How to Set Up IPv6-Only Networks

Overview

IPv6-only networks represent the future of Internet infrastructure, eliminating the complexity of dual-stack deployments while maintaining complete backward compatibility with IPv4-only services. Major organizations including T-Mobile US, Verizon Wireless, Google Cloud, and AWS have successfully deployed IPv6-only networks at massive scale.

This comprehensive guide covers planning, implementation, and troubleshooting of IPv6-only networks for both enterprise and home environments, with a focus on NAT64/DNS64 and 464XLAT mechanisms that enable seamless IPv4 compatibility.

Key technologies covered:


Why Deploy IPv6-Only Networks?

Operational Benefits

Simplified Network Management

Address Efficiency

Cost Reduction

Real-World Success Stories

T-Mobile US (2013-present)

Verizon Wireless

Telstra (2020)


Planning Your IPv6-Only Network

Prerequisites Assessment

Before beginning deployment, verify these essential requirements:

1. IPv6 Connectivity from ISP

Contact your Internet Service Provider to confirm:

2. Hardware and Software Compatibility

Inventory your infrastructure:

3. NAT64/DNS64 Infrastructure Planning

Determine deployment model:

4. Address Planning

Design your IPv6 addressing scheme:

Example /56 prefix from ISP: 2001:db8:1234::/56

Subnet allocation:
  2001:db8:1234:0::/64  - Management network
  2001:db8:1234:1::/64  - Corporate LAN
  2001:db8:1234:2::/64  - Guest WiFi
  2001:db8:1234:3::/64  - Servers
  2001:db8:1234:10::/64 - IoT devices
  ...
  2001:db8:1234:ff::/64 - Reserved for future use

Important: Avoid ULA (fc00::/7) addresses for internet-facing services. Use only global unicast addresses (2000::/3).

NAT64 Prefix Selection

Choose your NAT64 prefix based on deployment type:

Well-Known Prefix (64:ff9b::/96) - Recommended for most deployments

Network-Specific Prefix (Custom /96) - For advanced deployments

Recommendation: Start with 64:ff9b::/96 unless you have specific requirements for private IPv4 translation.


Implementation: Enterprise Network

Architecture Overview

┌──────────────────────────────────────────────────────────────┐
│                  IPv6-Only Enterprise Network                 │
│                  Prefix: 2001:db8:1234::/56                  │
│                                                               │
│  ┌─────────────┐    ┌──────────────┐    ┌─────────────┐    │
│  │   Client    │    │   Client     │    │   Server    │    │
│  │  Devices    │───▶│   Devices    │◀───│   VMs       │    │
│  │  (SLAAC)    │    │   (DHCPv6)   │    │  (Static)   │    │
│  └──────┬──────┘    └──────┬───────┘    └──────┬──────┘    │
│         │                   │                    │            │
│         └───────────────────┼────────────────────┘            │
│                             │                                 │
│                    ┌────────▼────────┐                       │
│                    │   Core Switch   │                       │
│                    │   IPv6 Routing  │                       │
│                    └────────┬────────┘                       │
│                             │                                 │
│         ┌───────────────────┼────────────────────┐           │
│         │                   │                    │            │
│  ┌──────▼──────┐   ┌────────▼────────┐   ┌─────▼──────┐   │
│  │   DNS64     │   │   Firewall      │   │  Internal  │   │
│  │   Server    │   │   IPv6 Rules    │   │  Services  │   │
│  │  (BIND9)    │   │                 │   │            │   │
│  └─────────────┘   └────────┬────────┘   └────────────┘   │
│                              │                              │
│                     ┌────────▼────────┐                    │
│                     │  NAT64 Gateway  │                    │
│                     │  64:ff9b::/96   │                    │
│                     │  IPv4 Pool:     │                    │
│                     │  203.0.113.0/24 │                    │
│                     └────────┬────────┘                    │
└──────────────────────────────┼─────────────────────────────┘
                               │
                        ┌──────▼──────┐
                        │   Internet  │
                        │  IPv4 + IPv6│
                        └─────────────┘

Step 1: Configure DNS64 Server

DNS64 synthesizes IPv6 addresses for IPv4-only destinations. We'll use BIND9 as the reference implementation.

Install BIND9 (Ubuntu/Debian):

