MUST NOT Requirements: MN-1: 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. MN-2: A QUIC endpoint **MUST NOT** reuse a stream ID within a connection. MN-3: The data at a given offset **MUST NOT** change if it is sent multiple times; an endpoint MAY treat receipt of different data at the same offset within a stream as a connection error of type PROTOCOL_VIOLATION. MN-4: An endpoint **MUST NOT** send data on any stream without ensuring that it is within the flow control limits set by its peer. MN-5: A sender **MUST NOT** send any of these frames from a terminal state ("Data Recvd" or "Reset Recvd"). MN-6: A sender **MUST NOT** send a STREAM or STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or any terminal state, that is, after sending a RESET_STREAM frame. MN-7: Therefore, a receiver **MUST NOT** wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the sender being blocked for the rest of the connection. MN-8: An endpoint **MUST NOT** send data on a stream at or beyond the final size. MN-9: Endpoints **MUST NOT** exceed the limit set by their peer. MN-10: An endpoint **MUST NOT** wait to receive this signal before advertising additional credit, since doing so will mean that the peer will be blocked for at least an entire round trip, and potentially for longer if the peer chooses to not send STREAMS_BLOCKED frames. MN-11: Connection IDs **MUST NOT** contain any information that can be used by an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same connection. MN-12: As a trivial example, this means the same connection ID **MUST NOT** be issued more than once on the same connection. MN-13: 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 connection migration, NAT rebinding, and client port reuse; and therefore **MUST NOT** be done unless an endpoint is certain that those protocol features are not in use. MN-14: An endpoint **MUST NOT** provide more connection IDs than the peer's limit. MN-15: An endpoint **MUST NOT** forget a connection ID without retiring it, though it MAY choose to treat having connection IDs in need of retirement that exceed this limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. MN-16: An endpoint **MUST NOT** send a Version Negotiation packet in response to receiving a Version Negotiation packet. MN-17: Note that this mechanism does not protect against downgrade attacks and **MUST NOT** be used outside of draft implementations. MN-18: An endpoint **MUST NOT** send a parameter more than once in a given transport parameters extension. MN-19: The definition of new transport parameters (Section 7.4.2) MUST specify whether they MUST, MAY, or **MUST NOT** be stored for 0-RTT. MN-20: A client **MUST NOT** use remembered values for the following parameters: ack_delay_exponent, max_ack_delay, initial_source_connection_id, original_destination_connection_id, preferred_address, retry_source_connection_id, and stateless_reset_token. MN-21: If 0-RTT data is accepted by the server, the server **MUST NOT** reduce any limits or alter any values that might be violated by the client with its 0-RTT data. MN-22: In particular, a server that accepts 0-RTT data **MUST NOT** set values for the following parameters (Section 18.2) that are smaller than the remembered value of the parameters. MN-23: When sending frames in 0-RTT packets, a client MUST only use remembered transport parameters; importantly, it **MUST NOT** use updated values that it learns from the server's updated transport parameters or from frames received in 1-RTT packets. MN-24: Prior to validating the client address, servers **MUST NOT** send more than three times as many bytes as the number of bytes they have received. MN-25: The client **MUST NOT** use the token provided in a Retry for future connections. MN-26: A token issued with NEW_TOKEN **MUST NOT** include information that would allow values to be linked by an observer to the connection on which it was issued, unless the values are encrypted. MN-27: A client **MUST NOT** include a token that is not applicable to the server that it is connecting to, unless the client has the knowledge that the server that issued the token and the server the client is connecting to are jointly managing the tokens. MN-28: An endpoint **MUST NOT** send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see Section 13.3. MN-29: An endpoint **MUST NOT** initiate connection migration before the handshake is confirmed, as defined in section 4.1.2 of [QUIC-TLS]. MN-30: If the peer sent the disable_active_migration transport parameter, an endpoint also **MUST NOT** send packets (including probing packets; see Section 9.1) from a different local address to the address the peer used during the handshake. MN-31: The endpoint **MUST NOT** send more than a minimum congestion window's worth of data per estimated round-trip time (kMinimumWindow, as defined in [QUIC-RECOVERY]). MN-32: Packets sent on the old path **MUST NOT** contribute to congestion control or RTT estimation for the new path. MN-33: This timer SHOULD be set as described in Section 6.2.1 of [QUIC-RECOVERY] and **MUST NOT** be more aggressive. MN-34: An endpoint **MUST NOT** reuse a connection ID when sending from more than one local address, for example when initiating connection migration as described in Section 9.2 or when probing a new network path as described in Section 9.1. MN-35: Similarly, an endpoint **MUST NOT** reuse a connection ID when sending to more than one destination address. MN-36: A client **MUST NOT** use these for other connections, including connections that are resumed from the current connection. MN-37: Servers **MUST NOT** send more than a minimum congestion window's worth of non-probing packets to the new address before path validation is complete. MN-38: While closing, an endpoint **MUST NOT** send packets unless they contain a CONNECTION_CLOSE frame; see Section 10.3 for details. MN-39: While otherwise identical to the closing state, an endpoint in the draining state **MUST NOT** send any packets. MN-40: An endpoint **MUST NOT** send further packets, which could result in a constant exchange of CONNECTION_CLOSE frames until the closing period on either peer ended. MN-41: An endpoint **MUST NOT** send a stateless reset that is three times or more larger than the packet it receives to avoid being used for amplification. MN-42: An endpoint **MUST NOT** check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired. MN-43: This method for choosing the Stateless Reset Token means that the combination of connection ID and static key **MUST NOT** be used for another connection. MN-44: A connection ID from a connection that is reset by revealing the Stateless Reset Token **MUST NOT** be reused for new connections at nodes that share a static key. MN-45: The same Stateless Reset Token **MUST NOT** be used for multiple connection IDs. MN-46: A stateless reset **MUST NOT** be used by an endpoint that has the state necessary to send a frame on the connection. MN-47: Senders **MUST NOT** coalesce QUIC packets for different connections into a single UDP datagram. MN-48: A QUIC endpoint **MUST NOT** reuse a packet number within the same packet number space in one connection. MN-49: A packet **MUST NOT** be acknowledged until packet protection has been successfully removed and all frames contained in the packet have been processed. MN-50: Since packets containing only ACK frames are not congestion controlled, an endpoint **MUST NOT** send more than one such packet in response to receiving an ack-eliciting packet. MN-51: An endpoint **MUST NOT** send a non-ack-eliciting packet in response to a non-ack-eliciting packet, even if there are packet gaps which precede the received packet. MN-52: A receiver **MUST NOT** bundle an ack-eliciting frame with all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. MN-53: An endpoint **MUST NOT** include delays that it does not control when populating the Ack Delay field in an ACK frame. MN-54: The content of a RESET_STREAM frame **MUST NOT** change when it is sent again. MN-55: UDP datagrams **MUST NOT** be fragmented at the IP layer. MN-56: An endpoint **MUST NOT** increase PMTU based on ICMP messages; see Section 3, clause 6 of [DPLPMTUD]. MN-57: In QUIC version 1, this value **MUST NOT** exceed 20. MN-58: In QUIC version 1, this value **MUST NOT** exceed 20 bytes. MN-59: A server **MUST NOT** send more than one Version Negotiation packet in response to a single UDP datagram. MN-60: A client **MUST NOT** reset the packet number it uses for 0-RTT packets, since the keys used to protect 0-RTT packets will not change as a result of responding to a Retry packet. MN-61: A client **MUST NOT** send 0-RTT packets once it starts processing 1-RTT packets from the server. MN-62: This value **MUST NOT** be equal to the Destination Connection ID field of the packet sent by the client. MN-63: A server **MUST NOT** send more than one Retry packet in response to a single UDP datagram. MN-64: The client **MUST NOT** change the Source Connection ID because the server could include the connection ID as part of its token validation logic; see Section 8.1.4. MN-65: A client **MUST NOT** change the cryptographic handshake message it sends in response to receiving a Retry. MN-66: A client **MUST NOT** reset the packet number for any packet number space after processing a Retry packet; Section 17.2.3 contains more information on this. MN-67: This transport parameter **MUST NOT** be sent by a client, but MAY be sent by a server. MN-68: When a peer sets this transport parameter, an endpoint **MUST NOT** use a new local address when sending to the address that the peer used during the handshake. MN-69: A server that chooses a zero-length connection ID **MUST NOT** provide a preferred address. MN-70: Similarly, a server **MUST NOT** include a zero- length connection ID in this transport parameter. MN-71: A client **MUST NOT** include any server-only transport parameter: original_destination_connection_id, preferred_address, retry_source_connection_id, or stateless_reset_token. MN-72: The token **MUST NOT** be empty. MN-73: Clients **MUST NOT** send NEW_TOKEN frames. MN-74: The sum of the largest received offsets on all streams - including streams in terminal states - **MUST NOT** exceed the value advertised by a receiver. MN-75: The data sent on a stream **MUST NOT** exceed the largest maximum stream data value advertised by the receiver. MN-76: An endpoint **MUST NOT** open more streams than permitted by the current stream limit set by its peer. MN-77: An endpoint **MUST NOT** send this frame if it currently requires that its peer send packets with a zero-length Destination Connection ID. MN-78: Receipt of the same frame multiple times **MUST NOT** be treated as a connection error. MN-79: The sequence number specified in a RETIRE_CONNECTION_ID frame **MUST NOT** refer to the Destination Connection ID field of the packet in which the frame is contained. MN-80: Servers **MUST NOT** send a HANDSHAKE_DONE frame before completing the handshake. MN-81: If any use of the codepoints is identified by this search or a request to update the registration is made, the codepoint **MUST NOT** be reclaimed. MN-82: Additionally, each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved and **MUST NOT** be assigned by IANA. SHALL NOT Requirements: ShaN-1: 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. SHOULD NOT Requirements: SN-1: 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. SN-2: Endpoints **SHOULD NOT** issue updates of the Retire Prior To field before receiving RETIRE_CONNECTION_ID frames that retire all connection IDs indicated by the previous Retire Prior To value. SN-3: Servers **SHOULD NOT** attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. SN-4: A client **SHOULD NOT** reuse a NEW_TOKEN token for different connection attempts. SN-5: Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to be valid for longer, but **SHOULD NOT** be accepted multiple times in a short period. SN-6: However, an endpoint **SHOULD NOT** send multiple PATH_CHALLENGE frames in a single packet. SN-7: An endpoint **SHOULD NOT** send a PATH_CHALLENGE more frequently than it would an Initial packet, ensuring that connection migration is no more load on a new path than establishing a new connection. SN-8: An endpoint **SHOULD NOT** initiate migration with a peer that has requested a zero-length connection ID, because traffic over the new path might be trivially linkable to traffic over the old one. SN-9: Servers that retain an open socket for accepting new connections **SHOULD NOT** exit the closing or draining period early. SN-10: An endpoint **SHOULD NOT** coalesce multiple packets at the same encryption level. SN-11: The endpoint **SHOULD NOT** continue sending ACK frames immediately unless more ack-eliciting packets are received out of order. SN-12: An endpoint **SHOULD NOT** perform this validation if this ACK frame does not advance the largest packet number acknowledged in this connection. SN-13: In the absence of these mechanisms, QUIC endpoints **SHOULD NOT** send IP packets larger than the smallest allowed maximum packet size. SN-14: Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and **SHOULD NOT** trigger a congestion control reaction; see Section 3, Bullet 7 of [DPLPMTUD]. SN-15: This means that client- controlled fields, such as the initial Destination Connection ID used on Initial and 0-RTT packets **SHOULD NOT** be used by themselves to make routing decisions. SN-16: This SHOULD be done only for the codepoints with the earliest recorded date and entries that have been updated less than a year prior **SHOULD NOT** be reclaimed. NOT RECOMMENDED Requirements: NRec-1: 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. MUST Requirements: MUST-1: 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. MUST-2: Endpoints **MUST** be able to deliver stream data to an application as an ordered byte-stream. MUST-3: There are certain operations that an application **MUST** be able to perform when interacting with QUIC streams. MUST-4: This document does not specify an API, but any implementation of this version of QUIC **MUST** expose the ability to perform the operations described in this section on a QUIC stream. MUST-5: An endpoint **MUST** open streams of the same type in increasing order of stream ID. MUST-6: Before a stream is created, all streams of the same type with lower- numbered stream IDs **MUST** be created. MUST-7: An endpoint that receives a STOP_SENDING frame **MUST** send a RESET_STREAM frame if the stream is in the Ready or Send state. MUST-8: If the STOP_SENDING frame is received on a stream that is already in the "Data Sent" state, an endpoint that wishes to cease retransmission of previously-sent STREAM frames on that stream **MUST** first send a RESET_STREAM frame. MUST-9: A receiver **MUST** close the connection with a FLOW_CONTROL_ERROR error (Section 11) if the sender violates the advertised connection or stream data limits. MUST-10: A sender **MUST** ignore any MAX_STREAM_DATA or MAX_DATA frames that do not increase flow control limits. MUST-11: On receiving a RESET_STREAM frame, a receiver definitively knows how many bytes were sent on that stream before the RESET_STREAM frame, and the receiver **MUST** use the final size of the stream to account for all bytes sent on the stream in its connection level flow controller. MUST-12: Both endpoints **MUST** maintain flow control state for the stream in the unterminated direction until that direction enters a terminal state, or until one of the endpoints sends CONNECTION_CLOSE. MUST-13: If either is received, the connection **MUST** be closed immediately with a connection error of type STREAM_LIMIT_ERROR; see Section 10.3. MUST-14: An endpoint that receives a frame with a stream ID exceeding the limit it has sent **MUST** treat this as a connection error of type STREAM_LIMIT_ERROR (Section 11). MUST-15: A receiver **MUST** ignore any MAX_STREAMS frame that does not increase the stream limit. MUST-16: The sequence number on each newly-issued connection ID **MUST** increase by 1. MUST-17: When an endpoint issues a connection ID, it **MUST** accept packets that carry this connection ID for the duration of the connection or until its peer invalidates the connection ID via a RETIRE_CONNECTION_ID frame (Section 19.16). MUST-18: After processing a NEW_CONNECTION_ID frame and adding and retiring active connection IDs, if the number of active connection IDs exceeds the value advertised in its active_connection_id_limit transport parameter, an endpoint **MUST** close the connection with an error of type CONNECTION_ID_LIMIT_ERROR. MUST-19: Upon receipt of an increased Retire Prior To field, the peer **MUST** stop using the corresponding connection IDs and retire them with RETIRE_CONNECTION_ID frames before adding the newly provided connection ID to the set of active connection IDs. MUST-20: An endpoint **MUST** generate a connection error if it commits changes to state before discovering an error. MUST-21: If a client receives a packet that has an unsupported version, it **MUST** discard that packet. MUST-22: Servers **MUST** drop smaller packets that specify unsupported versions. MUST-23: Servers **MUST** drop incoming packets under all other circumstances. MUST-24: Server deployments that use this simple form of load balancing **MUST** avoid the creation of a stateless reset oracle; see Section 21.9. MUST-25: There are certain operations that an application **MUST** be able to perform when interacting with the QUIC transport. MUST-26: This document does not specify an API, but any implementation of this version of QUIC **MUST** expose the ability to perform the operations described in this section on a QUIC connection. MUST-27: A client that supports only this version of QUIC **MUST** abandon the current connection attempt if it receives a Version Negotiation packet, with the following two exceptions. MUST-28: A client **MUST** discard any Version Negotiation packet if it has received and successfully. MUST-29: A client **MUST** discard a Version Negotiation packet that lists the QUIC version selected by the client. MUST-30: The client **MUST** check that the Destination and Source Connection ID fields match the Source and Destination Connection ID fields in a packet that the client sent. MUST-31: If this check fails, the packet **MUST** be discarded. MUST-32: The new connection **MUST** use a new random Destination Connection ID different from the one it had previously sent. MUST-33: The cryptographic handshake **MUST** provide the following properties:. MUST-34: Endpoints **MUST** explicitly negotiate an application protocol. MUST-35: This Destination Connection ID **MUST** be at least 8 bytes in length. MUST-36: Until a packet is received from the server, the client **MUST** use the same Destination Connection ID value on all packets in this connection. MUST-37: Once a client has received a valid Initial packet from the server, it **MUST** discard any subsequent packet it receives with a different Source Connection ID. MUST-38: A client **MUST** change the Destination Connection ID it uses for sending packets in response to only the first received Initial or Retry packet. MUST-39: A server **MUST** set the Destination Connection ID it uses for sending packets based on the first received Initial packet. MUST-40: Any further changes to the Destination Connection ID are only permitted if the values are taken from any received NEW_CONNECTION_ID frames; if subsequent Initial packets include a different Source Connection ID, they **MUST** be discarded. MUST-41: The values provided by a peer for these transport parameters **MUST** match the values that an endpoint used in the Destination and Source Connection ID fields of Initial packets that it sent. MUST-42: An endpoint **MUST** treat absence of the initial_source_connection_id transport parameter from either endpoint or absence of the original_destination_connection_id transport parameter from the server as a connection error of type TRANSPORT_PARAMETER_ERROR. MUST-43: An endpoint **MUST** treat the following as a connection error of type TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:. MUST-44: An endpoint **MUST** treat receipt of a transport parameter with an invalid value as a connection error of type TRANSPORT_PARAMETER_ERROR. MUST-45: The definition of new transport parameters (Section 7.4.2) **MUST** specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. MUST-46: The definition of new transport parameters (Section 7.4.2) MUST specify whether they **MUST**, MAY, or MUST NOT be stored for 0-RTT. MUST-47: The client **MUST** use the server's new values in the handshake instead, and absent new values from the server, the default value. MUST-48: A client that attempts to send 0-RTT data **MUST** remember all other transport parameters used by the server. MUST-49: A server **MUST** either reject 0-RTT data or abort a handshake if the implied values for transport parameters cannot be supported. MUST-50: When sending frames in 0-RTT packets, a client **MUST** only use remembered transport parameters; importantly, it MUST NOT use updated values that it learns from the server's updated transport parameters or from frames received in 1-RTT packets. MUST-51: An endpoint **MUST** ignore transport parameters that it does not support. MUST-52: Implementations **MUST** support buffering at least 4096 bytes of data received in out of order CRYPTO frames. MUST-53: If an endpoint does not expand its buffer, it **MUST** close the connection with a CRYPTO_BUFFER_EXCEEDED error code. MUST-54: Packets containing discarded CRYPTO frames **MUST** be acknowledged because the packet has been received and processed by the transport even though the CRYPTO frame was discarded. MUST-55: For the purposes of avoiding amplification prior to address validation, servers **MUST** count all of the payload bytes received in datagrams that are uniquely attributed to a single connection. MUST-56: Clients **MUST** ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary. MUST-57: To prevent this deadlock, clients **MUST** send a packet on a probe timeout (PTO, see Section 6.2 of [QUIC-RECOVERY]). MUST-58: Specifically, the client **MUST** send an Initial packet in a UDP datagram that contains at least 1200 bytes if it does not have Handshake keys, and otherwise send a Handshake packet. MUST-59: A token sent in a NEW_TOKEN frames or a Retry packet **MUST** be constructed in a way that allows the server to identify how it was provided to a client. MUST-60: This token **MUST** be repeated by the client in all Initial packets it sends for that connection after it receives the Retry packet. MUST-61: The client **MUST** include the token in all Initial packets it sends, unless a Retry replaces the token with a newer one. MUST-62: A server **MUST** ensure that every NEW_TOKEN frame it sends is unique across all clients, with the exception of those sent to repair losses of previously sent NEW_TOKEN frames. MUST-63: In comparison, a token obtained in a Retry packet **MUST** be used immediately during the connection attempt and cannot be used in subsequent connection attempts. MUST-64: When a server receives an Initial packet with an address validation token, it **MUST** attempt to validate the token, unless it has already completed address validation. MUST-65: An address validation token **MUST** be difficult to guess. MUST-66: For this design to work, the token **MUST** be covered by integrity protection against modification or falsification by clients. MUST-67: Tokens sent in NEW_TOKEN frames **MUST** include information that allows the server to verify that the client IP address has not changed from when the token was issued. MUST-68: If the client IP address has changed, the server **MUST** adhere to the anti-amplification limits found in Section 8.1. MUST-69: Servers **MUST** ensure that replay of tokens is prevented or limited. MUST-70: The endpoint **MUST** use unpredictable data in every PATH_CHALLENGE frame so that it can associate the peer's response with the corresponding PATH_CHALLENGE. MUST-71: On receiving a PATH_CHALLENGE frame, an endpoint **MUST** respond immediately by echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. MUST-72: An endpoint that has sent this transport parameter, but detects that a peer has nonetheless migrated to a different remote address **MUST** either drop the incoming packets on that path without generating a stateless reset or proceed with path validation and allow the peer to migrate. MUST-73: An endpoint **MUST** perform path validation (Section 8.2) if it detects any change to a peer's address, unless it has previously validated that address. MUST-74: If a client receives packets from an unknown server address, the client **MUST** discard these packets. MUST-75: In response to such a packet, an endpoint **MUST** start sending subsequent packets to the new peer address and MUST initiate path validation (Section 8.2) to verify the peer's ownership of the unvalidated address. MUST-76: In response to such a packet, an endpoint MUST start sending subsequent packets to the new peer address and **MUST** initiate path validation (Section 8.2) to verify the peer's ownership of the unvalidated address. MUST-77: An endpoint MAY send data to an unvalidated peer address, but it **MUST** protect against potential attacks as described in Section 9.3.1 and Section 9.3.2. MUST-78: Until a peer's address is deemed valid, an endpoint **MUST** limit the rate at which it sends data to this address. MUST-79: To protect the connection from failing due to such a spurious migration, an endpoint **MUST** revert to using the last validated peer address when validation of a new peer address fails. MUST-80: If an endpoint has no state about the last validated peer address, it **MUST** close the connection silently by discarding all connection state. MUST-81: In response to an apparent migration, endpoints **MUST** validate the previously active path using a PATH_CHALLENGE frame. MUST-82: On confirming a peer's ownership of its new address, an endpoint **MUST** immediately reset the congestion controller and round-trip time estimator for the new path to initial values (see Sections A.3 and B.3 in [QUIC-RECOVERY]) unless it has knowledge that a previous send rate or round-trip time estimate is valid for the new path. MUST-83: If path validation fails, the client **MUST** continue sending all future packets to the server's original IP address. MUST-84: The server **MUST** send other non-probing frames from its original address until it receives a non-probing packet from the client at its preferred address and until the server has validated the new path. MUST-85: The server **MUST** probe on the path toward the client from its preferred address. MUST-86: If path validation of the server's preferred address succeeds, the client **MUST** abandon validation of the original address and migrate to using the server's preferred address. MUST-87: If the connection to the server's preferred address is not from the same client address, the server **MUST** protect against potential attacks as described in Section 9.3.1 and Section 9.3.2. MUST-88: The flow label generation **MUST** be designed to minimize the chances of linkability with a previously used flow label, as this would enable correlating activity on multiple paths; see Section 9.5. MUST-89: An endpoint in the closing state **MUST** strictly limit the number of packets it sends to this new address until the address is validated; see Section 8.2. MUST-90: To avoid creating an unwitting amplification attack, such endpoints **MUST** reduce the frequency with which it sends packets containing a CONNECTION_CLOSE frame. MUST-91: To avoid this, endpoints **MUST** either limit transmission of CONNECTION_CLOSE frames to validated addresses or drop packets without response if the response would be more than three times larger than the received packet. MUST-92: After the handshake is confirmed (see Section 4.1.2 of [QUIC-TLS]), an endpoint **MUST** send any CONNECTION_CLOSE frames in a 1-RTT packet. MUST-93: A CONNECTION_CLOSE of type 0x1d **MUST** be replaced by a CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or Handshake packets. MUST-94: Endpoints **MUST** clear the value of the Reason Phrase field and SHOULD use the APPLICATION_ERROR code when converting to a CONNECTION_CLOSE of type 0x1c. MUST-95: An endpoint that wishes to communicate a fatal connection error **MUST** use a CONNECTION_CLOSE frame if it has sufficient state to do so. MUST-96: Endpoints **MUST** discard packets that are too small to be valid QUIC packets. MUST-97: Endpoints **MUST** send stateless reset packets formatted as a packet with a short header. MUST-98: However, endpoints **MUST** treat any packet ending in a valid stateless reset token as a stateless reset, as other QUIC versions might allow the use of a long header. MUST-99: However, the comparison **MUST** be performed when the first packet in an incoming datagram either cannot be associated with a connection, or cannot be decrypted. MUST-100: When comparing a datagram to Stateless Reset Token values, endpoints **MUST** perform the comparison without leaking information about the value of the token. MUST-101: If the last 16 bytes of the datagram are identical in value to a Stateless Reset Token, the endpoint **MUST** enter the draining period and not send any further packets on this connection. MUST-102: The stateless reset token **MUST** be difficult to guess. MUST-103: An endpoint that uses this design **MUST** either use the same connection ID length for all connections or encode the length of the connection ID such that it can be recovered without state. MUST-104: An endpoint **MUST** ensure that every Stateless Reset that it sends is smaller than the packet which triggered it, unless it maintains state sufficient to prevent looping. MUST-105: Errors that result in the connection being unusable, such as an obvious violation of protocol semantics or corruption of state that affects an entire connection, **MUST** be signaled using a CONNECTION_CLOSE frame (Section 19.19). MUST-106: RESET_STREAM **MUST** only be instigated by the application protocol that uses QUIC. MUST-107: Receivers **MUST** be able to process coalesced packets. MUST-108: The receiver of coalesced QUIC packets **MUST** individually process each QUIC packet and separately acknowledge them, as if they were received as the payload of different UDP datagrams. MUST-109: For example, if decryption fails (because the keys are not available or any other reason), the receiver MAY either discard or buffer the packet for later processing and **MUST** attempt to process the remaining packets. MUST-110: Subsequent packets sent in the same packet number space **MUST** increase the packet number by at least one. MUST-111: If the packet number for sending reaches 2^62 - 1, the sender **MUST** close the connection without sending a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send a Stateless Reset (Section 10.4) in response to further packets that it receives. MUST-112: A receiver **MUST** discard a newly unprotected packet unless it is certain that it has not processed another packet with the same packet number from the same packet number space. MUST-113: Duplicate suppression **MUST** happen after removing packet protection for the reasons described in Section 9.3 of [QUIC-TLS]. MUST-114: The payload of a packet that contains frames **MUST** contain at least one frame, and MAY contain multiple frames and multiple frame types. MUST-115: An endpoint **MUST** treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR. MUST-116: To ensure simple and efficient implementations of frame parsing, a frame type **MUST** use the shortest possible encoding. MUST-117: Every packet SHOULD be acknowledged at least once, and ack-eliciting packets **MUST** be acknowledged at least once within the maximum ack delay. MUST-118: A receiver **MUST** retain an ACK Range unless it can ensure that it will not subsequently accept packets with numbers in that range. MUST-119: Receivers can discard all ACK Ranges, but they **MUST** retain the largest packet number that has been successfully processed as that is used to recover packet numbers from subsequent packets; see Section 17.1. MUST-120: ACK frames **MUST** only be carried in a packet that has the same packet number space as the packet being ACKed; see Section 12.1. MUST-121: For instance, packets that are protected with 1-RTT keys **MUST** be acknowledged in packets that are also protected with 1-RTT keys. MUST-122: Packets that a client sends with 0-RTT packet protection **MUST** be acknowledged by the server in packets protected by 1-RTT keys. MUST-123: * The HANDSHAKE_DONE frame **MUST** be retransmitted until it is acknowledged. MUST-124: A receiver **MUST** accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. MUST-125: Upon detecting losses, a sender **MUST** take appropriate congestion control action. MUST-126: Even if an endpoint does not use ECN markings on packets it transmits, the endpoint **MUST** provide feedback about ECN markings received from the peer if they are accessible. MUST-127: An endpoint that sets ECT(0) or ECT(1) codepoints on packets it transmits **MUST** use the following steps on receiving an ACK frame to validate ECN. MUST-128: * For validation to succeed, the total increase in ECT(0), ECT(1), and CE counts **MUST** be no smaller than the total number of QUIC packets sent with an ECT codepoint that are newly acknowledged in this ACK frame. MUST-129: * Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE count, **MUST** be no smaller than the number of packets sent with the corresponding ECT codepoint that are newly acknowledged in this ACK frame. MUST-130: When this happens, and if validation succeeds, the local reference counts **MUST** be increased to match the counts in the ACK frame. MUST-131: Network routing and path elements can change mid- connection however; an endpoint **MUST** disable ECN if validation fails at any point in the connection. MUST-132: In IPv4 [IPv4], the DF bit **MUST** be set to prevent fragmentation on the path. MUST-133: A client **MUST** expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see Section 12.2. MUST-134: A server **MUST** discard an Initial packet that is carried in a UDP datagram with a payload that is less than the smallest allowed maximum packet size of 1200 bytes. MUST-135: The server **MUST** also limit the number of bytes it sends before validating the address of the client; see Section 8. MUST-136: If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses has fallen below the smallest allowed maximum packet size of 1200 bytes, it **MUST** immediately cease sending QUIC packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path. MUST-137: An endpoint **MUST** ignore an ICMP message that claims the PMTU has decreased below the minimum QUIC packet size. MUST-138: ICMP message validation **MUST** include matching IP addresses and UDP ports [RFC8085] and, when possible, connection IDs to an active QUIC session. MUST-139: The sender **MUST** use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and packet number being sent. MUST-140: Packets containing a zero value for this bit are not valid packets in this version and **MUST** be discarded. MUST-141: Endpoints that receive a version 1 long header with a value larger than 20 **MUST** drop the packet. MUST-142: Endpoints that receive a version 1 long header with a value larger than 20 **MUST** drop the packet. MUST-143: The value included prior to protection **MUST** be set to 0. MUST-144: An endpoint **MUST** treat receipt of a packet that has a non-zero value for these bits, after removing both packet and header protection, as a connection error of type PROTOCOL_VIOLATION. MUST-145: Clients **MUST** ignore the value of this field. MUST-146: The Version field of a Version Negotiation packet **MUST** be set to 0x00000000. MUST-147: The server **MUST** include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID field. MUST-148: The value for Source Connection ID **MUST** be copied from the Destination Connection ID of the received packet, which is initially randomly selected by a client. MUST-149: Initial packets sent by the server **MUST** set the Token Length field to zero; clients that receive an Initial packet with a non-zero Token Length field MUST either discard the packet or generate a connection error of type PROTOCOL_VIOLATION. MUST-150: Initial packets sent by the server MUST set the Token Length field to zero; clients that receive an Initial packet with a non-zero Token Length field **MUST** either discard the packet or generate a connection error of type PROTOCOL_VIOLATION. MUST-151: packets, a client **MUST** assume that all packets up to the current packet number are in flight, starting from a packet number of 0. MUST-152: An acknowledgment for a 1-RTT packet **MUST** be carried in a 1-RTT packet. MUST-153: Endpoints **MUST** treat receipt of Handshake packets with other frames as a connection error. MUST-154: A client **MUST** discard a Retry packet that contains a Source Connection ID field that is identical to the Destination Connection ID field of its Initial packet. MUST-155: The client **MUST** use the value from the Source Connection ID field of the Retry packet in the Destination Connection ID field of subsequent packets that it sends. MUST-156: A client **MUST** accept and process at most one Retry packet for each connection attempt. MUST-157: After the client has received and processed an Initial or Retry packet from the server, it **MUST** discard any subsequent Retry packets that it receives. MUST-158: Clients **MUST** discard Retry packets that have a Retry Integrity Tag that cannot be validated, see the Retry Packet Integrity section of [QUIC-TLS]. MUST-159: A client **MUST** discard a Retry packet with a zero-length Retry Token field. MUST-160: A client **MUST** use the same cryptographic handshake message it includes in this packet. MUST-161: If the client received and processed a Retry packet, it **MUST** validate that the retry_source_connection_id transport parameter is present and correct; otherwise, it MUST validate that the transport parameter is absent. MUST-162: If the client received and processed a Retry packet, it MUST validate that the retry_source_connection_id transport parameter is present and correct; otherwise, it **MUST** validate that the transport parameter is absent. MUST-163: A client **MUST** treat a failed validation as a connection error of type PROTOCOL_VIOLATION. MUST-164: Packets containing a zero value for this bit are not valid packets in this version and **MUST** be discarded. MUST-165: The value included prior to protection **MUST** be set to 0. MUST-166: An endpoint **MUST** treat receipt of a packet that has a non-zero value for these bits, after removing both packet and header protection, as a connection error of type PROTOCOL_VIOLATION. MUST-167: A QUIC stack that chooses to support the spin bit **MUST** implement it as specified in this section. MUST-168: Implementations **MUST** allow administrators of clients and servers to disable the spin bit either globally or on a per-connection basis. MUST-169: Even when the spin bit is not disabled by the administrator, endpoints **MUST** disable their use of the spin bit for a random selection of at least one in every 16 network paths, or for one in every 16 connection IDs. MUST-170: When the spin bit is disabled, endpoints MAY set the spin bit to any value, and **MUST** ignore any incoming value. MUST-171: A client **MUST** treat violation of these requirements as a connection error of type TRANSPORT_PARAMETER_ERROR. MUST-172: The value of the active_connection_id_limit parameter **MUST** be at least 2. MUST-173: An endpoint that receives a value less than 2 **MUST** close the connection with an error of type TRANSPORT_PARAMETER_ERROR. MUST-174: A server **MUST** treat receipt of any of these transport parameters as a connection error of type TRANSPORT_PARAMETER_ERROR. MUST-175: QUIC implementations **MUST** properly handle both types and, if they have enabled ECN for packets they send, they SHOULD use the information in the ECN section to manage their congestion state. MUST-176: If any computed packet number is negative, an endpoint **MUST** generate a connection error of type FRAME_ENCODING_ERROR. MUST-177: An endpoint that receives a RESET_STREAM frame for a send-only stream **MUST** terminate the connection with error STREAM_STATE_ERROR. MUST-178: Receiving a STOP_SENDING frame for a locally-initiated stream that has not yet been created **MUST** be treated as a connection error of type STREAM_STATE_ERROR. MUST-179: An endpoint that receives a STOP_SENDING frame for a receive-only stream **MUST** terminate the connection with error STREAM_STATE_ERROR. MUST-180: Receipt of a frame that exceeds this limit **MUST** be treated as a connection error of type FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. MUST-181: An endpoint **MUST** treat receipt of a NEW_TOKEN frame with an empty Token field as a connection error of type FRAME_ENCODING_ERROR. MUST-182: Servers **MUST** treat receipt of a NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION. MUST-183: An endpoint **MUST** terminate the connection with error STREAM_STATE_ERROR if it receives a STREAM frame for a locally- initiated stream that has not yet been created, or for a send-only stream. MUST-184: Receipt of a frame that exceeds this limit **MUST** be treated as a connection error of type FRAME_ENCODING_ERROR or FLOW_CONTROL_ERROR. MUST-185: An endpoint **MUST** terminate a connection with a FLOW_CONTROL_ERROR error if it receives more data than the maximum data value that it has sent, unless this is a result of a change in the initial limits; see Section 7.4.1. MUST-186: Receiving a MAX_STREAM_DATA frame for a locally- initiated stream that has not yet been created **MUST** be treated as a connection error of type STREAM_STATE_ERROR. MUST-187: An endpoint that receives a MAX_STREAM_DATA frame for a receive-only stream **MUST** terminate the connection with error STREAM_STATE_ERROR. MUST-188: An endpoint **MUST** terminate a connection with a FLOW_CONTROL_ERROR error if it receives more data than the largest maximum stream data that it has sent for the affected stream, unless this is a result of a change in the initial limits; see Section 7.4.1. MUST-189: Receipt of a frame that permits opening of a stream larger than this limit **MUST** be treated as a FRAME_ENCODING_ERROR. MUST-190: MAX_STREAMS frames which do not increase the stream limit **MUST** be ignored. MUST-191: An endpoint **MUST** terminate a connection with a STREAM_LIMIT_ERROR error if a peer opens more streams than was permitted. MUST-192: An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only stream **MUST** terminate the connection with error STREAM_STATE_ERROR. MUST-193: Receipt of a frame that encodes a larger stream ID **MUST** be treated as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. MUST-194: Values less than 1 and greater than 20 are invalid and **MUST** be treated as a connection error of type FRAME_ENCODING_ERROR. MUST-195: An endpoint that is sending packets with a zero-length Destination Connection ID **MUST** treat receipt of a NEW_CONNECTION_ID frame as a connection error of type PROTOCOL_VIOLATION. MUST-196: The Retire Prior To field **MUST** be less than or equal to the Sequence Number field. MUST-197: Receiving a value greater than the Sequence Number **MUST** be treated as a connection error of type FRAME_ENCODING_ERROR. MUST-198: A receiver **MUST** ignore any Retire Prior To fields that do not increase the largest received Retire Prior To value. MUST-199: An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number smaller than the Retire Prior To field of a previously received NEW_CONNECTION_ID frame **MUST** send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID, unless it has already done so for that sequence number. MUST-200: Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number greater than any previously sent to the peer **MUST** be treated as a connection error of type PROTOCOL_VIOLATION. MUST-201: An endpoint that provides a zero- length connection ID **MUST** treat receipt of a RETIRE_CONNECTION_ID frame as a connection error of type PROTOCOL_VIOLATION. MUST-202: The recipient of this frame **MUST** generate a PATH_RESPONSE frame (Section 19.18) containing the same Data. MUST-203: A server **MUST** treat receipt of a HANDSHAKE_DONE frame as a connection error of type PROTOCOL_VIOLATION. MUST-204: An extension to QUIC that wishes to use a new type of frame **MUST** first ensure that a peer is able to understand the frame. MUST-205: Extension frames **MUST** be congestion controlled and MUST cause an ACK frame to be sent. MUST-206: Extension frames MUST be congestion controlled and **MUST** cause an ACK frame to be sent. MUST-207: To defend against this style of denial service, endpoints that share a static key for stateless reset (see Section 10.4.2) **MUST** be arranged so that packets with a given connection ID always arrive at an instance that has connection state, unless that connection is no longer active. MUST-208: Future versions of QUIC that use Version Negotiation packets **MUST** define a mechanism that is robust against version downgrade attacks. MUST-209: Use of the first codepoint in a range is intended for use by specifications that are developed through the standards process [STD] and its allocation **MUST** be negotiated with IANA before use. MUST-210: IANA **MUST** allocate the selected codepoint unless that codepoint is already assigned or the codepoint is the first unallocated codepoint in the registry. MUST-211: A request to remove a codepoint **MUST** be reviewed by the designated expert(s). MUST-212: The expert(s) **MUST** attempt to determine whether the codepoint is still in use. MUST-213: All registrations made by Standards Track publications **MUST** be permanent. MUST-214: In addition to the fields in Section 22.1.1, permanent registrations in this registry **MUST** include the following fields:. MUST-215: In addition to the fields in Section 22.1.1, permanent registrations in this registry **MUST** include the following fields:. MUST-216: In addition to the fields in Section 22.1.1, permanent registrations in this registry **MUST** include the following fields:. SHALL Requirements: Sha-1: 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. Sha-2: IANA [**SHALL** add/has added] a registry for "QUIC Transport Parameters" under a "QUIC" heading. Sha-3: IANA [**SHALL** add/has added] a registry for "QUIC Frame Types" under a "QUIC" heading. Sha-4: IANA [**SHALL** add/has added] a registry for "QUIC Transport Error Codes" under a "QUIC" heading. REQUIRED Requirements: Req-1: 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. SHOULD Requirements: S-1: 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. S-2: A QUIC implementation **SHOULD** provide ways in which an application can indicate the relative priority of streams. S-3: When deciding the streams to which resources are dedicated, the implementation **SHOULD** use the information provided by the application. S-4: If the stream is in the "Recv" or "Size Known" states, the transport **SHOULD** signal this by sending a STOP_SENDING frame to prompt closure of the stream in the opposite direction. S-5: If the stream is in the Data Sent state and any outstanding data is declared lost, an endpoint **SHOULD** send a RESET_STREAM frame in lieu of a retransmission. S-6: An endpoint **SHOULD** copy the error code from the STOP_SENDING frame to the RESET_STREAM frame it sends, but MAY use any application error code. S-7: STOP_SENDING **SHOULD** only be sent for a stream that has not been reset by the peer. S-8: The implementation **SHOULD** provide an interface to QUIC to tell it about its buffering limits so that there is not excessive buffering at multiple layers. S-9: A sender **SHOULD** send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to write but is blocked by flow control limits. S-10: To keep the connection from closing, a sender that is flow control limited **SHOULD** periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it has no ack-eliciting packets in flight. S-11: If a RESET_STREAM or STREAM frame is received indicating a change in the final size for the stream, an endpoint **SHOULD** respond with a FINAL_SIZE_ERROR error; see Section 11. S-12: A receiver **SHOULD** treat receipt of data at or beyond the final size as a FINAL_SIZE_ERROR error, even after a stream is closed. S-13: An endpoint that is unable to open a new stream due to the peer's limits **SHOULD** send a STREAMS_BLOCKED frame (Section 19.14). S-14: An endpoint **SHOULD** ensure that its peer has a sufficient number of available and unused connection IDs. S-15: An endpoint **SHOULD** supply a new connection ID when the peer retires a connection ID. S-16: An endpoint that initiates migration and requires non-zero-length connection IDs **SHOULD** ensure that the pool of connection IDs available to its peer allows the peer to use a new connection ID on migration, as the peer will close the connection if the pool is exhausted. S-17: Endpoints **SHOULD** retire connection IDs when they are no longer actively using either the local or destination address for which the connection ID was used. S-18: The endpoint **SHOULD** continue to accept the previously issued connection IDs until they are retired by the peer. S-19: An endpoint **SHOULD** limit the number of connection IDs it has retired locally and have not yet been acknowledged. S-20: An endpoint **SHOULD** allow for sending and tracking a number of RETIRE_CONNECTION_ID frames of at least twice the active_connection_id limit. S-21: If a server receives a packet that indicates an unsupported version but is large enough to initiate a new connection for any one supported version, the server **SHOULD** send a Version Negotiation packet as described in Section 6.1. S-22: If a server refuses to accept a new connection, it **SHOULD** send an Initial packet containing a CONNECTION_CLOSE frame with error code CONNECTION_REFUSED. S-23: Clients are not able to send Handshake packets prior to receiving a server response, so servers **SHOULD** ignore any such packets. S-24: A server in a deployment that does not implement a solution to maintain connection continuity when the client address changes **SHOULD** indicate migration is not supported using the. S-25: Clients that support multiple QUIC versions **SHOULD** pad the first packet they send to the largest of the minimum packet sizes across all versions they support. S-26: An endpoint **SHOULD** treat receipt of duplicate transport parameters as a connection error of type TRANSPORT_PARAMETER_ERROR. S-27: The applicable subset of transport parameters that permit sending of application data **SHOULD** be set to non-zero values for 0-RTT. S-28: Instead, the server **SHOULD** immediately close (Section 10.3) the connection with an INVALID_TOKEN error. S-29: Thus, a token **SHOULD** have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time. S-30: When connecting to a server for which the client retains an applicable and unused token, it **SHOULD** include that token in the Token field of its Initial packet. S-31: If the token is invalid then the server **SHOULD** proceed as if the client did not have a validated address, including potentially sending a Retry. S-32: A server **SHOULD** encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly. S-33: If the validation succeeds, the server **SHOULD** then allow the handshake to proceed. S-34: To protect against such attacks, servers **SHOULD** ensure that tokens sent in Retry packets are only accepted for a short time. S-35: Tokens sent in Retry packets **SHOULD** include information that allows the server to verify that the source IP address and port in client packets remain constant. S-36: Endpoints **SHOULD** abandon path validation based on a timer. S-37: After verifying a new client address, the server **SHOULD** send new address validation tokens (Section 8) to the client. S-38: Note that since the endpoint will not have any round-trip time measurements to this address, the estimate **SHOULD** be the default initial value; see [QUIC-RECOVERY]. S-39: An endpoint that receives a PATH_CHALLENGE on an active path **SHOULD** send a non-probing packet in response. S-40: This timer **SHOULD** be set as described in Section 6.2.1 of [QUIC-RECOVERY] and MUST NOT be more aggressive. S-41: Changing port number can cause a peer to reset its congestion state (see Section 9.4), so the port **SHOULD** only be changed infrequently. S-42: To ensure that migration is possible and packets sent on different paths cannot be correlated, endpoints **SHOULD** provide new connection IDs before peers migrate; see Section 5.1.1. S-43: If a client receives packets from a new server address not indicated by the preferred_address transport parameter, the client **SHOULD** discard these packets. S-44: Once the handshake is confirmed, the client **SHOULD** select one of the two server's preferred addresses and initiate path validation (see Section 8.2) of that address using any previously unused active connection ID, taken from either the preferred_address transport parameter or a NEW_CONNECTION_ID frame. S-45: If path validation succeeds, the client **SHOULD** immediately begin sending all future packets to the new server address using the new connection ID and discontinue use of the old server address. S-46: It **SHOULD** drop packets for this connection received on the old IP address, but MAY continue to process delayed packets. S-47: In this case, the client **SHOULD** perform path validation to both the original and preferred server address from the client's new address concurrently. S-48: Servers **SHOULD** initiate path validation to the client's new address upon receiving a probe packet from a different address. S-49: A client that migrates to a new address **SHOULD** use a preferred address from the same address family for the server. S-50: Endpoints that send data using IPv6 **SHOULD** apply an IPv6 flow label in compliance with [RFC6437], unless the local API does not allow setting IPv6 flow labels. S-51: The IPv6 flow label **SHOULD** be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the destination CID. S-52: These states **SHOULD** persist for at least three times the current Probe Timeout (PTO) interval as defined in [QUIC-RECOVERY]. S-53: The draining period **SHOULD** end when the closing period would have ended. S-54: Once the closing or draining period has ended, an endpoint **SHOULD** discard all connection state. S-55: Application protocols that use QUIC **SHOULD** provide guidance on when deferring an idle timeout is appropriate. S-56: During the closing period, an endpoint that sends a CONNECTION_CLOSE frame **SHOULD** respond to any incoming packet that can be decrypted with another packet containing a CONNECTION_CLOSE frame. S-57: Such an endpoint **SHOULD** limit the number of packets it generates containing a CONNECTION_CLOSE frame. S-58: Under these circumstances, a server **SHOULD** send a CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at least one of them is processable by the client. S-59: * Prior to confirming the handshake, a peer might be unable to process 1-RTT packets, so an endpoint **SHOULD** send CONNECTION_CLOSE in both Handshake and 1-RTT packets. S-60: A server **SHOULD** also send CONNECTION_CLOSE in an Initial packet. S-61: Endpoints MUST clear the value of the Reason Phrase field and **SHOULD** use the APPLICATION_ERROR code when converting to a CONNECTION_CLOSE of type 0x1c. S-62: To prevent a resulting stateless reset from being trivially distinguishable from a valid packet, all packets sent by an endpoint **SHOULD** be padded to at least 22 bytes longer than the minimum connection ID that the endpoint might use. S-63: An endpoint that sends a stateless reset in response to a packet that is 43 bytes or less in length **SHOULD** send a stateless reset that is one byte shorter than the packet it responds to. S-64: An endpoint that detects an error **SHOULD** signal the existence of that error to its peer. S-65: The most appropriate error code (Section 20) **SHOULD** be included in the frame that signals the error. S-66: An endpoint **SHOULD** be prepared to retransmit a packet containing a CONNECTION_CLOSE frame if it receives more packets on a terminated connection. S-67: Application protocols **SHOULD** define rules for handling streams that are prematurely cancelled by either endpoint. S-68: Receivers **SHOULD** ignore any subsequent packets with a different Destination Connection ID than the first packet in the datagram. S-69: An endpoint **SHOULD** treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition. S-70: When sending a packet for any reason, an endpoint **SHOULD** attempt to bundle an ACK frame if one has not been sent recently. S-71: Every packet **SHOULD** be acknowledged at least once, and ack-eliciting packets MUST be acknowledged at least once within the maximum ack delay. S-72: In order to assist loss detection at the sender, an endpoint **SHOULD** send an ACK frame immediately on receiving an ack-eliciting packet that is out of order. S-73: If every subsequent ack-eliciting packet arrives out of order, then an ACK frame **SHOULD** be sent immediately for every received ack-eliciting packet. S-74: Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header **SHOULD** be acknowledged immediately, to reduce the peer's response time to congestion events. S-75: An endpoint **SHOULD** bundle ACK frames with other frames when there are new ack-eliciting packets to acknowledge. S-76: A receiver **SHOULD** send an ACK frame after receiving at least two ack- eliciting packets. S-77: ACK frames **SHOULD** always acknowledge the most recently received packets, and the more out-of-order the packets are, the more important it is to send an updated ACK frame quickly, to prevent the peer from declaring a packet as lost and spuriously retransmitting the frames it contains. S-78: After receiving acknowledgments for an ACK frame, the receiver **SHOULD** stop tracking those acknowledged ACK Ranges. S-79: A receiver **SHOULD** include an ACK Range containing the largest received packet number in every ACK frame. S-80: To avoid a deadlock, a sender **SHOULD** ensure that other frames are sent periodically in addition to PADDING frames to elicit acknowledgments from the receiver. S-81: An endpoint **SHOULD** stop sending MAX_STREAM_DATA frames when the receiving part of the stream enters a "Size Known" state. S-82: Endpoints **SHOULD** prioritize retransmission of data over sending new data, unless priorities specified by the application indicate otherwise; see Section 2.3. S-83: To start ECN validation, an endpoint **SHOULD** do the following when sending packets on a new path to a peer:. S-84: An endpoint **SHOULD** use DPLPMTUD (Section 14.3) or PMTUD (Section 14.2.1) to determine whether the path to a destination will support a desired maximum packet size without fragmentation. S-85: All QUIC packets that are not sent in a PMTU probe **SHOULD** be sized to fit within the maximum packet size to avoid the packet being fragmented or dropped [RFC8085]. S-86: QUIC implementations that implement any kind of PMTU discovery therefore **SHOULD** maintain a maximum packet size for each combination of local and remote IP addresses. S-87: QUIC endpoints using PMTUD **SHOULD** validate ICMP messages to protect from off-path injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. S-88: This validation **SHOULD** use the quoted packet supplied in the payload of an ICMP message to associate the message with a corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). S-89: The endpoint **SHOULD** ignore all ICMP messages that fail validation. S-90: Endpoints **SHOULD** set the initial value of BASE_PMTU (see Section 5.1 of [DPLPMTUD]) to be consistent with the minimum QUIC packet size. S-91: An endpoint **SHOULD** use a large enough packet number encoding to allow the packet number to be recovered even if the packet arrives after packets that are sent afterwards. S-92: Servers **SHOULD** be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet. S-93: Servers **SHOULD** be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet. S-94: Servers **SHOULD** set the most significant bit of this field (0x40) to 1 so that Version Negotiation packets appear to have the Fixed Bit field. S-95: A client **SHOULD** attempt to resend data in 0-RTT packets after it sends a new Initial packet. S-96: A server **SHOULD** treat a violation of remembered limits as a connection error of an appropriate type (for instance, a FLOW_CONTROL_ERROR for exceeding stream data limits). S-97: This value **SHOULD** include the receiver's expected delays in alarms firing. S-98: QUIC implementations MUST properly handle both types and, if they have enabled ECN for packets they send, they **SHOULD** use the information in the ECN section to manage their congestion state. S-99: Because the receiver doesn't use the ACK Delay for Initial and Handshake packets, a sender **SHOULD** send a value of 0. S-100: A sender **SHOULD** send a DATA_BLOCKED frame (type=0x14) when it wishes to send data, but is unable to due to connection-level flow control; see Section 4. S-101: A sender **SHOULD** send a STREAM_DATA_BLOCKED frame (type=0x15) when it wishes to send data, but is unable to due to stream-level flow control. S-102: A sender **SHOULD** send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when it wishes to open a stream, but is unable to due to the maximum stream limit set by its peer; see Section 19.11. S-103: This **SHOULD** be a UTF-8 encoded string [RFC3629]. S-104: Such extensions **SHOULD** define their interaction with previously-defined extensions modifying the same protocol components. S-105: Servers **SHOULD** provide mitigations for this attack by limiting the usage and lifetime of address validation tokens; see Section 8.1.3. S-106: QUIC deployments **SHOULD** provide mitigations for the Slowloris attacks, such as increasing the maximum number of clients the server will allow, limiting the number of connections a single IP address is allowed to make, imposing restrictions on the minimum transfer speed a connection is allowed to have, and restricting the length of time an endpoint is allowed to stay connected. S-107: QUIC deployments **SHOULD** provide mitigations against stream fragmentation attacks. S-108: While there are legitimate uses for all messages, implementations **SHOULD** track cost of processing relative to progress and treat excessive quantities of any non-productive packets as indicative of an attack. S-109: New uses of codepoints from QUIC registries **SHOULD** use a randomly selected codepoint that excludes both existing allocations and the first unallocated codepoint in the selected space. S-110: For codepoints that are encoded in variable-length integers (Section 16), such as frame types, codepoints that encode to four or eight bytes (that is, values 2^14 and above) **SHOULD** be used unless the usage is especially sensitive to having a longer encoding. S-111: This **SHOULD** be done only for the codepoints with the earliest recorded date and entries that have been updated less than a year prior SHOULD NOT be reclaimed. S-112: In addition to the advice in Section 22.1, specifications for new permanent registrations **SHOULD** describe the means by which an endpoint might determine that it can send the identified type of frame. RECOMMENDED Requirements: Rec-1: 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. Rec-2: A value of three times the larger of the current Probe Timeout (PTO) or the initial timeout (that is, 2*kInitialRtt) as defined in [QUIC-RECOVERY] is **RECOMMENDED**. Rec-3: It is **RECOMMENDED** that endpoints set the spin bit to a random value either chosen independently for each packet or chosen independently for each connection ID. MAY Requirements: MAY-1: 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. MAY-2: However, implementations **MAY** choose to offer the ability to deliver data out of order to a receiving application. MAY-3: The data at a given offset MUST NOT change if it is sent multiple times; an endpoint **MAY** treat receipt of different data at the same offset within a stream as a connection error of type PROTOCOL_VIOLATION. MAY-4: An endpoint **MAY** send a RESET_STREAM as the first frame that mentions a stream; this causes the sending part of that stream to open and then immediately transition to the "Reset Sent" state. MAY-5: An implementation **MAY** interrupt delivery of stream data, discard any data that was not consumed, and signal the receipt of the RESET_STREAM. MAY-6: A receiver **MAY** send STOP_SENDING in any state where it has not received a RESET_STREAM frame; that is states other than "Reset Recvd" or "Reset Read". MAY-7: An endpoint SHOULD copy the error code from the STOP_SENDING frame to the RESET_STREAM frame it sends, but **MAY** use any application error code. MAY-8: The endpoint that sends a STOP_SENDING frame **MAY** ignore the error code carried in any RESET_STREAM frame it receives. MAY-9: A receiver **MAY** send MAX_STREAM_DATA frames in multiple packets in order to make sure that the sender receives an update before running out of flow control credit, even if one of the packets is lost. MAY-10: Once a receiver advertises an offset, it **MAY** advertise a smaller offset, but this has no effect. MAY-11: An endpoint **MAY** send connection IDs that temporarily exceed a peer's limit if the NEW_CONNECTION_ID frame also requires the retirement of any excess, by including a sufficiently large value in the Retire Prior To field. MAY-12: If an endpoint provided fewer connection IDs than the peer's active_connection_id_limit, it **MAY** supply a new connection ID when it receives a packet with a previously unused connection ID. MAY-13: An endpoint **MAY** limit the frequency or the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs; see Section 10.4.2. MAY-14: An endpoint **MAY** also limit the issuance of connection IDs to reduce the amount of per-path state it maintains, such as path validation status, as its peer might interact with it over as many paths as there are issued connection IDs. MAY-15: If the endpoint can no longer process the indicated connection IDs, it **MAY** close the connection. MAY-16: An endpoint MUST NOT forget a connection ID without retiring it, though it **MAY** choose to treat having connection IDs in need of retirement that exceed this limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. MAY-17: Invalid packets without packet protection, such as Initial, Retry, or Version Negotiation, **MAY** be discarded. MAY-18: The client **MAY** drop these packets, or MAY buffer them in anticipation of later packets that allow it to compute the key. MAY-19: The client MAY drop these packets, or **MAY** buffer them in anticipation of later packets that allow it to compute the key. MAY-20: Servers **MAY** limit the number of packets that it responds to with a Version Negotiation packet. MAY-21: If the packet is a 0-RTT packet, the server **MAY** buffer a limited number of these packets in anticipation of a late-arriving Initial packet. MAY-22: A server **MAY** limit the number of Version Negotiation packets it sends. MAY-23: When a draft implementation receives a Version Negotiation packet, it **MAY** use it to attempt a new connection with one of the versions listed in the packet, instead of abandoning the current connection attempt; see Section 6.2. MAY-24: Endpoints **MAY** add reserved versions to any field where unknown or unsupported versions are ignored to test that a peer correctly ignores the value. MAY-25: Endpoints **MAY** send packets with a reserved version to test that a peer correctly discards the packet. MAY-26: The definition of new transport parameters (Section 7.4.2) MUST specify whether they MUST, **MAY**, or MUST NOT be stored for 0-RTT. MAY-27: A server **MAY** treat use of updated transport parameters in 0-RTT as a connection error of type PROTOCOL_VIOLATION. MAY-28: Endpoints **MAY** choose to allow more data to be buffered during the handshake. MAY-29: Once the handshake completes, if an endpoint is unable to buffer all data in a CRYPTO frame, it **MAY** discard that CRYPTO frame and all CRYPTO frames received in the future, or it MAY close the connection with a CRYPTO_BUFFER_EXCEEDED error code. MAY-30: Once the handshake completes, if an endpoint is unable to buffer all data in a CRYPTO frame, it MAY discard that CRYPTO frame and all CRYPTO frames received in the future, or it **MAY** close the connection with a CRYPTO_BUFFER_EXCEEDED error code. MAY-31: A server **MAY** provide clients with an address validation token during one connection that can be used on a subsequent connection. MAY-32: Servers **MAY** discard any Initial packet that does not carry the expected token. MAY-33: Information that allows the server to distinguish between tokens from Retry and NEW_TOKEN **MAY** be accessible to entities other than the server. MAY-34: A client **MAY** use a token from any previous connection to that server. MAY-35: Clients that want to break continuity of identity with a server **MAY** discard tokens provided using the NEW_TOKEN frame. MAY-36: Clients **MAY** use tokens obtained on one connection for any connection attempt using the same version. MAY-37: Tokens **MAY** include additional information about clients to further narrow applicability or reuse. MAY-38: An endpoint **MAY** bundle PATH_CHALLENGE and PATH_RESPONSE frames that are used for path validation with other frames. MAY-39: An endpoint **MAY** send multiple PATH_CHALLENGE frames to guard against packet loss. MAY-40: When an endpoint has no validated path on which to send packets, it **MAY** discard connection state. MAY-41: An endpoint capable of connection migration **MAY** wait for a new path to become available before discarding connection state. MAY-42: An endpoint **MAY** probe for peer reachability from a new local address using path validation Section 8.2 prior to migrating the connection to the new local address. MAY-43: To establish return reachability on the new path, an endpoint **MAY** concurrently initiate path validation Section 8.2 on the new path or it MAY choose to wait for the peer to send the next non-probing frame to its new address. MAY-44: To establish return reachability on the new path, an endpoint MAY concurrently initiate path validation Section 8.2 on the new path or it **MAY** choose to wait for the peer to send the next non-probing frame to its new address. MAY-45: An endpoint **MAY** send data to an unvalidated peer address, but it MUST protect against potential attacks as described in Section 9.3.1 and Section 9.3.2. MAY-46: An endpoint **MAY** skip validation of a peer address if that address has been seen recently. MAY-47: For instance, an endpoint **MAY** send a stateless reset in response to any further incoming packets. MAY-48: At any time, endpoints **MAY** change the Destination Connection ID they send to a value that has not been used on another path. MAY-49: Due to network changes outside the control of its peer, an endpoint might receive packets from a new source address with the same destination connection ID, in which case it **MAY** continue to use the current connection ID with the new remote address while still sending from the same local address. MAY-50: Servers **MAY** communicate a preferred address of each address family (IPv4 and IPv6) to allow clients to pick the one most suited to their network attachment. MAY-51: It SHOULD drop packets for this connection received on the old IP address, but **MAY** continue to process delayed packets. MAY-52: If path validation of the server's preferred address fails but validation of the server's original address succeeds, the client **MAY** migrate to its new address and continue sending to the server's original address. MAY-53: This connection ID is provided to ensure that the client has a connection ID available for migration, but the client **MAY** use this connection ID on any path. MAY-54: An endpoint **MAY** discard connection state if it does not have a validated path on which it can send packets; see Section 8.2. MAY-55: An endpoint **MAY** retain packet protection keys for incoming packets to allow it to read and process a CONNECTION_CLOSE frame. MAY-56: An endpoint **MAY** transition from the closing period to the draining period if it receives a CONNECTION_CLOSE frame or stateless reset, both of which indicate that the peer is also closing or draining. MAY-57: Endpoints that have some alternative means to ensure that late-arriving packets on the connection do not induce a response, such as those that are able to close the UDP socket, **MAY** use an abbreviated draining period which can allow for faster resource recovery. MAY-58: For instance, an endpoint **MAY** send a stateless reset in response to any further incoming packets. MAY-59: A server in the closing state **MAY** instead choose to discard packets received from a new source address. MAY-60: To minimize the state that an endpoint maintains for a closing connection, endpoints **MAY** send the exact same packet. MAY-61: An endpoint that receives a CONNECTION_CLOSE frame **MAY** send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. MAY-62: However, prior to confirming the handshake, it is possible that more advanced packet protection keys are not available to the peer, so another CONNECTION_CLOSE frame **MAY** be sent in a packet that uses a lower packet protection level. MAY-63: For this reason, endpoints **MAY** discard packets rather than immediately close if errors are detected in packets that lack authentication. MAY-64: An endpoint **MAY** send a stateless reset in response to receiving a packet that it cannot associate with an active connection. MAY-65: An endpoint **MAY** send a stateless reset in response to a packet with a long header. MAY-66: Endpoints **MAY** skip this check if any packet from a datagram is successfully processed. MAY-67: Endpoints are not required to compare new values against all previous values, but a duplicate value **MAY** be treated as a connection error of type PROTOCOL_VIOLATION. MAY-68: In particular, an endpoint **MAY** use any applicable error code when it detects an error condition; a generic error code (such as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place of specific error codes. MAY-69: An endpoint **MAY** close the connection in this manner even if the error only affects a single stream. MAY-70: For example, if decryption fails (because the keys are not available or any other reason), the receiver **MAY** either discard or buffer the packet for later processing and MUST attempt to process the remaining packets. MAY-71: If the packet number for sending reaches 2^62 - 1, the sender MUST close the connection without sending a CONNECTION_CLOSE frame or any further packets; an endpoint **MAY** send a Stateless Reset (Section 10.4) in response to further packets that it receives. MAY-72: The payload of a packet that contains frames MUST contain at least one frame, and **MAY** contain multiple frames and multiple frame types. MAY-73: An endpoint **MAY** treat the receipt of a frame type that uses a longer encoding than necessary as a connection error of type PROTOCOL_VIOLATION. MAY-74: A sender **MAY** wait for a short period of time to collect multiple frames before sending a packet that is not maximally packed, to avoid sending out. MAY-75: An implementation **MAY** use knowledge about application sending behavior or heuristics to determine whether and for how long to wait. MAY-76: When only non-ack-eliciting packets need to be acknowledged, an endpoint **MAY** wait until an ack-eliciting packet has been received to bundle an ACK frame with outgoing frames. MAY-77: A receiver **MAY** process multiple available packets before determining whether to send an ACK frame in response. MAY-78: This is necessary if an ACK frame would be too large to fit in a packet, however receivers **MAY** also limit ACK frame size further to preserve space for other frames. MAY-79: Implementations **MAY** use other methods defined in RFCs; see [RFC8311]. MAY-80: Even if validation fails, an endpoint **MAY** revalidate ECN on the same path at any later time in the connection. MAY-81: Datagrams containing Initial packets **MAY** exceed 1200 bytes if the client believes that the network path and peer both support the size that it chooses. MAY-82: A server **MAY** also immediately close the connection by sending a CONNECTION_CLOSE frame with an error code of PROTOCOL_VIOLATION; see Section 10.3.1. MAY-83: An endpoint **MAY** terminate the connection if an alternative path cannot be found. MAY-84: A QUIC implementation **MAY** be more conservative in computing the maximum packet size to allow for unknown tunnel overheads or IP header options/extensions. MAY-85: Any reduction in the QUIC maximum packet size in response to ICMP messages **MAY** be provisional until QUIC's loss detection algorithm determines that the quoted packet has actually been lost. MAY-86: A client or server **MAY** advertise support for any of these reserved versions. MAY-87: Reserved version numbers will never represent a real protocol; a client **MAY** use one of these version numbers with the expectation that the server will initiate version negotiation; a server MAY advertise support for one of these versions and can expect that clients ignore the value. MAY-88: Reserved version numbers will never represent a real protocol; a client MAY use one of these version numbers with the expectation that the server will initiate version negotiation; a server **MAY** advertise support for one of these versions and can expect that clients ignore the value. MAY-89: Handshake packets **MAY** contain CONNECTION_CLOSE frames of type 0x1c. MAY-90: A server **MAY** send Retry packets in response to Initial and 0-RTT packets. MAY-91: A server **MAY** treat a packet that contains a different cryptographic handshake message as a connection error or discard it. MAY-92: A client **MAY** attempt 0-RTT after receiving a Retry packet by sending 0-RTT packets to the connection ID provided by the server. MAY-93: When the spin bit is disabled, endpoints **MAY** set the spin bit to any value, and MUST ignore any incoming value. MAY-94: This transport parameter MUST NOT be sent by a client, but **MAY** be sent by a server. MAY-95: Servers **MAY** choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family. MAY-96: If an endpoint receives a NEW_CONNECTION_ID frame that repeats a previously issued connection ID with a different Stateless Reset Token or a different sequence number, or if a sequence number is used for different connection IDs, the endpoint **MAY** treat that receipt as a connection error of type PROTOCOL_VIOLATION. MAY-97: The peer **MAY** treat this as a connection error of type FRAME_ENCODING_ERROR. MAY-98: If the content of a PATH_RESPONSE frame does not match the content of a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint **MAY** generate a connection error of type PROTOCOL_VIOLATION. MAY-99: An endpoint **MAY** skip packet numbers when sending packets to detect this behavior. MAY-100: Endpoints **MAY** respond to this condition with a connection error, or by dropping packets. MAY-101: Provisional registrations **MAY** omit the Specification and Notes fields, plus any additional fields that might be required for a permanent registration. MAY-102: Requests for multiple codepoints **MAY** use a contiguous range. MAY-103: Applications to register codepoints in QUIC registries **MAY** include a codepoint as part of the registration. MAY-104: If no use of the codepoint was identified and no request was made to update the registration, the codepoint **MAY** be removed from the registry. MAY-105: The creation of a registry **MAY** specify additional constraints on permanent registrations. MAY-106: The creation of a registries **MAY** identify a range of codepoints where registrations are governed by a different registration policy. MAY-107: Description: A brief description of the error code semantics, which **MAY** be a summary if a specification reference is provided. OPTIONAL Requirements: O-1: 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. O-2: The spin bit is an **OPTIONAL** feature of QUIC.