Lessons Learned: Connectivity, Device Management Key for IPv6 Transition Success

The importance of IPv6 has received increased attention in recent months. As global IPv4 resources near depletion, regional registries like the American Registry for Internet Numbers (ARIN) continue to encourage the Internet community to adopt IPv6. The National Telecommunications and Information Administration (NTIA) and the U.S. Department of Commerce also recently organized an event to outline plans for government agencies to push adoption. These recent activities appear to be resulting in a rise in the number of organization actively planning for the transition.

Comcast initiated its IPv6 program in early 2005. Since then, the operator has continued to be on the IPv6 forefront, often sharing information about its plans for IPv6 as well as valuable deployment experiences.

Earlier this year, Comcast announced it would be conducting a number of trials (http://www.comcast6.net) to exercise various IPv6 technologies. The purpose of the trials is to help ensure the nuance of each technology is well-understood. Further, by conducting technology trials, Comcast expects to assess the seamlessness and usability of each for end users along with deployment consideration for the same from an operator’s point of view.

Trials And Devices

As various types of providers plan for or actively are readying their infrastructures, many are contemplating which technology is best used to enable IPv6. Content and service providers are faced with diverse challenges and, as such, will require different tools and techniques at different points in the transition. From a service provider’s point of view, leveraging IPv6 to manage devices has different requirements compared to enabling IPv6 connectivity to end users. However, there are many common requirements and principles relevant to both.

Leveraging IPv6 to manage devices is not analogous to enabling IPv6 connectivity to end users. In many cases, this is transparent to end user, which often is by design. Because support for IPv6 was included as part of DOCSIS specification development five years ago, DOCSIS 3.0- and, subsequently, DOCSIS 2.0-based cable-modem implementations have introduced support for management using IPv6. As with most technology-development and –implementation efforts, the quality of the products improves over time.

Support for IPv6 in DOCSIS devices is no different. While the quality of the implementations has, in fact, improved, opportunities to enhance the technology most always present themselves. Incremental enablement should be foundational to any major technology program, including IPv6. Some time ago, an enhancement that most often is called MDD (MAC Domain Descriptors) IP Mode Override was introduced into DOCSIS. The IP Mode MDD often is configured on the Cable Modem Termination System to instruct cable modems to attempt provisioning in one of several modes of operation.

As part of limited trials, it was identified that it may not be desirable for cable modems that support IPv6 to attempt initialization uncontrollably or in bulk. The need arose to be able control the IP mode used for device management at the cable modem and at the CMTS. MDD IP Mode Override is the feature that makes this possible. Many operators are using this feature to conduct limited and controlled IPv6 cable-modem-management trials. This feature truly places control in the hands of operators to determine how and when devices are managed using IPv6.

While support for IPv6 has improved dramatically in recent years, some non-technical challenges could be lurking for operators. When managing cable modems using IPv6, the ability of the device to operate fully and seamlessly in IPv6 mode is a strict requirement. Early implementations of IPv6 in cable modems had challenges and, in some cases, they would not operate properly in IPv6 mode. While this has improved dramatically, it still is likely that there are devices today that have been loaded with older firmware that can’t properly support IPv6. These devices could be located anywhere, from an operators warehouse to a technician’s vehicle awaiting deployment.

Enabling services to support IPv6 is a critical step in the transition. As the Internet community draws closer to the global depletion of IPv4, some new technologies have been born. However, some well-known technologies and techniques also are seeing great support.

6to4 Transition Technology

“6to4” is a well-known IPv6 transition technology whose creation dates back nearly 10 years. It’s the encapsulation of IPv6 packets within IPv4 packets. One of the main goals of 6to4 was to allow for access to IPv6 when service-provider access networks do not or cannot support native IPv6 connectivity.

An important aspect of 6to4 is that it leverages well-known IPv4 and IPv6 anycast addressing to facilitate 6to4 relay discovery. The deployment of open and poorly managed 6to4 relays coupled with the use of well-known anycast addressing has made it difficult to leverage 6to4 for high-quality, reliable IPv6 connectivity. Further, the encapsulation of IPv6 packets within IPv4 packets presents additional challenges related to the types of services for which 6to4 can be used. For example, live or interactive applications or communications likely will experience latency.

While it may not be possible to leverage 6to4 generally, service providers can deploy their own 6to4 relays to significantly reduce the latency associated with 6to4.

The Newest Addition

A new addition to the toolbox of transition technologies — 6rd or IPv6 Rapid Deployment (draft-ietf-softwire-ipv6-6rd) — is based on the same underlying technology upon which 6to4 is built. 6rd, however offers some interesting enhancements, namely freeing adopters of the same from the use of well-known IPv4 and IPv6 anycast addressing. This enhancement offers service providers more control over how 6rd traffic is routed and, ultimately, the quality of the same. 6rd is often recommend, and rightfully so, for service providers that simply cannot upgrade their access networks to support IPv6 natively.

However, 6rd (like 6to4) relies on the encapsulation of IPv6 packets within IPv4 packets. This fundamental attribute of 6rd (and 6to4) presents challenges related to the kinds of services that can reliably be consumed while offering a quality end-user experience. Service providers leveraging 6rd can deploy a robust, distributed 6rd border relay (BR) infrastructure to further increase performance and reliability.

As expected, this more than likely will require substantial investment. In centralized 6rd border relay deployments, it is important to note that IPv6 geolocation will be impacted. Centralized 6rd border relays, in most cases, will source IPv6 traffic from these centralized locations, which in turn may impede or complicate content and service localization.

Finally, while this technology offers promises to adopters running IPv6-incapable access networks, generally available home-networking equipment or customer edge (CE) that supports 6rd still appears to be lacking. While there are signs of change on this front, the absence of 6rd-capable customer edge equipment certainly will present challenges to would-be adopters.

Native Dual Stack

“Native dual stack” is the introduction of native IPv6 connectivity alongside existing, native IPv4 connectivity. With native dual stack, IPv6 packets are routed just as IPv4 packets are, with no tunnels, translation or encapsulation.

Native dual stack has for many years been referred to as the preferred approach to the transition to IPv6 because it offers the most seamless experience to end users. While native dual stack has many benefits, deployment of the same has not been embraced widely. In recent years, there has been renewed interest and support for native dual stack as the preferred IPv6 transition approach. Unfortunately, there are service providers that simply are not able to natively route IPv6 as they route IPv4 today.

For those that can or will be able to support IPv6, native dual stack is central to facilitating the transition. Most often, access networks capable of supporting native dual stack still require software upgrades and configuration to enable native IPv6 support alongside IPv4. While this can be viewed as “business as usual,” this is new territory, often unfolding at a slower pace. Incrementally orchestrating the upgrade and configuration activities for a new technology takes time.

A key aspect of deploying and enabling native dual stack is the end user’s home-network equipment. Not too long ago, there were virtually no residential home-networking implementations that supported native dual stack provisioning and operation. The availability of residential home-networking devices that meet the requirements for native dual stack has increased substantially and includes many well-known names today. Even with this increase in product availability, here is the remaining challenge: How to ensure that end users upgrade or purchase native dual stack-capable home-networking equipment.

Finally, the testing of native dual stack suggests the claims of seamlessness are, indeed, accurate, which is promising.

Dual Stack ‘Lite’

“Dual Stack Lite” is another newcomer to the collection of transition technologies. Unlike 6to4 and 6rd, Dual Stack Lite encapsulates IPv4 packets within IPv6 packets. Dual Stack Lite seems to be viewed as a technology that will be used when the pool of IPv4 addresses has fully depleted.

Dual Stack Lite is dependent on the availability of native IPv6 connectivity from the service provider. For encapsulated IPv4 traffic, Dual Stack Lite requires an Address Family Transition Router (AFTR) to terminate Dual Stack Lite tunnels. Additionally, the AFTR decapsulates IPv4 traffic and performs network address translation (NAT) for the same to the Internet.

While it is somewhat early to fully assess Dual Stack Lite, AFTR implementations are appearing; however, the availability of end-user home networking equipment that supports Dual Stack Lite is lacking, which may be acceptable, given the timing for this technology.

What Happens Next?

Conducting IPv6 technology trials offers providers and end users alike a great opportunity to identify and assess the opportunities and challenges associated with preparing for and deploying IPv6 in a production environment. Wide ranges of experiences have been gained already, and there is more to come as adoption increases.

Thus far, there have been many observations that have stemmed from the planning and execution of the these trials, specifically that content and services over IPv6 clearly are missing. In order to have a successful transition, IPv6-enabled end-user access, content and services must increase proportionally.

Even with recent news from content providers and the government, there are a number of challenges the cable community faces, most notably how IPv6-enabled content and services are advertised. To date, there are few, if any, popular content and services providers openly advertising their access to the same over IPv6. Limited access to content and services over IPv6 most certainly will impact the rate of adoption, which in turn impacts the entire Internet community.

John Jason Brzozowski is a Comcast Distinguished Engineer and the MSO’s chief architect for IPv6.