MAP-T in production

Brandon Martin lists.nanog at monmotha.net
Wed Jul 22 23:44:32 UTC 2020


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



More information about the NANOG mailing list