Happy Eyeballs: Success with Dual-Stack Hosts
obsoleted by
- rfc-8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrency
Extracted elements (23)
IPv6 is given preference over IPv4 (not just equal treatment) to reduce load on IPv4 infrastructure such as NAT devices and load-balancers, enabling ISPs and content providers to reduce IPv4 investment. Treating both address families equally based solely on connection speed would sustain IPv4 load and make IPv6 transition more expensive.
Non-winning connections are recommended to be abandoned (rather than reused) to reduce server file descriptors and TCP control block usage, reduce stateful middlebox (NAT/firewall) state, and prevent HTTP cookie and same-origin policy breakage that occurs when connections from the same client arrive from different IP address families.
Single shared hostnames for IPv4 and IPv6 are required (rather than separate namespaces like 'ipv6.example.com') to avoid namespace fragmentation that would reduce the ability for users to share hostnames and complicate printed material.
The 10-minute retry interval for a failed preferred address family avoids simple doubling of connection attempts on both IPv6 and IPv4, while still allowing the algorithm to detect when the preferred path becomes functional again. It can be implemented by flushing Happy Eyeballs state every 10 minutes.
The scope of Happy Eyeballs is limited to connection-oriented transports (TCP, SCTP) because connectionless protocols (UDP) require application-level request/response semantics (as used by ICE) to determine connectivity, which is outside this document's scope.
Using a 150-250 ms pacing interval rather than aggressive millisecond-scale timeouts is chosen because aggressive timeouts create billable traffic on some networks, create state in middleboxes (firewalls, IDS, NATs), and consume shared IPv4 ports; the longer interval still achieves imperceptible delay for users.
Happy Eyeballs applies only to connection-oriented transports (TCP, SCTP). For connectionless protocols such as UDP, a similar mechanism can be used only if the application has request/response semantics, as done by ICE for media path selection.
The interaction of Happy Eyeballs with hosts having three or more logical interfaces (e.g., due to VPN tunnels, multiple physical interfaces, or VLANs) is explicitly left for further study.
Web browsers implement a same-origin policy that causes subsequent connections to the same hostname to go to the same IPv4 or IPv6 address as the previous successful connection; Happy Eyeballs must not violate this policy even though it may reduce responsiveness in failure scenarios.
A Happy Eyeballs algorithm SHOULD re-initialize when the interface is connected to a new network, since every network has different characteristics (e.g., working or broken IPv6 or IPv4 connectivity).
A stateful Happy Eyeballs implementation that falls back to a non-preferred address family MUST occasionally make connection attempts using the host's preferred address family (as it may have become functional again) and SHOULD do so every 10 minutes.
After performing connection attempts, the client MUST cache information regarding the outcome of each connection attempt and use that information to avoid thrashing the network with subsequent attempts. Cache entries should be flushed when their age exceeds a system-defined maximum on the order of 10 minutes.
If connections using the preferred address family are again successful after a failure period, the preferred address family SHOULD be used for subsequent connections.
Implementations MUST prefer the first IP address family returned by the host's address preference policy unless implementing a stateful algorithm. If the host's policy is unknown or not attainable, implementations MUST prefer IPv6 over IPv4.
It is RECOMMENDED that connection attempts be paced 150-250 ms apart to balance human factors against network load, rather than using aggressive timeouts on the order of tens of milliseconds.
It is RECOMMENDED that the non-winning connections be abandoned, even though they could in some cases be put to reasonable use, in order to reduce load on the server and stateful middleboxes and reduce IPv4 address sharing contention.
Web browsers MUST NOT change their same-origin policy because of Happy Eyeballs, as doing so would create an additional security exposure.
Web site operators with native IPv6 connectivity SHOULD NOT offer multiple AAAA records because, for clients without Happy Eyeballs and with broken IPv6 connectivity, multiple AAAA records further increase the delay before falling back to IPv4.
When a DNS query returns multiple A or AAAA records, it is RECOMMENDED that a Happy Eyeballs implementation order the responses following the host's address preference policy and try the first address; if that fails, the next address SHOULD be an IPv4 address.
The Happy Eyeballs algorithm initiates a connection attempt with the preferred address family (typically IPv6), and if that connection does not complete within a short period (Firefox and Chrome use 300 ms), initiates a second attempt with the first address of the other address family (IPv4). The first connection established is used and the other is discarded.
Abandoning non-winning connections is recommended to reduce the risk of HTTP cookie-based attacks and same-origin policy violations that can occur when a client holds simultaneous connections to the same hostname from different IP address families.
Web browsers MUST NOT modify their same-origin policy to accommodate Happy Eyeballs behavior, because allowing connections to different IP addresses for the same origin would create additional security vulnerabilities beyond the connectivity benefits gained.
A stateful Happy Eyeballs implementation transitions from 'prefer IPv6' to 'prefer IPv4' when an IPv6 connection attempt fails within the timeout period. It returns to 'prefer IPv6' after 10 minutes (by flushing state) and retrying; if IPv6 succeeds again, it remains in the 'prefer IPv6' state. State is reset on network re-initialization.