NAT64 and DNS64: Connecting IPv6-Only Networks to IPv4

The IPv6-Only Future#

Dual-stack—running IPv4 and IPv6 simultaneously—is the standard migration approach. But maintaining two parallel networks forever isn't the goal. The endpoint is IPv6-only infrastructure with legacy IPv4 accessed only when necessary.

This transition already happens in mobile networks. Major carriers run IPv6-only stacks on smartphones. T-Mobile, AT&T, and Verizon eliminated IPv4 from their LTE/5G networks years ago. Your phone has an IPv6 address. When you access an IPv4-only website, NAT64 and DNS64 handle translation transparently.

Enterprise networks follow the same path. IPv6-only reduces complexity, eliminates IPv4 address exhaustion concerns, and simplifies routing. But complete IPv4 elimination isn't realistic yet—too many services remain IPv4-only. NAT64 and DNS64 bridge this gap, allowing IPv6-only networks to access the IPv4 Internet.

How NAT64 and DNS64 Work Together#

NAT64 performs protocol translation at the network layer. DNS64 synthesizes IPv6 addresses that trigger this translation. They work as a pair—DNS64 without NAT64 is useless, and NAT64 without DNS64 requires manual configuration.

The Translation Flow#

Here's what happens when an IPv6-only client accesses an IPv4-only service:

┌─────────────────────────────────────────────────────────────────┐
│ 1. Client queries DNS for www.ipv4only.example.com             │
│    Query type: AAAA (IPv6 address)                             │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. DNS64 server queries upstream DNS                            │
│    Receives: A record → 198.51.100.10 (IPv4 only)              │
│    No AAAA record exists                                        │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. DNS64 synthesizes AAAA record                                │
│    Combines NAT64 prefix + IPv4 address                        │
│    Result: 64:ff9b::198.51.100.10                              │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. Client receives synthesized IPv6 address                     │
│    Sends packets to 64:ff9b::198.51.100.10                     │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 5. NAT64 gateway intercepts packets                             │
│    Recognizes 64:ff9b::/96 prefix                              │
│    Extracts embedded IPv4: 198.51.100.10                       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 6. NAT64 translates IPv6 → IPv4                                 │
│    Changes packet headers                                       │
│    Performs stateful NAT (tracks session)                       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 7. IPv4 packet sent to destination                              │
│    Source: NAT64 gateway IPv4 address                           │
│    Destination: 198.51.100.10                                   │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 8. Return traffic translated back                               │
│    NAT64 looks up session                                       │
│    Translates IPv4 → IPv6                                       │
│    Forwards to client                                           │
└─────────────────────────────────────────────────────────────────┘

The client sees only IPv6. The IPv4-only service sees only IPv4. NAT64 and DNS64 handle translation invisibly.

The Well-Known Prefix#

The standard NAT64 prefix is 64:ff9b::/96 (RFC 6052). This well-known prefix tells everyone "IPv4 addresses are embedded here."

IPv4 address embedding works like this:

IPv4 address:    198.51.100.10
In hex:          C6.33.64.0A
NAT64 prefix:    64:ff9b::
Combined:        64:ff9b::c633:640a
Expanded:        64:ff9b::198.51.100.10 (common notation)

The last 32 bits of the IPv6 address contain the IPv4 address. Applications never see this—it's purely internal to the translation infrastructure.

You can use custom prefixes instead of the well-known prefix. Common choices include organization-specific prefixes like 2001:db8:64::/96. This allows traffic engineering (routing NAT64 traffic differently) but requires DNS64 configuration changes.

DNS64 Deep Dive#

DNS64 is a DNS server with special translation logic. It intercepts AAAA queries and synthesizes responses when only A records exist.

DNS64 Logic Flow#

AAAA query for example.com
    ↓
Query upstream for AAAA
    ↓
AAAA record exists? ─ YES ─→ Return AAAA record (native IPv6)
    │
    NO
    ↓
Query upstream for A
    ↓
A record exists? ─ NO ─→ Return NXDOMAIN
    │
    YES
    ↓
Synthesize AAAA = prefix + IPv4
    ↓
Return synthesized AAAA

Key behaviors:

