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 …

Twenty years ago, the fastest Internet backbone links were 1.5Mbps. Today we argue whether that's a fast enough minimum to connect home users. In 1993, 1.3 million machines were connected to the Internet. By this past summer, that number had risen to 769 million and this only counts systems that have DNS names. The notion of a computer that is not connected to the Internet is patently absurd these days.

But all of this rapid progress is going to slow in the next few years. The Internet will soon be sailing in very rough seas, as it's about to run out of addresses, needing to be gutted and reconfigured for continued growth in the second half of the 2010s and beyond. Originally, the idea was that this upgrade would happen quietly in the background, but over the past few years, it has become clear that the change from the current Internet Protocol version 4, which is quickly running out of addresses, to the new version 6 will be quite a messy affair.

Legacy problems

Across the computing industry, we spend enormous amounts of money and effort on keeping older, "legacy" systems running. The examples range from huge and costly to small and merely annoying: planes circle around in holding patterns burning precious fuel because air traffic control can't keep up on systems that are less powerful than a smartphone; WiFi networks don't reach their top speeds because an original 802.11(no letter), 2Mbps system could show up—you never know. So when engineers dream, we dream of leaving all of yesterday's technology behind and starting from scratch. But such clean breaks are rarely possible.

For instance, the original 10 megabit Ethernet specification allows for 1500-byte packets. Filling up 10Mbps takes about 830 of those 1500-byte packets. Then Fast Ethernet came along, which was 100Mbps, but the packet size remained the same so that 100Mbps ethernet gear could be hooked up to 10Mbps ethernet equipment without compatibility issues. Fast Ethernet needs 8300 packets per second to fill up the pipe. Gigabit Ethernet needs 83,000 and 10 Gigabit Ethernet needs almost a million packets per second (well, 830,000).

For each faster Ethernet standard, the switch vendors need to pull out even more stops to process an increasingly outrageous numbers of packets per second, running the CAMs that store the forwarding tables at insane speeds that demand huge amounts of power. The need to connect antique NE2000 cards meant sticking to 1500 bytes for Fast Ethernet, and then the need to talk to those rusty Fast Ethernet cards meant sticking to 1500 bytes for Gigabit Ethernet, and so on. At each point, the next step makes sense, but the entire journey ends up looking irrational.

The problem in the middle

Of course, change does manage to happen. We went from 10Mbps to 10Gbps Ethernet, from wired to wireless, and from a Web that was barely able to show blinking text to one running all manners of applications. We even gained the DNS and TCP congestion control only in the late 1980s. But the reason we were able to change all of these technologies is that they happen either above or below the Internet Protocol in the network stack.

Network protocols are built as "stacks" where a number of layers each provide a part of the required functionality. The famous OSI reference model has seven layers, but the TCP/IP stack has only four. Starting from the bottom and moving up, the (data)link layer knows how to send packets through cables or the air; the network layer knows about routing and addressing, allowing packets to find their way through the network; and the transport layer makes multi-packet communications work, and finally the application layer makes applications work over the network. These layers map to OSI layers 2, 3, 4, and 7, respectively. Each of these layers has many different protocols to choose from, except the network layer, which has only IP. Hence it looks like the waist in an hourglass.

The TCP/IP stack and OSI reference model

Ethernet operates at the datalink layer (and also on OSI layer 1, the physical layer), and supports complex networks of its own, but Ethernet networks are nonetheless limited in size and scope, and can be upgraded with relative ease. The transport layer, where TCP and UDP live, has some upgradability issues, but in principle, routers don't look beyond the network layer, so they don't care if a packet is TCP, UDP or some other *P. This means that changing to a new transport protocol just involves updating the end systems that send and receive the packets—the routers in the middle don't care. (Firewalls do care, hence the complications in practice.) The same is true for application protocols like HTTP, FTP, or SMTP. If your browser decides to start downloading webpages using FTP, that's between the browser and the remote server; the rest of the network doesn't care.

But in contrast to the other layers of the stack, IP is everywhere. The source of the packet needs to create a valid IP packet, which all the routers along the way must process in order to send the packet down the right path. And the destination must be able to decode the IP packet. So changing the Internet Protocol means changing all hosts and all routers.

