draft-ietf-quic-transport-29.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: December 11, 2020 Mozilla Expires: January 11, 2021 Mozilla
June 9, 2020 July 10, 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-29 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 December 11, 2020. This Internet-Draft will expire on January 11, 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13
2.4. Required Operations on Streams . . . . . . . . . . . . . 13 2.4. Required Operations on Streams . . . . . . . . . . . . . 13
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 14 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 14
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 16 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 16
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 19 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 19
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 19 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 19
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 20 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 20
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 21 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 22 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 22
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 23 4.2. Increasing Flow Control Limits . . . . . . . . . . . . . 23
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 24 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 24
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 24 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 24
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 25 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 25
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 26 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 27 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 27
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 29 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 29
5.2. Matching Packets to Connections . . . . . . . . . . . . . 30 5.2. Matching Packets to Connections . . . . . . . . . . . . . 30
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 31 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 31
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 31 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 31
skipping to change at page 3, line 19 skipping to change at page 3, line 19
7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 42 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 42
7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 42 7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 42
7.4.2. New Transport Parameters . . . . . . . . . . . . . . 44 7.4.2. New Transport Parameters . . . . . . . . . . . . . . 44
7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 44 7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 44
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 45 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 45
8.1. Address Validation During Connection Establishment . . . 45 8.1. Address Validation During Connection Establishment . . . 45
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 46 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 46
8.1.2. Address Validation using Retry Packets . . . . . . . 46 8.1.2. Address Validation using Retry Packets . . . . . . . 46
8.1.3. Address Validation for Future Connections . . . . . . 47 8.1.3. Address Validation for Future Connections . . . . . . 47
8.1.4. Address Validation Token Integrity . . . . . . . . . 50 8.1.4. Address Validation Token Integrity . . . . . . . . . 50
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 50 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 51
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 51 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 51
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 51 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 52
8.5. Successful Path Validation . . . . . . . . . . . . . . . 52 8.5. Successful Path Validation . . . . . . . . . . . . . . . 52
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 52 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 52
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 53 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 53
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 54 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 54
9.2. Initiating Connection Migration . . . . . . . . . . . . . 54 9.2. Initiating Connection Migration . . . . . . . . . . . . . 54
9.3. Responding to Connection Migration . . . . . . . . . . . 55 9.3. Responding to Connection Migration . . . . . . . . . . . 55
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 55 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 55
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 56 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 56
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 56 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 56
9.4. Loss Detection and Congestion Control . . . . . . . . . . 57 9.4. Loss Detection and Congestion Control . . . . . . . . . . 57
skipping to change at page 4, line 8 skipping to change at page 4, line 8
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 71 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 71
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 72 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 72
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 73 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 73
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 73 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 73
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 74 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 74
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 74 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 74
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 75 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 75
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 75 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 75
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 76 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 76
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 78 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 78
13. Packetization and Reliability . . . . . . . . . . . . . . . . 80 13. Packetization and Reliability . . . . . . . . . . . . . . . . 81
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 81 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 81
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 81 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 82
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 82 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 82
13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 83 13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 83
13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 83 13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 84
13.2.4. Receiver Tracking of ACK Frames . . . . . . . . . . 84 13.2.4. Receiver Tracking of ACK Frames . . . . . . . . . . 84
13.2.5. Limiting ACK Ranges . . . . . . . . . . . . . . . . 84 13.2.5. Limiting ACK Ranges . . . . . . . . . . . . . . . . 85
13.2.6. Measuring and Reporting Host Delay . . . . . . . . . 85 13.2.6. Measuring and Reporting Host Delay . . . . . . . . . 86
13.2.7. ACK Frames and Packet Protection . . . . . . . . . . 85 13.2.7. ACK Frames and Packet Protection . . . . . . . . . . 86
13.2.8. PADDING Frames Consume Congestion Window . . . . . . 86 13.2.8. PADDING Frames Consume Congestion Window . . . . . . 86
13.3. Retransmission of Information . . . . . . . . . . . . . 86 13.3. Retransmission of Information . . . . . . . . . . . . . 86
13.4. Explicit Congestion Notification . . . . . . . . . . . . 88 13.4. Explicit Congestion Notification . . . . . . . . . . . . 89
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 89 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 89
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 89 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 90
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 91 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 92
14.1. Initial Packet Size . . . . . . . . . . . . . . . . . . 92 14.1. Initial Packet Size . . . . . . . . . . . . . . . . . . 93
14.2. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 92 14.2. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 93
14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 93 14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 94
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 94 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 95
14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 94 14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 95
14.3.2. Validating the QUIC Path with DPLPMTUD . . . . . . . 94 14.3.2. Validating the QUIC Path with DPLPMTUD . . . . . . . 95
14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 95 14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 95
14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 95 14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 96
14.4.1. PMTU Probes Containing Source Connection ID . . . . 95 14.4.1. PMTU Probes Containing Source Connection ID . . . . 96
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 96 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 96
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 97 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 97
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 97 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 98
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 98 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 98
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 99 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 99
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 101 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 102
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 103 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 103
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 105 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 105
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 106 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 107
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 107 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 108
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 109 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 110
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 111 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 112
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 112 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 113
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 113 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 114
18.2. Transport Parameter Definitions . . . . . . . . . . . . 113 18.2. Transport Parameter Definitions . . . . . . . . . . . . 114
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 117 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 118
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 117 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 118
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 118 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 118
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 118 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 119
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 120 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 120
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 121 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 122
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 122 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 122
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 122 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 123
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 123 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 124
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 124 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 125
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 125 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 126
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 126 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 127
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 127 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 128
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 128 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 129
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 128 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 129
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 129 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 130
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 130 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 131
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 130 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 131
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 132 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 133
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 133 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 134
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 133 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 134
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 134 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 135
19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 135 19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 136
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 135 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 136
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 136 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 137
20.1. Application Protocol Error Codes . . . . . . . . . . . . 138 20.1. Application Protocol Error Codes . . . . . . . . . . . . 139
21. Security Considerations . . . . . . . . . . . . . . . . . . . 138 21. Security Considerations . . . . . . . . . . . . . . . . . . . 139
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 138 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 139
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 139 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 140
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 139 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 140
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 139 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 140
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 140 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 141
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 140 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 141
21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 141 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 142
21.8. Explicit Congestion Notification Attacks . . . . . . . . 141 21.8. Explicit Congestion Notification Attacks . . . . . . . . 142
21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 141 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 142
21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 142 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 143
21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 142 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 143
21.12. Overview of Security Properties . . . . . . . . . . . . 142 21.12. Overview of Security Properties . . . . . . . . . . . . 143
21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 143 21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 144
21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 145 21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 146
21.12.3. Connection Migration . . . . . . . . . . . . . . . 145 21.12.3. Connection Migration . . . . . . . . . . . . . . . 146
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 150 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151
22.1. Registration Policies for QUIC Registries . . . . . . . 150 22.1. Registration Policies for QUIC Registries . . . . . . . 151
22.1.1. Provisional Registrations . . . . . . . . . . . . . 150 22.1.1. Provisional Registrations . . . . . . . . . . . . . 151
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 151 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 152
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 151 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 152
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 152 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 153
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 152 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 153
22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 155 22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 156
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 155 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 156
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 157 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 158
23.1. Normative References . . . . . . . . . . . . . . . . . . 157 23.1. Normative References . . . . . . . . . . . . . . . . . . 158
23.2. Informative References . . . . . . . . . . . . . . . . . 158 23.2. Informative References . . . . . . . . . . . . . . . . . 160
23.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 160 23.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 160 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 162
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 161 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 162
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 162 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 163
C.1. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 162 C.1. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 163
C.2. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 162 C.2. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 164
C.3. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 164 C.3. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 165
C.4. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 164 C.4. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 165
C.5. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 164 C.5. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 165
C.6. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 165 C.6. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 166
C.7. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 166 C.7. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 167
C.8. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 167 C.8. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 168
C.9. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 167 C.9. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 168
C.10. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 168 C.10. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 169
C.11. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 168 C.11. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 170
C.12. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 169 C.12. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 170
C.13. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 170 C.13. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 171
C.14. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 171 C.14. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 172
C.15. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 171 C.15. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 172
C.16. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 171 C.16. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 172
C.17. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 172 C.17. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 173
C.18. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 173 C.18. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 174
C.19. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 173 C.19. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 174
C.20. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 174 C.20. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 175
C.21. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 175 C.21. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 176
C.22. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 175 C.22. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 176
C.23. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 176 C.23. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 177
C.24. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 176 C.24. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 178
C.25. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 177 C.25. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 178
C.26. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 177 C.26. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 179
C.27. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 178 C.27. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 179
C.28. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 179 C.28. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 180
C.29. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 181 C.29. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 182
C.30. Since draft-hamilton-quic-transport-protocol-01 . . . . . 181 C.30. Since draft-hamilton-quic-transport-protocol-01 . . . . . 182
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 183 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 184
1. Introduction 1. Introduction
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
o Stream multiplexing o Stream multiplexing
o Stream and connection-level flow control o Stream and connection-level flow control
o Low-latency connection establishment o Low-latency connection establishment
skipping to change at page 13, line 20 skipping to change at page 13, line 20
Stream multiplexing can have a significant effect on application Stream multiplexing can have a significant effect on application
performance if resources allocated to streams are correctly performance if resources allocated to streams are correctly
prioritized. prioritized.
QUIC does not provide a mechanism for exchanging prioritization QUIC does not provide a mechanism for exchanging prioritization
information. Instead, it relies on receiving priority information information. Instead, it relies on receiving priority information
from the application that uses QUIC. from the application that uses QUIC.
A QUIC implementation SHOULD provide ways in which an application can A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams. When deciding the streams indicate the relative priority of streams. An implementation uses
to which resources are dedicated, the implementation SHOULD use the information provided by the application to determine how to allocate
information provided by the application. resources to active streams.
2.4. Required Operations on Streams 2.4. Required Operations on Streams
There are certain operations that an application MUST be able to There are certain operations that an application MUST be able to
perform when interacting with QUIC streams. This document does not perform when interacting with QUIC streams. This document does not
specify an API, but any implementation of this version of QUIC MUST specify an API, but any implementation of this version of QUIC MUST
expose the ability to perform the operations described in this expose the ability to perform the operations described in this
section on a QUIC stream. section on a QUIC stream.
On the sending part of a stream, application protocols need to be On the sending part of a stream, application protocols need to be
skipping to change at page 14, line 25 skipping to change at page 14, line 25
streams on which an endpoint receives data (Section 3.2). streams on which an endpoint receives data (Section 3.2).
Unidirectional streams use the applicable state machine directly. Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines. For the most part, Bidirectional streams use both state machines. For the most part,
the use of these state machines is the same whether the stream is the use of these state machines is the same whether the stream is
unidirectional or bidirectional. The conditions for opening a stream unidirectional or bidirectional. The conditions for opening a stream
are slightly more complex for a bidirectional stream because the are slightly more complex for a bidirectional stream because the
opening of either the send or receive side causes the stream to open opening of either the send or receive side causes the stream to open
in both directions. in both directions.
An endpoint MUST open streams of the same type in increasing order of
stream ID.
Note: These states are largely informative. This document uses Note: These states are largely informative. This document uses
stream states to describe rules for when and how different types stream states to describe rules for when and how different types
of frames can be sent and the reactions that are expected when of frames can be sent and the reactions that are expected when
different types of frames are received. Though these state different types of frames are received. Though these state
machines are intended to be useful in implementing QUIC, these machines are intended to be useful in implementing QUIC, these
states aren't intended to constrain implementations. An states aren't intended to constrain implementations. An
implementation can define a different state machine as long as its implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements behavior is consistent with an implementation that implements
these states. these states.
skipping to change at page 22, line 23 skipping to change at page 22, line 23
Data sent in CRYPTO frames is not flow controlled in the same way as Data sent in CRYPTO frames is not flow controlled in the same way as
stream data. QUIC relies on the cryptographic protocol stream data. QUIC relies on the cryptographic protocol
implementation to avoid excessive buffering of data; see [QUIC-TLS]. implementation to avoid excessive buffering of data; see [QUIC-TLS].
The implementation SHOULD provide an interface to QUIC to tell it The implementation SHOULD provide an interface to QUIC to tell it
about its buffering limits so that there is not excessive buffering about its buffering limits so that there is not excessive buffering
at multiple layers. at multiple layers.
4.1. Data Flow Control 4.1. Data Flow Control
QUIC employs a credit-based flow-control scheme similar to that in QUIC employs a limit-based flow-control scheme where a receiver
HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is advertises the limit of total bytes it is prepared to receive on a
prepared to receive on a given stream and for the entire connection. given stream or for the entire connection. This leads to two levels
This leads to two levels of data flow control in QUIC: of data flow control in QUIC:
o Stream flow control, which prevents a single stream from consuming o Stream flow control, which prevents a single stream from consuming
the entire receive buffer for a connection by limiting the amount the entire receive buffer for a connection by limiting the amount
of data that can be sent on any stream. of data that can be sent on any stream.
o Connection flow control, which prevents senders from exceeding a o Connection flow control, which prevents senders from exceeding a
receiver's buffer capacity for the connection, by limiting the receiver's buffer capacity for the connection, by limiting the
total bytes of stream data sent in STREAM frames on all streams. total bytes of stream data sent in STREAM frames on all streams.
A receiver sets initial credits for all streams by sending transport A receiver sets initial limits for all streams by sending transport
parameters during the handshake (Section 7.4). A receiver sends parameters during the handshake (Section 7.4). A receiver sends
MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to
the sender to advertise additional credit. the sender to advertise larger limits.
A receiver advertises credit for a stream by sending a A receiver can advertise a larger limit for a stream by sending a
MAX_STREAM_DATA frame with the Stream ID field set appropriately. A MAX_STREAM_DATA frame with the Stream ID field set appropriately. A
MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a
stream. A receiver could use the current offset of data consumed to stream. A receiver could use the current offset of data consumed to
determine the flow control offset to be advertised. A receiver MAY determine the flow control offset to be advertised. A receiver MAY
send MAX_STREAM_DATA frames in multiple packets in order to make sure send MAX_STREAM_DATA frames in multiple packets in order to make sure
that the sender receives an update before running out of flow control that the sender receives an update before running out of flow
credit, even if one of the packets is lost. control, even if one of the packets is lost.
A receiver advertises credit for a connection by sending a MAX_DATA A receiver can advertise a larger limit for a connection by sending a
frame, which indicates the maximum of the sum of the absolute byte MAX_DATA frame, which indicates the maximum of the sum of the
offsets of all streams. A receiver maintains a cumulative sum of absolute byte offsets of all streams. A receiver maintains a
bytes received on all streams, which is used to check for flow cumulative sum of bytes received on all streams, which is used to
control violations. A receiver might use a sum of bytes consumed on check for flow control violations. A receiver might use a sum of
all streams to determine the maximum data limit to be advertised. bytes consumed on all streams to determine the maximum data limit to
be advertised.
A receiver can advertise a larger offset by sending MAX_STREAM_DATA Once a receiver advertises a limit for the connection or a stream, it
or MAX_DATA frames. Once a receiver advertises an offset, it MAY MAY advertise a smaller limit, but this has no effect.
advertise a smaller offset, but this has no effect.
A receiver MUST close the connection with a FLOW_CONTROL_ERROR error A receiver MUST close the connection with a FLOW_CONTROL_ERROR error
(Section 11) if the sender violates the advertised connection or (Section 11) if the sender violates the advertised connection or
stream data limits. stream data limits.
A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do
not increase flow control limits. not increase flow control limits.
If a sender runs out of flow control credit, it will be unable to If a sender has sent data up to the limit, it will be unable to send
send new data and is considered blocked. A sender SHOULD send a new data and is considered blocked. A sender SHOULD send a
STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to
write but is blocked by flow control limits. If a sender is blocked write but is blocked by flow control limits. If a sender is blocked
for a period longer than the idle timeout (Section 10.2), the for a period longer than the idle timeout (Section 10.2), the
connection might be closed even when data is available for connection might be closed even when data is available for
transmission. To keep the connection from closing, a sender that is transmission. To keep the connection from closing, a sender that is
flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED
or DATA_BLOCKED frame when it has no ack-eliciting packets in flight. or DATA_BLOCKED frame when it has no ack-eliciting packets in flight.
4.2. Flow Credit Increments 4.2. Increasing Flow Control Limits
Implementations decide when and how much credit to advertise in Implementations decide when and how much credit to advertise in
MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few
considerations. considerations.
To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or
MAX_DATA frame multiple times within a round trip or send it early MAX_DATA frame multiple times within a round trip or send it early
enough to allow for recovery from loss of the frame. enough to allow for recovery from loss of the frame.
Control frames contribute to connection overhead. Therefore, Control frames contribute to connection overhead. Therefore,
skipping to change at page 30, line 45 skipping to change at page 30, line 45
becomes unusable. becomes unusable.
Packets that are matched to an existing connection are discarded if Packets that are matched to an existing connection are discarded if
the packets are inconsistent with the state of that connection. For the packets are inconsistent with the state of that connection. For
example, packets are discarded if they indicate a different protocol example, packets are discarded if they indicate a different protocol
version than that of the connection, or if the removal of packet version than that of the connection, or if the removal of packet
protection is unsuccessful once the expected keys are available. protection is unsuccessful once the expected keys are available.
Invalid packets without packet protection, such as Initial, Retry, or Invalid packets without packet protection, such as Initial, Retry, or
Version Negotiation, MAY be discarded. An endpoint MUST generate a Version Negotiation, MAY be discarded. An endpoint MUST generate a
connection error if it commits changes to state before discovering an connection error if processing of the contents of these packets prior
error. to discovering an error resulted in changes to the state of a
connection that cannot be reverted.
5.2.1. Client Packet Handling 5.2.1. Client Packet Handling
Valid packets sent to clients always include a Destination Connection Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects. Clients that choose to ID that matches a value the client selects. Clients that choose to
receive zero-length connection IDs can use the local address and port receive zero-length connection IDs can use the local address and port
to identify a connection. Packets that don't match an existing to identify a connection. Packets that don't match an existing
connection are discarded. connection are discarded.
Due to packet reordering or loss, a client might receive packets for Due to packet reordering or loss, a client might receive packets for
skipping to change at page 31, line 41 skipping to change at page 31, line 41
semantics and encodings for any version-specific field. In semantics and encodings for any version-specific field. In
particular, different packet protection keys might be used for particular, different packet protection keys might be used for
different versions. Servers that do not support a particular version different versions. Servers that do not support a particular version
are unlikely to be able to decrypt the payload of the packet. are unlikely to be able to decrypt the payload of the packet.
Servers SHOULD NOT attempt to decode or decrypt a packet from an Servers SHOULD NOT attempt to decode or decrypt a packet from an
unknown version, but instead send a Version Negotiation packet, unknown version, but instead send a Version Negotiation packet,
provided that the packet is sufficiently long. provided that the packet is sufficiently long.
Packets with a supported version, or no version field, are matched to Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero- a connection using the connection ID or - for packets with zero-
length connection IDs - the local address and port. If the packet length connection IDs - the local address and port. These packets
doesn't match an existing connection, the server continues below. are processed using the selected connection; otherwise, 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 refuses to accept a new connection, it SHOULD send an If a server refuses to accept a new connection, it SHOULD send an
Initial packet containing a CONNECTION_CLOSE frame with error code Initial packet containing a CONNECTION_CLOSE frame with error code
CONNECTION_REFUSED. 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
skipping to change at page 34, line 37 skipping to change at page 34, line 37
6. Version Negotiation 6. Version Negotiation
Version negotiation ensures that client and server agree to a QUIC Version negotiation ensures that client and server agree to a QUIC
version that is mutually supported. A server sends a Version version that is mutually supported. A server sends a Version
Negotiation packet in response to each packet that might initiate a Negotiation packet in response to each packet that might initiate a
new connection; see Section 5.2 for details. new connection; see Section 5.2 for details.
The size of the first packet sent by a client will determine whether The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet. Clients that support a server sends a Version Negotiation packet. Clients that support
multiple QUIC versions SHOULD pad the first packet they send to the multiple QUIC versions SHOULD pad the first UDP datagram they send to
largest of the minimum packet sizes across all versions they support. the largest of the minimum datagram sizes from all versions they
This ensures that the server responds if there is a mutually support. This ensures that the server responds if there is a
supported version. mutually supported version.
6.1. Sending Version Negotiation Packets 6.1. Sending Version Negotiation Packets
If the version selected by the client is not acceptable to the If the version selected by the client is not acceptable to the
server, the server responds with a Version Negotiation packet; see server, the server responds with a Version Negotiation packet; see
Section 17.2.1. This includes a list of versions that the server Section 17.2.1. This includes a list of versions that the server
will accept. An endpoint MUST NOT send a Version Negotiation packet will accept. An endpoint MUST NOT send a Version Negotiation packet
in response to receiving a Version Negotiation packet. in response to receiving a Version Negotiation packet.
This system allows a server to process packets with unsupported This system allows a server to process packets with unsupported
skipping to change at page 37, line 12 skipping to change at page 37, line 12
* 1-RTT keys have forward secrecy * 1-RTT keys have forward secrecy
o authenticated values for transport parameters of both endpoints, o authenticated values for transport parameters of both endpoints,
and confidentiality protection for server transport parameters and confidentiality protection for server transport parameters
(see Section 7.4) (see Section 7.4)
o authenticated negotiation of an application protocol (TLS uses o authenticated negotiation of an application protocol (TLS uses
ALPN [RFC7301] for this purpose) ALPN [RFC7301] for this purpose)
An endpoint can verify support for Explicit Congestion Notification An endpoint verifies support for Explicit Congestion Notification
(ECN) in the first packets it sends, as described in Section 13.4.2. (ECN) in the first packets it sends, as described in Section 13.4.2.
The CRYPTO frame can be sent in different packet number spaces The CRYPTO frame can be sent in different packet number spaces
(Section 12.3). The offsets used by CRYPTO frames to ensure ordered (Section 12.3). The offsets used by CRYPTO frames to ensure ordered
delivery of cryptographic handshake data start from zero in each delivery of cryptographic handshake data start from zero in each
packet number space. packet number space.
Endpoints MUST explicitly negotiate an application protocol. This Endpoints MUST explicitly negotiate an application protocol. This
avoids situations where there is a disagreement about the protocol avoids situations where there is a disagreement about the protocol
that is in use. that is in use.
skipping to change at page 43, line 51 skipping to change at page 43, line 51
o initial_max_streams_uni o initial_max_streams_uni
Omitting or setting a zero value for certain transport parameters can Omitting or setting a zero value for certain transport parameters can
result in 0-RTT data being enabled, but not usable. The applicable result in 0-RTT data being enabled, but not usable. The applicable
subset of transport parameters that permit sending of application subset of transport parameters that permit sending of application
data SHOULD be set to non-zero values for 0-RTT. This includes data SHOULD be set to non-zero values for 0-RTT. This includes
initial_max_data and either initial_max_streams_bidi and initial_max_data and either initial_max_streams_bidi and
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_bidi_remote, or initial_max_streams_uni and
initial_max_stream_data_uni. initial_max_stream_data_uni.
A server MAY store and recover the previously sent values of the
max_idle_timout, max_udp_payload_size, and disable_active_migration
parameters and reject 0-RTT if it selects smaller values. Lowering
the values of these parameters while also accepting 0-RTT data could
degrade the performance of the connection. Specifically, lowering
the max_udp_payload_size could result in dropped packets leading to
worse performance compared to rejecting 0-RTT data outright.
A server MUST either reject 0-RTT data or abort a handshake if the A server MUST either reject 0-RTT data or abort a handshake if the
implied values for transport parameters cannot be supported. implied values for transport parameters cannot be supported.
When sending frames in 0-RTT packets, a client MUST only use When sending frames in 0-RTT packets, a client MUST only use
remembered transport parameters; importantly, it MUST NOT use updated remembered transport parameters; importantly, it MUST NOT use updated
values that it learns from the server's updated transport parameters values that it learns from the server's updated transport parameters
or from frames received in 1-RTT packets. Updated values of or from frames received in 1-RTT packets. Updated values of
transport parameters from the handshake apply only to 1-RTT packets. transport parameters from the handshake apply only to 1-RTT packets.
For instance, flow control limits from remembered transport For instance, flow control limits from remembered transport
parameters apply to all 0-RTT packets even if those values are parameters apply to all 0-RTT packets even if those values are
skipping to change at page 44, line 36 skipping to change at page 44, line 44
Section 22.2. Section 22.2.
7.5. Cryptographic Message Buffering 7.5. Cryptographic Message Buffering
Implementations need to maintain a buffer of CRYPTO data received out Implementations need to maintain a buffer of CRYPTO data received out
of order. Because there is no flow control of CRYPTO frames, an of order. Because there is no flow control of CRYPTO frames, an
endpoint could potentially force its peer to buffer an unbounded endpoint could potentially force its peer to buffer an unbounded
amount of data. amount of data.
Implementations MUST support buffering at least 4096 bytes of data Implementations MUST support buffering at least 4096 bytes of data
received in out of order CRYPTO frames. Endpoints MAY choose to received in out-of-order CRYPTO frames. Endpoints MAY choose to
allow more data to be buffered during the handshake. A larger limit allow more data to be buffered during the handshake. A larger limit
during the handshake could allow for larger keys or credentials to be during the handshake could allow for larger keys or credentials to be
exchanged. An endpoint's buffer size does not need to remain exchanged. An endpoint's buffer size does not need to remain
constant during the life of the connection. constant during the life of the connection.
Being unable to buffer CRYPTO frames during the handshake can lead to Being unable to buffer CRYPTO frames during the handshake can lead to
a connection failure. If an endpoint's buffer is exceeded during the a connection failure. If an endpoint's buffer is exceeded during the
handshake, it can expand its buffer temporarily to complete the handshake, it can expand its buffer temporarily to complete the
handshake. If an endpoint does not expand its buffer, it MUST close handshake. If an endpoint does not expand its buffer, it MUST close
the connection with a CRYPTO_BUFFER_EXCEEDED error code. the connection with a CRYPTO_BUFFER_EXCEEDED error code.
skipping to change at page 52, line 18 skipping to change at page 52, line 28
additional PATH_RESPONSE frames. additional PATH_RESPONSE frames.
8.5. Successful Path Validation 8.5. Successful Path Validation
A new address is considered valid when a PATH_RESPONSE frame is A new address is considered valid when a PATH_RESPONSE frame is
received that contains the data that was sent in a previous received that contains the data that was sent in a previous
PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing
a PATH_CHALLENGE frame is not adequate validation, since the a PATH_CHALLENGE frame is not adequate validation, since the
acknowledgment can be spoofed by a malicious peer. acknowledgment can be spoofed by a malicious peer.
Note that receipt on a different local address does not result in
path validation failure, as it might be a result of a forwarded
packet (see Section 9.3.3) or misrouting. It is possible that a
valid PATH_RESPONSE might be received in the future.
8.6. Failed Path Validation 8.6. Failed Path Validation
Path validation only fails when the endpoint attempting to validate Path validation only fails when the endpoint attempting to validate
the path abandons its attempt to validate the path. the path abandons its attempt to validate the path.
Endpoints SHOULD abandon path validation based on a timer. When Endpoints SHOULD abandon path validation based on a timer. When
setting this timer, implementations are cautioned that the new path setting this timer, implementations are cautioned that the new path
could have a longer round-trip time than the original. A value of could have a longer round-trip time than the original. A value of
three times the larger of the current Probe Timeout (PTO) or the three times the larger of the current Probe Timeout (PTO) or the
initial timeout (that is, 2*kInitialRtt) as defined in initial timeout (that is, 2*kInitialRtt) as defined in
skipping to change at page 54, line 50 skipping to change at page 54, line 50
When migrating, the new path might not support the endpoint's current When migrating, the new path might not support the endpoint's current
sending rate. Therefore, the endpoint resets its congestion sending rate. Therefore, the endpoint resets its congestion
controller, as described in Section 9.4. controller, as described in Section 9.4.
The new path might not have the same ECN capability. Therefore, the The new path might not have the same ECN capability. Therefore, the
endpoint verifies ECN capability as described in Section 13.4. endpoint verifies ECN capability as described in Section 13.4.
Receiving acknowledgments for data sent on the new path serves as Receiving acknowledgments for data sent on the new path serves as
proof of the peer's reachability from the new address. Note that proof of the peer's reachability from the new address. Note that
since acknowledgments may be received on any path, return since acknowledgments may be received on any path, return
reachability on the new path is not established. To establish return reachability on the new path is not established. No method is
provided to establish return reachability, as endpoints independently
determine reachability on each direction of a path. To establish
reachability on the new path, an endpoint MAY concurrently initiate reachability on the new path, an endpoint MAY concurrently initiate
path validation Section 8.2 on the new path or it MAY choose to wait path validation Section 8.2 on the new path. An endpoint MAY defer
for the peer to send the next non-probing frame to its new address. path validation until after a peer sends the next non-probing frame
to its new address.
9.3. Responding to Connection Migration 9.3. Responding to Connection Migration
Receiving a packet from a new peer address containing a non-probing Receiving a packet from a new peer address containing a non-probing
frame indicates that the peer has migrated to that address. frame indicates that the peer has migrated to that address.
In response to such a packet, an endpoint MUST start sending In response to such a packet, an endpoint MUST start sending
subsequent packets to the new peer address and MUST initiate path subsequent packets to the new peer address and MUST initiate path
validation (Section 8.2) to verify the peer's ownership of the validation (Section 8.2) to verify the peer's ownership of the
unvalidated address. unvalidated address.
skipping to change at page 62, line 27 skipping to change at page 62, line 27
on any path. on any path.
9.7. Use of IPv6 Flow-Label and Migration 9.7. Use of IPv6 Flow-Label and Migration
Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label
in compliance with [RFC6437], unless the local API does not allow in compliance with [RFC6437], unless the local API does not allow
setting IPv6 flow labels. setting IPv6 flow labels.
The IPv6 flow label SHOULD be a pseudo-random function of the source The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the and destination addresses, source and destination UDP ports, and the
destination CID. The flow label generation MUST be designed to Destination Connection ID field. The flow label generation MUST be
minimize the chances of linkability with a previously used flow designed to minimize the chances of linkability with a previously
label, as this would enable correlating activity on multiple paths; used flow label, as this would enable correlating activity on
see Section 9.5. multiple paths; see Section 9.5.
A possible implementation is to compute the flow label as a A possible implementation is to compute the flow label as a
cryptographic hash function of the source and destination addresses, cryptographic hash function of the source and destination addresses,
source and destination UDP ports, destination CID, and a local source and destination UDP ports, Destination Connection ID field,
secret. and a local secret.
10. Connection Termination 10. Connection Termination
An established QUIC connection can be terminated in one of three An established QUIC connection can be terminated in one of three
ways: ways:
o idle timeout (Section 10.2) o idle timeout (Section 10.2)
o immediate close (Section 10.3) o immediate close (Section 10.3)
skipping to change at page 65, line 27 skipping to change at page 65, line 27
Application protocols that use QUIC SHOULD provide guidance on when Application protocols that use QUIC SHOULD provide guidance on when
deferring an idle timeout is appropriate. Unnecessary sending of deferring an idle timeout is appropriate. Unnecessary sending of
PING frames could have a detrimental effect on performance. PING frames could have a detrimental effect on performance.
A connection will time out if no packets are sent or received for a A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout period longer than the time negotiated using the max_idle_timeout
transport parameter; see Section 10. However, state in middleboxes transport parameter; see Section 10. However, state in middleboxes
might time out earlier than that. Though REQ-5 in [RFC4787] might time out earlier than that. Though REQ-5 in [RFC4787]
recommends a 2 minute timeout interval, experience shows that sending recommends a 2 minute timeout interval, experience shows that sending
packets every 15 to 30 seconds is necessary to prevent the majority packets every 30 seconds is necessary to prevent the majority of
of middleboxes from losing state for UDP flows. middleboxes from losing state for UDP flows [GATEWAY].
10.3. Immediate Close 10.3. Immediate Close
An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to
terminate the connection immediately. A CONNECTION_CLOSE frame terminate the connection immediately. A CONNECTION_CLOSE frame
causes all streams to immediately become closed; open streams can be causes all streams to immediately become closed; open streams can be
assumed to be implicitly reset. assumed to be implicitly reset.
After sending a CONNECTION_CLOSE frame, an endpoint immediately After sending a CONNECTION_CLOSE frame, an endpoint immediately
enters the closing state. enters the closing state.
skipping to change at page 68, line 46 skipping to change at page 68, line 46
} }
Figure 9: Stateless Reset Packet Figure 9: Stateless Reset Packet
This design ensures that a stateless reset packet is - to the extent This design ensures that a stateless reset packet is - to the extent
possible - indistinguishable from a regular packet with a short possible - indistinguishable from a regular packet with a short
header. header.
A stateless reset uses an entire UDP datagram, starting with the A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header. The remainder of the first byte first two bits of the packet header. The remainder of the first byte
and an arbitrary number of bytes following it that are set to and an arbitrary number of bytes following it that are set to values
unpredictable values. The last 16 bytes of the datagram contain a that SHOULD be indistinguishable from random. The last 16 bytes of
Stateless Reset Token. the datagram contain a Stateless Reset Token.
To entities other than its intended recipient, a stateless reset will To entities other than its intended recipient, a stateless reset will
appear to be a packet with a short header. For the stateless reset appear to be a packet with a short header. For the stateless reset
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
skipping to change at page 75, line 8 skipping to change at page 75, line 8
uses a version-independent packet with a long header; see uses a version-independent packet with a long header; see
Section 17.2.1. Section 17.2.1.
Packets with the short header are designed for minimal overhead and Packets with the short header are designed for minimal overhead and
are used after a connection is established and 1-RTT keys are are used after a connection is established and 1-RTT keys are
available; see Section 17.3. available; see Section 17.3.
12.1. Protected Packets 12.1. Protected Packets
All QUIC packets except Version Negotiation packets use authenticated All QUIC packets except Version Negotiation packets use authenticated
encryption with additional data (AEAD) [RFC5116] to provide encryption with associated data (AEAD) [RFC5116] to provide
confidentiality and integrity protection. Retry packets use AEAD to confidentiality and integrity protection. Retry packets use AEAD to
provide integrity protection. Details of packet protection are found provide integrity protection. Details of packet protection are found
in [QUIC-TLS]; this section includes an overview of the process. in [QUIC-TLS]; this section includes an overview of the process.
Initial packets are protected using keys that are statically derived. Initial packets are protected using keys that are statically derived.
This packet protection is not effective confidentiality protection. This packet protection is not effective confidentiality protection.
Initial protection only exists to ensure that the sender of the Initial protection only exists to ensure that the sender of the
packet is on the network path. Any entity that receives the Initial packet is on the network path. Any entity that receives the Initial
packet from a client can recover the keys necessary to remove packet packet from a client can recover the keys necessary to remove packet
protection or to generate packets that will be successfully protection or to generate packets that will be successfully
skipping to change at page 76, line 9 skipping to change at page 76, line 9
Section 14.4.1. Receivers MUST be able to process coalesced packets. Section 14.4.1. Receivers MUST be able to process coalesced packets.
Coalescing packets in order of increasing encryption levels (Initial, Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it
more likely the receiver will be able to process all the packets in a more likely the receiver will be able to process all the packets in a
single pass. A packet with a short header does not include a length, single pass. A packet with a short header does not include a length,
so it can only be the last packet included in a UDP datagram. An so it can only be the last packet included in a UDP datagram. An
endpoint SHOULD NOT coalesce multiple packets at the same encryption endpoint SHOULD NOT coalesce multiple packets at the same encryption
level. level.
Senders MUST NOT coalesce QUIC packets for different connections into Receivers MAY route based on the information in the first packet
a single UDP datagram. Receivers SHOULD ignore any subsequent contained in a UDP datagram. Senders MUST NOT coalesce QUIC packets
packets with a different Destination Connection ID than the first for different connections into a single UDP datagram. Receivers
packet in the datagram. SHOULD ignore any subsequent packets with a different Destination
Connection ID than the first packet in the datagram.
Every QUIC packet that is coalesced into a single UDP datagram is Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete. The receiver of coalesced QUIC packets MUST separate and complete. The receiver of coalesced QUIC packets MUST
individually process each QUIC packet and separately acknowledge individually process each QUIC packet and separately acknowledge
them, as if they were received as the payload of different UDP them, as if they were received as the payload of different UDP
datagrams. For example, if decryption fails (because the keys are datagrams. For example, if decryption fails (because the keys are
not available or any other reason), the receiver MAY either discard not available or any other reason), the receiver MAY either discard
or buffer the packet for later processing and MUST attempt to process or buffer the packet for later processing and MUST attempt to process
the remaining packets. the remaining packets.
skipping to change at page 79, line 5 skipping to change at page 79, line 5
} }
Figure 11: Generic Frame Layout Figure 11: Generic Frame Layout
The frame types defined in this specification are listed in Table 3. The frame types defined in this specification are listed in Table 3.
The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and
CONNECTION_CLOSE frames is used to carry other frame-specific flags. CONNECTION_CLOSE frames is used to carry other frame-specific flags.
For all other frames, the Frame Type field simply identifies the For all other frames, the Frame Type field simply identifies the
frame. These frames are explained in more detail in Section 19. frame. These frames are explained in more detail in Section 19.
+-------------+----------------------+----------------+---------+ +-------------+----------------------+----------------+------+------+
| Type Value | Frame Type Name | Definition | Packets | | Type Value | Frame Type Name | Definition | Pkts | Spec |
+-------------+----------------------+----------------+---------+ +-------------+----------------------+----------------+------+------+
| 0x00 | PADDING | Section 19.1 | IH01 | | 0x00 | PADDING | Section 19.1 | IH01 | NP |
| | | | | | | | | | |
| 0x01 | PING | Section 19.2 | IH01 | | 0x01 | PING | Section 19.2 | IH01 | |
| | | | | | | | | | |
| 0x02 - 0x03 | ACK | Section 19.3 | IH_1 | | 0x02 - 0x03 | ACK | Section 19.3 | IH_1 | NC |
| | | | | | | | | | |
| 0x04 | RESET_STREAM | Section 19.4 | __01 | | 0x04 | RESET_STREAM | Section 19.4 | __01 | |
| | | | | | | | | | |
| 0x05 | STOP_SENDING | Section 19.5 | __01 | | 0x05 | STOP_SENDING | Section 19.5 | __01 | |
| | | | | | | | | | |
| 0x06 | CRYPTO | Section 19.6 | IH_1 | | 0x06 | CRYPTO | Section 19.6 | IH_1 | |
| | | | | | | | | | |
| 0x07 | NEW_TOKEN | Section 19.7 | ___1 | | 0x07 | NEW_TOKEN | Section 19.7 | ___1 | |
| | | | | | | | | | |
| 0x08 - 0x0f | STREAM | Section 19.8 | __01 | | 0x08 - 0x0f | STREAM | Section 19.8 | __01 | F |
| | | | | | | | | | |
| 0x10 | MAX_DATA | Section 19.9 | __01 | | 0x10 | MAX_DATA | Section 19.9 | __01 | |
| | | | | | | | | | |
| 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | | 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | |
| | | | | | | | | | |
| 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | __01 | | 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | __01 | |
| | | | | | | | | | |
| 0x14 | DATA_BLOCKED | Section 19.12 | __01 | | 0x14 | DATA_BLOCKED | Section 19.12 | __01 | |
| | | | | | | | | | |
| 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | |
| | | | | | | | | | |
| 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | |
| | | | | | | | | | |
| 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | | 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 | | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P |
| | | | | | | | | | |
| 0x1b | PATH_RESPONSE | Section 19.18 | __01 | | 0x1b | PATH_RESPONSE | Section 19.18 | __01 | P |
| | | | | | | | | | |
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | |
| | | | | | | | | | |
| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | |
+-------------+----------------------+----------------+---------+ +-------------+----------------------+----------------+------+------+
Table 3: Frame Types Table 3: Frame Types
The "Packets" column in Table 3 does not form part of the IANA The "Pkts" column in Table 3 lists the types of packets that each
registry; see Section 22.3. This column lists the types of packets frame type could appear in, indicated by the following characters:
that each frame type could appear in, indicated by the following
characters:
I: Initial (Section 17.2.2) I: Initial (Section 17.2.2)
H: Handshake (Section 17.2.4) H: Handshake (Section 17.2.4)
0: 0-RTT (Section 17.2.3) 0: 0-RTT (Section 17.2.3)
1: 1-RTT (Section 17.3) 1: 1-RTT (Section 17.3)
ih: A CONNECTION_CLOSE frame of type 0x1d cannot appear in Initial ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial
or Handshake packets. or Handshake packets.
Section 4 of [QUIC-TLS] provides more detail about these Section 4 of [QUIC-TLS] provides more detail about these
restrictions. Note that all frames can appear in 1-RTT packets. restrictions. Note that all frames can appear in 1-RTT packets.
The "Spec" column in Table 3 summarizes any special rules governing
the processing or generation of the frame type, as indicated by the
following characters:
N: Packets containing only frames with this marking are not ack-
eliciting; see Section 13.2.
C: Packets containing only frames with this marking do not count
toward bytes in flight for congestion control purposes; see
[QUIC-RECOVERY].
P: Packets containing only frames with this marking can be used to
probe new network paths during connection migration; see
Section 9.1.
F: The content of frames with this marking are flow controlled; see
Section 4.
The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA
registry; see Section 22.3.
An endpoint MUST treat the receipt of a frame of unknown type as a An endpoint MUST treat the receipt of a frame of unknown type as a
connection error of type FRAME_ENCODING_ERROR. connection error of type FRAME_ENCODING_ERROR.
All QUIC frames are idempotent in this version of QUIC. That is, a All QUIC frames are idempotent in this version of QUIC. That is, a
valid frame does not cause undesirable side effects or errors when valid frame does not cause undesirable side effects or errors when
received more than once. received more than once.
The Frame Type field uses a variable length integer encoding (see The Frame Type field uses a variable length integer encoding (see
Section 16) with one exception. To ensure simple and efficient Section 16) with one exception. To ensure simple and efficient
implementations of frame parsing, a frame type MUST use the shortest implementations of frame parsing, a frame type MUST use the shortest
skipping to change at page 82, line 48 skipping to change at page 83, line 19
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.
The algorithms in [QUIC-RECOVERY] are expected to be resilient to The algorithms in [QUIC-RECOVERY] are expected to be resilient to
receivers that do not follow guidance offered above. However, an receivers that do not follow guidance offered above. However, an
implementer should only deviate from these requirements after careful implementation should only deviate from these requirements after
consideration of the performance implications of doing so. careful consideration of the performance implications of a change,
for connections made by the endpoint and for other users of the
network.
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.
13.2.2. Acknowledgement Frequency 13.2.2. Acknowledgement Frequency
A receiver determines how frequently to send acknowledgements in A receiver determines how frequently to send acknowledgements in
response to ack-eliciting packets. This determination involves a response to ack-eliciting packets. This determination involves a
tradeoff. trade-off.
Endpoints rely on timely acknowledgment to detect loss; see Section 6 Endpoints rely on timely acknowledgment to detect loss; see Section 6
of [QUIC-RECOVERY]. Window-based congestion controllers, such as the of [QUIC-RECOVERY]. Window-based congestion controllers, such as the
one in Section 7 of [QUIC-RECOVERY], rely on acknowledgments to one in Section 7 of [QUIC-RECOVERY], rely on acknowledgments to
manage their congestion window. In both cases, delaying manage their congestion window. In both cases, delaying
acknowledgments can adversely affect performance. acknowledgments can adversely affect performance.
On the other hand, reducing the frequency of packets that carry only On the other hand, reducing the frequency of packets that carry only
acknowledgements reduces packet transmission and processing cost at acknowledgements reduces packet transmission and processing cost at
both endpoints. It can also improve connection throughput on both endpoints. It can also improve connection throughput on
skipping to change at page 84, line 43 skipping to change at page 85, line 17
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
retransmissions from the sender. This is necessary if an ACK frame retransmissions from the sender. This is necessary if an ACK frame
would be too large to fit in a packet, however receivers MAY also would be too large to fit in a packet. Receivers MAY also limit ACK
limit ACK frame size further to preserve space for other frames. frame size further to preserve space for other frames or to limit the
capacity that acknowledgments consume.
A receiver MUST retain an ACK Range unless it can ensure that it will A receiver MUST retain an ACK Range unless it can ensure that it will
not subsequently accept packets with numbers in that range. not subsequently accept packets with numbers in that range.
Maintaining a minimum packet number that increases as ranges are Maintaining a minimum packet number that increases as ranges are
discarded is one way to achieve this with minimal state. discarded is one way to achieve this with minimal state.
Receivers can discard all ACK Ranges, but they MUST retain the Receivers can discard all ACK Ranges, but they MUST retain the
largest packet number that has been successfully processed as that is largest packet number that has been successfully processed as that is
used to recover packet numbers from subsequent packets; see used to recover packet numbers from subsequent packets; see
Section 17.1. Section 17.1.
skipping to change at page 85, line 24 skipping to change at page 85, line 45
to be unnecessarily disabled; see Section 13.4.2. to be unnecessarily disabled; see Section 13.4.2.
A receiver that sends only non-ack-eliciting packets, such as ACK A receiver that sends only non-ack-eliciting packets, such as ACK
frames, might not receive an acknowledgement for a long period of frames, might not receive an acknowledgement for a long period of
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 packets that
that would otherwise be non-ack-eliciting, to avoid an infinite would otherwise be non-ack-eliciting, to avoid an infinite feedback
feedback loop of acknowledgements. loop of acknowledgements.
13.2.6. 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
skipping to change at page 90, line 40 skipping to change at page 91, line 17
codepoint for only the first ten outgoing packets on a path, or for a codepoint for only the first ten outgoing packets on a path, or for a
period of three RTTs, whichever occurs first. period of three RTTs, whichever occurs first.
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 ECT(1) counts. codepoint need to perform ECN validation using ECT(1) counts.
13.4.2.2. Receiving ACK Frames 13.4.2.2. Receiving ACK Frames
An endpoint that sets ECT(0) or ECT(1) codepoints on packets it Erroneous application of ECN marks in the network can result in
transmits MUST use the following steps on receiving an ACK frame to degraded connection performance. An endpoint that receives an ACK
validate ECN. frame with ECN counts therefore validates the counts before using
them. It performs this validation by comparing newly received counts
o If this ACK frame newly acknowledges a packet that the endpoint against those from the last successfully processed ACK frame. Any
sent with either ECT(0) or ECT(1) codepoints set, and if no ECN increase in ECN counts is validated based on the markings that were
feedback is present in the ACK frame, validation fails. This step applied to packets that are newly acknowledged in the ACK frame.
protects against both a network element that zeroes out ECN bits
and a peer that is unable to access ECN markings, since the peer
could respond without ECN feedback in these cases.
o For validation to succeed, the total increase in ECT(0), ECT(1),
and CE counts MUST be no smaller than the total number of QUIC
packets sent with an ECT codepoint that are newly acknowledged in
this ACK frame. This step detects any network remarking from
ECT(0), ECT(1), or CE codepoints to Not-ECT.
o Any increase in either ECT(0) or ECT(1) counts, plus any increase If an ACK frame newly acknowledges a packet that the endpoint sent
in the CE count, MUST be no smaller than the number of packets with either ECT(0) or ECT(1) codepoints set, ECN validation fails if
sent with the corresponding ECT codepoint that are newly ECN counts are not present in the ACK frame. This check detects a
acknowledged in this ACK frame. This step detects any erroneous network element that zeroes out ECN bits or a peer that is unable to
network remarking from ECT(0) to ECT(1) (or vice versa). access ECN markings.
Processing ECN counts out of order can result in validation failure. ECN validation fails if the sum of the increase in ECT(0) and ECN-CE
An endpoint SHOULD NOT perform this validation if this ACK frame does counts is less than the number of newly acknowledged packets that
not advance the largest packet number acknowledged in this were originally sent with an ECT(0) marking. Similarly, ECN
connection. validation fails if the sum of the increases to ECT(1) and ECN-CE
counts is less than the number of newly acknowledged packets sent
with an ECT(1) marking. These checks can detect removal of ECN
markings in the network.
An endpoint could miss acknowledgements for a packet when ACK frames An endpoint could miss acknowledgements for a packet when ACK frames
are lost. It is therefore possible for the total increase in ECT(0), are lost. It is therefore possible for the total increase in ECT(0),
ECT(1), and CE counts to be greater than the number of packets ECT(1), and ECN-CE counts to be greater than the number of packets
acknowledged in an ACK frame. When this happens, and if validation acknowledged in an ACK frame. This is why counts are permitted to be
succeeds, the local reference counts MUST be increased to match the larger than might be accounted for by newly acknowledged packets.
counts in the ACK frame.
ECN validation MAY fail if the total count for an ECT(0) or ECT(1)
marking exceeds the total number of packets sent with the
corresponding marking. In particular, an endpoint that never applies
a particular marking can fail validation when a non-zero count for
the corresponding marking is received. This check can detect when
packets are marked ECT(0) or ECT(1) in the network.
Processing ECN counts out of order can result in validation failure.
An endpoint SHOULD skip ECN validation on an ACK frame that does not
increase the largest acknowledged packet number.
13.4.2.3. Validation Outcomes 13.4.2.3. Validation Outcomes
If validation fails, then the endpoint stops sending ECN markings in If validation fails, then the endpoint stops sending ECN markings in
subsequent IP packets with the expectation that either the network subsequent IP packets with the expectation that either the network
path or the peer does not support ECN. path or the peer does not support ECN.
Upon successful validation, an endpoint can continue to set ECT Upon successful validation, an endpoint can continue to set ECT
codepoints in subsequent packets with the expectation that the path codepoints in subsequent packets with the expectation that the path
is ECN-capable. Network routing and path elements can change mid- is ECN-capable. Network routing and path elements can change mid-
skipping to change at page 102, line 28 skipping to change at page 103, line 4
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 As future versions of QUIC may support Connection IDs larger than the
version 1 limit, Version Negotiation packets could carry Connection version 1 limit, Version Negotiation packets could carry Connection
IDs that are longer than 20 bytes. IDs that are longer than 20 bytes.
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 which the server supports. versions which the server supports.
A Version Negotiation packet cannot be explicitly acknowledged in an A Version Negotiation packet is not acknowledged. It is only sent in
ACK frame by a client. Receiving another Initial packet implicitly response to a packet that indicates an unsupported version; see
acknowledges a Version Negotiation packet. 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.
Consequently, a Version Negotiation packet consumes an entire UDP Consequently, a Version Negotiation packet consumes an entire UDP
datagram. datagram.
A server MUST NOT send more than one Version Negotiation packet in A server MUST NOT send more than one Version Negotiation packet in
response to a single UDP datagram. response to a single UDP datagram.
See Section 6 for a description of the version negotiation process. See Section 6 for a description of the version negotiation process.
skipping to change at page 116, line 31 skipping to change at page 117, line 19
preferred address. Similarly, a server MUST NOT include a zero- preferred address. Similarly, a server MUST NOT include a zero-
length connection ID in this transport parameter. A client MUST length connection ID in this transport parameter. A client MUST
treat violation of these requirements as a connection error of treat violation of these requirements as a connection error of
type TRANSPORT_PARAMETER_ERROR. type TRANSPORT_PARAMETER_ERROR.
Preferred Address { Preferred Address {
IPv4 Address (32), IPv4 Address (32),
IPv4 Port (16), IPv4 Port (16),
IPv6 Address (128), IPv6 Address (128),
IPv6 Port (16), IPv6 Port (16),
CID Length (8), Connection ID Length (8),
Connection ID (..), Connection ID (..),
Stateless Reset Token (128), Stateless Reset Token (128),
} }
Figure 20: Preferred Address format Figure 20: Preferred Address format
active_connection_id_limit (0x0e): The active connection ID limit is active_connection_id_limit (0x0e): The active connection ID limit is
an integer value specifying the maximum number of connection IDs an integer value specifying the maximum number of connection IDs
from the peer that an endpoint is willing to store. This value from the peer that an endpoint is willing to store. This value
includes the connection ID received during the handshake, that includes the connection ID received during the handshake, that
skipping to change at page 118, line 37 skipping to change at page 119, line 22
packets they have received and processed. The ACK frame contains one packets they have received and processed. The ACK frame contains one
or more ACK Ranges. ACK Ranges identify acknowledged packets. If or more ACK Ranges. ACK Ranges identify acknowledged packets. If
the frame type is 0x03, ACK frames also contain the sum of QUIC the frame type is 0x03, ACK frames also contain the sum of QUIC
packets with associated ECN marks received on the connection up until packets with associated ECN marks received on the connection up until
this point. QUIC implementations MUST properly handle both types this point. QUIC implementations MUST properly handle both types
and, if they have enabled ECN for packets they send, they SHOULD use and, if they have enabled ECN for packets they send, they SHOULD use
the information in the ECN section to manage their congestion state. the information in the ECN section to manage their congestion state.
QUIC acknowledgements are irrevocable. Once acknowledged, a packet QUIC acknowledgements are irrevocable. Once acknowledged, a packet
remains acknowledged, even if it does not appear in a future ACK remains acknowledged, even if it does not appear in a future ACK
frame. This is unlike TCP SACKs ([RFC2018]). frame. This is unlike reneging for TCP SACKs ([RFC2018]).
Packets from different packet number spaces can be identified using Packets from different packet number spaces can be identified using
the same numeric value. An acknowledgment for a packet needs to the same numeric value. An acknowledgment for a packet needs to
indicate both a packet number and a packet number space. This is indicate both a packet number and a packet number space. This is
accomplished by having each ACK frame only acknowledge packet numbers accomplished by having each ACK frame only acknowledge packet numbers
in the same space as the packet in which the ACK frame is contained. in the same space as the packet in which the ACK frame is contained.
Version Negotiation and Retry packets cannot be acknowledged because Version Negotiation and Retry packets cannot be acknowledged because
they do not contain a packet number. Rather than relying on ACK they do not contain a packet number. Rather than relying on ACK
frames, these packets are implicitly acknowledged by the next Initial frames, these packets are implicitly acknowledged by the next Initial
skipping to change at page 133, line 38 skipping to change at page 134, line 38
Type (i) = 0x1a, Type (i) = 0x1a,
Data (64), Data (64),
} }
Figure 39: PATH_CHALLENGE Frame Format Figure 39: PATH_CHALLENGE Frame Format
PATH_CHALLENGE frames contain the following fields: PATH_CHALLENGE frames contain the following fields:
Data: This 8-byte field contains arbitrary data. Data: This 8-byte field contains arbitrary data.
A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that
sufficient to ensure that it is easier to receive the packet than it it is easier to receive the packet than it is to guess the value
is to guess the value correctly. correctly.
The recipient of this frame MUST generate a PATH_RESPONSE frame The recipient of this frame MUST generate a PATH_RESPONSE frame
(Section 19.18) containing the same Data. (Section 19.18) containing the same Data.
19.18. PATH_RESPONSE Frame 19.18. PATH_RESPONSE Frame
The PATH_RESPONSE frame (type=0x1b) is sent in response to a The PATH_RESPONSE frame (type=0x1b) is sent in response to a
PATH_CHALLENGE frame. Its format, shown in Figure 40 is identical to PATH_CHALLENGE frame. Its format, shown in Figure 40 is identical to
the PATH_CHALLENGE frame (Section 19.17). the PATH_CHALLENGE frame (Section 19.17).
skipping to change at page 136, line 7 skipping to change at page 137, line 7
that is unknown to its peer. that is unknown to its peer.
An extension to QUIC that wishes to use a new type of frame MUST An extension to QUIC that wishes to use a new type of frame MUST
first ensure that a peer is able to understand the frame. An first ensure that a peer is able to understand the frame. An
endpoint can use a transport parameter to signal its willingness to endpoint can use a transport parameter to signal its willingness to
receive one or more extension frame types with the one transport receive one or more extension frame types with the one transport
parameter. parameter.
Extensions that modify or replace core protocol functionality Extensions that modify or replace core protocol functionality
(including frame types) will be difficult to combine with other (including frame types) will be difficult to combine with other
extensions which modify or replace the same functionality unless the extensions that modify or replace the same functionality unless the
behavior of the combination is explicitly defined. Such extensions behavior of the combination is explicitly defined. Such extensions
SHOULD define their interaction with previously-defined extensions SHOULD define their interaction with previously-defined extensions
modifying the same protocol components. modifying the same protocol components.
Extension frames MUST be congestion controlled and MUST cause an ACK Extension frames MUST be congestion controlled and MUST cause an ACK
frame to be sent. The exception is extension frames that replace or frame to be sent. The exception is extension frames that replace or
supplement the ACK frame. Extension frames are not included in flow supplement the ACK frame. Extension frames are not included in flow
control unless specified in the extension. control unless specified in the extension.
An IANA registry is used to manage the assignment of frame types; see An IANA registry is used to manage the assignment of frame types; see
skipping to change at page 137, line 25 skipping to change at page 138, line 25
forbidden, or is otherwise in error. forbidden, or is otherwise in error.
CONNECTION_ID_LIMIT_ERROR (0x9): The number of connection IDs CONNECTION_ID_LIMIT_ERROR (0x9): The number of connection IDs
provided by the peer exceeds the advertised provided by the peer exceeds the advertised
active_connection_id_limit. active_connection_id_limit.
PROTOCOL_VIOLATION (0xA): An endpoint detected an error with PROTOCOL_VIOLATION (0xA): An endpoint detected an error with
protocol compliance that was not covered by more specific error protocol compliance that was not covered by more specific error
codes. codes.
INVALID_TOKEN (0xB): A server received a Retry Token in a client INVALID_TOKEN (0xB): A server received a client Initial that
Initial that is invalid. contained an invalid Token field.
APPLICATION_ERROR (0xC): The application or application protocol APPLICATION_ERROR (0xC): The application or application protocol
caused the connection to be closed. caused the connection to be closed.
CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in
CRYPTO frames than it can buffer. CRYPTO frames than it can buffer.
CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range
of 256 values is reserved for carrying error codes specific to the of 256 values is reserved for carrying error codes specific to the
cryptographic handshake that is used. Codes for errors occurring cryptographic handshake that is used. Codes for errors occurring
skipping to change at page 155, line 31 skipping to change at page 156, line 31
Frame Name: A short mnemonic for the frame type. Frame Name: A short mnemonic for the frame type.
In addition to the advice in Section 22.1, specifications for new In addition to the advice in Section 22.1, specifications for new
permanent registrations SHOULD describe the means by which an permanent registrations SHOULD describe the means by which an
endpoint might determine that it can send the identified type of endpoint might determine that it can send the identified type of
frame. An accompanying transport parameter registration is expected frame. An accompanying transport parameter registration is expected
for most registrations; see Section 22.2. Specifications for for most registrations; see Section 22.2. Specifications for
permanent registrations also needs to describe the format and permanent registrations also needs to describe the format and
assigned semantics of any fields in the frame. assigned semantics of any fields in the frame.
The initial contents of this registry are tabulated in Table 3. The initial contents of this registry are tabulated in Table 3. Note
that the registry does not include the "Pkts" and "Spec" columns from
Table 3.
22.4. QUIC Transport Error Codes Registry 22.4. QUIC Transport Error Codes Registry
IANA [SHALL add/has added] a registry for "QUIC Transport Error IANA [SHALL add/has added] a registry for "QUIC Transport Error
Codes" under a "QUIC" heading. Codes" under a "QUIC" heading.
The "QUIC Transport Error Codes" registry governs a 62-bit space. The "QUIC Transport Error Codes" registry governs a 62-bit space.
This space is split into three spaces that are governed by different This space is split into three spaces that are governed by different
policies. Permanent registrations in this registry are assigned policies. Permanent registrations in this registry are assigned
using the Specification Required policy [RFC8126], except for values using the Specification Required policy [RFC8126], except for values
skipping to change at page 156, line 16 skipping to change at page 157, line 19
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 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 | CONNECTION_REFUSED_ERROR | Server refuses | Section 20 | | 0x2 | CONNECTION_REFUSED | Server refuses | Section 20 |
| | | a connection | | | | | 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 | |
skipping to change at page 157, line 18 skipping to change at page 158, line 21
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
23. References 23. References
23.1. Normative References 23.1. Normative References
[DPLPMTUD] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-21 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-22
(work in progress), May 2020. (work in progress), June 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-29 (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-29 (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 159, line 9 skipping to change at page 160, line 15
23.2. Informative References 23.2. Informative References
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[EARLY-DESIGN] [EARLY-DESIGN]
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[GATEWAY] Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
Sarolahti, P., and M. Kojo, "An experimental study of home
gateway characteristics", Proceedings of the 10th annual
conference on Internet measurement - IMC '10,
DOI 10.1145/1879141.1879174, 2010.
[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-09 (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-07
(work in progress), January 2020. (work in progress), July 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>.
 End of changes. 72 change blocks. 
288 lines changed or deleted 329 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/