IPv4 address exhaustion is no longer a future problem — it is an operational constraint that most hosting providers have been working around for years through CGNAT, address sharing, and increasingly expensive IPv4 lease markets. The practical path forward is IPv6-only infrastructure with NAT64/DNS64 translation for backward compatibility with the remaining IPv4-only services.

This guide walks through the migration from dual-stack to IPv6-only default operation, covering the translation mechanisms, DNS configuration, testing strategies, and the specific failure modes you need to plan for.

Why IPv6-only is becoming the default

Several forces are converging in 2026:

  • IPv4 lease costs continue to rise as the transfer market tightens
  • Major mobile carriers (T-Mobile, Reliance Jio, SK Telecom) already run IPv6-only networks with NAT64 for millions of subscribers
  • Cloud providers (AWS, Google Cloud, Azure) now offer IPv6-only VPC configurations with integrated NAT64
  • Apple's App Store has required IPv6 compatibility since 2016, and Apple's network stack defaults to IPv6-first
  • Cloudflare, Fastly, and other CDNs serve all content over IPv6 natively

For a hosting operator, the question is no longer "should we support IPv6?" but "when do we stop paying for dual-stack overhead?"

Mental model: the translation layer

In an IPv6-only network, hosts have only IPv6 addresses. To reach IPv4-only destinations, two components work together:

DNS64

A DNS64 resolver intercepts DNS responses that contain only A records (IPv4) and synthesises AAAA records (IPv6) by embedding the IPv4 address within a well-known IPv6 prefix (typically 64:ff9b::/96).

Example:

  • Client queries legacy-api.example.com
  • Authoritative DNS returns only A 203.0.113.42
  • DNS64 resolver synthesises AAAA 64:ff9b::cb00:712a (203.0.113.42 encoded in hex)
  • Client connects to the synthesised IPv6 address

NAT64

A NAT64 gateway sits at the network edge and translates between IPv6 and IPv4:

  • Receives traffic destined for the 64:ff9b::/96 prefix
  • Extracts the embedded IPv4 address
  • Translates the packet from IPv6 to IPv4 and forwards it
  • Maintains connection state for return traffic

Together, DNS64 + NAT64 allow IPv6-only hosts to reach IPv4-only services transparently.

Pre-migration assessment

1. Audit your IPv4 dependencies

Before going IPv6-only, identify everything that requires IPv4:

  • External APIs — do they have AAAA records? Many still don't.
  • Payment processors — webhook callbacks may come from IPv4-only sources
  • Email servers — some SMTP relays are still IPv4-only
  • Monitoring services — synthetic checks may not support IPv6
  • Package repositories — most major ones support IPv6, but verify your specific mirrors
  • Internal services — databases, message queues, internal APIs

2. Verify DNS infrastructure

Your authoritative DNS must serve AAAA records for all your public services. Check:

dig AAAA yourdomain.com +short

If no AAAA record exists, add one. Your DNS provider must support AAAA records (all modern providers do).

3. Test application compatibility

Some applications have IPv6 bugs that surface only in IPv6-only environments:

  • Hard-coded IPv4 addresses in configuration files
  • Libraries that default to AF_INET instead of AF_UNSPEC
  • Connection strings using IPv4 literal addresses
  • IP address validation regex that rejects IPv6 format

Migration checklist

Phase 1: Dual-stack with IPv6 preference

  1. Ensure all services have both A and AAAA records
  2. Configure servers to prefer IPv6 for outbound connections (precedence ::ffff:0:0/96 40 in /etc/gai.conf on Linux)
  3. Verify all internal communication works over IPv6
  4. Monitor IPv6 vs IPv4 traffic ratios

Phase 2: Deploy NAT64/DNS64

  1. Set up NAT64 gateway — options include:
    • Cloud-provider managed NAT64 (AWS, GCP)
    • Jool (open-source, Linux-based)
    • Tayga (simple stateless NAT64)
  2. Configure DNS64 resolver — options include:
    • BIND 9 with dns64 directive
    • Unbound with dns64-prefix
    • Cloud-provider managed DNS64
  3. Test translation — from an IPv6-only test host, resolve and connect to a known IPv4-only destination
  4. Verify MTU — NAT64 adds overhead; ensure path MTU discovery works correctly

Phase 3: IPv6-only for new infrastructure

  1. Provision new servers with IPv6-only networking
  2. Point them to the DNS64 resolver
  3. Route their traffic through the NAT64 gateway for IPv4 destinations
  4. Monitor for connection failures to IPv4-only services

Phase 4: Migrate existing infrastructure

  1. Remove IPv4 addresses from dual-stack servers one service at a time
  2. Update internal DNS to remove A records for internal services
  3. Keep NAT64/DNS64 running for external IPv4 dependencies
  4. Update monitoring to check IPv6 connectivity specifically

Failure modes to plan for

DNS64 synthesis for DNSSEC-signed domains. DNS64 modifies DNS responses, which breaks DNSSEC validation if the client validates locally. Solutions:

  • Run DNS64 as a validating resolver that strips DNSSEC for synthesised records
  • Or use DNS64 only for domains that lack AAAA records (most DNS64 implementations do this automatically)

NAT64 state table exhaustion. High-traffic NAT64 gateways can run out of translation state entries. Monitor state table usage and scale horizontally if needed.

Applications that use literal IPv4 addresses. Some configuration files, API endpoints, or embedded URLs use IPv4 addresses directly. These bypass DNS64 entirely and fail in IPv6-only environments. Audit and fix these before migration.

PMTU issues. NAT64 adds encapsulation overhead. If path MTU discovery is broken (blocked ICMP), connections may silently fail for large packets. Ensure ICMPv6 "Packet Too Big" messages are not filtered.

IPv4-only captive portals. Some network-level services (hotel Wi-Fi, airline internet) only work with IPv4. This affects mobile users, not servers, but is worth noting for completeness.

Verification

  1. From an IPv6-only host, resolve an IPv4-only domain: dig AAAA ipv4only.arpa — should return the DNS64-synthesised address
  2. Connect to an IPv4-only service: curl -6 http://ipv4only.example.com/ — should succeed through NAT64
  3. Verify DNSSEC does not break: dig +dnssec example.com AAAA — should validate correctly for native AAAA records
  4. Test large transfers: download a >1 MB file through NAT64 to verify MTU handling
  5. Monitor NAT64 state table: ensure utilisation stays below 80% under normal load

When to keep dual-stack

  • Public-facing web servers that need direct IPv4 reachability from legacy clients without NAT64 in the path
  • Services required by contractual SLA to be reachable over IPv4
  • Email infrastructure where IPv4 reputation and reverse DNS are critical for deliverability

For most backend infrastructure, internal services, and new deployments, IPv6-only with NAT64 is the practical choice in 2026.

Related reading on wplus.net