202 Reader Comments

So Mac OSX doesn't support IPv6? I believe you since you obviously know more about this than I do... but would you explain why I have an IPv6 setting and legitimate address (2002:47c6:94e5::21f:d0ff:fed4:nnnn) in my OSX network settings then? I even bought a firewall router that supports IPv6.

None of that is good for anything? :-( Bummer. I thought I was ahead of the curve.

tvalleau, Mac OS X does support IPv6. Actually, this article specifically says that there is a long standing bug in the implementation of IPv6 in its DNS code, which implies that the IPv6 implementation exists in the first place. ;-)

Great article, although I have a strange sense of deja vu - the core issues with the ipv6 transition have been written about a lot over the past decade. It would be interesting to know more about where exactly major ISPs and important companies are with preparing to use/support ipv6. I am a hobbyist developer who runs a couple servers from my basement, and I'm dreading having to re-learn everything I know about networking. I confess to being one of the people who plans to avoid dealing with ipv6 as long as possible. Networking was once defined as "when you can't get any work done because of the failure of a machine you've never heard of" and until ignoring ipv6 starts causing me problems, I will continue to guiltily use ipv4 only.

Wow that was a good read. It stinks that a bunch of open source network tools I use are not going to have ipv6 support. Its a bigger deal then I realized. Even the developers of these specific tools admit that adding full ipv6 support now would break to much stuff and "nobody uses IPv6 anyway". LoL

Interesting article. What I, as a home-network-maintaining hobbyist would really like to know, is how on earth I'm gonna ping, tracert over the network. Do I have to remember the (what is it?) 16 hex characters of all my devices?

In my opinion, the fact that we _still_ have the Internet is a miracle, given its lack of the owner and the multitude of aggressively competing, stubbornly conservative hardware/service vendors. IETF has no power to actually force anything (pun intended), and without sufficient pressure no vendors will really care. If the US Congress and EU order everybody to use IPv6 (or IPX, or AppleTalk, for that matter), we all will be happily using it in a year.

I find it amusing that the two biggest problems we've found with deciding that 32-bit numbers are big enough have happened within the span of a few years. First the 4GB RAM limit, and now the internet is breaking!

Also, what was wrong with a 64 bit address o_O?

For that matter, why not just extend to a scheme that goes something like ***.63.34.53.82, where the first triple digit is used in my theoretical IPv41 (because apparently logical naming schemes are out of style), and any IPv41 hardware that gets an address that begins in 000 just passes on the rest of it as if it was IPv4.

It seems like we picked the exact wrong thing to decide to start over :/

For that matter, why not just extend to a scheme that goes something like ***.63.34.53.82, where the first triple digit is used in my theoretical IPv41 (because apparently logical naming schemes are out of style), and any IPv41 hardware that gets an address that begins in 000 just passes on the rest of it as if it was IPv4.

There's no room to add an extra two bytes (one for source, one for destination). And even if there was, adding one byte just multiplies address space by 256. Given the exponential growth of the internet, it would be an awful lot of work and a really hacky protocol change just to get another 10 years or so. And, of course, no traditional IPv4 devices would support it anyway, so you'd have the same migration problems as IPv6.

I remember back before there was IPv6, there was Tcp Upd over Big Addresses or TUBA, and Cisco actually had it running in their routers.

I don't know much about it except that there was a big battle and lots of not-invented-here anger, as mentioned in the article, and the end result was a monstrosity of a compromise that no one really wanted but didn't have anyone actively hating it as much as the alternatives. So they held their noses and voted in IPv6.

Thanks a lot guys.

I wonder if the solution is to just admit we blew it and restart with better goals: something with more addresses but much simpler to upgrade, so, you know, people will actually use it.

For that matter, why not just extend to a scheme that goes something like ***.63.34.53.82, where the first triple digit is used in my theoretical IPv41 (because apparently logical naming schemes are out of style), and any IPv41 hardware that gets an address that begins in 000 just passes on the rest of it as if it was IPv4.

