Summary

  • Happy Eyeballs protects users by trying viable addresses without waiting too long for a broken or slow family. That design can make an aggregate success rate look healthy while IPv6 is failing.
  • Operators need family-specific evidence: answers returned, candidates attempted, winning family, losing errors and forced-family results for representative access cohorts.

Imagine a morning in which the main synthetic monitor is green, checkout completion is steady and support reports no outage. A second probe, forced to use IPv6 from one access network, cannot connect. Both observations can be true. The ordinary client received A and AAAA answers, started an IPv6 attempt, then established IPv4 quickly enough that the user saw only a small delay.

This is a hypothetical diagnostic, not a report about a named network. It exposes a measurement mistake. Transaction success proves that one usable path completed the work. It does not prove that every advertised address family was healthy.

RFC 8305 defines Happy Eyeballs v2 to reduce user-visible delay when addresses or entire families are blocked, broken or suboptimal. The procedure begins asynchronous A and AAAA resolution, orders candidate destinations, starts connection attempts with controlled staggering, and keeps the connection that succeeds. Other attempts are then cancelled. The algorithm generally prefers IPv6, but availability is the immediate objective.

The recommended timers illustrate why dashboards can miss the defect. RFC 8305 gives 50 milliseconds as a resolution-delay default and 250 milliseconds as a connection-attempt delay when no historical round-trip estimate is available. Implementations can adapt these values and use remembered performance. They are not universal client behaviour. The durable fact is the race: the winning application connection may reveal little about the losing candidate unless the client exports that evidence.

Address selection adds another layer. RFC 6724 orders source and destination choices across IPv6 and IPv4 and permits administrative policy to override defaults. A host can therefore prefer a family because of policy, address scope, source availability or learned usability. Two clients asking for the same name can create different candidate orders and take different paths without either violating the standards.

An aggregate HTTP success counter collapses these decisions into one bit. It omits whether AAAA arrived, which IPv6 address was tried, how long it waited, whether the failure was DNS, neighbour discovery, routing, filtering, path MTU or the destination service, and whether IPv4 won by policy or rescue. It can also hide concentration: fallback may occur only in one mobile network, home-router generation, operating-system release or enterprise security stack.

The minimum evidence record belongs at connection setup. Preserve the A and AAAA answers and their arrival times; ordered destination candidates; source and destination family; start and completion time for every attempt; losing error or timeout; winning family; resolver path; access ASN or cohort; destination edge; application outcome; client implementation and observation time. Do not infer a failure cause from fallback alone.

Pair ordinary dual-stack checks with forced-IPv6 and forced-IPv4 canaries. The ordinary check protects the customer journey. The forced checks test the individual control surfaces. A dual-stack success with a failed IPv6 canary should remain available and visibly degraded, not be promoted to full health.

RFC 6556 approached the problem through controlled testing of dual-stack user experience. That distinction still matters: a test has to say which family it exercised and what impairment it introduced. A green browser result is not a substitute for a protocol-family experiment.

Sources