Change of Address: IPv6
Steady growth of high-speed Internet subscriptions and explosive adoption rates of voice over Internet protocol (VoIP) services are having positive effects on the bottom lines of firms offering these types of services. Next-generation technologies such as IPTV and IP multimedia subsystem (IMS) are expected to enable service offerings and revenue growth while presenting operators and service providers with opportunities to improve how these services are delivered.
At the heart of many of these services of today is IP, or more specifically, IP version 4 (IPv4). Limited in various ways, however, IPv4 is preparing to yield some of the stage to its successor, IP version 6 (IPv6.) What follows is an explanation of IPv6 and an overview of possible adoption paths, a look at how IPv6 relates to DOCSIS 3.0 and other network protocols, and an assessment of IPv6’s impact on systems and applications. IPv4 vs. IPv6 IP-based services seem new to many consumers; however, IPv4, the underlying protocol used to deliver these services today, is more than 30 years old. Change, nonetheless, has been in the works for several years.
In the early 1990s, the Internet Engineering Task Force started work on the next generation of IP, IPv6. Why so? Various limitations of IPv4, along with adoption rates over the past several decades, made it clear that IPv4 would not be able to satisfy the growing needs of the Internet community and organizations that intended to use IP to deliver services.
In particular, IPv4 was limited to offering about 4.3 billion IP addresses. By contrast, IPv6 provides more than 340 undecillion unique addresses! That’s roughly 3 followed by 38 zeroes, as opposed to 4 followed by nine zeroes.
Some other fundamental differences between IPv4 and IPv6 are that IPv4 addresses are 32 bits whereas IPv6 address are 128 bits, and IPv4 address are in decimal format while IPv6 addresses are in colon-hexadecimal format.
The following is an example of an IPv6 global unicast address: 2001:0DB8:0410:0001:02AA:00FF:FE3F:2A1C.
It is clear that IPv6 addresses are unlike what most are accustomed to using with IPv4 (for example, 192.168.0.1). The added length and format will certainly present challenges and catalysts for change. In addition to the format and length, there are other differences between IPv4 and IPv6 including but not limited to packet structure and address assignment mechanisms. Adoption paths The adoption of IPv6 is not intended to take place overnight. In most, if not all, cases, the adoption should take place gradually. In fact, there are several transition technologies that have been specified along with IPv6 to support its gradual adoption. This implies that IPv4 and IPv6 are likely to co-exist for the foreseeable future, perhaps decades.
Furthermore, motivations to adopt IPv6 vary from organization to organization. In most cases, the limitations associated with the IPv4 address space, as compared to the vast space provided by IPv6, offer the greatest impetus. In fact, that is one of the core motivations for the adoption of IPv6 in the cable industry.
Finally, there is a wide range of factors to account for when adopting IPv6, and the applicability of the same varies depending on the discipline and functional aspect of deployment. It is essential that these differences be clearly understood as the adoption of IPv6 evolves and progresses. This will help to ensure that the various components required for a successful deployment of IPv6 are, in fact, available.
So how are cable operators adopting IPv6? And what will be its impact on various systems and applications central to cable? Leaving aside for now both core and access network technologies, let’s turn for answers to those questions to the relationship between DOCSIS 3.0 and IPv6, to related network protocols, and to the area of systems and applications development. IPv6 and DOCSIS To meet the growing needs of the community, the cable industry has started taking the necessary steps to prepare for the introduction and adoption of IPv6. In collaboration with CableLabs, representatives from the vendor and operator communities worked together to introduce IPv6 into DOCSIS 3.0 and related specifications.
The DOCSIS 3.0 specification largely provides for the adoption of IPv6 for the management of devices that adhere to it, including but not limited to cable modems and set-top boxes. Beyond use for the management of DOCSIS devices, the introduction of IPv6 also lays the foundation for cable operators to provide subscriber services over IPv6.
Fundamentally, DOCSIS 3.0 calls for cable end-points or nodes, including but not limited to cable modem termination systems (CMTSs), cable modems and others, to adopt many of the well-known standards that define how the same interact with other elements on the network. Examples include interactions of end points or nodes with IPv6-enabled network elements, including routers; and, of course, interactions with other IPv6 end points or nodes—router and neighbor discovery, respectively.
One of the most notable aspects of DOCSIS 3.0 as it relates to IPv6 and systems is its use of stateful dynamic host configuration protocol version 6 (DHCPv6) for the assignment of IPv6 address and configuration information for management of the same over IPv6.
Stateful DHCPv6 is required to facilitate address acquisition over the use of stateless autoconfiguration, which is a feature of IPv6 that allows for the generation of IPv6 addresses by an end-point based on information contained within router advertisements. The use of stateful DHCPv6 is analogous to how pre-DOCSIS 3.0 IPv4-only networks have embraced DHCPv4 for the assignment of IPv4 addresses and configuration information.
Stateless DHCPv6 is a new feature related to DHCPv6 where only configuration information is assigned. DOCSIS specifications have not definitively specified how this technology will be applied. Furthermore, the introduction of IPv6 into DOCSIS 3.0 in addition to continued support for IPv4 allows for new operating modes for DOCSIS cable modems. These operating modes not only include the ability for modems to support initialization and management in IPv4 or IPv6 but also support alternate provisioning and dual stack provisioning modes. Alternate provisioning mode allows for a device to be provisioned or initialized in an alternate version of IP after initialization in the preferred version fails; dual stack allows for initialization and management over IPv4 and IPv6 simultaneously.
Most other protocols leveraged by DOCSIS 3.0 to support the introduction of IPv6 are not drastically different from their IPv4 predecessors. For example, the trivial file transfer protocol (TFTP), time of day (ToD) and Syslog are essentially the same underlying protocols as specified by the IETF. The main difference between the IPv4 and IPv6 versions lies in the transport that is employed. Change to the core of the respective protocols was not required to introduce support for IPv6. Network protocols As mentioned, stateful DHCPv6 is central to the initialization and provisioning of DOCSIS 3.0 devices where management or interaction with the same is desired over IPv6. Stateful DHCPv6 provides much of what DHCPv4 has and does for existing IPv4 networks, including those based on DOCSIS 1.x and DOCSIS 2.0. However, it is critical to note that DHCPv6 is not synonymous with DHCPv4; they are two separate and distinct protocols. For the same reason, it would also be inaccurate to state that DHCPv6 is simply an upgrade to DHCPv4.
Another significant and easily overlooked difference between DHCPv4 and DHCPv6 is that core DHCPv6 no longer leverages media access control (MAC) addresses to uniquely identify clients; DHCP unique identifiers (DUIDs) are used. MAC addresses and DUIDs are fundamentally different identifiers. The intention of each, however, is to uniquely represent clients in their respective versions of DHCP.
In many environments, especially cable, the presence of a MAC address is critical to be able to provision and manage subscriber services. Many processes and applications used to facilitate service delivery have been built around the use of a device’s MAC address.
The departure of DHCPv6 from the use of the MAC address introduced the potential to affect significantly the adoption of IPv6. That, in turn, had the potential to broaden the scope of changes required to systems and various back office applications to support the adoption of IPv6. Fortunately, provisions were introduced into the DOCSIS 3.0 specification to allow for the continued use of the MAC address even when devices are IPv6-enabled and using DHCPv6 to obtain IPv6 address and configuration information.
The domain name system (DNS) is technically not specified as part of DOCSIS 3.0 to facilitate the initialization, provisioning or management of DOCSIS 3.0 cable modems, regardless of IP version. However, the role of DNS as part of the adoption of IPv6 is likely to increase significantly, in part because of the complex nature and increased length of IPv6 addresses.
Unlike today, where many in operations, support or engineering capacities can easily commit many IPv4 addresses to memory, the possibility of committing even a few IPv6 addresses to memory is unlikely, if not impossible. Most, if not all, Internet users today access Web sites and other Internet resources using easily remembered names instead of IP addresses. This approach will be employed further where networks have begun or continue to adopt IPv6. In turn, the reliability, performance and scalability of DNS in this capacity are critical to support the adoption of IPv6.
DNS must also support IPv6 transport as well as the introduction of new types of resource records for IPv6, specifically AAAA (often called quad-A records) to represent host to IPv6 address mappings. Conversely, to represent IPv6 address to host mappings in DNS, pointer or PTR resource records continue to be used, as with IPv4. (See Figure 1.) The adoption of IPv6 absolutely increases the complexity associated with the management of DNS. Specifically, reverse zone creation for IPv6 prefixes and the population of the corresponding PTR records become exponentially more complicated and error-prone. (See Figure 1 on page 22.) The complexity of IPv6 addresses will certainly act as a catalyst to depart from the use of literal IP (IPv4 and IPv6) addresses in the management and operation of IP networks and the services delivered over them. To support such a shift, a manageable and robust DNS infrastructure that supports IPv6 must be in place.
Finally, the advent of IPv6-enabled cable devices of tomorrow, such as set-top boxes, may require DNS services for normal operations regardless of IP version. This further emphasizes the need for a robust DNS infrastructure to ensure that next-generation devices and services can be managed effectively. Systems and applications The makeup of strategic systems and applications used to manage and facilitate service delivery typically consists of commercially supported as well as in-house or internally developed applications.
Vendor-developed and supported applications generally require the direction of subject matter experts to define system requirements and collaborate with vendors to ensure the same are sufficiently addressed by the resulting solution. More and more, operators or providers, especially larger ones, take on the ownership and responsibility of end-to-end application or systems development. Internalizing these types of activities often requires professional staff to manage architecture, design and requirements; it also calls for technical staff from various disciplines.
Internally developed systems and applications are often naturally complex modes of gathering and manipulating data from multiple sources, which in turn act as catalysts for other systems to facilitate the management of the underlying network and ultimately service delivery. The foyer of IPv6 and adoption of the same for those responsible for internally developed and managed applications represent yet another challenge in already complicated environments.
The adoption of IPv6 for applications and systems can and is likely to have unique implications per application. Appreciation and understanding of these differences are especially important for those situations where the applications are internally developed. Improper IPv6 context could result in significant issues including but not limited to the availability of applications and systems that support IPv6. In turn, those issues could have adverse operational impacts and, even worse, impede growth.
In general, the impacts of IPv6 on systems and applications could apply to the use of IPv6 transport, the presentation of IPv6 data, and the manipulation of IPv6 data. First, as for transport, applications or end points need to communicate over IPv6. The data that is carried over an IPv6 transport can be that of IPv4 or IPv6 or unrelated to IP altogether. Second, data that is IPv6-specific, such as IPv6 addresses that have been gathered or collected over IPv4, IPv6 and/or some other means, if presented must be done in a usable format. Finally, such data may need to be manipulated or processed in an IPv6-specific manner.
Applicability of the previous points is likely to vary per application or system. The points discussed offer fundamental context that can be used to facilitate the assessment of how, if at all, the adoption of IPv6 will impact a system or application. To be continued Given how differently IPv6 will play out across various systems, as well as different parts of the network, there will be many endings to the story of IPv6 and its impact on cable.
The applicability of IPv6 on the operational support system (OSS) and network management system (NMS) infrastructure, for instance, is a question not only of the relevant standards but also of transport requirements of the same. The impact of a cable operator’s deployment strategy is a further distinguishing factor.
For now, several useful takeaways from this IPv6 overview are the motivation for its adoption rooted in the vast address space; the related uses of stateful DHCPv6 by DOCSIS; the measured differences of DHCPv6 to DHCPv4, including the departure from MAC addresses to DUIDs; the heightened role of DNS within an IPv6 deployment; and the range of implications on cable-specific systems and applications.
All in all, that makes IPv6’s adoption in cable very much a work in progress. John Jason Brzozowski is an architect and principal engineer at Comcast. Reach him at [email protected].
