NAT64 and DNS64: Running an IPv6-Only Network

An IPv6-only network is a genuinely simpler network: one address family to plan, one set of firewall rules, no dual-stack routing table doubling in size. The obstacle is that a large fraction of the internet still answers on IPv4 only. NAT64 and DNS64 solve exactly that problem as a pair — the resolver synthesises AAAA records pointing into a translation prefix, and the translator converts those IPv6 flows into IPv4 on the way out. This guide covers the deployment decisions that determine whether it works in practice, drawing on the operational experience documented in RFC 7269.

The two mechanisms, and why they must agree

DNS64 is a resolver that, when asked for a hostname that has an A record but no AAAA record, returns a synthetic AAAA address created by prefixing the IPv4 address with a configured prefix — normally the well-known prefix 64:ff9b::/96, or a network-specific prefix (NSP) when you want to control routing yourself. NAT64 is the translator that receives packets addressed into that prefix, extracts the embedded IPv4 address, and translates the flow to IPv4. The prefix must be identical on both, or clients will receive synthesised addresses the translator does not own.

Design decisions before deployment

Well-known prefix or network-specific prefix? The well-known prefix is simple and requires no IPv6 routing changes, but because it is globally defined it may be filtered or have special meaning elsewhere. A network-specific prefix costs you a routable range but gives you control over the traffic path and lets you place the translator where the traffic actually flows.

Where does the translator sit? Put it where the IPv4 breakout happens. In mobile and access networks NAT64 often serves as the default gateway for all IPv6 traffic, which means it must have both IPv6 and IPv4 configured on its internet-facing side — traffic to dual-stack servers is forwarded through it rather than translated, since DNS64 only synthesises when no AAAA exists.

DNS64 placement and load balancing. Because DNS64 controls the address returned, it is also the place to steer clients to different translators: synthesise the AAAA with different prefixes on different resolvers and you have per-translator load balancing without touching the clients.

Configuring DNS64 in BIND

// named.conf.options
options {
    dns64 64:ff9b::/96 {
        exclude {
            // do not synthesise for destinations that should stay native
            2001:db8::/32;
        };
        clients { any; };
        mapped { any; };
        break-dnssec yes;
    };
};

The exclude clause matters more than it looks: without it, an operator that wants a specific dual-stack service to use its native AAAA path can be forced through the translator. break-dnssec is required because a synthesised AAAA invalidates the DNSSEC chain of the original answer — document that trade-off, because it is the single most common objection to DNS64 from security teams.

Operating it: what breaks and how to tell

# verify synthesis is happening as designed
dig AAAA www.example.org @10.0.0.53
dig A www.example.org @10.0.0.53

# check the translator's state on Linux with Jool or tayga
jool instance display
jool stats display
cat /proc/net/nf_conntrack | grep -c "ipv6"   # translation table pressure

Three failure signatures are worth memorising. First, applications that use IPv4 literals instead of hostnames will bypass DNS64 completely and fail — that is what 464XLAT exists to fix, so any environment with hardcoded IPv4 addresses should deploy the CLAT component alongside. Second, a website that is reachable via the translator but broken for its IPv4-only content endpoints is often a dual-stack server issue: when a host has both A and AAAA, DNS64 returns the real AAAA and no translation happens, which is correct behaviour and occasionally surprising. Third, asymmetric or failed translation shows up as TCP handshakes that complete but stall on data — check MTU and the translator's path MTU handling before blaming the application.

Scale the translator deliberately: stateful translation keeps per-flow state, so size the table and the CPU budget against the connection rate, not just throughput, and run translators in a redundant pair with DNS64 pointing at both prefixes so a translator failure is a re-resolution, not an outage.

Address plan and prefix choice in detail

The synthesised address tells the translator what to do, so the prefix is not a cosmetic choice. Three options exist and each has consequences for routing, troubleshooting and the security posture.

If you operate more than one translator, the prefix is also your traffic-engineering tool: give each translator its own NSP, and let different resolvers synthesise different prefixes so the load is distributed without touching clients. Document the mapping, because the next engineer looking at an address that begins with a non-global prefix needs to know instantly whether it is a translation artefact or a misconfiguration.

Failure modes and what each looks like on the wire

