hi Remi, sorry but i follow this late. something not clear to me, according to our earlier discussions.
2012/3/8 Rémi Després <[email protected]> > > Le 2012-03-08 à 03:47, Washam Fan a écrit : > > > Hi Remi, > > > >>>>> Secondly, -04 added NAT64+ parts. > >>>>> If I understood correctly, there are no additional requirements for > NAT64 > >>>>> boxes. > >>>> > >>>> Well, NAT64 boxes remain what they are. > >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 > although it > >>>> has a dual stack. > >>>> > >>>> But the advantage of 4rd tunneling over RFC6145 double translation is > better > >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols > that may > >>>> use the TCP checksum algorithms) > to clarify my understanding: 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the DF=1/MF=1 cases 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message directly as IPv6 payload is a wise idea. lack of address consistency ensurance mechanism (i.e. no header checksum in IPv6 header no pseudo-header checksum in ICMPv4 message) 3. for the "future protocols", i remember our earlier discussion concluded that CNP can free the code change with ALREADY KNOWN tcp-checksumed protocols. am i wrong here? > >>>> For an ISP to extend this advantage to its stateful NAT64, it need to > be 4rd > >>>> aware (become a NAT64+). > >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address > (with a V > >>>> octet instead of a "u" octet), use the 4rd header mapping instead of > RFC6145 > >>>> translation. > questions: 1. NAT64+ here refers to stateful case only, right? 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decision between 4rd-U pseudo-encapsulation (let me use this term because i argue it does not conform to the behavior of encapsulation) and NAT64 translation? (as we have neither V nor U in the IPv4 addresses). > >>> > >>> I perfer to leave NAT64 out of scope. > >> > >> NAT64 as is remains out of scope. > >> What is in scope is only the possibility to improve IPv4 transparency > of NAT64 nodes by using transparent tunneling, instead of double > translation, when reached by 4rd CEs (making them NAT64+ nodes). > > > > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a > > new term NAT64+ invented? > > > NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 needs > to be upgraded to replace RFC5145 translation by header mapping when IPv6 > addresses it deals with are 4rd addresses (have the V octet). > > > > > >> This new capability, introduced in -04, is derived from the 464XLAT > proposal. > >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only networks > can communicate via NAT64s, but IPv4 transparency has limitations which can > be eliminated by upgrading NAT64s to NAT64+ status (a backward compatible > evolution). > >> > > > > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? > > To take advantage, for customers that are 4rd capable, of better IPv4 > transparency than with double translation, the NAT64 MUST be upgraded. > may i add that it (4rd-U) provides better IPv4 transparency than double translation but less simplicity in the term of layering architecture than encapsulation? (here i avoid sticking things on my understanding to "transparency"). personally i don't think transparency is the most important reason that generally operators prefer encapsulation rather than translation. simplicity and clear concept in architecture is the reason. no matter how much we keep IPv4 information unchanged across the IPv6 domain, as long as the IPv4 header is destroyed, it is a solution of "translation" rather than of "encapsulation". i don't incline to use the term "tunneling" since tunnel could have a variety of forms, among which encapsulation is one but not the only one. cheers, maoke > Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts, > or dual-stack hosts supporting BIH of RFC6535): they can continue to use > the NAT64+ as an ordinary NAT64. > > Regards, > RD > > > > > Thanks, > > washam > >>> Such transparency could be achieved by whther to add fragmentation > header. > >>> Anyway, let's hear some comments from the group > >> > >> OK > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
