IPv6: Ready when you are

When the Internet was growing exponentially, so was the fear that its address space would quickly be exhausted because of the limitations of its 32-bit address space. Anticipating these and other concerns, the Internet Protocol Next Generation (IPng) working group of the Internet Engineering Task Force (IETF) began codifying solutions to a number of problems inherent in Internet protocol version 4 (IPv.4).

Disappearing act
By the end of 1998, Internet protocol version 6 (IPv.6) was accepted as a draft standard. As that milestone approached, expectations arose that the Internet would rapidly migrate to this new technology. That migration has not occurred for two primary reasons: - There is very little end-user (i.e., application) demand for IPv.6; therefore, infrastructure providers have no economic incentive to build out an IPv.6 infrastructure. Rather, the primary benefits of IPv.6 accrue at the network management level, in areas such as interdomain routing, network configuration, end-to-end security and address space management. - Fears about imminent IP address depletion have been exaggerated. Nevertheless, Asia (especially China) is currently experiencing significant difficulty with IP address allocations. Europe's IP address space issues are somewhat less pressing, but still of concern, especially as mobile, third-generation (3G) networks proliferate. In contrast, there is a general sense of complacency about these issues in the United States. Given the lack of a bona fide "crisis" in IP address space depletion or a "killer app" that would require use of IPv.6, the remainder of the technology's benefits has been insufficient to drive this technology into the mainstream. Therefore, IPv.6 has largely (and justifiably) "dropped off the radar screen" of U.S. enterprises, although it has become a strategic priority in Europe and a pressing issue in Asia.

NAT: A false sense of security
Further inhibiting the adoption of IPv.6 has been ability of the network industry to develop compensating technologies for IPv.4's shortcomings. Foremost among those is network address translation (NAT).

Analogous to private branch exchanges (PBX) in the telephone world, enterprises use NAT to overcome a limited allocation of IP addresses and to simplify the process of reconfiguring data networks. NAT greatly simplifies both, but introduces two serious, long-term issues:

• NAT's address translation architecture makes it very difficult to implement end-to-end, packet-level security in transactions. At best, Secure Sockets Layer (SSL) and HTTP/S provide partial solutions to this problem.
• As enterprises expand or merge networks, the cumulative effort/expense required to support and administer various NAT devices increases significantly. Equally important, these expenses are recurring, and thus add substantial, undesirable operating overhead to network infrastructures. Thus, the long-term viability of NAT as a workaround to address space and network management issues is problematic.

The lesser of two evils
As problematic as NAT has become, that solution is preferable to the largely unknown and unproved benefits that IPv.6 offers today. The migration to IPv.6 within an enterprise requires not only a number of investments, but some leaps of faith, as well. Some network hardware components will be software-upgradeable, but many others, such as firewalls, hubs, and switches, will not. Those items for which there are IPv.6-compliant versions will be more expensive than their IPv.4 counterparts until high-volume production reduces their price.

The limited availability of network components and technical expertise amplifies these issues. It takes considerable expertise to build IPv.4-to-IPv.6 tunnels--which are often needed--not only to interconnect dispersed enterprise network segments, but to connect the enterprise itself to an IPv.6-capable backbone. Also at issue is the limited availability of native IPv.6 facilities, which can be acquired from a few larger Internet service providers (ISPs), but have yet to become generally available from smaller regional or local providers.

Software is not the problem
IPv.6 also requires upgrades to application and communication software. IPV.6 protocol stacks are available for most commercial operating systems. Windows offers IPv.6 application programming interfaces for developers and will provide production versions of IPv.6 in upcoming releases of Windows XP.

By 2004, IPv.6 support in Windows will enable most off-the-shelf programs to operate natively using this protocol (0.8 probability). Upgrading custom-written software will not require wholesale rewrites, as was the case with year 2000 compliance. Rather, changes to current applications will be isolated to network interface routines, and can be undertaken during routine software maintenance cycles. This may represent a substantial undertaking or enterprises with many or complex network-aware applications.

Despite the lack of demand for IPv.6, considerable progress has been made in fleshing out the standards for key supporting technologies. Currently, more than 40 adopted, draft, and informational standards are being used to guide IPv.6 product development and implementation efforts. The 6BONE was established in 1996 by the Next Generation Transition (NGtrans) workgroup of the IETF. Overseen by NGtrans, major backbone and equipment providers have collaboratively implemented a functioning IPv.6 test bed. Enterprises can connect to the 6BONE via a participating ISP. The most common means of interconnecting is to create a six-to-four tunnel from an enterprise to the 6BONE. A six-to-four tunnel will connect IPv.4 routers and resolve IPv.4-to-IPv.6 addresses. IPv.6 addresses are available from a pseudo top-level aggregator (p-TLA); some of these are Tier 1 ISPs.

The Internet2, a university/industry high-speed Internet consortium, also offers native IPv.6 connectivity to its members. Given the long lead times necessary to develop new equipment, the major network equipment suppliers have been steadily releasing, refining, and deploying IPv.6-compliant products in major backbone providers and ISPs. Leading backbone providers and ISPs continue to accumulate experience in deploying and operating blended IPv.4 and IPv.6 networks.

Back from the dead
Given the NAT workaround, IP address space depletion in the United States will not become a significant driver for IPv.6 adoption until 2007 (0.7 probability). However, China faces daunting problems as it attempts to configure its national infrastructure using today's highly fragmented address space.

The Japanese government also sees IPv.6 as a strategic imperative and is providing tax incentives to accelerate the testing and deployment of native IPv.6 networks throughout the country. These moves can be traced to the entirely correct belief that the explosion of wireless and network-connected home entertainment devices will soon inhibit Internet deployment throughout Asia. For example, the next generation of Sony's PlayStation will run IPv.6 and IPv.4 natively through a dual-stack implementation.

Bottom line:
The proliferation of Internet-connected wireless and consumer devices will steadily increase the pressure for enterprises to adapt their networks and enterprise applications to run over IPv.6. Europe and Asia will lead the U.S. by two to three years in IPv.6 deployment. Enterprises that build systems with embedded Internet connectivity should plan their product development accordingly. Similarly, enterprises should develop a long-term IPv.6 deployment plan for their in-house and global networks.