Lazy Eye Inspection: Capturing the State of Happy Eyeballs Implementations

TL;DR

This work investigates real-world Happy Eyeballs deployments across browsers and resolvers, comparing HEv1, HEv2, and the evolving HEv3 landscape. It deploys a dual measurement framework—a controlled local testbed and a web-based tool—to measure CAD $($Connection Attempt Delay$)$, RD $($Resolution Delay$)$, and address selection, plus resolver behavior, across nine browsers and multiple OSes. Key findings show that while most browsers prefer IPv6 when available, Safari uniquely implements RD and interleaving features, and DNS A-record delays can throttle IPv6 performance in Chrome and Firefox; iCloud Private Relay further alters HE behavior. The authors release the test framework and a public web tool to enable broad, ongoing evaluation, underscoring the need for standardization and closer coordination with DNS resolvers as HE evolves.$CAD$,$RD$.$ECH$.$TLS$.

Abstract

Happy Eyeballs (HE) started out by describing a mechanism that prefers IPv6 connections while ensuring a fast fallback to IPv4 when IPv6 fails. The IETF is currently working on the third version of HE. While the standards include recommendations for HE parameters choices, it is up to the client and OS to implement HE. In this paper we investigate the state of HE in various clients, particularly web browsers and recursive resolvers. We introduce a framework to analyze and measure client's HE implementations and parameter choices. According to our evaluation, only Safari supports all HE features. Safari is also the only client implementation in our study that uses a dynamic IPv4 connection attempt delay, a resolution delay, and interlaces addresses. We further show that problems with the DNS A record lookup can even delay and interrupt the network connectivity despite a fully functional IPv6 setup with Chrome and Firefox. We publish our testbed measurement framework and a web-based tool to test HE properties on arbitrary browsers.

Figures (5)

• Figure 1: Happy Eyeballs (v2): A client first resolves the server's name. Then it prioritizes the addresses based on a local policy and proceeds to attempt to establish a connection to the server. HEv1 only focuses on the connection establishment, HEv2 additionally includes the name resolution.
• Figure 2: IP address family of established connection as measured on our local testbed setup. We omitted Safari, which has a cad of 2s to improve the visibility of the remaining results.
• Figure 3: Overview of the local testbed and its components and configurations (see \ref{['sec:approach']}).
• Figure 4: Screenshots of our web-based testing tool website taken from measurements with Safari (see \ref{['sec:approach']}). We make the tool publicly available on accept to allow individuals to easily test and understand their client behavior.
• Figure 5: Address selection based on an internal priority list. The plot shows the address family used by browsers at the n-th connection attempt.