Moving to IPv6: Rebuilding the Heart of the Internet Without Missing a Beat

Within the coming decade, Internet Protocol version 6 (IPv6) will be key to enabling 50 billion connections among people, processes, data, and things in the Internet of Everything (IoE). But how we get there from here is not a simple matter.

I’m very pleased to invite Mark Townsley, Cisco Fellow and recognized industry expert on IP, to discuss this important transition in the second of our three-part blog series on IPv6. The first blog in Mark’s series was “Demystifying IPv6”.

Three years ago, I organized a conference in Paris where I thought it would be fascinating to bring together the original designers of IPv6 alongside the engineers who were finally deploying it at scale more than a decade later. During this discussion, Steve Deering, one of the “fathers” of IPv6 in the 1990s, was asked one of the most common questions about IPv6: Why wasn’t it designed for backward compatibility with IPv4? After all, wouldn’t it be easier to make the transition if the two versions could transparently coexist? Steve answered that the problem is not that IPv6 wasn’t designed to be backward-compatible—the real problem is that IPv4 wasn’t designed to be forward-compatible.

Steve was making the point that IPv4 was designed with a fixed address space. Given the number of computers connected to the Arpanet throughout the 1970s, this fixed-length address field seemed to be sufficient—at least for that version of IP. IP had been replaced before, and it seemed perfectly reasonable at the time that it might be replaced again.

Network protocols were fluid things well into the 1990s—with IPX, AppleTalk, Banyan VINES, DECnet, SNA, and XNS all running over the same data links. IPv4 sat alongside these other networking protocols, quietly taking its dominant position over nearly two decades. IPv6 was designed to sit alongside IPv4 in a very similar manner, taking its dominant position over time as well. To make this a seamless process, existing networked devices must be able to speak IPv6 and IPv4 at the same time—ideally, without users even knowing it.

Virtually all modern operating systems used by people today—Windows Vista, 7 or 8, Apple Mac OS X or iOS, and Google Android—are dual-stack, meaning they support both IPv6 and IPv4. This large installed base was “step zero” in the transition to a new Internet Protocol. The next steps were World IPv6 Day in 2011 and World IPv6 Launch in 2012. In just over two years, we have entered a phase of progressive uptake, and are poised to reach 50 percent IPv6 adoption within five years.

While the “human” Internet we know today has begun its transition from IPv4 to IPv6, there is another Internet of “things” that is beginning to emerge from a multitude of incompatible, often proprietary protocols that have been fragmenting the industry. As the Internet of Things emerges, it will embrace IPv6, and skip over IPv4 entirely.

Easing the Challenges of Dual-Stack

IP touches every part of the Internet, and any transition from IPv4 is bound to be challenging on multiple levels.

While dual-stack is an essential baseline mode of operation, in some cases we’ll need the ability to overlay IPv6 on top of IPv4, then IPv4 on top of IPv6—particularly for “last mile” connections where the burden of running two IP stacks in parallel is perhaps the greatest. Two protocols are particularly useful in this transition:

1. IPv6 rapid deployment (6rd) specifies how an ISP can set up reversible mapping between its own IPv6 and IPv4 address spaces, allowing IPv6 to run over an existing IPv4 network with very little overhead.
2. Mapping of address and port (MAP) is the practical inverse of 6rd, allowing IPv4 to run over the new IPv6 network. Not only is the IPv4 address space mapped into IPv6, but part of the port space above IPv4 is mapped as well, enabling concurrent IPv4 and IPv6 service while using far fewer IPv4 addresses.

Cisco believes it is important to be able to map IPv4 and IPv6 addresses in the network in a way that doesn’t require tracking each and every session a user launches from a networked device. 6rd and MAP do just that, in a way that scales because the mapping rules can be aggregated—similar to how the IP routing system itself works. This is a clear advantage in terms of scale and efficiency compared to mechanisms that require the network to track individual flows.

While some areas of the network will remain dual-stack for a long time, these two technologies come as near as we have so far to making IPv6 and IPv4 backward- and forward-compatible within the network. This can help solve some of the greatest challenges for both IPv6 deployment and IPv4 address scarcity. The value proposition of 6rd to the global deployment of IPv6 is already measurable and clear. I believe the same will be true of MAP in coming years.

Successfully completing the transition to IPv6 will require the ongoing commitment and vision of every network operator, device manufacturer, software developer, and anyone else who develops Internet-based technology. We have only begun to imagine the transformation that will take place as more and more people, processes, data, and things are connected in the Internet of Everything.

In the next installment, we’ll take a closer look at some of the exciting new things a fully IPv6-enabled network can bring.