The Dual Stack Dilemma

We are entering the transitional period between IPv4 andIPv6, and things are going to get awkward for a while. IPv4 addresses will officially be used up in the next couple of years, although for most practical purposes you can consider the pool of unallocated IPv4 addresses to be depleted already. I know of two very large service providers whose requests for new IPv4 allocations were, in the last couple of months, denied.

The “awkward period” we are entering is caused by several unavoidable facts:

1)   With few exceptions, the only new globally unique unicast addresses you can get from your regional address registries are IPv6. Those organizations are becoming very protective of the few IPv4 blocks they have left, and even those will be gone in short order.

2)   The vast majority of the user devices connecting to theInternet are IPv4.

3)   The vast majority of content accessible over the Internet is IPv4 only.

4)   The vast majority of service provider connectivity to their customers remains IPv4 only. Getting even basic connectivity to the “IPv6 Internet” usually requires some form of IPv6-over-IPv4 tunneling, and the average user has no motivation to enable this.

5)   Although modern operating systems are fully IPv6 capable (Windows Vista, MAC OS, most flavors of Unix), there is still a huge installed base of operating systems that either have limited IPv6 support (Windows XP) or none at all.

6)   Service providers are faced with growing their network using IPv6, while continuing to serve legacy IPv4 customers. They are going tobe coping with some unwieldy logical architectures for a while.

7)   New customer networks will probably continue to spring up using private IPv4 addresses, even if all the gear they install is IPv6 capable. It will take years for IT personnel to become comfortable with IPv6.The difference is that increasingly, the public side of their NAT devices is going to be IPv6 rather than IPv4.

Coping with the early transitional years, in which most content and users are still on IPv4 but the only new addresses are IPv6, falls heavily on service providers. They cannot continue giving customers globally routable IPv4 addresses, they cannot get new globally routable IPv4 addresses for expanding their own networks, and yet they must continue to serve both legacy IPv4 customers and new customers – all of whom are primarily trying to reach IPv4 destinations.

Keep in mind that the vast majority of broadband customers could care less whether their application traffic is riding over IPv4 or IPv6, or even know what IP is. Customers care about services, and how well those services are delivered. So any effort by a service provider to introduce IPv6 that reduces service quality or inconveniences their customers is going to be costly. In an intensely competitive market, even perceptions matter: A customer might not have run Windows 95 for years, and his IPv4-only game system might be gathering dust in the closet, but tell him that he cannot use them and he might switch providers.

Therefore IPv4 and IPv6 must coexist for some number of years, and their coexistence must be transparent to end users. In fact if an IPv4-to-IPv6 transition is successful, the end users should not even notice it.

The tools available to networkers for IPv4/IPv6 coexistence fall into one of four categories:

·     Dual stack: A dual stack device is “bilingual;” that is, it can originate and understand both IPv4 and IPv6 packets.

·     Manually configured tunnels: A tunnel carries IPv4 packets in IPv6, or IPv6 packets in IPv4. A manually configured tunnel is one in which the network operator specifies the endpoints of the tunnel and the encapsulation technology; the tunnel stays up until the operator removes it. Manual tunnels are ideal for connecting IPv6 sites over IPv4 or vice versa. IP in IP, GRE, and MPLS are the usual technologies used.

·     Automatic tunnels: 6to4, ISATAP, DSTM, and tunnel brokers are the most prominent examples of automatic tunnels; these technologies are best applied when temporary tunneling is required. Unlike manual tunnels, automatic tunnels identify their own endpoints and are set up and torn down as needed.

·     Translators:These are used when an IPv4-only device must speak to an IPv6-only device, or when some portion of the network between two end systems can only carry one IP version. Some translators, such as NAT-PT, work at the network layer and convert all packets of one version to packets of the other version. Other translators are Application Layer Gateways (ALGs) that only convert packets belonging to certain applications.

Dual stacking is by far the preferable solution in most scenarios. The dual stacked device can speak equally to IPv4 devices, IPv6 devices, and other dual-stacked devices (with the two devices agreeing on which IP version to speak). And the entire transition can be driven by DNS: If a dual-stacked device queries the name of a destination and DNS gives it an IPv4 address (a DNS A Record), it sends IPv4 packets. If DNS responds with an IPv6 address (a DNS AAAA Record), it sends IPv6 packets.

There’s an unfortunate flaw in the assumed simplicity of dual stacking, though. If you are going to dual stack everything, everything needs both an IPv6 and an IPv4 address.  And… um… we’re out of IPv4 addresses. This is where we came in.

Dual stacking would have been the ideal transition strategy about ten years ago, when there were still plenty of IPv4 addresses to go around. But we didn’t: Ten years ago there were not that many people who believed we would be running out of IPv4 addresses this soon, and few saw a compelling case for going to the expense and trouble to make the transition. Most of us who were advocating IPv6 at that time – myself included– were talking about killer applications and exploding mobile markets and exploding Asian populations and getting back to an end-to-end Internet model, not address depletion.

Ironically, even now the network operators who are the least inclined to start planning for IPv6 are those who are still sitting on an abundant supply of IPv4 addresses. They’re in the best position to use dual stacking and avoiding the eventual pain of transition, but they are not feeling the sense of urgency that comes from analyzing their usagerates and seeing a big hard wall just around the next curve.

This does not by a long shot mean that dual stacking is no longer an option for IPv4/IPv6 coexistence. It just means that we must continue handling the IPv4 address challenges the way we’ve been handling them since the mid-1990s: with Network Address Translation. Building dual stacked networks that mix global IPv6 addresses and NAT-ed IPv4 addresses is feasible; it’s just, as I said in the beginning, awkward.

There is no shortage of proposals for stretching what’s left of the IPv4 address space into dual stacked networks: Carrier-Grade NAT (CGN), NAT444, NAT464, Dual-Stack Lite, IVI, A+P… The challenge is deciding which of the proposed solutions are the most practical for the most networks. None of them have yet gone into widespread deployment, and the details of some are still being worked out in the IETF.

Over the next few posts I’m going to be looking into these various “global IPv6 plus private IPv4” combinations for dual stack deployment.

• carrier-grade NAT
• CGN
• IPv6
• NAT