v6ops-transition-comparison (was: Re: MAP-T (was: Re: V6 still not supported))

[John Curran <jcurran () istaff org>]

Jordi - 

        Very nice indeed!   Please pass along my thanks to your coauthors for this most excellent (and badly needed) 
document!

:-) 
/John

> On 25 Mar 2022, at 4:53 PM, JORDI PALET MARTINEZ via NANOG <nanog () nanog org> wrote:
>
> The cost of deploying MAP in CPEs is a bit higher than 464XLAT, which is not an issue anyway. There are several open 
> source implementations for both of them.
>
> It is true that MAP avoids state in the network, however, it means higher "cost" for users in terms of restrictions 
> of ports. It also means more IPv4 addresses even if the ports are not used. In some countries, like India, MAP was 
> not alllowed by the regulator, because the lack of proper logging, so it was push-back by the bigger provider 
> (probably the bigger in the world - Jio) of IPv6.
>
> At the end, if you turn on IPv6 to residential customers, typically you will get 70-80% IPv6 traffic, so the state in 
> the NAT64 using 464XLAT is lower and lower every day.
>
> With 464XLAT there is no restriction on the number of ports per subscriber, the usage of IPv4 addresses is more 
> efficient, and of course, you can use the same protocol in cellular networks, with also make simpler the support of 
> backup links in CPEs (for example GPON in the primary link and 4G in the backup one).
>
> Last but not least, 464XLAT also allows enterprise networks to swich to IPv6-only (with IPv4aaS) providing a smooth 
> transition to a final IPv6-only stage.
>
> The fact that in terms of users 464XLAT exceeds all the other transition tehcnologies all together, should mean 
> something.
>
> There is a bunch of information at https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/, which is 
> just waiting for the final OK from the IESG to jumpt to the final stage (RFC Editor).
>
> Regads,
> Jordi
>
>
> Saludos,
> Jordi
> @jordipalet