The Hitchhiker’s Guide to Ipv6

On April 15, 2009, John Curran, then chairman of the board of trustees (and now president and CEO) for the American Registry for Internet Numbers (ARIN), sent a letter to corporate leaders of the Internet community underscoring a key concern. "At the current rate of consumption, IPv4 addresses will be depleted within the next two years," Curran stated.

Curran strongly recommended that service providers start planning for IPv6 adoption, if they had not done so already.

The adoption of IP version 6 (IPv6), like that of any technology, has its benefits and challenges. But at least one key benefit is well understood. By means of a 128-bit address, IPv6 has a maximum of 2 ¹²⁸ available addresses — that is, roughly 34 followed by 37 zeros. In one popular translation, this is enough to give multiple IP addresses to every grain of sand on the planet.

What requires further attention are the challenges of IPv6 adoption. With the goal of sharing insight into what it takes to deploy IPv6 (and with a nod to Douglas Adams, author of The Hitchhiker’s Guide to the Galaxy, for inspiring the title and corresponding subheads) this article addresses three general topics:

• IPv6 gaps, status and trends

• Testing and integration

• IPv4 to IPv6 transition

Life, the universe and IPv6

Given the focus on IPv4 address depletion, more businesses, content providers, and service providers are demonstrating interest and initiative toward IPv6 adoption. While this is good news, the fact remains that the adoption and introduction of IPv6 will not happen overnight. This becomes clear by evaluating support for and adoption of IPv6 in a handful of key areas.

Interconnections. The ability of providers to interconnect over IPv4 and IPv6 alike is an important requirement to enable seamless public consumption of content and services using IPv6. The number of network interconnections where IPv6 is enabled continues to grow. Their level of support and quality also are rising. While there are cases where IPv6 interconnections are not supported, the expectation is that as IPv6 traffic grows, so too will cases where IPv6 is supported.

Content. IPv6-enabled consumer devices require generally accesible, hosted and distributed content available over IPv6. The capability of providers to host and deliver content over IPv6 seems to be taking a turn for the better, with more players in the space enabling IPv6 as part of their service offerings. Of special note for content distributors: an IPv4 and IPv6-capable content distribution system could transmit content to consumer devices over IPv4 and IPv6 as appropriate, even though the original content may be acquired using one version of IP.

Security. The fundamentals of IPv6 security, including host-based and data center firewalls, are already in place. However, there are critical if well-understood gaps related to IPv6 security in the areas of vulnerability assessment and event detection, correlation, and prevention.

Left unaddressed, these gaps will complicate network security and may impede a provider’s ability to extend IPv6 beyond device management. Extending IPv6 broadband connectivity to consumers beyond device management increases the exposures and threats to the underlying network that must be managed to ensure that IPv4 and IPv6 subscriber services are of the highest quality and reliability.

DOCSIS. Until recently, the ability to offer IPv6-capable broadband services has been lacking across many types of broadband technologies. Development efforts by CableLabs, however, led to DOCSIS 3.0 specifications that support IPv6. Moreover, much of that work has been leveraged to introduce support for IPv6 in DOCSIS 2.0-based devices. The widespread deployment of DOCSIS 3.0 infrastructure that supports IPv6 will provide the essential foundation to enable IPv6-capable broadband services to consumers. (See sidebar, "DOCSIS Devices.")

Service introduction. Unlike Y2K, there is not an exact date when the available IPv4 address pool will be fully depleted. The underlying objective for most providers is to ensure that a residential or commercial subscriber’s Internet experience is unaffected as support for IPv6 is introduced. As long as the availability of Internet resources permits, some providers will introduce support for IPv6 alongside of a subscriber’s existing IPv4-only service. The simultaneous support of IPv4 and IPv6 needs to apply to the case where a subscriber has a computer directly connected to the broadband network and to the case where some form of home networking equipment is present between the broadband access network and one or more subscriber devices.

This approach provides a mechanism that enables subscriber devices to access content and services that are available over IPv6; otherwise, the devices automatically fall back to using IPv4.

Provisioning and DNS. Providers are planning deployments and strategies to minimize the impacts of IPv6. This is particularly true with regards to provisioning systems and the Domain Name System (DNS). From a provisioning point of view, it is important that providers can enable IPv6 granularly. Support for IPv6 continues to evolve in specific areas of broadband networks. As such, providers need this level of control to ensure a reliable and predictable introduction of IPv6 with no adverse impact on legacy services.

DNS is critical to the how the Internet works. This continues to be the case with the adoption of IPv6. It pays to plan carefully, because hastily enabling or populating DNS with IPv6 can adversely impact a subscriber’s experience. (For more on the role of DNS, see "Change of Address: IPv6," CT, January 2007.)

Home networking. A significant population of computing and home networking equipment in use today does not support IPv6 at all, or supports it in a limited fashion. Industry efforts have been underway to ensure that computing and home networking equipment properly support IPv6.

In the best case, subscribers pay attention when making purchasing decisions about home networking equipment. Full support for IPv6 when upgrading or refreshing their computing and home networking equipment is desirable, but is still growing in availability. (See sidebar, "Home Networking.")

Don’t Panic

As mentioned previously, the adoption and deployment of IPv6 has increased noticeably in recent years.

For most Internet service providers, adoption requires that a significant population of elements be upgraded and or developed to support their deployments of IPv6. In addition to introducing support for IPv6 in the core or backbone network, itself a significant effort, there are substantial quantities of back office components and access network elements that must be upgraded to support IPv6. (See sidebar, "Server Upgrades.")