• Native IPv6 preferred: If AAAA exists, DNS64 returns it unchanged. No synthesis. NAT64 not involved.
• IPv4 fallback only: Synthesis happens only when AAAA doesn't exist
• Cache TTL preservation: Synthesized records inherit TTL from A record
• DNSSEC complexity: Synthesis breaks DNSSEC validation (more on this later)

DNS64 Configuration Examples#

BIND 9:

options {
    // ... other options ...
    dns64 64:ff9b::/96 {
        clients { any; };
        mapped { !192.168.0.0/16; !10.0.0.0/8; any; };
        exclude { 64:ff9b::/96; ::ffff:0:0/96; };
        suffix ::;
    };
};

This configuration enables DNS64 with the well-known prefix, excluding private IPv4 ranges.

Parameters:

• clients: Which clients get DNS64 (usually any)
• mapped: Which IPv4 addresses to translate (exclude RFC 1918 private addresses)
• exclude: Which IPv6 ranges to never synthesize
• suffix: Customizes where IPv4 embeds in address (advanced)

Unbound:

server:
    module-config: "dns64 validator iterator"
 
dns64:
    dns64-prefix: 64:ff9b::/96
    dns64-synthall: no

• dns64-synthall: Whether to synthesize even when AAAA exists (usually no)

PowerDNS Recursor:

# In recursor.conf
enable-dns64: yes
dns64-prefix: 64:ff9b::/96

DNS64 Discovery#

Clients need to know which DNS server provides DNS64. Typically configured via:

Router Advertisements (SLAAC):

# radvd.conf
interface eth0 {
    RDNSS 2001:db8::53 {
        AdvRDNSSLifetime 300;
    };
};

This advertises the DNS64 server address to all clients via Router Advertisements.

DHCPv6:

option dhcp6.name-servers 2001:db8::53;

Modern operating systems accept DNS servers from both RA and DHCPv6.

NAT64 Deep Dive#

NAT64 is stateful translation—it maintains session state like traditional NAT44. Each client connection gets a mapping in the NAT64 gateway's state table.

Stateful Translation#

The NAT64 gateway tracks:

• IPv6 source address and port
• IPv4 destination address and port
• Translated IPv4 source address and port
• Protocol (TCP/UDP/ICMP)
• Session timers

Session Table Entry:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IPv6 Client Side          │  IPv4 Server Side
━━━━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━
2001:db8:100::45:1234     │  203.0.113.5:6789
  (client IPv6:port)      │    (NAT IPv4:port)
                          │        ↕
                          │  198.51.100.10:80
                          │  (destination IPv4:port)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Protocol: TCP
State: ESTABLISHED
Timeout: 7440 seconds

When return traffic arrives at 203.0.113.5:6789, NAT64 looks up the session and translates back to 2001:db8:100::45:1234.

Protocol Translation#

NAT64 translates more than addresses—it converts between IPv4 and IPv6 packet formats:

IPv6 packet:

[ IPv6 Header | TCP/UDP/ICMP Header | Payload ]

Translated to IPv4:

[ IPv4 Header | TCP/UDP/ICMP Header | Payload ]

Translation includes:

• TTL/Hop Limit: Decremented and copied
• Fragmentation: IPv6 fragmentation → IPv4 fragmentation (with MTU considerations)
• ICMP: ICMPv6 → ICMPv4 (message type mapping)
• Checksums: Recalculated for new protocol headers

Addressing Pool#

NAT64 needs IPv4 addresses for outbound connections. Small deployments use a single IPv4 address with port overloading (like home routers). Larger deployments use pools.

# Small: Single IPv4
NAT64 pool: 203.0.113.5/32
Max clients: ~65,000 concurrent sessions
 
# Large: IPv4 pool
NAT64 pool: 203.0.113.0/24
Max clients: ~16 million concurrent sessions

Address exhaustion concerns apply—NAT64 faces the same port limitations as NAT44.

Implementation Options#

Multiple NAT64 software implementations exist, from lightweight to carrier-grade.

TAYGA: Lightweight Userspace#

TAYGA is a simple userspace NAT64 daemon for Linux. Good for small deployments and testing.

Installation:

apt-get install tayga

