Merge branch 'main' into svcb-reliant

draft-happy-eyeballs-v3.md

@@ -32,6 +32,10 @@ author:
     fullname: Nidhi Jaju
     organization: Google
     email: "[email protected]"
+ -
+    fullname: Kenichi Ishibashi
+    organization: Google
+    email: "[email protected]"
 
 normative:
 
@@ -224,13 +228,36 @@ 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
 {{connections}}). It is important that the ordered list involve all
-addresses from both families 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.
+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=I-D.sbn-tls-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.
 
-First, the client MUST sort the addresses received up to this point
-using Destination Address Selection ({{!RFC6724, Section 6}}).
+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 {{priority}} 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}}).
 
 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
@@ -245,24 +272,44 @@ 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 address
-families. Whichever address family is first in the list should be
-followed by an address of the other address family; that is, if the
-first address in the sorted list is IPv6, then the first IPv4 address
-should be moved up in the list to be second in the list. An
-implementation MAY want to favor one address family more by allowing
-multiple addresses of that family to be attempted before trying the
-other family. The number of contiguous addresses of the first
-address family will be referred to as the "First Address Family
-Count" and can be a configurable value. This is performed to avoid
-waiting through a long list of addresses from a given address family
-if connectivity over that address family is impaired.
+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
+address of the other protocol type and same address family, and then
+an endpoint from the same 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, and then the first QUIC IPv4 address should be moved up
+in the list to be third 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
+({{!RFC6724, Section 5}}) is performed once per destination address and
 is out of scope of this document.
 
+## Sorting Based on Priority {#priority}
+SVCB {{SVCB}} RRs indicate a priority for each ServiceMode response.
+This prioirity 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 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.
+
+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.
+
 # Connection Attempts {#connections}
 
 Once the list of addresses received up to this point has been
@@ -332,6 +379,33 @@ 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.
 
+## 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 )
+~~~
+
+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=RFC7838}}
+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}}.
+
 # DNS Answer Changes During Happy Eyeballs Connection Setup {#changes}
 
 If, during the course of connection establishment, the DNS answers
@@ -454,11 +528,12 @@ Happy Eyeballs are as follows:
 - Resolution Delay ({{query}}): The time to wait for a AAAA response
 after receiving an A response. Recommended to be 50 milliseconds.
 
-- First Address Family Count ({{sorting}}): The number of addresses
-belonging to the first address family (such as IPv6) that should
-be attempted before attempting another address family.
+- Preferred Protocol Combination Count ({{sorting}}): 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 address family.
+particular combination of address family and protocol.
 
 - Connection Attempt Delay ({{connections}}): The time to wait between
 connection attempts in the absence of RTT data. Recommended to be