nanog mailing list archives

Re: MAP-T in production


From: Brandon Martin <lists.nanog () monmotha net>
Date: Wed, 22 Jul 2020 19:44:32 -0400

On 7/22/20 6:04 PM, JORDI PALET MARTINEZ wrote:
The comparison between MAP-T and 464XLAT is not just state.

With 464XLAT you can have more subscribers (almost unlimited) per IP address, without a limitation on the number of 
ports, so you save a lot of money in addresses.

And of course, a limited number of ports in MAP-T means troubles for customers, so help desk cost.

Indeed, the static nature of the carrier-side NAT64 translation, while removing state, also imposes restrictions that 
get more severe as you increase the degree of address overload.  I can certainly see why the cellular folks can't 
feasibly adopt it.

However, for strictly wireline folks, especially those just starting to run into address space exhaustion problems, 
even a 4:1 overload or so is quite useful and is likely, I think, to generate no more support load than fully stateful 
carrier-side NAT64 ala 464XLAT or NAT444 which is the punt solution, per se.

I think that both technologies have their strong use cases.  Folks needing lots of overload will probably prefer 
464XLAT and just suck up the state handling for reasons you describe, while folks who figure they can essentially run 
out the clock on nearly-complete IPv6 transition with only modest overload may prefer MAP or LW4o6.

I've been working a lot with CPE providers (see RFC8585), and I believe that 464XLAT is getting more support.

This has also been my experience.  My preferred CPE vendor is claiming 464XLAT support now (though I've not tested it), 
but doesn't appear to even know what MAP or LW4o6 are and certainly has expressed no plans to support it at least at 
the sales engineer questionnaire level.
-- 
Brandon Martin


Current thread: