Happy Eyeballs Version 3: Better Connectivity Using Concurrency

4.1. Sending DNS Queries

Clients first need to determine which DNS resource records they will include in queries for a named host.¶

This decision is based on whether the client has "connectivity" using IPv4 and/or IPv6 on the current Provisioning Domain (PvD) [PvD]. Generally, "connectivity" for an address family is defined as having at least one non-loopback and and non-link-local ([RFC3927],[RFC4291]) address of that address family from which to send packets, and at least one non-link local route for the address family. When there is IPv6 connectivity, the client MUST include a query for AAAA records. When there is IPv4 connectivity, the client MUST include a query for A records. Additionally, if the client has detected a NAT64 prefix ([NAT64]) on the network, the client MUST include a query for A records (see Section 8 for more details on detecting the NAT64 prefix and handling answers).¶

In addition to requesting AAAA and A records, depending on which application is establishing the connection, clients can request either SVCB or HTTPS records [SVCB]. For applications using HTTP or HTTPS (including applications using WebSockets), the client SHOULD send a query for HTTPS records.¶

All of the DNS queries SHOULD be made as soon after one another as possible. The order in which the queries are sent SHOULD be as follows (omitting any query that doesn't apply based on the logic described above):¶

1. SVCB or HTTPS query¶

2. AAAA query¶

3. A query¶

This ordering assumes that the client implementing the Happy Eyeballs algorithm is able to specifically influence the queries that are sent, or has a guarantee from the DNS stub resolver about how the queries are sent. This is not possible in all environments and operating systems depending on the APIs available.¶

Note that the DNS stub resolver implementation might itself employ the Happy Eyeballs algorithm, particularly when connecting to an encrypted DNS server (using [DOT], [DOH], or [DOQ], for example, potentially discovered via [RFC9461]). Additionally, Section 4.3 of [RFC10001] provides guidance for how stub resolvers ought to handle dual-stack environments. Following this guidance is beneficial to clients implementing Happy Eyeballs, as it ensures that dual-stack networks are handled well during DNS resolution, which is a prerequisite for the rest of the Happy Eyeballs algorithm to work well.¶

4.2. Handling DNS Answers Asynchronously

Once the client receives sufficient answers to its DNS queries, it can move onto the phases of sorting endpoints (Section 5) and establishing connections (Section 6).¶

Implementations SHOULD NOT wait for all answers to return before starting the next steps of connection establishment. If one query fails or takes significantly longer to return, waiting for those answers can significantly delay connection establishment that could otherwise proceed with already received answers.¶

Therefore, the client SHOULD treat DNS resolution as asynchronous, processing different record types independently. Note that if the platform does not offer an asynchronous DNS API, this behavior can be simulated by making separate synchronous queries for each record type in parallel.¶

The client moves onto sorting endpoints and establishing connections once one of the following condition sets is met:¶

Either:¶

• Some positive (non-empty) address answers have been received AND¶

• A postive (non-empty) or negative (empty) answer has been received for the preferred address family that was queried AND¶

• SVCB/HTTPS service information has been received (or has received a negative response)¶

Or:¶

• Some positive (non-empty) address answers have been received AND¶

• A resolution time delay has passed after which other answers have not been received¶

Positive answers can be IP addresses received either from AAAA or A records, or IP address hints received directly in SVCB/HTTPS records.¶

Negative answers are exclusively responses to AAAA or A records that contain no IP addresses (with or without an error like NXDOMAIN). If all answers come back with negative answers, the connection establishment will fail or need to wait until other answers are received.¶

On networks that have both default routes for IPv6 and IPv4, IPv6 is assumed to be the preferred address family. If only one of IPv6 or IPv4 has a default route, that address family should be considered the preferred address family for progressing the algorithm.¶

The resolution time delay is a short time that provides a chance to receive preferred addresses (via AAAA records) along with service information (via SVCB/HTTPS records). This accounts for the case where the AAAA or SVCB/HTTPS records follow the A records by a few milliseconds. This delay is referred to as the "Resolution Delay".¶

The RECOMMENDED value for the Resolution Delay is 25 milliseconds.¶

4.3. Handling New Answers

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

4.4. Handling Expired Answers

Previously received DNS answers might expire (exceed their TTL) while connection attempts are still in progress. A Happy Eyeballs client will not cancel those ongoing attempts when the answers expire. However, the client MAY trigger new DNS queries to fetch non-expired answers after the original records have expired, in the case in which the original answers have not yet led to a successful connection. Addition of any new answers is handled as described in Section 4.3 and Section 7; that is, ongoing connection attempts will not be cancelled, but any endpoint for which a connection attempt had not yet been started that is no longer in the resolved endpoint list will be removed.¶

Additionally, the fact that Happy Eyeballs enables clients to handle updates to the resolved endpoint list asynchronously enables the use of expired answers "optimistically" while waiting for non-expired answers. This approach is called "optimistic DNS", and is described in [OPTIMISTIC-DNS].¶

5.1. Grouping By Application Protocols and Security Requirements

Clients first group based on which application protocols the destination endpoints support and which security features those endpoints offer. These are based on information from SVCB/HTTPS records about application-layer protocols ("alpn" values) and other parameters like TLS Encrypted Client Hello configuration ("ech" values, see [SVCB-ECH]).¶

For cases where the answers do not include any SVCB/HTTPS information, or if all of the answers are associated with the same SVCB/HTTPS record, this step is trivial: all answers belong to one group, and the client assumes they support the same protocols and security properties.¶

However, the client is aware of different sets of destination endpoints that advertise different capabilities when it receives multiple distinct SVCB/HTTPS records. The client SHOULD separate these endpoints into different groups, such that all endpoints in a group share the same application protocols and relevant security properties. The specific parameters that are relevant to the client depend on the client implementation and application.¶

Note that some destination endpoints might need to be added to multiple groups at this stage. For example, consider the following HTTPS records:¶

 example.com. 60 IN HTTPS 1 svc1.example.com. (
     alpn="h3,h2" ipv6hint=2001:db8::2 )
 example.com. 60 IN HTTPS 1 svc2.example.com. (
     alpn="h2" ipv6hint=2001:db8::4 )

In this case, 2001:db8::2 can be used with HTTP/3 and HTTP/2, but 2001:db8::4 can only be used with HTTP/2. If the client creates a grouping for HTTP/3-capable endpoints and HTTP/2-capable endpoints, 2001:db8::2 would exist in both groups (assuming that all other security properties are the same).¶

Connection racing as described in Section 6 applies to different destination endpoint options within one of these groups. The logic for prioritizing and falling back between groups of endpoints with different security properties and protocol properties is implementation-defined.¶

5.2. Grouping By Service Priority

The next step of grouping and sorting is to group across different services (as defined by SVCB/HTTPS records), and sort these groups by priority.¶

This step allows server-published priorities to be reflected in the client connection establishment algorithm.¶

SVCB [SVCB] records indicate a priority for each ServiceMode response. This priority applies to any IPv4 or IPv6 address hints in the record itself, as well as any addresses received on A or AAAA queries for the name in the ServiceMode record. The priority in a SVCB ServiceMode record 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 record with the TargetName "." applies to the owner name in the record, and the priority of that SVCB record applies to any A or AAAA records for the same owner name. These answers are sorted according to that SVCB record's priority.¶

All endpoints received from a particular SVCB service (within a group as defined in Section 5.1), either by an associated AAAA or A record or address hints, SHOULD be separated into a group by the client. These service-based groups SHOULD then be sorted using the service priority.¶

For cases where the answers do not include any SVCB/HTTPS information, or if all of the answers are associated with the same SVCB/HTTPS record, this step is trivial: all answers belong to one group that has the same priority.¶

When there are multiple services, and thus multiple groups, with the same priority, the client SHOULD shuffle these groups randomly.¶

If there are some SVCB/HTTPS services received, but there are AAAA or A records that do not have an associated service (for example, if no SVCB/HTTPS record is received for the original name using the "." TargetName), the unassociated addresses SHOULD be put in a group of endpoints that is prioritized at the end of the list.¶

5.3. Sorting Destination Endpoints Within Groups

Within each group of endpoints, after grouping based on the logic in Section 5.1 and Section 5.2, the client sorts the endpoints based on preference and historical data.¶

First, the client MUST sort the endpoints 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 endpoint's IP 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 be partitioned using the same boundaries used for privacy-sensitive information specific to that endpoint, and MUST NOT be used across different Provisioning Domains (PvDs) [PvD]. See Section 9 for discussion around handling multiple PvDs. Implementations that use historical data MUST ensure that clients with different historical data will eventually converge toward the same behaviors. For example, clients can periodically ignore historical data to ensure that fresh addresses are attempted.¶

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 endpoint of the other address family. For example, if the first endpoint in the sorted list has an IPv6 address, then the first IPv4 endpoint should be moved up in the list to be second in the list. An implementation MAY choose to favor one address family more by allowing multiple addresses of that family to be attempted before trying the next. The number of contiguous endpoints of the first address family of properties will be referred to as the "Preferred Address Family Count" and can be a configurable value. This avoids waiting through a long list of endpoints for a given address family if connectivity over that address family is impaired.¶

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

6.1. Determining successful connection establishment

The determination of when a connection attempt has successfully completed (and other attempts can be cancelled) ultimately depends on the client application's interpretation of the connection state being ready to use. This will generally include at least the transport-level handshake with the remote endpoint (such as the TCP or QUIC handshake), but can involve other higher-level handshakes or state checks as well.¶

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 TCP (such as for encrypted HTTP connections), clients SHOULD 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 usually only need to wait for a single handshake to complete.¶

Beyond TCP, TLS, and/or QUIC handshakes, clients may also wait for other requirements to be met before determining that the connection establishment was successful. For example, clients generally validate that the server's certificate provided via TLS is trusted, and that operation can be asynchronous.¶

In cases where the connection establishment determination goes beyond the initial transport handshake, the Next Connection Attempt Timer ought to be adjusted after the initial transport handshake is completed. When the connection establishment makes progress, but has not completed, the timer SHOULD be extended to a new value that represents an estimated time for the full connection establishment to complete.¶

For example, consider a case where connection establishment involves both a TCP handshake and a TLS handshake. If the timer is initially set to be roughly at the time when a TCP SYN packet would be retransmitted, and the TCP handshake completes before the timer fires, the timer should be adjusted to allow for the time in which the TLS handshake could complete.¶

While transport layer handshakes generally do not have restrictions on attempts to establish a connection, some cryptographic handshakes might depend on SVCB ServiceMode records and impose limitations on establishing a connection. For instance, ECH-capable clients might rely on SVCB records that contain the "ech" SvcParamKey [SVCB-ECH] before starting a TLS handshake. See Section 6.3 for details on when clients need to pend or abandon connection attempts while awaiting SVCB records.¶

6.2. Handling Application Layer Protocol Negotiation (ALPN)

The alpn and no-default-alpn SvcParamKeys in SVCB records indicate the "SVCB ALPN set," which specifies the underlying transport protocols supported by the associated service endpoint. When the client requests SVCB records, 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 record:¶

 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 record 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) records, 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].¶

