Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

[Washam Fan <[e-mail]>]

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