draft-ietf-quic-transport-05.txt   draft-ietf-quic-transport-06.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: February 16, 2018 Mozilla Expires: March 26, 2018 Mozilla
August 15, 2017 September 22, 2017
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-05 draft-ietf-quic-transport-06
Abstract Abstract
This document defines the core of the QUIC transport protocol. This This document defines the core of the QUIC transport protocol. This
document describes connection establishment, packet format, document describes connection establishment, packet format,
multiplexing and reliability. Accompanying documents describe the multiplexing and reliability. Accompanying documents describe the
cryptographic handshake and loss detection. cryptographic handshake and loss detection.
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
mailing list (quic@ietf.org), which is archived at mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic. https://mailarchive.ietf.org/arch/search/?email_list=quic .
Working Group information can be found at https://github.com/quicwg; Working Group information can be found at https://github.com/quicwg ;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
https://github.com/quicwg/base-drafts/labels/transport. https://github.com/quicwg/base-drafts/labels/transport .
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 16, 2018. This Internet-Draft will expire on March 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
5.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 16 5.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 16
5.6. Connection ID . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Connection ID . . . . . . . . . . . . . . . . . . . . . . 17
5.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 17 5.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 17
5.7.1. Initial Packet Number . . . . . . . . . . . . . . . . 19 5.7.1. Initial Packet Number . . . . . . . . . . . . . . . . 19
5.8. Handling Packets from Different Versions . . . . . . . . 19 5.8. Handling Packets from Different Versions . . . . . . . . 19
6. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 19 6. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 19
7. Life of a Connection . . . . . . . . . . . . . . . . . . . . 21 7. Life of a Connection . . . . . . . . . . . . . . . . . . . . 21
7.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 22 7.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 22
7.1.1. Using Reserved Versions . . . . . . . . . . . . . . . 23 7.1.1. Using Reserved Versions . . . . . . . . . . . . . . . 23
7.2. Cryptographic and Transport Handshake . . . . . . . . . . 23 7.2. Cryptographic and Transport Handshake . . . . . . . . . . 23
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 24 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 25
7.3.1. Transport Parameter Definitions . . . . . . . . . . . 26 7.3.1. Transport Parameter Definitions . . . . . . . . . . . 26
7.3.2. Values of Transport Parameters for 0-RTT . . . . . . 27 7.3.2. Values of Transport Parameters for 0-RTT . . . . . . 27
7.3.3. New Transport Parameters . . . . . . . . . . . . . . 27 7.3.3. New Transport Parameters . . . . . . . . . . . . . . 28
7.3.4. Version Negotiation Validation . . . . . . . . . . . 28 7.3.4. Version Negotiation Validation . . . . . . . . . . . 28
7.4. Stateless Retries . . . . . . . . . . . . . . . . . . . . 29 7.4. Stateless Retries . . . . . . . . . . . . . . . . . . . . 29
7.5. Proof of Source Address Ownership . . . . . . . . . . . . 29 7.5. Proof of Source Address Ownership . . . . . . . . . . . . 30
7.5.1. Client Address Validation Procedure . . . . . . . . . 30 7.5.1. Client Address Validation Procedure . . . . . . . . . 31
7.5.2. Address Validation on Session Resumption . . . . . . 31 7.5.2. Address Validation on Session Resumption . . . . . . 31
7.5.3. Address Validation Token Integrity . . . . . . . . . 32 7.5.3. Address Validation Token Integrity . . . . . . . . . 32
7.6. Connection Migration . . . . . . . . . . . . . . . . . . 32 7.6. Connection Migration . . . . . . . . . . . . . . . . . . 32
7.6.1. Privacy Implications of Connection Migration . . . . 32 7.6.1. Privacy Implications of Connection Migration . . . . 33
7.6.2. Address Validation for Migrated Connections . . . . . 33 7.6.2. Address Validation for Migrated Connections . . . . . 34
7.7. Connection Termination . . . . . . . . . . . . . . . . . 34 7.7. Connection Termination . . . . . . . . . . . . . . . . . 34
7.8. Stateless Reset . . . . . . . . . . . . . . . . . . . . . 34 7.7.1. Draining Period . . . . . . . . . . . . . . . . . . . 34
7.8.1. Detecting a Stateless Reset . . . . . . . . . . . . . 36 7.7.2. Application Close . . . . . . . . . . . . . . . . . . 35
7.8.2. Calculating a Stateless Reset Token . . . . . . . . . 36 7.7.3. Idle Timeout . . . . . . . . . . . . . . . . . . . . 35
8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 37 7.7.4. Immediate Close . . . . . . . . . . . . . . . . . . . 35
8.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 37 7.7.5. Stateless Reset . . . . . . . . . . . . . . . . . . . 36
8.2. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 37 8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 38
8.3. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 38 8.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 38
8.4. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 39 8.2. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 39
8.5. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 39 8.3. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 39
8.6. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 40 8.4. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 40
8.7. PING frame . . . . . . . . . . . . . . . . . . . . . . . 41 8.5. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 41
8.8. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 41 8.6. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 42
8.9. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 41 8.7. PING frame . . . . . . . . . . . . . . . . . . . . . . . 42
8.10. STREAM_ID_NEEDED Frame . . . . . . . . . . . . . . . . . 42 8.8. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 43
8.11. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 42 8.9. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 43
8.12. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 43 8.10. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 43
8.13. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 43 8.11. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 44
8.13.1. ACK Block Section . . . . . . . . . . . . . . . . . 46 8.12. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 44
8.13.2. Timestamp Section . . . . . . . . . . . . . . . . . 46 8.13. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 45
8.13.3. ACK Frames and Packet Protection . . . . . . . . . . 48 8.13.1. ACK Block Section . . . . . . . . . . . . . . . . . 47
8.14. STREAM Frame . . . . . . . . . . . . . . . . . . . . . . 49 8.13.2. Timestamp Section . . . . . . . . . . . . . . . . . 48
9. Packetization and Reliability . . . . . . . . . . . . . . . . 51 8.13.3. ACK Frames and Packet Protection . . . . . . . . . . 50
9.1. Special Considerations for PMTU Discovery . . . . . . . . 53 8.14. STREAM Frame . . . . . . . . . . . . . . . . . . . . . . 51
10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 53 9. Packetization and Reliability . . . . . . . . . . . . . . . . 53
10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 54 9.1. Special Considerations for PMTU Discovery . . . . . . . . 55
10.2. Life of a Stream . . . . . . . . . . . . . . . . . . . . 54 10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 55
10.2.1. idle . . . . . . . . . . . . . . . . . . . . . . . . 56 10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 56
10.2.2. open . . . . . . . . . . . . . . . . . . . . . . . . 56 10.2. Life of a Stream . . . . . . . . . . . . . . . . . . . . 56
10.2.3. half-closed (local) . . . . . . . . . . . . . . . . 57 10.2.1. idle . . . . . . . . . . . . . . . . . . . . . . . . 58
10.2.4. half-closed (remote) . . . . . . . . . . . . . . . . 57 10.2.2. open . . . . . . . . . . . . . . . . . . . . . . . . 58
10.2.5. closed . . . . . . . . . . . . . . . . . . . . . . . 58 10.2.3. half-closed (local) . . . . . . . . . . . . . . . . 59
10.3. Solicited State Transitions . . . . . . . . . . . . . . 58 10.2.4. half-closed (remote) . . . . . . . . . . . . . . . . 59
10.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 59 10.2.5. closed . . . . . . . . . . . . . . . . . . . . . . . 60
10.5. Sending and Receiving Data . . . . . . . . . . . . . . . 59 10.3. Solicited State Transitions . . . . . . . . . . . . . . 60
10.6. Stream Prioritization . . . . . . . . . . . . . . . . . 60 10.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 61
11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 61 10.5. Sending and Receiving Data . . . . . . . . . . . . . . . 61
11.1. Edge Cases and Other Considerations . . . . . . . . . . 62 10.6. Stream Prioritization . . . . . . . . . . . . . . . . . 62
11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 63 11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 63
11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 63 11.1. Edge Cases and Other Considerations . . . . . . . . . . 64
11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 63 11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 65
11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 64 11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 65
11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 64 11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 65
12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 65 11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 66
12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 65 11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 66
12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 66 12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 67
12.3. Error Codes . . . . . . . . . . . . . . . . . . . . . . 66 12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 67
13. Security and Privacy Considerations . . . . . . . . . . . . . 68 12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 68
13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 68 12.3. Error Codes . . . . . . . . . . . . . . . . . . . . . . 68
13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 68 13. Security and Privacy Considerations . . . . . . . . . . . . . 70
13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 69 13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 70
13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 69 13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 70
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 71
14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 70 13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 71
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
15.1. Normative References . . . . . . . . . . . . . . . . . . 71 14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 72
15.2. Informative References . . . . . . . . . . . . . . . . . 72 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 73
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 73 15.1. Normative References . . . . . . . . . . . . . . . . . . 73
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 73 15.2. Informative References . . . . . . . . . . . . . . . . . 74
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 73 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 74 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 75
C.1. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 74 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 75
C.2. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 74 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 76
C.3. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 75 C.1. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 76
C.4. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 76 C.2. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 76
C.5. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 78 C.3. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 77
C.6. Since draft-hamilton-quic-transport-protocol-01 . . . . . 78 C.4. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 C.5. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 78
C.6. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 80
C.7. Since draft-hamilton-quic-transport-protocol-01 . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
QUIC is a multiplexed and secure transport protocol that runs on top QUIC is a multiplexed and secure transport protocol that runs on top
of UDP. QUIC aims to provide a flexible set of features that allow of UDP. QUIC aims to provide a flexible set of features that allow
it to be a general-purpose transport for multiple applications. it to be a general-purpose transport for multiple applications.
QUIC implements techniques learned from experience with TCP, SCTP and QUIC implements techniques learned from experience with TCP, SCTP and
other transport protocols. QUIC uses UDP as substrate so as to not other transport protocols. QUIC uses UDP as substrate so as to not
require changes to legacy client operating systems and middleboxes to require changes to legacy client operating systems and middleboxes to
skipping to change at page 5, line 31 skipping to change at page 5, line 34
Server: The endpoint accepting incoming QUIC connections. Server: The endpoint accepting incoming QUIC connections.
Endpoint: The client or server end of a connection. Endpoint: The client or server end of a connection.
Stream: A logical, bi-directional channel of ordered bytes within a Stream: A logical, bi-directional channel of ordered bytes within a
QUIC connection. QUIC connection.
Connection: A conversation between two QUIC endpoints with a single Connection: A conversation between two QUIC endpoints with a single
encryption context that multiplexes streams within it. encryption context that multiplexes streams within it.
Connection ID: The identifier for a QUIC connection. Connection ID: The 64-bit unsigned number used as an identifier for
a QUIC connection.
QUIC packet: A well-formed UDP payload that can be parsed by a QUIC QUIC packet: A well-formed UDP payload that can be parsed by a QUIC
receiver. QUIC packet size in this document refers to the UDP receiver. QUIC packet size in this document refers to the UDP
payload size. payload size.
2.1. Notational Conventions 2.1. Notational Conventions
Packet and frame diagrams use the format described in [RFC2360] Packet and frame diagrams use the format described in [RFC2360]
Section 3.1, with the following additional conventions: Section 3.1, with the following additional conventions:
skipping to change at page 8, line 10 skipping to change at page 8, line 10
Generally, QUIC packets are always authenticated and the payload is Generally, QUIC packets are always authenticated and the payload is
typically fully encrypted. The parts of the packet header which are typically fully encrypted. The parts of the packet header which are
not encrypted are still authenticated by the receiver, so as to not encrypted are still authenticated by the receiver, so as to
thwart any packet injection or manipulation by third parties. Some thwart any packet injection or manipulation by third parties. Some
early handshake packets, such as the Version Negotiation packet, are early handshake packets, such as the Version Negotiation packet, are
not encrypted, but information sent in these unencrypted handshake not encrypted, but information sent in these unencrypted handshake
packets is later verified as part of cryptographic processing. packets is later verified as part of cryptographic processing.
3.6. Connection Migration and Resilience to NAT Rebinding 3.6. Connection Migration and Resilience to NAT Rebinding
QUIC connections are identified by a 64-bit Connection ID, randomly QUIC connections are identified by a Connection ID, a 64-bit unsigned
generated by the server. QUIC's consistent connection ID allows number randomly generated by the server. QUIC's consistent
connections to survive changes to the client's IP and port, such as connection ID allows connections to survive changes to the client's
those caused by NAT rebindings or by the client changing network IP and port, such as those caused by NAT rebindings or by the client
connectivity to a new address. QUIC provides automatic cryptographic changing network connectivity to a new address. QUIC provides
verification of a rebound client, since the client continues to use automatic cryptographic verification of a rebound lient, since the
the same session key for encrypting and decrypting packets. The client continues to use the same session key for encrypting and
consistent connection ID can be used to allow migration of the decrypting packets. The consistent connection ID can be used to
connection to a new server IP address as well, since the Connection allow migration of the connection to a new server IP address as well,
ID remains consistent across changes in the client's and the server's since the Connection ID remains consistent across changes in the
network addresses. client's and the server's network addresses.
3.7. Version Negotiation 3.7. Version Negotiation
QUIC version negotiation allows for multiple versions of the protocol QUIC version negotiation allows for multiple versions of the protocol
to be deployed and used concurrently. Version negotiation is to be deployed and used concurrently. Version negotiation is
described in Section 7.1. described in Section 7.1.
4. Versions 4. Versions
QUIC versions are identified using a 32-bit value. QUIC versions are identified using a 32-bit unsigned number.
The version 0x00000000 is reserved to represent an invalid version. The version 0x00000000 is reserved to represent an invalid version.
This version of the specification is identified by the number This version of the specification is identified by the number
0x00000001. 0x00000001.
Version 0x00000001 of QUIC uses TLS as a cryptographic handshake Version 0x00000001 of QUIC uses TLS as a cryptographic handshake
protocol, as described in [QUIC-TLS]. protocol, as described in [QUIC-TLS].
Versions with the most significant 16 bits of the version number Versions with the most significant 16 bits of the version number
cleared are reserved for use in future IETF consensus documents. cleared are reserved for use in future IETF consensus documents.
skipping to change at page 15, line 32 skipping to change at page 15, line 32
fields from the triggering client packet. This allows a client to fields from the triggering client packet. This allows a client to
verify that the server received its packet. verify that the server received its packet.
A Server Stateless Retry packet is never explicitly acknowledged in A Server Stateless Retry packet is never explicitly acknowledged in
an ACK frame by a client. Receiving another Client Initial packet an ACK frame by a client. Receiving another Client Initial packet
implicitly acknowledges a Server Stateless Retry packet. implicitly acknowledges a Server Stateless Retry packet.
After receiving a Server Stateless Retry packet, the client uses a After receiving a Server Stateless Retry packet, the client uses a
new Client Initial packet containing the next cryptographic handshake new Client Initial packet containing the next cryptographic handshake
message. The client retains the state of its cryptographic message. The client retains the state of its cryptographic
handshake, but discards all transport state. In effect, the next handshake, but discards all transport state. The new Client Initial
cryptographic handshake message is sent on a new connection. The new packet includes a newly randomized packet number, STREAM frames on
Client Initial packet is sent in a packet with a newly randomized stream 0 that start again at an offset of 0, and the original
packet number and starting at a stream offset of 0. connection ID.
Continuing the cryptographic handshake is necessary to ensure that an Continuing the cryptographic handshake is necessary to ensure that an
attacker cannot force a downgrade of any cryptographic parameters. attacker cannot force a downgrade of any cryptographic parameters.
In addition to continuing the cryptographic handshake, the client In addition to continuing the cryptographic handshake, the client
MUST remember the results of any version negotiation that occurred MUST remember the results of any version negotiation that occurred
(see Section 7.1). The client MAY also retain any observed RTT or (see Section 7.1). The client MAY also retain any observed RTT or
congestion state that it has accumulated for the flow, but other congestion state that it has accumulated for the flow, but other
transport state MUST be discarded. transport state MUST be discarded.
The payload of the Server Stateless Retry packet contains STREAM The payload of the Server Stateless Retry packet contains STREAM
skipping to change at page 18, line 11 skipping to change at page 18, line 11
The packet number is a 64-bit unsigned number and is used as part of The packet number is a 64-bit unsigned number and is used as part of
a cryptographic nonce for packet encryption. Each endpoint maintains a cryptographic nonce for packet encryption. Each endpoint maintains
a separate packet number for sending and receiving. The packet a separate packet number for sending and receiving. The packet
number for sending MUST increase by at least one after sending any number for sending MUST increase by at least one after sending any
packet, unless otherwise specified (see Section 5.7.1). packet, unless otherwise specified (see Section 5.7.1).
A QUIC endpoint MUST NOT reuse a packet number within the same A QUIC endpoint MUST NOT reuse a packet number within the same
connection (that is, under the same cryptographic keys). If the connection (that is, under the same cryptographic keys). If the
packet number for sending reaches 2^64 - 1, the sender MUST close the packet number for sending reaches 2^64 - 1, the sender MUST close the
connection without sending a CONNECTION_CLOSE frame or any further connection without sending a CONNECTION_CLOSE frame or any further
packets; the sender MAY send a Public Reset packet in response to packets; a server MAY send a Stateless Reset (Section 7.7.5) in
further packets that it receives. response to further packets that it receives.
To reduce the number of bits required to represent the packet number To reduce the number of bits required to represent the packet number
over the wire, only the least significant bits of the packet number over the wire, only the least significant bits of the packet number
are transmitted. The actual packet number for each packet is are transmitted. The actual packet number for each packet is
reconstructed at the receiver based on the largest packet number reconstructed at the receiver based on the largest packet number
received on a successfully authenticated packet. received on a successfully authenticated packet.
A packet number is decoded by finding the packet number value that is A packet number is decoded by finding the packet number value that is
closest to the next expected packet. The next expected packet is the closest to the next expected packet. The next expected packet is the
highest received packet number plus one. For example, if the highest highest received packet number plus one. For example, if the highest
skipping to change at page 21, line 26 skipping to change at page 21, line 26
| 0x05 | MAX_STREAM_DATA | Section 8.5 | | 0x05 | MAX_STREAM_DATA | Section 8.5 |
| | | | | | | |
| 0x06 | MAX_STREAM_ID | Section 8.6 | | 0x06 | MAX_STREAM_ID | Section 8.6 |
| | | | | | | |
| 0x07 | PING | Section 8.7 | | 0x07 | PING | Section 8.7 |
| | | | | | | |
| 0x08 | BLOCKED | Section 8.8 | | 0x08 | BLOCKED | Section 8.8 |
| | | | | | | |
| 0x09 | STREAM_BLOCKED | Section 8.9 | | 0x09 | STREAM_BLOCKED | Section 8.9 |
| | | | | | | |
| 0x0a | STREAM_ID_NEEDED | Section 8.10 | | 0x0a | STREAM_ID_BLOCKED | Section 8.10 |
| | | | | | | |
| 0x0b | NEW_CONNECTION_ID | Section 8.11 | | 0x0b | NEW_CONNECTION_ID | Section 8.11 |
| | | | | | | |
| 0x0c | STOP_SENDING | Section 8.12 | | 0x0c | STOP_SENDING | Section 8.12 |
| | | | | | | |
| 0xa0 - 0xbf | ACK | Section 8.13 | | 0xa0 - 0xbf | ACK | Section 8.13 |
| | | | | | | |
| 0xc0 - 0xff | STREAM | Section 8.14 | | 0xc0 - 0xff | STREAM | Section 8.14 |
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
skipping to change at page 22, line 25 skipping to change at page 22, line 25
protocol being used. protocol being used.
When the server receives a packet from a client with the long header When the server receives a packet from a client with the long header
format, it compares the client's version to the versions it supports. format, it compares the client's version to the versions it supports.
If the version selected by the client is not acceptable to the If the version selected by the client is not acceptable to the
server, the server discards the incoming packet and responds with a server, the server discards the incoming packet and responds with a
Version Negotiation packet (Section 5.3). This includes a list of Version Negotiation packet (Section 5.3). This includes a list of
versions that the server will accept. versions that the server will accept.
To avoid packet amplification attacks a server MUST NOT send a
Version Negotiation packet that is larger than the packet it responds
to. It is anticipated that this is ample space for all QUIC versions
that a single server might need to advertise.
A server sends a Version Negotiation packet for every packet that it A server sends a Version Negotiation packet for every packet that it
receives with an unacceptable version. This allows a server to receives with an unacceptable version. This allows a server to
process packets with unsupported versions without retaining state. process packets with unsupported versions without retaining state.
Though either the initial client packet or the version negotiation Though either the initial client packet or the version negotiation
packet that is sent in response could be lost, the client will send packet that is sent in response could be lost, the client will send
new packets until it successfully receives a response. new packets until it successfully receives a response.
If the packet contains a version that is acceptable to the server, If the packet contains a version that is acceptable to the server,
the server proceeds with the handshake (Section 7.2). This commits the server proceeds with the handshake (Section 7.2). This commits
the server to the version that the client selected. the server to the version that the client selected.
skipping to change at page 25, line 34 skipping to change at page 25, line 42
opaque value<0..2^16-1>; opaque value<0..2^16-1>;
} TransportParameter; } TransportParameter;
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: case client_hello:
QuicVersion negotiated_version; QuicVersion negotiated_version;
QuicVersion initial_version; QuicVersion initial_version;
case encrypted_extensions: case encrypted_extensions:
QuicVersion supported_versions<2..2^8-4>; QuicVersion supported_versions<4..2^8-4>;
case new_session_ticket: case new_session_ticket:
struct {}; struct {};
}; };
TransportParameter parameters<30..2^16-1>; TransportParameter parameters<30..2^16-1>;
} TransportParameters; } TransportParameters;
Figure 6: Definition of TransportParameters Figure 6: Definition of TransportParameters
The "extension_data" field of the quic_transport_parameters extension The "extension_data" field of the quic_transport_parameters extension
skipping to change at page 26, line 40 skipping to change at page 26, line 50
initial_max_stream_id (0x0002): The initial maximum stream ID initial_max_stream_id (0x0002): The initial maximum stream ID
parameter contains the initial maximum stream number the peer may parameter contains the initial maximum stream number the peer may
initiate, encoded as an unsigned 32-bit integer. This is initiate, encoded as an unsigned 32-bit integer. This is
equivalent to sending a MAX_STREAM_ID (Section 8.6) immediately equivalent to sending a MAX_STREAM_ID (Section 8.6) immediately
after completing the handshake. after completing the handshake.
idle_timeout (0x0003): The idle timeout is a value in seconds that idle_timeout (0x0003): The idle timeout is a value in seconds that
is encoded as an unsigned 16-bit integer. The maximum value is is encoded as an unsigned 16-bit integer. The maximum value is
600 seconds (10 minutes). 600 seconds (10 minutes).
stateless_reset_token (0x0005): The Stateless Reset Token is used in A server MUST include the following transport parameters:
verifying a stateless reset, see Section 7.8. This parameter is a
sequence of 16 octets. stateless_reset_token (0x0006): The Stateless Reset Token is used in
verifying a stateless reset, see Section 7.7.5. This parameter is
a sequence of 16 octets.
A client MUST NOT include a stateless reset token. A server MUST
treat receipt of a stateless_reset_token transport parameter as a
connection error of type TRANSPORT_PARAMETER_ERROR.
An endpoint MAY use the following transport parameters: An endpoint MAY use the following transport parameters:
omit_connection_id (0x0004): The omit connection identifier omit_connection_id (0x0004): The omit connection identifier
parameter indicates that packets sent to the endpoint that parameter indicates that packets sent to the endpoint that
advertises this parameter can omit the connection ID. This can be advertises this parameter can omit the connection ID. This can be
used by an endpoint where it knows that source and destination IP used by an endpoint where it knows that source and destination IP
address and port are sufficient for it to identify a connection. address and port are sufficient for it to identify a connection.
This parameter is zero length. Absence this parameter indicates This parameter is zero length. Absence this parameter indicates
that the endpoint relies on the connection ID being present in that the endpoint relies on the connection ID being present in
skipping to change at page 34, line 9 skipping to change at page 34, line 17
as described in [QUIC-TLS] Section 5.6. as described in [QUIC-TLS] Section 5.6.
7.6.2. Address Validation for Migrated Connections 7.6.2. Address Validation for Migrated Connections
TODO: see issue #161 TODO: see issue #161
7.7. Connection Termination 7.7. Connection Termination
Connections should remain open until they become idle for a pre- Connections should remain open until they become idle for a pre-
negotiated period of time. A QUIC connection, once established, can negotiated period of time. A QUIC connection, once established, can
be terminated in one of three ways: be terminated in one of four ways:
1. Explicit Shutdown: An endpoint sends a CONNECTION_CLOSE frame to o application close (Section 7.7.2)
terminate the connection. An endpoint MAY use application-layer
mechanisms prior to a CONNECTION_CLOSE to indicate that the
connection will soon be terminated. On termination of the active
streams, a CONNECTION_CLOSE may be sent. If an endpoint sends a
CONNECTION_CLOSE frame while unterminated streams are active (no
FIN bit or RST_STREAM frames have been sent or received for one
or more streams), then the peer must assume that the streams were
incomplete and were abnormally terminated.
2. Implicit Shutdown: The default idle timeout is a required o idle timeout (Section 7.7.3)
parameter in connection negotiation. The maximum is 10 minutes.
If there is no network activity for the duration of the idle
timeout, the connection is closed. By default a CONNECTION_CLOSE
frame will be sent. A silent close option can be enabled when it
is expensive to send an explicit close, such as mobile networks
that must wake up the radio.
3. Stateless Reset: An endpoint that loses state can use this o immediate close (Section 7.7.4)
procedure to cause the connection to terminate early, see
Section 7.8 for details.
After receiving either a CONNECTION_CLOSE frame or a Public Reset, an o stateless reset (Section 7.7.5)
endpoint MUST NOT send additional packets on that connection. After
sending either a CONNECTION_CLOSE frame or a Public Reset packet,
implementations MUST NOT send any non-closing packets on that
connection. If additional packets are received after this time and
before idle_timeout seconds has passed, implementations SHOULD
respond to them by sending a CONNECTION_CLOSE (which MAY just be a
duplicate of the previous CONNECTION_CLOSE packet) but MAY also send
a Public Reset packet. Implementations SHOULD throttle these
responses, for instance by exponentially backing off the number of
packets which are received before sending a response. After this
time, implementations SHOULD respond to unexpected packets with a
Public Reset packet.
7.8. Stateless Reset 7.7.1. Draining Period
After a connection is closed for any reason, an endpoint might
receive packets from its peer. These packets might have been sent
prior to receiving any close signal, or they might be retransmissions
of packets for which acknowledgments were lost.
The draining period persists for three times the current
Retransmission Timeout (RTO) interval as defined in [QUIC-RECOVERY].
During this period, new packets can be acknowledged, but no new
application data can be sent on the connection.
Different treatment is given to packets that are received while a
connection is in the draining period depending on how the connection
was closed. In all cases, it is possible to acknowledge packets that
are received as normal, but other reactions might be preferable
depending on how the connection was closed. An endpoint that is in a
draining period MUST NOT send packets containing frames other than
ACK, PADDING, or CONNECTION_CLOSE.
Once the draining period has ended, an endpoint SHOULD discard per-
connection state. This results in new packets on the connection
being discarded. An endpoint MAY send a stateless reset in response
to any further incoming packets.
The draining period does not apply when a stateless reset
(Section 7.7.5) is used.
7.7.2. Application Close
An application protocol can arrange to close a connection. This
might be after negotiating a graceful shutdown. The application
protocol exchanges whatever messages that are needed to cause both
endpoints to agree to close the connection, after which the
application requests that the connection be closed. A negotiated
shutdown might not result in exchanging messages that are visible to
the transport.
In the draining period, an endpoint that has been closed by an
application SHOULD generate and send ACK frames as normal. This
allows the peer to receive acknowledgements where previous
acknowledgements were lost.
7.7.3. Idle Timeout
A connection that remains idle for longer than the idle timeout (see
Section 7.3.1) becomes closed. Either peer removes connection state
if they have neither sent nor received a packet for this time.
The time at which an idle timeout takes effect won't be perfectly
synchronized on peers. A connection enters the draining period when
the idle timeout expires. During this time, an endpoint that
receives new packets MAY choose to restore the connection.
Alternatively, an endpoint that receives packets MAY signal the
timeout using an immediate close.
7.7.4. Immediate Close
An endpoint sends a CONNECTION_CLOSE frame to terminate the
connection immediately. A CONNECTION_CLOSE causes all open streams
to immediately become closed; open streams can be assumed to be
implicitly reset. After sending or receiving a CONNECTION_CLOSE
frame, endpoints immediately enter a draining period.
During the draining period, an endpoint that sends a CONNECTION_CLOSE
frame SHOULD respond to any subsequent packet that it receives with
another packet containing a CONNECTION_CLOSE frame. To reduce the
state that an endpoint maintains in this case, it MAY send the exact
same packet. However, endpoints SHOULD limit the number of
CONNECTION_CLOSE messages they generate. For instance, an endpoint
could progressively increase the number of packets that it receives
before sending additional CONNECTION_CLOSE frames.
Note: Allowing retransmission of a packet contradicts other advice
in this document that recommends the creation of new packet
numbers for every packet. Sending new packet numbers is primarily
of advantage to loss recovery and congestion control, which are
not expected to be relevant for a closed connection.
Retransmitting the final packet requires less state.
An endpoint can cease sending CONNECTION_CLOSE frames if it receives
either a CONNECTION_CLOSE or an acknowledgement for a packet that
contained a CONNECTION_CLOSE.
7.7.5. Stateless Reset
A stateless reset is provided as an option of last resort for a A stateless reset is provided as an option of last resort for a
server that does not have access to the state of a connection. A server that does not have access to the state of a connection. A
server crash or outage might result in clients continuing to send server crash or outage might result in clients continuing to send
data to a server that is unable to properly continue the connection. data to a server that is unable to properly continue the connection.
A server that wishes to communicate a fatal connection error MUST use A server that wishes to communicate a fatal connection error MUST use
a CONNECTION_CLOSE frame if it has sufficient state to do so. a CONNECTION_CLOSE frame if it has sufficient state to do so.
To support this process, the server sends a stateless_reset_token To support this process, the server sends a stateless_reset_token
value during the handshake in the transport parameters. This value value during the handshake in the transport parameters. This value
is protected by encryption, so only client and server know this is protected by encryption, so only client and server know this
value. value.
A server that receives packets that it cannot process sends a packet A server that receives packets that it cannot process sends a packet
in the following layout: in the following layout:
skipping to change at page 35, line 35 skipping to change at page 37, line 4
| | | |
+ + + +
| | | |
+ Stateless Reset Token (128) + + Stateless Reset Token (128) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octets (*) ... | Random Octets (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This packet SHOULD use the short header form with the shortest This packet SHOULD use the short header form with the shortest
possible packet number encoding. This minimizes the perceived gap possible packet number encoding. This minimizes the perceived gap
between the last packet that the server sent and this packet. The between the last packet that the server sent and this packet. The
leading octet of the Stateless Reset Token will be interpreted as a leading octet of the Stateless Reset Token will be interpreted as a
packet number. A server MAY use a different short header type, packet number. A server MAY use a different short header type,
indicating a different packet number length, but this allows for the indicating a different packet number length, but this allows for the
message to be identified as a stateless reset more easily using message to be identified as a stateless reset more easily using
heuristics. heuristics.
A server copies the connection ID field from the packet that triggers A server copies the connection ID field from the packet that triggers
the stateless reset. A server omits the connection ID if explicitly the stateless reset. A server omits the connection ID if explicitly
configured to do so, or if the client packet did not include a configured to do so, or if the client packet did not include a
connection ID. connection ID.
After the first short header octet and optional connection ID, the After the first short header octet and optional connection ID, the
server includes the value of the Stateless Reset Token that it server includes the value of the Stateless Reset Token that it
included in its transport parameters. included in its transport parameters.
After the Stateless Reset Token, the endpoint pads the message with After the Stateless Reset Token, the server pads the message with an
an arbitrary number of octets containing random values. arbitrary number of octets containing random values.
This design ensures that a stateless reset packet is - to the extent This design ensures that a stateless reset packet is - to the extent
possible - indistinguishable from a regular packet. possible - indistinguishable from a regular packet.
A stateless reset is not appropriate for signaling error conditions. A stateless reset is not appropriate for signaling error conditions.
An endpoint that wishes to communicate a fatal connection error MUST An endpoint that wishes to communicate a fatal connection error MUST
use a CONNECTION_CLOSE frame if it has sufficient state to do so. use a CONNECTION_CLOSE frame if it has sufficient state to do so.
7.8.1. Detecting a Stateless Reset 7.7.5.1. Detecting a Stateless Reset
A client detects a potential stateless reset when a packet with a A client detects a potential stateless reset when a packet with a
short header cannot be decrypted. The client then performs a short header cannot be decrypted. The client then performs a
constant-time comparison of the 16 octets that follow the Connection constant-time comparison of the 16 octets that follow the Connection
ID with the Stateless Reset Token provided by the server in its ID with the Stateless Reset Token provided by the server in its
transport parameters. If this comparison is successful, the transport parameters. If this comparison is successful, the
connection MUST be terminated immediately. Otherwise, the packet can connection MUST be terminated immediately. Otherwise, the packet can
be discarded. be discarded.
7.8.2. Calculating a Stateless Reset Token 7.7.5.2. Calculating a Stateless Reset Token
The stateless reset token MUST be difficult to guess. In order to The stateless reset token MUST be difficult to guess. In order to
create a Stateless Reset Token, a server could randomly generate create a Stateless Reset Token, a server could randomly generate
[RFC4086] a secret for every connection that it creates. However, [RFC4086] a secret for every connection that it creates. However,
this presents a coordination problem when there are multiple servers this presents a coordination problem when there are multiple servers
in a cluster or a storage problem for a server that might lose state. in a cluster or a storage problem for a server that might lose state.
Stateless reset specifically exists to handle the case where state is Stateless reset specifically exists to handle the case where state is
lost, so this approach is suboptimal. lost, so this approach is suboptimal.
A single static key can be used across all connections to the same A single static key can be used across all connections to the same
skipping to change at page 37, line 38 skipping to change at page 39, line 10
provide protection against traffic analysis for protected packets. provide protection against traffic analysis for protected packets.
A PADDING frame has no content. That is, a PADDING frame consists of A PADDING frame has no content. That is, a PADDING frame consists of
the single octet that identifies the frame as a PADDING frame. the single octet that identifies the frame as a PADDING frame.
8.2. RST_STREAM Frame 8.2. RST_STREAM Frame
An endpoint may use a RST_STREAM frame (type=0x01) to abruptly An endpoint may use a RST_STREAM frame (type=0x01) to abruptly
terminate a stream. terminate a stream.
After sending a RST_STREAM, an endpoint ceases transmission of STREAM After sending a RST_STREAM, an endpoint ceases transmission and
frames on the identified stream. A receiver of RST_STREAM can retransmission of STREAM frames on the identified stream. A receiver
discard any data that it already received on that stream. An of RST_STREAM can discard any data that it already received on that
endpoint sends a RST_STREAM in response to a RST_STREAM unless the stream.
stream is already closed.
The RST_STREAM frame is as follows: The RST_STREAM frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (32) | | Stream ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (32) | | Error Code (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 25 skipping to change at page 42, line 40
terminate a connection with a STREAM_ID_ERROR error if a peer terminate a connection with a STREAM_ID_ERROR error if a peer
initiates a stream with a higher stream ID than it has sent, unless initiates a stream with a higher stream ID than it has sent, unless
this is a result of a change in the initial limits (see this is a result of a change in the initial limits (see
Section 7.3.2). Section 7.3.2).
8.7. PING frame 8.7. PING frame
Endpoints can use PING frames (type=0x07) to verify that their peers Endpoints can use PING frames (type=0x07) to verify that their peers
are still alive or to check reachability to the peer. The PING frame are still alive or to check reachability to the peer. The PING frame
contains no additional fields. The receiver of a PING frame simply contains no additional fields. The receiver of a PING frame simply
needs to acknowledge the packet containing this frame. The PING needs to acknowledge the packet containing this frame.
frame SHOULD be used to keep a connection alive when a stream is
open. The default is to send a PING frame after 15 seconds of A PING frame has no additional fields.
quiescence. A PING frame has no additional fields.
The PING frame can be used to keep a connection alive when an
application or application protocol wishes to prevent the connection
from timing out. An application protocol SHOULD provide guidance
about the conditions under which generating a PING is recommended.
This guidance SHOULD indicate whether it is the client or the server
that is expected to send the PING. Having both endpoints send PING
frames without coordination can produce an excessive number of
packets and poor performance.
A connection will time out if no packets are sent or received for a
period longer than the time specified in the idle_timeout transport
parameter (see Section 7.7). However, state in middleboxes might
time out earlier than that. Though REQ-5 in [RFC4787] recommends a 2
minute timeout interval, experience shows that sending packets every
15 to 30 seconds is necessary to prevent the majority of middleboxes
from losing state for UDP flows.
8.8. BLOCKED Frame 8.8. BLOCKED Frame
A sender sends a BLOCKED frame (type=0x08) when it wishes to send A sender sends a BLOCKED frame (type=0x08) when it wishes to send
data, but is unable to due to connection-level flow control (see data, but is unable to due to connection-level flow control (see
Section 11.2.1). BLOCKED frames can be used as input to tuning of Section 11.2.1). BLOCKED frames can be used as input to tuning of
flow control algorithms (see Section 11.1.2). flow control algorithms (see Section 11.1.2).
The BLOCKED frame does not contain a payload. The BLOCKED frame does not contain a payload.
skipping to change at page 42, line 4 skipping to change at page 43, line 35
send data, but is unable to due to stream-level flow control. This send data, but is unable to due to stream-level flow control. This
frame is analogous to BLOCKED (Section 8.8). frame is analogous to BLOCKED (Section 8.8).
The STREAM_BLOCKED frame is as follows: The STREAM_BLOCKED frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (32) | | Stream ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The STREAM_BLOCKED frame contains a single field: The STREAM_BLOCKED frame contains a single field:
Stream ID: A 32-bit unsigned number indicating the stream which is Stream ID: A 32-bit unsigned number indicating the stream which is
flow control blocked. flow control blocked.
An endpoint MAY send a STREAM_BLOCKED frame for a stream that exceeds 8.10. STREAM_ID_BLOCKED Frame
the maximum stream ID set by its peer (see Section 8.6). This does
not open the stream, but informs the peer that a new stream was
needed, but the stream limit prevented the creation of the stream.
8.10. STREAM_ID_NEEDED Frame
A sender sends a STREAM_ID_NEEDED frame (type=0x0a) when it wishes to A sender MAY send a STREAM_ID_BLOCKED frame (type=0x0a) when it
open a stream, but is unable to due to the maximum stream ID limit. wishes to open a stream, but is unable to due to the maximum stream
ID limit set by its peer (see Section 8.6). This does not open the
stream, but informs the peer that a new stream was needed, but the
stream limit prevented the creation of the stream.
The STREAM_ID_NEEDED frame does not contain a payload. The STREAM_ID_BLOCKED frame does not contain a payload.
8.11. NEW_CONNECTION_ID Frame 8.11. NEW_CONNECTION_ID Frame
A server sends a NEW_CONNECTION_ID frame (type=0x0b) to provide the A server sends a NEW_CONNECTION_ID frame (type=0x0b) to provide the
client with alternative connection IDs that can be used to break client with alternative connection IDs that can be used to break
linkability when migrating connections (see Section 7.6.1). linkability when migrating connections (see Section 7.6.1).
The NEW_CONNECTION_ID is as follows: The NEW_CONNECTION_ID is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 43, line 13 skipping to change at page 44, line 45
server. The sequence value can wrap; the value 65535 is followed server. The sequence value can wrap; the value 65535 is followed
by 0. When wrapping the sequence field, the server MUST ensure by 0. When wrapping the sequence field, the server MUST ensure
that a value with the same sequence has been received and that a value with the same sequence has been received and
acknowledged by the client. The connection ID that is assigned acknowledged by the client. The connection ID that is assigned
during the handshake is assumed to have a sequence of 65535. during the handshake is assumed to have a sequence of 65535.
Connection ID: A 64-bit connection ID. Connection ID: A 64-bit connection ID.
Stateless Reset Token: A 128-bit value that will be used to for a Stateless Reset Token: A 128-bit value that will be used to for a
stateless reset when the associated connection ID is used (see stateless reset when the associated connection ID is used (see
Section 7.8). Section 7.7.5).
8.12. STOP_SENDING Frame 8.12. STOP_SENDING Frame
An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate
that incoming data is being discarded on receipt at application that incoming data is being discarded on receipt at application
request. This signals a peer to abruptly terminate transmission on a request. This signals a peer to abruptly terminate transmission on a
stream. The frame is as follows: stream. The frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 53, line 11 skipping to change at page 55, line 11
A packet MUST NOT be acknowledged until packet protection has been A packet MUST NOT be acknowledged until packet protection has been
successfully removed and all frames contained in the packet have been successfully removed and all frames contained in the packet have been
processed. For STREAM frames, this means the data has been queued processed. For STREAM frames, this means the data has been queued
(but not necessarily delivered to the application). This also means (but not necessarily delivered to the application). This also means
that any stream state transitions triggered by STREAM or RST_STREAM that any stream state transitions triggered by STREAM or RST_STREAM
frames have occurred. Once the packet has been fully processed, a frames have occurred. Once the packet has been fully processed, a
receiver acknowledges receipt by sending one or more ACK frames receiver acknowledges receipt by sending one or more ACK frames
containing the packet number of the received packet. containing the packet number of the received packet.
To avoid creating an indefinite feedback loop, an endpoint MUST NOT To avoid creating an indefinite feedback loop, an endpoint MUST NOT
generate an ACK frame in response to a packet containing only ACK or send an ACK frame in response to a packet containing only ACK or
PADDING frames. PADDING frames, even if there are packet gaps which precede the
received packet. The endpoint MUST acknowledge packets containing
only ACK or PADDING frames in the next ACK frame that it sends.
Strategies and implications of the frequency of generating Strategies and implications of the frequency of generating
acknowledgments are discussed in more detail in [QUIC-RECOVERY]. acknowledgments are discussed in more detail in [QUIC-RECOVERY].
9.1. Special Considerations for PMTU Discovery 9.1. Special Considerations for PMTU Discovery
Traditional ICMP-based path MTU discovery in IPv4 [RFC1191] is Traditional ICMP-based path MTU discovery in IPv4 [RFC1191] is
potentially vulnerable to off-path attacks that successfully guess potentially vulnerable to off-path attacks that successfully guess
the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient
value. TCP connections mitigate this risk by using the (at minimum) value. TCP connections mitigate this risk by using the (at minimum)
skipping to change at page 61, line 38 skipping to change at page 63, line 38
QUIC employs a credit-based flow-control scheme similar to HTTP/2's QUIC employs a credit-based flow-control scheme similar to HTTP/2's
flow control [RFC7540]. A receiver advertises the number of octets flow control [RFC7540]. A receiver advertises the number of octets
it is prepared to receive on a given stream and for the entire it is prepared to receive on a given stream and for the entire
connection. This leads to two levels of flow control in QUIC: (i) connection. This leads to two levels of flow control in QUIC: (i)
Connection flow control, which prevents senders from exceeding a Connection flow control, which prevents senders from exceeding a
receiver's buffer capacity for the connection, and (ii) Stream flow receiver's buffer capacity for the connection, and (ii) Stream flow
control, which prevents a single stream from consuming the entire control, which prevents a single stream from consuming the entire
receive buffer for a connection. receive buffer for a connection.
A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to A data receiver sends MAX_STREAM_DATA or MAX_DATA frames to the
advertise additional credit by sending the absolute byte offset in sender to advertise additional credit. MAX_STREAM_DATA frames send
the connection or stream which it is willing to receive. the the maximum absolute byte offset of a stream, while MAX_DATA
sends the maximum sum of the absolute byte offsets of all streams
other than stream 0.
A receiver MAY advertise a larger offset at any point by sending A receiver MAY advertise a larger offset at any point by sending
MAX_DATA or MAX_STREAM_DATA frames. A receiver MUST NOT renege on an MAX_DATA or MAX_STREAM_DATA frames. A receiver MUST NOT renege on an
advertisement; that is, once a receiver advertises an offset, it MUST advertisement; that is, once a receiver advertises an offset, it MUST
NOT subsequently advertise a smaller offset. A sender could receive NOT subsequently advertise a smaller offset. A sender could receive
MAX_DATA or MAX_STREAM_DATA frames out of order; a sender MUST MAX_DATA or MAX_STREAM_DATA frames out of order; a sender MUST
therefore ignore any flow control offset that does not move the therefore ignore any flow control offset that does not move the
window forward. window forward.
A receiver MUST close the connection with a FLOW_CONTROL_ERROR error A receiver MUST close the connection with a FLOW_CONTROL_ERROR error
skipping to change at page 65, line 18 skipping to change at page 67, line 18
An endpoint that detects an error SHOULD signal the existence of that An endpoint that detects an error SHOULD signal the existence of that
error to its peer. Errors can affect an entire connection (see error to its peer. Errors can affect an entire connection (see
Section 12.1), or a single stream (see Section 12.2). Section 12.1), or a single stream (see Section 12.2).
The most appropriate error code (Section 12.3) SHOULD be included in The most appropriate error code (Section 12.3) SHOULD be included in
the frame that signals the error. Where this specification the frame that signals the error. Where this specification
identifies error conditions, it also identifies the error code that identifies error conditions, it also identifies the error code that
is used. is used.
A stateless reset (Section 7.8) is not suitable for any error that A stateless reset (Section 7.7.5) is not suitable for any error that
can be signaled with a CONNECTION_CLOSE or RST_STREAM frame. A can be signaled with a CONNECTION_CLOSE or RST_STREAM frame. A
stateless reset MUST NOT be used by an endpoint that has the state stateless reset MUST NOT be used by an endpoint that has the state
necessary to send a frame on the connection. necessary to send a frame on the connection.
12.1. Connection Errors 12.1. Connection Errors
Errors that result in the connection being unusable, such as an Errors that result in the connection being unusable, such as an
obvious violation of protocol semantics or corruption of state that obvious violation of protocol semantics or corruption of state that
affects an entire connection, MUST be signaled using a affects an entire connection, MUST be signaled using a
CONNECTION_CLOSE frame (Section 8.3). An endpoint MAY close the CONNECTION_CLOSE frame (Section 8.3). An endpoint MAY close the
skipping to change at page 65, line 43 skipping to change at page 67, line 43
endpoint SHOULD be prepared to retransmit a packet containing a endpoint SHOULD be prepared to retransmit a packet containing a
CONNECTION_CLOSE frame if it receives more packets on a terminated CONNECTION_CLOSE frame if it receives more packets on a terminated
connection. Limiting the number of retransmissions and the time over connection. Limiting the number of retransmissions and the time over
which this final packet is sent limits the effort expended on which this final packet is sent limits the effort expended on
terminated connections. terminated connections.
An endpoint that chooses not to retransmit packets containing An endpoint that chooses not to retransmit packets containing
CONNECTION_CLOSE risks a peer missing the first such packet. The CONNECTION_CLOSE risks a peer missing the first such packet. The
only mechanism available to an endpoint that continues to receive only mechanism available to an endpoint that continues to receive
data for a terminated connection is to use the stateless reset data for a terminated connection is to use the stateless reset
process (Section 7.8). process (Section 7.7.5).
An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT
signal the existence of the error to its peer. signal the existence of the error to its peer.
12.2. Stream Errors 12.2. Stream Errors
If the error affects a single stream, but otherwise leaves the If the error affects a single stream, but otherwise leaves the
connection in a recoverable state, the endpoint can send a RST_STREAM connection in a recoverable state, the endpoint can send a RST_STREAM
frame (Section 8.2) with an appropriate error code to terminate just frame (Section 8.2) with an appropriate error code to terminate just
the affected stream. the affected stream.
skipping to change at page 71, line 37 skipping to change at page 73, line 37
15.1. Normative References 15.1. Normative References
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-21 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
July 2017. July 2017.
[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 (work in and Congestion Control", draft-ietf-quic-recovery (work in
progress), August 2017. progress), September 2017.
[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-tls Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls
(work in progress), August 2017. (work in progress), September 2017.
[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-
<http://www.rfc-editor.org/info/rfc1191>. editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 1996, <https://www.rfc-editor.org/info/rfc1981>.
[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-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4086>. editor.org/info/rfc4086>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5226>. editor.org/info/rfc5226>.
15.2. Informative References 15.2. Informative References
[EARLY-DESIGN] [EARLY-DESIGN]
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2104>. editor.org/info/rfc2104>.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22,
RFC 2360, DOI 10.17487/RFC2360, June 1998, RFC 2360, DOI 10.17487/RFC2360, June 1998,
<http://www.rfc-editor.org/info/rfc2360>. <https://www.rfc-editor.org/info/rfc2360>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5869>. editor.org/info/rfc5869>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>. <https://www.rfc-editor.org/info/rfc6824>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] 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-
<http://www.rfc-editor.org/info/rfc7540>. editor.org/info/rfc7540>.
[SLOWLORIS] [SLOWLORIS]
RSnake Hansen, R., "Welcome to Slowloris...", June 2009, RSnake Hansen, R., "Welcome to Slowloris...", June 2009,
<https://web.archive.org/web/20150315054838/ <https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>. http://ha.ckers.org/slowloris/>.
[SST] Ford, B., "Structured streams", ACM SIGCOMM Computer [SST] Ford, B., "Structured streams", ACM SIGCOMM Computer
Communication Review Vol. 37, pp. 361, Communication Review Vol. 37, pp. 361,
DOI 10.1145/1282427.1282421, October 2007. DOI 10.1145/1282427.1282421, October 2007.
skipping to change at page 74, line 12 skipping to change at page 76, line 16
discussions and public ones on the quic@ietf.org and proto- discussions and public ones on the quic@ietf.org and proto-
quic@chromium.org mailing lists. Our thanks to all. quic@chromium.org mailing lists. Our thanks to all.
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-04 C.1. Since draft-ietf-quic-transport-05
o Stateless token is server-only (#726)
o Refactor section on connection termination (#733, #748, #328,
#177)
o Limit size of Version Negotiation packet (#585)
o Clarify when and what to ack (#736)
o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
o Clarify Keep-alive requirements (#729)
C.2. Since draft-ietf-quic-transport-04
o Introduce STOP_SENDING frame, RST_STREAM only resets in one o Introduce STOP_SENDING frame, RST_STREAM only resets in one
direction (#165) direction (#165)
o Removed GOAWAY; application protocols are responsible for graceful o Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
o Reduced the number of error codes (#96, #177, #184, #211) o Reduced the number of error codes (#96, #177, #184, #211)
o Version validation fields can't move or change (#121) o Version validation fields can't move or change (#121)
skipping to change at page 74, line 33 skipping to change at page 77, line 4
o Removed versions from the transport parameters in a o Removed versions from the transport parameters in a
NewSessionTicket message (#547) NewSessionTicket message (#547)
o Clarify the meaning of "bytes in flight" (#550) o Clarify the meaning of "bytes in flight" (#550)
o Public reset is now stateless reset and not visible to the path o Public reset is now stateless reset and not visible to the path
(#215) (#215)
o Reordered bits and fields in STREAM frame (#620) o Reordered bits and fields in STREAM frame (#620)
o Clarifications to the stream state machine (#572, #571) o Clarifications to the stream state machine (#572, #571)
o Increased the maximum length of the Largest Acknowledged field in o Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
o truncate_connection_id is renamed to omit_connection_id (#659) o truncate_connection_id is renamed to omit_connection_id (#659)
o CONNECTION_CLOSE terminates the connection like TCP RST (#330, o CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
C.2. Since draft-ietf-quic-transport-03 C.3. Since draft-ietf-quic-transport-03
o Change STREAM and RST_STREAM layout o Change STREAM and RST_STREAM layout
o Add MAX_STREAM_ID settings o Add MAX_STREAM_ID settings
C.3. Since draft-ietf-quic-transport-02 C.4. Since draft-ietf-quic-transport-02
o The size of the initial packet payload has a fixed minimum (#267, o The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
o Define when Version Negotiation packets are ignored (#284, #294, o Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
o The 64-bit FNV-1a algorithm is used for integrity protection of o The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517) unprotected packets (#167, #480, #481, #517)
skipping to change at page 75, line 35 skipping to change at page 78, line 4
o Version 1 of QUIC uses TLS; a new version is needed to use a o Version 1 of QUIC uses TLS; a new version is needed to use a
different handshake protocol (#516) different handshake protocol (#516)
o STREAM frames have a reduced number of offset lengths (#543, #430) o STREAM frames have a reduced number of offset lengths (#543, #430)
o Split some frames into separate connection- and stream- level o Split some frames into separate connection- and stream- level
frames (#443) frames (#443)
* WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450)
* BLOCKED split to match WINDOW_UPDATE split (#454) * BLOCKED split to match WINDOW_UPDATE split (#454)
* Define STREAM_ID_NEEDED frame (#455) * Define STREAM_ID_NEEDED frame (#455)
o A NEW_CONNECTION_ID frame supports connection migration without o A NEW_CONNECTION_ID frame supports connection migration without
linkability (#232, #491, #496) linkability (#232, #491, #496)
o Transport parameters for 0-RTT are retained from a previous o Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512) connection (#405, #513, #512)
* A client in 0-RTT no longer required to reset excess streams * A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
o Expanded security considerations (#440, #444, #445, #448) o Expanded security considerations (#440, #444, #445, #448)
C.4. Since draft-ietf-quic-transport-01 C.5. Since draft-ietf-quic-transport-01
o Defined short and long packet headers (#40, #148, #361) o Defined short and long packet headers (#40, #148, #361)
o Defined a versioning scheme and stable fields (#51, #361) o Defined a versioning scheme and stable fields (#51, #361)
o Define reserved version values for "greasing" negotiation (#112, o Define reserved version values for "greasing" negotiation (#112,
#278) #278)
o The initial packet number is randomized (#35, #283) o The initial packet number is randomized (#35, #283)
skipping to change at page 78, line 5 skipping to change at page 80, line 17
o Remove error code and reason phrase from GOAWAY (#352, #355) o Remove error code and reason phrase from GOAWAY (#352, #355)
o GOAWAY includes a final stream number for both directions (#347) o GOAWAY includes a final stream number for both directions (#347)
o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
o Defined priority as the responsibility of the application protocol o Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
C.5. Since draft-ietf-quic-transport-00 C.6. Since draft-ietf-quic-transport-00
o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
o Defined versioning o Defined versioning
o Reworked description of packet and frame layout o Reworked description of packet and frame layout
o Error code space is divided into regions for each component o Error code space is divided into regions for each component
o Use big endian for all numeric values o Use big endian for all numeric values
C.6. Since draft-hamilton-quic-transport-protocol-01 C.7. Since draft-hamilton-quic-transport-protocol-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added IANA Considerations section o Added IANA Considerations section
o Moved Contributors and Acknowledgments to appendices o Moved Contributors and Acknowledgments to appendices
Authors' Addresses Authors' Addresses
 End of changes. 65 change blocks. 
200 lines changed or deleted 305 lines changed or added

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