Transition Mechanisms for Dual-Stack Networks

Audience: network architects, cloud engineers, and isp6 members planning a network that runs IPv6 alongside (or in front of) an existing IPv4 estate. Covers the full spectrum from "IPv4 only with carrier-grade NAT" to "IPv6 only with stateless translation back to legacy v4 services" and the trade-offs between every step in between. Assumes familiarity with IPv6 addressing fundamentals; if scopes, /64s, and SLAAC are unfamiliar, start with Designing the Next Internet: An Introduction to IPv6.

Last updated: May 2026

1. Introduction

The Internet did not switch over from IPv4 to IPv6 on a flag day. It is transitioning gradually, and the operational reality of the next decade is a network that has to do both, sometimes in parallel, sometimes by translating between them, and sometimes by tunnelling one inside the other. The set of techniques that make this possible has grown into a small alphabet soup: dual-stack, NAT44, CGNAT, NAT64, DNS64, 464XLAT, DS-Lite, MAP-T, MAP-E, SIIT-DC, and most engineers come into a deployment unsure which of them applies to which problem.

This article maps the alphabet to the problem. Each mechanism solves a specific shape of "I have IPv4 here and IPv6 there and I need them to talk" problem, and choosing the wrong one can be expensive: a stateful translator where a stateless one would do, a tunnel where direct routing was already an option, or a CGNAT layer that breaks the next round of cloud services. The goal is to leave you with a clean mental model of which mechanism belongs in which architectural position.

The framing is from an isp6 member's perspective: you hold a portable IPv6 PA allocation that you announce from your own ASN, what should sit alongside it, in front of it, or behind it during the years that some of your traffic still needs to talk to IPv4-only systems?

The arc above is roughly the path most networks travel, although not every network visits every box, and many sit in two of them at once for years.

2. Why Transition Mechanisms Exist

The fundamental constraint is that IPv4 and IPv6 are not directly interoperable. An IPv6-only host has no native way to send a packet to an IPv4-only server, because the source and destination address fields are different sizes, the headers are different, and even the wire format is different. The two protocols have to be bridged, translated, encapsulated, or tunnelled.

The need for a transition mechanism comes from one of three pressures:

Almost every architectural decision below traces back to which of those three pressures dominates the design.

3. The Dual-Stack Baseline

Dual-stack is the simplest possible "transition": the host, the router, the firewall, and the DNS resolver all run both protocols at once. An interface has an IPv4 address and an IPv6 address simultaneously; applications use the operating system's address-selection rules (RFC 6724) to choose between them on a per-destination basis.

3.1 What Dual-Stack Costs You

Dual-stack is the most operationally honest mechanism, because the network is what it appears to be, and there is no translation magic. The cost is everywhere:

• Two routing tables, two firewall rule sets, two ACLs, two DNS records per service, two monitoring dashboards.
• Two attack surfaces. Anything reachable on IPv4 is also reachable on IPv6 if the firewall posture is not symmetric, a frequent source of incidents during the early dual-stack rollout.
• Two flavours of every operational issue. "It works on IPv4 but not on IPv6" is a daily helpdesk question for the first year.

3.2 What Dual-Stack Buys You

The simplicity is genuine: there is no translator in the data path, so there is no NAT64 prefix to debug, no DNS64 record to reason about, no MAP-T mapping rule to chase down. For an enterprise with a stable IPv4 estate that is adding IPv6, exactly the use case for an isp6 PA allocation, dual-stack is the right starting position.

The intent is that dual-stack is temporary. Eventually IPv4 retires, the v4 stack is disabled, and the network becomes v6-only. The remaining mechanisms in this article are all about what happens between "everything runs both" and "everything runs only v6".

4. Stretching IPv4: NAT44 and CGNAT

These two mechanisms exist because IPv4 ran out of public addresses, not because IPv6 needs anything from them. They are IPv4 survival tools, and their relevance to an IPv6-aware design is mostly the negative space they create: places where end-to-end connectivity is broken and where IPv6 deployment is the cleaner answer.

4.1 NAT44 (Basic Network Address Translation)

The familiar home-router pattern: an internal RFC 1918 network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) shares a single public IPv4 address. The router rewrites source addresses on outbound packets and maintains a translation table to send replies to the right inside host.

NAT44 is rarely positioned as a "security feature" any more, see Misconception 3: NAT Is a Security Feature. It is a workaround for address scarcity, full stop.

