Issue No. 03 - May/June (2003 vol. 7)
The Internet Engineering Task Force has been developing version 6 of the Internet Protocol for more than 10 years. In parallel with the protocol suite, the IETF has also built a toolkit to help ensure a seamless transition from IPv4. These tools generally fit into one of three categories:
• Tunneling. IPv6 packets are tunneled through an IPv4 network.
• Dual stack. Hosts and routers run both an IPv4 and IPv6 protocol stack.
• Translation. A gateway translates IPv4 packets to IPv6 packets (and vice versa).
IPv6 does not provide any better (or worse) support for quality of service than IPv4, but it does have many features you might already be familiar with, including larger address space, integrated security capabilities, easier configuration, and a simplified packet header format.
The Internet's ubiquity, coupled with the pending exhaustion of IPv4 addresses, gives IPv6 a legitimacy and inevitability that we can't ignore. IPv6 supports 340 undecillion (340 × 1036) unique IP addresses, which translates to approximately 6.5 × 1024 unique addresses per square meter of Earth. Contrast that with the 4 billion addresses in the IPv4 realm, and we can be confident that we won't face an address exhaustion problem with IPv6 anytime in the foreseeable future.
IPv6 implementations are available across the spectrum of hardware and software products for carriers, enterprises, and consumers. (A survey of IPv6 products and implementations is at http://playground.sun.com/ipng/ipng-implementations.html.) The protocol's use is mandated in next-generation mobile wireless standards. Networks that offer IPv6 connectivity are already popping up around the globe; NTT currently offers a dual-stack service in Japan, for example (www.ipv6style.jp/en/news/2003/0313_ntt.shtml). IPv6 stacks are already embedded around us (as in Microsoft XP;www.microsoft.com/windowsxp/pro/techinfo/administration/ipv6/) — often in places we don't even realize (for instance, Sony Playstation 2 supports a dual protocol stack; www.gamemarketwatch.com/news/item.asp?nid=1279). I could go on, but you can easily search on IPv6 and find hundreds of resources. And that proves my point: IPv6 has finally arrived.
Rather than covering well-tread ground, the IEEE Internet Computing editorial board thought it would be useful to examine the hurdles on the road toward an IPv6 Internet. Regardless of our roles in this industry — whether hardware engineers, network architects, application developers, microcode programmers, or technical writers — we will all encounter such challenges as we move forward. The theme features assembled for this issue help light the way by sharing the experiences of some of those at the vanguard of the IPv6-migration movement.
In the first article, "A Scenario-Based Review of IPv6 Transition Tools," Mackay and colleagues leverage their experience running 6Net, one of Europe's largest IPv6 research networks. They analyze the applicability of different transition tools on ISP, mobile wireless, corporate, and small- medium-business/residential networks. This article offers an excellent survey and a practical perspective on potential transition strategies that network planners can employ when IPv6 comes knocking.
Given that IPv6's integrated security functions require the use of a public key infrastructure, its significance in future networks cannot be overstated. A PKI is used to manage the distribution of public key certificates to entities that wish to communicate securely over the Internet using the IP security protocol (IPsec),1 which is a mandatory feature of IPv6. RFC 2460 states that a "full implementation of IPv6" includes implementation of the authorization header (AH) and encapsulating security payload (ESP).2 Indeed, many attach greater significance to these integrated authentication and encryption features than to IPv6's expanded addressing capabilities.
In "PKI Services for IPv6," Skarmeta and colleagues describe their efforts to modify a PKI to support IPv6 networks. The article presents a high-level overview of an existing PKI implementation and then offers a detailed analysis of the necessary modifications. The focus is on the Java Cryptographic Architecture/Extensions (JCA/JCE), an HTTP-over-IPv6 implementation, and a servlet API with an IPv6-enabled HTTP server. The authors conclude with a valuable discussion of PKIs' applicability in static and dynamic virtual private networks (VPNs) — precisely the IPv6 application that PKI will enable.
In "Porting the Session Initiation Protocol to IPv6," Robles, Ortiz, and Salvach�cument their experiences with a publicly available open-source SIP library.3 The authors outline their efforts to analyze the code, apply the modifications to port it to IPv6, and fix bugs. An exemplary case study on IPv6 porting, this article presents a valuable indication that the object-oriented paradigm can simplify the process of generating code that works on both IPv4 and IPv6 networks.
In the final theme article, "Evaluating IPv6 on Windows and Solaris," Zeadally and Raicu compare the performance of IPv4 and IPv6 implementations on the Windows and Solaris operating systems. Their results are consistent with the prevailing notion that IPv6 stacks will need to be optimized as their implementation density increases and applications rely on them for maximum performance. This article presents an ideal first snapshot of what needs to work now and in the future.
Grown-up IPV6 Community
The history of networking over the past 10 or 15 years is rife with conflict. Egged on by competing interests, proponents of various network architectures, protocols, and products have stridently denounced one another — creating headlines and lively conference panels, but little agreement.
In the IPv6 community, however, there is a sense of calm. Proponents know their day will come, and they are working hard so that the torch can be passed quietly amid little fanfare; one future day we will wake up and read that the majority of the billions of IP-addressable end points on the planet are running IPv6. The following articles attempt to illuminate the road we must travel.
I thank the authors for their outstanding contributions to this special issue, the others whose articles were left out due to space constraints rather than quality issues, and the many anonymous reviewers who contributed their time and expertise.
Chris Metz is a technical leader in the Service-Provider Engineering Group at Cisco Systems. Metz is author of IP Switching: Protocols and Architectures (McGraw-Hill, 1999) and coauthor of ATM and Multiprotocol Networking (McGraw-Hill, 1997). Contact him at firstname.lastname@example.org.