{"blob_link":"https://github.com/minhuw/coquic/blob/b5f0cf69","issue_link":"https://github.com/minhuw/coquic/issues","specifications":{"https://www.rfc-editor.org/rfc/rfc9000":{"format":"ietf","requirements":[42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563],"sections":[{"id":"name-abstract","title":"Abstract","lines":[" 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."]},{"id":"name-status-of-this-memo","title":"Status of This Memo","lines":[" This is an Internet Standards Track document.",""," This document is a product of the Internet Engineering Task Force"," (IETF). It represents the consensus of the IETF community. It has"," received public review and has been approved for publication by the"," Internet Engineering Steering Group (IESG). Further information on"," Internet Standards is available in Section 2 of RFC 7841.",""," Information about the current status of this document, any errata,"," and how to provide feedback on it may be obtained at"," https://www.rfc-editor.org/info/rfc9000."]},{"id":"name-copyright-notice","title":"Copyright Notice","lines":[" Copyright (c) 2021 IETF Trust and the persons identified as the"," document authors. All rights reserved.",""," This document is subject to BCP 78 and the IETF Trust's Legal"," Provisions Relating to IETF Documents"," (https://trustee.ietf.org/license-info) in effect on the date of"," publication of this document. Please review these documents"," carefully, as they describe your rights and restrictions with respect"," to this document. Code Components extracted from this document must"," include Simplified BSD License text as described in Section 4.e of"," the Trust Legal Provisions and are provided without warranty as"," described in the Simplified BSD License."]},{"id":"name-table-of-contents","title":"Table of Contents","lines":[" 1. Overview"," 1.1. Document Structure"," 1.2. Terms and Definitions"," 1.3. Notational Conventions"," 2. Streams"," 2.1. Stream Types and Identifiers"," 2.2. Sending and Receiving Data"," 2.3. Stream Prioritization"," 2.4. Operations on Streams"," 3. Stream States"," 3.1. Sending Stream States"," 3.2. Receiving Stream States"," 3.3. Permitted Frame Types"," 3.4. Bidirectional Stream States"," 3.5. Solicited State Transitions"," 4. Flow Control"," 4.1. Data Flow Control"," 4.2. Increasing Flow Control Limits"," 4.3. Flow Control Performance"," 4.4. Handling Stream Cancellation"," 4.5. Stream Final Size"," 4.6. Controlling Concurrency"," 5. Connections"," 5.1. Connection ID"," 5.1.1. Issuing Connection IDs"," 5.1.2. Consuming and Retiring Connection IDs"," 5.2. Matching Packets to Connections"," 5.2.1. Client Packet Handling"," 5.2.2. Server Packet Handling"," 5.2.3. Considerations for Simple Load Balancers"," 5.3. Operations on Connections"," 6. Version Negotiation"," 6.1. Sending Version Negotiation Packets"," 6.2. Handling Version Negotiation Packets"," 6.3. Using Reserved Versions"," 7. Cryptographic and Transport Handshake"," 7.1. Example Handshake Flows"," 7.2. Negotiating Connection IDs"," 7.3. Authenticating Connection IDs"," 7.4. Transport Parameters"," 7.4.1. Values of Transport Parameters for 0-RTT"," 7.4.2. New Transport Parameters"," 7.5. Cryptographic Message Buffering"," 8. Address Validation"," 8.1. Address Validation during Connection Establishment"," 8.1.1. Token Construction"," 8.1.2. Address Validation Using Retry Packets"," 8.1.3. Address Validation for Future Connections"," 8.1.4. Address Validation Token Integrity"," 8.2. Path Validation"," 8.2.1. Initiating Path Validation"," 8.2.2. Path Validation Responses"," 8.2.3. Successful Path Validation"," 8.2.4. Failed Path Validation"," 9. Connection Migration"," 9.1. Probing a New Path"," 9.2. Initiating Connection Migration"," 9.3. Responding to Connection Migration"," 9.3.1. Peer Address Spoofing"," 9.3.2. On-Path Address Spoofing"," 9.3.3. Off-Path Packet Forwarding"," 9.4. Loss Detection and Congestion Control"," 9.5. Privacy Implications of Connection Migration"," 9.6. Server's Preferred Address"," 9.6.1. Communicating a Preferred Address"," 9.6.2. Migration to a Preferred Address"," 9.6.3. Interaction of Client Migration and Preferred Address"," 9.7. Use of IPv6 Flow Label and Migration"," 10. Connection Termination"," 10.1. Idle Timeout"," 10.1.1. Liveness Testing"," 10.1.2. Deferring Idle Timeout"," 10.2. Immediate Close"," 10.2.1. Closing Connection State"," 10.2.2. Draining Connection State"," 10.2.3. Immediate Close during the Handshake"," 10.3. Stateless Reset"," 10.3.1. Detecting a Stateless Reset"," 10.3.2. Calculating a Stateless Reset Token"," 10.3.3. Looping"," 11. Error Handling"," 11.1. Connection Errors"," 11.2. Stream Errors"," 12. Packets and Frames"," 12.1. Protected Packets"," 12.2. Coalescing Packets"," 12.3. Packet Numbers"," 12.4. Frames and Frame Types"," 12.5. Frames and Number Spaces"," 13. Packetization and Reliability"," 13.1. Packet Processing"," 13.2. Generating Acknowledgments"," 13.2.1. Sending ACK Frames"," 13.2.2. Acknowledgment Frequency"," 13.2.3. Managing ACK Ranges"," 13.2.4. Limiting Ranges by Tracking ACK Frames"," 13.2.5. Measuring and Reporting Host Delay"," 13.2.6. ACK Frames and Packet Protection"," 13.2.7. PADDING Frames Consume Congestion Window"," 13.3. Retransmission of Information"," 13.4. Explicit Congestion Notification"," 13.4.1. Reporting ECN Counts"," 13.4.2. ECN Validation"," 14. Datagram Size"," 14.1. Initial Datagram Size"," 14.2. Path Maximum Transmission Unit"," 14.2.1. Handling of ICMP Messages by PMTUD"," 14.3. Datagram Packetization Layer PMTU Discovery"," 14.3.1. DPLPMTUD and Initial Connectivity"," 14.3.2. Validating the Network Path with DPLPMTUD"," 14.3.3. Handling of ICMP Messages by DPLPMTUD"," 14.4. Sending QUIC PMTU Probes"," 14.4.1. PMTU Probes Containing Source Connection ID"," 15. Versions"," 16. Variable-Length Integer Encoding"," 17. Packet Formats"," 17.1. Packet Number Encoding and Decoding"," 17.2. Long Header Packets"," 17.2.1. Version Negotiation Packet"," 17.2.2. Initial Packet"," 17.2.3. 0-RTT"," 17.2.4. Handshake Packet"," 17.2.5. Retry Packet"," 17.3. Short Header Packets"," 17.3.1. 1-RTT Packet"," 17.4. Latency Spin Bit"," 18. Transport Parameter Encoding"," 18.1. Reserved Transport Parameters"," 18.2. Transport Parameter Definitions"," 19. Frame Types and Formats"," 19.1. PADDING Frames"," 19.2. PING Frames"," 19.3. ACK Frames"," 19.3.1. ACK Ranges"," 19.3.2. ECN Counts"," 19.4. RESET_STREAM Frames"," 19.5. STOP_SENDING Frames"," 19.6. CRYPTO Frames"," 19.7. NEW_TOKEN Frames"," 19.8. STREAM Frames"," 19.9. MAX_DATA Frames"," 19.10. MAX_STREAM_DATA Frames"," 19.11. MAX_STREAMS Frames"," 19.12. DATA_BLOCKED Frames"," 19.13. STREAM_DATA_BLOCKED Frames"," 19.14. STREAMS_BLOCKED Frames"," 19.15. NEW_CONNECTION_ID Frames"," 19.16. RETIRE_CONNECTION_ID Frames"," 19.17. PATH_CHALLENGE Frames"," 19.18. PATH_RESPONSE Frames"," 19.19. CONNECTION_CLOSE Frames"," 19.20. HANDSHAKE_DONE Frames"," 19.21. Extension Frames"," 20. Error Codes"," 20.1. Transport Error Codes"," 20.2. Application Protocol Error Codes"," 21. Security Considerations"," 21.1. Overview of Security Properties"," 21.1.1. Handshake"," 21.1.2. Protected Packets"," 21.1.3. Connection Migration"," 21.2. Handshake Denial of Service"," 21.3. Amplification Attack"," 21.4. Optimistic ACK Attack"," 21.5. Request Forgery Attacks"," 21.5.1. Control Options for Endpoints"," 21.5.2. Request Forgery with Client Initial Packets"," 21.5.3. Request Forgery with Preferred Addresses"," 21.5.4. Request Forgery with Spoofed Migration"," 21.5.5. Request Forgery with Version Negotiation"," 21.5.6. Generic Request Forgery Countermeasures"," 21.6. Slowloris Attacks"," 21.7. Stream Fragmentation and Reassembly Attacks"," 21.8. Stream Commitment Attack"," 21.9. Peer Denial of Service"," 21.10. Explicit Congestion Notification Attacks"," 21.11. Stateless Reset Oracle"," 21.12. Version Downgrade"," 21.13. Targeted Attacks by Routing"," 21.14. Traffic Analysis"," 22. IANA Considerations"," 22.1. Registration Policies for QUIC Registries"," 22.1.1. Provisional Registrations"," 22.1.2. Selecting Codepoints"," 22.1.3. Reclaiming Provisional Codepoints"," 22.1.4. Permanent Registrations"," 22.2. QUIC Versions Registry"," 22.3. QUIC Transport Parameters Registry"," 22.4. QUIC Frame Types Registry"," 22.5. QUIC Transport Error Codes Registry"," 23. References"," 23.1. Normative References"," 23.2. Informative References"," Appendix A. Pseudocode"," A.1. Sample Variable-Length Integer Decoding"," A.2. Sample Packet Number Encoding Algorithm"," A.3. Sample Packet Number Decoding Algorithm"," A.4. Sample ECN Validation Algorithm"," Contributors"," Authors' Addresses"]},{"id":"section-1","title":"Overview","lines":[" QUIC is a secure general-purpose transport protocol. This document"," defines version 1 of QUIC, which conforms to the version-independent"," properties of QUIC defined in [QUIC-INVARIANTS].",""," QUIC is a connection-oriented protocol that creates a stateful"," interaction between a client and server.",""," The QUIC handshake combines negotiation of cryptographic and"," transport parameters. QUIC integrates the TLS handshake [TLS13],"," although using a customized framing for protecting packets. The"," integration of TLS and QUIC is described in more detail in"," [QUIC-TLS]. The handshake is structured to permit the exchange of"," application data as soon as possible. This includes an option for"," clients to send data immediately (0-RTT), which requires some form of"," prior communication or configuration to enable.",""," Endpoints communicate in QUIC by exchanging QUIC packets. Most"," packets contain frames, which carry control information and"," application data between endpoints. QUIC authenticates the entirety"," of each packet and encrypts as much of each packet as is practical."," QUIC packets are carried in UDP datagrams [UDP] to better facilitate"," deployment in existing systems and networks.",""," Application protocols exchange information over a QUIC connection via"," streams, which are ordered sequences of bytes. Two types of streams"," can be created: bidirectional streams, which allow both endpoints to"," send data; and unidirectional streams, which allow a single endpoint"," to send data. A credit-based scheme is used to limit stream creation"," and to bound the amount of data that can be sent.",""," QUIC provides the necessary feedback to implement reliable delivery"," and congestion control. An algorithm for detecting and recovering"," from loss of data is described in Section 6 of [QUIC-RECOVERY]. QUIC"," depends on congestion control to avoid network congestion. An"," exemplary congestion control algorithm is described in Section 7 of"," [QUIC-RECOVERY].",""," QUIC connections are not strictly bound to a single network path."," Connection migration uses connection identifiers to allow connections"," to transfer to a new network path. Only clients are able to migrate"," in this version of QUIC. This design also allows connections to"," continue after changes in network topology or address mappings, such"," as might be caused by NAT rebinding.",""," Once established, multiple options are provided for connection"," termination. Applications can manage a graceful shutdown, endpoints"," can negotiate a timeout period, errors can cause immediate connection"," teardown, and a stateless mechanism provides for termination of"," connections after one endpoint has lost state."]},{"id":"section-1.1","title":"Document Structure","lines":[" This document describes the core QUIC protocol and is structured as"," follows:",""," * Streams are the basic service abstraction that QUIC provides.",""," - Section 2 describes core concepts related to streams,",""," - Section 3 provides a reference model for stream states, and",""," - Section 4 outlines the operation of flow control.",""," * Connections are the context in which QUIC endpoints communicate.",""," - Section 5 describes core concepts related to connections,",""," - Section 6 describes version negotiation,",""," - Section 7 details the process for establishing connections,",""," - Section 8 describes address validation and critical denial-of-"," service mitigations,",""," - Section 9 describes how endpoints migrate a connection to a new"," network path,",""," - Section 10 lists the options for terminating an open"," connection, and",""," - Section 11 provides guidance for stream and connection error"," handling.",""," * Packets and frames are the basic unit used by QUIC to communicate.",""," - Section 12 describes concepts related to packets and frames,",""," - Section 13 defines models for the transmission, retransmission,"," and acknowledgment of data, and",""," - Section 14 specifies rules for managing the size of datagrams"," carrying QUIC packets.",""," * Finally, encoding details of QUIC protocol elements are described"," in:",""," - Section 15 (versions),",""," - Section 16 (integer encoding),",""," - Section 17 (packet headers),",""," - Section 18 (transport parameters),",""," - Section 19 (frames), and",""," - Section 20 (errors).",""," Accompanying documents describe QUIC's loss detection and congestion"," control [QUIC-RECOVERY], and the use of TLS and other cryptographic"," mechanisms [QUIC-TLS].",""," This document defines QUIC version 1, which conforms to the protocol"," invariants in [QUIC-INVARIANTS].",""," To refer to QUIC version 1, cite this document. References to the"," limited set of version-independent properties of QUIC can cite"," [QUIC-INVARIANTS]."]},{"id":"section-1.2","title":"Terms and Definitions","lines":[" 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 [RFC2119] [RFC8174] when, and only when, they appear in all"," capitals, as shown here.",""," Commonly used terms in this document are described below.",""," QUIC: The transport protocol described by this document. QUIC is a"," name, not an acronym.",""," Endpoint: An entity that can participate in a QUIC connection by"," generating, receiving, and processing QUIC packets. There are"," only two types of endpoints in QUIC: client and server.",""," Client: The endpoint that initiates a QUIC connection.",""," Server: The endpoint that accepts a QUIC connection.",""," QUIC packet: A complete processable unit of QUIC that can be"," encapsulated in a UDP datagram. One or more QUIC packets can be"," encapsulated in a single UDP datagram.",""," Ack-eliciting packet: A QUIC packet that contains frames other than"," ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to"," send an acknowledgment; see Section 13.2.1.",""," Frame: A unit of structured protocol information. There are"," multiple frame types, each of which carries different information."," Frames are contained in QUIC packets.",""," Address: When used without qualification, the tuple of IP version,"," IP address, and UDP port number that represents one end of a"," network path.",""," Connection ID: An identifier that is used to identify a QUIC"," connection at an endpoint. Each endpoint selects one or more"," connection IDs for its peer to include in packets sent towards the"," endpoint. This value is opaque to the peer.",""," Stream: A unidirectional or bidirectional channel of ordered bytes"," within a QUIC connection. A QUIC connection can carry multiple"," simultaneous streams.",""," Application: An entity that uses QUIC to send and receive data.",""," This document uses the terms \"QUIC packets\", \"UDP datagrams\", and \"IP"," packets\" to refer to the units of the respective protocols. That is,"," one or more QUIC packets can be encapsulated in a UDP datagram, which"," is in turn encapsulated in an IP packet."]},{"id":"section-1.3","title":"Notational Conventions","lines":[" Packet and frame diagrams in this document use a custom format. The"," purpose of this format is to summarize, not define, protocol"," elements. Prose defines the complete semantics and details of"," structures.",""," Complex fields are named and then followed by a list of fields"," surrounded by a pair of matching braces. Each field in this list is"," separated by commas.",""," Individual fields include length information, plus indications about"," fixed value, optionality, or repetitions. Individual fields use the"," following notational conventions, with all lengths in bits:",""," x (A): Indicates that x is A bits long",""," x (i): Indicates that x holds an integer value using the variable-"," length encoding described in Section 16",""," x (A..B): Indicates that x can be any length from A to B; A can be"," omitted to indicate a minimum of zero bits, and B can be omitted"," to indicate no set upper limit; values in this format always end"," on a byte boundary",""," x (L) = C: Indicates that x has a fixed value of C; the length of x"," is described by L, which can use any of the length forms above",""," x (L) = C..D: Indicates that x has a value in the range from C to D,"," inclusive, with the length described by L, as above",""," [x (L)]: Indicates that x is optional and has a length of L",""," x (L) ...: Indicates that x is repeated zero or more times and that"," each instance has a length of L",""," This document uses network byte order (that is, big endian) values."," Fields are placed starting from the high-order bits of each byte.",""," By convention, individual fields reference a complex field by using"," the name of the complex field.",""," Figure 1 provides an example:",""," Example Structure {"," One-bit Field (1),"," 7-bit Field with Fixed Value (7) = 61,"," Field with Variable-Length Integer (i),"," Arbitrary-Length Field (..),"," Variable-Length Field (8..24),"," Field With Minimum Length (16..),"," Field With Maximum Length (..128),"," [Optional Field (64)],"," Repeated Field (8) ...,"," }",""," Figure 1: Example Format",""," When a single-bit field is referenced in prose, the position of that"," field can be clarified by using the value of the byte that carries"," the field with the field's value set. For example, the value 0x80"," could be used to refer to the single-bit field in the most"," significant bit of the byte, such as One-bit Field in Figure 1."]},{"id":"section-2","title":"Streams","lines":[" Streams in QUIC provide a lightweight, ordered byte-stream"," abstraction to an application. Streams can be unidirectional or"," bidirectional.",""," Streams can be created by sending data. Other processes associated"," with stream management -- ending, canceling, and managing flow"," control -- are all designed to impose minimal overheads. For"," instance, a single STREAM frame (Section 19.8) can open, carry data"," for, and close a stream. Streams can also be long-lived and can last"," the entire duration of a connection.",""," Streams can be created by either endpoint, can concurrently send data"," interleaved with other streams, and can be canceled. QUIC does not"," provide any means of ensuring ordering between bytes on different"," streams.",""," QUIC allows for an arbitrary number of streams to operate"," concurrently and for an arbitrary amount of data to be sent on any"," stream, subject to flow control constraints and stream limits; see"," Section 4."]},{"id":"section-2.1","title":"Stream Types and Identifiers","lines":[" Streams can be unidirectional or bidirectional. Unidirectional"," streams carry data in one direction: from the initiator of the stream"," to its peer. Bidirectional streams allow for data to be sent in both"," directions.",""," Streams are identified within a connection by a numeric value,"," referred to as the stream ID. A stream ID is a 62-bit integer (0 to"," 2^62-1) that is unique for all streams on a connection. Stream IDs",[[[],0," are encoded as variable-length integers; see Section 16. "],[[307,2019,2025,2026,2029,2030,2038,2039,2652,2860],244,"A QUIC"]],[[[],0," "],[[307,2019,2025,2026,2029,2030,2038,2039,2652,2860],244,"endpoint MUST NOT reuse a stream ID within a connection."]],""," The least significant bit (0x01) of the stream ID identifies the"," initiator of the stream. Client-initiated streams have even-numbered"," stream IDs (with the bit set to 0), and server-initiated streams have"," odd-numbered stream IDs (with the bit set to 1).",""," The second least significant bit (0x02) of the stream ID"," distinguishes between bidirectional streams (with the bit set to 0)"," and unidirectional streams (with the bit set to 1).",""," The two least significant bits from a stream ID therefore identify a"," stream as one of four types, as summarized in Table 1.",""," +======+==================================+"," | Bits | Stream Type |"," +======+==================================+"," | 0x00 | Client-Initiated, Bidirectional |"," +------+----------------------------------+"," | 0x01 | Server-Initiated, Bidirectional |"," +------+----------------------------------+"," | 0x02 | Client-Initiated, Unidirectional |"," +------+----------------------------------+"," | 0x03 | Server-Initiated, Unidirectional |"," +------+----------------------------------+",""," Table 1: Stream ID Types",""," The stream space for each type begins at the minimum value (0x00"," through 0x03, respectively); successive streams of each type are"," created with numerically increasing stream IDs. A stream ID that is"," used out of order results in all streams of that type with lower-"," numbered stream IDs also being opened."],"requirements":[307]},{"id":"section-2.2","title":"Sending and Receiving Data","lines":[" STREAM frames (Section 19.8) encapsulate data sent by an application."," An endpoint uses the Stream ID and Offset fields in STREAM frames to"," place data in order.","",[[[],0," "],[[308,1832,2819],244,"Endpoints MUST be able to deliver stream data to an application as an"]],[[[],0," "],[[308,1832,2819],244,"ordered byte stream."],[[],0," Delivering an ordered byte stream requires that"]]," an endpoint buffer any data that is received out of order, up to the"," advertised flow control limit.",""," QUIC makes no specific allowances for delivery of stream data out of",[[[],0," order. "],[[309],96,"However, "],[[309,1425,1830,2360,2361,2820],116,"implementations MAY choose to offer the ability to"]],[[[],0," "],[[309,1425,1830,2360,2361,2820],116,"deliver data out of order to a receiving application."]],""," An endpoint could receive data for a stream at the same stream offset"," multiple times. Data that has already been received can be",[[[],0," discarded. "],[[310,2366,2467,2538,2541],244,"The data at a given offset MUST NOT change if it is sent"]],[[[],0," "],[[310,2366,2467,2538,2541],244,"multiple times"],[[21,310],226,"; an endpoint MAY treat receipt of different data at"]],[[[],0," "],[[21,310],226,"the same offset within a stream as a connection error of type"]],[[[],0," "],[[21,310],226,"PROTOCOL_VIOLATION."]],""," Streams are an ordered byte-stream abstraction with no other"," structure visible to QUIC. STREAM frame boundaries are not expected"," to be preserved when data is transmitted, retransmitted after packet"," loss, or delivered to the application at a receiver.","",[[[],0," "],[[311,2468,2641,2643,2848],244,"An endpoint MUST NOT send data on any stream without ensuring that it"]],[[[],0," "],[[311,2468,2641,2643,2848],244,"is within the flow control limits set by its peer."],[[],0," Flow control is"]]," described in detail in Section 4."],"requirements":[308,309,310,311]},{"id":"section-2.3","title":"Stream Prioritization","lines":[" Stream multiplexing can have a significant effect on application"," performance if resources allocated to streams are correctly"," prioritized.",""," QUIC does not provide a mechanism for exchanging prioritization"," information. Instead, it relies on receiving priority information"," from the application.","",[[[],0," "],[[312,1717,2818],180,"A QUIC implementation SHOULD provide ways in which an application can"]],[[[],0," "],[[312,1717,2818],180,"indicate the relative priority of streams."],[[],0," An implementation uses"]]," information provided by the application to determine how to allocate"," resources to active streams."],"requirements":[312]},{"id":"section-2.4","title":"Operations on Streams","lines":[" This document does not define an API for QUIC; it instead defines a"," set of functions on streams that application protocols can rely upon."," An application protocol can assume that a QUIC implementation"," provides an interface that includes the operations described in this"," section. An implementation designed for use with a specific"," application protocol might provide only those operations that are"," used by that protocol.",""," On the sending part of a stream, an application protocol can:",""," * write data, understanding when stream flow control credit"," (Section 4.1) has successfully been reserved to send the written"," data;",""," * end the stream (clean termination), resulting in a STREAM frame"," (Section 19.8) with the FIN bit set; and",""," * reset the stream (abrupt termination), resulting in a RESET_STREAM"," frame (Section 19.4) if the stream was not already in a terminal"," state.",""," On the receiving part of a stream, an application protocol can:",""," * read data; and",""," * abort reading of the stream and request closure, possibly"," resulting in a STOP_SENDING frame (Section 19.5).",""," An application protocol can also request to be informed of state"," changes on streams, including when the peer has opened or reset a"," stream, when a peer aborts reading on a stream, when new data is"," available, and when data can or cannot be written to the stream due"," to flow control."]},{"id":"section-3","title":"Stream States","lines":[" This section describes streams in terms of their send or receive"," components. Two state machines are described: one for the streams on"," which an endpoint transmits data (Section 3.1) and another for"," streams on which an endpoint receives data (Section 3.2).",""," Unidirectional streams use either the sending or receiving state"," machine, depending on the stream type and endpoint role."," Bidirectional streams use both state machines at both endpoints. For"," the most part, the use of these state machines is the same whether"," the stream is unidirectional or bidirectional. The conditions for"," opening a stream are slightly more complex for a bidirectional stream"," because the opening of either the send or receive side causes the"," stream to open in both directions.",""," The state machines shown in this section are largely informative."," This document uses stream states to describe rules for when and how"," different types of frames can be sent and the reactions that are"," expected when different types of frames are received. Though these"," state machines are intended to be useful in implementing QUIC, these"," states are not intended to constrain implementations. An"," implementation can define a different state machine as long as its"," behavior is consistent with an implementation that implements these"," states.",""," | Note: In some cases, a single event or action can cause a"," | transition through multiple states. For instance, sending"," | STREAM with a FIN bit set can cause two state transitions for a"," | sending stream: from the \"Ready\" state to the \"Send\" state, and"," | from the \"Send\" state to the \"Data Sent\" state."]},{"id":"section-3.1","title":"Sending Stream States","lines":[" Figure 2 shows the states for the part of a stream that sends data to"," a peer.",""," o"," | Create Stream (Sending)"," | Peer Creates Bidirectional Stream"," v"," +-------+"," | Ready | Send RESET_STREAM"," | |-----------------------."," +-------+ |"," | |"," | Send STREAM / |"," | STREAM_DATA_BLOCKED |"," v |"," +-------+ |"," | Send | Send RESET_STREAM |"," | |---------------------->|"," +-------+ |"," | |"," | Send STREAM + FIN |"," v v"," +-------+ +-------+"," | Data | Send RESET_STREAM | Reset |"," | Sent |------------------>| Sent |"," +-------+ +-------+"," | |"," | Recv All ACKs | Recv ACK"," v v"," +-------+ +-------+"," | Data | | Reset |"," | Recvd | | Recvd |"," +-------+ +-------+",""," Figure 2: States for Sending Parts of Streams",""," The sending part of a stream that the endpoint initiates (types 0 and"," 2 for clients, 1 and 3 for servers) is opened by the application."," The \"Ready\" state represents a newly created stream that is able to"," accept data from the application. Stream data might be buffered in"," this state in preparation for sending.",""," Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a"," sending part of a stream to enter the \"Send\" state. An"," implementation might choose to defer allocating a stream ID to a"," stream until it sends the first STREAM frame and enters this state,"," which can allow for better stream prioritization.",""," The sending part of a bidirectional stream initiated by a peer (type"," 0 for a server, type 1 for a client) starts in the \"Ready\" state when"," the receiving part is created.",""," In the \"Send\" state, an endpoint transmits -- and retransmits as"," necessary -- stream data in STREAM frames. The endpoint respects the"," flow control limits set by its peer and continues to accept and"," process MAX_STREAM_DATA frames. An endpoint in the \"Send\" state"," generates STREAM_DATA_BLOCKED frames if it is blocked from sending by"," stream flow control limits (Section 4.1).",""," After the application indicates that all stream data has been sent"," and a STREAM frame containing the FIN bit is sent, the sending part"," of the stream enters the \"Data Sent\" state. From this state, the"," endpoint only retransmits stream data as necessary. The endpoint"," does not need to check flow control limits or send"," STREAM_DATA_BLOCKED frames for a stream in this state."," MAX_STREAM_DATA frames might be received until the peer receives the"," final stream offset. The endpoint can safely ignore any"," MAX_STREAM_DATA frames it receives from its peer for a stream in this"," state.",""," Once all stream data has been successfully acknowledged, the sending"," part of the stream enters the \"Data Recvd\" state, which is a terminal"," state.",""," From any state that is one of \"Ready\", \"Send\", or \"Data Sent\", an"," application can signal that it wishes to abandon transmission of"," stream data. Alternatively, an endpoint might receive a STOP_SENDING"," frame from its peer. In either case, the endpoint sends a"," RESET_STREAM frame, which causes the stream to enter the \"Reset Sent\""," state.","",[[[],0," "],[[22,352],98,"An endpoint MAY send a RESET_STREAM as the first frame that mentions"]],[[[],0," "],[[22,352],98,"a stream; this causes the sending part of that stream to open and"]],[[[],0," "],[[22,352],98,"then immediately transition to the \"Reset Sent\" state."]],""," Once a packet containing a RESET_STREAM has been acknowledged, the"," sending part of the stream enters the \"Reset Recvd\" state, which is a"," terminal state."],"requirements":[352]},{"id":"section-3.2","title":"Receiving Stream States","lines":[" Figure 3 shows the states for the part of a stream that receives data"," from a peer. The states for a receiving part of a stream mirror only"," some of the states of the sending part of the stream at the peer."," The receiving part of a stream does not track states on the sending"," part that cannot be observed, such as the \"Ready\" state. Instead,"," the receiving part of a stream tracks the delivery of data to the"," application, some of which cannot be observed by the sender.",""," o"," | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM"," | Create Bidirectional Stream (Sending)"," | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional)"," | Create Higher-Numbered Stream"," v"," +-------+"," | Recv | Recv RESET_STREAM"," | |-----------------------."," +-------+ |"," | |"," | Recv STREAM + FIN |"," v |"," +-------+ |"," | Size | Recv RESET_STREAM |"," | Known |---------------------->|"," +-------+ |"," | |"," | Recv All Data |"," v v"," +-------+ Recv RESET_STREAM +-------+"," | Data |--- (optional) --->| Reset |"," | Recvd | Recv All Data | Recvd |"," +-------+<-- (optional) ----+-------+"," | |"," | App Read All Data | App Read Reset"," v v"," +-------+ +-------+"," | Data | | Reset |"," | Read | | Read |"," +-------+ +-------+",""," Figure 3: States for Receiving Parts of Streams",""," The receiving part of a stream initiated by a peer (types 1 and 3 for"," a client, or 0 and 2 for a server) is created when the first STREAM,"," STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that"," stream. For bidirectional streams initiated by a peer, receipt of a"," MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the"," stream also creates the receiving part. The initial state for the"," receiving part of a stream is \"Recv\".",""," For a bidirectional stream, the receiving part enters the \"Recv\""," state when the sending part initiated by the endpoint (type 0 for a"," client, type 1 for a server) enters the \"Ready\" state.",""," An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or"," STOP_SENDING frame is received from the peer for that stream."," Receiving a MAX_STREAM_DATA frame for an unopened stream indicates"," that the remote peer has opened the stream and is providing flow"," control credit. Receiving a STOP_SENDING frame for an unopened"," stream indicates that the remote peer no longer wishes to receive"," data on this stream. Either frame might arrive before a STREAM or"," STREAM_DATA_BLOCKED frame if packets are lost or reordered.","",[[[],0," "],[[353,2024,2835,2844],244,"Before a stream is created, all streams of the same type with lower-"]],[[[],0," "],[[353,2024,2835,2844],244,"numbered stream IDs MUST be created."],[[],0," This ensures that the creation"]]," order for streams is consistent on both endpoints.",""," In the \"Recv\" state, the endpoint receives STREAM and"," STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be"," reassembled into the correct order for delivery to the application."," As data is consumed by the application and buffer space becomes"," available, the endpoint sends MAX_STREAM_DATA frames to allow the"," peer to send more data.",""," When a STREAM frame with a FIN bit is received, the final size of the"," stream is known; see Section 4.5. The receiving part of the stream"," then enters the \"Size Known\" state. In this state, the endpoint no"," longer needs to send MAX_STREAM_DATA frames; it only receives any"," retransmissions of stream data.",""," Once all data for the stream has been received, the receiving part"," enters the \"Data Recvd\" state. This might happen as a result of"," receiving the same STREAM frame that causes the transition to \"Size"," Known\". After all data has been received, any STREAM or"," STREAM_DATA_BLOCKED frames for the stream can be discarded.",""," The \"Data Recvd\" state persists until stream data has been delivered"," to the application. Once stream data has been delivered, the stream"," enters the \"Data Read\" state, which is a terminal state.",""," Receiving a RESET_STREAM frame in the \"Recv\" or \"Size Known\" state"," causes the stream to enter the \"Reset Recvd\" state. This might cause"," the delivery of stream data to the application to be interrupted.",""," It is possible that all stream data has already been received when a"," RESET_STREAM is received (that is, in the \"Data Recvd\" state)."," Similarly, it is possible for remaining stream data to arrive after"," receiving a RESET_STREAM frame (the \"Reset Recvd\" state). An"," implementation is free to manage this situation as it chooses.",""," Sending a RESET_STREAM means that an endpoint cannot guarantee"," delivery of stream data; however, there is no requirement that stream",[[[],0," data not be delivered if a RESET_STREAM is received. "],[[23,354],98,"An"]],[[[],0," "],[[23,354],98,"implementation MAY interrupt delivery of stream data, discard any"]],[[[],0," "],[[23,354],98,"data that was not consumed, and signal the receipt of the"]],[[[],0," "],[[23,354],98,"RESET_STREAM."],[[],0," A RESET_STREAM signal might be suppressed or withheld"]]," if stream data is completely received and is buffered to be read by"," the application. If the RESET_STREAM is suppressed, the receiving"," part of the stream remains in \"Data Recvd\".",""," Once the application receives the signal indicating that the stream"," was reset, the receiving part of the stream transitions to the \"Reset"," Read\" state, which is a terminal state."],"requirements":[353,354]},{"id":"section-3.3","title":"Permitted Frame Types","lines":[" The sender of a stream sends just three frame types that affect the"," state of a stream at either the sender or the receiver: STREAM"," (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM"," (Section 19.4).","",[[[],0," "],[[355,2457,2465,2861,3084,3089],244,"A sender MUST NOT send any of these frames from a terminal state"]],[[[],0," "],[[355,2457,2465,2861,3084,3089],244,"(\"Data Recvd\" or \"Reset Recvd\")."],[[],0," "],[[356,2458,2459,2466,2862,3085,3090],244,"A sender MUST NOT send a STREAM or"]],[[[],0," "],[[356,2458,2459,2466,2862,3085,3090],244,"STREAM_DATA_BLOCKED frame for a stream in the \"Reset Sent\" state or"]],[[[],0," "],[[356,2458,2459,2466,2862,3085,3090],244,"any terminal state -- that is, after sending a RESET_STREAM frame."],[[],0," A"]]," receiver could receive any of these three frames in any state, due to"," the possibility of delayed delivery of packets carrying them.",""," The receiver of a stream sends MAX_STREAM_DATA frames (Section 19.10)"," and STOP_SENDING frames (Section 19.5).",""," The receiver only sends MAX_STREAM_DATA frames in the \"Recv\" state.",[[[],0," "],[[24,357],98,"A receiver MAY send a STOP_SENDING frame in any state where it has"]],[[[],0," "],[[24,357],98,"not received a RESET_STREAM frame -- that is, states other than"]],[[[],0," "],[[24,357],98,"\"Reset Recvd\" or \"Reset Read\"."],[[],0," However, there is little value in"]]," sending a STOP_SENDING frame in the \"Data Recvd\" state, as all stream"," data has been received. A sender could receive either of these two"," types of frames in any state as a result of delayed delivery of"," packets."],"requirements":[355,356,357]},{"id":"section-3.4","title":"Bidirectional Stream States","lines":[" A bidirectional stream is composed of sending and receiving parts."," Implementations can represent states of the bidirectional stream as"," composites of sending and receiving stream states. The simplest"," model presents the stream as \"open\" when either sending or receiving"," parts are in a non-terminal state and \"closed\" when both sending and"," receiving streams are in terminal states.",""," Table 2 shows a more complex mapping of bidirectional stream states"," that loosely correspond to the stream states defined in HTTP/2"," [HTTP2]. This shows that multiple states on sending or receiving"," parts of streams are mapped to the same composite state. Note that"," this is just one possibility for such a mapping; this mapping"," requires that data be acknowledged before the transition to a"," \"closed\" or \"half-closed\" state.",""," +===================+=======================+=================+"," | Sending Part | Receiving Part | Composite State |"," +===================+=======================+=================+"," | No Stream / Ready | No Stream / Recv (*1) | idle |"," +-------------------+-----------------------+-----------------+"," | Ready / Send / | Recv / Size Known | open |"," | Data Sent | | |"," +-------------------+-----------------------+-----------------+"," | Ready / Send / | Data Recvd / Data | half-closed |"," | Data Sent | Read | (remote) |"," +-------------------+-----------------------+-----------------+"," | Ready / Send / | Reset Recvd / Reset | half-closed |"," | Data Sent | Read | (remote) |"," +-------------------+-----------------------+-----------------+"," | Data Recvd | Recv / Size Known | half-closed |"," | | | (local) |"," +-------------------+-----------------------+-----------------+"," | Reset Sent / | Recv / Size Known | half-closed |"," | Reset Recvd | | (local) |"," +-------------------+-----------------------+-----------------+"," | Reset Sent / | Data Recvd / Data | closed |"," | Reset Recvd | Read | |"," +-------------------+-----------------------+-----------------+"," | Reset Sent / | Reset Recvd / Reset | closed |"," | Reset Recvd | Read | |"," +-------------------+-----------------------+-----------------+"," | Data Recvd | Data Recvd / Data | closed |"," | | Read | |"," +-------------------+-----------------------+-----------------+"," | Data Recvd | Reset Recvd / Reset | closed |"," | | Read | |"," +-------------------+-----------------------+-----------------+",""," Table 2: Possible Mapping of Stream States to HTTP/2",""," | Note (*1): A stream is considered \"idle\" if it has not yet been"," | created or if the receiving part of the stream is in the \"Recv\""," | state without yet having received any frames."]},{"id":"section-3.5","title":"Solicited State Transitions","lines":[" If an application is no longer interested in the data it is receiving"," on a stream, it can abort reading the stream and specify an"," application error code.","",[[[],0," "],[[358,1743,2829],180,"If the stream is in the \"Recv\" or \"Size Known\" state, the transport"]],[[[],0," "],[[358,1743,2829],180,"SHOULD signal this by sending a STOP_SENDING frame to prompt closure"]],[[[],0," "],[[358,1743,2829],180,"of the stream in the opposite direction."],[[],0," This typically indicates"]]," that the receiving application is no longer reading data it receives"," from the stream, but it is not a guarantee that incoming data will be"," ignored.",""," STREAM frames received after sending a STOP_SENDING frame are still"," counted toward connection and stream flow control, even though these"," frames can be discarded upon receipt.",""," A STOP_SENDING frame requests that the receiving endpoint send a",[[[],0," RESET_STREAM frame. "],[[359,2455,2833],244,"An endpoint that receives a STOP_SENDING frame"]],[[[],0," "],[[359,2455,2833],244,"MUST send a RESET_STREAM frame if the stream is in the \"Ready\" or"]],[[[],0," "],[[359,2455,2833],244,"\"Send\" state."],[[],0," "],[[25,360],98,"If the stream is in the \"Data Sent\" state, the"]],[[[],0," "],[[25,360],98,"endpoint MAY defer sending the RESET_STREAM frame until the packets"]],[[[],0," "],[[25,360],98,"containing outstanding data are acknowledged or declared lost."],[[],0," "],[[361,2447,3086,3087],180,"If"]],[[[],0," "],[[361,2447,3086,3087],180,"any outstanding data is declared lost, the endpoint SHOULD send a"]],[[[],0," "],[[361,2447,3086,3087],180,"RESET_STREAM frame instead of retransmitting the data."]],"",[[[],0," "],[[362,2456,2834],180,"An endpoint SHOULD copy the error code from the STOP_SENDING frame to"]],[[[],0," "],[[362,2456,2834],180,"the RESET_STREAM frame it sends, but it can use any application error"]],[[[],0," "],[[362,2456,2834],180,"code."],[[],0," "],[[26,363],98,"An endpoint that sends a STOP_SENDING frame MAY ignore the"]],[[[],0," "],[[26,363],98,"error code in any RESET_STREAM frames subsequently received for that"]],[[[],0," "],[[26,363],98,"stream."]],"",[[[],0," "],[[364,2448,3094],180,"STOP_SENDING SHOULD only be sent for a stream that has not been reset"]],[[[],0," "],[[364,2448,3094],180,"by the peer."],[[],0," STOP_SENDING is most useful for streams in the \"Recv\""]]," or \"Size Known\" state.",""," An endpoint is expected to send another STOP_SENDING frame if a"," packet containing a previous STOP_SENDING is lost. However, once"," either all stream data or a RESET_STREAM frame has been received for"," the stream -- that is, the stream is in any state other than \"Recv\""," or \"Size Known\" -- sending a STOP_SENDING frame is unnecessary.",""," An endpoint that wishes to terminate both directions of a"," bidirectional stream can terminate one direction by sending a"," RESET_STREAM frame, and it can encourage prompt termination in the"," opposite direction by sending a STOP_SENDING frame."],"requirements":[358,359,360,361,362,363,364]},{"id":"section-4","title":"Flow Control","lines":[" Receivers need to limit the amount of data that they are required to"," buffer, in order to prevent a fast sender from overwhelming them or a"," malicious sender from consuming a large amount of memory. To enable"," a receiver to limit memory commitments for a connection, streams are"," flow controlled both individually and across a connection as a whole."," A QUIC receiver controls the maximum amount of data the sender can"," send on a stream as well as across all streams at any time, as"," described in Sections 4.1 and 4.2.",""," Similarly, to limit concurrency within a connection, a QUIC endpoint"," controls the maximum cumulative number of streams that its peer can"," initiate, as described in Section 4.6.",""," Data sent in CRYPTO frames is not flow controlled in the same way as"," stream data. QUIC relies on the cryptographic protocol"," implementation to avoid excessive buffering of data; see [QUIC-TLS].",[[[],0," "],[[383,2370],176,"To avoid excessive buffering at multiple layers, QUIC implementations"]],[[[],0," "],[[383,2370],176,"SHOULD provide an interface for the cryptographic protocol"]],[[[],0," "],[[383,2370],176,"implementation to communicate its buffering limits."]]],"requirements":[383]},{"id":"section-4.1","title":"Data Flow Control","lines":[" QUIC employs a limit-based flow control scheme where a receiver"," advertises the limit of total bytes it is prepared to receive on a"," given stream or for the entire connection. This leads to two levels"," of data flow control in QUIC:",""," * Stream flow control, which prevents a single stream from consuming"," the entire receive buffer for a connection by limiting the amount"," of data that can be sent on each stream.",""," * Connection flow control, which prevents senders from exceeding a"," receiver's buffer capacity for the connection by limiting the"," total bytes of stream data sent in STREAM frames on all streams.","",[[[],0," "],[[365,2144,2469,2642,2644],244,"Senders MUST NOT send data in excess of either limit."]],""," A receiver sets initial limits for all streams through transport"," parameters during the handshake (Section 7.4). Subsequently, a"," receiver sends MAX_STREAM_DATA frames (Section 19.10) or MAX_DATA"," frames (Section 19.9) to the sender to advertise larger limits.",""," A receiver can advertise a larger limit for a stream by sending a"," MAX_STREAM_DATA frame with the corresponding stream ID. A"," MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a"," stream. A receiver could determine the flow control offset to be"," advertised based on the current offset of data consumed on that"," stream.",""," A receiver can advertise a larger limit for a connection by sending a"," MAX_DATA frame, which indicates the maximum of the sum of the"," absolute byte offsets of all streams. A receiver maintains a"," cumulative sum of bytes received on all streams, which is used to"," check for violations of the advertised connection or stream data"," limits. A receiver could determine the maximum data limit to be"," advertised based on the sum of bytes consumed on all streams.",""," Once a receiver advertises a limit for the connection or a stream, it"," is not an error to advertise a smaller limit, but the smaller limit"," has no effect.","",[[[],0," "],[[366,1858,2671,2677],244,"A receiver MUST close the connection with an error of type"]],[[[],0," "],[[366,1858,2671,2677],244,"FLOW_CONTROL_ERROR if the sender violates the advertised connection"]],[[[],0," "],[[366,1858,2671,2677],244,"or stream data limits; see Section 11 for details on error handling."]],"",[[[],0," "],[[367,2460,2461,2647],244,"A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do"]],[[[],0," "],[[367,2460,2461,2647],244,"not increase flow control limits."]],""," If a sender has sent data up to the limit, it will be unable to send",[[[],0," new data and is considered blocked. "],[[368,2464,2645,2646],180,"A sender SHOULD send a"]],[[[],0," "],[[368,2464,2645,2646],180,"STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver"]],[[[],0," "],[[368,2464,2645,2646],180,"that it has data to write but is blocked by flow control limits."],[[],0," If"]]," a sender is blocked for a period longer than the idle timeout"," (Section 10.1), the receiver might close the connection even when the",[[[],0," sender has data that is available for transmission. "],[[369,2151,2152,2588,2589],180,"To keep the"]],[[[],0," "],[[369,2151,2152,2588,2589],180,"connection from closing, a sender that is flow control limited SHOULD"]],[[[],0," "],[[369,2151,2152,2588,2589],180,"periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it"]],[[[],0," "],[[369,2151,2152,2588,2589],180,"has no ack-eliciting packets in flight."]]],"requirements":[365,366,367,368,369]},{"id":"section-4.2","title":"Increasing Flow Control Limits","lines":[" Implementations decide when and how much credit to advertise in"," MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few"," considerations.","",[[[],0," "],[[370,2045,2046],112,"To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or"]],[[[],0," "],[[370,2045,2046],112,"MAX_DATA frame multiple times within a round trip or send it early"]],[[[],0," "],[[370,2045,2046],112,"enough to allow time for loss of the frame and subsequent recovery."]],""," Control frames contribute to connection overhead. Therefore,"," frequently sending MAX_STREAM_DATA and MAX_DATA frames with small"," changes is undesirable. On the other hand, if updates are less"," frequent, larger increments to limits are necessary to avoid blocking"," a sender, requiring larger resource commitments at the receiver."," There is a trade-off between resource commitment and overhead when"," determining how large a limit is advertised.",""," A receiver can use an autotuning mechanism to tune the frequency and"," amount of advertised additional credit based on a round-trip time"," estimate and the rate at which the receiving application consumes"," data, similar to common TCP implementations. As an optimization, an"," endpoint could send frames related to flow control only when there"," are other frames to send, ensuring that flow control does not cause"," extra packets to be sent.",""," A blocked sender is not required to send STREAM_DATA_BLOCKED or",[[[],0," DATA_BLOCKED frames. "],[[371,1831,1833,2651],244,"Therefore, a receiver MUST NOT wait for a"]],[[[],0," "],[[371,1831,1833,2651],244,"STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a"]],[[[],0," "],[[371,1831,1833,2651],244,"MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the"]],[[[],0," "],[[371,1831,1833,2651],244,"sender being blocked for the rest of the connection."],[[],0," Even if the"]]," sender sends these frames, waiting for them will result in the sender"," being blocked for at least an entire round trip.",""," When a sender receives credit after being blocked, it might be able"," to send a large amount of data in response, resulting in short-term"," congestion; see Section 7.7 of [QUIC-RECOVERY] for a discussion of"," how a sender can avoid this congestion."],"requirements":[370,371]},{"id":"section-4.3","title":"Flow Control Performance","lines":[" If an endpoint cannot ensure that its peer always has available flow"," control credit that is greater than the peer's bandwidth-delay"," product on this connection, its receive throughput will be limited by"," flow control.",""," Packet loss can cause gaps in the receive buffer, preventing the"," application from consuming data and freeing up receive buffer space.",""," Sending timely updates of flow control limits can improve"," performance. Sending packets only to provide flow control updates"," can increase network load and adversely affect performance. Sending"," flow control updates along with other frames, such as ACK frames,"," reduces the cost of those updates."]},{"id":"section-4.4","title":"Handling Stream Cancellation","lines":[" Endpoints need to eventually agree on the amount of flow control"," credit that has been consumed on every stream, to be able to account"," for all bytes for connection-level flow control.",""," On receipt of a RESET_STREAM frame, an endpoint will tear down state"," for the matching stream and ignore further data arriving on that"," stream.",""," RESET_STREAM terminates one direction of a stream abruptly. For a"," bidirectional stream, RESET_STREAM has no effect on data flow in the",[[[],0," opposite direction. "],[[372,2022,2023,2851,2852,2853,2854],244,"Both endpoints MUST maintain flow control state"]],[[[],0," "],[[372,2022,2023,2851,2852,2853,2854],244,"for the stream in the unterminated direction until that direction"]],[[[],0," "],[[372,2022,2023,2851,2852,2853,2854],244,"enters a terminal state."]]],"requirements":[372]},{"id":"section-4.5","title":"Stream Final Size","lines":[" The final size is the amount of flow control credit that is consumed"," by a stream. Assuming that every contiguous byte on the stream was"," sent once, the final size is the number of bytes sent. More"," generally, this is one higher than the offset of the byte with the"," largest offset sent on the stream, or zero if no bytes were sent.",""," A sender always communicates the final size of a stream to the"," receiver reliably, no matter how the stream is terminated. The final"," size is the sum of the Offset and Length fields of a STREAM frame"," with a FIN flag, noting that these fields might be implicit."," Alternatively, the Final Size field of a RESET_STREAM frame carries"," this value. This guarantees that both endpoints agree on how much"," flow control credit was consumed by the sender on that stream.",""," An endpoint will know the final size for a stream when the receiving"," part of the stream enters the \"Size Known\" or \"Reset Recvd\" state",[[[],0," (Section 3). "],[[373,2020,2649],244,"The receiver MUST use the final size of the stream to"]],[[[],0," "],[[373,2020,2649],244,"account for all bytes sent on the stream in its connection-level flow"]],[[[],0," "],[[373,2020,2649],244,"controller."]],"",[[[],0," "],[[374,2445,2839],244,"An endpoint MUST NOT send data on a stream at or beyond the final"]],[[[],0," "],[[374,2445,2839],244,"size."]],"",[[[],0," "],[[2450,2451,2855,2858],20,"Once a final size for a stream is known, it cannot change."],[[],0," "],[[375,1859,2856,2859,3082,3083],180,"If a"]],[[[],0," "],[[375,1859,2856,2859,3082,3083],180,"RESET_STREAM or STREAM frame is received indicating a change in the"]],[[[],0," "],[[375,1859,2856,2859,3082,3083],180,"final size for the stream, an endpoint SHOULD respond with an error"]],[[[],0," "],[[375,1859,2856,2859,3082,3083],180,"of type FINAL_SIZE_ERROR; see Section 11 for details on error"]],[[[],0," "],[[375,1859,2856,2859,3082,3083],180,"handling."],[[],0," "],[[376,2452,2453,2857],180,"A receiver SHOULD treat receipt of data at or beyond the"]],[[[],0," "],[[376,2452,2453,2857],180,"final size as an error of type FINAL_SIZE_ERROR, even after a stream"]],[[[],0," "],[[376,2452,2453,2857],180,"is closed."],[[],0," Generating these errors is not mandatory, because"]]," requiring that an endpoint generate these errors also means that the"," endpoint needs to maintain the final size state for closed streams,"," which could mean a significant state commitment."],"requirements":[373,374,375,376]},{"id":"section-4.6","title":"Controlling Concurrency","lines":[" An endpoint limits the cumulative number of incoming streams a peer"," can open. Only streams with a stream ID less than \"(max_streams * 4"," + first_stream_id_of_type)\" can be opened; see Table 1. Initial"," limits are set in the transport parameters; see Section 18.2."," Subsequent limits are advertised using MAX_STREAMS frames; see"," Section 19.11. Separate limits apply to unidirectional and"," bidirectional streams.",""," If a max_streams transport parameter or a MAX_STREAMS frame is"," received with a value greater than 2^60, this would allow a maximum"," stream ID that cannot be expressed as a variable-length integer; see",[[[],0," Section 16. "],[[377,1628,1637,2499,2973,2982,3030],244,"If either is received, the connection MUST be closed"]],[[[],0," "],[[377,1628,1637,2499,2973,2982,3030],244,"immediately with a connection error of type TRANSPORT_PARAMETER_ERROR"]],[[[],0," "],[[377,1628,1637,2499,2973,2982,3030],244,"if the offending value was received in a transport parameter or of"]],[[[],0," "],[[377,1628,1637,2499,2973,2982,3030],244,"type FRAME_ENCODING_ERROR if it was received in a frame; see"]],[[[],0," "],[[377,1628,1637,2499,2973,2982,3030],244,"Section 10.2."]],"",[[[],0," "],[[378,2439,2441,2442,3078],244,"Endpoints MUST NOT exceed the limit set by their peer."],[[],0," "],[[379,2035,2843],244,"An endpoint"]],[[[],0," "],[[379,2035,2843],244,"that receives a frame with a stream ID exceeding the limit it has"]],[[[],0," "],[[379,2035,2843],244,"sent MUST treat this as a connection error of type"]],[[[],0," "],[[379,2035,2843],244,"STREAM_LIMIT_ERROR; see Section 11 for details on error handling."]],""," Once a receiver advertises a stream limit using the MAX_STREAMS",[[[],0," frame, advertising a smaller limit has no effect. "],[[380,2443,2846],244,"MAX_STREAMS frames"]],[[[],0," "],[[380,2443,2846],244,"that do not increase the stream limit MUST be ignored."]],""," As with stream and connection flow control, this document leaves"," implementations to decide when and how many streams should be",[[[],0," advertised to a peer via MAX_STREAMS. "],[[2827],4,"Implementations might choose"]],[[[],0," "],[[2827],4,"to increase limits as streams are closed, to keep the number of"]],[[[],0," "],[[2827],4,"streams available to peers roughly consistent."]],"",[[[],0," "],[[381,2027,2840],180,"An endpoint that is unable to open a new stream due to the peer's"]],[[[],0," "],[[381,2027,2840],180,"limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14)."],[[],0," This"]],[[[],0," signal is considered useful for debugging. "],[[382,2047,2849,2850],244,"An endpoint MUST NOT wait"]],[[[],0," "],[[382,2047,2849,2850],244,"to receive this signal before advertising additional credit, since"]],[[[],0," "],[[382,2047,2849,2850],244,"doing so will mean that the peer will be blocked for at least an"]],[[[],0," "],[[382,2047,2849,2850],244,"entire round trip, and potentially indefinitely if the peer chooses"]],[[[],0," "],[[382,2047,2849,2850],244,"not to send STREAMS_BLOCKED frames."]]],"requirements":[377,378,379,380,381,382]},{"id":"section-5","title":"Connections","lines":[" A QUIC connection is shared state between a client and a server.",""," Each connection starts with a handshake phase, during which the two"," endpoints establish a shared secret using the cryptographic handshake"," protocol [QUIC-TLS] and negotiate the application protocol. The"," handshake (Section 7) confirms that both endpoints are willing to"," communicate (Section 8.1) and establishes parameters for the"," connection (Section 7.4).",""," An application protocol can use the connection during the handshake"," phase with some limitations. 0-RTT allows application data to be"," sent by a client before receiving a response from the server."," However, 0-RTT provides no protection against replay attacks; see"," Section 9.2 of [QUIC-TLS]. A server can also send application data"," to a client before it receives the final cryptographic handshake"," messages that allow it to confirm the identity and liveness of the"," client. These capabilities allow an application protocol to offer"," the option of trading some security guarantees for reduced latency.",""," The use of connection IDs (Section 5.1) allows connections to migrate"," to a new network path, both as a direct choice of an endpoint and"," when forced by a change in a middlebox. Section 9 describes"," mitigations for the security and privacy issues associated with"," migration.",""," For connections that are no longer needed or desired, there are"," several ways for a client and server to terminate a connection, as"," described in Section 10."]},{"id":"section-5.1","title":"Connection ID","lines":[" Each connection possesses a set of connection identifiers, or"," connection IDs, each of which can identify the connection."," Connection IDs are independently selected by endpoints; each endpoint"," selects the connection IDs that its peer uses.",""," The primary function of a connection ID is to ensure that changes in"," addressing at lower protocol layers (UDP, IP) do not cause packets"," for a QUIC connection to be delivered to the wrong endpoint. Each"," endpoint selects connection IDs using an implementation-specific (and"," perhaps deployment-specific) method that will allow packets with that"," connection ID to be routed back to the endpoint and to be identified"," by the endpoint upon receipt.",""," Multiple connection IDs are used so that endpoints can send packets"," that cannot be identified by an observer as being for the same"," connection without cooperation from an endpoint; see Section 9.5.","",[[[],0," "],[[403,1845],240,"Connection IDs MUST NOT contain any information that can be used by"]],[[[],0," "],[[403,1845],240,"an external observer (that is, one that does not cooperate with the"]],[[[],0," "],[[403,1845],240,"issuer) to correlate them with other connection IDs for the same"]],[[[],0," "],[[403,1845],240,"connection."],[[],0," "],[[404,1971,2608],244,"As a trivial example, this means the same connection ID"]],[[[],0," "],[[404,1971,2608],244,"MUST NOT be issued more than once on the same connection."]],""," Packets with long headers include Source Connection ID and"," Destination Connection ID fields. These fields are used to set the"," connection IDs for new connections; see Section 7.2 for details.",""," Packets with short headers (Section 17.3) only include the"," Destination Connection ID and omit the explicit length. The length"," of the Destination Connection ID field is expected to be known to"," endpoints. Endpoints using a load balancer that routes based on"," connection ID could agree with the load balancer on a fixed length"," for connection IDs or agree on an encoding scheme. A fixed portion"," could encode an explicit length, which allows the entire connection"," ID to vary in length and still be used by the load balancer.",""," A Version Negotiation (Section 17.2.1) packet echoes the connection"," IDs selected by the client, both to ensure correct routing toward the"," client and to demonstrate that the packet is in response to a packet"," sent by the client.",""," A zero-length connection ID can be used when a connection ID is not"," needed to route to the correct endpoint. However, multiplexing"," connections on the same local IP address and port while using zero-"," length connection IDs will cause failures in the presence of peer",[[[],0," connection migration, NAT rebinding, and client port reuse. "],[[405,2306],240,"An"]],[[[],0," "],[[405,2306],240,"endpoint MUST NOT use the same IP address and port for multiple"]],[[[],0," "],[[405,2306],240,"concurrent connections with zero-length connection IDs, unless it is"]],[[[],0," "],[[405,2306],240,"certain that those protocol features are not in use."]],""," When an endpoint uses a non-zero-length connection ID, it needs to"," ensure that the peer has a supply of connection IDs from which to"," choose for packets sent to the endpoint. These connection IDs are"," supplied by the endpoint using the NEW_CONNECTION_ID frame"," (Section 19.15)."],"requirements":[403,404,405]},{"id":"section-5.1.1","title":"Issuing Connection IDs","lines":[" Each connection ID has an associated sequence number to assist in"," detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer"," to the same value. The initial connection ID issued by an endpoint"," is sent in the Source Connection ID field of the long packet header"," (Section 17.2) during the handshake. The sequence number of the",[[[],0," initial connection ID is 0. "],[[2621,2628],4,"If the preferred_address transport"]],[[[],0," "],[[2621,2628],4,"parameter is sent, the sequence number of the supplied connection ID"]],[[[],0," "],[[2621,2628],4,"is 1."]],""," Additional connection IDs are communicated to the peer using",[[[],0," NEW_CONNECTION_ID frames (Section 19.15). "],[[384,1970,2623,2630],244,"The sequence number on"]],[[[],0," "],[[384,1970,2623,2630],244,"each newly issued connection ID MUST increase by 1."],[[],0," The connection"]]," ID that a client selects for the first Destination Connection ID"," field it sends and any connection ID provided by a Retry packet are"," not assigned sequence numbers.","",[[[],0," "],[[385,1746,2639],244,"When an endpoint issues a connection ID, it MUST accept packets that"]],[[[],0," "],[[385,1746,2639],244,"carry this connection ID for the duration of the connection or until"]],[[[],0," "],[[385,1746,2639],244,"its peer invalidates the connection ID via a RETIRE_CONNECTION_ID"]],[[[],0," "],[[385,1746,2639],244,"frame (Section 19.16)."],[[],0," Connection IDs that are issued and not"]]," retired are considered active; any active connection ID is valid for"," use with the current connection at any time, in any packet type."," This includes the connection ID issued by the server via the"," preferred_address transport parameter.","",[[[],0," "],[[386,1975,2611],180,"An endpoint SHOULD ensure that its peer has a sufficient number of"]],[[[],0," "],[[386,1975,2611],180,"available and unused connection IDs."],[[],0," Endpoints advertise the number"]]," of active connection IDs they are willing to maintain using the",[[[],0," active_connection_id_limit transport parameter. "],[[387,1977,1985,2612,2619],244,"An endpoint MUST NOT"]],[[[],0," "],[[387,1977,1985,2612,2619],244,"provide more connection IDs than the peer's limit."],[[],0," "],[[388,1982,2624],116,"An endpoint MAY"]],[[[],0," "],[[388,1982,2624],116,"send connection IDs that temporarily exceed a peer's limit if the"]],[[[],0," "],[[388,1982,2624],116,"NEW_CONNECTION_ID frame also requires the retirement of any excess,"]],[[[],0," "],[[388,1982,2624],116,"by including a sufficiently large value in the Retire Prior To field."]],""," A NEW_CONNECTION_ID frame might cause an endpoint to add some active"," connection IDs and retire others based on the value of the Retire",[[[],0," Prior To field. "],[[389,1957,1961,1983,2601],244,"After processing a NEW_CONNECTION_ID frame and"]],[[[],0," "],[[389,1957,1961,1983,2601],244,"adding and retiring active connection IDs, if the number of active"]],[[[],0," "],[[389,1957,1961,1983,2601],244,"connection IDs exceeds the value advertised in its"]],[[[],0," "],[[389,1957,1961,1983,2601],244,"active_connection_id_limit transport parameter, an endpoint MUST"]],[[[],0," "],[[389,1957,1961,1983,2601],244,"close the connection with an error of type CONNECTION_ID_LIMIT_ERROR."]],"",[[[],0," "],[[390,1968,2614],180,"An endpoint SHOULD supply a new connection ID when the peer retires a"]],[[[],0," "],[[390,1968,2614],180,"connection ID."],[[],0," "],[[391,1984,2617,2618],116,"If an endpoint provided fewer connection IDs than the"]],[[[],0," "],[[391,1984,2617,2618],116,"peer's active_connection_id_limit, it MAY supply a new connection ID"]],[[[],0," "],[[391,1984,2617,2618],116,"when it receives a packet with a previously unused connection ID."],[[],0," "],[[392,1978],112,"An"]],[[[],0," "],[[392,1978],112,"endpoint MAY limit the total number of connection IDs issued for each"]],[[[],0," "],[[392,1978],112,"connection to avoid the risk of running out of connection IDs; see"]],[[[],0," "],[[392,1978],112,"Section 10.3.2."],[[],0," "],[[393,1979],112,"An endpoint MAY also limit the issuance of"]],[[[],0," "],[[393,1979],112,"connection IDs to reduce the amount of per-path state it maintains,"]],[[[],0," "],[[393,1979],112,"such as path validation status, as its peer might interact with it"]],[[[],0," "],[[393,1979],112,"over as many paths as there are issued connection IDs."]],"",[[[],0," "],[[394,1725,2048,2733,2736],180,"An endpoint that initiates migration and requires non-zero-length"]],[[[],0," "],[[394,1725,2048,2733,2736],180,"connection IDs SHOULD ensure that the pool of connection IDs"]],[[[],0," "],[[394,1725,2048,2733,2736],180,"available to its peer allows the peer to use a new connection ID on"]],[[[],0," "],[[394,1725,2048,2733,2736],180,"migration, as the peer will be unable to respond if the pool is"]],[[[],0," "],[[394,1725,2048,2733,2736],180,"exhausted."]],"",[[[],0," "],[[2620,2629],4,"An endpoint that selects a zero-length connection ID during the"]],[[[],0," "],[[2620,2629],4,"handshake cannot issue a new connection ID."],[[],0," A zero-length"]]," Destination Connection ID field is used in all packets sent toward"," such an endpoint over any network path."],"requirements":[384,385,386,387,388,389,390,391,392,393,394]},{"id":"section-5.1.2","title":"Consuming and Retiring Connection IDs","lines":[" An endpoint can change the connection ID it uses for a peer to"," another available one at any time during the connection. An endpoint"," consumes connection IDs in response to a migrating peer; see"," Section 9.5 for more details.",""," An endpoint maintains a set of connection IDs received from its peer,"," any of which it can use when sending packets. When the endpoint"," wishes to remove a connection ID from use, it sends a"," RETIRE_CONNECTION_ID frame to its peer. Sending a"," RETIRE_CONNECTION_ID frame indicates that the connection ID will not"," be used again and requests that the peer replace it with a new"," connection ID using a NEW_CONNECTION_ID frame.",""," As discussed in Section 9.5, endpoints limit the use of a connection"," ID to packets sent from a single local address to a single",[[[],0," destination address. "],[[395,2050,2738],180,"Endpoints SHOULD retire connection IDs when"]],[[[],0," "],[[395,2050,2738],180,"they are no longer actively using either the local or destination"]],[[[],0," "],[[395,2050,2738],180,"address for which the connection ID was used."]],"",[[[],0," "],[[1973],16,"An endpoint might need to stop accepting previously issued connection"]],[[[],0," "],[[1973],16,"IDs in certain circumstances. Such an endpoint can cause its peer to"]],[[[],0," "],[[1973],16,"retire connection IDs by sending a NEW_CONNECTION_ID frame with an"]],[[[],0," "],[[1973],16,"increased Retire Prior To field."],[[],0," "],[[396,1747,1974,2625,2640],180,"The endpoint SHOULD continue to"]],[[[],0," "],[[396,1747,1974,2625,2640],180,"accept the previously issued connection IDs until they are retired by"]],[[[],0," "],[[396,1747,1974,2625,2640],180,"the peer."],[[],0," "],[[397,1956,1960],112,"If the endpoint can no longer process the indicated"]],[[[],0," "],[[397,1956,1960],112,"connection IDs, it MAY close the connection."]],"",[[[],0," "],[[398,1954,2591,2593],244,"Upon receipt of an increased Retire Prior To field, the peer MUST"]],[[[],0," "],[[398,1954,2591,2593],244,"stop using the corresponding connection IDs and retire them with"]],[[[],0," "],[[398,1954,2591,2593],244,"RETIRE_CONNECTION_ID frames before adding the newly provided"]],[[[],0," "],[[398,1954,2591,2593],244,"connection ID to the set of active connection IDs."],[[],0," This ordering"]]," allows an endpoint to replace all active connection IDs without the"," possibility of a peer having no available connection IDs and without"," exceeding the limit the peer sets in the active_connection_id_limit"," transport parameter; see Section 18.2. Failure to cease using the"," connection IDs when requested can result in connection failures, as"," the issuing endpoint might be unable to continue using the connection"," IDs with the active connection.","",[[[],0," "],[[399,1964,2598],180,"An endpoint SHOULD limit the number of connection IDs it has retired"]],[[[],0," "],[[399,1964,2598],180,"locally for which RETIRE_CONNECTION_ID frames have not yet been"]],[[[],0," "],[[399,1964,2598],180,"acknowledged."],[[],0," "],[[400,1803,1965,2133,2597],180,"An endpoint SHOULD allow for sending and tracking a"]],[[[],0," "],[[400,1803,1965,2133,2597],180,"number of RETIRE_CONNECTION_ID frames of at least twice the value of"]],[[[],0," "],[[400,1803,1965,2133,2597],180,"the active_connection_id_limit transport parameter."],[[],0," "],[[401,1804,1962,2594,2595,2596],244,"An endpoint MUST"]],[[[],0," "],[[401,1804,1962,2594,2595,2596],244,"NOT forget a connection ID without retiring it, though it MAY choose"]],[[[],0," "],[[401,1804,1962,2594,2595,2596],244,"to treat having connection IDs in need of retirement that exceed this"]],[[[],0," "],[[401,1804,1962,2594,2595,2596],244,"limit as a connection error of type CONNECTION_ID_LIMIT_ERROR."]],"",[[[],0," "],[[402,1980,1981,2609,2615,2616,2627,2631],180,"Endpoints SHOULD NOT issue updates of the Retire Prior To field"]],[[[],0," "],[[402,1980,1981,2609,2615,2616,2627,2631],180,"before receiving RETIRE_CONNECTION_ID frames that retire all"]],[[[],0," "],[[402,1980,1981,2609,2615,2616,2627,2631],180,"connection IDs indicated by the previous Retire Prior To value."]]],"requirements":[395,396,397,398,399,400,401,402]},{"id":"section-5.2","title":"Matching Packets to Connections","lines":[" Incoming packets are classified on receipt. Packets can either be"," associated with an existing connection or -- for servers --"," potentially create a new connection.",""," Endpoints try to associate a packet with an existing connection. If"," the packet has a non-zero-length Destination Connection ID"," corresponding to an existing connection, QUIC processes that packet"," accordingly. Note that more than one connection ID can be associated"," with a connection; see Section 5.1.",""," If the Destination Connection ID is zero length and the addressing"," information in the packet matches the addressing information the"," endpoint uses to identify a connection with a zero-length connection"," ID, QUIC processes the packet as part of that connection. An"," endpoint can use just destination IP and port or both source and"," destination addresses for identification, though this makes"," connections fragile as described in Section 5.1.",""," Endpoints can send a Stateless Reset (Section 10.3) for any packets"," that cannot be attributed to an existing connection. A Stateless"," Reset allows a peer to more quickly identify when a connection"," becomes unusable.",""," Packets that are matched to an existing connection are discarded if"," the packets are inconsistent with the state of that connection. For"," example, packets are discarded if they indicate a different protocol"," version than that of the connection or if the removal of packet"," protection is unsuccessful once the expected keys are available.","",[[[],0," "],[[418,1707],112,"Invalid packets that lack strong integrity protection, such as"]],[[[],0," "],[[418,1707],112,"Initial, Retry, or Version Negotiation, MAY be discarded."],[[],0," "],[[419,1708,2810,2811],244,"An"]],[[[],0," "],[[419,1708,2810,2811],244,"endpoint MUST generate a connection error if processing the contents"]],[[[],0," "],[[419,1708,2810,2811],244,"of these packets prior to discovering an error, or fully revert any"]],[[[],0," "],[[419,1708,2810,2811],244,"changes made during that processing."]]],"requirements":[418,419]},{"id":"section-5.2.1","title":"Client Packet Handling","lines":[" Valid packets sent to clients always include a Destination Connection"," ID that matches a value the client selects. Clients that choose to"," receive zero-length connection IDs can use the local address and port"," to identify a connection. Packets that do not match an existing"," connection -- based on Destination Connection ID or, if this value is"," zero length, local IP address and port -- are discarded.",""," Due to packet reordering or loss, a client might receive packets for"," a connection that are encrypted with a key it has not yet computed.",[[[],0," "],[[406,1704],112,"The client MAY drop these packets, or it MAY buffer them in"]],[[[],0," "],[[406,1704],112,"anticipation of later packets that allow it to compute the key."]],"",[[[],0," "],[[407,1889],240,"If a client receives a packet that uses a different version than it"]],[[[],0," "],[[407,1889],240,"initially selected, it MUST discard that packet."]]],"requirements":[406,407]},{"id":"section-5.2.2","title":"Server Packet Handling","lines":[[[[],0," "],[[408,2320,2902],180,"If a server receives a packet that indicates an unsupported version"]],[[[],0," "],[[408,2320,2902],180,"and if the packet is large enough to initiate a new connection for"]],[[[],0," "],[[408,2320,2902],180,"any supported version, the server SHOULD send a Version Negotiation"]],[[[],0," "],[[408,2320,2902],180,"packet as described in Section 6.1."],[[],0," "],[[409,2318],112,"A server MAY limit the number of"]],[[[],0," "],[[409,2318],112,"packets to which it responds with a Version Negotiation packet."]],[[[],0," "],[[410,2322,2885,2899],244,"Servers MUST drop smaller packets that specify unsupported versions."]],""," The first packet for an unsupported version can use different"," semantics and encodings for any version-specific field. In"," particular, different packet protection keys might be used for"," different versions. Servers that do not support a particular version"," are unlikely to be able to decrypt the payload of the packet or",[[[],0," properly interpret the result. "],[[411,2321,2903],180,"Servers SHOULD respond with a Version"]],[[[],0," "],[[411,2321,2903],180,"Negotiation packet, provided that the datagram is sufficiently long."]],""," Packets with a supported version, or no Version field, are matched to"," a connection using the connection ID or -- for packets with zero-"," length connection IDs -- the local address and port. These packets"," are processed using the selected connection; otherwise, the server"," continues as described below.",""," If the packet is an Initial packet fully conforming with the"," specification, the server proceeds with the handshake (Section 7)."," This commits the server to the version that the client selected.","",[[[],0," "],[[412,2329,2894],180,"If a server refuses to accept a new connection, it SHOULD send an"]],[[[],0," "],[[412,2329,2894],180,"Initial packet containing a CONNECTION_CLOSE frame with error code"]],[[[],0," "],[[412,2329,2894],180,"CONNECTION_REFUSED."]],"",[[[],0," "],[[413,2299,2960],116,"If the packet is a 0-RTT packet, the server MAY buffer a limited"]],[[[],0," "],[[413,2299,2960],116,"number of these packets in anticipation of a late-arriving Initial"]],[[[],0," "],[[413,2299,2960],116,"packet."],[[],0," "],[[414,2324,2896],180,"Clients are not able to send Handshake packets prior to"]],[[[],0," "],[[414,2324,2896],180,"receiving a server response, so servers SHOULD ignore any such"]],[[[],0," "],[[414,2324,2896],180,"packets."]],"",[[[],0," "],[[415,2325,2897],244,"Servers MUST drop incoming packets under all other circumstances."]]],"requirements":[408,409,410,411,412,413,414,415]},{"id":"section-5.2.3","title":"Considerations for Simple Load Balancers","lines":[" A server deployment could load-balance among servers using only"," source and destination IP addresses and ports. Changes to the"," client's IP address or port could result in packets being forwarded"," to the wrong server. Such a server deployment could use one of the"," following methods for connection continuity when a client's address"," changes.",""," * Servers could use an out-of-band mechanism to forward packets to"," the correct server based on connection ID.",""," * If servers can use a dedicated server IP address or port, other"," than the one that the client initially connects to, they could use"," the preferred_address transport parameter to request that clients"," move connections to that dedicated address. Note that clients"," could choose not to use the preferred address.","",[[[],0," "],[[40,416],162,"A server in a deployment that does not implement a solution to"]],[[[],0," "],[[40,416],162,"maintain connection continuity when the client address changes SHOULD"]],[[[],0," "],[[40,416],162,"indicate that migration is not supported by using the"]],[[[],0," "],[[40,416],162,"disable_active_migration transport parameter."],[[],0," The"]]," disable_active_migration transport parameter does not prohibit"," connection migration after a client has acted on a preferred_address"," transport parameter.","",[[[],0," "],[[41,417],226,"Server deployments that use this simple form of load balancing MUST"]],[[[],0," "],[[41,417],226,"avoid the creation of a stateless reset oracle; see Section 21.11."]]],"requirements":[416,417]},{"id":"section-5.3","title":"Operations on Connections","lines":[" This document does not define an API for QUIC; it instead defines a"," set of functions for QUIC connections that application protocols can"," rely upon. An application protocol can assume that an implementation"," of QUIC provides an interface that includes the operations described"," in this section. An implementation designed for use with a specific"," application protocol might provide only those operations that are"," used by that protocol.",""," When implementing the client role, an application protocol can:",""," * open a connection, which begins the exchange described in"," Section 7;",""," * enable Early Data when available; and",""," * be informed when Early Data has been accepted or rejected by a"," server.",""," When implementing the server role, an application protocol can:",""," * listen for incoming connections, which prepares for the exchange"," described in Section 7;",""," * if Early Data is supported, embed application-controlled data in"," the TLS resumption ticket sent to the client; and",""," * if Early Data is supported, retrieve application-controlled data"," from the client's resumption ticket and accept or reject Early"," Data based on that information.",""," In either role, an application protocol can:",""," * configure minimum values for the initial number of permitted"," streams of each type, as communicated in the transport parameters"," (Section 7.4);",""," * control resource allocation for receive buffers by setting flow"," control limits both for streams and for the connection;",""," * identify whether the handshake has completed successfully or is"," still ongoing;",""," * keep a connection from silently closing, by either generating PING"," frames (Section 19.2) or requesting that the transport send"," additional frames before the idle timeout expires (Section 10.1);"," and",""," * immediately close (Section 10.2) the connection."]},{"id":"section-6","title":"Version Negotiation","lines":[" Version negotiation allows a server to indicate that it does not"," support the version the client used. A server sends a Version"," Negotiation packet in response to each packet that might initiate a"," new connection; see Section 5.2 for details.",""," The size of the first packet sent by a client will determine whether",[[[],0," a server sends a Version Negotiation packet. "],[[427,2094],176,"Clients that support"]],[[[],0," "],[[427,2094],176,"multiple QUIC versions SHOULD ensure that the first UDP datagram they"]],[[[],0," "],[[427,2094],176,"send is sized to the largest of the minimum datagram sizes from all"]],[[[],0," "],[[427,2094],176,"versions they support, using PADDING frames (Section 19.1) as"]],[[[],0," "],[[427,2094],176,"necessary."],[[],0," This ensures that the server responds if there is a"]]," mutually supported version. A server might not send a Version"," Negotiation packet if the datagram it receives is smaller than the"," minimum size specified in a different version; see Section 14.1."],"requirements":[427]},{"id":"section-6.1","title":"Sending Version Negotiation Packets","lines":[" If the version selected by the client is not acceptable to the"," server, the server responds with a Version Negotiation packet; see"," Section 17.2.1. This includes a list of versions that the server",[[[],0," will accept. "],[[420,2220,2880],244,"An endpoint MUST NOT send a Version Negotiation packet"]],[[[],0," "],[[420,2220,2880],244,"in response to receiving a Version Negotiation packet."]],""," This system allows a server to process packets with unsupported"," versions without retaining state. Though either the Initial packet"," or the Version Negotiation packet that is sent in response could be"," lost, the client will send new packets until it successfully receives"," a response or it abandons the connection attempt.","",[[[],0," "],[[421,2319],112,"A server MAY limit the number of Version Negotiation packets it"]],[[[],0," "],[[421,2319],112,"sends."],[[],0," For instance, a server that is able to recognize packets as"]]," 0-RTT might choose not to send Version Negotiation packets in"," response to 0-RTT packets with the expectation that it will"," eventually receive an Initial packet."],"requirements":[420,421]},{"id":"section-6.2","title":"Handling Version Negotiation Packets","lines":[" Version Negotiation packets are designed to allow for functionality"," to be defined in the future that allows QUIC to negotiate the version"," of QUIC to use for a connection. Future Standards Track"," specifications might change how implementations that support multiple"," versions of QUIC react to Version Negotiation packets received in"," response to an attempt to establish a connection using this version.","",[[[],0," "],[[422,2341,2792,2795],244,"A client that supports only this version of QUIC MUST abandon the"]],[[[],0," "],[[422,2341,2792,2795],244,"current connection attempt if it receives a Version Negotiation"]],[[[],0," "],[[422,2341,2792,2795],244,"packet, with the following two exceptions."],[[],0," "],[[423,2268,2339,2794,2889],244,"A client MUST discard any"]],[[[],0," "],[[423,2268,2339,2794,2889],244,"Version Negotiation packet if it has received and successfully"]],[[[],0," "],[[423,2268,2339,2794,2889],244,"processed any other packet, including an earlier Version Negotiation"]],[[[],0," "],[[423,2268,2339,2794,2889],244,"packet."],[[],0," "],[[424,2270,2340,2793],244,"A client MUST discard a Version Negotiation packet that"]],[[[],0," "],[[424,2270,2340,2793],244,"lists the QUIC version selected by the client."]],""," How to perform version negotiation is left as future work defined by"," future Standards Track specifications. In particular, that future"," work will ensure robustness against version downgrade attacks; see"," Section 21.12."],"requirements":[422,423,424]},{"id":"section-6.3","title":"Using Reserved Versions","lines":[" For a server to use a new version in the future, clients need to"," correctly handle unsupported versions. Some version numbers"," (0x?a?a?a?a, as defined in Section 15) are reserved for inclusion in"," fields that contain version numbers.","",[[[],0," "],[[425,2292],112,"Endpoints MAY add reserved versions to any field where unknown or"]],[[[],0," "],[[425,2292],112,"unsupported versions are ignored to test that a peer correctly"]],[[[],0," "],[[425,2292],112,"ignores the value."],[[],0," For instance, an endpoint could include a"]]," reserved version in a Version Negotiation packet; see Section 17.2.1.",[[[],0," "],[[426,2310,2884],116,"Endpoints MAY send packets with a reserved version to test that a"]],[[[],0," "],[[426,2310,2884],116,"peer correctly discards the packet."]]],"requirements":[425,426]},{"id":"section-7","title":"Cryptographic and Transport Handshake","lines":[" QUIC relies on a combined cryptographic and transport handshake to"," minimize connection establishment latency. QUIC uses the CRYPTO"," frame (Section 19.6) to transmit the cryptographic handshake. The"," version of QUIC defined in this document is identified as 0x00000001"," and uses TLS as described in [QUIC-TLS]; a different QUIC version"," could indicate that a different cryptographic handshake protocol is"," in use.",""," QUIC provides reliable, ordered delivery of the cryptographic"," handshake data. QUIC packet protection is used to encrypt as much of",[[[],0," the handshake protocol as possible. "],[[458,2200,2203,2692,2693],244,"The cryptographic handshake MUST"]],[[[],0," "],[[458,2200,2203,2692,2693],244,"provide the following properties:"]],""," * authenticated key exchange, where",""," - a server is always authenticated,",""," - a client is optionally authenticated,",""," - every connection produces distinct and unrelated keys, and",""," - keying material is usable for packet protection for both 0-RTT"," and 1-RTT packets.",""," * authenticated exchange of values for transport parameters of both"," endpoints, and confidentiality protection for server transport"," parameters (see Section 7.4).",""," * authenticated negotiation of an application protocol (TLS uses"," Application-Layer Protocol Negotiation (ALPN) [ALPN] for this"," purpose).",""," The CRYPTO frame can be sent in different packet number spaces"," (Section 12.3). The offsets used by CRYPTO frames to ensure ordered"," delivery of cryptographic handshake data start from zero in each"," packet number space.",""," Figure 4 shows a simplified handshake and the exchange of packets and"," frames that are used to advance the handshake. Exchange of"," application data during the handshake is enabled where possible,"," shown with an asterisk (\"*\"). Once the handshake is complete,"," endpoints are able to exchange application data freely.",""," Client Server",""," Initial (CRYPTO)"," 0-RTT (*) ---------->"," Initial (CRYPTO)"," Handshake (CRYPTO)"," <---------- 1-RTT (*)"," Handshake (CRYPTO)"," 1-RTT (*) ---------->"," <---------- 1-RTT (HANDSHAKE_DONE)",""," 1-RTT <=========> 1-RTT",""," Figure 4: Simplified QUIC Handshake",""," Endpoints can use packets sent during the handshake to test for"," Explicit Congestion Notification (ECN) support; see Section 13.4. An"," endpoint validates support for ECN by observing whether the ACK"," frames acknowledging the first packets it sends carry ECN counts, as"," described in Section 13.4.2.","",[[[],0," "],[[459,2376,2377,2378,2387,2390,2396,3145,3146,3147,3148],244,"Endpoints MUST explicitly negotiate an application protocol."],[[],0," This"]]," avoids situations where there is a disagreement about the protocol"," that is in use."],"requirements":[458,459]},{"id":"section-7.1","title":"Example Handshake Flows","lines":[" Details of how TLS is integrated with QUIC are provided in"," [QUIC-TLS], but some examples are provided here. An extension of"," this exchange to support client address validation is shown in"," Section 8.1.2.",""," Once any address validation exchanges are complete, the cryptographic"," handshake is used to agree on cryptographic keys. The cryptographic"," handshake is carried in Initial (Section 17.2.2) and Handshake"," (Section 17.2.4) packets.",""," Figure 5 provides an overview of the 1-RTT handshake. Each line"," shows a QUIC packet with the packet type and packet number shown"," first, followed by the frames that are typically contained in those"," packets. For instance, the first packet is of type Initial, with"," packet number 0, and contains a CRYPTO frame carrying the"," ClientHello.",""," Multiple QUIC packets -- even of different packet types -- can be"," coalesced into a single UDP datagram; see Section 12.2. As a result,"," this handshake could consist of as few as four UDP datagrams, or any"," number more (subject to limits inherent to the protocol, such as"," congestion control and anti-amplification). For instance, the"," server's first flight contains Initial packets, Handshake packets,"," and \"0.5-RTT data\" in 1-RTT packets.",""," Client Server",""," Initial[0]: CRYPTO[CH] ->",""," Initial[0]: CRYPTO[SH] ACK[0]"," Handshake[0]: CRYPTO[EE, CERT, CV, FIN]"," <- 1-RTT[0]: STREAM[1, \"...\"]",""," Initial[1]: ACK[0]"," Handshake[0]: CRYPTO[FIN], ACK[0]"," 1-RTT[0]: STREAM[0, \"...\"], ACK[0] ->",""," Handshake[1]: ACK[0]"," <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, \"...\"], ACK[0]",""," Figure 5: Example 1-RTT Handshake",""," Figure 6 shows an example of a connection with a 0-RTT handshake and"," a single packet of 0-RTT data. Note that as described in"," Section 12.3, the server acknowledges 0-RTT data in 1-RTT packets,"," and the client sends 1-RTT packets in the same packet number space.",""," Client Server",""," Initial[0]: CRYPTO[CH]"," 0-RTT[0]: STREAM[0, \"...\"] ->",""," Initial[0]: CRYPTO[SH] ACK[0]"," Handshake[0] CRYPTO[EE, FIN]"," <- 1-RTT[0]: STREAM[1, \"...\"] ACK[0]",""," Initial[1]: ACK[0]"," Handshake[0]: CRYPTO[FIN], ACK[0]"," 1-RTT[1]: STREAM[0, \"...\"] ACK[0] ->",""," Handshake[1]: ACK[0]"," <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, \"...\"], ACK[1]",""," Figure 6: Example 0-RTT Handshake"]},{"id":"section-7.2","title":"Negotiating Connection IDs","lines":[" A connection ID is used to ensure consistent routing of packets, as"," described in Section 5.1. The long header contains two connection"," IDs: the Destination Connection ID is chosen by the recipient of the"," packet and is used to provide consistent routing; the Source"," Connection ID is used to set the Destination Connection ID used by"," the peer.",""," During the handshake, packets with the long header (Section 17.2) are"," used to establish the connection IDs used by both endpoints. Each"," endpoint uses the Source Connection ID field to specify the"," connection ID that is used in the Destination Connection ID field of"," packets being sent to them. After processing the first Initial"," packet, each endpoint sets the Destination Connection ID field in"," subsequent packets it sends to the value of the Source Connection ID"," field that it received.",""," When an Initial packet is sent by a client that has not previously"," received an Initial or Retry packet from the server, the client"," populates the Destination Connection ID field with an unpredictable",[[[],0," value. "],[[428,2326,2901],244,"This Destination Connection ID MUST be at least 8 bytes in"]],[[[],0," "],[[428,2326,2901],244,"length."],[[],0," "],[[429,1991,2634],244,"Until a packet is received from the server, the client MUST"]],[[[],0," "],[[429,1991,2634],244,"use the same Destination Connection ID value on all packets in this"]],[[[],0," "],[[429,1991,2634],244,"connection."]],"",[[[],0," "],[[2239],16,"The Destination Connection ID field from the first Initial packet"]],[[[],0," "],[[2239],16,"sent by a client is used to determine packet protection keys for"]],[[[],0," "],[[2239],16,"Initial packets."],[[],0," These keys change after receiving a Retry packet;"]]," see Section 5.2 of [QUIC-TLS].",""," The client populates the Source Connection ID field with a value of"," its choosing and sets the Source Connection ID Length field to"," indicate the length.",""," 0-RTT packets in the first flight use the same Destination Connection"," ID and Source Connection ID values as the client's first Initial"," packet.",""," Upon first receiving an Initial or Retry packet from the server, the"," client uses the Source Connection ID supplied by the server as the"," Destination Connection ID for subsequent packets, including any 0-RTT"," packets. This means that a client might have to change the"," connection ID it sets in the Destination Connection ID field twice"," during connection establishment: once in response to a Retry packet",[[[],0," and once in response to an Initial packet from the server. "],[[430,1752,1758,1768,1770,2637,2686,2688],244,"Once a"]],[[[],0," "],[[430,1752,1758,1768,1770,2637,2686,2688],244,"client has received a valid Initial packet from the server, it MUST"]],[[[],0," "],[[430,1752,1758,1768,1770,2637,2686,2688],244,"discard any subsequent packet it receives on that connection with a"]],[[[],0," "],[[430,1752,1758,1768,1770,2637,2686,2688],244,"different Source Connection ID."]],"",[[[],0," "],[[431,1988,1990,2635],244,"A client MUST change the Destination Connection ID it uses for"]],[[[],0," "],[[431,1988,1990,2635],244,"sending packets in response to only the first received Initial or"]],[[[],0," "],[[431,1988,1990,2635],244,"Retry packet."],[[],0," "],[[432,1754,1987,1989,2636,2664],244,"A server MUST set the Destination Connection ID it"]],[[[],0," "],[[432,1754,1987,1989,2636,2664],244,"uses for sending packets based on the first received Initial packet."]],[[[],0," "],[[433,1753,1769],240,"Any further changes to the Destination Connection ID are only"]],[[[],0," "],[[433,1753,1769],240,"permitted if the values are taken from NEW_CONNECTION_ID frames; "],[[433,1753,1769,2638,2687],244,"if"]],[[[],0," "],[[433,1753,1769,2638,2687],244,"subsequent Initial packets include a different Source Connection ID,"]],[[[],0," "],[[433,1753,1769,2638,2687],244,"they MUST be discarded."],[[],0," This avoids unpredictable outcomes that"]]," might otherwise result from stateless processing of multiple Initial"," packets with different Source Connection IDs.",""," The Destination Connection ID that an endpoint sends can change over"," the lifetime of a connection, especially in response to connection"," migration (Section 9); see Section 5.1.1 for details."],"requirements":[428,429,430,431,432,433]},{"id":"section-7.3","title":"Authenticating Connection IDs","lines":[" The choice each endpoint makes about connection IDs during the"," handshake is authenticated by including all values in transport"," parameters; see Section 7.4. This ensures that all connection IDs"," used for the handshake are also authenticated by the cryptographic"," handshake.",""," Each endpoint includes the value of the Source Connection ID field"," from the first Initial packet it sent in the"," initial_source_connection_id transport parameter; see Section 18.2."," A server includes the Destination Connection ID field from the first"," Initial packet it received from the client in the"," original_destination_connection_id transport parameter; if the server"," sent a Retry packet, this refers to the first Initial packet received"," before sending the Retry packet. If it sends a Retry packet, a"," server also includes the Source Connection ID field from the Retry"," packet in the retry_source_connection_id transport parameter.","",[[[],0," "],[[434,2490,2510,3032,3052],244,"The values provided by a peer for these transport parameters MUST"]],[[[],0," "],[[434,2490,2510,3032,3052],244,"match the values that an endpoint used in the Destination and Source"]],[[[],0," "],[[434,2490,2510,3032,3052],244,"Connection ID fields of Initial packets that it sent (and received,"]],[[[],0," "],[[434,2490,2510,3032,3052],244,"for servers)."],[[],0," "],[[435,2491,2511,3054],244,"Endpoints MUST validate that received transport"]],[[[],0," "],[[435,2491,2511,3054],244,"parameters match received connection ID values."],[[],0," Including connection"]]," ID values in transport parameters and verifying them ensures that an"," attacker cannot influence the choice of connection ID for a"," successful connection by injecting packets carrying attacker-chosen"," connection IDs during the handshake.","",[[[],0," "],[[436,2489,2509,3031,3051],244,"An endpoint MUST treat the absence of the"]],[[[],0," "],[[436,2489,2509,3031,3051],244,"initial_source_connection_id transport parameter from either endpoint"]],[[[],0," "],[[436,2489,2509,3031,3051],244,"or the absence of the original_destination_connection_id transport"]],[[[],0," "],[[436,2489,2509,3031,3051],244,"parameter from the server as a connection error of type"]],[[[],0," "],[[436,2489,2509,3031,3051],244,"TRANSPORT_PARAMETER_ERROR."]],"",[[[],0," "],[[437,2512,2513,3053,3055,3056],244,"An endpoint MUST treat the following as a connection error of type"]],[[[],0," "],[[437,2512,2513,3053,3055,3056],244,"TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:"]],""," * absence of the retry_source_connection_id transport parameter from"," the server after receiving a Retry packet,",""," * presence of the retry_source_connection_id transport parameter"," when no Retry packet was received, or",""," * a mismatch between values received from a peer in these transport"," parameters and the value sent in the corresponding Destination or"," Source Connection ID fields of Initial packets.",""," If a zero-length connection ID is selected, the corresponding"," transport parameter is included with a zero-length value.",""," Figure 7 shows the connection IDs (with DCID=Destination Connection"," ID, SCID=Source Connection ID) that are used in a complete handshake."," The exchange of Initial packets is shown, plus the later exchange of"," 1-RTT packets that includes the connection ID established during the"," handshake.",""," Client Server",""," Initial: DCID=S1, SCID=C1 ->"," <- Initial: DCID=C1, SCID=S3"," ..."," 1-RTT: DCID=S3 ->"," <- 1-RTT: DCID=C1",""," Figure 7: Use of Connection IDs in a Handshake",""," Figure 8 shows a similar handshake that includes a Retry packet.",""," Client Server",""," Initial: DCID=S1, SCID=C1 ->"," <- Retry: DCID=C1, SCID=S2"," Initial: DCID=S2, SCID=C1 ->"," <- Initial: DCID=C1, SCID=S3"," ..."," 1-RTT: DCID=S3 ->"," <- 1-RTT: DCID=C1",""," Figure 8: Use of Connection IDs in a Handshake with Retry",""," In both cases (Figures 7 and 8), the client sets the value of the"," initial_source_connection_id transport parameter to \"C1\".",""," When the handshake does not include a Retry (Figure 7), the server"," sets original_destination_connection_id to \"S1\" (note that this value"," is chosen by the client) and initial_source_connection_id to \"S3\"."," In this case, the server does not include a"," retry_source_connection_id transport parameter.",""," When the handshake includes a Retry (Figure 8), the server sets"," original_destination_connection_id to \"S1\","," retry_source_connection_id to \"S2\", and initial_source_connection_id"," to \"S3\"."],"requirements":[434,435,436,437]},{"id":"section-7.4","title":"Transport Parameters","lines":[" During connection establishment, both endpoints make authenticated"," declarations of their transport parameters. Endpoints are required"," to comply with the restrictions that each parameter defines; the"," description of each parameter includes rules for its handling.",""," Transport parameters are declarations that are made unilaterally by"," each endpoint. Each endpoint can choose values for transport"," parameters independent of the values chosen by its peer.",""," The encoding of the transport parameters is detailed in Section 18.",""," QUIC includes the encoded transport parameters in the cryptographic"," handshake. Once the handshake completes, the transport parameters"," declared by the peer are available. Each endpoint validates the"," values provided by its peer.",""," Definitions for each of the defined transport parameters are included"," in Section 18.2.","",[[[],0," "],[[450,2492,2496,2497,3021,3022,3033],244,"An endpoint MUST treat receipt of a transport parameter with an"]],[[[],0," "],[[450,2492,2496,2497,3021,3022,3033],244,"invalid value as a connection error of type"]],[[[],0," "],[[450,2492,2496,2497,3021,3022,3033],244,"TRANSPORT_PARAMETER_ERROR."]],"",[[[],0," "],[[451,2475,3020],244,"An endpoint MUST NOT send a parameter more than once in a given"]],[[[],0," "],[[451,2475,3020],244,"transport parameters extension."],[[],0," "],[[452,2478,3025,3026],180,"An endpoint SHOULD treat receipt of"]],[[[],0," "],[[452,2478,3025,3026],180,"duplicate transport parameters as a connection error of type"]],[[[],0," "],[[452,2478,3025,3026],180,"TRANSPORT_PARAMETER_ERROR."]],""," Endpoints use transport parameters to authenticate the negotiation of"," connection IDs during the handshake; see Section 7.3.",""," ALPN (see [ALPN]) allows clients to offer multiple application"," protocols during connection establishment. The transport parameters"," that a client includes during the handshake apply to all application"," protocols that the client offers. Application protocols can"," recommend values for transport parameters, such as the initial flow"," control limits. However, application protocols that set constraints"," on values for transport parameters could make it impossible for a"," client to offer multiple application protocols if these constraints"," conflict."],"requirements":[450,451,452]},{"id":"section-7.4.1","title":"Values of Transport Parameters for 0-RTT","lines":[" Using 0-RTT depends on both client and server using protocol"," parameters that were negotiated from a previous connection. To"," enable 0-RTT, endpoints store the values of the server transport"," parameters with any session tickets it receives on the connection."," Endpoints also store any information required by the application"," protocol or cryptographic handshake; see Section 4.6 of [QUIC-TLS]."," The values of stored transport parameters are used when attempting"," 0-RTT using the session tickets.",""," Remembered transport parameters apply to the new connection until the"," handshake completes and the client starts sending 1-RTT packets."," Once the handshake completes, the client uses the transport"," parameters established in the handshake. Not all transport"," parameters are remembered, as some do not apply to future connections"," or they have no effect on the use of 0-RTT.","",[[[],0," "],[[39,438],226,"The definition of a new transport parameter (Section 7.4.2) MUST"]],[[[],0," "],[[39,438],226,"specify whether storing the transport parameter for 0-RTT is"]],[[[],0," "],[[39,438],226,"mandatory, optional, or prohibited."],[[],0," A client need not store a"]]," transport parameter it cannot process.","",[[[],0," "],[[439,1917,2876],244,"A client MUST NOT use remembered values for the following parameters:"]],[[[],0," "],[[439,1917,2876],244,"ack_delay_exponent, max_ack_delay, initial_source_connection_id,"]],[[[],0," "],[[439,1917,2876],244,"original_destination_connection_id, preferred_address,"]],[[[],0," "],[[439,1917,2876],244,"retry_source_connection_id, and stateless_reset_token."],[[],0," "],[[440,1918,2877],244,"The client"]],[[[],0," "],[[440,1918,2877],244,"MUST use the server's new values in the handshake instead; if the"]],[[[],0," "],[[440,1918,2877],244,"server does not provide new values, the default values are used."]],"",[[[],0," "],[[441,2197,2863],244,"A client that attempts to send 0-RTT data MUST remember all other"]],[[[],0," "],[[441,2197,2863],244,"transport parameters used by the server that it is able to process."]]," The server can remember these transport parameters or can store an"," integrity-protected copy of the values in the ticket and recover the"," information when accepting 0-RTT data. A server uses the transport"," parameters in determining whether to accept 0-RTT data.","",[[[],0," "],[[442,1856,2872],244,"If 0-RTT data is accepted by the server, the server MUST NOT reduce"]],[[[],0," "],[[442,1856,2872],244,"any limits or alter any values that might be violated by the client"]],[[[],0," "],[[442,1856,2872],244,"with its 0-RTT data."],[[],0," "],[[443,1857,2873],244,"In particular, a server that accepts 0-RTT data"]],[[[],0," "],[[443,1857,2873],244,"MUST NOT set values for the following parameters (Section 18.2) that"]],[[[],0," "],[[443,1857,2873],244,"are smaller than the remembered values of the parameters."]],""," * active_connection_id_limit",""," * initial_max_data",""," * initial_max_stream_data_bidi_local",""," * initial_max_stream_data_bidi_remote",""," * initial_max_stream_data_uni",""," * initial_max_streams_bidi",""," * initial_max_streams_uni",""," Omitting or setting a zero value for certain transport parameters can",[[[],0," result in 0-RTT data being enabled but not usable. "],[[444,1422,2356,2865],180,"The applicable"]],[[[],0," "],[[444,1422,2356,2865],180,"subset of transport parameters that permit the sending of application"]],[[[],0," "],[[444,1422,2356,2865],180,"data SHOULD be set to non-zero values for 0-RTT."],[[],0," This includes"]]," initial_max_data and either (1) initial_max_streams_bidi and"," initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni"," and initial_max_stream_data_uni.",""," A server might provide larger initial stream flow control limits for"," streams than the remembered values that a client applies when sending"," 0-RTT. Once the handshake completes, the client updates the flow"," control limits on all sending streams using the updated values of"," initial_max_stream_data_bidi_remote and initial_max_stream_data_uni.","",[[[],0," "],[[445,1855],112,"A server MAY store and recover the previously sent values of the"]],[[[],0," "],[[445,1855],112,"max_idle_timeout, max_udp_payload_size, and disable_active_migration"]],[[[],0," "],[[445,1855],112,"parameters and reject 0-RTT if it selects smaller values."],[[],0," Lowering"]]," the values of these parameters while also accepting 0-RTT data could"," degrade the performance of the connection. Specifically, lowering"," the max_udp_payload_size could result in dropped packets, leading to"," worse performance compared to rejecting 0-RTT data outright.","",[[[],0," "],[[446,1920,2871],244,"A server MUST reject 0-RTT data if the restored values for transport"]],[[[],0," "],[[446,1920,2871],244,"parameters cannot be supported."]],"",[[[],0," "],[[447,1915,2199,2875],244,"When sending frames in 0-RTT packets, a client MUST only use"]],[[[],0," "],[[447,1915,2199,2875],244,"remembered transport parameters; importantly, it MUST NOT use updated"]],[[[],0," "],[[447,1915,2199,2875],244,"values that it learns from the server's updated transport parameters"]],[[[],0," "],[[447,1915,2199,2875],244,"or from frames received in 1-RTT packets."],[[],0," Updated values of"]]," transport parameters from the handshake apply only to 1-RTT packets."," For instance, flow control limits from remembered transport"," parameters apply to all 0-RTT packets even if those values are",[[[],0," increased by the handshake or by frames sent in 1-RTT packets. "],[[],0,"A"]],[[[],0," "],[[448],96,"server MAY treat the use of updated transport parameters in 0-RTT as"]],[[[],0," "],[[448],96,"a connection error of type PROTOCOL_VIOLATION."]]],"requirements":[438,439,440,441,442,443,444,445,446,447,448]},{"id":"section-7.4.2","title":"New Transport Parameters","lines":[" New transport parameters can be used to negotiate new protocol",[[[],0," behavior. "],[[449,2488,3024],244,"An endpoint MUST ignore transport parameters that it does"]],[[[],0," "],[[449,2488,3024],244,"not support."],[[],0," The absence of a transport parameter therefore disables"]]," any optional protocol feature that is negotiated using the parameter."," As described in Section 18.1, some identifiers are reserved in order"," to exercise this requirement.",""," A client that does not understand a transport parameter can discard"," it and attempt 0-RTT on subsequent connections. However, if the"," client adds support for a discarded transport parameter, it risks"," violating the constraints that the transport parameter establishes if"," it attempts 0-RTT. New transport parameters can avoid this problem"," by setting a default of the most conservative value. Clients can"," avoid this problem by remembering all parameters, even those not"," currently supported.",""," New transport parameters can be registered according to the rules in"," Section 22.3."],"requirements":[449]},{"id":"section-7.5","title":"Cryptographic Message Buffering","lines":[" Implementations need to maintain a buffer of CRYPTO data received out"," of order. Because there is no flow control of CRYPTO frames, an"," endpoint could potentially force its peer to buffer an unbounded"," amount of data.","",[[[],0," "],[[453,2367,3075],244,"Implementations MUST support buffering at least 4096 bytes of data"]],[[[],0," "],[[453,2367,3075],244,"received in out-of-order CRYPTO frames."],[[],0," "],[[454],96,"Endpoints MAY choose to"]],[[[],0," "],[[454],96,"allow more data to be buffered during the handshake."],[[],0," A larger limit"]]," during the handshake could allow for larger keys or credentials to be"," exchanged. An endpoint's buffer size does not need to remain"," constant during the life of the connection.",""," Being unable to buffer CRYPTO frames during the handshake can lead to"," a connection failure. If an endpoint's buffer is exceeded during the"," handshake, it can expand its buffer temporarily to complete the",[[[],0," handshake. "],[[455,1750,1864,2655,3076],244,"If an endpoint does not expand its buffer, it MUST close"]],[[[],0," "],[[455,1750,1864,2655,3076],244,"the connection with a CRYPTO_BUFFER_EXCEEDED error code."]],"",[[[],0," "],[[456,1811,1821],112,"Once the handshake completes, if an endpoint is unable to buffer all"]],[[[],0," "],[[456,1811,1821],112,"data in a CRYPTO frame, it MAY discard that CRYPTO frame and all"]],[[[],0," "],[[456,1811,1821],112,"CRYPTO frames received in the future, or it MAY close the connection"]],[[[],0," "],[[456,1811,1821],112,"with a CRYPTO_BUFFER_EXCEEDED error code."],[[],0," "],[[457,1765,2724],244,"Packets containing"]],[[[],0," "],[[457,1765,2724],244,"discarded CRYPTO frames MUST be acknowledged because the packet has"]],[[[],0," "],[[457,1765,2724],244,"been received and processed by the transport even though the CRYPTO"]],[[[],0," "],[[457,1765,2724],244,"frame was discarded."]]],"requirements":[453,454,455,456,457]},{"id":"section-8","title":"Address Validation","lines":[" Address validation ensures that an endpoint cannot be used for a"," traffic amplification attack. In such an attack, a packet is sent to"," a server with spoofed source address information that identifies a"," victim. If a server generates more or larger packets in response to"," that packet, the attacker can use the server to send more data toward"," the victim than it would be able to send on its own.",""," The primary defense against amplification attacks is verifying that a"," peer is able to receive packets at the transport address that it",[[[],0," claims. "],[[514,2060,2757,2758],244,"Therefore, after receiving packets from an address that is"]],[[[],0," "],[[514,2060,2757,2758],244,"not yet validated, an endpoint MUST limit the amount of data it sends"]],[[[],0," "],[[514,2060,2757,2758],244,"to the unvalidated address to three times the amount of data received"]],[[[],0," "],[[514,2060,2757,2758],244,"from that address."],[[],0," This limit on the size of responses is known as"]]," the anti-amplification limit.",""," Address validation is performed both during connection establishment"," (see Section 8.1) and during connection migration (see Section 8.2)."],"requirements":[514]},{"id":"section-8.1","title":"Address Validation during Connection Establishment","lines":[" Connection establishment implicitly provides address validation for"," both endpoints. In particular, receipt of a packet protected with"," Handshake keys confirms that the peer successfully processed an"," Initial packet. Once an endpoint has successfully processed a"," Handshake packet from the peer, it can consider the peer address to"," have been validated.","",[[[],0," "],[[489],96,"Additionally, an endpoint MAY consider the peer address validated if"]],[[[],0," "],[[489],96,"the peer uses a connection ID chosen by the endpoint and the"]],[[[],0," "],[[489],96,"connection ID contains at least 64 bits of entropy."]],""," For the client, the value of the Destination Connection ID field in"," its first Initial packet allows it to validate the server address as"," a part of successfully processing any packet. Initial packets from"," the server are protected with keys that are derived from this value"," (see Section 5.2 of [QUIC-TLS]). Alternatively, the value is echoed"," by the server in Version Negotiation packets (Section 6) or included"," in the Integrity Tag in Retry packets (Section 5.8 of [QUIC-TLS]).","",[[[],0," "],[[490,2059,2665],244,"Prior to validating the client address, servers MUST NOT send more"]],[[[],0," "],[[490,2059,2665],244,"than three times as many bytes as the number of bytes they have"]],[[[],0," "],[[490,2059,2665],244,"received."],[[],0," This limits the magnitude of any amplification attack that"]],[[[],0," can be mounted using spoofed source addresses. "],[[491,1696,2575],244,"For the purposes of"]],[[[],0," "],[[491,1696,2575],244,"avoiding amplification prior to address validation, servers MUST"]],[[[],0," "],[[491,1696,2575],244,"count all of the payload bytes received in datagrams that are"]],[[[],0," "],[[491,1696,2575],244,"uniquely attributed to a single connection."],[[],0," This includes datagrams"]]," that contain packets that are successfully processed and datagrams"," that contain packets that are all discarded.","",[[[],0," "],[[492,2091,2713],244,"Clients MUST ensure that UDP datagrams containing Initial packets"]],[[[],0," "],[[492,2091,2713],244,"have UDP payloads of at least 1200 bytes, adding PADDING frames as"]],[[[],0," "],[[492,2091,2713],244,"necessary."],[[],0," A client that sends padded datagrams allows the server to"]]," send more data prior to completing address validation.",""," Loss of an Initial or Handshake packet from the server can cause a"," deadlock if the client does not send additional Initial or Handshake"," packets. A deadlock could occur when the server reaches its anti-"," amplification limit and the client has received acknowledgments for"," all the data it has sent. In this case, when the client has no"," reason to send additional packets, the server will be unable to send",[[[],0," more data because it has not validated the client's address. "],[[493,1739,2178,2544,2546,2547,2549,2550],244,"To"]],[[[],0," "],[[493,1739,2178,2544,2546,2547,2549,2550],244,"prevent this deadlock, clients MUST send a packet on a Probe Timeout"]],[[[],0," "],[[493,1739,2178,2544,2546,2547,2549,2550],244,"(PTO); see Section 6.2 of [QUIC-RECOVERY]."],[[],0," "],[[494,1900,2113,2124,2545,2548,2551,2552],244,"Specifically, the client"]],[[[],0," "],[[494,1900,2113,2124,2545,2548,2551,2552],244,"MUST send an Initial packet in a UDP datagram that contains at least"]],[[[],0," "],[[494,1900,2113,2124,2545,2548,2551,2552],244,"1200 bytes if it does not have Handshake keys, and otherwise send a"]],[[[],0," "],[[494,1900,2113,2124,2545,2548,2551,2552],244,"Handshake packet."]],""," A server might wish to validate the client address before starting"," the cryptographic handshake. QUIC uses a token in the Initial packet"," to provide address validation prior to completing the handshake."," This token is delivered to the client during connection establishment"," with a Retry packet (see Section 8.1.2) or in a previous connection"," using the NEW_TOKEN frame (see Section 8.1.3).",""," In addition to sending limits imposed prior to address validation,"," servers are also constrained in what they can send by the limits set"," by the congestion controller. Clients are only constrained by the"," congestion controller."],"requirements":[489,490,491,492,493,494]},{"id":"section-8.1.1","title":"Token Construction","lines":[[[[],0," "],[[460,2213,2910],244,"A token sent in a NEW_TOKEN frame or a Retry packet MUST be"]],[[[],0," "],[[460,2213,2910],244,"constructed in a way that allows the server to identify how it was"]],[[[],0," "],[[460,2213,2910],244,"provided to a client."],[[],0," These tokens are carried in the same field but"]]," require different handling from servers."],"requirements":[460]},{"id":"section-8.1.2","title":"Address Validation Using Retry Packets","lines":[" Upon receiving the client's Initial packet, the server can request"," address validation by sending a Retry packet (Section 17.2.5)",[[[],0," containing a token. "],[[461,2352,2798],244,"This token MUST be repeated by the client in all"]],[[[],0," "],[[461,2352,2798],244,"Initial packets it sends for that connection after it receives the"]],[[[],0," "],[[461,2352,2798],244,"Retry packet."]],""," In response to processing an Initial packet containing a token that"," was provided in a Retry packet, a server cannot send another Retry"," packet; it can only refuse the connection or permit it to proceed.",""," As long as it is not possible for an attacker to generate a valid"," token for its own address (see Section 8.1.4) and the client is able"," to return that token, it proves to the server that it received the"," token.",""," A server can also use a Retry packet to defer the state and"," processing costs of connection establishment. Requiring the server"," to provide a different connection ID, along with the"," original_destination_connection_id transport parameter defined in"," Section 18.2, forces the server to demonstrate that it, or an entity"," it cooperates with, received the original Initial packet from the"," client. Providing a different connection ID also grants a server"," some control over how subsequent packets are routed. This can be"," used to direct connections to a different server instance.",""," If a server receives a client Initial that contains an invalid Retry"," token but is otherwise valid, it knows the client will not accept"," another Retry token. The server can discard such a packet and allow"," the client to time out to detect handshake failure, but that could",[[[],0," impose a significant latency penalty on the client. "],[[462,2331],176,"Instead, the"]],[[[],0," "],[[462,2331],176,"server SHOULD immediately close (Section 10.2) the connection with an"]],[[[],0," "],[[462,2331],176,"INVALID_TOKEN error."],[[],0," Note that a server has not established any"]]," state for the connection at this point and so does not enter the"," closing period.",""," A flow showing the use of a Retry packet is shown in Figure 9.",""," Client Server",""," Initial[0]: CRYPTO[CH] ->",""," <- Retry+Token",""," Initial+Token[1]: CRYPTO[CH] ->",""," Initial[0]: CRYPTO[SH] ACK[1]"," Handshake[0]: CRYPTO[EE, CERT, CV, FIN]"," <- 1-RTT[0]: STREAM[1, \"...\"]",""," Figure 9: Example Handshake with Retry"],"requirements":[461,462]},{"id":"section-8.1.3","title":"Address Validation for Future Connections","lines":[[[[],0," "],[[463,2261],112,"A server MAY provide clients with an address validation token during"]],[[[],0," "],[[463,2261],112,"one connection that can be used on a subsequent connection."],[[],0," Address"]]," validation is especially important with 0-RTT because a server"," potentially sends a significant amount of data to a client in"," response to 0-RTT data.",""," The server uses the NEW_TOKEN frame (Section 19.7) to provide the"," client with an address validation token that can be used to validate"," future connections. In a future connection, the client includes this",[[[],0," token in Initial packets to provide address validation. "],[[464,2112,2353,2799,2937],244,"The client"]],[[[],0," "],[[464,2112,2353,2799,2937],244,"MUST include the token in all Initial packets it sends, unless a"]],[[[],0," "],[[464,2112,2353,2799,2937],244,"Retry replaces the token with a newer one."],[[],0," "],[[465,2257,2308,2939],244,"The client MUST NOT use"]],[[[],0," "],[[465,2257,2308,2939],244,"the token provided in a Retry for future connections."],[[],0," "],[[466],96,"Servers MAY"]],[[[],0," "],[[466],96,"discard any Initial packet that does not carry the expected token."]],""," Unlike the token that is created for a Retry packet, which is used"," immediately, the token sent in the NEW_TOKEN frame can be used after",[[[],0," some period of time has passed. "],[[467,2236,2249,2917],180,"Thus, a token SHOULD have an"]],[[[],0," "],[[467,2236,2249,2917],180,"expiration time, which could be either an explicit expiration time or"]],[[[],0," "],[[467,2236,2249,2917],180,"an issued timestamp that can be used to dynamically calculate the"]],[[[],0," "],[[467,2236,2249,2917],180,"expiration time."],[[],0," A server can store the expiration time or include"]]," it in an encrypted form in the token.","",[[[],0," "],[[468,2234,2237,2925,2927],244,"A token issued with NEW_TOKEN MUST NOT include information that would"]],[[[],0," "],[[468,2234,2237,2925,2927],244,"allow values to be linked by an observer to the connection on which"]],[[[],0," "],[[468,2234,2237,2925,2927],244,"it was issued."],[[],0," For example, it cannot include the previous"]]," connection ID or addressing information, unless the values are",[[[],0," encrypted. "],[[469,2233,2238,2924,2926],244,"A server MUST ensure that every NEW_TOKEN frame it sends"]],[[[],0," "],[[469,2233,2238,2924,2926],244,"is unique across all clients, with the exception of those sent to"]],[[[],0," "],[[469,2233,2238,2924,2926],244,"repair losses of previously sent NEW_TOKEN frames."],[[],0," "],[[470,2214],112,"Information that"]],[[[],0," "],[[470,2214],112,"allows the server to distinguish between tokens from Retry and"]],[[[],0," "],[[470,2214],112,"NEW_TOKEN MAY be accessible to entities other than the server."]],""," It is unlikely that the client port number is the same on two"," different connections; validating the port is therefore unlikely to"," be successful.",""," A token received in a NEW_TOKEN frame is applicable to any server"," that the connection is considered authoritative for (e.g., server",[[[],0," names included in the certificate). "],[[471,2263,2307,2933,2936],180,"When connecting to a server for"]],[[[],0," "],[[471,2263,2307,2933,2936],180,"which the client retains an applicable and unused token, it SHOULD"]],[[[],0," "],[[471,2263,2307,2933,2936],180,"include that token in the Token field of its Initial packet."]]," Including a token might allow the server to validate the client",[[[],0," address without an additional round trip. "],[[472,2264,2938],244,"A client MUST NOT include"]],[[[],0," "],[[472,2264,2938],244,"a token that is not applicable to the server that it is connecting"]],[[[],0," "],[[472,2264,2938],244,"to, unless the client has the knowledge that the server that issued"]],[[[],0," "],[[472,2264,2938],244,"the token and the server the client is connecting to are jointly"]],[[[],0," "],[[472,2264,2938],244,"managing the tokens."],[[],0," "],[[473,2259,2932],116,"A client MAY use a token from any previous"]],[[[],0," "],[[473,2259,2932],116,"connection to that server."]],""," A token allows a server to correlate activity between the connection"," where the token was issued and any connection where it is used."," Clients that want to break continuity of identity with a server can",[[[],0," discard tokens provided using the NEW_TOKEN frame. "],[[474,2258,2309,2940],244,"In comparison, a"]],[[[],0," "],[[474,2258,2309,2940],244,"token obtained in a Retry packet MUST be used immediately during the"]],[[[],0," "],[[474,2258,2309,2940],244,"connection attempt and cannot be used in subsequent connection"]],[[[],0," "],[[474,2258,2309,2940],244,"attempts."]],"",[[[],0," "],[[475,2267,2934,2935],180,"A client SHOULD NOT reuse a token from a NEW_TOKEN frame for"]],[[[],0," "],[[475,2267,2934,2935],180,"different connection attempts."],[[],0," Reusing a token allows connections to"]]," be linked by entities on the network path; see Section 9.5.",""," Clients might receive multiple tokens on a single connection. Aside"," from preventing linkability, any token can be used in any connection"," attempt. Servers can send additional tokens to either enable address"," validation for multiple connection attempts or replace older tokens"," that might become invalid. For a client, this ambiguity means that"," sending the most recent unused token is most likely to be effective."," Though saving and using older tokens have no negative consequences,"," clients can regard older tokens as being less likely to be useful to"," the server for address validation.","",[[[],0," "],[[476,2330,2921],244,"When a server receives an Initial packet with an address validation"]],[[[],0," "],[[476,2330,2921],244,"token, it MUST attempt to validate the token, unless it has already"]],[[[],0," "],[[476,2330,2921],244,"completed address validation."],[[],0," "],[[477,2332],176,"If the token is invalid, then the"]],[[[],0," "],[[477,2332],176,"server SHOULD proceed as if the client did not have a validated"]],[[[],0," "],[[477,2332],176,"address, including potentially sending a Retry packet."],[[],0," Tokens"]]," provided with NEW_TOKEN frames and Retry packets can be distinguished"," by servers (see Section 8.1.1), and the latter can be validated more",[[[],0," strictly. "],[[478,2335,2922],180,"If the validation succeeds, the server SHOULD then allow"]],[[[],0," "],[[478,2335,2922],180,"the handshake to proceed."]],""," | Note: The rationale for treating the client as unvalidated"," | rather than discarding the packet is that the client might have"," | received the token in a previous connection using the NEW_TOKEN"," | frame, and if the server has lost state, it might be unable to"," | validate the token at all, leading to connection failure if the"," | packet is discarded.",""," In a stateless design, a server can use encrypted and authenticated"," tokens to pass information to clients that the server can later"," recover and use to validate a client address. Tokens are not"," integrated into the cryptographic handshake, and so they are not"," authenticated. For instance, a client might be able to reuse a"," token. To avoid attacks that exploit this property, a server can"," limit its use of tokens to only the information needed to validate"," client addresses.","",[[[],0," "],[[479,2266],112,"Clients MAY use tokens obtained on one connection for any connection"]],[[[],0," "],[[479,2266],112,"attempt using the same version."],[[],0," When selecting a token to use,"]]," clients do not need to consider other properties of the connection"," that is being attempted, including the choice of possible application"," protocols, session tickets, or other connection properties."],"requirements":[463,464,465,466,467,468,469,470,471,472,473,474,475,476,477,478,479]},{"id":"section-8.1.4","title":"Address Validation Token Integrity","lines":[[[[],0," "],[[480,2232,2908],244,"An address validation token MUST be difficult to guess."],[[],0," Including a"]]," random value with at least 128 bits of entropy in the token would be"," sufficient, but this depends on the server remembering the value it"," sends to clients.",""," A token-based scheme allows the server to offload any state",[[[],0," associated with validation to the client. "],[[481,2215,2216,2920],244,"For this design to work,"]],[[[],0," "],[[481,2215,2216,2920],244,"the token MUST be covered by integrity protection against"]],[[[],0," "],[[481,2215,2216,2920],244,"modification or falsification by clients."],[[],0," Without integrity"]]," protection, malicious clients could generate or guess values for"," tokens that would be accepted by the server. Only the server"," requires access to the integrity protection key for tokens.",""," There is no need for a single well-defined format for the token",[[[],0," because the server that generates the token also consumes it. "],[[482,2243,2911],180,"Tokens"]],[[[],0," "],[[482,2243,2911],180,"sent in Retry packets SHOULD include information that allows the"]],[[[],0," "],[[482,2243,2911],180,"server to verify that the source IP address and port in client"]],[[[],0," "],[[482,2243,2911],180,"packets remain constant."]],"",[[[],0," "],[[483,2251,2915],244,"Tokens sent in NEW_TOKEN frames MUST include information that allows"]],[[[],0," "],[[483,2251,2915],244,"the server to verify that the client IP address has not changed from"]],[[[],0," "],[[483,2251,2915],244,"when the token was issued."],[[],0," Servers can use tokens from NEW_TOKEN"]]," frames in deciding not to send a Retry packet, even if the client",[[[],0," address has changed. "],[[484,2058,2923],244,"If the client IP address has changed, the"]],[[[],0," "],[[484,2058,2923],244,"server MUST adhere to the anti-amplification limit; see Section 8."]]," Note that in the presence of NAT, this requirement might be"," insufficient to protect other hosts that share the NAT from"," amplification attacks.",""," Attackers could replay tokens to use servers as amplifiers in DDoS",[[[],0," attacks. "],[[485,2242,2245,2247,2912],244,"To protect against such attacks, servers MUST ensure that"]],[[[],0," "],[[485,2242,2245,2247,2912],244,"replay of tokens is prevented or limited."],[[],0," "],[[486,2231,2241,2914],180,"Servers SHOULD ensure that"]],[[[],0," "],[[486,2231,2241,2914],180,"tokens sent in Retry packets are only accepted for a short time, as"]],[[[],0," "],[[486,2231,2241,2914],180,"they are returned immediately by clients."],[[],0," "],[[487,2250,2252,2919],180,"Tokens that are provided"]],[[[],0," "],[[487,2250,2252,2919],180,"in NEW_TOKEN frames (Section 19.7) need to be valid for longer but"]],[[[],0," "],[[487,2250,2252,2919],180,"SHOULD NOT be accepted multiple times."],[[],0," "],[[488,2253,2254],112,"Servers are encouraged to"]],[[[],0," "],[[488,2253,2254],112,"allow tokens to be used only once, if possible; tokens MAY include"]],[[[],0," "],[[488,2253,2254],112,"additional information about clients to further narrow applicability"]],[[[],0," "],[[488,2253,2254],112,"or reuse."]]],"requirements":[480,481,482,483,484,485,486,487,488]},{"id":"section-8.2","title":"Path Validation","lines":[" Path validation is used by both peers during connection migration"," (see Section 9) to verify reachability after a change of address. In"," path validation, endpoints test reachability between a specific local"," address and a specific peer address, where an address is the 2-tuple"," of IP address and port.",""," Path validation tests that packets sent on a path to a peer are"," received by that peer. Path validation is used to ensure that"," packets received from a migrating peer do not carry a spoofed source"," address.",""," Path validation does not validate that a peer can send in the return"," direction. Acknowledgments cannot be used for return path validation"," because they contain insufficient entropy and might be spoofed."," Endpoints independently determine reachability on each direction of a"," path, and therefore return reachability can only be established by"," the peer.",""," Path validation can be used at any time by either endpoint. For"," instance, an endpoint might check that a peer is still in possession"," of its address after a period of quiescence.",""," Path validation is not designed as a NAT traversal mechanism. Though"," the mechanism described here might be effective for the creation of"," NAT bindings that support NAT traversal, the expectation is that one"," endpoint is able to receive packets without first having sent a"," packet on that path. Effective NAT traversal needs additional"," synchronization mechanisms that are not provided here.","",[[[],0," "],[[513,2764],100,"An endpoint MAY include other frames with the PATH_CHALLENGE and"]],[[[],0," "],[[513,2764],100,"PATH_RESPONSE frames used for path validation."],[[],0," In particular, an"]]," endpoint can include PADDING frames with a PATH_CHALLENGE frame for"," Path Maximum Transmission Unit Discovery (PMTUD); see Section 14.2.1."," An endpoint can also include its own PATH_CHALLENGE frame when"," sending a PATH_RESPONSE frame.",""," An endpoint uses a new connection ID for probes sent from a new local"," address; see Section 9.5. When probing a new path, an endpoint can"," ensure that its peer has an unused connection ID available for"," responses. Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in"," the same packet, if the peer's active_connection_id_limit permits,"," ensures that an unused connection ID will be available to the peer"," when sending a response.",""," An endpoint can choose to simultaneously probe multiple paths. The"," number of simultaneous paths used for probes is limited by the number"," of extra connection IDs its peer has previously supplied, since each"," new local address used for a probe requires a previously unused"," connection ID."],"requirements":[513]},{"id":"section-8.2.1","title":"Initiating Path Validation","lines":[" To initiate path validation, an endpoint sends a PATH_CHALLENGE frame"," containing an unpredictable payload on the path to be validated.","",[[[],0," "],[[495,1806],112,"An endpoint MAY send multiple PATH_CHALLENGE frames to guard against"]],[[[],0," "],[[495,1806],112,"packet loss."],[[],0," "],[[496,2081,2137,2140,2143,2788],180,"However, an endpoint SHOULD NOT send multiple"]],[[[],0," "],[[496,2081,2137,2140,2143,2788],180,"PATH_CHALLENGE frames in a single packet."]],"",[[[],0," "],[[497,2141,2789],180,"An endpoint SHOULD NOT probe a new path with packets containing a"]],[[[],0," "],[[497,2141,2789],180,"PATH_CHALLENGE frame more frequently than it would send an Initial"]],[[[],0," "],[[497,2141,2789],180,"packet."],[[],0," This ensures that connection migration is no more load on a"]]," new path than establishing a new connection.","",[[[],0," "],[[498,1848,1849,2782],244,"The endpoint MUST use unpredictable data in every PATH_CHALLENGE"]],[[[],0," "],[[498,1848,1849,2782],244,"frame so that it can associate the peer's response with the"]],[[[],0," "],[[498,1848,1849,2782],244,"corresponding PATH_CHALLENGE."]],"",[[[],0," "],[[499,2079,2786,2787],244,"An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame"]],[[[],0," "],[[499,2079,2786,2787],244,"to at least the smallest allowed maximum datagram size of 1200 bytes,"]],[[[],0," "],[[499,2079,2786,2787],244,"unless the anti-amplification limit for the path does not permit"]],[[[],0," "],[[499,2079,2786,2787],244,"sending a datagram of this size."],[[],0," Sending UDP datagrams of this size"]]," ensures that the network path from the endpoint to the peer can be"," used for QUIC; see Section 14.",""," When an endpoint is unable to expand the datagram size to 1200 bytes"," due to the anti-amplification limit, the path MTU will not be",[[[],0," validated. "],[[500,1944,2778],244,"To ensure that the path MTU is large enough, the endpoint"]],[[[],0," "],[[500,1944,2778],244,"MUST perform a second path validation by sending a PATH_CHALLENGE"]],[[[],0," "],[[500,1944,2778],244,"frame in a datagram of at least 1200 bytes."],[[],0," This additional"]]," validation can be performed after a PATH_RESPONSE is successfully"," received or when enough bytes have been received on the path that"," sending the larger datagram will not result in exceeding the anti-"," amplification limit.","",[[[],0," "],[[501,2147,2763],244,"Unlike other cases where datagrams are expanded, endpoints MUST NOT"]],[[[],0," "],[[501,2147,2763],244,"discard datagrams that appear to be too small when they contain"]],[[[],0," "],[[501,2147,2763],244,"PATH_CHALLENGE or PATH_RESPONSE."]]],"requirements":[495,496,497,498,499,500,501]},{"id":"section-8.2.2","title":"Path Validation Responses","lines":[[[[],0," "],[[502,1941,2760,2774],244,"On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by"]],[[[],0," "],[[502,1941,2760,2774],244,"echoing the data contained in the PATH_CHALLENGE frame in a"]],[[[],0," "],[[502,1941,2760,2774],244,"PATH_RESPONSE frame."],[[],0," "],[[503,2134,2567],244,"An endpoint MUST NOT delay transmission of a"]],[[[],0," "],[[503,2134,2567],244,"packet containing a PATH_RESPONSE frame unless constrained by"]],[[[],0," "],[[503,2134,2567],244,"congestion control."]],"",[[[],0," "],[[504,2135,2766,2772],244,"A PATH_RESPONSE frame MUST be sent on the network path where the"]],[[[],0," "],[[504,2135,2766,2772],244,"PATH_CHALLENGE frame was received."],[[],0," This ensures that path validation"]]," by a peer only succeeds if the path is functional in both directions.",[[[],0," "],[[505,1816,2785],244,"This requirement MUST NOT be enforced by the endpoint that initiates"]],[[[],0," "],[[505,1816,2785],244,"path validation, as that would enable an attack on migration; see"]],[[[],0," "],[[505,1816,2785],244,"Section 9.3.3."]],"",[[[],0," "],[[506,2078,2767,2773,2777],244,"An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame"]],[[[],0," "],[[506,2078,2767,2773,2777],244,"to at least the smallest allowed maximum datagram size of 1200 bytes."]]," This verifies that the path is able to carry datagrams of this size",[[[],0," in both directions. "],[[507,2146,2762],244,"However, an endpoint MUST NOT expand the"]],[[[],0," "],[[507,2146,2762],244,"datagram containing the PATH_RESPONSE if the resulting data exceeds"]],[[[],0," "],[[507,2146,2762],244,"the anti-amplification limit."],[[],0," This is expected to only occur if the"]]," received PATH_CHALLENGE was not sent in an expanded datagram.","",[[[],0," "],[[508,2136,2768],244,"An endpoint MUST NOT send more than one PATH_RESPONSE frame in"]],[[[],0," "],[[508,2136,2768],244,"response to one PATH_CHALLENGE frame; see Section 13.3."],[[],0," The peer is"]]," expected to send more PATH_CHALLENGE frames as necessary to evoke"," additional PATH_RESPONSE frames."],"requirements":[502,503,504,505,506,507,508]},{"id":"section-8.2.3","title":"Successful Path Validation","lines":[" Path validation succeeds when a PATH_RESPONSE frame is received that"," contains the data that was sent in a previous PATH_CHALLENGE frame."," A PATH_RESPONSE frame received on any network path validates the path"," on which the PATH_CHALLENGE was sent.",""," If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not"," expanded to at least 1200 bytes and if the response to it validates"," the peer address, the path is validated but not the path MTU. As a"," result, the endpoint can now send more than three times the amount of",[[[],0," data that has been received. "],[[509,1945,2779],244,"However, the endpoint MUST initiate"]],[[[],0," "],[[509,1945,2779],244,"another path validation with an expanded datagram to verify that the"]],[[[],0," "],[[509,1945,2779],244,"path supports the required MTU."]],""," Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE"," frame is not adequate validation, since the acknowledgment can be"," spoofed by a malicious peer."],"requirements":[509]},{"id":"section-8.2.4","title":"Failed Path Validation","lines":[" Path validation only fails when the endpoint attempting to validate"," the path abandons its attempt to validate the path.","",[[[],0," "],[[510,1733,2790],180,"Endpoints SHOULD abandon path validation based on a timer."],[[],0," When"]]," setting this timer, implementations are cautioned that the new path",[[[],0," could have a longer round-trip time than the original. "],[[511,2173,2784],180,"A value of"]],[[[],0," "],[[511,2173,2784],180,"three times the larger of the current PTO or the PTO for the new path"]],[[[],0," "],[[511,2173,2784],180,"(using kInitialRtt, as defined in [QUIC-RECOVERY]) is RECOMMENDED."]],""," This timeout allows for multiple PTOs to expire prior to failing path"," validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE"," frame does not cause path validation failure.",""," Note that the endpoint might receive packets containing other frames"," on the new path, but a PATH_RESPONSE frame with appropriate data is"," required for path validation to succeed.",""," When an endpoint abandons path validation, it determines that the"," path is unusable. This does not necessarily imply a failure of the"," connection -- endpoints can continue sending packets over other paths"," as appropriate. If no paths are available, an endpoint can wait for",[[[],0," a new path to become available or close the connection. "],[[512,1928],112,"An endpoint"]],[[[],0," "],[[512,1928],112,"that has no valid network path to its peer MAY signal this using the"]],[[[],0," "],[[512,1928],112,"NO_VIABLE_PATH connection error, noting that this is only possible if"]],[[[],0," "],[[512,1928],112,"the network path exists but does not support the required MTU"]],[[[],0," "],[[512,1928],112,"(Section 14)."]],""," A path validation might be abandoned for other reasons besides"," failure. Primarily, this happens if a connection migration to a new"," path is initiated while a path validation on the old path is in"," progress."],"requirements":[510,511,512]},{"id":"section-9","title":"Connection Migration","lines":[" The use of a connection ID allows connections to survive changes to"," endpoint addresses (IP address and port), such as those caused by an"," endpoint migrating to a new network. This section describes the"," process by which an endpoint migrates to a new address.",""," The design of QUIC relies on endpoints retaining a stable address for",[[[],0," the duration of the handshake. "],[[557,1722,2732],244,"An endpoint MUST NOT initiate"]],[[[],0," "],[[557,1722,2732],244,"connection migration before the handshake is confirmed, as defined in"]],[[[],0," "],[[557,1722,2732],244,"Section 4.1.2 of [QUIC-TLS]."]],"",[[[],0," "],[[558,1724,2726,2756],244,"If the peer sent the disable_active_migration transport parameter, an"]],[[[],0," "],[[558,1724,2726,2756],244,"endpoint also MUST NOT send packets (including probing packets; see"]],[[[],0," "],[[558,1724,2726,2756],244,"Section 9.1) from a different local address to the address the peer"]],[[[],0," "],[[558,1724,2726,2756],244,"used during the handshake, unless the endpoint has acted on a"]],[[[],0," "],[[558,1724,2726,2756],244,"preferred_address transport parameter from the peer."],[[],0," "],[[559,1934,2742],244,"If the peer"]],[[[],0," "],[[559,1934,2742],244,"violates this requirement, the endpoint MUST either drop the incoming"]],[[[],0," "],[[559,1934,2742],244,"packets on that path without generating a Stateless Reset or proceed"]],[[[],0," "],[[559,1934,2742],244,"with path validation and allow the peer to migrate."],[[],0," Generating a"]]," Stateless Reset or closing the connection would allow third parties"," in the network to cause connections to close by spoofing or otherwise"," manipulating observed traffic.",""," Not all changes of peer address are intentional, or active,"," migrations. The peer could experience NAT rebinding: a change of"," address due to a middlebox, usually a NAT, allocating a new outgoing",[[[],0," port or even a new outgoing IP address for a flow. "],[[560,1810,1836,1842,1937,2729,2741],244,"An endpoint MUST"]],[[[],0," "],[[560,1810,1836,1842,1937,2729,2741],244,"perform path validation (Section 8.2) if it detects any change to a"]],[[[],0," "],[[560,1810,1836,1842,1937,2729,2741],244,"peer's address, unless it has previously validated that address."]],"",[[[],0," "],[[561,1734],112,"When an endpoint has no validated path on which to send packets, it"]],[[[],0," "],[[561,1734],112,"MAY discard connection state."],[[],0," "],[[562],96,"An endpoint capable of connection"]],[[[],0," "],[[562],96,"migration MAY wait for a new path to become available before"]],[[[],0," "],[[562],96,"discarding connection state."]],""," This document limits migration of connections to new client"," addresses, except as described in Section 9.6. Clients are"," responsible for initiating all migrations. Servers do not send non-"," probing packets (see Section 9.1) toward a client address until they",[[[],0," see a non-probing packet from that address. "],[[563,2304],240,"If a client receives"]],[[[],0," "],[[563,2304],240,"packets from an unknown server address, the client MUST discard these"]],[[[],0," "],[[563,2304],240,"packets."]]],"requirements":[557,558,559,560,561,562,563]},{"id":"section-9.1","title":"Probing a New Path","lines":[[[[],0," "],[[515,1731],112,"An endpoint MAY probe for peer reachability from a new local address"]],[[[],0," "],[[515,1731],112,"using path validation (Section 8.2) prior to migrating the connection"]],[[[],0," "],[[515,1731],112,"to the new local address."],[[],0," Failure of path validation simply means"]]," that the new path is not usable for this connection. Failure to"," validate a path does not cause the connection to end unless there are"," no valid alternative paths available.","",[[[],0," "],[[2754],4,"PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames"]],[[[],0," "],[[2754],4,"are \"probing frames\", and all other frames are \"non-probing frames\"."]]," A packet containing only probing frames is a \"probing packet\", and a"," packet containing any other frame is a \"non-probing packet\"."],"requirements":[515]},{"id":"section-9.2","title":"Initiating Connection Migration","lines":[" An endpoint can migrate a connection to a new local address by"," sending packets containing non-probing frames from that address.",""," Each endpoint validates its peer's address during connection"," establishment. Therefore, a migrating endpoint can send to its peer"," knowing that the peer is willing to receive at the peer's current"," address. Thus, an endpoint can migrate to a new local address"," without first validating the peer's address.",""," To establish reachability on the new path, an endpoint initiates path",[[[],0," validation (Section 8.2) on the new path. "],[[516],96,"An endpoint MAY defer path"]],[[[],0," "],[[516],96,"validation until after a peer sends the next non-probing frame to its"]],[[[],0," "],[[516],96,"new address."]],""," When migrating, the new path might not support the endpoint's current"," sending rate. Therefore, the endpoint resets its congestion"," controller and RTT estimate, as described in Section 9.4.",""," The new path might not have the same ECN capability. Therefore, the"," endpoint validates ECN capability as described in Section 13.4."],"requirements":[516]},{"id":"section-9.3","title":"Responding to Connection Migration","lines":[" Receiving a packet from a new peer address containing a non-probing"," frame indicates that the peer has migrated to that address.","",[[[],0," "],[[522,1809,1835,1841,1935,2727,2739],244,"If the recipient permits the migration, it MUST send subsequent"]],[[[],0," "],[[522,1809,1835,1841,1935,2727,2739],244,"packets to the new peer address"],[[522,1809,1835,1841],240," "],[[522,1809,1835,1841,1936,2728,2740],244,"and MUST initiate path validation"]],[[[],0," "],[[522,1809,1835,1841,1936,2728,2740],244,"(Section 8.2) to verify the peer's ownership of the address if"]],[[[],0," "],[[522,1809,1835,1841,1936,2728,2740],244,"validation is not already underway."],[[],0," If the recipient has no unused"]]," connection IDs from the peer, it will not be able to send anything on"," the new path until the peer provides one; see Section 9.5.","",[[[],0," "],[[2053],16,"An endpoint only changes the address to which it sends packets in"]],[[[],0," "],[[2053],16,"response to the highest-numbered non-probing packet."],[[],0," This ensures"]]," that an endpoint does not send packets to an old peer address in the"," case that it receives reordered packets.","",[[[],0," "],[[523,2150,2730],244,"An endpoint MAY send data to an unvalidated peer address, but it MUST"]],[[[],0," "],[[523,2150,2730],244,"protect against potential attacks as described in Sections 9.3.1 and"]],[[[],0," "],[[523,2150,2730],244,"9.3.2."],[[],0," "],[[524],96,"An endpoint MAY skip validation of a peer address if that"]],[[[],0," "],[[524],96,"address has been seen recently."],[[],0," In particular, if an endpoint"]]," returns to a previously validated path after detecting some form of"," spurious migration, skipping address validation and restoring loss"," detection and congestion state can reduce the performance impact of"," the attack.",""," After changing the address to which it sends non-probing packets, an"," endpoint can abandon any path validation for other addresses.",""," Receiving a packet from a new peer address could be the result of a"," NAT rebinding at the peer.","",[[[],0," "],[[525,2256,2931],180,"After verifying a new client address, the server SHOULD send new"]],[[[],0," "],[[525,2256,2931],180,"address validation tokens (Section 8) to the client."]]],"requirements":[522,523,524,525]},{"id":"section-9.3.1","title":"Peer Address Spoofing","lines":[" It is possible that a peer is spoofing its source address to cause an"," endpoint to send excessive amounts of data to an unwilling host. If"," the endpoint sends significantly more data than the spoofing peer,"," connection migration might be used to amplify the volume of data that"," an attacker can generate toward a victim.",""," As described in Section 9.3, an endpoint is required to validate a"," peer's new address to confirm the peer's possession of the new"," address. Until a peer's address is deemed valid, an endpoint limits"," the amount of data it sends to that address; see Section 8. In the"," absence of this limit, an endpoint risks being used for a denial-of-"," service attack against an unsuspecting victim.",""," If an endpoint skips validation of a peer address as described above,"," it does not need to limit its sending rate."]},{"id":"section-9.3.2","title":"On-Path Address Spoofing","lines":[" An on-path attacker could cause a spurious connection migration by"," copying and forwarding a packet with a spoofed address such that it"," arrives before the original packet. The packet with the spoofed"," address will be seen to come from a migrating connection, and the"," original packet will be seen as a duplicate and dropped. After a"," spurious migration, validation of the source address will fail"," because the entity at the source address does not have the necessary"," cryptographic keys to read or respond to the PATH_CHALLENGE frame"," that is sent to it even if it wanted to.","",[[[],0," "],[[517,1737,2791],244,"To protect the connection from failing due to such a spurious"]],[[[],0," "],[[517,1737,2791],244,"migration, an endpoint MUST revert to using the last validated peer"]],[[[],0," "],[[517,1737,2791],244,"address when validation of a new peer address fails."],[[],0," Additionally,"]]," receipt of packets with higher packet numbers from the legitimate"," peer address will trigger another connection migration. This will"," cause the validation of the address of the spurious migration to be"," abandoned, thus containing migrations initiated by the attacker"," injecting a single packet.","",[[[],0," "],[[518,1736,2759],244,"If an endpoint has no state about the last validated peer address, it"]],[[[],0," "],[[518,1736,2759],244,"MUST close the connection silently by discarding all connection"]],[[[],0," "],[[518,1736,2759],244,"state."],[[],0," This results in new packets on the connection being handled"]],[[[],0," generically. "],[[519,2303],112,"For instance, an endpoint MAY send a Stateless Reset in"]],[[[],0," "],[[519,2303],112,"response to any further incoming packets."]]],"requirements":[517,518,519]},{"id":"section-9.3.3","title":"Off-Path Packet Forwarding","lines":[" An off-path attacker that can observe packets might forward copies of"," genuine packets to endpoints. If the copied packet arrives before"," the genuine packet, this will appear as a NAT rebinding. Any genuine"," packet will be discarded as a duplicate. If the attacker is able to"," continue forwarding packets, it might be able to cause migration to a"," path via the attacker. This places the attacker on-path, giving it"," the ability to observe or drop all subsequent packets.",""," This style of attack relies on the attacker using a path that has"," approximately the same characteristics as the direct path between"," endpoints. The attack is more reliable if relatively few packets are"," sent or if packet loss coincides with the attempted attack.",""," A non-probing packet received on the original path that increases the"," maximum received packet number will cause the endpoint to move back"," to that path. Eliciting packets on this path increases the"," likelihood that the attack is unsuccessful. Therefore, mitigation of"," this attack relies on triggering the exchange of packets.","",[[[],0," "],[[520,1939,2142,2731],244,"In response to an apparent migration, endpoints MUST validate the"]],[[[],0," "],[[520,1939,2142,2731],244,"previously active path using a PATH_CHALLENGE frame."],[[],0," This induces"]]," the sending of new packets on that path. If the path is no longer"," viable, the validation attempt will time out and fail; if the path is"," viable but no longer desired, the validation will succeed but only"," results in probing packets being sent on the path.","",[[[],0," "],[[521,1942,2157,2776],180,"An endpoint that receives a PATH_CHALLENGE on an active path SHOULD"]],[[[],0," "],[[521,1942,2157,2776],180,"send a non-probing packet in response."],[[],0," If the non-probing packet"]]," arrives before any copy made by an attacker, this results in the"," connection being migrated back to the original path. Any subsequent"," migration to another path restarts this entire process.",""," This defense is imperfect, but this is not considered a serious"," problem. If the path via the attack is reliably faster than the"," original path despite multiple attempts to use that original path, it"," is not possible to distinguish between an attack and an improvement"," in routing.",""," An endpoint could also use heuristics to improve detection of this"," style of attack. For instance, NAT rebinding is improbable if"," packets were recently received on the old path; similarly, rebinding"," is rare on IPv6 paths. Endpoints can also look for duplicated"," packets. Conversely, a change in connection ID is more likely to"," indicate an intentional migration rather than an attack."],"requirements":[520,521]},{"id":"section-9.4","title":"Loss Detection and Congestion Control","lines":[" The capacity available on the new path might not be the same as the",[[[],0," old path. "],[[526,2055,2061,2780],244,"Packets sent on the old path MUST NOT contribute to"]],[[[],0," "],[[526,2055,2061,2780],244,"congestion control or RTT estimation for the new path."]],"",[[[],0," "],[[527,2056,2062,2781],244,"On confirming a peer's ownership of its new address, an endpoint MUST"]],[[[],0," "],[[527,2056,2062,2781],244,"immediately reset the congestion controller and round-trip time"]],[[[],0," "],[[527,2056,2062,2781],244,"estimator for the new path to initial values (see Appendices A.3 and"]],[[[],0," "],[[527,2056,2062,2781],244,"B.3 of [QUIC-RECOVERY]) unless the only change in the peer's address"]],[[[],0," "],[[527,2056,2062,2781],244,"is its port number."],[[],0," "],[[528],96,"Because port-only changes are commonly the"]],[[[],0," "],[[528],96,"result of NAT rebinding or other middlebox activity, the endpoint MAY"]],[[[],0," "],[[528],96,"instead retain its congestion control state and round-trip estimate"]],[[[],0," "],[[528],96,"in those cases instead of reverting to initial values."],[[],0," In cases"]]," where congestion control state retained from an old path is used on a"," new path with substantially different characteristics, a sender could"," transmit too aggressively until the congestion controller and the RTT"," estimator have adapted. Generally, implementations are advised to be"," cautious when using previous values on a new path.",""," There could be apparent reordering at the receiver when an endpoint"," sends data and probes from/to multiple addresses during the migration"," period, since the two resulting paths could have different round-trip"," times. A receiver of packets on multiple paths will still send ACK"," frames covering all received packets.",""," While multiple paths might be used during connection migration, a"," single congestion control context and a single loss recovery context"," (as described in [QUIC-RECOVERY]) could be adequate. For instance,"," an endpoint might delay switching to a new congestion control context"," until it is confirmed that an old path is no longer needed (such as"," the case described in Section 9.3.3).",""," A sender can make exceptions for probe packets so that their loss"," detection is independent and does not unduly cause the congestion"," controller to reduce its sending rate. An endpoint might set a"," separate timer when a PATH_CHALLENGE is sent, which is canceled if"," the corresponding PATH_RESPONSE is received. If the timer fires"," before the PATH_RESPONSE is received, the endpoint might send a new"," PATH_CHALLENGE and restart the timer for a longer period of time.",[[[],0," "],[[529,1938,1940,2783],244,"This timer SHOULD be set as described in Section 6.2.1 of"]],[[[],0," "],[[529,1938,1940,2783],244,"[QUIC-RECOVERY] and MUST NOT be more aggressive."]]],"requirements":[526,527,528,529]},{"id":"section-9.5","title":"Privacy Implications of Connection Migration","lines":[" Using a stable connection ID on multiple network paths would allow a"," passive observer to correlate activity between those paths. An"," endpoint that moves between networks might not wish to have their"," activity correlated by any entity other than their peer, so different"," connection IDs are used when sending from different local addresses,"," as discussed in Section 5.1. For this to be effective, endpoints"," need to ensure that connection IDs they provide cannot be linked by"," any other entity.","",[[[],0," "],[[530,1930,1986],112,"At any time, endpoints MAY change the Destination Connection ID they"]],[[[],0," "],[[530,1930,1986],112,"transmit with to a value that has not been used on another path."]],"",[[[],0," "],[[531,1931,2734],244,"An endpoint MUST NOT reuse a connection ID when sending from more"]],[[[],0," "],[[531,1931,2734],244,"than one local address -- for example, when initiating connection"]],[[[],0," "],[[531,1931,2734],244,"migration as described in Section 9.2 or when probing a new network"]],[[[],0," "],[[531,1931,2734],244,"path as described in Section 9.1."]],"",[[[],0," "],[[532,1932,2735],244,"Similarly, an endpoint MUST NOT reuse a connection ID when sending to"]],[[[],0," "],[[532,1932,2735],244,"more than one destination address."],[[],0," "],[[533,1933],112,"Due to network changes outside"]],[[[],0," "],[[533,1933],112,"the control of its peer, an endpoint might receive packets from a new"]],[[[],0," "],[[533,1933],112,"source address with the same Destination Connection ID field value,"]],[[[],0," "],[[533,1933],112,"in which case it MAY continue to use the current connection ID with"]],[[[],0," "],[[533,1933],112,"the new remote address while still sending from the same local"]],[[[],0," "],[[533,1933],112,"address."]],""," These requirements regarding connection ID reuse apply only to the"," sending of packets, as unintentional changes in path without a change"," in connection ID are possible. For example, after a period of"," network inactivity, NAT rebinding might cause packets to be sent on a"," new path when the client resumes sending. An endpoint responds to"," such an event as described in Section 9.3.",""," Using different connection IDs for packets sent in both directions on"," each new network path eliminates the use of the connection ID for"," linking packets from the same connection across different network"," paths. Header protection ensures that packet numbers cannot be used"," to correlate activity. This does not prevent other properties of"," packets, such as timing and size, from being used to correlate"," activity.","",[[[],0," "],[[534,2049,2737],180,"An endpoint SHOULD NOT initiate migration with a peer that has"]],[[[],0," "],[[534,2049,2737],180,"requested a zero-length connection ID, because traffic over the new"]],[[[],0," "],[[534,2049,2737],180,"path might be trivially linkable to traffic over the old one."],[[],0," If the"]]," server is able to associate packets with a zero-length connection ID"," to the right connection, it means that the server is using other"," information to demultiplex packets. For example, a server might"," provide a unique address to every client -- for instance, using HTTP"," alternative services [ALTSVC]. Information that might allow correct"," routing of packets across multiple network paths will also allow"," activity on those paths to be linked by entities other than the peer.",""," A client might wish to reduce linkability by switching to a new"," connection ID, source UDP port, or IP address (see [RFC8981]) when"," sending traffic after a period of inactivity. Changing the address"," from which it sends packets at the same time might cause the server"," to detect a connection migration. This ensures that the mechanisms"," that support migration are exercised even for clients that do not",[[[],0," experience NAT rebindings or genuine migrations. "],[[535,1429],176,"Changing address"]],[[[],0," "],[[535,1429],176,"can cause a peer to reset its congestion control state (see"]],[[[],0," "],[[535,1429],176,"Section 9.4), so addresses SHOULD only be changed infrequently."]],""," An endpoint that exhausts available connection IDs cannot probe new"," paths or initiate migration, nor can it respond to probes or attempts",[[[],0," by its peer to migrate. "],[[536,1976,2725],180,"To ensure that migration is possible and"]],[[[],0," "],[[536,1976,2725],180,"packets sent on different paths cannot be correlated, endpoints"]],[[[],0," "],[[536,1976,2725],180,"SHOULD provide new connection IDs before peers migrate; see"]],[[[],0," "],[[536,1976,2725],180,"Section 5.1.1."],[[],0," If a peer might have exhausted available connection"]]," IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in"," all packets sent on a new network path."],"requirements":[530,531,532,533,534,535,536]},{"id":"section-9.6","title":"Server's Preferred Address","lines":[" QUIC allows servers to accept connections on one IP address and"," attempt to transfer these connections to a more preferred address"," shortly after the handshake. This is particularly useful when"," clients initially connect to an address shared by multiple servers"," but would prefer to use a unicast address to ensure connection"," stability. This section describes the protocol for migrating a"," connection to a preferred server address.",""," Migrating a connection to a new server address mid-connection is not",[[[],0," supported by the version of QUIC specified in this document. "],[[554,2305],176,"If a"]],[[[],0," "],[[554,2305],176,"client receives packets from a new server address when the client has"]],[[[],0," "],[[554,2305],176,"not initiated a migration to that address, the client SHOULD discard"]],[[[],0," "],[[554,2305],176,"these packets."]]],"requirements":[554]},{"id":"section-9.6.1","title":"Communicating a Preferred Address","lines":[" A server conveys a preferred address by including the"," preferred_address transport parameter in the TLS handshake.","",[[[],0," "],[[537,1426],112,"Servers MAY communicate a preferred address of each address family"]],[[[],0," "],[[537,1426],112,"(IPv4 and IPv6) to allow clients to pick the one most suited to their"]],[[[],0," "],[[537,1426],112,"network attachment."]],"",[[[],0," "],[[538,1428,1730,2743,3097],180,"Once the handshake is confirmed, the client SHOULD select one of the"]],[[[],0," "],[[538,1428,1730,2743,3097],180,"two addresses provided by the server and initiate path validation"]],[[[],0," "],[[538,1428,1730,2743,3097],180,"(see Section 8.2)."],[[],0," A client constructs packets using any previously"]]," unused active connection ID, taken from either the preferred_address"," transport parameter or a NEW_CONNECTION_ID frame.","",[[[],0," "],[[539,1817,2052,2057,2746],180,"As soon as path validation succeeds, the client SHOULD begin sending"]],[[[],0," "],[[539,1817,2052,2057,2746],180,"all future packets to the new server address using the new connection"]],[[[],0," "],[[539,1817,2052,2057,2746],180,"ID and discontinue use of the old server address."],[[],0," "],[[540,1738,2751],244,"If path validation"]],[[[],0," "],[[540,1738,2751],244,"fails, the client MUST continue sending all future packets to the"]],[[[],0," "],[[540,1738,2751],244,"server's original IP address."]]],"requirements":[537,538,539,540]},{"id":"section-9.6.2","title":"Migration to a Preferred Address","lines":[[[[],0," "],[[541,1728,2051,2745],244,"A client that migrates to a preferred address MUST validate the"]],[[[],0," "],[[541,1728,2051,2745],244,"address it chooses before migrating; see Section 21.5.3."]],""," A server might receive a packet addressed to its preferred IP address"," at any time after it accepts a connection. If this packet contains a"," PATH_CHALLENGE frame, the server sends a packet containing a",[[[],0," PATH_RESPONSE frame as per Section 8.2. "],[[542,2149],240,"The server MUST send non-"]],[[[],0," "],[[542,2149],240,"probing packets from its original address until it receives a non-"]],[[[],0," "],[[542,2149],240,"probing packet from the client at its preferred address and until the"]],[[[],0," "],[[542,2149],240,"server has validated the new path."]],"",[[[],0," "],[[543,2138,2775],244,"The server MUST probe on the path toward the client from its"]],[[[],0," "],[[543,2138,2775],244,"preferred address."],[[],0," This helps to guard against spurious migration"]]," initiated by an attacker.",""," Once the server has completed its path validation and has received a"," non-probing packet with a new largest packet number on its preferred"," address, the server begins sending non-probing packets to the client",[[[],0," exclusively from its preferred IP address. "],[[544,1808,1820,1834,1840,2054,2752,2753],180,"The server SHOULD drop"]],[[[],0," "],[[544,1808,1820,1834,1840,2054,2752,2753],180,"newer packets for this connection that are received on the old IP"]],[[[],0," "],[[544,1808,1820,1834,1840,2054,2752,2753],180,"address."],[[],0," "],[[545],96,"The server MAY continue to process delayed packets that are"]],[[[],0," "],[[545],96,"received on the old IP address."]],""," The addresses that a server provides in the preferred_address"," transport parameter are only valid for the connection in which they",[[[],0," are provided. "],[[546,1726],240,"A client MUST NOT use these for other connections,"]],[[[],0," "],[[546,1726],240,"including connections that are resumed from the current connection."]]],"requirements":[541,542,543,544,545,546]},{"id":"section-9.6.3","title":"Interaction of Client Migration and Preferred Address","lines":[" A client might need to perform a connection migration before it has",[[[],0," migrated to the server's preferred address. "],[[547,1729,2749],180,"In this case, the client"]],[[[],0," "],[[547,1729,2749],180,"SHOULD perform path validation to both the original and preferred"]],[[[],0," "],[[547,1729,2749],180,"server address from the client's new address concurrently."]],"",[[[],0," "],[[548,1946,2747,2748],244,"If path validation of the server's preferred address succeeds, the"]],[[[],0," "],[[548,1946,2747,2748],244,"client MUST abandon validation of the original address and migrate to"]],[[[],0," "],[[548,1946,2747,2748],244,"using the server's preferred address."],[[],0," "],[[549,2750],100,"If path validation of the"]],[[[],0," "],[[549,2750],100,"server's preferred address fails but validation of the server's"]],[[[],0," "],[[549,2750],100,"original address succeeds, the client MAY migrate to its new address"]],[[[],0," "],[[549,2750],100,"and continue sending to the server's original address."]],"",[[[],0," "],[[550],224,"If packets received at the server's preferred address have a"]],[[[],0," "],[[550],224,"different source address than observed from the client during the"]],[[[],0," "],[[550],224,"handshake, the server MUST protect against potential attacks as"]],[[[],0," "],[[550],224,"described in Sections 9.3.1 and 9.3.2."],[[],0," In addition to intentional"]]," simultaneous migration, this might also occur because the client's"," access network used a different NAT binding for the server's"," preferred address.","",[[[],0," "],[[551,2139,2765],180,"Servers SHOULD initiate path validation to the client's new address"]],[[[],0," "],[[551,2139,2765],180,"upon receiving a probe packet from a different address; see"]],[[[],0," "],[[551,2139,2765],180,"Section 8."]],"",[[[],0," "],[[552,2288,2930],180,"A client that migrates to a new address SHOULD use a preferred"]],[[[],0," "],[[552,2288,2930],180,"address from the same address family for the server."]],""," The connection ID provided in the preferred_address transport",[[[],0," parameter is not specific to the addresses that are provided. "],[[553,1727],112,"This"]],[[[],0," "],[[553,1727],112,"connection ID is provided to ensure that the client has a connection"]],[[[],0," "],[[553,1727],112,"ID available for migration, but the client MAY use this connection ID"]],[[[],0," "],[[553,1727],112,"on any path."]]],"requirements":[547,548,549,550,551,552,553]},{"id":"section-9.7","title":"Use of IPv6 Flow Label and Migration","lines":[[[[],0," "],[[555,1595,3103],180,"Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label"]],[[[],0," "],[[555,1595,3103],180,"in compliance with [RFC6437], unless the local API does not allow"]],[[[],0," "],[[555,1595,3103],180,"setting IPv6 flow labels."]],"",[[[],0," "],[[556,1596],240,"The flow label generation MUST be designed to minimize the chances of"]],[[[],0," "],[[556,1596],240,"linkability with a previously used flow label, as a stable flow label"]],[[[],0," "],[[556,1596],240,"would enable correlating activity on multiple paths; see Section 9.5."]],""," [RFC6437] suggests deriving values using a pseudorandom function to"," generate flow labels. Including the Destination Connection ID field"," in addition to source and destination addresses when generating flow"," labels ensures that changes are synchronized with changes in other"," observable identifiers. A cryptographic hash function that combines"," these inputs with a local secret is one way this might be"," implemented."],"requirements":[555,556]},{"id":"section-10","title":"Connection Termination","lines":[" An established QUIC connection can be terminated in one of three"," ways:",""," * idle timeout (Section 10.1)",""," * immediate close (Section 10.2)",""," * stateless reset (Section 10.3)","",[[[],0," "],[[90,1735],112,"An endpoint MAY discard connection state if it does not have a"]],[[[],0," "],[[90,1735],112,"validated path on which it can send packets; see Section 8.2."]]],"requirements":[90]},{"id":"section-10.1","title":"Idle Timeout","lines":[[[[],0," "],[[1732,2695],20,"If a max_idle_timeout is specified by either endpoint in its"]],[[[],0," "],[[1732,2695],20,"transport parameters (Section 18.2), the connection is silently"]],[[[],0," "],[[1732,2695],20,"closed and its state is discarded when it remains idle for longer"]],[[[],0," "],[[1732,2695],20,"than the minimum of the max_idle_timeout value advertised by both"]],[[[],0," "],[[1732,2695],20,"endpoints."]],""," Each endpoint advertises a max_idle_timeout, but the effective value"," at an endpoint is computed as the minimum of the two advertised"," values (or the sole advertised value, if only one endpoint advertises"," a non-zero value). By announcing a max_idle_timeout, an endpoint"," commits to initiating an immediate close (Section 10.2) if it"," abandons the connection prior to the effective value.","",[[[],0," "],[[2069,2696,2698],20,"An endpoint restarts its idle timer when a packet from its peer is"]],[[[],0," "],[[2069,2696,2698],20,"received and processed successfully."],[[],0," "],[[2070,2697],20,"An endpoint also restarts its"]],[[[],0," "],[[2070,2697],20,"idle timer when sending an ack-eliciting packet if no other ack-"]],[[[],0," "],[[2070,2697],20,"eliciting packets have been sent since last receiving and processing"]],[[[],0," "],[[2070,2697],20,"a packet."],[[],0," Restarting this timer when sending a packet ensures that"]]," connections are not closed after new activity is initiated.","",[[[],0," "],[[43,2174,2694],244,"To avoid excessively small idle timeout periods, endpoints MUST"]],[[[],0," "],[[43,2174,2694],244,"increase the idle timeout period to be at least three times the"]],[[[],0," "],[[43,2174,2694],244,"current Probe Timeout (PTO)."],[[],0," This allows for multiple PTOs to"]]," expire, and therefore multiple probes to be sent and lost, prior to"," idle timeout."],"requirements":[43]},{"id":"section-10.1.1","title":"Liveness Testing","lines":[" An endpoint that sends packets close to the effective timeout risks"," having them be discarded at the peer, since the idle timeout period"," might have expired at the peer before these packets arrive.",""," An endpoint can send a PING or another ack-eliciting frame to test"," the connection for liveness if the peer could time out soon, such as"," within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially"," useful if any available application data cannot be safely retried."," Note that the application determines what data is safe to retry."]},{"id":"section-10.1.2","title":"Deferring Idle Timeout","lines":[" An endpoint might need to send ack-eliciting packets to avoid an idle"," timeout if it is expecting response data but does not have or is"," unable to send application data.",""," An implementation of QUIC might provide applications with an option"," to defer an idle timeout. This facility could be used when the"," application wishes to avoid losing state that has been associated"," with an open connection but does not expect to exchange application"," data for some time. With this option, an endpoint could send a PING"," frame (Section 19.2) periodically, which will cause the peer to"," restart its idle timeout period. Sending a packet containing a PING"," frame restarts the idle timeout for this endpoint also if this is the"," first ack-eliciting packet sent since receiving a packet. Sending a"," PING frame causes the peer to respond with an acknowledgment, which"," also restarts the idle timeout for the endpoint.","",[[[],0," "],[[27,42],162,"Application protocols that use QUIC SHOULD provide guidance on when"]],[[[],0," "],[[27,42],162,"deferring an idle timeout is appropriate."],[[],0," Unnecessary sending of"]]," PING frames could have a detrimental effect on performance.",""," A connection will time out if no packets are sent or received for a"," period longer than the time negotiated using the max_idle_timeout"," transport parameter; see Section 10. However, state in middleboxes"," might time out earlier than that. Though REQ-5 in [RFC4787]"," recommends a 2-minute timeout interval, experience shows that sending"," packets every 30 seconds is necessary to prevent the majority of"," middleboxes from losing state for UDP flows [GATEWAY]."],"requirements":[42]},{"id":"section-10.2","title":"Immediate Close","lines":[" An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to"," terminate the connection immediately. A CONNECTION_CLOSE frame"," causes all streams to immediately become closed; open streams can be"," assumed to be implicitly reset.",""," After sending a CONNECTION_CLOSE frame, an endpoint immediately"," enters the closing state; see Section 10.2.1. After receiving a"," CONNECTION_CLOSE frame, endpoints enter the draining state; see"," Section 10.2.2.",""," Violations of the protocol lead to an immediate close.",""," An immediate close can be used after an application protocol has"," arranged to close a connection. This might be after the application"," protocol negotiates a graceful shutdown. The application protocol"," can exchange messages that are needed for both application endpoints"," to agree that the connection can be closed, after which the"," application requests that QUIC close the connection. When QUIC"," consequently closes the connection, a CONNECTION_CLOSE frame with an"," application-supplied error code will be used to signal closure to the"," peer.","",[[[],0," "],[[1998,1999],16,"The closing and draining connection states exist to ensure that"]],[[[],0," "],[[1998,1999],16,"connections close cleanly and that delayed or reordered packets are"]],[[[],0," "],[[1998,1999],16,"properly discarded. "],[[63,1998,1999,2709,2710],180,"These states SHOULD persist for at least three"]],[[[],0," "],[[63,1998,1999,2709,2710],180,"times the current PTO interval as defined in [QUIC-RECOVERY]."]],""," Disposing of connection state prior to exiting the closing or"," draining state could result in an endpoint generating a Stateless"," Reset unnecessarily when it receives a late-arriving packet.",[[[],0," "],[[64],96,"Endpoints that have some alternative means to ensure that late-"]],[[[],0," "],[[64],96,"arriving packets do not induce a response, such as those that are"]],[[[],0," "],[[64],96,"able to close the UDP socket, MAY end these states earlier to allow"]],[[[],0," "],[[64],96,"for faster resource recovery."],[[],0," "],[[65,2211,2958,2959],180,"Servers that retain an open socket for"]],[[[],0," "],[[65,2211,2958,2959],180,"accepting new connections SHOULD NOT end the closing or draining"]],[[[],0," "],[[65,2211,2958,2959],180,"state early."]],"",[[[],0," "],[[66,2212,2338,2895],180,"Once its closing or draining state ends, an endpoint SHOULD discard"]],[[[],0," "],[[66,2212,2338,2895],180,"all connection state."],[[],0," "],[[67,2302],112,"The endpoint MAY send a Stateless Reset in"]],[[[],0," "],[[67,2302],112,"response to any further incoming packets belonging to this"]],[[[],0," "],[[67,2302],112,"connection."]]],"requirements":[63,64,65,66,67]},{"id":"section-10.2.1","title":"Closing Connection State","lines":[" An endpoint enters the closing state after initiating an immediate"," close.",""," In the closing state, an endpoint retains only enough information to"," generate a packet containing a CONNECTION_CLOSE frame and to identify"," packets as belonging to the connection. An endpoint in the closing"," state sends a packet containing a CONNECTION_CLOSE frame in response"," to any incoming packet that it attributes to the connection.","",[[[],0," "],[[44,1695,2700],180,"An endpoint SHOULD limit the rate at which it generates packets in"]],[[[],0," "],[[44,1695,2700],180,"the closing state."],[[],0," For instance, an endpoint could wait for a"]]," progressively increasing number of received packets or amount of time"," before responding to received packets.","",[[[],0," "],[[45],96,"An endpoint's selected connection ID and the QUIC version are"]],[[[],0," "],[[45],96,"sufficient information to identify packets for a closing connection;"]],[[[],0," "],[[45],96,"the endpoint MAY discard all other connection state."],[[],0," An endpoint"]],[[[],0," that is closing is not required to process any received frame. "],[[46],96,"An"]],[[[],0," "],[[46],96,"endpoint MAY retain packet protection keys for incoming packets to"]],[[[],0," "],[[46],96,"allow it to read and process a CONNECTION_CLOSE frame."]],"",[[[],0," "],[[47],96,"An endpoint MAY drop packet protection keys when entering the closing"]],[[[],0," "],[[47],96,"state and send a packet containing a CONNECTION_CLOSE frame in"]],[[[],0," "],[[47],96,"response to any UDP datagram that is received."],[[],0," However, an endpoint"]]," that discards packet protection keys cannot identify and discard",[[[],0," invalid packets. "],[[48,1692,2106,2702],244,"To avoid being used for an amplification attack,"]],[[[],0," "],[[48,1692,2106,2702],244,"such endpoints MUST limit the cumulative size of packets it sends to"]],[[[],0," "],[[48,1692,2106,2702],244,"three times the cumulative size of the packets that are received and"]],[[[],0," "],[[48,1692,2106,2702],244,"attributed to the connection."],[[],0," "],[[49],96,"To minimize the state that an endpoint"]],[[[],0," "],[[49],96,"maintains for a closing connection, endpoints MAY send the exact same"]],[[[],0," "],[[49],96,"packet in response to any received packet."]],""," | Note: Allowing retransmission of a closing packet is an"," | exception to the requirement that a new packet number be used"," | for each packet; see Section 12.3. Sending new packet numbers"," | is primarily of advantage to loss recovery and congestion"," | control, which are not expected to be relevant for a closed"," | connection. Retransmitting the final packet requires less"," | state.",""," While in the closing state, an endpoint could receive packets from a"," new source address, possibly indicating a connection migration; see",[[[],0," Section 9. "],[[50,1693,2107,2703],244,"An endpoint in the closing state MUST either discard"]],[[[],0," "],[[50,1693,2107,2703],244,"packets received from an unvalidated address or limit the cumulative"]],[[[],0," "],[[50,1693,2107,2703],244,"size of packets it sends to an unvalidated address to three times the"]],[[[],0," "],[[50,1693,2107,2703],244,"size of packets it receives from that address."]],""," An endpoint is not expected to handle key updates when it is closing"," (Section 6 of [QUIC-TLS]). A key update might prevent the endpoint"," from moving from the closing state to the draining state, as the"," endpoint will not be able to process subsequently received packets,"," but it otherwise has no impact."],"requirements":[44,45,46,47,48,49,50]},{"id":"section-10.2.2","title":"Draining Connection State","lines":[" The draining state is entered once an endpoint receives a"," CONNECTION_CLOSE frame, which indicates that its peer is closing or",[[[],0," draining. "],[[51,1740,2957],244,"While otherwise identical to the closing state, an"]],[[[],0," "],[[51,1740,2957],244,"endpoint in the draining state MUST NOT send any packets."],[[],0," Retaining"]]," packet protection keys is unnecessary once a connection is in the"," draining state.","",[[[],0," "],[[52],96,"An endpoint that receives a CONNECTION_CLOSE frame MAY send a single"]],[[[],0," "],[[52],96,"packet containing a CONNECTION_CLOSE frame before entering the"]],[[[],0," "],[[52],96,"draining state, using a NO_ERROR code if appropriate."],[[],0," "],[[53,2082,2956],244,"An endpoint"]],[[[],0," "],[[53,2082,2956],244,"MUST NOT send further packets."],[[],0," Doing so could result in a constant"]]," exchange of CONNECTION_CLOSE frames until one of the endpoints exits"," the closing state.","",[[[],0," "],[[54],96,"An endpoint MAY enter the draining state from the closing state if it"]],[[[],0," "],[[54],96,"receives a CONNECTION_CLOSE frame, which indicates that the peer is"]],[[[],0," "],[[54],96,"also closing or draining."],[[],0," In this case, the draining state ends when"]]," the closing state would have ended. In other words, the endpoint"," uses the same end time but ceases transmission of any packets on this"," connection."],"requirements":[51,52,53,54]},{"id":"section-10.2.3","title":"Immediate Close during the Handshake","lines":[" When sending a CONNECTION_CLOSE frame, the goal is to ensure that the"," peer will process the frame. Generally, this means sending the frame"," in a packet with the highest level of packet protection to avoid the",[[[],0," packet being discarded. "],[[55,2101,2145,2704,2830],244,"After the handshake is confirmed (see"]],[[[],0," "],[[55,2101,2145,2704,2830],244,"Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any"]],[[[],0," "],[[55,2101,2145,2704,2830],244,"CONNECTION_CLOSE frames in a 1-RTT packet."],[[],0," "],[[56,2104],112,"However, prior to"]],[[[],0," "],[[56,2104],112,"confirming the handshake, it is possible that more advanced packet"]],[[[],0," "],[[56,2104],112,"protection keys are not available to the peer, so another"]],[[[],0," "],[[56,2104],112,"CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower"]],[[[],0," "],[[56,2104],112,"packet protection level."],[[],0," More specifically:"]],""," * A client will always know whether the server has Handshake keys"," (see Section 17.2.2.1), but it is possible that a server does not",[[[],0," know whether the client has Handshake keys. "],[[57,2105,2717],180,"Under these"]],[[[],0," "],[[57,2105,2717],180,"circumstances, a server SHOULD send a CONNECTION_CLOSE frame in"]],[[[],0," "],[[57,2105,2717],180,"both Handshake and Initial packets to ensure that at least one of"]],[[[],0," "],[[57,2105,2717],180,"them is processable by the client."]],""," * A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet"," cannot be assured that the server has accepted 0-RTT. Sending a"," CONNECTION_CLOSE frame in an Initial packet makes it more likely"," that the server can receive the close signal, even if the"," application error code might not be received.","",[[[],0," "],[[58,2102,2719],180,"* Prior to confirming the handshake, a peer might be unable to"]],[[[],0," "],[[58,2102,2719],180,"process 1-RTT packets, so an endpoint SHOULD send a"]],[[[],0," "],[[58,2102,2719],180,"CONNECTION_CLOSE frame in both Handshake and 1-RTT packets."],[[],0," "],[[],0,"A"]],[[[],0," "],[[59,2103,2720],180,"server SHOULD also send a CONNECTION_CLOSE frame in an Initial"]],[[[],0," "],[[59,2103,2720],180,"packet."]],""," Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake"," packet could expose application state or be used to alter application",[[[],0," state. "],[[60,2098,2705,2707],244,"A CONNECTION_CLOSE of type 0x1d MUST be replaced by a"]],[[[],0," "],[[60,2098,2705,2707],244,"CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or"]],[[[],0," "],[[60,2098,2705,2707],244,"Handshake packets."],[[],0," Otherwise, information about the application"]],[[[],0," state might be revealed. "],[[61,2099,2706,2708],244,"Endpoints MUST clear the value of the"]],[[[],0," "],[[61,2099,2706,2708],244,"Reason Phrase field and SHOULD use the APPLICATION_ERROR code when"]],[[[],0," "],[[61,2099,2706,2708],244,"converting to a CONNECTION_CLOSE of type 0x1c."]],""," CONNECTION_CLOSE frames sent in multiple packet types can be"," coalesced into a single UDP datagram; see Section 12.2.",""," An endpoint can send a CONNECTION_CLOSE frame in an Initial packet."," This might be in response to unauthenticated information received in"," Initial or Handshake packets. Such an immediate close might expose"," legitimate connections to a denial of service. QUIC does not include"," defensive measures for on-path attacks during the handshake; see"," Section 21.2. However, at the cost of reducing feedback about errors"," for legitimate peers, some forms of denial of service can be made"," more difficult for an attacker if endpoints discard illegal packets",[[[],0," rather than terminating a connection with CONNECTION_CLOSE. "],[[62,1705],112,"For this"]],[[[],0," "],[[62,1705],112,"reason, endpoints MAY discard packets rather than immediately close"]],[[[],0," "],[[62,1705],112,"if errors are detected in packets that lack authentication."]],""," An endpoint that has not established state, such as a server that"," detects an error in an Initial packet, does not enter the closing"," state. An endpoint that has no state for the connection does not"," enter a closing or draining period on sending a CONNECTION_CLOSE"," frame."],"requirements":[55,56,57,58,59,60,61,62]},{"id":"section-10.3","title":"Stateless Reset","lines":[" A stateless reset is provided as an option of last resort for an"," endpoint that does not have access to the state of a connection. A"," crash or outage might result in peers continuing to send data to an",[[[],0," endpoint that is unable to properly continue the connection. "],[[80,2279],112,"An"]],[[[],0," "],[[80,2279],112,"endpoint MAY send a Stateless Reset in response to receiving a packet"]],[[[],0," "],[[80,2279],112,"that it cannot associate with an active connection."]],""," A stateless reset is not appropriate for indicating errors in active",[[[],0," connections. "],[[81,2004,2716],244,"An endpoint that wishes to communicate a fatal"]],[[[],0," "],[[81,2004,2716],244,"connection error MUST use a CONNECTION_CLOSE frame if it is able."]],""," To support this process, an endpoint issues a stateless reset token,"," which is a 16-byte value that is hard to guess. If the peer"," subsequently receives a Stateless Reset, which is a UDP datagram that"," ends in that stateless reset token, the peer will immediately end the"," connection.",""," A stateless reset token is specific to a connection ID. An endpoint"," issues a stateless reset token by including the value in the"," Stateless Reset Token field of a NEW_CONNECTION_ID frame. Servers"," can also issue a stateless_reset_token transport parameter during the"," handshake that applies to the connection ID that it selected during"," the handshake. These exchanges are protected by encryption, so only"," client and server know their value. Note that clients cannot use the"," stateless_reset_token transport parameter because their transport"," parameters do not have confidentiality protection.",""," Tokens are invalidated when their associated connection ID is retired"," via a RETIRE_CONNECTION_ID frame (Section 19.16).",""," An endpoint that receives packets that it cannot process sends a"," packet in the following layout (see Section 1.3):",""," Stateless Reset {"," Fixed Bits (2) = 1,"," Unpredictable Bits (38..),"," Stateless Reset Token (128),"," }",""," Figure 10: Stateless Reset",""," This design ensures that a Stateless Reset is -- to the extent"," possible -- indistinguishable from a regular packet with a short"," header.",""," A Stateless Reset uses an entire UDP datagram, starting with the",[[[],0," first two bits of the packet header. "],[[82,2285,2945],180,"The remainder of the first byte"]],[[[],0," "],[[82,2285,2945],180,"and an arbitrary number of bytes following it are set to values that"]],[[[],0," "],[[82,2285,2945],180,"SHOULD be indistinguishable from random."],[[],0," The last 16 bytes of the"]]," datagram contain a stateless reset token.",""," To entities other than its intended recipient, a Stateless Reset will"," appear to be a packet with a short header. For the Stateless Reset"," to appear as a valid QUIC packet, the Unpredictable Bits field needs"," to include at least 38 bits of data (or 5 bytes, less the two fixed"," bits).",""," The resulting minimum size of 21 bytes does not guarantee that a"," Stateless Reset is difficult to distinguish from other packets if the",[[[],0," recipient requires the use of a connection ID. "],[[83,1678,1891,3013],180,"To achieve that end,"]],[[[],0," "],[[83,1678,1891,3013],180,"the endpoint SHOULD ensure that all packets it sends are at least 22"]],[[[],0," "],[[83,1678,1891,3013],180,"bytes longer than the minimum connection ID length that it requests"]],[[[],0," "],[[83,1678,1891,3013],180,"the peer to include in its packets, adding PADDING frames as"]],[[[],0," "],[[83,1678,1891,3013],180,"necessary."],[[],0," This ensures that any Stateless Reset sent by the peer is"]],[[[],0," indistinguishable from a valid packet sent to the endpoint. "],[[84,2283,2941],180,"An"]],[[[],0," "],[[84,2283,2941],180,"endpoint that sends a Stateless Reset in response to a packet that is"]],[[[],0," "],[[84,2283,2941],180,"43 bytes or shorter SHOULD send a Stateless Reset that is one byte"]],[[[],0," "],[[84,2283,2941],180,"shorter than the packet it responds to."]],""," These values assume that the stateless reset token is the same length"," as the minimum expansion of the packet protection AEAD. Additional"," unpredictable bytes are necessary if the endpoint could have"," negotiated a packet protection scheme with a larger minimum"," expansion.","",[[[],0," "],[[85,2284,2944,2947],244,"An endpoint MUST NOT send a Stateless Reset that is three times or"]],[[[],0," "],[[85,2284,2944,2947],244,"more larger than the packet it receives to avoid being used for"]],[[[],0," "],[[85,2284,2944,2947],244,"amplification."],[[],0," Section 10.3.3 describes additional limits on"]]," Stateless Reset size.","",[[[],0," "],[[86,2221,2223,2225,2878,2879],244,"Endpoints MUST discard packets that are too small to be valid QUIC"]],[[[],0," "],[[86,2221,2223,2225,2878,2879],244,"packets."],[[],0," To give an example, with the set of AEAD functions defined"]]," in [QUIC-TLS], short header packets that are smaller than 21 bytes"," are never valid.","",[[[],0," "],[[87,2280,2943],244,"Endpoints MUST send Stateless Resets formatted as a packet with a"]],[[[],0," "],[[87,2280,2943],244,"short header."],[[],0," "],[[88,2276,2950],244,"However, endpoints MUST treat any packet ending in a"]],[[[],0," "],[[88,2276,2950],244,"valid stateless reset token as a Stateless Reset, as other QUIC"]],[[[],0," "],[[88,2276,2950],244,"versions might allow the use of a long header."]],"",[[[],0," "],[[89],96,"An endpoint MAY send a Stateless Reset in response to a packet with a"]],[[[],0," "],[[89],96,"long header."],[[],0," Sending a Stateless Reset is not effective prior to the"]]," stateless reset token being available to a peer. In this QUIC"," version, packets with a long header are only used during connection"," establishment. Because the stateless reset token is not available"," until connection establishment is complete or near completion,"," ignoring an unknown packet with a long header might be as effective"," as sending a Stateless Reset.",""," An endpoint cannot determine the Source Connection ID from a packet"," with a short header; therefore, it cannot set the Destination"," Connection ID in the Stateless Reset. The Destination Connection ID"," will therefore differ from the value used in previous packets. A"," random Destination Connection ID makes the connection ID appear to be"," the result of moving to a new connection ID that was provided using a"," NEW_CONNECTION_ID frame; see Section 19.15.",""," Using a randomized connection ID results in two problems:",""," * The packet might not reach the peer. If the Destination"," Connection ID is critical for routing toward the peer, then this"," packet could be incorrectly routed. This might also trigger"," another Stateless Reset in response; see Section 10.3.3. A"," Stateless Reset that is not correctly routed is an ineffective"," error detection and recovery mechanism. In this case, endpoints"," will need to rely on other methods -- such as timers -- to detect"," that the connection has failed.",""," * The randomly generated connection ID can be used by entities other"," than the peer to identify this as a potential Stateless Reset. An"," endpoint that occasionally uses different connection IDs might"," introduce some uncertainty about this.",""," This stateless reset design is specific to QUIC version 1. An"," endpoint that supports multiple versions of QUIC needs to generate a"," Stateless Reset that will be accepted by peers that support any"," version that the endpoint might support (or might have supported"," prior to losing state). Designers of new versions of QUIC need to be"," aware of this and either (1) reuse this design or (2) use a portion"," of the packet other than the last 16 bytes for carrying data."],"requirements":[80,81,82,83,84,85,86,87,88,89]},{"id":"section-10.3.1","title":"Detecting a Stateless Reset","lines":[" An endpoint detects a potential Stateless Reset using the trailing 16"," bytes of the UDP datagram. An endpoint remembers all stateless reset"," tokens associated with the connection IDs and remote addresses for"," datagrams it has recently sent. This includes Stateless Reset Token"," field values from NEW_CONNECTION_ID frames and the server's transport"," parameters but excludes stateless reset tokens associated with"," connection IDs that are either unused or retired. The endpoint"," identifies a received datagram as a Stateless Reset by comparing the"," last 16 bytes of the datagram with all stateless reset tokens"," associated with the remote address on which the datagram was"," received.",""," This comparison can be performed for every inbound datagram.",[[[],0," "],[[68,2315],112,"Endpoints MAY skip this check if any packet from a datagram is"]],[[[],0," "],[[68,2315],112,"successfully processed."],[[],0," "],[[69,2312,2314,2316,2954],244,"However, the comparison MUST be performed"]],[[[],0," "],[[69,2312,2314,2316,2954],244,"when the first packet in an incoming datagram either cannot be"]],[[[],0," "],[[69,2312,2314,2316,2954],244,"associated with a connection or cannot be decrypted."]],"",[[[],0," "],[[70,1748,2592],244,"An endpoint MUST NOT check for any stateless reset tokens associated"]],[[[],0," "],[[70,1748,2592],244,"with connection IDs it has not used or for connection IDs that have"]],[[[],0," "],[[70,1748,2592],244,"been retired."]],"",[[[],0," "],[[71,2278,2951],244,"When comparing a datagram to stateless reset token values, endpoints"]],[[[],0," "],[[71,2278,2951],244,"MUST perform the comparison without leaking information about the"]],[[[],0," "],[[71,2278,2951],244,"value of the token."],[[],0," For example, performing this comparison in"]]," constant time protects the value of individual stateless reset tokens"," from information leakage through timing side channels. Another"," approach would be to store and compare the transformed values of"," stateless reset tokens instead of the raw token values, where the"," transformation is defined as a cryptographically secure pseudorandom"," function using a secret key (e.g., block cipher, Hashed Message"," Authentication Code (HMAC) [RFC2104]). An endpoint is not expected"," to protect information about whether a packet was successfully"," decrypted or the number of valid stateless reset tokens.","",[[[],0," "],[[72,2000,2194,2277,2955],244,"If the last 16 bytes of the datagram are identical in value to a"]],[[[],0," "],[[72,2000,2194,2277,2955],244,"stateless reset token, the endpoint MUST enter the draining period"]],[[[],0," "],[[72,2000,2194,2277,2955],244,"and not send any further packets on this connection."]]],"requirements":[68,69,70,71,72]},{"id":"section-10.3.2","title":"Calculating a Stateless Reset Token","lines":[[[[],0," "],[[73,1847,2219,2952],244,"The stateless reset token MUST be difficult to guess."],[[],0," In order to"]]," create a stateless reset token, an endpoint could randomly generate"," [RANDOM] a secret for every connection that it creates. However,"," this presents a coordination problem when there are multiple"," instances in a cluster or a storage problem for an endpoint that"," might lose state. Stateless reset specifically exists to handle the"," case where state is lost, so this approach is suboptimal.",""," A single static key can be used across all connections to the same"," endpoint by generating the proof using a pseudorandom function that"," takes a static key and the connection ID chosen by the endpoint (see"," Section 5.1) as input. An endpoint could use HMAC [RFC2104] (for"," example, HMAC(static_key, connection_id)) or the HMAC-based Key"," Derivation Function (HKDF) [RFC5869] (for example, using the static"," key as input keying material, with the connection ID as salt). The"," output of this function is truncated to 16 bytes to produce the"," stateless reset token for that connection.",""," An endpoint that loses state can use the same method to generate a"," valid stateless reset token. The connection ID comes from the packet"," that the endpoint receives.",""," This design relies on the peer always sending a connection ID in its"," packets so that the endpoint can use the connection ID from a packet",[[[],0," to reset the connection. "],[[74,2210,2281,2953],244,"An endpoint that uses this design MUST"]],[[[],0," "],[[74,2210,2281,2953],244,"either use the same connection ID length for all connections or"]],[[[],0," "],[[74,2210,2281,2953],244,"encode the length of the connection ID such that it can be recovered"]],[[[],0," "],[[74,2210,2281,2953],244,"without state."],[[],0," In addition, it cannot provide a zero-length"]]," connection ID.",""," Revealing the stateless reset token allows any entity to terminate",[[[],0," the connection, so a value can only be used once. "],[[28,75],226,"This method for"]],[[[],0," "],[[28,75],226,"choosing the stateless reset token means that the combination of"]],[[[],0," "],[[28,75],226,"connection ID and static key MUST NOT be used for another connection."]]," A denial-of-service attack is possible if the same connection ID is"," used by instances that share a static key or if an attacker can cause"," a packet to be routed to an instance that has no state but the same",[[[],0," static key; see Section 21.11. "],[[29,76],226,"A connection ID from a connection"]],[[[],0," "],[[29,76],226,"that is reset by revealing the stateless reset token MUST NOT be"]],[[[],0," "],[[29,76],226,"reused for new connections at nodes that share a static key."]],"",[[[],0," "],[[77,1846,1972,2622,2626,2632],244,"The same stateless reset token MUST NOT be used for multiple"]],[[[],0," "],[[77,1846,1972,2622,2626,2632],244,"connection IDs."],[[],0," "],[[78,1949,1952,1958,1959],112,"Endpoints are not required to compare new values"]],[[[],0," "],[[78,1949,1952,1958,1959],112,"against all previous values, but a duplicate value MAY be treated as"]],[[[],0," "],[[78,1949,1952,1958,1959],112,"a connection error of type PROTOCOL_VIOLATION."]],""," Note that Stateless Resets do not have any cryptographic protection."],"requirements":[73,74,75,76,77,78]},{"id":"section-10.3.3","title":"Looping","lines":[" The design of a Stateless Reset is such that without knowing the"," stateless reset token it is indistinguishable from a valid packet."," For instance, if a server sends a Stateless Reset to another server,"," it might receive another Stateless Reset in response, which could"," lead to an infinite exchange.","",[[[],0," "],[[79,2282,2942,2946,2948,2949],244,"An endpoint MUST ensure that every Stateless Reset that it sends is"]],[[[],0," "],[[79,2282,2942,2946,2948,2949],244,"smaller than the packet that triggered it, unless it maintains state"]],[[[],0," "],[[79,2282,2942,2946,2948,2949],244,"sufficient to prevent looping."],[[],0," In the event of a loop, this results"]]," in packets eventually being too small to trigger a response.",""," An endpoint can remember the number of Stateless Resets that it has"," sent and stop generating new Stateless Resets once a limit is"," reached. Using separate limits for different remote addresses will"," ensure that Stateless Resets can be used to close connections when"," other peers or connections have exhausted limits.",""," A Stateless Reset that is smaller than 41 bytes might be identifiable"," as a Stateless Reset by an observer, depending upon the length of the"," peer's connection IDs. Conversely, not sending a Stateless Reset in"," response to a small packet might result in Stateless Resets not being"," useful in detecting cases of broken connections where only very small"," packets are sent; such failures might only be detected by other"," means, such as timers."],"requirements":[79]},{"id":"section-11","title":"Error Handling","lines":[[[[],0," "],[[96,2002,2715,2723],180,"An endpoint that detects an error SHOULD signal the existence of that"]],[[[],0," "],[[96,2002,2715,2723],180,"error to its peer."],[[],0," Both transport-level and application-level errors"]]," can affect an entire connection; see Section 11.1. Only application-"," level errors can be isolated to a single stream; see Section 11.2.","",[[[],0," "],[[97,2003,2718],180,"The most appropriate error code (Section 20) SHOULD be included in"]],[[[],0," "],[[97,2003,2718],180,"the frame that signals the error."],[[],0," Where this specification"]]," identifies error conditions, it also identifies the error code that"," is used; though these are worded as requirements, different"," implementation strategies might lead to different errors being",[[[],0," reported. "],[[98,2005],112,"In particular, an endpoint MAY use any applicable error"]],[[[],0," "],[[98,2005],112,"code when it detects an error condition; a generic error code (such"]],[[[],0," "],[[98,2005],112,"as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place"]],[[[],0," "],[[98,2005],112,"of specific error codes."]],""," A stateless reset (Section 10.3) is not suitable for any error that",[[[],0," can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. "],[[],0,"A"]],[[[],0," "],[[99,2313,2890],244,"stateless reset MUST NOT be used by an endpoint that has the state"]],[[[],0," "],[[99,2313,2890],244,"necessary to send a frame on the connection."]]],"requirements":[96,97,98,99]},{"id":"section-11.1","title":"Connection Errors","lines":[[[[],0," "],[[91,2001,2714,2722],244,"Errors that result in the connection being unusable, such as an"]],[[[],0," "],[[91,2001,2714,2722],244,"obvious violation of protocol semantics or corruption of state that"]],[[[],0," "],[[91,2001,2714,2722],244,"affects an entire connection, MUST be signaled using a"]],[[[],0," "],[[91,2001,2714,2722],244,"CONNECTION_CLOSE frame (Section 19.19)."]],""," Application-specific protocol errors are signaled using the"," CONNECTION_CLOSE frame with a frame type of 0x1d. Errors that are"," specific to the transport, including all those described in this"," document, are carried in the CONNECTION_CLOSE frame with a frame type"," of 0x1c.","",[[[],0," A CONNECTION_CLOSE frame could be sent in a packet that is lost. "],[[92,1694,2701],180,"An"]],[[[],0," "],[[92,1694,2701],180,"endpoint SHOULD be prepared to retransmit a packet containing a"]],[[[],0," "],[[92,1694,2701],180,"CONNECTION_CLOSE frame if it receives more packets on a terminated"]],[[[],0," "],[[92,1694,2701],180,"connection."],[[],0," Limiting the number of retransmissions and the time over"]]," which this final packet is sent limits the effort expended on"," terminated connections.",""," An endpoint that chooses not to retransmit packets containing a"," CONNECTION_CLOSE frame risks a peer missing the first such packet."," The only mechanism available to an endpoint that continues to receive"," data for a terminated connection is to attempt the stateless reset"," process (Section 10.3).","",[[[],0," "],[[93,1706],112,"As the AEAD for Initial packets does not provide strong"]],[[[],0," "],[[93,1706],112,"authentication, an endpoint MAY discard an invalid Initial packet."]]," Discarding an Initial packet is permitted even where this"," specification otherwise mandates a connection error. An endpoint can"," only discard a packet if it does not process the frames in the packet"," or reverts the effects of any processing. Discarding invalid Initial"," packets might be used to reduce exposure to denial of service; see"," Section 21.2."],"requirements":[91,92,93]},{"id":"section-11.2","title":"Stream Errors","lines":[" If an application-level error affects a single stream but otherwise"," leaves the connection in a recoverable state, the endpoint can send a"," RESET_STREAM frame (Section 19.4) with an appropriate error code to"," terminate just the affected stream.",""," Resetting a stream without the involvement of the application"," protocol could cause the application protocol to enter an",[[[],0," unrecoverable state. "],[[94,1721,2828,2832],244,"RESET_STREAM MUST only be instigated by the"]],[[[],0," "],[[94,1721,2828,2832],244,"application protocol that uses QUIC."]],""," The semantics of the application error code carried in RESET_STREAM"," are defined by the application protocol. Only the application"," protocol is able to cause a stream to be terminated. A local"," instance of the application protocol uses a direct API call, and a"," remote instance uses the STOP_SENDING frame, which triggers an"," automatic RESET_STREAM.","",[[[],0," "],[[30,95],162,"Application protocols SHOULD define rules for handling streams that"]],[[[],0," "],[[30,95],162,"are prematurely canceled by either endpoint."]]],"requirements":[94,95]},{"id":"section-12","title":"Packets and Frames","lines":[" QUIC endpoints communicate by exchanging packets. Packets have"," confidentiality and integrity protection; see Section 12.1. Packets"," are carried in UDP datagrams; see Section 12.2.",""," This version of QUIC uses the long packet header during connection"," establishment; see Section 17.2. Packets with the long header are"," Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake"," (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation"," uses a version-independent packet with a long header; see"," Section 17.2.1.",""," Packets with the short header are designed for minimal overhead and"," are used after a connection is established and 1-RTT keys are"," available; see Section 17.3."]},{"id":"section-12.1","title":"Protected Packets","lines":[" QUIC packets have different levels of cryptographic protection based"," on the type of packet. Details of packet protection are found in"," [QUIC-TLS]; this section includes an overview of the protections that"," are provided.",""," Version Negotiation packets have no cryptographic protection; see"," [QUIC-INVARIANTS].",""," Retry packets use an AEAD function [AEAD] to protect against"," accidental modification.",""," Initial packets use an AEAD function, the keys for which are derived"," using a value that is visible on the wire. Initial packets therefore"," do not have effective confidentiality protection. Initial protection"," exists to ensure that the sender of the packet is on the network"," path. Any entity that receives an Initial packet from a client can"," recover the keys that will allow them to both read the contents of"," the packet and generate Initial packets that will be successfully"," authenticated at either endpoint. The AEAD also protects Initial"," packets against accidental modification.",""," All other packets are protected with keys derived from the"," cryptographic handshake. The cryptographic handshake ensures that"," only the communicating endpoints receive the corresponding keys for"," Handshake, 0-RTT, and 1-RTT packets. Packets protected with 0-RTT"," and 1-RTT keys have strong confidentiality and integrity protection.",""," The Packet Number field that appears in some packet types has"," alternative confidentiality protection that is applied as part of"," header protection; see Section 5.4 of [QUIC-TLS] for details. The"," underlying packet number increases with each packet sent in a given"," packet number space; see Section 12.3 for details."]},{"id":"section-12.2","title":"Coalescing Packets","lines":[" Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake"," (Section 17.2.4) packets contain a Length field that determines the"," end of the packet. The length includes both the Packet Number and"," Payload fields, both of which are confidentiality protected and"," initially of unknown length. The length of the Payload field is"," learned once header protection is removed.",""," Using the Length field, a sender can coalesce multiple QUIC packets"," into one UDP datagram. This can reduce the number of UDP datagrams"," needed to complete the cryptographic handshake and start sending"," data. This can also be used to construct Path Maximum Transmission",[[[],0," Unit (PMTU) probes; see Section 14.4.1. "],[[100,1688,1689,3017],244,"Receivers MUST be able to"]],[[[],0," "],[[100,1688,1689,3017],244,"process coalesced packets."]],""," Coalescing packets in order of increasing encryption levels (Initial,"," 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it"," more likely that the receiver will be able to process all the packets"," in a single pass. A packet with a short header does not include a"," length, so it can only be the last packet included in a UDP datagram.",[[[],0," "],[[101,2160,2559],180,"An endpoint SHOULD include multiple frames in a single packet if they"]],[[[],0," "],[[101,2160,2559],180,"are to be sent at the same encryption level, instead of coalescing"]],[[[],0," "],[[101,2160,2559],180,"multiple packets at the same encryption level."]],"",[[[],0," "],[[102,2311],112,"Receivers MAY route based on the information in the first packet"]],[[[],0," "],[[102,2311],112,"contained in a UDP datagram."],[[],0," "],[[103,2085,2086,2864],244,"Senders MUST NOT coalesce QUIC packets"]],[[[],0," "],[[103,2085,2086,2864],244,"with different connection IDs into a single UDP datagram."],[[],0," "],[[104,1715,2663],180,"Receivers"]],[[[],0," "],[[104,1715,2663],180,"SHOULD ignore any subsequent packets with a different Destination"]],[[[],0," "],[[104,1715,2663],180,"Connection ID than the first packet in the datagram."]],""," Every QUIC packet that is coalesced into a single UDP datagram is",[[[],0," separate and complete. "],[[105,1716,1756,1760,2661,2662],244,"The receiver of coalesced QUIC packets MUST"]],[[[],0," "],[[105,1716,1756,1760,2661,2662],244,"individually process each QUIC packet and separately acknowledge"]],[[[],0," "],[[105,1716,1756,1760,2661,2662],244,"them, as if they were received as the payload of different UDP"]],[[[],0," "],[[105,1716,1756,1760,2661,2662],244,"datagrams."],[[],0," "],[[106,1703,2845],244,"For example, if decryption fails (because the keys are"]],[[[],0," "],[[106,1703,2845],244,"not available or for any other reason), the receiver MAY either"]],[[[],0," "],[[106,1703,2845],244,"discard or buffer the packet for later processing and MUST attempt to"]],[[[],0," "],[[106,1703,2845],244,"process the remaining packets."]],""," Retry packets (Section 17.2.5), Version Negotiation packets"," (Section 17.2.1), and packets with a short header (Section 17.3) do"," not contain a Length field and so cannot be followed by other packets"," in the same UDP datagram. Note also that there is no situation where"," a Retry or Version Negotiation packet is coalesced with another"," packet."],"requirements":[100,101,102,103,104,105,106]},{"id":"section-12.3","title":"Packet Numbers","lines":[" The packet number is an integer in the range 0 to 2^62-1. This"," number is used in determining the cryptographic nonce for packet"," protection. Each endpoint maintains a separate packet number for"," sending and receiving.",""," Packet numbers are limited to this range because they need to be"," representable in whole in the Largest Acknowledged field of an ACK"," frame (Section 19.3). When present in a long or short header,"," however, packet numbers are reduced and encoded in 1 to 4 bytes; see"," Section 17.1.",""," Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5)"," packets do not include a packet number.",""," Packet numbers are divided into three spaces in QUIC:",""," Initial space: All Initial packets (Section 17.2.2) are in this"," space.",""," Handshake space: All Handshake packets (Section 17.2.4) are in this"," space.",""," Application data space: All 0-RTT (Section 17.2.3) and 1-RTT"," (Section 17.3.1) packets are in this space.",""," As described in [QUIC-TLS], each packet type uses different"," protection keys.",""," Conceptually, a packet number space is the context in which a packet"," can be processed and acknowledged. Initial packets can only be sent"," with Initial packet protection keys and acknowledged in packets that"," are also Initial packets. Similarly, Handshake packets are sent at"," the Handshake encryption level and can only be acknowledged in"," Handshake packets.",""," This enforces cryptographic separation between the data sent in the"," different packet number spaces. Packet numbers in each space start",[[[],0," at packet number 0. "],[[107,1778,2562,2565],244,"Subsequent packets sent in the same packet"]],[[[],0," "],[[107,1778,2562,2565],244,"number space MUST increase the packet number by at least one."]],""," 0-RTT and 1-RTT data exist in the same packet number space to make"," loss recovery algorithms easier to implement between the two packet"," types.","",[[[],0," "],[[108,1779,2563,2566],244,"A QUIC endpoint MUST NOT reuse a packet number within the same packet"]],[[[],0," "],[[108,1779,2563,2566],244,"number space in one connection."],[[],0," "],[[109,1776,2574],244,"If the packet number for sending"]],[[[],0," "],[[109,1776,2574],244,"reaches 2^62-1, the sender MUST close the connection without sending"]],[[[],0," "],[[109,1776,2574],244,"a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send"]],[[[],0," "],[[109,1776,2574],244,"a Stateless Reset (Section 10.3) in response to further packets that"]],[[[],0," "],[[109,1776,2574],244,"it receives."]],"",[[[],0," "],[[110,1867,2822],244,"A receiver MUST discard a newly unprotected packet unless it is"]],[[[],0," "],[[110,1867,2822],244,"certain that it has not processed another packet with the same packet"]],[[[],0," "],[[110,1867,2822],244,"number from the same packet number space."],[[],0," "],[[111,1868,2823],244,"Duplicate suppression MUST"]],[[[],0," "],[[111,1868,2823],244,"happen after removing packet protection for the reasons described in"]],[[[],0," "],[[111,1868,2823],244,"Section 9.5 of [QUIC-TLS]."]],""," Endpoints that track all individual packets for the purposes of"," detecting duplicates are at risk of accumulating excessive state."," The data required for detecting duplicates can be limited by"," maintaining a minimum packet number below which all packets are"," immediately dropped. Any minimum needs to account for large"," variations in round-trip time, which includes the possibility that a"," peer might probe network paths with much larger round-trip times; see"," Section 9.",""," Packet number encoding at a sender and decoding at a receiver are"," described in Section 17.1."],"requirements":[107,108,109,110,111]},{"id":"section-12.4","title":"Frames and Frame Types","lines":[" The payload of QUIC packets, after removing packet protection,"," consists of a sequence of complete frames, as shown in Figure 11."," Version Negotiation, Stateless Reset, and Retry packets do not"," contain frames.",""," Packet Payload {"," Frame (8..) ...,"," }",""," Figure 11: QUIC Payload","",[[[],0," "],[[112,1656,2998],244,"The payload of a packet that contains frames MUST contain at least"]],[[[],0," "],[[112,1656,2998],244,"one frame, and MAY contain multiple frames and multiple frame types."]],[[[],0," "],[[113,1662,1673,3000,3007],244,"An endpoint MUST treat receipt of a packet containing no frames as a"]],[[[],0," "],[[113,1662,1673,3000,3007],244,"connection error of type PROTOCOL_VIOLATION."],[[],0," Frames always fit"]]," within a single QUIC packet and cannot span multiple packets.",""," Each frame begins with a Frame Type, indicating its type, followed by"," additional type-dependent fields:",""," Frame {"," Frame Type (i),"," Type-Dependent Fields (..),"," }",""," Figure 12: Generic Frame Layout",""," Table 3 lists and summarizes information about each frame type that"," is defined in this specification. A description of this summary is"," included after the table.",""," +============+======================+===============+======+======+"," | Type Value | Frame Type Name | Definition | Pkts | Spec |"," +============+======================+===============+======+======+"," | 0x00 | PADDING | Section 19.1 | IH01 | NP |"," +------------+----------------------+---------------+------+------+"," | 0x01 | PING | Section 19.2 | IH01 | |"," +------------+----------------------+---------------+------+------+"," | 0x02-0x03 | ACK | Section 19.3 | IH_1 | NC |"," +------------+----------------------+---------------+------+------+"," | 0x04 | RESET_STREAM | Section 19.4 | __01 | |"," +------------+----------------------+---------------+------+------+"," | 0x05 | STOP_SENDING | Section 19.5 | __01 | |"," +------------+----------------------+---------------+------+------+"," | 0x06 | CRYPTO | Section 19.6 | IH_1 | |"," +------------+----------------------+---------------+------+------+"," | 0x07 | NEW_TOKEN | Section 19.7 | ___1 | |"," +------------+----------------------+---------------+------+------+"," | 0x08-0x0f | STREAM | Section 19.8 | __01 | F |"," +------------+----------------------+---------------+------+------+"," | 0x10 | MAX_DATA | Section 19.9 | __01 | |"," +------------+----------------------+---------------+------+------+"," | 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | |"," +------------+----------------------+---------------+------+------+"," | 0x12-0x13 | MAX_STREAMS | Section 19.11 | __01 | |"," +------------+----------------------+---------------+------+------+"," | 0x14 | DATA_BLOCKED | Section 19.12 | __01 | |"," +------------+----------------------+---------------+------+------+"," | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | |"," +------------+----------------------+---------------+------+------+"," | 0x16-0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | |"," +------------+----------------------+---------------+------+------+"," | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P |"," +------------+----------------------+---------------+------+------+"," | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | |"," +------------+----------------------+---------------+------+------+"," | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P |"," +------------+----------------------+---------------+------+------+"," | 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P |"," +------------+----------------------+---------------+------+------+"," | 0x1c-0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N |"," +------------+----------------------+---------------+------+------+"," | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | |"," +------------+----------------------+---------------+------+------+",""," Table 3: Frame Types",""," The format and semantics of each frame type are explained in more"," detail in Section 19. The remainder of this section provides a"," summary of important and general information.",""," The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and"," CONNECTION_CLOSE frames is used to carry other frame-specific flags."," For all other frames, the Frame Type field simply identifies the"," frame.",""," The \"Pkts\" column in Table 3 lists the types of packets that each"," frame type could appear in, indicated by the following characters:",""," I: Initial (Section 17.2.2)",""," H: Handshake (Section 17.2.4)",""," 0: 0-RTT (Section 17.2.3)",""," 1: 1-RTT (Section 17.3.1)",""," ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial"," or Handshake packets.",""," For more details about these restrictions, see Section 12.5. Note",[[[],0," that all frames can appear in 1-RTT packets. "],[[114,1657,1664,3002,3004],244,"An endpoint MUST treat"]],[[[],0," "],[[114,1657,1664,3002,3004],244,"receipt of a frame in a packet type that is not permitted as a"]],[[[],0," "],[[114,1657,1664,3002,3004],244,"connection error of type PROTOCOL_VIOLATION."]],""," The \"Spec\" column in Table 3 summarizes any special rules governing"," the processing or generation of the frame type, as indicated by the"," following characters:",""," N: Packets containing only frames with this marking are not ack-"," eliciting; see Section 13.2.",""," C: Packets containing only frames with this marking do not count"," toward bytes in flight for congestion control purposes; see"," [QUIC-RECOVERY].",""," P: Packets containing only frames with this marking can be used to"," probe new network paths during connection migration; see"," Section 9.1.",""," F: The contents of frames with this marking are flow controlled;"," see Section 4.",""," The \"Pkts\" and \"Spec\" columns in Table 3 do not form part of the IANA"," registry; see Section 22.4.","",[[[],0," "],[[115,1644,1648,2966],244,"An endpoint MUST treat the receipt of a frame of unknown type as a"]],[[[],0," "],[[115,1644,1648,2966],244,"connection error of type FRAME_ENCODING_ERROR."]],""," All frames are idempotent in this version of QUIC. That is, a valid"," frame does not cause undesirable side effects or errors when received"," more than once.",""," The Frame Type field uses a variable-length integer encoding (see",[[[],0," Section 16), with one exception. "],[[116,1642,1645,1647,2963,2964,2965],244,"To ensure simple and efficient"]],[[[],0," "],[[116,1642,1645,1647,2963,2964,2965],244,"implementations of frame parsing, a frame type MUST use the shortest"]],[[[],0," "],[[116,1642,1645,1647,2963,2964,2965],244,"possible encoding."],[[],0," For frame types defined in this document, this"]]," means a single-byte encoding, even though it is possible to encode"," these values as a two-, four-, or eight-byte variable-length integer."," For instance, though 0x4001 is a legitimate two-byte encoding for a"," variable-length integer with a value of 1, PING frames are always"," encoded as a single byte with the value 0x01. This rule applies to",[[[],0," all current and future QUIC frame types. "],[[117],96,"An endpoint MAY treat the"]],[[[],0," "],[[117],96,"receipt of a frame type that uses a longer encoding than necessary as"]],[[[],0," "],[[117],96,"a connection error of type PROTOCOL_VIOLATION."]]],"requirements":[112,113,114,115,116,117]},{"id":"section-12.5","title":"Frames and Number Spaces","lines":[" Some frames are prohibited in different packet number spaces. The"," rules here generalize those of TLS, in that frames associated with"," establishing the connection can usually appear in packets in any"," packet number space, whereas those associated with transferring data"," can only appear in the application data packet number space:","",[[[],0," "],[[118,1679,1684],112,"* PADDING, PING, and CRYPTO frames MAY appear in any packet number"]],[[[],0," "],[[118,1679,1684],112,"space."]],"",[[[],0," "],[[119,1680,1685],112,"* CONNECTION_CLOSE frames signaling errors at the QUIC layer (type"]],[[[],0," "],[[119,1680,1685],112,"0x1c) MAY appear in any packet number space."],[[],0," "],[[120,1654,2994],244,"CONNECTION_CLOSE"]],[[[],0," "],[[120,1654,2994],244,"frames signaling application errors (type 0x1d) MUST only appear"]],[[[],0," "],[[120,1654,2994],244,"in the application data packet number space."]],"",[[[],0," "],[[121,1681,1686],112,"* ACK frames MAY appear in any packet number space but can only"]],[[[],0," "],[[121,1681,1686],112,"acknowledge packets that appeared in that packet number space."]]," However, as noted below, 0-RTT packets cannot contain ACK frames.","",[[[],0," "],[[122,1655,1663,2997,3001],244,"* All other frame types MUST only be sent in the application data"]],[[[],0," "],[[122,1655,1663,2997,3001],244,"packet number space."]],""," Note that it is not possible to send the following frames in 0-RTT"," packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,",[[[],0," PATH_RESPONSE, and RETIRE_CONNECTION_ID. "],[[123,1683],112,"A server MAY treat receipt"]],[[[],0," "],[[123,1683],112,"of these frames in 0-RTT packets as a connection error of type"]],[[[],0," "],[[123,1683],112,"PROTOCOL_VIOLATION."]]],"requirements":[118,119,120,121,122,123]},{"id":"section-13","title":"Packetization and Reliability","lines":[" A sender sends one or more frames in a QUIC packet; see Section 12.4.",""," A sender can minimize per-packet bandwidth and computational costs by",[[[],0," including as many frames as possible in each QUIC packet. "],[[165],96,"A sender"]],[[[],0," "],[[165],96,"MAY wait for a short period of time to collect multiple frames before"]],[[[],0," "],[[165],96,"sending a packet that is not maximally packed, to avoid sending out"]],[[[],0," "],[[165],96,"large numbers of small packets."],[[],0," "],[[166],96,"An implementation MAY use knowledge"]],[[[],0," "],[[166],96,"about application sending behavior or heuristics to determine whether"]],[[[],0," "],[[166],96,"and for how long to wait."],[[],0," This waiting period is an implementation"]]," decision, and an implementation should be careful to delay"," conservatively, since any delay is likely to increase application-"," visible latency.",""," Stream multiplexing is achieved by interleaving STREAM frames from"," multiple streams into one or more QUIC packets. A single QUIC packet"," can include multiple STREAM frames from one or more streams.",""," One of the benefits of QUIC is avoidance of head-of-line blocking"," across multiple streams. When a packet loss occurs, only streams"," with data in that packet are blocked waiting for a retransmission to"," be received, while other streams can continue making progress. Note"," that when data from multiple streams is included in a single QUIC"," packet, loss of that packet blocks all those streams from making"," progress. Implementations are advised to include as few streams as"," necessary in outgoing packets without losing transmission efficiency"," to underfilled packets."],"requirements":[165,166]},{"id":"section-13.1","title":"Packet Processing","lines":[[[[],0," "],[[124,1755,1759,1762,1772,1837,2656,2657,2658],244,"A packet MUST NOT be acknowledged until packet protection has been"]],[[[],0," "],[[124,1755,1759,1762,1772,1837,2656,2657,2658],244,"successfully removed and all frames contained in the packet have been"]],[[[],0," "],[[124,1755,1759,1762,1772,1837,2656,2657,2658],244,"processed."],[[],0," For STREAM frames, this means the data has been enqueued"]]," in preparation to be received by the application protocol, but it"," does not require that data be delivered and consumed.",""," Once the packet has been fully processed, a receiver acknowledges"," receipt by sending one or more ACK frames containing the packet"," number of the received packet.","",[[[],0," "],[[125,1781,2532],180,"An endpoint SHOULD treat receipt of an acknowledgment for a packet it"]],[[[],0," "],[[125,1781,2532],180,"did not send as a connection error of type PROTOCOL_VIOLATION, if it"]],[[[],0," "],[[125,1781,2532],180,"is able to detect the condition."],[[],0," For further discussion of how this"]]," might be achieved, see Section 21.4."],"requirements":[124,125]},{"id":"section-13.2","title":"Generating Acknowledgments","lines":[" Endpoints acknowledge all packets they receive and process. However,"," only ack-eliciting packets cause an ACK frame to be sent within the"," maximum ack delay. Packets that are not ack-eliciting are only"," acknowledged when an ACK frame is sent for other reasons.","",[[[],0," "],[[150,2159,2561],180,"When sending a packet for any reason, an endpoint SHOULD attempt to"]],[[[],0," "],[[150,2159,2561],180,"include an ACK frame if one has not been sent recently."],[[],0," Doing so"]]," helps with timely loss detection at the peer.",""," In general, frequent feedback from a receiver improves loss and"," congestion response, but this has to be balanced against excessive"," load generated by a receiver that sends an ACK frame in response to"," every ack-eliciting packet. The guidance offered below seeks to"," strike this balance."],"requirements":[150]},{"id":"section-13.2.1","title":"Sending ACK Frames","lines":[[[[],0," "],[[126,1763,1773,1838,1872,2577,2580,2583],244,"Every packet SHOULD be acknowledged at least once, and ack-eliciting"]],[[[],0," "],[[126,1763,1773,1838,1872,2577,2580,2583],244,"packets MUST be acknowledged at least once within the maximum delay"]],[[[],0," "],[[126,1763,1773,1838,1872,2577,2580,2583],244,"an endpoint communicated using the max_ack_delay transport parameter;"]],[[[],0," "],[[126,1763,1773,1838,1872,2577,2580,2583],244,"see Section 18.2."],[[],0," max_ack_delay declares an explicit contract: an"]]," endpoint promises to never intentionally delay acknowledgments of an"," ack-eliciting packet by more than the indicated value. If it does,"," any excess accrues to the RTT estimate and could result in spurious"," or delayed retransmissions from the peer. A sender uses the"," receiver's max_ack_delay value in determining timeouts for timer-"," based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY].","",[[[],0," "],[[127,1757,1761,1764,1774,1839,2555,2556,2578,2581,2584],244,"An endpoint MUST acknowledge all ack-eliciting Initial and Handshake"]],[[[],0," "],[[127,1757,1761,1764,1774,1839,2555,2556,2578,2581,2584],244,"packets immediately and all ack-eliciting 0-RTT and 1-RTT packets"]],[[[],0," "],[[127,1757,1761,1764,1774,1839,2555,2556,2578,2581,2584],244,"within its advertised max_ack_delay, with the following exception."]]," Prior to handshake confirmation, an endpoint might not have packet"," protection keys for decrypting Handshake, 0-RTT, or 1-RTT packets"," when they are received. It might therefore buffer them and"," acknowledge them when the requisite keys become available.","",[[[],0," "],[[128,2156,2582],244,"Since packets containing only ACK frames are not congestion"]],[[[],0," "],[[128,2156,2582],244,"controlled, an endpoint MUST NOT send more than one such packet in"]],[[[],0," "],[[128,2156,2582],244,"response to receiving an ack-eliciting packet."]],"",[[[],0," "],[[129,1843,2870],244,"An endpoint MUST NOT send a non-ack-eliciting packet in response to a"]],[[[],0," "],[[129,1843,2870],244,"non-ack-eliciting packet, even if there are packet gaps that precede"]],[[[],0," "],[[129,1843,2870],244,"the received packet."],[[],0," This avoids an infinite feedback loop of"]]," acknowledgments, which could prevent the connection from ever"," becoming idle. Non-ack-eliciting packets are eventually acknowledged"," when the endpoint sends an ACK frame in response to other events.",""," An endpoint that is only sending ACK frames will not receive"," acknowledgments from its peer unless those acknowledgments are",[[[],0," included in packets with ack-eliciting frames. "],[[130,2080,2560],180,"An endpoint SHOULD"]],[[[],0," "],[[130,2080,2560],180,"send an ACK frame with other frames when there are new ack-eliciting"]],[[[],0," "],[[130,2080,2560],180,"packets to acknowledge."],[[],0," "],[[131,1871],112,"When only non-ack-eliciting packets need to"]],[[[],0," "],[[131,1871],112,"be acknowledged, an endpoint MAY choose not to send an ACK frame with"]],[[[],0," "],[[131,1871],112,"outgoing frames until an ack-eliciting packet has been received."]],""," An endpoint that is only sending non-ack-eliciting packets might"," choose to occasionally add an ack-eliciting frame to those packets to",[[[],0," ensure that it receives an acknowledgment; see Section 13.2.4. "],[[132,2110,2117,2553,2554],244,"In"]],[[[],0," "],[[132,2110,2117,2553,2554],244,"that case, an endpoint MUST NOT send an ack-eliciting frame in all"]],[[[],0," "],[[132,2110,2117,2553,2554],244,"packets that would otherwise be non-ack-eliciting, to avoid an"]],[[[],0," "],[[132,2110,2117,2553,2554],244,"infinite feedback loop of acknowledgments."]],"",[[[],0," "],[[133,2402,3071],180,"In order to assist loss detection at the sender, an endpoint SHOULD"]],[[[],0," "],[[133,2402,3071],180,"generate and send an ACK frame without delay when it receives an ack-"]],[[[],0," "],[[133,2402,3071],180,"eliciting packet either:"]],"",[[[],0," "],[[2402,3071],20,"* when the received packet has a packet number less than another"]],[[[],0," "],[[2402,3071],20,"ack-eliciting packet that has been received, or"]],"",[[[],0," "],[[2402,3071],20,"* when the packet has a packet number larger than the highest-"]],[[[],0," "],[[2402,3071],20,"numbered ack-eliciting packet that has been received and there are"]],[[[],0," "],[[2402,3071],20,"missing packets between that packet and this packet."]],"",[[[],0," "],[[134,1870,2579],180,"Similarly, packets marked with the ECN Congestion Experienced (CE)"]],[[[],0," "],[[134,1870,2579],180,"codepoint in the IP header SHOULD be acknowledged immediately, to"]],[[[],0," "],[[134,1870,2579],180,"reduce the peer's response time to congestion events."]],""," The algorithms in [QUIC-RECOVERY] are expected to be resilient to"," receivers that do not follow the guidance offered above. However, an"," implementation should only deviate from these requirements after"," careful consideration of the performance implications of a change,"," for connections made by the endpoint and for other users of the"," network."],"requirements":[126,127,128,129,130,131,132,133,134]},{"id":"section-13.2.2","title":"Acknowledgment Frequency","lines":[" A receiver determines how frequently to send acknowledgments in"," response to ack-eliciting packets. This determination involves a"," trade-off.",""," Endpoints rely on timely acknowledgment to detect loss; see Section 6"," of [QUIC-RECOVERY]. Window-based congestion controllers, such as the"," one described in Section 7 of [QUIC-RECOVERY], rely on"," acknowledgments to manage their congestion window. In both cases,"," delaying acknowledgments can adversely affect performance.",""," On the other hand, reducing the frequency of packets that carry only"," acknowledgments reduces packet transmission and processing cost at"," both endpoints. It can improve connection throughput on severely"," asymmetric links and reduce the volume of acknowledgment traffic"," using return path capacity; see Section 3 of [RFC3449].","",[[[],0," "],[[135,2401,3070],180,"A receiver SHOULD send an ACK frame after receiving at least two ack-"]],[[[],0," "],[[135,2401,3070],180,"eliciting packets."],[[],0," This recommendation is general in nature and"]]," consistent with recommendations for TCP endpoint behavior [RFC5681]."," Knowledge of network conditions, knowledge of the peer's congestion"," controller, or further research and experimentation might suggest"," alternative acknowledgment strategies with better performance"," characteristics.","",[[[],0," "],[[136,2404],112,"A receiver MAY process multiple available packets before determining"]],[[[],0," "],[[136,2404],112,"whether to send an ACK frame in response."]]],"requirements":[135,136]},{"id":"section-13.2.3","title":"Managing ACK Ranges","lines":[" When an ACK frame is sent, one or more ranges of acknowledged packets"," are included. Including acknowledgments for older packets reduces"," the chance of spurious retransmissions caused by losing previously"," sent ACK frames, at the cost of larger ACK frames.","",[[[],0," "],[[137,2403,2410,3064,3072],180,"ACK frames SHOULD always acknowledge the most recently received"]],[[[],0," "],[[137,2403,2410,3064,3072],180,"packets, and the"],[[137,2403,3072],180," more out of order the packets are, the more"]],[[[],0," "],[[137,2403,3072],180,"important it is to send an updated ACK frame quickly, to prevent the"]],[[[],0," "],[[137,2403,3072],180,"peer from declaring a packet as lost and spuriously retransmitting"]],[[[],0," "],[[137,2403,3072],180,"the frames it contains."],[[],0," An ACK frame is expected to fit within a"]]," single QUIC packet. If it does not, then older ranges (those with"," the smallest packet numbers) are omitted.",""," A receiver limits the number of ACK Ranges (Section 19.3.1) it"," remembers and sends in ACK frames, both to limit the size of ACK",[[[],0," frames and to avoid resource exhaustion. "],[[138,2412,3067],180,"After receiving"]],[[[],0," "],[[138,2412,3067],180,"acknowledgments for an ACK frame, the receiver SHOULD stop tracking"]],[[[],0," "],[[138,2412,3067],180,"those acknowledged ACK Ranges."],[[],0," Senders can expect acknowledgments"]]," for most packets, but QUIC does not guarantee receipt of an"," acknowledgment for every packet that the receiver processes.",""," It is possible that retaining many ACK Ranges could cause an ACK"," frame to become too large. A receiver can discard unacknowledged ACK"," Ranges to limit ACK frame size, at the cost of increased"," retransmissions from the sender. This is necessary if an ACK frame",[[[],0," would be too large to fit in a packet. "],[[139,2405],112,"Receivers MAY also limit ACK"]],[[[],0," "],[[139,2405],112,"frame size further to preserve space for other frames or to limit the"]],[[[],0," "],[[139,2405],112,"capacity that acknowledgments consume."]],"",[[[],0," "],[[140,2406,3066],244,"A receiver MUST retain an ACK Range unless it can ensure that it will"]],[[[],0," "],[[140,2406,3066],244,"not subsequently accept packets with numbers in that range."]],[[[],0," "],[[2406,3066],20,"Maintaining a minimum packet number that increases as ranges are"]],[[[],0," "],[[2406,3066],20,"discarded is one way to achieve this with minimal state."]],"",[[[],0," "],[[141,1869,2400,2821,2824,3065],244,"Receivers can discard all ACK Ranges, but they MUST retain the"]],[[[],0," "],[[141,1869,2400,2821,2824,3065],244,"largest packet number that has been successfully processed, as that"]],[[[],0," "],[[141,1869,2400,2821,2824,3065],244,"is used to recover packet numbers from subsequent packets; see"]],[[[],0," "],[[141,1869,2400,2821,2824,3065],244,"Section 17.1."]],"",[[[],0," "],[[142,2407,3063],180,"A receiver SHOULD include an ACK Range containing the largest"]],[[[],0," "],[[142,2407,3063],180,"received packet number in every ACK frame."],[[],0," The Largest Acknowledged"]]," field is used in ECN validation at a sender, and including a lower"," value than what was included in a previous ACK frame could cause ECN"," to be unnecessarily disabled; see Section 13.4.2.",""," Section 13.2.4 describes an exemplary approach for determining what"," packets to acknowledge in each ACK frame. Though the goal of this"," algorithm is to generate an acknowledgment for every packet that is"," processed, it is still possible for acknowledgments to be lost."],"requirements":[137,138,139,140,141,142]},{"id":"section-13.2.4","title":"Limiting Ranges by Tracking ACK Frames","lines":[" When a packet containing an ACK frame is sent, the Largest"," Acknowledged field in that frame can be saved. When a packet"," containing an ACK frame is acknowledged, the receiver can stop"," acknowledging packets less than or equal to the Largest Acknowledged"," field in the sent ACK frame.",""," A receiver that sends only non-ack-eliciting packets, such as ACK"," frames, might not receive an acknowledgment for a long period of"," time. This could cause the receiver to maintain state for a large"," number of ACK frames for a long period of time, and ACK frames it"," sends could be unnecessarily large. In such a case, a receiver could"," send a PING or other small ack-eliciting frame occasionally, such as"," once per round trip, to elicit an ACK from the peer.",""," In cases without ACK frame loss, this algorithm allows for a minimum"," of 1 RTT of reordering. In cases with ACK frame loss and reordering,"," this approach does not guarantee that every acknowledgment is seen by"," the sender before it is no longer included in the ACK frame. Packets"," could be received out of order, and all subsequent ACK frames"," containing them could be lost. In this case, the loss recovery"," algorithm could cause spurious retransmissions, but the sender will"," continue making forward progress."]},{"id":"section-13.2.5","title":"Measuring and Reporting Host Delay","lines":[" An endpoint measures the delays intentionally introduced between the"," time the packet with the largest packet number is received and the"," time an acknowledgment is sent. The endpoint encodes this"," acknowledgment delay in the ACK Delay field of an ACK frame; see"," Section 19.3. This allows the receiver of the ACK frame to adjust"," for any intentional delays, which is important for getting a better"," estimate of the path RTT when acknowledgments are delayed.",""," A packet might be held in the OS kernel or elsewhere on the host",[[[],0," before being processed. "],[[143,2408,3068],244,"An endpoint MUST NOT include delays that it"]],[[[],0," "],[[143,2408,3068],244,"does not control when populating the ACK Delay field in an ACK frame."]],[[[],0," "],[[144,1714,1913,2691],180,"However, endpoints SHOULD include buffering delays caused by"]],[[[],0," "],[[144,1714,1913,2691],180,"unavailability of decryption keys, since these delays can be large"]],[[[],0," "],[[144,1714,1913,2691],180,"and are likely to be non-repeating."]],"",[[[],0," "],[[145,2409,3069],180,"When the measured acknowledgment delay is larger than its"]],[[[],0," "],[[145,2409,3069],180,"max_ack_delay, an endpoint SHOULD report the measured delay."],[[],0," This"]]," information is especially useful during the handshake when delays"," might be large; see Section 13.2.1."],"requirements":[143,144,145]},{"id":"section-13.2.6","title":"ACK Frames and Packet Protection","lines":[[[[],0," "],[[146,2108,2116,2125,2557],244,"ACK frames MUST only be carried in a packet that has the same packet"]],[[[],0," "],[[146,2108,2116,2125,2557],244,"number space as the packet being acknowledged; see Section 12.1."],[[],0," "],[[147,2126,2524],244,"For"]],[[[],0," "],[[147,2126,2524],244,"instance, packets that are protected with 1-RTT keys MUST be"]],[[[],0," "],[[147,2126,2524],244,"acknowledged in packets that are also protected with 1-RTT keys."]],"",[[[],0," "],[[148,1771,2128,2866],244,"Packets that a client sends with 0-RTT packet protection MUST be"]],[[[],0," "],[[148,1771,2128,2866],244,"acknowledged by the server in packets protected by 1-RTT keys."],[[],0," This"]]," can mean that the client is unable to use these acknowledgments if"," the server cryptographic handshake messages are delayed or lost."," Note that the same limitation applies to other data sent by the"," server protected by the 1-RTT keys."],"requirements":[146,147,148]},{"id":"section-13.2.7","title":"PADDING Frames Consume Congestion Window","lines":[" Packets containing PADDING frames are considered to be in flight for"," congestion control purposes [QUIC-RECOVERY]. Packets containing only"," PADDING frames therefore consume congestion window but do not",[[[],0," generate acknowledgments that will open the congestion window. "],[[149,2153,2542],180,"To"]],[[[],0," "],[[149,2153,2542],180,"avoid a deadlock, a sender SHOULD ensure that other frames are sent"]],[[[],0," "],[[149,2153,2542],180,"periodically in addition to PADDING frames to elicit acknowledgments"]],[[[],0," "],[[149,2153,2542],180,"from the receiver."]]],"requirements":[149]},{"id":"section-13.3","title":"Retransmission of Information","lines":[" QUIC packets that are determined to be lost are not retransmitted"," whole. The same applies to the frames that are contained within lost"," packets. Instead, the information that might be carried in frames is"," sent again in new frames as needed.",""," New frames and packets are used to carry information that is"," determined to have been lost. In general, information is sent again"," when a packet containing that information is determined to be lost,"," and sending ceases when a packet containing that information is"," acknowledged.",""," * Data sent in CRYPTO frames is retransmitted according to the rules"," in [QUIC-RECOVERY], until all data has been acknowledged. Data in"," CRYPTO frames for Initial and Handshake packets is discarded when"," keys for the corresponding packet number space are discarded.",""," * Application data sent in STREAM frames is retransmitted in new"," STREAM frames unless the endpoint has sent a RESET_STREAM for that"," stream. Once an endpoint sends a RESET_STREAM frame, no further"," STREAM frames are needed.",""," * ACK frames carry the most recent set of acknowledgments and the"," acknowledgment delay from the largest acknowledged packet, as"," described in Section 13.2.1. Delaying the transmission of packets"," containing ACK frames or resending old ACK frames can cause the"," peer to generate an inflated RTT sample or unnecessarily disable"," ECN.",""," * Cancellation of stream transmission, as carried in a RESET_STREAM"," frame, is sent until acknowledged or until all stream data is"," acknowledged by the peer (that is, either the \"Reset Recvd\" or"," \"Data Recvd\" state is reached on the sending part of the stream).",[[[],0," "],[[151,2446,2472,3088,3091],244,"The content of a RESET_STREAM frame MUST NOT change when it is"]],[[[],0," "],[[151,2446,2472,3088,3091],244,"sent again."]],""," * Similarly, a request to cancel stream transmission, as encoded in"," a STOP_SENDING frame, is sent until the receiving part of the"," stream enters either a \"Data Recvd\" or \"Reset Recvd\" state; see"," Section 3.5.",""," * Connection close signals, including packets that contain"," CONNECTION_CLOSE frames, are not sent again when packet loss is"," detected. Resending these signals is described in Section 10.",""," * The current connection maximum data is sent in MAX_DATA frames."," An updated value is sent in a MAX_DATA frame if the packet"," containing the most recently sent MAX_DATA frame is declared lost"," or when the endpoint decides to update the limit. Care is"," necessary to avoid sending this frame too often, as the limit can"," increase frequently and cause an unnecessarily large number of"," MAX_DATA frames to be sent; see Section 4.2.",""," * The current maximum stream data offset is sent in MAX_STREAM_DATA"," frames. Like MAX_DATA, an updated value is sent when the packet"," containing the most recent MAX_STREAM_DATA frame for a stream is"," lost or when the limit is updated, with care taken to prevent the",[[[],0," frame from being sent too often. "],[[152,2454,2462,3092],180,"An endpoint SHOULD stop sending"]],[[[],0," "],[[152,2454,2462,3092],180,"MAX_STREAM_DATA frames when the receiving part of the stream"]],[[[],0," "],[[152,2454,2462,3092],180,"enters a \"Size Known\" or \"Reset Recvd\" state."]],""," * The limit on streams of a given type is sent in MAX_STREAMS"," frames. Like MAX_DATA, an updated value is sent when a packet"," containing the most recent MAX_STREAMS for a stream type frame is"," declared lost or when the limit is updated, with care taken to"," prevent the frame from being sent too often.",""," * Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED,"," and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection"," scope, STREAM_DATA_BLOCKED frames have stream scope, and"," STREAMS_BLOCKED frames are scoped to a specific stream type. A"," new frame is sent if a packet containing the most recent frame for"," a scope is lost, but only while the endpoint is blocked on the"," corresponding limit. These frames always include the limit that"," is causing blocking at the time that they are transmitted.",""," * A liveness or path validation check using PATH_CHALLENGE frames is"," sent periodically until a matching PATH_RESPONSE frame is received"," or until there is no remaining need for liveness or path"," validation checking. PATH_CHALLENGE frames include a different"," payload each time they are sent.",""," * Responses to path validation using PATH_RESPONSE frames are sent"," just once. The peer is expected to send more PATH_CHALLENGE"," frames as necessary to evoke additional PATH_RESPONSE frames.",""," * New connection IDs are sent in NEW_CONNECTION_ID frames and"," retransmitted if the packet containing them is lost."," Retransmissions of this frame carry the same sequence number"," value. Likewise, retired connection IDs are sent in"," RETIRE_CONNECTION_ID frames and retransmitted if the packet"," containing them is lost.",""," * NEW_TOKEN frames are retransmitted if the packet containing them"," is lost. No special support is made for detecting reordered and"," duplicated NEW_TOKEN frames other than a direct comparison of the"," frame contents.",""," * PING and PADDING frames contain no information, so lost PING or"," PADDING frames do not require repair.","",[[[],0," "],[[153,1807,2590],244,"* The HANDSHAKE_DONE frame MUST be retransmitted until it is"]],[[[],0," "],[[153,1807,2590],244,"acknowledged."]],"",[[[],0," "],[[154,2471,3080],180,"Endpoints SHOULD prioritize retransmission of data over sending new"]],[[[],0," "],[[154,2471,3080],180,"data, unless priorities specified by the application indicate"]],[[[],0," "],[[154,2471,3080],180,"otherwise; see Section 2.3."]],""," Even though a sender is encouraged to assemble frames containing up-"," to-date information every time it sends a packet, it is not forbidden"," to retransmit copies of frames from lost packets. A sender that"," retransmits copies of frames needs to handle decreases in available"," payload size due to changes in packet number length, connection ID",[[[],0," length, and path MTU. "],[[155,1749,2648],244,"A receiver MUST accept packets containing an"]],[[[],0," "],[[155,1749,2648],244,"outdated frame, such as a MAX_DATA frame carrying a smaller maximum"]],[[[],0," "],[[155,1749,2648],244,"data value than one found in an older packet."]],"",[[[],0," "],[[156,1801,1802,2539,2540],180,"A sender SHOULD avoid retransmitting information from packets once"]],[[[],0," "],[[156,1801,1802,2539,2540],180,"they are acknowledged."],[[],0," This includes packets that are acknowledged"]]," after being declared lost, which can happen in the presence of"," network reordering. Doing so requires senders to retain information"," about packets after they are declared lost. A sender can discard"," this information after a period of time elapses that adequately"," allows for reordering, such as a PTO (Section 6.2 of"," [QUIC-RECOVERY]), or based on other events, such as reaching a memory"," limit.","",[[[],0," "],[[157,1788,2586,2587],244,"Upon detecting losses, a sender MUST take appropriate congestion"]],[[[],0," "],[[157,1788,2586,2587],244,"control action."],[[],0," The details of loss detection and congestion control"]]," are described in [QUIC-RECOVERY]."],"requirements":[151,152,153,154,155,156,157]},{"id":"section-13.4","title":"Explicit Congestion Notification","lines":[" QUIC endpoints can use ECN [RFC3168] to detect and respond to network"," congestion. ECN allows an endpoint to set an ECN-Capable Transport"," (ECT) codepoint in the ECN field of an IP packet. A network node can"," then indicate congestion by setting the ECN-CE codepoint in the ECN"," field instead of dropping the packet [RFC8087]. Endpoints react to"," reported congestion by reducing their sending rate in response, as"," described in [QUIC-RECOVERY].",""," To enable ECN, a sending QUIC endpoint first determines whether a"," path supports ECN marking and whether the peer reports the ECN values"," in received IP headers; see Section 13.4.2."]},{"id":"section-13.4.1","title":"Reporting ECN Counts","lines":[" The use of ECN requires the receiving endpoint to read the ECN field"," from an IP packet, which is not possible on all platforms. If an"," endpoint does not implement ECN support or does not have access to"," received ECN fields, it does not report ECN counts for packets it"," receives.","",[[[],0," "],[[158,2411,2526],244,"Even if an endpoint does not set an ECT field in packets it sends,"]],[[[],0," "],[[158,2411,2526],244,"the endpoint MUST provide feedback about ECN markings it receives, if"]],[[[],0," "],[[158,2411,2526],244,"these are accessible."],[[],0," Failing to report the ECN counts will cause"]]," the sender to disable the use of ECN for this connection.",""," On receiving an IP packet with an ECT(0), ECT(1), or ECN-CE"," codepoint, an ECN-enabled endpoint accesses the ECN field and"," increases the corresponding ECT(0), ECT(1), or ECN-CE count. These"," ECN counts are included in subsequent ACK frames; see Sections 13.2"," and 19.3.",""," Each packet number space maintains separate acknowledgment state and"," separate ECN counts. Coalesced QUIC packets (see Section 12.2) share"," the same IP header so the ECN counts are incremented once for each"," coalesced QUIC packet.",""," For example, if one each of an Initial, Handshake, and 1-RTT QUIC"," packet are coalesced into a single UDP datagram, the ECN counts for"," all three packet number spaces will be incremented by one each, based"," on the ECN field of the single IP header.",""," ECN counts are only incremented when QUIC packets from the received"," IP packet are processed. As such, duplicate QUIC packets are not"," processed and do not increase ECN counts; see Section 21.10 for"," relevant security concerns."],"requirements":[158]},{"id":"section-13.4.2","title":"ECN Validation","lines":[" It is possible for faulty network devices to corrupt or erroneously"," drop packets that carry a non-zero ECN codepoint. To ensure"," connectivity in the presence of such devices, an endpoint validates"," the ECN counts for each network path and disables the use of ECN on"," that path if errors are detected.",""," To perform ECN validation for a new path:",""," * The endpoint sets an ECT(0) codepoint in the IP header of early"," outgoing packets sent on a new path to the peer [RFC8311].",""," * The endpoint monitors whether all packets sent with an ECT"," codepoint are eventually deemed lost (Section 6 of"," [QUIC-RECOVERY]), indicating that ECN validation has failed.",""," If an endpoint has cause to expect that IP packets with an ECT"," codepoint might be dropped by a faulty network element, the endpoint"," could set an ECT codepoint for only the first ten outgoing packets on"," a path, or for a period of three PTOs (see Section 6.2 of"," [QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints"," are subsequently lost, it can disable marking on the assumption that"," the marking caused the loss.",""," An endpoint thus attempts to use ECN and validates this for each new"," connection, when switching to a server's preferred address, and on"," active connection migration to a new path. Appendix A.4 describes"," one possible algorithm.",""," Other methods of probing paths for ECN support are possible, as are",[[[],0," different marking strategies. "],[[164],96,"Implementations MAY use other methods"]],[[[],0," "],[[164],96,"defined in RFCs; see [RFC8311]."],[[],0," Implementations that use the ECT(1)"]]," codepoint need to perform ECN validation using the reported ECT(1)"," counts."],"requirements":[164]},{"id":"section-13.4.2.1","title":"Receiving ACK Frames with ECN Counts","lines":[" Erroneous application of ECN-CE markings by the network can result in"," degraded connection performance. An endpoint that receives an ACK"," frame with ECN counts therefore validates the counts before using"," them. It performs this validation by comparing newly received counts"," against those from the last successfully processed ACK frame. Any"," increase in the ECN counts is validated based on the ECN markings"," that were applied to packets that are newly acknowledged in the ACK"," frame.",""," If an ACK frame newly acknowledges a packet that the endpoint sent"," with either the ECT(0) or ECT(1) codepoint set, ECN validation fails"," if the corresponding ECN counts are not present in the ACK frame."," This check detects a network element that zeroes the ECN field or a"," peer that does not report ECN markings.",""," ECN validation also fails if the sum of the increase in ECT(0) and"," ECN-CE counts is less than the number of newly acknowledged packets"," that were originally sent with an ECT(0) marking. Similarly, ECN"," validation fails if the sum of the increases to ECT(1) and ECN-CE"," counts is less than the number of newly acknowledged packets sent"," with an ECT(1) marking. These checks can detect remarking of ECN-CE"," markings by the network.",""," An endpoint could miss acknowledgments for a packet when ACK frames"," are lost. It is therefore possible for the total increase in ECT(0),"," ECT(1), and ECN-CE counts to be greater than the number of packets"," that are newly acknowledged by an ACK frame. This is why ECN counts"," are permitted to be larger than the total number of packets that are"," acknowledged.",""," Validating ECN counts from reordered ACK frames can result in",[[[],0," failure. "],[[159,1783,2535],244,"An endpoint MUST NOT fail ECN validation as a result of"]],[[[],0," "],[[159,1783,2535],244,"processing an ACK frame that does not increase the largest"]],[[[],0," "],[[159,1783,2535],244,"acknowledged packet number."]],""," ECN validation can fail if the received total count for either ECT(0)"," or ECT(1) exceeds the total number of packets sent with each"," corresponding ECT codepoint. In particular, validation will fail"," when an endpoint receives a non-zero ECN count corresponding to an"," ECT codepoint that it never applied. This check detects when packets"," are remarked to ECT(0) or ECT(1) in the network."],"requirements":[159]},{"id":"section-13.4.2.2","title":"ECN Validation Outcomes","lines":[[[[],0," "],[[160,1784,1785,1786,1792,1793,1794,1796,1797,1798,2074,2533,2568,2570,2572,2573],244,"If validation fails, then the endpoint MUST disable ECN."],[[],0," "],[[2076,2571],20,"It stops"]],[[[],0," "],[[2076,2571],20,"setting the ECT codepoint in IP packets that it sends, assuming that"]],[[[],0," "],[[2076,2571],20,"either the network path or the peer does not support ECN."]],"",[[[],0," "],[[161],96,"Even if validation fails, an endpoint MAY revalidate ECN for the same"]],[[[],0," "],[[161],96,"path at any later time in the connection."],[[],0," An endpoint could continue"]]," to periodically attempt validation.","",[[[],0," "],[[162,1787,1795,1799,2077],112,"Upon successful validation, an endpoint MAY continue to set an ECT"]],[[[],0," "],[[162,1787,1795,1799,2077],112,"codepoint in subsequent packets it sends, with the expectation that"]],[[[],0," "],[[162,1787,1795,1799,2077],112,"the path is ECN capable."],[[],0," "],[[163,2075,2569],244,"Network routing and path elements can"]],[[[],0," "],[[163,2075,2569],244,"change mid-connection; an endpoint MUST disable ECN if validation"]],[[[],0," "],[[163,2075,2569],244,"later fails."]]],"requirements":[160,161,162,163]},{"id":"section-14","title":"Datagram Size","lines":[" A UDP datagram can include one or more QUIC packets. The datagram"," size refers to the total UDP payload size of a single UDP datagram"," carrying QUIC packets. The datagram size includes one or more QUIC"," packet headers and protected payloads, but not the UDP or IP headers.",""," The maximum datagram size is defined as the largest size of UDP"," payload that can be sent across a network path using a single UDP",[[[],0," datagram. "],[[189,1927,2770],244,"QUIC MUST NOT be used if the network path cannot support a"]],[[[],0," "],[[189,1927,2770],244,"maximum datagram size of at least 1200 bytes."]],""," QUIC assumes a minimum IP packet size of at least 1280 bytes. This"," is the IPv6 minimum size [IPv6] and is also supported by most modern"," IPv4 networks. Assuming the minimum IP header size of 40 bytes for"," IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this"," results in a maximum datagram size of 1232 bytes for IPv6 and 1252"," bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are"," expected to be able to support QUIC.",""," | Note: This requirement to support a UDP payload of 1200 bytes"," | limits the space available for IPv6 extension headers to 32"," | bytes or IPv4 options to 52 bytes if the path only supports the"," | IPv6 minimum MTU of 1280 bytes. This affects Initial packets"," | and path validation.",""," Any maximum datagram size larger than 1200 bytes can be discovered"," using Path Maximum Transmission Unit Discovery (PMTUD) (see"," Section 14.2.1) or Datagram Packetization Layer PMTU Discovery"," (DPLPMTUD) (see Section 14.3).",""," Enforcement of the max_udp_payload_size transport parameter"," (Section 18.2) might act as an additional limit on the maximum"," datagram size. A sender can avoid exceeding this limit, once the"," value is known. However, prior to learning the value of the"," transport parameter, endpoints risk datagrams being lost if they send"," datagrams larger than the smallest allowed maximum datagram size of"," 1200 bytes.","",[[[],0," "],[[190,1599,3100],244,"UDP datagrams MUST NOT be fragmented at the IP layer."],[[],0," "],[[191,1600,3101],244,"In IPv4"]],[[[],0," "],[[191,1600,3101],244,"[IPv4], the Don't Fragment (DF) bit MUST be set if possible, to"]],[[[],0," "],[[191,1600,3101],244,"prevent fragmentation on the path."]],""," QUIC sometimes requires datagrams to be no smaller than a certain"," size; see Section 8.1 as an example. However, the size of a datagram"," is not authenticated. That is, if an endpoint receives a datagram of"," a certain size, it cannot know that the sender sent the datagram at",[[[],0," the same size. "],[[192,2328,2900],244,"Therefore, an endpoint MUST NOT close a connection"]],[[[],0," "],[[192,2328,2900],244,"when it receives a datagram that does not meet size constraints; the"]],[[[],0," "],[[192,2328,2900],244,"endpoint MAY discard such datagrams."]]],"requirements":[189,190,191,192]},{"id":"section-14.1","title":"Initial Datagram Size","lines":[[[[],0," "],[[167,2092,2558,2712],244,"A client MUST expand the payload of all UDP datagrams carrying"]],[[[],0," "],[[167,2092,2558,2712],244,"Initial packets to at least the smallest allowed maximum datagram"]],[[[],0," "],[[167,2092,2558,2712],244,"size of 1200 bytes by adding PADDING frames to the Initial packet or"]],[[[],0," "],[[167,2092,2558,2712],244,"by coalescing the Initial packet; see Section 12.2."],[[],0," Initial packets"]]," can even be coalesced with invalid packets, which a receiver will",[[[],0," discard. "],[[168,2093,2721],244,"Similarly, a server MUST expand the payload of all UDP"]],[[[],0," "],[[168,2093,2721],244,"datagrams carrying ack-eliciting Initial packets to at least the"]],[[[],0," "],[[168,2093,2721],244,"smallest allowed maximum datagram size of 1200 bytes."]],""," Sending UDP datagrams of this size ensures that the network path"," supports a reasonable Path Maximum Transmission Unit (PMTU), in both"," directions. Additionally, a client that expands Initial packets"," helps reduce the amplitude of amplification attacks caused by server"," responses toward an unverified client address; see Section 8.","",[[[],0," "],[[169,2090],112,"Datagrams containing Initial packets MAY exceed 1200 bytes if the"]],[[[],0," "],[[169,2090],112,"sender believes that the network path and peer both support the size"]],[[[],0," "],[[169,2090],112,"that it chooses."]],"",[[[],0," "],[[170,2327,2898],244,"A server MUST discard an Initial packet that is carried in a UDP"]],[[[],0," "],[[170,2327,2898],244,"datagram with a payload that is smaller than the smallest allowed"]],[[[],0," "],[[170,2327,2898],244,"maximum datagram size of 1200 bytes."],[[],0," "],[[171],96,"A server MAY also immediately"]],[[[],0," "],[[171],96,"close the connection by sending a CONNECTION_CLOSE frame with an"]],[[[],0," "],[[171],96,"error code of PROTOCOL_VIOLATION; see Section 10.2.3."]],"",[[[],0," "],[[172,2066,2666],244,"The server MUST also limit the number of bytes it sends before"]],[[[],0," "],[[172,2066,2666],244,"validating the address of the client; see Section 8."]]],"requirements":[167,168,169,170,171,172]},{"id":"section-14.2","title":"Path Maximum Transmission Unit","lines":[" The PMTU is the maximum size of the entire IP packet, including the"," IP header, UDP header, and UDP payload. The UDP payload includes one"," or more QUIC packet headers and protected payloads. The PMTU can"," depend on path characteristics and can therefore change over time."," The largest UDP payload an endpoint sends at any given time is"," referred to as the endpoint's maximum datagram size.","",[[[],0," "],[[180,2067,2176,2536],180,"An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD"]],[[[],0," "],[[180,2067,2176,2536],180,"(Section 14.2.1) to determine whether the path to a destination will"]],[[[],0," "],[[180,2067,2176,2536],180,"support a desired maximum datagram size without fragmentation."],[[],0," "],[[181,2065,2838],180,"In"]],[[[],0," "],[[181,2065,2838],180,"the absence of these mechanisms, QUIC endpoints SHOULD NOT send"]],[[[],0," "],[[181,2065,2838],180,"datagrams larger than the smallest allowed maximum datagram size."]],""," Both DPLPMTUD and PMTUD send datagrams that are larger than the",[[[],0," current maximum datagram size, referred to as PMTU probes. "],[[182,2162,2837],180,"All QUIC"]],[[[],0," "],[[182,2162,2837],180,"packets that are not sent in a PMTU probe SHOULD be sized to fit"]],[[[],0," "],[[182,2162,2837],180,"within the maximum datagram size to avoid the datagram being"]],[[[],0," "],[[182,2162,2837],180,"fragmented or dropped [RFC8085]."]],"",[[[],0," "],[[183,1926,2769],244,"If a QUIC endpoint determines that the PMTU between any pair of local"]],[[[],0," "],[[183,1926,2769],244,"and remote IP addresses cannot support the smallest allowed maximum"]],[[[],0," "],[[183,1926,2769],244,"datagram size of 1200 bytes, it MUST immediately cease sending QUIC"]],[[[],0," "],[[183,1926,2769],244,"packets, except for those in PMTU probes or those containing"]],[[[],0," "],[[183,1926,2769],244,"CONNECTION_CLOSE frames, on the affected path."],[[],0," "],[[184,1925],112,"An endpoint MAY"]],[[[],0," "],[[184,1925],112,"terminate the connection if an alternative path cannot be found."]],""," Each pair of local and remote addresses could have a different PMTU.",[[[],0," "],[[185,1924,2893],180,"QUIC implementations that implement any kind of PMTU discovery"]],[[[],0," "],[[185,1924,2893],180,"therefore SHOULD maintain a maximum datagram size for each"]],[[[],0," "],[[185,1924,2893],180,"combination of local and remote IP addresses."]],"",[[[],0," "],[[186,2063,2064],112,"A QUIC implementation MAY be more conservative in computing the"]],[[[],0," "],[[186,2063,2064],112,"maximum datagram size to allow for unknown tunnel overheads or IP"]],[[[],0," "],[[186,2063,2064],112,"header options/extensions."]]],"requirements":[180,181,182,183,184,185,186]},{"id":"section-14.2.1","title":"Handling of ICMP Messages by PMTUD","lines":[" PMTUD [RFC1191] [RFC8201] relies on reception of ICMP messages (that"," is, IPv6 Packet Too Big (PTB) messages) that indicate when an IP"," packet is dropped because it is larger than the local router MTU."," DPLPMTUD can also optionally use these messages. This use of ICMP"," messages is potentially vulnerable to attacks by entities that cannot"," observe packets but might successfully guess the addresses used on"," the path. These attacks could reduce the PMTU to a bandwidth-"," inefficient value.","",[[[],0," "],[[173,1597,3102],244,"An endpoint MUST ignore an ICMP message that claims the PMTU has"]],[[[],0," "],[[173,1597,3102],244,"decreased below QUIC's smallest allowed maximum datagram size."]],""," The requirements for generating ICMP [RFC1812] [RFC4443] state that"," the quoted packet should contain as much of the original packet as"," possible without exceeding the minimum MTU for the IP version. The"," size of the quoted packet can actually be smaller, or the information"," unintelligible, as described in Section 1.1 of [DPLPMTUD].","",[[[],0," "],[[174,2336],176,"QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect"]],[[[],0," "],[[174,2336],176,"from packet injection as specified in [RFC8201] and Section 5.2 of"]],[[[],0," "],[[174,2336],176,"[RFC8085]."],[[],0," "],[[175,1598,2337,2892],180,"This validation SHOULD use the quoted packet supplied in"]],[[[],0," "],[[175,1598,2337,2892],180,"the payload of an ICMP message to associate the message with a"]],[[[],0," "],[[175,1598,2337,2892],180,"corresponding transport connection (see Section 4.6.1 of [DPLPMTUD])."]],[[[],0," "],[[176,2300],240,"ICMP message validation MUST include matching IP addresses and UDP"]],[[[],0," "],[[176,2300],240,"ports [RFC8085] and, when possible, connection IDs to an active QUIC"]],[[[],0," "],[[176,2300],240,"session."],[[],0," "],[[177,2301,2891],180,"The endpoint SHOULD ignore all ICMP messages that fail"]],[[[],0," "],[[177,2301,2891],180,"validation."]],"",[[[],0," "],[[178,1929,2771],244,"An endpoint MUST NOT increase the PMTU based on ICMP messages; see"]],[[[],0," "],[[178,1929,2771],244,"Item 6 in Section 3 of [DPLPMTUD]."],[[],0," "],[[179],96,"Any reduction in QUIC's maximum"]],[[[],0," "],[[179],96,"datagram size in response to ICMP messages MAY be provisional until"]],[[[],0," "],[[179],96,"QUIC's loss detection algorithm determines that the quoted packet has"]],[[[],0," "],[[179],96,"actually been lost."]]],"requirements":[173,174,175,176,177,178,179]},{"id":"section-14.3","title":"Datagram Packetization Layer PMTU Discovery","lines":[" DPLPMTUD [DPLPMTUD] relies on tracking loss or acknowledgment of QUIC"," packets that are carried in PMTU probes. PMTU probes for DPLPMTUD"," that use the PADDING frame implement \"Probing using padding data\", as"," defined in Section 4.1 of [DPLPMTUD].","",[[[],0," "],[[187,1421,2354,3095],180,"Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of"]],[[[],0," "],[[187,1421,2354,3095],180,"[DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum"]],[[[],0," "],[[187,1421,2354,3095],180,"datagram size."],[[],0," The MIN_PLPMTU is the same as the BASE_PLPMTU."]],""," QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum"," Packet Size (MPS) (Section 4.4 of [DPLPMTUD]) for each combination of"," local and remote IP addresses. This corresponds to the maximum"," datagram size."],"requirements":[187]},{"id":"section-14.3.1","title":"DPLPMTUD and Initial Connectivity","lines":[" From the perspective of DPLPMTUD, QUIC is an acknowledged"," Packetization Layer (PL). A QUIC sender can therefore enter the"," DPLPMTUD BASE state (Section 5.2 of [DPLPMTUD]) when the QUIC"," connection handshake has been completed."]},{"id":"section-14.3.2","title":"Validating the Network Path with DPLPMTUD","lines":[" QUIC is an acknowledged PL; therefore, a QUIC sender does not"," implement a DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE"," state; see Section 5.2 of [DPLPMTUD]."]},{"id":"section-14.3.3","title":"Handling of ICMP Messages by DPLPMTUD","lines":[" An endpoint using DPLPMTUD requires the validation of any received"," ICMP PTB message before using the PTB information, as defined in"," Section 4.6 of [DPLPMTUD]. In addition to UDP port validation, QUIC"," validates an ICMP message by using other PL information (e.g.,"," validation of connection IDs in the quoted packet of any received"," ICMP message).",""," The considerations for processing ICMP messages described in"," Section 14.2.1 also apply if these messages are used by DPLPMTUD."]},{"id":"section-14.4","title":"Sending QUIC PMTU Probes","lines":[" PMTU probes are ack-eliciting packets.",""," Endpoints could limit the content of PMTU probes to PING and PADDING"," frames, since packets that are larger than the current maximum",[[[],0," datagram size are more likely to be dropped by the network. "],[[188,1805,2068,2537],180,"Loss of"]],[[[],0," "],[[188,1805,2068,2537],180,"a QUIC packet that is carried in a PMTU probe is therefore not a"]],[[[],0," "],[[188,1805,2068,2537],180,"reliable indication of congestion and SHOULD NOT trigger a congestion"]],[[[],0," "],[[188,1805,2068,2537],180,"control reaction; see Item 7 in Section 3 of [DPLPMTUD]."],[[],0," However,"]]," PMTU probes consume congestion window, which could delay subsequent"," transmission by an application."],"requirements":[188]},{"id":"section-14.4.1","title":"PMTU Probes Containing Source Connection ID","lines":[" Endpoints that rely on the Destination Connection ID field for"," routing incoming QUIC packets are likely to require that the"," connection ID be included in PMTU probes to route any resulting ICMP"," messages (Section 14.2.1) back to the correct endpoint. However,"," only long header packets (Section 17.2) contain the Source Connection"," ID field, and long header packets are not decrypted or acknowledged"," by the peer once the handshake is complete.",""," One way to construct a PMTU probe is to coalesce (see Section 12.2) a"," packet with a long header, such as a Handshake or 0-RTT packet"," (Section 17.2), with a short header packet in a single UDP datagram."," If the resulting PMTU probe reaches the endpoint, the packet with the"," long header will be ignored, but the short header packet will be"," acknowledged. If the PMTU probe causes an ICMP message to be sent,"," the first part of the probe will be quoted in that message. If the"," Source Connection ID field is within the quoted portion of the probe,"," that could be used for routing or validation of the ICMP message.",""," | Note: The purpose of using a packet with a long header is only"," | to ensure that the quoted packet contained in the ICMP message"," | contains a Source Connection ID field. This packet does not"," | need to be a valid packet, and it can be sent even if there is"," | no current use for packets of that type."]},{"id":"section-15","title":"Versions","lines":[" QUIC versions are identified using a 32-bit unsigned number.",""," The version 0x00000000 is reserved to represent version negotiation."," This version of the specification is identified by the number"," 0x00000001.",""," Other versions of QUIC might have different properties from this"," version. The properties of QUIC that are guaranteed to be consistent"," across all versions of the protocol are described in"," [QUIC-INVARIANTS].",""," Version 0x00000001 of QUIC uses TLS as a cryptographic handshake"," protocol, as described in [QUIC-TLS].",""," Versions with the most significant 16 bits of the version number"," cleared are reserved for use in future IETF consensus documents.",""," Versions that follow the pattern 0x?a?a?a?a are reserved for use in"," forcing version negotiation to be exercised -- that is, any version",[[[],0," number where the low four bits of all bytes is 1010 (in binary). "],[[],0,"A"]],[[[],0," "],[[193,2290],112,"client or server MAY advertise support for any of these reserved"]],[[[],0," "],[[193,2290],112,"versions."]],"",[[[],0," "],[[194,2289],112,"Reserved version numbers will never represent a real protocol; a"]],[[[],0," "],[[194,2289],112,"client MAY use one of these version numbers with the expectation that"]],[[[],0," "],[[194,2289],112,"the server will initiate version negotiation; "],[[194,2289,2291],112,"a server MAY advertise"]],[[[],0," "],[[194,2289,2291],112,"support for one of these versions and can expect that clients ignore"]],[[[],0," "],[[194,2289,2291],112,"the value."]]],"requirements":[193,194]},{"id":"section-16","title":"Variable-Length Integer Encoding","lines":[" QUIC packets and frames commonly use a variable-length encoding for"," non-negative integer values. This encoding ensures that smaller"," integer values need fewer bytes to encode.",""," The QUIC variable-length integer encoding reserves the two most"," significant bits of the first byte to encode the base-2 logarithm of"," the integer encoding length in bytes. The integer value is encoded"," on the remaining bits, in network byte order.",""," This means that integers are encoded on 1, 2, 4, or 8 bytes and can"," encode 6-, 14-, 30-, or 62-bit values, respectively. Table 4"," summarizes the encoding properties.",""," +======+========+=============+=======================+"," | 2MSB | Length | Usable Bits | Range |"," +======+========+=============+=======================+"," | 00 | 1 | 6 | 0-63 |"," +------+--------+-------------+-----------------------+"," | 01 | 2 | 14 | 0-16383 |"," +------+--------+-------------+-----------------------+"," | 10 | 4 | 30 | 0-1073741823 |"," +------+--------+-------------+-----------------------+"," | 11 | 8 | 62 | 0-4611686018427387903 |"," +------+--------+-------------+-----------------------+",""," Table 4: Summary of Integer Encodings",""," An example of a decoding algorithm and sample encodings are shown in"," Appendix A.1.",""," Values do not need to be encoded on the minimum number of bytes"," necessary, with the sole exception of the Frame Type field; see"," Section 12.4.",""," Versions (Section 15), packet numbers sent in the header"," (Section 17.1), and the length of connection IDs in long header"," packets (Section 17.2) are described using integers but do not use"," this encoding."]},{"id":"section-17","title":"Packet Formats","lines":[" All numeric values are encoded in network byte order (that is, big"," endian), and all field sizes are in bits. Hexadecimal notation is"," used for describing the value of fields."]},{"id":"section-17.1","title":"Packet Number Encoding and Decoding","lines":[" Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3)."," When present in long or short packet headers, they are encoded in 1"," to 4 bytes. The number of bits required to represent the packet"," number is reduced by including only the least significant bits of the"," packet number.",""," The encoded packet number is protected as described in Section 5.4 of"," [QUIC-TLS].","",[[[],0," "],[[195,1892],240,"Prior to receiving an acknowledgment for a packet number space, the"]],[[[],0," "],[[195,1892],240,"full packet number MUST be included; it is not to be truncated, as"]],[[[],0," "],[[195,1892],240,"described below."]],"",[[[],0," "],[[196,1893],240,"After an acknowledgment is received for a packet number space, the"]],[[[],0," "],[[196,1893],240,"sender MUST use a packet number size able to represent more than"]],[[[],0," "],[[196,1893],240,"twice as large a range as the difference between the largest"]],[[[],0," "],[[196,1893],240,"acknowledged packet number and the packet number being sent."],[[],0," A peer"]]," receiving the packet will then correctly decode the packet number,"," unless the packet is delayed in transit such that it arrives after",[[[],0," many higher-numbered packets have been received. "],[[197,1894],176,"An endpoint SHOULD"]],[[[],0," "],[[197,1894],176,"use a large enough packet number encoding to allow the packet number"]],[[[],0," "],[[197,1894],176,"to be recovered even if the packet arrives after packets that are"]],[[[],0," "],[[197,1894],176,"sent afterwards."]],""," As a result, the size of the packet number encoding is at least one"," bit more than the base-2 logarithm of the number of contiguous"," unacknowledged packet numbers, including the new packet. Pseudocode"," and an example for packet number encoding can be found in"," Appendix A.2.",""," At a receiver, protection of the packet number is removed prior to"," recovering the full packet number. The full packet number is then"," reconstructed based on the number of significant bits present, the"," value of those bits, and the largest packet number received in a"," successfully authenticated packet. Recovering the full packet number"," is necessary to successfully complete the removal of packet"," protection.","",[[[],0," "],[[1676,2987],20,"Once header protection is removed, the packet number is decoded by"]],[[[],0," "],[[1676,2987],20,"finding the packet number value that is closest to the next expected"]],[[[],0," "],[[1676,2987],20,"packet."],[[],0," The next expected packet is the highest received packet"]]," number plus one. Pseudocode and an example for packet number"," decoding can be found in Appendix A.3."],"requirements":[195,196,197]},{"id":"section-17.2","title":"Long Header Packets","lines":[" Long Header Packet {"," Header Form (1) = 1,"," Fixed Bit (1) = 1,"," Long Packet Type (2),"," Type-Specific Bits (4),"," Version (32),"," Destination Connection ID Length (8),"," Destination Connection ID (0..160),"," Source Connection ID Length (8),"," Source Connection ID (0..160),"," Type-Specific Payload (..),"," }",""," Figure 13: Long Header Packet Format",""," Long headers are used for packets that are sent prior to the"," establishment of 1-RTT keys. Once 1-RTT keys are available, a sender"," switches to sending packets using the short header (Section 17.3)."," The long form allows for special packets -- such as the Version"," Negotiation packet -- to be represented in this uniform fixed-length"," packet format. Packets that use the long header contain the"," following fields:",""," Header Form: The most significant bit (0x80) of byte 0 (the first"," byte) is set to 1 for long headers.",""," Fixed Bit: The next bit (0x40) of byte 0 is set to 1, unless the",[[[],0," packet is a Version Negotiation packet. "],[[230,1674,3009],244,"Packets containing a zero"]],[[[],0," "],[[230,1674,3009],244,"value for this bit are not valid packets in this version and MUST"]],[[[],0," "],[[230,1674,3009],244,"be discarded."],[[],0," A value of 1 for this bit allows QUIC to coexist"]]," with other protocols; see [RFC7983].",""," Long Packet Type: The next two bits (those with a mask of 0x30) of"," byte 0 contain a packet type. Packet types are listed in Table 5.",""," Type-Specific Bits: The semantics of the lower four bits (those with"," a mask of 0x0f) of byte 0 are determined by the packet type.",""," Version: The QUIC Version is a 32-bit field that follows the first"," byte. This field indicates the version of QUIC that is in use and"," determines how the rest of the protocol fields are interpreted.",""," Destination Connection ID Length: The byte following the version"," contains the length in bytes of the Destination Connection ID"," field that follows it. This length is encoded as an 8-bit",[[[],0," unsigned integer. "],[[231,234,1668,2996],244,"In QUIC version 1, this value MUST NOT exceed"]],[[[],0," "],[[231,234,1668,2996],244,"20 bytes."],[[],0," "],[[232,235,1653,1661,1666,2999],244,"Endpoints that receive a version 1 long header with a"]],[[[],0," "],[[232,235,1653,1661,1666,2999],244,"value larger than 20 MUST drop the packet."],[[],0," "],[[233,236,2227,2228,2906,2907],180,"In order to properly"]],[[[],0," "],[[233,236,2227,2228,2906,2907],180,"form a Version Negotiation packet, servers SHOULD be able to read"]],[[[],0," "],[[233,236,2227,2228,2906,2907],180,"longer connection IDs from other QUIC versions."]],""," Destination Connection ID: The Destination Connection ID field"," follows the Destination Connection ID Length field, which"," indicates the length of this field. Section 7.2 describes the use"," of this field in more detail.",""," Source Connection ID Length: The byte following the Destination"," Connection ID contains the length in bytes of the Source"," Connection ID field that follows it. This length is encoded as an"," 8-bit unsigned integer. In QUIC version 1, this value MUST NOT"," exceed 20 bytes. Endpoints that receive a version 1 long header"," with a value larger than 20 MUST drop the packet. In order to"," properly form a Version Negotiation packet, servers SHOULD be able"," to read longer connection IDs from other QUIC versions.",""," Source Connection ID: The Source Connection ID field follows the"," Source Connection ID Length field, which indicates the length of"," this field. Section 7.2 describes the use of this field in more"," detail.",""," Type-Specific Payload: The remainder of the packet, if any, is type"," specific.",""," In this version of QUIC, the following packet types with the long"," header are defined:",""," +======+===========+================+"," | Type | Name | Section |"," +======+===========+================+"," | 0x00 | Initial | Section 17.2.2 |"," +------+-----------+----------------+"," | 0x01 | 0-RTT | Section 17.2.3 |"," +------+-----------+----------------+"," | 0x02 | Handshake | Section 17.2.4 |"," +------+-----------+----------------+"," | 0x03 | Retry | Section 17.2.5 |"," +------+-----------+----------------+",""," Table 5: Long Header Packet Types",""," The header form bit, Destination and Source Connection ID lengths,"," Destination and Source Connection ID fields, and Version fields of a"," long header packet are version independent. The other fields in the"," first byte are version specific. See [QUIC-INVARIANTS] for details"," on how packets from different versions of QUIC are interpreted.",""," The interpretation of the fields and the payload are specific to a"," version and packet type. While type-specific semantics for this"," version are described in the following sections, several long header"," packets in this version of QUIC contain these additional fields:",""," Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are"," reserved across multiple packet types. These bits are protected",[[[],0," using header protection; see Section 5.4 of [QUIC-TLS]. "],[[237,1658,2988],244,"The value"]],[[[],0," "],[[237,1658,2988],244,"included prior to protection MUST be set to 0."],[[],0," "],[[238,1675,3008],244,"An endpoint MUST"]],[[[],0," "],[[238,1675,3008],244,"treat receipt of a packet that has a non-zero value for these bits"]],[[[],0," "],[[238,1675,3008],244,"after removing both packet and header protection as a connection"]],[[[],0," "],[[238,1675,3008],244,"error of type PROTOCOL_VIOLATION."],[[],0," Discarding such a packet after"]]," only removing header protection can expose the endpoint to"," attacks; see Section 9.5 of [QUIC-TLS].",""," Packet Number Length: In packet types that contain a Packet Number"," field, the least significant two bits (those with a mask of 0x03)"," of byte 0 contain the length of the Packet Number field, encoded"," as an unsigned two-bit integer that is one less than the length of"," the Packet Number field in bytes. That is, the length of the"," Packet Number field is the value of this field plus one. These"," bits are protected using header protection; see Section 5.4 of"," [QUIC-TLS].",""," Length: This is the length of the remainder of the packet (that is,"," the Packet Number and Payload fields) in bytes, encoded as a"," variable-length integer (Section 16).",""," Packet Number: This field is 1 to 4 bytes long. The packet number"," is protected using header protection; see Section 5.4 of"," [QUIC-TLS]. The length of the Packet Number field is encoded in"," the Packet Number Length bits of byte 0; see above.",""," Packet Payload: This is the payload of the packet -- containing a"," sequence of frames -- that is protected using packet protection."],"requirements":[230,231,232,233,234,235,236,237,238]},{"id":"section-17.2.1","title":"Version Negotiation Packet","lines":[" A Version Negotiation packet is inherently not version specific."," Upon receipt by a client, it will be identified as a Version"," Negotiation packet based on the Version field having a value of 0.",""," The Version Negotiation packet is a response to a client packet that"," contains a version that is not supported by the server. It is only"," sent by servers.",""," The layout of a Version Negotiation packet is:",""," Version Negotiation Packet {"," Header Form (1) = 1,"," Unused (7),"," Version (32) = 0,"," Destination Connection ID Length (8),"," Destination Connection ID (0..2040),"," Source Connection ID Length (8),"," Source Connection ID (0..2040),"," Supported Version (32) ...,"," }",""," Figure 14: Version Negotiation Packet","",[[[],0," "],[[1660,2991],20,"The value in the Unused field is set to an arbitrary value by the"]],[[[],0," "],[[1660,2991],20,"server. "],[[198,1660,2991],244,"Clients MUST ignore the value of this field."],[[],0," "],[[199,1669,2989],180,"Where QUIC"]],[[[],0," "],[[199,1669,2989],180,"might be multiplexed with other protocols (see [RFC7983]), servers"]],[[[],0," "],[[199,1669,2989],180,"SHOULD set the most significant bit of this field (0x40) to 1 so that"]],[[[],0," "],[[199,1669,2989],180,"Version Negotiation packets appear to have the Fixed Bit field."],[[],0," Note"]]," that other versions of QUIC might not make a similar recommendation.","",[[[],0," "],[[200,1670,2990],244,"The Version field of a Version Negotiation packet MUST be set to"]],[[[],0," "],[[200,1670,2990],244,"0x00000000."]],"",[[[],0," "],[[201,2294,2882],244,"The server MUST include the value from the Source Connection ID field"]],[[[],0," "],[[201,2294,2882],244,"of the packet it receives in the Destination Connection ID field."]],[[[],0," "],[[202,2295,2883],244,"The value for Source Connection ID MUST be copied from the"]],[[[],0," "],[[202,2295,2883],244,"Destination Connection ID of the received packet, which is initially"]],[[[],0," "],[[202,2295,2883],244,"randomly selected by a client."],[[],0," Echoing both connection IDs gives"]]," clients some assurance that the server received the packet and that"," the Version Negotiation packet was not generated by an entity that"," did not observe the Initial packet.",""," Future versions of QUIC could have different requirements for the"," lengths of connection IDs. In particular, connection IDs might have",[[[],0," a smaller minimum length or a greater maximum length. "],[[203,2317,2905],244,"Version-"]],[[[],0," "],[[203,2317,2905],244,"specific rules for the connection ID therefore MUST NOT influence a"]],[[[],0," "],[[203,2317,2905],244,"decision about whether to send a Version Negotiation packet."]],""," The remainder of the Version Negotiation packet is a list of 32-bit"," versions that the server supports.",""," A Version Negotiation packet is not acknowledged. It is only sent in"," response to a packet that indicates an unsupported version; see"," Section 5.2.2.",""," The Version Negotiation packet does not include the Packet Number and"," Length fields present in other packets that use the long header form."," Consequently, a Version Negotiation packet consumes an entire UDP"," datagram.","",[[[],0," "],[[204,2323,2904],244,"A server MUST NOT send more than one Version Negotiation packet in"]],[[[],0," "],[[204,2323,2904],244,"response to a single UDP datagram."]],""," See Section 6 for a description of the version negotiation process."],"requirements":[198,199,200,201,202,203,204]},{"id":"section-17.2.2","title":"Initial Packet","lines":[" An Initial packet uses long headers with a type value of 0x00. It"," carries the first CRYPTO frames sent by the client and server to"," perform key exchange, and it carries ACK frames in either direction.",""," Initial Packet {"," Header Form (1) = 1,"," Fixed Bit (1) = 1,"," Long Packet Type (2) = 0,"," Reserved Bits (2),"," Packet Number Length (2),"," Version (32),"," Destination Connection ID Length (8),"," Destination Connection ID (0..160),"," Source Connection ID Length (8),"," Source Connection ID (0..160),"," Token Length (i),"," Token (..),"," Length (i),"," Packet Number (8..32),"," Packet Payload (8..),"," }",""," Figure 15: Initial Packet",""," The Initial packet contains a long header as well as the Length and"," Packet Number fields; see Section 17.2. The first byte contains the"," Reserved and Packet Number Length bits; see also Section 17.2."," Between the Source Connection ID and Length fields, there are two"," additional fields specific to the Initial packet.",""," Token Length: A variable-length integer specifying the length of the"," Token field, in bytes. This value is 0 if no token is present.",[[[],0," "],[[205,1751,1767,2089,2659,2660],244,"Initial packets sent by the server MUST set the Token Length field"]],[[[],0," "],[[205,1751,1767,2089,2659,2660],244,"to 0; clients that receive an Initial packet with a non-zero Token"]],[[[],0," "],[[205,1751,1767,2089,2659,2660],244,"Length field MUST either discard the packet or generate a"]],[[[],0," "],[[205,1751,1767,2089,2659,2660],244,"connection error of type PROTOCOL_VIOLATION."]],""," Token: The value of the token that was previously provided in a"," Retry packet or NEW_TOKEN frame; see Section 8.1.",""," In order to prevent tampering by version-unaware middleboxes, Initial"," packets are protected with connection- and version-specific keys"," (Initial keys) as described in [QUIC-TLS]. This protection does not"," provide confidentiality or integrity against attackers that can"," observe packets, but it does prevent attackers that cannot observe"," packets from spoofing Initial packets.",""," The client and server use the Initial packet type for any packet that"," contains an initial cryptographic handshake message. This includes"," all cases where a new packet containing the initial cryptographic"," message needs to be created, such as the packets sent after receiving"," a Retry packet; see Section 17.2.5.",""," A server sends its first Initial packet in response to a client",[[[],0," Initial. "],[[206,2115],112,"A server MAY send multiple Initial packets."],[[],0," The"]]," cryptographic key exchange could require multiple round trips or"," retransmissions of this data.",""," The payload of an Initial packet includes a CRYPTO frame (or frames)"," containing a cryptographic handshake message, ACK frames, or both."," PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also"," permitted. An endpoint that receives an Initial packet containing"," other frames can either discard the packet as spurious or treat it as"," a connection error.",""," The first packet sent by a client always includes a CRYPTO frame that"," contains the start or all of the first cryptographic handshake"," message. The first CRYPTO frame sent always begins at an offset of"," 0; see Section 7.",""," Note that if the server sends a TLS HelloRetryRequest (see"," Section 4.7 of [QUIC-TLS]), the client will send another series of"," Initial packets. These Initial packets will continue the"," cryptographic handshake and will contain CRYPTO frames starting at an"," offset matching the size of the CRYPTO frames sent in the first"," flight of Initial packets."],"requirements":[205,206]},{"id":"section-17.2.2.1","title":"Abandoning Initial Packets","lines":[" A client stops both sending and processing Initial packets when it"," sends its first Handshake packet. A server stops sending and"," processing Initial packets when it receives its first Handshake"," packet. Though packets might still be in flight or awaiting"," acknowledgment, no further Initial packets need to be exchanged"," beyond this point. Initial packet protection keys are discarded (see"," Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and"," congestion control state; see Section 6.4 of [QUIC-RECOVERY].",""," Any data in CRYPTO frames is discarded -- and no longer retransmitted"," -- when Initial keys are discarded."]},{"id":"section-17.2.3","title":"0-RTT","lines":[" A 0-RTT packet uses long headers with a type value of 0x01, followed"," by the Length and Packet Number fields; see Section 17.2. The first"," byte contains the Reserved and Packet Number Length bits; see"," Section 17.2. A 0-RTT packet is used to carry \"early\" data from the"," client to the server as part of the first flight, prior to handshake"," completion. As part of the TLS handshake, the server can accept or"," reject this early data.",""," See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its"," limitations.",""," 0-RTT Packet {"," Header Form (1) = 1,"," Fixed Bit (1) = 1,"," Long Packet Type (2) = 1,"," Reserved Bits (2),"," Packet Number Length (2),"," Version (32),"," Destination Connection ID Length (8),"," Destination Connection ID (0..160),"," Source Connection ID Length (8),"," Source Connection ID (0..160),"," Length (i),"," Packet Number (8..32),"," Packet Payload (8..),"," }",""," Figure 16: 0-RTT Packet",""," Packet numbers for 0-RTT protected packets use the same space as"," 1-RTT protected packets.",""," After a client receives a Retry packet, 0-RTT packets are likely to",[[[],0," have been lost or discarded by the server. "],[[207,2205,2802],180,"A client SHOULD attempt"]],[[[],0," "],[[207,2205,2802],180,"to resend data in 0-RTT packets after it sends a new Initial packet."]],[[[],0," "],[[208,1777,2564,2803],244,"New packet numbers MUST be used for any new packets that are sent; as"]],[[[],0," "],[[208,1777,2564,2803],244,"described in Section 17.2.5.3, reusing packet numbers could"]],[[[],0," "],[[208,1777,2564,2803],244,"compromise packet protection."]],""," A client only receives acknowledgments for its 0-RTT packets once the"," handshake is complete, as defined in Section 4.1.1 of [QUIC-TLS].","",[[[],0," "],[[209,1766,1775,2869],244,"A client MUST NOT send 0-RTT packets once it starts processing 1-RTT"]],[[[],0," "],[[209,1766,1775,2869],244,"packets from the server."],[[],0," This means that 0-RTT packets cannot"]]," contain any response to frames from 1-RTT packets. For instance, a"," client cannot send an ACK frame in a 0-RTT packet, because that can",[[[],0," only acknowledge a 1-RTT packet. "],[[210,2127,2525],244,"An acknowledgment for a 1-RTT"]],[[[],0," "],[[210,2127,2525],244,"packet MUST be carried in a 1-RTT packet."]],"",[[[],0," "],[[211,1829,2037,2867,2868],180,"A server SHOULD treat a violation of remembered limits"]],[[[],0," "],[[211,1829,2037,2867,2868],180,"(Section 7.4.1) as a connection error of an appropriate type (for"]],[[[],0," "],[[211,1829,2037,2867,2868],180,"instance, a FLOW_CONTROL_ERROR for exceeding stream data limits)."]]],"requirements":[207,208,209,210,211]},{"id":"section-17.2.4","title":"Handshake Packet","lines":[" A Handshake packet uses long headers with a type value of 0x02,"," followed by the Length and Packet Number fields; see Section 17.2."," The first byte contains the Reserved and Packet Number Length bits;"," see Section 17.2. It is used to carry cryptographic handshake"," messages and acknowledgments from the server and client.",""," Handshake Packet {"," Header Form (1) = 1,"," Fixed Bit (1) = 1,"," Long Packet Type (2) = 2,"," Reserved Bits (2),"," Packet Number Length (2),"," Version (32),"," Destination Connection ID Length (8),"," Destination Connection ID (0..160),"," Source Connection ID Length (8),"," Source Connection ID (0..160),"," Length (i),"," Packet Number (8..32),"," Packet Payload (8..),"," }",""," Figure 17: Handshake Protected Packet",""," Once a client has received a Handshake packet from a server, it uses"," Handshake packets to send subsequent cryptographic handshake messages"," and acknowledgments to the server.",""," The Destination Connection ID field in a Handshake packet contains a"," connection ID that is chosen by the recipient of the packet; the"," Source Connection ID includes the connection ID that the sender of"," the packet wishes to use; see Section 7.2.",""," Handshake packets have their own packet number space, and thus the"," first Handshake packet sent by a server contains a packet number of"," 0.",""," The payload of this packet contains CRYPTO frames and could contain",[[[],0," PING, PADDING, or ACK frames. "],[[212,2100],112,"Handshake packets MAY contain"]],[[[],0," "],[[212,2100],112,"CONNECTION_CLOSE frames of type 0x1c."],[[],0," "],[[213,1665,1687,3003],244,"Endpoints MUST treat receipt"]],[[[],0," "],[[213,1665,1687,3003],244,"of Handshake packets with other frames as a connection error of type"]],[[[],0," "],[[213,1665,1687,3003],244,"PROTOCOL_VIOLATION."]],""," Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames"," for Handshake packets is discarded -- and no longer retransmitted --"," when Handshake protection keys are discarded."],"requirements":[212,213]},{"id":"section-17.2.5","title":"Retry Packet","lines":[" As shown in Figure 18, a Retry packet uses a long packet header with"," a type value of 0x03. It carries an address validation token created"," by the server. It is used by a server that wishes to perform a"," retry; see Section 8.1.",""," Retry Packet {"," Header Form (1) = 1,"," Fixed Bit (1) = 1,"," Long Packet Type (2) = 3,"," Unused (4),"," Version (32),"," Destination Connection ID Length (8),"," Destination Connection ID (0..160),"," Source Connection ID Length (8),"," Source Connection ID (0..160),"," Retry Token (..),"," Retry Integrity Tag (128),"," }",""," Figure 18: Retry Packet","",[[[],0," A Retry packet does not contain any protected fields. "],[[229,1667,2992],244,"The value in"]],[[[],0," "],[[229,1667,2992],244,"the Unused field is set to an arbitrary value by the server; a client"]],[[[],0," "],[[229,1667,2992],244,"MUST ignore these bits."],[[],0," In addition to the fields from the long"]]," header, it contains these additional fields:",""," Retry Token: An opaque token that the server can use to validate the"," client's address.",""," Retry Integrity Tag: Defined in Section 5.8 (\"Retry Packet"," Integrity\") of [QUIC-TLS]."],"requirements":[229]},{"id":"section-17.2.5.1","title":"Sending a Retry Packet","lines":[" The server populates the Destination Connection ID with the"," connection ID that the client included in the Source Connection ID of"," the Initial packet.",""," The server includes a connection ID of its choice in the Source",[[[],0," Connection ID field. "],[[214,2297,2881],244,"This value MUST NOT be equal to the Destination"]],[[[],0," "],[[214,2297,2881],244,"Connection ID field of the packet sent by the client."],[[],0," "],[[215,2349,2809],244,"A client MUST"]],[[[],0," "],[[215,2349,2809],244,"discard a Retry packet that contains a Source Connection ID field"]],[[[],0," "],[[215,2349,2809],244,"that is identical to the Destination Connection ID field of its"]],[[[],0," "],[[215,2349,2809],244,"Initial packet."],[[],0," "],[[216,2209,2796],244,"The client MUST use the value from the Source"]],[[[],0," "],[[216,2209,2796],244,"Connection ID field of the Retry packet in the Destination Connection"]],[[[],0," "],[[216,2209,2796],244,"ID field of subsequent packets that it sends."]],"",[[[],0," "],[[217,2333],112,"A server MAY send Retry packets in response to Initial and 0-RTT"]],[[[],0," "],[[217,2333],112,"packets."],[[],0," A server can either discard or buffer 0-RTT packets that it"]]," receives. A server can send multiple Retry packets as it receives",[[[],0," Initial or 0-RTT packets. "],[[218,2334,2909],244,"A server MUST NOT send more than one Retry"]],[[[],0," "],[[218,2334,2909],244,"packet in response to a single UDP datagram."]]],"requirements":[214,215,216,217,218]},{"id":"section-17.2.5.2","title":"Handling a Retry Packet","lines":[[[[],0," "],[[219,2345,2806],244,"A client MUST accept and process at most one Retry packet for each"]],[[[],0," "],[[219,2345,2806],244,"connection attempt."],[[],0," "],[[220,2346,2807,2808],244,"After the client has received and processed an"]],[[[],0," "],[[220,2346,2807,2808],244,"Initial or Retry packet from the server, it MUST discard any"]],[[[],0," "],[[220,2346,2807,2808],244,"subsequent Retry packets that it receives."]],"",[[[],0," "],[[221,2347,2804],244,"Clients MUST discard Retry packets that have a Retry Integrity Tag"]],[[[],0," "],[[221,2347,2804],244,"that cannot be validated; see Section 5.8 of [QUIC-TLS]."],[[],0," This"]]," diminishes an attacker's ability to inject a Retry packet and",[[[],0," protects against accidental corruption of Retry packets. "],[[222,2350,2805],244,"A client"]],[[[],0," "],[[222,2350,2805],244,"MUST discard a Retry packet with a zero-length Retry Token field."]],""," The client responds to a Retry packet with an Initial packet that"," includes the provided Retry token to continue connection"," establishment.",""," A client sets the Destination Connection ID field of this Initial"," packet to the value from the Source Connection ID field in the Retry"," packet. Changing the Destination Connection ID field also results in"," a change to the keys used to protect the Initial packet. It also",[[[],0," sets the Token field to the token provided in the Retry packet. "],[[223,2111,2114,2351,2797],244,"The"]],[[[],0," "],[[223,2111,2114,2351,2797],244,"client MUST NOT change the Source Connection ID because the server"]],[[[],0," "],[[223,2111,2114,2351,2797],244,"could include the connection ID as part of its token validation"]],[[[],0," "],[[223,2111,2114,2351,2797],244,"logic; see Section 8.1.4."]],""," A Retry packet does not include a packet number and cannot be"," explicitly acknowledged by a client."],"requirements":[219,220,221,222,223]},{"id":"section-17.2.5.3","title":"Continuing a Handshake after Retry","lines":[" Subsequent Initial packets from the client include the connection ID"," and token values from the Retry packet. The client copies the Source"," Connection ID field from the Retry packet to the Destination"," Connection ID field and uses this value until an Initial packet with"," an updated value is received; see Section 7.2. The value of the"," Token field is copied to all subsequent Initial packets; see"," Section 8.1.2.",""," Other than updating the Destination Connection ID and Token fields,"," the Initial packet sent by the client is subject to the same",[[[],0," restrictions as the first Initial packet. "],[[224,2206,2800],244,"A client MUST use the same"]],[[[],0," "],[[224,2206,2800],244,"cryptographic handshake message it included in this packet."],[[],0," "],[[225],96,"A server"]],[[[],0," "],[[225],96,"MAY treat a packet that contains a different cryptographic handshake"]],[[[],0," "],[[225],96,"message as a connection error or discard it."],[[],0," Note that including a"]]," Token field reduces the available space for the cryptographic"," handshake message, which might result in the client needing to send"," multiple Initial packets.","",[[[],0," "],[[226,2207],112,"A client MAY attempt 0-RTT after receiving a Retry packet by sending"]],[[[],0," "],[[226,2207],112,"0-RTT packets to the connection ID provided by the server."]],"",[[[],0," "],[[227,2801],228,"A client MUST NOT reset the packet number for any packet number space"]],[[[],0," "],[[227,2801],228,"after processing a Retry packet."],[[],0," In particular, 0-RTT packets"]]," contain confidential information that will most likely be"," retransmitted on receiving a Retry packet. The keys used to protect"," these new 0-RTT packets will not change as a result of responding to"," a Retry packet. However, the data sent in these packets could be"," different than what was sent earlier. Sending these new packets with"," the same packet number is likely to compromise the packet protection"," for those packets because the same key and nonce could be used to",[[[],0," protect different content. "],[[228],96,"A server MAY abort the connection if it"]],[[[],0," "],[[228],96,"detects that the client reset the packet number."]],""," The connection IDs used in Initial and Retry packets exchanged"," between client and server are copied to the transport parameters and"," validated as described in Section 7.3."],"requirements":[224,225,226,227,228]},{"id":"section-17.3","title":"Short Header Packets","lines":[" This version of QUIC defines a single packet type that uses the short"," packet header."]},{"id":"section-17.3.1","title":"1-RTT Packet","lines":[" A 1-RTT packet uses a short packet header. It is used after the"," version and 1-RTT keys are negotiated.",""," 1-RTT Packet {"," Header Form (1) = 0,"," Fixed Bit (1) = 1,"," Spin Bit (1),"," Reserved Bits (2),"," Key Phase (1),"," Packet Number Length (2),"," Destination Connection ID (0..160),"," Packet Number (8..32),"," Packet Payload (8..),"," }",""," Figure 19: 1-RTT Packet",""," 1-RTT packets contain the following fields:",""," Header Form: The most significant bit (0x80) of byte 0 is set to 0"," for the short header.","",[[[],0," Fixed Bit: The next bit (0x40) of byte 0 is set to 1. "],[[239,1671,3005,3011],244,"Packets"]],[[[],0," "],[[239,1671,3005,3011],244,"containing a zero value for this bit are not valid packets in this"]],[[[],0," "],[[239,1671,3005,3011],244,"version and MUST be discarded."],[[],0," A value of 1 for this bit allows"]]," QUIC to coexist with other protocols; see [RFC7983].",""," Spin Bit: The third most significant bit (0x20) of byte 0 is the"," latency spin bit, set as described in Section 17.4.",""," Reserved Bits: The next two bits (those with a mask of 0x18) of byte"," 0 are reserved. These bits are protected using header protection;",[[[],0," see Section 5.4 of [QUIC-TLS]. "],[[240,1659,2995],244,"The value included prior to"]],[[[],0," "],[[240,1659,2995],244,"protection MUST be set to 0."],[[],0," "],[[241,1672,3006],244,"An endpoint MUST treat receipt of a"]],[[[],0," "],[[241,1672,3006],244,"packet that has a non-zero value for these bits, after removing"]],[[[],0," "],[[241,1672,3006],244,"both packet and header protection, as a connection error of type"]],[[[],0," "],[[241,1672,3006],244,"PROTOCOL_VIOLATION."],[[],0," Discarding such a packet after only removing"]]," header protection can expose the endpoint to attacks; see"," Section 9.5 of [QUIC-TLS].",""," Key Phase: The next bit (0x04) of byte 0 indicates the key phase,"," which allows a recipient of a packet to identify the packet"," protection keys that are used to protect the packet. See"," [QUIC-TLS] for details. This bit is protected using header"," protection; see Section 5.4 of [QUIC-TLS].",""," Packet Number Length: The least significant two bits (those with a"," mask of 0x03) of byte 0 contain the length of the Packet Number"," field, encoded as an unsigned two-bit integer that is one less"," than the length of the Packet Number field in bytes. That is, the"," length of the Packet Number field is the value of this field plus"," one. These bits are protected using header protection; see"," Section 5.4 of [QUIC-TLS].",""," Destination Connection ID: The Destination Connection ID is a"," connection ID that is chosen by the intended recipient of the"," packet. See Section 5.1 for more details.",""," Packet Number: The Packet Number field is 1 to 4 bytes long. The"," packet number is protected using header protection; see"," Section 5.4 of [QUIC-TLS]. The length of the Packet Number field"," is encoded in Packet Number Length field. See Section 17.1 for"," details.",""," Packet Payload: 1-RTT packets always include a 1-RTT protected"," payload.",""," The header form bit and the Destination Connection ID field of a"," short header packet are version independent. The remaining fields"," are specific to the selected QUIC version. See [QUIC-INVARIANTS] for"," details on how packets from different versions of QUIC are"," interpreted."],"requirements":[239,240,241]},{"id":"section-17.4","title":"Latency Spin Bit","lines":[" The latency spin bit, which is defined for 1-RTT packets"," (Section 17.3.1), enables passive latency monitoring from observation"," points on the network path throughout the duration of a connection."," The server reflects the spin value received, while the client \"spins\""," it after one RTT. On-path observers can measure the time between two"," spin bit toggle events to estimate the end-to-end RTT of a"," connection.",""," The spin bit is only present in 1-RTT packets, since it is possible"," to measure the initial RTT of a connection by observing the"," handshake. Therefore, the spin bit is available after version"," negotiation and connection establishment are completed. On-path"," measurement and use of the latency spin bit are further discussed in"," [QUIC-MANAGEABILITY].","",[[[],0," "],[[242,1423,2358],112,"The spin bit is an OPTIONAL feature of this version of QUIC."],[[],0," "],[[243,1691,2529],244,"An"]],[[[],0," "],[[243,1691,2529],244,"endpoint that does not support this feature MUST disable it, as"]],[[[],0," "],[[243,1691,2529],244,"defined below."]],""," Each endpoint unilaterally decides if the spin bit is enabled or",[[[],0," disabled for a connection. "],[[244,1424,2359,2528],244,"Implementations MUST allow administrators"]],[[[],0," "],[[244,1424,2359,2528],244,"of clients and servers to disable the spin bit either globally or on"]],[[[],0," "],[[244,1424,2359,2528],244,"a per-connection basis."],[[],0," "],[[245,1690,1850,2531],244,"Even when the spin bit is not disabled by"]],[[[],0," "],[[245,1690,1850,2531],244,"the administrator, endpoints MUST disable their use of the spin bit"]],[[[],0," "],[[245,1690,1850,2531],244,"for a random selection of at least one in every 16 network paths, or"]],[[[],0," "],[[245,1690,1850,2531],244,"for one in every 16 connection IDs, in order to ensure that QUIC"]],[[[],0," "],[[245,1690,1850,2531],244,"connections that disable the spin bit are commonly observed on the"]],[[[],0," "],[[245,1690,1850,2531],244,"network."],[[],0," As each endpoint disables the spin bit independently, this"]]," ensures that the spin bit signal is disabled on approximately one in"," eight network paths.","",[[[],0," "],[[246,2071,2072,2527],244,"When the spin bit is disabled, endpoints MAY set the spin bit to any"]],[[[],0," "],[[246,2071,2072,2527],244,"value and MUST ignore any incoming value."],[[],0," "],[[247,2073,2530],180,"It is RECOMMENDED that"]],[[[],0," "],[[247,2073,2530],180,"endpoints set the spin bit to a random value either chosen"]],[[[],0," "],[[247,2073,2530],180,"independently for each packet or chosen independently for each"]],[[[],0," "],[[247,2073,2530],180,"connection ID."]],""," If the spin bit is enabled for the connection, the endpoint maintains"," a spin value for each network path and sets the spin bit in the"," packet header to the currently stored value when a 1-RTT packet is"," sent on that path. The spin value is initialized to 0 in the"," endpoint for each network path. Each endpoint also remembers the"," highest packet number seen from its peer on each path.",""," When a server receives a 1-RTT packet that increases the highest"," packet number seen by the server from the client on a given network"," path, it sets the spin value for that path to be equal to the spin"," bit in the received packet.",""," When a client receives a 1-RTT packet that increases the highest"," packet number seen by the client from the server on a given network"," path, it sets the spin value for that path to the inverse of the spin"," bit in the received packet.",""," An endpoint resets the spin value for a network path to 0 when"," changing the connection ID being used on that network path."],"requirements":[242,243,244,245,246,247]},{"id":"section-18","title":"Transport Parameter Encoding","lines":[" The extension_data field of the quic_transport_parameters extension"," defined in [QUIC-TLS] contains the QUIC transport parameters. They"," are encoded as a sequence of transport parameters, as shown in"," Figure 20:",""," Transport Parameters {"," Transport Parameter (..) ...,"," }",""," Figure 20: Sequence of Transport Parameters",""," Each transport parameter is encoded as an (identifier, length, value)"," tuple, as shown in Figure 21:",""," Transport Parameter {"," Transport Parameter ID (i),"," Transport Parameter Length (i),"," Transport Parameter Value (..),"," }",""," Figure 21: Transport Parameter Encoding",""," The Transport Parameter Length field contains the length of the"," Transport Parameter Value field in bytes.",""," QUIC encodes transport parameters into a sequence of bytes, which is"," then included in the cryptographic handshake."]},{"id":"section-18.1","title":"Reserved Transport Parameters","lines":[" Transport parameters with an identifier of the form \"31 * N + 27\" for"," integer values of N are reserved to exercise the requirement that"," unknown transport parameters be ignored. These transport parameters"," have no semantics and can carry arbitrary values."]},{"id":"section-18.2","title":"Transport Parameter Definitions","lines":[" This section details the transport parameters defined in this"," document.",""," Many transport parameters listed here have integer values. Those"," transport parameters that are identified as integers use a variable-"," length integer encoding; see Section 16. Transport parameters have a"," default value of 0 if the transport parameter is absent, unless"," otherwise stated.",""," The following transport parameters are defined:",""," original_destination_connection_id (0x00): This parameter is the"," value of the Destination Connection ID field from the first"," Initial packet sent by the client; see Section 7.3. This"," transport parameter is only sent by a server.",""," max_idle_timeout (0x01): The maximum idle timeout is a value in"," milliseconds that is encoded as an integer; see (Section 10.1)."," Idle timeout is disabled when both endpoints omit this transport"," parameter or specify a value of 0.",""," stateless_reset_token (0x02): A stateless reset token is used in"," verifying a stateless reset; see Section 10.3. This parameter is",[[[],0," a sequence of 16 bytes. "],[[248,2500,3041],244,"This transport parameter MUST NOT be sent"]],[[[],0," "],[[248,2500,3041],244,"by a client but MAY be sent by a server."],[[],0," A server that does not"]]," send this transport parameter cannot use stateless reset"," (Section 10.3) for the connection ID negotiated during the"," handshake.",""," max_udp_payload_size (0x03): The maximum UDP payload size parameter"," is an integer value that limits the size of UDP payloads that the"," endpoint is willing to receive. UDP datagrams with payloads"," larger than this limit are not likely to be processed by the"," receiver.",""," The default for this parameter is the maximum permitted UDP",[[[],0," payload of 65527. "],[[2493,3034],20,"Values below 1200 are invalid."]],""," This limit does act as an additional constraint on datagram size"," in the same way as the path MTU, but it is a property of the"," endpoint and not the path; see Section 14. It is expected that"," this is the space an endpoint dedicates to holding incoming"," packets.",""," initial_max_data (0x04): The initial maximum data parameter is an"," integer value that contains the initial value for the maximum"," amount of data that can be sent on the connection. This is"," equivalent to sending a MAX_DATA (Section 19.9) for the connection"," immediately after completing the handshake.",""," initial_max_stream_data_bidi_local (0x05): This parameter is an"," integer value specifying the initial flow control limit for"," locally initiated bidirectional streams. This limit applies to"," newly created bidirectional streams opened by the endpoint that"," sends the transport parameter. In client transport parameters,"," this applies to streams with an identifier with the least"," significant two bits set to 0x00; in server transport parameters,"," this applies to streams with the least significant two bits set to"," 0x01.",""," initial_max_stream_data_bidi_remote (0x06): This parameter is an"," integer value specifying the initial flow control limit for peer-"," initiated bidirectional streams. This limit applies to newly"," created bidirectional streams opened by the endpoint that receives"," the transport parameter. In client transport parameters, this"," applies to streams with an identifier with the least significant"," two bits set to 0x01; in server transport parameters, this applies"," to streams with the least significant two bits set to 0x00.",""," initial_max_stream_data_uni (0x07): This parameter is an integer"," value specifying the initial flow control limit for unidirectional"," streams. This limit applies to newly created unidirectional"," streams opened by the endpoint that receives the transport"," parameter. In client transport parameters, this applies to"," streams with an identifier with the least significant two bits set"," to 0x03; in server transport parameters, this applies to streams"," with the least significant two bits set to 0x02.",""," initial_max_streams_bidi (0x08): The initial maximum bidirectional"," streams parameter is an integer value that contains the initial"," maximum number of bidirectional streams the endpoint that receives"," this transport parameter is permitted to initiate. If this"," parameter is absent or zero, the peer cannot open bidirectional"," streams until a MAX_STREAMS frame is sent. Setting this parameter"," is equivalent to sending a MAX_STREAMS (Section 19.11) of the"," corresponding type with the same value.",""," initial_max_streams_uni (0x09): The initial maximum unidirectional"," streams parameter is an integer value that contains the initial"," maximum number of unidirectional streams the endpoint that"," receives this transport parameter is permitted to initiate. If"," this parameter is absent or zero, the peer cannot open"," unidirectional streams until a MAX_STREAMS frame is sent. Setting"," this parameter is equivalent to sending a MAX_STREAMS"," (Section 19.11) of the corresponding type with the same value.",""," ack_delay_exponent (0x0a): The acknowledgment delay exponent is an"," integer value indicating an exponent used to decode the ACK Delay"," field in the ACK frame (Section 19.3). If this value is absent, a"," default value of 3 is assumed (indicating a multiplier of 8)."," Values above 20 are invalid.",""," max_ack_delay (0x0b): The maximum acknowledgment delay is an integer"," value indicating the maximum amount of time in milliseconds by",[[[],0," which the endpoint will delay sending acknowledgments. "],[[249,2355],176,"This value"]],[[[],0," "],[[249,2355],176,"SHOULD include the receiver's expected delays in alarms firing."]]," For example, if a receiver sets a timer for 5ms and alarms"," commonly fire up to 1ms late, then it should send a max_ack_delay"," of 6ms. If this value is absent, a default of 25 milliseconds is",[[[],0," assumed. "],[[2498,3023],20,"Values of 2^14 or greater are invalid."]],""," disable_active_migration (0x0c): The disable active migration"," transport parameter is included if the endpoint does not support"," active connection migration (Section 9) on the address being used",[[[],0," during the handshake. "],[[250,1723,2755],244,"An endpoint that receives this transport"]],[[[],0," "],[[250,1723,2755],244,"parameter MUST NOT use a new local address when sending to the"]],[[[],0," "],[[250,1723,2755],244,"address that the peer used during the handshake."],[[],0," This transport"]]," parameter does not prohibit connection migration after a client"," has acted on a preferred_address transport parameter. This"," parameter is a zero-length value.",""," preferred_address (0x0d): The server's preferred address is used to"," effect a change in server address at the end of the handshake, as"," described in Section 9.6. This transport parameter is only sent",[[[],0," by a server. "],[[251,1427],112,"Servers MAY choose to only send a preferred address"]],[[[],0," "],[[251,1427],112,"of one address family by sending an all-zero address and port"]],[[[],0," "],[[251,1427],112,"(0.0.0.0:0 or [::]:0) for the other family."],[[],0," IP addresses are"]]," encoded in network byte order.",""," The preferred_address transport parameter contains an address and"," port for both IPv4 and IPv6. The four-byte IPv4 Address field is"," followed by the associated two-byte IPv4 Port field. This is"," followed by a 16-byte IPv6 Address field and two-byte IPv6 Port"," field. After address and port pairs, a Connection ID Length field"," describes the length of the following Connection ID field."," Finally, a 16-byte Stateless Reset Token field includes the"," stateless reset token associated with the connection ID. The"," format of this transport parameter is shown in Figure 22 below.",""," The Connection ID field and the Stateless Reset Token field"," contain an alternative connection ID that has a sequence number of"," 1; see Section 5.1.1. Having these values sent alongside the"," preferred address ensures that there will be at least one unused"," active connection ID when the client initiates migration to the"," preferred address.",""," The Connection ID and Stateless Reset Token fields of a preferred"," address are identical in syntax and semantics to the corresponding",[[[],0," fields of a NEW_CONNECTION_ID frame (Section 19.15). "],[[252,2514,2516,3044,3046],244,"A server"]],[[[],0," "],[[252,2514,2516,3044,3046],244,"that chooses a zero-length connection ID MUST NOT provide a"]],[[[],0," "],[[252,2514,2516,3044,3046],244,"preferred address."],[[],0," "],[[253,2476,2479,3048,3050],244,"Similarly, a server MUST NOT include a zero-"]],[[[],0," "],[[253,2476,2479,3048,3050],244,"length connection ID in this transport parameter."],[[],0," "],[[254,2477,2480,2515,2517,3045,3047,3049],244,"A client MUST"]],[[[],0," "],[[254,2477,2480,2515,2517,3045,3047,3049],244,"treat a violation of these requirements as a connection error of"]],[[[],0," "],[[254,2477,2480,2515,2517,3045,3047,3049],244,"type TRANSPORT_PARAMETER_ERROR."]],""," Preferred Address {"," IPv4 Address (32),"," IPv4 Port (16),"," IPv6 Address (128),"," IPv6 Port (16),"," Connection ID Length (8),"," Connection ID (..),"," Stateless Reset Token (128),"," }",""," Figure 22: Preferred Address Format",""," active_connection_id_limit (0x0e): This is an integer value"," specifying the maximum number of connection IDs from the peer that"," an endpoint is willing to store. This value includes the"," connection ID received during the handshake, that received in the"," preferred_address transport parameter, and those received in",[[[],0," NEW_CONNECTION_ID frames. "],[[255,2494,3028],244,"The value of the"]],[[[],0," "],[[255,2494,3028],244,"active_connection_id_limit parameter MUST be at least 2."],[[],0," "],[[256,2495,3029],244,"An"]],[[[],0," "],[[256,2495,3029],244,"endpoint that receives a value less than 2 MUST close the"]],[[[],0," "],[[256,2495,3029],244,"connection with an error of type TRANSPORT_PARAMETER_ERROR."],[[],0," If"]]," this transport parameter is absent, a default of 2 is assumed. If"," an endpoint issues a zero-length connection ID, it will never send"," a NEW_CONNECTION_ID frame and therefore ignores the"," active_connection_id_limit value received from its peer.",""," initial_source_connection_id (0x0f): This is the value that the"," endpoint included in the Source Connection ID field of the first"," Initial packet it sends for the connection; see Section 7.3.",""," retry_source_connection_id (0x10): This is the value that the server"," included in the Source Connection ID field of a Retry packet; see"," Section 7.3. This transport parameter is only sent by a server.",""," If present, transport parameters that set initial per-stream flow"," control limits (initial_max_stream_data_bidi_local,"," initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni)"," are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on"," every stream of the corresponding type immediately after opening. If"," the transport parameter is absent, streams of that type start with a"," flow control limit of 0.","",[[[],0," "],[[257,2501,3035,3037,3039,3042],244,"A client MUST NOT include any server-only transport parameter:"]],[[[],0," "],[[257,2501,3035,3037,3039,3042],244,"original_destination_connection_id, preferred_address,"]],[[[],0," "],[[257,2501,3035,3037,3039,3042],244,"retry_source_connection_id, or stateless_reset_token."],[[],0," "],[[258,2502,3036,3038,3040,3043],244,"A server MUST"]],[[[],0," "],[[258,2502,3036,3038,3040,3043],244,"treat receipt of any of these transport parameters as a connection"]],[[[],0," "],[[258,2502,3036,3038,3040,3043],244,"error of type TRANSPORT_PARAMETER_ERROR."]]],"requirements":[248,249,250,251,252,253,254,255,256,257,258]},{"id":"section-19","title":"Frame Types and Formats","lines":[" As described in Section 12.4, packets contain one or more frames."," This section describes the format and semantics of the core QUIC"," frame types."]},{"id":"section-19.1","title":"PADDING Frames","lines":[" A PADDING frame (type=0x00) has no semantic value. PADDING frames"," can be used to increase the size of a packet. Padding can be used to"," increase an Initial packet to the minimum required size or to provide"," protection against traffic analysis for protected packets.",""," PADDING frames are formatted as shown in Figure 23, which shows that"," PADDING frames have no content. That is, a PADDING frame consists of"," the single byte that identifies the frame as a PADDING frame.",""," PADDING Frame {"," Type (i) = 0x00,"," }",""," Figure 23: PADDING Frame Format"]},{"id":"section-19.2","title":"PING Frames","lines":[" Endpoints can use PING frames (type=0x01) to verify that their peers"," are still alive or to check reachability to the peer.",""," PING frames are formatted as shown in Figure 24, which shows that"," PING frames have no content.",""," PING Frame {"," Type (i) = 0x01,"," }",""," Figure 24: PING Frame Format",""," The receiver of a PING frame simply needs to acknowledge the packet"," containing this frame.",""," The PING frame can be used to keep a connection alive when an"," application or application protocol wishes to prevent the connection"," from timing out; see Section 10.1.2."]},{"id":"section-19.3","title":"ACK Frames","lines":[" Receivers send ACK frames (types 0x02 and 0x03) to inform senders of"," packets they have received and processed. The ACK frame contains one"," or more ACK Ranges. ACK Ranges identify acknowledged packets. If"," the frame type is 0x03, ACK frames also contain the cumulative count"," of QUIC packets with associated ECN marks received on the connection",[[[],0," up until this point. "],[[294,1643,1646,1649,1800,2534,2961,2962],244,"QUIC implementations MUST properly handle both"]],[[[],0," "],[[294,1643,1646,1649,1800,2534,2961,2962],244,"types, and, if they have enabled ECN for packets they send, they"]],[[[],0," "],[[294,1643,1646,1649,1800,2534,2961,2962],244,"SHOULD use the information in the ECN section to manage their"]],[[[],0," "],[[294,1643,1646,1649,1800,2534,2961,2962],244,"congestion state."]],""," QUIC acknowledgments are irrevocable. Once acknowledged, a packet"," remains acknowledged, even if it does not appear in a future ACK"," frame. This is unlike reneging for TCP Selective Acknowledgments"," (SACKs) [RFC2018].",""," Packets from different packet number spaces can be identified using"," the same numeric value. An acknowledgment for a packet needs to"," indicate both a packet number and a packet number space. This is"," accomplished by having each ACK frame only acknowledge packet numbers"," in the same space as the packet in which the ACK frame is contained.",""," Version Negotiation and Retry packets cannot be acknowledged because"," they do not contain a packet number. Rather than relying on ACK"," frames, these packets are implicitly acknowledged by the next Initial"," packet sent by the client.",""," ACK frames are formatted as shown in Figure 25.",""," ACK Frame {"," Type (i) = 0x02..0x03,"," Largest Acknowledged (i),"," ACK Delay (i),"," ACK Range Count (i),"," First ACK Range (i),"," ACK Range (..) ...,"," [ECN Counts (..)],"," }",""," Figure 25: ACK Frame Format",""," ACK frames contain the following fields:",""," Largest Acknowledged: A variable-length integer representing the"," largest packet number the peer is acknowledging; this is usually"," the largest packet number that the peer has received prior to"," generating the ACK frame. Unlike the packet number in the QUIC"," long or short header, the value in an ACK frame is not truncated.",""," ACK Delay: A variable-length integer encoding the acknowledgment"," delay in microseconds; see Section 13.2.5. It is decoded by"," multiplying the value in the field by 2 to the power of the"," ack_delay_exponent transport parameter sent by the sender of the"," ACK frame; see Section 18.2. Compared to simply expressing the"," delay as an integer, this encoding allows for a larger range of"," values within the same number of bytes, at the cost of lower"," resolution.",""," ACK Range Count: A variable-length integer specifying the number of"," ACK Range fields in the frame.",""," First ACK Range: A variable-length integer indicating the number of"," contiguous packets preceding the Largest Acknowledged that are"," being acknowledged. That is, the smallest packet acknowledged in"," the range is determined by subtracting the First ACK Range value"," from the Largest Acknowledged field.",""," ACK Ranges: Contains additional ranges of packets that are"," alternately not acknowledged (Gap) and acknowledged (ACK Range);"," see Section 19.3.1.",""," ECN Counts: The three ECN counts; see Section 19.3.2."],"requirements":[294]},{"id":"section-19.3.1","title":"ACK Ranges","lines":[" Each ACK Range consists of alternating Gap and ACK Range Length"," values in descending packet number order. ACK Ranges can be"," repeated. The number of Gap and ACK Range Length values is"," determined by the ACK Range Count field; one of each value is present"," for each value in the ACK Range Count field.",""," ACK Ranges are structured as shown in Figure 26.",""," ACK Range {"," Gap (i),"," ACK Range Length (i),"," }",""," Figure 26: ACK Ranges",""," The fields that form each ACK Range are:",""," Gap: A variable-length integer indicating the number of contiguous"," unacknowledged packets preceding the packet number one lower than"," the smallest in the preceding ACK Range.",""," ACK Range Length: A variable-length integer indicating the number of"," contiguous acknowledged packets preceding the largest packet"," number, as determined by the preceding Gap.",""," Gap and ACK Range Length values use a relative integer encoding for"," efficiency. Though each encoded value is positive, the values are"," subtracted, so that each ACK Range describes progressively lower-"," numbered packets.",""," Each ACK Range acknowledges a contiguous range of packets by"," indicating the number of acknowledged packets that precede the"," largest packet number in that range. A value of 0 indicates that"," only the largest packet number is acknowledged. Larger ACK Range"," values indicate a larger range, with corresponding lower values for"," the smallest packet number in the range. Thus, given a largest"," packet number for the range, the smallest value is determined by the"," following formula:",""," smallest = largest - ack_range",""," An ACK Range acknowledges all packets between the smallest packet"," number and the largest, inclusive.",""," The largest value for an ACK Range is determined by cumulatively"," subtracting the size of all preceding ACK Range Lengths and Gaps.",""," Each Gap indicates a range of packets that are not being"," acknowledged. The number of packets in the gap is one higher than"," the encoded value of the Gap field.",""," The value of the Gap field establishes the largest packet number"," value for the subsequent ACK Range using the following formula:",""," largest = previous_smallest - gap - 2","",[[[],0," "],[[293,1618,1619,1620,2967],244,"If any computed packet number is negative, an endpoint MUST generate"]],[[[],0," "],[[293,1618,1619,1620,2967],244,"a connection error of type FRAME_ENCODING_ERROR."]]],"requirements":[293]},{"id":"section-19.3.2","title":"ECN Counts","lines":[" The ACK frame uses the least significant bit of the type value (that"," is, type 0x03) to indicate ECN feedback and report receipt of QUIC"," packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE"," in the packet's IP header. ECN counts are only present when the ACK"," frame type is 0x03.",""," When present, there are three ECN counts, as shown in Figure 27.",""," ECN Counts {"," ECT0 Count (i),"," ECT1 Count (i),"," ECN-CE Count (i),"," }",""," Figure 27: ECN Count Format",""," The ECN count fields are:",""," ECT0 Count: A variable-length integer representing the total number"," of packets received with the ECT(0) codepoint in the packet number"," space of the ACK frame.",""," ECT1 Count: A variable-length integer representing the total number"," of packets received with the ECT(1) codepoint in the packet number"," space of the ACK frame.",""," ECN-CE Count: A variable-length integer representing the total"," number of packets received with the ECN-CE codepoint in the packet"," number space of the ACK frame.",""," ECN counts are maintained separately for each packet number space."]},{"id":"section-19.4","title":"RESET_STREAM Frames","lines":[" An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly"," terminate the sending part of a stream.",""," After sending a RESET_STREAM, an endpoint ceases transmission and"," retransmission of STREAM frames on the identified stream. A receiver"," of RESET_STREAM can discard any data that it already received on that"," stream.","",[[[],0," "],[[295,2032,2679],244,"An endpoint that receives a RESET_STREAM frame for a send-only stream"]],[[[],0," "],[[295,2032,2679],244,"MUST terminate the connection with error STREAM_STATE_ERROR."]],""," RESET_STREAM frames are formatted as shown in Figure 28.",""," RESET_STREAM Frame {"," Type (i) = 0x04,"," Stream ID (i),"," Application Protocol Error Code (i),"," Final Size (i),"," }",""," Figure 28: RESET_STREAM Frame Format",""," RESET_STREAM frames contain the following fields:",""," Stream ID: A variable-length integer encoding of the stream ID of"," the stream being terminated.",""," Application Protocol Error Code: A variable-length integer"," containing the application protocol error code (see Section 20.2)"," that indicates why the stream is being closed.",""," Final Size: A variable-length integer indicating the final size of"," the stream by the RESET_STREAM sender, in units of bytes; see"," Section 4.5."],"requirements":[295]},{"id":"section-19.5","title":"STOP_SENDING Frames","lines":[" An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that"," incoming data is being discarded on receipt per application request."," STOP_SENDING requests that a peer cease transmission on a stream.",""," A STOP_SENDING frame can be sent for streams in the \"Recv\" or \"Size",[[[],0," Known\" states; see Section 3.2. "],[[296,2042,2680],244,"Receiving a STOP_SENDING frame for a"]],[[[],0," "],[[296,2042,2680],244,"locally initiated stream that has not yet been created MUST be"]],[[[],0," "],[[296,2042,2680],244,"treated as a connection error of type STREAM_STATE_ERROR."],[[],0," "],[[297,2040,2681],244,"An"]],[[[],0," "],[[297,2040,2681],244,"endpoint that receives a STOP_SENDING frame for a receive-only stream"]],[[[],0," "],[[297,2040,2681],244,"MUST terminate the connection with error STREAM_STATE_ERROR."]],""," STOP_SENDING frames are formatted as shown in Figure 29.",""," STOP_SENDING Frame {"," Type (i) = 0x05,"," Stream ID (i),"," Application Protocol Error Code (i),"," }",""," Figure 29: STOP_SENDING Frame Format",""," STOP_SENDING frames contain the following fields:",""," Stream ID: A variable-length integer carrying the stream ID of the"," stream being ignored.",""," Application Protocol Error Code: A variable-length integer"," containing the application-specified reason the sender is ignoring"," the stream; see Section 20.2."],"requirements":[296,297]},{"id":"section-19.6","title":"CRYPTO Frames","lines":[" A CRYPTO frame (type=0x06) is used to transmit cryptographic"," handshake messages. It can be sent in all packet types except 0-RTT."," The CRYPTO frame offers the cryptographic protocol an in-order stream"," of bytes. CRYPTO frames are functionally identical to STREAM frames,"," except that they do not bear a stream identifier; they are not flow"," controlled; and they do not carry markers for optional offset,"," optional length, and the end of the stream.",""," CRYPTO frames are formatted as shown in Figure 30.",""," CRYPTO Frame {"," Type (i) = 0x06,"," Offset (i),"," Length (i),"," Crypto Data (..),"," }",""," Figure 30: CRYPTO Frame Format",""," CRYPTO frames contain the following fields:",""," Offset: A variable-length integer specifying the byte offset in the"," stream for the data in this CRYPTO frame.",""," Length: A variable-length integer specifying the length of the"," Crypto Data field in this CRYPTO frame.",""," Crypto Data: The cryptographic message data.",""," There is a separate flow of cryptographic handshake data in each"," encryption level, each of which starts at an offset of 0. This"," implies that each encryption level is treated as a separate CRYPTO"," stream of data.",""," The largest offset delivered on a stream -- the sum of the offset and",[[[],0," data length -- cannot exceed 2^62-1. "],[[298,1621,1622,1633,2968,2978],244,"Receipt of a frame that exceeds"]],[[[],0," "],[[298,1621,1622,1633,2968,2978],244,"this limit MUST be treated as a connection error of type"]],[[[],0," "],[[298,1621,1622,1633,2968,2978],244,"FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED."]],""," Unlike STREAM frames, which include a stream ID indicating to which"," stream the data belongs, the CRYPTO frame carries data for a single"," stream per encryption level. The stream does not have an explicit"," end, so CRYPTO frames do not have a FIN bit."],"requirements":[298]},{"id":"section-19.7","title":"NEW_TOKEN Frames","lines":[" A server sends a NEW_TOKEN frame (type=0x07) to provide the client"," with a token to send in the header of an Initial packet for a future"," connection.",""," NEW_TOKEN frames are formatted as shown in Figure 31.",""," NEW_TOKEN Frame {"," Type (i) = 0x07,"," Token Length (i),"," Token (..),"," }",""," Figure 31: NEW_TOKEN Frame Format",""," NEW_TOKEN frames contain the following fields:",""," Token Length: A variable-length integer specifying the length of the"," token in bytes.",""," Token: An opaque blob that the client can use with a future Initial",[[[],0," packet. "],[[299,1623,1634,2969,2979],244,"The token MUST NOT be empty."],[[],0," "],[[300,1624,2970],244,"A client MUST treat receipt"]],[[[],0," "],[[300,1624,2970],244,"of a NEW_TOKEN frame with an empty Token field as a connection"]],[[[],0," "],[[300,1624,2970],244,"error of type FRAME_ENCODING_ERROR."]],""," A client might receive multiple NEW_TOKEN frames that contain the"," same token value if packets containing the frame are incorrectly"," determined to be lost. Clients are responsible for discarding"," duplicate values, which might be used to link connection attempts;"," see Section 8.1.3.","",[[[],0," "],[[301,1744,2711],244,"Clients MUST NOT send NEW_TOKEN frames."],[[],0," "],[[302,1818,1826,2690],244,"A server MUST treat receipt"]],[[[],0," "],[[302,1818,1826,2690],244,"of a NEW_TOKEN frame as a connection error of type"]],[[[],0," "],[[302,1818,1826,2690],244,"PROTOCOL_VIOLATION."]]],"requirements":[299,300,301,302]},{"id":"section-19.8","title":"STREAM Frames","lines":[" STREAM frames implicitly create a stream and carry stream data. The"," Type field in the STREAM frame takes the form 0b00001XXX (or the set"," of values from 0x08 to 0x0f). The three low-order bits of the frame"," type determine the fields that are present in the frame:",""," * The OFF bit (0x04) in the frame type is set to indicate that there"," is an Offset field present. When set to 1, the Offset field is"," present. When set to 0, the Offset field is absent and the Stream"," Data starts at an offset of 0 (that is, the frame contains the"," first bytes of the stream, or the end of a stream that includes no"," data).",""," * The LEN bit (0x02) in the frame type is set to indicate that there"," is a Length field present. If this bit is set to 0, the Length"," field is absent and the Stream Data field extends to the end of"," the packet. If this bit is set to 1, the Length field is present.",""," * The FIN bit (0x01) indicates that the frame marks the end of the"," stream. The final size of the stream is the sum of the offset and"," the length of this frame.","",[[[],0," "],[[303,2031,2034,2842],244,"An endpoint MUST terminate the connection with error"]],[[[],0," "],[[303,2031,2034,2842],244,"STREAM_STATE_ERROR if it receives a STREAM frame for a locally"]],[[[],0," "],[[303,2031,2034,2842],244,"initiated stream that has not yet been created, or for a send-only"]],[[[],0," "],[[303,2031,2034,2842],244,"stream."]],""," STREAM frames are formatted as shown in Figure 32.",""," STREAM Frame {"," Type (i) = 0x08..0x0f,"," Stream ID (i),"," [Offset (i)],"," [Length (i)],"," Stream Data (..),"," }",""," Figure 32: STREAM Frame Format",""," STREAM frames contain the following fields:",""," Stream ID: A variable-length integer indicating the stream ID of the"," stream; see Section 2.1.",""," Offset: A variable-length integer specifying the byte offset in the"," stream for the data in this STREAM frame. This field is present"," when the OFF bit is set to 1. When the Offset field is absent,"," the offset is 0.",""," Length: A variable-length integer specifying the length of the"," Stream Data field in this STREAM frame. This field is present"," when the LEN bit is set to 1. When the LEN bit is set to 0, the"," Stream Data field consumes all the remaining bytes in the packet.",""," Stream Data: The bytes from the designated stream to be delivered.",""," When a Stream Data field has a length of 0, the offset in the STREAM"," frame is the offset of the next byte that would be sent.",""," The first byte in the stream has an offset of 0. The largest offset"," delivered on a stream -- the sum of the offset and data length --"," cannot exceed 2^62-1, as it is not possible to provide flow control",[[[],0," credit for that data. "],[[304,1625,1626,1635,2971,2980],244,"Receipt of a frame that exceeds this limit"]],[[[],0," "],[[304,1625,1626,1635,2971,2980],244,"MUST be treated as a connection error of type FRAME_ENCODING_ERROR or"]],[[[],0," "],[[304,1625,1626,1635,2971,2980],244,"FLOW_CONTROL_ERROR."]]],"requirements":[303,304]},{"id":"section-19.9","title":"MAX_DATA Frames","lines":[" A MAX_DATA frame (type=0x10) is used in flow control to inform the"," peer of the maximum amount of data that can be sent on the connection"," as a whole.",""," MAX_DATA frames are formatted as shown in Figure 33.",""," MAX_DATA Frame {"," Type (i) = 0x10,"," Maximum Data (i),"," }",""," Figure 33: MAX_DATA Frame Format",""," MAX_DATA frames contain the following field:",""," Maximum Data: A variable-length integer indicating the maximum"," amount of data that can be sent on the entire connection, in units"," of bytes.","",[[[],0," All data sent in STREAM frames counts toward this limit. "],[[305,2021,2650,2670],244,"The sum of"]],[[[],0," "],[[305,2021,2650,2670],244,"the final sizes on all streams -- including streams in terminal"]],[[[],0," "],[[305,2021,2650,2670],244,"states -- MUST NOT exceed the value advertised by a receiver."],[[],0," "],[[306,1828,2669,2676],244,"An"]],[[[],0," "],[[306,1828,2669,2676],244,"endpoint MUST terminate a connection with an error of type"]],[[[],0," "],[[306,1828,2669,2676],244,"FLOW_CONTROL_ERROR if it receives more data than the maximum data"]],[[[],0," "],[[306,1828,2669,2676],244,"value that it has sent."],[[],0," This includes violations of remembered"]]," limits in Early Data; see Section 7.4.1."],"requirements":[305,306]},{"id":"section-19.10","title":"MAX_STREAM_DATA Frames","lines":[" A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform"," a peer of the maximum amount of data that can be sent on a stream.",""," A MAX_STREAM_DATA frame can be sent for streams in the \"Recv\" state;",[[[],0," see Section 3.2. "],[[259,2043,2673,2682],244,"Receiving a MAX_STREAM_DATA frame for a locally"]],[[[],0," "],[[259,2043,2673,2682],244,"initiated stream that has not yet been created MUST be treated as a"]],[[[],0," "],[[259,2043,2673,2682],244,"connection error of type STREAM_STATE_ERROR."],[[],0," "],[[260,2041,2674,2683],244,"An endpoint that"]],[[[],0," "],[[260,2041,2674,2683],244,"receives a MAX_STREAM_DATA frame for a receive-only stream MUST"]],[[[],0," "],[[260,2041,2674,2683],244,"terminate the connection with error STREAM_STATE_ERROR."]],""," MAX_STREAM_DATA frames are formatted as shown in Figure 34.",""," MAX_STREAM_DATA Frame {"," Type (i) = 0x11,"," Stream ID (i),"," Maximum Stream Data (i),"," }",""," Figure 34: MAX_STREAM_DATA Frame Format",""," MAX_STREAM_DATA frames contain the following fields:",""," Stream ID: The stream ID of the affected stream, encoded as a"," variable-length integer.",""," Maximum Stream Data: A variable-length integer indicating the"," maximum amount of data that can be sent on the identified stream,"," in units of bytes.",""," When counting data toward this limit, an endpoint accounts for the"," largest received offset of data that is sent or received on the"," stream. Loss or reordering can mean that the largest received offset"," on a stream can be greater than the total size of data received on"," that stream. Receiving STREAM frames might not increase the largest"," received offset.","",[[[],0," "],[[261,2470,3077],244,"The data sent on a stream MUST NOT exceed the largest maximum stream"]],[[[],0," "],[[261,2470,3077],244,"data value advertised by the receiver."],[[],0," "],[[262,2449,2672,2678,3081],244,"An endpoint MUST terminate a"]],[[[],0," "],[[262,2449,2672,2678,3081],244,"connection with an error of type FLOW_CONTROL_ERROR if it receives"]],[[[],0," "],[[262,2449,2672,2678,3081],244,"more data than the largest maximum stream data that it has sent for"]],[[[],0," "],[[262,2449,2672,2678,3081],244,"the affected stream."],[[],0," This includes violations of remembered limits"]]," in Early Data; see Section 7.4.1."],"requirements":[259,260,261,262]},{"id":"section-19.11","title":"MAX_STREAMS Frames","lines":[" A MAX_STREAMS frame (type=0x12 or 0x13) informs the peer of the"," cumulative number of streams of a given type it is permitted to open."," A MAX_STREAMS frame with a type of 0x12 applies to bidirectional"," streams, and a MAX_STREAMS frame with a type of 0x13 applies to"," unidirectional streams.",""," MAX_STREAMS frames are formatted as shown in Figure 35.",""," MAX_STREAMS Frame {"," Type (i) = 0x12..0x13,"," Maximum Streams (i),"," }",""," Figure 35: MAX_STREAMS Frame Format",""," MAX_STREAMS frames contain the following field:",""," Maximum Streams: A count of the cumulative number of streams of the"," corresponding type that can be opened over the lifetime of the"," connection. This value cannot exceed 2^60, as it is not possible",[[[],0," to encode stream IDs larger than 2^62-1. "],[[263,1627,1636,2972,2981],244,"Receipt of a frame that"]],[[[],0," "],[[263,1627,1636,2972,2981],244,"permits opening of a stream larger than this limit MUST be treated"]],[[[],0," "],[[263,1627,1636,2972,2981],244,"as a connection error of type FRAME_ENCODING_ERROR."]],""," Loss or reordering can cause an endpoint to receive a MAX_STREAMS"," frame with a lower stream limit than was previously received.",[[[],0," "],[[264,2444,2847],244,"MAX_STREAMS frames that do not increase the stream limit MUST be"]],[[[],0," "],[[264,2444,2847],244,"ignored."]],"",[[[],0," "],[[265,2440,3079],244,"An endpoint MUST NOT open more streams than permitted by the current"]],[[[],0," "],[[265,2440,3079],244,"stream limit set by its peer."],[[],0," For instance, a server that receives a"]]," unidirectional stream limit of 3 is permitted to open streams 3, 7,",[[[],0," and 11, but not stream 15. "],[[266,2036,2653],244,"An endpoint MUST terminate a connection"]],[[[],0," "],[[266,2036,2653],244,"with an error of type STREAM_LIMIT_ERROR if a peer opens more streams"]],[[[],0," "],[[266,2036,2653],244,"than was permitted."],[[],0," This includes violations of remembered limits in"]]," Early Data; see Section 7.4.1.",""," Note that these frames (and the corresponding transport parameters)"," do not describe the number of streams that can be opened"," concurrently. The limit includes streams that have been closed as"," well as those that are open."],"requirements":[263,264,265,266]},{"id":"section-19.12","title":"DATA_BLOCKED Frames","lines":[[[[],0," "],[[267,2044,2654],180,"A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes"]],[[[],0," "],[[267,2044,2654],180,"to send data but is unable to do so due to connection-level flow"]],[[[],0," "],[[267,2044,2654],180,"control; see Section 4."],[[],0," DATA_BLOCKED frames can be used as input to"]]," tuning of flow control algorithms; see Section 4.2.",""," DATA_BLOCKED frames are formatted as shown in Figure 36.",""," DATA_BLOCKED Frame {"," Type (i) = 0x14,"," Maximum Data (i),"," }",""," Figure 36: DATA_BLOCKED Frame Format",""," DATA_BLOCKED frames contain the following field:",""," Maximum Data: A variable-length integer indicating the connection-"," level limit at which blocking occurred."],"requirements":[267]},{"id":"section-19.13","title":"STREAM_DATA_BLOCKED Frames","lines":[[[[],0," "],[[268,2463,3093],180,"A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it"]],[[[],0," "],[[268,2463,3093],180,"wishes to send data but is unable to do so due to stream-level flow"]],[[[],0," "],[[268,2463,3093],180,"control."],[[],0," This frame is analogous to DATA_BLOCKED (Section 19.12)."]],"",[[[],0," "],[[269,2033,2675,2684],244,"An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only"]],[[[],0," "],[[269,2033,2675,2684],244,"stream MUST terminate the connection with error STREAM_STATE_ERROR."]],""," STREAM_DATA_BLOCKED frames are formatted as shown in Figure 37.",""," STREAM_DATA_BLOCKED Frame {"," Type (i) = 0x15,"," Stream ID (i),"," Maximum Stream Data (i),"," }",""," Figure 37: STREAM_DATA_BLOCKED Frame Format",""," STREAM_DATA_BLOCKED frames contain the following fields:",""," Stream ID: A variable-length integer indicating the stream that is"," blocked due to flow control.",""," Maximum Stream Data: A variable-length integer indicating the offset"," of the stream at which the blocking occurred."],"requirements":[268,269]},{"id":"section-19.14","title":"STREAMS_BLOCKED Frames","lines":[[[[],0," "],[[270,2028,2841],180,"A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when"]],[[[],0," "],[[270,2028,2841],180,"it wishes to open a stream but is unable to do so due to the maximum"]],[[[],0," "],[[270,2028,2841],180,"stream limit set by its peer; see Section 19.11."],[[],0," A STREAMS_BLOCKED"]]," frame of type 0x16 is used to indicate reaching the bidirectional"," stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to"," indicate reaching the unidirectional stream limit.",""," A STREAMS_BLOCKED frame does not open the stream, but informs the"," peer that a new stream was needed and the stream limit prevented the"," creation of the stream.",""," STREAMS_BLOCKED frames are formatted as shown in Figure 38.",""," STREAMS_BLOCKED Frame {"," Type (i) = 0x16..0x17,"," Maximum Streams (i),"," }",""," Figure 38: STREAMS_BLOCKED Frame Format",""," STREAMS_BLOCKED frames contain the following field:",""," Maximum Streams: A variable-length integer indicating the maximum"," number of streams allowed at the time the frame was sent. This"," value cannot exceed 2^60, as it is not possible to encode stream",[[[],0," IDs larger than 2^62-1. "],[[271,1629,1638,2974,2983],244,"Receipt of a frame that encodes a larger"]],[[[],0," "],[[271,1629,1638,2974,2983],244,"stream ID MUST be treated as a connection error of type"]],[[[],0," "],[[271,1629,1638,2974,2983],244,"STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR."]]],"requirements":[270,271]},{"id":"section-19.15","title":"NEW_CONNECTION_ID Frames","lines":[" An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide"," its peer with alternative connection IDs that can be used to break"," linkability when migrating connections; see Section 9.5.",""," NEW_CONNECTION_ID frames are formatted as shown in Figure 39.",""," NEW_CONNECTION_ID Frame {"," Type (i) = 0x18,"," Sequence Number (i),"," Retire Prior To (i),"," Length (8),"," Connection ID (8..160),"," Stateless Reset Token (128),"," }",""," Figure 39: NEW_CONNECTION_ID Frame Format",""," NEW_CONNECTION_ID frames contain the following fields:",""," Sequence Number: The sequence number assigned to the connection ID"," by the sender, encoded as a variable-length integer; see"," Section 5.1.1.",""," Retire Prior To: A variable-length integer indicating which"," connection IDs should be retired; see Section 5.1.2.",""," Length: An 8-bit unsigned integer containing the length of the",[[[],0," connection ID. "],[[272,1630,1639,2975,2984],244,"Values less than 1 and greater than 20 are invalid"]],[[[],0," "],[[272,1630,1639,2975,2984],244,"and MUST be treated as a connection error of type"]],[[[],0," "],[[272,1630,1639,2975,2984],244,"FRAME_ENCODING_ERROR."]],""," Connection ID: A connection ID of the specified length.",""," Stateless Reset Token: A 128-bit value that will be used for a"," stateless reset when the associated connection ID is used; see"," Section 10.3.","",[[[],0," "],[[273,1969,2613],244,"An endpoint MUST NOT send this frame if it currently requires that"]],[[[],0," "],[[273,1969,2613],244,"its peer send packets with a zero-length Destination Connection ID."]]," Changing the length of a connection ID to or from zero length makes"," it difficult to identify when the value of the connection ID changed.",[[[],0," "],[[274,1947,2606],244,"An endpoint that is sending packets with a zero-length Destination"]],[[[],0," "],[[274,1947,2606],244,"Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a"]],[[[],0," "],[[274,1947,2606],244,"connection error of type PROTOCOL_VIOLATION."]],""," Transmission errors, timeouts, and retransmissions might cause the",[[[],0," same NEW_CONNECTION_ID frame to be received multiple times. "],[[275,1951,2605],244,"Receipt"]],[[[],0," "],[[275,1951,2605],244,"of the same frame multiple times MUST NOT be treated as a connection"]],[[[],0," "],[[275,1951,2605],244,"error."],[[],0," A receiver can use the sequence number supplied in the"]]," NEW_CONNECTION_ID frame to handle receiving the same"," NEW_CONNECTION_ID frame multiple times.","",[[[],0," "],[[276,1950,1953],112,"If an endpoint receives a NEW_CONNECTION_ID frame that repeats a"]],[[[],0," "],[[276,1950,1953],112,"previously issued connection ID with a different Stateless Reset"]],[[[],0," "],[[276,1950,1953],112,"Token field value or a different Sequence Number field value, or if a"]],[[[],0," "],[[276,1950,1953],112,"sequence number is used for different connection IDs, the endpoint"]],[[[],0," "],[[276,1950,1953],112,"MAY treat that receipt as a connection error of type"]],[[[],0," "],[[276,1950,1953],112,"PROTOCOL_VIOLATION."]],""," The Retire Prior To field applies to connection IDs established"," during connection setup and the preferred_address transport",[[[],0," parameter; see Section 5.1.2. "],[[277,1631,1640,2599,2976,2985],244,"The value in the Retire Prior To field"]],[[[],0," "],[[277,1631,1640,2599,2976,2985],244,"MUST be less than or equal to the value in the Sequence Number field."]],[[[],0," "],[[278,1632,1641,2600,2977,2986],244,"Receiving a value in the Retire Prior To field that is greater than"]],[[[],0," "],[[278,1632,1641,2600,2977,2986],244,"that in the Sequence Number field MUST be treated as a connection"]],[[[],0," "],[[278,1632,1641,2600,2977,2986],244,"error of type FRAME_ENCODING_ERROR."]],""," Once a sender indicates a Retire Prior To value, smaller values sent",[[[],0," in subsequent NEW_CONNECTION_ID frames have no effect. "],[[279,1948,2602],244,"A receiver"]],[[[],0," "],[[279,1948,2602],244,"MUST ignore any Retire Prior To fields that do not increase the"]],[[[],0," "],[[279,1948,2602],244,"largest received Retire Prior To value."]],"",[[[],0," "],[[280,1955,2603,2604],244,"An endpoint that receives a NEW_CONNECTION_ID frame with a sequence"]],[[[],0," "],[[280,1955,2603,2604],244,"number smaller than the Retire Prior To field of a previously"]],[[[],0," "],[[280,1955,2603,2604],244,"received NEW_CONNECTION_ID frame MUST send a corresponding"]],[[[],0," "],[[280,1955,2603,2604],244,"RETIRE_CONNECTION_ID frame that retires the newly received connection"]],[[[],0," "],[[280,1955,2603,2604],244,"ID, unless it has already done so for that sequence number."]]],"requirements":[272,273,274,275,276,277,278,279,280]},{"id":"section-19.16","title":"RETIRE_CONNECTION_ID Frames","lines":[" An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to"," indicate that it will no longer use a connection ID that was issued"," by its peer. This includes the connection ID provided during the"," handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a"," request to the peer to send additional connection IDs for future use;"," see Section 5.1. New connection IDs can be delivered to a peer using"," the NEW_CONNECTION_ID frame (Section 19.15).",""," Retiring a connection ID invalidates the stateless reset token"," associated with that connection ID.",""," RETIRE_CONNECTION_ID frames are formatted as shown in Figure 40.",""," RETIRE_CONNECTION_ID Frame {"," Type (i) = 0x19,"," Sequence Number (i),"," }",""," Figure 40: RETIRE_CONNECTION_ID Frame Format",""," RETIRE_CONNECTION_ID frames contain the following field:",""," Sequence Number: The sequence number of the connection ID being"," retired; see Section 5.1.2.","",[[[],0," "],[[281,1967,2610],244,"Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number"]],[[[],0," "],[[281,1967,2610],244,"greater than any previously sent to the peer MUST be treated as a"]],[[[],0," "],[[281,1967,2610],244,"connection error of type PROTOCOL_VIOLATION."]],"",[[[],0," "],[[282,1963,2633],244,"The sequence number specified in a RETIRE_CONNECTION_ID frame MUST"]],[[[],0," "],[[282,1963,2633],244,"NOT refer to the Destination Connection ID field of the packet in"]],[[[],0," "],[[282,1963,2633],244,"which the frame is contained."],[[],0," "],[[283],96,"The peer MAY treat this as a"]],[[[],0," "],[[283],96,"connection error of type PROTOCOL_VIOLATION."]],""," An endpoint cannot send this frame if it was provided with a zero-",[[[],0," length connection ID by its peer. "],[[284,1966,2607],244,"An endpoint that provides a zero-"]],[[[],0," "],[[284,1966,2607],244,"length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID"]],[[[],0," "],[[284,1966,2607],244,"frame as a connection error of type PROTOCOL_VIOLATION."]]],"requirements":[281,282,283,284]},{"id":"section-19.17","title":"PATH_CHALLENGE Frames","lines":[" Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check"," reachability to the peer and for path validation during connection"," migration.",""," PATH_CHALLENGE frames are formatted as shown in Figure 41.",""," PATH_CHALLENGE Frame {"," Type (i) = 0x1a,"," Data (64),"," }",""," Figure 41: PATH_CHALLENGE Frame Format",""," PATH_CHALLENGE frames contain the following field:",""," Data: This 8-byte field contains arbitrary data.",""," Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that"," it is easier to receive the packet than it is to guess the value"," correctly.","",[[[],0," "],[[285,1943,2761],244,"The recipient of this frame MUST generate a PATH_RESPONSE frame"]],[[[],0," "],[[285,1943,2761],244,"(Section 19.18) containing the same Data value."]]],"requirements":[285]},{"id":"section-19.18","title":"PATH_RESPONSE Frames","lines":[" A PATH_RESPONSE frame (type=0x1b) is sent in response to a"," PATH_CHALLENGE frame.",""," PATH_RESPONSE frames are formatted as shown in Figure 42. The format"," of a PATH_RESPONSE frame is identical to that of the PATH_CHALLENGE"," frame; see Section 19.17.",""," PATH_RESPONSE Frame {"," Type (i) = 0x1b,"," Data (64),"," }",""," Figure 42: PATH_RESPONSE Frame Format","",[[[],0," "],[[286],96,"If the content of a PATH_RESPONSE frame does not match the content of"]],[[[],0," "],[[286],96,"a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint"]],[[[],0," "],[[286],96,"MAY generate a connection error of type PROTOCOL_VIOLATION."]]],"requirements":[286]},{"id":"section-19.19","title":"CONNECTION_CLOSE Frames","lines":[" An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to"," notify its peer that the connection is being closed. The"," CONNECTION_CLOSE frame with a type of 0x1c is used to signal errors"," at only the QUIC layer, or the absence of errors (with the NO_ERROR"," code). The CONNECTION_CLOSE frame with a type of 0x1d is used to"," signal an error with the application that uses QUIC.",""," If there are open streams that have not been explicitly closed, they"," are implicitly closed when the connection is closed.",""," CONNECTION_CLOSE frames are formatted as shown in Figure 43.",""," CONNECTION_CLOSE Frame {"," Type (i) = 0x1c..0x1d,"," Error Code (i),"," [Frame Type (i)],"," Reason Phrase Length (i),"," Reason Phrase (..),"," }",""," Figure 43: CONNECTION_CLOSE Frame Format",""," CONNECTION_CLOSE frames contain the following fields:",""," Error Code: A variable-length integer that indicates the reason for"," closing this connection. A CONNECTION_CLOSE frame of type 0x1c"," uses codes from the space defined in Section 20.1. A"," CONNECTION_CLOSE frame of type 0x1d uses codes defined by the"," application protocol; see Section 20.2.",""," Frame Type: A variable-length integer encoding the type of frame"," that triggered the error. A value of 0 (equivalent to the mention"," of the PADDING frame) is used when the frame type is unknown. The"," application-specific variant of CONNECTION_CLOSE (type 0x1d) does"," not include this field.",""," Reason Phrase Length: A variable-length integer specifying the"," length of the reason phrase in bytes. Because a CONNECTION_CLOSE"," frame cannot be split between packets, any limits on packet size"," will also limit the space available for a reason phrase.",""," Reason Phrase: Additional diagnostic information for the closure."," This can be zero length if the sender chooses not to give details",[[[],0," beyond the Error Code value. "],[[287,1742,2831],180,"This SHOULD be a UTF-8 encoded"]],[[[],0," "],[[287,1742,2831],180,"string [RFC3629], though the frame does not carry information,"]],[[[],0," "],[[287,1742,2831],180,"such as language tags, that would aid comprehension by any entity"]],[[[],0," "],[[287,1742,2831],180,"other than the one that created the text."]],""," The application-specific variant of CONNECTION_CLOSE (type 0x1d) can"," only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an"," application wishes to abandon a connection during the handshake, an"," endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error"," code of APPLICATION_ERROR in an Initial or Handshake packet."],"requirements":[287]},{"id":"section-19.20","title":"HANDSHAKE_DONE Frames","lines":[" The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal"," confirmation of the handshake to the client.",""," HANDSHAKE_DONE frames are formatted as shown in Figure 44, which"," shows that HANDSHAKE_DONE frames have no content.",""," HANDSHAKE_DONE Frame {"," Type (i) = 0x1e,"," }",""," Figure 44: HANDSHAKE_DONE Frame Format","",[[[],0," A HANDSHAKE_DONE frame can only be sent by the server. "],[[288,1922,2155,2667,2699],244,"Servers MUST"]],[[[],0," "],[[288,1922,2155,2667,2699],244,"NOT send a HANDSHAKE_DONE frame before completing the handshake."],[[],0," "],[[],0,"A"]],[[[],0," "],[[289,1819,1827,2685,2689],244,"server MUST treat receipt of a HANDSHAKE_DONE frame as a connection"]],[[[],0," "],[[289,1819,1827,2685,2689],244,"error of type PROTOCOL_VIOLATION."]]],"requirements":[288,289]},{"id":"section-19.21","title":"Extension Frames","lines":[" QUIC frames do not use a self-describing encoding. An endpoint"," therefore needs to understand the syntax of all frames before it can"," successfully process a packet. This allows for efficient encoding of"," frames, but it means that an endpoint cannot send a frame of a type"," that is unknown to its peer.","",[[[],0," "],[[290,1718,2825],244,"An extension to QUIC that wishes to use a new type of frame MUST"]],[[[],0," "],[[290,1718,2825],244,"first ensure that a peer is able to understand the frame."],[[],0," An"]]," endpoint can use a transport parameter to signal its willingness to"," receive extension frame types. One transport parameter can indicate"," support for one or more extension frame types.",""," Extensions that modify or replace core protocol functionality"," (including frame types) will be difficult to combine with other"," extensions that modify or replace the same functionality unless the",[[[],0," behavior of the combination is explicitly defined. "],[[31,291],162,"Such extensions"]],[[[],0," "],[[31,291],162,"SHOULD define their interaction with previously defined extensions"]],[[[],0," "],[[31,291],162,"modifying the same protocol components."]],"",[[[],0," "],[[292,1865,2163,2836],244,"Extension frames MUST be congestion controlled and MUST cause an ACK"]],[[[],0," "],[[292,1865,2163,2836],244,"frame to be sent."],[[],0," The exception is extension frames that replace or"]]," supplement the ACK frame. Extension frames are not included in flow"," control unless specified in the extension.",""," An IANA registry is used to manage the assignment of frame types; see"," Section 22.4."],"requirements":[290,291,292]},{"id":"section-20","title":"Error Codes","lines":[" QUIC transport error codes and application error codes are 62-bit"," unsigned integers."]},{"id":"section-20.1","title":"Transport Error Codes","lines":[" This section lists the defined QUIC transport error codes that can be"," used in a CONNECTION_CLOSE frame with a type of 0x1c. These errors"," apply to the entire connection.",""," NO_ERROR (0x00): An endpoint uses this with CONNECTION_CLOSE to"," signal that the connection is being closed abruptly in the absence"," of any error.",""," INTERNAL_ERROR (0x01): The endpoint encountered an internal error"," and cannot continue with the connection.",""," CONNECTION_REFUSED (0x02): The server refused to accept a new"," connection.",""," FLOW_CONTROL_ERROR (0x03): An endpoint received more data than it"," permitted in its advertised data limits; see Section 4.",""," STREAM_LIMIT_ERROR (0x04): An endpoint received a frame for a stream"," identifier that exceeded its advertised stream limit for the"," corresponding stream type.",""," STREAM_STATE_ERROR (0x05): An endpoint received a frame for a stream"," that was not in a state that permitted that frame; see Section 3.",""," FINAL_SIZE_ERROR (0x06): (1) An endpoint received a STREAM frame"," containing data that exceeded the previously established final"," size, (2) an endpoint received a STREAM frame or a RESET_STREAM"," frame containing a final size that was lower than the size of"," stream data that was already received, or (3) an endpoint received"," a STREAM frame or a RESET_STREAM frame containing a different"," final size to the one already established.",""," FRAME_ENCODING_ERROR (0x07): An endpoint received a frame that was"," badly formatted -- for instance, a frame of an unknown type or an"," ACK frame that has more acknowledgment ranges than the remainder"," of the packet could carry.",""," TRANSPORT_PARAMETER_ERROR (0x08): An endpoint received transport"," parameters that were badly formatted, included an invalid value,"," omitted a mandatory transport parameter, included a forbidden"," transport parameter, or were otherwise in error.",""," CONNECTION_ID_LIMIT_ERROR (0x09): The number of connection IDs"," provided by the peer exceeds the advertised"," active_connection_id_limit.",""," PROTOCOL_VIOLATION (0x0a): An endpoint detected an error with"," protocol compliance that was not covered by more specific error"," codes.",""," INVALID_TOKEN (0x0b): A server received a client Initial that"," contained an invalid Token field.",""," APPLICATION_ERROR (0x0c): The application or application protocol"," caused the connection to be closed.",""," CRYPTO_BUFFER_EXCEEDED (0x0d): An endpoint has received more data in"," CRYPTO frames than it can buffer.",""," KEY_UPDATE_ERROR (0x0e): An endpoint detected errors in performing"," key updates; see Section 6 of [QUIC-TLS].",""," AEAD_LIMIT_REACHED (0x0f): An endpoint has reached the"," confidentiality or integrity limit for the AEAD algorithm used by"," the given connection.",""," NO_VIABLE_PATH (0x10): An endpoint has determined that the network"," path is incapable of supporting QUIC. An endpoint is unlikely to"," receive a CONNECTION_CLOSE frame carrying this code except when"," the path does not support a large enough MTU.",""," CRYPTO_ERROR (0x0100-0x01ff): The cryptographic handshake failed. A"," range of 256 values is reserved for carrying error codes specific"," to the cryptographic handshake that is used. Codes for errors"," occurring when TLS is used for the cryptographic handshake are"," described in Section 4.8 of [QUIC-TLS].",""," See Section 22.5 for details on registering new error codes.",""," In defining these error codes, several principles are applied. Error"," conditions that might require specific action on the part of a"," recipient are given unique codes. Errors that represent common"," conditions are given specific codes. Absent either of these"," conditions, error codes are used to identify a general function of"," the stack, like flow control or transport parameter handling."," Finally, generic errors are provided for conditions where"," implementations are unable or unwilling to use more specific codes."]},{"id":"section-20.2","title":"Application Protocol Error Codes","lines":[" The management of application error codes is left to application"," protocols. Application protocol error codes are used for the"," RESET_STREAM frame (Section 19.4), the STOP_SENDING frame"," (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d"," (Section 19.19)."]},{"id":"section-21","title":"Security Considerations","lines":[" The goal of QUIC is to provide a secure transport connection."," Section 21.1 provides an overview of those properties; subsequent"," sections discuss constraints and caveats regarding these properties,"," including descriptions of known attacks and countermeasures."]},{"id":"section-21.1","title":"Overview of Security Properties","lines":[" A complete security analysis of QUIC is outside the scope of this"," document. This section provides an informal description of the"," desired security properties as an aid to implementers and to help"," guide protocol analysis.",""," QUIC assumes the threat model described in [SEC-CONS] and provides"," protections against many of the attacks that arise from that model.",""," For this purpose, attacks are divided into passive and active"," attacks. Passive attackers have the ability to read packets from the"," network, while active attackers also have the ability to write"," packets into the network. However, a passive attack could involve an"," attacker with the ability to cause a routing change or other"," modification in the path taken by packets that comprise a connection.",""," Attackers are additionally categorized as either on-path attackers or"," off-path attackers. An on-path attacker can read, modify, or remove"," any packet it observes such that the packet no longer reaches its"," destination, while an off-path attacker observes the packets but"," cannot prevent the original packet from reaching its intended"," destination. Both types of attackers can also transmit arbitrary"," packets. This definition differs from that of Section 3.5 of"," [SEC-CONS] in that an off-path attacker is able to observe packets.",""," Properties of the handshake, protected packets, and connection"," migration are considered separately."]},{"id":"section-21.1.1","title":"Handshake","lines":[" The QUIC handshake incorporates the TLS 1.3 handshake and inherits"," the cryptographic properties described in Appendix E.1 of [TLS13]."," Many of the security properties of QUIC depend on the TLS handshake"," providing these properties. Any attack on the TLS handshake could"," affect QUIC.",""," Any attack on the TLS handshake that compromises the secrecy or"," uniqueness of session keys, or the authentication of the"," participating peers, affects other security guarantees provided by"," QUIC that depend on those keys. For instance, migration (Section 9)"," depends on the efficacy of confidentiality protections, both for the"," negotiation of keys using the TLS handshake and for QUIC packet"," protection, to avoid linkability across network paths.",""," An attack on the integrity of the TLS handshake might allow an"," attacker to affect the selection of application protocol or QUIC"," version.",""," In addition to the properties provided by TLS, the QUIC handshake"," provides some defense against DoS attacks on the handshake."]},{"id":"section-21.1.1.1","title":"Anti-Amplification","lines":[" Address validation (Section 8) is used to verify that an entity that"," claims a given address is able to receive packets at that address."," Address validation limits amplification attack targets to addresses"," for which an attacker can observe packets.",""," Prior to address validation, endpoints are limited in what they are"," able to send. Endpoints cannot send data toward an unvalidated"," address in excess of three times the data received from that address.",""," | Note: The anti-amplification limit only applies when an"," | endpoint responds to packets received from an unvalidated"," | address. The anti-amplification limit does not apply to"," | clients when establishing a new connection or when initiating"," | connection migration."]},{"id":"section-21.1.1.2","title":"Server-Side DoS","lines":[" Computing the server's first flight for a full handshake is"," potentially expensive, requiring both a signature and a key exchange"," computation. In order to prevent computational DoS attacks, the"," Retry packet provides a cheap token exchange mechanism that allows"," servers to validate a client's IP address prior to doing any"," expensive computations at the cost of a single round trip. After a"," successful handshake, servers can issue new tokens to a client, which"," will allow new connection establishment without incurring this cost."]},{"id":"section-21.1.1.3","title":"On-Path Handshake Termination","lines":[" An on-path or off-path attacker can force a handshake to fail by"," replacing or racing Initial packets. Once valid Initial packets have"," been exchanged, subsequent Handshake packets are protected with the"," Handshake keys, and an on-path attacker cannot force handshake"," failure other than by dropping packets to cause endpoints to abandon"," the attempt.",""," An on-path attacker can also replace the addresses of packets on"," either side and therefore cause the client or server to have an"," incorrect view of the remote addresses. Such an attack is"," indistinguishable from the functions performed by a NAT."]},{"id":"section-21.1.1.4","title":"Parameter Negotiation","lines":[" The entire handshake is cryptographically protected, with the Initial"," packets being encrypted with per-version keys and the Handshake and"," later packets being encrypted with keys derived from the TLS key"," exchange. Further, parameter negotiation is folded into the TLS"," transcript and thus provides the same integrity guarantees as"," ordinary TLS negotiation. An attacker can observe the client's"," transport parameters (as long as it knows the version-specific salt)"," but cannot observe the server's transport parameters and cannot"," influence parameter negotiation.",""," Connection IDs are unencrypted but integrity protected in all"," packets.",""," This version of QUIC does not incorporate a version negotiation"," mechanism; implementations of incompatible versions will simply fail"," to establish a connection."]},{"id":"section-21.1.2","title":"Protected Packets","lines":[" Packet protection (Section 12.1) applies authenticated encryption to"," all packets except Version Negotiation packets, though Initial and"," Retry packets have limited protection due to the use of version-"," specific keying material; see [QUIC-TLS] for more details. This"," section considers passive and active attacks against protected"," packets.",""," Both on-path and off-path attackers can mount a passive attack in"," which they save observed packets for an offline attack against packet"," protection at a future time; this is true for any observer of any"," packet on any network.",""," An attacker that injects packets without being able to observe valid"," packets for a connection is unlikely to be successful, since packet"," protection ensures that valid packets are only generated by endpoints"," that possess the key material established during the handshake; see"," Sections 7 and 21.1.1. Similarly, any active attacker that observes"," packets and attempts to insert new data or modify existing data in"," those packets should not be able to generate packets deemed valid by"," the receiving endpoint, other than Initial packets.",""," A spoofing attack, in which an active attacker rewrites unprotected"," parts of a packet that it forwards or injects, such as the source or"," destination address, is only effective if the attacker can forward"," packets to the original endpoint. Packet protection ensures that the"," packet payloads can only be processed by the endpoints that completed"," the handshake, and invalid packets are ignored by those endpoints.",""," An attacker can also modify the boundaries between packets and UDP"," datagrams, causing multiple packets to be coalesced into a single"," datagram or splitting coalesced packets into multiple datagrams."," Aside from datagrams containing Initial packets, which require"," padding, modification of how packets are arranged in datagrams has no"," functional effect on a connection, although it might change some"," performance characteristics."]},{"id":"section-21.1.3","title":"Connection Migration","lines":[" Connection migration (Section 9) provides endpoints with the ability"," to transition between IP addresses and ports on multiple paths, using"," one path at a time for transmission and receipt of non-probing"," frames. Path validation (Section 8.2) establishes that a peer is"," both willing and able to receive packets sent on a particular path."," This helps reduce the effects of address spoofing by limiting the"," number of packets sent to a spoofed address.",""," This section describes the intended security properties of connection"," migration under various types of DoS attacks."]},{"id":"section-21.1.3.1","title":"On-Path Active Attacks","lines":[" An attacker that can cause a packet it observes to no longer reach"," its intended destination is considered an on-path attacker. When an"," attacker is present between a client and server, endpoints are"," required to send packets through the attacker to establish"," connectivity on a given path.",""," An on-path attacker can:",""," * Inspect packets",""," * Modify IP and UDP packet headers",""," * Inject new packets",""," * Delay packets",""," * Reorder packets",""," * Drop packets",""," * Split and merge datagrams along packet boundaries",""," An on-path attacker cannot:",""," * Modify an authenticated portion of a packet and cause the"," recipient to accept that packet",""," An on-path attacker has the opportunity to modify the packets that it"," observes; however, any modifications to an authenticated portion of a"," packet will cause it to be dropped by the receiving endpoint as"," invalid, as packet payloads are both authenticated and encrypted.",""," QUIC aims to constrain the capabilities of an on-path attacker as"," follows:",""," 1. An on-path attacker can prevent the use of a path for a"," connection, causing the connection to fail if it cannot use a"," different path that does not contain the attacker. This can be"," achieved by dropping all packets, modifying them so that they"," fail to decrypt, or other methods.",""," 2. An on-path attacker can prevent migration to a new path for which"," the attacker is also on-path by causing path validation to fail"," on the new path.",""," 3. An on-path attacker cannot prevent a client from migrating to a"," path for which the attacker is not on-path.",""," 4. An on-path attacker can reduce the throughput of a connection by"," delaying packets or dropping them.",""," 5. An on-path attacker cannot cause an endpoint to accept a packet"," for which it has modified an authenticated portion of that"," packet."]},{"id":"section-21.1.3.2","title":"Off-Path Active Attacks","lines":[" An off-path attacker is not directly on the path between a client and"," server but could be able to obtain copies of some or all packets sent"," between the client and the server. It is also able to send copies of"," those packets to either endpoint.",""," An off-path attacker can:",""," * Inspect packets",""," * Inject new packets",""," * Reorder injected packets",""," An off-path attacker cannot:",""," * Modify packets sent by endpoints",""," * Delay packets",""," * Drop packets",""," * Reorder original packets",""," An off-path attacker can create modified copies of packets that it"," has observed and inject those copies into the network, potentially"," with spoofed source and destination addresses.",""," For the purposes of this discussion, it is assumed that an off-path"," attacker has the ability to inject a modified copy of a packet into"," the network that will reach the destination endpoint prior to the"," arrival of the original packet observed by the attacker. In other"," words, an attacker has the ability to consistently \"win\" a race with"," the legitimate packets between the endpoints, potentially causing the"," original packet to be ignored by the recipient.",""," It is also assumed that an attacker has the resources necessary to"," affect NAT state. In particular, an attacker can cause an endpoint"," to lose its NAT binding and then obtain the same port for use with"," its own traffic.",""," QUIC aims to constrain the capabilities of an off-path attacker as"," follows:",""," 1. An off-path attacker can race packets and attempt to become a"," \"limited\" on-path attacker.",""," 2. An off-path attacker can cause path validation to succeed for"," forwarded packets with the source address listed as the off-path"," attacker as long as it can provide improved connectivity between"," the client and the server.",""," 3. An off-path attacker cannot cause a connection to close once the"," handshake has completed.",""," 4. An off-path attacker cannot cause migration to a new path to fail"," if it cannot observe the new path.",""," 5. An off-path attacker can become a limited on-path attacker during"," migration to a new path for which it is also an off-path"," attacker.",""," 6. An off-path attacker can become a limited on-path attacker by"," affecting shared NAT state such that it sends packets to the"," server from the same IP address and port that the client"," originally used."]},{"id":"section-21.1.3.3","title":"Limited On-Path Active Attacks","lines":[" A limited on-path attacker is an off-path attacker that has offered"," improved routing of packets by duplicating and forwarding original"," packets between the server and the client, causing those packets to"," arrive before the original copies such that the original packets are"," dropped by the destination endpoint.",""," A limited on-path attacker differs from an on-path attacker in that"," it is not on the original path between endpoints, and therefore the"," original packets sent by an endpoint are still reaching their"," destination. This means that a future failure to route copied"," packets to the destination faster than their original path will not"," prevent the original packets from reaching the destination.",""," A limited on-path attacker can:",""," * Inspect packets",""," * Inject new packets",""," * Modify unencrypted packet headers",""," * Reorder packets",""," A limited on-path attacker cannot:",""," * Delay packets so that they arrive later than packets sent on the"," original path",""," * Drop packets",""," * Modify the authenticated and encrypted portion of a packet and"," cause the recipient to accept that packet",""," A limited on-path attacker can only delay packets up to the point"," that the original packets arrive before the duplicate packets,"," meaning that it cannot offer routing with worse latency than the"," original path. If a limited on-path attacker drops packets, the"," original copy will still arrive at the destination endpoint.",""," QUIC aims to constrain the capabilities of a limited off-path"," attacker as follows:",""," 1. A limited on-path attacker cannot cause a connection to close"," once the handshake has completed.",""," 2. A limited on-path attacker cannot cause an idle connection to"," close if the client is first to resume activity.",""," 3. A limited on-path attacker can cause an idle connection to be"," deemed lost if the server is the first to resume activity.",""," Note that these guarantees are the same guarantees provided for any"," NAT, for the same reasons."]},{"id":"section-21.2","title":"Handshake Denial of Service","lines":[" As an encrypted and authenticated transport, QUIC provides a range of"," protections against denial of service. Once the cryptographic"," handshake is complete, QUIC endpoints discard most packets that are"," not authenticated, greatly limiting the ability of an attacker to"," interfere with existing connections.",""," Once a connection is established, QUIC endpoints might accept some"," unauthenticated ICMP packets (see Section 14.2.1), but the use of"," these packets is extremely limited. The only other type of packet"," that an endpoint might accept is a stateless reset (Section 10.3),"," which relies on the token being kept secret until it is used.",""," During the creation of a connection, QUIC only provides protection"," against attacks from off the network path. All QUIC packets contain"," proof that the recipient saw a preceding packet from its peer.",""," Addresses cannot change during the handshake, so endpoints can"," discard packets that are received on a different network path.",""," The Source and Destination Connection ID fields are the primary means"," of protection against an off-path attack during the handshake; see"," Section 8.1. These are required to match those set by a peer."," Except for Initial and Stateless Resets, an endpoint only accepts"," packets that include a Destination Connection ID field that matches a"," value the endpoint previously chose. This is the only protection"," offered for Version Negotiation packets.",""," The Destination Connection ID field in an Initial packet is selected"," by a client to be unpredictable, which serves an additional purpose."," The packets that carry the cryptographic handshake are protected with"," a key that is derived from this connection ID and a salt specific to"," the QUIC version. This allows endpoints to use the same process for"," authenticating packets that they receive as they use after the"," cryptographic handshake completes. Packets that cannot be"," authenticated are discarded. Protecting packets in this fashion"," provides a strong assurance that the sender of the packet saw the"," Initial packet and understood it.",""," These protections are not intended to be effective against an"," attacker that is able to receive QUIC packets prior to the connection"," being established. Such an attacker can potentially send packets"," that will be accepted by QUIC endpoints. This version of QUIC"," attempts to detect this sort of attack, but it expects that endpoints"," will fail to establish a connection rather than recovering. For the"," most part, the cryptographic handshake protocol [QUIC-TLS] is"," responsible for detecting tampering during the handshake.",""," Endpoints are permitted to use other methods to detect and attempt to"," recover from interference with the handshake. Invalid packets can be"," identified and discarded using other methods, but no specific method"," is mandated in this document."]},{"id":"section-21.3","title":"Amplification Attack","lines":[" An attacker might be able to receive an address validation token"," (Section 8) from a server and then release the IP address it used to"," acquire that token. At a later time, the attacker can initiate a"," 0-RTT connection with a server by spoofing this same address, which"," might now address a different (victim) endpoint. The attacker can"," thus potentially cause the server to send an initial congestion"," window's worth of data towards the victim.","",[[[],0," "],[[316,2230,2235,2240,2248,2913,2916,2918],180,"Servers SHOULD provide mitigations for this attack by limiting the"]],[[[],0," "],[[316,2230,2235,2240,2248,2913,2916,2918],180,"usage and lifetime of address validation tokens; see Section 8.1.3."]]],"requirements":[316]},{"id":"section-21.4","title":"Optimistic ACK Attack","lines":[" An endpoint that acknowledges packets it has not received might cause"," a congestion controller to permit sending at rates beyond what the",[[[],0," network supports. "],[[317,1780],112,"An endpoint MAY skip packet numbers when sending"]],[[[],0," "],[[317,1780],112,"packets to detect this behavior."],[[],0," An endpoint can then immediately"]]," close the connection with a connection error of type"," PROTOCOL_VIOLATION; see Section 10.2."],"requirements":[317]},{"id":"section-21.5","title":"Request Forgery Attacks","lines":[" A request forgery attack occurs where an endpoint causes its peer to"," issue a request towards a victim, with the request controlled by the"," endpoint. Request forgery attacks aim to provide an attacker with"," access to capabilities of its peer that might otherwise be"," unavailable to the attacker. For a networking protocol, a request"," forgery attack is often used to exploit any implicit authorization"," conferred on the peer by the victim due to the peer's location in the"," network.",""," For request forgery to be effective, an attacker needs to be able to"," influence what packets the peer sends and where these packets are"," sent. If an attacker can target a vulnerable service with a"," controlled payload, that service might perform actions that are"," attributed to the attacker's peer but are decided by the attacker.",""," For example, cross-site request forgery [CSRF] exploits on the Web"," cause a client to issue requests that include authorization cookies"," [COOKIE], allowing one site access to information and actions that"," are intended to be restricted to a different site.",""," As QUIC runs over UDP, the primary attack modality of concern is one"," where an attacker can select the address to which its peer sends UDP"," datagrams and can control some of the unprotected content of those"," packets. As much of the data sent by QUIC endpoints is protected,"," this includes control over ciphertext. An attack is successful if an"," attacker can cause a peer to send a UDP datagram to a host that will"," perform some action based on content in the datagram.",""," This section discusses ways in which QUIC might be used for request"," forgery attacks.",""," This section also describes limited countermeasures that can be"," implemented by QUIC endpoints. These mitigations can be employed"," unilaterally by a QUIC implementation or deployment, without"," potential targets for request forgery attacks taking action."," However, these countermeasures could be insufficient if UDP-based"," services do not properly authorize requests.",""," Because the migration attack described in Section 21.5.4 is quite"," powerful and does not have adequate countermeasures, QUIC server"," implementations should assume that attackers can cause them to",[[[],0," generate arbitrary UDP payloads to arbitrary destinations. "],[[33,325],162,"QUIC"]],[[[],0," "],[[33,325],162,"servers SHOULD NOT be deployed in networks that do not deploy ingress"]],[[[],0," "],[[33,325],162,"filtering [BCP38] and also have inadequately secured UDP endpoints."]],""," Although it is not generally possible to ensure that clients are not"," co-located with vulnerable endpoints, this version of QUIC does not"," allow servers to migrate, thus preventing spoofed migration attacks",[[[],0," on clients. "],[[36,326],226,"Any future extension that allows server migration MUST"]],[[[],0," "],[[36,326],226,"also define countermeasures for forgery attacks."]]],"requirements":[325,326]},{"id":"section-21.5.1","title":"Control Options for Endpoints","lines":[" QUIC offers some opportunities for an attacker to influence or"," control where its peer sends UDP datagrams:",""," * initial connection establishment (Section 7), where a server is"," able to choose where a client sends datagrams -- for example, by"," populating DNS records;",""," * preferred addresses (Section 9.6), where a server is able to"," choose where a client sends datagrams;",""," * spoofed connection migrations (Section 9.3.1), where a client is"," able to use source address spoofing to select where a server sends"," subsequent datagrams; and",""," * spoofed packets that cause a server to send a Version Negotiation"," packet (Section 21.5.5).",""," In all cases, the attacker can cause its peer to send datagrams to a"," victim that might not understand QUIC. That is, these packets are"," sent by the peer prior to address validation; see Section 8.",""," Outside of the encrypted portion of packets, QUIC offers an endpoint"," several options for controlling the content of UDP datagrams that its"," peer sends. The Destination Connection ID field offers direct"," control over bytes that appear early in packets sent by the peer; see"," Section 5.1. The Token field in Initial packets offers a server"," control over other bytes of Initial packets; see Section 17.2.2.",""," There are no measures in this version of QUIC to prevent indirect"," control over the encrypted portions of packets. It is necessary to"," assume that endpoints are able to control the contents of frames that"," a peer sends, especially those frames that convey application data,"," such as STREAM frames. Though this depends to some degree on details"," of the application protocol, some control is possible in many"," protocol usage contexts. As the attacker has access to packet"," protection keys, they are likely to be capable of predicting how a"," peer will encrypt future packets. Successful control over datagram"," content then only requires that the attacker be able to predict the"," packet number and placement of frames in packets with some amount of"," reliability.",""," This section assumes that limiting control over datagram content is"," not feasible. The focus of the mitigations in subsequent sections is"," on limiting the ways in which datagrams that are sent prior to"," address validation can be used for request forgery."]},{"id":"section-21.5.2","title":"Request Forgery with Client Initial Packets","lines":[" An attacker acting as a server can choose the IP address and port on"," which it advertises its availability, so Initial packets from clients"," are assumed to be available for use in this sort of attack. The"," address validation implicit in the handshake ensures that -- for a"," new connection -- a client will not send other types of packets to a"," destination that does not understand QUIC or is not willing to accept"," a QUIC connection.",""," Initial packet protection (Section 5.2 of [QUIC-TLS]) makes it"," difficult for servers to control the content of Initial packets sent"," by clients. A client choosing an unpredictable Destination"," Connection ID ensures that servers are unable to control any of the"," encrypted portion of Initial packets from clients.",""," However, the Token field is open to server control and does allow a"," server to use clients to mount request forgery attacks. The use of"," tokens provided with the NEW_TOKEN frame (Section 8.1.3) offers the"," only option for request forgery during connection establishment.",""," Clients, however, are not obligated to use the NEW_TOKEN frame."," Request forgery attacks that rely on the Token field can be avoided"," if clients send an empty Token field when the server address has"," changed from when the NEW_TOKEN frame was received.",""," Clients could avoid using NEW_TOKEN if the server address changes."," However, not including a Token field could adversely affect"," performance. Servers could rely on NEW_TOKEN to enable the sending"," of data in excess of the three-times limit on sending data; see"," Section 8.1. In particular, this affects cases where clients use"," 0-RTT to request data from servers.",""," Sending a Retry packet (Section 17.2.5) offers a server the option to"," change the Token field. After sending a Retry, the server can also"," control the Destination Connection ID field of subsequent Initial"," packets from the client. This also might allow indirect control over"," the encrypted content of Initial packets. However, the exchange of a"," Retry packet validates the server's address, thereby preventing the"," use of subsequent Initial packets for request forgery."]},{"id":"section-21.5.3","title":"Request Forgery with Preferred Addresses","lines":[" Servers can specify a preferred address, which clients then migrate"," to after confirming the handshake; see Section 9.6. The Destination"," Connection ID field of packets that the client sends to a preferred"," address can be used for request forgery.","",[[[],0," "],[[318,2148,2744],244,"A client MUST NOT send non-probing frames to a preferred address"]],[[[],0," "],[[318,2148,2744],244,"prior to validating that address; see Section 8."],[[],0," This greatly"]]," reduces the options that a server has to control the encrypted"," portion of datagrams.",""," This document does not offer any additional countermeasures that are"," specific to the use of preferred addresses and can be implemented by"," endpoints. The generic measures described in Section 21.5.6 could be"," used as further mitigation."],"requirements":[318]},{"id":"section-21.5.4","title":"Request Forgery with Spoofed Migration","lines":[" Clients are able to present a spoofed source address as part of an"," apparent connection migration to cause a server to send datagrams to"," that address.",""," The Destination Connection ID field in any packets that a server"," subsequently sends to this spoofed address can be used for request"," forgery. A client might also be able to influence the ciphertext.",""," A server that only sends probing packets (Section 9.1) to an address"," prior to address validation provides an attacker with only limited"," control over the encrypted portion of datagrams. However,"," particularly for NAT rebinding, this can adversely affect"," performance. If the server sends frames carrying application data,"," an attacker might be able to control most of the content of"," datagrams.",""," This document does not offer specific countermeasures that can be"," implemented by endpoints, aside from the generic measures described"," in Section 21.5.6. However, countermeasures for address spoofing at"," the network level -- in particular, ingress filtering [BCP38] -- are"," especially effective against attacks that use spoofing and originate"," from an external network."]},{"id":"section-21.5.5","title":"Request Forgery with Version Negotiation","lines":[" Clients that are able to present a spoofed source address on a packet"," can cause a server to send a Version Negotiation packet"," (Section 17.2.1) to that address.",""," The absence of size restrictions on the connection ID fields for"," packets of an unknown version increases the amount of data that the"," client controls from the resulting datagram. The first byte of this"," packet is not under client control and the next four bytes are zero,"," but the client is able to control up to 512 bytes starting from the"," fifth byte.",""," No specific countermeasures are provided for this attack, though"," generic protections (Section 21.5.6) could apply. In this case,"," ingress filtering [BCP38] is also effective."]},{"id":"section-21.5.6","title":"Generic Request Forgery Countermeasures","lines":[" The most effective defense against request forgery attacks is to"," modify vulnerable services to use strong authentication. However,"," this is not always something that is within the control of a QUIC"," deployment. This section outlines some other steps that QUIC"," endpoints could take unilaterally. These additional steps are all"," discretionary because, depending on circumstances, they could"," interfere with or prevent legitimate uses.",""," Services offered over loopback interfaces often lack proper",[[[],0," authentication. "],[[319,2286],112,"Endpoints MAY prevent connection attempts or"]],[[[],0," "],[[319,2286],112,"migration to a loopback address."],[[],0," "],[[320,2217,2929],180,"Endpoints SHOULD NOT allow"]],[[[],0," "],[[320,2217,2929],180,"connections or migration to a loopback address if the same service"]],[[[],0," "],[[320,2217,2929],180,"was previously available at a different interface or if the address"]],[[[],0," "],[[320,2217,2929],180,"was provided by a service at a non-loopback address."],[[],0," Endpoints that"]]," depend on these capabilities could offer an option to disable these"," protections.",""," Similarly, endpoints could regard a change in address to a link-local"," address [RFC4291] or an address in a private-use range [RFC1918] from"," a global, unique-local [RFC4193], or non-private address as a"," potential attempt at request forgery. Endpoints could refuse to use"," these addresses entirely, but that carries a significant risk of",[[[],0," interfering with legitimate uses. "],[[321,2218,2928],180,"Endpoints SHOULD NOT refuse to use"]],[[[],0," "],[[321,2218,2928],180,"an address unless they have specific knowledge about the network"]],[[[],0," "],[[321,2218,2928],180,"indicating that sending datagrams to unvalidated addresses in a given"]],[[[],0," "],[[321,2218,2928],180,"range is not safe."]],"",[[[],0," "],[[322],96,"Endpoints MAY choose to reduce the risk of request forgery by not"]],[[[],0," "],[[322],96,"including values from NEW_TOKEN frames in Initial packets or by only"]],[[[],0," "],[[322],96,"sending probing frames in packets prior to completing address"]],[[[],0," "],[[322],96,"validation."],[[],0," Note that this does not prevent an attacker from using"]]," the Destination Connection ID field for an attack.",""," Endpoints are not expected to have specific information about the"," location of servers that could be vulnerable targets of a request"," forgery attack. However, it might be possible over time to identify"," specific UDP ports that are common targets of attacks or particular",[[[],0," patterns in datagrams that are used for attacks. "],[[323,2287],112,"Endpoints MAY"]],[[[],0," "],[[323,2287],112,"choose to avoid sending datagrams to these ports or not send"]],[[[],0," "],[[323,2287],112,"datagrams that match these patterns prior to validating the"]],[[[],0," "],[[323,2287],112,"destination address."],[[],0," "],[[324],96,"Endpoints MAY retire connection IDs containing"]],[[[],0," "],[[324],96,"patterns known to be problematic without using them."]],""," | Note: Modifying endpoints to apply these protections is more"," | efficient than deploying network-based protections, as"," | endpoints do not need to perform any additional processing when"," | sending to an address that has been validated."],"requirements":[319,320,321,322,323,324]},{"id":"section-21.6","title":"Slowloris Attacks","lines":[" The attacks commonly known as Slowloris [SLOWLORIS] try to keep many"," connections to the target endpoint open and hold them open as long as"," possible. These attacks can be executed against a QUIC endpoint by"," generating the minimum amount of activity necessary to avoid being"," closed for inactivity. This might involve sending small amounts of"," data, gradually opening flow control windows in order to control the"," sender rate, or manufacturing ACK frames that simulate a high loss"," rate.","",[[[],0," "],[[37,327],162,"QUIC deployments SHOULD provide mitigations for the Slowloris"]],[[[],0," "],[[37,327],162,"attacks, such as increasing the maximum number of clients the server"]],[[[],0," "],[[37,327],162,"will allow, limiting the number of connections a single IP address is"]],[[[],0," "],[[37,327],162,"allowed to make, imposing restrictions on the minimum transfer speed"]],[[[],0," "],[[37,327],162,"a connection is allowed to have, and restricting the length of time"]],[[[],0," "],[[37,327],162,"an endpoint is allowed to stay connected."]]],"requirements":[327]},{"id":"section-21.7","title":"Stream Fragmentation and Reassembly Attacks","lines":[" An adversarial sender might intentionally not send portions of the"," stream data, causing the receiver to commit resources for the unsent"," data. This could cause a disproportionate receive buffer memory"," commitment and/or the creation of a large and inefficient data"," structure at the receiver.",""," An adversarial receiver might intentionally not acknowledge packets"," containing stream data in an attempt to force the sender to store the"," unacknowledged stream data for retransmission.",""," The attack on receivers is mitigated if flow control windows"," correspond to available memory. However, some receivers will"," overcommit memory and advertise flow control offsets in the aggregate"," that exceed actual available memory. The overcommitment strategy can"," lead to better performance when endpoints are well behaved, but"," renders endpoints vulnerable to the stream fragmentation attack.","",[[[],0," "],[[38,328],162,"QUIC deployments SHOULD provide mitigations for stream fragmentation"]],[[[],0," "],[[38,328],162,"attacks."],[[],0," Mitigations could consist of avoiding overcommitting"]]," memory, limiting the size of tracking data structures, delaying"," reassembly of STREAM frames, implementing heuristics based on the age"," and duration of reassembly holes, or some combination of these."],"requirements":[328]},{"id":"section-21.8","title":"Stream Commitment Attack","lines":[" An adversarial endpoint can open a large number of streams,"," exhausting state on an endpoint. The adversarial endpoint could"," repeat the process on a large number of connections, in a manner"," similar to SYN flooding attacks in TCP.",""," Normally, clients will open streams sequentially, as explained in"," Section 2.1. However, when several streams are initiated at short"," intervals, loss or reordering can cause STREAM frames that open"," streams to be received out of sequence. On receiving a higher-"," numbered stream ID, a receiver is required to open all intervening"," streams of the same type; see Section 3.2. Thus, on a new"," connection, opening stream 4000000 opens 1 million and 1 client-"," initiated bidirectional streams.",""," The number of active streams is limited by the"," initial_max_streams_bidi and initial_max_streams_uni transport"," parameters as updated by any received MAX_STREAMS frames, as"," explained in Section 4.6. If chosen judiciously, these limits"," mitigate the effect of the stream commitment attack. However,"," setting the limit too low could affect performance when applications"," expect to open a large number of streams."]},{"id":"section-21.9","title":"Peer Denial of Service","lines":[" QUIC and TLS both contain frames or messages that have legitimate"," uses in some contexts, but these frames or messages can be abused to"," cause a peer to expend processing resources without having any"," observable impact on the state of the connection.",""," Messages can also be used to change and revert state in small or"," inconsequential ways, such as by sending small increments to flow"," control limits.",""," If processing costs are disproportionately large in comparison to"," bandwidth consumption or effect on state, then this could allow a"," malicious peer to exhaust processing capacity.","",[[[],0," "],[[329,2014,2585],180,"While there are legitimate uses for all messages, implementations"]],[[[],0," "],[[329,2014,2585],180,"SHOULD track cost of processing relative to progress and treat"]],[[[],0," "],[[329,2014,2585],180,"excessive quantities of any non-productive packets as indicative of"]],[[[],0," "],[[329,2014,2585],180,"an attack."],[[2585],4," "],[[330,2015,2585],116,"Endpoints MAY respond to this condition with a connection"]],[[[],0," "],[[330,2015,2585],116,"error or by dropping packets."]]],"requirements":[329,330]},{"id":"section-21.10","title":"Explicit Congestion Notification Attacks","lines":[" An on-path attacker could manipulate the value of ECN fields in the"," IP header to influence the sender's rate. [RFC3168] discusses"," manipulations and their effects in more detail.",""," A limited on-path attacker can duplicate and send packets with"," modified ECN fields to affect the sender's rate. If duplicate"," packets are discarded by a receiver, an attacker will need to race"," the duplicate packet against the original to be successful in this"," attack. Therefore, QUIC endpoints ignore the ECN field in an IP"," packet unless at least one QUIC packet in that IP packet is"," successfully processed; see Section 13.4."]},{"id":"section-21.11","title":"Stateless Reset Oracle","lines":[" Stateless resets create a possible denial-of-service attack analogous"," to a TCP reset injection. This attack is possible if an attacker is"," able to cause a stateless reset token to be generated for a"," connection with a selected connection ID. An attacker that can cause"," this token to be generated can reset an active connection with the"," same connection ID.",""," If a packet can be routed to different instances that share a static"," key -- for example, by changing an IP address or port -- then an",[[[],0," attacker can cause the server to send a stateless reset. "],[[34,313],226,"To defend"]],[[[],0," "],[[34,313],226,"against this style of denial of service, endpoints that share a"]],[[[],0," "],[[34,313],226,"static key for stateless resets (see Section 10.3.2) MUST be arranged"]],[[[],0," "],[[34,313],226,"so that packets with a given connection ID always arrive at an"]],[[[],0," "],[[34,313],226,"instance that has connection state, unless that connection is no"]],[[[],0," "],[[34,313],226,"longer active."]],"",[[[],0," "],[[35,314],226,"More generally, servers MUST NOT generate a stateless reset if a"]],[[[],0," "],[[35,314],226,"connection with the corresponding connection ID could be active on"]],[[[],0," "],[[35,314],226,"any endpoint using the same static key."]],""," In the case of a cluster that uses dynamic load balancing, it is"," possible that a change in load-balancer configuration could occur"," while an active instance retains connection state. Even if an"," instance retains connection state, the change in routing and"," resulting stateless reset will result in the connection being"," terminated. If there is no chance of the packet being routed to the"," correct instance, it is better to send a stateless reset than wait"," for the connection to time out. However, this is acceptable only if"," the routing cannot be influenced by an attacker."],"requirements":[313,314]},{"id":"section-21.12","title":"Version Downgrade","lines":[" This document defines QUIC Version Negotiation packets (Section 6),"," which can be used to negotiate the QUIC version used between two"," endpoints. However, this document does not specify how this"," negotiation will be performed between this version and subsequent"," future versions. In particular, Version Negotiation packets do not",[[[],0," contain any mechanism to prevent version downgrade attacks. "],[[32,315],226,"Future"]],[[[],0," "],[[32,315],226,"versions of QUIC that use Version Negotiation packets MUST define a"]],[[[],0," "],[[32,315],226,"mechanism that is robust against version downgrade attacks."]]],"requirements":[315]},{"id":"section-21.13","title":"Targeted Attacks by Routing","lines":[" Deployments should limit the ability of an attacker to target a new"," connection to a particular server instance. Ideally, routing"," decisions are made independently of client-selected values, including"," addresses. Once an instance is selected, a connection ID can be"," selected so that later packets are routed to the same instance."]},{"id":"section-21.14","title":"Traffic Analysis","lines":[" The length of QUIC packets can reveal information about the length of"," the content of those packets. The PADDING frame is provided so that"," endpoints have some ability to obscure the length of packet content;"," see Section 19.1.",""," Defeating traffic analysis is challenging and the subject of active"," research. Length is not the only way that information might leak."," Endpoints might also reveal sensitive information through other side"," channels, such as the timing of packets."]},{"id":"section-22","title":"IANA Considerations","lines":[" This document establishes several registries for the management of"," codepoints in QUIC. These registries operate on a common set of"," policies as defined in Section 22.1."]},{"id":"section-22.1","title":"Registration Policies for QUIC Registries","lines":[" All QUIC registries allow for both provisional and permanent"," registration of codepoints. This section documents policies that are"," common to these registries."]},{"id":"section-22.1.1","title":"Provisional Registrations","lines":[" Provisional registrations of codepoints are intended to allow for"," private use and experimentation with extensions to QUIC. Provisional"," registrations only require the inclusion of the codepoint value and"," contact information. However, provisional registrations could be"," reclaimed and reassigned for another purpose.",""," Provisional registrations require Expert Review, as defined in"," Section 4.5 of [RFC8126]. The designated expert or experts are"," advised that only registrations for an excessive proportion of"," remaining codepoint space or the very first unassigned value (see"," Section 22.1.2) can be rejected.",""," Provisional registrations will include a Date field that indicates"," when the registration was last updated. A request to update the date"," on any provisional registration can be made without review from the"," designated expert(s).",""," All QUIC registries include the following fields to support"," provisional registration:",""," Value: The assigned codepoint."," Status: \"permanent\" or \"provisional\"."," Specification: A reference to a publicly available specification for"," the value."," Date: The date of the last update to the registration."," Change Controller: The entity that is responsible for the definition"," of the registration."," Contact: Contact details for the registrant."," Notes: Supplementary notes about the registration.","",[[[],0," "],[[0,331],98,"Provisional registrations MAY omit the Specification and Notes"]],[[[],0," "],[[0,331],98,"fields, plus any additional fields that might be required for a"]],[[[],0," "],[[0,331],98,"permanent registration."],[[],0," The Date field is not required as part of"]]," requesting a registration, as it is set to the date the registration"," is created or updated."],"requirements":[331]},{"id":"section-22.1.2","title":"Selecting Codepoints","lines":[[[[],0," "],[[1,332],162,"New requests for codepoints from QUIC registries SHOULD use a"]],[[[],0," "],[[1,332],162,"randomly selected codepoint that excludes both existing allocations"]],[[[],0," "],[[1,332],162,"and the first unallocated codepoint in the selected space."],[[],0," "],[[4,333],98,"Requests"]],[[[],0," "],[[4,333],98,"for multiple codepoints MAY use a contiguous range."],[[],0," This minimizes"]]," the risk that differing semantics are attributed to the same"," codepoint by different implementations.",""," The use of the first unassigned codepoint is reserved for allocation"," using the Standards Action policy; see Section 4.9 of [RFC8126]. The"," early codepoint assignment process [EARLY-ASSIGN] can be used for"," these values.","",[[[],0," "],[[2,334],162,"For codepoints that are encoded in variable-length integers"]],[[[],0," "],[[2,334],162,"(Section 16), such as frame types, codepoints that encode to four or"]],[[[],0," "],[[2,334],162,"eight bytes (that is, values 2^14 and above) SHOULD be used unless"]],[[[],0," "],[[2,334],162,"the usage is especially sensitive to having a longer encoding."]],"",[[[],0," "],[[5,335],98,"Applications to register codepoints in QUIC registries MAY include a"]],[[[],0," "],[[5,335],98,"requested codepoint as part of the registration."],[[],0," "],[[3,336],226,"IANA MUST allocate"]],[[[],0," "],[[3,336],226,"the selected codepoint if the codepoint is unassigned and the"]],[[[],0," "],[[3,336],226,"requirements of the registration policy are met."]]],"requirements":[332,333,334,335,336]},{"id":"section-22.1.3","title":"Reclaiming Provisional Codepoints","lines":[" A request might be made to remove an unused provisional registration"," from the registry to reclaim space in a registry, or a portion of the"," registry (such as the 64-16383 range for codepoints that use",[[[],0," variable-length encodings). "],[[6,337],162,"This SHOULD be done only for the"]],[[[],0," "],[[6,337],162,"codepoints with the earliest recorded date, and entries that have"]],[[[],0," "],[[6,337],162,"been updated less than a year prior SHOULD NOT be reclaimed."]],"",[[[],0," "],[[7,338],226,"A request to remove a codepoint MUST be reviewed by the designated"]],[[[],0," "],[[7,338],226,"experts."],[[],0," "],[[8,339],226,"The experts MUST attempt to determine whether the codepoint"]],[[[],0," "],[[8,339],226,"is still in use."],[[],0," Experts are advised to contact the listed contacts"]]," for the registration, plus as wide a set of protocol implementers as"," possible in order to determine whether any use of the codepoint is"," known. The experts are also advised to allow at least four weeks for"," responses.","",[[[],0," "],[[9,340],226,"If any use of the codepoints is identified by this search or a"]],[[[],0," "],[[9,340],226,"request to update the registration is made, the codepoint MUST NOT be"]],[[[],0," "],[[9,340],226,"reclaimed."],[[],0," Instead, the date on the registration is updated. A note"]]," might be added for the registration recording relevant information"," that was learned.","",[[[],0," "],[[10,341],98,"If no use of the codepoint was identified and no request was made to"]],[[[],0," "],[[10,341],98,"update the registration, the codepoint MAY be removed from the"]],[[[],0," "],[[10,341],98,"registry."]],""," This review and consultation process also applies to requests to"," change a provisional registration into a permanent registration,"," except that the goal is not to determine whether there is no use of"," the codepoint but to determine that the registration is an accurate"," representation of any deployed usage."],"requirements":[337,338,339,340,341]},{"id":"section-22.1.4","title":"Permanent Registrations","lines":[" Permanent registrations in QUIC registries use the Specification"," Required policy (Section 4.6 of [RFC8126]), unless otherwise"," specified. The designated expert or experts verify that a"," specification exists and is readily accessible. Experts are"," encouraged to be biased towards approving registrations unless they"," are abusive, frivolous, or actively harmful (not merely aesthetically",[[[],0," displeasing or architecturally dubious). "],[[13,342],98,"The creation of a registry"]],[[[],0," "],[[13,342],98,"MAY specify additional constraints on permanent registrations."]],"",[[[],0," "],[[12,343],98,"The creation of a registry MAY identify a range of codepoints where"]],[[[],0," "],[[12,343],98,"registrations are governed by a different registration policy."],[[],0," For"]]," instance, the \"QUIC Frame Types\" registry (Section 22.4) has a"," stricter policy for codepoints in the range from 0 to 63.",""," Any stricter requirements for permanent registrations do not prevent"," provisional registrations for affected codepoints. For instance, a"," provisional registration for a frame type of 61 could be requested.","",[[[],0," "],[[11,344],226,"All registrations made by Standards Track publications MUST be"]],[[[],0," "],[[11,344],226,"permanent."]],""," All registrations in this document are assigned a permanent status"," and list a change controller of the IETF and a contact of the QUIC"," Working Group (quic@ietf.org)."],"requirements":[342,343,344]},{"id":"section-22.2","title":"QUIC Versions Registry","lines":[" IANA has added a registry for \"QUIC Versions\" under a \"QUIC\" heading.",""," The \"QUIC Versions\" registry governs a 32-bit space; see Section 15."," This registry follows the registration policy from Section 22.1."," Permanent registrations in this registry are assigned using the"," Specification Required policy (Section 4.6 of [RFC8126]).",""," The codepoint of 0x00000001 for the protocol is assigned with"," permanent status to the protocol defined in this document. The"," codepoint of 0x00000000 is permanently reserved; the note for this"," codepoint indicates that this version is reserved for version"," negotiation.","",[[[],0," "],[[14,345],226,"All codepoints that follow the pattern 0x?a?a?a?a are reserved, MUST"]],[[[],0," "],[[14,345],226,"NOT be assigned by IANA, and MUST NOT appear in the listing of"]],[[[],0," "],[[14,345],226,"assigned values."]]],"requirements":[345]},{"id":"section-22.3","title":"QUIC Transport Parameters Registry","lines":[" IANA has added a registry for \"QUIC Transport Parameters\" under a"," \"QUIC\" heading.",""," The \"QUIC Transport Parameters\" registry governs a 62-bit space."," This registry follows the registration policy from Section 22.1."," Permanent registrations in this registry are assigned using the"," Specification Required policy (Section 4.6 of [RFC8126]), except for"," values between 0x00 and 0x3f (in hexadecimal), inclusive, which are"," assigned using Standards Action or IESG Approval as defined in"," Sections 4.9 and 4.10 of [RFC8126].","",[[[],0," "],[[15,346],226,"In addition to the fields listed in Section 22.1.1, permanent"]],[[[],0," "],[[15,346],226,"registrations in this registry MUST include the following field:"]],""," Parameter Name: A short mnemonic for the parameter.",""," The initial contents of this registry are shown in Table 6.",""," +=======+=====================================+===============+"," | Value | Parameter Name | Specification |"," +=======+=====================================+===============+"," | 0x00 | original_destination_connection_id | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x01 | max_idle_timeout | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x02 | stateless_reset_token | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x03 | max_udp_payload_size | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x04 | initial_max_data | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x05 | initial_max_stream_data_bidi_local | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x07 | initial_max_stream_data_uni | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x08 | initial_max_streams_bidi | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x09 | initial_max_streams_uni | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x0a | ack_delay_exponent | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x0b | max_ack_delay | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x0c | disable_active_migration | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x0d | preferred_address | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x0e | active_connection_id_limit | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x0f | initial_source_connection_id | Section 18.2 |"," +-------+-------------------------------------+---------------+"," | 0x10 | retry_source_connection_id | Section 18.2 |"," +-------+-------------------------------------+---------------+",""," Table 6: Initial QUIC Transport Parameters Registry Entries","",[[[],0," "],[[16,347],226,"Each value of the form \"31 * N + 27\" for integer values of N (that"]],[[[],0," "],[[16,347],226,"is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned"]],[[[],0," "],[[16,347],226,"by IANA and MUST NOT appear in the listing of assigned values."]]],"requirements":[346,347]},{"id":"section-22.4","title":"QUIC Frame Types Registry","lines":[" IANA has added a registry for \"QUIC Frame Types\" under a \"QUIC\""," heading.",""," The \"QUIC Frame Types\" registry governs a 62-bit space. This"," registry follows the registration policy from Section 22.1."," Permanent registrations in this registry are assigned using the"," Specification Required policy (Section 4.6 of [RFC8126]), except for"," values between 0x00 and 0x3f (in hexadecimal), inclusive, which are"," assigned using Standards Action or IESG Approval as defined in"," Sections 4.9 and 4.10 of [RFC8126].","",[[[],0," "],[[17,348],226,"In addition to the fields listed in Section 22.1.1, permanent"]],[[[],0," "],[[17,348],226,"registrations in this registry MUST include the following field:"]],""," Frame Type Name: A short mnemonic for the frame type.","",[[[],0," "],[[18,349],162,"In addition to the advice in Section 22.1, specifications for new"]],[[[],0," "],[[18,349],162,"permanent registrations SHOULD describe the means by which an"]],[[[],0," "],[[18,349],162,"endpoint might determine that it can send the identified type of"]],[[[],0," "],[[18,349],162,"frame."],[[],0," An accompanying transport parameter registration is expected"]]," for most registrations; see Section 22.3. Specifications for"," permanent registrations also need to describe the format and assigned"," semantics of any fields in the frame.",""," The initial contents of this registry are tabulated in Table 3. Note"," that the registry does not include the \"Pkts\" and \"Spec\" columns from"," Table 3."],"requirements":[348,349]},{"id":"section-22.5","title":"QUIC Transport Error Codes Registry","lines":[" IANA has added a registry for \"QUIC Transport Error Codes\" under a"," \"QUIC\" heading.",""," The \"QUIC Transport Error Codes\" registry governs a 62-bit space."," This space is split into three ranges that are governed by different"," policies. Permanent registrations in this registry are assigned"," using the Specification Required policy (Section 4.6 of [RFC8126]),"," except for values between 0x00 and 0x3f (in hexadecimal), inclusive,"," which are assigned using Standards Action or IESG Approval as defined"," in Sections 4.9 and 4.10 of [RFC8126].","",[[[],0," "],[[19,350],226,"In addition to the fields listed in Section 22.1.1, permanent"]],[[[],0," "],[[19,350],226,"registrations in this registry MUST include the following fields:"]],""," Code: A short mnemonic for the parameter.","",[[[],0," "],[[20,351],98,"Description: A brief description of the error code semantics, which"]],[[[],0," "],[[20,351],98,"MAY be a summary if a specification reference is provided."]],""," The initial contents of this registry are shown in Table 7.",""," +=======+===========================+================+==============+"," |Value | Code |Description |Specification |"," +=======+===========================+================+==============+"," |0x00 | NO_ERROR |No error |Section 20 |"," +-------+---------------------------+----------------+--------------+"," |0x01 | INTERNAL_ERROR |Implementation |Section 20 |"," | | |error | |"," +-------+---------------------------+----------------+--------------+"," |0x02 | CONNECTION_REFUSED |Server refuses a|Section 20 |"," | | |connection | |"," +-------+---------------------------+----------------+--------------+"," |0x03 | FLOW_CONTROL_ERROR |Flow control |Section 20 |"," | | |error | |"," +-------+---------------------------+----------------+--------------+"," |0x04 | STREAM_LIMIT_ERROR |Too many streams|Section 20 |"," | | |opened | |"," +-------+---------------------------+----------------+--------------+"," |0x05 | STREAM_STATE_ERROR |Frame received |Section 20 |"," | | |in invalid | |"," | | |stream state | |"," +-------+---------------------------+----------------+--------------+"," |0x06 | FINAL_SIZE_ERROR |Change to final |Section 20 |"," | | |size | |"," +-------+---------------------------+----------------+--------------+"," |0x07 | FRAME_ENCODING_ERROR |Frame encoding |Section 20 |"," | | |error | |"," +-------+---------------------------+----------------+--------------+"," |0x08 | TRANSPORT_PARAMETER_ERROR |Error in |Section 20 |"," | | |transport | |"," | | |parameters | |"," +-------+---------------------------+----------------+--------------+"," |0x09 | CONNECTION_ID_LIMIT_ERROR |Too many |Section 20 |"," | | |connection IDs | |"," | | |received | |"," +-------+---------------------------+----------------+--------------+"," |0x0a | PROTOCOL_VIOLATION |Generic protocol|Section 20 |"," | | |violation | |"," +-------+---------------------------+----------------+--------------+"," |0x0b | INVALID_TOKEN |Invalid Token |Section 20 |"," | | |received | |"," +-------+---------------------------+----------------+--------------+"," |0x0c | APPLICATION_ERROR |Application |Section 20 |"," | | |error | |"," +-------+---------------------------+----------------+--------------+"," |0x0d | CRYPTO_BUFFER_EXCEEDED |CRYPTO data |Section 20 |"," | | |buffer | |"," | | |overflowed | |"," +-------+---------------------------+----------------+--------------+"," |0x0e | KEY_UPDATE_ERROR |Invalid packet |Section 20 |"," | | |protection | |"," | | |update | |"," +-------+---------------------------+----------------+--------------+"," |0x0f | AEAD_LIMIT_REACHED |Excessive use of|Section 20 |"," | | |packet | |"," | | |protection keys | |"," +-------+---------------------------+----------------+--------------+"," |0x10 | NO_VIABLE_PATH |No viable |Section 20 |"," | | |network path | |"," | | |exists | |"," +-------+---------------------------+----------------+--------------+"," |0x0100-| CRYPTO_ERROR |TLS alert code |Section 20 |"," |0x01ff | | | |"," +-------+---------------------------+----------------+--------------+",""," Table 7: Initial QUIC Transport Error Codes Registry Entries"],"requirements":[350,351]},{"id":"section-23","title":"References","lines":[]},{"id":"section-23.1","title":"Normative References","lines":[" [BCP38] Ferguson, P. and D. Senie, \"Network Ingress Filtering:"," Defeating Denial of Service Attacks which employ IP Source"," Address Spoofing\", BCP 38, RFC 2827, May 2000.",""," ",""," [DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T."," Völker, \"Packetization Layer Path MTU Discovery for"," Datagram Transports\", RFC 8899, DOI 10.17487/RFC8899,"," September 2020, .",""," [EARLY-ASSIGN]"," Cotton, M., \"Early IANA Allocation of Standards Track Code"," Points\", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January"," 2014, .",""," [IPv4] Postel, J., \"Internet Protocol\", STD 5, RFC 791,"," DOI 10.17487/RFC0791, September 1981,"," .",""," [QUIC-INVARIANTS]"," Thomson, M., \"Version-Independent Properties of QUIC\","," RFC 8999, DOI 10.17487/RFC8999, May 2021,"," .",""," [QUIC-RECOVERY]"," Iyengar, J., Ed. and I. Swett, Ed., \"QUIC Loss Detection"," and Congestion Control\", RFC 9002, DOI 10.17487/RFC9002,"," May 2021, .",""," [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., \"Using TLS to Secure"," QUIC\", RFC 9001, DOI 10.17487/RFC9001, May 2021,"," .",""," [RFC1191] Mogul, J. and S. Deering, \"Path MTU discovery\", RFC 1191,"," DOI 10.17487/RFC1191, November 1990,"," .",""," [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate"," Requirement Levels\", BCP 14, RFC 2119,"," DOI 10.17487/RFC2119, March 1997,"," .",""," [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, \"The Addition"," of Explicit Congestion Notification (ECN) to IP\","," RFC 3168, DOI 10.17487/RFC3168, September 2001,"," .",""," [RFC3629] Yergeau, F., \"UTF-8, a transformation format of ISO"," 10646\", STD 63, RFC 3629, DOI 10.17487/RFC3629, November"," 2003, .",""," [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,"," \"IPv6 Flow Label Specification\", RFC 6437,"," DOI 10.17487/RFC6437, November 2011,"," .",""," [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, \"UDP Usage"," Guidelines\", BCP 145, RFC 8085, DOI 10.17487/RFC8085,"," March 2017, .",""," [RFC8126] Cotton, M., Leiba, B., and T. Narten, \"Guidelines for"," Writing an IANA Considerations Section in RFCs\", BCP 26,"," RFC 8126, DOI 10.17487/RFC8126, June 2017,"," .",""," [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC"," 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,"," May 2017, .",""," [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,"," \"Path MTU Discovery for IP version 6\", STD 87, RFC 8201,"," DOI 10.17487/RFC8201, July 2017,"," .",""," [RFC8311] Black, D., \"Relaxing Restrictions on Explicit Congestion"," Notification (ECN) Experimentation\", RFC 8311,"," DOI 10.17487/RFC8311, January 2018,"," .",""," [TLS13] Rescorla, E., \"The Transport Layer Security (TLS) Protocol"," Version 1.3\", RFC 8446, DOI 10.17487/RFC8446, August 2018,"," .",""," [UDP] Postel, J., \"User Datagram Protocol\", STD 6, RFC 768,"," DOI 10.17487/RFC0768, August 1980,"," ."]},{"id":"section-23.2","title":"Informative References","lines":[" [AEAD] McGrew, D., \"An Interface and Algorithms for Authenticated"," Encryption\", RFC 5116, DOI 10.17487/RFC5116, January 2008,"," .",""," [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,"," \"Transport Layer Security (TLS) Application-Layer Protocol"," Negotiation Extension\", RFC 7301, DOI 10.17487/RFC7301,"," July 2014, .",""," [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, \"HTTP"," Alternative Services\", RFC 7838, DOI 10.17487/RFC7838,"," April 2016, .",""," [COOKIE] Barth, A., \"HTTP State Management Mechanism\", RFC 6265,"," DOI 10.17487/RFC6265, April 2011,"," .",""," [CSRF] Barth, A., Jackson, C., and J. Mitchell, \"Robust defenses"," for cross-site request forgery\", Proceedings of the 15th"," ACM conference on Computer and communications security -"," CCS '08, DOI 10.1145/1455770.1455782, 2008,"," .",""," [EARLY-DESIGN]"," Roskind, J., \"QUIC: Multiplexed Stream Transport Over"," UDP\", 2 December 2013, .",""," [GATEWAY] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S.,"," Sarolahti, P., and M. Kojo, \"An experimental study of home"," gateway characteristics\", Proceedings of the 10th ACM"," SIGCOMM conference on Internet measurement - IMC '10,"," DOI 10.1145/1879141.1879174, November 2010,"," .",""," [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., \"Hypertext"," Transfer Protocol Version 2 (HTTP/2)\", RFC 7540,"," DOI 10.17487/RFC7540, May 2015,"," .",""," [IPv6] Deering, S. and R. Hinden, \"Internet Protocol, Version 6"," (IPv6) Specification\", STD 86, RFC 8200,"," DOI 10.17487/RFC8200, July 2017,"," .",""," [QUIC-MANAGEABILITY]"," Kuehlewind, M. and B. Trammell, \"Manageability of the QUIC"," Transport Protocol\", Work in Progress, Internet-Draft,"," draft-ietf-quic-manageability-11, 21 April 2021,"," .",""," [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,"," \"Randomness Requirements for Security\", BCP 106, RFC 4086,"," DOI 10.17487/RFC4086, June 2005,"," .",""," [RFC1812] Baker, F., Ed., \"Requirements for IP Version 4 Routers\","," RFC 1812, DOI 10.17487/RFC1812, June 1995,"," .",""," [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G."," J., and E. Lear, \"Address Allocation for Private"," Internets\", BCP 5, RFC 1918, DOI 10.17487/RFC1918,"," February 1996, .",""," [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, \"TCP"," Selective Acknowledgment Options\", RFC 2018,"," DOI 10.17487/RFC2018, October 1996,"," .",""," [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, \"HMAC: Keyed-"," Hashing for Message Authentication\", RFC 2104,"," DOI 10.17487/RFC2104, February 1997,"," .",""," [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M."," Sooriyabandara, \"TCP Performance Implications of Network"," Path Asymmetry\", BCP 69, RFC 3449, DOI 10.17487/RFC3449,"," December 2002, .",""," [RFC4193] Hinden, R. and B. Haberman, \"Unique Local IPv6 Unicast"," Addresses\", RFC 4193, DOI 10.17487/RFC4193, October 2005,"," .",""," [RFC4291] Hinden, R. and S. Deering, \"IP Version 6 Addressing"," Architecture\", RFC 4291, DOI 10.17487/RFC4291, February"," 2006, .",""," [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., \"Internet"," Control Message Protocol (ICMPv6) for the Internet"," Protocol Version 6 (IPv6) Specification\", STD 89,"," RFC 4443, DOI 10.17487/RFC4443, March 2006,"," .",""," [RFC4787] Audet, F., Ed. and C. Jennings, \"Network Address"," Translation (NAT) Behavioral Requirements for Unicast"," UDP\", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January"," 2007, .",""," [RFC5681] Allman, M., Paxson, V., and E. Blanton, \"TCP Congestion"," Control\", RFC 5681, DOI 10.17487/RFC5681, September 2009,"," .",""," [RFC5869] Krawczyk, H. and P. Eronen, \"HMAC-based Extract-and-Expand"," Key Derivation Function (HKDF)\", RFC 5869,"," DOI 10.17487/RFC5869, May 2010,"," .",""," [RFC7983] Petit-Huguenin, M. and G. Salgueiro, \"Multiplexing Scheme"," Updates for Secure Real-time Transport Protocol (SRTP)"," Extension for Datagram Transport Layer Security (DTLS)\","," RFC 7983, DOI 10.17487/RFC7983, September 2016,"," .",""," [RFC8087] Fairhurst, G. and M. Welzl, \"The Benefits of Using"," Explicit Congestion Notification (ECN)\", RFC 8087,"," DOI 10.17487/RFC8087, March 2017,"," .",""," [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,"," \"Temporary Address Extensions for Stateless Address"," Autoconfiguration in IPv6\", RFC 8981,"," DOI 10.17487/RFC8981, February 2021,"," .",""," [SEC-CONS] Rescorla, E. and B. Korver, \"Guidelines for Writing RFC"," Text on Security Considerations\", BCP 72, RFC 3552,"," DOI 10.17487/RFC3552, July 2003,"," .",""," [SLOWLORIS]"," \"RSnake\" Hansen, R., \"Welcome to Slowloris - the low"," bandwidth, yet greedy and poisonous HTTP client!\", June"," 2009, ."]},{"id":"appendix-A","title":"Pseudocode","lines":[" The pseudocode in this section describes sample algorithms. These"," algorithms are intended to be correct and clear, rather than being"," optimally performant.",""," The pseudocode segments in this section are licensed as Code"," Components; see the Copyright Notice."]},{"id":"appendix-A.1","title":"Sample Variable-Length Integer Decoding","lines":[" The pseudocode in Figure 45 shows how a variable-length integer can"," be read from a stream of bytes. The function ReadVarint takes a"," single argument -- a sequence of bytes, which can be read in network"," byte order.",""," ReadVarint(data):"," // The length of variable-length integers is encoded in the"," // first two bits of the first byte."," v = data.next_byte()"," prefix = v >> 6"," length = 1 << prefix",""," // Once the length is known, remove these bits and read any"," // remaining bytes."," v = v & 0x3f"," repeat length-1 times:"," v = (v << 8) + data.next_byte()"," return v",""," Figure 45: Sample Variable-Length Integer Decoding Algorithm",""," For example, the eight-byte sequence 0xc2197c5eff14e88c decodes to"," the decimal value 151,288,809,941,952,652; the four-byte sequence"," 0x9d7f3e7d decodes to 494,878,333; the two-byte sequence 0x7bbd"," decodes to 15,293; and the single byte 0x25 decodes to 37 (as does"," the two-byte sequence 0x4025)."]},{"id":"appendix-A.2","title":"Sample Packet Number Encoding Algorithm","lines":[" The pseudocode in Figure 46 shows how an implementation can select an"," appropriate size for packet number encodings.",""," The EncodePacketNumber function takes two arguments:",""," * full_pn is the full packet number of the packet being sent.",""," * largest_acked is the largest packet number that has been"," acknowledged by the peer in the current packet number space, if"," any.",""," EncodePacketNumber(full_pn, largest_acked):",""," // The number of bits must be at least one more"," // than the base-2 logarithm of the number of contiguous"," // unacknowledged packet numbers, including the new packet."," if largest_acked is None:"," num_unacked = full_pn + 1"," else:"," num_unacked = full_pn - largest_acked",""," min_bits = log(num_unacked, 2) + 1"," num_bytes = ceil(min_bits / 8)",""," // Encode the integer value and truncate to"," // the num_bytes least significant bytes."," return encode(full_pn, num_bytes)",""," Figure 46: Sample Packet Number Encoding Algorithm",""," For example, if an endpoint has received an acknowledgment for packet"," 0xabe8b3 and is sending a packet with a number of 0xac5c02, there are"," 29,519 (0x734f) outstanding packet numbers. In order to represent at"," least twice this range (59,038 packets, or 0xe69e), 16 bits are"," required.",""," In the same state, sending a packet with a number of 0xace8fe uses"," the 24-bit encoding, because at least 18 bits are required to"," represent twice the range (131,222 packets, or 0x020096)."]},{"id":"appendix-A.3","title":"Sample Packet Number Decoding Algorithm","lines":[" The pseudocode in Figure 47 includes an example algorithm for"," decoding packet numbers after header protection has been removed.",""," The DecodePacketNumber function takes three arguments:",""," * largest_pn is the largest packet number that has been successfully"," processed in the current packet number space.",""," * truncated_pn is the value of the Packet Number field.",""," * pn_nbits is the number of bits in the Packet Number field (8, 16,"," 24, or 32).",""," DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):"," expected_pn = largest_pn + 1"," pn_win = 1 << pn_nbits"," pn_hwin = pn_win / 2"," pn_mask = pn_win - 1"," // The incoming packet number should be greater than"," // expected_pn - pn_hwin and less than or equal to"," // expected_pn + pn_hwin"," //"," // This means we cannot just strip the trailing bits from"," // expected_pn and add the truncated_pn because that might"," // yield a value outside the window."," //"," // The following code calculates a candidate value and"," // makes sure it's within the packet number window."," // Note the extra checks to prevent overflow and underflow."," candidate_pn = (expected_pn & ~pn_mask) | truncated_pn"," if candidate_pn <= expected_pn - pn_hwin and"," candidate_pn < (1 << 62) - pn_win:"," return candidate_pn + pn_win"," if candidate_pn > expected_pn + pn_hwin and"," candidate_pn >= pn_win:"," return candidate_pn - pn_win"," return candidate_pn",""," Figure 47: Sample Packet Number Decoding Algorithm",""," For example, if the highest successfully authenticated packet had a"," packet number of 0xa82f30ea, then a packet containing a 16-bit value"," of 0x9b32 will be decoded as 0xa82f9b32."]},{"id":"appendix-A.4","title":"Sample ECN Validation Algorithm","lines":[" Each time an endpoint commences sending on a new network path, it"," determines whether the path supports ECN; see Section 13.4. If the"," path supports ECN, the goal is to use ECN. Endpoints might also"," periodically reassess a path that was determined to not support ECN.",""," This section describes one method for testing new paths. This"," algorithm is intended to show how a path might be tested for ECN"," support. Endpoints can implement different methods.",""," The path is assigned an ECN state that is one of \"testing\","," \"unknown\", \"failed\", or \"capable\". On paths with a \"testing\" or"," \"capable\" state, the endpoint sends packets with an ECT marking --"," ECT(0) by default; otherwise, the endpoint sends unmarked packets.",""," To start testing a path, the ECN state is set to \"testing\", and"," existing ECN counts are remembered as a baseline.",""," The testing period runs for a number of packets or a limited time, as"," determined by the endpoint. The goal is not to limit the duration of"," the testing period but to ensure that enough marked packets are sent"," for received ECN counts to provide a clear indication of how the path"," treats marked packets. Section 13.4.2 suggests limiting this to ten"," packets or three times the PTO.",""," After the testing period ends, the ECN state for the path becomes"," \"unknown\". From the \"unknown\" state, successful validation of the"," ECN counts in an ACK frame (see Section 13.4.2.1) causes the ECN"," state for the path to become \"capable\", unless no marked packet has"," been acknowledged.",""," If validation of ECN counts fails at any time, the ECN state for the"," affected path becomes \"failed\". An endpoint can also mark the ECN"," state for a path as \"failed\" if marked packets are all declared lost"," or if they are all ECN-CE marked.",""," Following this algorithm ensures that ECN is rarely disabled for"," paths that properly support ECN. Any path that incorrectly modifies"," markings will cause ECN to be disabled. For those rare cases where"," marked packets are discarded by the path, the short duration of the"," testing period limits the number of losses incurred."]},{"id":"name-contributors","title":"Contributors","lines":[" The original design and rationale behind this protocol draw"," significantly from work by Jim Roskind [EARLY-DESIGN].",""," The IETF QUIC Working Group received an enormous amount of support"," from many people. The following people provided substantive"," contributions to this document:",""," * Alessandro Ghedini"," * Alyssa Wilk"," * Antoine Delignat-Lavaud"," * Brian Trammell"," * Christian Huitema"," * Colin Perkins"," * David Schinazi"," * Dmitri Tikhonov"," * Eric Kinnear"," * Eric Rescorla"," * Gorry Fairhurst"," * Ian Swett"," * Igor Lubashev"," * 奥 一穂 (Kazuho Oku)"," * Lars Eggert"," * Lucas Pardue"," * Magnus Westerlund"," * Marten Seemann"," * Martin Duke"," * Mike Bishop"," * Mikkel Fahnøe Jørgensen"," * Mirja Kühlewind"," * Nick Banks"," * Nick Harper"," * Patrick McManus"," * Roberto Peon"," * Ryan Hamilton"," * Subodh Iyengar"," * Tatsuhiro Tsujikawa"," * Ted Hardie"," * Tom Jones"," * Victor Vasiliev"]},{"id":"name-authors-addresses","title":"Authors' Addresses","lines":[" Jana Iyengar (editor)"," Fastly",""," Email: jri.ietf@gmail.com",""," Martin Thomson (editor)"," Mozilla",""," Email: mt@lowentropy.net"]}]},"https://www.rfc-editor.org/rfc/rfc9001":{"format":"ietf","requirements":[564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600,601,602,603,604,605,606,607,608,609,610,611,612,613,614,615,616,617,618,619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,684],"sections":[{"id":"name-abstract","title":"Abstract","lines":[" This document describes how Transport Layer Security (TLS) is used to"," secure QUIC."]},{"id":"name-status-of-this-memo","title":"Status of This Memo","lines":[" This is an Internet Standards Track document.",""," This document is a product of the Internet Engineering Task Force"," (IETF). It represents the consensus of the IETF community. It has"," received public review and has been approved for publication by the"," Internet Engineering Steering Group (IESG). Further information on"," Internet Standards is available in Section 2 of RFC 7841.",""," Information about the current status of this document, any errata,"," and how to provide feedback on it may be obtained at"," https://www.rfc-editor.org/info/rfc9001."]},{"id":"name-copyright-notice","title":"Copyright Notice","lines":[" Copyright (c) 2021 IETF Trust and the persons identified as the"," document authors. All rights reserved.",""," This document is subject to BCP 78 and the IETF Trust's Legal"," Provisions Relating to IETF Documents"," (https://trustee.ietf.org/license-info) in effect on the date of"," publication of this document. Please review these documents"," carefully, as they describe your rights and restrictions with respect"," to this document. Code Components extracted from this document must"," include Simplified BSD License text as described in Section 4.e of"," the Trust Legal Provisions and are provided without warranty as"," described in the Simplified BSD License."]},{"id":"name-table-of-contents","title":"Table of Contents","lines":[" 1. Introduction"," 2. Notational Conventions"," 2.1. TLS Overview"," 3. Protocol Overview"," 4. Carrying TLS Messages"," 4.1. Interface to TLS"," 4.1.1. Handshake Complete"," 4.1.2. Handshake Confirmed"," 4.1.3. Sending and Receiving Handshake Messages"," 4.1.4. Encryption Level Changes"," 4.1.5. TLS Interface Summary"," 4.2. TLS Version"," 4.3. ClientHello Size"," 4.4. Peer Authentication"," 4.5. Session Resumption"," 4.6. 0-RTT"," 4.6.1. Enabling 0-RTT"," 4.6.2. Accepting and Rejecting 0-RTT"," 4.6.3. Validating 0-RTT Configuration"," 4.7. HelloRetryRequest"," 4.8. TLS Errors"," 4.9. Discarding Unused Keys"," 4.9.1. Discarding Initial Keys"," 4.9.2. Discarding Handshake Keys"," 4.9.3. Discarding 0-RTT Keys"," 5. Packet Protection"," 5.1. Packet Protection Keys"," 5.2. Initial Secrets"," 5.3. AEAD Usage"," 5.4. Header Protection"," 5.4.1. Header Protection Application"," 5.4.2. Header Protection Sample"," 5.4.3. AES-Based Header Protection"," 5.4.4. ChaCha20-Based Header Protection"," 5.5. Receiving Protected Packets"," 5.6. Use of 0-RTT Keys"," 5.7. Receiving Out-of-Order Protected Packets"," 5.8. Retry Packet Integrity"," 6. Key Update"," 6.1. Initiating a Key Update"," 6.2. Responding to a Key Update"," 6.3. Timing of Receive Key Generation"," 6.4. Sending with Updated Keys"," 6.5. Receiving with Different Keys"," 6.6. Limits on AEAD Usage"," 6.7. Key Update Error Code"," 7. Security of Initial Messages"," 8. QUIC-Specific Adjustments to the TLS Handshake"," 8.1. Protocol Negotiation"," 8.2. QUIC Transport Parameters Extension"," 8.3. Removing the EndOfEarlyData Message"," 8.4. Prohibit TLS Middlebox Compatibility Mode"," 9. Security Considerations"," 9.1. Session Linkability"," 9.2. Replay Attacks with 0-RTT"," 9.3. Packet Reflection Attack Mitigation"," 9.4. Header Protection Analysis"," 9.5. Header Protection Timing Side Channels"," 9.6. Key Diversity"," 9.7. Randomness"," 10. IANA Considerations"," 11. References"," 11.1. Normative References"," 11.2. Informative References"," Appendix A. Sample Packet Protection"," A.1. Keys"," A.2. Client Initial"," A.3. Server Initial"," A.4. Retry"," A.5. ChaCha20-Poly1305 Short Header Packet"," Appendix B. AEAD Algorithm Analysis"," B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage"," Limits"," B.1.1. Confidentiality Limit"," B.1.2. Integrity Limit"," B.2. Analysis of AEAD_AES_128_CCM Usage Limits"," Contributors"," Authors' Addresses"]},{"id":"section-1","title":"Introduction","lines":[" This document describes how QUIC [QUIC-TRANSPORT] is secured using"," TLS [TLS13].",""," TLS 1.3 provides critical latency improvements for connection"," establishment over previous versions. Absent packet loss, most new"," connections can be established and secured within a single round"," trip; on subsequent connections between the same client and server,"," the client can often send application data immediately, that is,"," using a zero round-trip setup.",""," This document describes how TLS acts as a security component of QUIC."]},{"id":"section-2","title":"Notational Conventions","lines":[" 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 [RFC2119] [RFC8174] when, and only when, they appear in all"," capitals, as shown here.",""," This document uses the terminology established in [QUIC-TRANSPORT].",""," For brevity, the acronym TLS is used to refer to TLS 1.3, though a"," newer version could be used; see Section 4.2."]},{"id":"section-2.1","title":"TLS Overview","lines":[" TLS provides two endpoints with a way to establish a means of"," communication over an untrusted medium (for example, the Internet)."," TLS enables authentication of peers and provides confidentiality and"," integrity protection for messages that endpoints exchange.",""," Internally, TLS is a layered protocol, with the structure shown in"," Figure 1.",""," +-------------+------------+--------------+---------+"," Content | | | Application | |"," Layer | Handshake | Alerts | Data | ... |"," | | | | |"," +-------------+------------+--------------+---------+"," Record | |"," Layer | Records |"," | |"," +---------------------------------------------------+",""," Figure 1: TLS Layers",""," Each content-layer message (e.g., handshake, alerts, and application"," data) is carried as a series of typed TLS records by the record"," layer. Records are individually cryptographically protected and then"," transmitted over a reliable transport (typically TCP), which provides"," sequencing and guaranteed delivery.",""," The TLS authenticated key exchange occurs between two endpoints:"," client and server. The client initiates the exchange and the server"," responds. If the key exchange completes successfully, both client"," and server will agree on a secret. TLS supports both pre-shared key"," (PSK) and Diffie-Hellman over either finite fields or elliptic curves"," ((EC)DHE) key exchanges. PSK is the basis for Early Data (0-RTT);"," the latter provides forward secrecy (FS) when the (EC)DHE keys are"," destroyed. The two modes can also be combined to provide forward"," secrecy while using the PSK for authentication.",""," After completing the TLS handshake, the client will have learned and"," authenticated an identity for the server, and the server is"," optionally able to learn and authenticate an identity for the client."," TLS supports X.509 [RFC5280] certificate-based authentication for"," both server and client. When PSK key exchange is used (as in"," resumption), knowledge of the PSK serves to authenticate the peer.",""," The TLS key exchange is resistant to tampering by attackers, and it"," produces shared secrets that cannot be controlled by either"," participating peer.",""," TLS provides two basic handshake modes of interest to QUIC:",""," * A full 1-RTT handshake, in which the client is able to send"," application data after one round trip and the server immediately"," responds after receiving the first handshake message from the"," client.",""," * A 0-RTT handshake, in which the client uses information it has"," previously learned about the server to send application data"," immediately. This application data can be replayed by an"," attacker, so 0-RTT is not suitable for carrying instructions that"," might initiate any action that could cause unwanted effects if"," replayed.",""," A simplified TLS handshake with 0-RTT application data is shown in"," Figure 2.",""," Client Server",""," ClientHello"," (0-RTT Application Data) -------->"," ServerHello"," {EncryptedExtensions}"," {Finished}"," <-------- [Application Data]"," {Finished} -------->",""," [Application Data] <-------> [Application Data]",""," () Indicates messages protected by Early Data (0-RTT) Keys"," {} Indicates messages protected using Handshake Keys"," [] Indicates messages protected using Application Data"," (1-RTT) Keys",""," Figure 2: TLS Handshake with 0-RTT",""," Figure 2 omits the EndOfEarlyData message, which is not used in QUIC;"," see Section 8.3. Likewise, neither ChangeCipherSpec nor KeyUpdate"," messages are used by QUIC. ChangeCipherSpec is redundant in TLS 1.3;"," see Section 8.4. QUIC has its own key update mechanism; see"," Section 6.",""," Data is protected using a number of encryption levels:",""," * Initial keys",""," * Early data (0-RTT) keys",""," * Handshake keys",""," * Application data (1-RTT) keys",""," Application data can only appear in the early data and application"," data levels. Handshake and alert messages may appear in any level.",""," The 0-RTT handshake can be used if the client and server have"," previously communicated. In the 1-RTT handshake, the client is"," unable to send protected application data until it has received all"," of the handshake messages sent by the server."]},{"id":"section-3","title":"Protocol Overview","lines":[" QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality"," and integrity protection of packets. For this it uses keys derived"," from a TLS handshake [TLS13], but instead of carrying TLS records"," over QUIC (as with TCP), TLS handshake and alert messages are carried"," directly over the QUIC transport, which takes over the"," responsibilities of the TLS record layer, as shown in Figure 3.",""," +--------------+--------------+ +-------------+"," | TLS | TLS | | QUIC |"," | Handshake | Alerts | | Applications|"," | | | | (h3, etc.) |"," +--------------+--------------+-+-------------+"," | |"," | QUIC Transport |"," | (streams, reliability, congestion, etc.) |"," | |"," +---------------------------------------------+"," | |"," | QUIC Packet Protection |"," | |"," +---------------------------------------------+",""," Figure 3: QUIC Layers",""," QUIC also relies on TLS for authentication and negotiation of"," parameters that are critical to security and performance.",""," Rather than a strict layering, these two protocols cooperate: QUIC"," uses the TLS handshake; TLS uses the reliability, ordered delivery,"," and record layer provided by QUIC.",""," At a high level, there are two main interactions between the TLS and"," QUIC components:",""," * The TLS component sends and receives messages via the QUIC"," component, with QUIC providing a reliable stream abstraction to"," TLS.",""," * The TLS component provides a series of updates to the QUIC"," component, including (a) new packet protection keys to install and"," (b) state changes such as handshake completion, the server"," certificate, etc.",""," Figure 4 shows these interactions in more detail, with the QUIC"," packet protection being called out specially.",""," +------------+ +------------+"," | |<---- Handshake Messages ----->| |"," | |<- Validate 0-RTT Parameters ->| |"," | |<--------- 0-RTT Keys ---------| |"," | QUIC |<------- Handshake Keys -------| TLS |"," | |<--------- 1-RTT Keys ---------| |"," | |<------- Handshake Done -------| |"," +------------+ +------------+"," | ^"," | Protect | Protected"," v | Packet"," +------------+"," | QUIC |"," | Packet |"," | Protection |"," +------------+",""," Figure 4: QUIC and TLS Interactions",""," Unlike TLS over TCP, QUIC applications that want to send data do not"," send it using TLS Application Data records. Rather, they send it as"," QUIC STREAM frames or other frame types, which are then carried in"," QUIC packets."]},{"id":"section-4","title":"Carrying TLS Messages","lines":[" QUIC carries TLS handshake data in CRYPTO frames, each of which"," consists of a contiguous block of handshake data identified by an"," offset and length. Those frames are packaged into QUIC packets and"," encrypted under the current encryption level. As with TLS over TCP,"," once TLS handshake data has been delivered to QUIC, it is QUIC's"," responsibility to deliver it reliably. Each chunk of data that is"," produced by TLS is associated with the set of keys that TLS is",[[[],0," currently using. "],[[600,2364],240,"If QUIC needs to retransmit that data, it MUST use"]],[[[],0," "],[[600,2364],240,"the same keys even if TLS has already updated to newer keys."]],""," Each encryption level corresponds to a packet number space. The"," packet number space that is used determines the semantics of frames."," Some frames are prohibited in different packet number spaces; see"," Section 12.5 of [QUIC-TRANSPORT].",""," Because packets could be reordered on the wire, QUIC uses the packet"," type to indicate which keys were used to protect a given packet, as",[[[],0," shown in Table 1. "],[[601,1156],161,"When packets of different types need to be sent,"]],[[[],0," "],[[601,1156],161,"endpoints SHOULD use coalesced packets to send them in the same UDP"]],[[[],0," "],[[601,1156],161,"datagram."]],""," +=====================+=================+==================+"," | Packet Type | Encryption Keys | PN Space |"," +=====================+=================+==================+"," | Initial | Initial secrets | Initial |"," +=====================+-----------------+------------------+"," | 0-RTT Protected | 0-RTT | Application data |"," +=====================+-----------------+------------------+"," | Handshake | Handshake | Handshake |"," +=====================+-----------------+------------------+"," | Retry | Retry | N/A |"," +=====================+-----------------+------------------+"," | Version Negotiation | N/A | N/A |"," +=====================+-----------------+------------------+"," | Short Header | 1-RTT | Application data |"," +=====================+-----------------+------------------+",""," Table 1: Encryption Keys by Packet Type",""," Section 17 of [QUIC-TRANSPORT] shows how packets at the various"," encryption levels fit into the handshake process."],"requirements":[600,601]},{"id":"section-4.1","title":"Interface to TLS","lines":[" As shown in Figure 4, the interface from QUIC to TLS consists of four"," primary functions:",""," * Sending and receiving handshake messages",""," * Processing stored transport and application state from a resumed"," session and determining if it is valid to generate or accept 0-RTT"," data",""," * Rekeying (both transmit and receive)",""," * Updating handshake state",""," Additional functions might be needed to configure TLS. In"," particular, QUIC and TLS need to agree on which is responsible for"," validation of peer credentials, such as certificate validation"," [RFC5280]."]},{"id":"section-4.1.1","title":"Handshake Complete","lines":[" In this document, the TLS handshake is considered complete when the"," TLS stack has reported that the handshake is complete. This happens"," when the TLS stack has both sent a Finished message and verified the"," peer's Finished message. Verifying the peer's Finished message"," provides the endpoints with an assurance that previous handshake"," messages have not been modified. Note that the handshake does not"," complete at both endpoints simultaneously. Consequently, any"," requirement that is based on the completion of the handshake depends"," on the perspective of the endpoint in question."]},{"id":"section-4.1.2","title":"Handshake Confirmed","lines":[" In this document, the TLS handshake is considered confirmed at the",[[[],0," server when the handshake completes. "],[[564,1921,2154],240,"The server MUST send a"]],[[[],0," "],[[564,1921,2154],240,"HANDSHAKE_DONE frame as soon as the handshake is complete."],[[],0," At the"]]," client, the handshake is considered confirmed when a HANDSHAKE_DONE"," frame is received.","",[[[],0," "],[[565,1148],97,"Additionally, a client MAY consider the handshake to be confirmed"]],[[[],0," "],[[565,1148],97,"when it receives an acknowledgment for a 1-RTT packet."],[[],0," This can be"]]," implemented by recording the lowest packet number sent with 1-RTT"," keys and comparing it to the Largest Acknowledged field in any"," received 1-RTT ACK frame: once the latter is greater than or equal to"," the former, the handshake is confirmed."],"requirements":[564,565]},{"id":"section-4.1.3","title":"Sending and Receiving Handshake Messages","lines":[" In order to drive the handshake, TLS depends on being able to send"," and receive handshake messages. There are two basic functions on"," this interface: one where QUIC requests handshake messages and one"," where QUIC provides bytes that comprise handshake messages.",""," Before starting the handshake, QUIC provides TLS with the transport"," parameters (see Section 8.2) that it wishes to carry.",""," A QUIC client starts TLS by requesting TLS handshake bytes from TLS."," The client acquires handshake bytes before sending its first packet."," A QUIC server starts the process by providing TLS with the client's"," handshake bytes.",""," At any time, the TLS stack at an endpoint will have a current sending"," encryption level and a receiving encryption level. TLS encryption"," levels determine the QUIC packet type and keys that are used for"," protecting data.",""," Each encryption level is associated with a different sequence of"," bytes, which is reliably transmitted to the peer in CRYPTO frames."," When TLS provides handshake bytes to be sent, they are appended to"," the handshake bytes for the current encryption level. The encryption"," level then determines the type of packet that the resulting CRYPTO"," frame is carried in; see Table 1.",""," Four encryption levels are used, producing keys for Initial, 0-RTT,"," Handshake, and 1-RTT packets. CRYPTO frames are carried in just"," three of these levels, omitting the 0-RTT level. These four levels"," correspond to three packet number spaces: Initial and Handshake"," encrypted packets use their own separate spaces; 0-RTT and 1-RTT"," packets use the application data packet number space.",""," QUIC takes the unprotected content of TLS handshake records as the"," content of CRYPTO frames. TLS record protection is not used by QUIC."," QUIC assembles CRYPTO frames into QUIC packets, which are protected"," using QUIC packet protection.",""," QUIC CRYPTO frames only carry TLS handshake messages. TLS alerts are"," turned into QUIC CONNECTION_CLOSE error codes; see Section 4.8. TLS"," application data and other content types cannot be carried by QUIC at"," any encryption level; it is an error if they are received from the"," TLS stack.",""," When an endpoint receives a QUIC packet containing a CRYPTO frame"," from the network, it proceeds as follows:",""," * If the packet uses the current TLS receiving encryption level,"," sequence the data into the input flow as usual. As with STREAM"," frames, the offset is used to find the proper location in the data"," sequence. If the result of this process is that new data is"," available, then it is delivered to TLS in order.","",[[[],0," "],[[566,1149],225,"* If the packet is from a previously installed encryption level, it"]],[[[],0," "],[[566,1149],225,"MUST NOT contain data that extends past the end of previously"]],[[[],0," "],[[566,1149],225,"received data in that flow."],[[],0," "],[[567,1150],225,"Implementations MUST treat any"]],[[[],0," "],[[567,1150],225,"violations of this requirement as a connection error of type"]],[[[],0," "],[[567,1150],225,"PROTOCOL_VIOLATION."]],""," * If the packet is from a new encryption level, it is saved for"," later processing by TLS. Once TLS moves to receiving from this",[[[],0," encryption level, saved data can be provided to TLS. "],[[568,1151],225,"When TLS"]],[[[],0," "],[[568,1151],225,"provides keys for a higher encryption level, if there is data from"]],[[[],0," "],[[568,1151],225,"a previous encryption level that TLS has not consumed, this MUST"]],[[[],0," "],[[568,1151],225,"be treated as a connection error of type PROTOCOL_VIOLATION."]],""," Each time that TLS is provided with new data, new handshake bytes are"," requested from TLS. TLS might not provide any bytes if the handshake"," messages it has received are incomplete or it has no data to send.",""," The content of CRYPTO frames might either be processed incrementally"," by TLS or buffered until complete messages or flights are available."," TLS is responsible for buffering handshake bytes that have arrived in",[[[],0," order. "],[[2368],16,"QUIC is responsible for buffering handshake bytes that arrive"]],[[[],0," "],[[2368],16,"out of order or for encryption levels that are not yet ready."],[[],0," QUIC"]]," does not provide any means of flow control for CRYPTO frames; see"," Section 7.5 of [QUIC-TRANSPORT].",""," Once the TLS handshake is complete, this is indicated to QUIC along"," with any final handshake bytes that TLS needs to send. At this"," stage, the transport parameters that the peer advertised during the"," handshake are authenticated; see Section 8.2.",""," Once the handshake is complete, TLS becomes passive. TLS can still"," receive data from its peer and respond in kind, but it will not need"," to send more data unless specifically requested -- either by an"," application or QUIC. One reason to send data is that the server"," might wish to provide additional or updated session tickets to a"," client.",""," When the handshake is complete, QUIC only needs to provide TLS with"," any data that arrives in CRYPTO streams. In the same manner that is"," used during the handshake, new data is requested from TLS after"," providing received data."],"requirements":[566,567,568]},{"id":"section-4.1.4","title":"Encryption Level Changes","lines":[" As keys at a given encryption level become available to TLS, TLS"," indicates to QUIC that reading or writing keys at that encryption"," level are available.",""," The availability of new keys is always a result of providing inputs"," to TLS. TLS only provides new keys after being initialized (by a"," client) or when provided with new handshake data.",""," However, a TLS implementation could perform some of its processing"," asynchronously. In particular, the process of validating a",[[[],0," certificate can take some time. "],[[569,1702,2369],176,"While waiting for TLS processing to"]],[[[],0," "],[[569,1702,2369],176,"complete, an endpoint SHOULD buffer received packets if they might be"]],[[[],0," "],[[569,1702,2369],176,"processed using keys that are not yet available."],[[],0," These packets can"]],[[[],0," be processed once keys are provided by TLS. "],[[570,1152],161,"An endpoint SHOULD"]],[[[],0," "],[[570,1152],161,"continue to respond to packets that can be processed during this"]],[[[],0," "],[[570,1152],161,"time."]],""," After processing inputs, TLS might produce handshake bytes, keys for"," new encryption levels, or both.",""," TLS provides QUIC with three items as a new encryption level becomes"," available:",""," * A secret",""," * An Authenticated Encryption with Associated Data (AEAD) function",""," * A Key Derivation Function (KDF)",""," These values are based on the values that TLS negotiates and are used"," by QUIC to generate packet and header protection keys; see Section 5"," and Section 5.4.",""," If 0-RTT is possible, it is ready after the client sends a TLS"," ClientHello message or the server receives that message. After"," providing a QUIC client with the first handshake bytes, the TLS stack"," might signal the change to 0-RTT keys. On the server, after"," receiving handshake bytes that contain a ClientHello message, a TLS"," server might signal that 0-RTT keys are available.",""," Although TLS only uses one encryption level at a time, QUIC may use"," more than one level. For instance, after sending its Finished"," message (using a CRYPTO frame at the Handshake encryption level) an"," endpoint can send STREAM data (in 1-RTT encryption). If the Finished"," message is lost, the endpoint uses the Handshake encryption level to"," retransmit the lost message. Reordering or loss of packets can mean"," that QUIC will need to handle packets at multiple encryption levels."," During the handshake, this means potentially handling packets at"," higher and lower encryption levels than the current encryption level"," used by TLS.",""," In particular, server implementations need to be able to read packets"," at the Handshake encryption level at the same time as the 0-RTT"," encryption level. A client could interleave ACK frames that are"," protected with Handshake keys with 0-RTT data, and the server needs"," to process those acknowledgments in order to detect lost Handshake"," packets.",""," QUIC also needs access to keys that might not ordinarily be available"," to a TLS implementation. For instance, a client might need to"," acknowledge Handshake packets before it is ready to send CRYPTO"," frames at that encryption level. TLS therefore needs to provide keys"," to QUIC before it might produce them for its own use."],"requirements":[569,570]},{"id":"section-4.1.5","title":"TLS Interface Summary","lines":[" Figure 5 summarizes the exchange between QUIC and TLS for both client"," and server. Solid arrows indicate packets that carry handshake data;"," dashed arrows show where application data can be sent. Each arrow is"," tagged with the encryption level used for that transmission.",""," Client Server"," ====== ======",""," Get Handshake"," Initial ------------->"," Install tx 0-RTT keys"," 0-RTT - - - - - - - ->",""," Handshake Received"," Get Handshake"," <------------- Initial"," Install rx 0-RTT keys"," Install Handshake keys"," Get Handshake"," <----------- Handshake"," Install tx 1-RTT keys"," <- - - - - - - - 1-RTT",""," Handshake Received (Initial)"," Install Handshake keys"," Handshake Received (Handshake)"," Get Handshake"," Handshake ----------->"," Handshake Complete"," Install 1-RTT keys"," 1-RTT - - - - - - - ->",""," Handshake Received"," Handshake Complete"," Handshake Confirmed"," Install rx 1-RTT keys"," <--------------- 1-RTT"," (HANDSHAKE_DONE)"," Handshake Confirmed",""," Figure 5: Interaction Summary between QUIC and TLS",""," Figure 5 shows the multiple packets that form a single \"flight\" of"," messages being processed individually, to show what incoming messages"," trigger different actions. This shows multiple \"Get Handshake\""," invocations to retrieve handshake messages at different encryption"," levels. New handshake messages are requested after incoming packets"," have been processed.",""," Figure 5 shows one possible structure for a simple handshake"," exchange. The exact process varies based on the structure of"," endpoint implementations and the order in which packets arrive."," Implementations could use a different number of operations or execute"," them in other orders."]},{"id":"section-4.2","title":"TLS Version","lines":[" This document describes how TLS 1.3 [TLS13] is used with QUIC.",""," In practice, the TLS handshake will negotiate a version of TLS to"," use. This could result in a version of TLS newer than 1.3 being"," negotiated if both endpoints support that version. This is"," acceptable provided that the features of TLS 1.3 that are used by"," QUIC are supported by the newer version.","",[[[],0," "],[[571,2382],240,"Clients MUST NOT offer TLS versions older than 1.3."],[[],0," A badly"]]," configured TLS implementation could negotiate TLS 1.2 or another",[[[],0," older version of TLS. "],[[572,2383],240,"An endpoint MUST terminate the connection if a"]],[[[],0," "],[[572,2383],240,"version of TLS older than 1.3 is negotiated."]]],"requirements":[571,572]},{"id":"section-4.3","title":"ClientHello Size","lines":[" The first Initial packet from a client contains the start or all of"," its first cryptographic handshake message, which for TLS is the"," ClientHello. Servers might need to parse the entire ClientHello"," (e.g., to access extensions such as Server Name Identification (SNI)"," or Application-Layer Protocol Negotiation (ALPN)) in order to decide"," whether to accept the new incoming QUIC connection. If the"," ClientHello spans multiple Initial packets, such servers would need"," to buffer the first received fragments, which could consume excessive",[[[],0," resources if the client's address has not yet been validated. "],[[573,1153],97,"To"]],[[[],0," "],[[573,1153],97,"avoid this, servers MAY use the Retry feature (see Section 8.1 of"]],[[[],0," "],[[573,1153],97,"[QUIC-TRANSPORT]) to only buffer partial ClientHello messages from"]],[[[],0," "],[[573,1153],97,"clients with a validated address."]],""," QUIC packet and framing add at least 36 bytes of overhead to the"," ClientHello message. That overhead increases if the client chooses a"," Source Connection ID field longer than zero bytes. Overheads also do"," not include the token or a Destination Connection ID longer than 8"," bytes, both of which might be required if a server sends a Retry"," packet.",""," A typical TLS ClientHello can easily fit into a 1200-byte packet."," However, in addition to the overheads added by QUIC, there are"," several variables that could cause this limit to be exceeded. Large"," session tickets, multiple or large key shares, and long lists of"," supported ciphers, signature algorithms, versions, QUIC transport"," parameters, and other negotiable parameters and extensions could"," cause this message to grow.",""," For servers, in addition to connection IDs and tokens, the size of"," TLS session tickets can have an effect on a client's ability to"," connect efficiently. Minimizing the size of these values increases"," the probability that clients can use them and still fit their entire"," ClientHello message in their first Initial packet.",""," The TLS implementation does not need to ensure that the ClientHello"," is large enough to meet QUIC's requirements for datagrams that carry"," Initial packets; see Section 14.1 of [QUIC-TRANSPORT]. QUIC"," implementations use PADDING frames or packet coalescing to ensure"," that datagrams are large enough."],"requirements":[573]},{"id":"section-4.4","title":"Peer Authentication","lines":[" The requirements for authentication depend on the application"," protocol that is in use. TLS provides server authentication and"," permits the server to request client authentication.","",[[[],0," "],[[574,2392],240,"A client MUST authenticate the identity of the server."],[[],0," This"]]," typically involves verification that the identity of the server is"," included in a certificate and that the certificate is issued by a"," trusted entity (see for example [RFC2818]).",""," | Note: Where servers provide certificates for authentication,"," | the size of the certificate chain can consume a large number of"," | bytes. Controlling the size of certificate chains is critical"," | to performance in QUIC as servers are limited to sending 3"," | bytes for every byte received prior to validating the client"," | address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a"," | certificate chain can be managed by limiting the number of"," | names or extensions; using keys with small public key"," | representations, like ECDSA; or by using certificate"," | compression [COMPRESS].","",[[[],0," "],[[575,2393],112,"A server MAY request that the client authenticate during the"]],[[[],0," "],[[575,2393],112,"handshake."],[[],0," "],[[576,2394],112,"A server MAY refuse a connection if the client is unable"]],[[[],0," "],[[576,2394],112,"to authenticate when requested."],[[],0," The requirements for client"]]," authentication vary based on application protocol and deployment.","",[[[],0," "],[[577,1174],225,"A server MUST NOT use post-handshake client authentication (as"]],[[[],0," "],[[577,1174],225,"defined in Section 4.6.2 of [TLS13]) because the multiplexing offered"]],[[[],0," "],[[577,1174],225,"by QUIC prevents clients from correlating the certificate request"]],[[[],0," "],[[577,1174],225,"with the application-level event that triggered it (see"]],[[[],0," "],[[577,1174],225,"[HTTP2-TLS13])."],[[],0," "],[[578,1175],225,"More specifically, servers MUST NOT send post-"]],[[[],0," "],[[578,1175],225,"handshake TLS CertificateRequest messages, and clients MUST treat"]],[[[],0," "],[[578,1175],225,"receipt of such messages as a connection error of type"]],[[[],0," "],[[578,1175],225,"PROTOCOL_VIOLATION."]]],"requirements":[574,575,576,577,578]},{"id":"section-4.5","title":"Session Resumption","lines":[" QUIC can use the session resumption feature of TLS 1.3. It does this"," by carrying NewSessionTicket messages in CRYPTO frames after the"," handshake is complete. Session resumption can be used to provide"," 0-RTT and can also be used when 0-RTT is disabled.",""," Endpoints that use session resumption might need to remember some"," information about the current connection when creating a resumed"," connection. TLS requires that some information be retained; see"," Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state"," being retained when resuming a connection unless 0-RTT is also used;"," see Section 7.4.1 of [QUIC-TRANSPORT] and Section 4.6.1. Application"," protocols could depend on state that is retained between resumed"," connections.",""," Clients can store any state required for resumption along with the"," session ticket. Servers can use the session ticket to help carry"," state.",""," Session resumption allows servers to link activity on the original"," connection with the resumed connection, which might be a privacy"," issue for clients. Clients can choose not to enable resumption to",[[[],0," avoid creating this correlation. "],[[579,1176],161,"Clients SHOULD NOT reuse tickets as"]],[[[],0," "],[[579,1176],161,"that allows entities other than the server to correlate connections;"]],[[[],0," "],[[579,1176],161,"see Appendix C.4 of [TLS13]."]]],"requirements":[579]},{"id":"section-4.6","title":"0-RTT","lines":[" The 0-RTT feature in QUIC allows a client to send application data"," before the handshake is complete. This is made possible by reusing"," negotiated parameters from a previous connection. To enable this,"," 0-RTT depends on the client remembering critical parameters and"," providing the server with a TLS session ticket that allows the server"," to recover the same information.",""," This information includes parameters that determine TLS state, as"," governed by [TLS13], QUIC transport parameters, the chosen"," application protocol, and any information the application protocol"," might need; see Section 4.6.3. This information determines how 0-RTT"," packets and their contents are formed.",""," To ensure that the same information is available to both endpoints,"," all information used to establish 0-RTT comes from the same"," connection. Endpoints cannot selectively disregard information that"," might alter the sending or processing of 0-RTT.",""," [TLS13] sets a limit of seven days on the time between the original"," connection and any attempt to use 0-RTT. There are other constraints"," on 0-RTT usage, notably those caused by the potential exposure to"," replay attack; see Section 9.2."]},{"id":"section-4.6.1","title":"Enabling 0-RTT","lines":[" The TLS early_data extension in the NewSessionTicket message is"," defined to convey (in the max_early_data_size parameter) the amount"," of TLS 0-RTT data the server is willing to accept. QUIC does not use"," TLS early data. QUIC uses 0-RTT packets to carry early data."," Accordingly, the max_early_data_size parameter is repurposed to hold"," a sentinel value 0xffffffff to indicate that the server is willing to"," accept QUIC 0-RTT data. To indicate that the server does not accept"," 0-RTT data, the early_data extension is omitted from the"," NewSessionTicket. The amount of data that the client can send in"," QUIC 0-RTT is controlled by the initial_max_data transport parameter"," supplied by the server.","",[[[],0," "],[[580,3144],228,"Servers MUST NOT send the early_data extension with a"]],[[[],0," "],[[580,3144],228,"max_early_data_size field set to any value other than 0xffffffff."],[[],0," "],[[],0,"A"]],[[[],0," "],[[581,1177],225,"client MUST treat receipt of a NewSessionTicket that contains an"]],[[[],0," "],[[581,1177],225,"early_data extension with any other value as a connection error of"]],[[[],0," "],[[581,1177],225,"type PROTOCOL_VIOLATION."]],""," A client that wishes to send 0-RTT packets uses the early_data"," extension in the ClientHello message of a subsequent handshake; see"," Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT"," packets.",""," A client that attempts 0-RTT might also provide an address validation"," token if the server has sent a NEW_TOKEN frame; see Section 8.1 of"," [QUIC-TRANSPORT]."],"requirements":[580,581]},{"id":"section-4.6.2","title":"Accepting and Rejecting 0-RTT","lines":[" A server accepts 0-RTT by sending an early_data extension in the"," EncryptedExtensions; see Section 4.2.10 of [TLS13]. The server then"," processes and acknowledges the 0-RTT packets that it receives.",""," A server rejects 0-RTT by sending the EncryptedExtensions without an"," early_data extension. A server will always reject 0-RTT if it sends",[[[],0," a TLS HelloRetryRequest. "],[[582,1187],225,"When rejecting 0-RTT, a server MUST NOT"]],[[[],0," "],[[582,1187],225,"process any 0-RTT packets, even if it could."],[[],0," "],[[583,1188],161,"When 0-RTT was"]],[[[],0," "],[[583,1188],161,"rejected, a client SHOULD treat receipt of an acknowledgment for a"]],[[[],0," "],[[583,1188],161,"0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it"]],[[[],0," "],[[583,1188],161,"is able to detect the condition."]],""," When 0-RTT is rejected, all connection characteristics that the"," client assumed might be incorrect. This includes the choice of"," application protocol, transport parameters, and any application",[[[],0," configuration. "],[[584,1189],225,"The client therefore MUST reset the state of all"]],[[[],0," "],[[584,1189],225,"streams, including application state bound to those streams."]],"",[[[],0," "],[[585,1190],97,"A client MAY reattempt 0-RTT if it receives a Retry or Version"]],[[[],0," "],[[585,1190],97,"Negotiation packet."],[[],0," These packets do not signify rejection of 0-RTT."]]],"requirements":[582,583,584,585]},{"id":"section-4.6.3","title":"Validating 0-RTT Configuration","lines":[" When a server receives a ClientHello with the early_data extension,"," it has to decide whether to accept or reject 0-RTT data from the"," client. Some of this decision is made by the TLS stack (e.g.,"," checking that the cipher suite being resumed was included in the"," ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack"," has no reason to reject 0-RTT data, the QUIC stack or the application"," protocol using QUIC might reject 0-RTT data because the configuration"," of the transport or application associated with the resumed session"," is not compatible with the server's current configuration.",""," QUIC requires additional transport state to be associated with a"," 0-RTT session ticket. One common way to implement this is using"," stateless session tickets and storing this state in the session"," ticket. Application protocols that use QUIC might have similar"," requirements regarding associating or storing state. This associated"," state is used for deciding whether 0-RTT data must be rejected. For"," example, HTTP/3 settings [QUIC-HTTP] determine how 0-RTT data from"," the client is interpreted. Other applications using QUIC could have"," different requirements for determining whether to accept or reject"," 0-RTT data."]},{"id":"section-4.7","title":"HelloRetryRequest","lines":[" The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be"," used to request that a client provide new information, such as a key"," share, or to validate some characteristic of the client. From the"," perspective of QUIC, HelloRetryRequest is not differentiated from"," other cryptographic handshake messages that are carried in Initial",[[[],0," packets. "],[[586,1178],161,"Although it is in principle possible to use this feature"]],[[[],0," "],[[586,1178],161,"for address verification, QUIC implementations SHOULD instead use the"]],[[[],0," "],[[586,1178],161,"Retry feature; see Section 8.1 of [QUIC-TRANSPORT]."]]],"requirements":[586]},{"id":"section-4.8","title":"TLS Errors","lines":[" If TLS experiences an error, it generates an appropriate alert as"," defined in Section 6 of [TLS13].",""," A TLS alert is converted into a QUIC connection error. The"," AlertDescription value is added to 0x0100 to produce a QUIC error"," code from the range reserved for CRYPTO_ERROR; see Section 20.1 of"," [QUIC-TRANSPORT]. The resulting value is sent in a QUIC"," CONNECTION_CLOSE frame of type 0x1c.",""," QUIC is only able to convey an alert level of \"fatal\". In TLS 1.3,"," the only existing uses for the \"warning\" level are to signal",[[[],0," connection close; see Section 6.1 of [TLS13]. "],[[587,2397],240,"As QUIC provides"]],[[[],0," "],[[587,2397],240,"alternative mechanisms for connection termination and the TLS"]],[[[],0," "],[[587,2397],240,"connection is only closed if an error is encountered, a QUIC endpoint"]],[[[],0," "],[[587,2397],240,"MUST treat any alert from TLS as if it were at the \"fatal\" level."]],""," QUIC permits the use of a generic code in place of a specific error"," code; see Section 11 of [QUIC-TRANSPORT]. For TLS alerts, this"," includes replacing any alert with a generic alert, such as",[[[],0," handshake_failure (0x0128 in QUIC). "],[[588,1186],97,"Endpoints MAY use a generic"]],[[[],0," "],[[588,1186],97,"error code to avoid possibly exposing confidential information."]]],"requirements":[587,588]},{"id":"section-4.9","title":"Discarding Unused Keys","lines":[" After QUIC has completed a move to a new encryption level, packet"," protection keys for previous encryption levels can be discarded."," This occurs several times during the handshake, as well as when keys"," are updated; see Section 6.",""," Packet protection keys are not discarded immediately when new keys",[[[],0," are available. "],[[597,2365],240,"If packets from a lower encryption level contain"]],[[[],0," "],[[597,2365],240,"CRYPTO frames, frames that retransmit that data MUST be sent at the"]],[[[],0," "],[[597,2365],240,"same encryption level."],[[],0," Similarly, an endpoint generates"]]," acknowledgments for packets at the same encryption level as the"," packet being acknowledged. Thus, it is possible that keys for a"," lower encryption level are needed for a short time after keys for a"," newer encryption level are available.",""," An endpoint cannot discard keys for a given encryption level unless"," it has received all the cryptographic handshake messages from its"," peer at that encryption level and its peer has done the same."," Different methods for determining this are provided for Initial keys"," (Section 4.9.1) and Handshake keys (Section 4.9.2). These methods do"," not prevent packets from being received or sent at that encryption"," level because a peer might not have received all the acknowledgments"," necessary.","",[[[],0," "],[[598,1154],225,"Though an endpoint might retain older keys, new data MUST be sent at"]],[[[],0," "],[[598,1154],225,"the highest currently available encryption level."],[[],0," Only ACK frames"]]," and retransmissions of data in CRYPTO frames are sent at a previous",[[[],0," encryption level. "],[[599,1155],97,"These packets MAY also include PADDING frames."]]],"requirements":[597,598,599]},{"id":"section-4.9.1","title":"Discarding Initial Keys","lines":[" Packets protected with Initial secrets (Section 5.2) are not"," authenticated, meaning that an attacker could spoof packets with the"," intent to disrupt a connection. To limit these attacks, Initial"," packet protection keys are discarded more aggressively than other"," keys.",""," The successful use of Handshake packets indicates that no more"," Initial packets need to be exchanged, as these keys can only be"," produced after receiving all CRYPTO frames from Initial packets.",[[[],0," "],[[589,1994,2096],240,"Thus, a client MUST discard Initial keys when it first sends a"]],[[[],0," "],[[589,1994,2096],240,"Handshake packet and a server MUST discard Initial keys when it first"]],[[[],0," "],[[589,1994,2096],240,"successfully processes a Handshake packet."],[[],0," "],[[590,1995,2097],240,"Endpoints MUST NOT send"]],[[[],0," "],[[590,1995,2097],240,"Initial packets after this point."]],""," This results in abandoning loss recovery state for the Initial"," encryption level and ignoring any outstanding Initial packets."],"requirements":[589,590]},{"id":"section-4.9.2","title":"Discarding Handshake Keys","lines":[[[[],0," "],[[591,1923,2668],244,"An endpoint MUST discard its Handshake keys when the TLS handshake is"]],[[[],0," "],[[591,1923,2668],244,"confirmed (Section 4.1.2)."]]],"requirements":[591]},{"id":"section-4.9.3","title":"Discarding 0-RTT Keys","lines":[" 0-RTT and 1-RTT packets share the same packet number space, and"," clients do not send 0-RTT packets after sending a 1-RTT packet"," (Section 5.6).","",[[[],0," "],[[592,2083],176,"Therefore, a client SHOULD discard 0-RTT keys as soon as it installs"]],[[[],0," "],[[592,2083],176,"1-RTT keys as they have no use after that moment."]],"",[[[],0," "],[[593,1901],112,"Additionally, a server MAY discard 0-RTT keys as soon as it receives"]],[[[],0," "],[[593,1901],112,"a 1-RTT packet."],[[],0," However, due to packet reordering, a 0-RTT packet"]],[[[],0," could arrive after a 1-RTT packet. "],[[594,1902],112,"Servers MAY temporarily retain"]],[[[],0," "],[[594,1902],112,"0-RTT keys to allow decrypting reordered packets without requiring"]],[[[],0," "],[[594,1902],112,"their contents to be retransmitted with 1-RTT keys."],[[],0," "],[[595,2185,2186],240,"After receiving"]],[[[],0," "],[[595,2185,2186],240,"a 1-RTT packet, servers MUST discard 0-RTT keys within a short time;"]],[[[],0," "],[[595,2185,2186],240,"the RECOMMENDED time period is three times the Probe Timeout (PTO,"]],[[[],0," "],[[595,2185,2186],240,"see [QUIC-RECOVERY])."],[[],0," "],[[596,1191],97,"A server MAY discard 0-RTT keys earlier if it"]],[[[],0," "],[[596,1191],97,"determines that it has received all 0-RTT packets, which can be done"]],[[[],0," "],[[596,1191],97,"by keeping track of missing packet numbers."]]],"requirements":[592,593,594,595,596]},{"id":"section-5","title":"Packet Protection","lines":[" As with TLS over TCP, QUIC protects packets with keys derived from"," the TLS handshake, using the AEAD algorithm [AEAD] negotiated by TLS.",""," QUIC packets have varying protections depending on their type:",""," * Version Negotiation packets have no cryptographic protection.",""," * Retry packets use AEAD_AES_128_GCM to provide protection against"," accidental modification and to limit the entities that can produce"," a valid Retry; see Section 5.8.",""," * Initial packets use AEAD_AES_128_GCM with keys derived from the"," Destination Connection ID field of the first Initial packet sent"," by the client; see Section 5.2.",""," * All other packets have strong cryptographic protections for"," confidentiality and integrity, using keys and algorithms"," negotiated by TLS.",""," This section describes how packet protection is applied to Handshake"," packets, 0-RTT packets, and 1-RTT packets. The same packet"," protection process is applied to Initial packets. However, as it is"," trivial to determine the keys used for Initial packets, these packets"," are not considered to have confidentiality or integrity protection."," Retry packets use a fixed key and so similarly lack confidentiality"," and integrity protection."]},{"id":"section-5.1","title":"Packet Protection Keys","lines":[" QUIC derives packet protection keys in the same way that TLS derives"," record protection keys.",""," Each encryption level has separate secret values for protection of"," packets sent in each direction. These traffic secrets are derived by"," TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all"," encryption levels except the Initial encryption level. The secrets"," for the Initial encryption level are computed based on the client's"," initial Destination Connection ID, as described in Section 5.2.",""," The keys used for packet protection are computed from the TLS secrets"," using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label"," function described in Section 7.1 of [TLS13] is used with the hash"," function from the negotiated cipher suite. All uses of HKDF-Expand-"," Label in QUIC use a zero-length Context.",""," Note that labels, which are described using strings, are encoded as"," bytes using ASCII [ASCII] without quotes or any trailing NUL byte.","",[[[],0," "],[[602,1157],225,"Other versions of TLS MUST provide a similar function in order to be"]],[[[],0," "],[[602,1157],225,"used with QUIC."]],""," The current encryption level secret and the label \"quic key\" are"," input to the KDF to produce the AEAD key; the label \"quic iv\" is used"," to derive the Initialization Vector (IV); see Section 5.3. The"," header protection key uses the \"quic hp\" label; see Section 5.4."," Using these labels provides key separation between QUIC and TLS; see"," Section 9.6.",""," Both \"quic key\" and \"quic hp\" are used to produce keys, so the Length"," provided to HKDF-Expand-Label along with these labels is determined"," by the size of keys in the AEAD or header protection algorithm. The"," Length provided with \"quic iv\" is the minimum length of the AEAD"," nonce or 8 bytes if that is larger; see [AEAD].",""," The KDF used for initial secrets is always the HKDF-Expand-Label"," function from TLS 1.3; see Section 5.2."],"requirements":[602]},{"id":"section-5.2","title":"Initial Secrets","lines":[" Initial packets apply the packet protection process, but use a secret"," derived from the Destination Connection ID field from the client's"," first Initial packet.",""," This secret is determined by using HKDF-Extract (see Section 2.2 of"," [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and"," the input keying material (IKM) of the Destination Connection ID"," field. This produces an intermediate pseudorandom key (PRK) that is"," used to derive two separate secrets for sending and receiving.",""," The secret used by clients to construct Initial packets uses the PRK"," and the label \"client in\" as input to the HKDF-Expand-Label function"," from TLS [TLS13] to produce a 32-byte secret. Packets constructed by"," the server use the same process with the label \"server in\". The hash"," function for HKDF when deriving initial secrets and keys is SHA-256"," [SHA].",""," This process in pseudocode is:",""," initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a"," initial_secret = HKDF-Extract(initial_salt,"," client_dst_connection_id)",""," client_initial_secret = HKDF-Expand-Label(initial_secret,"," \"client in\", \"\","," Hash.length)"," server_initial_secret = HKDF-Expand-Label(initial_secret,"," \"server in\", \"\","," Hash.length)",""," The connection ID used with HKDF-Expand-Label is the Destination"," Connection ID in the Initial packet sent by the client. This will be"," a randomly selected value unless the client creates the Initial"," packet after receiving a Retry packet, where the Destination"," Connection ID is selected by the server.","",[[[],0," "],[[603,2372,3139],180,"Future versions of QUIC SHOULD generate a new salt value, thus"]],[[[],0," "],[[603,2372,3139],180,"ensuring that the keys are different for each version of QUIC."],[[],0," This"]]," prevents a middlebox that recognizes only one version of QUIC from"," seeing or modifying the contents of packets from future versions.","",[[[],0," "],[[604,3014,3138],228,"The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for"]],[[[],0," "],[[604,3014,3138],228,"Initial packets even where the TLS versions offered do not include"]],[[[],0," "],[[604,3014,3138],228,"TLS 1.3."]],""," The secrets used for constructing subsequent Initial packets change"," when a server sends a Retry packet to use the connection ID value"," selected by the server. The secrets do not change when a client"," changes the Destination Connection ID it uses in response to an"," Initial packet from the server.",""," | Note: The Destination Connection ID field could be any length"," | up to 20 bytes, including zero length if the server sends a"," | Retry packet with a zero-length Source Connection ID field."," | After a Retry, the Initial keys provide the client no assurance"," | that the server received its packet, so the client has to rely"," | on the exchange that included the Retry packet to validate the"," | server address; see Section 8.1 of [QUIC-TRANSPORT].",""," Appendix A contains sample Initial packets."],"requirements":[603,604]},{"id":"section-5.3","title":"AEAD Usage","lines":[" The Authenticated Encryption with Associated Data (AEAD) function"," (see [AEAD]) used for QUIC packet protection is the AEAD that is"," negotiated for use with the TLS connection. For example, if TLS is"," using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM"," function is used.",""," QUIC can use any of the cipher suites defined in [TLS13] with the",[[[],0," exception of TLS_AES_128_CCM_8_SHA256. "],[[605,2379,2380,2381],240,"A cipher suite MUST NOT be"]],[[[],0," "],[[605,2379,2380,2381],240,"negotiated unless a header protection scheme is defined for the"]],[[[],0," "],[[605,2379,2380,2381],240,"cipher suite."],[[],0," This document defines a header protection scheme for"]]," all cipher suites defined in [TLS13] aside from"," TLS_AES_128_CCM_8_SHA256. These cipher suites have a 16-byte"," authentication tag and produce an output 16 bytes larger than their"," input.","",[[[],0," "],[[606,1179],225,"An endpoint MUST NOT reject a ClientHello that offers a cipher suite"]],[[[],0," "],[[606,1179],225,"that it does not support, or it would be impossible to deploy a new"]],[[[],0," "],[[606,1179],225,"cipher suite."],[[],0," This also applies to TLS_AES_128_CCM_8_SHA256."]],""," When constructing packets, the AEAD function is applied prior to"," applying header protection; see Section 5.4. The unprotected packet"," header is part of the associated data (A). When processing packets,"," an endpoint first removes the header protection.",""," The key and IV for the packet are computed as described in"," Section 5.1. The nonce, N, is formed by combining the packet"," protection IV with the packet number. The 62 bits of the"," reconstructed QUIC packet number in network byte order are left-"," padded with zeros to the size of the IV. The exclusive OR of the"," padded packet number and the IV forms the AEAD nonce.",""," The associated data, A, for the AEAD is the contents of the QUIC"," header, starting from the first byte of either the short or long"," header, up to and including the unprotected packet number.",""," The input plaintext, P, for the AEAD is the payload of the QUIC"," packet, as described in [QUIC-TRANSPORT].",""," The output ciphertext, C, of the AEAD is transmitted in place of P.",""," Some AEAD functions have limits for how many packets can be encrypted"," under the same key and IV; see Section 6.6. This might be lower than",[[[],0," the packet number limit. "],[[607,2010],240,"An endpoint MUST initiate a key update"]],[[[],0," "],[[607,2010],240,"(Section 6) prior to exceeding any limit set for the AEAD that is in"]],[[[],0," "],[[607,2010],240,"use."]]],"requirements":[605,606,607]},{"id":"section-5.4","title":"Header Protection","lines":[" Parts of QUIC packet headers, in particular the Packet Number field,"," are protected using a key that is derived separately from the packet"," protection key and IV. The key derived using the \"quic hp\" label is"," used to provide confidentiality protection for those fields that are"," not exposed to on-path elements.",""," This protection applies to the least significant bits of the first"," byte, plus the Packet Number field. The four least significant bits"," of the first byte are protected for packets with long headers; the"," five least significant bits of the first byte are protected for"," packets with short headers. For both header forms, this covers the"," reserved bits and the Packet Number Length field; the Key Phase bit"," is also protected for packets with a short header.",""," The same header protection key is used for the duration of the"," connection, with the value not changing after a key update (see"," Section 6). This allows header protection to be used to protect the"," key phase.",""," This process does not apply to Retry or Version Negotiation packets,"," which do not contain a protected payload or any of the fields that"," are protected by this process."]},{"id":"section-5.4.1","title":"Header Protection Application","lines":[" Header protection is applied after packet protection is applied (see"," Section 5.3). The ciphertext of the packet is sampled and used as"," input to an encryption algorithm. The algorithm used depends on the"," negotiated AEAD.",""," The output of this algorithm is a 5-byte mask that is applied to the"," protected header fields using exclusive OR. The least significant"," bits of the first byte of the packet are masked by the least"," significant bits of the first mask byte, and the packet number is"," masked with the remaining bytes. Any unused bytes of mask that might"," result from a shorter packet number encoding are unused.",""," Figure 6 shows a sample algorithm for applying header protection."," Removing header protection only differs in the order in which the"," packet number length (pn_length) is determined (here \"^\" is used to"," represent exclusive OR).",""," mask = header_protection(hp_key, sample)",""," pn_length = (packet[0] & 0x03) + 1"," if (packet[0] & 0x80) == 0x80:"," # Long header: 4 bits masked"," packet[0] ^= mask[0] & 0x0f"," else:"," # Short header: 5 bits masked"," packet[0] ^= mask[0] & 0x1f",""," # pn_offset is the start of the Packet Number field."," packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]",""," Figure 6: Header Protection Pseudocode",""," Specific header protection functions are defined based on the"," selected cipher suite; see Section 5.4.3 and Section 5.4.4.",""," Figure 7 shows an example long header packet (Initial) and a short"," header packet (1-RTT). Figure 7 shows the fields in each header that"," are covered by header protection and the portion of the protected"," packet payload that is sampled.",""," Initial Packet {"," Header Form (1) = 1,"," Fixed Bit (1) = 1,"," Long Packet Type (2) = 0,"," Reserved Bits (2), # Protected"," Packet Number Length (2), # Protected"," Version (32),"," DCID Len (8),"," Destination Connection ID (0..160),"," SCID Len (8),"," Source Connection ID (0..160),"," Token Length (i),"," Token (..),"," Length (i),"," Packet Number (8..32), # Protected"," Protected Payload (0..24), # Skipped Part"," Protected Payload (128), # Sampled Part"," Protected Payload (..) # Remainder"," }",""," 1-RTT Packet {"," Header Form (1) = 0,"," Fixed Bit (1) = 1,"," Spin Bit (1),"," Reserved Bits (2), # Protected"," Key Phase (1), # Protected"," Packet Number Length (2), # Protected"," Destination Connection ID (0..160),"," Packet Number (8..32), # Protected"," Protected Payload (0..24), # Skipped Part"," Protected Payload (128), # Sampled Part"," Protected Payload (..), # Remainder"," }",""," Figure 7: Header Protection and Ciphertext Sample","",[[[],0," "],[[608,2375],240,"Before a TLS cipher suite can be used with QUIC, a header protection"]],[[[],0," "],[[608,2375],240,"algorithm MUST be specified for the AEAD used with that cipher suite."]]," This document defines algorithms for AEAD_AES_128_GCM,"," AEAD_AES_128_CCM, AEAD_AES_256_GCM (all these AES AEADs are defined"," in [AEAD]), and AEAD_CHACHA20_POLY1305 (defined in [CHACHA]). Prior"," to TLS selecting a cipher suite, AES header protection is used"," (Section 5.4.3), matching the AEAD_AES_128_GCM packet protection."],"requirements":[608]},{"id":"section-5.4.2","title":"Header Protection Sample","lines":[" The header protection algorithm uses both the header protection key"," and a sample of the ciphertext from the packet Payload field.",""," The same number of bytes are always sampled, but an allowance needs"," to be made for the removal of protection by a receiving endpoint,"," which will not know the length of the Packet Number field. The"," sample of ciphertext is taken starting from an offset of 4 bytes"," after the start of the Packet Number field. That is, in sampling"," packet ciphertext for header protection, the Packet Number field is"," assumed to be 4 bytes long (its maximum possible encoded length).","",[[[],0," "],[[609,3018,3019],228,"An endpoint MUST discard packets that are not long enough to contain"]],[[[],0," "],[[609,3018,3019],228,"a complete sample."]],""," To ensure that sufficient data is available for sampling, packets are"," padded so that the combined lengths of the encoded packet number and"," protected payload is at least 4 bytes longer than the sample required"," for header protection. The cipher suites defined in [TLS13] -- other"," than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme"," is not defined in this document -- have 16-byte expansions and"," 16-byte header protection samples. This results in needing at least"," 3 bytes of frames in the unprotected payload if the packet number is"," encoded on a single byte, or 2 bytes of frames for a 2-byte packet"," number encoding.",""," The sampled ciphertext can be determined by the following pseudocode:",""," # pn_offset is the start of the Packet Number field."," sample_offset = pn_offset + 4",""," sample = packet[sample_offset..sample_offset+sample_length]",""," Where the packet number offset of a short header packet can be"," calculated as:",""," pn_offset = 1 + len(connection_id)",""," And the packet number offset of a long header packet can be"," calculated as:",""," pn_offset = 7 + len(destination_connection_id) +"," len(source_connection_id) +"," len(payload_length)"," if packet_type == Initial:"," pn_offset += len(token_length) +"," len(token)",""," For example, for a packet with a short header, an 8-byte connection"," ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to"," 28 inclusive (using zero-based indexing).",""," Multiple QUIC packets might be included in the same UDP datagram."," Each packet is handled separately."],"requirements":[609]},{"id":"section-5.4.3","title":"AES-Based Header Protection","lines":[" This section defines the packet protection algorithm for"," AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM."," AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES in Electronic"," Codebook (ECB) mode. AEAD_AES_256_GCM uses 256-bit AES in ECB mode."," AES is defined in [AES].",""," This algorithm samples 16 bytes from the packet ciphertext. This"," value is used as the input to AES-ECB. In pseudocode, the header"," protection function is defined as:",""," header_protection(hp_key, sample):"," mask = AES-ECB(hp_key, sample)"]},{"id":"section-5.4.4","title":"ChaCha20-Based Header Protection","lines":[" When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw"," ChaCha20 function as defined in Section 2.4 of [CHACHA]. This uses a"," 256-bit key and 16 bytes sampled from the packet protection output.",""," The first 4 bytes of the sampled ciphertext are the block counter. A"," ChaCha20 implementation could take a 32-bit integer in place of a"," byte sequence, in which case, the byte sequence is interpreted as a"," little-endian value.",""," The remaining 12 bytes are used as the nonce. A ChaCha20"," implementation might take an array of three 32-bit integers in place"," of a byte sequence, in which case, the nonce bytes are interpreted as"," a sequence of 32-bit little-endian integers.",""," The encryption mask is produced by invoking ChaCha20 to protect 5"," zero bytes. In pseudocode, the header protection function is defined"," as:",""," header_protection(hp_key, sample):"," counter = sample[0..3]"," nonce = sample[4..15]"," mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})"]},{"id":"section-5.5","title":"Receiving Protected Packets","lines":[[[[],0," "],[[610,1866],240,"Once an endpoint successfully receives a packet with a given packet"]],[[[],0," "],[[610,1866],240,"number, it MUST discard all packets in the same packet number space"]],[[[],0," "],[[610,1866],240,"with higher packet numbers if they cannot be successfully unprotected"]],[[[],0," "],[[610,1866],240,"with either the same key, or -- if there is a key update -- a"]],[[[],0," "],[[610,1866],240,"subsequent packet protection key; see Section 6."],[[],0," "],[[611,1880],240,"Similarly, a packet"]],[[[],0," "],[[611,1880],240,"that appears to trigger a key update but cannot be unprotected"]],[[[],0," "],[[611,1880],240,"successfully MUST be discarded."]],""," Failure to unprotect a packet does not necessarily indicate the"," existence of a protocol error in a peer or an attack. The truncated"," packet number encoding used in QUIC can cause packet numbers to be"," decoded incorrectly if they are delayed significantly."],"requirements":[610,611]},{"id":"section-5.6","title":"Use of 0-RTT Keys","lines":[" If 0-RTT keys are available (see Section 4.6.1), the lack of replay"," protection means that restrictions on their use are necessary to"," avoid replay attacks on the protocol.",""," Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM,"," STOP_SENDING, and CONNECTION_CLOSE frames are potentially unsafe for"," use with 0-RTT as they carry application data. Application data that"," is received in 0-RTT could cause an application at the server to"," process the data multiple times rather than just once. Additional"," actions taken by a server as a result of processing replayed",[[[],0," application data could have unwanted consequences. "],[[612,1897,2195],240,"A client"]],[[[],0," "],[[612,1897,2195],240,"therefore MUST NOT use 0-RTT for application data unless specifically"]],[[[],0," "],[[612,1897,2195],240,"requested by the application that is in use."]],"",[[[],0," "],[[613,1192],225,"An application protocol that uses QUIC MUST include a profile that"]],[[[],0," "],[[613,1192],225,"defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to"]],[[[],0," "],[[613,1192],225,"carry QUIC frames that do not carry application data."],[[],0," For example, a"]]," profile for HTTP is described in [HTTP-REPLAY] and used for HTTP/3;"," see Section 10.9 of [QUIC-HTTP].",""," Though replaying packets might result in additional connection"," attempts, the effect of processing replayed frames that do not carry"," application data is limited to changing the state of the affected"," connection. A TLS handshake cannot be successfully completed using"," replayed packets.","",[[[],0," "],[[614,1193],97,"A client MAY wish to apply additional restrictions on what data it"]],[[[],0," "],[[614,1193],97,"sends prior to the completion of the TLS handshake."]],""," A client otherwise treats 0-RTT keys as equivalent to 1-RTT keys,"," except that it cannot send certain frames with 0-RTT keys; see"," Section 12.5 of [QUIC-TRANSPORT].",""," A client that receives an indication that its 0-RTT data has been"," accepted by a server can send 0-RTT data until it receives all of the",[[[],0," server's handshake messages. "],[[615,1194],161,"A client SHOULD stop sending 0-RTT data"]],[[[],0," "],[[615,1194],161,"if it receives an indication that 0-RTT data has been rejected."]],"",[[[],0," "],[[616,1898],240,"A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT"]],[[[],0," "],[[616,1898],240,"keys to protect acknowledgments of 0-RTT packets."],[[],0," "],[[617,1162],225,"A client MUST NOT"]],[[[],0," "],[[617,1162],225,"attempt to decrypt 0-RTT packets it receives and instead MUST discard"]],[[[],0," "],[[617,1162],225,"them."]],"",[[[],0," "],[[618,1899,2084],240,"Once a client has installed 1-RTT keys, it MUST NOT send any more"]],[[[],0," "],[[618,1899,2084],240,"0-RTT packets."]],""," | Note: 0-RTT data can be acknowledged by the server as it"," | receives it, but any packets containing acknowledgments of"," | 0-RTT data cannot have packet protection removed by the client"," | until the TLS handshake is complete. The 1-RTT keys necessary"," | to remove packet protection cannot be derived until the client"," | receives all server handshake messages."],"requirements":[612,613,614,615,616,617,618]},{"id":"section-5.7","title":"Receiving Out-of-Order Protected Packets","lines":[" Due to reordering and loss, protected packets might be received by an"," endpoint before the final TLS handshake messages are received. A"," client will be unable to decrypt 1-RTT packets from the server,"," whereas a server will be able to decrypt 1-RTT packets from the",[[[],0," client. "],[[619,1163],225,"Endpoints in either role MUST NOT decrypt 1-RTT packets from"]],[[[],0," "],[[619,1163],225,"their peer prior to completing the handshake."]],""," Even though 1-RTT keys are available to a server after receiving the"," first handshake messages from a client, it is missing assurances on"," the client state:",""," * The client is not authenticated, unless the server has chosen to"," use a pre-shared key and validated the client's pre-shared key"," binder; see Section 4.2.11 of [TLS13].",""," * The client has not demonstrated liveness, unless the server has"," validated the client's address with a Retry packet or other means;"," see Section 8.1 of [QUIC-TRANSPORT].",""," * Any received 0-RTT data that the server responds to might be due"," to a replay attack.",""," Therefore, the server's use of 1-RTT keys before the handshake is",[[[],0," complete is limited to sending data. "],[[620,1874,1876,1878,1895],240,"A server MUST NOT process"]],[[[],0," "],[[620,1874,1876,1878,1895],240,"incoming 1-RTT protected packets before the TLS handshake is"]],[[[],0," "],[[620,1874,1876,1878,1895],240,"complete."],[[],0," Because sending acknowledgments indicates that all frames"]]," in a packet have been processed, a server cannot send acknowledgments",[[[],0," for 1-RTT packets until the TLS handshake is complete. "],[[621,1875,1877,1879,1896],112,"Received"]],[[[],0," "],[[621,1875,1877,1879,1896],112,"packets protected with 1-RTT keys MAY be stored and later decrypted"]],[[[],0," "],[[621,1875,1877,1879,1896],112,"and used once the handshake is complete."]],""," | Note: TLS implementations might provide all 1-RTT secrets prior"," | to handshake completion. Even where QUIC implementations have"," | 1-RTT read keys, those keys are not to be used prior to"," | completing the handshake.",""," The requirement for the server to wait for the client Finished"," message creates a dependency on that message being delivered. A"," client can avoid the potential for head-of-line blocking that this"," implies by sending its 1-RTT packets coalesced with a Handshake"," packet containing a copy of the CRYPTO frame that carries the"," Finished message, until one of the Handshake packets is acknowledged."," This enables immediate server processing for those packets.",""," A server could receive packets protected with 0-RTT keys prior to",[[[],0," receiving a TLS ClientHello. "],[[622,1164],97,"The server MAY retain these packets for"]],[[[],0," "],[[622,1164],97,"later decryption in anticipation of receiving a ClientHello."]],""," A client generally receives 1-RTT keys at the same time as the",[[[],0," handshake completes. "],[[623,1165],225,"Even if it has 1-RTT secrets, a client MUST NOT"]],[[[],0," "],[[623,1165],225,"process incoming 1-RTT protected packets before the TLS handshake is"]],[[[],0," "],[[623,1165],225,"complete."]]],"requirements":[619,620,621,622,623]},{"id":"section-5.8","title":"Retry Packet Integrity","lines":[" Retry packets (see Section 17.2.5 of [QUIC-TRANSPORT]) carry a Retry"," Integrity Tag that provides two properties: it allows the discarding"," of packets that have accidentally been corrupted by the network, and"," only an entity that observes an Initial packet can send a valid Retry"," packet.",""," The Retry Integrity Tag is a 128-bit field that is computed as the"," output of AEAD_AES_128_GCM [AEAD] used with the following inputs:",""," * The secret key, K, is 128 bits equal to"," 0xbe0c690b9f66575a1d766b54e368c84e.",""," * The nonce, N, is 96 bits equal to 0x461599d35d632bf2239825bb.",""," * The plaintext, P, is empty.",""," * The associated data, A, is the contents of the Retry Pseudo-"," Packet, as illustrated in Figure 8:",""," The secret key and the nonce are values derived by calling HKDF-"," Expand-Label using"," 0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as"," the secret, with labels being \"quic key\" and \"quic iv\" (Section 5.1).",""," Retry Pseudo-Packet {"," ODCID Length (8),"," Original Destination Connection ID (0..160),"," Header Form (1) = 1,"," Fixed Bit (1) = 1,"," Long Packet Type (2) = 3,"," Unused (4),"," Version (32),"," DCID Len (8),"," Destination Connection ID (0..160),"," SCID Len (8),"," Source Connection ID (0..160),"," Retry Token (..),"," }",""," Figure 8: Retry Pseudo-Packet",""," The Retry Pseudo-Packet is not sent over the wire. It is computed by"," taking the transmitted Retry packet, removing the Retry Integrity"," Tag, and prepending the two following fields:",""," ODCID Length: The ODCID Length field contains the length in bytes of"," the Original Destination Connection ID field that follows it,"," encoded as an 8-bit unsigned integer.",""," Original Destination Connection ID: The Original Destination"," Connection ID contains the value of the Destination Connection ID"," from the Initial packet that this Retry is in response to. The"," length of this field is given in ODCID Length. The presence of"," this field ensures that a valid Retry packet can only be sent by"," an entity that observes the Initial packet."]},{"id":"section-6","title":"Key Update","lines":[[[[],0," "],[[655,1745],112,"Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY"]],[[[],0," "],[[655,1745],112,"initiate a key update."]],""," The Key Phase bit indicates which packet protection keys are used to"," protect the packet. The Key Phase bit is initially set to 0 for the"," first set of 1-RTT packets and toggled to signal each subsequent key"," update.",""," The Key Phase bit allows a recipient to detect a change in keying"," material without needing to receive the first packet that triggered"," the change. An endpoint that notices a changed Key Phase bit updates"," keys and decrypts the packet that contains the changed value.",""," Initiating a key update results in both endpoints updating keys."," This differs from TLS where endpoints can update keys independently.",""," This mechanism replaces the key update mechanism of TLS, which relies",[[[],0," on KeyUpdate messages sent using 1-RTT encryption keys. "],[[656,1180],225,"Endpoints"]],[[[],0," "],[[656,1180],225,"MUST NOT send a TLS KeyUpdate message."],[[],0," "],[[657,1181],225,"Endpoints MUST treat the"]],[[[],0," "],[[657,1181],225,"receipt of a TLS KeyUpdate message as a connection error of type"]],[[[],0," "],[[657,1181],225,"0x010a, equivalent to a fatal TLS alert of unexpected_message; see"]],[[[],0," "],[[657,1181],225,"Section 4.8."]],""," Figure 9 shows a key update process, where the initial set of keys"," used (identified with @M) are replaced by updated keys (identified"," with @N). The value of the Key Phase bit is indicated in brackets"," [].",""," Initiating Peer Responding Peer",""," @M [0] QUIC Packets",""," ... Update to @N"," @N [1] QUIC Packets"," -------->"," Update to @N ..."," QUIC Packets [1] @N"," <--------"," QUIC Packets [1] @N"," containing ACK"," <--------"," ... Key Update Permitted",""," @N [1] QUIC Packets"," containing ACK for @N packets"," -------->"," Key Update Permitted ...",""," Figure 9: Key Update"],"requirements":[655,656,657]},{"id":"section-6.1","title":"Initiating a Key Update","lines":[" Endpoints maintain separate read and write secrets for packet"," protection. An endpoint initiates a key update by updating its"," packet protection write secret and using that to protect new packets."," The endpoint creates a new write secret from the existing write"," secret as performed in Section 7.2 of [TLS13]. This uses the KDF"," function provided by TLS with a label of \"quic ku\". The"," corresponding key and IV are created from that secret as defined in"," Section 5.1. The header protection key is not updated.",""," For example, to update write keys with TLS 1.3, HKDF-Expand-Label is"," used as:",""," secret_ = HKDF-Expand-Label(secret_, \"quic ku\","," \"\", Hash.length)",""," The endpoint toggles the value of the Key Phase bit and uses the"," updated key and IV to protect all subsequent packets.","",[[[],0," "],[[624,2129],240,"An endpoint MUST NOT initiate a key update prior to having confirmed"]],[[[],0," "],[[624,2129],240,"the handshake (Section 4.1.2)."],[[],0," "],[[625,2130],240,"An endpoint MUST NOT initiate a"]],[[[],0," "],[[625,2130],240,"subsequent key update unless it has received an acknowledgment for a"]],[[[],0," "],[[625,2130],240,"packet that was sent protected with keys from the current key phase."]]," This ensures that keys are available to both peers before another key"," update can be initiated. This can be implemented by tracking the"," lowest packet number sent with each key phase and the highest"," acknowledged packet number in the 1-RTT space: once the latter is"," higher than or equal to the former, another key update can be"," initiated.",""," | Note: Keys of packets other than the 1-RTT packets are never"," | updated; their keys are derived solely from the TLS handshake"," | state.",""," The endpoint that initiates a key update also updates the keys that"," it uses for receiving packets. These keys will be needed to process"," packets the peer sends after updating.","",[[[],0," "],[[626,1699,1711],240,"An endpoint MUST retain old keys until it has successfully"]],[[[],0," "],[[626,1699,1711],240,"unprotected a packet sent using the new keys."],[[],0," "],[[627,2187],176,"An endpoint SHOULD"]],[[[],0," "],[[627,2187],176,"retain old keys for some time after unprotecting a packet sent using"]],[[[],0," "],[[627,2187],176,"the new keys."],[[],0," Discarding old keys too early can cause delayed"]]," packets to be discarded. Discarding packets will be interpreted as"," packet loss by the peer and could adversely affect performance."],"requirements":[624,625,626,627]},{"id":"section-6.2","title":"Responding to a Key Update","lines":[" A peer is permitted to initiate a key update after receiving an"," acknowledgment of a packet in the current key phase. An endpoint"," detects a key update when processing a packet with a key phase that"," differs from the value used to protect the last packet it sent. To"," process this packet, the endpoint uses the next packet protection key"," and IV. See Section 6.3 for considerations about generating these"," keys.",""," If a packet is successfully processed using the next key and IV, then",[[[],0," the peer has initiated a key update. "],[[628,1700,1712],240,"The endpoint MUST update its"]],[[[],0," "],[[628,1700,1712],240,"send keys to the corresponding key phase in response, as described in"]],[[[],0," "],[[628,1700,1712],240,"Section 6.1."],[[],0," "],[[629,1701,1713],240,"Sending keys MUST be updated before sending an"]],[[[],0," "],[[629,1701,1713],240,"acknowledgment for the packet that was received with updated keys."]]," By acknowledging the packet that triggered the key update in a packet"," protected with the updated keys, the endpoint signals that the key"," update is complete.",""," An endpoint can defer sending the packet or acknowledgment according"," to its normal packet sending behavior; it is not necessary to"," immediately generate a packet in response to a key update. The next"," packet sent by the endpoint will use the updated keys. The next"," packet that contains an acknowledgment will cause the key update to"," be completed. If an endpoint detects a second update before it has"," sent any packets with updated keys containing an acknowledgment for"," the packet that initiated the key update, it indicates that its peer",[[[],0," has updated keys twice without awaiting confirmation. "],[[630,1860],112,"An endpoint"]],[[[],0," "],[[630,1860],112,"MAY treat such consecutive key updates as a connection error of type"]],[[[],0," "],[[630,1860],112,"KEY_UPDATE_ERROR."]],"",[[[],0," "],[[631,1782,1861],112,"An endpoint that receives an acknowledgment that is carried in a"]],[[[],0," "],[[631,1782,1861],112,"packet protected with old keys where any acknowledged packet was"]],[[[],0," "],[[631,1782,1861],112,"protected with newer keys MAY treat that as a connection error of"]],[[[],0," "],[[631,1782,1861],112,"type KEY_UPDATE_ERROR."],[[],0," This indicates that a peer has received and"]]," acknowledged a packet that initiates a key update, but has not"," updated keys in response."],"requirements":[628,629,630,631]},{"id":"section-6.3","title":"Timing of Receive Key Generation","lines":[[[[],0," "],[[632,1166],225,"Endpoints responding to an apparent key update MUST NOT generate a"]],[[[],0," "],[[632,1166],225,"timing side-channel signal that might indicate that the Key Phase bit"]],[[[],0," "],[[632,1166],225,"was invalid (see Section 9.5)."],[[],0," Endpoints can use randomized packet"]]," protection keys in place of discarded keys when key updates are not"," yet permitted. Using randomized keys ensures that attempting to"," remove packet protection does not result in timing variations, and"," results in packets with an invalid Key Phase bit being rejected.",""," The process of creating new packet protection keys for receiving",[[[],0," packets could reveal that a key update has occurred. "],[[633,2190],112,"An endpoint MAY"]],[[[],0," "],[[633,2190],112,"generate new keys as part of packet processing, but this creates a"]],[[[],0," "],[[633,2190],112,"timing signal that could be used by an attacker to learn when key"]],[[[],0," "],[[633,2190],112,"updates happen and thus leak the value of the Key Phase bit."]],""," Endpoints are generally expected to have current and next receive",[[[],0," packet protection keys available. "],[[634,1167],97,"For a short period after a key"]],[[[],0," "],[[634,1167],97,"update completes, up to the PTO, endpoints MAY defer generation of"]],[[[],0," "],[[634,1167],97,"the next set of receive packet protection keys."],[[],0," This allows"]]," endpoints to retain only two sets of receive keys; see Section 6.5.","",[[[],0," "],[[635,1698,1710],176,"Once generated, the next set of packet protection keys SHOULD be"]],[[[],0," "],[[635,1698,1710],176,"retained, even if the packet that was received was subsequently"]],[[[],0," "],[[635,1698,1710],176,"discarded."],[[],0," Packets containing apparent key updates are easy to"]]," forge, and while the process of key update does not require"," significant effort, triggering this process could be used by an"," attacker for DoS.","",[[[],0," "],[[636,1697,1709,2191],240,"For this reason, endpoints MUST be able to retain two sets of packet"]],[[[],0," "],[[636,1697,1709,2191],240,"protection keys for receiving packets: the current and the next."]]," Retaining the previous keys in addition to these might improve"," performance, but this is not essential."],"requirements":[632,633,634,635,636]},{"id":"section-6.4","title":"Sending with Updated Keys","lines":[" An endpoint never sends packets that are protected with old keys."," Only the current keys are used. Keys used for protecting packets can"," be discarded immediately after switching to newer keys.","",[[[],0," "],[[637,1168],225,"Packets with higher packet numbers MUST be protected with either the"]],[[[],0," "],[[637,1168],225,"same or newer packet protection keys than packets with lower packet"]],[[[],0," "],[[637,1168],225,"numbers."],[[],0," "],[[638,1169],225,"An endpoint that successfully removes protection with old"]],[[[],0," "],[[638,1169],225,"keys when newer keys were used for packets with lower packet numbers"]],[[[],0," "],[[638,1169],225,"MUST treat this as a connection error of type KEY_UPDATE_ERROR."]]],"requirements":[637,638]},{"id":"section-6.5","title":"Receiving with Different Keys","lines":[" For receiving packets during a key update, packets protected with"," older keys might arrive if they were delayed by the network."," Retaining old packet protection keys allows these packets to be"," successfully processed.",""," As packets protected with keys from the next key phase use the same"," Key Phase value as those protected with keys from the previous key"," phase, it is necessary to distinguish between the two if packets"," protected with old keys are to be processed. This can be done using"," packet numbers. A recovered packet number that is lower than any"," packet number from the current key phase uses the previous packet"," protection keys; a recovered packet number that is higher than any"," packet number from the current key phase requires the use of the next"," packet protection keys.",""," Some care is necessary to ensure that any process for selecting"," between previous, current, and next packet protection keys does not"," expose a timing side channel that might reveal which keys were used"," to remove packet protection. See Section 9.5 for more information.",""," Alternatively, endpoints can retain only two sets of packet"," protection keys, swapping previous for next after enough time has"," passed to allow for reordering in the network. In this case, the Key"," Phase bit alone can be used to select keys.","",[[[],0," "],[[639,1170],97,"An endpoint MAY allow a period of approximately the Probe Timeout"]],[[[],0," "],[[639,1170],97,"(PTO; see [QUIC-RECOVERY]) after promoting the next set of receive"]],[[[],0," "],[[639,1170],97,"keys to be current before it creates the subsequent set of packet"]],[[[],0," "],[[639,1170],97,"protection keys."],[[],0," "],[[640,1171],97,"These updated keys MAY replace the previous keys at"]],[[[],0," "],[[640,1171],97,"that time."],[[],0," With the caveat that PTO is a subjective measure -- that"]]," is, a peer could have a different view of the RTT -- this time is"," expected to be long enough that any reordered packets would be"," declared lost by a peer even if they were acknowledged and short"," enough to allow a peer to initiate further key updates.",""," Endpoints need to allow for the possibility that a peer might not be"," able to decrypt packets that initiate a key update during the period",[[[],0," when the peer retains old keys. "],[[641,2188],176,"Endpoints SHOULD wait three times"]],[[[],0," "],[[641,2188],176,"the PTO before initiating a key update after receiving an"]],[[[],0," "],[[641,2188],176,"acknowledgment that confirms that the previous key update was"]],[[[],0," "],[[641,2188],176,"received."],[[],0," Failing to allow sufficient time could lead to packets"]]," being discarded.","",[[[],0," "],[[642,2189],176,"An endpoint SHOULD retain old read keys for no more than three times"]],[[[],0," "],[[642,2189],176,"the PTO after having received a packet protected using the new keys."]],[[[],0," "],[[643,2193],176,"After this period, old read keys and their corresponding secrets"]],[[[],0," "],[[643,2193],176,"SHOULD be discarded."]]],"requirements":[639,640,641,642,643]},{"id":"section-6.6","title":"Limits on AEAD Usage","lines":[" This document sets usage limits for AEAD algorithms to ensure that"," overuse does not give an adversary a disproportionate advantage in"," attacking the confidentiality and integrity of communications when"," using QUIC.",""," The usage limits defined in TLS 1.3 exist for protection against"," attacks on confidentiality and apply to successful applications of"," AEAD protection. The integrity protections in authenticated"," encryption also depend on limiting the number of attempts to forge"," packets. TLS achieves this by closing connections after any record"," fails an authentication check. In comparison, QUIC ignores any"," packet that cannot be authenticated, allowing multiple forgery"," attempts.",""," QUIC accounts for AEAD confidentiality and integrity limits"," separately. The confidentiality limit applies to the number of"," packets encrypted with a given key. The integrity limit applies to"," the number of packets decrypted within a given connection. Details"," on enforcing these limits for each AEAD algorithm follow below.","",[[[],0," "],[[644,2009,2131],240,"Endpoints MUST count the number of encrypted packets for each set of"]],[[[],0," "],[[644,2009,2131],240,"keys."],[[],0," "],[[645,2006],240,"If the total number of encrypted packets with the same key"]],[[[],0," "],[[645,2006],240,"exceeds the confidentiality limit for the selected AEAD, the endpoint"]],[[[],0," "],[[645,2006],240,"MUST stop using those keys."],[[],0," "],[[646,2011],240,"Endpoints MUST initiate a key update"]],[[[],0," "],[[646,2011],240,"before sending more protected packets than the confidentiality limit"]],[[[],0," "],[[646,2011],240,"for the selected AEAD permits."],[[],0," "],[[647,1862,2007],240,"If a key update is not possible or"]],[[[],0," "],[[647,1862,2007],240,"integrity limits are reached, the endpoint MUST stop using the"]],[[[],0," "],[[647,1862,2007],240,"connection and only send stateless resets in response to receiving"]],[[[],0," "],[[647,1862,2007],240,"packets."],[[],0," "],[[648,1863,2008],176,"It is RECOMMENDED that endpoints immediately close the"]],[[[],0," "],[[648,1863,2008],176,"connection with a connection error of type AEAD_LIMIT_REACHED before"]],[[[],0," "],[[648,1863,2008],176,"reaching a state where key updates are not possible."]],""," For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit"," is 2^23 encrypted packets; see Appendix B.1. For"," AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the"," number of possible packets (2^62) and so can be disregarded. For"," AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted"," packets; see Appendix B.2. Applying a limit reduces the probability"," that an attacker can distinguish the AEAD in use from a random"," permutation; see [AEBounds], [ROBUST], and [GCM-MU].","",[[[],0," "],[[649,2012],240,"In addition to counting packets sent, endpoints MUST count the number"]],[[[],0," "],[[649,2012],240,"of received packets that fail authentication during the lifetime of a"]],[[[],0," "],[[649,2012],240,"connection."],[[],0," "],[[650,2013],240,"If the total number of received packets that fail"]],[[[],0," "],[[650,2013],240,"authentication within the connection, across all keys, exceeds the"]],[[[],0," "],[[650,2013],240,"integrity limit for the selected AEAD, the endpoint MUST immediately"]],[[[],0," "],[[650,2013],240,"close the connection with a connection error of type"]],[[[],0," "],[[650,2013],240,"AEAD_LIMIT_REACHED and not process any more packets."]],""," For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is"," 2^52 invalid packets; see Appendix B.1. For AEAD_CHACHA20_POLY1305,"," the integrity limit is 2^36 invalid packets; see [AEBounds]. For"," AEAD_AES_128_CCM, the integrity limit is 2^21.5 invalid packets; see"," Appendix B.2. Applying this limit reduces the probability that an"," attacker can successfully forge a packet; see [AEBounds], [ROBUST],"," and [GCM-MU].","",[[[],0," "],[[651,1172],97,"Endpoints that limit the size of packets MAY use higher"]],[[[],0," "],[[651,1172],97,"confidentiality and integrity limits; see Appendix B for details."]],"",[[[],0," "],[[652,1173],97,"Future analyses and specifications MAY relax confidentiality or"]],[[[],0," "],[[652,1173],97,"integrity limits for an AEAD."]],"",[[[],0," "],[[653,1881,1883],240,"Any TLS cipher suite that is specified for use with QUIC MUST define"]],[[[],0," "],[[653,1881,1883],240,"limits on the use of the associated AEAD function that preserves"]],[[[],0," "],[[653,1881,1883],240,"margins for confidentiality and integrity."],[[],0," "],[[654,1882,1884],240,"That is, limits MUST be"]],[[[],0," "],[[654,1882,1884],240,"specified for the number of packets that can be authenticated and for"]],[[[],0," "],[[654,1882,1884],240,"the number of packets that can fail authentication."],[[],0," Providing a"]]," reference to any analysis upon which values are based -- and any"," assumptions used in that analysis -- allows limits to be adapted to"," varying usage conditions."],"requirements":[644,645,646,647,648,649,650,651,652,653,654]},{"id":"section-6.7","title":"Key Update Error Code","lines":[" The KEY_UPDATE_ERROR error code (0x0e) is used to signal errors"," related to key updates."]},{"id":"section-7","title":"Security of Initial Messages","lines":[" Initial packets are not protected with a secret key, so they are"," subject to potential tampering by an attacker. QUIC provides"," protection against attackers that cannot read packets but does not"," attempt to provide additional protection against attacks where the"," attacker can observe and inject packets. Some forms of tampering --"," such as modifying the TLS messages themselves -- are detectable, but"," some -- such as modifying ACKs -- are not.",""," For example, an attacker could inject a packet containing an ACK"," frame to make it appear that a packet had not been received or to"," create a false impression of the state of the connection (e.g., by"," modifying the ACK Delay). Note that such a packet could cause a",[[[],0," legitimate packet to be dropped as a duplicate. "],[[658,1158],161,"Implementations"]],[[[],0," "],[[658,1158],161,"SHOULD use caution in relying on any data that is contained in"]],[[[],0," "],[[658,1158],161,"Initial packets that is not otherwise authenticated."]],""," It is also possible for the attacker to tamper with data that is"," carried in Handshake packets, but because that sort of tampering"," requires modifying TLS handshake messages, any such tampering will"," cause the TLS handshake to fail."],"requirements":[658]},{"id":"section-8","title":"QUIC-Specific Adjustments to the TLS Handshake","lines":[" Certain aspects of the TLS handshake are different when used with"," QUIC.",""," QUIC also requires additional features from TLS. In addition to"," negotiation of cryptographic parameters, the TLS handshake carries"," and authenticates values for QUIC transport parameters."]},{"id":"section-8.1","title":"Protocol Negotiation","lines":[" QUIC requires that the cryptographic handshake provide authenticated"," protocol negotiation. TLS uses Application-Layer Protocol",[[[],0," Negotiation [ALPN] to select an application protocol. "],[[659,2386,2395],240,"Unless another"]],[[[],0," "],[[659,2386,2395],240,"mechanism is used for agreeing on an application protocol, endpoints"]],[[[],0," "],[[659,2386,2395],240,"MUST use ALPN for this purpose."]],"",[[[],0," "],[[660,2388],240,"When using ALPN, endpoints MUST immediately close a connection (see"]],[[[],0," "],[[660,2388],240,"Section 10.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS"]],[[[],0," "],[[660,2388],240,"alert (QUIC error code 0x0178; see Section 4.8) if an application"]],[[[],0," "],[[660,2388],240,"protocol is not negotiated."],[[],0," "],[[661,1143],225,"While [ALPN] only specifies that servers"]],[[[],0," "],[[661,1143],225,"use this alert, QUIC clients MUST use error 0x0178 to terminate a"]],[[[],0," "],[[661,1143],225,"connection when ALPN negotiation fails."]],"",[[[],0," "],[[662,1144],97,"An application protocol MAY restrict the QUIC versions that it can"]],[[[],0," "],[[662,1144],97,"operate over."],[[],0," "],[[663,2391],240,"Servers MUST select an application protocol compatible"]],[[[],0," "],[[663,2391],240,"with the QUIC version that the client has selected."],[[],0," "],[[664,2389],240,"The server MUST"]],[[[],0," "],[[664,2389],240,"treat the inability to select a compatible application protocol as a"]],[[[],0," "],[[664,2389],240,"connection error of type 0x0178 (no_application_protocol)."]],[[[],0," "],[[665,1145],225,"Similarly, a client MUST treat the selection of an incompatible"]],[[[],0," "],[[665,1145],225,"application protocol by a server as a connection error of type"]],[[[],0," "],[[665,1145],225,"0x0178."]]],"requirements":[659,660,661,662,663,664,665]},{"id":"section-8.2","title":"QUIC Transport Parameters Extension","lines":[" QUIC transport parameters are carried in a TLS extension. Different"," versions of QUIC might define a different method for negotiating"," transport configuration.",""," Including transport parameters in the TLS handshake provides"," integrity protection for these values.",""," enum {"," quic_transport_parameters(0x39), (65535)"," } ExtensionType;",""," The extension_data field of the quic_transport_parameters extension"," contains a value that is defined by the version of QUIC that is in"," use.","",[[[],0," "],[[3143],4,"The quic_transport_parameters extension is carried in the ClientHello"]],[[[],0," "],[[3143],4,"and the EncryptedExtensions messages during the handshake."],[[],0," "],[[666,1916,2384],240,"Endpoints"]],[[[],0," "],[[666,1916,2384],240,"MUST send the quic_transport_parameters extension;"],[[666,1916],240," endpoints that"]],[[[],0," "],[[666,1916],240,"receive ClientHello or EncryptedExtensions messages without the"]],[[[],0," "],[[666,1916],240,"quic_transport_parameters extension MUST close the connection with an"]],[[[],0," "],[[666,1916],240,"error of type 0x016d (equivalent to a fatal TLS missing_extension"]],[[[],0," "],[[666,1916],240,"alert, see Section 4.8)."]],""," Transport parameters become available prior to the completion of the"," handshake. A server might use these values earlier than handshake"," completion. However, the value of transport parameters is not"," authenticated until the handshake completes, so any use of these"," parameters cannot depend on their authenticity. Any tampering with"," transport parameters will cause the handshake to fail.","",[[[],0," "],[[667,2385],240,"Endpoints MUST NOT send this extension in a TLS connection that does"]],[[[],0," "],[[667,2385],240,"not use QUIC (such as the use of TLS with TCP defined in [TLS13])."],[[],0," "],[[],0,"A"]],[[[],0," "],[[668,1182],225,"fatal unsupported_extension alert MUST be sent by an implementation"]],[[[],0," "],[[668,1182],225,"that supports this extension if the extension is received when the"]],[[[],0," "],[[668,1182],225,"transport is not QUIC."]],""," Negotiating the quic_transport_parameters extension causes the"," EndOfEarlyData to be removed; see Section 8.3."],"requirements":[666,667,668]},{"id":"section-8.3","title":"Removing the EndOfEarlyData Message","lines":[" The TLS EndOfEarlyData message is not used with QUIC. QUIC does not"," rely on this message to mark the end of 0-RTT data or to signal the"," change to Handshake keys.","",[[[],0," "],[[669,1183],225,"Clients MUST NOT send the EndOfEarlyData message."],[[],0," "],[[670,1682],240,"A server MUST"]],[[[],0," "],[[670,1682],240,"treat receipt of a CRYPTO frame in a 0-RTT packet as a connection"]],[[[],0," "],[[670,1682],240,"error of type PROTOCOL_VIOLATION."]],""," As a result, EndOfEarlyData does not appear in the TLS handshake"," transcript."],"requirements":[669,670]},{"id":"section-8.4","title":"Prohibit TLS Middlebox Compatibility Mode","lines":[" Appendix D.4 of [TLS13] describes an alteration to the TLS 1.3"," handshake as a workaround for bugs in some middleboxes. The TLS 1.3"," middlebox compatibility mode involves setting the legacy_session_id"," field to a 32-byte value in the ClientHello and ServerHello, then"," sending a change_cipher_spec record. Both field and record carry no"," semantic content and are ignored.",""," This mode has no use in QUIC as it only applies to middleboxes that"," interfere with TLS over TCP. QUIC also provides no means to carry a",[[[],0," change_cipher_spec record. "],[[671,1184],225,"A client MUST NOT request the use of the"]],[[[],0," "],[[671,1184],225,"TLS 1.3 compatibility mode."],[[],0," "],[[672,1185],161,"A server SHOULD treat the receipt of a"]],[[[],0," "],[[672,1185],161,"TLS ClientHello with a non-empty legacy_session_id field as a"]],[[[],0," "],[[672,1185],161,"connection error of type PROTOCOL_VIOLATION."]]],"requirements":[671,672]},{"id":"section-9","title":"Security Considerations","lines":[" All of the security considerations that apply to TLS also apply to"," the use of TLS in QUIC. Reading all of [TLS13] and its appendices is"," the best way to gain an understanding of the security properties of"," QUIC.",""," This section summarizes some of the more important security aspects"," specific to the TLS integration, though there are many security-"," relevant details in the remainder of the document."]},{"id":"section-9.1","title":"Session Linkability","lines":[" Use of TLS session tickets allows servers and possibly other entities"," to correlate connections made by the same client; see Section 4.5 for"," details."]},{"id":"section-9.2","title":"Replay Attacks with 0-RTT","lines":[" As described in Section 8 of [TLS13], use of TLS early data comes"," with an exposure to replay attack. The use of 0-RTT in QUIC is"," similarly vulnerable to replay attack.","",[[[],0," "],[[673,1195],225,"Endpoints MUST implement and use the replay protections described in"]],[[[],0," "],[[673,1195],225,"[TLS13], however it is recognized that these protections are"]],[[[],0," "],[[673,1195],225,"imperfect."],[[],0," Therefore, additional consideration of the risk of replay"]]," is needed.",""," QUIC is not vulnerable to replay attack, except via the application"," protocol information it might carry. The management of QUIC protocol"," state based on the frame types defined in [QUIC-TRANSPORT] is not"," vulnerable to replay. Processing of QUIC frames is idempotent and"," cannot result in invalid connection states if frames are replayed,"," reordered, or lost. QUIC connections do not produce effects that"," last beyond the lifetime of the connection, except for those produced"," by the application protocol that QUIC serves.",""," TLS session tickets and address validation tokens are used to carry"," QUIC configuration information between connections, specifically, to"," enable a server to efficiently recover state that is used in",[[[],0," connection establishment and address validation. "],[[674,1196],225,"These MUST NOT be"]],[[[],0," "],[[674,1196],225,"used to communicate application semantics between endpoints; clients"]],[[[],0," "],[[674,1196],225,"MUST treat them as opaque values."],[[],0," The potential for reuse of these"]]," tokens means that they require stronger protections against replay.",""," A server that accepts 0-RTT on a connection incurs a higher cost than"," accepting a connection without 0-RTT. This includes higher"," processing and computation costs. Servers need to consider the"," probability of replay and all associated costs when accepting 0-RTT.",""," Ultimately, the responsibility for managing the risks of replay",[[[],0," attacks with 0-RTT lies with an application protocol. "],[[675,1197],225,"An application"]],[[[],0," "],[[675,1197],225,"protocol that uses QUIC MUST describe how the protocol uses 0-RTT and"]],[[[],0," "],[[675,1197],225,"the measures that are employed to protect against replay attack."],[[],0," An"]]," analysis of replay risk needs to consider all QUIC protocol features"," that carry application semantics.",""," Disabling 0-RTT entirely is the most effective defense against replay"," attack.","",[[[],0," "],[[676,1198],225,"QUIC extensions MUST either describe how replay attacks affect their"]],[[[],0," "],[[676,1198],225,"operation or prohibit the use of the extension in 0-RTT."],[[],0," "],[[677,1199],225,"Application"]],[[[],0," "],[[677,1199],225,"protocols MUST either prohibit the use of extensions that carry"]],[[[],0," "],[[677,1199],225,"application semantics in 0-RTT or provide replay mitigation"]],[[[],0," "],[[677,1199],225,"strategies."]]],"requirements":[673,674,675,676,677]},{"id":"section-9.3","title":"Packet Reflection Attack Mitigation","lines":[" A small ClientHello that results in a large block of handshake"," messages from a server can be used in packet reflection attacks to"," amplify the traffic generated by an attacker.","",[[[],0," QUIC includes three defenses against this attack. "],[[678,1159],225,"First, the packet"]],[[[],0," "],[[678,1159],225,"containing a ClientHello MUST be padded to a minimum size."],[[],0," Second,"]]," if responding to an unverified source address, the server is"," forbidden to send more than three times as many bytes as the number"," of bytes it has received (see Section 8.1 of [QUIC-TRANSPORT])."," Finally, because acknowledgments of Handshake packets are"," authenticated, a blind attacker cannot forge them. Put together,"," these defenses limit the level of amplification."],"requirements":[678]},{"id":"section-9.4","title":"Header Protection Analysis","lines":[" [NAN] analyzes authenticated encryption algorithms that provide nonce"," privacy, referred to as \"Hide Nonce\" (HN) transforms. The general"," header protection construction in this document is one of those"," algorithms (HN1). Header protection is applied after the packet"," protection AEAD, sampling a set of bytes (\"sample\") from the AEAD"," output and encrypting the header field using a pseudorandom function"," (PRF) as follows:",""," protected_field = field XOR PRF(hp_key, sample)",""," The header protection variants in this document use a pseudorandom"," permutation (PRP) in place of a generic PRF. However, since all PRPs"," are also PRFs [IMC], these variants do not deviate from the HN1"," construction.",""," As \"hp_key\" is distinct from the packet protection key, it follows"," that header protection achieves AE2 security as defined in [NAN] and"," therefore guarantees privacy of \"field\", the protected packet header.",[[[],0," "],[[679,1146],225,"Future header protection variants based on this construction MUST use"]],[[[],0," "],[[679,1146],225,"a PRF to ensure equivalent security guarantees."]],""," Use of the same key and ciphertext sample more than once risks"," compromising header protection. Protecting two different headers"," with the same key and ciphertext sample reveals the exclusive OR of"," the protected fields. Assuming that the AEAD acts as a PRF, if L"," bits are sampled, the odds of two ciphertext samples being identical"," approach 2^(-L/2), that is, the birthday bound. For the algorithms"," described in this document, that probability is one in 2^64.",""," To prevent an attacker from modifying packet headers, the header is"," transitively authenticated using packet protection; the entire packet"," header is part of the authenticated additional data. Protected"," fields that are falsified or modified can only be detected once the"," packet protection is removed."],"requirements":[679]},{"id":"section-9.5","title":"Header Protection Timing Side Channels","lines":[" An attacker could guess values for packet numbers or Key Phase and"," have an endpoint confirm guesses through timing side channels."," Similarly, guesses for the packet number length can be tried and"," exposed. If the recipient of a packet discards packets with"," duplicate packet numbers without attempting to remove packet"," protection, they could reveal through timing side channels that the",[[[],0," packet number matches a received packet. "],[[680,1160],225,"For authentication to be"]],[[[],0," "],[[680,1160],225,"free from side channels, the entire process of header protection"]],[[[],0," "],[[680,1160],225,"removal, packet number recovery, and packet protection removal MUST"]],[[[],0," "],[[680,1160],225,"be applied together without timing and other side channels."]],"",[[[],0," "],[[681,1161],225,"For the sending of packets, construction and protection of packet"]],[[[],0," "],[[681,1161],225,"payloads and packet numbers MUST be free from side channels that"]],[[[],0," "],[[681,1161],225,"would reveal the packet number or its encoded size."]],""," During a key update, the time taken to generate new keys could reveal"," through timing side channels that a key update has occurred."," Alternatively, where an attacker injects packets, this side channel",[[[],0," could reveal the value of the Key Phase on injected packets. "],[[682,2192],176,"After"]],[[[],0," "],[[682,2192],176,"receiving a key update, an endpoint SHOULD generate and save the next"]],[[[],0," "],[[682,2192],176,"set of receive packet protection keys, as described in Section 6.3."]]," By generating new keys before a key update is received, receipt of"," packets will not create timing signals that leak the value of the Key"," Phase.",""," This depends on not doing this key generation during packet"," processing, and it can require that endpoints maintain three sets of"," packet protection keys for receiving: for the previous key phase, for"," the current key phase, and for the next key phase. Endpoints can"," instead choose to defer generation of the next receive packet"," protection keys until they discard old keys so that only two sets of"," receive keys need to be retained at any point in time."],"requirements":[680,681,682]},{"id":"section-9.6","title":"Key Diversity","lines":[" In using TLS, the central key schedule of TLS is used. As a result"," of the TLS handshake messages being integrated into the calculation"," of secrets, the inclusion of the QUIC transport parameters extension"," ensures that the handshake and 1-RTT keys are not the same as those"," that might be produced by a server running TLS over TCP. To avoid"," the possibility of cross-protocol key synchronization, additional"," measures are provided to improve key separation.",""," The QUIC packet protection keys and IVs are derived using a different"," label than the equivalent keys in TLS.","",[[[],0," "],[[683,1147],161,"To preserve this separation, "],[[683,1147,2374,3140],181,"a new version of QUIC SHOULD define new"]],[[[],0," "],[[683,1147,2374,3140],181,"labels for key derivation for packet protection key and IV, plus the"]],[[[],0," "],[[683,1147,2374,3140],181,"header protection keys."],[[],0," This version of QUIC uses the string \"quic\"."]]," Other versions can use a version-specific label in place of that"," string.",""," The initial secrets use a key that is specific to the negotiated QUIC",[[[],0," version. "],[[684,2371],176,"New QUIC versions SHOULD define a new salt value used in"]],[[[],0," "],[[684,2371],176,"calculating initial secrets."]]],"requirements":[683,684]},{"id":"section-9.7","title":"Randomness","lines":[" QUIC depends on endpoints being able to generate secure random"," numbers, both directly for protocol values such as the connection ID,"," and transitively via TLS. See [RFC4086] for guidance on secure"," random number generation."]},{"id":"section-10","title":"IANA Considerations","lines":[" IANA has registered a codepoint of 57 (or 0x39) for the"," quic_transport_parameters extension (defined in Section 8.2) in the"," \"TLS ExtensionType Values\" registry [TLS-REGISTRIES].",""," The Recommended column for this extension is marked Yes. The TLS 1.3"," Column includes CH (ClientHello) and EE (EncryptedExtensions).",""," +=======+===========================+=====+=============+===========+"," | Value | Extension Name | TLS | Recommended | Reference |"," | | | 1.3 | | |"," +=======+===========================+=====+=============+===========+"," | 57 | quic_transport_parameters | CH, | Y | This |"," | | | EE | | document |"," +-------+---------------------------+-----+-------------+-----------+",""," Table 2: TLS ExtensionType Values Registry Entry"]},{"id":"section-11","title":"References","lines":[]},{"id":"section-11.1","title":"Normative References","lines":[" [AEAD] McGrew, D., \"An Interface and Algorithms for Authenticated"," Encryption\", RFC 5116, DOI 10.17487/RFC5116, January 2008,"," .",""," [AES] \"Advanced encryption standard (AES)\", National Institute"," of Standards and Technology report,"," DOI 10.6028/nist.fips.197, November 2001,"," .",""," [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,"," \"Transport Layer Security (TLS) Application-Layer Protocol"," Negotiation Extension\", RFC 7301, DOI 10.17487/RFC7301,"," July 2014, .",""," [CHACHA] Nir, Y. and A. Langley, \"ChaCha20 and Poly1305 for IETF"," Protocols\", RFC 8439, DOI 10.17487/RFC8439, June 2018,"," .",""," [HKDF] Krawczyk, H. and P. Eronen, \"HMAC-based Extract-and-Expand"," Key Derivation Function (HKDF)\", RFC 5869,"," DOI 10.17487/RFC5869, May 2010,"," .",""," [QUIC-RECOVERY]"," Iyengar, J., Ed. and I. Swett, Ed., \"QUIC Loss Detection"," and Congestion Control\", RFC 9002, DOI 10.17487/RFC9002,"," May 2021, .",""," [QUIC-TRANSPORT]"," Iyengar, J., Ed. and M. Thomson, Ed., \"QUIC: A UDP-Based"," Multiplexed and Secure Transport\", RFC 9000,"," DOI 10.17487/RFC9000, May 2021,"," .",""," [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate"," Requirement Levels\", BCP 14, RFC 2119,"," DOI 10.17487/RFC2119, March 1997,"," .",""," [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,"," \"Randomness Requirements for Security\", BCP 106, RFC 4086,"," DOI 10.17487/RFC4086, June 2005,"," .",""," [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC"," 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,"," May 2017, .",""," [SHA] Dang, Q., \"Secure Hash Standard\", National Institute of"," Standards and Technology report,"," DOI 10.6028/nist.fips.180-4, July 2015,"," .",""," [TLS-REGISTRIES]"," Salowey, J. and S. Turner, \"IANA Registry Updates for TLS"," and DTLS\", RFC 8447, DOI 10.17487/RFC8447, August 2018,"," .",""," [TLS13] Rescorla, E., \"The Transport Layer Security (TLS) Protocol"," Version 1.3\", RFC 8446, DOI 10.17487/RFC8446, August 2018,"," ."]},{"id":"section-11.2","title":"Informative References","lines":[" [AEBounds] Luykx, A. and K. Paterson, \"Limits on Authenticated"," Encryption Use in TLS\", 28 August 2017,"," .",""," [ASCII] Cerf, V., \"ASCII format for network interchange\", STD 80,"," RFC 20, DOI 10.17487/RFC0020, October 1969,"," .",""," [CCM-ANALYSIS]"," Jonsson, J., \"On the Security of CTR + CBC-MAC\", Selected"," Areas in Cryptography, SAC 2002, Lecture Notes in Computer"," Science, vol 2595, pp. 76-93, DOI 10.1007/3-540-36492-7_7,"," 2003, .",""," [COMPRESS] Ghedini, A. and V. Vasiliev, \"TLS Certificate"," Compression\", RFC 8879, DOI 10.17487/RFC8879, December"," 2020, .",""," [GCM-MU] Hoang, V., Tessaro, S., and A. Thiruvengadam, \"The Multi-"," user Security of GCM, Revisited: Tight Bounds for Nonce"," Randomization\", CCS '18: Proceedings of the 2018 ACM"," SIGSAC Conference on Computer and Communications Security,"," pp. 1429-1440, DOI 10.1145/3243734.3243816, 2018,"," .",""," [HTTP-REPLAY]"," Thomson, M., Nottingham, M., and W. Tarreau, \"Using Early"," Data in HTTP\", RFC 8470, DOI 10.17487/RFC8470, September"," 2018, .",""," [HTTP2-TLS13]"," Benjamin, D., \"Using TLS 1.3 with HTTP/2\", RFC 8740,"," DOI 10.17487/RFC8740, February 2020,"," .",""," [IMC] Katz, J. and Y. Lindell, \"Introduction to Modern"," Cryptography, Second Edition\", ISBN 978-1466570269, 6"," November 2014.",""," [NAN] Bellare, M., Ng, R., and B. Tackmann, \"Nonces Are Noticed:"," AEAD Revisited\", Advances in Cryptology - CRYPTO 2019,"," Lecture Notes in Computer Science, vol 11692, pp. 235-265,"," DOI 10.1007/978-3-030-26948-7_9, 2019,"," .",""," [QUIC-HTTP]"," Bishop, M., Ed., \"Hypertext Transfer Protocol Version 3"," (HTTP/3)\", Work in Progress, Internet-Draft, draft-ietf-"," quic-http-34, 2 February 2021,"," .",""," [RFC2818] Rescorla, E., \"HTTP Over TLS\", RFC 2818,"," DOI 10.17487/RFC2818, May 2000,"," .",""," [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,"," Housley, R., and W. Polk, \"Internet X.509 Public Key"," Infrastructure Certificate and Certificate Revocation List"," (CRL) Profile\", RFC 5280, DOI 10.17487/RFC5280, May 2008,"," .",""," [ROBUST] Fischlin, M., Günther, F., and C. Janson, \"Robust"," Channels: Handling Unreliable Networks in the Record"," Layers of QUIC and DTLS 1.3\", 16 May 2020,"," ."]},{"id":"appendix-A","title":"Sample Packet Protection","lines":[" This section shows examples of packet protection so that"," implementations can be verified incrementally. Samples of Initial"," packets from both client and server plus a Retry packet are defined."," These packets use an 8-byte client-chosen Destination Connection ID"," of 0x8394c8f03e515708. Some intermediate values are included. All"," values are shown in hexadecimal."]},{"id":"appendix-A.1","title":"Keys","lines":[" The labels generated during the execution of the HKDF-Expand-Label"," function (that is, HkdfLabel.label) and part of the value given to"," the HKDF-Expand function in order to produce its output are:",""," client in: 00200f746c73313320636c69656e7420696e00",""," server in: 00200f746c7331332073657276657220696e00",""," quic key: 00100e746c7331332071756963206b657900",""," quic iv: 000c0d746c733133207175696320697600",""," quic hp: 00100d746c733133207175696320687000",""," The initial secret is common:",""," initial_secret = HKDF-Extract(initial_salt, cid)"," = 7db5df06e7a69e432496adedb0085192"," 3595221596ae2ae9fb8115c1e9ed0a44",""," The secrets for protecting client packets are:",""," client_initial_secret"," = HKDF-Expand-Label(initial_secret, \"client in\", \"\", 32)"," = c00cf151ca5be075ed0ebfb5c80323c4"," 2d6b7db67881289af4008f1f6c357aea",""," key = HKDF-Expand-Label(client_initial_secret, \"quic key\", \"\", 16)"," = 1f369613dd76d5467730efcbe3b1a22d",""," iv = HKDF-Expand-Label(client_initial_secret, \"quic iv\", \"\", 12)"," = fa044b2f42a3fd3b46fb255c",""," hp = HKDF-Expand-Label(client_initial_secret, \"quic hp\", \"\", 16)"," = 9f50449e04a0e810283a1e9933adedd2",""," The secrets for protecting server packets are:",""," server_initial_secret"," = HKDF-Expand-Label(initial_secret, \"server in\", \"\", 32)"," = 3c199828fd139efd216c155ad844cc81"," fb82fa8d7446fa7d78be803acdda951b",""," key = HKDF-Expand-Label(server_initial_secret, \"quic key\", \"\", 16)"," = cf3a5331653c364c88f0f379b6067e37",""," iv = HKDF-Expand-Label(server_initial_secret, \"quic iv\", \"\", 12)"," = 0ac1493ca1905853b0bba03e",""," hp = HKDF-Expand-Label(server_initial_secret, \"quic hp\", \"\", 16)"," = c206b8d9b9f0f37644430b490eeaa314"]},{"id":"appendix-A.2","title":"Client Initial","lines":[" The client sends an Initial packet. The unprotected payload of this"," packet contains the following CRYPTO frame, plus enough PADDING"," frames to make a 1162-byte payload:",""," 060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868"," 04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578"," 616d706c652e636f6dff01000100000a 00080006001d00170018001000070005"," 04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba"," baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400"," 0d0010000e0403050306030203080408 050806002d00020101001c0002400100"," 3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000"," 75300901100f088394c8f03e51570806 048000ffff",""," The unprotected header indicates a length of 1182 bytes: the 4-byte"," packet number, 1162 bytes of frames, and the 16-byte authentication"," tag. The header includes the connection ID and a packet number of 2:",""," c300000001088394c8f03e5157080000449e00000002",""," Protecting the payload produces output that is sampled for header"," protection. Because the header uses a 4-byte packet number encoding,"," the first 16 bytes of the protected payload is sampled and then"," applied to the header as follows:",""," sample = d1b1c98dd7689fb8ec11d242b123dc9b",""," mask = AES-ECB(hp, sample)[0..4]"," = 437b9aec36",""," header[0] ^= mask[0] & 0x0f"," = c0"," header[18..21] ^= mask[1..4]"," = 7b9aec34"," header = c000000001088394c8f03e5157080000449e7b9aec34",""," The resulting protected packet is:",""," c000000001088394c8f03e5157080000 449e7b9aec34d1b1c98dd7689fb8ec11"," d242b123dc9bd8bab936b47d92ec356c 0bab7df5976d27cd449f63300099f399"," 1c260ec4c60d17b31f8429157bb35a12 82a643a8d2262cad67500cadb8e7378c"," 8eb7539ec4d4905fed1bee1fc8aafba1 7c750e2c7ace01e6005f80fcb7df6212"," 30c83711b39343fa028cea7f7fb5ff89 eac2308249a02252155e2347b63d58c5"," 457afd84d05dfffdb20392844ae81215 4682e9cf012f9021a6f0be17ddd0c208"," 4dce25ff9b06cde535d0f920a2db1bf3 62c23e596d11a4f5a6cf3948838a3aec"," 4e15daf8500a6ef69ec4e3feb6b1d98e 610ac8b7ec3faf6ad760b7bad1db4ba3"," 485e8a94dc250ae3fdb41ed15fb6a8e5 eba0fc3dd60bc8e30c5c4287e53805db"," 059ae0648db2f64264ed5e39be2e20d8 2df566da8dd5998ccabdae053060ae6c"," 7b4378e846d29f37ed7b4ea9ec5d82e7 961b7f25a9323851f681d582363aa5f8"," 9937f5a67258bf63ad6f1a0b1d96dbd4 faddfcefc5266ba6611722395c906556"," be52afe3f565636ad1b17d508b73d874 3eeb524be22b3dcbc2c7468d54119c74"," 68449a13d8e3b95811a198f3491de3e7 fe942b330407abf82a4ed7c1b311663a"," c69890f4157015853d91e923037c227a 33cdd5ec281ca3f79c44546b9d90ca00"," f064c99e3dd97911d39fe9c5d0b23a22 9a234cb36186c4819e8b9c5927726632"," 291d6a418211cc2962e20fe47feb3edf 330f2c603a9d48c0fcb5699dbfe58964"," 25c5bac4aee82e57a85aaf4e2513e4f0 5796b07ba2ee47d80506f8d2c25e50fd"," 14de71e6c418559302f939b0e1abd576 f279c4b2e0feb85c1f28ff18f58891ff"," ef132eef2fa09346aee33c28eb130ff2 8f5b766953334113211996d20011a198"," e3fc433f9f2541010ae17c1bf202580f 6047472fb36857fe843b19f5984009dd"," c324044e847a4f4a0ab34f719595de37 252d6235365e9b84392b061085349d73"," 203a4a13e96f5432ec0fd4a1ee65accd d5e3904df54c1da510b0ff20dcc0c77f"," cb2c0e0eb605cb0504db87632cf3d8b4 dae6e705769d1de354270123cb11450e"," fc60ac47683d7b8d0f811365565fd98c 4c8eb936bcab8d069fc33bd801b03ade"," a2e1fbc5aa463d08ca19896d2bf59a07 1b851e6c239052172f296bfb5e724047"," 90a2181014f3b94a4e97d117b4381303 68cc39dbb2d198065ae3986547926cd2"," 162f40a29f0c3c8745c0f50fba3852e5 66d44575c29d39a03f0cda721984b6f4"," 40591f355e12d439ff150aab7613499d bd49adabc8676eef023b15b65bfc5ca0"," 6948109f23f350db82123535eb8a7433 bdabcb909271a6ecbcb58b936a88cd4e"," 8f2e6ff5800175f113253d8fa9ca8885 c2f552e657dc603f252e1a8e308f76f0"," be79e2fb8f5d5fbbe2e30ecadd220723 c8c0aea8078cdfcb3868263ff8f09400"," 54da48781893a7e49ad5aff4af300cd8 04a6b6279ab3ff3afb64491c85194aab"," 760d58a606654f9f4400e8b38591356f bf6425aca26dc85244259ff2b19c41b9"," f96f3ca9ec1dde434da7d2d392b905dd f3d1f9af93d1af5950bd493f5aa731b4"," 056df31bd267b6b90a079831aaf579be 0a39013137aac6d404f518cfd4684064"," 7e78bfe706ca4cf5e9c5453e9f7cfd2b 8b4c8d169a44e55c88d4a9a7f9474241"," e221af44860018ab0856972e194cd934"]},{"id":"appendix-A.3","title":"Server Initial","lines":[" The server sends the following payload in response, including an ACK"," frame, a CRYPTO frame, and no PADDING frames:",""," 02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739"," 88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94"," 0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00"," 020304",""," The header from the server includes a new connection ID and a 2-byte"," packet number encoding for a packet number of 1:",""," c1000000010008f067a5502a4262b50040750001",""," As a result, after protection, the header protection sample is taken"," starting from the third protected byte:",""," sample = 2cd0991cd25b0aac406a5816b6394100"," mask = 2ec0d8356a"," header = cf000000010008f067a5502a4262b5004075c0d9",""," The final protected packet is then:",""," cf000000010008f067a5502a4262b500 4075c0d95a482cd0991cd25b0aac406a"," 5816b6394100f37a1c69797554780bb3 8cc5a99f5ede4cf73c3ec2493a1839b3"," dbcba3f6ea46c5b7684df3548e7ddeb9 c3bf9c73cc3f3bded74b562bfb19fb84"," 022f8ef4cdd93795d77d06edbb7aaf2f 58891850abbdca3d20398c276456cbc4"," 2158407dd074ee"]},{"id":"appendix-A.4","title":"Retry","lines":[" This shows a Retry packet that might be sent in response to the"," Initial packet in Appendix A.2. The integrity check includes the"," client-chosen connection ID value of 0x8394c8f03e515708, but that"," value is not included in the final Retry packet:",""," ff000000010008f067a5502a4262b574 6f6b656e04a265ba2eff4d829058fb3f"," 0f2496ba"]},{"id":"appendix-A.5","title":"ChaCha20-Poly1305 Short Header Packet","lines":[" This example shows some of the steps required to protect a packet"," with a short header. This example uses AEAD_CHACHA20_POLY1305.",""," In this example, TLS produces an application write secret from which"," a server uses HKDF-Expand-Label to produce four values: a key, an IV,"," a header protection key, and the secret that will be used after keys"," are updated (this last value is not used further in this example).",""," secret"," = 9ac312a7f877468ebe69422748ad00a1"," 5443f18203a07d6060f688f30f21632b",""," key = HKDF-Expand-Label(secret, \"quic key\", \"\", 32)"," = c6d98ff3441c3fe1b2182094f69caa2e"," d4b716b65488960a7a984979fb23e1c8",""," iv = HKDF-Expand-Label(secret, \"quic iv\", \"\", 12)"," = e0459b3474bdd0e44a41c144",""," hp = HKDF-Expand-Label(secret, \"quic hp\", \"\", 32)"," = 25a282b9e82f06f21f488917a4fc8f1b"," 73573685608597d0efcb076b0ab7a7a4",""," ku = HKDF-Expand-Label(secret, \"quic ku\", \"\", 32)"," = 1223504755036d556342ee9361d25342"," 1a826c9ecdf3c7148684b36b714881f9",""," The following shows the steps involved in protecting a minimal packet"," with an empty Destination Connection ID. This packet contains a"," single PING frame (that is, a payload of just 0x01) and has a packet"," number of 654360564. In this example, using a packet number of"," length 3 (that is, 49140 is encoded) avoids having to pad the payload"," of the packet; PADDING frames would be needed if the packet number is"," encoded on fewer bytes.",""," pn = 654360564 (decimal)"," nonce = e0459b3474bdd0e46d417eb0"," unprotected header = 4200bff4"," payload plaintext = 01"," payload ciphertext = 655e5cd55c41f69080575d7999c25a5bfb",""," The resulting ciphertext is the minimum size possible. One byte is"," skipped to produce the sample for header protection.",""," sample = 5e5cd55c41f69080575d7999c25a5bfb"," mask = aefefe7d03"," header = 4cfe4189",""," The protected packet is the smallest possible packet size of 21"," bytes.",""," packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb"]},{"id":"appendix-B","title":"AEAD Algorithm Analysis","lines":[" This section documents analyses used in deriving AEAD algorithm"," limits for AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM."," The analyses that follow use symbols for multiplication (*), division"," (/), and exponentiation (^), plus parentheses for establishing"," precedence. The following symbols are also used:",""," t: The size of the authentication tag in bits. For these ciphers, t"," is 128.",""," n: The size of the block function in bits. For these ciphers, n is"," 128.",""," k: The size of the key in bits. This is 128 for AEAD_AES_128_GCM"," and AEAD_AES_128_CCM; 256 for AEAD_AES_256_GCM.",""," l: The number of blocks in each packet (see below).",""," q: The number of genuine packets created and protected by endpoints."," This value is the bound on the number of packets that can be"," protected before updating keys.",""," v: The number of forged packets that endpoints will accept. This"," value is the bound on the number of forged packets that an"," endpoint can reject before updating keys.",""," o: The amount of offline ideal cipher queries made by an adversary.",""," The analyses that follow rely on a count of the number of block"," operations involved in producing each message. This analysis is"," performed for packets of size up to 2^11 (l = 2^7) and 2^16 (l ="," 2^12). A size of 2^11 is expected to be a limit that matches common"," deployment patterns, whereas the 2^16 is the maximum possible size of"," a QUIC packet. Only endpoints that strictly limit packet size can"," use the larger confidentiality and integrity limits that are derived"," using the smaller packet size.",""," For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is"," the length of the associated data in blocks plus the length of the"," plaintext in blocks.",""," For AEAD_AES_128_CCM, the total number of block cipher operations is"," the sum of the following: the length of the associated data in"," blocks, the length of the ciphertext in blocks, the length of the"," plaintext in blocks, plus 1. In this analysis, this is simplified to"," a value of twice the length of the packet in blocks (that is, \"2l ="," 2^8\" for packets that are limited to 2^11 bytes, or \"2l = 2^13\""," otherwise). This simplification is based on the packet containing"," all of the associated data and ciphertext. This results in a one to"," three block overestimation of the number of operations per packet."]},{"id":"appendix-B.1","title":"Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits","lines":[" [GCM-MU] specifies concrete bounds for AEAD_AES_128_GCM and"," AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents"," this analysis using several simplifying assumptions:",""," * The number of ciphertext blocks an attacker uses in forgery"," attempts is bounded by v * l, which is the number of forgery"," attempts multiplied by the size of each packet (in blocks).",""," * The amount of offline work done by an attacker does not dominate"," other factors in the analysis.",""," The bounds in [GCM-MU] are tighter and more complete than those used"," in [AEBounds], which allows for larger limits than those described in"," [TLS13]."]},{"id":"appendix-B.1.1","title":"Confidentiality Limit","lines":[" For confidentiality, Theorem (4.3) in [GCM-MU] establishes that, for"," a single user that does not repeat nonces, the dominant term in"," determining the distinguishing advantage between a real and random"," AEAD algorithm gained by an attacker is:",""," 2 * (q * l)^2 / 2^n",""," For a target advantage of 2^-57, this results in the relation:",""," q <= 2^35 / l",""," Thus, endpoints that do not send packets larger than 2^11 bytes"," cannot protect more than 2^28 packets in a single connection without"," causing an attacker to gain a more significant advantage than the"," target of 2^-57. The limit for endpoints that allow for the packet"," size to be as large as 2^16 is instead 2^23."]},{"id":"appendix-B.1.2","title":"Integrity Limit","lines":[" For integrity, Theorem (4.3) in [GCM-MU] establishes that an attacker"," gains an advantage in successfully forging a packet of no more than"," the following:",""," (1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n))"," + ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k)",""," The goal is to limit this advantage to 2^-57. For AEAD_AES_128_GCM,"," the fourth term in this inequality dominates the rest, so the others"," can be removed without significant effect on the result. This"," produces the following approximation:",""," v <= 2^64 / l",""," Endpoints that do not attempt to remove protection from packets"," larger than 2^11 bytes can attempt to remove protection from at most"," 2^57 packets. Endpoints that do not restrict the size of processed"," packets can attempt to remove protection from at most 2^52 packets.",""," For AEAD_AES_256_GCM, the same term dominates, but the larger value"," of k produces the following approximation:",""," v <= 2^192 / l",""," This is substantially larger than the limit for AEAD_AES_128_GCM."," However, this document recommends that the same limit be applied to"," both functions as either limit is acceptably large."]},{"id":"appendix-B.2","title":"Analysis of AEAD_AES_128_CCM Usage Limits","lines":[" TLS [TLS13] and [AEBounds] do not specify limits on usage for"," AEAD_AES_128_CCM. However, any AEAD that is used with QUIC requires"," limits on use that ensure that both confidentiality and integrity are"," preserved. This section documents that analysis.",""," [CCM-ANALYSIS] is used as the basis of this analysis. The results of"," that analysis are used to derive usage limits that are based on those"," chosen in [TLS13].",""," For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an"," attacker gains a distinguishing advantage over an ideal pseudorandom"," permutation (PRP) of no more than the following:",""," (2l * q)^2 / 2^n",""," The integrity limit in Theorem 1 in [CCM-ANALYSIS] provides an"," attacker a strictly higher advantage for the same number of messages."," As the targets for the confidentiality advantage and the integrity"," advantage are the same, only Theorem 1 needs to be considered.",""," Theorem 1 establishes that an attacker gains an advantage over an"," ideal PRP of no more than the following:",""," v / 2^t + (2l * (v + q))^2 / 2^n",""," As \"t\" and \"n\" are both 128, the first term is negligible relative to"," the second, so that term can be removed without a significant effect"," on the result.",""," This produces a relation that combines both encryption and decryption"," attempts with the same limit as that produced by the theorem for"," confidentiality alone. For a target advantage of 2^-57, this results"," in the following:",""," v + q <= 2^34.5 / l",""," By setting \"q = v\", values for both confidentiality and integrity"," limits can be produced. Endpoints that limit packets to 2^11 bytes"," therefore have both confidentiality and integrity limits of 2^26.5"," packets. Endpoints that do not restrict packet size have a limit of"," 2^21.5."]},{"id":"name-contributors","title":"Contributors","lines":[" The IETF QUIC Working Group received an enormous amount of support"," from many people. The following people provided substantive"," contributions to this document:",""," * Adam Langley"," * Alessandro Ghedini"," * Christian Huitema"," * Christopher Wood"," * David Schinazi"," * Dragana Damjanovic"," * Eric Rescorla"," * Felix Günther"," * Ian Swett"," * Jana Iyengar"," * 奥 一穂 (Kazuho Oku)"," * Marten Seemann"," * Martin Duke"," * Mike Bishop"," * Mikkel Fahnøe Jørgensen"," * Nick Banks"," * Nick Harper"," * Roberto Peon"," * Rui Paulo"," * Ryan Hamilton"," * Victor Vasiliev"]},{"id":"name-authors-addresses","title":"Authors' Addresses","lines":[" Martin Thomson (editor)"," Mozilla",""," Email: mt@lowentropy.net",""," Sean Turner (editor)"," sn3rd",""," Email: sean@sn3rd.com"]}]},"https://www.rfc-editor.org/rfc/rfc9002":{"format":"ietf","requirements":[685,686,687,688,689,690,691,692,693,694,695,696,697,698,699,700,701,702,703,704,705,706,707,708,709,710,711,712,713,714,715,716,717,718,719,720,721,722,723,724,725,726,727,728,729,730,731,732,733,734,735,736,737,738,739,740,741,742,743,744,745,746,747,748,749,750,751,752,753,754,755,756,757,758,759,760,761,762,763,764],"sections":[{"id":"name-abstract","title":"Abstract","lines":[" This document describes loss detection and congestion control"," mechanisms for QUIC."]},{"id":"name-status-of-this-memo","title":"Status of This Memo","lines":[" This is an Internet Standards Track document.",""," This document is a product of the Internet Engineering Task Force"," (IETF). It represents the consensus of the IETF community. It has"," received public review and has been approved for publication by the"," Internet Engineering Steering Group (IESG). Further information on"," Internet Standards is available in Section 2 of RFC 7841.",""," Information about the current status of this document, any errata,"," and how to provide feedback on it may be obtained at"," https://www.rfc-editor.org/info/rfc9002."]},{"id":"name-copyright-notice","title":"Copyright Notice","lines":[" Copyright (c) 2021 IETF Trust and the persons identified as the"," document authors. All rights reserved.",""," This document is subject to BCP 78 and the IETF Trust's Legal"," Provisions Relating to IETF Documents"," (https://trustee.ietf.org/license-info) in effect on the date of"," publication of this document. Please review these documents"," carefully, as they describe your rights and restrictions with respect"," to this document. Code Components extracted from this document must"," include Simplified BSD License text as described in Section 4.e of"," the Trust Legal Provisions and are provided without warranty as"," described in the Simplified BSD License."]},{"id":"name-table-of-contents","title":"Table of Contents","lines":[" 1. Introduction"," 2. Conventions and Definitions"," 3. Design of the QUIC Transmission Machinery"," 4. Relevant Differences between QUIC and TCP"," 4.1. Separate Packet Number Spaces"," 4.2. Monotonically Increasing Packet Numbers"," 4.3. Clearer Loss Epoch"," 4.4. No Reneging"," 4.5. More ACK Ranges"," 4.6. Explicit Correction for Delayed Acknowledgments"," 4.7. Probe Timeout Replaces RTO and TLP"," 4.8. The Minimum Congestion Window Is Two Packets"," 4.9. Handshake Packets Are Not Special"," 5. Estimating the Round-Trip Time"," 5.1. Generating RTT Samples"," 5.2. Estimating min_rtt"," 5.3. Estimating smoothed_rtt and rttvar"," 6. Loss Detection"," 6.1. Acknowledgment-Based Detection"," 6.1.1. Packet Threshold"," 6.1.2. Time Threshold"," 6.2. Probe Timeout"," 6.2.1. Computing PTO"," 6.2.2. Handshakes and New Paths"," 6.2.3. Speeding up Handshake Completion"," 6.2.4. Sending Probe Packets"," 6.3. Handling Retry Packets"," 6.4. Discarding Keys and Packet State"," 7. Congestion Control"," 7.1. Explicit Congestion Notification"," 7.2. Initial and Minimum Congestion Window"," 7.3. Congestion Control States"," 7.3.1. Slow Start"," 7.3.2. Recovery"," 7.3.3. Congestion Avoidance"," 7.4. Ignoring Loss of Undecryptable Packets"," 7.5. Probe Timeout"," 7.6. Persistent Congestion"," 7.6.1. Duration"," 7.6.2. Establishing Persistent Congestion"," 7.6.3. Example"," 7.7. Pacing"," 7.8. Underutilizing the Congestion Window"," 8. Security Considerations"," 8.1. Loss and Congestion Signals"," 8.2. Traffic Analysis"," 8.3. Misreporting ECN Markings"," 9. References"," 9.1. Normative References"," 9.2. Informative References"," Appendix A. Loss Recovery Pseudocode"," A.1. Tracking Sent Packets"," A.1.1. Sent Packet Fields"," A.2. Constants of Interest"," A.3. Variables of Interest"," A.4. Initialization"," A.5. On Sending a Packet"," A.6. On Receiving a Datagram"," A.7. On Receiving an Acknowledgment"," A.8. Setting the Loss Detection Timer"," A.9. On Timeout"," A.10. Detecting Lost Packets"," A.11. Upon Dropping Initial or Handshake Keys"," Appendix B. Congestion Control Pseudocode"," B.1. Constants of Interest"," B.2. Variables of Interest"," B.3. Initialization"," B.4. On Packet Sent"," B.5. On Packet Acknowledgment"," B.6. On New Congestion Event"," B.7. Process ECN Information"," B.8. On Packets Lost"," B.9. Removing Discarded Packets from Bytes in Flight"," Contributors"," Authors' Addresses"]},{"id":"section-1","title":"Introduction","lines":[" QUIC is a secure, general-purpose transport protocol, described in"," [QUIC-TRANSPORT]. This document describes loss detection and"," congestion control mechanisms for QUIC."]},{"id":"section-2","title":"Conventions and Definitions","lines":[" 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 [RFC2119] [RFC8174] when, and only when, they appear in all"," capitals, as shown here.",""," Definitions of terms that are used in this document:",""," Ack-eliciting frames: All frames other than ACK, PADDING, and"," CONNECTION_CLOSE are considered ack-eliciting.",""," Ack-eliciting packets: Packets that contain ack-eliciting frames"," elicit an ACK from the receiver within the maximum acknowledgment"," delay and are called ack-eliciting packets.",""," In-flight packets: Packets are considered in flight when they are"," ack-eliciting or contain a PADDING frame, and they have been sent"," but are not acknowledged, declared lost, or discarded along with"," old keys."]},{"id":"section-3","title":"Design of the QUIC Transmission Machinery","lines":[" All transmissions in QUIC are sent with a packet-level header, which"," indicates the encryption level and includes a packet sequence number"," (referred to below as a packet number). The encryption level"," indicates the packet number space, as described in Section 12.3 of"," [QUIC-TRANSPORT]. Packet numbers never repeat within a packet number"," space for the lifetime of a connection. Packet numbers are sent in"," monotonically increasing order within a space, preventing ambiguity."," It is permitted for some packet numbers to never be used, leaving"," intentional gaps.",""," This design obviates the need for disambiguating between"," transmissions and retransmissions; this eliminates significant"," complexity from QUIC's interpretation of TCP loss detection"," mechanisms.",""," QUIC packets can contain multiple frames of different types. The"," recovery mechanisms ensure that data and frames that need reliable"," delivery are acknowledged or declared lost and sent in new packets as"," necessary. The types of frames contained in a packet affect recovery"," and congestion control logic:",""," * All packets are acknowledged, though packets that contain no ack-"," eliciting frames are only acknowledged along with ack-eliciting"," packets.",""," * Long header packets that contain CRYPTO frames are critical to the"," performance of the QUIC handshake and use shorter timers for"," acknowledgment.",""," * Packets containing frames besides ACK or CONNECTION_CLOSE frames"," count toward congestion control limits and are considered to be in"," flight.",""," * PADDING frames cause packets to contribute toward bytes in flight"," without directly causing an acknowledgment to be sent."]},{"id":"section-4","title":"Relevant Differences between QUIC and TCP","lines":[" Readers familiar with TCP's loss detection and congestion control"," will find algorithms here that parallel well-known TCP ones."," However, protocol differences between QUIC and TCP contribute to"," algorithmic differences. These protocol differences are briefly"," described below."]},{"id":"section-4.1","title":"Separate Packet Number Spaces","lines":[" QUIC uses separate packet number spaces for each encryption level,"," except 0-RTT and all generations of 1-RTT keys use the same packet"," number space. Separate packet number spaces ensures that the"," acknowledgment of packets sent with one level of encryption will not"," cause spurious retransmission of packets sent with a different"," encryption level. Congestion control and round-trip time (RTT)"," measurement are unified across packet number spaces."]},{"id":"section-4.2","title":"Monotonically Increasing Packet Numbers","lines":[" TCP conflates transmission order at the sender with delivery order at"," the receiver, resulting in the retransmission ambiguity problem"," [RETRANSMISSION]. QUIC separates transmission order from delivery"," order: packet numbers indicate transmission order, and delivery order"," is determined by the stream offsets in STREAM frames.",""," QUIC's packet number is strictly increasing within a packet number"," space and directly encodes transmission order. A higher packet"," number signifies that the packet was sent later, and a lower packet"," number signifies that the packet was sent earlier. When a packet"," containing ack-eliciting frames is detected lost, QUIC includes"," necessary frames in a new packet with a new packet number, removing"," ambiguity about which packet is acknowledged when an ACK is received."," Consequently, more accurate RTT measurements can be made, spurious"," retransmissions are trivially detected, and mechanisms such as Fast"," Retransmit can be applied universally, based only on packet number.",""," This design point significantly simplifies loss detection mechanisms"," for QUIC. Most TCP mechanisms implicitly attempt to infer"," transmission ordering based on TCP sequence numbers -- a nontrivial"," task, especially when TCP timestamps are not available."]},{"id":"section-4.3","title":"Clearer Loss Epoch","lines":[" QUIC starts a loss epoch when a packet is lost. The loss epoch ends"," when any packet sent after the start of the epoch is acknowledged."," TCP waits for the gap in the sequence number space to be filled, and"," so if a segment is lost multiple times in a row, the loss epoch may"," not end for several round trips. Because both should reduce their"," congestion windows only once per epoch, QUIC will do it once for"," every round trip that experiences loss, while TCP may only do it once"," across multiple round trips."]},{"id":"section-4.4","title":"No Reneging","lines":[" QUIC ACK frames contain information similar to that in TCP Selective"," Acknowledgments (SACKs) [RFC2018]. However, QUIC does not allow a"," packet acknowledgment to be reneged, greatly simplifying"," implementations on both sides and reducing memory pressure on the"," sender."]},{"id":"section-4.5","title":"More ACK Ranges","lines":[" QUIC supports many ACK ranges, as opposed to TCP's three SACK ranges."," In high-loss environments, this speeds recovery, reduces spurious"," retransmits, and ensures forward progress without relying on"," timeouts."]},{"id":"section-4.6","title":"Explicit Correction for Delayed Acknowledgments","lines":[" QUIC endpoints measure the delay incurred between when a packet is"," received and when the corresponding acknowledgment is sent, allowing"," a peer to maintain a more accurate RTT estimate; see Section 13.2 of"," [QUIC-TRANSPORT]."]},{"id":"section-4.7","title":"Probe Timeout Replaces RTO and TLP","lines":[" QUIC uses a probe timeout (PTO; see Section 6.2), with a timer based"," on TCP's retransmission timeout (RTO) computation; see [RFC6298]."," QUIC's PTO includes the peer's maximum expected acknowledgment delay"," instead of using a fixed minimum timeout.",""," Similar to the RACK-TLP loss detection algorithm for TCP [RFC8985],"," QUIC does not collapse the congestion window when the PTO expires,"," since a single packet loss at the tail does not indicate persistent"," congestion. Instead, QUIC collapses the congestion window when"," persistent congestion is declared; see Section 7.6. In doing this,"," QUIC avoids unnecessary congestion window reductions, obviating the"," need for correcting mechanisms such as Forward RTO-Recovery (F-RTO)"," [RFC5682]. Since QUIC does not collapse the congestion window on a"," PTO expiration, a QUIC sender is not limited from sending more in-"," flight packets after a PTO expiration if it still has available"," congestion window. This occurs when a sender is application limited"," and the PTO timer expires. This is more aggressive than TCP's RTO"," mechanism when application limited, but identical when not"," application limited.",""," QUIC allows probe packets to temporarily exceed the congestion window"," whenever the timer expires."]},{"id":"section-4.8","title":"The Minimum Congestion Window Is Two Packets","lines":[" TCP uses a minimum congestion window of one packet. However, loss of"," that single packet means that the sender needs to wait for a PTO to"," recover (Section 6.2), which can be much longer than an RTT. Sending"," a single ack-eliciting packet also increases the chances of incurring"," additional latency when a receiver delays its acknowledgment.",""," QUIC therefore recommends that the minimum congestion window be two"," packets. While this increases network load, it is considered safe"," since the sender will still reduce its sending rate exponentially"," under persistent congestion (Section 6.2)."]},{"id":"section-4.9","title":"Handshake Packets Are Not Special","lines":[" TCP treats the loss of SYN or SYN-ACK packet as persistent congestion"," and reduces the congestion window to one packet; see [RFC5681]. QUIC"," treats loss of a packet containing handshake data the same as other"," losses."]},{"id":"section-5","title":"Estimating the Round-Trip Time","lines":[" At a high level, an endpoint measures the time from when a packet was"," sent to when it is acknowledged as an RTT sample. The endpoint uses"," RTT samples and peer-reported host delays (see Section 13.2 of"," [QUIC-TRANSPORT]) to generate a statistical description of the"," network path's RTT. An endpoint computes the following three values"," for each path: the minimum value over a period of time (min_rtt), an"," exponentially weighted moving average (smoothed_rtt), and the mean"," deviation (referred to as \"variation\" in the rest of this document)"," in the observed RTT samples (rttvar)."]},{"id":"section-5.1","title":"Generating RTT Samples","lines":[[[[],0," "],[[1789],16,"An endpoint generates an RTT sample on receiving an ACK frame that"]],[[[],0," "],[[1789],16,"meets the following two conditions:"]],""," * the largest acknowledged packet number is newly acknowledged, and",""," * at least one of the newly acknowledged packets was ack-eliciting.","",[[[],0," "],[[2426],16,"The RTT sample, latest_rtt, is generated as the time elapsed since"]],[[[],0," "],[[2426],16,"the largest acknowledged packet was sent:"]],""," latest_rtt = ack_time - send_time_of_largest_acked",""," An RTT sample is generated using only the largest acknowledged packet"," in the received ACK frame. This is because a peer reports"," acknowledgment delays for only the largest acknowledged packet in an"," ACK frame. While the reported acknowledgment delay is not used by"," the RTT sample measurement, it is used to adjust the RTT sample in"," subsequent computations of smoothed_rtt and rttvar (Section 5.3).","",[[[],0," "],[[685,2414],176,"To avoid generating multiple RTT samples for a single packet, an ACK"]],[[[],0," "],[[685,2414],176,"frame SHOULD NOT be used to update RTT estimates if it does not newly"]],[[[],0," "],[[685,2414],176,"acknowledge the largest acknowledged packet."]],"",[[[],0," "],[[686,2415],240,"An RTT sample MUST NOT be generated on receiving an ACK frame that"]],[[[],0," "],[[686,2415],240,"does not newly acknowledge at least one ack-eliciting packet."],[[],0," A peer"]]," usually does not send an ACK frame when only non-ack-eliciting"," packets are received. Therefore, an ACK frame that contains"," acknowledgments for only non-ack-eliciting packets could include an"," arbitrarily large ACK Delay value. Ignoring such ACK frames avoids"," complications in subsequent smoothed_rtt and rttvar computations.",""," A sender might generate multiple RTT samples per RTT when multiple"," ACK frames are received within an RTT. As suggested in [RFC6298],"," doing so might result in inadequate history in smoothed_rtt and"," rttvar. Ensuring that RTT estimates retain sufficient history is an"," open research question."],"requirements":[685,686]},{"id":"section-5.2","title":"Estimating min_rtt","lines":[" min_rtt is the sender's estimate of the minimum RTT observed for a"," given network path over a period of time. In this document, min_rtt"," is used by loss detection to reject implausibly small RTT samples.","",[[[],0," "],[[687,2427,3074],244,"min_rtt MUST be set to the latest_rtt on the first RTT sample."]],[[[],0," "],[[688,2428],240,"min_rtt MUST be set to the lesser of min_rtt and latest_rtt"]],[[[],0," "],[[688,2428],240,"(Section 5.1) on all other samples."]],""," An endpoint uses only locally observed times in computing the min_rtt"," and does not adjust for acknowledgment delays reported by the peer."," Doing so allows the endpoint to set a lower bound for the"," smoothed_rtt based entirely on what it observes (see Section 5.3) and"," limits potential underestimation due to erroneously reported delays"," by the peer.",""," The RTT for a network path may change over time. If a path's actual"," RTT decreases, the min_rtt will adapt immediately on the first low"," sample. If the path's actual RTT increases, however, the min_rtt"," will not adapt to it, allowing future RTT samples that are smaller"," than the new RTT to be included in smoothed_rtt.","",[[[],0," "],[[689,1224],161,"Endpoints SHOULD set the min_rtt to the newest RTT sample after"]],[[[],0," "],[[689,1224],161,"persistent congestion is established."],[[],0," This avoids repeatedly"]]," declaring persistent congestion when the RTT increases. This also"," allows a connection to reset its estimate of min_rtt and smoothed_rtt"," after a disruptive network event; see Section 5.3.","",[[[],0," "],[[690,1225],97,"Endpoints MAY reestablish the min_rtt at other times in the"]],[[[],0," "],[[690,1225],97,"connection, such as when traffic volume is low and an acknowledgment"]],[[[],0," "],[[690,1225],97,"is received with a low acknowledgment delay."],[[],0," "],[[691,2429],176,"Implementations SHOULD"]],[[[],0," "],[[691,2429],176,"NOT refresh the min_rtt value too often since the actual minimum RTT"]],[[[],0," "],[[691,2429],176,"of the path is not frequently observable."]]],"requirements":[687,688,689,690,691]},{"id":"section-5.3","title":"Estimating smoothed_rtt and rttvar","lines":[" smoothed_rtt is an exponentially weighted moving average of an"," endpoint's RTT samples, and rttvar estimates the variation in the RTT"," samples using a mean variation.",""," The calculation of smoothed_rtt uses RTT samples after adjusting them"," for acknowledgment delays. These delays are decoded from the ACK"," Delay field of ACK frames as described in Section 19.3 of"," [QUIC-TRANSPORT].",""," The peer might report acknowledgment delays that are larger than the"," peer's max_ack_delay during the handshake (Section 13.2.1 of",[[[],0," [QUIC-TRANSPORT]). "],[[692,1790,2430],176,"To account for this, the endpoint SHOULD ignore"]],[[[],0," "],[[692,1790,2430],176,"max_ack_delay until the handshake is confirmed, as defined in"]],[[[],0," "],[[692,1790,2430],176,"Section 4.1.2 of [QUIC-TLS]."],[[],0," When they occur, these large"]]," acknowledgment delays are likely to be non-repeating and limited to"," the handshake. The endpoint can therefore use them without limiting"," them to the max_ack_delay, avoiding unnecessary inflation of the RTT"," estimate.",""," Note that a large acknowledgment delay can result in a substantially"," inflated smoothed_rtt if there is an error either in the peer's"," reporting of the acknowledgment delay or in the endpoint's min_rtt",[[[],0," estimate. "],[[693,1226],97,"Therefore, prior to handshake confirmation, an endpoint"]],[[[],0," "],[[693,1226],97,"MAY ignore RTT samples if adjusting the RTT sample for acknowledgment"]],[[[],0," "],[[693,1226],97,"delay causes the sample to be less than the min_rtt."]],""," After the handshake is confirmed, any acknowledgment delays reported"," by the peer that are greater than the peer's max_ack_delay are"," attributed to unintentional but potentially repeating delays, such as"," scheduler latency at the peer or loss of previous acknowledgments."," Excess delays could also be due to a noncompliant receiver."," Therefore, these extra delays are considered effectively part of path"," delay and incorporated into the RTT estimate.",""," Therefore, when adjusting an RTT sample using peer-reported"," acknowledgment delays, an endpoint:","",[[[],0," "],[[694,1227],97,"* MAY ignore the acknowledgment delay for Initial packets, since"]],[[[],0," "],[[694,1227],97,"these acknowledgments are not delayed by the peer (Section 13.2.1"]],[[[],0," "],[[694,1227],97,"of [QUIC-TRANSPORT]);"]],"",[[[],0," "],[[695,1791,2431],176,"* SHOULD ignore the peer's max_ack_delay until the handshake is"]],[[[],0," "],[[695,1791,2431],176,"confirmed;"]],"",[[[],0," "],[[696,2432],240,"* MUST use the lesser of the acknowledgment delay and the peer's"]],[[[],0," "],[[696,2432],240,"max_ack_delay after the handshake is confirmed; and"]],"",[[[],0," "],[[697,2433],240,"* MUST NOT subtract the acknowledgment delay from the RTT sample if"]],[[[],0," "],[[697,2433],240,"the resulting value is smaller than the min_rtt."],[[],0," This limits the"]]," underestimation of the smoothed_rtt due to a misreporting peer.",""," Additionally, an endpoint might postpone the processing of"," acknowledgments when the corresponding decryption keys are not"," immediately available. For example, a client might receive an"," acknowledgment for a 0-RTT packet that it cannot decrypt because",[[[],0," 1-RTT packet protection keys are not yet available to it. "],[[698,1228],161,"In such"]],[[[],0," "],[[698,1228],161,"cases, an endpoint SHOULD subtract such local delays from its RTT"]],[[[],0," "],[[698,1228],161,"sample until the handshake is confirmed."]],""," Similar to [RFC6298], smoothed_rtt and rttvar are computed as"," follows.",""," An endpoint initializes the RTT estimator during connection"," establishment and when the estimator is reset during connection"," migration; see Section 9.4 of [QUIC-TRANSPORT]. Before any RTT"," samples are available for a new path or when the estimator is reset,"," the estimator is initialized using the initial RTT; see"," Section 6.2.2.",""," smoothed_rtt and rttvar are initialized as follows, where kInitialRtt"," contains the initial RTT value:",""," smoothed_rtt = kInitialRtt"," rttvar = kInitialRtt / 2",""," RTT samples for the network path are recorded in latest_rtt; see"," Section 5.1. On the first RTT sample after initialization, the"," estimator is reset using that sample. This ensures that the"," estimator retains no history of past samples. Packets sent on other"," paths do not contribute RTT samples to the current path, as described"," in Section 9.4 of [QUIC-TRANSPORT].",""," On the first RTT sample after initialization, smoothed_rtt and rttvar"," are set as follows:",""," smoothed_rtt = latest_rtt"," rttvar = latest_rtt / 2",""," On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows:",""," ack_delay = decoded acknowledgment delay from ACK frame"," if (handshake confirmed):"," ack_delay = min(ack_delay, max_ack_delay)"," adjusted_rtt = latest_rtt"," if (latest_rtt >= min_rtt + ack_delay):"," adjusted_rtt = latest_rtt - ack_delay"," smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt"," rttvar_sample = abs(smoothed_rtt - adjusted_rtt)"," rttvar = 3/4 * rttvar + 1/4 * rttvar_sample"],"requirements":[692,693,694,695,696,697,698]},{"id":"section-6","title":"Loss Detection","lines":[" QUIC senders use acknowledgments to detect lost packets and a PTO to"," ensure acknowledgments are received; see Section 6.2. This section"," provides a description of these algorithms.",""," If a packet is lost, the QUIC transport needs to recover from that"," loss, such as by retransmitting the data, sending an updated frame,"," or discarding the frame. For more information, see Section 13.3 of"," [QUIC-TRANSPORT].",""," Loss detection is separate per packet number space, unlike RTT"," measurement and congestion control, because RTT and congestion"," control are properties of the path, whereas loss detection also"," relies upon key availability."]},{"id":"section-6.1","title":"Acknowledgment-Based Detection","lines":[" Acknowledgment-based loss detection implements the spirit of TCP's"," Fast Retransmit [RFC5681], Early Retransmit [RFC5827], Forward"," Acknowledgment [FACK], SACK loss recovery [RFC6675], and RACK-TLP"," [RFC8985]. This section provides an overview of how these algorithms"," are implemented in QUIC.","",[[[],0," "],[[2421],16,"A packet is declared lost if it meets all of the following"]],[[[],0," "],[[2421],16,"conditions:"]],""," * The packet is unacknowledged, in flight, and was sent prior to an"," acknowledged packet.",""," * The packet was sent kPacketThreshold packets before an"," acknowledged packet (Section 6.1.1), or it was sent long enough in"," the past (Section 6.1.2).",""," The acknowledgment indicates that a packet sent later was delivered,"," and the packet and time thresholds provide some tolerance for packet"," reordering.",""," Spuriously declaring packets as lost leads to unnecessary"," retransmissions and may result in degraded performance due to the"," actions of the congestion controller upon detecting loss."," Implementations can detect spurious retransmissions and increase the"," packet or time reordering threshold to reduce future spurious",[[[],0," retransmissions and loss events. "],[[707,2420],112,"Implementations with adaptive time"]],[[[],0," "],[[707,2420],112,"thresholds MAY choose to start with smaller initial reordering"]],[[[],0," "],[[707,2420],112,"thresholds to minimize recovery latency."]]],"requirements":[707]},{"id":"section-6.1.1","title":"Packet Threshold","lines":[[[[],0," "],[[699,2434],176,"The RECOMMENDED initial value for the packet reordering threshold"]],[[[],0," "],[[699,2434],176,"(kPacketThreshold) is 3, based on best practices for TCP loss"]],[[[],0," "],[[699,2434],176,"detection [RFC5681] [RFC6675]."],[[],0," "],[[700,2416,2435],176,"In order to remain similar to TCP,"]],[[[],0," "],[[700,2416,2435],176,"implementations SHOULD NOT use a packet threshold less than 3;"],[[700,2435],176," see"]],[[[],0," "],[[700,2435],176,"[RFC5681]."]],""," Some networks may exhibit higher degrees of packet reordering,"," causing a sender to detect spurious losses. Additionally, packet"," reordering could be more common with QUIC than TCP because network"," elements that could observe and reorder TCP packets cannot do that"," for QUIC and also because QUIC packet numbers are encrypted."," Algorithms that increase the reordering threshold after spuriously"," detecting losses, such as RACK [RFC8985], have proven to be useful in"," TCP and are expected to be at least as useful in QUIC."],"requirements":[699,700]},{"id":"section-6.1.2","title":"Time Threshold","lines":[[[[],0," "],[[701,2413],176,"Once a later packet within the same packet number space has been"]],[[[],0," "],[[701,2413],176,"acknowledged, an endpoint SHOULD declare an earlier packet lost if it"]],[[[],0," "],[[701,2413],176,"was sent a threshold amount of time in the past."],[[],0," "],[[702,2399],240,"To avoid declaring"]],[[[],0," "],[[702,2399],240,"packets as lost too early, this time threshold MUST be set to at"]],[[[],0," "],[[702,2399],240,"least the local timer granularity, as indicated by the kGranularity"]],[[[],0," "],[[702,2399],240,"constant."],[[],0," "],[[2422],16,"The time threshold is:"]],"",[[[],0," "],[[2398,2422],16,"max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)"]],"",[[[],0," "],[[703,2417],176,"If packets sent prior to the largest acknowledged packet cannot yet"]],[[[],0," "],[[703,2417],176,"be declared lost, then a timer SHOULD be set for the remaining time."]],""," Using max(smoothed_rtt, latest_rtt) protects from the two following"," cases:",""," * the latest RTT sample is lower than the smoothed RTT, perhaps due"," to reordering where the acknowledgment encountered a shorter path;",""," * the latest RTT sample is higher than the smoothed RTT, perhaps due"," to a sustained increase in the actual RTT, but the smoothed RTT"," has not yet caught up.","",[[[],0," "],[[704,2436],176,"The RECOMMENDED time threshold (kTimeThreshold), expressed as an RTT"]],[[[],0," "],[[704,2436],176,"multiplier, is 9/8."],[[],0," "],[[705,2437],176,"The RECOMMENDED value of the timer granularity"]],[[[],0," "],[[705,2437],176,"(kGranularity) is 1 millisecond."]],""," | Note: TCP's RACK [RFC8985] specifies a slightly larger"," | threshold, equivalent to 5/4, for a similar purpose."," | Experience with QUIC shows that 9/8 works well.","",[[[],0," "],[[706,2418,2419],112,"Implementations MAY experiment with absolute thresholds, thresholds"]],[[[],0," "],[[706,2418,2419],112,"from previous connections, adaptive thresholds, or the including of"]],[[[],0," "],[[706,2418,2419],112,"RTT variation."],[[],0," Smaller thresholds reduce reordering resilience and"]]," increase spurious retransmissions, and larger thresholds increase"," loss detection delay."],"requirements":[701,702,703,704,705,706]},{"id":"section-6.2","title":"Probe Timeout","lines":[" A Probe Timeout (PTO) triggers the sending of one or two probe"," datagrams when ack-eliciting packets are not acknowledged within the"," expected period of time or the server may not have validated the"," client's address. A PTO enables a connection to recover from loss of"," tail packets or acknowledgments.",""," As with loss detection, the PTO is per packet number space. That is,"," a PTO value is computed per packet number space.","",[[[],0," "],[[731,1221],225,"A PTO timer expiration event does not indicate packet loss and MUST"]],[[[],0," "],[[731,1221],225,"NOT cause prior unacknowledged packets to be marked as lost."],[[],0," When an"]]," acknowledgment is received that newly acknowledges packets, loss"," detection proceeds as dictated by the packet and time threshold"," mechanisms; see Section 6.1.",""," The PTO algorithm used in QUIC implements the reliability functions"," of Tail Loss Probe [RFC8985], RTO [RFC5681], and F-RTO algorithms for"," TCP [RFC5682]. The timeout computation is based on TCP's RTO period"," [RFC6298]."],"requirements":[731]},{"id":"section-6.2.1","title":"Computing PTO","lines":[" When an ack-eliciting packet is transmitted, the sender schedules a"," timer for the PTO period as follows:","",[[[],0," "],[[2423],16,"PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay"]],""," The PTO period is the amount of time that a sender ought to wait for"," an acknowledgment of a sent packet. This time period includes the"," estimated network RTT (smoothed_rtt), the variation in the estimate"," (4*rttvar), and max_ack_delay, to account for the maximum time by"," which a receiver might delay sending an acknowledgment.","",[[[],0," "],[[2170],16,"When the PTO is armed for Initial or Handshake packet number spaces,"]],[[[],0," "],[[2170],16,"the max_ack_delay in the PTO period computation is set to 0"],[[],0,", since"]]," the peer is expected to not delay these packets intentionally; see"," Section 13.2.1 of [QUIC-TRANSPORT].","",[[[],0," "],[[708,2424],240,"The PTO period MUST be at least kGranularity to avoid the timer"]],[[[],0," "],[[708,2424],240,"expiring immediately."]],"",[[[],0," "],[[709,2171],240,"When ack-eliciting packets in multiple packet number spaces are in"]],[[[],0," "],[[709,2171],240,"flight, the timer MUST be set to the earlier value of the Initial and"]],[[[],0," "],[[709,2171],240,"Handshake packet number spaces."]],"",[[[],0," "],[[710,2172],240,"An endpoint MUST NOT set its PTO timer for the Application Data"]],[[[],0," "],[[710,2172],240,"packet number space until the handshake is confirmed."],[[],0," Doing so"]]," prevents the endpoint from retransmitting information in packets when"," either the peer does not yet have the keys to process them or the"," endpoint does not yet have the keys to process their acknowledgments."," For example, this can happen when a client sends 0-RTT packets to the"," server; it does so without knowing whether the server will be able to"," decrypt them. Similarly, this can happen when a server sends 1-RTT"," packets before confirming that the client has verified the server's"," certificate and can therefore read these 1-RTT packets.","",[[[],0," "],[[711,1206],161,"A sender SHOULD restart its PTO timer every time an ack-eliciting"]],[[[],0," "],[[711,1206],161,"packet is sent or acknowledged, or when Initial or Handshake keys are"]],[[[],0," "],[[711,1206],161,"discarded (Section 4.9 of [QUIC-TLS])."],[[],0," This ensures the PTO is"]]," always set based on the latest estimate of the RTT and for the"," correct packet across packet number spaces.","",[[[],0," "],[[712,2179,2425],240,"When a PTO timer expires, the PTO backoff MUST be increased,"]],[[[],0," "],[[712,2179,2425],240,"resulting in the PTO period being set to twice its current value."]]," The PTO backoff factor is reset when an acknowledgment is received,"," except in the following case. A server might take longer to respond"," to packets during the handshake than otherwise. To protect such a"," server from repeated client probes, the PTO backoff is not reset at a"," client that is not yet certain that the server has finished"," validating the client's address. That is, a client does not reset"," the PTO backoff factor on receiving acknowledgments in Initial"," packets.",""," This exponential reduction in the sender's rate is important because"," consecutive PTOs might be caused by loss of packets or"," acknowledgments due to severe congestion. Even when there are ack-"," eliciting packets in flight in multiple packet number spaces, the"," exponential increase in PTO occurs across all spaces to prevent"," excess load on the network. For example, a timeout in the Initial"," packet number space doubles the length of the timeout in the"," Handshake packet number space.",""," The total length of time over which consecutive PTOs expire is"," limited by the idle timeout.","",[[[],0," "],[[713,2168],240,"The PTO timer MUST NOT be set if a timer is set for time threshold"]],[[[],0," "],[[713,2168],240,"loss detection; see Section 6.1.2."],[[],0," A timer that is set for time"]]," threshold loss detection will expire earlier than the PTO timer in"," most cases and is less likely to spuriously retransmit data."],"requirements":[708,709,710,711,712,713]},{"id":"section-6.2.2","title":"Handshakes and New Paths","lines":[[[[],0," "],[[717,1208],97,"Resumed connections over the same network MAY use the previous"]],[[[],0," "],[[717,1208],97,"connection's final smoothed RTT value as the resumed connection's"]],[[[],0," "],[[717,1208],97,"initial RTT."],[[],0," "],[[718,2438,3073],180,"When no previous RTT is available, the initial RTT"]],[[[],0," "],[[718,2438,3073],180,"SHOULD be set to 333 milliseconds."],[[],0," This results in handshakes"]]," starting with a PTO of 1 second, as recommended for TCP's initial"," RTO; see Section 2 of [RFC6298].","",[[[],0," "],[[719,1209],161,"A connection MAY use the delay between sending a PATH_CHALLENGE and"]],[[[],0," "],[[719,1209],161,"receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in"]],[[[],0," "],[[719,1209],161,"Appendix A.2) for a new path, but the delay SHOULD NOT be considered"]],[[[],0," "],[[719,1209],161,"an RTT sample."]],""," When the Initial keys and Handshake keys are discarded (see"," Section 6.4), any Initial packets and Handshake packets can no longer",[[[],0," be acknowledged, so they are removed from bytes in flight. "],[[720,1996,1997],240,"When"]],[[[],0," "],[[720,1996,1997],240,"Initial or Handshake keys are discarded, the PTO and loss detection"]],[[[],0," "],[[720,1996,1997],240,"timers MUST be reset, because discarding keys indicates forward"]],[[[],0," "],[[720,1996,1997],240,"progress and the loss detection timer might have been set for a now-"]],[[[],0," "],[[720,1996,1997],240,"discarded packet number space."]]],"requirements":[717,718,719,720]},{"id":"section-6.2.2.1","title":"Before Address Validation","lines":[" Until the server has validated the client's address on the path, the"," amount of data it can send is limited to three times the amount of",[[[],0," data received, as specified in Section 8.1 of [QUIC-TRANSPORT]. "],[[714,2169],240,"If"]],[[[],0," "],[[714,2169],240,"no additional data can be sent, the server's PTO timer MUST NOT be"]],[[[],0," "],[[714,2169],240,"armed until datagrams have been received from the client because"]],[[[],0," "],[[714,2169],240,"packets sent on PTO count against the anti-amplification limit."]],""," When the server receives a datagram from the client, the"," amplification limit is increased and the server resets the PTO timer."," If the PTO timer is then set to a time in the past, it is executed"," immediately. Doing so avoids sending new 1-RTT packets prior to"," packets critical to the completion of the handshake. In particular,"," this can happen when 0-RTT is accepted but the server fails to"," validate the client's address.",""," Since the server could be blocked until more datagrams are received"," from the client, it is the client's responsibility to send packets to"," unblock the server until it is certain that the server has finished",[[[],0," its address validation (see Section 8 of [QUIC-TRANSPORT]). "],[[715,1207],225,"That is,"]],[[[],0," "],[[715,1207],225,"the client MUST set the PTO timer if the client has not received an"]],[[[],0," "],[[715,1207],225,"acknowledgment for any of its Handshake packets and the handshake is"]],[[[],0," "],[[715,1207],225,"not confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no"]],[[[],0," "],[[715,1207],225,"packets in flight."],[[],0," "],[[716,2180],240,"When the PTO fires, the client MUST send a"]],[[[],0," "],[[716,2180],240,"Handshake packet if it has Handshake keys, otherwise it MUST send an"]],[[[],0," "],[[716,2180],240,"Initial packet in a UDP datagram with a payload of at least 1200"]],[[[],0," "],[[716,2180],240,"bytes."]]],"requirements":[714,715,716]},{"id":"section-6.2.3","title":"Speeding up Handshake Completion","lines":[" When a server receives an Initial packet containing duplicate CRYPTO"," data, it can assume the client did not receive all of the server's"," CRYPTO data sent in Initial packets, or the client's estimated RTT is"," too small. When a client receives Handshake or 1-RTT packets prior"," to obtaining Handshake keys, it may assume some or all of the"," server's Initial packets were lost.","",[[[],0," "],[[721,1210],97,"To speed up handshake completion under these conditions, an endpoint"]],[[[],0," "],[[721,1210],97,"MAY, for a limited number of times per connection, send a packet"]],[[[],0," "],[[721,1210],97,"containing unacknowledged CRYPTO data earlier than the PTO expiry,"]],[[[],0," "],[[721,1210],97,"subject to the address validation limits in Section 8.1 of"]],[[[],0," "],[[721,1210],97,"[QUIC-TRANSPORT]."],[[],0," Doing so at most once for each connection is"]]," adequate to quickly recover from a single packet loss. An endpoint"," that always retransmits packets in response to receiving packets that"," it cannot process risks creating an infinite exchange of packets.",""," Endpoints can also use coalesced packets (see Section 12.2 of"," [QUIC-TRANSPORT]) to ensure that each datagram elicits at least one"," acknowledgment. For example, a client can coalesce an Initial packet"," containing PING and PADDING frames with a 0-RTT data packet, and a"," server can coalesce an Initial packet containing a PING frame with"," one or more packets in its first flight."],"requirements":[721]},{"id":"section-6.2.4","title":"Sending Probe Packets","lines":[[[[],0," "],[[722,2177],240,"When a PTO timer expires, a sender MUST send at least one ack-"]],[[[],0," "],[[722,2177],240,"eliciting packet in the packet number space as a probe."],[[],0," "],[[723,2182],112,"An endpoint"]],[[[],0," "],[[723,2182],112,"MAY send up to two full-sized datagrams containing ack-eliciting"]],[[[],0," "],[[723,2182],112,"packets to avoid an expensive consecutive PTO expiration due to a"]],[[[],0," "],[[723,2182],112,"single lost datagram or to transmit data from multiple packet number"]],[[[],0," "],[[723,2182],112,"spaces."],[[],0," "],[[724,1217,2576],229,"All probe packets sent on a PTO MUST be ack-eliciting."]],"",[[[],0," "],[[725,2181],176,"In addition to sending data in the packet number space for which the"]],[[[],0," "],[[725,2181],176,"timer expired, the sender SHOULD send ack-eliciting packets from"]],[[[],0," "],[[725,2181],176,"other packet number spaces with in-flight data, coalescing packets if"]],[[[],0," "],[[725,2181],176,"possible."],[[],0," This is particularly valuable when the server has both"]]," Initial and Handshake data in flight or when the client has both"," Handshake and Application Data in flight because the peer might only"," have receive keys for one of the two packet number spaces.",""," If the sender wants to elicit a faster acknowledgment on PTO, it can"," skip a packet number to eliminate the acknowledgment delay.","",[[[],0," "],[[726,1218],161,"An endpoint SHOULD include new data in packets that are sent on PTO"]],[[[],0," "],[[726,1218],161,"expiration."],[[],0," "],[[727,2183],112,"Previously sent data MAY be sent if no new data can be"]],[[[],0," "],[[727,2183],112,"sent."],[[],0," "],[[728,1219],97,"Implementations MAY use alternative strategies for determining"]],[[[],0," "],[[728,1219],97,"the content of probe packets, including sending new or retransmitted"]],[[[],0," "],[[728,1219],97,"data based on the application's priorities."]],""," It is possible the sender has no new or previously sent data to send."," As an example, consider the following sequence of events: new"," application data is sent in a STREAM frame, deemed lost, then"," retransmitted in a new packet, and then the original transmission is",[[[],0," acknowledged. "],[[729,2184,2543],180,"When there is no data to send, the sender SHOULD send"]],[[[],0," "],[[729,2184,2543],180,"a PING or other ack-eliciting frame in a single packet, rearming the"]],[[[],0," "],[[729,2184,2543],180,"PTO timer."]],"",[[[],0," "],[[730,1220],97,"Alternatively, instead of sending an ack-eliciting packet, the sender"]],[[[],0," "],[[730,1220],97,"MAY mark any packets still in flight as lost."],[[],0," Doing so avoids"]]," sending an additional packet but increases the risk that loss is"," declared too aggressively, resulting in an unnecessary rate reduction"," by the congestion controller.",""," Consecutive PTO periods increase exponentially, and as a result,"," connection recovery latency increases exponentially as packets"," continue to be dropped in the network. Sending two packets on PTO"," expiration increases resilience to packet drops, thus reducing the"," probability of consecutive PTO events.",""," When the PTO timer expires multiple times and new data cannot be"," sent, implementations must choose between sending the same payload"," every time or sending different payloads. Sending the same payload"," may be simpler and ensures the highest priority frames arrive first."," Sending different payloads each time reduces the chances of spurious"," retransmission."],"requirements":[722,723,724,725,726,727,728,729,730]},{"id":"section-6.3","title":"Handling Retry Packets","lines":[" A Retry packet causes a client to send another Initial packet,"," effectively restarting the connection process. A Retry packet"," indicates that the Initial packet was received but not processed. A"," Retry packet cannot be treated as an acknowledgment because it does"," not indicate that a packet was processed or specify the packet"," number.",""," Clients that receive a Retry packet reset congestion control and loss"," recovery state, including resetting any pending timers. Other"," connection state, in particular cryptographic handshake messages, is"," retained; see Section 17.2.5 of [QUIC-TRANSPORT].","",[[[],0," "],[[732,1222],97,"The client MAY compute an RTT estimate to the server as the time"]],[[[],0," "],[[732,1222],97,"period from when the first Initial packet was sent to when a Retry or"]],[[[],0," "],[[732,1222],97,"a Version Negotiation packet is received."],[[],0," "],[[733,1223],97,"The client MAY use this"]],[[[],0," "],[[733,1223],97,"value in place of its default for the initial RTT estimate."]]],"requirements":[732,733]},{"id":"section-6.4","title":"Discarding Keys and Packet State","lines":[" When Initial and Handshake packet protection keys are discarded (see"," Section 4.9 of [QUIC-TLS]), all packets that were sent with those"," keys can no longer be acknowledged because their acknowledgments",[[[],0," cannot be processed. "],[[734,1992,1993],240,"The sender MUST discard all recovery state"]],[[[],0," "],[[734,1992,1993],240,"associated with those packets and MUST remove them from the count of"]],[[[],0," "],[[734,1992,1993],240,"bytes in flight."]],""," Endpoints stop sending and receiving Initial packets once they start"," exchanging Handshake packets; see Section 17.2.2.1 of"," [QUIC-TRANSPORT]. At this point, recovery state for all in-flight"," Initial packets is discarded.",""," When 0-RTT is rejected, recovery state for all in-flight 0-RTT"," packets is discarded.",""," If a server accepts 0-RTT, but does not buffer 0-RTT packets that"," arrive before Initial packets, early 0-RTT packets will be declared"," lost, but that is expected to be infrequent.",""," It is expected that keys are discarded at some time after the packets"," encrypted with them are either acknowledged or declared lost."," However, Initial and Handshake secrets are discarded as soon as"," Handshake and 1-RTT keys are proven to be available to both client"," and server; see Section 4.9.1 of [QUIC-TLS]."],"requirements":[734]},{"id":"section-7","title":"Congestion Control","lines":[" This document specifies a sender-side congestion controller for QUIC"," similar to TCP NewReno [RFC6582].",""," The signals QUIC provides for congestion control are generic and are"," designed to support different sender-side algorithms. A sender can"," unilaterally choose a different algorithm to use, such as CUBIC"," [RFC8312].","",[[[],0," "],[[762,1204],225,"If a sender uses a different controller than that specified in this"]],[[[],0," "],[[762,1204],225,"document, the chosen controller MUST conform to the congestion"]],[[[],0," "],[[762,1204],225,"control guidelines specified in Section 3.1 of [RFC8085]."]],"",[[[],0," "],[[1605],16,"Similar to TCP, packets containing only ACK frames do not count"]],[[[],0," "],[[1605],16,"toward bytes in flight and are not congestion controlled."],[[],0," "],[[763,1205],97,"Unlike"]],[[[],0," "],[[763,1205],97,"TCP, QUIC can detect the loss of these packets and MAY use that"]],[[[],0," "],[[763,1205],97,"information to adjust the congestion controller or the rate of ACK-"]],[[[],0," "],[[763,1205],97,"only packets being sent, but this document does not describe a"]],[[[],0," "],[[763,1205],97,"mechanism for doing so."]],""," The congestion controller is per path, so packets sent on other paths"," do not alter the current path's congestion controller, as described"," in Section 9.4 of [QUIC-TRANSPORT].",""," The algorithm in this document specifies and uses the controller's"," congestion window in bytes.","",[[[],0," "],[[764,2164],240,"An endpoint MUST NOT send a packet if it would cause bytes_in_flight"]],[[[],0," "],[[764,2164],240,"(see Appendix B.2) to be larger than the congestion window, unless"]],[[[],0," "],[[764,2164],240,"the packet is sent on a PTO timer expiration (see Section 6.2) or"]],[[[],0," "],[[764,2164],240,"when entering recovery (see Section 7.3.2)."]]],"requirements":[762,763,764]},{"id":"section-7.1","title":"Explicit Congestion Notification","lines":[" If a path has been validated to support Explicit Congestion"," Notification (ECN) [RFC3168] [RFC8311], QUIC treats a Congestion"," Experienced (CE) codepoint in the IP header as a signal of"," congestion. This document specifies an endpoint's response when the"," peer-reported ECN-CE count increases; see Section 13.4.2 of"," [QUIC-TRANSPORT]."]},{"id":"section-7.2","title":"Initial and Minimum Congestion Window","lines":[" QUIC begins every connection in slow start with the congestion window",[[[],0," set to an initial value. "],[[735,1602],176,"Endpoints SHOULD use an initial congestion"]],[[[],0," "],[[735,1602],176,"window of ten times the maximum datagram size (max_datagram_size),"]],[[[],0," "],[[735,1602],176,"while limiting the window to the larger of 14,720 bytes or twice the"]],[[[],0," "],[[735,1602],176,"maximum datagram size."],[[],0," This follows the analysis and recommendations"]]," in [RFC6928], increasing the byte limit to account for the smaller"," 8-byte overhead of UDP compared to the 20-byte overhead for TCP.","",[[[],0," "],[[736,1213],161,"If the maximum datagram size changes during the connection, the"]],[[[],0," "],[[736,1213],161,"initial congestion window SHOULD be recalculated with the new size."]],[[[],0," "],[[737,1214],161,"If the maximum datagram size is decreased in order to complete the"]],[[[],0," "],[[737,1214],161,"handshake, the congestion window SHOULD be set to the new initial"]],[[[],0," "],[[737,1214],161,"congestion window."]],""," Prior to validating the client's address, the server can be further"," limited by the anti-amplification limit as specified in Section 8.1"," of [QUIC-TRANSPORT]. Though the anti-amplification limit can prevent"," the congestion window from being fully utilized and therefore slow"," down the increase in congestion window, it does not directly affect"," the congestion window.",""," The minimum congestion window is the smallest value the congestion"," window can attain in response to loss, an increase in the peer-",[[[],0," reported ECN-CE count, or persistent congestion. "],[[738,1615],176,"The RECOMMENDED"]],[[[],0," "],[[738,1615],176,"value is 2 * max_datagram_size."]]],"requirements":[735,736,737,738]},{"id":"section-7.3","title":"Congestion Control States","lines":[" The NewReno congestion controller described in this document has"," three distinct states, as shown in Figure 1.",""," New path or +------------+"," persistent congestion | Slow |"," (O)---------------------->| Start |"," +------------+"," |"," Loss or |"," ECN-CE increase |"," v"," +------------+ Loss or +------------+"," | Congestion | ECN-CE increase | Recovery |"," | Avoidance |------------------>| Period |"," +------------+ +------------+"," ^ |"," | |"," +----------------------------+"," Acknowledgment of packet"," sent during recovery",""," Figure 1: Congestion Control States and Transitions",""," These states and the transitions between them are described in"," subsequent sections."]},{"id":"section-7.3.1","title":"Slow Start","lines":[" A NewReno sender is in slow start any time the congestion window is"," below the slow start threshold. A sender begins in slow start"," because the slow start threshold is initialized to an infinite value.","",[[[],0," "],[[1606,1608],16,"While a sender is in slow start, the congestion window increases by"]],[[[],0," "],[[1606,1608],16,"the number of bytes acknowledged when each acknowledgment is"]],[[[],0," "],[[1606,1608],16,"processed."],[[],0," This results in exponential growth of the congestion"]]," window.","",[[[],0," "],[[739,1603,1611],240,"The sender MUST exit slow start and enter a recovery period when a"]],[[[],0," "],[[739,1603,1611],240,"packet is lost or when the ECN-CE count reported by its peer"]],[[[],0," "],[[739,1603,1611],240,"increases."]],""," A sender reenters slow start any time the congestion window is less"," than the slow start threshold, which only occurs after persistent"," congestion is declared."],"requirements":[739]},{"id":"section-7.3.2","title":"Recovery","lines":[" A NewReno sender enters a recovery period when it detects the loss of",[[[],0," a packet or when the ECN-CE count reported by its peer increases. "],[[],0,"A"]],[[[],0," "],[[1610],16,"sender that is already in a recovery period stays in it and does not"]],[[[],0," "],[[1610],16,"reenter it."]],"",[[[],0," "],[[740,1612],240,"On entering a recovery period, a sender MUST set the slow start"]],[[[],0," "],[[740,1612],240,"threshold to half the value of the congestion window when loss is"]],[[[],0," "],[[740,1612],240,"detected."],[[],0," "],[[741,1613],240,"The congestion window MUST be set to the reduced value of"]],[[[],0," "],[[741,1613],240,"the slow start threshold before exiting the recovery period."]],"",[[[],0," "],[[742,1616],112,"Implementations MAY reduce the congestion window immediately upon"]],[[[],0," "],[[742,1616],112,"entering a recovery period or use other mechanisms, such as"]],[[[],0," "],[[742,1616],112,"Proportional Rate Reduction [PRR], to reduce the congestion window"]],[[[],0," "],[[742,1616],112,"more gradually."],[[],0," If the congestion window is reduced immediately, a"]]," single packet can be sent prior to reduction. This speeds up loss"," recovery if the data in the lost packet is retransmitted and is"," similar to TCP as described in Section 5 of [RFC6675].",""," The recovery period aims to limit congestion window reduction to once"," per round trip. Therefore, during a recovery period, the congestion"," window does not change in response to new losses or increases in the"," ECN-CE count.",""," A recovery period ends and the sender enters congestion avoidance"," when a packet sent during the recovery period is acknowledged. This"," is slightly different from TCP's definition of recovery, which ends"," when the lost segment that started recovery is acknowledged"," [RFC5681]."],"requirements":[740,741,742]},{"id":"section-7.3.3","title":"Congestion Avoidance","lines":[" A NewReno sender is in congestion avoidance any time the congestion"," window is at or above the slow start threshold and not in a recovery"," period.","",[[[],0," "],[[743,1607,1609],240,"A sender in congestion avoidance uses an Additive Increase"]],[[[],0," "],[[743,1607,1609],240,"Multiplicative Decrease (AIMD) approach that MUST limit the increase"]],[[[],0," "],[[743,1607,1609],240,"to the congestion window to at most one maximum datagram size for"]],[[[],0," "],[[743,1607,1609],240,"each congestion window that is acknowledged."]],""," The sender exits congestion avoidance and enters a recovery period"," when a packet is lost or when the ECN-CE count reported by its peer"," increases."],"requirements":[743]},{"id":"section-7.4","title":"Ignoring Loss of Undecryptable Packets","lines":[" During the handshake, some packet protection keys might not be"," available when a packet arrives, and the receiver can choose to drop"," the packet. In particular, Handshake and 0-RTT packets cannot be"," processed until the Initial packets arrive, and 1-RTT packets cannot",[[[],0," be processed until the handshake completes. "],[[744,1211],97,"Endpoints MAY ignore the"]],[[[],0," "],[[744,1211],97,"loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived"]],[[[],0," "],[[744,1211],97,"before the peer had packet protection keys to process those packets."]],[[[],0," "],[[745,1212],225,"Endpoints MUST NOT ignore the loss of packets that were sent after"]],[[[],0," "],[[745,1212],225,"the earliest acknowledged packet in a given packet number space."]]],"requirements":[744,745]},{"id":"section-7.5","title":"Probe Timeout","lines":[[[[],0," "],[[746,2016,2161],240,"Probe packets MUST NOT be blocked by the congestion controller."],[[],0," "],[[],0,"A"]],[[[],0," "],[[747,2095],240,"sender MUST however count these packets as being additionally in"]],[[[],0," "],[[747,2095],240,"flight, since these packets add network load without establishing"]],[[[],0," "],[[747,2095],240,"packet loss."],[[],0," Note that sending probe packets might cause the"]]," sender's bytes in flight to exceed the congestion window until an"," acknowledgment is received that establishes loss or delivery of"," packets."],"requirements":[746,747]},{"id":"section-7.6","title":"Persistent Congestion","lines":[" When a sender establishes loss of all packets sent over a long enough"," duration, the network is considered to be experiencing persistent"," congestion."]},{"id":"section-7.6.1","title":"Duration","lines":[" The persistent congestion duration is computed as follows:",""," (smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *"," kPersistentCongestionThreshold",""," Unlike the PTO computation in Section 6.2, this duration includes the"," max_ack_delay irrespective of the packet number spaces in which"," losses are established.",""," This duration allows a sender to send as many packets before"," establishing persistent congestion, including some in response to PTO"," expiration, as TCP does with Tail Loss Probes [RFC8985] and an RTO"," [RFC5681].",""," Larger values of kPersistentCongestionThreshold cause the sender to"," become less responsive to persistent congestion in the network, which"," can result in aggressive sending into a congested network. Too small"," a value can result in a sender declaring persistent congestion"," unnecessarily, resulting in reduced throughput for the sender.","",[[[],0," "],[[748,1844],176,"The RECOMMENDED value for kPersistentCongestionThreshold is 3, which"]],[[[],0," "],[[748,1844],176,"results in behavior that is approximately equivalent to a TCP sender"]],[[[],0," "],[[748,1844],176,"declaring an RTO after two TLPs."]],""," This design does not use consecutive PTO events to establish"," persistent congestion, since application patterns impact PTO"," expiration. For example, a sender that sends small amounts of data"," with silence periods between them restarts the PTO timer every time"," it sends, potentially preventing the PTO timer from expiring for a"," long period of time, even when no acknowledgments are being received."," The use of a duration enables a sender to establish persistent"," congestion without depending on PTO expiration."],"requirements":[748]},{"id":"section-7.6.2","title":"Establishing Persistent Congestion","lines":[" A sender establishes persistent congestion after the receipt of an"," acknowledgment if two packets that are ack-eliciting are declared"," lost, and:",""," * across all packet number spaces, none of the packets sent between"," the send times of these two packets are acknowledged;",""," * the duration between the send times of these two packets exceeds"," the persistent congestion duration (Section 7.6.1); and",""," * a prior RTT sample existed when these two packets were sent.","",[[[],0," "],[[749,1904],240,"These two packets MUST be ack-eliciting, since a receiver is required"]],[[[],0," "],[[749,1904],240,"to acknowledge only ack-eliciting packets within its maximum"]],[[[],0," "],[[749,1904],240,"acknowledgment delay; see Section 13.2 of [QUIC-TRANSPORT]."]],"",[[[],0," "],[[750,1903],176,"The persistent congestion period SHOULD NOT start until there is at"]],[[[],0," "],[[750,1903],176,"least one RTT sample."],[[],0," Before the first RTT sample, a sender arms its"]]," PTO timer based on the initial RTT (Section 6.2.2), which could be"," substantially larger than the actual RTT. Requiring a prior RTT"," sample prevents a sender from establishing persistent congestion with"," potentially too few probes.","",[[[],0," "],[[751,1215],161,"Since network congestion is not affected by packet number spaces,"]],[[[],0," "],[[751,1215],161,"persistent congestion SHOULD consider packets sent across packet"]],[[[],0," "],[[751,1215],161,"number spaces."],[[],0," "],[[752,1216],97,"A sender that does not have state for all packet"]],[[[],0," "],[[752,1216],97,"number spaces or an implementation that cannot compare send times"]],[[[],0," "],[[752,1216],97,"across packet number spaces MAY use state for just the packet number"]],[[[],0," "],[[752,1216],97,"space that was acknowledged."],[[],0," This might result in erroneously"]]," declaring persistent congestion, but it will not lead to a failure to"," detect persistent congestion.","",[[[],0," "],[[753,1601,1614,2175],240,"When persistent congestion is declared, the sender's congestion"]],[[[],0," "],[[753,1601,1614,2175],240,"window MUST be reduced to the minimum congestion window"]],[[[],0," "],[[753,1601],240,"(kMinimumWindow), similar to a TCP sender's response on an RTO"]],[[[],0," "],[[753,1601],240,"[RFC5681]."]]],"requirements":[749,750,751,752,753]},{"id":"section-7.6.3","title":"Example","lines":[" The following example illustrates how a sender might establish"," persistent congestion. Assume:",""," smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2"," kPersistentCongestionThreshold = 3",""," Consider the following sequence of events:",""," +========+===================================+"," | Time | Action |"," +========+===================================+"," | t=0 | Send packet #1 (application data) |"," +--------+-----------------------------------+"," | t=1 | Send packet #2 (application data) |"," +--------+-----------------------------------+"," | t=1.2 | Receive acknowledgment of #1 |"," +--------+-----------------------------------+"," | t=2 | Send packet #3 (application data) |"," +--------+-----------------------------------+"," | t=3 | Send packet #4 (application data) |"," +--------+-----------------------------------+"," | t=4 | Send packet #5 (application data) |"," +--------+-----------------------------------+"," | t=5 | Send packet #6 (application data) |"," +--------+-----------------------------------+"," | t=6 | Send packet #7 (application data) |"," +--------+-----------------------------------+"," | t=8 | Send packet #8 (PTO 1) |"," +--------+-----------------------------------+"," | t=12 | Send packet #9 (PTO 2) |"," +--------+-----------------------------------+"," | t=12.2 | Receive acknowledgment of #9 |"," +--------+-----------------------------------+",""," Table 1",""," Packets 2 through 8 are declared lost when the acknowledgment for"," packet 9 is received at \"t = 12.2\".",""," The congestion period is calculated as the time between the oldest"," and newest lost packets: \"8 - 1 = 7\". The persistent congestion"," duration is \"2 * 3 = 6\". Because the threshold was reached and"," because none of the packets between the oldest and the newest lost"," packets were acknowledged, the network is considered to have"," experienced persistent congestion.",""," While this example shows PTO expiration, they are not required for"," persistent congestion to be established."]},{"id":"section-7.7","title":"Pacing","lines":[[[[],0," "],[[754,2166],176,"A sender SHOULD pace sending of all in-flight packets based on input"]],[[[],0," "],[[754,2166],176,"from the congestion controller."]],""," Sending multiple packets into the network without any delay between"," them creates a packet burst that might cause short-term congestion",[[[],0," and losses. "],[[755,2167],240,"Senders MUST either use pacing or limit such bursts."]],[[[],0," "],[[756,1604,1617],176,"Senders SHOULD limit bursts to the initial congestion window; see"]],[[[],0," "],[[756,1604,1617],176,"Section 7.2."],[[],0," "],[[757,1200],97,"A sender with knowledge that the network path to the"]],[[[],0," "],[[757,1200],97,"receiver can absorb larger bursts MAY use a higher limit."]],""," An implementation should take care to architect its congestion"," controller to work well with a pacer. For instance, a pacer might"," wrap the congestion controller and control the availability of the"," congestion window, or a pacer might pace out packets handed to it by"," the congestion controller.",""," Timely delivery of ACK frames is important for efficient loss",[[[],0," recovery. "],[[758,2132],176,"To avoid delaying their delivery to the peer, packets"]],[[[],0," "],[[758,2132],176,"containing only ACK frames SHOULD therefore not be paced."]],""," Endpoints can implement pacing as they choose. A perfectly paced"," sender spreads packets exactly evenly over time. For a window-based"," congestion controller, such as the one in this document, that rate"," can be computed by averaging the congestion window over the RTT."," Expressed as a rate in units of bytes per time, where"," congestion_window is in bytes:",""," rate = N * congestion_window / smoothed_rtt",""," Or expressed as an inter-packet interval in units of time:",""," interval = ( smoothed_rtt * packet_size / congestion_window ) / N",""," Using a value for \"N\" that is small, but at least 1 (for example,"," 1.25) ensures that variations in RTT do not result in"," underutilization of the congestion window.",""," Practical considerations, such as packetization, scheduling delays,"," and computational efficiency, can cause a sender to deviate from this"," rate over time periods that are much shorter than an RTT.",""," One possible implementation strategy for pacing uses a leaky bucket"," algorithm, where the capacity of the \"bucket\" is limited to the"," maximum burst size and the rate the \"bucket\" fills is determined by"," the above function."],"requirements":[754,755,756,757,758]},{"id":"section-7.8","title":"Underutilizing the Congestion Window","lines":[" When bytes in flight is smaller than the congestion window and"," sending is not pacing limited, the congestion window is"," underutilized. This can happen due to insufficient application data",[[[],0," or flow control limits. "],[[759,1201],161,"When this occurs, the congestion window"]],[[[],0," "],[[759,1201],161,"SHOULD NOT be increased in either slow start or congestion avoidance."]],""," A sender that paces packets (see Section 7.7) might delay sending"," packets and not fully utilize the congestion window due to this",[[[],0," delay. "],[[760,1202],161,"A sender SHOULD NOT consider itself application limited if it"]],[[[],0," "],[[760,1202],161,"would have fully utilized the congestion window without pacing delay."]],"",[[[],0," "],[[761,1203],97,"A sender MAY implement alternative mechanisms to update its"]],[[[],0," "],[[761,1203],97,"congestion window after periods of underutilization, such as those"]],[[[],0," "],[[761,1203],97,"proposed for TCP in [RFC7661]."]]],"requirements":[759,760,761]},{"id":"section-8","title":"Security Considerations","lines":[]},{"id":"section-8.1","title":"Loss and Congestion Signals","lines":[" Loss detection and congestion control fundamentally involve the"," consumption of signals, such as delay, loss, and ECN markings, from"," unauthenticated entities. An attacker can cause endpoints to reduce"," their sending rate by manipulating these signals: by dropping"," packets, by altering path delay strategically, or by changing ECN"," codepoints."]},{"id":"section-8.2","title":"Traffic Analysis","lines":[" Packets that carry only ACK frames can be heuristically identified by"," observing packet size. Acknowledgment patterns may expose"," information about link characteristics or application behavior. To"," reduce leaked information, endpoints can bundle acknowledgments with"," other frames, or they can use PADDING frames at a potential cost to"," performance."]},{"id":"section-8.3","title":"Misreporting ECN Markings","lines":[" A receiver can misreport ECN markings to alter the congestion"," response of a sender. Suppressing reports of ECN-CE markings could"," cause a sender to increase their send rate. This increase could"," result in congestion and loss.",""," A sender can detect suppression of reports by marking occasional"," packets that it sends with an ECN-CE marking. If a packet sent with"," an ECN-CE marking is not reported as having been CE marked when the"," packet is acknowledged, then the sender can disable ECN for that path"," by not setting ECN-Capable Transport (ECT) codepoints in subsequent"," packets sent on that path [RFC3168].",""," Reporting additional ECN-CE markings will cause a sender to reduce"," their sending rate, which is similar in effect to advertising reduced"," connection flow control limits and so no advantage is gained by doing"," so.",""," Endpoints choose the congestion controller that they use. Congestion"," controllers respond to reports of ECN-CE by reducing their rate, but"," the response may vary. Markings can be treated as equivalent to loss"," [RFC3168], but other responses can be specified, such as [RFC8511] or"," [RFC8311]."]},{"id":"section-9","title":"References","lines":[]},{"id":"section-9.1","title":"Normative References","lines":[" [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., \"Using TLS to Secure"," QUIC\", RFC 9001, DOI 10.17487/RFC9001, May 2021,"," .",""," [QUIC-TRANSPORT]"," Iyengar, J., Ed. and M. Thomson, Ed., \"QUIC: A UDP-Based"," Multiplexed and Secure Transport\", RFC 9000,"," DOI 10.17487/RFC9000, May 2021,"," .",""," [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate"," Requirement Levels\", BCP 14, RFC 2119,"," DOI 10.17487/RFC2119, March 1997,"," .",""," [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, \"The Addition"," of Explicit Congestion Notification (ECN) to IP\","," RFC 3168, DOI 10.17487/RFC3168, September 2001,"," .",""," [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, \"UDP Usage"," Guidelines\", BCP 145, RFC 8085, DOI 10.17487/RFC8085,"," March 2017, .",""," [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC"," 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,"," May 2017, ."]},{"id":"section-9.2","title":"Informative References","lines":[" [FACK] Mathis, M. and J. Mahdavi, \"Forward acknowledgement:"," Refining TCP Congestion Control\", ACM SIGCOMM Computer"," Communication Review, DOI 10.1145/248157.248181, August"," 1996, .",""," [PRR] Mathis, M., Dukkipati, N., and Y. Cheng, \"Proportional"," Rate Reduction for TCP\", RFC 6937, DOI 10.17487/RFC6937,"," May 2013, .",""," [RETRANSMISSION]"," Karn, P. and C. Partridge, \"Improving Round-Trip Time"," Estimates in Reliable Transport Protocols\", ACM"," Transactions on Computer Systems,"," DOI 10.1145/118544.118549, November 1991,"," .",""," [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, \"TCP"," Selective Acknowledgment Options\", RFC 2018,"," DOI 10.17487/RFC2018, October 1996,"," .",""," [RFC3465] Allman, M., \"TCP Congestion Control with Appropriate Byte"," Counting (ABC)\", RFC 3465, DOI 10.17487/RFC3465, February"," 2003, .",""," [RFC5681] Allman, M., Paxson, V., and E. Blanton, \"TCP Congestion"," Control\", RFC 5681, DOI 10.17487/RFC5681, September 2009,"," .",""," [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata,"," \"Forward RTO-Recovery (F-RTO): An Algorithm for Detecting"," Spurious Retransmission Timeouts with TCP\", RFC 5682,"," DOI 10.17487/RFC5682, September 2009,"," .",""," [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and"," P. Hurtig, \"Early Retransmit for TCP and Stream Control"," Transmission Protocol (SCTP)\", RFC 5827,"," DOI 10.17487/RFC5827, May 2010,"," .",""," [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,"," \"Computing TCP's Retransmission Timer\", RFC 6298,"," DOI 10.17487/RFC6298, June 2011,"," .",""," [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, \"The"," NewReno Modification to TCP's Fast Recovery Algorithm\","," RFC 6582, DOI 10.17487/RFC6582, April 2012,"," .",""," [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,"," and Y. Nishida, \"A Conservative Loss Recovery Algorithm"," Based on Selective Acknowledgment (SACK) for TCP\","," RFC 6675, DOI 10.17487/RFC6675, August 2012,"," .",""," [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,"," \"Increasing TCP's Initial Window\", RFC 6928,"," DOI 10.17487/RFC6928, April 2013,"," .",""," [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, \"Updating"," TCP to Support Rate-Limited Traffic\", RFC 7661,"," DOI 10.17487/RFC7661, October 2015,"," .",""," [RFC8311] Black, D., \"Relaxing Restrictions on Explicit Congestion"," Notification (ECN) Experimentation\", RFC 8311,"," DOI 10.17487/RFC8311, January 2018,"," .",""," [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and"," R. Scheffenegger, \"CUBIC for Fast Long-Distance Networks\","," RFC 8312, DOI 10.17487/RFC8312, February 2018,"," .",""," [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,"," \"TCP Alternative Backoff with ECN (ABE)\", RFC 8511,"," DOI 10.17487/RFC8511, December 2018,"," .",""," [RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, \"The"," RACK-TLP Loss Detection Algorithm for TCP\", RFC 8985,"," DOI 10.17487/RFC8985, February 2021,"," ."]},{"id":"appendix-A","title":"Loss Recovery Pseudocode","lines":[" We now describe an example implementation of the loss detection"," mechanisms described in Section 6.",""," The pseudocode segments in this section are licensed as Code"," Components; see the copyright notice."]},{"id":"appendix-A.1","title":"Tracking Sent Packets","lines":[" To correctly implement congestion control, a QUIC sender tracks every"," ack-eliciting packet until the packet is acknowledged or lost. It is"," expected that implementations will be able to access this information"," by packet number and crypto context and store the per-packet fields"," (Appendix A.1.1) for loss recovery and congestion control.",""," After a packet is declared lost, the endpoint can still maintain"," state for it for an amount of time to allow for packet reordering;"," see Section 13.3 of [QUIC-TRANSPORT]. This enables a sender to"," detect spurious retransmissions.",""," Sent packets are tracked for each packet number space, and ACK"," processing only applies to a single space."]},{"id":"appendix-A.1.1","title":"Sent Packet Fields","lines":[" packet_number: The packet number of the sent packet.",""," ack_eliciting: A Boolean that indicates whether a packet is ack-"," eliciting. If true, it is expected that an acknowledgment will be"," received, though the peer could delay sending the ACK frame"," containing it by up to the max_ack_delay.",""," in_flight: A Boolean that indicates whether the packet counts toward"," bytes in flight.",""," sent_bytes: The number of bytes sent in the packet, not including"," UDP or IP overhead, but including QUIC framing overhead.",""," time_sent: The time the packet was sent."]},{"id":"appendix-A.2","title":"Constants of Interest","lines":[" Constants used in loss recovery are based on a combination of RFCs,"," papers, and common practice.",""," kPacketThreshold: Maximum reordering in packets before packet"," threshold loss detection considers a packet lost. The value"," recommended in Section 6.1.1 is 3.",""," kTimeThreshold: Maximum reordering in time before time threshold"," loss detection considers a packet lost. Specified as an RTT"," multiplier. The value recommended in Section 6.1.2 is 9/8.",""," kGranularity: Timer granularity. This is a system-dependent value,"," and Section 6.1.2 recommends a value of 1 ms.",""," kInitialRtt: The RTT used before an RTT sample is taken. The value"," recommended in Section 6.2.2 is 333 ms.",""," kPacketNumberSpace: An enum to enumerate the three packet number"," spaces:",""," enum kPacketNumberSpace {"," Initial,"," Handshake,"," ApplicationData,"," }"]},{"id":"appendix-A.3","title":"Variables of Interest","lines":[" Variables required to implement the congestion control mechanisms are"," described in this section.",""," latest_rtt: The most recent RTT measurement made when receiving an"," acknowledgment for a previously unacknowledged packet.",""," smoothed_rtt: The smoothed RTT of the connection, computed as"," described in Section 5.3.",""," rttvar: The RTT variation, computed as described in Section 5.3.",""," min_rtt: The minimum RTT seen over a period of time, ignoring"," acknowledgment delay, as described in Section 5.2.",""," first_rtt_sample: The time that the first RTT sample was obtained.",""," max_ack_delay: The maximum amount of time by which the receiver"," intends to delay acknowledgments for packets in the Application"," Data packet number space, as defined by the eponymous transport"," parameter (Section 18.2 of [QUIC-TRANSPORT]). Note that the"," actual ack_delay in a received ACK frame may be larger due to late"," timers, reordering, or loss.",""," loss_detection_timer: Multi-modal timer used for loss detection.",""," pto_count: The number of times a PTO has been sent without receiving"," an acknowledgment.",""," time_of_last_ack_eliciting_packet[kPacketNumberSpace]: The time the"," most recent ack-eliciting packet was sent.",""," largest_acked_packet[kPacketNumberSpace]: The largest packet number"," acknowledged in the packet number space so far.",""," loss_time[kPacketNumberSpace]: The time at which the next packet in"," that packet number space can be considered lost based on exceeding"," the reordering window in time.",""," sent_packets[kPacketNumberSpace]: An association of packet numbers"," in a packet number space to information about them. Described in"," detail above in Appendix A.1."]},{"id":"appendix-A.4","title":"Initialization","lines":[" At the beginning of the connection, initialize the loss detection"," variables as follows:",""," loss_detection_timer.reset()"," pto_count = 0"," latest_rtt = 0"," smoothed_rtt = kInitialRtt"," rttvar = kInitialRtt / 2"," min_rtt = 0"," first_rtt_sample = 0"," for pn_space in [ Initial, Handshake, ApplicationData ]:"," largest_acked_packet[pn_space] = infinite"," time_of_last_ack_eliciting_packet[pn_space] = 0"," loss_time[pn_space] = 0"]},{"id":"appendix-A.5","title":"On Sending a Packet","lines":[" After a packet is sent, information about the packet is stored. The"," parameters to OnPacketSent are described in detail above in"," Appendix A.1.1.",""," Pseudocode for OnPacketSent follows:",""," OnPacketSent(packet_number, pn_space, ack_eliciting,"," in_flight, sent_bytes):"," sent_packets[pn_space][packet_number].packet_number ="," packet_number"," sent_packets[pn_space][packet_number].time_sent = now()"," sent_packets[pn_space][packet_number].ack_eliciting ="," ack_eliciting"," sent_packets[pn_space][packet_number].in_flight = in_flight"," sent_packets[pn_space][packet_number].sent_bytes = sent_bytes"," if (in_flight):"," if (ack_eliciting):"," time_of_last_ack_eliciting_packet[pn_space] = now()"," OnPacketSentCC(sent_bytes)"," SetLossDetectionTimer()"]},{"id":"appendix-A.6","title":"On Receiving a Datagram","lines":[" When a server is blocked by anti-amplification limits, receiving a"," datagram unblocks it, even if none of the packets in the datagram are"," successfully processed. In such a case, the PTO timer will need to"," be rearmed.",""," Pseudocode for OnDatagramReceived follows:",""," OnDatagramReceived(datagram):"," // If this datagram unblocks the server, arm the"," // PTO timer to avoid deadlock."," if (server was at anti-amplification limit):"," SetLossDetectionTimer()"," if loss_detection_timer.timeout < now():"," // Execute PTO if it would have expired"," // while the amplification limit applied."," OnLossDetectionTimeout()"]},{"id":"appendix-A.7","title":"On Receiving an Acknowledgment","lines":[" When an ACK frame is received, it may newly acknowledge any number of"," packets.",""," Pseudocode for OnAckReceived and UpdateRtt follow:",""," IncludesAckEliciting(packets):"," for packet in packets:"," if (packet.ack_eliciting):"," return true"," return false",""," OnAckReceived(ack, pn_space):"," if (largest_acked_packet[pn_space] == infinite):"," largest_acked_packet[pn_space] = ack.largest_acked"," else:"," largest_acked_packet[pn_space] ="," max(largest_acked_packet[pn_space], ack.largest_acked)",""," // DetectAndRemoveAckedPackets finds packets that are newly"," // acknowledged and removes them from sent_packets."," newly_acked_packets ="," DetectAndRemoveAckedPackets(ack, pn_space)"," // Nothing to do if there are no newly acked packets."," if (newly_acked_packets.empty()):"," return",""," // Update the RTT if the largest acknowledged is newly acked"," // and at least one ack-eliciting was newly acked."," if (newly_acked_packets.largest().packet_number =="," ack.largest_acked &&"," IncludesAckEliciting(newly_acked_packets)):"," latest_rtt ="," now() - newly_acked_packets.largest().time_sent"," UpdateRtt(ack.ack_delay)",""," // Process ECN information if present."," if (ACK frame contains ECN information):"," ProcessECN(ack, pn_space)",""," lost_packets = DetectAndRemoveLostPackets(pn_space)"," if (!lost_packets.empty()):"," OnPacketsLost(lost_packets)"," OnPacketsAcked(newly_acked_packets)",""," // Reset pto_count unless the client is unsure if"," // the server has validated the client's address."," if (PeerCompletedAddressValidation()):"," pto_count = 0"," SetLossDetectionTimer()",""," UpdateRtt(ack_delay):"," if (first_rtt_sample == 0):"," min_rtt = latest_rtt"," smoothed_rtt = latest_rtt"," rttvar = latest_rtt / 2"," first_rtt_sample = now()"," return",""," // min_rtt ignores acknowledgment delay."," min_rtt = min(min_rtt, latest_rtt)"," // Limit ack_delay by max_ack_delay after handshake"," // confirmation."," if (handshake confirmed):"," ack_delay = min(ack_delay, max_ack_delay)",""," // Adjust for acknowledgment delay if plausible."," adjusted_rtt = latest_rtt"," if (latest_rtt >= min_rtt + ack_delay):"," adjusted_rtt = latest_rtt - ack_delay",""," rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt)"," smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt"]},{"id":"appendix-A.8","title":"Setting the Loss Detection Timer","lines":[" QUIC loss detection uses a single timer for all timeout loss"," detection. The duration of the timer is based on the timer's mode,"," which is set in the packet and timer events further below. The"," function SetLossDetectionTimer defined below shows how the single"," timer is set.",""," This algorithm may result in the timer being set in the past,"," particularly if timers wake up late. Timers set in the past fire"," immediately.",""," Pseudocode for SetLossDetectionTimer follows (where the \"^\" operator"," represents exponentiation):",""," GetLossTimeAndSpace():"," time = loss_time[Initial]"," space = Initial"," for pn_space in [ Handshake, ApplicationData ]:"," if (time == 0 || loss_time[pn_space] < time):"," time = loss_time[pn_space];"," space = pn_space"," return time, space",""," GetPtoTimeAndSpace():"," duration = (smoothed_rtt + max(4 * rttvar, kGranularity))"," * (2 ^ pto_count)"," // Anti-deadlock PTO starts from the current time"," if (no ack-eliciting packets in flight):"," assert(!PeerCompletedAddressValidation())"," if (has handshake keys):"," return (now() + duration), Handshake"," else:"," return (now() + duration), Initial"," pto_timeout = infinite"," pto_space = Initial"," for space in [ Initial, Handshake, ApplicationData ]:"," if (no ack-eliciting packets in flight in space):"," continue;"," if (space == ApplicationData):"," // Skip Application Data until handshake confirmed."," if (handshake is not confirmed):"," return pto_timeout, pto_space"," // Include max_ack_delay and backoff for Application Data."," duration += max_ack_delay * (2 ^ pto_count)",""," t = time_of_last_ack_eliciting_packet[space] + duration"," if (t < pto_timeout):"," pto_timeout = t"," pto_space = space"," return pto_timeout, pto_space",""," PeerCompletedAddressValidation():"," // Assume clients validate the server's address implicitly."," if (endpoint is server):"," return true"," // Servers complete address validation when a"," // protected packet is received."," return has received Handshake ACK ||"," handshake confirmed",""," SetLossDetectionTimer():"," earliest_loss_time, _ = GetLossTimeAndSpace()"," if (earliest_loss_time != 0):"," // Time threshold loss detection."," loss_detection_timer.update(earliest_loss_time)"," return",""," if (server is at anti-amplification limit):"," // The server's timer is not set if nothing can be sent."," loss_detection_timer.cancel()"," return",""," if (no ack-eliciting packets in flight &&"," PeerCompletedAddressValidation()):"," // There is nothing to detect lost, so no timer is set."," // However, the client needs to arm the timer if the"," // server might be blocked by the anti-amplification limit."," loss_detection_timer.cancel()"," return",""," timeout, _ = GetPtoTimeAndSpace()"," loss_detection_timer.update(timeout)"]},{"id":"appendix-A.9","title":"On Timeout","lines":[" When the loss detection timer expires, the timer's mode determines"," the action to be performed.",""," Pseudocode for OnLossDetectionTimeout follows:",""," OnLossDetectionTimeout():"," earliest_loss_time, pn_space = GetLossTimeAndSpace()"," if (earliest_loss_time != 0):"," // Time threshold loss Detection"," lost_packets = DetectAndRemoveLostPackets(pn_space)"," assert(!lost_packets.empty())"," OnPacketsLost(lost_packets)"," SetLossDetectionTimer()"," return",""," if (no ack-eliciting packets in flight):"," assert(!PeerCompletedAddressValidation())"," // Client sends an anti-deadlock packet: Initial is padded"," // to earn more anti-amplification credit,"," // a Handshake packet proves address ownership."," if (has Handshake keys):"," SendOneAckElicitingHandshakePacket()"," else:"," SendOneAckElicitingPaddedInitialPacket()"," else:"," // PTO. Send new data if available, else retransmit old data."," // If neither is available, send a single PING frame."," _, pn_space = GetPtoTimeAndSpace()"," SendOneOrTwoAckElicitingPackets(pn_space)",""," pto_count++"," SetLossDetectionTimer()"]},{"id":"appendix-A.10","title":"Detecting Lost Packets","lines":[" DetectAndRemoveLostPackets is called every time an ACK is received or"," the time threshold loss detection timer expires. This function"," operates on the sent_packets for that packet number space and returns"," a list of packets newly detected as lost.",""," Pseudocode for DetectAndRemoveLostPackets follows:",""," DetectAndRemoveLostPackets(pn_space):"," assert(largest_acked_packet[pn_space] != infinite)"," loss_time[pn_space] = 0"," lost_packets = []"," loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt)",""," // Minimum time of kGranularity before packets are deemed lost."," loss_delay = max(loss_delay, kGranularity)",""," // Packets sent before this time are deemed lost."," lost_send_time = now() - loss_delay",""," foreach unacked in sent_packets[pn_space]:"," if (unacked.packet_number > largest_acked_packet[pn_space]):"," continue",""," // Mark packet as lost, or set time when it should be marked."," // Note: The use of kPacketThreshold here assumes that there"," // were no sender-induced gaps in the packet number space."," if (unacked.time_sent <= lost_send_time ||"," largest_acked_packet[pn_space] >="," unacked.packet_number + kPacketThreshold):"," sent_packets[pn_space].remove(unacked.packet_number)"," lost_packets.insert(unacked)"," else:"," if (loss_time[pn_space] == 0):"," loss_time[pn_space] = unacked.time_sent + loss_delay"," else:"," loss_time[pn_space] = min(loss_time[pn_space],"," unacked.time_sent + loss_delay)"," return lost_packets"]},{"id":"appendix-A.11","title":"Upon Dropping Initial or Handshake Keys","lines":[" When Initial or Handshake keys are discarded, packets from the space"," are discarded and loss detection state is updated.",""," Pseudocode for OnPacketNumberSpaceDiscarded follows:",""," OnPacketNumberSpaceDiscarded(pn_space):"," assert(pn_space != ApplicationData)"," RemoveFromBytesInFlight(sent_packets[pn_space])"," sent_packets[pn_space].clear()"," // Reset the loss detection and PTO timer"," time_of_last_ack_eliciting_packet[pn_space] = 0"," loss_time[pn_space] = 0"," pto_count = 0"," SetLossDetectionTimer()"]},{"id":"appendix-B","title":"Congestion Control Pseudocode","lines":[" We now describe an example implementation of the congestion"," controller described in Section 7.",""," The pseudocode segments in this section are licensed as Code"," Components; see the copyright notice."]},{"id":"appendix-B.1","title":"Constants of Interest","lines":[" Constants used in congestion control are based on a combination of"," RFCs, papers, and common practice.",""," kInitialWindow: Default limit on the initial bytes in flight as"," described in Section 7.2.",""," kMinimumWindow: Minimum congestion window in bytes as described in"," Section 7.2.",""," kLossReductionFactor: Scaling factor applied to reduce the"," congestion window when a new loss event is detected. Section 7"," recommends a value of 0.5.",""," kPersistentCongestionThreshold: Period of time for persistent"," congestion to be established, specified as a PTO multiplier."," Section 7.6 recommends a value of 3."]},{"id":"appendix-B.2","title":"Variables of Interest","lines":[" Variables required to implement the congestion control mechanisms are"," described in this section.",""," max_datagram_size: The sender's current maximum payload size. This"," does not include UDP or IP overhead. The max datagram size is"," used for congestion window computations. An endpoint sets the"," value of this variable based on its Path Maximum Transmission Unit"," (PMTU; see Section 14.2 of [QUIC-TRANSPORT]), with a minimum value"," of 1200 bytes.",""," ecn_ce_counters[kPacketNumberSpace]: The highest value reported for"," the ECN-CE counter in the packet number space by the peer in an"," ACK frame. This value is used to detect increases in the reported"," ECN-CE counter.",""," bytes_in_flight: The sum of the size in bytes of all sent packets"," that contain at least one ack-eliciting or PADDING frame and have"," not been acknowledged or declared lost. The size does not include"," IP or UDP overhead, but does include the QUIC header and"," Authenticated Encryption with Associated Data (AEAD) overhead."," Packets only containing ACK frames do not count toward"," bytes_in_flight to ensure congestion control does not impede"," congestion feedback.",""," congestion_window: Maximum number of bytes allowed to be in flight.",""," congestion_recovery_start_time: The time the current recovery period"," started due to the detection of loss or ECN. When a packet sent"," after this time is acknowledged, QUIC exits congestion recovery.",""," ssthresh: Slow start threshold in bytes. When the congestion window"," is below ssthresh, the mode is slow start and the window grows by"," the number of bytes acknowledged.",""," The congestion control pseudocode also accesses some of the variables"," from the loss recovery pseudocode."]},{"id":"appendix-B.3","title":"Initialization","lines":[" At the beginning of the connection, initialize the congestion control"," variables as follows:",""," congestion_window = kInitialWindow"," bytes_in_flight = 0"," congestion_recovery_start_time = 0"," ssthresh = infinite"," for pn_space in [ Initial, Handshake, ApplicationData ]:"," ecn_ce_counters[pn_space] = 0"]},{"id":"appendix-B.4","title":"On Packet Sent","lines":[" Whenever a packet is sent and it contains non-ACK frames, the packet"," increases bytes_in_flight.",""," OnPacketSentCC(sent_bytes):"," bytes_in_flight += sent_bytes"]},{"id":"appendix-B.5","title":"On Packet Acknowledgment","lines":[" This is invoked from loss detection's OnAckReceived and is supplied"," with the newly acked_packets from sent_packets.",""," In congestion avoidance, implementers that use an integer"," representation for congestion_window should be careful with division"," and can use the alternative approach suggested in Section 2.1 of"," [RFC3465].",""," InCongestionRecovery(sent_time):"," return sent_time <= congestion_recovery_start_time",""," OnPacketsAcked(acked_packets):"," for acked_packet in acked_packets:"," OnPacketAcked(acked_packet)",""," OnPacketAcked(acked_packet):"," if (!acked_packet.in_flight):"," return;"," // Remove from bytes_in_flight."," bytes_in_flight -= acked_packet.sent_bytes"," // Do not increase congestion_window if application"," // limited or flow control limited."," if (IsAppOrFlowControlLimited())"," return"," // Do not increase congestion window in recovery period."," if (InCongestionRecovery(acked_packet.time_sent)):"," return"," if (congestion_window < ssthresh):"," // Slow start."," congestion_window += acked_packet.sent_bytes"," else:"," // Congestion avoidance."," congestion_window +="," max_datagram_size * acked_packet.sent_bytes"," / congestion_window"]},{"id":"appendix-B.6","title":"On New Congestion Event","lines":[" This is invoked from ProcessECN and OnPacketsLost when a new"," congestion event is detected. If not already in recovery, this"," starts a recovery period and reduces the slow start threshold and"," congestion window immediately.",""," OnCongestionEvent(sent_time):"," // No reaction if already in a recovery period."," if (InCongestionRecovery(sent_time)):"," return",""," // Enter recovery period."," congestion_recovery_start_time = now()"," ssthresh = congestion_window * kLossReductionFactor"," congestion_window = max(ssthresh, kMinimumWindow)"," // A packet can be sent to speed up loss recovery."," MaybeSendOnePacket()"]},{"id":"appendix-B.7","title":"Process ECN Information","lines":[" This is invoked when an ACK frame with an ECN section is received"," from the peer.",""," ProcessECN(ack, pn_space):"," // If the ECN-CE counter reported by the peer has increased,"," // this could be a new congestion event."," if (ack.ce_counter > ecn_ce_counters[pn_space]):"," ecn_ce_counters[pn_space] = ack.ce_counter"," sent_time = sent_packets[ack.largest_acked].time_sent"," OnCongestionEvent(sent_time)"]},{"id":"appendix-B.8","title":"On Packets Lost","lines":[" This is invoked when DetectAndRemoveLostPackets deems packets lost.",""," OnPacketsLost(lost_packets):"," sent_time_of_last_loss = 0"," // Remove lost packets from bytes_in_flight."," for lost_packet in lost_packets:"," if lost_packet.in_flight:"," bytes_in_flight -= lost_packet.sent_bytes"," sent_time_of_last_loss ="," max(sent_time_of_last_loss, lost_packet.time_sent)"," // Congestion event if in-flight packets were lost"," if (sent_time_of_last_loss != 0):"," OnCongestionEvent(sent_time_of_last_loss)",""," // Reset the congestion window if the loss of these"," // packets indicates persistent congestion."," // Only consider packets sent after getting an RTT sample."," if (first_rtt_sample == 0):"," return"," pc_lost = []"," for lost in lost_packets:"," if lost.time_sent > first_rtt_sample:"," pc_lost.insert(lost)"," if (InPersistentCongestion(pc_lost)):"," congestion_window = kMinimumWindow"," congestion_recovery_start_time = 0"]},{"id":"appendix-B.9","title":"Removing Discarded Packets from Bytes in Flight","lines":[" When Initial or Handshake keys are discarded, packets sent in that"," space no longer count toward bytes in flight.",""," Pseudocode for RemoveFromBytesInFlight follows:",""," RemoveFromBytesInFlight(discarded_packets):"," // Remove any unacknowledged packets from flight."," foreach packet in discarded_packets:"," if packet.in_flight"," bytes_in_flight -= size"]},{"id":"name-contributors","title":"Contributors","lines":[" The IETF QUIC Working Group received an enormous amount of support"," from many people. The following people provided substantive"," contributions to this document:",""," * Alessandro Ghedini"," * Benjamin Saunders"," * Gorry Fairhurst"," * 山本和彦 (Kazu Yamamoto)"," * 奥 一穂 (Kazuho Oku)"," * Lars Eggert"," * Magnus Westerlund"," * Marten Seemann"," * Martin Duke"," * Martin Thomson"," * Mirja Kühlewind"," * Nick Banks"," * Praveen Balasubramanian"]},{"id":"name-authors-addresses","title":"Authors' Addresses","lines":[" Jana Iyengar (editor)"," Fastly",""," Email: jri.ietf@gmail.com",""," Ian Swett (editor)"," Google",""," Email: ianswett@google.com"]}]},"https://www.rfc-editor.org/rfc/rfc9114":{"format":"ietf","requirements":[765,766,767,768,769,770,771,772,773,774,775,776,777,778,779,780,781,782,783,784,785,786,787,788,789,790,791,792,793,794,795,796,797,798,799,800,801,802,803,804,805,806,807,808,809,810,811,812,813,814,815,816,817,818,819,820,821,822,823,824,825,826,827,828,829,830,831,832,833,834,835,836,837,838,839,840,841,842,843,844,845,846,847,848,849,850,851,852,853,854,855,856,857,858,859,860,861,862,863,864,865,866,867,868,869,870,871,872,873,874,875,876,877,878,879,880,881,882,883,884,885,886,887,888,889,890,891,892,893,894,895,896,897,898,899,900,901,902,903,904,905,906,907,908,909,910,911,912,913,914,915,916,917,918,919,920,921,922,923,924,925,926,927,928,929,930,931,932,933,934,935,936,937,938,939,940,941,942,943,944,945,946,947,948,949,950,951,952,953,954,955,956,957,958,959,960,961,962,963,964,965,966,967,968,969,970,971,972,973,974,975,976,977,978,979,980,981,982,983,984,985,986,987,988,989,990,991,992,993,994,995,996,997,998,999,1000,1001,1002,1003],"sections":[{"id":"name-abstract","title":"Abstract","lines":[" 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."]},{"id":"name-status-of-this-memo","title":"Status of This Memo","lines":[" This is an Internet Standards Track document.",""," This document is a product of the Internet Engineering Task Force"," (IETF). It represents the consensus of the IETF community. It has"," received public review and has been approved for publication by the"," Internet Engineering Steering Group (IESG). Further information on"," Internet Standards is available in Section 2 of RFC 7841.",""," Information about the current status of this document, any errata,"," and how to provide feedback on it may be obtained at"," https://www.rfc-editor.org/info/rfc9114."]},{"id":"name-copyright-notice","title":"Copyright Notice","lines":[" Copyright (c) 2022 IETF Trust and the persons identified as the"," document authors. All rights reserved.",""," This document is subject to BCP 78 and the IETF Trust's Legal"," Provisions Relating to IETF Documents"," (https://trustee.ietf.org/license-info) in effect on the date of"," publication of this document. Please review these documents"," carefully, as they describe your rights and restrictions with respect"," to this document. Code Components extracted from this document must"," include Revised BSD License text as described in Section 4.e of the"," Trust Legal Provisions and are provided without warranty as described"," in the Revised BSD License."]},{"id":"name-table-of-contents","title":"Table of Contents","lines":[" 1. Introduction"," 1.1. Prior Versions of HTTP"," 1.2. Delegation to QUIC"," 2. HTTP/3 Protocol Overview"," 2.1. Document Organization"," 2.2. Conventions and Terminology"," 3. Connection Setup and Management"," 3.1. Discovering an HTTP/3 Endpoint"," 3.1.1. HTTP Alternative Services"," 3.1.2. Other Schemes"," 3.2. Connection Establishment"," 3.3. Connection Reuse"," 4. Expressing HTTP Semantics in HTTP/3"," 4.1. HTTP Message Framing"," 4.1.1. Request Cancellation and Rejection"," 4.1.2. Malformed Requests and Responses"," 4.2. HTTP Fields"," 4.2.1. Field Compression"," 4.2.2. Header Size Constraints"," 4.3. HTTP Control Data"," 4.3.1. Request Pseudo-Header Fields"," 4.3.2. Response Pseudo-Header Fields"," 4.4. The CONNECT Method"," 4.5. HTTP Upgrade"," 4.6. Server Push"," 5. Connection Closure"," 5.1. Idle Connections"," 5.2. Connection Shutdown"," 5.3. Immediate Application Closure"," 5.4. Transport Closure"," 6. Stream Mapping and Usage"," 6.1. Bidirectional Streams"," 6.2. Unidirectional Streams"," 6.2.1. Control Streams"," 6.2.2. Push Streams"," 6.2.3. Reserved Stream Types"," 7. HTTP Framing Layer"," 7.1. Frame Layout"," 7.2. Frame Definitions"," 7.2.1. DATA"," 7.2.2. HEADERS"," 7.2.3. CANCEL_PUSH"," 7.2.4. SETTINGS"," 7.2.5. PUSH_PROMISE"," 7.2.6. GOAWAY"," 7.2.7. MAX_PUSH_ID"," 7.2.8. Reserved Frame Types"," 8. Error Handling"," 8.1. HTTP/3 Error Codes"," 9. Extensions to HTTP/3"," 10. Security Considerations"," 10.1. Server Authority"," 10.2. Cross-Protocol Attacks"," 10.3. Intermediary-Encapsulation Attacks"," 10.4. Cacheability of Pushed Responses"," 10.5. Denial-of-Service Considerations"," 10.5.1. Limits on Field Section Size"," 10.5.2. CONNECT Issues"," 10.6. Use of Compression"," 10.7. Padding and Traffic Analysis"," 10.8. Frame Parsing"," 10.9. Early Data"," 10.10. Migration"," 10.11. Privacy Considerations"," 11. IANA Considerations"," 11.1. Registration of HTTP/3 Identification String"," 11.2. New Registries"," 11.2.1. Frame Types"," 11.2.2. Settings Parameters"," 11.2.3. Error Codes"," 11.2.4. Stream Types"," 12. References"," 12.1. Normative References"," 12.2. Informative References"," Appendix A. Considerations for Transitioning from HTTP/2"," A.1. Streams"," A.2. HTTP Frame Types"," A.2.1. Prioritization Differences"," A.2.2. Field Compression Differences"," A.2.3. Flow-Control Differences"," A.2.4. Guidance for New Frame Type Definitions"," A.2.5. Comparison of HTTP/2 and HTTP/3 Frame Types"," A.3. HTTP/2 SETTINGS Parameters"," A.4. HTTP/2 Error Codes"," A.4.1. Mapping between HTTP/2 and HTTP/3 Errors"," Acknowledgments"," Index"," Author's Address"]},{"id":"section-1","title":"Introduction","lines":[" HTTP semantics ([HTTP]) are used for a broad range of services on the"," Internet. These semantics have most commonly been used with HTTP/1.1"," and HTTP/2. HTTP/1.1 has been used over a variety of transport and"," session layers, while HTTP/2 has been used primarily with TLS over"," TCP. HTTP/3 supports the same semantics over a new transport"," protocol: QUIC."]},{"id":"section-1.1","title":"Prior Versions of HTTP","lines":[" HTTP/1.1 ([HTTP/1.1]) uses whitespace-delimited text fields to convey"," HTTP messages. While these exchanges are human readable, using"," whitespace for message formatting leads to parsing complexity and"," excessive tolerance of variant behavior.",""," Because HTTP/1.1 does not include a multiplexing layer, multiple TCP"," connections are often used to service requests in parallel. However,"," that has a negative impact on congestion control and network"," efficiency, since TCP does not share congestion control across"," multiple connections.",""," HTTP/2 ([HTTP/2]) introduced a binary framing and multiplexing layer"," to improve latency without modifying the transport layer. However,"," because the parallel nature of HTTP/2's multiplexing is not visible"," to TCP's loss recovery mechanisms, a lost or reordered packet causes"," all active transactions to experience a stall regardless of whether"," that transaction was directly impacted by the lost packet."]},{"id":"section-1.2","title":"Delegation to QUIC","lines":[" The QUIC transport protocol incorporates stream multiplexing and per-"," stream flow control, similar to that provided by the HTTP/2 framing"," layer. By providing reliability at the stream level and congestion"," control across the entire connection, QUIC has the capability to"," improve the performance of HTTP compared to a TCP mapping. QUIC also"," incorporates TLS 1.3 ([TLS]) at the transport layer, offering"," comparable confidentiality and integrity to running TLS over TCP,"," with the improved connection setup latency of TCP Fast Open ([TFO]).",""," This document defines HTTP/3: a mapping of HTTP semantics over the"," QUIC transport protocol, drawing heavily on the design of HTTP/2."," HTTP/3 relies on QUIC to provide confidentiality and integrity"," protection of data; peer authentication; and reliable, in-order, per-"," stream delivery. While delegating stream lifetime and flow-control"," issues to QUIC, a binary framing similar to the HTTP/2 framing is"," used on each stream. Some HTTP/2 features are subsumed by QUIC,"," while other features are implemented atop QUIC.",""," QUIC is described in [QUIC-TRANSPORT]. For a full description of"," HTTP/2, see [HTTP/2]."]},{"id":"section-2","title":"HTTP/3 Protocol Overview","lines":[" HTTP/3 provides a transport for HTTP semantics using the QUIC"," transport protocol and an internal framing layer similar to HTTP/2.",""," Once a client knows that an HTTP/3 server exists at a certain"," endpoint, it opens a QUIC connection. QUIC provides protocol"," negotiation, stream-based multiplexing, and flow control. Discovery"," of an HTTP/3 endpoint is described in Section 3.1.",""," Within each stream, the basic unit of HTTP/3 communication is a frame"," (Section 7.2). Each frame type serves a different purpose. For"," example, HEADERS and DATA frames form the basis of HTTP requests and"," responses (Section 4.1). Frames that apply to the entire connection"," are conveyed on a dedicated control stream.",""," Multiplexing of requests is performed using the QUIC stream"," abstraction, which is described in Section 2 of [QUIC-TRANSPORT]."," Each request-response pair consumes a single QUIC stream. Streams"," are independent of each other, so one stream that is blocked or"," suffers packet loss does not prevent progress on other streams.",""," Server push is an interaction mode introduced in HTTP/2 ([HTTP/2])"," that permits a server to push a request-response exchange to a client"," in anticipation of the client making the indicated request. This"," trades off network usage against a potential latency gain. Several"," HTTP/3 frames are used to manage server push, such as PUSH_PROMISE,"," MAX_PUSH_ID, and CANCEL_PUSH.",""," As in HTTP/2, request and response fields are compressed for"," transmission. Because HPACK ([HPACK]) relies on in-order"," transmission of compressed field sections (a guarantee not provided"," by QUIC), HTTP/3 replaces HPACK with QPACK ([QPACK]). QPACK uses"," separate unidirectional streams to modify and track field table"," state, while encoded field sections refer to the state of the table"," without modifying it."]},{"id":"section-2.1","title":"Document Organization","lines":[" The following sections provide a detailed overview of the lifecycle"," of an HTTP/3 connection:",""," * \"Connection Setup and Management\" (Section 3) covers how an HTTP/3"," endpoint is discovered and an HTTP/3 connection is established.",""," * \"Expressing HTTP Semantics in HTTP/3\" (Section 4) describes how"," HTTP semantics are expressed using frames.",""," * \"Connection Closure\" (Section 5) describes how HTTP/3 connections"," are terminated, either gracefully or abruptly.",""," The details of the wire protocol and interactions with the transport"," are described in subsequent sections:",""," * \"Stream Mapping and Usage\" (Section 6) describes the way QUIC"," streams are used.",""," * \"HTTP Framing Layer\" (Section 7) describes the frames used on most"," streams.",""," * \"Error Handling\" (Section 8) describes how error conditions are"," handled and expressed, either on a particular stream or for the"," connection as a whole.",""," Additional resources are provided in the final sections:",""," * \"Extensions to HTTP/3\" (Section 9) describes how new capabilities"," can be added in future documents.",""," * A more detailed comparison between HTTP/2 and HTTP/3 can be found"," in Appendix A."]},{"id":"section-2.2","title":"Conventions and Terminology","lines":[" 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 [RFC2119] [RFC8174] when, and only when, they appear in all"," capitals, as shown here.",""," This document uses the variable-length integer encoding from"," [QUIC-TRANSPORT].",""," The following terms are used:",""," abort: An abrupt termination of a connection or stream, possibly due"," to an error condition.",""," client: The endpoint that initiates an HTTP/3 connection. Clients"," send HTTP requests and receive HTTP responses.",""," connection: A transport-layer connection between two endpoints using"," QUIC as the transport protocol.",""," connection error: An error that affects the entire HTTP/3"," connection.",""," endpoint: Either the client or server of the connection.",""," frame: The smallest unit of communication on a stream in HTTP/3,"," consisting of a header and a variable-length sequence of bytes"," structured according to the frame type.",""," Protocol elements called \"frames\" exist in both this document and"," [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are"," referenced, the frame name will be prefaced with \"QUIC\". For"," example, \"QUIC CONNECTION_CLOSE frames\". References without this"," preface refer to frames defined in Section 7.2.",""," HTTP/3 connection: A QUIC connection where the negotiated"," application protocol is HTTP/3.",""," peer: An endpoint. When discussing a particular endpoint, \"peer\""," refers to the endpoint that is remote to the primary subject of"," discussion.",""," receiver: An endpoint that is receiving frames.",""," sender: An endpoint that is transmitting frames.",""," server: The endpoint that accepts an HTTP/3 connection. Servers"," receive HTTP requests and send HTTP responses.",""," stream: A bidirectional or unidirectional bytestream provided by the"," QUIC transport. All streams within an HTTP/3 connection can be"," considered \"HTTP/3 streams\", but multiple stream types are defined"," within HTTP/3.",""," stream error: An application-level error on the individual stream.",""," The term \"content\" is defined in Section 6.4 of [HTTP].",""," Finally, the terms \"resource\", \"message\", \"user agent\", \"origin"," server\", \"gateway\", \"intermediary\", \"proxy\", and \"tunnel\" are defined"," in Section 3 of [HTTP].",""," Packet diagrams in this document use the format defined in"," Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of"," fields."]},{"id":"section-3","title":"Connection Setup and Management","lines":[]},{"id":"section-3.1","title":"Discovering an HTTP/3 Endpoint","lines":[" HTTP relies on the notion of an authoritative response: a response"," that has been determined to be the most appropriate response for that"," request given the state of the target resource at the time of"," response message origination by (or at the direction of) the origin"," server identified within the target URI. Locating an authoritative"," server for an HTTP URI is discussed in Section 4.3 of [HTTP].",""," The \"https\" scheme associates authority with possession of a"," certificate that the client considers to be trustworthy for the host",[[[],0," identified by the authority component of the URI. "],[[794,1284],225,"Upon receiving a"]],[[[],0," "],[[794,1284],225,"server certificate in the TLS handshake, the client MUST verify that"]],[[[],0," "],[[794,1284],225,"the certificate is an acceptable match for the URI's origin server"]],[[[],0," "],[[794,1284],225,"using the process described in Section 4.3.4 of [HTTP]."],[[],0," "],[[795,1285],225,"If the"]],[[[],0," "],[[795,1285],225,"certificate cannot be verified with respect to the URI's origin"]],[[[],0," "],[[795,1285],225,"server, the client MUST NOT consider the server authoritative for"]],[[[],0," "],[[795,1285],225,"that origin."]],"",[[[],0," "],[[796,1286],97,"A client MAY attempt access to a resource with an \"https\" URI by"]],[[[],0," "],[[796,1286],97,"resolving the host identifier to an IP address, establishing a QUIC"]],[[[],0," "],[[796,1286],97,"connection to that address on the indicated port (including"]],[[[],0," "],[[796,1286],97,"validation of the server certificate as described above), and sending"]],[[[],0," "],[[796,1286],97,"an HTTP/3 request message targeting the URI to the server over that"]],[[[],0," "],[[796,1286],97,"secured connection."],[[],0," Unless some other mechanism is used to select"]]," HTTP/3, the token \"h3\" is used in the Application-Layer Protocol"," Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.","",[[[],0," "],[[797,1287],161,"Connectivity problems (e.g., blocking UDP) can result in a failure to"]],[[[],0," "],[[797,1287],161,"establish a QUIC connection; clients SHOULD attempt to use TCP-based"]],[[[],0," "],[[797,1287],161,"versions of HTTP in this case."]],"",[[[],0," "],[[798,1288],97,"Servers MAY serve HTTP/3 on any UDP port; an alternative service"]],[[[],0," "],[[798,1288],97,"advertisement always includes an explicit port, and URIs contain"]],[[[],0," "],[[798,1288],97,"either an explicit port or a default port associated with the scheme."]]],"requirements":[794,795,796,797,798]},{"id":"section-3.1.1","title":"HTTP Alternative Services","lines":[" An HTTP origin can advertise the availability of an equivalent HTTP/3"," endpoint via the Alt-Svc HTTP response header field or the HTTP/2"," ALTSVC frame ([ALTSVC]) using the \"h3\" ALPN token.",""," For example, an origin could indicate in an HTTP response that HTTP/3"," was available on UDP port 50781 at the same hostname by including the"," following header field:",""," Alt-Svc: h3=\":50781\"","",[[[],0," "],[[792,1282],97,"On receipt of an Alt-Svc record indicating HTTP/3 support, a client"]],[[[],0," "],[[792,1282],97,"MAY attempt to establish a QUIC connection to the indicated host and"]],[[[],0," "],[[792,1282],97,"port; if this connection is successful, the client can send HTTP"]],[[[],0," "],[[792,1282],97,"requests using the mapping described in this document."]]],"requirements":[792]},{"id":"section-3.1.2","title":"Other Schemes","lines":[" Although HTTP is independent of the transport protocol, the \"http\""," scheme associates authority with the ability to receive TCP"," connections on the indicated port of whatever host is identified"," within the authority component. Because HTTP/3 does not use TCP,"," HTTP/3 cannot be used for direct access to the authoritative server"," for a resource identified by an \"http\" URI. However, protocol"," extensions such as [ALTSVC] permit the authoritative server to"," identify other services that are also authoritative and that might be"," reachable over HTTP/3.","",[[[],0," "],[[793,1283],225,"Prior to making requests for an origin whose scheme is not \"https\","]],[[[],0," "],[[793,1283],225,"the client MUST ensure the server is willing to serve that scheme."]]," For origins whose scheme is \"http\", an experimental method to"," accomplish this is described in [RFC8164]. Other mechanisms might be"," defined for various schemes in the future."],"requirements":[793]},{"id":"section-3.2","title":"Connection Establishment","lines":[[[[],0," HTTP/3 relies on QUIC version 1 as the underlying transport. "],[[799,1289],97,"The use"]],[[[],0," "],[[799,1289],97,"of other QUIC transport versions with HTTP/3 MAY be defined by future"]],[[[],0," "],[[799,1289],97,"specifications."]],""," QUIC version 1 uses TLS version 1.3 or greater as its handshake",[[[],0," protocol. "],[[800,1290],225,"HTTP/3 clients MUST support a mechanism to indicate the"]],[[[],0," "],[[800,1290],225,"target host to the server during the TLS handshake."],[[],0," "],[[801,1291],225,"If the server is"]],[[[],0," "],[[801,1291],225,"identified by a domain name ([DNS-TERMS]), clients MUST send the"]],[[[],0," "],[[801,1291],225,"Server Name Indication (SNI; [RFC6066]) TLS extension unless an"]],[[[],0," "],[[801,1291],225,"alternative mechanism to indicate the target host is used."]],""," QUIC connections are established as described in [QUIC-TRANSPORT]."," During connection establishment, HTTP/3 support is indicated by",[[[],0," selecting the ALPN token \"h3\" in the TLS handshake. "],[[802,1292],97,"Support for"]],[[[],0," "],[[802,1292],97,"other application-layer protocols MAY be offered in the same"]],[[[],0," "],[[802,1292],97,"handshake."]],""," While connection-level options pertaining to the core QUIC protocol"," are set in the initial crypto handshake, settings specific to HTTP/3",[[[],0," are conveyed in the SETTINGS frame. "],[[803,1445],240,"After the QUIC connection is"]],[[[],0," "],[[803,1445],240,"established, a SETTINGS frame MUST be sent by each endpoint as the"]],[[[],0," "],[[803,1445],240,"initial frame of their respective HTTP control stream."]]],"requirements":[799,800,801,802,803]},{"id":"section-3.3","title":"Connection Reuse","lines":[" HTTP/3 connections are persistent across multiple requests. For best"," performance, it is expected that clients will not close connections"," until it is determined that no further communication with a server is"," necessary (for example, when a user navigates away from a particular"," web page) or until the server closes the connection.","",[[[],0," "],[[804,1293],97,"Once a connection to a server endpoint exists, this connection MAY be"]],[[[],0," "],[[804,1293],97,"reused for requests with multiple different URI authority components."]],[[[],0," "],[[805,1294],225,"To use an existing connection for a new origin, clients MUST validate"]],[[[],0," "],[[805,1294],225,"the certificate presented by the server for the new origin server"]],[[[],0," "],[[805,1294],225,"using the process described in Section 4.3.4 of [HTTP]."],[[],0," This implies"]]," that clients will need to retain the server certificate and any"," additional information needed to verify that certificate; clients"," that do not do so will be unable to reuse the connection for"," additional origins.","",[[[],0," "],[[806,1295],225,"If the certificate is not acceptable with regard to the new origin"]],[[[],0," "],[[806,1295],225,"for any reason, the connection MUST NOT be reused and a new"]],[[[],0," "],[[806,1295],225,"connection SHOULD be established for the new origin."],[[],0," "],[[807,1296],161,"If the reason"]],[[[],0," "],[[807,1296],161,"the certificate cannot be verified might apply to other origins"]],[[[],0," "],[[807,1296],161,"already associated with the connection, the client SHOULD revalidate"]],[[[],0," "],[[807,1296],161,"the server certificate for those origins."],[[],0," For instance, if"]]," validation of a certificate fails because the certificate has expired"," or been revoked, this might be used to invalidate all other origins"," for which that certificate was used to establish authority.","",[[[],0," "],[[808,1297],161,"Clients SHOULD NOT open more than one HTTP/3 connection to a given IP"]],[[[],0," "],[[808,1297],161,"address and UDP port, where the IP address and port might be derived"]],[[[],0," "],[[808,1297],161,"from a URI, a selected alternative service ([ALTSVC]), a configured"]],[[[],0," "],[[808,1297],161,"proxy, or name resolution of any of these."],[[],0," "],[[809,1298],161,"A client MAY open"]],[[[],0," "],[[809,1298],161,"multiple HTTP/3 connections to the same IP address and UDP port using"]],[[[],0," "],[[809,1298],161,"different transport or TLS configurations but SHOULD avoid creating"]],[[[],0," "],[[809,1298],161,"multiple connections with the same configuration."]],""," Servers are encouraged to maintain open HTTP/3 connections for as"," long as possible but are permitted to terminate idle connections if",[[[],0," necessary. "],[[810,1237],161,"When either endpoint chooses to close the HTTP/3"]],[[[],0," "],[[810,1237],161,"connection, the terminating endpoint SHOULD first send a GOAWAY frame"]],[[[],0," "],[[810,1237],161,"(Section 5.2) so that both endpoints can reliably determine whether"]],[[[],0," "],[[810,1237],161,"previously sent frames have been processed and gracefully complete or"]],[[[],0," "],[[810,1237],161,"terminate any necessary remaining tasks."]],""," A server that does not wish clients to reuse HTTP/3 connections for a"," particular origin can indicate that it is not authoritative for a"," request by sending a 421 (Misdirected Request) status code in"," response to the request; see Section 7.4 of [HTTP]."],"requirements":[804,805,806,807,808,809,810]},{"id":"section-4","title":"Expressing HTTP Semantics in HTTP/3","lines":[]},{"id":"section-4.1","title":"HTTP Message Framing","lines":[" A client sends an HTTP request on a request stream, which is a",[[[],0," client-initiated bidirectional QUIC stream; see Section 6.1. "],[[],0,"A"]],[[[],0," "],[[827,1436],240,"client MUST send only a single request on a given stream."],[[],0," A server"]]," sends zero or more interim HTTP responses on the same stream as the"," request, followed by a single final HTTP response, as detailed below."," See Section 15 of [HTTP] for a description of interim and final HTTP"," responses.",""," Pushed responses are sent on a server-initiated unidirectional QUIC"," stream; see Section 6.2.2. A server sends zero or more interim HTTP"," responses, followed by a single final HTTP response, in the same"," manner as a standard response. Push is described in more detail in"," Section 4.6.","",[[[],0," "],[[828,1311],225,"On a given stream, receipt of multiple requests or receipt of an"]],[[[],0," "],[[828,1311],225,"additional HTTP response following a final HTTP response MUST be"]],[[[],0," "],[[828,1311],225,"treated as malformed."]],""," An HTTP message (request or response) consists of:",""," 1. the header section, including message control data, sent as a"," single HEADERS frame,",""," 2. optionally, the content, if present, sent as a series of DATA"," frames, and",""," 3. optionally, the trailer section, if present, sent as a single"," HEADERS frame.",""," Header and trailer sections are described in Sections 6.3 and 6.5 of"," [HTTP]; the content is described in Section 6.4 of [HTTP].","",[[[],0," "],[[829,1478,1479,1480,1481],240,"Receipt of an invalid sequence of frames MUST be treated as a"]],[[[],0," "],[[829,1478,1479,1480,1481],240,"connection error of type H3_FRAME_UNEXPECTED."],[[],0," In particular, a DATA"]]," frame before any HEADERS frame, or a HEADERS or DATA frame after the"," trailing HEADERS frame, is considered invalid. Other frame types,"," especially unknown frame types, might be permitted subject to their"," own rules; see Section 9.","",[[[],0," "],[[830,1326],97,"A server MAY send one or more PUSH_PROMISE frames before, after, or"]],[[[],0," "],[[830,1326],97,"interleaved with the frames of a response message."],[[],0," These"]]," PUSH_PROMISE frames are not part of the response; see Section 4.6 for",[[[],0," more details. "],[[831,1477],240,"PUSH_PROMISE frames are not permitted on push streams;"]],[[[],0," "],[[831,1477],240,"a pushed response that includes PUSH_PROMISE frames MUST be treated"]],[[[],0," "],[[831,1477],240,"as a connection error of type H3_FRAME_UNEXPECTED."]],"",[[[],0," "],[[832,1552],112,"Frames of unknown types (Section 9), including reserved frames"]],[[[],0," "],[[832,1552],112,"(Section 7.2.8) MAY be sent on a request or push stream before,"]],[[[],0," "],[[832,1552],112,"after, or interleaved with other frames described in this section."]],""," The HEADERS and PUSH_PROMISE frames might reference updates to the"," QPACK dynamic table. While these updates are not directly part of"," the message exchange, they must be received and processed before the"," message can be consumed. See Section 4.2 for more details.","",[[[],0," "],[[833,1273],225,"Transfer codings (see Section 7 of [HTTP/1.1]) are not defined for"]],[[[],0," "],[[833,1273],225,"HTTP/3; the Transfer-Encoding header field MUST NOT be used."]],"",[[[],0," "],[[834,1487],112,"A response MAY consist of multiple messages when and only when one or"]],[[[],0," "],[[834,1487],112,"more interim responses (1xx; see Section 15.2 of [HTTP]) precede a"]],[[[],0," "],[[834,1487],112,"final response to the same request."],[[],0," Interim responses do not contain"]]," content or trailer sections.",""," An HTTP request/response exchange fully consumes a client-initiated",[[[],0," bidirectional QUIC stream. "],[[835,1437],240,"After sending a request, a client MUST"]],[[[],0," "],[[835,1437],240,"close the stream for sending."],[[],0," "],[[836,1312],225,"Unless using the CONNECT method (see"]],[[[],0," "],[[836,1312],225,"Section 4.4), clients MUST NOT make stream closure dependent on"]],[[[],0," "],[[836,1312],225,"receiving a response to their request."],[[],0," "],[[837,1440],240,"After sending a final"]],[[[],0," "],[[837,1440],240,"response, the server MUST close the stream for sending."],[[],0," At this"]]," point, the QUIC stream is fully closed.",""," When a stream is closed, this indicates the end of the final HTTP",[[[],0," message. "],[[838,1313],161,"Because some messages are large or unbounded, endpoints"]],[[[],0," "],[[838,1313],161,"SHOULD begin processing partial HTTP messages once enough of the"]],[[[],0," "],[[838,1313],161,"message has been received to make progress."],[[],0," "],[[839,1491],176,"If a client-initiated"]],[[[],0," "],[[839,1491],176,"stream terminates without enough of the HTTP message to provide a"]],[[[],0," "],[[839,1491],176,"complete response, the server SHOULD abort its response stream with"]],[[[],0," "],[[839,1491],176,"the error code H3_REQUEST_INCOMPLETE."]],""," A server can send a complete response prior to the client sending an"," entire request if the response does not depend on any portion of the",[[[],0," request that has not been sent and received. "],[[840,1314],97,"When the server does"]],[[[],0," "],[[840,1314],97,"not need to receive the remainder of the request, it MAY abort"]],[[[],0," "],[[840,1314],97,"reading the request stream, send a complete response, and cleanly"]],[[[],0," "],[[840,1314],97,"close the sending part of the stream."],[[],0," "],[[841,1315],161,"The error code H3_NO_ERROR"]],[[[],0," "],[[841,1315],161,"SHOULD be used when requesting that the client stop sending on the"]],[[[],0," "],[[841,1315],161,"request stream."],[[],0," "],[[842,1316],225,"Clients MUST NOT discard complete responses as a"]],[[[],0," "],[[842,1316],225,"result of having their request terminated abruptly, though clients"]],[[[],0," "],[[842,1316],225,"can always discard responses at their discretion for other reasons."]],[[[],0," "],[[843,1317],161,"If the server sends a partial or complete response but does not abort"]],[[[],0," "],[[843,1317],161,"reading the request, clients SHOULD continue sending the content of"]],[[[],0," "],[[843,1317],161,"the request and close the stream normally."]]],"requirements":[827,828,829,830,831,832,833,834,835,836,837,838,839,840,841,842,843]},{"id":"section-4.1.1","title":"Request Cancellation and Rejection","lines":[[[[],0," "],[[811,1299],97,"Once a request stream has been opened, the request MAY be cancelled"]],[[[],0," "],[[811,1299],97,"by either endpoint."],[[],0," Clients cancel requests if the response is no"]]," longer of interest; servers cancel requests if they are unable to or",[[[],0," choose not to respond. "],[[812,1300],161,"When possible, it is RECOMMENDED that servers"]],[[[],0," "],[[812,1300],161,"send an HTTP response with an appropriate status code rather than"]],[[[],0," "],[[812,1300],161,"cancelling a request it has already begun processing."]],"",[[[],0," "],[[813,1301],161,"Implementations SHOULD cancel requests by abruptly terminating any"]],[[[],0," "],[[813,1301],161,"directions of a stream that are still open."],[[],0," To do so, an"]]," implementation resets the sending parts of streams and aborts reading"," on the receiving parts of streams; see Section 2.4 of"," [QUIC-TRANSPORT].",""," When the server cancels a request without performing any application",[[[],0," processing, the request is considered \"rejected\". "],[[814,1302],161,"The server SHOULD"]],[[[],0," "],[[814,1302],161,"abort its response stream with the error code H3_REQUEST_REJECTED."]]," In this context, \"processed\" means that some data from the stream was"," passed to some higher layer of software that might have taken some"," action as a result. The client can treat requests rejected by the"," server as though they had never been sent at all, thereby allowing"," them to be retried later.","",[[[],0," "],[[815,1303],225,"Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests"]],[[[],0," "],[[815,1303],225,"that were partially or fully processed."],[[],0," "],[[816,1304],161,"When a server abandons a"]],[[[],0," "],[[816,1304],161,"response after partial processing, it SHOULD abort its response"]],[[[],0," "],[[816,1304],161,"stream with the error code H3_REQUEST_CANCELLED."]],"",[[[],0," "],[[817,1305],161,"Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel"]],[[[],0," "],[[817,1305],161,"requests."],[[],0," "],[[818,1306],97,"Upon receipt of this error code, a server MAY abruptly"]],[[[],0," "],[[818,1306],97,"terminate the response using the error code H3_REQUEST_REJECTED if no"]],[[[],0," "],[[818,1306],97,"processing was performed."],[[],0," "],[[819,1307],225,"Clients MUST NOT use the"]],[[[],0," "],[[819,1307],225,"H3_REQUEST_REJECTED error code, except when a server has requested"]],[[[],0," "],[[819,1307],225,"closure of the request stream with this error code."]],"",[[[],0," "],[[820,1308],97,"If a stream is cancelled after receiving a complete response, the"]],[[[],0," "],[[820,1308],97,"client MAY ignore the cancellation and use the response."],[[],0," "],[[821,1309],161,"However, if"]],[[[],0," "],[[821,1309],161,"a stream is cancelled after receiving a partial response, the"]],[[[],0," "],[[821,1309],161,"response SHOULD NOT be used."],[[],0," "],[[822,1310],161,"Only idempotent actions such as GET,"]],[[[],0," "],[[822,1310],161,"PUT, or DELETE can be safely retried; a client SHOULD NOT"]],[[[],0," "],[[822,1310],161,"automatically retry a request with a non-idempotent method unless it"]],[[[],0," "],[[822,1310],161,"has some means to know that the request semantics are idempotent"]],[[[],0," "],[[822,1310],161,"independent of the method or some means to detect that the original"]],[[[],0," "],[[822,1310],161,"request was never applied."],[[],0," See Section 9.2.2 of [HTTP] for more"]]," details."],"requirements":[811,812,813,814,815,816,817,818,819,820,821,822]},{"id":"section-4.1.2","title":"Malformed Requests and Responses","lines":[" A malformed request or response is one that is an otherwise valid"," sequence of frames but is invalid due to:",""," * the presence of prohibited fields or pseudo-header fields,",""," * the absence of mandatory pseudo-header fields,",""," * invalid values for pseudo-header fields,",""," * pseudo-header fields after fields,",""," * an invalid sequence of HTTP messages,",""," * the inclusion of uppercase field names, or",""," * the inclusion of invalid characters in field names or values.",""," A request or response that is defined as having content when it"," contains a Content-Length header field (Section 8.6 of [HTTP]) is"," malformed if the value of the Content-Length header field does not"," equal the sum of the DATA frame lengths received. A response that is"," defined as never having content, even when a Content-Length is"," present, can have a non-zero Content-Length header field even though"," no content is included in DATA frames.","",[[[],0," "],[[823,1271],225,"Intermediaries that process HTTP requests or responses (i.e., any"]],[[[],0," "],[[823,1271],225,"intermediary not acting as a tunnel) MUST NOT forward a malformed"]],[[[],0," "],[[823,1271],225,"request or response."],[[],0," "],[[824,1483,1486],240,"Malformed requests or responses that are"]],[[[],0," "],[[824,1483,1486],240,"detected MUST be treated as a stream error of type H3_MESSAGE_ERROR."]],"",[[[],0," "],[[825,1272],97,"For malformed requests, a server MAY send an HTTP response indicating"]],[[[],0," "],[[825,1272],97,"the error prior to closing or resetting the stream."],[[],0," "],[[826,1485,1492],240,"Clients MUST NOT"]],[[[],0," "],[[826,1485,1492],240,"accept a malformed response."],[[],0," Note that these requirements are"]]," intended to protect against several types of common attacks against"," HTTP; they are deliberately strict because being permissive can"," expose implementations to these vulnerabilities."],"requirements":[823,824,825,826]},{"id":"section-4.2","title":"HTTP Fields","lines":[" HTTP messages carry metadata as a series of key-value pairs called"," \"HTTP fields\"; see Sections 6.3 and 6.5 of [HTTP]. For a listing of"," registered HTTP fields, see the \"Hypertext Transfer Protocol (HTTP)"," Field Name Registry\" maintained at . Like HTTP/2, HTTP/3 has additional considerations"," related to the use of characters in field names, the Connection"," header field, and pseudo-header fields.",""," Field names are strings containing a subset of ASCII characters."," Properties of HTTP field names and values are discussed in more",[[[],0," detail in Section 5.1 of [HTTP]. "],[[848,1276],225,"Characters in field names MUST be"]],[[[],0," "],[[848,1276],225,"converted to lowercase prior to their encoding."],[[],0," "],[[849,1514,3115],244,"A request or"]],[[[],0," "],[[849,1514,3115],244,"response containing uppercase characters in field names MUST be"]],[[[],0," "],[[849,1514,3115],244,"treated as malformed."]],""," HTTP/3 does not use the Connection header field to indicate"," connection-specific fields; in this protocol, connection-specific",[[[],0," metadata is conveyed by other means. "],[[850,1526,3113],244,"An endpoint MUST NOT generate"]],[[[],0," "],[[850,1526,3113],244,"an HTTP/3 field section containing connection-specific fields; any"]],[[[],0," "],[[850,1526,3113],244,"message containing connection-specific fields MUST be treated as"]],[[[],0," "],[[850,1526,3113],244,"malformed."]],"",[[[],0," "],[[851,1527,3114],244,"The only exception to this is the TE header field, which MAY be"]],[[[],0," "],[[851,1527,3114],244,"present in an HTTP/3 request header; when it is, it MUST NOT contain"]],[[[],0," "],[[851,1527,3114],244,"any value other than \"trailers\"."]],"",[[[],0," "],[[852,1277],225,"An intermediary transforming an HTTP/1.x message to HTTP/3 MUST"]],[[[],0," "],[[852,1277],225,"remove connection-specific header fields as discussed in"]],[[[],0," "],[[852,1277],225,"Section 7.6.1 of [HTTP], or their messages will be treated by other"]],[[[],0," "],[[852,1277],225,"HTTP/3 endpoints as malformed."]]],"requirements":[848,849,850,851,852]},{"id":"section-4.2.1","title":"Field Compression","lines":[" [QPACK] describes a variation of HPACK that gives an encoder some"," control over how much head-of-line blocking can be caused by"," compression. This allows an encoder to balance compression"," efficiency with latency. HTTP/3 uses QPACK to compress header and"," trailer sections, including the control data present in the header"," section.","",[[[],0," "],[[844,1274],97,"To allow for better compression efficiency, the Cookie header field"]],[[[],0," "],[[844,1274],97,"([COOKIES]) MAY be split into separate field lines, each with one or"]],[[[],0," "],[[844,1274],97,"more cookie-pairs, before compression."],[[],0," "],[[845,1275],225,"If a decompressed field"]],[[[],0," "],[[845,1275],225,"section contains multiple cookie field lines, these MUST be"]],[[[],0," "],[[845,1275],225,"concatenated into a single byte string using the two-byte delimiter"]],[[[],0," "],[[845,1275],225,"of \"; \" (ASCII 0x3b, 0x20) before being passed into a context other"]],[[[],0," "],[[845,1275],225,"than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic"]],[[[],0," "],[[845,1275],225,"HTTP server application."]]],"requirements":[844,845]},{"id":"section-4.2.2","title":"Header Size Constraints","lines":[[[[],0," "],[[846,1482,1484,1488,1490],112,"An HTTP/3 implementation MAY impose a limit on the maximum size of"]],[[[],0," "],[[846,1482,1484,1488,1490],112,"the message header it will accept on an individual HTTP message."],[[],0," A"]]," server that receives a larger header section than it is willing to"," handle can send an HTTP 431 (Request Header Fields Too Large) status"," code ([RFC6585]). A client can discard responses that it cannot"," process. The size of a field list is calculated based on the"," uncompressed size of fields, including the length of the name and"," value in bytes plus an overhead of 32 bytes for each field.",""," If an implementation wishes to advise its peer of this limit, it can"," be conveyed as a number of bytes in the",[[[],0," SETTINGS_MAX_FIELD_SECTION_SIZE parameter. "],[[847,1435,1439],176,"An implementation that"]],[[[],0," "],[[847,1435,1439],176,"has received this parameter SHOULD NOT send an HTTP message header"]],[[[],0," "],[[847,1435,1439],176,"that exceeds the indicated size, as the peer will likely refuse to"]],[[[],0," "],[[847,1435,1439],176,"process it."],[[],0," However, an HTTP message can traverse one or more"]]," intermediaries before reaching the origin server; see Section 3.7 of"," [HTTP]. Because this limit is applied separately by each"," implementation that processes the message, messages below this limit"," are not guaranteed to be accepted."],"requirements":[846,847]},{"id":"section-4.3","title":"HTTP Control Data","lines":[" Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where"," the field name begins with the : character (ASCII 0x3a). These"," pseudo-header fields convey message control data; see Section 6.2 of"," [HTTP].","",[[[],0," Pseudo-header fields are not HTTP fields. "],[[864,1533,1543],240,"Endpoints MUST NOT"]],[[[],0," "],[[864,1533,1543],240,"generate pseudo-header fields other than those defined in this"]],[[[],0," "],[[864,1533,1543],240,"document."],[[],0," However, an extension could negotiate a modification of"]]," this restriction; see Section 9.",""," Pseudo-header fields are only valid in the context in which they are",[[[],0," defined. "],[[865,1534,1544],240,"Pseudo-header fields defined for requests MUST NOT appear"]],[[[],0," "],[[865,1534,1544],240,"in responses; pseudo-header fields defined for responses MUST NOT"]],[[[],0," "],[[865,1534,1544],240,"appear in requests."],[[],0," "],[[866,1547],240,"Pseudo-header fields MUST NOT appear in trailer"]],[[[],0," "],[[866,1547],240,"sections."],[[],0," "],[[867,1535,1545],240,"Endpoints MUST treat a request or response that contains"]],[[[],0," "],[[867,1535,1545],240,"undefined or invalid pseudo-header fields as malformed."]],"",[[[],0," "],[[868,1524,1541],240,"All pseudo-header fields MUST appear in the header section before"]],[[[],0," "],[[868,1524,1541],240,"regular header fields."],[[],0," "],[[869,1525,1542],240,"Any request or response that contains a"]],[[[],0," "],[[869,1525,1542],240,"pseudo-header field that appears in a header section after a regular"]],[[[],0," "],[[869,1525,1542],240,"header field MUST be treated as malformed."]]],"requirements":[864,865,866,867,868,869]},{"id":"section-4.3.1","title":"Request Pseudo-Header Fields","lines":[" The following pseudo-header fields are defined for requests:",""," \":method\": Contains the HTTP method (Section 9 of [HTTP])",""," \":scheme\": Contains the scheme portion of the target URI"," (Section 3.1 of [URI]).",""," The :scheme pseudo-header is not restricted to URIs with scheme"," \"http\" and \"https\". A proxy or gateway can translate requests for"," non-HTTP schemes, enabling the use of HTTP to interact with non-"," HTTP services.",""," See Section 3.1.2 for guidance on using a scheme other than"," \"https\".",""," \":authority\": Contains the authority portion of the target URI",[[[],0," (Section 3.2 of [URI]). "],[[853,1539],240,"The authority MUST NOT include the"]],[[[],0," "],[[853,1539],240,"deprecated userinfo subcomponent for URIs of scheme \"http\" or"]],[[[],0," "],[[853,1539],240,"\"https\"."]],"",[[[],0," "],[[854,1278],225,"To ensure that the HTTP/1.1 request line can be reproduced"]],[[[],0," "],[[854,1278],225,"accurately, this pseudo-header field MUST be omitted when"]],[[[],0," "],[[854,1278],225,"translating from an HTTP/1.1 request that has a request target in"]],[[[],0," "],[[854,1278],225,"a method-specific form; see Section 7.1 of [HTTP]."],[[],0," "],[[855,1279],161,"Clients that"]],[[[],0," "],[[855,1279],161,"generate HTTP/3 requests directly SHOULD use the :authority"]],[[[],0," "],[[855,1279],161,"pseudo-header field instead of the Host header field."],[[],0," "],[[856,1280],225,"An"]],[[[],0," "],[[856,1280],225,"intermediary that converts an HTTP/3 request to HTTP/1.1 MUST"]],[[[],0," "],[[856,1280],225,"create a Host field if one is not present in a request by copying"]],[[[],0," "],[[856,1280],225,"the value of the :authority pseudo-header field."]],""," \":path\": Contains the path and query parts of the target URI (the"," \"path-absolute\" production and optionally a ? character (ASCII"," 0x3f) followed by the \"query\" production; see Sections 3.3 and 3.4"," of [URI].","",[[[],0," "],[[857,1532],240,"This pseudo-header field MUST NOT be empty for \"http\" or \"https\""]],[[[],0," "],[[857,1532],240,"URIs; \"http\" or \"https\" URIs that do not contain a path component"]],[[[],0," "],[[857,1532],240,"MUST include a value of / (ASCII 0x2f)."],[[],0," An OPTIONS request that"]]," does not include a path component includes the value * (ASCII"," 0x2a) for the :path pseudo-header field; see Section 7.1 of"," [HTTP].","",[[[],0," "],[[858,1528,1529,1531,1537],240,"All HTTP/3 requests MUST include exactly one value for the :method,"]],[[[],0," "],[[858,1528,1529,1531,1537],240,":scheme, and :path pseudo-header fields, unless the request is a"]],[[[],0," "],[[858,1528,1529,1531,1537],240,"CONNECT request; see Section 4.4."]],"",[[[],0," "],[[859,1538],240,"If the :scheme pseudo-header field identifies a scheme that has a"]],[[[],0," "],[[859,1538],240,"mandatory authority component (including \"http\" and \"https\"), the"]],[[[],0," "],[[859,1538],240,"request MUST contain either an :authority pseudo-header field or a"]],[[[],0," "],[[859,1538],240,"Host header field."],[[],0," "],[[860,1530],240,"If these fields are present, they MUST NOT be"]],[[[],0," "],[[860,1530],240,"empty."],[[],0," "],[[861,1540],240,"If both fields are present, they MUST contain the same value."]],[[[],0," "],[[862,1281],225,"If the scheme does not have a mandatory authority component and none"]],[[[],0," "],[[862,1281],225,"is provided in the request target, the request MUST NOT contain the"]],[[[],0," "],[[862,1281],225,":authority pseudo-header or Host header fields."]],""," An HTTP request that omits mandatory pseudo-header fields or contains"," invalid values for those pseudo-header fields is malformed.",""," HTTP/3 does not define a way to carry the version identifier that is"," included in the HTTP/1.1 request line. HTTP/3 requests implicitly"," have a protocol version of \"3.0\"."],"requirements":[853,854,855,856,857,858,859,860,861,862]},{"id":"section-4.3.2","title":"Response Pseudo-Header Fields","lines":[" For responses, a single \":status\" pseudo-header field is defined that",[[[],0," carries the HTTP status code; see Section 15 of [HTTP]. "],[[863,1546],240,"This pseudo-"]],[[[],0," "],[[863,1546],240,"header field MUST be included in all responses; otherwise, the"]],[[[],0," "],[[863,1546],240,"response is malformed (see Section 4.1.2)."]],""," HTTP/3 does not define a way to carry the version or reason phrase"," that is included in an HTTP/1.1 status line. HTTP/3 responses"," implicitly have a protocol version of \"3.0\"."],"requirements":[863]},{"id":"section-4.4","title":"The CONNECT Method","lines":[" The CONNECT method requests that the recipient establish a tunnel to"," the destination origin server identified by the request-target; see"," Section 9.3.6 of [HTTP]. It is primarily used with HTTP proxies to"," establish a TLS session with an origin server for the purposes of"," interacting with \"https\" resources.",""," In HTTP/1.x, CONNECT is used to convert an entire HTTP connection"," into a tunnel to a remote host. In HTTP/2 and HTTP/3, the CONNECT"," method is used to establish a tunnel over a single stream.","",[[[],0," "],[[870,1536],240,"A CONNECT request MUST be constructed as follows:"]],""," * The :method pseudo-header field is set to \"CONNECT\"",""," * The :scheme and :path pseudo-header fields are omitted",""," * The :authority pseudo-header field contains the host and port to"," connect to (equivalent to the authority-form of the request-target"," of CONNECT requests; see Section 7.1 of [HTTP]).",""," The request stream remains open at the end of the request to carry"," the data to be transferred. A CONNECT request that does not conform"," to these restrictions is malformed.",""," A proxy that supports CONNECT establishes a TCP connection"," ([RFC0793]) to the server identified in the :authority pseudo-header"," field. Once this connection is successfully established, the proxy"," sends a HEADERS frame containing a 2xx series status code to the"," client, as defined in Section 15.3 of [HTTP].",""," All DATA frames on the stream correspond to data sent or received on"," the TCP connection. The payload of any DATA frame sent by the client"," is transmitted by the proxy to the TCP server; data received from the"," TCP server is packaged into DATA frames by the proxy. Note that the"," size and number of TCP segments is not guaranteed to map predictably"," to the size and number of HTTP DATA or QUIC STREAM frames.",""," Once the CONNECT method has completed, only DATA frames are permitted",[[[],0," to be sent on the stream. "],[[871,1229],97,"Extension frames MAY be used if"]],[[[],0," "],[[871,1229],97,"specifically permitted by the definition of the extension."],[[],0," "],[[872,1230],225,"Receipt"]],[[[],0," "],[[872,1230],225,"of any other known frame type MUST be treated as a connection error"]],[[[],0," "],[[872,1230],225,"of type H3_FRAME_UNEXPECTED."]],""," The TCP connection can be closed by either peer. When the client"," ends the request stream (that is, the receive stream at the proxy"," enters the \"Data Recvd\" state), the proxy will set the FIN bit on its"," connection to the TCP server. When the proxy receives a packet with"," the FIN bit set, it will close the send stream that it sends to the",[[[],0," client. "],[[873,1231],161,"TCP connections that remain half closed in a single"]],[[[],0," "],[[873,1231],161,"direction are not invalid, but are often handled poorly by servers,"]],[[[],0," "],[[873,1231],161,"so clients SHOULD NOT close a stream for sending while they still"]],[[[],0," "],[[873,1231],161,"expect to receive data from the target of the CONNECT."]],""," A TCP connection error is signaled by abruptly terminating the"," stream. A proxy treats any error in the TCP connection, which"," includes receiving a TCP segment with the RST bit set, as a stream"," error of type H3_CONNECT_ERROR.","",[[[],0," "],[[874,1232],225,"Correspondingly, if a proxy detects an error with the stream or the"]],[[[],0," "],[[874,1232],225,"QUIC connection, it MUST close the TCP connection."],[[],0," "],[[875,1233],225,"If the proxy"]],[[[],0," "],[[875,1233],225,"detects that the client has reset the stream or aborted reading from"]],[[[],0," "],[[875,1233],225,"the stream, it MUST close the TCP connection."],[[],0," "],[[876,1234],161,"If the stream is reset"]],[[[],0," "],[[876,1234],161,"or reading is aborted by the client, a proxy SHOULD perform the same"]],[[[],0," "],[[876,1234],161,"operation on the other direction in order to ensure that both"]],[[[],0," "],[[876,1234],161,"directions of the stream are cancelled."],[[],0," "],[[877,1235],161,"In all these cases, if the"]],[[[],0," "],[[877,1235],161,"underlying TCP implementation permits it, the proxy SHOULD send a TCP"]],[[[],0," "],[[877,1235],161,"segment with the RST bit set."]],"",[[[],0," "],[[878,1236],161,"Since CONNECT creates a tunnel to an arbitrary server, proxies that"]],[[[],0," "],[[878,1236],161,"support CONNECT SHOULD restrict its use to a set of known ports or a"]],[[[],0," "],[[878,1236],161,"list of safe request targets; see Section 9.3.6 of [HTTP] for more"]],[[[],0," "],[[878,1236],161,"details."]]],"requirements":[870,871,872,873,874,875,876,877,878]},{"id":"section-4.5","title":"HTTP Upgrade","lines":[" HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of"," [HTTP]) or the 101 (Switching Protocols) informational status code"," (Section 15.2.2 of [HTTP])."]},{"id":"section-4.6","title":"Server Push","lines":[" Server push is an interaction mode that permits a server to push a"," request-response exchange to a client in anticipation of the client"," making the indicated request. This trades off network usage against"," a potential latency gain. HTTP/3 server push is similar to what is"," described in Section 8.2 of [HTTP/2], but it uses different"," mechanisms.",""," Each server push is assigned a unique push ID by the server. The"," push ID is used to refer to the push in various contexts throughout"," the lifetime of the HTTP/3 connection.",""," The push ID space begins at zero and ends at a maximum value set by"," the MAX_PUSH_ID frame. In particular, a server is not able to push"," until after the client sends a MAX_PUSH_ID frame. A client sends"," MAX_PUSH_ID frames to control the number of pushes that a server can",[[[],0," promise. "],[[879,1327],161,"A server SHOULD use push IDs sequentially, beginning from"]],[[[],0," "],[[879,1327],161,"zero."],[[],0," "],[[880,1467],240,"A client MUST treat receipt of a push stream as a connection"]],[[[],0," "],[[880,1467],240,"error of type H3_ID_ERROR when no MAX_PUSH_ID frame has been sent or"]],[[[],0," "],[[880,1467],240,"when the stream references a push ID that is greater than the maximum"]],[[[],0," "],[[880,1467],240,"push ID."]],""," The push ID is used in one or more PUSH_PROMISE frames that carry the"," control data and header fields of the request message. These frames"," are sent on the request stream that generated the push. This allows",[[[],0," the server push to be associated with a client request. "],[[881,1328],225,"When the"]],[[[],0," "],[[881,1328],225,"same push ID is promised on multiple request streams, the"]],[[[],0," "],[[881,1328],225,"decompressed request field sections MUST contain the same fields in"]],[[[],0," "],[[881,1328],225,"the same order, and both the name and the value in each field MUST be"]],[[[],0," "],[[881,1328],225,"identical."]],""," The push ID is then included with the push stream that ultimately"," fulfills those promises. The push stream identifies the push ID of"," the promise that it fulfills, then contains a response to the"," promised request as described in Section 4.1.",""," Finally, the push ID can be used in CANCEL_PUSH frames; see"," Section 7.2.3. Clients use this frame to indicate they do not wish"," to receive a promised resource. Servers use this frame to indicate"," they will not be fulfilling a previous promise.","",[[[],0," Not all requests can be pushed. "],[[882,1329],97,"A server MAY push requests that have"]],[[[],0," "],[[882,1329],97,"the following properties:"]],""," * cacheable; see Section 9.2.3 of [HTTP]",""," * safe; see Section 9.2.1 of [HTTP]",""," * does not include request content or a trailer section","",[[[],0," "],[[883,1330],225,"The server MUST include a value in the :authority pseudo-header field"]],[[[],0," "],[[883,1330],225,"for which the server is authoritative."],[[],0," "],[[884,1331],225,"If the client has not yet"]],[[[],0," "],[[884,1331],225,"validated the connection for the origin indicated by the pushed"]],[[[],0," "],[[884,1331],225,"request, it MUST perform the same verification process it would do"]],[[[],0," "],[[884,1331],225,"before sending a request for that origin on the connection; see"]],[[[],0," "],[[884,1331],225,"Section 3.3."],[[],0," "],[[885,1332],225,"If this verification fails, the client MUST NOT"]],[[[],0," "],[[885,1332],225,"consider the server authoritative for that origin."]],"",[[[],0," "],[[886,1333],161,"Clients SHOULD send a CANCEL_PUSH frame upon receipt of a"]],[[[],0," "],[[886,1333],161,"PUSH_PROMISE frame carrying a request that is not cacheable, is not"]],[[[],0," "],[[886,1333],161,"known to be safe, that indicates the presence of request content, or"]],[[[],0," "],[[886,1333],161,"for which it does not consider the server authoritative."],[[],0," "],[[887,1334],225,"Any"]],[[[],0," "],[[887,1334],225,"corresponding responses MUST NOT be used or cached."]],""," Each pushed response is associated with one or more client requests."," The push is associated with the request stream on which the"," PUSH_PROMISE frame was received. The same server push can be"," associated with additional client requests using a PUSH_PROMISE frame",[[[],0," with the same push ID on multiple request streams. "],[[888,1335],97,"These"]],[[[],0," "],[[888,1335],97,"associations do not affect the operation of the protocol, but they"]],[[[],0," "],[[888,1335],97,"MAY be considered by user agents when deciding how to use pushed"]],[[[],0," "],[[888,1335],97,"resources."]],""," Ordering of a PUSH_PROMISE frame in relation to certain parts of the",[[[],0," response is important. "],[[889,1336],161,"The server SHOULD send PUSH_PROMISE frames"]],[[[],0," "],[[889,1336],161,"prior to sending HEADERS or DATA frames that reference the promised"]],[[[],0," "],[[889,1336],161,"responses."],[[],0," This reduces the chance that a client requests a resource"]]," that will be pushed by the server.",""," Due to reordering, push stream data can arrive before the"," corresponding PUSH_PROMISE frame. When a client receives a new push"," stream with an as-yet-unknown push ID, both the associated client"," request and the pushed request header fields are unknown. The client"," can buffer the stream data in expectation of the matching"," PUSH_PROMISE. The client can use stream flow control (Section 4.1 of"," [QUIC-TRANSPORT]) to limit the amount of data a server may commit to",[[[],0," the pushed stream. "],[[890,1337],161,"Clients SHOULD abort reading and discard data"]],[[[],0," "],[[890,1337],161,"already read from push streams if no corresponding PUSH_PROMISE frame"]],[[[],0," "],[[890,1337],161,"is processed in a reasonable amount of time."]],""," Push stream data can also arrive after a client has cancelled a push."," In this case, the client can abort reading the stream with an error"," code of H3_REQUEST_CANCELLED. This asks the server not to transfer"," additional data and indicates that it will be discarded upon receipt.",""," Pushed responses that are cacheable (see Section 3 of [HTTP-CACHING])"," can be stored by the client, if it implements an HTTP cache. Pushed"," responses are considered successfully validated on the origin server"," (e.g., if the \"no-cache\" cache response directive is present; see"," Section 5.2.2.4 of [HTTP-CACHING]) at the time the pushed response is"," received.","",[[[],0," "],[[891,1338],225,"Pushed responses that are not cacheable MUST NOT be stored by any"]],[[[],0," "],[[891,1338],225,"HTTP cache."],[[],0," "],[[892,1339],97,"They MAY be made available to the application"]],[[[],0," "],[[892,1339],97,"separately."]]],"requirements":[879,880,881,882,883,884,885,886,887,888,889,890,891,892]},{"id":"section-5","title":"Connection Closure","lines":[" Once established, an HTTP/3 connection can be used for many requests"," and responses over time until the connection is closed. Connection"," closure can happen in any of several different ways."]},{"id":"section-5.1","title":"Idle Connections","lines":[" Each QUIC endpoint declares an idle timeout during the handshake. If"," the QUIC connection remains idle (no packets received) for longer"," than this duration, the peer will assume that the connection has been",[[[],0," closed. "],[[893,1238],161,"HTTP/3 implementations will need to open a new HTTP/3"]],[[[],0," "],[[893,1238],161,"connection for new requests if the existing connection has been idle"]],[[[],0," "],[[893,1238],161,"for longer than the idle timeout negotiated during the QUIC"]],[[[],0," "],[[893,1238],161,"handshake, and they SHOULD do so if approaching the idle timeout; see"]],[[[],0," "],[[893,1238],161,"Section 10.1 of [QUIC-TRANSPORT]."]],""," HTTP clients are expected to request that the transport keep"," connections open while there are responses outstanding for requests"," or server pushes, as described in Section 10.1.2 of [QUIC-TRANSPORT]."," If the client is not expecting a response from the server, allowing"," an idle connection to time out is preferred over expending effort",[[[],0," maintaining a connection that might not be needed. "],[[894,1239],97,"A gateway MAY"]],[[[],0," "],[[894,1239],97,"maintain connections in anticipation of need rather than incur the"]],[[[],0," "],[[894,1239],97,"latency cost of connection establishment to servers."],[[],0," "],[[895,1240],161,"Servers SHOULD"]],[[[],0," "],[[895,1240],161,"NOT actively keep connections open."]]],"requirements":[893,894,895]},{"id":"section-5.2","title":"Connection Shutdown","lines":[" Even when a connection is not idle, either endpoint can decide to"," stop using the connection and initiate a graceful connection close."," Endpoints initiate the graceful shutdown of an HTTP/3 connection by"," sending a GOAWAY frame. The GOAWAY frame contains an identifier that"," indicates to the receiver the range of requests or pushes that were"," or might be processed in this connection. The server sends a client-"," initiated bidirectional stream ID; the client sends a push ID."," Requests or pushes with the indicated identifier or greater are",[[[],0," rejected (Section 4.1.1) by the sender of the GOAWAY. "],[[896,1241],97,"This"]],[[[],0," "],[[896,1241],97,"identifier MAY be zero if no requests or pushes were processed."]],""," The information in the GOAWAY frame enables a client and server to"," agree on which requests or pushes were accepted prior to the shutdown",[[[],0," of the HTTP/3 connection. "],[[897,1242],161,"Upon sending a GOAWAY frame, the endpoint"]],[[[],0," "],[[897,1242],161,"SHOULD explicitly cancel (see Sections 4.1.1 and 7.2.3) any requests"]],[[[],0," "],[[897,1242],161,"or pushes that have identifiers greater than or equal to the one"]],[[[],0," "],[[897,1242],161,"indicated, in order to clean up transport state for the affected"]],[[[],0," "],[[897,1242],161,"streams."],[[],0," "],[[898,1243],161,"The endpoint SHOULD continue to do so as more requests or"]],[[[],0," "],[[898,1243],161,"pushes arrive."]],"",[[[],0," "],[[899,1443],240,"Endpoints MUST NOT initiate new requests or promise new pushes on the"]],[[[],0," "],[[899,1443],240,"connection after receipt of a GOAWAY frame from the peer."],[[],0," "],[[900,1244],97,"Clients"]],[[[],0," "],[[900,1244],97,"MAY establish a new connection to send additional requests."]],""," Some requests or pushes might already be in transit:",""," * Upon receipt of a GOAWAY frame, if the client has already sent"," requests with a stream ID greater than or equal to the identifier"," contained in the GOAWAY frame, those requests will not be"," processed. Clients can safely retry unprocessed requests on a"," different HTTP connection. A client that is unable to retry"," requests loses all requests that are in flight when the server"," closes the connection.",""," Requests on stream IDs less than the stream ID in a GOAWAY frame"," from the server might have been processed; their status cannot be"," known until a response is received, the stream is reset"," individually, another GOAWAY is received with a lower stream ID"," than that of the request in question, or the connection"," terminates.","",[[[],0," "],[[901,1245],97,"Servers MAY reject individual requests on streams below the"]],[[[],0," "],[[901,1245],97,"indicated ID if these requests were not processed."]],""," * If a server receives a GOAWAY frame after having promised pushes"," with a push ID greater than or equal to the identifier contained"," in the GOAWAY frame, those pushes will not be accepted.","",[[[],0," "],[[902,1246],161,"Servers SHOULD send a GOAWAY frame when the closing of a connection"]],[[[],0," "],[[902,1246],161,"is known in advance, even if the advance notice is small, so that the"]],[[[],0," "],[[902,1246],161,"remote peer can know whether or not a request has been partially"]],[[[],0," "],[[902,1246],161,"processed."],[[],0," For example, if an HTTP client sends a POST at the same"]]," time that a server closes a QUIC connection, the client cannot know"," if the server started to process that POST request if the server does"," not send a GOAWAY frame to indicate what streams it might have acted"," on.","",[[[],0," "],[[903,1444],240,"An endpoint MAY send multiple GOAWAY frames indicating different"]],[[[],0," "],[[903,1444],240,"identifiers, but the identifier in each frame MUST NOT be greater"]],[[[],0," "],[[903,1444],240,"than the identifier in any previous frame, since clients might"]],[[[],0," "],[[903,1444],240,"already have retried unprocessed requests on another HTTP connection."]],[[[],0," "],[[904,1505],240,"Receiving a GOAWAY containing a larger identifier than previously"]],[[[],0," "],[[904,1505],240,"received MUST be treated as a connection error of type H3_ID_ERROR."]],""," An endpoint that is attempting to gracefully shut down a connection"," can send a GOAWAY frame with a value set to the maximum possible"," value (2^62-4 for servers, 2^62-1 for clients). This ensures that"," the peer stops creating new requests or pushes. After allowing time"," for any in-flight requests or pushes to arrive, the endpoint can send"," another GOAWAY frame indicating which requests or pushes it might"," accept before the end of the connection. This ensures that a"," connection can be cleanly shut down without losing requests.",""," A client has more flexibility in the value it chooses for the Push ID"," field in a GOAWAY that it sends. A value of 2^62-1 indicates that"," the server can continue fulfilling pushes that have already been"," promised. A smaller value indicates the client will reject pushes",[[[],0," with push IDs greater than or equal to this value. "],[[905,1247],97,"Like the server,"]],[[[],0," "],[[905,1247],97,"the client MAY send subsequent GOAWAY frames so long as the specified"]],[[[],0," "],[[905,1247],97,"push ID is no greater than any previously sent value."]],""," Even when a GOAWAY indicates that a given request or push will not be"," processed or accepted upon receipt, the underlying transport"," resources still exist. The endpoint that initiated these requests"," can cancel them to clean up transport state.","",[[[],0," "],[[906,1248],97,"Once all accepted requests and pushes have been processed, the"]],[[[],0," "],[[906,1248],97,"endpoint can permit the connection to become idle, or it MAY initiate"]],[[[],0," "],[[906,1248],97,"an immediate closure of the connection."],[[],0," "],[[907,1249],161,"An endpoint that completes a"]],[[[],0," "],[[907,1249],161,"graceful shutdown SHOULD use the H3_NO_ERROR error code when closing"]],[[[],0," "],[[907,1249],161,"the connection."]],""," If a client has consumed all available bidirectional stream IDs with"," requests, the server need not send a GOAWAY frame, since the client"," is unable to make further requests."],"requirements":[896,897,898,899,900,901,902,903,904,905,906,907]},{"id":"section-5.3","title":"Immediate Application Closure","lines":[" An HTTP/3 implementation can immediately close the QUIC connection at"," any time. This results in sending a QUIC CONNECTION_CLOSE frame to"," the peer indicating that the application layer has terminated the"," connection. The application error code in this frame indicates to"," the peer why the connection is being closed. See Section 8 for error"," codes that can be used when closing a connection in HTTP/3.","",[[[],0," "],[[908,1250],97,"Before closing the connection, a GOAWAY frame MAY be sent to allow"]],[[[],0," "],[[908,1250],97,"the client to retry some requests."],[[],0," Including the GOAWAY frame in the"]]," same packet as the QUIC CONNECTION_CLOSE frame improves the chances"," of the frame being received by clients.",""," If there are open streams that have not been explicitly closed, they"," are implicitly closed when the connection is closed; see Section 10.2"," of [QUIC-TRANSPORT]."],"requirements":[908]},{"id":"section-5.4","title":"Transport Closure","lines":[" For various reasons, the QUIC transport could indicate to the"," application layer that the connection has terminated. This might be"," due to an explicit closure by the peer, a transport-level error, or a"," change in network topology that interrupts connectivity.","",[[[],0," "],[[909,1251],225,"If a connection terminates without a GOAWAY frame, clients MUST"]],[[[],0," "],[[909,1251],225,"assume that any request that was sent, whether in whole or in part,"]],[[[],0," "],[[909,1251],225,"might have been processed."]]],"requirements":[909]},{"id":"section-6","title":"Stream Mapping and Usage","lines":[" A QUIC stream provides reliable in-order delivery of bytes, but makes"," no guarantees about order of delivery with regard to bytes on other"," streams. In version 1 of QUIC, the stream data containing HTTP"," frames is carried by QUIC STREAM frames, but this framing is"," invisible to the HTTP framing layer. The transport layer buffers and"," orders received stream data, exposing a reliable byte stream to the"," application. Although QUIC permits out-of-order delivery within a"," stream, HTTP/3 does not make use of this feature.",""," QUIC streams can be either unidirectional, carrying data only from"," initiator to receiver, or bidirectional, carrying data in both"," directions. Streams can be initiated by either the client or the"," server. For more detail on QUIC streams, see Section 2 of"," [QUIC-TRANSPORT].",""," When HTTP fields and data are sent over QUIC, the QUIC layer handles"," most of the stream management. HTTP does not need to do any separate"," multiplexing when using QUIC: data sent over a QUIC stream always"," maps to a particular HTTP transaction or to the entire HTTP/3"," connection context."]},{"id":"section-6.1","title":"Bidirectional Streams","lines":[" All client-initiated bidirectional streams are used for HTTP requests"," and responses. A bidirectional stream ensures that the response can"," be readily correlated with the request. These streams are referred"," to as request streams.",""," This means that the client's first request occurs on QUIC stream 0,",[[[],0," with subsequent requests on streams 4, 8, and so on. "],[[910,1365],161,"In order to"]],[[[],0," "],[[910,1365],161,"permit these streams to open, an HTTP/3 server SHOULD configure non-"]],[[[],0," "],[[910,1365],161,"zero minimum values for the number of permitted streams and the"]],[[[],0," "],[[910,1365],161,"initial stream flow-control window."],[[],0," "],[[911,1366],161,"So as to not unnecessarily limit"]],[[[],0," "],[[911,1366],161,"parallelism, at least 100 request streams SHOULD be permitted at a"]],[[[],0," "],[[911,1366],161,"time."]],""," HTTP/3 does not use server-initiated bidirectional streams, though an",[[[],0," extension could define a use for these streams. "],[[912,1452],240,"Clients MUST treat"]],[[[],0," "],[[912,1452],240,"receipt of a server-initiated bidirectional stream as a connection"]],[[[],0," "],[[912,1452],240,"error of type H3_STREAM_CREATION_ERROR unless such an extension has"]],[[[],0," "],[[912,1452],240,"been negotiated."]]],"requirements":[910,911,912]},{"id":"section-6.2","title":"Unidirectional Streams","lines":[" Unidirectional streams, in either direction, are used for a range of"," purposes. The purpose is indicated by a stream type, which is sent"," as a variable-length integer at the start of the stream. The format"," and structure of data that follows this integer is determined by the"," stream type.",""," Unidirectional Stream Header {"," Stream Type (i),"," }",""," Figure 1: Unidirectional Stream Header",""," Two stream types are defined in this document: control streams"," (Section 6.2.1) and push streams (Section 6.2.2). [QPACK] defines"," two additional stream types. Other stream types can be defined by"," extensions to HTTP/3; see Section 9 for more details. Some stream"," types are reserved (Section 6.2.3).",""," The performance of HTTP/3 connections in the early phase of their"," lifetime is sensitive to the creation and exchange of data on"," unidirectional streams. Endpoints that excessively restrict the"," number of streams or the flow-control window of these streams will"," increase the chance that the remote peer reaches the limit early and"," becomes blocked. In particular, implementations should consider that"," remote peers may wish to exercise reserved stream behavior"," (Section 6.2.3) with some of the unidirectional streams they are"," permitted to use.",""," Each endpoint needs to create at least one unidirectional stream for"," the HTTP control stream. QPACK requires two additional"," unidirectional streams, and other extensions might require further",[[[],0," streams. "],[[927,1373],225,"Therefore, the transport parameters sent by both clients"]],[[[],0," "],[[927,1373],225,"and servers MUST allow the peer to create at least three"]],[[[],0," "],[[927,1373],225,"unidirectional streams."],[[],0," "],[[928,1374],161,"These transport parameters SHOULD also"]],[[[],0," "],[[928,1374],161,"provide at least 1,024 bytes of flow-control credit to each"]],[[[],0," "],[[928,1374],161,"unidirectional stream."]],""," Note that an endpoint is not required to grant additional credits to"," create more unidirectional streams if its peer consumes all the"," initial credits before creating the critical unidirectional streams.",[[[],0," "],[[929,1375],161,"Endpoints SHOULD create the HTTP control stream as well as the"]],[[[],0," "],[[929,1375],161,"unidirectional streams required by mandatory extensions (such as the"]],[[[],0," "],[[929,1375],161,"QPACK encoder and decoder streams) first, and then create additional"]],[[[],0," "],[[929,1375],161,"streams as allowed by their peer."]],""," If the stream header indicates a stream type that is not supported by"," the recipient, the remainder of the stream cannot be consumed as the",[[[],0," semantics are unknown. "],[[930,1463],240,"Recipients of unknown stream types MUST"]],[[[],0," "],[[930,1463],240,"either abort reading of the stream or discard incoming data without"]],[[[],0," "],[[930,1463],240,"further processing."],[[],0," "],[[931,1376],161,"If reading is aborted, the recipient SHOULD use"]],[[[],0," "],[[931,1376],161,"the H3_STREAM_CREATION_ERROR error code or a reserved error code"]],[[[],0," "],[[931,1376],161,"(Section 8.1)."],[[],0," "],[[932,1464],240,"The recipient MUST NOT consider unknown stream types"]],[[[],0," "],[[932,1464],240,"to be a connection error of any kind."]],"",[[[],0," "],[[933,1377],161,"As certain stream types can affect connection state, a recipient"]],[[[],0," "],[[933,1377],161,"SHOULD NOT discard data from incoming unidirectional streams prior to"]],[[[],0," "],[[933,1377],161,"reading the stream type."]],"",[[[],0," "],[[934,1378],97,"Implementations MAY send stream types before knowing whether the peer"]],[[[],0," "],[[934,1378],97,"supports them."],[[],0," "],[[935,1379],225,"However, stream types that could modify the state or"]],[[[],0," "],[[935,1379],225,"semantics of existing protocol components, including QPACK or other"]],[[[],0," "],[[935,1379],225,"extensions, MUST NOT be sent until the peer is known to support them."]],""," A sender can close or reset a unidirectional stream unless otherwise",[[[],0," specified. "],[[936,1380],225,"A receiver MUST tolerate unidirectional streams being"]],[[[],0," "],[[936,1380],225,"closed or reset prior to the reception of the unidirectional stream"]],[[[],0," "],[[936,1380],225,"header."]]],"requirements":[927,928,929,930,931,932,933,934,935,936]},{"id":"section-6.2.1","title":"Control Streams","lines":[" A control stream is indicated by a stream type of 0x00. Data on this"," stream consists of HTTP/3 frames, as defined in Section 7.2.","",[[[],0," "],[[913,1446],240,"Each side MUST initiate a single control stream at the beginning of"]],[[[],0," "],[[913,1446],240,"the connection and send its SETTINGS frame as the first frame on this"]],[[[],0," "],[[913,1446],240,"stream."],[[],0," "],[[914,1493],240,"If the first frame of the control stream is any other frame"]],[[[],0," "],[[914,1493],240,"type, this MUST be treated as a connection error of type"]],[[[],0," "],[[914,1493],240,"H3_MISSING_SETTINGS."],[[],0," "],[[915,1455],240,"Only one control stream per peer is permitted;"]],[[[],0," "],[[915,1455],240,"receipt of a second stream claiming to be a control stream MUST be"]],[[[],0," "],[[915,1455],240,"treated as a connection error of type H3_STREAM_CREATION_ERROR."],[[],0," "],[[916,1450],240,"The"]],[[[],0," "],[[916,1450],240,"sender MUST NOT close the control stream, and the receiver MUST NOT"]],[[[],0," "],[[916,1450],240,"request that the sender close the control stream."],[[],0," "],[[917,1448,1453],240,"If either control"]],[[[],0," "],[[917,1448,1453],240,"stream is closed at any point, this MUST be treated as a connection"]],[[[],0," "],[[917,1448,1453],240,"error of type H3_CLOSED_CRITICAL_STREAM."],[[],0," Connection errors are"]]," described in Section 8.","",[[[],0," "],[[918,1367],161,"Because the contents of the control stream are used to manage the"]],[[[],0," "],[[918,1367],161,"behavior of other streams, endpoints SHOULD provide enough flow-"]],[[[],0," "],[[918,1367],161,"control credit to keep the peer's control stream from becoming"]],[[[],0," "],[[918,1367],161,"blocked."]],""," A pair of unidirectional streams is used rather than a single"," bidirectional stream. This allows either peer to send data as soon"," as it is able. Depending on whether 0-RTT is available on the QUIC"," connection, either client or server might be able to send stream data"," first."],"requirements":[913,914,915,916,917,918]},{"id":"section-6.2.2","title":"Push Streams","lines":[" Server push is an optional feature introduced in HTTP/2 that allows a"," server to initiate a response before a request has been made. See"," Section 4.6 for more details.",""," A push stream is indicated by a stream type of 0x01, followed by the"," push ID of the promise that it fulfills, encoded as a variable-length"," integer. The remaining data on this stream consists of HTTP/3"," frames, as defined in Section 7.2, and fulfills a promised server"," push by zero or more interim HTTP responses followed by a single"," final HTTP response, as defined in Section 4.1. Server push and push"," IDs are described in Section 4.6.","",[[[],0," "],[[919,1456],240,"Only servers can push; if a server receives a client-initiated push"]],[[[],0," "],[[919,1456],240,"stream, this MUST be treated as a connection error of type"]],[[[],0," "],[[919,1456],240,"H3_STREAM_CREATION_ERROR."]],""," Push Stream Header {"," Stream Type (i) = 0x01,"," Push ID (i),"," }",""," Figure 2: Push Stream Header","",[[[],0," "],[[920,1368],161,"A client SHOULD NOT abort reading on a push stream prior to reading"]],[[[],0," "],[[920,1368],161,"the push stream header, as this could lead to disagreement between"]],[[[],0," "],[[920,1368],161,"client and server on which push IDs have already been consumed."]],"",[[[],0," "],[[921,1468],240,"Each push ID MUST only be used once in a push stream header."],[[],0," "],[[922,1469],240,"If a"]],[[[],0," "],[[922,1469],240,"client detects that a push stream header includes a push ID that was"]],[[[],0," "],[[922,1469],240,"used in another push stream header, the client MUST treat this as a"]],[[[],0," "],[[922,1469],240,"connection error of type H3_ID_ERROR."]]],"requirements":[919,920,921,922]},{"id":"section-6.2.3","title":"Reserved Stream Types","lines":[" Stream types of the format 0x1f * N + 0x21 for non-negative integer"," values of N are reserved to exercise the requirement that unknown"," types be ignored. These streams have no semantics, and they can be",[[[],0," sent when application-layer padding is desired. "],[[923,1369],97,"They MAY also be"]],[[[],0," "],[[923,1369],97,"sent on connections where no data is currently being transferred."]],[[[],0," "],[[924,1370],225,"Endpoints MUST NOT consider these streams to have any meaning upon"]],[[[],0," "],[[924,1370],225,"receipt."]],""," The payload and length of the stream are selected in any manner the",[[[],0," sending implementation chooses. "],[[925,1371],97,"When sending a reserved stream type,"]],[[[],0," "],[[925,1371],97,"the implementation MAY either terminate the stream cleanly or reset"]],[[[],0," "],[[925,1371],97,"it."],[[],0," "],[[926,1372],161,"When resetting the stream, either the H3_NO_ERROR error code or"]],[[[],0," "],[[926,1372],161,"a reserved error code (Section 8.1) SHOULD be used."]]],"requirements":[923,924,925,926]},{"id":"section-7","title":"HTTP Framing Layer","lines":[" HTTP frames are carried on QUIC streams, as described in Section 6."," HTTP/3 defines three stream types: control stream, request stream,"," and push stream. This section describes HTTP/3 frame formats and"," their permitted stream types; see Table 1 for an overview. A"," comparison between HTTP/2 and HTTP/3 frames is provided in"," Appendix A.2.",""," +==============+================+================+========+=========+"," | Frame | Control Stream | Request | Push | Section |"," | | | Stream | Stream | |"," +==============+================+================+========+=========+"," | DATA | No | Yes | Yes | Section |"," | | | | | 7.2.1 |"," +--------------+----------------+----------------+--------+---------+"," | HEADERS | No | Yes | Yes | Section |"," | | | | | 7.2.2 |"," +--------------+----------------+----------------+--------+---------+"," | CANCEL_PUSH | Yes | No | No | Section |"," | | | | | 7.2.3 |"," +--------------+----------------+----------------+--------+---------+"," | SETTINGS | Yes (1) | No | No | Section |"," | | | | | 7.2.4 |"," +--------------+----------------+----------------+--------+---------+"," | PUSH_PROMISE | No | Yes | No | Section |"," | | | | | 7.2.5 |"," +--------------+----------------+----------------+--------+---------+"," | GOAWAY | Yes | No | No | Section |"," | | | | | 7.2.6 |"," +--------------+----------------+----------------+--------+---------+"," | MAX_PUSH_ID | Yes | No | No | Section |"," | | | | | 7.2.7 |"," +--------------+----------------+----------------+--------+---------+"," | Reserved | Yes | Yes | Yes | Section |"," | | | | | 7.2.8 |"," +--------------+----------------+----------------+--------+---------+",""," Table 1: HTTP/3 Frames and Stream Type Overview",""," The SETTINGS frame can only occur as the first frame of a Control"," stream; this is indicated in Table 1 with a (1). Specific guidance"," is provided in the relevant section.",""," Note that, unlike QUIC frames, HTTP/3 frames can span multiple"," packets."]},{"id":"section-7.1","title":"Frame Layout","lines":[" All frames have the following format:",""," HTTP/3 Frame Format {"," Type (i),"," Length (i),"," Frame Payload (..),"," }",""," Figure 3: HTTP/3 Frame Format",""," A frame includes the following fields:",""," Type: A variable-length integer that identifies the frame type.",""," Length: A variable-length integer that describes the length in bytes"," of the Frame Payload.",""," Frame Payload: A payload, the semantics of which are determined by"," the Type field.","",[[[],0," "],[[937,1517,3111],244,"Each frame's payload MUST contain exactly the fields identified in"]],[[[],0," "],[[937,1517,3111],244,"its description."],[[],0," "],[[938,1518,3112],244,"A frame payload that contains additional bytes"]],[[[],0," "],[[938,1518,3112],244,"after the identified fields or a frame payload that terminates before"]],[[[],0," "],[[938,1518,3112],244,"the end of the identified fields MUST be treated as a connection"]],[[[],0," "],[[938,1518,3112],244,"error of type H3_FRAME_ERROR."],[[],0," "],[[939,1252],225,"In particular, redundant length"]],[[[],0," "],[[939,1252],225,"encodings MUST be verified to be self-consistent; see Section 10.8."]],"",[[[],0," "],[[940,1470,1471],240,"When a stream terminates cleanly, if the last frame on the stream was"]],[[[],0," "],[[940,1470,1471],240,"truncated, this MUST be treated as a connection error of type"]],[[[],0," "],[[940,1470,1471],240,"H3_FRAME_ERROR."],[[],0," Streams that terminate abruptly may be reset at any"]]," point in a frame."],"requirements":[937,938,939,940]},{"id":"section-7.2","title":"Frame Definitions","lines":[]},{"id":"section-7.2.1","title":"DATA","lines":[" DATA frames (type=0x00) convey arbitrary, variable-length sequences"," of bytes associated with HTTP request or response content.","",[[[],0," "],[[941,1472,1475],240,"DATA frames MUST be associated with an HTTP request or response."],[[],0," "],[[942,1499],240,"If"]],[[[],0," "],[[942,1499],240,"a DATA frame is received on a control stream, the recipient MUST"]],[[[],0," "],[[942,1499],240,"respond with a connection error of type H3_FRAME_UNEXPECTED."]],""," DATA Frame {"," Type (i) = 0x00,"," Length (i),"," Data (..),"," }",""," Figure 4: DATA Frame"],"requirements":[941,942]},{"id":"section-7.2.2","title":"HEADERS","lines":[" The HEADERS frame (type=0x01) is used to carry an HTTP field section"," that is encoded using QPACK. See [QPACK] for more details.",""," HEADERS Frame {"," Type (i) = 0x01,"," Length (i),"," Encoded Field Section (..),"," }",""," Figure 5: HEADERS Frame",""," HEADERS frames can only be sent on request streams or push streams.",[[[],0," "],[[943,1500],240,"If a HEADERS frame is received on a control stream, the recipient"]],[[[],0," "],[[943,1500],240,"MUST respond with a connection error of type H3_FRAME_UNEXPECTED."]]],"requirements":[943]},{"id":"section-7.2.3","title":"CANCEL_PUSH","lines":[" The CANCEL_PUSH frame (type=0x03) is used to request cancellation of"," a server push prior to the push stream being received. The"," CANCEL_PUSH frame identifies a server push by push ID (see"," Section 4.6), encoded as a variable-length integer.",""," When a client sends a CANCEL_PUSH frame, it is indicating that it",[[[],0," does not wish to receive the promised resource. "],[[944,1340],161,"The server SHOULD"]],[[[],0," "],[[944,1340],161,"abort sending the resource, but the mechanism to do so depends on the"]],[[[],0," "],[[944,1340],161,"state of the corresponding push stream."],[[],0," If the server has not yet"]],[[[],0," created a push stream, it does not create one. "],[[945,1341],161,"If the push stream is"]],[[[],0," "],[[945,1341],161,"open, the server SHOULD abruptly terminate that stream."],[[],0," "],[[946,1342],97,"If the push"]],[[[],0," "],[[946,1342],97,"stream has already ended, the server MAY still abruptly terminate the"]],[[[],0," "],[[946,1342],97,"stream or MAY take no action."]],""," A server sends a CANCEL_PUSH frame to indicate that it will not be"," fulfilling a promise that was previously sent. The client cannot"," expect the corresponding promise to be fulfilled, unless it has",[[[],0," already received and processed the promised response. "],[[947,1343],161,"Regardless of"]],[[[],0," "],[[947,1343],161,"whether a push stream has been opened, a server SHOULD send a"]],[[[],0," "],[[947,1343],161,"CANCEL_PUSH frame when it determines that promise will not be"]],[[[],0," "],[[947,1343],161,"fulfilled."],[[],0," If a stream has already been opened, the server can abort"]]," sending on the stream with an error code of H3_REQUEST_CANCELLED.",""," Sending a CANCEL_PUSH frame has no direct effect on the state of",[[[],0," existing push streams. "],[[948,1344],161,"A client SHOULD NOT send a CANCEL_PUSH frame"]],[[[],0," "],[[948,1344],161,"when it has already received a corresponding push stream."],[[],0," A push"]]," stream could arrive after a client has sent a CANCEL_PUSH frame,",[[[],0," because a server might not have processed the CANCEL_PUSH. "],[[949,1345],161,"The"]],[[[],0," "],[[949,1345],161,"client SHOULD abort reading the stream with an error code of"]],[[[],0," "],[[949,1345],161,"H3_REQUEST_CANCELLED."]],"",[[[],0," A CANCEL_PUSH frame is sent on the control stream. "],[[950,1253],225,"Receiving a"]],[[[],0," "],[[950,1253],225,"CANCEL_PUSH frame on a stream other than the control stream MUST be"]],[[[],0," "],[[950,1253],225,"treated as a connection error of type H3_FRAME_UNEXPECTED."]],""," CANCEL_PUSH Frame {"," Type (i) = 0x03,"," Length (i),"," Push ID (i),"," }",""," Figure 6: CANCEL_PUSH Frame",""," The CANCEL_PUSH frame carries a push ID encoded as a variable-length"," integer. The Push ID field identifies the server push that is being",[[[],0," cancelled; see Section 4.6. "],[[951,1507,1508],240,"If a CANCEL_PUSH frame is received that"]],[[[],0," "],[[951,1507,1508],240,"references a push ID greater than currently allowed on the"]],[[[],0," "],[[951,1507,1508],240,"connection, this MUST be treated as a connection error of type"]],[[[],0," "],[[951,1507,1508],240,"H3_ID_ERROR."]],""," If the client receives a CANCEL_PUSH frame, that frame might identify"," a push ID that has not yet been mentioned by a PUSH_PROMISE frame due",[[[],0," to reordering. "],[[952,1509],240,"If a server receives a CANCEL_PUSH frame for a push"]],[[[],0," "],[[952,1509],240,"ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST"]],[[[],0," "],[[952,1509],240,"be treated as a connection error of type H3_ID_ERROR."]]],"requirements":[944,945,946,947,948,949,950,951,952]},{"id":"section-7.2.4","title":"SETTINGS","lines":[" The SETTINGS frame (type=0x04) conveys configuration parameters that"," affect how endpoints communicate, such as preferences and constraints"," on peer behavior. Individually, a SETTINGS parameter can also be"," referred to as a \"setting\"; the identifier and value of each setting"," parameter can be referred to as a \"setting identifier\" and a \"setting"," value\".",""," SETTINGS frames always apply to an entire HTTP/3 connection, never a",[[[],0," single stream. "],[[969,1494],240,"A SETTINGS frame MUST be sent as the first frame of"]],[[[],0," "],[[969,1494],240,"each control stream (see Section 6.2.1) by each peer, and it MUST NOT"]],[[[],0," "],[[969,1494],240,"be sent subsequently."],[[],0," "],[[970,1497,1498],240,"If an endpoint receives a second SETTINGS"]],[[[],0," "],[[970,1497,1498],240,"frame on the control stream, the endpoint MUST respond with a"]],[[[],0," "],[[970,1497,1498],240,"connection error of type H3_FRAME_UNEXPECTED."]],"",[[[],0," "],[[971,1501],240,"SETTINGS frames MUST NOT be sent on any stream other than the control"]],[[[],0," "],[[971,1501],240,"stream."],[[],0," "],[[972,3109],228,"If an endpoint receives a SETTINGS frame on a different"]],[[[],0," "],[[972,3109],228,"stream, the endpoint MUST respond with a connection error of type"]],[[[],0," "],[[972,3109],228,"H3_FRAME_UNEXPECTED."]],""," SETTINGS parameters are not negotiated; they describe characteristics"," of the sending peer that can be used by the receiving peer. However,"," a negotiation can be implied by the use of SETTINGS: each peer uses"," SETTINGS to advertise a set of supported values. The definition of"," the setting would describe how each peer combines the two sets to"," conclude which choice will be used. SETTINGS does not provide a"," mechanism to identify when the choice takes effect.",""," Different values for the same parameter can be advertised by each"," peer. For example, a client might be willing to consume a very large"," response field section, while servers are more cautious about request"," size.","",[[[],0," "],[[973,1519],240,"The same setting identifier MUST NOT occur more than once in the"]],[[[],0," "],[[973,1519],240,"SETTINGS frame."],[[],0," "],[[974,1520],112,"A receiver MAY treat the presence of duplicate"]],[[[],0," "],[[974,1520],112,"setting identifiers as a connection error of type H3_SETTINGS_ERROR."]],""," The payload of a SETTINGS frame consists of zero or more parameters."," Each parameter consists of a setting identifier and a value, both"," encoded as QUIC variable-length integers.",""," Setting {"," Identifier (i),"," Value (i),"," }",""," SETTINGS Frame {"," Type (i) = 0x04,"," Length (i),"," Setting (..) ...,"," }",""," Figure 7: SETTINGS Frame","",[[[],0," "],[[975,1522],240,"An implementation MUST ignore any parameter with an identifier it"]],[[[],0," "],[[975,1522],240,"does not understand."]]],"requirements":[969,970,971,972,973,974,975]},{"id":"section-7.2.4.1","title":"Defined SETTINGS Parameters","lines":[" The following settings are defined in HTTP/3:",""," SETTINGS_MAX_FIELD_SECTION_SIZE (0x06): The default value is"," unlimited. See Section 4.2.2 for usage.",""," Setting identifiers of the format 0x1f * N + 0x21 for non-negative"," integer values of N are reserved to exercise the requirement that"," unknown identifiers be ignored. Such settings have no defined",[[[],0," meaning. "],[[953,1431],176,"Endpoints SHOULD include at least one such setting in their"]],[[[],0," "],[[953,1431],176,"SETTINGS frame."],[[],0," "],[[954,1353],225,"Endpoints MUST NOT consider such settings to have"]],[[[],0," "],[[954,1353],225,"any meaning upon receipt."]],""," Because the setting has no defined meaning, the value of the setting"," can be any value the implementation selects.",""," Setting identifiers that were defined in [HTTP/2] where there is no"," corresponding HTTP/3 setting have also been reserved",[[[],0," (Section 11.2.2). "],[[955,1521],240,"These reserved settings MUST NOT be sent, and"]],[[[],0," "],[[955,1521],240,"their receipt MUST be treated as a connection error of type"]],[[[],0," "],[[955,1521],240,"H3_SETTINGS_ERROR."]],""," Additional settings can be defined by extensions to HTTP/3; see"," Section 9 for more details."],"requirements":[953,954,955]},{"id":"section-7.2.4.2","title":"Initialization","lines":[[[[],0," "],[[956,1434,1438],240,"An HTTP implementation MUST NOT send frames or requests that would be"]],[[[],0," "],[[956,1434,1438],240,"invalid based on its current understanding of the peer's settings."]],"",[[[],0," All settings begin at an initial value. "],[[957,1354],161,"Each endpoint SHOULD use"]],[[[],0," "],[[957,1354],161,"these initial values to send messages before the peer's SETTINGS"]],[[[],0," "],[[957,1354],161,"frame has arrived, as packets carrying the settings can be lost or"]],[[[],0," "],[[957,1354],161,"delayed."],[[],0," When the SETTINGS frame arrives, any settings are changed"]]," to their new values.",""," This removes the need to wait for the SETTINGS frame before sending",[[[],0," messages. "],[[958,1355],225,"Endpoints MUST NOT require any data to be received from"]],[[[],0," "],[[958,1355],225,"the peer prior to sending the SETTINGS frame; settings MUST be sent"]],[[[],0," "],[[958,1355],225,"as soon as the transport is ready to send data."]],""," For servers, the initial value of each client setting is the default"," value.",""," For clients using a 1-RTT QUIC connection, the initial value of each"," server setting is the default value. 1-RTT keys will always become"," available prior to the packet containing SETTINGS being processed by",[[[],0," QUIC, even if the server sends SETTINGS immediately. "],[[959,1356],161,"Clients SHOULD"]],[[[],0," "],[[959,1356],161,"NOT wait indefinitely for SETTINGS to arrive before sending requests,"]],[[[],0," "],[[959,1356],161,"but they SHOULD process received datagrams in order to increase the"]],[[[],0," "],[[959,1356],161,"likelihood of processing SETTINGS before sending the first request."]],""," When a 0-RTT QUIC connection is being used, the initial value of each",[[[],0," server setting is the value used in the previous session. "],[[960,1357],161,"Clients"]],[[[],0," "],[[960,1357],161,"SHOULD store the settings the server provided in the HTTP/3"]],[[[],0," "],[[960,1357],161,"connection where resumption information was provided, but they MAY"]],[[[],0," "],[[960,1357],161,"opt not to store settings in certain cases (e.g., if the session"]],[[[],0," "],[[960,1357],161,"ticket is received before the SETTINGS frame)."],[[],0," "],[[961,1358],225,"A client MUST comply"]],[[[],0," "],[[961,1358],225,"with stored settings -- or default values if no values are stored --"]],[[[],0," "],[[961,1358],225,"when attempting 0-RTT."],[[],0," "],[[962,1359],225,"Once a server has provided new settings,"]],[[[],0," "],[[962,1359],225,"clients MUST comply with those values."]],""," A server can remember the settings that it advertised or store an"," integrity-protected copy of the values in the ticket and recover the"," information when accepting 0-RTT data. A server uses the HTTP/3",[[[],0," settings values in determining whether to accept 0-RTT data. "],[[963,1360],225,"If the"]],[[[],0," "],[[963,1360],225,"server cannot determine that the settings remembered by a client are"]],[[[],0," "],[[963,1360],225,"compatible with its current settings, it MUST NOT accept 0-RTT data."]]," Remembered settings are compatible if a client complying with those"," settings would not violate the server's current settings.","",[[[],0," "],[[964,1361],97,"A server MAY accept 0-RTT and subsequently provide different settings"]],[[[],0," "],[[964,1361],97,"in its SETTINGS frame."],[[],0," "],[[965,1511],240,"If 0-RTT data is accepted by the server, its"]],[[[],0," "],[[965,1511],240,"SETTINGS frame MUST NOT reduce any limits or alter any values that"]],[[[],0," "],[[965,1511],240,"might be violated by the client with its 0-RTT data."],[[],0," "],[[966,1362],225,"The server MUST"]],[[[],0," "],[[966,1362],225,"include all settings that differ from their default values."],[[],0," "],[[967,1432,1495],240,"If a"]],[[[],0," "],[[967,1432,1495],240,"server accepts 0-RTT but then sends settings that are not compatible"]],[[[],0," "],[[967,1432,1495],240,"with the previously specified settings, this MUST be treated as a"]],[[[],0," "],[[967,1432,1495],240,"connection error of type H3_SETTINGS_ERROR."],[[],0," "],[[968,1512],240,"If a server accepts"]],[[[],0," "],[[968,1512],240,"0-RTT but then sends a SETTINGS frame that omits a setting value that"]],[[[],0," "],[[968,1512],240,"the client understands (apart from reserved setting identifiers) that"]],[[[],0," "],[[968,1512],240,"was previously specified to have a non-default value, this MUST be"]],[[[],0," "],[[968,1512],240,"treated as a connection error of type H3_SETTINGS_ERROR."]]],"requirements":[956,957,958,959,960,961,962,963,964,965,966,967,968]},{"id":"section-7.2.5","title":"PUSH_PROMISE","lines":[" The PUSH_PROMISE frame (type=0x05) is used to carry a promised"," request header section from server to client on a request stream.",""," PUSH_PROMISE Frame {"," Type (i) = 0x05,"," Length (i),"," Push ID (i),"," Encoded Field Section (..),"," }",""," Figure 8: PUSH_PROMISE Frame",""," The payload consists of:",""," Push ID: A variable-length integer that identifies the server push"," operation. A push ID is used in push stream headers (Section 4.6)"," and CANCEL_PUSH frames.",""," Encoded Field Section: QPACK-encoded request header fields for the"," promised response. See [QPACK] for more details.","",[[[],0," "],[[976,1442],240,"A server MUST NOT use a push ID that is larger than the client has"]],[[[],0," "],[[976,1442],240,"provided in a MAX_PUSH_ID frame (Section 7.2.7)."],[[],0," "],[[977,1476],240,"A client MUST treat"]],[[[],0," "],[[977,1476],240,"receipt of a PUSH_PROMISE frame that contains a larger push ID than"]],[[[],0," "],[[977,1476],240,"the client has advertised as a connection error of H3_ID_ERROR."]],"",[[[],0," "],[[978,1346],97,"A server MAY use the same push ID in multiple PUSH_PROMISE frames."]],[[[],0," "],[[979,1347],225,"If so, the decompressed request header sets MUST contain the same"]],[[[],0," "],[[979,1347],225,"fields in the same order, and both the name and the value in each"]],[[[],0," "],[[979,1347],225,"field MUST be exact matches."],[[],0," "],[[980,1348],161,"Clients SHOULD compare the request"]],[[[],0," "],[[980,1348],161,"header sections for resources promised multiple times."],[[],0," "],[[981,1489],240,"If a client"]],[[[],0," "],[[981,1489],240,"receives a push ID that has already been promised and detects a"]],[[[],0," "],[[981,1489],240,"mismatch, it MUST respond with a connection error of type"]],[[[],0," "],[[981,1489],240,"H3_GENERAL_PROTOCOL_ERROR."],[[],0," "],[[982,1349],161,"If the decompressed field sections match"]],[[[],0," "],[[982,1349],161,"exactly, the client SHOULD associate the pushed content with each"]],[[[],0," "],[[982,1349],161,"stream on which a PUSH_PROMISE frame was received."]],""," Allowing duplicate references to the same push ID is primarily to",[[[],0," reduce duplication caused by concurrent requests. "],[[983,1350],161,"A server SHOULD"]],[[[],0," "],[[983,1350],161,"avoid reusing a push ID over a long period."],[[],0," Clients are likely to"]]," consume server push responses and not retain them for reuse over"," time. Clients that see a PUSH_PROMISE frame that uses a push ID that"," they have already consumed and discarded are forced to ignore the"," promise.","",[[[],0," "],[[984,1502],240,"If a PUSH_PROMISE frame is received on the control stream, the client"]],[[[],0," "],[[984,1502],240,"MUST respond with a connection error of type H3_FRAME_UNEXPECTED."]],"",[[[],0," "],[[985,1473],240,"A client MUST NOT send a PUSH_PROMISE frame."],[[],0," "],[[986,1474],240,"A server MUST treat the"]],[[[],0," "],[[986,1474],240,"receipt of a PUSH_PROMISE frame as a connection error of type"]],[[[],0," "],[[986,1474],240,"H3_FRAME_UNEXPECTED."]],""," See Section 4.6 for a description of the overall server push"," mechanism."],"requirements":[976,977,978,979,980,981,982,983,984,985,986]},{"id":"section-7.2.6","title":"GOAWAY","lines":[" The GOAWAY frame (type=0x07) is used to initiate graceful shutdown of"," an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint"," to stop accepting new requests or pushes while still finishing"," processing of previously received requests and pushes. This enables"," administrative actions, like server maintenance. GOAWAY by itself"," does not close a connection.",""," GOAWAY Frame {"," Type (i) = 0x07,"," Length (i),"," Stream ID/Push ID (i),"," }",""," Figure 9: GOAWAY Frame",""," The GOAWAY frame is always sent on the control stream. In the"," server-to-client direction, it carries a QUIC stream ID for a client-"," initiated bidirectional stream encoded as a variable-length integer.",[[[],0," "],[[987,1523],240,"A client MUST treat receipt of a GOAWAY frame containing a stream ID"]],[[[],0," "],[[987,1523],240,"of any other type as a connection error of type H3_ID_ERROR."]],""," In the client-to-server direction, the GOAWAY frame carries a push ID"," encoded as a variable-length integer.",""," The GOAWAY frame applies to the entire connection, not a specific",[[[],0," stream. "],[[988,1503],240,"A client MUST treat a GOAWAY frame on a stream other than"]],[[[],0," "],[[988,1503],240,"the control stream as a connection error of type H3_FRAME_UNEXPECTED."]],""," See Section 5.2 for more information on the use of the GOAWAY frame."],"requirements":[987,988]},{"id":"section-7.2.7","title":"MAX_PUSH_ID","lines":[" The MAX_PUSH_ID frame (type=0x0d) is used by clients to control the"," number of server pushes that the server can initiate. This sets the"," maximum value for a push ID that the server can use in PUSH_PROMISE"," and CANCEL_PUSH frames. Consequently, this also limits the number of"," push streams that the server can initiate in addition to the limit"," maintained by the QUIC transport.","",[[[],0," The MAX_PUSH_ID frame is always sent on the control stream. "],[[989,1504],240,"Receipt"]],[[[],0," "],[[989,1504],240,"of a MAX_PUSH_ID frame on any other stream MUST be treated as a"]],[[[],0," "],[[989,1504],240,"connection error of type H3_FRAME_UNEXPECTED."]],"",[[[],0," "],[[990,1548],240,"A server MUST NOT send a MAX_PUSH_ID frame."],[[],0," "],[[991,1549],240,"A client MUST treat the"]],[[[],0," "],[[991,1549],240,"receipt of a MAX_PUSH_ID frame as a connection error of type"]],[[[],0," "],[[991,1549],240,"H3_FRAME_UNEXPECTED."]],""," The maximum push ID is unset when an HTTP/3 connection is created,"," meaning that a server cannot push until it receives a MAX_PUSH_ID"," frame. A client that wishes to manage the number of promised server"," pushes can increase the maximum push ID by sending MAX_PUSH_ID frames"," as the server fulfills or cancels server pushes.",""," MAX_PUSH_ID Frame {"," Type (i) = 0x0d,"," Length (i),"," Push ID (i),"," }",""," Figure 10: MAX_PUSH_ID Frame",""," The MAX_PUSH_ID frame carries a single variable-length integer that"," identifies the maximum value for a push ID that the server can use;",[[[],0," see Section 4.6. "],[[992,1506,3108],244,"A MAX_PUSH_ID frame cannot reduce the maximum push"]],[[[],0," "],[[992,1506,3108],244,"ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than"]],[[[],0," "],[[992,1506,3108],244,"previously received MUST be treated as a connection error of type"]],[[[],0," "],[[992,1506,3108],244,"H3_ID_ERROR."]]],"requirements":[989,990,991,992]},{"id":"section-7.2.8","title":"Reserved Frame Types","lines":[" Frame types of the format 0x1f * N + 0x21 for non-negative integer"," values of N are reserved to exercise the requirement that unknown",[[[],0," types be ignored (Section 9). "],[[993,1553],112,"These frames have no semantics, and"]],[[[],0," "],[[993,1553],112,"they MAY be sent on any stream where frames are allowed to be sent."]],[[[],0," This enables their use for application-layer padding. "],[[994,1554],240,"Endpoints MUST"]],[[[],0," "],[[994,1554],240,"NOT consider these frames to have any meaning upon receipt."]],""," The payload and length of the frames are selected in any manner the"," implementation chooses.",""," Frame types that were used in HTTP/2 where there is no corresponding",[[[],0," HTTP/3 frame have also been reserved (Section 11.2.1). "],[[995,1550,1555],240,"These frame"]],[[[],0," "],[[995,1550,1555],240,"types MUST NOT be sent, and their receipt MUST be treated as a"]],[[[],0," "],[[995,1550,1555],240,"connection error of type H3_FRAME_UNEXPECTED."]]],"requirements":[993,994,995]},{"id":"section-8","title":"Error Handling","lines":[" When a stream cannot be completed successfully, QUIC allows the"," application to abruptly terminate (reset) that stream and communicate"," a reason; see Section 2.4 of [QUIC-TRANSPORT]. This is referred to"," as a \"stream error\". An HTTP/3 implementation can decide to close a"," QUIC stream and communicate the type of error. Wire encodings of"," error codes are defined in Section 8.1. Stream errors are distinct"," from HTTP status codes that indicate error conditions. Stream errors"," indicate that the sender did not transfer or consume the full request"," or response, while HTTP status codes indicate the result of a request"," that was successfully received.",""," If an entire connection needs to be terminated, QUIC similarly"," provides mechanisms to communicate a reason; see Section 5.3 of"," [QUIC-TRANSPORT]. This is referred to as a \"connection error\"."," Similar to stream errors, an HTTP/3 implementation can terminate a"," QUIC connection and communicate the reason using an error code from"," Section 8.1.",""," Although the reasons for closing streams and connections are called"," \"errors\", these actions do not necessarily indicate a problem with"," the connection or either implementation. For example, a stream can"," be reset if the requested resource is no longer needed.","",[[[],0," "],[[997,1323],97,"An endpoint MAY choose to treat a stream error as a connection error"]],[[[],0," "],[[997,1323],97,"under certain circumstances, closing the entire connection in"]],[[[],0," "],[[997,1323],97,"response to a condition on a single stream."],[[],0," Implementations need to"]]," consider the impact on outstanding requests before making this"," choice.","",[[[],0," "],[[998,1324],225,"Because new error codes can be defined without negotiation (see"]],[[[],0," "],[[998,1324],225,"Section 9), use of an error code in an unexpected context or receipt"]],[[[],0," "],[[998,1324],225,"of an unknown error code MUST be treated as equivalent to"]],[[[],0," "],[[998,1324],225,"H3_NO_ERROR."],[[],0," However, closing a stream can have other effects"]]," regardless of the error code; for example, see Section 4.1."],"requirements":[997,998]},{"id":"section-8.1","title":"HTTP/3 Error Codes","lines":[" The following error codes are defined for use when abruptly"," terminating streams, aborting reading of streams, or immediately"," closing HTTP/3 connections.",""," H3_NO_ERROR (0x0100): No error. This is used when the connection or"," stream needs to be closed, but there is no error to signal.",""," H3_GENERAL_PROTOCOL_ERROR (0x0101): Peer violated protocol"," requirements in a way that does not match a more specific error"," code or endpoint declines to use the more specific error code.",""," H3_INTERNAL_ERROR (0x0102): An internal error has occurred in the"," HTTP stack.",""," H3_STREAM_CREATION_ERROR (0x0103): The endpoint detected that its"," peer created a stream that it will not accept.",""," H3_CLOSED_CRITICAL_STREAM (0x0104): A stream required by the HTTP/3"," connection was closed or reset.",""," H3_FRAME_UNEXPECTED (0x0105): A frame was received that was not"," permitted in the current state or on the current stream.",""," H3_FRAME_ERROR (0x0106): A frame that fails to satisfy layout"," requirements or with an invalid size was received.",""," H3_EXCESSIVE_LOAD (0x0107): The endpoint detected that its peer is"," exhibiting a behavior that might be generating excessive load.",""," H3_ID_ERROR (0x0108): A stream ID or push ID was used incorrectly,"," such as exceeding a limit, reducing a limit, or being reused.",""," H3_SETTINGS_ERROR (0x0109): An endpoint detected an error in the"," payload of a SETTINGS frame.",""," H3_MISSING_SETTINGS (0x010a): No SETTINGS frame was received at the"," beginning of the control stream.",""," H3_REQUEST_REJECTED (0x010b): A server rejected a request without"," performing any application processing.",""," H3_REQUEST_CANCELLED (0x010c): The request or its response"," (including pushed response) is cancelled.",""," H3_REQUEST_INCOMPLETE (0x010d): The client's stream terminated"," without containing a fully formed request.",""," H3_MESSAGE_ERROR (0x010e): An HTTP message was malformed and cannot"," be processed.",""," H3_CONNECT_ERROR (0x010f): The TCP connection established in"," response to a CONNECT request was reset or abnormally closed.",""," H3_VERSION_FALLBACK (0x0110): The requested operation cannot be"," served over HTTP/3. The peer should retry over HTTP/1.1.",""," Error codes of the format 0x1f * N + 0x21 for non-negative integer"," values of N are reserved to exercise the requirement that unknown"," error codes be treated as equivalent to H3_NO_ERROR (Section 9).",[[[],0," "],[[996,1322],161,"Implementations SHOULD select an error code from this space with some"]],[[[],0," "],[[996,1322],161,"probability when they would have sent H3_NO_ERROR."]]],"requirements":[996]},{"id":"section-9","title":"Extensions to HTTP/3","lines":[" HTTP/3 permits extension of the protocol. Within the limitations"," described in this section, protocol extensions can be used to provide"," additional services or alter any aspect of the protocol. Extensions"," are effective only within the scope of a single HTTP/3 connection.",""," This applies to the protocol elements defined in this document. This"," does not affect the existing options for extending HTTP, such as"," defining new methods, status codes, or fields.",""," Extensions are permitted to use new frame types (Section 7.2), new"," settings (Section 7.2.4.1), new error codes (Section 8), or new"," unidirectional stream types (Section 6.2). Registries are"," established for managing these extension points: frame types"," (Section 11.2.1), settings (Section 11.2.2), error codes"," (Section 11.2.3), and stream types (Section 11.2.4).","",[[[],0," "],[[999,1551,1556],240,"Implementations MUST ignore unknown or unsupported values in all"]],[[[],0," "],[[999,1551,1556],240,"extensible protocol elements."],[[],0," "],[[1000,1381],225,"Implementations MUST discard data or"]],[[[],0," "],[[1000,1381],225,"abort reading on unidirectional streams that have unknown or"]],[[[],0," "],[[1000,1381],225,"unsupported types."],[[],0," This means that any of these extension points can"]]," be safely used by extensions without prior arrangement or",[[[],0," negotiation. "],[[1001,1254],161,"However, where a known frame type is required to be in"]],[[[],0," "],[[1001,1254],161,"a specific location, such as the SETTINGS frame as the first frame of"]],[[[],0," "],[[1001,1254],161,"the control stream (see Section 6.2.1), an unknown frame type does"]],[[[],0," "],[[1001,1254],161,"not satisfy that requirement and SHOULD be treated as an error."]],"",[[[],0," "],[[1002,1363],225,"Extensions that could change the semantics of existing protocol"]],[[[],0," "],[[1002,1363],225,"components MUST be negotiated before being used."],[[],0," For example, an"]]," extension that changes the layout of the HEADERS frame cannot be used"," until the peer has given a positive signal that this is acceptable."," Coordinating when such a revised layout comes into effect could prove"," complex. As such, allocating new identifiers for new definitions of"," existing protocol elements is likely to be more effective.",""," This document does not mandate a specific method for negotiating the"," use of an extension, but it notes that a setting (Section 7.2.4.1)"," could be used for that purpose. If both peers set a value that"," indicates willingness to use the extension, then the extension can be",[[[],0," used. "],[[1003,1364],225,"If a setting is used for extension negotiation, the default"]],[[[],0," "],[[1003,1364],225,"value MUST be defined in such a fashion that the extension is"]],[[[],0," "],[[1003,1364],225,"disabled if the setting is omitted."]]],"requirements":[999,1000,1001,1002,1003]},{"id":"section-10","title":"Security Considerations","lines":[" The security considerations of HTTP/3 should be comparable to those"," of HTTP/2 with TLS. However, many of the considerations from"," Section 10 of [HTTP/2] apply to [QUIC-TRANSPORT] and are discussed in"," that document."]},{"id":"section-10.1","title":"Server Authority","lines":[" HTTP/3 relies on the HTTP definition of authority. The security"," considerations of establishing authority are discussed in"," Section 17.1 of [HTTP]."]},{"id":"section-10.2","title":"Cross-Protocol Attacks","lines":[" The use of ALPN in the TLS and QUIC handshakes establishes the target"," application protocol before application-layer bytes are processed."," This ensures that endpoints have strong assurances that peers are"," using the same protocol.",""," This does not guarantee protection from all cross-protocol attacks."," Section 21.5 of [QUIC-TRANSPORT] describes some ways in which the"," plaintext of QUIC packets can be used to perform request forgery"," against endpoints that don't use authenticated transports."]},{"id":"section-10.3","title":"Intermediary-Encapsulation Attacks","lines":[" The HTTP/3 field encoding allows the expression of names that are not"," valid field names in the syntax used by HTTP (Section 5.1 of [HTTP]).",[[[],0," "],[[765,1513],240,"Requests or responses containing invalid field names MUST be treated"]],[[[],0," "],[[765,1513],240,"as malformed."],[[],0," Therefore, an intermediary cannot translate an HTTP/3"]]," request or response containing an invalid field name into an HTTP/1.1"," message.",""," Similarly, HTTP/3 can transport field values that are not valid."," While most values that can be encoded will not alter field parsing,"," carriage return (ASCII 0x0d), line feed (ASCII 0x0a), and the null"," character (ASCII 0x00) might be exploited by an attacker if they are",[[[],0," translated verbatim. "],[[766,1515],240,"Any request or response that contains a"]],[[[],0," "],[[766,1515],240,"character not permitted in a field value MUST be treated as"]],[[[],0," "],[[766,1515],240,"malformed."],[[],0," Valid characters are defined by the \"field-content\" ABNF"]]," rule in Section 5.5 of [HTTP]."],"requirements":[765,766]},{"id":"section-10.4","title":"Cacheability of Pushed Responses","lines":[" Pushed responses do not have an explicit request from the client; the"," request is provided by the server in the PUSH_PROMISE frame.",""," Caching responses that are pushed is possible based on the guidance"," provided by the origin server in the Cache-Control header field."," However, this can cause issues if a single server hosts more than one"," tenant. For example, a server might offer multiple users each a"," small portion of its URI space.","",[[[],0," "],[[767,1325],225,"Where multiple tenants share space on the same server, that server"]],[[[],0," "],[[767,1325],225,"MUST ensure that tenants are not able to push representations of"]],[[[],0," "],[[767,1325],225,"resources that they do not have authority over."],[[],0," Failure to enforce"]]," this would allow a tenant to provide a representation that would be"," served out of cache, overriding the actual representation that the"," authoritative tenant provides.",""," Clients are required to reject pushed responses for which an origin"," server is not authoritative; see Section 4.6."],"requirements":[767]},{"id":"section-10.5","title":"Denial-of-Service Considerations","lines":[" An HTTP/3 connection can demand a greater commitment of resources to"," operate than an HTTP/1.1 or HTTP/2 connection. The use of field"," compression and flow control depend on a commitment of resources for"," storing a greater amount of state. Settings for these features"," ensure that memory commitments for these features are strictly"," bounded.",""," The number of PUSH_PROMISE frames is constrained in a similar",[[[],0," fashion. "],[[769,1441],176,"A client that accepts server push SHOULD limit the number"]],[[[],0," "],[[769,1441],176,"of push IDs it issues at a time."]],""," Processing capacity cannot be guarded as effectively as state"," capacity.",""," The ability to send undefined protocol elements that the peer is"," required to ignore can be abused to cause a peer to expend additional"," processing time. This might be done by setting multiple undefined"," SETTINGS parameters, unknown frame types, or unknown stream types."," Note, however, that some uses are entirely legitimate, such as"," optional-to-understand extensions and padding to increase resistance"," to traffic analysis.",""," Compression of field sections also offers some opportunities to waste"," processing resources; see Section 7 of [QPACK] for more details on"," potential abuses.",""," All these features -- i.e., server push, unknown protocol elements,"," field compression -- have legitimate uses. These features become a"," burden only when they are used unnecessarily or to excess.",""," An endpoint that does not monitor such behavior exposes itself to a",[[[],0," risk of denial-of-service attack. "],[[770,1318],161,"Implementations SHOULD track the"]],[[[],0," "],[[770,1318],161,"use of these features and set limits on their use."],[[],0," "],[[771,1319],97,"An endpoint MAY"]],[[[],0," "],[[771,1319],97,"treat activity that is suspicious as a connection error of type"]],[[[],0," "],[[771,1319],97,"H3_EXCESSIVE_LOAD, but false positives will result in disrupting"]],[[[],0," "],[[771,1319],97,"valid connections and requests."]]],"requirements":[769,770,771]},{"id":"section-10.5.1","title":"Limits on Field Section Size","lines":[" A large field section (Section 4.1) can cause an implementation to"," commit a large amount of state. Header fields that are critical for"," routing can appear toward the end of a header section, which prevents"," streaming of the header section to its ultimate destination. This"," ordering and other reasons, such as ensuring cache correctness, mean"," that an endpoint likely needs to buffer the entire header section."," Since there is no hard limit to the size of a field section, some"," endpoints could be forced to commit a large amount of available"," memory for header fields.",""," An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE"," (Section 4.2.2) setting to advise peers of limits that might apply on",[[[],0," the size of field sections. "],[[768,1351],97,"This setting is only advisory, so"]],[[[],0," "],[[768,1351],97,"endpoints MAY choose to send field sections that exceed this limit"]],[[[],0," "],[[768,1351],97,"and risk having the request or response being treated as malformed."]]," This setting is specific to an HTTP/3 connection, so any request or"," response could encounter a hop with a lower, unknown limit. An"," intermediary can attempt to avoid this problem by passing on values"," presented by different peers, but they are not obligated to do so.",""," A server that receives a larger field section than it is willing to"," handle can send an HTTP 431 (Request Header Fields Too Large) status"," code ([RFC6585]). A client can discard responses that it cannot"," process."],"requirements":[768]},{"id":"section-10.5.2","title":"CONNECT Issues","lines":[" The CONNECT method can be used to create disproportionate load on a"," proxy, since stream creation is relatively inexpensive when compared"," to the creation and maintenance of a TCP connection. Therefore, a"," proxy that supports CONNECT might be more conservative in the number"," of simultaneous requests it accepts.",""," A proxy might also maintain some resources for a TCP connection"," beyond the closing of the stream that carries the CONNECT request,"," since the outgoing TCP connection remains in the TIME_WAIT state. To"," account for this, a proxy might delay increasing the QUIC stream"," limits for some time after a TCP connection terminates."]},{"id":"section-10.6","title":"Use of Compression","lines":[" Compression can allow an attacker to recover secret data when it is"," compressed in the same context as data under attacker control."," HTTP/3 enables compression of fields (Section 4.2); the following"," concerns also apply to the use of HTTP compressed content-codings;"," see Section 8.4.1 of [HTTP].",""," There are demonstrable attacks on compression that exploit the"," characteristics of the web (e.g., [BREACH]). The attacker induces"," multiple requests containing varying plaintext, observing the length"," of the resulting ciphertext in each, which reveals a shorter length"," when a guess about the secret is correct.","",[[[],0," "],[[772,1320],225,"Implementations communicating on a secure channel MUST NOT compress"]],[[[],0," "],[[772,1320],225,"content that includes both confidential and attacker-controlled data"]],[[[],0," "],[[772,1320],225,"unless separate compression contexts are used for each source of"]],[[[],0," "],[[772,1320],225,"data."],[[],0," "],[[773,1321],225,"Compression MUST NOT be used if the source of data cannot be"]],[[[],0," "],[[773,1321],225,"reliably determined."]],""," Further considerations regarding the compression of field sections"," are described in [QPACK]."],"requirements":[772,773]},{"id":"section-10.7","title":"Padding and Traffic Analysis","lines":[" Padding can be used to obscure the exact size of frame content and is"," provided to mitigate specific attacks within HTTP, for example,"," attacks where compressed content includes both attacker-controlled"," plaintext and secret data (e.g., [BREACH]).",""," Where HTTP/2 employs PADDING frames and Padding fields in other"," frames to make a connection more resistant to traffic analysis,"," HTTP/3 can either rely on transport-layer padding or employ the"," reserved frame and stream types discussed in Sections 7.2.8 and"," 6.2.3. These methods of padding produce different results in terms"," of the granularity of padding, how padding is arranged in relation to"," the information that is being protected, whether padding is applied"," in the case of packet loss, and how an implementation might control"," padding.",""," Reserved stream types can be used to give the appearance of sending"," traffic even when the connection is idle. Because HTTP traffic often"," occurs in bursts, apparent traffic can be used to obscure the timing"," or duration of such bursts, even to the point of appearing to send a"," constant stream of data. However, as such traffic is still flow"," controlled by the receiver, a failure to promptly drain such streams"," and provide additional flow-control credit can limit the sender's"," ability to send real traffic.",""," To mitigate attacks that rely on compression, disabling or limiting"," compression might be preferable to padding as a countermeasure.",""," Use of padding can result in less protection than might seem"," immediately obvious. Redundant padding could even be"," counterproductive. At best, padding only makes it more difficult for"," an attacker to infer length information by increasing the number of"," frames an attacker has to observe. Incorrectly implemented padding"," schemes can be easily defeated. In particular, randomized padding"," with a predictable distribution provides very little protection;"," similarly, padding payloads to a fixed size exposes information as"," payload sizes cross the fixed-sized boundary, which could be possible"," if an attacker can control plaintext."]},{"id":"section-10.8","title":"Frame Parsing","lines":[" Several protocol elements contain nested length elements, typically"," in the form of frames with an explicit length containing variable-"," length integers. This could pose a security risk to an incautious",[[[],0," implementer. "],[[774,1516],240,"An implementation MUST ensure that the length of a"]],[[[],0," "],[[774,1516],240,"frame exactly matches the length of the fields it contains."]]],"requirements":[774]},{"id":"section-10.9","title":"Early Data","lines":[" The use of 0-RTT with HTTP/3 creates an exposure to replay attack.",[[[],0," "],[[775,1352],225,"The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when"]],[[[],0," "],[[775,1352],225,"using HTTP/3 with 0-RTT."],[[],0," When applying [HTTP-REPLAY] to HTTP/3,"]]," references to the TLS layer refer to the handshake performed within"," QUIC, while all references to application data refer to the contents"," of streams."],"requirements":[775]},{"id":"section-10.10","title":"Migration","lines":[" Certain HTTP implementations use the client address for logging or"," access-control purposes. Since a QUIC client's address might change"," during a connection (and future versions might support simultaneous"," use of multiple addresses), such implementations will need to either"," actively retrieve the client's current address or addresses when they"," are relevant or explicitly accept that the original address might"," change."]},{"id":"section-10.11","title":"Privacy Considerations","lines":[" Several characteristics of HTTP/3 provide an observer an opportunity"," to correlate actions of a single client or server over time. These"," include the value of settings, the timing of reactions to stimulus,"," and the handling of any features that are controlled by settings.",""," As far as these create observable differences in behavior, they could"," be used as a basis for fingerprinting a specific client.",""," HTTP/3's preference for using a single QUIC connection allows"," correlation of a user's activity on a site. Reusing connections for"," different origins allows for correlation of activity across those"," origins.",""," Several features of QUIC solicit immediate responses and can be used"," by an endpoint to measure latency to their peer; this might have"," privacy implications in certain scenarios."]},{"id":"section-11","title":"IANA Considerations","lines":[" This document registers a new ALPN protocol ID (Section 11.1) and"," creates new registries that manage the assignment of code points in"," HTTP/3."]},{"id":"section-11.1","title":"Registration of HTTP/3 Identification String","lines":[" This document creates a new registration for the identification of"," HTTP/3 in the \"TLS Application-Layer Protocol Negotiation (ALPN)"," Protocol IDs\" registry established in [RFC7301].",""," The \"h3\" string identifies HTTP/3:",""," Protocol: HTTP/3",""," Identification Sequence: 0x68 0x33 (\"h3\")",""," Specification: This document"]},{"id":"section-11.2","title":"New Registries","lines":[" New registries created in this document operate under the QUIC"," registration policy documented in Section 22.1 of [QUIC-TRANSPORT]."," These registries all include the common set of fields listed in"," Section 22.1.1 of [QUIC-TRANSPORT]. These registries are collected"," under the \"Hypertext Transfer Protocol version 3 (HTTP/3)\" heading.",""," The initial allocations in these registries are all assigned"," permanent status and list a change controller of the IETF and a"," contact of the HTTP working group (ietf-http-wg@w3.org)."]},{"id":"section-11.2.1","title":"Frame Types","lines":[" This document establishes a registry for HTTP/3 frame type codes."," The \"HTTP/3 Frame Types\" registry governs a 62-bit space. This"," registry follows the QUIC registry policy; see Section 11.2."," Permanent registrations in this registry are assigned using the"," Specification Required policy ([RFC8126]), except for values between"," 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using"," Standards Action or IESG Approval as defined in Sections 4.9 and 4.10"," of [RFC8126].",""," While this registry is separate from the \"HTTP/2 Frame Type\" registry"," defined in [HTTP/2], it is preferable that the assignments parallel",[[[],0," each other where the code spaces overlap. "],[[776,1255],161,"If an entry is present in"]],[[[],0," "],[[776,1255],161,"only one registry, every effort SHOULD be made to avoid assigning the"]],[[[],0," "],[[776,1255],161,"corresponding value to an unrelated operation."],[[],0," "],[[777,1256],97,"Expert reviewers MAY"]],[[[],0," "],[[777,1256],97,"reject unrelated registrations that would conflict with the same"]],[[[],0," "],[[777,1256],97,"value in the corresponding registry."]],"",[[[],0," "],[[778,1257],225,"In addition to common fields as described in Section 11.2, permanent"]],[[[],0," "],[[778,1257],225,"registrations in this registry MUST include the following field:"]],""," Frame Type: A name or label for the frame type.","",[[[],0," "],[[779,1258],225,"Specifications of frame types MUST include a description of the frame"]],[[[],0," "],[[779,1258],225,"layout and its semantics, including any parts of the frame that are"]],[[[],0," "],[[779,1258],225,"conditionally present."]],""," The entries in Table 2 are registered by this document.",""," +==============+=======+===============+"," | Frame Type | Value | Specification |"," +==============+=======+===============+"," | DATA | 0x00 | Section 7.2.1 |"," +--------------+-------+---------------+"," | HEADERS | 0x01 | Section 7.2.2 |"," +--------------+-------+---------------+"," | Reserved | 0x02 | This document |"," +--------------+-------+---------------+"," | CANCEL_PUSH | 0x03 | Section 7.2.3 |"," +--------------+-------+---------------+"," | SETTINGS | 0x04 | Section 7.2.4 |"," +--------------+-------+---------------+"," | PUSH_PROMISE | 0x05 | Section 7.2.5 |"," +--------------+-------+---------------+"," | Reserved | 0x06 | This document |"," +--------------+-------+---------------+"," | GOAWAY | 0x07 | Section 7.2.6 |"," +--------------+-------+---------------+"," | Reserved | 0x08 | This document |"," +--------------+-------+---------------+"," | Reserved | 0x09 | This document |"," +--------------+-------+---------------+"," | MAX_PUSH_ID | 0x0d | Section 7.2.7 |"," +--------------+-------+---------------+",""," Table 2: Initial HTTP/3 Frame Types","",[[[],0," "],[[780,1259],225,"Each code of the format 0x1f * N + 0x21 for non-negative integer"]],[[[],0," "],[[780,1259],225,"values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)"]],[[[],0," "],[[780,1259],225,"MUST NOT be assigned by IANA and MUST NOT appear in the listing of"]],[[[],0," "],[[780,1259],225,"assigned values."]]],"requirements":[776,777,778,779,780]},{"id":"section-11.2.2","title":"Settings Parameters","lines":[" This document establishes a registry for HTTP/3 settings. The"," \"HTTP/3 Settings\" registry governs a 62-bit space. This registry"," follows the QUIC registry policy; see Section 11.2. Permanent"," registrations in this registry are assigned using the Specification"," Required policy ([RFC8126]), except for values between 0x00 and 0x3f"," (in hexadecimal; inclusive), which are assigned using Standards"," Action or IESG Approval as defined in Sections 4.9 and 4.10 of"," [RFC8126].",""," While this registry is separate from the \"HTTP/2 Settings\" registry"," defined in [HTTP/2], it is preferable that the assignments parallel",[[[],0," each other. "],[[781,1260],161,"If an entry is present in only one registry, every"]],[[[],0," "],[[781,1260],161,"effort SHOULD be made to avoid assigning the corresponding value to"]],[[[],0," "],[[781,1260],161,"an unrelated operation."],[[],0," "],[[782,1261],97,"Expert reviewers MAY reject unrelated"]],[[[],0," "],[[782,1261],97,"registrations that would conflict with the same value in the"]],[[[],0," "],[[782,1261],97,"corresponding registry."]],"",[[[],0," "],[[783,1262],225,"In addition to common fields as described in Section 11.2, permanent"]],[[[],0," "],[[783,1262],225,"registrations in this registry MUST include the following fields:"]],""," Setting Name: A symbolic name for the setting. Specifying a setting"," name is optional.","",[[[],0," Default: The value of the setting unless otherwise indicated. "],[[],0,"A"]],[[[],0," "],[[784,1263],161,"default SHOULD be the most restrictive possible value."]],""," The entries in Table 3 are registered by this document.",""," +========================+=======+=================+===========+"," | Setting Name | Value | Specification | Default |"," +========================+=======+=================+===========+"," | Reserved | 0x00 | This document | N/A |"," +------------------------+-------+-----------------+-----------+"," | Reserved | 0x02 | This document | N/A |"," +------------------------+-------+-----------------+-----------+"," | Reserved | 0x03 | This document | N/A |"," +------------------------+-------+-----------------+-----------+"," | Reserved | 0x04 | This document | N/A |"," +------------------------+-------+-----------------+-----------+"," | Reserved | 0x05 | This document | N/A |"," +------------------------+-------+-----------------+-----------+"," | MAX_FIELD_SECTION_SIZE | 0x06 | Section 7.2.4.1 | Unlimited |"," +------------------------+-------+-----------------+-----------+",""," Table 3: Initial HTTP/3 Settings",""," For formatting reasons, setting names can be abbreviated by removing"," the 'SETTINGS_' prefix.","",[[[],0," "],[[785,1264],225,"Each code of the format 0x1f * N + 0x21 for non-negative integer"]],[[[],0," "],[[785,1264],225,"values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)"]],[[[],0," "],[[785,1264],225,"MUST NOT be assigned by IANA and MUST NOT appear in the listing of"]],[[[],0," "],[[785,1264],225,"assigned values."]]],"requirements":[781,782,783,784,785]},{"id":"section-11.2.3","title":"Error Codes","lines":[" This document establishes a registry for HTTP/3 error codes. The"," \"HTTP/3 Error Codes\" registry manages a 62-bit space. This registry"," follows the QUIC registry policy; see Section 11.2. Permanent"," registrations in this registry are assigned using the Specification"," Required policy ([RFC8126]), except for values between 0x00 and 0x3f"," (in hexadecimal; inclusive), which are assigned using Standards"," Action or IESG Approval as defined in Sections 4.9 and 4.10 of"," [RFC8126].",""," Registrations for error codes are required to include a description"," of the error code. An expert reviewer is advised to examine new"," registrations for possible duplication with existing error codes."," Use of existing registrations is to be encouraged, but not mandated.",[[[],0," "],[[786,1265],97,"Use of values that are registered in the \"HTTP/2 Error Code\" registry"]],[[[],0," "],[[786,1265],97,"is discouraged, and expert reviewers MAY reject such registrations."]],""," In addition to common fields as described in Section 11.2, this",[[[],0," registry includes two additional fields. "],[[787,1266],225,"Permanent registrations in"]],[[[],0," "],[[787,1266],225,"this registry MUST include the following field:"]],""," Name: A name for the error code.",""," Description: A brief description of the error code semantics.",""," The entries in Table 4 are registered by this document. These error"," codes were selected from the range that operates on a Specification"," Required policy to avoid collisions with HTTP/2 error codes.",""," +===========================+========+==============+===============+"," | Name | Value | Description | Specification |"," +===========================+========+==============+===============+"," | H3_NO_ERROR | 0x0100 | No error | Section 8.1 |"," +---------------------------+--------+--------------+---------------+"," | H3_GENERAL_PROTOCOL_ERROR | 0x0101 | General | Section 8.1 |"," | | | protocol | |"," | | | error | |"," +---------------------------+--------+--------------+---------------+"," | H3_INTERNAL_ERROR | 0x0102 | Internal | Section 8.1 |"," | | | error | |"," +---------------------------+--------+--------------+---------------+"," | H3_STREAM_CREATION_ERROR | 0x0103 | Stream | Section 8.1 |"," | | | creation | |"," | | | error | |"," +---------------------------+--------+--------------+---------------+"," | H3_CLOSED_CRITICAL_STREAM | 0x0104 | Critical | Section 8.1 |"," | | | stream was | |"," | | | closed | |"," +---------------------------+--------+--------------+---------------+"," | H3_FRAME_UNEXPECTED | 0x0105 | Frame not | Section 8.1 |"," | | | permitted | |"," | | | in the | |"," | | | current | |"," | | | state | |"," +---------------------------+--------+--------------+---------------+"," | H3_FRAME_ERROR | 0x0106 | Frame | Section 8.1 |"," | | | violated | |"," | | | layout or | |"," | | | size rules | |"," +---------------------------+--------+--------------+---------------+"," | H3_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 |"," | | | generating | |"," | | | excessive | |"," | | | load | |"," +---------------------------+--------+--------------+---------------+"," | H3_ID_ERROR | 0x0108 | An | Section 8.1 |"," | | | identifier | |"," | | | was used | |"," | | | incorrectly | |"," +---------------------------+--------+--------------+---------------+"," | H3_SETTINGS_ERROR | 0x0109 | SETTINGS | Section 8.1 |"," | | | frame | |"," | | | contained | |"," | | | invalid | |"," | | | values | |"," +---------------------------+--------+--------------+---------------+"," | H3_MISSING_SETTINGS | 0x010a | No SETTINGS | Section 8.1 |"," | | | frame | |"," | | | received | |"," +---------------------------+--------+--------------+---------------+"," | H3_REQUEST_REJECTED | 0x010b | Request not | Section 8.1 |"," | | | processed | |"," +---------------------------+--------+--------------+---------------+"," | H3_REQUEST_CANCELLED | 0x010c | Data no | Section 8.1 |"," | | | longer | |"," | | | needed | |"," +---------------------------+--------+--------------+---------------+"," | H3_REQUEST_INCOMPLETE | 0x010d | Stream | Section 8.1 |"," | | | terminated | |"," | | | early | |"," +---------------------------+--------+--------------+---------------+"," | H3_MESSAGE_ERROR | 0x010e | Malformed | Section 8.1 |"," | | | message | |"," +---------------------------+--------+--------------+---------------+"," | H3_CONNECT_ERROR | 0x010f | TCP reset | Section 8.1 |"," | | | or error on | |"," | | | CONNECT | |"," | | | request | |"," +---------------------------+--------+--------------+---------------+"," | H3_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 |"," | | | HTTP/1.1 | |"," +---------------------------+--------+--------------+---------------+",""," Table 4: Initial HTTP/3 Error Codes","",[[[],0," "],[[788,1267],225,"Each code of the format 0x1f * N + 0x21 for non-negative integer"]],[[[],0," "],[[788,1267],225,"values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)"]],[[[],0," "],[[788,1267],225,"MUST NOT be assigned by IANA and MUST NOT appear in the listing of"]],[[[],0," "],[[788,1267],225,"assigned values."]]],"requirements":[786,787,788]},{"id":"section-11.2.4","title":"Stream Types","lines":[" This document establishes a registry for HTTP/3 unidirectional stream"," types. The \"HTTP/3 Stream Types\" registry governs a 62-bit space."," This registry follows the QUIC registry policy; see Section 11.2."," Permanent registrations in this registry are assigned using the"," Specification Required policy ([RFC8126]), except for values between"," 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using"," Standards Action or IESG Approval as defined in Sections 4.9 and 4.10"," of [RFC8126].","",[[[],0," "],[[789,1268],225,"In addition to common fields as described in Section 11.2, permanent"]],[[[],0," "],[[789,1268],225,"registrations in this registry MUST include the following fields:"]],""," Stream Type: A name or label for the stream type.",""," Sender: Which endpoint on an HTTP/3 connection may initiate a stream"," of this type. Values are \"Client\", \"Server\", or \"Both\".","",[[[],0," "],[[790,1269],225,"Specifications for permanent registrations MUST include a description"]],[[[],0," "],[[790,1269],225,"of the stream type, including the layout and semantics of the stream"]],[[[],0," "],[[790,1269],225,"contents."]],""," The entries in Table 5 are registered by this document.",""," +================+=======+===============+========+"," | Stream Type | Value | Specification | Sender |"," +================+=======+===============+========+"," | Control Stream | 0x00 | Section 6.2.1 | Both |"," +----------------+-------+---------------+--------+"," | Push Stream | 0x01 | Section 4.6 | Server |"," +----------------+-------+---------------+--------+",""," Table 5: Initial Stream Types","",[[[],0," "],[[791,1270],225,"Each code of the format 0x1f * N + 0x21 for non-negative integer"]],[[[],0," "],[[791,1270],225,"values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)"]],[[[],0," "],[[791,1270],225,"MUST NOT be assigned by IANA and MUST NOT appear in the listing of"]],[[[],0," "],[[791,1270],225,"assigned values."]]],"requirements":[789,790,791]},{"id":"section-12","title":"References","lines":[]},{"id":"section-12.1","title":"Normative References","lines":[" [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, \"HTTP"," Alternative Services\", RFC 7838, DOI 10.17487/RFC7838,"," April 2016, .",""," [COOKIES] Barth, A., \"HTTP State Management Mechanism\", RFC 6265,"," DOI 10.17487/RFC6265, April 2011,"," .",""," [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,"," Ed., \"HTTP Semantics\", STD 97, RFC 9110,"," DOI 10.17487/RFC9110, June 2022,"," .",""," [HTTP-CACHING]"," Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,"," Ed., \"HTTP Caching\", STD 98, RFC 9111,"," DOI 10.17487/RFC9111, June 2022,"," .",""," [HTTP-REPLAY]"," Thomson, M., Nottingham, M., and W. Tarreau, \"Using Early"," Data in HTTP\", RFC 8470, DOI 10.17487/RFC8470, September"," 2018, .",""," [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., \"QPACK:"," Field Compression for HTTP/3\", RFC 9204,"," DOI 10.17487/RFC9204, June 2022,"," .",""," [QUIC-TRANSPORT]"," Iyengar, J., Ed. and M. Thomson, Ed., \"QUIC: A UDP-Based"," Multiplexed and Secure Transport\", RFC 9000,"," DOI 10.17487/RFC9000, May 2021,"," .",""," [RFC0793] Postel, J., \"Transmission Control Protocol\", STD 7,"," RFC 793, DOI 10.17487/RFC0793, September 1981,"," .",""," [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate"," Requirement Levels\", BCP 14, RFC 2119,"," DOI 10.17487/RFC2119, March 1997,"," .",""," [RFC6066] Eastlake 3rd, D., \"Transport Layer Security (TLS)"," Extensions: Extension Definitions\", RFC 6066,"," DOI 10.17487/RFC6066, January 2011,"," .",""," [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,"," \"Transport Layer Security (TLS) Application-Layer Protocol"," Negotiation Extension\", RFC 7301, DOI 10.17487/RFC7301,"," July 2014, .",""," [RFC8126] Cotton, M., Leiba, B., and T. Narten, \"Guidelines for"," Writing an IANA Considerations Section in RFCs\", BCP 26,"," RFC 8126, DOI 10.17487/RFC8126, June 2017,"," .",""," [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC"," 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,"," May 2017, .",""," [URI] Berners-Lee, T., Fielding, R., and L. Masinter, \"Uniform"," Resource Identifier (URI): Generic Syntax\", STD 66,"," RFC 3986, DOI 10.17487/RFC3986, January 2005,"," ."]},{"id":"section-12.2","title":"Informative References","lines":[" [BREACH] Gluck, Y., Harris, N., and A. Prado, \"BREACH: Reviving the"," CRIME Attack\", July 2013,"," .",""," [DNS-TERMS]"," Hoffman, P., Sullivan, A., and K. Fujiwara, \"DNS"," Terminology\", BCP 219, RFC 8499, DOI 10.17487/RFC8499,"," January 2019, .",""," [HPACK] Peon, R. and H. Ruellan, \"HPACK: Header Compression for"," HTTP/2\", RFC 7541, DOI 10.17487/RFC7541, May 2015,"," .",""," [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,"," Ed., \"HTTP/1.1\", STD 99, RFC 9112, DOI 10.17487/RFC9112,"," June 2022, .",""," [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., \"HTTP/2\", RFC 9113,"," DOI 10.17487/RFC9113, June 2022,"," .",""," [RFC6585] Nottingham, M. and R. Fielding, \"Additional HTTP Status"," Codes\", RFC 6585, DOI 10.17487/RFC6585, April 2012,"," .",""," [RFC8164] Nottingham, M. and M. Thomson, \"Opportunistic Security for"," HTTP/2\", RFC 8164, DOI 10.17487/RFC8164, May 2017,"," .",""," [TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, \"TCP"," Fast Open\", RFC 7413, DOI 10.17487/RFC7413, December 2014,"," .",""," [TLS] Rescorla, E., \"The Transport Layer Security (TLS) Protocol"," Version 1.3\", RFC 8446, DOI 10.17487/RFC8446, August 2018,"," ."]},{"id":"appendix-A","title":"Considerations for Transitioning from HTTP/2","lines":[" HTTP/3 is strongly informed by HTTP/2, and it bears many"," similarities. This section describes the approach taken to design"," HTTP/3, points out important differences from HTTP/2, and describes"," how to map HTTP/2 extensions into HTTP/3.",""," HTTP/3 begins from the premise that similarity to HTTP/2 is"," preferable, but not a hard requirement. HTTP/3 departs from HTTP/2"," where QUIC differs from TCP, either to take advantage of QUIC"," features (like streams) or to accommodate important shortcomings"," (such as a lack of total ordering). While HTTP/3 is similar to"," HTTP/2 in key aspects, such as the relationship of requests and"," responses to streams, the details of the HTTP/3 design are"," substantially different from HTTP/2.",""," Some important departures are noted in this section."]},{"id":"appendix-A.1","title":"Streams","lines":[" HTTP/3 permits use of a larger number of streams (2^62-1) than"," HTTP/2. The same considerations about exhaustion of stream"," identifier space apply, though the space is significantly larger such"," that it is likely that other limits in QUIC are reached first, such"," as the limit on the connection flow-control window.",""," In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by"," QUIC. QUIC considers a stream closed when all data has been received"," and sent data has been acknowledged by the peer. HTTP/2 considers a"," stream closed when the frame containing the END_STREAM bit has been"," committed to the transport. As a result, the stream for an"," equivalent exchange could remain \"active\" for a longer period of"," time. HTTP/3 servers might choose to permit a larger number of"," concurrent client-initiated bidirectional streams to achieve"," equivalent concurrency to HTTP/2, depending on the expected usage"," patterns.",""," In HTTP/2, only request and response bodies (the frame payload of"," DATA frames) are subject to flow control. All HTTP/3 frames are sent"," on QUIC streams, so all frames on all streams are flow controlled in"," HTTP/3.",""," Due to the presence of other unidirectional stream types, HTTP/3 does"," not rely exclusively on the number of concurrent unidirectional"," streams to control the number of concurrent in-flight pushes."," Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the"," number of pushes received from an HTTP/3 server."]},{"id":"appendix-A.2","title":"HTTP Frame Types","lines":[" Many framing concepts from HTTP/2 can be elided on QUIC, because the"," transport deals with them. Because frames are already on a stream,"," they can omit the stream number. Because frames do not block"," multiplexing (QUIC's multiplexing occurs below this layer), the"," support for variable-maximum-length packets can be removed. Because"," stream termination is handled by QUIC, an END_STREAM flag is not"," required. This permits the removal of the Flags field from the"," generic frame layout.",""," Frame payloads are largely drawn from [HTTP/2]. However, QUIC"," includes many features (e.g., flow control) that are also present in"," HTTP/2. In these cases, the HTTP mapping does not re-implement them."," As a result, several HTTP/2 frame types are not required in HTTP/3."," Where an HTTP/2-defined frame is no longer used, the frame ID has"," been reserved in order to maximize portability between HTTP/2 and"," HTTP/3 implementations. However, even frame types that appear in"," both mappings do not have identical semantics.",""," Many of the differences arise from the fact that HTTP/2 provides an"," absolute ordering between frames across all streams, while QUIC"," provides this guarantee on each stream only. As a result, if a frame"," type makes assumptions that frames from different streams will still"," be received in the order sent, HTTP/3 will break them.",""," Some examples of feature adaptations are described below, as well as"," general guidance to extension frame implementors converting an HTTP/2"," extension to HTTP/3."]},{"id":"appendix-A.2.1","title":"Prioritization Differences","lines":[" HTTP/2 specifies priority assignments in PRIORITY frames and"," (optionally) in HEADERS frames. HTTP/3 does not provide a means of"," signaling priority.",""," Note that, while there is no explicit signaling for priority, this"," does not mean that prioritization is not important for achieving good"," performance."]},{"id":"appendix-A.2.2","title":"Field Compression Differences","lines":[" HPACK was designed with the assumption of in-order delivery. A"," sequence of encoded field sections must arrive (and be decoded) at an"," endpoint in the same order in which they were encoded. This ensures"," that the dynamic state at the two endpoints remains in sync.",""," Because this total ordering is not provided by QUIC, HTTP/3 uses a"," modified version of HPACK, called QPACK. QPACK uses a single"," unidirectional stream to make all modifications to the dynamic table,"," ensuring a total order of updates. All frames that contain encoded"," fields merely reference the table state at a given time without"," modifying it.",""," [QPACK] provides additional details."]},{"id":"appendix-A.2.3","title":"Flow-Control Differences","lines":[" HTTP/2 specifies a stream flow-control mechanism. Although all"," HTTP/2 frames are delivered on streams, only the DATA frame payload"," is subject to flow control. QUIC provides flow control for stream"," data and all HTTP/3 frame types defined in this document are sent on"," streams. Therefore, all frame headers and payload are subject to"," flow control."]},{"id":"appendix-A.2.4","title":"Guidance for New Frame Type Definitions","lines":[" Frame type definitions in HTTP/3 often use the QUIC variable-length"," integer encoding. In particular, stream IDs use this encoding, which"," allows for a larger range of possible values than the encoding used"," in HTTP/2. Some frames in HTTP/3 use an identifier other than a"," stream ID (e.g., push IDs). Redefinition of the encoding of"," extension frame types might be necessary if the encoding includes a"," stream ID.",""," Because the Flags field is not present in generic HTTP/3 frames,"," those frames that depend on the presence of flags need to allocate"," space for flags as part of their frame payload.",""," Other than these issues, frame type HTTP/2 extensions are typically"," portable to QUIC simply by replacing stream 0 in HTTP/2 with a"," control stream in HTTP/3. HTTP/3 extensions will not assume"," ordering, but would not be harmed by ordering, and are expected to be"," portable to HTTP/2."]},{"id":"appendix-A.2.5","title":"Comparison of HTTP/2 and HTTP/3 Frame Types","lines":[" DATA (0x00): Padding is not defined in HTTP/3 frames. See"," Section 7.2.1.",""," HEADERS (0x01): The PRIORITY region of HEADERS is not defined in"," HTTP/3 frames. Padding is not defined in HTTP/3 frames. See"," Section 7.2.2.",""," PRIORITY (0x02): As described in Appendix A.2.1, HTTP/3 does not"," provide a means of signaling priority.",""," RST_STREAM (0x03): RST_STREAM frames do not exist in HTTP/3, since"," QUIC provides stream lifecycle management. The same code point is"," used for the CANCEL_PUSH frame (Section 7.2.3).",""," SETTINGS (0x04): SETTINGS frames are sent only at the beginning of"," the connection. See Section 7.2.4 and Appendix A.3.",""," PUSH_PROMISE (0x05): The PUSH_PROMISE frame does not reference a"," stream; instead, the push stream references the PUSH_PROMISE frame"," using a push ID. See Section 7.2.5.",""," PING (0x06): PING frames do not exist in HTTP/3, as QUIC provides"," equivalent functionality.",""," GOAWAY (0x07): GOAWAY does not contain an error code. In the"," client-to-server direction, it carries a push ID instead of a"," server-initiated stream ID. See Section 7.2.6.",""," WINDOW_UPDATE (0x08): WINDOW_UPDATE frames do not exist in HTTP/3,"," since QUIC provides flow control.",""," CONTINUATION (0x09): CONTINUATION frames do not exist in HTTP/3;"," instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are"," permitted.",""," Frame types defined by extensions to HTTP/2 need to be separately"," registered for HTTP/3 if still applicable. The IDs of frames defined"," in [HTTP/2] have been reserved for simplicity. Note that the frame"," type space in HTTP/3 is substantially larger (62 bits versus 8 bits),"," so many HTTP/3 frame types have no equivalent HTTP/2 code points."," See Section 11.2.1."]},{"id":"appendix-A.3","title":"HTTP/2 SETTINGS Parameters","lines":[" An important difference from HTTP/2 is that settings are sent once,"," as the first frame of the control stream, and thereafter cannot"," change. This eliminates many corner cases around synchronization of"," changes.",""," Some transport-level options that HTTP/2 specifies via the SETTINGS"," frame are superseded by QUIC transport parameters in HTTP/3. The"," HTTP-level setting that is retained in HTTP/3 has the same value as"," in HTTP/2. The superseded settings are reserved, and their receipt"," is an error. See Section 7.2.4.1 for discussion of both the retained"," and reserved values.",""," Below is a listing of how each HTTP/2 SETTINGS parameter is mapped:",""," SETTINGS_HEADER_TABLE_SIZE (0x01): See [QPACK].",""," SETTINGS_ENABLE_PUSH (0x02): This is removed in favor of the"," MAX_PUSH_ID frame, which provides a more granular control over"," server push. Specifying a setting with the identifier 0x02"," (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the"," HTTP/3 SETTINGS frame is an error.",""," SETTINGS_MAX_CONCURRENT_STREAMS (0x03): QUIC controls the largest"," open stream ID as part of its flow-control logic. Specifying a"," setting with the identifier 0x03 (corresponding to the"," SETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 SETTINGS"," frame is an error.",""," SETTINGS_INITIAL_WINDOW_SIZE (0x04): QUIC requires both stream and"," connection flow-control window sizes to be specified in the"," initial transport handshake. Specifying a setting with the"," identifier 0x04 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE"," parameter) in the HTTP/3 SETTINGS frame is an error.",""," SETTINGS_MAX_FRAME_SIZE (0x05): This setting has no equivalent in"," HTTP/3. Specifying a setting with the identifier 0x05"," (corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) in the"," HTTP/3 SETTINGS frame is an error.",""," SETTINGS_MAX_HEADER_LIST_SIZE (0x06): This setting identifier has"," been renamed SETTINGS_MAX_FIELD_SECTION_SIZE.",""," In HTTP/3, setting values are variable-length integers (6, 14, 30, or"," 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2."," This will often produce a shorter encoding, but can produce a longer"," encoding for settings that use the full 32-bit space. Settings"," ported from HTTP/2 might choose to redefine their value to limit it"," to 30 bits for more efficient encoding or to make use of the 62-bit"," space if more than 30 bits are required.",""," Settings need to be defined separately for HTTP/2 and HTTP/3. The"," IDs of settings defined in [HTTP/2] have been reserved for"," simplicity. Note that the settings identifier space in HTTP/3 is"," substantially larger (62 bits versus 16 bits), so many HTTP/3"," settings have no equivalent HTTP/2 code point. See Section 11.2.2.",""," As QUIC streams might arrive out of order, endpoints are advised not"," to wait for the peers' settings to arrive before responding to other"," streams. See Section 7.2.4.2."]},{"id":"appendix-A.4","title":"HTTP/2 Error Codes","lines":[" QUIC has the same concepts of \"stream\" and \"connection\" errors that"," HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3"," mean that error codes are not directly portable between versions.",""," The HTTP/2 error codes defined in Section 7 of [HTTP/2] logically map"," to the HTTP/3 error codes as follows:",""," NO_ERROR (0x00): H3_NO_ERROR in Section 8.1.",""," PROTOCOL_ERROR (0x01): This is mapped to H3_GENERAL_PROTOCOL_ERROR"," except in cases where more specific error codes have been defined."," Such cases include H3_FRAME_UNEXPECTED, H3_MESSAGE_ERROR, and"," H3_CLOSED_CRITICAL_STREAM defined in Section 8.1.",""," INTERNAL_ERROR (0x02): H3_INTERNAL_ERROR in Section 8.1.",""," FLOW_CONTROL_ERROR (0x03): Not applicable, since QUIC handles flow"," control.",""," SETTINGS_TIMEOUT (0x04): Not applicable, since no acknowledgment of"," SETTINGS is defined.",""," STREAM_CLOSED (0x05): Not applicable, since QUIC handles stream"," management.",""," FRAME_SIZE_ERROR (0x06): H3_FRAME_ERROR error code defined in"," Section 8.1.",""," REFUSED_STREAM (0x07): H3_REQUEST_REJECTED (in Section 8.1) is used"," to indicate that a request was not processed. Otherwise, not"," applicable because QUIC handles stream management.",""," CANCEL (0x08): H3_REQUEST_CANCELLED in Section 8.1.",""," COMPRESSION_ERROR (0x09): Multiple error codes are defined in"," [QPACK].",""," CONNECT_ERROR (0x0a): H3_CONNECT_ERROR in Section 8.1.",""," ENHANCE_YOUR_CALM (0x0b): H3_EXCESSIVE_LOAD in Section 8.1.",""," INADEQUATE_SECURITY (0x0c): Not applicable, since QUIC is assumed to"," provide sufficient security on all connections.",""," HTTP_1_1_REQUIRED (0x0d): H3_VERSION_FALLBACK in Section 8.1.",""," Error codes need to be defined for HTTP/2 and HTTP/3 separately. See"," Section 11.2.3."]},{"id":"appendix-A.4.1","title":"Mapping between HTTP/2 and HTTP/3 Errors","lines":[" An intermediary that converts between HTTP/2 and HTTP/3 may encounter"," error conditions from either upstream. It is useful to communicate"," the occurrence of errors to the downstream, but error codes largely"," reflect connection-local problems that generally do not make sense to"," propagate.",""," An intermediary that encounters an error from an upstream origin can"," indicate this by sending an HTTP status code such as 502 (Bad"," Gateway), which is suitable for a broad class of errors.",""," There are some rare cases where it is beneficial to propagate the"," error by mapping it to the closest matching error type to the"," receiver. For example, an intermediary that receives an HTTP/2"," stream error of type REFUSED_STREAM from the origin has a clear"," signal that the request was not processed and that the request is"," safe to retry. Propagating this error condition to the client as an"," HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to"," take the action it deems most appropriate. In the reverse direction,"," the intermediary might deem it beneficial to pass on client request"," cancellations that are indicated by terminating a stream with"," H3_REQUEST_CANCELLED; see Section 4.1.1.",""," Conversion between errors is described in the logical mapping. The"," error codes are defined in non-overlapping spaces in order to protect"," against accidental conversion that could result in the use of"," inappropriate or unknown error codes for the target version. An"," intermediary is permitted to promote stream errors to connection"," errors but they should be aware of the cost to the HTTP/3 connection"," for what might be a temporary or intermittent error."]},{"id":"name-acknowledgments","title":"Acknowledgments","lines":[" Robbie Shade and Mike Warres were the authors of draft-shade-quic-"," http2-mapping, a precursor of this document.",""," The IETF QUIC Working Group received an enormous amount of support"," from many people. Among others, the following people provided"," substantial contributions to this document:",""," * Bence Beky"," * Daan De Meyer"," * Martin Duke"," * Roy Fielding"," * Alan Frindell"," * Alessandro Ghedini"," * Nick Harper"," * Ryan Hamilton"," * Christian Huitema"," * Subodh Iyengar"," * Robin Marx"," * Patrick McManus"," * Luca Niccolini"," * 奥 一穂 (Kazuho Oku)"," * Lucas Pardue"," * Roberto Peon"," * Julian Reschke"," * Eric Rescorla"," * Martin Seemann"," * Ben Schwartz"," * Ian Swett"," * Willy Taureau"," * Martin Thomson"," * Dmitri Tikhonov"," * Tatsuhiro Tsujikawa",""," A portion of Mike Bishop's contribution was supported by Microsoft"," during his employment there."]},{"id":"name-index","title":"Index","lines":[" C D G H M P R S",""," C",""," CANCEL_PUSH Section 2, Paragraph 5; Section 4.6, Paragraph 6;"," Section 4.6, Paragraph 10; Table 1; *_Section 7.2.3_*;"," Section 7.2.5, Paragraph 4.2.1; Section 7.2.7, Paragraph 1;"," Table 2; Appendix A.2.5, Paragraph 1.8.1"," connection error Section 2.2; Section 4.1, Paragraph 7;"," Section 4.1, Paragraph 8; Section 4.4, Paragraph 8;"," Section 4.4, Paragraph 10; Section 4.6, Paragraph 3;"," Section 5.2, Paragraph 7; Section 6.1, Paragraph 3;"," Section 6.2, Paragraph 7; Section 6.2.1, Paragraph 2;"," Section 6.2.1, Paragraph 2; Section 6.2.1, Paragraph 2;"," Section 6.2.2, Paragraph 3; Section 6.2.2, Paragraph 6;"," Section 7.1, Paragraph 5; Section 7.1, Paragraph 6;"," Section 7.2.1, Paragraph 2; Section 7.2.2, Paragraph 3;"," Section 7.2.3, Paragraph 5; Section 7.2.3, Paragraph 7;"," Section 7.2.3, Paragraph 8; Section 7.2.4, Paragraph 2;"," Section 7.2.4, Paragraph 3; Section 7.2.4, Paragraph 6;"," Section 7.2.4.1, Paragraph 5; Section 7.2.4.2, Paragraph 8;"," Section 7.2.4.2, Paragraph 8; Section 7.2.5, Paragraph 5;"," Section 7.2.5, Paragraph 6; Section 7.2.5, Paragraph 8;"," Section 7.2.5, Paragraph 9; Section 7.2.6, Paragraph 3;"," Section 7.2.6, Paragraph 5; Section 7.2.7, Paragraph 2;"," Section 7.2.7, Paragraph 3; Section 7.2.7, Paragraph 6;"," Section 7.2.8, Paragraph 3; *_Section 8_*; Section 10.5,"," Paragraph 7; Appendix A.4.1, Paragraph 4"," control stream Section 2, Paragraph 3; Section 3.2, Paragraph"," 4; Section 6.2, Paragraph 3; Section 6.2, Paragraph 5;"," Section 6.2, Paragraph 6; *_Section 6.2.1_*; Section 7,"," Paragraph 1; Section 7.2.1, Paragraph 2; Section 7.2.2,"," Paragraph 3; Section 7.2.3, Paragraph 5; Section 7.2.3,"," Paragraph 5; Section 7.2.4, Paragraph 2; Section 7.2.4,"," Paragraph 2; Section 7.2.4, Paragraph 3; Section 7.2.5,"," Paragraph 8; Section 7.2.6, Paragraph 3; Section 7.2.6,"," Paragraph 5; Section 7.2.7, Paragraph 2; Section 8.1,"," Paragraph 2.22.1; Section 9, Paragraph 4; Appendix A.2.4,"," Paragraph 3; Appendix A.3, Paragraph 1",""," D",""," DATA Section 2, Paragraph 3; Section 4.1, Paragraph 5, Item 2;"," Section 4.1, Paragraph 7; Section 4.1, Paragraph 7;"," Section 4.1.2, Paragraph 3; Section 4.1.2, Paragraph 3;"," Section 4.4, Paragraph 7; Section 4.4, Paragraph 7;"," Section 4.4, Paragraph 7; Section 4.4, Paragraph 7;"," Section 4.4, Paragraph 8; Section 4.6, Paragraph 12;"," Table 1; *_Section 7.2.1_*; Table 2; Appendix A.1, Paragraph"," 3; Appendix A.2.3, Paragraph 1; Appendix A.2.5",""," G",""," GOAWAY Section 3.3, Paragraph 5; Section 5.2, Paragraph 1;"," Section 5.2, Paragraph 1; Section 5.2, Paragraph 1;"," Section 5.2, Paragraph 2; Section 5.2, Paragraph 2;"," Section 5.2, Paragraph 3; Section 5.2, Paragraph 5.1.1;"," Section 5.2, Paragraph 5.1.1; Section 5.2, Paragraph 5.1.2;"," Section 5.2, Paragraph 5.1.2; Section 5.2, Paragraph 5, Item"," 2; Section 5.2, Paragraph 5, Item 2; Section 5.2, Paragraph"," 6; Section 5.2, Paragraph 6; Section 5.2, Paragraph 7;"," Section 5.2, Paragraph 7; Section 5.2, Paragraph 8;"," Section 5.2, Paragraph 8; Section 5.2, Paragraph 9;"," Section 5.2, Paragraph 9; Section 5.2, Paragraph 10;"," Section 5.2, Paragraph 12; Section 5.3, Paragraph 2;"," Section 5.3, Paragraph 2; Section 5.4, Paragraph 2; Table 1;"," *_Section 7.2.6_*; Table 2; Appendix A.2.5; Appendix A.2.5,"," Paragraph 1.16.1",""," H",""," H3_CLOSED_CRITICAL_STREAM Section 6.2.1, Paragraph 2;"," Section 8.1; Table 4; Appendix A.4, Paragraph 3.4.1"," H3_CONNECT_ERROR Section 4.4, Paragraph 10; Section 8.1;"," Table 4; Appendix A.4, Paragraph 3.22.1"," H3_EXCESSIVE_LOAD Section 8.1; Section 10.5, Paragraph 7;"," Table 4; Appendix A.4, Paragraph 3.24.1"," H3_FRAME_ERROR Section 7.1, Paragraph 5; Section 7.1,"," Paragraph 6; Section 8.1; Table 4; Appendix A.4, Paragraph"," 3.14.1"," H3_FRAME_UNEXPECTED Section 4.1, Paragraph 7; Section 4.1,"," Paragraph 8; Section 4.4, Paragraph 8; Section 7.2.1,"," Paragraph 2; Section 7.2.2, Paragraph 3; Section 7.2.3,"," Paragraph 5; Section 7.2.4, Paragraph 2; Section 7.2.4,"," Paragraph 3; Section 7.2.5, Paragraph 8; Section 7.2.5,"," Paragraph 9; Section 7.2.6, Paragraph 5; Section 7.2.7,"," Paragraph 2; Section 7.2.7, Paragraph 3; Section 7.2.8,"," Paragraph 3; Section 8.1; Table 4; Appendix A.4, Paragraph"," 3.4.1"," H3_GENERAL_PROTOCOL_ERROR Section 7.2.5, Paragraph 6;"," Section 8.1; Table 4; Appendix A.4, Paragraph 3.4.1"," H3_ID_ERROR Section 4.6, Paragraph 3; Section 5.2, Paragraph"," 7; Section 6.2.2, Paragraph 6; Section 7.2.3, Paragraph 7;"," Section 7.2.3, Paragraph 8; Section 7.2.5, Paragraph 5;"," Section 7.2.6, Paragraph 3; Section 7.2.7, Paragraph 6;"," Section 8.1; Table 4"," H3_INTERNAL_ERROR Section 8.1; Table 4; Appendix A.4,"," Paragraph 3.6.1"," H3_MESSAGE_ERROR Section 4.1.2, Paragraph 4; Section 8.1;"," Table 4; Appendix A.4, Paragraph 3.4.1"," H3_MISSING_SETTINGS Section 6.2.1, Paragraph 2; Section 8.1;"," Table 4"," H3_NO_ERROR Section 4.1, Paragraph 15; Section 5.2, Paragraph"," 11; Section 6.2.3, Paragraph 2; Section 8, Paragraph 5;"," Section 8.1; Section 8.1, Paragraph 3; Section 8.1,"," Paragraph 3; Table 4; Appendix A.4, Paragraph 3.2.1"," H3_REQUEST_CANCELLED Section 4.1.1, Paragraph 4;"," Section 4.1.1, Paragraph 5; Section 4.6, Paragraph 14;"," Section 7.2.3, Paragraph 3; Section 7.2.3, Paragraph 4;"," Section 8.1; Table 4; Appendix A.4, Paragraph 3.18.1;"," Appendix A.4.1, Paragraph 3"," H3_REQUEST_INCOMPLETE Section 4.1, Paragraph 14; Section 8.1;"," Table 4"," H3_REQUEST_REJECTED Section 4.1.1, Paragraph 3; Section 4.1.1,"," Paragraph 4; Section 4.1.1, Paragraph 5; Section 4.1.1,"," Paragraph 5; Section 8.1; Table 4; Appendix A.4, Paragraph"," 3.16.1; Appendix A.4.1, Paragraph 3"," H3_SETTINGS_ERROR Section 7.2.4, Paragraph 6; Section 7.2.4.1,"," Paragraph 5; Section 7.2.4.2, Paragraph 8; Section 7.2.4.2,"," Paragraph 8; Section 8.1; Table 4"," H3_STREAM_CREATION_ERROR Section 6.1, Paragraph 3;"," Section 6.2, Paragraph 7; Section 6.2.1, Paragraph 2;"," Section 6.2.2, Paragraph 3; Section 8.1; Table 4"," H3_VERSION_FALLBACK Section 8.1; Table 4; Appendix A.4,"," Paragraph 3.28.1"," HEADERS Section 2, Paragraph 3; Section 4.1, Paragraph 5, Item"," 1; Section 4.1, Paragraph 5, Item 3; Section 4.1, Paragraph"," 7; Section 4.1, Paragraph 7; Section 4.1, Paragraph 7;"," Section 4.1, Paragraph 10; Section 4.4, Paragraph 6;"," Section 4.6, Paragraph 12; Table 1; *_Section 7.2.2_*;"," Section 9, Paragraph 5; Table 2; Appendix A.2.1, Paragraph"," 1; Appendix A.2.5; Appendix A.2.5, Paragraph 1.4.1;"," Appendix A.2.5, Paragraph 1.20.1",""," M",""," malformed Section 4.1, Paragraph 3; *_Section 4.1.2_*;"," Section 4.2, Paragraph 2; Section 4.2, Paragraph 3;"," Section 4.2, Paragraph 5; Section 4.3, Paragraph 3;"," Section 4.3, Paragraph 4; Section 4.3.1, Paragraph 5;"," Section 4.3.2, Paragraph 1; Section 4.4, Paragraph 5;"," Section 8.1, Paragraph 2.30.1; Section 10.3, Paragraph 1;"," Section 10.3, Paragraph 2; Section 10.5.1, Paragraph 2"," MAX_PUSH_ID Section 2, Paragraph 5; Section 4.6, Paragraph 3;"," Section 4.6, Paragraph 3; Section 4.6, Paragraph 3;"," Section 4.6, Paragraph 3; Table 1; Section 7.2.5, Paragraph"," 5; *_Section 7.2.7_*; Table 2; Appendix A.1, Paragraph 4;"," Appendix A.3, Paragraph 4.4.1",""," P",""," push ID *_Section 4.6_*; Section 5.2, Paragraph 1;"," Section 5.2, Paragraph 5, Item 2; Section 5.2, Paragraph 9;"," Section 6.2.2, Paragraph 2; Section 6.2.2, Paragraph 6;"," Section 6.2.2, Paragraph 6; Section 7.2.3, Paragraph 1;"," Section 7.2.3, Paragraph 7; Section 7.2.3, Paragraph 7;"," Section 7.2.3, Paragraph 8; Section 7.2.3, Paragraph 8;"," Section 7.2.5, Paragraph 4.2.1; Section 7.2.5, Paragraph 5;"," Section 7.2.5, Paragraph 5; Section 7.2.5, Paragraph 6;"," Section 7.2.5, Paragraph 6; Section 7.2.5, Paragraph 7;"," Section 7.2.5, Paragraph 7; Section 7.2.5, Paragraph 7;"," Section 7.2.6, Paragraph 4; Section 7.2.7, Paragraph 1;"," Section 7.2.7, Paragraph 4; Section 7.2.7, Paragraph 4;"," Section 7.2.7, Paragraph 6; Section 7.2.7, Paragraph 6;"," Section 8.1, Paragraph 2.18.1; Appendix A.2.5, Paragraph"," 1.12.1; Appendix A.2.5, Paragraph 1.16.1"," push stream Section 4.1, Paragraph 8; Section 4.1, Paragraph"," 9; Section 4.6, Paragraph 3; Section 4.6, Paragraph 5;"," Section 4.6, Paragraph 5; Section 4.6, Paragraph 13;"," Section 4.6, Paragraph 13; Section 4.6, Paragraph 13;"," Section 6.2, Paragraph 3; *_Section 6.2.2_*; Section 7,"," Paragraph 1; Section 7.2.2, Paragraph 3; Section 7.2.3,"," Paragraph 1; Section 7.2.3, Paragraph 2; Section 7.2.3,"," Paragraph 2; Section 7.2.3, Paragraph 2; Section 7.2.3,"," Paragraph 2; Section 7.2.3, Paragraph 3; Section 7.2.3,"," Paragraph 4; Section 7.2.3, Paragraph 4; Section 7.2.3,"," Paragraph 4; Section 7.2.5, Paragraph 4.2.1; Section 7.2.7,"," Paragraph 1; Appendix A.2.5, Paragraph 1.12.1"," PUSH_PROMISE Section 2, Paragraph 5; Section 4.1, Paragraph 8;"," Section 4.1, Paragraph 8; Section 4.1, Paragraph 8;"," Section 4.1, Paragraph 8; Section 4.1, Paragraph 10;"," Section 4.6, Paragraph 4; Section 4.6, Paragraph 10;"," Section 4.6, Paragraph 11; Section 4.6, Paragraph 11;"," Section 4.6, Paragraph 12; Section 4.6, Paragraph 12;"," Section 4.6, Paragraph 13; Section 4.6, Paragraph 13;"," Section 4.6, Paragraph 13; Table 1; Section 7.2.3, Paragraph"," 8; Section 7.2.3, Paragraph 8; *_Section 7.2.5_*;"," Section 7.2.7, Paragraph 1; Section 10.4, Paragraph 1;"," Section 10.5, Paragraph 2; Table 2; Appendix A.2.5;"," Appendix A.2.5, Paragraph 1.12.1; Appendix A.2.5, Paragraph"," 1.12.1; Appendix A.2.5, Paragraph 1.20.1",""," R",""," request stream Section 4.1, Paragraph 1; Section 4.1,"," Paragraph 15; Section 4.1, Paragraph 15; Section 4.1.1,"," Paragraph 1; Section 4.1.1, Paragraph 5; Section 4.4,"," Paragraph 5; Section 4.4, Paragraph 9; Section 4.6,"," Paragraph 4; Section 4.6, Paragraph 4; Section 4.6,"," Paragraph 11; Section 4.6, Paragraph 11; *_Section 6.1_*;"," Section 7, Paragraph 1; Section 7.2.2, Paragraph 3;"," Section 7.2.5, Paragraph 1",""," S",""," SETTINGS Section 3.2, Paragraph 4; Section 3.2, Paragraph 4;"," Section 6.2.1, Paragraph 2; Table 1; Section 7, Paragraph 3;"," *_Section 7.2.4_*; Section 8.1, Paragraph 2.20.1;"," Section 8.1, Paragraph 2.22.1; Section 9, Paragraph 4;"," Section 10.5, Paragraph 4; Table 2; Table 4; Table 4;"," Appendix A.2.5; Appendix A.2.5, Paragraph 1.10.1;"," Appendix A.3, Paragraph 2; Appendix A.3, Paragraph 3;"," Appendix A.3, Paragraph 4.4.1; Appendix A.3, Paragraph"," 4.6.1; Appendix A.3, Paragraph 4.8.1; Appendix A.3,"," Paragraph 4.10.1; Appendix A.4, Paragraph 3.10.1"," SETTINGS_MAX_FIELD_SECTION_SIZE Section 4.2.2, Paragraph 2;"," Section 7.2.4.1; Section 10.5.1, Paragraph 2; Appendix A.3,"," Paragraph 4.12.1"," stream error Section 2.2; Section 4.1.2, Paragraph 4;"," Section 4.4, Paragraph 10; *_Section 8_*; Appendix A.4.1,"," Paragraph 3; Appendix A.4.1, Paragraph 3; Appendix A.4.1,"," Paragraph 4"]},{"id":"name-author-s-address","title":"Author's Address","lines":[" Mike Bishop (editor)"," Akamai"," Email: mbishop@evequefou.be"]}]},"https://www.rfc-editor.org/rfc/rfc9204":{"format":"ietf","requirements":[1004,1005,1006,1007,1008,1009,1010,1011,1012,1013,1014,1015,1016,1017,1018,1019,1020,1021,1022,1023,1024,1025,1026,1027,1028,1029,1030,1031,1032,1033,1034,1035,1036,1037,1038,1039,1040,1041,1042,1043,1044,1045,1046,1047,1048,1049],"sections":[{"id":"name-abstract","title":"Abstract","lines":[" This specification defines QPACK: a compression format for"," efficiently representing HTTP fields that is to be used in HTTP/3."," This is a variation of HPACK compression that seeks to reduce head-"," of-line blocking."]},{"id":"name-status-of-this-memo","title":"Status of This Memo","lines":[" This is an Internet Standards Track document.",""," This document is a product of the Internet Engineering Task Force"," (IETF). It represents the consensus of the IETF community. It has"," received public review and has been approved for publication by the"," Internet Engineering Steering Group (IESG). Further information on"," Internet Standards is available in Section 2 of RFC 7841.",""," Information about the current status of this document, any errata,"," and how to provide feedback on it may be obtained at"," https://www.rfc-editor.org/info/rfc9204."]},{"id":"name-copyright-notice","title":"Copyright Notice","lines":[" Copyright (c) 2022 IETF Trust and the persons identified as the"," document authors. All rights reserved.",""," This document is subject to BCP 78 and the IETF Trust's Legal"," Provisions Relating to IETF Documents"," (https://trustee.ietf.org/license-info) in effect on the date of"," publication of this document. Please review these documents"," carefully, as they describe your rights and restrictions with respect"," to this document. Code Components extracted from this document must"," include Revised BSD License text as described in Section 4.e of the"," Trust Legal Provisions and are provided without warranty as described"," in the Revised BSD License."]},{"id":"name-table-of-contents","title":"Table of Contents","lines":[" 1. Introduction"," 1.1. Conventions and Definitions"," 1.2. Notational Conventions"," 2. Compression Process Overview"," 2.1. Encoder"," 2.1.1. Limits on Dynamic Table Insertions"," 2.1.2. Blocked Streams"," 2.1.3. Avoiding Flow-Control Deadlocks"," 2.1.4. Known Received Count"," 2.2. Decoder"," 2.2.1. Blocked Decoding"," 2.2.2. State Synchronization"," 2.2.3. Invalid References"," 3. Reference Tables"," 3.1. Static Table"," 3.2. Dynamic Table"," 3.2.1. Dynamic Table Size"," 3.2.2. Dynamic Table Capacity and Eviction"," 3.2.3. Maximum Dynamic Table Capacity"," 3.2.4. Absolute Indexing"," 3.2.5. Relative Indexing"," 3.2.6. Post-Base Indexing"," 4. Wire Format"," 4.1. Primitives"," 4.1.1. Prefixed Integers"," 4.1.2. String Literals"," 4.2. Encoder and Decoder Streams"," 4.3. Encoder Instructions"," 4.3.1. Set Dynamic Table Capacity"," 4.3.2. Insert with Name Reference"," 4.3.3. Insert with Literal Name"," 4.3.4. Duplicate"," 4.4. Decoder Instructions"," 4.4.1. Section Acknowledgment"," 4.4.2. Stream Cancellation"," 4.4.3. Insert Count Increment"," 4.5. Field Line Representations"," 4.5.1. Encoded Field Section Prefix"," 4.5.2. Indexed Field Line"," 4.5.3. Indexed Field Line with Post-Base Index"," 4.5.4. Literal Field Line with Name Reference"," 4.5.5. Literal Field Line with Post-Base Name Reference"," 4.5.6. Literal Field Line with Literal Name"," 5. Configuration"," 6. Error Handling"," 7. Security Considerations"," 7.1. Probing Dynamic Table State"," 7.1.1. Applicability to QPACK and HTTP"," 7.1.2. Mitigation"," 7.1.3. Never-Indexed Literals"," 7.2. Static Huffman Encoding"," 7.3. Memory Consumption"," 7.4. Implementation Limits"," 8. IANA Considerations"," 8.1. Settings Registration"," 8.2. Stream Type Registration"," 8.3. Error Code Registration"," 9. References"," 9.1. Normative References"," 9.2. Informative References"," Appendix A. Static Table"," Appendix B. Encoding and Decoding Examples"," B.1. Literal Field Line with Name Reference"," B.2. Dynamic Table"," B.3. Speculative Insert"," B.4. Duplicate Instruction, Stream Cancellation"," B.5. Dynamic Table Insert, Eviction"," Appendix C. Sample Single-Pass Encoding Algorithm"," Acknowledgments"," Authors' Addresses"]},{"id":"section-1","title":"Introduction","lines":[" The QUIC transport protocol ([QUIC-TRANSPORT]) is designed to support"," HTTP semantics, and its design subsumes many of the features of"," HTTP/2 ([HTTP/2]). HTTP/2 uses HPACK ([RFC7541]) for compression of"," the header and trailer sections. If HPACK were used for HTTP/3"," ([HTTP/3]), it would induce head-of-line blocking for field sections"," due to built-in assumptions of a total ordering across frames on all"," streams.",""," QPACK reuses core concepts from HPACK, but is redesigned to allow"," correctness in the presence of out-of-order delivery, with"," flexibility for implementations to balance between resilience against"," head-of-line blocking and optimal compression ratio. The design"," goals are to closely approach the compression ratio of HPACK with"," substantially less head-of-line blocking under the same loss"," conditions."]},{"id":"section-1.1","title":"Conventions and Definitions","lines":[" 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 [RFC2119] [RFC8174] when, and only when, they appear in all"," capitals, as shown here.",""," The following terms are used in this document:",""," HTTP fields: Metadata sent as part of an HTTP message. The term"," encompasses both header and trailer fields. Colloquially, the"," term \"headers\" has often been used to refer to HTTP header fields"," and trailer fields; this document uses \"fields\" for generality.",""," HTTP field line: A name-value pair sent as part of an HTTP field"," section. See Sections 6.3 and 6.5 of [HTTP].",""," HTTP field value: Data associated with a field name, composed from"," all field line values with that field name in that section,"," concatenated together with comma separators.",""," Field section: An ordered collection of HTTP field lines associated"," with an HTTP message. A field section can contain multiple field"," lines with the same name. It can also contain duplicate field"," lines. An HTTP message can include both header and trailer"," sections.",""," Representation: An instruction that represents a field line,"," possibly by reference to the dynamic and static tables.",""," Encoder: An implementation that encodes field sections.",""," Decoder: An implementation that decodes encoded field sections.",""," Absolute Index: A unique index for each entry in the dynamic table.",""," Base: A reference point for relative and post-Base indices."," Representations that reference dynamic table entries are relative"," to a Base.",""," Insert Count: The total number of entries inserted in the dynamic"," table.",""," Note that QPACK is a name, not an abbreviation."]},{"id":"section-1.2","title":"Notational Conventions","lines":[" Diagrams in this document use the format described in Section 3.1 of"," [RFC2360], with the following additional conventions:",""," x (A) Indicates that x is A bits long.",""," x (A+) Indicates that x uses the prefixed integer encoding defined"," in Section 4.1.1, beginning with an A-bit prefix.",""," x ... Indicates that x is variable length and extends to the end of"," the region."]},{"id":"section-2","title":"Compression Process Overview","lines":[" Like HPACK, QPACK uses two tables for associating field lines"," (\"headers\") to indices. The static table (Section 3.1) is predefined"," and contains common header field lines (some of them with an empty"," value). The dynamic table (Section 3.2) is built up over the course"," of the connection and can be used by the encoder to index both header"," and trailer field lines in the encoded field sections.",""," QPACK defines unidirectional streams for sending instructions from"," encoder to decoder and vice versa."]},{"id":"section-2.1","title":"Encoder","lines":[" An encoder converts a header or trailer section into a series of"," representations by emitting either an indexed or a literal"," representation for each field line in the list; see Section 4.5."," Indexed representations achieve high compression by replacing the"," literal name and possibly the value with an index to either the"," static or dynamic table. References to the static table and literal"," representations do not require any dynamic state and never risk head-"," of-line blocking. References to the dynamic table risk head-of-line"," blocking if the encoder has not received an acknowledgment indicating"," the entry is available at the decoder.","",[[[],0," "],[[1008,1390],97,"An encoder MAY insert any entry in the dynamic table it chooses; it"]],[[[],0," "],[[1008,1390],97,"is not limited to field lines it is compressing."]],""," QPACK preserves the ordering of field lines within each field",[[[],0," section. "],[[1009,1586],240,"An encoder MUST emit field representations in the order"]],[[[],0," "],[[1009,1586],240,"they appear in the input field section."]],""," QPACK is designed to place the burden of optional state tracking on"," the encoder, resulting in relatively simple decoders."],"requirements":[1008,1009]},{"id":"section-2.1.1","title":"Limits on Dynamic Table Insertions","lines":[" Inserting entries into the dynamic table might not be possible if the"," table contains entries that cannot be evicted.",""," A dynamic table entry cannot be evicted immediately after insertion,"," even if it has never been referenced. Once the insertion of a"," dynamic table entry has been acknowledged and there are no"," outstanding references to the entry in unacknowledged"," representations, the entry becomes evictable. Note that references"," on the encoder stream never preclude the eviction of an entry,"," because those references are guaranteed to be processed before the"," instruction evicting the entry.","",[[[],0," "],[[1004,1559],240,"If the dynamic table does not contain enough room for a new entry"]],[[[],0," "],[[1004,1559],240,"without evicting other entries, and the entries that would be evicted"]],[[[],0," "],[[1004,1559],240,"are not evictable, the encoder MUST NOT insert that entry into the"]],[[[],0," "],[[1004,1559],240,"dynamic table (including duplicates of existing entries)."],[[],0," In order"]]," to avoid this, an encoder that uses the dynamic table has to keep"," track of each dynamic table entry referenced by each field section"," until those representations are acknowledged by the decoder; see"," Section 4.4.1."],"requirements":[1004]},{"id":"section-2.1.1.1","title":"Avoiding Prohibited Insertions","lines":[" To ensure that the encoder is not prevented from adding new entries,"," the encoder can avoid referencing entries that are close to eviction."," Rather than reference such an entry, the encoder can emit a Duplicate"," instruction (Section 4.3.4) and reference the duplicate instead.",""," Determining which entries are too close to eviction to reference is"," an encoder preference. One heuristic is to target a fixed amount of"," available space in the dynamic table: either unused space or space"," that can be reclaimed by evicting non-blocking entries. To achieve"," this, the encoder can maintain a draining index, which is the"," smallest absolute index (Section 3.2.4) in the dynamic table that it"," will emit a reference for. As new entries are inserted, the encoder"," increases the draining index to maintain the section of the table"," that it will not reference. If the encoder does not create new"," references to entries with an absolute index lower than the draining"," index, the number of unacknowledged references to those entries will"," eventually become zero, allowing them to be evicted.",""," <-- Newer Entries Older Entries -->"," (Larger Indices) (Smaller Indices)"," +--------+---------------------------------+----------+"," | Unused | Referenceable | Draining |"," | Space | Entries | Entries |"," +--------+---------------------------------+----------+"," ^ ^ ^"," | | |"," Insertion Point Draining Index Dropping"," Point",""," Figure 1: Draining Dynamic Table Entries"]},{"id":"section-2.1.2","title":"Blocked Streams","lines":[" Because QUIC does not guarantee order between data on different"," streams, a decoder might encounter a representation that references a"," dynamic table entry that it has not yet received.",""," Each encoded field section contains a Required Insert Count"," (Section 4.5.1), the lowest possible value for the Insert Count with"," which the field section can be decoded. For a field section encoded"," using references to the dynamic table, the Required Insert Count is"," one larger than the largest absolute index of all referenced dynamic"," table entries. For a field section encoded with no references to the"," dynamic table, the Required Insert Count is zero.",""," When the decoder receives an encoded field section with a Required"," Insert Count greater than its own Insert Count, the stream cannot be"," processed immediately and is considered \"blocked\"; see Section 2.2.1.",""," The decoder specifies an upper bound on the number of streams that"," can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting; see",[[[],0," Section 5. "],[[1005,1558],240,"An encoder MUST limit the number of streams that could"]],[[[],0," "],[[1005,1558],240,"become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all"]],[[[],0," "],[[1005,1558],240,"times."],[[],0," "],[[1006,1589,3123],244,"If a decoder encounters more blocked streams than it promised"]],[[[],0," "],[[1006,1589,3123],244,"to support, it MUST treat this as a connection error of type"]],[[[],0," "],[[1006,1589,3123],244,"QPACK_DECOMPRESSION_FAILED."]],""," Note that the decoder might not become blocked on every stream that"," risks becoming blocked.",""," An encoder can decide whether to risk having a stream become blocked."," If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS,"," compression efficiency can often be improved by referencing dynamic"," table entries that are still in transit, but if there is loss or"," reordering, the stream can become blocked at the decoder. An encoder"," can avoid the risk of blocking by only referencing dynamic table"," entries that have been acknowledged, but this could mean using"," literals. Since literals make the encoded field section larger, this"," can result in the encoder becoming blocked on congestion or flow-"," control limits."],"requirements":[1005,1006]},{"id":"section-2.1.3","title":"Avoiding Flow-Control Deadlocks","lines":[" Writing instructions on streams that are limited by flow control can"," produce deadlocks.",""," A decoder might stop issuing flow-control credit on the stream that"," carries an encoded field section until the necessary updates are"," received on the encoder stream. If the granting of flow-control"," credit on the encoder stream (or the connection as a whole) depends"," on the consumption and release of data on the stream carrying the"," encoded field section, a deadlock might result.",""," More generally, a stream containing a large instruction can become"," deadlocked if the decoder withholds flow-control credit until the"," instruction is completely received.","",[[[],0," "],[[1007,1382],161,"To avoid these deadlocks, an encoder SHOULD NOT write an instruction"]],[[[],0," "],[[1007,1382],161,"unless sufficient stream and connection flow-control credit is"]],[[[],0," "],[[1007,1382],161,"available for the entire instruction."]]],"requirements":[1007]},{"id":"section-2.1.4","title":"Known Received Count","lines":[" The Known Received Count is the total number of dynamic table"," insertions and duplications acknowledged by the decoder. The encoder"," tracks the Known Received Count in order to identify which dynamic"," table entries can be referenced without potentially blocking a"," stream. The decoder tracks the Known Received Count in order to be"," able to send Insert Count Increment instructions.",""," A Section Acknowledgment instruction (Section 4.4.1) implies that the"," decoder has received all dynamic table state necessary to decode the"," field section. If the Required Insert Count of the acknowledged"," field section is greater than the current Known Received Count, the"," Known Received Count is updated to that Required Insert Count value.",""," An Insert Count Increment instruction (Section 4.4.3) increases the"," Known Received Count by its Increment parameter. See Section 2.2.2.3"," for guidance."]},{"id":"section-2.2","title":"Decoder","lines":[" As in HPACK, the decoder processes a series of representations and"," emits the corresponding field sections. It also processes"," instructions received on the encoder stream that modify the dynamic"," table. Note that encoded field sections and encoder stream"," instructions arrive on separate streams. This is unlike HPACK, where"," encoded field sections (header blocks) can contain instructions that"," modify the dynamic table, and there is no dedicated stream of HPACK"," instructions.","",[[[],0," "],[[1017,1575,3126],244,"The decoder MUST emit field lines in the order their representations"]],[[[],0," "],[[1017,1575,3126],244,"appear in the encoded field section."]]],"requirements":[1017]},{"id":"section-2.2.1","title":"Blocked Decoding","lines":[" Upon receipt of an encoded field section, the decoder examines the"," Required Insert Count. When the Required Insert Count is less than"," or equal to the decoder's Insert Count, the field section can be"," processed immediately. Otherwise, the stream on which the field"," section was received becomes blocked.","",[[[],0," "],[[1010,1383],161,"While blocked, encoded field section data SHOULD remain in the"]],[[[],0," "],[[1010,1383],161,"blocked stream's flow-control window."],[[],0," This data is unusable until"]]," the stream becomes unblocked, and releasing the flow control"," prematurely makes the decoder vulnerable to memory exhaustion"," attacks. A stream becomes unblocked when the Insert Count becomes"," greater than or equal to the Required Insert Count for all encoded"," field sections the decoder has started reading from the stream.",""," When processing encoded field sections, the decoder expects the"," Required Insert Count to equal the lowest possible value for the"," Insert Count with which the field section can be decoded, as",[[[],0," prescribed in Section 2.1.2. "],[[1011,1571,1573,3134,3135,3136],244,"If it encounters a Required Insert"]],[[[],0," "],[[1011,1571,1573,3134,3135,3136],244,"Count smaller than expected, it MUST treat this as a connection error"]],[[[],0," "],[[1011,1571,1573,3134,3135,3136],244,"of type QPACK_DECOMPRESSION_FAILED; see Section 2.2.3."],[[],0," "],[[1012,1391],97,"If it"]],[[[],0," "],[[1012,1391],97,"encounters a Required Insert Count larger than expected, it MAY treat"]],[[[],0," "],[[1012,1391],97,"this as a connection error of type QPACK_DECOMPRESSION_FAILED."]]],"requirements":[1010,1011,1012]},{"id":"section-2.2.2","title":"State Synchronization","lines":[" The decoder signals the following events by emitting decoder"," instructions (Section 4.4) on the decoder stream."]},{"id":"section-2.2.2.1","title":"Completed Processing of a Field Section","lines":[[[[],0," "],[[1013,1580,1590,3116],244,"After the decoder finishes decoding a field section encoded using"]],[[[],0," "],[[1013,1580,1590,3116],244,"representations containing dynamic table references, it MUST emit a"]],[[[],0," "],[[1013,1580,1590,3116],244,"Section Acknowledgment instruction (Section 4.4.1)."],[[],0," A stream may"]]," carry multiple field sections in the case of intermediate responses,"," trailers, and pushed requests. The encoder interprets each"," Section Acknowledgment instruction as acknowledging the earliest"," unacknowledged field section containing dynamic table references sent"," on the given stream."],"requirements":[1013]},{"id":"section-2.2.2.2","title":"Abandonment of a Stream","lines":[" When an endpoint receives a stream reset before the end of a stream"," or before all encoded field sections are processed on that stream, or"," when it abandons reading of a stream, it generates a Stream"," Cancellation instruction; see Section 4.4.2. This signals to the"," encoder that all references to the dynamic table on that stream are",[[[],0," no longer outstanding. "],[[1014,1392],97,"A decoder with a maximum dynamic table"]],[[[],0," "],[[1014,1392],97,"capacity (Section 3.2.3) equal to zero MAY omit sending Stream"]],[[[],0," "],[[1014,1392],97,"Cancellations, because the encoder cannot have any dynamic table"]],[[[],0," "],[[1014,1392],97,"references."],[[],0," An encoder cannot infer from this instruction that any"]]," updates to the dynamic table have been received.",""," The Section Acknowledgment and Stream Cancellation instructions"," permit the encoder to remove references to entries in the dynamic"," table. When an entry with an absolute index lower than the Known"," Received Count has zero references, then it is considered evictable;"," see Section 2.1.1."],"requirements":[1014]},{"id":"section-2.2.2.3","title":"New Table Entries","lines":[" After receiving new table entries on the encoder stream, the decoder"," chooses when to emit Insert Count Increment instructions; see"," Section 4.4.3. Emitting this instruction after adding each new"," dynamic table entry will provide the timeliest feedback to the"," encoder, but could be redundant with other decoder feedback. By"," delaying an Insert Count Increment instruction, the decoder might be"," able to coalesce multiple Insert Count Increment instructions or"," replace them entirely with Section Acknowledgments; see"," Section 4.4.1. However, delaying too long may lead to compression"," inefficiencies if the encoder waits for an entry to be acknowledged"," before using it."]},{"id":"section-2.2.3","title":"Invalid References","lines":[[[[],0," "],[[1015,1570,1572,1574,1576,1577,1578,1579],240,"If the decoder encounters a reference in a field line representation"]],[[[],0," "],[[1015,1570,1572,1574,1576,1577,1578,1579],240,"to a dynamic table entry that has already been evicted or that has an"]],[[[],0," "],[[1015,1570,1572,1574,1576,1577,1578,1579],240,"absolute index greater than or equal to the declared Required Insert"]],[[[],0," "],[[1015,1570,1572,1574,1576,1577,1578,1579],240,"Count (Section 4.5.1), it MUST treat this as a connection error of"]],[[[],0," "],[[1015,1570,1572,1574,1576,1577,1578,1579],240,"type QPACK_DECOMPRESSION_FAILED."]],"",[[[],0," "],[[1016,1581,1582,1583,1584],240,"If the decoder encounters a reference in an encoder instruction to a"]],[[[],0," "],[[1016,1581,1582,1583,1584],240,"dynamic table entry that has already been evicted, it MUST treat this"]],[[[],0," "],[[1016,1581,1582,1583,1584],240,"as a connection error of type QPACK_ENCODER_STREAM_ERROR."]]],"requirements":[1015,1016]},{"id":"section-3","title":"Reference Tables","lines":[" Unlike in HPACK, entries in the QPACK static and dynamic tables are"," addressed separately. The following sections describe how entries in"," each table are addressed."]},{"id":"section-3.1","title":"Static Table","lines":[" The static table consists of a predefined list of field lines, each"," of which has a fixed index over time. Its entries are defined in"," Appendix A.",""," All entries in the static table have a name and a value. However,"," values can be empty (that is, have a length of 0). Each entry is"," identified by a unique index.",""," Note that the QPACK static table is indexed from 0, whereas the HPACK"," static table is indexed from 1.","",[[[],0," "],[[1018,3137],228,"When the decoder encounters an invalid static table index in a field"]],[[[],0," "],[[1018,3137],228,"line representation, it MUST treat this as a connection error of type"]],[[[],0," "],[[1018,3137],228,"QPACK_DECOMPRESSION_FAILED."],[[],0," "],[[1019,3131],228,"If this index is received on the encoder"]],[[[],0," "],[[1019,3131],228,"stream, this MUST be treated as a connection error of type"]],[[[],0," "],[[1019,3131],228,"QPACK_ENCODER_STREAM_ERROR."]]],"requirements":[1018,1019]},{"id":"section-3.2","title":"Dynamic Table","lines":[" The dynamic table consists of a list of field lines maintained in"," first-in, first-out order. A QPACK encoder and decoder share a"," dynamic table that is initially empty. The encoder adds entries to"," the dynamic table and sends them to the decoder via instructions on"," the encoder stream; see Section 4.3.",""," The dynamic table can contain duplicate entries (i.e., entries with",[[[],0," the same name and same value). "],[[1026,1585,3129],244,"Therefore, duplicate entries MUST NOT"]],[[[],0," "],[[1026,1585,3129],244,"be treated as an error by the decoder."]],""," Dynamic table entries can have empty values."],"requirements":[1026]},{"id":"section-3.2.1","title":"Dynamic Table Size","lines":[" The size of the dynamic table is the sum of the size of its entries.",""," The size of an entry is the sum of its name's length in bytes, its"," value's length in bytes, and 32 additional bytes. The size of an"," entry is calculated using the length of its name and value without"," Huffman encoding applied."]},{"id":"section-3.2.2","title":"Dynamic Table Capacity and Eviction","lines":[" The encoder sets the capacity of the dynamic table, which serves as"," the upper limit on its size. The initial capacity of the dynamic"," table is zero. The encoder sends a Set Dynamic Table Capacity"," instruction (Section 4.3.1) with a non-zero capacity to begin using"," the dynamic table.",""," Before a new entry is added to the dynamic table, entries are evicted"," from the end of the dynamic table until the size of the dynamic table",[[[],0," is less than or equal to (table capacity - size of new entry). "],[[1020,1560,1562,3125],244,"The"]],[[[],0," "],[[1020,1560,1562,3125],244,"encoder MUST NOT cause a dynamic table entry to be evicted unless"]],[[[],0," "],[[1020,1560,1562,3125],244,"that entry is evictable; see Section 2.1.1."],[[],0," The new entry is then"]],[[[],0," added to the table. "],[[1021,1561,3130],244,"It is an error if the encoder attempts to add an"]],[[[],0," "],[[1021,1561,3130],244,"entry that is larger than the dynamic table capacity; the decoder"]],[[[],0," "],[[1021,1561,3130],244,"MUST treat this as a connection error of type"]],[[[],0," "],[[1021,1561,3130],244,"QPACK_ENCODER_STREAM_ERROR."]],""," A new entry can reference an entry in the dynamic table that will be"," evicted when adding this new entry into the dynamic table."," Implementations are cautioned to avoid deleting the referenced name"," or value if the referenced entry is evicted from the dynamic table"," prior to inserting the new entry.",""," Whenever the dynamic table capacity is reduced by the encoder"," (Section 4.3.1), entries are evicted from the end of the dynamic"," table until the size of the dynamic table is less than or equal to"," the new table capacity. This mechanism can be used to completely"," clear entries from the dynamic table by setting a capacity of 0,"," which can subsequently be restored."],"requirements":[1020,1021]},{"id":"section-3.2.3","title":"Maximum Dynamic Table Capacity","lines":[" To bound the memory requirements of the decoder, the decoder limits"," the maximum value the encoder is permitted to set for the dynamic"," table capacity. In HTTP/3, this limit is determined by the value of"," SETTINGS_QPACK_MAX_TABLE_CAPACITY sent by the decoder; see Section 5.",[[[],0," "],[[1022,1587],240,"The encoder MUST NOT set a dynamic table capacity that exceeds this"]],[[[],0," "],[[1022,1587],240,"maximum, but it can choose to use a lower dynamic table capacity; see"]],[[[],0," "],[[1022,1587],240,"Section 4.3.1."]],""," For clients using 0-RTT data in HTTP/3, the server's maximum table"," capacity is the remembered value of the setting or zero if the value",[[[],0," was not previously sent. "],[[1023,3110],100,"When the client's 0-RTT value of the"]],[[[],0," "],[[1023,3110],100,"SETTING is zero, the server MAY set it to a non-zero value in its"]],[[[],0," "],[[1023,3110],100,"SETTINGS frame."],[[],0," "],[[1024,1433,1496,1510],240,"If the remembered value is non-zero, the server MUST"]],[[[],0," "],[[1024,1433,1496,1510],240,"send the same non-zero value in its SETTINGS frame."],[[],0," If it specifies"]]," any other value, or omits SETTINGS_QPACK_MAX_TABLE_CAPACITY from"," SETTINGS, the encoder must treat this as a connection error of type"," QPACK_DECODER_STREAM_ERROR.",""," For clients not using 0-RTT data (whether 0-RTT is not attempted or"," is rejected) and for all HTTP/3 servers, the maximum table capacity"," is 0 until the encoder processes a SETTINGS frame with a non-zero"," value of SETTINGS_QPACK_MAX_TABLE_CAPACITY.","",[[[],0," "],[[1025,1588],240,"When the maximum table capacity is zero, the encoder MUST NOT insert"]],[[[],0," "],[[1025,1588],240,"entries into the dynamic table and MUST NOT send any encoder"]],[[[],0," "],[[1025,1588],240,"instructions on the encoder stream."]]],"requirements":[1022,1023,1024,1025]},{"id":"section-3.2.4","title":"Absolute Indexing","lines":[" Each entry possesses an absolute index that is fixed for the lifetime"," of that entry. The first entry inserted has an absolute index of 0;"," indices increase by one with each insertion."]},{"id":"section-3.2.5","title":"Relative Indexing","lines":[" Relative indices begin at zero and increase in the opposite direction"," from the absolute index. Determining which entry has a relative"," index of 0 depends on the context of the reference.",""," In encoder instructions (Section 4.3), a relative index of 0 refers"," to the most recently inserted value in the dynamic table. Note that"," this means the entry referenced by a given relative index will change"," while interpreting instructions on the encoder stream.",""," +-----+---------------+-------+"," | n-1 | ... | d | Absolute Index"," + - - +---------------+ - - - +"," | 0 | ... | n-d-1 | Relative Index"," +-----+---------------+-------+"," ^ |"," | V"," Insertion Point Dropping Point",""," n = count of entries inserted"," d = count of entries dropped",""," Figure 2: Example Dynamic Table Indexing - Encoder Stream",""," Unlike in encoder instructions, relative indices in field line"," representations are relative to the Base at the beginning of the"," encoded field section; see Section 4.5.1. This ensures that"," references are stable even if encoded field sections and dynamic"," table updates are processed out of order.",""," In a field line representation, a relative index of 0 refers to the"," entry with absolute index equal to Base - 1.",""," Base"," |"," V"," +-----+-----+-----+-----+-------+"," | n-1 | n-2 | n-3 | ... | d | Absolute Index"," +-----+-----+ - +-----+ - +"," | 0 | ... | n-d-3 | Relative Index"," +-----+-----+-------+",""," n = count of entries inserted"," d = count of entries dropped"," In this example, Base = n - 2",""," Figure 3: Example Dynamic Table Indexing - Relative Index in"," Representation"]},{"id":"section-3.2.6","title":"Post-Base Indexing","lines":[" Post-Base indices are used in field line representations for entries"," with absolute indices greater than or equal to Base, starting at 0"," for the entry with absolute index equal to Base and increasing in the"," same direction as the absolute index.",""," Post-Base indices allow an encoder to process a field section in a"," single pass and include references to entries added while processing"," this (or other) field sections.",""," Base"," |"," V"," +-----+-----+-----+-----+-----+"," | n-1 | n-2 | n-3 | ... | d | Absolute Index"," +-----+-----+-----+-----+-----+"," | 1 | 0 | Post-Base Index"," +-----+-----+",""," n = count of entries inserted"," d = count of entries dropped"," In this example, Base = n - 2",""," Figure 4: Example Dynamic Table Indexing - Post-Base Index in"," Representation"]},{"id":"section-4","title":"Wire Format","lines":[]},{"id":"section-4.1","title":"Primitives","lines":[]},{"id":"section-4.1.1","title":"Prefixed Integers","lines":[" The prefixed integer from Section 5.1 of [RFC7541] is used heavily"," throughout this document. The format from [RFC7541] is used"," unmodified. Note, however, that QPACK uses some prefix sizes not"," actually used in HPACK.","",[[[],0," "],[[1027,1557],240,"QPACK implementations MUST be able to decode integers up to and"]],[[[],0," "],[[1027,1557],240,"including 62 bits long."]]],"requirements":[1027]},{"id":"section-4.1.2","title":"String Literals","lines":[" The string literal defined by Section 5.2 of [RFC7541] is also used"," throughout. This string format includes optional Huffman encoding.",""," HPACK defines string literals to begin on a byte boundary. They"," begin with a single bit flag, denoted as 'H' in this document"," (indicating whether the string is Huffman encoded), followed by the"," string length encoded as a 7-bit prefix integer, and finally the"," indicated number of bytes of data. When Huffman encoding is enabled,"," the Huffman table from Appendix B of [RFC7541] is used without"," modification and the indicated length is the size of the string after"," encoding.",""," This document expands the definition of string literals by permitting"," them to begin other than on a byte boundary. An \"N-bit prefix string"," literal\" begins mid-byte, with the first (8-N) bits allocated to a"," previous field. The string uses one bit for the Huffman flag,"," followed by the length of the encoded string as a (N-1)-bit prefix"," integer. The prefix size, N, can have a value between 2 and 8,"," inclusive. The remainder of the string literal is unmodified.",""," A string literal without a prefix length noted is an 8-bit prefix"," string literal and follows the definitions in [RFC7541] without"," modification."]},{"id":"section-4.2","title":"Encoder and Decoder Streams","lines":[" QPACK defines two unidirectional stream types:",""," * An encoder stream is a unidirectional stream of type 0x02. It"," carries an unframed sequence of encoder instructions from encoder"," to decoder.",""," * A decoder stream is a unidirectional stream of type 0x03. It"," carries an unframed sequence of decoder instructions from decoder"," to encoder.","",[[[],0," HTTP/3 endpoints contain a QPACK encoder and decoder. "],[[1028,1447,1458,1461,3104,3106],244,"Each endpoint"]],[[[],0," "],[[1028,1447,1458,1461,3104,3106],244,"MUST initiate, at most, one encoder stream and, at most, one decoder"]],[[[],0," "],[[1028,1447,1458,1461,3104,3106],244,"stream."],[[],0," "],[[1029,1459,1462,3105,3107],244,"Receipt of a second instance of either stream type MUST be"]],[[[],0," "],[[1029,1459,1462,3105,3107],244,"treated as a connection error of type H3_STREAM_CREATION_ERROR."]],"",[[[],0," "],[[1030,1451],240,"The sender MUST NOT close either of these streams, and the receiver"]],[[[],0," "],[[1030,1451],240,"MUST NOT request that the sender close either of these streams."]],[[[],0," "],[[1031,1449,1454],240,"Closure of either unidirectional stream type MUST be treated as a"]],[[[],0," "],[[1031,1449,1454],240,"connection error of type H3_CLOSED_CRITICAL_STREAM."]],"",[[[],0," "],[[1032,1393],97,"An endpoint MAY avoid creating an encoder stream if it will not be"]],[[[],0," "],[[1032,1393],97,"used (for example, if its encoder does not wish to use the dynamic"]],[[[],0," "],[[1032,1393],97,"table or if the maximum size of the dynamic table permitted by the"]],[[[],0," "],[[1032,1393],97,"peer is zero)."]],"",[[[],0," "],[[1033,1394],97,"An endpoint MAY avoid creating a decoder stream if its decoder sets"]],[[[],0," "],[[1033,1394],97,"the maximum capacity of the dynamic table to zero."]],"",[[[],0," "],[[1034,1457,1460],240,"An endpoint MUST allow its peer to create an encoder stream and a"]],[[[],0," "],[[1034,1457,1460],240,"decoder stream even if the connection's settings prevent their use."]]],"requirements":[1028,1029,1030,1031,1032,1033,1034]},{"id":"section-4.3","title":"Encoder Instructions","lines":[" An encoder sends encoder instructions on the encoder stream to set"," the capacity of the dynamic table and add dynamic table entries."," Instructions adding table entries can use existing entries to avoid"," transmitting redundant information. The name can be transmitted as a"," reference to an existing entry in the static or the dynamic table or"," as a string literal. For entries that already exist in the dynamic"," table, the full entry can also be used by reference, creating a"," duplicate entry."]},{"id":"section-4.3.1","title":"Set Dynamic Table Capacity","lines":[" An encoder informs the decoder of a change to the dynamic table"," capacity using an instruction that starts with the '001' 3-bit"," pattern. This is followed by the new dynamic table capacity"," represented as an integer with a 5-bit prefix; see Section 4.1.1.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 0 | 0 | 1 | Capacity (5+) |"," +---+---+---+-------------------+",""," Figure 5: Set Dynamic Table Capacity","",[[[],0," "],[[1035,1591,3132],244,"The new capacity MUST be lower than or equal to the limit described"]],[[[],0," "],[[1035,1591,3132],244,"in Section 3.2.3."],[[],0," In HTTP/3, this limit is the value of the"]]," SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter (Section 5) received from",[[[],0," the decoder. "],[[1036,1592,3133],244,"The decoder MUST treat a new dynamic table capacity"]],[[[],0," "],[[1036,1592,3133],244,"value that exceeds this limit as a connection error of type"]],[[[],0," "],[[1036,1592,3133],244,"QPACK_ENCODER_STREAM_ERROR."]],""," Reducing the dynamic table capacity can cause entries to be evicted;",[[[],0," see Section 3.2.2. "],[[1037,1593,3124],244,"This MUST NOT cause the eviction of entries that"]],[[[],0," "],[[1037,1593,3124],244,"are not evictable; see Section 2.1.1."],[[],0," Changing the capacity of the"]]," dynamic table is not acknowledged as this instruction does not insert"," an entry."],"requirements":[1035,1036,1037]},{"id":"section-4.3.2","title":"Insert with Name Reference","lines":[" An encoder adds an entry to the dynamic table where the field name"," matches the field name of an entry stored in the static or the"," dynamic table using an instruction that starts with the '1' 1-bit"," pattern. The second ('T') bit indicates whether the reference is to"," the static or dynamic table. The 6-bit prefix integer"," (Section 4.1.1) that follows is used to locate the table entry for"," the field name. When T=1, the number represents the static table"," index; when T=0, the number is the relative index of the entry in the"," dynamic table.",""," The field name reference is followed by the field value represented"," as a string literal; see Section 4.1.2.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 1 | T | Name Index (6+) |"," +---+---+-----------------------+"," | H | Value Length (7+) |"," +---+---------------------------+"," | Value String (Length bytes) |"," +-------------------------------+",""," Figure 6: Insert Field Line -- Indexed Name"]},{"id":"section-4.3.3","title":"Insert with Literal Name","lines":[" An encoder adds an entry to the dynamic table where both the field"," name and the field value are represented as string literals using an"," instruction that starts with the '01' 2-bit pattern.",""," This is followed by the name represented as a 6-bit prefix string"," literal and the value represented as an 8-bit prefix string literal;"," see Section 4.1.2.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 0 | 1 | H | Name Length (5+) |"," +---+---+---+-------------------+"," | Name String (Length bytes) |"," +---+---------------------------+"," | H | Value Length (7+) |"," +---+---------------------------+"," | Value String (Length bytes) |"," +-------------------------------+",""," Figure 7: Insert Field Line -- New Name"]},{"id":"section-4.3.4","title":"Duplicate","lines":[" An encoder duplicates an existing entry in the dynamic table using an"," instruction that starts with the '000' 3-bit pattern. This is"," followed by the relative index of the existing entry represented as"," an integer with a 5-bit prefix; see Section 4.1.1.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 0 | 0 | 0 | Index (5+) |"," +---+---+---+-------------------+",""," Figure 8: Duplicate",""," The existing entry is reinserted into the dynamic table without"," resending either the name or the value. This is useful to avoid"," adding a reference to an older entry, which might block inserting new"," entries."]},{"id":"section-4.4","title":"Decoder Instructions","lines":[" A decoder sends decoder instructions on the decoder stream to inform"," the encoder about the processing of field sections and table updates"," to ensure consistency of the dynamic table."]},{"id":"section-4.4.1","title":"Section Acknowledgment","lines":[" After processing an encoded field section whose declared Required"," Insert Count is not zero, the decoder emits a Section Acknowledgment"," instruction. The instruction starts with the '1' 1-bit pattern,"," followed by the field section's associated stream ID encoded as a"," 7-bit prefix integer; see Section 4.1.1.",""," This instruction is used as described in Sections 2.1.4 and 2.2.2.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 1 | Stream ID (7+) |"," +---+---------------------------+",""," Figure 9: Section Acknowledgment","",[[[],0," "],[[1038,1594,3127],244,"If an encoder receives a Section Acknowledgment instruction referring"]],[[[],0," "],[[1038,1594,3127],244,"to a stream on which every encoded field section with a non-zero"]],[[[],0," "],[[1038,1594,3127],244,"Required Insert Count has already been acknowledged, this MUST be"]],[[[],0," "],[[1038,1594,3127],244,"treated as a connection error of type QPACK_DECODER_STREAM_ERROR."]],""," The Section Acknowledgment instruction might increase the Known"," Received Count; see Section 2.1.4."],"requirements":[1038]},{"id":"section-4.4.2","title":"Stream Cancellation","lines":[" When a stream is reset or reading is abandoned, the decoder emits a"," Stream Cancellation instruction. The instruction starts with the"," '01' 2-bit pattern, followed by the stream ID of the affected stream"," encoded as a 6-bit prefix integer.",""," This instruction is used as described in Section 2.2.2.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 0 | 1 | Stream ID (6+) |"," +---+---+-----------------------+",""," Figure 10: Stream Cancellation"]},{"id":"section-4.4.3","title":"Insert Count Increment","lines":[" The Insert Count Increment instruction starts with the '00' 2-bit"," pattern, followed by the Increment encoded as a 6-bit prefix integer."," This instruction increases the Known Received Count (Section 2.1.4)"," by the value of the Increment parameter. The decoder should send an"," Increment value that increases the Known Received Count to the total"," number of dynamic table insertions and duplications processed so far.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 0 | 0 | Increment (6+) |"," +---+---+-----------------------+",""," Figure 11: Insert Count Increment","",[[[],0," "],[[1039,3128],228,"An encoder that receives an Increment field equal to zero, or one"]],[[[],0," "],[[1039,3128],228,"that increases the Known Received Count beyond what the encoder has"]],[[[],0," "],[[1039,3128],228,"sent, MUST treat this as a connection error of type"]],[[[],0," "],[[1039,3128],228,"QPACK_DECODER_STREAM_ERROR."]]],"requirements":[1039]},{"id":"section-4.5","title":"Field Line Representations","lines":[" An encoded field section consists of a prefix and a possibly empty"," sequence of representations defined in this section. Each"," representation corresponds to a single field line. These"," representations reference the static table or the dynamic table in a"," particular state, but they do not modify that state.",""," Encoded field sections are carried in frames on streams defined by"," the enclosing protocol."]},{"id":"section-4.5.1","title":"Encoded Field Section Prefix","lines":[" Each encoded field section is prefixed with two integers. The"," Required Insert Count is encoded as an integer with an 8-bit prefix"," using the encoding described in Section 4.5.1.1. The Base is encoded"," as a Sign bit ('S') and a Delta Base value with a 7-bit prefix; see"," Section 4.5.1.2.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | Required Insert Count (8+) |"," +---+---------------------------+"," | S | Delta Base (7+) |"," +---+---------------------------+"," | Encoded Field Lines ..."," +-------------------------------+",""," Figure 12: Encoded Field Section"]},{"id":"section-4.5.1.1","title":"Required Insert Count","lines":[" Required Insert Count identifies the state of the dynamic table"," needed to process the encoded field section. Blocking decoders use"," the Required Insert Count to determine when it is safe to process the"," rest of the field section.",""," The encoder transforms the Required Insert Count as follows before"," encoding:",""," if ReqInsertCount == 0:"," EncInsertCount = 0"," else:"," EncInsertCount = (ReqInsertCount mod (2 * MaxEntries)) + 1",""," Here MaxEntries is the maximum number of entries that the dynamic"," table can have. The smallest entry has empty name and value strings"," and has the size of 32. Hence, MaxEntries is calculated as:",""," MaxEntries = floor( MaxTableCapacity / 32 )",""," MaxTableCapacity is the maximum capacity of the dynamic table as"," specified by the decoder; see Section 3.2.3.",""," This encoding limits the length of the prefix on long-lived"," connections.",""," The decoder can reconstruct the Required Insert Count using an",[[[],0," algorithm such as the following. "],[[1040,1563,1564,1565,1566,3119,3120,3121,3122],244,"If the decoder encounters a value"]],[[[],0," "],[[1040,1563,1564,1565,1566,3119,3120,3121,3122],244,"of EncodedInsertCount that could not have been produced by a"]],[[[],0," "],[[1040,1563,1564,1565,1566,3119,3120,3121,3122],244,"conformant encoder, it MUST treat this as a connection error of type"]],[[[],0," "],[[1040,1563,1564,1565,1566,3119,3120,3121,3122],244,"QPACK_DECOMPRESSION_FAILED."]],""," TotalNumberOfInserts is the total number of inserts into the"," decoder's dynamic table.",""," FullRange = 2 * MaxEntries"," if EncodedInsertCount == 0:"," ReqInsertCount = 0"," else:"," if EncodedInsertCount > FullRange:"," Error"," MaxValue = TotalNumberOfInserts + MaxEntries",""," # MaxWrapped is the largest possible value of"," # ReqInsertCount that is 0 mod 2 * MaxEntries"," MaxWrapped = floor(MaxValue / FullRange) * FullRange"," ReqInsertCount = MaxWrapped + EncodedInsertCount - 1",""," # If ReqInsertCount exceeds MaxValue, the Encoder's value"," # must have wrapped one fewer time"," if ReqInsertCount > MaxValue:"," if ReqInsertCount <= FullRange:"," Error"," ReqInsertCount -= FullRange",""," # Value of 0 must be encoded as 0."," if ReqInsertCount == 0:"," Error",""," For example, if the dynamic table is 100 bytes, then the Required"," Insert Count will be encoded modulo 6. If a decoder has received 10"," inserts, then an encoded value of 4 indicates that the Required"," Insert Count is 9 for the field section."],"requirements":[1040]},{"id":"section-4.5.1.2","title":"Base","lines":[" The Base is used to resolve references in the dynamic table as"," described in Section 3.2.5.",""," To save space, the Base is encoded relative to the Required Insert"," Count using a one-bit Sign ('S' in Figure 12) and the Delta Base"," value. A Sign bit of 0 indicates that the Base is greater than or"," equal to the value of the Required Insert Count; the decoder adds the"," value of Delta Base to the Required Insert Count to determine the"," value of the Base. A Sign bit of 1 indicates that the Base is less"," than the Required Insert Count; the decoder subtracts the value of"," Delta Base from the Required Insert Count and also subtracts one to"," determine the value of the Base. That is:",""," if Sign == 0:"," Base = ReqInsertCount + DeltaBase"," else:"," Base = ReqInsertCount - DeltaBase - 1",""," A single-pass encoder determines the Base before encoding a field"," section. If the encoder inserted entries in the dynamic table while"," encoding the field section and is referencing them, Required Insert"," Count will be greater than the Base, so the encoded difference is"," negative and the Sign bit is set to 1. If the field section was not"," encoded using representations that reference the most recent entry in"," the table and did not insert any new entries, the Base will be"," greater than the Required Insert Count, so the encoded difference"," will be positive and the Sign bit is set to 0.","",[[[],0," "],[[1041,1567,1568,3117],244,"The value of Base MUST NOT be negative."],[[],0," Though the protocol might"]]," operate correctly with a negative Base using post-Base indexing, it",[[[],0," is unnecessary and inefficient. "],[[1042,1569,3118],244,"An endpoint MUST treat a field block"]],[[[],0," "],[[1042,1569,3118],244,"with a Sign bit of 1 as invalid if the value of Required Insert Count"]],[[[],0," "],[[1042,1569,3118],244,"is less than or equal to the value of Delta Base."]],""," An encoder that produces table updates before encoding a field"," section might set Base to the value of Required Insert Count. In"," such a case, both the Sign bit and the Delta Base will be set to"," zero.",""," A field section that was encoded without references to the dynamic"," table can use any value for the Base; setting Delta Base to zero is"," one of the most efficient encodings.",""," For example, with a Required Insert Count of 9, a decoder receives a"," Sign bit of 1 and a Delta Base of 2. This sets the Base to 6 and"," enables post-Base indexing for three entries. In this example, a"," relative index of 1 refers to the fifth entry that was added to the"," table; a post-Base index of 1 refers to the eighth entry."],"requirements":[1041,1042]},{"id":"section-4.5.2","title":"Indexed Field Line","lines":[" An indexed field line representation identifies an entry in the"," static table or an entry in the dynamic table with an absolute index"," less than the value of the Base.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 1 | T | Index (6+) |"," +---+---+-----------------------+",""," Figure 13: Indexed Field Line",""," This representation starts with the '1' 1-bit pattern, followed by"," the 'T' bit, indicating whether the reference is into the static or"," dynamic table. The 6-bit prefix integer (Section 4.1.1) that follows"," is used to locate the table entry for the field line. When T=1, the"," number represents the static table index; when T=0, the number is the"," relative index of the entry in the dynamic table."]},{"id":"section-4.5.3","title":"Indexed Field Line with Post-Base Index","lines":[" An indexed field line with post-Base index representation identifies"," an entry in the dynamic table with an absolute index greater than or"," equal to the value of the Base.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 0 | 0 | 0 | 1 | Index (4+) |"," +---+---+---+---+---------------+",""," Figure 14: Indexed Field Line with Post-Base Index",""," This representation starts with the '0001' 4-bit pattern. This is"," followed by the post-Base index (Section 3.2.6) of the matching field"," line, represented as an integer with a 4-bit prefix; see"," Section 4.1.1."]},{"id":"section-4.5.4","title":"Literal Field Line with Name Reference","lines":[" A literal field line with name reference representation encodes a"," field line where the field name matches the field name of an entry in"," the static table or the field name of an entry in the dynamic table"," with an absolute index less than the value of the Base.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 0 | 1 | N | T |Name Index (4+)|"," +---+---+---+---+---------------+"," | H | Value Length (7+) |"," +---+---------------------------+"," | Value String (Length bytes) |"," +-------------------------------+",""," Figure 15: Literal Field Line with Name Reference",""," This representation starts with the '01' 2-bit pattern. The"," following bit, 'N', indicates whether an intermediary is permitted to",[[[],0," add this field line to the dynamic table on subsequent hops. "],[[1043,1385],225,"When"]],[[[],0," "],[[1043,1385],225,"the 'N' bit is set, the encoded field line MUST always be encoded"]],[[[],0," "],[[1043,1385],225,"with a literal representation."],[[],0," "],[[1044,1386],225,"In particular, when a peer sends a"]],[[[],0," "],[[1044,1386],225,"field line that it received represented as a literal field line with"]],[[[],0," "],[[1044,1386],225,"the 'N' bit set, it MUST use a literal representation to forward this"]],[[[],0," "],[[1044,1386],225,"field line."],[[],0," This bit is intended for protecting field values that"]]," are not to be put at risk by compressing them; see Section 7.1 for"," more details.",""," The fourth ('T') bit indicates whether the reference is to the static"," or dynamic table. The 4-bit prefix integer (Section 4.1.1) that"," follows is used to locate the table entry for the field name. When"," T=1, the number represents the static table index; when T=0, the"," number is the relative index of the entry in the dynamic table.",""," Only the field name is taken from the dynamic table entry; the field"," value is encoded as an 8-bit prefix string literal; see"," Section 4.1.2."],"requirements":[1043,1044]},{"id":"section-4.5.5","title":"Literal Field Line with Post-Base Name Reference","lines":[" A literal field line with post-Base name reference representation"," encodes a field line where the field name matches the field name of a"," dynamic table entry with an absolute index greater than or equal to"," the value of the Base.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 0 | 0 | 0 | 0 | N |NameIdx(3+)|"," +---+---+---+---+---+-----------+"," | H | Value Length (7+) |"," +---+---------------------------+"," | Value String (Length bytes) |"," +-------------------------------+",""," Figure 16: Literal Field Line with Post-Base Name Reference",""," This representation starts with the '0000' 4-bit pattern. The fifth"," bit is the 'N' bit as described in Section 4.5.4. This is followed"," by a post-Base index of the dynamic table entry (Section 3.2.6)"," encoded as an integer with a 3-bit prefix; see Section 4.1.1.",""," Only the field name is taken from the dynamic table entry; the field"," value is encoded as an 8-bit prefix string literal; see"," Section 4.1.2."]},{"id":"section-4.5.6","title":"Literal Field Line with Literal Name","lines":[" The literal field line with literal name representation encodes a"," field name and a field value as string literals.",""," 0 1 2 3 4 5 6 7"," +---+---+---+---+---+---+---+---+"," | 0 | 0 | 1 | N | H |NameLen(3+)|"," +---+---+---+---+---+-----------+"," | Name String (Length bytes) |"," +---+---------------------------+"," | H | Value Length (7+) |"," +---+---------------------------+"," | Value String (Length bytes) |"," +-------------------------------+",""," Figure 17: Literal Field Line with Literal Name",""," This representation starts with the '001' 3-bit pattern. The fourth"," bit is the 'N' bit as described in Section 4.5.4. The name follows,"," represented as a 4-bit prefix string literal, then the value,"," represented as an 8-bit prefix string literal; see Section 4.1.2."]},{"id":"section-5","title":"Configuration","lines":[" QPACK defines two settings for the HTTP/3 SETTINGS frame:",""," SETTINGS_QPACK_MAX_TABLE_CAPACITY (0x01): The default value is zero."," See Section 3.2 for usage. This is the equivalent of the"," SETTINGS_HEADER_TABLE_SIZE from HTTP/2.",""," SETTINGS_QPACK_BLOCKED_STREAMS (0x07): The default value is zero."," See Section 2.1.2."]},{"id":"section-6","title":"Error Handling","lines":[" The following error codes are defined for HTTP/3 to indicate failures"," of QPACK that prevent the stream or connection from continuing:",""," QPACK_DECOMPRESSION_FAILED (0x0200): The decoder failed to interpret"," an encoded field section and is not able to continue decoding that"," field section.",""," QPACK_ENCODER_STREAM_ERROR (0x0201): The decoder failed to interpret"," an encoder instruction received on the encoder stream.",""," QPACK_DECODER_STREAM_ERROR (0x0202): The encoder failed to interpret"," a decoder instruction received on the decoder stream."]},{"id":"section-7","title":"Security Considerations","lines":[" This section describes potential areas of security concern with"," QPACK:",""," * Use of compression as a length-based oracle for verifying guesses"," about secrets that are compressed into a shared compression"," context.",""," * Denial of service resulting from exhausting processing or memory"," capacity at a decoder."]},{"id":"section-7.1","title":"Probing Dynamic Table State","lines":[" QPACK reduces the encoded size of field sections by exploiting the"," redundancy inherent in protocols like HTTP. The ultimate goal of"," this is to reduce the amount of data that is required to send HTTP"," requests or responses.",""," The compression context used to encode header and trailer fields can"," be probed by an attacker who can both define fields to be encoded and"," transmitted and observe the length of those fields once they are"," encoded. When an attacker can do both, they can adaptively modify"," requests in order to confirm guesses about the dynamic table state."," If a guess is compressed into a shorter length, the attacker can"," observe the encoded length and infer that the guess was correct.",""," This is possible even over the Transport Layer Security Protocol"," ([TLS]) and the QUIC Transport Protocol ([QUIC-TRANSPORT]), because"," while TLS and QUIC provide confidentiality protection for content,"," they only provide a limited amount of protection for the length of"," that content.",""," | Note: Padding schemes only provide limited protection against"," | an attacker with these capabilities, potentially only forcing"," | an increased number of guesses to learn the length associated"," | with a given guess. Padding schemes also work directly against"," | compression by increasing the number of bits that are"," | transmitted.",""," Attacks like CRIME ([CRIME]) demonstrated the existence of these"," general attacker capabilities. The specific attack exploited the"," fact that DEFLATE ([RFC1951]) removes redundancy based on prefix"," matching. This permitted the attacker to confirm guesses a character"," at a time, reducing an exponential-time attack into a linear-time"," attack."]},{"id":"section-7.1.1","title":"Applicability to QPACK and HTTP","lines":[" QPACK mitigates, but does not completely prevent, attacks modeled on"," CRIME ([CRIME]) by forcing a guess to match an entire field line"," rather than individual characters. An attacker can only learn"," whether a guess is correct or not, so the attacker is reduced to a"," brute-force guess for the field values associated with a given field"," name.",""," Therefore, the viability of recovering specific field values depends"," on the entropy of values. As a result, values with high entropy are"," unlikely to be recovered successfully. However, values with low"," entropy remain vulnerable.",""," Attacks of this nature are possible any time that two mutually"," distrustful entities control requests or responses that are placed"," onto a single HTTP/3 connection. If the shared QPACK compressor"," permits one entity to add entries to the dynamic table, and the other"," to refer to those entries while encoding chosen field lines, then the"," attacker (the second entity) can learn the state of the table by"," observing the length of the encoded output.",""," For example, requests or responses from mutually distrustful entities"," can occur when an intermediary either:",""," * sends requests from multiple clients on a single connection toward"," an origin server, or",""," * takes responses from multiple origin servers and places them on a"," shared connection toward a client.",""," Web browsers also need to assume that requests made on the same"," connection by different web origins ([RFC6454]) are made by mutually"," distrustful entities. Other scenarios involving mutually distrustful"," entities are also possible."]},{"id":"section-7.1.2","title":"Mitigation","lines":[" Users of HTTP that require confidentiality for header or trailer"," fields can use values with entropy sufficient to make guessing"," infeasible. However, this is impractical as a general solution"," because it forces all users of HTTP to take steps to mitigate"," attacks. It would impose new constraints on how HTTP is used.",""," Rather than impose constraints on users of HTTP, an implementation of"," QPACK can instead constrain how compression is applied in order to"," limit the potential for dynamic table probing.",""," An ideal solution segregates access to the dynamic table based on the"," entity that is constructing the message. Field values that are added"," to the table are attributed to an entity, and only the entity that"," created a particular value can extract that value.",""," To improve compression performance of this option, certain entries"," might be tagged as being public. For example, a web browser might"," make the values of the Accept-Encoding header field available in all"," requests.",""," An encoder without good knowledge of the provenance of field values"," might instead introduce a penalty for many field lines with the same"," field name and different values. This penalty could cause a large"," number of attempts to guess a field value to result in the field not"," being compared to the dynamic table entries in future messages,"," effectively preventing further guesses.",""," This response might be made inversely proportional to the length of"," the field value. Disabling access to the dynamic table for a given"," field name might occur for shorter values more quickly or with higher"," probability than for longer values.",""," This mitigation is most effective between two endpoints. If messages"," are re-encoded by an intermediary without knowledge of which entity"," constructed a given message, the intermediary could inadvertently"," merge compression contexts that the original encoder had specifically"," kept separate.",""," | Note: Simply removing entries corresponding to the field from"," | the dynamic table can be ineffectual if the attacker has a"," | reliable way of causing values to be reinstalled. For example,"," | a request to load an image in a web browser typically includes"," | the Cookie header field (a potentially highly valued target for"," | this sort of attack), and websites can easily force an image to"," | be loaded, thereby refreshing the entry in the dynamic table."]},{"id":"section-7.1.3","title":"Never-Indexed Literals","lines":[" Implementations can also choose to protect sensitive fields by not"," compressing them and instead encoding their value as literals.",""," Refusing to insert a field line into the dynamic table is only"," effective if doing so is avoided on all hops. The never-indexed"," literal bit (see Section 4.5.4) can be used to signal to"," intermediaries that a particular value was intentionally sent as a"," literal.","",[[[],0," "],[[1045,1387],225,"An intermediary MUST NOT re-encode a value that uses a literal"]],[[[],0," "],[[1045,1387],225,"representation with the 'N' bit set with another representation that"]],[[[],0," "],[[1045,1387],225,"would index it."],[[],0," "],[[1046,1388],225,"If QPACK is used for re-encoding, a literal"]],[[[],0," "],[[1046,1388],225,"representation with the 'N' bit set MUST be used."],[[],0," "],[[1047,1389],225,"If HPACK is used"]],[[[],0," "],[[1047,1389],225,"for re-encoding, the never-indexed literal representation (see"]],[[[],0," "],[[1047,1389],225,"Section 6.2.3 of [RFC7541]) MUST be used."]],""," The choice to mark that a field value should never be indexed depends"," on several factors. Since QPACK does not protect against guessing an"," entire field value, short or low-entropy values are more readily"," recovered by an adversary. Therefore, an encoder might choose not to"," index values with low entropy.",""," An encoder might also choose not to index values for fields that are"," considered to be highly valuable or sensitive to recovery, such as"," the Cookie or Authorization header fields.",""," On the contrary, an encoder might prefer indexing values for fields"," that have little or no value if they were exposed. For instance, a"," User-Agent header field does not commonly vary between requests and"," is sent to any server. In that case, confirmation that a particular"," User-Agent value has been used provides little value.",""," Note that these criteria for deciding to use a never-indexed literal"," representation will evolve over time as new attacks are discovered."],"requirements":[1045,1046,1047]},{"id":"section-7.2","title":"Static Huffman Encoding","lines":[" There is no currently known attack against a static Huffman encoding."," A study has shown that using a static Huffman encoding table created"," an information leakage; however, this same study concluded that an"," attacker could not take advantage of this information leakage to"," recover any meaningful amount of information (see [PETAL])."]},{"id":"section-7.3","title":"Memory Consumption","lines":[" An attacker can try to cause an endpoint to exhaust its memory."," QPACK is designed to limit both the peak and stable amounts of memory"," allocated by an endpoint.",""," QPACK uses the definition of the maximum size of the dynamic table"," and the maximum number of blocking streams to limit the amount of"," memory the encoder can cause the decoder to consume. In HTTP/3,"," these values are controlled by the decoder through the settings"," parameters SETTINGS_QPACK_MAX_TABLE_CAPACITY and"," SETTINGS_QPACK_BLOCKED_STREAMS, respectively (see Section 3.2.3 and"," Section 2.1.2). The limit on the size of the dynamic table takes"," into account the size of the data stored in the dynamic table, plus a"," small allowance for overhead. The limit on the number of blocked"," streams is only a proxy for the maximum amount of memory required by"," the decoder. The actual maximum amount of memory will depend on how"," much memory the decoder uses to track each blocked stream.",""," A decoder can limit the amount of state memory used for the dynamic"," table by setting an appropriate value for the maximum size of the"," dynamic table. In HTTP/3, this is realized by setting an appropriate"," value for the SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter. An"," encoder can limit the amount of state memory it uses by choosing a"," smaller dynamic table size than the decoder allows and signaling this"," to the decoder (see Section 4.3.1).",""," A decoder can limit the amount of state memory used for blocked"," streams by setting an appropriate value for the maximum number of"," blocked streams. In HTTP/3, this is realized by setting an"," appropriate value for the SETTINGS_QPACK_BLOCKED_STREAMS parameter."," Streams that risk becoming blocked consume no additional state memory"," on the encoder.",""," An encoder allocates memory to track all dynamic table references in"," unacknowledged field sections. An implementation can directly limit"," the amount of state memory by only using as many references to the"," dynamic table as it wishes to track; no signaling to the decoder is"," required. However, limiting references to the dynamic table will"," reduce compression effectiveness.",""," The amount of temporary memory consumed by an encoder or decoder can"," be limited by processing field lines sequentially. A decoder"," implementation does not need to retain a complete list of field lines"," while decoding a field section. An encoder implementation does not"," need to retain a complete list of field lines while encoding a field"," section if it is using a single-pass algorithm. Note that it might"," be necessary for an application to retain a complete list of field"," lines for other reasons; even if QPACK does not force this to occur,"," application constraints might make this necessary.",""," While the negotiated limit on the dynamic table size accounts for"," much of the memory that can be consumed by a QPACK implementation,"," data that cannot be immediately sent due to flow control is not"," affected by this limit. Implementations should limit the size of"," unsent data, especially on the decoder stream where flexibility to"," choose what to send is limited. Possible responses to an excess of"," unsent data might include limiting the ability of the peer to open"," new streams, reading only from the encoder stream, or closing the"," connection."]},{"id":"section-7.4","title":"Implementation Limits","lines":[" An implementation of QPACK needs to ensure that large values for"," integers, long encoding for integers, or long string literals do not"," create security weaknesses.",""," An implementation has to set a limit for the values it accepts for"," integers, as well as for the encoded length; see Section 4.1.1. In"," the same way, it has to set a limit to the length it accepts for",[[[],0," string literals; see Section 4.1.2. "],[[1048,1384],161,"These limits SHOULD be large"]],[[[],0," "],[[1048,1384],161,"enough to process the largest individual field the HTTP"]],[[[],0," "],[[1048,1384],161,"implementation can be configured to accept."]],"",[[[],0," "],[[1049,1465,1466],240,"If an implementation encounters a value larger than it is able to"]],[[[],0," "],[[1049,1465,1466],240,"decode, this MUST be treated as a stream error of type"]],[[[],0," "],[[1049,1465,1466],240,"QPACK_DECOMPRESSION_FAILED if on a request stream or a connection"]],[[[],0," "],[[1049,1465,1466],240,"error of the appropriate type if on the encoder or decoder stream."]]],"requirements":[1048,1049]},{"id":"section-8","title":"IANA Considerations","lines":[" This document makes multiple registrations in the registries defined"," by [HTTP/3]. The allocations created by this document are all"," assigned permanent status and list a change controller of the IETF"," and a contact of the HTTP working group (ietf-http-wg@w3.org)."]},{"id":"section-8.1","title":"Settings Registration","lines":[" This document specifies two settings. The entries in the following"," table are registered in the \"HTTP/3 Settings\" registry established in"," [HTTP/3].",""," +==========================+======+===============+=========+"," | Setting Name | Code | Specification | Default |"," +==========================+======+===============+=========+"," | QPACK_MAX_TABLE_CAPACITY | 0x01 | Section 5 | 0 |"," +--------------------------+------+---------------+---------+"," | QPACK_BLOCKED_STREAMS | 0x07 | Section 5 | 0 |"," +--------------------------+------+---------------+---------+",""," Table 1: Additions to the HTTP/3 Settings Registry",""," For formatting reasons, the setting names here are abbreviated by"," removing the 'SETTINGS_' prefix."]},{"id":"section-8.2","title":"Stream Type Registration","lines":[" This document specifies two stream types. The entries in the"," following table are registered in the \"HTTP/3 Stream Types\" registry"," established in [HTTP/3].",""," +======================+======+===============+========+"," | Stream Type | Code | Specification | Sender |"," +======================+======+===============+========+"," | QPACK Encoder Stream | 0x02 | Section 4.2 | Both |"," +----------------------+------+---------------+--------+"," | QPACK Decoder Stream | 0x03 | Section 4.2 | Both |"," +----------------------+------+---------------+--------+",""," Table 2: Additions to the HTTP/3 Stream Types Registry"]},{"id":"section-8.3","title":"Error Code Registration","lines":[" This document specifies three error codes. The entries in the"," following table are registered in the \"HTTP/3 Error Codes\" registry"," established in [HTTP/3].",""," +============================+========+=============+===============+"," | Name | Code |Description | Specification |"," +============================+========+=============+===============+"," | QPACK_DECOMPRESSION_FAILED | 0x0200 |Decoding of a| Section 6 |"," | | |field section| |"," | | |failed | |"," +----------------------------+--------+-------------+---------------+"," | QPACK_ENCODER_STREAM_ERROR | 0x0201 |Error on the | Section 6 |"," | | |encoder | |"," | | |stream | |"," +----------------------------+--------+-------------+---------------+"," | QPACK_DECODER_STREAM_ERROR | 0x0202 |Error on the | Section 6 |"," | | |decoder | |"," | | |stream | |"," +----------------------------+--------+-------------+---------------+",""," Table 3: Additions to the HTTP/3 Error Codes Registry"]},{"id":"section-9","title":"References","lines":[]},{"id":"section-9.1","title":"Normative References","lines":[" [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,"," Ed., \"HTTP Semantics\", STD 97, RFC 9110,"," DOI 10.17487/RFC9110, June 2022,"," .",""," [HTTP/3] Bishop, M., Ed., \"HTTP/3\", RFC 9114, DOI 10.17487/RFC9114,"," June 2022, .",""," [QUIC-TRANSPORT]"," Iyengar, J., Ed. and M. Thomson, Ed., \"QUIC: A UDP-Based"," Multiplexed and Secure Transport\", RFC 9000,"," DOI 10.17487/RFC9000, May 2021,"," .",""," [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate"," Requirement Levels\", BCP 14, RFC 2119,"," DOI 10.17487/RFC2119, March 1997,"," .",""," [RFC2360] Scott, G., \"Guide for Internet Standards Writers\", BCP 22,"," RFC 2360, DOI 10.17487/RFC2360, June 1998,"," .",""," [RFC7541] Peon, R. and H. Ruellan, \"HPACK: Header Compression for"," HTTP/2\", RFC 7541, DOI 10.17487/RFC7541, May 2015,"," .",""," [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC"," 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,"," May 2017, ."]},{"id":"section-9.2","title":"Informative References","lines":[" [CRIME] Wikipedia, \"CRIME\", May 2015, .",""," [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., \"HTTP/2\", RFC 9113,"," DOI 10.17487/RFC9113, June 2022,"," .",""," [PETAL] Tan, J. and J. Nahata, \"PETAL: Preset Encoding"," Table Information Leakage\", April 2013,"," .",""," [RFC1951] Deutsch, P., \"DEFLATE Compressed Data Format Specification"," version 1.3\", RFC 1951, DOI 10.17487/RFC1951, May 1996,"," .",""," [RFC6454] Barth, A., \"The Web Origin Concept\", RFC 6454,"," DOI 10.17487/RFC6454, December 2011,"," .",""," [TLS] Rescorla, E., \"The Transport Layer Security (TLS) Protocol"," Version 1.3\", RFC 8446, DOI 10.17487/RFC8446, August 2018,"," ."]},{"id":"appendix-A","title":"Static Table","lines":[" This table was generated by analyzing actual Internet traffic in 2018"," and including the most common header fields, after filtering out some"," unsupported and non-standard values. Due to this methodology, some"," of the entries may be inconsistent or appear multiple times with"," similar but not identical values. The order of the entries is"," optimized to encode the most common header fields with the smallest"," number of bytes.",""," +=======+==================================+=======================+"," | Index | Name | Value |"," +=======+==================================+=======================+"," | 0 | :authority | |"," +-------+----------------------------------+-----------------------+"," | 1 | :path | / |"," +-------+----------------------------------+-----------------------+"," | 2 | age | 0 |"," +-------+----------------------------------+-----------------------+"," | 3 | content-disposition | |"," +-------+----------------------------------+-----------------------+"," | 4 | content-length | 0 |"," +-------+----------------------------------+-----------------------+"," | 5 | cookie | |"," +-------+----------------------------------+-----------------------+"," | 6 | date | |"," +-------+----------------------------------+-----------------------+"," | 7 | etag | |"," +-------+----------------------------------+-----------------------+"," | 8 | if-modified-since | |"," +-------+----------------------------------+-----------------------+"," | 9 | if-none-match | |"," +-------+----------------------------------+-----------------------+"," | 10 | last-modified | |"," +-------+----------------------------------+-----------------------+"," | 11 | link | |"," +-------+----------------------------------+-----------------------+"," | 12 | location | |"," +-------+----------------------------------+-----------------------+"," | 13 | referer | |"," +-------+----------------------------------+-----------------------+"," | 14 | set-cookie | |"," +-------+----------------------------------+-----------------------+"," | 15 | :method | CONNECT |"," +-------+----------------------------------+-----------------------+"," | 16 | :method | DELETE |"," +-------+----------------------------------+-----------------------+"," | 17 | :method | GET |"," +-------+----------------------------------+-----------------------+"," | 18 | :method | HEAD |"," +-------+----------------------------------+-----------------------+"," | 19 | :method | OPTIONS |"," +-------+----------------------------------+-----------------------+"," | 20 | :method | POST |"," +-------+----------------------------------+-----------------------+"," | 21 | :method | PUT |"," +-------+----------------------------------+-----------------------+"," | 22 | :scheme | http |"," +-------+----------------------------------+-----------------------+"," | 23 | :scheme | https |"," +-------+----------------------------------+-----------------------+"," | 24 | :status | 103 |"," +-------+----------------------------------+-----------------------+"," | 25 | :status | 200 |"," +-------+----------------------------------+-----------------------+"," | 26 | :status | 304 |"," +-------+----------------------------------+-----------------------+"," | 27 | :status | 404 |"," +-------+----------------------------------+-----------------------+"," | 28 | :status | 503 |"," +-------+----------------------------------+-----------------------+"," | 29 | accept | */* |"," +-------+----------------------------------+-----------------------+"," | 30 | accept | application/dns- |"," | | | message |"," +-------+----------------------------------+-----------------------+"," | 31 | accept-encoding | gzip, deflate, br |"," +-------+----------------------------------+-----------------------+"," | 32 | accept-ranges | bytes |"," +-------+----------------------------------+-----------------------+"," | 33 | access-control-allow-headers | cache-control |"," +-------+----------------------------------+-----------------------+"," | 34 | access-control-allow-headers | content-type |"," +-------+----------------------------------+-----------------------+"," | 35 | access-control-allow-origin | * |"," +-------+----------------------------------+-----------------------+"," | 36 | cache-control | max-age=0 |"," +-------+----------------------------------+-----------------------+"," | 37 | cache-control | max-age=2592000 |"," +-------+----------------------------------+-----------------------+"," | 38 | cache-control | max-age=604800 |"," +-------+----------------------------------+-----------------------+"," | 39 | cache-control | no-cache |"," +-------+----------------------------------+-----------------------+"," | 40 | cache-control | no-store |"," +-------+----------------------------------+-----------------------+"," | 41 | cache-control | public, max- |"," | | | age=31536000 |"," +-------+----------------------------------+-----------------------+"," | 42 | content-encoding | br |"," +-------+----------------------------------+-----------------------+"," | 43 | content-encoding | gzip |"," +-------+----------------------------------+-----------------------+"," | 44 | content-type | application/dns- |"," | | | message |"," +-------+----------------------------------+-----------------------+"," | 45 | content-type | application/ |"," | | | javascript |"," +-------+----------------------------------+-----------------------+"," | 46 | content-type | application/json |"," +-------+----------------------------------+-----------------------+"," | 47 | content-type | application/x-www- |"," | | | form-urlencoded |"," +-------+----------------------------------+-----------------------+"," | 48 | content-type | image/gif |"," +-------+----------------------------------+-----------------------+"," | 49 | content-type | image/jpeg |"," +-------+----------------------------------+-----------------------+"," | 50 | content-type | image/png |"," +-------+----------------------------------+-----------------------+"," | 51 | content-type | text/css |"," +-------+----------------------------------+-----------------------+"," | 52 | content-type | text/html; |"," | | | charset=utf-8 |"," +-------+----------------------------------+-----------------------+"," | 53 | content-type | text/plain |"," +-------+----------------------------------+-----------------------+"," | 54 | content-type | text/ |"," | | | plain;charset=utf-8 |"," +-------+----------------------------------+-----------------------+"," | 55 | range | bytes=0- |"," +-------+----------------------------------+-----------------------+"," | 56 | strict-transport-security | max-age=31536000 |"," +-------+----------------------------------+-----------------------+"," | 57 | strict-transport-security | max-age=31536000; |"," | | | includesubdomains |"," +-------+----------------------------------+-----------------------+"," | 58 | strict-transport-security | max-age=31536000; |"," | | | includesubdomains; |"," | | | preload |"," +-------+----------------------------------+-----------------------+"," | 59 | vary | accept-encoding |"," +-------+----------------------------------+-----------------------+"," | 60 | vary | origin |"," +-------+----------------------------------+-----------------------+"," | 61 | x-content-type-options | nosniff |"," +-------+----------------------------------+-----------------------+"," | 62 | x-xss-protection | 1; mode=block |"," +-------+----------------------------------+-----------------------+"," | 63 | :status | 100 |"," +-------+----------------------------------+-----------------------+"," | 64 | :status | 204 |"," +-------+----------------------------------+-----------------------+"," | 65 | :status | 206 |"," +-------+----------------------------------+-----------------------+"," | 66 | :status | 302 |"," +-------+----------------------------------+-----------------------+"," | 67 | :status | 400 |"," +-------+----------------------------------+-----------------------+"," | 68 | :status | 403 |"," +-------+----------------------------------+-----------------------+"," | 69 | :status | 421 |"," +-------+----------------------------------+-----------------------+"," | 70 | :status | 425 |"," +-------+----------------------------------+-----------------------+"," | 71 | :status | 500 |"," +-------+----------------------------------+-----------------------+"," | 72 | accept-language | |"," +-------+----------------------------------+-----------------------+"," | 73 | access-control-allow-credentials | FALSE |"," +-------+----------------------------------+-----------------------+"," | 74 | access-control-allow-credentials | TRUE |"," +-------+----------------------------------+-----------------------+"," | 75 | access-control-allow-headers | * |"," +-------+----------------------------------+-----------------------+"," | 76 | access-control-allow-methods | get |"," +-------+----------------------------------+-----------------------+"," | 77 | access-control-allow-methods | get, post, options |"," +-------+----------------------------------+-----------------------+"," | 78 | access-control-allow-methods | options |"," +-------+----------------------------------+-----------------------+"," | 79 | access-control-expose-headers | content-length |"," +-------+----------------------------------+-----------------------+"," | 80 | access-control-request-headers | content-type |"," +-------+----------------------------------+-----------------------+"," | 81 | access-control-request-method | get |"," +-------+----------------------------------+-----------------------+"," | 82 | access-control-request-method | post |"," +-------+----------------------------------+-----------------------+"," | 83 | alt-svc | clear |"," +-------+----------------------------------+-----------------------+"," | 84 | authorization | |"," +-------+----------------------------------+-----------------------+"," | 85 | content-security-policy | script-src 'none'; |"," | | | object-src 'none'; |"," | | | base-uri 'none' |"," +-------+----------------------------------+-----------------------+"," | 86 | early-data | 1 |"," +-------+----------------------------------+-----------------------+"," | 87 | expect-ct | |"," +-------+----------------------------------+-----------------------+"," | 88 | forwarded | |"," +-------+----------------------------------+-----------------------+"," | 89 | if-range | |"," +-------+----------------------------------+-----------------------+"," | 90 | origin | |"," +-------+----------------------------------+-----------------------+"," | 91 | purpose | prefetch |"," +-------+----------------------------------+-----------------------+"," | 92 | server | |"," +-------+----------------------------------+-----------------------+"," | 93 | timing-allow-origin | * |"," +-------+----------------------------------+-----------------------+"," | 94 | upgrade-insecure-requests | 1 |"," +-------+----------------------------------+-----------------------+"," | 95 | user-agent | |"," +-------+----------------------------------+-----------------------+"," | 96 | x-forwarded-for | |"," +-------+----------------------------------+-----------------------+"," | 97 | x-frame-options | deny |"," +-------+----------------------------------+-----------------------+"," | 98 | x-frame-options | sameorigin |"," +-------+----------------------------------+-----------------------+",""," Table 4: Static Table",""," Any line breaks that appear within field names or values are due to"," formatting."]},{"id":"appendix-B","title":"Encoding and Decoding Examples","lines":[" The following examples represent a series of exchanges between an"," encoder and a decoder. The exchanges are designed to exercise most"," QPACK instructions and highlight potentially common patterns and"," their impact on dynamic table state. The encoder sends three encoded"," field sections containing one field line each, as well as two"," speculative inserts that are not referenced.",""," The state of the encoder's dynamic table is shown, along with its"," current size. Each entry is shown with the Absolute Index of the"," entry (Abs), the current number of outstanding encoded field sections"," with references to that entry (Ref), along with the name and value."," Entries above the 'acknowledged' line have been acknowledged by the"," decoder."]},{"id":"appendix-B.1","title":"Literal Field Line with Name Reference","lines":[" The encoder sends an encoded field section containing a literal"," representation of a field with a static name reference.",""," Data | Interpretation"," | Encoder's Dynamic Table",""," Stream: 0"," 0000 | Required Insert Count = 0, Base = 0"," 510b 2f69 6e64 6578 | Literal Field Line with Name Reference"," 2e68 746d 6c | Static Table, Index=1"," | (:path=/index.html)",""," Abs Ref Name Value"," ^-- acknowledged --^"," Size=0"]},{"id":"appendix-B.2","title":"Dynamic Table","lines":[" The encoder sets the dynamic table capacity, inserts a header with a"," dynamic name reference, then sends a potentially blocking, encoded"," field section referencing this new entry. The decoder acknowledges"," processing the encoded field section, which implicitly acknowledges"," all dynamic table insertions up to the Required Insert Count.",""," Stream: Encoder"," 3fbd01 | Set Dynamic Table Capacity=220"," c00f 7777 772e 6578 | Insert With Name Reference"," 616d 706c 652e 636f | Static Table, Index=0"," 6d | (:authority=www.example.com)"," c10c 2f73 616d 706c | Insert With Name Reference"," 652f 7061 7468 | Static Table, Index=1"," | (:path=/sample/path)",""," Abs Ref Name Value"," ^-- acknowledged --^"," 0 0 :authority www.example.com"," 1 0 :path /sample/path"," Size=106",""," Stream: 4"," 0381 | Required Insert Count = 2, Base = 0"," 10 | Indexed Field Line With Post-Base Index"," | Absolute Index = Base(0) + Index(0) = 0"," | (:authority=www.example.com)"," 11 | Indexed Field Line With Post-Base Index"," | Absolute Index = Base(0) + Index(1) = 1"," | (:path=/sample/path)",""," Abs Ref Name Value"," ^-- acknowledged --^"," 0 1 :authority www.example.com"," 1 1 :path /sample/path"," Size=106",""," Stream: Decoder"," 84 | Section Acknowledgment (stream=4)",""," Abs Ref Name Value"," 0 0 :authority www.example.com"," 1 0 :path /sample/path"," ^-- acknowledged --^"," Size=106"]},{"id":"appendix-B.3","title":"Speculative Insert","lines":[" The encoder inserts a header into the dynamic table with a literal"," name. The decoder acknowledges receipt of the entry. The encoder"," does not send any encoded field sections.",""," Stream: Encoder"," 4a63 7573 746f 6d2d | Insert With Literal Name"," 6b65 790c 6375 7374 | (custom-key=custom-value)"," 6f6d 2d76 616c 7565 |",""," Abs Ref Name Value"," 0 0 :authority www.example.com"," 1 0 :path /sample/path"," ^-- acknowledged --^"," 2 0 custom-key custom-value"," Size=160",""," Stream: Decoder"," 01 | Insert Count Increment (1)",""," Abs Ref Name Value"," 0 0 :authority www.example.com"," 1 0 :path /sample/path"," 2 0 custom-key custom-value"," ^-- acknowledged --^"," Size=160"]},{"id":"appendix-B.4","title":"Duplicate Instruction, Stream Cancellation","lines":[" The encoder duplicates an existing entry in the dynamic table, then"," sends an encoded field section referencing the dynamic table entries"," including the duplicated entry. The packet containing the encoder"," stream data is delayed. Before the packet arrives, the decoder"," cancels the stream and notifies the encoder that the encoded field"," section was not processed.",""," Stream: Encoder"," 02 | Duplicate (Relative Index = 2)"," | Absolute Index ="," | Insert Count(3) - Index(2) - 1 = 0",""," Abs Ref Name Value"," 0 0 :authority www.example.com"," 1 0 :path /sample/path"," 2 0 custom-key custom-value"," ^-- acknowledged --^"," 3 0 :authority www.example.com"," Size=217",""," Stream: 8"," 0500 | Required Insert Count = 4, Base = 4"," 80 | Indexed Field Line, Dynamic Table"," | Absolute Index = Base(4) - Index(0) - 1 = 3"," | (:authority=www.example.com)"," c1 | Indexed Field Line, Static Table Index = 1"," | (:path=/)"," 81 | Indexed Field Line, Dynamic Table"," | Absolute Index = Base(4) - Index(1) - 1 = 2"," | (custom-key=custom-value)",""," Abs Ref Name Value"," 0 0 :authority www.example.com"," 1 0 :path /sample/path"," 2 1 custom-key custom-value"," ^-- acknowledged --^"," 3 1 :authority www.example.com"," Size=217",""," Stream: Decoder"," 48 | Stream Cancellation (Stream=8)",""," Abs Ref Name Value"," 0 0 :authority www.example.com"," 1 0 :path /sample/path"," 2 0 custom-key custom-value"," ^-- acknowledged --^"," 3 0 :authority www.example.com"," Size=217"]},{"id":"appendix-B.5","title":"Dynamic Table Insert, Eviction","lines":[" The encoder inserts another header into the dynamic table, which"," evicts the oldest entry. The encoder does not send any encoded field"," sections.",""," Stream: Encoder"," 810d 6375 7374 6f6d | Insert With Name Reference"," 2d76 616c 7565 32 | Dynamic Table, Relative Index = 1"," | Absolute Index ="," | Insert Count(4) - Index(1) - 1 = 2"," | (custom-key=custom-value2)",""," Abs Ref Name Value"," 1 0 :path /sample/path"," 2 0 custom-key custom-value"," ^-- acknowledged --^"," 3 0 :authority www.example.com"," 4 0 custom-key custom-value2"," Size=215"]},{"id":"appendix-C","title":"Sample Single-Pass Encoding Algorithm","lines":[" Pseudocode for single-pass encoding, excluding handling of"," duplicates, non-blocking mode, available encoder stream flow control"," and reference tracking.",""," # Helper functions:"," # ===="," # Encode an integer with the specified prefix and length"," encodeInteger(buffer, prefix, value, prefixLength)",""," # Encode a dynamic table insert instruction with optional static"," # or dynamic name index (but not both)"," encodeInsert(buffer, staticNameIndex, dynamicNameIndex, fieldLine)",""," # Encode a static index reference"," encodeStaticIndexReference(buffer, staticIndex)",""," # Encode a dynamic index reference relative to Base"," encodeDynamicIndexReference(buffer, dynamicIndex, base)",""," # Encode a literal with an optional static name index"," encodeLiteral(buffer, staticNameIndex, fieldLine)",""," # Encode a literal with a dynamic name index relative to Base"," encodeDynamicLiteral(buffer, dynamicNameIndex, base, fieldLine)",""," # Encoding Algorithm"," # ===="," base = dynamicTable.getInsertCount()"," requiredInsertCount = 0"," for line in fieldLines:"," staticIndex = staticTable.findIndex(line)"," if staticIndex is not None:"," encodeStaticIndexReference(streamBuffer, staticIndex)"," continue",""," dynamicIndex = dynamicTable.findIndex(line)"," if dynamicIndex is None:"," # No matching entry. Either insert+index or encode literal"," staticNameIndex = staticTable.findName(line.name)"," if staticNameIndex is None:"," dynamicNameIndex = dynamicTable.findName(line.name)",""," if shouldIndex(line) and dynamicTable.canIndex(line):"," encodeInsert(encoderBuffer, staticNameIndex,"," dynamicNameIndex, line)"," dynamicIndex = dynamicTable.add(line)",""," if dynamicIndex is None:"," # Could not index it, literal"," if dynamicNameIndex is not None:"," # Encode literal with dynamic name, possibly above Base"," encodeDynamicLiteral(streamBuffer, dynamicNameIndex,"," base, line)"," requiredInsertCount = max(requiredInsertCount,"," dynamicNameIndex)"," else:"," # Encodes a literal with a static name or literal name"," encodeLiteral(streamBuffer, staticNameIndex, line)"," else:"," # Dynamic index reference"," assert(dynamicIndex is not None)"," requiredInsertCount = max(requiredInsertCount, dynamicIndex)"," # Encode dynamicIndex, possibly above Base"," encodeDynamicIndexReference(streamBuffer, dynamicIndex, base)",""," # encode the prefix"," if requiredInsertCount == 0:"," encodeInteger(prefixBuffer, 0x00, 0, 8)"," encodeInteger(prefixBuffer, 0x00, 0, 7)"," else:"," wireRIC = ("," requiredInsertCount"," % (2 * getMaxEntries(maxTableCapacity))"," ) + 1;"," encodeInteger(prefixBuffer, 0x00, wireRIC, 8)"," if base >= requiredInsertCount:"," encodeInteger(prefixBuffer, 0x00,"," base - requiredInsertCount, 7)"," else:"," encodeInteger(prefixBuffer, 0x80,"," requiredInsertCount - base - 1, 7)",""," return encoderBuffer, prefixBuffer + streamBuffer"]},{"id":"name-acknowledgments","title":"Acknowledgments","lines":[" The IETF QUIC Working Group received an enormous amount of support"," from many people.",""," The compression design team did substantial work exploring the"," problem space and influencing the initial draft version of this"," document. The contributions of design team members Roberto Peon,"," Martin Thomson, and Dmitri Tikhonov are gratefully acknowledged.",""," The following people also provided substantial contributions to this"," document:",""," * Bence Beky"," * Alessandro Ghedini"," * Ryan Hamilton"," * Robin Marx"," * Patrick McManus"," * 奥 一穂 (Kazuho Oku)"," * Lucas Pardue"," * Biren Roy"," * Ian Swett",""," This document draws heavily on the text of [RFC7541]. The indirect"," input of those authors is also gratefully acknowledged.",""," Buck Krasic's contribution was supported by Google during his"," employment there.",""," A portion of Mike Bishop's contribution was supported by Microsoft"," during his employment there."]},{"id":"name-authors-addresses","title":"Authors' Addresses","lines":[" Charles 'Buck' Krasic"," Email: krasic@acm.org",""," Mike Bishop"," Akamai Technologies"," Email: mbishop@evequefou.be",""," Alan Frindell (editor)"," Facebook"," Email: afrind@fb.com"]}]},"https://www.rfc-editor.org/rfc/rfc9221":{"format":"ietf","requirements":[1050,1051,1052,1053,1054,1055,1056,1057,1058,1059,1060,1061,1062,1063,1064,1065,1066,1067,1068,1069],"sections":[{"id":"name-abstract","title":"Abstract","lines":[" This document defines an extension to the QUIC transport protocol to"," add support for sending and receiving unreliable datagrams over a"," QUIC connection."]},{"id":"name-status-of-this-memo","title":"Status of This Memo","lines":[" This is an Internet Standards Track document.",""," This document is a product of the Internet Engineering Task Force"," (IETF). It represents the consensus of the IETF community. It has"," received public review and has been approved for publication by the"," Internet Engineering Steering Group (IESG). Further information on"," Internet Standards is available in Section 2 of RFC 7841.",""," Information about the current status of this document, any errata,"," and how to provide feedback on it may be obtained at"," https://www.rfc-editor.org/info/rfc9221."]},{"id":"name-copyright-notice","title":"Copyright Notice","lines":[" Copyright (c) 2022 IETF Trust and the persons identified as the"," document authors. All rights reserved.",""," This document is subject to BCP 78 and the IETF Trust's Legal"," Provisions Relating to IETF Documents"," (https://trustee.ietf.org/license-info) in effect on the date of"," publication of this document. Please review these documents"," carefully, as they describe your rights and restrictions with respect"," to this document. Code Components extracted from this document must"," include Revised BSD License text as described in Section 4.e of the"," Trust Legal Provisions and are provided without warranty as described"," in the Revised BSD License."]},{"id":"name-table-of-contents","title":"Table of Contents","lines":[" 1. Introduction"," 1.1. Specification of Requirements"," 2. Motivation"," 3. Transport Parameter"," 4. Datagram Frame Types"," 5. Behavior and Usage"," 5.1. Multiplexing Datagrams"," 5.2. Acknowledgement Handling"," 5.3. Flow Control"," 5.4. Congestion Control"," 6. Security Considerations"," 7. IANA Considerations"," 7.1. QUIC Transport Parameter"," 7.2. QUIC Frame Types"," 8. References"," 8.1. Normative References"," 8.2. Informative References"," Acknowledgments"," Authors' Addresses"]},{"id":"section-1","title":"Introduction","lines":[" The QUIC transport protocol [RFC9000] provides a secure, multiplexed"," connection for transmitting reliable streams of application data."," QUIC uses various frame types to transmit data within packets, and"," each frame type defines whether the data it contains will be"," retransmitted. Streams of reliable application data are sent using"," STREAM frames.",""," Some applications, particularly those that need to transmit real-time"," data, prefer to transmit data unreliably. In the past, these"," applications have built directly upon UDP [RFC0768] as a transport"," and have often added security with DTLS [RFC6347]. Extending QUIC to"," support transmitting unreliable application data provides another"," option for secure datagrams with the added benefit of sharing the"," cryptographic and authentication context used for reliable streams.",""," This document defines two new DATAGRAM QUIC frame types that carry"," application data without requiring retransmissions."]},{"id":"section-1.1","title":"Specification of Requirements","lines":[" 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 [RFC2119] [RFC8174] when, and only when, they appear in all"," capitals, as shown here."]},{"id":"section-2","title":"Motivation","lines":[" Transmitting unreliable data over QUIC provides benefits over"," existing solutions:",""," * Applications that want to use both a reliable stream and an"," unreliable flow to the same peer can benefit by sharing a single"," handshake and authentication context between a reliable QUIC"," stream and a flow of unreliable QUIC datagrams. This can reduce"," the latency required for handshakes compared to opening both a TLS"," connection and a DTLS connection.",""," * QUIC uses a more nuanced loss recovery mechanism than the DTLS"," handshake. This can allow loss recovery to occur more quickly for"," QUIC data.",""," * QUIC datagrams are subject to QUIC congestion control. Providing"," a single congestion control for both reliable and unreliable data"," can be more effective and efficient.",""," These features can be useful for optimizing audio/video streaming"," applications, gaming applications, and other real-time network"," applications.",""," Unreliable QUIC datagrams can also be used to implement an IP packet"," tunnel over QUIC, such as for a Virtual Private Network (VPN)."," Internet-layer tunneling protocols generally require a reliable and"," authenticated handshake followed by unreliable secure transmission of"," IP packets. This can, for example, require a TLS connection for the"," control data and DTLS for tunneling IP packets. A single QUIC"," connection could support both parts with the use of unreliable"," datagrams in addition to reliable streams."]},{"id":"section-3","title":"Transport Parameter","lines":[" Support for receiving the DATAGRAM frame types is advertised by means"," of a QUIC transport parameter (name=max_datagram_frame_size,",[[[],0," value=0x20). "],[[2486,3027],20,"The max_datagram_frame_size transport parameter is an"]],[[[],0," "],[[2486,3027],20,"integer value (represented as a variable-length integer) that"]],[[[],0," "],[[2486,3027],20,"represents the maximum size of a DATAGRAM frame (including the frame"]],[[[],0," "],[[2486,3027],20,"type, length, and payload) the endpoint is willing to receive, in"]],[[[],0," "],[[2486,3027],20,"bytes."]],""," The default for this parameter is 0, which indicates that the"," endpoint does not support DATAGRAM frames. A value greater than 0"," indicates that the endpoint supports the DATAGRAM frame types and is"," willing to receive such frames on this connection.","",[[[],0," "],[[1050,1719],240,"An endpoint MUST NOT send DATAGRAM frames until it has received the"]],[[[],0," "],[[1050,1719],240,"max_datagram_frame_size transport parameter with a non-zero value"]],[[[],0," "],[[1050,1719],240,"during the handshake (or during a previous handshake if 0-RTT is"]],[[[],0," "],[[1050,1719],240,"used)."],[[],0," "],[[1051,1720],240,"An endpoint MUST NOT send DATAGRAM frames that are larger"]],[[[],0," "],[[1051,1720],240,"than the max_datagram_frame_size value it has received from its peer."]],[[[],0," "],[[1052,1813,1823],240,"An endpoint that receives a DATAGRAM frame when it has not indicated"]],[[[],0," "],[[1052,1813,1823],240,"support via the transport parameter MUST terminate the connection"]],[[[],0," "],[[1052,1813,1823],240,"with an error of type PROTOCOL_VIOLATION."],[[],0," "],[[1053,1814,1824],240,"Similarly, an endpoint"]],[[[],0," "],[[1053,1814,1824],240,"that receives a DATAGRAM frame that is larger than the value it sent"]],[[[],0," "],[[1053,1814,1824],240,"in its max_datagram_frame_size transport parameter MUST terminate the"]],[[[],0," "],[[1053,1814,1824],240,"connection with an error of type PROTOCOL_VIOLATION."]],"",[[[],0," "],[[1054,2357],176,"For most uses of DATAGRAM frames, it is RECOMMENDED to send a value"]],[[[],0," "],[[1054,2357],176,"of 65535 in the max_datagram_frame_size transport parameter to"]],[[[],0," "],[[1054,2357],176,"indicate that this endpoint will accept any DATAGRAM frame that fits"]],[[[],0," "],[[1054,2357],176,"inside a QUIC packet."]],""," The max_datagram_frame_size transport parameter is a unidirectional",[[[],0," limit and indication of support of DATAGRAM frames. "],[[1055,2826],100,"Application"]],[[[],0," "],[[1055,2826],100,"protocols that use DATAGRAM frames MAY choose to only negotiate and"]],[[[],0," "],[[1055,2826],100,"use them in a single direction."]],"",[[[],0," "],[[1056,2198],112,"When clients use 0-RTT, they MAY store the value of the server's"]],[[[],0," "],[[1056,2198],112,"max_datagram_frame_size transport parameter."],[[],0," Doing so allows the"]],[[[],0," client to send DATAGRAM frames in 0-RTT packets. "],[[1057,1399],225,"When servers decide"]],[[[],0," "],[[1057,1399],225,"to accept 0-RTT data, they MUST send a max_datagram_frame_size"]],[[[],0," "],[[1057,1399],225,"transport parameter greater than or equal to the value they sent to"]],[[[],0," "],[[1057,1399],225,"the client in the connection where they sent them the"]],[[[],0," "],[[1057,1399],225,"NewSessionTicket message."],[[],0," "],[[1058,1919,2874],244,"If a client stores the value of the"]],[[[],0," "],[[1058,1919,2874],244,"max_datagram_frame_size transport parameter with their 0-RTT state,"]],[[[],0," "],[[1058,1919,2874],244,"they MUST validate that the new value of the max_datagram_frame_size"]],[[[],0," "],[[1058,1919,2874],244,"transport parameter sent by the server in the handshake is greater"]],[[[],0," "],[[1058,1919,2874],244,"than or equal to the stored value; if not, the client MUST terminate"]],[[[],0," "],[[1058,1919,2874],244,"the connection with error PROTOCOL_VIOLATION."]],"",[[[],0," "],[[1059,1395],225,"Application protocols that use datagrams MUST define how they react"]],[[[],0," "],[[1059,1395],225,"to the absence of the max_datagram_frame_size transport parameter."]]," If datagram support is integral to the application, the application"," protocol can fail the handshake if the max_datagram_frame_size"," transport parameter is not present."],"requirements":[1050,1051,1052,1053,1054,1055,1056,1057,1058,1059]},{"id":"section-4","title":"Datagram Frame Types","lines":[" DATAGRAM frames are used to transmit application data in an"," unreliable manner. The Type field in the DATAGRAM frame takes the"," form 0b0011000X (or the values 0x30 and 0x31). The least significant"," bit of the Type field in the DATAGRAM frame is the LEN bit (0x01),"," which indicates whether there is a Length field present: if this bit"," is set to 0, the Length field is absent and the Datagram Data field"," extends to the end of the packet; if this bit is set to 1, the Length"," field is present.",""," DATAGRAM frames are structured as follows:",""," DATAGRAM Frame {"," Type (i) = 0x30..0x31,"," [Length (i)],"," Datagram Data (..),"," }",""," Figure 1: DATAGRAM Frame Format",""," DATAGRAM frames contain the following fields:",""," Length: A variable-length integer specifying the length of the"," Datagram Data field in bytes. This field is present only when the"," LEN bit is set to 1. When the LEN bit is set to 0, the Datagram"," Data field extends to the end of the QUIC packet. Note that empty"," (i.e., zero-length) datagrams are allowed.",""," Datagram Data: The bytes of the datagram to be delivered."]},{"id":"section-5","title":"Behavior and Usage","lines":[" When an application sends a datagram over a QUIC connection, QUIC"," will generate a new DATAGRAM frame and send it in the first available",[[[],0," packet. "],[[1066,2816],164,"This frame SHOULD be sent as soon as possible (as determined"]],[[[],0," "],[[1066,2816],164,"by factors like congestion control, described below) and MAY be"]],[[[],0," "],[[1066,2816],164,"coalesced with other frames."]],"",[[[],0," "],[[1067,1815,1825],176,"When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD"]],[[[],0," "],[[1067,1815,1825],176,"deliver the data to the application immediately, as long as it is"]],[[[],0," "],[[1067,1815,1825],176,"able to process the frame and can store the contents in memory."]],"",[[[],0," "],[[1068,1812],240,"Like STREAM frames, DATAGRAM frames contain application data and MUST"]],[[[],0," "],[[1068,1812],240,"be protected with either 0-RTT or 1-RTT keys."]],""," Note that while the max_datagram_frame_size transport parameter"," places a limit on the maximum size of DATAGRAM frames, that limit can"," be further reduced by the max_udp_payload_size transport parameter"," and the Maximum Transmission Unit (MTU) of the path between"," endpoints. DATAGRAM frames cannot be fragmented; therefore,"," application protocols need to handle cases where the maximum datagram"," size is limited by other factors."],"requirements":[1066,1067,1068]},{"id":"section-5.1","title":"Multiplexing Datagrams","lines":[" DATAGRAM frames belong to a QUIC connection as a whole and are not"," associated with any stream ID at the QUIC layer. However, it is"," expected that applications will want to differentiate between"," specific DATAGRAM frames by using identifiers, such as for logical"," flows of datagrams or to distinguish between different kinds of"," datagrams.",""," Defining the identifiers used to multiplex different kinds of"," datagrams or flows of datagrams is the responsibility of the"," application protocol running over QUIC. The application defines the"," semantics of the Datagram Data field and how it is parsed.",""," If the application needs to support the coexistence of multiple flows"," of datagrams, one recommended pattern is to use a variable-length"," integer at the beginning of the Datagram Data field. This is a"," simple approach that allows a large number of flows to be encoded"," using minimal space.","",[[[],0," "],[[1060,2158,2362,2363,2817],180,"QUIC implementations SHOULD present an API to applications to assign"]],[[[],0," "],[[1060,2158,2362,2363,2817],180,"relative priorities to DATAGRAM frames with respect to each other and"]],[[[],0," "],[[1060,2158,2362,2363,2817],180,"to QUIC streams."]]],"requirements":[1060]},{"id":"section-5.2","title":"Acknowledgement Handling","lines":[" Although DATAGRAM frames are not retransmitted upon loss detection,",[[[],0," they are ack-eliciting ([RFC9002]). "],[[1061,1873],176,"Receivers SHOULD support"]],[[[],0," "],[[1061,1873],176,"delaying ACK frames (within the limits specified by max_ack_delay) in"]],[[[],0," "],[[1061,1873],176,"response to receiving packets that only contain DATAGRAM frames,"]],[[[],0," "],[[1061,1873],176,"since the sender takes no action if these packets are temporarily"]],[[[],0," "],[[1061,1873],176,"unacknowledged."],[[],0," Receivers will continue to send ACK frames when"]]," conditions indicate a packet might be lost, since the packet's"," payload is unknown to the receiver, and when dictated by"," max_ack_delay or other protocol components.",""," As with any ack-eliciting frame, when a sender suspects that a packet"," containing only DATAGRAM frames has been lost, it sends probe packets"," to elicit a faster acknowledgement as described in Section 6.2.4 of"," [RFC9002].","",[[[],0," "],[[1062,1396],97,"If a sender detects that a packet containing a specific DATAGRAM"]],[[[],0," "],[[1062,1396],97,"frame might have been lost, the implementation MAY notify the"]],[[[],0," "],[[1062,1396],97,"application that it believes the datagram was lost."]],"",[[[],0," "],[[1063,1397],97,"Similarly, if a packet containing a DATAGRAM frame is acknowledged,"]],[[[],0," "],[[1063,1397],97,"the implementation MAY notify the sender application that the"]],[[[],0," "],[[1063,1397],97,"datagram was successfully transmitted and received."],[[],0," Due to"]]," reordering, this can include a DATAGRAM frame that was thought to be"," lost but, at a later point, was received and acknowledged. It is"," important to note that acknowledgement of a DATAGRAM frame only"," indicates that the transport-layer handling on the receiver processed"," the frame and does not guarantee that the application on the receiver"," successfully processed the data. Thus, this signal cannot replace"," application-layer signals that indicate successful processing."],"requirements":[1061,1062,1063]},{"id":"section-5.3","title":"Flow Control","lines":[" DATAGRAM frames do not provide any explicit flow control signaling"," and do not contribute to any per-flow or connection-wide data limit.",""," The risk associated with not providing flow control for DATAGRAM"," frames is that a receiver might not be able to commit the necessary"," resources to process the frames. For example, it might not be able",[[[],0," to store the frame contents in memory. "],[[1064,1398],97,"However, since DATAGRAM"]],[[[],0," "],[[1064,1398],97,"frames are inherently unreliable, they MAY be dropped by the receiver"]],[[[],0," "],[[1064,1398],97,"if the receiver cannot process them."]]],"requirements":[1064]},{"id":"section-5.4","title":"Congestion Control","lines":[" DATAGRAM frames employ the QUIC connection's congestion controller."," As a result, a connection might be unable to send a DATAGRAM frame"," generated by the application until the congestion controller allows",[[[],0," it [RFC9002]. "],[[1065,2165],240,"The sender MUST either delay sending the frame until"]],[[[],0," "],[[1065,2165],240,"the controller allows it or drop the frame without sending it (at"]],[[[],0," "],[[1065,2165],240,"which point it MAY notify the application)."],[[],0," Implementations that use"]]," packet pacing (Section 7.7 of [RFC9002]) can also delay the sending"," of DATAGRAM frames to maintain consistent packet pacing.",""," Implementations can optionally support allowing the application to"," specify a sending expiration time beyond which a congestion-"," controlled DATAGRAM frame ought to be dropped without transmission."],"requirements":[1065]},{"id":"section-6","title":"Security Considerations","lines":[" The DATAGRAM frame shares the same security properties as the rest of"," the data transmitted within a QUIC connection, and the security",[[[],0," considerations of [RFC9000] apply accordingly. "],[[1069,1822],240,"All application data"]],[[[],0," "],[[1069,1822],240,"transmitted with the DATAGRAM frame, like the STREAM frame, MUST be"]],[[[],0," "],[[1069,1822],240,"protected either by 0-RTT or 1-RTT keys."]],""," Application protocols that allow DATAGRAM frames to be sent in 0-RTT"," require a profile that defines acceptable use of 0-RTT; see"," Section 5.6 of [RFC9001].",""," The use of DATAGRAM frames might be detectable by an adversary on"," path that is capable of dropping packets. Since DATAGRAM frames do"," not use transport-level retransmission, connections that use DATAGRAM"," frames might be distinguished from other connections due to their"," different response to packet loss."],"requirements":[1069]},{"id":"section-7","title":"IANA Considerations","lines":[]},{"id":"section-7.1","title":"QUIC Transport Parameter","lines":[" This document registers a new value in the \"QUIC Transport"," Parameters\" registry maintained at .",""," Value: 0x20"," Parameter Name: max_datagram_frame_size"," Status: permanent"," Specification: RFC 9221"]},{"id":"section-7.2","title":"QUIC Frame Types","lines":[" This document registers two new values in the \"QUIC Frame Types\""," registry maintained at .",""," Value: 0x30-0x31"," Frame Name: DATAGRAM"," Status: permanent"," Specification: RFC 9221"]},{"id":"section-8","title":"References","lines":[]},{"id":"section-8.1","title":"Normative References","lines":[" [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate"," Requirement Levels\", BCP 14, RFC 2119,"," DOI 10.17487/RFC2119, March 1997,"," .",""," [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC"," 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,"," May 2017, .",""," [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., \"QUIC: A UDP-Based"," Multiplexed and Secure Transport\", RFC 9000,"," DOI 10.17487/RFC9000, May 2021,"," .",""," [RFC9001] Thomson, M., Ed. and S. Turner, Ed., \"Using TLS to Secure"," QUIC\", RFC 9001, DOI 10.17487/RFC9001, May 2021,"," .",""," [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., \"QUIC Loss Detection"," and Congestion Control\", RFC 9002, DOI 10.17487/RFC9002,"," May 2021, ."]},{"id":"section-8.2","title":"Informative References","lines":[" [RFC0768] Postel, J., \"User Datagram Protocol\", STD 6, RFC 768,"," DOI 10.17487/RFC0768, August 1980,"," .",""," [RFC6347] Rescorla, E. and N. Modadugu, \"Datagram Transport Layer"," Security Version 1.2\", RFC 6347, DOI 10.17487/RFC6347,"," January 2012, ."]},{"id":"name-acknowledgments","title":"Acknowledgments","lines":[" The original proposal for this work came from Ian Swett.",""," This document had reviews and input from many contributors in the"," IETF QUIC Working Group, with substantive input from Nick Banks,"," Lucas Pardue, Rui Paulo, Martin Thomson, Victor Vasiliev, and Chris"," Wood."]},{"id":"name-authors-addresses","title":"Authors' Addresses","lines":[" Tommy Pauly"," Apple Inc."," One Apple Park Way"," Cupertino, CA 95014"," United States of America"," Email: tpauly@apple.com",""," Eric Kinnear"," Apple Inc."," One Apple Park Way"," Cupertino, CA 95014"," United States of America"," Email: ekinnear@apple.com",""," David Schinazi"," Google LLC"," 1600 Amphitheatre Parkway"," Mountain View, CA 94043"," United States of America"," Email: dschinazi.ietf@gmail.com"]}]},"https://www.rfc-editor.org/rfc/rfc9287":{"format":"ietf","requirements":[1070,1071,1072,1073,1074,1075,1076,1077,1078],"sections":[{"id":"name-abstract","title":"Abstract","lines":[" This document describes a method for negotiating the ability to send"," an arbitrary value for the second-most significant bit in QUIC"," packets."]},{"id":"name-status-of-this-memo","title":"Status of This Memo","lines":[" This is an Internet Standards Track document.",""," This document is a product of the Internet Engineering Task Force"," (IETF). It represents the consensus of the IETF community. It has"," received public review and has been approved for publication by the"," Internet Engineering Steering Group (IESG). Further information on"," Internet Standards is available in Section 2 of RFC 7841.",""," Information about the current status of this document, any errata,"," and how to provide feedback on it may be obtained at"," https://www.rfc-editor.org/info/rfc9287."]},{"id":"name-copyright-notice","title":"Copyright Notice","lines":[" Copyright (c) 2022 IETF Trust and the persons identified as the"," document authors. All rights reserved.",""," This document is subject to BCP 78 and the IETF Trust's Legal"," Provisions Relating to IETF Documents"," (https://trustee.ietf.org/license-info) in effect on the date of"," publication of this document. Please review these documents"," carefully, as they describe your rights and restrictions with respect"," to this document. Code Components extracted from this document must"," include Revised BSD License text as described in Section 4.e of the"," Trust Legal Provisions and are provided without warranty as described"," in the Revised BSD License."]},{"id":"name-table-of-contents","title":"Table of Contents","lines":[" 1. Introduction"," 2. Conventions and Definitions"," 3. The Grease QUIC Bit Transport Parameter"," 3.1. Clearing the QUIC Bit"," 3.2. Using the QUIC Bit"," 4. Security Considerations"," 5. IANA Considerations"," 6. References"," 6.1. Normative References"," 6.2. Informative References"," Author's Address"]},{"id":"section-1","title":"Introduction","lines":[" The version-independent definition of QUIC [QUIC-INVARIANTS]"," intentionally describes a very narrow set of fields that are visible"," to entities other than endpoints. Beyond those characteristics that"," are invariant, very little about the \"wire image\" [RFC8546] of QUIC"," is visible.",""," The second-most significant bit of the first byte in every QUIC"," packet is defined as having a fixed value in QUIC version 1 [QUIC]."," The purpose of having a fixed value is to allow endpoints to"," efficiently distinguish QUIC from other protocols; see [DEMUX] for a"," description of a system that might use this property. As this bit"," can identify a packet as QUIC, it is sometimes referred to as the"," \"QUIC Bit\".",""," Where endpoints and the intermediaries that support them do not"," depend on the QUIC Bit having a fixed value, sending the same value"," in every packet is more of a liability than an asset. If systems"," come to depend on a fixed value, then it might become infeasible to"," define a version of QUIC that attributes semantics to this bit.",""," In order to safeguard future use of this bit, this document defines a"," QUIC transport parameter that indicates that an endpoint is willing"," to receive QUIC packets containing any value for this bit. By"," sending different values for this bit, the hope is that the value"," will remain available for future use [USE-IT]."]},{"id":"section-2","title":"Conventions and Definitions","lines":[" 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 [RFC2119] [RFC8174] when, and only when, they appear in all"," capitals, as shown here.",""," This document uses terms and notational conventions from [QUIC]."]},{"id":"section-3","title":"The Grease QUIC Bit Transport Parameter","lines":[" The grease_quic_bit transport parameter (0x2ab2) is defined for QUIC"," version 1 [QUIC]. This transport parameter can be sent by both",[[[],0," client and server. "],[[1077,2487],240,"The transport parameter is sent with an empty"]],[[[],0," "],[[1077,2487],240,"value; an endpoint that understands this transport parameter MUST"]],[[[],0," "],[[1077,2487],240,"treat receipt of a non-empty value of the transport parameter as a"]],[[[],0," "],[[1077,2487],240,"connection error of type TRANSPORT_PARAMETER_ERROR."]],"",[[[],0," "],[[1078,1741,2222,2224,3010,3012],244,"An endpoint that advertises the grease_quic_bit transport parameter"]],[[[],0," "],[[1078,1741,2222,2224,3010,3012],244,"MUST accept packets with the QUIC Bit set to a value of 0."],[[],0," The QUIC"]]," Bit is defined as the second-most significant bit of the first byte"," of QUIC packets (that is, the value 0x40)."],"requirements":[1077,1078]},{"id":"section-3.1","title":"Clearing the QUIC Bit","lines":[[[[],0," "],[[1070,1677],176,"Endpoints that receive the grease_quic_bit transport parameter from a"]],[[[],0," "],[[1070,1677],176,"peer SHOULD set the QUIC Bit to an unpredictable value unless another"]],[[[],0," "],[[1070,1677],176,"extension assigns specific meaning to the value of the bit."]],""," Endpoints can set the QUIC Bit to 0 on all packets that are sent"," after receiving and processing transport parameters. This could"," include Initial, Handshake, and Retry packets.","",[[[],0," "],[[1071,1400],97,"A client MAY also set the QUIC Bit to 0 in Initial, Handshake, or"]],[[[],0," "],[[1071,1400],97,"0-RTT packets that are sent prior to receiving transport parameters"]],[[[],0," "],[[1071,1400],97,"from the server."],[[],0," "],[[1072,1885],240,"However, a client MUST NOT set the QUIC Bit to 0"]],[[[],0," "],[[1072,1885],240,"unless the Initial packets it sends include a token provided by the"]],[[[],0," "],[[1072,1885],240,"server in a NEW_TOKEN frame (Section 19.7 of [QUIC]), received less"]],[[[],0," "],[[1072,1885],240,"than 604800 seconds (7 days) prior on a connection where the server"]],[[[],0," "],[[1072,1885],240,"also included the grease_quic_bit transport parameter."]],""," | This 7-day limit allows for changes in server configuration."," | If server configuration changes and a client does not set the"," | QUIC Bit, then it is possible that a server will drop packets,"," | resulting in connection failures.","",[[[],0," "],[[1073,1886],240,"A server MUST set the QUIC Bit to 0 only after processing transport"]],[[[],0," "],[[1073,1886],240,"parameters from a client."],[[],0," "],[[1074,1887],240,"A server MUST NOT remember that a client"]],[[[],0," "],[[1074,1887],240,"negotiated the extension in a previous connection and set the QUIC"]],[[[],0," "],[[1074,1887],240,"Bit to 0 based on that information."]],"",[[[],0," "],[[1075,1888],240,"An endpoint MUST NOT set the QUIC Bit to 0 without knowing whether"]],[[[],0," "],[[1075,1888],240,"the peer supports the extension."],[[],0," As Stateless Reset packets"]]," (Section 10.3 of [QUIC]) are only used after a loss of connection"," state, endpoints are unlikely to be able to set the QUIC Bit to 0 on"," Stateless Reset packets."],"requirements":[1070,1071,1072,1073,1074,1075]},{"id":"section-3.2","title":"Using the QUIC Bit","lines":[" The purpose of this extension is to allow for the use of the QUIC Bit"," by later extensions.",""," Extensions to QUIC that define semantics for the QUIC Bit can be"," negotiated at the same time as the grease_quic_bit transport"," parameter. In this case, a recipient needs to be able to distinguish"," a randomized value from a value carrying information according to the",[[[],0," extension. "],[[1076,1401],225,"Extensions that use the QUIC Bit MUST negotiate their use"]],[[[],0," "],[[1076,1401],225,"prior to acting on any semantic."]],""," For example, an extension might define a transport parameter that is"," sent in addition to the grease_quic_bit transport parameter. Though"," the value of the QUIC Bit in packets received by a peer might be set"," according to rules defined by the extension, they might also be"," randomized as specified in this document.",""," The receipt of a transport parameter for an extension that uses the"," QUIC Bit could be used to confirm that a peer supports the semantic"," defined in the extension. To avoid acting on a randomized signal,"," the extension can require that endpoints set the QUIC Bit according"," to the rules of the extension but defer acting on the information"," conveyed until the transport parameter for the extension is received.",""," Extensions that define semantics for the QUIC Bit can be negotiated"," without using the grease_quic_bit transport parameter. However,"," including both extensions allows for the QUIC Bit to be greased even"," if the alternative use is not supported."],"requirements":[1076]},{"id":"section-4","title":"Security Considerations","lines":[" This document introduces no new security considerations for endpoints"," or entities that can rely on endpoint cooperation. However, this"," change makes the task of identifying QUIC more difficult without"," cooperation of endpoints. This sometimes works counter to the"," security goals of network operators who rely on network"," classification to identify threats; see Section 3.1 of"," [MANAGEABILITY] for a more comprehensive treatment of this topic."]},{"id":"section-5","title":"IANA Considerations","lines":[" This document registers the grease_quic_bit transport parameter in"," the \"QUIC Transport Parameters\" registry established in Section 22.3"," of [QUIC]. The following fields are registered:",""," Value: 0x2ab2",""," Parameter Name: grease_quic_bit",""," Status: Permanent",""," Specification: RFC 9287",""," Date: 2022-07-13",""," Change Controller: IETF (iesg@ietf.org)",""," Contact: QUIC Working Group (quic@ietf.org)",""," Notes: (none)"]},{"id":"section-6","title":"References","lines":[]},{"id":"section-6.1","title":"Normative References","lines":[" [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., \"QUIC: A UDP-Based"," Multiplexed and Secure Transport\", RFC 9000,"," DOI 10.17487/RFC9000, May 2021,"," .",""," [QUIC-INVARIANTS]"," Thomson, M., \"Version-Independent Properties of QUIC\","," RFC 8999, DOI 10.17487/RFC8999, May 2021,"," .",""," [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate"," Requirement Levels\", BCP 14, RFC 2119,"," DOI 10.17487/RFC2119, March 1997,"," .",""," [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC"," 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,"," May 2017, ."]},{"id":"section-6.2","title":"Informative References","lines":[" [DEMUX] Aboba, B., Salgueiro, G., and C. Perkins, \"Multiplexing"," Scheme Updates for QUIC\", Work in Progress, Internet-"," Draft, draft-ietf-avtcore-rfc7983bis-06, 5 August 2022,"," .",""," [MANAGEABILITY]"," Kuehlewind, M. and B. Trammell, \"Manageability of the QUIC"," Transport Protocol\", Work in Progress, Internet-Draft,"," draft-ietf-quic-manageability-18, 15 July 2022,"," .",""," [RFC8546] Trammell, B. and M. Kuehlewind, \"The Wire Image of a"," Network Protocol\", RFC 8546, DOI 10.17487/RFC8546, April"," 2019, .",""," [USE-IT] Thomson, M. and T. Pauly, \"Long-Term Viability of Protocol"," Extension Mechanisms\", RFC 9170, DOI 10.17487/RFC9170,"," December 2021, ."]},{"id":"name-author-s-address","title":"Author's Address","lines":[" Martin Thomson"," Mozilla"," Email: mt@lowentropy.net"]}]},"https://www.rfc-editor.org/rfc/rfc9368":{"format":"ietf","requirements":[1079,1080,1081,1082,1083,1084,1085,1086,1087,1088,1089,1090,1091,1092,1093,1094,1095,1096,1097,1098,1099,1100,1101,1102,1103,1104,1105,1106,1107,1108,1109,1110,1111,1112,1113,1114,1115,1116,1117,1118,1119,1120,1121,1122,1123,1124,1125,1126],"sections":[{"id":"name-abstract","title":"Abstract","lines":[" QUIC does not provide a complete version negotiation mechanism but"," instead only provides a way for the server to indicate that the"," version the client chose is unacceptable. This document describes a"," version negotiation mechanism that allows a client and server to"," select a mutually supported version. Optionally, if the client's"," chosen version and the negotiated version share a compatible first"," flight format, the negotiation can take place without incurring an"," extra round trip. This document updates RFC 8999."]},{"id":"name-status-of-this-memo","title":"Status of This Memo","lines":[" This is an Internet Standards Track document.",""," This document is a product of the Internet Engineering Task Force"," (IETF). It represents the consensus of the IETF community. It has"," received public review and has been approved for publication by the"," Internet Engineering Steering Group (IESG). Further information on"," Internet Standards is available in Section 2 of RFC 7841.",""," Information about the current status of this document, any errata,"," and how to provide feedback on it may be obtained at"," https://www.rfc-editor.org/info/rfc9368."]},{"id":"name-copyright-notice","title":"Copyright Notice","lines":[" Copyright (c) 2023 IETF Trust and the persons identified as the"," document authors. All rights reserved.",""," This document is subject to BCP 78 and the IETF Trust's Legal"," Provisions Relating to IETF Documents"," (https://trustee.ietf.org/license-info) in effect on the date of"," publication of this document. Please review these documents"," carefully, as they describe your rights and restrictions with respect"," to this document. Code Components extracted from this document must"," include Revised BSD License text as described in Section 4.e of the"," Trust Legal Provisions and are provided without warranty as described"," in the Revised BSD License."]},{"id":"name-table-of-contents","title":"Table of Contents","lines":[" 1. Introduction"," 1.1. Conventions"," 1.2. Definitions"," 2. Version Negotiation Mechanism"," 2.1. Incompatible Version Negotiation"," 2.2. Compatible Versions"," 2.3. Compatible Version Negotiation"," 2.4. Connections and Version Negotiation"," 2.5. Client Choice of Original Version"," 3. Version Information"," 4. Version Downgrade Prevention"," 5. Server Deployments of QUIC"," 6. Application-Layer Protocol Considerations"," 7. Considerations for Future Versions"," 7.1. Interaction with Retry"," 7.2. Interaction with TLS Resumption"," 7.3. Interaction with 0-RTT"," 8. Special Handling for QUIC Version 1"," 9. Security Considerations"," 10. IANA Considerations"," 10.1. QUIC Transport Parameter"," 10.2. QUIC Transport Error Code"," 11. References"," 11.1. Normative References"," 11.2. Informative References"," Acknowledgments"," Authors' Addresses"]},{"id":"section-1","title":"Introduction","lines":[" The version-invariant properties of QUIC [QUIC-INVARIANTS] define a"," Version Negotiation packet but do not specify how an endpoint reacts"," when it receives one. QUIC version 1 [QUIC] allows the server to use"," a Version Negotiation packet to indicate that the version the client"," chose is unacceptable, but it doesn't allow the client to safely make"," use of that information to create a new connection with a mutually"," supported version. This document updates [QUIC-INVARIANTS] by"," defining version negotiation mechanisms that leverage the Version"," Negotiation packet.",""," With proper safety mechanisms in place, the Version Negotiation"," packet can be part of a mechanism to allow two QUIC implementations"," to negotiate between two totally disjoint versions of QUIC. This"," document specifies version negotiation using Version Negotiation"," packets, which adds an extra round trip to connection establishment"," if needed.",""," It is beneficial to avoid additional round trips whenever possible,"," especially given that most incremental versions are broadly similar"," to the previous version. This specification also defines a simple"," version negotiation mechanism which leverages similarities between"," versions and can negotiate between \"compatible\" versions without"," additional round trips."]},{"id":"section-1.1","title":"Conventions","lines":[" 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 [RFC2119] [RFC8174] when, and only when, they appear in all"," capitals, as shown here."]},{"id":"section-1.2","title":"Definitions","lines":[" The document uses the following terms:",""," * In the context of a given QUIC connection, the \"first flight\" of"," packets refers to the set of packets the client creates and sends"," to initiate the connection before it has heard back from the"," server.",""," * In the context of a given QUIC connection, the \"client's Chosen"," Version\" is the QUIC version of the connection's first flight.",""," * The \"Original Version\" is the QUIC version of the very first"," packet the client sends to the server. If version negotiation"," spans multiple connections (see Section 2.4), the Original Version"," is equal to the client's Chosen Version of the first QUIC"," connection.",""," * The \"Negotiated Version\" is the QUIC version in use on the"," connection once the version negotiation process completes.",""," * The \"Maximum Segment Lifetime\" (MSL) represents the time a QUIC",[[[],0," packet can exist in the network. "],[[1079,1411],161,"Implementations can make this"]],[[[],0," "],[[1079,1411],161,"configurable, and a RECOMMENDED value is one minute."],[[],0," Note that"]]," the term \"segment\" here originated in Section 3.4.1 of [TCP]."],"requirements":[1079]},{"id":"section-2","title":"Version Negotiation Mechanism","lines":[" This document specifies two means of performing version negotiation:"," 1) \"incompatible\", which requires a round trip and is applicable to"," all versions, and 2) \"compatible\", which allows saving the round trip"," but only applies when the versions are compatible (see Section 2.2).",""," The client initiates a QUIC connection by choosing an Original"," Version and sending a first flight of QUIC packets with a long header"," to the server [QUIC-INVARIANTS]. The client's first flight includes"," Version Information (see Section 3), which will be used to optionally"," enable compatible version negotiation (see Section 2.3) and to"," prevent version downgrade attacks (see Section 4).",""," Upon receiving this first flight, the server verifies whether it"," knows how to parse first flights from the Chosen Version (which is"," also the Original Version in this case). If it does not, then it"," starts incompatible version negotiation (see Section 2.1), which"," causes the client to initiate a new connection with a different"," version. For instance, if the client initiates a connection with"," version A that the server can't parse, the server starts incompatible"," version negotiation; then, when the client initiates a new connection"," with version B, we say that the first connection's client Chosen"," Version is A, the second connection's client Chosen Version is B, and"," the Original Version for the entire sequence is A.","",[[[],0," "],[[1094,1908],112,"If the server can parse the first flight, it can establish the"]],[[[],0," "],[[1094,1908],112,"connection using the client's Chosen Version, or it MAY select any"]],[[[],0," "],[[1094,1908],112,"other compatible version, as described in Section 2.3."]],""," Note that it is possible for a server to have the ability to parse"," the first flight of a given version without fully supporting it, in"," the sense that it implements enough of the version's specification to"," parse first flight packets but not enough to fully establish a"," connection using that version."],"requirements":[1094]},{"id":"section-2.1","title":"Incompatible Version Negotiation","lines":[" The server starts incompatible version negotiation by sending a",[[[],0," Version Negotiation packet. "],[[1080,2296],240,"This packet SHALL include each entry"]],[[[],0," "],[[1080,2296],240,"from the server's set of Offered Versions (see Section 5) in a"]],[[[],0," "],[[1080,2296],240,"Supported Version field."],[[],0," "],[[1081,2293],112,"The server MAY add reserved versions (as"]],[[[],0," "],[[1081,2293],112,"defined in Section 6.3 of [QUIC]) in Supported Version fields."]],""," Clients will ignore a Version Negotiation packet if it contains the"," Original Version attempted by the client, as required by Section 4."," The client also ignores a Version Negotiation packet that contains"," incorrect connection ID fields, as required by Section 6 of"," [QUIC-INVARIANTS].","",[[[],0," "],[[1082,2272],240,"Upon receiving the Version Negotiation packet, the client SHALL"]],[[[],0," "],[[1082,2272],240,"search for a version it supports in the list provided by the server."]],[[[],0," "],[[1083,2275,2344],240,"If it doesn't find one, it SHALL abort the connection attempt."]],[[[],0," "],[[1084,2273,2342,2886],244,"Otherwise, it SHALL select a mutually supported version and send a"]],[[[],0," "],[[1084,2273,2342,2886],244,"new first flight with that version -- this version is now the"]],[[[],0," "],[[1084,2273,2342,2886],244,"Negotiated Version."]],""," The new first flight will allow the endpoints to establish a"," connection using the Negotiated Version. The handshake of the"," Negotiated Version will exchange Version Information (see Section 3)"," that is required to ensure that version negotiation was genuine,"," i.e., that no attacker injected packets in order to influence the"," version negotiation process (see Section 4).","",[[[],0," Only servers can start incompatible version negotiation. "],[[1085,2226],240,"Clients"]],[[[],0," "],[[1085,2226],240,"MUST NOT send Version Negotiation packets and servers MUST ignore all"]],[[[],0," "],[[1085,2226],240,"received Version Negotiation packets."]]],"requirements":[1080,1081,1082,1083,1084,1085]},{"id":"section-2.2","title":"Compatible Versions","lines":[" If A and B are two distinct versions of QUIC, A is said to be"," \"compatible\" with B if it is possible to take a first flight of"," packets from version A and convert it into a first flight of packets"," from version B. As an example, if versions A and B are absolutely"," equal in their wire image and behavior during the handshake but"," differ after the handshake, then A is compatible with B and B is"," compatible with A. Note that the conversion of the first flight can"," be lossy; some data, such as QUIC version 1 0-RTT packets, could be"," ignored during conversion and retransmitted later.",""," Version compatibility is not symmetric. It is possible for version A"," to be compatible with version B and for version B not to be"," compatible with version A. This could happen, for example, if"," version B is a strict superset of version A, i.e., if version A"," includes the concept of streams and STREAM frames and version B"," includes the concept of streams and the hypothetical concept of tubes"," along with STREAM and TUBE frames, then A would be compatible with B,"," but B would not be compatible with A.",""," Note that version compatibility does not mean that every single"," possible instance of a first flight will succeed in conversion to the"," other version. A first flight using version A is said to be"," \"compatible\" with version B if two conditions are met: (1) version A"," is compatible with version B and (2) the conversion of this first"," flight to version B is well defined. For example, if version B is"," equal to version A in all aspects except it introduced a new frame in"," its first flight that version A cannot parse or even ignore, then"," version B could still be compatible with version A, as conversions"," would succeed for connections where that frame is not used. In this"," example, first flights using version B that carry this new frame"," would not be compatible with version A.",""," When a new version of QUIC is defined, it is assumed to not be"," compatible with any other version unless otherwise specified."," Similarly, no other version is compatible with the new version unless",[[[],0," otherwise specified. "],[[1086,1854],240,"Implementations MUST NOT assume compatibility"]],[[[],0," "],[[1086,1854],240,"between versions unless explicitly specified."]],""," Note that both endpoints might disagree on whether two versions are"," compatible or not. For example, two versions could have been defined"," concurrently and then specified as compatible in a third document"," much later -- in that scenario, one endpoint might be aware of the"," compatibility document, while the other may not."],"requirements":[1086]},{"id":"section-2.3","title":"Compatible Version Negotiation","lines":[" When the server can parse the client's first flight using the"," client's Chosen Version, it can extract the client's Version"," Information structure (see Section 3). This contains the list of"," versions that the client knows its first flight is compatible with.","",[[[],0," "],[[1087,1907],240,"In order to perform compatible version negotiation, the server MUST"]],[[[],0," "],[[1087,1907],240,"select one of these versions that it (1) supports and (2) knows the"]],[[[],0," "],[[1087,1907],240,"client's Chosen Version is compatible with."],[[],0," This selected version is"]]," now the Negotiated Version. After selecting it, the server attempts"," to convert the client's first flight into that version and replies to"," the client as if it had received the converted first flight.",""," If those formats are identical, as in cases where the Negotiated"," Version is the same as the client's Chosen Version, then this will be",[[[],0," the identity transformation. "],[[1088,1912],240,"If the first flight is correctly"]],[[[],0," "],[[1088,1912],240,"formatted, then this conversion process cannot fail by definition of"]],[[[],0," "],[[1088,1912],240,"the first flight being compatible; if the server is unable to convert"]],[[[],0," "],[[1088,1912],240,"the first flight, it MUST abort the handshake."]],"",[[[],0," "],[[1089,1403],225,"If a document specifies that a QUIC version is compatible with"]],[[[],0," "],[[1089,1403],225,"another, that document MUST specify the mechanism by which clients"]],[[[],0," "],[[1089,1403],225,"are made aware of the Negotiated Version."],[[],0," An example of such a"]]," mechanism is to have the client determine the server's Negotiated"," Version by examining the QUIC long header Version field. Note that,"," in this example mechanism, it is possible for the server to initially"," send packets with the client's Chosen Version before switching to the"," Negotiated Version (this can happen when the client's Version"," Information structure spans multiple packets; in that case, the"," server might acknowledge the first packet in the client's Chosen"," Version and later switch to a different Negotiated Version).",[[[],0," "],[[1090,1404],161,"Mutually compatible versions SHOULD use the same mechanism."]],""," Note that, after the first flight is converted to the Negotiated"," Version, the handshake completes in the Negotiated Version. If the"," Negotiated Version has requirements that apply during the handshake,"," those requirements apply to the entire handshake, including the",[[[],0," converted first flight. "],[[1091,1405],225,"In particular, if the Negotiated Version"]],[[[],0," "],[[1091,1405],225,"mandates that endpoints perform validations on Handshake packets,"]],[[[],0," "],[[1091,1405],225,"endpoints MUST also perform such validations on the converted first"]],[[[],0," "],[[1091,1405],225,"flight."],[[],0," For instance, if the Negotiated Version requires that the"]]," 5-tuple remain stable for the entire handshake (as QUIC version 1"," does), then both endpoints need to validate the 5-tuple of all"," packets received during the handshake, including the converted first"," flight.",""," Note also that the client can disable compatible version negotiation"," by only including the Chosen Version in the Available Versions field"," of the Version Information (see Section 3).",""," If the server does not find a compatible version (including the"," client's Chosen Version), it will perform incompatible version"," negotiation instead (see Section 2.1).",""," Note that it is possible to have incompatible version negotiation"," followed by compatible version negotiation. For instance, if version"," A is compatible with version B and version C is compatible with"," version D, the following scenario could occur:",""," Client Server",""," Chosen = A, Available Versions = (A, B) ------------->"," <------------------------ Version Negotiation = (D, C)",""," Chosen = C, Available Versions = (C, D) ------------->"," <------------- Chosen = D, Available Versions = (D, C)",""," Figure 1: Combined Negotiation Example",""," In this example, the client selected C from the server's Version"," Negotiation packet, but the server preferred D and then selected it"," from the client's offer."],"requirements":[1087,1088,1089,1090,1091]},{"id":"section-2.4","title":"Connections and Version Negotiation","lines":[" QUIC connections are shared state between a client and a server"," [QUIC-INVARIANTS]. The compatible version negotiation mechanism"," defined in this document (see Section 2.3) is performed as part of a"," single QUIC connection; that is, the packets with the client's Chosen"," Version are part of the same connection as the packets with the"," Negotiated Version.",""," In comparison, the incompatible version negotiation mechanism, which"," leverages QUIC Version Negotiation packets (see Section 2.1),"," conceptually operates across two QUIC connections, i.e., the"," connection attempt prior to receiving the Version Negotiation packet"," is distinct from the connection with the incompatible version that"," follows.",""," Note that this separation across two connections is conceptual, i.e.,"," it applies to normative requirements on QUIC connections, but it does"," not require implementations to internally use two distinct connection"," objects."]},{"id":"section-2.5","title":"Client Choice of Original Version","lines":[[[[],0," "],[[1092,1412],161,"When the client picks its Original Version, it SHOULD try to avoid"]],[[[],0," "],[[1092,1412],161,"incompatible version negotiation to save a round trip."],[[],0," "],[[1093,1413],161,"Therefore,"]],[[[],0," "],[[1093,1413],161,"the client SHOULD pick an Original Version to maximize the combined"]],[[[],0," "],[[1093,1413],161,"probability that both:"]],""," * the server knows how to parse first flights from the Original"," Version and",""," * the Original Version is compatible with the client's preferred"," version.",""," Without additional information, this could mean selecting the oldest"," version that the client supports while advertising newer compatible"," versions in the client's first flight."],"requirements":[1092,1093]},{"id":"section-3","title":"Version Information","lines":[" During the handshake, endpoints will exchange Version Information,"," which consists of a Chosen Version and a list of Available Versions.",[[[],0," "],[[1095,1851],240,"Any version of QUIC that supports this mechanism MUST provide a"]],[[[],0," "],[[1095,1851],240,"mechanism to exchange Version Information in both directions during"]],[[[],0," "],[[1095,1851],240,"the handshake, such that this data is authenticated."]],""," In QUIC version 1, the Version Information is transmitted using a new"," version_information transport parameter (see Section 7.4 of [QUIC])."," The contents of Version Information are shown below (using the"," notation from Section 1.3 of [QUIC]):","",[[[],0," "],[[2473,2482],16,"Version Information {"]],[[[],0," "],[[2473,2482],16,"Chosen Version (32),"]],[[[],0," "],[[2473,2482],16,"Available Versions (32) ...,"]],[[[],0," "],[[],0,"}"]],""," Figure 2: Version Information Format",""," The content of each field is described below:",""," Chosen Version: The version that the sender has chosen to use for"," this connection. In most cases, this field will be equal to the"," value of the Version field in the long header that carries this"," data; however, future versions or extensions can choose to set"," different values in the long header Version field.",""," The contents of the Available Versions field depend on whether it is"," sent by the client or by the server.",""," Client-Sent Available Versions: When sent by a client, the Available"," Versions field lists all the versions that this first flight is",[[[],0," compatible with, ordered by descending preference. "],[[1096,1853],240,"Note that the"]],[[[],0," "],[[1096,1853],240,"version in the Chosen Version field MUST be included in this list"]],[[[],0," "],[[1096,1853],240,"to allow the client to communicate the Chosen Version's"]],[[[],0," "],[[1096,1853],240,"preference."],[[],0," "],[[1097,1909],112,"Note that this preference is only advisory; servers"]],[[[],0," "],[[1097,1909],112,"MAY choose to use their own preference instead."]]," Server-Sent Available Versions: When sent by a server, the Available"," Versions field lists all the Fully Deployed Versions of this"," server deployment (see Section 5). The ordering of the versions"," in this field does not carry any semantics. Note that the version"," in the Chosen Version field is not necessarily included in this"," list, because the server operator could be in the process of",[[[],0," removing support for this version. "],[[1098,1416],97,"For the same reason, the"]],[[[],0," "],[[1098,1416],97,"Available Versions field MAY be empty."]],"",[[[],0," "],[[1099,1417],97,"Clients and servers MAY both include versions following the pattern"]],[[[],0," "],[[1099,1417],97,"0x?a?a?a?a in their Available Versions list."],[[],0," Those versions are"]]," reserved to exercise version negotiation (see Section 15 of [QUIC])"," and will never be selected when choosing a version to use."],"requirements":[1095,1096,1097,1098,1099]},{"id":"section-4","title":"Version Downgrade Prevention","lines":[" A version downgrade is an attack where a malicious entity manages to"," make the QUIC endpoints negotiate a QUIC version different from the"," one they would have negotiated in the absence of the attack. The"," mechanism described in this document is designed to prevent downgrade"," attacks.","",[[[],0," "],[[1100,2271,2887],244,"Clients MUST ignore any received Version Negotiation packets that"]],[[[],0," "],[[1100,2271,2887],244,"contain the Original Version."],[[],0," "],[[1101,2269,2888],244,"A client that makes a connection"]],[[[],0," "],[[1101,2269,2888],244,"attempt based on information received from a Version Negotiation"]],[[[],0," "],[[1101,2269,2888],244,"packet MUST ignore any Version Negotiation packets it receives in"]],[[[],0," "],[[1101,2269,2888],244,"response to that connection attempt."]],"",[[[],0," "],[[1102,2481,2503],240,"Both endpoints MUST parse their peer's Version Information during the"]],[[[],0," "],[[1102,2481,2503],240,"handshake."],[[],0," "],[[1103,2483],240,"If that leads to a parsing failure (for example, if it is"]],[[[],0," "],[[1103,2483],240,"too short or if its length is not divisible by four), then the"]],[[[],0," "],[[1103,2483],240,"endpoint MUST close the connection; if the connection was using QUIC"]],[[[],0," "],[[1103,2483],240,"version 1, that connection closure MUST use a transport error of type"]],[[[],0," "],[[1103,2483],240,"TRANSPORT_PARAMETER_ERROR."],[[],0," "],[[1104,2484,2485,2504,2518,3057,3058],244,"If an endpoint receives a Chosen Version"]],[[[],0," "],[[1104,2484,2485,2504,2518,3057,3058],244,"equal to zero, or any Available Version equal to zero, it MUST treat"]],[[[],0," "],[[1104,2484,2485,2504,2518,3057,3058],244,"it as a parsing failure."],[[],0," "],[[1105,2505],240,"If a server receives Version Information"]],[[[],0," "],[[1105,2505],240,"where the Chosen Version is not included in Available Versions, it"]],[[[],0," "],[[1105,2505],240,"MUST treat it as a parsing failure."]],"",[[[],0," "],[[1106,2474],240,"Every QUIC version that supports version negotiation MUST define a"]],[[[],0," "],[[1106,2474],240,"method for closing the connection with a version negotiation error."]]," For QUIC version 1, version negotiation errors are signaled using a"," transport error of type VERSION_NEGOTIATION_ERROR (see Section 10.2).",""," When a server receives a client's first flight, the server will first"," establish which QUIC version is in use for this connection in order"," to properly parse the first flight. This may involve examining data"," that is not part of the handshake transcript, such as parts of the",[[[],0," packet header. "],[[1107,1905],240,"When the server then processes the client's Version"]],[[[],0," "],[[1107,1905],240,"Information, the server MUST validate that the client's Chosen"]],[[[],0," "],[[1107,1905],240,"Version matches the version in use for the connection."],[[],0," "],[[1108,1906,2507],240,"If the two"]],[[[],0," "],[[1108,1906,2507],240,"differ, the server MUST close the connection with a version"]],[[[],0," "],[[1108,1906,2507],240,"negotiation error."]],""," In the specific case of QUIC version 1, the server determines that"," version 1 is in use by observing that the Version field of the first",[[[],0," Long Header packet it receives is set to 0x00000001. "],[[1109,2506],240,"Subsequently,"]],[[[],0," "],[[1109,2506],240,"if the server receives the client's Version Information over QUIC"]],[[[],0," "],[[1109,2506],240,"version 1 (as indicated by the Version field of the Long Header"]],[[[],0," "],[[1109,2506],240,"packets that carried the transport parameters) and the client's"]],[[[],0," "],[[1109,2506],240,"Chosen Version is not set to 0x00000001, the server MUST close the"]],[[[],0," "],[[1109,2506],240,"connection with a version negotiation error."]],"",[[[],0," "],[[1110,2508],112,"Servers MAY complete the handshake even if the Version Information is"]],[[[],0," "],[[1110,2508],112,"missing."],[[],0," "],[[1111,2519],240,"Clients MUST NOT complete the handshake if they are"]],[[[],0," "],[[1111,2519],240,"reacting to a Version Negotiation packet and the Version Information"]],[[[],0," "],[[1111,2519],240,"is missing, but MAY do so otherwise."]],"",[[[],0," "],[[1112,2520,3060],244,"If a client receives Version Information where the server's Chosen"]],[[[],0," "],[[1112,2520,3060],244,"Version was not sent by the client as part of its Available Versions,"]],[[[],0," "],[[1112,2520,3060],244,"the client MUST close the connection with a version negotiation"]],[[[],0," "],[[1112,2520,3060],244,"error."],[[],0," "],[[1113,3059],228,"If a client has reacted to a Version Negotiation packet and"]],[[[],0," "],[[1113,3059],228,"the server's Version Information was missing, the client MUST close"]],[[[],0," "],[[1113,3059],228,"the connection with a version negotiation error."]],"",[[[],0," "],[[1114,2017,2521],240,"If the client received and acted on a Version Negotiation packet, the"]],[[[],0," "],[[1114,2017,2521],240,"client MUST validate the server's Available Versions field."],[[],0," The"]]," Available Versions field is validated by confirming that the client"," would have attempted the same version with knowledge of the versions"," the server supports. That is, the client would have selected the"," same version if it received a Version Negotiation packet that listed"," the versions in the server's Available Versions field, plus the",[[[],0," Negotiated Version. "],[[1115,2523,3061,3062],244,"If the client would have selected a different"]],[[[],0," "],[[1115,2523,3061,3062],244,"version, the client MUST close the connection with a version"]],[[[],0," "],[[1115,2523,3061,3062],244,"negotiation error."],[[],0," "],[[1116,2522],240,"In particular, if the client reacted to a Version"]],[[[],0," "],[[1116,2522],240,"Negotiation packet and the server's Available Versions field is"]],[[[],0," "],[[1116,2522],240,"empty, the client MUST close the connection with a version"]],[[[],0," "],[[1116,2522],240,"negotiation error."],[[],0," These connection closures prevent an attacker"]]," from being able to use forged Version Negotiation packets to force a"," version downgrade.",""," As an example, let's assume a client supports hypothetical QUIC"," versions 10, 12, and 14 with a preference for higher versions. The"," client initiates a connection attempt with version 12. Let's explore"," two independent example scenarios:",""," * In the first scenario, the server supports versions 10, 13, and"," 14, but only 13 and 14 are Fully Deployed (see Section 5). The"," server sends a Version Negotiation packet with versions 10, 13,"," and 14. This triggers an incompatible version negotiation, and"," the client initiates a new connection with version 14. Then, the"," server's Available Versions field contains 13 and 14. In that"," scenario, the client would have also picked 14 if it had received"," a Version Negotiation packet with versions 13 and 14; therefore,"," the handshake succeeds using Negotiated Version 14.",""," * In the second scenario, the server supports versions 10, 13, and"," 14, and they are all Fully Deployed. However, the attacker forges"," a Version Negotiation packet with versions 10 and 13. This"," triggers an incompatible version negotiation, and the client"," initiates a new connection with version 10. Then, the server's"," Available Versions field contains 10, 13, and 14. In that"," scenario, the client would have picked 14 instead of 10 if it had"," received a Version Negotiation packet with versions 10, 13, and"," 14; therefore, the client aborts the handshake with a version"," negotiation error.",""," This validation of Available Versions is not sufficient to prevent"," downgrade. Downgrade prevention also depends on the client ignoring"," Version Negotiation packets that contain the Original Version (see"," Section 2.1).",""," After the process of version negotiation described in this document"," completes, the version in use for the connection is the version that"," the server sent in the Chosen Version field of its Version"," Information. That remains true even if other versions were used in"," the Version field of long headers at any point in the lifetime of the",[[[],0," connection. "],[[1117,2018],240,"In particular, since the client can be made aware of the"]],[[[],0," "],[[1117,2018],240,"Negotiated Version by the QUIC long header version during compatible"]],[[[],0," "],[[1117,2018],240,"version negotiation (see Section 2.3), clients MUST validate that the"]],[[[],0," "],[[1117,2018],240,"server's Chosen Version is equal to the Negotiated Version; if they"]],[[[],0," "],[[1117,2018],240,"do not match, the client MUST close the connection with a version"]],[[[],0," "],[[1117,2018],240,"negotiation error."],[[],0," This prevents an attacker's ability to influence"]]," version negotiation by forging the long header Version field."],"requirements":[1100,1101,1102,1103,1104,1105,1106,1107,1108,1109,1110,1111,1112,1113,1114,1115,1116,1117]},{"id":"section-5","title":"Server Deployments of QUIC","lines":[" While this document mainly discusses a single QUIC server, it is"," common for deployments of QUIC servers to include a fleet of multiple"," server instances. Therefore, we define the following terms:",""," Acceptable Versions: This is the set of versions supported by a"," given server instance. More specifically, these are the versions"," that a given server instance will use if a client sends a first"," flight using them."," Offered Versions: This is the set of versions that a given server"," instance will send in a Version Negotiation packet if it receives"," a first flight from an unknown version. This set will most often"," be equal to the Acceptable Versions set, except during short"," transitions while versions are added or removed (see below)."," Fully Deployed Versions: This is the set of QUIC versions that is"," supported and negotiated by every single QUIC server instance in"," this deployment. If a deployment only contains a single server"," instance, then this set is equal to the Offered Versions set,"," except during short transitions while versions are added or"," removed (see below).",""," If a deployment contains multiple server instances, software updates"," may not happen at exactly the same time on all server instances."," Because of this, a client might receive a Version Negotiation packet"," from a server instance that has already been updated, and the"," client's resulting connection attempt might reach a different server"," instance which hasn't been updated yet.",""," However, even when there is only a single server instance, it is"," still possible to receive a stale Version Negotiation packet if the"," server performs its software update while the Version Negotiation"," packet is in flight.",""," This could cause the version downgrade prevention mechanism described",[[[],0," in Section 4 to falsely detect a downgrade attack. "],[[1118,1406],161,"To avoid that,"]],[[[],0," "],[[1118,1406],161,"server operators SHOULD perform a three-step process when they wish"]],[[[],0," "],[[1118,1406],161,"to add or remove support for a version, as described below."]],""," When adding support for a new version:",""," * The first step is to progressively add support for the new version"," to all server instances. This step updates the Acceptable"," Versions but not the Offered Versions nor the Fully Deployed"," Versions. Once all server instances have been updated, operators"," wait for at least one MSL to allow any in-flight Version"," Negotiation packets to arrive.",""," * Then, the second step is to progressively add the new version to"," Offered Versions on all server instances. Once complete,"," operators wait for at least another MSL.",""," * Finally, the third step is to progressively add the new version to"," Fully Deployed Versions on all server instances.",""," When removing support for a version:",""," * The first step is to progressively remove the version from Fully"," Deployed Versions on all server instances. Once it has been"," removed on all server instances, operators wait for at least one"," MSL to allow any in-flight Version Negotiation packets to arrive.",""," * Then, the second step is to progressively remove the version from"," Offered Versions on all server instances. Once complete,"," operators wait for at least another MSL.",""," * Finally, the third step is to progressively remove support for the"," version from all server instances. That step updates the"," Acceptable Versions.",""," Note that, during the update window, connections are vulnerable to"," downgrade attacks for Acceptable Versions that are not Fully"," Deployed. This is because a client cannot distinguish such a"," downgrade attack from legitimate exchanges with both updated and non-"," updated server instances."],"requirements":[1118]},{"id":"section-6","title":"Application-Layer Protocol Considerations","lines":[" When a client creates a QUIC connection, its goal is to use an"," application-layer protocol. Therefore, when considering which"," versions are compatible, clients will only consider versions that"," support one of the intended application-layer protocols. If the"," client's first flight advertises multiple Application-Layer Protocol"," Negotiation (ALPN) [ALPN] tokens and multiple compatible versions, it"," is possible for some application-layer protocols to not be able to"," run over some of the offered compatible versions. It is the server's"," responsibility to only select an ALPN token that can run over the"," compatible QUIC version that it selects.","",[[[],0," "],[[1119,1402],225,"A given ALPN token MUST NOT be used with a new QUIC version that is"]],[[[],0," "],[[1119,1402],225,"different from the version for which the ALPN token was originally"]],[[[],0," "],[[1119,1402],225,"defined, unless all the following requirements are met:"]],""," * The new QUIC version supports the transport features required by"," the application protocol.",""," * The new QUIC version supports ALPN.",""," * The version of QUIC for which the ALPN token was originally"," defined is compatible with the new QUIC version.","",[[[],0," "],[[1120,2274,2343],240,"When incompatible version negotiation is in use, the second"]],[[[],0," "],[[1120,2274,2343],240,"connection that is created in response to the received Version"]],[[[],0," "],[[1120,2274,2343],240,"Negotiation packet MUST restart its application-layer protocol"]],[[[],0," "],[[1120,2274,2343],240,"negotiation process without taking into account the Original Version."]]],"requirements":[1119,1120]},{"id":"section-7","title":"Considerations for Future Versions","lines":[[[[],0," "],[[1124,1408],161,"In order to facilitate the deployment of future versions of QUIC,"]],[[[],0," "],[[1124,1408],161,"designers of future versions SHOULD attempt to design their new"]],[[[],0," "],[[1124,1408],161,"version such that commonly deployed versions are compatible with it."]],""," QUIC version 1 defines multiple features which are not documented in"," the QUIC invariants. Since, at the time of writing, QUIC version 1"," is widely deployed, this section discusses considerations for future"," versions to help with compatibility with QUIC version 1."],"requirements":[1124]},{"id":"section-7.1","title":"Interaction with Retry","lines":[" QUIC version 1 features Retry packets, which the server can send to"," validate the client's IP address before parsing the client's first"," flight. A server that sends a Retry packet can do so before parsing"," the client's first flight. Therefore, a server that sends a Retry"," packet might not have processed the client's Version Information"," before doing so.","",[[[],0," "],[[1121,1409],225,"If a future document wishes to define compatibility between two"]],[[[],0," "],[[1121,1409],225,"versions that support Retry, that document MUST specify how version"]],[[[],0," "],[[1121,1409],225,"negotiation (both compatible and incompatible) interacts with Retry"]],[[[],0," "],[[1121,1409],225,"during a handshake that requires both."],[[],0," For example, that could be"]]," accomplished by having the server first send a Retry packet in the"," Original Version, thereby validating the client's IP address before"," attempting compatible version negotiation. If both versions support"," authenticating Retry packets, the compatibility definition needs to"," define how to authenticate the Retry in the Negotiated Version"," handshake even though the Retry itself was sent using the client's"," Chosen Version."],"requirements":[1121]},{"id":"section-7.2","title":"Interaction with TLS Resumption","lines":[" QUIC version 1 uses TLS 1.3, which supports session resumption by"," sending session tickets in one connection that can be used in a later",[[[],0," connection (see Section 2.2 of [TLS]). "],[[1122,1407],161,"New versions that also use"]],[[[],0," "],[[1122,1407],161,"TLS 1.3 SHOULD mandate that their session tickets are tightly scoped"]],[[[],0," "],[[1122,1407],161,"to one version of QUIC, i.e., require that clients not use them"]],[[[],0," "],[[1122,1407],161,"across multiple version and that servers validate this client"]],[[[],0," "],[[1122,1407],161,"requirement."],[[],0," This helps mitigate cross-protocol attacks."]]],"requirements":[1122]},{"id":"section-7.3","title":"Interaction with 0-RTT","lines":[" QUIC version 1 allows sending data from the client to the server",[[[],0," during the handshake by using 0-RTT packets. "],[[1123,1410],225,"If a future document"]],[[[],0," "],[[1123,1410],225,"wishes to define compatibility between two versions that support"]],[[[],0," "],[[1123,1410],225,"0-RTT, that document MUST address the scenario where there are 0-RTT"]],[[[],0," "],[[1123,1410],225,"packets in the client's first flight."],[[],0," For example, this could be"]]," accomplished by defining which transformations are applied to 0-RTT"," packets. That document could specify that compatible version"," negotiation causes 0-RTT data to be rejected by the server."],"requirements":[1123]},{"id":"section-8","title":"Special Handling for QUIC Version 1","lines":[[[[],0," "],[[1125,1414],225,"Because QUIC version 1 was the only QUIC version that was published"]],[[[],0," "],[[1125,1414],225,"on the IETF Standards Track before this document, it is handled"]],[[[],0," "],[[1125,1414],225,"specially as follows: if a client is starting a QUIC version 1"]],[[[],0," "],[[1125,1414],225,"connection in response to a received Version Negotiation packet and"]],[[[],0," "],[[1125,1414],225,"the version_information transport parameter is missing from the"]],[[[],0," "],[[1125,1414],225,"server's transport parameters, then the client SHALL proceed as if"]],[[[],0," "],[[1125,1414],225,"the server's transport parameters contained a version_information"]],[[[],0," "],[[1125,1414],225,"transport parameter with a Chosen Version set to 0x00000001 and an"]],[[[],0," "],[[1125,1414],225,"Available Version list containing exactly one version set to"]],[[[],0," "],[[1125,1414],225,"0x00000001."],[[],0," This allows version negotiation to work with servers"]],[[[],0," that only support QUIC version 1. "],[[1126,1415],225,"Note that implementations that"]],[[[],0," "],[[1126,1415],225,"wish to use version negotiation to negotiate versions other than QUIC"]],[[[],0," "],[[1126,1415],225,"version 1 MUST implement the version negotiation mechanism defined in"]],[[[],0," "],[[1126,1415],225,"this document."]]],"requirements":[1125,1126]},{"id":"section-9","title":"Security Considerations","lines":[" The security of this version negotiation mechanism relies on the"," authenticity of the Version Information exchanged during the"," handshake. In QUIC version 1, transport parameters are"," authenticated, ensuring the security of this mechanism. Negotiation"," between compatible versions will have the security of the weakest"," common version.",""," The requirement that versions not be assumed compatible mitigates the"," possibility of cross-protocol attacks, but more analysis is still"," needed here. That analysis is out of scope for this document."]},{"id":"section-10","title":"IANA Considerations","lines":[]},{"id":"section-10.1","title":"QUIC Transport Parameter","lines":[" IANA has registered the following value in the \"QUIC Transport"," Parameters\" registry maintained at .",""," Value: 0x11"," Parameter Name: version_information"," Status: permanent"," Specification: RFC 9368"]},{"id":"section-10.2","title":"QUIC Transport Error Code","lines":[" IANA has registered the following value in the \"QUIC Transport Error"," Codes\" registry maintained at .",""," Value: 0x11"," Code: VERSION_NEGOTIATION_ERROR"," Description: Error negotiating version"," Status: permanent"," Specification: RFC 9368"]},{"id":"section-11","title":"References","lines":[]},{"id":"section-11.1","title":"Normative References","lines":[" [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,"," \"Transport Layer Security (TLS) Application-Layer Protocol"," Negotiation Extension\", RFC 7301, DOI 10.17487/RFC7301,"," July 2014, .",""," [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., \"QUIC: A UDP-Based"," Multiplexed and Secure Transport\", RFC 9000,"," DOI 10.17487/RFC9000, May 2021,"," .",""," [QUIC-INVARIANTS]"," Thomson, M., \"Version-Independent Properties of QUIC\","," RFC 8999, DOI 10.17487/RFC8999, May 2021,"," .",""," [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate"," Requirement Levels\", BCP 14, RFC 2119,"," DOI 10.17487/RFC2119, March 1997,"," .",""," [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC"," 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,"," May 2017, .",""," [TLS] Rescorla, E., \"The Transport Layer Security (TLS) Protocol"," Version 1.3\", RFC 8446, DOI 10.17487/RFC8446, August 2018,"," ."]},{"id":"section-11.2","title":"Informative References","lines":[" [TCP] Eddy, W., Ed., \"Transmission Control Protocol (TCP)\","," STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,"," ."]},{"id":"name-acknowledgments","title":"Acknowledgments","lines":[" The authors would like to thank Nick Banks, Mike Bishop, Martin Duke,"," Ryan Hamilton, Roberto Peon, Anthony Rossi, and Martin Thomson for"," their input and contributions."]},{"id":"name-authors-addresses","title":"Authors' Addresses","lines":[" David Schinazi"," Google LLC"," 1600 Amphitheatre Parkway"," Mountain View, CA 94043"," United States of America"," Email: dschinazi.ietf@gmail.com",""," Eric Rescorla"," Mozilla"," Email: ekr@rtfm.com"]}]},"https://www.rfc-editor.org/rfc/rfc9369":{"format":"ietf","requirements":[1127,1128,1129,1130,1131,1132,1133,1134,1135,1136,1137,1138,1139,1140,1141,1142],"sections":[{"id":"name-abstract","title":"Abstract","lines":[" This document specifies QUIC version 2, which is identical to QUIC"," version 1 except for some trivial details. Its purpose is to combat"," various ossification vectors and exercise the version negotiation"," framework. It also serves as a template for the minimum changes in"," any future version of QUIC.",""," Note that \"version 2\" is an informal name for this proposal that"," indicates it is the second version of QUIC to be published as a"," Standards Track document. The protocol specified here uses a version"," number other than 2 in the wire image, in order to minimize"," ossification risks."]},{"id":"name-status-of-this-memo","title":"Status of This Memo","lines":[" This is an Internet Standards Track document.",""," This document is a product of the Internet Engineering Task Force"," (IETF). It represents the consensus of the IETF community. It has"," received public review and has been approved for publication by the"," Internet Engineering Steering Group (IESG). Further information on"," Internet Standards is available in Section 2 of RFC 7841.",""," Information about the current status of this document, any errata,"," and how to provide feedback on it may be obtained at"," https://www.rfc-editor.org/info/rfc9369."]},{"id":"name-copyright-notice","title":"Copyright Notice","lines":[" Copyright (c) 2023 IETF Trust and the persons identified as the"," document authors. All rights reserved.",""," This document is subject to BCP 78 and the IETF Trust's Legal"," Provisions Relating to IETF Documents"," (https://trustee.ietf.org/license-info) in effect on the date of"," publication of this document. Please review these documents"," carefully, as they describe your rights and restrictions with respect"," to this document. Code Components extracted from this document must"," include Revised BSD License text as described in Section 4.e of the"," Trust Legal Provisions and are provided without warranty as described"," in the Revised BSD License."]},{"id":"name-table-of-contents","title":"Table of Contents","lines":[" 1. Introduction"," 2. Conventions"," 3. Differences with QUIC Version 1"," 3.1. Version Field"," 3.2. Long Header Packet Types"," 3.3. Cryptography Changes"," 3.3.1. Initial Salt"," 3.3.2. HMAC-based Key Derivation Function (HKDF) Labels"," 3.3.3. Retry Integrity Tag"," 4. Version Negotiation Considerations"," 4.1. Compatible Negotiation Requirements"," 5. TLS Resumption and NEW_TOKEN Tokens"," 6. Ossification Considerations"," 7. Applicability"," 8. Security Considerations"," 9. IANA Considerations"," 10. References"," 10.1. Normative References"," 10.2. Informative References"," Appendix A. Sample Packet Protection"," A.1. Keys"," A.2. Client Initial"," A.3. Server Initial"," A.4. Retry"," A.5. ChaCha20-Poly1305 Short Header Packet"," Acknowledgments"," Author's Address"]},{"id":"section-1","title":"Introduction","lines":[" QUIC version 1 [QUIC] has numerous extension points, including the"," version number that occupies the second through fifth bytes of every"," long header (see [QUIC-INVARIANTS]). If experimental versions are"," rare, and QUIC version 1 constitutes the vast majority of QUIC"," traffic, there is the potential for middleboxes to ossify on the"," version bytes that are usually 0x00000001.",""," In QUIC version 1, Initial packets are encrypted with the version-"," specific salt, as described in Section 5.2 of [QUIC-TLS]. Protecting"," Initial packets in this way allows observers to inspect their"," contents, which includes the TLS Client Hello or Server Hello"," messages. Again, there is the potential for middleboxes to ossify on"," the version 1 key derivation and packet formats.",""," Finally, [QUIC-VN] describes two mechanisms endpoints can use to"," negotiate which QUIC version to select. The \"incompatible\" version"," negotiation method can support switching from any QUIC version to any"," other version with full generality, at the cost of an additional"," round trip at the start of the connection. \"Compatible\" version"," negotiation eliminates the round-trip penalty but levies some"," restrictions on how much the two versions can differ semantically.",""," QUIC version 2 is meant to mitigate ossification concerns and"," exercise the version negotiation mechanisms. The changes provide an"," example of the minimum set of changes necessary to specify a new QUIC"," version. However, note that the choice of the version number on the"," wire is randomly chosen instead of \"2\", and the two bits that"," identify each Long Header packet type are different from version 1;"," both of these properties are meant to combat ossification and are not"," strictly required of a new QUIC version.",""," Any endpoint that supports two versions needs to implement version"," negotiation to protect against downgrade attacks."]},{"id":"section-2","title":"Conventions","lines":[" 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 [RFC2119] [RFC8174] when, and only when, they appear in all"," capitals, as shown here."]},{"id":"section-3","title":"Differences with QUIC Version 1","lines":[[[[],0," "],[[1127,1650,1651,1652,2373,2993,3015,3016,3141,3142],244,"Except for a few differences, QUIC version 2 endpoints MUST implement"]],[[[],0," "],[[1127,1650,1651,1652,2373,2993,3015,3016,3141,3142],244,"the QUIC version 1 specification as described in [QUIC], [QUIC-TLS],"]],[[[],0," "],[[1127,1650,1651,1652,2373,2993,3015,3016,3141,3142],244,"and [QUIC-RECOVERY]."],[[],0," The remainder of this section lists the"]]," differences."],"requirements":[1127]},{"id":"section-3.1","title":"Version Field","lines":[" The Version field of long headers is 0x6b3343cf. This was generated"," by taking the first four bytes of the sha256sum of \"QUICv2 version"," number\"."]},{"id":"section-3.2","title":"Long Header Packet Types","lines":[" All version 2 Long Header packet types are different. The Type field"," values are:",""," * Initial: 0b01",""," * 0-RTT: 0b10",""," * Handshake: 0b11",""," * Retry: 0b00"]},{"id":"section-3.3","title":"Cryptography Changes","lines":[]},{"id":"section-3.3.1","title":"Initial Salt","lines":[" The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS]"," changes to:",""," initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9",""," This is the first 20 bytes of the sha256sum of \"QUICv2 salt\"."]},{"id":"section-3.3.2","title":"HMAC-based Key Derivation Function (HKDF) Labels","lines":[" The labels used in [QUIC-TLS] to derive packet protection keys"," (Section 5.1), header protection keys (Section 5.4), Retry Integrity"," Tag keys (Section 5.8), and key updates (Section 6.1) change from"," \"quic key\" to \"quicv2 key\", from \"quic iv\" to \"quicv2 iv\", from"," \"quic hp\" to \"quicv2 hp\", and from \"quic ku\" to \"quicv2 ku\" to meet"," the guidance for new versions in Section 9.6 of that document."]},{"id":"section-3.3.3","title":"Retry Integrity Tag","lines":[" The key and nonce used for the Retry Integrity Tag (Section 5.8 of"," [QUIC-TLS]) change to:",""," secret ="," 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f"," key = 0x8fb4b01b56ac48e260fbcbcead7ccc92"," nonce = 0xd86969bc2d7c6d9990efb04a",""," The secret is the sha256sum of \"QUICv2 retry secret\". The key and"," nonce are derived from this secret with the labels \"quicv2 key\" and"," \"quicv2 iv\", respectively."]},{"id":"section-4","title":"Version Negotiation Considerations","lines":[" QUIC version 2 is not intended to deprecate version 1. Endpoints"," that support version 2 might continue support for version 1 to"," maximize compatibility with other endpoints. In particular, HTTP",[[[],0," clients often use Alt-Svc [RFC7838] to discover QUIC support. "],[[1138,1430,3096],180,"As"]],[[[],0," "],[[1138,1430,3096],180,"this mechanism does not currently distinguish between QUIC versions,"]],[[[],0," "],[[1138,1430,3096],180,"HTTP servers SHOULD support multiple versions to reduce the"]],[[[],0," "],[[1138,1430,3096],180,"probability of incompatibility and the cost associated with QUIC"]],[[[],0," "],[[1138,1430,3096],180,"version negotiation or TCP fallback."],[[],0," For example, an origin"]]," advertising support for \"h3\" in Alt-Svc should support QUIC version"," 1, as it was the original QUIC version used by HTTP/3; therefore,"," some clients will only support that version.","",[[[],0," "],[[1139,1852],240,"Any QUIC endpoint that supports QUIC version 2 MUST send, process,"]],[[[],0," "],[[1139,1852],240,"and validate the version_information transport parameter specified in"]],[[[],0," "],[[1139,1852],240,"[QUIC-VN] to prevent version downgrade attacks."]],""," Note that version 2 meets the definition in [QUIC-VN] of a compatible"," version with version 1, and version 1 is compatible with version 2."," Therefore, servers can use compatible negotiation to switch a",[[[],0," connection between the two versions. "],[[1140,1911,3098],180,"Endpoints that support both"]],[[[],0," "],[[1140,1911,3098],180,"versions SHOULD support compatible version negotiation to avoid a"]],[[[],0," "],[[1140,1911,3098],180,"round trip."]]],"requirements":[1138,1139,1140]},{"id":"section-4.1","title":"Compatible Negotiation Requirements","lines":[" Compatible version negotiation between versions 1 and 2 follows the"," same requirements in either direction. This section uses the terms"," \"original version\" and \"negotiated version\" from [QUIC-VN].","",[[[],0," "],[[1128,2201,2204,2298],240,"If the server sends a Retry packet, it MUST use the original version."]],[[[],0," The client ignores Retry packets using other versions. "],[[1129,2208,2348],240,"The client"]],[[[],0," "],[[1129,2208,2348],240,"MUST NOT use a different version in the subsequent Initial packet"]],[[[],0," "],[[1129,2208,2348],240,"that contains the Retry token."],[[],0," "],[[1130,2229,2244,2246],112,"The server MAY encode the QUIC"]],[[[],0," "],[[1130,2229,2244,2246],112,"version in its Retry token to validate that the client did not switch"]],[[[],0," "],[[1130,2229,2244,2246],112,"versions, and drop the packet if it switched, to enforce client"]],[[[],0," "],[[1130,2229,2244,2246],112,"compliance."]],""," QUIC version 2 uses the same transport parameters to authenticate the",[[[],0," Retry as QUIC version 1. "],[[1131,2202],240,"After switching to a negotiated version"]],[[[],0," "],[[1131,2202],240,"after a Retry, the server MUST include the relevant transport"]],[[[],0," "],[[1131,2202],240,"parameters to validate that the server sent the Retry and the"]],[[[],0," "],[[1131,2202],240,"connection IDs used in the exchange, as described in Section 7.3 of"]],[[[],0," "],[[1131,2202],240,"[QUIC]."]],"",[[[],0," "],[[2109],16,"The server cannot send CRYPTO frames until it has processed the"]],[[[],0," "],[[2109],16,"client's transport parameters."],[[],0," "],[[1132,2118,2120,2122,2812],244,"The server MUST send all CRYPTO"]],[[[],0," "],[[1132,2118,2120,2122,2812],244,"frames using the negotiated version."]],""," The client learns the negotiated version by observing the first long"," header Version field that differs from the original version. If the"," client receives a CRYPTO frame from the server in the original"," version, it indicates that the negotiated version is equal to the"," original version.","",[[[],0," "],[[2087],16,"Before the server is able to process transport parameters from the"]],[[[],0," "],[[2087],16,"client, it might need to respond to Initial packets from the client."]],[[[],0," "],[[2087],16,"For these packets, the server uses the original version."]],"",[[[],0," "],[[1133,2088,2814,3099],180,"Once the client has learned the negotiated version, it SHOULD send"]],[[[],0," "],[[1133,2088,2814,3099],180,"subsequent Initial packets using that version."],[[],0," "],[[1134,1418],225,"The server MUST NOT"]],[[[],0," "],[[1134,1418],225,"discard its original version Initial receive keys until it"]],[[[],0," "],[[1134,1418],225,"successfully processes a Handshake packet with the negotiated"]],[[[],0," "],[[1134,1418],225,"version."]],"",[[[],0," "],[[1135,1910,2119,2121,2123,2813,2815],244,"Both endpoints MUST send Handshake and 1-RTT packets using the"]],[[[],0," "],[[1135,1910,2119,2121,2123,2813,2815],244,"negotiated version."],[[],0," "],[[1136,1890],240,"An endpoint MUST drop packets using any other"]],[[[],0," "],[[1136,1890],240,"version."],[[],0," Endpoints have no need to generate the keying material that"]]," would allow them to decrypt or authenticate such packets.","",[[[],0," "],[[1137,1420],225,"The client MUST NOT send 0-RTT packets using the negotiated version,"]],[[[],0," "],[[1137,1420],225,"even after processing a packet of that version from the server."]]," Servers can accept 0-RTT and then process 0-RTT packets from the"," original version."],"requirements":[1128,1129,1130,1131,1132,1133,1134,1135,1136,1137]},{"id":"section-5","title":"TLS Resumption and NEW_TOKEN Tokens","lines":[" TLS session tickets and NEW_TOKEN tokens are specific to the QUIC",[[[],0," version of the connection that provided them. "],[[1141,2196,2260,2265],240,"Clients MUST NOT use a"]],[[[],0," "],[[1141,2196,2260,2265],240,"session ticket or token from a QUIC version 1 connection to initiate"]],[[[],0," "],[[1141,2196,2260,2265],240,"a QUIC version 2 connection, and vice versa."],[[],0," "],[[1914,2255,2262],16,"When a connection"]],[[[],0," "],[[1914,2255,2262],16,"includes compatible version negotiation, any issued server tokens are"]],[[[],0," "],[[1914,2255,2262],16,"considered to originate from the negotiated version, not the original"]],[[[],0," "],[[1914,2255,2262],16,"one."]],"",[[[],0," "],[[1142,1419],225,"Servers MUST validate the originating version of any session ticket"]],[[[],0," "],[[1142,1419],225,"or token and not accept one issued from a different version."],[[],0," A"]]," rejected ticket results in falling back to a full TLS handshake,"," without 0-RTT. A rejected token results in the client address"," remaining unverified, which limits the amount of data the server can"," send.",""," After compatible version negotiation, any resulting session ticket"," maps to the negotiated version rather than the original one."],"requirements":[1141,1142]},{"id":"section-6","title":"Ossification Considerations","lines":[" QUIC version 2 provides protection against some forms of"," ossification. Devices that assume that all long headers will encode"," version 1, or that the version 1 Initial key derivation formula will"," remain version-invariant, will not correctly process version 2"," packets.",""," However, many middleboxes, such as firewalls, focus on the first"," packet in a connection, which will often remain in the version 1"," format due to the considerations above.",""," Clients interested in combating middlebox ossification can initiate a"," connection using version 2 if they are reasonably certain the server"," supports it and if they are willing to suffer a round-trip penalty if"," they are incorrect. In particular, a server that issues a session"," ticket for version 2 indicates an intent to maintain version 2"," support while the ticket remains valid, even if support cannot be"," guaranteed."]},{"id":"section-7","title":"Applicability","lines":[" QUIC version 2 provides no change from QUIC version 1 for the"," capabilities available to applications. Therefore, all Application-"," Layer Protocol Negotiation (ALPN) [RFC7301] codepoints specified to"," operate over QUIC version 1 can also operate over this version of"," QUIC. In particular, both the \"h3\" [HTTP/3] and \"doq\" [RFC9250]"," ALPNs can operate over QUIC version 2.",""," Unless otherwise stated, all QUIC extensions defined to work with"," version 1 also work with version 2."]},{"id":"section-8","title":"Security Considerations","lines":[" QUIC version 2 introduces no changes to the security or privacy"," properties of QUIC version 1.",""," The mandatory version negotiation mechanism guards against downgrade"," attacks, but downgrades have no security implications, as the version"," properties are identical.",""," Support for QUIC version 2 can help an observer to fingerprint both"," client and server devices."]},{"id":"section-9","title":"IANA Considerations","lines":[" IANA has added the following entries to the \"QUIC Versions\" registry"," maintained at .",""," Value: 0x6b3343cf"," Status: permanent"," Specification: RFC 9369"," Change Controller: IETF"," Contact: QUIC WG",""," Value: 0x709a50c4"," Status: provisional"," Specification: RFC 9369"," Change Controller: IETF"," Contact: QUIC WG"," Notes: QUIC v2 draft codepoint"]},{"id":"section-10","title":"References","lines":[]},{"id":"section-10.1","title":"Normative References","lines":[" [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., \"QUIC: A UDP-Based"," Multiplexed and Secure Transport\", RFC 9000,"," DOI 10.17487/RFC9000, May 2021,"," .",""," [QUIC-RECOVERY]"," Iyengar, J., Ed. and I. Swett, Ed., \"QUIC Loss Detection"," and Congestion Control\", RFC 9002, DOI 10.17487/RFC9002,"," May 2021, .",""," [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., \"Using TLS to Secure"," QUIC\", RFC 9001, DOI 10.17487/RFC9001, May 2021,"," .",""," [QUIC-VN] Schinazi, D. and E. Rescorla, \"Compatible Version"," Negotiation for QUIC\", RFC 9368, DOI 10.17487/RFC9368, May"," 2023, .",""," [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate"," Requirement Levels\", BCP 14, RFC 2119,"," DOI 10.17487/RFC2119, March 1997,"," .",""," [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC"," 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,"," May 2017, ."]},{"id":"section-10.2","title":"Informative References","lines":[" [HTTP/3] Bishop, M., Ed., \"HTTP/3\", RFC 9114, DOI 10.17487/RFC9114,"," June 2022, .",""," [QUIC-INVARIANTS]"," Thomson, M., \"Version-Independent Properties of QUIC\","," RFC 8999, DOI 10.17487/RFC8999, May 2021,"," .",""," [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,"," \"Transport Layer Security (TLS) Application-Layer Protocol"," Negotiation Extension\", RFC 7301, DOI 10.17487/RFC7301,"," July 2014, .",""," [RFC7838] Nottingham, M., McManus, P., and J. Reschke, \"HTTP"," Alternative Services\", RFC 7838, DOI 10.17487/RFC7838,"," April 2016, .",""," [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, \"DNS over"," Dedicated QUIC Connections\", RFC 9250,"," DOI 10.17487/RFC9250, May 2022,"," ."]},{"id":"appendix-A","title":"Sample Packet Protection","lines":[" This section shows examples of packet protection so that"," implementations can be verified incrementally. Samples of Initial"," packets from both the client and server plus a Retry packet are"," defined. These packets use an 8-byte client-chosen Destination"," Connection ID of 0x8394c8f03e515708. Some intermediate values are"," included. All values are shown in hexadecimal."]},{"id":"appendix-A.1","title":"Keys","lines":[" The labels generated during the execution of the HKDF-Expand-Label"," function (that is, HkdfLabel.label) and part of the value given to"," the HKDF-Expand function in order to produce its output are:",""," client in: 00200f746c73313320636c69656e7420696e00",""," server in: 00200f746c7331332073657276657220696e00",""," quicv2 key: 001010746c73313320717569637632206b657900",""," quicv2 iv: 000c0f746c7331332071756963763220697600",""," quicv2 hp: 00100f746c7331332071756963763220687000",""," The initial secret is common:",""," initial_secret = HKDF-Extract(initial_salt, cid)"," = 2062e8b3cd8d52092614b8071d0aa1fb"," 7c2e3ac193f78b280e72d8f5751f6aba",""," The secrets for protecting client packets are:",""," client_initial_secret"," = HKDF-Expand-Label(initial_secret, \"client in\", \"\", 32)"," = 14ec9d6eb9fd7af83bf5a668bc17a7e2"," 83766aade7ecd0891f70f9ff7f4bf47b",""," key = HKDF-Expand-Label(client_initial_secret, \"quicv2 key\", \"\", 16)"," = 8b1a0bc121284290a29e0971b5cd045d",""," iv = HKDF-Expand-Label(client_initial_secret, \"quicv2 iv\", \"\", 12)"," = 91f73e2351d8fa91660e909f",""," hp = HKDF-Expand-Label(client_initial_secret, \"quicv2 hp\", \"\", 16)"," = 45b95e15235d6f45a6b19cbcb0294ba9",""," The secrets for protecting server packets are:",""," server_initial_secret"," = HKDF-Expand-Label(initial_secret, \"server in\", \"\", 32)"," = 0263db1782731bf4588e7e4d93b74639"," 07cb8cd8200b5da55a8bd488eafc37c1",""," key = HKDF-Expand-Label(server_initial_secret, \"quicv2 key\", \"\", 16)"," = 82db637861d55e1d011f19ea71d5d2a7",""," iv = HKDF-Expand-Label(server_initial_secret, \"quicv2 iv\", \"\", 12)"," = dd13c276499c0249d3310652",""," hp = HKDF-Expand-Label(server_initial_secret, \"quicv2 hp\", \"\", 16)"," = edf6d05c83121201b436e16877593c3a"]},{"id":"appendix-A.2","title":"Client Initial","lines":[" The client sends an Initial packet. The unprotected payload of this"," packet contains the following CRYPTO frame, plus enough PADDING"," frames to make a 1162-byte payload:",""," 060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868"," 04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578"," 616d706c652e636f6dff01000100000a 00080006001d00170018001000070005"," 04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba"," baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400"," 0d0010000e0403050306030203080408 050806002d00020101001c0002400100"," 3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000"," 75300901100f088394c8f03e51570806 048000ffff",""," The unprotected header indicates a length of 1182 bytes: the 4-byte"," packet number, 1162 bytes of frames, and the 16-byte authentication"," tag. The header includes the connection ID and a packet number of 2:",""," d36b3343cf088394c8f03e5157080000449e00000002",""," Protecting the payload produces an output that is sampled for header"," protection. Because the header uses a 4-byte packet number encoding,"," the first 16 bytes of the protected payload is sampled and then"," applied to the header as follows:",""," sample = ffe67b6abcdb4298b485dd04de806071",""," mask = AES-ECB(hp, sample)[0..4]"," = 94a0c95e80",""," header[0] ^= mask[0] & 0x0f"," = d7"," header[18..21] ^= mask[1..4]"," = a0c95e82"," header = d76b3343cf088394c8f03e5157080000449ea0c95e82",""," The resulting protected packet is:",""," d76b3343cf088394c8f03e5157080000 449ea0c95e82ffe67b6abcdb4298b485"," dd04de806071bf03dceebfa162e75d6c 96058bdbfb127cdfcbf903388e99ad04"," 9f9a3dd4425ae4d0992cfff18ecf0fdb 5a842d09747052f17ac2053d21f57c5d"," 250f2c4f0e0202b70785b7946e992e58 a59ac52dea6774d4f03b55545243cf1a"," 12834e3f249a78d395e0d18f4d766004 f1a2674802a747eaa901c3f10cda5500"," cb9122faa9f1df66c392079a1b40f0de 1c6054196a11cbea40afb6ef5253cd68"," 18f6625efce3b6def6ba7e4b37a40f77 32e093daa7d52190935b8da58976ff33"," 12ae50b187c1433c0f028edcc4c2838b 6a9bfc226ca4b4530e7a4ccee1bfa2a3"," d396ae5a3fb512384b2fdd851f784a65 e03f2c4fbe11a53c7777c023462239dd"," 6f7521a3f6c7d5dd3ec9b3f233773d4b 46d23cc375eb198c63301c21801f6520"," bcfb7966fc49b393f0061d974a2706df 8c4a9449f11d7f3d2dcbb90c6b877045"," 636e7c0c0fe4eb0f697545460c806910 d2c355f1d253bc9d2452aaa549e27a1f"," ac7cf4ed77f322e8fa894b6a83810a34 b361901751a6f5eb65a0326e07de7c12"," 16ccce2d0193f958bb3850a833f7ae43 2b65bc5a53975c155aa4bcb4f7b2c4e5"," 4df16efaf6ddea94e2c50b4cd1dfe060 17e0e9d02900cffe1935e0491d77ffb4"," fdf85290fdd893d577b1131a610ef6a5 c32b2ee0293617a37cbb08b847741c3b"," 8017c25ca9052ca1079d8b78aebd4787 6d330a30f6a8c6d61dd1ab5589329de7"," 14d19d61370f8149748c72f132f0fc99 f34d766c6938597040d8f9e2bb522ff9"," 9c63a344d6a2ae8aa8e51b7b90a4a806 105fcbca31506c446151adfeceb51b91"," abfe43960977c87471cf9ad4074d30e1 0d6a7f03c63bd5d4317f68ff325ba3bd"," 80bf4dc8b52a0ba031758022eb025cdd 770b44d6d6cf0670f4e990b22347a7db"," 848265e3e5eb72dfe8299ad7481a4083 22cac55786e52f633b2fb6b614eaed18"," d703dd84045a274ae8bfa73379661388 d6991fe39b0d93debb41700b41f90a15"," c4d526250235ddcd6776fc77bc97e7a4 17ebcb31600d01e57f32162a8560cacc"," 7e27a096d37a1a86952ec71bd89a3e9a 30a2a26162984d7740f81193e8238e61"," f6b5b984d4d3dfa033c1bb7e4f0037fe bf406d91c0dccf32acf423cfa1e70710"," 10d3f270121b493ce85054ef58bada42 310138fe081adb04e2bd901f2f13458b"," 3d6758158197107c14ebb193230cd115 7380aa79cae1374a7c1e5bbcb80ee23e"," 06ebfde206bfb0fcbc0edc4ebec30966 1bdd908d532eb0c6adc38b7ca7331dce"," 8dfce39ab71e7c32d318d136b6100671 a1ae6a6600e3899f31f0eed19e3417d1"," 34b90c9058f8632c798d4490da498730 7cba922d61c39805d072b589bd52fdf1"," e86215c2d54e6670e07383a27bbffb5a ddf47d66aa85a0c6f9f32e59d85a44dd"," 5d3b22dc2be80919b490437ae4f36a0a e55edf1d0b5cb4e9a3ecabee93dfc6e3"," 8d209d0fa6536d27a5d6fbb17641cde2 7525d61093f1b28072d111b2b4ae5f89"," d5974ee12e5cf7d5da4d6a31123041f3 3e61407e76cffcdcfd7e19ba58cf4b53"," 6f4c4938ae79324dc402894b44faf8af bab35282ab659d13c93f70412e85cb19"," 9a37ddec600545473cfb5a05e08d0b20 9973b2172b4d21fb69745a262ccde96b"," a18b2faa745b6fe189cf772a9f84cbfc"]},{"id":"appendix-A.3","title":"Server Initial","lines":[" The server sends the following payload in response, including an ACK"," frame, a CRYPTO frame, and no PADDING frames:",""," 02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739"," 88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94"," 0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00"," 020304",""," The header from the server includes a new connection ID and a 2-byte"," packet number encoding for a packet number of 1:",""," d16b3343cf0008f067a5502a4262b50040750001",""," As a result, after protection, the header protection sample is taken,"," starting from the third protected byte:",""," sample = 6f05d8a4398c47089698baeea26b91eb"," mask = 4dd92e91ea"," header = dc6b3343cf0008f067a5502a4262b5004075d92f",""," The final protected packet is then:",""," dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698"," baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17"," f9af6e16886c61bfc703106fbaf3cb4c fa52382dd16a393e42757507698075b2"," c984c707f0a0812d8cd5a6881eaf21ce da98f4bd23f6fe1a3e2c43edd9ce7ca8"," 4bed8521e2e140"]},{"id":"appendix-A.4","title":"Retry","lines":[" This shows a Retry packet that might be sent in response to the"," Initial packet in Appendix A.2. The integrity check includes the"," client-chosen connection ID value of 0x8394c8f03e515708, but that"," value is not included in the final Retry packet:",""," cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436"," 65dcc7b6"]},{"id":"appendix-A.5","title":"ChaCha20-Poly1305 Short Header Packet","lines":[" This example shows some of the steps required to protect a packet"," with a short header. It uses AEAD_CHACHA20_POLY1305.",""," In this example, TLS produces an application write secret from which"," a server uses HKDF-Expand-Label to produce four values: a key, an"," Initialization Vector (IV), a header protection key, and the secret"," that will be used after keys are updated (this last value is not used"," further in this example).",""," secret"," = 9ac312a7f877468ebe69422748ad00a1"," 5443f18203a07d6060f688f30f21632b",""," key = HKDF-Expand-Label(secret, \"quicv2 key\", \"\", 32)"," = 3bfcddd72bcf02541d7fa0dd1f5f9eee"," a817e09a6963a0e6c7df0f9a1bab90f2",""," iv = HKDF-Expand-Label(secret, \"quicv2 iv\", \"\", 12)"," = a6b5bc6ab7dafce30ffff5dd",""," hp = HKDF-Expand-Label(secret, \"quicv2 hp\", \"\", 32)"," = d659760d2ba434a226fd37b35c69e2da"," 8211d10c4f12538787d65645d5d1b8e2",""," ku = HKDF-Expand-Label(secret, \"quicv2 ku\", \"\", 32)"," = c69374c49e3d2a9466fa689e49d476db"," 5d0dfbc87d32ceeaa6343fd0ae4c7d88",""," The following shows the steps involved in protecting a minimal packet"," with an empty Destination Connection ID. This packet contains a"," single PING frame (that is, a payload of just 0x01) and has a packet"," number of 654360564. In this example, using a packet number of"," length 3 (that is, 49140 is encoded) avoids having to pad the payload"," of the packet; PADDING frames would be needed if the packet number is"," encoded on fewer bytes.",""," pn = 654360564 (decimal)"," nonce = a6b5bc6ab7dafce328ff4a29"," unprotected header = 4200bff4"," payload plaintext = 01"," payload ciphertext = 0ae7b6b932bc27d786f4bc2bb20f2162ba",""," The resulting ciphertext is the minimum size possible. One byte is"," skipped to produce the sample for header protection.",""," sample = e7b6b932bc27d786f4bc2bb20f2162ba"," mask = 97580e32bf"," header = 5558b1c6",""," The protected packet is the smallest possible packet size of 21"," bytes.",""," packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba"]},{"id":"name-acknowledgments","title":"Acknowledgments","lines":[" The author would like to thank Christian Huitema, Lucas Pardue, Kyle"," Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro"," Tsujikawa, and Martin Thomson for their helpful suggestions."]},{"id":"name-author-s-address","title":"Author's Address","lines":[" Martin Duke"," Google LLC"," Email: martin.h.duke@gmail.com"]}]}},"annotations":[{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.1","line":3,"type":"EXCEPTION","comment":"This requirement defines IANA registry metadata for provisional QUIC\ncodepoint registrations, not behavior implemented by a QUIC endpoint.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":15,"type":"EXCEPTION","comment":"This is guidance for authors requesting QUIC registry codepoints, not a\ntransport behavior implemented by CoQUIC.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":27,"type":"EXCEPTION","comment":"This is guidance for authors requesting QUIC registry codepoints, not a\ntransport behavior implemented by CoQUIC.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":40,"type":"EXCEPTION","comment":"This requirement is directed at IANA registry administration, not at QUIC\nendpoint implementations.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":52,"type":"EXCEPTION","comment":"This is guidance for authors requesting QUIC registry codepoints, not a\ntransport behavior implemented by CoQUIC.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":63,"type":"EXCEPTION","comment":"This is guidance for applications registering QUIC codepoints, not runtime\nbehavior implemented by this endpoint.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":74,"type":"EXCEPTION","comment":"This requirement concerns designated-expert maintenance of IANA registries,\nnot QUIC endpoint behavior.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":86,"type":"EXCEPTION","comment":"This requirement concerns designated-expert maintenance of IANA registries,\nnot QUIC endpoint behavior.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":97,"type":"EXCEPTION","comment":"This requirement concerns designated-expert maintenance of IANA registries,\nnot QUIC endpoint behavior.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":108,"type":"EXCEPTION","comment":"This requirement concerns designated-expert maintenance of IANA registries,\nnot QUIC endpoint behavior.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":120,"type":"EXCEPTION","comment":"This requirement concerns designated-expert maintenance of IANA registries,\nnot QUIC endpoint behavior.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.4","line":132,"type":"EXCEPTION","comment":"This requirement is directed at IANA registry policy, not at QUIC endpoint\nimplementations.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.4","line":143,"type":"EXCEPTION","comment":"This requirement concerns how IANA registries define registration policy\nranges, not behavior implemented by a QUIC endpoint.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.4","line":154,"type":"EXCEPTION","comment":"This requirement concerns registry-definition policy, not behavior implemented\nby a QUIC endpoint.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.2","line":165,"type":"EXCEPTION","comment":"This requirement is directed at IANA registry administration. CoQUIC can\ntest handling of reserved values separately, but it does not assign or list\nIANA codepoints.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.3","line":178,"type":"EXCEPTION","comment":"This requirement defines the format of IANA transport-parameter registry\nentries, not QUIC endpoint behavior.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.3","line":189,"type":"EXCEPTION","comment":"This requirement is directed at IANA registry administration. CoQUIC can\ntest handling of reserved transport parameters separately, but it does not\nassign or list IANA codepoints.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.4","line":202,"type":"EXCEPTION","comment":"This requirement defines the format of IANA frame-type registry entries,\nnot QUIC endpoint behavior.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.4","line":213,"type":"EXCEPTION","comment":"This requirement is guidance for specifications that register new frame\ntypes, not behavior implemented by this QUIC endpoint.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.5","line":226,"type":"EXCEPTION","comment":"This requirement defines the format of IANA error-code registry entries,\nnot QUIC endpoint behavior.\n"},{"source":".duvet/exceptions/rfc9000/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.5","line":237,"type":"EXCEPTION","comment":"This requirement defines IANA error-code registry metadata, not runtime\nbehavior implemented by this endpoint.\n"},{"source":".duvet/exceptions/rfc9000/implementation-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":3,"type":"EXCEPTION","comment":"This is optional receiver policy. CoQUIC accepts overlapping stream bytes\nby retaining the first received data for an offset and discarding duplicate\ncoverage, rather than closing the connection when a later overlap carries\ndifferent bytes.\n"},{"source":".duvet/exceptions/rfc9000/implementation-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.1","line":17,"type":"EXCEPTION","comment":"This is an optional stream-state transition. CoQUIC supports resetting a\nstream, but its application-facing stream creation path does not need to\nadvertise this particular first-frame shortcut as a separate required\nfeature.\n"},{"source":".duvet/exceptions/rfc9000/implementation-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.2","line":31,"type":"EXCEPTION","comment":"This is optional receive-side reset delivery policy. CoQUIC exposes peer\nstream reset events, while exact application delivery interruption and\ndiscard policy is an implementation choice rather than a mandatory\ntransport requirement.\n"},{"source":".duvet/exceptions/rfc9000/implementation-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":46,"type":"EXCEPTION","comment":"This is optional receiver behavior. CoQUIC sends STOP_SENDING for active\nreceive-side cancellation paths, but it does not need to exercise every\nstate in which STOP_SENDING is permitted.\n"},{"source":".duvet/exceptions/rfc9000/implementation-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":59,"type":"EXCEPTION","comment":"This is optional behavior after receiving STOP_SENDING for a stream whose\ndata has already been sent. CoQUIC may send the reset promptly rather than\nusing this deferral strategy.\n"},{"source":".duvet/exceptions/rfc9000/implementation-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":72,"type":"EXCEPTION","comment":"This is optional local policy for handling a peer RESET_STREAM after\nsending STOP_SENDING. CoQUIC records peer reset information; ignoring that\napplication error code is allowed but not required.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1.2","line":3,"type":"EXCEPTION","comment":"This requirement is directed at application-protocol specifications using\nQUIC. CoQUIC implements the transport facility; protocol-specific guidance\nbelongs to each application protocol.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":15,"type":"EXCEPTION","comment":"CoQUIC can derive stateless reset tokens from a configured static secret\nand a connection ID, but global uniqueness of user-supplied or\ncross-process connection IDs under a shared static key is an endpoint\ndeployment/configuration invariant outside a single transport connection.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":29,"type":"EXCEPTION","comment":"This constrains how operators allocate and persist connection IDs across\nnodes or restarts that share a stateless-reset key. A CoQUIC endpoint can\nretain local reset-token routes, but it cannot prove that another process\nor future deployment will not reuse a revealed connection ID with the same\nstatic key.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.2","line":44,"type":"EXCEPTION","comment":"This requirement is directed at application-protocol specifications using\nQUIC. CoQUIC exposes stream reset and cancellation behavior but does not\ndefine the application protocol policy for every protocol layered on QUIC.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.21","line":56,"type":"EXCEPTION","comment":"This requirement is directed at specifications defining future QUIC\nextensions, not at the base transport implementation.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.12","line":68,"type":"EXCEPTION","comment":"This requirement is directed at specifications for future QUIC versions.\nCoQUIC implements currently supported version-negotiation behavior but does\nnot define future versions of QUIC.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5","line":81,"type":"EXCEPTION","comment":"This is deployment guidance for operators of QUIC servers. CoQUIC cannot\nverify network ingress filtering or the security posture of unrelated UDP\nendpoints in the deployment environment.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.11","line":94,"type":"EXCEPTION","comment":"This requirement is directed at deployments that shard QUIC connections\nacross multiple endpoint instances sharing a stateless-reset key. CoQUIC\ncan generate and verify reset tokens for an endpoint, but arranging\ncluster routing so a connection ID reaches the correct live instance is\noutside the transport library.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.11","line":110,"type":"EXCEPTION","comment":"This is a multi-instance deployment invariant. CoQUIC suppresses\nstateless resets for connection IDs owned by the local endpoint state, but\nit cannot know whether another process or host that shares a configured\nstatic key still has active connection state.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5","line":124,"type":"EXCEPTION","comment":"This requirement is directed at specifications defining future server\nmigration extensions, not at the base transport implementation.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.6","line":135,"type":"EXCEPTION","comment":"This is deployment guidance for operators. CoQUIC can expose transport\nlimits and timers, but deployment-specific client quotas and transfer-speed\npolicies are outside the transport protocol implementation.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.7","line":151,"type":"EXCEPTION","comment":"This is deployment guidance for operators. CoQUIC tracks stream state, but\ndeployment-specific abuse policies and operational mitigation choices are\noutside the transport protocol implementation.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":163,"type":"EXCEPTION","comment":"This requirement is directed at specifications defining new transport\nparameters. CoQUIC implements the storage behavior for transport parameters\nit supports, but it does not define every future transport parameter.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.3","line":176,"type":"EXCEPTION","comment":"This is deployment guidance. CoQUIC exposes the disable_active_migration\ntransport parameter in configuration, but whether a particular deployment\nhas load-balancing continuity for client address changes is known only to\nthe application or operator.\n"},{"source":".duvet/exceptions/rfc9000/non-runtime-requirements.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.3","line":191,"type":"EXCEPTION","comment":"This requirement constrains deployment architecture for servers using\nload balancing and shared reset keys. CoQUIC cannot verify cluster routing\nor cross-instance state ownership from within a single endpoint.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1.2","line":33,"type":"SPEC","level":"SHOULD","comment":"Application protocols that use QUIC SHOULD provide guidance on when\ndeferring an idle timeout is appropriate.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":31,"type":"SPEC","level":"MUST","comment":"To avoid excessively small idle timeout periods, endpoints MUST\nincrease the idle timeout period to be at least three times the\ncurrent Probe Timeout (PTO).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":58,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD limit the rate at which it generates packets in\nthe closing state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":65,"type":"SPEC","level":"MAY","comment":"An endpoint's selected connection ID and the QUIC version are\nsufficient information to identify packets for a closing connection;\nthe endpoint MAY discard all other connection state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":73,"type":"SPEC","level":"MAY","comment":"An\nendpoint MAY retain packet protection keys for incoming packets to\nallow it to read and process a CONNECTION_CLOSE frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":81,"type":"SPEC","level":"MAY","comment":"An endpoint MAY drop packet protection keys when entering the closing\nstate and send a packet containing a CONNECTION_CLOSE frame in\nresponse to any UDP datagram that is received.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":89,"type":"SPEC","level":"MUST","comment":"To avoid being used for an amplification attack,\nsuch endpoints MUST limit the cumulative size of packets it sends to\nthree times the cumulative size of the packets that are received and\nattributed to the connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":98,"type":"SPEC","level":"MAY","comment":"To minimize the state that an endpoint\nmaintains for a closing connection, endpoints MAY send the exact same\npacket in response to any received packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":106,"type":"SPEC","level":"MUST","comment":"An endpoint in the closing state MUST either discard\npackets received from an unvalidated address or limit the cumulative\nsize of packets it sends to an unvalidated address to three times the\nsize of packets it receives from that address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.2","line":26,"type":"SPEC","level":"MUST","comment":"While otherwise identical to the closing state, an\nendpoint in the draining state MUST NOT send any packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.2","line":33,"type":"SPEC","level":"MAY","comment":"An endpoint that receives a CONNECTION_CLOSE frame MAY send a single\npacket containing a CONNECTION_CLOSE frame before entering the\ndraining state, using a NO_ERROR code if appropriate.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.2","line":41,"type":"SPEC","level":"MUST","comment":"An endpoint\nMUST NOT send further packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.2","line":48,"type":"SPEC","level":"MAY","comment":"An endpoint MAY enter the draining state from the closing state if it\nreceives a CONNECTION_CLOSE frame, which indicates that the peer is\nalso closing or draining.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":65,"type":"SPEC","level":"MUST","comment":"After the handshake is confirmed (see\nSection 4.1.2 of [QUIC-TLS]), an endpoint MUST send any\nCONNECTION_CLOSE frames in a 1-RTT packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":73,"type":"SPEC","level":"MAY","comment":"However, prior to\nconfirming the handshake, it is possible that more advanced packet\nprotection keys are not available to the peer, so another\nCONNECTION_CLOSE frame MAY be sent in a packet that uses a lower\npacket protection level.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":83,"type":"SPEC","level":"SHOULD","comment":"Under these\ncircumstances, a server SHOULD send a CONNECTION_CLOSE frame in\nboth Handshake and Initial packets to ensure that at least one of\nthem is processable by the client.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":92,"type":"SPEC","level":"SHOULD","comment":"* Prior to confirming the handshake, a peer might be unable to\nprocess 1-RTT packets, so an endpoint SHOULD send a\nCONNECTION_CLOSE frame in both Handshake and 1-RTT packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":100,"type":"SPEC","level":"SHOULD","comment":"A\nserver SHOULD also send a CONNECTION_CLOSE frame in an Initial\npacket.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":108,"type":"SPEC","level":"MUST","comment":"A CONNECTION_CLOSE of type 0x1d MUST be replaced by a\nCONNECTION_CLOSE of type 0x1c when sending the frame in Initial or\nHandshake packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":116,"type":"SPEC","level":"MUST","comment":"Endpoints MUST clear the value of the\nReason Phrase field and SHOULD use the APPLICATION_ERROR code when\nconverting to a CONNECTION_CLOSE of type 0x1c.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":124,"type":"SPEC","level":"MAY","comment":"For this\nreason, endpoints MAY discard packets rather than immediately close\nif errors are detected in packets that lack authentication.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":47,"type":"SPEC","level":"SHOULD","comment":"These states SHOULD persist for at least three\ntimes the current PTO interval as defined in [QUIC-RECOVERY].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":54,"type":"SPEC","level":"MAY","comment":"Endpoints that have some alternative means to ensure that late-\narriving packets do not induce a response, such as those that are\nable to close the UDP socket, MAY end these states earlier to allow\nfor faster resource recovery.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":63,"type":"SPEC","level":"SHOULD","comment":"Servers that retain an open socket for\naccepting new connections SHOULD NOT end the closing or draining\nstate early.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":71,"type":"SPEC","level":"SHOULD","comment":"Once its closing or draining state ends, an endpoint SHOULD discard\nall connection state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":78,"type":"SPEC","level":"MAY","comment":"The endpoint MAY send a Stateless Reset in\nresponse to any further incoming packets belonging to this\nconnection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":44,"type":"SPEC","level":"MAY","comment":"Endpoints MAY skip this check if any packet from a datagram is\nsuccessfully processed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":51,"type":"SPEC","level":"MUST","comment":"However, the comparison MUST be performed\nwhen the first packet in an incoming datagram either cannot be\nassociated with a connection or cannot be decrypted.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":59,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT check for any stateless reset tokens associated\nwith connection IDs it has not used or for connection IDs that have\nbeen retired.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":67,"type":"SPEC","level":"MUST","comment":"When comparing a datagram to stateless reset token values, endpoints\nMUST perform the comparison without leaking information about the\nvalue of the token.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":75,"type":"SPEC","level":"MUST","comment":"If the last 16 bytes of the datagram are identical in value to a\nstateless reset token, the endpoint MUST enter the draining period\nand not send any further packets on this connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":53,"type":"SPEC","level":"MUST","comment":"The stateless reset token MUST be difficult to guess.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":59,"type":"SPEC","level":"MUST","comment":"An endpoint that uses this design MUST\neither use the same connection ID length for all connections or\nencode the length of the connection ID such that it can be recovered\nwithout state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":68,"type":"SPEC","level":"MUST","comment":"This method for\nchoosing the stateless reset token means that the combination of\nconnection ID and static key MUST NOT be used for another connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":76,"type":"SPEC","level":"MUST","comment":"A connection ID from a connection\nthat is reset by revealing the stateless reset token MUST NOT be\nreused for new connections at nodes that share a static key.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":84,"type":"SPEC","level":"MUST","comment":"The same stateless reset token MUST NOT be used for multiple\nconnection IDs.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":91,"type":"SPEC","level":"MAY","comment":"Endpoints are not required to compare new values\nagainst all previous values, but a duplicate value MAY be treated as\na connection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.3","line":30,"type":"SPEC","level":"MUST","comment":"An endpoint MUST ensure that every Stateless Reset that it sends is\nsmaller than the packet that triggered it, unless it maintains state\nsufficient to prevent looping.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":136,"type":"SPEC","level":"MAY","comment":"An\nendpoint MAY send a Stateless Reset in response to receiving a packet\nthat it cannot associate with an active connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":144,"type":"SPEC","level":"MUST","comment":"An endpoint that wishes to communicate a fatal\nconnection error MUST use a CONNECTION_CLOSE frame if it is able.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":151,"type":"SPEC","level":"SHOULD","comment":"The remainder of the first byte\nand an arbitrary number of bytes following it are set to values that\nSHOULD be indistinguishable from random.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":159,"type":"SPEC","level":"SHOULD","comment":"To achieve that end,\nthe endpoint SHOULD ensure that all packets it sends are at least 22\nbytes longer than the minimum connection ID length that it requests\nthe peer to include in its packets, adding PADDING frames as\nnecessary.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":169,"type":"SPEC","level":"SHOULD","comment":"An\nendpoint that sends a Stateless Reset in response to a packet that is\n43 bytes or shorter SHOULD send a Stateless Reset that is one byte\nshorter than the packet it responds to.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":178,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send a Stateless Reset that is three times or\nmore larger than the packet it receives to avoid being used for\namplification.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":186,"type":"SPEC","level":"MUST","comment":"Endpoints MUST discard packets that are too small to be valid QUIC\npackets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":193,"type":"SPEC","level":"MUST","comment":"Endpoints MUST send Stateless Resets formatted as a packet with a\nshort header.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":200,"type":"SPEC","level":"MUST","comment":"However, endpoints MUST treat any packet ending in a\nvalid stateless reset token as a Stateless Reset, as other QUIC\nversions might allow the use of a long header.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":208,"type":"SPEC","level":"MAY","comment":"An endpoint MAY send a Stateless Reset in response to a packet with a\nlong header.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10","line":17,"type":"SPEC","level":"MAY","comment":"An endpoint MAY discard connection state if it does not have a\nvalidated path on which it can send packets; see Section 8.2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.1","line":38,"type":"SPEC","level":"MUST","comment":"Errors that result in the connection being unusable, such as an\nobvious violation of protocol semantics or corruption of state that\naffects an entire connection, MUST be signaled using a\nCONNECTION_CLOSE frame (Section 19.19).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.1","line":47,"type":"SPEC","level":"SHOULD","comment":"An\nendpoint SHOULD be prepared to retransmit a packet containing a\nCONNECTION_CLOSE frame if it receives more packets on a terminated\nconnection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.1","line":56,"type":"SPEC","level":"MAY","comment":"As the AEAD for Initial packets does not provide strong\nauthentication, an endpoint MAY discard an invalid Initial packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.2","line":25,"type":"SPEC","level":"MUST","comment":"RESET_STREAM MUST only be instigated by the\napplication protocol that uses QUIC.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.2","line":32,"type":"SPEC","level":"SHOULD","comment":"Application protocols SHOULD define rules for handling streams that\nare prematurely canceled by either endpoint.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":25,"type":"SPEC","level":"SHOULD","comment":"An endpoint that detects an error SHOULD signal the existence of that\nerror to its peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":32,"type":"SPEC","level":"SHOULD","comment":"The most appropriate error code (Section 20) SHOULD be included in\nthe frame that signals the error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":39,"type":"SPEC","level":"MAY","comment":"In particular, an endpoint MAY use any applicable error\ncode when it detects an error condition; a generic error code (such\nas PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place\nof specific error codes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":48,"type":"SPEC","level":"MUST","comment":"A\nstateless reset MUST NOT be used by an endpoint that has the state\nnecessary to send a frame on the connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":50,"type":"SPEC","level":"MUST","comment":"Receivers MUST be able to\nprocess coalesced packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":57,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD include multiple frames in a single packet if they\nare to be sent at the same encryption level, instead of coalescing\nmultiple packets at the same encryption level.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":65,"type":"SPEC","level":"MAY","comment":"Receivers MAY route based on the information in the first packet\ncontained in a UDP datagram.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":72,"type":"SPEC","level":"MUST","comment":"Senders MUST NOT coalesce QUIC packets\nwith different connection IDs into a single UDP datagram.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":79,"type":"SPEC","level":"SHOULD","comment":"Receivers\nSHOULD ignore any subsequent packets with a different Destination\nConnection ID than the first packet in the datagram.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":87,"type":"SPEC","level":"MUST","comment":"The receiver of coalesced QUIC packets MUST\nindividually process each QUIC packet and separately acknowledge\nthem, as if they were received as the payload of different UDP\ndatagrams.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":96,"type":"SPEC","level":"MUST","comment":"For example, if decryption fails (because the keys are\nnot available or for any other reason), the receiver MAY either\ndiscard or buffer the packet for later processing and MUST attempt to\nprocess the remaining packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":74,"type":"SPEC","level":"MUST","comment":"Subsequent packets sent in the same packet\nnumber space MUST increase the packet number by at least one.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":81,"type":"SPEC","level":"MUST","comment":"A QUIC endpoint MUST NOT reuse a packet number within the same packet\nnumber space in one connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":88,"type":"SPEC","level":"MUST","comment":"If the packet number for sending\nreaches 2^62-1, the sender MUST close the connection without sending\na CONNECTION_CLOSE frame or any further packets; an endpoint MAY send\na Stateless Reset (Section 10.3) in response to further packets that\nit receives.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":98,"type":"SPEC","level":"MUST","comment":"A receiver MUST discard a newly unprotected packet unless it is\ncertain that it has not processed another packet with the same packet\nnumber from the same packet number space.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":106,"type":"SPEC","level":"MUST","comment":"Duplicate suppression MUST\nhappen after removing packet protection for the reasons described in\nSection 9.5 of [QUIC-TLS].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":151,"type":"SPEC","level":"MUST","comment":"The payload of a packet that contains frames MUST contain at least\none frame, and MAY contain multiple frames and multiple frame types.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":158,"type":"SPEC","level":"MUST","comment":"An endpoint MUST treat receipt of a packet containing no frames as a\nconnection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":165,"type":"SPEC","level":"MUST","comment":"An endpoint MUST treat\nreceipt of a frame in a packet type that is not permitted as a\nconnection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":173,"type":"SPEC","level":"MUST","comment":"An endpoint MUST treat the receipt of a frame of unknown type as a\nconnection error of type FRAME_ENCODING_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":180,"type":"SPEC","level":"MUST","comment":"To ensure simple and efficient\nimplementations of frame parsing, a frame type MUST use the shortest\npossible encoding.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":188,"type":"SPEC","level":"MAY","comment":"An endpoint MAY treat the\nreceipt of a frame type that uses a longer encoding than necessary as\na connection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":32,"type":"SPEC","level":"MAY","comment":"* PADDING, PING, and CRYPTO frames MAY appear in any packet number\nspace.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":39,"type":"SPEC","level":"MAY","comment":"* CONNECTION_CLOSE frames signaling errors at the QUIC layer (type\n0x1c) MAY appear in any packet number space.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":46,"type":"SPEC","level":"MUST","comment":"CONNECTION_CLOSE\nframes signaling application errors (type 0x1d) MUST only appear\nin the application data packet number space.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":54,"type":"SPEC","level":"MAY","comment":"* ACK frames MAY appear in any packet number space but can only\nacknowledge packets that appeared in that packet number space.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":61,"type":"SPEC","level":"MUST","comment":"* All other frame types MUST only be sent in the application data\npacket number space.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":68,"type":"SPEC","level":"MAY","comment":"A server MAY treat receipt\nof these frames in 0-RTT packets as a connection error of type\nPROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":20,"type":"SPEC","level":"MUST","comment":"A packet MUST NOT be acknowledged until packet protection has been\nsuccessfully removed and all frames contained in the packet have been\nprocessed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":28,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD treat receipt of an acknowledgment for a packet it\ndid not send as a connection error of type PROTOCOL_VIOLATION, if it\nis able to detect the condition.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":72,"type":"SPEC","level":"MUST","comment":"Every packet SHOULD be acknowledged at least once, and ack-eliciting\npackets MUST be acknowledged at least once within the maximum delay\nan endpoint communicated using the max_ack_delay transport parameter;\nsee Section 18.2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":81,"type":"SPEC","level":"MUST","comment":"An endpoint MUST acknowledge all ack-eliciting Initial and Handshake\npackets immediately and all ack-eliciting 0-RTT and 1-RTT packets\nwithin its advertised max_ack_delay, with the following exception.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":89,"type":"SPEC","level":"MUST","comment":"Since packets containing only ACK frames are not congestion\ncontrolled, an endpoint MUST NOT send more than one such packet in\nresponse to receiving an ack-eliciting packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":97,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send a non-ack-eliciting packet in response to a\nnon-ack-eliciting packet, even if there are packet gaps that precede\nthe received packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":105,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD\nsend an ACK frame with other frames when there are new ack-eliciting\npackets to acknowledge.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":113,"type":"SPEC","level":"MAY","comment":"When only non-ack-eliciting packets need to\nbe acknowledged, an endpoint MAY choose not to send an ACK frame with\noutgoing frames until an ack-eliciting packet has been received.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":121,"type":"SPEC","level":"MUST","comment":"In\nthat case, an endpoint MUST NOT send an ack-eliciting frame in all\npackets that would otherwise be non-ack-eliciting, to avoid an\ninfinite feedback loop of acknowledgments.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":130,"type":"SPEC","level":"SHOULD","comment":"In order to assist loss detection at the sender, an endpoint SHOULD\ngenerate and send an ACK frame without delay when it receives an ack-\neliciting packet either:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":138,"type":"SPEC","level":"SHOULD","comment":"Similarly, packets marked with the ECN Congestion Experienced (CE)\ncodepoint in the IP header SHOULD be acknowledged immediately, to\nreduce the peer's response time to congestion events.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.2","line":32,"type":"SPEC","level":"SHOULD","comment":"A receiver SHOULD send an ACK frame after receiving at least two ack-\neliciting packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.2","line":39,"type":"SPEC","level":"MAY","comment":"A receiver MAY process multiple available packets before determining\nwhether to send an ACK frame in response.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":55,"type":"SPEC","level":"SHOULD","comment":"ACK frames SHOULD always acknowledge the most recently received\npackets, and the more out of order the packets are, the more\nimportant it is to send an updated ACK frame quickly, to prevent the\npeer from declaring a packet as lost and spuriously retransmitting\nthe frames it contains.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":65,"type":"SPEC","level":"SHOULD","comment":"After receiving\nacknowledgments for an ACK frame, the receiver SHOULD stop tracking\nthose acknowledged ACK Ranges.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":73,"type":"SPEC","level":"MAY","comment":"Receivers MAY also limit ACK\nframe size further to preserve space for other frames or to limit the\ncapacity that acknowledgments consume.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":81,"type":"SPEC","level":"MUST","comment":"A receiver MUST retain an ACK Range unless it can ensure that it will\nnot subsequently accept packets with numbers in that range.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":88,"type":"SPEC","level":"MUST","comment":"Receivers can discard all ACK Ranges, but they MUST retain the\nlargest packet number that has been successfully processed, as that\nis used to recover packet numbers from subsequent packets; see\nSection 17.1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":97,"type":"SPEC","level":"SHOULD","comment":"A receiver SHOULD include an ACK Range containing the largest\nreceived packet number in every ACK frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":25,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT include delays that it\ndoes not control when populating the ACK Delay field in an ACK frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":32,"type":"SPEC","level":"SHOULD","comment":"However, endpoints SHOULD include buffering delays caused by\nunavailability of decryption keys, since these delays can be large\nand are likely to be non-repeating.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":40,"type":"SPEC","level":"SHOULD","comment":"When the measured acknowledgment delay is larger than its\nmax_ack_delay, an endpoint SHOULD report the measured delay.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":17,"type":"SPEC","level":"MUST","comment":"ACK frames MUST only be carried in a packet that has the same packet\nnumber space as the packet being acknowledged; see Section 12.1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":24,"type":"SPEC","level":"MUST","comment":"For\ninstance, packets that are protected with 1-RTT keys MUST be\nacknowledged in packets that are also protected with 1-RTT keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":32,"type":"SPEC","level":"MUST","comment":"Packets that a client sends with 0-RTT packet protection MUST be\nacknowledged by the server in packets protected by 1-RTT keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.7","line":13,"type":"SPEC","level":"SHOULD","comment":"To\navoid a deadlock, a sender SHOULD ensure that other frames are sent\nperiodically in addition to PADDING frames to elicit acknowledgments\nfrom the receiver.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2","line":20,"type":"SPEC","level":"SHOULD","comment":"When sending a packet for any reason, an endpoint SHOULD attempt to\ninclude an ACK frame if one has not been sent recently.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":135,"type":"SPEC","level":"MUST","comment":"The content of a RESET_STREAM frame MUST NOT change when it is\nsent again.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":142,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD stop sending\nMAX_STREAM_DATA frames when the receiving part of the stream\nenters a \"Size Known\" or \"Reset Recvd\" state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":150,"type":"SPEC","level":"MUST","comment":"* The HANDSHAKE_DONE frame MUST be retransmitted until it is\nacknowledged.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":157,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD prioritize retransmission of data over sending new\ndata, unless priorities specified by the application indicate\notherwise; see Section 2.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":165,"type":"SPEC","level":"MUST","comment":"A receiver MUST accept packets containing an\noutdated frame, such as a MAX_DATA frame carrying a smaller maximum\ndata value than one found in an older packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":173,"type":"SPEC","level":"SHOULD","comment":"A sender SHOULD avoid retransmitting information from packets once\nthey are acknowledged.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":180,"type":"SPEC","level":"MUST","comment":"Upon detecting losses, a sender MUST take appropriate congestion\ncontrol action.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.1","line":37,"type":"SPEC","level":"MUST","comment":"Even if an endpoint does not set an ECT field in packets it sends,\nthe endpoint MUST provide feedback about ECN markings it receives, if\nthese are accessible.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.1","line":47,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT fail ECN validation as a result of\nprocessing an ACK frame that does not increase the largest\nacknowledged packet number.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":19,"type":"SPEC","level":"MUST","comment":"If validation fails, then the endpoint MUST disable ECN.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":25,"type":"SPEC","level":"MAY","comment":"Even if validation fails, an endpoint MAY revalidate ECN for the same\npath at any later time in the connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":32,"type":"SPEC","level":"MAY","comment":"Upon successful validation, an endpoint MAY continue to set an ECT\ncodepoint in subsequent packets it sends, with the expectation that\nthe path is ECN capable.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":40,"type":"SPEC","level":"MUST","comment":"Network routing and path elements can\nchange mid-connection; an endpoint MUST disable ECN if validation\nlater fails.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2","line":39,"type":"SPEC","level":"MAY","comment":"Implementations MAY use other methods\ndefined in RFCs; see [RFC8311].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13","line":32,"type":"SPEC","level":"MAY","comment":"A sender\nMAY wait for a short period of time to collect multiple frames before\nsending a packet that is not maximally packed, to avoid sending out\nlarge numbers of small packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13","line":41,"type":"SPEC","level":"MAY","comment":"An implementation MAY use knowledge\nabout application sending behavior or heuristics to determine whether\nand for how long to wait.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":33,"type":"SPEC","level":"MUST","comment":"A client MUST expand the payload of all UDP datagrams carrying\nInitial packets to at least the smallest allowed maximum datagram\nsize of 1200 bytes by adding PADDING frames to the Initial packet or\nby coalescing the Initial packet; see Section 12.2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":42,"type":"SPEC","level":"MUST","comment":"Similarly, a server MUST expand the payload of all UDP\ndatagrams carrying ack-eliciting Initial packets to at least the\nsmallest allowed maximum datagram size of 1200 bytes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":50,"type":"SPEC","level":"MAY","comment":"Datagrams containing Initial packets MAY exceed 1200 bytes if the\nsender believes that the network path and peer both support the size\nthat it chooses.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":58,"type":"SPEC","level":"MUST","comment":"A server MUST discard an Initial packet that is carried in a UDP\ndatagram with a payload that is smaller than the smallest allowed\nmaximum datagram size of 1200 bytes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":66,"type":"SPEC","level":"MAY","comment":"A server MAY also immediately\nclose the connection by sending a CONNECTION_CLOSE frame with an\nerror code of PROTOCOL_VIOLATION; see Section 10.2.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":74,"type":"SPEC","level":"MUST","comment":"The server MUST also limit the number of bytes it sends before\nvalidating the address of the client; see Section 8.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":39,"type":"SPEC","level":"MUST","comment":"An endpoint MUST ignore an ICMP message that claims the PMTU has\ndecreased below QUIC's smallest allowed maximum datagram size.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":46,"type":"SPEC","level":"SHOULD","comment":"QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect\nfrom packet injection as specified in [RFC8201] and Section 5.2 of\n[RFC8085].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":54,"type":"SPEC","level":"SHOULD","comment":"This validation SHOULD use the quoted packet supplied in\nthe payload of an ICMP message to associate the message with a\ncorresponding transport connection (see Section 4.6.1 of [DPLPMTUD]).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":62,"type":"SPEC","level":"MUST","comment":"ICMP message validation MUST include matching IP addresses and UDP\nports [RFC8085] and, when possible, connection IDs to an active QUIC\nsession.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":70,"type":"SPEC","level":"SHOULD","comment":"The endpoint SHOULD ignore all ICMP messages that fail\nvalidation.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":77,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT increase the PMTU based on ICMP messages; see\nItem 6 in Section 3 of [DPLPMTUD].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":84,"type":"SPEC","level":"MAY","comment":"Any reduction in QUIC's maximum\ndatagram size in response to ICMP messages MAY be provisional until\nQUIC's loss detection algorithm determines that the quoted packet has\nactually been lost.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":40,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD\n(Section 14.2.1) to determine whether the path to a destination will\nsupport a desired maximum datagram size without fragmentation.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":48,"type":"SPEC","level":"SHOULD","comment":"In\nthe absence of these mechanisms, QUIC endpoints SHOULD NOT send\ndatagrams larger than the smallest allowed maximum datagram size.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":56,"type":"SPEC","level":"SHOULD","comment":"All QUIC\npackets that are not sent in a PMTU probe SHOULD be sized to fit\nwithin the maximum datagram size to avoid the datagram being\nfragmented or dropped [RFC8085].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":65,"type":"SPEC","level":"MUST","comment":"If a QUIC endpoint determines that the PMTU between any pair of local\nand remote IP addresses cannot support the smallest allowed maximum\ndatagram size of 1200 bytes, it MUST immediately cease sending QUIC\npackets, except for those in PMTU probes or those containing\nCONNECTION_CLOSE frames, on the affected path.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":75,"type":"SPEC","level":"MAY","comment":"An endpoint MAY\nterminate the connection if an alternative path cannot be found.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":82,"type":"SPEC","level":"SHOULD","comment":"QUIC implementations that implement any kind of PMTU discovery\ntherefore SHOULD maintain a maximum datagram size for each\ncombination of local and remote IP addresses.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":90,"type":"SPEC","level":"MAY","comment":"A QUIC implementation MAY be more conservative in computing the\nmaximum datagram size to allow for unknown tunnel overheads or IP\nheader options/extensions.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.3","line":19,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of\n[DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum\ndatagram size.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.4","line":16,"type":"SPEC","level":"SHOULD","comment":"Loss of\na QUIC packet that is carried in a PMTU probe is therefore not a\nreliable indication of congestion and SHOULD NOT trigger a congestion\ncontrol reaction; see Item 7 in Section 3 of [DPLPMTUD].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":54,"type":"SPEC","level":"MUST","comment":"QUIC MUST NOT be used if the network path cannot support a\nmaximum datagram size of at least 1200 bytes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":61,"type":"SPEC","level":"MUST","comment":"UDP datagrams MUST NOT be fragmented at the IP layer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":67,"type":"SPEC","level":"MUST","comment":"In IPv4\n[IPv4], the Don't Fragment (DF) bit MUST be set if possible, to\nprevent fragmentation on the path.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":75,"type":"SPEC","level":"MUST","comment":"Therefore, an endpoint MUST NOT close a connection\nwhen it receives a datagram that does not meet size constraints; the\nendpoint MAY discard such datagrams.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-15","line":34,"type":"SPEC","level":"MAY","comment":"A\nclient or server MAY advertise support for any of these reserved\nversions.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-15","line":42,"type":"SPEC","level":"MAY","comment":"Reserved version numbers will never represent a real protocol; a\nclient MAY use one of these version numbers with the expectation that\nthe server will initiate version negotiation; a server MAY advertise\nsupport for one of these versions and can expect that clients ignore\nthe value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.1","line":49,"type":"SPEC","level":"MUST","comment":"Prior to receiving an acknowledgment for a packet number space, the\nfull packet number MUST be included; it is not to be truncated, as\ndescribed below.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.1","line":57,"type":"SPEC","level":"MUST","comment":"After an acknowledgment is received for a packet number space, the\nsender MUST use a packet number size able to represent more than\ntwice as large a range as the difference between the largest\nacknowledged packet number and the packet number being sent.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.1","line":66,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD\nuse a large enough packet number encoding to allow the packet number\nto be recovered even if the packet arrives after packets that are\nsent afterwards.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":70,"type":"SPEC","level":"MUST","comment":"Clients MUST ignore the value of this field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":76,"type":"SPEC","level":"SHOULD","comment":"Where QUIC\nmight be multiplexed with other protocols (see [RFC7983]), servers\nSHOULD set the most significant bit of this field (0x40) to 1 so that\nVersion Negotiation packets appear to have the Fixed Bit field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":85,"type":"SPEC","level":"MUST","comment":"The Version field of a Version Negotiation packet MUST be set to\n0x00000000.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":92,"type":"SPEC","level":"MUST","comment":"The server MUST include the value from the Source Connection ID field\nof the packet it receives in the Destination Connection ID field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":99,"type":"SPEC","level":"MUST","comment":"The value for Source Connection ID MUST be copied from the\nDestination Connection ID of the received packet, which is initially\nrandomly selected by a client.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":107,"type":"SPEC","level":"MUST","comment":"Version-\nspecific rules for the connection ID therefore MUST NOT influence a\ndecision about whether to send a Version Negotiation packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":115,"type":"SPEC","level":"MUST","comment":"A server MUST NOT send more than one Version Negotiation packet in\nresponse to a single UDP datagram.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.2","line":82,"type":"SPEC","level":"MUST","comment":"Initial packets sent by the server MUST set the Token Length field\nto 0; clients that receive an Initial packet with a non-zero Token\nLength field MUST either discard the packet or generate a\nconnection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.2","line":91,"type":"SPEC","level":"MAY","comment":"A server MAY send multiple Initial packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":58,"type":"SPEC","level":"SHOULD","comment":"A client SHOULD attempt\nto resend data in 0-RTT packets after it sends a new Initial packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":65,"type":"SPEC","level":"MUST","comment":"New packet numbers MUST be used for any new packets that are sent; as\ndescribed in Section 17.2.5.3, reusing packet numbers could\ncompromise packet protection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":73,"type":"SPEC","level":"MUST","comment":"A client MUST NOT send 0-RTT packets once it starts processing 1-RTT\npackets from the server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":80,"type":"SPEC","level":"MUST","comment":"An acknowledgment for a 1-RTT\npacket MUST be carried in a 1-RTT packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":87,"type":"SPEC","level":"SHOULD","comment":"A server SHOULD treat a violation of remembered limits\n(Section 7.4.1) as a connection error of an appropriate type (for\ninstance, a FLOW_CONTROL_ERROR for exceeding stream data limits).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.4","line":52,"type":"SPEC","level":"MAY","comment":"Handshake packets MAY contain\nCONNECTION_CLOSE frames of type 0x1c.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.4","line":59,"type":"SPEC","level":"MUST","comment":"Endpoints MUST treat receipt\nof Handshake packets with other frames as a connection error of type\nPROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":24,"type":"SPEC","level":"MUST","comment":"This value MUST NOT be equal to the Destination\nConnection ID field of the packet sent by the client.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":31,"type":"SPEC","level":"MUST","comment":"A client MUST\ndiscard a Retry packet that contains a Source Connection ID field\nthat is identical to the Destination Connection ID field of its\nInitial packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":40,"type":"SPEC","level":"MUST","comment":"The client MUST use the value from the Source\nConnection ID field of the Retry packet in the Destination Connection\nID field of subsequent packets that it sends.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":48,"type":"SPEC","level":"MAY","comment":"A server MAY send Retry packets in response to Initial and 0-RTT\npackets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":55,"type":"SPEC","level":"MUST","comment":"A server MUST NOT send more than one Retry\npacket in response to a single UDP datagram.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":32,"type":"SPEC","level":"MUST","comment":"A client MUST accept and process at most one Retry packet for each\nconnection attempt.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":39,"type":"SPEC","level":"MUST","comment":"After the client has received and processed an\nInitial or Retry packet from the server, it MUST discard any\nsubsequent Retry packets that it receives.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":47,"type":"SPEC","level":"MUST","comment":"Clients MUST discard Retry packets that have a Retry Integrity Tag\nthat cannot be validated; see Section 5.8 of [QUIC-TLS].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":54,"type":"SPEC","level":"MUST","comment":"A client\nMUST discard a Retry packet with a zero-length Retry Token field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":61,"type":"SPEC","level":"MUST","comment":"The\nclient MUST NOT change the Source Connection ID because the server\ncould include the connection ID as part of its token validation\nlogic; see Section 8.1.4.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.3","line":42,"type":"SPEC","level":"MUST","comment":"A client MUST use the same\ncryptographic handshake message it included in this packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.3","line":49,"type":"SPEC","level":"MAY","comment":"A server\nMAY treat a packet that contains a different cryptographic handshake\nmessage as a connection error or discard it.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.3","line":57,"type":"SPEC","level":"MAY","comment":"A client MAY attempt 0-RTT after receiving a Retry packet by sending\n0-RTT packets to the connection ID provided by the server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.3","line":64,"type":"SPEC","level":"MUST","comment":"A client MUST NOT reset the packet number for any packet number space\nafter processing a Retry packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.3","line":71,"type":"SPEC","level":"MAY","comment":"A server MAY abort the connection if it\ndetects that the client reset the packet number.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5","line":37,"type":"SPEC","level":"MUST","comment":"The value in\nthe Unused field is set to an arbitrary value by the server; a client\nMUST ignore these bits.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":137,"type":"SPEC","level":"MUST","comment":"Packets containing a zero\nvalue for this bit are not valid packets in this version and MUST\nbe discarded.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":145,"type":"SPEC","level":"MUST","comment":"In QUIC version 1, this value MUST NOT exceed\n20 bytes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":152,"type":"SPEC","level":"MUST","comment":"Endpoints that receive a version 1 long header with a\nvalue larger than 20 MUST drop the packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":159,"type":"SPEC","level":"SHOULD","comment":"In order to properly\nform a Version Negotiation packet, servers SHOULD be able to read\nlonger connection IDs from other QUIC versions.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":167,"type":"SPEC","level":"MUST","comment":"In QUIC version 1, this value MUST NOT\nexceed 20 bytes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":174,"type":"SPEC","level":"MUST","comment":"Endpoints that receive a version 1 long header\nwith a value larger than 20 MUST drop the packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":181,"type":"SPEC","level":"SHOULD","comment":"In order to\nproperly form a Version Negotiation packet, servers SHOULD be able\nto read longer connection IDs from other QUIC versions.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":189,"type":"SPEC","level":"MUST","comment":"The value\nincluded prior to protection MUST be set to 0.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":196,"type":"SPEC","level":"MUST","comment":"An endpoint MUST\ntreat receipt of a packet that has a non-zero value for these bits\nafter removing both packet and header protection as a connection\nerror of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":78,"type":"SPEC","level":"MUST","comment":"Packets\ncontaining a zero value for this bit are not valid packets in this\nversion and MUST be discarded.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":86,"type":"SPEC","level":"MUST","comment":"The value included prior to\nprotection MUST be set to 0.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":93,"type":"SPEC","level":"MUST","comment":"An endpoint MUST treat receipt of a\npacket that has a non-zero value for these bits, after removing\nboth packet and header protection, as a connection error of type\nPROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":62,"type":"SPEC","level":"MAY","comment":"The spin bit is an OPTIONAL feature of this version of QUIC.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":68,"type":"SPEC","level":"MUST","comment":"An\nendpoint that does not support this feature MUST disable it, as\ndefined below.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":76,"type":"SPEC","level":"MUST","comment":"Implementations MUST allow administrators\nof clients and servers to disable the spin bit either globally or on\na per-connection basis.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":84,"type":"SPEC","level":"MUST","comment":"Even when the spin bit is not disabled by\nthe administrator, endpoints MUST disable their use of the spin bit\nfor a random selection of at least one in every 16 network paths, or\nfor one in every 16 connection IDs, in order to ensure that QUIC\nconnections that disable the spin bit are commonly observed on the\nnetwork.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":95,"type":"SPEC","level":"MUST","comment":"When the spin bit is disabled, endpoints MAY set the spin bit to any\nvalue and MUST ignore any incoming value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":102,"type":"SPEC","level":"SHOULD","comment":"It is RECOMMENDED that\nendpoints set the spin bit to a random value either chosen\nindependently for each packet or chosen independently for each\nconnection ID.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":208,"type":"SPEC","level":"MUST","comment":"This transport parameter MUST NOT be sent\nby a client but MAY be sent by a server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":215,"type":"SPEC","level":"SHOULD","comment":"This value\nSHOULD include the receiver's expected delays in alarms firing.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":222,"type":"SPEC","level":"MUST","comment":"An endpoint that receives this transport\nparameter MUST NOT use a new local address when sending to the\naddress that the peer used during the handshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":230,"type":"SPEC","level":"MAY","comment":"Servers MAY choose to only send a preferred address\nof one address family by sending an all-zero address and port\n(0.0.0.0:0 or [::]:0) for the other family.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":238,"type":"SPEC","level":"MUST","comment":"A server\nthat chooses a zero-length connection ID MUST NOT provide a\npreferred address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":246,"type":"SPEC","level":"MUST","comment":"Similarly, a server MUST NOT include a zero-\nlength connection ID in this transport parameter.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":253,"type":"SPEC","level":"MUST","comment":"A client MUST\ntreat a violation of these requirements as a connection error of\ntype TRANSPORT_PARAMETER_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":261,"type":"SPEC","level":"MUST","comment":"The value of the\nactive_connection_id_limit parameter MUST be at least 2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":268,"type":"SPEC","level":"MUST","comment":"An\nendpoint that receives a value less than 2 MUST close the\nconnection with an error of type TRANSPORT_PARAMETER_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":276,"type":"SPEC","level":"MUST","comment":"A client MUST NOT include any server-only transport parameter:\noriginal_destination_connection_id, preferred_address,\nretry_source_connection_id, or stateless_reset_token.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":284,"type":"SPEC","level":"MUST","comment":"A server MUST\ntreat receipt of any of these transport parameters as a connection\nerror of type TRANSPORT_PARAMETER_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.10.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":48,"type":"SPEC","level":"MUST","comment":"Receiving a MAX_STREAM_DATA frame for a locally\ninitiated stream that has not yet been created MUST be treated as a\nconnection error of type STREAM_STATE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.10.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":56,"type":"SPEC","level":"MUST","comment":"An endpoint that\nreceives a MAX_STREAM_DATA frame for a receive-only stream MUST\nterminate the connection with error STREAM_STATE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.10.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":64,"type":"SPEC","level":"MUST","comment":"The data sent on a stream MUST NOT exceed the largest maximum stream\ndata value advertised by the receiver.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.10.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":71,"type":"SPEC","level":"MUST","comment":"An endpoint MUST terminate a\nconnection with an error of type FLOW_CONTROL_ERROR if it receives\nmore data than the largest maximum stream data that it has sent for\nthe affected stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":47,"type":"SPEC","level":"MUST","comment":"Receipt of a frame that\npermits opening of a stream larger than this limit MUST be treated\nas a connection error of type FRAME_ENCODING_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":55,"type":"SPEC","level":"MUST","comment":"MAX_STREAMS frames that do not increase the stream limit MUST be\nignored.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":62,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT open more streams than permitted by the current\nstream limit set by its peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":69,"type":"SPEC","level":"MUST","comment":"An endpoint MUST terminate a connection\nwith an error of type STREAM_LIMIT_ERROR if a peer opens more streams\nthan was permitted.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.12.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.12","line":24,"type":"SPEC","level":"SHOULD","comment":"A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes\nto send data but is unable to do so due to connection-level flow\ncontrol; see Section 4.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.13.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.13","line":30,"type":"SPEC","level":"SHOULD","comment":"A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it\nwishes to send data but is unable to do so due to stream-level flow\ncontrol.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.13.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.13","line":38,"type":"SPEC","level":"MUST","comment":"An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only\nstream MUST terminate the connection with error STREAM_STATE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.14.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.14","line":34,"type":"SPEC","level":"SHOULD","comment":"A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when\nit wishes to open a stream but is unable to do so due to the maximum\nstream limit set by its peer; see Section 19.11.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.14.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.14","line":42,"type":"SPEC","level":"MUST","comment":"Receipt of a frame that encodes a larger\nstream ID MUST be treated as a connection error of type\nSTREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":83,"type":"SPEC","level":"MUST","comment":"Values less than 1 and greater than 20 are invalid\nand MUST be treated as a connection error of type\nFRAME_ENCODING_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":91,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send this frame if it currently requires that\nits peer send packets with a zero-length Destination Connection ID.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":98,"type":"SPEC","level":"MUST","comment":"An endpoint that is sending packets with a zero-length Destination\nConnection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a\nconnection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":106,"type":"SPEC","level":"MUST","comment":"Receipt\nof the same frame multiple times MUST NOT be treated as a connection\nerror.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":114,"type":"SPEC","level":"MAY","comment":"If an endpoint receives a NEW_CONNECTION_ID frame that repeats a\npreviously issued connection ID with a different Stateless Reset\nToken field value or a different Sequence Number field value, or if a\nsequence number is used for different connection IDs, the endpoint\nMAY treat that receipt as a connection error of type\nPROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":125,"type":"SPEC","level":"MUST","comment":"The value in the Retire Prior To field\nMUST be less than or equal to the value in the Sequence Number field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":132,"type":"SPEC","level":"MUST","comment":"Receiving a value in the Retire Prior To field that is greater than\nthat in the Sequence Number field MUST be treated as a connection\nerror of type FRAME_ENCODING_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":140,"type":"SPEC","level":"MUST","comment":"A receiver\nMUST ignore any Retire Prior To fields that do not increase the\nlargest received Retire Prior To value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":148,"type":"SPEC","level":"MUST","comment":"An endpoint that receives a NEW_CONNECTION_ID frame with a sequence\nnumber smaller than the Retire Prior To field of a previously\nreceived NEW_CONNECTION_ID frame MUST send a corresponding\nRETIRE_CONNECTION_ID frame that retires the newly received connection\nID, unless it has already done so for that sequence number.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.16.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":44,"type":"SPEC","level":"MUST","comment":"Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number\ngreater than any previously sent to the peer MUST be treated as a\nconnection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.16.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":52,"type":"SPEC","level":"MUST","comment":"The sequence number specified in a RETIRE_CONNECTION_ID frame MUST\nNOT refer to the Destination Connection ID field of the packet in\nwhich the frame is contained.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.16.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":60,"type":"SPEC","level":"MAY","comment":"The peer MAY treat this as a\nconnection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.16.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":67,"type":"SPEC","level":"MUST","comment":"An endpoint that provides a zero-\nlength connection ID MUST treat receipt of a RETIRE_CONNECTION_ID\nframe as a connection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.17.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.17","line":29,"type":"SPEC","level":"MUST","comment":"The recipient of this frame MUST generate a PATH_RESPONSE frame\n(Section 19.18) containing the same Data value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.18.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.18","line":23,"type":"SPEC","level":"MAY","comment":"If the content of a PATH_RESPONSE frame does not match the content of\na PATH_CHALLENGE frame previously sent by the endpoint, the endpoint\nMAY generate a connection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.19.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.19","line":59,"type":"SPEC","level":"SHOULD","comment":"This SHOULD be a UTF-8 encoded\nstring [RFC3629], though the frame does not carry information,\nsuch as language tags, that would aid comprehension by any entity\nother than the one that created the text.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.20.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":22,"type":"SPEC","level":"MUST","comment":"Servers MUST\nNOT send a HANDSHAKE_DONE frame before completing the handshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.20.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":29,"type":"SPEC","level":"MUST","comment":"A\nserver MUST treat receipt of a HANDSHAKE_DONE frame as a connection\nerror of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.21.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.21","line":32,"type":"SPEC","level":"MUST","comment":"An extension to QUIC that wishes to use a new type of frame MUST\nfirst ensure that a peer is able to understand the frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.21.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.21","line":39,"type":"SPEC","level":"SHOULD","comment":"Such extensions\nSHOULD define their interaction with previously defined extensions\nmodifying the same protocol components.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.21.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.21","line":47,"type":"SPEC","level":"MUST","comment":"Extension frames MUST be congestion controlled and MUST cause an ACK\nframe to be sent.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3.1","line":64,"type":"SPEC","level":"MUST","comment":"If any computed packet number is negative, an endpoint MUST generate\na connection error of type FRAME_ENCODING_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3","line":77,"type":"SPEC","level":"MUST","comment":"QUIC implementations MUST properly handle both\ntypes, and, if they have enabled ECN for packets they send, they\nSHOULD use the information in the ECN section to manage their\ncongestion state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.4","line":40,"type":"SPEC","level":"MUST","comment":"An endpoint that receives a RESET_STREAM frame for a send-only stream\nMUST terminate the connection with error STREAM_STATE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.5","line":35,"type":"SPEC","level":"MUST","comment":"Receiving a STOP_SENDING frame for a\nlocally initiated stream that has not yet been created MUST be\ntreated as a connection error of type STREAM_STATE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.5","line":43,"type":"SPEC","level":"MUST","comment":"An\nendpoint that receives a STOP_SENDING frame for a receive-only stream\nMUST terminate the connection with error STREAM_STATE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.6","line":49,"type":"SPEC","level":"MUST","comment":"Receipt of a frame that exceeds\nthis limit MUST be treated as a connection error of type\nFRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":39,"type":"SPEC","level":"MUST","comment":"The token MUST NOT be empty.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":45,"type":"SPEC","level":"MUST","comment":"A client MUST treat receipt\nof a NEW_TOKEN frame with an empty Token field as a connection\nerror of type FRAME_ENCODING_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":53,"type":"SPEC","level":"MUST","comment":"Clients MUST NOT send NEW_TOKEN frames.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":59,"type":"SPEC","level":"MUST","comment":"A server MUST treat receipt\nof a NEW_TOKEN frame as a connection error of type\nPROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":70,"type":"SPEC","level":"MUST","comment":"An endpoint MUST terminate the connection with error\nSTREAM_STATE_ERROR if it receives a STREAM frame for a locally\ninitiated stream that has not yet been created, or for a send-only\nstream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":79,"type":"SPEC","level":"MUST","comment":"Receipt of a frame that exceeds this limit\nMUST be treated as a connection error of type FRAME_ENCODING_ERROR or\nFLOW_CONTROL_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.9","line":32,"type":"SPEC","level":"MUST","comment":"The sum of\nthe final sizes on all streams -- including streams in terminal\nstates -- MUST NOT exceed the value advertised by a receiver.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.9","line":40,"type":"SPEC","level":"MUST","comment":"An\nendpoint MUST terminate a connection with an error of type\nFLOW_CONTROL_ERROR if it receives more data than the maximum data\nvalue that it has sent.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":48,"type":"SPEC","level":"MUST","comment":"A QUIC\nendpoint MUST NOT reuse a stream ID within a connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":34,"type":"SPEC","level":"MUST","comment":"Endpoints MUST be able to deliver stream data to an application as an\nordered byte stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":41,"type":"SPEC","level":"MAY","comment":"However, implementations MAY choose to offer the ability to\ndeliver data out of order to a receiving application.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":48,"type":"SPEC","level":"MUST","comment":"The data at a given offset MUST NOT change if it is sent\nmultiple times; an endpoint MAY treat receipt of different data at\nthe same offset within a stream as a connection error of type\nPROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":57,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send data on any stream without ensuring that it\nis within the flow control limits set by its peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.3","line":18,"type":"SPEC","level":"SHOULD","comment":"A QUIC implementation SHOULD provide ways in which an application can\nindicate the relative priority of streams.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.11","line":35,"type":"SPEC","level":"MUST","comment":"To defend\nagainst this style of denial of service, endpoints that share a\nstatic key for stateless resets (see Section 10.3.2) MUST be arranged\nso that packets with a given connection ID always arrive at an\ninstance that has connection state, unless that connection is no\nlonger active.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.11.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.11","line":46,"type":"SPEC","level":"MUST","comment":"More generally, servers MUST NOT generate a stateless reset if a\nconnection with the corresponding connection ID could be active on\nany endpoint using the same static key.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.12.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.12","line":14,"type":"SPEC","level":"MUST","comment":"Future\nversions of QUIC that use Version Negotiation packets MUST define a\nmechanism that is robust against version downgrade attacks.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.3","line":16,"type":"SPEC","level":"SHOULD","comment":"Servers SHOULD provide mitigations for this attack by limiting the\nusage and lifetime of address validation tokens; see Section 8.1.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.4","line":12,"type":"SPEC","level":"MAY","comment":"An endpoint MAY skip packet numbers when sending\npackets to detect this behavior.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.3","line":20,"type":"SPEC","level":"MUST","comment":"A client MUST NOT send non-probing frames to a preferred address\nprior to validating that address; see Section 8.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":53,"type":"SPEC","level":"MAY","comment":"Endpoints MAY prevent connection attempts or\nmigration to a loopback address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":60,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD NOT allow\nconnections or migration to a loopback address if the same service\nwas previously available at a different interface or if the address\nwas provided by a service at a non-loopback address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":69,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD NOT refuse to use\nan address unless they have specific knowledge about the network\nindicating that sending datagrams to unvalidated addresses in a given\nrange is not safe.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":78,"type":"SPEC","level":"MAY","comment":"Endpoints MAY choose to reduce the risk of request forgery by not\nincluding values from NEW_TOKEN frames in Initial packets or by only\nsending probing frames in packets prior to completing address\nvalidation.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":87,"type":"SPEC","level":"MAY","comment":"Endpoints MAY\nchoose to avoid sending datagrams to these ports or not send\ndatagrams that match these patterns prior to validating the\ndestination address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":96,"type":"SPEC","level":"MAY","comment":"Endpoints MAY retire connection IDs containing\npatterns known to be problematic without using them.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5","line":56,"type":"SPEC","level":"SHOULD","comment":"QUIC\nservers SHOULD NOT be deployed in networks that do not deploy ingress\nfiltering [BCP38] and also have inadequately secured UDP endpoints.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5","line":64,"type":"SPEC","level":"MUST","comment":"Any future extension that allows server migration MUST\nalso define countermeasures for forgery attacks.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.6","line":21,"type":"SPEC","level":"SHOULD","comment":"QUIC deployments SHOULD provide mitigations for the Slowloris\nattacks, such as increasing the maximum number of clients the server\nwill allow, limiting the number of connections a single IP address is\nallowed to make, imposing restrictions on the minimum transfer speed\na connection is allowed to have, and restricting the length of time\nan endpoint is allowed to stay connected.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.7","line":28,"type":"SPEC","level":"SHOULD","comment":"QUIC deployments SHOULD provide mitigations for stream fragmentation\nattacks.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.9","line":24,"type":"SPEC","level":"SHOULD","comment":"While there are legitimate uses for all messages, implementations\nSHOULD track cost of processing relative to progress and treat\nexcessive quantities of any non-productive packets as indicative of\nan attack.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.9","line":33,"type":"SPEC","level":"MAY","comment":"Endpoints MAY respond to this condition with a connection\nerror or by dropping packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.1","line":41,"type":"SPEC","level":"MAY","comment":"Provisional registrations MAY omit the Specification and Notes\nfields, plus any additional fields that might be required for a\npermanent registration.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":27,"type":"SPEC","level":"SHOULD","comment":"New requests for codepoints from QUIC registries SHOULD use a\nrandomly selected codepoint that excludes both existing allocations\nand the first unallocated codepoint in the selected space.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":35,"type":"SPEC","level":"MAY","comment":"Requests\nfor multiple codepoints MAY use a contiguous range.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":42,"type":"SPEC","level":"SHOULD","comment":"For codepoints that are encoded in variable-length integers\n(Section 16), such as frame types, codepoints that encode to four or\neight bytes (that is, values 2^14 and above) SHOULD be used unless\nthe usage is especially sensitive to having a longer encoding.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":51,"type":"SPEC","level":"MAY","comment":"Applications to register codepoints in QUIC registries MAY include a\nrequested codepoint as part of the registration.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.2","line":58,"type":"SPEC","level":"MUST","comment":"IANA MUST allocate\nthe selected codepoint if the codepoint is unassigned and the\nrequirements of the registration policy are met.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":36,"type":"SPEC","level":"SHOULD","comment":"This SHOULD be done only for the\ncodepoints with the earliest recorded date, and entries that have\nbeen updated less than a year prior SHOULD NOT be reclaimed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":44,"type":"SPEC","level":"MUST","comment":"A request to remove a codepoint MUST be reviewed by the designated\nexperts.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":51,"type":"SPEC","level":"MUST","comment":"The experts MUST attempt to determine whether the codepoint\nis still in use.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":58,"type":"SPEC","level":"MUST","comment":"If any use of the codepoints is identified by this search or a\nrequest to update the registration is made, the codepoint MUST NOT be\nreclaimed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.3","line":66,"type":"SPEC","level":"MAY","comment":"If no use of the codepoint was identified and no request was made to\nupdate the registration, the codepoint MAY be removed from the\nregistry.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.4","line":30,"type":"SPEC","level":"MAY","comment":"The creation of a registry\nMAY specify additional constraints on permanent registrations.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.4","line":37,"type":"SPEC","level":"MAY","comment":"The creation of a registry MAY identify a range of codepoints where\nregistrations are governed by a different registration policy.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.1.4","line":44,"type":"SPEC","level":"MUST","comment":"All registrations made by Standards Track publications MUST be\npermanent.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.2","line":22,"type":"SPEC","level":"MUST","comment":"All codepoints that follow the pattern 0x?a?a?a?a are reserved, MUST\nNOT be assigned by IANA, and MUST NOT appear in the listing of\nassigned values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.3","line":67,"type":"SPEC","level":"MUST","comment":"In addition to the fields listed in Section 22.1.1, permanent\nregistrations in this registry MUST include the following field:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.3","line":74,"type":"SPEC","level":"MUST","comment":"Each value of the form \"31 * N + 27\" for integer values of N (that\nis, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned\nby IANA and MUST NOT appear in the listing of assigned values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.4","line":33,"type":"SPEC","level":"MUST","comment":"In addition to the fields listed in Section 22.1.1, permanent\nregistrations in this registry MUST include the following field:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.4","line":40,"type":"SPEC","level":"SHOULD","comment":"In addition to the advice in Section 22.1, specifications for new\npermanent registrations SHOULD describe the means by which an\nendpoint might determine that it can send the identified type of\nframe.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.5","line":92,"type":"SPEC","level":"MUST","comment":"In addition to the fields listed in Section 22.1.1, permanent\nregistrations in this registry MUST include the following fields:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-22.5","line":99,"type":"SPEC","level":"MAY","comment":"Description: A brief description of the error code semantics, which\nMAY be a summary if a specification reference is provided.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.1","line":94,"type":"SPEC","level":"MAY","comment":"An endpoint MAY send a RESET_STREAM as the first frame that mentions\na stream; this causes the sending part of that stream to open and\nthen immediately transition to the \"Reset Sent\" state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.2","line":119,"type":"SPEC","level":"MUST","comment":"Before a stream is created, all streams of the same type with lower-\nnumbered stream IDs MUST be created.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.2","line":126,"type":"SPEC","level":"MAY","comment":"An\nimplementation MAY interrupt delivery of stream data, discard any\ndata that was not consumed, and signal the receipt of the\nRESET_STREAM.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":29,"type":"SPEC","level":"MUST","comment":"A sender MUST NOT send any of these frames from a terminal state\n(\"Data Recvd\" or \"Reset Recvd\").\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":36,"type":"SPEC","level":"MUST","comment":"A sender MUST NOT send a STREAM or\nSTREAM_DATA_BLOCKED frame for a stream in the \"Reset Sent\" state or\nany terminal state -- that is, after sending a RESET_STREAM frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":44,"type":"SPEC","level":"MAY","comment":"A receiver MAY send a STOP_SENDING frame in any state where it has\nnot received a RESET_STREAM frame -- that is, states other than\n\"Reset Recvd\" or \"Reset Read\".\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":50,"type":"SPEC","level":"SHOULD","comment":"If the stream is in the \"Recv\" or \"Size Known\" state, the transport\nSHOULD signal this by sending a STOP_SENDING frame to prompt closure\nof the stream in the opposite direction.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":58,"type":"SPEC","level":"MUST","comment":"An endpoint that receives a STOP_SENDING frame\nMUST send a RESET_STREAM frame if the stream is in the \"Ready\" or\n\"Send\" state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":66,"type":"SPEC","level":"MAY","comment":"If the stream is in the \"Data Sent\" state, the\nendpoint MAY defer sending the RESET_STREAM frame until the packets\ncontaining outstanding data are acknowledged or declared lost.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":74,"type":"SPEC","level":"SHOULD","comment":"If\nany outstanding data is declared lost, the endpoint SHOULD send a\nRESET_STREAM frame instead of retransmitting the data.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":82,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD copy the error code from the STOP_SENDING frame to\nthe RESET_STREAM frame it sends, but it can use any application error\ncode.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":90,"type":"SPEC","level":"MAY","comment":"An endpoint that sends a STOP_SENDING frame MAY ignore the\nerror code in any RESET_STREAM frames subsequently received for that\nstream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":98,"type":"SPEC","level":"SHOULD","comment":"STOP_SENDING SHOULD only be sent for a stream that has not been reset\nby the peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":62,"type":"SPEC","level":"MUST","comment":"Senders MUST NOT send data in excess of either limit.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":68,"type":"SPEC","level":"MUST","comment":"A receiver MUST close the connection with an error of type\nFLOW_CONTROL_ERROR if the sender violates the advertised connection\nor stream data limits; see Section 11 for details on error handling.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":76,"type":"SPEC","level":"MUST","comment":"A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do\nnot increase flow control limits.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":83,"type":"SPEC","level":"SHOULD","comment":"A sender SHOULD send a\nSTREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver\nthat it has data to write but is blocked by flow control limits.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":91,"type":"SPEC","level":"SHOULD","comment":"To keep the\nconnection from closing, a sender that is flow control limited SHOULD\nperiodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it\nhas no ack-eliciting packets in flight.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.2","line":42,"type":"SPEC","level":"MAY","comment":"To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or\nMAX_DATA frame multiple times within a round trip or send it early\nenough to allow time for loss of the frame and subsequent recovery.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.2","line":50,"type":"SPEC","level":"MUST","comment":"Therefore, a receiver MUST NOT wait for a\nSTREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a\nMAX_STREAM_DATA or MAX_DATA frame; doing so could result in the\nsender being blocked for the rest of the connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.4","line":19,"type":"SPEC","level":"MUST","comment":"Both endpoints MUST maintain flow control state\nfor the stream in the unterminated direction until that direction\nenters a terminal state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":39,"type":"SPEC","level":"MUST","comment":"The receiver MUST use the final size of the stream to\naccount for all bytes sent on the stream in its connection-level flow\ncontroller.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":47,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send data on a stream at or beyond the final\nsize.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":54,"type":"SPEC","level":"SHOULD","comment":"If a\nRESET_STREAM or STREAM frame is received indicating a change in the\nfinal size for the stream, an endpoint SHOULD respond with an error\nof type FINAL_SIZE_ERROR; see Section 11 for details on error\nhandling.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":64,"type":"SPEC","level":"SHOULD","comment":"A receiver SHOULD treat receipt of data at or beyond the\nfinal size as an error of type FINAL_SIZE_ERROR, even after a stream\nis closed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":45,"type":"SPEC","level":"MUST","comment":"If either is received, the connection MUST be closed\nimmediately with a connection error of type TRANSPORT_PARAMETER_ERROR\nif the offending value was received in a transport parameter or of\ntype FRAME_ENCODING_ERROR if it was received in a frame; see\nSection 10.2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":55,"type":"SPEC","level":"MUST","comment":"Endpoints MUST NOT exceed the limit set by their peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":61,"type":"SPEC","level":"MUST","comment":"An endpoint\nthat receives a frame with a stream ID exceeding the limit it has\nsent MUST treat this as a connection error of type\nSTREAM_LIMIT_ERROR; see Section 11 for details on error handling.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":70,"type":"SPEC","level":"MUST","comment":"MAX_STREAMS frames\nthat do not increase the stream limit MUST be ignored.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":77,"type":"SPEC","level":"SHOULD","comment":"An endpoint that is unable to open a new stream due to the peer's\nlimits SHOULD send a STREAMS_BLOCKED frame (Section 19.14).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":84,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT wait\nto receive this signal before advertising additional credit, since\ndoing so will mean that the peer will be blocked for at least an\nentire round trip, and potentially indefinitely if the peer chooses\nnot to send STREAMS_BLOCKED frames.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4","line":25,"type":"SPEC","level":"SHOULD","comment":"To avoid excessive buffering at multiple layers, QUIC implementations\nSHOULD provide an interface for the cryptographic protocol\nimplementation to communicate its buffering limits.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":69,"type":"SPEC","level":"MUST","comment":"The sequence number on\neach newly issued connection ID MUST increase by 1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":76,"type":"SPEC","level":"MUST","comment":"When an endpoint issues a connection ID, it MUST accept packets that\ncarry this connection ID for the duration of the connection or until\nits peer invalidates the connection ID via a RETIRE_CONNECTION_ID\nframe (Section 19.16).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":85,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD ensure that its peer has a sufficient number of\navailable and unused connection IDs.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":92,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT\nprovide more connection IDs than the peer's limit.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":99,"type":"SPEC","level":"MAY","comment":"An endpoint MAY\nsend connection IDs that temporarily exceed a peer's limit if the\nNEW_CONNECTION_ID frame also requires the retirement of any excess,\nby including a sufficiently large value in the Retire Prior To field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":108,"type":"SPEC","level":"MUST","comment":"After processing a NEW_CONNECTION_ID frame and\nadding and retiring active connection IDs, if the number of active\nconnection IDs exceeds the value advertised in its\nactive_connection_id_limit transport parameter, an endpoint MUST\nclose the connection with an error of type CONNECTION_ID_LIMIT_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":118,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD supply a new connection ID when the peer retires a\nconnection ID.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":125,"type":"SPEC","level":"MAY","comment":"If an endpoint provided fewer connection IDs than the\npeer's active_connection_id_limit, it MAY supply a new connection ID\nwhen it receives a packet with a previously unused connection ID.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":133,"type":"SPEC","level":"MAY","comment":"An\nendpoint MAY limit the total number of connection IDs issued for each\nconnection to avoid the risk of running out of connection IDs; see\nSection 10.3.2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":142,"type":"SPEC","level":"MAY","comment":"An endpoint MAY also limit the issuance of\nconnection IDs to reduce the amount of per-path state it maintains,\nsuch as path validation status, as its peer might interact with it\nover as many paths as there are issued connection IDs.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":151,"type":"SPEC","level":"SHOULD","comment":"An endpoint that initiates migration and requires non-zero-length\nconnection IDs SHOULD ensure that the pool of connection IDs\navailable to its peer allows the peer to use a new connection ID on\nmigration, as the peer will be unable to respond if the pool is\nexhausted.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":57,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD retire connection IDs when\nthey are no longer actively using either the local or destination\naddress for which the connection ID was used.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":65,"type":"SPEC","level":"SHOULD","comment":"The endpoint SHOULD continue to\naccept the previously issued connection IDs until they are retired by\nthe peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":73,"type":"SPEC","level":"MAY","comment":"If the endpoint can no longer process the indicated\nconnection IDs, it MAY close the connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":80,"type":"SPEC","level":"MUST","comment":"Upon receipt of an increased Retire Prior To field, the peer MUST\nstop using the corresponding connection IDs and retire them with\nRETIRE_CONNECTION_ID frames before adding the newly provided\nconnection ID to the set of active connection IDs.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":89,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD limit the number of connection IDs it has retired\nlocally for which RETIRE_CONNECTION_ID frames have not yet been\nacknowledged.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":97,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD allow for sending and tracking a\nnumber of RETIRE_CONNECTION_ID frames of at least twice the value of\nthe active_connection_id_limit transport parameter.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":105,"type":"SPEC","level":"MUST","comment":"An endpoint MUST\nNOT forget a connection ID without retiring it, though it MAY choose\nto treat having connection IDs in need of retirement that exceed this\nlimit as a connection error of type CONNECTION_ID_LIMIT_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":114,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD NOT issue updates of the Retire Prior To field\nbefore receiving RETIRE_CONNECTION_ID frames that retire all\nconnection IDs indicated by the previous Retire Prior To value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1","line":61,"type":"SPEC","level":"MUST","comment":"Connection IDs MUST NOT contain any information that can be used by\nan external observer (that is, one that does not cooperate with the\nissuer) to correlate them with other connection IDs for the same\nconnection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1","line":70,"type":"SPEC","level":"MUST","comment":"As a trivial example, this means the same connection ID\nMUST NOT be issued more than once on the same connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1","line":77,"type":"SPEC","level":"MUST","comment":"An\nendpoint MUST NOT use the same IP address and port for multiple\nconcurrent connections with zero-length connection IDs, unless it is\ncertain that those protocol features are not in use.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.1","line":20,"type":"SPEC","level":"MAY","comment":"The client MAY drop these packets, or it MAY buffer them in\nanticipation of later packets that allow it to compute the key.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.1","line":27,"type":"SPEC","level":"MUST","comment":"If a client receives a packet that uses a different version than it\ninitially selected, it MUST discard that packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":42,"type":"SPEC","level":"SHOULD","comment":"If a server receives a packet that indicates an unsupported version\nand if the packet is large enough to initiate a new connection for\nany supported version, the server SHOULD send a Version Negotiation\npacket as described in Section 6.1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":51,"type":"SPEC","level":"MAY","comment":"A server MAY limit the number of\npackets to which it responds with a Version Negotiation packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":58,"type":"SPEC","level":"MUST","comment":"Servers MUST drop smaller packets that specify unsupported versions.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":64,"type":"SPEC","level":"SHOULD","comment":"Servers SHOULD respond with a Version\nNegotiation packet, provided that the datagram is sufficiently long.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":71,"type":"SPEC","level":"SHOULD","comment":"If a server refuses to accept a new connection, it SHOULD send an\nInitial packet containing a CONNECTION_CLOSE frame with error code\nCONNECTION_REFUSED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":79,"type":"SPEC","level":"MAY","comment":"If the packet is a 0-RTT packet, the server MAY buffer a limited\nnumber of these packets in anticipation of a late-arriving Initial\npacket.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":87,"type":"SPEC","level":"SHOULD","comment":"Clients are not able to send Handshake packets prior to\nreceiving a server response, so servers SHOULD ignore any such\npackets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":95,"type":"SPEC","level":"MUST","comment":"Servers MUST drop incoming packets under all other circumstances.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.3","line":32,"type":"SPEC","level":"SHOULD","comment":"A server in a deployment that does not implement a solution to\nmaintain connection continuity when the client address changes SHOULD\nindicate that migration is not supported by using the\ndisable_active_migration transport parameter.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.3","line":41,"type":"SPEC","level":"MUST","comment":"Server deployments that use this simple form of load balancing MUST\navoid the creation of a stateless reset oracle; see Section 21.11.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2","line":40,"type":"SPEC","level":"MAY","comment":"Invalid packets that lack strong integrity protection, such as\nInitial, Retry, or Version Negotiation, MAY be discarded.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2","line":47,"type":"SPEC","level":"MUST","comment":"An\nendpoint MUST generate a connection error if processing the contents\nof these packets prior to discovering an error, or fully revert any\nchanges made during that processing.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.1","line":23,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send a Version Negotiation packet\nin response to receiving a Version Negotiation packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.1","line":30,"type":"SPEC","level":"MAY","comment":"A server MAY limit the number of Version Negotiation packets it\nsends.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":25,"type":"SPEC","level":"MUST","comment":"A client that supports only this version of QUIC MUST abandon the\ncurrent connection attempt if it receives a Version Negotiation\npacket, with the following two exceptions.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":33,"type":"SPEC","level":"MUST","comment":"A client MUST discard any\nVersion Negotiation packet if it has received and successfully\nprocessed any other packet, including an earlier Version Negotiation\npacket.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":42,"type":"SPEC","level":"MUST","comment":"A client MUST discard a Version Negotiation packet that\nlists the QUIC version selected by the client.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.3","line":17,"type":"SPEC","level":"MAY","comment":"Endpoints MAY add reserved versions to any field where unknown or\nunsupported versions are ignored to test that a peer correctly\nignores the value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.3","line":25,"type":"SPEC","level":"MAY","comment":"Endpoints MAY send packets with a reserved version to test that a\npeer correctly discards the packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6","line":20,"type":"SPEC","level":"SHOULD","comment":"Clients that support\nmultiple QUIC versions SHOULD ensure that the first UDP datagram they\nsend is sized to the largest of the minimum datagram sizes from all\nversions they support, using PADDING frames (Section 19.1) as\nnecessary.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":68,"type":"SPEC","level":"MUST","comment":"This Destination Connection ID MUST be at least 8 bytes in\nlength.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":75,"type":"SPEC","level":"MUST","comment":"Until a packet is received from the server, the client MUST\nuse the same Destination Connection ID value on all packets in this\nconnection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":83,"type":"SPEC","level":"MUST","comment":"Once a\nclient has received a valid Initial packet from the server, it MUST\ndiscard any subsequent packet it receives on that connection with a\ndifferent Source Connection ID.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":92,"type":"SPEC","level":"MUST","comment":"A client MUST change the Destination Connection ID it uses for\nsending packets in response to only the first received Initial or\nRetry packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":100,"type":"SPEC","level":"MUST","comment":"A server MUST set the Destination Connection ID it\nuses for sending packets based on the first received Initial packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":107,"type":"SPEC","level":"MUST","comment":"Any further changes to the Destination Connection ID are only\npermitted if the values are taken from NEW_CONNECTION_ID frames; if\nsubsequent Initial packets include a different Source Connection ID,\nthey MUST be discarded.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":98,"type":"SPEC","level":"MUST","comment":"The values provided by a peer for these transport parameters MUST\nmatch the values that an endpoint used in the Destination and Source\nConnection ID fields of Initial packets that it sent (and received,\nfor servers).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":107,"type":"SPEC","level":"MUST","comment":"Endpoints MUST validate that received transport\nparameters match received connection ID values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":114,"type":"SPEC","level":"MUST","comment":"An endpoint MUST treat the absence of the\ninitial_source_connection_id transport parameter from either endpoint\nor the absence of the original_destination_connection_id transport\nparameter from the server as a connection error of type\nTRANSPORT_PARAMETER_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":124,"type":"SPEC","level":"MUST","comment":"An endpoint MUST treat the following as a connection error of type\nTRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":96,"type":"SPEC","level":"MUST","comment":"The definition of a new transport parameter (Section 7.4.2) MUST\nspecify whether storing the transport parameter for 0-RTT is\nmandatory, optional, or prohibited.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":104,"type":"SPEC","level":"MUST","comment":"A client MUST NOT use remembered values for the following parameters:\nack_delay_exponent, max_ack_delay, initial_source_connection_id,\noriginal_destination_connection_id, preferred_address,\nretry_source_connection_id, and stateless_reset_token.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":113,"type":"SPEC","level":"MUST","comment":"The client\nMUST use the server's new values in the handshake instead; if the\nserver does not provide new values, the default values are used.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":121,"type":"SPEC","level":"MUST","comment":"A client that attempts to send 0-RTT data MUST remember all other\ntransport parameters used by the server that it is able to process.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":128,"type":"SPEC","level":"MUST","comment":"If 0-RTT data is accepted by the server, the server MUST NOT reduce\nany limits or alter any values that might be violated by the client\nwith its 0-RTT data.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":136,"type":"SPEC","level":"MUST","comment":"In particular, a server that accepts 0-RTT data\nMUST NOT set values for the following parameters (Section 18.2) that\nare smaller than the remembered values of the parameters.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":144,"type":"SPEC","level":"SHOULD","comment":"The applicable\nsubset of transport parameters that permit the sending of application\ndata SHOULD be set to non-zero values for 0-RTT.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":152,"type":"SPEC","level":"MAY","comment":"A server MAY store and recover the previously sent values of the\nmax_idle_timeout, max_udp_payload_size, and disable_active_migration\nparameters and reject 0-RTT if it selects smaller values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":160,"type":"SPEC","level":"MUST","comment":"A server MUST reject 0-RTT data if the restored values for transport\nparameters cannot be supported.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":167,"type":"SPEC","level":"MUST","comment":"When sending frames in 0-RTT packets, a client MUST only use\nremembered transport parameters; importantly, it MUST NOT use updated\nvalues that it learns from the server's updated transport parameters\nor from frames received in 1-RTT packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":176,"type":"SPEC","level":"MAY","comment":"A\nserver MAY treat the use of updated transport parameters in 0-RTT as\na connection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.2","line":24,"type":"SPEC","level":"MUST","comment":"An endpoint MUST ignore transport parameters that it does\nnot support.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":46,"type":"SPEC","level":"MUST","comment":"An endpoint MUST treat receipt of a transport parameter with an\ninvalid value as a connection error of type\nTRANSPORT_PARAMETER_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":54,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send a parameter more than once in a given\ntransport parameters extension.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":61,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD treat receipt of\nduplicate transport parameters as a connection error of type\nTRANSPORT_PARAMETER_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":31,"type":"SPEC","level":"MUST","comment":"Implementations MUST support buffering at least 4096 bytes of data\nreceived in out-of-order CRYPTO frames.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":38,"type":"SPEC","level":"MAY","comment":"Endpoints MAY choose to\nallow more data to be buffered during the handshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":45,"type":"SPEC","level":"MUST","comment":"If an endpoint does not expand its buffer, it MUST close\nthe connection with a CRYPTO_BUFFER_EXCEEDED error code.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":52,"type":"SPEC","level":"MAY","comment":"Once the handshake completes, if an endpoint is unable to buffer all\ndata in a CRYPTO frame, it MAY discard that CRYPTO frame and all\nCRYPTO frames received in the future, or it MAY close the connection\nwith a CRYPTO_BUFFER_EXCEEDED error code.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":61,"type":"SPEC","level":"MUST","comment":"Packets containing\ndiscarded CRYPTO frames MUST be acknowledged because the packet has\nbeen received and processed by the transport even though the CRYPTO\nframe was discarded.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":73,"type":"SPEC","level":"MUST","comment":"The cryptographic handshake MUST\nprovide the following properties:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":80,"type":"SPEC","level":"MUST","comment":"Endpoints MUST explicitly negotiate an application protocol.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.1","line":10,"type":"SPEC","level":"MUST","comment":"A token sent in a NEW_TOKEN frame or a Retry packet MUST be\nconstructed in a way that allows the server to identify how it was\nprovided to a client.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.2","line":56,"type":"SPEC","level":"MUST","comment":"This token MUST be repeated by the client in all\nInitial packets it sends for that connection after it receives the\nRetry packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.2","line":64,"type":"SPEC","level":"SHOULD","comment":"Instead, the\nserver SHOULD immediately close (Section 10.2) the connection with an\nINVALID_TOKEN error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":109,"type":"SPEC","level":"MAY","comment":"A server MAY provide clients with an address validation token during\none connection that can be used on a subsequent connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":116,"type":"SPEC","level":"MUST","comment":"The client\nMUST include the token in all Initial packets it sends, unless a\nRetry replaces the token with a newer one.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":124,"type":"SPEC","level":"MUST","comment":"The client MUST NOT use\nthe token provided in a Retry for future connections.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":131,"type":"SPEC","level":"MAY","comment":"Servers MAY\ndiscard any Initial packet that does not carry the expected token.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":138,"type":"SPEC","level":"SHOULD","comment":"Thus, a token SHOULD have an\nexpiration time, which could be either an explicit expiration time or\nan issued timestamp that can be used to dynamically calculate the\nexpiration time.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":147,"type":"SPEC","level":"MUST","comment":"A token issued with NEW_TOKEN MUST NOT include information that would\nallow values to be linked by an observer to the connection on which\nit was issued.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":155,"type":"SPEC","level":"MUST","comment":"A server MUST ensure that every NEW_TOKEN frame it sends\nis unique across all clients, with the exception of those sent to\nrepair losses of previously sent NEW_TOKEN frames.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":163,"type":"SPEC","level":"MAY","comment":"Information that\nallows the server to distinguish between tokens from Retry and\nNEW_TOKEN MAY be accessible to entities other than the server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":171,"type":"SPEC","level":"SHOULD","comment":"When connecting to a server for\nwhich the client retains an applicable and unused token, it SHOULD\ninclude that token in the Token field of its Initial packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":179,"type":"SPEC","level":"MUST","comment":"A client MUST NOT include\na token that is not applicable to the server that it is connecting\nto, unless the client has the knowledge that the server that issued\nthe token and the server the client is connecting to are jointly\nmanaging the tokens.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":189,"type":"SPEC","level":"MAY","comment":"A client MAY use a token from any previous\nconnection to that server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":196,"type":"SPEC","level":"MUST","comment":"In comparison, a\ntoken obtained in a Retry packet MUST be used immediately during the\nconnection attempt and cannot be used in subsequent connection\nattempts.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":205,"type":"SPEC","level":"SHOULD","comment":"A client SHOULD NOT reuse a token from a NEW_TOKEN frame for\ndifferent connection attempts.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":212,"type":"SPEC","level":"MUST","comment":"When a server receives an Initial packet with an address validation\ntoken, it MUST attempt to validate the token, unless it has already\ncompleted address validation.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":220,"type":"SPEC","level":"SHOULD","comment":"If the token is invalid, then the\nserver SHOULD proceed as if the client did not have a validated\naddress, including potentially sending a Retry packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":228,"type":"SPEC","level":"SHOULD","comment":"If the validation succeeds, the server SHOULD then allow\nthe handshake to proceed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":235,"type":"SPEC","level":"MAY","comment":"Clients MAY use tokens obtained on one connection for any connection\nattempt using the same version.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":45,"type":"SPEC","level":"MUST","comment":"An address validation token MUST be difficult to guess.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":51,"type":"SPEC","level":"MUST","comment":"For this design to work,\nthe token MUST be covered by integrity protection against\nmodification or falsification by clients.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":59,"type":"SPEC","level":"SHOULD","comment":"Tokens\nsent in Retry packets SHOULD include information that allows the\nserver to verify that the source IP address and port in client\npackets remain constant.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":68,"type":"SPEC","level":"MUST","comment":"Tokens sent in NEW_TOKEN frames MUST include information that allows\nthe server to verify that the client IP address has not changed from\nwhen the token was issued.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":76,"type":"SPEC","level":"MUST","comment":"If the client IP address has changed, the\nserver MUST adhere to the anti-amplification limit; see Section 8.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":83,"type":"SPEC","level":"MUST","comment":"To protect against such attacks, servers MUST ensure that\nreplay of tokens is prevented or limited.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":90,"type":"SPEC","level":"SHOULD","comment":"Servers SHOULD ensure that\ntokens sent in Retry packets are only accepted for a short time, as\nthey are returned immediately by clients.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":98,"type":"SPEC","level":"SHOULD","comment":"Tokens that are provided\nin NEW_TOKEN frames (Section 19.7) need to be valid for longer but\nSHOULD NOT be accepted multiple times.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":106,"type":"SPEC","level":"MAY","comment":"Servers are encouraged to\nallow tokens to be used only once, if possible; tokens MAY include\nadditional information about clients to further narrow applicability\nor reuse.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":64,"type":"SPEC","level":"MAY","comment":"Additionally, an endpoint MAY consider the peer address validated if\nthe peer uses a connection ID chosen by the endpoint and the\nconnection ID contains at least 64 bits of entropy.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":72,"type":"SPEC","level":"MUST","comment":"Prior to validating the client address, servers MUST NOT send more\nthan three times as many bytes as the number of bytes they have\nreceived.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":80,"type":"SPEC","level":"MUST","comment":"For the purposes of\navoiding amplification prior to address validation, servers MUST\ncount all of the payload bytes received in datagrams that are\nuniquely attributed to a single connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":89,"type":"SPEC","level":"MUST","comment":"Clients MUST ensure that UDP datagrams containing Initial packets\nhave UDP payloads of at least 1200 bytes, adding PADDING frames as\nnecessary.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":97,"type":"SPEC","level":"MUST","comment":"To\nprevent this deadlock, clients MUST send a packet on a Probe Timeout\n(PTO); see Section 6.2 of [QUIC-RECOVERY].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":105,"type":"SPEC","level":"MUST","comment":"Specifically, the client\nMUST send an Initial packet in a UDP datagram that contains at least\n1200 bytes if it does not have Handshake keys, and otherwise send a\nHandshake packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":42,"type":"SPEC","level":"MAY","comment":"An endpoint MAY send multiple PATH_CHALLENGE frames to guard against\npacket loss.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":49,"type":"SPEC","level":"SHOULD","comment":"However, an endpoint SHOULD NOT send multiple\nPATH_CHALLENGE frames in a single packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":56,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD NOT probe a new path with packets containing a\nPATH_CHALLENGE frame more frequently than it would send an Initial\npacket.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":64,"type":"SPEC","level":"MUST","comment":"The endpoint MUST use unpredictable data in every PATH_CHALLENGE\nframe so that it can associate the peer's response with the\ncorresponding PATH_CHALLENGE.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":72,"type":"SPEC","level":"MUST","comment":"An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame\nto at least the smallest allowed maximum datagram size of 1200 bytes,\nunless the anti-amplification limit for the path does not permit\nsending a datagram of this size.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":81,"type":"SPEC","level":"MUST","comment":"To ensure that the path MTU is large enough, the endpoint\nMUST perform a second path validation by sending a PATH_CHALLENGE\nframe in a datagram of at least 1200 bytes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":89,"type":"SPEC","level":"MUST","comment":"Unlike other cases where datagrams are expanded, endpoints MUST NOT\ndiscard datagrams that appear to be too small when they contain\nPATH_CHALLENGE or PATH_RESPONSE.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":31,"type":"SPEC","level":"MUST","comment":"On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by\nechoing the data contained in the PATH_CHALLENGE frame in a\nPATH_RESPONSE frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":39,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT delay transmission of a\npacket containing a PATH_RESPONSE frame unless constrained by\ncongestion control.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":47,"type":"SPEC","level":"MUST","comment":"A PATH_RESPONSE frame MUST be sent on the network path where the\nPATH_CHALLENGE frame was received.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":54,"type":"SPEC","level":"MUST","comment":"This requirement MUST NOT be enforced by the endpoint that initiates\npath validation, as that would enable an attack on migration; see\nSection 9.3.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":62,"type":"SPEC","level":"MUST","comment":"An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame\nto at least the smallest allowed maximum datagram size of 1200 bytes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":69,"type":"SPEC","level":"MUST","comment":"However, an endpoint MUST NOT expand the\ndatagram containing the PATH_RESPONSE if the resulting data exceeds\nthe anti-amplification limit.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":77,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send more than one PATH_RESPONSE frame in\nresponse to one PATH_CHALLENGE frame; see Section 13.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.3","line":22,"type":"SPEC","level":"MUST","comment":"However, the endpoint MUST initiate\nanother path validation with an expanded datagram to verify that the\npath supports the required MTU.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.4","line":37,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD abandon path validation based on a timer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.4","line":43,"type":"SPEC","level":"SHOULD","comment":"A value of\nthree times the larger of the current PTO or the PTO for the new path\n(using kInitialRtt, as defined in [QUIC-RECOVERY]) is RECOMMENDED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.4","line":51,"type":"SPEC","level":"MAY","comment":"An endpoint\nthat has no valid network path to its peer MAY signal this using the\nNO_VIABLE_PATH connection error, noting that this is only possible if\nthe network path exists but does not support the required MTU\n(Section 14).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2","line":55,"type":"SPEC","level":"MAY","comment":"An endpoint MAY include other frames with the PATH_CHALLENGE and\nPATH_RESPONSE frames used for path validation.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8","line":23,"type":"SPEC","level":"MUST","comment":"Therefore, after receiving packets from an address that is\nnot yet validated, an endpoint MUST limit the amount of data it sends\nto the unvalidated address to three times the amount of data received\nfrom that address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.1","line":17,"type":"SPEC","level":"MAY","comment":"An endpoint MAY probe for peer reachability from a new local address\nusing path validation (Section 8.2) prior to migrating the connection\nto the new local address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.2","line":26,"type":"SPEC","level":"MAY","comment":"An endpoint MAY defer path\nvalidation until after a peer sends the next non-probing frame to its\nnew address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.2","line":30,"type":"SPEC","level":"MUST","comment":"To protect the connection from failing due to such a spurious\nmigration, an endpoint MUST revert to using the last validated peer\naddress when validation of a new peer address fails.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.2","line":38,"type":"SPEC","level":"MUST","comment":"If an endpoint has no state about the last validated peer address, it\nMUST close the connection silently by discarding all connection\nstate.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.2","line":46,"type":"SPEC","level":"MAY","comment":"For instance, an endpoint MAY send a Stateless Reset in\nresponse to any further incoming packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.3","line":50,"type":"SPEC","level":"MUST","comment":"In response to an apparent migration, endpoints MUST validate the\npreviously active path using a PATH_CHALLENGE frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.3","line":57,"type":"SPEC","level":"SHOULD","comment":"An endpoint that receives a PATH_CHALLENGE on an active path SHOULD\nsend a non-probing packet in response.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":38,"type":"SPEC","level":"MUST","comment":"If the recipient permits the migration, it MUST send subsequent\npackets to the new peer address and MUST initiate path validation\n(Section 8.2) to verify the peer's ownership of the address if\nvalidation is not already underway.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":47,"type":"SPEC","level":"MUST","comment":"An endpoint MAY send data to an unvalidated peer address, but it MUST\nprotect against potential attacks as described in Sections 9.3.1 and\n9.3.2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":55,"type":"SPEC","level":"MAY","comment":"An endpoint MAY skip validation of a peer address if that\naddress has been seen recently.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":62,"type":"SPEC","level":"SHOULD","comment":"After verifying a new client address, the server SHOULD send new\naddress validation tokens (Section 8) to the client.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":46,"type":"SPEC","level":"MUST","comment":"Packets sent on the old path MUST NOT contribute to\ncongestion control or RTT estimation for the new path.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":53,"type":"SPEC","level":"MUST","comment":"On confirming a peer's ownership of its new address, an endpoint MUST\nimmediately reset the congestion controller and round-trip time\nestimator for the new path to initial values (see Appendices A.3 and\nB.3 of [QUIC-RECOVERY]) unless the only change in the peer's address\nis its port number.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":63,"type":"SPEC","level":"MAY","comment":"Because port-only changes are commonly the\nresult of NAT rebinding or other middlebox activity, the endpoint MAY\ninstead retain its congestion control state and round-trip estimate\nin those cases instead of reverting to initial values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":72,"type":"SPEC","level":"MUST","comment":"This timer SHOULD be set as described in Section 6.2.1 of\n[QUIC-RECOVERY] and MUST NOT be more aggressive.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":75,"type":"SPEC","level":"MAY","comment":"At any time, endpoints MAY change the Destination Connection ID they\ntransmit with to a value that has not been used on another path.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":82,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT reuse a connection ID when sending from more\nthan one local address -- for example, when initiating connection\nmigration as described in Section 9.2 or when probing a new network\npath as described in Section 9.1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":91,"type":"SPEC","level":"MUST","comment":"Similarly, an endpoint MUST NOT reuse a connection ID when sending to\nmore than one destination address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":98,"type":"SPEC","level":"MAY","comment":"Due to network changes outside\nthe control of its peer, an endpoint might receive packets from a new\nsource address with the same Destination Connection ID field value,\nin which case it MAY continue to use the current connection ID with\nthe new remote address while still sending from the same local\naddress.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":109,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD NOT initiate migration with a peer that has\nrequested a zero-length connection ID, because traffic over the new\npath might be trivially linkable to traffic over the old one.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":117,"type":"SPEC","level":"SHOULD","comment":"Changing address\ncan cause a peer to reset its congestion control state (see\nSection 9.4), so addresses SHOULD only be changed infrequently.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":125,"type":"SPEC","level":"SHOULD","comment":"To ensure that migration is possible and\npackets sent on different paths cannot be correlated, endpoints\nSHOULD provide new connection IDs before peers migrate; see\nSection 5.1.1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":24,"type":"SPEC","level":"MAY","comment":"Servers MAY communicate a preferred address of each address family\n(IPv4 and IPv6) to allow clients to pick the one most suited to their\nnetwork attachment.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":32,"type":"SPEC","level":"SHOULD","comment":"Once the handshake is confirmed, the client SHOULD select one of the\ntwo addresses provided by the server and initiate path validation\n(see Section 8.2).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":40,"type":"SPEC","level":"SHOULD","comment":"As soon as path validation succeeds, the client SHOULD begin sending\nall future packets to the new server address using the new connection\nID and discontinue use of the old server address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":48,"type":"SPEC","level":"MUST","comment":"If path validation\nfails, the client MUST continue sending all future packets to the\nserver's original IP address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":33,"type":"SPEC","level":"MUST","comment":"A client that migrates to a preferred address MUST validate the\naddress it chooses before migrating; see Section 21.5.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":40,"type":"SPEC","level":"MUST","comment":"The server MUST send non-\nprobing packets from its original address until it receives a non-\nprobing packet from the client at its preferred address and until the\nserver has validated the new path.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":49,"type":"SPEC","level":"MUST","comment":"The server MUST probe on the path toward the client from its\npreferred address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":56,"type":"SPEC","level":"SHOULD","comment":"The server SHOULD drop\nnewer packets for this connection that are received on the old IP\naddress.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":64,"type":"SPEC","level":"MAY","comment":"The server MAY continue to process delayed packets that are\nreceived on the old IP address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":71,"type":"SPEC","level":"MUST","comment":"A client MUST NOT use these for other connections,\nincluding connections that are resumed from the current connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":38,"type":"SPEC","level":"SHOULD","comment":"In this case, the client\nSHOULD perform path validation to both the original and preferred\nserver address from the client's new address concurrently.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":46,"type":"SPEC","level":"MUST","comment":"If path validation of the server's preferred address succeeds, the\nclient MUST abandon validation of the original address and migrate to\nusing the server's preferred address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":54,"type":"SPEC","level":"MAY","comment":"If path validation of the\nserver's preferred address fails but validation of the server's\noriginal address succeeds, the client MAY migrate to its new address\nand continue sending to the server's original address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":63,"type":"SPEC","level":"MUST","comment":"If packets received at the server's preferred address have a\ndifferent source address than observed from the client during the\nhandshake, the server MUST protect against potential attacks as\ndescribed in Sections 9.3.1 and 9.3.2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":72,"type":"SPEC","level":"SHOULD","comment":"Servers SHOULD initiate path validation to the client's new address\nupon receiving a probe packet from a different address; see\nSection 8.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":80,"type":"SPEC","level":"SHOULD","comment":"A client that migrates to a new address SHOULD use a preferred\naddress from the same address family for the server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":87,"type":"SPEC","level":"MAY","comment":"This\nconnection ID is provided to ensure that the client has a connection\nID available for migration, but the client MAY use this connection ID\non any path.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6","line":19,"type":"SPEC","level":"SHOULD","comment":"If a\nclient receives packets from a new server address when the client has\nnot initiated a migration to that address, the client SHOULD discard\nthese packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.7","line":21,"type":"SPEC","level":"SHOULD","comment":"Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label\nin compliance with [RFC6437], unless the local API does not allow\nsetting IPv6 flow labels.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.7","line":29,"type":"SPEC","level":"MUST","comment":"The flow label generation MUST be designed to minimize the chances of\nlinkability with a previously used flow label, as a stable flow label\nwould enable correlating activity on multiple paths; see Section 9.5.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":47,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT initiate\nconnection migration before the handshake is confirmed, as defined in\nSection 4.1.2 of [QUIC-TLS].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":55,"type":"SPEC","level":"MUST","comment":"If the peer sent the disable_active_migration transport parameter, an\nendpoint also MUST NOT send packets (including probing packets; see\nSection 9.1) from a different local address to the address the peer\nused during the handshake, unless the endpoint has acted on a\npreferred_address transport parameter from the peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":65,"type":"SPEC","level":"MUST","comment":"If the peer\nviolates this requirement, the endpoint MUST either drop the incoming\npackets on that path without generating a Stateless Reset or proceed\nwith path validation and allow the peer to migrate.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":74,"type":"SPEC","level":"MUST","comment":"An endpoint MUST\nperform path validation (Section 8.2) if it detects any change to a\npeer's address, unless it has previously validated that address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":82,"type":"SPEC","level":"MAY","comment":"When an endpoint has no validated path on which to send packets, it\nMAY discard connection state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":89,"type":"SPEC","level":"MAY","comment":"An endpoint capable of connection\nmigration MAY wait for a new path to become available before\ndiscarding connection state.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":97,"type":"SPEC","level":"MUST","comment":"If a client receives\npackets from an unknown server address, the client MUST discard these\npackets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.2","line":18,"type":"SPEC","level":"MUST","comment":"The server MUST send a\nHANDSHAKE_DONE frame as soon as the handshake is complete.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.2","line":25,"type":"SPEC","level":"MAY","comment":"Additionally, a client MAY consider the handshake to be confirmed\nwhen it receives an acknowledgment for a 1-RTT packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.3","line":99,"type":"SPEC","level":"MUST","comment":"* If the packet is from a previously installed encryption level, it\nMUST NOT contain data that extends past the end of previously\nreceived data in that flow.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.3","line":107,"type":"SPEC","level":"MUST","comment":"Implementations MUST treat any\nviolations of this requirement as a connection error of type\nPROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.3","line":115,"type":"SPEC","level":"MUST","comment":"When TLS\nprovides keys for a higher encryption level, if there is data from\na previous encryption level that TLS has not consumed, this MUST\nbe treated as a connection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.4","line":69,"type":"SPEC","level":"SHOULD","comment":"While waiting for TLS processing to\ncomplete, an endpoint SHOULD buffer received packets if they might be\nprocessed using keys that are not yet available.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.4","line":77,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD\ncontinue to respond to packets that can be processed during this\ntime.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.2","line":18,"type":"SPEC","level":"MUST","comment":"Clients MUST NOT offer TLS versions older than 1.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.2","line":24,"type":"SPEC","level":"MUST","comment":"An endpoint MUST terminate the connection if a\nversion of TLS older than 1.3 is negotiated.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.3","line":45,"type":"SPEC","level":"MAY","comment":"To\navoid this, servers MAY use the Retry feature (see Section 8.1 of\n[QUIC-TRANSPORT]) to only buffer partial ClientHello messages from\nclients with a validated address.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":39,"type":"SPEC","level":"MUST","comment":"A client MUST authenticate the identity of the server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":45,"type":"SPEC","level":"MAY","comment":"A server MAY request that the client authenticate during the\nhandshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":52,"type":"SPEC","level":"MAY","comment":"A server MAY refuse a connection if the client is unable\nto authenticate when requested.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":59,"type":"SPEC","level":"MUST","comment":"A server MUST NOT use post-handshake client authentication (as\ndefined in Section 4.6.2 of [TLS13]) because the multiplexing offered\nby QUIC prevents clients from correlating the certificate request\nwith the application-level event that triggered it (see\n[HTTP2-TLS13]).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":69,"type":"SPEC","level":"MUST","comment":"More specifically, servers MUST NOT send post-\nhandshake TLS CertificateRequest messages, and clients MUST treat\nreceipt of such messages as a connection error of type\nPROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.5","line":30,"type":"SPEC","level":"SHOULD","comment":"Clients SHOULD NOT reuse tickets as\nthat allows entities other than the server to correlate connections;\nsee Appendix C.4 of [TLS13].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.1","line":32,"type":"SPEC","level":"MUST","comment":"Servers MUST NOT send the early_data extension with a\nmax_early_data_size field set to any value other than 0xffffffff.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.1","line":39,"type":"SPEC","level":"MUST","comment":"A\nclient MUST treat receipt of a NewSessionTicket that contains an\nearly_data extension with any other value as a connection error of\ntype PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.2","line":26,"type":"SPEC","level":"MUST","comment":"When rejecting 0-RTT, a server MUST NOT\nprocess any 0-RTT packets, even if it could.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.2","line":33,"type":"SPEC","level":"SHOULD","comment":"When 0-RTT was\nrejected, a client SHOULD treat receipt of an acknowledgment for a\n0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it\nis able to detect the condition.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.2","line":42,"type":"SPEC","level":"MUST","comment":"The client therefore MUST reset the state of all\nstreams, including application state bound to those streams.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.2","line":49,"type":"SPEC","level":"MAY","comment":"A client MAY reattempt 0-RTT if it receives a Retry or Version\nNegotiation packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.7","line":14,"type":"SPEC","level":"SHOULD","comment":"Although it is in principle possible to use this feature\nfor address verification, QUIC implementations SHOULD instead use the\nRetry feature; see Section 8.1 of [QUIC-TRANSPORT].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.8","line":27,"type":"SPEC","level":"MUST","comment":"As QUIC provides\nalternative mechanisms for connection termination and the TLS\nconnection is only closed if an error is encountered, a QUIC endpoint\nMUST treat any alert from TLS as if it were at the \"fatal\" level.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.8","line":36,"type":"SPEC","level":"MAY","comment":"Endpoints MAY use a generic\nerror code to avoid possibly exposing confidential information.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.1","line":22,"type":"SPEC","level":"MUST","comment":"Thus, a client MUST discard Initial keys when it first sends a\nHandshake packet and a server MUST discard Initial keys when it first\nsuccessfully processes a Handshake packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.1","line":30,"type":"SPEC","level":"MUST","comment":"Endpoints MUST NOT send\nInitial packets after this point.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.2","line":8,"type":"SPEC","level":"MUST","comment":"An endpoint MUST discard its Handshake keys when the TLS handshake is\nconfirmed (Section 4.1.2).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":23,"type":"SPEC","level":"SHOULD","comment":"Therefore, a client SHOULD discard 0-RTT keys as soon as it installs\n1-RTT keys as they have no use after that moment.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":30,"type":"SPEC","level":"MAY","comment":"Additionally, a server MAY discard 0-RTT keys as soon as it receives\na 1-RTT packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":37,"type":"SPEC","level":"MAY","comment":"Servers MAY temporarily retain\n0-RTT keys to allow decrypting reordered packets without requiring\ntheir contents to be retransmitted with 1-RTT keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":45,"type":"SPEC","level":"MUST","comment":"After receiving\na 1-RTT packet, servers MUST discard 0-RTT keys within a short time;\nthe RECOMMENDED time period is three times the Probe Timeout (PTO,\nsee [QUIC-RECOVERY]).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":54,"type":"SPEC","level":"MAY","comment":"A server MAY discard 0-RTT keys earlier if it\ndetermines that it has received all 0-RTT packets, which can be done\nby keeping track of missing packet numbers.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9","line":33,"type":"SPEC","level":"MUST","comment":"If packets from a lower encryption level contain\nCRYPTO frames, frames that retransmit that data MUST be sent at the\nsame encryption level.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9","line":41,"type":"SPEC","level":"MUST","comment":"Though an endpoint might retain older keys, new data MUST be sent at\nthe highest currently available encryption level.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9","line":48,"type":"SPEC","level":"MAY","comment":"These packets MAY also include PADDING frames.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4","line":47,"type":"SPEC","level":"MUST","comment":"If QUIC needs to retransmit that data, it MUST use\nthe same keys even if TLS has already updated to newer keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4","line":54,"type":"SPEC","level":"SHOULD","comment":"When packets of different types need to be sent,\nendpoints SHOULD use coalesced packets to send them in the same UDP\ndatagram.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.1","line":43,"type":"SPEC","level":"MUST","comment":"Other versions of TLS MUST provide a similar function in order to be\nused with QUIC.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.2","line":66,"type":"SPEC","level":"SHOULD","comment":"Future versions of QUIC SHOULD generate a new salt value, thus\nensuring that the keys are different for each version of QUIC.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.2","line":73,"type":"SPEC","level":"MUST","comment":"The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for\nInitial packets even where the TLS versions offered do not include\nTLS 1.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.3","line":51,"type":"SPEC","level":"MUST","comment":"A cipher suite MUST NOT be\nnegotiated unless a header protection scheme is defined for the\ncipher suite.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.3","line":59,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT reject a ClientHello that offers a cipher suite\nthat it does not support, or it would be impossible to deploy a new\ncipher suite.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.3","line":67,"type":"SPEC","level":"MUST","comment":"An endpoint MUST initiate a key update\n(Section 6) prior to exceeding any limit set for the AEAD that is in\nuse.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.4.1","line":89,"type":"SPEC","level":"MUST","comment":"Before a TLS cipher suite can be used with QUIC, a header protection\nalgorithm MUST be specified for the AEAD used with that cipher suite.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.4.2","line":59,"type":"SPEC","level":"MUST","comment":"An endpoint MUST discard packets that are not long enough to contain\na complete sample.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.5","line":18,"type":"SPEC","level":"MUST","comment":"Once an endpoint successfully receives a packet with a given packet\nnumber, it MUST discard all packets in the same packet number space\nwith higher packet numbers if they cannot be successfully unprotected\nwith either the same key, or -- if there is a key update -- a\nsubsequent packet protection key; see Section 6.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.5","line":28,"type":"SPEC","level":"MUST","comment":"Similarly, a packet\nthat appears to trigger a key update but cannot be unprotected\nsuccessfully MUST be discarded.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":58,"type":"SPEC","level":"MUST","comment":"A client\ntherefore MUST NOT use 0-RTT for application data unless specifically\nrequested by the application that is in use.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":66,"type":"SPEC","level":"MUST","comment":"An application protocol that uses QUIC MUST include a profile that\ndefines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to\ncarry QUIC frames that do not carry application data.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":74,"type":"SPEC","level":"MAY","comment":"A client MAY wish to apply additional restrictions on what data it\nsends prior to the completion of the TLS handshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":81,"type":"SPEC","level":"SHOULD","comment":"A client SHOULD stop sending 0-RTT data\nif it receives an indication that 0-RTT data has been rejected.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":88,"type":"SPEC","level":"MUST","comment":"A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT\nkeys to protect acknowledgments of 0-RTT packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":95,"type":"SPEC","level":"MUST","comment":"A client MUST NOT\nattempt to decrypt 0-RTT packets it receives and instead MUST discard\nthem.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":103,"type":"SPEC","level":"MUST","comment":"Once a client has installed 1-RTT keys, it MUST NOT send any more\n0-RTT packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":58,"type":"SPEC","level":"MUST","comment":"Endpoints in either role MUST NOT decrypt 1-RTT packets from\ntheir peer prior to completing the handshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":65,"type":"SPEC","level":"MUST","comment":"A server MUST NOT process\nincoming 1-RTT protected packets before the TLS handshake is\ncomplete.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":73,"type":"SPEC","level":"MAY","comment":"Received\npackets protected with 1-RTT keys MAY be stored and later decrypted\nand used once the handshake is complete.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":81,"type":"SPEC","level":"MAY","comment":"The server MAY retain these packets for\nlater decryption in anticipation of receiving a ClientHello.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":88,"type":"SPEC","level":"MUST","comment":"Even if it has 1-RTT secrets, a client MUST NOT\nprocess incoming 1-RTT protected packets before the TLS handshake is\ncomplete.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.1","line":49,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT initiate a key update prior to having confirmed\nthe handshake (Section 4.1.2).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.1","line":56,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT initiate a\nsubsequent key update unless it has received an acknowledgment for a\npacket that was sent protected with keys from the current key phase.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.1","line":64,"type":"SPEC","level":"MUST","comment":"An endpoint MUST retain old keys until it has successfully\nunprotected a packet sent using the new keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.1","line":71,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD\nretain old keys for some time after unprotecting a packet sent using\nthe new keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":41,"type":"SPEC","level":"MUST","comment":"The endpoint MUST update its\nsend keys to the corresponding key phase in response, as described in\nSection 6.1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":49,"type":"SPEC","level":"MUST","comment":"Sending keys MUST be updated before sending an\nacknowledgment for the packet that was received with updated keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":56,"type":"SPEC","level":"MAY","comment":"An endpoint\nMAY treat such consecutive key updates as a connection error of type\nKEY_UPDATE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":64,"type":"SPEC","level":"MAY","comment":"An endpoint that receives an acknowledgment that is carried in a\npacket protected with old keys where any acknowledged packet was\nprotected with newer keys MAY treat that as a connection error of\ntype KEY_UPDATE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":37,"type":"SPEC","level":"MUST","comment":"Endpoints responding to an apparent key update MUST NOT generate a\ntiming side-channel signal that might indicate that the Key Phase bit\nwas invalid (see Section 9.5).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":45,"type":"SPEC","level":"MAY","comment":"An endpoint MAY\ngenerate new keys as part of packet processing, but this creates a\ntiming signal that could be used by an attacker to learn when key\nupdates happen and thus leak the value of the Key Phase bit.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":54,"type":"SPEC","level":"MAY","comment":"For a short period after a key\nupdate completes, up to the PTO, endpoints MAY defer generation of\nthe next set of receive packet protection keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":62,"type":"SPEC","level":"SHOULD","comment":"Once generated, the next set of packet protection keys SHOULD be\nretained, even if the packet that was received was subsequently\ndiscarded.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":70,"type":"SPEC","level":"MUST","comment":"For this reason, endpoints MUST be able to retain two sets of packet\nprotection keys for receiving packets: the current and the next.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.4","line":15,"type":"SPEC","level":"MUST","comment":"Packets with higher packet numbers MUST be protected with either the\nsame or newer packet protection keys than packets with lower packet\nnumbers.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.4","line":23,"type":"SPEC","level":"MUST","comment":"An endpoint that successfully removes protection with old\nkeys when newer keys were used for packets with lower packet numbers\nMUST treat this as a connection error of type KEY_UPDATE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":53,"type":"SPEC","level":"MAY","comment":"An endpoint MAY allow a period of approximately the Probe Timeout\n(PTO; see [QUIC-RECOVERY]) after promoting the next set of receive\nkeys to be current before it creates the subsequent set of packet\nprotection keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":62,"type":"SPEC","level":"MAY","comment":"These updated keys MAY replace the previous keys at\nthat time.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":69,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD wait three times\nthe PTO before initiating a key update after receiving an\nacknowledgment that confirms that the previous key update was\nreceived.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":78,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD retain old read keys for no more than three times\nthe PTO after having received a packet protected using the new keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":85,"type":"SPEC","level":"SHOULD","comment":"After this period, old read keys and their corresponding secrets\nSHOULD be discarded.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":77,"type":"SPEC","level":"MUST","comment":"Endpoints MUST count the number of encrypted packets for each set of\nkeys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":84,"type":"SPEC","level":"MUST","comment":"If the total number of encrypted packets with the same key\nexceeds the confidentiality limit for the selected AEAD, the endpoint\nMUST stop using those keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":92,"type":"SPEC","level":"MUST","comment":"Endpoints MUST initiate a key update\nbefore sending more protected packets than the confidentiality limit\nfor the selected AEAD permits.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":100,"type":"SPEC","level":"MUST","comment":"If a key update is not possible or\nintegrity limits are reached, the endpoint MUST stop using the\nconnection and only send stateless resets in response to receiving\npackets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":109,"type":"SPEC","level":"SHOULD","comment":"It is RECOMMENDED that endpoints immediately close the\nconnection with a connection error of type AEAD_LIMIT_REACHED before\nreaching a state where key updates are not possible.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":117,"type":"SPEC","level":"MUST","comment":"In addition to counting packets sent, endpoints MUST count the number\nof received packets that fail authentication during the lifetime of a\nconnection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":125,"type":"SPEC","level":"MUST","comment":"If the total number of received packets that fail\nauthentication within the connection, across all keys, exceeds the\nintegrity limit for the selected AEAD, the endpoint MUST immediately\nclose the connection with a connection error of type\nAEAD_LIMIT_REACHED and not process any more packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":135,"type":"SPEC","level":"MAY","comment":"Endpoints that limit the size of packets MAY use higher\nconfidentiality and integrity limits; see Appendix B for details.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":142,"type":"SPEC","level":"MAY","comment":"Future analyses and specifications MAY relax confidentiality or\nintegrity limits for an AEAD.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":149,"type":"SPEC","level":"MUST","comment":"Any TLS cipher suite that is specified for use with QUIC MUST define\nlimits on the use of the associated AEAD function that preserves\nmargins for confidentiality and integrity.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":157,"type":"SPEC","level":"MUST","comment":"That is, limits MUST be\nspecified for the number of packets that can be authenticated and for\nthe number of packets that can fail authentication.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6","line":55,"type":"SPEC","level":"MAY","comment":"Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY\ninitiate a key update.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6","line":62,"type":"SPEC","level":"MUST","comment":"Endpoints\nMUST NOT send a TLS KeyUpdate message.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6","line":69,"type":"SPEC","level":"MUST","comment":"Endpoints MUST treat the\nreceipt of a TLS KeyUpdate message as a connection error of type\n0x010a, equivalent to a fatal TLS alert of unexpected_message; see\nSection 4.8.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-7","line":26,"type":"SPEC","level":"SHOULD","comment":"Implementations\nSHOULD use caution in relying on any data that is contained in\nInitial packets that is not otherwise authenticated.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":27,"type":"SPEC","level":"MUST","comment":"Unless another\nmechanism is used for agreeing on an application protocol, endpoints\nMUST use ALPN for this purpose.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":35,"type":"SPEC","level":"MUST","comment":"When using ALPN, endpoints MUST immediately close a connection (see\nSection 10.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS\nalert (QUIC error code 0x0178; see Section 4.8) if an application\nprotocol is not negotiated.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":44,"type":"SPEC","level":"MUST","comment":"While [ALPN] only specifies that servers\nuse this alert, QUIC clients MUST use error 0x0178 to terminate a\nconnection when ALPN negotiation fails.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":52,"type":"SPEC","level":"MAY","comment":"An application protocol MAY restrict the QUIC versions that it can\noperate over.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":59,"type":"SPEC","level":"MUST","comment":"Servers MUST select an application protocol compatible\nwith the QUIC version that the client has selected.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":66,"type":"SPEC","level":"MUST","comment":"The server MUST\ntreat the inability to select a compatible application protocol as a\nconnection error of type 0x0178 (no_application_protocol).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":74,"type":"SPEC","level":"MUST","comment":"Similarly, a client MUST treat the selection of an incompatible\napplication protocol by a server as a connection error of type\n0x0178.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.2","line":44,"type":"SPEC","level":"MUST","comment":"Endpoints\nMUST send the quic_transport_parameters extension; endpoints that\nreceive ClientHello or EncryptedExtensions messages without the\nquic_transport_parameters extension MUST close the connection with an\nerror of type 0x016d (equivalent to a fatal TLS missing_extension\nalert, see Section 4.8).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.2","line":55,"type":"SPEC","level":"MUST","comment":"Endpoints MUST NOT send this extension in a TLS connection that does\nnot use QUIC (such as the use of TLS with TCP defined in [TLS13]).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.2","line":62,"type":"SPEC","level":"MUST","comment":"A\nfatal unsupported_extension alert MUST be sent by an implementation\nthat supports this extension if the extension is received when the\ntransport is not QUIC.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.3","line":16,"type":"SPEC","level":"MUST","comment":"Clients MUST NOT send the EndOfEarlyData message.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.3","line":22,"type":"SPEC","level":"MUST","comment":"A server MUST\ntreat receipt of a CRYPTO frame in a 0-RTT packet as a connection\nerror of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.4","line":19,"type":"SPEC","level":"MUST","comment":"A client MUST NOT request the use of the\nTLS 1.3 compatibility mode.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.4","line":26,"type":"SPEC","level":"SHOULD","comment":"A server SHOULD treat the receipt of a\nTLS ClientHello with a non-empty legacy_session_id field as a\nconnection error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":52,"type":"SPEC","level":"MUST","comment":"Endpoints MUST implement and use the replay protections described in\n[TLS13], however it is recognized that these protections are\nimperfect.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":60,"type":"SPEC","level":"MUST","comment":"These MUST NOT be\nused to communicate application semantics between endpoints; clients\nMUST treat them as opaque values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":68,"type":"SPEC","level":"MUST","comment":"An application\nprotocol that uses QUIC MUST describe how the protocol uses 0-RTT and\nthe measures that are employed to protect against replay attack.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":76,"type":"SPEC","level":"MUST","comment":"QUIC extensions MUST either describe how replay attacks affect their\noperation or prohibit the use of the extension in 0-RTT.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":83,"type":"SPEC","level":"MUST","comment":"Application\nprotocols MUST either prohibit the use of extensions that carry\napplication semantics in 0-RTT or provide replay mitigation\nstrategies.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.3","line":18,"type":"SPEC","level":"MUST","comment":"First, the packet\ncontaining a ClientHello MUST be padded to a minimum size.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.4","line":40,"type":"SPEC","level":"MUST","comment":"Future header protection variants based on this construction MUST use\na PRF to ensure equivalent security guarantees.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.5","line":38,"type":"SPEC","level":"MUST","comment":"For authentication to be\nfree from side channels, the entire process of header protection\nremoval, packet number recovery, and packet protection removal MUST\nbe applied together without timing and other side channels.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.5","line":47,"type":"SPEC","level":"MUST","comment":"For the sending of packets, construction and protection of packet\npayloads and packet numbers MUST be free from side channels that\nwould reveal the packet number or its encoded size.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.5","line":55,"type":"SPEC","level":"SHOULD","comment":"After\nreceiving a key update, an endpoint SHOULD generate and save the next\nset of receive packet protection keys, as described in Section 6.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.6","line":26,"type":"SPEC","level":"SHOULD","comment":"To preserve this separation, a new version of QUIC SHOULD define new\nlabels for key derivation for packet protection key and IV, plus the\nheader protection keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.6","line":34,"type":"SPEC","level":"SHOULD","comment":"New QUIC versions SHOULD define a new salt value used in\ncalculating initial secrets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.1","line":42,"type":"SPEC","level":"SHOULD","comment":"To avoid generating multiple RTT samples for a single packet, an ACK\nframe SHOULD NOT be used to update RTT estimates if it does not newly\nacknowledge the largest acknowledged packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.1","line":50,"type":"SPEC","level":"MUST","comment":"An RTT sample MUST NOT be generated on receiving an ACK frame that\ndoes not newly acknowledge at least one ack-eliciting packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":38,"type":"SPEC","level":"MUST","comment":"min_rtt MUST be set to the latest_rtt on the first RTT sample.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":44,"type":"SPEC","level":"MUST","comment":"min_rtt MUST be set to the lesser of min_rtt and latest_rtt\n(Section 5.1) on all other samples.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":51,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD set the min_rtt to the newest RTT sample after\npersistent congestion is established.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":58,"type":"SPEC","level":"MAY","comment":"Endpoints MAY reestablish the min_rtt at other times in the\nconnection, such as when traffic volume is low and an acknowledgment\nis received with a low acknowledgment delay.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":66,"type":"SPEC","level":"SHOULD","comment":"Implementations SHOULD\nNOT refresh the min_rtt value too often since the actual minimum RTT\nof the path is not frequently observable.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":105,"type":"SPEC","level":"SHOULD","comment":"To account for this, the endpoint SHOULD ignore\nmax_ack_delay until the handshake is confirmed, as defined in\nSection 4.1.2 of [QUIC-TLS].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":113,"type":"SPEC","level":"MAY","comment":"Therefore, prior to handshake confirmation, an endpoint\nMAY ignore RTT samples if adjusting the RTT sample for acknowledgment\ndelay causes the sample to be less than the min_rtt.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":121,"type":"SPEC","level":"MAY","comment":"* MAY ignore the acknowledgment delay for Initial packets, since\nthese acknowledgments are not delayed by the peer (Section 13.2.1\nof [QUIC-TRANSPORT]);\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":129,"type":"SPEC","level":"SHOULD","comment":"* SHOULD ignore the peer's max_ack_delay until the handshake is\nconfirmed;\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":136,"type":"SPEC","level":"MUST","comment":"* MUST use the lesser of the acknowledgment delay and the peer's\nmax_ack_delay after the handshake is confirmed; and\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":143,"type":"SPEC","level":"MUST","comment":"* MUST NOT subtract the acknowledgment delay from the RTT sample if\nthe resulting value is smaller than the min_rtt.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":150,"type":"SPEC","level":"SHOULD","comment":"In such\ncases, an endpoint SHOULD subtract such local delays from its RTT\nsample until the handshake is confirmed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.1","line":20,"type":"SPEC","level":"SHOULD","comment":"The RECOMMENDED initial value for the packet reordering threshold\n(kPacketThreshold) is 3, based on best practices for TCP loss\ndetection [RFC5681] [RFC6675].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.1","line":28,"type":"SPEC","level":"SHOULD","comment":"In order to remain similar to TCP,\nimplementations SHOULD NOT use a packet threshold less than 3; see\n[RFC5681].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":41,"type":"SPEC","level":"SHOULD","comment":"Once a later packet within the same packet number space has been\nacknowledged, an endpoint SHOULD declare an earlier packet lost if it\nwas sent a threshold amount of time in the past.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":49,"type":"SPEC","level":"MUST","comment":"To avoid declaring\npackets as lost too early, this time threshold MUST be set to at\nleast the local timer granularity, as indicated by the kGranularity\nconstant.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":58,"type":"SPEC","level":"SHOULD","comment":"If packets sent prior to the largest acknowledged packet cannot yet\nbe declared lost, then a timer SHOULD be set for the remaining time.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":65,"type":"SPEC","level":"SHOULD","comment":"The RECOMMENDED time threshold (kTimeThreshold), expressed as an RTT\nmultiplier, is 9/8.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":72,"type":"SPEC","level":"SHOULD","comment":"The RECOMMENDED value of the timer granularity\n(kGranularity) is 1 millisecond.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":79,"type":"SPEC","level":"MAY","comment":"Implementations MAY experiment with absolute thresholds, thresholds\nfrom previous connections, adaptive thresholds, or the including of\nRTT variation.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1","line":34,"type":"SPEC","level":"MAY","comment":"Implementations with adaptive time\nthresholds MAY choose to start with smaller initial reordering\nthresholds to minimize recovery latency.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":73,"type":"SPEC","level":"MUST","comment":"The PTO period MUST be at least kGranularity to avoid the timer\nexpiring immediately.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":80,"type":"SPEC","level":"MUST","comment":"When ack-eliciting packets in multiple packet number spaces are in\nflight, the timer MUST be set to the earlier value of the Initial and\nHandshake packet number spaces.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":88,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT set its PTO timer for the Application Data\npacket number space until the handshake is confirmed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":95,"type":"SPEC","level":"SHOULD","comment":"A sender SHOULD restart its PTO timer every time an ack-eliciting\npacket is sent or acknowledged, or when Initial or Handshake keys are\ndiscarded (Section 4.9 of [QUIC-TLS]).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":103,"type":"SPEC","level":"MUST","comment":"When a PTO timer expires, the PTO backoff MUST be increased,\nresulting in the PTO period being set to twice its current value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":110,"type":"SPEC","level":"MUST","comment":"The PTO timer MUST NOT be set if a timer is set for time threshold\nloss detection; see Section 6.1.2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2.1","line":32,"type":"SPEC","level":"MUST","comment":"If\nno additional data can be sent, the server's PTO timer MUST NOT be\narmed until datagrams have been received from the client because\npackets sent on PTO count against the anti-amplification limit.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2.1","line":41,"type":"SPEC","level":"MUST","comment":"That is,\nthe client MUST set the PTO timer if the client has not received an\nacknowledgment for any of its Handshake packets and the handshake is\nnot confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no\npackets in flight.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2.1","line":51,"type":"SPEC","level":"MUST","comment":"When the PTO fires, the client MUST send a\nHandshake packet if it has Handshake keys, otherwise it MUST send an\nInitial packet in a UDP datagram with a payload of at least 1200\nbytes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":25,"type":"SPEC","level":"MAY","comment":"Resumed connections over the same network MAY use the previous\nconnection's final smoothed RTT value as the resumed connection's\ninitial RTT.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":33,"type":"SPEC","level":"SHOULD","comment":"When no previous RTT is available, the initial RTT\nSHOULD be set to 333 milliseconds.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":40,"type":"SPEC","level":"SHOULD","comment":"A connection MAY use the delay between sending a PATH_CHALLENGE and\nreceiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in\nAppendix A.2) for a new path, but the delay SHOULD NOT be considered\nan RTT sample.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":49,"type":"SPEC","level":"MUST","comment":"When\nInitial or Handshake keys are discarded, the PTO and loss detection\ntimers MUST be reset, because discarding keys indicates forward\nprogress and the loss detection timer might have been set for a now-\ndiscarded packet number space.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.3","line":28,"type":"SPEC","level":"MAY","comment":"To speed up handshake completion under these conditions, an endpoint\nMAY, for a limited number of times per connection, send a packet\ncontaining unacknowledged CRYPTO data earlier than the PTO expiry,\nsubject to the address validation limits in Section 8.1 of\n[QUIC-TRANSPORT].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":56,"type":"SPEC","level":"MUST","comment":"When a PTO timer expires, a sender MUST send at least one ack-\neliciting packet in the packet number space as a probe.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":63,"type":"SPEC","level":"MAY","comment":"An endpoint\nMAY send up to two full-sized datagrams containing ack-eliciting\npackets to avoid an expensive consecutive PTO expiration due to a\nsingle lost datagram or to transmit data from multiple packet number\nspaces.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":73,"type":"SPEC","level":"MUST","comment":"All probe packets sent on a PTO MUST be ack-eliciting.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":79,"type":"SPEC","level":"SHOULD","comment":"In addition to sending data in the packet number space for which the\ntimer expired, the sender SHOULD send ack-eliciting packets from\nother packet number spaces with in-flight data, coalescing packets if\npossible.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":88,"type":"SPEC","level":"SHOULD","comment":"An endpoint SHOULD include new data in packets that are sent on PTO\nexpiration.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":95,"type":"SPEC","level":"MAY","comment":"Previously sent data MAY be sent if no new data can be\nsent.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":102,"type":"SPEC","level":"MAY","comment":"Implementations MAY use alternative strategies for determining\nthe content of probe packets, including sending new or retransmitted\ndata based on the application's priorities.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":110,"type":"SPEC","level":"SHOULD","comment":"When there is no data to send, the sender SHOULD send\na PING or other ack-eliciting frame in a single packet, rearming the\nPTO timer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":118,"type":"SPEC","level":"MAY","comment":"Alternatively, instead of sending an ack-eliciting packet, the sender\nMAY mark any packets still in flight as lost.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2","line":25,"type":"SPEC","level":"MUST","comment":"A PTO timer expiration event does not indicate packet loss and MUST\nNOT cause prior unacknowledged packets to be marked as lost.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.3","line":22,"type":"SPEC","level":"MAY","comment":"The client MAY compute an RTT estimate to the server as the time\nperiod from when the first Initial packet was sent to when a Retry or\na Version Negotiation packet is received.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.3","line":30,"type":"SPEC","level":"MAY","comment":"The client MAY use this\nvalue in place of its default for the initial RTT estimate.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.4","line":30,"type":"SPEC","level":"MUST","comment":"The sender MUST discard all recovery state\nassociated with those packets and MUST remove them from the count of\nbytes in flight.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.2","line":31,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD use an initial congestion\nwindow of ten times the maximum datagram size (max_datagram_size),\nwhile limiting the window to the larger of 14,720 bytes or twice the\nmaximum datagram size.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.2","line":40,"type":"SPEC","level":"SHOULD","comment":"If the maximum datagram size changes during the connection, the\ninitial congestion window SHOULD be recalculated with the new size.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.2","line":47,"type":"SPEC","level":"SHOULD","comment":"If the maximum datagram size is decreased in order to complete the\nhandshake, the congestion window SHOULD be set to the new initial\ncongestion window.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.2","line":55,"type":"SPEC","level":"SHOULD","comment":"The RECOMMENDED\nvalue is 2 * max_datagram_size.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.1","line":22,"type":"SPEC","level":"MUST","comment":"The sender MUST exit slow start and enter a recovery period when a\npacket is lost or when the ECN-CE count reported by its peer\nincreases.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.2","line":34,"type":"SPEC","level":"MUST","comment":"On entering a recovery period, a sender MUST set the slow start\nthreshold to half the value of the congestion window when loss is\ndetected.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.2","line":42,"type":"SPEC","level":"MUST","comment":"The congestion window MUST be set to the reduced value of\nthe slow start threshold before exiting the recovery period.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.2","line":49,"type":"SPEC","level":"MAY","comment":"Implementations MAY reduce the congestion window immediately upon\nentering a recovery period or use other mechanisms, such as\nProportional Rate Reduction [PRR], to reduce the congestion window\nmore gradually.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.3","line":18,"type":"SPEC","level":"MUST","comment":"A sender in congestion avoidance uses an Additive Increase\nMultiplicative Decrease (AIMD) approach that MUST limit the increase\nto the congestion window to at most one maximum datagram size for\neach congestion window that is acknowledged.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.4","line":15,"type":"SPEC","level":"MAY","comment":"Endpoints MAY ignore the\nloss of Handshake, 0-RTT, and 1-RTT packets that might have arrived\nbefore the peer had packet protection keys to process those packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.4","line":23,"type":"SPEC","level":"MUST","comment":"Endpoints MUST NOT ignore the loss of packets that were sent after\nthe earliest acknowledged packet in a given packet number space.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.5","line":13,"type":"SPEC","level":"MUST","comment":"Probe packets MUST NOT be blocked by the congestion controller.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.5","line":19,"type":"SPEC","level":"MUST","comment":"A\nsender MUST however count these packets as being additionally in\nflight, since these packets add network load without establishing\npacket loss.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.1","line":38,"type":"SPEC","level":"SHOULD","comment":"The RECOMMENDED value for kPersistentCongestionThreshold is 3, which\nresults in behavior that is approximately equivalent to a TCP sender\ndeclaring an RTO after two TLPs.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":42,"type":"SPEC","level":"MUST","comment":"These two packets MUST be ack-eliciting, since a receiver is required\nto acknowledge only ack-eliciting packets within its maximum\nacknowledgment delay; see Section 13.2 of [QUIC-TRANSPORT].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":50,"type":"SPEC","level":"SHOULD","comment":"The persistent congestion period SHOULD NOT start until there is at\nleast one RTT sample.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":57,"type":"SPEC","level":"SHOULD","comment":"Since network congestion is not affected by packet number spaces,\npersistent congestion SHOULD consider packets sent across packet\nnumber spaces.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":65,"type":"SPEC","level":"MAY","comment":"A sender that does not have state for all packet\nnumber spaces or an implementation that cannot compare send times\nacross packet number spaces MAY use state for just the packet number\nspace that was acknowledged.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":74,"type":"SPEC","level":"MUST","comment":"When persistent congestion is declared, the sender's congestion\nwindow MUST be reduced to the minimum congestion window\n(kMinimumWindow), similar to a TCP sender's response on an RTO\n[RFC5681].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":51,"type":"SPEC","level":"SHOULD","comment":"A sender SHOULD pace sending of all in-flight packets based on input\nfrom the congestion controller.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":58,"type":"SPEC","level":"MUST","comment":"Senders MUST either use pacing or limit such bursts.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":64,"type":"SPEC","level":"SHOULD","comment":"Senders SHOULD limit bursts to the initial congestion window; see\nSection 7.2.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":71,"type":"SPEC","level":"MAY","comment":"A sender with knowledge that the network path to the\nreceiver can absorb larger bursts MAY use a higher limit.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":78,"type":"SPEC","level":"SHOULD","comment":"To avoid delaying their delivery to the peer, packets\ncontaining only ACK frames SHOULD therefore not be paced.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.8","line":20,"type":"SPEC","level":"SHOULD","comment":"When this occurs, the congestion window\nSHOULD NOT be increased in either slow start or congestion avoidance.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.8","line":27,"type":"SPEC","level":"SHOULD","comment":"A sender SHOULD NOT consider itself application limited if it\nwould have fully utilized the congestion window without pacing delay.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.8","line":34,"type":"SPEC","level":"MAY","comment":"A sender MAY implement alternative mechanisms to update its\ncongestion window after periods of underutilization, such as those\nproposed for TCP in [RFC7661].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7","line":36,"type":"SPEC","level":"MUST","comment":"If a sender uses a different controller than that specified in this\ndocument, the chosen controller MUST conform to the congestion\ncontrol guidelines specified in Section 3.1 of [RFC8085].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7","line":44,"type":"SPEC","level":"MAY","comment":"Unlike\nTCP, QUIC can detect the loss of these packets and MAY use that\ninformation to adjust the congestion controller or the rate of ACK-\nonly packets being sent, but this document does not describe a\nmechanism for doing so.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7","line":54,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send a packet if it would cause bytes_in_flight\n(see Appendix B.2) to be larger than the congestion window, unless\nthe packet is sent on a PTO timer expiration (see Section 6.2) or\nwhen entering recovery (see Section 7.3.2).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.3","line":21,"type":"SPEC","level":"MUST","comment":"Requests or responses containing invalid field names MUST be treated\nas malformed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.3","line":28,"type":"SPEC","level":"MUST","comment":"Any request or response that contains a\ncharacter not permitted in a field value MUST be treated as\nmalformed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.4","line":24,"type":"SPEC","level":"MUST","comment":"Where multiple tenants share space on the same server, that server\nMUST ensure that tenants are not able to push representations of\nresources that they do not have authority over.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.5.1","line":30,"type":"SPEC","level":"MAY","comment":"This setting is only advisory, so\nendpoints MAY choose to send field sections that exceed this limit\nand risk having the request or response being treated as malformed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.5","line":42,"type":"SPEC","level":"SHOULD","comment":"A client that accepts server push SHOULD limit the number\nof push IDs it issues at a time.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.5","line":49,"type":"SPEC","level":"SHOULD","comment":"Implementations SHOULD track the\nuse of these features and set limits on their use.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.5","line":56,"type":"SPEC","level":"MAY","comment":"An endpoint MAY\ntreat activity that is suspicious as a connection error of type\nH3_EXCESSIVE_LOAD, but false positives will result in disrupting\nvalid connections and requests.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.6","line":26,"type":"SPEC","level":"MUST","comment":"Implementations communicating on a secure channel MUST NOT compress\ncontent that includes both confidential and attacker-controlled data\nunless separate compression contexts are used for each source of\ndata.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.6","line":35,"type":"SPEC","level":"MUST","comment":"Compression MUST NOT be used if the source of data cannot be\nreliably determined.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.8","line":11,"type":"SPEC","level":"MUST","comment":"An implementation MUST ensure that the length of a\nframe exactly matches the length of the fields it contains.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-10.9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.9","line":12,"type":"SPEC","level":"MUST","comment":"The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when\nusing HTTP/3 with 0-RTT.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":66,"type":"SPEC","level":"SHOULD","comment":"If an entry is present in\nonly one registry, every effort SHOULD be made to avoid assigning the\ncorresponding value to an unrelated operation.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":74,"type":"SPEC","level":"MAY","comment":"Expert reviewers MAY\nreject unrelated registrations that would conflict with the same\nvalue in the corresponding registry.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":82,"type":"SPEC","level":"MUST","comment":"In addition to common fields as described in Section 11.2, permanent\nregistrations in this registry MUST include the following field:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":89,"type":"SPEC","level":"MUST","comment":"Specifications of frame types MUST include a description of the frame\nlayout and its semantics, including any parts of the frame that are\nconditionally present.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":97,"type":"SPEC","level":"MUST","comment":"Each code of the format 0x1f * N + 0x21 for non-negative integer\nvalues of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)\nMUST NOT be assigned by IANA and MUST NOT appear in the listing of\nassigned values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":59,"type":"SPEC","level":"SHOULD","comment":"If an entry is present in only one registry, every\neffort SHOULD be made to avoid assigning the corresponding value to\nan unrelated operation.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":67,"type":"SPEC","level":"MAY","comment":"Expert reviewers MAY reject unrelated\nregistrations that would conflict with the same value in the\ncorresponding registry.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":75,"type":"SPEC","level":"MUST","comment":"In addition to common fields as described in Section 11.2, permanent\nregistrations in this registry MUST include the following fields:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":82,"type":"SPEC","level":"SHOULD","comment":"A\ndefault SHOULD be the most restrictive possible value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":89,"type":"SPEC","level":"MUST","comment":"Each code of the format 0x1f * N + 0x21 for non-negative integer\nvalues of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)\nMUST NOT be assigned by IANA and MUST NOT appear in the listing of\nassigned values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.3","line":114,"type":"SPEC","level":"MAY","comment":"Use of values that are registered in the \"HTTP/2 Error Code\" registry\nis discouraged, and expert reviewers MAY reject such registrations.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.3","line":121,"type":"SPEC","level":"MUST","comment":"Permanent registrations in\nthis registry MUST include the following field:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.3","line":128,"type":"SPEC","level":"MUST","comment":"Each code of the format 0x1f * N + 0x21 for non-negative integer\nvalues of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)\nMUST NOT be assigned by IANA and MUST NOT appear in the listing of\nassigned values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.4","line":43,"type":"SPEC","level":"MUST","comment":"In addition to common fields as described in Section 11.2, permanent\nregistrations in this registry MUST include the following fields:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.4","line":50,"type":"SPEC","level":"MUST","comment":"Specifications for permanent registrations MUST include a description\nof the stream type, including the layout and semantics of the stream\ncontents.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-11.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.4","line":58,"type":"SPEC","level":"MUST","comment":"Each code of the format 0x1f * N + 0x21 for non-negative integer\nvalues of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)\nMUST NOT be assigned by IANA and MUST NOT appear in the listing of\nassigned values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1.1","line":20,"type":"SPEC","level":"MAY","comment":"On receipt of an Alt-Svc record indicating HTTP/3 support, a client\nMAY attempt to establish a QUIC connection to the indicated host and\nport; if this connection is successful, the client can send HTTP\nrequests using the mapping described in this document.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1.2","line":21,"type":"SPEC","level":"MUST","comment":"Prior to making requests for an origin whose scheme is not \"https\",\nthe client MUST ensure the server is willing to serve that scheme.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":39,"type":"SPEC","level":"MUST","comment":"Upon receiving a\nserver certificate in the TLS handshake, the client MUST verify that\nthe certificate is an acceptable match for the URI's origin server\nusing the process described in Section 4.3.4 of [HTTP].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":48,"type":"SPEC","level":"MUST","comment":"If the\ncertificate cannot be verified with respect to the URI's origin\nserver, the client MUST NOT consider the server authoritative for\nthat origin.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":57,"type":"SPEC","level":"MAY","comment":"A client MAY attempt access to a resource with an \"https\" URI by\nresolving the host identifier to an IP address, establishing a QUIC\nconnection to that address on the indicated port (including\nvalidation of the server certificate as described above), and sending\nan HTTP/3 request message targeting the URI to the server over that\nsecured connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":68,"type":"SPEC","level":"SHOULD","comment":"Connectivity problems (e.g., blocking UDP) can result in a failure to\nestablish a QUIC connection; clients SHOULD attempt to use TCP-based\nversions of HTTP in this case.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":76,"type":"SPEC","level":"MAY","comment":"Servers MAY serve HTTP/3 on any UDP port; an alternative service\nadvertisement always includes an explicit port, and URIs contain\neither an explicit port or a default port associated with the scheme.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":28,"type":"SPEC","level":"MAY","comment":"The use\nof other QUIC transport versions with HTTP/3 MAY be defined by future\nspecifications.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":36,"type":"SPEC","level":"MUST","comment":"HTTP/3 clients MUST support a mechanism to indicate the\ntarget host to the server during the TLS handshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":43,"type":"SPEC","level":"MUST","comment":"If the server is\nidentified by a domain name ([DNS-TERMS]), clients MUST send the\nServer Name Indication (SNI; [RFC6066]) TLS extension unless an\nalternative mechanism to indicate the target host is used.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":52,"type":"SPEC","level":"MAY","comment":"Support for\nother application-layer protocols MAY be offered in the same\nhandshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":60,"type":"SPEC","level":"MUST","comment":"After the QUIC connection is\nestablished, a SETTINGS frame MUST be sent by each endpoint as the\ninitial frame of their respective HTTP control stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":52,"type":"SPEC","level":"MAY","comment":"Once a connection to a server endpoint exists, this connection MAY be\nreused for requests with multiple different URI authority components.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":59,"type":"SPEC","level":"MUST","comment":"To use an existing connection for a new origin, clients MUST validate\nthe certificate presented by the server for the new origin server\nusing the process described in Section 4.3.4 of [HTTP].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":67,"type":"SPEC","level":"MUST","comment":"If the certificate is not acceptable with regard to the new origin\nfor any reason, the connection MUST NOT be reused and a new\nconnection SHOULD be established for the new origin.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":75,"type":"SPEC","level":"SHOULD","comment":"If the reason\nthe certificate cannot be verified might apply to other origins\nalready associated with the connection, the client SHOULD revalidate\nthe server certificate for those origins.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":84,"type":"SPEC","level":"SHOULD","comment":"Clients SHOULD NOT open more than one HTTP/3 connection to a given IP\naddress and UDP port, where the IP address and port might be derived\nfrom a URI, a selected alternative service ([ALTSVC]), a configured\nproxy, or name resolution of any of these.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":93,"type":"SPEC","level":"SHOULD","comment":"A client MAY open\nmultiple HTTP/3 connections to the same IP address and UDP port using\ndifferent transport or TLS configurations but SHOULD avoid creating\nmultiple connections with the same configuration.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-3.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":102,"type":"SPEC","level":"SHOULD","comment":"When either endpoint chooses to close the HTTP/3\nconnection, the terminating endpoint SHOULD first send a GOAWAY frame\n(Section 5.2) so that both endpoints can reliably determine whether\npreviously sent frames have been processed and gracefully complete or\nterminate any necessary remaining tasks.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":50,"type":"SPEC","level":"MAY","comment":"Once a request stream has been opened, the request MAY be cancelled\nby either endpoint.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":57,"type":"SPEC","level":"SHOULD","comment":"When possible, it is RECOMMENDED that servers\nsend an HTTP response with an appropriate status code rather than\ncancelling a request it has already begun processing.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":65,"type":"SPEC","level":"SHOULD","comment":"Implementations SHOULD cancel requests by abruptly terminating any\ndirections of a stream that are still open.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":72,"type":"SPEC","level":"SHOULD","comment":"The server SHOULD\nabort its response stream with the error code H3_REQUEST_REJECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":79,"type":"SPEC","level":"MUST","comment":"Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests\nthat were partially or fully processed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":86,"type":"SPEC","level":"SHOULD","comment":"When a server abandons a\nresponse after partial processing, it SHOULD abort its response\nstream with the error code H3_REQUEST_CANCELLED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":94,"type":"SPEC","level":"SHOULD","comment":"Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel\nrequests.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":101,"type":"SPEC","level":"MAY","comment":"Upon receipt of this error code, a server MAY abruptly\nterminate the response using the error code H3_REQUEST_REJECTED if no\nprocessing was performed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":109,"type":"SPEC","level":"MUST","comment":"Clients MUST NOT use the\nH3_REQUEST_REJECTED error code, except when a server has requested\nclosure of the request stream with this error code.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":117,"type":"SPEC","level":"MAY","comment":"If a stream is cancelled after receiving a complete response, the\nclient MAY ignore the cancellation and use the response.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":124,"type":"SPEC","level":"SHOULD","comment":"However, if\na stream is cancelled after receiving a partial response, the\nresponse SHOULD NOT be used.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":132,"type":"SPEC","level":"SHOULD","comment":"Only idempotent actions such as GET,\nPUT, or DELETE can be safely retried; a client SHOULD NOT\nautomatically retry a request with a non-idempotent method unless it\nhas some means to know that the request semantics are idempotent\nindependent of the method or some means to detect that the original\nrequest was never applied.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":42,"type":"SPEC","level":"MUST","comment":"Intermediaries that process HTTP requests or responses (i.e., any\nintermediary not acting as a tunnel) MUST NOT forward a malformed\nrequest or response.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":50,"type":"SPEC","level":"MUST","comment":"Malformed requests or responses that are\ndetected MUST be treated as a stream error of type H3_MESSAGE_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":57,"type":"SPEC","level":"MAY","comment":"For malformed requests, a server MAY send an HTTP response indicating\nthe error prior to closing or resetting the stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":64,"type":"SPEC","level":"MUST","comment":"Clients MUST NOT\naccept a malformed response.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":98,"type":"SPEC","level":"MUST","comment":"A\nclient MUST send only a single request on a given stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":105,"type":"SPEC","level":"MUST","comment":"On a given stream, receipt of multiple requests or receipt of an\nadditional HTTP response following a final HTTP response MUST be\ntreated as malformed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":113,"type":"SPEC","level":"MUST","comment":"Receipt of an invalid sequence of frames MUST be treated as a\nconnection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":120,"type":"SPEC","level":"MAY","comment":"A server MAY send one or more PUSH_PROMISE frames before, after, or\ninterleaved with the frames of a response message.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":127,"type":"SPEC","level":"MUST","comment":"PUSH_PROMISE frames are not permitted on push streams;\na pushed response that includes PUSH_PROMISE frames MUST be treated\nas a connection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":135,"type":"SPEC","level":"MAY","comment":"Frames of unknown types (Section 9), including reserved frames\n(Section 7.2.8) MAY be sent on a request or push stream before,\nafter, or interleaved with other frames described in this section.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":143,"type":"SPEC","level":"MUST","comment":"Transfer codings (see Section 7 of [HTTP/1.1]) are not defined for\nHTTP/3; the Transfer-Encoding header field MUST NOT be used.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":150,"type":"SPEC","level":"MAY","comment":"A response MAY consist of multiple messages when and only when one or\nmore interim responses (1xx; see Section 15.2 of [HTTP]) precede a\nfinal response to the same request.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":158,"type":"SPEC","level":"MUST","comment":"After sending a request, a client MUST\nclose the stream for sending.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":165,"type":"SPEC","level":"MUST","comment":"Unless using the CONNECT method (see\nSection 4.4), clients MUST NOT make stream closure dependent on\nreceiving a response to their request.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":173,"type":"SPEC","level":"MUST","comment":"After sending a final\nresponse, the server MUST close the stream for sending.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":180,"type":"SPEC","level":"SHOULD","comment":"Because some messages are large or unbounded, endpoints\nSHOULD begin processing partial HTTP messages once enough of the\nmessage has been received to make progress.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":188,"type":"SPEC","level":"SHOULD","comment":"If a client-initiated\nstream terminates without enough of the HTTP message to provide a\ncomplete response, the server SHOULD abort its response stream with\nthe error code H3_REQUEST_INCOMPLETE.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":197,"type":"SPEC","level":"MAY","comment":"When the server does\nnot need to receive the remainder of the request, it MAY abort\nreading the request stream, send a complete response, and cleanly\nclose the sending part of the stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":206,"type":"SPEC","level":"SHOULD","comment":"The error code H3_NO_ERROR\nSHOULD be used when requesting that the client stop sending on the\nrequest stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":214,"type":"SPEC","level":"MUST","comment":"Clients MUST NOT discard complete responses as a\nresult of having their request terminated abruptly, though clients\ncan always discard responses at their discretion for other reasons.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":222,"type":"SPEC","level":"SHOULD","comment":"If the server sends a partial or complete response but does not abort\nreading the request, clients SHOULD continue sending the content of\nthe request and close the stream normally.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.1","line":21,"type":"SPEC","level":"MAY","comment":"To allow for better compression efficiency, the Cookie header field\n([COOKIES]) MAY be split into separate field lines, each with one or\nmore cookie-pairs, before compression.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.1","line":29,"type":"SPEC","level":"MUST","comment":"If a decompressed field\nsection contains multiple cookie field lines, these MUST be\nconcatenated into a single byte string using the two-byte delimiter\nof \"; \" (ASCII 0x3b, 0x20) before being passed into a context other\nthan HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic\nHTTP server application.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.2","line":25,"type":"SPEC","level":"MAY","comment":"An HTTP/3 implementation MAY impose a limit on the maximum size of\nthe message header it will accept on an individual HTTP message.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.2","line":32,"type":"SPEC","level":"SHOULD","comment":"An implementation that\nhas received this parameter SHOULD NOT send an HTTP message header\nthat exceeds the indicated size, as the peer will likely refuse to\nprocess it.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":36,"type":"SPEC","level":"MUST","comment":"Characters in field names MUST be\nconverted to lowercase prior to their encoding.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":43,"type":"SPEC","level":"MUST","comment":"A request or\nresponse containing uppercase characters in field names MUST be\ntreated as malformed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":51,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT generate\nan HTTP/3 field section containing connection-specific fields; any\nmessage containing connection-specific fields MUST be treated as\nmalformed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":60,"type":"SPEC","level":"MUST","comment":"The only exception to this is the TE header field, which MAY be\npresent in an HTTP/3 request header; when it is, it MUST NOT contain\nany value other than \"trailers\".\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":68,"type":"SPEC","level":"MUST","comment":"An intermediary transforming an HTTP/1.x message to HTTP/3 MUST\nremove connection-specific header fields as discussed in\nSection 7.6.1 of [HTTP], or their messages will be treated by other\nHTTP/3 endpoints as malformed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":67,"type":"SPEC","level":"MUST","comment":"The authority MUST NOT include the\ndeprecated userinfo subcomponent for URIs of scheme \"http\" or\n\"https\".\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":75,"type":"SPEC","level":"MUST","comment":"To ensure that the HTTP/1.1 request line can be reproduced\naccurately, this pseudo-header field MUST be omitted when\ntranslating from an HTTP/1.1 request that has a request target in\na method-specific form; see Section 7.1 of [HTTP].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":84,"type":"SPEC","level":"SHOULD","comment":"Clients that\ngenerate HTTP/3 requests directly SHOULD use the :authority\npseudo-header field instead of the Host header field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":92,"type":"SPEC","level":"MUST","comment":"An\nintermediary that converts an HTTP/3 request to HTTP/1.1 MUST\ncreate a Host field if one is not present in a request by copying\nthe value of the :authority pseudo-header field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":101,"type":"SPEC","level":"MUST","comment":"This pseudo-header field MUST NOT be empty for \"http\" or \"https\"\nURIs; \"http\" or \"https\" URIs that do not contain a path component\nMUST include a value of / (ASCII 0x2f).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":109,"type":"SPEC","level":"MUST","comment":"All HTTP/3 requests MUST include exactly one value for the :method,\n:scheme, and :path pseudo-header fields, unless the request is a\nCONNECT request; see Section 4.4.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":117,"type":"SPEC","level":"MUST","comment":"If the :scheme pseudo-header field identifies a scheme that has a\nmandatory authority component (including \"http\" and \"https\"), the\nrequest MUST contain either an :authority pseudo-header field or a\nHost header field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":126,"type":"SPEC","level":"MUST","comment":"If these fields are present, they MUST NOT be\nempty.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":133,"type":"SPEC","level":"MUST","comment":"If both fields are present, they MUST contain the same value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":139,"type":"SPEC","level":"MUST","comment":"If the scheme does not have a mandatory authority component and none\nis provided in the request target, the request MUST NOT contain the\n:authority pseudo-header or Host header fields.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.2","line":14,"type":"SPEC","level":"MUST","comment":"This pseudo-\nheader field MUST be included in all responses; otherwise, the\nresponse is malformed (see Section 4.1.2).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":27,"type":"SPEC","level":"MUST","comment":"Endpoints MUST NOT\ngenerate pseudo-header fields other than those defined in this\ndocument.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":35,"type":"SPEC","level":"MUST","comment":"Pseudo-header fields defined for requests MUST NOT appear\nin responses; pseudo-header fields defined for responses MUST NOT\nappear in requests.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":43,"type":"SPEC","level":"MUST","comment":"Pseudo-header fields MUST NOT appear in trailer\nsections.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":50,"type":"SPEC","level":"MUST","comment":"Endpoints MUST treat a request or response that contains\nundefined or invalid pseudo-header fields as malformed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":57,"type":"SPEC","level":"MUST","comment":"All pseudo-header fields MUST appear in the header section before\nregular header fields.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":64,"type":"SPEC","level":"MUST","comment":"Any request or response that contains a\npseudo-header field that appears in a header section after a regular\nheader field MUST be treated as malformed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":78,"type":"SPEC","level":"MUST","comment":"A CONNECT request MUST be constructed as follows:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":84,"type":"SPEC","level":"MAY","comment":"Extension frames MAY be used if\nspecifically permitted by the definition of the extension.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":91,"type":"SPEC","level":"MUST","comment":"Receipt\nof any other known frame type MUST be treated as a connection error\nof type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":99,"type":"SPEC","level":"SHOULD","comment":"TCP connections that remain half closed in a single\ndirection are not invalid, but are often handled poorly by servers,\nso clients SHOULD NOT close a stream for sending while they still\nexpect to receive data from the target of the CONNECT.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":108,"type":"SPEC","level":"MUST","comment":"Correspondingly, if a proxy detects an error with the stream or the\nQUIC connection, it MUST close the TCP connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":115,"type":"SPEC","level":"MUST","comment":"If the proxy\ndetects that the client has reset the stream or aborted reading from\nthe stream, it MUST close the TCP connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":123,"type":"SPEC","level":"SHOULD","comment":"If the stream is reset\nor reading is aborted by the client, a proxy SHOULD perform the same\noperation on the other direction in order to ensure that both\ndirections of the stream are cancelled.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":132,"type":"SPEC","level":"SHOULD","comment":"In all these cases, if the\nunderlying TCP implementation permits it, the proxy SHOULD send a TCP\nsegment with the RST bit set.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":140,"type":"SPEC","level":"SHOULD","comment":"Since CONNECT creates a tunnel to an arbitrary server, proxies that\nsupport CONNECT SHOULD restrict its use to a set of known ports or a\nlist of safe request targets; see Section 9.3.6 of [HTTP] for more\ndetails.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":110,"type":"SPEC","level":"SHOULD","comment":"A server SHOULD use push IDs sequentially, beginning from\nzero.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":117,"type":"SPEC","level":"MUST","comment":"A client MUST treat receipt of a push stream as a connection\nerror of type H3_ID_ERROR when no MAX_PUSH_ID frame has been sent or\nwhen the stream references a push ID that is greater than the maximum\npush ID.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":126,"type":"SPEC","level":"MUST","comment":"When the\nsame push ID is promised on multiple request streams, the\ndecompressed request field sections MUST contain the same fields in\nthe same order, and both the name and the value in each field MUST be\nidentical.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":136,"type":"SPEC","level":"MAY","comment":"A server MAY push requests that have\nthe following properties:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":143,"type":"SPEC","level":"MUST","comment":"The server MUST include a value in the :authority pseudo-header field\nfor which the server is authoritative.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":150,"type":"SPEC","level":"MUST","comment":"If the client has not yet\nvalidated the connection for the origin indicated by the pushed\nrequest, it MUST perform the same verification process it would do\nbefore sending a request for that origin on the connection; see\nSection 3.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":160,"type":"SPEC","level":"MUST","comment":"If this verification fails, the client MUST NOT\nconsider the server authoritative for that origin.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":167,"type":"SPEC","level":"SHOULD","comment":"Clients SHOULD send a CANCEL_PUSH frame upon receipt of a\nPUSH_PROMISE frame carrying a request that is not cacheable, is not\nknown to be safe, that indicates the presence of request content, or\nfor which it does not consider the server authoritative.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":176,"type":"SPEC","level":"MUST","comment":"Any\ncorresponding responses MUST NOT be used or cached.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":183,"type":"SPEC","level":"MAY","comment":"These\nassociations do not affect the operation of the protocol, but they\nMAY be considered by user agents when deciding how to use pushed\nresources.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":192,"type":"SPEC","level":"SHOULD","comment":"The server SHOULD send PUSH_PROMISE frames\nprior to sending HEADERS or DATA frames that reference the promised\nresponses.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":200,"type":"SPEC","level":"SHOULD","comment":"Clients SHOULD abort reading and discard data\nalready read from push streams if no corresponding PUSH_PROMISE frame\nis processed in a reasonable amount of time.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":208,"type":"SPEC","level":"MUST","comment":"Pushed responses that are not cacheable MUST NOT be stored by any\nHTTP cache.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-4.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":215,"type":"SPEC","level":"MAY","comment":"They MAY be made available to the application\nseparately.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.1","line":24,"type":"SPEC","level":"SHOULD","comment":"HTTP/3 implementations will need to open a new HTTP/3\nconnection for new requests if the existing connection has been idle\nfor longer than the idle timeout negotiated during the QUIC\nhandshake, and they SHOULD do so if approaching the idle timeout; see\nSection 10.1 of [QUIC-TRANSPORT].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.1","line":34,"type":"SPEC","level":"MAY","comment":"A gateway MAY\nmaintain connections in anticipation of need rather than incur the\nlatency cost of connection establishment to servers.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.1","line":42,"type":"SPEC","level":"SHOULD","comment":"Servers SHOULD\nNOT actively keep connections open.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":101,"type":"SPEC","level":"MAY","comment":"This\nidentifier MAY be zero if no requests or pushes were processed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":108,"type":"SPEC","level":"SHOULD","comment":"Upon sending a GOAWAY frame, the endpoint\nSHOULD explicitly cancel (see Sections 4.1.1 and 7.2.3) any requests\nor pushes that have identifiers greater than or equal to the one\nindicated, in order to clean up transport state for the affected\nstreams.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":118,"type":"SPEC","level":"SHOULD","comment":"The endpoint SHOULD continue to do so as more requests or\npushes arrive.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":125,"type":"SPEC","level":"MUST","comment":"Endpoints MUST NOT initiate new requests or promise new pushes on the\nconnection after receipt of a GOAWAY frame from the peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":132,"type":"SPEC","level":"MAY","comment":"Clients\nMAY establish a new connection to send additional requests.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":139,"type":"SPEC","level":"MAY","comment":"Servers MAY reject individual requests on streams below the\nindicated ID if these requests were not processed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":146,"type":"SPEC","level":"SHOULD","comment":"Servers SHOULD send a GOAWAY frame when the closing of a connection\nis known in advance, even if the advance notice is small, so that the\nremote peer can know whether or not a request has been partially\nprocessed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":155,"type":"SPEC","level":"MUST","comment":"An endpoint MAY send multiple GOAWAY frames indicating different\nidentifiers, but the identifier in each frame MUST NOT be greater\nthan the identifier in any previous frame, since clients might\nalready have retried unprocessed requests on another HTTP connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":164,"type":"SPEC","level":"MUST","comment":"Receiving a GOAWAY containing a larger identifier than previously\nreceived MUST be treated as a connection error of type H3_ID_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":171,"type":"SPEC","level":"MAY","comment":"Like the server,\nthe client MAY send subsequent GOAWAY frames so long as the specified\npush ID is no greater than any previously sent value.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":179,"type":"SPEC","level":"MAY","comment":"Once all accepted requests and pushes have been processed, the\nendpoint can permit the connection to become idle, or it MAY initiate\nan immediate closure of the connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":187,"type":"SPEC","level":"SHOULD","comment":"An endpoint that completes a\ngraceful shutdown SHOULD use the H3_NO_ERROR error code when closing\nthe connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.3","line":21,"type":"SPEC","level":"MAY","comment":"Before closing the connection, a GOAWAY frame MAY be sent to allow\nthe client to retry some requests.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-5.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.4","line":14,"type":"SPEC","level":"MUST","comment":"If a connection terminates without a GOAWAY frame, clients MUST\nassume that any request that was sent, whether in whole or in part,\nmight have been processed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.1","line":24,"type":"SPEC","level":"SHOULD","comment":"In order to\npermit these streams to open, an HTTP/3 server SHOULD configure non-\nzero minimum values for the number of permitted streams and the\ninitial stream flow-control window.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.1","line":33,"type":"SPEC","level":"SHOULD","comment":"So as to not unnecessarily limit\nparallelism, at least 100 request streams SHOULD be permitted at a\ntime.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.1","line":41,"type":"SPEC","level":"MUST","comment":"Clients MUST treat\nreceipt of a server-initiated bidirectional stream as a connection\nerror of type H3_STREAM_CREATION_ERROR unless such an extension has\nbeen negotiated.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":32,"type":"SPEC","level":"MUST","comment":"Each side MUST initiate a single control stream at the beginning of\nthe connection and send its SETTINGS frame as the first frame on this\nstream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":40,"type":"SPEC","level":"MUST","comment":"If the first frame of the control stream is any other frame\ntype, this MUST be treated as a connection error of type\nH3_MISSING_SETTINGS.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":48,"type":"SPEC","level":"MUST","comment":"Only one control stream per peer is permitted;\nreceipt of a second stream claiming to be a control stream MUST be\ntreated as a connection error of type H3_STREAM_CREATION_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":56,"type":"SPEC","level":"MUST","comment":"The\nsender MUST NOT close the control stream, and the receiver MUST NOT\nrequest that the sender close the control stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":64,"type":"SPEC","level":"MUST","comment":"If either control\nstream is closed at any point, this MUST be treated as a connection\nerror of type H3_CLOSED_CRITICAL_STREAM.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":72,"type":"SPEC","level":"SHOULD","comment":"Because the contents of the control stream are used to manage the\nbehavior of other streams, endpoints SHOULD provide enough flow-\ncontrol credit to keep the peer's control stream from becoming\nblocked.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.2","line":37,"type":"SPEC","level":"MUST","comment":"Only servers can push; if a server receives a client-initiated push\nstream, this MUST be treated as a connection error of type\nH3_STREAM_CREATION_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.2","line":45,"type":"SPEC","level":"SHOULD","comment":"A client SHOULD NOT abort reading on a push stream prior to reading\nthe push stream header, as this could lead to disagreement between\nclient and server on which push IDs have already been consumed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.2","line":53,"type":"SPEC","level":"MUST","comment":"Each push ID MUST only be used once in a push stream header.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.2","line":59,"type":"SPEC","level":"MUST","comment":"If a\nclient detects that a push stream header includes a push ID that was\nused in another push stream header, the client MUST treat this as a\nconnection error of type H3_ID_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.3","line":19,"type":"SPEC","level":"MAY","comment":"They MAY also be\nsent on connections where no data is currently being transferred.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.3","line":26,"type":"SPEC","level":"MUST","comment":"Endpoints MUST NOT consider these streams to have any meaning upon\nreceipt.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.3","line":33,"type":"SPEC","level":"MAY","comment":"When sending a reserved stream type,\nthe implementation MAY either terminate the stream cleanly or reset\nit.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.3","line":41,"type":"SPEC","level":"SHOULD","comment":"When resetting the stream, either the H3_NO_ERROR error code or\na reserved error code (Section 8.1) SHOULD be used.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":73,"type":"SPEC","level":"MUST","comment":"Therefore, the transport parameters sent by both clients\nand servers MUST allow the peer to create at least three\nunidirectional streams.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":81,"type":"SPEC","level":"SHOULD","comment":"These transport parameters SHOULD also\nprovide at least 1,024 bytes of flow-control credit to each\nunidirectional stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":89,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD create the HTTP control stream as well as the\nunidirectional streams required by mandatory extensions (such as the\nQPACK encoder and decoder streams) first, and then create additional\nstreams as allowed by their peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":98,"type":"SPEC","level":"MUST","comment":"Recipients of unknown stream types MUST\neither abort reading of the stream or discard incoming data without\nfurther processing.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":106,"type":"SPEC","level":"SHOULD","comment":"If reading is aborted, the recipient SHOULD use\nthe H3_STREAM_CREATION_ERROR error code or a reserved error code\n(Section 8.1).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":114,"type":"SPEC","level":"MUST","comment":"The recipient MUST NOT consider unknown stream types\nto be a connection error of any kind.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":121,"type":"SPEC","level":"SHOULD","comment":"As certain stream types can affect connection state, a recipient\nSHOULD NOT discard data from incoming unidirectional streams prior to\nreading the stream type.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":129,"type":"SPEC","level":"MAY","comment":"Implementations MAY send stream types before knowing whether the peer\nsupports them.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":136,"type":"SPEC","level":"MUST","comment":"However, stream types that could modify the state or\nsemantics of existing protocol components, including QPACK or other\nextensions, MUST NOT be sent until the peer is known to support them.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-6.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":144,"type":"SPEC","level":"MUST","comment":"A receiver MUST tolerate unidirectional streams being\nclosed or reset prior to the reception of the unidirectional stream\nheader.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":37,"type":"SPEC","level":"MUST","comment":"Each frame's payload MUST contain exactly the fields identified in\nits description.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":44,"type":"SPEC","level":"MUST","comment":"A frame payload that contains additional bytes\nafter the identified fields or a frame payload that terminates before\nthe end of the identified fields MUST be treated as a connection\nerror of type H3_FRAME_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":53,"type":"SPEC","level":"MUST","comment":"In particular, redundant length\nencodings MUST be verified to be self-consistent; see Section 10.8.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":60,"type":"SPEC","level":"MUST","comment":"When a stream terminates cleanly, if the last frame on the stream was\ntruncated, this MUST be treated as a connection error of type\nH3_FRAME_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.1","line":20,"type":"SPEC","level":"MUST","comment":"DATA frames MUST be associated with an HTTP request or response.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.1","line":26,"type":"SPEC","level":"MUST","comment":"If\na DATA frame is received on a control stream, the recipient MUST\nrespond with a connection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.2","line":20,"type":"SPEC","level":"MUST","comment":"If a HEADERS frame is received on a control stream, the recipient\nMUST respond with a connection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":61,"type":"SPEC","level":"SHOULD","comment":"The server SHOULD\nabort sending the resource, but the mechanism to do so depends on the\nstate of the corresponding push stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":69,"type":"SPEC","level":"SHOULD","comment":"If the push stream is\nopen, the server SHOULD abruptly terminate that stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":76,"type":"SPEC","level":"MAY","comment":"If the push\nstream has already ended, the server MAY still abruptly terminate the\nstream or MAY take no action.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":84,"type":"SPEC","level":"SHOULD","comment":"Regardless of\nwhether a push stream has been opened, a server SHOULD send a\nCANCEL_PUSH frame when it determines that promise will not be\nfulfilled.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":93,"type":"SPEC","level":"SHOULD","comment":"A client SHOULD NOT send a CANCEL_PUSH frame\nwhen it has already received a corresponding push stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":100,"type":"SPEC","level":"SHOULD","comment":"The\nclient SHOULD abort reading the stream with an error code of\nH3_REQUEST_CANCELLED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":108,"type":"SPEC","level":"MUST","comment":"Receiving a\nCANCEL_PUSH frame on a stream other than the control stream MUST be\ntreated as a connection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":116,"type":"SPEC","level":"MUST","comment":"If a CANCEL_PUSH frame is received that\nreferences a push ID greater than currently allowed on the\nconnection, this MUST be treated as a connection error of type\nH3_ID_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":125,"type":"SPEC","level":"MUST","comment":"If a server receives a CANCEL_PUSH frame for a push\nID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST\nbe treated as a connection error of type H3_ID_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.1","line":29,"type":"SPEC","level":"SHOULD","comment":"Endpoints SHOULD include at least one such setting in their\nSETTINGS frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.1","line":36,"type":"SPEC","level":"MUST","comment":"Endpoints MUST NOT consider such settings to have\nany meaning upon receipt.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.1","line":43,"type":"SPEC","level":"MUST","comment":"These reserved settings MUST NOT be sent, and\ntheir receipt MUST be treated as a connection error of type\nH3_SETTINGS_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":62,"type":"SPEC","level":"MUST","comment":"An HTTP implementation MUST NOT send frames or requests that would be\ninvalid based on its current understanding of the peer's settings.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":69,"type":"SPEC","level":"SHOULD","comment":"Each endpoint SHOULD use\nthese initial values to send messages before the peer's SETTINGS\nframe has arrived, as packets carrying the settings can be lost or\ndelayed.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":78,"type":"SPEC","level":"MUST","comment":"Endpoints MUST NOT require any data to be received from\nthe peer prior to sending the SETTINGS frame; settings MUST be sent\nas soon as the transport is ready to send data.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":86,"type":"SPEC","level":"SHOULD","comment":"Clients SHOULD\nNOT wait indefinitely for SETTINGS to arrive before sending requests,\nbut they SHOULD process received datagrams in order to increase the\nlikelihood of processing SETTINGS before sending the first request.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":95,"type":"SPEC","level":"SHOULD","comment":"Clients\nSHOULD store the settings the server provided in the HTTP/3\nconnection where resumption information was provided, but they MAY\nopt not to store settings in certain cases (e.g., if the session\nticket is received before the SETTINGS frame).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":105,"type":"SPEC","level":"MUST","comment":"A client MUST comply\nwith stored settings -- or default values if no values are stored --\nwhen attempting 0-RTT.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":113,"type":"SPEC","level":"MUST","comment":"Once a server has provided new settings,\nclients MUST comply with those values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":120,"type":"SPEC","level":"MUST","comment":"If the\nserver cannot determine that the settings remembered by a client are\ncompatible with its current settings, it MUST NOT accept 0-RTT data.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":128,"type":"SPEC","level":"MAY","comment":"A server MAY accept 0-RTT and subsequently provide different settings\nin its SETTINGS frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":135,"type":"SPEC","level":"MUST","comment":"If 0-RTT data is accepted by the server, its\nSETTINGS frame MUST NOT reduce any limits or alter any values that\nmight be violated by the client with its 0-RTT data.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":143,"type":"SPEC","level":"MUST","comment":"The server MUST\ninclude all settings that differ from their default values.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":150,"type":"SPEC","level":"MUST","comment":"If a\nserver accepts 0-RTT but then sends settings that are not compatible\nwith the previously specified settings, this MUST be treated as a\nconnection error of type H3_SETTINGS_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":159,"type":"SPEC","level":"MUST","comment":"If a server accepts\n0-RTT but then sends a SETTINGS frame that omits a setting value that\nthe client understands (apart from reserved setting identifiers) that\nwas previously specified to have a non-default value, this MUST be\ntreated as a connection error of type H3_SETTINGS_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":61,"type":"SPEC","level":"MUST","comment":"A SETTINGS frame MUST be sent as the first frame of\neach control stream (see Section 6.2.1) by each peer, and it MUST NOT\nbe sent subsequently.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":69,"type":"SPEC","level":"MUST","comment":"If an endpoint receives a second SETTINGS\nframe on the control stream, the endpoint MUST respond with a\nconnection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":77,"type":"SPEC","level":"MUST","comment":"SETTINGS frames MUST NOT be sent on any stream other than the control\nstream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":84,"type":"SPEC","level":"MUST","comment":"If an endpoint receives a SETTINGS frame on a different\nstream, the endpoint MUST respond with a connection error of type\nH3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":92,"type":"SPEC","level":"MUST","comment":"The same setting identifier MUST NOT occur more than once in the\nSETTINGS frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":99,"type":"SPEC","level":"MAY","comment":"A receiver MAY treat the presence of duplicate\nsetting identifiers as a connection error of type H3_SETTINGS_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":106,"type":"SPEC","level":"MUST","comment":"An implementation MUST ignore any parameter with an identifier it\ndoes not understand.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":60,"type":"SPEC","level":"MUST","comment":"A server MUST NOT use a push ID that is larger than the client has\nprovided in a MAX_PUSH_ID frame (Section 7.2.7).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":67,"type":"SPEC","level":"MUST","comment":"A client MUST treat\nreceipt of a PUSH_PROMISE frame that contains a larger push ID than\nthe client has advertised as a connection error of H3_ID_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":75,"type":"SPEC","level":"MAY","comment":"A server MAY use the same push ID in multiple PUSH_PROMISE frames.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":81,"type":"SPEC","level":"MUST","comment":"If so, the decompressed request header sets MUST contain the same\nfields in the same order, and both the name and the value in each\nfield MUST be exact matches.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":89,"type":"SPEC","level":"SHOULD","comment":"Clients SHOULD compare the request\nheader sections for resources promised multiple times.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":96,"type":"SPEC","level":"MUST","comment":"If a client\nreceives a push ID that has already been promised and detects a\nmismatch, it MUST respond with a connection error of type\nH3_GENERAL_PROTOCOL_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":105,"type":"SPEC","level":"SHOULD","comment":"If the decompressed field sections match\nexactly, the client SHOULD associate the pushed content with each\nstream on which a PUSH_PROMISE frame was received.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":113,"type":"SPEC","level":"SHOULD","comment":"A server SHOULD\navoid reusing a push ID over a long period.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":120,"type":"SPEC","level":"MUST","comment":"If a PUSH_PROMISE frame is received on the control stream, the client\nMUST respond with a connection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":127,"type":"SPEC","level":"MUST","comment":"A client MUST NOT send a PUSH_PROMISE frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":133,"type":"SPEC","level":"MUST","comment":"A server MUST treat the\nreceipt of a PUSH_PROMISE frame as a connection error of type\nH3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.6","line":35,"type":"SPEC","level":"MUST","comment":"A client MUST treat receipt of a GOAWAY frame containing a stream ID\nof any other type as a connection error of type H3_ID_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.6","line":42,"type":"SPEC","level":"MUST","comment":"A client MUST treat a GOAWAY frame on a stream other than\nthe control stream as a connection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.7","line":41,"type":"SPEC","level":"MUST","comment":"Receipt\nof a MAX_PUSH_ID frame on any other stream MUST be treated as a\nconnection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.7","line":49,"type":"SPEC","level":"MUST","comment":"A server MUST NOT send a MAX_PUSH_ID frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.7","line":55,"type":"SPEC","level":"MUST","comment":"A client MUST treat the\nreceipt of a MAX_PUSH_ID frame as a connection error of type\nH3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.7","line":63,"type":"SPEC","level":"MUST","comment":"A MAX_PUSH_ID frame cannot reduce the maximum push\nID; receipt of a MAX_PUSH_ID frame that contains a smaller value than\npreviously received MUST be treated as a connection error of type\nH3_ID_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.8","line":20,"type":"SPEC","level":"MAY","comment":"These frames have no semantics, and\nthey MAY be sent on any stream where frames are allowed to be sent.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.8","line":27,"type":"SPEC","level":"MUST","comment":"Endpoints MUST\nNOT consider these frames to have any meaning upon receipt.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-7.2.8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.8","line":34,"type":"SPEC","level":"MUST","comment":"These frame\ntypes MUST NOT be sent, and their receipt MUST be treated as a\nconnection error of type H3_FRAME_UNEXPECTED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-8.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-8.1","line":67,"type":"SPEC","level":"SHOULD","comment":"Implementations SHOULD select an error code from this space with some\nprobability when they would have sent H3_NO_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-8","line":40,"type":"SPEC","level":"MAY","comment":"An endpoint MAY choose to treat a stream error as a connection error\nunder certain circumstances, closing the entire connection in\nresponse to a condition on a single stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-8","line":48,"type":"SPEC","level":"MUST","comment":"Because new error codes can be defined without negotiation (see\nSection 9), use of an error code in an unexpected context or receipt\nof an unknown error code MUST be treated as equivalent to\nH3_NO_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":47,"type":"SPEC","level":"MUST","comment":"Implementations MUST ignore unknown or unsupported values in all\nextensible protocol elements.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":54,"type":"SPEC","level":"MUST","comment":"Implementations MUST discard data or\nabort reading on unidirectional streams that have unknown or\nunsupported types.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":62,"type":"SPEC","level":"SHOULD","comment":"However, where a known frame type is required to be in\na specific location, such as the SETTINGS frame as the first frame of\nthe control stream (see Section 6.2.1), an unknown frame type does\nnot satisfy that requirement and SHOULD be treated as an error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":71,"type":"SPEC","level":"MUST","comment":"Extensions that could change the semantics of existing protocol\ncomponents MUST be negotiated before being used.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9114/section-9.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":78,"type":"SPEC","level":"MUST","comment":"If a setting is used for extension negotiation, the default\nvalue MUST be defined in such a fashion that the extension is\ndisabled if the setting is omitted.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1.1","line":26,"type":"SPEC","level":"MUST","comment":"If the dynamic table does not contain enough room for a new entry\nwithout evicting other entries, and the entries that would be evicted\nare not evictable, the encoder MUST NOT insert that entry into the\ndynamic table (including duplicates of existing entries).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1.2","line":43,"type":"SPEC","level":"MUST","comment":"An encoder MUST limit the number of streams that could\nbecome blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all\ntimes.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1.2","line":51,"type":"SPEC","level":"MUST","comment":"If a decoder encounters more blocked streams than it promised\nto support, it MUST treat this as a connection error of type\nQPACK_DECOMPRESSION_FAILED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1.3","line":23,"type":"SPEC","level":"SHOULD","comment":"To avoid these deadlocks, an encoder SHOULD NOT write an instruction\nunless sufficient stream and connection flow-control credit is\navailable for the entire instruction.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1","line":26,"type":"SPEC","level":"MAY","comment":"An encoder MAY insert any entry in the dynamic table it chooses; it\nis not limited to field lines it is compressing.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1","line":33,"type":"SPEC","level":"MUST","comment":"An encoder MUST emit field representations in the order\nthey appear in the input field section.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":28,"type":"SPEC","level":"SHOULD","comment":"While blocked, encoded field section data SHOULD remain in the\nblocked stream's flow-control window.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":35,"type":"SPEC","level":"MUST","comment":"If it encounters a Required Insert\nCount smaller than expected, it MUST treat this as a connection error\nof type QPACK_DECOMPRESSION_FAILED; see Section 2.2.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":43,"type":"SPEC","level":"MAY","comment":"If it\nencounters a Required Insert Count larger than expected, it MAY treat\nthis as a connection error of type QPACK_DECOMPRESSION_FAILED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.2.2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.2.1","line":14,"type":"SPEC","level":"MUST","comment":"After the decoder finishes decoding a field section encoded using\nrepresentations containing dynamic table references, it MUST emit a\nSection Acknowledgment instruction (Section 4.4.1).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.2.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.2.2","line":22,"type":"SPEC","level":"MAY","comment":"A decoder with a maximum dynamic table\ncapacity (Section 3.2.3) equal to zero MAY omit sending Stream\nCancellations, because the encoder cannot have any dynamic table\nreferences.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":15,"type":"SPEC","level":"MUST","comment":"If the decoder encounters a reference in a field line representation\nto a dynamic table entry that has already been evicted or that has an\nabsolute index greater than or equal to the declared Required Insert\nCount (Section 4.5.1), it MUST treat this as a connection error of\ntype QPACK_DECOMPRESSION_FAILED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":25,"type":"SPEC","level":"MUST","comment":"If the decoder encounters a reference in an encoder instruction to a\ndynamic table entry that has already been evicted, it MUST treat this\nas a connection error of type QPACK_ENCODER_STREAM_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2","line":17,"type":"SPEC","level":"MUST","comment":"The decoder MUST emit field lines in the order their representations\nappear in the encoded field section.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.1","line":22,"type":"SPEC","level":"MUST","comment":"When the decoder encounters an invalid static table index in a field\nline representation, it MUST treat this as a connection error of type\nQPACK_DECOMPRESSION_FAILED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.1","line":30,"type":"SPEC","level":"MUST","comment":"If this index is received on the encoder\nstream, this MUST be treated as a connection error of type\nQPACK_ENCODER_STREAM_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-3.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.2","line":34,"type":"SPEC","level":"MUST","comment":"The\nencoder MUST NOT cause a dynamic table entry to be evicted unless\nthat entry is evictable; see Section 2.1.1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-3.2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.2","line":42,"type":"SPEC","level":"MUST","comment":"It is an error if the encoder attempts to add an\nentry that is larger than the dynamic table capacity; the decoder\nMUST treat this as a connection error of type\nQPACK_ENCODER_STREAM_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-3.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":32,"type":"SPEC","level":"MUST","comment":"The encoder MUST NOT set a dynamic table capacity that exceeds this\nmaximum, but it can choose to use a lower dynamic table capacity; see\nSection 4.3.1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-3.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":40,"type":"SPEC","level":"MAY","comment":"When the client's 0-RTT value of the\nSETTING is zero, the server MAY set it to a non-zero value in its\nSETTINGS frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-3.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":48,"type":"SPEC","level":"MUST","comment":"If the remembered value is non-zero, the server MUST\nsend the same non-zero value in its SETTINGS frame.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-3.2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":55,"type":"SPEC","level":"MUST","comment":"When the maximum table capacity is zero, the encoder MUST NOT insert\nentries into the dynamic table and MUST NOT send any encoder\ninstructions on the encoder stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2","line":17,"type":"SPEC","level":"MUST","comment":"Therefore, duplicate entries MUST NOT\nbe treated as an error by the decoder.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.1.1","line":13,"type":"SPEC","level":"MUST","comment":"QPACK implementations MUST be able to decode integers up to and\nincluding 62 bits long.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":36,"type":"SPEC","level":"MUST","comment":"Each endpoint\nMUST initiate, at most, one encoder stream and, at most, one decoder\nstream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":44,"type":"SPEC","level":"MUST","comment":"Receipt of a second instance of either stream type MUST be\ntreated as a connection error of type H3_STREAM_CREATION_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":51,"type":"SPEC","level":"MUST","comment":"The sender MUST NOT close either of these streams, and the receiver\nMUST NOT request that the sender close either of these streams.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":58,"type":"SPEC","level":"MUST","comment":"Closure of either unidirectional stream type MUST be treated as a\nconnection error of type H3_CLOSED_CRITICAL_STREAM.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":65,"type":"SPEC","level":"MAY","comment":"An endpoint MAY avoid creating an encoder stream if it will not be\nused (for example, if its encoder does not wish to use the dynamic\ntable or if the maximum size of the dynamic table permitted by the\npeer is zero).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":74,"type":"SPEC","level":"MAY","comment":"An endpoint MAY avoid creating a decoder stream if its decoder sets\nthe maximum capacity of the dynamic table to zero.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":81,"type":"SPEC","level":"MUST","comment":"An endpoint MUST allow its peer to create an encoder stream and a\ndecoder stream even if the connection's settings prevent their use.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.3.1","line":30,"type":"SPEC","level":"MUST","comment":"The new capacity MUST be lower than or equal to the limit described\nin Section 3.2.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.3.1","line":37,"type":"SPEC","level":"MUST","comment":"The decoder MUST treat a new dynamic table capacity\nvalue that exceeds this limit as a connection error of type\nQPACK_ENCODER_STREAM_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.3.1","line":45,"type":"SPEC","level":"MUST","comment":"This MUST NOT cause the eviction of entries that\nare not evictable; see Section 2.1.1.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.4.1","line":28,"type":"SPEC","level":"MUST","comment":"If an encoder receives a Section Acknowledgment instruction referring\nto a stream on which every encoded field section with a non-zero\nRequired Insert Count has already been acknowledged, this MUST be\ntreated as a connection error of type QPACK_DECODER_STREAM_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.4.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.4.3","line":24,"type":"SPEC","level":"MUST","comment":"An encoder that receives an Increment field equal to zero, or one\nthat increases the Known Received Count beyond what the encoder has\nsent, MUST treat this as a connection error of type\nQPACK_DECODER_STREAM_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.5.1.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.1","line":68,"type":"SPEC","level":"MUST","comment":"If the decoder encounters a value\nof EncodedInsertCount that could not have been produced by a\nconformant encoder, it MUST treat this as a connection error of type\nQPACK_DECOMPRESSION_FAILED.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.2","line":54,"type":"SPEC","level":"MUST","comment":"The value of Base MUST NOT be negative.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.5.1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.2","line":60,"type":"SPEC","level":"MUST","comment":"An endpoint MUST treat a field block\nwith a Sign bit of 1 as invalid if the value of Required Insert Count\nis less than or equal to the value of Delta Base.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.5.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.4","line":42,"type":"SPEC","level":"MUST","comment":"When\nthe 'N' bit is set, the encoded field line MUST always be encoded\nwith a literal representation.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-4.5.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.4","line":50,"type":"SPEC","level":"MUST","comment":"In particular, when a peer sends a\nfield line that it received represented as a literal field line with\nthe 'N' bit set, it MUST use a literal representation to forward this\nfield line.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-7.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.1.3","line":40,"type":"SPEC","level":"MUST","comment":"An intermediary MUST NOT re-encode a value that uses a literal\nrepresentation with the 'N' bit set with another representation that\nwould index it.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-7.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.1.3","line":48,"type":"SPEC","level":"MUST","comment":"If QPACK is used for re-encoding, a literal\nrepresentation with the 'N' bit set MUST be used.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-7.1.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.1.3","line":55,"type":"SPEC","level":"MUST","comment":"If HPACK is used\nfor re-encoding, the never-indexed literal representation (see\nSection 6.2.3 of [RFC7541]) MUST be used.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-7.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.4","line":21,"type":"SPEC","level":"SHOULD","comment":"These limits SHOULD be large\nenough to process the largest individual field the HTTP\nimplementation can be configured to accept.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9204/section-7.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.4","line":29,"type":"SPEC","level":"MUST","comment":"If an implementation encounters a value larger than it is able to\ndecode, this MUST be treated as a stream error of type\nQPACK_DECOMPRESSION_FAILED if on a request stream or a connection\nerror of the appropriate type if on the encoder or decoder stream.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":59,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send DATAGRAM frames until it has received the\nmax_datagram_frame_size transport parameter with a non-zero value\nduring the handshake (or during a previous handshake if 0-RTT is\nused).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":68,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT send DATAGRAM frames that are larger\nthan the max_datagram_frame_size value it has received from its peer.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":75,"type":"SPEC","level":"MUST","comment":"An endpoint that receives a DATAGRAM frame when it has not indicated\nsupport via the transport parameter MUST terminate the connection\nwith an error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":83,"type":"SPEC","level":"MUST","comment":"Similarly, an endpoint\nthat receives a DATAGRAM frame that is larger than the value it sent\nin its max_datagram_frame_size transport parameter MUST terminate the\nconnection with an error of type PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":92,"type":"SPEC","level":"SHOULD","comment":"For most uses of DATAGRAM frames, it is RECOMMENDED to send a value\nof 65535 in the max_datagram_frame_size transport parameter to\nindicate that this endpoint will accept any DATAGRAM frame that fits\ninside a QUIC packet.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":101,"type":"SPEC","level":"MAY","comment":"Application\nprotocols that use DATAGRAM frames MAY choose to only negotiate and\nuse them in a single direction.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":109,"type":"SPEC","level":"MAY","comment":"When clients use 0-RTT, they MAY store the value of the server's\nmax_datagram_frame_size transport parameter.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":116,"type":"SPEC","level":"MUST","comment":"When servers decide\nto accept 0-RTT data, they MUST send a max_datagram_frame_size\ntransport parameter greater than or equal to the value they sent to\nthe client in the connection where they sent them the\nNewSessionTicket message.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":126,"type":"SPEC","level":"MUST","comment":"If a client stores the value of the\nmax_datagram_frame_size transport parameter with their 0-RTT state,\nthey MUST validate that the new value of the max_datagram_frame_size\ntransport parameter sent by the server in the handshake is greater\nthan or equal to the stored value; if not, the client MUST terminate\nthe connection with error PROTOCOL_VIOLATION.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":137,"type":"SPEC","level":"MUST","comment":"Application protocols that use datagrams MUST define how they react\nto the absence of the max_datagram_frame_size transport parameter.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-5.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.1","line":27,"type":"SPEC","level":"SHOULD","comment":"QUIC implementations SHOULD present an API to applications to assign\nrelative priorities to DATAGRAM frames with respect to each other and\nto QUIC streams.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.2","line":35,"type":"SPEC","level":"SHOULD","comment":"Receivers SHOULD support\ndelaying ACK frames (within the limits specified by max_ack_delay) in\nresponse to receiving packets that only contain DATAGRAM frames,\nsince the sender takes no action if these packets are temporarily\nunacknowledged.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.2","line":45,"type":"SPEC","level":"MAY","comment":"If a sender detects that a packet containing a specific DATAGRAM\nframe might have been lost, the implementation MAY notify the\napplication that it believes the datagram was lost.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-5.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.2","line":53,"type":"SPEC","level":"MAY","comment":"Similarly, if a packet containing a DATAGRAM frame is acknowledged,\nthe implementation MAY notify the sender application that the\ndatagram was successfully transmitted and received.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-5.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.3","line":15,"type":"SPEC","level":"MAY","comment":"However, since DATAGRAM\nframes are inherently unreliable, they MAY be dropped by the receiver\nif the receiver cannot process them.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-5.4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.4","line":18,"type":"SPEC","level":"MUST","comment":"The sender MUST either delay sending the frame until\nthe controller allows it or drop the frame without sending it (at\nwhich point it MAY notify the application).\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5","line":26,"type":"SPEC","level":"SHOULD","comment":"This frame SHOULD be sent as soon as possible (as determined\nby factors like congestion control, described below) and MAY be\ncoalesced with other frames.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5","line":34,"type":"SPEC","level":"SHOULD","comment":"When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD\ndeliver the data to the application immediately, as long as it is\nable to process the frame and can store the contents in memory.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5","line":42,"type":"SPEC","level":"MUST","comment":"Like STREAM frames, DATAGRAM frames contain application data and MUST\nbe protected with either 0-RTT or 1-RTT keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9221/section-6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-6","line":21,"type":"SPEC","level":"MUST","comment":"All application data\ntransmitted with the DATAGRAM frame, like the STREAM frame, MUST be\nprotected either by 0-RTT or 1-RTT keys.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9287/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":37,"type":"SPEC","level":"SHOULD","comment":"Endpoints that receive the grease_quic_bit transport parameter from a\npeer SHOULD set the QUIC Bit to an unpredictable value unless another\nextension assigns specific meaning to the value of the bit.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9287/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":45,"type":"SPEC","level":"MAY","comment":"A client MAY also set the QUIC Bit to 0 in Initial, Handshake, or\n0-RTT packets that are sent prior to receiving transport parameters\nfrom the server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9287/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":53,"type":"SPEC","level":"MUST","comment":"However, a client MUST NOT set the QUIC Bit to 0\nunless the Initial packets it sends include a token provided by the\nserver in a NEW_TOKEN frame (Section 19.7 of [QUIC]), received less\nthan 604800 seconds (7 days) prior on a connection where the server\nalso included the grease_quic_bit transport parameter.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9287/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":63,"type":"SPEC","level":"MUST","comment":"A server MUST set the QUIC Bit to 0 only after processing transport\nparameters from a client.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9287/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":70,"type":"SPEC","level":"MUST","comment":"A server MUST NOT remember that a client\nnegotiated the extension in a previous connection and set the QUIC\nBit to 0 based on that information.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9287/section-3.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":78,"type":"SPEC","level":"MUST","comment":"An endpoint MUST NOT set the QUIC Bit to 0 without knowing whether\nthe peer supports the extension.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9287/section-3.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.2","line":33,"type":"SPEC","level":"MUST","comment":"Extensions that use the QUIC Bit MUST negotiate their use\nprior to acting on any semantic.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9287/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3","line":17,"type":"SPEC","level":"MUST","comment":"The transport parameter is sent with an empty\nvalue; an endpoint that understands this transport parameter MUST\ntreat receipt of a non-empty value of the transport parameter as a\nconnection error of type TRANSPORT_PARAMETER_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9287/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3","line":26,"type":"SPEC","level":"MUST","comment":"An endpoint that advertises the grease_quic_bit transport parameter\nMUST accept packets with the QUIC Bit set to a value of 0.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-1.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-1.2","line":29,"type":"SPEC","level":"SHOULD","comment":"Implementations can make this\nconfigurable, and a RECOMMENDED value is one minute.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":35,"type":"SPEC","level":"MUST","comment":"This packet SHALL include each entry\nfrom the server's set of Offered Versions (see Section 5) in a\nSupported Version field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":43,"type":"SPEC","level":"MAY","comment":"The server MAY add reserved versions (as\ndefined in Section 6.3 of [QUIC]) in Supported Version fields.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":50,"type":"SPEC","level":"MUST","comment":"Upon receiving the Version Negotiation packet, the client SHALL\nsearch for a version it supports in the list provided by the server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":57,"type":"SPEC","level":"MUST","comment":"If it doesn't find one, it SHALL abort the connection attempt.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":63,"type":"SPEC","level":"MUST","comment":"Otherwise, it SHALL select a mutually supported version and send a\nnew first flight with that version -- this version is now the\nNegotiated Version.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":71,"type":"SPEC","level":"MUST","comment":"Clients\nMUST NOT send Version Negotiation packets and servers MUST ignore all\nreceived Version Negotiation packets.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.2","line":49,"type":"SPEC","level":"MUST","comment":"Implementations MUST NOT assume compatibility\nbetween versions unless explicitly specified.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":77,"type":"SPEC","level":"MUST","comment":"In order to perform compatible version negotiation, the server MUST\nselect one of these versions that it (1) supports and (2) knows the\nclient's Chosen Version is compatible with.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":85,"type":"SPEC","level":"MUST","comment":"If the first flight is correctly\nformatted, then this conversion process cannot fail by definition of\nthe first flight being compatible; if the server is unable to convert\nthe first flight, it MUST abort the handshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":94,"type":"SPEC","level":"MUST","comment":"If a document specifies that a QUIC version is compatible with\nanother, that document MUST specify the mechanism by which clients\nare made aware of the Negotiated Version.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":102,"type":"SPEC","level":"SHOULD","comment":"Mutually compatible versions SHOULD use the same mechanism.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":108,"type":"SPEC","level":"MUST","comment":"In particular, if the Negotiated Version\nmandates that endpoints perform validations on Handshake packets,\nendpoints MUST also perform such validations on the converted first\nflight.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.5","line":20,"type":"SPEC","level":"SHOULD","comment":"When the client picks its Original Version, it SHOULD try to avoid\nincompatible version negotiation to save a round trip.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.5","line":27,"type":"SPEC","level":"SHOULD","comment":"Therefore,\nthe client SHOULD pick an Original Version to maximize the combined\nprobability that both:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2","line":39,"type":"SPEC","level":"MAY","comment":"If the server can parse the first flight, it can establish the\nconnection using the client's Chosen Version, or it MAY select any\nother compatible version, as described in Section 2.3.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":55,"type":"SPEC","level":"MUST","comment":"Any version of QUIC that supports this mechanism MUST provide a\nmechanism to exchange Version Information in both directions during\nthe handshake, such that this data is authenticated.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":63,"type":"SPEC","level":"MUST","comment":"Note that the\nversion in the Chosen Version field MUST be included in this list\nto allow the client to communicate the Chosen Version's\npreference.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":72,"type":"SPEC","level":"MAY","comment":"Note that this preference is only advisory; servers\nMAY choose to use their own preference instead.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":79,"type":"SPEC","level":"MAY","comment":"For the same reason, the\nAvailable Versions field MAY be empty.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":86,"type":"SPEC","level":"MAY","comment":"Clients and servers MAY both include versions following the pattern\n0x?a?a?a?a in their Available Versions list.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":124,"type":"SPEC","level":"MUST","comment":"Clients MUST ignore any received Version Negotiation packets that\ncontain the Original Version.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":131,"type":"SPEC","level":"MUST","comment":"A client that makes a connection\nattempt based on information received from a Version Negotiation\npacket MUST ignore any Version Negotiation packets it receives in\nresponse to that connection attempt.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":140,"type":"SPEC","level":"MUST","comment":"Both endpoints MUST parse their peer's Version Information during the\nhandshake.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":147,"type":"SPEC","level":"MUST","comment":"If that leads to a parsing failure (for example, if it is\ntoo short or if its length is not divisible by four), then the\nendpoint MUST close the connection; if the connection was using QUIC\nversion 1, that connection closure MUST use a transport error of type\nTRANSPORT_PARAMETER_ERROR.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":157,"type":"SPEC","level":"MUST","comment":"If an endpoint receives a Chosen Version\nequal to zero, or any Available Version equal to zero, it MUST treat\nit as a parsing failure.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":165,"type":"SPEC","level":"MUST","comment":"If a server receives Version Information\nwhere the Chosen Version is not included in Available Versions, it\nMUST treat it as a parsing failure.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":173,"type":"SPEC","level":"MUST","comment":"Every QUIC version that supports version negotiation MUST define a\nmethod for closing the connection with a version negotiation error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":180,"type":"SPEC","level":"MUST","comment":"When the server then processes the client's Version\nInformation, the server MUST validate that the client's Chosen\nVersion matches the version in use for the connection.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":188,"type":"SPEC","level":"MUST","comment":"If the two\ndiffer, the server MUST close the connection with a version\nnegotiation error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":196,"type":"SPEC","level":"MUST","comment":"Subsequently,\nif the server receives the client's Version Information over QUIC\nversion 1 (as indicated by the Version field of the Long Header\npackets that carried the transport parameters) and the client's\nChosen Version is not set to 0x00000001, the server MUST close the\nconnection with a version negotiation error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":207,"type":"SPEC","level":"MAY","comment":"Servers MAY complete the handshake even if the Version Information is\nmissing.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":214,"type":"SPEC","level":"MUST","comment":"Clients MUST NOT complete the handshake if they are\nreacting to a Version Negotiation packet and the Version Information\nis missing, but MAY do so otherwise.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":222,"type":"SPEC","level":"MUST","comment":"If a client receives Version Information where the server's Chosen\nVersion was not sent by the client as part of its Available Versions,\nthe client MUST close the connection with a version negotiation\nerror.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":231,"type":"SPEC","level":"MUST","comment":"If a client has reacted to a Version Negotiation packet and\nthe server's Version Information was missing, the client MUST close\nthe connection with a version negotiation error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":239,"type":"SPEC","level":"MUST","comment":"If the client received and acted on a Version Negotiation packet, the\nclient MUST validate the server's Available Versions field.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":246,"type":"SPEC","level":"MUST","comment":"If the client would have selected a different\nversion, the client MUST close the connection with a version\nnegotiation error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":254,"type":"SPEC","level":"MUST","comment":"In particular, if the client reacted to a Version\nNegotiation packet and the server's Available Versions field is\nempty, the client MUST close the connection with a version\nnegotiation error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":263,"type":"SPEC","level":"MUST","comment":"In particular, since the client can be made aware of the\nNegotiated Version by the QUIC long header version during compatible\nversion negotiation (see Section 2.3), clients MUST validate that the\nserver's Chosen Version is equal to the Negotiated Version; if they\ndo not match, the client MUST close the connection with a version\nnegotiation error.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-5","line":79,"type":"SPEC","level":"SHOULD","comment":"To avoid that,\nserver operators SHOULD perform a three-step process when they wish\nto add or remove support for a version, as described below.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-6","line":33,"type":"SPEC","level":"MUST","comment":"A given ALPN token MUST NOT be used with a new QUIC version that is\ndifferent from the version for which the ALPN token was originally\ndefined, unless all the following requirements are met:\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-6.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-6","line":41,"type":"SPEC","level":"MUST","comment":"When incompatible version negotiation is in use, the second\nconnection that is created in response to the received Version\nNegotiation packet MUST restart its application-layer protocol\nnegotiation process without taking into account the Original Version.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-7.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-7.1","line":24,"type":"SPEC","level":"MUST","comment":"If a future document wishes to define compatibility between two\nversions that support Retry, that document MUST specify how version\nnegotiation (both compatible and incompatible) interacts with Retry\nduring a handshake that requires both.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-7.2.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-7.2","line":13,"type":"SPEC","level":"SHOULD","comment":"New versions that also use\nTLS 1.3 SHOULD mandate that their session tickets are tightly scoped\nto one version of QUIC, i.e., require that clients not use them\nacross multiple version and that servers validate this client\nrequirement.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-7.3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-7.3","line":14,"type":"SPEC","level":"MUST","comment":"If a future document\nwishes to define compatibility between two versions that support\n0-RTT, that document MUST address the scenario where there are 0-RTT\npackets in the client's first flight.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-7.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-7","line":14,"type":"SPEC","level":"SHOULD","comment":"In order to facilitate the deployment of future versions of QUIC,\ndesigners of future versions SHOULD attempt to design their new\nversion such that commonly deployed versions are compatible with it.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-8","line":20,"type":"SPEC","level":"MUST","comment":"Because QUIC version 1 was the only QUIC version that was published\non the IETF Standards Track before this document, it is handled\nspecially as follows: if a client is starting a QUIC version 1\nconnection in response to a received Version Negotiation packet and\nthe version_information transport parameter is missing from the\nserver's transport parameters, then the client SHALL proceed as if\nthe server's transport parameters contained a version_information\ntransport parameter with a Chosen Version set to 0x00000001 and an\nAvailable Version list containing exactly one version set to\n0x00000001.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9368/section-8.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-8","line":35,"type":"SPEC","level":"MUST","comment":"Note that implementations that\nwish to use version negotiation to negotiate versions other than QUIC\nversion 1 MUST implement the version negotiation mechanism defined in\nthis document.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-3.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":10,"type":"SPEC","level":"MUST","comment":"Except for a few differences, QUIC version 2 endpoints MUST implement\nthe QUIC version 1 specification as described in [QUIC], [QUIC-TLS],\nand [QUIC-RECOVERY].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":54,"type":"SPEC","level":"MUST","comment":"If the server sends a Retry packet, it MUST use the original version.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":60,"type":"SPEC","level":"MUST","comment":"The client\nMUST NOT use a different version in the subsequent Initial packet\nthat contains the Retry token.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":68,"type":"SPEC","level":"MAY","comment":"The server MAY encode the QUIC\nversion in its Retry token to validate that the client did not switch\nversions, and drop the packet if it switched, to enforce client\ncompliance.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":77,"type":"SPEC","level":"MUST","comment":"After switching to a negotiated version\nafter a Retry, the server MUST include the relevant transport\nparameters to validate that the server sent the Retry and the\nconnection IDs used in the exchange, as described in Section 7.3 of\n[QUIC].\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":87,"type":"SPEC","level":"MUST","comment":"The server MUST send all CRYPTO\nframes using the negotiated version.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":94,"type":"SPEC","level":"SHOULD","comment":"Once the client has learned the negotiated version, it SHOULD send\nsubsequent Initial packets using that version.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":101,"type":"SPEC","level":"MUST","comment":"The server MUST NOT\ndiscard its original version Initial receive keys until it\nsuccessfully processes a Handshake packet with the negotiated\nversion.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":110,"type":"SPEC","level":"MUST","comment":"Both endpoints MUST send Handshake and 1-RTT packets using the\nnegotiated version.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":117,"type":"SPEC","level":"MUST","comment":"An endpoint MUST drop packets using any other\nversion.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":124,"type":"SPEC","level":"MUST","comment":"The client MUST NOT send 0-RTT packets using the negotiated version,\neven after processing a packet of that version from the server.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4","line":28,"type":"SPEC","level":"SHOULD","comment":"As\nthis mechanism does not currently distinguish between QUIC versions,\nHTTP servers SHOULD support multiple versions to reduce the\nprobability of incompatibility and the cost associated with QUIC\nversion negotiation or TCP fallback.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4","line":38,"type":"SPEC","level":"MUST","comment":"Any QUIC endpoint that supports QUIC version 2 MUST send, process,\nand validate the version_information transport parameter specified in\n[QUIC-VN] to prevent version downgrade attacks.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-4.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4","line":46,"type":"SPEC","level":"SHOULD","comment":"Endpoints that support both\nversions SHOULD support compatible version negotiation to avoid a\nround trip.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-5","line":23,"type":"SPEC","level":"MUST","comment":"Clients MUST NOT use a\nsession ticket or token from a QUIC version 1 connection to initiate\na QUIC version 2 connection, and vice versa.\n"},{"source":".duvet/requirements/www.rfc-editor.org/rfc/rfc9369/section-5.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-5","line":31,"type":"SPEC","level":"MUST","comment":"Servers MUST validate the originating version of any session ticket\nor token and not accept one issued from a different version.\n"},{"source":".duvet/todos/rfc9001/alpn-version.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":3,"type":"TODO","comment":"Client-side ALPN failure mapping and application-protocol QUIC-version compatibility policy are not yet fully implemented or tested.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/41","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/alpn-version.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":17,"type":"TODO","comment":"Client-side ALPN failure mapping and application-protocol QUIC-version compatibility policy are not yet fully implemented or tested.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/41","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/alpn-version.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":30,"type":"TODO","comment":"Client-side ALPN failure mapping and application-protocol QUIC-version compatibility policy are not yet fully implemented or tested.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/41","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/future-version.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.4","line":3,"type":"TODO","comment":"This requirement applies to future QUIC versions or future header-protection variants and is tracked as future-version work.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/43","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/future-version.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.6","line":16,"type":"TODO","comment":"This requirement applies to future QUIC versions or future header-protection variants and is tracked as future-version work.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/43","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.2","line":3,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.3","line":16,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.3","line":30,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.3","line":44,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.4","line":59,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.3","line":73,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9","line":88,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9","line":101,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4","line":113,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/handshake-crypto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.1","line":127,"type":"TODO","comment":"Handshake CRYPTO progression, partial ClientHello buffering, packetization, padding, and coalescing behavior needs implementation or stronger proof before these RFC 9001 requirements can be annotated as complete.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/37","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/initial-side-channel.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-7","line":3,"type":"TODO","comment":"Initial-packet trust boundaries, ClientHello padding, and packet-protection side-channel properties need an explicit implementation audit and tests where practical.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/42","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/initial-side-channel.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.3","line":17,"type":"TODO","comment":"Initial-packet trust boundaries, ClientHello padding, and packet-protection side-channel properties need an explicit implementation audit and tests where practical.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/42","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/initial-side-channel.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.5","line":30,"type":"TODO","comment":"Initial-packet trust boundaries, ClientHello padding, and packet-protection side-channel properties need an explicit implementation audit and tests where practical.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/42","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/initial-side-channel.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.5","line":45,"type":"TODO","comment":"Initial-packet trust boundaries, ClientHello padding, and packet-protection side-channel properties need an explicit implementation audit and tests where practical.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/42","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":3,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":17,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":30,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":43,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":57,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":71,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.4","line":85,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.4","line":99,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":113,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":128,"type":"TODO","comment":"1-RTT pre-handshake processing and key-update ordering/timing hardening is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":141,"type":"TODO","comment":"AEAD limit policy currently uses conservative fixed limits and does not implement packet-size-dependent higher limits.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/one-rtt-key-update.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":154,"type":"TODO","comment":"Future AEAD limit relaxations are not yet modeled in CoQUIC policy and should be considered with key-update hardening work.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/40","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":3,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":19,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.5","line":34,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.1","line":48,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.7","line":63,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.3","line":77,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6","line":91,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6","line":104,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.2","line":119,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.3","line":134,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.4","line":146,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.4","line":159,"type":"TODO","comment":"TLS policy behavior is not yet explicitly implemented or tested for these RFC 9001 requirements.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/tls-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.8","line":173,"type":"TODO","comment":"TLS alert and error-code policy is not yet explicitly documented or tested for this RFC 9001 confidentiality option.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/38","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.2","line":3,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.2","line":16,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.2","line":31,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.2","line":44,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":57,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":71,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":85,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":98,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":111,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":125,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":139,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":153,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9001/zero-rtt-replay.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.2","line":166,"type":"TODO","comment":"0-RTT rejection, retry, replay-protection, and application-profile policy needs implementation, documentation, or stronger tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/39","tags":["rfc9001"]},{"source":".duvet/todos/rfc9002/app-limited-controller.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":3,"type":"TODO","comment":"Application-limited congestion-window behavior, optional underutilization mechanisms, ACK-only loss feedback, and RFC8085 conformance policy need implementation, tests, or durable documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/50","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/app-limited-controller.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.8","line":17,"type":"TODO","comment":"Application-limited congestion-window behavior, optional underutilization mechanisms, ACK-only loss feedback, and RFC8085 conformance policy need implementation, tests, or durable documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/50","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/app-limited-controller.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.8","line":31,"type":"TODO","comment":"Application-limited congestion-window behavior, optional underutilization mechanisms, ACK-only loss feedback, and RFC8085 conformance policy need implementation, tests, or durable documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/50","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/app-limited-controller.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.8","line":45,"type":"TODO","comment":"Application-limited congestion-window behavior, optional underutilization mechanisms, ACK-only loss feedback, and RFC8085 conformance policy need implementation, tests, or durable documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/50","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/app-limited-controller.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7","line":60,"type":"TODO","comment":"Application-limited congestion-window behavior, optional underutilization mechanisms, ACK-only loss feedback, and RFC8085 conformance policy need implementation, tests, or durable documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/50","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/app-limited-controller.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7","line":75,"type":"TODO","comment":"Application-limited congestion-window behavior, optional underutilization mechanisms, ACK-only loss feedback, and RFC8085 conformance policy need implementation, tests, or durable documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/50","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/handshake-pto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":3,"type":"TODO","comment":"Handshake PTO restart, no-in-flight client probe arming, optional path-validation RTT reuse, and optional early CRYPTO retransmission policy are incomplete or not yet proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/45","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/handshake-pto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2.1","line":18,"type":"TODO","comment":"Handshake PTO restart, no-in-flight client probe arming, optional path-validation RTT reuse, and optional early CRYPTO retransmission policy are incomplete or not yet proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/45","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/handshake-pto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":35,"type":"TODO","comment":"Handshake PTO restart, no-in-flight client probe arming, optional path-validation RTT reuse, and optional early CRYPTO retransmission policy are incomplete or not yet proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/45","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/handshake-pto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":50,"type":"TODO","comment":"Handshake PTO restart, no-in-flight client probe arming, optional path-validation RTT reuse, and optional early CRYPTO retransmission policy are incomplete or not yet proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/45","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/handshake-pto.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.3","line":66,"type":"TODO","comment":"Handshake PTO restart, no-in-flight client probe arming, optional path-validation RTT reuse, and optional early CRYPTO retransmission policy are incomplete or not yet proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/45","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/loss-ignore.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.4","line":3,"type":"TODO","comment":"Loss-ignore policy around peer packet protection key availability and earliest-acknowledged packet boundaries is incomplete or not yet proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/48","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/loss-ignore.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.4","line":18,"type":"TODO","comment":"Loss-ignore policy around peer packet protection key availability and earliest-acknowledged packet boundaries is incomplete or not yet proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/48","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/path-cwnd.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.2","line":3,"type":"TODO","comment":"Live congestion-window behavior for max_datagram_size changes is incomplete or not yet proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/47","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/path-cwnd.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.2","line":17,"type":"TODO","comment":"Live congestion-window behavior for max_datagram_size changes is incomplete or not yet proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/47","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/persistent-congestion.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":3,"type":"TODO","comment":"Persistent congestion cross-packet-space scope is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/49","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/persistent-congestion.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":18,"type":"TODO","comment":"Persistent congestion cross-packet-space scope is incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/49","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/pto-probes.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":3,"type":"TODO","comment":"PTO probe content and PTO expiration loss semantics need stronger implementation, tests, or durable policy documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/46","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/pto-probes.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":16,"type":"TODO","comment":"PTO probe content and PTO expiration loss semantics need stronger implementation, tests, or durable policy documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/46","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/pto-probes.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":30,"type":"TODO","comment":"PTO probe content and PTO expiration loss semantics need stronger implementation, tests, or durable policy documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/46","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/pto-probes.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":45,"type":"TODO","comment":"PTO probe content and PTO expiration loss semantics need stronger implementation, tests, or durable policy documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/46","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/pto-probes.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2","line":59,"type":"TODO","comment":"PTO probe content and PTO expiration loss semantics need stronger implementation, tests, or durable policy documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/46","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/pto-probes.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.3","line":73,"type":"TODO","comment":"PTO probe content and PTO expiration loss semantics need stronger implementation, tests, or durable policy documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/46","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/pto-probes.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.3","line":88,"type":"TODO","comment":"PTO probe content and PTO expiration loss semantics need stronger implementation, tests, or durable policy documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/46","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/rtt-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":3,"type":"TODO","comment":"RTT estimation edge policies around min_rtt refresh, pre-confirmation ACK delay, Initial ACK delay, and local delay compensation are incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/44","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/rtt-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":17,"type":"TODO","comment":"RTT estimation edge policies around min_rtt refresh, pre-confirmation ACK delay, Initial ACK delay, and local delay compensation are incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/44","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/rtt-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":32,"type":"TODO","comment":"RTT estimation edge policies around min_rtt refresh, pre-confirmation ACK delay, Initial ACK delay, and local delay compensation are incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/44","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/rtt-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":47,"type":"TODO","comment":"RTT estimation edge policies around min_rtt refresh, pre-confirmation ACK delay, Initial ACK delay, and local delay compensation are incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/44","tags":["rfc9002"]},{"source":".duvet/todos/rfc9002/rtt-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":62,"type":"TODO","comment":"RTT estimation edge policies around min_rtt refresh, pre-confirmation ACK delay, Initial ACK delay, and local delay compensation are incomplete or not yet proven by tests and source annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/44","tags":["rfc9002"]},{"source":".duvet/todos/rfc9114/connect.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":3,"type":"TODO","comment":"HTTP/3 CONNECT construction, extension-frame, half-close, TCP tunnel teardown, and proxy safety behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/54","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connect.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":16,"type":"TODO","comment":"HTTP/3 CONNECT construction, extension-frame, half-close, TCP tunnel teardown, and proxy safety behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/54","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connect.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":30,"type":"TODO","comment":"HTTP/3 CONNECT construction, extension-frame, half-close, TCP tunnel teardown, and proxy safety behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/54","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connect.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":45,"type":"TODO","comment":"HTTP/3 CONNECT construction, extension-frame, half-close, TCP tunnel teardown, and proxy safety behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/54","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connect.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":58,"type":"TODO","comment":"HTTP/3 CONNECT construction, extension-frame, half-close, TCP tunnel teardown, and proxy safety behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/54","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connect.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":72,"type":"TODO","comment":"HTTP/3 CONNECT construction, extension-frame, half-close, TCP tunnel teardown, and proxy safety behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/54","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connect.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":87,"type":"TODO","comment":"HTTP/3 CONNECT construction, extension-frame, half-close, TCP tunnel teardown, and proxy safety behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/54","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connect.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":101,"type":"TODO","comment":"HTTP/3 CONNECT construction, extension-frame, half-close, TCP tunnel teardown, and proxy safety behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/54","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":3,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.1","line":19,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.1","line":35,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.1","line":49,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":62,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":75,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":91,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":104,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":117,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":130,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":145,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":159,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":173,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.3","line":187,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/connection-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.4","line":200,"type":"TODO","comment":"HTTP/3 connection lifecycle, idle-timeout, GOAWAY, graceful shutdown, and request-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/56","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/frame-validation.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":3,"type":"TODO","comment":"HTTP/3 frame length, redundant encoding, and frame-placement edge cases need implementation, tests, or stronger Duvet annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/60","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/frame-validation.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":16,"type":"TODO","comment":"HTTP/3 frame length, redundant encoding, and frame-placement edge cases need implementation, tests, or stronger Duvet annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/60","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/frame-validation.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":30,"type":"TODO","comment":"HTTP/3 frame length, redundant encoding, and frame-placement edge cases need implementation, tests, or stronger Duvet annotations.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/60","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":3,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":17,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":31,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":44,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.1","line":58,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":73,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":87,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":101,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":114,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.2","line":127,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.3","line":142,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.3","line":155,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.3","line":168,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.4","line":183,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.4","line":196,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/iana-registries.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-11.2.4","line":210,"type":"TODO","comment":"HTTP/3 IANA registry, extension registration, and reserved codepoint policy need durable contributor documentation and validation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/61","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":3,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":17,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":30,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.1","line":43,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.1","line":57,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":74,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":87,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":102,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":117,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":131,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/message-mapping.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":146,"type":"TODO","comment":"HTTP/3 message mapping, malformed-message forwarding, Cookie handling, lowercase field generation, and HTTP/1.x translation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/53","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1.1","line":3,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1.2","line":18,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":31,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":46,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":61,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":78,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.1","line":92,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":106,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":120,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":133,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":148,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":162,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":175,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":189,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":203,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":218,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/origin.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.3","line":233,"type":"TODO","comment":"HTTP/3 origin authority, Alt-Svc discovery, SNI, certificate validation, fallback, and connection reuse policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/51","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":3,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":16,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":30,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":43,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":56,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":69,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":83,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":96,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":110,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":124,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":137,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.1","line":151,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":168,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":182,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":196,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":210,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":225,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":239,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/request-lifecycle.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":253,"type":"TODO","comment":"HTTP/3 request cancellation, retry, stream-abort, partial-response, and response-disposition behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/52","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/security-errors.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.5","line":3,"type":"TODO","comment":"HTTP/3 excessive-load, compression confidentiality, unknown error-code, and reserved error-code policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/59","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/security-errors.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.5","line":16,"type":"TODO","comment":"HTTP/3 excessive-load, compression confidentiality, unknown error-code, and reserved error-code policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/59","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/security-errors.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.6","line":31,"type":"TODO","comment":"HTTP/3 excessive-load, compression confidentiality, unknown error-code, and reserved error-code policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/59","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/security-errors.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.6","line":46,"type":"TODO","comment":"HTTP/3 excessive-load, compression confidentiality, unknown error-code, and reserved error-code policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/59","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/security-errors.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-8.1","line":59,"type":"TODO","comment":"HTTP/3 excessive-load, compression confidentiality, unknown error-code, and reserved error-code policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/59","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/security-errors.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-8","line":72,"type":"TODO","comment":"HTTP/3 excessive-load, compression confidentiality, unknown error-code, and reserved error-code policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/59","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/security-errors.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-8","line":86,"type":"TODO","comment":"HTTP/3 excessive-load, compression confidentiality, unknown error-code, and reserved error-code policy need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/59","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.4","line":3,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":17,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":30,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":43,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":59,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":72,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":85,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":101,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":114,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":129,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":142,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":157,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":171,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":185,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":198,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":211,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":225,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":238,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":252,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":267,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":280,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":294,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":306,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":320,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":333,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/server-push.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":347,"type":"TODO","comment":"HTTP/3 server push authority, cacheability, cancellation, duplicate promise, and push ID reuse behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/55","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.5.1","line":3,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.9","line":17,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.1","line":30,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":43,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":58,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":72,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":87,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":103,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":117,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":130,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":144,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":157,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":170,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/settings-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":183,"type":"TODO","comment":"HTTP/3 SETTINGS, 0-RTT compatibility, anti-replay, remembered settings, and extension negotiation defaults need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/58","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.1","line":3,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.1","line":18,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":32,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.2","line":47,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.3","line":61,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.3","line":74,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.3","line":87,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.3","line":101,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":114,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":128,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":142,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":157,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":171,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":185,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":198,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":212,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9114/stream-management.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":226,"type":"TODO","comment":"HTTP/3 stream limits, flow credit, reserved streams, unknown stream handling, and stream negotiation behavior need implementation, tests, or durable unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/57","tags":["rfc9114"]},{"source":".duvet/todos/rfc9204/flow-control.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1.3","line":2,"type":"TODO","comment":"QPACK instruction writes and blocked field-section storage need an explicit flow-control policy or implementation that avoids RFC 9204 deadlock scenarios.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/63","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/flow-control.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":16,"type":"TODO","comment":"QPACK instruction writes and blocked field-section storage need an explicit flow-control policy or implementation that avoids RFC 9204 deadlock scenarios.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/63","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/limits.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.4","line":2,"type":"TODO","comment":"QPACK literal/string/integer decode limits need a documented and tested relationship to the largest individual field the HTTP implementation can be configured to accept.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/65","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/never-index.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.4","line":2,"type":"TODO","comment":"The current HTTP/3 field model stores name/value pairs without preserving QPACK literal never-index metadata, so N-bit forwarding and intermediary re-encoding requirements need implementation or explicit unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/62","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/never-index.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.4","line":16,"type":"TODO","comment":"The current HTTP/3 field model stores name/value pairs without preserving QPACK literal never-index metadata, so N-bit forwarding and intermediary re-encoding requirements need implementation or explicit unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/62","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/never-index.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.1.3","line":31,"type":"TODO","comment":"The current HTTP/3 field model stores name/value pairs without preserving QPACK literal never-index metadata, so N-bit forwarding and intermediary re-encoding requirements need implementation or explicit unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/62","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/never-index.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.1.3","line":45,"type":"TODO","comment":"The current HTTP/3 field model stores name/value pairs without preserving QPACK literal never-index metadata, so N-bit forwarding and intermediary re-encoding requirements need implementation or explicit unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/62","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/never-index.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.1.3","line":58,"type":"TODO","comment":"The current HTTP/3 field model stores name/value pairs without preserving QPACK literal never-index metadata, so N-bit forwarding and intermediary re-encoding requirements need implementation or explicit unsupported-status documentation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/62","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/optional-compression-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1","line":2,"type":"TODO","comment":"These RFC 9204 optional QPACK behaviors need an implementation decision, tests for selected behavior, or durable documentation that coquic intentionally does not implement the option.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/64","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/optional-compression-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":15,"type":"TODO","comment":"These RFC 9204 optional QPACK behaviors need an implementation decision, tests for selected behavior, or durable documentation that coquic intentionally does not implement the option.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/64","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/optional-compression-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.2.2","line":29,"type":"TODO","comment":"These RFC 9204 optional QPACK behaviors need an implementation decision, tests for selected behavior, or durable documentation that coquic intentionally does not implement the option.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/64","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/optional-compression-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":44,"type":"TODO","comment":"These RFC 9204 optional QPACK behaviors need an implementation decision, tests for selected behavior, or durable documentation that coquic intentionally does not implement the option.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/64","tags":["rfc9204"]},{"source":".duvet/todos/rfc9204/optional-compression-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":59,"type":"TODO","comment":"These RFC 9204 optional QPACK behaviors need an implementation decision, tests for selected behavior, or durable documentation that coquic intentionally does not implement the option.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/64","tags":["rfc9204"]},{"source":".duvet/todos/rfc9221/application-datagram-absence-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":3,"type":"TODO","comment":"Application-level DATAGRAM users need an explicit, tested policy for missing\nQUIC max_datagram_frame_size transport support.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/67","tags":["rfc9221"]},{"source":".duvet/todos/rfc9221/datagram-lifecycle-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.2","line":3,"type":"TODO","comment":"The current DATAGRAM API does not expose stable per-DATAGRAM suspected-loss\nnotifications to applications.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/68","tags":["rfc9221"]},{"source":".duvet/todos/rfc9221/datagram-lifecycle-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.2","line":18,"type":"TODO","comment":"The current DATAGRAM API does not expose stable per-DATAGRAM acknowledgement\nnotifications to applications.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/68","tags":["rfc9221"]},{"source":".duvet/todos/rfc9221/datagram-lifecycle-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.3","line":33,"type":"TODO","comment":"Receiver behavior for DATAGRAM frames that cannot be processed is not yet an\nexplicit application-facing policy with targeted tests.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/68","tags":["rfc9221"]},{"source":".duvet/todos/rfc9221/server-zero-rtt-datagram-parameter.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":3,"type":"TODO","comment":"Server-side 0-RTT acceptance does not yet persist or compare the DATAGRAM\nmax_datagram_frame_size value associated with issued session tickets, so this\nRFC 9221 continuity requirement is not implemented or proven.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/66","tags":["rfc9221"]},{"source":".duvet/todos/rfc9287/client-pre-tp-grease-quic-bit.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":3,"type":"TODO","comment":"Clients currently only grease the QUIC Bit after peer transport parameters are\nvalidated; the optional pre-transport-parameter client path based on a recent\nqualifying NEW_TOKEN is not implemented.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/69","tags":["rfc9287"]},{"source":".duvet/todos/rfc9287/quic-bit-extension-semantics.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.2","line":3,"type":"TODO","comment":"No current extension assigns semantic meaning to the QUIC Bit, and the codebase\ndoes not yet have an explicit extension-negotiation guard or policy for future\nQUIC-bit semantics.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/70","tags":["rfc9287"]},{"source":".duvet/todos/rfc9368/alpn-version-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-6","line":3,"type":"TODO","comment":"CoQUIC does not yet enforce or document an ALPN-to-QUIC-version compatibility\npolicy for introducing new QUIC versions.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/75","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/compatible-version-contract.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":3,"type":"TODO","comment":"The repository needs a durable compatibility contract for future compatible\nQUIC versions, including how clients learn the negotiated version.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/72","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/compatible-version-contract.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":18,"type":"TODO","comment":"The repository needs a durable compatibility contract for future compatible\nQUIC versions, including a common negotiated-version discovery mechanism where\npossible.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/72","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/compatible-version-contract.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":32,"type":"TODO","comment":"Converted first-flight validation requirements are not yet documented or tested\nas part of CoQUIC's future compatible-version contract.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/72","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/deployment-future-guidance.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-5","line":3,"type":"TODO","comment":"CoQUIC does not yet have durable operator guidance for RFC 9368's version\nadd/remove deployment process.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/77","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/deployment-future-guidance.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-7.2","line":18,"type":"TODO","comment":"CoQUIC does not yet document or enforce future-version session ticket scoping\nrules across QUIC versions.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/77","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/deployment-future-guidance.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-7","line":35,"type":"TODO","comment":"CoQUIC does not yet have durable contributor guidance for future-version\ncompatibility design goals.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/77","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/future-retry-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-7.1","line":3,"type":"TODO","comment":"Future compatible-version design guidance does not yet document the required\nRetry interaction rules.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/76","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/future-retry-zero-rtt.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-7.3","line":19,"type":"TODO","comment":"Future compatible-version design guidance does not yet document required\n0-RTT first-flight behavior.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/76","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/msl.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-1.2","line":3,"type":"TODO","comment":"CoQUIC does not yet expose or document an RFC 9368 Maximum Segment Lifetime\nconfiguration with the recommended one-minute default.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/71","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/original-version-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.5","line":3,"type":"TODO","comment":"Client Original Version selection is configuration-driven and does not yet\nimplement an explicit policy to avoid incompatible version negotiation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/73","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/original-version-policy.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.5","line":17,"type":"TODO","comment":"Client Original Version selection does not yet score parse probability and\ncompatibility with the preferred version.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/73","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/v1-fallback-nonv1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-8","line":3,"type":"TODO","comment":"The special QUIC v1 fallback for missing server Version Information after\nreacting to a Version Negotiation packet is not yet implemented.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/78","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/v1-fallback-nonv1.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-8","line":25,"type":"TODO","comment":"CoQUIC's non-v1 version negotiation paths need an explicit audit against the\ncomplete RFC 9368 mechanism before full support is declared.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/78","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/version-information-advertisement.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":3,"type":"TODO","comment":"CoQUIC does not yet expose or document an intentional policy for sending empty\nAvailable Versions in Version Information.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/74","tags":["rfc9368"]},{"source":".duvet/todos/rfc9368/version-information-advertisement.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":17,"type":"TODO","comment":"Reserved-version greasing is implemented for Version Negotiation packets, but\nnot yet for the Version Information Available Versions list.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/74","tags":["rfc9368"]},{"source":".duvet/todos/rfc9369/initial-key-retention.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":3,"type":"TODO","comment":"Server Handshake processing currently discards the Initial packet space after\nsuccessfully processing any server-side Handshake packet; it needs an explicit\nnegotiated-version condition for compatible version negotiation.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/79","tags":["rfc9369"]},{"source":".duvet/todos/rfc9369/server-ticket-version.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-5","line":3,"type":"TODO","comment":"NEW_TOKEN validation is version-scoped, but server-side TLS session-ticket\nacceptance does not yet appear to validate the QUIC version that issued the\nticket.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/80","tags":["rfc9369"]},{"source":".duvet/todos/rfc9369/zero-rtt-original-version.toml","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":3,"type":"TODO","comment":"Client 0-RTT packet construction currently passes current_version_ through the\napplication packet send paths; after compatible negotiation this can become the\nnegotiated version instead of the original version.\n","tracking_issue":"https://github.com/minhuw/coquic/issues/81","tags":["rfc9369"]},{"source":"include/coquic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.3","line":105},{"source":"include/coquic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":116},{"source":"include/coquic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":129},{"source":"include/coquic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":131},{"source":"include/coquic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":175},{"source":"src/http09/http09_runtime.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":481},{"source":"src/http09/http09_runtime.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":499},{"source":"src/http09/http09_runtime.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":1422},{"source":"src/http09/http09_runtime.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":1426},{"source":"src/http09/http09_runtime.h","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4","line":41},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.1","line":309},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":449},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":454},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":536},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.2","line":539},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":569},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":758},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":844},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.2","line":847},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":1101},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.5","line":1126},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":1167},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":1174},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":1573},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-3.2","line":1728},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":1732},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":1749},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":1903},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":1907},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":1966},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":1970},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.1","line":2004},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":2090},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":2094},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":2105},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.2","line":2121},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":2134},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":2137},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":2141},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":2155},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":2158},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":2162},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":2175},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2","line":2178},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.4","line":2233},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-7.4","line":2279},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.6","line":2310},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.2","line":2322},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.2","line":2324},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":2357},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":2404},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.1","line":2492},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":2499},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":2501},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.1","line":2516},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":2523},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":2587},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":2650},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":2667},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":2797},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":2824},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.2","line":2914},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":2926},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.2","line":2977},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":2989},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":2991},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":2998},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.2","line":3056},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":3076},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2.2","line":3100},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":3236},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1.2","line":3262},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-6.2.1","line":3314},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":3324},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":3335},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":3340},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":3355},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":3360},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.1","line":3370},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.2","line":3373},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":3376},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.5","line":3379},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.6","line":3383},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.7","line":3386},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-5.2","line":3401},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.7","line":3413},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":3426},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":3444},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.3","line":3455},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":3509},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":3521},{"source":"src/http3/http3_connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.2","line":3525},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.3","line":402},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":408},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.3","line":415},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-10.8","line":513},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":583},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":586},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":788},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":791},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4.1","line":797},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":812},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.6","line":819},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":847},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":850},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":860},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":876},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":902},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":919},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":940},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":955},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":968},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":993},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":996},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":1000},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.4","line":1007},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":1040},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":1048},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":1058},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.1","line":1067},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":1092},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":1095},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":1131},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":1134},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":1138},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3.2","line":1162},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.3","line":1181},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.7","line":1207},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.7","line":1209},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.8","line":1215},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":1218},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.1","line":1233},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.8","line":1237},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.8","line":1240},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.8","line":1243},{"source":"src/http3/http3_protocol.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-9","line":1246},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.1.1","line":466},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1.2","line":734},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1.1","line":769},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.2","line":774},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.2","line":804},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.2","line":815},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.1","line":892},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.1","line":908},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.1","line":921},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.1","line":932},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.2","line":983},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.2","line":994},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.2","line":996},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1018},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":1029},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1033},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":1056},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1060},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2","line":1225},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1259},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1291},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1332},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1384},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.2.1","line":1465},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1516},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1526},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1593},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.3","line":1603},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2","line":1611},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1","line":1639},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":1668},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":1726},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1.2","line":1785},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.2.1","line":1826},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.3.1","line":1859},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.3.1","line":1862},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.3.1","line":1883},{"source":"src/http3/http3_qpack.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.4.1","line":1969},{"source":"src/io/poll_io_engine.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.7","line":400},{"source":"src/io/poll_io_engine.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.7","line":404},{"source":"src/io/poll_io_engine.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":1382},{"source":"src/io/poll_io_engine.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":1399},{"source":"src/io/shared_udp_backend_core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":118},{"source":"src/io/shared_udp_backend_core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":120},{"source":"src/quic/cca/bbr.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":258},{"source":"src/quic/cca/common.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.2","line":228},{"source":"src/quic/cca/cubic.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.1","line":345},{"source":"src/quic/cca/cubic.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":410},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7","line":54},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.1","line":150},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.3","line":159},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.1","line":297},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.3","line":308},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.2","line":384},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.1","line":406},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.2","line":409},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.2","line":414},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":423},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.2","line":446},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.3.2","line":457},{"source":"src/quic/cca/newreno.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":523},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3.1","line":412},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3.1","line":446},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3.1","line":457},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.6","line":646},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.6","line":675},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":694},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":696},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":743},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":794},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":939},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":943},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.14","line":966},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1000},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1008},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1011},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.6","line":1149},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":1170},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":1199},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":1264},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":1268},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.14","line":1308},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1329},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1333},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1336},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1540},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3","line":1579},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1779},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1814},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3","line":1846},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1896},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1905},{"source":"src/quic/codec/frame.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3","line":1911},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":30},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":38},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":50},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":170},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":199},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":202},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":221},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":231},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":264},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":278},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":286},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":350},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":392},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":408},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":411},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.4","line":415},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":510},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5","line":535},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":558},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":628},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":634},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":722},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":729},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":761},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":814},{"source":"src/quic/codec/packet.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":823},{"source":"src/quic/codec/packet_number.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.1","line":67},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":430},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":500},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":576},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":579},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":582},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.3","line":626},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":629},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":636},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":639},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":642},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.4","line":668},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":4077},{"source":"src/quic/codec/protected_codec.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":4248},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":8},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":14},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":154},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":159},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.1","line":171},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":175},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":198},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":344},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":348},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.1","line":423},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":426},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":430},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.4","line":463},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":467},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.1","line":474},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":488},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.1","line":492},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2","line":496},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2","line":515},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":716},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":719},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.1","line":766},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":769},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":773},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":905},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":969},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":977},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.3","line":1035},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.21","line":1059},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":1062},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":1072},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.2","line":1117},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":1134},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1143},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":1147},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1156},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":1169},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":1179},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":1184},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":1188},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":1195},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.1","line":1199},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":1287},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.4","line":1301},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":1312},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10","line":1315},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.2","line":1318},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.2","line":1326},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":1330},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1363},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.2","line":1415},{"source":"src/quic/connection/connection.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3","line":1499},{"source":"src/quic/connection/connection_effects.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.19","line":62},{"source":"src/quic/connection/connection_effects.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":106},{"source":"src/quic/connection/connection_effects.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":137},{"source":"src/quic/connection/connection_effects.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6","line":150},{"source":"src/quic/connection/connection_effects.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":287},{"source":"src/quic/connection/connection_effects.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":292},{"source":"src/quic/connection/connection_effects.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":332},{"source":"src/quic/connection/connection_flow_control.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":67},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":44},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.2","line":283},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":295},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":300},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":324},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":344},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":348},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":364},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":389},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":433},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":437},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":453},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":483},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":492},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":497},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":534},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":553},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.2","line":587},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":599},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":604},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":678},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":760},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":764},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":773},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":778},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":894},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":919},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":928},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":932},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":935},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.4","line":946},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":986},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":1015},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.1","line":1394},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1442},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1456},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1471},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1480},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":1522},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.1","line":1619},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":1627},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":1631},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":2336},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":2347},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":2360},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":2369},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":2404},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":2415},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":2427},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":2436},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3","line":2445},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":2583},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":2601},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":2656},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":2664},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.4","line":2723},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":2733},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":2848},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":2905},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":2912},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":2917},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":2968},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5","line":3027},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":3036},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":3040},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5","line":3048},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":3304},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":3311},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":3339},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":3362},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":3437},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":3491},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-6","line":3537},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":3547},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":3551},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5","line":3559},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":3841},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":3864},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.9","line":3927},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":3931},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":3946},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.2","line":4011},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":4062},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.2","line":4091},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":4118},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":4126},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":4131},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":4154},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":4162},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":4167},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":4191},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":4198},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":4203},{"source":"src/quic/connection/connection_inbound_recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":4235},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.1","line":75},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1","line":760},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":793},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":805},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":839},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":847},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":872},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":1237},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4","line":1241},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":1247},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.2","line":1275},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1425},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1429},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1433},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":1484},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":1490},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":1579},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.2","line":1582},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":1619},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":1623},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":1671},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.21","line":1743},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.5","line":1841},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":1847},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":1851},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":1860},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":1886},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":1901},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":1905},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.2","line":1910},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":1969},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":1972},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":1990},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":1993},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":2016},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":2019},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.5","line":2123},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":2139},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":2143},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":2164},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":2168},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":2197},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":2203},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":2206},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3.1","line":2210},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.1","line":2373},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":2376},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":2579},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.1","line":2591},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.1","line":2603},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.1","line":2608},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":3070},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.7","line":3073},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":3221},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":3224},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":3227},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":3327},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":3440},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":3443},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":4249},{"source":"src/quic/connection/connection_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":4265},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":119},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":123},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":131},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2","line":135},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":139},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":158},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4","line":254},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.3","line":261},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":302},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-5","line":362},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":401},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.2","line":425},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":446},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":451},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":467},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":479},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.2","line":523},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":526},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.2","line":545},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":613},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":619},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":622},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":628},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.4","line":647},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":669},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":698},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":702},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":707},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":721},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":742},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":746},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":751},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":754},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":763},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.3","line":784},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":792},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":812},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.3","line":816},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.17","line":819},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":867},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.3","line":871},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":902},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":929},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":940},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":953},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":957},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":966},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":977},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":981},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":997},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1013},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1046},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1049},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":1076},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":1095},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1113},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1116},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1135},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":1148},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1155},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1162},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":1206},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":1218},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1238},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1247},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1269},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1","line":1273},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":1278},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1292},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1297},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1323},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":1326},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1330},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1333},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1337},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1342},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1361},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1396},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1401},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1441},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1445},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":1512},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1526},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1529},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1537},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1540},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1546},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.4","line":1605},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.4","line":1611},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.1","line":1621},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.1","line":1625},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":1628},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":1640},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":1716},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":1740},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":1747},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.1","line":1772},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":1777},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":1780},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":1783},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":1789},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":1819},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":1823},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":1827},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":1835},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.3","line":1854},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":1857},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":1869},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":1885},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.9","line":1916},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.9","line":1921},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.5","line":1939},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":2030},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":2033},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":2168},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":2368},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.9","line":2371},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.4","line":2391},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.4","line":2519},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.2","line":2554},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":2573},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":2578},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":2591},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.14","line":2594},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":2635},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":2640},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":2647},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.4","line":2652},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.13","line":2655},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":2674},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":2681},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":2685},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":2688},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":2701},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":2706},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.5","line":2745},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":2748},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.5","line":2756},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":2760},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.12","line":3249},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.2","line":3276},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.2","line":3291},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":3314},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":3350},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":3355},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":3384},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":3401},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":3404},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":3416},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":3454},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":3490},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":3493},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":3511},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":3544},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":3577},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8","line":3591},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":3643},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":3646},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":3669},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":3677},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":3706},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":3737},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":3793},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.4","line":3826},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":3917},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":3930},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":3969},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":3990},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":3993},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":4013},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":4015},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":4036},{"source":"src/quic/connection/connection_paths_streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":4043},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":16},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":24},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":135},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":158},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.2","line":743},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":784},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":787},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":796},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":801},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":968},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":972},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.2","line":978},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":1100},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1121},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":1125},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":1131},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6","line":1135},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.5","line":1289},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.1","line":1315},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.1","line":1320},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1462},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1466},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.4","line":1523},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1576},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1584},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1589},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1598},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1604},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":1663},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":1668},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":1738},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1743},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":1773},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":1809},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":1814},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1823},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":1870},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.2","line":1950},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":2008},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":2028},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":2072},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":2075},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":2093},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":2096},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":2174},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":2177},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":2208},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":2281},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":2284},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":2287},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":2289},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.1","line":2342},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.1","line":2345},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.6","line":2383},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":2474},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":2567},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":2608},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":2612},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":2622},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":2628},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":2639},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":2642},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":2646},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":2684},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.3","line":2688},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":2691},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":2728},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":3060},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":3146},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":3152},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.3","line":3450},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":3453},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":3458},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":3931},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":3939},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.7","line":3947},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.2","line":4070},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":4073},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":4185},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.3","line":4223},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.1","line":4298},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2","line":4339},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":4380},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.5","line":4597},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":4925},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.21","line":4981},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7","line":4984},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.4","line":4989},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":4997},{"source":"src/quic/connection/connection_send.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.7","line":5005},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":80},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2.1","line":113},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":144},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":151},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":155},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.4","line":236},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":263},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-7.6.2","line":339},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":383},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":498},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":524},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":536},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2.1","line":562},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":585},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":600},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":660},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":858},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":946},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.3","line":959},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.1","line":968},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":971},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":975},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":997},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.3","line":1001},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.5","line":1004},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-6.5","line":1126},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":1173},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.6","line":1240},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-5","line":1244},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1253},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":1257},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1260},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":1282},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1331},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1359},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":1389},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1418},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":1485},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.3","line":1508},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.3","line":1523},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1530},{"source":"src/quic/connection/connection_timers.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":1535},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":91},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":643},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":646},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.1","line":824},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":828},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":899},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":923},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":1185},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":1198},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":1271},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.1","line":1329},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":1543},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3","line":1552},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":1558},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3","line":1572},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":1578},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":1590},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":1598},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":1611},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1679},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.3","line":1691},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1695},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1706},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":1720},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":1735},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.3","line":1740},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":1744},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":1756},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":1760},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1804},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.3","line":1850},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1854},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1858},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1863},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1870},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1891},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1906},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1917},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.3","line":1952},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":1956},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1961},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1966},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1976},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":1979},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":2011},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-5","line":2084},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":2093},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2121},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2124},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2134},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-5","line":2139},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2150},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-5","line":2155},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2170},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2174},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-5","line":2180},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2188},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2191},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":2207},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":2211},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":2238},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":2241},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":2249},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":2258},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-6","line":2262},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":2300},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":2307},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":2311},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":2326},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":2342},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":2345},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":2360},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.3","line":2382},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":2394},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":2398},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":2408},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":2540},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":2543},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":2559},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-15","line":2577},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-15","line":2583},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-15","line":2586},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.3","line":2589},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":2593},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":2599},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":2602},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":2609},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":2644},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":2652},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":2770},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":2892},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":2896},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":2956},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.2","line":2960},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":3188},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6","line":3191},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1","line":3541},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3559},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3563},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3566},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.3","line":3648},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":3726},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":3732},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":3748},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":3766},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":3776},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":3815},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":3833},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":3844},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.1","line":3847},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":3850},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":3855},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":3858},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":3866},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":3885},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":3889},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":3899},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":3908},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":3912},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":3931},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3952},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.2","line":3966},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":4001},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":4005},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":4008},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":4092},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":4130},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":4134},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":4288},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":4359},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":4379},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":4391},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":4396},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-6","line":4400},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":4425},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":4438},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":4441},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":4449},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":4456},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":4461},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":4467},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":4477},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.2","line":4481},{"source":"src/quic/core.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":4485},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.3","line":104},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":115},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":120},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":129},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":138},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":140},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":201},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":367},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.1","line":479},{"source":"src/quic/core.h","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.1","line":488},{"source":"src/quic/crypto/crypto_stream.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4","line":163},{"source":"src/quic/crypto/crypto_stream.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9","line":166},{"source":"src/quic/crypto/crypto_stream.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":170},{"source":"src/quic/crypto/crypto_stream.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":644},{"source":"src/quic/crypto/crypto_stream.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.3","line":650},{"source":"src/quic/crypto/crypto_stream.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.1.4","line":653},{"source":"src/quic/crypto/crypto_stream.h","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4","line":275},{"source":"src/quic/crypto/packet_crypto_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.6","line":28},{"source":"src/quic/crypto/packet_crypto_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.2","line":140},{"source":"src/quic/crypto/packet_crypto_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":162},{"source":"src/quic/crypto/packet_crypto_internal.h","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.6","line":166},{"source":"src/quic/crypto/packet_crypto_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.4.1","line":1121},{"source":"src/quic/crypto/tls_adapter_boringssl.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":351},{"source":"src/quic/crypto/tls_adapter_boringssl.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":756},{"source":"src/quic/crypto/tls_adapter_boringssl.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":892},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.3","line":201},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.3","line":206},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.3","line":211},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.2","line":247},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.2","line":249},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.2","line":377},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.2","line":379},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":443},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":446},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":841},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":846},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":855},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":857},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":973},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":975},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.4","line":977},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.1","line":1012},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":1015},{"source":"src/quic/crypto/tls_adapter_quictls.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.8","line":1213},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":32},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":34},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":117},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.2","line":134},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":137},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":146},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.2","line":172},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":229},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":233},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":261},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":269},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":272},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":278},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.1","line":286},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":373},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":1616},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.1","line":2044},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.1","line":2058},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.1","line":2108},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":2141},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":2464},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":2484},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1","line":2488},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1","line":2502},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":2510},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":2526},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":2528},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.1","line":2536},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.1","line":2558},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":2577},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":2579},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":2582},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":2609},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":2613},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":2616},{"source":"src/quic/transport/recovery.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.3","line":2619},{"source":"src/quic/transport/recovery.h","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.1","line":29},{"source":"src/quic/transport/recovery.h","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.1","line":33},{"source":"src/quic/transport/recovery.h","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":37},{"source":"src/quic/transport/recovery.h","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.1.2","line":41},{"source":"src/quic/transport/recovery.h","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":45},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":205},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":207},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":211},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":216},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":284},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":287},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":316},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":339},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":342},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":366},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":399},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":425},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":428},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":434},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":439},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":448},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":487},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":491},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":507},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":510},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":580},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":589},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":593},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":609},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.13","line":670},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":674},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":738},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":741},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":771},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":780},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":783},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":785},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":801},{"source":"src/quic/transport/streams.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":836},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":131},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":154},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":202},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":326},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":329},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":386},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":503},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":506},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":539},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-3","line":542},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":549},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":567},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":589},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":618},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3","line":632},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.2","line":644},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":657},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":666},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":671},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":678},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":682},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":687},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":690},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":697},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":704},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":708},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":713},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":724},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":727},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":731},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":744},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":747},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":764},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":768},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":775},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":783},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":789},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":795},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":800},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":811},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":820},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":826},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":830},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":838},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":842},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":854},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":866},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":870},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":879},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":883},{"source":"src/quic/transport/transport_parameters.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":895},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":26,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":29,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.1","line":33,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":95,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":98,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":101,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":115,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.4","line":131,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":1216,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1250,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3","line":1297,"type":"TEST"},{"source":"tests/core/connection/ack_receive_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.1","line":1319,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":148,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.4","line":193,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":471,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":498,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":540,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":546,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.7","line":1120,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":1124,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1481,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1488,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1730,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1741,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1756,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1800,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1810,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1818,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1831,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":1949,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":2043,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":2193,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":2220,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":2224,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":2634,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":3555,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":3559,"type":"TEST"},{"source":"tests/core/connection/ack_recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2","line":3829,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":438,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":441,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":447,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":470,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":473,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":1221,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1666,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1711,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1714,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1718,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1760,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.4.2.2","line":1798,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":1957,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":2070,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.4","line":2474,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":2906,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":2911,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":2938,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":2974,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":2979,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":3010,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":3014,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":3019,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.9","line":3334,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":3690,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":3727,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":3950,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":3991,"type":"TEST"},{"source":"tests/core/connection/ack_send_path_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":4114,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":255,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":267,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":308,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":322,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":360,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":397,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":426,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":445,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":479,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":482,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":559,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":592,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":618,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":644,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":665,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":683,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":709,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1","line":781,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":787,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":839,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":907,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":910,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":939,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":982,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":986,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1001,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1030,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1061,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1083,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1106,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1144,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":1157,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1175,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1179,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1191,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":1204,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1233,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1319,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1358,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1386,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1392,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":1410,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.16","line":1533,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1657,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1693,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1733,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1769,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":1773,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":1849,"type":"TEST"},{"source":"tests/core/connection/connection_id_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":1854,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":77,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":80,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":122,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":125,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":816,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":829,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":841,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":847,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":986,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.9","line":989,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.2","line":1129,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":1193,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":1223,"type":"TEST"},{"source":"tests/core/connection/flow_control_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.12","line":1242,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":125,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":193,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":211,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.1","line":238,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.2","line":261,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.2","line":286,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":343,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":348,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":393,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":883,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1168,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":1292,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":1721,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.9.2","line":1760,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.9","line":2373,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.9","line":2377,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":2414,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":2418,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":2568,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":2582,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.13","line":2597,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.9","line":2744,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.1","line":2792,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":2796,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.4","line":2939,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.5","line":2975,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.5","line":2990,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":3006,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":3021,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.13","line":3037,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":3212,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":3268,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":3272,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":3361,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":3537,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":3591,"type":"TEST"},{"source":"tests/core/connection/handshake_inbound_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":4042,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":105,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":126,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":265,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":276,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":294,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":301,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.1","line":313,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.20","line":646,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":828,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.1","line":840,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":881,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.1","line":923,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":977,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1014,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1020,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1054,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1063,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":1089,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":1104,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":1118,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":1202,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1","line":1207,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.1","line":1317,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":1322,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":1325,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1329,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":1334,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1369,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1375,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":1406,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.1","line":1419,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":1424,"type":"TEST"},{"source":"tests/core/connection/handshake_lifecycle_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":1710,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":89,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":140,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":178,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":197,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":200,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":205,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.3","line":231,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":775,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":819,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":824,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":829,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.1","line":853,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.5","line":881,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.1.2","line":918,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":1163,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":1170,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":1173,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":1205,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":1430,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.3","line":1458,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":1469,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":1476,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":1530,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":1609,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":1647,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":1747,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":1752,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":1796,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":1832,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.1","line":1870,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":2115,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9","line":2119,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8","line":2196,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8","line":2207,"type":"TEST"},{"source":"tests/core/connection/migration_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.2","line":2231,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":104,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.17","line":108,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":244,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":249,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2","line":318,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":322,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":653,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":657,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":666,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":696,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":702,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":727,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":749,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":753,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":772,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.2","line":777,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.3","line":822,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":1220,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":1394,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.3","line":1398,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":1479,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":1482,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":1514,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.4","line":1534,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.4","line":1539,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.2","line":1570,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":1909,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":1935,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":1988,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.1","line":1995,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.2.4","line":2022,"type":"TEST"},{"source":"tests/core/connection/path_validation_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3.2","line":2026,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":254,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":285,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":319,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":425,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":501,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":511,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.2","line":520,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":524,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.3","line":530,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.3","line":539,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":630,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":638,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":677,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":709,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":754,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":798,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.2","line":834,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":894,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2","line":1017,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2","line":1053,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1188,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1191,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1204,"type":"TEST"},{"source":"tests/core/connection/retry_version_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":1207,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5","line":112,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-5.1","line":130,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.3","line":146,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":424,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":459,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":819,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":831,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.3","line":835,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":840,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.21","line":1076,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":1079,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":1216,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.2","line":1398,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":1452,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.3","line":1514,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.19","line":1566,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11.2","line":1611,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":1614,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":1619,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.2","line":1656,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.21","line":1941,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":2689,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":2715,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":2911,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":2961,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.14","line":2985,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":3415,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":3434,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.2","line":3454,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":4092,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":4135,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":4138,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.2","line":4306,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":4391,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":4417,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.4","line":4494,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.4","line":4501,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.4","line":4556,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.4","line":4564,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":4613,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":4615,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":4625,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":4650,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":4652,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-2.1","line":4684,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":4883,"type":"TEST"},{"source":"tests/core/connection/stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":4886,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":95,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":298,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":589,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.6","line":765,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":880,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":919,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.3","line":1153,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":1469,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1605,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1608,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1612,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":1678,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1738,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1743,"type":"TEST"},{"source":"tests/core/connection/zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.1","line":1748,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":300,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":309,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.1","line":315,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":405,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":427,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":431,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.3","line":515,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":538,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-2.1","line":577,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":619,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":650,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-6.2","line":698,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-11","line":798,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":1282,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":1290,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2","line":1302,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":1563,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":1724,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":1962,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":1965,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.1","line":1989,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":1993,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":1996,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.2","line":2019,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":2043,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":2048,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":2051,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":2083,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":2092,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":2096,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":2138,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5.1","line":2220,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.1","line":2249,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":2260,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":2278,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.3","line":2289,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":2292,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":2331,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.3","line":2346,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2349,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.3","line":2366,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":2369,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":2382,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2419,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2423,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.4","line":2460,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2644,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2648,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2664,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":2668,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":2758,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-21.5.6","line":2852,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.3","line":2915,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.3","line":3004,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3040,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3047,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3052,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3059,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3090,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3094,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3097,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3135,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-8.1.3","line":3138,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":3176,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.3","line":3181,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":3186,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":3191,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":3206,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.3","line":3222,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":3236,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.3","line":3241,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.3","line":3255,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":3270,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":3274,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":3384,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.2","line":3440,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":3502,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3.1","line":3518,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.2","line":3523,"type":"TEST"},{"source":"tests/core/endpoint/internal_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2.2","line":3525,"type":"TEST"},{"source":"tests/core/endpoint/multiplex_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":552,"type":"TEST"},{"source":"tests/core/endpoint/multiplex_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.2","line":562,"type":"TEST"},{"source":"tests/core/endpoint/server_routing_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-5.2.2","line":220,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3","line":337,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3","line":368,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1101,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1112,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1123,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1146,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.3.1","line":1641,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.6","line":1783,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":1801,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":1803,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":1818,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":1909,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":1913,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.14","line":1929,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1948,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1955,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":1958,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.6","line":2009,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.7","line":2019,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.8","line":2032,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":2060,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":2064,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.14","line":2091,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":2100,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":2114,"type":"TEST"},{"source":"tests/core/packets/frame_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.15","line":2117,"type":"TEST"},{"source":"tests/core/packets/packet_number_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.1","line":13,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":91,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":110,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":115,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.1","line":132,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.5","line":183,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":227,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":302,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":509,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":574,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":668,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":887,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":981,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1018,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.5","line":1079,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1082,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2.4","line":1099,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1149,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":1171,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":1177,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.4","line":1200,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":1220,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.2","line":1247,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3","line":1256,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-17.3.1","line":1278,"type":"TEST"},{"source":"tests/core/packets/packet_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9287","target_section":"section-3","line":1292,"type":"TEST"},{"source":"tests/core/packets/protected_codec_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-10.3","line":945,"type":"TEST"},{"source":"tests/core/packets/protected_codec_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.2","line":1830,"type":"TEST"},{"source":"tests/core/packets/protected_codec_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":2066,"type":"TEST"},{"source":"tests/core/packets/protected_codec_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":2093,"type":"TEST"},{"source":"tests/core/packets/protected_codec_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-12.2","line":3350,"type":"TEST"},{"source":"tests/core/packets/protected_codec_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.4.2","line":3575,"type":"TEST"},{"source":"tests/core/packets/protected_codec_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.4.2","line":3595,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":302,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":486,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":501,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":505,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4.2","line":646,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":669,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":687,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9221","target_section":"section-3","line":801,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":850,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":853,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":866,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":898,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":918,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.4","line":937,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":941,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":958,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":962,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":981,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":985,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1004,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1008,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1027,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1030,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1034,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1056,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1060,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1081,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1085,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1097,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1100,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-18.2","line":1154,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":1203,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":1224,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":1245,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":1248,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":1268,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.3","line":1289,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":1390,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":1417,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":1464,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":1493,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":1599,"type":"TEST"},{"source":"tests/core/packets/transport_parameters_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9368","target_section":"section-4","line":1630,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":591,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":594,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":690,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":755,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":808,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":906,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.5","line":925,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.2","line":1101,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.1","line":1134,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.2.3","line":1143,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-6.2.2","line":3276,"type":"TEST"},{"source":"tests/core/recovery/recovery_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9002","target_section":"section-5.2","line":3295,"type":"TEST"},{"source":"tests/core/streams/crypto_stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":1152,"type":"TEST"},{"source":"tests/core/streams/crypto_stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7.5","line":1174,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":149,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.6","line":161,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.11","line":163,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":303,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.10","line":482,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":513,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-4.5","line":529,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":555,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":558,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":570,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":578,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":586,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":606,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.3","line":609,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":616,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-13.3","line":909,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-19.13","line":945,"type":"TEST"},{"source":"tests/core/streams/streams_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-3.5","line":1111,"type":"TEST"},{"source":"tests/ffi/core_ffi_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.3","line":346,"type":"TEST"},{"source":"tests/http09/runtime/config_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4","line":489,"type":"TEST"},{"source":"tests/http09/runtime/preferred_address_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.6.1","line":14,"type":"TEST"},{"source":"tests/http09/runtime/retry_zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4","line":239,"type":"TEST"},{"source":"tests/http09/runtime/retry_zero_rtt_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-4.1","line":246,"type":"TEST"},{"source":"tests/http09/runtime/socket_io_backend_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":861,"type":"TEST"},{"source":"tests/http09/runtime/socket_io_backend_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14","line":863,"type":"TEST"},{"source":"tests/http09/runtime/socket_io_backend_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-14.2.1","line":917,"type":"TEST"},{"source":"tests/http09/runtime/socket_io_backend_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-9.7","line":934,"type":"TEST"},{"source":"tests/http3/connection_control_stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":231,"type":"TEST"},{"source":"tests/http3/connection_control_stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":235,"type":"TEST"},{"source":"tests/http3/connection_control_stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":255,"type":"TEST"},{"source":"tests/http3/connection_control_stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.2","line":259,"type":"TEST"},{"source":"tests/http3/connection_control_stream_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.7","line":796,"type":"TEST"},{"source":"tests/http3/connection_error_paths_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.2.4","line":84,"type":"TEST"},{"source":"tests/http3/connection_error_paths_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.3","line":1958,"type":"TEST"},{"source":"tests/http3/protocol_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":421,"type":"TEST"},{"source":"tests/http3/protocol_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-7.1","line":424,"type":"TEST"},{"source":"tests/http3/protocol_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":596,"type":"TEST"},{"source":"tests/http3/protocol_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":827,"type":"TEST"},{"source":"tests/http3/protocol_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9114","target_section":"section-4.2","line":978,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.2.1","line":216,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.2","line":245,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.2","line":247,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.1","line":261,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.1","line":275,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.1","line":289,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.5.1.1","line":303,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.1.2","line":346,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.3.1","line":372,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.2","line":398,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2","line":430,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.4.1","line":588,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.4.3","line":664,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2","line":718,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.2.2","line":761,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.1","line":775,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.3.1","line":910,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-4.3.1","line":913,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":1102,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":1321,"type":"TEST"},{"source":"tests/http3/qpack_dynamic_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-2.2.1","line":1497,"type":"TEST"},{"source":"tests/http3/qpack_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9204","target_section":"section-3.1","line":111,"type":"TEST"},{"source":"tests/tls/packet_crypto_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.2","line":743,"type":"TEST"},{"source":"tests/tls/packet_crypto_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-5.2","line":783,"type":"TEST"},{"source":"tests/tls/packet_crypto_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-9.6","line":786,"type":"TEST"},{"source":"tests/tls/packet_crypto_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":798,"type":"TEST"},{"source":"tests/tls/packet_crypto_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9369","target_section":"section-3","line":905,"type":"TEST"},{"source":"tests/tls/tls_adapter_contract_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-8.2","line":250,"type":"TEST"},{"source":"tests/tls/tls_adapter_contract_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9001","target_section":"section-4.6.1","line":389,"type":"TEST"},{"source":"tests/tls/tls_adapter_contract_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":705,"type":"TEST"},{"source":"tests/tls/tls_adapter_contract_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":714,"type":"TEST"},{"source":"tests/tls/tls_adapter_contract_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":873,"type":"TEST"},{"source":"tests/tls/tls_adapter_contract_test.cpp","target_path":"https://www.rfc-editor.org/rfc/rfc9000","target_section":"section-7","line":892,"type":"TEST"}],"statuses":{"42":{"spec":108,"exception":108,"related":[27]},"43":{"spec":154,"citation":154,"test":154,"related":[2174,2694]},"44":{"spec":84,"citation":84,"test":84,"related":[1695,2700]},"45":{"spec":181,"incomplete":181},"46":{"spec":122,"incomplete":122},"47":{"spec":177,"incomplete":177},"48":{"spec":213,"citation":213,"test":213,"related":[1692,2106,2702]},"49":{"spec":149,"incomplete":149},"50":{"spec":235,"citation":235,"test":235,"related":[1693,2107,2703]},"51":{"spec":107,"citation":107,"test":107,"related":[1740,2957]},"52":{"spec":183,"incomplete":183},"53":{"spec":41,"citation":41,"test":41,"related":[2082,2956]},"54":{"spec":161,"incomplete":161},"55":{"spec":134,"citation":134,"test":134,"related":[2101,2145,2704,2830]},"56":{"spec":228,"citation":228,"related":[2104]},"57":{"spec":173,"citation":173,"test":173,"related":[2105,2717]},"58":{"spec":173,"citation":173,"test":173,"related":[2102,2719]},"59":{"spec":69,"citation":69,"test":69,"related":[2103,2720]},"60":{"spec":137,"citation":137,"test":137,"related":[2098,2705,2707]},"61":{"spec":149,"citation":149,"test":149,"related":[2099,2706,2708]},"62":{"spec":134,"citation":134,"related":[1705]},"63":{"spec":107,"citation":107,"test":107,"related":[1998,1999,2709,2710]},"64":{"spec":224,"incomplete":224},"65":{"spec":114,"citation":114,"test":114,"related":[2211,2958,2959]},"66":{"spec":88,"citation":88,"test":88,"related":[2212,2338,2895]},"67":{"spec":111,"citation":111,"related":[2302]},"68":{"spec":85,"citation":85,"related":[2315]},"69":{"spec":155,"citation":155,"test":155,"related":[2312,2314,2316,2954]},"70":{"spec":148,"citation":148,"test":148,"related":[1748,2592]},"71":{"spec":152,"citation":152,"test":152,"related":[2278,2951]},"72":{"spec":182,"citation":182,"test":182,"related":[2000,2194,2277,2955]},"73":{"spec":53,"citation":53,"test":53,"related":[1847,2219,2952]},"74":{"spec":183,"citation":183,"test":183,"related":[2210,2281,2953]},"75":{"spec":148,"exception":148,"related":[28]},"76":{"spec":157,"exception":157,"related":[29]},"77":{"spec":75,"citation":75,"test":75,"related":[1846,1972,2622,2626,2632]},"78":{"spec":162,"citation":162,"related":[1949,1952,1958,1959]},"79":{"spec":165,"citation":165,"test":165,"related":[2282,2942,2946,2948,2949]},"80":{"spec":122,"citation":122,"related":[2279]},"81":{"spec":111,"citation":111,"test":111,"related":[2004,2716]},"82":{"spec":139,"citation":139,"test":139,"related":[2285,2945]},"83":{"spec":225,"citation":225,"test":225,"related":[1678,1891,3013]},"84":{"spec":176,"citation":176,"test":176,"related":[2283,2941]},"85":{"spec":143,"citation":143,"test":143,"related":[2284,2944,2947]},"86":{"spec":74,"citation":74,"test":74,"related":[2221,2223,2225,2878,2879]},"87":{"spec":78,"citation":78,"test":78,"related":[2280,2943]},"88":{"spec":161,"citation":161,"test":161,"related":[2276,2950]},"89":{"spec":81,"incomplete":81},"90":{"spec":123,"citation":123,"related":[1735]},"91":{"spec":223,"citation":223,"test":223,"related":[2001,2714,2722]},"92":{"spec":142,"citation":142,"test":142,"related":[1694,2701]},"93":{"spec":121,"citation":121,"related":[1706]},"94":{"spec":79,"citation":79,"test":79,"related":[1721,2828,2832]},"95":{"spec":111,"exception":111,"related":[30]},"96":{"spec":87,"citation":87,"test":87,"related":[2002,2715,2723]},"97":{"spec":99,"citation":99,"test":99,"related":[2003,2718]},"98":{"spec":214,"citation":214,"related":[2005]},"99":{"spec":110,"citation":110,"test":110,"related":[2313,2890]},"100":{"spec":51,"citation":51,"test":51,"related":[1688,1689,3017]},"101":{"spec":181,"citation":181,"test":181,"related":[2160,2559]},"102":{"spec":92,"citation":92,"related":[2311]},"103":{"spec":95,"citation":95,"test":95,"related":[2085,2086,2864]},"104":{"spec":126,"citation":126,"test":126,"related":[1715,2663]},"105":{"spec":179,"citation":179,"test":179,"related":[1716,1756,1760,2661,2662]},"106":{"spec":216,"citation":216,"test":216,"related":[1703,2845]},"107":{"spec":103,"citation":103,"test":103,"related":[1778,2562,2565]},"108":{"spec":100,"citation":100,"test":100,"related":[1779,2563,2566]},"109":{"spec":249,"citation":249,"test":249,"related":[1776,2574]},"110":{"spec":173,"citation":173,"test":173,"related":[1867,2822]},"111":{"spec":120,"citation":120,"test":120,"related":[1868,2823]},"112":{"spec":134,"citation":134,"test":134,"related":[1656,2998]},"113":{"spec":112,"citation":112,"test":112,"related":[1662,1673,3000,3007]},"114":{"spec":128,"citation":128,"test":128,"related":[1657,1664,3002,3004]},"115":{"spec":112,"citation":112,"test":112,"related":[1644,1648,2966]},"116":{"spec":116,"citation":116,"test":116,"related":[1642,1645,1647,2963,2964,2965]},"117":{"spec":140,"incomplete":140},"118":{"spec":73,"citation":73,"related":[1679,1684]},"119":{"spec":111,"citation":111,"related":[1680,1685]},"120":{"spec":124,"citation":124,"test":124,"related":[1654,2994]},"121":{"spec":126,"citation":126,"related":[1681,1686]},"122":{"spec":86,"citation":86,"test":86,"related":[1655,1663,2997,3001]},"123":{"spec":107,"citation":107,"related":[1683]},"124":{"spec":145,"citation":145,"test":145,"related":[1755,1759,1762,1772,1837,2656,2657,2658]},"125":{"spec":169,"citation":169,"test":169,"related":[1781,2532]},"126":{"spec":221,"citation":221,"test":221,"related":[1763,1773,1838,1872,2577,2580,2583]},"127":{"spec":199,"citation":199,"test":199,"related":[1757,1761,1764,1774,1839,2555,2556,2578,2581,2584]},"128":{"spec":171,"citation":171,"test":171,"related":[2156,2582]},"129":{"spec":157,"citation":157,"test":157,"related":[1843,2870]},"130":{"spec":109,"citation":109,"test":109,"related":[2080,2560]},"131":{"spec":176,"citation":176,"related":[1871]},"132":{"spec":172,"citation":172,"test":172,"related":[2110,2117,2553,2554]},"133":{"spec":160,"citation":160,"test":160,"related":[2402,3071]},"134":{"spec":184,"citation":184,"test":184,"related":[1870,2579]},"135":{"spec":87,"citation":87,"test":87,"related":[2401,3070]},"136":{"spec":109,"citation":109,"related":[2404]},"137":{"spec":280,"citation":280,"test":280,"related":[2403,2410,3064,3072]},"138":{"spec":112,"citation":112,"test":112,"related":[2412,3067]},"139":{"spec":135,"citation":135,"related":[2405]},"140":{"spec":128,"citation":128,"test":128,"related":[2406,3066]},"141":{"spec":204,"citation":204,"test":204,"related":[1869,2400,2821,2824,3065]},"142":{"spec":103,"citation":103,"test":103,"related":[2407,3063]},"143":{"spec":112,"citation":112,"test":112,"related":[2408,3068]},"144":{"spec":161,"citation":161,"test":161,"related":[1714,1913,2691]},"145":{"spec":117,"citation":117,"test":117,"related":[2409,3069]},"146":{"spec":132,"citation":132,"test":132,"related":[2108,2116,2125,2557]},"147":{"spec":127,"citation":127,"test":127,"related":[2126,2524]},"148":{"spec":126,"citation":126,"test":126,"related":[1771,2128,2866]},"149":{"spec":155,"citation":155,"test":155,"related":[2153,2542]},"150":{"spec":122,"citation":122,"test":122,"related":[2159,2561]},"151":{"spec":73,"citation":73,"test":73,"related":[2446,2472,3088,3091]},"152":{"spec":136,"citation":136,"test":136,"related":[2454,2462,3092]},"153":{"spec":74,"citation":74,"test":74,"related":[1807,2590]},"154":{"spec":155,"citation":155,"test":155,"related":[2471,3080]},"155":{"spec":156,"citation":156,"test":156,"related":[1749,2648]},"156":{"spec":88,"citation":88,"test":88,"related":[1801,1802,2539,2540]},"157":{"spec":79,"citation":79,"test":79,"related":[1788,2586,2587]},"158":{"spec":156,"citation":156,"test":156,"related":[2411,2526]},"159":{"spec":140,"citation":140,"test":140,"related":[1783,2535]},"160":{"spec":56,"citation":56,"test":56,"related":[1784,1785,1786,1792,1793,1794,1796,1797,1798,2074,2533,2568,2570,2572,2573]},"161":{"spec":110,"incomplete":110},"162":{"spec":157,"citation":157,"related":[1787,1795,1799,2077]},"163":{"spec":114,"citation":114,"test":114,"related":[2075,2569]},"164":{"spec":68,"incomplete":68},"165":{"spec":175,"incomplete":175},"166":{"spec":129,"incomplete":129},"167":{"spec":246,"citation":246,"test":246,"related":[2092,2558,2712]},"168":{"spec":171,"citation":171,"test":171,"related":[2093,2721]},"169":{"spec":149,"citation":149,"related":[2090]},"170":{"spec":165,"citation":165,"test":165,"related":[2327,2898]},"171":{"spec":146,"incomplete":146},"172":{"spec":114,"citation":114,"test":114,"related":[2066,2666]},"173":{"spec":126,"citation":126,"test":126,"related":[1597,3102]},"174":{"spec":143,"citation":143,"related":[2336]},"175":{"spec":187,"citation":187,"test":187,"related":[1598,2337,2892]},"176":{"spec":142,"citation":142,"related":[2300]},"177":{"spec":65,"citation":65,"test":65,"related":[2301,2891]},"178":{"spec":100,"citation":100,"test":100,"related":[1929,2771]},"179":{"spec":186,"incomplete":186},"180":{"spec":185,"citation":185,"test":185,"related":[2067,2176,2536]},"181":{"spec":130,"citation":130,"test":130,"related":[2065,2838]},"182":{"spec":164,"citation":164,"test":164,"related":[2162,2837]},"183":{"spec":309,"citation":309,"test":309,"related":[1926,2769]},"184":{"spec":79,"citation":79,"related":[1925]},"185":{"spec":165,"citation":165,"test":165,"related":[1924,2893]},"186":{"spec":154,"citation":154,"related":[2063,2064]},"187":{"spec":148,"citation":148,"test":148,"related":[1421,2354,3095]},"188":{"spec":196,"citation":196,"test":196,"related":[1805,2068,2537]},"189":{"spec":103,"citation":103,"test":103,"related":[1927,2770]},"190":{"spec":53,"citation":53,"test":53,"related":[1599,3100]},"191":{"spec":104,"citation":104,"test":104,"related":[1600,3101]},"192":{"spec":154,"citation":154,"test":154,"related":[2328,2900]},"193":{"spec":73,"citation":73,"related":[2290]},"194":{"spec":279,"citation":279,"related":[2289,2291]},"195":{"spec":149,"citation":149,"related":[1892]},"196":{"spec":250,"citation":250,"related":[1893]},"197":{"spec":167,"citation":167,"related":[1894]},"198":{"spec":44,"citation":44,"test":44,"related":[1660,2991]},"199":{"spec":208,"citation":208,"test":208,"related":[1669,2989]},"200":{"spec":75,"citation":75,"test":75,"related":[1670,2990]},"201":{"spec":134,"citation":134,"test":134,"related":[2294,2882]},"202":{"spec":156,"citation":156,"test":156,"related":[2295,2883]},"203":{"spec":135,"citation":135,"test":135,"related":[2317,2905]},"204":{"spec":100,"citation":100,"test":100,"related":[2323,2904]},"205":{"spec":233,"citation":233,"test":233,"related":[1751,1767,2089,2659,2660]},"206":{"spec":43,"citation":43,"related":[2115]},"207":{"spec":91,"citation":91,"test":91,"related":[2205,2802]},"208":{"spec":157,"citation":157,"test":157,"related":[1777,2564,2803]},"209":{"spec":92,"citation":92,"test":92,"related":[1766,1775,2869]},"210":{"spec":70,"citation":70,"test":70,"related":[2127,2525]},"211":{"spec":184,"citation":184,"test":184,"related":[1829,2037,2867,2868]},"212":{"spec":66,"citation":66,"related":[2100]},"213":{"spec":115,"citation":115,"test":115,"related":[1665,1687,3003]},"214":{"spec":100,"citation":100,"test":100,"related":[2297,2881]},"215":{"spec":156,"citation":156,"test":156,"related":[2349,2809]},"216":{"spec":159,"citation":159,"test":159,"related":[2209,2796]},"217":{"spec":72,"citation":72,"related":[2333]},"218":{"spec":86,"citation":86,"test":86,"related":[2334,2909]},"219":{"spec":85,"citation":85,"test":85,"related":[2345,2806]},"220":{"spec":148,"citation":148,"test":148,"related":[2346,2807,2808]},"221":{"spec":122,"citation":122,"test":122,"related":[2347,2804]},"222":{"spec":73,"citation":73,"test":73,"related":[2350,2805]},"223":{"spec":157,"citation":157,"test":157,"related":[2111,2114,2351,2797]},"224":{"spec":85,"citation":85,"test":85,"related":[2206,2800]},"225":{"spec":120,"incomplete":120},"226":{"spec":126,"citation":126,"related":[2207]},"227":{"spec":101,"test":101,"related":[2801]},"228":{"spec":87,"incomplete":87},"229":{"spec":104,"citation":104,"test":104,"related":[1667,2992]},"230":{"spec":103,"citation":103,"test":103,"related":[1674,3009]},"231":{"spec":54,"citation":54,"test":54,"related":[1668,2996]},"232":{"spec":95,"citation":95,"test":95,"related":[1653,1661,1666,2999]},"233":{"spec":132,"citation":132,"test":132,"related":[2227,2228,2906,2907]},"234":{"spec":54,"citation":54,"test":54,"related":[1668,2996]},"235":{"spec":95,"citation":95,"test":95,"related":[1653,1661,1666,2999]},"236":{"spec":132,"citation":132,"test":132,"related":[2227,2228,2906,2907]},"237":{"spec":55,"citation":55,"test":55,"related":[1658,2988]},"238":{"spec":179,"citation":179,"test":179,"related":[1675,3008]},"239":{"spec":103,"citation":103,"test":103,"related":[1671,3005,3011]},"240":{"spec":55,"citation":55,"test":55,"related":[1659,2995]},"241":{"spec":181,"citation":181,"test":181,"related":[1672,3006]},"242":{"spec":60,"citation":60,"related":[1423,2358]},"243":{"spec":79,"citation":79,"test":79,"related":[1691,2529]},"244":{"spec":132,"citation":132,"test":132,"related":[1424,2359,2528]},"245":{"spec":314,"citation":314,"test":314,"related":[1690,1850,2531]},"246":{"spec":109,"citation":109,"test":109,"related":[2071,2072,2527]},"247":{"spec":156,"citation":156,"test":156,"related":[2073,2530]},"248":{"spec":81,"citation":81,"test":81,"related":[2500,3041]},"249":{"spec":73,"citation":73,"related":[2355]},"250":{"spec":150,"citation":150,"test":150,"related":[1723,2755]},"251":{"spec":155,"citation":155,"related":[1427]},"252":{"spec":85,"citation":85,"test":85,"related":[2514,2516,3044,3046]},"253":{"spec":93,"citation":93,"test":93,"related":[2476,2479,3048,3050]},"254":{"spec":108,"citation":108,"test":108,"related":[2477,2480,2515,2517,3045,3047,3049]},"255":{"spec":72,"citation":72,"test":72,"related":[2494,3028]},"256":{"spec":118,"citation":118,"test":118,"related":[2495,3029]},"257":{"spec":169,"citation":169,"test":169,"related":[2501,3035,3037,3039,3042]},"258":{"spec":119,"citation":119,"test":119,"related":[2502,3036,3038,3040,3043]},"259":{"spec":158,"citation":158,"test":158,"related":[2043,2673,2682]},"260":{"spec":134,"citation":134,"test":134,"related":[2041,2674,2683]},"261":{"spec":106,"citation":106,"test":106,"related":[2470,3077]},"262":{"spec":181,"citation":181,"test":181,"related":[2449,2672,2678,3081]},"263":{"spec":140,"citation":140,"test":140,"related":[1627,1636,2972,2981]},"264":{"spec":72,"citation":72,"test":72,"related":[2444,2847]},"265":{"spec":97,"citation":97,"test":97,"related":[2440,3079]},"266":{"spec":127,"citation":127,"test":127,"related":[2036,2653]},"267":{"spec":155,"citation":155,"test":155,"related":[2044,2654]},"268":{"spec":143,"citation":143,"test":143,"related":[2463,3093]},"269":{"spec":136,"citation":136,"test":136,"related":[2033,2675,2684]},"270":{"spec":185,"citation":185,"test":185,"related":[2028,2841]},"271":{"spec":138,"citation":138,"test":138,"related":[1629,1638,2974,2983]},"272":{"spec":120,"citation":120,"test":120,"related":[1630,1639,2975,2984]},"273":{"spec":133,"citation":133,"test":133,"related":[1969,2613]},"274":{"spec":176,"citation":176,"test":176,"related":[1947,2606]},"275":{"spec":81,"citation":81,"test":81,"related":[1951,2605]},"276":{"spec":334,"citation":334,"related":[1950,1953]},"277":{"spec":107,"citation":107,"test":107,"related":[1631,1640,2599,2976,2985]},"278":{"spec":167,"citation":167,"test":167,"related":[1632,1641,2600,2977,2986]},"279":{"spec":112,"citation":112,"test":112,"related":[1948,2602]},"280":{"spec":314,"citation":314,"test":314,"related":[1955,2603,2604]},"281":{"spec":177,"citation":177,"test":177,"related":[1967,2610]},"282":{"spec":160,"citation":160,"test":160,"related":[1963,2633]},"283":{"spec":72,"incomplete":72},"284":{"spec":153,"citation":153,"test":153,"related":[1966,2607]},"285":{"spec":110,"citation":110,"test":110,"related":[1943,2761]},"286":{"spec":196,"incomplete":196},"287":{"spec":198,"citation":198,"test":198,"related":[1742,2831]},"288":{"spec":76,"citation":76,"test":76,"related":[1922,2155,2667,2699]},"289":{"spec":100,"citation":100,"test":100,"related":[1819,1827,2685,2689]},"290":{"spec":121,"citation":121,"test":121,"related":[1718,2825]},"291":{"spec":120,"exception":120,"related":[31]},"292":{"spec":85,"citation":85,"test":85,"related":[1865,2163,2836]},"293":{"spec":116,"citation":116,"test":116,"related":[1618,1619,1620,2967]},"294":{"spec":188,"citation":188,"test":188,"related":[1643,1646,1649,1800,2534,2961,2962]},"295":{"spec":129,"citation":129,"test":129,"related":[2032,2679]},"296":{"spec":155,"citation":155,"test":155,"related":[2042,2680]},"297":{"spec":131,"citation":131,"test":131,"related":[2040,2681]},"298":{"spec":134,"citation":134,"test":134,"related":[1621,1622,1633,2968,2978]},"299":{"spec":28,"citation":28,"test":28,"related":[1623,1634,2969,2979]},"300":{"spec":124,"citation":124,"test":124,"related":[1624,2970]},"301":{"spec":39,"citation":39,"test":39,"related":[1744,2711]},"302":{"spec":96,"citation":96,"test":96,"related":[1818,1826,2690]},"303":{"spec":187,"citation":187,"test":187,"related":[2031,2034,2842]},"304":{"spec":130,"citation":130,"test":130,"related":[1625,1626,1635,2971,2980]},"305":{"spec":134,"citation":134,"test":134,"related":[2021,2650,2670]},"306":{"spec":148,"citation":148,"test":148,"related":[1828,2669,2676]},"307":{"spec":62,"citation":62,"test":62,"related":[2019,2025,2026,2029,2030,2038,2039,2652,2860]},"308":{"spec":89,"citation":89,"test":89,"related":[1832,2819]},"309":{"spec":112,"incomplete":9,"citation":103,"test":103,"related":[1425,1830,2360,2361,2820]},"310":{"spec":202,"citation":70,"test":70,"exception":132,"related":[21,2366,2467,2538,2541]},"311":{"spec":119,"citation":119,"test":119,"related":[2468,2641,2643,2848]},"312":{"spec":111,"citation":111,"test":111,"related":[1717,2818]},"313":{"spec":281,"exception":281,"related":[34]},"314":{"spec":169,"exception":169,"related":[35]},"315":{"spec":132,"exception":132,"related":[32]},"316":{"spec":133,"citation":133,"test":133,"related":[2230,2235,2240,2248,2913,2916,2918]},"317":{"spec":80,"citation":80,"related":[1780]},"318":{"spec":112,"citation":112,"test":112,"related":[2148,2744]},"319":{"spec":76,"citation":76,"related":[2286]},"320":{"spec":211,"citation":211,"test":211,"related":[2217,2929]},"321":{"spec":185,"citation":185,"test":185,"related":[2218,2928]},"322":{"spec":205,"incomplete":205},"323":{"spec":152,"citation":152,"related":[2287]},"324":{"spec":98,"incomplete":98},"325":{"spec":140,"exception":140,"related":[33]},"326":{"spec":102,"exception":102,"related":[36]},"327":{"spec":374,"exception":374,"related":[37]},"328":{"spec":76,"exception":76,"related":[38]},"329":{"spec":204,"citation":204,"test":204,"related":[2014,2585]},"330":{"spec":86,"citation":86,"test":86,"related":[2015,2585]},"331":{"spec":148,"exception":148,"related":[0]},"332":{"spec":186,"exception":186,"related":[1]},"333":{"spec":59,"exception":59,"related":[4]},"334":{"spec":255,"exception":255,"related":[2]},"335":{"spec":116,"exception":116,"related":[5]},"336":{"spec":127,"exception":127,"related":[3]},"337":{"spec":157,"exception":157,"related":[6]},"338":{"spec":74,"exception":74,"related":[7]},"339":{"spec":75,"exception":75,"related":[8]},"340":{"spec":141,"exception":141,"related":[9]},"341":{"spec":139,"exception":139,"related":[10]},"342":{"spec":88,"exception":88,"related":[13]},"343":{"spec":129,"exception":129,"related":[12]},"344":{"spec":72,"exception":72,"related":[11]},"345":{"spec":146,"exception":146,"related":[14]},"346":{"spec":125,"exception":125,"related":[15]},"347":{"spec":196,"exception":196,"related":[16]},"348":{"spec":125,"exception":125,"related":[17]},"349":{"spec":196,"exception":196,"related":[18]},"350":{"spec":126,"exception":126,"related":[19]},"351":{"spec":126,"exception":126,"related":[20]},"352":{"spec":187,"exception":187,"related":[22]},"353":{"spec":104,"citation":104,"test":104,"related":[2024,2835,2844]},"354":{"spec":137,"exception":137,"related":[23]},"355":{"spec":96,"citation":96,"test":96,"related":[2457,2465,2861,3084,3089]},"356":{"spec":167,"citation":167,"test":167,"related":[2458,2459,2466,2862,3085,3090]},"357":{"spec":159,"exception":159,"related":[24]},"358":{"spec":175,"citation":175,"test":175,"related":[1743,2829]},"359":{"spec":124,"citation":124,"test":124,"related":[2455,2833]},"360":{"spec":175,"exception":175,"related":[25]},"361":{"spec":121,"citation":121,"test":121,"related":[2447,3086,3087]},"362":{"spec":143,"citation":143,"test":143,"related":[2456,2834]},"363":{"spec":133,"exception":133,"related":[26]},"364":{"spec":81,"citation":81,"test":81,"related":[2448,3094]},"365":{"spec":53,"citation":53,"test":53,"related":[2144,2469,2642,2644]},"366":{"spec":193,"citation":193,"test":193,"related":[1858,2671,2677]},"367":{"spec":100,"citation":100,"test":100,"related":[2460,2461,2647]},"368":{"spec":155,"citation":155,"test":155,"related":[2464,2645,2646]},"369":{"spec":188,"citation":188,"test":188,"related":[2151,2152,2588,2589]},"370":{"spec":201,"citation":201,"related":[2045,2046]},"371":{"spec":214,"citation":214,"test":214,"related":[1831,1833,2651]},"372":{"spec":136,"citation":136,"test":136,"related":[2022,2023,2851,2852,2853,2854]},"373":{"spec":133,"citation":133,"test":133,"related":[2020,2649]},"374":{"spec":70,"citation":70,"test":70,"related":[2445,2839]},"375":{"spec":208,"citation":208,"test":208,"related":[1859,2856,2859,3082,3083]},"376":{"spec":134,"citation":134,"test":134,"related":[2452,2453,2857]},"377":{"spec":260,"citation":260,"test":260,"related":[1628,1637,2499,2973,2982,3030]},"378":{"spec":54,"citation":54,"test":54,"related":[2439,2441,2442,3078]},"379":{"spec":191,"citation":191,"test":191,"related":[2035,2843]},"380":{"spec":72,"citation":72,"test":72,"related":[2443,2846]},"381":{"spec":124,"citation":124,"test":124,"related":[2027,2840]},"382":{"spec":257,"citation":257,"test":257,"related":[2047,2849,2850]},"383":{"spec":178,"citation":178,"related":[2370]},"384":{"spec":73,"citation":73,"test":73,"related":[1970,2623,2630]},"385":{"spec":223,"citation":223,"test":223,"related":[1746,2639]},"386":{"spec":102,"citation":102,"test":102,"related":[1975,2611]},"387":{"spec":70,"citation":70,"test":70,"related":[1977,1985,2612,2619]},"388":{"spec":216,"citation":216,"test":216,"related":[1982,2624]},"389":{"spec":295,"citation":295,"test":295,"related":[1957,1961,1983,2601]},"390":{"spec":83,"citation":83,"test":83,"related":[1968,2614]},"391":{"spec":186,"citation":186,"test":186,"related":[1984,2617,2618]},"392":{"spec":152,"citation":152,"related":[1978]},"393":{"spec":229,"citation":229,"related":[1979]},"394":{"spec":265,"citation":265,"test":265,"related":[1725,2048,2733,2736]},"395":{"spec":153,"citation":153,"test":153,"related":[2050,2738]},"396":{"spec":109,"citation":109,"test":109,"related":[1747,1974,2625,2640]},"397":{"spec":95,"citation":95,"related":[1956,1960]},"398":{"spec":239,"citation":239,"test":239,"related":[1954,2591,2593]},"399":{"spec":144,"citation":144,"test":144,"related":[1964,2598]},"400":{"spec":170,"citation":170,"test":170,"related":[1803,1965,2133,2597]},"401":{"spec":215,"citation":215,"test":215,"related":[1804,1962,2594,2595,2596]},"402":{"spec":186,"citation":186,"test":186,"related":[1980,1981,2609,2615,2616,2627,2631]},"403":{"spec":209,"citation":209,"related":[1845]},"404":{"spec":112,"citation":112,"test":112,"related":[1971,2608]},"405":{"spec":185,"citation":185,"related":[2306]},"406":{"spec":122,"citation":122,"related":[1704]},"407":{"spec":115,"citation":115,"related":[1889]},"408":{"spec":235,"citation":235,"test":235,"related":[2320,2902]},"409":{"spec":95,"citation":95,"related":[2318]},"410":{"spec":68,"citation":68,"test":68,"related":[2322,2885,2899]},"411":{"spec":105,"citation":105,"test":105,"related":[2321,2903]},"412":{"spec":150,"citation":150,"test":150,"related":[2329,2894]},"413":{"spec":137,"citation":137,"test":137,"related":[2299,2960]},"414":{"spec":125,"citation":125,"test":125,"related":[2324,2896]},"415":{"spec":65,"citation":65,"test":65,"related":[2325,2897]},"416":{"spec":229,"exception":229,"related":[40]},"417":{"spec":133,"exception":133,"related":[41]},"418":{"spec":119,"citation":119,"related":[1707]},"419":{"spec":173,"citation":173,"test":173,"related":[1708,2810,2811]},"420":{"spec":108,"citation":108,"test":108,"related":[2220,2880]},"421":{"spec":69,"citation":69,"related":[2319]},"422":{"spec":170,"citation":170,"test":170,"related":[2341,2792,2795]},"423":{"spec":162,"citation":162,"test":162,"related":[2268,2339,2794,2889]},"424":{"spec":101,"citation":101,"test":101,"related":[2270,2340,2793]},"425":{"spec":145,"citation":145,"related":[2292]},"426":{"spec":100,"citation":100,"test":100,"related":[2310,2884]},"427":{"spec":227,"citation":227,"related":[2094]},"428":{"spec":65,"citation":65,"test":65,"related":[2326,2901]},"429":{"spec":137,"citation":137,"test":137,"related":[1991,2634]},"430":{"spec":171,"citation":171,"test":171,"related":[1752,1758,1768,1770,2637,2686,2688]},"431":{"spec":140,"citation":140,"test":140,"related":[1988,1990,2635]},"432":{"spec":118,"citation":118,"test":118,"related":[1754,1987,1989,2636,2664]},"433":{"spec":219,"citation":219,"test":93,"related":[1753,1769,2638,2687]},"434":{"spec":213,"citation":213,"test":213,"related":[2490,2510,3032,3052]},"435":{"spec":94,"citation":94,"test":94,"related":[2491,2511,3054]},"436":{"spec":257,"citation":257,"test":257,"related":[2489,2509,3031,3051]},"437":{"spec":114,"citation":114,"test":114,"related":[2512,2513,3053,3055,3056]},"438":{"spec":159,"exception":159,"related":[39]},"439":{"spec":241,"citation":241,"test":241,"related":[1917,2876]},"440":{"spec":139,"citation":139,"test":139,"related":[1918,2877]},"441":{"spec":132,"citation":132,"test":132,"related":[2197,2863]},"442":{"spec":154,"citation":154,"test":154,"related":[1856,2872]},"443":{"spec":172,"citation":172,"test":172,"related":[1857,2873]},"444":{"spec":131,"citation":131,"test":131,"related":[1422,2356,2865]},"445":{"spec":189,"citation":189,"related":[1855]},"446":{"spec":99,"citation":99,"test":99,"related":[1920,2871]},"447":{"spec":238,"citation":238,"test":238,"related":[1915,2199,2875]},"448":{"spec":114,"incomplete":114},"449":{"spec":69,"citation":69,"test":69,"related":[2488,3024]},"450":{"spec":132,"citation":132,"test":132,"related":[2492,2496,2497,3021,3022,3033]},"451":{"spec":94,"citation":94,"test":94,"related":[2475,3020]},"452":{"spec":121,"citation":121,"test":121,"related":[2478,3025,3026]},"453":{"spec":105,"citation":105,"test":105,"related":[2367,3075]},"454":{"spec":75,"incomplete":75},"455":{"spec":112,"citation":112,"test":112,"related":[1750,1864,2655,3076]},"456":{"spec":241,"citation":241,"related":[1811,1821]},"457":{"spec":172,"citation":172,"test":172,"related":[1765,2724]},"458":{"spec":65,"citation":65,"test":65,"related":[2200,2203,2692,2693]},"459":{"spec":60,"citation":60,"test":60,"related":[2376,2377,2378,2387,2390,2396,3145,3146,3147,3148]},"460":{"spec":146,"citation":146,"test":146,"related":[2213,2910]},"461":{"spec":127,"citation":127,"test":127,"related":[2352,2798]},"462":{"spec":101,"citation":101,"related":[2331]},"463":{"spec":127,"citation":127,"related":[2261]},"464":{"spec":116,"citation":116,"test":116,"related":[2112,2353,2799,2937]},"465":{"spec":76,"citation":76,"test":76,"related":[2257,2308,2939]},"466":{"spec":77,"incomplete":77},"467":{"spec":178,"citation":178,"test":178,"related":[2236,2249,2917]},"468":{"spec":150,"citation":150,"test":150,"related":[2234,2237,2925,2927]},"469":{"spec":171,"citation":171,"test":171,"related":[2233,2238,2924,2926]},"470":{"spec":140,"citation":140,"related":[2214]},"471":{"spec":157,"citation":157,"test":157,"related":[2263,2307,2933,2936]},"472":{"spec":242,"citation":242,"test":242,"related":[2264,2938]},"473":{"spec":68,"citation":68,"test":68,"related":[2259,2932]},"474":{"spec":155,"citation":155,"test":155,"related":[2258,2309,2940]},"475":{"spec":90,"citation":90,"test":90,"related":[2267,2934,2935]},"476":{"spec":163,"citation":163,"test":163,"related":[2330,2921]},"477":{"spec":150,"citation":150,"related":[2332]},"478":{"spec":81,"citation":81,"test":81,"related":[2335,2922]},"479":{"spec":99,"citation":99,"related":[2266]},"480":{"spec":55,"citation":55,"test":55,"related":[2232,2908]},"481":{"spec":122,"citation":122,"test":122,"related":[2215,2216,2920]},"482":{"spec":156,"citation":156,"test":156,"related":[2243,2911]},"483":{"spec":162,"citation":162,"test":162,"related":[2251,2915]},"484":{"spec":107,"citation":107,"test":107,"related":[2058,2923]},"485":{"spec":98,"citation":98,"test":98,"related":[2242,2245,2247,2912]},"486":{"spec":134,"citation":134,"test":134,"related":[2231,2241,2914]},"487":{"spec":128,"citation":128,"test":128,"related":[2250,2252,2919]},"488":{"spec":168,"citation":168,"related":[2253,2254]},"489":{"spec":179,"incomplete":179},"490":{"spec":138,"citation":138,"test":138,"related":[2059,2665]},"491":{"spec":187,"citation":187,"test":187,"related":[1696,2575]},"492":{"spec":141,"citation":141,"test":141,"related":[2091,2713]},"493":{"spec":112,"citation":112,"test":112,"related":[1739,2178,2544,2546,2547,2549,2550]},"494":{"spec":176,"citation":176,"test":176,"related":[1900,2113,2124,2545,2548,2551,2552]},"495":{"spec":80,"citation":80,"related":[1806]},"496":{"spec":86,"citation":86,"test":86,"related":[2081,2137,2140,2143,2788]},"497":{"spec":138,"citation":138,"test":138,"related":[2141,2789]},"498":{"spec":152,"citation":152,"test":152,"related":[1848,1849,2782]},"499":{"spec":234,"citation":234,"test":234,"related":[2079,2786,2787]},"500":{"spec":165,"citation":165,"test":165,"related":[1944,2778]},"501":{"spec":162,"citation":162,"test":162,"related":[2147,2763]},"502":{"spec":143,"citation":143,"test":143,"related":[1941,2760,2774]},"503":{"spec":124,"citation":124,"test":124,"related":[2134,2567]},"504":{"spec":98,"citation":98,"test":98,"related":[2135,2766,2772]},"505":{"spec":147,"citation":147,"test":147,"related":[1816,2785]},"506":{"spec":137,"citation":137,"test":137,"related":[2078,2767,2773,2777]},"507":{"spec":136,"citation":136,"test":136,"related":[2146,2762]},"508":{"spec":117,"citation":117,"test":117,"related":[2136,2768]},"509":{"spec":134,"citation":134,"test":134,"related":[1945,2779]},"510":{"spec":58,"citation":58,"test":58,"related":[1733,2790]},"511":{"spec":145,"citation":145,"test":145,"related":[2173,2784]},"512":{"spec":222,"citation":222,"related":[1928]},"513":{"spec":110,"test":110,"related":[2764]},"514":{"spec":214,"citation":214,"test":214,"related":[2060,2757,2758]},"515":{"spec":162,"citation":162,"related":[1731]},"516":{"spec":107,"incomplete":107},"517":{"spec":180,"citation":180,"test":180,"related":[1737,2791]},"518":{"spec":138,"citation":138,"test":138,"related":[1736,2759]},"519":{"spec":96,"citation":96,"related":[2303]},"520":{"spec":117,"citation":117,"test":117,"related":[1939,2142,2731]},"521":{"spec":105,"citation":105,"test":105,"related":[1942,2157,2776]},"522":{"spec":225,"citation":225,"test":224,"related":[1809,1835,1841,1935,1936,2727,2728,2739,2740]},"523":{"spec":143,"citation":143,"test":143,"related":[2150,2730]},"524":{"spec":88,"incomplete":88},"525":{"spec":116,"citation":116,"test":116,"related":[2256,2931]},"526":{"spec":105,"citation":105,"test":105,"related":[2055,2061,2780]},"527":{"spec":287,"citation":287,"test":287,"related":[2056,2062,2781]},"528":{"spec":232,"incomplete":232},"529":{"spec":105,"citation":105,"test":105,"related":[1938,1940,2783]},"530":{"spec":132,"citation":132,"related":[1930,1986]},"531":{"spec":230,"citation":230,"test":230,"related":[1931,2734]},"532":{"spec":103,"citation":103,"test":103,"related":[1932,2735]},"533":{"spec":303,"citation":303,"related":[1933]},"534":{"spec":190,"citation":190,"test":190,"related":[2049,2737]},"535":{"spec":138,"citation":138,"related":[1429]},"536":{"spec":176,"citation":176,"test":176,"related":[1976,2725]},"537":{"spec":154,"citation":154,"related":[1426]},"538":{"spec":151,"citation":151,"test":151,"related":[1428,1730,2743,3097]},"539":{"spec":186,"citation":186,"test":186,"related":[1817,2052,2057,2746]},"540":{"spec":112,"citation":112,"test":112,"related":[1738,2751]},"541":{"spec":119,"citation":119,"test":119,"related":[1728,2051,2745]},"542":{"spec":194,"citation":194,"related":[2149]},"543":{"spec":78,"citation":78,"test":78,"related":[2138,2775]},"544":{"spec":95,"citation":95,"test":95,"related":[1808,1820,1834,1840,2054,2752,2753]},"545":{"spec":90,"incomplete":90},"546":{"spec":117,"citation":117,"related":[1726]},"547":{"spec":147,"citation":147,"test":147,"related":[1729,2749]},"548":{"spec":172,"citation":172,"test":172,"related":[1946,2747,2748]},"549":{"spec":210,"test":210,"related":[2750]},"550":{"spec":226,"incomplete":226},"551":{"spec":136,"citation":136,"test":136,"related":[2139,2765]},"552":{"spec":114,"citation":114,"test":114,"related":[2288,2930]},"553":{"spec":153,"citation":153,"related":[1727]},"554":{"spec":155,"citation":155,"related":[2305]},"555":{"spec":157,"citation":157,"test":157,"related":[1595,3103]},"556":{"spec":207,"citation":207,"related":[1596]},"557":{"spec":126,"citation":126,"test":126,"related":[1722,2732]},"558":{"spec":316,"citation":316,"test":316,"related":[1724,2726,2756]},"559":{"spec":199,"citation":199,"test":199,"related":[1934,2742]},"560":{"spec":147,"citation":147,"test":147,"related":[1810,1836,1842,1937,2729,2741]},"561":{"spec":96,"citation":96,"related":[1734]},"562":{"spec":121,"incomplete":121},"563":{"spec":97,"citation":97,"related":[2304]},"564":{"spec":80,"citation":80,"related":[1921,2154]},"565":{"spec":119,"incomplete":119,"todo":119,"related":[1148]},"566":{"spec":156,"incomplete":156,"todo":156,"related":[1149]},"567":{"spec":109,"incomplete":109,"todo":109,"related":[1150]},"568":{"spec":198,"incomplete":198,"todo":198,"related":[1151]},"569":{"spec":152,"citation":152,"related":[1702,2369]},"570":{"spec":87,"incomplete":87,"todo":87,"related":[1152]},"571":{"spec":51,"citation":51,"related":[2382]},"572":{"spec":90,"citation":90,"related":[2383]},"573":{"spec":166,"incomplete":166,"todo":166,"related":[1153]},"574":{"spec":54,"citation":54,"related":[2392]},"575":{"spec":70,"citation":70,"related":[2393]},"576":{"spec":87,"citation":87,"related":[2394]},"577":{"spec":266,"incomplete":266,"todo":266,"related":[1174]},"578":{"spec":184,"incomplete":184,"todo":184,"related":[1175]},"579":{"spec":131,"incomplete":131,"todo":131,"related":[1176]},"580":{"spec":118,"test":118,"related":[3144]},"581":{"spec":154,"incomplete":154,"todo":154,"related":[1177]},"582":{"spec":83,"incomplete":83,"todo":83,"related":[1187]},"583":{"spec":180,"incomplete":180,"todo":180,"related":[1188]},"584":{"spec":108,"incomplete":108,"todo":108,"related":[1189]},"585":{"spec":81,"incomplete":81,"todo":81,"related":[1190]},"586":{"spec":176,"incomplete":176,"todo":176,"related":[1178]},"587":{"spec":211,"citation":211,"related":[2397]},"588":{"spec":90,"incomplete":90,"todo":90,"related":[1186]},"589":{"spec":173,"citation":173,"related":[1994,2096]},"590":{"spec":56,"citation":56,"related":[1995,2097]},"591":{"spec":95,"citation":95,"test":95,"related":[1923,2668]},"592":{"spec":117,"citation":117,"related":[2083]},"593":{"spec":83,"citation":83,"related":[1901]},"594":{"spec":147,"citation":147,"related":[1902]},"595":{"spec":170,"citation":170,"related":[2185,2186]},"596":{"spec":156,"incomplete":156,"todo":156,"related":[1191]},"597":{"spec":137,"citation":137,"related":[2365]},"598":{"spec":117,"incomplete":117,"todo":117,"related":[1154]},"599":{"spec":46,"incomplete":46,"todo":46,"related":[1155]},"600":{"spec":110,"citation":110,"related":[2364]},"601":{"spec":124,"incomplete":124,"todo":124,"related":[1156]},"602":{"spec":83,"incomplete":83,"todo":83,"related":[1157]},"603":{"spec":124,"citation":124,"test":124,"related":[2372,3139]},"604":{"spec":140,"test":140,"related":[3014,3138]},"605":{"spec":102,"citation":102,"related":[2379,2380,2381]},"606":{"spec":148,"incomplete":148,"todo":148,"related":[1179]},"607":{"spec":110,"citation":110,"related":[2010]},"608":{"spec":137,"citation":137,"related":[2375]},"609":{"spec":86,"test":86,"related":[3018,3019]},"610":{"spec":312,"citation":312,"related":[1866]},"611":{"spec":112,"citation":112,"related":[1880]},"612":{"spec":121,"citation":121,"related":[1897,2195]},"613":{"spec":188,"incomplete":188,"todo":188,"related":[1192]},"614":{"spec":117,"incomplete":117,"todo":117,"related":[1193]},"615":{"spec":102,"incomplete":102,"todo":102,"related":[1194]},"616":{"spec":115,"citation":115,"related":[1898]},"617":{"spec":91,"incomplete":91,"todo":91,"related":[1162]},"618":{"spec":79,"citation":79,"related":[1899,2084]},"619":{"spec":105,"incomplete":105,"todo":105,"related":[1163]},"620":{"spec":94,"citation":94,"related":[1874,1876,1878,1895]},"621":{"spec":115,"citation":115,"related":[1875,1877,1879,1896]},"622":{"spec":99,"incomplete":99,"todo":99,"related":[1164]},"623":{"spec":124,"incomplete":124,"todo":124,"related":[1165]},"624":{"spec":98,"citation":98,"related":[2129]},"625":{"spec":167,"citation":167,"related":[2130]},"626":{"spec":103,"citation":103,"related":[1699,1711]},"627":{"spec":99,"citation":99,"related":[2187]},"628":{"spec":109,"citation":109,"related":[1700,1712]},"629":{"spec":112,"citation":112,"related":[1701,1713]},"630":{"spec":96,"citation":96,"related":[1860]},"631":{"spec":215,"citation":215,"related":[1782,1861]},"632":{"spec":165,"incomplete":165,"todo":165,"related":[1166]},"633":{"spec":206,"citation":206,"related":[2190]},"634":{"spec":143,"incomplete":143,"todo":143,"related":[1167]},"635":{"spec":137,"citation":137,"related":[1698,1710]},"636":{"spec":132,"citation":132,"related":[1697,1709,2191]},"637":{"spec":143,"incomplete":143,"todo":143,"related":[1168]},"638":{"spec":188,"incomplete":188,"todo":188,"related":[1169]},"639":{"spec":212,"incomplete":212,"todo":212,"related":[1170]},"640":{"spec":61,"incomplete":61,"todo":61,"related":[1171]},"641":{"spec":160,"citation":160,"related":[2188]},"642":{"spec":136,"citation":136,"related":[2189]},"643":{"spec":84,"citation":84,"related":[2193]},"644":{"spec":73,"citation":73,"related":[2009,2131]},"645":{"spec":154,"citation":154,"related":[2006]},"646":{"spec":134,"citation":134,"related":[2011]},"647":{"spec":170,"citation":170,"related":[1862,2007]},"648":{"spec":174,"citation":174,"related":[1863,2008]},"649":{"spec":149,"citation":149,"related":[2012]},"650":{"spec":287,"citation":287,"related":[2013]},"651":{"spec":120,"incomplete":120,"todo":120,"related":[1172]},"652":{"spec":92,"incomplete":92,"todo":92,"related":[1173]},"653":{"spec":174,"citation":174,"related":[1881,1883]},"654":{"spec":143,"citation":143,"related":[1882,1884]},"655":{"spec":90,"citation":90,"related":[1745]},"656":{"spec":47,"incomplete":47,"todo":47,"related":[1180]},"657":{"spec":166,"incomplete":166,"todo":166,"related":[1181]},"658":{"spec":129,"incomplete":129,"todo":129,"related":[1158]},"659":{"spec":113,"citation":113,"related":[2386,2395]},"660":{"spec":227,"citation":227,"related":[2388]},"661":{"spec":144,"incomplete":144,"todo":144,"related":[1143]},"662":{"spec":79,"incomplete":79,"todo":79,"related":[1144]},"663":{"spec":105,"citation":105,"related":[2391]},"664":{"spec":141,"citation":141,"related":[2389]},"665":{"spec":132,"incomplete":132,"todo":132,"related":[1145]},"666":{"spec":295,"citation":295,"related":[1916,2384]},"667":{"spec":134,"citation":134,"related":[2385]},"668":{"spec":155,"incomplete":155,"todo":155,"related":[1182]},"669":{"spec":49,"incomplete":49,"todo":49,"related":[1183]},"670":{"spec":111,"citation":111,"related":[1682]},"671":{"spec":67,"incomplete":67,"todo":67,"related":[1184]},"672":{"spec":143,"incomplete":143,"todo":143,"related":[1185]},"673":{"spec":138,"incomplete":138,"todo":138,"related":[1195]},"674":{"spec":118,"incomplete":118,"todo":118,"related":[1196]},"675":{"spec":147,"incomplete":147,"todo":147,"related":[1197]},"676":{"spec":124,"incomplete":124,"todo":124,"related":[1198]},"677":{"spec":144,"incomplete":144,"todo":144,"related":[1199]},"678":{"spec":75,"incomplete":75,"todo":75,"related":[1159]},"679":{"spec":116,"incomplete":116,"todo":116,"related":[1146]},"680":{"spec":214,"incomplete":214,"todo":214,"related":[1160]},"681":{"spec":180,"incomplete":180,"todo":180,"related":[1161]},"682":{"spec":141,"citation":141,"related":[2192]},"683":{"spec":159,"incomplete":29,"citation":130,"test":130,"todo":159,"related":[1147,2374,3140]},"684":{"spec":84,"citation":84,"related":[2371]},"685":{"spec":181,"citation":181,"related":[2414]},"686":{"spec":127,"citation":127,"related":[2415]},"687":{"spec":62,"citation":62,"test":62,"related":[2427,3074]},"688":{"spec":94,"citation":94,"related":[2428]},"689":{"spec":100,"incomplete":100,"todo":100,"related":[1224]},"690":{"spec":171,"incomplete":171,"todo":171,"related":[1225]},"691":{"spec":131,"citation":131,"related":[2429]},"692":{"spec":136,"citation":136,"related":[1790,2430]},"693":{"spec":176,"incomplete":176,"todo":176,"related":[1226]},"694":{"spec":151,"incomplete":151,"todo":151,"related":[1227]},"695":{"spec":74,"citation":74,"related":[1791,2431]},"696":{"spec":116,"citation":116,"related":[2432]},"697":{"spec":116,"citation":116,"related":[2433]},"698":{"spec":112,"incomplete":112,"todo":112,"related":[1228]},"699":{"spec":156,"citation":156,"related":[2434]},"700":{"spec":110,"citation":110,"related":[2416,2435]},"701":{"spec":181,"citation":181,"related":[2413]},"702":{"spec":158,"citation":158,"related":[2399]},"703":{"spec":135,"citation":135,"related":[2417]},"704":{"spec":87,"citation":87,"related":[2436]},"705":{"spec":78,"citation":78,"related":[2437]},"706":{"spec":148,"citation":148,"related":[2418,2419]},"707":{"spec":136,"citation":136,"related":[2420]},"708":{"spec":84,"citation":84,"related":[2424]},"709":{"spec":166,"citation":166,"related":[2171]},"710":{"spec":116,"citation":116,"related":[2172]},"711":{"spec":172,"incomplete":172,"todo":172,"related":[1206]},"712":{"spec":125,"citation":125,"related":[2179,2425]},"713":{"spec":100,"citation":100,"related":[2168]},"714":{"spec":195,"citation":195,"related":[2169]},"715":{"spec":230,"incomplete":230,"todo":230,"related":[1207]},"716":{"spec":180,"citation":180,"related":[2180]},"717":{"spec":139,"incomplete":139,"todo":139,"related":[1208]},"718":{"spec":84,"citation":84,"test":84,"related":[2438,3073]},"719":{"spec":217,"incomplete":217,"todo":217,"related":[1209]},"720":{"spec":232,"citation":232,"related":[1996,1997]},"721":{"spec":273,"incomplete":273,"todo":273,"related":[1210]},"722":{"spec":117,"citation":117,"related":[2177]},"723":{"spec":215,"citation":215,"related":[2182]},"724":{"spec":54,"test":54,"todo":54,"related":[1217,2576]},"725":{"spec":210,"citation":210,"related":[2181]},"726":{"spec":78,"incomplete":78,"todo":78,"related":[1218]},"727":{"spec":59,"citation":59,"related":[2183]},"728":{"spec":173,"incomplete":173,"todo":173,"related":[1219]},"729":{"spec":131,"citation":131,"test":131,"related":[2184,2543]},"730":{"spec":114,"incomplete":114,"todo":114,"related":[1220]},"731":{"spec":127,"incomplete":127,"todo":127,"related":[1221]},"732":{"spec":174,"incomplete":174,"todo":174,"related":[1222]},"733":{"spec":82,"incomplete":82,"todo":82,"related":[1223]},"734":{"spec":126,"citation":126,"related":[1992,1993]},"735":{"spec":198,"citation":198,"related":[1602]},"736":{"spec":130,"incomplete":130,"todo":130,"related":[1213]},"737":{"spec":149,"incomplete":149,"todo":149,"related":[1214]},"738":{"spec":46,"citation":46,"related":[1615]},"739":{"spec":136,"citation":136,"related":[1603,1611]},"740":{"spec":137,"citation":137,"related":[1612]},"741":{"spec":117,"citation":117,"related":[1613]},"742":{"spec":205,"citation":205,"related":[1616]},"743":{"spec":235,"citation":235,"related":[1607,1609]},"744":{"spec":159,"incomplete":159,"todo":159,"related":[1211]},"745":{"spec":130,"incomplete":130,"todo":130,"related":[1212]},"746":{"spec":63,"citation":63,"related":[2016,2161]},"747":{"spec":141,"citation":141,"related":[2095]},"748":{"spec":168,"citation":168,"related":[1844]},"749":{"spec":188,"citation":188,"related":[1904]},"750":{"spec":88,"citation":88,"related":[1903]},"751":{"spec":143,"incomplete":143,"todo":143,"related":[1215]},"752":{"spec":209,"incomplete":209,"todo":209,"related":[1216]},"753":{"spec":190,"citation":190,"related":[1601,1614,2175]},"754":{"spec":99,"citation":99,"related":[2166]},"755":{"spec":52,"citation":52,"related":[2167]},"756":{"spec":77,"citation":77,"related":[1604,1617]},"757":{"spec":109,"incomplete":109,"todo":109,"related":[1200]},"758":{"spec":110,"citation":110,"related":[2132]},"759":{"spec":108,"incomplete":108,"todo":108,"related":[1201]},"760":{"spec":130,"incomplete":130,"todo":130,"related":[1202]},"761":{"spec":155,"incomplete":155,"todo":155,"related":[1203]},"762":{"spec":186,"incomplete":186,"todo":186,"related":[1204]},"763":{"spec":221,"incomplete":221,"todo":221,"related":[1205]},"764":{"spec":242,"citation":242,"related":[2164]},"765":{"spec":81,"citation":81,"related":[1513]},"766":{"spec":108,"citation":108,"related":[1515]},"767":{"spec":177,"incomplete":177,"todo":177,"related":[1325]},"768":{"spec":166,"incomplete":166,"todo":166,"related":[1351]},"769":{"spec":89,"citation":89,"related":[1441]},"770":{"spec":82,"incomplete":82,"todo":82,"related":[1318]},"771":{"spec":173,"incomplete":173,"todo":173,"related":[1319]},"772":{"spec":204,"incomplete":204,"todo":204,"related":[1320]},"773":{"spec":80,"incomplete":80,"todo":80,"related":[1321]},"774":{"spec":109,"citation":109,"related":[1516]},"775":{"spec":89,"incomplete":89,"todo":89,"related":[1352]},"776":{"spec":140,"incomplete":140,"todo":140,"related":[1255]},"777":{"spec":120,"incomplete":120,"todo":120,"related":[1256]},"778":{"spec":132,"incomplete":132,"todo":132,"related":[1257]},"779":{"spec":158,"incomplete":158,"todo":158,"related":[1258]},"780":{"spec":212,"incomplete":212,"todo":212,"related":[1259]},"781":{"spec":140,"incomplete":140,"todo":140,"related":[1260]},"782":{"spec":120,"incomplete":120,"todo":120,"related":[1261]},"783":{"spec":133,"incomplete":133,"todo":133,"related":[1262]},"784":{"spec":54,"incomplete":54,"todo":54,"related":[1263]},"785":{"spec":212,"incomplete":212,"todo":212,"related":[1264]},"786":{"spec":136,"incomplete":136,"todo":136,"related":[1265]},"787":{"spec":73,"incomplete":73,"todo":73,"related":[1266]},"788":{"spec":212,"incomplete":212,"todo":212,"related":[1267]},"789":{"spec":133,"incomplete":133,"todo":133,"related":[1268]},"790":{"spec":146,"incomplete":146,"todo":146,"related":[1269]},"791":{"spec":212,"incomplete":212,"todo":212,"related":[1270]},"792":{"spec":253,"incomplete":253,"todo":253,"related":[1282]},"793":{"spec":133,"incomplete":133,"todo":133,"related":[1283]},"794":{"spec":205,"incomplete":205,"todo":205,"related":[1284]},"795":{"spec":146,"incomplete":146,"todo":146,"related":[1285]},"796":{"spec":345,"incomplete":345,"todo":345,"related":[1286]},"797":{"spec":167,"incomplete":167,"todo":167,"related":[1287]},"798":{"spec":197,"incomplete":197,"todo":197,"related":[1288]},"799":{"spec":91,"incomplete":91,"todo":91,"related":[1289]},"800":{"spec":106,"incomplete":106,"todo":106,"related":[1290]},"801":{"spec":201,"incomplete":201,"todo":201,"related":[1291]},"802":{"spec":81,"incomplete":81,"todo":81,"related":[1292]},"803":{"spec":148,"citation":148,"related":[1445]},"804":{"spec":138,"incomplete":138,"todo":138,"related":[1293]},"805":{"spec":189,"incomplete":189,"todo":189,"related":[1294]},"806":{"spec":177,"incomplete":177,"todo":177,"related":[1295]},"807":{"spec":185,"incomplete":185,"todo":185,"related":[1296]},"808":{"spec":246,"incomplete":246,"todo":246,"related":[1297]},"809":{"spec":202,"incomplete":202,"todo":202,"related":[1298]},"810":{"spec":293,"incomplete":293,"todo":293,"related":[1237]},"811":{"spec":86,"incomplete":86,"todo":86,"related":[1299]},"812":{"spec":163,"incomplete":163,"todo":163,"related":[1300]},"813":{"spec":109,"incomplete":109,"todo":109,"related":[1301]},"814":{"spec":83,"incomplete":83,"todo":83,"related":[1302]},"815":{"spec":107,"incomplete":107,"todo":107,"related":[1303]},"816":{"spec":135,"incomplete":135,"todo":135,"related":[1304]},"817":{"spec":72,"incomplete":72,"todo":72,"related":[1305]},"818":{"spec":148,"incomplete":148,"todo":148,"related":[1306]},"819":{"spec":141,"incomplete":141,"todo":141,"related":[1307]},"820":{"spec":121,"incomplete":121,"todo":121,"related":[1308]},"821":{"spec":100,"incomplete":100,"todo":100,"related":[1309]},"822":{"spec":318,"incomplete":318,"todo":318,"related":[1310]},"823":{"spec":150,"incomplete":150,"todo":150,"related":[1271]},"824":{"spec":108,"citation":108,"related":[1483,1486]},"825":{"spec":120,"incomplete":120,"todo":120,"related":[1272]},"826":{"spec":44,"citation":44,"related":[1485,1492]},"827":{"spec":57,"citation":57,"related":[1436]},"828":{"spec":149,"incomplete":149,"todo":149,"related":[1311]},"829":{"spec":106,"citation":106,"related":[1478,1479,1480,1481]},"830":{"spec":117,"incomplete":117,"todo":117,"related":[1326]},"831":{"spec":171,"citation":171,"related":[1477]},"832":{"spec":191,"citation":191,"related":[1552]},"833":{"spec":126,"incomplete":126,"todo":126,"related":[1273]},"834":{"spec":170,"citation":170,"related":[1487]},"835":{"spec":67,"citation":67,"related":[1437]},"836":{"spec":137,"incomplete":137,"todo":137,"related":[1312]},"837":{"spec":76,"citation":76,"related":[1440]},"838":{"spec":162,"incomplete":162,"todo":162,"related":[1313]},"839":{"spec":190,"citation":190,"related":[1491]},"840":{"spec":184,"incomplete":184,"todo":184,"related":[1314]},"841":{"spec":107,"incomplete":107,"todo":107,"related":[1315]},"842":{"spec":181,"incomplete":181,"todo":181,"related":[1316]},"843":{"spec":178,"incomplete":178,"todo":178,"related":[1317]},"844":{"spec":173,"incomplete":173,"todo":173,"related":[1274]},"845":{"spec":307,"incomplete":307,"todo":307,"related":[1275]},"846":{"spec":130,"citation":130,"related":[1482,1484,1488,1490]},"847":{"spec":165,"citation":165,"related":[1435,1439]},"848":{"spec":80,"incomplete":80,"todo":80,"related":[1276]},"849":{"spec":96,"citation":96,"test":96,"related":[1514,3115]},"850":{"spec":169,"citation":169,"test":169,"related":[1526,3113]},"851":{"spec":163,"citation":163,"test":163,"related":[1527,3114]},"852":{"spec":216,"incomplete":216,"todo":216,"related":[1277]},"853":{"spec":103,"citation":103,"related":[1539]},"854":{"spec":230,"incomplete":230,"todo":230,"related":[1278]},"855":{"spec":124,"incomplete":124,"todo":124,"related":[1279]},"856":{"spec":176,"incomplete":176,"todo":176,"related":[1280]},"857":{"spec":168,"citation":168,"related":[1532]},"858":{"spec":164,"citation":164,"related":[1528,1529,1531,1537]},"859":{"spec":214,"citation":214,"related":[1538]},"860":{"spec":51,"citation":51,"related":[1530]},"861":{"spec":61,"citation":61,"related":[1540]},"862":{"spec":182,"incomplete":182,"todo":182,"related":[1281]},"863":{"spec":116,"citation":116,"related":[1546]},"864":{"spec":89,"citation":89,"related":[1533,1543]},"865":{"spec":141,"citation":141,"related":[1534,1544]},"866":{"spec":56,"citation":56,"related":[1547]},"867":{"spec":111,"citation":111,"related":[1535,1545]},"868":{"spec":87,"citation":87,"related":[1524,1541]},"869":{"spec":149,"citation":149,"related":[1525,1542]},"870":{"spec":49,"citation":49,"related":[1536]},"871":{"spec":89,"incomplete":89,"todo":89,"related":[1229]},"872":{"spec":102,"incomplete":102,"todo":102,"related":[1230]},"873":{"spec":237,"incomplete":237,"todo":237,"related":[1231]},"874":{"spec":117,"incomplete":117,"todo":117,"related":[1232]},"875":{"spec":125,"incomplete":125,"todo":125,"related":[1233]},"876":{"spec":190,"incomplete":190,"todo":190,"related":[1234]},"877":{"spec":124,"incomplete":124,"todo":124,"related":[1235]},"878":{"spec":209,"incomplete":209,"todo":209,"related":[1236]},"879":{"spec":62,"incomplete":62,"todo":62,"related":[1327]},"880":{"spec":205,"citation":205,"related":[1467]},"881":{"spec":211,"incomplete":211,"todo":211,"related":[1328]},"882":{"spec":61,"incomplete":61,"todo":61,"related":[1329]},"883":{"spec":107,"incomplete":107,"todo":107,"related":[1330]},"884":{"spec":229,"incomplete":229,"todo":229,"related":[1331]},"885":{"spec":97,"incomplete":97,"todo":97,"related":[1332]},"886":{"spec":248,"incomplete":248,"todo":248,"related":[1333]},"887":{"spec":54,"incomplete":54,"todo":54,"related":[1334]},"888":{"spec":145,"incomplete":145,"todo":145,"related":[1335]},"889":{"spec":119,"incomplete":119,"todo":119,"related":[1336]},"890":{"spec":158,"incomplete":158,"todo":158,"related":[1337]},"891":{"spec":76,"incomplete":76,"todo":76,"related":[1338]},"892":{"spec":56,"incomplete":56,"todo":56,"related":[1339]},"893":{"spec":282,"incomplete":282,"todo":282,"related":[1238]},"894":{"spec":131,"incomplete":131,"todo":131,"related":[1239]},"895":{"spec":49,"incomplete":49,"todo":49,"related":[1240]},"896":{"spec":67,"incomplete":67,"todo":67,"related":[1241]},"897":{"spec":245,"incomplete":245,"todo":245,"related":[1242]},"898":{"spec":71,"incomplete":71,"todo":71,"related":[1243]},"899":{"spec":126,"citation":126,"related":[1443]},"900":{"spec":66,"incomplete":66,"todo":66,"related":[1244]},"901":{"spec":109,"incomplete":109,"todo":109,"related":[1245]},"902":{"spec":210,"incomplete":210,"todo":210,"related":[1246]},"903":{"spec":260,"citation":260,"related":[1444]},"904":{"spec":132,"citation":132,"related":[1505]},"905":{"spec":138,"incomplete":138,"todo":138,"related":[1247]},"906":{"spec":170,"incomplete":170,"todo":170,"related":[1248]},"907":{"spec":111,"incomplete":111,"todo":111,"related":[1249]},"908":{"spec":100,"incomplete":100,"todo":100,"related":[1250]},"909":{"spec":156,"incomplete":156,"todo":156,"related":[1251]},"910":{"spec":177,"incomplete":177,"todo":177,"related":[1365]},"911":{"spec":103,"incomplete":103,"todo":103,"related":[1366]},"912":{"spec":167,"citation":167,"related":[1452]},"913":{"spec":143,"citation":143,"related":[1446]},"914":{"spec":135,"citation":135,"related":[1493]},"915":{"spec":175,"citation":175,"related":[1455]},"916":{"spec":119,"citation":119,"related":[1450]},"917":{"spec":124,"citation":124,"related":[1448,1453]},"918":{"spec":199,"incomplete":199,"todo":199,"related":[1367]},"919":{"spec":150,"citation":150,"related":[1456]},"920":{"spec":196,"incomplete":196,"todo":196,"related":[1368]},"921":{"spec":60,"citation":60,"related":[1468]},"922":{"spec":176,"citation":176,"related":[1469]},"923":{"spec":81,"incomplete":81,"todo":81,"related":[1369]},"924":{"spec":74,"incomplete":74,"todo":74,"related":[1370]},"925":{"spec":106,"incomplete":106,"todo":106,"related":[1371]},"926":{"spec":114,"incomplete":114,"todo":114,"related":[1372]},"927":{"spec":135,"incomplete":135,"todo":135,"related":[1373]},"928":{"spec":119,"incomplete":119,"todo":119,"related":[1374]},"929":{"spec":231,"incomplete":231,"todo":231,"related":[1375]},"930":{"spec":125,"citation":125,"related":[1463]},"931":{"spec":125,"incomplete":125,"todo":125,"related":[1376]},"932":{"spec":89,"citation":89,"related":[1464]},"933":{"spec":157,"incomplete":157,"todo":157,"related":[1377]},"934":{"spec":83,"incomplete":83,"todo":83,"related":[1378]},"935":{"spec":188,"incomplete":188,"todo":188,"related":[1379]},"936":{"spec":127,"incomplete":127,"todo":127,"related":[1380]},"937":{"spec":82,"citation":82,"test":82,"related":[1517,3111]},"938":{"spec":208,"citation":208,"test":208,"related":[1518,3112]},"939":{"spec":98,"incomplete":98,"todo":98,"related":[1252]},"940":{"spec":145,"citation":145,"related":[1470,1471]},"941":{"spec":64,"citation":64,"related":[1472,1475]},"942":{"spec":126,"citation":126,"related":[1499]},"943":{"spec":130,"citation":130,"related":[1500]},"944":{"spec":125,"incomplete":125,"todo":125,"related":[1340]},"945":{"spec":76,"incomplete":76,"todo":76,"related":[1341]},"946":{"spec":109,"incomplete":109,"todo":109,"related":[1342]},"947":{"spec":145,"incomplete":145,"todo":145,"related":[1343]},"948":{"spec":101,"incomplete":101,"todo":101,"related":[1344]},"949":{"spec":84,"incomplete":84,"todo":84,"related":[1345]},"950":{"spec":136,"incomplete":136,"todo":136,"related":[1253]},"951":{"spec":171,"citation":171,"related":[1507,1508]},"952":{"spec":173,"citation":173,"related":[1509]},"953":{"spec":74,"citation":74,"related":[1431]},"954":{"spec":74,"incomplete":74,"todo":74,"related":[1353]},"955":{"spec":122,"citation":122,"related":[1521]},"956":{"spec":135,"citation":135,"related":[1434,1438]},"957":{"spec":162,"incomplete":162,"todo":162,"related":[1354]},"958":{"spec":169,"incomplete":169,"todo":169,"related":[1355]},"959":{"spec":217,"incomplete":217,"todo":217,"related":[1356]},"960":{"spec":242,"incomplete":242,"todo":242,"related":[1357]},"961":{"spec":110,"incomplete":110,"todo":110,"related":[1358]},"962":{"spec":78,"incomplete":78,"todo":78,"related":[1359]},"963":{"spec":142,"incomplete":142,"todo":142,"related":[1360]},"964":{"spec":91,"incomplete":91,"todo":91,"related":[1361]},"965":{"spec":162,"citation":162,"related":[1511]},"966":{"spec":74,"incomplete":74,"todo":74,"related":[1362]},"967":{"spec":180,"citation":180,"related":[1432,1495]},"968":{"spec":279,"citation":279,"related":[1512]},"969":{"spec":141,"citation":141,"related":[1494]},"970":{"spec":147,"citation":147,"related":[1497,1498]},"971":{"spec":76,"citation":76,"related":[1501]},"972":{"spec":140,"test":140,"related":[3109]},"973":{"spec":79,"citation":79,"related":[1519]},"974":{"spec":114,"citation":114,"related":[1520]},"975":{"spec":85,"citation":85,"related":[1522]},"976":{"spec":114,"citation":114,"related":[1442]},"977":{"spec":149,"citation":149,"related":[1476]},"978":{"spec":66,"incomplete":66,"todo":66,"related":[1346]},"979":{"spec":158,"incomplete":158,"todo":158,"related":[1347]},"980":{"spec":88,"incomplete":88,"todo":88,"related":[1348]},"981":{"spec":157,"citation":157,"related":[1489]},"982":{"spec":155,"incomplete":155,"todo":155,"related":[1349]},"983":{"spec":58,"incomplete":58,"todo":58,"related":[1350]},"984":{"spec":134,"citation":134,"related":[1502]},"985":{"spec":44,"citation":44,"related":[1473]},"986":{"spec":104,"citation":104,"related":[1474]},"987":{"spec":128,"citation":128,"related":[1523]},"988":{"spec":126,"citation":126,"related":[1503]},"989":{"spec":115,"citation":115,"related":[1504]},"990":{"spec":43,"citation":43,"related":[1548]},"991":{"spec":103,"citation":103,"related":[1549]},"992":{"spec":196,"citation":196,"test":196,"related":[1506,3108]},"993":{"spec":102,"citation":102,"related":[1553]},"994":{"spec":73,"citation":73,"related":[1554]},"995":{"spec":118,"citation":118,"related":[1550,1555]},"996":{"spec":119,"incomplete":119,"todo":119,"related":[1322]},"997":{"spec":172,"incomplete":172,"todo":172,"related":[1323]},"998":{"spec":200,"incomplete":200,"todo":200,"related":[1324]},"999":{"spec":93,"citation":93,"related":[1551,1556]},"1000":{"spec":114,"incomplete":114,"todo":114,"related":[1381]},"1001":{"spec":252,"incomplete":252,"todo":252,"related":[1254]},"1002":{"spec":111,"incomplete":111,"todo":111,"related":[1363]},"1003":{"spec":155,"incomplete":155,"todo":155,"related":[1364]},"1004":{"spec":257,"citation":257,"related":[1559]},"1005":{"spec":128,"citation":128,"related":[1558]},"1006":{"spec":148,"citation":148,"test":148,"related":[1589,3123]},"1007":{"spec":167,"incomplete":167,"todo":167,"related":[1382]},"1008":{"spec":115,"incomplete":115,"todo":115,"related":[1390]},"1009":{"spec":94,"citation":94,"related":[1586]},"1010":{"spec":99,"incomplete":99,"todo":99,"related":[1383]},"1011":{"spec":157,"citation":157,"test":157,"related":[1571,1573,3134,3135,3136]},"1012":{"spec":136,"incomplete":136,"todo":136,"related":[1391]},"1013":{"spec":183,"citation":183,"test":183,"related":[1580,1590,3116]},"1014":{"spec":175,"incomplete":175,"todo":175,"related":[1392]},"1015":{"spec":303,"citation":303,"related":[1570,1572,1574,1576,1577,1578,1579]},"1016":{"spec":194,"citation":194,"related":[1581,1582,1583,1584]},"1017":{"spec":104,"citation":104,"test":104,"related":[1575,3126]},"1018":{"spec":164,"test":164,"related":[3137]},"1019":{"spec":125,"test":125,"related":[3131]},"1020":{"spec":111,"citation":111,"test":111,"related":[1560,1562,3125]},"1021":{"spec":185,"citation":185,"test":185,"related":[1561,3130]},"1022":{"spec":150,"citation":150,"related":[1587]},"1023":{"spec":116,"test":116,"related":[3110]},"1024":{"spec":103,"citation":103,"related":[1433,1496,1510]},"1025":{"spec":163,"citation":163,"related":[1588]},"1026":{"spec":75,"citation":75,"test":75,"related":[1585,3129]},"1027":{"spec":86,"citation":86,"related":[1557]},"1028":{"spec":88,"citation":88,"test":88,"related":[1447,1458,1461,3104,3106]},"1029":{"spec":121,"citation":121,"test":121,"related":[1459,1462,3105,3107]},"1030":{"spec":130,"citation":130,"related":[1451]},"1031":{"spec":116,"citation":116,"related":[1449,1454]},"1032":{"spec":212,"incomplete":212,"todo":212,"related":[1393]},"1033":{"spec":117,"incomplete":117,"todo":117,"related":[1394]},"1034":{"spec":132,"citation":132,"related":[1457,1460]},"1035":{"spec":84,"citation":84,"test":84,"related":[1591,3132]},"1036":{"spec":137,"citation":137,"test":137,"related":[1592,3133]},"1037":{"spec":85,"citation":85,"test":85,"related":[1593,3124]},"1038":{"spec":263,"citation":263,"test":263,"related":[1594,3127]},"1039":{"spec":210,"test":210,"related":[3128]},"1040":{"spec":188,"citation":188,"test":188,"related":[1563,1564,1565,1566,3119,3120,3121,3122]},"1041":{"spec":39,"citation":39,"test":39,"related":[1567,1568,3117]},"1042":{"spec":154,"citation":154,"test":154,"related":[1569,3118]},"1043":{"spec":99,"incomplete":99,"todo":99,"related":[1385]},"1044":{"spec":182,"incomplete":182,"todo":182,"related":[1386]},"1045":{"spec":145,"incomplete":145,"todo":145,"related":[1387]},"1046":{"spec":92,"incomplete":92,"todo":92,"related":[1388]},"1047":{"spec":119,"incomplete":119,"todo":119,"related":[1389]},"1048":{"spec":126,"incomplete":126,"todo":126,"related":[1384]},"1049":{"spec":250,"citation":250,"related":[1465,1466]},"1050":{"spec":202,"citation":202,"related":[1719]},"1051":{"spec":126,"citation":126,"related":[1720]},"1052":{"spec":174,"citation":174,"related":[1813,1823]},"1053":{"spec":211,"citation":211,"related":[1814,1824]},"1054":{"spec":218,"citation":218,"related":[2357]},"1055":{"spec":109,"test":109,"related":[2826]},"1056":{"spec":108,"citation":108,"related":[2198]},"1057":{"spec":226,"incomplete":226,"todo":226,"related":[1399]},"1058":{"spec":349,"citation":349,"test":349,"related":[1919,2874]},"1059":{"spec":133,"incomplete":133,"todo":133,"related":[1395]},"1060":{"spec":153,"citation":153,"test":153,"related":[2158,2362,2363,2817]},"1061":{"spec":237,"citation":237,"related":[1873]},"1062":{"spec":176,"incomplete":176,"todo":176,"related":[1396]},"1063":{"spec":179,"incomplete":179,"todo":179,"related":[1397]},"1064":{"spec":128,"incomplete":128,"todo":128,"related":[1398]},"1065":{"spec":160,"citation":160,"related":[2165]},"1066":{"spec":151,"test":151,"related":[2816]},"1067":{"spec":191,"citation":191,"related":[1815,1825]},"1068":{"spec":114,"citation":114,"related":[1812]},"1069":{"spec":127,"citation":127,"related":[1822]},"1070":{"spec":197,"citation":197,"related":[1677]},"1071":{"spec":148,"incomplete":148,"todo":148,"related":[1400]},"1072":{"spec":303,"citation":303,"related":[1885]},"1073":{"spec":92,"citation":92,"related":[1886]},"1074":{"spec":141,"citation":141,"related":[1887]},"1075":{"spec":98,"citation":98,"related":[1888]},"1076":{"spec":89,"incomplete":89,"todo":89,"related":[1401]},"1077":{"spec":227,"citation":227,"related":[2487]},"1078":{"spec":125,"citation":125,"test":125,"related":[1741,2222,2224,3010,3012]},"1079":{"spec":81,"incomplete":81,"todo":81,"related":[1411]},"1080":{"spec":122,"citation":122,"related":[2296]},"1081":{"spec":102,"citation":102,"related":[2293]},"1082":{"spec":131,"citation":131,"related":[2272]},"1083":{"spec":62,"citation":62,"related":[2275,2344]},"1084":{"spec":146,"citation":146,"test":146,"related":[2273,2342,2886]},"1085":{"spec":113,"citation":113,"related":[2226]},"1086":{"spec":90,"citation":90,"related":[1854]},"1087":{"spec":177,"citation":177,"related":[1907]},"1088":{"spec":215,"citation":215,"related":[1912]},"1089":{"spec":169,"incomplete":169,"todo":169,"related":[1403]},"1090":{"spec":59,"incomplete":59,"todo":59,"related":[1404]},"1091":{"spec":179,"incomplete":179,"todo":179,"related":[1405]},"1092":{"spec":120,"incomplete":120,"todo":120,"related":[1412]},"1093":{"spec":99,"incomplete":99,"todo":99,"related":[1413]},"1094":{"spec":182,"citation":182,"related":[1908]},"1095":{"spec":182,"citation":182,"related":[1851]},"1096":{"spec":144,"citation":144,"related":[1853]},"1097":{"spec":98,"citation":98,"related":[1909]},"1098":{"spec":62,"incomplete":62,"todo":62,"related":[1416]},"1099":{"spec":111,"incomplete":111,"todo":111,"related":[1417]},"1100":{"spec":94,"citation":94,"test":94,"related":[2271,2887]},"1101":{"spec":197,"citation":197,"test":197,"related":[2269,2888]},"1102":{"spec":79,"citation":79,"related":[2481,2503]},"1103":{"spec":282,"citation":282,"related":[2483]},"1104":{"spec":132,"citation":132,"test":132,"related":[2484,2485,2504,2518,3057,3058]},"1105":{"spec":141,"citation":141,"related":[2505]},"1106":{"spec":133,"citation":133,"related":[2474]},"1107":{"spec":167,"citation":167,"related":[1905]},"1108":{"spec":87,"citation":87,"related":[1906,2507]},"1109":{"spec":314,"citation":314,"related":[2506]},"1110":{"spec":77,"citation":77,"related":[2508]},"1111":{"spec":155,"citation":155,"related":[2519]},"1112":{"spec":204,"citation":204,"test":204,"related":[2520,3060]},"1113":{"spec":174,"test":174,"related":[3059]},"1114":{"spec":128,"citation":128,"related":[2017,2521]},"1115":{"spec":123,"citation":123,"test":123,"related":[2523,3061,3062]},"1116":{"spec":188,"citation":188,"related":[2522]},"1117":{"spec":343,"citation":343,"related":[2018]},"1118":{"spec":140,"incomplete":140,"todo":140,"related":[1406]},"1119":{"spec":188,"incomplete":188,"todo":188,"related":[1402]},"1120":{"spec":252,"citation":252,"related":[2274,2343]},"1121":{"spec":235,"incomplete":235,"todo":235,"related":[1409]},"1122":{"spec":230,"incomplete":230,"todo":230,"related":[1407]},"1123":{"spec":189,"incomplete":189,"todo":189,"related":[1410]},"1124":{"spec":196,"incomplete":196,"todo":196,"related":[1408]},"1125":{"spec":590,"incomplete":590,"todo":590,"related":[1414]},"1126":{"spec":182,"incomplete":182,"todo":182,"related":[1415]},"1127":{"spec":157,"citation":157,"test":157,"related":[1650,1651,1652,2373,2993,3015,3016,3141,3142]},"1128":{"spec":69,"citation":69,"related":[2201,2204,2298]},"1129":{"spec":105,"citation":105,"related":[2208,2348]},"1130":{"spec":173,"citation":173,"related":[2229,2244,2246]},"1131":{"spec":235,"citation":235,"related":[2202]},"1132":{"spec":67,"citation":67,"test":67,"related":[2118,2120,2122,2812]},"1133":{"spec":112,"citation":112,"test":112,"related":[2088,2814,3099]},"1134":{"spec":146,"incomplete":146,"todo":146,"related":[1418]},"1135":{"spec":81,"citation":81,"test":81,"related":[1910,2119,2121,2123,2813,2815]},"1136":{"spec":53,"citation":53,"related":[1890]},"1137":{"spec":131,"incomplete":131,"todo":131,"related":[1420]},"1138":{"spec":229,"citation":229,"test":229,"related":[1430,3096]},"1139":{"spec":182,"citation":182,"related":[1852]},"1140":{"spec":103,"citation":103,"test":103,"related":[1911,3098]},"1141":{"spec":134,"citation":134,"related":[2196,2260,2265]},"1142":{"spec":127,"incomplete":127,"todo":127,"related":[1419]}},"refs":[{},{"todo":true},{"exception":true},{"exception":true,"todo":true},{"test":true},{"test":true,"todo":true},{"test":true,"exception":true},{"test":true,"exception":true,"todo":true},{"implication":true},{"implication":true,"todo":true},{"implication":true,"exception":true},{"implication":true,"exception":true,"todo":true},{"implication":true,"test":true},{"implication":true,"test":true,"todo":true},{"implication":true,"test":true,"exception":true},{"implication":true,"test":true,"exception":true,"todo":true},{"citation":true},{"citation":true,"todo":true},{"citation":true,"exception":true},{"citation":true,"exception":true,"todo":true},{"citation":true,"test":true},{"citation":true,"test":true,"todo":true},{"citation":true,"test":true,"exception":true},{"citation":true,"test":true,"exception":true,"todo":true},{"citation":true,"implication":true},{"citation":true,"implication":true,"todo":true},{"citation":true,"implication":true,"exception":true},{"citation":true,"implication":true,"exception":true,"todo":true},{"citation":true,"implication":true,"test":true},{"citation":true,"implication":true,"test":true,"todo":true},{"citation":true,"implication":true,"test":true,"exception":true},{"citation":true,"implication":true,"test":true,"exception":true,"todo":true},{"spec":true},{"spec":true,"todo":true},{"spec":true,"exception":true},{"spec":true,"exception":true,"todo":true},{"spec":true,"test":true},{"spec":true,"test":true,"todo":true},{"spec":true,"test":true,"exception":true},{"spec":true,"test":true,"exception":true,"todo":true},{"spec":true,"implication":true},{"spec":true,"implication":true,"todo":true},{"spec":true,"implication":true,"exception":true},{"spec":true,"implication":true,"exception":true,"todo":true},{"spec":true,"implication":true,"test":true},{"spec":true,"implication":true,"test":true,"todo":true},{"spec":true,"implication":true,"test":true,"exception":true},{"spec":true,"implication":true,"test":true,"exception":true,"todo":true},{"spec":true,"citation":true},{"spec":true,"citation":true,"todo":true},{"spec":true,"citation":true,"exception":true},{"spec":true,"citation":true,"exception":true,"todo":true},{"spec":true,"citation":true,"test":true},{"spec":true,"citation":true,"test":true,"todo":true},{"spec":true,"citation":true,"test":true,"exception":true},{"spec":true,"citation":true,"test":true,"exception":true,"todo":true},{"spec":true,"citation":true,"implication":true},{"spec":true,"citation":true,"implication":true,"todo":true},{"spec":true,"citation":true,"implication":true,"exception":true},{"spec":true,"citation":true,"implication":true,"exception":true,"todo":true},{"spec":true,"citation":true,"implication":true,"test":true},{"spec":true,"citation":true,"implication":true,"test":true,"todo":true},{"spec":true,"citation":true,"implication":true,"test":true,"exception":true},{"spec":true,"citation":true,"implication":true,"test":true,"exception":true,"todo":true},{"level":"MAY"},{"todo":true,"level":"MAY"},{"exception":true,"level":"MAY"},{"exception":true,"todo":true,"level":"MAY"},{"test":true,"level":"MAY"},{"test":true,"todo":true,"level":"MAY"},{"test":true,"exception":true,"level":"MAY"},{"test":true,"exception":true,"todo":true,"level":"MAY"},{"implication":true,"level":"MAY"},{"implication":true,"todo":true,"level":"MAY"},{"implication":true,"exception":true,"level":"MAY"},{"implication":true,"exception":true,"todo":true,"level":"MAY"},{"implication":true,"test":true,"level":"MAY"},{"implication":true,"test":true,"todo":true,"level":"MAY"},{"implication":true,"test":true,"exception":true,"level":"MAY"},{"implication":true,"test":true,"exception":true,"todo":true,"level":"MAY"},{"citation":true,"level":"MAY"},{"citation":true,"todo":true,"level":"MAY"},{"citation":true,"exception":true,"level":"MAY"},{"citation":true,"exception":true,"todo":true,"level":"MAY"},{"citation":true,"test":true,"level":"MAY"},{"citation":true,"test":true,"todo":true,"level":"MAY"},{"citation":true,"test":true,"exception":true,"level":"MAY"},{"citation":true,"test":true,"exception":true,"todo":true,"level":"MAY"},{"citation":true,"implication":true,"level":"MAY"},{"citation":true,"implication":true,"todo":true,"level":"MAY"},{"citation":true,"implication":true,"exception":true,"level":"MAY"},{"citation":true,"implication":true,"exception":true,"todo":true,"level":"MAY"},{"citation":true,"implication":true,"test":true,"level":"MAY"},{"citation":true,"implication":true,"test":true,"todo":true,"level":"MAY"},{"citation":true,"implication":true,"test":true,"exception":true,"level":"MAY"},{"citation":true,"implication":true,"test":true,"exception":true,"todo":true,"level":"MAY"},{"spec":true,"level":"MAY"},{"spec":true,"todo":true,"level":"MAY"},{"spec":true,"exception":true,"level":"MAY"},{"spec":true,"exception":true,"todo":true,"level":"MAY"},{"spec":true,"test":true,"level":"MAY"},{"spec":true,"test":true,"todo":true,"level":"MAY"},{"spec":true,"test":true,"exception":true,"level":"MAY"},{"spec":true,"test":true,"exception":true,"todo":true,"level":"MAY"},{"spec":true,"implication":true,"level":"MAY"},{"spec":true,"implication":true,"todo":true,"level":"MAY"},{"spec":true,"implication":true,"exception":true,"level":"MAY"},{"spec":true,"implication":true,"exception":true,"todo":true,"level":"MAY"},{"spec":true,"implication":true,"test":true,"level":"MAY"},{"spec":true,"implication":true,"test":true,"todo":true,"level":"MAY"},{"spec":true,"implication":true,"test":true,"exception":true,"level":"MAY"},{"spec":true,"implication":true,"test":true,"exception":true,"todo":true,"level":"MAY"},{"spec":true,"citation":true,"level":"MAY"},{"spec":true,"citation":true,"todo":true,"level":"MAY"},{"spec":true,"citation":true,"exception":true,"level":"MAY"},{"spec":true,"citation":true,"exception":true,"todo":true,"level":"MAY"},{"spec":true,"citation":true,"test":true,"level":"MAY"},{"spec":true,"citation":true,"test":true,"todo":true,"level":"MAY"},{"spec":true,"citation":true,"test":true,"exception":true,"level":"MAY"},{"spec":true,"citation":true,"test":true,"exception":true,"todo":true,"level":"MAY"},{"spec":true,"citation":true,"implication":true,"level":"MAY"},{"spec":true,"citation":true,"implication":true,"todo":true,"level":"MAY"},{"spec":true,"citation":true,"implication":true,"exception":true,"level":"MAY"},{"spec":true,"citation":true,"implication":true,"exception":true,"todo":true,"level":"MAY"},{"spec":true,"citation":true,"implication":true,"test":true,"level":"MAY"},{"spec":true,"citation":true,"implication":true,"test":true,"todo":true,"level":"MAY"},{"spec":true,"citation":true,"implication":true,"test":true,"exception":true,"level":"MAY"},{"spec":true,"citation":true,"implication":true,"test":true,"exception":true,"todo":true,"level":"MAY"},{"level":"SHOULD"},{"todo":true,"level":"SHOULD"},{"exception":true,"level":"SHOULD"},{"exception":true,"todo":true,"level":"SHOULD"},{"test":true,"level":"SHOULD"},{"test":true,"todo":true,"level":"SHOULD"},{"test":true,"exception":true,"level":"SHOULD"},{"test":true,"exception":true,"todo":true,"level":"SHOULD"},{"implication":true,"level":"SHOULD"},{"implication":true,"todo":true,"level":"SHOULD"},{"implication":true,"exception":true,"level":"SHOULD"},{"implication":true,"exception":true,"todo":true,"level":"SHOULD"},{"implication":true,"test":true,"level":"SHOULD"},{"implication":true,"test":true,"todo":true,"level":"SHOULD"},{"implication":true,"test":true,"exception":true,"level":"SHOULD"},{"implication":true,"test":true,"exception":true,"todo":true,"level":"SHOULD"},{"citation":true,"level":"SHOULD"},{"citation":true,"todo":true,"level":"SHOULD"},{"citation":true,"exception":true,"level":"SHOULD"},{"citation":true,"exception":true,"todo":true,"level":"SHOULD"},{"citation":true,"test":true,"level":"SHOULD"},{"citation":true,"test":true,"todo":true,"level":"SHOULD"},{"citation":true,"test":true,"exception":true,"level":"SHOULD"},{"citation":true,"test":true,"exception":true,"todo":true,"level":"SHOULD"},{"citation":true,"implication":true,"level":"SHOULD"},{"citation":true,"implication":true,"todo":true,"level":"SHOULD"},{"citation":true,"implication":true,"exception":true,"level":"SHOULD"},{"citation":true,"implication":true,"exception":true,"todo":true,"level":"SHOULD"},{"citation":true,"implication":true,"test":true,"level":"SHOULD"},{"citation":true,"implication":true,"test":true,"todo":true,"level":"SHOULD"},{"citation":true,"implication":true,"test":true,"exception":true,"level":"SHOULD"},{"citation":true,"implication":true,"test":true,"exception":true,"todo":true,"level":"SHOULD"},{"spec":true,"level":"SHOULD"},{"spec":true,"todo":true,"level":"SHOULD"},{"spec":true,"exception":true,"level":"SHOULD"},{"spec":true,"exception":true,"todo":true,"level":"SHOULD"},{"spec":true,"test":true,"level":"SHOULD"},{"spec":true,"test":true,"todo":true,"level":"SHOULD"},{"spec":true,"test":true,"exception":true,"level":"SHOULD"},{"spec":true,"test":true,"exception":true,"todo":true,"level":"SHOULD"},{"spec":true,"implication":true,"level":"SHOULD"},{"spec":true,"implication":true,"todo":true,"level":"SHOULD"},{"spec":true,"implication":true,"exception":true,"level":"SHOULD"},{"spec":true,"implication":true,"exception":true,"todo":true,"level":"SHOULD"},{"spec":true,"implication":true,"test":true,"level":"SHOULD"},{"spec":true,"implication":true,"test":true,"todo":true,"level":"SHOULD"},{"spec":true,"implication":true,"test":true,"exception":true,"level":"SHOULD"},{"spec":true,"implication":true,"test":true,"exception":true,"todo":true,"level":"SHOULD"},{"spec":true,"citation":true,"level":"SHOULD"},{"spec":true,"citation":true,"todo":true,"level":"SHOULD"},{"spec":true,"citation":true,"exception":true,"level":"SHOULD"},{"spec":true,"citation":true,"exception":true,"todo":true,"level":"SHOULD"},{"spec":true,"citation":true,"test":true,"level":"SHOULD"},{"spec":true,"citation":true,"test":true,"todo":true,"level":"SHOULD"},{"spec":true,"citation":true,"test":true,"exception":true,"level":"SHOULD"},{"spec":true,"citation":true,"test":true,"exception":true,"todo":true,"level":"SHOULD"},{"spec":true,"citation":true,"implication":true,"level":"SHOULD"},{"spec":true,"citation":true,"implication":true,"todo":true,"level":"SHOULD"},{"spec":true,"citation":true,"implication":true,"exception":true,"level":"SHOULD"},{"spec":true,"citation":true,"implication":true,"exception":true,"todo":true,"level":"SHOULD"},{"spec":true,"citation":true,"implication":true,"test":true,"level":"SHOULD"},{"spec":true,"citation":true,"implication":true,"test":true,"todo":true,"level":"SHOULD"},{"spec":true,"citation":true,"implication":true,"test":true,"exception":true,"level":"SHOULD"},{"spec":true,"citation":true,"implication":true,"test":true,"exception":true,"todo":true,"level":"SHOULD"},{"level":"MUST"},{"todo":true,"level":"MUST"},{"exception":true,"level":"MUST"},{"exception":true,"todo":true,"level":"MUST"},{"test":true,"level":"MUST"},{"test":true,"todo":true,"level":"MUST"},{"test":true,"exception":true,"level":"MUST"},{"test":true,"exception":true,"todo":true,"level":"MUST"},{"implication":true,"level":"MUST"},{"implication":true,"todo":true,"level":"MUST"},{"implication":true,"exception":true,"level":"MUST"},{"implication":true,"exception":true,"todo":true,"level":"MUST"},{"implication":true,"test":true,"level":"MUST"},{"implication":true,"test":true,"todo":true,"level":"MUST"},{"implication":true,"test":true,"exception":true,"level":"MUST"},{"implication":true,"test":true,"exception":true,"todo":true,"level":"MUST"},{"citation":true,"level":"MUST"},{"citation":true,"todo":true,"level":"MUST"},{"citation":true,"exception":true,"level":"MUST"},{"citation":true,"exception":true,"todo":true,"level":"MUST"},{"citation":true,"test":true,"level":"MUST"},{"citation":true,"test":true,"todo":true,"level":"MUST"},{"citation":true,"test":true,"exception":true,"level":"MUST"},{"citation":true,"test":true,"exception":true,"todo":true,"level":"MUST"},{"citation":true,"implication":true,"level":"MUST"},{"citation":true,"implication":true,"todo":true,"level":"MUST"},{"citation":true,"implication":true,"exception":true,"level":"MUST"},{"citation":true,"implication":true,"exception":true,"todo":true,"level":"MUST"},{"citation":true,"implication":true,"test":true,"level":"MUST"},{"citation":true,"implication":true,"test":true,"todo":true,"level":"MUST"},{"citation":true,"implication":true,"test":true,"exception":true,"level":"MUST"},{"citation":true,"implication":true,"test":true,"exception":true,"todo":true,"level":"MUST"},{"spec":true,"level":"MUST"},{"spec":true,"todo":true,"level":"MUST"},{"spec":true,"exception":true,"level":"MUST"},{"spec":true,"exception":true,"todo":true,"level":"MUST"},{"spec":true,"test":true,"level":"MUST"},{"spec":true,"test":true,"todo":true,"level":"MUST"},{"spec":true,"test":true,"exception":true,"level":"MUST"},{"spec":true,"test":true,"exception":true,"todo":true,"level":"MUST"},{"spec":true,"implication":true,"level":"MUST"},{"spec":true,"implication":true,"todo":true,"level":"MUST"},{"spec":true,"implication":true,"exception":true,"level":"MUST"},{"spec":true,"implication":true,"exception":true,"todo":true,"level":"MUST"},{"spec":true,"implication":true,"test":true,"level":"MUST"},{"spec":true,"implication":true,"test":true,"todo":true,"level":"MUST"},{"spec":true,"implication":true,"test":true,"exception":true,"level":"MUST"},{"spec":true,"implication":true,"test":true,"exception":true,"todo":true,"level":"MUST"},{"spec":true,"citation":true,"level":"MUST"},{"spec":true,"citation":true,"todo":true,"level":"MUST"},{"spec":true,"citation":true,"exception":true,"level":"MUST"},{"spec":true,"citation":true,"exception":true,"todo":true,"level":"MUST"},{"spec":true,"citation":true,"test":true,"level":"MUST"},{"spec":true,"citation":true,"test":true,"todo":true,"level":"MUST"},{"spec":true,"citation":true,"test":true,"exception":true,"level":"MUST"},{"spec":true,"citation":true,"test":true,"exception":true,"todo":true,"level":"MUST"},{"spec":true,"citation":true,"implication":true,"level":"MUST"},{"spec":true,"citation":true,"implication":true,"todo":true,"level":"MUST"},{"spec":true,"citation":true,"implication":true,"exception":true,"level":"MUST"},{"spec":true,"citation":true,"implication":true,"exception":true,"todo":true,"level":"MUST"},{"spec":true,"citation":true,"implication":true,"test":true,"level":"MUST"},{"spec":true,"citation":true,"implication":true,"test":true,"todo":true,"level":"MUST"},{"spec":true,"citation":true,"implication":true,"test":true,"exception":true,"level":"MUST"},{"spec":true,"citation":true,"implication":true,"test":true,"exception":true,"todo":true,"level":"MUST"}]}