Free — no signup required

Happy Eyeballs: The Dual-Stack Race

2 min read

Avoiding the Delay

During the early years of IPv6 deployment, a frustrating problem emerged: users with IPv6 enabled on their networks experienced slower web browsing than users on pure IPv4. The cause was broken IPv6 paths. An ISP might advertise IPv6 support, but the actual path to a destination would silently fail — packets would be dropped somewhere in the middle, and the OS would wait for a TCP connection timeout (often 20 seconds) before falling back to IPv4. Users blamed "IPv6" for being slow, when the real problem was broken routing.

Happy Eyeballs (RFC 6555, updated by RFC 8305) is the algorithm that solved this perception problem. It is implemented in every modern browser and most operating systems.

The Algorithm

User visits google.com
│
├─ Step 1: DNS queries sent simultaneously
│   ├─ Query for A record (IPv4)
│   └─ Query for AAAA record (IPv6)
│
├─ Step 2: First DNS response arrives (usually AAAA, since IPv6 is preferred)
│   └─ Start TCP/TLS handshake to IPv6 address
│
├─ Step 3: Wait 250ms (the "resolution delay")
│   └─ If IPv6 handshake succeeds → use it, cancel IPv4 attempt
│   └─ If 250ms passes with no success → start IPv4 handshake in parallel
│
└─ Step 4: Whichever handshake completes first wins
    └─ Losing connection is immediately closed

The 250ms delay gives IPv6 a head start (since it is preferred) while ensuring that a broken IPv6 path adds at most 250ms of latency before IPv4 kicks in — barely perceptible to users.

Why IPv6 is Preferred

When both IPv4 and IPv6 are available, IPv6 is preferred by default (per RFC 6724, the Default Address Selection rules). This is intentional — the internet needs to migrate to IPv6, and preferring it when available accelerates adoption. Happy Eyeballs makes this preference safe by ensuring broken IPv6 never degrades user experience.

Real-World Impact

Google's internal data showed that before Happy Eyeballs, users with broken IPv6 paths experienced 20-second delays. After browser adoption of Happy Eyeballs, the penalty dropped to under 250ms. This was the key enabler for major websites to enable IPv6 by default — they no longer had to worry about penalizing users with misconfigured IPv6.

Key Point: Happy Eyeballs is what made IPv6 deployment safe for major websites. Without it, any broken IPv6 path would cause user-visible slowness, creating a disincentive to enable IPv6. The algorithm's elegance is that it requires no network changes — it is purely a client-side behavior that makes dual-stack networks transparent to end users.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free