Looming IPv6 Transition Crunch Complicates Outlook for Internet

John Curran, president & CEO, ARIN

John Curran, president & CEO, ARIN

June 4, 2010 – With time running out rapidly on the supply of IPv4 addresses the Internet world appears to be heading into what could be a crisis of historical proportions owing to the fact that the transition to IPv6 is shaping up to be much more complicated than many people expect.

Notwithstanding various naysayers’ arguments as to why the address exhaust scenario isn’t as dire as the American Registry for Internet Numbers and other concerned parties say it is, the fact is the depletion rate of available IPv4 addresses is running right on target with projections set a year ago and earlier. Indeed, says John Curran, president and CEO of ARIN, already this year the volume of IPv4 addresses allocated from the Internet Assigned Number Authority (IANA) pool has reached the number allocated for all of 2009.

“The fact is, the demand for Internet addresses is going up,” Curran says. “We’re going to run out of numbers in the IANA pool by July 30 next year.”

The approximately 2.7 billion Internet addresses comprising the free IANA pool were divided into 256 blocks of “slash 8” allocations that have been meted out over the years to ARIN and the other regional authorities charged with fulfilling requests for IP addresses from ISPs, enterprises, governments and other entities across the globe. There are just 18 of these blocks left, out of which the share to be allocated to ARIN represents enough numbers to allow for ongoing individual allocations through about March of 2012 Curran says. At that point no one in North America, the region covered by ARIN, will be able to obtain an Internet address conforming to the IPv4 32-bit format.

IPv6 was designed to do away with any threat of address exhaust for a long, long time to come. Because IPv6 is based on a 128-bit scheme the volume of possible number combinations for individual addresses is astronomically greater, equating to 340 trillion, trillion, trillion addresses. One illustration of the proportionate difference cited by Curran is that if IPv4 addresses were compacted at a density sufficient to put them all inside a golf ball, IPv6 addresses at the same density would fill a sphere the size of the sun.

Already ARIN has cut the per-request allocation of IPv4 addresses to ISPs from a years’ worth of anticipated requirements to just six months’ worth, Curran says. “It’s quite possible we’ll move to a three-month allocation window,” he says, adding, “Most ISPs realize the end is near.”

But realizing it and taking timely action are two different things. “The transition to IPv6 was to be gradual, but it’s going to be a flash cut over the next one to two years in many cases,” says Chris Donley, project director for network protocols at CableLabs.

Flash cutting to IPv6 may be difficult. The transition entails finding ways to support use of IPv6 addresses for adding new customers and/or new devices while continuing to support all the IPv4 addresses. Since IPv6 is not backward compatible with IPv4, this means routers must have different routing tables for IPv6; devices running IPv6 that connect with IPv4-addressed devices must have some means of translating between the two; provisions for security must be altered, and many other steps must be taken to allow an IPv6-based ecosystem to emerge in an IPv4-saturated environment.

For example, new IPv6 home gateways designed to interface with legacy devices may be entering the market, but it will take awhile before they’re ready for prime time, Donley notes. “Recently CableLabs and vendors tested a number of these devices,” he says. “We streamed content from Netflix and YouTube over IPv6 to real [IPv4] devices behind these gateways.” Those tests showed “there’s still a lot of work to be done” at the manufacturing level to assure smooth interoperability.

The pace of preparations for IPv6 over cable and carrier networks is mixed. At the Tier 1 carrier level “most carriers are in full-fledged transition mode,” says Chris Davis, senior director of marketing at NTT America, the U.S. arm of the Japanese carrier. Noting that NTT has been operating in “dual-stack” mode, meaning transporting both IPv6 and IPv4 streams over its backbone, since 2006, Davis says the flow of transition announcements from NTT’s competitors has been fairly steady over the past couple of years.

But at the regional carrier and MSO levels it’s a mixed bag, he adds. “I’d say that large telcos with big consumer interests have yet to make big announcements,” he notes.

The leading force behind the transition in U.S. cable has been Comcast. According to
John Jason Brzozowski, chief architect and IPv6 distinguished engineer at Comcast, the MSO is on target to complete four important trials this year. “We’ve been preparing for the trials by making sure our access networks, DNS (domain name server) infrastructure, home gateways and other things required to support v6 meet the technical needs of the trials,” Brzozowski says.