sudo apt-get update
sudo apt-get install bind9 bind9-doc bind9utils

Configure DNS64 (/etc/bind/named.conf.options):

options {
    directory "/var/cache/bind";

    // DNS64 configuration
    dns64 64:ff9b::/96 {
        clients { any; };
        mapped { any; };
        exclude {
            ::ffff:0000:0000/96;  // IPv4-mapped IPv6
            64:ff9b::/96;         // NAT64 well-known prefix itself
        };
        recursive-only yes;
    };

    // Standard recursive resolver settings
    recursion yes;
    allow-recursion {
        2001:db8:1234::/56;  // Your IPv6 prefix
        ::1;
    };

    // Forwarders (optional - use your ISP or public DNS)
    forwarders {
        2001:4860:4860::8888;  // Google Public DNS
        2001:4860:4860::8844;
    };

    // DNSSEC validation
    dnssec-validation auto;

    listen-on-v6 { any; };
};

Start and enable DNS64:

sudo systemctl restart bind9
sudo systemctl enable bind9

Test DNS64 synthesis:

# Query IPv4-only domain through DNS64
dig AAAA www.example.com @2001:db8:1234::53

# Expected: Synthesized AAAA record like 64:ff9b::93e5:70b
# (which embeds IPv4 address 147.229.7.11)

Alternative: Use Google Public DNS64

For smaller deployments, you can use Google's public DNS64 service:

DNS64 resolvers:
  2001:4860:4860::6464
  2001:4860:4860::64

Configuration: Point clients to these IPv6 addresses
Prefix used: 64:ff9b::/96 (well-known prefix)

Step 2: Deploy NAT64 Gateway

NAT64 performs stateful IPv6-to-IPv4 protocol translation. We'll use Jool, a high-performance open-source NAT64 implementation.

Install Jool (Ubuntu/Debian):

# Install kernel headers
sudo apt-get install linux-headers-$(uname -r)

# Install Jool
sudo apt-get install jool-dkms jool-tools

# Load kernel module
sudo modprobe jool

Configure NAT64 instance:

# Create NAT64 instance with well-known prefix
sudo jool instance add "enterprise-nat64" --netfilter --pool6 64:ff9b::/96

# Add IPv4 address pool (your public IPv4 addresses)
# Separate port ranges for TCP, UDP, and ICMP
sudo jool -i "enterprise-nat64" pool4 add --tcp 203.0.113.10 1024-65535
sudo jool -i "enterprise-nat64" pool4 add --udp 203.0.113.10 1024-65535
sudo jool -i "enterprise-nat64" pool4 add --icmp 203.0.113.10 1024-65535

# For multiple IPv4 addresses, add more entries:
sudo jool -i "enterprise-nat64" pool4 add --tcp 203.0.113.11 1024-65535
sudo jool -i "enterprise-nat64" pool4 add --udp 203.0.113.11 1024-65535

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

# Make forwarding persistent
echo "net.ipv6.conf.all.forwarding=1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.conf.all.forwarding=1" | sudo tee -a /etc/sysctl.conf

Configure network interfaces:

# Example configuration for NAT64 gateway with two interfaces
# eth0: IPv6 side (internal network)
# eth1: IPv4 side (internet)

# IPv6 interface
sudo ip -6 addr add 2001:db8:1234:0::1/64 dev eth0
sudo ip link set eth0 up

# IPv4 interface
sudo ip addr add 203.0.113.10/24 dev eth1
sudo ip link set eth1 up

# Default routes
sudo ip -6 route add default via 2001:db8:1234:0::ffff dev eth0
sudo ip route add default via 203.0.113.1 dev eth1

Persistent Jool configuration (/etc/jool/jool.conf):

{
    "instance": "enterprise-nat64",
    "framework": "netfilter",
    "global": {
        "pool6": "64:ff9b::/96"
    },
    "pool4": [
        {
            "protocol": "TCP",
            "prefix": "203.0.113.10/32",
            "port-range": "1024-65535"
        },
        {
            "protocol": "UDP",
            "prefix": "203.0.113.10/32",
            "port-range": "1024-65535"
        },
        {
            "protocol": "ICMP",
            "prefix": "203.0.113.10/32",
            "port-range": "1024-65535"
        }
    ]
}

Create systemd service (/etc/systemd/system/jool-nat64.service):

