draft-ietf-quic-invariants-03.txt   draft-ietf-quic-invariants-04.txt 
QUIC M. Thomson QUIC M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track October 03, 2018 Intended status: Standards Track April 12, 2019
Expires: April 6, 2019 Expires: October 14, 2019
Version-Independent Properties of QUIC Version-Independent Properties of QUIC
draft-ietf-quic-invariants-03 draft-ietf-quic-invariants-04
Abstract Abstract
This document defines the properties of the QUIC transport protocol This document defines the properties of the QUIC transport protocol
that are expected to remain unchanged over time as new versions of that are expected to remain unchanged over time as new versions of
the protocol are developed. the protocol are developed.
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 42 skipping to change at page 1, line 42
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 April 6, 2019. This Internet-Draft will expire on October 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 34 skipping to change at page 3, line 34
packets. QUIC endpoints use QUIC packets to establish a QUIC packets. QUIC endpoints use QUIC packets to establish a QUIC
connection, which is shared protocol state between those endpoints. connection, which is shared protocol state between those endpoints.
4. QUIC Packet Headers 4. QUIC Packet Headers
A QUIC packet is the content of the UDP datagrams exchanged by QUIC A QUIC packet is the content of the UDP datagrams exchanged by QUIC
endpoints. This document describes the contents of those datagrams. endpoints. This document describes the contents of those datagrams.
QUIC defines two types of packet header: long and short. Packets QUIC defines two types of packet header: long and short. Packets
with long headers are identified by the most significant bit of the with long headers are identified by the most significant bit of the
first octet being set; packets with a short header have that bit first byte being set; packets with a short header have that bit
cleared. cleared.
Aside from the values described here, the payload of QUIC packets is Aside from the values described here, the payload of QUIC packets is
version-specific and of arbitrary length. version-specific and of arbitrary length.
4.1. Long Header 4.1. Long Header
Long headers take the form described in Figure 1. Bits that have Long headers take the form described in Figure 1. Bits that have
version-specific semantics are marked with an X. version-specific semantics are marked with an X.
skipping to change at page 4, line 23 skipping to change at page 4, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ... | Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ... | Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ... |X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: QUIC Long Header Figure 1: QUIC Long Header
A QUIC packet with a long header has the high bit of the first octet A QUIC packet with a long header has the high bit of the first byte
set to 1. All other bits in that octet are version specific. set to 1. All other bits in that byte are version specific.
The next four octets include a 32-bit Version field (see The next four bytes include a 32-bit Version field (see Section 4.4).
Section 4.4).
The next octet contains the length in octets of the two Connection The next byte contains the length in bytes of the two Connection IDs
IDs (see Section 4.3) that follow. Each length is encoded as a 4-bit (see Section 4.3) that follow. Each length is encoded as a 4-bit
unsigned integer. The length of the Destination Connection ID (DCIL) unsigned integer. The length of the Destination Connection ID (DCIL)
occupies the high bits of the octet and the length of the Source occupies the high bits of the byte and the length of the Source
Connection ID (SCIL) occupies the low bits of the octet. An encoded Connection ID (SCIL) occupies the low bits of the byte. An encoded
length of 0 indicates that the connection ID is also 0 octets in length of 0 indicates that the connection ID is also 0 bytes in
length. Non-zero encoded lengths are increased by 3 to get the full length. Non-zero encoded lengths are increased by 3 to get the full
length of the connection ID; the final value is therefore either 0 or length of the connection ID; the final value is therefore either 0 or
between 4 and 18 octets in length (inclusive). For example, an octet between 4 and 18 bytes in length (inclusive). For example, an byte
with the value 0xe0 describes a 17 octet Destination Connection ID with the value 0xe0 describes a 17 byte Destination Connection ID and
and a zero octet Source Connection ID. a zero byte Source Connection ID.
The connection ID lengths are followed by two connection IDs. The The connection ID lengths are followed by two connection IDs. The
connection ID associated with the recipient of the packet (the connection ID associated with the recipient of the packet (the
Destination Connection ID) is followed by the connection ID Destination Connection ID) is followed by the connection ID
associated with the sender of the packet (the Source Connection ID). associated with the sender of the packet (the Source Connection ID).
The remainder of the packet contains version-specific content. The remainder of the packet contains version-specific content.
4.2. Short Header 4.2. Short Header
skipping to change at page 5, line 17 skipping to change at page 5, line 17
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|X X X X X X X| |0|X X X X X X X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (*) ... | Destination Connection ID (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ... |X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: QUIC Short Header Figure 2: QUIC Short Header
A QUIC packet with a short header has the high bit of the first octet A QUIC packet with a short header has the high bit of the first byte
set to 0. set to 0.
A QUIC packet with a short header includes a Destination Connection A QUIC packet with a short header includes a Destination Connection
ID. The short header does not include the Connection ID Lengths, ID. The short header does not include the Connection ID Lengths,
Source Connection ID, or Version fields. Source Connection ID, or Version fields.
The remainder of the packet has version-specific semantics. The remainder of the packet has version-specific semantics.
4.3. Connection ID 4.3. Connection ID
skipping to change at page 6, line 12 skipping to change at page 6, line 12
additional properties which apply to a specific QUIC version, or to a additional properties which apply to a specific QUIC version, or to a
range of QUIC versions. range of QUIC versions.
5. Version Negotiation 5. Version Negotiation
A QUIC endpoint that receives a packet with a long header and a A QUIC endpoint that receives a packet with a long header and a
version it either does not understand or does not support might send version it either does not understand or does not support might send
a Version Negotiation packet in response. Packets with a short a Version Negotiation packet in response. Packets with a short
header do not trigger version negotiation. header do not trigger version negotiation.
A Version Negotiation packet sets the high bit of the first octet, A Version Negotiation packet sets the high bit of the first byte, and
and thus it conforms with the format of a packet with a long header thus it conforms with the format of a packet with a long header as
as defined in Section 4.1. A Version Negotiation packet is defined in Section 4.1. A Version Negotiation packet is identifiable
identifiable as such by the Version field, which is set to as such by the Version field, which is set to 0x00000000.
0x00000000.
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|X X X X X X X| |1|X X X X X X X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) = 0 | | Version (32) = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)| |DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 9 skipping to change at page 8, line 9
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
8. References 8. References
8.1. Normative References 8.1. Normative References
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-14 (work in progress), October 2018. transport-18 (work in progress), April 2019.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[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-14 (work in progress), October 2018. tls-18 (work in progress), April 2019.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
8.3. URIs 8.3. URIs
[1] https://mailarchive.ietf.org/arch/search/?email_list=quic [1] https://mailarchive.ietf.org/arch/search/?email_list=quic
[2] https://github.com/quicwg [2] https://github.com/quicwg
skipping to change at page 9, line 50 skipping to change at page 9, line 50
directions directions
o Only one connection at a time is established between any pair of o Only one connection at a time is established between any pair of
QUIC endpoints QUIC endpoints
Author's Address Author's Address
Martin Thomson Martin Thomson
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: mt@lowentropy.net
 End of changes. 15 change blocks. 
26 lines changed or deleted 24 lines changed or added

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