Re: MAP-T (was: Re: V6 still not supported)
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.msisa%2Fhtml%2Fnat.html 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 > 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 on behalf of Vasilenko > Eduard via NANOG > Reply-To: Vasilenko Eduard > Date: Friday, March 25, 2022 at 11:17 AM > To: Jared Brown , "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@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 >
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 on behalf of Vasilenko Eduard via NANOG Reply-To: Vasilenko Eduard Date: Friday, March 25, 2022 at 11:17 AM To: Jared Brown , "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@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
Re: MAP-T (was: Re: V6 still not supported)
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" escribió: It appears that JORDI PALET MARTINEZ via NANOG 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.
Re: MAP-T (was: Re: V6 still not supported)
It appears that JORDI PALET MARTINEZ via NANOG 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
v6ops-transition-comparison (was: Re: MAP-T (was: Re: V6 still not supported))
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 > 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
RE: MAP-T (was: Re: V6 still not supported)
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-ipv6-only-networks 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:raj...@cisco.com] Sent: Saturday, March 26, 2022 12:44 AM To: Vasilenko Eduard ; Jared Brown ; 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 on behalf of Vasilenko Eduard via NANOG Reply-To: Vasilenko Eduard Date: Friday, March 25, 2022 at 11:17 AM To: Jared Brown , "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@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
Re: MAP-T (was: Re: V6 still not supported)
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@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.
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@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
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