Total failure to reach an IPv4-only site. Check the resolver first: query for A and AAAA separately. If the AAAA answer is not synthesised, DNS64 is misconfigured or excluded. If it is synthesised but the connection hangs, the translator's prefix does not match the one the resolver used — the packet is routed somewhere that will not translate it.

Partial failure: handshake completes, data stalls. Classic path MTU problem. Translation changes packet sizes and ICMPv6 handling; a translator that does not generate or forward the right "packet too big" messages leaves a black hole for large segments.

Some applications fail, others work. Applications that resolve names succeed; applications with hardcoded IPv4 literals bypass DNS64 entirely. This is the case 464XLAT is designed for, and the fix is not a resolver tweak.

# end-to-end sanity tests
dig AAAA ipv4only.example.org @10.0.0.53      # expect a synthesised AAAA
dig A    ipv4only.example.org @10.0.0.53
ping6 64:ff9b::c000:0201                       # translator reachability
curl -6 -v http://ipv4only.example.org/        # application-level test

# translator side (Jool example)
jool instance display
jool stats display
cat /proc/net/nf_conntrack | wc -l              # translation table pressure

Sizing, logging and security

Stateful NAT64 keeps a translation entry per flow, so capacity planning has to be about connection setup rate and table size, not just throughput. Two numbers decide whether the translator survives peak: how many concurrent flows it can track, and how quickly it can create and expire entries. Watch for a rising count in the conntrack table alongside falling free memory — that is the translator starting to drop flows under load, and it manifests to users as timeouts that appear random.

Logging deserves deliberate attention because NAT64 breaks the traditional log correlation between address and subscriber: with translation, one IPv4 address maps to many IPv6 clients over time, so an IPv4-side log entry is useless without the translation record. Export the translator's logging with the IPv6 source, the translated source port and a timestamp good enough to correlate, and keep it as long as your legal retention requires. And because DNS64 synthesises against DNSSEC signatures, plan how you will explain the break-dnssec trade-off to whoever owns security review — it is a legitimate trade-off, but it must be a documented decision rather than a surprise.

FAQ

Can I skip DNS64 and use static mappings? Yes for a small, fixed set of destinations — the translator supports explicit IPv6-to-IPv4 bindings. It does not scale, and it defeats the purpose of a name-based internet.

Does NAT64 work for inbound connections from IPv4? No. NAT64 as deployed is client-initiated: an IPv4 host cannot open a connection to a synthesised address without a static mapping. Services that must be reachable from IPv4 need dual-stack or a reverse proxy.

What happens to my IPv4-only monitoring tools? They will not work over IPv6; plan to migrate monitoring to the IPv6 side or to a dual-stack management network before the transition, not after.

Is 464XLAT required? It is required wherever applications use IPv4 literals or the IPv4 socket API exclusively. If your environment is fully name-based and modern, the CLAT can be skipped — but audit before deciding, because a single legacy application with a hardcoded address will fail.

Migration sequence for an existing dual-stack network

• Phase 1 — resolve first. Add DNS64 to the resolver alongside existing AAAA answers, and verify that the synthesis path returns addresses in the prefix you control. No traffic uses it yet, and the resolver change is reversible in one step.
• Phase 2 — translator in place. Bring up NAT64 in the same prefix and confirm the translator answers for the synthesised addresses, with a test client configured to use it manually.
• Phase 3 — pilot clients. Move a small group of hosts to IPv6-only (or disable their IPv4 default route) and verify their application set. This phase always finds something: a hardcoded IPv4 literal, an agent that only speaks IPv4, a monitoring check that pings an IPv4 address.
• Phase 4 — routing simplification. Only after the pilot group is stable should you start removing IPv4 routes and DHCP scopes. Each removal is a small, reversible step.
• Phase 5 — IPv4 retained only at the edge. The end state is IPv4 nowhere except the translator and any explicitly dual-stack service, which is the configuration with the fewest moving parts and the clearest failure model.

Keep the rollback available throughout: a client that still has an IPv4 address can be moved back by re-enabling its IPv4 default route. Environments that remove IPv4 everywhere at once lose that option and discover their exceptions during an outage instead of during a pilot.

Related Reading

Related reading: NAT64 and 464XLAT: Running an IPv6-Only Network, DS-Lite: Running IPv4 over an IPv6-Only Access Network, IPv6 Address Planning for Enterprise Networks

原文链接：https://datatracker.ietf.org/doc/rfc7269