Visual RFC.
ALL RFCs / RFC 8305
Read the RFC ↗

RFC 8305 / START HERE

Happy Eyeballs v2, before the details

Happy Eyeballs is a name for reducing connection delay, not an acronym. Version 2 is the algorithm described by RFC 8305.

When a name has several IPv6 and IPv4 addresses, a client can start staggered connection attempts and keep the first successful connection rather than waiting a long time for one broken path.

Start the guide See the 6 chapters ↓

The idea in one picture

  1. Resolve candidates

  2. Stagger attempts

  3. Keep one winner

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

This December 2017 Proposed Standard replaces RFC 6555. It coordinates asynchronous DNS answers, destination ordering, connection pacing and cancellation, with special handling for detected IPv6-only translation networks.

A familiar example

Imagine trying several entrances to a building, starting the next try after a short wait while earlier tries continue. Once one opens, stop the remaining tries. An open entrance does not prove the service inside is working or trustworthy.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

DNS wireRFC 1035 · beginner overview ↗TCPRFC 9293 · beginner overview ↗IPv6RFC 8200 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Resolve addresses without waiting for every answerDNS discovery and connection establishment overlap so one slow answer need not block usable candidates.
  2. Rank all candidates, then interleave familiesA race needs an ordered list containing all currently available candidate addresses.
  3. Stagger attempts and stop after the first successNew attempts can start while earlier attempts remain pending, without launching the whole list at once.
  4. React to DNS changes according to progressA changing answer list affects waiting candidates differently from attempts that already started.
  5. Handle detected IPv6-only translation networksNAT64/DNS64 contexts can need local address synthesis rather than direct IPv4 attempts.
  6. Keep pacing, application health and identity distinctRecommended defaults control load and delay; they do not guarantee that the selected service works or is trusted.
Start with chapter one →

This introduction explains RFC 8305 (2017). Read the original RFC ↗