]> Google Switzerland GmbH

ietf@trammell.ch

Web and Internet Transport Heuristics and Algorithms to Prioritize Protocol deploYment icmp happy eyeballs debugging measurement This document specifies Slow Alternate Detection (SAD) for Happy Eyeballs, an ICMP-based advisory path signal for exposing information about path non-selection on-path devices in order to aid debugging and measurement of Happy Eyeballs. About This Document Status information for this document may be found at . Discussion of this document takes place on the Heuristics and Algorithms to Prioritize Protocol deploYment Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Happy Eyeballs 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 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.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Message Format (ICMP) The message format for SAD is identical for both ICMPv4 and ICMPv6, and is depicted in

SAD Message Format

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.

Code 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 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 for the use of this message. When present, the Additional Data field of a Not Selected contains the DNS Message associated with the answer that

Hash Algorithm (HAlg) 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
2-15	undef	Reserved for Future Use

Approximate Sample Rate TODO: allows the sender to expose a sample rate, if applied. Design an encoding for common useful sample rates.

5-tuple fields 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.

Additional Data The Additional Data contains code-specific additional data. If present, it MUST be hashed with a hash algorithm specified by the Hash Algorithm field.

Protocol Behaviors Each of the (currently one) message code(s) associated with the SAD message has an associated protocol behavior, defined below.

Not Selected 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 ), it MUST NOT include the hashed DNS Answer in the Not Selected message.

Security Considerations TODO analyze various attacks against this approach.

IANA Considerations 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 .

References Normative References Apple Inc Google LLC Google LLC Google LLC Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. Federal Information Processing Standard, FIPS Informative References This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.

Acknowledgments 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.