They wanted to tinker with the IP header (and obviate the need for DHCP etc as the article goes into). If they just wanted to expand the addressing then yes, that would have been fine - an "IPv41" router would recognise the signature in the IPv4 host (or source or both) address and then read in x number of additional bytes worth of additional addressing as an "IPv41" header. An IPv4 router would drop the packet because the address is invalid.

Has anyone yet thought of creating a user-generated database all all the hardware and software out there with instant search and explanations of what hardware supports IPv6 out of the box and what softwares need to be patched and how?

It seems like this could be an immense time-saver tool as sysadmins all across the world need an easy way to sort through their "network inventory" to determine what work needs to be done and what hardware needs to be replaced.

In 20,000 years when we've colonised the multiverse with countless zillions of people, warpspace network engineers will look back and curse IPv6 designers for being so short-sighted with their measley 128-bit addresses.

I don't understand why the author says that the P2P works worse over IPv6 because of the lack of NAT... it works better. No firewall on router, real IP addresses. You just need a v6 tracker and v6 peers and off you go

This was an interesting article. So far, in looking in to IPv6, I hadn't seen much discussion of most of the troubles discussed here.

I didn't understand the point made in the section on firewall issues:

Quote:

All of this means that peer-to-peer protocols such as VoIP solutions and BitTorrent work worse over IPv6 than over IPv4. This situation probably won't be resolved any time soon, as people with "security" in their job title refuse to consider passing through unsolicited, incoming packets in any way, shape, or form.

Given that VoIP is mission-critical -- IP phones are extremely common -- I have a hard time believing that sysadmins will simply refuse to allow VoIP.

IPv6 gives me a headache. I wonder if we will be around to see when IPv6 for some insane reason needs to be replaced because every little device in the world needs its own IP. Imagine that world where your toothbrush needs an IP, and us geezers will lament the day we could just brush our dentures without one.

I think you skipped over the security issues with IPv6. It has taken a long time to get IPv4 implementations on both desktops, servers and network infrastructure that generally don't crash or have serious remotely compromisable bugs. IPv6 is considerably more complex and has new features which will inevitably have security bugs, this is a big hurdle to adoption IMHO.

IPv6 gives me a headache. I wonder if we will be around to see when IPv6 for some insane reason needs to be replaced because every little device in the world needs its own IP. Imagine that world where your toothbrush needs an IP, and us geezers will lament the day we could just brush our dentures without one.

IPv4 is an address space of 2^32; IPv6 is an address space of 2^128. That means that if you took the Internet, gave every IP address it's own copy of the Internet, then gave every IP address within that mega-Internet it's own Internet... you could give one uber-Internet to every living person on Earth with space to spare.

"All of this means that peer-to-peer protocols such as VoIP solutions and BitTorrent work worse over IPv6 than over IPv4"

Absolute bullshit. Instead of port forwarding to ONE HOST, you can have a direct connection to any host behind the router, and for security, the router's firewall allows you to get port allowance for one, or many, or all hosts, whatever you choose. Exactly the same as for IPv4 without NAT.

IPv6 NAT and "So it would still be possible to obfuscate an internal network that uses private addresses"...

This is absolutely ridiculous as there is no such thing as a private IPv6 address. The very idea of an IPv6 NAT is totally insane and only comes to mind of people who can't get that NAT is but a hack and are too lazy not to use what they know and has been created out of necessity (masquerading), but to actually use IP (whether v4 or v6) in the simplest ways, as it was designed, that is using routers as what they do best: routing, i.e. forwarding (or refusing to forward) packets between networks. KISS.

That kind of half-informed article is exactly what hampers the adoption of IPv6. There is absolutely zero downside of IPv6. It's either different or better, and the smart people at IETF took great care of that.

IETF & v6 people came up with plans A, B ,C and D, hoping for people to use them during the last years. Those to blame are IT netadmins & companies that sat on their butts for 20 years, and are still waiting on some kludge to come up (like double NAT, or full proxying of an internal v4 network out to a v6) instead of previously using the perfectly sound solutions that already exist but are made useless by the worlds reluctance to move on because "hey, it works right now".

