| Internet-Draft | Slow Alternate Detection for Happy Eyeba | November 2025 |
| Trammell | Expires 11 May 2026 | [Page] |
This document specifies Slow Alternate Detection (SAD) for Happy Eyeballs, an ICMP-based advisory path signal [RFC8558] for exposing information about path non-selection on-path devices in order to aid debugging and measurement of Happy Eyeballs.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-trammell-happy-sad/.¶
Discussion of this document takes place on the Heuristics and Algorithms to Prioritize Protocol deploYment Working Group mailing list (mailto:happy@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/happy/. Subscribe at https://www.ietf.org/mailman/listinfo/happy/.¶
Source for this draft and an issue tracker can be found at https://github.com/britram/happy-sad.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 May 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Happy Eyeballs [I-D.ietf-happy-happyeyeballs-v3] encourages new protocol deployment by reducing the availabity risk associated with attempting to use them. However, in doing so, it masks configuration and deployment failures of these very protocols. There are potential causes of such failures, with potential root causes at the end user terminal, CPE, access network, CDN, DNS configuration, and end server. Given the diffusion of root causes, debugging these errors can be difficult.¶
This document presents Slow Alternate Detection (SAD), an ICMP-based advisory path signal [RFC8558] to devices along the path of a non-selected candidate designed as part of an array of approaches to this problem. It is intended to be used together with complementary monitoring and logging information at each point along the potential failure chain of a non-selected candidate.¶
This design uses hashes of data relevant to a failure to allow the correlation of nonselection events to on path devices and actors who already have access to that data, while allowing only aggregate analysis by other on-path actors.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The message format for SAD is identical for both ICMPv4 and ICMPv6, and is depicted in Figure 1¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 44 | Code | HAlg | ASR | NextHdr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Transport Port | Destination Transport Port |
+-------------------------------+-------------------------------+
| Additional Data |
| (code-dependent) |
... ...
The Code, HAlg (Hash Algorithm), ASR (Approximate Sample Rate), Next Header and Source and Destination Transport Port, and Additional Data fields are described in the subsections below.¶
The ICMP Code for a SAD message takes one of the following values, and specifies the message's semantics as well as the meaning of the Additional Data field. It can take the following values:¶
| Code | Description | Additional Data |
|---|---|---|
| 0 | Not Selected | hashed DNS Answer |
| 1-255 | Reserved | not present |
Not Selected indicates that is sent to a non-selected candidate by the client, after it has made the decision not to use that candidate. See Section 4.1 for the use of this message.¶
When present, the Additional Data field of a Not Selected contains the DNS Message [RFC1035] associated with the answer that¶
The Hash Algorithm field determines both the length of the Additional Data field and the hash algorithm used to hash it. The following hash algorithms are available:¶
| Value | Length | Algorithm |
|---|---|---|
| 0 | 0 | Additional Data Omitted |
| 1 | 256 | SHA256 [RFC6234] |
| 2-15 | undef | Reserved for Future Use |
TODO: allows the sender to expose a sample rate, if applied. Design an encoding for common useful sample rates.¶
The Next Header (or Protocol) field contains the IP protocol (e.g. TCP, UDP) of the non-selected path. The Source and Destination Transport Port fields contain the source and destination port of the non-selected path. While this will not allow NAT transparency of the SAD message, it does allow analysis and correlation across the NAT by the operator thereof. If the candidate transport protocol does not have port numbers, or if the client chooses not to expose them, these fields are set to 0.¶
The Additional Data contains code-specific additional data. If present, it MUST be hashed with a hash algorithm specified by the Hash Algorithm field.¶
Each of the (currently one) message code(s) associated with the SAD message has an associated protocol behavior, defined below.¶
A client sends a Not Selected message after it has decided not to use a given candidate identified by the 5-tuple in the Not Selected message. There is no guarantee of the relative timing of the SAD Not Selected message and the transport layer shutdown datagrams associated with this nonselection.¶
The client may send Not Selected messages on only a sampled portion of its non-selected candidates. In this case, the client SHOULD expose the selected sample rate in the Approximate Sample Rate field.¶
As this is an advisory path signal, forwarding elements and servers MUST NOT take any action on the receipt of a Not Selected message beyond logging them for later analysis.¶
If the client knows that its DNS Answer message was retrieved from an off-path resolver (e.g., via DoH [RFC8484]), it MUST NOT include the hashed DNS Answer in the Not Selected message.¶
TODO analyze various attacks against this approach.¶
This document has two actions for IANA:¶
It requests the allocation of Type 44 in the ICMP Type Numbers registry for Slow Alternative Detection, with this document as reference on publication as an RFC.¶
It requests the establishment the Slow Alternative Detection ICMP Code Field subregistry initialized with the contents of Section 3.1.¶
Thanks to the participants in the discussions on error reporting at the HAPPY WG meetings at IETF 123 in Madrid, IETF 124 in Montreal, and on the mailing list in between, to which this document is an answer. Special thanks to Martin Duke for backronyming the name of this extension.¶