Skip to main content

Happy Eyeballs Version 3: Better Connectivity Using Concurrency
draft-pauly-v6ops-happy-eyeballs-v3-02

Document Type Active Internet-Draft (individual)
Authors Tommy Pauly , David Schinazi , Nidhi Jaju , Kenichi Ishibashi
Last updated 2024-08-26
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-pauly-v6ops-happy-eyeballs-v3-02
Network Working Group                                           T. Pauly
Internet-Draft                                                 Apple Inc
Intended status: Informational                               D. Schinazi
Expires: 28 February 2025                                        N. Jaju
                                                            K. Ishibashi
                                                              Google LLC
                                                          27 August 2024

    Happy Eyeballs Version 3: Better Connectivity Using Concurrency
                 draft-pauly-v6ops-happy-eyeballs-v3-02

Abstract

   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.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://tfpauly.github.io/draft-happy-eyeballs-v3/draft-pauly-v6ops-
   happy-eyeballs-v3.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-pauly-v6ops-happy-
   eyeballs-v3/.

   Source for this draft and an issue tracker can be found at
   https://github.com/tfpauly/draft-happy-eyeballs-v3.

Status of This Memo

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

Pauly, et al.           Expires 28 February 2025                [Page 1]
Internet-Draft              Happy Eyeballs v3                August 2024

   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 28 February 2025.

Copyright Notice

   Copyright (c) 2024 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Hostname Resolution Query Handling  . . . . . . . . . . . . .   4
     4.1.  Handling Multiple DNS Server Addresses  . . . . . . . . .   6
   5.  Sorting Addresses . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Sorting Based on Priority . . . . . . . . . . . . . . . .   8
   6.  Connection Attempts . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Determining successful connection establishment . . . . .  10
     6.2.  Handling Application Layer Protocol Negotiation (ALPN)  .  10
   7.  DNS Answer Changes During Happy Eyeballs Connection Setup . .  11
   8.  Supporting IPv6-Only Networks with NAT64 and DNS64  . . . . .  11
     8.1.  IPv4 Address Literals . . . . . . . . . . . . . . . . . .  12
     8.2.  Hostnames with Broken AAAA Records  . . . . . . . . . . .  12
     8.3.  Virtual Private Networks  . . . . . . . . . . . . . . . .  13
   9.  Summary of Configurable Values  . . . . . . . . . . . . . . .  13
   10. Limitations . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Path Maximum Transmission Unit Discovery . . . . . . . .  15
     10.2.  Application Layer  . . . . . . . . . . . . . . . . . . .  15
     10.3.  Hiding Operational Issues  . . . . . . . . . . . . . . .  15
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     13.2.  Informative References . . . . . . . . . . . . . . . . .  17

Pauly, et al.           Expires 28 February 2025                [Page 2]
Internet-Draft              Happy Eyeballs v3                August 2024

   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   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.

   This document defines the algorithm for "Happy Eyeballs", a technique
   for reducing user-visible delays on dual-stack hosts.  This
   definition updates the description in [HEV2], which itself obsoleted
   [RFC6555].

   The Happy Eyeballs algorithm of racing connections to resolved
   addresses has several stages to avoid delays to the user whenever
   possible, while preferring the use of IPv6.  This document discusses
   how to handle DNS queries when starting a connection on a dual-stack
   client, how to create an ordered list of destination addresses to
   which to attempt connections, and how to race the connection
   attempts.

   As compared to [HEV2], this document adds support for incorporating
   SVCB / HTTPS resource records (RRs) [SVCB].  SVCB RRs provide
   alternative endpoints and associated information about protocol
   support, Encrypted ClientHello [ECH] keys, address hints, among other
   relevant hints which may help speed up connection establishment and
   improve user privacy.  Discovering protocol support during
   resolution, such as for HTTP/3 over QUIC [RFC9114], allows upgrading
   between protocols on the current connection attempts, instead of
   waiting for subsequent attempts to use information from other
   discovery mechanisms such as HTTP Alternative Services [AltSvc].
   These records can be queried along with A and AAAA records, and the
   updated algorithm defines how to handle SVCB responses to improve
   address and protocol selection.

