draft-ietf-quic-transport-27.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: August 24, 2020 Mozilla Expires: October 3, 2020 Mozilla
February 21, 2020 April 1, 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-27 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 August 24, 2020. This Internet-Draft will expire on October 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 26 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 26
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 27 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 27
5.2. Matching Packets to Connections . . . . . . . . . . . . . 28 5.2. Matching Packets to Connections . . . . . . . . . . . . . 28
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 29 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 29
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 29 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 29
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 30 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 30
5.4. Required Operations on Connections . . . . . . . . . . . 31 5.4. Required Operations on Connections . . . . . . . . . . . 31
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 32 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 32
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 32 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 32
6.2. Handling Version Negotiation Packets . . . . . . . . . . 32 6.2. Handling Version Negotiation Packets . . . . . . . . . . 33
6.2.1. Version Negotiation Between Draft Versions . . . . . 33 6.2.1. Version Negotiation Between Draft Versions . . . . . 33
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 33 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 33
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 34 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 34
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 35 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 35
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 36 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 36
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 37 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 37
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 38 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 38
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 39 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 39
7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 40 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 40
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 40 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 40
8.1. Address Validation During Connection Establishment . . . 40 8.1. Address Validation During Connection Establishment . . . 41
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 41 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 42
8.1.2. Address Validation using Retry Packets . . . . . . . 42 8.1.2. Address Validation using Retry Packets . . . . . . . 42
8.1.3. Address Validation for Future Connections . . . . . . 43 8.1.3. Address Validation for Future Connections . . . . . . 43
8.1.4. Address Validation Token Integrity . . . . . . . . . 45 8.1.4. Address Validation Token Integrity . . . . . . . . . 45
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 46 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 46
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 46 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 47
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 47 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 47
8.5. Successful Path Validation . . . . . . . . . . . . . . . 47 8.5. Successful Path Validation . . . . . . . . . . . . . . . 47
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 47 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 48
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 48 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 48
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 49 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 49
9.2. Initiating Connection Migration . . . . . . . . . . . . . 49 9.2. Initiating Connection Migration . . . . . . . . . . . . . 50
9.3. Responding to Connection Migration . . . . . . . . . . . 50 9.3. Responding to Connection Migration . . . . . . . . . . . 50
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 50 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 51
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 51 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 51
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 51 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 52
9.4. Loss Detection and Congestion Control . . . . . . . . . . 53 9.4. Loss Detection and Congestion Control . . . . . . . . . . 53
9.5. Privacy Implications of Connection Migration . . . . . . 53 9.5. Privacy Implications of Connection Migration . . . . . . 54
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 55 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 55
9.6.1. Communicating a Preferred Address . . . . . . . . . . 55 9.6.1. Communicating a Preferred Address . . . . . . . . . . 55
9.6.2. Responding to Connection Migration . . . . . . . . . 55 9.6.2. Responding to Connection Migration . . . . . . . . . 56
9.6.3. Interaction of Client Migration and Preferred Address 56 9.6.3. Interaction of Client Migration and Preferred Address 56
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 56 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 57
10. Connection Termination . . . . . . . . . . . . . . . . . . . 57 10. Connection Termination . . . . . . . . . . . . . . . . . . . 57
10.1. Closing and Draining Connection States . . . . . . . . . 57 10.1. Closing and Draining Connection States . . . . . . . . . 57
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 58 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 59
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 59 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 59
10.3.1. Immediate Close During the Handshake . . . . . . . . 60 10.3.1. Immediate Close During the Handshake . . . . . . . . 61
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 61 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 62
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 64 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 65
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 65 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 66
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 66 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 67
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 66 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 67
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 67 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 68
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 67 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 68
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 68 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 69
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 68 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 69
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 69 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 70
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 70 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 71
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 71 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 72
13. Packetization and Reliability . . . . . . . . . . . . . . . . 74 13. Packetization and Reliability . . . . . . . . . . . . . . . . 75
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 75 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 76
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 75 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 76
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 76 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 77
13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 77 13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 78
13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 78 13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 79
13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 78 13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 79
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 78 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 80
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 79 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 80
13.3. Retransmission of Information . . . . . . . . . . . . . 79 13.3. Retransmission of Information . . . . . . . . . . . . . 80
13.4. Explicit Congestion Notification . . . . . . . . . . . . 82 13.4. Explicit Congestion Notification . . . . . . . . . . . . 83
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 82 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 83
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 83 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 84
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 85 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 86
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 85 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 86
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 86 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 87
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 87 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 88
14.3.1. PMTU Probes Containing Source Connection ID . . . . 87 14.3.1. PMTU Probes Containing Source Connection ID . . . . 89
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 88 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 89
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 89 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 90
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 89 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 91
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 90 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 91
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 91 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 92
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 93 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 95
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 95 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 96
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 97 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 98
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 99 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 100
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 100 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 101
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 102 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 104
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 104 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 106
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 105 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 107
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 106 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 108
18.2. Transport Parameter Definitions . . . . . . . . . . . . 106 18.2. Transport Parameter Definitions . . . . . . . . . . . . 108
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 111 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 112
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 111 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 112
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 111 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 112
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 112 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 113
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 114 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 115
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 115 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 116
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 116 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 117
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 117 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 118
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 118 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 119
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 119 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 120
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 120 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 121
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 121 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 122
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 122 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 123
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 123 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 124
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 124 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 125
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 124 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 125
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 125 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 126
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 125 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 126
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 127 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 128
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 128 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 129
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 129 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 130
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 129 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 130
19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 130 19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 131
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 130 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 131
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 131 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 132
20.1. Application Protocol Error Codes . . . . . . . . . . . . 133 20.1. Application Protocol Error Codes . . . . . . . . . . . . 134
21. Security Considerations . . . . . . . . . . . . . . . . . . . 133 21. Security Considerations . . . . . . . . . . . . . . . . . . . 134
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 133 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 134
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 134 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 135
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 134 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 135
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 134 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 135
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 135 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 136
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 135 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 136
21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 136 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 137
21.8. Explicit Congestion Notification Attacks . . . . . . . . 136 21.8. Explicit Congestion Notification Attacks . . . . . . . . 137
21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 136 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 138
21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 137 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 138
21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 137 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 138
21.12. Overview of Security Properties . . . . . . . . . . . . 137 21.12. Overview of Security Properties . . . . . . . . . . . . 139
21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 138 21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 139
21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 139 21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 141
21.12.3. Connection Migration . . . . . . . . . . . . . . . 140 21.12.3. Connection Migration . . . . . . . . . . . . . . . 141
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145
22.1. Registration Policies for QUIC Registries . . . . . . . 144 22.1. Registration Policies for QUIC Registries . . . . . . . 146
22.1.1. Provisional Registrations . . . . . . . . . . . . . 144 22.1.1. Provisional Registrations . . . . . . . . . . . . . 146
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 145 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 147
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 146 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 147
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 146 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 148
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 147 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 148
22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 148 22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 149
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 149 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 150
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 151 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 152
23.1. Normative References . . . . . . . . . . . . . . . . . . 151 23.1. Normative References . . . . . . . . . . . . . . . . . . 152
23.2. Informative References . . . . . . . . . . . . . . . . . 152 23.2. Informative References . . . . . . . . . . . . . . . . . 153
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 154 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 155
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 155 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 156
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 156 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 157
C.1. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 156 C.1. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 157
C.2. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 156 C.2. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 157
C.3. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 156 C.3. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 158
C.4. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 158 C.4. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 159
C.5. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 158 C.5. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 159
C.6. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 159 C.6. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 161
C.7. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 160 C.7. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 161
C.8. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 161 C.8. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 162
C.9. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 161 C.9. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 162
C.10. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 162 C.10. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 163
C.11. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 162 C.11. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 163
C.12. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 164 C.12. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 165
C.13. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 164 C.13. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 165
C.14. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 164 C.14. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 165
C.15. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 165 C.15. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 166
C.16. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 166 C.16. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 167
C.17. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 166 C.17. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 167
C.18. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 167 C.18. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 168
C.19. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 167 C.19. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 168
C.20. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 168 C.20. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 169
C.21. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 169 C.21. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 170
C.22. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 169 C.22. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 170
C.23. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 169 C.23. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 170
C.24. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 170 C.24. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 171
C.25. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 170 C.25. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 171
C.26. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 171 C.26. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 172
C.27. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 173 C.27. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 174
C.28. Since draft-hamilton-quic-transport-protocol-01 . . . . . 173 C.28. Since draft-hamilton-quic-transport-protocol-01 . . . . . 174
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 175
1. Introduction 1. Introduction
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
o Stream multiplexing o Stream multiplexing
o Stream and connection-level flow control o Stream and connection-level flow control
skipping to change at page 8, line 42 skipping to change at page 8, line 42
QUIC packet: A complete processable unit of QUIC that can be QUIC packet: A complete processable unit of QUIC that can be
encapsulated in a UDP datagram. Multiple QUIC packets can be encapsulated in a UDP datagram. Multiple QUIC packets can be
encapsulated in a single UDP datagram. encapsulated in a single UDP datagram.
Ack-eliciting Packet: A QUIC packet that contains frames other than Ack-eliciting Packet: A QUIC packet that contains frames other than
ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to
send an acknowledgment (see Section 13.2.1). send an acknowledgment (see Section 13.2.1).
Out-of-order packet: A packet that does not increase the largest Out-of-order packet: A packet that does not increase the largest
received packet number for its packet number space (Section 12.3) received packet number for its packet number space (Section 12.3)
by exactly one. A packet can arrive out of order if it is delayed by exactly one. A packet can arrive out of order if it is
or if earlier packets are lost or delayed. delayed, if earlier packets are lost or delayed, or if the sender
intentionally skips a packet number.
Endpoint: An entity that can participate in a QUIC connection by Endpoint: An entity that can participate in a QUIC connection by
generating, receiving, and processing QUIC packets. There are generating, receiving, and processing QUIC packets. There are
only two types of endpoint in QUIC: client and server. only two types of endpoint in QUIC: client and server.
Client: The endpoint initiating a QUIC connection. Client: The endpoint initiating a QUIC connection.
Server: The endpoint accepting incoming QUIC connections. Server: The endpoint accepting incoming QUIC connections.
Address: When used without qualification, the tuple of IP version, Address: When used without qualification, the tuple of IP version,
skipping to change at page 27, line 12 skipping to change at page 27, line 12
ID randomly selected by the client in the Initial packet and any ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection numbers unless a server opts to retain them as its initial connection
ID. ID.
When an endpoint issues a connection ID, it MUST accept packets that When an endpoint issues a connection ID, it MUST accept packets that
carry this connection ID for the duration of the connection or until carry this connection ID for the duration of the connection or until
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
frame (Section 19.16). Connection IDs that are issued and not frame (Section 19.16). Connection IDs that are issued and not
retired are considered active; any active connection ID is valid for retired are considered active; any active connection ID is valid for
use at any time, in any packet type. This includes the connection ID use with the current connection at any time, in any packet type.
issued by the server via the preferred_address transport parameter. This includes the connection ID issued by the server via the
preferred_address transport parameter.
An endpoint SHOULD ensure that its peer has a sufficient number of An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. Endpoints store received available and unused connection IDs. Endpoints store received
connection IDs for future use and advertise the number of connection connection IDs for future use and advertise the number of connection
IDs they are willing to store with the active_connection_id_limit IDs they are willing to store with the active_connection_id_limit
transport parameter. An endpoint MUST NOT provide more connection transport parameter. An endpoint MUST NOT provide more connection
IDs than the peer's limit. An endpoint that receives more connection IDs than the peer's limit. An endpoint that receives more connection
IDs than its advertised active_connection_id_limit MUST close the IDs than its advertised active_connection_id_limit MUST close the
connection with an error of type CONNECTION_ID_LIMIT_ERROR. connection with an error of type CONNECTION_ID_LIMIT_ERROR.
skipping to change at page 28, line 5 skipping to change at page 28, line 7
Section 9.5 for more. Section 9.5 for more.
An endpoint maintains a set of connection IDs received from its peer, An endpoint maintains a set of connection IDs received from its peer,
any of which it can use when sending packets. When the endpoint any of which it can use when sending packets. When the endpoint
wishes to remove a connection ID from use, it sends a wishes to remove a connection ID from use, it sends a
RETIRE_CONNECTION_ID frame to its peer. Sending a RETIRE_CONNECTION_ID frame to its peer. Sending a
RETIRE_CONNECTION_ID frame indicates that the connection ID will not RETIRE_CONNECTION_ID frame indicates that the connection ID will not
be used again and requests that the peer replace it with a new be used again and requests that the peer replace it with a new
connection ID using a NEW_CONNECTION_ID frame. connection ID using a NEW_CONNECTION_ID frame.
As discussed in Section 9.5, each connection ID MUST be used on As discussed in Section 9.5, endpoints limit the use of a connection
packets sent from only one local address. An endpoint that migrates ID to a single network path where possible. Endpoints SHOULD retire
away from a local address SHOULD retire all connection IDs used on connection IDs when no longer actively using the network path on
that address once it no longer plans to use that address. which the connection ID was used.
An endpoint can cause its peer to retire connection IDs by sending a An endpoint might need to stop accepting previously issued connection
NEW_CONNECTION_ID frame with an increased Retire Prior To field. IDs in certain circumstances. Such an endpoint can cause its peer to
Upon receipt, the peer MUST first retire the corresponding connection retire connection IDs by sending a NEW_CONNECTION_ID frame with an
IDs using RETIRE_CONNECTION_ID frames and then add the newly provided increased Retire Prior To field. The endpoint SHOULD continue to
connection ID to the set of active connection IDs. Failure to retire accept the previously issued connection IDs until they are retired by
the connection IDs within approximately one PTO can cause packets to the peer. If the endpoint can no longer process the indicated
be delayed, lost, or cause the original endpoint to send a stateless connection IDs, it MAY close the connection.
reset in response to a connection ID it can no longer route
correctly.
An endpoint MAY discard a connection ID for which retirement has been Upon receipt of an increased Retire Prior To field, the peer MUST
requested once an interval of no less than 3 PTO has elapsed since an stop using the corresponding connection IDs and retire them with
acknowledgement is received for the NEW_CONNECTION_ID frame RETIRE_CONNECTION_ID frames before adding the newly provided
requesting that retirement. Until then, the endpoint SHOULD be connection ID to the set of active connection IDs. This ordering
prepared to receive packets that contain the connection ID that it allows an endpoint that has already supplied its peer with as many
has requested be retired. Subsequent incoming packets using that connection IDs as allowed by the active_connection_id_limit transport
connection ID could elicit a response with the corresponding parameter to replace those connection IDs with new ones as necessary.
stateless reset token. Failure to cease using the connection IDs when requested can result
in connection failures, as the issuing endpoint might be unable to
continue using the connection IDs with the active connection.
5.2. Matching Packets to Connections 5.2. Matching Packets to Connections
Incoming packets are classified on receipt. Packets can either be Incoming packets are classified on receipt. Packets can either be
associated with an existing connection, or - for servers - associated with an existing connection, or - for servers -
potentially create a new connection. potentially create a new connection.
Endpoints try to associate a packet with an existing connection. If Endpoints try to associate a packet with an existing connection. If
the packet has a non-zero-length Destination Connection ID the packet has a non-zero-length Destination Connection ID
corresponding to an existing connection, QUIC processes that packet corresponding to an existing connection, QUIC processes that packet
skipping to change at page 31, line 50 skipping to change at page 32, line 6
In either role, applications need to be able to: In either role, applications need to be able to:
o configure minimum values for the initial number of permitted o configure minimum values for the initial number of permitted
streams of each type, as communicated in the transport parameters streams of each type, as communicated in the transport parameters
(Section 7.3); (Section 7.3);
o control resource allocation of various types, including flow o control resource allocation of various types, including flow
control and the number of permitted streams of each type; control and the number of permitted streams of each type;
o identify whether the handshake has completed successfully or is o identify whether the handshake has completed successfully or is
still ongoing still ongoing;
o keep a connection from silently closing, either by generating PING o keep a connection from silently closing, either by generating PING
frames (Section 19.2) or by requesting that the transport send frames (Section 19.2) or by requesting that the transport send
additional frames before the idle timeout expires (Section 10.2); additional frames before the idle timeout expires (Section 10.2);
and and
o immediately close (Section 10.3) the connection. o immediately close (Section 10.3) the connection.
6. Version Negotiation 6. Version Negotiation
skipping to change at page 35, line 24 skipping to change at page 35, line 28
handshake is carried in Initial (Section 17.2.2) and Handshake handshake is carried in Initial (Section 17.2.2) and Handshake
(Section 17.2.4) packets. (Section 17.2.4) packets.
Figure 3 provides an overview of the 1-RTT handshake. Each line Figure 3 provides an overview of the 1-RTT handshake. Each line
shows a QUIC packet with the packet type and packet number shown shows a QUIC packet with the packet type and packet number shown
first, followed by the frames that are typically contained in those first, followed by the frames that are typically contained in those
packets. So, for instance the first packet is of type Initial, with packets. So, for instance the first packet is of type Initial, with
packet number 0, and contains a CRYPTO frame carrying the packet number 0, and contains a CRYPTO frame carrying the
ClientHello. ClientHello.
Note that multiple QUIC packets - even of different encryption levels Note that multiple QUIC packets - even of different packet types -
- may be coalesced into a single UDP datagram (see Section 12.2), and can be coalesced into a single UDP datagram (see Section 12.2), and
so this handshake may consist of as few as 4 UDP datagrams, or any so this handshake may consist of as few as 4 UDP datagrams, or any
number more. For instance, the server's first flight contains number more. For instance, the server's first flight contains
packets from the Initial encryption level (obfuscation), the Initial packets, Handshake packets, and "0.5-RTT data" in 1-RTT
Handshake level, and "0.5-RTT data" from the server at the 1-RTT packets with a short header.
encryption level.
Client Server Client Server
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
Initial[0]: CRYPTO[SH] ACK[0] Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0]: CRYPTO[EE, CERT, CV, FIN] Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."] <- 1-RTT[0]: STREAM[1, "..."]
Initial[1]: ACK[0] Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0] Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1-RTT[0]: STREAM[0, "..."], ACK[0] ->
1-RTT[1]: STREAM[3, "..."], ACK[0] 1-RTT[1]: STREAM[3, "..."], ACK[0]
<- Handshake[1]: ACK[0] <- Handshake[1]: ACK[0]
Figure 3: Example 1-RTT Handshake Figure 3: Example 1-RTT Handshake
Figure 4 shows an example of a connection with a 0-RTT handshake and Figure 4 shows an example of a connection with a 0-RTT handshake and
a single packet of 0-RTT data. Note that as described in a single packet of 0-RTT data. Note that as described in
Section 12.3, the server acknowledges 0-RTT data at the 1-RTT Section 12.3, the server acknowledges 0-RTT data in 1-RTT packets,
encryption level, and the client sends 1-RTT packets in the same and the client sends 1-RTT packets in the same packet number space.
packet number space.
Client Server Client Server
Initial[0]: CRYPTO[CH] Initial[0]: CRYPTO[CH]
0-RTT[0]: STREAM[0, "..."] -> 0-RTT[0]: STREAM[0, "..."] ->
Initial[0]: CRYPTO[SH] ACK[0] Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0] CRYPTO[EE, FIN] Handshake[0] CRYPTO[EE, FIN]
<- 1-RTT[0]: STREAM[1, "..."] ACK[0] <- 1-RTT[0]: STREAM[1, "..."] ACK[0]
skipping to change at page 36, line 35 skipping to change at page 36, line 38
7.2. Negotiating Connection IDs 7.2. Negotiating Connection IDs
A connection ID is used to ensure consistent routing of packets, as A connection ID is used to ensure consistent routing of packets, as
described in Section 5.1. The long header contains two connection described in Section 5.1. The long header contains two connection
IDs: the Destination Connection ID is chosen by the recipient of the IDs: the Destination Connection ID is chosen by the recipient of the
packet and is used to provide consistent routing; the Source packet and is used to provide consistent routing; the Source
Connection ID is used to set the Destination Connection ID used by Connection ID is used to set the Destination Connection ID used by
the peer. the peer.
During the handshake, packets with the long header (Section 17.2) are During the handshake, packets with the long header (Section 17.2) are
used to establish the connection ID that each endpoint uses. Each used to establish the connection IDs in each direction. Each
endpoint uses the Source Connection ID field to specify the endpoint uses the Source Connection ID field to specify the
connection ID that is used in the Destination Connection ID field of connection ID that is used in the Destination Connection ID field of
packets being sent to them. Upon receiving a packet, each endpoint packets being sent to them. Upon receiving a packet, each endpoint
sets the Destination Connection ID it sends to match the value of the sets the Destination Connection ID it sends to match the value of the
Source Connection ID that they receive. Source Connection ID that it receives.
When an Initial packet is sent by a client that has not previously When an Initial packet is sent by a client that has not previously
received an Initial or Retry packet from the server, it populates the received an Initial or Retry packet from the server, the client
Destination Connection ID field with an unpredictable value. This populates the Destination Connection ID field with an unpredictable
MUST be at least 8 bytes in length. Until a packet is received from value. This Destination Connection ID MUST be at least 8 bytes in
the server, the client MUST use the same value unless it abandons the length. Until a packet is received from the server, the client MUST
connection attempt and starts a new one. The initial Destination use the same Destination Connection ID value on all packets in this
Connection ID is used to determine packet protection keys for Initial connection. This Destination Connection ID is used to determine
packets. packet protection keys for Initial packets.
The client populates the Source Connection ID field with a value of The client populates the Source Connection ID field with a value of
its choosing and sets the SCID Len field to indicate the length. its choosing and sets the SCID Len field to indicate the length.
The first flight of 0-RTT packets use the same Destination and Source The first flight of 0-RTT packets use the same Destination Connection
Connection ID values as the client's first Initial. ID and Source Connection ID values as the client's first Initial
packet.
Upon first receiving an Initial or Retry packet from the server, the Upon first receiving an Initial or Retry packet from the server, the
client uses the Source Connection ID supplied by the server as the client uses the Source Connection ID supplied by the server as the
Destination Connection ID for subsequent packets, including any Destination Connection ID for subsequent packets, including all
subsequent 0-RTT packets. That means that a client might change the subsequent 0-RTT packets. This means that a client might have to
Destination Connection ID twice during connection establishment, once change the connection ID it sets in the Destination Connection ID
in response to a Retry and once in response to the first Initial field twice during connection establishment: once in response to a
packet from the server. Once a client has received an Initial packet Retry, and once in response to an Initial packet from the server.
from the server, it MUST discard any packet it receives with a Once a client has received an Initial packet from the server, it MUST
different Source Connection ID. discard any subsequent packet it receives with a different Source
Connection ID.
A client MUST only change the value it sends in the Destination A client MUST change the Destination Connection ID it uses for
Connection ID in response to the first packet of each type it sending packets in response to only the first received Initial or
receives from the server (Retry or Initial); a server MUST set its Retry packet. A server MUST set the Destination Connection ID it
value based on the Initial packet. Any additional changes are not uses for sending packets based on the first received Initial packet.
permitted; if subsequent packets of those types include a different Any further changes to the Destination Connection ID are only
Source Connection ID, they MUST be discarded. This avoids problems permitted if the values are taken from any received NEW_CONNECTION_ID
that might arise from stateless processing of multiple Initial frames; if subsequent Initial packets include a different Source
packets producing different connection IDs. Connection ID, they MUST be discarded. This avoids unpredictable
outcomes that might otherwise result from stateless processing of
multiple Initial packets with different Source Connection IDs.
The connection ID can change over the lifetime of a connection, The Destination Connection ID that an endpoint sends can change over
especially in response to connection migration (Section 9); see the lifetime of a connection, especially in response to connection
Section 5.1.1 for details. migration (Section 9); see Section 5.1.1 for details.
7.3. Transport Parameters 7.3. Transport Parameters
During connection establishment, both endpoints make authenticated During connection establishment, both endpoints make authenticated
declarations of their transport parameters. These declarations are declarations of their transport parameters. Endpoints are required
made unilaterally by each endpoint. Endpoints are required to comply to comply with the restrictions implied by these parameters; the
with the restrictions implied by these parameters; the description of description of each parameter includes rules for its handling.
each parameter includes rules for its handling.
Transport parameters are declarations that are made unilaterally by
each endpoint. Each endpoint can choose values for transport
parameters independent of the values chosen by its peer.
The encoding of the transport parameters is detailed in Section 18. The encoding of the transport parameters is detailed in Section 18.
QUIC includes the encoded transport parameters in the cryptographic QUIC includes the encoded transport parameters in the cryptographic
handshake. Once the handshake completes, the transport parameters handshake. Once the handshake completes, the transport parameters
declared by the peer are available. Each endpoint validates the declared by the peer are available. Each endpoint validates the
value provided by its peer. value provided by its peer.
Definitions for each of the defined transport parameters are included Definitions for each of the defined transport parameters are included
in Section 18.2. in Section 18.2.
skipping to change at page 38, line 34 skipping to change at page 38, line 39
parameters apply to the new connection until the handshake completes parameters apply to the new connection until the handshake completes
and the client starts sending 1-RTT packets. Once the handshake and the client starts sending 1-RTT packets. Once the handshake
completes, the client uses the transport parameters established in completes, the client uses the transport parameters established in
the handshake. the handshake.
The definition of new transport parameters (Section 7.3.2) MUST The definition of new transport parameters (Section 7.3.2) MUST
specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A
client need not store a transport parameter it cannot process. client need not store a transport parameter it cannot process.
A client MUST NOT use remembered values for the following parameters: A client MUST NOT use remembered values for the following parameters:
original_connection_id, preferred_address, stateless_reset_token, original_connection_id, preferred_address, stateless_reset_token, and
ack_delay_exponent and active_connection_id_limit. The client MUST ack_delay_exponent. The client MUST use the server's new values in
use the server's new values in the handshake instead, and absent new the handshake instead, and absent new values from the server, the
values from the server, the default value. default value.
A client that attempts to send 0-RTT data MUST remember all other A client that attempts to send 0-RTT data MUST remember all other
transport parameters used by the server. The server can remember transport parameters used by the server. The server can remember
these transport parameters, or store an integrity-protected copy of these transport parameters, or store an integrity-protected copy of
the values in the ticket and recover the information when accepting the values in the ticket and recover the information when accepting
0-RTT data. A server uses the transport parameters in determining 0-RTT data. A server uses the transport parameters in determining
whether to accept 0-RTT data. whether to accept 0-RTT data.
If 0-RTT data is accepted by the server, the server MUST NOT reduce If 0-RTT data is accepted by the server, the server MUST NOT reduce
any limits or alter any values that might be violated by the client any limits or alter any values that might be violated by the client
skipping to change at page 39, line 4 skipping to change at page 39, line 12
0-RTT data. A server uses the transport parameters in determining 0-RTT data. A server uses the transport parameters in determining
whether to accept 0-RTT data. whether to accept 0-RTT data.
If 0-RTT data is accepted by the server, the server MUST NOT reduce If 0-RTT data is accepted by the server, the server MUST NOT reduce
any limits or alter any values that might be violated by the client any limits or alter any values that might be violated by the client
with its 0-RTT data. In particular, a server that accepts 0-RTT data with its 0-RTT data. In particular, a server that accepts 0-RTT data
MUST NOT set values for the following parameters (Section 18.2) that MUST NOT set values for the following parameters (Section 18.2) that
are smaller than the remembered value of the parameters. are smaller than the remembered value of the parameters.
o initial_max_data o initial_max_data
o initial_max_stream_data_bidi_local o initial_max_stream_data_bidi_local
o initial_max_stream_data_bidi_remote o initial_max_stream_data_bidi_remote
o initial_max_stream_data_uni o initial_max_stream_data_uni
o initial_max_streams_bidi o initial_max_streams_bidi
o initial_max_streams_uni o initial_max_streams_uni
o active_connection_id_limit
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 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.
skipping to change at page 41, line 11 skipping to change at page 41, line 17
Connection establishment implicitly provides address validation for Connection establishment implicitly provides address validation for
both endpoints. In particular, receipt of a packet protected with both endpoints. In particular, receipt of a packet protected with
Handshake keys confirms that the client received the Initial packet Handshake keys confirms that the client received the Initial packet
from the server. Once the server has successfully processed a from the server. Once the server has successfully processed a
Handshake packet from the client, it can consider the client address Handshake packet from the client, it can consider the client address
to have been validated. to have been validated.
Prior to validating the client address, servers MUST NOT send more Prior to validating the client address, servers MUST NOT send more
than three times as many bytes as the number of bytes they have than three times as many bytes as the number of bytes they have
received. This limits the magnitude of any amplification attack that received. This limits the magnitude of any amplification attack that
can be mounted using spoofed source addresses. In determining this can be mounted using spoofed source addresses. For the purposes of
limit, servers only count the size of successfully processed packets. avoiding amplification prior to address validation, servers MUST
count all of the payload bytes received in datagrams that are
uniquely attributed to a single connection. This includes datagrams
that contain packets that are successfully processed and datagrams
that contain packets that are all discarded.
Clients MUST ensure that UDP datagrams containing Initial packets Clients MUST ensure that UDP datagrams containing Initial packets
have UDP payloads of at least 1200 bytes, adding padding to packets have UDP payloads of at least 1200 bytes, adding padding to packets
in the datagram as necessary. Sending padded datagrams ensures that in the datagram as necessary. Sending padded datagrams ensures that
the server is not overly constrained by the amplification the server is not overly constrained by the amplification
restriction. restriction.
Packet loss, in particular loss of a Handshake packet from the Loss of an Initial or Handshake packet from the server can cause a
server, can cause a situation in which the server cannot send when deadlock if the client does not send additional Initial or Handshake
the client has no data to send and the anti-amplification limit is packets. A deadlock could occur when the server reaches its anti-
reached. In order to avoid this causing a handshake deadlock, amplification limit and the client has received acknowledgements for
clients MUST send a packet upon a probe timeout, as described in all the data it has sent. In this case, when the client has no
[QUIC-RECOVERY]. If the client has no data to retransmit and does reason to send additional packets, the server will be unable to send
not have Handshake keys, it MUST send an Initial packet in a UDP more data because it has not validated the client's address. To
datagram of at least 1200 bytes. If the client has Handshake keys, prevent this deadlock, clients MUST send a packet on a probe timeout
it SHOULD send a Handshake packet. (PTO, see Section 5.3 of [QUIC-RECOVERY]). Specifically, the client
MUST send an Initial packet in a UDP datagram of at least 1200 bytes
if it does not have Handshake keys, and otherwise send a Handshake
packet.
A server might wish to validate the client address before starting A server might wish to validate the client address before starting
the cryptographic handshake. QUIC uses a token in the Initial packet the cryptographic handshake. QUIC uses a token in the Initial packet
to provide address validation prior to completing the handshake. to provide address validation prior to completing the handshake.
This token is delivered to the client during connection establishment This token is delivered to the client during connection establishment
with a Retry packet (see Section 8.1.2) or in a previous connection with a Retry packet (see Section 8.1.2) or in a previous connection
using the NEW_TOKEN frame (see Section 8.1.3). using the NEW_TOKEN frame (see Section 8.1.3).
In addition to sending limits imposed prior to address validation, In addition to sending limits imposed prior to address validation,
servers are also constrained in what they can send by the limits set servers are also constrained in what they can send by the limits set
by the congestion controller. Clients are only constrained by the by the congestion controller. Clients are only constrained by the
congestion controller. congestion controller.
8.1.1. Token Construction 8.1.1. Token Construction
A token sent in a NEW_TOKEN frames or a Retry packet MUST be A token sent in a NEW_TOKEN frames or a Retry packet MUST be
constructed in a way that allows the server to identity how it was constructed in a way that allows the server to identify how it was
provided to a client. These tokens are carried in the same field, provided to a client. These tokens are carried in the same field,
but require different handling from servers. but require different handling from servers.
8.1.2. Address Validation using Retry Packets 8.1.2. Address Validation using Retry Packets
Upon receiving the client's Initial packet, the server can request Upon receiving the client's Initial packet, the server can request
address validation by sending a Retry packet (Section 17.2.5) address validation by sending a Retry packet (Section 17.2.5)
containing a token. This token MUST be repeated by the client in all containing a token. This token MUST be repeated by the client in all
Initial packets it sends for that connection after it receives the Initial packets it sends for that connection after it receives the
Retry packet. In response to processing an Initial containing a Retry packet. In response to processing an Initial containing a
skipping to change at page 42, line 34 skipping to change at page 42, line 43
forces the server to demonstrate that it, or an entity it cooperates forces the server to demonstrate that it, or an entity it cooperates
with, received the original Initial packet from the client. with, received the original Initial packet from the client.
Providing a different connection ID also grants a server some control Providing a different connection ID also grants a server some control
over how subsequent packets are routed. This can be used to direct over how subsequent packets are routed. This can be used to direct
connections to a different server instance. connections to a different server instance.
If a server receives a client Initial that can be unprotected but If a server receives a client Initial that can be unprotected but
contains an invalid Retry token, it knows the client will not accept contains an invalid Retry token, it knows the client will not accept
another Retry token. The server can discard such a packet and allow another Retry token. The server can discard such a packet and allow
the client to time out to detect handshake failure, but that could the client to time out to detect handshake failure, but that could
impose a significant latency penalty on the client. A server MAY impose a significant latency penalty on the client. Instead, the
proceed with the connection without verifying the token, though the server SHOULD immediately close (Section 10.3) the connection with an
server MUST NOT consider the client address validated. If a server INVALID_TOKEN error. Note that a server has not established any
chooses not to proceed with the handshake, it SHOULD immediately state for the connection at this point and so does not enter the
close (Section 10.3) the connection with an INVALID_TOKEN error. closing period.
Note that a server has not established any state for the connection
at this point and so does not enter the closing period.
A flow showing the use of a Retry packet is shown in Figure 5. A flow showing the use of a Retry packet is shown in Figure 5.
Client Server Client Server
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
<- Retry+Token <- Retry+Token
Initial+Token[1]: CRYPTO[CH] -> Initial+Token[1]: CRYPTO[CH] ->
skipping to change at page 43, line 45 skipping to change at page 43, line 45
Unlike the token that is created for a Retry packet, which is used Unlike the token that is created for a Retry packet, which is used
immediately, the token sent in the NEW_TOKEN frame might be used immediately, the token sent in the NEW_TOKEN frame might be used
after some period of time has passed. Thus, a token SHOULD have an after some period of time has passed. Thus, a token SHOULD have an
expiration time, which could be either an explicit expiration time or expiration time, which could be either an explicit expiration time or
an issued timestamp that can be used to dynamically calculate the an issued timestamp that can be used to dynamically calculate the
expiration time. A server can store the expiration time or include expiration time. A server can store the expiration time or include
it in an encrypted form in the token. it in an encrypted form in the token.
A token issued with NEW_TOKEN MUST NOT include information that would A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an on-path observer to the connection on allow values to be linked by an observer to the connection on which
which it was issued, unless the values are encrypted. For example, it was issued, unless the values are encrypted. For example, it
it cannot include the previous connection ID or addressing cannot include the previous connection ID or addressing information.
information. A server MUST ensure that every NEW_TOKEN frame it A server MUST ensure that every NEW_TOKEN frame it sends is unique
sends is unique across all clients, with the exception of those sent across all clients, with the exception of those sent to repair losses
to repair losses of previously sent NEW_TOKEN frames. Information of previously sent NEW_TOKEN frames. Information that allows the
that allows the server to distinguish between tokens from Retry and server to distinguish between tokens from Retry and NEW_TOKEN MAY be
NEW_TOKEN MAY be accessible to entities other than the server. accessible to entities other than the server.
It is unlikely that the client port number is the same on two It is unlikely that the client port number is the same on two
different connections; validating the port is therefore unlikely to different connections; validating the port is therefore unlikely to
be successful. be successful.
A token received in a NEW_TOKEN frame is applicable to any server A token received in a NEW_TOKEN frame is applicable to any server
that the connection is considered authoritative for (e.g., server that the connection is considered authoritative for (e.g., server
names included in the certificate). When connecting to a server for names included in the certificate). When connecting to a server for
which the client retains an applicable and unused token, it SHOULD which the client retains an applicable and unused token, it SHOULD
include that token in the Token field of its Initial packet. include that token in the Token field of its Initial packet.
skipping to change at page 45, line 49 skipping to change at page 45, line 49
A token-based scheme allows the server to offload any state A token-based scheme allows the server to offload any state
associated with validation to the client. For this design to work, associated with validation to the client. For this design to work,
the token MUST be covered by integrity protection against the token MUST be covered by integrity protection against
modification or falsification by clients. Without integrity modification or falsification by clients. Without integrity
protection, malicious clients could generate or guess values for protection, malicious clients could generate or guess values for
tokens that would be accepted by the server. Only the server tokens that would be accepted by the server. Only the server
requires access to the integrity protection key for tokens. requires access to the integrity protection key for tokens.
There is no need for a single well-defined format for the token There is no need for a single well-defined format for the token
because the server that generates the token also consumes it. A because the server that generates the token also consumes it. Tokens
token could include information about the claimed client address (IP sent in Retry packets SHOULD include information that allows the
and port), a timestamp, and any other supplementary information the server to verify that the source IP address and port in client
server will need to validate the token in the future. packets remains constant.
Tokens sent in NEW_TOKEN frames MUST include information that allows
the server to verify that the client IP address has not changed from
when the token was issued. Servers can use tokens from NEW_TOKEN in
deciding not to send a Retry packet, even if the client address has
changed. If the client IP address has changed, the server MUST
adhere to the anti-amplification limits found in Section 8.1. Note
that in the presence of NAT, this requirement might be insufficient
to protect other hosts that share the NAT from amplification attack.
Servers MUST ensure that replay of tokens is prevented or limited.
For instance, servers might limit the time over which a token is
accepted. Tokens provided in NEW_TOKEN frames might need to allow
longer validity periods. Tokens MAY include additional information
about clients to further narrow applicability or reuse.
8.2. Path Validation 8.2. Path Validation
Path validation is used during connection migration (see Section 9 Path validation is used during connection migration (see Section 9
and Section 9.6) by the migrating endpoint to verify reachability of and Section 9.6) by the migrating endpoint to verify reachability of
a peer from a new local address. In path validation, endpoints test a peer from a new local address. In path validation, endpoints test
reachability between a specific local address and a specific peer reachability between a specific local address and a specific peer
address, where an address is the two-tuple of IP address and port. address, where an address is the two-tuple of IP address and port.
Path validation tests that packets (PATH_CHALLENGE) can be both sent Path validation tests that packets (PATH_CHALLENGE) can be both sent
skipping to change at page 58, line 40 skipping to change at page 59, line 7
While in the closing period, an endpoint could receive packets from a While in the closing period, an endpoint could receive packets from a
new source address, indicating a connection migration (Section 9). new source address, indicating a connection migration (Section 9).
An endpoint in the closing state MUST strictly limit the number of An endpoint in the closing state MUST strictly limit the number of
packets it sends to this new address until the address is validated packets it sends to this new address until the address is validated
(see Section 8.2). A server in the closing state MAY instead choose (see Section 8.2). A server in the closing state MAY instead choose
to discard packets received from a new source address. to discard packets received from a new source address.
10.2. Idle Timeout 10.2. Idle Timeout
If the idle timeout is enabled by either peer, a connection is If a max_idle_timeout is specified by either peer in its transport
silently closed and its state is discarded when it remains idle for parameters (Section 18.2), the connection is silently closed and its
longer than the minimum of the max_idle_timeouts (see Section 18.2) state is discarded when it remains idle for longer than the minimum
and three times the current Probe Timeout (PTO). of both peers max_idle_timeout values and three times the current
Probe Timeout (PTO).
Each endpoint advertises a max_idle_timeout, but the effective value Each endpoint advertises a max_idle_timeout, but the effective value
at an endpoint is computed as the minimum of the two advertised at an endpoint is computed as the minimum of the two advertised
values. By announcing a max_idle_timeout, an endpoint commits to values. By announcing a max_idle_timeout, an endpoint commits to
initiating an immediate close (Section 10.3) if it abandons the initiating an immediate close (Section 10.3) if it abandons the
connection prior to the effective value. connection prior to the effective value.
An endpoint restarts its idle timer when a packet from its peer is An endpoint restarts its idle timer when a packet from its peer is
received and processed successfully. The idle timer is also received and processed successfully. An endpoint also restarts its
restarted when sending an ack-eliciting packet (see [QUIC-RECOVERY]), idle timer when sending an ack-eliciting packet if no other ack-
but only if no other ack-eliciting packets have been sent since last eliciting packets have been sent since last receiving and processing
receiving a packet. Restarting when sending packets ensures that a packet. Restarting this timer when sending a packet ensures that
connections do not prematurely time out when initiating new activity. connections are not closed after new activity is initiated.
An endpoint might need to send packets to avoid an idle timeout if it
is unable to send application data due to being blocked on flow
control limits; see Section 4.
An endpoint that sends packets near the end of the idle timeout An endpoint might need to send ack-eliciting packets to avoid an idle
period risks having those packets discarded if its peer enters the timeout if it is expecting response data, but does not have or is
draining state before the packets arrive. If a peer could time out unable to send application data.
within a Probe Timeout (PTO; see Section 6.6 of [QUIC-RECOVERY]), it
is advisable to test for liveness before sending any data that cannot An endpoint that sends packets close to the effective timeout risks
be retried safely. Note that it is likely that only applications or having them be discarded at the peer, since the peer might enter its
application protocols will know what information can be retried. draining state before these packets arrive. An endpoint can send a
PING or another ack-eliciting frame to test the connection for
liveness if the peer could time out soon, such as within a PTO; see
Section 6.6 of [QUIC-RECOVERY]. This is especially useful if any
available application data cannot be safely retried. Note that the
application determines what data is safe to retry.
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 60, line 40 skipping to change at page 61, line 14
10.3.1. Immediate Close During the Handshake 10.3.1. Immediate Close During the Handshake
When sending CONNECTION_CLOSE, the goal is to ensure that the peer When sending CONNECTION_CLOSE, the goal is to ensure that the peer
will process the frame. Generally, this means sending the frame in a will process the frame. Generally, this means sending the frame in a
packet with the highest level of packet protection to avoid the packet with the highest level of packet protection to avoid the
packet being discarded. After the handshake is confirmed (see packet being discarded. After the handshake is confirmed (see
Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any
CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to
confirming the handshake, it is possible that more advanced packet confirming the handshake, it is possible that more advanced packet
protection keys are not available to the peer, so the frame MAY be protection keys are not available to the peer, so another
replicated in a packet that uses a lower packet protection level. CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower
packet protection level. More specifically:
A client will always know whether the server has Handshake keys (see o A client will always know whether the server has Handshake keys
Section 17.2.2.1), but it is possible that a server does not know (see Section 17.2.2.1), but it is possible that a server does not
whether the client has Handshake keys. Under these circumstances, a know whether the client has Handshake keys. Under these
server SHOULD send a CONNECTION_CLOSE frame in both Handshake and circumstances, a server SHOULD send a CONNECTION_CLOSE frame in
Initial packets to ensure that at least one of them is processable by both Handshake and Initial packets to ensure that at least one of
the client. Similarly, a peer might be unable to read 1-RTT packets, them is processable by the client.
so an endpoint SHOULD send CONNECTION_CLOSE in Handshake and 1-RTT
packets prior to confirming the handshake. These packets can be o A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be
assured of the server has accepted 0-RTT and so sending a
CONNECTION_CLOSE frame in an Initial packet makes it more likely
that the server can receive the close signal, even if the
application error code might not be received.
o Prior to confirming the handshake, a peer might be unable to
process 1-RTT packets, so an endpoint SHOULD send CONNECTION_CLOSE
in both Handshake and 1-RTT packets. A server SHOULD also send
CONNECTION_CLOSE in an Initial packet.
Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake
packet could expose application state or be used to alter application
state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a
CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or
Handshake packets. Otherwise, information about the application
state might be revealed. Endpoints MUST clear the value of the
Reason Phrase field and SHOULD use the APPLICATION_ERROR code when
converting to a CONNECTION_CLOSE of type 0x1c.
CONNECTION_CLOSE frames sent in multiple packet types can be
coalesced into a single UDP datagram; see Section 12.2. coalesced into a single UDP datagram; see Section 12.2.
An endpoint might send a CONNECTION_CLOSE frame in an Initial packet An endpoint might send a CONNECTION_CLOSE frame in an Initial packet
or in response to unauthenticated information received in Initial or or in response to unauthenticated information received in Initial or
Handshake packets. Such an immediate close might expose legitimate Handshake packets. Such an immediate close might expose legitimate
connections to a denial of service. QUIC does not include defensive connections to a denial of service. QUIC does not include defensive
measures for on-path attacks during the handshake; see Section 21.1. measures for on-path attacks during the handshake; see Section 21.1.
However, at the cost of reducing feedback about errors for legitimate However, at the cost of reducing feedback about errors for legitimate
peers, some forms of denial of service can be made more difficult for peers, some forms of denial of service can be made more difficult for
an attacker if endpoints discard illegal packets rather than an attacker if endpoints discard illegal packets rather than
terminating a connection with CONNECTION_CLOSE. For this reason, terminating a connection with CONNECTION_CLOSE. For this reason,
endpoints MAY discard packets rather than immediately close if errors endpoints MAY discard packets rather than immediately close if errors
are detected in packets that lack authentication. are detected in packets that lack authentication.
An endpoint that has not established state, such as a server that An endpoint that has not established state, such as a server that
detects an error in an Initial packet, does not enter the closing detects an error in an Initial packet, does not enter the closing
state. An endpoint that has no state for the connection does not state. An endpoint that has no state for the connection does not
skipping to change at page 68, line 47 skipping to change at page 69, line 47
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
authenticated. authenticated.
All other packets are protected with keys derived from the All other packets are protected with keys derived from the
cryptographic handshake. The type of the packet from the long header cryptographic handshake. The type of the packet from the long header
or key phase from the short header are used to identify which or key phase from the short header are used to identify which
encryption level - and therefore the keys - that are used. Packets encryption keys are used. Packets protected with 0-RTT and 1-RTT
protected with 0-RTT and 1-RTT keys are expected to have keys are expected to have confidentiality and data origin
confidentiality and data origin authentication; the cryptographic authentication; the cryptographic handshake ensures that only the
handshake ensures that only the communicating endpoints receive the communicating endpoints receive the corresponding keys.
corresponding keys.
The packet number field contains a packet number, which has The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet additional confidentiality protection that is applied after packet
protection is applied (see [QUIC-TLS] for details). The underlying protection is applied (see [QUIC-TLS] for details). The underlying
packet number increases with each packet sent in a given packet packet number increases with each packet sent in a given packet
number space; see Section 12.3 for details. number space; see Section 12.3 for details.
12.2. Coalescing Packets 12.2. Coalescing Packets
Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake
skipping to change at page 69, line 28 skipping to change at page 70, line 28
learned once header protection is removed. learned once header protection is removed.
Using the Length field, a sender can coalesce multiple QUIC packets Using the Length field, a sender can coalesce multiple QUIC packets
into one UDP datagram. This can reduce the number of UDP datagrams into one UDP datagram. This can reduce the number of UDP datagrams
needed to complete the cryptographic handshake and start sending needed to complete the cryptographic handshake and start sending
data. This can also be used to construct PMTU probes (see data. This can also be used to construct PMTU probes (see
Section 14.3.1). Receivers MUST be able to process coalesced Section 14.3.1). Receivers MUST be able to process coalesced
packets. packets.
Coalescing packets in order of increasing encryption levels (Initial, Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it
able to process all the packets in a single pass. A packet with a more likely the receiver will be able to process all the packets in a
short header does not include a length, so it can only be the last single pass. A packet with a short header does not include a length,
packet included in a UDP datagram. An endpoint SHOULD NOT coalesce so it can only be the last packet included in a UDP datagram. An
multiple packets at the same encryption level. endpoint SHOULD NOT coalesce multiple packets at the same encryption
level.
Senders MUST NOT coalesce QUIC packets for different connections into Senders MUST NOT coalesce QUIC packets for different connections into
a single UDP datagram. Receivers SHOULD ignore any subsequent a single UDP datagram. Receivers SHOULD ignore any subsequent
packets with a different Destination Connection ID than the first packets with a different Destination Connection ID than the first
packet in the datagram. packet in the datagram.
Every QUIC packet that is coalesced into a single UDP datagram is Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete. 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
skipping to change at page 73, line 44 skipping to change at page 74, line 44
| 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 |
| | | | | | | | | |
| 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 |
| | | | | | | | | |
| 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 |
| | | | | | | | | |
| 0x1b | PATH_RESPONSE | Section 19.18 | __01 | | 0x1b | PATH_RESPONSE | Section 19.18 | __01 |
| | | | | | | | | |
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | IH_1* | | 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 "Packets" column in Table 3 does not form part of the IANA
registry (see Section 22.3). This column lists the types of packets registry (see Section 22.3). This column lists the types of packets
that each frame type can appear in, indicated by the following that each frame type could appear in, indicated by the following
characters: 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)
*: A CONNECTION_CLOSE frame of type 0x1c can appear in Initial, ih: A CONNECTION_CLOSE frame of type 0x1d cannot appear in Initial
Handshake, and 1-RTT packets, whereas a CONNECTION_CLOSE of type or Handshake packets.
0x1d can only appear in a 1-RTT packet.
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.
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.
skipping to change at page 75, line 43 skipping to change at page 76, line 42
receipt by sending one or more ACK frames containing the packet receipt by sending one or more ACK frames containing the packet
number of the received packet. number of the received packet.
13.2. Generating Acknowledgements 13.2. Generating Acknowledgements
Endpoints acknowledge all packets they receive and process. However, Endpoints acknowledge all packets they receive and process. However,
only ack-eliciting packets cause an ACK frame to be sent within the only ack-eliciting packets cause an ACK frame to be sent within the
maximum ack delay. Packets that are not ack-eliciting are only maximum ack delay. Packets that are not ack-eliciting are only
acknowledged when an ACK frame is sent for other reasons. acknowledged when an ACK frame is sent for other reasons.
When sending a packet for any reason, an endpoint should attempt to When sending a packet for any reason, an endpoint SHOULD attempt to
bundle an ACK frame if one has not been sent recently. Doing so bundle an ACK frame if one has not been sent recently. Doing so
helps with timely loss detection at the peer. helps with timely loss detection at the peer.
In general, frequent feedback from a receiver improves loss and In general, frequent feedback from a receiver improves loss and
congestion response, but this has to be balanced against excessive congestion response, but this has to be balanced against excessive
load generated by a receiver that sends an ACK frame in response to load generated by a receiver that sends an ACK frame in response to
every ack-eliciting packet. The guidance offered below seeks to every ack-eliciting packet. The guidance offered below seeks to
strike this balance. strike this balance.
13.2.1. Sending ACK Frames 13.2.1. Sending ACK Frames
skipping to change at page 76, line 22 skipping to change at page 77, line 22
intentionally delay acknowledgments of an ack-eliciting packet by intentionally delay acknowledgments of an ack-eliciting packet by
more than the indicated value. If it does, any excess accrues to the more than the indicated value. If it does, any excess accrues to the
RTT estimate and could result in spurious or delayed retransmissions RTT estimate and could result in spurious or delayed retransmissions
from the peer. For Initial and Handshake packets, a max_ack_delay of from the peer. For Initial and Handshake packets, a max_ack_delay of
0 is used. The sender uses the receiver's "max_ack_delay" value in 0 is used. The sender uses the receiver's "max_ack_delay" value in
determining timeouts for timer-based retransmission, as detailed in determining timeouts for timer-based retransmission, as detailed in
Section 5.2.1 of [QUIC-RECOVERY]. Section 5.2.1 of [QUIC-RECOVERY].
An ACK frame SHOULD be generated for at least every second ack- An ACK frame SHOULD be generated for at least every second ack-
eliciting packet. This recommendation is in keeping with standard eliciting packet. This recommendation is in keeping with standard
practice for TCP [RFC5681]. practice for TCP [RFC5681]. A receiver could decide to send an ACK
frame less frequently if it has information about how frequently the
sender's congestion controller needs feedback, or if the receiver is
CPU or bandwidth constrained.
In order to assist loss detection at the sender, an endpoint SHOULD In order to assist loss detection at the sender, an endpoint SHOULD
send an ACK frame immediately on receiving an ack-eliciting packet send an ACK frame immediately on receiving an ack-eliciting packet
that is out of order. The endpoint MAY continue sending ACK frames that is out of order. The endpoint SHOULD NOT continue sending ACK
immediately on each subsequently received packet, but the endpoint frames immediately unless more ack-eliciting packets are received out
SHOULD return to acknowledging every other packet within a period of of order. If every subsequent ack-eliciting packet arrives out of
1/8 x RTT, unless more ack-eliciting packets are received out of
order. If every subsequent ack-eliciting packet arrives out of
order, then an ACK frame SHOULD be sent immediately for every order, then an ACK frame SHOULD be sent immediately for every
received ack-eliciting packet. received ack-eliciting packet.
Similarly, packets marked with the ECN Congestion Experienced (CE) Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to codepoint in the IP header SHOULD be acknowledged immediately, to
reduce the peer's response time to congestion events. reduce the peer's response time to congestion events.
As an optimization, a receiver MAY process multiple packets before As an optimization, a receiver MAY process multiple packets before
sending any ACK frames in response. In this case the receiver can sending any ACK frames in response. In this case the receiver can
determine whether an immediate or delayed acknowledgement should be determine whether an immediate or delayed acknowledgement should be
skipping to change at page 78, line 24 skipping to change at page 79, line 24
of 1 RTT of reordering. In cases with ACK frame loss and reordering, of 1 RTT of reordering. In cases with ACK frame loss and reordering,
this approach does not guarantee that every acknowledgement is seen this approach does not guarantee that every acknowledgement is seen
by the sender before it is no longer included in the ACK frame. by the sender before it is no longer included in the ACK frame.
Packets could be received out of order and all subsequent ACK frames Packets could be received out of order and all subsequent ACK frames
containing them could be lost. In this case, the loss recovery containing them could be lost. In this case, the loss recovery
algorithm could cause spurious retransmits, but the sender will algorithm could cause spurious retransmits, but the sender will
continue making forward progress. continue making forward progress.
13.2.4. Limiting ACK Ranges 13.2.4. Limiting ACK Ranges
To limit ACK Ranges (see Section 19.3.1) to those that have not yet A receiver limits the number of ACK Ranges (Section 19.3.1) it
been received by the sender, the receiver SHOULD track which ACK remembers and sends in ACK frames, both to limit the size of ACK
frames have been acknowledged by its peer. The receiver SHOULD frames and to avoid resource exhaustion. After receiving
exclude already acknowledged packets from future ACK frames whenever acknowledgments for an ACK frame, the receiver SHOULD stop tracking
these packets would unnecessarily contribute to the ACK frame size. those acknowledged ACK Ranges.
When the receiver is only sending non-ack-eliciting packets, it can
bundle a PING or other small ack-eliciting frame with a fraction of
them, such as once per round trip, to enable dropping unnecessary ACK
ranges and any state for previously sent packets. The receiver MUST
NOT bundle an ack-eliciting frame, such as a PING, with all packets
that would otherwise be non-ack-eliciting, in order to avoid an
infinite feedback loop of acknowledgements.
To limit receiver state or the size of ACK frames, a receiver MAY It is possible that retaining many ACK Ranges could cause an ACK
limit the number of ACK Ranges it sends. A receiver can do this even frame to become too large. A receiver can discard unacknowledged ACK
without receiving acknowledgment of its ACK frames, with the Ranges to limit ACK frame size, at the cost of increased
knowledge this could cause the sender to unnecessarily retransmit retransmissions from the sender. This is necessary if an ACK frame
some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare would be too large to fit in a packet, however receivers MAY also
packets lost after sufficiently newer packets are acknowledged. limit ACK frame size further to preserve space for other frames.
Therefore, the receiver SHOULD repeatedly acknowledge newly received
packets in preference to packets received in the past. When discarding unacknowledged ACK Ranges, a receiver MUST retain the
largest received packet number. A receiver SHOULD retain ACK Ranges
containing newly received packets or higher-numbered packets.
A receiver that sends only non-ack-eliciting packets, such as ACK
frames, might not receive an acknowledgement for a long period of
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
sends could be unnecessarily large. In such a case, a receiver could
bundle a PING or other small ack-eliciting frame occasionally, such
as once per round trip, to elicit an ACK from the peer.
A receiver MUST NOT bundle an ack-eliciting frame with all packets
that would otherwise be non-ack-eliciting, to avoid an infinite
feedback loop of acknowledgements.
13.2.5. Measuring and Reporting Host Delay 13.2.5. 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 79, line 40 skipping to change at page 80, line 48
New frames and packets are used to carry information that is New frames and packets are used to carry information that is
determined to have been lost. In general, information is sent again determined to have been lost. In general, information is sent again
when a packet containing that information is determined to be lost when a packet containing that information is determined to be lost
and sending ceases when a packet containing that information is and sending ceases when a packet containing that information is
acknowledged. acknowledged.
o Data sent in CRYPTO frames is retransmitted according to the rules o Data sent in CRYPTO frames is retransmitted according to the rules
in [QUIC-RECOVERY], until all data has been acknowledged. Data in in [QUIC-RECOVERY], until all data has been acknowledged. Data in
CRYPTO frames for Initial and Handshake packets is discarded when CRYPTO frames for Initial and Handshake packets is discarded when
keys for the corresponding encryption level are discarded. keys for the corresponding packet number space are discarded.
o Application data sent in STREAM frames is retransmitted in new o Application data sent in STREAM frames is retransmitted in new
STREAM frames unless the endpoint has sent a RESET_STREAM for that STREAM frames unless the endpoint has sent a RESET_STREAM for that
stream. Once an endpoint sends a RESET_STREAM frame, no further stream. Once an endpoint sends a RESET_STREAM frame, no further
STREAM frames are needed. STREAM frames are needed.
o ACK frames carry the most recent set of acknowledgements and the o ACK frames carry the most recent set of acknowledgements and the
Ack Delay from the largest acknowledged packet, as described in Ack Delay from the largest acknowledged packet, as described in
Section 13.2.1. Delaying the transmission of packets containing Section 13.2.1. Delaying the transmission of packets containing
ACK frames or sending old ACK frames can cause the peer to ACK frames or sending old ACK frames can cause the peer to
skipping to change at page 96, line 8 skipping to change at page 97, line 34
| Packet Number (8/16/24/32) ... | Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ... | Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Initial Packet Figure 11: Initial Packet
The Initial packet contains a long header as well as the Length and The Initial packet contains a long header as well as the Length and
Packet Number fields. The first byte contains the Reserved and Packet Number fields. The first byte contains the Reserved and
Packet Number Length bits. Between the SCID and Length fields, there Packet Number Length bits. Between the SCID and Length fields, there
are two additional field specific to the Initial packet. are two additional fields specific to the Initial packet.
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
Token field, in bytes. This value is zero if no token is present. Token field, in bytes. This value is zero if no token is present.
Initial packets sent by the server MUST set the Token Length field Initial packets sent by the server MUST set the Token Length field
to zero; clients that receive an Initial packet with a non-zero to zero; clients that receive an Initial packet with a non-zero
Token Length field MUST either discard the packet or generate a Token Length field MUST either discard the packet or generate a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
Token: The value of the token that was previously provided in a Token: The value of the token that was previously provided in a
Retry packet or NEW_TOKEN frame. Retry packet or NEW_TOKEN frame.
skipping to change at page 100, line 14 skipping to change at page 101, line 19
Handshake packets are their own packet number space, and thus the Handshake packets are their own packet number space, and thus the
first Handshake packet sent by a server contains a packet number of first Handshake packet sent by a server contains a packet number of
0. 0.
The payload of this packet contains CRYPTO frames and could contain The payload of this packet contains CRYPTO frames and could contain
PING, PADDING, or ACK frames. Handshake packets MAY contain PING, PADDING, or ACK frames. Handshake packets MAY contain
CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake
packets with other frames as a connection error. packets with other frames as a connection error.
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames
the Handshake encryption level is discarded - and no longer for Handshake packets is discarded - and no longer retransmitted -
retransmitted - when Handshake protection keys are discarded. when Handshake protection keys are discarded.
17.2.5. Retry Packet 17.2.5. Retry Packet
A Retry packet uses a long packet header with a type value of 0x3. A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server. It is It carries an address validation token created by the server. It is
used by a server that wishes to perform a retry (see Section 8.1). used by a server that wishes to perform a retry (see Section 8.1).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 107, line 33 skipping to change at page 108, line 48
parameter or specify a value of 0. parameter or specify a value of 0.
stateless_reset_token (0x02): A stateless reset token is used in stateless_reset_token (0x02): A stateless reset token is used in
verifying a stateless reset; see Section 10.4. This parameter is verifying a stateless reset; see Section 10.4. This parameter is
a sequence of 16 bytes. This transport parameter MUST NOT be sent a sequence of 16 bytes. This transport parameter MUST NOT be sent
by a client, but MAY be sent by a server. A server that does not by a client, but MAY be sent by a server. A server that does not
send this transport parameter cannot use stateless reset send this transport parameter cannot use stateless reset
(Section 10.4) for the connection ID negotiated during the (Section 10.4) for the connection ID negotiated during the
handshake. handshake.
max_packet_size (0x03): The maximum packet size parameter is an max_udp_payload_size (0x03): The maximum UDP payload size parameter
integer value that limits the size of packets that the endpoint is is an integer value that limits the size of UDP payloads that the
willing to receive. This indicates that packets larger than this endpoint is willing to receive. UDP packets with payloads larger
limit will be dropped. The default for this parameter is the than this limit are not likely to be processed by the receiver.
maximum permitted UDP payload of 65527. Values below 1200 are
invalid. This limit only applies to protected packets
(Section 12.1).
initial_max_data (0x04): The initial maximum data parameter is an The default for this parameter is the maximum permitted UDP
integer value that contains the initial value for the maximum payload of 65527. Values below 1200 are invalid.
amount of data that can be sent on the connection. This is
equivalent to sending a MAX_DATA (Section 19.9) for the connection This limit does act as an additional constraint on datagram size
immediately after completing the handshake. in the same way as the path MTU, but it is a property of the
endpoint and not the path. It is expected that this is the space
an endpoint dedicates to holding incoming packets.
initial_max_data (0x04):
The initial maximum data parameter is an integer value that
contains the initial value for the maximum amount of data that can
be sent on the connection. This is equivalent to sending a
MAX_DATA (Section 19.9) for the connection immediately after
completing the handshake.
initial_max_stream_data_bidi_local (0x05): This parameter is an initial_max_stream_data_bidi_local (0x05): This parameter is an
integer value specifying the initial flow control limit for integer value specifying the initial flow control limit for
locally-initiated bidirectional streams. This limit applies to locally-initiated bidirectional streams. This limit applies to
newly created bidirectional streams opened by the endpoint that newly created bidirectional streams opened by the endpoint that
sends the transport parameter. In client transport parameters, sends the transport parameter. In client transport parameters,
this applies to streams with an identifier with the least this applies to streams with an identifier with the least
significant two bits set to 0x0; in server transport parameters, significant two bits set to 0x0; in server transport parameters,
this applies to streams with the least significant two bits set to this applies to streams with the least significant two bits set to
0x1. 0x1.
skipping to change at page 109, line 24 skipping to change at page 110, line 45
port other than that used to perform the handshake. This port other than that used to perform the handshake. This
parameter is a zero-length value. parameter is a zero-length value.
preferred_address (0x0d): The server's preferred address is used to preferred_address (0x0d): The server's preferred address is used to
effect a change in server address at the end of the handshake, as effect a change in server address at the end of the handshake, as
described in Section 9.6. The format of this transport parameter described in Section 9.6. The format of this transport parameter
is shown in Figure 17. This transport parameter is only sent by a is shown in Figure 17. This transport parameter is only sent by a
server. Servers MAY choose to only send a preferred address of server. Servers MAY choose to only send a preferred address of
one address family by sending an all-zero address and port one address family by sending an all-zero address and port
(0.0.0.0:0 or ::.0) for the other family. IP addresses are (0.0.0.0:0 or ::.0) for the other family. IP addresses are
encoded in network byte order. The CID Length field contains the encoded in network byte order.
length of the Connection ID field.
The Connection ID field and the Stateless Reset Token field
contain an alternative connection ID that has a sequence number of
1 (Section 5.1.1). Having these values bundled with the preferred
address ensures that there will be at least one unused active
connection ID when the client initiates migration to the preferred
address.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (32) | | IPv4 Address (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Port (16) | | IPv4 Port (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
skipping to change at page 120, line 28 skipping to change at page 121, line 28
o The LEN bit (0x02) in the frame type is set to indicate that there o The LEN bit (0x02) in the frame type is set to indicate that there
is a Length field present. If this bit is set to 0, the Length is a Length field present. If this bit is set to 0, the Length
field is absent and the Stream Data field extends to the end of field is absent and the Stream Data field extends to the end of
the packet. If this bit is set to 1, the Length field is present. the packet. If this bit is set to 1, the Length field is present.
o The FIN bit (0x01) of the frame type is set only on frames that o The FIN bit (0x01) of the frame type is set only on frames that
contain the final size of the stream. Setting this bit indicates contain the final size of the stream. Setting this bit indicates
that the frame marks the end of the stream. that the frame marks the end of the stream.
An endpoint that receives a STREAM frame for a send-only stream MUST An endpoint MUST terminate the connection with error
terminate the connection with error STREAM_STATE_ERROR. STREAM_STATE_ERROR if it receives a STREAM frame for a locally-
initiated stream that has not yet been created, or for a send-only
stream.
The STREAM frames are shown in Figure 25. The STREAM frames are shown in Figure 25.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Offset (i)] ... | [Offset (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 127, line 31 skipping to change at page 128, line 31
Sequence Number MUST be treated as a connection error of type Sequence Number MUST be treated as a connection error of type
FRAME_ENCODING_ERROR. FRAME_ENCODING_ERROR.
Once a sender indicates a Retire Prior To value, smaller values sent Once a sender indicates a Retire Prior To value, smaller values sent
in subsequent NEW_CONNECTION_ID frames have no effect. A receiver in subsequent NEW_CONNECTION_ID frames have no effect. A receiver
MUST ignore any Retire Prior To fields that do not increase the MUST ignore any Retire Prior To fields that do not increase the
largest received Retire Prior To value. largest received Retire Prior To value.
An endpoint that receives a NEW_CONNECTION_ID frame with a sequence An endpoint that receives a NEW_CONNECTION_ID frame with a sequence
number smaller than the Retire Prior To field of a previously number smaller than the Retire Prior To field of a previously
received NEW_CONNECTION_ID frame MUST immediately send a received NEW_CONNECTION_ID frame MUST send a corresponding
corresponding RETIRE_CONNECTION_ID frame that retires the newly RETIRE_CONNECTION_ID frame that retires the newly received connection
received connection ID. ID, unless it has already done so for that sequence number.
19.16. RETIRE_CONNECTION_ID Frame 19.16. RETIRE_CONNECTION_ID Frame
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to
indicate that it will no longer use a connection ID that was issued indicate that it will no longer use a connection ID that was issued
by its peer. This may include the connection ID provided during the by its peer. This may include the connection ID provided during the
handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a
request to the peer to send additional connection IDs for future use request to the peer to send additional connection IDs for future use
(see Section 5.1). New connection IDs can be delivered to a peer (see Section 5.1). New connection IDs can be delivered to a peer
using the NEW_CONNECTION_ID frame (Section 19.15). using the NEW_CONNECTION_ID frame (Section 19.15).
skipping to change at page 130, line 28 skipping to change at page 131, line 28
length of the reason phrase in bytes. Because a CONNECTION_CLOSE length of the reason phrase in bytes. Because a CONNECTION_CLOSE
frame cannot be split between packets, any limits on packet size frame cannot be split between packets, any limits on packet size
will also limit the space available for a reason phrase. will also limit the space available for a reason phrase.
Reason Phrase: A human-readable explanation for why the connection Reason Phrase: A human-readable explanation for why the connection
was closed. This can be zero length if the sender chooses to not was closed. This can be zero length if the sender chooses to not
give details beyond the Error Code. This SHOULD be a UTF-8 give details beyond the Error Code. This SHOULD be a UTF-8
encoded string [RFC3629]. encoded string [RFC3629].
The application-specific variant of CONNECTION_CLOSE (type 0x1d) can The application-specific variant of CONNECTION_CLOSE (type 0x1d) can
only be sent using an 1-RTT packet ([QUIC-TLS], Section 4). When an only be sent using 0-RTT or 1-RTT packets ([QUIC-TLS], Section 4).
application wishes to abandon a connection during the handshake, an When an application wishes to abandon a connection during the
endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error handshake, an endpoint can send a CONNECTION_CLOSE frame (type 0x1c)
code of 0x15a ("user_canceled" alert; see [TLS13]) in an Initial or a with an error code of APPLICATION_ERROR in an Initial or a Handshake
Handshake packet. packet.
19.20. HANDSHAKE_DONE frame 19.20. HANDSHAKE_DONE frame
The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal
confirmation of the handshake to the client. The HANDSHAKE_DONE confirmation of the handshake to the client. The HANDSHAKE_DONE
frame contains no additional fields. frame contains no additional fields.
This frame can only be sent by the server. Servers MUST NOT send a This frame can only be sent by the server. Servers MUST NOT send a
HANDSHAKE_DONE frame before completing the handshake. A server MUST HANDSHAKE_DONE frame before completing the handshake. A server MUST
treat receipt of a HANDSHAKE_DONE frame as a connection error of type treat receipt of a HANDSHAKE_DONE frame as a connection error of type
skipping to change at page 132, line 34 skipping to change at page 133, line 34
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 Retry Token in a client
Initial that is invalid. Initial that is invalid.
APPLICATION_ERROR (0xC): The application or application protocol
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
when TLS is used for the crypto handshake are described in when TLS is used for the crypto handshake are described in
Section 4.8 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 22.4 for details of registering new error codes. See Section 22.4 for details of registering new error codes.
skipping to change at page 148, line 14 skipping to change at page 149, line 16
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| Value | Parameter Name | Specification | | Value | Parameter Name | Specification |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x00 | original_connection_id | Section 18.2 | | 0x00 | original_connection_id | Section 18.2 |
| | | | | | | |
| 0x01 | max_idle_timeout | Section 18.2 | | 0x01 | max_idle_timeout | Section 18.2 |
| | | | | | | |
| 0x02 | stateless_reset_token | Section 18.2 | | 0x02 | stateless_reset_token | Section 18.2 |
| | | | | | | |
| 0x03 | max_packet_size | Section 18.2 | | 0x03 | max_udp_payload_size | Section 18.2 |
| | | | | | | |
| 0x04 | initial_max_data | Section 18.2 | | 0x04 | initial_max_data | Section 18.2 |
| | | | | | | |
| 0x05 | initial_max_stream_data_bidi_local | Section 18.2 | | 0x05 | initial_max_stream_data_bidi_local | Section 18.2 |
| | | | | | | |
| 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 | | 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 |
| | | | | | | |
| 0x07 | initial_max_stream_data_uni | Section 18.2 | | 0x07 | initial_max_stream_data_uni | Section 18.2 |
| | | | | | | |
| 0x08 | initial_max_streams_bidi | Section 18.2 | | 0x08 | initial_max_streams_bidi | Section 18.2 |
skipping to change at page 150, line 42 skipping to change at page 151, line 45
| | | connection IDs | | | | | connection IDs | |
| | | received | | | | | received | |
| | | | | | | | | |
| 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 |
| | | protocol | | | | | protocol | |
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xB | INVALID_TOKEN | Invalid Token | Section 20 | | 0xB | INVALID_TOKEN | Invalid Token | Section 20 |
| | | Received | | | | | Received | |
| | | | | | | | | |
| 0xC | APPLICATION_ERROR | Application | Section 20 |
| | | error | |
| | | | |
| 0xD | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 | | 0xD | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 |
| | | buffer | | | | | buffer | |
| | | overflowed | | | | | overflowed | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
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-14 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-17
(work in progress), February 2020. (work in progress), March 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-27 (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-27 (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 153, line 7 skipping to change at page 154, line 7
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-07 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-06 Transport Protocol", draft-ietf-quic-manageability-06
(work in progress), January 2020. (work in progress), January 2020.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
skipping to change at page 156, line 35 skipping to change at page 157, line 35
Appendix C. Change Log Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-26 C.1. Since draft-ietf-quic-transport-26
o Change format of transport paramters to use varints (#3294, #3169) o Change format of transport parameters to use varints (#3294,
#3169)
C.2. Since draft-ietf-quic-transport-25 C.2. Since draft-ietf-quic-transport-25
o Define the use of CONNECTION_CLOSE prior to establishing o Define the use of CONNECTION_CLOSE prior to establishing
connection state (#3269, #3297, #3292) connection state (#3269, #3297, #3292)
o Allow use of address validation tokens after client address o Allow use of address validation tokens after client address
changes (#3307, #3308) changes (#3307, #3308)
o Define the timer for address validation (#2910, #3339) o Define the timer for address validation (#2910, #3339)
 End of changes. 76 change blocks. 
361 lines changed or deleted 443 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/