Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

[Fernando Frediani <[e-mail]>]

On 04/01/2020 00:33, Alejandro D'Egidio wrote:
>
>> Folks,
>>
>> I've read the document, and have the following comments:
>>
>> It would seem to me is that this document has resulted from an
>> operators' concern that deployment of 464xlat might result in
>> unnecessary heavyweight use of the stateful PLAT, leading to scalability
>> problems or unnecessary money spendings. In that sense, I would like the
>> issue to be documented (even if somehow we don't agree on a workaround).
> Yes, from one point of view it is correct what you said and in addition to that we have an unnecessary second translation (NAT64) when customer traffic was translated to IPv6 (NAT46) and the destination (content) is available in IPv6 also, so we could avoid both a bottleneck and a performance impairment. That's why we consider this as an optimization.

This is the biggest thing of this proposal, eliminate any unnecessary 
double translation where it's not needed and 'convert' any traffic that 
would originally happen in IPv4 (due to legacy devices behind the CPE) 
into IPv6 to external world. This has as result a even smaller need of 
IPv4 addresses in the PLAT to communicate to these destinations which 
have IPv6 support. 464XLAT is already great in saving IPv4 addresses and 
with this proposal it helps to reduce even more the dependency of IPv4 
regardless the devices the user has at home.

This is also an advantage over CGNAT + IPv6 scenarios where this IPv4 
traffic originated from these legacy devices can't bypass the CGNAT 
device. So in this case it translates into even higher savings as it 
means even less traffic passing through the PLAT device.

Regards
Fernando