Pauly, et al.           Expires 28 February 2025                [Page 3]
Internet-Draft              Happy Eyeballs v3                August 2024

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Overview

   This document defines a method of connection establishment, named the
   "Happy Eyeballs Connection Setup".  This approach has several
   distinct phases:

   1.  Initiation of asynchronous DNS queries (Section 4)

   2.  Sorting of resolved destination addresses (Section 5)

   3.  Initiation of asynchronous connection attempts (Section 6)

   4.  Establishment of one connection, which cancels all other attempts
       (Section 6)

   Note that this document assumes that the preference policy for the
   host destination address favors IPv6 over IPv4.  IPv6 has many
   desirable properties designed to be improvements over IPv4 [IPV6].

   This document also assumes that the preference policy favors QUIC
   over TCP.  QUIC only requires one packet to establish a secure
   connection, making it quicker compared to TCP [QUIC].

   If the host is configured to have different preferences, the
   recommendations in this document can be easily adapted.

4.  Hostname Resolution Query Handling

   When a client has both IPv4 and IPv6 connectivity and is trying to
   establish a connection with a named host, it needs to send out both
   AAAA and A DNS queries.  Both queries SHOULD be made as soon after
   one another as possible, with the AAAA query made first and
   immediately followed by the A query.

Pauly, et al.           Expires 28 February 2025                [Page 4]
Internet-Draft              Happy Eyeballs v3                August 2024

   Additionally, if the client also wants to receive SVCB / HTTPS
   resource records (RRs) [SVCB], it SHOULD issue the SVCB query
   immediately before the AAAA and A queries (prioritizing the SVCB
   query since it can also include address hints).  If the client has
   only one of IPv4 or IPv6 connectivity, it still issues the SVCB query
   prior to whichever AAAA or A query is appropriate.  Note that upon
   receiving a SVCB answer, the client might need to issue futher AAAA
   and/or A queries to resolve the service name included in the RR.

   Implementations SHOULD NOT wait for all answers to return before
   attempting connection establishment.  If one query fails to return or
   takes significantly longer to return, waiting for the other answers
   can significantly delay the connection establishment of the first
   one.  Therefore, the client SHOULD treat DNS resolution as
   asynchronous.  Note that if the platform does not offer an
   asynchronous DNS API, this behavior can be simulated by making
   separate synchronous queries, each on a different thread.

   The algorithm for acting upon received answers depends on whether the
   client sent out queries for SVCB RRs.

   If the client did not request SVCB RRs:

   *  If a positive AAAA response (a response containing at least one
      valid AAAA RR) is received first, the first IPv6 connection
      attempt is immediately started.

   *  If a positive A response is received first (which might be due to
      reordering), the client SHOULD wait a short time for the AAAA
      response to ensure that preference is given to IPv6, since it is
      common for the AAAA response to follow the A response by a few
      milliseconds.  This delay is referred to as the "Resolution
      Delay".  If a negative AAAA response (no error, no data) is
      received within the Resolution Delay period or the AAAA response
      has not been received by the end of the Resolution Delay period,
      the client SHOULD proceed to sorting addresses (see Section 5) and
      staggered connection attempts (see Section 6) using any IPv4
      addresses received so far.

   If the client did request SVCB RRs:

Pauly, et al.           Expires 28 February 2025                [Page 5]
Internet-Draft              Happy Eyeballs v3                August 2024

   *  If the client receives any positive response back (containing a
      valid AAAA, A, or SVCB ServiceMode RR), it starts the Resolution
      Delay timer, which is run until both the AAAA and SVCB ServiceMode
      responses are received, or a SVCB response is received that also
      includes at least one address in the ipv6hint parameter.  Once a
      SVCB response and at least one IPv6 address have been received, or
      the timer expires, the client proceeds with the process of sorting
      addresses and staggered connection attempts.

   For both variations of the algorithm, the RECOMMENDED value for the
   Resolution Delay is 50 milliseconds.

   If new positive responses arrive while connection attempts are in
   progress, but before any connection has been established, then the
   newly received addresses are incorporated into the list of available
   candidate addresses (see Section 7) and the process of connection
   attempts will continue with the new addresses added, until one
   connection is established.