While there was a certain amount of arrogance and hand-waving at the IETF (it's the right thing to do so everyone will just do it, right?), most of the blame belongs to apathy in ISPs, OS vendors and corporations.

Planning for IPv6 migration has always been an ultra-low priority, just like many other things that are procrastinated on until a crisis occurs (global warming, anyone?). Back in 1998 when I was architect at a major European ISP that shall not be named, I tried to ensure IPv6 capability was required in all our equipment RFPs, but was roundly ignored, even though RIPE was refusing to assign them new IPv4 addresses at the time because they had too many and could not account for their efficient usage (every single desktop at the 150,000+ employee company had a globally unique IP, and each site, no matter how small, had a full /8 subnet because of limitations in their routers)..

It would probably have helped if the IANA and RIRs that actually dole out IPv4 addresses were more economics-literate. It is a real scandal that HP or Stanford have as many IPv4 addresses as all of China. ARIN should have started charging rent on IPv4 addresses to give squatters an incentive to release them. They should also have made assignment of new IPv4 addresses beyond a certain volume contingent on IPv6 deployment a long time ago, 2004 at least.

For instance, Mac OS X 10.6 Snow Leopard has a serious bug in its DNS code that makes it ignore IPv6 in the DNS when there is a CNAME record involved, a case which is not uncommon. One year and four point updates later, the bug is still there.

I can't wait to see The Day IPv4 Adresses Ran Out. Maybe the EU will start mandating IPv6 usage before it happens though; one never knows what might come out of this technocratic body.

I studied IPv6 a few years ago and from what I found, most of OS and routers manufacturers have already implemented IPv6 in their products, so I ended up concluding that the ball was in the ISP camp. It seems I overlooked a bit the quality side of these implementations and the utter lack of maturity they will have once we start using them however. It will be soon a great time for Network Admins.

IPv6 NAT and "So it would still be possible to obfuscate an internal network that uses private addresses"...

This is absolutely ridiculous as there is no such thing as a private IPv6 address.

There are private IPv6 adresses -- they are called site-local addresses and serve exactly the same purpose as RFC 1918 private addresses..

Quote:

The very idea of an IPv6 NAT is totally insane and only comes to mind of people who can't get that NAT is but a hack and are too lazy not to use what they know and has been created out of necessity (masquerading), but to actually use IP (whether v4 or v6) in the simplest ways, as it was designed, that is using routers as what they do best: routing, i.e. forwarding (or refusing to forward) packets between networks. KISS.

I agree with the notion, that NAT is evil, but on the other hand, 1:1 NAT is much less evil than the many -to-one NAT.

Two years ago, the United States just completed a transition from Analog TV broadcasts to Digital TV broadcasts. There was a lot of kicking and screaming about that transition, and the digital transition was pushed back from February to June. And, that was for an entertainment device.

Now, we are talking about transition from IPv4 to IPv6. This makes the digital TV transition look like child's play. We got people who have legacy systems with legacy browsers (Internet Exploder 6 anyone?) combined with companies who are loathe to spend money on IT upgrades.

*Shrug* Perhaps I will be making a ton of money configuring computers for IPv6 in the near future.

Good article.I don't currently see a viable solution for an IPv6 adoption. ISPs, network OEMs, users and apps will have to suddenly start to use it in it's best form. Ain't gonna happen. Plus, even a limited implementation would be hacker's delight since there are so many thing exploitable and punishable in IPv6 and the rest of the pack that comes with it.The mistake was the incompatibility with IPv4. Compatibility would of been plan B.

HTTP pipelining involves a bit more than what I mentioned: it doesn't just keep the TCP session open, but with pipelining new requests are also sent before the server is done sending the data for previous ones.

Mac OS X has supported IPv6 since at least 10.2 Jaguar, it's just that with 10.6 under some circumstances AAAA records in the DNS are ignored. The result is that YouTube or Google aren't reachable over IPv6 on a Snow Leopard system even if your DNS server is whitelisted by Google. My bugreport about this is still open.

Hex numpads: this brings me back to my misspent youth where I copied pages upon pages of hex code from Commodore 64 magazines. I reprogrammed the numeric keypad on my C128 to work as a hex numpad to make it easier. And then I hired my sister to do it. :-)