6.3. Dropping or Pending Connection Attempts

Some situations related to handling SVCB responses can require connection attempts to be dropped, or pended until SVCB responses return.¶

Section 3.1 of [SVCB] describes client behavior for handling resolution failures when responses are "cryptographically protected" using DNSSEC [DNSSEC] or encrypted DNS ([DOT], [DOH], or [DOQ], for example). If SVCB resolution fails when using cryptographic protection, clients SHOULD abandon connection attempts altogether to avoid downgrade attacks.¶

Use of cryptographic protection in DNS can influence other parts of Happy Eyeballs connection establishment, as well.¶

Situations in which DNS is not protected allow for any records to be blocked or modified, so security properties derived from SVCB records are opportunistic only. However, when DNS is cryptographically protected, clients can be stricter about relying on the properties from SVCB records.¶

Section 5.1 of [SVCB] explains that clients "MUST NOT transmit any information that could be altered by the SVCB response until it arrives", and specifically mentions properties that affect the TLS ClientHello. This restriction specifically applies when a client's behavior will be altered by the SVCB response, which depends both on the client implementation's ability to support a particular feature, as well as the client implementation's willingness to rely on the SVCB response to enable a particular feature.¶

Based on this, clients in some scenarios MUST pend starting a TLS handshake (either after TCP or as part of QUIC) until SVCB responses have been received, even after the "Resolution Delay" defined in Section 4 has been reached. Specifically, clients MUST pend starting handshakes if all of the following are true:¶

