draft-ietf-quic-transport-34.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: July 19, 2021 Mozilla Expires: October 24, 2021 Mozilla
January 15, 2021 April 22, 2021
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-34 draft-ietf-quic-transport-latest
Abstract Abstract
This document defines the core of the QUIC transport protocol. QUIC This document defines the core of the QUIC transport protocol. QUIC
provides applications with flow-controlled streams for structured provides applications with flow-controlled streams for structured
communication, low-latency connection establishment, and network path communication, low-latency connection establishment, and network path
migration. QUIC includes security measures that ensure migration. QUIC includes security measures that ensure
confidentiality, integrity, and availability in a range of deployment confidentiality, integrity, and availability in a range of deployment
circumstances. Accompanying documents describe the integration of circumstances. Accompanying documents describe the integration of
TLS for key negotiation, loss detection, and an exemplary congestion TLS for key negotiation, loss detection, and an exemplary congestion
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 19, 2021. This Internet-Draft will expire on October 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 11, line 32 skipping to change at page 11, line 32
fixed value, optionality, or repetitions. Individual fields use the fixed value, optionality, or repetitions. Individual fields use the
following notational conventions, with all lengths in bits: following notational conventions, with all lengths in bits:
x (A): Indicates that x is A bits long x (A): Indicates that x is A bits long
x (i): Indicates that x holds an integer value using the variable- x (i): Indicates that x holds an integer value using the variable-
length encoding in Section 16 length encoding in Section 16
x (A..B): Indicates that x can be any length from A to B; A can be 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 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 indicate no set upper limit; values in this format always end on a
an byte boundary byte boundary
x (L) = C: Indicates that x has a fixed value of C with the length x (L) = C: Indicates that x has a fixed value of C with the length
described by L, which can use any of the three length forms above described by L, which can use any of the three length forms above
x (L) = C..D: Indicates that x has a value in the range from C to D, 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 inclusive, with the length described by L, as above
[x (L)]: Indicates that x is optional (and has length of L) [x (L)]: Indicates that x is optional (and has length of L)
x (L) ...: Indicates that zero or more instances of x are present x (L) ...: Indicates that zero or more instances of x are present
skipping to change at page 13, line 13 skipping to change at page 13, line 13
streams carry data in one direction: from the initiator of the stream 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 to its peer. Bidirectional streams allow for data to be sent in both
directions. directions.
Streams are identified within a connection by a numeric value, 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 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 2^62-1) that is unique for all streams on a connection. Stream IDs
are encoded as variable-length integers; see Section 16. A QUIC are encoded as variable-length integers; see Section 16. A QUIC
endpoint MUST NOT reuse a stream ID within a connection. endpoint MUST NOT reuse a stream ID within a connection.
The least significant bit (0x1) of the stream ID identifies the The least significant bit (0x01) of the stream ID identifies the
initiator of the stream. Client-initiated streams have even-numbered initiator of the stream. Client-initiated streams have even-numbered
stream IDs (with the bit set to 0), and server-initiated streams have stream IDs (with the bit set to 0), and server-initiated streams have
odd-numbered stream IDs (with the bit set to 1). odd-numbered stream IDs (with the bit set to 1).
The second least significant bit (0x2) of the stream ID distinguishes The second least significant bit (0x02) of the stream ID
between bidirectional streams (with the bit set to 0) and distinguishes between bidirectional streams (with the bit set to 0)
unidirectional streams (with the bit set to 1). and unidirectional streams (with the bit set to 1).
The two least significant bits from a stream ID therefore identify a The two least significant bits from a stream ID therefore identify a
stream as one of four types, as summarized in Table 1. stream as one of four types, as summarized in Table 1.
+------+----------------------------------+ +------+----------------------------------+
| Bits | Stream Type | | Bits | Stream Type |
+------+----------------------------------+ +------+----------------------------------+
| 0x0 | Client-Initiated, Bidirectional | | 0x00 | Client-Initiated, Bidirectional |
| | | | | |
| 0x1 | Server-Initiated, Bidirectional | | 0x01 | Server-Initiated, Bidirectional |
| | | | | |
| 0x2 | Client-Initiated, Unidirectional | | 0x02 | Client-Initiated, Unidirectional |
| | | | | |
| 0x3 | Server-Initiated, Unidirectional | | 0x03 | Server-Initiated, Unidirectional |
+------+----------------------------------+ +------+----------------------------------+
Table 1: Stream ID Types Table 1: Stream ID Types
The stream space for each type begins at the minimum value (0x0 The stream space for each type begins at the minimum value (0x00
through 0x3 respectively); successive streams of each type are through 0x03 respectively); successive streams of each type are
created with numerically increasing stream IDs. A stream ID that is created with numerically increasing stream IDs. A stream ID that is
used out of order results in all streams of that type with lower- used out of order results in all streams of that type with lower-
numbered stream IDs also being opened. numbered stream IDs also being opened.
2.2. Sending and Receiving Data 2.2. Sending and Receiving Data
STREAM frames (Section 19.8) encapsulate data sent by an application. STREAM frames (Section 19.8) encapsulate data sent by an application.
An endpoint uses the Stream ID and Offset fields in STREAM frames to An endpoint uses the Stream ID and Offset fields in STREAM frames to
place data in order. place data in order.
skipping to change at page 26, line 18 skipping to change at page 26, line 18
A blocked sender is not required to send STREAM_DATA_BLOCKED or A blocked sender is not required to send STREAM_DATA_BLOCKED or
DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a
STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a
MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the
sender being blocked for the rest of the connection. Even if the sender being blocked for the rest of the connection. Even if the
sender sends these frames, waiting for them will result in the sender sender sends these frames, waiting for them will result in the sender
being blocked for at least an entire round trip. being blocked for at least an entire round trip.
When a sender receives credit after being blocked, it might be able 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 to send a large amount of data in response, resulting in short-term
congestion; see Section 7.7 in [QUIC-RECOVERY] for a discussion of congestion; see Section 7.7 of [QUIC-RECOVERY] for a discussion of
how a sender can avoid this congestion. how a sender can avoid this congestion.
4.3. Flow Control Performance 4.3. Flow Control Performance
If an endpoint cannot ensure that its peer always has available flow If an endpoint cannot ensure that its peer always has available flow
control credit that is greater than the peer's bandwidth-delay control credit that is greater than the peer's bandwidth-delay
product on this connection, its receive throughput will be limited by product on this connection, its receive throughput will be limited by
flow control. flow control.
Packet loss can cause gaps in the receive buffer, preventing the Packet loss can cause gaps in the receive buffer, preventing the
skipping to change at page 28, line 16 skipping to change at page 28, line 16
if the offending value was received in a transport parameter or of if the offending value was received in a transport parameter or of
type FRAME_ENCODING_ERROR if it was received in a frame; see type FRAME_ENCODING_ERROR if it was received in a frame; see
Section 10.2. Section 10.2.
Endpoints MUST NOT exceed the limit set by their peer. An endpoint Endpoints MUST NOT exceed the limit set by their peer. An endpoint
that receives a frame with a stream ID exceeding the limit it has 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 sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR
(Section 11). (Section 11).
Once a receiver advertises a stream limit using the MAX_STREAMS Once a receiver advertises a stream limit using the MAX_STREAMS
frame, advertising a smaller limit has no effect. A receiver MUST frame, advertising a smaller limit has no effect. MAX_STREAMS frames
ignore any MAX_STREAMS frame that does not increase the stream limit. that do not increase the stream limit MUST be ignored.
As with stream and connection flow control, this document leaves As with stream and connection flow control, this document leaves
implementations to decide when and how many streams should be implementations to decide when and how many streams should be
advertised to a peer via MAX_STREAMS. Implementations might choose advertised to a peer via MAX_STREAMS. Implementations might choose
to increase limits as streams are closed, to keep the number of to increase limits as streams are closed, to keep the number of
streams available to peers roughly consistent. streams available to peers roughly consistent.
An endpoint that is unable to open a new stream due to the peer's 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). This limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This
signal is considered useful for debugging. An endpoint MUST NOT wait signal is considered useful for debugging. An endpoint MUST NOT wait
skipping to change at page 40, line 28 skipping to change at page 40, line 28
handshake is carried in Initial (Section 17.2.2) and Handshake handshake is carried in Initial (Section 17.2.2) and Handshake
(Section 17.2.4) packets. (Section 17.2.4) packets.
Figure 5 provides an overview of the 1-RTT handshake. Each line Figure 5 provides an overview of the 1-RTT handshake. Each line
shows a QUIC packet with the packet type and packet number shown shows a QUIC packet with the packet type and packet number shown
first, followed by the frames that are typically contained in those first, followed by the frames that are typically contained in those
packets. So, for instance the first packet is of type Initial, with packets. So, for instance the first packet is of type Initial, with
packet number 0, and contains a CRYPTO frame carrying the packet number 0, and contains a CRYPTO frame carrying the
ClientHello. ClientHello.
Multiple QUIC packets - even of different packet types - can be Multiple QUIC packets -- even of different packet types -- can be
coalesced into a single UDP datagram; see Section 12.2. As a result, coalesced into a single UDP datagram; see Section 12.2. As a result,
this handshake could consist of as few as 4 UDP datagrams, or any this handshake could consist of as few as 4 UDP datagrams, or any
number more (subject to limits inherent to the protocol, such as number more (subject to limits inherent to the protocol, such as
congestion control and anti-amplification). For instance, the congestion control and anti-amplification). For instance, the
server's first flight contains Initial packets, Handshake packets, server's first flight contains Initial packets, Handshake packets,
and "0.5-RTT data" in 1-RTT packets. and "0.5-RTT data" in 1-RTT packets.
Client Server Client Server
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
skipping to change at page 45, line 27 skipping to change at page 45, line 27
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
An endpoint MUST NOT send a parameter more than once in a given An endpoint MUST NOT send a parameter more than once in a given
transport parameters extension. An endpoint SHOULD treat receipt of transport parameters extension. An endpoint SHOULD treat receipt of
duplicate transport parameters as a connection error of type duplicate transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
Endpoints use transport parameters to authenticate the negotiation of Endpoints use transport parameters to authenticate the negotiation of
connection IDs during the handshake; see Section 7.3. connection IDs during the handshake; see Section 7.3.
Application Layer Protocol Negotiation (ALPN; see [ALPN]) allows Application-Layer Protocol Negotiation (ALPN; see [ALPN]) allows
clients to offer multiple application protocols during connection clients to offer multiple application protocols during connection
establishment. The transport parameters that a client includes establishment. The transport parameters that a client includes
during the handshake apply to all application protocols that the during the handshake apply to all application protocols that the
client offers. Application protocols can recommend values for client offers. Application protocols can recommend values for
transport parameters, such as the initial flow control limits. transport parameters, such as the initial flow control limits.
However, application protocols that set constraints on values for However, application protocols that set constraints on values for
transport parameters could make it impossible for a client to offer transport parameters could make it impossible for a client to offer
multiple application protocols if these constraints conflict. multiple application protocols if these constraints conflict.
7.4.1. Values of Transport Parameters for 0-RTT 7.4.1. Values of Transport Parameters for 0-RTT
skipping to change at page 47, line 7 skipping to change at page 47, line 7
o initial_max_streams_uni o initial_max_streams_uni
Omitting or setting a zero value for certain transport parameters can Omitting or setting a zero value for certain transport parameters can
result in 0-RTT data being enabled, but not usable. The applicable result in 0-RTT data being enabled, but not usable. The applicable
subset of transport parameters that permit sending of application subset of transport parameters that permit sending of application
data SHOULD be set to non-zero values for 0-RTT. This includes data SHOULD be set to non-zero values for 0-RTT. This includes
initial_max_data and either initial_max_streams_bidi and initial_max_data and either initial_max_streams_bidi and
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_bidi_remote, or initial_max_streams_uni and
initial_max_stream_data_uni. 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.
A server MAY store and recover the previously sent values of the A server MAY store and recover the previously sent values of the
max_idle_timeout, max_udp_payload_size, and disable_active_migration max_idle_timeout, max_udp_payload_size, and disable_active_migration
parameters and reject 0-RTT if it selects smaller values. Lowering parameters and reject 0-RTT if it selects smaller values. Lowering
the values of these parameters while also accepting 0-RTT data could the values of these parameters while also accepting 0-RTT data could
degrade the performance of the connection. Specifically, lowering degrade the performance of the connection. Specifically, lowering
the max_udp_payload_size could result in dropped packets leading to the max_udp_payload_size could result in dropped packets leading to
worse performance compared to rejecting 0-RTT data outright. worse performance compared to rejecting 0-RTT data outright.
A server MUST reject 0-RTT data if the restored values for transport A server MUST reject 0-RTT data if the restored values for transport
parameters cannot be supported. parameters cannot be supported.
skipping to change at page 60, line 13 skipping to change at page 60, line 13
endpoint validates ECN capability as described in Section 13.4. endpoint validates ECN capability as described in Section 13.4.
9.3. Responding to Connection Migration 9.3. Responding to Connection Migration
Receiving a packet from a new peer address containing a non-probing Receiving a packet from a new peer address containing a non-probing
frame indicates that the peer has migrated to that address. frame indicates that the peer has migrated to that address.
If the recipient permits the migration, it MUST send subsequent If the recipient permits the migration, it MUST send subsequent
packets to the new peer address and MUST initiate path validation packets to the new peer address and MUST initiate path validation
(Section 8.2) to verify the peer's ownership of the address if (Section 8.2) to verify the peer's ownership of the address if
validation is not already underway. validation is not already underway. 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.
An endpoint only changes the address to which it sends packets in An endpoint only changes the address to which it sends packets in
response to the highest-numbered non-probing packet. This ensures response to the highest-numbered non-probing packet. This ensures
that an endpoint does not send packets to an old peer address in the that an endpoint does not send packets to an old peer address in the
case that it receives reordered packets. case that it receives reordered packets.
An endpoint MAY send data to an unvalidated peer address, but it MUST 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 protect against potential attacks as described in Section 9.3.1 and
Section 9.3.2. An endpoint MAY skip validation of a peer address if Section 9.3.2. An endpoint MAY skip validation of a peer address if
that address has been seen recently. In particular, if an endpoint that address has been seen recently. In particular, if an endpoint
skipping to change at page 83, line 7 skipping to change at page 83, line 7
different packet number spaces. Packet numbers in each space start different packet number spaces. Packet numbers in each space start
at packet number 0. Subsequent packets sent in the same packet at packet number 0. Subsequent packets sent in the same packet
number space MUST increase the packet number by at least one. 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 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 loss recovery algorithms easier to implement between the two packet
types. types.
A QUIC endpoint MUST NOT reuse a packet number within the same packet A QUIC endpoint MUST NOT reuse a packet number within the same packet
number space in one connection. If the packet number for sending number space in one connection. If the packet number for sending
reaches 2^62 - 1, the sender MUST close the connection without reaches 2^62-1, the sender MUST close the connection without sending
sending a CONNECTION_CLOSE frame or any further packets; an endpoint a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send
MAY send a Stateless Reset (Section 10.3) in response to further a Stateless Reset (Section 10.3) in response to further packets that
packets that it receives. it receives.
A receiver MUST discard a newly unprotected packet unless it is A receiver MUST discard a newly unprotected packet unless it is
certain that it has not processed another packet with the same packet certain that it has not processed another packet with the same packet
number from the same packet number space. Duplicate suppression MUST number from the same packet number space. Duplicate suppression MUST
happen after removing packet protection for the reasons described in happen after removing packet protection for the reasons described in
Section 9.5 of [QUIC-TLS]. Section 9.5 of [QUIC-TLS].
Endpoints that track all individual packets for the purposes of Endpoints that track all individual packets for the purposes of
detecting duplicates are at risk of accumulating excessive state. detecting duplicates are at risk of accumulating excessive state.
The data required for detecting duplicates can be limited by The data required for detecting duplicates can be limited by
skipping to change at page 104, line 7 skipping to change at page 104, line 7
14.4. Sending QUIC PMTU Probes 14.4. Sending QUIC PMTU Probes
PMTU probes are ack-eliciting packets. PMTU probes are ack-eliciting packets.
Endpoints could limit the content of PMTU probes to PING and PADDING Endpoints could limit the content of PMTU probes to PING and PADDING
frames, since packets that are larger than the current maximum frames, since packets that are larger than the current maximum
datagram size are more likely to be dropped by the network. Loss of datagram size are more likely to be dropped by the network. Loss of
a QUIC packet that is carried in a PMTU probe is therefore not a a QUIC packet that is carried in a PMTU probe is therefore not a
reliable indication of congestion and SHOULD NOT trigger a congestion reliable indication of congestion and SHOULD NOT trigger a congestion
control reaction; see Section 3, Bullet 7 of [DPLPMTUD]. However, control reaction; see Bullet 7 in Section 3 of [DPLPMTUD]. However,
PMTU probes consume congestion window, which could delay subsequent PMTU probes consume congestion window, which could delay subsequent
transmission by an application. transmission by an application.
14.4.1. PMTU Probes Containing Source Connection ID 14.4.1. PMTU Probes Containing Source Connection ID
Endpoints that rely on the destination connection ID for routing Endpoints that rely on the destination connection ID for routing
incoming QUIC packets are likely to require that the connection ID be incoming QUIC packets are likely to require that the connection ID be
included in PMTU probes to route any resulting ICMP messages included in PMTU probes to route any resulting ICMP messages
(Section 14.2.1) back to the correct endpoint. However, only long (Section 14.2.1) back to the correct endpoint. However, only long
header packets (Section 17.2) contain the Source Connection ID field, header packets (Section 17.2) contain the Source Connection ID field,
skipping to change at page 109, line 8 skipping to change at page 109, line 8
Type-Specific Payload: The remainder of the packet, if any, is type- Type-Specific Payload: The remainder of the packet, if any, is type-
specific. specific.
In this version of QUIC, the following packet types with the long In this version of QUIC, the following packet types with the long
header are defined: header are defined:
+------+-----------+-----------------+ +------+-----------+-----------------+
| Type | Name | Section | | Type | Name | Section |
+------+-----------+-----------------+ +------+-----------+-----------------+
| 0x0 | Initial | Section 17.2.2 | | 0x00 | Initial | Section 17.2.2 |
| | | | | | | |
| 0x1 | 0-RTT | Section 17.2.3 | | 0x01 | 0-RTT | Section 17.2.3 |
| | | | | | | |
| 0x2 | Handshake | Section 17.2.4 | | 0x02 | Handshake | Section 17.2.4 |
| | | | | | | |
| 0x3 | Retry | Section 17.2.5 | | 0x03 | Retry | Section 17.2.5 |
+------+-----------+-----------------+ +------+-----------+-----------------+
Table 5: Long Header Packet Types Table 5: Long Header Packet Types
The header form bit, Destination and Source Connection ID lengths, The header form bit, Destination and Source Connection ID lengths,
Destination and Source Connection ID fields, and Version fields of a Destination and Source Connection ID fields, and Version fields of a
long header packet are version-independent. The other fields in the long header packet are version-independent. The other fields in the
first byte are version-specific. See [QUIC-INVARIANTS] for details first byte are version-specific. See [QUIC-INVARIANTS] for details
on how packets from different versions of QUIC are interpreted. on how packets from different versions of QUIC are interpreted.
skipping to change at page 111, line 30 skipping to change at page 111, line 30
Consequently, a Version Negotiation packet consumes an entire UDP Consequently, a Version Negotiation packet consumes an entire UDP
datagram. datagram.
A server MUST NOT send more than one Version Negotiation packet in A server MUST NOT send more than one Version Negotiation packet in
response to a single UDP datagram. response to a single UDP datagram.
See Section 6 for a description of the version negotiation process. See Section 6 for a description of the version negotiation process.
17.2.2. Initial Packet 17.2.2. Initial Packet
An Initial packet uses long headers with a type value of 0x0. It 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 carries the first CRYPTO frames sent by the client and server to
perform key exchange, and carries ACKs in either direction. perform key exchange, and carries ACKs in either direction.
Initial Packet { Initial Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 0, Long Packet Type (2) = 0,
Reserved Bits (2), Reserved Bits (2),
Packet Number Length (2), Packet Number Length (2),
Version (32), Version (32),
skipping to change at page 113, line 28 skipping to change at page 113, line 28
acknowledgment, no further Initial packets need to be exchanged acknowledgment, no further Initial packets need to be exchanged
beyond this point. Initial packet protection keys are discarded (see beyond this point. Initial packet protection keys are discarded (see
Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and
congestion control state; see Section 6.4 of [QUIC-RECOVERY]. congestion control state; see Section 6.4 of [QUIC-RECOVERY].
Any data in CRYPTO frames is discarded - and no longer retransmitted Any data in CRYPTO frames is discarded - and no longer retransmitted
- when Initial keys are discarded. - when Initial keys are discarded.
17.2.3. 0-RTT 17.2.3. 0-RTT
A 0-RTT packet uses long headers with a type value of 0x1, followed 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 by the Length and Packet Number fields; see Section 17.2. The first
byte contains the Reserved and Packet Number Length bits; see 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 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 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 completion. As part of the TLS handshake, the server can accept or
reject this early data. reject this early data.
See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its
limitations. limitations.
skipping to change at page 114, line 49 skipping to change at page 114, line 49
client cannot send an ACK frame in a 0-RTT packet, because that can client cannot send an ACK frame in a 0-RTT packet, because that can
only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT
packet MUST be carried in a 1-RTT packet. packet MUST be carried in a 1-RTT packet.
A server SHOULD treat a violation of remembered limits A server SHOULD treat a violation of remembered limits
(Section 7.4.1) as a connection error of an appropriate type (for (Section 7.4.1) as a connection error of an appropriate type (for
instance, a FLOW_CONTROL_ERROR for exceeding stream data limits). instance, a FLOW_CONTROL_ERROR for exceeding stream data limits).
17.2.4. Handshake Packet 17.2.4. Handshake Packet
A Handshake packet uses long headers with a type value of 0x2, A Handshake packet uses long headers with a type value of 0x02,
followed by the Length and Packet Number fields; see Section 17.2. followed by the Length and Packet Number fields; see Section 17.2.
The first byte contains the Reserved and Packet Number Length bits; The first byte contains the Reserved and Packet Number Length bits;
see Section 17.2. It is used to carry cryptographic handshake see Section 17.2. It is used to carry cryptographic handshake
messages and acknowledgments from the server and client. messages and acknowledgments from the server and client.
Handshake Packet { Handshake Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 2, Long Packet Type (2) = 2,
Reserved Bits (2), Reserved Bits (2),
skipping to change at page 116, line 7 skipping to change at page 116, line 7
CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt
of Handshake packets with other frames as a connection error of type of Handshake packets with other frames as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames
for Handshake packets is discarded - and no longer retransmitted - for Handshake packets is discarded - and no longer retransmitted -
when Handshake protection keys are discarded. when Handshake protection keys are discarded.
17.2.5. Retry Packet 17.2.5. Retry Packet
A Retry packet uses a long packet header with a type value of 0x3. 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 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. used by a server that wishes to perform a retry; see Section 8.1.
Retry Packet { Retry Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 3, Long Packet Type (2) = 3,
Unused (4), Unused (4),
Version (32), Version (32),
Destination Connection ID Length (8), Destination Connection ID Length (8),
skipping to change at page 123, line 35 skipping to change at page 123, line 35
amount of data that can be sent on the connection. This is amount of data that can be sent on the connection. This is
equivalent to sending a MAX_DATA (Section 19.9) for the connection equivalent to sending a MAX_DATA (Section 19.9) for the connection
immediately after completing the handshake. immediately after completing the handshake.
initial_max_stream_data_bidi_local (0x05): This parameter is an initial_max_stream_data_bidi_local (0x05): This parameter is an
integer value specifying the initial flow control limit for integer value specifying the initial flow control limit for
locally-initiated bidirectional streams. This limit applies to locally-initiated bidirectional streams. This limit applies to
newly created bidirectional streams opened by the endpoint that newly created bidirectional streams opened by the endpoint that
sends the transport parameter. In client transport parameters, sends the transport parameter. In client transport parameters,
this applies to streams with an identifier with the least this applies to streams with an identifier with the least
significant two bits set to 0x0; in server transport parameters, significant two bits set to 0x00; in server transport parameters,
this applies to streams with the least significant two bits set to this applies to streams with the least significant two bits set to
0x1. 0x01.
initial_max_stream_data_bidi_remote (0x06): This parameter is an initial_max_stream_data_bidi_remote (0x06): This parameter is an
integer value specifying the initial flow control limit for peer- integer value specifying the initial flow control limit for peer-
initiated bidirectional streams. This limit applies to newly initiated bidirectional streams. This limit applies to newly
created bidirectional streams opened by the endpoint that receives created bidirectional streams opened by the endpoint that receives
the transport parameter. In client transport parameters, this the transport parameter. In client transport parameters, this
applies to streams with an identifier with the least significant applies to streams with an identifier with the least significant
two bits set to 0x1; in server transport parameters, this applies two bits set to 0x01; in server transport parameters, this applies
to streams with the least significant two bits set to 0x0. to streams with the least significant two bits set to 0x00.
initial_max_stream_data_uni (0x07): This parameter is an integer initial_max_stream_data_uni (0x07): This parameter is an integer
value specifying the initial flow control limit for unidirectional value specifying the initial flow control limit for unidirectional
streams. This limit applies to newly created unidirectional streams. This limit applies to newly created unidirectional
streams opened by the endpoint that receives the transport streams opened by the endpoint that receives the transport
parameter. In client transport parameters, this applies to parameter. In client transport parameters, this applies to
streams with an identifier with the least significant two bits set streams with an identifier with the least significant two bits set
to 0x3; in server transport parameters, this applies to streams to 0x03; in server transport parameters, this applies to streams
with the least significant two bits set to 0x2. with the least significant two bits set to 0x02.
initial_max_streams_bidi (0x08): The initial maximum bidirectional initial_max_streams_bidi (0x08): The initial maximum bidirectional
streams parameter is an integer value that contains the initial streams parameter is an integer value that contains the initial
maximum number of bidirectional streams the endpoint that receives maximum number of bidirectional streams the endpoint that receives
this transport parameter is permitted to initiate. If this this transport parameter is permitted to initiate. If this
parameter is absent or zero, the peer cannot open bidirectional parameter is absent or zero, the peer cannot open bidirectional
streams until a MAX_STREAMS frame is sent. Setting this parameter streams until a MAX_STREAMS frame is sent. Setting this parameter
is equivalent to sending a MAX_STREAMS (Section 19.11) of the is equivalent to sending a MAX_STREAMS (Section 19.11) of the
corresponding type with the same value. corresponding type with the same value.
skipping to change at page 132, line 12 skipping to change at page 132, line 12
the stream by the RESET_STREAM sender, in unit of bytes; see the stream by the RESET_STREAM sender, in unit of bytes; see
Section 4.5. Section 4.5.
19.5. STOP_SENDING Frames 19.5. STOP_SENDING Frames
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that
incoming data is being discarded on receipt at application request. incoming data is being discarded on receipt at application request.
STOP_SENDING requests that a peer cease transmission on a stream. 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 A STOP_SENDING frame can be sent for streams in the Recv or Size
Known states; see Section 3.1. Receiving a STOP_SENDING frame for a Known states; see Section 3.2. Receiving a STOP_SENDING frame for a
locally-initiated stream that has not yet been created MUST be locally-initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR. An treated as a connection error of type STREAM_STATE_ERROR. An
endpoint that receives a STOP_SENDING frame for a receive-only stream endpoint that receives a STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error STREAM_STATE_ERROR. MUST terminate the connection with error STREAM_STATE_ERROR.
STOP_SENDING frames are formatted as shown in Figure 27. STOP_SENDING frames are formatted as shown in Figure 27.
STOP_SENDING Frame { STOP_SENDING Frame {
Type (i) = 0x05, Type (i) = 0x05,
Stream ID (i), Stream ID (i),
skipping to change at page 136, line 40 skipping to change at page 136, line 40
receives more data than the maximum data value that it has sent. receives more data than the maximum data value that it has sent.
This includes violations of remembered limits in Early Data; see This includes violations of remembered limits in Early Data; see
Section 7.4.1. Section 7.4.1.
19.10. MAX_STREAM_DATA Frames 19.10. MAX_STREAM_DATA Frames
A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform 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 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; A MAX_STREAM_DATA frame can be sent for streams in the Recv state;
see Section 3.1. Receiving a MAX_STREAM_DATA frame for a locally- see Section 3.2. Receiving a MAX_STREAM_DATA frame for a locally-
initiated stream that has not yet been created MUST be treated as a initiated stream that has not yet been created MUST be treated as a
connection error of type STREAM_STATE_ERROR. An endpoint that connection error of type STREAM_STATE_ERROR. An endpoint that
receives a MAX_STREAM_DATA frame for a receive-only stream MUST receives a MAX_STREAM_DATA frame for a receive-only stream MUST
terminate the connection with error STREAM_STATE_ERROR. terminate the connection with error STREAM_STATE_ERROR.
MAX_STREAM_DATA frames are formatted as shown in Figure 32. MAX_STREAM_DATA frames are formatted as shown in Figure 32.
MAX_STREAM_DATA Frame { MAX_STREAM_DATA Frame {
Type (i) = 0x11, Type (i) = 0x11,
Stream ID (i), Stream ID (i),
skipping to change at page 146, line 11 skipping to change at page 146, line 11
QUIC transport error codes and application error codes are 62-bit QUIC transport error codes and application error codes are 62-bit
unsigned integers. unsigned integers.
20.1. Transport Error Codes 20.1. Transport Error Codes
This section lists the defined QUIC transport error codes that can be 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 used in a CONNECTION_CLOSE frame with a type of 0x1c. These errors
apply to the entire connection. apply to the entire connection.
NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to NO_ERROR (0x00): An endpoint uses this with CONNECTION_CLOSE to
signal that the connection is being closed abruptly in the absence signal that the connection is being closed abruptly in the absence
of any error. of any error.
INTERNAL_ERROR (0x1): The endpoint encountered an internal error and INTERNAL_ERROR (0x01): The endpoint encountered an internal error
cannot continue with the connection. and cannot continue with the connection.
CONNECTION_REFUSED (0x2): The server refused to accept a new CONNECTION_REFUSED (0x02): The server refused to accept a new
connection. connection.
FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it FLOW_CONTROL_ERROR (0x03): An endpoint received more data than it
permitted in its advertised data limits; see Section 4. permitted in its advertised data limits; see Section 4.
STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream STREAM_LIMIT_ERROR (0x04): An endpoint received a frame for a stream
identifier that exceeded its advertised stream limit for the identifier that exceeded its advertised stream limit for the
corresponding stream type. corresponding stream type.
STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 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. that was not in a state that permitted that frame; see Section 3.
FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame FINAL_SIZE_ERROR (0x06): An endpoint received a STREAM frame
containing data that exceeded the previously established final containing data that exceeded the previously established final
size. Or an endpoint received a STREAM frame or a RESET_STREAM size. Or an endpoint received a STREAM frame or a RESET_STREAM
frame containing a final size that was lower than the size of frame containing a final size that was lower than the size of
stream data that was already received. Or an endpoint received a stream data that was already received. Or an endpoint received a
STREAM frame or a RESET_STREAM frame containing a different final STREAM frame or a RESET_STREAM frame containing a different final
size to the one already established. size to the one already established.
FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was FRAME_ENCODING_ERROR (0x07): An endpoint received a frame that was
badly formatted. For instance, a frame of an unknown type, or an badly formatted. For instance, a frame of an unknown type, or an
ACK frame that has more acknowledgment ranges than the remainder ACK frame that has more acknowledgment ranges than the remainder
of the packet could carry. of the packet could carry.
TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport TRANSPORT_PARAMETER_ERROR (0x08): An endpoint received transport
parameters that were badly formatted, included an invalid value, parameters that were badly formatted, included an invalid value,
omitted a mandatory transport parameter, included a forbidden omitted a mandatory transport parameter, included a forbidden
transport parameter, or were otherwise in error. transport parameter, or were otherwise in error.
CONNECTION_ID_LIMIT_ERROR (0x9): The number of connection IDs CONNECTION_ID_LIMIT_ERROR (0x09): The number of connection IDs
provided by the peer exceeds the advertised provided by the peer exceeds the advertised
active_connection_id_limit. active_connection_id_limit.
PROTOCOL_VIOLATION (0xa): An endpoint detected an error with PROTOCOL_VIOLATION (0x0a): An endpoint detected an error with
protocol compliance that was not covered by more specific error protocol compliance that was not covered by more specific error
codes. codes.
INVALID_TOKEN (0xb): A server received a client Initial that INVALID_TOKEN (0x0b): A server received a client Initial that
contained an invalid Token field. contained an invalid Token field.
APPLICATION_ERROR (0xc): The application or application protocol APPLICATION_ERROR (0x0c): The application or application protocol
caused the connection to be closed. caused the connection to be closed.
CRYPTO_BUFFER_EXCEEDED (0xd): An endpoint has received more data in CRYPTO_BUFFER_EXCEEDED (0x0d): An endpoint has received more data in
CRYPTO frames than it can buffer. CRYPTO frames than it can buffer.
KEY_UPDATE_ERROR (0xe): An endpoint detected errors in performing KEY_UPDATE_ERROR (0x0e): An endpoint detected errors in performing
key updates; see Section 6 of [QUIC-TLS]. key updates; see Section 6 of [QUIC-TLS].
AEAD_LIMIT_REACHED (0xf): An endpoint has reached the AEAD_LIMIT_REACHED (0x0f): An endpoint has reached the
confidentiality or integrity limit for the AEAD algorithm used by confidentiality or integrity limit for the AEAD algorithm used by
the given connection. the given connection.
NO_VIABLE_PATH (0x10): An endpoint has determined that the network NO_VIABLE_PATH (0x10): An endpoint has determined that the network
path is incapable of supporting QUIC. An endpoint is unlikely to path is incapable of supporting QUIC. An endpoint is unlikely to
receive CONNECTION_CLOSE carrying this code except when the path receive CONNECTION_CLOSE carrying this code except when the path
does not support a large enough MTU. does not support a large enough MTU.
CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range CRYPTO_ERROR (0x01XX): The cryptographic handshake failed. A range
of 256 values is reserved for carrying error codes specific to the of 256 values is reserved for carrying error codes specific to the
cryptographic handshake that is used. Codes for errors occurring cryptographic handshake that is used. Codes for errors occurring
when TLS is used for the crypto handshake are described in when TLS is used for the crypto handshake are described in
Section 4.8 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 22.5 for details of registering new error codes. See Section 22.5 for details of registering new error codes.
In defining these error codes, several principles are applied. Error In defining these error codes, several principles are applied. Error
conditions that might require specific action on the part of a conditions that might require specific action on the part of a
recipient are given unique codes. Errors that represent common recipient are given unique codes. Errors that represent common
skipping to change at page 171, line 15 skipping to change at page 171, line 15
22.4. QUIC Frame Types Registry 22.4. QUIC Frame Types Registry
IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
"QUIC" heading. "QUIC" heading.
The "QUIC Frame Types" registry governs a 62-bit space. This The "QUIC Frame Types" registry governs a 62-bit space. This
registry follows the registration policy from Section 22.1. registry follows the registration policy from Section 22.1.
Permanent registrations in this registry are assigned using the Permanent registrations in this registry are assigned using the
Specification Required policy ([RFC8126]), except for values between Specification Required policy ([RFC8126]), except for values between
0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
Standards Action or IESG Approval as defined in Section 4.9 and 4.10 Standards Action or IESG Approval as defined in Sections 4.9 and 4.10
of [RFC8126]. of [RFC8126].
In addition to the fields in Section 22.1.1, permanent registrations In addition to the fields in Section 22.1.1, permanent registrations
in this registry MUST include the following field: in this registry MUST include the following field:
Frame Name: A short mnemonic for the frame type. Frame Name: A short mnemonic for the frame type.
In addition to the advice in Section 22.1, specifications for new In addition to the advice in Section 22.1, specifications for new
permanent registrations SHOULD describe the means by which an permanent registrations SHOULD describe the means by which an
endpoint might determine that it can send the identified type of endpoint might determine that it can send the identified type of
skipping to change at page 171, line 46 skipping to change at page 171, line 46
IANA [SHALL add/has added] a registry for "QUIC Transport Error IANA [SHALL add/has added] a registry for "QUIC Transport Error
Codes" under a "QUIC" heading. Codes" under a "QUIC" heading.
The "QUIC Transport Error Codes" registry governs a 62-bit space. The "QUIC Transport Error Codes" registry governs a 62-bit space.
This space is split into three regions that are governed by different This space is split into three regions that are governed by different
policies. Permanent registrations in this registry are assigned policies. Permanent registrations in this registry are assigned
using the Specification Required policy ([RFC8126]), except for using the Specification Required policy ([RFC8126]), except for
values between 0x00 and 0x3f (in hexadecimal; inclusive), which are values between 0x00 and 0x3f (in hexadecimal; inclusive), which are
assigned using Standards Action or IESG Approval as defined in assigned using Standards Action or IESG Approval as defined in
Section 4.9 and 4.10 of [RFC8126]. Sections 4.9 and 4.10 of [RFC8126].
In addition to the fields in Section 22.1.1, permanent registrations In addition to the fields in Section 22.1.1, permanent registrations
in this registry MUST include the following fields: in this registry MUST include the following fields:
Code: A short mnemonic for the parameter. Code: A short mnemonic for the parameter.
Description: A brief description of the error code semantics, which Description: A brief description of the error code semantics, which
MAY be a summary if a specification reference is provided. MAY be a summary if a specification reference is provided.
The initial contents of this registry are shown in Table 7. The initial contents of this registry are shown in Table 7.
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| Valu | Code | Description | Specification | | Valu | Code | Description | Specification |
| e | | | | | e | | | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x0 | NO_ERROR | No error | Section 20 | | 0x00 | NO_ERROR | No error | Section 20 |
| | | | | | | | | |
| 0x1 | INTERNAL_ERROR | Implementation | Section 20 | | 0x01 | INTERNAL_ERROR | Implementation | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0x2 | CONNECTION_REFUSED | Server refuses | Section 20 | | 0x02 | CONNECTION_REFUSED | Server refuses | Section 20 |
| | | a connection | | | | | a connection | |
| | | | | | | | | |
| 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | | 0x03 | FLOW_CONTROL_ERROR | Flow control | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 | | 0x04 | STREAM_LIMIT_ERROR | Too many | Section 20 |
| | | streams opened | | | | | streams opened | |
| | | | | | | | | |
| 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | | 0x05 | STREAM_STATE_ERROR | Frame received | Section 20 |
| | | in invalid | | | | | in invalid | |
| | | stream state | | | | | stream state | |
| | | | | | | | | |
| 0x6 | FINAL_SIZE_ERROR | Change to | Section 20 | | 0x06 | FINAL_SIZE_ERROR | Change to | Section 20 |
| | | final size | | | | | final size | |
| | | | | | | | | |
| 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | | 0x07 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | | 0x08 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 |
| | | transport | | | | | transport | |
| | | parameters | | | | | parameters | |
| | | | | | | | | |
| 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many | Section 20 | | 0x09 | CONNECTION_ID_LIMIT_ERROR | Too many | Section 20 |
| | | connection IDs | | | | | connection IDs | |
| | | received | | | | | received | |
| | | | | | | | | |
| 0xa | PROTOCOL_VIOLATION | Generic | Section 20 | | 0x0a | PROTOCOL_VIOLATION | Generic | Section 20 |
| | | protocol | | | | | protocol | |
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xb | INVALID_TOKEN | Invalid Token | Section 20 | | 0x0b | INVALID_TOKEN | Invalid Token | Section 20 |
| | | Received | | | | | Received | |
| | | | | | | | | |
| 0xc | APPLICATION_ERROR | Application | Section 20 | | 0x0c | APPLICATION_ERROR | Application | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0xd | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 | | 0x0d | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 |
| | | buffer | | | | | buffer | |
| | | overflowed | | | | | overflowed | |
| | | | | | | | | |
| 0xe | KEY_UPDATE_ERROR | Invalid packet | Section 20 | | 0x0e | KEY_UPDATE_ERROR | Invalid packet | Section 20 |
| | | protection | | | | | protection | |
| | | update | | | | | update | |
| | | | | | | | | |
| 0xf | AEAD_LIMIT_REACHED | Excessive use | Section 20 | | 0x0f | AEAD_LIMIT_REACHED | Excessive use | Section 20 |
| | | of packet | | | | | of packet | |
| | | protection | | | | | protection | |
| | | keys | | | | | keys | |
| | | | | | | | | |
| 0x10 | NO_VIABLE_PATH | No viable | Section 20 | | 0x10 | NO_VIABLE_PATH | No viable | Section 20 |
| | | network path | | | | | network path | |
| | | exists | | | | | exists | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
skipping to change at page 174, line 7 skipping to change at page 174, line 7
Cotton, M., "Early IANA Allocation of Standards Track Code Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>. 2014, <https://www.rfc-editor.org/info/rfc7120>.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-13 (work in progress), January draft-ietf-quic-invariants-latest (work in progress).
2021.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-34 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress), January 2021. (work in progress).
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls-
tls-34 (work in progress), January 2021. latest (work in progress).
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 176, line 27 skipping to change at page 176, line 27
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-08 Transport Protocol", draft-ietf-quic-manageability-10
(work in progress), November 2020. (work in progress), February 2021.
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
skipping to change at page 179, line 44 skipping to change at page 179, line 44
min_bits = log(num_unacked, 2) + 1 min_bits = log(num_unacked, 2) + 1
num_bytes = ceil(min_bits / 8) num_bytes = ceil(min_bits / 8)
// Encode the integer value and truncate to // Encode the integer value and truncate to
// the num_bytes least-significant bytes. // the num_bytes least-significant bytes.
return encode(full_pn, num_bytes) return encode(full_pn, num_bytes)
Figure 44: Sample Packet Number Encoding Algorithm Figure 44: Sample Packet Number Encoding Algorithm
For example, if an endpoint has received an acknowledgment for packet For example, if an endpoint has received an acknowledgment for packet
0xabe8bc and is sending a packet with a number of 0xac5c02, there are 0xabe8b3 and is sending a packet with a number of 0xac5c02, there are
29,519 (0x734f) outstanding packets. In order to represent at least 29,519 (0x734f) outstanding packet numbers. In order to represent at
twice this range (59,038 packets, or 0xe69e), 16 bits are required. 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 In the same state, sending a packet with a number of 0xace8fe needs
the 24-bit encoding, because at least 18 bits are required to the 24-bit encoding, because at least 18 bits are required to
represent twice the range (131,182 packets, or 0x2006e). represent twice the range (131,222 packets, or 0x020096).
A.3. Sample Packet Number Decoding Algorithm A.3. Sample Packet Number Decoding Algorithm
The pseudocode in Figure 45 includes an example algorithm for The pseudocode in Figure 45 includes an example algorithm for
decoding packet numbers after header protection has been removed. decoding packet numbers after header protection has been removed.
The DecodePacketNumber function takes three arguments: The DecodePacketNumber function takes three arguments:
o largest_pn is the largest packet number that has been successfully o largest_pn is the largest packet number that has been successfully
processed in the current packet number space. processed in the current packet number space.
skipping to change at page 184, line 7 skipping to change at page 184, line 7
arrival and avoid unnecessary retransmission (#3956, #3957) arrival and avoid unnecessary retransmission (#3956, #3957)
o Allow a server to reject connections if a client reuses packet o Allow a server to reject connections if a client reuses packet
numbers after Retry (#3989, #3990) numbers after Retry (#3989, #3990)
o Limit recommendation for immediate acknowledgment to when ack- o Limit recommendation for immediate acknowledgment to when ack-
eliciting packets are reordered (#4001, #4000) eliciting packets are reordered (#4001, #4000)
B.5. Since draft-ietf-quic-transport-28 B.5. Since draft-ietf-quic-transport-28
o Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED o Made SERVER_BUSY error (0x02) more generic, now CONNECTION_REFUSED
(#3709, #3690, #3694) (#3709, #3690, #3694)
o Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs o Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs
(#3703, #3691) (#3703, #3691)
o Integrate QUIC-specific language from draft-ietf-tsvwg-datagram- o Integrate QUIC-specific language from draft-ietf-tsvwg-datagram-
plpmtud (#3695, #3702) plpmtud (#3695, #3702)
o disable_active_migration does not apply to the addresses offered o disable_active_migration does not apply to the addresses offered
in server_preferred_address (#3608, #3670) in server_preferred_address (#3608, #3670)
skipping to change at page 189, line 43 skipping to change at page 189, line 43
B.14. Since draft-ietf-quic-transport-19 B.14. Since draft-ietf-quic-transport-19
o Refine discussion of 0-RTT transport parameters (#2467, #2464) o Refine discussion of 0-RTT transport parameters (#2467, #2464)
o Fewer transport parameters need to be remembered for 0-RTT (#2624, o Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467) #2467)
o Spin bit text incorporated (#2564) o Spin bit text incorporated (#2564)
o Close the connection when maximum stream ID in MAX_STREAMS exceeds o Close the connection when maximum stream ID in MAX_STREAMS exceeds
2^62 - 1 (#2499, #2487) 2^62-1 (#2499, #2487)
o New connection ID required for intentional migration (#2414, o New connection ID required for intentional migration (#2414,
#2413) #2413)
o Connection ID issuance can be rate-limited (#2436, #2428) o Connection ID issuance can be rate-limited (#2436, #2428)
o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
o Initial packets from clients need to be padded to 1200 unless a o Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523) Handshake packet is sent as well (#2522, #2523)
 End of changes. 77 change blocks. 
94 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/