Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

[Ole Troan <[e-mail]>]

> A specific example: certain vpn clients, still in service, fail when tethered to a nat64/dns64 device. Typically, a customer is tethering their work machine to their personal handset. NAT64/DNS64 does not provide what the client needs and neither can the OS. Such client SW may be older but is still in service, they are not yet end of support.
> 
> Customers care if this breaks. So do I, this is doing harm. And no, they won't revert to their corp IT dept. They know this relates to their provider.
> With 464xlat these usecases simply work.
> I have zero calls into customer services concerning devices with 464xlat.
> 
> 464xlat is the reason why IPv6-only can work where the end OS is unknown.
> IPv6-only for the handset mass-market is the way to mitigate exhaustion.

464xlat is a mechanism to deliver IPv4 service across an IPv6 transport.
Yes, it mitigates exhaustion. - By sharing a single IPv4 address among more and more end-users.
It's just like any other CGN, with the differences being that you need CE support and you can disable IPv4 in the access network.

MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much all do the same.
The main difference is where session state is kept.

464XLAT or more commonly deployed 44464XLAT is the worst of any combination. It keeps sessions state both at the CE/CLAT and the BR/PLAT. Building scalable stateful devices is hard and expensive. And in the case of IPv4 sharing mechanisms unnecessary.

Ole