Five ways for IPv6 and IPv4 to peacefully co-exist

It would have been so easy if the early Internet and TCP/IP network designers had made IPv6 backward compatible with IPv4. They didn't. In 1981, IPv4's 32-bit 4.3 billion addresses look more than enough addresses for the ARPANet/Internet. That was the Internet then, this is the Internet now.

Oh, network professionals saw the Internet address shortage coming and knew it would be a problem. I can't do better than to quote, Leslie Daigle, Chief Internet Technology Officer for the Internet Society, who admitted at a June 2009 meeting that "IPv6's lack of real backwards compatibility for IPv4 was [its] single critical failure." It's too late now to cry over spilled standards. We need to work on getting the two fundamental network standards to peacefully co-operate today.

There are several ways of handling this issue. Let me warn you right now, none of them are perfect, but one, or more of them, should work for your company. Before buying into any of these technologies though you must throughly test Ipv6-to-IPv4 and back again component interoperability before deploying them. There's a lot that go wrong, and you don't want any of it happening during business hours on your production network.

IPv4/IPv6 co-existence can take one of three forms.. One is dual stack, where your network hardware runs IPv4 and IPv6 simultaneously. Next is when you "tunnel" one protocol within another. Usually, this means taking IPv6 packets and encapsulating them in IPv4 packets. The technical basics for these are outlined in the RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. Finally, there's Network Address Translation-Protocol Translation (NAT-PT) aka RFC-2766. This works just like the name says, software or a device translates IPv6 packets into IPv4 packets.

While Network Address Translation (NAT) fans might like this at first glance, it comes with its own set of problems. As Cisco points out in its excellent white paper, "Network Address Translator-Protocol Translator," "The application of each area must be well understood, as the protocol does not represent a generic mechanism that would be universally applicable." In short, you'd better know your way around Application Level Gateways (ALG) if you plan on deploying NAT-PT.

In addition, a core difference between NAT-PT and IPv4 NAT is that address translations must be done for both incoming and outgoing traffic. This can get complicated in a hurry. You could use static, bi-directional mapping, but that will get out of date quickly and it doesn't scale worth a damn. Of course, you could use Domain Name System (DNS), but old-style DNS servers don't support IPv6's AAAA records. And, again, I see real scaling problems as those DNS servers that do support IPv6 get constantly bombarded by address requests.

With Dual-IP stacks, your computers, routers, switches, and other devices run both protocols, but IPv6 will be the preferred protocol. A common procedure is to start by enabling both TCP/IP protocol stacks on the wide area network (WAN) core routers, then perimeter routers and firewalls, followed by your data-center routers and finally the desktop access routers. As the public Internet transitions to IPv6, your network administrators may need to deploy dual-stack capable switches on your; edges earlier.

The upside of this approach is that Dual-IP stacks are supported by all the major operating system and network vendors. The downside is that most legacy networking hardware and servers don't support IPv6. This can lead to such problems as dual-stack edge switches running into DNS (Domain Name Server) problems while users are trying to get to various Internet sites. In addition, many versions of Internet applications, even such commonplace ones as File Transfer Protocol (FTP), won't work with IPv6.

One way to answer these problems is to use Dual Stack Application Level Gateways (DS-ALG) These gateways are commonly used as proxies that translates between the two protocols over the IPv4 Internet.

The bad news with this approach is that it will only work for specific applications. It also has the potential to slow traffic down as every packet has to be inspected to see if it needs DS-ALG services.

In tunneling, one protocol is carrying inside another. Usually, that's going to be IPv6 in IPv4. These tunnels can move your IPv6 packets across both your internal IPv4 WAN and the mainly IPv4 Internet, Someday, when IPv6 becomes the top Internet protocol, we'll use IPv6 tunnels to carry IPv4 traffic.

There are two kinds of tunnels: manual, aka static, and dynamic. Manually configured IPv6 tunneling requires configuration at both ends of the tunnel. The manual approach is best just for connecting say corporate IPv6 intranets over the Internet. It's not a good answer to any other IPv6 Internet problem.

Dynamic tunnels use a variety of techniques to establish packet destination address and routing on the fly. This makes them far easier to create and maintain. I

The most popular dynamic tunneling technique is 6to4. It has the advantage of not requiring an explicit tunnel set-up. Instead, it uses dedicated relay routers to forward encapsulated IPv6 packets over IPv4 links. A significant advantage of 6to4, is that it lets you set up Ipv6/V4 tunnels without requiring a lot of manual effort. 6To4 uses IPv4 unicast to create point-to-point links over the IPv4 backbone for transmission.

To be used safely, your vendor and network engineers must be sure to set its security up carefully. It's all too easy to hide bad traffic inside the encapsulated packets and to spoof addresses within the IPv4 and IPv6 headers, which can lead to Denial of Service (DoS) attacks.

These are some of the most popular ways to get IPv6 and IPv4 on the same network. There are many others. Want to know what the worst news about all of them is? None of them are very compatible with the others. As I've said before, like it or lump it you are going to need to move to IPv6.

In the meantime, you're almost certain to need one, or more, of these technologies in the next few years. Again, Before deploying any IPv4/IPv6 bridging solutions, you're going to need to spend a lot of time having your network engineers and vendors making sure that everything in your new network stacks can interoperate. It' all too easy to mix and match equipment and methods in ways that will slow your network down to a crawl.

I will also add that you must test out the hardware and software before signing off on it. I've already found that a lot of stuff, which says it's IPv6 ready isn't really, but that's a story for another day.