draft-ietf-quic-transport-latest.txt		draft-ietf-quic-transport-auth48.txt
	skipping to change at page 2, line 7 ¶		skipping to change at line 52 ¶
	(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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6		1. Overview
	1.1. Document Structure . . . . . . . . . . . . . . . . . . . 7		1.1. Document Structure
	1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8		1.2. Terms and Definitions
	1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9		1.3. Notational Conventions
	2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		2. Streams
	2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 11		2.1. Stream Types and Identifiers
	2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 12		2.2. Sending and Receiving Data
	2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13		2.3. Stream Prioritization
	2.4. Operations on Streams . . . . . . . . . . . . . . . . . . 13		2.4. Operations on Streams
	3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14		3. Stream States
	3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 15		3.1. Sending Stream States
	3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 17		3.2. Receiving Stream States
	3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 20		3.3. Permitted Frame Types
	3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 20		3.4. Bidirectional Stream States
	3.5. Solicited State Transitions . . . . . . . . . . . . . . . 22		3.5. Solicited State Transitions
	4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23		4. Flow Control
	4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 23		4.1. Data Flow Control
	4.2. Increasing Flow Control Limits . . . . . . . . . . . . . 24		4.2. Increasing Flow Control Limits
	4.3. Flow Control Performance . . . . . . . . . . . . . . . . 25		4.3. Flow Control Performance
	4.4. Handling Stream Cancellation . . . . . . . . . . . . . . 25		4.4. Handling Stream Cancellation
	4.5. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26		4.5. Stream Final Size
	4.6. Controlling Concurrency . . . . . . . . . . . . . . . . . 27		4.6. Controlling Concurrency
	5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27		5. Connections
	5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 28		5.1. Connection ID
	5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 29		5.1.1. Issuing Connection IDs
	5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 31		5.1.2. Consuming and Retiring Connection IDs
	5.2. Matching Packets to Connections . . . . . . . . . . . . . 32		5.2. Matching Packets to Connections
	5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 33		5.2.1. Client Packet Handling
	5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 33		5.2.2. Server Packet Handling
	5.2.3. Considerations for Simple Load Balancers . . . . . . 34		5.2.3. Considerations for Simple Load Balancers
	5.3. Operations on Connections . . . . . . . . . . . . . . . . 34		5.3. Operations on Connections
	6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 36		6. Version Negotiation
	6.1. Sending Version Negotiation Packets . . . . . . . . . . . 36		6.1. Sending Version Negotiation Packets
	6.2. Handling Version Negotiation Packets . . . . . . . . . . 36		6.2. Handling Version Negotiation Packets
	6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 37		6.3. Using Reserved Versions
	7. Cryptographic and Transport Handshake . . . . . . . . . . . . 37		7. Cryptographic and Transport Handshake
	7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 39		7.1. Example Handshake Flows
	7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 40		7.2. Negotiating Connection IDs
	7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 41		7.3. Authenticating Connection IDs
	7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 43		7.4. Transport Parameters
	7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 44		7.4.1. Values of Transport Parameters for 0-RTT
	7.4.2. New Transport Parameters . . . . . . . . . . . . . . 46		7.4.2. New Transport Parameters
	7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 47		7.5. Cryptographic Message Buffering
	8. Address Validation . . . . . . . . . . . . . . . . . . . . . 47		8. Address Validation
	8.1. Address Validation during Connection Establishment . . . 48		8.1. Address Validation during Connection Establishment
	8.1.1. Token Construction . . . . . . . . . . . . . . . . . 49		8.1.1. Token Construction
	8.1.2. Address Validation Using Retry Packets . . . . . . . 49		8.1.2. Address Validation Using Retry Packets
	8.1.3. Address Validation for Future Connections . . . . . . 50		8.1.3. Address Validation for Future Connections
	8.1.4. Address Validation Token Integrity . . . . . . . . . 52		8.1.4. Address Validation Token Integrity
	8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 53		8.2. Path Validation
	8.2.1. Initiating Path Validation . . . . . . . . . . . . . 54		8.2.1. Initiating Path Validation
	8.2.2. Path Validation Responses . . . . . . . . . . . . . . 55		8.2.2. Path Validation Responses
	8.2.3. Successful Path Validation . . . . . . . . . . . . . 56		8.2.3. Successful Path Validation
	8.2.4. Failed Path Validation . . . . . . . . . . . . . . . 56		8.2.4. Failed Path Validation
	9. Connection Migration . . . . . . . . . . . . . . . . . . . . 57		9. Connection Migration
	9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 58		9.1. Probing a New Path
	9.2. Initiating Connection Migration . . . . . . . . . . . . . 58		9.2. Initiating Connection Migration
	9.3. Responding to Connection Migration . . . . . . . . . . . 59		9.3. Responding to Connection Migration
	9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 59		9.3.1. Peer Address Spoofing
	9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 60		9.3.2. On-Path Address Spoofing
	9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 60		9.3.3. Off-Path Packet Forwarding
	9.4. Loss Detection and Congestion Control . . . . . . . . . . 61		9.4. Loss Detection and Congestion Control
	9.5. Privacy Implications of Connection Migration . . . . . . 62		9.5. Privacy Implications of Connection Migration
	9.6. Server's Preferred Address . . . . . . . . . . . . . . . 64		9.6. Server's Preferred Address
	9.6.1. Communicating a Preferred Address . . . . . . . . . . 64		9.6.1. Communicating a Preferred Address
	9.6.2. Migration to a Preferred Address . . . . . . . . . . 64		9.6.2. Migration to a Preferred Address
	9.6.3. Interaction of Client Migration and Preferred Address 65		9.6.3. Interaction of Client Migration and Preferred Address
	9.7. Use of IPv6 Flow Label and Migration . . . . . . . . . . 66		9.7. Use of IPv6 Flow Label and Migration
	10. Connection Termination . . . . . . . . . . . . . . . . . . . 66		10. Connection Termination
	10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 66		10.1. Idle Timeout
	10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 67		10.1.1. Liveness Testing
	10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 67		10.1.2. Deferring Idle Timeout
	10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 68		10.2. Immediate Close
	10.2.1. Closing Connection State . . . . . . . . . . . . . . 69		10.2.1. Closing Connection State
	10.2.2. Draining Connection State . . . . . . . . . . . . . 70		10.2.2. Draining Connection State
	10.2.3. Immediate Close during the Handshake . . . . . . . . 70		10.2.3. Immediate Close during the Handshake
	10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 72		10.3. Stateless Reset
	10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 74		10.3.1. Detecting a Stateless Reset
	10.3.2. Calculating a Stateless Reset Token . . . . . . . . 75		10.3.2. Calculating a Stateless Reset Token
	10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 76		10.3.3. Looping
	11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 77		11. Error Handling
	11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 77		11.1. Connection Errors
	11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 78		11.2. Stream Errors
	12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 79		12. Packets and Frames
	12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 79		12.1. Protected Packets
	12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 80		12.2. Coalescing Packets
	12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 81		12.3. Packet Numbers
	12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 82		12.4. Frames and Frame Types
	12.5. Frames and Number Spaces . . . . . . . . . . . . . . . . 86		12.5. Frames and Number Spaces
	13. Packetization and Reliability . . . . . . . . . . . . . . . . 87		13. Packetization and Reliability
	13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 87		13.1. Packet Processing
	13.2. Generating Acknowledgments . . . . . . . . . . . . . . . 88		13.2. Generating Acknowledgments
	13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 88		13.2.1. Sending ACK Frames
	13.2.2. Acknowledgment Frequency . . . . . . . . . . . . . . 89		13.2.2. Acknowledgment Frequency
	13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 90		13.2.3. Managing ACK Ranges
	13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 91		13.2.4. Limiting Ranges by Tracking ACK Frames
	13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 92		13.2.5. Measuring and Reporting Host Delay
	13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 92		13.2.6. ACK Frames and Packet Protection
	13.2.7. PADDING Frames Consume Congestion Window . . . . . . 92		13.2.7. PADDING Frames Consume Congestion Window
	13.3. Retransmission of Information . . . . . . . . . . . . . 93		13.3. Retransmission of Information
	13.4. Explicit Congestion Notification . . . . . . . . . . . . 95		13.4. Explicit Congestion Notification
	13.4.1. Reporting ECN Counts . . . . . . . . . . . . . . . . 96		13.4.1. Reporting ECN Counts
	13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 96		13.4.2. ECN Validation
	14. Datagram Size . . . . . . . . . . . . . . . . . . . . . . . . 98		14. Datagram Size
	14.1. Initial Datagram Size . . . . . . . . . . . . . . . . . 99		14.1. Initial Datagram Size
	14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 100		14.2. Path Maximum Transmission Unit
	14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 101		14.2.1. Handling of ICMP Messages by PMTUD
	14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 102		14.3. Datagram Packetization Layer PMTU Discovery
	14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 102		14.3.1. DPLPMTUD and Initial Connectivity
	14.3.2. Validating the Network Path with DPLPMTUD . . . . . 102		14.3.2. Validating the Network Path with DPLPMTUD
	14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 102		14.3.3. Handling of ICMP Messages by DPLPMTUD
	14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 102		14.4. Sending QUIC PMTU Probes
	14.4.1. PMTU Probes Containing Source Connection ID . . . . 103		14.4.1. PMTU Probes Containing Source Connection ID
	15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 103		15. Versions
	16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 104		16. Variable-Length Integer Encoding
	17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 105		17. Packet Formats
	17.1. Packet Number Encoding and Decoding . . . . . . . . . . 105		17.1. Packet Number Encoding and Decoding
	17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 106		17.2. Long Header Packets
	17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 109		17.2.1. Version Negotiation Packet
	17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 110		17.2.2. Initial Packet
	17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 112		17.2.3. 0-RTT
	17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 114		17.2.4. Handshake Packet
	17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 115		17.2.5. Retry Packet
	17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 117		17.3. Short Header Packets
	17.3.1. 1-RTT Packet . . . . . . . . . . . . . . . . . . . . 117		17.3.1. 1-RTT Packet
	17.4. Latency Spin Bit . . . . . . . . . . . . . . . . . . . . 119		17.4. Latency Spin Bit
	18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 120		18. Transport Parameter Encoding
	18.1. Reserved Transport Parameters . . . . . . . . . . . . . 121		18.1. Reserved Transport Parameters
	18.2. Transport Parameter Definitions . . . . . . . . . . . . 121		18.2. Transport Parameter Definitions
	19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 125		19. Frame Types and Formats
	19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 125		19.1. PADDING Frames
	19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 126		19.2. PING Frames
	19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 126		19.3. ACK Frames
	19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 128		19.3.1. ACK Ranges
	19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 129		19.3.2. ECN Counts
	19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 130		19.4. RESET_STREAM Frames
	19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 131		19.5. STOP_SENDING Frames
	19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 131		19.6. CRYPTO Frames
	19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 132		19.7. NEW_TOKEN Frames
	19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 133		19.8. STREAM Frames
	19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 135		19.9. MAX_DATA Frames
	19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 135		19.10. MAX_STREAM_DATA Frames
	19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 136		19.11. MAX_STREAMS Frames
	19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 137		19.12. DATA_BLOCKED Frames
	19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 138		19.13. STREAM_DATA_BLOCKED Frames
	19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 138		19.14. STREAMS_BLOCKED Frames
	19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 139		19.15. NEW_CONNECTION_ID Frames
	19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 140		19.16. RETIRE_CONNECTION_ID Frames
	19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 141		19.17. PATH_CHALLENGE Frames
	19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 142		19.18. PATH_RESPONSE Frames
	19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 142		19.19. CONNECTION_CLOSE Frames
	19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 143		19.20. HANDSHAKE_DONE Frames
	19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 144		19.21. Extension Frames
	20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 144		20. Error Codes
	20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 145		20.1. Transport Error Codes
	20.2. Application Protocol Error Codes . . . . . . . . . . . . 146		20.2. Application Protocol Error Codes
	21. Security Considerations . . . . . . . . . . . . . . . . . . . 147		21. Security Considerations
	21.1. Overview of Security Properties . . . . . . . . . . . . 147		21.1. Overview of Security Properties
	21.1.1. Handshake . . . . . . . . . . . . . . . . . . . . . 147		21.1.1. Handshake
	21.1.2. Protected Packets . . . . . . . . . . . . . . . . . 149		21.1.2. Protected Packets
	21.1.3. Connection Migration . . . . . . . . . . . . . . . . 150		21.1.3. Connection Migration
	21.2. Handshake Denial of Service . . . . . . . . . . . . . . 154		21.2. Handshake Denial of Service
	21.3. Amplification Attack . . . . . . . . . . . . . . . . . . 155		21.3. Amplification Attack
	21.4. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 155		21.4. Optimistic ACK Attack
	21.5. Request Forgery Attacks . . . . . . . . . . . . . . . . 156		21.5. Request Forgery Attacks
	21.5.1. Control Options for Endpoints . . . . . . . . . . . 157		21.5.1. Control Options for Endpoints
	21.5.2. Request Forgery with Client Initial Packets . . . . 158		21.5.2. Request Forgery with Client Initial Packets
	21.5.3. Request Forgery with Preferred Addresses . . . . . . 159		21.5.3. Request Forgery with Preferred Addresses
	21.5.4. Request Forgery with Spoofed Migration . . . . . . . 159		21.5.4. Request Forgery with Spoofed Migration
	21.5.5. Request Forgery with Version Negotiation . . . . . . 160		21.5.5. Request Forgery with Version Negotiation
	21.5.6. Generic Request Forgery Countermeasures . . . . . . 160		21.5.6. Generic Request Forgery Countermeasures
	21.6. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 161		21.6. Slowloris Attacks
	21.7. Stream Fragmentation and Reassembly Attacks . . . . . . 161		21.7. Stream Fragmentation and Reassembly Attacks
	21.8. Stream Commitment Attack . . . . . . . . . . . . . . . . 162		21.8. Stream Commitment Attack
	21.9. Peer Denial of Service . . . . . . . . . . . . . . . . . 162		21.9. Peer Denial of Service
	21.10. Explicit Congestion Notification Attacks . . . . . . . . 163		21.10. Explicit Congestion Notification Attacks
	21.11. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 163		21.11. Stateless Reset Oracle
	21.12. Version Downgrade . . . . . . . . . . . . . . . . . . . 164		21.12. Version Downgrade
	21.13. Targeted Attacks by Routing . . . . . . . . . . . . . . 164		21.13. Targeted Attacks by Routing
	21.14. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 164		21.14. Traffic Analysis
	22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164		22. IANA Considerations
	22.1. Registration Policies for QUIC Registries . . . . . . . 165		22.1. Registration Policies for QUIC Registries
	22.1.1. Provisional Registrations . . . . . . . . . . . . . 165		22.1.1. Provisional Registrations
	22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 166		22.1.2. Selecting Codepoints
	22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 166		22.1.3. Reclaiming Provisional Codepoints
	22.1.4. Permanent Registrations . . . . . . . . . . . . . . 167		22.1.4. Permanent Registrations
	22.2. QUIC Versions Registry . . . . . . . . . . . . . . . . . 167		22.2. QUIC Versions Registry
	22.3. QUIC Transport Parameters Registry . . . . . . . . . . . 168		22.3. QUIC Transport Parameters Registry
	22.4. QUIC Frame Types Registry . . . . . . . . . . . . . . . 170		22.4. QUIC Frame Types Registry
	22.5. QUIC Transport Error Codes Registry . . . . . . . . . . 170		22.5. QUIC Transport Error Codes Registry
			23. References
	23. References . . . . . . . . . . . . . . . . . . . . . . . . . 172		23.1. Normative References
	23.1. Normative References . . . . . . . . . . . . . . . . . . 172		23.2. Informative References
	23.2. Informative References . . . . . . . . . . . . . . . . . 174		Appendix A. Pseudocode
	Appendix A. Pseudocode . . . . . . . . . . . . . . . . . . . . . 177		A.1. Sample Variable-Length Integer Decoding
	A.1. Sample Variable-Length Integer Decoding . . . . . . . . . 177		A.2. Sample Packet Number Encoding Algorithm
	A.2. Sample Packet Number Encoding Algorithm . . . . . . . . . 178		A.3. Sample Packet Number Decoding Algorithm
	A.3. Sample Packet Number Decoding Algorithm . . . . . . . . . 179		A.4. Sample ECN Validation Algorithm
	A.4. Sample ECN Validation Algorithm . . . . . . . . . . . . . 180		Contributors
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 181		Authors' Addresses
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 184
	1. Overview		1. Overview
	QUIC is a secure general-purpose transport protocol. This document		QUIC is a secure general-purpose transport protocol. This document
	defines version 1 of QUIC, which conforms to the version-independent		defines version 1 of QUIC, which conforms to the version-independent
	properties of QUIC defined in [QUIC-INVARIANTS].		properties of QUIC defined in [QUIC-INVARIANTS].
	QUIC is a connection-oriented protocol that creates a stateful		QUIC is a connection-oriented protocol that creates a stateful
	interaction between a client and server.		interaction between a client and server.
	skipping to change at page 7, line 25 ¶		skipping to change at line 310 ¶
	termination. Applications can manage a graceful shutdown, endpoints		termination. Applications can manage a graceful shutdown, endpoints
	can negotiate a timeout period, errors can cause immediate connection		can negotiate a timeout period, errors can cause immediate connection
	teardown, and a stateless mechanism provides for termination of		teardown, and a stateless mechanism provides for termination of
	connections after one endpoint has lost state.		connections after one endpoint has lost state.
	1.1. Document Structure		1.1. Document Structure
	This document describes the core QUIC protocol and is structured as		This document describes the core QUIC protocol and is structured as
	follows:		follows:
	o Streams are the basic service abstraction that QUIC provides.		* Streams are the basic service abstraction that QUIC provides.
	* Section 2 describes core concepts related to streams,		- Section 2 describes core concepts related to streams,
	* Section 3 provides a reference model for stream states, and		- Section 3 provides a reference model for stream states, and
	* Section 4 outlines the operation of flow control.		- Section 4 outlines the operation of flow control.
	o Connections are the context in which QUIC endpoints communicate.		* Connections are the context in which QUIC endpoints communicate.
	* Section 5 describes core concepts related to connections,		- Section 5 describes core concepts related to connections,
	* Section 6 describes version negotiation,		- Section 6 describes version negotiation,
	* Section 7 details the process for establishing connections,		- Section 7 details the process for establishing connections,
	* Section 8 describes address validation and critical denial-of-		- Section 8 describes address validation and critical denial-of-
	service mitigations,		service mitigations,
	* Section 9 describes how endpoints migrate a connection to a new		- Section 9 describes how endpoints migrate a connection to a new
	network path,		network path,
	* Section 10 lists the options for terminating an open		- Section 10 lists the options for terminating an open
	connection, and		connection, and
	* Section 11 provides guidance for stream and connection error		- Section 11 provides guidance for stream and connection error
	handling.		handling.
	o Packets and frames are the basic unit used by QUIC to communicate.		* Packets and frames are the basic unit used by QUIC to communicate.
	* Section 12 describes concepts related to packets and frames,		- Section 12 describes concepts related to packets and frames,
	* Section 13 defines models for the transmission, retransmission,		- Section 13 defines models for the transmission, retransmission,
	and acknowledgment of data, and		and acknowledgment of data, and
	* Section 14 specifies rules for managing the size of datagrams		- Section 14 specifies rules for managing the size of datagrams
	carrying QUIC packets.		carrying QUIC packets.
	o Finally, encoding details of QUIC protocol elements are described		* Finally, encoding details of QUIC protocol elements are described
	in:		in:
	* Section 15 (versions),		- Section 15 (versions),
	* Section 16 (integer encoding),		- Section 16 (integer encoding),
	* Section 17 (packet headers),		- Section 17 (packet headers),
	* Section 18 (transport parameters),		- Section 18 (transport parameters),
	* Section 19 (frames), and		- Section 19 (frames), and
	* Section 20 (errors).		- Section 20 (errors).
	Accompanying documents describe QUIC's loss detection and congestion		Accompanying documents describe QUIC's loss detection and congestion
	control [QUIC-RECOVERY], and the use of TLS and other cryptographic		control [QUIC-RECOVERY], and the use of TLS and other cryptographic
	mechanisms [QUIC-TLS].		mechanisms [QUIC-TLS].
	This document defines QUIC version 1, which conforms to the protocol		This document defines QUIC version 1, which conforms to the protocol
	invariants in [QUIC-INVARIANTS].		invariants in [QUIC-INVARIANTS].
	To refer to QUIC version 1, cite this document. References to the		To refer to QUIC version 1, cite this document. References to the
	limited set of version-independent properties of QUIC can cite		limited set of version-independent properties of QUIC can cite
	skipping to change at page 11, line 17 ¶		skipping to change at line 483 ¶
	7-bit Field with Fixed Value (7) = 61,		7-bit Field with Fixed Value (7) = 61,
	Field with Variable-Length Integer (i),		Field with Variable-Length Integer (i),
	Arbitrary-Length Field (..),		Arbitrary-Length Field (..),
	Variable-Length Field (8..24),		Variable-Length Field (8..24),
	Field With Minimum Length (16..),		Field With Minimum Length (16..),
	Field With Maximum Length (..128),		Field With Maximum Length (..128),
	[Optional Field (64)],		[Optional Field (64)],
	Repeated Field (8) ...,		Repeated Field (8) ...,
	}		}
	Figure 1: Example Format		Figure 1: Example Format
	When a single-bit field is referenced in prose, the position of that		When a single-bit field is referenced in prose, the position of that
	field can be clarified by using the value of the byte that carries		field can be clarified by using the value of the byte that carries
	the field with the field's value set. For example, the value 0x80		the field with the field's value set. For example, the value 0x80
	could be used to refer to the single-bit field in the most		could be used to refer to the single-bit field in the most
	significant bit of the byte, such as One-bit Field in Figure 1.		significant bit of the byte, such as One-bit Field in Figure 1.
	2. Streams		2. Streams
	Streams in QUIC provide a lightweight, ordered byte-stream		Streams in QUIC provide a lightweight, ordered byte-stream
	skipping to change at page 12, line 25 ¶		skipping to change at line 539 ¶
	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 (0x02) of the stream ID		The second least significant bit (0x02) of the stream ID
	distinguishes between bidirectional streams (with the bit set to 0)		distinguishes between bidirectional streams (with the bit set to 0)
	and 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 |
	+------+----------------------------------+		+======+==================================+
	| 0x00 | Client-Initiated, Bidirectional |		| 0x00 | Client-Initiated, Bidirectional |
	| | |		+------+----------------------------------+
	| 0x01 | Server-Initiated, Bidirectional |		| 0x01 | Server-Initiated, Bidirectional |
	| | |		+------+----------------------------------+
	| 0x02 | Client-Initiated, Unidirectional |		| 0x02 | Client-Initiated, Unidirectional |
	| | |		+------+----------------------------------+
	| 0x03 | 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 (0x00		The stream space for each type begins at the minimum value (0x00
	through 0x03, 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.
	skipping to change at page 14, line 9 ¶		skipping to change at line 617 ¶
	This document does not define an API for QUIC; it instead defines a		This document does not define an API for QUIC; it instead defines a
	set of functions on streams that application protocols can rely upon.		set of functions on streams that application protocols can rely upon.
	An application protocol can assume that a QUIC implementation		An application protocol can assume that a QUIC implementation
	provides an interface that includes the operations described in this		provides an interface that includes the operations described in this
	section. An implementation designed for use with a specific		section. An implementation designed for use with a specific
	application protocol might provide only those operations that are		application protocol might provide only those operations that are
	used by that protocol.		used by that protocol.
	On the sending part of a stream, an application protocol can:		On the sending part of a stream, an application protocol can:
	o write data, understanding when stream flow control credit		* write data, understanding when stream flow control credit
	(Section 4.1) has successfully been reserved to send the written		(Section 4.1) has successfully been reserved to send the written
	data;		data;
	o end the stream (clean termination), resulting in a STREAM frame		* end the stream (clean termination), resulting in a STREAM frame
	(Section 19.8) with the FIN bit set; and		(Section 19.8) with the FIN bit set; and
	o reset the stream (abrupt termination), resulting in a RESET_STREAM		* reset the stream (abrupt termination), resulting in a RESET_STREAM
	frame (Section 19.4) if the stream was not already in a terminal		frame (Section 19.4) if the stream was not already in a terminal
	state.		state.
	On the receiving part of a stream, an application protocol can:		On the receiving part of a stream, an application protocol can:
	o read data; and		* read data; and
	o abort reading of the stream and request closure, possibly		* abort reading of the stream and request closure, possibly
	resulting in a STOP_SENDING frame (Section 19.5).		resulting in a STOP_SENDING frame (Section 19.5).
	An application protocol can also request to be informed of state		An application protocol can also request to be informed of state
	changes on streams, including when the peer has opened or reset a		changes on streams, including when the peer has opened or reset a
	stream, when a peer aborts reading on a stream, when new data is		stream, when a peer aborts reading on a stream, when new data is
	available, and when data can or cannot be written to the stream due		available, and when data can or cannot be written to the stream due
	to flow control.		to flow control.
	3. Stream States		3. Stream States
	skipping to change at page 15, line 11 ¶		skipping to change at line 667 ¶
	The state machines shown in this section are largely informative.		The state machines shown in this section are largely informative.
	This document uses stream states to describe rules for when and how		This document uses stream states to describe rules for when and how
	different types of frames can be sent and the reactions that are		different types of frames can be sent and the reactions that are
	expected when different types of frames are received. Though these		expected when different types of frames are received. Though these
	state machines are intended to be useful in implementing QUIC, these		state machines are intended to be useful in implementing QUIC, these
	states are not intended to constrain implementations. An		states are not intended to constrain implementations. An
	implementation can define a different state machine as long as its		implementation can define a different state machine as long as its
	behavior is consistent with an implementation that implements these		behavior is consistent with an implementation that implements these
	states.		states.
	Note: In some cases, a single event or action can cause a		| Note: In some cases, a single event or action can cause a
	transition through multiple states. For instance, sending STREAM		| transition through multiple states. For instance, sending
	with a FIN bit set can cause two state transitions for a sending		| STREAM with a FIN bit set can cause two state transitions for a
	stream: from the "Ready" state to the "Send" state, and from the		| sending stream: from the "Ready" state to the "Send" state, and
	"Send" state to the "Data Sent" state.		| from the "Send" state to the "Data Sent" state.
	3.1. Sending Stream States		3.1. Sending Stream States
	Figure 2 shows the states for the part of a stream that sends data to		Figure 2 shows the states for the part of a stream that sends data to
	a peer.		a peer.
	o		o
	| Create Stream (Sending)		| Create Stream (Sending)
	| Peer Creates Bidirectional Stream		| Peer Creates Bidirectional Stream
	v		v
	skipping to change at page 21, line 9 ¶		skipping to change at line 923 ¶
	receiving streams are in terminal states.		receiving streams are in terminal states.
	Table 2 shows a more complex mapping of bidirectional stream states		Table 2 shows a more complex mapping of bidirectional stream states
	that loosely correspond to the stream states defined in HTTP/2		that loosely correspond to the stream states defined in HTTP/2
	[HTTP2]. This shows that multiple states on sending or receiving		[HTTP2]. This shows that multiple states on sending or receiving
	parts of streams are mapped to the same composite state. Note that		parts of streams are mapped to the same composite state. Note that
	this is just one possibility for such a mapping; this mapping		this is just one possibility for such a mapping; this mapping
	requires that data be acknowledged before the transition to a		requires that data be acknowledged before the transition to a
	"closed" or "half-closed" state.		"closed" or "half-closed" state.
	+----------------------+-----------------------+--------------------+		+===================+=======================+=================+
	| Sending Part | Receiving Part | Composite State |		| Sending Part | Receiving Part | Composite State |
	+----------------------+-----------------------+--------------------+		+===================+=======================+=================+
	| No Stream / Ready | No Stream / Recv (*1) | idle |		| No Stream / Ready | No Stream / Recv (*1) | idle |
	| | | |		+-------------------+-----------------------+-----------------+
	| Ready / Send / Data | Recv / Size Known | open |		| Ready / Send / | Recv / Size Known | open |
	| Sent | | |		| Data Sent | | |
	| | | |		+-------------------+-----------------------+-----------------+
	| Ready / Send / Data | Data Recvd / Data | half-closed |		| Ready / Send / | Data Recvd / Data | half-closed |
	| Sent | Read | (remote) |		| Data Sent | Read | (remote) |
	| | | |		+-------------------+-----------------------+-----------------+
	| Ready / Send / Data | Reset Recvd / Reset | half-closed |		| Ready / Send / | Reset Recvd / Reset | half-closed |
	| Sent | Read | (remote) |		| Data Sent | Read | (remote) |
	| | | |		+-------------------+-----------------------+-----------------+
	| Data Recvd | Recv / Size Known | half-closed |		| Data Recvd | Recv / Size Known | half-closed |
	| | | (local) |		| | | (local) |
	| | | |		+-------------------+-----------------------+-----------------+
	| Reset Sent / Reset | Recv / Size Known | half-closed |		| Reset Sent / | Recv / Size Known | half-closed |
	| Recvd | | (local) |		| Reset Recvd | | (local) |
	| | | |		+-------------------+-----------------------+-----------------+
	| Reset Sent / Reset | Data Recvd / Data | closed |		| Reset Sent / | Data Recvd / Data | closed |
	| Recvd | Read | |		| Reset Recvd | Read | |
	| | | |		+-------------------+-----------------------+-----------------+
	| Reset Sent / Reset | Reset Recvd / Reset | closed |		| Reset Sent / | Reset Recvd / Reset | closed |
	| Recvd | Read | |		| Reset Recvd | Read | |
	| | | |		+-------------------+-----------------------+-----------------+
	| Data Recvd | Data Recvd / Data | closed |		| Data Recvd | Data Recvd / Data | closed |
	| | Read | |		| | Read | |
	| | | |		+-------------------+-----------------------+-----------------+
	| Data Recvd | Reset Recvd / Reset | closed |		| Data Recvd | Reset Recvd / Reset | closed |
	| | Read | |		| | Read | |
	+----------------------+-----------------------+--------------------+		+-------------------+-----------------------+-----------------+
	Table 2: Possible Mapping of Stream States to HTTP/2		Table 2: Possible Mapping of Stream States to HTTP/2
	Note (*1): A stream is considered "idle" if it has not yet been		| Note (*1): A stream is considered "idle" if it has not yet been
	created or if the receiving part of the stream is in the "Recv"		| created or if the receiving part of the stream is in the "Recv"
	state without yet having received any frames.		| state without yet having received any frames.
	3.5. Solicited State Transitions		3.5. Solicited State Transitions
	If an application is no longer interested in the data it is receiving		If an application is no longer interested in the data it is receiving
	on a stream, it can abort reading the stream and specify an		on a stream, it can abort reading the stream and specify an
	application error code.		application error code.
	If the stream is in the "Recv" or "Size Known" state, the transport		If the stream is in the "Recv" or "Size Known" state, the transport
	SHOULD signal this by sending a STOP_SENDING frame to prompt closure		SHOULD signal this by sending a STOP_SENDING frame to prompt closure
	of the stream in the opposite direction. This typically indicates		of the stream in the opposite direction. This typically indicates
	skipping to change at page 23, line 34 ¶		skipping to change at line 1038 ¶
	SHOULD provide an interface for the cryptographic protocol		SHOULD provide an interface for the cryptographic protocol
	implementation to communicate its buffering limits.		implementation to communicate its buffering limits.
	4.1. Data Flow Control		4.1. Data Flow Control
	QUIC employs a limit-based flow control scheme where a receiver		QUIC employs a limit-based flow control scheme where a receiver
	advertises the limit of total bytes it is prepared to receive on a		advertises the limit of total bytes it is prepared to receive on a
	given stream or for the entire connection. This leads to two levels		given stream or for the entire connection. This leads to two levels
	of data flow control in QUIC:		of data flow control in QUIC:
	o Stream flow control, which prevents a single stream from consuming		* Stream flow control, which prevents a single stream from consuming
	the entire receive buffer for a connection by limiting the amount		the entire receive buffer for a connection by limiting the amount
	of data that can be sent on each stream.		of data that can be sent on each stream.
	o Connection flow control, which prevents senders from exceeding a		* Connection flow control, which prevents senders from exceeding a
	receiver's buffer capacity for the connection by limiting the		receiver's buffer capacity for the connection by limiting the
	total bytes of stream data sent in STREAM frames on all streams.		total bytes of stream data sent in STREAM frames on all streams.
	Senders MUST NOT send data in excess of either limit.		Senders MUST NOT send data in excess of either limit.
	A receiver sets initial limits for all streams through transport		A receiver sets initial limits for all streams through transport
	parameters during the handshake (Section 7.4). Subsequently, a		parameters during the handshake (Section 7.4). Subsequently, a
	receiver sends MAX_STREAM_DATA frames (Section 19.10) or MAX_DATA		receiver sends MAX_STREAM_DATA frames (Section 19.10) or MAX_DATA
	frames (Section 19.9) to the sender to advertise larger limits.		frames (Section 19.9) to the sender to advertise larger limits.
	skipping to change at page 28, line 10 ¶		skipping to change at line 1251 ¶
	A QUIC connection is shared state between a client and a server.		A QUIC connection is shared state between a client and a server.
	Each connection starts with a handshake phase, during which the two		Each connection starts with a handshake phase, during which the two
	endpoints establish a shared secret using the cryptographic handshake		endpoints establish a shared secret using the cryptographic handshake
	protocol [QUIC-TLS] and negotiate the application protocol. The		protocol [QUIC-TLS] and negotiate the application protocol. The
	handshake (Section 7) confirms that both endpoints are willing to		handshake (Section 7) confirms that both endpoints are willing to
	communicate (Section 8.1) and establishes parameters for the		communicate (Section 8.1) and establishes parameters for the
	connection (Section 7.4).		connection (Section 7.4).
	An application protocol can use the connection during the handshake		An application protocol can use the connection during the handshake
	phase with some limitations. 0-RTT allows application data to be sent		phase with some limitations. 0-RTT allows application data to be
	by a client before receiving a response from the server. However,		sent by a client before receiving a response from the server.
	0-RTT provides no protection against replay attacks; see Section 9.2		However, 0-RTT provides no protection against replay attacks; see
	of [QUIC-TLS]. A server can also send application data to a client		Section 9.2 of [QUIC-TLS]. A server can also send application data
	before it receives the final cryptographic handshake messages that		to a client before it receives the final cryptographic handshake
	allow it to confirm the identity and liveness of the client. These		messages that allow it to confirm the identity and liveness of the
	capabilities allow an application protocol to offer the option of		client. These capabilities allow an application protocol to offer
	trading some security guarantees for reduced latency.		the option of trading some security guarantees for reduced latency.
	The use of connection IDs (Section 5.1) allows connections to migrate		The use of connection IDs (Section 5.1) allows connections to migrate
	to a new network path, both as a direct choice of an endpoint and		to a new network path, both as a direct choice of an endpoint and
	when forced by a change in a middlebox. Section 9 describes		when forced by a change in a middlebox. Section 9 describes
	mitigations for the security and privacy issues associated with		mitigations for the security and privacy issues associated with
	migration.		migration.
	For connections that are no longer needed or desired, there are		For connections that are no longer needed or desired, there are
	several ways for a client and server to terminate a connection, as		several ways for a client and server to terminate a connection, as
	described in Section 10.		described in Section 10.
	skipping to change at page 34, line 26 ¶		skipping to change at line 1550 ¶
	5.2.3. Considerations for Simple Load Balancers		5.2.3. Considerations for Simple Load Balancers
	A server deployment could load-balance among servers using only		A server deployment could load-balance among servers using only
	source and destination IP addresses and ports. Changes to the		source and destination IP addresses and ports. Changes to the
	client's IP address or port could result in packets being forwarded		client's IP address or port could result in packets being forwarded
	to the wrong server. Such a server deployment could use one of the		to the wrong server. Such a server deployment could use one of the
	following methods for connection continuity when a client's address		following methods for connection continuity when a client's address
	changes.		changes.
	o Servers could use an out-of-band mechanism to forward packets to		* Servers could use an out-of-band mechanism to forward packets to
	the correct server based on connection ID.		the correct server based on connection ID.
	o If servers can use a dedicated server IP address or port, other		* If servers can use a dedicated server IP address or port, other
	than the one that the client initially connects to, they could use		than the one that the client initially connects to, they could use
	the preferred_address transport parameter to request that clients		the preferred_address transport parameter to request that clients
	move connections to that dedicated address. Note that clients		move connections to that dedicated address. Note that clients
	could choose not to use the preferred address.		could choose not to use the preferred address.
	A server in a deployment that does not implement a solution to		A server in a deployment that does not implement a solution to
	maintain connection continuity when the client address changes SHOULD		maintain connection continuity when the client address changes SHOULD
	indicate that migration is not supported by using the		indicate that migration is not supported by using the
	disable_active_migration transport parameter. The		disable_active_migration transport parameter. The
	disable_active_migration transport parameter does not prohibit		disable_active_migration transport parameter does not prohibit
	skipping to change at page 35, line 9 ¶		skipping to change at line 1582 ¶
	This document does not define an API for QUIC; it instead defines a		This document does not define an API for QUIC; it instead defines a
	set of functions for QUIC connections that application protocols can		set of functions for QUIC connections that application protocols can
	rely upon. An application protocol can assume that an implementation		rely upon. An application protocol can assume that an implementation
	of QUIC provides an interface that includes the operations described		of QUIC provides an interface that includes the operations described
	in this section. An implementation designed for use with a specific		in this section. An implementation designed for use with a specific
	application protocol might provide only those operations that are		application protocol might provide only those operations that are
	used by that protocol.		used by that protocol.
	When implementing the client role, an application protocol can:		When implementing the client role, an application protocol can:
	o open a connection, which begins the exchange described in		* open a connection, which begins the exchange described in
	Section 7;		Section 7;
	o enable Early Data when available; and		* enable Early Data when available; and
	o be informed when Early Data has been accepted or rejected by a		* be informed when Early Data has been accepted or rejected by a
	server.		server.
	When implementing the server role, an application protocol can:		When implementing the server role, an application protocol can:
	o listen for incoming connections, which prepares for the exchange		* listen for incoming connections, which prepares for the exchange
	described in Section 7;		described in Section 7;
	o if Early Data is supported, embed application-controlled data in		* if Early Data is supported, embed application-controlled data in
	the TLS resumption ticket sent to the client; and		the TLS resumption ticket sent to the client; and
	o if Early Data is supported, retrieve application-controlled data		* if Early Data is supported, retrieve application-controlled data
	from the client's resumption ticket and accept or reject Early		from the client's resumption ticket and accept or reject Early
	Data based on that information.		Data based on that information.
	In either role, an application protocol can:		In either role, an application protocol can:
	o configure minimum values for the initial number of permitted		* configure minimum values for the initial number of permitted
	streams of each type, as communicated in the transport parameters		streams of each type, as communicated in the transport parameters
	(Section 7.4);		(Section 7.4);
	o control resource allocation for receive buffers by setting flow		* control resource allocation for receive buffers by setting flow
	control limits both for streams and for the connection;		control limits both for streams and for the connection;
	o identify whether the handshake has completed successfully or is		* identify whether the handshake has completed successfully or is
	still ongoing;		still ongoing;
	o keep a connection from silently closing, by either generating PING		* keep a connection from silently closing, by either generating PING
	frames (Section 19.2) or requesting that the transport send		frames (Section 19.2) or requesting that the transport send
	additional frames before the idle timeout expires (Section 10.1);		additional frames before the idle timeout expires (Section 10.1);
	and		and
	o immediately close (Section 10.2) the connection.		* immediately close (Section 10.2) the connection.
	6. Version Negotiation		6. Version Negotiation
	Version negotiation allows a server to indicate that it does not		Version negotiation allows a server to indicate that it does not
	support the version the client used. A server sends a Version		support the version the client used. A server sends a Version
	Negotiation packet in response to each packet that might initiate a		Negotiation packet in response to each packet that might initiate a
	new connection; see Section 5.2 for details.		new connection; see Section 5.2 for details.
	The size of the first packet sent by a client will determine whether		The size of the first packet sent by a client will determine whether
	a server sends a Version Negotiation packet. Clients that support		a server sends a Version Negotiation packet. Clients that support
	skipping to change at page 37, line 44 ¶		skipping to change at line 1709 ¶
	version of QUIC defined in this document is identified as 0x00000001		version of QUIC defined in this document is identified as 0x00000001
	and uses TLS as described in [QUIC-TLS]; a different QUIC version		and uses TLS as described in [QUIC-TLS]; a different QUIC version
	could indicate that a different cryptographic handshake protocol is		could indicate that a different cryptographic handshake protocol is
	in use.		in use.
	QUIC provides reliable, ordered delivery of the cryptographic		QUIC provides reliable, ordered delivery of the cryptographic
	handshake data. QUIC packet protection is used to encrypt as much of		handshake data. QUIC packet protection is used to encrypt as much of
	the handshake protocol as possible. The cryptographic handshake MUST		the handshake protocol as possible. The cryptographic handshake MUST
	provide the following properties:		provide the following properties:
	o authenticated key exchange, where		* authenticated key exchange, where
	* a server is always authenticated,		- a server is always authenticated,
	* a client is optionally authenticated,		- a client is optionally authenticated,
	* every connection produces distinct and unrelated keys, and		- every connection produces distinct and unrelated keys, and
	* keying material is usable for packet protection for both 0-RTT
			- keying material is usable for packet protection for both 0-RTT
	and 1-RTT packets.		and 1-RTT packets.
	o authenticated exchange of values for transport parameters of both		* authenticated exchange of values for transport parameters of both
	endpoints, and confidentiality protection for server transport		endpoints, and confidentiality protection for server transport
	parameters (see Section 7.4).		parameters (see Section 7.4).
	o authenticated negotiation of an application protocol (TLS uses		* authenticated negotiation of an application protocol (TLS uses
	Application-Layer Protocol Negotiation (ALPN) [ALPN] for this		Application-Layer Protocol Negotiation (ALPN) [ALPN] for this
	purpose).		purpose).
	The CRYPTO frame can be sent in different packet number spaces		The CRYPTO frame can be sent in different packet number spaces
	(Section 12.3). The offsets used by CRYPTO frames to ensure ordered		(Section 12.3). The offsets used by CRYPTO frames to ensure ordered
	delivery of cryptographic handshake data start from zero in each		delivery of cryptographic handshake data start from zero in each
	packet number space.		packet number space.
	Figure 4 shows a simplified handshake and the exchange of packets and		Figure 4 shows a simplified handshake and the exchange of packets and
	frames that are used to advance the handshake. Exchange of		frames that are used to advance the handshake. Exchange of
	skipping to change at page 42, line 28 ¶		skipping to change at line 1934 ¶
	An endpoint MUST treat the absence of the		An endpoint MUST treat the absence of the
	initial_source_connection_id transport parameter from either endpoint		initial_source_connection_id transport parameter from either endpoint
	or the absence of the original_destination_connection_id transport		or the absence of the original_destination_connection_id transport
	parameter from the server as a connection error of type		parameter from the server as a connection error of type
	TRANSPORT_PARAMETER_ERROR.		TRANSPORT_PARAMETER_ERROR.
	An endpoint MUST treat the following as a connection error of type		An endpoint MUST treat the following as a connection error of type
	TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:		TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:
	o absence of the retry_source_connection_id transport parameter from		* absence of the retry_source_connection_id transport parameter from
	the server after receiving a Retry packet,		the server after receiving a Retry packet,
	o presence of the retry_source_connection_id transport parameter		* presence of the retry_source_connection_id transport parameter
	when no Retry packet was received, or		when no Retry packet was received, or
	o a mismatch between values received from a peer in these transport		* a mismatch between values received from a peer in these transport
	parameters and the value sent in the corresponding Destination or		parameters and the value sent in the corresponding Destination or
	Source Connection ID fields of Initial packets.		Source Connection ID fields of Initial packets.
	If a zero-length connection ID is selected, the corresponding		If a zero-length connection ID is selected, the corresponding
	transport parameter is included with a zero-length value.		transport parameter is included with a zero-length value.
	Figure 7 shows the connection IDs (with DCID=Destination Connection		Figure 7 shows the connection IDs (with DCID=Destination Connection
	ID, SCID=Source Connection ID) that are used in a complete handshake.		ID, SCID=Source Connection ID) that are used in a complete handshake.
	The exchange of Initial packets is shown, plus the later exchange of		The exchange of Initial packets is shown, plus the later exchange of
	1-RTT packets that includes the connection ID established during the		1-RTT packets that includes the connection ID established during the
	handshake.		handshake.
	Client Server		Client Server
	Initial: DCID=S1, SCID=C1 ->		Initial: DCID=S1, SCID=C1 ->
	<- Initial: DCID=C1, SCID=S3		<- Initial: DCID=C1, SCID=S3
	...		...
	1-RTT: DCID=S3 ->		1-RTT: DCID=S3 ->
	<- 1-RTT: DCID=C1		<- 1-RTT: DCID=C1
	Figure 7: Use of Connection IDs in a Handshake		Figure 7: Use of Connection IDs in a Handshake
	Figure 8 shows a similar handshake that includes a Retry packet.		Figure 8 shows a similar handshake that includes a Retry packet.
	Client Server		Client Server
	Initial: DCID=S1, SCID=C1 ->		Initial: DCID=S1, SCID=C1 ->
	<- Retry: DCID=C1, SCID=S2		<- Retry: DCID=C1, SCID=S2
	Initial: DCID=S2, SCID=C1 ->		Initial: DCID=S2, SCID=C1 ->
	<- Initial: DCID=C1, SCID=S3		<- Initial: DCID=C1, SCID=S3
	...		...
	skipping to change at page 45, line 32 ¶		skipping to change at line 2077 ¶
	integrity-protected copy of the values in the ticket and recover the		integrity-protected copy of the values in the ticket and recover the
	information when accepting 0-RTT data. A server uses the transport		information when accepting 0-RTT data. A server uses the transport
	parameters in determining whether to accept 0-RTT data.		parameters in determining whether to accept 0-RTT data.
	If 0-RTT data is accepted by the server, the server MUST NOT reduce		If 0-RTT data is accepted by the server, the server MUST NOT reduce
	any limits or alter any values that might be violated by the client		any limits or alter any values that might be violated by the client
	with its 0-RTT data. In particular, a server that accepts 0-RTT data		with its 0-RTT data. In particular, a server that accepts 0-RTT data
	MUST NOT set values for the following parameters (Section 18.2) that		MUST NOT set values for the following parameters (Section 18.2) that
	are smaller than the remembered values of the parameters.		are smaller than the remembered values of the parameters.
	o active_connection_id_limit		* active_connection_id_limit
	o initial_max_data		* initial_max_data
	o initial_max_stream_data_bidi_local		* initial_max_stream_data_bidi_local
	o initial_max_stream_data_bidi_remote		* initial_max_stream_data_bidi_remote
	o initial_max_stream_data_uni		* initial_max_stream_data_uni
	o initial_max_streams_bidi		* initial_max_streams_bidi
	o initial_max_streams_uni		* 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 the sending of application		subset of transport parameters that permit the 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 (1) initial_max_streams_bidi and		initial_max_data and either (1) initial_max_streams_bidi and
	initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni		initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni
	and initial_max_stream_data_uni.		and initial_max_stream_data_uni.
	A server might provide larger initial stream flow control limits for		A server might provide larger initial stream flow control limits for
	skipping to change at page 50, line 31 ¶		skipping to change at line 2315 ¶
	Initial[0]: CRYPTO[CH] ->		Initial[0]: CRYPTO[CH] ->
	<- Retry+Token		<- Retry+Token
	Initial+Token[1]: CRYPTO[CH] ->		Initial+Token[1]: CRYPTO[CH] ->
	Initial[0]: CRYPTO[SH] ACK[1]		Initial[0]: CRYPTO[SH] ACK[1]
	Handshake[0]: CRYPTO[EE, CERT, CV, FIN]		Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
	<- 1-RTT[0]: STREAM[1, "..."]		<- 1-RTT[0]: STREAM[1, "..."]
	Figure 9: Example Handshake with Retry		Figure 9: Example Handshake with Retry
	8.1.3. Address Validation for Future Connections		8.1.3. Address Validation for Future Connections
	A server MAY provide clients with an address validation token during		A server MAY provide clients with an address validation token during
	one connection that can be used on a subsequent connection. Address		one connection that can be used on a subsequent connection. Address
	validation is especially important with 0-RTT because a server		validation is especially important with 0-RTT because a server
	potentially sends a significant amount of data to a client in		potentially sends a significant amount of data to a client in
	response to 0-RTT data.		response to 0-RTT data.
	The server uses the NEW_TOKEN frame (Section 19.7) to provide the		The server uses the NEW_TOKEN frame (Section 19.7) to provide the
	skipping to change at page 52, line 21 ¶		skipping to change at line 2401 ¶
	When a server receives an Initial packet with an address validation		When a server receives an Initial packet with an address validation
	token, it MUST attempt to validate the token, unless it has already		token, it MUST attempt to validate the token, unless it has already
	completed address validation. If the token is invalid, then the		completed address validation. If the token is invalid, then the
	server SHOULD proceed as if the client did not have a validated		server SHOULD proceed as if the client did not have a validated
	address, including potentially sending a Retry packet. Tokens		address, including potentially sending a Retry packet. Tokens
	provided with NEW_TOKEN frames and Retry packets can be distinguished		provided with NEW_TOKEN frames and Retry packets can be distinguished
	by servers (see Section 8.1.1), and the latter can be validated more		by servers (see Section 8.1.1), and the latter can be validated more
	strictly. If the validation succeeds, the server SHOULD then allow		strictly. If the validation succeeds, the server SHOULD then allow
	the handshake to proceed.		the handshake to proceed.
	Note: The rationale for treating the client as unvalidated rather		| Note: The rationale for treating the client as unvalidated
	than discarding the packet is that the client might have received		| rather than discarding the packet is that the client might have
	the token in a previous connection using the NEW_TOKEN frame, and		| received the token in a previous connection using the NEW_TOKEN
	if the server has lost state, it might be unable to validate the		| frame, and if the server has lost state, it might be unable to
	token at all, leading to connection failure if the packet is		| validate the token at all, leading to connection failure if the
	discarded.		| packet is discarded.
	In a stateless design, a server can use encrypted and authenticated		In a stateless design, a server can use encrypted and authenticated
	tokens to pass information to clients that the server can later		tokens to pass information to clients that the server can later
	recover and use to validate a client address. Tokens are not		recover and use to validate a client address. Tokens are not
	integrated into the cryptographic handshake, and so they are not		integrated into the cryptographic handshake, and so they are not
	authenticated. For instance, a client might be able to reuse a		authenticated. For instance, a client might be able to reuse a
	token. To avoid attacks that exploit this property, a server can		token. To avoid attacks that exploit this property, a server can
	limit its use of tokens to only the information needed to validate		limit its use of tokens to only the information needed to validate
	client addresses.		client addresses.
	skipping to change at page 66, line 37 ¶		skipping to change at line 3085 ¶
	labels ensures that changes are synchronized with changes in other		labels ensures that changes are synchronized with changes in other
	observable identifiers. A cryptographic hash function that combines		observable identifiers. A cryptographic hash function that combines
	these inputs with a local secret is one way this might be		these inputs with a local secret is one way this might be
	implemented.		implemented.
	10. Connection Termination		10. Connection Termination
	An established QUIC connection can be terminated in one of three		An established QUIC connection can be terminated in one of three
	ways:		ways:
	o idle timeout (Section 10.1)		* idle timeout (Section 10.1)
	o immediate close (Section 10.2)		* immediate close (Section 10.2)
	o stateless reset (Section 10.3)		* stateless reset (Section 10.3)
	An endpoint MAY discard connection state if it does not have a		An endpoint MAY discard connection state if it does not have a
	validated path on which it can send packets; see Section 8.2.		validated path on which it can send packets; see Section 8.2.
	10.1. Idle Timeout		10.1. Idle Timeout
	If a max_idle_timeout is specified by either endpoint in its		If a max_idle_timeout is specified by either endpoint in its
	transport parameters (Section 18.2), the connection is silently		transport parameters (Section 18.2), the connection is silently
	closed and its state is discarded when it remains idle for longer		closed and its state is discarded when it remains idle for longer
	than the minimum of the max_idle_timeout value advertised by both		than the minimum of the max_idle_timeout value advertised by both
	skipping to change at page 69, line 49 ¶		skipping to change at line 3242 ¶
	state and send a packet containing a CONNECTION_CLOSE frame in		state and send a packet containing a CONNECTION_CLOSE frame in
	response to any UDP datagram that is received. However, an endpoint		response to any UDP datagram that is received. However, an endpoint
	that discards packet protection keys cannot identify and discard		that discards packet protection keys cannot identify and discard
	invalid packets. To avoid being used for an amplification attack,		invalid packets. To avoid being used for an amplification attack,
	such endpoints MUST limit the cumulative size of packets it sends to		such endpoints MUST limit the cumulative size of packets it sends to
	three times the cumulative size of the packets that are received and		three times the cumulative size of the packets that are received and
	attributed to the connection. To minimize the state that an endpoint		attributed to the connection. To minimize the state that an endpoint
	maintains for a closing connection, endpoints MAY send the exact same		maintains for a closing connection, endpoints MAY send the exact same
	packet in response to any received packet.		packet in response to any received packet.
	Note: Allowing retransmission of a closing packet is an exception		| Note: Allowing retransmission of a closing packet is an
	to the requirement that a new packet number be used for each		| exception to the requirement that a new packet number be used
	packet; see Section 12.3. Sending new packet numbers is primarily		| for each packet; see Section 12.3. Sending new packet numbers
	of advantage to loss recovery and congestion control, which are		| is primarily of advantage to loss recovery and congestion
	not expected to be relevant for a closed connection.		| control, which are not expected to be relevant for a closed
	Retransmitting the final packet requires less state.		| connection. Retransmitting the final packet requires less
			| state.
	While in the closing state, an endpoint could receive packets from a		While in the closing state, an endpoint could receive packets from a
	new source address, possibly indicating a connection migration; see		new source address, possibly indicating a connection migration; see
	Section 9. An endpoint in the closing state MUST either discard		Section 9. An endpoint in the closing state MUST either discard
	packets received from an unvalidated address or limit the cumulative		packets received from an unvalidated address or limit the cumulative
	size of packets it sends to an unvalidated address to three times the		size of packets it sends to an unvalidated address to three times the
	size of packets it receives from that address.		size of packets it receives from that address.
	An endpoint is not expected to handle key updates when it is closing		An endpoint is not expected to handle key updates when it is closing
	(Section 6 of [QUIC-TLS]). A key update might prevent the endpoint		(Section 6 of [QUIC-TLS]). A key update might prevent the endpoint
	skipping to change at page 71, line 9 ¶		skipping to change at line 3299 ¶
	peer will process the frame. Generally, this means sending the frame		peer will process the frame. Generally, this means sending the frame
	in a packet with the highest level of packet protection to avoid the		in a packet with the highest level of packet protection to avoid the
	packet being discarded. After the handshake is confirmed (see		packet being discarded. After the handshake is confirmed (see
	Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any		Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any
	CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to		CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to
	confirming the handshake, it is possible that more advanced packet		confirming the handshake, it is possible that more advanced packet
	protection keys are not available to the peer, so another		protection keys are not available to the peer, so another
	CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower		CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower
	packet protection level. More specifically:		packet protection level. More specifically:
	o A client will always know whether the server has Handshake keys		* A client will always know whether the server has Handshake keys
	(see Section 17.2.2.1), but it is possible that a server does not		(see Section 17.2.2.1), but it is possible that a server does not
	know whether the client has Handshake keys. Under these		know whether the client has Handshake keys. Under these
	circumstances, a server SHOULD send a CONNECTION_CLOSE frame in		circumstances, a server SHOULD send a CONNECTION_CLOSE frame in
	both Handshake and Initial packets to ensure that at least one of		both Handshake and Initial packets to ensure that at least one of
	them is processable by the client.		them is processable by the client.
	o A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet		* A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet
	cannot be assured that the server has accepted 0-RTT. Sending a		cannot be assured that the server has accepted 0-RTT. Sending a
	CONNECTION_CLOSE frame in an Initial packet makes it more likely		CONNECTION_CLOSE frame in an Initial packet makes it more likely
	that the server can receive the close signal, even if the		that the server can receive the close signal, even if the
	application error code might not be received.		application error code might not be received.
	o Prior to confirming the handshake, a peer might be unable to		* Prior to confirming the handshake, a peer might be unable to
	process 1-RTT packets, so an endpoint SHOULD send a		process 1-RTT packets, so an endpoint SHOULD send a
	CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. A		CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. A
	server SHOULD also send a CONNECTION_CLOSE frame in an Initial		server SHOULD also send a CONNECTION_CLOSE frame in an Initial
	packet.		packet.
	Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake		Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake
	packet could expose application state or be used to alter application		packet could expose application state or be used to alter application
	state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a		state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a
	CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or		CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or
	Handshake packets. Otherwise, information about the application		Handshake packets. Otherwise, information about the application
	skipping to change at page 72, line 52 ¶		skipping to change at line 3389 ¶
	An endpoint that receives packets that it cannot process sends a		An endpoint that receives packets that it cannot process sends a
	packet in the following layout (see Section 1.3):		packet in the following layout (see Section 1.3):
	Stateless Reset {		Stateless Reset {
	Fixed Bits (2) = 1,		Fixed Bits (2) = 1,
	Unpredictable Bits (38..),		Unpredictable Bits (38..),
	Stateless Reset Token (128),		Stateless Reset Token (128),
	}		}
	Figure 10: Stateless Reset		Figure 10: Stateless Reset
	This design ensures that a Stateless Reset is -- to the extent		This design ensures that a Stateless Reset is -- to the extent
	possible -- indistinguishable from a regular packet with a short		possible -- indistinguishable from a regular packet with a short
	header.		header.
	A Stateless Reset uses an entire UDP datagram, starting with the		A Stateless Reset uses an entire UDP datagram, starting with the
	first two bits of the packet header. The remainder of the first byte		first two bits of the packet header. The remainder of the first byte
	and an arbitrary number of bytes following it are set to values that		and an arbitrary number of bytes following it are set to values that
	SHOULD be indistinguishable from random. The last 16 bytes of the		SHOULD be indistinguishable from random. The last 16 bytes of the
	datagram contain a stateless reset token.		datagram contain a stateless reset token.
	skipping to change at page 74, line 24 ¶		skipping to change at line 3459 ¶
	An endpoint cannot determine the Source Connection ID from a packet		An endpoint cannot determine the Source Connection ID from a packet
	with a short header; therefore, it cannot set the Destination		with a short header; therefore, it cannot set the Destination
	Connection ID in the Stateless Reset. The Destination Connection ID		Connection ID in the Stateless Reset. The Destination Connection ID
	will therefore differ from the value used in previous packets. A		will therefore differ from the value used in previous packets. A
	random Destination Connection ID makes the connection ID appear to be		random Destination Connection ID makes the connection ID appear to be
	the result of moving to a new connection ID that was provided using a		the result of moving to a new connection ID that was provided using a
	NEW_CONNECTION_ID frame; see Section 19.15.		NEW_CONNECTION_ID frame; see Section 19.15.
	Using a randomized connection ID results in two problems:		Using a randomized connection ID results in two problems:
	o The packet might not reach the peer. If the Destination		* The packet might not reach the peer. If the Destination
	Connection ID is critical for routing toward the peer, then this		Connection ID is critical for routing toward the peer, then this
	packet could be incorrectly routed. This might also trigger		packet could be incorrectly routed. This might also trigger
	another Stateless Reset in response; see Section 10.3.3. A		another Stateless Reset in response; see Section 10.3.3. A
	Stateless Reset that is not correctly routed is an ineffective		Stateless Reset that is not correctly routed is an ineffective
	error detection and recovery mechanism. In this case, endpoints		error detection and recovery mechanism. In this case, endpoints
	will need to rely on other methods -- such as timers -- to detect		will need to rely on other methods -- such as timers -- to detect
	that the connection has failed.		that the connection has failed.
	o The randomly generated connection ID can be used by entities other		* The randomly generated connection ID can be used by entities other
	than the peer to identify this as a potential Stateless Reset. An		than the peer to identify this as a potential Stateless Reset. An
	endpoint that occasionally uses different connection IDs might		endpoint that occasionally uses different connection IDs might
	introduce some uncertainty about this.		introduce some uncertainty about this.
	This stateless reset design is specific to QUIC version 1. An		This stateless reset design is specific to QUIC version 1. An
	endpoint that supports multiple versions of QUIC needs to generate a		endpoint that supports multiple versions of QUIC needs to generate a
	Stateless Reset that will be accepted by peers that support any		Stateless Reset that will be accepted by peers that support any
	version that the endpoint might support (or might have supported		version that the endpoint might support (or might have supported
	prior to losing state). Designers of new versions of QUIC need to be		prior to losing state). Designers of new versions of QUIC need to be
	aware of this and either (1) reuse this design or (2) use a portion		aware of this and either (1) reuse this design or (2) use a portion
	skipping to change at page 84, line 5 ¶		skipping to change at line 3881 ¶
	Frame Type (i),		Frame Type (i),
	Type-Dependent Fields (..),		Type-Dependent Fields (..),
	}		}
	Figure 12: Generic Frame Layout		Figure 12: Generic Frame Layout
	Table 3 lists and summarizes information about each frame type that		Table 3 lists and summarizes information about each frame type that
	is defined in this specification. A description of this summary is		is defined in this specification. A description of this summary is
	included after the table.		included after the table.
	+------------+----------------------+----------------+------+------+		+============+======================+===============+======+======+
	| Type Value | Frame Type Name | Definition | Pkts | Spec |		| Type Value | Frame Type Name | Definition | Pkts | Spec |
	+------------+----------------------+----------------+------+------+		+============+======================+===============+======+======+
	| 0x00 | PADDING | Section 19.1 | IH01 | NP |		| 0x00 | PADDING | Section 19.1 | IH01 | NP |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x01 | PING | Section 19.2 | IH01 | |		| 0x01 | PING | Section 19.2 | IH01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x02-0x03 | ACK | Section 19.3 | IH_1 | NC |		| 0x02-0x03 | ACK | Section 19.3 | IH_1 | NC |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x04 | RESET_STREAM | Section 19.4 | __01 | |		| 0x04 | RESET_STREAM | Section 19.4 | __01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x05 | STOP_SENDING | Section 19.5 | __01 | |		| 0x05 | STOP_SENDING | Section 19.5 | __01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x06 | CRYPTO | Section 19.6 | IH_1 | |		| 0x06 | CRYPTO | Section 19.6 | IH_1 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x07 | NEW_TOKEN | Section 19.7 | ___1 | |		| 0x07 | NEW_TOKEN | Section 19.7 | ___1 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x08-0x0f | STREAM | Section 19.8 | __01 | F |		| 0x08-0x0f | STREAM | Section 19.8 | __01 | F |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x10 | MAX_DATA | Section 19.9 | __01 | |		| 0x10 | MAX_DATA | Section 19.9 | __01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | |		| 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x12-0x13 | MAX_STREAMS | Section 19.11 | __01 | |		| 0x12-0x13 | MAX_STREAMS | Section 19.11 | __01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x14 | DATA_BLOCKED | Section 19.12 | __01 | |		| 0x14 | DATA_BLOCKED | Section 19.12 | __01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | |		| 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x16-0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | |		| 0x16-0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P |		| 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | |		| 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P |		| 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P |		| 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x1c-0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N |		| 0x1c-0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N |
	| | | | | |		+------------+----------------------+---------------+------+------+
	| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | |		| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | |
	+------------+----------------------+----------------+------+------+		+------------+----------------------+---------------+------+------+
	Table 3: Frame Types		Table 3: Frame Types
	The format and semantics of each frame type are explained in more		The format and semantics of each frame type are explained in more
	detail in Section 19. The remainder of this section provides a		detail in Section 19. The remainder of this section provides a
	summary of important and general information.		summary of important and general information.
	The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and		The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and
	CONNECTION_CLOSE frames is used to carry other frame-specific flags.		CONNECTION_CLOSE frames is used to carry other frame-specific flags.
	For all other frames, the Frame Type field simply identifies the		For all other frames, the Frame Type field simply identifies the
	frame.		frame.
	skipping to change at page 86, line 33 ¶		skipping to change at line 4004 ¶
	a connection error of type PROTOCOL_VIOLATION.		a connection error of type PROTOCOL_VIOLATION.
	12.5. Frames and Number Spaces		12.5. Frames and Number Spaces
	Some frames are prohibited in different packet number spaces. The		Some frames are prohibited in different packet number spaces. The
	rules here generalize those of TLS, in that frames associated with		rules here generalize those of TLS, in that frames associated with
	establishing the connection can usually appear in packets in any		establishing the connection can usually appear in packets in any
	packet number space, whereas those associated with transferring data		packet number space, whereas those associated with transferring data
	can only appear in the application data packet number space:		can only appear in the application data packet number space:
	o PADDING, PING, and CRYPTO frames MAY appear in any packet number		* PADDING, PING, and CRYPTO frames MAY appear in any packet number
	space.		space.
	o CONNECTION_CLOSE frames signaling errors at the QUIC layer (type		* CONNECTION_CLOSE frames signaling errors at the QUIC layer (type
	0x1c) MAY appear in any packet number space. CONNECTION_CLOSE		0x1c) MAY appear in any packet number space. CONNECTION_CLOSE
	frames signaling application errors (type 0x1d) MUST only appear		frames signaling application errors (type 0x1d) MUST only appear
	in the application data packet number space.		in the application data packet number space.
	o ACK frames MAY appear in any packet number space but can only		* ACK frames MAY appear in any packet number space but can only
	acknowledge packets that appeared in that packet number space.		acknowledge packets that appeared in that packet number space.
	However, as noted below, 0-RTT packets cannot contain ACK frames.		However, as noted below, 0-RTT packets cannot contain ACK frames.
	o All other frame types MUST only be sent in the application data		* All other frame types MUST only be sent in the application data
	packet number space.		packet number space.
	Note that it is not possible to send the following frames in 0-RTT		Note that it is not possible to send the following frames in 0-RTT
	packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,		packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
	PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt		PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt
	of these frames in 0-RTT packets as a connection error of type		of these frames in 0-RTT packets as a connection error of type
	PROTOCOL_VIOLATION.		PROTOCOL_VIOLATION.
	13. Packetization and Reliability		13. Packetization and Reliability
	skipping to change at page 88, line 27 ¶		skipping to change at line 4093 ¶
	congestion response, but this has to be balanced against excessive		congestion response, but this has to be balanced against excessive
	load generated by a receiver that sends an ACK frame in response to		load generated by a receiver that sends an ACK frame in response to
	every ack-eliciting packet. The guidance offered below seeks to		every ack-eliciting packet. The guidance offered below seeks to
	strike this balance.		strike this balance.
	13.2.1. Sending ACK Frames		13.2.1. Sending ACK Frames
	Every packet SHOULD be acknowledged at least once, and ack-eliciting		Every packet SHOULD be acknowledged at least once, and ack-eliciting
	packets MUST be acknowledged at least once within the maximum delay		packets MUST be acknowledged at least once within the maximum delay
	an endpoint communicated using the max_ack_delay transport parameter;		an endpoint communicated using the max_ack_delay transport parameter;
	see Section 18.2. max_ack_delay declares an explicit contract: an		see Section 18.2. max_ack_delay declares an explicit contract: an
	endpoint promises to never intentionally delay acknowledgments of an		endpoint promises to never intentionally delay acknowledgments of an
	ack-eliciting packet by more than the indicated value. If it does,		ack-eliciting packet by more than the indicated value. If it does,
	any excess accrues to the RTT estimate and could result in spurious		any excess accrues to the RTT estimate and could result in spurious
	or delayed retransmissions from the peer. A sender uses the		or delayed retransmissions from the peer. A sender uses the
	receiver's max_ack_delay value in determining timeouts for timer-		receiver's max_ack_delay value in determining timeouts for timer-
	based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY].		based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY].
	An endpoint MUST acknowledge all ack-eliciting Initial and Handshake		An endpoint MUST acknowledge all ack-eliciting Initial and Handshake
	packets immediately and all ack-eliciting 0-RTT and 1-RTT packets		packets immediately and all ack-eliciting 0-RTT and 1-RTT packets
	within its advertised max_ack_delay, with the following exception.		within its advertised max_ack_delay, with the following exception.
	skipping to change at page 89, line 24 ¶		skipping to change at line 4139 ¶
	choose to occasionally add an ack-eliciting frame to those packets to		choose to occasionally add an ack-eliciting frame to those packets to
	ensure that it receives an acknowledgment; see Section 13.2.4. In		ensure that it receives an acknowledgment; see Section 13.2.4. In
	that case, an endpoint MUST NOT send an ack-eliciting frame in all		that case, an endpoint MUST NOT send an ack-eliciting frame in all
	packets that would otherwise be non-ack-eliciting, to avoid an		packets that would otherwise be non-ack-eliciting, to avoid an
	infinite feedback loop of acknowledgments.		infinite feedback loop of acknowledgments.
	In order to assist loss detection at the sender, an endpoint SHOULD		In order to assist loss detection at the sender, an endpoint SHOULD
	generate and send an ACK frame without delay when it receives an ack-		generate and send an ACK frame without delay when it receives an ack-
	eliciting packet either:		eliciting packet either:
	o when the received packet has a packet number less than another		* when the received packet has a packet number less than another
	ack-eliciting packet that has been received, or		ack-eliciting packet that has been received, or
	o when the packet has a packet number larger than the highest-		* when the packet has a packet number larger than the highest-
	numbered ack-eliciting packet that has been received and there are		numbered ack-eliciting packet that has been received and there are
	missing packets between that packet and this packet.		missing packets between that packet and this packet.
	Similarly, packets marked with the ECN Congestion Experienced (CE)		Similarly, packets marked with the ECN Congestion Experienced (CE)
	codepoint in the IP header SHOULD be acknowledged immediately, to		codepoint in the IP header SHOULD be acknowledged immediately, to
	reduce the peer's response time to congestion events.		reduce the peer's response time to congestion events.
	The algorithms in [QUIC-RECOVERY] are expected to be resilient to		The algorithms in [QUIC-RECOVERY] are expected to be resilient to
	receivers that do not follow the guidance offered above. However, an		receivers that do not follow the guidance offered above. However, an
	implementation should only deviate from these requirements after		implementation should only deviate from these requirements after
	skipping to change at page 93, line 18 ¶		skipping to change at line 4322 ¶
	whole. The same applies to the frames that are contained within lost		whole. The same applies to the frames that are contained within lost
	packets. Instead, the information that might be carried in frames is		packets. Instead, the information that might be carried in frames is
	sent again in new frames as needed.		sent again in new frames as needed.
	New frames and packets are used to carry information that is		New frames and packets are used to carry information that is
	determined to have been lost. In general, information is sent again		determined to have been lost. In general, information is sent again
	when a packet containing that information is determined to be lost,		when a packet containing that information is determined to be lost,
	and sending ceases when a packet containing that information is		and sending ceases when a packet containing that information is
	acknowledged.		acknowledged.
	o Data sent in CRYPTO frames is retransmitted according to the rules		* Data sent in CRYPTO frames is retransmitted according to the rules
	in [QUIC-RECOVERY], until all data has been acknowledged. Data in		in [QUIC-RECOVERY], until all data has been acknowledged. Data in
	CRYPTO frames for Initial and Handshake packets is discarded when		CRYPTO frames for Initial and Handshake packets is discarded when
	keys for the corresponding packet number space are discarded.		keys for the corresponding packet number space are discarded.
	o Application data sent in STREAM frames is retransmitted in new		* Application data sent in STREAM frames is retransmitted in new
	STREAM frames unless the endpoint has sent a RESET_STREAM for that		STREAM frames unless the endpoint has sent a RESET_STREAM for that
	stream. Once an endpoint sends a RESET_STREAM frame, no further		stream. Once an endpoint sends a RESET_STREAM frame, no further
	STREAM frames are needed.		STREAM frames are needed.
	o ACK frames carry the most recent set of acknowledgments and the		* ACK frames carry the most recent set of acknowledgments and the
	acknowledgment delay from the largest acknowledged packet, as		acknowledgment delay from the largest acknowledged packet, as
	described in Section 13.2.1. Delaying the transmission of packets		described in Section 13.2.1. Delaying the transmission of packets
	containing ACK frames or resending old ACK frames can cause the		containing ACK frames or resending old ACK frames can cause the
	peer to generate an inflated RTT sample or unnecessarily disable		peer to generate an inflated RTT sample or unnecessarily disable
	ECN.		ECN.
	o Cancellation of stream transmission, as carried in a RESET_STREAM		* Cancellation of stream transmission, as carried in a RESET_STREAM
	frame, is sent until acknowledged or until all stream data is		frame, is sent until acknowledged or until all stream data is
	acknowledged by the peer (that is, either the "Reset Recvd" or		acknowledged by the peer (that is, either the "Reset Recvd" or
	"Data Recvd" state is reached on the sending part of the stream).		"Data Recvd" state is reached on the sending part of the stream).
	The content of a RESET_STREAM frame MUST NOT change when it is		The content of a RESET_STREAM frame MUST NOT change when it is
	sent again.		sent again.
	o Similarly, a request to cancel stream transmission, as encoded in		* Similarly, a request to cancel stream transmission, as encoded in
	a STOP_SENDING frame, is sent until the receiving part of the		a STOP_SENDING frame, is sent until the receiving part of the
	stream enters either a "Data Recvd" or "Reset Recvd" state; see		stream enters either a "Data Recvd" or "Reset Recvd" state; see
	Section 3.5.		Section 3.5.
	o Connection close signals, including packets that contain		* Connection close signals, including packets that contain
	CONNECTION_CLOSE frames, are not sent again when packet loss is		CONNECTION_CLOSE frames, are not sent again when packet loss is
	detected. Resending these signals is described in Section 10.		detected. Resending these signals is described in Section 10.
	o The current connection maximum data is sent in MAX_DATA frames.		* The current connection maximum data is sent in MAX_DATA frames.
	An updated value is sent in a MAX_DATA frame if the packet		An updated value is sent in a MAX_DATA frame if the packet
	containing the most recently sent MAX_DATA frame is declared lost		containing the most recently sent MAX_DATA frame is declared lost
	or when the endpoint decides to update the limit. Care is		or when the endpoint decides to update the limit. Care is
	necessary to avoid sending this frame too often, as the limit can		necessary to avoid sending this frame too often, as the limit can
	increase frequently and cause an unnecessarily large number of		increase frequently and cause an unnecessarily large number of
	MAX_DATA frames to be sent; see Section 4.2.		MAX_DATA frames to be sent; see Section 4.2.
	o The current maximum stream data offset is sent in MAX_STREAM_DATA		* The current maximum stream data offset is sent in MAX_STREAM_DATA
	frames. Like MAX_DATA, an updated value is sent when the packet		frames. Like MAX_DATA, an updated value is sent when the packet
	containing the most recent MAX_STREAM_DATA frame for a stream is		containing the most recent MAX_STREAM_DATA frame for a stream is
	lost or when the limit is updated, with care taken to prevent the		lost or when the limit is updated, with care taken to prevent the
	frame from being sent too often. An endpoint SHOULD stop sending		frame from being sent too often. An endpoint SHOULD stop sending
	MAX_STREAM_DATA frames when the receiving part of the stream		MAX_STREAM_DATA frames when the receiving part of the stream
	enters a "Size Known" or "Reset Recvd" state.		enters a "Size Known" or "Reset Recvd" state.
	o The limit on streams of a given type is sent in MAX_STREAMS		* The limit on streams of a given type is sent in MAX_STREAMS
	frames. Like MAX_DATA, an updated value is sent when a packet		frames. Like MAX_DATA, an updated value is sent when a packet
	containing the most recent MAX_STREAMS for a stream type frame is		containing the most recent MAX_STREAMS for a stream type frame is
	declared lost or when the limit is updated, with care taken to		declared lost or when the limit is updated, with care taken to
	prevent the frame from being sent too often.		prevent the frame from being sent too often.
	o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED,		* Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED,
	and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection		and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection
	scope, STREAM_DATA_BLOCKED frames have stream scope, and		scope, STREAM_DATA_BLOCKED frames have stream scope, and
	STREAMS_BLOCKED frames are scoped to a specific stream type. A		STREAMS_BLOCKED frames are scoped to a specific stream type. A
	new frame is sent if a packet containing the most recent frame for		new frame is sent if a packet containing the most recent frame for
	a scope is lost, but only while the endpoint is blocked on the		a scope is lost, but only while the endpoint is blocked on the
	corresponding limit. These frames always include the limit that		corresponding limit. These frames always include the limit that
	is causing blocking at the time that they are transmitted.		is causing blocking at the time that they are transmitted.
	o A liveness or path validation check using PATH_CHALLENGE frames is		* A liveness or path validation check using PATH_CHALLENGE frames is
	sent periodically until a matching PATH_RESPONSE frame is received		sent periodically until a matching PATH_RESPONSE frame is received
	or until there is no remaining need for liveness or path		or until there is no remaining need for liveness or path
	validation checking. PATH_CHALLENGE frames include a different		validation checking. PATH_CHALLENGE frames include a different
	payload each time they are sent.		payload each time they are sent.
	o Responses to path validation using PATH_RESPONSE frames are sent		* Responses to path validation using PATH_RESPONSE frames are sent
	just once. The peer is expected to send more PATH_CHALLENGE		just once. The peer is expected to send more PATH_CHALLENGE
	frames as necessary to evoke additional PATH_RESPONSE frames.		frames as necessary to evoke additional PATH_RESPONSE frames.
	o New connection IDs are sent in NEW_CONNECTION_ID frames and		* New connection IDs are sent in NEW_CONNECTION_ID frames and
	retransmitted if the packet containing them is lost.		retransmitted if the packet containing them is lost.
	Retransmissions of this frame carry the same sequence number		Retransmissions of this frame carry the same sequence number
	value. Likewise, retired connection IDs are sent in		value. Likewise, retired connection IDs are sent in
	RETIRE_CONNECTION_ID frames and retransmitted if the packet		RETIRE_CONNECTION_ID frames and retransmitted if the packet
	containing them is lost.		containing them is lost.
	o NEW_TOKEN frames are retransmitted if the packet containing them		* NEW_TOKEN frames are retransmitted if the packet containing them
	is lost. No special support is made for detecting reordered and		is lost. No special support is made for detecting reordered and
	duplicated NEW_TOKEN frames other than a direct comparison of the		duplicated NEW_TOKEN frames other than a direct comparison of the
	frame contents.		frame contents.
	o PING and PADDING frames contain no information, so lost PING or		* PING and PADDING frames contain no information, so lost PING or
	PADDING frames do not require repair.		PADDING frames do not require repair.
	o The HANDSHAKE_DONE frame MUST be retransmitted until it is		* The HANDSHAKE_DONE frame MUST be retransmitted until it is
	acknowledged.		acknowledged.
	Endpoints SHOULD prioritize retransmission of data over sending new		Endpoints SHOULD prioritize retransmission of data over sending new
	data, unless priorities specified by the application indicate		data, unless priorities specified by the application indicate
	otherwise; see Section 2.3.		otherwise; see Section 2.3.
	Even though a sender is encouraged to assemble frames containing up-		Even though a sender is encouraged to assemble frames containing up-
	to-date information every time it sends a packet, it is not forbidden		to-date information every time it sends a packet, it is not forbidden
	to retransmit copies of frames from lost packets. A sender that		to retransmit copies of frames from lost packets. A sender that
	retransmits copies of frames needs to handle decreases in available		retransmits copies of frames needs to handle decreases in available
	skipping to change at page 97, line 5 ¶		skipping to change at line 4499 ¶
	13.4.2. ECN Validation		13.4.2. ECN Validation
	It is possible for faulty network devices to corrupt or erroneously		It is possible for faulty network devices to corrupt or erroneously
	drop packets that carry a non-zero ECN codepoint. To ensure		drop packets that carry a non-zero ECN codepoint. To ensure
	connectivity in the presence of such devices, an endpoint validates		connectivity in the presence of such devices, an endpoint validates
	the ECN counts for each network path and disables the use of ECN on		the ECN counts for each network path and disables the use of ECN on
	that path if errors are detected.		that path if errors are detected.
	To perform ECN validation for a new path:		To perform ECN validation for a new path:
	o The endpoint sets an ECT(0) codepoint in the IP header of early		* The endpoint sets an ECT(0) codepoint in the IP header of early
	outgoing packets sent on a new path to the peer [RFC8311].		outgoing packets sent on a new path to the peer [RFC8311].
	o The endpoint monitors whether all packets sent with an ECT		* The endpoint monitors whether all packets sent with an ECT
	codepoint are eventually deemed lost (Section 6 of		codepoint are eventually deemed lost (Section 6 of
	[QUIC-RECOVERY]), indicating that ECN validation has failed.		[QUIC-RECOVERY]), indicating that ECN validation has failed.
	If an endpoint has cause to expect that IP packets with an ECT		If an endpoint has cause to expect that IP packets with an ECT
	codepoint might be dropped by a faulty network element, the endpoint		codepoint might be dropped by a faulty network element, the endpoint
	could set an ECT codepoint for only the first ten outgoing packets on		could set an ECT codepoint for only the first ten outgoing packets on
	a path, or for a period of three PTOs (see Section 6.2 of		a path, or for a period of three PTOs (see Section 6.2 of
	[QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints		[QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints
	are subsequently lost, it can disable marking on the assumption that		are subsequently lost, it can disable marking on the assumption that
	the marking caused the loss.		the marking caused the loss.
	skipping to change at page 99, line 15 ¶		skipping to change at line 4605 ¶
	maximum datagram size of at least 1200 bytes.		maximum datagram size of at least 1200 bytes.
	QUIC assumes a minimum IP packet size of at least 1280 bytes. This		QUIC assumes a minimum IP packet size of at least 1280 bytes. This
	is the IPv6 minimum size [IPv6] and is also supported by most modern		is the IPv6 minimum size [IPv6] and is also supported by most modern
	IPv4 networks. Assuming the minimum IP header size of 40 bytes for		IPv4 networks. Assuming the minimum IP header size of 40 bytes for
	IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this		IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this
	results in a maximum datagram size of 1232 bytes for IPv6 and 1252		results in a maximum datagram size of 1232 bytes for IPv6 and 1252
	bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are		bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are
	expected to be able to support QUIC.		expected to be able to support QUIC.
	Note: This requirement to support a UDP payload of 1200 bytes		| Note: This requirement to support a UDP payload of 1200 bytes
	limits the space available for IPv6 extension headers to 32 bytes		| limits the space available for IPv6 extension headers to 32
	or IPv4 options to 52 bytes if the path only supports the IPv6		| bytes or IPv4 options to 52 bytes if the path only supports the
	minimum MTU of 1280 bytes. This affects Initial packets and path		| IPv6 minimum MTU of 1280 bytes. This affects Initial packets
	validation.		| and path validation.
	Any maximum datagram size larger than 1200 bytes can be discovered		Any maximum datagram size larger than 1200 bytes can be discovered
	using Path Maximum Transmission Unit Discovery (PMTUD) (see		using Path Maximum Transmission Unit Discovery (PMTUD) (see
	Section 14.2.1) or Datagram Packetization Layer PMTU Discovery		Section 14.2.1) or Datagram Packetization Layer PMTU Discovery
	(DPLPMTUD) (see Section 14.3).		(DPLPMTUD) (see Section 14.3).
	Enforcement of the max_udp_payload_size transport parameter		Enforcement of the max_udp_payload_size transport parameter
	(Section 18.2) might act as an additional limit on the maximum		(Section 18.2) might act as an additional limit on the maximum
	datagram size. A sender can avoid exceeding this limit, once the		datagram size. A sender can avoid exceeding this limit, once the
	value is known. However, prior to learning the value of the		value is known. However, prior to learning the value of the
	skipping to change at page 103, line 30 ¶		skipping to change at line 4813 ¶
	One way to construct a PMTU probe is to coalesce (see Section 12.2) a		One way to construct a PMTU probe is to coalesce (see Section 12.2) a
	packet with a long header, such as a Handshake or 0-RTT packet		packet with a long header, such as a Handshake or 0-RTT packet
	(Section 17.2), with a short header packet in a single UDP datagram.		(Section 17.2), with a short header packet in a single UDP datagram.
	If the resulting PMTU probe reaches the endpoint, the packet with the		If the resulting PMTU probe reaches the endpoint, the packet with the
	long header will be ignored, but the short header packet will be		long header will be ignored, but the short header packet will be
	acknowledged. If the PMTU probe causes an ICMP message to be sent,		acknowledged. If the PMTU probe causes an ICMP message to be sent,
	the first part of the probe will be quoted in that message. If the		the first part of the probe will be quoted in that message. If the
	Source Connection ID field is within the quoted portion of the probe,		Source Connection ID field is within the quoted portion of the probe,
	that could be used for routing or validation of the ICMP message.		that could be used for routing or validation of the ICMP message.
	Note: The purpose of using a packet with a long header is only to		| Note: The purpose of using a packet with a long header is only
	ensure that the quoted packet contained in the ICMP message		| to ensure that the quoted packet contained in the ICMP message
	contains a Source Connection ID field. This packet does not need		| contains a Source Connection ID field. This packet does not
	to be a valid packet, and it can be sent even if there is no		| need to be a valid packet, and it can be sent even if there is
	current use for packets of that type.		| no current use for packets of that type.
	15. Versions		15. Versions
	QUIC versions are identified using a 32-bit unsigned number.		QUIC versions are identified using a 32-bit unsigned number.
	The version 0x00000000 is reserved to represent version negotiation.		The version 0x00000000 is reserved to represent version negotiation.
	This version of the specification is identified by the number		This version of the specification is identified by the number
	0x00000001.		0x00000001.
	Other versions of QUIC might have different properties from this		Other versions of QUIC might have different properties from this
	skipping to change at page 104, line 35 ¶		skipping to change at line 4865 ¶
	The QUIC variable-length integer encoding reserves the two most		The QUIC variable-length integer encoding reserves the two most
	significant bits of the first byte to encode the base-2 logarithm of		significant bits of the first byte to encode the base-2 logarithm of
	the integer encoding length in bytes. The integer value is encoded		the integer encoding length in bytes. The integer value is encoded
	on the remaining bits, in network byte order.		on the remaining bits, in network byte order.
	This means that integers are encoded on 1, 2, 4, or 8 bytes and can		This means that integers are encoded on 1, 2, 4, or 8 bytes and can
	encode 6-, 14-, 30-, or 62-bit values, respectively. Table 4		encode 6-, 14-, 30-, or 62-bit values, respectively. Table 4
	summarizes the encoding properties.		summarizes the encoding properties.
	+------+--------+-------------+-----------------------+		+======+========+=============+=======================+
	| 2MSB | Length | Usable Bits | Range |		| 2MSB | Length | Usable Bits | Range |
	+------+--------+-------------+-----------------------+		+======+========+=============+=======================+
	| 00 | 1 | 6 | 0-63 |		| 00 | 1 | 6 | 0-63 |
	| | | | |		+------+--------+-------------+-----------------------+
	| 01 | 2 | 14 | 0-16383 |		| 01 | 2 | 14 | 0-16383 |
	| | | | |		+------+--------+-------------+-----------------------+
	| 10 | 4 | 30 | 0-1073741823 |		| 10 | 4 | 30 | 0-1073741823 |
	| | | | |		+------+--------+-------------+-----------------------+
	| 11 | 8 | 62 | 0-4611686018427387903 |		| 11 | 8 | 62 | 0-4611686018427387903 |
	+------+--------+-------------+-----------------------+		+------+--------+-------------+-----------------------+
	Table 4: Summary of Integer Encodings		Table 4: Summary of Integer Encodings
	An example of a decoding algorithm and sample encodings are shown in		An example of a decoding algorithm and sample encodings are shown in
	Appendix A.1.		Appendix A.1.
	Values do not need to be encoded on the minimum number of bytes		Values do not need to be encoded on the minimum number of bytes
	necessary, with the sole exception of the Frame Type field; see		necessary, with the sole exception of the Frame Type field; see
	skipping to change at page 106, line 34 ¶		skipping to change at line 4958 ¶
	Long Packet Type (2),		Long Packet Type (2),
	Type-Specific Bits (4),		Type-Specific Bits (4),
	Version (32),		Version (32),
	Destination Connection ID Length (8),		Destination Connection ID Length (8),
	Destination Connection ID (0..160),		Destination Connection ID (0..160),
	Source Connection ID Length (8),		Source Connection ID Length (8),
	Source Connection ID (0..160),		Source Connection ID (0..160),
	Type-Specific Payload (..),		Type-Specific Payload (..),
	}		}
	Figure 13: Long Header Packet Format		Figure 13: Long Header Packet Format
	Long headers are used for packets that are sent prior to the		Long headers are used for packets that are sent prior to the
	establishment of 1-RTT keys. Once 1-RTT keys are available, a sender		establishment of 1-RTT keys. Once 1-RTT keys are available, a sender
	switches to sending packets using the short header (Section 17.3).		switches to sending packets using the short header (Section 17.3).
	The long form allows for special packets -- such as the Version		The long form allows for special packets -- such as the Version
	Negotiation packet -- to be represented in this uniform fixed-length		Negotiation packet -- to be represented in this uniform fixed-length
	packet format. Packets that use the long header contain the		packet format. Packets that use the long header contain the
	following fields:		following fields:
	Header Form: The most significant bit (0x80) of byte 0 (the first		Header Form: The most significant bit (0x80) of byte 0 (the first
	skipping to change at page 108, line 5 ¶		skipping to change at line 5021 ¶
	Source Connection ID Length field, which indicates the length of		Source Connection ID Length field, which indicates the length of
	this field. Section 7.2 describes the use of this field in more		this field. Section 7.2 describes the use of this field in more
	detail.		detail.
	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 |
	+------+-----------+-----------------+		+======+===========+================+
	| 0x00 | Initial | Section 17.2.2 |		| 0x00 | Initial | Section 17.2.2 |
	| | | |		+------+-----------+----------------+
	| 0x01 | 0-RTT | Section 17.2.3 |		| 0x01 | 0-RTT | Section 17.2.3 |
	| | | |		+------+-----------+----------------+
	| 0x02 | Handshake | Section 17.2.4 |		| 0x02 | Handshake | Section 17.2.4 |
	| | | |		+------+-----------+----------------+
	| 0x03 | 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.
	The interpretation of the fields and the payload are specific to a		The interpretation of the fields and the payload are specific to a
	skipping to change at page 113, line 24 ¶		skipping to change at line 5266 ¶
	Version (32),		Version (32),
	Destination Connection ID Length (8),		Destination Connection ID Length (8),
	Destination Connection ID (0..160),		Destination Connection ID (0..160),
	Source Connection ID Length (8),		Source Connection ID Length (8),
	Source Connection ID (0..160),		Source Connection ID (0..160),
	Length (i),		Length (i),
	Packet Number (8..32),		Packet Number (8..32),
	Packet Payload (8..),		Packet Payload (8..),
	}		}
	0-RTT Packet		Figure 16: 0-RTT Packet
	Packet numbers for 0-RTT protected packets use the same space as		Packet numbers for 0-RTT protected packets use the same space as
	1-RTT protected packets.		1-RTT protected packets.
	After a client receives a Retry packet, 0-RTT packets are likely to		After a client receives a Retry packet, 0-RTT packets are likely to
	have been lost or discarded by the server. A client SHOULD attempt		have been lost or discarded by the server. A client SHOULD attempt
	to resend data in 0-RTT packets after it sends a new Initial packet.		to resend data in 0-RTT packets after it sends a new Initial packet.
	New packet numbers MUST be used for any new packets that are sent; as		New packet numbers MUST be used for any new packets that are sent; as
	described in Section 17.2.5.3, reusing packet numbers could		described in Section 17.2.5.3, reusing packet numbers could
	compromise packet protection.		compromise packet protection.
	skipping to change at page 114, line 29 ¶		skipping to change at line 5316 ¶
	Version (32),		Version (32),
	Destination Connection ID Length (8),		Destination Connection ID Length (8),
	Destination Connection ID (0..160),		Destination Connection ID (0..160),
	Source Connection ID Length (8),		Source Connection ID Length (8),
	Source Connection ID (0..160),		Source Connection ID (0..160),
	Length (i),		Length (i),
	Packet Number (8..32),		Packet Number (8..32),
	Packet Payload (8..),		Packet Payload (8..),
	}		}
	Figure 16: Handshake Protected Packet		Figure 17: Handshake Protected Packet
	Once a client has received a Handshake packet from a server, it uses		Once a client has received a Handshake packet from a server, it uses
	Handshake packets to send subsequent cryptographic handshake messages		Handshake packets to send subsequent cryptographic handshake messages
	and acknowledgments to the server.		and acknowledgments to the server.
	The Destination Connection ID field in a Handshake packet contains a		The Destination Connection ID field in a Handshake packet contains a
	connection ID that is chosen by the recipient of the packet; the		connection ID that is chosen by the recipient of the packet; the
	Source Connection ID includes the connection ID that the sender of		Source Connection ID includes the connection ID that the sender of
	the packet wishes to use; see Section 7.2.		the packet wishes to use; see Section 7.2.
	skipping to change at page 115, line 7 ¶		skipping to change at line 5343 ¶
	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
	As shown in Figure 17, a Retry packet uses a long packet header with		As shown in Figure 18, a Retry packet uses a long packet header with
	a type value of 0x03. It carries an address validation token created		a type value of 0x03. It carries an address validation token created
	by the server. It is used by a server that wishes to perform a		by the server. It is used by a server that wishes to perform a
	retry; see Section 8.1.		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),
	Destination Connection ID (0..160),		Destination Connection ID (0..160),
	Source Connection ID Length (8),		Source Connection ID Length (8),
	Source Connection ID (0..160),		Source Connection ID (0..160),
	Retry Token (..),		Retry Token (..),
	Retry Integrity Tag (128),		Retry Integrity Tag (128),
	}		}
	Figure 17: Retry Packet		Figure 18: Retry Packet
	A Retry packet does not contain any protected fields. The value in		A Retry packet does not contain any protected fields. The value in
	the Unused field is set to an arbitrary value by the server; a client		the Unused field is set to an arbitrary value by the server; a client
	MUST ignore these bits. In addition to the fields from the long		MUST ignore these bits. In addition to the fields from the long
	header, it contains these additional fields:		header, it contains these additional fields:
	Retry Token: An opaque token that the server can use to validate the		Retry Token: An opaque token that the server can use to validate the
	client's address.		client's address.
	Retry Integrity Tag: Defined in Section "Retry Packet Integrity"		Retry Integrity Tag: Defined in Section 5.8 ("Retry Packet
	[QUIC-TLS] of [QUIC-TLS].		Integrity") of [QUIC-TLS].
	17.2.5.1. Sending a Retry Packet		17.2.5.1. Sending a Retry Packet
	The server populates the Destination Connection ID with the		The server populates the Destination Connection ID with the
	connection ID that the client included in the Source Connection ID of		connection ID that the client included in the Source Connection ID of
	the Initial packet.		the Initial packet.
	The server includes a connection ID of its choice in the Source		The server includes a connection ID of its choice in the Source
	Connection ID field. This value MUST NOT be equal to the Destination		Connection ID field. This value MUST NOT be equal to the Destination
	Connection ID field of the packet sent by the client. A client MUST		Connection ID field of the packet sent by the client. A client MUST
	skipping to change at page 118, line 17 ¶		skipping to change at line 5486 ¶
	Fixed Bit (1) = 1,		Fixed Bit (1) = 1,
	Spin Bit (1),		Spin Bit (1),
	Reserved Bits (2),		Reserved Bits (2),
	Key Phase (1),		Key Phase (1),
	Packet Number Length (2),		Packet Number Length (2),
	Destination Connection ID (0..160),		Destination Connection ID (0..160),
	Packet Number (8..32),		Packet Number (8..32),
	Packet Payload (8..),		Packet Payload (8..),
	}		}
	1-RTT Packet		Figure 19: 1-RTT Packet
	1-RTT packets contain the following fields:		1-RTT packets contain the following fields:
	Header Form: The most significant bit (0x80) of byte 0 is set to 0		Header Form: The most significant bit (0x80) of byte 0 is set to 0
	for the short header.		for the short header.
	Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets		Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
	containing a zero value for this bit are not valid packets in this		containing a zero value for this bit are not valid packets in this
	version and MUST be discarded. A value of 1 for this bit allows		version and MUST be discarded. A value of 1 for this bit allows
	QUIC to coexist with other protocols; see [RFC7983].		QUIC to coexist with other protocols; see [RFC7983].
	skipping to change at page 120, line 42 ¶		skipping to change at line 5608 ¶
	bit in the received packet.		bit in the received packet.
	An endpoint resets the spin value for a network path to 0 when		An endpoint resets the spin value for a network path to 0 when
	changing the connection ID being used on that network path.		changing the connection ID being used on that network path.
	18. Transport Parameter Encoding		18. Transport Parameter Encoding
	The extension_data field of the quic_transport_parameters extension		The extension_data field of the quic_transport_parameters extension
	defined in [QUIC-TLS] contains the QUIC transport parameters. They		defined in [QUIC-TLS] contains the QUIC transport parameters. They
	are encoded as a sequence of transport parameters, as shown in		are encoded as a sequence of transport parameters, as shown in
	Figure 18:		Figure 20:
	Transport Parameters {		Transport Parameters {
	Transport Parameter (..) ...,		Transport Parameter (..) ...,
	}		}
	Figure 18: Sequence of Transport Parameters		Figure 20: Sequence of Transport Parameters
	Each transport parameter is encoded as an (identifier, length, value)		Each transport parameter is encoded as an (identifier, length, value)
	tuple, as shown in Figure 19:		tuple, as shown in Figure 21:
	Transport Parameter {		Transport Parameter {
	Transport Parameter ID (i),		Transport Parameter ID (i),
	Transport Parameter Length (i),		Transport Parameter Length (i),
	Transport Parameter Value (..),		Transport Parameter Value (..),
	}		}
	Figure 19: Transport Parameter Encoding		Figure 21: Transport Parameter Encoding
	The Transport Parameter Length field contains the length of the		The Transport Parameter Length field contains the length of the
	Transport Parameter Value field in bytes.		Transport Parameter Value field in bytes.
	QUIC encodes transport parameters into a sequence of bytes, which is		QUIC encodes transport parameters into a sequence of bytes, which is
	then included in the cryptographic handshake.		then included in the cryptographic handshake.
	18.1. Reserved Transport Parameters		18.1. Reserved Transport Parameters
	Transport parameters with an identifier of the form "31 * N + 27" for		Transport parameters with an identifier of the form "31 * N + 27" for
	skipping to change at page 124, line 21 ¶		skipping to change at line 5779 ¶
	encoded in network byte order.		encoded in network byte order.
	The preferred_address transport parameter contains an address and		The preferred_address transport parameter contains an address and
	port for both IPv4 and IPv6. The four-byte IPv4 Address field is		port for both IPv4 and IPv6. The four-byte IPv4 Address field is
	followed by the associated two-byte IPv4 Port field. This is		followed by the associated two-byte IPv4 Port field. This is
	followed by a 16-byte IPv6 Address field and two-byte IPv6 Port		followed by a 16-byte IPv6 Address field and two-byte IPv6 Port
	field. After address and port pairs, a Connection ID Length field		field. After address and port pairs, a Connection ID Length field
	describes the length of the following Connection ID field.		describes the length of the following Connection ID field.
	Finally, a 16-byte Stateless Reset Token field includes the		Finally, a 16-byte Stateless Reset Token field includes the
	stateless reset token associated with the connection ID. The		stateless reset token associated with the connection ID. The
	format of this transport parameter is shown in Figure 20 below.		format of this transport parameter is shown in Figure 22 below.
	The Connection ID field and the Stateless Reset Token field		The Connection ID field and the Stateless Reset Token field
	contain an alternative connection ID that has a sequence number of		contain an alternative connection ID that has a sequence number of
	1; see Section 5.1.1. Having these values sent alongside the		1; see Section 5.1.1. Having these values sent alongside the
	preferred address ensures that there will be at least one unused		preferred address ensures that there will be at least one unused
	active connection ID when the client initiates migration to the		active connection ID when the client initiates migration to the
	preferred address.		preferred address.
	The Connection ID and Stateless Reset Token fields of a preferred		The Connection ID and Stateless Reset Token fields of a preferred
	address are identical in syntax and semantics to the corresponding		address are identical in syntax and semantics to the corresponding
	skipping to change at page 124, line 49 ¶		skipping to change at line 5807 ¶
	Preferred Address {		Preferred Address {
	IPv4 Address (32),		IPv4 Address (32),
	IPv4 Port (16),		IPv4 Port (16),
	IPv6 Address (128),		IPv6 Address (128),
	IPv6 Port (16),		IPv6 Port (16),
	Connection ID Length (8),		Connection ID Length (8),
	Connection ID (..),		Connection ID (..),
	Stateless Reset Token (128),		Stateless Reset Token (128),
	}		}
	Figure 20: Preferred Address Format		Figure 22: Preferred Address Format
	active_connection_id_limit (0x0e): This is an integer value		active_connection_id_limit (0x0e): This is an integer value
	specifying the maximum number of connection IDs from the peer that		specifying the maximum number of connection IDs from the peer that
	an endpoint is willing to store. This value includes the		an endpoint is willing to store. This value includes the
	connection ID received during the handshake, that received in the		connection ID received during the handshake, that received in the
	preferred_address transport parameter, and those received in		preferred_address transport parameter, and those received in
	NEW_CONNECTION_ID frames. The value of the		NEW_CONNECTION_ID frames. The value of the
	active_connection_id_limit parameter MUST be at least 2. An		active_connection_id_limit parameter MUST be at least 2. An
	endpoint that receives a value less than 2 MUST close the		endpoint that receives a value less than 2 MUST close the
	connection with an error of type TRANSPORT_PARAMETER_ERROR. If		connection with an error of type TRANSPORT_PARAMETER_ERROR. If
	skipping to change at page 126, line 5 ¶		skipping to change at line 5858 ¶
	This section describes the format and semantics of the core QUIC		This section describes the format and semantics of the core QUIC
	frame types.		frame types.
	19.1. PADDING Frames		19.1. PADDING Frames
	A PADDING frame (type=0x00) has no semantic value. PADDING frames		A PADDING frame (type=0x00) has no semantic value. PADDING frames
	can be used to increase the size of a packet. Padding can be used to		can be used to increase the size of a packet. Padding can be used to
	increase an Initial packet to the minimum required size or to provide		increase an Initial packet to the minimum required size or to provide
	protection against traffic analysis for protected packets.		protection against traffic analysis for protected packets.
	PADDING frames are formatted as shown in Figure 21, which shows that		PADDING frames are formatted as shown in Figure 23, which shows that
	PADDING frames have no content. That is, a PADDING frame consists of		PADDING frames have no content. That is, a PADDING frame consists of
	the single byte that identifies the frame as a PADDING frame.		the single byte that identifies the frame as a PADDING frame.
	PADDING Frame {		PADDING Frame {
	Type (i) = 0x00,		Type (i) = 0x00,
	}		}
	Figure 21: PADDING Frame Format		Figure 23: PADDING Frame Format
	19.2. PING Frames		19.2. PING Frames
	Endpoints can use PING frames (type=0x01) to verify that their peers		Endpoints can use PING frames (type=0x01) to verify that their peers
	are still alive or to check reachability to the peer.		are still alive or to check reachability to the peer.
	PING frames are formatted as shown in Figure 22, which shows that		PING frames are formatted as shown in Figure 24, which shows that
	PING frames have no content.		PING frames have no content.
	PING Frame {		PING Frame {
	Type (i) = 0x01,		Type (i) = 0x01,
	}		}
	Figure 22: PING Frame Format		Figure 24: PING Frame Format
	The receiver of a PING frame simply needs to acknowledge the packet		The receiver of a PING frame simply needs to acknowledge the packet
	containing this frame.		containing this frame.
	The PING frame can be used to keep a connection alive when an		The PING frame can be used to keep a connection alive when an
	application or application protocol wishes to prevent the connection		application or application protocol wishes to prevent the connection
	from timing out; see Section 10.1.2.		from timing out; see Section 10.1.2.
	19.3. ACK Frames		19.3. ACK Frames
	skipping to change at page 127, line 16 ¶		skipping to change at line 5917 ¶
	the same numeric value. An acknowledgment for a packet needs to		the same numeric value. An acknowledgment for a packet needs to
	indicate both a packet number and a packet number space. This is		indicate both a packet number and a packet number space. This is
	accomplished by having each ACK frame only acknowledge packet numbers		accomplished by having each ACK frame only acknowledge packet numbers
	in the same space as the packet in which the ACK frame is contained.		in the same space as the packet in which the ACK frame is contained.
	Version Negotiation and Retry packets cannot be acknowledged because		Version Negotiation and Retry packets cannot be acknowledged because
	they do not contain a packet number. Rather than relying on ACK		they do not contain a packet number. Rather than relying on ACK
	frames, these packets are implicitly acknowledged by the next Initial		frames, these packets are implicitly acknowledged by the next Initial
	packet sent by the client.		packet sent by the client.
	ACK frames are formatted as shown in Figure 23.		ACK frames are formatted as shown in Figure 25.
	ACK Frame {		ACK Frame {
	Type (i) = 0x02..0x03,		Type (i) = 0x02..0x03,
	Largest Acknowledged (i),		Largest Acknowledged (i),
	ACK Delay (i),		ACK Delay (i),
	ACK Range Count (i),		ACK Range Count (i),
	First ACK Range (i),		First ACK Range (i),
	ACK Range (..) ...,		ACK Range (..) ...,
	[ECN Counts (..)],		[ECN Counts (..)],
	}		}
	Figure 23: ACK Frame Format		Figure 25: ACK Frame Format
	ACK frames contain the following fields:		ACK frames contain the following fields:
	Largest Acknowledged: A variable-length integer representing the		Largest Acknowledged: A variable-length integer representing the
	largest packet number the peer is acknowledging; this is usually		largest packet number the peer is acknowledging; this is usually
	the largest packet number that the peer has received prior to		the largest packet number that the peer has received prior to
	generating the ACK frame. Unlike the packet number in the QUIC		generating the ACK frame. Unlike the packet number in the QUIC
	long or short header, the value in an ACK frame is not truncated.		long or short header, the value in an ACK frame is not truncated.
	ACK Delay: A variable-length integer encoding the acknowledgment		ACK Delay: A variable-length integer encoding the acknowledgment
	skipping to change at page 128, line 21 ¶		skipping to change at line 5971 ¶
	ECN Counts: The three ECN counts; see Section 19.3.2.		ECN Counts: The three ECN counts; see Section 19.3.2.
	19.3.1. ACK Ranges		19.3.1. ACK Ranges
	Each ACK Range consists of alternating Gap and ACK Range Length		Each ACK Range consists of alternating Gap and ACK Range Length
	values in descending packet number order. ACK Ranges can be		values in descending packet number order. ACK Ranges can be
	repeated. The number of Gap and ACK Range Length values is		repeated. The number of Gap and ACK Range Length values is
	determined by the ACK Range Count field; one of each value is present		determined by the ACK Range Count field; one of each value is present
	for each value in the ACK Range Count field.		for each value in the ACK Range Count field.
	ACK Ranges are structured as shown in Figure 24.		ACK Ranges are structured as shown in Figure 26.
	ACK Range {		ACK Range {
	Gap (i),		Gap (i),
	ACK Range Length (i),		ACK Range Length (i),
	}		}
	Figure 24: ACK Ranges		Figure 26: ACK Ranges
	The fields that form each ACK Range are:		The fields that form each ACK Range are:
	Gap: A variable-length integer indicating the number of contiguous		Gap: A variable-length integer indicating the number of contiguous
	unacknowledged packets preceding the packet number one lower than		unacknowledged packets preceding the packet number one lower than
	the smallest in the preceding ACK Range.		the smallest in the preceding ACK Range.
	ACK Range Length: A variable-length integer indicating the number of		ACK Range Length: A variable-length integer indicating the number of
	contiguous acknowledged packets preceding the largest packet		contiguous acknowledged packets preceding the largest packet
	number, as determined by the preceding Gap.		number, as determined by the preceding Gap.
	skipping to change at page 129, line 35 ¶		skipping to change at line 6032 ¶
	a connection error of type FRAME_ENCODING_ERROR.		a connection error of type FRAME_ENCODING_ERROR.
	19.3.2. ECN Counts		19.3.2. ECN Counts
	The ACK frame uses the least significant bit of the type value (that		The ACK frame uses the least significant bit of the type value (that
	is, type 0x03) to indicate ECN feedback and report receipt of QUIC		is, type 0x03) to indicate ECN feedback and report receipt of QUIC
	packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE		packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE
	in the packet's IP header. ECN counts are only present when the ACK		in the packet's IP header. ECN counts are only present when the ACK
	frame type is 0x03.		frame type is 0x03.
	When present, there are three ECN counts, as shown in Figure 25.		When present, there are three ECN counts, as shown in Figure 27.
	ECN Counts {		ECN Counts {
	ECT0 Count (i),		ECT0 Count (i),
	ECT1 Count (i),		ECT1 Count (i),
	ECN-CE Count (i),		ECN-CE Count (i),
	}		}
	Figure 25: ECN Count Format		Figure 27: ECN Count Format
	The ECN count fields are:		The ECN count fields are:
	ECT0 Count: A variable-length integer representing the total number		ECT0 Count: A variable-length integer representing the total number
	of packets received with the ECT(0) codepoint in the packet number		of packets received with the ECT(0) codepoint in the packet number
	space of the ACK frame.		space of the ACK frame.
	ECT1 Count: A variable-length integer representing the total number		ECT1 Count: A variable-length integer representing the total number
	of packets received with the ECT(1) codepoint in the packet number		of packets received with the ECT(1) codepoint in the packet number
	space of the ACK frame.		space of the ACK frame.
	skipping to change at page 130, line 28 ¶		skipping to change at line 6071 ¶
	terminate the sending part of a stream.		terminate the sending part of a stream.
	After sending a RESET_STREAM, an endpoint ceases transmission and		After sending a RESET_STREAM, an endpoint ceases transmission and
	retransmission of STREAM frames on the identified stream. A receiver		retransmission of STREAM frames on the identified stream. A receiver
	of RESET_STREAM can discard any data that it already received on that		of RESET_STREAM can discard any data that it already received on that
	stream.		stream.
	An endpoint that receives a RESET_STREAM frame for a send-only stream		An endpoint that receives a RESET_STREAM frame for a send-only stream
	MUST terminate the connection with error STREAM_STATE_ERROR.		MUST terminate the connection with error STREAM_STATE_ERROR.
	RESET_STREAM frames are formatted as shown in Figure 26.		RESET_STREAM frames are formatted as shown in Figure 28.
	RESET_STREAM Frame {		RESET_STREAM Frame {
	Type (i) = 0x04,		Type (i) = 0x04,
	Stream ID (i),		Stream ID (i),
	Application Protocol Error Code (i),		Application Protocol Error Code (i),
	Final Size (i),		Final Size (i),
	}		}
	Figure 26: RESET_STREAM Frame Format		Figure 28: RESET_STREAM Frame Format
	RESET_STREAM frames contain the following fields:		RESET_STREAM frames contain the following fields:
	Stream ID: A variable-length integer encoding of the stream ID of		Stream ID: A variable-length integer encoding of the stream ID of
	the stream being terminated.		the stream being terminated.
	Application Protocol Error Code: A variable-length integer		Application Protocol Error Code: A variable-length integer
	containing the application protocol error code (see Section 20.2)		containing the application protocol error code (see Section 20.2)
	that indicates why the stream is being closed.		that indicates why the stream is being closed.
	skipping to change at page 131, line 18 ¶		skipping to change at line 6108 ¶
	incoming data is being discarded on receipt per application request.		incoming data is being discarded on receipt per 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.2. 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 29.
	STOP_SENDING Frame {		STOP_SENDING Frame {
	Type (i) = 0x05,		Type (i) = 0x05,
	Stream ID (i),		Stream ID (i),
	Application Protocol Error Code (i),		Application Protocol Error Code (i),
	}		}
	Figure 27: STOP_SENDING Frame Format		Figure 29: STOP_SENDING Frame Format
	STOP_SENDING frames contain the following fields:		STOP_SENDING frames contain the following fields:
	Stream ID: A variable-length integer carrying the stream ID of the		Stream ID: A variable-length integer carrying the stream ID of the
	stream being ignored.		stream being ignored.
	Application Protocol Error Code: A variable-length integer		Application Protocol Error Code: A variable-length integer
	containing the application-specified reason the sender is ignoring		containing the application-specified reason the sender is ignoring
	the stream; see Section 20.2.		the stream; see Section 20.2.
	19.6. CRYPTO Frames		19.6. CRYPTO Frames
	A CRYPTO frame (type=0x06) is used to transmit cryptographic		A CRYPTO frame (type=0x06) is used to transmit cryptographic
	handshake messages. It can be sent in all packet types except 0-RTT.		handshake messages. It can be sent in all packet types except 0-RTT.
	The CRYPTO frame offers the cryptographic protocol an in-order stream		The CRYPTO frame offers the cryptographic protocol an in-order stream
	of bytes. CRYPTO frames are functionally identical to STREAM frames,		of bytes. CRYPTO frames are functionally identical to STREAM frames,
	except that they do not bear a stream identifier; they are not flow		except that they do not bear a stream identifier; they are not flow
	controlled; and they do not carry markers for optional offset,		controlled; and they do not carry markers for optional offset,
	optional length, and the end of the stream.		optional length, and the end of the stream.
	CRYPTO frames are formatted as shown in Figure 28.		CRYPTO frames are formatted as shown in Figure 30.
	CRYPTO Frame {		CRYPTO Frame {
	Type (i) = 0x06,		Type (i) = 0x06,
	Offset (i),		Offset (i),
	Length (i),		Length (i),
	Crypto Data (..),		Crypto Data (..),
	}		}
	Figure 28: CRYPTO Frame Format		Figure 30: CRYPTO Frame Format
	CRYPTO frames contain the following fields:		CRYPTO frames contain the following fields:
	Offset: A variable-length integer specifying the byte offset in the		Offset: A variable-length integer specifying the byte offset in the
	stream for the data in this CRYPTO frame.		stream for the data in this CRYPTO frame.
	Length: A variable-length integer specifying the length of the		Length: A variable-length integer specifying the length of the
	Crypto Data field in this CRYPTO frame.		Crypto Data field in this CRYPTO frame.
	Crypto Data: The cryptographic message data.		Crypto Data: The cryptographic message data.
	skipping to change at page 132, line 45 ¶		skipping to change at line 6179 ¶
	stream the data belongs, the CRYPTO frame carries data for a single		stream the data belongs, the CRYPTO frame carries data for a single
	stream per encryption level. The stream does not have an explicit		stream per encryption level. The stream does not have an explicit
	end, so CRYPTO frames do not have a FIN bit.		end, so CRYPTO frames do not have a FIN bit.
	19.7. NEW_TOKEN Frames		19.7. NEW_TOKEN Frames
	A server sends a NEW_TOKEN frame (type=0x07) to provide the client		A server sends a NEW_TOKEN frame (type=0x07) to provide the client
	with a token to send in the header of an Initial packet for a future		with a token to send in the header of an Initial packet for a future
	connection.		connection.
	NEW_TOKEN frames are formatted as shown in Figure 29.		NEW_TOKEN frames are formatted as shown in Figure 31.
	NEW_TOKEN Frame {		NEW_TOKEN Frame {
	Type (i) = 0x07,		Type (i) = 0x07,
	Token Length (i),		Token Length (i),
	Token (..),		Token (..),
	}		}
	Figure 29: NEW_TOKEN Frame Format		Figure 31: NEW_TOKEN Frame Format
	NEW_TOKEN frames contain the following fields:		NEW_TOKEN frames contain the following fields:
	Token Length: A variable-length integer specifying the length of the		Token Length: A variable-length integer specifying the length of the
	token in bytes.		token in bytes.
	Token: An opaque blob that the client can use with a future Initial		Token: An opaque blob that the client can use with a future Initial
	packet. The token MUST NOT be empty. A client MUST treat receipt		packet. The token MUST NOT be empty. A client MUST treat receipt
	of a NEW_TOKEN frame with an empty Token field as a connection		of a NEW_TOKEN frame with an empty Token field as a connection
	error of type FRAME_ENCODING_ERROR.		error of type FRAME_ENCODING_ERROR.
	skipping to change at page 133, line 40 ¶		skipping to change at line 6216 ¶
	of a NEW_TOKEN frame as a connection error of type		of a NEW_TOKEN frame as a connection error of type
	PROTOCOL_VIOLATION.		PROTOCOL_VIOLATION.
	19.8. STREAM Frames		19.8. STREAM Frames
	STREAM frames implicitly create a stream and carry stream data. The		STREAM frames implicitly create a stream and carry stream data. The
	Type field in the STREAM frame takes the form 0b00001XXX (or the set		Type field in the STREAM frame takes the form 0b00001XXX (or the set
	of values from 0x08 to 0x0f). The three low-order bits of the frame		of values from 0x08 to 0x0f). The three low-order bits of the frame
	type determine the fields that are present in the frame:		type determine the fields that are present in the frame:
	o The OFF bit (0x04) in the frame type is set to indicate that there		* The OFF bit (0x04) in the frame type is set to indicate that there
	is an Offset field present. When set to 1, the Offset field is		is an Offset field present. When set to 1, the Offset field is
	present. When set to 0, the Offset field is absent and the Stream		present. When set to 0, the Offset field is absent and the Stream
	Data starts at an offset of 0 (that is, the frame contains the		Data starts at an offset of 0 (that is, the frame contains the
	first bytes of the stream, or the end of a stream that includes no		first bytes of the stream, or the end of a stream that includes no
	data).		data).
	o The LEN bit (0x02) in the frame type is set to indicate that there		* The LEN bit (0x02) in the frame type is set to indicate that there
	is a Length field present. If this bit is set to 0, the Length		is a Length field present. If this bit is set to 0, the Length
	field is absent and the Stream Data field extends to the end of		field is absent and the Stream Data field extends to the end of
	the packet. If this bit is set to 1, the Length field is present.		the packet. If this bit is set to 1, the Length field is present.
	o The FIN bit (0x01) indicates that the frame marks the end of the		* The FIN bit (0x01) indicates that the frame marks the end of the
	stream. The final size of the stream is the sum of the offset and		stream. The final size of the stream is the sum of the offset and
	the length of this frame.		the length of this frame.
	An endpoint MUST terminate the connection with error		An endpoint MUST terminate the connection with error
	STREAM_STATE_ERROR if it receives a STREAM frame for a locally		STREAM_STATE_ERROR if it receives a STREAM frame for a locally
	initiated stream that has not yet been created, or for a send-only		initiated stream that has not yet been created, or for a send-only
	stream.		stream.
	STREAM frames are formatted as shown in Figure 30.		STREAM frames are formatted as shown in Figure 32.
	STREAM Frame {		STREAM Frame {
	Type (i) = 0x08..0x0f,		Type (i) = 0x08..0x0f,
	Stream ID (i),		Stream ID (i),
	[Offset (i)],		[Offset (i)],
	[Length (i)],		[Length (i)],
	Stream Data (..),		Stream Data (..),
	}		}
	Figure 30: STREAM Frame Format		Figure 32: STREAM Frame Format
	STREAM frames contain the following fields:		STREAM frames contain the following fields:
	Stream ID: A variable-length integer indicating the stream ID of the		Stream ID: A variable-length integer indicating the stream ID of the
	stream; see Section 2.1.		stream; see Section 2.1.
	Offset: A variable-length integer specifying the byte offset in the		Offset: A variable-length integer specifying the byte offset in the
	stream for the data in this STREAM frame. This field is present		stream for the data in this STREAM frame. This field is present
	when the OFF bit is set to 1. When the Offset field is absent,		when the OFF bit is set to 1. When the Offset field is absent,
	the offset is 0.		the offset is 0.
	skipping to change at page 135, line 11 ¶		skipping to change at line 6282 ¶
	credit for that data. Receipt of a frame that exceeds this limit		credit for that data. Receipt of a frame that exceeds this limit
	MUST be treated as a connection error of type FRAME_ENCODING_ERROR or		MUST be treated as a connection error of type FRAME_ENCODING_ERROR or
	FLOW_CONTROL_ERROR.		FLOW_CONTROL_ERROR.
	19.9. MAX_DATA Frames		19.9. MAX_DATA Frames
	A MAX_DATA frame (type=0x10) is used in flow control to inform the		A MAX_DATA frame (type=0x10) is used in flow control to inform the
	peer of the maximum amount of data that can be sent on the connection		peer of the maximum amount of data that can be sent on the connection
	as a whole.		as a whole.
	MAX_DATA frames are formatted as shown in Figure 31.		MAX_DATA frames are formatted as shown in Figure 33.
	MAX_DATA Frame {		MAX_DATA Frame {
	Type (i) = 0x10,		Type (i) = 0x10,
	Maximum Data (i),		Maximum Data (i),
	}		}
	Figure 31: MAX_DATA Frame Format		Figure 33: MAX_DATA Frame Format
	MAX_DATA frames contain the following field:		MAX_DATA frames contain the following field:
	Maximum Data: A variable-length integer indicating the maximum		Maximum Data: A variable-length integer indicating the maximum
	amount of data that can be sent on the entire connection, in units		amount of data that can be sent on the entire connection, in units
	of bytes.		of bytes.
	All data sent in STREAM frames counts toward this limit. The sum of		All data sent in STREAM frames counts toward this limit. The sum of
	the final sizes on all streams -- including streams in terminal		the final sizes on all streams -- including streams in terminal
	states -- MUST NOT exceed the value advertised by a receiver. An		states -- MUST NOT exceed the value advertised by a receiver. An
	skipping to change at page 135, line 46 ¶		skipping to change at line 6317 ¶
	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.2. 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 34.
	MAX_STREAM_DATA Frame {		MAX_STREAM_DATA Frame {
	Type (i) = 0x11,		Type (i) = 0x11,
	Stream ID (i),		Stream ID (i),
	Maximum Stream Data (i),		Maximum Stream Data (i),
	}		}
	Figure 32: MAX_STREAM_DATA Frame Format		Figure 34: MAX_STREAM_DATA Frame Format
	MAX_STREAM_DATA frames contain the following fields:		MAX_STREAM_DATA frames contain the following fields:
	Stream ID: The stream ID of the affected stream, encoded as a		Stream ID: The stream ID of the affected stream, encoded as a
	variable-length integer.		variable-length integer.
	Maximum Stream Data: A variable-length integer indicating the		Maximum Stream Data: A variable-length integer indicating the
	maximum amount of data that can be sent on the identified stream,		maximum amount of data that can be sent on the identified stream,
	in units of bytes.		in units of bytes.
	skipping to change at page 136, line 44 ¶		skipping to change at line 6358 ¶
	in Early Data; see Section 7.4.1.		in Early Data; see Section 7.4.1.
	19.11. MAX_STREAMS Frames		19.11. MAX_STREAMS Frames
	A MAX_STREAMS frame (type=0x12 or 0x13) informs the peer of the		A MAX_STREAMS frame (type=0x12 or 0x13) informs the peer of the
	cumulative number of streams of a given type it is permitted to open.		cumulative number of streams of a given type it is permitted to open.
	A MAX_STREAMS frame with a type of 0x12 applies to bidirectional		A MAX_STREAMS frame with a type of 0x12 applies to bidirectional
	streams, and a MAX_STREAMS frame with a type of 0x13 applies to		streams, and a MAX_STREAMS frame with a type of 0x13 applies to
	unidirectional streams.		unidirectional streams.
	MAX_STREAMS frames are formatted as shown in Figure 33.		MAX_STREAMS frames are formatted as shown in Figure 35.
	MAX_STREAMS Frame {		MAX_STREAMS Frame {
	Type (i) = 0x12..0x13,		Type (i) = 0x12..0x13,
	Maximum Streams (i),		Maximum Streams (i),
	}		}
	Figure 33: MAX_STREAMS Frame Format		Figure 35: MAX_STREAMS Frame Format
	MAX_STREAMS frames contain the following field:		MAX_STREAMS frames contain the following field:
	Maximum Streams: A count of the cumulative number of streams of the		Maximum Streams: A count of the cumulative number of streams of the
	corresponding type that can be opened over the lifetime of the		corresponding type that can be opened over the lifetime of the
	connection. This value cannot exceed 2^60, as it is not possible		connection. This value cannot exceed 2^60, as it is not possible
	to encode stream IDs larger than 2^62-1. Receipt of a frame that		to encode stream IDs larger than 2^62-1. Receipt of a frame that
	permits opening of a stream larger than this limit MUST be treated		permits opening of a stream larger than this limit MUST be treated
	as a connection error of type FRAME_ENCODING_ERROR.		as a connection error of type FRAME_ENCODING_ERROR.
	skipping to change at page 137, line 39 ¶		skipping to change at line 6401 ¶
	concurrently. The limit includes streams that have been closed as		concurrently. The limit includes streams that have been closed as
	well as those that are open.		well as those that are open.
	19.12. DATA_BLOCKED Frames		19.12. DATA_BLOCKED Frames
	A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes		A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes
	to send data but is unable to do so due to connection-level flow		to send data but is unable to do so due to connection-level flow
	control; see Section 4. DATA_BLOCKED frames can be used as input to		control; see Section 4. DATA_BLOCKED frames can be used as input to
	tuning of flow control algorithms; see Section 4.2.		tuning of flow control algorithms; see Section 4.2.
	DATA_BLOCKED frames are formatted as shown in Figure 34.		DATA_BLOCKED frames are formatted as shown in Figure 36.
	DATA_BLOCKED Frame {		DATA_BLOCKED Frame {
	Type (i) = 0x14,		Type (i) = 0x14,
	Maximum Data (i),		Maximum Data (i),
	}		}
	Figure 34: DATA_BLOCKED Frame Format		Figure 36: DATA_BLOCKED Frame Format
	DATA_BLOCKED frames contain the following field:		DATA_BLOCKED frames contain the following field:
	Maximum Data: A variable-length integer indicating the connection-		Maximum Data: A variable-length integer indicating the connection-
	level limit at which blocking occurred.		level limit at which blocking occurred.
	19.13. STREAM_DATA_BLOCKED Frames		19.13. STREAM_DATA_BLOCKED Frames
	A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it		A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
	wishes to send data but is unable to do so due to stream-level flow		wishes to send data but is unable to do so due to stream-level flow
	control. This frame is analogous to DATA_BLOCKED (Section 19.12).		control. This frame is analogous to DATA_BLOCKED (Section 19.12).
	An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only		An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only
	stream MUST terminate the connection with error STREAM_STATE_ERROR.		stream MUST terminate the connection with error STREAM_STATE_ERROR.
	STREAM_DATA_BLOCKED frames are formatted as shown in Figure 35.		STREAM_DATA_BLOCKED frames are formatted as shown in Figure 37.
	STREAM_DATA_BLOCKED Frame {		STREAM_DATA_BLOCKED Frame {
	Type (i) = 0x15,		Type (i) = 0x15,
	Stream ID (i),		Stream ID (i),
	Maximum Stream Data (i),		Maximum Stream Data (i),
	}		}
	Figure 35: STREAM_DATA_BLOCKED Frame Format		Figure 37: STREAM_DATA_BLOCKED Frame Format
	STREAM_DATA_BLOCKED frames contain the following fields:		STREAM_DATA_BLOCKED frames contain the following fields:
	Stream ID: A variable-length integer indicating the stream that is		Stream ID: A variable-length integer indicating the stream that is
	blocked due to flow control.		blocked due to flow control.
	Maximum Stream Data: A variable-length integer indicating the offset		Maximum Stream Data: A variable-length integer indicating the offset
	of the stream at which the blocking occurred.		of the stream at which the blocking occurred.
	19.14. STREAMS_BLOCKED Frames		19.14. STREAMS_BLOCKED Frames
	skipping to change at page 138, line 45 ¶		skipping to change at line 6455 ¶
	it wishes to open a stream but is unable to do so due to the maximum		it wishes to open a stream but is unable to do so due to the maximum
	stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED		stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED
	frame of type 0x16 is used to indicate reaching the bidirectional		frame of type 0x16 is used to indicate reaching the bidirectional
	stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to		stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to
	indicate reaching the unidirectional stream limit.		indicate reaching the unidirectional stream limit.
	A STREAMS_BLOCKED frame does not open the stream, but informs the		A STREAMS_BLOCKED frame does not open the stream, but informs the
	peer that a new stream was needed and the stream limit prevented the		peer that a new stream was needed and the stream limit prevented the
	creation of the stream.		creation of the stream.
	STREAMS_BLOCKED frames are formatted as shown in Figure 36.		STREAMS_BLOCKED frames are formatted as shown in Figure 38.
	STREAMS_BLOCKED Frame {		STREAMS_BLOCKED Frame {
	Type (i) = 0x16..0x17,		Type (i) = 0x16..0x17,
	Maximum Streams (i),		Maximum Streams (i),
	}		}
	Figure 36: STREAMS_BLOCKED Frame Format		Figure 38: STREAMS_BLOCKED Frame Format
	STREAMS_BLOCKED frames contain the following field:		STREAMS_BLOCKED frames contain the following field:
	Maximum Streams: A variable-length integer indicating the maximum		Maximum Streams: A variable-length integer indicating the maximum
	number of streams allowed at the time the frame was sent. This		number of streams allowed at the time the frame was sent. This
	value cannot exceed 2^60, as it is not possible to encode stream		value cannot exceed 2^60, as it is not possible to encode stream
	IDs larger than 2^62-1. Receipt of a frame that encodes a larger		IDs larger than 2^62-1. Receipt of a frame that encodes a larger
	stream ID MUST be treated as a connection error of type		stream ID MUST be treated as a connection error of type
	STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR.		STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR.
	19.15. NEW_CONNECTION_ID Frames		19.15. NEW_CONNECTION_ID Frames
	An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide		An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide
	its peer with alternative connection IDs that can be used to break		its peer with alternative connection IDs that can be used to break
	linkability when migrating connections; see Section 9.5.		linkability when migrating connections; see Section 9.5.
	NEW_CONNECTION_ID frames are formatted as shown in Figure 37.		NEW_CONNECTION_ID frames are formatted as shown in Figure 39.
	NEW_CONNECTION_ID Frame {		NEW_CONNECTION_ID Frame {
	Type (i) = 0x18,		Type (i) = 0x18,
	Sequence Number (i),		Sequence Number (i),
	Retire Prior To (i),		Retire Prior To (i),
	Length (8),		Length (8),
	Connection ID (8..160),		Connection ID (8..160),
	Stateless Reset Token (128),		Stateless Reset Token (128),
	}		}
	Figure 37: NEW_CONNECTION_ID Frame Format		Figure 39: NEW_CONNECTION_ID Frame Format
	NEW_CONNECTION_ID frames contain the following fields:		NEW_CONNECTION_ID frames contain the following fields:
	Sequence Number: The sequence number assigned to the connection ID		Sequence Number: The sequence number assigned to the connection ID
	by the sender, encoded as a variable-length integer; see		by the sender, encoded as a variable-length integer; see
	Section 5.1.1.		Section 5.1.1.
	Retire Prior To: A variable-length integer indicating which		Retire Prior To: A variable-length integer indicating which
	connection IDs should be retired; see Section 5.1.2.		connection IDs should be retired; see Section 5.1.2.
	skipping to change at page 141, line 10 ¶		skipping to change at line 6566 ¶
	indicate that it will no longer use a connection ID that was issued		indicate that it will no longer use a connection ID that was issued
	by its peer. This includes the connection ID provided during the		by its peer. This includes the connection ID provided during the
	handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a		handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a
	request to the peer to send additional connection IDs for future use;		request to the peer to send additional connection IDs for future use;
	see Section 5.1. New connection IDs can be delivered to a peer using		see Section 5.1. New connection IDs can be delivered to a peer using
	the NEW_CONNECTION_ID frame (Section 19.15).		the NEW_CONNECTION_ID frame (Section 19.15).
	Retiring a connection ID invalidates the stateless reset token		Retiring a connection ID invalidates the stateless reset token
	associated with that connection ID.		associated with that connection ID.
	RETIRE_CONNECTION_ID frames are formatted as shown in Figure 38.		RETIRE_CONNECTION_ID frames are formatted as shown in Figure 40.
	RETIRE_CONNECTION_ID Frame {		RETIRE_CONNECTION_ID Frame {
	Type (i) = 0x19,		Type (i) = 0x19,
	Sequence Number (i),		Sequence Number (i),
	}		}
	Figure 38: RETIRE_CONNECTION_ID Frame Format		Figure 40: RETIRE_CONNECTION_ID Frame Format
	RETIRE_CONNECTION_ID frames contain the following field:		RETIRE_CONNECTION_ID frames contain the following field:
	Sequence Number: The sequence number of the connection ID being		Sequence Number: The sequence number of the connection ID being
	retired; see Section 5.1.2.		retired; see Section 5.1.2.
	Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number		Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number
	greater than any previously sent to the peer MUST be treated as a		greater than any previously sent to the peer MUST be treated as a
	connection error of type PROTOCOL_VIOLATION.		connection error of type PROTOCOL_VIOLATION.
	skipping to change at page 141, line 44 ¶		skipping to change at line 6600 ¶
	length connection ID by its peer. An endpoint that provides a zero-		length connection ID by its peer. An endpoint that provides a zero-
	length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID		length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID
	frame as a connection error of type PROTOCOL_VIOLATION.		frame as a connection error of type PROTOCOL_VIOLATION.
	19.17. PATH_CHALLENGE Frames		19.17. PATH_CHALLENGE Frames
	Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check		Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check
	reachability to the peer and for path validation during connection		reachability to the peer and for path validation during connection
	migration.		migration.
	PATH_CHALLENGE frames are formatted as shown in Figure 39.		PATH_CHALLENGE frames are formatted as shown in Figure 41.
	PATH_CHALLENGE Frame {		PATH_CHALLENGE Frame {
	Type (i) = 0x1a,		Type (i) = 0x1a,
	Data (64),		Data (64),
	}		}
	Figure 39: PATH_CHALLENGE Frame Format		Figure 41: PATH_CHALLENGE Frame Format
	PATH_CHALLENGE frames contain the following field:		PATH_CHALLENGE frames contain the following field:
	Data: This 8-byte field contains arbitrary data.		Data: This 8-byte field contains arbitrary data.
	Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that		Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that
	it is easier to receive the packet than it is to guess the value		it is easier to receive the packet than it is to guess the value
	correctly.		correctly.
	The recipient of this frame MUST generate a PATH_RESPONSE frame		The recipient of this frame MUST generate a PATH_RESPONSE frame
	(Section 19.18) containing the same Data value.		(Section 19.18) containing the same Data value.
	19.18. PATH_RESPONSE Frames		19.18. PATH_RESPONSE Frames
	A PATH_RESPONSE frame (type=0x1b) is sent in response to a		A PATH_RESPONSE frame (type=0x1b) is sent in response to a
	PATH_CHALLENGE frame.		PATH_CHALLENGE frame.
	PATH_RESPONSE frames are formatted as shown in Figure 40. The format		PATH_RESPONSE frames are formatted as shown in Figure 42. The format
	of a PATH_RESPONSE frame is identical to that of the PATH_CHALLENGE		of a PATH_RESPONSE frame is identical to that of the PATH_CHALLENGE
	frame; see Section 19.17.		frame; see Section 19.17.
	PATH_RESPONSE Frame {		PATH_RESPONSE Frame {
	Type (i) = 0x1b,		Type (i) = 0x1b,
	Data (64),		Data (64),
	}		}
	Figure 40: PATH_RESPONSE Frame Format		Figure 42: PATH_RESPONSE Frame Format
	If the content of a PATH_RESPONSE frame does not match the content of		If the content of a PATH_RESPONSE frame does not match the content of
	a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint		a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint
	MAY generate a connection error of type PROTOCOL_VIOLATION.		MAY generate a connection error of type PROTOCOL_VIOLATION.
	19.19. CONNECTION_CLOSE Frames		19.19. CONNECTION_CLOSE Frames
	An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to		An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to
	notify its peer that the connection is being closed. The		notify its peer that the connection is being closed. The
	CONNECTION_CLOSE frame with a type of 0x1c is used to signal errors		CONNECTION_CLOSE frame with a type of 0x1c is used to signal errors
	at only the QUIC layer, or the absence of errors (with the NO_ERROR		at only the QUIC layer, or the absence of errors (with the NO_ERROR
	code). The CONNECTION_CLOSE frame with a type of 0x1d is used to		code). The CONNECTION_CLOSE frame with a type of 0x1d is used to
	signal an error with the application that uses QUIC.		signal an error with the application that uses QUIC.
	If there are open streams that have not been explicitly closed, they		If there are open streams that have not been explicitly closed, they
	are implicitly closed when the connection is closed.		are implicitly closed when the connection is closed.
	CONNECTION_CLOSE frames are formatted as shown in Figure 41.		CONNECTION_CLOSE frames are formatted as shown in Figure 43.
	CONNECTION_CLOSE Frame {		CONNECTION_CLOSE Frame {
	Type (i) = 0x1c..0x1d,		Type (i) = 0x1c..0x1d,
	Error Code (i),		Error Code (i),
	[Frame Type (i)],		[Frame Type (i)],
	Reason Phrase Length (i),		Reason Phrase Length (i),
	Reason Phrase (..),		Reason Phrase (..),
	}		}
	Figure 41: CONNECTION_CLOSE Frame Format		Figure 43: CONNECTION_CLOSE Frame Format
	CONNECTION_CLOSE frames contain the following fields:		CONNECTION_CLOSE frames contain the following fields:
	Error Code: A variable-length integer that indicates the reason for		Error Code: A variable-length integer that indicates the reason for
	closing this connection. A CONNECTION_CLOSE frame of type 0x1c		closing this connection. A CONNECTION_CLOSE frame of type 0x1c
	uses codes from the space defined in Section 20.1. A		uses codes from the space defined in Section 20.1. A
	CONNECTION_CLOSE frame of type 0x1d uses codes defined by the		CONNECTION_CLOSE frame of type 0x1d uses codes defined by the
	application protocol; see Section 20.2.		application protocol; see Section 20.2.
	Frame Type: A variable-length integer encoding the type of frame		Frame Type: A variable-length integer encoding the type of frame
	skipping to change at page 144, line 5 ¶		skipping to change at line 6701 ¶
	only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an		only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an
	application wishes to abandon a connection during the handshake, an		application wishes to abandon a connection during the handshake, an
	endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error		endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error
	code of APPLICATION_ERROR in an Initial or Handshake packet.		code of APPLICATION_ERROR in an Initial or Handshake packet.
	19.20. HANDSHAKE_DONE Frames		19.20. HANDSHAKE_DONE Frames
	The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal		The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal
	confirmation of the handshake to the client.		confirmation of the handshake to the client.
	HANDSHAKE_DONE frames are formatted as shown in Figure 42, which		HANDSHAKE_DONE frames are formatted as shown in Figure 44, which
	shows that HANDSHAKE_DONE frames have no content.		shows that HANDSHAKE_DONE frames have no content.
	HANDSHAKE_DONE Frame {		HANDSHAKE_DONE Frame {
	Type (i) = 0x1e,		Type (i) = 0x1e,
	}		}
	Figure 42: HANDSHAKE_DONE Frame Format		Figure 44: HANDSHAKE_DONE Frame Format
	A HANDSHAKE_DONE frame can only be sent by the server. Servers MUST		A HANDSHAKE_DONE frame can only be sent by the server. Servers MUST
	NOT send a HANDSHAKE_DONE frame before completing the handshake. A		NOT send a HANDSHAKE_DONE frame before completing the handshake. A
	server MUST treat receipt of a HANDSHAKE_DONE frame as a connection		server MUST treat receipt of a HANDSHAKE_DONE frame as a connection
	error of type PROTOCOL_VIOLATION.		error of type PROTOCOL_VIOLATION.
	19.21. Extension Frames		19.21. Extension Frames
	QUIC frames do not use a self-describing encoding. An endpoint		QUIC frames do not use a self-describing encoding. An endpoint
	therefore needs to understand the syntax of all frames before it can		therefore needs to understand the syntax of all frames before it can
	skipping to change at page 148, line 31 ¶		skipping to change at line 6917 ¶
	Address validation (Section 8) is used to verify that an entity that		Address validation (Section 8) is used to verify that an entity that
	claims a given address is able to receive packets at that address.		claims a given address is able to receive packets at that address.
	Address validation limits amplification attack targets to addresses		Address validation limits amplification attack targets to addresses
	for which an attacker can observe packets.		for which an attacker can observe packets.
	Prior to address validation, endpoints are limited in what they are		Prior to address validation, endpoints are limited in what they are
	able to send. Endpoints cannot send data toward an unvalidated		able to send. Endpoints cannot send data toward an unvalidated
	address in excess of three times the data received from that address.		address in excess of three times the data received from that address.
	Note: The anti-amplification limit only applies when an endpoint		| Note: The anti-amplification limit only applies when an
	responds to packets received from an unvalidated address. The		| endpoint responds to packets received from an unvalidated
	anti-amplification limit does not apply to clients when		| address. The anti-amplification limit does not apply to
	establishing a new connection or when initiating connection		| clients when establishing a new connection or when initiating
	migration.		| connection migration.
	21.1.1.2. Server-Side DoS		21.1.1.2. Server-Side DoS
	Computing the server's first flight for a full handshake is		Computing the server's first flight for a full handshake is
	potentially expensive, requiring both a signature and a key exchange		potentially expensive, requiring both a signature and a key exchange
	computation. In order to prevent computational DoS attacks, the		computation. In order to prevent computational DoS attacks, the
	Retry packet provides a cheap token exchange mechanism that allows		Retry packet provides a cheap token exchange mechanism that allows
	servers to validate a client's IP address prior to doing any		servers to validate a client's IP address prior to doing any
	expensive computations at the cost of a single round trip. After a		expensive computations at the cost of a single round trip. After a
	successful handshake, servers can issue new tokens to a client, which		successful handshake, servers can issue new tokens to a client, which
	skipping to change at page 150, line 45 ¶		skipping to change at line 7028 ¶
	21.1.3.1. On-Path Active Attacks		21.1.3.1. On-Path Active Attacks
	An attacker that can cause a packet it observes to no longer reach		An attacker that can cause a packet it observes to no longer reach
	its intended destination is considered an on-path attacker. When an		its intended destination is considered an on-path attacker. When an
	attacker is present between a client and server, endpoints are		attacker is present between a client and server, endpoints are
	required to send packets through the attacker to establish		required to send packets through the attacker to establish
	connectivity on a given path.		connectivity on a given path.
	An on-path attacker can:		An on-path attacker can:
	o Inspect packets		* Inspect packets
	o Modify IP and UDP packet headers		* Modify IP and UDP packet headers
	o Inject new packets		* Inject new packets
	o Delay packets		* Delay packets
	o Reorder packets
	o Drop packets		* Reorder packets
	o Split and merge datagrams along packet boundaries		* Drop packets
			* Split and merge datagrams along packet boundaries
	An on-path attacker cannot:		An on-path attacker cannot:
	o Modify an authenticated portion of a packet and cause the		* Modify an authenticated portion of a packet and cause the
	recipient to accept that packet		recipient to accept that packet
	An on-path attacker has the opportunity to modify the packets that it		An on-path attacker has the opportunity to modify the packets that it
	observes; however, any modifications to an authenticated portion of a		observes; however, any modifications to an authenticated portion of a
	packet will cause it to be dropped by the receiving endpoint as		packet will cause it to be dropped by the receiving endpoint as
	invalid, as packet payloads are both authenticated and encrypted.		invalid, as packet payloads are both authenticated and encrypted.
	QUIC aims to constrain the capabilities of an on-path attacker as		QUIC aims to constrain the capabilities of an on-path attacker as
	follows:		follows:
	skipping to change at page 152, line 5 ¶		skipping to change at line 7084 ¶
	21.1.3.2. Off-Path Active Attacks		21.1.3.2. Off-Path Active Attacks
	An off-path attacker is not directly on the path between a client and		An off-path attacker is not directly on the path between a client and
	server but could be able to obtain copies of some or all packets sent		server but could be able to obtain copies of some or all packets sent
	between the client and the server. It is also able to send copies of		between the client and the server. It is also able to send copies of
	those packets to either endpoint.		those packets to either endpoint.
	An off-path attacker can:		An off-path attacker can:
	o Inspect packets		* Inspect packets
	o Inject new packets		* Inject new packets
	o Reorder injected packets		* Reorder injected packets
	An off-path attacker cannot:		An off-path attacker cannot:
	o Modify packets sent by endpoints		* Modify packets sent by endpoints
	o Delay packets		* Delay packets
	o Drop packets		* Drop packets
	o Reorder original packets		* Reorder original packets
	An off-path attacker can create modified copies of packets that it		An off-path attacker can create modified copies of packets that it
	has observed and inject those copies into the network, potentially		has observed and inject those copies into the network, potentially
	with spoofed source and destination addresses.		with spoofed source and destination addresses.
	For the purposes of this discussion, it is assumed that an off-path		For the purposes of this discussion, it is assumed that an off-path
	attacker has the ability to inject a modified copy of a packet into		attacker has the ability to inject a modified copy of a packet into
	the network that will reach the destination endpoint prior to the		the network that will reach the destination endpoint prior to the
	arrival of the original packet observed by the attacker. In other		arrival of the original packet observed by the attacker. In other
	words, an attacker has the ability to consistently "win" a race with		words, an attacker has the ability to consistently "win" a race with
	skipping to change at page 153, line 34 ¶		skipping to change at line 7160 ¶
	A limited on-path attacker differs from an on-path attacker in that		A limited on-path attacker differs from an on-path attacker in that
	it is not on the original path between endpoints, and therefore the		it is not on the original path between endpoints, and therefore the
	original packets sent by an endpoint are still reaching their		original packets sent by an endpoint are still reaching their
	destination. This means that a future failure to route copied		destination. This means that a future failure to route copied
	packets to the destination faster than their original path will not		packets to the destination faster than their original path will not
	prevent the original packets from reaching the destination.		prevent the original packets from reaching the destination.
	A limited on-path attacker can:		A limited on-path attacker can:
	o Inspect packets		* Inspect packets
	o Inject new packets		* Inject new packets
	o Modify unencrypted packet headers		* Modify unencrypted packet headers
	o Reorder packets		* Reorder packets
	A limited on-path attacker cannot:		A limited on-path attacker cannot:
	o Delay packets so that they arrive later than packets sent on the		* Delay packets so that they arrive later than packets sent on the
	original path		original path
	o Drop packets		* Drop packets
	o Modify the authenticated and encrypted portion of a packet and		* Modify the authenticated and encrypted portion of a packet and
	cause the recipient to accept that packet		cause the recipient to accept that packet
	A limited on-path attacker can only delay packets up to the point		A limited on-path attacker can only delay packets up to the point
	that the original packets arrive before the duplicate packets,		that the original packets arrive before the duplicate packets,
	meaning that it cannot offer routing with worse latency than the		meaning that it cannot offer routing with worse latency than the
	original path. If a limited on-path attacker drops packets, the		original path. If a limited on-path attacker drops packets, the
	original copy will still arrive at the destination endpoint.		original copy will still arrive at the destination endpoint.
	QUIC aims to constrain the capabilities of a limited off-path		QUIC aims to constrain the capabilities of a limited off-path
	attacker as follows:		attacker as follows:
	skipping to change at page 154, line 50 ¶		skipping to change at line 7223 ¶
	During the creation of a connection, QUIC only provides protection		During the creation of a connection, QUIC only provides protection
	against attacks from off the network path. All QUIC packets contain		against attacks from off the network path. All QUIC packets contain
	proof that the recipient saw a preceding packet from its peer.		proof that the recipient saw a preceding packet from its peer.
	Addresses cannot change during the handshake, so endpoints can		Addresses cannot change during the handshake, so endpoints can
	discard packets that are received on a different network path.		discard packets that are received on a different network path.
	The Source and Destination Connection ID fields are the primary means		The Source and Destination Connection ID fields are the primary means
	of protection against an off-path attack during the handshake; see		of protection against an off-path attack during the handshake; see
	Section 8.1. These are required to match those set by a peer.		Section 8.1. These are required to match those set by a peer.
	Except for Initial packets and Stateless Resets, an endpoint only		Except for Initial and Stateless Resets, an endpoint only accepts
	accepts packets that include a Destination Connection ID field that		packets that include a Destination Connection ID field that matches a
	matches a value the endpoint previously chose. This is the only		value the endpoint previously chose. This is the only protection
	protection offered for Version Negotiation packets.		offered for Version Negotiation packets.
	The Destination Connection ID field in an Initial packet is selected		The Destination Connection ID field in an Initial packet is selected
	by a client to be unpredictable, which serves an additional purpose.		by a client to be unpredictable, which serves an additional purpose.
	The packets that carry the cryptographic handshake are protected with		The packets that carry the cryptographic handshake are protected with
	a key that is derived from this connection ID and a salt specific to		a key that is derived from this connection ID and a salt specific to
	the QUIC version. This allows endpoints to use the same process for		the QUIC version. This allows endpoints to use the same process for
	authenticating packets that they receive as they use after the		authenticating packets that they receive as they use after the
	cryptographic handshake completes. Packets that cannot be		cryptographic handshake completes. Packets that cannot be
	authenticated are discarded. Protecting packets in this fashion		authenticated are discarded. Protecting packets in this fashion
	provides a strong assurance that the sender of the packet saw the		provides a strong assurance that the sender of the packet saw the
	skipping to change at page 157, line 18 ¶		skipping to change at line 7333 ¶
	co-located with vulnerable endpoints, this version of QUIC does not		co-located with vulnerable endpoints, this version of QUIC does not
	allow servers to migrate, thus preventing spoofed migration attacks		allow servers to migrate, thus preventing spoofed migration attacks
	on clients. Any future extension that allows server migration MUST		on clients. Any future extension that allows server migration MUST
	also define countermeasures for forgery attacks.		also define countermeasures for forgery attacks.
	21.5.1. Control Options for Endpoints		21.5.1. Control Options for Endpoints
	QUIC offers some opportunities for an attacker to influence or		QUIC offers some opportunities for an attacker to influence or
	control where its peer sends UDP datagrams:		control where its peer sends UDP datagrams:
	o initial connection establishment (Section 7), where a server is		* initial connection establishment (Section 7), where a server is
	able to choose where a client sends datagrams -- for example, by		able to choose where a client sends datagrams -- for example, by
	populating DNS records;		populating DNS records;
	o preferred addresses (Section 9.6), where a server is able to		* preferred addresses (Section 9.6), where a server is able to
	choose where a client sends datagrams;		choose where a client sends datagrams;
	o spoofed connection migrations (Section 9.3.1), where a client is		* spoofed connection migrations (Section 9.3.1), where a client is
	able to use source address spoofing to select where a server sends		able to use source address spoofing to select where a server sends
	subsequent datagrams; and		subsequent datagrams; and
	o spoofed packets that cause a server to send a Version Negotiation		* spoofed packets that cause a server to send a Version Negotiation
	packet (Section 21.5.5).		packet (Section 21.5.5).
	In all cases, the attacker can cause its peer to send datagrams to a		In all cases, the attacker can cause its peer to send datagrams to a
	victim that might not understand QUIC. That is, these packets are		victim that might not understand QUIC. That is, these packets are
	sent by the peer prior to address validation; see Section 8.		sent by the peer prior to address validation; see Section 8.
	Outside of the encrypted portion of packets, QUIC offers an endpoint		Outside of the encrypted portion of packets, QUIC offers an endpoint
	several options for controlling the content of UDP datagrams that its		several options for controlling the content of UDP datagrams that its
	peer sends. The Destination Connection ID field offers direct		peer sends. The Destination Connection ID field offers direct
	control over bytes that appear early in packets sent by the peer; see		control over bytes that appear early in packets sent by the peer; see
	skipping to change at page 161, line 18 ¶		skipping to change at line 7521 ¶
	Endpoints are not expected to have specific information about the		Endpoints are not expected to have specific information about the
	location of servers that could be vulnerable targets of a request		location of servers that could be vulnerable targets of a request
	forgery attack. However, it might be possible over time to identify		forgery attack. However, it might be possible over time to identify
	specific UDP ports that are common targets of attacks or particular		specific UDP ports that are common targets of attacks or particular
	patterns in datagrams that are used for attacks. Endpoints MAY		patterns in datagrams that are used for attacks. Endpoints MAY
	choose to avoid sending datagrams to these ports or not send		choose to avoid sending datagrams to these ports or not send
	datagrams that match these patterns prior to validating the		datagrams that match these patterns prior to validating the
	destination address. Endpoints MAY retire connection IDs containing		destination address. Endpoints MAY retire connection IDs containing
	patterns known to be problematic without using them.		patterns known to be problematic without using them.
	Note: Modifying endpoints to apply these protections is more		| Note: Modifying endpoints to apply these protections is more
	efficient than deploying network-based protections, as endpoints		| efficient than deploying network-based protections, as
	do not need to perform any additional processing when sending to		| endpoints do not need to perform any additional processing when
	an address that has been validated.		| sending to an address that has been validated.
	21.6. Slowloris Attacks		21.6. Slowloris Attacks
	The attacks commonly known as Slowloris [SLOWLORIS] try to keep many		The attacks commonly known as Slowloris [SLOWLORIS] try to keep many
	connections to the target endpoint open and hold them open as long as		connections to the target endpoint open and hold them open as long as
	possible. These attacks can be executed against a QUIC endpoint by		possible. These attacks can be executed against a QUIC endpoint by
	generating the minimum amount of activity necessary to avoid being		generating the minimum amount of activity necessary to avoid being
	closed for inactivity. This might involve sending small amounts of		closed for inactivity. This might involve sending small amounts of
	data, gradually opening flow control windows in order to control the		data, gradually opening flow control windows in order to control the
	sender rate, or manufacturing ACK frames that simulate a high loss		sender rate, or manufacturing ACK frames that simulate a high loss
	skipping to change at page 169, line 5 ¶		skipping to change at line 7864 ¶
	assigned using Standards Action or IESG Approval as defined in		assigned using Standards Action or IESG Approval as defined in
	Sections 4.9 and 4.10 of [RFC8126].		Sections 4.9 and 4.10 of [RFC8126].
	In addition to the fields listed in Section 22.1.1, permanent		In addition to the fields listed in Section 22.1.1, permanent
	registrations in this registry MUST include the following field:		registrations in this registry MUST include the following field:
	Parameter Name: A short mnemonic for the parameter.		Parameter Name: A short mnemonic for the parameter.
	The initial contents of this registry are shown in Table 6.		The initial contents of this registry are shown in Table 6.
	+-------+-------------------------------------+---------------+		+=======+=====================================+===============+
	| Value | Parameter Name | Specification |		| Value | Parameter Name | Specification |
	+-------+-------------------------------------+---------------+		+=======+=====================================+===============+
	| 0x00 | original_destination_connection_id | Section 18.2 |		| 0x00 | original_destination_connection_id | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x01 | max_idle_timeout | Section 18.2 |		| 0x01 | max_idle_timeout | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x02 | stateless_reset_token | Section 18.2 |		| 0x02 | stateless_reset_token | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x03 | max_udp_payload_size | Section 18.2 |		| 0x03 | max_udp_payload_size | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x04 | initial_max_data | Section 18.2 |		| 0x04 | initial_max_data | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x05 | initial_max_stream_data_bidi_local | Section 18.2 |		| 0x05 | initial_max_stream_data_bidi_local | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 |		| 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x07 | initial_max_stream_data_uni | Section 18.2 |		| 0x07 | initial_max_stream_data_uni | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x08 | initial_max_streams_bidi | Section 18.2 |		| 0x08 | initial_max_streams_bidi | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x09 | initial_max_streams_uni | Section 18.2 |		| 0x09 | initial_max_streams_uni | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x0a | ack_delay_exponent | Section 18.2 |		| 0x0a | ack_delay_exponent | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x0b | max_ack_delay | Section 18.2 |		| 0x0b | max_ack_delay | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x0c | disable_active_migration | Section 18.2 |		| 0x0c | disable_active_migration | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x0d | preferred_address | Section 18.2 |		| 0x0d | preferred_address | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x0e | active_connection_id_limit | Section 18.2 |		| 0x0e | active_connection_id_limit | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x0f | initial_source_connection_id | Section 18.2 |		| 0x0f | initial_source_connection_id | Section 18.2 |
	| | | |		+-------+-------------------------------------+---------------+
	| 0x10 | retry_source_connection_id | Section 18.2 |		| 0x10 | retry_source_connection_id | Section 18.2 |
	+-------+-------------------------------------+---------------+		+-------+-------------------------------------+---------------+
	Table 6: Initial QUIC Transport Parameters Registry Entries		Table 6: Initial QUIC Transport Parameters Registry Entries
	Each value of the form "31 * N + 27" for integer values of N (that		Each value of the form "31 * N + 27" for integer values of N (that
	is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned		is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned
	by IANA and MUST NOT appear in the listing of assigned values.		by IANA and MUST NOT appear in the listing of assigned values.
	22.4. QUIC Frame Types Registry		22.4. QUIC Frame Types Registry
	skipping to change at page 171, line 10 ¶		skipping to change at line 7961 ¶
	In addition to the fields listed in Section 22.1.1, permanent		In addition to the fields listed in Section 22.1.1, permanent
	registrations in this registry MUST include the following fields:		registrations 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.
	+-------------+-----------------------+--------------+--------------+		+=======+===========================+================+==============+
	| Value | Code | Description | Specificatio |		|Value | Code |Description |Specification |
	| | | | n |		+=======+===========================+================+==============+
	+-------------+-----------------------+--------------+--------------+		|0x00 | NO_ERROR |No error |Section 20 |
	| 0x00 | NO_ERROR | No error | Section 20 |		+-------+---------------------------+----------------+--------------+
	| | | | |		|0x01 | INTERNAL_ERROR |Implementation |Section 20 |
	| 0x01 | INTERNAL_ERROR | Implementati | Section 20 |		| | |error | |
	| | | on error | |		+-------+---------------------------+----------------+--------------+
	| | | | |		|0x02 | CONNECTION_REFUSED |Server refuses a|Section 20 |
	| 0x02 | CONNECTION_REFUSED | Server | Section 20 |		| | |connection | |
	| | | refuses a | |		+-------+---------------------------+----------------+--------------+
	| | | connection | |		|0x03 | FLOW_CONTROL_ERROR |Flow control |Section 20 |
	| | | | |		| | |error | |
	| 0x03 | FLOW_CONTROL_ERROR | Flow control | Section 20 |		+-------+---------------------------+----------------+--------------+
	| | | error | |		|0x04 | STREAM_LIMIT_ERROR |Too many streams|Section 20 |
	| | | | |		| | |opened | |
	| 0x04 | STREAM_LIMIT_ERROR | Too many | Section 20 |		+-------+---------------------------+----------------+--------------+
	| | | streams | |		|0x05 | STREAM_STATE_ERROR |Frame received |Section 20 |
	| | | opened | |		| | |in invalid | |
	| | | | |		| | |stream state | |
	| 0x05 | STREAM_STATE_ERROR | Frame | Section 20 |		+-------+---------------------------+----------------+--------------+
	| | | received in | |		|0x06 | FINAL_SIZE_ERROR |Change to final |Section 20 |
	| | | invalid | |		| | |size | |
	| | | stream state | |		+-------+---------------------------+----------------+--------------+
	| | | | |		|0x07 | FRAME_ENCODING_ERROR |Frame encoding |Section 20 |
	| 0x06 | FINAL_SIZE_ERROR | Change to | Section 20 |		| | |error | |
	| | | final size | |		+-------+---------------------------+----------------+--------------+
	| | | | |		|0x08 | TRANSPORT_PARAMETER_ERROR |Error in |Section 20 |
	| 0x07 | FRAME_ENCODING_ERROR | Frame | Section 20 |		| | |transport | |
	| | | encoding | |		| | |parameters | |
	| | | error | |		+-------+---------------------------+----------------+--------------+
	| | | | |		|0x09 | CONNECTION_ID_LIMIT_ERROR |Too many |Section 20 |
	| 0x08 | TRANSPORT_PARAMETER_E | Error in | Section 20 |		| | |connection IDs | |
	| | RROR | transport | |		| | |received | |
	| | | parameters | |		+-------+---------------------------+----------------+--------------+
	| | | | |		|0x0a | PROTOCOL_VIOLATION |Generic protocol|Section 20 |
	| 0x09 | CONNECTION_ID_LIMIT_E | Too many | Section 20 |		| | |violation | |
	| | RROR | connection | |		+-------+---------------------------+----------------+--------------+
	| | | IDs received | |		|0x0b | INVALID_TOKEN |Invalid Token |Section 20 |
	| | | | |		| | |received | |
	| 0x0a | PROTOCOL_VIOLATION | Generic | Section 20 |		+-------+---------------------------+----------------+--------------+
	| | | protocol | |		|0x0c | APPLICATION_ERROR |Application |Section 20 |
	| | | violation | |		| | |error | |
	| | | | |		+-------+---------------------------+----------------+--------------+
	| 0x0b | INVALID_TOKEN | Invalid | Section 20 |		|0x0d | CRYPTO_BUFFER_EXCEEDED |CRYPTO data |Section 20 |
	| | | Token | |		| | |buffer | |
	| | | received | |		| | |overflowed | |
	| | | | |		+-------+---------------------------+----------------+--------------+
	| 0x0c | APPLICATION_ERROR | Application | Section 20 |		|0x0e | KEY_UPDATE_ERROR |Invalid packet |Section 20 |
	| | | error | |		| | |protection | |
	| | | | |		| | |update | |
	| 0x0d | CRYPTO_BUFFER_EXCEEDE | CRYPTO data | Section 20 |		+-------+---------------------------+----------------+--------------+
	| | D | buffer | |		|0x0f | AEAD_LIMIT_REACHED |Excessive use of|Section 20 |
	| | | overflowed | |		| | |packet | |
	| | | | |		| | |protection keys | |
	| 0x0e | KEY_UPDATE_ERROR | Invalid | Section 20 |		+-------+---------------------------+----------------+--------------+
	| | | packet | |		|0x10 | NO_VIABLE_PATH |No viable |Section 20 |
	| | | protection | |		| | |network path | |
	| | | update | |		| | |exists | |
	| | | | |		+-------+---------------------------+----------------+--------------+
	| 0x0f | AEAD_LIMIT_REACHED | Excessive | Section 20 |		|0x0100-| CRYPTO_ERROR |TLS alert code |Section 20 |
	| | | use of | |		|0x01ff | | | |
	| | | packet | |		+-------+---------------------------+----------------+--------------+
	| | | protection | |
	| | | keys | |
	| | | | |
	| 0x10 | NO_VIABLE_PATH | No viable | Section 20 |
	| | | network path | |
	| | | exists | |
	| | | | |
	| 0x0100-0x0 | CRYPTO_ERROR | TLS alert | Section 20 |
	| 1ff | | code | |
	+-------------+-----------------------+--------------+--------------+
	Table 7: Initial QUIC Transport Error Codes Registry Entries		Table 7: Initial QUIC Transport Error Codes Registry Entries
	23. References		23. References
	23.1. Normative References		23.1. Normative References
	[BCP38] Consisting of: [RFC2827],		[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	<https://www.rfc-editor.org/info/bcp38>.		Defeating Denial of Service Attacks which employ IP Source
			Address Spoofing", BCP 38, RFC 2827, May 2000.
	[DPLPMTUD]		<https://www.rfc-editor.org/info/bcp38>
	Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
	T. Voelker, "Packetization Layer Path MTU Discovery for		[DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
			Völker, "Packetization Layer Path MTU Discovery for
	Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,		Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
	September 2020, <https://www.rfc-editor.org/info/rfc8899>.		September 2020, <https://www.rfc-editor.org/info/rfc8899>.
	[EARLY-ASSIGN]		[EARLY-ASSIGN]
	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,
	skipping to change at page 173, line 24 ¶		skipping to change at line 8061 ¶
	[QUIC-INVARIANTS]		[QUIC-INVARIANTS]
	Thomson, M., "Version-Independent Properties of QUIC",		Thomson, M., "Version-Independent Properties of QUIC",
	RFC 8999, DOI 10.17487/RFC8999, May 2021,		RFC 8999, DOI 10.17487/RFC8999, May 2021,
	<https://www.rfc-editor.org/info/rfc8999>.		<https://www.rfc-editor.org/info/rfc8999>.
	[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", RFC 9002, DOI 10.17487/RFC9002,		and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
	May 2021, <https://www.rfc-editor.org/info/rfc9002>.		May 2021, <https://www.rfc-editor.org/info/rfc9002>.
	[QUIC-TLS]		[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
	Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
	QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,		QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
	<https://www.rfc-editor.org/info/rfc9001>.		<https://www.rfc-editor.org/info/rfc9001>.
	[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>.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
	May 2000, <https://www.rfc-editor.org/info/rfc2827>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<https://www.rfc-editor.org/info/rfc3168>.		<https://www.rfc-editor.org/info/rfc3168>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	2003, <https://www.rfc-editor.org/info/rfc3629>.		2003, <https://www.rfc-editor.org/info/rfc3629>.
	[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,		[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
	skipping to change at page 175, line 16 ¶		skipping to change at line 8141 ¶
	Alternative Services", RFC 7838, DOI 10.17487/RFC7838,		Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
	April 2016, <https://www.rfc-editor.org/info/rfc7838>.		April 2016, <https://www.rfc-editor.org/info/rfc7838>.
	[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust defenses		[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust defenses
	for cross-site request forgery", Proceedings of the 15th		for cross-site request forgery", Proceedings of the 15th
	ACM conference on Computer and communications security -		ACM conference on Computer and communications security -
	CCS '08, DOI 10.1145/1455770.1455782, 2008.		CCS '08, DOI 10.1145/1455770.1455782, 2008,
			<https://doi.org/10.1145/1455770.1455782>.
	[EARLY-DESIGN]		[EARLY-DESIGN]
	Roskind, J., "QUIC: Multiplexed Stream Transport Over		Roskind, J., "QUIC: Multiplexed Stream Transport Over
	UDP", December 2013, <https://docs.google.com/document/		UDP", 2 December 2013, <https://docs.google.com/document/
	d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/		d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/
	edit?usp=sharing>.		edit?usp=sharing>.
	[GATEWAY] Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S.,		[GATEWAY] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
	Sarolahti, P., and M. Kojo, "An experimental study of home		Sarolahti, P., and M. Kojo, "An experimental study of home
	gateway characteristics", DOI 10.1145/1879141.1879174,		gateway characteristics", Proceedings of the 10th ACM
	Proceedings of the 10th ACM SIGCOMM conference on Internet		SIGCOMM conference on Internet measurement - IMC '10,
	measurement - IMC '10, November 2010.		DOI 10.1145/1879141.1879174, November 2010,
			<https://doi.org/10.1145/1879141.1879174>.
	[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	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-11		Transport Protocol", Work in Progress, Internet-Draft,
	(work in progress), April 2021.		draft-ietf-quic-manageability-11, 21 April 2021,
			<https://tools.ietf.org/html/draft-ietf-quic-
			manageability-11>.
	[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>.
	[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
	and E. Lear, "Address Allocation for Private Internets",		J., and E. Lear, "Address Allocation for Private
	BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,		Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
	<https://www.rfc-editor.org/info/rfc1918>.		February 1996, <https://www.rfc-editor.org/info/rfc1918>.
	[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP		[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
	Selective Acknowledgment Options", RFC 2018,		Selective Acknowledgment Options", RFC 2018,
	DOI 10.17487/RFC2018, October 1996,		DOI 10.17487/RFC2018, October 1996,
	<https://www.rfc-editor.org/info/rfc2018>.		<https://www.rfc-editor.org/info/rfc2018>.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	DOI 10.17487/RFC2104, February 1997,		DOI 10.17487/RFC2104, February 1997,
	<https://www.rfc-editor.org/info/rfc2104>.		<https://www.rfc-editor.org/info/rfc2104>.
	skipping to change at page 177, line 22 ¶		skipping to change at line 8248 ¶
	Explicit Congestion Notification (ECN)", RFC 8087,		Explicit Congestion Notification (ECN)", RFC 8087,
	DOI 10.17487/RFC8087, March 2017,		DOI 10.17487/RFC8087, March 2017,
	<https://www.rfc-editor.org/info/rfc8087>.		<https://www.rfc-editor.org/info/rfc8087>.
	[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,		[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
	"Temporary Address Extensions for Stateless Address		"Temporary Address Extensions for Stateless Address
	Autoconfiguration in IPv6", RFC 8981,		Autoconfiguration in IPv6", RFC 8981,
	DOI 10.17487/RFC8981, February 2021,		DOI 10.17487/RFC8981, February 2021,
	<https://www.rfc-editor.org/info/rfc8981>.		<https://www.rfc-editor.org/info/rfc8981>.
	[SEC-CONS]		[SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003,		DOI 10.17487/RFC3552, July 2003,
	<https://www.rfc-editor.org/info/rfc3552>.		<https://www.rfc-editor.org/info/rfc3552>.
	[SLOWLORIS]		[SLOWLORIS]
	"RSnake" Hansen, R., "Welcome to Slowloris - the low		"RSnake" Hansen, R., "Welcome to Slowloris - the low
	bandwidth, yet greedy and poisonous HTTP client!", June		bandwidth, yet greedy and poisonous HTTP client!", June
	2009, <https://web.archive.org/web/20150315054838/		2009, <https://web.archive.org/web/20150315054838/
	http://ha.ckers.org/slowloris/>.		http://ha.ckers.org/slowloris/>.
	skipping to change at page 177, line 45 ¶		skipping to change at line 8270 ¶
	The pseudocode in this section describes sample algorithms. These		The pseudocode in this section describes sample algorithms. These
	algorithms are intended to be correct and clear, rather than being		algorithms are intended to be correct and clear, rather than being
	optimally performant.		optimally performant.
	The pseudocode segments in this section are licensed as Code		The pseudocode segments in this section are licensed as Code
	Components; see the Copyright Notice.		Components; see the Copyright Notice.
	A.1. Sample Variable-Length Integer Decoding		A.1. Sample Variable-Length Integer Decoding
	The pseudocode in Figure 43 shows how a variable-length integer can		The pseudocode in Figure 45 shows how a variable-length integer can
	be read from a stream of bytes. The function ReadVarint takes a		be read from a stream of bytes. The function ReadVarint takes a
	single argument -- a sequence of bytes, which can be read in network		single argument -- a sequence of bytes, which can be read in network
	byte order.		byte order.
	ReadVarint(data):		ReadVarint(data):
	// The length of variable-length integers is encoded in the		// The length of variable-length integers is encoded in the
	// first two bits of the first byte.		// first two bits of the first byte.
	v = data.next_byte()		v = data.next_byte()
	prefix = v >> 6		prefix = v >> 6
	length = 1 << prefix		length = 1 << prefix
	// Once the length is known, remove these bits and read any		// Once the length is known, remove these bits and read any
	// remaining bytes.		// remaining bytes.
	v = v & 0x3f		v = v & 0x3f
	repeat length-1 times:		repeat length-1 times:
	v = (v << 8) + data.next_byte()		v = (v << 8) + data.next_byte()
	return v		return v
	Figure 43: Sample Variable-Length Integer Decoding Algorithm		Figure 45: Sample Variable-Length Integer Decoding Algorithm
	For example, the eight-byte sequence 0xc2197c5eff14e88c decodes to		For example, the eight-byte sequence 0xc2197c5eff14e88c decodes to
	the decimal value 151,288,809,941,952,652; the four-byte sequence		the decimal value 151,288,809,941,952,652; the four-byte sequence
	0x9d7f3e7d decodes to 494,878,333; the two-byte sequence 0x7bbd		0x9d7f3e7d decodes to 494,878,333; the two-byte sequence 0x7bbd
	decodes to 15,293; and the single byte 0x25 decodes to 37 (as does		decodes to 15,293; and the single byte 0x25 decodes to 37 (as does
	the two-byte sequence 0x4025).		the two-byte sequence 0x4025).
	A.2. Sample Packet Number Encoding Algorithm		A.2. Sample Packet Number Encoding Algorithm
	The pseudocode in Figure 44 shows how an implementation can select an		The pseudocode in Figure 46 shows how an implementation can select an
	appropriate size for packet number encodings.		appropriate size for packet number encodings.
	The EncodePacketNumber function takes two arguments:		The EncodePacketNumber function takes two arguments:
	o full_pn is the full packet number of the packet being sent.		* full_pn is the full packet number of the packet being sent.
	o largest_acked is the largest packet number that has been		* largest_acked is the largest packet number that has been
	acknowledged by the peer in the current packet number space, if		acknowledged by the peer in the current packet number space, if
	any.		any.
	EncodePacketNumber(full_pn, largest_acked):		EncodePacketNumber(full_pn, largest_acked):
	// The number of bits must be at least one more		// The number of bits must be at least one more
	// than the base-2 logarithm of the number of contiguous		// than the base-2 logarithm of the number of contiguous
	// unacknowledged packet numbers, including the new packet.		// unacknowledged packet numbers, including the new packet.
	if largest_acked is None:		if largest_acked is None:
	num_unacked = full_pn + 1		num_unacked = full_pn + 1
	else:		else:
	num_unacked = full_pn - largest_acked		num_unacked = full_pn - largest_acked
	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 46: 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
	0xabe8b3 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 packet numbers. In order to represent at		29,519 (0x734f) outstanding packet numbers. In order to represent at
	least twice this range (59,038 packets, or 0xe69e), 16 bits are		least twice this range (59,038 packets, or 0xe69e), 16 bits are
	required.		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 uses
	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,222 packets, or 0x020096).		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 47 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		* 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.
	o truncated_pn is the value of the Packet Number field.		* truncated_pn is the value of the Packet Number field.
	o pn_nbits is the number of bits in the Packet Number field (8, 16,		* pn_nbits is the number of bits in the Packet Number field (8, 16,
	24, or 32).		24, or 32).
	DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):		DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
	expected_pn = largest_pn + 1		expected_pn = largest_pn + 1
	pn_win = 1 << pn_nbits		pn_win = 1 << pn_nbits
	pn_hwin = pn_win / 2		pn_hwin = pn_win / 2
	pn_mask = pn_win - 1		pn_mask = pn_win - 1
	// The incoming packet number should be greater than		// The incoming packet number should be greater than
	// expected_pn - pn_hwin and less than or equal to		// expected_pn - pn_hwin and less than or equal to
	// expected_pn + pn_hwin		// expected_pn + pn_hwin
	skipping to change at page 180, line 30 ¶		skipping to change at line 8379 ¶
	// Note the extra checks to prevent overflow and underflow.		// Note the extra checks to prevent overflow and underflow.
	candidate_pn = (expected_pn & ~pn_mask) | truncated_pn		candidate_pn = (expected_pn & ~pn_mask) | truncated_pn
	if candidate_pn <= expected_pn - pn_hwin and		if candidate_pn <= expected_pn - pn_hwin and
	candidate_pn < (1 << 62) - pn_win:		candidate_pn < (1 << 62) - pn_win:
	return candidate_pn + pn_win		return candidate_pn + pn_win
	if candidate_pn > expected_pn + pn_hwin and		if candidate_pn > expected_pn + pn_hwin and
	candidate_pn >= pn_win:		candidate_pn >= pn_win:
	return candidate_pn - pn_win		return candidate_pn - pn_win
	return candidate_pn		return candidate_pn
	Figure 45: Sample Packet Number Decoding Algorithm		Figure 47: Sample Packet Number Decoding Algorithm
	For example, if the highest successfully authenticated packet had a		For example, if the highest successfully authenticated packet had a
	packet number of 0xa82f30ea, then a packet containing a 16-bit value		packet number of 0xa82f30ea, then a packet containing a 16-bit value
	of 0x9b32 will be decoded as 0xa82f9b32.		of 0x9b32 will be decoded as 0xa82f9b32.
	A.4. Sample ECN Validation Algorithm		A.4. Sample ECN Validation Algorithm
	Each time an endpoint commences sending on a new network path, it		Each time an endpoint commences sending on a new network path, it
	determines whether the path supports ECN; see Section 13.4. If the		determines whether the path supports ECN; see Section 13.4. If the
	path supports ECN, the goal is to use ECN. Endpoints might also		path supports ECN, the goal is to use ECN. Endpoints might also
	skipping to change at page 181, line 41 ¶		skipping to change at line 8437 ¶
	Contributors		Contributors
	The original design and rationale behind this protocol draw		The original design and rationale behind this protocol draw
	significantly from work by Jim Roskind [EARLY-DESIGN].		significantly from work by Jim Roskind [EARLY-DESIGN].
	The IETF QUIC Working Group received an enormous amount of support		The IETF QUIC Working Group received an enormous amount of support
	from many people. The following people provided substantive		from many people. The following people provided substantive
	contributions to this document:		contributions to this document:
	o Alessandro Ghedini		* Alessandro Ghedini
			* Alyssa Wilk
	o Alyssa Wilk		* Antoine Delignat-Lavaud
			* Brian Trammell
	o Antoine Delignat-Lavaud		* Christian Huitema
	o Brian Trammell		* Colin Perkins
			* David Schinazi
	o Christian Huitema		* Dmitri Tikhonov
			* Eric Kinnear
	o Colin Perkins		* Eric Rescorla
			* Gorry Fairhurst
	o David Schinazi		* Ian Swett
			* Igor Lubashev
	o Dmitri Tikhonov		* 奥 一穂 (Kazuho Oku)
			* Lars Eggert
	o Eric Kinnear		* Lucas Pardue
			* Magnus Westerlund
	o Eric Rescorla		* Marten Seemann
			* Martin Duke
	o Gorry Fairhurst		* Mike Bishop
			* Mikkel Fahnøe Jørgensen
	o Ian Swett		* Mirja Kühlewind
			* Nick Banks
	o Igor Lubashev		* Nick Harper
			* Patrick McManus
	o Kazuho Oku		* Roberto Peon
			* Ryan Hamilton
	o Lars Eggert		* Subodh Iyengar
	o Lucas Pardue		* Tatsuhiro Tsujikawa
			* Ted Hardie
	o Magnus Westerlund		* Tom Jones
			* Victor Vasiliev
	o Marten Seemann
	o Martin Duke
	o Mike Bishop
	o Mikkel Fahnoee Joergensen
	o Mirja Kuehlewind
	o Nick Banks
	o Nick Harper
	o Patrick McManus
	o Roberto Peon
	o Ryan Hamilton
	o Subodh Iyengar
	o Tatsuhiro Tsujikawa
	o Ted Hardie
	o Tom Jones
	o Victor Vasiliev
	Authors' Addresses		Authors' Addresses
	Jana Iyengar (editor)		Jana Iyengar (editor)
	Fastly		Fastly
	Email: jri.ietf@gmail.com		Email: jri.ietf@gmail.com
	Martin Thomson (editor)		Martin Thomson (editor)
	Mozilla		Mozilla
End of changes. 251 change blocks.
	724 lines changed or deleted		687 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/