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

John Curran jcurran at istaff.org
Sat Mar 26 16:19:53 UTC 2022


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


More information about the NANOG mailing list