Happy Eyeballs Version 2: Better Connectivity Using Concurrency
obsoletes
- rfc-6555 — Happy Eyeballs: Success with Dual-Stack Hosts
Extracted elements (26)
A minimum Connection Attempt Delay of 10 ms (recommended 100 ms) is required to avoid congestion collapse in the presence of high packet-loss rates; without a floor, historical RTT data could drive attempts so close together they overwhelm the network.
The algorithm interleaves address families rather than exhausting one family at a time to avoid waiting through a long list of addresses from a given family if connectivity over that family is impaired. This provides the racing benefit of Happy Eyeballs across all resolved addresses, not just the first IPv4 and first IPv6 pair.
The delay values (Resolution Delay 50 ms, Connection Attempt Delay 250 ms, Minimum 100 ms, Maximum 2 s, Last Resort Local Synthesis Delay 2 s) were determined empirically by measuring timing of connections on a very wide set of production devices, chosen to reduce user-visible wait times while minimizing network load. These values are expected to increase over time as IPv6 reliability improves.
A simple implementation of RFC 8305 remains compliant with the predecessor RFC 6555. RFC 8305 adds handling for multiple addresses per family, DNS updates during racing, historical RTT leverage, and NAT64/DNS64 support — none of which were addressed by RFC 6555.
Happy Eyeballs only addresses initial TCP/IP handshake failures. Issues such as Path MTU Discovery problems, application-layer failures (TLS, HTTP), and operational misconfigurations (broken IPv6 on a network) may be masked or undetected by the algorithm.
After a connection succeeds, the DNS client resolver SHOULD still process DNS replies from the network for a short period (recommended 1 second) to populate the DNS cache for subsequent connections, even if the asynchronous DNS query may be canceled.
After sorting, the client SHOULD interleave address families in the ordered list so that the first address of each family alternates; an implementation MAY allow multiple addresses of the first family (First Address Family Count) before trying the other family.
Client systems SHOULD NOT have an explicit limit to the number of DNS servers that can be configured. If such a limit is required by hardware, the client SHOULD use at least one address from each address family from the available list.
Connection attempts SHOULD NOT be made simultaneously; instead one attempt is started first and subsequent attempts are staggered. Once one connection succeeds, all other pending attempts SHOULD be canceled and any un-attempted addresses SHOULD be ignored.
DNS queries SHOULD be sent over IPv6 first when multiple DNS server addresses are configured. If DNS queries to the IPv6 address receive no responses, that address may be marked as penalized and queries sent to other DNS server addresses.
During connection setup, if an address already being attempted is removed from DNS answers, the connection attempt SHOULD NOT be canceled. If an address not yet attempted is removed, it SHOULD be removed from the list. New addresses added to DNS answers should be sorted into the list of un-attempted addresses.
If a positive A response arrives first, the client SHOULD wait the Resolution Delay (recommended 50 ms) for the AAAA response before proceeding to address sorting and staggered connection attempts using available IPv4 addresses.
If the client is stateful and has RTT history, it SHOULD add a Destination Address Selection rule between rules 8 and 9 preferring lower-RTT addresses, and another rule preferring previously used addresses. This historical RTT data MUST NOT be used across different network interfaces and SHOULD be flushed when the network changes.
Implementations SHOULD NOT wait for both families of DNS answers to return before attempting connection establishment; the client SHOULD treat DNS resolution as asynchronous to avoid delaying the first connection attempt.
On platforms without 464XLAT, the Happy Eyeballs engine SHOULD follow the NAT64/DNS64 recommendations in Section 7. These features SHOULD only be enabled when the host detects an IPv6-only network with NAT64 (routable IPv6, no routable IPv4, DNS resolver available).
The client MUST sort all resolved destination addresses using Destination Address Selection per RFC 6724 Section 6 before initiating connection attempts.
The Connection Attempt Delay MUST have a lower bound; a subsequent connection MUST NOT be started within 10 milliseconds of the previous attempt. The recommended minimum (Minimum Connection Attempt Delay) is 100 milliseconds. The maximum (Maximum Connection Attempt Delay) SHOULD be bounded, with a recommended value of 2 seconds.
When a client has both IPv4 and IPv6 connectivity, it SHOULD send both AAAA and A DNS queries as soon as possible, with the AAAA query made first and immediately followed by the A query.
For IPv4 address literals on IPv6-only networks, the Happy Eyeballs engine queries the network for the NAT64 prefix (RFC 7050), synthesizes IPv6 addresses using RFC 6052 encoding, inserts them into the candidate list, and proceeds with the standard connection algorithm.
The Connection Attempt Delay is the time to wait before starting the next connection attempt. The recommended default is 250 milliseconds. A more nuanced implementation should target the time when the previous attempt would send its second TCP SYN, based on the TCP retransmission timer (RFC 6298).
The First Address Family Count is the configurable number of contiguous addresses of the first address family attempted before trying the other family. The recommended value is 1; a value of 2 may be used to more aggressively favor a particular address family.
The Happy Eyeballs Connection Setup has four distinct phases: (1) initiation of asynchronous DNS queries, (2) sorting of resolved destination addresses, (3) initiation of asynchronous connection attempts, and (4) establishment of one connection that cancels all other attempts. The algorithm assumes IPv6 is preferred over IPv4.
The Resolution Delay is the time the client waits for a AAAA response after receiving an A response first (due to reordering), to ensure preference is given to IPv6. The recommended value is 50 milliseconds.
To handle hostnames with broken AAAA records (valid addresses that never reply) on IPv6-only/NAT64 networks, the client starts a Last Resort Local Synthesis Delay timer (recommended 2 seconds) when the last connection attempt fires. If no connection succeeds when the timer fires, the client queries the DNS for the A record and synthesizes an IPv6 address locally.
VPN scenarios where internal hostnames resolve to external IPv4 addresses with no route on an IPv6-only underlying network require the client to resolve the A record via the VPN resolver and locally synthesize an IPv6 address using the NAT64 prefix, as if the address were application-provided.
Applications MUST NOT rely on a stable hostname-to-address mapping to ensure security properties, since DNS results may change between queries. Happy Eyeballs increases the likelihood that subsequent connections to a single hostname use different IP addresses.