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) >>>> 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. >>> >>> 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. 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
