Like it, or lump it, we’re going to have use both IPv6 and IPv4 on our corporate networks and the Internet for years to come. Here’s how we can do it.
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. And, while Leslie Daigle, Chief Internet Technology Officer for the Internet Society, admitted at a June 2009 meeting that IPv6′s “lack of real backwards compatibility for IPv4 was [its] single critical failure,” crying over spilt standards isn’t going to help us now. No, instead we have to make the best of using IPv6 in an IPv4 world.
How? It depends on what your network and operating system vendors offer. You may not know it, but almost all vendors already have a variety of solutions in place. You must — I can’t emphasis this enough — must test IPv6-to-IPv4 component interoperability before deploying them. Let’s take a look at the options.
IPv4/IPv6 approaches usually take one of two forms. One is dual stack, where your network hardware ends up running IPv4 and IPv6 at the same time. The other is to “tunnel” one protocol within another. Usually, this means taking IPv6 packets and encapsulating them in IPv4 packets. Their technical basics are outlined in the RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers.
There are other methods as well. For example, there’s Network Address Translation – Protocol Translation (NAT-PT). Like the name says, in this method an additional device translates IPv6 packets into IPv4 packets.
Dual-stacking and tunneling are going to be your main choices. Both come with advantages and disadvantages.
With this method, your computers, routers, switches, and other devices run both protocols, but IPv6, if it works, is 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 the enterprises’ edges earlier.
The advantage of this approach is that Dual-IP stacks are supported by all the major operating system and network vendors. The downside is that many 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.
Dual Stack Application Level Gateway
A related problem is that some versions of older network programs, such as File Transfer Protocol (FTP), won’t work with IPv6 addresses. That’s where Dual-Stack Application Level Gateway (DS-ALG) comes in. This gateway acts as a proxy that translates between the two protocols over the IPv4 Internet.
There are several downsides to this method. First, it will only work for specific applications and it will also slow traffic down as every packet has to be inspected to see if it needs DS-ALG services.
Network Address Translator – Protocol Translator
Another approach is to set up a table where an IPv6 switch has all useful IPv4 addresses mapped within it. As you might guess, this can increase network latency because of the time spent updating these tables and giving packets new addresses on the fly. In addition, NAT-PT also requires ALGs to resolve application-level issues that arise from those IP address translations.
IPv6 over IPv4 tunneling
In tunneling, one protocol is carrying inside another. Typically, that’s going to be IPv6 in IPv4. These tunnels can move your IPv6 packets across both your internal IPv4 WAN and the Internet, which will stay primarily IPv4-based for years to come. Another way to think about this technology is to consider it as tunnels between IPv6 islands with IPv4 seas in the way. Eventually, as IPv6 becomes dominant, we’ll start to see IPv6 tunnels carrying IPv4 traffic across IPv6 seas.
There are two types of tunnels: manual, aka static, and dynamic. Manually configured IPv6 tunneling requires configuration at both ends of the tunnel. As you can already tell just from the sound of it, this manual approach is not an ideal solution for businesses looking to keep networking costs down. 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. On the other hand, manually set up static tunnels make it possible to track traffic from endpoint to endpoint. This in turn makes static tunnels more secure.
Dynamic tunnel technologies are becoming dominant. Businesses would rather deal with the security headaches of dynamic tunneling tomorrow than pay for static tunnel maintenance today.
The most popular 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 (which has nothing to do with the Chicago song “25 or 6 to 4“), is that it’s lets you set up Ipv6/V4 tunnels without jumping through a lot of configuration hoops. The actual traffic 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.
So what’s a CIO to do? Well, at this point, 6to4 tunneling looks to be the easiest path to take. It also has the advantage of having wide vendor support even down to inexpensive commercial off-the-shelf equipment.
However, 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’s all too easy to mix and match equipment and methods in ways that will slow your network down to a crawl. Do you want to explain to your CEO why no one could reach the Internet from the corporate intranet for a week? I didn’t think so.
Related Information From Dell.com: Intelligent Infrastructure: The IT You Already Own — But Smarter