For most enterprises, an IPv6-only target is the right strategy: address management gets simpler, some “legacy” weight in network design lifts, and you align better with the modern cloud/edge world. But the practical reality is this: IPv4 dependencies don’t disappear overnight.
NAT64/DNS64 here isn’t an “infinite temporary fix”; it produces value as a controlled bridge: IPv6-only clients can reach IPv4-only targets, and you manage the transformation in pieces.
1) NAT64 and DNS64: who does what?
- DNS64: A client asks for the AAAA of a domain. If the destination has no IPv6, DNS64 produces a synthesized AAAA (with the NAT64 prefix).
- NAT64: Takes the IPv6 traffic from the client, translates it to the destination’s IPv4, and manages the return path.
If these two don’t run together, deploying NAT64 alone leaves the question “where will DNS find it?” unanswered.
2) When does it make sense? (and when doesn’t it?)
Sensible scenarios:
- Some services in the internal network are IPv4-only, but you want to make the client network IPv6-only.
- You want to make IPv6 the standard in a data center / campus / overlay network.
- You need a temporary access bridge before the application team can ship IPv6 support.
Risky/wrong scenarios:
- Network traffic is heavily stateful and has a “fixed source IP” expectation (some license/allowlist worlds).
- Protocols use “IP literals” (clients that never look at DNS).
- DNSSEC validation behavior and split-horizon are complex (this needs design).
3) Design: minimum viable architecture
The model I’ve seen as the most stable in the field:
- At least two NAT64 nodes (HA) + healthcheck
- A NAT64 prefix standard (clearly published internally)
- DNS64 enabled only on specific client segments (a phased rollout)
- Logs/metrics: NAT64 state, translation errors, top domains
3.1 Where should NAT64 sit?
Principle: NAT64 should be near “egress,” but it shouldn’t be a “single point.”
- Campus/branch: at the edge (centralized NAT64) can raise latency
- Data center: placing it in the core gives a more balanced result
The operational goal: NAT64 should not be a “hidden” component during an incident.
4) Operational runbook: what do you check when something breaks?
4.1 Symptom: an IPv6-only client can’t reach some sites
- Is the domain returning AAAA? Is DNS64 synthesis happening?
- Is DNS64 active only on that segment?
- Is the NAT64 node healthy? (CPU/state/packet drop)
- Is the destination’s IPv4 reachable? (routing/ACL)
- Is there an MTU/PMTUD problem? (common when there’s a tunnel/overlay)
4.2 Symptom: some applications work, others blow up
These are usually applications that “don’t use DNS” or that use “IP literals.”
- Are there IP literals in the app’s config?
- Is a proxy/agent doing its own DNS resolution and behaving differently?
4.3 Symptom: a security/allowlist complaint (source IP)
NAT64 presents the source IP from a NAT pool to the destination side.
- Is the NAT64 pool defined on the allowlist side?
- Is the NAT64 pool static, or dynamic?
- Is this dependency planned, or temporary?
5) Monitoring: manage NAT64/DNS64 with “metrics,” not with “the eyeball”
The minimum metric set I recommend:
- NAT64:
translations_active,translations_failed,icmp_errors,conntrack_usage - DNS64:
synth_aaaa_total,synth_aaaa_ratio,dns_errors_total - Operations: “top domains via NAT64” (which dependencies are still IPv4-only?)
These metrics expose the real state of the IPv6-only migration: which services are still tied to IPv4?
6) Migration strategy: build the bridge so you can take it down one day
The value of NAT64/DNS64 lies in making the migration possible. So answer these from day one:
- Which services are IPv4-only? Who owns them?
- Is there a target date for IPv6 support?
- Which critical domains are routed through NAT64?
- Is the “what breaks?” list ready for when NAT64 is removed?
7) Closing
An IPv6-only migration isn’t about “flipping IPv6 on in one setting.” NAT64/DNS64 is a strong bridge on this journey when used correctly: it provides a non-disruptive transition, exposes the dependencies, and makes the phased transformation possible. But what makes the bridge operable is segment-based activation, measurement, and a clear removal plan.