CableLabs has taken a lead role working with its MSO members to articulate various transition paths from IPv4 to IPv6 and to develop a home premises gateway strategy that will avoid consumer confusion in an environment where two totally incompatible address systems are operating at the same time. As is the case with many CableLabs initiatives, the organization has begun holding interoperability tests every six months or so to keep everyone on the same page as new iterations of various transition and CPE strategies come into play.
“Basically we’re organized around three activities,” says Chris Donley, project director for network protocols at CableLabs. “They include knowledge sharing, where we hold regular meetings to discuss best practices and lessons learned; vendor readiness, which involves sharing common requirements with the vendor community and conducting interops, and, third, development.”
This last area of activity is vital to building on the IPv6 capabilities that were made a part of the DOCSIS 3.0 standard in 2006. Working with cable companies and the Internet Engineering Task Force, CableLabs has been fostering cable-optimized refinements in IPv4-to-IPv6 transition platforms already adopted by the IETF as well as promoting development of a new strategy, known as “Dual-Stack Lite,” originated by Comcast and now one of the three transition modes CableLabs has identified as recommended options for cable operators.
The past year has seen cable operators’ engagement with the extremely complex issues surrounding transition to IPv6 intensify amid growing realization that reserves of IPv4 addresses service providers need to sign up new subscribers are diminishing at an accelerating pace. “The exhaustion of IPv4 address is coming on really fast,” Donley says.
Estimates vary, he notes, but the projected date when the Internet Assigned Number Authority (IANA) will run out of addresses to hand out to regional dispensaries like ARIN (American Registry for Internet Numbers), the body governing address allocations in North America, keeps advancing, with some experts saying March of next year, others saying August. “ARIN will have six to nine months after that point before they run out,” Donley notes.
“It will be harder and harder for service providers to get new IPv4 addresses as we get closer to those dates,” he adds. “The Internet registries are tightening their policies to conserve IPv4 as long as possible.”
Making matters worse is the fact that the more MSOs gain experience preparing to enable IPv6 to run in parallel with IPv4, the more complicated and drawn out the process looks to be, notes Jason Weil, principal architect in the Network Architecture Group at Cox Communications. “One of the things we need to understand is the development window from customer premises vendors can be pretty long,” Weil says. “And it can be long for back-end vendors as well.”
Planning and training, capital cost budgeting processes, selection of transition strategies, adjustments in provisioning and other back-office processes and a lot of little details such as the need for new processor boards in cable modem terminations systems and aggregation routers, new line cards and many other changes are taxing MSOs that have begun the transition process.
“It’s a very difficult process to go through to make sure all your staff, support staff, call center agents, anybody inside the organization that will be customer facing – internal, external – has to be able to know their aspect and speak ipv6,” says Eric Ballard, manager of backbone engineering at Suddenlink Communications, a cable company serving 1.3 million subscribers in Texas and several other states.
“By the end of this year and going into next year we want to have all of our customer-facing services IPv6 enabled,” Ballard says. “We want to be able to provision and find the evolution path to where we can actually enable our residential customers with IPv6. We also need to take a different slant on our commercial customers, because the commercial implementation from a direct Ethernet-delivered product not provided through the CMTS is quite different.”
“There’s a rash of changes in how you do things,” agrees Steve Harris, director of advanced network technologies program development at the Society of Cable Telecommunications Engineers. “A lot of these things take time to iron out, so starting early will reduce your costs in the long run.”
All the complications stem from the fact that IPv6 and IPv4 are completely incompatible with one another. IPv6 was designed to do away with any threat of address exhaust for a long, long time to come with use of a 128-bit numbering scheme that extends the volume of possible combinations for individual addresses from a few billion under the IPv4 32-bit system to over 340 trillion, trillion, trillion.
And beyond the direct incompatibility is the fact that much of how Internet trafficking mechanisms work changes with IPv6. Packets are still routed, but there are new routing discovery protocols, and the hierarchical approach to address fields is entirely different. Multicast works under a new protocol. The design of headers that manage network treatment of datagrams, the bearers of information in IP packets, is completely different. Even the traditional base-ten decimal numbering system used in IPv4 notations is gone, replaced by base-16 hexadecimal notation.
Now, as cable operators get serious about implementing support for IPv6, the planning around the various transition strategies is intensifying with much dialogue in regular meetings convened through CableLabs. “We do biweekly roundtable calls with people from various MSOs where they can bring up agenda items, questions they have as they’re going through development and testing plans,” Donley says, noting the number of people on the calls is now averaging 20 or more. “People are sharing their experiences and asking questions of other MSOs.”
As for vendors, here, too, there’s been a significant uptick in engagement with the IPv6 challenge, says John Berg, a CableLabs senior engineer who manages interops for PacketCable and DOCSIS. “My perception is the vendor community is very engaged and is working closely with our members,” he says.
“We’re seeing a wide variety of products represented at the interops,” he notes. “Our last one, at the end of April, tested over 30 products from 15 vendors. In the past we were more focused on network issues. Now we’re focused more on how end users are going to perceive and address problems that come up with use of IPv6.”
The goal in setting up a smooth transition to IPv6 is to render addressing issues as invisible to consumers as they are with IPv4, Donley says. “Most people don’t know what IPv4 is,” he says. “We’re hoping to keep it that way with IPv6.”
The baseline transition strategy known as “Dual Stack” entails operating both the IPv6 and IPv4 environments over the same network infrastructure to allow end user devices to communicate in whichever protocol they’re equipped for. If a Dual-Stack network device such as the CMTS queries the name of a destination and the DNS (Domain Name System) gives it an IPv4 address (a DNS A Record), the CMTS sends IPv4 packets. If the DNS responds with an IPv6 address (a DNS AAAA Record), it sends IPv6 packets.
Any Dual-Stack network device can speak equally to IPv4 devices, IPv6 devices and other Dual-Stack devices, where, in the last instance, the two devices agree on which IP version to use. Thus, under Dual Stack, the entire transition can be driven by the IPv6-enabled DNS. All DOCSIS 3.0 CMTSs and modems are Dual-Stack devices, and CableLabs has now developed specifications to accommodate upgrades of 2.0 CMTSs and modems to Dual-Stack status.
When these IPv6-capable cable modems provision in IPv6 they use stateful DHCPv6 (Dynamic Host Configuration Protocol for IPv6) to acquire their IPv6 address, which is basically how modems provision with IPv4. The cable modem can provision itself for IPv4, IPv6 or Dual Stack mode, where it gets both an IPv4 and IPv6 address for management purposes.
At the same time, existing customers equipped with DOCSIS 3.0 or IPv6-enhanced 2.0 cable modems on a Dual-Stack network will be able to add and obtain addresses for new IPv6 devices that support stateful DHCPv6 provisioning. The modems will bridge IPv4 and IPv6 subscriber traffic no matter what mode the modem uses for management applications.
To extend address provisioning to devices that employ Stateless Auto Address Configuration (SLAAC), a provisioning mode that is not used with DOCSIS, CableLabs has developed an eRouter specification that defines a lightweight Dual-Stack cable modem with an embedded router. The eRouter will do WAN-side configuration using stateful DHCPv6 while passing SLAAC or stateful provisioning commands through to devices in accord with whichever provisioning system is required by a given device.
But, for all these preparations and the elegance of dual stack as a migration strategy, there’s one essential drawback, which is that for every IPv4 device connected by an IPv6 subscriber, there has to be a new IPv4 address provisioned. Unlike IPv4, IPv6 has no provision for Network Address Translation, which uses private addresses behind a public address to allow end users to continually add to their collection of connected devices without requiring new public addresses.
Given the fact that most new subscribers will likely have at least one device that needs an IPv4 address, the absence of the private address option means the exhaust rate on IPv4 will be the same or even accelerated compared to what it would be using IPv4 with NAT for new signups.
Thus, Dual Stack isn’t really a way to prolong address exhaust but rather serves to prepare for the eventual cutover to a predominantly IPv6 mode of operations while assuring there will be support for legacy IPv4 devices for some time to come.
“Dual Stack is the preferred method,” Donley says. “But it’s tied to how many addresses the providers have. There are a number of devices such as iPads or IP-enabled TV sets that may never be upgraded to support v6. At some point Dual Stack alone may not be practical anymore, because they won’t have enough addresses to support all the new subscribers who have IPv4 devices that need to be connected.”
Making matters even more difficult is the fact that not all content providers will implement a dual-address support mode on their Web sites, meaning IPv6 devices trying to access those sites will get error messages, likely followed by complaints to service provider call centers. “We need to provide consistent Internet service for customers whether they have IPv4-enabled equipment or IPv6-enabled equipment and whether the content is v4 or v6,” Donley says.
One approach to slowing IPv4 exhaust is a new version of NAT known as NAT444, which would overlay the traditional IPv4 NAT approach with a new one that employs a Carrier Grade NAT (CGN). NAT444, still in the draft stage at the IETF, retains traditional NAT for extending private addresses to devices behind a customer’s publicly addressed router while using the network-based CGN to extend private addresses to tens if not hundreds of end users from a single IPv4 address.
But use of NAT444 raises many unresolved concerns about how the technology might affect quality of service. For one thing, with multiple subscribers sharing a single public IPv4 address, there is likely to be an impact on any systems, external as well as internal, that assume an IPv4 address uniquely identifies an Internet subscriber. Externally, these would include e-mail spam monitoring systems and certain law enforcement systems. Internally, some provisioning systems operate in this fashion to support automated subscriber activation, including self service.
Moreover, the well-known complications associated with hooking up certain types of devices to premises-based NAT routers could be greatly magnified in the double-NAT environment where endpoints would be limited in their ability to negotiate port usage, notes Suddenlink’s Ballard. “As you know if you’ve implemented a small NAT router at your house and tried to get it to work with different gaming devices or Sling boxes or whatever, it’s complicated,” he says. “Take that and implement it on a scale like our 1.3 million subscribers and that’s going to get very complicated very quickly.”
Perhaps most troublesome of all, the double NAT architecture fragments the network, which complicates troubleshooting and repairs.”NAT444 is going to be an operational nightmare across our industry,” Ballard concludes.
No one else seems to like it much either. “We have suspicions NAT444 and other NAT techniques in operators’ networks will break apps,” Donley says. “We have a lot of operators testing this in their labs.”
“The problem is we don’t know how many apps it breaks,” agrees Cox’s Jason Weil. “For me the best we can do is move to Dual Stack and when IPv4 runs out do Dual-Stack Lite.”
DS Lite is another, newer transition option being worked on by CableLabs and the IETF that was first proposed by Comcast. DS Lite provides a means by which all IPv4 traffic destined for IPv6-addressed customers is delivered over stateless IPv6 tunnels between the CGN and the customer’s IPv6 gateway. This solution would require that new customers who receive IPv6 addresses be equipped with gateways that perform this tunneling, avoiding the need to implement NAT for IPv4 devices at the CPE.
As reported previously (June, p. 1) Comcast and the non-profit group Internet Systems Consortium (ISC) recently released open source Address Family Transition Router (AFTR) software to facilitate service providers’ implementation of DS-Lite. AFTR, the heart of the IPv4-IPv6 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.
Pending the outcome of trials, Comcast officials have indicated DS Lite is likely to be the MSO’s preferred approach to accommodating the addition of new subscribers once the IPv4 address supply runs out. Comcast expects to complete the transition to dual-stack operations prior to having to implement DS-Lite when IPv4 addresses run out.
A final transition methodology winning support from CableLabs at this point is IPv6 Rapid Deployment (6RD), a public tunneling solution that encapsulates IPv6 into IPv4. It uses a public IPv6 prefix to ensure that all IPv6 communications entering the operator’s local network pass through the operator’s tunneling points to reach designated users. The technology requires that CMTSs be upgraded to support encapsulation and de-encapsulation and that IPv6-addressed end users be equipped with modems or routers that do the same thing.
“6RD will help some ops who are not able to move to doc 3 fast enough to roll out v6 and still offer customers good quality of service,” Donley says. So far, he adds, lab tests conducted by operators, CableLabs and others have indicated that 6RD performs as intended.
On another front, CableLabs is working with the IETF and the Broadband Forum, the carrier standards body, to develop specifications for an IPv6 Home Gateway that would work in the Dual Stack environment on both cable and DSL networks. The draft specifications, moving rapidly toward formal adoption at IETF, support both the stateful provisioning required by CableLabs and the provisioning process known as Stateless Auto Address Configuration (SLAAC), a provisioning mode that is not used with DOCSIS. “This would be to allow similar functionality in devices customers purchase at retail,” Donley says.
For all the progress made so far, the cable industry still has a long way to go when it comes to resolving many of the technical issues surrounding transition strategies and myriad implementation details that necessarily are unique to each operator’s network and current IPv4 addressing environments. “The biggest hurdle I would say is there’s not a clear path to the edge for CPE (customer premises equipment),” Ballard says. “We have DS Lite, the eRouter, the v6 Home Gateway – a lot of different technologies that are coming up. It’s getting better and better every day, but we’re still not quite there yet.”
But, he quickly adds, MSOs can’t afford to wait until all the answers are solidified. “Waiting is not an option,” he says. “You can’t just keep playing the waiting game. You have to get out there and get your feet wet with IPv6, and you have to start all these processes immediately.”