Summary

  • Happy Eyeballs reduces user-visible delay by overlapping candidate connections; the winner proves reachability only for that candidate.
  • DNS arrival, address ordering, attempt timing, failure and cancellation must be retained per family.
  • Product success and dual-stack health are different operational claims.

Consider one illustrative episode: a page loads uneventfully after AAAA and A answers arrive, the client starts IPv6, IPv4 follows, and IPv4 completes first. The user sees no outage. A dashboard built only from completed sessions also sees no outage. Yet IPv6 may have encountered a path or service problem, or merely been cancelled before it had time to answer. The winning connection cannot distinguish those cases.

RFC 8305 specifies the racing behaviour from which this ambiguity can arise. Its Happy Eyeballs Version 2 procedure starts A and AAAA resolution close together, sorts the available destinations using RFC 6724, interleaves address families, and starts connection attempts after controlled delays. Once one attempt succeeds, the others should be cancelled. In this article's editorial assessment, that can protect availability because a defective option need not impose its full timeout on the user.

But cancellation destroys a naive health inference. An IPv6 attempt marked “cancelled” after an IPv4 win is not an IPv6 success, and it is not necessarily an IPv6 failure. It is censored evidence. Equally, an IPv4 winner does not prove that the policy preferred IPv4: DNS timing, RFC 6724 ordering and remembered round-trip times can all shape the race.

The familiar 250-millisecond value is also not a service-level truth. RFC 8305 offers it as one recommended default Connection Attempt Delay. It permits adaptation, sets safety bounds, and separates that delay from the shorter Resolution Delay used when A arrives before AAAA. A useful receipt therefore records actual values and timestamps, not merely “Happy Eyeballs enabled.”

The standard itself names hiding operational issues as a limitation. This is the central control problem. A client feature can improve availability while weakening the signal that would cause an operator to repair IPv6, DNS, routing, firewall or listener defects. The correct response is not to disable racing. It is to measure the losing and cancelled paths without making the user wait for them.

For each connection episode, preserve the network context, resolver path, A and AAAA arrival times, ordered candidate list, family, configured Resolution Delay, configured or adapted Connection Attempt Delay, actual attempt offset, handshake milestone, per-attempt outcome, application outcome, cancellation reason, winner, and the network scope and lifetime of any cached connection history used by the algorithm.

As an editorial operational recommendation, aggregate this evidence within a limited retention window: the aim is not a permanent record of individual browsing, but enough bounded evidence to separate resolution delay, policy ordering, path failure, server rejection and ordinary race cancellation.

RFC 6555, which RFC 8305 replaced, began from a pragmatic observation: broken IPv6 could create unacceptable delay. The newer algorithm refines that remedy. Neither document says a recovered session certifies the losing family. RFC 6724 likewise defines selection policy, not a probe result. Operators should keep those semantics separate.