# Create TUN interface
ip tuntap add name nat64 mode tun
ip link set nat64 up
ip addr add 192.168.255.1/24 dev nat64
ip addr add 2001:db8:ffff::1/96 dev nat64

This creates the virtual interface for NAT64 traffic.

Configuration (/etc/tayga.conf):

tun-device nat64
ipv4-addr 192.168.255.1
ipv6-addr 2001:db8:ffff::1
prefix 64:ff9b::/96
dynamic-pool 192.168.255.0/24
data-dir /var/lib/tayga

Start and route:

systemctl start tayga

# Route NAT64 prefix through TAYGA
ip route add 64:ff9b::/96 dev nat64
ip route add 192.168.255.0/24 dev nat64

# Enable forwarding
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1

Pros: Simple, lightweight, easy setup Cons: Limited performance (userspace), no clustering, minimal features

Jool: Kernel Module#

Jool implements NAT64 as a Linux kernel module, offering better performance.

Installation:

# Add repository (Debian/Ubuntu)
apt-get install linux-headers-$(uname -r)
apt-get install jool-dkms jool-tools

# Load module
modprobe jool

Configuration:

# Create NAT64 instance
jool instance add "default" --netfilter --pool6 64:ff9b::/96

This creates a NAT64 instance named "default" using the well-known prefix.

# Add IPv4 address pool
jool -i "default" pool4 add --tcp 203.0.113.5 1024-65535
jool -i "default" pool4 add --udp 203.0.113.5 1024-65535
jool -i "default" pool4 add --icmp 203.0.113.5 1024-65535

# Enable
jool -i "default" global update enabled true

Routing:

ip route add 64:ff9b::/96 via 2001:db8::1

Pros: High performance (kernel space), active development, good documentation Cons: Kernel module complexity, occasional compatibility issues with kernel updates

Cloud Provider NAT64#

Major cloud platforms offer managed NAT64:

AWS (NAT64 via Egress-Only Internet Gateway):

AWS doesn't provide native NAT64, but you can deploy Jool or TAYGA on EC2 instances. Some third-party AMIs exist.

Alternative: Use dual-stack with IPv6-only internal networks and IPv4 for external access.

Google Cloud Platform:

GCP provides Cloud NAT with NAT64 support (beta):

# Create NAT64 subnet
gcloud compute networks subnets create nat64-subnet \
  --network=my-network \
  --region=us-central1 \
  --range=10.0.0.0/24 \
  --enable-nat64

# Configure Cloud NAT
gcloud compute routers nats create my-nat64 \
  --router=my-router \
  --region=us-central1 \
  --enable-nat64 \
  --nat64-prefix=64:ff9b::/96

Azure:

Azure supports IPv6 but doesn't offer managed NAT64. Deploy your own using Linux VMs with Jool or TAYGA.

Pros (managed services): No maintenance, scalable, integrated monitoring Cons: Cloud-specific, less configuration flexibility, potential cost

Carrier-Grade NAT64#

Telecom and large ISP deployments use commercial solutions:

• Cisco ASR with CGv6
• Juniper MX Series with NAT64 service
• A10 Thunder CGN
• F5 BIG-IP with CGNAT module

These handle millions of simultaneous sessions with high availability, logging for legal compliance, and sophisticated traffic policies.

464XLAT: Enabling IPv4-Only Applications#

NAT64/DNS64 works transparently for dual-stack applications. But some apps hardcode IPv4 addresses or use protocols that DNS64 can't intercept. 464XLAT solves this.

How 464XLAT Works#

464XLAT adds client-side translation (CLAT) before NAT64 (PLAT):

┌─────────────┐      ┌──────────────┐      ┌──────────────┐
│  IPv4 App   │      │              │      │              │
│             │      │ IPv6-Only    │      │ IPv4 Server  │
│ 192.0.0.10  │      │ Network      │      │198.51.100.10 │
└──────┬──────┘      └──────────────┘      └──────────────┘
       │                                            │
   CLAT (local)                                PLAT (ISP)
   NAT46: IPv4→IPv6                           NAT64: IPv6→IPv4
       │                                            │
       └──────────── IPv6 Network ─────────────────┘

Steps:

