Summary

  • RFC 6555 framed dual-stack fallback as a short race between address families; RFC 8305 replaced that example with a complete scheduling sequence for name resolution, destination ordering and connection attempts.
  • The recommended 250 ms connection-attempt delay is not merely a performance constant. It allocates time between a preferred path, a fallback path and the extra network load created by parallel work.
  • Racing protects users from slow or broken initial TCP/IP paths, but it can conceal faults from operators, preserve dependence on IPv4 and leave application-layer failures untouched.

In April 2012, RFC 6555 gave a name to an experience rather than to a new wire protocol. A dual-stack host could receive IPv6 and IPv4 destinations, prefer IPv6 as the architecture intended, and still make a user wait when that preferred path was impaired. The RFC's example kept the host's address-preference order, started the first connection, and after a short interval launched the first address from the other family. Firefox and Chrome were then using 300 milliseconds. Whichever connection became established first was retained; the competing one was discarded.

That simple rule changed who bore the cost of an incomplete transition. Without racing, a user paid in visible delay for an operator's broken IPv6 path. With racing, the client spent a little extra work to insure the user against that failure. The mechanism therefore joined three interests that were not perfectly aligned: the user wanted the first usable connection, the standards architecture wanted IPv6 preference, and the network wanted to avoid an indiscriminate multiplication of attempts.

RFC 6555 explicitly resisted turning fallback into permanent IPv4 preference. When no useful history existed, IPv6 remained preferred, and implementations were warned not to impose needless IPv4 load throughout what was already expected to be a long transition. The 300 ms example was a compromise, not a universal timeout. Too long and the mechanism stops protecting the user. Too short and almost every ordinary connection becomes a two-family race, consuming sockets, packets and server work even when the first path would have succeeded.

By December 2017, deployment and measurement had exposed the limits of describing the mechanism as one timer between two attempts. RFC 8305 obsoleted RFC 6555 and specified a scheduler with four connected stages. A client sends asynchronous DNS queries, sorts all returned destination addresses, starts asynchronous connection attempts on a staggered schedule, then retains one successful connection and cancels the remaining work.

The DNS stage already contains a race. RFC 8305 recommends asking for AAAA first and issuing A immediately afterward rather than serialising the queries. If A arrives first, a recommended 50 ms Resolution Delay gives AAAA a brief opportunity to arrive. This keeps a quick IPv4 answer from mechanically excluding IPv6 while avoiding a long wait for a missing or delayed answer. Answers may also change while setup is under way, so the scheduler must be able to add newly learned destinations rather than treating the first response as final.

Sorting is the next control surface. Destination-address selection supplies the base order, but an implementation may use historical round-trip time or evidence that an address worked previously on the same network. The list is interleaved across address families. That detail matters: a host with several unusable addresses in one family should not force the client to exhaust all of them before trying a viable address in the other.

RFC 8305 recommends a default Connection Attempt Delay of 250 ms. It recommends 100 ms as a minimum, says the value must never fall below 10 ms, and recommends a maximum of two seconds. The First Address Family Count is recommended to be one. These are empirical engineering values, deliberately adjustable as networks and implementations evolve. They price two harms: the human cost of waiting and the system cost of speculative work. A lower delay buys latency at the price of more overlapping attempts. A higher delay saves load but makes the chosen preference order more visible whenever it is wrong.

The resulting algorithm is broader than a contest between one IPv6 address and one IPv4 address. It handles multiple destinations, changing DNS answers, local history, and IPv6-only access using NAT64/DNS64. It also draws a firm boundary. Happy Eyeballs handles initial TCP/IP connection failure. It does not make a successful transport carry a functioning application, and it cannot cure later application-layer refusal or protocol failure.

Its operational paradox is therefore central, not incidental. A user sees a page open and concludes the network worked. The client may know that the preferred path lost, but that information is not necessarily visible to the operator who owns the fault. RFC 6555 already recognised that racing makes address-family failures harder to diagnose; RFC 8305 notes examples such as path-MTU problems that can remain masked. A mechanism that improves aggregate reliability can reduce the salience of the component failure responsible for the race.

Happy Eyeballs should thus be understood as a compatibility bargain. It preserves an IPv6 preference without making the user its involuntary tester, while keeping IPv4 available as an insurance asset. But insurance changes incentives. If fallback is fast enough, a broken IPv6 path may generate fewer complaints; if IPv4 always wins, applications and operators retain reasons to keep scarce IPv4 capacity. The scheduler cannot resolve that political economy. It can only make the trade explicit in delays, ordering, history and telemetry.