4.1.  Handling Multiple DNS Server Addresses

   If multiple DNS server addresses are configured for the current
   network, the client may have the option of sending its DNS queries
   over IPv4 or IPv6.  In keeping with the Happy Eyeballs approach,
   queries SHOULD be sent over IPv6 first (note that this is not
   referring to the sending of AAAA or A queries, but rather the address
   of the DNS server itself and IP version used to transport DNS
   messages).  If DNS queries sent to the IPv6 address do not receive
   responses, that address may be marked as penalized and queries can be
   sent to other DNS server addresses.

   As native IPv6 deployments become more prevalent and IPv4 addresses
   are exhausted, it is expected that IPv6 connectivity will have
   preferential treatment within networks.  If a DNS server is
   configured to be accessible over IPv6, IPv6 should be assumed to be
   the preferred address family.

   Client systems SHOULD NOT have an explicit limit to the number of DNS
   servers that can be configured, either manually or by the network.
   If such a limit is required by hardware limitations, the client
   SHOULD use at least one address from each address family from the
   available list.

Pauly, et al.           Expires 28 February 2025                [Page 6]
Internet-Draft              Happy Eyeballs v3                August 2024

5.  Sorting Addresses

   Before attempting to connect to any of the resolved destination
   addresses, the client should define the order in which to start the
   attempts.  Once the order has been defined, the client can use a
   simple algorithm for racing each option after a short delay (see
   Section 6).  It is important that the ordered list involve all
   addresses from both families and all protocols that have been
   received by this point, as this allows the client to get the racing
   effect of Happy Eyeballs for the entire list, not just the first IPv4
   and first IPv6 addresses.

   Note that the following sorting steps are an incremental sort,
   meaning that the client SHOULD sort within each sorted group for each
   incremental step.

   If any of the answers were from SVCB RRs, they SHOULD be sorted ahead
   of any answers that were not associated with a SVCB record.

   If the client supports TLS Encrypted Client Hello (ECH) discovery
   through SVCB records [SVCB-ECH], depending on the client's preference
   to handle ECH, the client SHOULD sort addresses with ECH keys taking
   priority to maintain privacy when attempting connection
   establishment.

   The client then sorts the addresses received up to this point, within
   each group, by service priority if the set of addresses contain any
   answers from SVCB records.  See Section 5.1 for details.

   The client SHOULD also sort the addresses in protocol order, such
   that QUIC is prioritized over TCP, as it connects faster and
   generally results in a better experience once connected.  For
   example, QUIC provides improved delivery and congestion control,
   supports connection migration, and provides other benefits [QUIC].

   Then, within each group at equal priority, the client MUST sort the
   addresses using Destination Address Selection ([RFC6724], Section 6).

Pauly, et al.           Expires 28 February 2025                [Page 7]
Internet-Draft              Happy Eyeballs v3                August 2024

   If the client is stateful and has a history of expected round-trip
   times (RTTs) for the routes to access each address, it SHOULD add a
   Destination Address Selection rule between rules 8 and 9 that prefers
   addresses with lower RTTs.  If the client keeps track of which
   addresses it used in the past, it SHOULD add another Destination
   Address Selection rule between the RTT rule and rule 9, which prefers
   used addresses over unused ones.  This helps servers that use the
   client's IP address during authentication, as is the case for TCP
   Fast Open [RFC7413] and some Hypertext Transport Protocol (HTTP)
   cookies.  This historical data MUST NOT be used across different
   network interfaces and SHOULD be flushed whenever a device changes
   the network to which it is attached.

   Next, the client SHOULD modify the ordered list to interleave
   protocols and address families.  Whichever combination of protocol
   and address family is first in the list should be followed by an
   endpoint of the other protocol type and same address family, then an
   endpoint from the same protocol and other address family, and then an
   endpoint from the other protocol and other address family.  For
   example, if the first address in the sorted list is a QUIC IPv6
   address, then the first TCP IPv6 address should be moved up in the
   list to be second in the list, then the first QUIC IPv4 address
   should be moved up to be third in the list, and then the first TCP
   IPv4 address should be moved up to be fourth in the list.  An
   implementation MAY choose to favor one protocol or address family
   more by allowing multiple addresses of that protocol or family to be
   attempted before trying the other combinations.  The number of
   contiguous addresses of the first combination of properties will be
   referred to as the "Preferred Protocol Combination Count" and can be
   a configurable value.  This avoids waiting through a long list of
   addresses from a given address family using a given protocol if
   connectivity over a protocol or an address family is impaired.

   Note that the address selection described in this section only
   applies to destination addresses; Source Address Selection
   ([RFC6724], Section 5) is performed once per destination address and
   is out of scope of this document.