These back office systems require either direct IPv6 connectivity to IPv6-enabled devices or the ability to store and manage information about IPv6 devices, such as provisioning, Dynamic Host Configuration Protocol (DHCP) and Communications Assistance for Law Enforcement Act (CALEA)-related systems.

The coordination, planning and deployment of these hundreds or thousands of devices to support IPv6 is a non-trivial task. This is of particular importance to ensure the introduction of IPv6 does not impact existing IPv4-based subscriber services.

Digging deeper, one notes considerable quantities and types of activities that must be performed well in advance of any upgrades or migrations in a production environment.

After establishing a deployment plan, testing migration and interoperability is paramount. This is particularly true in DOCSIS networks. In such cases, large populations (in some cases millions) of devices from multiple vendors including cable modem termination system (CMTS), cable modem, and back office elements all must operate seamlessly and reliably. (See sidebar, "Comcast and NANOG.")

The activities referred to here are obviously preceded by months or years of specification, design, and development efforts. Fortunately, would-be and active adopters of IPv6 can leverage the pioneering work that has taken place in recent years to expedite and even jumpstart their own IPv6 deployment efforts.

Much of the work that has been done to introduce support for IPv6 into DOCSIS 2.0, DOCSIS 3.0, and other related technologies can be leveraged directly. The larger community beyond the cable industry can also benefit from the experience and lessons learned.

Bridges at the edge

Even with the increase in IPv6 deployment activities, it is expected that the Internet community will essentially deplete the IPv4 address pool while there are still legacy consumer devices and Internet services and applications in use that are not IPv6-ready.

Examples of legacy devices without IPv6 support include certain game consoles, televisions, cameras with Wi-Fi interfaces, and of course computers running older operating systems. Furthermore, many "long tail" Internet website and application owners may not have enabled IPv6 access to their services.

In response, the Internet community has initiated various technology specification efforts that are intended to enable a smooth transition. While several approaches have been under consideration, two of the more popular and widely discussed technologies have been Network Address Translation (NAT)444 and Dual-Stack lite.

Both NAT444 and Dual-Stack lite enable the conservation of IPv4 addresses through the use of a carrier-grade NAT (CGN), alternatively called a large scale network address translation (LSN).

The concept of the carrier-grade NAT refers to an expansion of the well-known concept of network address translation, just on a much larger scale than the typical NAT in a home or office router. A CGN essentially enables providers to share a single public IPv4 address among a number of subscribers.

Most of the best practices for NATs learned by the Internet community apply to CGNs, and are being documented by the Internet Engineering Task Force (IETF) BEHAVE working group. The NAT444 approach simultaneously leverages two levels of NAT functionality: standard NAT within the subscriber home router, and CGN in the service provider network. NAT444 uses ordinary IPv4 connectivity between the home router and the CGN, and can work with existing subscriber home routers. Deployment of NAT444 is largely decoupled from IPv6 deployment. Draft specifications for NAT444 are being discussed in the IETF.

Dual-Stack lite directly leverages the native deployment of IPv6 by transporting IPv4 traffic over stateless IPv6 tunnels from the subscriber’s home router to the CGN. The horizontal scaling aspects of this tunnel-based approach may offer flexibility in the number and location of CGN equipment, potentially simplifying capacity management of the infrastructure. With Dual-Stack lite, the external interface of the home gateway is only configured with IPv6. The service provider does not need to allocate any IPv4 addresses at all, further helping to relieve the growing pressure related to IPv4 address depletion.

A key requirement for Dual-Stack lite is that the home networking equipment must support Dual-Stack lite, which in many cases will not apply to legacy home networking equipment. (Legacy equipment may not support IPv6 either.) Dual-Stack lite is being specified in the IETF Softwire working group, with significant participation and leadership by Comcast.

While the NAT444 and Dual-Stack lite approaches sound straightforward and somewhat benign, the Internet community is working to overcome a number of operational and deployment challenges related to the technologies.

Because multiple subscribers will share a single public IPv4 address, there may be an impact to internal and external systems that assume that an IPv4 address uniquely identifies an Internet subscriber. For example, some operator provisioning systems assume unique subscriber IPv4 addresses to enable automated subscriber activation or self-service.

Likewise, e-mail spam and Internet-abuse monitoring systems, as well as law enforcement systems, typically assume that an IPv4 address of an Internet offender can be associated with a unique subscriber. (Note: the volume of CGN data that enables abuse management may be substantial.) Furthermore, the operator must also ensure adequate manageability, performance, scalability, and reliability of CGNs in production deployments.

It is critical for operators to enable continued IPv4 Internet access to legacy consumer devices and to Internet services and applications, in addition to promoting the universal adoption of IPv6 technologies. In short, operators need to maintain IPv4 service without the dependency on unique per-subscriber IPv4 addresses.

Summary

Despite tremendous progress, much work on IPv6 lies ahead. That work will come in many forms. One large project includes efforts to ensure that support for and the deployment of IPv6 in the underlying Internet infrastructure takes place in a timely manner to enable the consumption, content and service over IPv6.

Related efforts include transition strategies to address the challenges that will present themselves when the available IPv4 address pool depletes within the next couple of years. It is important for adopters of IPv6 to consider the desired goal. It is also helpful for adopters, particularly those in the early stages, to recognize, understand and learn from the challenges that already have been overcome.

The bottom line is that it is not too late for IPv6. But the sooner you start the better. Those who have blazed the trail so far are ready to assist. See you online.

John Jason Brzozowski is principal engineer for IPv6 at NE&TO for Comcast Corporation.