IPv6 adoption is growing. Around 30% of the Alexa Top 1000 websites support IPv6. Comcast, the ISP I am using, rolled out IPv6 to every customer, and according to some statistics, around 70% are actually using it [1]. About 35% of traffic reaching Google uses IPv6 [2]. I have been using IPv6 myself for probably over a decade by now. Initially via Hurricane Electric tunnels, and later as Comcast made IPv6 available, I used the allocation provided by Comcast. So why stop using it now?

To better understand who is using IPv6, let's "zoom in" on Google's IPv6 statistic. The graph is notably "noisy." But the reason it looks so broad isn't noise: IPv6 usage is higher on Weekends compared to Weekdays.

The reason is pretty simple. For ISPs, IPv6 is needed in case they run out of IPv4 address space. Currently, not a lot of enterprises or businesses are adding IP address space. Actually, the opposite is happening: Enterprises are dismantling datacenters and are moving them into the cloud. 

This leaves home users, particularly mobile users, as the main growth area for IP addresses and, with that, the sole use case for IPv6. But ISPs still have to support IPv4 access as well, often via carrier-grade NAT (cgNAT). By having to support both IPv4 and IPv6, ISPs have not really been able to take advantage of everything IPv6 has to offer, and implementations have been "messy."

How IPv6 is supposed to work

IPv6 has a lot of promise. Or should I say: IPv6 promises a lot of features. One of the big ones is end-to-end connectivity and the end of NAT. For a home user, NAT isn't really a bit problem. But for carriers, NAT is getting complex and expensive. Some estimates talk about up to $40/year/user [3]. IPv6 also has the potential to be faster, but real-world results are mixed at this point. IPv6 works best if end-user networks are assigned a /48. This may sound like an excessive amount of addresses, but there is a reason for /48s being the "sweet spot." First of all, the minimum network size in IPv6 is a /64. Your ISP will typically assign you at least a /64. But this allocation can not be split into various subnets, making it impossible to, for example, set up a distinct IoT subnet. With IPv4, we can use NAT to create various subnets. But with IPv6, we do not really have NAT as an option. 

Unless: If you have a /48!. A/48 is so "magic" because you have 16 bits to play with. This allows for the use of "Prefix Translation." Yes! NAT for IPv6. The main advantage of this over plain old NAT is that each internal IP address will be mapped to a unique external address. But why do "NAT" in IPv6? Because you may need to renumber... For IPv4, having your external IP address change isn't a big deal. NAT will make the change transparent to your network. But in IPv6, renumbering may have to happen too, and with all hosts in your network using publicly routed IP addresses, you will need to renumber every single host in your network. Sure... some of this can be automated... if it works.

RIPE, the European regional internet registry, suggests a "/48 for everybody" in its "Best Current Operational Practice" document [4] . From this document:

4.2.1. /48 for everybody

This is probably the most practical way to assign IPv6 prefixes to end customer CPE devices. In this case everyone has a /48 prefix and advanced end-users are less likely to make mistakes when addressing their networks and devices, resulting in much less call-centre time to sort out problems. It also has the advantage of sharing the same prefix size as ULAs and some transition mechanisms, so this facilitates a direct mapping of existing customer addressing plans to the delegated prefix.

Sadly, ISPs have made extra money selling IP address allocations and are unwilling to hand out /48s. IPv6 is a beautiful protocol. It removes many of the rough edges of IPv4 and turns IPv4, a research experiment that essentially was left running by mistake, into a global business network.

So let's look at some current IPv6 implementations I have had first-hand experience with and why they fail.

AT&T Mobile

All AT&T mobile phones will be assigned a /64. Devices tethered to a mobile phone will receive addresses from this /64. This works well for mobile phones as you are not likely to run a complex network from a mobile phone. But AT&T has a special treat for you: NAT! All IPv6 traffic from the phone appears to be NAT'ed. This will remove the biggest advantage of IPv6 immediately. No idea why IPv6 would do that.

T-Mobile Mobile Phone

Again, your phone will receive an IPv6 /64. T-Mobile may also take advantage of "464 XLAT" if your phone supports it [5]. This protocol will encapsulate all your IPv4 traffic into IPv6. T-Mobile will only "see" IPv6 traffic on its network and NAT IPv4 at its border. Pretty neat set up but can be "messy" in that your phone no longer has a unique IPv4 address within T-Mobile's network (not even a unique unroutable address, but instead, 464XLAT uses a small netblock set aside for 464-XLAT, so essentially all phones use the same IPv4 address) [6].

But from my own experience, neither T-Mobile nor AT&T allows inbound traffic to the phone's IPv6 address. This negates some of the advantages of having a globally routable IPv6 address.

T-Mobile 5G Home Internet

This service is still rather new, and I have only been experimenting with it for a couple of days. But it appears to work pretty much like the T-Mobile phone-based internet service. Your T-Mobile gateway is assigned a NAT'ed IPv4 address and a single /64. You cannot use IPv6 if you are using your own router/firewall connected to the 5G access point, and for IPv4, you have to deal with double/tribble NAT. Unless all of your devices are directly connected to the access point, IPv6 is useless.

T-Mobiles gateway is also locked down and not allowing any "bridge mode" or other configuration options.

Comcast/Xfinity Business Service

Comcast will assign business users a /56. You may connect a router to the modem, and it may request a /59 allowing for multiple routers to be connected. But be aware that the modem doesn't really track which router gets what /59, so after a reboot, your router may get a different /59 (out of the /56 assigned to the modem). Also, Comcast currently does not offer static IPv6 assignments. If you change your modem, you will get a new /59 even if your IPv4 address range remains the same (if you paid for a static IPv4 address). In the past, Comcast also changed its allocation policies without notice. For example, it used to be that the router received a /60 from the modem. Now it does receive a /59. The route MUST request the address via DHCP, or the modem will not know how to route it. Expiring DHCP leases or a modem reboot will break IPv6. (Comcast sometimes reboots modems without notice for firmware upgrades). Only obtaining a /56 and not having the ability to use special IPv6 features like mobile IP, failover to another carrier will not work.

By default, the Comcast supplied modem will block inbound IPv6, but this is easily adjusted (so actually a good thing to set it up secure by default). The firewall in the modem is a bit of a joke, but well, it blocks some packets...

Comcast IPv6 Firewall Configuration Options

All Carriers: Support

So far, I have not had a successful support call regarding IPv6 with any ISP. As far as the ISP is concerned: If IPv4 is working for you, your connection is working, and there is no reason for them to fix anything. 

Final words

No static IPv6 addresses, no /48 allocations, inability to do fail over to a different carrier, stability issues, and lack of support are why I now, after 10+ years, no longer use IPv6 in my network. There are pockets where I may still use it, but so far, there isn't really a good reason to keep IPv6 enabled. Nothing "broke" so far. Lackluster implementations by ISPs that fix the current issue and no/limited use of ISPs by enterprise networks and cloud providers make it difficult to justify the time it takes. And maybe I am getting too old to play with my network configuration all the time.

Please comment if you had your own experience with IPv6 you would like to share.

[1] https://www.worldipv6launch.org/measurements/
[2] https://www.google.com/intl/en/ipv6/statistics.html
[3] https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf
[4] https://www.ripe.net/publications/docs/ripe-690
[5] https://datatracker.ietf.org/doc/html/rfc6877
[6] https://www.internetsociety.org/resources/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|