Publishing a DNS AAAA record declares to the world that a hostname can be reached over IPv6. However, having an AAAA record is not proof that IPv6 actually works. On today's dual-stack internet, broken IPv6 routes, unconfigured firewall rules, missing web server bindings, and silent packet drops frequently leave IPv6 broken while IPv4 operates completely normally.
The AAAA Record Fallacy
Many administrators add an AAAA record during an IPv6 deployment checklist and test the domain in their regular web browser. The site loads immediately, leading to the conclusion that IPv6 is working properly.
In reality, modern browsers implement Happy Eyeballs (RFC 8305). When a client requests a dual-stack domain, the browser initiates parallel connection attempts to both the IPv6 and IPv4 addresses, with a slight head start (typically 50–250ms) given to IPv6. If the IPv6 handshake fails or hangs, the browser silently falls back to IPv4. To the end user, the website appears functional, but all traffic actually travels over IPv4 — completely masking a broken IPv6 setup.
The Stages of an IPv6 Connectivity Test
To diagnose true IPv6 reachability from an external perspective, testing must isolate each layer of the network stack:
- DNS AAAA Discovery: First, verify that authoritative nameservers publish valid IPv6 addresses (AAAA records). If no AAAA records exist, clients cannot initiate IPv6 connections.
- TCP Handshake (Port 443 / 80): Attempt a direct TCP three-way handshake over IPv6 to the published addresses. This reveals whether IPv6 routing works and whether upstream firewalls or security groups permit inbound IPv6 SYN packets.
- TLS & HTTP/HTTPS Negotiation: Complete the TLS handshake and retrieve an HTTP status code over IPv6. This verifies that the web server (e.g., Nginx, Envoy, Caddy) has explicit IPv6 listening sockets configured (
listen [::]:443) and presents a valid certificate for the requested SNI host. - Dual-Stack Comparison: Run the same checks over IPv4 simultaneously to determine whether failures are isolated to IPv6 or represent a total service outage.
Common IPv6 Failure Modes
1. IPv4 Works, IPv6 Fails (The Split-Brain Failure)
This is the most critical failure mode for dual-stack services. IPv4 connects promptly, but IPv6 handshakes time out or reset. Because IPv6-only clients (such as mobile networks in many regions) have no IPv4 fallback, those users experience total site outages.
Common causes include:
- Cloud Security Groups: Inbound IPv4 firewall rules (
0.0.0.0/0) were created on port 443, but corresponding IPv6 rules (::/0) were forgotten. - Missing Server Bindings: The web server process is listening on
0.0.0.0:443instead of[::]:443, oripv6only=onis improperly configured. - Orphaned AAAA Records: When changing hosting providers, the IPv4 A record was updated, but an old AAAA record pointing to the decommissioned server was left behind.
2. Multiple IPv6 Addresses With Mixed Results
High-availability architectures and CDN services often publish multiple IPv6 addresses for a single domain. If one origin or edge node in the pool has degraded routing or an expired TLS certificate, visitors routed to that specific IP experience intermittent connection drops. Testing all published IPv6 addresses individually isolates the malfunctioning node.
3. TCP Connects, But HTTPS Fails
If the TCP three-way handshake succeeds but the TLS handshake stalls or resets, the issue is typically:
- Path MTU Black Hole: IPv6 packets require a minimum MTU of 1280 bytes and do not support in-flight fragmentation by routers. If ICMPv6 Type 2 ("Packet Too Big") messages are blocked by an overly aggressive firewall, large TLS ClientHello or Certificate packets cannot pass, causing handshakes to hang.
- SNI / Vhost Mismatch: The web server terminates TLS on IPv4 virtual hosts correctly, but the default IPv6 virtual host lacks the required certificate.
Why ICMP Ping Can Be Misleading
ICMPv6 is essential for core IPv6 operations like Neighbor Discovery and Path MTU Discovery. However, many transit networks, corporate firewalls, and CDN edge proxies intentionally block incoming ICMP echo requests ("ping").
A failed ICMP ping does not mean IPv6 is broken if TCP and HTTPS traffic complete successfully. A robust IPv6 diagnostic treats TCP/HTTPS availability as the primary truth and reports ICMP reachability as supplementary diagnostic data.
How to Verify and Troubleshoot
To diagnose your own systems:
- Use the IPv6 Connectivity Checker to test public DNS, TCP, and HTTPS negotiation from PacketFlo's neutral server.
- Inspect DNS records using DNS Lookup with record type set to
AAAA. - Test specific IPv6 ports with Port Checker to determine whether non-web services (such as SSH on port 22 or SMTP on port 25) accept IPv6 connections.
- Inspect certificate validity and cipher negotiation using the SSL Certificate Checker.
Frequently Asked Questions
Why isn't having an AAAA record enough to prove IPv6 works?
An AAAA record in DNS merely maps a hostname to an IPv6 address; it does not verify that the server at that address is running, that routing to it exists, that firewalls allow traffic through, or that the web server is listening on IPv6 sockets.
What is Happy Eyeballs, and why does it hide IPv6 problems?
Happy Eyeballs (RFC 8305) is an algorithm implemented in web browsers and operating systems to prevent dual-stack delays. If an IPv6 connection attempt fails or takes too long, the browser automatically and silently falls back to IPv4. This makes a website appear healthy to visitors on dual-stack connections even when its IPv6 configuration is completely broken.
Why does ping fail if web traffic over IPv6 succeeds?
Many hosting providers, CDNs, and cloud firewalls drop ICMP echo requests (ping) while allowing TCP traffic on ports 80 and 443. If TCP and HTTPS checks succeed over IPv6, your IPv6 web service is healthy even if ICMP ping does not return an echo reply.
How do I fix 'IPv4 works, IPv6 fails' on my server?
Check three common bottlenecks: 1) Security Groups / Firewall: Ensure inbound traffic on ports 80 and 443 is permitted from ::/0 (IPv6 anywhere), not just 0.0.0.0/0. 2) Web Server Configuration: In Nginx, ensure you have listen [::]:443 ssl; alongside listen 443 ssl;. In Apache, ensure Listen 443 is not bound exclusively to an IPv4 address. 3) DNS Records: Verify that the IP in your AAAA record matches the current public IPv6 address assigned to your network interface.