The case for IPv4.1

In 2003, Dan Bernstein wrote about the IPv6 mess, focusing primarily on the lack of viable migration plan. Avery Pennarun wrote again about the problem in 2011, also with a focus on the lack of viable migration plan. Now it's been another decade, for a total of around 30 years on this project.

With the benefit of 20/20 hindsight, we now know that the IPv6 plan was never a very good one. If IPv6 had been accurately estimated to take 30+ years of migration, it would not have achieved the buy-in that it did, and most likely the designers would have kept going. The individuals involved are all top of class from what I can tell, but sometimes good people produce bad results, especially in a group context. I'm reminded, in all of this, about the Ada programming language, with the unusual way it was designed. I'm even more reminded of a certain saying about committees: "none of us is dumb as all of us".

Big migrations do not always go this way. The World Wide Web only needed nine years, if we count from Tim Berners-Lee's memo to the launch of the Google search engine. Under the right conditions, the whole Internet can upgrade in less than ten years.

The difference in these projects is easy to understand. Avery describes it as follows:

In short, any IPv6 transition plan involves everyone having an IPv4 address, right up until everyone has an IPv6 address, at which point we can start dropping IPv4, which means IPv6 will start being useful. This is a classic chicken-and-egg problem, and it's unsolvable by brute force; it needs some kind of non-obvious insight. djb apparently hadn't seen any such insight by 2002, and I haven't seen much new since then.

Here in 2024, it's not really too late to start on a backup plan. It's anyone's guess whether a more modest IPv4.1 proposal would finish faster than IPv6, but we can all be sure of one thing. Our chances are better if we have two dogs in the race.

How to do it

Here's the general idea of IPv4.1, just to show what I mean. It's been posted about before, so consider this to be my explanation rather than anything fundamentally new.

The core change for IPv4.1 is that the IP packet header needs room for a larger address. The packet format can be the one from the SIPP proposal, but with version "7" instead of "6", since 6 is now taken. When an address is written down, for example in a router's configuration UI, these 8-byte addresses can be written down the same way we are used to, just with 8 digits instead of 4. Existing addresses can be zero-padded on the left, e.g. 0.0.0.0.127.0.0.1.

Whenever two machines talk to each other, they use the existing IPv4 packet format if they both have 4-byte addresses. If either of them has an 8-byte address, then they switch to the IPv4.1 format. In this case, though, the packets still mean the same thing they always did! Part of the key to achieving a large migration is not to saddle it with additional ones.

8-byte addresses should be sufficient for this problem. The reason that IPv6 addresses use 16 bytes is that IPv6 plans for the machines on people's private internal networks to avoid reusing an address from anyone else's private network. This property will not be pursued for IPv4.1, and it would not do anything useful it were, because per the previous paragraph, all the packets in IPv4.1 are supposed to mean the same thing they did in IPv4.

Rollout

During the initial rollout of IPv4.1, many machines will not yet be able to talk to each other with the extended addresses. This will be much like the case with IPv6 right now.

From there, it will be a race. It's speculation which race will go faster, but IPv4.1 has some big advantages. It doesn't take any configuration file changes, and it doesn't require designing IP blocks. It definitely doesn't require thinking about link-local addresses, updates to how DHCP works, or any other fundamental aspects of networking. All that it takes for IPv4.1 to win is for software providers to add it into their latest version, and for the major nodes on the Internet to upgrade their software some time over the next 5-10 years. Major Internet nodes usually have to upgrade their software once in a while, already, due to security and compliance requirements.

We don't have to know for sure that IPv4.1 will win the race before we can make a decision about trying. We can simply observe that the problem is important, and we can observe that our chances are better with two ways to win.