The looming exhaustion of IPv4 address space at the Regional Internet Registries (RIRs) in 2012 will pressure organizations to develop IPv6 migration strategies. The myriad of transition technologies–including NAT64, 6rd, and DS-Lite–are daunting to network designers and support staff. Many articles and posts on the Internet point to dual stack–the coexistence of IPv4 and IPv6 on a host–as the ideal method for implementing IPv6. While I applaud those who contribute to IPv6 adoption by enabling their network for IPv6, network engineers could do more to help the community by planning for an IPv6-only infrastructure.
What’s wrong with dual stack? The configuration represents 1999′s solution for IPv6 migration. If a critical business driver for IPv6 had emerged that year, vendors, carriers, and enterprises would have banded together to bring IPv6 into the mainstream. Unfortunately, that’s not how IPv6 adoption has progressed. Now that we are nearly depleted of IPv4 addresses, dual stack is less appealing.
Dual stack does not solve the IPv4 exhaustion problem. When the RIR exhaustion happens for your region, you will turn to IPv4 transfer markets for new addresses. To provide an indicator of IPv4 valuation, last year Microsoft purchased over 666,000 IP addresses from Nortel for $7.5M USD, or $11.25 per address. Rather than investing in IPv4, companies should include at least some IPv6-only hosts in their migration efforts. Don’t double down on NAT by deploying NAT444 (a.k.a. Large Scale NAT), a two-layered NAT solution that introduces numerous operational and user experience problems.
Dual stack introduces challenges for your operations group. In the NOC, service assurance increases in complexity, as engineers must troubleshoot unexpected interactions between IPv4 and IPv6. Staffing needs increase as engineers are supporting what I’ll call “2 x” efforts. The engineers potentially could be handling two routing protocols, two packet data protocol (PDP) contexts/bearers in mobile networks, and two sets of documentation. The “2 x” work also applies to provisioning, deployment, and performance management.
Another issue in dual stack deployments is that protocol selection can be pushed to the application layer to cope with broken or degraded IPv6 connectivity. The Happy Eyeballs Internet Draft describes an algorithm for applications to choose between IPv4 and IPv6 with the goal of improving the user experience. IPv6-only configurations obviate this layer violation.
In IPv6-only environments, network designers need a mechanism for hosts to reach IPv4 content. NAT64 combined with DNS64 solves the problem (for a detailed technical description of NAT64 see Scott Hogg’s Network World article). NAT64 is not only theory; the technology is live on production networks. T-Mobile USA uses NAT64/DNS64 for its public IPv6 beta. Other wireless and wireline carriers are in the process of testing or implementing NAT64.
The need for IPv6-only deployments is not understood by our extended community (including application and OS developers). You can experience the resulting problems firsthand by attempting to install any Linux distribution with an IPv6-only connection. You’ll see strange failures like the attempt to resolve AAAA records over IPv4 transport. My offer to help the maintainers of one distribution improve IPv6 support in the installer and network configuration application received a quizzical response –”The 2.6 kernel has IPv6 support. What are you talking about?” I was not surprised, as little operational experience exists with IPv6-only. Bugs and missing functionality go unnoticed.
IPv6 advocates are becoming increasingly vocal on IPv6-only deployment. People such as Jari Arkko (Ericsson), Irene Nikolova (Google) and Cameron Byrne (T-Mobile USA) are spreading the message on IPv6-only in the IETF, Internet forums, and speaking engagements. Some great ways for others to get involved include participating in the IETF v6ops mailing list, asking your hardware and software vendors about IPv6-only deployments, and encouraging OS and application developers to remove dependencies on IPv4 connectivity.
IPv6-only is the sole, long-term solution. Getting to this end state will require more operational experience with IPv6-only deployments. Don’t settle for dual stack. Go IPv6-only and share your experiences with the community.