[要約] RFC 8999は、QUICプロトコルのバージョンに依存しない特性について説明しています。この文書の目的は、QUICの設計原則と核となる概念を明確にすることです。利用場面としては、QUICの実装者やプロトコルの進化に貢献する開発者にとってのガイドラインとして機能します。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8999 Mozilla
Category: Standards Track May 2021
ISSN: 2070-1721
Version-Independent Properties of QUIC
QUICのバージョンに依存しないプロパティ
Abstract
概要
This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol.
このドキュメントでは、プロトコルのすべてのバージョンに共通のQUICトランスポートプロトコルのプロパティを定義します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8999.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8999で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. An Extremely Abstract Description of QUIC 2. Fixed Properties of All QUIC Versions 3. Conventions and Definitions 4. Notational Conventions 5. QUIC Packets 5.1. Long Header 5.2. Short Header 5.3. Connection ID 5.4. Version 6. Version Negotiation 7. Security and Privacy Considerations 8. References 8.1. Normative References 8.2. Informative References Appendix A. Incorrect Assumptions Author's Address
1. QUICの極めて抽象的な説明2.すべてのQUICバージョンの固定プロパティ3.規則と定義4.表記規則5. QUICパケット5.1。ロングヘッダー5.2。短いヘッダー5.3。接続ID 5.4。バージョン6.バージョン・ネゴシエーション7.セキュリティーとプライバシーの考慮事項8.参照8.1。規範的参考文献8.2。有益な参考文献付録A.誤った仮定著者の住所
QUIC is a connection-oriented protocol between two endpoints. Those endpoints exchange UDP datagrams. These UDP datagrams contain QUIC packets. QUIC endpoints use QUIC packets to establish a QUIC connection, which is shared protocol state between those endpoints.
QUICは、2つのエンドポイント間の接続指向プロトコルです。これらのエンドポイントはUDPデータグラムを交換します。これらのUDPデータグラムにはQUICパケットが含まれています。QUICエンドポイントは、QUICのパケットを使用して、それらのエンドポイント間の共有プロトコル状態です。
In addition to providing secure, multiplexed transport, QUIC [QUIC-TRANSPORT] allows for the option to negotiate a version. This allows the protocol to change over time in response to new requirements. Many characteristics of the protocol could change between versions.
安全な多重化トランスポートの提供に加えて、QUIC [QUIC-transport]はバージョンをネゴシエートするオプションを許可します。これにより、プロトコルは新しい要件に応じて時間の経過とともに変化することができます。プロトコルの多くの特性はバージョン間で変わる可能性があります。
This document describes the subset of QUIC that is intended to remain stable as new versions are developed and deployed. All of these invariants are independent of the IP version.
このドキュメントでは、新しいバージョンが開発され展開されているため、安定したままであることを目的としたQUICのサブセットについて説明します。これらの不変式のすべてはIPバージョンとは無関係です。
The primary goal of this document is to ensure that it is possible to deploy new versions of QUIC. By documenting the properties that cannot change, this document aims to preserve the ability for QUIC endpoints to negotiate changes to any other aspect of the protocol. As a consequence, this also guarantees a minimal amount of information that is made available to entities other than endpoints. Unless specifically prohibited in this document, any aspect of the protocol can change between different versions.
この文書の主な目的は、新しいバージョンのQUICを展開することが可能であることを確認することです。変更できないプロパティを文書化することで、この文書はQUICのエンドポイントがプロトコルの他の側面への変更をネゴシエートする機能を保持することを目的としています。結果として、これはエンドポイント以外のエンティティに利用可能にされる最小限の情報も保証されます。この文書では特に禁止されていない限り、プロトコルの任意の側面は異なるバージョン間で変更できます。
Appendix A contains a non-exhaustive list of some incorrect assumptions that might be made based on knowledge of QUIC version 1; these do not apply to every version of QUIC.
付録Aには、QUICバージョン1の知識に基づいて行われる可能性があるいくつかの不正確な仮定の非網羅的なリストが含まれています。これらはQUICのすべてのバージョンには適用されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document defines requirements on future QUIC versions, even where normative language is not used.
規範的言語が使用されていない場合でも、この文書は将来のQUICのバージョンに関する要件を定義しています。
This document uses terms and notational conventions from [QUIC-TRANSPORT].
この文書では、[QUIC-Transport]から用語と表記規則を使用しています。
The format of packets is described using the notation defined in this section. This notation is the same as that used in [QUIC-TRANSPORT].
パケットの形式は、このセクションで定義されている表記法を使用して説明されています。この表記は[QUIC-Transport]で使用したものと同じです。
Complex fields are named and then followed by a list of fields surrounded by a pair of matching braces. Each field in this list is separated by commas.
複雑なフィールドは名前が付けられ、次に一致する一致するブレースによって囲まれたフィールドのリストが付けられます。このリストの各フィールドはコンマで区切られています。
Individual fields include length information, plus indications about fixed value, optionality, or repetitions. Individual fields use the following notational conventions, with all lengths in bits:
個々のフィールドには、長さ情報、および固定値、オプション、または繰り返しに関する指示が含まれています。個々のフィールドは、すべての長さがビットで、以下の表記規則を使用します。
x (A): Indicates that x is A bits long
X（a）：xが長いビットであることを示します
x (A..B): Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits, and B can be omitted to indicate no set upper limit; values in this format always end on a byte boundary
X（a..b）：xがAからBまでの長さになることができることを示します。aは、最小0ビットを示すために省略することができ、bは設定されていない上限を示さずにbを省略することができる。このフォーマットの値は常にバイト境界で終わります
x (L) = C: Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above
X（L）= C：xがcの固定値を有することを示します。xの長さはLによって記述され、これは上記の長さの形式のいずれかを使用できます
x (L) ...: Indicates that x is repeated zero or more times and that each instance has a length of L
X（L）...：Xがゼロ回以上繰り返され、各インスタンスがLの長さを持つことを示します。
This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.
この文書はネットワークバイト順（つまり、大きなエンディアン）値を使用します。各バイトの高次ビットからフィールドが配置されます。
Figure 1 shows an example structure:
例の構成例を示します。
Example Structure {
One-bit Field (1),
7-bit Field with Fixed Value (7) = 61,
Arbitrary-Length Field (..),
Variable-Length Field (8..24),
Repeated Field (8) ...,
}
Figure 1: Example Format
図1：形式の例
QUIC endpoints exchange UDP datagrams that contain one or more QUIC packets. This section describes the invariant characteristics of a QUIC packet. A version of QUIC could permit multiple QUIC packets in a single UDP datagram, but the invariant properties only describe the first packet in a datagram.
QUICのエンドポイントは、1つ以上のQUICパケットを含むUDPデータグラムを交換します。このセクションでは、QUICパケットの不変特性について説明します。QUICのバージョンは、単一のUDPデータグラム内の複数のQUICパケットを許可できますが、不変プロパティはデータグラムの最初のパケットのみを説明します。
QUIC defines two types of packet headers: long and short. Packets with a long header are identified by the most significant bit of the first byte being set; packets with a short header have that bit cleared.
QUICは2種類のパケットヘッダーを定義します。長いヘッダーを持つパケットは、セットされている最初のバイトの最上位ビットによって識別されます。短いヘッダーを持つパケットはそのビットがクリアされています。
QUIC packets might be integrity protected, including the header. However, QUIC Version Negotiation packets are not integrity protected; see Section 6.
QUICパケットは、ヘッダーを含む整合性保護されている可能性があります。ただし、QUICバージョンネゴシエーションパケットは整合性保護されていません。セクション6を参照してください。
Aside from the values described here, the payload of QUIC packets is version specific and of arbitrary length.
ここで説明した値とは別に、QUICパケットのペイロードはバージョン固有の長さ、任意の長さです。
Long headers take the form described in Figure 2.
長いヘッダーは図2に記載されている形式を取ります。
Long Header Packet {
Header Form (1) = 1,
Version-Specific Bits (7),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..2040),
Source Connection ID Length (8),
Source Connection ID (0..2040),
Version-Specific Data (..),
}
Figure 2: QUIC Long Header
図2：QUICロングヘッダー
A QUIC packet with a long header has the high bit of the first byte set to 1. All other bits in that byte are version specific.
長いヘッダーを持つQUICパケットには、最初のバイトが1に設定されています。そのバイトの他のすべてのビットはバージョン固有です。
The next four bytes include a 32-bit Version field. Versions are described in Section 5.4.
次の4バイトには32ビット版フィールドがあります。バージョンはセクション5.4で説明されています。
The next byte contains the length in bytes of the Destination Connection ID field that follows it. This length is encoded as an 8-bit unsigned integer. The Destination Connection ID field follows the Destination Connection ID Length field and is between 0 and 255 bytes in length. Connection IDs are described in Section 5.3.
次のバイトには、それに続く宛先接続IDフィールドの長さが含まれています。この長さは8ビットの符号なし整数としてエンコードされています。宛先接続IDフィールドは、宛先接続ID長フィールドに従い、長さが0から255バイトの間である。接続IDはセクション5.3で説明されています。
The next byte contains the length in bytes of the Source Connection ID field that follows it. This length is encoded as an 8-bit unsigned integer. The Source Connection ID field follows the Source Connection ID Length field and is between 0 and 255 bytes in length.
次のバイトには、続くソース接続IDフィールドの長さが含まれています。この長さは8ビットの符号なし整数としてエンコードされています。[ソース接続ID]フィールドは、ソース接続IDの長さフィールドに従います。長さは0から255バイトです。
The remainder of the packet contains version-specific content.
パケットの残りの部分にはバージョン固有のコンテンツが含まれています。
Short headers take the form described in Figure 3.
短いヘッダーは図3に記載されている形式を取ります。
Short Header Packet {
Header Form (1) = 0,
Version-Specific Bits (7),
Destination Connection ID (..),
Version-Specific Data (..),
}
Figure 3: QUIC Short Header
図3：QUICの短いヘッダー
A QUIC packet with a short header has the high bit of the first byte set to 0.
短いヘッダーを持つQUICパケットは、最初のバイトが0に設定されています。
A QUIC packet with a short header includes a Destination Connection ID immediately following the first byte. The short header does not include the Destination Connection ID Length, Source Connection ID Length, Source Connection ID, or Version fields. The length of the Destination Connection ID is not encoded in packets with a short header and is not constrained by this specification.
短いヘッダを有するQUICパケットは、最初のバイトの直後の宛先接続IDを含む。短いヘッダには、宛先接続IDの長さ、送信元接続IDの長さ、ソース接続ID、またはバージョンフィールドは含まれていません。宛先接続IDの長さは、短いヘッダーを持つパケットでエンコードされず、この仕様によって制約されていません。
The remainder of the packet has version-specific semantics.
パケットの残りの部分にはバージョン固有のセマンティクスがあります。
A connection ID is an opaque field of arbitrary length.
接続IDは任意の長さの不透明領域である。
The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP, and below) do not cause packets for a QUIC connection to be delivered to the wrong QUIC endpoint. The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint. At the endpoint, the connection ID is used to identify the QUIC connection for which the packet is intended.
接続IDの主な関数は、低いプロトコルレイヤ（UDP、IP、および下）でのアドレッシングの変更がQUIC接続のパケットを間違ったQUICエンドポイントに配信させないようにするためです。接続IDは、エンドポイントとそれらをサポートする仲介者によって使用され、各QUICパケットをエンドポイントの正しいインスタンスに配信できるようにする。エンドポイントでは、接続IDは、パケットが意図されているQUIC接続を識別するために使用されます。
The connection ID is chosen by each endpoint using version-specific methods. Packets for the same QUIC connection might use different connection ID values.
接続IDは、バージョン固有のメソッドを使用して各エンドポイントによって選択されます。同じQUIC接続のパケットは、異なる接続ID値を使用する可能性があります。
The Version field contains a 4-byte identifier. This value can be used by endpoints to identify a QUIC version. A Version field with a value of 0x00000000 is reserved for version negotiation; see Section 6. All other values are potentially valid.
バージョンフィールドには4バイトの識別子が含まれています。この値は、QUICバージョンを識別するためにエンドポイントで使用できます。値0x00000000のバージョンフィールドは、バージョンネゴシエーション用に予約されています。セクション6を参照してください。他のすべての値は潜在的に有効です。
The properties described in this document apply to all versions of QUIC. A protocol that does not conform to the properties described in this document is not QUIC. Future documents might describe additional properties that apply to a specific QUIC version or to a range of QUIC versions.
このドキュメントに記載されているプロパティは、QUICのすべてのバージョンに適用されます。この文書に記載されているプロパティに準拠していないプロトコルはQUICではありません。将来の文書は、特定のQUICバージョンまたはさまざまなQUICバージョンに適用される追加のプロパティを記述できます。
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 a Version Negotiation packet in response. Packets with a short header do not trigger version negotiation.
長いヘッダーとバージョンを持つパケットを受信するQUICエンドポイントは、それに応じてバージョンネゴシエーションパケットを送信することはできません。短いヘッダーを持つパケットはバージョンネゴシエーションをトリガーしません。
A Version Negotiation packet sets the high bit of the first byte, and thus it conforms with the format of a packet with a long header as defined in Section 5.1. A Version Negotiation packet is identifiable as such by the Version field, which is set to 0x00000000.
バージョンネゴシエーションパケットは、最初のバイトのハイビットを設定し、それによってセクション5.1で定義されている長いヘッダーを持つパケットのフォーマットに準拠しています。バージョンネゴシエーションパケットは、0x00000000に設定されているバージョンフィールドによって識別可能です。
Version Negotiation Packet {
Header Form (1) = 1,
Unused (7),
Version (32) = 0,
Destination Connection ID Length (8),
Destination Connection ID (0..2040),
Source Connection ID Length (8),
Source Connection ID (0..2040),
Supported Version (32) ...,
}
Figure 4: Version Negotiation Packet
図4：バージョンネゴシエーションパケット
Only the most significant bit of the first byte of a Version Negotiation packet has any defined value. The remaining 7 bits, labeled "Unused", can be set to any value when sending and MUST be ignored on receipt.
バージョンネゴシエーションパケットの最初のバイトの最上位ビットのみに定義された値があります。"未使用"というラベルの残りの残りの7ビットは、送信時に任意の値に設定でき、受信時に無視する必要があります。
After the Source Connection ID field, the Version Negotiation packet contains a list of Supported Version fields, each identifying a version that the endpoint sending the packet supports. A Version Negotiation packet contains no other fields. An endpoint MUST ignore a packet that contains no Supported Version fields or contains a truncated Supported Version value.
ソース接続IDフィールドの後、バージョンネゴシエーションパケットにサポートされているバージョンフィールドのリストが含まれています。それぞれがパケットサポートを送信するエンドポイントが送信されるバージョンを識別します。バージョンネゴシエーションパケットには他のフィールドが含まれていません。エンドポイントは、サポートされているバージョンフィールドを含むパケットを無視する必要があります。または、トランケートされたサポートされているバージョン値を含みます。
Version Negotiation packets do not use integrity or confidentiality protection. Specific QUIC versions might include protocol elements that allow endpoints to detect modification or corruption in the set of supported versions.
バージョンネゴシエーションパケットは、完全性または機密性保護を使用しません。特定のQUICバージョンには、エンドポイントがサポートされているバージョンのセット内の変更または破損を検出できるプロトコル要素が含まれる場合があります。
An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID field. The value for the Source Connection ID field MUST be copied from the Destination Connection ID field of the received packet, which is initially randomly selected by a client. Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an attacker that is unable to observe packets.
エンドポイントは、宛先接続IDフィールドに受信したパケットのソース接続IDフィールドからの値を含める必要があります。ソース接続IDフィールドの値は、受信したパケットの宛先接続IDフィールドからコピーする必要があります。これは最初はクライアントによってランダムに選択されます。両方の接続IDをエコーすると、サーバーがパケットを受信し、バージョンネゴシエーションパケットがパケットを監視できない攻撃者によって生成されなかったことをクライアントに提供します。
An endpoint that receives a Version Negotiation packet might change the version that it decides to use for subsequent packets. The conditions under which an endpoint changes its QUIC version will depend on the version of QUIC that it chooses.
バージョンネゴシエーションパケットを受信するエンドポイントは、後続のパケットに使用することを決定するバージョンを変更する可能性があります。エンドポイントがそのQUICバージョンを変更する条件は、選択したQUICのバージョンによって異なります。
See [QUIC-TRANSPORT] for a more thorough description of how an endpoint that supports QUIC version 1 generates and consumes a Version Negotiation packet.
QUICバージョン1をサポートするエンドポイントがバージョンネゴシエーションパケットを生成し消費する方法の詳細については、[QUIC-Transport]を参照してください。
It is possible that middleboxes could observe traits of a specific version of QUIC and assume that when other versions of QUIC exhibit similar traits the same underlying semantic is being expressed. There are potentially many such traits; see Appendix A. Some effort has been made to either eliminate or obscure some observable traits in QUIC version 1, but many of these remain. Other QUIC versions might make different design decisions and so exhibit different traits.
ミドルボックスが特定のバージョンのQUICの特性を観察できる可能性があり、その他のバージョンのQUICが同じ基本的な意味で表現されていることを示していることが可能です。そのような特性が多くある。付録Aを参照してください。QUICバージョン1でいくつかの観測可能な特性を排除または不明瞭にするためのいくつかの努力がなされていますが、これらの多くは残っています。他のQUICバージョンは別のデザインの決定を下すかもしれませんし、それでは異なる形質を示します。
The QUIC version number does not appear in all QUIC packets, which means that reliably extracting information from a flow based on version-specific traits requires that middleboxes retain state for every connection ID they see.
QUICバージョン番号はすべてのQUICパケットに表示されません。これは、バージョン固有の特性に基づくフローから情報を確実に抽出することを意味します。
The Version Negotiation packet described in this document is not integrity protected; it only has modest protection against insertion by attackers. An endpoint MUST authenticate the semantic content of a Version Negotiation packet if it attempts a different QUIC version as a result.
このドキュメントに記載されているバージョンネゴシエーションパケットは、整合性保護されていません。攻撃者による挿入に対する控えめな保護のみがあります。結果として異なるQUICバージョンを試みると、エンドポイントはバージョンネゴシエーションパケットの意味内容を認証しなければなりません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.
[QUIC-TLS] Thomson、M.、ED。S.ターナー、ed。、「TLSをセキュリティに使用する」、RFC 9001、DOI 10.17487 / RFC9001、2021年5月、<https：//www.rfc-editor.org/info/rfc9001>。
[QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[QUIC-Transport] Iyengar、J.、ED。そして、「Q. Thomson」、「QUIC：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487 / RFC9000、<https：//www.rfc-editor.org/info/rfc9000>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116] MCGREW、D。、「認証済み暗号化のためのインタフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<https：//www.rfc-editor.org/info/rfc5116>。
There are several traits of QUIC version 1 [QUIC-TRANSPORT] that are not protected from observation but are nonetheless considered to be changeable when a new version is deployed.
展望台から保護されていないが、それにもかかわらず、新しいバージョンが展開されたときに変更可能であると考えられるQUICバージョン1 [QUIC-Transport]のいくつかの特性があります。
This section lists a sampling of incorrect assumptions that might be made about QUIC based on knowledge of QUIC version 1. Some of these statements are not even true for QUIC version 1. This is not an exhaustive list; it is intended to be illustrative only.
このセクションでは、QUICバージョン1の知識に基づいてQUICについて行われる可能性がある誤った仮定のサンプリングをリストします。これらのステートメントの一部は、QUICバージョン1に対しても当てはまりません。これは網羅的なリストではありません。それは例示的なものになることを意図しています。
*Any and all of the following statements can be false for a given QUIC version:*
*与えられたQUICのバージョンでは、次のステートメントのすべてがFALSEになる可能性があります。
* QUIC uses TLS [QUIC-TLS], and some TLS messages are visible on the wire.
* QUICはTLS [QUIC-TLS]を使用し、いくつかのTLSメッセージがワイヤーに表示されます。
* QUIC long headers are only exchanged during connection establishment.
* QUICの長いヘッダーは接続確立中にのみ交換されます。
* Every flow on a given 5-tuple will include a connection establishment phase.
* 特定の5タプル上のすべてのフローは接続確立フェーズを含みます。
* The first packets exchanged on a flow use the long header.
* フローで交換された最初のパケットはロングヘッダーを使用します。
* The last packet before a long period of quiescence might be assumed to contain only an acknowledgment.
* 長期間の静止期前の最後のパケットは、確認応答のみを含むと想定されます。
* QUIC uses an Authenticated Encryption with Associated Data (AEAD) function (AEAD_AES_128_GCM; see [RFC5116]) to protect the packets it exchanges during connection establishment.
* QUICは、接続確立中に交換したパケットを保護するために、関連データ（AEAD_AES_128_GCM; [RFC5116]参照）を使用して認証された暗号化を使用します。
* QUIC packet numbers are encrypted and appear as the first encrypted bytes.
* QUICのパケット番号は暗号化され、最初の暗号化されたバイトとして表示されます。
* QUIC packet numbers increase by one for every packet sent.
* 送信されたパケットごとに、QUICのパケット番号が1つずつ増加します。
* QUIC has a minimum size for the first handshake packet sent by a client.
* QUICは、クライアントによって送信された最初のハンドシェイクパケットの最小サイズです。
* QUIC stipulates that a client speak first.
* QUICは、クライアントが最初に話すことを規定しています。
* QUIC packets always have the second bit of the first byte (0x40) set.
* QUICパケットは常に最初のバイト（0x40）セットの2番目のビットを持ちます。
* A QUIC Version Negotiation packet is only sent by a server.
* QUICバージョンネゴシエーションパケットは、サーバーによってのみ送信されます。
* A QUIC connection ID changes infrequently.
* QUIC接続IDはめったに変化しません。
* QUIC endpoints change the version they speak if they are sent a Version Negotiation packet.
* QUICのエンドポイントは、バージョンネゴシエーションパケットを送信した場合に自分の話を変更します。
* The Version field in a QUIC long header is the same in both directions.
* QUICロングヘッダーのバージョンフィールドは、両方向で同じです。
* A QUIC packet with a particular value in the Version field means that the corresponding version of QUIC is in use.
* バージョンフィールドに特定の値を持つQUICパケットは、対応するバージョンのQUICが使用中であることを意味します。
* Only one connection at a time is established between any pair of QUIC endpoints.
* QUICの任意のエンドポイントの間には、一度に1つの接続のみが確立されます。
Author's Address
著者の住所
Martin Thomson Mozilla
Martin Thomson Mozilla.
Email: mt@lowentropy.net