The third in a series of blogs throughout 2025 highlighting the state of IPv6 across the industry, best practices to consider, and how Cisco is helping customers on their journeys with its products and services.
The IPv6 transition has been underway for nearly 30 years, with IPv6 traffic on the Internet now surpassing 50% by all measures [1]. Most applications and network stacks now prefer IPv6 by default, and thanks to technologies like Happy Eyeballs [2], end users in a dual-stack environment rarely notice if IPv6 fails over to IPv4. Fortunately, that failure scenario is becoming less common as the robustness of the IPv6 Internet improves and end-user networks are deployed with great confidence.
Two Broad Stages
The journey to IPv6 typically occurs in two broad stages: first, by moving from IPv4-only to a dual-stack world, where we turn on IPv6 and run both protocols simultaneously; and then gradually retiring IPv4. Traditional dual-stack deployments are often completed in what is commonly referred to as the “Inside Out” method, where the core of the network will be dual-stacked first. Once routing and operational experience are established in the network infrastructure and everything else is in place (see below), edge access switches and APs will finally enable IPv6 on their user-facing segments, providing end-users with IPv6 connectivity. Later, the transition from dual-stack to IPv6-only occurs in roughly the reverse order. 
Internet Edge and Data Centers
Before we can dual-stack our users, we must dual-stack our Internet Edge with support from our security team (who should be involved from the start!). Once the Internet Edge supports IPv6, focus shifts to the Data Centers; dual-stacking the servers allows us to begin verifying application access over IPv6 while most users continue to utilize IPv4 (with specific test users being dual-stacked). The network team and help desk should be dual-stacked so they can start experiencing the transition firsthand. (On a related note, eventually all management-plane functions of network operations can move to IPv6-only while the data-plane remains dual-stacked). Next the DMZ can be transitioned and DNS entries provided to build an Internet presence with IPv6. And finally, IPv6 can be deployed to user-facing VLANs.
NetFlow and Traffic Monitoring
Ideally, 100% of our internal applications will be IPv6 enabled and preferred. NetFlow collection of internal traffic helps monitor this, quickly identifying legacy applications for remediation (via upgrades, replacements, or front-ending with dual-stacked devices). The goal is for the only remaining IPv4 traffic on the network to be bound to the Internet. NetFlow should show that Internet-bound IPv6 traffic is steadily increasing as other organizations complete their own IPv6 transition.
DNS64 and NAT64
Once the dual-stack transition is complete and any brokenness hidden by Happy Eyeballs has been proactively identified and fixed, it’s time to incrementally remove IPv4 from the network. Fortunately, the standards bodies have defined NAT64 [3] and DNS64 [4] for just this use case. These complementary technologies allow an IPv6-only client to reach IPv4-only content, permitting the use of IPv6 as the single protocol within the network [5]. While DNS64 and NAT64 may be deployed before fully removing IPv4 to gain familiarity and experience, the real magic happens once IPv4 is gone.
IPv6-mostly and CLAT
With dual-stack and NAT64 in place, the next step is moving to an IPv6-mostly deployment, a new paradigm built on a set of technologies [6][7] that provides an easier glide path to an IPv6-only future. In IPv6-mostly, the client operating system provides its own IPv4-to-IPv6 translator known as a CLAT (customer-side translator) for applications that still have IPv4 dependencies. Whether the destination is IPv4-only or the application code uses embedded IPv4 literals, this traffic is translated into IPv6 packets across the IPv6-only enterprise network, and then back to IPv4 at the edge via NAT64. Clients are signaled to utilize IPv6-mostly on dual-stack access segments via DHCP Option 108, a DHCPv4 option that tells the client it is safe to forgo an IPv4 address and run only IPv6. Because IPv4 is still being offered, an IPv6-mostly network continues to service clients that don’t support local translation via CLAT. Now clients can choose the protocol to use based on their capabilities, rather than being forced by the network.
IPv6-only Future
As we continue to monitor network traffic with NetFlow, we should expect to see IPv6 traffic continue to steadily increase and eventually we validate there is no longer any utilization of IPv4 on certain user VLANs. That’s the time to remove IPv4 from those network segments. As more IPv4 is turned off, it can also be removed from the network infrastructure equipment. One day, in the hopefully not-to-distant future, 100% IPv6 usage will be seen at the Internet Edge and in the DMZ. Until then, NAT64, DNS64 and CLAT will continue to serve us well.
References
[1] https://blogs.cisco.com/industries/ipv6-in-2025-where-are-we
[2] https://datatracker.ietf.org/doc/html/rfc8305
[3] https://datatracker.ietf.org/doc/html/rfc6146
[4] https://datatracker.ietf.org/doc/html/rfc6147
[5] https://www.youtube.com/watch?v=_GkynY809eg