Comcast’s core backbone network has been IPv6 capable since 2006, which allowed the MSO to provide support for wholesale customers’ operations in IPv6 starting last year. While preparing all the core routers, DNS servers, peering points and other backbone components is not trivial, the really heavy lifting comes on the legacy cable network side where an immense amount of work is needed to enable IPv6 support in back-office components and access network elements.

As Brzozowsky notes, to safely launch support for IPv6 over access networks a large MSO must not only deploy thousands of new devices; it must ensure smooth interoperability across large populations of devices often numbering in the millions, including CMTSs (cable modem termination systems) cable modems and back-office elements.

All this work is facilitated by the fact that cable’s DOCSIS 3.0 standard provides for support for IPv6 in the new generation of CMTSs and cable modems, and CableLabs has also set an upgrade path for enabling IPv6 over DOCSIS 2.0 infrastructure. CableLabs is also working with the IETF (Internet Engineering Task Force) to define an IPv6 gateway enabling connectivity over cable and DSL networks to both IPv6 and IPv4 devices in the home.

In Comcast’s case the trials planned for the second half of this year are designed to test various steps in the migration path to introduction of IPv6 and to help the MSO refine the details of that migration, Brzozowsky says. These trials, involving over 5,600 volunteers using new IPv6-enabled premises devices, will take place in three phases, beginning with the use of a tunneling technique known as 6RD, whereby IPv6-based communications are transmitted over the IPv4 network. This could be an important option in areas where network operators have not equipped their networks to support IPv6.

“I fully support people with challenges in their networks using 6RD to support IPv6, but we haven’t determined if we’re going to use it ourselves,” Brzozowsky says. While there are drawbacks to 6RD, including very little market support in CPE devices, he adds, “I can tell you from testing so far that it just works. It could be a very compelling solution for people who have IPv6 challenges in their networks.”

Phase two of the Comcast initiative will entail dual-stack operations of native IPv4 and IPv6 transmissions in two trials, one for residential and one for commercial customers. In this approach, which will be used with the lion’s share of Comcast’s customers when the company goes live with IPv6 in its access networks starting next year, customers assigned global IPv4 addresses will continue to communicate as they always have over IPv4 infrastructure, while new IPv6 devices will be provided IPv6 addresses to support communications over the IPv6 infrastructure.

This approach to bringing IPv6 in play works fine until the world runs out of IPv4 addresses to assign new subscribers. At that point merely giving someone an IPv6 address will not suffice, because people will have a bunch of legacy IPv4 devices that won’t respond to communications coming in over their IPv6 connections. Thus, some way must be found to continue supporting legacy devices owned by new subscribers once there are no more IPv4 addresses to hand out.

In the legacy Internet world, ISPs typically assign customers one public IPv4 address and then, through use of the technique known as NAT (Network Address Translation), allocate private addresses tied to that public address for purposes of connecting multiple premises devices to the access network. When it comes to planning for IPv4 address exhaust, what is known as Carrier Grade NAT (CGN) comes into play, where multiple new subscribers will be assigned private address extensions to a commonly shared IPv4 address that is managed within the provider’s network. This way one public IPv4 address might serve ten, 100 or even 200 new customers, thereby ameliorating the pain and urgency of getting every device connected via IPv6.

While one approach to CGN, known as “NAT444,” would continue delivering all IPv4 communications over the IPv4 network, another approach developed by Comcast and known as “Dual-Stack Lite” provides a means by which all IPv4 traffic is tunneled over the IPv6 access network. This does away with the complexities of managing two tiers of NAT – the legacy premises system and CGN – over the IPv4 infrastructure and speeds the transition of everyone to IPv6. DS-Lite has grown in appeal and is now in advanced stages of standardization at the IETF.

In March Comcast and the non-profit group Internet Systems Consortium (ISC) released open source Address Family Transition Router (AFTR) software to facilitate service providers’ implementation of DS-Lite. AFTR, the heart of the IPv4-IPv4 CGN translation process, operates in conjunction with another new element, the DS-Lite Basic Bridging BroadBand element (B4), which resides in each IPv6 gateway device as the tunneling point for sending IPv4 traffic through the IPv6 network to the translation center.