1. App sends IPv4 packet to 192.0.0.10 (CLAT virtual interface)
2. CLAT translates IPv4 → IPv6 using local prefix (e.g., 64:ff9b::c000:0a)
3. IPv6 packet traverses network to PLAT (NAT64 gateway)
4. PLAT translates IPv6 → IPv4
5. IPv4 packet reaches destination

The app sees local IPv4 connectivity. The network is IPv6-only. Translation happens at both ends.

464XLAT on Mobile#

Android and iOS implement CLAT automatically when connected to IPv6-only networks with NAT64:

Android CLAT:

• Detects NAT64 by querying for ipv4only.arpa (returns synthesized AAAA if NAT64 exists)
• Creates clat4 interface with 192.0.0.0/29 addresses
• Routes IPv4 app traffic through CLAT
• Translates to IPv6 using detected NAT64 prefix

iOS CLAT:

• Similar detection mechanism
• Transparent to apps and users

This is why IPv4-only apps work on T-Mobile, AT&T, and other IPv6-only mobile networks.

Linux 464XLAT with Clatd#

For Linux systems on IPv6-only networks:

# Install
apt-get install clatd

# Configure /etc/clatd.conf
clat-v4-addr=192.0.0.1
clat-v6-addr=2001:db8:1234:5678::1
plat-prefix=64:ff9b::/96

# Start
systemctl enable --now clatd

# Verify
ip addr show clat
ping -4 8.8.8.8  # Should work even on IPv6-only network

Use 464XLAT when:

• You have IPv4-only applications that can't be updated
• Applications bypass DNS (hardcoded IPs)
• You need transparent IPv4 support on IPv6-only infrastructure

Deployment Scenarios#

NAT64/DNS64 fits specific use cases. Understanding when to deploy it avoids architectural mistakes.

Scenario 1: Mobile Networks#

Situation: 5G/LTE carrier with millions of subscribers, limited IPv4 addresses

Solution: IPv6-only network with NAT64/DNS64 + 464XLAT

Benefits:

• Eliminates IPv4 from radio network and core
• Simplified routing (single protocol)
• Scales without IPv4 address constraints
• Supports legacy apps via 464XLAT

Implementation:

• PLAT (NAT64) in carrier core
• DNS64 on carrier DNS servers
• CLAT on handsets (automatic)

This is the dominant mobile architecture globally.

Scenario 2: Enterprise IPv6-Only Networks#

Situation: New data center, want IPv6-only to avoid dual-stack complexity

Solution: IPv6-only internal network, NAT64 for accessing external IPv4 services

Benefits:

• Simplified addressing (no IPv4 DHCP, NAT, etc.)
• Modern architecture
• Forces applications to support IPv6

Challenges:

• Some enterprise apps remain IPv4-only
• Management interfaces often IPv4-only
• Legacy hardware compatibility

Recommendation: Dual-stack usually easier for enterprise. IPv6-only makes sense for greenfield, cloud-native environments.

Scenario 3: Cloud-Native Microservices#

Situation: Kubernetes cluster, services communicate internally via IPv6

Solution: IPv6-only cluster with NAT64 for external IPv4 API dependencies

Benefits:

• Simplified service mesh
• No IPv4 address exhaustion in large clusters
• Native IPv6 for container networking

Implementation:

• Kubernetes IPv6-only mode
• NAT64 gateway for egress
• DNS64 via cluster DNS (CoreDNS supports it)

# CoreDNS ConfigMap with DNS64
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        dns64 64:ff9b::/96
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

Growing use case as IPv6 becomes standard in container orchestration.

Limitations and Gotchas#

NAT64/DNS64 isn't perfect. Understanding limitations prevents deployment failures.

1. DNSSEC Breaks#

DNS64 synthesizes AAAA records that don't exist in the authoritative zone. DNSSEC signatures don't cover these synthetic records, so validation fails.

Solutions:

• Disable DNSSEC validation on DNS64 resolver (not ideal)
• Use DNS64 that supports RFC 6147 DNSSEC handling (limited implementation)
• Accept that DNSSEC-signed IPv4-only domains won't validate

This is the biggest operational challenge with DNS64.

2. Hardcoded IPv4 Addresses#

Applications with hardcoded IPs bypass DNS, so DNS64 never sees the query. NAT64 can't help because it only recognizes the NAT64 prefix.

Solutions:

