Is IPv6 Doomed?

Today is World IPv6 Day. That’s the day a number of Internet heavyweights are testing out their readiness for the next version of IP, the networking protocol that serves as the foundation for the Internet.

The current version of the IP protocol, called IPv4, suffers from a serious weakness: it gives computers addresses that are only 32 bits long, which means that there are only 232, or around 4 billion, possible addresses. That seemed like a large amount when the Internet was just an academic research network back in the 1970s. But on a planet with 7 billion people, it’s beginning to feel a little cramped. IPv6 uses 128-bit addresses, and 2128 is such an enormous number that the world will never again have to worry about running out of address space.

The IPv6 transition has been widely portrayed as inevitable, with some outlets falsely claiming that it will soon be impossible to add a new device to the Internet without an IPv6 address. But it’s not so obvious that this is true. There’s no doubt that it would be beneficial to move the Internet to IPv6, but the transition faces a massive collective action problem. Indeed, I’m starting to suspect that the collective action problem may be so severe that the transition might not happen at all.

To understand the problem, we have to first get into the technical weeds a bit. Network administrators have long used a technology called Network Address Translation to allow multiple client computers to share a single IP address. This is the technology that allows your WiFi router to share your single cable or DSL connection among all the devices in your house. As the name suggests, NAT works by assigning a “private” IP address to each device inside your network, and then “translating” between the public and private IP address spaces.

Network administrators hate NATs because it breaks one of the Internet’s most elegant features: the ability for any two hosts on the network to connect to one another. But the ability to share IP addresses is so useful that the technology has proliferated. And most applications are now designed to gracefully handle working behind a NAT.

Which bring us to the IPv6 transition. The plan is for hosts to gradually transition from using IPv4 addresses to IPv6 addresses. The challenge, though, is that people on the IPv4 network want to be able to talk to people on the IPv6 network, and vice-versa. Getting from IPv6 to IPv4 is no problem; the IPv6 spec allocates a block of IPv6 addresses (of which there’s no shortage) to correspond to IPv4 addresses. But going the other way is hard, because the IPv4 protocol has no way of addressing more than 232 distinct addresses.

There is a mind-boggling array of methods for dealing with this problem, and I couldn’t explain them all to you if I wanted to. But conceptually, there are two options. One is to use what amounts to a huge NAT to translate between IPv6 and IPv4. Every IPv6 host is given a corresponding IPv4 address (which it might share with many others). The IPv4 host communicates with this address, and there’s a gateway that automatically translates these packets between the IPv4 and IPv6 protocols. Under this approach, the IPv4 host can be blissfully unaware it’s talking to an IPv6 host, because all it knows about is the IPv4 address of the gateway.

The other approach is to have hosts be “dual stacked,” meaning that they’re simultaneously maintaining two different (possibly virtual) network connections with two different addresses. Dual-stacked hosts send IPv6 packets to other hosts on the new network, but fall back to IPv4 to communicate with hosts that are only on that network.

Now, the key thing to realize about these methods is that under either approach, IPv4 hosts have zero incentive to switch to IPv6. There are enough IPv4-only hosts around that every IPv6 host will want to find a way to continue communicating on the IPv4 network. And that’s another way of saying that an IPv4 network that ignores the transition won’t face any negative consequences for doing so for a long time. Moreover, under either scheme, every IPv6 host still needs to have an IPv4 address, so switching to IPv6 doesn’t even do much to economize on scarce IPv4 addresses. True, under the NAT-based approach, multiple IPv6 hosts share a single IPv4 address. But most of those address savings can be achieved simply by adopting a regular old IPv4 NAT. If anything, adopting IPv6 just makes things unnecessarily complicated.

To put things another way, no IPv4 host will begin to experience negative consequences from dragging its feet until IPv6 hosts start dropping IPv4 support. And this will happen only after the vast majority of IPv4 hosts have migrated. Given that running two parallel networks is more expensive than running an IPv4 network only, the rational thing to do is to wait for other people to go first.

No one wants to say this because it really is in everyone’s interest for the transition to occur. But it’s not hard to read between the lines. Here, for example, a commentator says “You have to make the transition. It is better to do that sooner than later because it demonstrates that you are a modern, well organised company that is visible on the modern infrastructure of the internet.” This is complete nonsense. The overwhelming majority of users have no idea what IPv6 is and won’t even notice when a company they do business with makes the switch.

So we may be in for a decade-long period wherein everyone talks about the IPv6 transition but only a handful of large companies actually do anything about it. If I’m right, then one of two things will happen. One possibility is that networking elites will eventually realize that the gradual approach is hopeless and lobby for the stiffer medicine of a legislative mandate. The other possibility is that we’ll discover that IPv4 isn’t as bad as we thought, and learn to live with four billion addresses indefinitely. In my next post I’ll examine how we might do that.

More and more NAT may be cheaper than DS-Lite, but I suspect that it won’t be. NATing 100s of Gbps of traffic isn’t going to be cheap. Given that some major content providers are already dual-stack, broadband ISPs can reduce their NAT costs by adopting IPv6 and DS-Lite. You are definitely right that the incentive is to wait until IPv4 is completely exhausted before doing anything.

One (unmentioned) way to overcome these sorts of problems is through regulation. Rules requiring end user ISPs to transition to IPv6 by a certain date, and to drop IPv4 support by a certain later date – even just in the United States – would go very far to stimulate the transition. I’m not necessarily advocating such an approach, though I think the end-user ISPs are among the entities most inclined to switch anyway (as they may bear the greatest brunt of NAT costs and any secondary market costs to acquire additional blocks of IPv4 addresses) so the political pushback may not be as severe as with some regulatory approaches.

So we may be in for a decade-long period wherein everyone talks about the IPv6 transition but only a handful of large companies actually do anything about it.

You mean the previous decade where we’ve done just that doesn’t count?

Julian Simon comes to mind here when it comes to scarcity of resources. I suspect we have not yet exhausted the ways that humans will creatively figure out how to extend IPv4 rather than the very expensive transition to v6.

“I suspect we have not yet exhausted the ways that humans will creatively figure out how to extend IPv4 rather than the very expensive transition to v6.”

The costs are primarily in managing parallel configurations, but a lot of that can be automated. The costs for building IPv6 capability into hardware and software at the network and host level are already sunk. (My home network has been dual stack since 2005, apart from a few devices–TiVo, Wii, and Squeezebox.) I’m pretty sure there will come a time when IPv4 costs exceed IPv6 costs, especially for new entrants into the ISP and webhosting business.

Mark Newton of Internode gave a talk at AusCERT 2011 in May about how they made the transition to dual stack in just a few months, and in which he also points out some of the difficulties and pitfalls of transition–as well as those for not transitioning or transitioning later. He also spends some time talking about the security issues, which I’ve summarized at the blog post linked to my name on this comment.