MAP-T in production
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. Thanks. - Brian
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. Sent from my iPad
On Jul 22, 2020, at 2:16 PM, Brian Johnson <brian.johnson@netgeek.us> wrote:
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.
Thanks.
- Brian
I’m here ;-) 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 El 22/7/20 23:25, "NANOG en nombre de Fred Baker" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de fredbaker.ietf@gmail.com> escribió: 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. Sent from my iPad On Jul 22, 2020, at 2:16 PM, Brian Johnson <brian.johnson@netgeek.us> wrote: 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. Thanks. - Brian ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 7/22/20 5:15 PM, Brian Johnson wrote:
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.
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. -- Brandon Martin
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. See also RFC8683. Regards, Jordi @jordipalet El 22/7/20 23:32, "NANOG en nombre de Brandon Martin" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de lists.nanog@monmotha.net> escribió: On 7/22/20 5:15 PM, Brian Johnson wrote: > 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. 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. -- Brandon Martin ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
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
On Wed, Jul 22, 2020 at 2:18 PM Brian Johnson <brian.johnson@netgeek.us> wrote:
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 https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/Char...
I’d love any real life examples and success/failure stories.
Thanks.
- Brian
On 22/07/2020 22:15, Brian Johnson wrote:
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.
Richard Patterson did a talk about Sky Italia's 'greenfield' build at UKNOF45, earlier this year: https://www.youtube.com/watch?v=9Cg3dLR95wY Lots of interesting stuff in there, but the pertinent broadband termination parts - which go on to mentioning MAP-T - start at ~15:00. Regards, -- Tom
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. Thoughts… - Brian
On Jul 22, 2020, at 4:15 PM, Brian Johnson <brian.johnson@netgeek.us> wrote:
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.
Thanks.
- Brian
On 7/24/20 10:46 PM, Brian Johnson wrote:
OK Randy. How about a suggestion that is useful.
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. -- Brandon Martin
OK Randy. How about a suggestion that is useful.
I’m leaning toward DS-lite and NAT444 a great path. fork lift all cpe and cgn in the core. the vendors' dream
$subject. map-e. ... the list is long. ds-lite is close to the bottom of it, except if you are a vendor salesperson. randy
On 25/Jul/20 03:24, Randy Bush wrote:
a great path. fork lift all cpe and cgn in the core. the vendors' dream
All major vendors are shipping IPv6. Some even 464XLAT. And yet they will not put those forward as long term solutions. As Randy points out, CG-NAT sells plenty in license fees. And you need more and more, every year. Not less. So, go ahead and enrich the vendors, at the expense of your business. And we shall all wonder why they keep saying "But no one is asking for IPv6". Mark.
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. ;)
On Jul 26, 2020, at 7:23 AM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 25/Jul/20 03:24, Randy Bush wrote:
a great path. fork lift all cpe and cgn in the core. the vendors' dream
All major vendors are shipping IPv6. Some even 464XLAT. And yet they will not put those forward as long term solutions.
As Randy points out, CG-NAT sells plenty in license fees. And you need more and more, every year. Not less.
So, go ahead and enrich the vendors, at the expense of your business. And we shall all wonder why they keep saying "But no one is asking for IPv6".
Mark.
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. Regards Baldur man. 27. jul. 2020 21.05 skrev Brian Johnson <brian.johnson@netgeek.us>:
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. ;)
On Jul 26, 2020, at 7:23 AM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 25/Jul/20 03:24, Randy Bush wrote:
a great path. fork lift all cpe and cgn in the core. the vendors' dream
All major vendors are shipping IPv6. Some even 464XLAT. And yet they will not put those forward as long term solutions.
As Randy points out, CG-NAT sells plenty in license fees. And you need more and more, every year. Not less.
So, go ahead and enrich the vendors, at the expense of your business. And we shall all wonder why they keep saying "But no one is asking for IPv6".
Mark.
participants (9)
-
Baldur Norddahl -
Brandon Martin -
Brian Johnson -
Ca By -
Fred Baker -
JORDI PALET MARTINEZ -
Mark Tinka -
Randy Bush -
Tom Hill