In our previous tutorial, we examined a number of vendors that have implemented IPv6 capabilities on their products However, receiving the assurance from a single vendor that their product supports IPv6 is one issue, and transitioning that product to IPv6, along with those from a number of vendors that support your enterprise, may be a very different challenge.
As part of the early IPv6 development work, the Internet Engineering Task Force (IETF) recognized that a major undertaking such as the transition from IPv4 to IPv6 would require transition technologies, not just a transition strategy. In addition, no specific timeframe was mandated for such a move away from the existing IPv4. Some network managers may want to be early adopters and take advantage of the key IPv6 enhancements – such as addressing and stronger security – while others may not see the need to migrate for a long time.
However, a key underlying assumption in the transition planning is that an existing IPv4 infrastructure is presently available, and that the most immediate challenge will be transporting IPv6 packets over these existing IPv4 networks, so that isolated islands of IPv6 networks do not exist. As more networks make the transition, however, the converse may occur – the transport of IPv4 packets over burgeoning IPv6 infrastructures to support legacy IPv4 applications.
The key elements of these transition technologies are described in Basic Transition Mechanisms for Hosts and Routers, published as RFC 4213. This document specifies what is considered to be the core elements of the transition technologies, dual stack and configured tunneling. The document also defines a number of node types based upon their protocol support, including legacy systems that only support IPv4, future systems that will only support IPv6, and the dual or IPv6/IPv4 node, which implements both IPv6 and IPv4.
The Dual Stack (also known as a dual IP layer) approach is considered the most straightforward approach to transition. This method assumes that the host or router provides support for both protocols, IPv4 and IPv6, within its architecture, and thus has the capability to send and receive both IPv4 and IPv6 packets. Thus, the dual node can interoperate with an IPv4 device using IPv4 packets, and interoperate with an IPv6 device using IPv6 packets. It can also operate in one of three modes: with only the IPv4 stack enabled, with only the IPv6 stack enabled, or with both IPv4 and IPv6 stacks enabled. Since a dual stack node supports both protocols, it can also be configured with both the IPv4 32-bit addresses and the IPv6 128-bit addresses, using IPv4 mechanisms such as the Dynamic Host Configuration Protocol (DHCP) to acquire its IPv4 addresses, and using IPv6 mechanisms, such as stateless autoconfiguration, or DHCPv6 to acquire its IPv6 addresses. IPv6 implementations today are very likely dual stacks, as IPv6-only products would have very limited communication partners.
Configured Tunneling provides a way for the existing IPv4 routing infrastructure to remain functional, and also carry IPv6 traffic as an IPv6 routing infrastructure is under development. A tunnel is a bi-directional point-to-point link between two network endpoints. Data is carried through that tunnel using a process called encapsulation, in which the IPv6 packet is carried inside an IPv4 packet, which makes IPv4 appear as a Data Link Layer with respect to IPv6 packet transport. The encapsulating IPv4 header is created at the entry point of the tunnel, and then removed at the exit point of the tunnel. The tunnel endpoint addresses are determined by from configuration information that is stored at the encapsulating endpoint, hence the name configured tunnel (or also called an explicit tunnel). These tunnels can be defined to go between router-to-router, host-to-router, host-to-host or router-to-host, but are most likely to be used in a router-to-router configuration. The configured tunnel may be managed by a tunnel broker, a dedicated server described in RFC 3053, that manages tunnel requests coming from end users.
Other transition mechanisms have been defined, and may be appropriate for some network configurations. Automatic Tunneling is described in RFC 2893 (the earlier version of RFC 4213), and is a process that allows IPv4/IPv6 nodes to communicate over an IPv4 routing infrastructure without using pre-configured tunnels. The nodes that perform automatic tunneling are assigned a special type of address, called an IPv4-compatible address, which carries the 32-bit IPv4 address within a 128-bit IPv6 address format. The automatic designation results from the simple process of performing the reverse function, i.e. extracting the IPv4address from the IPv6 address.
Another automatic tunneling scheme is called 6to4, which is described in RFC 3056, Connection of IPv6 Domains via IPv4 Clouds. This process allows IPv6 sites to communicate with each other via an IPv4 network without using explicit tunnels, and for these sites to communicate with native IPv6 domains via relay routers. With 6to4, the IPv4 Internet is treated as if it were one single data link.
A proposed enhancement to the 6to4 method is another automatic tunneling technique called Teredo, which is supported by Microsoft, and defined in RFC 4380. Teredo enables nodes that are located behind an IPv4 Network Address Translation (NAT) device to tunnel packets using the User Datagram Protocol (UDP), and thus obtain IPv6 connectivity. Teredo requires the use of server and relay elements to assist with path connectivity.
The Intra-Site Automatic Tunneling Addressing Protocol, or ISATAP, is defined in RFC 4214, and is considered an experimental protocol. ISATAP is used to connect IPv6 hosts and routers over an IPv4 network using a process that views the IPv4 network as a link layer for IPv6, and other nodes on the network as potential IPv6 hosts or routers. This process acts as a host-to-host, host-to-router, or router-to host automatic tunnel.
The above list should get you started, with likely more methods to be proposed as the IPv6 technology becomes more prevalent. Our final tutorial will consider IPv6 network implementation and management issues.
Mark A. Miller, P.E. is President of DigiNet Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Implementing IPv6, and the Internet Technologies Handbook, both published by John Wiley & Sons.
Article courtesy of Enterprise IT Planet, © 2007 DigiNet Corporation, All Rights Reserved