Why Your Network Should Go IPv6 Only

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.


  1. Jason Gardiner says

    We are running dual-stack like many providers.  One of my goals is to deploy a IPv6-only site some time this year.  I’ve been looking at the different technologies to do so and have been largely disappointed in the support for doing so.  NAT64/DNS64seems to be the currently preferred method (over NAT-PT) but there are very few tools out there.  I was never able to get Ecdysis to behave correctly.  Tayga has been better. 

    • says


      I’m glad you pointed out tools. These are critical in operationalizing NAT64/DNS64. Although NAT64/DNS64 is a solution, it is still middleware that breaks the end-to-end principle and introduces another component for Ops to troubleshoot.

      I was not aware of the Tayga project. If you’ve tested DNS64 implementations using Tayga for the NAT64 piece, please share your thoughts and recommendations.

      Jeff L.

  2. Cb says

    I believe NAT64 is a native part of OpenBSD PF now. There are also commercial solutions from Cisco, juniper, a10, f5, and Brocade. Isc bind, nominum, and
    secure64 all have support of dns64.

  3. says

    I agree with Jeff. As the 1990’s wrapped up, so did the multi-protocol IP/IPX/AppleTalk networks that preceded it. There was a clear push to move all applications to IPv4, in order to simplify the network and standardize on a common protocol. There wasn’t fear about IPX address depletion or AppleTalk end-of-life, but a pure simplification of the network and the components on the network that make it all work.

    Right now, we’re missing that driver as a motivation to get to IPv6. With the exception of some global customers that I run into who are seeing the push to v6 in Asia, most are taking a laid back approach that they’ll continue to run 1918 address space internally and just focus IPv6 at the Internet edge, or go dual stack if absolutely pushed. The problem is, there are still too many applications out there that are IPv4 only (including net mgmt platforms), that still provide too much fuel for the instinctive resistance to go full IPv6. Even going purely v6 at home is a non-option, due to application dependencies on v4. There needs to be the same push from customers to simplify … to be IP version agnostic, in order to gain momentum and complete the transition, IMO.

    • Ktokash says

      There’s a difference between v4 -> v6, and the IP-only push of the late 90s.  IPv4 doesn’t suck nearly as much as IPX (I never worked with Appletalk, but from the CCNA/CCNP stuff I studied it seemed fairly bad as well).  Sure there are a few things here and there I’d like to change with v4, but the reality is no one would change if we weren’t running out.

      • says

        Agreed … to the extent that IP doesn’t have much of the chattiness (if I can use that word) that IPX/AppleTalk/DECnet had. Part of the driver for the original move to unify around IPv4 was to get away from the more broadcast intensive protocols (I don’t miss implementing SAP filters on my routers) to IP. 

        Netware and IPX was better/faster at file and print services until customers pushed for better performing IPv4 variants.I also agree that if v4 had adequate address space today, we wouldn’t be having the conversation about v6. Like with any technology, there is a lifespan for everything. Unfortunately, IPv4 didn’t anticipate the growth that it would have, and we’re reaching (or have reached) the end of it’s useful life. Vendors and customers have a decision to make: become IP version agnostic, or contribute to the frenzy that’s coming when the last of the RIR’s are depleted and v4 address space becomes either extremely expensive, or impossible to obtain altogether.

  4. Alxxthegeek says

    What do you do when you work for a uni and they are not planning to look at ipv6 for another 5 years and are actively blocking its use around the campus ?

    When the senior network engineer says there is no need for ipv6 here.

    Mostly alcatel, with some older cisco gear and new HP switches

    • says


      Our role as IPv6 advocates is not an easy one. In my work, I’ve seen mid to senior-level level engineers perform amazing work in advancing IPv6 within their respective organizations. Continue to explain the technical issues with IPv4 depletion and the business continuity concern. The facts give credence to your position.

  5. Matej Gregr says

    NAT64/DNS64 will break everything except web browsing. Are you sure, that you can provide connection to your customers, where they cannot use Skype, AOL or games? Will these customer pay for that service? I really doubt so.

      • says


        I believe your statement is overly broad. NAT64 will break some applications; however, the user experience may be better than you think. We should be focusing our efforts on educating application developers and working within the community to address NAT64 challenges. As more and more traffic shifts to IPv6, we can gradually return to a transparent, end-to-end service model.

        The alternative is NAT444. 

      • says


        I believe your statement is overly broad. NAT64 will break some applications; however, the user experience may be better than you think. We should be focusing our efforts on educating application developers and working within the community to address NAT64 challenges. As more and more traffic shifts to IPv6, we can gradually return to a transparent, end-to-end service model.

        The alternative is NAT444. 

        • Wes Felter says

          Jeff, DS-Lite breaks fewer apps than NAT64; I’m surprised you didn’t know/mention this.

          I sort of understand why mobile carriers are saying “la la I can’t hear you” about DS-Lite, since it would take them years to get the B4 functionality into mobile OSes, but for enterprise or residential wireline networks I think DS-Lite is the superior option.

          • Tore Anderson says

            None of the major consoles (PS3, Xbox, Wii) support IPv6, for example, so I agree that wireline ISPs pretty much have to support dual-stack on the LAN side for quite some time.

            That said, there are some clear benefits to making the ISP’s access network IPv6-only – reduced complexity and recovering public IPv4 addresses, for starters. I disagree, however, that DS-Lite is the superiour option for such ISPs, as it includes a stateful centralized NAT44 function (the AFTR). Neither the ISP nor the subscriber has any benefit from centralized NAT44.

            I believe that 4RD (tunneling) or dIVI-PD (dual translation) are both better options for such ISPs than DS-Lite. They are both stateless and do not have any centralized NAT44, and may optionally provide IPv4 address sharing (by stealing bits from the TCP/UDP port space).

  6. Merrill Hammond says

    I have been slowly preparing my workplace network with IPv6 running dual-stack for now, and started thinking what I would have to do to go IPv6 only.  Along with NAT64, I ran into another big problem.  I can’t PXE boot on a single desktop, laptop, or server over IPv6.  Considering in our environment we do a LOT of reimaging, this will keep me from removing IPv4 from my subnets for a while.

  7. Wes Felter says

    I agree that mobile carriers shouldn’t try to bear the cost of two PDPs; that’s why in theory they can run IPv6-only over the air and use DS-Lite (which is completely tunneled over IPv6).

  8. Derrik Pates says

    My home network is IPv6-enabled, but there are so many devices (like my A/V receiver, TiVo, XBox 360 and PlayStation 3) that still require IPv4 connectivity. I’d have to do separate VLANs, which would negate the benefits of having the hardware on the same network (for things like video/audio streaming and mDNS discovery). Dear vendors: START SUPPORTING IPv6 ALREADY.

Leave a Reply

Your email address will not be published. Required fields are marked *