5.1.  Sorting Based on Priority

   SVCB [SVCB] RRs indicate a priority for each ServiceMode response.
   This priority applies to any IPv4 or IPv6 address hints in the RR
   itself, as well as any addresses received on A or AAAA queries for
   the name in the ServiceMode RR.  The priority in a ServiceMode SVCB
   RR is always greater than 0.

   SVCB answers with the lowest numerical value (such as 1) are sorted
   first, and answers with higher numerical values are sorted later.

Pauly, et al.           Expires 28 February 2025                [Page 8]
Internet-Draft              Happy Eyeballs v3                August 2024

   Note that a SVCB RR with the TargetName "." applies to the owner name
   in the RR, and the priority of that SVCB RR applies to any A or AAAA
   RRs for the same owner name.  These answers are sorted according to
   that SVCB RR's priority.

6.  Connection Attempts

   Once the list of addresses received up to this point has been
   constructed, the client will attempt to make connections.  In order
   to avoid unreasonable network load, connection attempts SHOULD NOT be
   made simultaneously.  Instead, one connection attempt to a single
   address is started first, followed by the others in the list, one at
   a time.  Starting a new connection attempt does not affect previous
   attempts, as multiple connection attempts may occur in parallel.
   Once one of the connection attempts succeeds (Section 6.1), all other
   connections attempts that have not yet succeeded SHOULD be canceled.
   Any address that was not yet attempted as a connection SHOULD be
   ignored.  At that time, the asynchronous DNS query MAY be canceled as
   new addresses will not be used for this connection.  However, the DNS
   client resolver SHOULD still process DNS replies from the network for
   a short period of time (recommended to be 1 second), as they will
   populate the DNS cache and can be used for subsequent connections.

   A simple implementation can have a fixed delay for how long to wait
   before starting the next connection attempt.  This delay is referred
   to as the "Connection Attempt Delay".  One recommended value for a
   default delay is 250 milliseconds.  A more nuanced implementation's
   delay should correspond to the time when the previous attempt is
   retrying its handshake (such as sending a second TCP SYN or a second
   QUIC Initial), based on the retransmission timer ([RFC6298],
   [RFC9002]).  If the client has historical RTT data gathered from
   other connections to the same host or prefix, it can use this
   information to influence its delay.  Note that this algorithm should
   only try to approximate the time of the first handshake packet
   retransmission, and not any further retransmissions that may be
   influenced by exponential timer back off.

   The Connection Attempt Delay MUST have a lower bound, especially if
   it is computed using historical data.  More specifically, a
   subsequent connection MUST NOT be started within 10 milliseconds of
   the previous attempt.  The recommended minimum value is 100
   milliseconds, which is referred to as the "Minimum Connection Attempt
   Delay".  This minimum value is required to avoid congestion collapse
   in the presence of high packet-loss rates.  The Connection Attempt
   Delay SHOULD have an upper bound, referred to as the "Maximum
   Connection Attempt Delay".  The current recommended value is 2
   seconds.

Pauly, et al.           Expires 28 February 2025                [Page 9]
Internet-Draft              Happy Eyeballs v3                August 2024

