Don’t kill yourself over IPv6

With IPv6 now being widely supported by most major vendors, the implementation and transition over to it is accelerating (or will soon). This can be exciting, and concerning, to many network administrators and engineers. What options are available to help in this transition? How do they help and how easy are they to implement? These are good questions for anybody in this situation to be asking.

So, what are the options?

There are three main transition option groups: dual stack (running both IPv4 and IPv6 at the same time), tunneling (using a technology to “tunnel” through one protocol to get to another; e.g. from IPv6 through IPv4 to another IPv6 network), and translation (converting IPv4 traffic to IPv6, and vice versa).

1.       Dual stack

Many companies choose to initially use dual stack since it’s easy to implement and doesn’t typically affect any of the IPv4 servers or hosts. The only thing you need to make this work is IPv6 supporting routing equipment (which most vendors support), and IPv6 support on the selected IPv6 supporting devices.

2.       Tunneling

Of course, the problem with this is that if the internal networking infrastructure is complex, the addition of IPv6 support could take some time and considerable planning to ensure no collateral effect. In these situations, a tunneling transition technology can be very handy. For example, if you only wanted two internal LAN networks within an organization to begin support for IPv6, you could create a tunnel between them, or just one out to the IPv6 internet with changes only required on the local host devices or the routing device.
Tunneling is also a very common technology that is used to bridge bigger networks together (for both IPv4 and IPv6) without exposing internal network information. If a company wanted to support IPv6 on its internal networks but not on its internet connections, it could choose to tunnel IPv6 traffic between internal company sites over a public IPv4 network.

3.       Translation

The third option is IPv4 to IPv6 translation. This should be a familiar concept to most networking people because this type of technology is often used to translate between internal private IPv4 address ranges and pubic IPv4 address ranges, to access the internet.
IPv4 to IPv6 translation isn’t quite so simple. The problem isn’t really the basic translation between an IPv4 and an IPv6 address, which is rather simple (Using NAT64).  The problem is when a network host attempts to perform Domain Name System (DNS) look-ups (or some other application look-ups).
For example, if an internal IPv6 host wanted to go to a website, it would initially put in a Fully Qualified Domain Name (FQDN). This would result in a DNS lookup of that name. While it’s common for most internet websites to have IPv4 DNS records, the existence of an IPv6 DNS record isn’t so common.

DNS64

Because of this problem, technologies like DNS64 have been created. DNS64 provides you with the ability to look initially for an IPv6 DNS record. If one does not exist, it has the ability to create an IPv6 DNS record from an existing IPv4 DNS record on the fly. This ability, along with a supporting NAT64 device (the technology that provides IPv4 to IPv6 address translation), enables a reasonably seamless network experience when only IPv4 options are available from an IPv6-only device.
The networking community as a whole has done a good job of getting on top of the issues that have and do exist in the transition between IPv4 and IPv6.