draft-ietf-quic-transport-28.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: November 20, 2020 Mozilla Expires: December 7, 2020 Mozilla
May 19, 2020 June 5, 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-28 draft-ietf-quic-transport-latest
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 November 20, 2020. This Internet-Draft will expire on December 7, 2020.
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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 10 skipping to change at page 4, line 10
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 73 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 73
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 73 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 73
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 74 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 74
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 74 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 74
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 75 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 75
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 77 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 77
13. Packetization and Reliability . . . . . . . . . . . . . . . . 79 13. Packetization and Reliability . . . . . . . . . . . . . . . . 79
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 80 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 80
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 80 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 80
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 81 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 81
13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 82 13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 82
13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 83 13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 82
13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 83 13.2.4. Receiver Tracking of ACK Frames . . . . . . . . . . 83
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 84 13.2.5. Limiting ACK Ranges . . . . . . . . . . . . . . . . 83
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 84 13.2.6. Measuring and Reporting Host Delay . . . . . . . . . 84
13.3. Retransmission of Information . . . . . . . . . . . . . 84 13.2.7. ACK Frames and Packet Protection . . . . . . . . . . 84
13.2.8. PADDING Frames Consume Congestion Window . . . . . . 85
13.3. Retransmission of Information . . . . . . . . . . . . . 85
13.4. Explicit Congestion Notification . . . . . . . . . . . . 87 13.4. Explicit Congestion Notification . . . . . . . . . . . . 87
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 87 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 88
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 88 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 88
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 90 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 90
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 91 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 91
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 91 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 92
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 92 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 93
14.3.1. PMTU Probes Containing Source Connection ID . . . . 93 14.3.1. PMTU Probes Containing Source Connection ID . . . . 93
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 93 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 94
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 94 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 95
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 95 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 95
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 95 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 96
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 96 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 97
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 99 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 99
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 100 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 101
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 102 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 103
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 104 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 104
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 105 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 105
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 107 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 107
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 109 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 109
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 110 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 110
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 111 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 111
18.2. Transport Parameter Definitions . . . . . . . . . . . . 111 18.2. Transport Parameter Definitions . . . . . . . . . . . . 111
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 115 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 115
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 115 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 115
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 115 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 115
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 116 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 116
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 117 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 118
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 118 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 119
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 119 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 120
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 120 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 120
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 121 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 121
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 122 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 122
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 122 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 123
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 124 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 124
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 124 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 125
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 125 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 126
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 126 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 126
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 127 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 127
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 127 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 128
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 128 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 128
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 130 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 130
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 130 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 131
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 131 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 131
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 131 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 132
19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 132 19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 133
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 133 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 133
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 133 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 134
20.1. Application Protocol Error Codes . . . . . . . . . . . . 135 20.1. Application Protocol Error Codes . . . . . . . . . . . . 135
21. Security Considerations . . . . . . . . . . . . . . . . . . . 135 21. Security Considerations . . . . . . . . . . . . . . . . . . . 136
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 135 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 136
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 136 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 137
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 137 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 137
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 137 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 137
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 137 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 138
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 138 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 138
21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 138 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 139
21.8. Explicit Congestion Notification Attacks . . . . . . . . 139 21.8. Explicit Congestion Notification Attacks . . . . . . . . 139
21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 139 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 139
21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 139 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 140
21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 140 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 140
21.12. Overview of Security Properties . . . . . . . . . . . . 140 21.12. Overview of Security Properties . . . . . . . . . . . . 140
21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 140 21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 141
21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 142 21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 143
21.12.3. Connection Migration . . . . . . . . . . . . . . . 143 21.12.3. Connection Migration . . . . . . . . . . . . . . . 143
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147
22.1. Registration Policies for QUIC Registries . . . . . . . 147 22.1. Registration Policies for QUIC Registries . . . . . . . 148
22.1.1. Provisional Registrations . . . . . . . . . . . . . 147 22.1.1. Provisional Registrations . . . . . . . . . . . . . 148
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 148 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 149
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 149 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 149
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 149 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 150
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 150 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 150
22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 152 22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 152
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 152 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 152
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 154 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 154
23.1. Normative References . . . . . . . . . . . . . . . . . . 154 23.1. Normative References . . . . . . . . . . . . . . . . . . 154
23.2. Informative References . . . . . . . . . . . . . . . . . 155 23.2. Informative References . . . . . . . . . . . . . . . . . 155
23.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 157 23.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 157 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 157
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 158 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 158
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 159 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 159
C.1. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 159 C.1. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 159
C.2. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 160 C.2. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 160
C.3. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 160 C.3. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 160
C.4. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 160 C.4. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 161
C.5. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 162 C.5. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 162
C.6. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 162 C.6. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 162
C.7. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 163 C.7. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 164
C.8. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 164 C.8. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 164
C.9. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 165 C.9. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 165
C.10. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 165 C.10. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 165
C.11. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 166 C.11. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 166
C.12. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 166 C.12. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 166
C.13. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 168 C.13. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 168
C.14. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 168 C.14. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 168
C.15. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 168 C.15. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 168
C.16. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 169 C.16. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 169
C.17. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 170 C.17. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 170
skipping to change at page 7, line 50 skipping to change at page 8, line 4
* 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 packets.
o Finally, encoding details of QUIC protocol elements are described o 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
[QUIC-TLS]. [QUIC-TLS].
This document defines QUIC version 1, which conforms to the protocol This document defines QUIC version 1, which conforms to the protocol
invariants in [QUIC-INVARIANTS]. invariants in [QUIC-INVARIANTS].
To refer to QUIC version 1, cite this document. References to the
limited set of version-independent properties of QUIC can cite
[QUIC-INVARIANTS].
1.2. Terms and Definitions 1.2. Terms and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Commonly used terms in the document are described below. Commonly used terms in the document are described below.
skipping to change at page 9, line 47 skipping to change at page 10, line 4
x (i): Indicates that x uses the variable-length encoding in x (i): Indicates that x uses the variable-length encoding in
Section 16 Section 16
x (A..B): Indicates that x can be any length from A to B; A can be x (A..B): Indicates that x can be any length from A to B; A can be
omitted to indicate a minimum of zero bits and B can be omitted to omitted to indicate a minimum of zero bits and B can be omitted to
indicate no set upper limit; values in this format always end on indicate no set upper limit; values in this format always end on
an octet boundary an octet boundary
x (?) = C: Indicates that x has a fixed value of C x (?) = C: Indicates that x has a fixed value of C
x (?) = C..D: Indicates that x has a value in the range from C to D, x (?) = C..D: Indicates that x has a value in the range from C to D,
inclusive inclusive
[x (E)]: Indicates that x is optional (and has length of E) [x (E)]: Indicates that x is optional (and has length of E)
x (E) ...: Indicates that x is repeated zero or more times (and that x (E) ...: Indicates that x is repeated zero or more times (and that
each instance is length E) each instance is length E)
By convention, individual fields reference a complex field by using By convention, individual fields reference a complex field by using
the name of the complex field. the name of the complex field.
For example: For example:
Example Structure { Example Structure {
One-bit Field (1), One-bit Field (1),
7-bit Field with Fixed Value (7) = 61, 7-bit Field with Fixed Value (7) = 61,
Field with Variable-Length Integer (i),
Arbitrary-Length Field (..), Arbitrary-Length Field (..),
Variable-Length Field (8..24), Variable-Length Field (8..24),
Field With Minimum Length (16..), Field With Minimum Length (16..),
Field With Maximum Length (..128), Field With Maximum Length (..128),
[Optional Field (64)], [Optional Field (64)],
Repeated Field (8) ..., Repeated Field (8) ...,
} }
Figure 1: Example Format Figure 1: Example Format
skipping to change at page 31, line 40 skipping to change at page 31, line 40
Packets with a supported version, or no version field, are matched to Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero- a connection using the connection ID or - for packets with zero-
length connection IDs - the local address and port. If the packet length connection IDs - the local address and port. If the packet
doesn't match an existing connection, the server continues below. doesn't match an existing connection, the server continues below.
If the packet is an Initial packet fully conforming with the If the packet is an Initial packet fully conforming with the
specification, the server proceeds with the handshake (Section 7). specification, the server proceeds with the handshake (Section 7).
This commits the server to the version that the client selected. This commits the server to the version that the client selected.
If a server isn't currently accepting any new connections, it SHOULD If a server refuses to accept a new connection, it SHOULD send an
send an Initial packet containing a CONNECTION_CLOSE frame with error Initial packet containing a CONNECTION_CLOSE frame with error code
code SERVER_BUSY. CONNECTION_REFUSED.
If the packet is a 0-RTT packet, the server MAY buffer a limited If the packet is a 0-RTT packet, the server MAY buffer a limited
number of these packets in anticipation of a late-arriving Initial number of these packets in anticipation of a late-arriving Initial
packet. Clients are not able to send Handshake packets prior to packet. Clients are not able to send Handshake packets prior to
receiving a server response, so servers SHOULD ignore any such receiving a server response, so servers SHOULD ignore any such
packets. packets.
Servers MUST drop incoming packets under all other circumstances. Servers MUST drop incoming packets under all other circumstances.
5.2.3. Considerations for Simple Load Balancers 5.2.3. Considerations for Simple Load Balancers
skipping to change at page 50, line 17 skipping to change at page 50, line 17
the token MUST be covered by integrity protection against the token MUST be covered by integrity protection against
modification or falsification by clients. Without integrity modification or falsification by clients. Without integrity
protection, malicious clients could generate or guess values for protection, malicious clients could generate or guess values for
tokens that would be accepted by the server. Only the server tokens that would be accepted by the server. Only the server
requires access to the integrity protection key for tokens. requires access to the integrity protection key for tokens.
There is no need for a single well-defined format for the token There is no need for a single well-defined format for the token
because the server that generates the token also consumes it. Tokens because the server that generates the token also consumes it. Tokens
sent in Retry packets SHOULD include information that allows the sent in Retry packets SHOULD include information that allows the
server to verify that the source IP address and port in client server to verify that the source IP address and port in client
packets remains constant. packets remain constant.
Tokens sent in NEW_TOKEN frames MUST include information that allows Tokens sent in NEW_TOKEN frames MUST include information that allows
the server to verify that the client IP address has not changed from the server to verify that the client IP address has not changed from
when the token was issued. Servers can use tokens from NEW_TOKEN in when the token was issued. Servers can use tokens from NEW_TOKEN in
deciding not to send a Retry packet, even if the client address has deciding not to send a Retry packet, even if the client address has
changed. If the client IP address has changed, the server MUST changed. If the client IP address has changed, the server MUST
adhere to the anti-amplification limits found in Section 8.1. Note adhere to the anti-amplification limits found in Section 8.1. Note
that in the presence of NAT, this requirement might be insufficient that in the presence of NAT, this requirement might be insufficient
to protect other hosts that share the NAT from amplification attack. to protect other hosts that share the NAT from amplification attack.
skipping to change at page 68, line 27 skipping to change at page 68, line 27
to appear as a valid QUIC packet, the Unpredictable Bits field needs to appear as a valid QUIC packet, the Unpredictable Bits field needs
to include at least 38 bits of data (or 5 bytes, less the two fixed to include at least 38 bits of data (or 5 bytes, less the two fixed
bits). bits).
A minimum size of 21 bytes does not guarantee that a stateless reset A minimum size of 21 bytes does not guarantee that a stateless reset
is difficult to distinguish from other packets if the recipient is difficult to distinguish from other packets if the recipient
requires the use of a connection ID. To prevent a resulting requires the use of a connection ID. To prevent a resulting
stateless reset from being trivially distinguishable from a valid stateless reset from being trivially distinguishable from a valid
packet, all packets sent by an endpoint SHOULD be padded to at least packet, all packets sent by an endpoint SHOULD be padded to at least
22 bytes longer than the minimum connection ID that the endpoint 22 bytes longer than the minimum connection ID that the endpoint
might use. An endpoint that sends a stateless reset in response to might use. An endpoint that sends a stateless reset in response to a
packet that is 43 bytes or less in length SHOULD send a stateless packet that is 43 bytes or less in length SHOULD send a stateless
reset that is one byte shorter than the packet it responds to. reset that is one byte shorter than the packet it responds to.
These values assume that the Stateless Reset Token is the same as the These values assume that the Stateless Reset Token is the same length
minimum expansion of the packet protection AEAD. Additional as the minimum expansion of the packet protection AEAD. Additional
unpredictable bytes are necessary if the endpoint could have unpredictable bytes are necessary if the endpoint could have
negotiated a packet protection scheme with a larger minimum negotiated a packet protection scheme with a larger minimum
expansion. expansion.
An endpoint MUST NOT send a stateless reset that is three times or An endpoint MUST NOT send a stateless reset that is three times or
more larger than the packet it receives to avoid being used for more larger than the packet it receives to avoid being used for
amplification. Section 10.4.3 describes additional limits on amplification. Section 10.4.3 describes additional limits on
stateless reset size. stateless reset size.
Endpoints MUST discard packets that are too small to be valid QUIC Endpoints MUST discard packets that are too small to be valid QUIC
skipping to change at page 76, line 49 skipping to change at page 76, line 49
number space in one connection. If the packet number for sending number space in one connection. If the packet number for sending
reaches 2^62 - 1, the sender MUST close the connection without reaches 2^62 - 1, the sender MUST close the connection without
sending a CONNECTION_CLOSE frame or any further packets; an endpoint sending a CONNECTION_CLOSE frame or any further packets; an endpoint
MAY send a Stateless Reset (Section 10.4) in response to further MAY send a Stateless Reset (Section 10.4) in response to further
packets that it receives. packets that it receives.
A receiver MUST discard a newly unprotected packet unless it is A receiver MUST discard a newly unprotected packet unless it is
certain that it has not processed another packet with the same packet certain that it has not processed another packet with the same packet
number from the same packet number space. Duplicate suppression MUST number from the same packet number space. Duplicate suppression MUST
happen after removing packet protection for the reasons described in happen after removing packet protection for the reasons described in
Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate Section 9.3 of [QUIC-TLS].
suppression can be found in Section 3.4.3 of [RFC4303].
Endpoints that track all individual packets for the purposes of
detecting duplicates are at risk of accumulating excessive state.
The data required for detecting duplicates can be limited by
maintaining a minimum packet number below which all packets are
immediately dropped. Any minimum needs to account for large
variations in round trip time, which includes the possibility that a
peer might probe network paths with a much larger round trip times;
see Section 9.
Packet number encoding at a sender and decoding at a receiver are Packet number encoding at a sender and decoding at a receiver are
described in Section 17.1. described in Section 17.1.
12.4. Frames and Frame Types 12.4. Frames and Frame Types
The payload of QUIC packets, after removing packet protection, The payload of QUIC packets, after removing packet protection,
consists of a sequence of complete frames, as shown in Figure 10. consists of a sequence of complete frames, as shown in Figure 10.
Version Negotiation, Stateless Reset, and Retry packets do not Version Negotiation, Stateless Reset, and Retry packets do not
contain frames. contain frames.
skipping to change at page 80, line 35 skipping to change at page 80, line 35
A packet MUST NOT be acknowledged until packet protection has been A packet MUST NOT be acknowledged until packet protection has been
successfully removed and all frames contained in the packet have been successfully removed and all frames contained in the packet have been
processed. For STREAM frames, this means the data has been enqueued processed. For STREAM frames, this means the data has been enqueued
in preparation to be received by the application protocol, but it in preparation to be received by the application protocol, but it
does not require that data is delivered and consumed. does not require that data is delivered and consumed.
Once the packet has been fully processed, a receiver acknowledges Once the packet has been fully processed, a receiver acknowledges
receipt by sending one or more ACK frames containing the packet receipt by sending one or more ACK frames containing the packet
number of the received packet. number of the received packet.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it
did not send as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition.
13.2. Generating Acknowledgements 13.2. Generating Acknowledgements
Endpoints acknowledge all packets they receive and process. However, Endpoints acknowledge all packets they receive and process. However,
only ack-eliciting packets cause an ACK frame to be sent within the only ack-eliciting packets cause an ACK frame to be sent within the
maximum ack delay. Packets that are not ack-eliciting are only maximum ack delay. Packets that are not ack-eliciting are only
acknowledged when an ACK frame is sent for other reasons. acknowledged when an ACK frame is sent for other reasons.
When sending a packet for any reason, an endpoint SHOULD attempt to When sending a packet for any reason, an endpoint SHOULD attempt to
bundle an ACK frame if one has not been sent recently. Doing so bundle an ACK frame if one has not been sent recently. Doing so
helps with timely loss detection at the peer. helps with timely loss detection at the peer.
skipping to change at page 81, line 20 skipping to change at page 81, line 23
max_ack_delay transport parameter; see Section 18.2. max_ack_delay max_ack_delay transport parameter; see Section 18.2. max_ack_delay
declares an explicit contract: an endpoint promises to never declares an explicit contract: an endpoint promises to never
intentionally delay acknowledgments of an ack-eliciting packet by intentionally delay acknowledgments of an ack-eliciting packet by
more than the indicated value. If it does, any excess accrues to the more than the indicated value. If it does, any excess accrues to the
RTT estimate and could result in spurious or delayed retransmissions RTT estimate and could result in spurious or delayed retransmissions
from the peer. For Initial and Handshake packets, a max_ack_delay of from the peer. For Initial and Handshake packets, a max_ack_delay of
0 is used. The sender uses the receiver's max_ack_delay value in 0 is used. The sender uses the receiver's max_ack_delay value in
determining timeouts for timer-based retransmission, as detailed in determining timeouts for timer-based retransmission, as detailed in
Section 5.2.1 of [QUIC-RECOVERY]. Section 5.2.1 of [QUIC-RECOVERY].
An ACK frame SHOULD be generated for at least every second ack- Since packets containing only ACK frames are not congestion
eliciting packet. This recommendation is in keeping with standard controlled, an endpoint MUST NOT send more than one such packet in
practice for TCP [RFC5681]. A receiver could decide to send an ACK response to receiving an ack-eliciting packet.
frame less frequently if it has information about how frequently the
sender's congestion controller needs feedback, or if the receiver is An endpoint MUST NOT send a non-ack-eliciting packet in response to a
CPU or bandwidth constrained. non-ack-eliciting packet, even if there are packet gaps which precede
the received packet. This avoids an infinite feedback loop of
acknowledgements, which could prevent the connection from ever
becoming idle. Non-ack-eliciting packets are eventually acknowledged
when the endpoint sends an ACK frame in response to other events.
In order to assist loss detection at the sender, an endpoint SHOULD In order to assist loss detection at the sender, an endpoint SHOULD
send an ACK frame immediately on receiving an ack-eliciting packet send an ACK frame immediately on receiving an ack-eliciting packet
that is out of order. The endpoint SHOULD NOT continue sending ACK that is out of order. The endpoint SHOULD NOT continue sending ACK
frames immediately unless more ack-eliciting packets are received out frames immediately unless more ack-eliciting packets are received out
of order. If every subsequent ack-eliciting packet arrives out of of order. If every subsequent ack-eliciting packet arrives out of
order, then an ACK frame SHOULD be sent immediately for every order, then an ACK frame SHOULD be sent immediately for every
received ack-eliciting packet. received ack-eliciting packet.
Similarly, packets marked with the ECN Congestion Experienced (CE) Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to codepoint in the IP header SHOULD be acknowledged immediately, to
reduce the peer's response time to congestion events. reduce the peer's response time to congestion events.
As an optimization, a receiver MAY process multiple packets before The algorithms in [QUIC-RECOVERY] are expected to be resilient to
sending any ACK frames in response. In this case the receiver can receivers that do not follow guidance offered above. However, an
determine whether an immediate or delayed acknowledgement should be implementer should only deviate from these requirements after careful
generated after processing incoming packets. consideration of the performance implications of doing so.
Packets containing PADDING frames are considered to be in flight for
congestion control purposes [QUIC-RECOVERY]. Sending only PADDING
frames might cause the sender to become limited by the congestion
controller with no acknowledgments forthcoming from the receiver.
Therefore, a sender SHOULD ensure that other frames are sent in
addition to PADDING frames to elicit acknowledgments from the
receiver.
An endpoint that is only sending ACK frames will not receive An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are acknowledgments from its peer unless those acknowledgements are
included in packets with ack-eliciting frames. An endpoint SHOULD included in packets with ack-eliciting frames. An endpoint SHOULD
bundle ACK frames with other frames when there are new ack-eliciting bundle ACK frames with other frames when there are new ack-eliciting
packets to acknowledge. When only non-ack-eliciting packets need to packets to acknowledge. When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to bundle an ACK frame with outgoing frames. has been received to bundle an ACK frame with outgoing frames.
The algorithms in [QUIC-RECOVERY] are resilient to receivers that do 13.2.2. Acknowledgement Frequency
not follow guidance offered above. However, an implementor should
only deviate from these requirements after careful consideration of
the performance implications of doing so.
Packets containing only ACK frames are not congestion controlled, so A receiver determines how frequently to send acknowledgements in
there are limits on how frequently they can be sent. An endpoint response to ack-eliciting packets. This determination involves a
MUST NOT send more than one ACK-frame-only packet in response to tradeoff.
receiving an ack-eliciting packet. An endpoint MUST NOT send a non-
ack-eliciting packet in response to a non-ack-eliciting packet, even
if there are packet gaps which precede the received packet. Limiting
ACK frames avoids an infinite feedback loop of acknowledgements,
which could prevent the connection from ever becoming idle. However,
the endpoint acknowledges non-ACK-eliciting packets when it sends an
ACK frame.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it Endpoints rely on timely acknowledgment to detect loss; see Section 5
did not send as a connection error of type PROTOCOL_VIOLATION, if it of [QUIC-RECOVERY]. Window-based congestion controllers, such as the
is able to detect the condition. one in Section 6 of [QUIC-RECOVERY], rely on acknowledgments to
manage their congestion window. In both cases, delaying
acknowledgments can adversely affect performance.
13.2.2. Managing ACK Ranges On the other hand, reducing the frequency of packets that carry only
acknowledgements reduces packet transmission and processing cost at
both endpoints. It can also improve connection throughput on
severely asymmetric links; see Section 3 of [RFC3449].
A receiver SHOULD send an ACK frame after receiving at least two ack-
eliciting packets. This recommendation is general in nature and
consistent with recommendations for TCP endpoint behavior [RFC5681].
Knowledge of network conditions, knowledge of the peer's congestion
controller, or further research and experimentation might suggest
alternative acknowledgment strategies with better performance
characteristics.
A receiver MAY process multiple available packets before determining
whether to send an ACK frame in response.
13.2.3. Managing ACK Ranges
When an ACK frame is sent, one or more ranges of acknowledged packets When an ACK frame is sent, one or more ranges of acknowledged packets
are included. Including older packets reduces the chance of spurious are included. Including older packets reduces the chance of spurious
retransmits caused by losing previously sent ACK frames, at the cost retransmits caused by losing previously sent ACK frames, at the cost
of larger ACK frames. of larger ACK frames.
ACK frames SHOULD always acknowledge the most recently received ACK frames SHOULD always acknowledge the most recently received
packets, and the more out-of-order the packets are, the more packets, and the more out-of-order the packets are, the more
important it is to send an updated ACK frame quickly, to prevent the important it is to send an updated ACK frame quickly, to prevent the
peer from declaring a packet as lost and spuriously retransmitting peer from declaring a packet as lost and spuriously retransmitting
the frames it contains. An ACK frame is expected to fit within a the frames it contains. An ACK frame is expected to fit within a
single QUIC packet. If it does not, then older ranges (those with single QUIC packet. If it does not, then older ranges (those with
the smallest packet numbers) are omitted. the smallest packet numbers) are omitted.
Section 13.2.3 and Section 13.2.4 describe an exemplary approach for Section 13.2.4 and Section 13.2.5 describe an exemplary approach for
determining what packets to acknowledge in each ACK frame. Though determining what packets to acknowledge in each ACK frame. Though
the goal of these algorithms is to generate an acknowledgment for the goal of these algorithms is to generate an acknowledgment for
every packet that is processed, it is still possible for every packet that is processed, it is still possible for
acknowledgments to be lost. A sender cannot expect to receive an acknowledgments to be lost. A sender cannot expect to receive an
acknowledgment for every packet that the receiver processes. acknowledgment for every packet that the receiver processes.
13.2.3. Receiver Tracking of ACK Frames 13.2.4. Receiver Tracking of ACK Frames
When a packet containing an ACK frame is sent, the largest When a packet containing an ACK frame is sent, the largest
acknowledged in that frame may be saved. When a packet containing an acknowledged in that frame may be saved. When a packet containing an
ACK frame is acknowledged, the receiver can stop acknowledging ACK frame is acknowledged, the receiver can stop acknowledging
packets less than or equal to the largest acknowledged in the sent packets less than or equal to the largest acknowledged in the sent
ACK frame. ACK frame.
In cases without ACK frame loss, this algorithm allows for a minimum In cases without ACK frame loss, this algorithm allows for a minimum
of 1 RTT of reordering. In cases with ACK frame loss and reordering, of 1 RTT of reordering. In cases with ACK frame loss and reordering,
this approach does not guarantee that every acknowledgement is seen this approach does not guarantee that every acknowledgement is seen
by the sender before it is no longer included in the ACK frame. by the sender before it is no longer included in the ACK frame.
Packets could be received out of order and all subsequent ACK frames Packets could be received out of order and all subsequent ACK frames
containing them could be lost. In this case, the loss recovery containing them could be lost. In this case, the loss recovery
algorithm could cause spurious retransmits, but the sender will algorithm could cause spurious retransmits, but the sender will
continue making forward progress. continue making forward progress.
13.2.4. Limiting ACK Ranges 13.2.5. Limiting ACK Ranges
A receiver limits the number of ACK Ranges (Section 19.3.1) it A receiver limits the number of ACK Ranges (Section 19.3.1) it
remembers and sends in ACK frames, both to limit the size of ACK remembers and sends in ACK frames, both to limit the size of ACK
frames and to avoid resource exhaustion. After receiving frames and to avoid resource exhaustion. After receiving
acknowledgments for an ACK frame, the receiver SHOULD stop tracking acknowledgments for an ACK frame, the receiver SHOULD stop tracking
those acknowledged ACK Ranges. those acknowledged ACK Ranges.
It is possible that retaining many ACK Ranges could cause an ACK It is possible that retaining many ACK Ranges could cause an ACK
frame to become too large. A receiver can discard unacknowledged ACK frame to become too large. A receiver can discard unacknowledged ACK
Ranges to limit ACK frame size, at the cost of increased Ranges to limit ACK frame size, at the cost of increased
skipping to change at page 84, line 19 skipping to change at page 84, line 28
time. This could cause the receiver to maintain state for a large time. This could cause the receiver to maintain state for a large
number of ACK frames for a long period of time, and ACK frames it number of ACK frames for a long period of time, and ACK frames it
sends could be unnecessarily large. In such a case, a receiver could sends could be unnecessarily large. In such a case, a receiver could
bundle a PING or other small ack-eliciting frame occasionally, such bundle a PING or other small ack-eliciting frame occasionally, such
as once per round trip, to elicit an ACK from the peer. as once per round trip, to elicit an ACK from the peer.
A receiver MUST NOT bundle an ack-eliciting frame with all packets A receiver MUST NOT bundle an ack-eliciting frame with all packets
that would otherwise be non-ack-eliciting, to avoid an infinite that would otherwise be non-ack-eliciting, to avoid an infinite
feedback loop of acknowledgements. feedback loop of acknowledgements.
13.2.5. Measuring and Reporting Host Delay 13.2.6. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between the An endpoint measures the delays intentionally introduced between the
time the packet with the largest packet number is received and the time the packet with the largest packet number is received and the
time an acknowledgment is sent. The endpoint encodes this delay in time an acknowledgment is sent. The endpoint encodes this delay in
the Ack Delay field of an ACK frame; see Section 19.3. This allows the Ack Delay field of an ACK frame; see Section 19.3. This allows
the receiver of the ACK to adjust for any intentional delays, which the receiver of the ACK to adjust for any intentional delays, which
is important for getting a better estimate of the path RTT when is important for getting a better estimate of the path RTT when
acknowledgments are delayed. A packet might be held in the OS kernel acknowledgments are delayed. A packet might be held in the OS kernel
or elsewhere on the host before being processed. An endpoint MUST or elsewhere on the host before being processed. An endpoint MUST
NOT include delays that it does not control when populating the Ack NOT include delays that it does not control when populating the Ack
Delay field in an ACK frame. Delay field in an ACK frame.
13.2.6. ACK Frames and Packet Protection 13.2.7. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed; see Section 12.1. For number space as the packet being ACKed; see Section 12.1. For
instance, packets that are protected with 1-RTT keys MUST be instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys. acknowledged in packets that are also protected with 1-RTT keys.
Packets that a client sends with 0-RTT packet protection MUST be Packets that a client sends with 0-RTT packet protection MUST be
acknowledged by the server in packets protected by 1-RTT keys. This acknowledged by the server in packets protected by 1-RTT keys. This
can mean that the client is unable to use these acknowledgments if can mean that the client is unable to use these acknowledgments if
the server cryptographic handshake messages are delayed or lost. the server cryptographic handshake messages are delayed or lost.
skipping to change at page 84, line 43 skipping to change at page 85, line 4
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed; see Section 12.1. For number space as the packet being ACKed; see Section 12.1. For
instance, packets that are protected with 1-RTT keys MUST be instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys. acknowledged in packets that are also protected with 1-RTT keys.
Packets that a client sends with 0-RTT packet protection MUST be Packets that a client sends with 0-RTT packet protection MUST be
acknowledged by the server in packets protected by 1-RTT keys. This acknowledged by the server in packets protected by 1-RTT keys. This
can mean that the client is unable to use these acknowledgments if can mean that the client is unable to use these acknowledgments if
the server cryptographic handshake messages are delayed or lost. the server cryptographic handshake messages are delayed or lost.
Note that the same limitation applies to other data sent by the Note that the same limitation applies to other data sent by the
server protected by the 1-RTT keys. server protected by the 1-RTT keys.
13.2.8. PADDING Frames Consume Congestion Window
Packets containing PADDING frames are considered to be in flight for
congestion control purposes [QUIC-RECOVERY]. Packets containing only
PADDING frames therefore consume congestion window but do not
generate acknowledgments that will open the congestion window. To
avoid a deadlock, a sender SHOULD ensure that other frames are sent
periodically in addition to PADDING frames to elicit acknowledgments
from the receiver.
13.3. Retransmission of Information 13.3. Retransmission of Information
QUIC packets that are determined to be lost are not retransmitted QUIC packets that are determined to be lost are not retransmitted
whole. The same applies to the frames that are contained within lost whole. The same applies to the frames that are contained within lost
packets. Instead, the information that might be carried in frames is packets. Instead, the information that might be carried in frames is
sent again in new frames as needed. sent again in new frames as needed.
New frames and packets are used to carry information that is New frames and packets are used to carry information that is
determined to have been lost. In general, information is sent again determined to have been lost. In general, information is sent again
when a packet containing that information is determined to be lost when a packet containing that information is determined to be lost
skipping to change at page 102, line 12 skipping to change at page 102, line 20
message needs to be created, such as the packets sent after receiving message needs to be created, such as the packets sent after receiving
a Retry packet (Section 17.2.5). a Retry packet (Section 17.2.5).
A server sends its first Initial packet in response to a client A server sends its first Initial packet in response to a client
Initial. A server may send multiple Initial packets. The Initial. A server may send multiple Initial packets. The
cryptographic key exchange could require multiple round trips or cryptographic key exchange could require multiple round trips or
retransmissions of this data. retransmissions of this data.
The payload of an Initial packet includes a CRYPTO frame (or frames) The payload of an Initial packet includes a CRYPTO frame (or frames)
containing a cryptographic handshake message, ACK frames, or both. containing a cryptographic handshake message, ACK frames, or both.
PING, PADDING, and CONNECTION_CLOSE frames are also permitted. An PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also
endpoint that receives an Initial packet containing other frames can permitted. An endpoint that receives an Initial packet containing
either discard the packet as spurious or treat it as a connection other frames can either discard the packet as spurious or treat it as
error. a connection error.
The first packet sent by a client always includes a CRYPTO frame that The first packet sent by a client always includes a CRYPTO frame that
contains the start or all of the first cryptographic handshake contains the start or all of the first cryptographic handshake
message. The first CRYPTO frame sent always begins at an offset of message. The first CRYPTO frame sent always begins at an offset of
0; see Section 7. 0; see Section 7.
Note that if the server sends a HelloRetryRequest, the client will Note that if the server sends a HelloRetryRequest, the client will
send another series of Initial packets. These Initial packets will send another series of Initial packets. These Initial packets will
continue the cryptographic handshake and will contain CRYPTO frames continue the cryptographic handshake and will contain CRYPTO frames
starting at an offset matching the size of the CRYPTO frames sent in starting at an offset matching the size of the CRYPTO frames sent in
the first flight of Initial packets. the first flight of Initial packets.
17.2.2.1. Abandoning Initial Packets 17.2.2.1. Abandoning Initial Packets
A client stops both sending and processing Initial packets when it A client stops both sending and processing Initial packets when it
sends its first Handshake packet. A server stops sending and sends its first Handshake packet. A server stops sending and
processing Initial packets when it receives its first Handshake processing Initial packets when it receives its first Handshake
packet. Though packets might still be in flight or awaiting packet. Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged acknowledgment, no further Initial packets need to be exchanged
beyond this point. Initial packet protection keys are discarded (see beyond this point. Initial packet protection keys are discarded (see
Section 4.10.1 of [QUIC-TLS]) along with any loss recovery and Section 4.11.1 of [QUIC-TLS]) along with any loss recovery and
congestion control state; see Section 6.5 of [QUIC-RECOVERY]. congestion control state; see Section 6.5 of [QUIC-RECOVERY].
Any data in CRYPTO frames is discarded - and no longer retransmitted Any data in CRYPTO frames is discarded - and no longer retransmitted
- when Initial keys are discarded. - when Initial keys are discarded.
17.2.3. 0-RTT 17.2.3. 0-RTT
A 0-RTT packet uses long headers with a type value of 0x1, followed A 0-RTT packet uses long headers with a type value of 0x1, followed
by the Length and Packet Number fields. The first byte contains the by the Length and Packet Number fields. The first byte contains the
Reserved and Packet Number Length bits. It is used to carry "early" Reserved and Packet Number Length bits. It is used to carry "early"
skipping to change at page 104, line 50 skipping to change at page 105, line 13
connection ID that is chosen by the recipient of the packet; the connection ID that is chosen by the recipient of the packet; the
Source Connection ID includes the connection ID that the sender of Source Connection ID includes the connection ID that the sender of
the packet wishes to use; see Section 7.2. the packet wishes to use; see Section 7.2.
Handshake packets are their own packet number space, and thus the Handshake packets are their own packet number space, and thus the
first Handshake packet sent by a server contains a packet number of first Handshake packet sent by a server contains a packet number of
0. 0.
The payload of this packet contains CRYPTO frames and could contain The payload of this packet contains CRYPTO frames and could contain
PING, PADDING, or ACK frames. Handshake packets MAY contain PING, PADDING, or ACK frames. Handshake packets MAY contain
CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt
packets with other frames as a connection error. of Handshake packets with other frames as a connection error.
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames
for Handshake packets is discarded - and no longer retransmitted - for Handshake packets is discarded - and no longer retransmitted -
when Handshake protection keys are discarded. when Handshake protection keys are discarded.
17.2.5. Retry Packet 17.2.5. Retry Packet
A Retry packet uses a long packet header with a type value of 0x3. A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server. It is It carries an address validation token created by the server. It is
used by a server that wishes to perform a retry; see Section 8.1. used by a server that wishes to perform a retry; see Section 8.1.
skipping to change at page 105, line 49 skipping to change at page 106, line 12
Retry Integrity Tag: See the Retry Packet Integrity section of Retry Integrity Tag: See the Retry Packet Integrity section of
[QUIC-TLS]. [QUIC-TLS].
17.2.5.1. Sending a Retry Packet 17.2.5.1. Sending a Retry Packet
The server populates the Destination Connection ID with the The server populates the Destination Connection ID with the
connection ID that the client included in the Source Connection ID of connection ID that the client included in the Source Connection ID of
the Initial packet. the Initial packet.
The server includes a connection ID of its choice in the Source The server includes a connection ID of its choice in the Source
Connection ID field. This value MUST not be equal to the Destination Connection ID field. This value MUST NOT be equal to the Destination
Connection ID field of the packet sent by the client. A client MUST Connection ID field of the packet sent by the client. A client MUST
discard a Retry packet that contains a Source Connection ID field discard a Retry packet that contains a Source Connection ID field
that is identical to the Destination Connection ID field of its that is identical to the Destination Connection ID field of its
Initial packet. The client MUST use the value from the Source Initial packet. The client MUST use the value from the Source
Connection ID field of the Retry packet in the Destination Connection Connection ID field of the Retry packet in the Destination Connection
ID field of subsequent packets that it sends. ID field of subsequent packets that it sends.
A server MAY send Retry packets in response to Initial and 0-RTT A server MAY send Retry packets in response to Initial and 0-RTT
packets. A server can either discard or buffer 0-RTT packets that it packets. A server can either discard or buffer 0-RTT packets that it
receives. A server can send multiple Retry packets as it receives receives. A server can send multiple Retry packets as it receives
skipping to change at page 114, line 39 skipping to change at page 115, line 5
connection with an error of type TRANSPORT_PARAMETER_ERROR. If connection with an error of type TRANSPORT_PARAMETER_ERROR. If
this transport parameter is absent, a default of 2 is assumed. If this transport parameter is absent, a default of 2 is assumed. If
an endpoint issues a zero-length connection ID, it will never send an endpoint issues a zero-length connection ID, it will never send
a NEW_CONNECTION_ID frame and therefore ignores the a NEW_CONNECTION_ID frame and therefore ignores the
active_connection_id_limit value received from its peer. active_connection_id_limit value received from its peer.
initial_source_connection_id (0x0f): The value that the endpoint initial_source_connection_id (0x0f): The value that the endpoint
included in the Source Connection ID field of the first Initial included in the Source Connection ID field of the first Initial
packet it sends for the connection; see Section 7.3. packet it sends for the connection; see Section 7.3.
retry_source_connection_id (0x10): The value that the the server retry_source_connection_id (0x10): The value that the server
included in the Source Connection ID field of a Retry packet; see included in the Source Connection ID field of a Retry packet; see
Section 7.3. This transport parameter is only sent by a server. Section 7.3. This transport parameter is only sent by a server.
If present, transport parameters that set initial flow control limits If present, transport parameters that set initial flow control limits
(initial_max_stream_data_bidi_local, (initial_max_stream_data_bidi_local,
initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni)
are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on
every stream of the corresponding type immediately after opening. If every stream of the corresponding type immediately after opening. If
the transport parameter is absent, streams of that type start with a the transport parameter is absent, streams of that type start with a
flow control limit of 0. flow control limit of 0.
skipping to change at page 132, line 21 skipping to change at page 132, line 46
} }
Figure 39: CONNECTION_CLOSE Frame Format Figure 39: CONNECTION_CLOSE Frame Format
CONNECTION_CLOSE frames contain the following fields: CONNECTION_CLOSE frames contain the following fields:
Error Code: A variable length integer error code which indicates the Error Code: A variable length integer error code which indicates the
reason for closing this connection. A CONNECTION_CLOSE frame of reason for closing this connection. A CONNECTION_CLOSE frame of
type 0x1c uses codes from the space defined in Section 20. A type 0x1c uses codes from the space defined in Section 20. A
CONNECTION_CLOSE frame of type 0x1d uses codes from the CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space; see Section 20.1 application protocol error code space; see Section 20.1.
Frame Type: A variable-length integer encoding the type of frame Frame Type: A variable-length integer encoding the type of frame
that triggered the error. A value of 0 (equivalent to the mention that triggered the error. A value of 0 (equivalent to the mention
of the PADDING frame) is used when the frame type is unknown. The of the PADDING frame) is used when the frame type is unknown. The
application-specific variant of CONNECTION_CLOSE (type 0x1d) does application-specific variant of CONNECTION_CLOSE (type 0x1d) does
not include this field. not include this field.
Reason Phrase Length: A variable-length integer specifying the Reason Phrase Length: A variable-length integer specifying the
length of the reason phrase in bytes. Because a CONNECTION_CLOSE length of the reason phrase in bytes. Because a CONNECTION_CLOSE
frame cannot be split between packets, any limits on packet size frame cannot be split between packets, any limits on packet size
will also limit the space available for a reason phrase. will also limit the space available for a reason phrase.
Reason Phrase: A human-readable explanation for why the connection Reason Phrase: A human-readable explanation for why the connection
was closed. This can be zero length if the sender chooses to not was closed. This can be zero length if the sender chooses to not
give details beyond the Error Code. This SHOULD be a UTF-8 give details beyond the Error Code. This SHOULD be a UTF-8
encoded string [RFC3629]. encoded string [RFC3629].
The application-specific variant of CONNECTION_CLOSE (type 0x1d) can The application-specific variant of CONNECTION_CLOSE (type 0x1d) can
only be sent using 0-RTT or 1-RTT packets ([QUIC-TLS], Section 4). only be sent using 0-RTT or 1-RTT packets; see Section 4 of
When an application wishes to abandon a connection during the [QUIC-TLS]. When an application wishes to abandon a connection
handshake, an endpoint can send a CONNECTION_CLOSE frame (type 0x1c) during the handshake, an endpoint can send a CONNECTION_CLOSE frame
with an error code of APPLICATION_ERROR in an Initial or a Handshake (type 0x1c) with an error code of APPLICATION_ERROR in an Initial or
packet. a Handshake packet.
19.20. HANDSHAKE_DONE frame 19.20. HANDSHAKE_DONE frame
The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal
confirmation of the handshake to the client. The HANDSHAKE_DONE confirmation of the handshake to the client. The HANDSHAKE_DONE
frame contains no additional fields. frame contains no additional fields.
This frame can only be sent by the server. Servers MUST NOT send a This frame can only be sent by the server. Servers MUST NOT send a
HANDSHAKE_DONE frame before completing the handshake. A server MUST HANDSHAKE_DONE frame before completing the handshake. A server MUST
treat receipt of a HANDSHAKE_DONE frame as a connection error of type treat receipt of a HANDSHAKE_DONE frame as a connection error of type
skipping to change at page 134, line 5 skipping to change at page 134, line 28
used in a CONNECTION_CLOSE frame. These errors apply to the entire used in a CONNECTION_CLOSE frame. These errors apply to the entire
connection. connection.
NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to
signal that the connection is being closed abruptly in the absence signal that the connection is being closed abruptly in the absence
of any error. of any error.
INTERNAL_ERROR (0x1): The endpoint encountered an internal error and INTERNAL_ERROR (0x1): The endpoint encountered an internal error and
cannot continue with the connection. cannot continue with the connection.
SERVER_BUSY (0x2): The server is currently busy and does not accept CONNECTION_REFUSED (0x2): The server refused to accept a new
any new connections. connection.
FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it
permitted in its advertised data limits; see Section 4. permitted in its advertised data limits; see Section 4.
STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream
identifier that exceeded its advertised stream limit for the identifier that exceeded its advertised stream limit for the
corresponding stream type. corresponding stream type.
STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream
that was not in a state that permitted that frame; see Section 3. that was not in a state that permitted that frame; see Section 3.
skipping to change at page 153, line 16 skipping to change at page 153, line 16
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| Valu | Error | Description | Specification | | Valu | Error | Description | Specification |
| e | | | | | e | | | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x0 | NO_ERROR | No error | Section 20 | | 0x0 | NO_ERROR | No error | Section 20 |
| | | | | | | | | |
| 0x1 | INTERNAL_ERROR | Implementation | Section 20 | | 0x1 | INTERNAL_ERROR | Implementation | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0x2 | SERVER_BUSY | Server | Section 20 | | 0x2 | CONNECTION_REFUSED_ERROR | Server refuses | Section 20 |
| | | currently busy | | | | | a connection | |
| | | | | | | | | |
| 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 | | 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 |
| | | streams opened | | | | | streams opened | |
| | | | | | | | | |
| 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 |
| | | in invalid | | | | | in invalid | |
| | | stream state | | | | | stream state | |
skipping to change at page 154, line 27 skipping to change at page 154, line 27
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-21 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-21
(work in progress), May 2020. (work in progress), May 2020.
[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", draft-ietf-quic-recovery-28 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls-
tls-28 (work in progress). latest (work in progress).
[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 156, line 16 skipping to change at page 156, line 16
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-08 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-06 Transport Protocol", draft-ietf-quic-manageability-06
(work in progress), January 2020. (work in progress), January 2020.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
RFC 4303, DOI 10.17487/RFC4303, December 2005, Sooriyabandara, "TCP Performance Implications of Network
<https://www.rfc-editor.org/info/rfc4303>. Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
skipping to change at page 160, line 30 skipping to change at page 160, line 30
o Restored text on dropping bogus Version Negotiation packets o Restored text on dropping bogus Version Negotiation packets
(#3532, #3533) (#3532, #3533)
o Clarified that largest acknowledged needs to be saved, but not o Clarified that largest acknowledged needs to be saved, but not
necessarily signaled in all cases (#3541, #3581) necessarily signaled in all cases (#3541, #3581)
o Addressed linkability risk with the use of preferred_address o Addressed linkability risk with the use of preferred_address
(#3559, #3563) (#3559, #3563)
o Added authentication of handshake connection IDs (#3439, #3499)
o Opening a stream in the wrong direction is an error (#3527)
C.2. Since draft-ietf-quic-transport-26 C.2. Since draft-ietf-quic-transport-26
o Change format of transport parameters to use varints (#3294, o Change format of transport parameters to use varints (#3294,
#3169) #3169)
C.3. Since draft-ietf-quic-transport-25 C.3. Since draft-ietf-quic-transport-25
o Define the use of CONNECTION_CLOSE prior to establishing o Define the use of CONNECTION_CLOSE prior to establishing
connection state (#3269, #3297, #3292) connection state (#3269, #3297, #3292)
 End of changes. 64 change blocks. 
123 lines changed or deleted 163 lines changed or added

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