1. DNS responses are cryptographically protected with DNSSEC or encrypted DNS. Note that, if unencrypted and unsigned DNS is used, SVCB information is opportunistic; clients MAY wait for SVCB responses but do not need to.¶

2. The client implementation supports parsing and using a particular security-related SVCB parameter, such as the "ech" SvcParamKey [SVCB-ECH]. (In contrast, implementations that do not support actively using ECH do not need to wait for SVCB resolution if that is the only reason to do so).¶

3. The client relies on the presence of the particular SVCB-related parameter to enable the relevant protocol feature. For example, if a connection attempt would normally be using cleartext HTTP unless an HTTPS DNS record would cause the client to upgrade, the client needs to wait for the record; however, if the client already would be using HTTP over TLS, then it is not relying on that signal from SVCB. As another example, some SVCB properties can affect the TLS ClientHello in ways that optimize performance (like tls-supported-groups [I-D.ietf-tls-key-share-prediction]) but only aim to save round trips. The other TLS groups can be discovered through the TLS handshake itself, instead of SVCB, and thus do not require waiting for SVCB responses.¶

Pending the TLS handshake affects transport protocols differently once address records are available and any applicable Resolution Delay has elapsed:¶

• For QUIC, the TLS ClientHello is carried in the initial packet of the connection. If the client needs to pend starting the TLS handshake until SVCB responses have arrived, it needs to pend sending any QUIC packets.¶

