HAPPY

Summary

The HAPPY working group met at IETF 125 to discuss progress on the main algorithm specification, implementation experience in Firefox, and new proposals for path selection observability. Significant focus was placed on refining the behavior of draft-ietf-happy-happyeyeballs-v3 in complex network environments, such as IPv6-only networks with NAT64 and split-tunnel VPNs. Firefox shared details on their new Rust-based implementation of Happy Eyeballs v3 (HEv3) and their plans for public telemetry. A new experimental proposal for signaling path selection failures via ICMP was also introduced.

Key Discussion Points

Happy Eyeballs v3

Nidhi and Tommy Pauly presented updates on Happy Eyeballs v3.

Recent Changes: The draft now recommends a "should" for waiting for TLS handshakes. It clarifies that connection attempt delays should not change for resumed connections (0-RTT). Text was added to address MTU issues and the handling of historical data across network changes.
IPv6-only and VPN Scenarios: Jen Linkova summarized a proposal to handle split-tunnel VPNs and NAT64 environments. The proposed logic suggests that if a global IPv6 address exists in the Provisioning Domain (PVD), the client should request AAAA; if a NAT64 prefix is discovered or a non-loopback IPv4 address exists, it should request A. Synthesized IPv6 addresses should be treated as IPv4 candidates for racing purposes.
Scope and PVDs: Ben Schwartz questioned whether multi-interface/VPN logic was in scope. Lorenzo Colitti and Tommy Pauly suggested using the term "PVD" instead of "interface" to better describe consistent configuration sets, noting that split-tunnels often involve multiple interfaces within one logical PVD.
Document Structure: Ben Schwartz proposed a significant refactoring of the draft to separate normative requirements from the example algorithm. He argued for making the requirements more abstract and the algorithm more "algorithmic" (potentially using pseudo-code). Tommy Pauly and Lorenzo Colitti discussed the distinction between a Standards Track document and a Best Current Practice (BCP), noting that much of HE is focused on user experience rather than protocol interoperability.

HEv3 in Firefox

Max Resing presented on HEv3 in Firefox.

Implementation: Firefox has implemented HEv3 as a standalone, deterministic Rust library (available on GitHub). It is currently in Firefox Nightly (disabled by default) and supports HTTPS DNS RRs and DNS over HTTPS (DoH).
Telemetry: Mozilla plans to collect public telemetry on Time to First Byte (TTFB), resolution delays, and the number of connection attempts.
OS vs. Application: Stewart Cheshire emphasized that Happy Eyeballs should ideally be implemented in the OS network stack so all applications benefit, citing the difference between iOS (stack-level) and Android (historically browser-level). Lorenzo Colitti noted the difficulty for cross-platform applications like Chrome or Firefox to rely on OS libraries that may not support the necessary cross-layer (DNS/TLS/QUIC) optimizations.

Slow Alternate Detection and Path Selection Observability

Brian Trammell presented Slow Alternate Detection and Path Selection Observability.

Proposal: An experimental mechanism using a new ICMP type/code to signal to the network and server when a path was "slow" or not selected by the Happy Eyeballs algorithm.
Technical Details: The signal would include a hashed DNS answer to link the failure to a specific domain without leaking full SNI/ECH information. It includes a sample rate parameter to prevent ICMP spam.
Feedback: Ben Schwartz and Lars Eggert raised significant privacy concerns regarding the hashed DNS answer, noting it could still leak destination information. Lars Eggert also questioned the feasibility of userspace applications sending ICMP on modern restricted operating systems. Lucas Pardue suggested that in-band signaling (e.g., HTTP/2 frames or QUIC error codes) might be more actionable for server operators.

Decisions and Action Items

Terminology Change: The working group reached a sense of the room to move away from the word "interface" and instead use "Provisioning Domain" (PVD) to describe the scope of the algorithm's inputs. Tommy Pauly will file an issue to track this.
VPN/IPv6-only Text: Jen Linkova and Andre Mesarovic (via GitHub) will refine the text regarding A/AAAA query triggers and the treatment of synthesized addresses to ensure split-tunnel VPN cases are handled correctly.
Restructuring: Tommy Pauly, Nidhi, and Ben Schwartz will collaborate on a compromise for the document structure that improves clarity between normative requirements and implementation guidance without unnecessary repetition.

Next Steps

Main Draft: The authors will incorporate the PVD terminology and the agreed-upon VPN/IPv6-only logic into draft-ietf-happy-happyeyeballs-v3.
Implementation Feedback: Max Resing will share initial telemetry results from Firefox Nightly at IETF 126 to help tune recommendation values (e.g., resolution delays).
Observability: Discussion on path signaling will continue on the mailing list, specifically looking at privacy-preserving alternatives to ICMP.

Automatic IETF Minutes