idnits 2.17.1 draft-ietf-webtrans-http2-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (7 March 2022) is 781 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) -- Possible downref: Normative reference to a draft: ref. 'HTTP' == Outdated reference: A later version (-07) exists of draft-ietf-webtrans-overview-03 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-09) exists of draft-ietf-webtrans-http3-02 -- Obsolete informational reference (is this intentional?): RFC 6824 (ref. 'MPTCP') (Obsoleted by RFC 8684) -- Duplicate reference: RFC9000, mentioned in 'QUIC', was also mentioned in 'RFC9000'. Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 webtrans A. Frindell 3 Internet-Draft Facebook Inc. 4 Intended status: Standards Track E. Kinnear 5 Expires: 8 September 2022 T. Pauly 6 Apple Inc. 7 M. Thomson 8 Mozilla 9 V. Vasiliev 10 Google 11 G. Xie 12 Facebook Inc. 13 7 March 2022 15 WebTransport using HTTP/2 16 draft-ietf-webtrans-http2-03 18 Abstract 20 WebTransport defines a set of low-level communications features 21 designed for client-server interactions that are initiated by Web 22 clients. This document describes a protocol that can provide many of 23 the capabilities of WebTransport over HTTP/2. This protocol enables 24 the use of WebTransport when a UDP-based protocol is not available. 26 Note to Readers 28 Discussion of this draft takes place on the WebTransport mailing list 29 (webtransport@ietf.org (mailto:webtransport@ietf.org)), which is 30 archived at https://mailarchive.ietf.org/arch/ 31 search/?email_list=webtransport. 33 The repository tracking the issues for this draft can be found at 34 https://github.com/ietf-wg-webtrans/draft-webtransport-http2. The 35 web API draft corresponding to this document can be found at 36 https://w3c.github.io/webtransport/. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 8 September 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Session Establishment . . . . . . . . . . . . . . . . . . . . 4 75 3.1. Establishing a Transport-Capable HTTP/2 Connection . . . 5 76 3.2. Extended CONNECT in HTTP/2 . . . . . . . . . . . . . . . 5 77 3.3. Creating a New Session . . . . . . . . . . . . . . . . . 5 78 3.4. Limiting the Number of Simultaneous Sessions . . . . . . 6 79 4. WebTransport Features . . . . . . . . . . . . . . . . . . . . 6 80 4.1. Transport Considerations . . . . . . . . . . . . . . . . 6 81 4.2. WebTransport Stream States . . . . . . . . . . . . . . . 7 82 5. WebTransport Frames . . . . . . . . . . . . . . . . . . . . . 7 83 5.1. WT_PADDING Frames . . . . . . . . . . . . . . . . . . . . 8 84 5.2. WT_RESET_STREAM Frames . . . . . . . . . . . . . . . . . 8 85 5.3. WT_STOP_SENDING Frames . . . . . . . . . . . . . . . . . 9 86 5.4. WT_STREAM Frames . . . . . . . . . . . . . . . . . . . . 9 87 5.5. WT_MAX_DATA Frames . . . . . . . . . . . . . . . . . . . 10 88 5.6. WT_MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . 10 89 5.7. WT_MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . 11 90 5.8. WT_DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . 12 91 5.9. WT_STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . 12 92 5.10. WT_STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . 13 93 5.11. WT_DATAGRAM Frames . . . . . . . . . . . . . . . . . . . 13 94 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 7. Session Termination . . . . . . . . . . . . . . . . . . . . . 16 96 8. Transport Properties . . . . . . . . . . . . . . . . . . . . 16 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 10.1. HTTP/2 SETTINGS Parameter Registration . . . . . . . . . 18 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 102 11.2. Informative References . . . . . . . . . . . . . . . . . 19 103 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 107 1. Introduction 109 WebTransport [OVERVIEW] is designed to provide generic communication 110 capabilities to Web clients that use HTTP/3 [HTTP3]. The HTTP/3 111 WebTransport protocol [WEBTRANSPORT-H3] allows Web clients to use 112 QUIC [QUIC] features such as streams or datagrams [DATAGRAM]. 113 However, there are some environments where QUIC cannot be deployed. 115 This document defines a protocol that provides all of the core 116 functions of WebTransport using HTTP semantics. This includes 117 unidirectional streams, bidirectional streams, and datagrams. 119 By relying only on generic HTTP semantics, this protocol might allow 120 deployment using any HTTP version. However, this document only 121 defines negotiation for HTTP/2 [H2] as the current most common TCP- 122 based fallback to HTTP/3. 124 1.1. Terminology 126 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 This document follows terminology defined in Section 1.2 of 133 [OVERVIEW]. Note that this document distinguishes between a 134 WebTransport server and an HTTP/2 server. An HTTP/2 server is the 135 server that terminates HTTP/2 connections; a WebTransport server is 136 an application that accepts WebTransport sessions, which can be 137 accessed using HTTP/2 and this protocol. 139 2. Protocol Overview 141 WebTransport servers are identified by an HTTPS URI as defined in 142 Section 4.2.2 of [HTTP]. 144 When an HTTP/2 connection is established, both the client and server 145 have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to 146 indicate that they both support WebTransport over HTTP/2. 148 A client initiates a WebTransport session by sending an extended 149 CONNECT request [RFC8441]. If the server accepts the request, a 150 WebTransport session is established. The stream that carries the 151 CONNECT request is used to exchange bidirectional data for the 152 session. This stream will be referred to as a _CONNECT stream_. The 153 stream ID of a CONNECT stream, which will be referrred to as a 154 _Session ID_, is used to uniquely identify a given WebTransport 155 session within the connection. 157 After the session is established, endpoints exchange _WebTransport 158 frames_ using the bidirectional CONNECT stream. Within this stream, 159 _WebTransport streams_ and _WebTransport datagrams_ are multiplexed. 160 In HTTP/2, WebTransport frames are carried in HTTP/2 DATA frames. 161 Multiple independent WebTransport sessions can share a connection if 162 the HTTP version supports that, as HTTP/2 does. 164 WebTransport frames closely mirror a subset of QUIC frames and 165 provide the essential WebTransport features. Within a WebTransport 166 session, endpoints can 168 * create and use bidirectional or unidirectional streams with no 169 additional round trips using WT_STREAM frames 171 Stream creation and data flow on streams uses flow control mechanisms 172 modeled on those in QUIC. Flow control is managed using the 173 WebTransport frames: WT_MAX_DATA, WT_MAX_STREAM_DATA, WT_MAX_STREAMS, 174 WT_DATA_BLOCKED, WT_STREAM_DATA_BLOCKED, and WT_STREAMS_BLOCKED. 175 Flow control for the CONNECT stream as a whole, as provided by the 176 HTTP version in use, applies in addition to any WebTransport-session- 177 level flow control. 179 WebTransport streams can be aborted using a WT_RESET_STREAM frame and 180 a receiver can request that a sender stop sending with a 181 WT_STOP_SENDING frame. 183 A WebTransport session is terminated when the CONNECT stream that 184 created it is closed. This implicitly closes all WebTransport 185 streams that were multiplexed over that CONNECT stream. 187 3. Session Establishment 188 3.1. Establishing a Transport-Capable HTTP/2 Connection 190 In order to indicate support for WebTransport, both the client and 191 the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1" 192 in their SETTINGS frame. Endpoints MUST NOT use any WebTransport- 193 related functionality unless the parameter has been negotiated. 195 3.2. Extended CONNECT in HTTP/2 197 [RFC8441] defines an extended CONNECT method in Section 4, enabled by 198 the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter. An endpoint does not 199 need to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and 200 SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT 201 setting implies that an endpoint supports extended CONNECT. 203 3.3. Creating a New Session 205 As WebTransport sessions are established over HTTP, they are 206 identified using the https URI scheme [RFC7230]. 208 In order to create a new WebTransport session, a client can send an 209 HTTP CONNECT request. The :protocol pseudo-header field ([RFC8441]) 210 MUST be set to webtransport (Section 7.1 of [WEBTRANSPORT-H3]). The 211 :scheme field MUST be https. Both the :authority and the :path value 212 MUST be set; those fields indicate the desired WebTransport server. 213 In a Web context, the request MUST include an Origin header field 214 [ORIGIN] that includes the origin of the site that requested the 215 creation of the session. 217 Upon receiving an extended CONNECT request with a :protocol field set 218 to webtransport, the HTTP server checks if the identified resource 219 supports WebTransport sessions. If the resource does not, the server 220 SHOULD reply with status code 404 (Section 6.5.4 of [RFC7231]). To 221 accept a WebTransport session the server replies with 2xx status 222 code. Before accepting a session, a server MUST ensure that it 223 authorizes use of the session by the site identified in the Origin 224 header. 226 From the client's perspective, a WebTransport session is established 227 when the client receives a 200 response. From the server's 228 perspective, a session is established once it sends a 200 response. 229 Both endpoints MUST NOT send any WebTransport frames on a given 230 session before that session is established. 232 3.4. Limiting the Number of Simultaneous Sessions 234 From a flow control perspective, WebTransport sessions count against 235 HTTP/2 session flow control limits just like regular HTTP requests, 236 since they are established via an HTTP CONNECT request. This 237 document does not make any effort to introduce a separate flow 238 control mechanism for WebTransport sessions. If the server needs to 239 limit the rate of incoming requests, it has alternative mechanisms at 240 its disposal: 242 * HTTP_STREAM_REFUSED error code defined in [RFC7540] indicates to 243 the receiving HTTP/2 stack that the request was not processed in 244 any way. 246 * HTTP status code 429 indicates that the request was rejected due 247 to rate limiting [RFC6585]. Unlike the previous method, this 248 signal is directly propagated to the application. 250 4. WebTransport Features 252 WebTransport over TCP-based HTTP semantics provides the following 253 features described in [OVERVIEW]: unidirectional streams, 254 bidirectional streams, and datagrams, initiated by either endpoint. 256 WebTransport streams and datagrams that belong to different 257 WebTransport sessions are identified by the CONNECT stream on which 258 they are transmitted, with one WebTransport session consuming one 259 CONNECT stream. 261 4.1. Transport Considerations 263 Because WebTransport over TCP-based HTTP semantics relies on the 264 underlying protocols to provide in order and reliable delivery, there 265 are some notable differences from the way in which QUIC handles 266 application data. 268 Endpoints MUST send stream data in order. As there is no ordering 269 mechanism available for the receiver to reassemble incoming data, 270 receivers assume that all data arriving in STREAM frames is 271 contiguous and in order. 273 DATAGRAM frames are delivered to the remote WebTransport endpoint 274 reliably, however this does not require that the receiving 275 implementation deliver that data to the application in a reliable 276 manner. 278 4.2. WebTransport Stream States 280 WebTransport streams have states that mirror the states of QUIC 281 streams (Section 3 of [RFC9000]) as closely as possible to aid in 282 ease of implementation. 284 Because WebTransport does not provide an acknowledgement mechanism 285 for WebTransport frames, it relies on the underlying transport's in 286 order delivery to inform stream state transitions. Wherever QUIC 287 relies on receiving an ack for a packet to transition between stream 288 states, WebTransport performs that transition immediately. 290 5. WebTransport Frames 292 WebTransport frames mirror their QUIC counterparts as closely as 293 possible to enable maximal reuse of any applicable QUIC 294 infrastructure by implementors. 296 A WebTransport frame begins with a Frame Type and Frame Length which 297 are followed by zero or more fields that are type-dependent. 299 Frame { 300 Frame Type (i), 301 Frame Length (i), 302 Type-Dependent Fields (..), 303 } 305 Figure 1: WebTransport Frame Format 307 The Frame Type field indicates the type of the frame, defining what 308 type-dependent fields will be present. 310 The Frame Length field indicates the length of the WebTransport 311 frame, including all type-dependent fields and other information. It 312 does not include the size of the Frame Type or Frame Length fields 313 themselves. 315 Both of these fields use a variable-length integer encoding (see 316 Section 16 of [RFC9000]), with one exception. To ensure simple and 317 efficient implementations of frame parsing, the frame type and length 318 MUST use the shortest possible encoding. For example, for the frame 319 types defined in this document, this means a single-byte encoding, 320 even though it is possible to encode these values as a two-, four-, 321 or eight-byte variable-length integer. 323 5.1. WT_PADDING Frames 325 A WT_PADDING frame (type=0x00) has no semantic value. PADDING frames 326 can be used to introduce additional data between other WebTransport 327 frames and can also be used to provide protection against traffic 328 analysis or for other reasons. 330 WT_PADDING Frame { 331 Type (i) = 0x00, 332 Length (i), 333 Padding (..), 334 } 336 Figure 2: WT_PADDING Frame Format 338 The Padding field MUST be set to an all-zero sequence of bytes of any 339 length as specified by the Length field. 341 5.2. WT_RESET_STREAM Frames 343 A WebTransport frame called WT_RESET_STREAM is introduced for either 344 endpoint to abruptly terminate the sending part of a WebTransport 345 stream. 347 An endpoint uses a WT_RESET_STREAM frame (type=0x04) to abruptly 348 terminate the sending part of a stream. 350 After sending a WT_RESET_STREAM, an endpoint ceases transmission and 351 retransmission of WT_STREAM frames on the identified stream. A 352 receiver of WT_RESET_STREAM can discard any data that it already 353 received on that stream. 355 WT_RESET_STREAM Frame { 356 Type (i) = 0x04, 357 Length (i), 358 Stream ID (i), 359 Application Protocol Error Code (i), 360 } 362 Figure 3: WT_RESET_STREAM Frame Format 364 The WT_RESET_STREAM frame defines the following fields: 366 Stream ID: A variable-length integer encoding of the WebTransport 367 stream ID of the stream being terminated. 369 Application Protocol Error Code: A variable-length integer 370 containing the application protocol error code that indicates why 371 the stream is being closed. 373 Unlike the equivalent QUIC frame, this frame does not include a Final 374 Size field. In-order delivery of WT_STREAM frames ensures that the 375 amount of session-level flow control consumed by a stream is always 376 known by both endpoints. 378 5.3. WT_STOP_SENDING Frames 380 A WebTransport frame called WT_STOP_SENDING is introduced to 381 communicate that incoming data is being discarded on receipt per 382 application request. WT_STOP_SENDING requests that a peer cease 383 transmission on a stream. 385 WT_STOP_SENDING Frame { 386 Type (i) = 0x05, 387 Length (i), 388 Stream ID (i), 389 Application Protocol Error Code (i), 390 } 392 Figure 4: WT_STOP_SENDING Frame Format 394 The WT_STOP_SENDING frame defines the following fields: 396 Stream ID: A variable-length integer carrying the WebTransport 397 stream ID of the stream being ignored. 399 Application Protocol Error Code: A variable-length integer 400 containing the application-specified reason the sender is ignoring 401 the stream. 403 5.4. WT_STREAM Frames 405 WT_STREAM frames implicitly create a stream and carry stream data. 407 The Type field in the WT_STREAM frame is either 0x0a or 0x0b. This 408 uses the same frame types as a QUIC STREAM frame with the OFF bit 409 clear and the LEN bit set. The FIN bit (0x01) in the frame type 410 indicates that the frame marks the end of the stream in one 411 direction. Stream data consists of any number of 0x0a frames 412 followed by a terminal 0x0b frame. 414 WT_STREAM Frame { 415 Type (i) = 0x0a..0x0b, 416 Length (i), 417 Stream ID (i), 418 Stream Data (..), 419 } 421 Figure 5: WT_STREAM Frame Format 423 WT_STREAM frames contain the following fields: 425 Stream ID: The stream ID for the stream. 427 Stream Data: Zero or more bytes of data for the stream. Empty 428 WT_STREAM frames MUST NOT be used unless they open or close a 429 stream; an endpoint MAY treat an empty WT_STREAM frame that 430 neither starts nor ends a stream as a session error. 432 5.5. WT_MAX_DATA Frames 434 A WebTransport frame called WT_MAX_DATA is introduced to inform the 435 peer of the maximum amount of data that can be sent on the 436 WebTransport session as a whole. 438 WT_MAX_DATA Frame { 439 Type (i) = 0x10, 440 Length (i), 441 Maximum Data (i), 442 } 444 Figure 6: WT_MAX_DATA Frame Format 446 WT_MAX_DATA frames contain the following field: 448 Maximum Data: A variable-length integer indicating the maximum 449 amount of data that can be sent on the entire connection, in units 450 of bytes. 452 All data sent in WT_STREAM frames counts toward this limit. The sum 453 of the lengths of Stream Data fields in WT_STREAM frames MUST NOT 454 exceed the value advertised by a receiver. 456 5.6. WT_MAX_STREAM_DATA Frames 458 A WebTransport frame called WT_MAX_STREAM_DATA is introduced to 459 inform a peer of the maximum amount of data that can be sent on a 460 stream. 462 WT_MAX_STREAM_DATA Frame { 463 Type (i) = 0x11, 464 Length (i), 465 Stream ID (i), 466 Maximum Stream Data (i), 467 } 469 Figure 7: WT_MAX_STREAM_DATA Frame Format 471 WT_MAX_STREAM_DATA frames contain the following fields: 473 Stream ID: The stream ID of the affected WebTransport stream, 474 encoded as a variable-length integer. 476 Maximum Stream Data: A variable-length integer indicating the 477 maximum amount of data that can be sent on the identified stream, 478 in units of bytes. 480 All data sent in WT_STREAM frames for the identified stream counts 481 toward this limit. The sum of the lengths of Stream Data fields in 482 WT_STREAM frames on the identified stream MUST NOT exceed the value 483 advertised by a receiver. 485 5.7. WT_MAX_STREAMS Frames 487 A WebTransport frame called WT_MAX_STREAMS is introduced to inform 488 the peer of the cumulative number of streams of a given type it is 489 permitted to open. A WT_MAX_STREAMS frame with a type of 0x12 490 applies to bidirectional streams, and a WT_MAX_STREAMS frame with a 491 type of 0x13 applies to unidirectional streams. 493 WT_MAX_STREAMS Frame { 494 Type (i) = 0x12..0x13, 495 Length (i), 496 Maximum Streams (i), 497 } 499 Figure 8: WT_MAX_STREAMS Frame Format 501 WT_MAX_STREAMS frames contain the following field: 503 Maximum Streams: A count of the cumulative number of streams of the 504 corresponding type that can be opened over the lifetime of the 505 connection. This value cannot exceed 2^60, as it is not possible 506 to encode stream IDs larger than 2^62-1. 508 An endpoint MUST NOT open more streams than permitted by the current 509 stream limit set by its peer. For instance, a server that receives a 510 unidirectional stream limit of 3 is permitted to open streams 3, 7, 511 and 11, but not stream 15. 513 Note that this limit includes streams that have been closed as well 514 as those that are open. 516 5.8. WT_DATA_BLOCKED Frames 518 A sender SHOULD send a WT_DATA_BLOCKED frame (type=0x14) when it 519 wishes to send data but is unable to do so due to WebTransport 520 session-level flow control. WT_DATA_BLOCKED frames can be used as 521 input to tuning of flow control algorithms. 523 WT_DATA_BLOCKED Frame { 524 Type (i) = 0x14, 525 Length (i), 526 Maximum Data (i), 527 } 529 Figure 9: WT_DATA_BLOCKED Frame Format 531 WT_DATA_BLOCKED frames contain the following field: 533 Maximum Data: A variable-length integer indicating the session-level 534 limit at which blocking occurred. 536 5.9. WT_STREAM_DATA_BLOCKED Frames 538 A sender SHOULD send a WT_STREAM_DATA_BLOCKED frame (type=0x15) when 539 it wishes to send data but is unable to do so due to stream-level 540 flow control. This frame is analogous to WT_DATA_BLOCKED. 542 WT_STREAM_DATA_BLOCKED Frame { 543 Type (i) = 0x15, 544 Length (i), 545 Stream ID (i), 546 Maximum Stream Data (i), 547 } 549 Figure 10: WT_STREAM_DATA_BLOCKED Frame Format 551 WT_STREAM_DATA_BLOCKED frames contain the following fields: 553 Stream ID: A variable-length integer indicating the WebTransport 554 stream that is blocked due to flow control. 556 Maximum Stream Data: A variable-length integer indicating the offset 557 of the stream at which the blocking occurred. 559 5.10. WT_STREAMS_BLOCKED Frames 561 A sender SHOULD send a WT_STREAMS_BLOCKED frame (type=0x16 or 0x17) 562 when it wishes to open a stream but is unable to do so due to the 563 maximum stream limit set by its peer. A WT_STREAMS_BLOCKED frame of 564 type 0x16 is used to indicate reaching the bidirectional stream 565 limit, and a STREAMS_BLOCKED frame of type 0x17 is used to indicate 566 reaching the unidirectional stream limit. 568 A WT_STREAMS_BLOCKED frame does not open the stream, but informs the 569 peer that a new stream was needed and the stream limit prevented the 570 creation of the stream. 572 WT_STREAMS_BLOCKED Frame { 573 Type (i) = 0x16..0x17, 574 Length (i), 575 Maximum Streams (i), 576 } 578 Figure 11: WT_STREAMS_BLOCKED Frame Format 580 WT_STREAMS_BLOCKED frames contain the following field: 582 Maximum Streams: A variable-length integer indicating the maximum 583 number of streams allowed at the time the frame was sent. This 584 value cannot exceed 2^60, as it is not possible to encode stream 585 IDs larger than 2^62-1. 587 5.11. WT_DATAGRAM Frames 589 The WT_DATAGRAM frame type (0x31) is used to carry datagram traffic. 590 Frame type 0x30 is also reserved to maintain parity with QUIC, but 591 unused, as all WebTransport frames MUST contain a length field. 593 WT_DATAGRAM Frame { 594 Type (i) = 0x31, 595 Length (i), 596 Datagram Data (..), 597 } 599 Figure 12: WT_DATAGRAM Frame Format 601 WT_DATAGRAM frames contain the following fields: 603 Datagram Data: The content of the datagram to be delivered. 605 The data in WT_DATAGRAM frames is not subject to flow control. The 606 receiver MAY discard this data if it does not have sufficient space 607 to buffer it. 609 An intermediary could forward the data in a WT_DATAGRAM frame over 610 another protocol, such as WebTransport over HTTP/3. In QUIC, a 611 datagram frame can span at most one packet. Because of that, the 612 applications have to know the maximum size of the datagram they can 613 send. However, when proxying the datagrams, the hop-by-hop MTUs can 614 vary. 616 6. Examples 618 An example of negotiating a WebTransport Stream on an HTTP/2 619 connection follows. This example is intended to closely follow the 620 example in Section 5.1 of [RFC8441] to help illustrate the 621 differences defined in this document. 623 [[ From Client ]] [[ From Server ]] 625 SETTINGS 626 SETTINGS_ENABLE_WEBTRANSPORT = 1 628 SETTINGS 629 SETTINGS_ENABLE_WEBTRANSPORT = 1 631 HEADERS + END_HEADERS 632 Stream ID = 3 633 :method = CONNECT 634 :protocol = webtransport 635 :scheme = https 636 :path = / 637 :authority = server.example.com 638 origin: server.example.com 640 HEADERS + END_HEADERS 641 Stream ID = 3 642 :status = 200 644 WT_STREAM 645 Stream ID = 5 646 WebTransport Data 648 WT_STREAM + FIN 649 Stream ID = 5 650 WebTransport Data 652 WT_STREAM + FIN 653 Stream ID = 5 654 WebTransport Data 656 An example of the server initiating a WebTransport Stream follows. 657 The only difference here is the endpoint that sends the first 658 WT_STREAM frame. 660 [[ From Client ]] [[ From Server ]] 662 SETTINGS 663 SETTINGS_ENABLE_WEBTRANSPORT = 1 665 SETTINGS 666 SETTINGS_ENABLE_WEBTRANSPORT = 1 668 HEADERS + END_HEADERS 669 Stream ID = 3 670 :method = CONNECT 671 :protocol = webtransport 672 :scheme = https 673 :path = / 674 :authority = server.example.com 675 origin: server.example.com 676 HEADERS + END_HEADERS 677 Stream ID = 3 678 :status = 200 680 WT_STREAM 681 Stream ID = 2 682 WebTransport Data 684 WT_STREAM + FIN 685 Stream ID = 2 686 WebTransport Data 688 WT_STREAM + FIN 689 Stream ID = 2 690 WebTransport Data 692 7. Session Termination 694 An WebTransport session over HTTP/2 is terminated when either 695 endpoint closes the stream associated with the CONNECT request that 696 initiated the session. Upon learning about the session being 697 terminated, the endpoint MUST stop sending new datagrams and reset 698 all of the streams associated with the session. 700 8. Transport Properties 702 The WebTransport framework [OVERVIEW] defines a set of optional 703 transport properties that clients can use to determine the presence 704 of features which might allow additional optimizations beyond the 705 common set of properties available via all WebTransport protocols. 706 Below are details about support in Http2Transport for those 707 properties. 709 Stream Independence: Http2Transport does not support stream 710 independence, as HTTP/2 inherently has head of line blocking. 712 Partial Reliability: Http2Transport does not support partial 713 reliability, as HTTP/2 retransmits any lost data. This means that 714 any datagrams sent via Http2Transport will be retransmitted 715 regardless of the preference of the application. The receiver is 716 permitted to drop them, however, if it is unable to buffer them. 718 Pooling Support: Http2Transport supports pooling, as multiple 719 transports using Http2Transport may share the same underlying 720 HTTP/2 connection and therefore share a congestion controller and 721 other transport context. 723 Connection Mobility: Http2Transport does not support connection 724 mobility, unless an underlying transport protocol that supports 725 multipath or migration, such as MPTCP [MPTCP], is used underneath 726 HTTP/2 and TLS. Without such support, Http2Transport connections 727 cannot survive network transitions. 729 9. Security Considerations 731 WebTransport over HTTP/2 satisfies all of the security requirements 732 imposed by [OVERVIEW] on WebTransport protocols, thus providing a 733 secure framework for client-server communication in cases when the 734 client is potentially untrusted. 736 WebTransport over HTTP/2 requires explicit opt-in through the use of 737 HTTP SETTINGS; this avoids potential protocol confusion attacks by 738 ensuring the HTTP/2 server explicitly supports it. It also requires 739 the use of the Origin header, providing the server with the ability 740 to deny access to Web-based clients that do not originate from a 741 trusted origin. 743 Just like HTTP traffic going over HTTP/2, WebTransport pools traffic 744 to different origins within a single connection. Different origins 745 imply different trust domains, meaning that the implementations have 746 to treat each transport as potentially hostile towards others on the 747 same connection. One potential attack is a resource exhaustion 748 attack: since all of the transports share both congestion control and 749 flow control context, a single client aggressively using up those 750 resources can cause other transports to stall. The user agent thus 751 SHOULD implement a fairness scheme that ensures that each transport 752 within connection gets a reasonable share of controlled resources; 753 this applies both to sending data and to opening new streams. 755 10. IANA Considerations 756 10.1. HTTP/2 SETTINGS Parameter Registration 758 The following entry is added to the "HTTP/2 Settings" registry 759 established by [RFC7540]: 761 The SETTINGS_ENABLE_WEBTRANSPORT parameter indicates that the 762 specified HTTP/2 connection is WebTransport-capable. 764 Setting Name: ENABLE_WEBTRANSPORT 766 Value: 0x2b603742 768 Default: 0 770 Specification: This document 772 11. References 774 11.1. Normative References 776 [H2] Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, 777 Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 778 2022, . 781 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 782 Semantics", Work in Progress, Internet-Draft, draft-ietf- 783 httpbis-semantics-19, 12 September 2021, 784 . 787 [ORIGIN] Barth, A., "The Web Origin Concept", RFC 6454, 788 DOI 10.17487/RFC6454, December 2011, 789 . 791 [OVERVIEW] Vasiliev, V., "The WebTransport Protocol Framework", Work 792 in Progress, Internet-Draft, draft-ietf-webtrans-overview- 793 03, 7 March 2022, . 796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 797 Requirement Levels", BCP 14, RFC 2119, 798 DOI 10.17487/RFC2119, March 1997, 799 . 801 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 802 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, 803 . 805 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 806 Protocol (HTTP/1.1): Message Syntax and Routing", 807 RFC 7230, DOI 10.17487/RFC7230, June 2014, 808 . 810 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 811 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 812 DOI 10.17487/RFC7231, June 2014, 813 . 815 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 816 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 817 DOI 10.17487/RFC7540, May 2015, 818 . 820 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 821 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 822 May 2017, . 824 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 825 RFC 8441, DOI 10.17487/RFC8441, September 2018, 826 . 828 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 829 Multiplexed and Secure Transport", RFC 9000, 830 DOI 10.17487/RFC9000, May 2021, 831 . 833 [WEBTRANSPORT-H3] 834 Frindell, A., Kinnear, E., and V. Vasiliev, "WebTransport 835 over HTTP/3", Work in Progress, Internet-Draft, draft- 836 ietf-webtrans-http3-02, 25 October 2021, 837 . 840 11.2. Informative References 842 [DATAGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 843 Datagram Extension to QUIC", Work in Progress, Internet- 844 Draft, draft-ietf-quic-datagram-10, 4 February 2022, 845 . 848 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 849 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 850 quic-http-34, 2 February 2021, 851 . 854 [MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 855 "TCP Extensions for Multipath Operation with Multiple 856 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 857 . 859 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 860 Multiplexed and Secure Transport", RFC 9000, 861 DOI 10.17487/RFC9000, May 2021, 862 . 864 Acknowledgments 866 Thanks to Anthony Chivetta, Joshua Otto, and Valentin Pistol for 867 their contributions in the design and implementation of this work. 869 Index 871 W 873 W 875 WT_DATAGRAM Section 5.11, Paragraph 1; Section 5.11, Paragraph 876 3; Section 5.11, Paragraph 5; Section 5.11, Paragraph 6 877 WT_DATA_BLOCKED Section 2, Paragraph 7; Section 5.8, Paragraph 878 1; Section 5.8, Paragraph 1; Section 5.8, Paragraph 3; 879 Section 5.9, Paragraph 1 880 WT_MAX_DATA Section 2, Paragraph 7; Section 5.5, Paragraph 1; 881 Section 5.5, Paragraph 3 882 WT_MAX_STREAMS Section 2, Paragraph 7; Section 5.7, Paragraph 883 1; Section 5.7, Paragraph 1; Section 5.7, Paragraph 1; 884 Section 5.7, Paragraph 3 885 WT_MAX_STREAM_DATA Section 2, Paragraph 7; Section 5.6, 886 Paragraph 1; Section 5.6, Paragraph 3 887 WT_PADDING Section 5.1, Paragraph 1 888 WT_RESET_STREAM Section 2, Paragraph 8; Section 5.2, Paragraph 889 1; Section 5.2, Paragraph 2; Section 5.2, Paragraph 3; 890 Section 5.2, Paragraph 3; Section 5.2, Paragraph 5 891 WT_STOP_SENDING Section 2, Paragraph 8; Section 5.3, Paragraph 892 1; Section 5.3, Paragraph 1; Section 5.3, Paragraph 3 893 WT_STREAM Section 2, Paragraph 6, Item 1; Section 5.2, 894 Paragraph 3; Section 5.2, Paragraph 7; Section 5.4, 895 Paragraph 1; Section 5.4, Paragraph 2; Section 5.4, 896 Paragraph 4; Section 5.4, Paragraph 5.4.1; Section 5.4, 897 Paragraph 5.4.1; Section 5.5, Paragraph 5; Section 5.5, 898 Paragraph 5; Section 5.6, Paragraph 5; Section 5.6, 899 Paragraph 5; Section 6, Paragraph 3 900 WT_STREAMS_BLOCKED Section 2, Paragraph 7; Section 5.10, 901 Paragraph 1; Section 5.10, Paragraph 1; Section 5.10, 902 Paragraph 2; Section 5.10, Paragraph 4 903 WT_STREAM_DATA_BLOCKED Section 2, Paragraph 7; Section 5.9, 904 Paragraph 1; Section 5.9, Paragraph 3 906 Authors' Addresses 908 Alan Frindell 909 Facebook Inc. 910 Email: afrind@fb.com 912 Eric Kinnear 913 Apple Inc. 914 One Apple Park Way 915 Cupertino, California 95014, 916 United States of America 917 Email: ekinnear@apple.com 919 Tommy Pauly 920 Apple Inc. 921 One Apple Park Way 922 Cupertino, California 95014, 923 United States of America 924 Email: tpauly@apple.com 926 Martin Thomson 927 Mozilla 928 Email: mt@lowentropy.net 930 Victor Vasiliev 931 Google 932 Email: vasilvv@google.com 934 Guowu Xie 935 Facebook Inc. 936 Email: woo@fb.com