idnits 2.17.00 (12 Aug 2021) /tmp/idnits44125/draft-duke-httpbis-quic-version-alt-svc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (4 March 2022) is 78 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Duke 3 Internet-Draft Google 4 Intended status: Standards Track L. Pardue 5 Expires: 5 September 2022 Cloudflare 6 4 March 2022 8 An Alt-Svc Parameter for QUIC Versions 9 draft-duke-httpbis-quic-version-alt-svc-00 11 Abstract 13 HTTP Alternative Services (Alt-Svc) describes how one origin's 14 resource can be accessed via a different protocol/host/port 15 combination. Alternatives are advertised by servers using the Alt- 16 Svc header field or the ALTSVC frame. This includes a protocol name, 17 which reuses Application Layer Protocol Negotiation (ALPN) 18 codepoints. The "h3" codepoint indicates the availability of HTTP/3. 19 A client that uses such an alternative first makes a QUIC connection. 20 However, without a priori knowledge of which QUIC version to use, 21 clients might incur a round-trip latency penalty to complete QUIC 22 version negotiation, or forfeit desirable properties of a QUIC 23 version. This document specifies a new Alt-Svc parameter that 24 specifies alternative supported QUIC versions, which substantially 25 reduces the chance of this penalty. 27 About This Document 29 This note is to be removed before publishing as an RFC. 31 The latest revision of this draft can be found at 32 https://martinduke.github.io/quic-version-alt-svc-parameter/draft- 33 duke-httpbis-quic-version-alt-svc.html. Status information for this 34 document may be found at https://datatracker.ietf.org/doc/draft-duke- 35 httpbis-quic-version-alt-svc/. 37 Discussion of this document takes place on the HTTP Working Group 38 mailing list (mailto:ietf-http-wg@w3.org), which is archived at 39 https://lists.w3.org/Archives/Public/ietf-http-wg/. 41 Source for this draft and an issue tracker can be found at 42 https://github.com/martinduke/quic-version-alt-svc-parameter. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 5 September 2022. 61 Copyright Notice 63 Copyright (c) 2022 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Revised BSD License text as 72 described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Revised BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 78 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 79 3. The quicv Parameter . . . . . . . . . . . . . . . . . . . . . 4 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 84 6.2. Informative References . . . . . . . . . . . . . . . . . 5 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 88 1. Introduction 90 HTTP Alternative Services (Alt-Svc) [ALTSVC] describes how one 91 origin's resource can be accessed via a different protocol/host/port 92 combination. Alternatives are advertised by servers using the Alt- 93 Svc header field or the ALTSVC frame. This includes a protocol name, 94 which reuses codepoints from the Application-Layer Protocol 95 Negotiation (ALPN) TLS extension [RFC7301]. Servers can advertise 96 multiple alternatives, in which case the order reflects the server's 97 preferences (the first value being the most preferred). 99 Clients can ignore alternative services, or pick one at their 100 discretion. A client might use any details from the advertisement, 101 in addition to out of band information, in determining if an 102 alternative is suitable or preferred. 104 While ALPN was originally intend to allow multiple applications to 105 utilize TLS or DTLS on the same IP address and TCP or UDP port, ALPN 106 can also usefully identify the transport in an Alt-Svc context. The 107 "h3" ALPN codepoint informs the client that it can use HTTP/3 108 [I-D.ietf-quic-http] for access, which in turn requires the QUIC 109 transport protocol [RFC8999]. 111 QUIC is versioned. A client and server that both support a QUIC 112 version can, through a negotiation process, generally agree on that 113 version in no more than one round-trip. However, to avoid that 114 penalty clients might use the most commonly deployed QUIC version 115 (e.g. version 1 [RFC9000] at the time of writing), rather than the 116 version with the most desirable properties for the client's use case. 118 To avoid the round-trip, one solution would be to register unique 119 ALPN codepoints for each HTTP/3 and QUIC version combination. 120 However, this might complicate deployment of new versions and 121 deprecation of old ones: architecturally, an application should 122 provide its ALPN to its QUIC implementation. In this case, fully 123 deploying a new version in that implementation would require updating 124 all applications that use it. 126 Instead, this document specifies an Alt-Svc parameter that lists the 127 QUIC versions available to serve the resource. Clients that do not 128 understand this parameter will ignore it. They might default to the 129 most likely version, and/or incur a round-trip penalty in the event 130 of a mismatch. Clients that do process the parameter will connect 131 successfully using the most desirable version with high probability. 133 2. Conventions and Definitions 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in 138 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 This document uses the Augmented BNF defined in [RFC5234] and imports 142 parameter from Section 3 of [ALTSVC]. 144 3. The quicv Parameter 146 This document specifies the "quicv" Alt-Svc parameter, which lists 147 the QUIC versions supported by an endpoint, using the hexadecimal 148 representation of the version field in a QUIC long header, as 149 indicated in [RFC8999]. Senders MAY omit leading zeroes from version 150 numbers. 152 quicv = version-list 153 version-list = DQUOTE version 1*( OWS, "," OWS version-number) DQUOTE 154 version = 1*8 HEXDIG; hex-encoded QUIC version 156 Examples: 158 Alt-Svc: h3=":443"; quicv="1" 159 Alt-Svc: h3=":443"; quicv="709a50c4,1" 160 Alt-Svc: h3=":443"; quicv="709a50c4,1", h3=":1001"; quicv="709a50c4" 162 The order of entries in version-list reflects the server's preference 163 (with the first value being the most preferred alternative). 165 Note that the quicv parameter applies to a single associated entry in 166 the Alt-Svc list. Servers MUST NOT provide a quicv parameter to an 167 entry containing ALPN codepoint that does not potentially utilize 168 QUIC. 170 If the Alt-Svc information resolves to a server pool that 171 inconsistently supports different QUIC versions, the parameter SHOULD 172 only advertise versions that are supported throughout the pool. 174 4. Security Considerations 176 This document inherits the security considerations of [ALTSVC], 177 especially the implications of "Changing Protocols" in Section 9.3. 178 There are few protocol properties guaranteed to hold across all QUIC 179 versions, so endpoints should be aware what capabilities are 180 intrinsic to the QUIC versions they are advertising. 182 This parameter reveals capabilities of the described server, but this 183 information is already available by inducing the server to generate a 184 QUIC version negotiation packet. 186 5. IANA Considerations 188 Please add this entry ot the HTTP Alt-Svc Parameter Registry: 190 Alt-Svc Parameter: quicv 191 Reference: This document 193 6. References 195 6.1. Normative References 197 [ALTSVC] Bishop, M. and M. Thomson, "HTTP Alternative Services", 198 Work in Progress, Internet-Draft, draft-ietf-httpbis- 199 rfc7838bis-00, 31 August 2021, 200 . 203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, 205 DOI 10.17487/RFC2119, March 1997, 206 . 208 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 209 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 210 May 2017, . 212 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 213 Specifications: ABNF", STD 68, RFC 5234, 214 DOI 10.17487/RFC5234, January 2008, 215 . 217 6.2. Informative References 219 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 220 "Transport Layer Security (TLS) Application-Layer Protocol 221 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 222 July 2014, . 224 [I-D.ietf-quic-http] 225 Bishop, M., "Hypertext Transfer Protocol Version 3 226 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 227 quic-http-34, 2 February 2021, 228 . 231 [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", 232 RFC 8999, DOI 10.17487/RFC8999, May 2021, 233 . 235 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 236 Multiplexed and Secure Transport", RFC 9000, 237 DOI 10.17487/RFC9000, May 2021, 238 . 240 Acknowledgments 242 TODO acknowledge. 244 Authors' Addresses 246 Martin Duke 247 Google 248 Email: martin.h.duke@gmail.com 250 Lucas Pardue 251 Cloudflare 252 Email: lucaspardue.24.7@gmail.com