draft-ietf-quic-transport-31.txt   draft-ietf-quic-transport-32.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: 29 March 2021 Mozilla Expires: 23 April 2021 Mozilla
25 September 2020 20 October 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-31 draft-ietf-quic-transport-32
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 29 March 2021. This Internet-Draft will expire on 23 April 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 26 skipping to change at page 3, line 26
8.1.4. Address Validation Token Integrity . . . . . . . . . 54 8.1.4. Address Validation Token Integrity . . . . . . . . . 54
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 55 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 55
8.2.1. Initiating Path Validation . . . . . . . . . . . . . 56 8.2.1. Initiating Path Validation . . . . . . . . . . . . . 56
8.2.2. Path Validation Responses . . . . . . . . . . . . . . 57 8.2.2. Path Validation Responses . . . . . . . . . . . . . . 57
8.2.3. Successful Path Validation . . . . . . . . . . . . . 57 8.2.3. Successful Path Validation . . . . . . . . . . . . . 57
8.2.4. Failed Path Validation . . . . . . . . . . . . . . . 57 8.2.4. Failed Path Validation . . . . . . . . . . . . . . . 57
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 58 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 58
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 59 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 59
9.2. Initiating Connection Migration . . . . . . . . . . . . . 59 9.2. Initiating Connection Migration . . . . . . . . . . . . . 59
9.3. Responding to Connection Migration . . . . . . . . . . . 60 9.3. Responding to Connection Migration . . . . . . . . . . . 60
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 60 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 61
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 61 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 61
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 61 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 62
9.4. Loss Detection and Congestion Control . . . . . . . . . . 62 9.4. Loss Detection and Congestion Control . . . . . . . . . . 63
9.5. Privacy Implications of Connection Migration . . . . . . 63 9.5. Privacy Implications of Connection Migration . . . . . . 64
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 65 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 65
9.6.1. Communicating a Preferred Address . . . . . . . . . . 65 9.6.1. Communicating a Preferred Address . . . . . . . . . . 66
9.6.2. Migration to a Preferred Address . . . . . . . . . . 66 9.6.2. Migration to a Preferred Address . . . . . . . . . . 66
9.6.3. Interaction of Client Migration and Preferred 9.6.3. Interaction of Client Migration and Preferred
Address . . . . . . . . . . . . . . . . . . . . . . . 66 Address . . . . . . . . . . . . . . . . . . . . . . . 67
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 67 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 68
10. Connection Termination . . . . . . . . . . . . . . . . . . . 67 10. Connection Termination . . . . . . . . . . . . . . . . . . . 68
10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 68 10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 68
10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 68 10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 69
10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 68 10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 69
10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 69 10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 70
10.2.1. Closing Connection State . . . . . . . . . . . . . . 70 10.2.1. Closing Connection State . . . . . . . . . . . . . . 71
10.2.2. Draining Connection State . . . . . . . . . . . . . 71 10.2.2. Draining Connection State . . . . . . . . . . . . . 72
10.2.3. Immediate Close During the Handshake . . . . . . . . 72 10.2.3. Immediate Close During the Handshake . . . . . . . . 72
10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 73 10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 74
10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 76 10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 76
10.3.2. Calculating a Stateless Reset Token . . . . . . . . 77 10.3.2. Calculating a Stateless Reset Token . . . . . . . . 77
10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 78 10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 78
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 78 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 79
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 79 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 79
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 79 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 80
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 80 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 80
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 80 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 81
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 81 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 82
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 82 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 83
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 83 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 84
12.5. Frames and Number Spaces . . . . . . . . . . . . . . . . 87 12.5. Frames and Number Spaces . . . . . . . . . . . . . . . . 88
13. Packetization and Reliability . . . . . . . . . . . . . . . . 87 13. Packetization and Reliability . . . . . . . . . . . . . . . . 88
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 88 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 89
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 88 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 89
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 89 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 90
13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 90 13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 91
13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 91 13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 92
13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 92 13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 93
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 92 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 93
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 93 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 94
13.2.7. PADDING Frames Consume Congestion Window . . . . . . 93 13.2.7. PADDING Frames Consume Congestion Window . . . . . . 94
13.3. Retransmission of Information . . . . . . . . . . . . . 93 13.3. Retransmission of Information . . . . . . . . . . . . . 94
13.4. Explicit Congestion Notification . . . . . . . . . . . . 96 13.4. Explicit Congestion Notification . . . . . . . . . . . . 97
13.4.1. Reporting ECN Counts . . . . . . . . . . . . . . . . 96 13.4.1. Reporting ECN Counts . . . . . . . . . . . . . . . . 97
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 97 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 98
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 99 14. Datagram Size . . . . . . . . . . . . . . . . . . . . . . . . 100
14.1. Initial Packet Size . . . . . . . . . . . . . . . . . . 100 14.1. Initial Datagram Size . . . . . . . . . . . . . . . . . 101
14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 100 14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 102
14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 101 14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 102
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 102 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 103
14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 102 14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 104
14.3.2. Validating the QUIC Path with DPLPMTUD . . . . . . . 102 14.3.2. Validating the Network Path with DPLPMTUD . . . . . 104
14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 102 14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 104
14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 103 14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 104
14.4.1. PMTU Probes Containing Source Connection ID . . . . 103 14.4.1. PMTU Probes Containing Source Connection ID . . . . 104
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 103 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 105
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 104 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 106
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 105 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 107
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 105 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 107
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 106 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 108
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 109 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 111
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 110 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 112
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 113 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 114
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 114 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 115
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 115 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 116
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 117 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 119
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 119 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 121
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 120 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 122
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 121 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 122
18.2. Transport Parameter Definitions . . . . . . . . . . . . 121 18.2. Transport Parameter Definitions . . . . . . . . . . . . 123
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 125 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 127
19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 125 19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 127
19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 126 19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 127
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 126 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 128
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 128 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 129
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 129 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 131
19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 130 19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 131
19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 131 19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 132
19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 131 19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 133
19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 132 19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 134
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 133 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 134
19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 135 19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 136
19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 135 19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 136
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 136 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 137
19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 137 19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 138
19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 138 19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 139
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 138 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 139
19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 139 19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 140
19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 140 19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 142
19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 141 19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 143
19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 142 19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 143
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 142 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 144
19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 143 19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 145
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 144 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 145
20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 144 20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 146
20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 145 20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 146
20.2. Application Protocol Error Codes . . . . . . . . . . . . 146 20.2. Application Protocol Error Codes . . . . . . . . . . . . 148
21. Security Considerations . . . . . . . . . . . . . . . . . . . 147 21. Security Considerations . . . . . . . . . . . . . . . . . . . 148
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 147 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 148
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 148 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 149
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 148 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 149
21.4. Request Forgery Attacks . . . . . . . . . . . . . . . . 148 21.4. Request Forgery Attacks . . . . . . . . . . . . . . . . 150
21.4.1. Control Options for Endpoints . . . . . . . . . . . 149 21.4.1. Control Options for Endpoints . . . . . . . . . . . 151
21.4.2. Request Forgery with Client Initial Packets . . . . 151 21.4.2. Request Forgery with Client Initial Packets . . . . 152
21.4.3. Request Forgery with Preferred Addresses . . . . . . 151 21.4.3. Request Forgery with Preferred Addresses . . . . . . 153
21.4.4. Request Forgery with Spoofed Migration . . . . . . . 152 21.4.4. Request Forgery with Spoofed Migration . . . . . . . 153
21.4.5. Generic Request Forgery Countermeasures . . . . . . 152 21.4.5. Generic Request Forgery Countermeasures . . . . . . 154
21.5. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 153 21.5. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 155
21.6. Stream Fragmentation and Reassembly Attacks . . . . . . 154 21.6. Stream Fragmentation and Reassembly Attacks . . . . . . 155
21.7. Stream Commitment Attack . . . . . . . . . . . . . . . . 154 21.7. Stream Commitment Attack . . . . . . . . . . . . . . . . 156
21.8. Peer Denial of Service . . . . . . . . . . . . . . . . . 155 21.8. Peer Denial of Service . . . . . . . . . . . . . . . . . 156
21.9. Explicit Congestion Notification Attacks . . . . . . . . 155 21.9. Explicit Congestion Notification Attacks . . . . . . . . 157
21.10. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 156 21.10. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 157
21.11. Version Downgrade . . . . . . . . . . . . . . . . . . . 156 21.11. Version Downgrade . . . . . . . . . . . . . . . . . . . 158
21.12. Targeted Attacks by Routing . . . . . . . . . . . . . . 157 21.12. Targeted Attacks by Routing . . . . . . . . . . . . . . 158
21.13. Overview of Security Properties . . . . . . . . . . . . 157 21.13. Overview of Security Properties . . . . . . . . . . . . 158
21.13.1. Handshake . . . . . . . . . . . . . . . . . . . . . 157 21.13.1. Handshake . . . . . . . . . . . . . . . . . . . . . 159
21.13.2. Protected Packets . . . . . . . . . . . . . . . . . 159 21.13.2. Protected Packets . . . . . . . . . . . . . . . . . 160
21.13.3. Connection Migration . . . . . . . . . . . . . . . 160 21.13.3. Connection Migration . . . . . . . . . . . . . . . 161
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 165
22.1. Registration Policies for QUIC Registries . . . . . . . 164 22.1. Registration Policies for QUIC Registries . . . . . . . 165
22.1.1. Provisional Registrations . . . . . . . . . . . . . 164 22.1.1. Provisional Registrations . . . . . . . . . . . . . 165
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 165 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 166
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 166 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 167
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 166 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 168
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 167 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 168
22.3. QUIC Frame Types Registry . . . . . . . . . . . . . . . 168 22.3. QUIC Frame Types Registry . . . . . . . . . . . . . . . 169
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 169 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 170
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 171 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 172
23.1. Normative References . . . . . . . . . . . . . . . . . . 171 23.1. Normative References . . . . . . . . . . . . . . . . . . 172
23.2. Informative References . . . . . . . . . . . . . . . . . 172 23.2. Informative References . . . . . . . . . . . . . . . . . 173
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 175 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 176
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 176 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 177
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 177 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 178
C.1. Since draft-ietf-quic-transport-30 . . . . . . . . . . . 177 C.1. Since draft-ietf-quic-transport-31 . . . . . . . . . . . 178
C.2. Since draft-ietf-quic-transport-29 . . . . . . . . . . . 177 C.2. Since draft-ietf-quic-transport-30 . . . . . . . . . . . 179
C.3. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 178 C.3. Since draft-ietf-quic-transport-29 . . . . . . . . . . . 179
C.4. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 178 C.4. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 179
C.5. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 180 C.5. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 180
C.6. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 180 C.6. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 181
C.7. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 180 C.7. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 181
C.8. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 181 C.8. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 181
C.9. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 182 C.9. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 182
C.10. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 183 C.10. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 183
C.11. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 183 C.11. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 184
C.12. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 184 C.12. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 184
C.13. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 184 C.13. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 185
C.14. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 185 C.14. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 186
C.15. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 186 C.15. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 186
C.16. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 187 C.16. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 187
C.17. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 187 C.17. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 188
C.18. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 187 C.18. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 188
C.19. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 188 C.19. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 188
C.20. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 189 C.20. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 189
C.21. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 189 C.21. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 190
C.22. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 190 C.22. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 190
C.23. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 191 C.23. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 191
C.24. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 191 C.24. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 192
C.25. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 192 C.25. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 192
C.26. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 192 C.26. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 193
C.27. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 193 C.27. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 194
C.28. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 193 C.28. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 194
C.29. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 194 C.29. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 195
C.30. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 194 C.30. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 195
C.31. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 196 C.31. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 196
C.32. Since draft-hamilton-quic-transport-protocol-01 . . . . . 197 C.32. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 198
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 197 C.33. Since draft-hamilton-quic-transport-protocol-01 . . . . . 198
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 198 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 200
1. Overview 1. Overview
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
* Stream multiplexing * Stream multiplexing
* Stream- and connection-level flow control * Stream- and connection-level flow control
skipping to change at page 8, line 45 skipping to change at page 8, line 45
- Section 11 provides guidance for stream and connection error - Section 11 provides guidance for stream and connection error
handling. handling.
* Packets and frames are the basic unit used by QUIC to communicate. * Packets and frames are the basic unit used by QUIC to communicate.
- Section 12 describes concepts related to packets and frames, - Section 12 describes concepts related to packets and frames,
- Section 13 defines models for the transmission, retransmission, - Section 13 defines models for the transmission, retransmission,
and acknowledgement of data, and and acknowledgement of data, and
- Section 14 specifies rules for managing the size of packets. - Section 14 specifies rules for managing the size of datagrams
carrying QUIC packets.
* Finally, encoding details of QUIC protocol elements are described * Finally, encoding details of QUIC protocol elements are described
in: in:
- Section 15 (Versions), - Section 15 (Versions),
- Section 16 (Integer Encoding), - Section 16 (Integer Encoding),
- Section 17 (Packet Headers), - Section 17 (Packet Headers),
- Section 18 (Transport Parameters), - Section 18 (Transport Parameters),
- Section 19 (Frames), and - Section 19 (Frames), and
- Section 20 (Errors). - Section 20 (Errors).
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control [QUIC-RECOVERY], and the use of TLS for key negotiation control [QUIC-RECOVERY], and the use of TLS for key negotiation
skipping to change at page 57, line 5 skipping to change at page 57, line 5
An endpoint SHOULD NOT probe a new path with packets containing a An endpoint SHOULD NOT probe a new path with packets containing a
PATH_CHALLENGE frame more frequently than it would send an Initial PATH_CHALLENGE frame more frequently than it would send an Initial
packet. This ensures that connection migration is no more load on a packet. This ensures that connection migration is no more load on a
new path than establishing a new connection. new 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.
An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame
to at least the smallest allowed maximum datagram size of 1200 bytes.
Sending UDP datagrams of this size ensures that the network path from
the endpoint to the peer can be used for QUIC; see Section 14.
8.2.2. Path Validation Responses 8.2.2. Path Validation Responses
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by
echoing the data contained in the PATH_CHALLENGE frame in a echoing the data contained in the PATH_CHALLENGE frame in a
PATH_RESPONSE frame. A PATH_RESPONSE frame does not need to be sent PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a
on the network path where the PATH_CHALLENGE was received; a packet containing a PATH_RESPONSE frame unless constrained by
PATH_RESPONSE can be sent on any network path. An endpoint MUST NOT congestion control.
delay transmission of a packet containing a PATH_RESPONSE frame
unless constrained by congestion control. A PATH_RESPONSE frame MUST be sent on the network path where the
PATH_CHALLENGE was received. This ensures that path validation by a
peer only succeeds if the path is functional in both directions.
This requirement MUST NOT be enforced by the endpoint that initiates
path validation as that would enable an attack on migration; see
Section 9.3.3.
An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame
to at least the smallest allowed maximum datagram size of 1200 bytes.
This verifies that the path is able to carry datagrams of this size
in both directions.
An endpoint MUST NOT send more than one PATH_RESPONSE frame in An endpoint MUST NOT send more than one PATH_RESPONSE frame in
response to one PATH_CHALLENGE frame; see Section 13.3. The peer is response to one PATH_CHALLENGE frame; see Section 13.3. The peer is
expected to send more PATH_CHALLENGE frames as necessary to evoke expected to send more PATH_CHALLENGE frames as necessary to evoke
additional PATH_RESPONSE frames. additional PATH_RESPONSE frames.
8.2.3. Successful Path Validation 8.2.3. Successful Path Validation
Path validation succeeds when a PATH_RESPONSE frame is received that Path validation succeeds when a PATH_RESPONSE frame is received that
contains the data that was sent in a previous PATH_CHALLENGE frame. contains the data that was sent in a previous PATH_CHALLENGE frame.
This validates the path on which the PATH_CHALLENGE was sent. A PATH_RESPONSE frame received on any network path validates the path
on which the PATH_CHALLENGE was sent.
Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE
frame is not adequate validation, since the acknowledgment can be frame is not adequate validation, since the acknowledgment can be
spoofed by a malicious peer. spoofed by a malicious peer.
8.2.4. Failed Path Validation 8.2.4. Failed Path Validation
Path validation only fails when the endpoint attempting to validate Path validation only fails when the endpoint attempting to validate
the path abandons its attempt to validate the path. the path abandons its attempt to validate the path.
skipping to change at page 85, line 44 skipping to change at page 86, line 44
| 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | |
+-------------+----------------------+---------------+------+------+ +-------------+----------------------+---------------+------+------+
| 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P | | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P |
+-------------+----------------------+---------------+------+------+ +-------------+----------------------+---------------+------+------+
| 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | | | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | |
+-------------+----------------------+---------------+------+------+ +-------------+----------------------+---------------+------+------+
| 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P | | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P |
+-------------+----------------------+---------------+------+------+ +-------------+----------------------+---------------+------+------+
| 0x1b | PATH_RESPONSE | Section 19.18 | __01 | P | | 0x1b | PATH_RESPONSE | Section 19.18 | __01 | P |
+-------------+----------------------+---------------+------+------+ +-------------+----------------------+---------------+------+------+
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | | | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N |
+-------------+----------------------+---------------+------+------+ +-------------+----------------------+---------------+------+------+
| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | |
+-------------+----------------------+---------------+------+------+ +-------------+----------------------+---------------+------+------+
Table 3: Frame Types Table 3: Frame Types
The "Pkts" column in Table 3 lists the types of packets that each The "Pkts" column in Table 3 lists the types of packets that each
frame type could appear in, indicated by the following characters: frame type could appear in, indicated by the following characters:
I: Initial (Section 17.2.2) I: Initial (Section 17.2.2)
skipping to change at page 97, line 48 skipping to change at page 98, line 48
* The endpoint monitors whether all packets sent with an ECT * The endpoint monitors whether all packets sent with an ECT
codepoint are eventually deemed lost (Section 6 of codepoint are eventually deemed lost (Section 6 of
[QUIC-RECOVERY]), indicating that ECN validation has failed. [QUIC-RECOVERY]), indicating that ECN validation has failed.
If an endpoint has cause to expect that IP packets with an ECT If an endpoint has cause to expect that IP packets with an ECT
codepoint might be dropped by a faulty network element, the endpoint codepoint might be dropped by a faulty network element, the endpoint
could set an ECT codepoint for only the first ten outgoing packets on could set an ECT codepoint for only the first ten outgoing packets on
a path, or for a period of three PTOs (see Section 6.2 of a path, or for a period of three PTOs (see Section 6.2 of
[QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints [QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints
are subsequently lost, it can disable marking on the assumption that are subsequently lost, it can disable marking on the assumption that
the marking causes in loss. the marking caused the loss.
An endpoint thus attempts to use ECN and validates this for each new An endpoint thus attempts to use ECN and validates this for each new
connection, when switching to a server's preferred address, and on connection, when switching to a server's preferred address, and on
active connection migration to a new path. Appendix B describes one active connection migration to a new path. Appendix B describes one
possible algorithm. possible algorithm.
Other methods of probing paths for ECN support are possible, as are Other methods of probing paths for ECN support are possible, as are
different marking strategies. Implementations MAY use other methods different marking strategies. Implementations MAY use other methods
defined in RFCs; see [RFC8311]. Implementations that use the ECT(1) defined in RFCs; see [RFC8311]. Implementations that use the ECT(1)
codepoint need to perform ECN validation using the reported ECT(1) codepoint need to perform ECN validation using the reported ECT(1)
skipping to change at page 99, line 28 skipping to change at page 100, line 28
Even if validation fails, an endpoint MAY revalidate ECN for the same Even if validation fails, an endpoint MAY revalidate ECN for the same
path at any later time in the connection. An endpoint could continue path at any later time in the connection. An endpoint could continue
to periodically attempt validation. to periodically attempt validation.
Upon successful validation, an endpoint MAY continue to set an ECT Upon successful validation, an endpoint MAY continue to set an ECT
codepoint in subsequent packets it sends, with the expectation that codepoint in subsequent packets it sends, with the expectation that
the path is ECN-capable. Network routing and path elements can the path is ECN-capable. Network routing and path elements can
however change mid-connection; an endpoint MUST disable ECN if however change mid-connection; an endpoint MUST disable ECN if
validation later fails. validation later fails.
14. Packet Size 14. Datagram Size
The QUIC packet size includes the QUIC header and protected payload, A UDP datagram can include one or more QUIC packets. The datagram
but not the UDP or IP headers. size refers to the total UDP payload size of a single UDP datagram
carrying QUIC packets. The datagram size includes one or more QUIC
packet headers and protected payloads, but not the UDP or IP headers.
The maximum datagram size is defined as the largest size of UDP
payload that can be sent across a network path using a single UDP
datagram.
QUIC depends upon a minimum IP packet size of at least 1280 bytes. QUIC depends upon a minimum IP packet size of at least 1280 bytes.
This is the IPv6 minimum size ([IPv6]) and is also supported by most This is the IPv6 minimum size ([IPv6]) and is also supported by most
modern IPv4 networks. Assuming the minimum IP header size, this modern IPv4 networks. Assuming the minimum IP header size of 40
results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8
bytes for IPv4. bytes, this results in a maximum datagram size of 1232 bytes for IPv6
and 1252 bytes for IPv4.
The QUIC maximum packet size is the largest size of QUIC packet that The maximum datagram size MUST be at least 1200 bytes.
can be sent across a network path using a single packet. Any maximum
packet size larger than 1200 bytes can be discovered using Path Any maximum datagram size larger than 1200 bytes can be discovered
Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1) or using Path Maximum Transmission Unit Discovery (PMTUD; see
Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see Section 14.2.1) or Datagram Packetization Layer PMTU Discovery
Section 14.3). (DPLPMTUD; see Section 14.3).
Enforcement of the max_udp_payload_size transport parameter Enforcement of the max_udp_payload_size transport parameter
(Section 18.2) might act as an additional limit on the maximum packet (Section 18.2) might act as an additional limit on the maximum
size. A sender can avoid exceeding this limit, once the value is datagram size. A sender can avoid exceeding this limit, once the
known. However, prior to learning the value of the transport value is known. However, prior to learning the value of the
parameter, endpoints risk datagrams being lost if they send packets transport parameter, endpoints risk datagrams being lost if they send
larger than the smallest allowed maximum packet size of 1200 bytes. datagrams larger than the smallest allowed maximum datagram size of
1200 bytes.
UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4
([IPv4]), the DF bit MUST be set if possible, to prevent ([IPv4]), the DF bit MUST be set if possible, to prevent
fragmentation on the path. fragmentation on the path.
14.1. Initial Packet Size Datagrams are required to be of a minimum size under some conditions.
However, the size of the datagram is not authenticated. Therefore,
an endpoint MUST NOT close a connection when it receives a datagram
that does not meet size constraints, though the endpoint MAY discard
such datagrams.
14.1. Initial Datagram Size
A client MUST expand the payload of all UDP datagrams carrying A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least the smallest allowed maximum packet size Initial packets to at least the smallest allowed maximum datagram
(1200 bytes) by adding PADDING frames to the Initial packet or by size of 1200 bytes by adding PADDING frames to the Initial packet or
coalescing the Initial packet; see Section 12.2. Sending a UDP by coalescing the Initial packet; see Section 12.2. Similarly, a
datagram of this size ensures that the network path from the client server MUST expand the payload of all UDP datagrams carrying ack-
to the server supports a reasonable Path Maximum Transmission Unit eliciting Initial packets to at least the smallest allowed maximum
(PMTU). This also helps reduce the amplitude of amplification datagram size of 1200 bytes. Sending UDP datagrams of this size
attacks caused by server responses toward an unverified client ensures that the network path supports a reasonable Path Maximum
address; see Section 8. Transmission Unit (PMTU), in both directions. Additionally, a client
that expands Initial packets helps reduce the amplitude of
amplification attacks caused by server responses toward an unverified
client address; see Section 8.
Datagrams containing Initial packets MAY exceed 1200 bytes if the Datagrams containing Initial packets MAY exceed 1200 bytes if the
client believes that the network path and peer both support the size sender believes that the network path and peer both support the size
that it chooses. that it chooses.
A server MUST discard an Initial packet that is carried in a UDP A server MUST discard an Initial packet that is carried in a UDP
datagram with a payload that is less than the smallest allowed datagram with a payload that is smaller than the smallest allowed
maximum packet size of 1200 bytes. A server MAY also immediately maximum datagram size of 1200 bytes. A server MAY also immediately
close the connection by sending a CONNECTION_CLOSE frame with an close the connection by sending a CONNECTION_CLOSE frame with an
error code of PROTOCOL_VIOLATION; see Section 10.2.3. error code of PROTOCOL_VIOLATION; see Section 10.2.3.
The server MUST also limit the number of bytes it sends before The server MUST also limit the number of bytes it sends before
validating the address of the client; see Section 8. validating the address of the client; see Section 8.
14.2. Path Maximum Transmission Unit 14.2. Path Maximum Transmission Unit
The Path Maximum Transmission Unit (PMTU) is the maximum size of the The Path Maximum Transmission Unit (PMTU) is the maximum size of the
entire IP packet including the IP header, UDP header, and UDP entire IP packet including the IP header, UDP header, and UDP
payload. The UDP payload includes the QUIC packet header, protected payload. The UDP payload includes one or more QUIC packet headers
payload, and any authentication fields. The PMTU can depend on path and protected payloads. The PMTU can depend on path characteristics,
characteristics, and can therefore change over time. The largest UDP and can therefore change over time. The largest UDP payload an
payload an endpoint sends at any given time is referred to as the endpoint sends at any given time is referred to as the endpoint's
endpoint's maximum packet size. maximum datagram size.
An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD
(Section 14.2.1) to determine whether the path to a destination will (Section 14.2.1) to determine whether the path to a destination will
support a desired maximum packet size without fragmentation. In the support a desired maximum datagram size without fragmentation. In
absence of these mechanisms, QUIC endpoints SHOULD NOT send IP the absence of these mechanisms, QUIC endpoints SHOULD NOT send
packets larger than the smallest allowed maximum packet size. datagrams larger than the smallest allowed maximum datagram size.
Both DPLPMTUD and PMTUD send IP packets that are larger than the Both DPLPMTUD and PMTUD send datagrams that are larger than the
current maximum packet size, referred to as PMTU probes. All QUIC current maximum datagram size, referred to as PMTU probes. All QUIC
packets that are not sent in a PMTU probe SHOULD be sized to fit packets that are not sent in a PMTU probe SHOULD be sized to fit
within the maximum packet size to avoid the packet being fragmented within the maximum datagram size to avoid the datagram being
or dropped ([RFC8085]). fragmented or dropped ([RFC8085]).
If a QUIC endpoint determines that the PMTU between any pair of local If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses has fallen below the smallest allowed maximum and remote IP addresses has fallen below the smallest allowed maximum
packet size of 1200 bytes, it MUST immediately cease sending QUIC datagram size of 1200 bytes, it MUST immediately cease sending QUIC
packets, except for those in PMTU probes or those containing packets, except for those in PMTU probes or those containing
CONNECTION_CLOSE frames, on the affected path. An endpoint MAY CONNECTION_CLOSE frames, on the affected path. An endpoint MAY
terminate the connection if an alternative path cannot be found. terminate the connection if an alternative path cannot be found.
Each pair of local and remote addresses could have a different PMTU. Each pair of local and remote addresses could have a different PMTU.
QUIC implementations that implement any kind of PMTU discovery QUIC implementations that implement any kind of PMTU discovery
therefore SHOULD maintain a maximum packet size for each combination therefore SHOULD maintain a maximum datagram size for each
of local and remote IP addresses. combination of local and remote IP addresses.
A QUIC implementation MAY be more conservative in computing the A QUIC implementation MAY be more conservative in computing the
maximum packet size to allow for unknown tunnel overheads or IP maximum datagram size to allow for unknown tunnel overheads or IP
header options/extensions. header options/extensions.
14.2.1. Handling of ICMP Messages by PMTUD 14.2.1. Handling of ICMP Messages by PMTUD
Path Maximum Transmission Unit Discovery (PMTUD; [RFC1191], Path Maximum Transmission Unit Discovery (PMTUD; [RFC1191],
[RFC8201]) relies on reception of ICMP messages (e.g., IPv6 Packet [RFC8201]) relies on reception of ICMP messages (e.g., IPv6 Packet
Too Big messages) that indicate when a packet is dropped because it Too Big messages) that indicate when an IP packet is dropped because
is larger than the local router MTU. DPLPMTUD can also optionally it is larger than the local router MTU. DPLPMTUD can also optionally
use these messages. This use of ICMP messages is potentially use these messages. This use of ICMP messages is potentially
vulnerable to off-path attacks that successfully guess the addresses vulnerable to off-path attacks that successfully guess the addresses
used on the path and reduce the PMTU to a bandwidth-inefficient used on the path and reduce the PMTU to a bandwidth-inefficient
value. value.
An endpoint MUST ignore an ICMP message that claims the PMTU has An endpoint MUST ignore an ICMP message that claims the PMTU has
decreased below the minimum QUIC packet size. decreased below QUIC's smallest allowed maximum datagram size.
The requirements for generating ICMP ([RFC1812], [RFC4443]) state The requirements for generating ICMP ([RFC1812], [RFC4443]) state
that the quoted packet should contain as much of the original packet that the quoted packet should contain as much of the original packet
as possible without exceeding the minimum MTU for the IP version. as possible without exceeding the minimum MTU for the IP version.
The size of the quoted packet can actually be smaller, or the The size of the quoted packet can actually be smaller, or the
information unintelligible, as described in Section 1.1 of information unintelligible, as described in Section 1.1 of
[DPLPMTUD]. [DPLPMTUD].
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
from off-path injection as specified in [RFC8201] and Section 5.2 of from off-path injection as specified in [RFC8201] and Section 5.2 of
skipping to change at page 102, line 4 skipping to change at page 103, line 20
as possible without exceeding the minimum MTU for the IP version. as possible without exceeding the minimum MTU for the IP version.
The size of the quoted packet can actually be smaller, or the The size of the quoted packet can actually be smaller, or the
information unintelligible, as described in Section 1.1 of information unintelligible, as described in Section 1.1 of
[DPLPMTUD]. [DPLPMTUD].
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
from off-path injection as specified in [RFC8201] and Section 5.2 of from off-path injection as specified in [RFC8201] and Section 5.2 of
[RFC8085]. This validation SHOULD use the quoted packet supplied in [RFC8085]. This validation SHOULD use the quoted packet supplied in
the payload of an ICMP message to associate the message with a the payload of an ICMP message to associate the message with a
corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]).
ICMP message validation MUST include matching IP addresses and UDP ICMP message validation MUST include matching IP addresses and UDP
ports ([RFC8085]) and, when possible, connection IDs to an active ports ([RFC8085]) and, when possible, connection IDs to an active
QUIC session. The endpoint SHOULD ignore all ICMP messages that fail QUIC session. The endpoint SHOULD ignore all ICMP messages that fail
validation. validation.
An endpoint MUST NOT increase PMTU based on ICMP messages; see An endpoint MUST NOT increase PMTU based on ICMP messages; see
Section 3, clause 6 of [DPLPMTUD]. Any reduction in the QUIC maximum Section 3, clause 6 of [DPLPMTUD]. Any reduction in QUIC's maximum
packet size in response to ICMP messages MAY be provisional until datagram size in response to ICMP messages MAY be provisional until
QUIC's loss detection algorithm determines that the quoted packet has QUIC's loss detection algorithm determines that the quoted packet has
actually been lost. actually been lost.
14.3. Datagram Packetization Layer PMTU Discovery 14.3. Datagram Packetization Layer PMTU Discovery
Datagram Packetization Layer PMTU Discovery (DPLPMTUD; [DPLPMTUD]) Datagram Packetization Layer PMTU Discovery (DPLPMTUD; [DPLPMTUD])
relies on tracking loss or acknowledgment of QUIC packets that are relies on tracking loss or acknowledgment of QUIC packets that are
carried in PMTU probes. PMTU probes for DPLPMTUD that use the carried in PMTU probes. PMTU probes for DPLPMTUD that use the
PADDING frame implement "Probing using padding data", as defined in PADDING frame implement "Probing using padding data", as defined in
Section 4.1 of [DPLPMTUD]. Section 4.1 of [DPLPMTUD].
Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1 Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of
of [DPLPMTUD]) to be consistent with the minimum QUIC packet size. [DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum
The MIN_PLPMTU is the same as the BASE_PMTU. datagram size. The MIN_PLPMTU is the same as the BASE_PLPMTU.
QUIC endpoints implementing DPLPMTUD maintain a maximum packet size QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum
(DPLPMTUD MPS) for each combination of local and remote IP addresses. Packet Size (MPS, Section 4.4 of [DPLPMTUD]) for each combination of
local and remote IP addresses. This corresponds to the maximum
datagram size.
14.3.1. DPLPMTUD and Initial Connectivity 14.3.1. DPLPMTUD and Initial Connectivity
From the perspective of DPLPMTUD, QUIC is an acknowledged From the perspective of DPLPMTUD, QUIC is an acknowledged
packetization layer (PL). A sender can therefore enter the DPLPMTUD Packetization Layer (PL). A QUIC sender can therefore enter the
BASE state when the QUIC connection handshake has been completed. DPLPMTUD BASE state (Section 5.2 of [DPLPMTUD]) when the QUIC
connection handshake has been completed.
14.3.2. Validating the QUIC Path with DPLPMTUD 14.3.2. Validating the Network Path with DPLPMTUD
QUIC provides an acknowledged PL, therefore a sender does not QUIC is an acknowledged PL, therefore a QUIC sender does not
implement the DPLPMTUD CONFIRMATION_TIMER while in the implement a DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE
SEARCH_COMPLETE state; see Section 5.2 of [DPLPMTUD]. state; see Section 5.2 of [DPLPMTUD].
14.3.3. Handling of ICMP Messages by DPLPMTUD 14.3.3. Handling of ICMP Messages by DPLPMTUD
An endpoint using DPLPMTUD requires the validation of any received An endpoint using DPLPMTUD requires the validation of any received
ICMP Packet Too Big (PTB) message before using the PTB information, ICMP Packet Too Big (PTB) message before using the PTB information,
as defined in Section 4.6 of [DPLPMTUD]. In addition to UDP port as defined in Section 4.6 of [DPLPMTUD]. In addition to UDP port
validation, QUIC validates an ICMP message by using other PL validation, QUIC validates an ICMP message by using other PL
information (e.g., validation of connection IDs in the quoted packet information (e.g., validation of connection IDs in the quoted packet
of any received ICMP message). of any received ICMP message).
The considerations for processing ICMP messages described in The considerations for processing ICMP messages described in
Section 14.2.1 also apply if these messages are used by DPLPMTUD. Section 14.2.1 also apply if these messages are used by DPLPMTUD.
14.4. Sending QUIC PMTU Probes 14.4. Sending QUIC PMTU Probes
PMTU probes are ack-eliciting packets. PMTU probes are ack-eliciting packets.
Endpoints could limit the content of PMTU probes to PING and PADDING Endpoints could limit the content of PMTU probes to PING and PADDING
frames as packets that are larger than the current maximum packet frames, since packets that are larger than the current maximum
size are more likely to be dropped by the network. Loss of a QUIC datagram size are more likely to be dropped by the network. Loss of
packet that is carried in a PMTU probe is therefore not a reliable a QUIC packet that is carried in a PMTU probe is therefore not a
indication of congestion and SHOULD NOT trigger a congestion control reliable indication of congestion and SHOULD NOT trigger a congestion
reaction; see Section 3, Bullet 7 of [DPLPMTUD]. However, PMTU control reaction; see Section 3, Bullet 7 of [DPLPMTUD]. However,
probes consume congestion window, which could delay subsequent PMTU probes consume congestion window, which could delay subsequent
transmission by an application. transmission by an application.
14.4.1. PMTU Probes Containing Source Connection ID 14.4.1. PMTU Probes Containing Source Connection ID
Endpoints that rely on the destination connection ID for routing Endpoints that rely on the destination connection ID for routing
incoming QUIC packets are likely to require that the connection ID be incoming QUIC packets are likely to require that the connection ID be
included in PMTU probes to route any resulting ICMP messages included in PMTU probes to route any resulting ICMP messages
(Section 14.2.1) back to the correct endpoint. However, only long (Section 14.2.1) back to the correct endpoint. However, only long
header packets (Section 17.2) contain the Source Connection ID field, header packets (Section 17.2) contain the Source Connection ID field,
and long header packets are not decrypted or acknowledged by the peer and long header packets are not decrypted or acknowledged by the peer
skipping to change at page 110, line 4 skipping to change at page 111, line 30
Version Negotiation Packet { Version Negotiation Packet {
Header Form (1) = 1, Header Form (1) = 1,
Unused (7), Unused (7),
Version (32) = 0, Version (32) = 0,
Destination Connection ID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..2040), Destination Connection ID (0..2040),
Source Connection ID Length (8), Source Connection ID Length (8),
Source Connection ID (0..2040), Source Connection ID (0..2040),
Supported Version (32) ..., Supported Version (32) ...,
} }
Figure 14: Version Negotiation Packet Figure 14: Version Negotiation Packet
The value in the Unused field is selected randomly by the server. The value in the Unused field is selected randomly by the server.
Clients MUST ignore the value of this field. Servers SHOULD set the Clients MUST ignore the value of this field. Servers SHOULD set the
most significant bit of this field (0x40) to 1 so that Version most significant bit of this field (0x40) to 1 so that Version
Negotiation packets appear to have the Fixed Bit field. Negotiation packets appear to have the Fixed Bit field.
The Version field of a Version Negotiation packet MUST be set to The Version field of a Version Negotiation packet MUST be set to
0x00000000. 0x00000000.
The server MUST include the value from the Source Connection ID field The server MUST include the value from the Source Connection ID field
of the packet it receives in the Destination Connection ID field. of the packet it receives in the Destination Connection ID field.
The value for Source Connection ID MUST be copied from the The value for Source Connection ID MUST be copied from the
Destination Connection ID of the received packet, which is initially Destination Connection ID of the received packet, which is initially
randomly selected by a client. Echoing both connection IDs gives randomly selected by a client. Echoing both connection IDs gives
clients some assurance that the server received the packet and that clients some assurance that the server received the packet and that
the Version Negotiation packet was not generated by an off-path the Version Negotiation packet was not generated by an off-path
attacker. attacker.
As future versions of QUIC may support Connection IDs larger than the Future versions of QUIC may have different requirements for the
version 1 limit, Version Negotiation packets could carry Connection lengths of connection IDs. In particular, connection IDs might have
IDs that are longer than 20 bytes. a smaller minimum length or a greater maximum length. Version-
specific rules for the connection ID therefore MUST NOT influence a
server decision about whether to send a Version Negotiation packet.
The remainder of the Version Negotiation packet is a list of 32-bit The remainder of the Version Negotiation packet is a list of 32-bit
versions that the server supports. versions that the server supports.
A Version Negotiation packet is not acknowledged. It is only sent in A Version Negotiation packet is not acknowledged. It is only sent in
response to a packet that indicates an unsupported version; see response to a packet that indicates an unsupported version; see
Section 5.2.2. Section 5.2.2.
The Version Negotiation packet does not include the Packet Number and The Version Negotiation packet does not include the Packet Number and
Length fields present in other packets that use the long header form. Length fields present in other packets that use the long header form.
skipping to change at page 165, line 22 skipping to change at page 166, line 28
Value: The assigned codepoint. Value: The assigned codepoint.
Status: "Permanent" or "Provisional". Status: "Permanent" or "Provisional".
Specification: A reference to a publicly available specification for Specification: A reference to a publicly available specification for
the value. the value.
Date: The date of last update to the registration. Date: The date of last update to the registration.
Change Controller: The entity that is responsible for the definition
of the registration.
Contact: Contact details for the registrant. Contact: Contact details for the registrant.
Notes: Supplementary notes about the registration. Notes: Supplementary notes about the registration.
Provisional registrations MAY omit the Specification and Notes Provisional registrations MAY omit the Specification and Notes
fields, plus any additional fields that might be required for a fields, plus any additional fields that might be required for a
permanent registration. The Date field is not required as part of permanent registration. The Date field is not required as part of
requesting a registration as it is set to the date the registration requesting a registration as it is set to the date the registration
is created or updated. is created or updated.
skipping to change at page 167, line 14 skipping to change at page 168, line 30
Any stricter requirements for permanent registrations do not prevent Any stricter requirements for permanent registrations do not prevent
provisional registrations for affected codepoints. For instance, a provisional registrations for affected codepoints. For instance, a
provisional registration for a frame type (Section 22.3) of 61 could provisional registration for a frame type (Section 22.3) of 61 could
be requested. be requested.
All registrations made by Standards Track publications MUST be All registrations made by Standards Track publications MUST be
permanent. permanent.
All registrations in this document are assigned a permanent status All registrations in this document are assigned a permanent status
and list as contact the IETF (quic@ietf.org). and list a change controller of the IETF and a contact of the QUIC
working group (quic@ietf.org).
22.2. QUIC Transport Parameter Registry 22.2. QUIC Transport Parameter Registry
IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" IANA [SHALL add/has added] a registry for "QUIC Transport Parameters"
under a "QUIC" heading. under a "QUIC" heading.
The "QUIC Transport Parameters" registry governs a 62-bit space. The "QUIC Transport Parameters" registry governs a 62-bit space.
This registry follows the registration policy from Section 22.1. This registry follows the registration policy from Section 22.1.
Permanent registrations in this registry are assigned using the Permanent registrations in this registry are assigned using the
Specification Required policy ([RFC8126]). Specification Required policy ([RFC8126]).
skipping to change at page 171, line 31 skipping to change at page 172, line 31
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>. September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[QUIC-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", Work in Progress, Internet-Draft, and Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-31, 25 September 2020, draft-ietf-quic-recovery-32, 20 October 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-31>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-32>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", Work in Progress, Layer Security (TLS) to Secure QUIC", Work in Progress,
Internet-Draft, draft-ietf-quic-tls-31, 25 September 2020, Internet-Draft, draft-ietf-quic-tls-32, 20 October 2020,
<https://tools.ietf.org/html/draft-ietf-quic-tls-31>. <https://tools.ietf.org/html/draft-ietf-quic-tls-32>.
[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 174, line 8 skipping to change at page 175, line 8
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic- Work in Progress, Internet-Draft, draft-ietf-quic-
invariants-11, 25 September 2020, invariants-11, 20 October 2020,
<https://tools.ietf.org/html/draft-ietf-quic-invariants- <https://tools.ietf.org/html/draft-ietf-quic-invariants-
11>. 11>.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-07, 8 July 2020, draft-ietf-quic-manageability-07, 8 July 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
manageability-07.txt>. manageability-07.txt>.
skipping to change at page 177, line 36 skipping to change at page 178, line 36
marked packets are discarded by the path, the short duration of the marked packets are discarded by the path, the short duration of the
testing period limits the number of losses incurred. testing period limits the number of losses incurred.
Appendix C. Change Log Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-30 C.1. Since draft-ietf-quic-transport-31
* Require expansion of datagrams to ensure that a path supports at
least 1200 bytes in both directions:
- During the handshake ack-eliciting Initial packets from the
server need to be expanded (#4183, #4188)
- Path validation now requires packets containing PATH_CHALLENGE
and PATH_RESPONSE to be expanded and PATH_RESPONSE is sent on
the same network path (#4216, #4226)
* Though senders need to expand datagrams in some cases, receivers
cannot enforce this requirement (#4253, #4254)
* Split contact into contact and change controller for IANA
registrations (#4230, #4239)
C.2. Since draft-ietf-quic-transport-30
* Use TRANSPORT_PARAMETER_ERROR for an invalid transport parameter * Use TRANSPORT_PARAMETER_ERROR for an invalid transport parameter
(#4099, #4100) (#4099, #4100)
* Add a new error code for AEAD_LIMIT_REACHED code to avoid conflict * Add a new error code for AEAD_LIMIT_REACHED code to avoid conflict
(#4087, #4088) (#4087, #4088)
* Allow use of address validation token when server address changes * Allow use of address validation token when server address changes
(#4076, #4089) (#4076, #4089)
C.2. Since draft-ietf-quic-transport-29 C.3. Since draft-ietf-quic-transport-29
* Require the same connection ID on coalesced packets (#3800, #3930) * Require the same connection ID on coalesced packets (#3800, #3930)
* Allow caching of packets that can't be decrypted, by allowing the * Allow caching of packets that can't be decrypted, by allowing the
reported acknowledgment delay to exceed max_ack_delay prior to reported acknowledgment delay to exceed max_ack_delay prior to
confirming the handshake (#3821, #3980, #4035, #3874) confirming the handshake (#3821, #3980, #4035, #3874)
* Allow connection ID to be used for address validation (#3834, * Allow connection ID to be used for address validation (#3834,
#3924) #3924)
* Required protocol operations are no longer directed at * Required protocol operations are no longer directed at
implementations, but are features provided to application implementations, but are features provided to application
protocols (#3838, #3935) protocols (#3838, #3935)
skipping to change at page 178, line 33 skipping to change at page 179, line 49
* Recommend retention of state for lost packets to allow for late * Recommend retention of state for lost packets to allow for late
arrival and avoid unnecessary retransmission (#3956, #3957) arrival and avoid unnecessary retransmission (#3956, #3957)
* Allow a server to reject connections if a client reuses packet * Allow a server to reject connections if a client reuses packet
numbers after Retry (#3989, #3990) numbers after Retry (#3989, #3990)
* Limit recommendation for immediate acknowledgment to when ack- * Limit recommendation for immediate acknowledgment to when ack-
eliciting packets are reordered (#4001, #4000) eliciting packets are reordered (#4001, #4000)
C.3. Since draft-ietf-quic-transport-28 C.4. Since draft-ietf-quic-transport-28
* Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED * Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED
(#3709, #3690, #3694) (#3709, #3690, #3694)
* Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs * Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs
(#3703, #3691) (#3703, #3691)
* Integrate QUIC-specific language from draft-ietf-tsvwg-datagram- * Integrate QUIC-specific language from draft-ietf-tsvwg-datagram-
plpmtud (#3695, #3702) plpmtud (#3695, #3702)
* disable_active_migration does not apply to the addresses offered * disable_active_migration does not apply to the addresses offered
in server_preferred_address (#3608, #3670) in server_preferred_address (#3608, #3670)
C.4. Since draft-ietf-quic-transport-27 C.5. Since draft-ietf-quic-transport-27
* Allowed CONNECTION_CLOSE in any packet number space, with a * Allowed CONNECTION_CLOSE in any packet number space, with a
requirement to use a new transport-level error for application- requirement to use a new transport-level error for application-
specific errors in Initial and Handshake packets (#3430, #3435, specific errors in Initial and Handshake packets (#3430, #3435,
#3440) #3440)
* Clearer requirements for address validation (#2125, #3327) * Clearer requirements for address validation (#2125, #3327)
* Security analysis of handshake and migration (#2143, #2387, #2925) * Security analysis of handshake and migration (#2143, #2387, #2925)
* The entire payload of a datagram is used when counting bytes for * The entire payload of a datagram is used when counting bytes for
skipping to change at page 180, line 5 skipping to change at page 181, line 15
* Clarified that largest acknowledged needs to be saved, but not * Clarified that largest acknowledged needs to be saved, but not
necessarily signaled in all cases (#3541, #3581) necessarily signaled in all cases (#3541, #3581)
* Addressed linkability risk with the use of preferred_address * Addressed linkability risk with the use of preferred_address
(#3559, #3563) (#3559, #3563)
* Added authentication of handshake connection IDs (#3439, #3499) * Added authentication of handshake connection IDs (#3439, #3499)
* Opening a stream in the wrong direction is an error (#3527) * Opening a stream in the wrong direction is an error (#3527)
C.5. Since draft-ietf-quic-transport-26 C.6. Since draft-ietf-quic-transport-26
* Change format of transport parameters to use varints (#3294, * Change format of transport parameters to use varints (#3294,
#3169) #3169)
C.6. Since draft-ietf-quic-transport-25 C.7. Since draft-ietf-quic-transport-25
* Define the use of CONNECTION_CLOSE prior to establishing * Define the use of CONNECTION_CLOSE prior to establishing
connection state (#3269, #3297, #3292) connection state (#3269, #3297, #3292)
* Allow use of address validation tokens after client address * Allow use of address validation tokens after client address
changes (#3307, #3308) changes (#3307, #3308)
* Define the timer for address validation (#2910, #3339) * Define the timer for address validation (#2910, #3339)
C.7. Since draft-ietf-quic-transport-24 C.8. Since draft-ietf-quic-transport-24
* Added HANDSHAKE_DONE to signal handshake confirmation (#2863, * Added HANDSHAKE_DONE to signal handshake confirmation (#2863,
#3142, #3145) #3142, #3145)
* Add integrity check to Retry packets (#3014, #3274, #3120) * Add integrity check to Retry packets (#3014, #3274, #3120)
* Specify handling of reordered NEW_CONNECTION_ID frames (#3194, * Specify handling of reordered NEW_CONNECTION_ID frames (#3194,
#3202) #3202)
* Require checking of sequence numbers in RETIRE_CONNECTION_ID * Require checking of sequence numbers in RETIRE_CONNECTION_ID
skipping to change at page 181, line 25 skipping to change at page 182, line 33
* Idle timeout is symmetric (#2602, #3099) * Idle timeout is symmetric (#2602, #3099)
* Prohibit IP fragmentation (#3243, #3280) * Prohibit IP fragmentation (#3243, #3280)
* Define the use of provisional registration for all registries * Define the use of provisional registration for all registries
(#3109, #3020, #3102, #3170) (#3109, #3020, #3102, #3170)
* Packets on one path must not adjust values for a different path * Packets on one path must not adjust values for a different path
(#2909, #3139) (#2909, #3139)
C.8. Since draft-ietf-quic-transport-23 C.9. Since draft-ietf-quic-transport-23
* Allow ClientHello to span multiple packets (#2928, #3045) * Allow ClientHello to span multiple packets (#2928, #3045)
* Client Initial size constraints apply to UDP datagram payload * Client Initial size constraints apply to UDP datagram payload
(#3053, #3051) (#3053, #3051)
* Stateless reset changes (#2152, #2993) * Stateless reset changes (#2152, #2993)
- tokens need to be compared in constant time - tokens need to be compared in constant time
skipping to change at page 182, line 4 skipping to change at page 183, line 12
* A new connection ID is necessary when responding to migration * A new connection ID is necessary when responding to migration
(#2778, #2969) (#2778, #2969)
* Stronger requirements for connection ID retirement (#3046, #3096) * Stronger requirements for connection ID retirement (#3046, #3096)
* NEW_TOKEN cannot be empty (#2978, #2977) * NEW_TOKEN cannot be empty (#2978, #2977)
* PING can be sent at any encryption level (#3034, #3035) * PING can be sent at any encryption level (#3034, #3035)
* CONNECTION_CLOSE is not ack-eliciting (#3097, #3098) * CONNECTION_CLOSE is not ack-eliciting (#3097, #3098)
* Frame encoding error conditions updated (#3027, #3042) * Frame encoding error conditions updated (#3027, #3042)
* Non-ack-eliciting packets cannot be sent in response to non-ack- * Non-ack-eliciting packets cannot be sent in response to non-ack-
eliciting packets (#3100, #3104) eliciting packets (#3100, #3104)
* Servers have to change connection IDs in Retry (#2837, #3147) * Servers have to change connection IDs in Retry (#2837, #3147)
C.9. Since draft-ietf-quic-transport-22 C.10. Since draft-ietf-quic-transport-22
* Rules for preventing correlation by connection ID tightened * Rules for preventing correlation by connection ID tightened
(#2084, #2929) (#2084, #2929)
* Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, * Clarified use of CONNECTION_CLOSE in Handshake packets (#2151,
#2541, #2688) #2541, #2688)
* Discourage regressions of largest acknowledged in ACK (#2205, * Discourage regressions of largest acknowledged in ACK (#2205,
#2752) #2752)
skipping to change at page 183, line 19 skipping to change at page 184, line 26
#2840, #2841) #2840, #2841)
* Explanation of the effect of Retry on 0-RTT packets (#2842, #2852) * Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)
* Cryptographic handshake needs to provide server transport * Cryptographic handshake needs to provide server transport
parameter encryption (#2920, #2921) parameter encryption (#2920, #2921)
* Moved ACK generation guidance from recovery draft to transport * Moved ACK generation guidance from recovery draft to transport
draft (#1860, #2916). draft (#1860, #2916).
C.10. Since draft-ietf-quic-transport-21 C.11. Since draft-ietf-quic-transport-21
* Connection ID lengths are now one octet, but limited in version 1 * 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)
C.11. Since draft-ietf-quic-transport-20 C.12. Since draft-ietf-quic-transport-20
* Error codes are encoded as variable-length integers (#2672, #2680) * Error codes are encoded as variable-length integers (#2672, #2680)
* NEW_CONNECTION_ID includes a request to retire old connection IDs * NEW_CONNECTION_ID includes a request to retire old connection IDs
(#2645, #2769) (#2645, #2769)
* Tighter rules for generating and explicitly eliciting ACK frames * Tighter rules for generating and explicitly eliciting ACK frames
(#2546, #2794) (#2546, #2794)
* Recommend having only one packet per encryption level in a * Recommend having only one packet per encryption level in a
skipping to change at page 184, line 20 skipping to change at page 185, line 28
* PATH_RESPONSE no longer needs to be received on the validated path * PATH_RESPONSE no longer needs to be received on the validated path
(#2582, #2580, #2579, #2637) (#2582, #2580, #2579, #2637)
* PATH_RESPONSE frames are not stored and retransmitted (#2724, * PATH_RESPONSE frames are not stored and retransmitted (#2724,
#2729) #2729)
* Document hack for enabling routing of ICMP when doing PMTU probing * Document hack for enabling routing of ICMP when doing PMTU probing
(#1243, #2402) (#1243, #2402)
C.12. Since draft-ietf-quic-transport-19 C.13. Since draft-ietf-quic-transport-19
* Refine discussion of 0-RTT transport parameters (#2467, #2464) * Refine discussion of 0-RTT transport parameters (#2467, #2464)
* Fewer transport parameters need to be remembered for 0-RTT (#2624, * Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467) #2467)
* Spin bit text incorporated (#2564) * Spin bit text incorporated (#2564)
* Close the connection when maximum stream ID in MAX_STREAMS exceeds * 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 184, line 47 skipping to change at page 186, line 7
* The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) * The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
* Initial packets from clients need to be padded to 1200 unless a * 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)
* CRYPTO frames can be discarded if too much data is buffered * CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524) (#1834, #2524)
* Stateless reset uses a short header packet (#2599, #2600) * Stateless reset uses a short header packet (#2599, #2600)
C.13. Since draft-ietf-quic-transport-18 C.14. Since draft-ietf-quic-transport-18
* Removed version negotiation; version negotiation, including * 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)
* Added discussion of the use of IPv6 flow labels (#2348, #2399) * Added discussion of the use of IPv6 flow labels (#2348, #2399)
* A connection ID can't be retired in a packet that uses that * A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420) connection ID (#2101, #2420)
* Idle timeout transport parameter is in milliseconds (from seconds) * Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454) (#2453, #2454)
* Endpoints are required to use new connection IDs when they use new * Endpoints are required to use new connection IDs when they use new
network paths (#2413, #2414) network paths (#2413, #2414)
* Increased the set of permissible frames in 0-RTT (#2344, #2355) * Increased the set of permissible frames in 0-RTT (#2344, #2355)
C.14. Since draft-ietf-quic-transport-17 C.15. Since draft-ietf-quic-transport-17
* Stream-related errors now use STREAM_STATE_ERROR (#2305) * Stream-related errors now use STREAM_STATE_ERROR (#2305)
* Endpoints discard initial keys as soon as handshake keys are * Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
* Expanded conditions for ignoring ICMP packet too big messages * Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161) (#2108, #2161)
* Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, * Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
skipping to change at page 186, line 10 skipping to change at page 187, line 16
#2301) #2301)
* Allow server preferred address for both IPv4 and IPv6 (#2122, * Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
* Corrected requirements for migration to a preferred address * Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
* ACK of non-existent packet is illegal (#2298, #2302) * ACK of non-existent packet is illegal (#2298, #2302)
C.15. Since draft-ietf-quic-transport-16 C.16. Since draft-ietf-quic-transport-16
* Stream limits are defined as counts, not maximums (#1850, #1906) * Stream limits are defined as counts, not maximums (#1850, #1906)
* Require amplification attack defense after closing (#1905, #1911) * Require amplification attack defense after closing (#1905, #1911)
* Remove reservation of application error code 0 for STOPPING * Remove reservation of application error code 0 for STOPPING
(#1804, #1922) (#1804, #1922)
* Renumbered frames (#1945) * Renumbered frames (#1945)
skipping to change at page 187, line 4 skipping to change at page 188, line 11
* Allow STOP_SENDING to open a remote bidirectional stream (#1797, * Allow STOP_SENDING to open a remote bidirectional stream (#1797,
#2013) #2013)
* Added mitigation for off-path migration attacks (#1278, #1749, * Added mitigation for off-path migration attacks (#1278, #1749,
#2033) #2033)
* Don't let the PMTU to drop below 1280 (#2063, #2069) * Don't let the PMTU to drop below 1280 (#2063, #2069)
* Require peers to replace retired connection IDs (#2085) * Require peers to replace retired connection IDs (#2085)
* Servers are required to ignore Version Negotiation packets (#2088) * Servers are required to ignore Version Negotiation packets (#2088)
* Tokens are repeated in all Initial packets (#2089) * Tokens are repeated in all Initial packets (#2089)
* Clarified how PING frames are sent after loss (#2094) * Clarified how PING frames are sent after loss (#2094)
* Initial keys are discarded once Handshake are available (#1951, * Initial keys are discarded once Handshake are available (#1951,
#2045) #2045)
* ICMP PTB validation clarifications (#2161, #2109, #2108) * ICMP PTB validation clarifications (#2161, #2109, #2108)
C.16. Since draft-ietf-quic-transport-15 C.17. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
C.17. Since draft-ietf-quic-transport-14 C.18. Since draft-ietf-quic-transport-14
* Merge ACK and ACK_ECN (#1778, #1801) * Merge ACK and ACK_ECN (#1778, #1801)
* Explicitly communicate max_ack_delay (#981, #1781) * Explicitly communicate max_ack_delay (#981, #1781)
* Validate original connection ID after Retry packets (#1710, #1486, * Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
* Idle timeout is optional and has no specified maximum (#1765) * Idle timeout is optional and has no specified maximum (#1765)
* Update connection ID handling; add RETIRE_CONNECTION_ID type * 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)
* Include a Token in all Initial packets (#1649, #1794) * Include a Token in all Initial packets (#1649, #1794)
* Prevent handshake deadlock (#1764, #1824) * Prevent handshake deadlock (#1764, #1824)
C.18. Since draft-ietf-quic-transport-13 C.19. Since draft-ietf-quic-transport-13
* Streams open when higher-numbered streams of the same type open * Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
* Split initial stream flow control limit into 3 transport * Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
* All flow control transport parameters are optional (#1610) * All flow control transport parameters are optional (#1610)
* Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) * Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
skipping to change at page 188, line 28 skipping to change at page 189, line 35
* Permit 0-RTT after receiving Version Negotiation or Retry (#1507, * Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
* Permit Retry in response to 0-RTT (#1547, #1552) * Permit Retry in response to 0-RTT (#1547, #1552)
* Looser verification of ECN counters to account for ACK loss * Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
* Remove frame type field from APPLICATION_CLOSE (#1508, #1528) * Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
C.19. Since draft-ietf-quic-transport-12 C.20. Since draft-ietf-quic-transport-12
* Changes to integration of the TLS handshake (#829, #1018, #1094, * 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 189, line 23 skipping to change at page 190, line 29
* Fixed sampling method for packet number encryption; the length * 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)
* Stateless Reset is now symmetric and subject to size constraints * Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
* Added frame type extension mechanism (#58, #1473) * Added frame type extension mechanism (#58, #1473)
C.20. Since draft-ietf-quic-transport-11 C.21. Since draft-ietf-quic-transport-11
* Enable server to transition connections to a preferred address * Enable server to transition connections to a preferred address
(#560, #1251) (#560, #1251)
* Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, * Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079) #990, #734, #1317, #1267, #1079)
* Packet numbers use a variable-length encoding (#989, #1334) * Packet numbers use a variable-length encoding (#989, #1334)
* STREAM frames can now be empty (#1350) * STREAM frames can now be empty (#1350)
C.21. Since draft-ietf-quic-transport-10 C.22. Since draft-ietf-quic-transport-10
* Swap payload length and packed number fields in long header * Swap payload length and packed number fields in long header
(#1294) (#1294)
* Clarified that CONNECTION_CLOSE is allowed in Handshake packet * Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
* Spin bit reserved (#1283) * Spin bit reserved (#1283)
* Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 189, line 46 skipping to change at page 191, line 4
* Swap payload length and packed number fields in long header * Swap payload length and packed number fields in long header
(#1294) (#1294)
* Clarified that CONNECTION_CLOSE is allowed in Handshake packet * Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
* Spin bit reserved (#1283) * Spin bit reserved (#1283)
* Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
* A more complete connection migration (#1249) * A more complete connection migration (#1249)
* Refine opportunistic ACK defense text (#305, #1030, #1185) * Refine opportunistic ACK defense text (#305, #1030, #1185)
* A Stateless Reset Token isn't mandatory (#818, #1191) * A Stateless Reset Token isn't mandatory (#818, #1191)
* Removed implicit stream opening (#896, #1193) * Removed implicit stream opening (#896, #1193)
* An empty STREAM frame can be used to open a stream without sending * An empty STREAM frame can be used to open a stream without sending
data (#901, #1194) data (#901, #1194)
* Define stream counts in transport parameters rather than a maximum * Define stream counts in transport parameters rather than a maximum
stream ID (#1023, #1065) stream ID (#1023, #1065)
* STOP_SENDING is now prohibited before streams are used (#1050) * STOP_SENDING is now prohibited before streams are used (#1050)
* Recommend including ACK in Retry packets and allow PADDING (#1067, * Recommend including ACK in Retry packets and allow PADDING (#1067,
#882) #882)
* Endpoints now become closing after an idle timeout (#1178, #1179) * Endpoints now become closing after an idle timeout (#1178, #1179)
* Remove implication that Version Negotiation is sent when a packet * Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197) of the wrong version is received (#1197)
C.22. Since draft-ietf-quic-transport-09 C.23. Since draft-ietf-quic-transport-09
* Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with * 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)
* A server can now only send 3 packets without validating the client * A server can now only send 3 packets without validating the client
address (#38, #1090) address (#38, #1090)
* Delivery order of stream data is no longer strongly specified * Delivery order of stream data is no longer strongly specified
(#252, #1070) (#252, #1070)
skipping to change at page 190, line 43 skipping to change at page 192, line 4
* Rework of packet handling and version negotiation (#1038) * Rework of packet handling and version negotiation (#1038)
* Stream 0 is now exempt from flow control until the handshake * Stream 0 is now exempt from flow control until the handshake
completes (#1074, #725, #825, #1082) completes (#1074, #725, #825, #1082)
* Improved retransmission rules for all frame types: information is * 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)
* Added an error code for server busy signals (#1137) * Added an error code for server busy signals (#1137)
* Endpoints now set the connection ID that their peer uses. * 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)
C.23. Since draft-ietf-quic-transport-08 C.24. Since draft-ietf-quic-transport-08
* Clarified requirements for BLOCKED usage (#65, #924) * Clarified requirements for BLOCKED usage (#65, #924)
* BLOCKED frame now includes reason for blocking (#452, #924, #927, * BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
* GAP limitation in ACK Frame (#613) * GAP limitation in ACK Frame (#613)
* Improved PMTUD description (#614, #1036) * Improved PMTUD description (#614, #1036)
skipping to change at page 191, line 33 skipping to change at page 192, line 37
* Stateless reset clarified as version-specific (#930, #986) * Stateless reset clarified as version-specific (#930, #986)
* initial_max_stream_id_x transport parameters are optional (#970, * initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
* ACK delay assumes a default value during the handshake (#1007, * ACK delay assumes a default value during the handshake (#1007,
#1009) #1009)
* Removed transport parameters from NewSessionTicket (#1015) * Removed transport parameters from NewSessionTicket (#1015)
C.24. Since draft-ietf-quic-transport-07 C.25. Since draft-ietf-quic-transport-07
* The long header now has version before packet number (#926, #939) * The long header now has version before packet number (#926, #939)
* Rename and consolidate packet types (#846, #822, #847) * Rename and consolidate packet types (#846, #822, #847)
* Packet types are assigned new codepoints and the Connection ID * Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956) Flag is inverted (#426, #956)
* Removed type for Version Negotiation and use Version 0 (#963, * Removed type for Version Negotiation and use Version 0 (#963,
#968) #968)
skipping to change at page 192, line 28 skipping to change at page 193, line 33
* Address validation for connection migration (#161, #732, #878) * Address validation for connection migration (#161, #732, #878)
* Clearly defined retransmission rules for BLOCKED (#452, #65, #924) * Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
* negotiated_version is sent in server transport parameters (#710, * negotiated_version is sent in server transport parameters (#710,
#959) #959)
* Increased the range over which packet numbers are randomized * Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
C.25. Since draft-ietf-quic-transport-06 C.26. Since draft-ietf-quic-transport-06
* Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) * Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
* Split error code space between application and transport (#485) * Split error code space between application and transport (#485)
* Stateless reset token moved to end (#820) * Stateless reset token moved to end (#820)
* 1-RTT-protected long header types removed (#848) * 1-RTT-protected long header types removed (#848)
* No acknowledgments during draining period (#852) * No acknowledgments during draining period (#852)
* Remove "application close" as a separate close type (#854) * Remove "application close" as a separate close type (#854)
* Remove timestamps from the ACK frame (#841) * Remove timestamps from the ACK frame (#841)
* Require transport parameters to only appear once (#792) * Require transport parameters to only appear once (#792)
C.26. Since draft-ietf-quic-transport-05 C.27. Since draft-ietf-quic-transport-05
* Stateless token is server-only (#726) * Stateless token is server-only (#726)
* Refactor section on connection termination (#733, #748, #328, * Refactor section on connection termination (#733, #748, #328,
#177) #177)
* Limit size of Version Negotiation packet (#585) * Limit size of Version Negotiation packet (#585)
* Clarify when and what to ack (#736) * Clarify when and what to ack (#736)
* Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED * Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
* Clarify Keep-alive requirements (#729) * Clarify Keep-alive requirements (#729)
C.27. Since draft-ietf-quic-transport-04 C.28. Since draft-ietf-quic-transport-04
* Introduce STOP_SENDING frame, RESET_STREAM only resets in one * Introduce STOP_SENDING frame, RESET_STREAM only resets in one
direction (#165) direction (#165)
* Removed GOAWAY; application protocols are responsible for graceful * Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
* Reduced the number of error codes (#96, #177, #184, #211) * Reduced the number of error codes (#96, #177, #184, #211)
* Version validation fields can't move or change (#121) * Version validation fields can't move or change (#121)
skipping to change at page 193, line 47 skipping to change at page 195, line 5
* Increased the maximum length of the Largest Acknowledged field in * Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
* truncate_connection_id is renamed to omit_connection_id (#659) * truncate_connection_id is renamed to omit_connection_id (#659)
* CONNECTION_CLOSE terminates the connection like TCP RST (#330, * CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) * Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
C.28. Since draft-ietf-quic-transport-03 C.29. Since draft-ietf-quic-transport-03
* Change STREAM and RESET_STREAM layout * Change STREAM and RESET_STREAM layout
* Add MAX_STREAM_ID settings * Add MAX_STREAM_ID settings
C.29. Since draft-ietf-quic-transport-02 C.30. Since draft-ietf-quic-transport-02
* The size of the initial packet payload has a fixed minimum (#267, * The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
* Define when Version Negotiation packets are ignored (#284, #294, * Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
* The 64-bit FNV-1a algorithm is used for integrity protection of * 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 194, line 45 skipping to change at page 196, line 4
- BLOCKED split to match WINDOW_UPDATE split (#454) - BLOCKED split to match WINDOW_UPDATE split (#454)
- Define STREAM_ID_NEEDED frame (#455) - Define STREAM_ID_NEEDED frame (#455)
* A NEW_CONNECTION_ID frame supports connection migration without * A NEW_CONNECTION_ID frame supports connection migration without
linkability (#232, #491, #496) linkability (#232, #491, #496)
* Transport parameters for 0-RTT are retained from a previous * 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)
* Expanded security considerations (#440, #444, #445, #448) * Expanded security considerations (#440, #444, #445, #448)
C.30. Since draft-ietf-quic-transport-01 C.31. Since draft-ietf-quic-transport-01
* Defined short and long packet headers (#40, #148, #361) * Defined short and long packet headers (#40, #148, #361)
* Defined a versioning scheme and stable fields (#51, #361) * Defined a versioning scheme and stable fields (#51, #361)
* Define reserved version values for "greasing" negotiation (#112, * Define reserved version values for "greasing" negotiation (#112,
#278) #278)
* The initial packet number is randomized (#35, #283) * The initial packet number is randomized (#35, #283)
* Narrow the packet number encoding range requirement (#67, #286, * Narrow the packet number encoding range requirement (#67, #286,
skipping to change at page 196, line 49 skipping to change at page 198, line 8
* Remove error code and reason phrase from GOAWAY (#352, #355) * Remove error code and reason phrase from GOAWAY (#352, #355)
* GOAWAY includes a final stream number for both directions (#347) * GOAWAY includes a final stream number for both directions (#347)
* Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a * Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
* Defined priority as the responsibility of the application protocol * Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
C.31. Since draft-ietf-quic-transport-00 C.32. Since draft-ietf-quic-transport-00
* Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag * Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
* Defined versioning * Defined versioning
* Reworked description of packet and frame layout * Reworked description of packet and frame layout
* Error code space is divided into regions for each component * Error code space is divided into regions for each component
* Use big endian for all numeric values * Use big endian for all numeric values
C.32. Since draft-hamilton-quic-transport-protocol-01 C.33. Since draft-hamilton-quic-transport-protocol-01
* Adopted as base for draft-ietf-quic-tls * Adopted as base for draft-ietf-quic-tls
* Updated authors/editors list * Updated authors/editors list
* Added IANA Considerations section * Added IANA Considerations section
* Moved Contributors and Acknowledgments to appendices * Moved Contributors and Acknowledgments to appendices
Contributors Contributors
 End of changes. 93 change blocks. 
284 lines changed or deleted 350 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/