4.2 CGNAT / LSN / NAT444

Carrier-Grade NAT, also called Large-Scale NAT or NAT444, is what an ISP deploys when it cannot give every subscriber a public IPv4 address. The subscriber's router NATs to a non-routable address space (typically 100.64.0.0/10 per RFC 6598), and the carrier NATs that to a public address shared across thousands of subscribers. RFC 6888 captures the requirements.

The relevance of CGNAT to an isp6 deployment is usually a single observation: if your egress traffic is going through a CGNAT, your application's source address is shared with thousands of strangers, and you cannot accept inbound connections. The native IPv6 path bypasses CGNAT entirely, and that is one of the reasons IPv6 enables architectures (peer-to-peer, mesh VPNs, direct cloud endpoints) that CGNATed IPv4 does not.

5. Reaching Back: NAT64 and DNS64

This is the first mechanism that solves an IPv6-side problem rather than an IPv4-side one. The setting: a host on a v6-only network needs to reach a service that has only an IPv4 address. The native protocols cannot bridge that gap; NAT64 and DNS64 do it together.

5.1 NAT64 (RFC 6146)

NAT64 is a stateful translator that sits at the boundary of a v6-only network. It allocates a /96 IPv6 prefix, typically the well-known 64:ff9b::/96 from RFC 6052, and embeds the destination IPv4 address in the last 32 bits of an IPv6 address inside that /96.

A v6-only client sending traffic to 64:ff9b::192.0.2.1 is sending IPv6, but the NAT64 translator extracts the embedded IPv4, opens an IPv4 session on its outside interface, and bridges the flows.

NAT64 alone is not enough. The v6-only host still needs to find the embedded IPv6 address, and that is what DNS64 provides.

5.2 DNS64 (RFC 6147)

DNS64 is a recursive resolver that synthesises AAAA records when the authoritative DNS only returns A records. The flow:

1. v6-only host queries legacy.example.com for AAAA.
2. Authoritative DNS has no AAAA, only A returning 192.0.2.1.
3. DNS64 resolver intercepts the empty AAAA response, takes the A record, and synthesises a fake AAAA: 64:ff9b::192.0.2.1.
4. The host receives the synthesised AAAA, sends IPv6 traffic to it, and the NAT64 gateway translates.

The synthesised address has no real existence in DNS. It is a runtime construction that exists only because the DNS64 resolver knows the NAT64 gateway is configured for 64:ff9b::/96.

5.3 Where NAT64 + DNS64 Belongs

Cloud providers offer this pairing as a managed service: AWS calls it DNS64 and routes traffic via the NAT Gateway; Azure does it similarly via Virtual Network NAT; GCP exposes the same pattern via Cloud NAT. The reason is the same in all three: a customer wants to run an IPv6-only VPC for cleanliness but still has a long tail of v4-only third-party APIs to call. NAT64 + DNS64 makes that workable until the tail dries up.

If you are bringing your isp6 PA allocation to a cloud provider, see AWS, Azure, or Google Cloud, NAT64 + DNS64 is the mechanism most likely to appear in your reference architecture.

6. Surviving Legacy Apps on v6-Only Access: 464XLAT

NAT64 + DNS64 covers most v6-only-to-v4-only traffic, but it has a known failure mode: applications that hard-code IPv4 addresses or use IPv4 socket APIs. These apps never query DNS for AAAA records and never see the synthesised address; they just open a socket to an IPv4 literal and fail on a v6-only network.

464XLAT (RFC 6877) solves this by adding a second translator at the customer edge:

The application sees IPv4 sockets, the access network is v6-only, and the PLAT (NAT64) at the edge of the carrier sees the same flow it would have seen had NAT64 been the only mechanism. The CLAT does stateless NAT46, which means it scales linearly without per-flow tables.

464XLAT is the answer to "we want a v6-only access network but [insert legacy app] still expects v4". For an isp6 enterprise member this usually applies inside a corporate campus network rather than at the WAN edge, but the pattern is the same.

7. Operator-Scale Mechanisms: DS-Lite, MAP-E, MAP-T

These three are designed for carriers. They assume the operator runs an IPv6-native backbone and has to ration scarce IPv4 across many subscribers. For an isp6 enterprise member they are usually background context rather than something you deploy directly, but understanding them helps when an ISP's WAN behaviour seems mysterious.

7.1 DS-Lite (RFC 6333)

