About IPv6 Traffic Volume

Usual preamble when I rant about IPv6: what you’re about to read is my own personal opinion, repeated over the years and across employers. On my own blog I do not represent my employer, and my views do not necessarily align with its own. I have no vested interest in either success or failure of this particular technology.

Earlier this year, in a number of areas populated by IPv6 enthusiasts and geeks, there has been quite a bit of excitement going around – Google’s statistics showed that the IPv6 traffic to their services reached 45% last September, and from there, the in-group extrapolated that we’d hit 50% this year (2024.) By the time I’m writing, we’re at the end of September 2024, and nearly 13 months after those predictions… Google’s traffic has lowered back to 44%. Oops.

These type of interestingly odd targets (why care about 45% rather than 50%?) are usually a good opportunity for networking nerds to feel smug towards those naysayers and retrogrades that insist on using “legacy” IPv4 despite the many times we have been told that there are no addresses available, and that the world had moved on in 2013. As you can tell, I’m being a bit more heavy on the sarcasm than usual about this, but it is a topic that I keep writing about year in and year out, with very few breakthroughs when it comes to end-user adoption of IPv6.

So, let’s start with a question: does the traffic to Google (or to my current employer’s) represent an useful target to identify when IPv4 can be considered a completely legacy technology? I guess it does from the point of view of end-user adoption, which is exactly how both companies report their current statistics. It’s something that makes sense to me: as most operating systems will prefer sending requests over IPv6 if available, you can read the statistics in the opposite way, and understand that roughly 55% of users connect to Google services from providers that do not have IPv6 available. Obviously, this sounds less optimistic.

Above I made a caveat about end-user adoption. Indeed, for corporate, or enterprise, networks, IPv6 is a different story altogether. Back when I used to run the Gentoo Tinderbox, I have used IPv6 to reduce its network access, and constrain it to accessing the outside world through a proxy. You shouldn’t be surprised if complex backend architectures are designed with IPv6-only in mind — even though Docker does make that still miserable to this day, but I guess this is a topic for another time.

I would then move to a different question: so what if more than half the traffic on the Internet was transiting over IPv6? In my opinion, that would make not much of a difference, because of what the traffic consists of, nowadays. Indeed, if you paid any attention, the traffic mix of the Internet at large has significantly changed in the past ten or so years — Netflix, YouTube, Disney+ and all of the video streaming platforms either didn’t exist, or weren’t as widespread back when World IPv6 Launch was established. TikTok, Instagram, and the various other social networks were barely able to keep up with pictures, let alone video or live streaming. Twitch wasn’t a thing, so you can forget about GeForce Now, XBox Live and the other cloud gaming options too! OnLive and Gaikai were barely out of concept stage.

What I mean with this is that all of these streaming- and video-heavy services nowadays make up most of the traffic by bandwidth already alone. Depending on how the distribution of streaming traffic maps against the distribution of end-user IPv6 networks, it may very well be that we’re already in a situation where more than half of the traffic (represented in Tbps) is transiting over IPv6, without getting us any closer to be able to turn off IPv4 connectivity at large.

Another likely large slice of traffic transiting over IPv6, that doesn’t in my opinion move the needle regarding sunsetting IPv4, is provided by the increasingly fundamental role played by CDNs (Content Delivery Networks) such as Akamai, Cloudflare, or in the case of open source software projects, BunnyCDN. While these already existed ten years ago, it was still newsworthy when coordinated attacks took down important sites, and with the limited penetration of general cloud computing even then, penny-pinching on the traffic hitting your webservers directly wasn’t particularly high in anyone’s priorities.

But in 2024, it’s becoming a lot rarer for organizations to run websites, and even web applications, on premises — and particularly after Mirai, pretty much every organization who expects some teenager to want to pick up a fight with them would want to protect themselves through one of the many offers out there. And while there are still cases in which, if you’re putting a full blown dynamic web application behind them, you may not be IPv6 compatible, in the case of a “glossy” company website, having the CDN serve it over IPv6 as well as v4 is not just a click away, but also the default.

You could basically say that CDNs have done more for making more of the Internet available over IPv6 than most of the advocates out there. And even then, looking at Cloudflare’s own statistics, global adoption is barely at 30%, much lower than what both Google and Facebook report!

But just like in the case of Telegram, there’s more to a web application than being available over IPv6 for it to be compatible with it. Which is why what IPv6 In Real Life project is about: while being very amateurish, and limited in scope to what countries and services I’m aware of, I’m taking the view that the readiness for IPv6 needs to be expressed on the ability of people to use an IPv6 only network for their day to day tasks: banking, shopping, dealing with medical services, and buying mass transit tickets.

As it turns out, as a measurement, this is a fairly less comforting statistic. In particular, while basically every bank’s “glossy” site ends up being served by a VPN that actually supports IPv6, their online banking services very rarely support IPv6. And this particular characteristics also ends up poisoning the measurement of “Top XXX” domains — since it’s almost impossible to programmatically identify which additional hosts one would have to inspect, in addition to the “glossy” one, to be able to load the page over pure IPv6.

And this is without me looking into whether the various mobile apps people use and need have any chance of working without IPv4! These are likely using a different set of hosts, so it might very well be that they are even less IPv6 compatible than their websites — I just don’t have hte resources and the time to try and capture all of those in any consistent way.

Speaking of mobile apps, though, things are also interesting there. Apple has been making noise on the IPv6 topic for a while, and indeed back in 2016, they started requiring apps to be able to handle IPv6-only networks! Unfortunately, this also gets slightly confusingly reported as requiring all apps to work only over IPv6, which is not quite correct. Indeed the very same news post suggests you need to correctly support NAT64 gateways — which effectively means you need to make sure you don’t use IPV4-only APIs (which I guess are not even a thing on iOS), and that you should not use hardcoded IP addresses — since NAT64 relies on faking AAAA records for A-only hostnames.

This is obviously a step in the right direction, and it is possible that it pushed at least a few of the app developers to actually supporting IPv6 on their backend properly, but there’s no evidence on the direct correlation between those, so I would also still take it with a grain of salt. At the very least, though, we know that the iCloud Private Relay (which I covered recently) has IPv6 outbound connectivity, which it will gladly use to connect to Google and likely other services too, so it might actually part of the visible adoption of IPv6 after all.

So the short version is that I’m once again showing my doubts about the adoption of IPv6 among consumers, simply because it does not appear to have much if any upside that is worthwhile for your non-geek average consumer. And also wondering why we managed to make so much more steps forward in adoption of other networking technologies, such as HTTPS, DoH, and even Wireguard/Tailscale — while IPv6, despite being touted as a necessity for everyone is still reserved to backend systems, large corporate players, and geeks.