IPv6: Dual stack where you can; tunnel where you must

IPv6 was delivered with migration techniques to cover every conceivable IPv4 upgrade case, but many were ultimately rejected by the technology community, and today we are left with a small set of practical approaches.

IPv6 was delivered with migration techniques to cover every conceivable IPv4 upgrade case, but many were ultimately rejected by the technology community, and today we are left with a small set of practical approaches.

One technique, called dual stack, involves running IPv4 and IPv6 at the same time. End nodes and routers/switches run both protocols, and if IPv6 communication is possible that is the preferred protocol.

IPv6 migration strategies

A common dual-stack migration strategy is to make the transition from the core to the edge. This involves enabling two TCP/IP protocol stacks on the WAN core routers, then perimeter routers and firewalls, then the server-farm routers and finally the desktop access routers. After the network supports IPv6 and IPv4 protocols, the process will enable dual protocol stacks on the servers and then the edge computer systems.

Another approach is to use tunnels to carry one protocol inside another. These tunnels take IPv6 packets and encapsulate them in IPv4 packets to be sent across portions of the network that haven’t yet been upgraded to IPv6. Tunnels can be created where there are IPv6 islands separated by an IPv4 ocean, which will be the norm during the early stages of the transition to IPv6. Later there will be IPv4 islands that will need to be bridged across an IPv6 ocean.

Other techniques, such as network address translation–protocol translation (NAT-PT) simply translate IPv6 packets into IPv4 packets. These translation techniques are more complicated than IPv4 NAT because the protocols have different header formats. Translation techniques were intended to be used as a last resort.

Using dual-stack and tunneling techniques is preferable to using NAT-PT.

There are two types of tunnels: manual and dynamic. Manually configured IPv6 tunneling (RFC 2893) requires configuration at both ends of the tunnel, whereas dynamic tunnels are created automatically based on the packet destination address and routing. Dynamic tunneling techniques simplify maintenance compared with statically configured tunnels, but static tunnels make traffic information available for each endpoint, providing extra security against injected traffic.

There are, in fact, concerns over the security of tunneling techniques. For example, with dynamic tunnels it isn’t easy to track who is communicating over the transient tunnels, and you don’t know the tunnel destination endpoint. It is a scary proposition when your routers communicate with other nonauthenticated routers. It is also possible to send forged traffic toward a tunnel endpoint and get traffic spuriously inserted into the tunnel. Tunneling creates situations in which traffic will be encapsulated, and many firewalls won’t inspect the traffic if it is in a tunnel. Allowing IP Protocol 41 (IPv6 encapsulated in IPv4) through an IPv4 firewall is not a best practice. This is like creating an “IPv6 permit any any all” rule through the firewall.

Tunnels will constantly have to be changed and monitored as your transition progresses. Tunnels will also have to be removed when the IPv6 ocean gets larger and we migrate to full IPv6. Tunnels are, therefore, just a transitional technique, and troubleshooting in an environment full of tunnels will be challenging.

Dynamic tunnel techniques don’t create tunnel interfaces that can be monitored with SNMP. Dynamic tunnel techniques such as 6 to 4 use 2002::/16 addresses, which means you will need to re-address the network twice as part of the transition to IPv6. Many of the dynamic tunneling techniques are also unable to forward multicast traffic and can’t traverse an IPv4 NAT in the middle of the network.

It will be easier to try to run everything in a dual-stack mode first and then remove the IPv4 protocol over time. Currently there aren’t many systems being developed for IPv6-only communications, but there are many systems that work in dual-stack mode. Microsoft’s new operating systems, for example, have a dual-layer architecture that makes for seamless operation of either protocol. Therefore, migration plans should maximize the use of dual stack and minimize the amount of tunneling. It should also be mentioned that running dual stack is not the final state. We can’t forget that full migration to IPv6 is the final destination.

In the 1990s the network industry used the phrase “Switch where you can, route where you must.” However, over time the performance gap between routing and switching closed. For IPv6 transitions the new moniker will be “Dual stack where you can, tunnel where you must.”

Hogg is director of Advanced Technology Services Global Technology Resources, Inc. You can reach him at SHogg@GTRI.com.

Join the discussion
Be the first to comment on this article. Our Commenting Policies