draft-ietf-quic-transport-17.txt   draft-ietf-quic-transport-18.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: June 21, 2019 Mozilla Expires: July 27, 2019 Mozilla
December 18, 2018 January 23, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-17 draft-ietf-quic-transport-18
Abstract Abstract
This document defines the core of the QUIC transport protocol. This document defines the core of the QUIC transport protocol.
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 for key negotiation control and the use of TLS for key negotiation.
[QUIC-TLS].
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at mailing list (quic@ietf.org), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>. <https://mailarchive.ietf.org/arch/search/?email_list=quic>.
Working Group information can be found at <https://github.com/ Working Group information can be found at <https://github.com/
quicwg>; source code and issues list for this draft can be found at quicwg>; source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-transport>. <https://github.com/quicwg/base-drafts/labels/-transport>.
skipping to change at page 1, line 44 skipping to change at page 1, line 43
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 June 21, 2019. This Internet-Draft will expire on July 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 31 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 10 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 10
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Send Stream States . . . . . . . . . . . . . . . . . . . 11 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 11
3.2. Receive Stream States . . . . . . . . . . . . . . . . . . 13 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 13
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 16 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 16
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 17 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21
4.4. Stream Final Offset . . . . . . . . . . . . . . . . . . . 21 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25
5.2. Matching Packets to Connections . . . . . . . . . . . . . 25 5.2. Matching Packets to Connections . . . . . . . . . . . . . 25
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 26 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 26
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 26 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 26
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 27 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 27
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 27 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 27
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28
6.2. Handling Version Negotiation Packets . . . . . . . . . . 28 6.2. Handling Version Negotiation Packets . . . . . . . . . . 28
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 29 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 30
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 30 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 33 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 34
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35
7.3.3. Version Negotiation Validation . . . . . . . . . . . 35 7.3.3. Version Negotiation Validation . . . . . . . . . . . 36
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37
8.1. Address Validation During Connection Establishment . . . 37 8.1. Address Validation During Connection Establishment . . . 38
8.1.1. Address Validation using Retry Packets . . . . . . . 38 8.1.1. Address Validation using Retry Packets . . . . . . . 38
8.1.2. Address Validation for Future Connections . . . . . . 38 8.1.2. Address Validation for Future Connections . . . . . . 39
8.1.3. Address Validation Token Integrity . . . . . . . . . 40 8.1.3. Address Validation Token Integrity . . . . . . . . . 41
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 41 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 41
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 41 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 42
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 42 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 42
8.5. Successful Path Validation . . . . . . . . . . . . . . . 42 8.5. Successful Path Validation . . . . . . . . . . . . . . . 43
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 43 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 44
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 44 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 45
9.2. Initiating Connection Migration . . . . . . . . . . . . . 44 9.2. Initiating Connection Migration . . . . . . . . . . . . . 45
9.3. Responding to Connection Migration . . . . . . . . . . . 45 9.3. Responding to Connection Migration . . . . . . . . . . . 46
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 45 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 46
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 46 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 47
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 47 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 47
9.4. Loss Detection and Congestion Control . . . . . . . . . . 48 9.4. Loss Detection and Congestion Control . . . . . . . . . . 48
9.5. Privacy Implications of Connection Migration . . . . . . 49 9.5. Privacy Implications of Connection Migration . . . . . . 49
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50
9.6.1. Communicating A Preferred Address . . . . . . . . . . 50 9.6.1. Communicating A Preferred Address . . . . . . . . . . 50
9.6.2. Responding to Connection Migration . . . . . . . . . 50 9.6.2. Responding to Connection Migration . . . . . . . . . 51
9.6.3. Interaction of Client Migration and Preferred Address 51 9.6.3. Interaction of Client Migration and Preferred Address 51
10. Connection Termination . . . . . . . . . . . . . . . . . . . 51 10. Connection Termination . . . . . . . . . . . . . . . . . . . 52
10.1. Closing and Draining Connection States . . . . . . . . . 51 10.1. Closing and Draining Connection States . . . . . . . . . 52
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 53
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 53 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 54
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 55 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 55
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 57 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 57
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 57 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 58
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 58 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 59
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 59 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 59
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 59 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 60
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 60 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 60
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 60 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 61
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 60 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 61
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 61 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 62
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 62 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 62
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 63 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 64
13. Packetization and Reliability . . . . . . . . . . . . . . . . 66 13. Packetization and Reliability . . . . . . . . . . . . . . . . 66
13.1. Packet Processing and Acknowledgment . . . . . . . . . . 66 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 67
13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 67 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 67
13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 68 13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 68
13.2. Retransmission of Information . . . . . . . . . . . . . 68 13.2. Retransmission of Information . . . . . . . . . . . . . 68
13.3. Explicit Congestion Notification . . . . . . . . . . . . 70 13.3. Explicit Congestion Notification . . . . . . . . . . . . 71
13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 71 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 71
13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 71 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 72
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 73 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 73
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 73 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 74
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 74 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 75
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 75 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 76
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 76 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 76
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 77 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 77
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 77 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 78
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 78 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 78
17.2. Long Header Packet . . . . . . . . . . . . . . . . . . . 79 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 79
17.3. Short Header Packet . . . . . . . . . . . . . . . . . . 81 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 82
17.4. Version Negotiation Packet . . . . . . . . . . . . . . . 83 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 83
17.5. Initial Packet . . . . . . . . . . . . . . . . . . . . . 84 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 86
17.5.1. Abandoning Initial Packets . . . . . . . . . . . . . 86 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 87
17.5.2. Starting Packet Numbers . . . . . . . . . . . . . . 86 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 88
17.5.3. 0-RTT Packet Numbers . . . . . . . . . . . . . . . . 86 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 90
17.6. Handshake Packet . . . . . . . . . . . . . . . . . . . . 87 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 92
17.7. Retry Packet . . . . . . . . . . . . . . . . . . . . . . 88 18.1. Transport Parameter Definitions . . . . . . . . . . . . 94
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 90 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 97
18.1. Transport Parameter Definitions . . . . . . . . . . . . 92 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 97
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 94 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 97
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 95 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 97
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 95 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 99
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 95 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 101
19.3.1. ACK Block Section . . . . . . . . . . . . . . . . . 97 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 102
19.3.2. ECN section . . . . . . . . . . . . . . . . . . . . 99 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 102
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 100 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 103
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 100 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 104
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 101 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 104
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 102 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 106
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 102 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 106
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 104 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 107
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 104 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 108
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 105 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 109
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 106 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 109
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 107 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 110
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 107 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 111
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 108 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 112
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 109 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 112
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 110 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 113
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 110 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 114
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 111 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 114
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 112 20.1. Application Protocol Error Codes . . . . . . . . . . . . 115
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 112 21. Security Considerations . . . . . . . . . . . . . . . . . . . 116
20.1. Application Protocol Error Codes . . . . . . . . . . . . 113 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 116
21. Security Considerations . . . . . . . . . . . . . . . . . . . 114 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 117
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 114 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 117
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 115 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 117
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 115 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 118
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 115 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 118
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 116 21.7. Explicit Congestion Notification Attacks . . . . . . . . 119
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 116 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 119
21.7. Explicit Congestion Notification Attacks . . . . . . . . 117 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119
21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 117 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 119
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 121
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 117 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 122
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 119 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 125
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 120 23.1. Normative References . . . . . . . . . . . . . . . . . . 125
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 123 23.2. Informative References . . . . . . . . . . . . . . . . . 126
23.1. Normative References . . . . . . . . . . . . . . . . . . 123 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 128
23.2. Informative References . . . . . . . . . . . . . . . . . 124 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 128
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 126 B.1. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 128
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 126 B.2. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 129
B.1. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 126 B.3. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 130
B.2. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 128 B.4. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 130
B.3. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 128 B.5. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 131
B.4. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 128 B.6. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 132
B.5. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 129 B.7. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 133
B.6. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 130 B.8. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 133
B.7. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 130 B.9. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 134
B.8. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 131 B.10. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 134
B.9. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 131 B.11. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 135
B.10. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 132 B.12. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 136
B.11. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 133 B.13. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 136
B.12. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 133 B.14. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 136
B.13. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 133 B.15. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 137
B.14. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 134 B.16. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 137
B.15. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 134 B.17. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 138
B.16. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 135 B.18. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 140
B.17. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 137 B.19. Since draft-hamilton-quic-transport-protocol-01 . . . . . 140
B.18. Since draft-hamilton-quic-transport-protocol-01 . . . . . 137 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 141
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 138 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138
1. Introduction 1. Introduction
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
o Stream multiplexing o Stream multiplexing
o Stream and connection-level flow control o Stream and connection-level flow control
skipping to change at page 11, line 42 skipping to change at page 11, line 33
Note: These states are largely informative. This document uses Note: These states are largely informative. This document uses
stream states to describe rules for when and how different types stream states to describe rules for when and how different types
of frames can be sent and the reactions that are expected when of frames can be sent and the reactions that are expected when
different types of frames are received. Though these state different types of frames are received. Though these state
machines are intended to be useful in implementing QUIC, these machines are intended to be useful in implementing QUIC, these
states aren't intended to constrain implementations. An states aren't intended to constrain implementations. An
implementation can define a different state machine as long as its implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements behavior is consistent with an implementation that implements
these states. these states.
3.1. Send Stream States 3.1. Sending Stream States
Figure 1 shows the states for the part of a stream that sends data to Figure 1 shows the states for the part of a stream that sends data to
a peer. a peer.
o o
| Create Stream (Sending) | Create Stream (Sending)
| Peer Creates Bidirectional Stream | Peer Creates Bidirectional Stream
v v
+-------+ +-------+
| Ready | Send RESET_STREAM | Ready | Send RESET_STREAM
skipping to change at page 12, line 39 skipping to change at page 12, line 39
| Sent |------------------>| Sent | | Sent |------------------>| Sent |
+-------+ +-------+ +-------+ +-------+
| | | |
| Recv All ACKs | Recv ACK | Recv All ACKs | Recv ACK
v v v v
+-------+ +-------+ +-------+ +-------+
| Data | | Reset | | Data | | Reset |
| Recvd | | Recvd | | Recvd | | Recvd |
+-------+ +-------+ +-------+ +-------+
Figure 1: States for Send Streams Figure 1: States for Sending Parts of Streams
The sending part of stream that the endpoint initiates (types 0 and 2 The sending part of stream that the endpoint initiates (types 0 and 2
for clients, 1 and 3 for servers) is opened by the application. The for clients, 1 and 3 for servers) is opened by the application. The
"Ready" state represents a newly created stream that is able to "Ready" state represents a newly created stream that is able to
accept data from the application. Stream data might be buffered in accept data from the application. Stream data might be buffered in
this state in preparation for sending. this state in preparation for sending.
Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a send Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a
stream to enter the "Send" state. An implementation might choose to sending part of a stream to enter the "Send" state. An
defer allocating a stream ID to a send stream until it sends the implementation might choose to defer allocating a stream ID to a
first frame and enters this state, which can allow for better stream stream until it sends the first frame and enters this state, which
prioritization. can allow for better stream prioritization.
The sending part of a bidirectional stream initiated by a peer (type The sending part of a bidirectional stream initiated by a peer (type
0 for a server, type 1 for a client) enters the "Ready" state then 0 for a server, type 1 for a client) enters the "Ready" state then
immediately transitions to the "Send" state if the receiving part immediately transitions to the "Send" state if the receiving part
enters the "Recv" state (Section 3.2). enters the "Recv" state (Section 3.2).
In the "Send" state, an endpoint transmits - and retransmits as In the "Send" state, an endpoint transmits - and retransmits as
necessary - stream data in STREAM frames. The endpoint respects the necessary - stream data in STREAM frames. The endpoint respects the
flow control limits set by its peer, and continues to accept and flow control limits set by its peer, and continues to accept and
process MAX_STREAM_DATA frames. An endpoint in the "Send" state process MAX_STREAM_DATA frames. An endpoint in the "Send" state
generates STREAM_DATA_BLOCKED frames if it is blocked from sending by generates STREAM_DATA_BLOCKED frames if it is blocked from sending by
stream or connection flow control limits Section 4.1. stream or connection flow control limits Section 4.1.
After the application indicates that all stream data has been sent After the application indicates that all stream data has been sent
and a STREAM frame containing the FIN bit is sent, the send stream and a STREAM frame containing the FIN bit is sent, the sending part
enters the "Data Sent" state. From this state, the endpoint only of the stream enters the "Data Sent" state. From this state, the
retransmits stream data as necessary. The endpoint does not need to endpoint only retransmits stream data as necessary. The endpoint
check flow control limits or send STREAM_DATA_BLOCKED frames for a does not need to check flow control limits or send
send stream in this state. MAX_STREAM_DATA frames might be received STREAM_DATA_BLOCKED frames for a stream in this state.
until the peer receives the final stream offset. The endpoint can MAX_STREAM_DATA frames might be received until the peer receives the
safely ignore any MAX_STREAM_DATA frames it receives from its peer final stream offset. The endpoint can safely ignore any
for a stream in this state. MAX_STREAM_DATA frames it receives from its peer for a stream in this
state.
Once all stream data has been successfully acknowledged, the send Once all stream data has been successfully acknowledged, the sending
stream enters the "Data Recvd" state, which is a terminal state. part of the stream enters the "Data Recvd" state, which is a terminal
state.
From any of the "Ready", "Send", or "Data Sent" states, an From any of the "Ready", "Send", or "Data Sent" states, an
application can signal that it wishes to abandon transmission of application can signal that it wishes to abandon transmission of
stream data. Alternatively, an endpoint might receive a STOP_SENDING stream data. Alternatively, an endpoint might receive a STOP_SENDING
frame from its peer. In either case, the endpoint sends a frame from its peer. In either case, the endpoint sends a
RESET_STREAM frame, which causes the stream to enter the "Reset Sent" RESET_STREAM frame, which causes the stream to enter the "Reset Sent"
state. state.
An endpoint MAY send a RESET_STREAM as the first frame on a send An endpoint MAY send a RESET_STREAM as the first frame that mentions
stream; this causes the send stream to open and then immediately a stream; this causes the sending part of that stream to open and
transition to the "Reset Sent" state. then immediately transition to the "Reset Sent" state.
Once a packet containing a RESET_STREAM has been acknowledged, the Once a packet containing a RESET_STREAM has been acknowledged, the
send stream enters the "Reset Recvd" state, which is a terminal sending part of the stream enters the "Reset Recvd" state, which is a
state. terminal state.
3.2. Receive Stream States 3.2. Receiving Stream States
Figure 2 shows the states for the part of a stream that receives data Figure 2 shows the states for the part of a stream that receives data
from a peer. The states for a receive stream mirror only some of the from a peer. The states for a receiving part of a stream mirror only
states of the send stream at the peer. A receive stream does not some of the states of the sending part of the stream at the peer.
track states on the send stream that cannot be observed, such as the The receiving part of a stream does not track states on the sending
"Ready" state. Instead, receive streams track the delivery of data part that cannot be observed, such as the "Ready" state. Instead,
to the application, some of which cannot be observed by the sender. the receiving part of a stream tracks the delivery of data to the
application, some of which cannot be observed by the sender.
o o
| Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
| Create Bidirectional Stream (Sending) | Create Bidirectional Stream (Sending)
| Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional)
| Create Higher-Numbered Stream | Create Higher-Numbered Stream
v v
+-------+ +-------+
| Recv | Recv RESET_STREAM | Recv | Recv RESET_STREAM
| |-----------------------. | |-----------------------.
skipping to change at page 14, line 37 skipping to change at page 14, line 40
| Recvd | Recv All Data | Recvd | | Recvd | Recv All Data | Recvd |
+-------+<-- (optional) ----+-------+ +-------+<-- (optional) ----+-------+
| | | |
| App Read All Data | App Read RST | App Read All Data | App Read RST
v v v v
+-------+ +-------+ +-------+ +-------+
| Data | | Reset | | Data | | Reset |
| Read | | Read | | Read | | Read |
+-------+ +-------+ +-------+ +-------+
Figure 2: States for Receive Streams Figure 2: States for Receiving Parts of Streams
The receiving part of a stream initiated by a peer (types 1 and 3 for The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) is created when the first STREAM, a client, or 0 and 2 for a server) is created when the first STREAM,
STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream. STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream.
For bidirectional streams initiated by a peer, receipt of a For bidirectional streams initiated by a peer, receipt of a
MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
stream also creates the receiving part. The initial state for a stream also creates the receiving part. The initial state for the
receive stream is "Recv". receiving part of stream is "Recv".
The receive stream enters the "Recv" state when the sending part of a The receiving part of a stream enters the "Recv" state when the
bidirectional stream initiated by the endpoint (type 0 for a client, sending part of a bidirectional stream initiated by the endpoint
type 1 for a server) enters the "Ready" state. (type 0 for a client, type 1 for a server) enters the "Ready" state.
An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or
STOP_SENDING frame is received from the peer for that stream. STOP_SENDING frame is received from the peer for that stream.
Receiving a MAX_STREAM_DATA frame for an unopened stream indicates Receiving a MAX_STREAM_DATA frame for an unopened stream indicates
that the remote peer has opened the stream and is providing flow that the remote peer has opened the stream and is providing flow
control credit. Receiving a STOP_SENDING frame for an unopened control credit. Receiving a STOP_SENDING frame for an unopened
stream indicates that the remote peer no longer wishes to receive stream indicates that the remote peer no longer wishes to receive
data on this stream. Either frame might arrive before a STREAM or data on this stream. Either frame might arrive before a STREAM or
STREAM_DATA_BLOCKED frame if packets are lost or reordered. STREAM_DATA_BLOCKED frame if packets are lost or reordered.
Before creating a stream, all streams of the same type with lower- Before creating a stream, all streams of the same type with lower-
numbered stream IDs MUST be created. This ensures that the creation numbered stream IDs MUST be created. This ensures that the creation
order for streams is consistent on both endpoints. order for streams is consistent on both endpoints.
In the "Recv" state, the endpoint receives STREAM and In the "Recv" state, the endpoint receives STREAM and
STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be
reassembled into the correct order for delivery to the application. reassembled into the correct order for delivery to the application.
As data is consumed by the application and buffer space becomes As data is consumed by the application and buffer space becomes
available, the endpoint sends MAX_STREAM_DATA frames to allow the available, the endpoint sends MAX_STREAM_DATA frames to allow the
peer to send more data. peer to send more data.
When a STREAM frame with a FIN bit is received, the final offset is When a STREAM frame with a FIN bit is received, the final size of the
known (see Section 4.4). The receive stream enters the "Size Known" stream is known (see Section 4.4). The receiving part of the stream
state. In this state, the endpoint no longer needs to send then enters the "Size Known" state. In this state, the endpoint no
MAX_STREAM_DATA frames, it only receives any retransmissions of longer needs to send MAX_STREAM_DATA frames, it only receives any
stream data. retransmissions of stream data.
Once all data for the stream has been received, the receive stream Once all data for the stream has been received, the receiving part
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
Known". In this state, the endpoint has all stream data. Any STREAM Known". In this state, the endpoint has all stream data. Any STREAM
or STREAM_DATA_BLOCKED frames it receives for the stream can be or STREAM_DATA_BLOCKED frames it receives for the stream can be
discarded. discarded.
The "Data Recvd" state persists until stream data has been delivered The "Data Recvd" state persists until stream data has been delivered
to the application. Once stream data has been delivered, the stream to the application. Once stream data has been delivered, the stream
enters the "Data Read" state, which is a terminal state. enters the "Data Read" state, which is a terminal state.
skipping to change at page 16, line 7 skipping to change at page 16, line 13
possible for remaining stream data to arrive after receiving a possible for remaining stream data to arrive after receiving a
RESET_STREAM frame (the "Reset Recvd" state). An implementation is RESET_STREAM frame (the "Reset Recvd" state). An implementation is
free to manage this situation as it chooses. Sending RESET_STREAM free to manage this situation as it chooses. Sending RESET_STREAM
means that an endpoint cannot guarantee delivery of stream data; means that an endpoint cannot guarantee delivery of stream data;
however there is no requirement that stream data not be delivered if however there is no requirement that stream data not be delivered if
a RESET_STREAM is received. An implementation MAY interrupt delivery a RESET_STREAM is received. An implementation MAY interrupt delivery
of stream data, discard any data that was not consumed, and signal of stream data, discard any data that was not consumed, and signal
the receipt of the RESET_STREAM immediately. Alternatively, the the receipt of the RESET_STREAM immediately. Alternatively, the
RESET_STREAM signal might be suppressed or withheld if stream data is RESET_STREAM signal might be suppressed or withheld if stream data is
completely received and is buffered to be read by the application. completely received and is buffered to be read by the application.
In the latter case, the receive stream transitions from "Reset Recvd" In the latter case, the receiving part of the stream transitions from
to "Data Recvd". "Reset Recvd" to "Data 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 stream was reset, the receiving part of the stream transitions to
"Reset Read" state, which is a terminal state. the "Reset Read" state, which is a terminal state.
3.3. Permitted Frame Types 3.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 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM
(Section 19.4). (Section 19.4).
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
skipping to change at page 16, line 41 skipping to change at page 16, line 47
The receiver only sends MAX_STREAM_DATA in the "Recv" state. A The receiver only sends MAX_STREAM_DATA in the "Recv" state. A
receiver can send STOP_SENDING in any state where it has not received receiver can send STOP_SENDING in any state where it has not received
a RESET_STREAM frame; that is states other than "Reset Recvd" or a RESET_STREAM frame; that is states other than "Reset Recvd" or
"Reset Read". However there is little value in sending a "Reset Read". However there is little value in sending a
STOP_SENDING frame in the "Data Recvd" state, since all stream data STOP_SENDING frame in the "Data Recvd" state, since all stream data
has been received. A sender could receive either of these two frames has been received. A sender could receive either of these two frames
in any state as a result of delayed delivery of packets. in any state as a result of delayed delivery of packets.
3.4. Bidirectional Stream States 3.4. Bidirectional Stream States
A bidirectional stream is composed of a send stream and a receive A bidirectional stream is composed of sending and receiving parts.
stream. Implementations may represent states of the bidirectional Implementations may represent states of the bidirectional stream as
stream as composites of send and receive stream states. The simplest composites of sending and receiving stream states. The simplest
model presents the stream as "open" when either send or receive model presents the stream as "open" when either sending or receiving
stream is in a non-terminal state and "closed" when both send and parts are in a non-terminal state and "closed" when both sending and
receive streams are in a terminal state. receiving streams are in terminal states.
Table 2 shows a more complex mapping of bidirectional stream states Table 2 shows a more complex mapping of bidirectional stream states
that loosely correspond to the stream states in HTTP/2 [HTTP2]. This that loosely correspond to the stream states in HTTP/2 [HTTP2]. This
shows that multiple states on send or receive streams are mapped to shows that multiple states on sending or receiving parts of streams
the same composite state. Note that this is just one possibility for are mapped to the same composite state. Note that this is just one
such a mapping; this mapping requires that data is acknowledged possibility for such a mapping; this mapping requires that data is
before the transition to a "closed" or "half-closed" state. acknowledged before the transition to a "closed" or "half-closed"
state.
+-----------------------+---------------------+---------------------+ +-----------------------+---------------------+---------------------+
| Send Stream | Receive Stream | Composite State | | Sending Part | Receiving Part | Composite State |
+-----------------------+---------------------+---------------------+ +-----------------------+---------------------+---------------------+
| No Stream/Ready | No Stream/Recv *1 | idle | | No Stream/Ready | No Stream/Recv *1 | idle |
| | | | | | | |
| Ready/Send/Data Sent | Recv/Size Known | open | | Ready/Send/Data Sent | Recv/Size Known | open |
| | | | | | | |
| Ready/Send/Data Sent | Data Recvd/Data | half-closed | | Ready/Send/Data Sent | Data Recvd/Data | half-closed |
| | Read | (remote) | | | Read | (remote) |
| | | | | | | |
| Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed |
| | Read | (remote) | | | Read | (remote) |
| | | | | | | |
| Data Recvd | Recv/Size Known | half-closed (local) | | Data Recvd | Recv/Size Known | half-closed (local) |
| | | | | | | |
| Reset Sent/Reset | Recv/Size Known | half-closed (local) | | Reset Sent/Reset | Recv/Size Known | half-closed (local) |
| Recvd | | | | Recvd | | |
| | | | | | | |
| Data Recvd | Recv/Size Known | half-closed (local) |
| | | |
| Reset Sent/Reset | Data Recvd/Data | closed | | Reset Sent/Reset | Data Recvd/Data | closed |
| Recvd | Read | | | Recvd | Read | |
| | | | | | | |
| Reset Sent/Reset | Reset Recvd/Reset | closed | | Reset Sent/Reset | Reset Recvd/Reset | closed |
| Recvd | Read | | | Recvd | Read | |
| | | | | | | |
| Data Recvd | Data Recvd/Data | closed | | Data Recvd | Data Recvd/Data | closed |
| | Read | | | | Read | |
| | | | | | | |
| Data Recvd | Reset Recvd/Reset | closed | | Data Recvd | Reset Recvd/Reset | closed |
| | Read | | | | Read | |
+-----------------------+---------------------+---------------------+ +-----------------------+---------------------+---------------------+
Table 2: Possible Mapping of Stream States to HTTP/2 Table 2: Possible Mapping of Stream States to HTTP/2
Note (*1): A stream is considered "idle" if it has not yet been Note (*1): A stream is considered "idle" if it has not yet been
created, or if the receive stream is in the "Recv" state without created, or if the receiving part of the stream is in the "Recv"
yet having received any frames. state without yet having received any frames.
3.5. Solicited State Transitions 3.5. Solicited State Transitions
If an endpoint is no longer interested in the data it is receiving on If an endpoint is no longer interested in the data it is receiving on
a stream, it MAY send a STOP_SENDING frame identifying that stream to a stream, it MAY send a STOP_SENDING frame identifying that stream to
prompt closure of the stream in the opposite direction. This prompt closure of the stream in the opposite direction. This
typically indicates that the receiving application is no longer typically indicates that the receiving application is no longer
reading data it receives from the stream, but it is not a guarantee reading data it receives from the stream, but it is not a guarantee
that incoming data will be ignored. that incoming data will be ignored.
STREAM frames received after sending STOP_SENDING are still counted STREAM frames received after sending STOP_SENDING are still counted
toward connection and stream flow control, even though these frames toward connection and stream flow control, even though these frames
will be discarded upon receipt. will be discarded upon receipt.
A STOP_SENDING frame requests that the receiving endpoint send a A STOP_SENDING frame requests that the receiving endpoint send a
RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame
MUST send a RESET_STREAM frame for that stream. An endpoint SHOULD MUST send a RESET_STREAM frame if the stream is in the Ready or Send
copy the error code from the STOP_SENDING frame, but MAY use any state. If the stream is in the Data Sent state and any outstanding
application error code. The endpoint that sends a STOP_SENDING frame data is declared lost, an endpoint SHOULD send a RESET_STREAM frame
can ignore the error code carried in any RESET_STREAM frame it in lieu of a retransmission.
receives.
If the STOP_SENDING frame is received on a send stream that is An endpoint SHOULD copy the error code from the STOP_SENDING frame to
already in the "Data Sent" state, an endpoint that wishes to cease the RESET_STREAM frame it sends, but MAY use any application error
code. The endpoint that sends a STOP_SENDING frame MAY ignore the
error code carried in any RESET_STREAM frame it receives.
If the STOP_SENDING frame is received on a stream that is already in
the "Data Sent" state, an endpoint that wishes to cease
retransmission of previously-sent STREAM frames on that stream MUST retransmission of previously-sent STREAM frames on that stream MUST
first send a RESET_STREAM frame. first send a RESET_STREAM frame.
STOP_SENDING SHOULD only be sent for a receive stream that has not STOP_SENDING SHOULD only be sent for a stream that has not been reset
been reset. STOP_SENDING is most useful for streams in the "Recv" or by the peer. STOP_SENDING is most useful for streams in the "Recv"
"Size Known" states. or "Size Known" states.
An endpoint is expected to send another STOP_SENDING frame if a An endpoint is expected to send another STOP_SENDING frame if a
packet containing a previous STOP_SENDING is lost. However, once packet containing a previous STOP_SENDING is lost. However, once
either all stream data or a RESET_STREAM frame has been received for either all stream data or a RESET_STREAM frame has been received for
the stream - that is, the stream is in any state other than "Recv" or the stream - that is, the stream is in any state other than "Recv" or
"Size Known" - sending a STOP_SENDING frame is unnecessary. "Size Known" - sending a STOP_SENDING frame is unnecessary.
An endpoint that wishes to terminate both directions of a An endpoint that wishes to terminate both directions of a
bidirectional stream can terminate one direction by sending a bidirectional stream can terminate one direction by sending a
RESET_STREAM, and it can encourage prompt termination in the opposite RESET_STREAM, and it can encourage prompt termination in the opposite
skipping to change at page 20, line 44 skipping to change at page 21, line 5
This document leaves when and how many bytes to advertise in a This document leaves when and how many bytes to advertise in a
MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a
few considerations. These frames contribute to connection overhead. few considerations. These frames contribute to connection overhead.
Therefore frequently sending frames with small changes is Therefore frequently sending frames with small changes is
undesirable. At the same time, larger increments to limits are undesirable. At the same time, larger increments to limits are
necessary to avoid blocking if updates are less frequent, requiring necessary to avoid blocking if updates are less frequent, requiring
larger resource commitments at the receiver. Thus there is a trade- larger resource commitments at the receiver. Thus there is a trade-
off between resource commitment and overhead when determining how off between resource commitment and overhead when determining how
large a limit is advertised. large a limit is advertised.
A receiver MAY use an autotuning mechanism to tune the frequency and A receiver can use an autotuning mechanism to tune the frequency and
amount of advertised additional credit based on a round-trip time amount of advertised additional credit based on a round-trip 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. As an optimization,
sending frames related to flow control only when there are other
frames to send or when a peer is blocked ensures that flow control
doesn't cause extra packets to be sent.
If a sender runs out of flow control credit, it will be unable to If a sender runs out of flow control credit, it will be unable to
send new data and is considered blocked. It is generally considered send new data and is considered blocked. It is generally considered
best to not let the sender become blocked. To avoid blocking a best to not let the sender become blocked. To avoid blocking a
sender, and to reasonably account for the possibility of loss, a sender, and to reasonably account for the possibility of loss, a
receiver should send a MAX_DATA or MAX_STREAM_DATA frame at least two receiver should send a MAX_DATA or MAX_STREAM_DATA frame at least two
round trips before it expects the sender to get blocked. round trips before it expects the sender to get blocked.
A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED
frame before sending MAX_STREAM_DATA or MAX_DATA, since doing so will frame before sending MAX_STREAM_DATA or MAX_DATA, since doing so will
skipping to change at page 21, line 28 skipping to change at page 21, line 41
On receipt of a RESET_STREAM frame, an endpoint will tear down state On receipt of a RESET_STREAM frame, an endpoint will tear down state
for the matching stream and ignore further data arriving on that for the matching stream and ignore further data arriving on that
stream. If a RESET_STREAM frame is reordered with stream data for stream. If a RESET_STREAM frame is reordered with stream data for
the same stream, the receiver's estimate of the number of bytes the same stream, the receiver's estimate of the number of bytes
received on that stream can be lower than the sender's estimate of received on that stream can be lower than the sender's estimate of
the number sent. As a result, the two endpoints could disagree on the number sent. As a result, the two endpoints could disagree on
the number of bytes that count towards connection flow control. the number of bytes that count towards connection flow control.
To remedy this issue, a RESET_STREAM frame (Section 19.4) includes To remedy this issue, a RESET_STREAM frame (Section 19.4) includes
the final offset of data sent on the stream. On receiving a the final size of data sent on the stream. On receiving a
RESET_STREAM frame, a receiver definitively knows how many bytes were RESET_STREAM frame, a receiver definitively knows how many bytes were
sent on that stream before the RESET_STREAM frame, and the receiver sent on that stream before the RESET_STREAM frame, and the receiver
MUST use the final offset to account for all bytes sent on the stream MUST use the final size of the stream to account for all bytes sent
in its connection level flow controller. on the stream in its connection level flow controller.
RESET_STREAM terminates one direction of a stream abruptly. For a RESET_STREAM terminates one direction of a stream abruptly. For a
bidirectional stream, RESET_STREAM has no effect on data flow in the bidirectional stream, RESET_STREAM has no effect on data flow in the
opposite direction. Both endpoints MUST maintain flow control state opposite direction. Both endpoints MUST maintain flow control state
for the stream in the unterminated direction until that direction for the stream in the unterminated direction until that direction
enters a terminal state, or until one of the endpoints sends enters a terminal state, or until one of the endpoints sends
CONNECTION_CLOSE. CONNECTION_CLOSE.
4.4. Stream Final Offset 4.4. Stream Final Size
The final offset is the count of the number of bytes that are The final size is the amount of flow control credit that is consumed
transmitted on a stream. For a stream that is reset, the final by a stream. Assuming that every contiguous byte on the stream was
offset is carried explicitly in a RESET_STREAM frame. Otherwise, the sent once, the final size is the number of bytes sent. More
final offset is the offset of the end of the data carried in a STREAM generally, this is one higher than the largest byte offset sent on
frame marked with a FIN flag, or 0 in the case of incoming the stream.
unidirectional streams.
An endpoint will know the final offset for a stream when the receive For a stream that is reset, the final size is carried explicitly in a
stream enters the "Size Known" or "Reset Recvd" state (Section 3). RESET_STREAM frame. Otherwise, the final size is the offset plus the
length of a STREAM frame marked with a FIN flag, or 0 in the case of
incoming unidirectional streams.
An endpoint will know the final size for a stream when the receiving
part of the stream enters the "Size Known" or "Reset Recvd" state
(Section 3).
An endpoint MUST NOT send data on a stream at or beyond the final An endpoint MUST NOT send data on a stream at or beyond the final
offset. size.
Once a final offset for a stream is known, it cannot change. If a Once a final size for a stream is known, it cannot change. If a
RESET_STREAM or STREAM frame is received indicating a change in the RESET_STREAM or STREAM frame is received indicating a change in the
final offset for the stream, an endpoint SHOULD respond with a final size for the stream, an endpoint SHOULD respond with a
FINAL_OFFSET_ERROR error (see Section 11). A receiver SHOULD treat FINAL_SIZE_ERROR error (see Section 11). A receiver SHOULD treat
receipt of data at or beyond the final offset as a FINAL_OFFSET_ERROR receipt of data at or beyond the final size as a FINAL_SIZE_ERROR
error, even after a stream is closed. Generating these errors is not error, even after a stream is closed. Generating these errors is not
mandatory, but only because requiring that an endpoint generate these mandatory, but only because requiring that an endpoint generate these
errors also means that the endpoint needs to maintain the final errors also means that the endpoint needs to maintain the final size
offset state for closed streams, which could mean a significant state state for closed streams, which could mean a significant state
commitment. commitment.
4.5. Controlling Concurrency 4.5. Controlling Concurrency
An endpoint limits the cumulative number of incoming streams a peer An endpoint limits the cumulative number of incoming streams a peer
can open. Only streams with a stream ID less than (max_stream * 4 + can open. Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened (see Table 5). Initial initial_stream_id_for_type) can be opened (see Table 5). Initial
limits are set in the transport parameters (see Section 18.1) and limits are set in the transport parameters (see Section 18.1) and
subsequently limits are advertised using MAX_STREAMS frames subsequently limits are advertised using MAX_STREAMS frames
(Section 19.11). Separate limits apply to unidirectional and (Section 19.11). Separate limits apply to unidirectional and
skipping to change at page 23, line 48 skipping to change at page 24, line 18
Packets with short headers (Section 17.3) only include the Packets with short headers (Section 17.3) only include the
Destination Connection ID and omit the explicit length. The length Destination Connection ID and omit the explicit length. The length
of the Destination Connection ID field is expected to be known to of the Destination Connection ID field is expected to be known to
endpoints. Endpoints using a load balancer that routes based on endpoints. Endpoints using a load balancer that routes based on
connection ID could agree with the load balancer on a fixed length connection ID could agree with the load balancer on a fixed length
for connection IDs, or agree on an encoding scheme. A fixed portion for connection IDs, or agree on an encoding scheme. A fixed portion
could encode an explicit length, which allows the entire connection could encode an explicit length, which allows the entire connection
ID to vary in length and still be used by the load balancer. ID to vary in length and still be used by the load balancer.
A Version Negotiation (Section 17.4) packet echoes the connection IDs A Version Negotiation (Section 17.2.1) packet echoes the connection
selected by the client, both to ensure correct routing toward the IDs selected by the client, both to ensure correct routing toward the
client and to allow the client to validate that the packet is in client and to allow the client to validate that the packet is in
response to an Initial packet. response to an Initial packet.
A zero-length connection ID MAY be used when the connection ID is not A zero-length connection ID MAY be used when the connection ID is not
needed for routing and the address/port tuple of packets is needed for routing and the address/port tuple of packets is
sufficient to identify a connection. An endpoint whose peer has sufficient to identify a connection. An endpoint whose peer has
selected a zero-length connection ID MUST continue to use a zero- selected a zero-length connection ID MUST continue to use a zero-
length connection ID for the lifetime of the connection and MUST NOT length connection ID for the lifetime of the connection and MUST NOT
send packets from any other local address. send packets from any other local address.
skipping to change at page 25, line 44 skipping to change at page 26, line 14
Hosts try to associate a packet with an existing connection. If the Hosts try to associate a packet with an existing connection. If the
packet has a Destination Connection ID corresponding to an existing packet has a Destination Connection ID corresponding to an existing
connection, QUIC processes that packet accordingly. Note that more connection, QUIC processes that packet accordingly. Note that more
than one connection ID can be associated with a connection; see than one connection ID can be associated with a connection; see
Section 5.1. Section 5.1.
If the Destination Connection ID is zero length and the packet If the Destination Connection ID is zero length and the packet
matches the address/port tuple of a connection where the host did not matches the address/port tuple of a connection where the host did not
require connection IDs, QUIC processes the packet as part of that require connection IDs, QUIC processes the packet as part of that
connection. Endpoints MUST drop packets with zero-length Destination connection. Endpoints SHOULD either reject connection attempts that
Connection ID fields if they do not correspond to a single use the same addresses as existing connections, or use a non-zero-
connection. length Destination Connection ID so that packets can be correctly
attributed to connections.
Endpoints can send a Stateless Reset (Section 10.4) for any packets Endpoints can send a Stateless Reset (Section 10.4) for any packets
that cannot be attributed to an existing connection. A stateless that cannot be attributed to an existing connection. A stateless
reset allows a peer to more quickly identify when a connection reset allows a peer to more quickly identify when a connection
becomes unusable. becomes unusable.
Packets that are matched to an existing connection, but for which the Packets that are matched to an existing connection, but for which the
endpoint cannot remove packet protection, are discarded. endpoint cannot remove packet protection, are discarded.
Invalid packets without packet protection, such as Initial, Retry, or
Version Negotiation, MAY be discarded. An endpoint MUST generate a
connection error if it commits changes to state before discovering an
error.
5.2.1. Client Packet Handling 5.2.1. Client Packet Handling
Valid packets sent to clients always include a Destination Connection Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects. Clients that choose to ID that matches a value the client selects. Clients that choose to
receive zero-length connection IDs can use the address/port tuple to receive zero-length connection IDs can use the address/port tuple to
identify a connection. Packets that don't match an existing identify a connection. Packets that don't match an existing
connection are discarded. connection are discarded.
Due to packet reordering or loss, clients might receive packets for a Due to packet reordering or loss, clients might receive packets for a
connection that are encrypted with a key it has not yet computed. connection that are encrypted with a key it has not yet computed.
skipping to change at page 28, line 9 skipping to change at page 28, line 30
a server sends a Version Negotiation packet. Clients that support a server sends a Version Negotiation packet. Clients that support
multiple QUIC versions SHOULD pad the first packet they send to the multiple QUIC versions SHOULD pad the first packet they send to the
largest of the minimum packet sizes across all versions they support. largest of the minimum packet sizes across all versions they support.
This ensures that the server responds if there is a mutually This ensures that the server responds if there is a mutually
supported version. supported version.
6.1. Sending Version Negotiation Packets 6.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 (see server, the server responds with a Version Negotiation packet (see
Section 17.4). This includes a list of versions that the server will Section 17.2.1). This includes a list of versions that the server
accept. An endpoint MUST NOT send a Version Negotiation packet in will accept. An endpoint MUST NOT send a Version Negotiation packet
response to receiving a Version Negotiation packet. in response to receiving a Version Negotiation packet.
This system allows a server to process packets with unsupported This system allows a server to process packets with unsupported
versions without retaining state. Though either the Initial packet versions without retaining state. Though either the Initial packet
or the Version Negotiation packet that is sent in response could be 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.
A server MAY limit the number of Version Negotiation packets it A server MAY limit the number of Version Negotiation packets it
sends. For instance, a server that is able to recognize packets as sends. For instance, a server that is able to recognize packets as
0-RTT might choose not to send Version Negotiation packets in 0-RTT might choose not to send Version Negotiation packets in
skipping to change at page 29, line 6 skipping to change at page 29, line 27
A client MUST NOT change the version it uses unless it is in response A client MUST NOT change the version it uses unless it is in response
to a Version Negotiation packet from the server. Once a client to a Version Negotiation packet from the server. Once a client
receives a packet from the server which is not a Version Negotiation receives a packet from the server which is not a Version Negotiation
packet, it MUST discard other Version Negotiation packets on the same packet, it MUST discard other Version Negotiation packets on the same
connection. Similarly, a client MUST ignore a Version Negotiation connection. Similarly, a client MUST ignore a Version Negotiation
packet if it has already received and acted on a Version Negotiation packet if it has already received and acted on a Version Negotiation
packet. packet.
A client MUST ignore a Version Negotiation packet that lists the A client MUST ignore a Version Negotiation packet that lists the
client's chosen version. client's chosen version. If the client does not support any of the
versions the server offers, it aborts the connection attempt.
A client MAY attempt 0-RTT after receiving a Version Negotiation A client MAY attempt 0-RTT after receiving a Version Negotiation
packet. A client that sends additional 0-RTT packets MUST NOT reset packet. A client that sends additional 0-RTT packets MUST NOT reset
the packet number to 0 as a result, see Section 17.5.3. the packet number to 0 as a result, see Section 17.2.3.
Version negotiation packets have no cryptographic protection. The Version negotiation packets have no cryptographic protection. The
result of the negotiation MUST be revalidated as part of the result of the negotiation MUST be revalidated as part of the
cryptographic handshake (see Section 7.3.3). cryptographic handshake (see Section 7.3.3).
6.3. Using Reserved Versions 6.3. Using Reserved Versions
For a server to use a new version in the future, clients must For a server to use a new version in the future, clients must
correctly handle unsupported versions. To help ensure this, a server correctly handle unsupported versions. To help ensure this, a server
SHOULD include a reserved version (see Section 15) while generating a SHOULD include a reserved version (see Section 15) while generating a
skipping to change at page 30, line 38 skipping to change at page 31, line 13
protocol. protocol.
An endpoint can verify support for Explicit Congestion Notification An endpoint can verify support for Explicit Congestion Notification
(ECN) in the first packets it sends, as described in Section 13.3.2. (ECN) in the first packets it sends, as described in Section 13.3.2.
The CRYPTO frame can be sent in different packet number spaces. The The CRYPTO frame can be sent in different packet number spaces. The
sequence numbers used by CRYPTO frames to ensure ordered delivery of sequence numbers used by CRYPTO frames to ensure ordered delivery of
cryptographic handshake data start from zero in each packet number cryptographic handshake data start from zero in each packet number
space. space.
Endpoints MUST explicitly negotiate an application protocol. This
avoids situations where there is a disagreement about the protocol
that is in use.
7.1. Example Handshake Flows 7.1. Example Handshake Flows
Details of how TLS is integrated with QUIC are provided in Details of how TLS is integrated with QUIC are provided in
[QUIC-TLS], but some examples are provided here. An extension of [QUIC-TLS], but some examples are provided here. An extension of
this exchange to support client address validation is shown in this exchange to support client address validation is shown in
Section 8.1.1. Section 8.1.1.
Once any version negotiation and address validation exchanges are Once any version negotiation and address validation exchanges are
complete, the cryptographic handshake is used to agree on complete, the cryptographic handshake is used to agree on
cryptographic keys. The cryptographic handshake is carried in cryptographic keys. The cryptographic handshake is carried in
Initial (Section 17.5) and Handshake (Section 17.6) packets. Initial (Section 17.2.2) and Handshake (Section 17.2.4) packets.
Figure 4 provides an overview of the 1-RTT handshake. Each line Figure 4 provides an overview of the 1-RTT handshake. Each line
shows a QUIC packet with the packet type and packet number shown shows a QUIC packet with the packet type and packet number shown
first, followed by the frames that are typically contained in those first, followed by the frames that are typically contained in those
packets. So, for instance the first packet is of type Initial, with packets. So, for instance the first packet is of type Initial, with
packet number 0, and contains a CRYPTO frame carrying the packet number 0, and contains a CRYPTO frame carrying the
ClientHello. ClientHello.
Note that multiple QUIC packets - even of different encryption levels Note that multiple QUIC packets - even of different encryption levels
- may be coalesced into a single UDP datagram (see Section 12.2), and - may be coalesced into a single UDP datagram (see Section 12.2), and
skipping to change at page 34, line 6 skipping to change at page 34, line 31
The encoding of the transport parameters is detailed in Section 18. The encoding of the transport parameters is detailed in Section 18.
QUIC includes the encoded transport parameters in the cryptographic QUIC includes the encoded transport parameters in the cryptographic
handshake. Once the handshake completes, the transport parameters handshake. Once the handshake completes, the transport parameters
declared by the peer are available. Each endpoint validates the declared by the peer are available. Each endpoint validates the
value provided by its peer. In particular, version negotiation MUST value provided by its peer. In particular, version negotiation MUST
be validated (see Section 7.3.3) before the connection establishment be validated (see Section 7.3.3) before the connection establishment
is considered properly complete. is considered properly complete.
Definitions for each of the defined transport parameters are included Definitions for each of the defined transport parameters are included
in Section 18.1. Any given parameter MUST appear at most once in a in Section 18.1. An endpoint MUST treat receipt of a transport
given transport parameters extension. An endpoint MUST treat receipt parameter with an invalid value as a connection error of type
of duplicate transport parameters as a connection error of type TRANSPORT_PARAMETER_ERROR. Any given parameter MUST appear at most
TRANSPORT_PARAMETER_ERROR. once in a given transport parameters extension. An endpoint MUST
treat receipt of duplicate transport parameters as a connection error
of type TRANSPORT_PARAMETER_ERROR.
A server MUST include the original_connection_id transport parameter A server MUST include the original_connection_id transport parameter
(Section 18.1) if it sent a Retry packet to enable validation of the (Section 18.1) if it sent a Retry packet to enable validation of the
Retry, as described in Section 17.7. Retry, as described in Section 17.2.5.
7.3.1. Values of Transport Parameters for 0-RTT 7.3.1. 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
during that handshake. Remembered transport parameters apply to the during that handshake. Remembered transport parameters apply to the
new connection until the handshake completes and new transport new connection until the handshake completes and new transport
parameters from the server can be provided. parameters from the server can be provided.
skipping to change at page 35, line 44 skipping to change at page 36, line 26
retroactively authenticate the choice of version (see Section 6). retroactively authenticate the choice of version (see Section 6).
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 18.1). As a result, attacks on version negotiation by an Section 18.1). 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 17.4, this will be identical to the Negotiation packet Section 17.2.1, 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.
skipping to change at page 36, line 31 skipping to change at page 37, line 10
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
that it accepts (not an Initial packet that triggers a Retry or that it accepts (not an Initial packet that triggers a Retry or
Version Negotiation packet). A client that receives a Version Negotiation packet). A client that receives a
negotiated_version that does not match the version of QUIC that is in negotiated_version that does not match the version of QUIC that is in
use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR
error code. error code.
The server includes a list of versions that it would send in any The server includes a list of versions that it would send in any
version negotiation packet (Section 17.4) in the supported_versions version negotiation packet (Section 17.2.1) in the supported_versions
field. The server populates this field even if it did not send a field. The server populates this field even if it did not send a
version negotiation packet. version negotiation packet.
The client validates that the negotiated_version is included in the The client validates that the negotiated_version is included in the
supported_versions list and - if version negotiation was performed - supported_versions list and - if version negotiation was performed -
that it would have selected the negotiated version. A client MUST that it would have selected the negotiated version. A client MUST
terminate the connection with a VERSION_NEGOTIATION_ERROR error code terminate the connection with a VERSION_NEGOTIATION_ERROR error code
if the current QUIC version is not listed in the supported_versions if the current QUIC version is not listed in the supported_versions
list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error
code if version negotiation occurred but it would have selected a code if version negotiation occurred but it would have selected a
skipping to change at page 37, line 41 skipping to change at page 38, line 26
received. This limits the magnitude of any amplification attack that received. This limits the magnitude of any amplification attack that
can be mounted using spoofed source addresses. In determining this can be mounted using spoofed source addresses. In determining this
limit, servers only count the size of successfully processed packets. limit, servers only count the size of successfully processed packets.
Clients MUST pad UDP datagrams that contain only Initial packets to Clients MUST pad UDP datagrams that contain only Initial packets to
at least 1200 bytes. Once a client has received an acknowledgment at least 1200 bytes. Once a client has received an acknowledgment
for a Handshake packet it MAY send smaller datagrams. Sending padded for a Handshake packet it MAY send smaller datagrams. Sending padded
datagrams ensures that the server is not overly constrained by the datagrams ensures that the server is not overly constrained by the
amplification restriction. amplification restriction.
In order to prevent a handshake deadlock as a result of the server Packet loss, in particular loss of a Handshake packet from the
being unable to send, clients SHOULD send a packet upon a handshake server, can cause a situation in which the server cannot send when
timeout, as described in [QUIC-RECOVERY]. If the client has no data the client has no data to send and the anti-amplification limit is
to retransmit and does not have Handshake keys, it SHOULD send an reached. In order to avoid this causing a handshake deadlock,
Initial packet in a UDP datagram of at least 1200 bytes. If the clients SHOULD send a packet upon a handshake timeout, as described
client has Handshake keys, it SHOULD send a Handshake packet. in [QUIC-RECOVERY]. If the client has no data to retransmit and does
not have Handshake keys, it SHOULD send an Initial packet in a UDP
datagram of at least 1200 bytes. If the client has Handshake keys,
it SHOULD send a Handshake packet.
A server might wish to validate the client address before starting A server might wish to validate the client address before starting
the cryptographic handshake. QUIC uses a token in the Initial packet the cryptographic handshake. QUIC uses a token in the Initial packet
to provide address validation prior to completing the handshake. to provide address validation prior to completing the handshake.
This token is delivered to the client during connection establishment This token is delivered to the client during connection establishment
with a Retry packet (see Section 8.1.1) or in a previous connection with a Retry packet (see Section 8.1.1) or in a previous connection
using the NEW_TOKEN frame (see Section 8.1.2). using the NEW_TOKEN frame (see Section 8.1.2).
In addition to sending limits imposed prior to address validation,
servers are also constrained in what they can send by the limits set
by the congestion controller. Clients are only constrained by the
congestion controller.
8.1.1. Address Validation using Retry Packets 8.1.1. Address Validation using Retry Packets
Upon receiving the client's Initial packet, the server can request Upon receiving the client's Initial packet, the server can request
address validation by sending a Retry packet (Section 17.7) address validation by sending a Retry packet (Section 17.2.5)
containing a token. This token MUST be repeated by the client in all containing a token. This token MUST be repeated by the client in all
Initial packets it sends after it receives the Retry packet. In Initial packets it sends after it receives the Retry packet. In
response to processing an Initial containing a token, a server can response to processing an Initial containing a token, a server can
either abort the connection or permit it to proceed. either abort the connection or permit it to proceed.
As long as it is not possible for an attacker to generate a valid As long as it is not possible for an attacker to generate a valid
token for its own address (see Section 8.1.3) and the client is able token for its own address (see Section 8.1.3) and the client is able
to return that token, it proves to the server that it received the to return that token, it proves to the server that it received the
token. token.
skipping to change at page 39, line 17 skipping to change at page 40, line 7
future connections. The client includes this token in Initial future connections. The client includes this token in Initial
packets to provide address validation in a future connection. The packets to provide address validation in a future connection. The
client MUST include the token in all Initial packets it sends, unless client MUST include the token in all Initial packets it sends, unless
a Retry replaces the token with a newer token. The client MUST NOT a Retry replaces the token with a newer token. The client MUST NOT
use the token provided in a Retry for future connections. Servers use the token provided in a Retry for future connections. Servers
MAY discard any Initial packet that does not carry the expected MAY discard any Initial packet that does not carry the expected
token. token.
Unlike the token that is created for a Retry packet, there might be Unlike the token that is created for a Retry packet, there might be
some time between when the token is created and when the token is some time between when the token is created and when the token is
subsequently used. Thus, a resumption token SHOULD include an subsequently used. Thus, a token SHOULD include an expiration time.
expiration time. The server MAY include either an explicit The server MAY include either an explicit expiration time or an
expiration time or an issued timestamp and dynamically calculate the issued timestamp and dynamically calculate the expiration time. It
expiration time. It is also unlikely that the client port number is is also unlikely that the client port number is the same on two
the same on two different connections; validating the port is different connections; validating the port is therefore unlikely to
therefore unlikely to be successful. be successful.
A resumption token SHOULD be constructed to be easily distinguishable A token SHOULD be constructed to be easily distinguishable from
from tokens that are sent in Retry packets as they are carried in the tokens that are sent in Retry packets as they are carried in the same
same field. field.
If the client has a token received in a NEW_TOKEN frame on a previous If the client has a token received in a NEW_TOKEN frame on a previous
connection to what it believes to be the same server, it can include connection to what it believes to be the same server, it can include
that value in the Token field of its Initial packet. that value in the Token field of its Initial packet.
A token allows a server to correlate activity between the connection A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used. where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server MAY Clients that want to break continuity of identity with a server MAY
discard tokens provided using the NEW_TOKEN frame. Tokens obtained discard tokens provided using the NEW_TOKEN frame. A token obtained
in Retry packets MUST NOT be discarded. in a Retry packet MUST be used immediately during the connection
attempt and cannot be used in subsequent connection attempts.
A client SHOULD NOT reuse a token in different connections. Reusing A client SHOULD NOT reuse a token in different connections. Reusing
a token allows connections to be linked by entities on the network a token allows connections to be linked by entities on the network
path (see Section 9.5). A client MUST NOT reuse a token if it path (see Section 9.5). A client MUST NOT reuse a token if it
believes that its point of network attachment has changed since the believes that its point of network attachment has changed since the
token was last used; that is, if there is a change in its local IP token was last used; that is, if there is a change in its local IP
address or network interface. A client needs to start the connection address or network interface. A client needs to start the connection
process over if it migrates prior to completing the handshake. process over if it migrates prior to completing the handshake.
When a server receives an Initial packet with an address validation When a server receives an Initial packet with an address validation
skipping to change at page 40, line 20 skipping to change at page 41, line 11
discarded. A server MAY encode tokens provided with NEW_TOKEN discarded. A server MAY encode tokens provided with NEW_TOKEN
frames and Retry packets differently, and validate the latter more frames and Retry packets differently, and validate the latter more
strictly. strictly.
In a stateless design, a server can use encrypted and authenticated In a stateless design, a server can use encrypted and authenticated
tokens to pass information to clients that the server can later tokens to pass information to clients that the server can later
recover and use to validate a client address. Tokens are not recover and use to validate a client address. Tokens are not
integrated into the cryptographic handshake and so they are not integrated into the cryptographic handshake and so they are not
authenticated. For instance, a client might be able to reuse a authenticated. For instance, a client might be able to reuse a
token. To avoid attacks that exploit this property, a server can token. To avoid attacks that exploit this property, a server can
limit its use of tokens to only the information needed validate limit its use of tokens to only the information needed to validate
client addresses. client addresses.
Attackers could replay tokens to use servers as amplifiers in DDoS Attackers could replay tokens to use servers as amplifiers in DDoS
attacks. To protect against such attacks, servers SHOULD ensure that attacks. To protect against such attacks, servers SHOULD ensure that
tokens sent in Retry packets are only accepted for a short time. tokens sent in Retry packets are only accepted for a short time.
Tokens that are provided in NEW_TOKEN frames (see Section 19.7) need Tokens that are provided in NEW_TOKEN frames (see Section 19.7) need
to be valid for longer, but SHOULD NOT be accepted multiple times in to be valid for longer, but SHOULD NOT be accepted multiple times in
a short period. Servers are encouraged to allow tokens to be used a short period. Servers are encouraged to allow tokens to be used
only once, if possible. only once, if possible.
skipping to change at page 41, line 13 skipping to change at page 41, line 50
server will need to validate the token in the future. server will need to validate the token in the future.
8.2. Path Validation 8.2. Path Validation
Path validation is used during connection migration (see Section 9 Path validation is used during connection migration (see Section 9
and Section 9.6) by the migrating endpoint to verify reachability of and Section 9.6) by the migrating endpoint to verify reachability of
a peer from a new local address. In path validation, endpoints test a peer from a new local address. In path validation, endpoints test
reachability between a specific local address and a specific peer reachability between a specific local address and a specific peer
address, where an address is the two-tuple of IP address and port. address, where an address is the two-tuple of IP address and port.
Path validation tests that packets can be both sent to and received Path validation tests that packets (PATH_CHALLENGE) can be both sent
from a peer on the path. Importantly, it validates that the packets to and received (PATH_RESPONSE) from a peer on the path.
received from the migrating endpoint do not carry a spoofed source
address. Importantly, it validates that the packets received from the
migrating endpoint do not carry a spoofed source address.
Path validation can be used at any time by either endpoint. For Path validation can be used at any time by either endpoint. For
instance, an endpoint might check that a peer is still in possession instance, an endpoint might check that a peer is still in possession
of its address after a period of quiescence. of its address after a period of quiescence.
Path validation is not designed as a NAT traversal mechanism. Though Path validation is not designed as a NAT traversal mechanism. Though
the mechanism described here might be effective for the creation of the mechanism described here might be effective for the creation of
NAT bindings that support NAT traversal, the expectation is that one NAT bindings that support NAT traversal, the expectation is that one
or other peer is able to receive packets without first having sent a or other peer is able to receive packets without first having sent a
packet on that path. Effective NAT traversal needs additional packet on that path. Effective NAT traversal needs additional
skipping to change at page 42, line 5 skipping to change at page 42, line 42
To initiate path validation, an endpoint sends a PATH_CHALLENGE frame To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
containing a random payload on the path to be validated. containing a random payload on the path to be validated.
An endpoint MAY send multiple PATH_CHALLENGE frames to guard against An endpoint MAY send multiple PATH_CHALLENGE frames to guard against
packet loss. An endpoint SHOULD NOT send a PATH_CHALLENGE more packet loss. An endpoint SHOULD NOT send a PATH_CHALLENGE more
frequently than it would an Initial packet, ensuring that connection frequently than it would an Initial packet, ensuring that connection
migration is no more load on a new path than establishing a new migration is no more load on a new path than establishing a new
connection. connection.
The endpoint MUST use fresh random data in every PATH_CHALLENGE frame The endpoint MUST use unpredictable data in every PATH_CHALLENGE
so that it can associate the peer's response with the causative frame so that it can associate the peer's response with the
PATH_CHALLENGE. corresponding PATH_CHALLENGE.
8.4. Path Validation Responses 8.4. Path Validation Responses
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond On receiving a PATH_CHALLENGE frame, an endpoint MUST respond
immediately by echoing the data contained in the PATH_CHALLENGE frame immediately by echoing the data contained in the PATH_CHALLENGE frame
in a PATH_RESPONSE frame. However, because a PATH_CHALLENGE might be in a PATH_RESPONSE frame.
sent from a spoofed address, an endpoint MUST limit the rate at which
it sends PATH_RESPONSE frames and MAY silently discard PATH_CHALLENGE
frames that would cause it to respond at a higher rate.
To ensure that packets can be both sent to and received from the To ensure that packets can be both sent to and received from the
peer, the PATH_RESPONSE MUST be sent on the same path as the peer, the PATH_RESPONSE MUST be sent on the same path as the
triggering PATH_CHALLENGE. That is, from the same local address on triggering PATH_CHALLENGE. That is, from the same local address on
which the PATH_CHALLENGE was received, to the same remote address which the PATH_CHALLENGE was received, to the same remote address
from which the PATH_CHALLENGE was received. from which the PATH_CHALLENGE was received.
8.5. Successful Path Validation 8.5. Successful Path Validation
A new address is considered valid when a PATH_RESPONSE frame is A new address is considered valid when a PATH_RESPONSE frame is
received containing data that was sent in a previous PATH_CHALLENGE. received that meets the following criteria:
Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE
frame is not adequate validation, since the acknowledgment can be
spoofed by a malicious peer.
For path validation to be successful, a PATH_RESPONSE frame MUST be o It contains the data that was sent in a previous PATH_CHALLENGE.
received from the same remote address to which the corresponding Receipt of an acknowledgment for a packet containing a
PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a PATH_CHALLENGE frame is not adequate validation, since the
different remote address than the one to which the PATH_CHALLENGE was acknowledgment can be spoofed by a malicious peer.
sent, path validation is considered to have failed, even if the data
matches that sent in the PATH_CHALLENGE.
Additionally, the PATH_RESPONSE frame MUST be received on the same o It was sent from the same remote address to which the
local address from which the corresponding PATH_CHALLENGE was sent. corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame
An endpoint considers the path to be valid when a PATH_RESPONSE frame is received from a different remote address than the one to which
is received on the same path with the same payload as the the PATH_CHALLENGE was sent, path validation is considered to have
PATH_CHALLENGE frame. failed, even if the data matches that sent in the PATH_CHALLENGE.
If a PATH_RESPONSE frame is received on a different local address o It was received on the same local address from which the
than the one from which the PATH_CHALLENGE was sent, path validation corresponding PATH_CHALLENGE was sent.
is not considered to be successful, even if the data matches the
PATH_CHALLENGE. This doesn't result in path validation failure, as Note that receipt on a different local address does not result in
it might be a result of a forwarded packet (see Section 9.3.3) or path validation failure, as it might be a result of a forwarded
misrouting. packet (see Section 9.3.3) or misrouting. It is possible that a
valid PATH_RESPONSE might be received in the future.
8.6. Failed Path Validation 8.6. Failed Path Validation
Path validation only fails when the endpoint attempting to validate Path validation only fails when the endpoint attempting to validate
the path abandons its attempt to validate the path. the path abandons its attempt to validate the path.
Endpoints SHOULD abandon path validation based on a timer. When Endpoints SHOULD abandon path validation based on a timer. When
setting this timer, implementations are cautioned that the new path setting this timer, implementations are cautioned that the new path
could have a longer round-trip time than the original. A value of could have a longer round-trip time than the original. A value of
three times the current Retransmittion Timeout (RTO) as defined in three times the larger of the current Probe Timeout (PTO) or the
[QUIC-RECOVERY] is RECOMMENDED. initial timeout (that is, 2*kInitialRtt) as defined in
[QUIC-RECOVERY] is RECOMMENDED. That is:
validation_timeout = max(3*PTO, 6*kInitialRtt)
Note that the endpoint might receive packets containing other frames Note that the endpoint might receive packets containing other frames
on the new path, but a PATH_RESPONSE frame with appropriate data is on the new path, but a PATH_RESPONSE frame with appropriate data is
required for path validation to succeed. required for path validation to succeed.
When an endpoint abandons path validation, it determines that the When an endpoint abandons path validation, it determines that the
path is unusable. This does not necessarily imply a failure of the path is unusable. This does not necessarily imply a failure of the
connection - endpoints can continue sending packets over other paths connection - endpoints can continue sending packets over other paths
as appropriate. If no paths are available, an endpoint can wait for as appropriate. If no paths are available, an endpoint can wait for
a new path to become available or close the connection. a new path to become available or close the connection.
skipping to change at page 49, line 17 skipping to change at page 49, line 41
Using a stable connection ID on multiple network paths allows a Using a stable connection ID on multiple network paths allows a
passive observer to correlate activity between those paths. An passive observer to correlate activity between those paths. An
endpoint that moves between networks might not wish to have their endpoint that moves between networks might not wish to have their
activity correlated by any entity other than their peer, so different activity correlated by any entity other than their peer, so different
connection IDs are used when sending from different local addresses, connection IDs are used when sending from different local addresses,
as discussed in Section 5.1. For this to be effective endpoints need as discussed in Section 5.1. For this to be effective endpoints need
to ensure that connections IDs they provide cannot be linked by any to ensure that connections IDs they provide cannot be linked by any
other entity. other entity.
This eliminates the use of the connection ID for linking activity This eliminates the use of the connection ID for linking activity
from the same connection on different networks. Protection of packet from the same connection on different networks. Header protection
numbers ensures that packet numbers cannot be used to correlate ensures that packet numbers cannot be used to correlate activity.
activity. This does not prevent other properties of packets, such as This does not prevent other properties of packets, such as timing and
timing and size, from being used to correlate activity. size, from being used to correlate activity.
Clients MAY move to a new connection ID at any time based on Clients MAY move to a new connection ID at any time based on
implementation-specific concerns. For example, after a period of implementation-specific concerns. For example, after a period of
network inactivity NAT rebinding might occur when the client begins network inactivity NAT rebinding might occur when the client begins
sending data again. sending data again.
A client might wish to reduce linkability by employing a new A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period connection ID and source UDP port when sending traffic after a period
of inactivity. Changing the UDP port from which it sends packets at of inactivity. Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection the same time might cause the packet to appear as a connection
skipping to change at page 50, line 25 skipping to change at page 50, line 50
Migrating a connection to a new server address mid-connection is left Migrating a connection to a new server address mid-connection is left
for future work. If a client receives packets from a new server for future work. If a client receives packets from a new server
address not indicated by the preferred_address transport parameter, address not indicated by the preferred_address transport parameter,
the client SHOULD discard these packets. the client SHOULD discard these packets.
9.6.1. Communicating A Preferred Address 9.6.1. Communicating A Preferred Address
A server conveys a preferred address by including the A server conveys a preferred address by including the
preferred_address transport parameter in the TLS handshake. preferred_address transport parameter in the TLS handshake.
Once the handshake is finished, the client SHOULD initiate path Servers MAY communicate a preferred address of each address family
validation (see Section 8.2) of the server's preferred address using (IPv4 and IPv6) to allow clients to pick the one most suited to their
the connection ID provided in the preferred_address transport network attachment.
parameter.
Once the handshake is finished, the client SHOULD select one of the
two server's preferred addresses and initiate path validation (see
Section 8.2) of that address using the connection ID provided in the
preferred_address transport parameter.
If path validation succeeds, the client SHOULD immediately begin If path validation succeeds, the client SHOULD immediately begin
sending all future packets to the new server address using the new sending all future packets to the new server address using the new
connection ID and discontinue use of the old server address. If path connection ID and discontinue use of the old server address. If path
validation fails, the client MUST continue sending all future packets validation fails, the client MUST continue sending all future packets
to the server's original IP address. to the server's original IP address.
9.6.2. Responding to Connection Migration 9.6.2. Responding to Connection Migration
A server might receive a packet addressed to its preferred IP address A server might receive a packet addressed to its preferred IP address
at any time after it accepts a connection. If this packet contains a at any time after it accepts a connection. If this packet contains a
PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per
Section 8.2. The server MAY send other non-probing frames from its Section 8.2. The server MUST send other non-probing frames from its
preferred address, but MUST continue sending all probing packets from original address until it receives a non-probing packet from the
its original IP address. client at its preferred address and until the server has validated
the new path.
The server SHOULD also initiate path validation of the client using The server MUST probe on the path toward the client from its
its preferred address and the address from which it received the preferred address. This helps to guard against spurious migration
client probe. This helps to guard against spurious migration
initiated by an attacker. initiated by an attacker.
Once the server has completed its path validation and has received a Once the server has completed its path validation and has received a
non-probing packet with a new largest packet number on its preferred non-probing packet with a new largest packet number on its preferred
address, the server begins sending non-probing packets to the client address, the server begins sending non-probing packets to the client
exclusively from its preferred IP address. It SHOULD drop packets exclusively from its preferred IP address. It SHOULD drop packets
for this connection received on the old IP address, but MAY continue for this connection received on the old IP address, but MAY continue
to process delayed packets. to process delayed packets.
9.6.3. Interaction of Client Migration and Preferred Address 9.6.3. Interaction of Client Migration and Preferred Address
skipping to change at page 51, line 34 skipping to change at page 52, line 14
attacks as described in Section 9.3.1 and Section 9.3.2. In addition attacks as described in Section 9.3.1 and Section 9.3.2. In addition
to intentional simultaneous migration, this might also occur because to intentional simultaneous migration, this might also occur because
the client's access network used a different NAT binding for the the client's access network used a different NAT binding for the
server's preferred address. server's preferred address.
Servers SHOULD initiate path validation to the client's new address Servers SHOULD initiate path validation to the client's new address
upon receiving a probe packet from a different address. Servers MUST upon receiving a probe packet from a different address. Servers MUST
NOT send more than a minimum congestion window's worth of non-probing NOT send more than a minimum congestion window's worth of non-probing
packets to the new address before path validation is complete. packets to the new address before path validation is complete.
A client that migrates to a new address SHOULD use a preferred
address from the same address family for the server.
10. Connection Termination 10. Connection Termination
Connections should remain open until they become idle for a pre- Connections should remain open until they become idle for a pre-
negotiated period of time. A QUIC connection, once established, can negotiated period of time. A QUIC connection, once established, can
be terminated in one of three ways: be terminated in one of three ways:
o idle timeout (Section 10.2) o idle timeout (Section 10.2)
o immediate close (Section 10.3) o immediate close (Section 10.3)
o stateless reset (Section 10.4) o stateless reset (Section 10.4)
10.1. Closing and Draining Connection States 10.1. Closing and Draining Connection States
The closing and draining connection states exist to ensure that The closing and draining connection states exist to ensure that
connections close cleanly and that delayed or reordered packets are connections close cleanly and that delayed or reordered packets are
properly discarded. These states SHOULD persist for three times the properly discarded. These states SHOULD persist for three times the
current Retransmission Timeout (RTO) interval as defined in current Probe Timeout (PTO) interval as defined in [QUIC-RECOVERY].
[QUIC-RECOVERY].
An endpoint enters a closing period after initiating an immediate An endpoint enters a closing period after initiating an immediate
close (Section 10.3). While closing, an endpoint MUST NOT send close (Section 10.3). While closing, an endpoint MUST NOT send
packets unless they contain a CONNECTION_CLOSE frame (see packets unless they contain a CONNECTION_CLOSE frame (see
Section 10.3 for details). An endpoint retains only enough Section 10.3 for details). An endpoint retains only enough
information to generate a packet containing a CONNECTION_CLOSE frame information to generate a packet containing a CONNECTION_CLOSE frame
and to identify packets as belonging to the connection. The and to identify packets as belonging to the connection. The
connection ID and QUIC version is sufficient information to identify connection ID and QUIC version is sufficient information to identify
packets for a closing connection; an endpoint can discard all other packets for a closing connection; an endpoint can discard all other
connection state. An endpoint MAY retain packet protection keys for connection state. An endpoint MAY retain packet protection keys for
skipping to change at page 53, line 9 skipping to change at page 53, line 36
connection being handled generically. For instance, an endpoint MAY connection being handled generically. For instance, an endpoint MAY
send a stateless reset in response to any further incoming packets. send a stateless reset in response to any further incoming packets.
The draining and closing periods do not apply when a stateless reset The draining and closing periods do not apply when a stateless reset
(Section 10.4) is sent. (Section 10.4) is sent.
An endpoint is not expected to handle key updates when it is closing An endpoint is not expected to handle key updates when it is closing
or draining. A key update might prevent the endpoint from moving or draining. A key update might prevent the endpoint from moving
from the closing state to draining, but it otherwise has no impact. from the closing state to draining, but it otherwise has no impact.
An endpoint could receive packets from a new source address, While in the closing period, an endpoint could receive packets from a
indicating a client connection migration (Section 9), while in the new source address, indicating a client connection migration
closing period. An endpoint in the closing state MUST strictly limit (Section 9). An endpoint in the closing state MUST strictly limit
the number of packets it sends to this new address until the address the number of packets it sends to this new address until the address
is validated (see Section 8.2). A server in the closing state MAY is validated (see Section 8.2). A server in the closing state MAY
instead choose to discard packets received from a new source address. instead choose to discard packets received from a new source address.
10.2. Idle Timeout 10.2. Idle Timeout
If the idle timeout is enabled, a connection that remains idle for If the idle timeout is enabled, a connection that remains idle for
longer than the advertised idle timeout (see Section 18.1) is closed. longer than the advertised idle timeout (see Section 18.1) is closed.
A connection enters the draining state when the idle timeout expires. A connection enters the draining state when the idle timeout expires.
Each endpoint advertises its own idle timeout to its peer. The idle Each endpoint advertises its own idle timeout to its peer. An
timeout starts from the last packet received. In order to ensure enpdpoint restarts any timer it maintains when a packet from its peer
that initiating new activity postpones an idle timeout, an endpoint is received and processed successfully. The timer is also restarted
restarts this timer when sending a packet. An endpoint does not when sending a packet containing frames other than ACK or PADDING (an
postpone the idle timeout if another packet has been sent containing ACK-eliciting packet, see [QUIC-RECOVERY]), but only if no other ACK-
frames other than ACK or PADDING, and that other packet has not been eliciting packets have been sent since last receiving a packet.
acknowledged or declared lost. Packets that contain only ACK or Restarting when sending packets ensures that connections do not
PADDING frames are not acknowledged until an endpoint has other prematurely time out when initiating new activity.
frames to send, so they could prevent the timeout from being
refreshed.
The value for an idle timeout can be asymmetric. The value The value for an idle timeout can be asymmetric. The value
advertised by an endpoint is only used to determine whether the advertised by an endpoint is only used to determine whether the
connection is live at that endpoint. An endpoint that sends packets connection is live at that endpoint. An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the packets discarded if its peer enters the draining state before the
packets arrive. If a peer could timeout within an RTO (see packets arrive. If a peer could timeout within an Probe Timeout
Section 5.3.3 of [QUIC-RECOVERY]), it is advisable to test for (PTO, see Section 6.2.2 of [QUIC-RECOVERY]), it is advisable to test
liveness before sending any data that cannot be retried safely. for liveness before sending any data that cannot be retried safely.
10.3. Immediate Close 10.3. Immediate Close
An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to
terminate the connection immediately. A CONNECTION_CLOSE frame terminate the connection immediately. A CONNECTION_CLOSE frame
causes all streams to immediately become closed; open streams can be causes all streams to immediately become closed; open streams can be
assumed to be implicitly reset. assumed to be implicitly reset.
After sending a CONNECTION_CLOSE frame, endpoints immediately enter After sending a CONNECTION_CLOSE frame, endpoints immediately enter
the closing state. During the closing period, an endpoint that sends the closing state. During the closing period, an endpoint that sends
a CONNECTION_CLOSE frame SHOULD respond to any packet that it a CONNECTION_CLOSE frame SHOULD respond to any packet that it
receives with another packet containing a CONNECTION_CLOSE frame. To receives with another packet containing a CONNECTION_CLOSE frame. To
minimize the state that an endpoint maintains for a closing minimize the state that an endpoint maintains for a closing
connection, endpoints MAY send the exact same packet. However, connection, endpoints MAY send the exact same packet. However,
endpoints SHOULD limit the number of packets they generate containing endpoints SHOULD limit the number of packets they generate containing
a CONNECTION_CLOSE frame. For instance, an endpoint could a CONNECTION_CLOSE frame. For instance, an endpoint could
progressively increase the number of packets that it receives before progressively increase the number of packets that it receives before
sending additional packets or increase the time between packets. sending additional packets or increase the time between packets.
Note: Allowing retransmission of a packet contradicts other advice Note: Allowing retransmission of a closing packet contradicts other
in this document that recommends the creation of new packet advice in this document that recommends the creation of new packet
numbers for every packet. Sending new packet numbers is primarily numbers for every packet. Sending new packet numbers is primarily
of advantage to loss recovery and congestion control, which are of advantage to loss recovery and congestion control, which are
not expected to be relevant for a closed connection. not expected to be relevant for a closed connection.
Retransmitting the final packet requires less state. Retransmitting the final packet requires less state.
New packets from unverified addresses could be used to create an New packets from unverified addresses could be used to create an
amplification attack (see Section 8). To avoid this, endpoints MUST amplification attack (see Section 8). To avoid this, endpoints MUST
either limit transmission of CONNECTION_CLOSE frames to validated either limit transmission of CONNECTION_CLOSE frames to validated
addresses or drop packets without response if the response would be addresses or drop packets without response if the response would be
more than three times larger than the received packet. more than three times larger than the received packet.
skipping to change at page 55, line 30 skipping to change at page 56, line 8
protected by encryption, so only client and server know this value. protected by encryption, so only client and server know this value.
Tokens are invalidated when their associated connection ID is retired Tokens are invalidated when their associated connection ID is retired
via a RETIRE_CONNECTION_ID frame (Section 19.16). via a RETIRE_CONNECTION_ID frame (Section 19.16).
An endpoint that receives packets that it cannot process sends a An endpoint that receives packets that it cannot process sends a
packet in the following layout: packet in the following layout:
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|1| Random Bits (182..) ... |0|1| Unpredictable Bits (182..) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Stateless Reset Token (128) + + Stateless Reset Token (128) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Stateless Reset Packet Figure 7: Stateless Reset Packet
This design ensures that a stateless reset packet is - to the extent This design ensures that a stateless reset packet is - to the extent
possible - indistinguishable from a regular packet with a short possible - indistinguishable from a regular packet with a short
header. header.
A stateless reset uses an entire UDP datagram, starting with the A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header. The remainder of the first byte first two bits of the packet header. The remainder of the first byte
and an arbitrary number of random bytes following it are set to and an arbitrary number of bytes following it that are set to
unpredictable values. The last 16 bytes of the datagram contain a unpredictable values. The last 16 bytes of the datagram contain a
Stateless Reset Token. Stateless Reset Token.
A stateless reset will be interpreted by a recipient as a packet with A stateless reset will be interpreted by a recipient as a packet with
a short header. For the packet to appear as valid, the Random Bits a short header. For the packet to appear as valid, the Random Bits
field needs to include at least 182 bits of random or unpredictable field needs to include at least 182 bits of data (or 23 bytes, less
values (or 24 bytes, less the two fixed bits). This is intended to the two fixed bits). This is intended to allow for a Destination
allow for a destination connection ID of the maximum length Connection ID of the maximum length permitted, with a minimal packet
permitted, with a minimal packet number, and payload. The Stateless number, and payload. The Stateless Reset Token corresponds to the
Reset Token corresponds to the minimum expansion of the packet minimum expansion of the packet protection AEAD. More unpredictable
protection AEAD. More random bytes might be necessary if the bytes might be necessary if the endpoint could have negotiated a
endpoint could have negotiated a packet protection scheme with a packet protection scheme with a larger minimum AEAD expansion.
larger minimum AEAD expansion.
An endpoint SHOULD NOT send a stateless reset that is significantly An endpoint SHOULD NOT send a stateless reset that is significantly
larger than the packet it receives. Endpoints MUST discard packets larger than the packet it receives. Endpoints MUST discard packets
that are too small to be valid QUIC packets. With the set of AEAD that are too small to be valid QUIC packets. With the set of AEAD
functions defined in [QUIC-TLS], packets that are smaller than 21 functions defined in [QUIC-TLS], packets that are smaller than 21
bytes are never valid. bytes are never valid.
An endpoint MAY send a stateless reset in response to a packet with a An endpoint MAY send a stateless reset in response to a packet with a
long header. This would not be effective if the stateless reset long header. This would not be effective if the stateless reset
token was not yet available to a peer. In this QUIC version, packets token was not yet available to a peer. In this QUIC version, packets
skipping to change at page 57, line 18 skipping to change at page 57, line 44
This stateless reset design is specific to QUIC version 1. An This stateless reset design is specific to QUIC version 1. An
endpoint that supports multiple versions of QUIC needs to generate a endpoint that supports multiple versions of QUIC needs to generate a
stateless reset that will be accepted by peers that support any stateless reset that will be accepted by peers that support any
version that the endpoint might support (or might have supported version that the endpoint might support (or might have supported
prior to losing state). Designers of new versions of QUIC need to be prior to losing state). Designers of new versions of QUIC need to be
aware of this and either reuse this design, or use a portion of the aware of this and either reuse this design, or use a portion of the
packet other than the last 16 bytes for carrying data. packet other than the last 16 bytes for carrying data.
10.4.1. Detecting a Stateless Reset 10.4.1. Detecting a Stateless Reset
An endpoint detects a potential stateless reset when a packet with a An endpoint detects a potential stateless reset when a incoming
short header either cannot be decrypted or is marked as a duplicate packet with a short header either cannot be associated with a
packet. The endpoint then compares the last 16 bytes of the packet connection, cannot be decrypted, or is marked as a duplicate packet.
with the Stateless Reset Token provided by its peer, either in a The endpoint then compares the last 16 bytes of the packet with the
Stateless Reset Token provided by its peer, either in a
NEW_CONNECTION_ID frame or the server's transport parameters. If NEW_CONNECTION_ID frame or the server's transport parameters. If
these values are identical, the endpoint MUST enter the draining these values are identical, the endpoint MUST enter the draining
period and not send any further packets on this connection. If the period and not send any further packets on this connection. If the
comparison fails, the packet can be discarded. comparison fails, the packet can be discarded.
10.4.2. Calculating a Stateless Reset Token 10.4.2. Calculating a Stateless Reset Token
The stateless reset token MUST be difficult to guess. In order to The stateless reset token MUST be difficult to guess. In order to
create a Stateless Reset Token, an endpoint could randomly generate create a Stateless Reset Token, an endpoint could randomly generate
[RFC4086] a secret for every connection that it creates. However, [RFC4086] a secret for every connection that it creates. However,
skipping to change at page 58, line 27 skipping to change at page 59, line 10
same static key (see Section 21.8). A connection ID from a same static key (see Section 21.8). A connection ID from a
connection that is reset by revealing the Stateless Reset Token connection that is reset by revealing the Stateless Reset Token
cannot be reused for new connections at nodes that share a static cannot be reused for new connections at nodes that share a static
key. key.
Note that Stateless Reset packets do not have any cryptographic Note that Stateless Reset packets do not have any cryptographic
protection. protection.
10.4.3. Looping 10.4.3. Looping
The design of a Stateless Reset is such that it is indistinguishable The design of a Stateless Reset is such that without knowing the
from a valid packet. This means that a Stateless Reset might trigger stateless reset token it is indistinguishable from a valid packet.
the sending of a Stateless Reset in response, which could lead to For instance, if a server sends a Stateless Reset to another server
infinite exchanges. it might receive another Stateless Reset in response, which could
lead to an infinite exchange.
An endpoint MUST ensure that every Stateless Reset that it sends is An endpoint MUST ensure that every Stateless Reset that it sends is
smaller than the packet which triggered it, unless it maintains state smaller than the packet which triggered it, unless it maintains state
sufficient to prevent looping. In the event of a loop, this results sufficient to prevent looping. In the event of a loop, this results
in packets eventually being too small to trigger a response. in packets eventually being too small to trigger a response.
An endpoint can remember the number of Stateless Reset packets that An endpoint can remember the number of Stateless Reset packets that
it has sent and stop generating new Stateless Reset packets once a it has sent and stop generating new Stateless Reset packets once a
limit is reached. Using separate limits for different remote limit is reached. Using separate limits for different remote
addresses will ensure that Stateless Reset packets can be used to addresses will ensure that Stateless Reset packets can be used to
close connections when other peers or connections have exhausted close connections when other peers or connections have exhausted
limits. limits.
Reducing the size of a Stateless Reset below the recommended minimum Reducing the size of a Stateless Reset below the recommended minimum
size of 37 bytes could mean that the packet could reveal to an size of 39 bytes could mean that the packet could reveal to an
observer that it is a Stateless Reset. Conversely, refusing to send observer that it is a Stateless Reset. Conversely, refusing to send
a Stateless Reset in response to a small packet might result in a Stateless Reset in response to a small packet might result in
Stateless Reset not being useful in detecting cases of broken Stateless Reset not being useful in detecting cases of broken
connections where only very small packets are sent; such failures connections where only very small packets are sent; such failures
might only be detected by other means, such as timers. might only be detected by other means, such as timers.
An endpoint can increase the odds that a packet will trigger a An endpoint can increase the odds that a packet will trigger a
Stateless Reset if it cannot be processed by padding it to at least Stateless Reset if it cannot be processed by padding it to at least
38 bytes. 40 bytes.
11. Error Handling 11. Error Handling
An endpoint that detects an error SHOULD signal the existence of that An endpoint that detects an error SHOULD signal the existence of that
error to its peer. Both transport-level and application-level errors error to its peer. Both transport-level and application-level errors
can affect an entire connection (see Section 11.1), while only can affect an entire connection (see Section 11.1), while only
application-level errors can be isolated to a single stream (see application-level errors can be isolated to a single stream (see
Section 11.2). Section 11.2).
The most appropriate error code (Section 20) SHOULD be included in The most appropriate error code (Section 20) SHOULD be included in
skipping to change at page 60, line 27 skipping to change at page 61, line 9
RESET_STREAM MUST be instigated by the protocol using QUIC, either RESET_STREAM MUST be instigated by the protocol using QUIC, either
directly or through the receipt of a STOP_SENDING frame from a peer. directly or through the receipt of a STOP_SENDING frame from a peer.
RESET_STREAM carries an application error code. Resetting a stream RESET_STREAM carries an application error code. Resetting a stream
without knowledge of the application protocol could cause the without knowledge of the application protocol could cause the
protocol to enter an unrecoverable state. Application protocols protocol to enter an unrecoverable state. Application protocols
might require certain streams to be reliably delivered in order to might require certain streams to be reliably delivered in order to
guarantee consistent state between endpoints. guarantee consistent state between endpoints.
12. Packets and Frames 12. Packets and Frames
QUIC endpoints communicate by exchanging packets. Packets are QUIC endpoints communicate by exchanging packets. Packets have
carried in UDP datagrams (see Section 12.2) and have confidentiality confidentiality and integrity protection (see Section 12.1) and are
and integrity protection (see Section 12.1). carried in UDP datagrams (see Section 12.2).
This version of QUIC uses the long packet header (see Section 17.2) This version of QUIC uses the long packet header (see Section 17.2)
during connection establishment and the short header (see during connection establishment. Packets with the long header are
Section 17.3) once 1-RTT keys have been established. Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake
(Section 17.2.4), and Retry (Section 17.2.5). Version negotiation
Packets that carry the long header are Initial Section 17.5, Retry uses a version-independent packet with a long header (see
Section 17.7, Handshake Section 17.6, and 0-RTT Protected packets Section 17.2.1).
Section 12.1.
Packets with the short header are designed for minimal overhead and
are used after a connection is established.
Version negotiation uses a packet with a special format (see Packets with the short header (Section 17.3) are designed for minimal
Section 17.4). overhead and are used after a connection is established and 1-RTT
keys are available.
12.1. Protected Packets 12.1. Protected Packets
All QUIC packets except Version Negotiation and Retry packets use All QUIC packets except Version Negotiation and Retry packets use
authenticated encryption with additional data (AEAD) [RFC5119] to authenticated encryption with additional data (AEAD) [RFC5116] to
provide confidentiality and integrity protection. Details of packet provide confidentiality and integrity protection. Details of packet
protection are found in [QUIC-TLS]; this section includes an overview protection are found in [QUIC-TLS]; this section includes an overview
of the process. of the process.
Initial packets are protected using keys that are statically derived. Initial packets are protected using keys that are statically derived.
This packet protection is not effective confidentiality protection, This packet protection is not effective confidentiality protection.
it only exists to ensure that the sender of the packet is on the Initial protection only exists to ensure that the sender of the
network path. Any entity that receives the Initial packet from a packet is on the network path. Any entity that receives the Initial
client can recover the keys necessary to remove packet protection or packet from a client can recover the keys necessary to remove packet
to generate packets that will be successfully authenticated. protection or to generate packets that will be successfully
authenticated.
All other packets are protected with keys derived from the All other packets are protected with keys derived from the
cryptographic handshake. The type of the packet from the long header cryptographic handshake. The type of the packet from the long header
or key phase from the short header are used to identify which or key phase from the short header are used to identify which
encryption level - and therefore the keys - that are used. Packets encryption level - and therefore the keys - that are used. Packets
protected with 0-RTT and 1-RTT keys are expected to have protected with 0-RTT and 1-RTT keys are expected to have
confidentiality and data origin authentication; the cryptographic confidentiality and data origin authentication; the cryptographic
handshake ensures that only the communicating endpoints receive the handshake ensures that only the communicating endpoints receive the
corresponding keys. corresponding keys.
The packet number field contains a packet number, which has The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet additional confidentiality protection that is applied after packet
protection is applied (see [QUIC-TLS] for details). The underlying protection is applied (see [QUIC-TLS] for details). The underlying
packet number increases with each packet sent, see Section 12.3 for packet number increases with each packet sent in a given packet
details. number space, see Section 12.3 for details.
12.2. Coalescing Packets 12.2. Coalescing Packets
A sender can coalesce multiple QUIC packets into one UDP datagram. Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake
This can reduce the number of UDP datagrams needed to complete the (Section 17.2.4) packets contain a Length field, which determines the
cryptographic handshake and starting sending data. Receivers MUST be end of the packet. The length includes both the Packet Number and
able to process coalesced packets. Payload fields, both of which are confidentiality protected and
initially of unknown length. The length of the Payload field is
learned once header protection is removed.
Using the Length field, a sender can coalesce multiple QUIC packets
into one UDP datagram. This can reduce the number of UDP datagrams
needed to complete the cryptographic handshake and starting sending
data. Receivers MUST be able to process coalesced packets.
Coalescing packets in order of increasing encryption levels (Initial, Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be
able to process all the packets in a single pass. A packet with a able to process all the packets in a single pass. A packet with a
short header does not include a length, so it will always be the last short header does not include a length, so it can only be the last
packet included in a UDP datagram. packet included in a UDP datagram.
Senders MUST NOT coalesce QUIC packets for different connections into Senders MUST NOT coalesce QUIC packets for different connections into
a single UDP datagram. Receivers SHOULD ignore any subsequent a single UDP datagram. Receivers SHOULD ignore any subsequent
packets with a different Destination Connection ID than the first packets with a different Destination Connection ID than the first
packet in the datagram. packet in the datagram.
Every QUIC packet that is coalesced into a single UDP datagram is Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete. Though the values of some fields in the separate and complete. Though the values of some fields in the
packet header might be redundant, no fields are omitted. The packet header might be redundant, no fields are omitted. The
receiver of coalesced QUIC packets MUST individually process each receiver of coalesced QUIC packets MUST individually process each
QUIC packet and separately acknowledge them, as if they were received QUIC packet and separately acknowledge them, as if they were received
as the payload of different UDP datagrams. For example, if as the payload of different UDP datagrams. For example, if
decryption fails (because the keys are not available or any other decryption fails (because the keys are not available or any other
reason) or the packet is of an unknown type, the receiver MAY either reason), the the receiver MAY either discard or buffer the packet for
discard or buffer the packet for later processing and MUST attempt to later processing and MUST attempt to process the remaining packets.
process the remaining packets.
Retry packets (Section 17.7), Version Negotiation packets Retry packets (Section 17.2.5), Version Negotiation packets
(Section 17.4), and packets with a short header cannot be followed by (Section 17.2.1), and packets with a short header (Section 17.3) do
other packets in the same UDP datagram. not contain a Length field and so cannot be followed by other packets
in the same UDP datagram.
12.3. Packet Numbers 12.3. Packet Numbers
The packet number is an integer in the range 0 to 2^62-1. Where The packet number is an integer in the range 0 to 2^62-1. This
present, packet numbers are encoded as a variable-length integer (see number is used in determining the cryptographic nonce for packet
Section 16). This number is used in determining the cryptographic protection. Each endpoint maintains a separate packet number for
nonce for packet protection. Each endpoint maintains a separate sending and receiving.
packet number for sending and receiving.
Version Negotiation (Section 17.4) and Retry Section 17.7 packets do Packet numbers are limited to this range because they need to be
not include a packet number. representable in whole in the Largest Acknowledged field of an ACK
frame (Section 19.3). When present in a long or short header
however, packet numbers are reduced and encoded in 1 to 4 bytes, see
Section 17.1).
Version Negotiation (Section 17.2.1) and Retry Section 17.2.5 packets
do not include a packet number.
Packet numbers are divided into 3 spaces in QUIC: Packet numbers are divided into 3 spaces in QUIC:
o Initial space: All Initial packets Section 17.5 are in this space. o Initial space: All Initial packets Section 17.2.2 are in this
space.
o Handshake space: All Handshake packets Section 17.6 are in this o Handshake space: All Handshake packets Section 17.2.4 are in this
space. space.
o Application data space: All 0-RTT and 1-RTT encrypted packets o Application data space: All 0-RTT and 1-RTT encrypted packets
Section 12.1 are in this space. Section 12.1 are in this space.
As described in [QUIC-TLS], each packet type uses different As described in [QUIC-TLS], each packet type uses different
protection keys. protection keys.
Conceptually, a packet number space is the context in which a packet Conceptually, a packet number space is the context in which a packet
can be processed and acknowledged. Initial packets can only be sent can be processed and acknowledged. Initial packets can only be sent
with Initial packet protection keys and acknowledged in packets which with Initial packet protection keys and acknowledged in packets which
are also Initial packets. Similarly, Handshake packets are sent at are also Initial packets. Similarly, Handshake packets are sent at
the Handshake encryption level and can only be acknowledged in the Handshake encryption level and can only be acknowledged in
Handshake packets. Handshake packets.
This enforces cryptographic separation between the data sent in the This enforces cryptographic separation between the data sent in the
different packet sequence number spaces. Each packet number space different packet sequence number spaces. Packet numbers in each
starts at packet number 0. Subsequent packets sent in the same space start at packet number 0. Subsequent packets sent in the same
packet number space MUST increase the packet number by at least one. packet number space MUST increase the packet number by at least one.
0-RTT and 1-RTT data exist in the same packet number space to make 0-RTT and 1-RTT data exist in the same packet number space to make
loss recovery algorithms easier to implement between the two packet loss recovery algorithms easier to implement between the two packet
types. types.
A QUIC endpoint MUST NOT reuse a packet number within the same packet A QUIC endpoint MUST NOT reuse a packet number within the same packet
number space in one connection (that is, under the same cryptographic number space in one connection (that is, under the same cryptographic
keys). If the packet number for sending reaches 2^62 - 1, the sender keys). If the packet number for sending reaches 2^62 - 1, the sender
MUST close the connection without sending a CONNECTION_CLOSE frame or MUST close the connection without sending a CONNECTION_CLOSE frame or
skipping to change at page 65, line 49 skipping to change at page 66, line 5
| | | | | | | |
| 0x1a | PATH_CHALLENGE | Section 19.17 | | 0x1a | PATH_CHALLENGE | Section 19.17 |
| | | | | | | |
| 0x1b | PATH_RESPONSE | Section 19.18 | | 0x1b | PATH_RESPONSE | Section 19.18 |
| | | | | | | |
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 |
+-------------+----------------------+---------------+ +-------------+----------------------+---------------+
Table 3: Frame Types Table 3: Frame Types
All QUIC frames are idempotent. That is, a valid frame does not All QUIC frames are idempotent in this version of QUIC. That is, a
cause undesirable side effects or errors when received more than valid frame does not cause undesirable side effects or errors when
once. received more than once.
The Frame Type field uses a variable length integer encoding (see The Frame Type field uses a variable length integer encoding (see
Section 16) with one exception. To ensure simple and efficient Section 16) with one exception. To ensure simple and efficient
implementations of frame parsing, a frame type MUST use the shortest implementations of frame parsing, a frame type MUST use the shortest
possible encoding. Though a two-, four- or eight-byte encoding of possible encoding. Though a two-, four- or eight-byte encoding of
the frame types defined in this document is possible, the Frame Type the frame types defined in this document is possible, the Frame Type
field for these frames is encoded on a single byte. For instance, field for these frames is encoded on a single byte. For instance,
though 0x4007 is a legitimate two-byte encoding for a variable-length though 0x4001 is a legitimate two-byte encoding for a variable-length
integer with a value of 7, PING frames are always encoded as a single integer with a value of 1, PING frames are always encoded as a single
byte with the value 0x07. An endpoint MAY treat the receipt of a byte with the value 0x01. An endpoint MAY treat the receipt of a
frame type that uses a longer encoding than necessary as a connection frame type that uses a longer encoding than necessary as a connection
error of type PROTOCOL_VIOLATION. error of type PROTOCOL_VIOLATION.
13. Packetization and Reliability 13. Packetization and Reliability
A sender bundles one or more frames in a QUIC packet (see A sender bundles one or more frames in a QUIC packet (see
Section 12.4). Section 12.4).
A sender can minimize per-packet bandwidth and computational costs by A sender can minimize per-packet bandwidth and computational costs by
bundling as many frames as possible within a QUIC packet. A sender bundling as many frames as possible within a QUIC packet. A sender
MAY wait for a short period of time to bundle multiple frames before MAY wait for a short period of time to bundle multiple frames before
sending a packet that is not maximally packed, to avoid sending out sending a packet that is not maximally packed, to avoid sending out
large numbers of small packets. An implementation may use knowledge large numbers of small packets. An implementation MAY use knowledge
about application sending behavior or heuristics to determine whether about application sending behavior or heuristics to determine whether
and for how long to wait. This waiting period is an implementation and for how long to wait. This waiting period is an implementation
decision, and an implementation should be careful to delay decision, and an implementation should be careful to delay
conservatively, since any delay is likely to increase application- conservatively, since any delay is likely to increase application-
visible latency. visible latency.
Stream multiplexing is achieved by interleaving STREAM frames from Stream multiplexing is achieved by interleaving STREAM frames from
multiple streams into one or more QUIC packets. A single QUIC packet multiple streams into one or more QUIC packets. A single QUIC packet
can include multiple STREAM frames from one or more streams. can include multiple STREAM frames from one or more streams.
skipping to change at page 67, line 13 skipping to change at page 67, line 19
processed. For STREAM frames, this means the data has been enqueued processed. For STREAM frames, this means the data has been enqueued
in preparation to be received by the application protocol, but it in preparation to be received by the application protocol, but it
does not require that data is delivered and consumed. does not require that data is delivered and consumed.
Once the packet has been fully processed, a receiver acknowledges Once the packet has been fully processed, a receiver acknowledges
receipt by sending one or more ACK frames containing the packet receipt by sending one or more ACK frames containing the packet
number of the received packet. number of the received packet.
13.1.1. Sending ACK Frames 13.1.1. Sending ACK Frames
To avoid creating an indefinite feedback loop, an endpoint MUST NOT An endpoint MUST NOT send more than one packet containing only an ACK
send an ACK frame in response to a packet containing only ACK or frame per received packet that contains frames other than ACK and
PADDING frames, even if there are packet gaps which precede the PADDING frames. An endpoint MUST NOT send a packet containing only
received packet. The endpoint MUST however acknowledge packets an ACK frame in response to a packet containing only ACK or PADDING
containing only ACK or PADDING frames when sending ACK frames in frames, even if there are packet gaps which precede the received
response to other packets. packet. This prevents an indefinite feedback loop of ACKs. The
endpoint MUST however acknowledge packets containing only ACK or
PADDING frames when sending ACK frames in response to other packets.
Packets containing PADDING frames are considered to be in flight for Packets containing PADDING frames are considered to be in flight for
congestion control purposes [QUIC-RECOVERY]. Sending only PADDING congestion control purposes [QUIC-RECOVERY]. Sending only PADDING
frames might cause the sender to become limited by the congestion frames might cause the sender to become limited by the congestion
controller (as described in [QUIC-RECOVERY]) with no acknowledgments controller (as described in [QUIC-RECOVERY]) with no acknowledgments
forthcoming from the receiver. Therefore, a sender should ensure forthcoming from the receiver. Therefore, a sender SHOULD ensure
that other frames are sent in addition to PADDING frames to elicit that other frames are sent in addition to PADDING frames to elicit
acknowledgments from the receiver. acknowledgments from the receiver.
An endpoint MUST NOT send more than one packet containing only an ACK
frame per received packet that contains frames other than ACK and
PADDING frames.
The receiver's delayed acknowledgment timer SHOULD NOT exceed the The receiver's delayed acknowledgment timer SHOULD NOT exceed the
current RTT estimate or the value it indicates in the "max_ack_delay" current RTT estimate or the value it indicates in the "max_ack_delay"
transport parameter. This ensures an acknowledgment is sent at least transport parameter. This ensures an acknowledgment is sent at least
once per RTT when packets needing acknowledgement are received. The once per RTT when packets needing acknowledgement are received. The
sender can use the receiver's "max_ack_delay" value in determining sender can use the receiver's "max_ack_delay" value in determining
timeouts for timer-based retransmission. timeouts for timer-based retransmission.
Strategies and implications of the frequency of generating Strategies and implications of the frequency of generating
acknowledgments are discussed in more detail in [QUIC-RECOVERY]. acknowledgments are discussed in more detail in [QUIC-RECOVERY].
To limit ACK Blocks to those that have not yet been received by the To limit ACK Ranges (see Section 19.3.1) to those that have not yet
sender, the receiver SHOULD track which ACK frames have been been received by the sender, the receiver SHOULD track which ACK
acknowledged by its peer. Once an ACK frame has been acknowledged, frames have been acknowledged by its peer. The receiver SHOULD
the packets it acknowledges SHOULD NOT be acknowledged again. exclude already acknowledged packets from future ACK frames whenever
these packets would unnecessarily contribute to the ACK frame size.
Because ACK frames are not sent in response to ACK-only packets, a Because ACK frames are not sent in response to ACK-only packets, a
receiver that is only sending ACK frames will only receive receiver that is only sending ACK frames will only receive
acknowledgements for its packets if the sender includes them in acknowledgements for its packets if the sender includes them in
packets with non-ACK frames. A sender SHOULD bundle ACK frames with packets with non-ACK frames. A sender SHOULD bundle ACK frames with
other frames when possible. other frames when possible.
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 Ranges 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.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it
did not send as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition.
13.1.2. ACK Frames and Packet Protection 13.1.2. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed (see Section 12.1). For number space as the packet being ACKed (see Section 12.1). For
instance, packets that are protected with 1-RTT keys MUST be instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys. acknowledged in packets that are also protected with 1-RTT keys.
Packets that a client sends with 0-RTT packet protection MUST be Packets that a client sends with 0-RTT packet protection MUST be
acknowledged by the server in packets protected by 1-RTT keys. This acknowledged by the server in packets protected by 1-RTT keys. This
can mean that the client is unable to use these acknowledgments if can mean that the client is unable to use these acknowledgments if
the server cryptographic handshake messages are delayed or lost. the server cryptographic handshake messages are delayed or lost.
Note that the same limitation applies to other data sent by the Note that the same limitation applies to other data sent by the
server protected by the 1-RTT keys. server protected by the 1-RTT keys.
Endpoints SHOULD send acknowledgments for packets containing CRYPTO Endpoints SHOULD send acknowledgments for packets containing CRYPTO
frames with a reduced delay; see Section 5.3.1 of [QUIC-RECOVERY]. frames with a reduced delay; see Section 6.2.1 of [QUIC-RECOVERY].
13.2. Retransmission of Information 13.2. Retransmission of Information
QUIC packets that are determined to be lost are not retransmitted QUIC packets that are determined to be lost are not retransmitted
whole. The same applies to the frames that are contained within lost whole. The same applies to the frames that are contained within lost
packets. Instead, the information that might be carried in frames is packets. Instead, the information that might be carried in frames is
sent again in new frames as needed. sent again in new frames as needed.
New frames and packets are used to carry information that is New frames and packets are used to carry information that is
determined to have been lost. In general, information is sent again determined to have been lost. In general, information is sent again
skipping to change at page 69, line 12 skipping to change at page 69, line 22
stream. Once an endpoint sends a RESET_STREAM frame, no further stream. Once an endpoint sends a RESET_STREAM frame, no further
STREAM frames are needed. STREAM frames are needed.
o The most recent set of acknowledgments are sent in ACK frames. An o The most recent set of acknowledgments are sent in ACK frames. An
ACK frame SHOULD contain all unacknowledged acknowledgments, as ACK frame SHOULD contain all unacknowledged acknowledgments, as
described in Section 13.1.1. described in Section 13.1.1.
o Cancellation of stream transmission, as carried in a RESET_STREAM o Cancellation of stream transmission, as carried in a RESET_STREAM
frame, is sent until acknowledged or until all stream data is frame, is sent until acknowledged or until all stream data is
acknowledged by the peer (that is, either the "Reset Recvd" or acknowledged by the peer (that is, either the "Reset Recvd" or
"Data Recvd" state is reached on the send stream). The content of "Data Recvd" state is reached on the sending part of the stream).
a RESET_STREAM frame MUST NOT change when it is sent again. The content of a RESET_STREAM frame MUST NOT change when it is
sent again.
o Similarly, a request to cancel stream transmission, as encoded in o Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receive stream enters a STOP_SENDING frame, is sent until the receiving part of the
either a "Data Recvd" or "Reset Recvd" state, see Section 3.5. stream enters either a "Data Recvd" or "Reset Recvd" state, see
Section 3.5.
o Connection close signals, including packets that contain o Connection close signals, including packets that contain
CONNECTION_CLOSE frames, are not sent again when packet loss is CONNECTION_CLOSE frames, are not sent again when packet loss is
detected, but as described in Section 10. detected, but as described in Section 10.
o The current connection maximum data is sent in MAX_DATA frames. 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 An updated value is sent in a MAX_DATA frame if the packet
containing the most recently sent MAX_DATA frame is declared lost, containing the most recently sent MAX_DATA frame is declared lost,
or when the endpoint decides to update the limit. Care is or when the endpoint decides to update the limit. Care is
necessary to avoid sending this frame too often as the limit can necessary to avoid sending this frame too often as the limit can
increase frequently and cause an unnecessarily large number of increase frequently and cause an unnecessarily large number of
MAX_DATA frames to be sent. MAX_DATA frames to be sent.
o The current maximum stream data offset is sent in MAX_STREAM_DATA 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 frames. Like MAX_DATA, an updated value is sent when the packet
containing the most recent MAX_STREAM_DATA frame for a stream is containing the most recent MAX_STREAM_DATA frame for a stream is
lost or when the limit is updated, with care taken to prevent the lost or when the limit is updated, with care taken to prevent the
frame from being sent too often. An endpoint SHOULD stop sending frame from being sent too often. An endpoint SHOULD stop sending
MAX_STREAM_DATA frames when the receive stream enters a "Size MAX_STREAM_DATA frames when the receiving part of the stream
Known" state. enters a "Size Known" state.
o The limit on streams of a given type is sent in MAX_STREAMS o The limit on streams of a given type is sent in MAX_STREAMS
frames. Like MAX_DATA, an updated value is sent when a packet frames. Like MAX_DATA, an updated value is sent when a packet
containing the most recent MAX_STREAMS for a stream type frame is containing the most recent MAX_STREAMS for a stream type frame is
declared lost or when the limit is updated, with care taken to declared lost or when the limit is updated, with care taken to
prevent the frame from being sent too often. prevent the frame from being sent too often.
o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED,
and STREAMS_BLOCKED frames. DATA_BLOCKED streams have connection and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection
scope, STREAM_DATA_BLOCKED frames have stream scope, and scope, STREAM_DATA_BLOCKED frames have stream scope, and
STREAMS_BLOCKED frames are scoped to a specific stream type. New STREAMS_BLOCKED frames are scoped to a specific stream type. New
frames are sent if packets containing the most recent frame for a frames are sent if packets containing the most recent frame for a
scope is lost, but only while the endpoint is blocked on the scope is lost, but only while the endpoint is blocked on the
corresponding limit. These frames always include the limit that corresponding limit. These frames always include the limit that
is causing blocking at the time that they are transmitted. is causing blocking at the time that they are transmitted.
o A liveness or path validation check using PATH_CHALLENGE frames is o A liveness or path validation check using PATH_CHALLENGE frames is
sent periodically until a matching PATH_RESPONSE frame is received sent periodically until a matching PATH_RESPONSE frame is received
or until there is no remaining need for liveness or path or until there is no remaining need for liveness or path
skipping to change at page 70, line 29 skipping to change at page 70, line 41
RETIRE_CONNECTION_ID frames and retransmitted if the packet RETIRE_CONNECTION_ID frames and retransmitted if the packet
containing them is lost. containing them is lost.
o PING and PADDING frames contain no information, so lost PING or o PING and PADDING frames contain no information, so lost PING or
PADDING frames do not require repair. PADDING frames do not require repair.
Endpoints SHOULD prioritize retransmission of data over sending new Endpoints SHOULD prioritize retransmission of data over sending new
data, unless priorities specified by the application indicate data, unless priorities specified by the application indicate
otherwise (see Section 2.3). otherwise (see Section 2.3).
Even though a sender is encouraged to assemble frames containing up-
to-date information every time it sends a packet, it is not forbidden
to retransmit copies of frames from lost packets. A receiver MUST
accept packets containing an outdated frame, such as a MAX_DATA frame
carrying a smaller maximum data than one found in an older packet.
Upon detecting losses, a sender MUST take appropriate congestion Upon detecting losses, a sender MUST take appropriate congestion
control action. The details of loss detection and congestion control control action. The details of loss detection and congestion control
are described in [QUIC-RECOVERY]. are described in [QUIC-RECOVERY].
13.3. Explicit Congestion Notification 13.3. Explicit Congestion Notification
QUIC endpoints can use Explicit Congestion Notification (ECN) QUIC endpoints can use Explicit Congestion Notification (ECN)
[RFC3168] to detect and respond to network congestion. ECN allows a [RFC3168] to detect and respond to network congestion. ECN allows a
network node to indicate congestion in the network by setting a network node to indicate congestion in the network by setting a
codepoint in the IP header of a packet instead of dropping it. codepoint in the IP header of a packet instead of dropping it.
skipping to change at page 71, line 21 skipping to change at page 71, line 37
Section 13.1 and Section 19.3). Note that this requires being able Section 13.1 and Section 19.3). Note that this requires being able
to read the ECN codepoints from the enclosing IP packet, which is not to read the ECN codepoints from the enclosing IP packet, which is not
possible on all platforms. possible on all platforms.
A packet detected by a receiver as a duplicate does not affect the A packet detected by a receiver as a duplicate does not affect the
receiver's local ECN codepoint counts; see (Section 21.7) for receiver's local ECN codepoint counts; see (Section 21.7) for
relevant security concerns. relevant security concerns.
If an endpoint receives a QUIC packet without an ECT or CE codepoint If an endpoint receives a QUIC packet without an ECT or CE codepoint
in the IP packet header, it responds per Section 13.1 with an ACK in the IP packet header, it responds per Section 13.1 with an ACK
frame without increasing any ECN counts. if an endpoint does not frame without increasing any ECN counts. If an endpoint does not
implement ECN support or does not have access to received ECN implement ECN support or does not have access to received ECN
codepoints, it does not increase ECN counts. codepoints, it does not increase ECN counts.
Coalesced packets (see Section 12.2) mean that several packets can Coalesced packets (see Section 12.2) mean that several packets can
share the same IP header. The ECN counter for the ECN codepoint share the same IP header. The ECN counter for the ECN codepoint
received in the associated IP header are incremented once for each received in the associated IP header are incremented once for each
QUIC packet, not per enclosing IP packet or UDP datagram. QUIC packet, not per enclosing IP packet or UDP datagram.
Each packet number space maintains separate acknowledgement state and Each packet number space maintains separate acknowledgement state and
separate ECN counts. For example, if one each of an Initial, 0-RTT, separate ECN counts. For example, if one each of an Initial, 0-RTT,
skipping to change at page 72, line 13 skipping to change at page 72, line 30
a network device that is experiencing congestion. a network device that is experiencing congestion.
If a QUIC packet sent with an ECT codepoint is newly acknowledged by If a QUIC packet sent with an ECT codepoint is newly acknowledged by
the peer in an ACK frame without ECN feedback, the endpoint stops the peer in an ACK frame without ECN feedback, the endpoint stops
setting ECT codepoints in subsequent IP packets, with the expectation setting ECT codepoints in subsequent IP packets, with the expectation
that either the network path or the peer no longer supports ECN. that either the network path or the peer no longer supports ECN.
Network devices that corrupt or apply non-standard ECN markings might Network devices that corrupt or apply non-standard ECN markings might
result in reduced throughput or other undesirable side-effects. To result in reduced throughput or other undesirable side-effects. To
reduce this risk, an endpoint uses the following steps to verify the reduce this risk, an endpoint uses the following steps to verify the
counts it receives in an ACK frame. Counts MUST NOT be verified if counts it receives in an ACK frame.
the ACK frame does not increase the largest received packet number at
the endpoint.
o The total increase in ECT(0), ECT(1), and CE counts MUST be no o The total increase in ECT(0), ECT(1), and CE counts MUST be no
smaller than the total number of QUIC packets sent with an ECT smaller than the total number of QUIC packets sent with an ECT
codepoint that are newly acknowledged in this ACK frame. This codepoint that are newly acknowledged in this ACK frame. This
step detects any network remarking from ECT(0), ECT(1), or CE step detects any network remarking from ECT(0), ECT(1), or CE
codepoints to Not-ECT. codepoints to Not-ECT.
o Any increase in either ECT(0) or ECT(1) counts, plus any increase o Any increase in either ECT(0) or ECT(1) counts, plus any increase
in the CE count, MUST be no smaller than the number of packets in the CE count, MUST be no smaller than the number of packets
sent with the corresponding ECT codepoint that are newly sent with the corresponding ECT codepoint that are newly
acknowledged in this ACK frame. This step detects any erroneous acknowledged in this ACK frame. This step detects any erroneous
network remarking from ECT(0) to ECT(1) (or vice versa). network remarking from ECT(0) to ECT(1) (or vice versa).
An endpoint could miss acknowledgements for a packet when ACK frames An endpoint could miss acknowledgements for a packet when ACK frames
are lost. It is therefore possible for the total increase in ECT(0), are lost. It is therefore possible for the total increase in ECT(0),
ECT(1), and CE counts to be greater than the number of packets ECT(1), and CE counts to be greater than the number of packets
acknowledged in an ACK frame. When this happens, and if verification acknowledged in an ACK frame. When this happens, and if verification
succeeds, the local reference counts MUST be increased to match the succeeds, the local reference counts MUST be increased to match the
counts in the ACK frame. counts in the ACK frame.
Processing counts out of order can result in verification failure.
An endpoint SHOULD NOT perform this verification if the ACK frame is
received in a packet with packet number lower than a previously
received ACK frame. Verifying based on ACK frames that arrive out of
order can result in disabling ECN unnecessarily.
Upon successful verification, an endpoint continues to set ECT Upon successful verification, an endpoint continues to set ECT
codepoints in subsequent packets with the expectation that the path codepoints in subsequent packets with the expectation that the path
is ECN-capable. is ECN-capable.
If verification fails, then the endpoint ceases setting ECT If verification fails, then the endpoint ceases setting ECT
codepoints in subsequent IP packets with the expectation that either codepoints in subsequent IP packets with the expectation that either
the network path or the peer does not support ECN. the network path or the peer does not support ECN.
If an endpoint sets ECT codepoints on outgoing IP packets and If an endpoint sets ECT codepoints on outgoing IP packets and
encounters a retransmission timeout due to the absence of encounters a retransmission timeout due to the absence of
skipping to change at page 73, line 10 skipping to change at page 73, line 31
ECT codepoints in subsequent packets. Doing so allows the connection ECT codepoints in subsequent packets. Doing so allows the connection
to be resilient to network elements that corrupt ECN codepoints in to be resilient to network elements that corrupt ECN codepoints in
the IP header or drop packets with ECT or CE codepoints in the IP the IP header or drop packets with ECT or CE codepoints in the IP
header. header.
14. Packet Size 14. Packet Size
The QUIC packet size includes the QUIC header and protected payload, The QUIC packet size includes the QUIC header and protected payload,
but not the UDP or IP header. but not the UDP or IP header.
Clients MUST ensure they send the first Initial packet in single IP Clients MUST ensure they send the first Initial packet in a single IP
packet. Similarly, the first Initial packet sent after receiving a packet. Similarly, the first Initial packet sent after receiving a
Retry packet MUST be sent in a single IP packet. Retry packet MUST be sent in a single IP packet.
The payload of a UDP datagram carrying the first Initial packet MUST The payload of a UDP datagram carrying the first Initial packet MUST
be expanded to at least 1200 bytes, by adding PADDING frames to the be expanded to at least 1200 bytes, by adding PADDING frames to the
Initial packet and/or by combining the Initial packet with a 0-RTT Initial packet and/or by combining the Initial packet with a 0-RTT
packet (see Section 12.2). Sending a UDP datagram of this size packet (see Section 12.2). Sending a UDP datagram of this size
ensures that the network path supports a reasonable Maximum ensures that the network path supports a reasonable Maximum
Transmission Unit (MTU), and helps reduce the amplitude of Transmission Unit (MTU), and helps reduce the amplitude of
amplification attacks caused by server responses toward an unverified amplification attacks caused by server responses toward an unverified
skipping to change at page 78, line 7 skipping to change at page 78, line 22
integers, but do not use this encoding. integers, but do not use this encoding.
17. Packet Formats 17. Packet Formats
All numeric values are encoded in network byte order (that is, big- All numeric values are encoded in network byte order (that is, big-
endian) and all field sizes are in bits. Hexadecimal notation is endian) and all field sizes are in bits. Hexadecimal notation is
used for describing the value of fields. used for describing the value of fields.
17.1. Packet Number Encoding and Decoding 17.1. Packet Number Encoding and Decoding
Packet numbers in long and short packet headers are encoded in 1 to 4 Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3).
bytes. The number of bits required to represent the packet number is When present in long or short packet headers, they are encoded in 1
reduced by including the least significant bits of the packet number. to 4 bytes. The number of bits required to represent the packet
number is reduced by including the least significant bits of the
packet number.
The encoded packet number is protected as described in Section 5.4 of The encoded packet number is protected as described in Section 5.4 of
[QUIC-TLS]. [QUIC-TLS].
The sender MUST use a packet number size able to represent more than The sender MUST use a packet number size able to represent more than
twice as large a range than the difference between the largest twice as large a range than the difference between the largest
acknowledged packet and packet number being sent. A peer receiving acknowledged packet and packet number being sent. A peer receiving
the packet will then correctly decode the packet number, unless the the packet will then correctly decode the packet number, unless the
packet is delayed in transit such that it arrives after many higher- packet is delayed in transit such that it arrives after many higher-
numbered packets have been received. An endpoint SHOULD use a large numbered packets have been received. An endpoint SHOULD use a large
skipping to change at page 79, line 5 skipping to change at page 79, line 18
Once header protection is removed, the packet number is decoded by Once header protection is removed, the packet number is decoded by
finding the packet number value that is closest to the next expected finding the packet number value that is closest to the next expected
packet. The next expected packet is the highest received packet packet. The next expected packet is the highest received packet
number plus one. For example, if the highest successfully number plus one. For example, if the highest successfully
authenticated packet had a packet number of 0xa82f30ea, then a packet authenticated packet had a packet number of 0xa82f30ea, then a packet
containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32.
Example pseudo-code for packet number decoding can be found in Example pseudo-code for packet number decoding can be found in
Appendix A. Appendix A.
17.2. Long Header Packet 17.2. Long Header Packets
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|1|T T|R R|P P| |1|1|T T|X X X X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) | | Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)| |DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ... | Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ... | Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Long Header Packet Format Figure 10: Long Header Packet Format
Long headers are used for packets that are sent prior to the Long headers are used for packets that are sent prior to the
completion of version negotiation and establishment of 1-RTT keys. completion of version negotiation and establishment of 1-RTT keys.
Once both conditions are met, a sender switches to sending packets Once both conditions are met, a sender switches to sending packets
using the short header (Section 17.3). The long form allows for using the short header (Section 17.3). The long form allows for
special packets - such as the Version Negotiation packet - to be special packets - such as the Version Negotiation packet - to be
represented in this uniform fixed-length packet format. Packets that represented in this uniform fixed-length packet format. Packets that
use the long header contain the following fields: use the long header contain the following fields:
skipping to change at page 79, line 48 skipping to change at page 80, line 9
byte) is set to 1 for long headers. byte) is set to 1 for long headers.
Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
containing a zero value for this bit are not valid packets in this containing a zero value for this bit are not valid packets in this
version and MUST be discarded. version and MUST be discarded.
Long Packet Type (T): The next two bits (those with a mask of 0x30) Long Packet Type (T): The next two bits (those with a mask of 0x30)
of byte 0 contain a packet type. Packet types are listed in of byte 0 contain a packet type. Packet types are listed in
Table 5. Table 5.
Reserved Bits (R): The next two bits (those with a mask of 0x0c) of Type-Specific Bits (X): The lower four bits (those with a mask of
byte 0 are reserved. These bits are protected using header 0x0f) of byte 0 are type-specific.
protection (see Section 5.4 of [QUIC-TLS]). The value included
prior to protection MUST be set to 0. An endpoint MUST treat
receipt of a packet that has a non-zero value for these bits after
removing protection as a connection error of type
PROTOCOL_VIOLATION.
Packet Number Length (P): The least significant two bits (those with
a mask of 0x03) of byte 0 contain the length of the packet number,
encoded as an unsigned, two-bit integer that is one less than the
length of the packet number field in bytes. That is, the length
of the packet number field is the value of this field, plus one.
These bits are protected using header protection (see Section 5.4
of [QUIC-TLS]).
Version: The QUIC Version is a 32-bit field that follows the first Version: The QUIC Version is a 32-bit field that follows the first
byte. This field indicates which version of QUIC is in use and byte. This field indicates which version of QUIC is in use and
determines how the rest of the protocol fields are interpreted. determines how the rest of the protocol fields are interpreted.
DCIL and SCIL: The byte following the version contains the lengths DCIL and SCIL: The byte following the version contains the lengths
of the two connection ID fields that follow it. These lengths are of the two connection ID fields that follow it. These lengths are
encoded as two 4-bit unsigned integers. The Destination encoded as two 4-bit unsigned integers. The Destination
Connection ID Length (DCIL) field occupies the 4 high bits of the Connection ID Length (DCIL) field occupies the 4 high bits of the
byte and the Source Connection ID Length (SCIL) field occupies the byte and the Source Connection ID Length (SCIL) field occupies the
skipping to change at page 80, line 41 skipping to change at page 80, line 38
Destination Connection ID: The Destination Connection ID field Destination Connection ID: The Destination Connection ID field
follows the connection ID lengths and is either 0 bytes in length follows the connection ID lengths and is either 0 bytes in length
or between 4 and 18 bytes. Section 7.2 describes the use of this or between 4 and 18 bytes. Section 7.2 describes the use of this
field in more detail. field in more detail.
Source Connection ID: The Source Connection ID field follows the Source Connection ID: The Source Connection ID field follows the
Destination Connection ID and is either 0 bytes in length or Destination Connection ID and is either 0 bytes in length or
between 4 and 18 bytes. Section 7.2 describes the use of this between 4 and 18 bytes. Section 7.2 describes the use of this
field in more detail. field in more detail.
Length: The length of the remainder of the packet (that is, the In this version of QUIC, the following packet types with the long
Packet Number and Payload fields) in bytes, encoded as a variable- header are defined:
length integer (Section 16).
Packet Number: The packet number field is 1 to 4 bytes long. The
packet number has confidentiality protection separate from packet
protection, as described in Section 5.4 of [QUIC-TLS]. The length
of the packet number field is encoded in the plaintext packet
number. See Section 17.1 for details.
Payload: The payload of the packet.
The following packet types are defined:
+------+-----------------+--------------+ +------+-----------+----------------+
| Type | Name | Section | | Type | Name | Section |
+------+-----------------+--------------+ +------+-----------+----------------+
| 0x0 | Initial | Section 17.5 | | 0x0 | Initial | Section 17.2.2 |
| | | | | | | |
| 0x1 | 0-RTT Protected | Section 12.1 | | 0x1 | 0-RTT | Section 17.2.3 |
| | | | | | | |
| 0x2 | Handshake | Section 17.6 | | 0x2 | Handshake | Section 17.2.4 |
| | | | | | | |
| 0x3 | Retry | Section 17.7 | | 0x3 | Retry | Section 17.2.5 |
+------+-----------------+--------------+ +------+-----------+----------------+
Table 5: Long Header Packet Types Table 5: Long Header Packet Types
The header form bit, connection ID lengths byte, Destination and The header form bit, connection ID lengths byte, Destination and
Source Connection ID fields, and Version fields of a long header Source Connection ID fields, and Version fields of a long header
packet are version-independent. The other fields in the first byte, packet are version-independent. The other fields in the first byte
plus the Length and Packet Number fields are version-specific. See are version-specific. See [QUIC-INVARIANTS] for details on how
[QUIC-INVARIANTS] for details on how packets from different versions packets from different versions of 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. While type-specific semantics for this
are described in the following sections. version are described in the following sections, several long-header
packets in this version of QUIC contain these additional fields:
The end of the packet is determined by the Length field. The Length
field covers both the Packet Number and Payload fields, both of which
are confidentiality protected and initially of unknown length. The
length of the Payload field is learned once header protection is
removed. The Length field enables packet coalescing (Section 12.2).
17.3. Short Header Packet
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|S|R|R|K|P P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Short Header Packet Format
The short header can be used after the version and 1-RTT keys are
negotiated. Packets that use the short header contain the following
fields:
Header Form: The most significant bit (0x80) of byte 0 is set to 0
for the short header.
Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
containing a zero value for this bit are not valid packets in this
version and MUST be discarded.
Spin Bit (S): The sixth bit (0x20) of byte 0 is the Latency Spin
Bit, set as described in [SPIN].
Reserved Bits (R): The next two bits (those with a mask of 0x18) of
byte 0 are reserved. These bits are protected using header
protection (see Section 5.4 of [QUIC-TLS]). The value included
prior to protection MUST be set to 0. An endpoint MUST treat
receipt of a packet that has a non-zero value for these bits after
removing protection as a connection error of type
PROTOCOL_VIOLATION.
Key Phase (K): The next bit (0x04) of byte 0 indicates the key Reserved Bits (R): Two bits (those with a mask of 0x0c) of byte 0
phase, which allows a recipient of a packet to identify the packet are reserved across multiple packet types. These bits are
protection keys that are used to protect the packet. See protected using header protection (see Section 5.4 of [QUIC-TLS]).
[QUIC-TLS] for details. This bit is protected using header The value included prior to protection MUST be set to 0. An
protection (see Section 5.4 of [QUIC-TLS]). endpoint MUST treat receipt of a packet that has a non-zero value
for these bits after removing protection as a connection error of
type PROTOCOL_VIOLATION.
Packet Number Length (P): The least significant two bits (those with Packet Number Length (P): In packet types which contain a Packet
a mask of 0x03) of byte 0 contain the length of the packet number, Number field, the least significant two bits (those with a mask of
encoded as an unsigned, two-bit integer that is one less than the 0x03) of byte 0 contain the length of the packet number, encoded
length of the packet number field in bytes. That is, the length as an unsigned, two-bit integer that is one less than the length
of the packet number field is the value of this field, plus one. of the packet number field in bytes. That is, the length of the
These bits are protected using header protection (see Section 5.4 packet number field is the value of this field, plus one. These
of [QUIC-TLS]). bits are protected using header protection (see Section 5.4 of
[QUIC-TLS]).
Destination Connection ID: The Destination Connection ID is a Length: The length of the remainder of the packet (that is, the
connection ID that is chosen by the intended recipient of the Packet Number and Payload fields) in bytes, encoded as a variable-
packet. See Section 5.1 for more details. length integer (Section 16).
Packet Number: The packet number field is 1 to 4 bytes long. The Packet Number: The packet number field is 1 to 4 bytes long. The
packet number has confidentiality protection separate from packet packet number has confidentiality protection separate from packet
protection, as described in Section 5.4 of [QUIC-TLS]. The length protection, as described in Section 5.4 of [QUIC-TLS]. The length
of the packet number field is encoded in Packet Number Length of the packet number field is encoded in the Packet Number Length
field. See Section 17.1 for details. bits of byte 0 (see above).
Protected Payload: Packets with a short header always include a
1-RTT protected payload.
The header form bit and the connection ID field of a short header
packet are version-independent. The remaining fields are specific to
the selected QUIC version. See [QUIC-INVARIANTS] for details on how
packets from different versions of QUIC are interpreted.
17.4. Version Negotiation Packet 17.2.1. Version Negotiation Packet
A Version Negotiation packet is inherently not version-specific, and A Version Negotiation packet is inherently not version-specific.
does not use the long packet header (see Section 17.2). Upon receipt Upon receipt by a client, it will be identified as a Version
by a client, it will appear to be a packet using the long header, but Negotiation packet based on the Version field having a value of 0.
will be identified as a Version Negotiation packet based on the
Version field having a value of 0.
The Version Negotiation packet is a response to a client packet that The Version Negotiation packet is a response to a client packet that
contains a version that is not supported by the server, and is only contains a version that is not supported by the server, and is only
sent by servers. sent by servers.
The layout of a Version Negotiation packet is: The layout of a Version Negotiation packet is:
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 83, line 46 skipping to change at page 82, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version 1 (32) ... | Supported Version 1 (32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version 2 (32)] ... | [Supported Version 2 (32)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version N (32)] ... | [Supported Version N (32)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Version Negotiation Packet Figure 11: Version Negotiation Packet
The value in the Unused field is selected randomly by the server. The value in the Unused field is selected randomly by the server.
The Version field of a Version Negotiation packet MUST be set to The Version field of a Version Negotiation packet MUST be set to
0x00000000. 0x00000000.
The server MUST include the value from the Source Connection ID field The server MUST include the value from the Source Connection ID field
of the packet it receives in the Destination Connection ID field. of the packet it receives in the Destination Connection ID field.
The value for Source Connection ID MUST be copied from the The value for Source Connection ID MUST be copied from the
Destination Connection ID of the received packet, which is initially Destination Connection ID of the received packet, which is initially
skipping to change at page 84, line 26 skipping to change at page 83, line 22
A Version Negotiation packet cannot be explicitly acknowledged in an A Version Negotiation packet cannot be explicitly acknowledged in an
ACK frame by a client. Receiving another Initial packet implicitly ACK frame by a client. Receiving another Initial packet implicitly
acknowledges a Version Negotiation packet. acknowledges a Version Negotiation packet.
The Version Negotiation packet does not include the Packet Number and The Version Negotiation packet does not include the Packet Number and
Length fields present in other packets that use the long header form. Length fields present in other packets that use the long header form.
Consequently, a Version Negotiation packet consumes an entire UDP Consequently, a Version Negotiation packet consumes an entire UDP
datagram. datagram.
A server MUST NOT send more than one Version Negotiation packet in
response to a single UDP datagram.
See Section 6 for a description of the version negotiation process. See Section 6 for a description of the version negotiation process.
17.5. Initial Packet 17.2.2. Initial Packet
An Initial packet uses long headers with a type value of 0x0. It An Initial packet uses long headers with a type value of 0x0. It
carries the first CRYPTO frames sent by the client and server to carries the first CRYPTO frames sent by the client and server to
perform key exchange, and carries ACKs in either direction. perform key exchange, and carries ACKs in either direction.
In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys
(Initial keys) as described in [QUIC-TLS]. This protection does not
provide confidentiality or integrity against on-path attackers, but
provides some level of protection against off-path attackers.
An Initial packet (shown in Figure 13) has two additional header
fields that are added to the Long Header before the Length field.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|1| 0 |R R|P P| |1|1| 0 |R R|P P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) | | Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)| |DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ... | Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ... | Source Connection ID (0/32..144) ...
skipping to change at page 85, line 27 skipping to change at page 84, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ... | Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ... | Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ... | Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ... | Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Initial Packet Figure 12: Initial Packet
These fields include the token that was previously provided in a The Initial packet contains a long header as well as the Length and
Retry packet or NEW_TOKEN frame: Packet Number fields. The first byte contains the Reserved and
Packet Number Length bits. Between the SCID and Length fields, there
are two additional field specific to the Initial packet.
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
Token field, in bytes. This value is zero if no token is present. Token field, in bytes. This value is zero if no token is present.
Initial packets sent by the server MUST set the Token Length field Initial packets sent by the server MUST set the Token Length field
to zero; clients that receive an Initial packet with a non-zero to zero; clients that receive an Initial packet with a non-zero
Token Length field MUST either discard the packet or generate a Token Length field MUST either discard the packet or generate a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
Token: The value of the token. Token: The value of the token that was previously provided in a
Retry packet or NEW_TOKEN frame.
Payload: The payload of the packet.
In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys
(Initial keys) as described in [QUIC-TLS]. This protection does not
provide confidentiality or integrity against on-path attackers, but
provides some level of protection against off-path attackers.
The client and server use the Initial packet type for any packet that The client and server use the Initial packet type for any packet that
contains an initial cryptographic handshake message. This includes contains an initial cryptographic handshake message. This includes
all cases where a new packet containing the initial cryptographic all cases where a new packet containing the initial cryptographic
message needs to be created, such as the packets sent after receiving message needs to be created, such as the packets sent after receiving
a Version Negotiation (Section 17.4) or Retry packet (Section 17.7). a Version Negotiation (Section 17.2.1) or Retry packet
(Section 17.2.5).
A server sends its first Initial packet in response to a client A server sends its first Initial packet in response to a client
Initial. A server may send multiple Initial packets. The Initial. A server may send multiple Initial packets. The
cryptographic key exchange could require multiple round trips or cryptographic key exchange could require multiple round trips or
retransmissions of this data. retransmissions of this data.
The payload of an Initial packet includes a CRYPTO frame (or frames) The payload of an Initial packet includes a CRYPTO frame (or frames)
containing a cryptographic handshake message, ACK frames, or both. containing a cryptographic handshake message, ACK frames, or both.
PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint
that receives an Initial packet containing other frames can either that receives an Initial packet containing other frames can either
skipping to change at page 86, line 24 skipping to change at page 85, line 36
single UDP datagram (see Section 7). The first CRYPTO frame sent single UDP datagram (see Section 7). The first CRYPTO frame sent
always begins at an offset of 0 (see Section 7). always begins at an offset of 0 (see Section 7).
Note that if the server sends a HelloRetryRequest, the client will Note that if the server sends a HelloRetryRequest, the client will
send a second Initial packet. This Initial packet will continue the send a second Initial packet. This Initial packet will continue the
cryptographic handshake and will contain a CRYPTO frame with an cryptographic handshake and will contain a CRYPTO frame with an
offset matching the size of the CRYPTO frame sent in the first offset matching the size of the CRYPTO frame sent in the first
Initial packet. Cryptographic handshake messages subsequent to the Initial packet. Cryptographic handshake messages subsequent to the
first do not need to fit within a single UDP datagram. first do not need to fit within a single UDP datagram.
17.5.1. Abandoning Initial Packets 17.2.2.1. Abandoning Initial Packets
A client stops both sending and processing Initial packets when it A client stops both sending and processing Initial packets when it
sends its first Handshake packet. A server stops sending and sends its first Handshake packet. A server stops sending and
processing Initial packets when it receives its first Handshake processing Initial packets when it receives its first Handshake
packet. Though packets might still be in flight or awaiting packet. Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged acknowledgment, no further Initial packets need to be exchanged
beyond this point. Initial packet protection keys are discarded (see beyond this point. Initial packet protection keys are discarded (see
Section 4.10 of [QUIC-TLS]) along with any loss recovery and Section 4.10 of [QUIC-TLS]) along with any loss recovery and
congestion control state (see Sections 5.3.1.2 and 6.9 of congestion control state (see Sections 5.3.1.2 and 6.9 of
[QUIC-RECOVERY]). [QUIC-RECOVERY]).
Any data in CRYPTO frames is discarded - and no longer retransmitted Any data in CRYPTO frames is discarded - and no longer retransmitted
- when Initial keys are discarded. - when Initial keys are discarded.
17.5.2. Starting Packet Numbers 17.2.3. 0-RTT
The first Initial packet sent by either endpoint contains a packet A 0-RTT packet uses long headers with a type value of 0x1, followed
number of 0. The packet number MUST increase monotonically by the Length and Packet Number fields. The first byte contains the
thereafter. Initial packets are in a different packet number space Reserved and Packet Number Length bits. It is used to carry "early"
to other packets (see Section 12.3). data from the client to the server as part of the first flight, prior
to handshake completion. As part of the TLS handshake, the server
can accept or reject this early data.
17.5.3. 0-RTT Packet Numbers See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its
limitations.
+-+-+-+-+-+-+-+-+
|1|1| 1 |R R|P P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-RTT Packet
Packet numbers for 0-RTT protected packets use the same space as Packet numbers for 0-RTT protected packets use the same space as
1-RTT protected packets. 1-RTT protected packets.
After a client receives a Retry or Version Negotiation packet, 0-RTT After a client receives a Retry or Version Negotiation packet, 0-RTT
packets are likely to have been lost or discarded by the server. A packets are likely to have been lost or discarded by the server. A
client MAY attempt to resend data in 0-RTT packets after it sends a client MAY attempt to resend data in 0-RTT packets after it sends a
new Initial packet. new Initial packet.
A client MUST NOT reset the packet number it uses for 0-RTT packets. A client MUST NOT reset the packet number it uses for 0-RTT packets.
skipping to change at page 87, line 32 skipping to change at page 87, line 22
that all packets up to the current packet number are in flight, that all packets up to the current packet number are in flight,
starting from a packet number of 0. Thus, 0-RTT packets could need starting from a packet number of 0. Thus, 0-RTT packets could need
to use a longer packet number encoding. to use a longer packet number encoding.
A client SHOULD instead generate a fresh cryptographic handshake A client SHOULD instead generate a fresh cryptographic handshake
message and start packet numbers from 0. This ensures that new 0-RTT message and start packet numbers from 0. This ensures that new 0-RTT
packets will not use the same keys, avoiding any risk of key and packets will not use the same keys, avoiding any risk of key and
nonce reuse; this also prevents 0-RTT packets from previous handshake nonce reuse; this also prevents 0-RTT packets from previous handshake
attempts from being accepted as part of the connection. attempts from being accepted as part of the connection.
17.6. Handshake Packet 17.2.4. Handshake Packet
A Handshake packet uses long headers with a type value of 0x2. It is A Handshake packet uses long headers with a type value of 0x2,
used to carry acknowledgments and cryptographic handshake messages followed by the Length and Packet Number fields. The first byte
from the server and client. contains the Reserved and Packet Number Length bits. It is used to
carry acknowledgments and cryptographic handshake messages from the
server and client.
+-+-+-+-+-+-+-+-+
|1|1| 2 |R R|P P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Handshake Protected Packet
Once a client has received a Handshake packet from a server, it uses Once a client has received a Handshake packet from a server, it uses
Handshake packets to send subsequent cryptographic handshake messages Handshake packets to send subsequent cryptographic handshake messages
and acknowledgments to the server. and acknowledgments to the server.
The Destination Connection ID field in a Handshake packet contains a The Destination Connection ID field in a Handshake packet contains a
connection ID that is chosen by the recipient of the packet; the connection ID that is chosen by the recipient of the packet; the
Source Connection ID includes the connection ID that the sender of Source Connection ID includes the connection ID that the sender of
the packet wishes to use (see Section 7.2). the packet wishes to use (see Section 7.2).
The first Handshake packet sent by a server contains a packet number Handshake packets are their own packet number space, and thus the
of 0. Handshake packets are their own packet number space. Packet first Handshake packet sent by a server contains a packet number of
numbers are incremented normally for other Handshake packets. 0.
The payload of this packet contains CRYPTO frames and could contain The payload of this packet contains CRYPTO frames and could contain
PADDING, or ACK frames. Handshake packets MAY contain PADDING, or ACK frames. Handshake packets MAY contain
CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake
packets with other frames as a connection error. packets with other frames as a connection error.
Like Initial packets (see Section 17.5.1), data in CRYPTO frames at Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at
the Handshake encryption level is discarded - and no longer the Handshake encryption level is discarded - and no longer
retransmitted - when Handshake protection keys are discarded. retransmitted - when Handshake protection keys are discarded.
17.7. Retry Packet 17.2.5. Retry Packet
A Retry packet uses a long packet header with a type value of 0x3. A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server. It is It carries an address validation token created by the server. It is
used by a server that wishes to perform a stateless retry (see used by a server that wishes to perform a stateless retry (see
Section 8.1). Section 8.1).
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|1| 3 |ODCIL(4| |1|1| 3 | ODCIL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) | | Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)| |DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ... | Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ... | Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Connection ID (0/32..144) ... | Original Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Token (*) ... | Retry Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Retry Packet Figure 14: Retry Packet
A Retry packet (shown in Figure 14) only uses the invariant portion A Retry packet (shown in Figure 14) does not contain any protected
of the long packet header [QUIC-INVARIANTS]; that is, the fields up fields. In addition to the long header, it contains these additional
to and including the Destination and Source Connection ID fields. A fields:
Retry packet does not contain any protected fields. Like Version
Negotiation, a Retry packet contains the long header including the
connection IDs, but omits the Length, Packet Number, and Payload
fields. These are replaced with:
ODCIL: The four least-significant bits of the first byte of a Retry ODCIL: The four least-significant bits of the first byte of a Retry
packet are not protected as they are for other packets with the packet are not protected as they are for other packets with the
long header, because Retry packets don't contain a protected long header, because Retry packets don't contain a protected
payload. These bits instead encode the length of the Original payload. These bits instead encode the length of the Original
Destination Connection ID field. The length uses the same Destination Connection ID field. The length uses the same
encoding as the DCIL and SCIL fields. encoding as the DCIL and SCIL fields.
Original Destination Connection ID: The Original Destination Original Destination Connection ID: The Original Destination
Connection ID contains the value of the Destination Connection ID Connection ID contains the value of the Destination Connection ID
skipping to change at page 89, line 28 skipping to change at page 89, line 33
The server includes a connection ID of its choice in the Source The server includes a connection ID of its choice in the Source
Connection ID field. This value MUST not be equal to the Destination Connection ID field. This value MUST not be equal to the Destination
Connection ID field of the packet sent by the client. The client Connection ID field of the packet sent by the client. The client
MUST use this connection ID in the Destination Connection ID of MUST use this connection ID in the Destination Connection ID of
subsequent packets that it sends. subsequent packets that it sends.
A server MAY send Retry packets in response to Initial and 0-RTT A server MAY send Retry packets in response to Initial and 0-RTT
packets. A server can either discard or buffer 0-RTT packets that it packets. A server can either discard or buffer 0-RTT packets that it
receives. A server can send multiple Retry packets as it receives receives. A server can send multiple Retry packets as it receives
Initial or 0-RTT packets. Initial or 0-RTT packets. A server MUST NOT send more than one Retry
packet in response to a single UDP datagram.
A client MUST accept and process at most one Retry packet for each A client MUST accept and process at most one Retry packet for each
connection attempt. After the client has received and processed an connection attempt. After the client has received and processed an
Initial or Retry packet from the server, it MUST discard any Initial or Retry packet from the server, it MUST discard any
subsequent Retry packets that it receives. subsequent Retry packets that it receives.
Clients MUST discard Retry packets that contain an Original Clients MUST discard Retry packets that contain an Original
Destination Connection ID field that does not match the Destination Destination Connection ID field that does not match the Destination
Connection ID from its Initial packet. This prevents an off-path Connection ID from its Initial packet. This prevents an off-path
attacker from injecting a Retry packet. attacker from injecting a Retry packet.
skipping to change at page 90, line 16 skipping to change at page 90, line 21
token values from the Retry packet (see Section 7.2). Aside from token values from the Retry packet (see Section 7.2). Aside from
this, the Initial packet sent by the client is subject to the same this, the Initial packet sent by the client is subject to the same
restrictions as the first Initial packet. A client can either reuse restrictions as the first Initial packet. A client can either reuse
the cryptographic handshake message or construct a new one at its the cryptographic handshake message or construct a new one at its
discretion. discretion.
A client MAY attempt 0-RTT after receiving a Retry packet by sending A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server. A client 0-RTT packets to the connection ID provided by the server. A client
that sends additional 0-RTT packets without constructing a new that sends additional 0-RTT packets without constructing a new
cryptographic handshake message MUST NOT reset the packet number to 0 cryptographic handshake message MUST NOT reset the packet number to 0
after a Retry packet, see Section 17.5.3. after a Retry packet, see Section 17.2.3.
A server acknowledges the use of a Retry packet for a connection A server acknowledges the use of a Retry packet for a connection
using the original_connection_id transport parameter (see using the original_connection_id transport parameter (see
Section 18.1). If the server sends a Retry packet, it MUST include Section 18.1). If the server sends a Retry packet, it MUST include
the value of the Original Destination Connection ID field of the the value of the Original Destination Connection ID field of the
Retry packet (that is, the Destination Connection ID field from the Retry packet (that is, the Destination Connection ID field from the
client's first Initial packet) in the transport parameter. client's first Initial packet) in the transport parameter.
If the client received and processed a Retry packet, it validates If the client received and processed a Retry packet, it MUST validate
that the original_connection_id transport parameter is present and that the original_connection_id transport parameter is present and
correct; otherwise, it validates that the transport parameter is correct; otherwise, it MUST validate that the transport parameter is
absent. A client MUST treat a failed validation as a connection absent. A client MUST treat a failed validation as a connection
error of type TRANSPORT_PARAMETER_ERROR. error of type TRANSPORT_PARAMETER_ERROR.
A Retry packet does not include a packet number and cannot be A Retry packet does not include a packet number and cannot be
explicitly acknowledged by a client. explicitly acknowledged by a client.
17.3. Short Header Packets
This version of QUIC defines a single packet type which uses the
short packet header.
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|S|R|R|K|P P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Short Header Packet Format
The short header can be used after the version and 1-RTT keys are
negotiated. Packets that use the short header contain the following
fields:
Header Form: The most significant bit (0x80) of byte 0 is set to 0
for the short header.
Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
containing a zero value for this bit are not valid packets in this
version and MUST be discarded.
Spin Bit (S): The sixth bit (0x20) of byte 0 is the Latency Spin
Bit, set as described in [SPIN].
Reserved Bits (R): The next two bits (those with a mask of 0x18) of
byte 0 are reserved. These bits are protected using header
protection (see Section 5.4 of [QUIC-TLS]). The value included
prior to protection MUST be set to 0. An endpoint MUST treat
receipt of a packet that has a non-zero value for these bits after
removing protection as a connection error of type
PROTOCOL_VIOLATION.
Key Phase (K): The next bit (0x04) of byte 0 indicates the key
phase, which allows a recipient of a packet to identify the packet
protection keys that are used to protect the packet. See
[QUIC-TLS] for details. This bit is protected using header
protection (see Section 5.4 of [QUIC-TLS]).
Packet Number Length (P): The least significant two bits (those with
a mask of 0x03) of byte 0 contain the length of the packet number,
encoded as an unsigned, two-bit integer that is one less than the
length of the packet number field in bytes. That is, the length
of the packet number field is the value of this field, plus one.
These bits are protected using header protection (see Section 5.4
of [QUIC-TLS]).
Destination Connection ID: The Destination Connection ID is a
connection ID that is chosen by the intended recipient of the
packet. See Section 5.1 for more details.
Packet Number: The packet number field is 1 to 4 bytes long. The
packet number has confidentiality protection separate from packet
protection, as described in Section 5.4 of [QUIC-TLS]. The length
of the packet number field is encoded in Packet Number Length
field. See Section 17.1 for details.
Protected Payload: Packets with a short header always include a
1-RTT protected payload.
The header form bit and the connection ID field of a short header
packet are version-independent. The remaining fields are specific to
the selected QUIC version. See [QUIC-INVARIANTS] for details on how
packets from different versions of QUIC are interpreted.
18. Transport Parameter Encoding 18. Transport Parameter Encoding
The format of the transport parameters is the TransportParameters The format of the transport parameters is the TransportParameters
struct from Figure 15. This is described using the presentation struct from Figure 16. This is described using the presentation
language from Section 3 of [TLS13]. language from Section 3 of [TLS13].
uint32 QuicVersion; uint32 QuicVersion;
enum { enum {
original_connection_id(0), original_connection_id(0),
idle_timeout(1), idle_timeout(1),
stateless_reset_token(2), stateless_reset_token(2),
max_packet_size(3), max_packet_size(3),
initial_max_data(4), initial_max_data(4),
skipping to change at page 91, line 42 skipping to change at page 93, line 42
case client_hello: case client_hello:
QuicVersion initial_version; QuicVersion initial_version;
case encrypted_extensions: case encrypted_extensions:
QuicVersion negotiated_version; QuicVersion negotiated_version;
QuicVersion supported_versions<4..2^8-4>; QuicVersion supported_versions<4..2^8-4>;
}; };
TransportParameter parameters<0..2^16-1>; TransportParameter parameters<0..2^16-1>;
} TransportParameters; } TransportParameters;
Figure 15: Definition of TransportParameters Figure 16: Definition of TransportParameters
The "extension_data" field of the quic_transport_parameters extension The "extension_data" field of the quic_transport_parameters extension
defined in [QUIC-TLS] contains a TransportParameters value. TLS defined in [QUIC-TLS] contains a TransportParameters value. TLS
encoding rules are therefore used to describe the encoding of encoding rules are therefore used to describe the encoding of
transport parameters. transport parameters.
QUIC encodes transport parameters into a sequence of bytes, which are QUIC encodes transport parameters into a sequence of bytes, which are
then included in the cryptographic handshake. then included in the cryptographic handshake.
18.1. Transport Parameter Definitions 18.1. Transport Parameter Definitions
skipping to change at page 92, line 24 skipping to change at page 94, line 24
The following transport parameters are defined: The following transport parameters are defined:
original_connection_id (0x0000): The value of the Destination original_connection_id (0x0000): The value of the Destination
Connection ID field from the first Initial packet sent by the Connection ID field from the first Initial packet sent by the
client. This transport parameter is only sent by a server. A client. This transport parameter is only sent by a server. A
server MUST include the original_connection_id transport parameter server MUST include the original_connection_id transport parameter
if it sent a Retry packet. if it sent a Retry packet.
idle_timeout (0x0001): The idle timeout is a value in seconds that idle_timeout (0x0001): The idle timeout is a value in seconds that
is encoded as an integer. If this parameter is absent or zero is encoded as an integer, see (Section 10.2). If this parameter
then the idle timeout is disabled. is absent or zero then the idle timeout is disabled.
stateless_reset_token (0x0002): A stateless reset token is used in stateless_reset_token (0x0002): A stateless reset token is used in
verifying a stateless reset, see Section 10.4. This parameter is verifying a stateless reset, see Section 10.4. This parameter is
a sequence of 16 bytes. This transport parameter is only sent by a sequence of 16 bytes. This transport parameter is only sent by
a server. a server.
max_packet_size (0x0003): The maximum packet size parameter is an max_packet_size (0x0003): The maximum packet size parameter is an
integer value that limits the size of packets that the endpoint is integer value that limits the size of packets that the endpoint is
willing to receive. This indicates that packets larger than this willing to receive. This indicates that packets larger than this
limit will be dropped. The default for this parameter is the limit will be dropped. The default for this parameter is the
skipping to change at page 93, line 18 skipping to change at page 95, line 18
integer value specifying the initial flow control limit for peer- integer value specifying the initial flow control limit for peer-
initiated bidirectional streams. This limit applies to newly initiated bidirectional streams. This limit applies to newly
created bidirectional streams opened by the endpoint that receives created bidirectional streams opened by the endpoint that receives
the transport parameter. In client transport parameters, this the transport parameter. In client transport parameters, this
applies to streams with an identifier with the least significant applies to streams with an identifier with the least significant
two bits set to 0x1; in server transport parameters, this applies two bits set to 0x1; in server transport parameters, this applies
to streams with the least significant two bits set to 0x0. to streams with the least significant two bits set to 0x0.
initial_max_stream_data_uni (0x0007): This parameter is an integer initial_max_stream_data_uni (0x0007): This parameter is an integer
value specifying the initial flow control limit for unidirectional value specifying the initial flow control limit for unidirectional
streams. This limit applies to newly created bidirectional streams. This limit applies to newly created unidirectional
streams opened by the endpoint that receives the transport streams opened by the endpoint that receives the transport
parameter. In client transport parameters, this applies to parameter. In client transport parameters, this applies to
streams with an identifier with the least significant two bits set streams with an identifier with the least significant two bits set
to 0x3; in server transport parameters, this applies to streams to 0x3; in server transport parameters, this applies to streams
with the least significant two bits set to 0x2. with the least significant two bits set to 0x2.
initial_max_streams_bidi (0x0008): The initial maximum bidirectional initial_max_streams_bidi (0x0008): The initial maximum bidirectional
streams parameter is an integer value that contains the initial streams parameter is an integer value that contains the initial
maximum number of bidirectional streams the peer may initiate. If maximum number of bidirectional streams the peer may initiate. If
this parameter is absent or zero, the peer cannot open this parameter is absent or zero, the peer cannot open
skipping to change at page 94, line 7 skipping to change at page 96, line 7
value is also used for ACK frames that are sent in Initial and value is also used for ACK frames that are sent in Initial and
Handshake packets. Values above 20 are invalid. Handshake packets. Values above 20 are invalid.
max_ack_delay (0x000b): The maximum ACK delay is an integer value max_ack_delay (0x000b): The maximum ACK delay is an integer value
indicating the maximum amount of time in milliseconds by which the indicating the maximum amount of time in milliseconds by which the
endpoint will delay sending acknowledgments. This value SHOULD endpoint will delay sending acknowledgments. This value SHOULD
include the receiver's expected delays in alarms firing. For include the receiver's expected delays in alarms firing. For
example, if a receiver sets a timer for 5ms and alarms commonly example, if a receiver sets a timer for 5ms and alarms commonly
fire up to 1ms late, then it should send a max_ack_delay of 6ms. fire up to 1ms late, then it should send a max_ack_delay of 6ms.
If this value is absent, a default of 25 milliseconds is assumed. If this value is absent, a default of 25 milliseconds is assumed.
Values of 2^14 or greater are invalid.
disable_migration (0x000c): The disable migration transport disable_migration (0x000c): The disable migration transport
parameter is included if the endpoint does not support connection parameter is included if the endpoint does not support connection
migration (Section 9). Peers of an endpoint that sets this migration (Section 9). Peers of an endpoint that sets this
transport parameter MUST NOT send any packets, including probing transport parameter MUST NOT send any packets, including probing
packets (Section 9.1), from a local address other than that used packets (Section 9.1), from a local address other than that used
to perform the handshake. This parameter is a zero-length value. to perform the handshake. This parameter is a zero-length value.
preferred_address (0x000d): The server's preferred address is used preferred_address (0x000d): The server's preferred address is used
to effect a change in server address at the end of the handshake, to effect a change in server address at the end of the handshake,
as described in Section 9.6. The format of this transport as described in Section 9.6. The format of this transport
parameter is the PreferredAddress struct shown in Figure 16. This parameter is the PreferredAddress struct shown in Figure 17. This
transport parameter is only sent by a server. transport parameter is only sent by a server. Servers MAY choose
to only send a preferred address of one address family by sending
an all-zero address and port (0.0.0.0:0 or ::.0) for the other
family.
struct { struct {
enum { IPv4(4), IPv6(6), (15) } ipVersion; opaque ipv4Address[4];
opaque ipAddress<4..2^8-1>; uint16 ipv4Port;
uint16 port; opaque ipv6Address[16];
uint16 ipv6Port;
opaque connectionId<0..18>; opaque connectionId<0..18>;
opaque statelessResetToken[16]; opaque statelessResetToken[16];
} PreferredAddress; } PreferredAddress;
Figure 16: Preferred Address format Figure 17: Preferred Address format
If present, transport parameters that set initial flow control limits If present, transport parameters that set initial flow control limits
(initial_max_stream_data_bidi_local, (initial_max_stream_data_bidi_local,
initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni)
are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on
every stream of the corresponding type immediately after opening. If every stream of the corresponding type immediately after opening. If
the transport parameter is absent, streams of that type start with a the transport parameter is absent, streams of that type start with a
flow control limit of 0. flow control limit of 0.
A client MUST NOT include an original connection ID, a stateless A client MUST NOT include an original connection ID, a stateless
skipping to change at page 95, line 45 skipping to change at page 97, line 51
parameter (see Section 10). However, state in middleboxes might time parameter (see Section 10). However, state in middleboxes might time
out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 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.
19.3. ACK Frames 19.3. ACK Frames
Receivers send ACK frames (types 0x02 and 0x03) to inform senders of Receivers send ACK frames (types 0x02 and 0x03) to inform senders of
packets they have received and processed. The ACK frame contains one packets they have received and processed. The ACK frame contains one
or more ACK Blocks. ACK Blocks are ranges of acknowledged packets. or more ACK Ranges. ACK Ranges identify acknowledged packets. If
If the frame type is 0x03, ACK frames also contain the sum of QUIC the frame type is 0x03, ACK frames also contain the sum of QUIC
packets with associated ECN marks received on the connection up until packets with associated ECN marks received on the connection up until
this point. QUIC implementations MUST properly handle both types this point. QUIC implementations MUST properly handle both types
and, if they have enabled ECN for packets they send, they SHOULD use and, if they have enabled ECN for packets they send, they SHOULD use
the information in the ECN section to manage their congestion state. the information in the ECN section to manage their congestion state.
QUIC acknowledgements are irrevocable. Once acknowledged, a packet QUIC acknowledgements are irrevocable. Once acknowledged, a packet
remains acknowledged, even if it does not appear in a future ACK remains acknowledged, even if it does not appear in a future ACK
frame. This is unlike TCP SACKs ([RFC2018]). frame. This is unlike TCP SACKs ([RFC2018]).
It is expected that a sender will reuse the same packet number across It is expected that a sender will reuse the same packet number across
skipping to change at page 96, line 28 skipping to change at page 98, line 32
An ACK frame is as follows: An ACK 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Largest Acknowledged (i) ... | Largest Acknowledged (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Delay (i) ... | ACK Delay (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Block Count (i) ... | ACK Range Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Blocks (*) ... | First ACK Range (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ECN Section] ... | ACK Ranges (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ECN Counts] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: ACK Frame Format Figure 18: ACK Frame Format
ACK frames contain the following fields: ACK frames contain the following fields:
Largest Acknowledged: A variable-length integer representing the Largest Acknowledged: A variable-length integer representing the
largest packet number the peer is acknowledging; this is usually largest packet number the peer is acknowledging; this is usually
the largest packet number that the peer has received prior to the largest packet number that the peer has received prior to
generating the ACK frame. Unlike the packet number in the QUIC generating the ACK frame. Unlike the packet number in the QUIC
long or short header, the value in an ACK frame is not truncated. long or short header, the value in an ACK frame is not truncated.
ACK Delay: A variable-length integer including the time in ACK Delay: A variable-length integer including the time in
microseconds that the largest acknowledged packet, as indicated in microseconds that the largest acknowledged packet, as indicated in
the Largest Acknowledged field, was received by this peer to when the Largest Acknowledged field, was received by this peer to when
this ACK was sent. The value of the ACK Delay field is scaled by this ACK was sent. The value of the ACK Delay field is scaled by
multiplying the encoded value by 2 to the power of the value of multiplying the encoded value by 2 to the power of the value 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 the ACK frame. The "ack_delay_exponent" defaults to 3, or a
multiplier of 8 (see Section 18.1). Scaling in this fashion multiplier of 8 (see Section 18.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: A variable-length integer specifying the number of ACK Range Count: A variable-length integer specifying the number of
Additional ACK Block (and Gap) fields after the First ACK Block. Gap and ACK Range fields in the frame.
ACK Blocks: Contains one or more blocks of packet numbers which have First ACK Range: A variable-length integer indicating the number of
been successfully received, see Section 19.3.1. contiguous packets preceding the Largest Acknowledged that are
being acknowledged. The First ACK Range is encoded as an ACK
Range (see Section 19.3.1) starting from the Largest Acknowledged.
That is, the smallest packet acknowledged in the range is
determined by subtracting the First ACK Range value from the
Largest Acknowledged.
19.3.1. ACK Block Section ACK Ranges: Contains additional ranges of packets which are
alternately not acknowledged (Gap) and acknowledged (ACK Range),
see Section 19.3.1.
The ACK Block Section consists of alternating Gap and ACK Block ECN Counts: The three ECN Counts, see Section 19.3.2.
fields in descending packet number order. A First Ack Block field is
followed by a variable number of alternating Gap and Additional ACK
Blocks. The number of Gap and Additional ACK Block fields is
determined by the ACK Block Count field.
Gap and ACK Block fields use a relative integer encoding for 19.3.1. ACK Ranges
efficiency. Though each encoded value is positive, the values are
subtracted, so that each ACK Block describes progressively lower-
numbered packets. As long as contiguous ranges of packets are small,
the variable-length integer encoding ensures that each range can be
expressed in a small number of bytes.
The ACK frame uses the least significant bit (that is, type 0x03) to The ACK Ranges field consists of alternating Gap and ACK Range values
indicate ECN feedback and report receipt of QUIC packets with in descending packet number order. The number of Gap and ACK Range
associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP values is determined by the ACK Range Count field; one of each value
header. is present for each value in the ACK Range Count field.
ACK Ranges are structured 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First ACK Block (i) ... | [Gap (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional ACK Block (i) ... | [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap (i) ... | [Gap (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional ACK Block (i) ... | [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap (i) ... | [Gap (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional ACK Block (i) ... | [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: ACK Block Section Figure 19: ACK Ranges
Each ACK Block acknowledges a contiguous range of packets by The fields that form the ACK Ranges are:
Gap (repeated): A variable-length integer indicating the number of
contiguous unacknowledged packets preceding the packet number one
lower than the smallest in the preceding ACK Range.
ACK Range (repeated): A variable-length integer indicating the
number of contiguous acknowledged packets preceding the largest
packet number, as determined by the preceding Gap.
Gap and ACK Range value use a relative integer encoding for
efficiency. Though each encoded value is positive, the values are
subtracted, so that each ACK Range describes progressively lower-
numbered packets.
Each ACK Range acknowledges a contiguous range of packets by
indicating the number of acknowledged packets that precede the indicating the number of acknowledged packets that precede the
largest packet number in that block. A value of zero indicates that largest packet number in that range. A value of zero indicates that
only the largest packet number is acknowledged. Larger ACK Block only the largest packet number is acknowledged. Larger ACK Range
values indicate a larger range, with corresponding lower values for values indicate a larger range, with corresponding lower values for
the smallest packet number in the range. Thus, given a largest the smallest packet number in the range. Thus, given a largest
packet number for the ACK, the smallest value is determined by the packet number for the range, the smallest value is determined by the
formula: formula:
smallest = largest - ack_block smallest = largest - ack_range
The range of packets that are acknowledged by the ACK Block include An ACK Range acknowledges all packets between the smallest packet
the range from the smallest packet number to the largest, inclusive. number and the largest, inclusive.
The largest value for the First ACK Block is determined by the The largest value for an ACK Range is determined by cumulatively
Largest Acknowledged field; the largest for Additional ACK Blocks is subtracting the size of all preceding ACK Ranges and Gaps.
determined by cumulatively subtracting the size of all preceding ACK
Blocks and Gaps.
Each Gap indicates a range of packets that are not being Each Gap indicates a range of packets that are not being
acknowledged. The number of packets in the gap is one higher than acknowledged. The number of packets in the gap is one higher than
the encoded value of the Gap Field. the encoded value of the Gap field.
The value of the Gap field establishes the largest packet number The value of the Gap field establishes the largest packet number
value for the ACK Block that follows the gap using the following value for the subsequent ACK Range using the following formula:
formula:
largest = previous_smallest - gap - 2
If the calculated value for largest or smallest packet number for any
ACK Block is negative, an endpoint MUST generate a connection error
of type FRAME_ENCODING_ERROR indicating an error in an ACK frame.
The fields in the ACK Block Section are:
First ACK Block: A variable-length integer indicating the number of largest = previous_smallest - gap - 2
contiguous packets preceding the Largest Acknowledged that are
being acknowledged.
Gap (repeated): A variable-length integer indicating the number of If any computed packet number is negative, an endpoint MUST generate
contiguous unacknowledged packets preceding the packet number one a connection error of type FRAME_ENCODING_ERROR indicating an error
lower than the smallest in the preceding ACK Block. in an ACK frame.
Additional ACK Block (repeated): A variable-length integer 19.3.2. ECN Counts
indicating the number of contiguous acknowledged packets preceding
the largest packet number, as determined by the preceding Gap.
19.3.2. ECN section The ACK frame uses the least significant bit (that is, type 0x03) to
indicate ECN feedback and report receipt of QUIC packets with
associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP
header. ECN Counts are only present when the ACK frame type is 0x03.
The ECN section should only be parsed when the ACK frame type is ECN Counts are only parsed when the ACK frame type is 0x03. There
0x03. The ECN section consists of 3 ECN counts as shown below. are 3 ECN counts, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT(0) Count (i) ... | ECT(0) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT(1) Count (i) ... | ECT(1) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Count (i) ... | ECN-CE Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The three ECN Counts are:
ECT(0) Count: A variable-length integer representing the total ECT(0) Count: A variable-length integer representing the total
number packets received with the ECT(0) codepoint. number packets received with the ECT(0) codepoint.
ECT(1) Count: A variable-length integer representing the total ECT(1) Count: A variable-length integer representing the total
number packets received with the ECT(1) codepoint. number packets received with the ECT(1) codepoint.
CE Count: A variable-length integer representing the total number CE Count: A variable-length integer representing the total number
packets received with the CE codepoint. packets received with the CE codepoint.
ECN counts are maintained separately for each packet number space. ECN counts are maintained separately for each packet number space.
skipping to change at page 100, line 16 skipping to change at page 102, line 16
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly
terminate a stream. terminate a stream.
After sending a RESET_STREAM, an endpoint ceases transmission and After sending a RESET_STREAM, an endpoint ceases transmission and
retransmission of STREAM frames on the identified stream. A receiver retransmission of STREAM frames on the identified stream. A receiver
of RESET_STREAM can discard any data that it already received on that of RESET_STREAM can discard any data that it already received on that
stream. stream.
An endpoint that receives a RESET_STREAM frame for a send-only stream An endpoint that receives a RESET_STREAM frame for a send-only stream
MUST terminate the connection with error PROTOCOL_VIOLATION. MUST terminate the connection with error STREAM_STATE_ERROR.
The RESET_STREAM frame is as follows: The RESET_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 Size (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RESET_STREAM frames contain the following fields: RESET_STREAM frames contain the following fields:
Stream ID: A variable-length integer encoding of the Stream ID of Stream ID: A variable-length integer encoding of the Stream ID of
the stream being terminated. the stream being terminated.
Application Protocol Error Code: A 16-bit application protocol error Application Protocol Error Code: A 16-bit application protocol error
code (see Section 20.1) which indicates why the stream is being code (see Section 20.1) which indicates why the stream is being
closed. closed.
Final Offset: A variable-length integer indicating the absolute byte Final Size: A variable-length integer indicating the final size of
offset of the end of data written on this stream by the the stream by the RESET_STREAM sender, in unit of bytes.
RESET_STREAM sender.
19.5. STOP_SENDING Frame 19.5. STOP_SENDING Frame
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that
incoming data is being discarded on receipt at application request. incoming data is being discarded on receipt at application request.
This signals a peer to abruptly terminate transmission on a stream. STOP_SENDING requests that a peer cease transmission on a stream.
Receipt of a STOP_SENDING frame is invalid for a locally-initiated A STOP_SENDING frame can be sent for streams in the Recv or Size
stream that has not yet been created or is in the "Ready" state (see Known states (see Section 3.1). Receiving a STOP_SENDING frame for a
Section 3.1). Receiving a STOP_SENDING frame for a locally-initiated locally-initiated stream that has not yet been created MUST be
send stream that is "Ready" or not yet created MUST be treated as a treated as a connection error of type STREAM_STATE_ERROR. An
connection error of type PROTOCOL_VIOLATION. An endpoint that endpoint that receives a STOP_SENDING frame for a receive-only stream
receives a STOP_SENDING frame for a receive-only stream MUST MUST terminate the connection with error STREAM_STATE_ERROR.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 101, line 48 skipping to change at page 103, line 47
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset (i) ... | Offset (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ... | Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto Data (*) ... | Crypto Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: CRYPTO Frame Format Figure 20: CRYPTO Frame Format
CRYPTO frames contain the following fields: CRYPTO frames contain the following fields:
Offset: A variable-length integer specifying the byte offset in the Offset: A variable-length integer specifying the byte offset in the
stream for the data in this CRYPTO frame. stream for the data in this CRYPTO frame.
Length: A variable-length integer specifying the length of the Length: A variable-length integer specifying the length of the
Crypto Data field in this CRYPTO frame. Crypto Data field in this CRYPTO frame.
Crypto Data: The cryptographic message data. Crypto Data: The cryptographic message data.
skipping to change at page 102, line 25 skipping to change at page 104, line 25
implies that each encryption level is treated as a separate CRYPTO implies that each encryption level is treated as a separate CRYPTO
stream of data. stream of data.
Unlike STREAM frames, which include a Stream ID indicating to which Unlike STREAM frames, which include a Stream ID indicating to which
stream the data belongs, the CRYPTO frame carries data for a single stream the data belongs, the CRYPTO frame carries data for a single
stream per encryption level. The stream does not have an explicit stream per encryption level. The stream does not have an explicit
end, so CRYPTO frames do not have a FIN bit. end, so CRYPTO frames do not have a FIN bit.
19.7. NEW_TOKEN Frame 19.7. NEW_TOKEN Frame
A server sends a NEW_TOKEN frame (type=0x07) to provide the client a A server sends a NEW_TOKEN frame (type=0x07) to provide the client
token to send in the header of an Initial packet for a future with a token to send in the header of an Initial packet for a future
connection. connection.
The NEW_TOKEN frame is as follows: The NEW_TOKEN 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Length (i) ... | Token Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ... | Token (*) ...
skipping to change at page 103, line 18 skipping to change at page 105, line 18
Data starts at an offset of 0 (that is, the frame contains the Data starts at an offset of 0 (that is, the frame contains the
first bytes of the stream, or the end of a stream that includes no first bytes of the stream, or the end of a stream that includes no
data). data).
o The LEN bit (0x02) in the frame type is set to indicate that there 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 size of the stream. Setting this bit indicates
indicates that the frame marks the end of the stream. that the frame marks the end of the stream.
An endpoint that receives a STREAM frame for a send-only stream MUST An endpoint that receives a STREAM frame for a send-only stream MUST
terminate the connection with error PROTOCOL_VIOLATION. terminate the connection with error STREAM_STATE_ERROR.
The STREAM frames are as follows: The STREAM frames are 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)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Length (i)] ... | [Length (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Data (*) ... | Stream Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: STREAM Frame Format Figure 21: STREAM Frame Format
STREAM frames contain the following fields: STREAM frames contain the following fields:
Stream ID: A variable-length integer indicating the stream ID of the Stream ID: A variable-length integer indicating the stream ID of the
stream (see Section 2.1). stream (see Section 2.1).
Offset: A variable-length integer specifying the byte offset in the Offset: A variable-length integer specifying the byte offset in the
stream for the data in this STREAM frame. This field is present stream for the data in this STREAM frame. This field is present
when the OFF bit is set to 1. When the Offset field is absent, when the OFF bit is set to 1. When the Offset field is absent,
the offset is 0. the offset is 0.
skipping to change at page 104, line 13 skipping to change at page 106, line 13
Stream Data field in this STREAM frame. This field is present Stream Data field in this STREAM frame. This field is present
when the LEN bit is set to 1. When the LEN bit is set to 0, the when the LEN bit is set to 1. When the LEN bit is set to 0, the
Stream Data field consumes all the remaining bytes in the packet. Stream Data field consumes all the remaining bytes in the packet.
Stream Data: The bytes from the designated stream to be delivered. Stream Data: The bytes from the designated stream to be delivered.
When a Stream Data field has a length of 0, the offset in the STREAM When a Stream Data field has a length of 0, the offset in the STREAM
frame is the offset of the next byte that would be sent. frame is the offset of the next byte that would be sent.
The first byte in the stream has an offset of 0. The largest offset The first byte in the stream has an offset of 0. The largest offset
delivered on a stream - the sum of the re-constructed offset and data delivered on a stream - the sum of the offset and data length - MUST
length - MUST be less than 2^62. be less than 2^62.
19.9. MAX_DATA Frame 19.9. MAX_DATA Frame
The MAX_DATA frame (type=0x10) is used in flow control to inform the The MAX_DATA frame (type=0x10) is used in flow control to inform the
peer of the maximum amount of data that can be sent on the connection peer of the maximum amount of data that can be sent on the connection
as a whole. as a whole.
The MAX_DATA frame is as follows: The MAX_DATA frame is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 104, line 50 skipping to change at page 106, line 50
error if it receives more data than the maximum data value that it error if it receives more data than the maximum data value that it
has sent, unless this is a result of a change in the initial limits has sent, unless this is a result of a change in the initial limits
(see Section 7.3.1). (see Section 7.3.1).
19.10. MAX_STREAM_DATA Frame 19.10. MAX_STREAM_DATA Frame
The MAX_STREAM_DATA frame (type=0x11) is used in flow control to The MAX_STREAM_DATA frame (type=0x11) is used in flow control to
inform a peer of the maximum amount of data that can be sent on a 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 A MAX_STREAM_DATA frame can be sent for streams in the Recv state
stream MUST terminate the connection with error PROTOCOL_VIOLATION. (see Section 3.1). Receiving a MAX_STREAM_DATA frame for a locally-
initiated stream that has not yet been created MUST be treated as a
An endpoint that receives a MAX_STREAM_DATA frame for a send-only connection error of type STREAM_STATE_ERROR. An endpoint that
stream it has not opened MUST terminate the connection with error receives a MAX_STREAM_DATA frame for a receive-only stream MUST
PROTOCOL_VIOLATION. terminate the connection with error STREAM_STATE_ERROR.
Note that an endpoint may legally receive a MAX_STREAM_DATA frame on
a bidirectional stream it has not opened.
The MAX_STREAM_DATA frame is as follows: The MAX_STREAM_DATA 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 107, line 15 skipping to change at page 109, line 12
Data Limit: A variable-length integer indicating the connection- Data Limit: A variable-length integer indicating the connection-
level limit at which blocking occurred. level limit at which blocking occurred.
19.13. STREAM_DATA_BLOCKED Frame 19.13. STREAM_DATA_BLOCKED Frame
A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
wishes to send data, but is unable to due to stream-level flow wishes to send data, but is unable to due to stream-level flow
control. This frame is analogous to DATA_BLOCKED (Section 19.12). control. This frame is analogous to DATA_BLOCKED (Section 19.12).
An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only
stream MUST terminate the connection with error PROTOCOL_VIOLATION. stream MUST terminate the connection with error STREAM_STATE_ERROR.
The STREAM_DATA_BLOCKED frame is as follows: The STREAM_DATA_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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Data Limit (i) ... | Stream Data Limit (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 110, line 29 skipping to change at page 112, line 26
Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check
reachability to the peer and for path validation during connection reachability to the peer and for path validation during connection
migration. migration.
The PATH_CHALLENGE frames are as follows: The PATH_CHALLENGE frames are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Data (8) + + Data (64) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PATH_CHALLENGE frames contain the following fields: PATH_CHALLENGE frames contain the following fields:
Data: This 8-byte field contains arbitrary data. Data: This 8-byte field contains arbitrary data.
A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is
sufficient to ensure that it is easier to receive the packet than it sufficient to ensure that it is easier to receive the packet than it
is to guess the value correctly. is to guess the value correctly.
skipping to change at page 111, line 44 skipping to change at page 113, line 44
CONNECTION_CLOSE frame of type 0x1d uses codes from the CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space, see Section 20.1 application protocol error code space, see Section 20.1
Frame Type: A variable-length integer encoding the type of frame Frame Type: A variable-length integer encoding the type of frame
that triggered the error. A value of 0 (equivalent to the mention that triggered the error. A value of 0 (equivalent to the mention
of the PADDING frame) is used when the frame type is unknown. The of the PADDING frame) is used when the frame type is unknown. The
application-specific variant of CONNECTION_CLOSE (type 0x1d) does application-specific variant of CONNECTION_CLOSE (type 0x1d) does
not include this field. not include this field.
Reason Phrase Length: A variable-length integer specifying the Reason Phrase Length: A variable-length integer specifying the
length of the reason phrase in bytes. Note that a length of the reason phrase in bytes. Because a CONNECTION_CLOSE
CONNECTION_CLOSE frame cannot be split between packets, so in frame cannot be split between packets, any limits on packet size
practice any limits on packet size will also limit the space will also limit the space available for a reason phrase.
available for a reason phrase.
Reason Phrase: A human-readable explanation for why the connection Reason Phrase: A human-readable explanation for why the connection
was closed. This can be zero length if the sender chooses to not was closed. This can be zero length if the sender chooses to not
give details beyond the Error Code. This SHOULD be a UTF-8 give details beyond the Error Code. This SHOULD be a UTF-8
encoded string [RFC3629]. encoded string [RFC3629].
19.20. Extension Frames 19.20. Extension Frames
QUIC frames do not use a self-describing encoding. An endpoint QUIC frames do not use a self-describing encoding. An endpoint
therefore needs to understand the syntax of all frames before it can therefore needs to understand the syntax of all frames before it can
skipping to change at page 113, line 8 skipping to change at page 115, line 8
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 4). permitted in its advertised data limits (see Section 4).
STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream
identifier that exceeded its advertised stream limit for the identifier that exceeded its advertised stream limit for the
corresponding stream type. corresponding stream type.
STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream
that was not in a state that permitted that frame (see Section 3). that was not in a state that permitted that frame (see Section 3).
FINAL_OFFSET_ERROR (0x6): An endpoint received a STREAM frame FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame
containing data that exceeded the previously established final containing data that exceeded the previously established final
offset. Or an endpoint received a RESET_STREAM frame containing a size. Or an endpoint received a STREAM frame or a RESET_STREAM
final offset that was lower than the maximum offset of data that frame containing a final size that was lower than the size of
was already received. Or an endpoint received a RESET_STREAM stream data that was already received. Or an endpoint received a
frame containing a different final offset to the one already STREAM frame or a RESET_STREAM frame containing a different final
established. size to the one already established.
FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was
badly formatted. For instance, a frame of an unknown type, or an badly formatted. For instance, a frame of an unknown type, or an
ACK frame that has more acknowledgment ranges than the remainder ACK frame that has more acknowledgment ranges than the remainder
of the packet could carry. of the packet could carry.
TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport
parameters that were badly formatted, included an invalid value, parameters that were badly formatted, included an invalid value,
was absent even though it is mandatory, was present though it is was absent even though it is mandatory, was present though it is
forbidden, or is otherwise in error. forbidden, or is otherwise in error.
skipping to change at page 122, line 27 skipping to change at page 124, line 27
| 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 | | 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 |
| | | streams opened | | | | | streams opened | |
| | | | | | | | | |
| 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 |
| | | in invalid | | | | | in invalid | |
| | | stream state | | | | | stream state | |
| | | | | | | | | |
| 0x6 | FINAL_OFFSET_ERROR | Change to | Section 20 | | 0x6 | FINAL_SIZE_ERROR | Change to | Section 20 |
| | | final stream | | | | | final size | |
| | | offset | |
| | | | | | | | | |
| 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 |
| | | transport | | | | | transport | |
| | | parameters | | | | | parameters | |
| | | | | | | | | |
| 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 20 | | 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 20 |
| | | negotiation | | | | | negotiation | |
skipping to change at page 123, line 17 skipping to change at page 125, line 17
23.1. Normative References 23.1. Normative References
[DPLPMTUD] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler, Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler,
"Packetization Layer Path MTU Discovery for Datagram "Packetization Layer Path MTU Discovery for Datagram
Transports", draft-ietf-tsvwg-datagram-plpmtud-06 (work in Transports", draft-ietf-tsvwg-datagram-plpmtud-06 (work in
progress), November 2018. progress), November 2018.
[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-17 (work and Congestion Control", draft-ietf-quic-recovery-18 (work
in progress), December 2018. in progress), January 2019.
[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-17 (work in progress), December 2018. tls-18 (work in progress), January 2019.
[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 123, line 48 skipping to change at page 125, line 48
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5119] Edwards, T., "A Uniform Resource Name (URN) Namespace for [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
the Society of Motion Picture and Television Engineers Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
(SMPTE)", RFC 5119, DOI 10.17487/RFC5119, February 2008, <https://www.rfc-editor.org/info/rfc5116>.
<https://www.rfc-editor.org/info/rfc5119>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
skipping to change at page 124, line 49 skipping to change at page 126, line 49
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] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-03 (work in progress), December draft-ietf-quic-invariants-03 (work in progress), January
2018. 2019.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
skipping to change at page 126, line 47 skipping to change at page 128, line 47
return candidate_pn - pn_win return candidate_pn - pn_win
return candidate_pn return candidate_pn
Appendix B. Change Log Appendix B. 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.
B.1. Since draft-ietf-quic-transport-16 B.1. Since draft-ietf-quic-transport-17
o Stream-related errors now use STREAM_STATE_ERROR (#2305)
o Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045)
o Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161)
o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
#2241)
o Endpoints are permitted to discard malformed initial packets
(#2141)
o Clarified ECN implementation and usage requirements (#2156, #2201)
o Disable ECN count verification for packets that arrive out of
order (#2198, #2215)
o Use Probe Timeout (PTO) instead of RTO (#2206, #2238)
o Loosen constraints on retransmission of ACK ranges (#2199, #2245)
o Limit Retry and Version Negotiation to once per datagram (#2259,
#2303)
o Set a maximum value for max_ack_delay transport parameter (#2282,
#2301)
o Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296)
o Corrected requirements for migration to a preferred address
(#2146, #2349)
B.2. Since draft-ietf-quic-transport-16
o Stream limits are defined as counts, not maximums (#1850, #1906) o Stream limits are defined as counts, not maximums (#1850, #1906)
o Require amplification attack defense after closing (#1905, #1911) o Require amplification attack defense after closing (#1905, #1911)
o Remove reservation of application error code 0 for STOPPING o Remove reservation of application error code 0 for STOPPING
(#1804, #1922) (#1804, #1922)
o Renumbered frames (#1945) o Renumbered frames (#1945)
o Renumbered transport parameters (#1946) o Renumbered transport parameters (#1946)
o Numeric transport parameters are expressed as varints (#1608, o Numeric transport parameters are expressed as varints (#1608,
#1947, #1955) #1947, #1955)
skipping to change at page 127, line 15 skipping to change at page 130, line 4
(#1804, #1922) (#1804, #1922)
o Renumbered frames (#1945) o Renumbered frames (#1945)
o Renumbered transport parameters (#1946) o Renumbered transport parameters (#1946)
o Numeric transport parameters are expressed as varints (#1608, o Numeric transport parameters are expressed as varints (#1608,
#1947, #1955) #1947, #1955)
o Reorder the NEW_CONNECTION_ID frame (#1952, #1963) o Reorder the NEW_CONNECTION_ID frame (#1952, #1963)
o Rework the first byte (#2006) o Rework the first byte (#2006)
* Fix the 0x40 bit * Fix the 0x40 bit
* Change type values for long header * Change type values for long header
* Add spin bit to short header (#631, #1988) * Add spin bit to short header (#631, #1988)
* Encrypt the remainder of the first byte (#1322) * Encrypt the remainder of the first byte (#1322)
* Move packet number length to first byte * Move packet number length to first byte
* Move ODCIL to first byte of retry packets
* Simplify packet number protection (#1575) * Simplify packet number protection (#1575)
o Allow STOP_SENDING to open a remote bidirectional stream (#1797, o Allow STOP_SENDING to open a remote bidirectional stream (#1797,
#2013) #2013)
o Added mitigation for off-path migration attacks (#1278, #1749, o Added mitigation for off-path migration attacks (#1278, #1749,
#2033) #2033)
o Don't let the PMTU to drop below 1280 (#2063, #2069) o Don't let the PMTU to drop below 1280 (#2063, #2069)
o Require peers to replace retired connection IDs (#2085) o Require peers to replace retired connection IDs (#2085)
o Servers are required to ignore Version Negotiation packets (#2088) o Servers are required to ignore Version Negotiation packets (#2088)
o Tokens are repeated in all Initial packets (#2089) o Tokens are repeated in all Initial packets (#2089)
o Clarified how PING frames are sent after loss (#2094) o Clarified how PING frames are sent after loss (#2094)
o Initial keys are discarded once Handshake are avaialble (#1951, o Initial keys are discarded once Handshake are available (#1951,
#2045) #2045)
o ICMP PTB validation clarifications (#2161, #2109, #2108) o ICMP PTB validation clarifications (#2161, #2109, #2108)
B.2. Since draft-ietf-quic-transport-15 B.3. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.3. Since draft-ietf-quic-transport-14 B.4. Since draft-ietf-quic-transport-14
o Merge ACK and ACK_ECN (#1778, #1801) o Merge ACK and ACK_ECN (#1778, #1801)
o Explicitly communicate max_ack_delay (#981, #1781) o Explicitly communicate max_ack_delay (#981, #1781)
o Validate original connection ID after Retry packets (#1710, #1486, o Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
o Idle timeout is optional and has no specified maximum (#1765) o Idle timeout is optional and has no specified maximum (#1765)
o Update connection ID handling; add RETIRE_CONNECTION_ID type o Update connection ID handling; add RETIRE_CONNECTION_ID type
(#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
#1821) #1821)
o Include a Token in all Initial packets (#1649, #1794) o Include a Token in all Initial packets (#1649, #1794)
o Prevent handshake deadlock (#1764, #1824) o Prevent handshake deadlock (#1764, #1824)
B.4. Since draft-ietf-quic-transport-13 B.5. Since draft-ietf-quic-transport-13
o Streams open when higher-numbered streams of the same type open o Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
o Split initial stream flow control limit into 3 transport o Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
o All flow control transport parameters are optional (#1610) o All flow control transport parameters are optional (#1610)
o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
skipping to change at page 129, line 4 skipping to change at page 131, line 41
o Recommended defense against stateless reset spoofing (#1386, o Recommended defense against stateless reset spoofing (#1386,
#1554) #1554)
o Prevent infinite stateless reset exchanges (#1443, #1627) o Prevent infinite stateless reset exchanges (#1443, #1627)
o Forbid processing of the same packet number twice (#1405, #1624) o Forbid processing of the same packet number twice (#1405, #1624)
o Added a packet number decoding example (#1493) o Added a packet number decoding example (#1493)
o More precisely define idle timeout (#1429, #1614, #1652) o More precisely define idle timeout (#1429, #1614, #1652)
o Corrected format of Retry packet and prevented looping (#1492, o Corrected format of Retry packet and prevented looping (#1492,
#1451, #1448, #1498) #1451, #1448, #1498)
o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, o Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
o Permit Retry in response to 0-RTT (#1547, #1552) o Permit Retry in response to 0-RTT (#1547, #1552)
o Looser verification of ECN counters to account for ACK loss o Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) o Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
B.5. Since draft-ietf-quic-transport-12 B.6. Since draft-ietf-quic-transport-12
o Changes to integration of the TLS handshake (#829, #1018, #1094, o Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450, #1458) #1165, #1190, #1233, #1242, #1252, #1450, #1458)
* The cryptographic handshake uses CRYPTO frames, not stream 0 * The cryptographic handshake uses CRYPTO frames, not stream 0
* QUIC packet protection is used in place of TLS record * QUIC packet protection is used in place of TLS record
protection protection
* Separate QUIC packet number spaces are used for the handshake * Separate QUIC packet number spaces are used for the handshake
skipping to change at page 130, line 14 skipping to change at page 133, line 5
o Fixed sampling method for packet number encryption; the length o Fixed sampling method for packet number encryption; the length
field in long headers includes the packet number field in addition field in long headers includes the packet number field in addition
to the packet payload (#1387, #1389) to the packet payload (#1387, #1389)
o Stateless Reset is now symmetric and subject to size constraints o Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
o Added frame type extension mechanism (#58, #1473) o Added frame type extension mechanism (#58, #1473)
B.6. Since draft-ietf-quic-transport-11 B.7. Since draft-ietf-quic-transport-11
o Enable server to transition connections to a preferred address o Enable server to transition connections to a preferred address
(#560, #1251) (#560, #1251)
o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079) #990, #734, #1317, #1267, #1079)
o Packet numbers use a variable-length encoding (#989, #1334) o Packet numbers use a variable-length encoding (#989, #1334)
o STREAM frames can now be empty (#1350) o STREAM frames can now be empty (#1350)
B.7. Since draft-ietf-quic-transport-10 B.8. Since draft-ietf-quic-transport-10
o Swap payload length and packed number fields in long header o Swap payload length and packed number fields in long header
(#1294) (#1294)
o Clarified that CONNECTION_CLOSE is allowed in Handshake packet o Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
o Spin bit reserved (#1283) o Spin bit reserved (#1283)
o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 131, line 4 skipping to change at page 133, line 44
o Removed implicit stream opening (#896, #1193) o Removed implicit stream opening (#896, #1193)
o An empty STREAM frame can be used to open a stream without sending o An empty STREAM frame can be used to open a stream without sending
data (#901, #1194) data (#901, #1194)
o Define stream counts in transport parameters rather than a maximum o Define stream counts in transport parameters rather than a maximum
stream ID (#1023, #1065) stream ID (#1023, #1065)
o STOP_SENDING is now prohibited before streams are used (#1050) o STOP_SENDING is now prohibited before streams are used (#1050)
o Recommend including ACK in Retry packets and allow PADDING (#1067, o Recommend including ACK in Retry packets and allow PADDING (#1067,
#882) #882)
o Endpoints now become closing after an idle timeout (#1178, #1179) o Endpoints now become closing after an idle timeout (#1178, #1179)
o Remove implication that Version Negotiation is sent when a packet o Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197) of the wrong version is received (#1197)
B.8. Since draft-ietf-quic-transport-09 B.9. Since draft-ietf-quic-transport-09
o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d.
(#1091, #725, #1086) (#1091, #725, #1086)
o A server can now only send 3 packets without validating the client o A server can now only send 3 packets without validating the client
address (#38, #1090) address (#38, #1090)
o Delivery order of stream data is no longer strongly specified o Delivery order of stream data is no longer strongly specified
(#252, #1070) (#252, #1070)
skipping to change at page 131, line 39 skipping to change at page 134, line 32
o Improved retransmission rules for all frame types: information is o Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053) retransmitted, not packets or frames (#463, #765, #1095, #1053)
o Added an error code for server busy signals (#1137) o Added an error code for server busy signals (#1137)
o Endpoints now set the connection ID that their peer uses. o Endpoints now set the connection ID that their peer uses.
Connection IDs are variable length. Removed the Connection IDs are variable length. Removed the
omit_connection_id transport parameter and the corresponding short omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
B.9. Since draft-ietf-quic-transport-08 B.10. 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 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)
skipping to change at page 132, line 4 skipping to change at page 134, line 44
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 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, #743, #894) o Clarified stream state machine (#634, #662, #743, #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)
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)
B.10. Since draft-ietf-quic-transport-07 B.11. 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)
skipping to change at page 133, line 15 skipping to change at page 136, line 8
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)
B.11. Since draft-ietf-quic-transport-06 B.12. 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)
B.12. Since draft-ietf-quic-transport-05 B.13. 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)
B.13. Since draft-ietf-quic-transport-04 B.14. Since draft-ietf-quic-transport-04
o Introduce STOP_SENDING frame, RESET_STREAM only resets in one o Introduce STOP_SENDING frame, RESET_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 134, line 34 skipping to change at page 137, line 26
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)
B.14. Since draft-ietf-quic-transport-03 B.15. Since draft-ietf-quic-transport-03
o Change STREAM and RESET_STREAM layout o Change STREAM and RESET_STREAM layout
o Add MAX_STREAM_ID settings o Add MAX_STREAM_ID settings
B.15. Since draft-ietf-quic-transport-02 B.16. 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 135, line 37 skipping to change at page 138, line 30
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)
B.16. Since draft-ietf-quic-transport-01 B.17. 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 137, line 36 skipping to change at page 140, line 28
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 RESET_STREAM and CONNECTION_CLOSE are now at a o Error codes for RESET_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)
B.17. Since draft-ietf-quic-transport-00 B.18. 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
B.18. Since draft-hamilton-quic-transport-protocol-01 B.19. 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
Acknowledgments Acknowledgments
Special thanks are due to the following for helping shape pre-IETF Special thanks are due to the following for helping shape pre-IETF
QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon,
Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund.
skipping to change at page 138, line 42 skipping to change at page 141, line 39
Authors' Addresses Authors' Addresses
Jana Iyengar (editor) Jana Iyengar (editor)
Fastly Fastly
Email: jri.ietf@gmail.com Email: jri.ietf@gmail.com
Martin Thomson (editor) Martin Thomson (editor)
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: mt@lowentropy.net
 End of changes. 273 change blocks. 
748 lines changed or deleted 895 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/