Summary

  • Dual stack exposed a gap between DNS and reachability: an A or AAAA record supplies a candidate address, not proof that a transport connection can cross the current path.
  • RFC 6555 kept IPv6 as the preferred family but bounded its power to delay the user; RFC 8305 refined the method into asynchronous DNS, RFC 6724 sorting, family interleaving and staggered attempts.
  • The first completed setup wins only that connection. The mechanism improves user experience while potentially concealing the losing family's persistent faults from operators.

The address was true; the path was not

The transition problem was visible long before it acquired its cheerful name. RFC 1671, published in 1994, asked what a dual-stack host should do when DNS returned alternatives but one path crossed a black hole. A record could be correctly published while the host, tunnel, peering or intermediate network was not presently able to carry the protocol.

Serial connection logic made that discrepancy expensive. If policy placed IPv6 first, the application could send a SYN and wait through retransmissions before trying a working IPv4 address. An IPv4-only client appeared responsive; the supposedly more capable dual-stack client appeared broken. Users and administrators had an obvious escape: disable IPv6. A transition mechanism whose failure penalty trained people to turn it off was working against its own destination.

The tempting remedies were also poor. Separate ipv6.example names would divide a shared namespace. Static whitelists could not follow intermittent failures across every client path. DNS could advertise addresses, but it could not observe the route from this client at this moment. The missing fact belonged at connection time.

Preference became a head start

RFC 6555 standardized Happy Eyeballs in 2012. Its essential move was not to declare IPv4 and IPv6 equal. The host's address policy still usually preferred IPv6. The algorithm simply refused to turn that preference into a long exclusive lease on the user's patience.

A client starts with the preferred candidate. If it does not complete promptly, another attempt begins over the other family while the first may remain in flight. The attempts are paced because every extra SYN can consume server state, firewall entries, NAT ports and network capacity. When one connection succeeds, the non-winners are abandoned. Preference governs who starts; measured setup governs who serves this connection.

That distinction matters economically as well as technically. A pure fastest-path contest could keep unnecessary traffic on shared IPv4 addresses and translators, making it harder to reduce legacy capacity. An absolute IPv6 rule could punish users for faults outside their control. Happy Eyeballs placed a slight thumb on the transition scale, then let failure evidence lift it.

RFC 6555 also treated memory as provisional. A client could remember that one family had failed and avoid repeating the same delay, but it had to try the preferred family again periodically. The specification suggested an order of ten minutes and reset when the device joined a new network. Yesterday's broken tunnel was not authority over today's attachment.

Version 2 made DNS part of the race

By 2017, deployment experience allowed RFC 8305 to replace the first description with a more complete pipeline. A and AAAA queries begin almost together, AAAA first. The application need not wait for both. If A happens to arrive first, a recommended 50-millisecond resolution delay gives AAAA a brief chance to preserve IPv6's lead; if no useful AAAA arrives, IPv4 work can start.

The client then sorts the addresses using RFC 6724. That policy considers usable source addresses, scope, labels and other host knowledge. Sorting is not a connectivity certificate. It produces an informed order.

Happy Eyeballs v2 modifies that order by interleaving families. If the list begins with IPv6, the best IPv4 candidate normally moves into second place. This avoids waiting through five unreachable AAAA addresses before giving one IPv4 address a chance. The procedure races the whole candidate set, not merely one representative of each protocol.

Attempts begin one at a time and overlap. RFC 8305 recommends 250 milliseconds as a default connection-attempt delay. It forbids starting the next attempt within 10 milliseconds, recommends 100 milliseconds as the minimum and two seconds as the maximum. These are empirical, configurable bounds, not laws of nature. The document expects them to evolve as networks do.

History can refine the order, but only inside a defensible boundary. Expected round-trip time or a previously used address may influence selection. That memory must not leak across network interfaces and should be cleared when attachment changes. A hotel network's failure must not demote IPv6 after the laptop reaches home.

The winner proves less than it appears

The first successful attempt generally proves that a transport handshake completed. It does not prove that TLS will validate, HTTP will work, the application behind every address is consistent or large packets will survive the path. RFC 8305 explicitly notes that post-handshake Path MTU failures can remain hidden.

Nor does a winning address authenticate a server. DNS answers can change, and successive connections to one hostname may use different IP addresses. Identity belongs to the appropriate application security protocol, not to the race result.

The most important limitation is operational. If IPv6 fails every day while IPv4 wins after a quarter second, users may never complain. The client has converted an outage into a small latency increment. That is excellent resilience and poor fault visibility. RFC 8305 therefore calls for independent monitoring of all address families.

Happy Eyeballs did not settle the IPv4-versus-IPv6 argument. It designed a better boundary between policy and observation. Preference may choose the first experiment. It may not suppress contrary evidence indefinitely.

Sources and limits

The closed record is RFC 1671, RFC 6555, RFC 6724 and RFC 8305. These documents establish the problem, ordering rules, connection algorithm, recommended bounds and stated limitations. They do not supply current implementation shares, a universally optimal delay or evidence that one address family is globally healthier.