Biz & IT —

There is no Plan B: why the IPv4-to-IPv6 transition will be ugly

The Internet is running out of IPv4 addresses—not at some point in the future …

A brief history of Internet protocol transitions

In the early 1990s, it became obvious that the 32-bit addresses in the existing Internet Protocol were too small to allow for continued growth of the Internet beyond the first years of the 21st century. 4.3 billion possible different addresses (with 3.7 billion that are actually usable) only gets you so far in a world with 6, 7, or even 10 billion people. So the IETF leadership decided adopt the OSI/ITU-T CLNP protocol to replace IP. What now? Yes, really: the Connectionless Network Protocol. CLNP is basically IP from a parallel universe where everything has a different name, such as Network Service Access Point (NSAP) for address. NSAPs are variable length with a maximum of 160 bits, which would be a nice increase over the existing 32-bit IP addresses. And due to earlier, mostly unsuccessful, government mandates, major vendors had already implemented CLNP.

But the IETF constituency, suffering from a bad case of not-invented-here syndrome, wouldn't have it. So around 1995, the IP Next Generation effort resulted in a new version of the IP protocol to fix the address length limitation. The IETF took advantage of this opportunity to fix some other limitations of the existing IP version 4—nobody knows what happened to versions 1, 2, and 3—but they exercised restraint: complaints about the new protocol are evenly balanced between "they changed too much" and "they didn't fix enough." As a result, the way in which IPv6—don't ask what happened to version 5—interacts with Ethernet or other lower layers is rather different from IPv4, DHCP is significantly overhauled, and there's stateless autoconfiguration to configure the now 128-bit addresses. But other than that, IPv6 is still IP, so it would be fairly straightforward to transition from IPv4 to IPv6.

All of this has happened before

Interestingly, the Internet already lived through a transition from one protocol to another. In the 1970s, the ARPANET used NCP, the Network Control Program. NCP was full of quaint notions, such as the ability to contact a remote router and inquire whether an earlier message was received at the other end or not. (A bit like sending a letter to the mail carrier asking whether a letter you sent to a friend earlier was delivered or not.) Such complexities are hard to square with a lean, mean, and especially fast network, so a shiny new protocol was developed around 1980: IP/TCP. (Today, we call it TCP/IP, or IPv4, or just IP, as the TCP part is now implied.)

RFC 801 describes the transition from NCP to TCP/IP. Basically, the two protocols coexisted during 1982, and as of January 1, 1983, NCP went the way of the dodo, with only TCP/IP left. All told, they needed a year to transition a network with about a hundred nodes and three main applications: telnet, FTP, and mail. So it can hardly be a surprise that doing the same (transitioning from the soon-to-be-obsolete IPv4 to the new IPv6) less than two decades later for a network with hundreds of millions of nodes, and hundreds, if not thousands, of application types, would take a good long time.

The only saving grace is that the IETF started its IP next generation (IPng) effort, which eventually produced IPv6, very early, giving us nearly 20 years between the moment that IPv6 was first standardized in 1995 and the moment that the IPv4 addresses run out, probably 2012. The bad news is that those 20 years are almost up.

Ships in the night: the IPv6 solution

When IPv6 was developed in the middle of the 1990s, things we take for granted today didn't exist, or weren't widely used.

While IPv4 and IPv6 are very much alike to users and applications; "on the wire," the protocols are completely separate and don't interact. In routing, we call this the "ships in the night" approach. (Hopefully, at least one of them has radar.) The advantage of this design is that there is no need to change existing IPv4 infrastructure—IPv6 is simply added as a new protocol. All the limitations and mistakes that are part of IPv4 are left behind.

The problem with this approach is that the first person who wants to turn off IPv4 has to wait for the last person to add IPv6. It's like having a cell phone network that is not connected to the landline network. Everyone has to have both types of phones, with the expectation that in the far future, we can turn off the landlines and just use cell phones. And with cell phones, there is actually an advantage to switching: no cord. (Although landlines have some advantages, too.) With IPv6, there are no real advantages to switching for most users, who tend to be unimpressed by technological elegance and future-proofness.

All of this makes the transition to IPv6 like the trackstand strategy in match sprint track cycling, where competitors try to get their opponents to take the lead by not moving themselves. Once the opponent is in the lead, the "winner" of the trackstand can take advantage of the opponent's slipstream and keep up with reduced effort. After a decade of trackstanding, the migration towards IPv6 is finally starting to get underway, but unfortunately the progress comes way too late to avoid problems when the IPv4 addresses run out. But we'll come back to that. First, let's have a look at some of the differences between IPv4 and IPv6 that get in the way of an easy transition.

