2012-03-19 11:44, Maoke: > 2012/3/19 Rémi Després <[email protected]> > Le 2012-03-19 à 10:21, Maoke a écrit : >> 2012/3/19 Rémi Després <[email protected]> >> Le 2012-03-19 à 09:16, Maoke a écrit : >>> 2012/3/16 Rémi Després <[email protected]> >>> Maoke, >>> >>> Let me try a more complete picture than before: >>> >>> >>> A1 -----. >>> RFC6145-host| .-- 4rd BR --. >>> | | | >>> A2 -----:--(v6net)--: :--(v4 Internet)--- B >>> 4rd-CE | | | UDP Lite appli >>> >>> (no IPv4 @) | '-- NAT64+ --' >>> | >>> A3 -----' >>> 4rd-CE >>> (IPv4 @, shared or not) >>> >>> >>> NAT64+ is supposed to have a bindings for UDP Lite, either only for 4rd >>> IPv6 addresses (the minimum), or also for native IPv6 addresses (the >>> complete upgrade, with UDP-Lite checksum adjustment for these addresses) >>> >>> Connectivities I get are: >>> A2 => B (via NAT64+) >>> A3 <=> B (via 4rd BR) >>> (There is no A1-B connectivity) >>> ... >> let me have the following propositions: >> >> a. NAT64 suitable for any case no matter A2 is assigned with any kind of >> address, but currently only works for TCP and UDP. > > Yes (but with the DF bit transparency limitation that is avoided in case of > NAT64+) > >> b. NAT64+ works for the cases where A2 is assigned with a special type of >> IPv6 address with the CNP, without need to update checksum for any L4 >> protocols.
Seems right: no L4 update for IPv6 addresses having 4rd-U format. >> >> c. NAT64+ works like: >> if A2 has a V-CNP-address, then it doesn't update the checksum for any L4 >> protocols; >> if A2 has any other kind of native IPv6 address, then NAT64+ works just >> like NAT64, updating the checksum but also currently only works for TCP and >> UDP. Seems right too, and more precise. >> >> i think we are common that a. is true, right? > > Right, with the caveat above. > >> do you mean c. instead of b. ? > > NAT64+ works like NAT64 in all cases, except for 4rd CEs that: > - received a NAT64+ mapping rule > - have IPv6 prefixes from which no IPv4 address can be derived. > For them, better transparency is achieved by replacing double RFC6145 > translation by a Reversible header mapping. > > not yet cleared. "receives a NAT64+ mapping rule" for what? A CE receives the NAT64 mapping rule to know that, although it has no public IPv4 address, it can reach IPv4 servers via NAT64+, and thus avoid any v4/v6 translation (more transparent). > is the NAT64+ mapping rule stateless or stateful? The rule per se is neither. It just says what the CE has to do if having no public IPv4 address. What the NAT64+ must be stateful, at least for IPv6 addresses that are not mapped to any public IPv4 address. > what the behavior of NAT64+ in the case of "except"? is there "and" or "or" > between the "received ..." and the "have IPv6 prefixes..." clauses? Not understood. > please answer directly: do you mean c. instead of b.? (or, if either is not > applied, and you may have d.) If pressed to make a choice, c. seems a better expression of what is specified than b. Cheers, RD (Retransmitted with much unnecessary text deleted. The message was refused as being too long for the mailing list)
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
