draft-ietf-quic-transport-23.txt   draft-ietf-quic-transport-24.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: March 15, 2020 Mozilla Expires: May 7, 2020 Mozilla
September 12, 2019 November 04, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-23 draft-ietf-quic-transport-24
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 and the use of TLS for key negotiation. control and the use of TLS for key negotiation.
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
skipping to change at page 1, line 43 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 March 15, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 32 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 32
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 33 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 33
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 34 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 34
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 36 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 36
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 36 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 36
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 38 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 38
7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 38 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 38
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 38 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 38
8.1. Address Validation During Connection Establishment . . . 39 8.1. Address Validation During Connection Establishment . . . 39
8.1.1. Address Validation using Retry Packets . . . . . . . 40 8.1.1. Address Validation using Retry Packets . . . . . . . 40
8.1.2. Address Validation for Future Connections . . . . . . 40 8.1.2. Address Validation for Future Connections . . . . . . 41
8.1.3. Address Validation Token Integrity . . . . . . . . . 43 8.1.3. Address Validation Token Integrity . . . . . . . . . 43
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 43 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 43
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 44 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 44
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 44 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 44
8.5. Successful Path Validation . . . . . . . . . . . . . . . 44 8.5. Successful Path Validation . . . . . . . . . . . . . . . 44
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 45 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 45
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 45 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 45
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 46 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 46
9.2. Initiating Connection Migration . . . . . . . . . . . . . 47 9.2. Initiating Connection Migration . . . . . . . . . . . . . 47
9.3. Responding to Connection Migration . . . . . . . . . . . 47 9.3. Responding to Connection Migration . . . . . . . . . . . 47
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 48 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 48
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 48 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 48
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 49 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 49
9.4. Loss Detection and Congestion Control . . . . . . . . . . 50 9.4. Loss Detection and Congestion Control . . . . . . . . . . 50
9.5. Privacy Implications of Connection Migration . . . . . . 51 9.5. Privacy Implications of Connection Migration . . . . . . 51
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 52 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 52
9.6.1. Communicating a Preferred Address . . . . . . . . . . 52 9.6.1. Communicating a Preferred Address . . . . . . . . . . 52
9.6.2. Responding to Connection Migration . . . . . . . . . 52 9.6.2. Responding to Connection Migration . . . . . . . . . 53
9.6.3. Interaction of Client Migration and Preferred Address 53 9.6.3. Interaction of Client Migration and Preferred Address 53
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 53 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 54
10. Connection Termination . . . . . . . . . . . . . . . . . . . 54 10. Connection Termination . . . . . . . . . . . . . . . . . . . 54
10.1. Closing and Draining Connection States . . . . . . . . . 54 10.1. Closing and Draining Connection States . . . . . . . . . 54
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 55 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 56
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 56 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 56
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 57 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 58
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 60 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 60
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 61 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 61
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 62 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 62
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 62 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 63
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 63 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 63
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 64 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 64
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 64 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 64
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 64 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 65
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 65 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 65
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 66 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 66
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 67 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 68
13. Packetization and Reliability . . . . . . . . . . . . . . . . 70 13. Packetization and Reliability . . . . . . . . . . . . . . . . 70
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 71 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 71
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 71 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 71
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 71 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 71
13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 73 13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 73
13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 73 13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 73
13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 73 13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 73
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 74 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 74
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 74 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 74
13.3. Retransmission of Information . . . . . . . . . . . . . 75 13.3. Retransmission of Information . . . . . . . . . . . . . 74
13.4. Explicit Congestion Notification . . . . . . . . . . . . 77 13.4. Explicit Congestion Notification . . . . . . . . . . . . 77
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 77 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 77
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 78 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 78
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 80 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 80
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 81 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 80
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 82 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 81
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 83 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 82
14.3.1. PMTU Probes Containing Source Connection ID . . . . 83 14.3.1. PMTU Probes Containing Source Connection ID . . . . 83
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 83 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 83
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 84 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 84
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 85 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 85
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 85 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 85
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 86 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 86
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 89 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 89
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 91 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 90
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 93 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 92
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 95 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 94
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 96 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 95
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 98 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 98
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 100 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 99
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 101 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 100
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 102 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 101
18.2. Transport Parameter Definitions . . . . . . . . . . . . 102 18.2. Transport Parameter Definitions . . . . . . . . . . . . 101
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 106 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 106
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 106 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 106
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 106 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 106
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 106 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 107
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 108 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 108
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 110 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 110
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 111 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 111
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 111 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 111
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 112 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 112
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 113 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 113
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 114 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 114
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 115 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 115
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 116 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 116
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 117 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 117
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 118 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 118
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 118 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 118
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 119 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 119
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 119 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 120
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 121 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 121
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 122 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 122
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 123 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 123
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 123 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 123
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 124 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 124
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 124 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 124
20.1. Application Protocol Error Codes . . . . . . . . . . . . 126 20.1. Application Protocol Error Codes . . . . . . . . . . . . 126
21. Security Considerations . . . . . . . . . . . . . . . . . . . 126 21. Security Considerations . . . . . . . . . . . . . . . . . . . 126
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 126 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 126
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 127 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 127
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 127 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 127
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 128 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 128
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 128 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 128
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 128 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 129
21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 129 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 129
21.8. Explicit Congestion Notification Attacks . . . . . . . . 129 21.8. Explicit Congestion Notification Attacks . . . . . . . . 130
21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 130 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 130
21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 130 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 130
21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 130 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 131
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 131 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 131
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 132 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 132
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 133 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 133
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 135
23.1. Normative References . . . . . . . . . . . . . . . . . . 136 23.1. Normative References . . . . . . . . . . . . . . . . . . 136
23.2. Informative References . . . . . . . . . . . . . . . . . 137 23.2. Informative References . . . . . . . . . . . . . . . . . 137
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 139 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 139
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 140 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 140
B.1. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 140 B.1. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 140
B.2. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 141 B.2. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 140
B.3. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 141 B.3. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 142
B.4. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 142 B.4. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 142
B.5. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 142 B.5. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 143
B.6. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 143 B.6. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 143
B.7. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 144 B.7. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 144
B.8. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 145 B.8. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 144
B.9. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 145 B.9. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 146
B.10. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 145 B.10. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 146
B.11. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 146 B.11. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 146
B.12. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 147 B.12. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 147
B.13. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 147 B.13. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 148
B.14. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 148 B.14. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 148
B.15. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 148 B.15. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 149
B.16. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 149 B.16. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 149
B.17. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 150 B.17. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 150
B.18. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 150 B.18. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 151
B.19. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 151 B.19. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 151
B.20. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 151 B.20. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 151
B.21. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 152 B.21. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 152
B.22. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 153 B.22. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 152
B.23. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 155 B.23. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 153
B.24. Since draft-hamilton-quic-transport-protocol-01 . . . . . 155 B.24. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 155
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 155 B.25. Since draft-hamilton-quic-transport-protocol-01 . . . . . 155
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 156
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 156
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 8, line 22 skipping to change at page 8, line 22
Commonly used terms in the document are described below. Commonly used terms in the document are described below.
QUIC: The transport protocol described by this document. QUIC is a QUIC: The transport protocol described by this document. QUIC is a
name, not an acronym. name, not an acronym.
QUIC packet: A complete processable unit of QUIC that can be QUIC packet: A complete processable unit of QUIC that can be
encapsulated in a UDP datagram. Multiple QUIC packets can be encapsulated in a UDP datagram. Multiple QUIC packets can be
encapsulated in a single UDP datagram. encapsulated in a single UDP datagram.
Ack-eliciting Packet: A QUIC packet that contains frames other than
ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to
send an acknowledgment (see Section 13.2.1).
Endpoint: An entity that can participate in a QUIC connection by Endpoint: An entity that can participate in a QUIC connection by
generating, receiving, and processing QUIC packets. There are generating, receiving, and processing QUIC packets. There are
only two types of endpoint in QUIC: client and server. only two types of endpoint in QUIC: client and server.
Client: The endpoint initiating a QUIC connection. Client: The endpoint initiating a QUIC connection.
Server: The endpoint accepting incoming QUIC connections. Server: The endpoint accepting incoming QUIC connections.
Connection ID: An opaque identifier that is used to identify a QUIC Connection ID: An opaque identifier that is used to identify a QUIC
connection at an endpoint. Each endpoint sets a value for its connection at an endpoint. Each endpoint sets a value for its
skipping to change at page 11, line 44 skipping to change at page 11, line 44
perform when interacting with QUIC streams. This document does not perform when interacting with QUIC streams. This document does not
specify an API, but any implementation of this version of QUIC MUST specify an API, but any implementation of this version of QUIC MUST
expose the ability to perform the operations described in this expose the ability to perform the operations described in this
section on a QUIC stream. section on a QUIC stream.
On the sending part of a stream, application protocols need to be On the sending part of a stream, application protocols need to be
able to: able to:
o write data, understanding when stream flow control credit o write data, understanding when stream flow control credit
(Section 4.1) has successfully been reserved to send the written (Section 4.1) has successfully been reserved to send the written
data data;
o end the stream (clean termination), resulting in a STREAM frame o end the stream (clean termination), resulting in a STREAM frame
(Section 19.8) with the FIN bit set; and (Section 19.8) with the FIN bit set; and
o reset the stream (abrupt termination), resulting in a RESET_STREAM o reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (Section 19.4), even if the stream was already ended. frame (Section 19.4), if the stream was not already in a terminal
state.
On the receiving part of a stream, application protocols need to be On the receiving part of a stream, application protocols need to be
able to: able to:
o read data o read data; and
o abort reading of the stream and request closure, possibly o abort reading of the stream and request closure, possibly
resulting in a STOP_SENDING frame (Section 19.5) resulting in a STOP_SENDING frame (Section 19.5).
Applications also need to be informed of state changes on streams, Applications also need to be informed of state changes on streams,
including when the peer has opened or reset a stream, when a peer including when the peer has opened or reset a stream, when a peer
aborts reading on a stream, when new data is available, and when data aborts reading on a stream, when new data is available, and when data
can or cannot be written to the stream due to flow control. can or cannot be written to the stream due to flow control.
3. Stream States 3. Stream States
This section describes streams in terms of their send or receive This section describes streams in terms of their send or receive
components. Two state machines are described: one for the streams on components. Two state machines are described: one for the streams on
skipping to change at page 25, line 29 skipping to change at page 25, line 29
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.2.1) packet echoes the connection A Version Negotiation (Section 17.2.1) packet echoes the connection
IDs 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 can be used when a connection ID is not
needed for routing and the address/port tuple of packets is needed to route to the correct endpoint. However, multiplexing
sufficient to identify a connection. An endpoint whose peer has connections on the same local IP address and port while using zero-
selected a zero-length connection ID MUST continue to use a zero- length connection IDs will cause failures in the presence of peer
length connection ID for the lifetime of the connection and MUST NOT connection migration, NAT rebinding, and client port reuse; and
send packets from any other local address. therefore MUST NOT be done unless an endpoint is certain that those
protocol features are not in use.
When an endpoint has requested a non-zero-length connection ID, it When an endpoint has requested a non-zero-length connection ID, it
needs to ensure that the peer has a supply of connection IDs from needs to ensure that the peer has a supply of connection IDs from
which to choose for packets sent to the endpoint. These connection which to choose for packets sent to the endpoint. These connection
IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame
(Section 19.15). (Section 19.15).
5.1.1. Issuing Connection IDs 5.1.1. Issuing Connection IDs
Each Connection ID has an associated sequence number to assist in Each Connection ID has an associated sequence number to assist in
skipping to change at page 26, line 16 skipping to change at page 26, line 16
NEW_CONNECTION_ID frames (Section 19.15). The sequence number on NEW_CONNECTION_ID frames (Section 19.15). The sequence number on
each newly-issued connection ID MUST increase by 1. The connection each newly-issued connection ID MUST increase by 1. The connection
ID randomly selected by the client in the Initial packet and any ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection numbers unless a server opts to retain them as its initial connection
ID. ID.
When an endpoint issues a connection ID, it MUST accept packets that When an endpoint issues a connection ID, it MUST accept packets that
carry this connection ID for the duration of the connection or until carry this connection ID for the duration of the connection or until
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
frame (Section 19.16). frame (Section 19.16). Connection IDs that are issued and not
retired are considered active; any active connection ID can be used.
An endpoint SHOULD ensure that its peer has a sufficient number of An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. Endpoints store received available and unused connection IDs. Endpoints store received
connection IDs for future use and advertise the number of connection connection IDs for future use and advertise the number of connection
IDs they are willing to store with the active_connection_id_limit IDs they are willing to store with the active_connection_id_limit
transport parameter. An endpoint SHOULD NOT provide more connection transport parameter. An endpoint SHOULD NOT provide more connection
IDs than the peer's limit. IDs than the peer's limit.
An endpoint SHOULD supply a new connection ID when it receives a An endpoint SHOULD supply a new connection ID when it receives a
packet with a previously unused connection ID or when the peer packet with a previously unused connection ID or when the peer
skipping to change at page 27, line 10 skipping to change at page 27, line 10
RETIRE_CONNECTION_ID frame to its peer. Sending a RETIRE_CONNECTION_ID frame to its peer. Sending a
RETIRE_CONNECTION_ID frame indicates that the connection ID will not RETIRE_CONNECTION_ID frame indicates that the connection ID will not
be used again and requests that the peer replace it with a new be used again and requests that the peer replace it with a new
connection ID using a NEW_CONNECTION_ID frame. connection ID using a NEW_CONNECTION_ID frame.
As discussed in Section 9.5, each connection ID MUST be used on As discussed in Section 9.5, each connection ID MUST be used on
packets sent from only one local address. An endpoint that migrates packets sent from only one local address. An endpoint that migrates
away from a local address SHOULD retire all connection IDs used on away from a local address SHOULD retire all connection IDs used on
that address once it no longer plans to use that address. that address once it no longer plans to use that address.
An endpoint can request that its peer retire connection IDs by An endpoint can cause its peer to retire connection IDs by sending a
sending a NEW_CONNECTION_ID frame with an increased Retire Prior To NEW_CONNECTION_ID frame with an increased Retire Prior To field.
field. Upon receipt, the peer SHOULD retire the corresponding Upon receipt, the peer MUST retire the corresponding connection IDs
connection IDs and send the corresponding RETIRE_CONNECTION_ID frames and send corresponding RETIRE_CONNECTION_ID frames. Failing to
in a timely manner. Failing to do so can cause packets to be retire the connection IDs within approximately one PTO can cause
delayed, lost, or cause the original endpoint to send a stateless packets to be delayed, lost, or cause the original endpoint to send a
reset in response to a connection ID it can no longer route stateless reset in response to a connection ID it can no longer route
correctly. correctly.
An endpoint MAY discard a connection ID for which retirement has been An endpoint MAY discard a connection ID for which retirement has been
requested once an interval of no less than 3 PTO has elapsed since an requested once an interval of no less than 3 PTO has elapsed since an
acknowledgement is received for the NEW_CONNECTION_ID frame acknowledgement is received for the NEW_CONNECTION_ID frame
requesting that retirement. Subsequent incoming packets using that requesting that retirement. Until then, the endpoint SHOULD be
prepared to receive packets that contain the connection ID that it
has requested be retired. Subsequent incoming packets using that
connection ID could elicit a response with the corresponding connection ID could elicit a response with the corresponding
stateless reset token. stateless reset token.
5.2. Matching Packets to Connections 5.2. Matching Packets to Connections
Incoming packets are classified on receipt. Packets can either be Incoming packets are classified on receipt. Packets can either be
associated with an existing connection, or - for servers - associated with an existing connection, or - for servers -
potentially create a new connection. potentially create a new connection.
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 non-zero-length Destination Connection ID corresponding
connection, QUIC processes that packet accordingly. Note that more to an existing connection, QUIC processes that packet accordingly.
than one connection ID can be associated with a connection; see Note that more than one connection ID can be associated with a
Section 5.1. connection; see 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 local address and port of a connection where the host
require connection IDs, QUIC processes the packet as part of that used zero-length connection IDs, QUIC processes the packet as part of
connection. Endpoints SHOULD either reject connection attempts that that connection.
use the same addresses as existing connections, or use a non-zero-
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 are discarded if Packets that are matched to an existing connection are discarded if
the packets are inconsistent with the state of that connection. For the packets are inconsistent with the state of that connection. For
example, packets are discarded if they indicate a different protocol example, packets are discarded if they indicate a different protocol
version than that of the connection, or if the removal of packet version than that of the connection, or if the removal of packet
skipping to change at page 28, line 17 skipping to change at page 28, line 16
Invalid packets without packet protection, such as Initial, Retry, or Invalid packets without packet protection, such as Initial, Retry, or
Version Negotiation, MAY be discarded. An endpoint MUST generate a Version Negotiation, MAY be discarded. An endpoint MUST generate a
connection error if it commits changes to state before discovering an connection error if it commits changes to state before discovering an
error. 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 local address and port
identify a connection. Packets that don't match an existing to identify a connection. Packets that don't match an existing
connection are discarded. connection are discarded.
Due to packet reordering or loss, a client might receive packets for Due to packet reordering or loss, a client might receive packets for
a connection that are encrypted with a key it has not yet computed. a connection that are encrypted with a key it has not yet computed.
The client MAY drop these packets, or MAY buffer them in anticipation The client MAY drop these packets, or MAY buffer them in anticipation
of later packets that allow it to compute the key. of later packets that allow it to compute the key.
If a client receives a packet that has an unsupported version, it If a client receives a packet that has an unsupported version, it
MUST discard that packet. MUST discard that packet.
skipping to change at page 28, line 49 skipping to change at page 28, line 48
semantics and encodings for any version-specific field. In semantics and encodings for any version-specific field. In
particular, different packet protection keys might be used for particular, different packet protection keys might be used for
different versions. Servers that do not support a particular version different versions. Servers that do not support a particular version
are unlikely to be able to decrypt the payload of the packet. are unlikely to be able to decrypt the payload of the packet.
Servers SHOULD NOT attempt to decode or decrypt a packet from an Servers SHOULD NOT attempt to decode or decrypt a packet from an
unknown version, but instead send a Version Negotiation packet, unknown version, but instead send a Version Negotiation packet,
provided that the packet is sufficiently long. provided that the packet is sufficiently long.
Packets with a supported version, or no version field, are matched to Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero- a connection using the connection ID or - for packets with zero-
length connection IDs - the address tuple. If the packet doesn't length connection IDs - the local address and port. If the packet
match an existing connection, the server continues below. doesn't match an existing connection, the server continues below.
If the packet is an Initial packet fully conforming with the If the packet is an Initial packet fully conforming with the
specification, the server proceeds with the handshake (Section 7). specification, the server proceeds with the handshake (Section 7).
This commits the server to the version that the client selected. This commits the server to the version that the client selected.
If a server isn't currently accepting any new connections, it SHOULD If a server isn't currently accepting any new connections, it SHOULD
send an Initial packet containing a CONNECTION_CLOSE frame with error send an Initial packet containing a CONNECTION_CLOSE frame with error
code SERVER_BUSY. code SERVER_BUSY.
If the packet is a 0-RTT packet, the server MAY buffer a limited If the packet is a 0-RTT packet, the server MAY buffer a limited
skipping to change at page 29, line 38 skipping to change at page 29, line 38
perform when interacting with the QUIC transport. This document does perform when interacting with the QUIC transport. This document does
not specify an API, but any implementation of this version of QUIC not specify an API, but any implementation of this version of QUIC
MUST expose the ability to perform the operations described in this MUST expose the ability to perform the operations described in this
section on a QUIC connection. section on a QUIC connection.
When implementing the client role, applications need to be able to: When implementing the client role, applications need to be able to:
o open a connection, which begins the exchange described in o open a connection, which begins the exchange described in
Section 7; Section 7;
o enable 0-RTT; and o enable 0-RTT when available; and
o be informed when 0-RTT has been accepted or rejected by a server. o be informed when 0-RTT has been accepted or rejected by a server.
When implementing the server role, applications need to be able to: When implementing the server role, applications need to be able to:
o listen for incoming connections, which prepares for the exchange o listen for incoming connections, which prepares for the exchange
described in Section 7; described in Section 7;
o if Early Data is supported, embed application-controlled data in o if Early Data is supported, embed application-controlled data in
the TLS resumption ticket sent to the client; and the TLS resumption ticket sent to the client; and
skipping to change at page 32, line 48 skipping to change at page 32, line 48
* 1-RTT keys have forward secrecy * 1-RTT keys have forward secrecy
o authenticated values for transport parameters of both endpoints, o authenticated values for transport parameters of both endpoints,
and confidentiality protection for server transport parameters and confidentiality protection for server transport parameters
(see Section 7.3) (see Section 7.3)
o authenticated negotiation of an application protocol (TLS uses o authenticated negotiation of an application protocol (TLS uses
ALPN [RFC7301] for this purpose) ALPN [RFC7301] for this purpose)
The first CRYPTO frame from a client MUST be sent in a single packet.
Any second attempt that is triggered by address validation (see
Section 8.1) MUST also be sent within a single packet. This avoids
having to reassemble a message from multiple packets.
The first client packet of the cryptographic handshake protocol MUST
fit within a 1232 byte QUIC packet payload. This includes overheads
that reduce the space available to the cryptographic handshake
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.4.2. (ECN) in the first packets it sends, as described in Section 13.4.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 Endpoints MUST explicitly negotiate an application protocol. This
avoids situations where there is a disagreement about the protocol avoids situations where there is a disagreement about the protocol
skipping to change at page 39, line 29 skipping to change at page 39, line 29
from the server. Once the server has successfully processed a from the server. Once the server has successfully processed a
Handshake packet from the client, it can consider the client address Handshake packet from the client, it can consider the client address
to have been validated. to have been validated.
Prior to validating the client address, servers MUST NOT send more Prior to validating the client address, servers MUST NOT send more
than three times as many bytes as the number of bytes they have than three times as many bytes as the number of bytes they have
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 ensure that UDP datagrams containing only Initial Clients MUST ensure that UDP datagrams containing Initial packets
packets are sized to at least 1200 bytes, adding padding to packets have UDP payloads of at least 1200 bytes, adding padding to packets
in the datagram as necessary. Sending padded datagrams ensures that in the datagram as necessary. Sending padded datagrams ensures that
the server is not overly constrained by the amplification the server is not overly constrained by the amplification
restriction. restriction.
Packet loss, in particular loss of a Handshake packet from the Packet loss, in particular loss of a Handshake packet from the
server, can cause a situation in which the server cannot send when server, can cause a situation in which the server cannot send when
the client has no data to send and the anti-amplification limit is the client has no data to send and the anti-amplification limit is
reached. In order to avoid this causing a handshake deadlock, reached. In order to avoid this causing a handshake deadlock,
clients SHOULD send a packet upon a crypto retransmission timeout, as clients SHOULD send a packet upon a probe timeout, as described in
described in [QUIC-RECOVERY]. If the client has no data to [QUIC-RECOVERY]. If the client has no data to retransmit and does
retransmit and does not have Handshake keys, it SHOULD send an not have Handshake keys, it SHOULD send an Initial packet in a UDP
Initial packet in a UDP datagram of at least 1200 bytes. If the datagram of at least 1200 bytes. If the client has Handshake keys,
client has Handshake keys, it SHOULD send a Handshake packet. 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, In addition to sending limits imposed prior to address validation,
servers are also constrained in what they can send by the limits set servers are also constrained in what they can send by the limits set
skipping to change at page 40, line 26 skipping to change at page 40, line 26
Retry packet. In response to processing an Initial containing a Retry packet. In response to processing an Initial containing a
token, a server can either abort the connection or permit it to token, a server can either abort the connection or permit it to
proceed. 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.
A server can also use a Retry packet to defer the state and A server can also use a Retry packet to defer the state and
processing costs of connection establishment. By giving the client a processing costs of connection establishment. Requiring the server
different connection ID to use, a server can cause the connection to to provide a different connection ID, along with the
be routed to a server instance with more resources available for new original_connection_id transport parameter defined in Section 18.2,
connections. forces the server to demonstrate that it, or an entity it cooperates
with, received the original Initial packet from the client.
Providing a different connection ID also grants a server some control
over how subsequent packets are routed. This can be used to direct
connections to a different server instance.
A flow showing the use of a Retry packet is shown in Figure 5. A flow showing the use of a Retry packet is shown in Figure 5.
Client Server Client Server
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
<- Retry+Token <- Retry+Token
Initial+Token[1]: CRYPTO[CH] -> Initial+Token[1]: CRYPTO[CH] ->
skipping to change at page 44, line 23 skipping to change at page 44, line 26
endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the
same packet. This ensures that an unused connection ID will be same packet. This ensures that an unused connection ID will be
available to the peer when sending a response. available to the peer when sending a response.
8.3. Initiating Path Validation 8.3. Initiating Path Validation
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, however an endpoint SHOULD NOT send multiple packet loss. However, an endpoint SHOULD NOT send multiple
PATH_CHALLENGE frames in a single packet. An endpoint SHOULD NOT PATH_CHALLENGE frames in a single packet. An endpoint SHOULD NOT
send a PATH_CHALLENGE more frequently than it would an Initial send a PATH_CHALLENGE more frequently than it would an Initial
packet, ensuring that connection migration is no more load on a new packet, ensuring that connection migration is no more load on a new
path than establishing a new connection. path than establishing a new connection.
The endpoint MUST use unpredictable data in every PATH_CHALLENGE The endpoint MUST use unpredictable data in every PATH_CHALLENGE
frame so that it can associate the peer's response with the frame so that it can associate the peer's response with the
corresponding PATH_CHALLENGE. corresponding PATH_CHALLENGE.
8.4. Path Validation Responses 8.4. Path Validation Responses
skipping to change at page 51, line 21 skipping to change at page 51, line 21
PATH_CHALLENGE, and restart the timer for a longer period of time. PATH_CHALLENGE, and restart the timer for a longer period of time.
9.5. Privacy Implications of Connection Migration 9.5. Privacy Implications of Connection Migration
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 connection IDs they provide cannot be linked by any
other entity. other entity.
At any time, endpoints MAY change the Destination Connection ID they At any time, endpoints MAY change the Destination Connection ID they
send to a value that has not been used on another path. send to a value that has not been used on another path.
An endpoint MUST use a new connection ID if it initiates connection An endpoint MUST use a new connection ID if it initiates connection
migration. Using a new connection ID eliminates the use of the migration as described in Section 9.2 or probes a new network path as
connection ID for linking activity from the same connection on described in Section 9.1. An endpoint MUST use a new connection ID
different networks. Header protection ensures that packet numbers in response to a change in the address of a peer if the packet with
cannot be used to correlate activity. This does not prevent other the new peer address uses an active connection ID that has not been
properties of packets, such as timing and size, from being used to previously used by the peer.
correlate activity.
Using different connection IDs for packets sent in both directions on
each new network path eliminates the use of the connection ID for
linking packets from the same connection across different network
paths. Header protection ensures that packet numbers cannot be used
to correlate activity. This does not prevent other properties of
packets, such as timing and size, from being used to correlate
activity.
Unintentional changes in path without a change in connection ID are Unintentional changes in path without a change in connection ID are
possible. For example, after a period of network inactivity, NAT possible. For example, after a period of network inactivity, NAT
rebinding might cause packets to be sent on a new path when the rebinding might cause packets to be sent on a new path when the
client resumes sending. client resumes sending.
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
migration. This ensures that the mechanisms that support migration migration. This ensures that the mechanisms that support migration
are exercised even for clients that don't experience NAT rebindings are exercised even for clients that don't experience NAT rebindings
or genuine migrations. Changing port number can cause a peer to or genuine migrations. Changing port number can cause a peer to
reset its congestion state (see Section 9.4), so the port SHOULD only reset its congestion state (see Section 9.4), so the port SHOULD only
be changed infrequently. be changed infrequently.
An endpoint that exhausts available connection IDs cannot migrate. An endpoint that exhausts available connection IDs cannot probe new
To ensure that migration is possible and packets sent on different paths or initiate migration, nor can it respond to probes or attempts
paths cannot be correlated, endpoints SHOULD provide new connection by its peer to migrate. To ensure that migration is possible and
IDs before peers migrate. packets sent on different paths cannot be correlated, endpoints
SHOULD provide new connection IDs before peers migrate; see
Section 5.1.1. If a peer might have exhausted available connection
IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in
all packets sent on a new network path.
9.6. Server's Preferred Address 9.6. Server's Preferred Address
QUIC allows servers to accept connections on one IP address and QUIC allows servers to accept connections on one IP address and
attempt to transfer these connections to a more preferred address attempt to transfer these connections to a more preferred address
shortly after the handshake. This is particularly useful when shortly after the handshake. This is particularly useful when
clients initially connect to an address shared by multiple servers clients initially connect to an address shared by multiple servers
but would prefer to use a unicast address to ensure connection but would prefer to use a unicast address to ensure connection
stability. This section describes the protocol for migrating a stability. This section describes the protocol for migrating a
connection to a preferred server address. connection to a preferred server address.
skipping to change at page 56, line 5 skipping to change at page 56, line 15
10.2. Idle Timeout 10.2. Idle Timeout
If the idle timeout is enabled, a connection is silently closed and If the idle timeout is enabled, a connection is silently closed and
the state is discarded when it remains idle for longer than both the the state is discarded when it remains idle for longer than both the
advertised idle timeout (see Section 18.2) and three times the advertised idle timeout (see Section 18.2) and three times the
current Probe Timeout (PTO). current Probe Timeout (PTO).
Each endpoint advertises its own idle timeout to its peer. An Each endpoint advertises its own idle timeout to its peer. An
endpoint restarts any timer it maintains when a packet from its peer endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully. The timer is also restarted is received and processed successfully. The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an when sending an ack-eliciting packet (see [QUIC-RECOVERY]), but only
ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK- if no other ack-eliciting packets have been sent since last receiving
eliciting packets have been sent since last receiving a packet. a packet. Restarting when sending packets ensures that connections
Restarting when sending packets ensures that connections do not do not prematurely time out when initiating new activity.
prematurely time out when initiating new activity.
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 a Probe Timeout (PTO; packets arrive. If a peer could timeout within a Probe Timeout (PTO;
see Section 6.3 of [QUIC-RECOVERY]), it is advisable to test for see Section 6.3 of [QUIC-RECOVERY]), it is advisable to test for
liveness before sending any data that cannot be retried safely. Note liveness before sending any data that cannot be retried safely. Note
that it is likely that only applications or application protocols that it is likely that only applications or application protocols
skipping to change at page 58, line 12 skipping to change at page 58, line 21
crash or outage might result in peers continuing to send data to an crash or outage might result in peers continuing to send data to an
endpoint that is unable to properly continue the connection. An endpoint that is unable to properly continue the connection. An
endpoint MAY send a stateless reset in response to receiving a packet endpoint MAY send a stateless reset in response to receiving a packet
that it cannot associate with an active connection. that it cannot associate with an active connection.
A stateless reset is not appropriate for signaling error conditions. A stateless reset is not appropriate for signaling error conditions.
An endpoint that wishes to communicate a fatal connection error MUST An endpoint that wishes to communicate a fatal connection error MUST
use a CONNECTION_CLOSE frame if it has sufficient state to do so. use a CONNECTION_CLOSE frame if it has sufficient state to do so.
To support this process, a token is sent by endpoints. The token is To support this process, a token is sent by endpoints. The token is
carried in the NEW_CONNECTION_ID frame sent by either peer, and carried in the Stateless Reset Token field of a NEW_CONNECTION_ID
servers can specify the stateless_reset_token transport parameter frame. Servers can also specify a stateless_reset_token transport
during the handshake (clients cannot because their transport parameter during the handshake that applies to the connection ID that
parameters don't have confidentiality protection). This value is it selected during the handshake; clients cannot use this transport
protected by encryption, so only client and server know this value. parameter because their transport parameters don't have
Tokens are invalidated when their associated connection ID is retired confidentiality protection. These tokens are protected by
via a RETIRE_CONNECTION_ID frame (Section 19.16). encryption, so only client and server know their value. Tokens are
invalidated when their associated connection ID is retired 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| Unpredictable Bits (38 ..) ... |0|1| Unpredictable Bits (38 ..) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 60, line 33 skipping to change at page 60, line 45
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 an incoming An endpoint detects a potential stateless reset using the trailing 16
packet either cannot be associated with a connection, cannot be bytes of the UDP datagram. An endpoint remembers all Stateless Reset
decrypted, or is marked as a duplicate packet. The endpoint MUST Tokens associated with the connection IDs and remote addresses for
then compare the last 16 bytes of the packet with all Stateless Reset datagrams it has recently sent. This includes Stateless Reset Tokens
Tokens that are associated with connection IDs that the endpoint from NEW_CONNECTION_ID frames and the server's transport parameters
recently used to send packets from the IP address and port on which but excludes Stateless Reset Tokens associated with connection IDs
the datagram is received. This includes Stateless Reset Tokens from that are either unused or retired. The endpoint identifies a
NEW_CONNECTION_ID frames and the server's transport parameters. An received datagram as a stateless reset by comparing the last 16 bytes
endpoint MUST NOT check for any Stateless Reset Tokens associated of the datagram with all Stateless Reset Tokens associated with the
remote address on which the datagram was received.
This comparison can be performed for every inbound datagram.
Endpoints MAY skip this check if any packet from a datagram is
successfully processed. However, the comparison MUST be performed
when the first packet in an incoming datagram either cannot be
associated with a connection, or cannot be decrypted.
An endpoint MUST NOT check for any Stateless Reset Tokens associated
with connection IDs it has not used or for connection IDs that have with connection IDs it has not used or for connection IDs that have
been retired. been retired.
If the last 16 bytes of the packet values are identical to a When comparing a datagram to Stateless Reset Token values, endpoints
MUST perform the comparison without leaking information about the
value of the token. For example, performing this comparison in
constant time protects the value of individual Stateless Reset Tokens
from information leakage through timing side channels. Another
approach would be to store and compare the transformed values of
Stateless Reset Tokens instead of the raw token values, where the
transformation is defined as a cryptographically-secure pseudo-random
function using a secret key (e.g., block cipher, HMAC [RFC2104]). An
endpoint is not expected to protect information about whether a
packet was successfully decrypted, or the number of valid Stateless
Reset Tokens.
If the last 16 bytes of the datagram are identical in value to a
Stateless Reset Token, the endpoint MUST enter the draining period Stateless Reset Token, the endpoint MUST enter the draining period
and not send any further packets on this connection. If the and not send any further packets on this connection.
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,
this presents a coordination problem when there are multiple this presents a coordination problem when there are multiple
instances in a cluster or a storage problem for an endpoint that instances in a cluster or a storage problem for an endpoint that
might lose state. Stateless reset specifically exists to handle the might lose state. Stateless reset specifically exists to handle the
case where state is lost, so this approach is suboptimal. case where state is lost, so this approach is suboptimal.
skipping to change at page 61, line 48 skipping to change at page 62, line 30
the connection, so a value can only be used once. This method for the connection, so a value can only be used once. This method for
choosing the Stateless Reset Token means that the combination of choosing the Stateless Reset Token means that the combination of
connection ID and static key MUST NOT be used for another connection. connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the cause a packet to be routed to an instance that has no state but the
same static key; see Section 21.9. A connection ID from a connection same static key; see Section 21.9. A connection ID from a connection
that is reset by revealing the Stateless Reset Token MUST NOT be that is reset by revealing the Stateless Reset Token MUST NOT be
reused for new connections at nodes that share a static key. reused for new connections at nodes that share a static key.
The same Stateless Reset Token MAY be used for multiple connection The same Stateless Reset Token MUST NOT be used for multiple
IDs on the same connection. However, reuse of a Stateless Reset connection IDs. Endpoints are not required to compare new values
Token might expose an endpoint to denial of service if associated against all previous values, but a duplicate value MAY be treated as
connection IDs are forgotten while the associated token is still a connection error of type PROTOCOL_VIOLATION.
active at a peer. An endpoint MUST ensure that packets with
Destination Connection ID field values that correspond to a reused
Stateless Reset Token are attributed to the same connection as long
as the Stateless Reset Token is still usable, even when the
connection ID has been retired. Otherwise, an attacker might be able
to send a packet with a retired connection ID and cause the endpoint
to produce a Stateless Reset that it can use to disrupt the
connection, just as with the attacks in Section 21.9.
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 without knowing the The design of a Stateless Reset is such that without knowing the
stateless reset token it is indistinguishable from a valid packet. stateless reset token it is indistinguishable from a valid packet.
For instance, if a server sends a Stateless Reset to another server For instance, if a server sends a Stateless Reset to another server
it might receive another Stateless Reset in response, which could it might receive another Stateless Reset in response, which could
skipping to change at page 66, line 6 skipping to change at page 66, line 27
short header does not include a length, so it can only be the last short header does not include a length, so it can only be the last
packet included in a UDP datagram. An endpoint SHOULD NOT coalesce packet included in a UDP datagram. An endpoint SHOULD NOT coalesce
multiple packets at the same encryption level. multiple packets at the same encryption level.
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. The receiver of coalesced QUIC packets MUST
packet header might be redundant, no fields are omitted. The individually process each QUIC packet and separately acknowledge
receiver of coalesced QUIC packets MUST individually process each them, as if they were received as the payload of different UDP
QUIC packet and separately acknowledge them, as if they were received datagrams. For example, if decryption fails (because the keys are
as the payload of different UDP datagrams. For example, if not available or any other reason), the receiver MAY either discard
decryption fails (because the keys are not available or any other or buffer the packet for later processing and MUST attempt to process
reason), the receiver MAY either discard or buffer the packet for the remaining packets.
later processing and MUST attempt to process the remaining packets.
Retry packets (Section 17.2.5), Version Negotiation packets Retry packets (Section 17.2.5), Version Negotiation packets
(Section 17.2.1), and packets with a short header (Section 17.3) do (Section 17.2.1), and packets with a short header (Section 17.3) do
not contain a Length field and so cannot be followed by other packets not contain a Length field and so cannot be followed by other packets
in the same UDP datagram. Note also that there is no situation where in the same UDP datagram. Note also that there is no situation where
a Retry or Version Negotiation packet is coalesced with another a Retry or Version Negotiation packet is coalesced with another
packet. packet.
12.3. Packet Numbers 12.3. Packet Numbers
skipping to change at page 71, line 20 skipping to change at page 71, line 20
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.2. Generating Acknowledgements 13.2. Generating Acknowledgements
Endpoints acknowledge all packets they receive and process. However, Endpoints acknowledge all packets they receive and process. However,
only ack-eliciting packets (see [QUIC-RECOVERY]) trigger the sending only ack-eliciting packets cause an ACK frame to be sent within the
of an ACK frame. Packets that are not ack-eliciting are only maximum ack delay. Packets that are not ack-eliciting are only
acknowledged when an ACK frame is sent for other reasons. acknowledged when an ACK frame is sent for other reasons.
When sending a packet for any reason, an endpoint should attempt to When sending a packet for any reason, an endpoint should attempt to
bundle an ACK frame if one has not been sent recently. Doing so bundle an ACK frame if one has not been sent recently. Doing so
helps with timely loss detection at the peer. helps with timely loss detection at the peer.
In general, frequent feedback from a receiver improves loss and In general, frequent feedback from a receiver improves loss and
congestion response, but this has to be balanced against excessive congestion response, but this has to be balanced against excessive
load generated by a receiver that sends an ACK frame in response to load generated by a receiver that sends an ACK frame in response to
every ack-eliciting packet. The guidance offered below seeks to every ack-eliciting packet. The guidance offered below seeks to
strike this balance. strike this balance.
13.2.1. Sending ACK Frames 13.2.1. Sending ACK Frames
Every packet SHOULD be acknowledged at least once, and ack-eliciting
packets MUST be acknowledged at least once within the maximum ack
delay. An endpoint communicates its maximum delay using the
max_ack_delay transport parameter; see Section 18.2. max_ack_delay
declares an explicit contract: an endpoint promises to never
intentionally delay acknowledgments of an ack-eliciting packet by
more than the indicated value. If it does, any excess accrues to the
RTT estimate and could result in spurious or delayed retransmissions
from the peer. For Initial and Handshake packets, a max_ack_delay of
0 is used. The sender uses the receiver's "max_ack_delay" value in
determining timeouts for timer-based retransmission, as detailed in
Section 5.2.1 of [QUIC-RECOVERY].
An ACK frame SHOULD be generated for at least every second ack- An ACK frame SHOULD be generated for at least every second ack-
eliciting packet. This recommendation is in keeping with standard eliciting packet. This recommendation is in keeping with standard
practice for TCP [RFC5681]. practice for TCP [RFC5681].
A receiver's delayed acknowledgment timer SHOULD NOT exceed the
current RTT estimate or the value it indicates in the "max_ack_delay"
transport parameter. This ensures an acknowledgment is sent at least
once per RTT when packets needing acknowledgement are received. The
sender can use the receiver's "max_ack_delay" value in determining
timeouts for timer-based retransmission.
In order to assist loss detection at the sender, an endpoint SHOULD In order to assist loss detection at the sender, an endpoint SHOULD
send an ACK frame immediately on receiving an ack-eliciting packet send an ACK frame immediately on receiving an ack-eliciting packet
that is out of order. The endpoint MAY continue sending ACK frames that is out of order. The endpoint MAY continue sending ACK frames
immediately on each subsequently received packet, but the endpoint immediately on each subsequently received packet, but the endpoint
SHOULD return to acknowledging every other packet after a period of SHOULD return to acknowledging every other packet within a period of
1/8 x RTT, unless more ACK-eliciting packets are received out of 1/8 x RTT, unless more ack-eliciting packets are received out of
order. If every subsequent ACK-eliciting packet arrives out of order. If every subsequent ack-eliciting packet arrives out of
order, then an ACK frame SHOULD be sent immediately for every order, then an ACK frame SHOULD be sent immediately for every
received ACK-eliciting packet. received ack-eliciting packet.
Similarly, packets marked with the ECN Congestion Experienced (CE) Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to codepoint in the IP header SHOULD be acknowledged immediately, to
reduce the peer's response time to congestion events. reduce the peer's response time to congestion events.
As an optimization, a receiver MAY process multiple packets before As an optimization, a receiver MAY process multiple packets before
sending any ACK frames in response. In this case the receiver can sending any ACK frames in response. In this case the receiver can
determine whether an immediate or delayed acknowledgement should be determine whether an immediate or delayed acknowledgement should be
generated after processing incoming packets. generated after processing incoming packets.
Acknowledgements of packets carrying CRYPTO frames SHOULD be
minimally delayed, to complete the handshake with minimal latency.
Delaying them by a small amount, such as the local timer granularity,
allows the endpoint to bundle any data sent in response with the ACK
frame. ACK frames SHOULD be sent immediately when the crypto stack
indicates all data for that packet number space has been received.
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 with no acknowledgments forthcoming from the receiver.
forthcoming from the receiver. Therefore, a sender SHOULD ensure Therefore, a sender SHOULD ensure that other frames are sent in
that other frames are sent in addition to PADDING frames to elicit addition to PADDING frames to elicit acknowledgments from the
acknowledgments from the receiver. receiver.
An endpoint that is only sending ACK frames will not receive An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are acknowledgments from its peer unless those acknowledgements are
included in packets with ACK-eliciting frames. An endpoint SHOULD included in packets with ack-eliciting frames. An endpoint SHOULD
bundle ACK frames with other frames when there are new ACK-eliciting bundle ACK frames with other frames when there are new ack-eliciting
packets to acknowledge. When only non-ACK-eliciting packets need to packets to acknowledge. When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ACK-eliciting packet be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to bundle an ACK frame with outgoing frames. has been received to bundle an ACK frame with outgoing frames.
The algorithms in [QUIC-RECOVERY] are resilient to receivers that do The algorithms in [QUIC-RECOVERY] are resilient to receivers that do
not follow guidance offered above. However, an implementor should not follow guidance offered above. However, an implementor should
only deviate from these requirements after careful consideration of only deviate from these requirements after careful consideration of
the performance implications of doing so. the performance implications of doing so.
Packets containing only ACK frames are not congestion controlled, so Packets containing only ACK frames are not congestion controlled, so
there are limits on how frequently they can be sent. An endpoint there are limits on how frequently they can be sent. An endpoint
MUST NOT send more than one ACK-frame-only packet in response to MUST NOT send more than one ACK-frame-only packet in response to
receiving an ACK-eliciting packet (one containing frames other than receiving an ack-eliciting packet. An endpoint MUST NOT send a non-
ACK and/or PADDING). An endpoint MUST NOT send a packet containing ack-eliciting packet in response to a non-ack-eliciting packet, even
only an ACK frame in response to a non-ACK-eliciting packet (one if there are packet gaps which precede the received packet. Limiting
containing only ACK and/or PADDING frames), even if there are packet ACK frames avoids an infinite feedback loop of acknowledgements,
gaps which precede the received packet. Limiting ACK frames avoids which could prevent the connection from ever becoming idle. However,
an infinite feedback loop of acknowledgements, which could prevent the endpoint acknowledges non-ACK-eliciting packets when it sends an
the connection from ever becoming idle. However, the endpoint ACK frame.
acknowledges non-ACK-eliciting packets when it sends an ACK frame.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it 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 did not send as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition. is able to detect the condition.
13.2.2. Managing ACK Ranges 13.2.2. Managing ACK Ranges
When an ACK frame is sent, one or more ranges of acknowledged packets When an ACK frame is sent, one or more ranges of acknowledged packets
are included. Including older packets reduces the chance of spurious are included. Including older packets reduces the chance of spurious
retransmits caused by losing previously sent ACK frames, at the cost retransmits caused by losing previously sent ACK frames, at the cost
skipping to change at page 74, line 5 skipping to change at page 73, line 51
algorithm could cause spurious retransmits, but the sender will algorithm could cause spurious retransmits, but the sender will
continue making forward progress. continue making forward progress.
13.2.4. Limiting ACK Ranges 13.2.4. Limiting ACK Ranges
To limit ACK Ranges (see Section 19.3.1) to those that have not yet To limit ACK Ranges (see Section 19.3.1) to those that have not yet
been received by the sender, the receiver SHOULD track which ACK been received by the sender, the receiver SHOULD track which ACK
frames have been acknowledged by its peer. The receiver SHOULD frames have been acknowledged by its peer. The receiver SHOULD
exclude already acknowledged packets from future ACK frames whenever exclude already acknowledged packets from future ACK frames whenever
these packets would unnecessarily contribute to the ACK frame size. these packets would unnecessarily contribute to the ACK frame size.
When the receiver is only sending non-ACK-eliciting packets, it can When the receiver is only sending non-ack-eliciting packets, it can
bundle a PING or other small ACK-eliciting frame with a fraction of bundle a PING or other small ack-eliciting frame with a fraction of
them, such as once per round trip, to enable dropping unnecessary ACK them, such as once per round trip, to enable dropping unnecessary ACK
ranges and any state for previously sent packets. The receiver MUST ranges and any state for previously sent packets. The receiver MUST
NOT bundle an ACK-eliciting frame, such as a PING, with all packets NOT bundle an ack-eliciting frame, such as a PING, with all packets
that would otherwise be non-ACK-eliciting, in order to avoid an that would otherwise be non-ack-eliciting, in order to avoid an
infinite feedback loop of acknowledgements. infinite feedback loop of acknowledgements.
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 Ranges 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 algorithms ([QUIC-RECOVERY]) declare some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare
packets lost after sufficiently newer packets are acknowledged. packets lost after sufficiently newer packets are acknowledged.
Therefore, the receiver SHOULD repeatedly acknowledge newly received Therefore, the receiver SHOULD repeatedly acknowledge newly received
packets in preference to packets received in the past. packets in preference to packets received in the past.
13.2.5. Measuring and Reporting Host Delay 13.2.5. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between when An endpoint measures the delays intentionally introduced between when
an ACK-eliciting packet is received and the corresponding an ack-eliciting packet is received and the corresponding
acknowledgment is sent. The endpoint encodes this delay for the acknowledgment is sent. The endpoint encodes this delay for the
largest acknowledged packet in the Ack Delay field of an ACK frame largest acknowledged packet in the Ack Delay field of an ACK frame
(see Section 19.3). This allows the receiver of the ACK to adjust (see Section 19.3). This allows the receiver of the ACK to adjust
for any intentional delays, which is important for getting a better for any intentional delays, which is important for getting a better
estimate of the path RTT when acknowledgments are delayed. A packet estimate of the path RTT when acknowledgments are delayed. A packet
might be held in the OS kernel or elsewhere on the host before being might be held in the OS kernel or elsewhere on the host before being
processed. An endpoint MUST NOT include delays that is does not processed. An endpoint MUST NOT include delays that is does not
control when populating the Ack Delay field in an ACK frame. control when populating the Ack Delay field in an ACK frame.
An endpoint MUST NOT excessively delay acknowledgements of ack-
eliciting packets. An endpoint commits to a maximum delay using the
max_ack_delay transport parameter; see Section 18.2. max_ack_delay
declares an explicit contract: an endpoint promises to never delay
acknowledgments of an ack-eliciting packet by more than the indicated
value. If it does, any excess accrues to the RTT estimate and could
result in delayed retransmissions from the peer. For Initial and
Handshake packets, a max_ack_delay of 0 is used.
13.2.6. ACK Frames and Packet Protection 13.2.6. 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
skipping to change at page 75, line 35 skipping to change at page 75, line 23
o Data sent in CRYPTO frames is retransmitted according to the rules o Data sent in CRYPTO frames is retransmitted according to the rules
in [QUIC-RECOVERY], until all data has been acknowledged. Data in in [QUIC-RECOVERY], until all data has been acknowledged. Data in
CRYPTO frames for Initial and Handshake packets is discarded when CRYPTO frames for Initial and Handshake packets is discarded when
keys for the corresponding encryption level are discarded. keys for the corresponding encryption level are discarded.
o Application data sent in STREAM frames is retransmitted in new o Application data sent in STREAM frames is retransmitted in new
STREAM frames unless the endpoint has sent a RESET_STREAM for that STREAM frames unless the endpoint has sent a RESET_STREAM for that
stream. Once an endpoint sends a RESET_STREAM frame, no further stream. Once an endpoint sends a RESET_STREAM frame, no further
STREAM frames are needed. STREAM frames are needed.
o The most recent set of acknowledgments are sent in ACK frames. An o ACK frames carry the most recent set of acknowledgements and the
ACK frame SHOULD contain all unacknowledged acknowledgments, as Ack Delay from the largest acknowledged packet, as described in
described in Section 13.2.1. Section 13.2.1. Delaying the transmission of packets containing
ACK frames or sending old ACK frames can cause the peer to
generate an inflated RTT sample or unnecessarily disable ECN.
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 sending part of the stream). "Data Recvd" state is reached on the sending part of the stream).
The content of a RESET_STREAM frame MUST NOT change when it is The content of a RESET_STREAM frame MUST NOT change when it is
sent again. sent again.
o Similarly, a request to cancel stream transmission, as encoded in o Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receiving part of the a STOP_SENDING frame, is sent until the receiving part of the
skipping to change at page 92, line 46 skipping to change at page 92, line 23
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
discard the packet as spurious or treat it as a connection error. discard the packet as spurious or treat it as a connection error.
The first packet sent by a client always includes a CRYPTO frame that The first packet sent by a client always includes a CRYPTO frame that
contains the entirety of the first cryptographic handshake message. contains the start or all of the first cryptographic handshake
This packet, and the cryptographic handshake message, MUST fit in a message. The first CRYPTO frame sent always begins at an offset of 0
single UDP datagram (see Section 7). The first CRYPTO frame sent (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 another series of Initial packets. These Initial packets will
cryptographic handshake and will contain a CRYPTO frame with an continue the cryptographic handshake and will contain CRYPTO frames
offset matching the size of the CRYPTO frame sent in the first starting at an offset matching the size of the CRYPTO frames sent in
Initial packet. Cryptographic handshake messages subsequent to the the first flight of Initial packets.
first do not need to fit within a single UDP datagram.
17.2.2.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.9.1 of [QUIC-TLS]) along with any loss recovery and Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and
skipping to change at page 97, line 26 skipping to change at page 96, line 31
Retry Token: An opaque token that the server can use to validate the Retry Token: An opaque token that the server can use to validate the
client's address. client's address.
The server populates the Destination Connection ID with the The server populates the Destination Connection ID with the
connection ID that the client included in the Source Connection ID of connection ID that the client included in the Source Connection ID of
the Initial packet. the Initial packet.
The server includes a connection ID of its choice in the Source The server includes a connection ID of its choice in the Source
Connection ID field. This value MUST not be equal to the Destination Connection ID field. This value MUST not be equal to the Destination
Connection ID field of the packet sent by the client. The client Connection ID field of the packet sent by the client. A client MUST
MUST use this connection ID in the Destination Connection ID of discard a Retry packet that contains a Source Connection ID field
subsequent packets that it sends. that is identical to the Destination Connection ID field of its
Initial packet. The client MUST use the value from the Source
Connection ID field of the Retry packet in the Destination Connection
ID field of 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. A server MUST NOT send more than one Retry Initial or 0-RTT packets. A server MUST NOT send more than one Retry
packet in response to a single UDP datagram. 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
skipping to change at page 101, line 38 skipping to change at page 100, line 41
the risk that transient spin bit state can be used to link flows the risk that transient spin bit state can be used to link flows
across connection migration or ID change. across connection migration or ID change.
With this mechanism, the server reflects the spin value received, With this mechanism, the server reflects the spin value received,
while the client 'spins' it after one RTT. On-path observers can while the client 'spins' it after one RTT. On-path observers can
measure the time between two spin bit toggle events to estimate the measure the time between two spin bit toggle events to estimate the
end-to-end RTT of a connection. end-to-end RTT of a connection.
18. Transport Parameter Encoding 18. Transport Parameter Encoding
The format of the transport parameters is the TransportParameters The "extension_data" field of the quic_transport_parameters extension
struct from Figure 15. This is described using the presentation defined in [QUIC-TLS] contains the QUIC transport parameters. They
language from Section 3 of [TLS13]. are encoded as a length-prefixed sequence of transport parameters, as
shown in Figure 15:
enum { 0 1 2 3
original_connection_id(0), 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
idle_timeout(1), +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
stateless_reset_token(2), | Sequence Length (16) |
max_packet_size(3), +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
initial_max_data(4), | Transport Parameter 1 (*) ...
initial_max_stream_data_bidi_local(5), +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
initial_max_stream_data_bidi_remote(6), | Transport Parameter 2 (*) ...
initial_max_stream_data_uni(7), +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
initial_max_streams_bidi(8), ...
initial_max_streams_uni(9), +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ack_delay_exponent(10), | Transport Parameter N (*) ...
max_ack_delay(11), +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
disable_active_migration(12),
preferred_address(13),
active_connection_id_limit(14),
(65535)
} TransportParameterId;
struct { Figure 15: Sequence of Transport Parameters
TransportParameterId parameter;
opaque value<0..2^16-1>;
} TransportParameter;
TransportParameter TransportParameters<0..2^16-1>; The Sequence Length field contains the length of the sequence of
transport parameters, in bytes. Each transport parameter is encoded
as an (identifier, length, value) tuple, as shown in Figure 16:
Figure 15: Definition of TransportParameters 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Parameter ID (16) | Transport Param Length (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Parameter Value (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "extension_data" field of the quic_transport_parameters extension Figure 16: Transport Parameter Encoding
defined in [QUIC-TLS] contains a TransportParameters value. TLS
encoding rules are therefore used to describe the encoding of The Transport Param Length field contains the length of the Transport
transport parameters. Parameter Value field.
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. Reserved Transport Parameters 18.1. Reserved Transport Parameters
Transport parameters with an identifier of the form "31 * N + 27" for Transport parameters with an identifier of the form "31 * N + 27" for
integer values of N are reserved to exercise the requirement that integer values of N are reserved to exercise the requirement that
unknown transport parameters be ignored. These transport parameters unknown transport parameters be ignored. These transport parameters
have no semantics, and may carry arbitrary values. have no semantics, and may carry arbitrary values.
skipping to change at page 103, line 14 skipping to change at page 102, line 14
Many transport parameters listed here have integer values. Those Many transport parameters listed here have integer values. Those
transport parameters that are identified as integers use a variable- transport parameters that are identified as integers use a variable-
length integer encoding (see Section 16) and have a default value of length integer encoding (see Section 16) and have a default value of
0 if the transport parameter is absent, unless otherwise stated. 0 if the transport parameter is absent, unless otherwise stated.
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. This
server MUST include the original_connection_id transport parameter is the same value sent in the "Original Destination Connection ID"
if it sent a Retry packet. field of a Retry packet (see Section 17.2.5). A server MUST
include the original_connection_id transport parameter if it sent
a Retry packet.
idle_timeout (0x0001): The idle timeout is a value in milliseconds idle_timeout (0x0001): The idle timeout is a value in milliseconds
that is encoded as an integer; see (Section 10.2). If this that is encoded as an integer; see (Section 10.2). If this
parameter is absent or zero then the idle timeout is disabled. parameter 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 MUST NOT be sent a sequence of 16 bytes. This transport parameter MUST NOT be sent
by a client, but MAY be sent by a server. A server that does not by a client, but MAY be sent by a server. A server that does not
send this transport parameter cannot use stateless reset send this transport parameter cannot use stateless reset
skipping to change at page 105, line 16 skipping to change at page 104, line 19
transport parameter is included if the endpoint does not support transport parameter is included if the endpoint does not support
active connection migration (Section 9). Peers of an endpoint active connection migration (Section 9). Peers of an endpoint
that sets this transport parameter MUST NOT send any packets, that sets this transport parameter MUST NOT send any packets,
including probing packets (Section 9.1), from a local address or including probing packets (Section 9.1), from a local address or
port other than that used to perform the handshake. This port other than that used to perform the handshake. This
parameter is a zero-length value. 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 shown in Figure 17. This transport parameter is only
transport parameter is only sent by a server. Servers MAY choose sent by a server. Servers MAY choose to only send a preferred
to only send a preferred address of one address family by sending address of one address family by sending an all-zero address and
an all-zero address and port (0.0.0.0:0 or ::.0) for the other port (0.0.0.0:0 or ::.0) for the other family. IP addresses are
family. IP addresses are encoded in network byte order. encoded in network byte order. The CID Length field contains the
length of the Connection ID field.
struct { 0 1 2 3
opaque ipv4Address[4]; 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
uint16 ipv4Port; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opaque ipv6Address[16]; | IPv4 Address (32) |
uint16 ipv6Port; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opaque connectionId<0..20>; | IPv4 Port (16) |
opaque statelessResetToken[16]; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
} PreferredAddress; | |
+ +
| |
+ IPv6 Address (128) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Port (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID Length (8)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection ID (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Stateless Reset Token (128) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Preferred Address format Figure 17: Preferred Address format
active_connection_id_limit (0x000e): The maximum number of active_connection_id_limit (0x000e): The maximum number of
connection IDs from the peer that an endpoint is willing to store. connection IDs from the peer that an endpoint is willing to store.
This value includes only connection IDs sent in NEW_CONNECTION_ID This value includes only connection IDs sent in NEW_CONNECTION_ID
frames. If this parameter is absent, a default of 0 is assumed. frames. If this parameter is absent, a default of 0 is assumed.
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 server-only transport parameters
reset token, or a preferred address. A server MUST treat receipt of (original_connection_id, stateless_reset_token, or
any of these transport parameters as a connection error of type preferred_address). A server MUST treat receipt of any of these
transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
19. Frame Types and Formats 19. Frame Types and Formats
As described in Section 12.4, packets contain one or more frames. As described in Section 12.4, packets contain one or more frames.
This section describes the format and semantics of the core QUIC This section describes the format and semantics of the core QUIC
frame types. frame types.
19.1. PADDING Frame 19.1. PADDING Frame
skipping to change at page 107, line 41 skipping to change at page 107, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Range Count (i) ... | ACK Range Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First ACK Range (i) ... | First ACK Range (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Ranges (*) ... | ACK Ranges (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ECN Counts] ... | [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 representing the time delta in ACK Delay: A variable-length integer representing the time delta in
skipping to change at page 109, line 23 skipping to change at page 109, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ACK Range (i)] ... | [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap (i)] ... | [Gap (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ACK Range (i)] ... | [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: ACK Ranges Figure 19: ACK Ranges
The fields that form the ACK Ranges are: The fields that form the ACK Ranges are:
Gap (repeated): A variable-length integer indicating the number of Gap (repeated): A variable-length integer indicating the number of
contiguous unacknowledged packets preceding the packet number one contiguous unacknowledged packets preceding the packet number one
lower than the smallest in the preceding ACK Range. lower than the smallest in the preceding ACK Range.
ACK Range (repeated): A variable-length integer indicating the ACK Range (repeated): A variable-length integer indicating the
number of contiguous acknowledged packets preceding the largest number of contiguous acknowledged packets preceding the largest
packet number, as determined by the preceding Gap. packet number, as determined by the preceding Gap.
skipping to change at page 110, line 18 skipping to change at page 110, line 18
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 subsequent ACK Range using the following formula: value for the subsequent ACK Range using the following formula:
largest = previous_smallest - gap - 2 largest = previous_smallest - gap - 2
If any computed packet number is negative, an endpoint MUST generate If any computed packet number is negative, an endpoint MUST generate
a connection error of type FRAME_ENCODING_ERROR indicating an error a connection error of type FRAME_ENCODING_ERROR.
in an ACK frame.
19.3.2. ECN Counts 19.3.2. ECN Counts
The ACK frame uses the least significant bit (that is, type 0x03) to The ACK frame uses the least significant bit (that is, type 0x03) to
indicate ECN feedback and report receipt of QUIC packets with 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 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. header. ECN Counts are only present when the ACK frame type is 0x03.
ECN Counts are only parsed when the ACK frame type is 0x03. There ECN Counts are only parsed when the ACK frame type is 0x03. There
are 3 ECN counts, as follows: are 3 ECN counts, as follows:
skipping to change at page 113, line 15 skipping to change at page 112, line 49
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.
There is a separate flow of cryptographic handshake data in each There is a separate flow of cryptographic handshake data in each
encryption level, each of which starts at an offset of 0. This encryption level, each of which starts at an offset of 0. This
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.
The largest offset delivered on a stream - the sum of the offset and
data length - cannot exceed 2^62-1. Receipt of a frame that exceeds
this limit MUST be treated as a connection error of type
FRAME_ENCODING_ERROR.
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 server sends a NEW_TOKEN frame (type=0x07) to provide the client
with a token to send in the header of an Initial packet for a future with a token to send in the header of an Initial packet for a future
connection. connection.
skipping to change at page 114, line 4 skipping to change at page 113, line 43
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 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW_TOKEN frames contain the following fields: NEW_TOKEN frames contain the following fields:
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
token in bytes. token in bytes.
Token: An opaque blob that the client may use with a future Initial Token: An opaque blob that the client may use with a future Initial
packet. packet. The token MUST NOT be empty. An endpoint MUST treat
receipt of a NEW_TOKEN frame with an empty Token field as a
connection error of type FRAME_ENCODING_ERROR.
An endpoint might receive multiple NEW_TOKEN frames that contain the An endpoint might receive multiple NEW_TOKEN frames that contain the
same token value. Endpoints are responsible for discarding duplicate same token value. Endpoints are responsible for discarding duplicate
values, which might be used to link connection attempts; see values, which might be used to link connection attempts; see
Section 8.1.2. Section 8.1.2.
Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt
of a NEW_TOKEN frame as a connection error of type of a NEW_TOKEN frame as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
skipping to change at page 115, line 17 skipping to change at page 115, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 115, line 43 skipping to change at page 115, line 43
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 offset and data length - delivered on a stream - the sum of the offset and data length -
cannot exceed 2^62-1, as it is not possible to provide flow control cannot exceed 2^62-1, as it is not possible to provide flow control
credit for that data. Receipt of a frame that exceeds this limit credit for that data. Receipt of a frame that exceeds this limit
will be treated as a connection error of type FLOW_CONTROL_ERROR. MUST be treated as a connection error of type FRAME_ENCODING_ERROR or
FLOW_CONTROL_ERROR.
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 117, line 43 skipping to change at page 117, line 43
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Streams (i) ... | Maximum Streams (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAX_STREAMS frames contain the following fields: MAX_STREAMS frames contain the following fields:
Maximum Streams: A count of the cumulative number of streams of the Maximum Streams: A count of the cumulative number of streams of the
corresponding type that can be opened over the lifetime of the corresponding type that can be opened over the lifetime of the
connection. connection. Stream IDs cannot exceed 2^62-1, as it is not
possible to encode stream IDs larger than this value. Receipt of
a frame that permits opening of a stream larger than this limit
MUST be treated as a FRAME_ENCODING_ERROR.
Loss or reordering can cause a MAX_STREAMS frame to be received which Loss or reordering can cause a MAX_STREAMS frame to be received which
states a lower stream limit than an endpoint has previously received. states a lower stream limit than an endpoint has previously received.
MAX_STREAMS frames which do not increase the stream limit MUST be MAX_STREAMS frames which do not increase the stream limit MUST be
ignored. ignored.
An endpoint MUST NOT open more streams than permitted by the current An endpoint MUST NOT open more streams than permitted by the current
stream limit set by its peer. For instance, a server that receives a stream limit set by its peer. For instance, a server that receives a
unidirectional stream limit of 3 is permitted to open stream 3, 7, unidirectional stream limit of 3 is permitted to open stream 3, 7,
and 11, but not stream 15. An endpoint MUST terminate a connection and 11, but not stream 15. An endpoint MUST terminate a connection
skipping to change at page 119, line 36 skipping to change at page 119, line 45
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 Limit (i) ... | Stream Limit (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
STREAMS_BLOCKED frames contain the following fields: STREAMS_BLOCKED frames contain the following fields:
Stream Limit: A variable-length integer indicating the stream limit Stream Limit: A variable-length integer indicating the stream limit
at the time the frame was sent. at the time the frame was sent. Stream IDs cannot exceed 2^62-1,
as it is not possible to encode stream IDs larger than this value.
Receipt of a frame that encodes a larger stream ID MUST be treated
as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR.
19.15. NEW_CONNECTION_ID Frame 19.15. NEW_CONNECTION_ID Frame
An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide
its peer with alternative connection IDs that can be used to break its peer with alternative connection IDs that can be used to break
linkability when migrating connections (see Section 9.5). linkability when migrating connections (see Section 9.5).
The NEW_CONNECTION_ID frame is as follows: The NEW_CONNECTION_ID frame is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 120, line 36 skipping to change at page 120, line 44
Sequence Number: The sequence number assigned to the connection ID Sequence Number: The sequence number assigned to the connection ID
by the sender. See Section 5.1.1. by the sender. See Section 5.1.1.
Retire Prior To: A variable-length integer indicating which Retire Prior To: A variable-length integer indicating which
connection IDs should be retired. See Section 5.1.2. connection IDs should be retired. See Section 5.1.2.
Length: An 8-bit unsigned integer containing the length of the Length: An 8-bit unsigned integer containing the length of the
connection ID. Values less than 1 and greater than 20 are invalid connection ID. Values less than 1 and greater than 20 are invalid
and MUST be treated as a connection error of type and MUST be treated as a connection error of type
PROTOCOL_VIOLATION. FRAME_ENCODING_ERROR.
Connection ID: A connection ID of the specified length. Connection ID: A connection ID of the specified length.
Stateless Reset Token: A 128-bit value that will be used for a Stateless Reset Token: A 128-bit value that will be used for a
stateless reset when the associated connection ID is used (see stateless reset when the associated connection ID is used (see
Section 10.4). Section 10.4).
An endpoint MUST NOT send this frame if it currently requires that An endpoint MUST NOT send this frame if it currently requires that
its peer send packets with a zero-length Destination Connection ID. its peer send packets with a zero-length Destination Connection ID.
Changing the length of a connection ID to or from zero-length makes Changing the length of a connection ID to or from zero-length makes
skipping to change at page 121, line 26 skipping to change at page 121, line 34
The Retire Prior To field is a request for the peer to retire all The Retire Prior To field is a request for the peer to retire all
connection IDs with a sequence number less than the specified value. connection IDs with a sequence number less than the specified value.
This includes the initial and preferred_address transport parameter This includes the initial and preferred_address transport parameter
connection IDs. The peer SHOULD retire the corresponding connection connection IDs. The peer SHOULD retire the corresponding connection
IDs and send the corresponding RETIRE_CONNECTION_ID frames in a IDs and send the corresponding RETIRE_CONNECTION_ID frames in a
timely manner. timely manner.
The Retire Prior To field MUST be less than or equal to the Sequence The Retire Prior To field MUST be less than or equal to the Sequence
Number field. Receiving a value greater than the Sequence Number Number field. Receiving a value greater than the Sequence Number
MUST be treated as a connection error of type PROTOCOL_VIOLATION. MUST be treated as a connection error of type FRAME_ENCODING_ERROR.
Once a sender indicates a Retire Prior To value, smaller values sent Once a sender indicates a Retire Prior To value, smaller values sent
in subsequent NEW_CONNECTION_ID frames have no effect. A receiver in subsequent NEW_CONNECTION_ID frames have no effect. A receiver
MUST ignore any Retire Prior To fields that do not increase the MUST ignore any Retire Prior To fields that do not increase the
largest received Retire Prior To value. largest received Retire Prior To value.
19.16. RETIRE_CONNECTION_ID Frame 19.16. RETIRE_CONNECTION_ID Frame
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to
indicate that it will no longer use a connection ID that was issued indicate that it will no longer use a connection ID that was issued
skipping to change at page 122, line 4 skipping to change at page 122, line 12
Retiring a connection ID invalidates the stateless reset token Retiring a connection ID invalidates the stateless reset token
associated with that connection ID. associated with that connection ID.
The RETIRE_CONNECTION_ID frame is as follows: The RETIRE_CONNECTION_ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (i) ... | Sequence Number (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RETIRE_CONNECTION_ID frames contain the following fields: RETIRE_CONNECTION_ID frames contain the following fields:
Sequence Number: The sequence number of the connection ID being Sequence Number: The sequence number of the connection ID being
retired. See Section 5.1.2. retired. See Section 5.1.2.
Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number
greater than any previously sent to the peer MAY be treated as a greater than any previously sent to the peer MAY be treated as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
The sequence number specified in a RETIRE_CONNECTION_ID frame MUST The sequence number specified in a RETIRE_CONNECTION_ID frame MUST
NOT refer to the Destination Connection ID field of the packet in NOT refer to the Destination Connection ID field of the packet in
which the frame is contained. The peer MAY treat this as a which the frame is contained. The peer MAY treat this as a
connection error of type PROTOCOL_VIOLATION. connection error of type FRAME_ENCODING_ERROR.
An endpoint cannot send this frame if it was provided with a zero- An endpoint cannot send this frame if it was provided with a zero-
length connection ID by its peer. An endpoint that provides a zero- length connection ID by its peer. An endpoint that provides a zero-
length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID
frame as a connection error of type PROTOCOL_VIOLATION. frame as a connection error of type PROTOCOL_VIOLATION.
19.17. PATH_CHALLENGE Frame 19.17. PATH_CHALLENGE Frame
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
skipping to change at page 136, line 14 skipping to change at page 136, line 14
23.1. Normative References 23.1. Normative References
[DPLPMTUD] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08
(work in progress), June 2019. (work in progress), June 2019.
[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-23 (work and Congestion Control", draft-ietf-quic-recovery-24 (work
in progress), September 2019. in progress), November 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-23 (work in progress), September 2019. tls-24 (work in progress), November 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 137, line 50 skipping to change at page 137, line 50
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-07 (work in progress), draft-ietf-quic-invariants-07 (work in progress), November
September 2019. 2019.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-05 Transport Protocol", draft-ietf-quic-manageability-05
(work in progress), July 2019. (work in progress), July 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>.
skipping to change at page 140, line 12 skipping to change at page 140, line 12
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-22 B.1. Since draft-ietf-quic-transport-23
o Client Initial size constraints apply to UDP datagram payload
(#3053, #3051)
o Stateless reset changes (#2152, #2993)
* tokens need to be compared in constant time
* detection uses UDP datagrams, not packets
* tokens cannot be reused (#2785, #2968)
o Clearer rules for sharing of UDP ports and use of connection IDs
when doing so (#2844, #2851)
o A new connection ID is necessary when responding to migration
(#2778, #2969)
o Stronger requirements for connection ID retirement (#3046, #3096)
o NEW_TOKEN cannot be empty (#2978, #2977)
o PING can be sent at any encryption level (#3034, #3035)
o CONNECTION_CLOSE is not ack-eliciting (#3097, #3098)
o Frame encoding error conditions updated (#3027, #3042)
o Non-ack-eliciting packets cannot be sent in response to non-ack-
eliciting packets (#3100, #3104)
B.2. Since draft-ietf-quic-transport-22
o Rules for preventing correlation by connection ID tightened o Rules for preventing correlation by connection ID tightened
(#2084, #2929) (#2084, #2929)
o Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, o Clarified use of CONNECTION_CLOSE in Handshake packets (#2151,
#2541, #2688) #2541, #2688)
o Discourage regressions of largest acknowledged in ACK (#2205, o Discourage regressions of largest acknowledged in ACK (#2205,
#2752) #2752)
o Improved robusness of validation process for ECN counts (#2534, o Improved robustness of validation process for ECN counts (#2534,
#2752) #2752)
o Require endpoints to ignore spurious migration attempts (#2342, o Require endpoints to ignore spurious migration attempts (#2342,
#2893) #2893)
o Transport parameter for disabling migration clarified to allow NAT o Transport parameter for disabling migration clarified to allow NAT
rebinding (#2389, #2893) rebinding (#2389, #2893)
o Document principles for defining new error codes (#2388, #2880) o Document principles for defining new error codes (#2388, #2880)
skipping to change at page 140, line 46 skipping to change at page 141, line 31
o A maximum ACK delay of 0 is used for handshake packet number o A maximum ACK delay of 0 is used for handshake packet number
spaces (#2646, #2638) spaces (#2646, #2638)
o Improved rules for use of congestion control state on new paths o Improved rules for use of congestion control state on new paths
(#2685, #2918) (#2685, #2918)
o Removed recommendation to coordinate spin for multiple connections o Removed recommendation to coordinate spin for multiple connections
that share a path (#2763, #2882) that share a path (#2763, #2882)
o Allow smaller stateless resets and recommend a smaller minimum on o Allow smaller stateless resets and recommend a smaller minimum on
packets that might trigger a stateless reset (#2770, #2869, #2927) packets that might trigger a stateless reset (#2770, #2869, #2927,
#3007).
o Provide guidance around the interface to QUIC as used by o Provide guidance around the interface to QUIC as used by
application protocols (#2805, #2857) application protocols (#2805, #2857)
o Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825, o Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825,
#2826) #2826)
o Tighter rules about processing of rejected 0-RTT packets (#2829, o Tighter rules about processing of rejected 0-RTT packets (#2829,
#2840, #2841) #2840, #2841)
o Explanation of the effect of Retry on 0-RTT packets (#2842, #2852) o Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)
o Cryptographic handshake needs to provide server transport o Cryptographic handshake needs to provide server transport
parameter encryption (#2920, #2921) parameter encryption (#2920, #2921)
o Moved ACK generation guidance from recovery draft to transport o Moved ACK generation guidance from recovery draft to transport
draft (#1860, #2916). draft (#1860, #2916).
B.2. Since draft-ietf-quic-transport-21 B.3. Since draft-ietf-quic-transport-21
o Connection ID lengths are now one octet, but limited in version 1 o Connection ID lengths are now one octet, but limited in version 1
to 20 octets of length (#2736, #2749) to 20 octets of length (#2736, #2749)
B.3. Since draft-ietf-quic-transport-20 B.4. Since draft-ietf-quic-transport-20
o Error codes are encoded as variable-length integers (#2672, #2680) o Error codes are encoded as variable-length integers (#2672, #2680)
o NEW_CONNECTION_ID includes a request to retire old connection IDs o NEW_CONNECTION_ID includes a request to retire old connection IDs
(#2645, #2769) (#2645, #2769)
o Tighter rules for generating and explicitly eliciting ACK frames o Tighter rules for generating and explicitly eliciting ACK frames
(#2546, #2794) (#2546, #2794)
o Recommend having only one packet per encryption level in a o Recommend having only one packet per encryption level in a
skipping to change at page 142, line 17 skipping to change at page 143, line 5
o PATH_RESPONSE no longer needs to be received on the validated path o PATH_RESPONSE no longer needs to be received on the validated path
(#2582, #2580, #2579, #2637) (#2582, #2580, #2579, #2637)
o PATH_RESPONSE frames are not stored and retransmitted (#2724, o PATH_RESPONSE frames are not stored and retransmitted (#2724,
#2729) #2729)
o Document hack for enabling routing of ICMP when doing PMTU probing o Document hack for enabling routing of ICMP when doing PMTU probing
(#1243, #2402) (#1243, #2402)
B.4. Since draft-ietf-quic-transport-19 B.5. Since draft-ietf-quic-transport-19
o Refine discussion of 0-RTT transport parameters (#2467, #2464) o Refine discussion of 0-RTT transport parameters (#2467, #2464)
o Fewer transport parameters need to be remembered for 0-RTT (#2624, o Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467) #2467)
o Spin bit text incorporated (#2564) o Spin bit text incorporated (#2564)
o Close the connection when maximum stream ID in MAX_STREAMS exceeds o Close the connection when maximum stream ID in MAX_STREAMS exceeds
2^62 - 1 (#2499, #2487) 2^62 - 1 (#2499, #2487)
skipping to change at page 142, line 44 skipping to change at page 143, line 32
o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
o Initial packets from clients need to be padded to 1200 unless a o Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523) Handshake packet is sent as well (#2522, #2523)
o CRYPTO frames can be discarded if too much data is buffered o CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524) (#1834, #2524)
o Stateless reset uses a short header packet (#2599, #2600) o Stateless reset uses a short header packet (#2599, #2600)
B.5. Since draft-ietf-quic-transport-18 B.6. Since draft-ietf-quic-transport-18
o Removed version negotiation; version negotiation, including o Removed version negotiation; version negotiation, including
authentication of the result, will be addressed in the next authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313) version of QUIC (#1773, #2313)
o Added discussion of the use of IPv6 flow labels (#2348, #2399) o Added discussion of the use of IPv6 flow labels (#2348, #2399)
o A connection ID can't be retired in a packet that uses that o A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420) connection ID (#2101, #2420)
o Idle timeout transport parameter is in milliseconds (from seconds) o Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454) (#2453, #2454)
o Endpoints are required to use new connection IDs when they use new o Endpoints are required to use new connection IDs when they use new
network paths (#2413, #2414) network paths (#2413, #2414)
o Increased the set of permissible frames in 0-RTT (#2344, #2355) o Increased the set of permissible frames in 0-RTT (#2344, #2355)
B.6. Since draft-ietf-quic-transport-17 B.7. Since draft-ietf-quic-transport-17
o Stream-related errors now use STREAM_STATE_ERROR (#2305) o Stream-related errors now use STREAM_STATE_ERROR (#2305)
o Endpoints discard initial keys as soon as handshake keys are o Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
o Expanded conditions for ignoring ICMP packet too big messages o Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161) (#2108, #2161)
o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
skipping to change at page 144, line 7 skipping to change at page 144, line 44
#2301) #2301)
o Allow server preferred address for both IPv4 and IPv6 (#2122, o Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
o Corrected requirements for migration to a preferred address o Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
o ACK of non-existent packet is illegal (#2298, #2302) o ACK of non-existent packet is illegal (#2298, #2302)
B.7. Since draft-ietf-quic-transport-16 B.8. 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)
skipping to change at page 145, line 4 skipping to change at page 145, line 41
#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 available (#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.8. Since draft-ietf-quic-transport-15 B.9. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.9. Since draft-ietf-quic-transport-14 B.10. 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.10. Since draft-ietf-quic-transport-13 B.11. 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 146, line 12 skipping to change at page 147, line 4
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.11. Since draft-ietf-quic-transport-12 B.12. 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 147, line 20 skipping to change at page 148, line 14
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.12. Since draft-ietf-quic-transport-11 B.13. 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.13. Since draft-ietf-quic-transport-10 B.14. 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 148, line 4 skipping to change at page 148, line 45
o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
o A more complete connection migration (#1249) o A more complete connection migration (#1249)
o Refine opportunistic ACK defense text (#305, #1030, #1185) o Refine opportunistic ACK defense text (#305, #1030, #1185)
o A Stateless Reset Token isn't mandatory (#818, #1191) o A Stateless Reset Token isn't mandatory (#818, #1191)
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.14. Since draft-ietf-quic-transport-09 B.15. 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 148, line 47 skipping to change at page 149, line 39
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.15. Since draft-ietf-quic-transport-08 B.16. 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)
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.16. Since draft-ietf-quic-transport-07 B.17. 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 150, line 25 skipping to change at page 151, line 15
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.17. Since draft-ietf-quic-transport-06 B.18. 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.18. Since draft-ietf-quic-transport-05 B.19. 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.19. Since draft-ietf-quic-transport-04 B.20. 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 151, line 42 skipping to change at page 152, line 34
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.20. Since draft-ietf-quic-transport-03 B.21. 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.21. Since draft-ietf-quic-transport-02 B.22. 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 153, line 5 skipping to change at page 153, line 37
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.22. Since draft-ietf-quic-transport-01 B.23. 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 155, line 5 skipping to change at page 155, line 36
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.23. Since draft-ietf-quic-transport-00 B.24. 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.24. Since draft-hamilton-quic-transport-protocol-01 B.25. 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.
 End of changes. 131 change blocks. 
330 lines changed or deleted 422 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/