You mean to say that IPv6 is actually different from IPv4???

When IPv6 was developed in the middle of the 1990s, things we take for granted today didn't exist, or weren't widely used. For instance, today pretty much every system that isn't a router or a dedicated server gets its IP address and a bunch of other information through DHCP, the Dynamic Host Configuration Protocol. DHCP is remarkably complex and error-prone, compared to the way other protocols from the 1980s, such as IPX and AppleTalk, solve this problem.

With DHCP, the client first broadcasts a request. Hopefully, one or more servers see the request for an address and send an IP address offer. The client then evaluates the offers and takes one server up on its offer. The server must now remember to not give out the same address to another system until after the lease runs out, and the client must remember to renew the address lease with the server before the lease expires.

With IPX, this process is much simpler, and there's no dependence on server-stored information or timers. Routers broadcast a "network address," and each system creates its own individual address by combining the broadcasted network address and the MAC address burned into its Ethernet chip. AppleTalk is very similar, but the addresses are much shorter, so AppleTalk uses a random number rather than a MAC address. It also sends a few packets to determine if some other system already has the chosen address. Easy as pie.

When IPv6 was created, the IETF looked at protocols like IPX and AppleTalk and created stateless autoconfig, which is basically the IPX approach. Later, privacy concerns came up over embedding a machine's MAC address in its IPv6 address, so an AppleTalk-like option was added: hold the MAC address, substitute it for a random number, rinse and repeat every 24 hours to keep the government and other snoops on their toes. But why limit ourselves to two mechanisms for configuring IPv6 addresses (three if you count manual configuration)?

DHCP was then re-imagined as DCHPv6. Although the two DHCPs share the same concepts and architecture, their message formats and many operational details are completely different: DHCP is so intimately interwoven with IPv4 that simply making the address fields larger to support IPv6 was pretty much impossible. Also, routers already broadcast (well, multicast, which is more efficient) their existence for the purpose of stateless autoconfiguration, so two critical pieces of information can be learned only from those router advertisements; they are not present in DHCPv6. These two pieces of information are the default gateway/router address, and how many bits are part of the network prefix (the equivalent of the IPv4 subnet mask).

There is a third bit of crucial information that's needed before a host can enjoy network connectivity: the addresses of the local DNS servers. (Remembering those 128-bit IPv6 addresses is such a pain...) This is, of course, something that DHCPv6 can easily provide. There also a specification, recently upgraded to "standards track" status by the IETF, for putting DNS addresses in router advertisements. But today, routers don't yet do this.

The end result is a bit of a mess: all IPv6 systems support stateless autoconfig; Windows Vista and 7 support DHCPv6, but Windows XP and Mac OS X don't; on open source OSes a DHCPv6 client can usually be installed if one doesn't come with the distribution; and Vista and 7 also use the temporary, random number-derived addresses by default, whereas other OSes don't.

The trouble ahead

Ten years ago, this difference between IPv4 and IPv6 may have been met with a can-do attitude or perhaps resignation, but the peculiarities of IPv4 are now ingrained.

Right around this point in the story, many system administrators start becoming very uncomfortable about the transition to IPv6: they can't just set up a big DHCPv6 server that logs all address assignments and call it a day. On networks that need to support anything other than a Windows Vista/7 monoculture, it's infeasible to turn off stateless autoconfig, because then some systems simply wouldn't get an IPv6 address. Worse, the information that stateless autoconfig is not in use must be multicast by routers. Just one rogue router that says otherwise can make all hosts create those unpredictable temporary addresses, and may even siphon off traffic and do all kinds of horrific things to it.

Of course a rogue router sending out unwanted router advertisements isn't any different from a rogue router sending out IPv4 DHCP information, except that enterprise switches know how to deal with the latter, whereas they don't yet know what to do with the former. However, even if the fixes that are currently in the pipeline materialize, some sysadmins argue that the need to coordinate the information in DHCPv6 and that in router advertisements is too onerous, as router people and server people shouldn't be required to talk to each other.

Ten years ago, this difference between IPv4 and IPv6 may have been met with a can-do attitude or perhaps resignation, but the peculiarities of IPv4 are now so ingrained and the memories remain of the multi-protocol world that existed during the last decades of the previous century, that the lack of identicalness between IPv4 and IPv6 could be a real stumbling block today.

Iljitsch van Beijnum
Iljitsch is a contributing writer at Ars Technica, where he contributes articles about network protocols as well as Apple topics. He is currently finishing his Ph.D work at the telematics department at Universidad Carlos III de Madrid (UC3M) in Spain. Emaililjitsch.vanbeijnum@arstechnica.com//Twitter@iljitsch