Commentary on IPv6 slowdowns: Is this still good Internet?

Geoff Huston, thought leader at APNIC (Asia-Pacific Network Information Center), caused a stir at a conference in October 2024 with an opinion piece on the introduction of IPv6. Huston said that this was no longer so important because "CDNs and mobile traffic mean that address scarcity is no longer a major problem". Can this be true? Has all the work done in recent years on IPv6 and its introduction to the global network been in vain?

An opinion by Gert Döring

Gert Döring has been working with IPv6 since 1997. He builds technology for SpaceNet AG in Munich and works within the framework of various committees such as RIPE on sensible rules for IP management in Europe

The answer is a clear "it depends". First of all, it should be noted that Huston is not simply making unproven assertions, but deriving them from measurements on the Internet. However, every measurement must be accompanied by the question: What am I actually measuring here? Geoff only measures one part of the truth: the Internet from the perspective of the web browser. His measurement methodology is based on the delivery of large quantities of Google ads and the evaluation of the observed DNS and HTTP requests.

If you only use the web as the basis of your argument through a magnifying glass in this way, Huston is right about IPv6. It already works more or less: with carrier-grade NAT (Network Address Translation) and with IPv4 addresses that are shared by 8, 16, 32 customers of the same provider. In particular, IPv6 is of no use at the provider end if important content providers such as Github or Der Spiegel are still not accessible via IPv6 in 2024.

Is this still a good network?

But is it a "good internet"? Google issued the slogan "Google must not be slow" 20 years ago and started its IPv6 rollout – because it was already clear back then that an "IPv4 only" Internet with multiple NAT levels was not desirable. Every NAT device along the way creates delays and limits the number of parallel connections that are possible. If the NAT device is at its limit, elements of a website – are suddenly missing and the user is dissatisfied with the content provider. How well a carrier-grade NAT scales with the provider depends primarily on how many coins the provider wants to give its suppliers – and the sums involved are considerable.

IPv6 has the clear advantage here that the technology is much simpler on the provider side – this enables better performance with lower costs. The undeniable difficulty, however, is that these costs are distributed unevenly. If a content provider such as the Github mentioned above has other priorities than activating IPv6 for its offering, the providers must bear the costs: for more IPv4 addresses, NAT boxes and so on. After all, if the providers did not ensure that access to "IPv4 only" offerings was also possible, they would be the first address for the displeasure of their customers, not the IPv6 grouches on the part of the content providers. This means that the necessary pressure to act is lacking in many places and, in case of doubt, there is always some other project that is "more important for now".

But what does this mean when Geoff, based on his data, "questions the goal of completely replacing IPv4 with IPv6"? What nobody actually wants is to operate "dual-stacking", i.e. IPv4 and IPv6 permanently in parallel. This is unavoidable in many places during the (now decades-long) transition phase. After all, you have to be able to communicate with remote stations that only understand one of the two Internet protocols. But you don't really want to like it, because dual stack also means double work – double address assignment, monitoring (which is often forgotten), troubleshooting. And, of course, higher costs.

Back to square one or go for it?

So the question remains as to which approach promises more success: going back to IPv4-only or switching off IPv4 and only communicating via IPv6. T-Mobile USA and Meta already gave a possible answer to this question years ago (and practiced it successfully): in both companies' internal networks there is "IPv6 only", no more IPv4 because it is far too expensive. Only at the transition to the public Internet is there dual stacking, but this is implemented differently. T-Mobile uses NAT64 to reach the destinations of the old IP world, at Meta the load balancers in front of the servers speak IPv4 and IPv6, but only communicate "internally" via IPv6. Moving away from IPv6 is not an issue for either company.

This approach is possible in many enterprise networks that are currently struggling with the constantly rising costs of IPv4. They can gradually convert the internal network to IPv6-only and only use IPv4 at the external borders. There it makes sense to dual-stack for as long as necessary. Unfortunately, this will be the case for many years to come, as the number of procrastinators and hesitants is high: nobody can currently afford to switch off IPv4 completely.

So back to Geoff Hudson's contribution to the discussion. Although his measurements are good and important, I can't agree with his conclusion "Meh, it's no use anyway, so you might as well not do it". A half-finished changeover causes higher costs for everyone, a rollback to "IPv4 only" is not possible, so the answer is clear: we should stay the course.

(cku)