Has anyone implemented a MAP-T solution in production? I am looking for feedback on this as a deployment strategy for an IPv6 only core design. My concern is MAP-T CE stability and overhead on the network. The BR will have to do overloaded NAT anyway to access IPv4 only resources. The idea being that when IPv4 is no longer needed, this will be a quicker “clean-up” project than a dual-stack solution.
I have reviewed Jordan Gotlieb’s presentation from Charter and would love to hear if this is still in use at Charter or if was ever fully implemented and the experiences)
I’d love any real life examples and success/failure stories.
For the record, we are asking similar questions about 464XLAT in v6ops. If you are deploying it, please advise Jordi Palet Martinez.
For those unfamiliar with them, MAP-T and 464XLAT are each deployment frameworks for IPv4/IPv6 translation, as described in RFCs 4164, 4166, 4167, and 7915.
I'd love to hear about this (or MAP-E, or lw4o6) as well especially with regard to CPE support. My preferred CPE vendor keeps punting on it (though they do claim to support 464XLAT), and I'd really like something to point them to that will show them it's a "real thing". Getting rid of state at the CGN as is (or can be, at least) necessary with 464XLAT seems like a real boon while placing minimal additional burden on the CPE.
Has anyone implemented a MAP-T solution in production? I am looking for feedback on this as a deployment strategy for an IPv6 only core design. My concern is MAP-T CE stability and overhead on the network. The BR will have to do overloaded NAT anyway to access IPv4 only resources. The idea being that when IPv4 is no longer needed, this will be a quicker “clean-up” project than a dual-stack solution.
I have reviewed Jordan Gotlieb’s presentation from Charter and would love to hear if this is still in use at Charter or if was ever fully implemented and the experiences)
Does not loo like Charter moved the needle in the last few years
I’m tracking all possible products and deployments of NAT64/DNS64/464XLAT. I’ve done a few of them myself for many customers.
The idea is to bring the relevant RFCs to Internet Standards
We could try to do the same also with MAP-T and others. However, my point right now is that the one with a bigger deployment is 464XLAT (hundreds of millions of subscribers), which exceeds by far what has been done with all the other transitions technologies all together. The funny thing is that 464XLAT is just “informational”
Regards,
Jordi
@jordipalet
For the record, we are asking similar questions about 464XLAT in v6ops. If you are deploying it, please advise Jordi Palet Martinez.
For those unfamiliar with them, MAP-T and 464XLAT are each deployment frameworks for IPv4/IPv6 translation, as described in RFCs 4164, 4166, 4167, and 7915.
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.
If you have a network with both cellular and wireline, clearly 464XLAT is the only solution to have a single transition mechanism.
I've been working a lot with CPE providers (see RFC8585), and I believe that 464XLAT is getting more support.
I'm now involve in a 25.000.000 subscribers 464XLAT deployment project (DSL, GPON and cellular) ... just slowed down because the Covid-19 situation, but a small test best passed all the "evil" testing that we tried.
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.
I’ve gotten a lot of great feedback and want to restate some of my thoughts for further discussion:
1. It seems like the MAP-T is still in an initial phase of development/production. I’ve seen a few other people mentioning it, but it is early in deployment today.
2. When working with smaller and regional eye-ball networks throughout the US you need to be aware of a couple things. Think no engineering team, just an implementation crew and local support people (Small telco mentality). They need commercially available and widely supported solutions.
Based on the feedback I’ve seen so far, I would think that positioning a MAP-T solution in these scenarios might be more of a hassle and turn into a support nightmare. I’m leaning toward DS-lite and NAT444 right now as these are more proven and have greater deployed bases.
My approach thus far absent CPE support for transition mechanisms has been native IPv6 across the board + NAT444, but I use a VRF to regionalize the NAT444 routing and bring it to a semi-centralized gateway much like one would using DS-Lite, 464XLAT, MAP, LW4o6, etc.
No need to forklift anything, and you can deploy whatever suits you incrementally in regions where you need to. It also works with all user-supplied CPE routers which is a bonus as I hate to require that users use my CPE router, and it's not yet easy for consumers to verify beforehand that the router they're buying at Best Buy will support any particular transition tech, though I'd really like to get that fixed.
I'm quite small, though. I can imagine this would be a hassle compared to running a single stack access layer at scale, and of course the NAT is stateful no matter what you do with this technique.
NAT444 CGN does NOT solve an IPv6 problem at all. It solves an IPv4 shortage problem at best and is not designed as a long-term solution. I cannot force customers to buy new equipment to make them IPv6 compliant. The best option is to support, fully and unabashedly, IPv6 and help with the transition from IPv4 using techniques to solve for the problems/corner-cases.
All transition technologies are band-aids. We are talking about ways to bridge a gap. Anyone looking at any of these techniques as an end design goal has missed the IPv6 point all together and is not serving their users/customers well. In the end, we will have everyone on IPv6 and this entire conversation is mute.
BTW… name a transition technology that is supported by all legacy equipment…. I’ll enjoy the silence.
While I believe I in time will get at least 90% of residential users on IPv6, the track record for commercial customers is close to 0%. Also the number of websites and other Internet services with ipv6 is abysmal. We are somewhat saved by the American internet gigants which means that by traffic volume we are already halfway there.
My take is that the so called transition is going to last forever or so long that it could as well be. By volume and by end users we might get to 90% but no more. We need to plan for that and accept that is how it will be.
IPv6 is already saving money by reducing the need for NAT444 or NAT64. That 50% IPv6 traffic just doubled the number of users per NAT server. If we can get that to 90% we will have 10 times the users per server. Huge thanks to Netflix, Google, Apple, Akamai, Facebook etc for that.
With that said I would love to one day deploy MAP or LW4o6 simply to get rid of that NAT server. We need IPv4 as a service and stateless in the network. If we need to keep ipv4 around for a long time, we can as well make it easy and cheap.
