There is no single "IPv6 migration button." Instead there are three transition mechanisms, and the skill is knowing which one to reach for in a given situation. Dual-stack, tunneling, and translation each solve a different shape of problem, and picking the wrong one turns a clean migration into a fragile mess. This article is the decision guide that ties together the hands-on work from the rest of the series into one framework you can apply on real networks. It is part of the PingLabz IPv6 routing and services guide and connects to the broader IP routing fundamentals.
Three mechanisms, three different problems
Before choosing, be clear about what each mechanism actually does. Dual-stack runs IPv4 and IPv6 in parallel on the same devices and links, so every host and router speaks both protocols natively. Tunneling wraps IPv6 packets inside IPv4 (or the reverse) so that traffic of one protocol can cross a network that only forwards the other. Translation (NAT64 with DNS64) converts between the two protocols at a gateway so a host that speaks only one can talk to a host that speaks only the other. Those are three genuinely different operations: running both, carrying one inside the other, and converting one into the other. Match the operation to your constraint and the decision makes itself.
Dual-stack: the preferred end state
Dual-stack is the goal, not a bridge. When a device is dual-stacked, it has an IPv4 address and an IPv6 address on its interfaces, participates in both an IPv4 and an IPv6 routing table, and simply uses whichever protocol a given destination needs. Nothing is encapsulated, nothing is translated, and no application breaks, because both protocols are genuinely present end to end. Applications increasingly prefer IPv6 when it is available (the "happy eyeballs" behaviour in modern clients) and fall back to IPv4 seamlessly.
Every router in the lab for this series is dual-stacked, which is what let us run IPv6 IGPs, build tunnels, and configure NAT64 all on the same devices. That is the point: dual-stack is the foundation you build the other mechanisms on top of. The only real costs are operational: you run two protocols, so you maintain two sets of routing, two sets of ACLs, and two sets of security policy, and you must not let the IPv6 side lag behind the IPv4 side in hardening (an under-secured IPv6 stack on a dual-stack device is a classic blind spot). Choose dual-stack whenever you control both ends and can enable IPv6 everywhere along the path. It is the destination; the other two mechanisms exist only to get you there or to cover the gaps you cannot yet close.
Tunnels: carrying IPv6 islands over an IPv4 core
Sometimes you have IPv6 running at the edges but a core in the middle that is IPv4-only and cannot be upgraded yet (a provider network, a legacy WAN, a segment behind someone else's change freeze). Tunneling bridges those IPv6 islands by encapsulating their traffic in IPv4 so the core forwards it as ordinary IPv4, oblivious to the IPv6 payload inside. Both endpoints still speak native IPv6, so from the application's perspective nothing changed; only the transport across the gap differs.
We proved a manual IPv6-over-IPv4 tunnel in the tunnels article, carrying real IPv6 pings across an IPv4-only path at 100 percent success. The practical guidance from that work carries into the decision here: use a point-to-point tunnel (manual or GRE) when you have a known pair of endpoints, prefer GRE when you want to run an IPv6 IGP across the tunnel because GRE carries the multicast that OSPFv3 and EIGRP for IPv6 need, and avoid 6to4, which is automatic but deprecated. Remember the golden rule of tunnels: the underlay must be able to reach both endpoint addresses, and an up/up tunnel that will not pass traffic is almost always an underlay routing or MTU problem, not an IPv6 one. Tunnels are a bridge, deliberately temporary, that you keep until you can dual-stack the core and take them out.
Translation: an IPv6-only side reaching IPv4-only content
The hardest case is when one side genuinely does not speak the other protocol at all. An IPv6-only client network needs to reach an IPv4-only server, and there is no shared protocol to dual-stack and no way to tunnel because the client has no IPv4 stack to encapsulate. This is where translation, NAT64 paired with DNS64, is the answer. NAT64 rewrites IPv6 packets as IPv4 (and back) at a gateway, and DNS64 synthesises the IPv6 address the client uses to trigger that translation.
We walked the full mechanism in the NAT64 article, including the synthesized-address math and the honest note that the data-plane translation did not complete on the control-plane simulator we used. For the decision here, the key point is positioning: translation is a last resort, not a design goal. It is stateful, it introduces a choke point, and it quietly breaks applications that embed IP literals in their payloads. Reach for NAT64 and DNS64 specifically when you have an IPv6-only client network that must reach the legacy IPv4 internet or IPv4-only internal systems, and you cannot make those systems dual-stack. In every other situation, one of the first two mechanisms is a better fit.
The decision tree
Put the three together and the choice reduces to a short set of questions about what you control.
Dual-stack
Tunnel
Translation (NAT64+DNS64)
Read the tree as a sequence of questions. Can you control both ends and enable IPv6 along the whole path? Then dual-stack, and you are done. Do you have IPv6 islands separated by an IPv4-only core you cannot change? Then tunnel across it (GRE if you want dynamic routing, manual for a simple static pair). Is one side genuinely IPv6-only and the other genuinely IPv4-only, with no way to add the missing protocol? Then, and only then, translate with NAT64 and DNS64. Dual-stack is the goal; tunnels and translation are the bridges you use until you get there.
How these combine in a real migration
In practice you rarely pick just one. A realistic migration dual-stacks everything you can reach, tunnels IPv6 across the parts of the core you cannot yet upgrade, and stands up NAT64 for the pockets that are IPv6-only but still need IPv4 content. Over time the tunnels come out as the core gets dual-stacked, and the NAT64 footprint shrinks as more content becomes reachable over native IPv6. The direction of travel is always toward dual-stack (and eventually IPv6-only with less and less need for translation), with tunnels and translation as scaffolding you remove as the building takes shape. Thinking of them as scaffolding rather than as permanent fixtures keeps your design honest and keeps you from leaving fragile translation gateways in the path longer than necessary.
Security across the transition
Each mechanism carries its own security consideration, and the transition period is exactly when blind spots appear. On dual-stack, the biggest risk is an unhardened IPv6 stack: teams pour years into IPv4 ACLs and firewall rules and then bring up IPv6 with permissive or missing policy, handing attackers a wide-open second door into the same hosts. Treat the IPv6 control and data plane as a first-class citizen, matching every IPv4 protection with an IPv6 equivalent. On tunnels, remember that encapsulation can smuggle IPv6 straight through IPv4 inspection points that do not understand protocol 41 or GRE; protect any tunnel that crosses untrusted ground with IPsec, and filter rogue tunnels at the edge so users cannot build their own unsanctioned paths out of your network. On translation, the NAT64 gateway is a stateful choke point and therefore a denial-of-service target: its state table can be exhausted, so size it and rate-limit accordingly, and log translations for the same accountability reasons you log IPv4 NAT.
Common mistakes when choosing a mechanism
The most frequent error is reaching for translation when dual-stack was available. NAT64 is genuinely necessary only when one side cannot run the other protocol at all; if you could have enabled IPv6 on both ends, translation just added a fragile, app-breaking choke point for no reason. The second common mistake is treating tunnels as permanent. A tunnel is scaffolding for an IPv4-only core you have not upgraded yet, and every tunnel you leave in place is overhead, an MTU liability, and one more thing to troubleshoot; plan its removal from the day you build it. The third mistake is forgetting DNS: NAT64 without DNS64 does not work in practice because clients have no way to learn the synthesized address, and dual-stack deployments frequently trip over DNS resolvers that return IPv6 records before the IPv6 path is actually ready, causing timeouts that look like network faults. Get DNS behaviour right and half of your transition surprises disappear. Match the mechanism to the constraint, keep dual-stack as the destination, and treat everything else as temporary, and the migration stays under control.
Key Takeaways
- There are three IPv6 transition mechanisms, each for a different problem: dual-stack (run both), tunneling (carry one inside the other), translation (convert one into the other).
- Dual-stack is the preferred end state. Use it wherever you control both ends and can enable IPv6 along the whole path; nothing breaks because both protocols are genuinely present.
- Tunnels carry IPv6 islands across an IPv4-only core you cannot upgrade. Prefer GRE for dynamic routing, manual for a static pair, and avoid deprecated 6to4. Both ends still speak native IPv6.
- Translation (NAT64 + DNS64) is the last resort, for an IPv6-only client reaching IPv4-only content. It is stateful and breaks some applications, so use it only when you cannot dual-stack or tunnel.
- The decision tree: control both ends and can enable v6, dual-stack; v6 islands over a v4 core, tunnel; IPv6-only to IPv4-only, NAT64 and DNS64. Dual-stack is the goal, the others are bridges you remove over time.
This closes the IPv6 routing and translation series. Revisit the deep-dives on IPv6-over-IPv4 tunnels and NAT64, or head back to the IPv6 guide for the full cluster.
