draft-ietf-quic-transport-09.txt   draft-ietf-quic-transport-10.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Google Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: August 1, 2018 Mozilla Expires: September 6, 2018 Mozilla
January 28, 2018 March 05, 2018
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-09 draft-ietf-quic-transport-10
Abstract Abstract
This document defines the core of the QUIC transport protocol. This This document defines the core of the QUIC transport protocol. This
document describes connection establishment, packet format, document describes connection establishment, packet format,
multiplexing and reliability. Accompanying documents describe the multiplexing and reliability. Accompanying documents describe the
cryptographic handshake and loss detection. cryptographic handshake and loss detection.
Note to Readers Note to Readers
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Notational Conventions . . . . . . . . . . . . . . . . . 6 2.1. Notational Conventions . . . . . . . . . . . . . . . . . 6
3. A QUIC Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. A QUIC Overview . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Low-Latency Connection Establishment . . . . . . . . . . 6 3.1. Low-Latency Connection Establishment . . . . . . . . . . 7
3.2. Stream Multiplexing . . . . . . . . . . . . . . . . . . . 7 3.2. Stream Multiplexing . . . . . . . . . . . . . . . . . . . 7
3.3. Rich Signaling for Congestion Control and Loss Recovery . 7 3.3. Rich Signaling for Congestion Control and Loss Recovery . 7
3.4. Stream and Connection Flow Control . . . . . . . . . . . 7 3.4. Stream and Connection Flow Control . . . . . . . . . . . 7
3.5. Authenticated and Encrypted Header and Payload . . . . . 8 3.5. Authenticated and Encrypted Header and Payload . . . . . 8
3.6. Connection Migration and Resilience to NAT Rebinding . . 8 3.6. Connection Migration and Resilience to NAT Rebinding . . 8
3.7. Version Negotiation . . . . . . . . . . . . . . . . . . . 8 3.7. Version Negotiation . . . . . . . . . . . . . . . . . . . 9
4. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Packet Types and Formats . . . . . . . . . . . . . . . . . . 9 5. Packet Types and Formats . . . . . . . . . . . . . . . . . . 10
5.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Version Negotiation Packet . . . . . . . . . . . . . . . 13 5.3. Version Negotiation Packet . . . . . . . . . . . . . . . 13
5.4. Cryptographic Handshake Packets . . . . . . . . . . . . . 14 5.4. Cryptographic Handshake Packets . . . . . . . . . . . . . 14
5.4.1. Initial Packet . . . . . . . . . . . . . . . . . . . 14 5.4.1. Initial Packet . . . . . . . . . . . . . . . . . . . 15
5.4.2. Retry Packet . . . . . . . . . . . . . . . . . . . . 15 5.4.2. Retry Packet . . . . . . . . . . . . . . . . . . . . 15
5.4.3. Handshake Packet . . . . . . . . . . . . . . . . . . 15 5.4.3. Handshake Packet . . . . . . . . . . . . . . . . . . 16
5.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 16 5.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 17
5.6. Connection ID . . . . . . . . . . . . . . . . . . . . . . 16 5.6. Connection ID . . . . . . . . . . . . . . . . . . . . . . 17
5.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 17 5.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 18
5.7.1. Initial Packet Number . . . . . . . . . . . . . . . . 18 5.7.1. Initial Packet Number . . . . . . . . . . . . . . . . 19
5.8. Handling Packets from Different Versions . . . . . . . . 18
6. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 19 6. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 19
7. Life of a Connection . . . . . . . . . . . . . . . . . . . . 20 7. Life of a Connection . . . . . . . . . . . . . . . . . . . . 21
7.1. Matching Packets to Connections . . . . . . . . . . . . . 21 7.1. Matching Packets to Connections . . . . . . . . . . . . . 22
7.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 22 7.1.1. Client Packet Handling . . . . . . . . . . . . . . . 22
7.2.1. Sending Version Negotiation Packets . . . . . . . . . 22 7.1.2. Server Packet Handling . . . . . . . . . . . . . . . 22
7.2.2. Handling Version Negotiation Packets . . . . . . . . 23 7.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 23
7.2.3. Using Reserved Versions . . . . . . . . . . . . . . . 23 7.2.1. Sending Version Negotiation Packets . . . . . . . . . 23
7.3. Cryptographic and Transport Handshake . . . . . . . . . . 24 7.2.2. Handling Version Negotiation Packets . . . . . . . . 24
7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 25 7.2.3. Using Reserved Versions . . . . . . . . . . . . . . . 24
7.4.1. Transport Parameter Definitions . . . . . . . . . . . 27 7.3. Cryptographic and Transport Handshake . . . . . . . . . . 25
7.4.2. Values of Transport Parameters for 0-RTT . . . . . . 29 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 26
7.4.3. New Transport Parameters . . . . . . . . . . . . . . 29 7.4.1. Transport Parameter Definitions . . . . . . . . . . . 28
7.4.4. Version Negotiation Validation . . . . . . . . . . . 30 7.4.2. Values of Transport Parameters for 0-RTT . . . . . . 30
7.5. Stateless Retries . . . . . . . . . . . . . . . . . . . . 31 7.4.3. New Transport Parameters . . . . . . . . . . . . . . 30
7.6. Proof of Source Address Ownership . . . . . . . . . . . . 32 7.4.4. Version Negotiation Validation . . . . . . . . . . . 31
7.6.1. Client Address Validation Procedure . . . . . . . . . 32 7.5. Stateless Retries . . . . . . . . . . . . . . . . . . . . 32
7.6.2. Address Validation on Session Resumption . . . . . . 33 7.6. Proof of Source Address Ownership . . . . . . . . . . . . 33
7.6.3. Address Validation Token Integrity . . . . . . . . . 34 7.6.1. Client Address Validation Procedure . . . . . . . . . 33
7.7. Connection Migration . . . . . . . . . . . . . . . . . . 34 7.6.2. Address Validation on Session Resumption . . . . . . 34
7.7.1. Privacy Implications of Connection Migration . . . . 35 7.6.3. Address Validation Token Integrity . . . . . . . . . 35
7.7.2. Address Validation for Migrated Connections . . . . . 36 7.7. Connection Migration . . . . . . . . . . . . . . . . . . 35
7.8. Spurious Connection Migrations . . . . . . . . . . . . . 37 7.7.1. Privacy Implications of Connection Migration . . . . 36
7.9. Connection Termination . . . . . . . . . . . . . . . . . 38 7.7.2. Address Validation for Migrated Connections . . . . . 37
7.9.1. Closing and Draining Connection States . . . . . . . 38 7.8. Spurious Connection Migrations . . . . . . . . . . . . . 39
7.9.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 40 7.9. Connection Termination . . . . . . . . . . . . . . . . . 40
7.9.3. Immediate Close . . . . . . . . . . . . . . . . . . . 40 7.9.1. Closing and Draining Connection States . . . . . . . 40
7.9.4. Stateless Reset . . . . . . . . . . . . . . . . . . . 41 7.9.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 41
8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 44 7.9.3. Immediate Close . . . . . . . . . . . . . . . . . . . 41
8.1. Variable-Length Integer Encoding . . . . . . . . . . . . 44 7.9.4. Stateless Reset . . . . . . . . . . . . . . . . . . . 42
8.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 45 8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 45
8.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 45 8.1. Variable-Length Integer Encoding . . . . . . . . . . . . 45
8.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 46 8.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 46
8.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 47 8.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 46
8.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 47 8.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 47
8.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 48 8.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 48
8.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 49 8.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 48
8.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 49 8.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 49
8.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 50 8.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 50
8.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 50
8.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 51
8.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 51 8.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 51
8.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 51 8.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 52
8.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 52 8.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 52
8.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 52 8.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 53
8.15. PONG Frame . . . . . . . . . . . . . . . . . . . . . . . 53 8.15. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 54
8.16. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 53 8.15.1. ACK Block Section . . . . . . . . . . . . . . . . . 55
8.16.1. ACK Block Section . . . . . . . . . . . . . . . . . 55 8.15.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 57
8.16.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 56 8.15.3. ACK Frames and Packet Protection . . . . . . . . . . 58
8.16.3. ACK Frames and Packet Protection . . . . . . . . . . 57 8.16. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 59
8.17. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 58 8.17. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 59
9. Packetization and Reliability . . . . . . . . . . . . . . . . 60 8.18. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 60
9.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 61 9. Packetization and Reliability . . . . . . . . . . . . . . . . 61
9.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 62 9.1. Packet Processing and Acknowledgment . . . . . . . . . . 62
9.2.1. Special Considerations for PMTU Discovery . . . . . . 63 9.2. Retransmission of Information . . . . . . . . . . . . . . 62
9.2.2. Special Considerations for Packetization Layer PMTU 9.3. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 64
Discovery . . . . . . . . . . . . . . . . . . . . . . 63 9.4. Path Maximum Transmission Unit . . . . . . . . . . . . . 64
9.4.1. Special Considerations for PMTU Discovery . . . . . . 65
10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 64 9.4.2. Special Considerations for Packetization Layer PMTU
10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 64 Discovery . . . . . . . . . . . . . . . . . . . . . . 66
10.2. Stream States . . . . . . . . . . . . . . . . . . . . . 65 10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 66
10.2.1. Send Stream States . . . . . . . . . . . . . . . . . 66 10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 67
10.2.2. Receive Stream States . . . . . . . . . . . . . . . 68 10.2. Stream States . . . . . . . . . . . . . . . . . . . . . 68
10.2.3. Permitted Frame Types . . . . . . . . . . . . . . . 71 10.2.1. Send Stream States . . . . . . . . . . . . . . . . . 69
10.2.4. Bidirectional Stream States . . . . . . . . . . . . 71 10.2.2. Receive Stream States . . . . . . . . . . . . . . . 71
10.3. Solicited State Transitions . . . . . . . . . . . . . . 72 10.2.3. Permitted Frame Types . . . . . . . . . . . . . . . 74
10.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 73 10.2.4. Bidirectional Stream States . . . . . . . . . . . . 74
10.5. Sending and Receiving Data . . . . . . . . . . . . . . . 74 10.3. Solicited State Transitions . . . . . . . . . . . . . . 75
10.6. Stream Prioritization . . . . . . . . . . . . . . . . . 74 10.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 76
11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 75 10.5. Sending and Receiving Data . . . . . . . . . . . . . . . 77
11.1. Edge Cases and Other Considerations . . . . . . . . . . 76 10.6. Stream Prioritization . . . . . . . . . . . . . . . . . 77
11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 77 11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 78
11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 77 11.1. Edge Cases and Other Considerations . . . . . . . . . . 79
11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 78 11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 80
11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 78 11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 80
11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 78 11.1.3. Handshake Exemption . . . . . . . . . . . . . . . . 81
12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 79 11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 81
12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 79 11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 81
12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 80 11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 82
12.3. Transport Error Codes . . . . . . . . . . . . . . . . . 80 12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 82
12.4. Application Protocol Error Codes . . . . . . . . . . . . 82 12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 83
13. Security and Privacy Considerations . . . . . . . . . . . . . 82 12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 83
13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 82 12.3. Transport Error Codes . . . . . . . . . . . . . . . . . 84
13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 83 12.4. Application Protocol Error Codes . . . . . . . . . . . . 85
13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 83 13. Security and Privacy Considerations . . . . . . . . . . . . . 85
13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 83 13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 86
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 86
14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 84 13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 87
14.2. QUIC Transport Error Codes Registry . . . . . . . . . . 85 13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 87
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
15.1. Normative References . . . . . . . . . . . . . . . . . . 88 14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 87
15.2. Informative References . . . . . . . . . . . . . . . . . 89 14.2. QUIC Transport Error Codes Registry . . . . . . . . . . 89
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 90 15.1. Normative References . . . . . . . . . . . . . . . . . . 90
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 90 15.2. Informative References . . . . . . . . . . . . . . . . . 92
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 91 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.1. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 91 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 93
C.2. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 91 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 93
C.3. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 92 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 93
C.4. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 93 C.1. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 94
C.5. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 93 C.2. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 94
C.6. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 94 C.3. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 95
C.7. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 94 C.4. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 96
C.8. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 95 C.5. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 96
C.9. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 97 C.6. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 96
C.10. Since draft-hamilton-quic-transport-protocol-01 . . . . . 97 C.7. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 97
C.8. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 97
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97 C.9. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 98
C.10. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 100
C.11. Since draft-hamilton-quic-transport-protocol-01 . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
1. Introduction 1. Introduction
QUIC is a multiplexed and secure transport protocol that runs on top QUIC is a multiplexed and secure transport protocol that runs on top
of UDP. QUIC aims to provide a flexible set of features that allow of UDP. QUIC aims to provide a flexible set of features that allow
it to be a general-purpose transport for multiple applications. it to be a general-purpose transport for multiple applications.
QUIC implements techniques learned from experience with TCP, SCTP and QUIC implements techniques learned from experience with TCP, SCTP and
other transport protocols. QUIC uses UDP as substrate so as to not other transport protocols. QUIC uses UDP as substrate so as to not
require changes to legacy client operating systems and middleboxes to require changes to legacy client operating systems and middleboxes to
skipping to change at page 5, line 28 skipping to change at page 5, line 33
the protocol to evolve without incurring a dependency on upgrades to the protocol to evolve without incurring a dependency on upgrades to
middleboxes. This document describes the core QUIC protocol, middleboxes. This document describes the core QUIC protocol,
including the conceptual design, wire format, and mechanisms of the including the conceptual design, wire format, and mechanisms of the
QUIC protocol for connection establishment, stream multiplexing, QUIC protocol for connection establishment, stream multiplexing,
stream and connection-level flow control, and data reliability. stream and connection-level flow control, and data reliability.
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 1.3 for key negotiation control [QUIC-RECOVERY], and the use of TLS 1.3 for key negotiation
[QUIC-TLS]. [QUIC-TLS].
QUIC version 1 conforms to the protocol invariants in
[QUIC-INVARIANTS].
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Definitions of terms that are used in this document: Definitions of terms that are used in this document:
skipping to change at page 9, line 5 skipping to change at page 9, line 19
described in Section 7.2. described in Section 7.2.
4. Versions 4. 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 to this
version. The properties of QUIC that are guaranteed to be consistent
across all versions of the protocol are described in
[QUIC-INVARIANTS].
Version 0x00000001 of QUIC uses TLS as a cryptographic handshake Version 0x00000001 of QUIC uses TLS as a cryptographic handshake
protocol, as described in [QUIC-TLS]. protocol, as described in [QUIC-TLS].
Versions with the most significant 16 bits of the version number Versions with the most significant 16 bits of the version number
cleared are reserved for use in future IETF consensus documents. cleared are reserved for use in future IETF consensus documents.
Versions that follow the pattern 0x?a?a?a?a are reserved for use in Versions that follow the pattern 0x?a?a?a?a are reserved for use in
forcing version negotiation to be exercised. That is, any version forcing version negotiation to be exercised. That is, any version
number where the low four bits of all octets is 1010 (in binary). A number where the low four bits of all octets is 1010 (in binary). A
client or server MAY advertise support for any of these reserved client or server MAY advertise support for any of these reserved
skipping to change at page 11, line 24 skipping to change at page 11, line 44
| 0x7D | Handshake | Section 5.4.3 | | 0x7D | Handshake | Section 5.4.3 |
| | | | | | | |
| 0x7C | 0-RTT Protected | Section 5.5 | | 0x7C | 0-RTT Protected | Section 5.5 |
+------+-----------------+---------------+ +------+-----------------+---------------+
Table 1: Long Header Packet Types Table 1: Long Header Packet Types
The header form, packet type, connection ID, packet number and The header form, packet type, connection ID, packet number and
version fields of a long header packet are version-independent. The version fields of a long header packet are version-independent. The
types of packets defined in Table 1 are version-specific. See types of packets defined in Table 1 are version-specific. See
Section 5.8 for details on how packets from different versions of [QUIC-INVARIANTS] for details on how packets from different versions
QUIC are interpreted. 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
version and packet type. Type-specific semantics for this version version and packet type. Type-specific semantics for this version
are described in the following sections. are described in the following sections.
5.2. Short Header 5.2. Short Header
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|C|K| Type (5)| |0|C|K|1|0|T T T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ [Connection ID (64)] + + [Connection ID (64)] +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/32) ... | Packet Number (8/16/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Payload (*) ... | Protected Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 20 skipping to change at page 12, line 41
Connection ID field is present; if set to 1, the Connection ID Connection ID field is present; if set to 1, the Connection ID
field is omitted. The Connection ID field can only be omitted if field is omitted. The Connection ID field can only be omitted if
the omit_connection_id transport parameter (Section 7.4.1) is the omit_connection_id transport parameter (Section 7.4.1) is
specified by the intended recipient of the packet. specified by the intended recipient of the packet.
Key Phase Bit: The third bit (0x20) of octet 0 indicates the key Key Phase Bit: The third bit (0x20) of octet 0 indicates the key
phase, which allows a recipient of a packet to identify the packet phase, which allows a recipient of a packet to identify the packet
protection keys that are used to protect the packet. See protection keys that are used to protect the packet. See
[QUIC-TLS] for details. [QUIC-TLS] for details.
Short Packet Type: The remaining 5 bits of octet 0 include one of 32 [[Editor's Note: this section should be removed and the bit
definitions changed before this draft goes to the IESG.]]
Fourth bit: The fourth bit (0x10) of octet 0 is set to 1.
[[Editor's Note: this section should be removed and the bit
definitions changed before this draft goes to the IESG.]]
Google QUIC Demultipexing Bit: The fifth bit (0x8) of octet 0 is set
to 0. This allows implementations of Google QUIC to distinguish
Google QUIC packets from short header packets sent by a client
because Google QUIC servers expect the connection ID to always be
present. The special interpretation of this bit SHOULD be removed
from this specification when Google QUIC has finished
transitioning to the new header format.
Short Packet Type: The remaining 3 bits of octet 0 include one of 8
packet types. Table 2 lists the types that are defined for short packet types. Table 2 lists the types that are defined for short
packets. packets.
Connection ID: If the Omit Connection ID Flag is not set, a Connection ID: If the Omit Connection ID Flag is not set, a
connection ID occupies octets 1 through 8 of the packet. See connection ID occupies octets 1 through 8 of the packet. See
Section 5.6 for more details. Section 5.6 for more details.
Packet Number: The length of the packet number field depends on the Packet Number: The length of the packet number field depends on the
packet type. This field can be 1, 2 or 4 octets long depending on packet type. This field can be 1, 2 or 4 octets long depending on
the short packet type. the short packet type.
skipping to change at page 12, line 42 skipping to change at page 13, line 30
Protected Payload: Packets with a short header always include a Protected Payload: Packets with a short header always include a
1-RTT protected payload. 1-RTT protected payload.
The packet type in a short header currently determines only the size The packet type in a short header currently determines only the size
of the packet number field. Additional types can be used to signal of the packet number field. Additional types can be used to signal
the presence of other fields. the presence of other fields.
+------+--------------------+ +------+--------------------+
| Type | Packet Number Size | | Type | Packet Number Size |
+------+--------------------+ +------+--------------------+
| 0x1F | 1 octet | | 0x0 | 1 octet |
| | | | | |
| 0x1E | 2 octets | | 0x1 | 2 octets |
| | | | | |
| 0x1D | 4 octets | | 0x2 | 4 octets |
+------+--------------------+ +------+--------------------+
Table 2: Short Header Packet Types Table 2: Short Header Packet Types
The header form, omit connection ID flag, and connection ID of a The header form, omit connection ID flag, and connection ID of a
short header packet are version-independent. The remaining fields short header packet are version-independent. The remaining fields
are specific to the selected QUIC version. See Section 5.8 for are specific to the selected QUIC version. See [QUIC-INVARIANTS] for
details on how packets from different versions of QUIC are details on how packets from different versions of QUIC are
interpreted. interpreted.
5.3. Version Negotiation Packet 5.3. Version Negotiation Packet
A Version Negotiation packet is inherently not version-specific, and A Version Negotiation packet is inherently not version-specific, and
does not use the packet headers defined above. Upon receipt by a does not use the packet headers defined above. Upon receipt by a
client, it will appear to be a packet using the long header, but will client, it will appear to be a packet using the long header, but will
be identified as a Version Negotiation packet based on the Version be identified as a Version Negotiation packet based on the Version
field. field.
skipping to change at page 14, line 41 skipping to change at page 15, line 28
The client populates the connection ID field with randomly selected The client populates the connection ID field with randomly selected
values, unless it has received a packet from the server. If the values, unless it has received a packet from the server. If the
client has received a packet from the server, the connection ID field client has received a packet from the server, the connection ID field
uses the value provided by the server. uses the value provided by the server.
The first Initial packet that is sent by a client contains a The first Initial packet that is sent by a client contains a
randomized packet number. All subsequent packets contain a packet randomized packet number. All subsequent packets contain a packet
number that is incremented by one, see (Section 5.7). number that is incremented by one, see (Section 5.7).
The payload of a Initial packet consists of a STREAM frame (or The payload of an Initial packet consists of a STREAM frame (or
frames) for stream 0 containing a cryptographic handshake message, frames) for stream 0 containing a cryptographic handshake message,
with enough PADDING frames that the packet is at least 1200 octets with enough PADDING frames that the packet is at least 1200 octets
(see Section 9). The stream in this packet always starts at an (see Section 9). The stream in this packet always starts at an
offset of 0 (see Section 7.5) and the complete cryptographic offset of 0 (see Section 7.5) and the complete cryptographic
handshake message MUST fit in a single packet (see Section 7.3). handshake message MUST fit in a single packet (see Section 7.3).
The client uses the Initial packet type for any packet that contains The client uses the Initial packet type for any packet that contains
an initial cryptographic handshake message. This includes all cases an initial cryptographic handshake message. This includes all cases
where a new packet containing the initial cryptographic message needs where a new packet containing the initial cryptographic message needs
to be created, this includes the packets sent after receiving a to be created, this includes the packets sent after receiving a
skipping to change at page 16, line 12 skipping to change at page 16, line 49
The connection ID field in a Handshake packet contains a connection The connection ID field in a Handshake packet contains a connection
ID that is chosen by the server (see Section 5.6). ID that is chosen by the server (see Section 5.6).
The first Handshake packet sent by a server contains a randomized The first Handshake packet sent by a server contains a randomized
packet number. This value is increased for each subsequent packet packet number. This value is increased for each subsequent packet
sent by the server as described in Section 5.7. The client sent by the server as described in Section 5.7. The client
increments the packet number from its previous packet by one for each increments the packet number from its previous packet by one for each
Handshake packet that it sends (which might be an Initial, 0-RTT Handshake packet that it sends (which might be an Initial, 0-RTT
Protected, or Handshake packet). Protected, or Handshake packet).
Servers MUST NOT send more than three Handshake packets without
receiving a packet from a verified source address. Source addresses
can be verified through an address validation token, receipt of the
final cryptographic message from the client, or by receiving a valid
PATH_RESPONSE frame from the client.
If the server expects to generate more than three Handshake packets
in response to an Initial packet, it SHOULD include a PATH_CHALLENGE
frame in each Handshake packet that it sends. After receiving at
least one valid PATH_RESPONSE frame, the server can send its
remaining Handshake packets. Servers can instead perform address
validation using a Retry packet; this requires less state on the
server, but could involve additional computational effort depending
on implementation choices.
The payload of this packet contains STREAM frames and could contain The payload of this packet contains STREAM frames and could contain
PADDING and ACK frames. PADDING, ACK, PATH_CHALLENGE, or PATH_RESPONSE frames.
5.5. Protected Packets 5.5. Protected Packets
Packets that are protected with 0-RTT keys are sent with long Packets that are protected with 0-RTT keys are sent with long
headers; all packets protected with 1-RTT keys are sent with short headers; all packets protected with 1-RTT keys are sent with short
headers. The different packet types explicitly indicate the headers. The different packet types explicitly indicate the
encryption level and therefore the keys that are used to remove encryption level and therefore the keys that are used to remove
packet protection. packet protection.
Packets protected with 0-RTT keys use a type value of 0x7C. The Packets protected with 0-RTT keys use a type value of 0x7C. The
skipping to change at page 18, line 18 skipping to change at page 19, line 24
As a result, the size of the packet number encoding is at least one As a result, the size of the packet number encoding is at least one
more than the base 2 logarithm of the number of contiguous more than the base 2 logarithm of the number of contiguous
unacknowledged packet numbers, including the new packet. unacknowledged packet numbers, including the new packet.
For example, if an endpoint has received an acknowledgment for packet For example, if an endpoint has received an acknowledgment for packet
0x6afa2f, sending a packet with a number of 0x6b4264 requires a 0x6afa2f, sending a packet with a number of 0x6b4264 requires a
16-bit or larger packet number encoding; whereas a 32-bit packet 16-bit or larger packet number encoding; whereas a 32-bit packet
number is needed to send a packet with a number of 0x6bc107. number is needed to send a packet with a number of 0x6bc107.
Version Negotiation (Section 5.3) and Retry (Section 5.4.2) packets A Version Negotiation packet (Section 5.3) does not include a packet
have special rules for populating the packet number field. number. The Retry packet (Section 5.4.2) has special rules for
populating the packet number field.
5.7.1. Initial Packet Number 5.7.1. Initial Packet Number
The initial value for packet number MUST be selected randomly from a The initial value for packet number MUST be selected randomly from a
range between 0 and 2^32 - 1025 (inclusive). This value is selected range between 0 and 2^32 - 1025 (inclusive). This value is selected
so that Initial and Handshake packets exercise as many possible so that Initial and Handshake packets exercise as many possible
values for the Packet Number field as possible. values for the Packet Number field as possible.
Limiting the range allows both for loss of packets and for any Limiting the range allows both for loss of packets and for any
stateless exchanges. Packet numbers are incremented for subsequent stateless exchanges. Packet numbers are incremented for subsequent
packets, but packet loss and stateless handling can both mean that packets, but packet loss and stateless handling can both mean that
the first packet sent by an endpoint isn't necessarily the first the first packet sent by an endpoint isn't necessarily the first
packet received by its peer. The first packet received by a peer packet received by its peer. The first packet received by a peer
cannot be 2^32 or greater or the recipient will incorrectly assume a cannot be 2^32 or greater or the recipient will incorrectly assume a
packet number that is 2^32 values lower and discard the packet. packet number that is 2^32 values lower and discard the packet.
Use of a secure random number generator [RFC4086] is not necessary Use of a secure random number generator [RFC4086] is not necessary
for generating the initial packet number, nor is it necessary that for generating the initial packet number, nor is it necessary that
the value be uniformly distributed. the value be uniformly distributed.
5.8. Handling Packets from Different Versions
Between different versions the following things are guaranteed to
remain constant:
o the location of the header form flag,
o the location of the Omit Connection ID flag in short headers,
o the location and size of the Connection ID field in both header
forms,
o the location and size of the Version field in long headers,
o the format and semantics of the Version Negotiation packet.
Implementations MUST assume that an unsupported version uses an
unknown packet format. All other fields MUST be ignored when
processing a packet that contains an unsupported version.
6. Frames and Frame Types 6. Frames and Frame Types
The payload of all packets, after removing packet protection, The payload of all packets, after removing packet protection,
consists of a sequence of frames, as shown in Figure 4. Version consists of a sequence of frames, as shown in Figure 4. Version
Negotiation and Stateless Reset do not contain frames. Negotiation and Stateless Reset do not contain frames.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame 1 (*) ... | Frame 1 (*) ...
skipping to change at page 20, line 34 skipping to change at page 21, line 34
| 0x08 | BLOCKED | Section 8.10 | | 0x08 | BLOCKED | Section 8.10 |
| | | | | | | |
| 0x09 | STREAM_BLOCKED | Section 8.11 | | 0x09 | STREAM_BLOCKED | Section 8.11 |
| | | | | | | |
| 0x0a | STREAM_ID_BLOCKED | Section 8.12 | | 0x0a | STREAM_ID_BLOCKED | Section 8.12 |
| | | | | | | |
| 0x0b | NEW_CONNECTION_ID | Section 8.13 | | 0x0b | NEW_CONNECTION_ID | Section 8.13 |
| | | | | | | |
| 0x0c | STOP_SENDING | Section 8.14 | | 0x0c | STOP_SENDING | Section 8.14 |
| | | | | | | |
| 0x0d | PONG | Section 8.15 | | 0x0d | ACK | Section 8.15 |
| | | | | | | |
| 0x0e | ACK | Section 8.16 | | 0x0e | PATH_CHALLENGE | Section 8.16 |
| | | | | | | |
| 0x10 - 0x17 | STREAM | Section 8.17 | | 0x0f | PATH_RESPONSE | Section 8.17 |
| | | |
| 0x10 - 0x17 | STREAM | Section 8.18 |
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
Table 3: Frame Types Table 3: Frame Types
7. Life of a Connection 7. Life of a Connection
A QUIC connection is a single conversation between two QUIC A QUIC connection is a single conversation between two QUIC
endpoints. QUIC's connection establishment intertwines version endpoints. QUIC's connection establishment intertwines version
negotiation with the cryptographic and transport handshakes to reduce negotiation with the cryptographic and transport handshakes to reduce
connection establishment latency, as described in Section 7.3. Once connection establishment latency, as described in Section 7.3. Once
established, a connection may migrate to a different IP or port at established, a connection may migrate to a different IP or port at
either endpoint, due to NAT rebinding or mobility, as described in either endpoint, due to NAT rebinding or mobility, as described in
Section 7.7. Finally a connection may be terminated by either Section 7.7. Finally a connection may be terminated by either
endpoint, as described in Section 7.9. endpoint, as described in Section 7.9.
7.1. Matching Packets to Connections 7.1. Matching Packets to Connections
Incoming packets are classified on receipt. Packets can either be Incoming packets are classified on receipt. Packets can either be
associated with an existing connection, be discarded, or - for associated with an existing connection, or - for servers -
servers - potentially create a new connection. potentially create a new connection.
Packets that can be associated with an existing connection are Hosts try to associate the packet with an existing connection. If
handled according to the current state of that connection. Packets the packet has a connection ID corresponding to an existing
are associated with existing connections using connection ID if it is connection, QUIC processes that packet accordingly. Note that a
present; this might include connection IDs that were advertised using NEW_CONNECTION_ID frame (Section 8.13) would associate more than one
NEW_CONNECTION_ID (Section 8.13). Packets without connection IDs and connection ID with a connection.
long-form packets for connections that have incomplete cryptographic
handshakes are associated with an existing connection using the tuple
of source and destination IP addresses and ports.
A packet that uses the short header could be associated with an If there is no connection ID, but the packet matches the address/port
existing connection with an incomplete cryptographic handshake. Such tuple of a connection where the host did not require connection IDs,
a packet could be a valid packet that has been reordered with respect QUIC processes the packet as part of that connection. Endpoints MUST
to the long-form packets that will complete the cryptographic drop packets that omit connection IDs if they do not meet both of
handshake. This might happen after the final set of cryptographic these criteria.
handshake messages from either peer. These packets are expected to
be correlated with a connection using the tuple of IP addresses and
ports. Packets that might be reordered in this fashion SHOULD be
buffered in anticipation of the handshake completing.
0-RTT packets might be received prior to a Client Initial packet at a 7.1.1. Client Packet Handling
server. If the version of these packets is acceptable to the server,
it MAY buffer these packets in anticipation of receiving a reordered
Client Initial packet.
Buffering ensures that data is not lost, which improves performance; If a client receives a packet with an unknown connection ID, and it
conversely, discarding these packets could create false loss signals matches the tuple of a connection with no received packets, it is a
for the congestion controllers. However, limiting the number and reply to an Initial packet with a server-generated connection ID and
size of buffered packets might be needed to prevent exposure to will be processed accordingly. Clients SHOULD discard any packets
denial of service. with new connection IDs that do not meet these criteria.
For clients, any packet that cannot be associated with an existing Note that a successfully associated packet may be a Version
connection SHOULD be discarded if it is not buffered. Discarded Negotiation packet, which is handled in accordance with
packets MAY be logged for diagnostic or security purposes. Section 7.2.2.
For servers, packets that aren't associated with a connection Due to packet reordering or loss, clients might receive packets for a
potentially create a new connection. However, only packets that use connection encrypted with a key it has not yet computed. Clients MAY
the long packet header and that are at least the minimum size defined drop these packets, or MAY buffer them in anticipation of later
for the protocol version can be initial packets. A server MAY packets that allow it to compute the key.
discard packets with a short header or packets that are smaller than
the smallest minimum size for any version that the server supports.
A server that discards a packet that cannot be associated with a
connection MAY also generate a stateless reset (Section 7.9.4).
This version of QUIC defines a minimum size for initial packets of 7.1.2. Server Packet Handling
1200 octets (see Section 9). Versions of QUIC that define smaller
minimum initial packet sizes need to be aware that initial packets
will be discarded without action by servers that only support
versions with larger minimums. Clients that support multiple QUIC
versions can avoid this problem by ensuring that they increase the
size of their initial packets to the largest minimum size across all
of the QUIC versions they support. Servers need to recognize initial
packets that are the minimum size of all QUIC versions they support.
7.2. Version Negotiation If a server receives a packet that has an unsupported version and
sufficient length to be an Initial packet for some version supported
by the server, it SHOULD send a Version Negotiation packet as
described in Section 7.2.1. Servers MAY rate control these packets
to avoid storms of Version Negotiation packets.
QUIC's connection establishment begins with version negotiation, Servers MUST drop other packets that contain unsupported versions.
since all communication between the endpoints, including packet and
frame formats, relies on the two endpoints agreeing on a version.
A QUIC connection begins with a client sending an Initial packet Packets with a supported version, or no version field, are matched to
(Section 5.4.1). The details of the handshake mechanisms are a connection as described in Section 7.1. If not matched, the server
described in Section 7.3, but any Initial packet sent from the client continues below.
to the server MUST use the long header format - which includes the
version of the protocol being used - and they MUST be padded to at
least 1200 octets.
The server receives this packet and determines whether it potentially If the packet is an Initial packet fully conforming with the
creates a new connection (see Section 7.1). If the packet might specification, the server proceeds with the handshake (Section 7.3).
generate a new connection, the server then checks whether it This commits the server to the version that the client selected.
understands the version that the client has selected.
If the packet contains a version that is acceptable to the server, If a server isn't currently accepting any new connections, it SHOULD
the server proceeds with the handshake (Section 7.3). This commits send a Handshake packet containing a CONNECTION_CLOSE frame with
the server to the version that the client selected. error code SERVER_BUSY.
If the packet is a 0-RTT packet, the server MAY buffer a limited
number of these packets in anticipation of a late-arriving Initial
Packet. Clients are forbidden from sending Handshake packets prior
to receiving a server response, so servers SHOULD ignore any such
packets.
Servers MUST drop incoming packets under all other circumstances.
They SHOULD send a Stateless Reset (Section 7.9.4) if a connection ID
is present in the header.
7.2. Version Negotiation
Version negotiation ensures that client and server agree to a QUIC
version that is mutually supported. A server sends a Version
Negotiation packet in response to each packet that might initiate a
new connection, see Section 7.1 for details.
The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet. Clients that support
multiple QUIC versions SHOULD pad their Initial packets to reflect
the largest minimum Initial packet size of all their versions. This
ensures that that the server responds if there are any mutually
supported versions.
7.2.1. Sending Version Negotiation Packets 7.2.1. Sending Version Negotiation Packets
If the version selected by the client is not acceptable to the If the version selected by the client is not acceptable to the
server, the server responds with a Version Negotiation packet server, the server responds with a Version Negotiation packet
(Section 5.3). This includes a list of versions that the server will (Section 5.3). This includes a list of versions that the server will
accept. accept.
A server sends a Version Negotiation packet for any packet with an This system allows a server to process packets with unsupported
unacceptable version if that packet could create a new connection. versions without retaining state. Though either the Initial packet
This allows a server to process packets with unsupported versions or the Version Negotiation packet that is sent in response could be
without retaining state. Though either the Client Initial packet or
the version negotiation packet that is sent in response could be
lost, the client will send new packets until it successfully receives lost, the client will send new packets until it successfully receives
a response or it abandons the connection attempt. a response or it abandons the connection attempt.
7.2.2. Handling Version Negotiation Packets 7.2.2. Handling Version Negotiation Packets
When the client receives a Version Negotiation packet, it first When the client receives a Version Negotiation packet, it first
checks that the connection ID matches the connection ID the client checks that the connection ID matches the connection ID the client
sent. If this check fails, the packet MUST be discarded. sent. If this check fails, the packet MUST be discarded.
Once the Version Negotiation packet is determined to be valid, the Once the Version Negotiation packet is determined to be valid, the
skipping to change at page 28, line 43 skipping to change at page 29, line 43
max_packet_size (0x0005): The maximum packet size parameter places a max_packet_size (0x0005): The maximum packet size parameter places a
limit on the size of packets that the endpoint is willing to limit on the size of packets that the endpoint is willing to
receive, encoded as an unsigned 16-bit integer. This indicates receive, encoded as an unsigned 16-bit integer. This indicates
that packets larger than this limit will be dropped. The default that packets larger than this limit will be dropped. The default
for this parameter is the maximum permitted UDP payload of 65527. for this parameter is the maximum permitted UDP payload of 65527.
Values below 1200 are invalid. This limit only applies to Values below 1200 are invalid. This limit only applies to
protected packets (Section 5.5). protected packets (Section 5.5).
ack_delay_exponent (0x0007): An 8-bit unsigned integer value ack_delay_exponent (0x0007): An 8-bit unsigned integer value
indicating an exponent used to decode the ACK Delay field in the indicating an exponent used to decode the ACK Delay field in the
ACK frame, see Section 8.16. If this value is absent, a default ACK frame, see Section 8.15. If this value is absent, a default
value of 3 is assumed (indicating a multiplier of 8). The default value of 3 is assumed (indicating a multiplier of 8). The default
value is also used for ACK frames that are sent in Initial, value is also used for ACK frames that are sent in Initial,
Handshake, and Retry packets. Values above 20 are invalid. Handshake, and Retry packets. Values above 20 are invalid.
7.4.2. Values of Transport Parameters for 0-RTT 7.4.2. Values of Transport Parameters for 0-RTT
A client that attempts to send 0-RTT data MUST remember the transport A client that attempts to send 0-RTT data MUST remember the transport
parameters used by the server. The transport parameters that the parameters used by the server. The transport parameters that the
server advertises during connection establishment apply to all server advertises during connection establishment apply to all
connections that are resumed using the keying material established connections that are resumed using the keying material established
skipping to change at page 30, line 22 skipping to change at page 31, line 22
fields that encode version information. These parameters are used to fields that encode version information. These parameters are used to
retroactively authenticate the choice of version (see Section 7.2). retroactively authenticate the choice of version (see Section 7.2).
The cryptographic handshake provides integrity protection for the The cryptographic handshake provides integrity protection for the
negotiated version as part of the transport parameters (see negotiated version as part of the transport parameters (see
Section 7.4). As a result, attacks on version negotiation by an Section 7.4). As a result, attacks on version negotiation by an
attacker can be detected. attacker can be detected.
The client includes the initial_version field in its transport The client includes the initial_version field in its transport
parameters. The initial_version is the version that the client parameters. The initial_version is the version that the client
initially attempted to use. If the server did not send a version initially attempted to use. If the server did not send a Version
negotiation packet Section 5.3, this will be identical to the Negotiation packet Section 5.3, this will be identical to the
negotiated_version field in the server transport parameters. negotiated_version field in the server transport parameters.
A server that processes all packets in a stateful fashion can A server that processes all packets in a stateful fashion can
remember how version negotiation was performed and validate the remember how version negotiation was performed and validate the
initial_version value. initial_version value.
A server that does not maintain state for every packet it receives A server that does not maintain state for every packet it receives
(i.e., a stateless server) uses a different process. If the (i.e., a stateless server) uses a different process. If the
initial_version matches the version of QUIC that is in use, a initial_version matches the version of QUIC that is in use, a
stateless server can accept the value. stateless server can accept the value.
If the initial_version is different from the version of QUIC that is If the initial_version is different from the version of QUIC that is
in use, a stateless server MUST check that it would have sent a in use, a stateless server MUST check that it would have sent a
version negotiation packet if it had received a packet with the Version Negotiation packet if it had received a packet with the
indicated initial_version. If a server would have accepted the indicated initial_version. If a server would have accepted the
version included in the initial_version and the value differs from version included in the initial_version and the value differs from
the QUIC version that is in use, the server MUST terminate the the QUIC version that is in use, the server MUST terminate the
connection with a VERSION_NEGOTIATION_ERROR error. connection with a VERSION_NEGOTIATION_ERROR error.
The server includes both the version of QUIC that is in use and a The server includes both the version of QUIC that is in use and a
list of the QUIC versions that the server supports. list of the QUIC versions that the server supports.
The negotiated_version field is the version that is in use. This The negotiated_version field is the version that is in use. This
MUST be set by the server to the value that is on the Initial packet MUST be set by the server to the value that is on the Initial packet
skipping to change at page 36, line 45 skipping to change at page 37, line 45
proves that it is receiving packets at the new address and consents proves that it is receiving packets at the new address and consents
to receive data. to receive data.
Prior to validating the new remote address, and endpoint MUST limit Prior to validating the new remote address, and endpoint MUST limit
the amount of data and packets that it sends to its peer. At a the amount of data and packets that it sends to its peer. At a
minimum, this needs to consider the possibility that packets are sent minimum, this needs to consider the possibility that packets are sent
without congestion feedback. without congestion feedback.
Once a connection is established, address validation is relatively Once a connection is established, address validation is relatively
simple (see Section 7.6 for the process that is used during the simple (see Section 7.6 for the process that is used during the
handshake). An endpoint validates a remote address by sending a PING handshake). An endpoint validates a remote address by sending a
frame containing a payload that is hard to guess. This frame MUST be PATH_CHALLENGE frame containing a payload that is hard to guess.
sent in a packet that is sent to the new address. Once a PONG frame This frame MUST be sent in a packet that is sent to the new address.
containing the same payload is received, the address is considered to Once a PATH_RESPONSE frame containing the same payload is received,
be valid. The PONG frame can use any path on its return. A PING the address is considered to be valid.
frame containing 12 randomly generated [RFC4086] octets is sufficient
to ensure that it is easier to receive the packet than it is to guess
the value correctly.
If the PING frame is determined to be lost, a new PING frame SHOULD The new address is not considered valid until a PATH_RESPONSE frame
be generated. This PING frame MUST include a new Data field that is containing the same payload is received, even if the packet
similarly difficult to guess. containing the PATH_CHALLENGE frame is acknowledged.
The PATH_RESPONSE frame can use any path on its return.
An endpoint MAY send multiple PATH_CHALLENGE frames to handle packet
loss or to make additional measurements on a new network path.
An endpoint MUST use fresh random data in every PATH_CHALLENGE frame
so that it can associate the peer's response with the causative
PATH_CHALLENGE.
If the PATH_CHALLENGE frame is determined to be lost, a new
PATH_CHALLENGE frame SHOULD be generated. This PATH_CHALLENGE frame
MUST include new data that is similarly difficult to guess.
If validation of the new remote address fails, after allowing enough If validation of the new remote address fails, after allowing enough
time for possible loss and recovery of packets carrying PING and PONG time for recovering from possible loss of packets carrying
frames, the endpoint MUST terminate the connection. When setting PATH_CHALLENGE and PATH_RESPONSE frames, the endpoint MUST terminate
this timer, implementations are cautioned that the new path could the connection. When setting this timer, implementations are
have a longer round trip time than the original. The endpoint MUST cautioned that the new path could have a longer round trip time than
NOT send a CONNECTION_CLOSE frame in this case; it has to assume that the original. The endpoint MUST NOT send a CONNECTION_CLOSE frame in
the remote peer does not want to receive any more packets. this case; it has to assume that the remote peer cannot want to
receive any more packets.
If the remote address is validated successfully, the endpoint MAY If the remote address is validated successfully, the endpoint MAY
increase the rate that it sends on the new path using the state from increase the rate that it sends on the new path using the state from
the previous path. The capacity available on the new path might not the previous path. The capacity available on the new path might not
be the same as the old path. An endpoint MUST NOT restore its send be the same as the old path. An endpoint MUST NOT restore its send
rate unless it is reasonably sure that the path is the same as the rate unless it is reasonably sure that the path is the same as the
previous path. For instance, a change in only port number is likely previous path. For instance, a change in only port number is likely
indicative of a rebinding in a middlebox and not a complete change in indicative of a rebinding in a middlebox and not a complete change in
path. This determination likely depends on heuristics, which could path. This determination likely depends on heuristics, which could
be imperfect; if the new path capacity is significantly reduced, be imperfect; if the new path capacity is significantly reduced,
ultimately this relies on the congestion controller responding to ultimately this relies on the congestion controller responding to
congestion signals and reduce send rates appropriately. congestion signals and reduce send rates appropriately.
After verifying an address, the endpoint SHOULD update any address After verifying an address, the endpoint SHOULD update any address
validation tokens (Section 7.6) that it has issued to its peer if validation tokens (Section 7.6) that it has issued to its peer if
those are no longer valid based on the changed address. those are no longer valid based on the changed address.
Address validation using the PING frame MAY be used at any time by Address validation using the PATH_CHALLENGE frame MAY be used at any
either peer. For instance, an endpoint might check that a peer is time by either peer. For instance, an endpoint might check that a
still in possession of its address after a period of quiescence. peer is still in possession of its address after a period of
quiescence.
Upon seeing a connection migration, an endpoint that sees a new Upon seeing a connection migration, an endpoint that sees a new
address MUST abandon any address validation it is performing with address MUST abandon any address validation it is performing with
other addresses on the expectation that the validation is likely to other addresses on the expectation that the validation is likely to
fail. Abandoning address validation primarily means not closing the fail. Abandoning address validation primarily means not closing the
connection when a PONG frame is not received, but it could also mean connection when a PATH_RESPONSE frame is not received, but it could
ceasing retransmissions of the PING frame. An endpoint that doesn't also mean ceasing subsequent transmissions of the PATH_CHALLENGE
retransmit a PING frame might receive a PONG frame, which it MUST frame. An endpoint MUST ignore any subsequently received
ignore. PATH_RESPONSE frames from that address.
7.8. Spurious Connection Migrations 7.8. Spurious Connection Migrations
A connection migration could be triggered by an attacker that is able A connection migration could be triggered by an attacker that is able
to capture and forward a packet such that it arrives before the to capture and forward a packet such that it arrives before the
legitimate copy of that packet. Such a packet will appear to be a legitimate copy of that packet. Such a packet will appear to be a
legitimate connection migration and the legitimate copy will be legitimate connection migration and the legitimate copy will be
dropped as a duplicate. dropped as a duplicate.
After a spurious migration, validation of the source address will After a spurious migration, validation of the source address will
fail because the entity at the source address does not have the fail because the entity at the source address does not have the
necessary cryptographic keys to read or respond to the PING frame necessary cryptographic keys to read or respond to the PATH_CHALLENGE
that is sent to it, even if it wanted to. Such a spurious connection frame that is sent to it, even if it wanted to. Such a spurious
migration could result in the connection being dropped when the connection migration could result in the connection being dropped
source address validation fails. This grants an attacker the ability when the source address validation fails. This grants an attacker
to terminate the connection. the ability to terminate the connection.
Receipt of packets with higher packet numbers from the legitimate Receipt of packets with higher packet numbers from the legitimate
address will trigger another connection migration. This will cause address will trigger another connection migration. This will cause
the validation of the address of the spurious migration to be the validation of the address of the spurious migration to be
abandoned. abandoned.
To ensure that a peer sends packets from the legitimate address To ensure that a peer sends packets from the legitimate address
before the validation of the new address can fail, an endpoint SHOULD before the validation of the new address can fail, an endpoint SHOULD
attempt to validate the old remote address before attempting to attempt to validate the old remote address before attempting to
validate the new address. If the connection migration is spurious, validate the new address. If the connection migration is spurious,
then the legitimate address will be used to respond and the then the legitimate address will be used to respond and the
connection will migrate back to the old address. connection will migrate back to the old address.
As with any address validation, packets containing retransmissions of As with any address validation, packets containing a PATH_CHALLENGE
the PING frame validating an address MUST be sent to the address frame validating an address MUST be sent to the address being
being validated. Consequently, during a migration of a peer, an validated. Consequently, during a migration of a peer, an endpoint
endpoint could be sending to multiple remote addresses. could be sending to multiple remote addresses.
An endpoint MAY abandon address validation for an address that it An endpoint MAY abandon address validation for an address that it
considers to be already valid. That is, if successive connection considers to be already valid. That is, if successive connection
migrations occur in quick succession with the final remote address migrations occur in quick succession with the final remote address
being identical to the initial remote address, the endpoint MAY being identical to the initial remote address, the endpoint MAY
abandon address validation for that address. abandon address validation for that address.
7.9. Connection Termination 7.9. Connection Termination
Connections should remain open until they become idle for a pre- Connections should remain open until they become idle for a pre-
skipping to change at page 44, line 22 skipping to change at page 45, line 25
another connection. A connection ID from a connection that is reset another connection. A connection ID from a connection that is reset
by revealing the Stateless Reset Token cannot be reused for new by revealing the Stateless Reset Token cannot be reused for new
connections at the same server without first changing to use a connections at the same server without first changing to use a
different static key or server identifier. different static key or server identifier.
Note that Stateless Reset messages do not have any cryptographic Note that Stateless Reset messages do not have any cryptographic
protection. protection.
8. Frame Types and Formats 8. Frame Types and Formats
As described in Section 6, Regular packets contain one or more As described in Section 6, packets contain one or more frames. This
frames. We now describe the various QUIC frame types that can be section describes the format and semantics of the core QUIC frame
present in a Regular packet. The use of these frames and various types.
frame header bits are described in subsequent sections.
8.1. Variable-Length Integer Encoding 8.1. Variable-Length Integer Encoding
QUIC frames use a common variable-length encoding for all non- QUIC frames use a common variable-length encoding for all non-
negative integer values. This encoding ensures that smaller integer negative integer values. This encoding ensures that smaller integer
values need fewer octets to encode. values need fewer octets to encode.
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 octet to encode the base 2 logarithm of significant bits of the first octet to encode the base 2 logarithm of
the integer encoding length in octets. The integer value is encoded the integer encoding length in octets. The integer value is encoded
skipping to change at page 45, line 48 skipping to change at page 46, line 48
8.3. RST_STREAM Frame 8.3. RST_STREAM Frame
An endpoint may use a RST_STREAM frame (type=0x01) to abruptly An endpoint may use a RST_STREAM frame (type=0x01) to abruptly
terminate a stream. terminate a stream.
After sending a RST_STREAM, an endpoint ceases transmission and After sending a RST_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 RST_STREAM can discard any data that it already received on that of RST_STREAM can discard any data that it already received on that
stream. stream.
An endpoint that receives a RST_STREAM frame for a send-only stream
MUST terminate the connection with error PROTOCOL_VIOLATION.
The RST_STREAM frame is as follows: The RST_STREAM frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Error Code (16) | | Application Error Code (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Final Offset (i) ... | Final Offset (i) ...
skipping to change at page 48, line 15 skipping to change at page 49, line 15
QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it receives more QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it receives more
data than the maximum data value that it has sent, unless this is a data than the maximum data value that it has sent, unless this is a
result of a change in the initial limits (see Section 7.4.2). result of a change in the initial limits (see Section 7.4.2).
8.7. MAX_STREAM_DATA Frame 8.7. MAX_STREAM_DATA Frame
The MAX_STREAM_DATA frame (type=0x05) is used in flow control to The MAX_STREAM_DATA frame (type=0x05) is used in flow control to
inform a peer of the maximum amount of data that can be sent on a inform a peer of the maximum amount of data that can be sent on a
stream. stream.
An endpoint that receives a MAX_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error PROTOCOL_VIOLATION.
An endpoint that receives a MAX_STREAM_DATA frame for a send-only
stream it has not opened MUST terminate the connection with error
PROTOCOL_VIOLATION.
Note that an endpoint may legally receive a MAX_STREAM_DATA frame on
a bidirectional stream it has not opened.
The frame is as follows: The frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Stream Data (i) ... | Maximum Stream Data (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 49, line 41 skipping to change at page 50, line 48
A peer MUST NOT initiate a stream with a higher stream ID than the A peer MUST NOT initiate a stream with a higher stream ID than the
greatest maximum stream ID it has received. An endpoint MUST greatest maximum stream ID it has received. An endpoint MUST
terminate a connection with a STREAM_ID_ERROR error if a peer terminate a connection with a STREAM_ID_ERROR error if a peer
initiates a stream with a higher stream ID than it has sent, unless initiates a stream with a higher stream ID than it has sent, unless
this is a result of a change in the initial limits (see this is a result of a change in the initial limits (see
Section 7.4.2). Section 7.4.2).
8.9. PING Frame 8.9. PING Frame
Endpoints can use PING frames (type=0x07) to verify that their peers Endpoints can use PING frames (type=0x07) 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. The PING frame
contains no additional fields.
The PING frame contains a variable-length payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length(8) | Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: This 8-bit value describes the length of the Data field.
Data: This variable-length field contains arbitrary data.
A PING frame with an empty Data field causes the packet containing it The receiver of a PING frame simply needs to acknowledge the packet
to be acknowledged as normal. No other action is required of the containing this frame.
recipient.
An empty 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. An application protocol SHOULD provide guidance from timing out. An application protocol SHOULD provide guidance
about the conditions under which generating a PING is recommended. about the conditions under which generating a PING is recommended.
This guidance SHOULD indicate whether it is the client or the server This guidance SHOULD indicate whether it is the client or the server
that is expected to send the PING. Having both endpoints send PING that is expected to send the PING. Having both endpoints send PING
frames without coordination can produce an excessive number of frames without coordination can produce an excessive number of
packets and poor performance. packets and poor performance.
If the Data field is not empty, the recipient of this frame MUST
generate a PONG frame (Section 8.15) containing the same Data. A
PING frame with data is not appropriate for use in keeping a
connection alive, because the PONG frame elicits an acknowledgement,
causing the sender of the original PING to send two packets.
A connection will time out if no packets are sent or received for a A connection will time out if no packets are sent or received for a
period longer than the time specified in the idle_timeout transport period longer than the time specified in the idle_timeout transport
parameter (see Section 7.9). However, state in middleboxes might parameter (see Section 7.9). However, state in middleboxes might
time out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 time out earlier than that. Though REQ-5 in [RFC4787] recommends a 2
minute timeout interval, experience shows that sending packets every minute timeout interval, experience shows that sending packets every
15 to 30 seconds is necessary to prevent the majority of middleboxes 15 to 30 seconds is necessary to prevent the majority of middleboxes
from losing state for UDP flows. from losing state for UDP flows.
8.10. BLOCKED Frame 8.10. BLOCKED Frame
skipping to change at page 51, line 11 skipping to change at page 51, line 48
Offset: A variable-length integer indicating the connection-level Offset: A variable-length integer indicating the connection-level
offset at which the blocking occurred. offset at which the blocking occurred.
8.11. STREAM_BLOCKED Frame 8.11. STREAM_BLOCKED Frame
A sender SHOULD send a STREAM_BLOCKED frame (type=0x09) when it A sender SHOULD send a STREAM_BLOCKED frame (type=0x09) when it
wishes to send data, but is unable to due to stream-level flow wishes to send data, but is unable to due to stream-level flow
control. This frame is analogous to BLOCKED (Section 8.10). control. This frame is analogous to BLOCKED (Section 8.10).
An endpoint that receives a STREAM_BLOCKED frame for a send-only
stream MUST terminate the connection with error PROTOCOL_VIOLATION.
The STREAM_BLOCKED frame is as follows: The STREAM_BLOCKED frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset (i) ... | Offset (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 53, line 5 skipping to change at page 53, line 45
stateless reset when the associated connection ID is used (see stateless reset when the associated connection ID is used (see
Section 7.9.4). Section 7.9.4).
8.14. STOP_SENDING Frame 8.14. STOP_SENDING Frame
An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate
that incoming data is being discarded on receipt at application that incoming data is being discarded on receipt at application
request. This signals a peer to abruptly terminate transmission on a request. This signals a peer to abruptly terminate transmission on a
stream. stream.
An endpoint that receives a STOP_SENDING frame for a receive-only
stream MUST terminate the connection with error PROTOCOL_VIOLATION.
The STOP_SENDING frame is as follows: The STOP_SENDING frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Error Code (16) | | Application Error Code (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are: The fields are:
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 Error Code: A 16-bit, application-specified reason the Application Error Code: A 16-bit, application-specified reason the
sender is ignoring the stream (see Section 12.4). sender is ignoring the stream (see Section 12.4).
8.15. PONG Frame 8.15. ACK Frame
The PONG frame (type=0x0d) is sent in response to a PING frame that
contains data. Its format is identical to the PING frame
(Section 8.9).
An endpoint that receives an unsolicited PONG frame - that is, a PONG
frame containing a payload that is empty MUST generate a connection
error of type FRAME_ERROR, indicating the PONG frame (that is,
0x10d). If the content of a PONG frame does not match the content of
a PING frame previously sent by the endpoint, the endpoint MAY
generate a connection error of type UNSOLICITED_PONG.
8.16. ACK Frame
Receivers send ACK frames (type=0xe) to inform senders which packets Receivers send ACK frames (type=0x0d) to inform senders which packets
they have received and processed. A sent packet that has never been they have received and processed. A sent packet that has never been
acknowledged is missing. The ACK frame contains any number of ACK acknowledged is missing. The ACK frame contains any number of ACK
blocks. ACK blocks are ranges of acknowledged packets. blocks. ACK blocks are ranges of acknowledged packets.
Unlike TCP SACKs, QUIC acknowledgements are irrevocable. Once a Unlike TCP SACKs, QUIC acknowledgements are irrevocable. Once a
packet has been acknowledged, even if it does not appear in a future packet has been acknowledged, even if it does not appear in a future
ACK frame, it remains acknowledged. ACK frame, it remains acknowledged.
A client MUST NOT acknowledge Version Negotiation or Retry packets. A client MUST NOT acknowledge Retry packets. Retry packets include
These packet types contain packet numbers selected by the client, not the packet number from the Initial packet it responds to. Version
the server. Negotiation packets cannot be acknowledged because they do not
contain a packet number. Rather than relying on ACK frames, these
packets are implicitly acknowledged by the next Initial packet sent
by the client.
A sender MAY intentionally skip packet numbers to introduce entropy A sender MAY intentionally skip packet numbers to introduce entropy
into the connection, to avoid opportunistic acknowledgement attacks. into the connection, to avoid opportunistic acknowledgement attacks.
The sender SHOULD close the connection if an unsent packet number is The sender SHOULD close the connection if an unsent packet number is
acknowledged. The format of the ACK frame is efficient at expressing acknowledged. The format of the ACK frame is efficient at expressing
even long blocks of missing packets, allowing for large, even long blocks of missing packets, allowing for large,
unpredictable gaps. unpredictable gaps.
An ACK frame is shown below. An ACK frame is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 54, line 49 skipping to change at page 55, line 42
of the "ack_delay_exponent" transport parameter set by the sender of the "ack_delay_exponent" transport parameter set by the sender
of the ACK frame. The "ack_delay_exponent" defaults to 3, or a of the ACK frame. The "ack_delay_exponent" defaults to 3, or a
multiplier of 8 (see Section 7.4.1). Scaling in this fashion multiplier of 8 (see Section 7.4.1). Scaling in this fashion
allows for a larger range of values with a shorter encoding at the allows for a larger range of values with a shorter encoding at the
cost of lower resolution. cost of lower resolution.
ACK Block Count: The number of Additional ACK Block (and Gap) fields ACK Block Count: The number of Additional ACK Block (and Gap) fields
after the First ACK Block. after the First ACK Block.
ACK Blocks: Contains one or more blocks of packet numbers which have ACK Blocks: Contains one or more blocks of packet numbers which have
been successfully received, see Section 8.16.1. been successfully received, see Section 8.15.1.
8.16.1. ACK Block Section 8.15.1. ACK Block Section
The ACK Block Section consists of alternating Gap and ACK Block The ACK Block Section consists of alternating Gap and ACK Block
fields in descending packet number order. A First Ack Block field is fields in descending packet number order. A First Ack Block field is
followed by a variable number of alternating Gap and Additional ACK followed by a variable number of alternating Gap and Additional ACK
Blocks. The number of Gap and Additional ACK Block fields is Blocks. The number of Gap and Additional ACK Block fields is
determined by the ACK Block Count field. determined by the ACK Block Count field.
Gap and ACK Block fields use a relative integer encoding for Gap and ACK Block fields use a relative integer encoding for
efficiency. Though each encoded value is positive, the values are efficiency. Though each encoded value is positive, the values are
subtracted, so that each ACK Block describes progressively lower- subtracted, so that each ACK Block describes progressively lower-
skipping to change at page 56, line 42 skipping to change at page 57, line 34
being acknowledged. being acknowledged.
Gap (repeated): A variable-length integer indicating the number of Gap (repeated): A variable-length integer indicating the number of
contiguous unacknowledged packets preceding the packet number one contiguous unacknowledged packets preceding the packet number one
lower than the smallest in the preceding ACK Block. lower than the smallest in the preceding ACK Block.
ACK Block (repeated): A variable-length integer indicating the ACK Block (repeated): A variable-length integer indicating the
number of contiguous acknowledged packets preceding the largest number of contiguous acknowledged packets preceding the largest
packet number, as determined by the preceding Gap. packet number, as determined by the preceding Gap.
8.16.2. Sending ACK Frames 8.15.2. Sending ACK Frames
Implementations MUST NOT generate packets that only contain ACK Implementations MUST NOT generate packets that only contain ACK
frames in response to packets which only contain ACK frames. frames in response to packets which only contain ACK frames.
However, they MUST acknowledge packets containing only ACK frames However, they MUST acknowledge packets containing only ACK frames
when sending ACK frames in response to other packets. when sending ACK frames in response to other packets.
Implementations MUST NOT send more than one ACK frame per received Implementations MUST NOT send more than one ACK frame per received
packet that contains frames other than ACK frames. Packets packet that contains frames other than ACK frames. Packets
containing non-ACK frames MUST be acknowledged immediately or when a containing non-ACK frames MUST be acknowledged immediately or when a
delayed ack timer expires. delayed ack timer expires.
skipping to change at page 57, line 25 skipping to change at page 58, line 16
To limit receiver state or the size of ACK frames, a receiver MAY To limit receiver state or the size of ACK frames, a receiver MAY
limit the number of ACK blocks it sends. A receiver can do this even limit the number of ACK blocks it sends. A receiver can do this even
without receiving acknowledgment of its ACK frames, with the without receiving acknowledgment of its ACK frames, with the
knowledge this could cause the sender to unnecessarily retransmit knowledge this could cause the sender to unnecessarily retransmit
some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets
lost after sufficiently newer packets are acknowledged. Therefore, lost after sufficiently newer packets are acknowledged. Therefore,
the receiver SHOULD repeatedly acknowledge newly received packets in the receiver SHOULD repeatedly acknowledge newly received packets in
preference to packets received in the past. preference to packets received in the past.
8.16.3. ACK Frames and Packet Protection 8.15.3. ACK Frames and Packet Protection
ACK frames that acknowledge protected packets MUST be carried in a ACK frames that acknowledge protected packets MUST be carried in a
packet that has an equivalent or greater level of packet protection. packet that has an equivalent or greater level of packet protection.
Packets that are protected with 1-RTT keys MUST be acknowledged in Packets that are protected with 1-RTT keys MUST be acknowledged in
packets that are also protected with 1-RTT keys. packets that are also protected with 1-RTT keys.
A packet that is not protected and claims to acknowledge a packet A packet that is not protected and claims to acknowledge a packet
number that was sent with packet protection is not valid. An number that was sent with packet protection is not valid. An
unprotected packet that carries acknowledgments for protected packets unprotected packet that carries acknowledgments for protected packets
skipping to change at page 58, line 21 skipping to change at page 59, line 13
protection keys. protection keys.
For instance, a server acknowledges a TLS ClientHello in the packet For instance, a server acknowledges a TLS ClientHello in the packet
that carries the TLS ServerHello; similarly, a client can acknowledge that carries the TLS ServerHello; similarly, a client can acknowledge
a TLS HelloRetryRequest in the packet containing a second TLS a TLS HelloRetryRequest in the packet containing a second TLS
ClientHello. The complete set of server handshake messages (TLS ClientHello. The complete set of server handshake messages (TLS
ServerHello through to Finished) might be acknowledged by a client in ServerHello through to Finished) might be acknowledged by a client in
protected packets, because it is certain that the server is able to protected packets, because it is certain that the server is able to
decipher the packet. decipher the packet.
8.17. STREAM Frames 8.16. PATH_CHALLENGE Frame
Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check
reachability to the peer and for address validation during connection
establishment and connection migration.
PATH_CHALLENGE frames contain an 8-byte payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data (8) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data: This 8-byte field contains arbitrary data.
A PATH_CHALLENGE frame containing 8 octets that are hard to guess is
sufficient to ensure that it is easier to receive the packet than it
is to guess the value correctly.
The recipient of this frame MUST generate a PATH_RESPONSE frame
(Section 8.17) containing the same Data.
8.17. PATH_RESPONSE Frame
The PATH_RESPONSE frame (type=0x0f) is sent in response to a
PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE
frame (Section 8.16).
If the content of a PATH_RESPONSE frame does not match the content of
a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint
MAY generate a connection error of type UNSOLICITED_PATH_RESPONSE.
8.18. STREAM Frames
STREAM frames implicitly create a stream and carry stream data. The STREAM frames implicitly create a stream and carry stream data. The
STREAM frame takes the form 0b00010XXX (or the set of values from STREAM frame takes the form 0b00010XXX (or the set of values from
0x10 to 0x17). The value of the three low-order bits of the frame 0x10 to 0x17). The value of 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 o 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
skipping to change at page 58, line 44 skipping to change at page 60, line 28
o The LEN bit (0x02) in the frame type is set to indicate that there o 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) of the frame type is set only on frames that o The FIN bit (0x01) of the frame type is set only on frames that
contain the final offset of the stream. Setting this bit contain the final offset of the stream. Setting this bit
indicates that the frame marks the end of the stream. indicates that the frame marks the end of the stream.
An endpoint that receives a STREAM frame for a send-only stream MUST
terminate the connection with error PROTOCOL_VIOLATION.
A STREAM frame is shown below. A STREAM frame is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Offset (i)] ... | [Offset (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Length (i)] ... | [Length (i)] ...
skipping to change at page 60, line 12 skipping to change at page 61, line 42
occurs, only streams with data in that packet are blocked waiting for occurs, only streams with data in that packet are blocked waiting for
a retransmission to be received, while other streams can continue a retransmission to be received, while other streams can continue
making progress. Note that when data from multiple streams is making progress. Note that when data from multiple streams is
bundled into a single QUIC packet, loss of that packet blocks all bundled into a single QUIC packet, loss of that packet blocks all
those streams from making progress. An implementation is therefore those streams from making progress. An implementation is therefore
advised to bundle as few streams as necessary in outgoing packets advised to bundle as few streams as necessary in outgoing packets
without losing transmission efficiency to underfilled packets. without losing transmission efficiency to underfilled packets.
9. Packetization and Reliability 9. Packetization and Reliability
A sender bundles one or more frames in a Regular QUIC packet (see A sender bundles one or more frames in a QUIC packet (see Section 6).
Section 6).
A sender SHOULD minimize per-packet bandwidth and computational costs A sender SHOULD minimize per-packet bandwidth and computational costs
by bundling as many frames as possible within a QUIC packet. A by bundling as many frames as possible within a QUIC packet. A
sender MAY wait for a short period of time to bundle multiple frames sender MAY wait for a short period of time to bundle multiple frames
before sending a packet that is not maximally packed, to avoid before sending a packet that is not maximally packed, to avoid
sending out large numbers of small packets. An implementation may sending out large numbers of small packets. An implementation may
use heuristics about expected application sending behavior to use knowledge about application sending behavior or heuristics to
determine whether and for how long to wait. This waiting period is determine whether and for how long to wait. This waiting period is
an implementation decision, and an implementation should be careful an implementation decision, and an implementation should be careful
to delay conservatively, since any delay is likely to increase to delay conservatively, since any delay is likely to increase
application-visible latency. application-visible latency.
Regular QUIC packets are "containers" of frames; a packet is never 9.1. Packet Processing and Acknowledgment
retransmitted whole. How an endpoint handles the loss of the frame
depends on the type of the frame. Some frames are simply
retransmitted, some have their contents moved to new frames, and
others are never retransmitted.
When a packet is detected as lost, the sender re-sends any frames as A packet MUST NOT be acknowledged until packet protection has been
necessary: successfully removed and all frames contained in the packet have been
processed. Any stream state transitions triggered by the frame MUST
have occurred. For STREAM frames, this means the data has been
enqueued in preparation to be received by the application protocol,
but it does not require that data is delivered and consumed.
o All application data sent in STREAM frames MUST be retransmitted, Once the packet has been fully processed, a receiver acknowledges
unless the endpoint has sent a RST_STREAM for that stream. When receipt by sending one or more ACK frames containing the packet
an endpoint sends a RST_STREAM frame, data outstanding on that number of the received packet. To avoid creating an indefinite
stream SHOULD NOT be retransmitted, since subsequent data on this feedback loop, an endpoint MUST NOT send an ACK frame in response to
stream is expected to not be delivered by the receiver. a packet containing only ACK or PADDING frames, even if there are
packet gaps which precede the received packet. The endpoint MUST
acknowledge packets containing only ACK or PADDING frames in the next
ACK frame that it sends.
o ACK and PADDING frames MUST NOT be retransmitted. ACK frames Strategies and implications of the frequency of generating
containing updated information will be sent as described in acknowledgments are discussed in more detail in [QUIC-RECOVERY].
Section 8.16.
o STOP_SENDING frames MUST be retransmitted until the receive stream 9.2. Retransmission of Information
enters either a "Data Recvd" or "Reset Recvd" state. See
Section 10.3.
o The most recent MAX_STREAM_DATA frame for a stream MUST be QUIC packets that are determined to be lost are not retransmitted
retransmitted until the receive stream enters a "Size Known" whole. The same applies to the frames that are contained within lost
state. Any previous unacknowledged MAX_STREAM_DATA frame for the packets. Instead, the information that might be carried in frames is
same stream SHOULD NOT be retransmitted since a newer sent again in new frames as needed.
MAX_STREAM_DATA frame for a stream obviates the need for
delivering older ones. Similarly, the most recent MAX_DATA frame
MUST be retransmitted; previous unacknowledged ones SHOULD NOT be
retransmitted.
o BLOCKED, STREAM_BLOCKED, and STREAM_ID_BLOCKED frames SHOULD be New frames and packets are used to carry information that is
retransmitted if the sender is still blocked on the same limit. determined to have been lost. In general, information is sent again
If the limit has been increased since the frame was originally when a packet containing that information is determined to be lost
sent, the frame SHOULD NOT be retransmitted. and sending ceases when a packet containing that information is
acknowledged.
o All other frames MUST be retransmitted. o Application data sent in STREAM frames is retransmitted in new
STREAM frames unless the endpoint has sent a RST_STREAM for that
stream. Once an endpoint sends a RST_STREAM frame, no further
STREAM frames are needed.
Upon detecting losses, a sender MUST take appropriate congestion o The most recent set of acknowledgments are sent in ACK frames. An
control action. The details of loss detection and congestion control ACK frame SHOULD contain all unacknowledged acknowledgments, as
are described in [QUIC-RECOVERY]. described in Section 8.15.2.
A packet MUST NOT be acknowledged until packet protection has been o Cancellation of stream transmission, as carried in a RST_STREAM
successfully removed and all frames contained in the packet have been frame, is sent until acknowledged or until all stream data is
processed. For STREAM frames, this means the data has been queued acknowledged by the peer (that is, either the "Reset Recvd" or
(but not necessarily delivered to the application). This also means "Data Recvd" state is reached on the send stream). The content of
that any stream state transitions triggered by STREAM or RST_STREAM a RST_STREAM frame MUST NOT change when it is sent again.
frames have occurred. Once the packet has been fully processed, a
receiver acknowledges receipt by sending one or more ACK frames
containing the packet number of the received packet.
To avoid creating an indefinite feedback loop, an endpoint MUST NOT o Similarly, a request to cancel stream transmission, as encoded in
send an ACK frame in response to a packet containing only ACK or a STOP_SENDING frame, is sent until the receive stream enters
PADDING frames, even if there are packet gaps which precede the either a "Data Recvd" or "Reset Recvd" state, see Section 10.3.
received packet. The endpoint MUST acknowledge packets containing
only ACK or PADDING frames in the next ACK frame that it sends.
Strategies and implications of the frequency of generating o Connection close signals, including those that use
acknowledgments are discussed in more detail in [QUIC-RECOVERY]. CONNECTION_CLOSE and APPLICATION_CLOSE frames, are not sent again
when packet loss is detected, but as described in Section 7.9.
9.1. Packet Size o The current connection maximum data is sent in MAX_DATA frames.
An updated value is sent in a MAX_DATA frame if the packet
containing the most recently sent MAX_DATA frame is declared lost,
or when the endpoint decides to update the limit. Care is
necessary to avoid sending this frame too often as the limit can
increase frequently and cause an unnecessarily large number of
MAX_DATA frames to be sent.
o The current maximum stream data offset is sent in MAX_STREAM_DATA
frames. Like MAX_DATA, an updated value is sent when the packet
containing the most recent MAX_STREAM_DATA frame for a stream is
lost or when the limit is updated, with care taken to prevent the
frame from being sent too often. An endpoint SHOULD stop sending
MAX_STREAM_DATA frames when the receive stream enters a "Size
Known" state.
o The maximum stream ID for a stream of a given type is sent in
MAX_STREAM_ID frames. Like MAX_DATA, an updated value is sent
when a packet containing the most recent MAX_STREAM_ID for a
stream type frame is declared lost or when the limit is updated,
with care taken to prevent the frame from being sent too often.
o Blocked signals are carried in BLOCKED, STREAM_BLOCKED, and
STREAM_ID_BLOCKED frames. BLOCKED streams have connection scope,
STREAM_BLOCKED frames have stream scope, and STREAM_ID_BLOCKED
frames are scoped to a specific stream type. New frames are sent
if packets containing the most recent frame for a scope is lost,
but only while the endpoint is blocked on the corresponding limit.
These frames always include the limit that is causing blocking at
the time that they are transmitted.
o A liveness or path validation check using PATH_CHALLENGE frames is
sent periodically until a matching PATH_RESPONSE frame is received
or until there is no remaining need for liveness or path
validation checking. PATH_CHALLENGE frames include a different
payload each time they are sent.
o Responses to path validation using PATH_RESPONSE frames are sent
just once. A new PATH_CHALLENGE frame will be sent if another
PATH_RESPONSE frame is needed.
o New connection IDs are sent in NEW_CONNECTION_ID frames and
retransmitted if the packet containing them is lost.
o PADDING frames contain no information, so lost PADDING frames do
not require repair.
Upon detecting losses, a sender MUST take appropriate congestion
control action. The details of loss detection and congestion control
are described in [QUIC-RECOVERY].
9.3. Packet Size
The QUIC packet size includes the QUIC header and integrity check, The QUIC packet size includes the QUIC header and integrity check,
but not the UDP or IP header. but not the UDP or IP header.
Clients MUST pad any Initial packet it sends to have a QUIC packet Clients MUST pad any Initial packet it sends to have a QUIC packet
size of at least 1200 octets. Sending an Initial packet of this size size of at least 1200 octets. Sending an Initial packet of this size
ensures that the network path supports a reasonably sized packet, and ensures that the network path supports a reasonably sized packet, and
helps reduce the amplitude of amplification attacks caused by server helps reduce the amplitude of amplification attacks caused by server
responses toward an unverified client address. responses toward an unverified client address.
An Initial packet MAY exceed 1200 octets if the client knows that the An Initial packet MAY exceed 1200 octets if the client knows that the
Path Maximum Transmission Unit (PMTU) supports the size that it Path Maximum Transmission Unit (PMTU) supports the size that it
chooses. chooses.
A server MAY send a CONNECTION_CLOSE frame with error code A server MAY send a CONNECTION_CLOSE frame with error code
PROTOCOL_VIOLATION in response to an Initial packet smaller than 1200 PROTOCOL_VIOLATION in response to an Initial packet smaller than 1200
octets. It MUST NOT send any other frame type in response, or octets. It MUST NOT send any other frame type in response, or
otherwise behave as if any part of the offending packet was processed otherwise behave as if any part of the offending packet was processed
as valid. as valid.
9.2. Path Maximum Transmission Unit 9.4. Path Maximum Transmission Unit
The Path Maximum Transmission Unit (PMTU) is the maximum size of the The Path Maximum Transmission Unit (PMTU) is the maximum size of the
entire IP header, UDP header, and UDP payload. The UDP payload entire IP header, UDP header, and UDP payload. The UDP payload
includes the QUIC packet header, protected payload, and any includes the QUIC packet header, protected payload, and any
authentication fields. authentication fields.
All QUIC packets SHOULD be sized to fit within the estimated PMTU to All QUIC packets SHOULD be sized to fit within the estimated PMTU to
avoid IP fragmentation or packet drops. To optimize bandwidth avoid IP fragmentation or packet drops. To optimize bandwidth
efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery
([PLPMTUD]). Endpoints MAY use PMTU Discovery ([PMTUDv4], [PMTUDv6]) ([PLPMTUD]). Endpoints MAY use PMTU Discovery ([PMTUDv4], [PMTUDv6])
skipping to change at page 63, line 5 skipping to change at page 65, line 29
most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below
this number, even if it receives signals that indicate a smaller this number, even if it receives signals that indicate a smaller
limit might exist. limit might exist.
If a QUIC endpoint determines that the PMTU between any pair of local If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses has fallen below 1280 octets, it MUST and remote IP addresses has fallen below 1280 octets, it MUST
immediately cease sending QUIC packets on the affected path. This immediately cease sending QUIC packets on the affected path. This
could result in termination of the connection if an alternative path could result in termination of the connection if an alternative path
cannot be found. cannot be found.
9.2.1. Special Considerations for PMTU Discovery 9.4.1. Special Considerations for PMTU Discovery
Traditional ICMP-based path MTU discovery in IPv4 [RFC1191] is Traditional ICMP-based path MTU discovery in IPv4 [RFC1191] is
potentially vulnerable to off-path attacks that successfully guess potentially vulnerable to off-path attacks that successfully guess
the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient
value. TCP connections mitigate this risk by using the (at minimum) value. TCP connections mitigate this risk by using the (at minimum)
8 bytes of transport header echoed in the ICMP message to validate 8 bytes of transport header echoed in the ICMP message to validate
the TCP sequence number as valid for the current connection. the TCP sequence number as valid for the current connection.
However, as QUIC operates over UDP, in IPv4 the echoed information However, as QUIC operates over UDP, in IPv4 the echoed information
could consist only of the IP and UDP headers, which usually has could consist only of the IP and UDP headers, which usually has
insufficient entropy to mitigate off-path attacks. insufficient entropy to mitigate off-path attacks.
skipping to change at page 63, line 33 skipping to change at page 66, line 9
spurious. spurious.
o Store additional information from the IP or UDP headers from DF o Store additional information from the IP or UDP headers from DF
packets (for example, the IP ID or UDP checksum) to further packets (for example, the IP ID or UDP checksum) to further
authenticate incoming Datagram Too Big messages. authenticate incoming Datagram Too Big messages.
o Any reduction in PMTU due to a report contained in an ICMP packet o Any reduction in PMTU due to a report contained in an ICMP packet
is provisional until QUIC's loss detection algorithm determines is provisional until QUIC's loss detection algorithm determines
that the packet is actually lost. that the packet is actually lost.
9.2.2. Special Considerations for Packetization Layer PMTU Discovery 9.4.2. Special Considerations for Packetization Layer PMTU Discovery
The PADDING frame provides a useful option for PMTU probe packets The PADDING frame provides a useful option for PMTU probe packets
that does not exist in other transports. PADDING frames generate that does not exist in other transports. PADDING frames generate
acknowledgements, but their content need not be delivered reliably. acknowledgements, but their content need not be delivered reliably.
PADDING frames may delay the delivery of application data, as they PADDING frames may delay the delivery of application data, as they
consume the congestion window. However, by definition their likely consume the congestion window. However, by definition their likely
loss in a probe packet does not require delay-inducing retransmission loss in a probe packet does not require delay-inducing retransmission
of application data. of application data.
When implementing the algorithm in Section 7.2 of [RFC4821], the When implementing the algorithm in Section 7.2 of [RFC4821], the
skipping to change at page 64, line 21 skipping to change at page 66, line 45
carry data in one direction only; bidirectional streams allow for carry data in one direction only; bidirectional streams allow for
data to be sent in both directions. Different stream identifiers are data to be sent in both directions. Different stream identifiers are
used to distinguish between unidirectional and bidirectional streams, used to distinguish between unidirectional and bidirectional streams,
as well as to create a separation between streams that are initiated as well as to create a separation between streams that are initiated
by the client and server (see Section 10.1). by the client and server (see Section 10.1).
Either type of stream can be created by either endpoint, can Either type of stream can be created by either endpoint, can
concurrently send data interleaved with other streams, and can be concurrently send data interleaved with other streams, and can be
cancelled. cancelled.
Data that is received on a stream is delivered in order within that Stream offsets allow for the octets on a stream to be placed in
stream, but there is no particular delivery order across streams. order. An endpoint MUST be capable of delivering data received on a
Transmit ordering among streams is left to the implementation. stream in order. Implementations MAY choose to offer the ability to
deliver data out of order. There is no means of ensuring ordering
between octets on different streams.
The creation and destruction of streams are expected to have minimal The creation and destruction of streams are expected to have minimal
bandwidth and computational cost. A single STREAM frame may create, bandwidth and computational cost. A single STREAM frame may create,
carry data for, and terminate a stream, or a stream may last the carry data for, and terminate a stream, or a stream may last the
entire duration of a connection. entire duration of a connection.
Streams are individually flow controlled, allowing an endpoint to Streams are individually flow controlled, allowing an endpoint to
limit memory commitment and to apply back pressure. The creation of limit memory commitment and to apply back pressure. The creation of
streams is also flow controlled, with each peer declaring the maximum streams is also flow controlled, with each peer declaring the maximum
stream ID it is willing to accept at a given time. stream ID it is willing to accept at a given time.
skipping to change at page 67, line 6 skipping to change at page 70, line 6
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 behavior is consistent with an implementation that implements
these states. these states.
10.2.1. Send Stream States 10.2.1. Send Stream States
Figure 10 shows the states for the part of a stream that sends data Figure 10 shows the states for the part of a stream that sends data
to a peer. to a peer.
o o
| Application Open | Open Stream (Sending)
| Open Paired Stream (bidirectional) | Open Bidirectional Stream (Receiving)
v v
+-------+ +-------+
| Open | Send RST_STREAM | Open | Send RST_STREAM
| |-----------------------. | |-----------------------.
+-------+ | +-------+ |
| | | |
| Send STREAM / | | Send STREAM / |
| STREAM_BLOCKED | | STREAM_BLOCKED |
v | v |
+-------+ | +-------+ |
skipping to change at page 69, line 7 skipping to change at page 72, line 7
Figure 11 shows the states for the part of a stream that receives Figure 11 shows the states for the part of a stream that receives
data from a peer. The states for a receive stream mirror only some data from a peer. The states for a receive stream mirror only some
of the states of the send stream at the peer. A receive stream of the states of the send stream at the peer. A receive stream
doesn't track states on the send stream that cannot be observed, such doesn't track states on the send stream that cannot be observed, such
as the "Open" state; instead, receive streams track the delivery of as the "Open" state; instead, receive streams track the delivery of
data to the application or application protocol some of which cannot data to the application or application protocol some of which cannot
be observed by the sender. be observed by the sender.
o o
| Recv STREAM / STREAM_BLOCKED / RST_STREAM | Recv STREAM / STREAM_BLOCKED / RST_STREAM
| Open Paired Stream (bidirectional) | Open Bidirectional Stream (Sending)
| Recv MAX_STREAM_DATA | Recv MAX_STREAM_DATA
v v
+-------+ +-------+
| Recv | Recv RST_STREAM | Recv | Recv RST_STREAM
| |-----------------------. | |-----------------------.
+-------+ | +-------+ |
| | | |
| Recv STREAM + FIN | | Recv STREAM + FIN |
v | v |
+-------+ | +-------+ |
skipping to change at page 70, line 8 skipping to change at page 73, line 8
bidirectional stream initiated by the endpoint (type 0 for a client, bidirectional stream initiated by the endpoint (type 0 for a client,
type 1 for a server) enters the "Open" state. type 1 for a server) enters the "Open" state.
A bidirectional stream also opens when a MAX_STREAM_DATA frame is A bidirectional stream also opens when a MAX_STREAM_DATA frame is
received. Receiving a MAX_STREAM_DATA frame implies that the remote received. Receiving a MAX_STREAM_DATA frame implies that the remote
peer has opened the stream and is providing flow control credit. A peer has opened the stream and is providing flow control credit. A
MAX_STREAM_DATA frame might arrive before a STREAM or STREAM_BLOCKED MAX_STREAM_DATA frame might arrive before a STREAM or STREAM_BLOCKED
frame if packets are lost or reordered. frame if packets are lost or reordered.
In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED
frames. Incoming data is buffered and reassembled into the correct frames. Incoming data is buffered and can be reassembled into the
order for delivery to the application. As data is consumed by the correct order for delivery to the application. As data is consumed
application and buffer space becomes available, the endpoint sends by the application and buffer space becomes available, the endpoint
MAX_STREAM_DATA frames to allow the peer to send more data. sends MAX_STREAM_DATA frames to allow the peer to send more data.
When a STREAM frame with a FIN bit is received, the final offset (see When a STREAM frame with a FIN bit is received, the final offset (see
Section 11.3) is known. The receive stream enters the "Size Known" Section 11.3) is known. The receive stream enters the "Size Known"
state. In this state, the endpoint no longer needs to send state. In this state, the endpoint no longer needs to send
MAX_STREAM_DATA frames, it only receives any retransmissions of MAX_STREAM_DATA frames, it only receives any retransmissions of
stream data. stream data.
Once all data for the stream has been received, the receive stream Once all data for the stream has been received, the receive stream
enters the "Data Recvd" state. This might happen as a result of enters the "Data Recvd" state. This might happen as a result of
receiving the same STREAM frame that causes the transition to "Size receiving the same STREAM frame that causes the transition to "Size
skipping to change at page 71, line 9 skipping to change at page 74, line 9
effectively transitions to "Data Recvd" from "Reset Recvd". effectively transitions to "Data Recvd" from "Reset Recvd".
Once the application has been delivered the signal indicating that Once the application has been delivered the signal indicating that
the receive stream was reset, the receive stream transitions to the the receive stream was reset, the receive stream transitions to the
"Reset Read" state, which is a terminal state. "Reset Read" state, which is a terminal state.
10.2.3. Permitted Frame Types 10.2.3. Permitted Frame Types
The sender of a stream sends just three frame types that affect the The sender of a stream sends just three frame types that affect the
state of a stream at either sender or receiver: STREAM state of a stream at either sender or receiver: STREAM
(Section 8.17), STREAM_BLOCKED (Section 8.11), and RST_STREAM (Section 8.18), STREAM_BLOCKED (Section 8.11), and RST_STREAM
(Section 8.3). (Section 8.3).
A sender MUST NOT send any of these frames from a terminal state A sender MUST NOT send any of these frames from a terminal state
("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or
STREAM_BLOCKED after sending a RST_STREAM; that is, in the "Reset STREAM_BLOCKED after sending a RST_STREAM; that is, in the "Reset
Sent" state in addition to the terminal states. A receiver could Sent" state in addition to the terminal states. A receiver could
receive any of these frames in any state, but only due to the receive any of these frames in any state, but only due to the
possibility of delayed delivery of packets carrying them. possibility of delayed delivery of packets carrying them.
The receiver of a stream sends MAX_STREAM_DATA (Section 8.7) and The receiver of a stream sends MAX_STREAM_DATA (Section 8.7) and
skipping to change at page 74, line 17 skipping to change at page 77, line 17
Once a stream is created, endpoints may use the stream to send and Once a stream is created, endpoints may use the stream to send and
receive data. Each endpoint may send a series of STREAM frames receive data. Each endpoint may send a series of STREAM frames
encapsulating data on a stream until the stream is terminated in that encapsulating data on a stream until the stream is terminated in that
direction. Streams are an ordered byte-stream abstraction, and they direction. Streams are an ordered byte-stream abstraction, and they
have no other structure within them. STREAM frame boundaries are not have no other structure within them. STREAM frame boundaries are not
expected to be preserved in retransmissions from the sender or during expected to be preserved in retransmissions from the sender or during
delivery to the application at the receiver. delivery to the application at the receiver.
When new data is to be sent on a stream, a sender MUST set the When new data is to be sent on a stream, a sender MUST set the
encapsulating STREAM frame's offset field to the stream offset of the encapsulating STREAM frame's offset field to the stream offset of the
first byte of this new data. The first byte of data that is sent on first byte of this new data. The first octet of data on a stream has
a stream has the stream offset 0. The largest offset delivered on a an offset of 0. An endpoint is expected to send every stream octet.
stream MUST be less than 2^62. A receiver MUST ensure that received The largest offset delivered on a stream MUST be less than 2^62. A
stream data is delivered to the application as an ordered byte- receiver MUST ensure that received stream data is delivered to the
stream. Data received out of order MUST be buffered for later application as an ordered byte-stream. Data received out of order
delivery, as long as it is not in violation of the receiver's flow MUST be buffered for later delivery, as long as it is not in
control limits. violation of the receiver's flow control limits.
An endpoint MUST NOT send data on any stream without ensuring that it An endpoint MUST NOT send data on any stream without ensuring that it
is within the data limits set by its peer. The cryptographic is within the data limits set by its peer. The cryptographic
handshake stream, Stream 0, is exempt from the connection-level data handshake stream, Stream 0, is exempt from the connection-level data
limits established by MAX_DATA. Data on stream 0 other than the limits established by MAX_DATA. Data on stream 0 other than the
initial cryptographic handshake message is still subject to stream- initial cryptographic handshake message is still subject to stream-
level data limits and MAX_STREAM_DATA. This message is exempt from level data limits and MAX_STREAM_DATA. This message is exempt from
flow control because it needs to be sent in a single packet flow control because it needs to be sent in a single packet
regardless of the server's flow control state. This rule applies regardless of the server's flow control state. This rule applies
even for 0-RTT handshakes where the remembered value of even for 0-RTT handshakes where the remembered value of
skipping to change at page 76, line 37 skipping to change at page 79, line 37
A receiver advertises credit for a stream by sending a A receiver advertises credit for a stream by sending a
MAX_STREAM_DATA frame with the Stream ID set appropriately. A MAX_STREAM_DATA frame with the Stream ID set appropriately. A
receiver could use the current offset of data consumed to determine receiver could use the current offset of data consumed to determine
the flow control offset to be advertised. A receiver MAY send the flow control offset to be advertised. A receiver MAY send
MAX_STREAM_DATA frames in multiple packets in order to make sure that MAX_STREAM_DATA frames in multiple packets in order to make sure that
the sender receives an update before running out of flow control the sender receives an update before running out of flow control
credit, even if one of the packets is lost. credit, even if one of the packets is lost.
Connection flow control is a limit to the total bytes of stream data Connection flow control is a limit to the total bytes of stream data
sent in STREAM frames on all streams. A receiver advertises credit sent in STREAM frames on all streams except stream 0. A receiver
for a connection by sending a MAX_DATA frame. A receiver maintains a advertises credit for a connection by sending a MAX_DATA frame. A
cumulative sum of bytes received on all streams, which are used to receiver maintains a cumulative sum of bytes received on all
check for flow control violations. A receiver might use a sum of contributing streams, which are used to check for flow control
bytes consumed on all contributing streams to determine the maximum violations. A receiver might use a sum of bytes consumed on all
data limit to be advertised. contributing streams to determine the maximum data limit to be
advertised.
11.1. Edge Cases and Other Considerations 11.1. Edge Cases and Other Considerations
There are some edge cases which must be considered when dealing with There are some edge cases which must be considered when dealing with
stream and connection level flow control. Given enough time, both stream and connection level flow control. Given enough time, both
endpoints must agree on flow control state. If one end believes it endpoints must agree on flow control state. If one end believes it
can send more than the other end is willing to receive, the can send more than the other end is willing to receive, the
connection will be torn down when too much data arrives. connection will be torn down when too much data arrives.
Conversely if a sender believes it is blocked, while endpoint B Conversely if a sender believes it is blocked, while endpoint B
skipping to change at page 78, line 7 skipping to change at page 81, line 7
increments to limits if blocking is to be avoided. Thus, larger increments to limits if blocking is to be avoided. Thus, larger
updates require a receiver to commit to larger resource commitments. updates require a receiver to commit to larger resource commitments.
Thus there is a tradeoff between resource commitment and overhead Thus there is a tradeoff between resource commitment and overhead
when determining how large a limit is advertised. when determining how large a limit is advertised.
A receiver MAY use an autotuning mechanism to tune the frequency and A receiver MAY use an autotuning mechanism to tune the frequency and
amount that it increases data limits based on a roundtrip time amount that it increases data limits based on a roundtrip time
estimate and the rate at which the receiving application consumes estimate and the rate at which the receiving application consumes
data, similar to common TCP implementations. data, similar to common TCP implementations.
11.1.3. Handshake Exemption
During the initial handshake, an endpoint could need to send a larger
message on stream 0 than would ordinarily be permitted by the peer's
initial stream flow control window. Since MAX_STREAM_DATA frames are
not permitted in these early packets, the peer cannot provide
additional flow control window in order to complete the handshake.
Endpoints MAY exceed the flow control limits on stream 0 prior to the
completion of the cryptographic handshake. (That is, in Initial,
Retry, and Handshake packets.) However, once the handshake is
complete, endpoints MUST NOT send additional data beyond the peer's
permitted offset. If the amount of data sent during the handshake
exceeds the peer's maximum offset, the endpoint cannot send
additional data on stream 0 until the peer has sent a MAX_STREAM_DATA
frame indicating a larger maximum offset.
11.2. Stream Limit Increment 11.2. Stream Limit Increment
As with flow control, this document leaves when and how many streams As with flow control, this document leaves when and how many streams
to make available to a peer via MAX_STREAM_ID to implementations, but to make available to a peer via MAX_STREAM_ID to implementations, but
offers a few considerations. MAX_STREAM_ID frames constitute minimal offers a few considerations. MAX_STREAM_ID frames constitute minimal
overhead, while withholding MAX_STREAM_ID frames can prevent the peer overhead, while withholding MAX_STREAM_ID frames can prevent the peer
from using the available parallelism. from using the available parallelism.
Implementations will likely want to increase the maximum stream ID as Implementations will likely want to increase the maximum stream ID as
peer-initiated streams close. A receiver MAY also advance the peer-initiated streams close. A receiver MAY also advance the
skipping to change at page 81, line 8 skipping to change at page 84, line 27
used in a CONNECTION_CLOSE frame. These errors apply to the entire used in a CONNECTION_CLOSE frame. These errors apply to the entire
connection. connection.
NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to
signal that the connection is being closed abruptly in the absence signal that the connection is being closed abruptly in the absence
of any error. of any error.
INTERNAL_ERROR (0x1): The endpoint encountered an internal error and INTERNAL_ERROR (0x1): The endpoint encountered an internal error and
cannot continue with the connection. cannot continue with the connection.
SERVER_BUSY (0x2): The server is currently busy and does not accept
any new connections.
FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it
permitted in its advertised data limits (see Section 11). permitted in its advertised data limits (see Section 11).
STREAM_ID_ERROR (0x4): An endpoint received a frame for a stream STREAM_ID_ERROR (0x4): An endpoint received a frame for a stream
identifier that exceeded its advertised maximum stream ID. identifier that exceeded its advertised maximum stream ID.
STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream
that was not in a state that permitted that frame (see that was not in a state that permitted that frame (see
Section 10.2). Section 10.2).
skipping to change at page 81, line 47 skipping to change at page 85, line 21
VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport
parameters that contained version negotiation parameters that parameters that contained version negotiation parameters that
disagreed with the version negotiation that it performed. This disagreed with the version negotiation that it performed. This
error code indicates a potential version downgrade attack. error code indicates a potential version downgrade attack.
PROTOCOL_VIOLATION (0xA): An endpoint detected an error with PROTOCOL_VIOLATION (0xA): An endpoint detected an error with
protocol compliance that was not covered by more specific error protocol compliance that was not covered by more specific error
codes. codes.
UNSOLICITED_PONG (0xB): An endpoint received a PONG frame that did UNSOLICITED_PATH_RESPONSE (0xB): An endpoint received a
not correspond to any PING frame that it previously sent. PATH_RESPONSE frame that did not correspond to any PATH_CHALLENGE
frame that it previously sent.
FRAME_ERROR (0x1XX): An endpoint detected an error in a specific FRAME_ERROR (0x1XX): An endpoint detected an error in a specific
frame type. The frame type is included as the last octet of the frame type. The frame type is included as the last octet of the
error code. For example, an error in a MAX_STREAM_ID frame would error code. For example, an error in a MAX_STREAM_ID frame would
be indicated with the code (0x106). be indicated with the code (0x106).
See Section 14.2 for details of registering new error codes. Codes for errors occuring when TLS is used for the crypto handshake
are defined in Section 11 of [QUIC-TLS]. See Section 14.2 for
details of registering new error codes.
12.4. Application Protocol Error Codes 12.4. Application Protocol Error Codes
Application protocol error codes are 16-bit unsigned integers, but Application protocol error codes are 16-bit unsigned integers, but
the management of application error codes are left to application the management of application error codes are left to application
protocols. Application protocol error codes are used for the protocols. Application protocol error codes are used for the
RST_STREAM (Section 8.3) and APPLICATION_CLOSE (Section 8.5) frames. RST_STREAM (Section 8.3) and APPLICATION_CLOSE (Section 8.5) frames.
There is no restriction on the use of the 16-bit error code space for There is no restriction on the use of the 16-bit error code space for
application protocols. However, QUIC reserves the error code with a application protocols. However, QUIC reserves the error code with a
skipping to change at page 87, line 14 skipping to change at page 89, line 43
+-----------+------------------------+---------------+--------------+ +-----------+------------------------+---------------+--------------+
| Value | Error | Description | Specificatio | | Value | Error | Description | Specificatio |
| | | | n | | | | | n |
+-----------+------------------------+---------------+--------------+ +-----------+------------------------+---------------+--------------+
| 0x0 | NO_ERROR | No error | Section 12.3 | | 0x0 | NO_ERROR | No error | Section 12.3 |
| | | | | | | | | |
| 0x1 | INTERNAL_ERROR | Implementatio | Section 12.3 | | 0x1 | INTERNAL_ERROR | Implementatio | Section 12.3 |
| | | n error | | | | | n error | |
| | | | | | | | | |
| 0x2 | SERVER_BUSY | Server | Section 12.3 |
| | | currently | |
| | | busy | |
| | | | |
| 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 12.3 | | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 12.3 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0x4 | STREAM_ID_ERROR | Invalid | Section 12.3 | | 0x4 | STREAM_ID_ERROR | Invalid | Section 12.3 |
| | | stream ID | | | | | stream ID | |
| | | | | | | | | |
| 0x5 | STREAM_STATE_ERROR | Frame | Section 12.3 | | 0x5 | STREAM_STATE_ERROR | Frame | Section 12.3 |
| | | received in | | | | | received in | |
| | | invalid | | | | | invalid | |
| | | stream state | | | | | stream state | |
skipping to change at page 87, line 44 skipping to change at page 90, line 28
| | | parameters | | | | | parameters | |
| | | | | | | | | |
| 0x9 | VERSION_NEGOTIATION_ER | Version | Section 12.3 | | 0x9 | VERSION_NEGOTIATION_ER | Version | Section 12.3 |
| | ROR | negotiation | | | | ROR | negotiation | |
| | | failure | | | | | failure | |
| | | | | | | | | |
| 0xA | PROTOCOL_VIOLATION | Generic | Section 12.3 | | 0xA | PROTOCOL_VIOLATION | Generic | Section 12.3 |
| | | protocol | | | | | protocol | |
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xB | UNSOLICITED_PONG | Unsolicited | Section 12.3 | | 0xB | UNSOLICITED_PATH_RESPO | Unsolicited | Section 12.3 |
| | | PONG frame | | | | NSE | PATH_RESPONSE | |
| | | frame | |
| | | | | | | | | |
| 0x100-0x1 | FRAME_ERROR | Specific | Section 12.3 | | 0x100-0x1 | FRAME_ERROR | Specific | Section 12.3 |
| FF | | frame format | | | FF | | frame format | |
| | | error | | | | | error | |
+-----------+------------------------+---------------+--------------+ +-----------+------------------------+---------------+--------------+
Table 8: Initial QUIC Transport Error Codes Entries Table 8: Initial QUIC Transport Error Codes Entries
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-23 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
January 2018. July 2017.
[PLPMTUD] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [PLPMTUD] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[PMTUDv4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [PMTUDv4] 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>.
[PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-09 (work and Congestion Control", draft-ietf-quic-recovery-10 (work
in progress), January 2018. in progress), March 2018.
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
tls-09 (work in progress), January 2018. tls-10 (work in progress), March 2018.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 89, line 34 skipping to change at page 92, line 20
[EARLY-DESIGN] [EARLY-DESIGN]
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[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>.
[QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-00 (work in progress), March
2018.
[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>.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22,
RFC 2360, DOI 10.17487/RFC2360, June 1998, RFC 2360, DOI 10.17487/RFC2360, June 1998,
<https://www.rfc-editor.org/info/rfc2360>. <https://www.rfc-editor.org/info/rfc2360>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
skipping to change at page 91, line 16 skipping to change at page 94, line 7
discussions and public ones on the quic@ietf.org and proto- discussions and public ones on the quic@ietf.org and proto-
quic@chromium.org mailing lists. Our thanks to all. quic@chromium.org mailing lists. Our thanks to all.
Appendix C. Change Log Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-08 C.1. Since draft-ietf-quic-transport-09
o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d.
(#1091, #1086)
o A server can now only send 3 packets without validating the client
address (#38, #1090)
o Delivery order of stream data is no longer strongly specified
(#252, #1070)
o Rework of packet handling and version negotiation (#1038)
o Stream 0 is now exempt from flow control until the handshake
completes (#1074, #725, #1082)
o Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053)
o Added an error code for server busy signals (#1137)
C.2. Since draft-ietf-quic-transport-08
o Clarified requirements for BLOCKED usage (#65, #924) o Clarified requirements for BLOCKED usage (#65, #924)
o BLOCKED frame now includes reason for blocking (#452, #924, #927, o BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
o Cleartext integrity as version independent (#568)
o GAP limitation in ACK Frame (#613) o GAP limitation in ACK Frame (#613)
o Improved PMTUD description (#614, #1036) o Improved PMTUD description (#614, #1036)
o Clarified stream state machine (#634, #662, #894) o Clarified stream state machine (#634, #662, #894)
o Reserved versions don't need to be generated deterministically o Reserved versions don't need to be generated deterministically
(#831, #931) (#831, #931)
o You don't always need the draining period (#871) o You don't always need the draining period (#871)
skipping to change at page 91, line 46 skipping to change at page 95, line 10
o Stateless reset clarified as version-specific (#930, #986) o Stateless reset clarified as version-specific (#930, #986)
o initial_max_stream_id_x transport parameters are optional (#970, o initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
o Ack Delay assumes a default value during the handshake (#1007, o Ack Delay assumes a default value during the handshake (#1007,
#1009) #1009)
o Removed transport parameters from NewSessionTicket (#1015) o Removed transport parameters from NewSessionTicket (#1015)
C.2. Since draft-ietf-quic-transport-07 C.3. Since draft-ietf-quic-transport-07
o The long header now has version before packet number (#926, #939) o The long header now has version before packet number (#926, #939)
o Rename and consolidate packet types (#846, #822, #847) o Rename and consolidate packet types (#846, #822, #847)
o Packet types are assigned new codepoints and the Connection ID o Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956) Flag is inverted (#426, #956)
o Removed type for Version Negotiation and use Version 0 (#963, o Removed type for Version Negotiation and use Version 0 (#963,
#968) #968)
o Streams are split into unidirectional and bidirectional (#643, o Streams are split into unidirectional and bidirectional (#643,
#656, #720, #872, #175, #885) #656, #720, #872, #175, #885)
* Stream limits now have separate uni- and bi-directinal * Stream limits now have separate uni- and bi-directinal
skipping to change at page 92, line 42 skipping to change at page 96, line 5
o Address validation for connection migration (#161, #732, #878) o Address validation for connection migration (#161, #732, #878)
o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) o Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
o negotiated_version is sent in server transport parameters (#710, o negotiated_version is sent in server transport parameters (#710,
#959) #959)
o Increased the range over which packet numbers are randomized o Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
C.3. Since draft-ietf-quic-transport-06 C.4. Since draft-ietf-quic-transport-06
o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
o Split error code space between application and transport (#485) o Split error code space between application and transport (#485)
o Stateless reset token moved to end (#820) o Stateless reset token moved to end (#820)
o 1-RTT-protected long header types removed (#848) o 1-RTT-protected long header types removed (#848)
o No acknowledgments during draining period (#852) o No acknowledgments during draining period (#852)
o Remove "application close" as a separate close type (#854) o Remove "application close" as a separate close type (#854)
o Remove timestamps from the ACK frame (#841) o Remove timestamps from the ACK frame (#841)
o Require transport parameters to only appear once (#792) o Require transport parameters to only appear once (#792)
C.4. Since draft-ietf-quic-transport-05 C.5. Since draft-ietf-quic-transport-05
o Stateless token is server-only (#726) o Stateless token is server-only (#726)
o Refactor section on connection termination (#733, #748, #328, o Refactor section on connection termination (#733, #748, #328,
#177) #177)
o Limit size of Version Negotiation packet (#585) o Limit size of Version Negotiation packet (#585)
o Clarify when and what to ack (#736) o Clarify when and what to ack (#736)
o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
o Clarify Keep-alive requirements (#729) o Clarify Keep-alive requirements (#729)
C.5. Since draft-ietf-quic-transport-04 C.6. Since draft-ietf-quic-transport-04
o Introduce STOP_SENDING frame, RST_STREAM only resets in one o Introduce STOP_SENDING frame, RST_STREAM only resets in one
direction (#165) direction (#165)
o Removed GOAWAY; application protocols are responsible for graceful o Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
o Reduced the number of error codes (#96, #177, #184, #211) o Reduced the number of error codes (#96, #177, #184, #211)
o Version validation fields can't move or change (#121) o Version validation fields can't move or change (#121)
skipping to change at page 94, line 4 skipping to change at page 97, line 13
NewSessionTicket message (#547) NewSessionTicket message (#547)
o Clarify the meaning of "bytes in flight" (#550) o Clarify the meaning of "bytes in flight" (#550)
o Public reset is now stateless reset and not visible to the path o Public reset is now stateless reset and not visible to the path
(#215) (#215)
o Reordered bits and fields in STREAM frame (#620) o Reordered bits and fields in STREAM frame (#620)
o Clarifications to the stream state machine (#572, #571) o Clarifications to the stream state machine (#572, #571)
o Increased the maximum length of the Largest Acknowledged field in o Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
o truncate_connection_id is renamed to omit_connection_id (#659) o truncate_connection_id is renamed to omit_connection_id (#659)
o CONNECTION_CLOSE terminates the connection like TCP RST (#330, o CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
C.6. Since draft-ietf-quic-transport-03 C.7. Since draft-ietf-quic-transport-03
o Change STREAM and RST_STREAM layout o Change STREAM and RST_STREAM layout
o Add MAX_STREAM_ID settings o Add MAX_STREAM_ID settings
C.7. Since draft-ietf-quic-transport-02 C.8. Since draft-ietf-quic-transport-02
o The size of the initial packet payload has a fixed minimum (#267, o The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
o Define when Version Negotiation packets are ignored (#284, #294, o Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
o The 64-bit FNV-1a algorithm is used for integrity protection of o The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517) unprotected packets (#167, #480, #481, #517)
skipping to change at page 95, line 4 skipping to change at page 98, line 13
different handshake protocol (#516) different handshake protocol (#516)
o STREAM frames have a reduced number of offset lengths (#543, #430) o STREAM frames have a reduced number of offset lengths (#543, #430)
o Split some frames into separate connection- and stream- level o Split some frames into separate connection- and stream- level
frames (#443) frames (#443)
* WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450)
* BLOCKED split to match WINDOW_UPDATE split (#454) * BLOCKED split to match WINDOW_UPDATE split (#454)
* Define STREAM_ID_NEEDED frame (#455) * Define STREAM_ID_NEEDED frame (#455)
o A NEW_CONNECTION_ID frame supports connection migration without o A NEW_CONNECTION_ID frame supports connection migration without
linkability (#232, #491, #496) linkability (#232, #491, #496)
o Transport parameters for 0-RTT are retained from a previous o Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512) connection (#405, #513, #512)
* A client in 0-RTT no longer required to reset excess streams * A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
o Expanded security considerations (#440, #444, #445, #448) o Expanded security considerations (#440, #444, #445, #448)
C.8. Since draft-ietf-quic-transport-01 C.9. Since draft-ietf-quic-transport-01
o Defined short and long packet headers (#40, #148, #361) o Defined short and long packet headers (#40, #148, #361)
o Defined a versioning scheme and stable fields (#51, #361) o Defined a versioning scheme and stable fields (#51, #361)
o Define reserved version values for "greasing" negotiation (#112, o Define reserved version values for "greasing" negotiation (#112,
#278) #278)
o The initial packet number is randomized (#35, #283) o The initial packet number is randomized (#35, #283)
skipping to change at page 97, line 17 skipping to change at page 100, line 25
o Remove error code and reason phrase from GOAWAY (#352, #355) o Remove error code and reason phrase from GOAWAY (#352, #355)
o GOAWAY includes a final stream number for both directions (#347) o GOAWAY includes a final stream number for both directions (#347)
o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
o Defined priority as the responsibility of the application protocol o Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
C.9. Since draft-ietf-quic-transport-00 C.10. Since draft-ietf-quic-transport-00
o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
o Defined versioning o Defined versioning
o Reworked description of packet and frame layout o Reworked description of packet and frame layout
o Error code space is divided into regions for each component o Error code space is divided into regions for each component
o Use big endian for all numeric values o Use big endian for all numeric values
C.10. Since draft-hamilton-quic-transport-protocol-01 C.11. Since draft-hamilton-quic-transport-protocol-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added IANA Considerations section o Added IANA Considerations section
o Moved Contributors and Acknowledgments to appendices o Moved Contributors and Acknowledgments to appendices
Authors' Addresses Authors' Addresses
Jana Iyengar (editor) Jana Iyengar (editor)
Google Fastly
Email: jri@google.com
Email: jri.ietf@gmail.com
Martin Thomson (editor) Martin Thomson (editor)
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: martin.thomson@gmail.com
 End of changes. 124 change blocks. 
417 lines changed or deleted 585 lines changed or added

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