6.1.  Determining successful connection establishment

   The determination of when a connection attempt has successfully
   completed (and other attempts can be cancelled) depends on the
   protocols being used to establish a connection.  This can involve one
   or more protocol handshakes.

   Client connections that use TCP only (without TLS or another protocol
   on top, such as for unencrypted HTTP connections) will determine
   successful establishment based on completing the TCP handshake only.
   When TLS is used on top of of TCP (such as for encrypted HTTP
   connections), clients MAY choose to wait for the TLS handshake to
   successfully complete before cancelling other connection attempts.
   This is particularly useful for networks in which a TCP-terminating
   proxy might be causing TCP handshakes to succeed quickly, even though
   end-to-end connectivity with the TLS-terminating server will fail.
   QUIC connections inherently include a secure handshake in their main
   handshakes, and thus only need to wait for a single handshake to
   complete.

   While transport layer handshakes generally do not have restrictions
   on attempts to establish a connection, some cryptographic handshakes
   may be dependent on ServiceMode SVCB RRs and could impose limitations
   on establishing a connection.  For instance, ECH-capable clients may
   become SVCB-reliant clients (Section 3 of [SVCB]) when SVCB RRs
   contain the "ech" SvcParamKey [SVCB-ECH].  If the client is either an
   SVCB-reliant client or a SVCB-optional client that might switch to
   SVCB-reliant connection establishment during the process, the client
   MUST wait for SVCB RRs before proceeding with the cryptographic
   handshake.

6.2.  Handling Application Layer Protocol Negotiation (ALPN)

   The alpn and no-default-alpn SvcParamKeys in SVCB RRs indicate the
   "SVCB ALPN set," which specifies the underlying transport protocols
   supported by the associated service endpoint.  When the client
   requests SVCB RRs, it SHOULD perform the procedure specified in
   Section 7.1.2 of [SVCB] to determine the underlying transport
   protocols that both the client and the service endpoint support.  The
   client SHOULD NOT attempt to make a connection to a service endpoint
   whose SVCB ALPN set does not contain any protocols that the client
   supports.  For example, suppose the client is an HTTP client that
   only supports TCP-based versions such as HTTP/1.1 and HTTP/2, and it
   receives the following HTTPS RR:

    example.com. 60 IN HTTPS 1 svc1.example.com. (
        alpn="h3" no-default-alpn ipv6hint=2001:db8::2 )

Pauly, et al.           Expires 28 February 2025               [Page 10]
Internet-Draft              Happy Eyeballs v3                August 2024

   In this case, attempting a connection to 2001:db8::2 or any other
   address resolved for svc1.example.com would be incorrect because the
   RR indicates that svc1.example.com only supports HTTP/3, based on the
   ALPN value of "h3".

   If the client is an HTTP client that supports both Alt-Svc [AltSvc]
   and SVCB (HTTPS) RRs, the client SHOULD ensure that connection
   attempts are consistent with both the Alt-Svc parameters and the SVCB
   ALPN set, as specified in Section 9.3 of [SVCB].

7.  DNS Answer Changes During Happy Eyeballs Connection Setup

   If, during the course of connection establishment, the DNS answers
   change by either adding resolved addresses (for example due to DNS
   push notifications [RFC8765]) or removing previously resolved
   addresses (for example, due to expiry of the TTL on that DNS record),
   the client should react based on its current progress.  Additionally,
   once A and AAAA records are received, addresses received via SVCB
   hints that are not included in the A and AAAA records for the
   corresponding address family SHOULD be removed from the list, as
   specified in Section 7.3 of [SVCB].

   If an address is removed from the list that already had a connection
   attempt started, the connection attempt SHOULD NOT be canceled, but
   rather be allowed to continue.  If the removed address had not yet
   had a connection attempt started, it SHOULD be removed from the list
   of addresses to try.

   If an address is added to the list, it should be sorted into the list
   of addresses not yet attempted according to the rules above (see
   Section 5).

