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? > 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? 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