[Unit]
Description=Jool NAT64 Gateway
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/jool file handle /etc/jool/jool.conf
ExecStop=/usr/bin/jool instance remove "enterprise-nat64"

[Install]
WantedBy=multi-user.target

Enable and start NAT64:

sudo systemctl daemon-reload
sudo systemctl enable jool-nat64
sudo systemctl start jool-nat64

Step 3: Configure Router with PREF64 Advertisement

Modern clients can discover NAT64 prefixes automatically via Router Advertisements (RFC 8781). Configure your router to advertise the PREF64 option.

Install radvd (Router Advertisement Daemon):

sudo apt-get install radvd

Configure radvd (/etc/radvd.conf):

interface eth0
{
    AdvSendAdvert on;
    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 10;

    # Advertise network prefix
    prefix 2001:db8:1234:1::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr on;
    };

    # Advertise NAT64 prefix (PREF64 - RFC 8781)
    # This allows 464XLAT clients to discover NAT64 automatically
    PREF64 64:ff9b::/96
    {
        AdvPreferredLifetime 300;
        AdvValidLifetime 65535;
    };

    # DNS server advertisement (RDNSS)
    RDNSS 2001:db8:1234::53
    {
        AdvRDNSSLifetime 300;
    };
};

Start radvd:

sudo systemctl restart radvd
sudo systemctl enable radvd

Verify PREF64 advertisement (from client):

# On Linux client, check for PREF64 route
ip -6 route show | grep pref64

# Expected output:
# pref64 64:ff9b::/96 dev eth0 metric 1024 pref medium

Step 4: Configure IPv6 Firewall

IPv6-only networks require explicit firewall rules. Unlike IPv4 with NAT providing implicit protection, IPv6 devices often receive global addresses requiring careful IPv6 firewall configuration.

Example nftables configuration (/etc/nftables.conf):

#!/usr/sbin/nft -f

flush ruleset