• When TLS is used over TCP and the client needs to pend starting the TLS handshake, the client MAY speculatively start the TCP handshake using resolved A or AAAA addresses while holding back the TLS ClientHello until SVCB responses arrive. If the SVCB responses allow using an endpoint for which a speculative TCP handshake was started (for example, when SVCB returns a negative response or a ServiceMode record with TargetName "."), the client can proceed with the TLS handshake on that TCP connection. Conversely, if an endpoint with an in-progress or completed speculative TCP handshake is not selected once the SVCB response arrives (for example, because the client selects an alternative TargetName that provides "ech" [SVCB-ECH]), the client SHOULD close that TCP connection without sending a TLS ClientHello.¶

Starting a speculative TCP handshake before SVCB resolution completes trades privacy for reduced latency: although the TLS ClientHello is not exposed, sending TCP SYN packets to the origin's addresses can reveal communication with IP addresses that the client would not have contacted if an SVCB record directed it to an alternative TargetName (such as a shared ECH-enabled frontend). Clients with stricter privacy requirements MAY pend the TCP handshake until SVCB responses have been received.¶

8.1. Discovering PREF64

Clients can discover a network's PREF64 in one of the following ways:¶

1. From a Router Advertisement option ([PREF64])¶

2. From a DNS query for ipv4only.arpa ([RFC7050])¶

If a network with IPv6-only connectivity does not provide the prefix in a Router Advertisement [PREF64], clients SHOULD send the DNS query to discover the prefix [RFC7050].¶

Networks that use NAT64 might also include DNS64 [DNS64], in which the DNS resolver synthesizes A answers into AAAA answers. However, with the prefix available from router advertisements [PREF64], networks might choose to not deploy DNS64, as the latter has a number of disadvantages (see Section 4.3.4 of [V6-MOSTLY]).¶

To ensure compatibility with any NAT64 network, whenever the client detects a NAT64 prefix, from either of the options reference above, clients MUST send A queries in addition to AAAA queries (as specified in Section 4.1). This allows the client to receive any existing IPv4 A records and perform local NAT64 address synthesis, eliminating the network's need to run DNS64.¶

8.2. Handling Synthesized Answers

Synthesized IPv6 addresses (IPv4 addresses that have been synthensized into IPv6 addresses either locally using PREF64 or by a DNS64 resolver) MUST be de-synthesized into IPv4 addresses before being used by the Happy Eyeballs client for grouping and sorting (Section 5), and connecting. These addresses might be re-synthesized into IPv6 addresses (see Section 8.3), in which case implementations can choose to optimize processing by storing the original address, but still using the IPv4 address for purposes of sorting and route lookups.¶

IPv6 addresses received from AAAA records might come from DNS64 [DNS64]. Clients that are aware of the PREF64 value MUST check to see if an IPv6 address received from DNS is actually an IPv4 address.¶

8.3. Synthesizing IPv6 Addresses During Connection Establishment

When a client has discovered PREF64, it can use the prefix to synthesize IPv4 addresses into IPv6 addresses as defined in [RFC6052].¶