8.  Supporting IPv6-Only Networks with NAT64 and DNS64

   While many IPv6 transition protocols have been standardized and
   deployed, most are transparent to client devices.  The combined use
   of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is
   being deployed and requires changes in client devices.  One possible
   way to handle these networks is for the client device networking
   stack to implement 464XLAT [RFC6877]. 464XLAT has the advantage of
   not requiring changes to user space software; however, it requires
   per-packet translation if the application is using IPv4 literals and
   does not encourage client application software to support native
   IPv6.  On platforms that do not support 464XLAT, the Happy Eyeballs
   engine SHOULD follow the recommendations in this section to properly
   support IPv6-only networks with NAT64 and DNS64.

Pauly, et al.           Expires 28 February 2025               [Page 11]
Internet-Draft              Happy Eyeballs v3                August 2024

   The features described in this section SHOULD only be enabled when
   the host detects one of these networks.  A simple heuristic to
   achieve that is to check if the network offers routable IPv6
   addressing, does not offer routable IPv4 addressing, and offers a DNS
   resolver address.

8.1.  IPv4 Address Literals

   If client applications or users wish to connect to IPv4 address
   literals, the Happy Eyeballs engine will need to perform NAT64
   address synthesis for them.  The solution is similar to "Bump-in-the-
   Host" [RFC6535] but is implemented inside the Happy Eyeballs library.

   Note that some IPv4 prefixes are scoped to a given host or network,
   such as 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, and
   255.255.255.255/32, and therefore do not require NAT64 address
   synthesis.

   When an IPv4 address is passed into the library instead of a
   hostname, the device SHOULD use PREF64s received from Router
   Advertisements [RFC8781].  If the network does not provide PREF64s,
   the device SHOULD query the network for the NAT64 prefix using
   "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
   [RFC7050].  It then synthesizes an appropriate IPv6 address (or
   several) using the encoding described in "IPv6 Addressing of IPv4/
   IPv6 Translators" [RFC6052].  The synthesized addresses are then
   inserted into the list of addresses as if they were results from DNS
   queries; connection attempts follow the algorithm described above
   (see Section 6).

   Such translation also applies to any IPv4 address hints received in
   SVCB RRs.

8.2.  Hostnames with Broken AAAA Records

   At the time of writing, there exist a small but non-negligible number
   of hostnames that resolve to valid A records and broken AAAA records,
   which we define as AAAA records that contain seemingly valid IPv6
   addresses but those addresses never reply when contacted on the usual
   ports.  These can be, for example, caused by:

   *  Mistyping of the IPv6 address in the DNS zone configuration

   *  Routing black holes

   *  Service outages

Pauly, et al.           Expires 28 February 2025               [Page 12]
Internet-Draft              Happy Eyeballs v3                August 2024

   While an algorithm complying with the other sections of this document
   would correctly handle such hostnames on a dual-stack network, they
   will not necessarily function correctly on IPv6-only networks with
   NAT64 and DNS64.  Since DNS64 recursive resolvers rely on the
   authoritative name servers sending negative ("no error no answer")
   responses for AAAA records in order to synthesize, they will not
   synthesize records for these particular hostnames and will instead
   pass through the broken AAAA record.

   In order to support these scenarios, the client device needs to query
   the DNS for the A record and then perform local synthesis.  Since
   these types of hostnames are rare and, in order to minimize load on
   DNS servers, this A query should only be performed when the client
   has given up on the AAAA records it initially received.  This can be
   achieved by using a longer timeout, referred to as the "Last Resort
   Local Synthesis Delay"; the delay is recommended to be 2 seconds.
   The timer is started when the last connection attempt is fired.  If
   no connection attempt has succeeded when this timer fires, the device
   queries the DNS for the IPv4 address and, on reception of a valid A
   record, treats it as if it were provided by the application (see
   Section 8.1).