Peer-to-peer: yes, with straight, unfiltered IPv6 it works better. But if your home router comes with an IPv6 firewall and IPv4 NAT, the P2P applications have an easier time getting through the IPv4 NAT than the IPv6 firewall. But at least a firewall is something you can turn off and work is underway to create a protocol that will automatically poke holes in the firewall to make stuff like VoIP work while keeping the firewall enabled and without manual configuration on the user's part.

IPv6 has private addresses in the form of "site local" addresses, which are now "deprecated" by the IETF and in the form of "unique site local" addresses (ULAs) where everyone can autogenerate their own block of private address space, allowing for the easy interconnection of private networks.

I find it amusing that the two biggest problems we've found with deciding that 32-bit numbers are big enough have happened within the span of a few years. First the 4GB RAM limit, and now the internet is breaking!

Actually, there is another: 32-bit LBAs in the MBR, limiting disks to 2TB. This will probably be ugly as well, as the BIOS doesn't seem to be going anywhere, and Microsoft refuses to support GPT boot on a BIOS system. (Though, it isn't a problem for secondary disks, or OSs which can boot GPT partitions on a BIOS system...)

I've looked into IPv6 several times in the past years, wondering how I'm going to handle the transition for my organization. The problems I've encountered are numerous:

- Network equipment doesn't work right with IPv6. In particular most (if not all) our security systems morfe or less assume IPv4 even if some of them "kinda support" IPv6. Just to give an example everyone knows about: DNSBL are simply NOT working on IPv6 and our SMTP gateways reject 85% of the connections based on that alone.- Many IP-enabled office equipment can't cope either: printers, scanners, interphones, PBX, security systems, etc. There is simply no easy fix there.- Software tools aren't designed for IPv6. That is changing slowly but I have yet to see a workable way to implement, say, a Citrix web interface with secure gateway on anything but IPv4. heck: it doesn't even work right with FQDNs.- Connectivity. I don't know for you, but when I ask my ISP what kind of IPv6 connectivity he has, he usually offers me tickets to the next local soccer or hokey match instead of answering. It's great to have free tickets but I'd like an answer that doesn't involves the sentence "none at all".- VPNs 8in particular layer 2 VPNs) simply don't work right in IPv6, in particular if you're interfacing several different implementations.

In all, I think what we will do is create two worlds: one IPv6 only world where internal servers and workstations will live and on IPv4 world where all the "old junk" will live. In between, we'll place a IPv4 to IPv6 map so the "new" network can reach the "old" one. I hope that we'll be able to switch the external communication to IPv6 at some point but I'm far from certain I'll still be in the active workforce when that happens.

I think that the central issue for IPv6 is the lack of a business case. In general, you don't make any money adding IPv6 support. The only thing IPv6 really offers is more addresses and almost nobody is willing to pay for that, today.

Now, the situation is not as bad as the article suggests. IPv6 does work. Many be not as well as IPv4 but you can get a lot of work done.

In areas where ISPs have lots of IPv4 addresses, IPv6 doesn't really offer anything. But where ISPs are growing rapidly, in Asia, Latin America, but also the 3G networks, the choice will be between carrier grade NAT and IPv6.

I think that for Asia (and probably also Latin America) the transition will be relatively easy: every ISP will feel the need to switch to IPv6 and at the same time, lots of consumer devices are designed and build in Asia. Of course, websites dedicated to those regions will also quickly add IPv6 addresses.

For 3G in Europe, US, etc. it may be tricky. Most of the fixed line users will be happy with their IPv4 addresses so there is less incentive for websites to offer IPv6.

Some the issues (wanting to use DHCPv6, firewalls) are mostly an issue for (larger) corporations, which are mostly irrelevant for consumers. They may just have to wait for office routers that default to setting the 'M-bit' (managed network, tells hosts to use DHCPv6) and probably don't care much about support for p2p protocols.

In 20,000 years when we've colonised the multiverse with countless zillions of people, warpspace network engineers will look back and curse IPv6 designers for being so short-sighted with their measley 128-bit addresses.

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.