The End Game
Running dual-stack (both IPv4 and IPv6) is operationally expensive. You maintain two sets of firewall rules, two routing tables, two sets of security group rules, and two address plans. Every new service must be configured for both protocols. The long-term goal is IPv6-only infrastructure — but the internet still has significant IPv4-only services (legacy APIs, old CDNs, some payment processors). An IPv6-only host needs a way to reach them.
The solution is NAT64 + DNS64 — a pair of mechanisms that work together to give IPv6-only clients transparent access to IPv4-only destinations.
DNS64: Synthesizing IPv6 Addresses for IPv4 Destinations
DNS64 is a special DNS resolver that lies — constructively. When an IPv6-only client queries for legacy-api.example.com:
Client query: "What is the AAAA record for legacy-api.example.com?"
Normal DNS: "There is no AAAA record. Only A record: 203.0.113.5"
DNS64 response: "Here is a synthesized AAAA record: 64:ff9b::203.0.113.5"
└── Well-known NAT64 prefix (64:ff9b::/96) + IPv4 address
The client now has an IPv6 address to connect to. It has no idea the destination is actually IPv4-only.
NAT64: Translating at the Gateway
The synthesized address 64:ff9b::203.0.113.5 is routed to the NAT64 gateway — a device that understands this prefix means "translate to IPv4":
IPv6-only Client NAT64 Gateway IPv4 Internet
│ │ │
├── IPv6 packet ───────────────►│ │
│ Dst: 64:ff9b::203.0.113.5 │ │
│ ├── IPv4 packet ──────────►│
│ │ Dst: 203.0.113.5 │
│ │ Src: [NAT64 pool IP] │
│ │◄── IPv4 response ────────┤
│◄── IPv6 packet ───────────────┤ │
│ Src: 64:ff9b::203.0.113.5 │ │
The NAT64 gateway maintains a translation table (similar to IPv4 NAT) mapping IPv6 flows to IPv4 flows. From the client's perspective, it made a normal IPv6 connection. From the IPv4 server's perspective, it received a normal IPv4 connection from the NAT64 gateway's public IP.
AWS Example: IPv6-Only Subnets
AWS supports IPv6-only subnets in VPCs. Lambda functions and EC2 instances in these subnets use NAT64 via the Egress-Only Internet Gateway combined with a NAT64 gateway. This allows modern serverless workloads to be pure IPv6 internally while still calling legacy IPv4 APIs like GitHub, npm registries, or payment processors.
Lambda (IPv6-only)
│
├── Queries DNS64 resolver (provided by VPC)
│ Gets: 64:ff9b::140.82.121.4 (GitHub's IPv4 synthesized)
│
└── Sends IPv6 packet to 64:ff9b::140.82.121.4
→ Routed to NAT64 gateway
→ Translated to IPv4 packet to 140.82.121.4
→ GitHub responds
→ Response translated back to IPv6
→ Lambda receives response
Limitations of NAT64
NAT64 does not work for applications that embed IP addresses in their payload (like some FTP modes or SIP VoIP). It also does not help if the IPv4-only service uses IP-based authentication (the source IP will be the NAT64 gateway's IP, not the client's). These edge cases require application-level fixes.
Interviewers at cloud companies (AWS, GCP, Azure) frequently ask about IPv6-only VPC design. The key insight to demonstrate: DNS64 and NAT64 are complementary — DNS64 makes IPv4 destinations appear to have IPv6 addresses, and NAT64 performs the actual protocol translation. Neither works without the other. Also note that NAT64 is stateful (like IPv4 NAT), which means it reintroduces some of the operational complexity that IPv6-only networks were supposed to eliminate — but it is a controlled, temporary bridge, not a permanent architecture.
Key Point: NAT64/DNS64 is the migration bridge that makes IPv6-only infrastructure practical today. It allows organizations to simplify their internal network to a single protocol while maintaining access to the legacy IPv4 internet. As IPv4-only services migrate to dual-stack or IPv6-only, the need for NAT64 diminishes — it is designed to be a temporary mechanism, not a permanent fixture.