MAP-T (was: Re: V6 still not supported)
Most IPv6 transition mechanisms involve some form of (CG)NAT. After watching a NANOG presentation on MAP-T, I have a question regarding this. Why isn't MAP-T more prevalent, given that it is (almost) stateless on the provider side? Is it CPE support, the headache of moving state to the CPE, vendor support, or something else? NANOG 2017 Mapping of Address and Port using Translation MAP T: Deployment at Charter Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w - Jared
Hi Jared, Theoretically, MAP is better. But 1. Nobody has implemented it for the router. The code for the CGNAT engine gives the same cost/performance. No promised advantage from potentially stateless protocol. 2.MAP needs much bigger address space (not everybody has) because: a) powered-off subscribers consume their blocks anyway b) it is not possible to add "on the fly" additional 64 ports to the particular subscriber that abuse some Apple application (and go to 1k ports consumption) that may drive far above any reasonable limit of ports per subs. Design should block a big enough number of UDP/TCP ports for every subs (even most silent/conservative). Ed/ -----Original Message----- From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Jared Brown Sent: Friday, March 25, 2022 4:49 PM To: nanog@nanog.org Subject: MAP-T (was: Re: V6 still not supported) Most IPv6 transition mechanisms involve some form of (CG)NAT. After watching a NANOG presentation on MAP-T, I have a question regarding this. Why isn't MAP-T more prevalent, given that it is (almost) stateless on the provider side? Is it CPE support, the headache of moving state to the CPE, vendor support, or something else? NANOG 2017 Mapping of Address and Port using Translation MAP T: Deployment at Charter Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w - Jared
The cost of deploying MAP in CPEs is a bit higher than 464XLAT, which is not an issue anyway. There are several open source implementations for both of them. It is true that MAP avoids state in the network, however, it means higher "cost" for users in terms of restrictions of ports. It also means more IPv4 addresses even if the ports are not used. In some countries, like India, MAP was not alllowed by the regulator, because the lack of proper logging, so it was push-back by the bigger provider (probably the bigger in the world - Jio) of IPv6. At the end, if you turn on IPv6 to residential customers, typically you will get 70-80% IPv6 traffic, so the state in the NAT64 using 464XLAT is lower and lower every day. With 464XLAT there is no restriction on the number of ports per subscriber, the usage of IPv4 addresses is more efficient, and of course, you can use the same protocol in cellular networks, with also make simpler the support of backup links in CPEs (for example GPON in the primary link and 4G in the backup one). Last but not least, 464XLAT also allows enterprise networks to swich to IPv6-only (with IPv4aaS) providing a smooth transition to a final IPv6-only stage. The fact that in terms of users 464XLAT exceeds all the other transition tehcnologies all together, should mean something. There is a bunch of information at https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/, which is just waiting for the final OK from the IESG to jumpt to the final stage (RFC Editor). Regads, Jordi Saludos, Jordi @jordipalet -----Original Message----- From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Jared Brown Sent: Friday, March 25, 2022 4:49 PM To: nanog@nanog.org Subject: MAP-T (was: Re: V6 still not supported) Most IPv6 transition mechanisms involve some form of (CG)NAT. After watching a NANOG presentation on MAP-T, I have a question regarding this. Why isn't MAP-T more prevalent, given that it is (almost) stateless on the provider side? Is it CPE support, the headache of moving state to the CPE, vendor support, or something else? NANOG 2017 Mapping of Address and Port using Translation MAP T: Deployment at Charter Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w - Jared ********************************************** 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.
Jordi - Very nice indeed! Please pass along my thanks to your coauthors for this most excellent (and badly needed) document! :-) /John
On 25 Mar 2022, at 4:53 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
The cost of deploying MAP in CPEs is a bit higher than 464XLAT, which is not an issue anyway. There are several open source implementations for both of them.
It is true that MAP avoids state in the network, however, it means higher "cost" for users in terms of restrictions of ports. It also means more IPv4 addresses even if the ports are not used. In some countries, like India, MAP was not alllowed by the regulator, because the lack of proper logging, so it was push-back by the bigger provider (probably the bigger in the world - Jio) of IPv6.
At the end, if you turn on IPv6 to residential customers, typically you will get 70-80% IPv6 traffic, so the state in the NAT64 using 464XLAT is lower and lower every day.
With 464XLAT there is no restriction on the number of ports per subscriber, the usage of IPv4 addresses is more efficient, and of course, you can use the same protocol in cellular networks, with also make simpler the support of backup links in CPEs (for example GPON in the primary link and 4G in the backup one).
Last but not least, 464XLAT also allows enterprise networks to swich to IPv6-only (with IPv4aaS) providing a smooth transition to a final IPv6-only stage.
The fact that in terms of users 464XLAT exceeds all the other transition tehcnologies all together, should mean something.
There is a bunch of information at https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/, which is just waiting for the final OK from the IESG to jumpt to the final stage (RFC Editor).
Regads, Jordi
Saludos, Jordi @jordipalet
It appears that JORDI PALET MARTINEZ via NANOG <jordi.palet@consulintel.es> said:
At the end, if you turn on IPv6 to residential customers, typically you will get 70-80% IPv6 traffic, so the state in the NAT64 using 464XLAT is lower and lower every day.
Not disagreeing, but where does that number come from? Anectodally, on my home network I see less than 50%. R's, John
It comes from actual measurements in residential networks that already offer IPv6. In typical residential networks, a very high % of the traffic is Google/Youtube, Netflix, Facebook, CDNs, etc., which all are IPv6 enabled. Typically, is also similar in mobile networks, and this has been confirmed also by measurements in v6ops mailing list, for example from T-Mobile. If I recall correctly that was 3-4 years ago and was already 75% IPv6 traffic. Enterprises usually have a lower IPv6 %, so actual numbers in a given ISP my depend on the ratio of enterprise/residential customers. It may also depend on the case of residentials, on the age of SmartTVs, which may not be IPv6 enabled. El 26/3/22, 18:02, "John Levine" <johnl@iecc.com> escribió: It appears that JORDI PALET MARTINEZ via NANOG <jordi.palet@consulintel.es> said: >At the end, if you turn on IPv6 to residential customers, typically you will get 70-80% IPv6 traffic, so the state in the NAT64 using 464XLAT is lower and lower every day. Not disagreeing, but where does that number come from? Anectodally, on my home network I see less than 50%. R's, John ********************************************** 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.
JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:
It comes from actual measurements in residential networks that already offer IPv6.
In typical residential networks, a very high % of the traffic is Google/Youtube, Netflix, Facebook, CDNs, etc., which all are IPv6 enabled.
I wonder about that... In our small corner of the world, Tore has these useful measurements from a dual stack "high volume" web site (a local newspaper). This is a mix of enterprise and residential users on all types of access (ethernet, HFC, GPON, DSL, pigeon): https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor.html These users have had native dual stack (DHCPv6-PD + DHCP) for 5+ years. And most of them use their operator provided CPEs where dual-stack is enabled by default. Still, as you can see, only 50% of the clients end up using IPv6. I don't know why, but assume this is caused by the client systems behind the CPE. Either they don't support IPv6 or the users have disabled it.
Typically, is also similar in mobile networks, and this has been confirmed also by measurements in v6ops mailing list, for example from T-Mobile. If I recall correctly that was 3-4 years ago and was already 75% IPv6 traffic.
Yes, for traditional mobile (i.e handsets) the picture is completely different. Same view shows an average of 85% IPv6 on mobile access: https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor_mobil.html Note that the last 3G cell was switched off in January 2021 in this network, eliminating any client older than 10 years in practice (2G is still supported, but... well, it's not going to show up on traffic volume measurments).
Enterprises usually have a lower IPv6 %, so actual numbers in a given ISP my depend on the ratio of enterprise/residential customers. It may also depend on the case of residentials, on the age of SmartTVs, which may not be IPv6 enabled.
Yes, this will also affect the first measurement since it is a mix of enterprise/residential. But the majority is residential, as this relative volume by time of day clearly shows: https://munin.fud.no/vg.no/www.vg.no/vg_ipv6_telenor.html In any case, I'll claim it's hard for a fixed access provider to achive much more than 50% IPv6 volume today. We'll have to start disabling IPv4 to get better results than that. Mobile is a different animal, with client systems being replaced constantly. Bjørn
Bjørn Mork wrote on 27/03/2022 10:42:
Yes, for traditional mobile (i.e handsets) the picture is completely different. Same view shows an average of 85% IPv6 on mobile access: https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor_mobil.html
from the point of view of cgnat scaling, a more useful figure would be the number of ipv6 "sessions" vs natted ipv4 sessions. It's well established that many of the highest volume traffic sources on the internet are ipv6 enabled, but the long tail is definitely not. I.e. throughput is not necessarily a useful data point for substantiating many of the claims that are made here and elsewhere about ipv6 popularity. Nick
FWIW, MAP has been deployed by few operators (in at least 3 continents that I am aware of). Charter communications is one of the public references (see NANOG preso https://www.youtube.com/watch?v=ZmfYHCpfr_w). MAP (CPE function) has been supported in OpenWRT software (as well as many CPE vendor implementations) for few years now; MAP (BR function) has been supported by few vendors including Cisco (in IOS-XE and XR). Cheers, Rajiv https://openwrt.org/packages/pkgdata_owrt18_6/map-t https://openwrt.org/docs/guide-user/network/map -----Original Message----- From: NANOG <nanog-bounces+rajiva=cisco.com@nanog.org> on behalf of Vasilenko Eduard via NANOG <nanog@nanog.org> Reply-To: Vasilenko Eduard <vasilenko.eduard@huawei.com> Date: Friday, March 25, 2022 at 11:17 AM To: Jared Brown <nanog-isp@mail.com>, "nanog@nanog.org" <nanog@nanog.org> Subject: RE: MAP-T (was: Re: V6 still not supported) Hi Jared, Theoretically, MAP is better. But 1. Nobody has implemented it for the router. The code for the CGNAT engine gives the same cost/performance. No promised advantage from potentially stateless protocol. 2.MAP needs much bigger address space (not everybody has) because: a) powered-off subscribers consume their blocks anyway b) it is not possible to add "on the fly" additional 64 ports to the particular subscriber that abuse some Apple application (and go to 1k ports consumption) that may drive far above any reasonable limit of ports per subs. Design should block a big enough number of UDP/TCP ports for every subs (even most silent/conservative). Ed/ -----Original Message----- From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Jared Brown Sent: Friday, March 25, 2022 4:49 PM To: nanog@nanog.org Subject: MAP-T (was: Re: V6 still not supported) Most IPv6 transition mechanisms involve some form of (CG)NAT. After watching a NANOG presentation on MAP-T, I have a question regarding this. Why isn't MAP-T more prevalent, given that it is (almost) stateless on the provider side? Is it CPE support, the headache of moving state to the CPE, vendor support, or something else? NANOG 2017 Mapping of Address and Port using Translation MAP T: Deployment at Charter Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w - Jared
The best MAP discussion (really rich in details) is from Richard Patterson. Sky has implemented green field FBB in Italy. He did many presentations in different places. This one should be looked from 00:37 to 1:09 https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-ipv... The absence of logs is a really big advantage. But where to get big enough IPv4 address space for MAP? XLAT464 would win anyway because it is the only IPv4aaS translation available on a smartphone. Eduard -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Saturday, March 26, 2022 12:44 AM To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Jared Brown <nanog-isp@mail.com>; nanog@nanog.org Subject: Re: MAP-T (was: Re: V6 still not supported) FWIW, MAP has been deployed by few operators (in at least 3 continents that I am aware of). Charter communications is one of the public references (see NANOG preso https://www.youtube.com/watch?v=ZmfYHCpfr_w). MAP (CPE function) has been supported in OpenWRT software (as well as many CPE vendor implementations) for few years now; MAP (BR function) has been supported by few vendors including Cisco (in IOS-XE and XR). Cheers, Rajiv https://openwrt.org/packages/pkgdata_owrt18_6/map-t https://openwrt.org/docs/guide-user/network/map -----Original Message----- From: NANOG <nanog-bounces+rajiva=cisco.com@nanog.org> on behalf of Vasilenko Eduard via NANOG <nanog@nanog.org> Reply-To: Vasilenko Eduard <vasilenko.eduard@huawei.com> Date: Friday, March 25, 2022 at 11:17 AM To: Jared Brown <nanog-isp@mail.com>, "nanog@nanog.org" <nanog@nanog.org> Subject: RE: MAP-T (was: Re: V6 still not supported) Hi Jared, Theoretically, MAP is better. But 1. Nobody has implemented it for the router. The code for the CGNAT engine gives the same cost/performance. No promised advantage from potentially stateless protocol. 2.MAP needs much bigger address space (not everybody has) because: a) powered-off subscribers consume their blocks anyway b) it is not possible to add "on the fly" additional 64 ports to the particular subscriber that abuse some Apple application (and go to 1k ports consumption) that may drive far above any reasonable limit of ports per subs. Design should block a big enough number of UDP/TCP ports for every subs (even most silent/conservative). Ed/ -----Original Message----- From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Jared Brown Sent: Friday, March 25, 2022 4:49 PM To: nanog@nanog.org Subject: MAP-T (was: Re: V6 still not supported) Most IPv6 transition mechanisms involve some form of (CG)NAT. After watching a NANOG presentation on MAP-T, I have a question regarding this. Why isn't MAP-T more prevalent, given that it is (almost) stateless on the provider side? Is it CPE support, the headache of moving state to the CPE, vendor support, or something else? NANOG 2017 Mapping of Address and Port using Translation MAP T: Deployment at Charter Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w - Jared
BR support is maturing nicely. A few other vendors with implementations: Arista - https://www.arista.com/en/support/toi/eos-4-24-0f/14495-map-t-border-relay Nokia - https://infocenter.nokia.com/public/7750SR140R4/index.jsp?topic=%2Fcom.sr.ms... Netgate/TNSR - https://docs.netgate.com/tnsr/en/latest/map/index.html Thx, Ben
On Mar 25, 2022, at 3:44 PM, Rajiv Asati (rajiva) via NANOG <nanog@nanog.org> wrote:
FWIW, MAP has been deployed by few operators (in at least 3 continents that I am aware of).
Charter communications is one of the public references (see NANOG preso https://www.youtube.com/watch?v=ZmfYHCpfr_w).
MAP (CPE function) has been supported in OpenWRT software (as well as many CPE vendor implementations) for few years now; MAP (BR function) has been supported by few vendors including Cisco (in IOS-XE and XR).
Cheers, Rajiv
https://openwrt.org/packages/pkgdata_owrt18_6/map-t https://openwrt.org/docs/guide-user/network/map
-----Original Message----- From: NANOG <nanog-bounces+rajiva=cisco.com@nanog.org> on behalf of Vasilenko Eduard via NANOG <nanog@nanog.org> Reply-To: Vasilenko Eduard <vasilenko.eduard@huawei.com> Date: Friday, March 25, 2022 at 11:17 AM To: Jared Brown <nanog-isp@mail.com>, "nanog@nanog.org" <nanog@nanog.org> Subject: RE: MAP-T (was: Re: V6 still not supported)
Hi Jared, Theoretically, MAP is better. But
1. Nobody has implemented it for the router. The code for the CGNAT engine gives the same cost/performance. No promised advantage from potentially stateless protocol.
2.MAP needs much bigger address space (not everybody has) because: a) powered-off subscribers consume their blocks anyway b) it is not possible to add "on the fly" additional 64 ports to the particular subscriber that abuse some Apple application (and go to 1k ports consumption) that may drive far above any reasonable limit of ports per subs. Design should block a big enough number of UDP/TCP ports for every subs (even most silent/conservative).
Ed/ -----Original Message----- From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Jared Brown Sent: Friday, March 25, 2022 4:49 PM To: nanog@nanog.org Subject: MAP-T (was: Re: V6 still not supported)
Most IPv6 transition mechanisms involve some form of (CG)NAT. After watching a NANOG presentation on MAP-T, I have a question regarding this.
Why isn't MAP-T more prevalent, given that it is (almost) stateless on the provider side?
Is it CPE support, the headache of moving state to the CPE, vendor support, or something else?
NANOG 2017 Mapping of Address and Port using Translation MAP T: Deployment at Charter Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w
- Jared
participants (9)
-
Ben Plimpton -
Bjørn Mork -
Jared Brown -
John Curran -
John Levine -
JORDI PALET MARTINEZ -
Nick Hilliard -
Rajiv Asati (rajiva) -
Vasilenko Eduard