table ip6 filter {
    # Incoming traffic to router itself
    chain input {
        type filter hook input priority 0; policy drop;

        # Allow established/related connections
        ct state established,related accept

        # Allow loopback
        iif lo accept

        # Allow ICMPv6 (essential for IPv6)
        ip6 nexthdr ipv6-icmp accept

        # Allow DHCPv6
        udp dport 546 accept

        # Allow SSH (adjust as needed)
        tcp dport 22 accept

        # Allow DNS queries to local DNS64 server
        tcp dport 53 accept
        udp dport 53 accept

        # Log and drop everything else
        log prefix "IPv6 INPUT DROP: " drop
    }

    # Forwarding between networks
    chain forward {
        type filter hook forward priority 0; policy drop;

        # Allow established/related connections
        ct state established,related accept

        # Allow ICMPv6 forwarding (essential)
        ip6 nexthdr ipv6-icmp accept

        # Allow outbound from internal network
        iif eth0 oif eth1 accept

        # Log and drop everything else
        log prefix "IPv6 FORWARD DROP: " drop
    }

    # Outgoing traffic from router
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

# IPv4 rules for NAT64 translated traffic
table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif lo accept
        icmp type echo-request accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state established,related accept

        # Allow NAT64 translated traffic
        iif eth0 oif eth1 accept
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Apply firewall rules:

sudo systemctl enable nftables
sudo systemctl restart nftables

Critical ICMPv6 types to allow:

Never block ICMPv6 - it is essential for IPv6 operation.

Step 5: Configure Client Devices

Modern operating systems support IPv6 automatically. Ensure clients receive IPv6 configuration via SLAAC or DHCPv6.

Linux (verify IPv6 configuration):

# Check IPv6 addresses
ip -6 addr show

# Expected: Global unicast address (2001:db8:1234:1::xxxx)
# and link-local address (fe80::xxxx)

# Check default route
ip -6 route show default

# Verify DNS configuration
cat /etc/resolv.conf
# Should show IPv6 DNS server (2001:db8:1234::53)

# Test connectivity
ping6 google.com
curl -6 http://ipv6.google.com/

Windows (verify and configure):

# Check IPv6 configuration
ipconfig /all

# Should show:
# - IPv6 Address (global unicast starting with 2001:db8:1234)
# - Default Gateway (IPv6)
# - DNS Servers (IPv6)

# Test connectivity
ping -6 google.com

macOS (verify configuration):

# Check network configuration
ifconfig en0

# Test IPv6
ping6 google.com
curl -6 http://ipv6.google.com/

Step 6: Testing and Validation

After deployment, thoroughly test your IPv6-only network.

Test DNS64 synthesis:

# Query IPv4-only domain
dig AAAA ipv4.example.com @2001:db8:1234::53

# Should return synthesized AAAA with 64:ff9b:: prefix

Test NAT64 translation:

# From IPv6-only client, access IPv4-only service
curl -6 -v http://ipv4only.example.com/

# Should successfully connect via NAT64 translation

Monitor NAT64 gateway:

# Check Jool statistics
sudo jool -i "enterprise-nat64" stats display

# View active sessions
sudo jool -i "enterprise-nat64" session display

# Monitor pool4 utilization
sudo jool -i "enterprise-nat64" pool4 display

Comprehensive IPv6 connectivity test:

Visit test-ipv6.run from a client device to verify:

This testing platform provides detailed diagnostics to identify configuration issues before they impact users.


Implementation: Home Network

For home networks, IPv6-only deployment is simpler but requires router support or ISP-provided NAT64/DNS64.

Option 1: ISP-Provided NAT64/DNS64

Many modern ISPs (especially mobile carriers) provide NAT64/DNS64 infrastructure. This is the simplest deployment option.

Configuration steps:

  1. Contact your ISP to confirm IPv6-only service availability
  2. Request IPv6-only connection (disable IPv4 if dual-stack)
  3. Configure router for IPv6-only WAN:
    WAN Settings:
      Connection Type: IPv6 Only
      IPv6 Address: Automatic (DHCPv6 or SLAAC)
      IPv6 DNS: Automatic (from ISP)
    
  4. Enable IPv6 on LAN:
    LAN Settings:
      IPv6 Assignment: SLAAC + DHCPv6
      Router Advertisement: Enabled
      IPv6 DNS: Automatic (forward ISP DNS64)
    
  5. Test connectivity from client devices

Verification:

# Check if DNS64 is working
dig AAAA ipv4only.example.com

# If you get 64:ff9b:: addresses, DNS64 is active

Option 2: OpenWRT Router with 464XLAT

OpenWRT supports 464XLAT, allowing your router to provide CLAT functionality.

Install 464XLAT package:

opkg update
opkg install map-t

Configure WAN interface (via LuCI web interface):

Network > Interfaces > WAN

Protocol: DHCPv6 client
Request IPv6-prefix of length: 56 or 64 (as provided by ISP)

Configure 464XLAT:

Network > Interfaces > Add New Interface

Name: CLAT
Protocol: 464XLAT
Tunnel Settings:
  - Use well-known prefix 64:ff9b::/96
  - Or leave automatic to discover via DNS64

Configure LAN to distribute IPv6:

Network > Interfaces > LAN

IPv6 Settings:
  RA Service: Server mode
  DHCPv6 Service: Server mode
  NDP-Proxy: Disabled

Alternative: Command-line configuration (/etc/config/network):

config interface 'wan6'
    option proto 'dhcpv6'
    option reqaddress 'try'
    option reqprefix 'auto'

config interface 'clat'
    option proto '464xlat'
    option tunlink 'wan6'
    option ip4table 'auto'
    option ip6table 'auto'

Restart network:

/etc/init.d/network restart

Option 3: Google Public DNS64 (Simplest)

For quick testing or small home networks without NAT64 gateway:

Router configuration:

IPv6 DNS Servers:
  Primary:   2001:4860:4860::6464
  Secondary: 2001:4860:4860::64

Important limitation: This only provides DNS64. Your network must have access to a NAT64 gateway using 64:ff9b::/96. Many ISPs provide NAT64 automatically when they detect IPv6-only connectivity.

Verify NAT64 availability:

# Try to access IPv4-only service
curl -6 -v http://ipv4.example.com/

# If successful, NAT64 is available on your network path

Client Device Configuration

Android (464XLAT CLAT)

Android 4.3+ includes native 464XLAT CLAT support, automatically activated on IPv6-only networks.

Enable IPv6-only mode:

Settings > Network & Internet > Mobile network
Access Point Names > Your APN

APN Protocol: IPv6
APN Roaming Protocol: IPv6

Verification:

# CLAT activation creates virtual interface clat4
# Check via terminal app or ADB:
ip addr show clat4

# Should show 192.0.0.x address

How it works:

  1. Device connects to IPv6-only APN
  2. Detects absence of IPv4 connectivity
  3. Discovers NAT64 prefix (via DNS64 or PREF64)
  4. Activates CLAT, creating virtual IPv4 interface
  5. Applications see both IPv6 and IPv4 connectivity
  6. IPv4 traffic translated to IPv6, routed through carrier's PLAT

Result: All apps work, including those using IPv4 literals (games, VoIP, etc.)

iOS (464XLAT Support)

iOS 9.2+ supports 464XLAT automatically on IPv6-only networks.

Configuration: No manual configuration needed. iOS detects IPv6-only cellular networks and activates translation automatically.

App Store requirement: Apple requires all iOS apps to work on IPv6-only networks with NAT64/DNS64 since June 2016.

Windows 11

Windows 11 includes experimental 464XLAT support.

Enable CLAT (PowerShell as Administrator):

# Check current status
Get-NetNat64Configuration

# Enable CLAT (experimental feature)
Set-NetNat64Configuration -PrefixMapping 64:ff9b::/96

Verify:

ipconfig /all
# Look for IPv4 adapter with 192.0.0.x address

Linux (clatd)

Install and configure clatd for client-side 464XLAT:

Install clatd:

# Ubuntu/Debian
sudo apt-get install clatd

# Or from source
git clone https://github.com/toreanderson/clatd
cd clatd
sudo make install

Configure clatd (/etc/clatd.conf):

# Automatic configuration (discovers PLAT64 prefix via DNS64)
# No configuration needed in most cases

# Manual configuration (if automatic discovery fails):
plat-prefix 64:ff9b::/96

Start clatd:

sudo systemctl start clatd
sudo systemctl enable clatd

Verify CLAT interface:

ip addr show clat

# Should show virtual IPv4 interface with 192.0.0.x address

Router and Network Equipment Setup

Cisco Router Configuration

Enable IPv6 routing:

ipv6 unicast-routing

! Configure NAT64 prefix
ipv6 nat prefix 64:ff9b::/96

! Configure IPv4 address pool for NAT64
ipv6 nat v4-pool NAT64-POOL 203.0.113.10 203.0.113.20

! Configure interfaces
interface GigabitEthernet0/0
 description IPv6 LAN
 ipv6 address 2001:db8:1234:1::1/64
 ipv6 enable
 ipv6 nd prefix 2001:db8:1234:1::/64
 ipv6 nd ra interval 10
 ipv6 nat

interface GigabitEthernet0/1
 description IPv4 WAN
 ip address 203.0.113.10 255.255.255.0
 ipv6 nat

Configure DNS64 on Cisco:

! Enable DNS64
ipv6 nat prefix 64:ff9b::/96
ipv6 dns64 enable

! Specify DNS64 servers
ipv6 dns64 server 2001:db8:1234::53

MikroTik Router Configuration

Configure IPv6 address:

/ipv6 address add address=2001:db8:1234:1::1/64 interface=ether1

! Enable IPv6 routing
/ipv6 settings set forward=yes

! Configure NAT64
/ipv6 nat64
add prefix=64:ff9b::/96

! Add IPv4 pool
/ip pool add name=nat64-pool ranges=203.0.113.10-203.0.113.20

! Create NAT64 rule
/ipv6 nat64
add pool=nat64-pool protocol=tcp
add pool=nat64-pool protocol=udp
add pool=nat64-pool protocol=icmp

UniFi Configuration

UniFi Dream Machine / Gateway:

1. Network Settings > Internet > WAN
   - IPv6 Connection: DHCPv6
   - Prefix Delegation: Enabled

2. Network Settings > Networks > LAN
   - IPv6 Interface Type: Prefix Delegation
   - IPv6 RA: Enabled
   - DHCPv6/RDNSS DNS Control: Auto

3. Configure Custom DNS64 (via SSH):
   - SSH to device
   - Configure forwarding to DNS64 resolver

Note: Full NAT64 support varies by UniFi model and firmware. Consider using ISP-provided NAT64 or external gateway.

pfSense Configuration

pfSense 2.6+ supports NAT64 and DNS64 via packages.

Install necessary packages:

System > Package Manager > Available Packages

Install:
- bind (for DNS64)
- tayga (for NAT64 - alternative to Jool)

Configure TAYGA NAT64:

Services > TAYGA

Enable: Yes
IPv4 Pool: 203.0.113.10/28
IPv6 Prefix: 64:ff9b::/96

Configure DNS64 in BIND:

Services > BIND > Settings

Custom Options:
  dns64 64:ff9b::/96 {
    clients { any; };
    mapped { any; };
  };

Troubleshooting Common Issues

Problem 1: Clients Not Receiving IPv6 Addresses

Symptoms:

Diagnosis:

# On client
ip -6 addr show
# Look for 2001:xxxx addresses

# On router
sudo tcpdump -i eth0 icmp6
# Should see Router Advertisement packets

Solutions:

  1. Verify Router Advertisements are being sent:

    sudo radvdump
    # Should show RA packets with prefix information
    
  2. Check radvd configuration:

    sudo systemctl status radvd
    sudo journalctl -u radvd
    
  3. Verify prefix delegation from ISP:

    # Check DHCPv6-PD status
    ip -6 addr show
    # Look for delegated prefix
    
  4. Restart client networking:

    # Linux
    sudo systemctl restart NetworkManager
    
    # Windows
    ipconfig /release6
    ipconfig /renew6
    

Problem 2: DNS64 Not Synthesizing AAAA Records

Symptoms:

Diagnosis:

# Test DNS64 directly
dig AAAA ipv4only.example.com @2001:db8:1234::53

# Should return 64:ff9b::x.x.x.x addresses

Solutions:

  1. Check DNS64 configuration in BIND:

    sudo named-checkconf
    sudo journalctl -u bind9
    
  2. Verify dns64 block in configuration:

    dns64 64:ff9b::/96 {
      clients { any; };
      mapped { any; };
      recursive-only yes;
    };
    
  3. Test with known IPv4-only domain:

    dig A ipv4.test-ipv6.run  # Should return IPv4
    dig AAAA ipv4.test-ipv6.run @YOUR_DNS64  # Should synthesize IPv6
    
  4. Check DNSSEC validation:

    # DNS64 can conflict with DNSSEC
    # In named.conf.options:
    dnssec-validation auto;  # Usually works
    # Or temporarily disable to test:
    dnssec-validation no;
    

Problem 3: NAT64 Translation Failing

Symptoms:

Diagnosis:

# Test NAT64 translation
curl -6 -v http://ipv4only.example.com/

# Check NAT64 gateway status
sudo jool -i "enterprise-nat64" stats display

# Verify forwarding enabled
sysctl net.ipv6.conf.all.forwarding
sysctl net.ipv4.conf.all.forwarding
# Both should return 1

Solutions:

  1. Verify Jool is running:

    sudo jool instance display
    # Should show your NAT64 instance
    
  2. Check IPv4 pool configuration:

    sudo jool -i "enterprise-nat64" pool4 display
    # Should show configured IPv4 addresses and port ranges
    
  3. Verify routing:

    # On NAT64 gateway
    ip -6 route get 64:ff9b::8.8.8.8
    # Should route through correct interface
    
    ip route get 8.8.8.8
    # Should route through IPv4 interface
    
  4. Check firewall rules:

    # Ensure ICMPv6 and forwarding allowed
    sudo nft list ruleset | grep forward
    
  5. Test with tcpdump:

    # On NAT64 gateway IPv6 side
    sudo tcpdump -i eth0 -n 'dst 64:ff9b::/96'
    
    # On NAT64 gateway IPv4 side
    sudo tcpdump -i eth1 -n 'src 203.0.113.0/24'
    # Should see translated packets
    

Problem 4: Applications Using IPv4 Literals Fail

Symptoms:

Cause: IPv4 literals bypass DNS64 synthesis. Applications connecting directly to IPv4 addresses require 464XLAT CLAT.

Solutions:

  1. Deploy 464XLAT CLAT on clients:

    • Android/iOS: Automatic with carrier 464XLAT
    • Linux: Install clatd (see Client Configuration section)
    • Windows 11: Enable CLAT feature
    • Router-based: OpenWRT with 464XLAT package
  2. Advertise PREF64 via Router Advertisements:

    # In radvd.conf
    PREF64 64:ff9b::/96 { };
    

    This allows CLAT implementations to discover NAT64 prefix automatically.

  3. Update applications to use DNS names:

    • Contact app developers to use DNS instead of IPv4 literals
    • This is the long-term solution for IPv6 compatibility

Problem 5: Slow Performance / High Latency

Symptoms:

Diagnosis:

# Compare latencies
ping6 google.com  # Native IPv6
ping6 64:ff9b::8.8.8.8  # Via NAT64

# Traceroute to identify bottleneck
traceroute6 ipv4only.example.com

Solutions:

  1. Deploy NAT64 gateway closer to clients:

    • Reduce network hops between clients and NAT64 gateway
    • Consider distributed NAT64 deployment
  2. Upgrade NAT64 gateway hardware:

    • Ensure sufficient CPU for translation processing
    • Use hardware-accelerated NAT64 if available
  3. Check pool4 exhaustion:

    sudo jool -i "enterprise-nat64" stats display | grep -i "pool"
    # High pool utilization causes performance degradation
    
  4. Increase IPv4 pool size:

    sudo jool -i "enterprise-nat64" pool4 add --tcp 203.0.113.11 1024-65535
    # Add more IPv4 addresses to pool
    
  5. Consider stateless NAT64:

    • For high-performance scenarios with available IPv4 space
    • 1:1 mapping reduces translation overhead

Problem 6: DNSSEC Validation Failures

Symptoms:

Cause: DNS64 synthesis breaks DNSSEC validation chain (synthesized records aren't signed by domain owner).

Solutions:

  1. Configure DNS64 to validate before synthesis:

    # BIND configuration
    dnssec-validation auto;
    
    dns64 64:ff9b::/96 {
      # DNS64 validates A records, then synthesizes
    };
    
  2. Use trusted recursive resolver:

    • Deploy DNS64 as trusted infrastructure
    • Clients trust resolver to validate before synthesis
  3. Disable DNSSEC validation (not recommended for production):

    # Only for testing
    dnssec-validation no;
    
  4. Encourage services to deploy IPv6:

    • Native IPv6 eliminates need for DNS64 synthesis
    • No DNSSEC complications with native AAAA records

Testing and Validation Procedures

Network-Level Testing

Test 1: Verify IPv6 Connectivity

# From client device
ping6 google.com
ping6 2001:4860:4860::8888

# Should succeed with low latency

Test 2: Verify DNS64 Operation

# Query IPv4-only domain
dig AAAA ipv4.example.com

# Expected: AAAA record with 64:ff9b:: prefix
# Example: 64:ff9b::c000:201 (embedding 192.0.2.1)

Test 3: Verify NAT64 Translation

# Access IPv4-only service
curl -6 -v http://ipv4only.example.com/

# Should succeed with HTTP 200 response

Test 4: Verify 464XLAT (if deployed)

# Check for CLAT interface
ip addr show clat  # Linux/Android
ip addr show clat4  # Alternative name

# Should show 192.0.0.x address

# Test IPv4 literal access
curl -4 http://8.8.8.8  # Should work via CLAT+PLAT

Test 5: Performance Validation

# Measure IPv6 latency
ping6 -c 10 google.com

# Measure NAT64 latency
ping6 -c 10 64:ff9b::8.8.8.8

# Compare results (NAT64 should be <5ms additional latency)

Comprehensive Testing with test-ipv6.run

For thorough validation, use test-ipv6.run which performs:

  1. IPv4 Connectivity Test - Verifies IPv4 works (via NAT64 in IPv6-only)
  2. IPv6 Connectivity Test - Confirms native IPv6 functionality
  3. Dual-Stack Test - Validates both protocols work simultaneously
  4. IPv4 Latency Measurement - Measures IPv4 (or NAT64) performance
  5. IPv6 Latency Measurement - Measures native IPv6 performance
  6. Protocol Preference Detection - Determines browser preference

IPv6-Only Network Expected Results:

This tool provides comprehensive diagnostics and identifies misconfigurations that could impact user experience.

Application Testing

Test critical applications:

  1. Web browsing - Both IPv6 and IPv4-only sites
  2. Email clients - SMTP/IMAP/POP3 over IPv6
  3. Video streaming - YouTube, Netflix (prefer native IPv6)
  4. VoIP/Video conferencing - Zoom, Teams, WebEx
  5. Mobile apps - Especially those using IPv4 literals
  6. VPN clients - Verify compatibility with IPv6-only
  7. Cloud services - AWS, GCP, Azure connectivity

Create test matrix:

Application | IPv6 Native | IPv4 via NAT64 | 464XLAT | Status
------------|-------------|----------------|---------|-------
Chrome      | ✓           | ✓              | ✓       | OK
Zoom        | ✓           | ✓              | ✓       | OK
WhatsApp    | ✓           | ✗              | ✓       | Needs CLAT
VPN Client  | ✗           | ✗              | ✗       | Not compatible

Monitoring and Ongoing Validation

Set up continuous monitoring:

  1. NAT64 gateway metrics:

    # Create monitoring script
    #!/bin/bash
    while true; do
      echo "=== $(date) ==="
      sudo jool -i "enterprise-nat64" stats display | grep -E "(sessions|pool4)"
      sleep 300
    done
    
  2. DNS64 query logging:

    # BIND query logging
    logging {
      channel queries_log {
        file "/var/log/bind/queries.log" versions 3 size 10m;
        print-time yes;
      };
      category queries { queries_log; };
    };
    
  3. Connectivity alerts:

    • Monitor IPv6 reachability to external services
    • Alert on NAT64 pool exhaustion
    • Track DNS64 synthesis rates
  4. Performance baselines:

    • Establish normal latency ranges
    • Monitor for degradation
    • Compare IPv6 vs NAT64 paths

Best Practices Summary

Planning Phase

  1. Assess readiness - Verify ISP support, hardware compatibility, application requirements
  2. Choose deployment model - Enterprise on-premises vs ISP-provided vs cloud-managed
  3. Plan addressing - Design IPv6 subnets, choose NAT64 prefix
  4. Document architecture - Create network diagrams and configuration documentation

Implementation Phase

  1. Deploy DNS64 first - Ensure name resolution works before NAT64
  2. Configure NAT64 gateway - Use well-known prefix 64:ff9b::/96 for simplicity
  3. Enable PREF64 advertisements - Allow automatic 464XLAT CLAT discovery
  4. Configure firewalls carefully - Never block ICMPv6, allow necessary forwarding
  5. Test thoroughly - Validate each component before moving to next

Operation Phase

  1. Monitor continuously - Track NAT64 performance, pool utilization, connectivity
  2. Test regularly - Use test-ipv6.run for periodic validation
  3. Update documentation - Maintain current network diagrams and runbooks
  4. Train support staff - Ensure helpdesk understands IPv6-only troubleshooting
  5. Plan for native IPv6 - Monitor and encourage services to deploy AAAA records

Optimization Phase

  1. Analyze traffic patterns - Identify high-NAT64 usage to target for native IPv6
  2. Reduce translation dependency - Encourage adoption of native IPv6 services
  3. Scale infrastructure - Add NAT64 capacity as network grows
  4. Review security - Regular firewall audits, access control reviews

Conclusion

IPv6-only networks represent the future of Internet infrastructure, offering simplified operations, unlimited addressing, and reduced costs compared to dual-stack deployments. With NAT64/DNS64 and 464XLAT providing seamless backward compatibility, organizations can confidently deploy IPv6-only networks while maintaining complete access to IPv4-only services.

Key takeaways:

Deployment success factors:

  1. Thorough planning - Assess requirements, design architecture, document plans
  2. Phased implementation - Deploy DNS64, NAT64, PREF64, firewall in sequence
  3. Comprehensive testing - Validate each component, test applications, measure performance
  4. Continuous monitoring - Track metrics, identify issues early, optimize performance
  5. Regular validation - Use tools like test-ipv6.run to verify operation

As the Internet completes its transition to IPv6, IPv6-only networks provide the optimal path forward—eliminating legacy IPv4 complexity while maintaining universal connectivity through proven translation mechanisms.

Ready to verify your IPv6-only network? Visit test-ipv6.run for comprehensive connectivity testing and IPv6 readiness scoring.


Further Reading

IETF RFCs:

Implementation Resources:

Case Studies:


Last updated: 2025-10-26

Comprehensive IPv6 connectivity testing available at test-ipv6.run