The subscriber CPE gives the home network an RFC 1918 IPv4 address. v4 traffic is encapsulated in IPv6 (IPv4-in-IPv6, protocol 4) and tunnelled across the carrier's v6-only backbone to a centralised translator called the AFTR (Address Family Transition Router), which performs stateful NAT44 to a public v4 address. The subscriber never has a public v4 address; they share one with hundreds of others at the AFTR.

7.2 MAP-E (RFC 7597)

Mapping of Address and Port, Encapsulation. Solves DS-Lite's centralised-state problem by pre-allocating each subscriber a slice of an IPv4 address shared with N siblings, typically a fixed range of source ports, derived algorithmically from the subscriber's IPv6 prefix. The carrier no longer needs to keep per-flow state because the mapping rule deterministically tells every router which subscriber owns which port. v4 traffic is encapsulated in v6 the same way DS-Lite does it.

7.3 MAP-T (RFC 7599)

Mapping of Address and Port, Translation. Identical addressing model to MAP-E but translates v4 ↔ v6 instead of encapsulating. Stateless, algorithmic, and easier to debug than MAP-E because the wire packets at every hop look like the protocol they appear to be.

MAP-T is generally considered the most architecturally clean of the three, being stateless, free of encapsulation overhead and deterministic, and is increasingly the operator default for v4-as-a-Service over a v6-native backbone.

8. Stateless Translation in the Datacentre: SIIT-DC

RFC 7755 defines SIIT-DC: Stateless IP/ICMP Translation for Datacentre use. The setting: an IPv6-only datacentre that needs to serve a public-facing service to the IPv4 internet without polluting its internal addressing with v4 anywhere.

A SIIT-DC border router holds a public IPv4 address per externally-visible service. Inbound v4 traffic is statelessly translated to IPv6 by embedding the source v4 address into a known /96 inside the operator's IPv6 space; the v6 backend sees a clean v6 packet with an unambiguous source. Outbound v6 replies are translated back to v4 by the same stateless algorithm.

SIIT-DC is the cleanest endgame for an IPv6-only datacentre: the internal network is unburdened by IPv4, and the v4 surface is a thin, stateless edge. It is more relevant for service operators with an isp6 PA allocation behind a public-facing platform than it is for typical enterprise members.

9. The Tunnels Era: 6to4, Teredo, 6in4

Before native dual-stack was widely available, IPv6 islands were connected through tunnels over the IPv4 Internet. These mechanisms are mostly historical now, since most have been deprecated or are heavily filtered, but they still appear occasionally in legacy networks and exam questions.

For an isp6 member whose ISP is still v4-only, a 6in4 tunnel, or a modern WireGuard tunnel between sites, is the practical bridge until the upstream turns on native IPv6. It does not depend on isp6 in any way; the isp6 allocation is announced from whichever endpoint terminates the tunnel.

10. Choosing a Strategy

There is no single right answer. The mechanism follows from the shape of your problem, not the other way around. The matrix below maps the most common architectural starting positions to the mechanisms that fit them.

Wherever possible, prefer dual-stack first, native v6 second, translation last. Translators add operational surface area: a NAT64 gateway is a stateful piece of kit that must be sized, monitored, and made redundant; DNS64 synthesised records are awkward with DNSSEC; 464XLAT adds a second translator. None of this is a reason not to use them, and sometimes they are the only realistic path forward, but they are not free.

11. What isp6 Handles vs. What You Configure

Transition mechanisms operate at layers above the address allocation, so the isp6 boundary is straightforward. You bring your own architecture; isp6 provides the v6 address space the architecture sits inside.

If you deploy NAT64 with a network-specific /96 instead of 64:ff9b::/96, the /96 must come from inside your isp6 allocation. A /48 contains 65,536 /64s and can therefore comfortably reserve a /96 for translation use without straining the rest of the addressing plan; see Planning Your isp6 Allocation for how to fit it in cleanly.

12. Further Reading

• The protocol foundations. Designing the Next Internet: An Introduction to IPv6: what dual-stack is layered on top of.
• Why NAT is not a security feature. Misconception 3: NAT Is a Security Feature: the half of the NAT story most engineers internalise wrongly.
• Sizing the allocation around translators. Planning Your isp6 Allocation: where to put a network-specific NAT64 /96 inside your /48 or /44.
• Bringing your isp6 allocation to a cloud provider. AWS · Azure · Google Cloud. Each has a managed NAT64 + DNS64 offering.

13. References

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.