DS-Lite will comprise the third phase of the Comcast trial series this year and, at this point, is the MSO’s preferred approach to accommodating the addition of new subscribers once the IPv4 address supply runs out. Brzozowsky says Comcast expects to complete the transition to dual-stack operations prior to having to implement DS-Lite when IPv4 addresses run out.

Beyond all the back-office and network element upgrades and interoperability testing that go into enabling migration to IPv6, service providers have many issues to contend with that are common to the entire ecosystem of entities trying to manage transitions to IPv6. Indeed, says ARIN’s Curran, “Operating systems and network management tools, all your internal stuff, will be your biggest problem in migrating to v6.”

For example, Curran notes, every piece of software that requires recognition of a Web address must be able to accommodate the input of IPv6 addresses, which can be up to 57 characters long, counting buffer characters, versus the 16-character space typically used for entering IPv4 addresses. “Every time you created a data base or app and someone said how big is an IP address and you said 16 characters, some data base programmer made up an entry space 16 characters long,” he says. “If the app asks for your IP address and expects 16 characters, v6 doesn’t work.”

Adding to the IPv6 transition issues stacking up across the Internet ecosystem are points of newly discovered security vulnerabilities. “IPv6 adds a number of attack surfaces” beyond the ones that have been exposed in the IPv4 world over the past 30 years, notes Ron Hulen, CTO for cyber security solutions at Command Information, Inc., a supplier of security solutions to government agencies and corporations worldwide.

These include transition tunnels and protocol translators associated with dual-stack operations, Hulen notes. There’s also a vulnerability associated with how the IPv6 packet header is constructed, where instead of myriad fields tied to variable-length headers the architecture uses an extension mechanism where the main header supports additional fields with “hop ahead” instructions to extension headers for TCP/IP (Transport Control Protocol over IP), UDP (User Datagram Protocol) and other typical Internet trafficking operations.

Already Hulen’s group has witnessed hacker probes from China that used header extensions on IPv6 traffic. Some hacks involved unknown UDP extensions that forwarded traffic to Taiwan, Singapore and the Philippines. Security mechanisms provide strong protection against traditional types of attacks as they might affect IPv6, Hulen notes, but, he adds, “Who’s inspecting packets to make sure they’re not exposed to the vulnerabilities from unlimited extension headers?”

In another vivid demonstration of unresolved vulnerabilities, Hulen points to a recent staging of the Middle Atlantic Collegiate Cyber Defense Competition where undergraduates attempted to hack into each other’s systems. “V6 was in play for the competition and was enabled on all target hosts,” he says. “The firewall tools didn’t stop hacks of v6 traffic. The teams were able to ignore the rules and compromise each other’s systems.”

There’s much more to the IPv6 security story. “I can’t tell you everything we’ve seen,” Hulen says, “but IPv6 threats are real. Hackers are using IPv6 to tunnel into networks undetected. IPv6 adoption brings systemic effects that will require new tools and processes that have yet to be widely adopted.”

With time running out on the availability of IPv4 addresses, the problem the Internet ecosystem faces with IPv6 isn’t that all these problems can’t be addressed. It’s that as there’s ever less time to deal with all the issues discussed here, as well as many others, the potential for a major pileup grows.

For example, presently, only one half to two percent of all Web sites are enabled for IPv6, Curran notes. This may not seem to be a big deal, given only a tiny fraction of traffic to any given site is coming from IPv6 addresses. But being lulled into thinking there’s no need now to go through the hassles of addressing all the issues associated with internal adaptation to IPv6 will have consequences for content providers sooner than they may anticipate, he adds.

“Content providers that don’t put v6 on their Web sites by next year will see customers connected through v6 gateways to their sites,” Curran says. Given problems seen with overloading or malfunctioning of gateways, the user may experience delays or interruptions in content flow which the user will attribute to the quality of service on the site. Advertising tracking mechanisms won’t be able to identify users. And there’s the whole issue of IP address field incompatibilities, which will get in the way of authorizing credit card purchases. “The fact is, you’re going to be removed from a growing number of your customers if you don’t put v6 on your site,” Curran says.

For all players it comes down to either acting now or getting backed up in long lines of people waiting for expert assistance and resolution to internal compatibility issues. “You can get help pretty quickly now,” Curran notes. “That won’t be the case a year from now.”