• Deploy 464XLAT (handles all IPv4 traffic)
• Update applications to use DNS names
• Use application-layer gateways (rare, complex)

3. IPv4 Literals in URLs#

Web apps passing http://192.0.2.1/api in URLs or configuration. Browsers don't perform DNS lookups for IP literals, so DNS64 doesn't synthesize.

Solutions:

• Use hostnames instead of IP literals
• Application-layer proxies that rewrite literals
• 464XLAT

4. FTP and Other ALGs#

Protocols that embed IP addresses in application data (FTP active mode, SIP, etc.) often fail through NAT64. The address in the payload doesn't match the packet header.

Solution:

• Use FTP passive mode (no embedded addresses)
• Deploy protocol-aware NAT64 with ALG support (complex)
• Move to modern protocols that don't embed IPs

5. Fragmentation Issues#

Path MTU differences between IPv4 and IPv6 can cause fragmentation problems. IPv6 has a minimum MTU of 1280 bytes; IPv4 allows 576 bytes.

Solution:

• Ensure MTU is consistent across infrastructure
• Enable Path MTU Discovery (PMTUD)
• Monitor and alert on ICMP Packet Too Big messages

6. Reverse DNS#

PTR records for NAT64-translated addresses won't exist. Applications that require reverse DNS (some mail servers, access controls) may fail.

Solution:

• Create PTR records for NAT64 pool
• Configure services to not require reverse DNS
• Use IPv6 natively where reverse DNS matters

Monitoring and Troubleshooting#

NAT64/DNS64 adds translation layers that can obscure problems. Proper monitoring is essential.

DNS64 Verification#

Test whether DNS64 works:

# Query for known IPv4-only domain
dig AAAA ipv4.google.com @2001:db8::53

This should return a synthesized AAAA with the NAT64 prefix.

# Should return synthesized AAAA with NAT64 prefix
# Example: 64:ff9b::8.8.8.8

If you get no AAAA record, DNS64 isn't working.

NAT64 Connectivity Test#

Use the special test domain ipv4only.arpa:

# From IPv6-only client
ping6 ipv4only.arpa

This should receive a reply via NAT64.

# Should receive reply via NAT64
# The domain resolves to 192.0.0.170, synthesized to 64:ff9b::192.0.0.170

If ping fails, NAT64 gateway isn't reachable or not translating.

Session Table Inspection#

Check NAT64 session state:

Jool:

jool -i "default" session display

This shows active sessions.

# Shows active sessions
# Look for: client IPv6, translated IPv4, destination

TAYGA:

cat /var/lib/tayga/dynamic.map

This shows address mappings.

# Shows address mappings

High session counts indicate heavy use or potential issues (connection leaks).

Traffic Analysis#

Capture traffic before and after translation:

# Capture IPv6 traffic to NAT64 prefix
tcpdump -i eth0 -n 'ip6 and dst net 64:ff9b::/96'

# Capture translated IPv4 traffic
tcpdump -i eth1 -n 'ip and src 203.0.113.5'

# Compare to verify translation

Look for:

• Packets arriving at NAT64 but not being translated
• Translation happening but packets not forwarded
• Asymmetric routing (return traffic not reaching NAT64)

Common Problems#

Symptom: DNS64 returns synthesized AAAA, but connection fails

Causes:

• NAT64 gateway unreachable
• Firewall blocking NAT64 prefix
• Routing problem (packets to NAT64 prefix go wrong direction)

Debug:

traceroute6 64:ff9b::198.51.100.1
# Should route to NAT64 gateway

Symptom: Some sites work, others don't

Causes:

• Sites with native IPv6 work (no NAT64 involved)
• IPv4-only sites with special requirements fail
• Fragmentation or MTU issues

Debug:

# Test with different MTUs
ping6 -M do -s 1400 64:ff9b::198.51.100.1

Symptom: Connections slow or timing out

Causes:

• NAT64 gateway overloaded
• Session table full
• Asymmetric routing

Debug:

# Check NAT64 CPU and session count
# Monitor connection establishment time
time curl -6 http://ipv4-only-site.example.com

Security Considerations#

NAT64 introduces security implications beyond typical NAT.

Address Space Scanning#

