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/