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
- 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/
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 draft-ietf-v6ops-transition-comparison-02 - Pros and Cons of IPv6 Transition Technologies for IPv4aaS, which is just waiting for the final OK from the IESG to jumpt to the final stage (RFC Editor).
Regads,
Jordi
Saludos,
Jordi
@jordipalet
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 RIPE NCC Open House: IPv6-Only Networks — RIPE Network Coordination Centre
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
Jordi -
Very nice indeed! Please pass along my thanks to your coauthors for this most excellent (and badly needed) document!
/John
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
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
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
-----Original Message-----
BR support is maturing nicely. A few other vendors with implementations:
Arista - Login - Arista
Nokia - Help -
Netgate/TNSR - MAP (Mapping of Address and Port) | TNSR Documentation
Thx,
Ben