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:
Simplified Network Management
Address Efficiency
Cost Reduction
T-Mobile US (2013-present)
Verizon Wireless
Telstra (2020)
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).
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.
┌──────────────────────────────────────────────────────────────┐
│ 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│
└─────────────┘
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)
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
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
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.
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/
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.
For home networks, IPv6-only deployment is simpler but requires router support or ISP-provided NAT64/DNS64.
Many modern ISPs (especially mobile carriers) provide NAT64/DNS64 infrastructure. This is the simplest deployment option.
Configuration steps:
WAN Settings:
Connection Type: IPv6 Only
IPv6 Address: Automatic (DHCPv6 or SLAAC)
IPv6 DNS: Automatic (from ISP)
LAN Settings:
IPv6 Assignment: SLAAC + DHCPv6
Router Advertisement: Enabled
IPv6 DNS: Automatic (forward ISP DNS64)
Verification:
# Check if DNS64 is working
dig AAAA ipv4only.example.com
# If you get 64:ff9b:: addresses, DNS64 is active
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
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
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:
Result: All apps work, including those using IPv4 literals (games, VoIP, etc.)
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 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
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
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
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 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 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; };
};
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:
Verify Router Advertisements are being sent:
sudo radvdump
# Should show RA packets with prefix information
Check radvd configuration:
sudo systemctl status radvd
sudo journalctl -u radvd
Verify prefix delegation from ISP:
# Check DHCPv6-PD status
ip -6 addr show
# Look for delegated prefix
Restart client networking:
# Linux
sudo systemctl restart NetworkManager
# Windows
ipconfig /release6
ipconfig /renew6
Symptoms:
Diagnosis:
# Test DNS64 directly
dig AAAA ipv4only.example.com @2001:db8:1234::53
# Should return 64:ff9b::x.x.x.x addresses
Solutions:
Check DNS64 configuration in BIND:
sudo named-checkconf
sudo journalctl -u bind9
Verify dns64 block in configuration:
dns64 64:ff9b::/96 {
clients { any; };
mapped { any; };
recursive-only yes;
};
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
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;
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:
Verify Jool is running:
sudo jool instance display
# Should show your NAT64 instance
Check IPv4 pool configuration:
sudo jool -i "enterprise-nat64" pool4 display
# Should show configured IPv4 addresses and port ranges
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
Check firewall rules:
# Ensure ICMPv6 and forwarding allowed
sudo nft list ruleset | grep forward
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
Symptoms:
Cause: IPv4 literals bypass DNS64 synthesis. Applications connecting directly to IPv4 addresses require 464XLAT CLAT.
Solutions:
Deploy 464XLAT CLAT on clients:
Advertise PREF64 via Router Advertisements:
# In radvd.conf
PREF64 64:ff9b::/96 { };
This allows CLAT implementations to discover NAT64 prefix automatically.
Update applications to use DNS names:
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:
Deploy NAT64 gateway closer to clients:
Upgrade NAT64 gateway hardware:
Check pool4 exhaustion:
sudo jool -i "enterprise-nat64" stats display | grep -i "pool"
# High pool utilization causes performance degradation
Increase IPv4 pool size:
sudo jool -i "enterprise-nat64" pool4 add --tcp 203.0.113.11 1024-65535
# Add more IPv4 addresses to pool
Consider stateless NAT64:
Symptoms:
Cause: DNS64 synthesis breaks DNSSEC validation chain (synthesized records aren't signed by domain owner).
Solutions:
Configure DNS64 to validate before synthesis:
# BIND configuration
dnssec-validation auto;
dns64 64:ff9b::/96 {
# DNS64 validates A records, then synthesizes
};
Use trusted recursive resolver:
Disable DNSSEC validation (not recommended for production):
# Only for testing
dnssec-validation no;
Encourage services to deploy IPv6:
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)
For thorough validation, use test-ipv6.run which performs:
IPv6-Only Network Expected Results:
This tool provides comprehensive diagnostics and identifies misconfigurations that could impact user experience.
Test critical applications:
Create test matrix:
Application | IPv6 Native | IPv4 via NAT64 | 464XLAT | Status
------------|-------------|----------------|---------|-------
Chrome | ✓ | ✓ | ✓ | OK
Zoom | ✓ | ✓ | ✓ | OK
WhatsApp | ✓ | ✗ | ✓ | Needs CLAT
VPN Client | ✗ | ✗ | ✗ | Not compatible
Set up continuous monitoring:
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
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; };
};
Connectivity alerts:
Performance baselines:
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:
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.
IETF RFCs:
Implementation Resources:
Case Studies:
Last updated: 2025-10-26
Comprehensive IPv6 connectivity testing available at test-ipv6.run