Keep pacing, application health and identity distinct
06Recommended defaults control load and delay; they do not guarantee that the selected service works or is trusted.
One winning path does not authenticate the server or certify both address families. Monitoring and application security remain separate.
Source for this drawing: RFC 8305 · Read RFC section 8 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The replacement explicitly covers asynchronous DNS handling, multiple candidates per family, answer changes, history and IPv6-only NAT64/DNS64 contexts; it refines the original connection-racing description.
Read the updated RFC section ↗The first completed connection is not a complete health or security verdict.
- Section8 summarizes configurable recommendations: Resolution Delay50ms, First Address Family Count1 (2 may favor a family), Connection Attempt Delay250ms, recommended minimum100ms and maximum2s, plus2s last-resort local synthesis. The hard MUST-NOT bound is a subsequent start within10ms. The chosen clamp helper enforces that floor while allowing explicitly configured alternatives; recommended values are not universal MUSTs (§§5,8).
- These values reflect measurements discussed in this December2017 publication, not new measurements by this site. The document expects values to evolve and says delays SHOULD increase over time as client software is updated and IPv6 issues become less common. Do not infer that a current installation must use every pictured number (§8).
- Happy Eyeballs handles initial TCP/IP connection failures. TLS or HTTP can still fail after the winning handshake, because not every address necessarily hosts a functional application. The illustration stops at that application failure; it does not claim that RFC8305 silently repairs it by creating another successful session (§9.2).
- A small handshake can succeed while later traffic encounters path-MTU problems. Such failures can be masked during the initial race; solving them is outside this RFC. Section9.1 points to Packetization Layer Path MTU Discovery. The comparison is schematic, with no invented universal handshake size or packet MTU (§9.1).
- Fallback can hide persistent IPv6 problems from users, so operators are advised to monitor both families separately. Applications should not rely on a stable hostname-to-IP mapping for security, since DNS results and selected addresses can change. Winning a race does not authenticate an endpoint, establish TLS trust, or certify the unused family’s health (§§9.3,10).
Fictional offline examples. The default policy here prefers IPv6. V6-A/B/C and V4-A/B name distinct candidate destinations, not protocol fields. Helpers model selected decisions from already ranked addresses; they are not full DNS, RFC6724/source selection, TCP, TLS, NAT64 discovery or a network implementation. Times and equality ordering are stated example choices.
Read the RFC section ↗