IPv6: Assessing Transition Technologies

In our previous tutorial, we examined a number of
vendors that have implemented IPv6 capabilities on their
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

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

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
. 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

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
, that manages tunnel requests coming from end users.

Other transition mechanisms have been defined, and may be
appropriate for some network configurations. Automatic
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

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

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

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.

Author’s Biography

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
, and the
Internet Technologies Handbook
, both published by John
Wiley & Sons.

Article courtesy of Enterprise IT Planet, © 2007 DigiNet Corporation, All Rights Reserved

Latest Articles

Follow Us On Social Media

Explore More