idnits 2.17.1 draft-duke-httpbis-quic-version-alt-svc-01.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 April 2022) is 730 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 information found for draft-ietf-dsnop-svcb-https - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dsnop-svcb-https' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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: 29 October 2022 Cloudflare 6 27 April 2022 8 An Alt-Svc Parameter and SvcParamKey for QUIC Versions 9 draft-duke-httpbis-quic-version-alt-svc-01 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 Similarly, clients can retrieve additional instructions about access 28 to services or resources via DNS SVCB and HTTP Resource Records. 29 This document also defines a new SvcParamKey for these Resource 30 Records, which specifies the specific QUIC versions in use. 32 About This Document 34 This note is to be removed before publishing as an RFC. 36 The latest revision of this draft can be found at 37 https://martinduke.github.io/quic-version-alt-svc-parameter/draft- 38 duke-httpbis-quic-version-alt-svc.html. Status information for this 39 document may be found at https://datatracker.ietf.org/doc/draft-duke- 40 httpbis-quic-version-alt-svc/. 42 Discussion of this document takes place on the HTTP Working Group 43 mailing list (mailto:ietf-http-wg@w3.org), which is archived at 44 https://lists.w3.org/Archives/Public/ietf-http-wg/. 46 Source for this draft and an issue tracker can be found at 47 https://github.com/martinduke/quic-version-alt-svc-parameter. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on 29 October 2022. 66 Copyright Notice 68 Copyright (c) 2022 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 73 license-info) in effect on the date of publication of this document. 74 Please review these documents carefully, as they describe your rights 75 and restrictions with respect to this document. Code Components 76 extracted from this document must include Revised BSD License text as 77 described in Section 4.e of the Trust Legal Provisions and are 78 provided without warranty as described in the Revised BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 84 3. The quicv Parameter . . . . . . . . . . . . . . . . . . . . . 4 85 4. The quicv SvcParamKey . . . . . . . . . . . . . . . . . . . . 5 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 89 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 90 Normative References . . . . . . . . . . . . . . . . . . . . . 6 91 Informative References . . . . . . . . . . . . . . . . . . . . 6 92 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 93 A.1. since draft-duke-httpbis-quic-version-alt-svc-00 . . . . 7 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 96 1. Introduction 98 HTTP Alternative Services (Alt-Svc) [ALTSVC] describes how one 99 origin's resource can be accessed via a different protocol/host/port 100 combination. Alternatives are advertised by servers using the Alt- 101 Svc header field or the ALTSVC frame. This includes a protocol name, 102 which reuses codepoints from the Application-Layer Protocol 103 Negotiation (ALPN) TLS extension [RFC7301]. Servers can advertise 104 multiple alternatives, in which case the order reflects the server's 105 preferences (the first value being the most preferred). 107 Clients can ignore alternative services, or pick one at their 108 discretion. A client might use any details from the advertisement, 109 in addition to out of band information, in determining if an 110 alternative is suitable or preferred. 112 While ALPN was originally intend to allow multiple applications to 113 utilize TLS or DTLS on the same IP address and TCP or UDP port, ALPN 114 can also usefully identify the transport in an Alt-Svc context. The 115 "h3" ALPN codepoint informs the client that it can use HTTP/3 116 [I-D.ietf-quic-http] for access, which in turn requires the QUIC 117 transport protocol [RFC8999]. 119 QUIC is versioned. A client and server that both support a QUIC 120 version can, through a negotiation process, generally agree on that 121 version in no more than one round-trip. However, to avoid that 122 penalty clients might use the most commonly deployed QUIC version 123 (e.g. version 1 [RFC9000] at the time of writing), rather than the 124 version with the most desirable properties for the client's use case. 126 To avoid the round-trip, one solution would be to register unique 127 ALPN codepoints for each HTTP/3 and QUIC version combination. 128 However, this might complicate deployment of new versions and 129 deprecation of old ones: architecturally, an application should 130 provide its ALPN to its QUIC implementation. In this case, fully 131 deploying a new version in that implementation would require updating 132 all applications that use it. 134 Instead, this document specifies an Alt-Svc parameter that lists the 135 QUIC versions available to serve the resource. Clients that do not 136 understand this parameter will ignore it. They might default to the 137 most likely version, and/or incur a round-trip penalty in the event 138 of a mismatch. Clients that do process the parameter will connect 139 successfully using the most desirable version with high probability. 141 Domain Name System (DNS) Service Binding (SVCB) and HTTPS Resource 142 Records [I-D.ietf-dsnop-svcb-https] allow the distribution of access 143 instructions beyond the IP address via DNS. This document also 144 specifies a new SvcParamKey for these Resource Records to distribute 145 QUIC version information with this technique. 147 2. Conventions and Definitions 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in 152 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 This document uses the Augmented BNF defined in [RFC5234] and imports 156 parameter from Section 3 of [ALTSVC]. 158 3. The quicv Parameter 160 This document specifies the "quicv" Alt-Svc parameter, which lists 161 the QUIC versions supported by an endpoint, using the hexadecimal 162 representation of the version field in a QUIC long header, as 163 indicated in [RFC8999]. Senders MAY omit leading zeroes from version 164 numbers. 166 quicv = version-list 167 version-list = DQUOTE version 1*( OWS, "," OWS version-number) DQUOTE 168 version = 1*8 HEXDIG; hex-encoded QUIC version 170 Examples: 172 Alt-Svc: h3=":443"; quicv="1" 173 Alt-Svc: h3=":443"; quicv="709a50c4,1" 174 Alt-Svc: h3=":443"; quicv="709a50c4,1", h3=":1001"; quicv="709a50c4" 176 The order of entries in version-list reflects the server's preference 177 (with the first value being the most preferred alternative). 179 Note that the quicv parameter applies to a single associated entry in 180 the Alt-Svc list. Servers MUST NOT provide a quicv parameter to an 181 entry containing ALPN codepoint that does not potentially utilize 182 QUIC. 184 If the Alt-Svc information resolves to a server pool that 185 inconsistently supports different QUIC versions, the parameter SHOULD 186 only advertise versions that are supported throughout the pool. 188 4. The quicv SvcParamKey 190 SVCB and HTTPS Resource Records can include the quicv SvcParamKey. 191 Its presentation format value and use are identical to the quicv Alt- 192 Svc Parameter. Its wire format value consists of the version numbers 193 in network byte order. 195 To include the quicv SvcParamKey in a resource record, it MUST also 196 include at least one ALPN that can be delivered over QUIC. 198 For example, consider a service configuration that advertisees two 199 QUIC versions on the default port, but only one version on a non- 200 default port. 202 In Alt-Svc, this could be represented as: 204 Alt-Svc: h3=":443"; quicv="709a50c4,1", h3=":1001"; quicv="709a50c4" 206 As HTTPS RRs, this could be represented as: 208 example.com IN HTTPS 1 . alpn=h2,h3 quicv=709a50c4,1 209 example.com IN HTTPS 1 . alpn=h3 port=1001 quicv=709a50c4 211 5. Security Considerations 213 This document inherits the security considerations of [ALTSVC], 214 especially the implications of "Changing Protocols" in Section 9.3. 215 There are few protocol properties guaranteed to hold across all QUIC 216 versions, so endpoints should be aware what capabilities are 217 intrinsic to the QUIC versions they are advertising. 219 This parameter reveals capabilities of the described server, but this 220 information is already available by inducing the server to generate a 221 QUIC version negotiation packet. 223 6. IANA Considerations 225 Please add this entry to the HTTP Alt-Svc Parameter Registry: 227 Alt-Svc Parameter: quicv 229 Reference: This document 231 Please add this entry to the Service Binding (SVCB) Parameter 232 Registry: 234 Number: TBD 235 Name: quicv 237 Meaning: Supported QUIC versions 239 Format Reference: This document 241 Acknowledgments 243 Thanks to Ben Schwartz for his help with the Resource Record 244 formatting. 246 References 248 Normative References 250 [ALTSVC] Bishop, M. and M. Thomson, "HTTP Alternative Services", 251 Work in Progress, Internet-Draft, draft-ietf-httpbis- 252 rfc7838bis-00, 31 August 2021, 253 . 256 [I-D.ietf-dsnop-svcb-https] 257 "*** BROKEN REFERENCE ***". 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, 261 DOI 10.17487/RFC2119, March 1997, 262 . 264 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 265 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 266 May 2017, . 268 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 269 Specifications: ABNF", STD 68, RFC 5234, 270 DOI 10.17487/RFC5234, January 2008, 271 . 273 Informative References 275 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 276 "Transport Layer Security (TLS) Application-Layer Protocol 277 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 278 July 2014, . 280 [I-D.ietf-quic-http] 281 Bishop, M., "Hypertext Transfer Protocol Version 3 282 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 283 quic-http-34, 2 February 2021, 284 . 287 [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", 288 RFC 8999, DOI 10.17487/RFC8999, May 2021, 289 . 291 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 292 Multiplexed and Secure Transport", RFC 9000, 293 DOI 10.17487/RFC9000, May 2021, 294 . 296 Appendix A. Change Log 298 *RFC Editor's Note:* Please remove this section prior to 299 publication of a final version of this document. 301 A.1. since draft-duke-httpbis-quic-version-alt-svc-00 303 * Added SVCB and HTTPS Resource Records 305 Authors' Addresses 307 Martin Duke 308 Google 309 Email: martin.h.duke@gmail.com 311 Lucas Pardue 312 Cloudflare 313 Email: lucaspardue.24.7@gmail.com