If the Happy Eyeballs client is attempting a connection to an IPv4 address when there is no IPv4 route that applies for that address, then the client MUST synthesize this address into an IPv6 address using the PREF64. These IPv4 addresses can come from DNS (via A records or IPv4 address hints received in SVCB/HTTPS records), or from de-synthesizing IPv6 addresses, or from IPv4 literal addresses passed by an application. This solution is similar to "Bump-in-the-Host" [RFC6535], but is implemented inside the Happy Eyeballs client.¶

Note that NAT64 address synthesis is not always required or possible. Some IPv4 prefixes are scoped to a given host or network and do not require synthesis, such as 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, and 255.255.255.255/32.¶

11.1. Path Maximum Transmission Unit Discovery

Connections that use TCP only (without TLS or another protocol on top) perform connection racing only during the TCP handshake. Such connections can encounter issues where the TCP handshake (using small packets) completes but then large packets are dropped or incorrectly handled by the network due to a small MTU being configured somewhere in the network. Such issues might be more likely with IPv6 traffic [RFC8900] due to the network being unable to fragment IPv6 packets and associated issues with Path MTU Discovery, such as with ICMPv6 PTB messages not making it back to the client.¶

This problem can also occur when TLS is used, but the larger messages used in many TLS handshakes are often sufficient to ensure maximum-size TCP segments are deliverable. 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 these issues is out of scope of this document. One suggested approach is to use "Packetization Layer Path MTU Discovery" [RFC4821].¶

11.2. Application Layer

If the DNS returns multiple endpoints 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.¶

11.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.¶

14.1. Normative References

[ECH]

Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849, March 2026, <https://www.rfc-editor.org/rfc/rfc9849>.

[NAT64]

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

[PREF64]

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

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

[RFC3927]

Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, <https://www.rfc-editor.org/rfc/rfc3927>.

[RFC4291]

Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/rfc/rfc4291>.

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

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

[RFC6724-UPDATE]

Buraglio, N., Chown, T., and J. Duncan, "Prioritizing known-local IPv6 ULAs through address selection policy", Work in Progress, Internet-Draft, draft-ietf-6man-rfc6724-update-25, 11 August 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6724-update-25>.

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

[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., Bishop, M., and E. Nygren, "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings", RFC 9848, DOI 10.17487/RFC9848, March 2026, <https://www.rfc-editor.org/rfc/rfc9848>.

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

[DNS64]

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

[DNSSEC]

Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, <https://www.rfc-editor.org/rfc/rfc9364>.

[DOH]

Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/rfc/rfc8484>.

[DOQ]

Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/rfc/rfc9250>.

[DOT]

Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/rfc/rfc7858>.

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

[HTTP3]

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

[I-D.ietf-tls-key-share-prediction]

Benjamin, D., "TLS Key Share Prediction", Work in Progress, Internet-Draft, draft-ietf-tls-key-share-prediction-05, 15 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-key-share-prediction-05>.

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

[OPTIMISTIC-DNS]

Akiwate, G., Flack, P., and S. Cheshire, "Optimistic DNS", Work in Progress, Internet-Draft, draft-gakiwate-dnsop-optimistic-dns-01, 1 November 2026, <https://datatracker.ietf.org/doc/html/draft-gakiwate-dnsop-optimistic-dns-01>.

[PvD]

Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, <https://www.rfc-editor.org/rfc/rfc7556>.

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

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

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8765]

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

[RFC8900]

Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, <https://www.rfc-editor.org/rfc/rfc8900>.

[RFC9001]

Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.

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

[RFC9461]

Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, November 2023, <https://www.rfc-editor.org/rfc/rfc9461>.

[RFC9704]

Reddy.K, T., Wing, D., Smith, K., and B. Schwartz, "Establishing Local DNS Authority in Validated Split-Horizon Environments", RFC 9704, DOI 10.17487/RFC9704, January 2025, <https://www.rfc-editor.org/rfc/rfc9704>.

[RFC9846]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/rfc/rfc9846>.

[RFC10001]

Momoka and T. Fiebig, "Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments", BCP 91, RFC 10001, DOI 10.17487/RFC10001, August 2026, <https://www.rfc-editor.org/rfc/rfc10001>.

[V6-MOSTLY]

Buraglio, N., Caletka, O., and J. Linkova, "IPv6-mostly Networks: Deployment and Operations Considerations", Work in Progress, Internet-Draft, draft-ietf-v6ops-6mops-12, 29 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops-12>.