The NAT64 prefix makes IPv4 addresses predictable in IPv6. Attackers can scan 64:ff9b::/96 to discover what IPv4 services you're accessing.

Mitigation: Use network-specific NAT64 prefixes instead of well-known prefix, limiting exposure.

Bypassing Access Controls#

IPv4 access controls (firewall rules, ACLs) might not account for NAT64-translated traffic arriving from unexpected IPv6 sources.

Mitigation: Apply security policies to NAT64 gateway, not just endpoints.

NAT64 as Attack Amplifier#

Attackers on IPv6-only networks can use NAT64 to launch attacks against IPv4 targets, potentially bypassing IPv4-based rate limiting or blacklists.

Mitigation:

• Rate limit NAT64 sessions per source
• Log all NAT64 translations for abuse investigation
• Apply same security policies as IPv4 NAT

DNS64 Cache Poisoning#

If DNS64 server is compromised, attackers can synthesize malicious AAAA records pointing to attacker-controlled IPv4 addresses via NAT64.

Mitigation:

• Secure DNS64 servers (same as any DNS infrastructure)
• Use DNSSEC where possible (despite compatibility issues)
• Monitor DNS64 for unusual synthesis patterns

When to Use NAT64/DNS64 vs. Dual-Stack#

Decision framework:

┌─────────────────────────────────────────────────┐
│ Can you run dual-stack?                         │
└─────────────────────┬───────────────────────────┘
                      │
          ┌───────────┴──────────┐
          │                      │
         YES                    NO
          │                      │
          ▼                      ▼
   ┌─────────────┐     ┌─────────────────────┐
   │ Use         │     │ Why not?            │
   │ Dual-Stack  │     │                     │
   │             │     │ • IPv4 exhaustion   │
   │ (simpler,   │     │ • Architectural     │
   │  fewer      │     │   simplification    │
   │  issues)    │     │ • Mobile network    │
   └─────────────┘     │ • Cloud native      │
                       └──────────┬──────────┘
                                  │
                                  ▼
                         ┌────────────────────┐
                         │ Use NAT64/DNS64    │
                         │                    │
                         │ Add 464XLAT if:    │
                         │ • IPv4-only apps   │
                         │ • Hardcoded IPs    │
                         └────────────────────┘

NAT64/DNS64 makes sense when:

• IPv4 address exhaustion is a real constraint
• You're building new infrastructure (greenfield)
• Mobile network or cloud-native architecture
• Operational benefits of single-stack outweigh translation complexity

Dual-stack makes sense when:

• IPv4 addresses are available
• Mixed legacy and modern infrastructure
• Compatibility is highest priority
• Team familiarity with dual-stack

The Future of NAT64#

NAT64 adoption grows as IPv6-only networks become more common:

Trends:

• Mobile carriers almost universally deployed
• Cloud providers adding managed NAT64 options
• IoT and edge computing using IPv6-only + NAT64
• Data centers experimenting with IPv6-only for cost/simplicity

Challenges remaining:

• DNSSEC compatibility still unsolved elegantly
• Application-layer protocol issues persist
• Operational expertise still developing

Long-term: As IPv4 Internet shrinks and IPv6 becomes ubiquitous, NAT64 usage may decrease—most destinations will have native IPv6, requiring no translation. But that's years away. For now, NAT64/DNS64 is the key technology enabling IPv6-only networks.

Start Small and Test#

Don't deploy NAT64/DNS64 in production without thorough testing:

1. Lab environment: Set up TAYGA or Jool on test network
2. Configure DNS64: Use BIND or Unbound
3. Test applications: Verify your specific apps work through translation
4. Monitor performance: Measure latency and throughput overhead
5. Document issues: Note which apps or services have problems
6. Plan workarounds: Dual-stack for problematic services, 464XLAT for others

Only after successful testing should you consider production deployment, and even then, start with non-critical networks or user segments.

NAT64/DNS64 is powerful but adds complexity. Use it where it solves real problems, not because it's novel technology.

Related Articles#

• IPv6 Migration Strategies - Choosing the right migration approach
• Dual-Stack IPv6 Deployment - Running IPv4 and IPv6 together
• IPv6 DNS Configuration - Setting up DNS for IPv6

Frequently Asked Questions#