]> An Alt-Svc Parameter and SvcParamKey for QUIC Versions Google
martin.h.duke@gmail.com
Cloudflare
lucaspardue.24.7@gmail.com
Applications and Real-Time HTTP Internet-Draft HTTP Alternative Services (Alt-Svc) describes how one origin's resource can be accessed via a different protocol/host/port combination. Alternatives are advertised by servers using the Alt-Svc header field or the ALTSVC frame. This includes a protocol name, which reuses Application Layer Protocol Negotiation (ALPN) codepoints. The "h3" codepoint indicates the availability of HTTP/3. A client that uses such an alternative first makes a QUIC connection. However, without a priori knowledge of which QUIC version to use, clients might incur a round-trip latency penalty to complete QUIC version negotiation, or forfeit desirable properties of a QUIC version. This document specifies a new Alt-Svc parameter that specifies alternative supported QUIC versions, which substantially reduces the chance of this penalty. Similarly, clients can retrieve additional instructions about access to services or resources via DNS SVCB and HTTP Resource Records. This document also defines a new SvcParamKey for these Resource Records, which specifies the specific QUIC versions in use. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .
Introduction HTTP Alternative Services (Alt-Svc) describes how one origin's resource can be accessed via a different protocol/host/port combination. Alternatives are advertised by servers using the Alt-Svc header field or the ALTSVC frame. This includes a protocol name, which reuses codepoints from the Application-Layer Protocol Negotiation (ALPN) TLS extension . Servers can advertise multiple alternatives, in which case the order reflects the server's preferences (the first value being the most preferred). Clients can ignore alternative services, or pick one at their discretion. A client might use any details from the advertisement, in addition to out of band information, in determining if an alternative is suitable or preferred. While ALPN was originally intend to allow multiple applications to utilize TLS or DTLS on the same IP address and TCP or UDP port, ALPN can also usefully identify the transport in an Alt-Svc context. The "h3" ALPN codepoint informs the client that it can use HTTP/3 for access, which in turn requires the QUIC transport protocol . QUIC is versioned. A client and server that both support a QUIC version can, through a negotiation process, generally agree on that version in no more than one round-trip. However, to avoid that penalty clients might use the most commonly deployed QUIC version (e.g. version 1 at the time of writing), rather than the version with the most desirable properties for the client's use case. To avoid the round-trip, one solution would be to register unique ALPN codepoints for each HTTP/3 and QUIC version combination. However, this might complicate deployment of new versions and deprecation of old ones: architecturally, an application should provide its ALPN to its QUIC implementation. In this case, fully deploying a new version in that implementation would require updating all applications that use it. Instead, this document specifies an Alt-Svc parameter that lists the QUIC versions available to serve the resource. Clients that do not understand this parameter will ignore it. They might default to the most likely version, and/or incur a round-trip penalty in the event of a mismatch. Clients that do process the parameter will connect successfully using the most desirable version with high probability. Domain Name System (DNS) Service Binding (SVCB) and HTTPS Resource Records allow the distribution of access instructions beyond the IP address via DNS. This document also specifies a new SvcParamKey for these Resource Records to distribute QUIC version information with this technique.
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. This document uses the Augmented BNF defined in and imports parameter from .
The quicv Parameter This document specifies the "quicv" Alt-Svc parameter, which lists the QUIC versions supported by an endpoint, using the hexadecimal representation of the version field in a QUIC long header, as indicated in . Senders MAY omit leading zeroes from version numbers. Examples: The order of entries in version-list reflects the server's preference (with the first value being the most preferred alternative). Note that the quicv parameter applies to a single associated entry in the Alt-Svc list. Servers MUST NOT provide a quicv parameter to an entry containing ALPN codepoint that does not potentially utilize QUIC. If the Alt-Svc information resolves to a server pool that inconsistently supports different QUIC versions, the parameter SHOULD only advertise versions that are supported throughout the pool.
The quicv SvcParamKey SVCB and HTTPS Resource Records can include the quicv SvcParamKey. Its presentation format value and use are identical to the quicv Alt-Svc Parameter. Its wire format value consists of the version numbers in network byte order. To include the quicv SvcParamKey in a resource record, it MUST also include at least one ALPN that can be delivered over QUIC. For example, consider a service configuration that advertisees two QUIC versions on the default port, but only one version on a non-default port. In Alt-Svc, this could be represented as: As HTTPS RRs, this could be represented as:
Security Considerations This document inherits the security considerations of , especially the implications of "Changing Protocols" in Section 9.3. There are few protocol properties guaranteed to hold across all QUIC versions, so endpoints should be aware what capabilities are intrinsic to the QUIC versions they are advertising. This parameter reveals capabilities of the described server, but this information is already available by inducing the server to generate a QUIC version negotiation packet.
IANA Considerations Please add this entry to the HTTP Alt-Svc Parameter Registry: Alt-Svc Parameter: quicv Reference: This document Please add this entry to the Service Binding (SVCB) Parameter Registry: Number: TBD Name: quicv Meaning: Supported QUIC versions Format Reference: This document
Acknowledgments Thanks to Ben Schwartz for his help with the Resource Record formatting.
References Normative References HTTP Alternative Services Akamai Technologies Mozilla This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) Google Akamai Technologies Akamai Technologies This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Informative References Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. HTTP/3 The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. Version-Independent Properties of QUIC This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. QUIC: A UDP-Based Multiplexed and Secure Transport This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.
Change Log
  • RFC Editor's Note: Please remove this section prior to publication of a final version of this document.
since draft-duke-httpbis-quic-version-alt-svc-01
  • No changes
since draft-duke-httpbis-quic-version-alt-svc-00
  • Added SVCB and HTTPS Resource Records