IPv4-to-IPv6 Transition Strategies: Tunneling Approaches
(Part 2 of 3)
By Tim Rooney
Director, Product Management, BT Diamond IP

This article, excerpted from a white paper of the same name, is being presented over three issues of 6Sense and reviews the three primary migration technologies that can be used to transition from an IPv4 network to an IPv6 network. In February's issue we talked about Dual Stack. In this issue, we'll overview Tunneling. Then, in the April issue, we will discuss Translation. Click here to download our IPv6 Toolkit, which includes the full IPv4-to-IPv6 Transition Strategies white paper in addition to webinars on IPv6 management.

When we discuss migration, we're referring to an initial state of an IPv4-only network, which IPv6 nodes and networks are added to or overlaid over time, resulting in an IPv6-only network, or, more likely, a predominantly IPv6 network with continued IPv4 support.

Tunneling Approaches
A variety of tunneling technologies has been developed to support IPv4 over IPv6, as well as IPv6 over IPv4 tunneling. These technologies are generally categorized as configured or automatic. Configured tunnels are predefined, whereas automatic tunnels are created and torn down "on the fly." We'll discuss these two tunnel types after reviewing some tunneling basics.

In general, tunneling of IPv6 packets through an IPv4 network entails prefixing each IPv6 packet with an IPv4 header (Figure 1). This enables the tunneled packet to be routed over an IPv4 routing infrastructure. The entry node of the tunnel, whether a router or host, performs the encapsulation.¹ The source IPv4 address in the IPv4 header is populated with that node's IPv4 address and the destination address is that of the tunnel endpoint. The protocol field of the IPv4 header is set to 41 (decimal) indicating an encapsulated IPv6 packet. The exit node or tunnel endpoint performs decapsulation to strip off the IPv4 header and route the packet as appropriate to the ultimate destination via IPv6.

Tunnel types
While the process of tunneling is the same for all types of tunnels, there is a variety of scenarios based on defined tunnel endpoints. Probably the most common configuration is a router-to-router tunnel, depicted in Figure 2, which is the typical approach for configured tunnels.

In this figure, the originating IPv6 host on the left has an IPv6 address of W (for simplicity and brevity for now). A packet² destined for the host on the far end of the diagram with an IPv6 address of Z is sent to a router serving the subnet. This router (with an IPv4 address of B and an IPv6 address of X) receives the IPv6 packet. Configured to tunnel packets destined for the network on which host Z resides, the router encapsulates the IPv6 packet with an IPv4 header. The router uses its IPv4 address (B) as the source IPv4 address and the tunnel endpoint router (with an IPv4 address of C) as the destination address, which is depicted beneath the IPv4 network in the center of the figure. The endpoint router decapsulates the packet, stripping off the IPv4 header and routes the original IPv6 packet to its intended destination (Z).

Another tunneling scenario features an IPv6/IPv4 host capable of supporting both IPv4 and IPv6 protocols, tunneling a packet to a router, which, in turn, decapsulates the packet and routes it natively via IPv6. This flow and packet header addresses are shown in Figure 3. The tunneling mechanism is the same as in the router-to-router case, but the tunnel endpoints are different.

The router-to-host configuration, as shown in Figure 4, is also very similar to router-to-router tunneling. The originating IPv6 host on the left of the diagram sends the IPv6 packet to its local router, which routes it to a router closest to the destination. The serving router is configured to tunnel IPv6 packets over IPv4 to the host, as shown in the figure.

The final tunneling configuration is one that spans end-to-end, from host-to-host. If the routing infrastructure has not yet been upgraded to support IPv6, this tunneling configuration enables two IPv6/IPv4 hosts to communicate via a tunnel over an IPv4 network as shown in Figure 5. In this example, the communication is IPv4 from end–to-end.

Tunneling summary
Table 1 summarizes the applicability of tunneling based on the source host capabilities/network type and the destination address resolution and network type. The green-shaded cells in the table indicate use of a native IP version from end-to-end. Any intervening networks of the opposite protocol must be either tunneled through via a router-to-router protocol or translated at each boundary using a translation technology discussed in the next section. The yellow-shaded cells indicate a tunneling scenario, including configured tunnels. The arrow symbol represents a transition point or tunneling endpoint within the network that converts the corresponding native protocol to a tunneled protocol or vice versa. The red-shaded cells indicate an invalid connection option via tunneling. However, translation technologies could be employed to bridge these gaps.

Next issue of 6Sense: Translation Approaches. Click here to download our IPv6 Toolkit, which includes the full IPv4-to-IPv6 Transition Strategies white paper in addition to webinars on IPv6 management.

1. The tunnel encapsulator endpoint must also manage the resulting tunneled packet size with respect to the tunnel's maximum transmission unit (MTU) or packet size, and inform the source if the packet is too large to tunnel.
2. This packet is identified in the figure as the red rectangle beneath the originating host displaying the packet's IPv6 source address of W and destination address of Z.