8.3.  Virtual Private Networks

   Some Virtual Private Networks (VPNs) may be configured to handle DNS
   queries from the device.  The configuration could encompass all
   queries or a subset such as "*.internal.example.com".  These VPNs can
   also be configured to only route part of the IPv4 address space, such
   as 192.0.2.0/24.  However, if an internal hostname resolves to an
   external IPv4 address, these can cause issues if the underlying
   network is IPv6-only.  As an example, let's assume that
   "www.internal.example.com" has exactly one A record, 198.51.100.42,
   and no AAAA records.  The client will send the DNS query to the
   company's recursive resolver and that resolver will reply with these
   records.  The device now only has an IPv4 address to connect to and
   no route to that address.  Since the company's resolver does not know
   the NAT64 prefix of the underlying network, it cannot synthesize the
   address.  Similarly, the underlying network's DNS64 recursive
   resolver does not know the company's internal addresses, so it cannot
   resolve the hostname.  Because of this, the client device needs to
   resolve the A record using the company's resolver and then locally
   synthesize an IPv6 address, as if the resolved IPv4 address were
   provided by the application (Section 8.1).

9.  Summary of Configurable Values

   The values that may be configured as defaults on a client for use in
   Happy Eyeballs are as follows:

Pauly, et al.           Expires 28 February 2025               [Page 13]
Internet-Draft              Happy Eyeballs v3                August 2024

   *  Resolution Delay (Section 4): The time to wait for a AAAA response
      after receiving an A response.  Recommended to be 50 milliseconds.

   *  Preferred Protocol Combination Count (Section 5): The number of
      addresses belonging to the preferred address family (such as IPv6)
      using the preferred protocol (such as QUIC) that should be
      attempted before attempting the next combination of address family
      and protocol.  Recommended to be 1; 2 may be used to more
      aggressively favor a particular combination of address family and
      protocol.

   *  Connection Attempt Delay (Section 6): The time to wait between
      connection attempts in the absence of RTT data.  Recommended to be
      250 milliseconds.

   *  Minimum Connection Attempt Delay (Section 6): The minimum time to
      wait between connection attempts.  Recommended to be 100
      milliseconds.  MUST NOT be less than 10 milliseconds.

   *  Maximum Connection Attempt Delay (Section 6): The maximum time to
      wait between connection attempts.  Recommended to be 2 seconds.

   *  Last Resort Local Synthesis Delay (Section 8.2): The time to wait
      after starting the last IPv6 attempt and before sending the A
      query.  Recommended to be 2 seconds.

   The delay values described in this section were determined
   empirically by measuring the timing of connections on a very wide set
   of production devices.  They were picked to reduce wait times noticed
   by users while minimizing load on the network.  As time passes, it is
   expected that the properties of networks will evolve.  For that
   reason, it is expected that these values will change over time.
   Implementors should feel welcome to use different values without
   changing this specification.  Since IPv6 issues are expected to be
   less common, the delays SHOULD be increased with time as client
   software is updated.

10.  Limitations

   Happy Eyeballs will handle initial connection failures at the
   transport layer (such as TCP or QUIC); however, other failures or
   performance issues may still affect the chosen connection.

Pauly, et al.           Expires 28 February 2025               [Page 14]
Internet-Draft              Happy Eyeballs v3                August 2024

10.1.  Path Maximum Transmission Unit Discovery

   For TCP connections, since Happy Eyeballs is only active during the
   initial handshake and TCP does not pass the initial handshake, issues
   related to MTU can be masked and go unnoticed during Happy Eyeballs.
   For QUIC connections, a minimum MTU of at least 1200 bytes [RFC9000],
   Section 8.1-5 is guaranteed, but there is a chance that larger values
   may not be available.  Solving this issue is out of scope of this
   document.  One solution is to use "Packetization Layer Path MTU
   Discovery" [RFC4821].

10.2.  Application Layer

   If the DNS returns multiple addresses for different application
   servers, the application itself may not be operational and functional
   on all of them.  Common examples include Transport Layer Security
   (TLS) and HTTP.

10.3.  Hiding Operational Issues

   It has been observed in practice that Happy Eyeballs can hide issues
   in networks.  For example, if a misconfiguration causes IPv6 to
   consistently fail on a given network while IPv4 is still functional,
   Happy Eyeballs may impair the operator's ability to notice the issue.
   It is recommended that network operators deploy external means of
   monitoring to ensure functionality of all address families.

11.  Security Considerations

   Note that applications should not rely upon a stable hostname-to-
   address mapping to ensure any security properties, since DNS results
   may change between queries.  Happy Eyeballs may make it more likely
   that subsequent connections to a single hostname use different IP
   addresses.

