In February 2025, the Internet Engineering Task Force (IETF) approved the charter of the new Working Group ‘Heuristics and Algorithms to Prioritize Protocol deploYment (happy)‘. Currently, its main goal is to standardize Happy Eyeballs Version 3.
The first version of Happy Eyeballs (HE) was standardized by the IETF in 2012 as RFC 6555 by the v6ops Working Group. It describes a mechanism to prefer IPv6 for dual-stack hosts while ensuring a fast fallback to IPv4 when IPv6 fails.
In 2017, the initial version was obsoleted by HEv2, which maintained the focus on selecting between IPv4 and IPv6. The new Working Group and draft version expand the scope to include transport protocols like QUIC and Transport Layer Security (TLS) over TCP, and security mechanisms like Encrypted Client Hello (ECH).
While the HEv1 and HEv2 standards include recommendations for HE parameter choices, it is up to the client and OS to implement HE. Together with researchers from the Technical University of Munich and the Max Planck Institute for Informatics, we set out to analyse the state of HE implementations before developing a new standard.
Happy Eyeballs versions
HEv1
HEv1 (RFC 6555) focuses on basic connection attempts from a client to a server (the grey area in Figure 1). The idea is to race the connection establishment between IPv6 and IPv4 addresses, while prioritizing one address family based on the host’s address selection policy. If the Domain Name System (DNS) returns multiple records for each address family, the host orders them according to its address selection policy.
HEv1 recommends falling back to IPv4 after the first IPv6 attempt fails, even if multiple IPv6 addresses are available. If the initial IPv6 and IPv4 connections fail, HEv1 does not provide further instructions on the order of subsequent connection attempts, leaving this decision up to the application developers.
The core parameter of HEv1 is the Connection Attempt Delay (CAD), which is recommended to be within 150-250ms (see Table 1). If a client’s IPv6 connection is not successfully established within this delay, the client should initiate a parallel IPv4 connection. When one connection attempt succeeds, the client discards the others and should cache the outcome for ‘the order of 10 min’.
HEv2
HEv2 (RFC 8305) additionally considers DNS (see the complete process in Figure 1) and extends the description of the address selection.
In HEv2, a client should:
- Issue a AAAA query, immediately followed by an A query
- Initiate a connection attempt via IPv6 if a AAAA response is received first
- Wait for a Resolution Delay (RD) of 50ms if an A response is received first
- Initiate a connection attempt via IPv6 if a AAAA response arrives during the RD
- Initiate a connection attempt via IPv4 after the RD if no AAAA response is received
This behaviour prioritizes IPv6 while minimizing the user-visible delay if it is impaired.
HEv2 extends the description of address selection as follows:
- Uses a predefined policy to select from the retrieved addresses
- Interlaces the address list to alternate between IP address families
- Places an IPv6 address at the top of the list to maintain IPv6 preference
- Allows the list to begin with multiple IPv6 addresses
- Defines the number of initial same-family addresses as the First Address Family Count, recommended to be one or two to aggressively favour one family (as shown in Table 1)
Like in HEv1, the client then proceeds to establish a connection using the previously selected addresses. To prevent network congestion, it uses the CAD between subsequent attempts. HEv2 recommends a fixed CAD of 250ms. For history-inferred implementations, it defines an absolute minimum CAD of 10ms, recommends a minimum of 100ms, and a maximum CAD of 2s (see Table 1).
HEv3
As of 2025, the new ‘HAPPY’ IETF Working Group is working on an HEv3 draft. HEv3 proposes an approach to using existing Service Binding (SVCB) or HTTPS DNS resource records to support protocol discovery. The HEv3 address selection should favour IP addresses that support TLS ECH using QUIC, if available, or TCP if QUIC is not available. Besides those changes, HEv3 is currently like HEv2, using the same parameters and recommendations.
| HEv1 (2012) | HEv2 (2017) | HEv3 (2025 – ongoing) | |
| Considered protocols | IPv4, IPv6 | IPv4, IPv6, DNS | IPv4, IPv6, DNS, QUIC, … |
| DNS records | – | A, AAAA | SVCB, HTTPS, AAAA, A |
| Resolution delay | – | 50ms | 50ms |
| Address selection | IPv6 once, then IPv4 | alternating | IP family and L4 protocol |
| Fixed connection attempt delay | 150-250ms | 250ms | 250ms |
| Min/Rec. / Max when dynamic | – | 10ms/100ms/2s | 10ms/100 ms/2s |
Measuring the current state of Happy Eyeball implementations
Tests and testbed
We created different test scenarios to evaluate how clients using HEv1 and v2 algorithms connect to servers implemented:
- The CAD
- The RD
- The address selection, given multiple addresses of both families
We implemented these test cases in two different setups.
- A local testbed that eliminates any network effects.
- A web-based testing tool that allows everybody to test their client behaviour.
The source code for both tools is publicly available and can be used to evaluate current implementations and future changes of Happy Eyeballs implementations.
Our local testbed runs on Ubuntu 24.0.1 and includes several browsers:
- Mozilla Firefox
- Google Chrome
- Microsoft Edge
- Chromium
- Popular HTTP clients, wget and curl
We included browser versions as old as January 2021. Additionally, we measured Safari (17.5) on macOS.
To validate the results from the local testbed, we collected 161 web-based measurement results, each with at least ten repetitions per delay configuration. Results cover nine browsers in 22 versions running on seven operating systems. That amounts to a total of 33 different combinations. Table 2 provides an overview of our results.
Results: CAD
While all client applications prefer IPv6 if both versions are offered, wget (1.21.3) does not fall back to IPv4 in any of our test cases. All Chromium-based browsers use a CAD of 300ms. The command-line tool curl uses the smallest CAD of 200ms. Firefox follows the RFC recommendation of 250ms, but has a few outliers where it waits longer than 250ms for the IPv6 connection establishment.
In contrast to other browsers that matched our local measurements, we observed a wide range of CAD values for Safari in our web-based measurements. While local measurements were consistent at 2s, they ranged from 50ms up to 5s on the web, indicating a dynamic application of CAD. Moreover, Apple announced and deployed iCloud Private Relay (iCPR), a privacy-preserving proxying service, in December 2021.
As part of iCPR, Safari can relay traffic via an egress operator using MASQUE proxying. Connections via iCPR show completely different HE behaviour compared to Safari. The reason is that Safari does not create an IP tunnel via the relay network but only informs the egress node about the name of the server it wants to connect to. The egress node handles the DNS resolution and the stack up to the transport protocol headers of TCP and UDP. Therefore, measurements via iCPR show how the egress operators implement HE. For example, Akamai and Cloudflare egress nodes use a CAD of 150ms and 200ms, respectively.
| Prefers IPv6 | CAD implemented | AAAA first1 | RD implemented | IPv4 address used | IPv6 address used | Address selection2 | |
| Chrome 130.0 | ⬤ | ⬤ | ⬤ | ◯4 | 1 | 1 | ◯ |
| Chromium 130.0 | ⬤ | ⬤ | ⬤ | ◯4 | 1 | 1 | ◯ |
| Edge 130.0 | ⬤ | ⬤ | ⬤ | ◯ | 1 | 1 | ◯ |
| Firefox 132.0 | ⬤ | ⬤ | ◯ | ◯ | 1 | 1 | ◯ |
| Safari 17.6 | ⬤ | ⬤ | ⬤ | ⬤ | 10 | 10 | ⬤ |
| Mobile Safari | ⬤ | ⬤ | ⬤ | ⬤ | – | – | – |
| Chrome Mobile | ⬤ | ⬤ | ⬤ | ◯ | – | – | – |
| curl 7.88.1 | ⬤ | ⬤ | ⬤ | ◯ | 1 | 1 | ◯ |
| wget3 1.21.3 | ⬤ | ◯ | ◯ | ◯ | – | 1 | ◯ |
Table 2 — Evaluation of client applications implementation of HE features with our local and web-based measurement tools and their consistency between the measurement methods. ⬤ Observed as defined; ◐ Observed with RFC deviation; ◯ Not observed;1 Can also depend on the operating system’s stub resolver, except for Chromium-based browsers, which use their own stub resolver; 2 No web test validation; 3 Does not implement any type of HE; 4 Offers a flag to enable feature (HEv3 flag).
Results: RD
The RD test case delays the AAAA record to observe how clients implement the RD. Already, the testbed measurement results show that only Safari actually implements it. We found Safari to be using the RFC recommendation of 50ms. In their default state, Chromium-based browsers and Firefox depend on the resolver’s timeout. They do not apply any DNS resolution timeout on their own. A notable finding of our measurements is that some clients delay IPv6 connection initialization if an A record response has not been received. More detailed results about the resolution delay and the impact of DNS resolvers on results can be found in our paper.
We also operate a publicly available instance of our web-based measurement tool at Happy Eyeballs Webtester. If you want to contribute to our research, you can provide us with some information on your network state, as the tool does not collect any personally identifiable information (PII) like client IP address, subnet, or AS number by itself. We are actively working with the community to expand the tool with HEv3 tests and to provide additional features to enable more HE tests.
Conclusion
We systematically approach the measurement of how clients have implemented Happy Eyeballs features.
All widely used browsers prefer IPv6 connections when possible.
Except for Safari, which employs a dynamic, unpredictable approach, the observed CAD values are within a 50ms interval of the 250ms RFC suggestion.
Only Safari implements an RD and address selection mechanisms, thus HEv2.
In contrast, Chromium-based browsers and Firefox delay IPv6 connection initialization until the corresponding DNS A record arrives, even though IPv6 address information is available and preferred.
We suggest that all clients implement a timeout for DNS queries, even when HE is not implemented. The current situation is that slow A queries also slow down IPv6, even when IPv6 is not the cause of slower responses. This may contribute to negative perceptions of IPv6 and adversely affect IPv6 deployment.
Patrick Sattler is a data engineer at BENOCS GmbH and a guest scientist at the Technical University of Munich. He has published extensively on important Internet technologies, including IPv6, QUIC, TLS, and others.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.