12.  IANA Considerations

   This document does not require any IANA actions.

13.  References

13.1.  Normative References

   [ECH]      Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", Work in Progress, Internet-Draft,
              draft-ietf-tls-esni-20, 4 August 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              esni-20>.

Pauly, et al.           Expires 28 February 2025               [Page 15]
Internet-Draft              Happy Eyeballs v3                August 2024

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
              <https://www.rfc-editor.org/rfc/rfc4821>.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              DOI 10.17487/RFC6052, October 2010,
              <https://www.rfc-editor.org/rfc/rfc6052>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <https://www.rfc-editor.org/rfc/rfc6146>.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              DOI 10.17487/RFC6147, April 2011,
              <https://www.rfc-editor.org/rfc/rfc6147>.

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298,
              DOI 10.17487/RFC6298, June 2011,
              <https://www.rfc-editor.org/rfc/rfc6298>.

   [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
              Using "Bump-in-the-Host" (BIH)", RFC 6535,
              DOI 10.17487/RFC6535, February 2012,
              <https://www.rfc-editor.org/rfc/rfc6535>.

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
              <https://www.rfc-editor.org/rfc/rfc6724>.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, DOI 10.17487/RFC7050, November 2013,
              <https://www.rfc-editor.org/rfc/rfc7050>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Pauly, et al.           Expires 28 February 2025               [Page 16]
Internet-Draft              Happy Eyeballs v3                August 2024

   [RFC8781]  Colitti, L. and J. Linkova, "Discovering PREF64 in Router
              Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
              2020, <https://www.rfc-editor.org/rfc/rfc8781>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [SVCB]     Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [SVCB-ECH] Schwartz, B. M., Bishop, M., and E. Nygren, "Bootstrapping
              TLS Encrypted ClientHello with DNS Service Bindings", Work
              in Progress, Internet-Draft, draft-ietf-tls-svcb-ech-04,
              20 August 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-tls-svcb-ech-04>.

13.2.  Informative References

   [AltSvc]   Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.

   [HEV2]     Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8305>.

   [IPV6]     Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/rfc/rfc8200>.

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <https://www.rfc-editor.org/rfc/rfc6555>.

Pauly, et al.           Expires 28 February 2025               [Page 17]
Internet-Draft              Happy Eyeballs v3                August 2024

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              RFC 6877, DOI 10.17487/RFC6877, April 2013,
              <https://www.rfc-editor.org/rfc/rfc6877>.

   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
              <https://www.rfc-editor.org/rfc/rfc7413>.

   [RFC8765]  Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              RFC 8765, DOI 10.17487/RFC8765, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8765>.

   [RFC9002]  Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
              and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
              May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.

   [RFC9114]  Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

Acknowledgments

   The authors thank Dan Wing, Andrew Yourtchenko, and everyone else who
   worked on the original Happy Eyeballs design [RFC6555], Josh
   Graessley, Stuart Cheshire, and the rest of team at Apple that helped
   implement and instrument this algorithm, and Jason Fesler and Paul
   Saab who helped measure and refine this algorithm.  The authors would
   also like to thank Fred Baker, Nick Chettle, Lorenzo Colitti, Igor
   Gashinsky, Geoff Huston, Jen Linkova, Paul Hoffman, Philip Homburg,
   Warren Kumari, Erik Nygren, Jordi Palet Martinez, Rui Paulo, Stephen
   Strowes, Jinmei Tatuya, Dave Thaler, Joe Touch, and James Woodyatt
   for their input and contributions.

Authors' Addresses

   Tommy Pauly
   Apple Inc
   Email: tpauly@apple.com

   David Schinazi
   Google LLC
   Email: dschinazi.ietf@gmail.com

   Nidhi Jaju
   Google LLC
   Email: nidhijaju@google.com

Pauly, et al.           Expires 28 February 2025               [Page 18]
Internet-Draft              Happy Eyeballs v3                August 2024

   Kenichi Ishibashi
   Google LLC
   Email: bashi@google.com

Pauly, et al.           Expires 28 February 2025               [Page 19]