[要約] RFC 9000は、QUICプロトコルに関する基本的な仕様を定義しています。QUICは、信頼性とセキュリティを提供するためにUDPをベースにした多重化されたトランスポートプロトコルです。このプロトコルは、特にWebトラフィックやストリーミングメディアのような遅延に敏感なアプリケーションでの利用を目的として設計されています。QUICは、接続の確立時間の短縮、パケットの再送制御、暗号化通信の強化など、TCPよりも改善された特性を提供します。関連するRFCには、RFC 8999（QUICのバージョン1の適用性に関する声明）、RFC 9001（QUICの暗号化とTLSの統合）、RFC 9002（QUICの輻輳制御）などがあります。
Internet Engineering Task Force (IETF) J. Iyengar, Ed.
Request for Comments: 9000 Fastly
Category: Standards Track M. Thomson, Ed.
ISSN: 2070-1721 Mozilla
May 2021
QUIC: A UDP-Based Multiplexed and Secure Transport
QUIC：UDPベースの多重化および安全な輸送
Abstract
概要
This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.
この文書は、QUICトランスポートプロトコルのコアを定義します。QUICは、構造化通信、低レイテンシ接続確立、ネットワークパスの移行のためのフロー制御ストリームを含むアプリケーションを提供します。QUICには、展開状況の範囲で機密性、完全性、および可用性を確保するセキュリティ対策が含まれています。添付の文書は、鍵交渉、損失検出、および例示的な輻輳制御アルゴリズムのためのTLSの統合について説明する。
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/rfc9000.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9000で入手できます。
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. Overview
1.1. Document Structure
1.2. Terms and Definitions
1.3. Notational Conventions
2. Streams
2.1. Stream Types and Identifiers
2.2. Sending and Receiving Data
2.3. Stream Prioritization
2.4. Operations on Streams
3. Stream States
3.1. Sending Stream States
3.2. Receiving Stream States
3.3. Permitted Frame Types
3.4. Bidirectional Stream States
3.5. Solicited State Transitions
4. Flow Control
4.1. Data Flow Control
4.2. Increasing Flow Control Limits
4.3. Flow Control Performance
4.4. Handling Stream Cancellation
4.5. Stream Final Size
4.6. Controlling Concurrency
5. Connections
5.1. Connection ID
5.1.1. Issuing Connection IDs
5.1.2. Consuming and Retiring Connection IDs
5.2. Matching Packets to Connections
5.2.1. Client Packet Handling
5.2.2. Server Packet Handling
5.2.3. Considerations for Simple Load Balancers
5.3. Operations on Connections
6. Version Negotiation
6.1. Sending Version Negotiation Packets
6.2. Handling Version Negotiation Packets
6.3. Using Reserved Versions
7. Cryptographic and Transport Handshake
7.1. Example Handshake Flows
7.2. Negotiating Connection IDs
7.3. Authenticating Connection IDs
7.4. Transport Parameters
7.4.1. Values of Transport Parameters for 0-RTT
7.4.2. New Transport Parameters
7.5. Cryptographic Message Buffering
8. Address Validation
8.1. Address Validation during Connection Establishment
8.1.1. Token Construction
8.1.2. Address Validation Using Retry Packets
8.1.3. Address Validation for Future Connections
8.1.4. Address Validation Token Integrity
8.2. Path Validation
8.2.1. Initiating Path Validation
8.2.2. Path Validation Responses
8.2.3. Successful Path Validation
8.2.4. Failed Path Validation
9. Connection Migration
9.1. Probing a New Path
9.2. Initiating Connection Migration
9.3. Responding to Connection Migration
9.3.1. Peer Address Spoofing
9.3.2. On-Path Address Spoofing
9.3.3. Off-Path Packet Forwarding
9.4. Loss Detection and Congestion Control
9.5. Privacy Implications of Connection Migration
9.6. Server's Preferred Address
9.6.1. Communicating a Preferred Address
9.6.2. Migration to a Preferred Address
9.6.3. Interaction of Client Migration and Preferred Address
9.7. Use of IPv6 Flow Label and Migration
10. Connection Termination
10.1. Idle Timeout
10.1.1. Liveness Testing
10.1.2. Deferring Idle Timeout
10.2. Immediate Close
10.2.1. Closing Connection State
10.2.2. Draining Connection State
10.2.3. Immediate Close during the Handshake
10.3. Stateless Reset
10.3.1. Detecting a Stateless Reset
10.3.2. Calculating a Stateless Reset Token
10.3.3. Looping
11. Error Handling
11.1. Connection Errors
11.2. Stream Errors
12. Packets and Frames
12.1. Protected Packets
12.2. Coalescing Packets
12.3. Packet Numbers
12.4. Frames and Frame Types
12.5. Frames and Number Spaces
13. Packetization and Reliability
13.1. Packet Processing
13.2. Generating Acknowledgments
13.2.1. Sending ACK Frames
13.2.2. Acknowledgment Frequency
13.2.3. Managing ACK Ranges
13.2.4. Limiting Ranges by Tracking ACK Frames
13.2.5. Measuring and Reporting Host Delay
13.2.6. ACK Frames and Packet Protection
13.2.7. PADDING Frames Consume Congestion Window
13.3. Retransmission of Information
13.4. Explicit Congestion Notification
13.4.1. Reporting ECN Counts
13.4.2. ECN Validation
14. Datagram Size
14.1. Initial Datagram Size
14.2. Path Maximum Transmission Unit
14.2.1. Handling of ICMP Messages by PMTUD
14.3. Datagram Packetization Layer PMTU Discovery
14.3.1. DPLPMTUD and Initial Connectivity
14.3.2. Validating the Network Path with DPLPMTUD
14.3.3. Handling of ICMP Messages by DPLPMTUD
14.4. Sending QUIC PMTU Probes
14.4.1. PMTU Probes Containing Source Connection ID
15. Versions
16. Variable-Length Integer Encoding
17. Packet Formats
17.1. Packet Number Encoding and Decoding
17.2. Long Header Packets
17.2.1. Version Negotiation Packet
17.2.2. Initial Packet
17.2.3. 0-RTT
17.2.4. Handshake Packet
17.2.5. Retry Packet
17.3. Short Header Packets
17.3.1. 1-RTT Packet
17.4. Latency Spin Bit
18. Transport Parameter Encoding
18.1. Reserved Transport Parameters
18.2. Transport Parameter Definitions
19. Frame Types and Formats
19.1. PADDING Frames
19.2. PING Frames
19.3. ACK Frames
19.3.1. ACK Ranges
19.3.2. ECN Counts
19.4. RESET_STREAM Frames
19.5. STOP_SENDING Frames
19.6. CRYPTO Frames
19.7. NEW_TOKEN Frames
19.8. STREAM Frames
19.9. MAX_DATA Frames
19.10. MAX_STREAM_DATA Frames
19.11. MAX_STREAMS Frames
19.12. DATA_BLOCKED Frames
19.13. STREAM_DATA_BLOCKED Frames
19.14. STREAMS_BLOCKED Frames
19.15. NEW_CONNECTION_ID Frames
19.16. RETIRE_CONNECTION_ID Frames
19.17. PATH_CHALLENGE Frames
19.18. PATH_RESPONSE Frames
19.19. CONNECTION_CLOSE Frames
19.20. HANDSHAKE_DONE Frames
19.21. Extension Frames
20. Error Codes
20.1. Transport Error Codes
20.2. Application Protocol Error Codes
21. Security Considerations
21.1. Overview of Security Properties
21.1.1. Handshake
21.1.2. Protected Packets
21.1.3. Connection Migration
21.2. Handshake Denial of Service
21.3. Amplification Attack
21.4. Optimistic ACK Attack
21.5. Request Forgery Attacks
21.5.1. Control Options for Endpoints
21.5.2. Request Forgery with Client Initial Packets
21.5.3. Request Forgery with Preferred Addresses
21.5.4. Request Forgery with Spoofed Migration
21.5.5. Request Forgery with Version Negotiation
21.5.6. Generic Request Forgery Countermeasures
21.6. Slowloris Attacks
21.7. Stream Fragmentation and Reassembly Attacks
21.8. Stream Commitment Attack
21.9. Peer Denial of Service
21.10. Explicit Congestion Notification Attacks
21.11. Stateless Reset Oracle
21.12. Version Downgrade
21.13. Targeted Attacks by Routing
21.14. Traffic Analysis
22. IANA Considerations
22.1. Registration Policies for QUIC Registries
22.1.1. Provisional Registrations
22.1.2. Selecting Codepoints
22.1.3. Reclaiming Provisional Codepoints
22.1.4. Permanent Registrations
22.2. QUIC Versions Registry
22.3. QUIC Transport Parameters Registry
22.4. QUIC Frame Types Registry
22.5. QUIC Transport Error Codes Registry
23. References
23.1. Normative References
23.2. Informative References
Appendix A. Pseudocode
A.1. Sample Variable-Length Integer Decoding
A.2. Sample Packet Number Encoding Algorithm
A.3. Sample Packet Number Decoding Algorithm
A.4. Sample ECN Validation Algorithm
Contributors
Authors' Addresses
QUIC is a secure general-purpose transport protocol. This document defines version 1 of QUIC, which conforms to the version-independent properties of QUIC defined in [QUIC-INVARIANTS].
QUICは安全な汎用転送プロトコルです。このドキュメントはQUICのバージョン1を定義します。これは、[QUIC-INVARIANTS]で定義されているQUICのバージョンに依存しないプロパティに準拠しています。
QUIC is a connection-oriented protocol that creates a stateful interaction between a client and server.
QUICは、クライアントとサーバー間のステートフルインタラクションを作成する接続指向プロトコルです。
The QUIC handshake combines negotiation of cryptographic and transport parameters. QUIC integrates the TLS handshake [TLS13], although using a customized framing for protecting packets. The integration of TLS and QUIC is described in more detail in [QUIC-TLS]. The handshake is structured to permit the exchange of application data as soon as possible. This includes an option for clients to send data immediately (0-RTT), which requires some form of prior communication or configuration to enable.
QUICハンドシェイクは、暗号化パラメータとトランスポートパラメータのネゴシエーションを兼ね備えています。QUICは、パケットを保護するためのカスタマイズされたフレーミングを使用していますが、TLSハンドシェイク[TLS13]を統合します。TLSとQUICの統合は[QUIC-TLS]でより詳細に説明されています。ハンドシェイクは、できるだけ早くアプリケーションデータの交換を可能にするように構成されています。これには、クライアントにすぐにデータを送信するオプション（0-RTT）が含まれています。
Endpoints communicate in QUIC by exchanging QUIC packets. Most packets contain frames, which carry control information and application data between endpoints. QUIC authenticates the entirety of each packet and encrypts as much of each packet as is practical. QUIC packets are carried in UDP datagrams [UDP] to better facilitate deployment in existing systems and networks.
QUICパケットを交換することによって、エンドポイントがQUICで通信します。ほとんどのパケットには、エンドポイント間で制御情報とアプリケーションデータを運ぶフレームが含まれています。QUICは各パケットの全体を認証し、実用的な各パケットを暗号化します。QUICパケットは、既存のシステムとネットワークへの展開を容易にするために、UDPデータグラム[UDP]で搭載されています。
Application protocols exchange information over a QUIC connection via streams, which are ordered sequences of bytes. Two types of streams can be created: bidirectional streams, which allow both endpoints to send data; and unidirectional streams, which allow a single endpoint to send data. A credit-based scheme is used to limit stream creation and to bound the amount of data that can be sent.
アプリケーションプロトコルは、Streamsを介してQUIC接続を介して情報を交換します。これは、バイトの順序付きシーケンスです。2種類のストリームを作成できます。両方のエンドポイントがデータを送信できるようにする双方向ストリーム。単一のエンドポイントがデータを送信できるようにする単方向のストリーム。クレジットベースの方式は、ストリーム作成を制限し、送信できるデータ量をバインドするために使用されます。
QUIC provides the necessary feedback to implement reliable delivery and congestion control. An algorithm for detecting and recovering from loss of data is described in Section 6 of [QUIC-RECOVERY]. QUIC depends on congestion control to avoid network congestion. An exemplary congestion control algorithm is described in Section 7 of [QUIC-RECOVERY].
QUICは信頼できる配信と輻輳制御を実装するために必要なフィードバックを提供します。データの損失から検出および回復するためのアルゴリズムは、[QUIC-RECOVERY]のセクション6に記載されています。QUICは、ネットワークの輻輳を回避するための輻輳制御に依存します。例示的な輻輳制御アルゴリズムは、[QUIC-RECOVERY]のセクション7に記載されています。
QUIC connections are not strictly bound to a single network path. Connection migration uses connection identifiers to allow connections to transfer to a new network path. Only clients are able to migrate in this version of QUIC. This design also allows connections to continue after changes in network topology or address mappings, such as might be caused by NAT rebinding.
QUIC接続は単一のネットワークパスに厳密にバインドされていません。接続移行は接続識別子を使用して、接続を新しいネットワークパスに転送できるようにします。クライアントのみがこのバージョンのQUICで移行することができます。この設計により、NATの再バインドによって発生する可能性があるように、ネットワークトポロジまたはアドレスマッピングの変更後に接続も継続することができます。
Once established, multiple options are provided for connection termination. Applications can manage a graceful shutdown, endpoints can negotiate a timeout period, errors can cause immediate connection teardown, and a stateless mechanism provides for termination of connections after one endpoint has lost state.
確立されると、接続終了のために複数のオプションが提供されます。アプリケーションは正常なシャットダウンを管理でき、エンドポイントはタイムアウト期間をネゴシエートでき、エラーは即時接続のティアダウンを引き起こす可能性があり、ステートレスメカニズムは1つのエンドポイントが失われた後に接続の終了を提供します。
This document describes the core QUIC protocol and is structured as follows:
このドキュメントでは、QUICプロトコルの主要な部分について説明し、次のように構成されています。
* Streams are the basic service abstraction that QUIC provides.
* ストリーム (Streams) はQUICが提供する基本的な機能です。
- Section 2 describes core concepts related to streams,
- セクション2はストリームに関連するコア概念を説明しています。
- Section 3 provides a reference model for stream states, and
- セクション3はストリーム状態のための参照モデルを提供します
- Section 4 outlines the operation of flow control.
- セクション4はフロー制御の動作の概要を示します。
* Connections are the context in which QUIC endpoints communicate.
* 接続 (Connections) はQUICのエンドポイントが通信するコンテキストです。
- Section 5 describes core concepts related to connections,
- セクション5は接続に関連する主要な概念を説明しています。
- Section 6 describes version negotiation,
- セクション6はバージョン交渉を説明します。
- Section 7 details the process for establishing connections,
- セクション7は接続を確立するためのプロセスを詳しく説明します。
- Section 8 describes address validation and critical denial-of-service mitigations,
- セクション8はアドレス検証と重要なDoS攻撃軽減方法を説明しています。
- Section 9 describes how endpoints migrate a connection to a new network path,
- セクション9エンドポイントは新しいネットワークパスへの接続の移行方法について説明します。
- Section 10 lists the options for terminating an open connection, and
- セクション10は、開いている接続を終了するためのオプションを示しています。
- Section 11 provides guidance for stream and connection error handling.
- セクション11はストリームおよび接続エラー処理のためのガイダンスを提供します。
* Packets and frames are the basic unit used by QUIC to communicate.
* パケットとフレームは通信にQUICが使用する基本単位です。
- Section 12 describes concepts related to packets and frames,
- セクション12はパケットとフレームに関する概念について説明します。
- Section 13 defines models for the transmission, retransmission, and acknowledgment of data, and
- セクション13はデータの送信、再送信、および承認(ACK)のためのモデルを定義します。
- Section 14 specifies rules for managing the size of datagrams carrying QUIC packets.
- セクション14はQUICパケットを伝送するデータグラムのサイズを管理するためのルールを指定します。
* Finally, encoding details of QUIC protocol elements are described in:
* 最後に、QUICプロトコル要素の符号化の詳細については、以下で説明されています。
- Section 15 (versions),
- セクション15（バージョン）、
- Section 16 (integer encoding),
- セクション16（整数エンコーディング）、
- Section 17 (packet headers),
- セクション17（パケットヘッダー）
- Section 18 (transport parameters),
- セクション18（輸送パラメータ）
- Section 19 (frames), and
- セクション19（フレーム）
- Section 20 (errors).
- セクション20（エラー）
Accompanying documents describe QUIC's loss detection and congestion control [QUIC-RECOVERY], and the use of TLS and other cryptographic mechanisms [QUIC-TLS].
添付の文書は、QUICの損失検出および輻輳制御[QUIC-RECOVERY]、およびTLSおよびその他の暗号化メカニズム[QUIC-TLS]の使用について説明します。
This document defines QUIC version 1, which conforms to the protocol invariants in [QUIC-INVARIANTS].
このドキュメントは、[QUIC-INVARIANTS]のプロトコル不変式に準拠したQUICバージョン1を定義します。
To refer to QUIC version 1, cite this document. References to the limited set of version-independent properties of QUIC can cite [QUIC-INVARIANTS].
QUICバージョン1を参照するには、この文書を引用してください。QUICのバージョンに依存しない特性の限られたセットへの参照は、[QUIC-INVARIANTS]を引用することができます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Commonly used terms in this document are described below.
この文書では一般的に使用されている用語について説明します。
QUIC: The transport protocol described by this document. QUIC is a name, not an acronym.
QUIC：この文書で説明されているトランスポートプロトコル。QUICは頭字語ではなく名前です。
Endpoint: An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets. There are only two types of endpoints in QUIC: client and server.
エンドポイント：QUICパケットを生成、受信、および処理することによって、QUIC接続に参加できるエンティティ。QUICにはクライアントとサーバーには2種類のエンドポイントがあります。
Client: The endpoint that initiates a QUIC connection.
クライアント：QUIC接続を開始するエンドポイント。
Server: The endpoint that accepts a QUIC connection.
サーバー：QUIC接続を受け入れるエンドポイント。
QUIC packet: A complete processable unit of QUIC that can be encapsulated in a UDP datagram. One or more QUIC packets can be encapsulated in a single UDP datagram.
QUICパケット：UDPデータグラムにカプセル化できるQUICの完全な処理可能なユニット。1つ以上のQUICパケットを単一のUDPデータグラムにカプセル化できます。
Ack-eliciting packet: A QUIC packet that contains frames other than ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to send an acknowledgment; see Section 13.2.1.
Ack-eliciting packet：ACK、PADDING、およびCONNECTION_CLOSE以外のフレームを含むQUICパケット。これらは受信者に確認応答を送信させます。13.2.1項を参照してください。
Frame: A unit of structured protocol information. There are multiple frame types, each of which carries different information. Frames are contained in QUIC packets.
フレーム：構造化プロトコル情報の単位。複数のフレームタイプがあり、それぞれが異なる情報を運びます。フレームはQUICパケットに含まれています。
Address: When used without qualification, the tuple of IP version, IP address, and UDP port number that represents one end of a network path.
アドレス：修飾なしで使用されている場合は、ネットワークパスの一端を表すIPバージョン、IPアドレス、およびUDPポート番号のタプルです。
Connection ID: An identifier that is used to identify a QUIC connection at an endpoint. Each endpoint selects one or more connection IDs for its peer to include in packets sent towards the endpoint. This value is opaque to the peer.
接続ID：エンドポイントでQUIC接続を識別するために使用される識別子。各エンドポイントは、エンドポイントに向かって送信されたパケットに含めるためのピアの1つ以上の接続IDを選択します。この値はピアに不透明です。
Stream: A unidirectional or bidirectional channel of ordered bytes within a QUIC connection. A QUIC connection can carry multiple simultaneous streams.
ストリーム：QUIC接続内の順序付きバイトの単方向または双方向チャネル。QUIC接続は複数の同時ストリームを運ぶことができます。
Application: An entity that uses QUIC to send and receive data.
アプリケーション：QUICを使用してデータを送受信するエンティティ。
This document uses the terms "QUIC packets", "UDP datagrams", and "IP packets" to refer to the units of the respective protocols. That is, one or more QUIC packets can be encapsulated in a UDP datagram, which is in turn encapsulated in an IP packet.
この文書は、用語「QUICパケット」、「UDPデータグラム」、および「IPパケット」を使用して、それぞれのプロトコルの単位を参照します。すなわち、1つまたは複数のQUICパケットをUDPデータグラムにカプセル化することができ、これはIPパケットにカプセル化されています。
Packet and frame diagrams in this document use a custom format. The purpose of this format is to summarize, not define, protocol elements. Prose defines the complete semantics and details of structures.
この文書のパケットとフレーム図は、カスタム形式を使用します。このフォーマットの目的は要約され、定義されていない、プロトコル要素を要約することです。Proseは完全な意味論と構造の詳細を定義します。
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が長さAビットであることを示します
x (i): Indicates that x holds an integer value using the variable-length encoding described in Section 16
x (i): xがセクション16で説明されている可変長エンコーディングを使用して整数値を保持することを示します
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) = C..D: Indicates that x has a value in the range from C to D, inclusive, with the length described by L, as above
x (L) = C..D: xが、上記のようにLで説明されている長さを含むCからDまでの値の値を持つことを示します。
[x (L)]: Indicates that x is optional and has a length of L
[x (L)]: 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.
この文書はネットワークバイト順（つまり、ビッグエンディアン）値を使用します。各バイトの最上位ビットからフィールドが配置されます。
By convention, individual fields reference a complex field by using the name of the complex field.
慣例により、個々のフィールドは複雑フィールドの名前を使用して複雑なフィールドを参照します。
Figure 1 provides an example:
図1に例を示します。
Example Structure {
One-bit Field (1),
7-bit Field with Fixed Value (7) = 61,
Field with Variable-Length Integer (i),
Arbitrary-Length Field (..),
Variable-Length Field (8..24),
Field With Minimum Length (16..),
Field With Maximum Length (..128),
[Optional Field (64)],
Repeated Field (8) ...,
}
Figure 1: Example Format
図1：形式の例
When a single-bit field is referenced in prose, the position of that field can be clarified by using the value of the byte that carries the field with the field's value set. For example, the value 0x80 could be used to refer to the single-bit field in the most significant bit of the byte, such as One-bit Field in Figure 1.
散文でシングルビットフィールドが参照される場合、そのフィールドの位置は、フィールドの値が設定されたフィールドを運ぶバイトの値を使用して明確にすることができます。たとえば、値0x80は、図1の1ビットフィールドなど、バイトの最上位ビット内のシングルビットフィールドを参照するために使用できます。
Streams in QUIC provide a lightweight, ordered byte-stream abstraction to an application. Streams can be unidirectional or bidirectional.
QUICのストリームは、アプリケーションへの軽量、注文されたバイトストリームの抽象化を提供します。ストリームは一方向または双方向になる可能性があります。
Streams can be created by sending data. Other processes associated with stream management -- ending, canceling, and managing flow control -- are all designed to impose minimal overheads. For instance, a single STREAM frame (Section 19.8) can open, carry data for, and close a stream. Streams can also be long-lived and can last the entire duration of a connection.
ストリームは、データを送信することで作成できます。ストリーム管理に関連する他のプロセス（フロー制御の終了、キャンセル、および管理）はすべて、最小限のオーバーヘッドを課すように設計されています。たとえば、単一のSTREAMフレーム（セクション19.8）は、ストリームを開いたり、データを伝送したり、閉じたりすることができます。ストリームは長続きすることもあり、接続の全期間続くことがあります。
Streams can be created by either endpoint, can concurrently send data interleaved with other streams, and can be canceled. QUIC does not provide any means of ensuring ordering between bytes on different streams.
ストリームはどちらかのエンドポイントによって作成でき、他のストリームとインターリーブされたデータを同時に送信することができ、キャンセルすることができます。QUICは、さまざまなストリーム上のバイト間の順序を確保する手段を提供しません。
QUIC allows for an arbitrary number of streams to operate concurrently and for an arbitrary amount of data to be sent on any stream, subject to flow control constraints and stream limits; see Section 4.
QUICは、任意の数のストリームが同時に動作し、任意のストリームで任意のストリーム上で送信され、フロー制御の制約およびストリームの制限を条件として送信することを可能にします。セクション4を参照してください。
Streams can be unidirectional or bidirectional. Unidirectional streams carry data in one direction: from the initiator of the stream to its peer. Bidirectional streams allow for data to be sent in both directions.
ストリームは一方向または双方向になる可能性があります。一方向ストリームはデータを一方向に搬送します。ストリームの開始者からそのピアへ。双方向ストリームでは、データを両方向に送信できます。
Streams are identified within a connection by a numeric value, referred to as the stream ID. A stream ID is a 62-bit integer (0 to 2^62-1) that is unique for all streams on a connection. Stream IDs are encoded as variable-length integers; see Section 16. A QUIC endpoint MUST NOT reuse a stream ID within a connection.
ストリームは、ストリームIDと呼ばれる数値によって接続内で識別されます。ストリームIDは、接続上のすべてのストリームに対して一意である62ビット整数（0 ~ 2^62-1）です。ストリームIDは可変長整数としてエンコードされています。セクション16を参照してください。QUICエンドポイントは、接続内のストリームIDを再利用してはなりません。
The least significant bit (0x01) of the stream ID identifies the initiator of the stream. Client-initiated streams have even-numbered stream IDs (with the bit set to 0), and server-initiated streams have odd-numbered stream IDs (with the bit set to 1).
ストリームIDの最下位ビット（0x01）は、ストリームの開始者を識別します。クライアント開始ストリームには（ビットが0に設定されている）偶数番目のストリームIDがあり、サーバー起動ストリームには奇数のストリームIDがあります（ビットは1に設定されています）。
The second least significant bit (0x02) of the stream ID distinguishes between bidirectional streams (with the bit set to 0) and unidirectional streams (with the bit set to 1).
ストリームIDの2番目の最下位ビット（0x02）は、双方向ストリーム（ビットが0に設定されている）と一方向のストリーム（ビットが1に設定されている）とを区別します。
The two least significant bits from a stream ID therefore identify a stream as one of four types, as summarized in Table 1.
したがって、ストリームIDからの2つの最下位ビットは、表1のように、4つのタイプのうちの1つとしてストリームを識別します。
+======+==================================+
| Bits | Stream Type |
+======+==================================+
| 0x00 | Client-Initiated, Bidirectional |
+------+----------------------------------+
| 0x01 | Server-Initiated, Bidirectional |
+------+----------------------------------+
| 0x02 | Client-Initiated, Unidirectional |
+------+----------------------------------+
| 0x03 | Server-Initiated, Unidirectional |
+------+----------------------------------+
Table 1: Stream ID Types
表1：ストリームIDタイプ
The stream space for each type begins at the minimum value (0x00 through 0x03, respectively); successive streams of each type are created with numerically increasing stream IDs. A stream ID that is used out of order results in all streams of that type with lower-numbered stream IDs also being opened.
各タイプのストリームスペースは、最小値（0x00から0x03）で始まります。各タイプの連続したストリームは、数値的に増加するストリームIDを使用して作成されます。順序から使用されるストリームIDは、そのタイプのすべてのストリームで、より低い番号のストリームIDも開かれています。
STREAM frames (Section 19.8) encapsulate data sent by an application. An endpoint uses the Stream ID and Offset fields in STREAM frames to place data in order.
ストリームフレーム（セクション19.8）はアプリケーションによって送信されたデータをカプセル化します。エンドポイントは、ストリームフレーム内のストリームIDフィールドとオフセットフィールドを使用してデータを順番に配置します。
Endpoints MUST be able to deliver stream data to an application as an ordered byte stream. Delivering an ordered byte stream requires that an endpoint buffer any data that is received out of order, up to the advertised flow control limit.
エンドポイントは、順序付きバイトストリームとしてストリームデータをアプリケーションに配信できる必要があります。順序付けられたバイトストリームを配信するには、アドバタイズされたフロー制御の制限まで、順序から受信されたデータが任意のデータバッファを必要とする必要があります。
QUIC makes no specific allowances for delivery of stream data out of order. However, implementations MAY choose to offer the ability to deliver data out of order to a receiving application.
QUICは、ストリームデータを順番に配信するための特定の手当をしません。ただし、実装は、受信側アプリケーションに順番にデータを配信する能力を提供することを選択できます。
An endpoint could receive data for a stream at the same stream offset multiple times. Data that has already been received can be discarded. The data at a given offset MUST NOT change if it is sent multiple times; an endpoint MAY treat receipt of different data at the same offset within a stream as a connection error of type PROTOCOL_VIOLATION.
エンドポイントは、同じストリームオフセットを複数回オフセットしてストリームのデータを受信できます。すでに受信されているデータは破棄できます。与えられたオフセットのデータは、複数回送信された場合は変更しないでください。エンドポイントは、type PROTOCOL_VIOLATIONの接続エラーとして、ストリーム内の同じオフセットで異なるデータを受信することができます。
Streams are an ordered byte-stream abstraction with no other structure visible to QUIC. STREAM frame boundaries are not expected to be preserved when data is transmitted, retransmitted after packet loss, or delivered to the application at a receiver.
ストリームは、QUICに他の構造を表示しない順序付きバイトストリーム抽象化です。データが送信され、パケット損失の後に再送信されるか、受信機でアプリケーションに配信されるとき、ストリームフレームの境界は保持されることは期待されていません。
An endpoint MUST NOT send data on any stream without ensuring that it is within the flow control limits set by its peer. Flow control is described in detail in Section 4.
エンドポイントは、ピアによって設定されたフロー制御制限内にあることを確認せずに、ストリームにデータを送信してはなりません。フロー制御についてはセクション4で詳細に説明する。
Stream multiplexing can have a significant effect on application performance if resources allocated to streams are correctly prioritized.
ストリーム多重化は、ストリームに割り当てられているリソースが正しく優先される場合、アプリケーションのパフォーマンスに大きな影響を与える可能性があります。
QUIC does not provide a mechanism for exchanging prioritization information. Instead, it relies on receiving priority information from the application.
QUICは優先順位付け情報を交換するためのメカニズムを提供しません。代わりに、アプリケーションから優先度情報を受信することに依存しています。
A QUIC implementation SHOULD provide ways in which an application can indicate the relative priority of streams. An implementation uses information provided by the application to determine how to allocate resources to active streams.
QUIC実装は、アプリケーションがストリームの相対優先順位を示すことができる方法を提供するべきです。実装は、アプリケーションによって提供された情報を使用して、アクティブなストリームにリソースを割り当てる方法を決定します。
This document does not define an API for QUIC; it instead defines a set of functions on streams that application protocols can rely upon. An application protocol can assume that a QUIC implementation provides an interface that includes the operations described in this section. An implementation designed for use with a specific application protocol might provide only those operations that are used by that protocol.
この文書はQUIC用のAPIを定義しません。代わりに、アプリケーションプロトコルが依存できるストリーム上の一連の機能を定義します。アプリケーションプロトコルは、QUIC実装が、このセクションで説明されている操作を含むインターフェイスを提供すると仮定できます。特定のアプリケーションプロトコルで使用するように設計された実装は、そのプロトコルによって使用される操作のみを提供するかもしれません。
On the sending part of a stream, an application protocol can:
ストリームの送信部分では、次のことができます。
* write data, understanding when stream flow control credit (Section 4.1) has successfully been reserved to send the written data;
* データを書き込み、ストリームフロー制御クレジット（セクション4.1）が書き込まれたデータを送信するように予約されています。
* end the stream (clean termination), resulting in a STREAM frame (Section 19.8) with the FIN bit set; and
* ストリームを終了し (綺麗な終了)、FINビットを設定したストリームフレーム（セクション19.8）をもたらします。そして
* reset the stream (abrupt termination), resulting in a RESET_STREAM frame (Section 19.4) if the stream was not already in a terminal state.
* ストリームがまだ端末状態にない場合は、ストリームをリセットします (突然の終了)。
On the receiving part of a stream, an application protocol can:
ストリームの受信部分では、アプリケーションプロトコルが次のようにします。
* read data; and
* データを読み込む。そして
* abort reading of the stream and request closure, possibly resulting in a STOP_SENDING frame (Section 19.5).
* ストリームの読み取りを中止し、クローズを要求すると、STOP_SENDINGフレームが発生する可能性があります（セクション19.5）。
An application protocol can also request to be informed of state changes on streams, including when the peer has opened or reset a stream, when a peer aborts reading on a stream, when new data is available, and when data can or cannot be written to the stream due to flow control.
アプリケーションプロトコルは、相手がストリームを開いたりリセットしたりしたとき、相手がストリームを中止したとき、新しいデータが利用可能であるとき、および、フロー制御のためにデータをストリームに書き込むことができるときとできないときなどに、ストリームの状態変更を要求することがあります。
This section describes streams in terms of their send or receive components. Two state machines are described: one for the streams on which an endpoint transmits data (Section 3.1) and another for streams on which an endpoint receives data (Section 3.2).
このセクションでは、それらの送信または受信コンポーネントに関してストリームについて説明します。2つのステートマシンが説明されています。エンドポイントがデータを送信するストリーム（セクション3.1）とエンドポイントがデータを受信するストリーム（セクション3.2）。
Unidirectional streams use either the sending or receiving state machine, depending on the stream type and endpoint role. Bidirectional streams use both state machines at both endpoints. For the most part, the use of these state machines is the same whether the stream is unidirectional or bidirectional. The conditions for opening a stream are slightly more complex for a bidirectional stream because the opening of either the send or receive side causes the stream to open in both directions.
単方向ストリームは、ストリームタイプとエンドポイントの役割に応じて、送信ステートマシンまたは受信ステートマシンのいずれかを使用します。 双方向ストリームは、両方のエンドポイントで両方のステートマシンを使用します。ほとんどの場合、これらのステートマシンの使用は、ストリームが単方向であろうと双方向であろうと同じです。ストリームを開くための条件は、送信側または受信側のいずれかを開くとストリームが両方向に開くため、双方向ストリームの場合は少し複雑になります。
The state machines shown in this section are largely informative. This document uses stream states to describe rules for when and how different types of frames can be sent and the reactions that are expected when different types of frames are received. Though these state machines are intended to be useful in implementing QUIC, these states are not intended to constrain implementations. An implementation can define a different state machine as long as its behavior is consistent with an implementation that implements these states.
このセクションに示されている状態機械は主に有益です。このドキュメントはストリーム状態を使用して、さまざまな種類のフレームを送信できる場合と、異なる種類のフレームが受信されたときに予想される反応の規則を説明します。これらの状態機械はQUICを実装するのに役立つことを意図していますが、これらの状態は実装を制限することは意図していません。実装は、その動作がこれらの状態を実装する実装と一致している限り、異なるステートマシンを定義できます。
Note: In some cases, a single event or action can cause a transition through multiple states. For instance, sending STREAM with a FIN bit set can cause two state transitions for a sending stream: from the "Ready" state to the "Send" state, and from the "Send" state to the "Data Sent" state.
注：場合によっては、単一のイベントまたはアクションによって複数の状態が遷移することがあります。 たとえば、FINビットが設定されたSTREAMを送信すると、送信ストリームに対して2つの状態遷移が発生する可能性があります。「Ready」状態から「Send」状態へ、および「Send」状態から「DataSent」状態へです。
Figure 2 shows the states for the part of a stream that sends data to a peer.
図2は、ピアにデータを送信するストリームの一部の状態を示しています。
o
| Create Stream (Sending)
| Peer Creates Bidirectional Stream
v
+-------+
| Ready | Send RESET_STREAM
| |-----------------------.
+-------+ |
| |
| Send STREAM / |
| STREAM_DATA_BLOCKED |
v |
+-------+ |
| Send | Send RESET_STREAM |
| |---------------------->|
+-------+ |
| |
| Send STREAM + FIN |
v v
+-------+ +-------+
| Data | Send RESET_STREAM | Reset |
| Sent |------------------>| Sent |
+-------+ +-------+
| |
| Recv All ACKs | Recv ACK
v v
+-------+ +-------+
| Data | | Reset |
| Recvd | | Recvd |
+-------+ +-------+
Figure 2: States for Sending Parts of Streams
図2：ストリームの一部を送信するための状態
The sending part of a stream that the endpoint initiates (types 0 and 2 for clients, 1 and 3 for servers) is opened by the application. The "Ready" state represents a newly created stream that is able to accept data from the application. Stream data might be buffered in this state in preparation for sending.
エンドポイントが開始するストリームの送信部分（クライアントのタイプ0と2、サーバーの場合は1と3）がアプリケーションによって開かれます。「READY」状態は、アプリケーションからデータを受け入れることができる新しく作成されたストリームを表します。送信に備えてこの状態でストリームデータをバッファリングすることがあります。
Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a sending part of a stream to enter the "Send" state. An implementation might choose to defer allocating a stream ID to a stream until it sends the first STREAM frame and enters this state, which can allow for better stream prioritization.
最初のストリームまたはSTREAM_DATA_BLOCKEDフレームを送信すると、ストリームの送信部分が "Send"状態に入る。実装は、最初のストリームフレームを送信してこの状態を入力するまでストリームIDを割り当てることを選択することを選択できます。これにより、ストリーム優先順位付けを可能にします。
The sending part of a bidirectional stream initiated by a peer (type 0 for a server, type 1 for a client) starts in the "Ready" state when the receiving part is created.
ピアによって開始された双方向ストリームの送信部分（サーバのタイプ0、クライアントのタイプ1）は、受信側が作成されたときに「準備完了」状態で始まります。
In the "Send" state, an endpoint transmits -- and retransmits as necessary -- stream data in STREAM frames. The endpoint respects the flow control limits set by its peer and continues to accept and process MAX_STREAM_DATA frames. An endpoint in the "Send" state generates STREAM_DATA_BLOCKED frames if it is blocked from sending by stream flow control limits (Section 4.1).
「送信」状態では、エンドポイントは必要に応じてストリームフレームでストリームデータとして再送信する。エンドポイントは、そのピアによって設定されたフロー制御の制限を尊重し、MAX_STREAM_DATAフレームを受け入れて処理し続けます。「SEND」状態のエンドポイントは、ストリームフロー制御制限による送信からブロックされている場合（セクション4.1）、STREAM_DATA_BLOCKEDフレームを生成します。
After the application indicates that all stream data has been sent and a STREAM frame containing the FIN bit is sent, the sending part of the stream enters the "Data Sent" state. From this state, the endpoint only retransmits stream data as necessary. The endpoint does not need to check flow control limits or send STREAM_DATA_BLOCKED frames for a stream in this state. MAX_STREAM_DATA frames might be received until the peer receives the final stream offset. The endpoint can safely ignore any MAX_STREAM_DATA frames it receives from its peer for a stream in this state.
アプリケーションがすべてのストリームデータが送信され、FINビットを含むストリームフレームが送信されたことを示す後、ストリームの送信部分は「データ送信」状態に入ります。この状態から、エンドポイントは必要に応じてストリームデータのみを再送信します。エンドポイントは、この状態のストリームのフロー制御の制限またはSTREAM_DATA_BLOCKEDフレームをチェックする必要はありません。MAX_STREAM_DATAは、ピアが最終ストリームオフセットを受信するまで受信される可能性があります。この状態で、エンドポイントは、そのピアからそのピアを受信したMAX_STREAM_DATAフレームを安全に無視できます。
Once all stream data has been successfully acknowledged, the sending part of the stream enters the "Data Recvd" state, which is a terminal state.
すべてのストリームデータが正常に確認応答されると、ストリームの送信部分は端末状態である「Data Recvd」状態を入力します。
From any state that is one of "Ready", "Send", or "Data Sent", an application can signal that it wishes to abandon transmission of stream data. Alternatively, an endpoint might receive a STOP_SENDING frame from its peer. In either case, the endpoint sends a RESET_STREAM frame, which causes the stream to enter the "Reset Sent" state.
「準備完了」、「送信」、または「データ送信」のいずれかである任意の状態から、アプリケーションはストリームデータの送信を放棄したいことを知らせることができます。あるいは、エンドポイントはそのピアからSTOP_SENDINGフレームを受信することがあります。どちらの場合でも、エンドポイントはRESET_STREAMフレームを送信します。これにより、ストリームは「Reset Sent」状態に入ります。
An endpoint MAY send a RESET_STREAM as the first frame that mentions a stream; this causes the sending part of that stream to open and then immediately transition to the "Reset Sent" state.
エンドポイントは、ストリームを指す最初のフレームとしてRESET_STREMを送信することができます。これにより、そのストリームの送信部分が開き、次に「リセット送信」状態に移行します。
Once a packet containing a RESET_STREAM has been acknowledged, the sending part of the stream enters the "Reset Recvd" state, which is a terminal state.
RESET_STREAMを含むパケットが確認応答されると、ストリームの送信部分は端末状態である「Reset Recvd」状態を入力します。
Figure 3 shows the states for the part of a stream that receives data from a peer. The states for a receiving part of a stream mirror only some of the states of the sending part of the stream at the peer. The receiving part of a stream does not track states on the sending part that cannot be observed, such as the "Ready" state. Instead, the receiving part of a stream tracks the delivery of data to the application, some of which cannot be observed by the sender.
図3は、ピアからデータを受信するストリームの一部の状態を示しています。ストリームの受信部分の状態は、ピアのストリームの送信部分のいくつかの状態だけをミラーリングします。ストリームの受信部分は、「準備完了」状態など、観察できない送信部分の状態を追跡しない。代わりに、ストリームの受信部分はアプリケーションへのデータの配信を追跡します。そのうちのいくつかは送信者によって観察されません。
o
| Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
| Create Bidirectional Stream (Sending)
| Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional)
| Create Higher-Numbered Stream
v
+-------+
| Recv | Recv RESET_STREAM
| |-----------------------.
+-------+ |
| |
| Recv STREAM + FIN |
v |
+-------+ |
| Size | Recv RESET_STREAM |
| Known |---------------------->|
+-------+ |
| |
| Recv All Data |
v v
+-------+ Recv RESET_STREAM +-------+
| Data |--- (optional) --->| Reset |
| Recvd | Recv All Data | Recvd |
+-------+<-- (optional) ----+-------+
| |
| App Read All Data | App Read Reset
v v
+-------+ +-------+
| Data | | Reset |
| Read | | Read |
+-------+ +-------+
Figure 3: States for Receiving Parts of Streams
図3：ストリームの一部を受信するための状態
The receiving part of a stream initiated by a peer (types 1 and 3 for a client, or 0 and 2 for a server) is created when the first STREAM, STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that stream. For bidirectional streams initiated by a peer, receipt of a MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the stream also creates the receiving part. The initial state for the receiving part of a stream is "Recv".
ピアによって開始されたストリームの受信部分（クライアントのタイプ1および3、またはサーバの場合は0および2）によって開始されるストリームは、最初のストリーム、STREAM_DATA_BLOCKED、またはRESET_STREAMフレームがそのストリームに対して受信されると作成されます。ピアによって開始された双方向ストリームの場合、ストリームの送信部分のMAX_STREAM_DATAまたはSTOP_SENDINGフレームの受信も受信側を作成する。ストリームの受信部分の初期状態は「RECV」です。
For a bidirectional stream, the receiving part enters the "Recv" state when the sending part initiated by the endpoint (type 0 for a client, type 1 for a server) enters the "Ready" state.
双方向ストリームの場合、エンドポイントによって開始された送信部分（クライアントのタイプ0、サーバのタイプ1）が「準備完了」状態に入るときに、受信側は「RECV」状態に入ります。
An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or STOP_SENDING frame is received from the peer for that stream. Receiving a MAX_STREAM_DATA frame for an unopened stream indicates that the remote peer has opened the stream and is providing flow control credit. Receiving a STOP_SENDING frame for an unopened stream indicates that the remote peer no longer wishes to receive data on this stream. Either frame might arrive before a STREAM or STREAM_DATA_BLOCKED frame if packets are lost or reordered.
エンドポイントは、MAX_STREAM_DATAまたはSTOP_SENDINGフレームがそのストリームのピアから受信されると、双方向ストリームを開きます。未開封のストリームのMAX_STREAM_DATAフレームを受信すると、リモートピアがストリームを開き、フロー制御クレジットを提供していることを示します。未開封のストリームのSTOP_SENDINGフレームを受信すると、リモートピアがこのストリームのデータを受信したくないことを示します。パケットが紛失または並べ替えられている場合、どちらのフレームもSTREAM_DATA_BLOCKEDフレームの前に到着する可能性があります。
Before a stream is created, all streams of the same type with lower-numbered stream IDs MUST be created. This ensures that the creation order for streams is consistent on both endpoints.
ストリームが作成される前に、小さい番号のストリームIDを持つ同じタイプのすべてのストリームを作成する必要があります。これにより、ストリームの作成順序が両方のエンドポイントで一貫していることを確認します。
In the "Recv" state, the endpoint receives STREAM and STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be reassembled into the correct order for delivery to the application. As data is consumed by the application and buffer space becomes available, the endpoint sends MAX_STREAM_DATA frames to allow the peer to send more data.
「RECV」状態では、エンドポイントはストリームとSTREAM_DATA_BLOCKEDフレームを受け取ります。着信データはバッファされており、アプリケーションへの配信のために正しい順序に再組み立てできます。データがアプリケーションとバッファスペースによって消費されると、エンドポイントはMAX_STREAM_DATAフレームを送信してピアがより多くのデータを送信できるようにします。
When a STREAM frame with a FIN bit is received, the final size of the stream is known; see Section 4.5. The receiving part of the stream then enters the "Size Known" state. In this state, the endpoint no longer needs to send MAX_STREAM_DATA frames; it only receives any retransmissions of stream data.
フィンビットを有するストリームフレームが受信されると、ストリームの最終サイズは知られている。セクション4.5を参照してください。その後、ストリームの受信部分は「サイズの既知」状態に入る。この状態では、エンドポイントはmax_stream_dataフレームを送信する必要がなくなります。ストリームデータの再送信だけを受信します。
Once all data for the stream has been received, the receiving part enters the "Data Recvd" state. This might happen as a result of receiving the same STREAM frame that causes the transition to "Size Known". After all data has been received, any STREAM or STREAM_DATA_BLOCKED frames for the stream can be discarded.
ストリームのすべてのデータが受信されると、受信側は「Data Recvd」状態に入ります。これは、「サイズの既知」への移行を引き起こす同じストリームフレームを受信した結果として発生する可能性があります。すべてのデータが受信された後、ストリームのストリームまたはSTREAM_DATA_BLOCKEDフレームを破棄することができます。
The "Data Recvd" state persists until stream data has been delivered to the application. Once stream data has been delivered, the stream enters the "Data Read" state, which is a terminal state.
「受信された」状態は、ストリームデータがアプリケーションに配信されるまで持続します。ストリームデータが配信されると、ストリームは端末状態である「データ読み取り」状態を入力します。
Receiving a RESET_STREAM frame in the "Recv" or "Size Known" state causes the stream to enter the "Reset Recvd" state. This might cause the delivery of stream data to the application to be interrupted.
「RECV」または「既知の」状態でRESET_STREAMフレームを受信すると、ストリームが「RESE RESVD」状態に入る。これにより、アプリケーションへのストリームデータの配信が中断される可能性があります。
It is possible that all stream data has already been received when a RESET_STREAM is received (that is, in the "Data Recvd" state). Similarly, it is possible for remaining stream data to arrive after receiving a RESET_STREAM frame (the "Reset Recvd" state). An implementation is free to manage this situation as it chooses.
RESET_STREAMが受信されたとき（つまり、「Data Recvd」状態で）受信したときに、すべてのストリームデータが既に受信されている可能性があります。同様に、RESET_STREAMフレーム（「リセットRECVD」状態）を受信した後に残りのストリームデータが到着することが可能である。この状況は選択されているため、実装は自由に管理できます。
Sending a RESET_STREAM means that an endpoint cannot guarantee delivery of stream data; however, there is no requirement that stream data not be delivered if a RESET_STREAM is received. An implementation MAY interrupt delivery of stream data, discard any data that was not consumed, and signal the receipt of the RESET_STREAM. A RESET_STREAM signal might be suppressed or withheld if stream data is completely received and is buffered to be read by the application. If the RESET_STREAM is suppressed, the receiving part of the stream remains in "Data Recvd".
reset_streamの送信は、エンドポイントがストリームデータの配信を保証できないことを意味します。しかしながら、RESET_STREAMが受信された場合にストリームデータが配信されないという要件はない。実装はストリームデータの配信を中断し、消費されていないデータを破棄し、RESET_STREAMの受信を通知することができます。ストリームデータが完全に受信され、アプリケーションによって読み取られるようにバッファされている場合、RESET_STREAM信号を抑制または抑制することができます。RESET_STREAMが抑制されている場合、ストリームの受信部分は「Data Recvd」のままです。
Once the application receives the signal indicating that the stream was reset, the receiving part of the stream transitions to the "Reset Read" state, which is a terminal state.
アプリケーションがストリームがリセットされたことを示す信号を受信すると、ストリームの受信部分は端末状態である「リセット読み出し」状態に遷移する。
The sender of a stream sends just three frame types that affect the state of a stream at either the sender or the receiver: STREAM (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM (Section 19.4).
ストリームの送信者は、送信者または受信者：Stream（セクション19.8）、Stream_Data_Blocked（セクション19.13）、およびRESET_STREM（セクション19.4）のいずれかのストリームの状態に影響を与える3つのフレームタイプだけを送信します。
A sender MUST NOT send any of these frames from a terminal state ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send a STREAM or STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or any terminal state -- that is, after sending a RESET_STREAM frame. A receiver could receive any of these three frames in any state, due to the possibility of delayed delivery of packets carrying them.
送信者は、端末状態（「Data Recvd」または「RESET RESVD」）からこれらのフレームを送信してはいけません。送信者は、 "RESET SENT"状態または任意の端末状態、つまりRESET_STREAMフレームを送信した後のストリームのストリームまたはSTREAM_DATA_BLOCKEDフレームを送信してはなりません。受信機は、それらを伝送するパケットの配信が遅れる可能性のために、任意の3つのフレームのいずれかを受信することができる。
The receiver of a stream sends MAX_STREAM_DATA frames (Section 19.10) and STOP_SENDING frames (Section 19.5).
ストリームの受信側はMAX_STREAM_DATAフレーム（セクション19.10）とSTOP_SENDINGフレームを送信します（セクション19.5）。
The receiver only sends MAX_STREAM_DATA frames in the "Recv" state. A receiver MAY send a STOP_SENDING frame in any state where it has not received a RESET_STREAM frame -- that is, states other than "Reset Recvd" or "Reset Read". However, there is little value in sending a STOP_SENDING frame in the "Data Recvd" state, as all stream data has been received. A sender could receive either of these two types of frames in any state as a result of delayed delivery of packets.
受信機は「RECV」状態にあるMAX_STREAM_DATAフレームのみを送信します。受信機は、RESET_STREAMフレームを受信していない状態でSTOP_SENDINGフレームを送信してもよい。つまり、「RESECVDVD」または「リセットリード」以外の状態である。しかしながら、全てのストリームデータが受信されたので、「Data Recvd」状態に停止フレームを送信する際の値はほとんどない。送信者は、パケットの配信遅延の結果として、任意の状態でこれら2種類のフレームのいずれかを受信することができます。
A bidirectional stream is composed of sending and receiving parts. Implementations can represent states of the bidirectional stream as composites of sending and receiving stream states. The simplest model presents the stream as "open" when either sending or receiving parts are in a non-terminal state and "closed" when both sending and receiving streams are in terminal states.
双方向ストリームは、送受信部品からなる。実装は、ストリーム状態を送受信する複合材料としての双方向ストリームの状態を表すことができる。最も単純なモデルは、送受信部のいずれかが非端末状態にあるときに「open」としてストリームを表示し、送信ストリームと受信側の両方の状態が端末状態にあるときに「closed」と表示されます。
Table 2 shows a more complex mapping of bidirectional stream states that loosely correspond to the stream states defined in HTTP/2 [HTTP2]. This shows that multiple states on sending or receiving parts of streams are mapped to the same composite state. Note that this is just one possibility for such a mapping; this mapping requires that data be acknowledged before the transition to a "closed" or "half-closed" state.
表2は、HTTP/2 [http2]で定義されているストリーム状態に緩く対応する双方向ストリーム状態のより複雑なマッピングを示しています。これは、ストリームの一部を送受信するための複数の状態が同じ複合状態にマッピングされていることを示しています。これはそのようなマッピングのための1つの可能性だけです。このマッピングでは、「closed」または「half-closed」状態への移行前にデータを確認する必要があります。
+===================+=======================+=================+
| Sending Part | Receiving Part | Composite State |
+===================+=======================+=================+
| No Stream / Ready | No Stream / Recv (*1) | idle |
+-------------------+-----------------------+-----------------+
| Ready / Send / | Recv / Size Known | open |
| Data Sent | | |
+-------------------+-----------------------+-----------------+
| Ready / Send / | Data Recvd / Data | half-closed |
| Data Sent | Read | (remote) |
+-------------------+-----------------------+-----------------+
| Ready / Send / | Reset Recvd / Reset | half-closed |
| Data Sent | Read | (remote) |
+-------------------+-----------------------+-----------------+
| Data Recvd | Recv / Size Known | half-closed |
| | | (local) |
+-------------------+-----------------------+-----------------+
| Reset Sent / | Recv / Size Known | half-closed |
| Reset Recvd | | (local) |
+-------------------+-----------------------+-----------------+
| Reset Sent / | Data Recvd / Data | closed |
| Reset Recvd | Read | |
+-------------------+-----------------------+-----------------+
| Reset Sent / | Reset Recvd / Reset | closed |
| Reset Recvd | Read | |
+-------------------+-----------------------+-----------------+
| Data Recvd | Data Recvd / Data | closed |
| | Read | |
+-------------------+-----------------------+-----------------+
| Data Recvd | Reset Recvd / Reset | closed |
| | Read | |
+-------------------+-----------------------+-----------------+
Table 2: Possible Mapping of Stream States to HTTP/2
表2：ストリーム状態のhttp/2へのマッピング
Note (*1): A stream is considered "idle" if it has not yet been created or if the receiving part of the stream is in the "Recv" state without yet having received any frames.
注（*1）：ストリームがまだ作成されていない場合、またはストリームの受信部分がまだフレームを受信していない状態で「Recv」状態にある場合、ストリームは「idle」と見なされます。
If an application is no longer interested in the data it is receiving on a stream, it can abort reading the stream and specify an application error code.
アプリケーションがストリームで受信しているデータに関心がなくなった場合は、ストリームの読み取りを中止してアプリケーションエラーコードを指定できます。
If the stream is in the "Recv" or "Size Known" state, the transport SHOULD signal this by sending a STOP_SENDING frame to prompt closure of the stream in the opposite direction. This typically indicates that the receiving application is no longer reading data it receives from the stream, but it is not a guarantee that incoming data will be ignored.
ストリームが「RECV」または「サイズの既知」状態にある場合、トランスポートは、ストリームを反対方向に閉じるように停止するためにSTOP_SENDINGフレームを送信することによってこれをシグナリングする必要があります。これは通常、受信側アプリケーションがストリームから受信したデータを読み取っていないことを示しますが、着信データが無視されるのは保証されません。
STREAM frames received after sending a STOP_SENDING frame are still counted toward connection and stream flow control, even though these frames can be discarded upon receipt.
STOP_SENDINGフレームを送信した後に受信されたストリームフレームは、受信時にこれらのフレームを破棄することができるとしても、接続およびストリームフロー制御に依存します。
A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM frame if the stream is in the "Ready" or "Send" state. If the stream is in the "Data Sent" state, the endpoint MAY defer sending the RESET_STREAM frame until the packets containing outstanding data are acknowledged or declared lost. If any outstanding data is declared lost, the endpoint SHOULD send a RESET_STREAM frame instead of retransmitting the data.
STOP_SENDINGフレームは、受信側エンドポイントがRESET_STREAMフレームを送信するように要求します。STOP_SENDINGフレームを受信するエンドポイントは、ストリームが "Ready"または "Send"状態にある場合はRESET_STREAMフレームを送信する必要があります。ストリームが「データ送信」状態にある場合、エンドポイントは、未処理データを含むパケットが失われたか宣言されるまで、RESET_STREAMフレームの送信を延期することがあります。未処理のデータが失われた場合、データを再送信する代わりに、エンドポイントはRESET_STREAMフレームを送信する必要があります。
An endpoint SHOULD copy the error code from the STOP_SENDING frame to the RESET_STREAM frame it sends, but it can use any application error code. An endpoint that sends a STOP_SENDING frame MAY ignore the error code in any RESET_STREAM frames subsequently received for that stream.
エンドポイントは、STOP_SENDINGフレームからERRORコードを送信するRESET_STREAMフレームにコピーする必要がありますが、任意のアプリケーションエラーコードを使用できます。stop_seandingフレームを送信するエンドポイントは、そのストリームに対してその後受信された任意のRESET_STREAMフレーム内のエラーコードを無視することができる。
STOP_SENDING SHOULD only be sent for a stream that has not been reset by the peer. STOP_SENDING is most useful for streams in the "Recv" or "Size Known" state.
STOP_SENDINGは、ピアによってリセットされていないストリームに対してのみ送信されるべきです。STOP_SENDINGは、「RECV」または「既知の」状態のストリームに最も役立ちます。
An endpoint is expected to send another STOP_SENDING frame if a packet containing a previous STOP_SENDING is lost. However, once either all stream data or a RESET_STREAM frame has been received for the stream -- that is, the stream is in any state other than "Recv" or "Size Known" -- sending a STOP_SENDING frame is unnecessary.
前のSTOP_SENDINGを含むパケットが失われた場合、エンドポイントは別のSTOP_SENDINGフレームを送信すると予想されます。しかし、ストリームに対して全てのストリームデータまたはRESET_STREAMフレームが受信されると、ストリームは「RECV」以外の状態にある、または「既知の」 - STOP_SENDINGフレームを送信することは不要である。
An endpoint that wishes to terminate both directions of a bidirectional stream can terminate one direction by sending a RESET_STREAM frame, and it can encourage prompt termination in the opposite direction by sending a STOP_SENDING frame.
双方向ストリームの両方向を終了させることを望むエンドポイントは、RESET_STREAMフレームを送信することによって一方向を終了することができ、停止フレームを送信することによって反対方向に迅速な終了を促すことができる。
Receivers need to limit the amount of data that they are required to buffer, in order to prevent a fast sender from overwhelming them or a malicious sender from consuming a large amount of memory. To enable a receiver to limit memory commitments for a connection, streams are flow controlled both individually and across a connection as a whole. A QUIC receiver controls the maximum amount of data the sender can send on a stream as well as across all streams at any time, as described in Sections 4.1 and 4.2.
受信者は、ファスト送信者が圧倒的な送信者または悪意のある送信者が大量のメモリを消費するのを防ぐために、それらがバッファに必要なデータ量を制限する必要があります。受信機が接続のためにメモリコミットメントを制限することを可能にするために、ストリームは全体として個別におよび接続を両方ともフロー制御される。QUIC受信機は、セクション4.1および4.2で説明されているように、送信者がすべてのストリーム上で送信できるデータの最大量を制御できます。
Similarly, to limit concurrency within a connection, a QUIC endpoint controls the maximum cumulative number of streams that its peer can initiate, as described in Section 4.6.
同様に、接続内の並行性を制限するために、QUICエンドポイントは、セクション4.6で説明されているように、そのピアが開始できるストリームの最大累積数を制御します。
Data sent in CRYPTO frames is not flow controlled in the same way as stream data. QUIC relies on the cryptographic protocol implementation to avoid excessive buffering of data; see [QUIC-TLS]. To avoid excessive buffering at multiple layers, QUIC implementations SHOULD provide an interface for the cryptographic protocol implementation to communicate its buffering limits.
暗号フレームで送信されたデータは、ストリームデータと同じ方法でフロー制御されません。QUICは、データの過度のバッファリングを回避するために、暗号プロトコル実装に依存しています。[QUIC-TLS]を参照してください。複数の層で過度のバッファリングを回避するために、QUICの実装は暗号プロトコル実装のためのインタフェースを提供して、そのバッファリングの制限を伝達する必要があります。
QUIC employs a limit-based flow control scheme where a receiver advertises the limit of total bytes it is prepared to receive on a given stream or for the entire connection. This leads to two levels of data flow control in QUIC:
QUICは、受信機が所与のストリームまたは接続全体で受信する準備ができている合計バイトの限界を広告する限界ベースのフロー制御方式を採用しています。これにより、QUICの2つのレベルのデータフロー制御が可能になります。
* Stream flow control, which prevents a single stream from consuming the entire receive buffer for a connection by limiting the amount of data that can be sent on each stream.
* ストリームフロー制御。各ストリームで送信できるデータ量を制限することによって、単一のストリームが接続のために受信バッファ全体を消費するのを防ぎます。
* Connection flow control, which prevents senders from exceeding a receiver's buffer capacity for the connection by limiting the total bytes of stream data sent in STREAM frames on all streams.
* 接続フロー制御。すべてのストリームでストリームフレームで送信されたストリームデータの総バイトを制限することで、送信者が接続の受信機のバッファ容量を超えないようにする。
Senders MUST NOT send data in excess of either limit.
送信者はどちらの制限を超えてデータを送信してはいけません。
A receiver sets initial limits for all streams through transport parameters during the handshake (Section 7.4). Subsequently, a receiver sends MAX_STREAM_DATA frames (Section 19.10) or MAX_DATA frames (Section 19.9) to the sender to advertise larger limits.
受信者は、ハンドシェイク中にトランスポートパラメータを介してすべてのストリームの初期制限を設定します（セクション7.4）。その後、受信機は、MAX_STREAM_DATAフレーム（セクション19.10）またはMAX_DATAフレーム（セクション19.9）を送信者に送信して、大きな制限をアドバタイズします。
A receiver can advertise a larger limit for a stream by sending a MAX_STREAM_DATA frame with the corresponding stream ID. A MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a stream. A receiver could determine the flow control offset to be advertised based on the current offset of data consumed on that stream.
受信機は、対応するストリームIDを用いてMAX_STREAM_DATAフレームを送信することによってストリームに対してより大きな制限をアドバタイズすることができる。max_stream_dataフレームは、ストリームの最大絶対バイトオフセットを示します。受信機は、そのストリーム上で消費されるデータの現在のオフセットに基づいて宣伝されるべきフロー制御オフセットを決定することができる。
A receiver can advertise a larger limit for a connection by sending a MAX_DATA frame, which indicates the maximum of the sum of the absolute byte offsets of all streams. A receiver maintains a cumulative sum of bytes received on all streams, which is used to check for violations of the advertised connection or stream data limits. A receiver could determine the maximum data limit to be advertised based on the sum of bytes consumed on all streams.
受信機は、MAX_DATAフレームを送信することによって接続のためのより大きな制限をアドバタイズすることができ、これは、すべてのストリームの絶対バイトオフセットの合計の最大値を示す。受信機は、アドバタイズされた接続またはストリームのデータ制限の違反をチェックするために使用されるすべてのストリームで受信されたバイトの累積的なバイト数を維持します。受信機は、すべてのストリームで消費されるバイトの合計に基づいて宣伝される最大データ制限を決定することができます。
Once a receiver advertises a limit for the connection or a stream, it is not an error to advertise a smaller limit, but the smaller limit has no effect.
受信機が接続またはストリームの制限をアドバタイズすると、小さい制限をアドバタイズするためのエラーではありませんが、小さい制限は効果がありません。
A receiver MUST close the connection with an error of type FLOW_CONTROL_ERROR if the sender violates the advertised connection or stream data limits; see Section 11 for details on error handling.
送信者がアドバタイズされた接続またはストリームのデータ制限に違反した場合、受信機はFLOW_CONTROL_ERROR型のエラーとの接続を閉じる必要があります。エラー処理の詳細については11を参照してください。
A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do not increase flow control limits.
送信者は、フロー制御の制限を増加させないMAX_STREAM_DATAまたはMAX_DATAフレームを無視する必要があります。
If a sender has sent data up to the limit, it will be unable to send new data and is considered blocked. A sender SHOULD send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver that it has data to write but is blocked by flow control limits. If a sender is blocked for a period longer than the idle timeout (Section 10.1), the receiver might close the connection even when the sender has data that is available for transmission. To keep the connection from closing, a sender that is flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it has no ack-eliciting packets in flight.
送信者がデータを制限まで送信した場合は、新しいデータを送信できなくなり、ブロックされていると見なされます。送信者は、書き込みのデータがあるがフロー制御の制限によってブロックされていることを受信側に示すようにStream_Data_BlockedまたはData_Blockedフレームを送信する必要があります。送信者がアイドルタイムアウトより長い期間ブロックされている場合（セクション10.1）、送信者が送信に利用可能なデータがある場合でも、受信者は接続を閉じることがあります。接続を閉じることから、フロー制御制限である送信者は、飛行中にACKエリチコットパケットを持たない場合は、Stream_Data_BlockedまたはData_Blockedフレームを定期的に送信する必要があります。
Implementations decide when and how much credit to advertise in MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few considerations.
実装は、MAX_STREAM_DATAおよびMAX_DATAフレームでアドバタイズするかどうかとどのくらいのクレジットを決定しますが、このセクションではいくつかの考慮事項があります。
To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or MAX_DATA frame multiple times within a round trip or send it early enough to allow time for loss of the frame and subsequent recovery.
送信者をブロックするのを避けるために、受信者は、往復の中でMAX_STREAM_DATAまたはMAX_DATAフレームを複数回送信したり、フレームの損失とそれに続く回復の時間を許可するのに十分早く送信することができます。
Control frames contribute to connection overhead. Therefore, frequently sending MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable. On the other hand, if updates are less frequent, larger increments to limits are necessary to avoid blocking a sender, requiring larger resource commitments at the receiver. There is a trade-off between resource commitment and overhead when determining how large a limit is advertised.
制御フレームは接続オーバーヘッドに寄与する。したがって、頻繁にMAX_STREAM_DATAおよびMAX_DATAフレームが小さな変更を加えて望ましくない。一方、更新が少ない場合は、送信者をブロックするのを避けるために、より大きな増分が必要であり、受信側でより大きなリソースコミットメントを必要とする必要があります。限界が広告されているかを判断するときに、リソースのコミットメントとオーバーヘッドの間にトレードオフがあります。
A receiver can use an autotuning mechanism to tune the frequency and amount of advertised additional credit based on a round-trip time estimate and the rate at which the receiving application consumes data, similar to common TCP implementations. As an optimization, an endpoint could send frames related to flow control only when there are other frames to send, ensuring that flow control does not cause extra packets to be sent.
受信機は、共通のTCP実装と同様に、往復時間推定値と受信アプリケーションがデータを消費するレートとに基づいて、アドバタイズされた追加クレジットの周波数と量を調整するために自動操作機構を使用することができる。最適化として、エンドポイントはフロー制御に関連するフレームを送信することができ、フロー制御が追加のパケットを送信させないようにすることができないようにします。
A blocked sender is not required to send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the sender being blocked for the rest of the connection. Even if the sender sends these frames, waiting for them will result in the sender being blocked for at least an entire round trip.
ブロックされた送信者は、stream_data_blockedまたはdata_blockedフレームを送信する必要はありません。したがって、MAX_STREAM_DATAまたはMAX_DATAフレームを送信する前に、受信機はSTREAM_DATA_BLOCKEDまたはDATA_BLOCKEDフレームを待機してはいけません。そのようにして、送信者が残りの接続のためにブロックされている可能性があります。送信者がこれらのフレームを送信しても、それらを待っても送信者は少なくとも往復の全体のためにブロックされています。
When a sender receives credit after being blocked, it might be able to send a large amount of data in response, resulting in short-term congestion; see Section 7.7 of [QUIC-RECOVERY] for a discussion of how a sender can avoid this congestion.
送信者がブロックされた後にクレジットを受信すると、大量のデータを応答して送信できる可能性があり、その結果、短期間の輻輳が発生します。送信者がこの輻輳を回避できる方法については、[QUIC-Recovery]のセクション7.7を参照してください。
If an endpoint cannot ensure that its peer always has available flow control credit that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by flow control.
この接続でピアの帯域幅遅延積よりも大きい、ピアがピアの帯域幅遅延製品より大きい使用可能なフロー制御クレジットを常に使用できるようにすることができない場合、その受信スループットはフロー制御によって制限されます。
Packet loss can cause gaps in the receive buffer, preventing the application from consuming data and freeing up receive buffer space.
パケット損失は受信バッファにギャップを引き起こし、アプリケーションがデータを消費し、受信バッファスペースを解放するのを防ぐことができます。
Sending timely updates of flow control limits can improve performance. Sending packets only to provide flow control updates can increase network load and adversely affect performance. Sending flow control updates along with other frames, such as ACK frames, reduces the cost of those updates.
フロー制御の制限のタイムリーな更新を送信すると、パフォーマンスが向上します。フロー制御の更新を提供するためだけにパケットを送信することで、ネットワーク負荷を増やし、パフォーマンスに悪影響を及ぼす可能性があります。ACKフレームなどの他のフレームとともにフロー制御の更新を送信すると、それらの更新のコストが削減されます。
Endpoints need to eventually agree on the amount of flow control credit that has been consumed on every stream, to be able to account for all bytes for connection-level flow control.
エンドポイントは、接続レベルのフロー制御のためのすべてのバイトを考慮することができるように、すべてのストリームで消費されたフロー制御クレジットの量について最終的に同意する必要があります。
On receipt of a RESET_STREAM frame, an endpoint will tear down state for the matching stream and ignore further data arriving on that stream.
RESET_STREAMフレームを受信すると、エンドポイントはマッチングストリームに対して状態を引き下げ、そのストリームに到着するさらなるデータを無視します。
RESET_STREAM terminates one direction of a stream abruptly. For a bidirectional stream, RESET_STREAM has no effect on data flow in the opposite direction. Both endpoints MUST maintain flow control state for the stream in the unterminated direction until that direction enters a terminal state.
reset_streamはストリームの一方向を突然終了します。双方向ストリームの場合、reset_streamは反対方向のデータフローには影響しません。どちらのエンドポイントも、その方向が端末状態になるまで、終了した方向のストリームのフロー制御状態を維持する必要があります。
The final size is the amount of flow control credit that is consumed by a stream. Assuming that every contiguous byte on the stream was sent once, the final size is the number of bytes sent. More generally, this is one higher than the offset of the byte with the largest offset sent on the stream, or zero if no bytes were sent.
最終的なサイズは、ストリームによって消費されるフロー制御クレジットの量です。ストリーム上のすべての連続バイトが1回送信されたと仮定すると、最終的なサイズは送信されたバイト数です。より一般的には、これは、ストリームで送信された最大のオフセットを持つバイトのオフセットより1つずつ、バイトが送信されていない場合はゼロです。
A sender always communicates the final size of a stream to the receiver reliably, no matter how the stream is terminated. The final size is the sum of the Offset and Length fields of a STREAM frame with a FIN flag, noting that these fields might be implicit. Alternatively, the Final Size field of a RESET_STREAM frame carries this value. This guarantees that both endpoints agree on how much flow control credit was consumed by the sender on that stream.
送信者は、ストリームがどのように終了しても、常にストリームの最終サイズを確実に受信機に伝達します。最終的なサイズは、これらのフィールドが暗黙的になる可能性があることに注目して、FINフラグを持つストリームフレームのオフセットフィールドと長さフィールドの合計です。あるいは、RESET_STREAMフレームの最終サイズフィールドはこの値を搬送する。これにより、両方のエンドポイントがそのストリーム上の送信者によってどのようなフロー制御クレジットがどれだけ消費されたかについて一致することを保証します。
An endpoint will know the final size for a stream when the receiving part of the stream enters the "Size Known" or "Reset Recvd" state (Section 3). The receiver MUST use the final size of the stream to account for all bytes sent on the stream in its connection-level flow controller.
エンドポイントは、ストリームの受信部分が「サイズが既知の」または「RESET RECVD」状態に入るときのストリームの最終サイズを知っている（セクション3）。受信者は、接続レベルフローコントローラのストリームで送信されたすべてのバイトを考慮して、ストリームの最終サイズを使用する必要があります。
An endpoint MUST NOT send data on a stream at or beyond the final size.
エンドポイントは、最後のサイズ以上のストリームにデータを送信してはなりません。
Once a final size for a stream is known, it cannot change. If a RESET_STREAM or STREAM frame is received indicating a change in the final size for the stream, an endpoint SHOULD respond with an error of type FINAL_SIZE_ERROR; see Section 11 for details on error handling. A receiver SHOULD treat receipt of data at or beyond the final size as an error of type FINAL_SIZE_ERROR, even after a stream is closed. Generating these errors is not mandatory, because requiring that an endpoint generate these errors also means that the endpoint needs to maintain the final size state for closed streams, which could mean a significant state commitment.
ストリームの最後のサイズがわかったら、変更できません。ストリームの最終サイズの変更を示すRESET_STREAMまたはSTREAMフレームを受信した場合、エンドポイントはFINAL_SIZE_ERROR型のエラーで応答する必要があります。エラー処理の詳細については11を参照してください。受信機は、ストリームが閉じられた後でさえも、FINAL_SIZE_ERROR型のエラーとして最終サイズを超えてデータの受信を扱う必要があります。これらのエラーを生成することはこれらのエラーを生成する必要があるため、エンドポイントがクローズドストリームの最終サイズ状態を維持する必要があることを意味するため、必須ではありません。
An endpoint limits the cumulative number of incoming streams a peer can open. Only streams with a stream ID less than "(max_streams * 4 + first_stream_id_of_type)" can be opened; see Table 1. Initial limits are set in the transport parameters; see Section 18.2. Subsequent limits are advertised using MAX_STREAMS frames; see Section 19.11. Separate limits apply to unidirectional and bidirectional streams.
エンドポイントは、ピアが開くことができる着信ストリームの累積数を制限します。ストリームIDを持つストリームのみ "（max_streams * 4 first_stream_id_of_of_type）"を開くことができます。表1.トランスポートパラメータに初期制限が設定されています。18.2節を参照してください。その後の制限はMAX_STREAMSフレームを使用してアドバタイズされます。19.11節を参照してください。単方向ストリームおよび双方向ストリームには別の制限が適用されます。
If a max_streams transport parameter or a MAX_STREAMS frame is received with a value greater than 2^60, this would allow a maximum stream ID that cannot be expressed as a variable-length integer; see Section 16. If either is received, the connection MUST be closed immediately with a connection error of type TRANSPORT_PARAMETER_ERROR if the offending value was received in a transport parameter or of type FRAME_ENCODING_ERROR if it was received in a frame; see Section 10.2.
MAX_STREAMSトランスポートパラメータまたはMAX_STREAMSフレームが2 ^ 60より大きい値で受信された場合、これは可変長整数として表現できない最大ストリームIDを可能にする。16節を参照してください。どちらのどちらかを受け取られた場合は、トランスポートパラメータまたはフレーム内で受信された場合、Autformingの値を受信した場合は、TRANSPORT_PARAMETER_ERROR型の接続エラーで直ちに接続を閉じる必要があります。10.2項を参照してください。
Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a frame with a stream ID exceeding the limit it has sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR; see Section 11 for details on error handling.
エンドポイントは、ピアによって設定された制限を超えてはいけません。ストリームIDを持つフレームを受信したエンドポイントは、送信された制限を超えています。これをSTREAM_LIMIT_ERROR型の接続エラーとして扱う必要があります。エラー処理の詳細については11を参照してください。
Once a receiver advertises a stream limit using the MAX_STREAMS frame, advertising a smaller limit has no effect. MAX_STREAMS frames that do not increase the stream limit MUST be ignored.
受信機がMAX_STREAMSフレームを使用してストリーム制限をアドバタイズすると、小さい方限界を広告することは効果がありません。Streamの制限を上げないMAX_STREAMSフレームは無視される必要があります。
As with stream and connection flow control, this document leaves implementations to decide when and how many streams should be advertised to a peer via MAX_STREAMS. Implementations might choose to increase limits as streams are closed, to keep the number of streams available to peers roughly consistent.
ストリームと接続フロー制御と同様に、このドキュメントは、Max_streamを介してピアにアドバタイズする必要があるとき、および数のストリームをいつ、あるいは宣伝するかを決定するための実装を残します。実装は、ストリームが閉じられたときに制限を増やすことを選択して、ピアが大まかに一貫しているストリームの数を維持することができます。
An endpoint that is unable to open a new stream due to the peer's limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This signal is considered useful for debugging. An endpoint MUST NOT wait to receive this signal before advertising additional credit, since doing so will mean that the peer will be blocked for at least an entire round trip, and potentially indefinitely if the peer chooses not to send STREAMS_BLOCKED frames.
ピアの制限のために新しいストリームを開くことができないエンドポイントは、STREAMS_BLOCKEDフレームを送信する必要があります（セクション19.14）。この信号はデバッグに役立ちます。そのようなクレジットを広告する前にエンドポイントはこの信号を受信するのを待ってはいけません。
A QUIC connection is shared state between a client and a server.
QUIC接続は、クライアントとサーバー間の共有状態です。
Each connection starts with a handshake phase, during which the two endpoints establish a shared secret using the cryptographic handshake protocol [QUIC-TLS] and negotiate the application protocol. The handshake (Section 7) confirms that both endpoints are willing to communicate (Section 8.1) and establishes parameters for the connection (Section 7.4).
各接続はハンドシェイクフェーズで始まり、その間に2つのエンドポイントが暗号化ハンドシェイクプロトコル[QUIC-TLS]を使用して共有シークレットを確立し、アプリケーションプロトコルをネゴシエートします。ハンドシェイク（セクション7）は、両方のエンドポイントが通信しても構わないと思われる（セクション8.1）、接続のパラメータを確立することを確認します（セクション7.4）。
An application protocol can use the connection during the handshake phase with some limitations. 0-RTT allows application data to be sent by a client before receiving a response from the server. However, 0-RTT provides no protection against replay attacks; see Section 9.2 of [QUIC-TLS]. A server can also send application data to a client before it receives the final cryptographic handshake messages that allow it to confirm the identity and liveness of the client. These capabilities allow an application protocol to offer the option of trading some security guarantees for reduced latency.
アプリケーションプロトコルは、ハンドシェイクフェーズの間の接続をいくつかの制限で使用できます。0-RTTは、サーバーからの応答を受信する前に、クライアントによってアプリケーションデータを送信できます。ただし、0-RTTはリプレイ攻撃に対する保護はありません。[QUIC-TLS]のセクション9.2を参照してください。サーバーは、クライアントの身元および活性を確認できる最終暗号化ハンドシェイクメッセージを受信する前に、アプリケーションデータをクライアントに送信することもできます。これらの機能により、アプリケーションプロトコルはレイテンシを短縮するためにいくつかのセキュリティ保証を取引するオプションを提供することができます。
The use of connection IDs (Section 5.1) allows connections to migrate to a new network path, both as a direct choice of an endpoint and when forced by a change in a middlebox. Section 9 describes mitigations for the security and privacy issues associated with migration.
接続ID（セクション5.1）の使用は、接続を新しいネットワークパスに移行し、エンドポイントの直接選択とミドルボックスの変更によって強制されたときに移行することができます。セクション9は、移行に関連するセキュリティとプライバシーの問題に対する軽減について説明します。
For connections that are no longer needed or desired, there are several ways for a client and server to terminate a connection, as described in Section 10.
不要または望まれていない接続のために、セクション10で説明されているように、クライアントとサーバーが接続を終了する方法はいくつかあります。
Each connection possesses a set of connection identifiers, or connection IDs, each of which can identify the connection. Connection IDs are independently selected by endpoints; each endpoint selects the connection IDs that its peer uses.
各接続は、接続を識別することができる接続識別子のセットまたは接続IDを所有しています。接続IDは、エンドポイントによって独立して選択されます。各エンドポイントは、ピアが使用する接続IDを選択します。
The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP) do not cause packets for a QUIC connection to be delivered to the wrong endpoint. Each endpoint selects connection IDs using an implementation-specific (and perhaps deployment-specific) method that will allow packets with that connection ID to be routed back to the endpoint and to be identified by the endpoint upon receipt.
接続IDの主な機能は、下位プロトコルレイヤ（UDP、IP）でアドレス指定の変更がQUIC接続のパケットを間違ったエンドポイントに配信させないようにするためです。各エンドポイントは、その接続IDを持つパケットをエンドポイントにルーティングし、受信時にエンドポイントで識別されるようにする実装固有の（およびおそらく展開固有）メソッドを使用して接続IDを選択します。
Multiple connection IDs are used so that endpoints can send packets that cannot be identified by an observer as being for the same connection without cooperation from an endpoint; see Section 9.5.
エンドポイントが、エンドポイントからの協力なしに、オブザーバによって識別できないパケットを同じ接続のために送信することができないパケットを送信できるように、複数の接続IDが使用されます。9.5節を参照してください。
Connection IDs MUST NOT contain any information that can be used by an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same connection. As a trivial example, this means the same connection ID MUST NOT be issued more than once on the same connection.
接続IDには、外部オブザーバー（つまり、発行者と協力しないもの）が同じ接続の他の接続IDと相関するために使用できる情報を含める必要があります。些細な例として、これは同じ接続IDを同じ接続で複数回発行されてはいけません。
Packets with long headers include Source Connection ID and Destination Connection ID fields. These fields are used to set the connection IDs for new connections; see Section 7.2 for details.
長いヘッダーを持つパケットには、ソース接続IDと宛先接続IDフィールドがあります。これらのフィールドは、新しい接続のための接続IDを設定するために使用されます。詳細は7.2節をご覧ください。
Packets with short headers (Section 17.3) only include the Destination Connection ID and omit the explicit length. The length of the Destination Connection ID field is expected to be known to endpoints. Endpoints using a load balancer that routes based on connection ID could agree with the load balancer on a fixed length for connection IDs or agree on an encoding scheme. A fixed portion could encode an explicit length, which allows the entire connection ID to vary in length and still be used by the load balancer.
短いヘッダーを持つパケット（セクション17.3）は、宛先接続IDを含め、明示的な長さを省略します。宛先接続IDフィールドの長さはエンドポイントに認識されることが期待されています。ロードバランサを使用しているエンドポイント接続IDに基づくルートが、接続IDの固定長のロードバランサと一致し、または符号化方式で同意することができます。固定部分は明示的な長さを符号化することができ、それによって接続ID全体が長さが変化し、それでもロードバランサによって使用されることを可能にする。
A Version Negotiation (Section 17.2.1) packet echoes the connection IDs selected by the client, both to ensure correct routing toward the client and to demonstrate that the packet is in response to a packet sent by the client.
バージョンネゴシエーション（セクション17.2.1）パケットは、クライアントによって選択された接続IDをクライアントに向けて正しいルーティングを保証し、パケットがクライアントによって送信されたパケットに応答していることを実証するために、クライアントによって選択された接続IDをエコーします。
A zero-length connection ID can be used when a connection ID is not needed to route to the correct endpoint. However, multiplexing connections on the same local IP address and port while using zero-length connection IDs will cause failures in the presence of peer connection migration, NAT rebinding, and client port reuse. An endpoint MUST NOT use the same IP address and port for multiple concurrent connections with zero-length connection IDs, unless it is certain that those protocol features are not in use.
接続IDが正しいエンドポイントにルーティングするのに必要ない場合には、長さゼロの接続IDを使用できます。ただし、長さゼロの接続IDを使用している間に同じローカルIPアドレスとポートで接続を多重化すると、ピア接続の移行、NATの再バインド、およびクライアントポートの再利用が存在します。エンドポイントは、それらのプロトコル機能が使用されていないことが確実でない限り、長さゼロの接続IDと同じIPアドレスとポートを使用しないでください。
When an endpoint uses a non-zero-length connection ID, it needs to ensure that the peer has a supply of connection IDs from which to choose for packets sent to the endpoint. These connection IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame (Section 19.15).
エンドポイントがゼロ以外の接続IDを使用する場合、それはピアがエンドポイントに送信されたパケットの選択を選択する接続IDの供給を確実にする必要があります。これらの接続IDは、NEW_CONNECTION_IDフレームを使用してエンドポイントによって提供されます（セクション19.15）。
Each connection ID has an associated sequence number to assist in detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer to the same value. The initial connection ID issued by an endpoint is sent in the Source Connection ID field of the long packet header (Section 17.2) during the handshake. The sequence number of the initial connection ID is 0. If the preferred_address transport parameter is sent, the sequence number of the supplied connection ID is 1.
各接続IDには、NEW_CONNECTION_IDまたはRETIRE_CONNECTION_IDフレームが同じ値を参照するときの検出を支援するための関連するシーケンス番号があります。エンドポイントによって発行された初期接続IDは、ハンドシェイク中にロングパケットヘッダ（セクション17.2）のソース接続IDフィールドに送信されます。初期接続IDのシーケンス番号は0です。preose_addressトランスポートパラメータが送信された場合、指定された接続IDのシーケンス番号は1です。
Additional connection IDs are communicated to the peer using NEW_CONNECTION_ID frames (Section 19.15). The sequence number on each newly issued connection ID MUST increase by 1. The connection ID that a client selects for the first Destination Connection ID field it sends and any connection ID provided by a Retry packet are not assigned sequence numbers.
追加の接続IDは、NEW_CONNECTION_IDフレームを使用してピアに伝達されます（セクション19.15）。新たに発行された各接続IDのシーケンス番号は1で増加する必要があります。クライアントが送信する最初の宛先接続IDフィールドを選択し、再試行パケットによって提供された接続IDには、シーケンス番号が割り当てられていません。
When an endpoint issues a connection ID, it MUST accept packets that carry this connection ID for the duration of the connection or until its peer invalidates the connection ID via a RETIRE_CONNECTION_ID frame (Section 19.16). Connection IDs that are issued and not retired are considered active; any active connection ID is valid for use with the current connection at any time, in any packet type. This includes the connection ID issued by the server via the preferred_address transport parameter.
エンドポイントが接続IDを発行すると、接続の間、またはそのピアがRETIRE_CONNECTION_IDフレームを介して接続IDを無効にするまで、この接続IDをキャリングするパケットを受け入れる必要があります（セクション19.16）。発行されていない接続IDはアクティブと見なされます。アクティブな接続IDは、任意のパケットタイプで、現在の接続で使用するために有効です。これには、preferred_addressトランスポートパラメータを介してサーバーによって発行された接続IDが含まれます。
An endpoint SHOULD ensure that its peer has a sufficient number of available and unused connection IDs. Endpoints advertise the number of active connection IDs they are willing to maintain using the active_connection_id_limit transport parameter. An endpoint MUST NOT provide more connection IDs than the peer's limit. An endpoint MAY send connection IDs that temporarily exceed a peer's limit if the NEW_CONNECTION_ID frame also requires the retirement of any excess, by including a sufficiently large value in the Retire Prior To field.
エンドポイントは、ピアに十分な数の利用可能な接続IDがあることを確認する必要があります。エンドポイントは、active_connection_id_limitトランスポートパラメータを使用して保持しているアクティブな接続IDの数をアドバタイズします。エンドポイントは、ピアの制限よりも多くの接続IDを提供してはいけません。エンドポイントは、field以前にリタイアに十分大きい値を含めることによって、NEW_CONNECTION_IDフレームに余分な値を含めることによって、ピアの制限を一時的に超える接続IDを送信することができます。
A NEW_CONNECTION_ID frame might cause an endpoint to add some active connection IDs and retire others based on the value of the Retire Prior To field. After processing a NEW_CONNECTION_ID frame and adding and retiring active connection IDs, if the number of active connection IDs exceeds the value advertised in its active_connection_id_limit transport parameter, an endpoint MUST close the connection with an error of type CONNECTION_ID_LIMIT_ERROR.
NEW_CONNECTION_IDフレームは、エンドポイントがアクティブな接続IDを追加し、フィールドの前の引退の値に基づいて他のアクティブな接続IDを追加することがあります。新しい接続IDを追加してアクティブな接続IDを追加し、アクティブな接続IDを追加し、アクティブな接続IDの数がそのactive_connection_id_limitトランスポートパラメータでアドバタイズされている値を超える場合、エンドポイントはCONNECTION_ID_LIMIT_ERRORのエラーとの接続を閉じる必要があります。
An endpoint SHOULD supply a new connection ID when the peer retires a connection ID. If an endpoint provided fewer connection IDs than the peer's active_connection_id_limit, it MAY supply a new connection ID when it receives a packet with a previously unused connection ID. An endpoint MAY limit the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs; see Section 10.3.2. An endpoint MAY also limit the issuance of connection IDs to reduce the amount of per-path state it maintains, such as path validation status, as its peer might interact with it over as many paths as there are issued connection IDs.
ピアが接続IDを再起動すると、エンドポイントは新しい接続IDを指定する必要があります。エンドポイントがピアのactive_connection_id_limitよりも少ない接続IDを提供した場合、以前に未使用の接続IDを使用してパケットを受信したときに新しい接続IDを提供することがあります。エンドポイントは、接続IDを使い果たす危険性を回避するために、接続ごとに発行された接続IDの総数を制限することがあります。10.3.2項を参照してください。エンドポイントはまた、発行された接続IDがあるのと同じくらい多くの経路を超えてそれと対話するかもしれないので、パス検証の状態などのパスごとの状態の量を減らすために、接続IDの発行を制限することができる。
An endpoint that initiates migration and requires non-zero-length connection IDs SHOULD ensure that the pool of connection IDs available to its peer allows the peer to use a new connection ID on migration, as the peer will be unable to respond if the pool is exhausted.
移行を開始するエンドポイントで、ゼロ以外の接続IDが必要なエンドポイントで、ピアがプールが応答できない場合は、ピアが同輩が移行時に新しい接続IDを使用できるようになるようにする必要があります。疲れきった。
An endpoint that selects a zero-length connection ID during the handshake cannot issue a new connection ID. A zero-length Destination Connection ID field is used in all packets sent toward such an endpoint over any network path.
ハンドシェイク中に長さゼロの接続IDを選択するエンドポイントは、新しい接続IDを発行できません。ゼロ長さの宛先接続IDフィールドは、任意のネットワークパスにわたってそのようなエンドポイントに向かって送信されたすべてのパケットで使用されます。
An endpoint can change the connection ID it uses for a peer to another available one at any time during the connection. An endpoint consumes connection IDs in response to a migrating peer; see Section 9.5 for more details.
エンドポイントは、接続中にいつでもピアに使用する接続IDを変更できます。エンドポイントは、移行ピアに応答して接続IDを消費します。詳細については9.5節を参照してください。
An endpoint maintains a set of connection IDs received from its peer, any of which it can use when sending packets. When the endpoint wishes to remove a connection ID from use, it sends a RETIRE_CONNECTION_ID frame to its peer. Sending a RETIRE_CONNECTION_ID frame indicates that the connection ID will not be used again and requests that the peer replace it with a new connection ID using a NEW_CONNECTION_ID frame.
エンドポイントは、そのピアから受信した一連の接続IDを維持します。そのいずれかが、パケットを送信するときに使用できます。エンドポイントが使用から接続IDを削除したい場合は、RETIRE_CONNECTION_ID フレームをピアに送信します。RETIRE_CONNECTION_ID フレームの送信接続IDが再度使用されないことを示し、ピアが NEW_CONNECTION_ID フレームを使用して新しい接続IDを置き換えることを要求します。
As discussed in Section 9.5, endpoints limit the use of a connection ID to packets sent from a single local address to a single destination address. Endpoints SHOULD retire connection IDs when they are no longer actively using either the local or destination address for which the connection ID was used.
セクション9.5で説明したように、エンドポイントは、単一のローカルアドレスから単一の宛先アドレスに送信されたパケットへの接続IDの使用を制限します。エンドポイントは、接続IDが使用されているローカルアドレスまたは宛先アドレスのいずれかを積極的に使用しなくなったときに接続IDを復元する必要があります。
An endpoint might need to stop accepting previously issued connection IDs in certain circumstances. Such an endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. The endpoint SHOULD continue to accept the previously issued connection IDs until they are retired by the peer. If the endpoint can no longer process the indicated connection IDs, it MAY close the connection.
エンドポイントは、特定の状況で以前に発行された接続IDを受け入れるのを停止する必要があるかもしれません。そのようなエンドポイントは、フィールドの前に増加した引退をしてNEW_CONNECTION_IDフレームを送信することによって、そのピアが接続IDを復元させる可能性があります。エンドポイントは、ピアによって引退されるまで、以前に発行された接続IDを受け入れ続けるべきです。エンドポイントが示されている接続IDを処理できなくなった場合は、接続を閉じることがあります。
Upon receipt of an increased Retire Prior To field, the peer MUST stop using the corresponding connection IDs and retire them with RETIRE_CONNECTION_ID frames before adding the newly provided connection ID to the set of active connection IDs. This ordering allows an endpoint to replace all active connection IDs without the possibility of a peer having no available connection IDs and without exceeding the limit the peer sets in the active_connection_id_limit transport parameter; see Section 18.2. Failure to cease using the connection IDs when requested can result in connection failures, as the issuing endpoint might be unable to continue using the connection IDs with the active connection.
フィールド前に増加したリタイアを受信すると、ピアは対応する接続IDを使用して停止しなければならず、新しく提供された接続IDをアクティブな接続IDのセットに追加する前にRETIRE_CONNECTION_IDフレームを復元する必要があります。この順序付けにより、エンドポイントは、使用可能な接続IDを持たない可能性がなく、Active_Connection_ID_Limitトランスポートパラメータの制限を超えずに、すべてのアクティブ接続IDを置き換えることができます。18.2節を参照してください。要求されたときに接続IDの使用を中止しないと、発行エンドポイントがアクティブな接続で接続IDを使用し続けることができない場合があります。
An endpoint SHOULD limit the number of connection IDs it has retired locally for which RETIRE_CONNECTION_ID frames have not yet been acknowledged. An endpoint SHOULD allow for sending and tracking a number of RETIRE_CONNECTION_ID frames of at least twice the value of the active_connection_id_limit transport parameter. An endpoint MUST NOT forget a connection ID without retiring it, though it MAY choose to treat having connection IDs in need of retirement that exceed this limit as a connection error of type CONNECTION_ID_LIMIT_ERROR.
エンドポイントは、RETIRE_CONNECTION_IDフレームがまだ認識されていないローカルに廃止された接続IDの数を制限する必要があります。エンドポイントは、active_connection_id_limitトランスポートパラメータの少なくとも2倍の数のretile_connection_idフレームを送信および追跡することを可能にする必要があります。この制限を超える退任を必要とする退避が必要な退職を必要としていることを選択することは、Connection_ID_LIMIT_ERRORの接続エラーとして接続IDを扱うことを選択することができます。
Endpoints SHOULD NOT issue updates of the Retire Prior To field before receiving RETIRE_CONNECTION_ID frames that retire all connection IDs indicated by the previous Retire Prior To value.
エンドポイントは、値の前に前の引退によって示されるすべての接続IDを復元するRETIRE_CONNECTION_IDフレームを受信する前に、フィールドの前に引退の更新を発行しないでください。
Incoming packets are classified on receipt. Packets can either be associated with an existing connection or -- for servers -- potentially create a new connection.
着信パケットは受信時に分類されます。パケットは、既存の接続に関連付けるか、サーバーの場合は新しい接続を作成する可能性があります。
Endpoints try to associate a packet with an existing connection. If the packet has a non-zero-length Destination Connection ID corresponding to an existing connection, QUIC processes that packet accordingly. Note that more than one connection ID can be associated with a connection; see Section 5.1.
エンドポイントは、パケットを既存の接続に関連付けようとします。パケットに既存の接続に対応する長さがゼロ以外の宛先接続IDがある場合、QUICはそれに応じてそのパケットを処理します。 1つの接続に複数の接続IDを関連付けることができることに注意してください。 セクション5.1を参照してください。
If the Destination Connection ID is zero length and the addressing information in the packet matches the addressing information the endpoint uses to identify a connection with a zero-length connection ID, QUIC processes the packet as part of that connection. An endpoint can use just destination IP and port or both source and destination addresses for identification, though this makes connections fragile as described in Section 5.1.
宛先接続IDがゼロ長で、パケット内のアドレス指定情報がアドレス指定情報と一致した場合、エンドポイントは長さゼロの接続IDとの接続を識別するために使用され、その接続の一部としてパケットを処理します。エンドポイントは、識別のために宛先IPとポートのみ、またはソースアドレスと宛先の両方のアドレスだけを使用できますが、セクション5.1で説明したように接続は脆弱です。
Endpoints can send a Stateless Reset (Section 10.3) for any packets that cannot be attributed to an existing connection. A Stateless Reset allows a peer to more quickly identify when a connection becomes unusable.
エンドポイントは、既存の接続に属していないパケットについて、ステートレスリセット（セクション10.3）を送信できます。ステートレスリセットにより、接続が使用できなくなるとピアがより迅速に識別できます。
Packets that are matched to an existing connection are discarded if the packets are inconsistent with the state of that connection. For example, packets are discarded if they indicate a different protocol version than that of the connection or if the removal of packet protection is unsuccessful once the expected keys are available.
パケットがその接続の状態と矛盾している場合、既存の接続に一致するパケットは破棄されます。たとえば、パケットは、接続とは異なるプロトコルバージョンを示している場合、またはパケット保護の解除が可能になると、予想されるキーが使用可能になるとパケット保護の解除が失敗した場合は破棄されます。
Invalid packets that lack strong integrity protection, such as Initial, Retry, or Version Negotiation, MAY be discarded. An endpoint MUST generate a connection error if processing the contents of these packets prior to discovering an error, or fully revert any changes made during that processing.
初期、再試行、バージョンネゴシエーションなど、強力な完全性保護を欠いている無効なパケットは破棄されてもよい。エラーを検出する前にこれらのパケットの内容を処理する場合、エンドポイントは接続エラーを生成し、その処理中に行われた変更を完全に元に戻す必要があります。
Valid packets sent to clients always include a Destination Connection ID that matches a value the client selects. Clients that choose to receive zero-length connection IDs can use the local address and port to identify a connection. Packets that do not match an existing connection -- based on Destination Connection ID or, if this value is zero length, local IP address and port -- are discarded.
クライアントに送信された有効なパケットは常にクライアントが選択する値と一致する宛先接続IDを含みます。長さゼロの接続IDを受信することを選択するクライアントは、ローカルアドレスとポートを使用して接続を識別できます。宛先接続IDに基づく既存の接続と一致しないパケット、またはこの値がゼロの場合、ローカルIPアドレスとポート - は破棄されます。
Due to packet reordering or loss, a client might receive packets for a connection that are encrypted with a key it has not yet computed. The client MAY drop these packets, or it MAY buffer them in anticipation of later packets that allow it to compute the key.
パケットの並べ替えまたは損失のために、クライアントは、まだ計算されていないキーで暗号化されている接続のパケットを受信することがあります。クライアントはこれらのパケットをドロップすることも、後のパケットを予想してキーを計算できるようになります。
If a client receives a packet that uses a different version than it initially selected, it MUST discard that packet.
クライアントが最初に選択されているものとは異なるバージョンを使用するパケットを受信した場合は、そのパケットを破棄する必要があります。
If a server receives a packet that indicates an unsupported version and if the packet is large enough to initiate a new connection for any supported version, the server SHOULD send a Version Negotiation packet as described in Section 6.1. A server MAY limit the number of packets to which it responds with a Version Negotiation packet. Servers MUST drop smaller packets that specify unsupported versions.
サポートされていないバージョンを示すパケットをサーバーに受信した場合、およびパケットがサポートされているバージョンに対して新しい接続を開始するのに十分な大きさである場合、サーバーはセクション6.1で説明されているようにバージョンネゴシエーションパケットを送信する必要があります。サーバーは、バージョンネゴシエーションパケットで応答するパケットの数を制限することがあります。サーバーは、サポートされていないバージョンを指定する小さいパケットを削除する必要があります。
The first packet for an unsupported version can use different semantics and encodings for any version-specific field. In particular, different packet protection keys might be used for different versions. Servers that do not support a particular version are unlikely to be able to decrypt the payload of the packet or properly interpret the result. Servers SHOULD respond with a Version Negotiation packet, provided that the datagram is sufficiently long.
サポートされていないバージョンの最初のパケットは、任意のバージョン固有のフィールドに対して異なるセマンティクスとエンコーディングを使用できます。特に、さまざまなパケット保護キーがさまざまなバージョンに使用される場合があります。特定のバージョンをサポートしていないサーバーは、パケットのペイロードを復号化したり、結果を正しく解釈できることはほとんどありません。データグラムが十分に長いと、バージョンネゴシエーションパケットでサーバーが応答する必要があります。
Packets with a supported version, or no Version field, are matched to a connection using the connection ID or -- for packets with zero-length connection IDs -- the local address and port. These packets are processed using the selected connection; otherwise, the server continues as described below.
サポートされているバージョンを持つパケット、またはバージョン・フィールドは、Connection IDを使用した接続と一致し、長さゼロの接続IDを使用したパケット（ローカルアドレスとポート）。これらのパケットは、選択した接続を使用して処理されます。それ以外の場合、サーバーは以下のように続行されます。
If the packet is an Initial packet fully conforming with the specification, the server proceeds with the handshake (Section 7). This commits the server to the version that the client selected.
パケットが仕様に完全に準拠している初期パケットである場合、サーバはハンドシェイクで進行する（セクション7）。これにより、サーバーをクライアントが選択したバージョンにコミットします。
If a server refuses to accept a new connection, it SHOULD send an Initial packet containing a CONNECTION_CLOSE frame with error code CONNECTION_REFUSED.
サーバーが新しい接続を受け入れることを拒否した場合は、エラーコード CONNECTION_REFUSED を使って CONNECTION_CLOSE フレームを含む初期パケットを送信する必要があります。
If the packet is a 0-RTT packet, the server MAY buffer a limited number of these packets in anticipation of a late-arriving Initial packet. Clients are not able to send Handshake packets prior to receiving a server response, so servers SHOULD ignore any such packets.
パケットが0-RTTパケットである場合、サーバは、遅く到着した初期パケットを予想してこれらのパケットの限られた数をバッファすることができる。クライアントはサーバーの応答を受信する前にハンドシェイクパケットを送信することができないため、サーバーはそのようなパケットを無視する必要があります。
Servers MUST drop incoming packets under all other circumstances.
サーバーは他のすべての状況下で着信パケットを削除する必要があります。
A server deployment could load-balance among servers using only source and destination IP addresses and ports. Changes to the client's IP address or port could result in packets being forwarded to the wrong server. Such a server deployment could use one of the following methods for connection continuity when a client's address changes.
サーバーの展開は、送信元と宛先のIPアドレスとポートのみを使用してサーバー間でロードバランスをとることができます。クライアントのIPアドレスまたはポートへの変更は、パケットが間違ったサーバーに転送される可能性があります。そのようなサーバ展開は、クライアントのアドレスが変更されたときに接続継続性に次のいずれかの方法を使用することができる。
* Servers could use an out-of-band mechanism to forward packets to the correct server based on connection ID.
* サーバーは、接続IDに基づいてパケットを正しいサーバーに転送するために帯域外機構を使用できます。
* If servers can use a dedicated server IP address or port, other than the one that the client initially connects to, they could use the preferred_address transport parameter to request that clients move connections to that dedicated address. Note that clients could choose not to use the preferred address.
* クライアントが最初に接続するもの以外のサーバーが専用のサーバーのIPアドレスまたはポートを使用できる場合、それらはPreferred_Addressトランスポートパラメータを使用してクライアントがその専用アドレスへの接続を移動させることができます。クライアントが優先アドレスを使用しないことを選択できます。
A server in a deployment that does not implement a solution to maintain connection continuity when the client address changes SHOULD indicate that migration is not supported by using the disable_active_migration transport parameter. The disable_active_migration transport parameter does not prohibit connection migration after a client has acted on a preferred_address transport parameter.
クライアントアドレスの変更が、DISABLE_ACTIVE_MIGRATIONトランスポートパラメータを使用してマイグレーションがサポートされていない場合に接続継続を維持するためのソリューションを実装していない展開内のサーバー。disable_active_migrationトランスポートパラメータは、クライアントがpreferse_addressトランスポートパラメータで行動した後に接続移行を禁止しません。
Server deployments that use this simple form of load balancing MUST avoid the creation of a stateless reset oracle; see Section 21.11.
この単純な形式のロードバランシングを使用するサーバーの展開は、ステートレスリセットOracleの作成を避ける必要があります。21.11節を参照してください。
This document does not define an API for QUIC; it instead defines a set of functions for QUIC connections that application protocols can rely upon. An application protocol can assume that an implementation of QUIC provides an interface that includes the operations described in this section. An implementation designed for use with a specific application protocol might provide only those operations that are used by that protocol.
この文書はQUIC用のAPIを定義しません。代わりに、アプリケーションプロトコルが依存できるQUIC接続のセットを定義します。アプリケーションプロトコルは、QUICの実装が、このセクションで説明されている操作を含むインターフェースを提供すると仮定できます。特定のアプリケーションプロトコルで使用するように設計された実装は、そのプロトコルによって使用される操作のみを提供するかもしれません。
When implementing the client role, an application protocol can:
クライアントは、次のことができます。
* open a connection, which begins the exchange described in Section 7;
* 接続を開き、セクション7で説明されている交換を開始します。
* enable Early Data when available; and
* 利用可能なときに早期データ (Early Data) を有効にします。
* be informed when Early Data has been accepted or rejected by a server.
* サーバが早期データ (Early Data) を受理したか拒否したかを通知されます。
When implementing the server role, an application protocol can:
サーバーは、次のことができます。
* listen for incoming connections, which prepares for the exchange described in Section 7;
* 着信接続を聴き、セクション7で説明されている交換の準備をしています。
* if Early Data is supported, embed application-controlled data in the TLS resumption ticket sent to the client; and
* 早期データ (Early Data) がサポートされている場合は、クライアントに送信されたTLSの再開チケットにアプリケーション制御データを埋め込みます。
* if Early Data is supported, retrieve application-controlled data from the client's resumption ticket and accept or reject Early Data based on that information.
* 早期データ (Early Data) がサポートされている場合は、クライアントの再開チケットからアプリケーション管理データを取得し、その情報に基づいて早期データを受け入れるか拒否します。
In either role, an application protocol can:
どちらの役割でも、アプリケーションプロトコルは次のことができます。
* configure minimum values for the initial number of permitted streams of each type, as communicated in the transport parameters (Section 7.4);
* トランスポートパラメータに通信されるように、各タイプの許可されたストリームの初期数の最小値を設定します（セクション7.4）。
* control resource allocation for receive buffers by setting flow control limits both for streams and for the connection;
* フロー制御を設定することによって受信バッファの制御リソース割り当ては、ストリームと接続の両方を制限します。
* identify whether the handshake has completed successfully or is still ongoing;
* ハンドシェイクが正常に完了したかまだ進行中であるかを確認します。
* keep a connection from silently closing, by either generating PING frames (Section 19.2) or requesting that the transport send additional frames before the idle timeout expires (Section 10.1); and
* Pingフレームを生成する（セクション19.2）、またはアイドルタイムアウトの有効期限が切れる前に追加のフレームを送信するように静的に閉じることから接続を保持してください（セクション10.1）。
* immediately close (Section 10.2) the connection.
* 接続をすぐに閉じる（10.2節）。
Version negotiation allows a server to indicate that it does not support the version the client used. A server sends a Version Negotiation packet in response to each packet that might initiate a new connection; see Section 5.2 for details.
バージョンネゴシエーションを使用すると、サーバーはそれが使用されているクライアントのバージョンをサポートしていないことを示すことができます。サーバーは、新しい接続を開始する可能性のある各パケットに応答してバージョンネゴシエーションパケットを送信します。詳細は5.2節をご覧ください。
The size of the first packet sent by a client will determine whether a server sends a Version Negotiation packet. Clients that support multiple QUIC versions SHOULD ensure that the first UDP datagram they send is sized to the largest of the minimum datagram sizes from all versions they support, using PADDING frames (Section 19.1) as necessary. This ensures that the server responds if there is a mutually supported version. A server might not send a Version Negotiation packet if the datagram it receives is smaller than the minimum size specified in a different version; see Section 14.1.
クライアントによって送信された最初のパケットのサイズは、サーバーがバージョンネゴシエーションパケットを送信するかどうかを判断します。複数のQUICバージョンをサポートするクライアントは、送信フレーム（セクション19.1）を使用して、それらがサポートするすべてのバージョンから最大のデータグラムサイズの最大のサイズ（セクション19.1）を使用して、最初のUDPデータグラムが最小データグラムサイズでサイズ指定される必要があります。これにより、相互にサポートされているバージョンがある場合、サーバーが応答するようになります。受信したデータグラムが別のバージョンで指定された最小サイズより小さい場合、サーバーはバージョンネゴシエーションパケットを送信しない可能性があります。14.1項を参照してください。
If the version selected by the client is not acceptable to the server, the server responds with a Version Negotiation packet; see Section 17.2.1. This includes a list of versions that the server will accept. An endpoint MUST NOT send a Version Negotiation packet in response to receiving a Version Negotiation packet.
クライアントによって選択されたバージョンがサーバーに受け入れられない場合、サーバーはバージョンネゴシエーションパケットで応答します。17.2.1項を参照してください。これには、サーバーが受け入れるバージョンのリストが含まれます。バージョンネゴシエーションパケットの受信に応答して、エンドポイントはバージョンネゴシエーションパケットを送信してはなりません。
This system allows a server to process packets with unsupported versions without retaining state. Though either the Initial packet or the Version Negotiation packet that is sent in response could be lost, the client will send new packets until it successfully receives a response or it abandons the connection attempt.
このシステムでは、サーバーが保持状態なしでサポートされていないバージョンでパケットを処理できます。最初のパケットまたは応答に送信されるバージョンネゴシエーションパケットのどちらかが失われる可能性があるが、クライアントは応答を正常に受信するか、接続試行に棄却するまで新しいパケットを送信します。
A server MAY limit the number of Version Negotiation packets it sends. For instance, a server that is able to recognize packets as 0-RTT might choose not to send Version Negotiation packets in response to 0-RTT packets with the expectation that it will eventually receive an Initial packet.
サーバーは、送信するバージョンネゴシエーションパケットの数を制限することがあります。たとえば、パケットを0-RTTとして認識できるサーバーは、0-RTTパケットに応答してバージョンネゴシエーションパケットを送信しないことを選択できます。
Version Negotiation packets are designed to allow for functionality to be defined in the future that allows QUIC to negotiate the version of QUIC to use for a connection. Future Standards Track specifications might change how implementations that support multiple versions of QUIC react to Version Negotiation packets received in response to an attempt to establish a connection using this version.
バージョンネゴシエーションパケットは、QUICが接続に使用するためにQUICのバージョンをネゴシエートすることを可能にする将来機能を定義できるように設計されています。将来の標準トラック仕様は、このバージョンを使用して接続を確立しようとする試みに応答して受信されたバージョンネゴシエーションパケットに、複数のバージョンのQUICをサポートする方法を変更することができます。
A client that supports only this version of QUIC MUST abandon the current connection attempt if it receives a Version Negotiation packet, with the following two exceptions. A client MUST discard any Version Negotiation packet if it has received and successfully processed any other packet, including an earlier Version Negotiation packet. A client MUST discard a Version Negotiation packet that lists the QUIC version selected by the client.
このバージョンのQUICのみをサポートするクライアントは、バージョンネゴシエーションパケットを受信した場合に現在の接続試行を放棄する必要があります。クライアントは、以前のバージョンネゴシエーションパケットを含む他のパケットを受信して正常に処理した場合は、バージョンネゴシエーションパケットを破棄する必要があります。クライアントは、クライアントによって選択されたQUICバージョンをリストするバージョンネゴシエーションパケットを破棄する必要があります。
How to perform version negotiation is left as future work defined by future Standards Track specifications. In particular, that future work will ensure robustness against version downgrade attacks; see Section 21.12.
バージョンネゴシエーションを実行する方法将来の標準トラックの仕様によって定義された将来の作業として残されます。特に、将来の作業はバージョンダウングレード攻撃に対する堅牢性を保証します。21.12節を参照してください。
For a server to use a new version in the future, clients need to correctly handle unsupported versions. Some version numbers (0x?a?a?a?a, as defined in Section 15) are reserved for inclusion in fields that contain version numbers.
将来的に新しいバージョンを使用するためのサーバーが、クライアントはサポートされていないバージョンを正しく処理する必要があります。いくつかのバージョン番号（0x?a?a?a?a）は、バージョン番号を含むフィールドに含めるように予約されています。
Endpoints MAY add reserved versions to any field where unknown or unsupported versions are ignored to test that a peer correctly ignores the value. For instance, an endpoint could include a reserved version in a Version Negotiation packet; see Section 17.2.1. Endpoints MAY send packets with a reserved version to test that a peer correctly discards the packet.
エンドポイントは、不明またはサポートされていないバージョンが、ピアが値を正しく無視したことをテストするために無視された任意のフィールドに予約版を追加することができます。たとえば、エンドポイントは、バージョンネゴシエーションパケットに予約済みバージョンを含めることができます。17.2.1項を参照してください。エンドポイントは、ピアがパケットを正しく破棄したことをテストするために予約バージョンでパケットを送信することができます。
QUIC relies on a combined cryptographic and transport handshake to minimize connection establishment latency. QUIC uses the CRYPTO frame (Section 19.6) to transmit the cryptographic handshake. The version of QUIC defined in this document is identified as 0x00000001 and uses TLS as described in [QUIC-TLS]; a different QUIC version could indicate that a different cryptographic handshake protocol is in use.
QUICは、接続確立待ち時間を最小限に抑えるために、暗号化およびトランスポートハンドシェイクの組み合わせに依存しています。QUICは暗号化フレーム（セクション19.6）を使用して暗号化ハンドシェイクを送信します。この文書で定義されているQUICのバージョンは0x00000001として識別され、[QUIC-TLS]で説明されているようにTLSを使用します。異なるQUICバージョンは、異なる暗号化ハンドシェイクプロトコルが使用されていることを示す可能性があります。
QUIC provides reliable, ordered delivery of the cryptographic handshake data. QUIC packet protection is used to encrypt as much of the handshake protocol as possible. The cryptographic handshake MUST provide the following properties:
QUICは、暗号化ハンドシェイクデータの信頼性の高い順序付けられた配信を提供します。QUICのパケット保護は、できるだけ多くのハンドシェイクプロトコルを暗号化するために使用されます。暗号化ハンドシェイクは次のプロパティを提供しなければなりません。
* authenticated key exchange, where
* 認証された鍵交換
- a server is always authenticated,
- サーバーは常に認証されています。
- a client is optionally authenticated,
- クライアントはオプションで認証されています。
- every connection produces distinct and unrelated keys, and
- すべての接続は、異なりのないキーを生成します
- keying material is usable for packet protection for both 0-RTT and 1-RTT packets.
- キーイング材料は、0-RTTパケットと1-RTTパケットの両方のパケット保護に使用できます。
* authenticated exchange of values for transport parameters of both endpoints, and confidentiality protection for server transport parameters (see Section 7.4).
* 両方のエンドポイントのトランスポートパラメータ、およびサーバトランスポートパラメータの機密保護のための値の認証された値の交換（セクション7.4を参照）。
* authenticated negotiation of an application protocol (TLS uses Application-Layer Protocol Negotiation (ALPN) [ALPN] for this purpose).
* アプリケーションプロトコルの認証済みネゴシエーション（TLSは、この目的のためにアプリケーション層プロトコルネゴシエーション（ALPN）[ALPN]を使用します）。
The CRYPTO frame can be sent in different packet number spaces (Section 12.3). The offsets used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in each packet number space.
暗号フレームは、異なるパケット番号スペースで送信することができる（セクション12.3）。暗号化フレームが使用するオフセットは、暗号化ハンドシェイクデータの順序付けられた配信を確実にして各パケット番号スペースのゼロから始まります。
Figure 4 shows a simplified handshake and the exchange of packets and frames that are used to advance the handshake. Exchange of application data during the handshake is enabled where possible, shown with an asterisk ("*"). Once the handshake is complete, endpoints are able to exchange application data freely.
図4は、ハンドシェイクを進めるために使用される、簡素化されたハンドシェイクとパケットとフレームの交換を示しています。ハンドシェイク中のアプリケーションデータの交換は可能な限り、アスタリスク（ "*"）で表示されます。ハンドシェイクが完了すると、エンドポイントはアプリケーションデータを自由に交換することができます。
Client Server
Initial (CRYPTO)
0-RTT (*) ---------->
Initial (CRYPTO)
Handshake (CRYPTO)
<---------- 1-RTT (*)
Handshake (CRYPTO)
1-RTT (*) ---------->
<---------- 1-RTT (HANDSHAKE_DONE)
1-RTT <=========> 1-RTT
Figure 4: Simplified QUIC Handshake
図4：簡略化されたQUICハンドシェイク
Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see Section 13.4. An endpoint validates support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in Section 13.4.2.
エンドポイントは、ハンドシェイク中に送信されたパケットを使用して、明示的な輻輳通知（ECN）サポートをテストできます。13.4項を参照してください。エンドポイントは、セクション13.4.2で説明されているように、ACKフレームが送信ECNカウントを送信することを確認することによって、ACKフレームがCARRING COUNTSを確認するかどうかを観察することによってECNのサポートを検証します。
Endpoints MUST explicitly negotiate an application protocol. This avoids situations where there is a disagreement about the protocol that is in use.
エンドポイントはアプリケーションプロトコルを明示的にネゴシエートする必要があります。これにより、使用中のプロトコルについての意見の相違がある状況を回避します。
Details of how TLS is integrated with QUIC are provided in [QUIC-TLS], but some examples are provided here. An extension of this exchange to support client address validation is shown in Section 8.1.2.
TLSがQUICと統合されている方法の詳細は[QUIC-TLS]にありますが、いくつかの例がここに提供されています。クライアントアドレス検証をサポートするためのこの交換の拡張は、8.1.2項に示されています。
Once any address validation exchanges are complete, the cryptographic handshake is used to agree on cryptographic keys. The cryptographic handshake is carried in Initial (Section 17.2.2) and Handshake (Section 17.2.4) packets.
アドレス検証交換が完了すると、暗号化ハンドシェイクを使用して暗号化キーについて同意します。暗号化ハンドシェイクは初期（17.2.2項）およびハンドシェイク（第17.2.4節）パケットで行われます。
Figure 5 provides an overview of the 1-RTT handshake. Each line shows a QUIC packet with the packet type and packet number shown first, followed by the frames that are typically contained in those packets. For instance, the first packet is of type Initial, with packet number 0, and contains a CRYPTO frame carrying the ClientHello.
図5は、1-RTTハンドシェイクの概要を示しています。各行は、最初に示されているパケットタイプとパケット番号を持つQUICパケットを示し、その後にそれらのパケットに含まれているフレームが続きます。例えば、第1のパケットは、パケット番号0を有する初期タイプであり、ClientHelloを搬送する暗号フレームを含む。
Multiple QUIC packets -- even of different packet types -- can be coalesced into a single UDP datagram; see Section 12.2. As a result, this handshake could consist of as few as four UDP datagrams, or any number more (subject to limits inherent to the protocol, such as congestion control and anti-amplification). For instance, the server's first flight contains Initial packets, Handshake packets, and "0.5-RTT data" in 1-RTT packets.
複数のQUICパケット - 異なるパケットタイプでさえ - 単一のUDPデータグラムに合体することができます。12.2項を参照してください。その結果、このハンドシェイクは、4つのUDPデータグラムの4つのUDPデータグラム、または任意の数値（輻輳制御や増幅器のようなプロトコルに固有の制限の対象）からなる可能性があります。たとえば、サーバーの最初のフライトには、1 RTTパケットの初期パケット、ハンドシェイクパケット、および「0.5-RTTデータ」が含まれています。
Client Server
Initial[0]: CRYPTO[CH] ->
Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."]
Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[0]: STREAM[0, "..."], ACK[0] ->
Handshake[1]: ACK[0]
<- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[0]
Figure 5: Example 1-RTT Handshake
図5：1-RTTハンドシェイクの例
Figure 6 shows an example of a connection with a 0-RTT handshake and a single packet of 0-RTT data. Note that as described in Section 12.3, the server acknowledges 0-RTT data in 1-RTT packets, and the client sends 1-RTT packets in the same packet number space.
図6は、0-RTTハンドシェイクと0-RTTデータの単一パケットとの接続例を示しています。セクション12.3で説明されているように、サーバーは1-RTTパケットで0-RTTデータを確認し、クライアントは同じパケット番号スペースに1-RTTパケットを送信します。
Client Server
Initial[0]: CRYPTO[CH]
0-RTT[0]: STREAM[0, "..."] ->
Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0] CRYPTO[EE, FIN]
<- 1-RTT[0]: STREAM[1, "..."] ACK[0]
Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[1]: STREAM[0, "..."] ACK[0] ->
Handshake[1]: ACK[0]
<- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[1]
Figure 6: Example 0-RTT Handshake
図6：0-RTTハンドシェイクの例
A connection ID is used to ensure consistent routing of packets, as described in Section 5.1. The long header contains two connection IDs: the Destination Connection ID is chosen by the recipient of the packet and is used to provide consistent routing; the Source Connection ID is used to set the Destination Connection ID used by the peer.
接続IDは、セクション5.1で説明されているように、パケットの一貫したルーティングを確実にするために使用されます。ロングヘッダーには2つの接続IDが含まれています。宛先接続IDはパケットの受信者によって選択され、一貫したルーティングを提供するために使用されます。ソース接続IDは、ピアが使用する宛先接続IDを設定するために使用されます。
During the handshake, packets with the long header (Section 17.2) are used to establish the connection IDs used by both endpoints. Each endpoint uses the Source Connection ID field to specify the connection ID that is used in the Destination Connection ID field of packets being sent to them. After processing the first Initial packet, each endpoint sets the Destination Connection ID field in subsequent packets it sends to the value of the Source Connection ID field that it received.
ハンドシェイク中に、長いヘッダーを持つパケット（セクション17.2）は、両方のエンドポイントによって使用される接続IDを確立するために使用されます。各エンドポイントは、送信元接続IDフィールドを使用して、送信されているパケットの宛先接続IDフィールドで使用される接続IDを指定します。最初の初期パケットを処理した後、各エンドポイントは、受信したソース接続IDフィールドの値に送信された後続のパケット内の宛先接続IDフィールドを設定します。
When an Initial packet is sent by a client that has not previously received an Initial or Retry packet from the server, the client populates the Destination Connection ID field with an unpredictable value. This Destination Connection ID MUST be at least 8 bytes in length. Until a packet is received from the server, the client MUST use the same Destination Connection ID value on all packets in this connection.
初期パケットが、以前にサーバから初期または再試行パケットを受信していないクライアントによって送信されると、クライアントは宛先接続IDフィールドを予測不可能な値で入力する。この宛先接続IDは、長さが8バイト以上でなければなりません。パケットがサーバーから受信されるまで、クライアントはこの接続のすべてのパケットで同じ宛先接続ID値を使用する必要があります。
The Destination Connection ID field from the first Initial packet sent by a client is used to determine packet protection keys for Initial packets. These keys change after receiving a Retry packet; see Section 5.2 of [QUIC-TLS].
クライアントによって送信された最初の初期パケットからの宛先接続IDフィールドは、初期パケットのパケット保護キーを決定するために使用されます。これらのキーは再試行パケットを受信した後に変わります。[QUIC-TLS]のセクション5.2を参照してください。
The client populates the Source Connection ID field with a value of its choosing and sets the Source Connection ID Length field to indicate the length.
クライアントは、ソース接続IDフィールドを選択した値を選択し、その長さを示すためにソース接続IDの長さフィールドを設定します。
0-RTT packets in the first flight use the same Destination Connection ID and Source Connection ID values as the client's first Initial packet.
最初のフライト内の0-RTTパケットは、クライアントの最初の初期パケットとして同じ宛先接続IDとソース接続ID値を使用します。
Upon first receiving an Initial or Retry packet from the server, the client uses the Source Connection ID supplied by the server as the Destination Connection ID for subsequent packets, including any 0-RTT packets. This means that a client might have to change the connection ID it sets in the Destination Connection ID field twice during connection establishment: once in response to a Retry packet and once in response to an Initial packet from the server. Once a client has received a valid Initial packet from the server, it MUST discard any subsequent packet it receives on that connection with a different Source Connection ID.
クライアントは、サーバーから最初に初期パケットまたは再試行パケットを受信すると、サーバーから提供された送信元接続IDを、0-RTTパケットを含む後続のパケットの宛先接続IDとして使用します。つまり、クライアントは、接続の確立中に[宛先接続ID]フィールドに設定した接続IDを2回変更する必要がある場合があります。1回は再試行パケットに応答し、もう1回はサーバーからの初期パケットに応答します。クライアントがサーバーから有効な初期パケットを受信すると、その接続で受信した後続のパケットを別の送信元接続IDで破棄する必要があります。
A client MUST change the Destination Connection ID it uses for sending packets in response to only the first received Initial or Retry packet. A server MUST set the Destination Connection ID it uses for sending packets based on the first received Initial packet. Any further changes to the Destination Connection ID are only permitted if the values are taken from NEW_CONNECTION_ID frames; if subsequent Initial packets include a different Source Connection ID, they MUST be discarded. This avoids unpredictable outcomes that might otherwise result from stateless processing of multiple Initial packets with different Source Connection IDs.
クライアントは、最初の受信した初期パケットまたは再試行パケットのみに応答してパケットの送信に使用する宛先接続IDを変更する必要があります。サーバーは、最初の受信した初期パケットに基づいてパケットの送信に使用する宛先接続IDを設定する必要があります。宛先接続IDに対するそれ以上の変更は、値が NEW_CONNECTION_ID フレームから取得された場合にのみ許可されます。後続の初期パケットに異なる送信元接続IDが含まれている場合は、それらを破棄する必要があります。これにより、異なるソース接続IDを持つ複数の初期パケットのステートレス処理からそうでなければ、予測不可能な結果が回避されます。
The Destination Connection ID that an endpoint sends can change over the lifetime of a connection, especially in response to connection migration (Section 9); see Section 5.1.1 for details.
エンドポイントが送信する宛先接続IDは、特に接続移行に応答して、接続の有効期間を介して変更できます（セクション9）。詳細については5.1.1項を参照してください。
The choice each endpoint makes about connection IDs during the handshake is authenticated by including all values in transport parameters; see Section 7.4. This ensures that all connection IDs used for the handshake are also authenticated by the cryptographic handshake.
各エンドポイントは、ハンドシェイク中に接続IDを実行することで、トランスポートパラメータ内のすべての値を含めることによって認証されます。7.4節を参照してください。これにより、ハンドシェイクに使用されているすべての接続IDも暗号化ハンドシェイクによって認証されます。
Each endpoint includes the value of the Source Connection ID field from the first Initial packet it sent in the initial_source_connection_id transport parameter; see Section 18.2. A server includes the Destination Connection ID field from the first Initial packet it received from the client in the original_destination_connection_id transport parameter; if the server sent a Retry packet, this refers to the first Initial packet received before sending the Retry packet. If it sends a Retry packet, a server also includes the Source Connection ID field from the Retry packet in the retry_source_connection_id transport parameter.
各エンドポイントは、initial_source_connection_id トランスポートパラメータで送信された最初の初期パケットからのソース接続IDフィールドの値を含みます。18.2節を参照してください。サーバは、ofoliginal_destination_connection_id トランスポートパラメータのクライアントから受信した最初の初期パケットから宛先接続IDフィールドを含む。サーバが再試行パケットを送信した場合、これは再試行パケットを送信する前に受信された最初の初期パケットを指す。リトライパケットを送信すると、サーバは retry_source_connection_id トランスポートパラメータの再試行パケットからの送信元接続IDフィールドも含む。
The values provided by a peer for these transport parameters MUST match the values that an endpoint used in the Destination and Source Connection ID fields of Initial packets that it sent (and received, for servers). Endpoints MUST validate that received transport parameters match received connection ID values. Including connection ID values in transport parameters and verifying them ensures that an attacker cannot influence the choice of connection ID for a successful connection by injecting packets carrying attacker-chosen connection IDs during the handshake.
これらのトランスポートパラメータのピアによって提供される値は、送信された初期パケットの宛先とソース接続IDフィールドで使用されているエンドポイントが送信された（およびサーバーに対して受信されます）の値と一致する必要があります。エンドポイントは、受信したトランスポートパラメータが受信接続ID値と一致することを検証する必要があります。トランスポートパラメータの接続ID値を含み、それらを検証すると、ハンドシェイク中に攻撃者が選択した接続IDを伝送するパケットを注入することで、接続が成功した場合の接続IDの選択に影響を与えることができます。
An endpoint MUST treat the absence of the initial_source_connection_id transport parameter from either endpoint or the absence of the original_destination_connection_id transport parameter from the server as a connection error of type TRANSPORT_PARAMETER_ERROR.
エンドポイントは、いずれかのエンドポイントからの initial_source_connection_id トランスポートパラメータの欠如、またはサーバーからの original_destination_connection_id トランスポートパラメータの欠如を、タイプ TRANSPORT_PARAMETER_ERROR の接続エラーとして処理する必要があります。
An endpoint MUST treat the following as a connection error of type TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:
エンドポイントは、TRANSPORT_PARAMETER_ERROR または PROTOCOL_VIOLATION の種類の接続エラーとして次のものを扱う必要があります。
* absence of the retry_source_connection_id transport parameter from the server after receiving a Retry packet,
* 再試行パケットを受信した後、サーバーから retry_source_connection_id トランスポートパラメータがない場合、
* presence of the retry_source_connection_id transport parameter when no Retry packet was received, or
* 再試行パケットが受信されなかったときの retry_source_connection_id トランスポートパラメータがある場合、または
* a mismatch between values received from a peer in these transport parameters and the value sent in the corresponding Destination or Source Connection ID fields of Initial packets.
* これらのトランスポートパラメータのピアから受信された値と、初期パケットの対応する宛先またはソース接続IDフィールドに送信された値の間の不一致。
If a zero-length connection ID is selected, the corresponding transport parameter is included with a zero-length value.
長さゼロの接続IDが選択されている場合、対応するトランスポートパラメータは長さゼロの値に含まれます。
Figure 7 shows the connection IDs (with DCID=Destination Connection ID, SCID=Source Connection ID) that are used in a complete handshake. The exchange of Initial packets is shown, plus the later exchange of 1-RTT packets that includes the connection ID established during the handshake.
図7は、完全なハンドシェイクで使用されている接続ID（DCID =宛先接続ID、SCID = Source Connection ID）を示しています。初期パケットの交換は、ハンドシェイク中に確立された接続IDを含む1-RTTパケットの後半の交換を示しています。
Client Server
Initial: DCID=S1, SCID=C1 ->
<- Initial: DCID=C1, SCID=S3
...
1-RTT: DCID=S3 ->
<- 1-RTT: DCID=C1
Figure 7: Use of Connection IDs in a Handshake
図7：ハンドシェイク内の接続IDの使用
Figure 8 shows a similar handshake that includes a Retry packet.
リトライパケットを含む同様のハンドシェイクを示す図です。
Client Server
Initial: DCID=S1, SCID=C1 ->
<- Retry: DCID=C1, SCID=S2
Initial: DCID=S2, SCID=C1 ->
<- Initial: DCID=C1, SCID=S3
...
1-RTT: DCID=S3 ->
<- 1-RTT: DCID=C1
Figure 8: Use of Connection IDs in a Handshake with Retry
図8：リトライを使用したハンドシェイク内の接続IDの使用
In both cases (Figures 7 and 8), the client sets the value of the initial_source_connection_id transport parameter to "C1".
どちらの場合（図7と図8）、クライアントはinitial_source_connection_idトランスポートパラメータの値を "C1" に設定します。
When the handshake does not include a Retry (Figure 7), the server sets original_destination_connection_id to "S1" (note that this value is chosen by the client) and initial_source_connection_id to "S3". In this case, the server does not include a retry_source_connection_id transport parameter.
ハンドシェイクに再試行が含まれていない場合（図7）、サーバーはoriginal_destination_connection_idを "S1" に設定します（この値はクライアントによって選択され、initial_source_connection_id "S3" を設定します。この場合、サーバーはRETRY_SOURCE_CONNECTION_IDトランスポートパラメータを含まない。
When the handshake includes a Retry (Figure 8), the server sets original_destination_connection_id to "S1", retry_source_connection_id to "S2", and initial_source_connection_id to "S3".
ハンドシェイクが再試行を含む場合（図8）、サーバはriniginal_destination_connection_idを "S1"、retry_source_connection_id に "S2"、initial_source_connection_id を "S3" に設定します。
During connection establishment, both endpoints make authenticated declarations of their transport parameters. Endpoints are required to comply with the restrictions that each parameter defines; the description of each parameter includes rules for its handling.
接続確立中に、両方のエンドポイントはそれらのトランスポートパラメータの認証済み宣言を行います。エンドポイントは、各パラメータが定義する制限事項に準拠するために必要です。各パラメータの説明には、その処理のための規則が含まれています。
Transport parameters are declarations that are made unilaterally by each endpoint. Each endpoint can choose values for transport parameters independent of the values chosen by its peer.
トランスポートパラメータは、各エンドポイントによって一方的に行われる宣言です。各エンドポイントは、ピアによって選択された値とは無関係にトランスポートパラメータの値を選択できます。
The encoding of the transport parameters is detailed in Section 18.
トランスポートパラメータの符号化はセクション18に詳述されています。
QUIC includes the encoded transport parameters in the cryptographic handshake. Once the handshake completes, the transport parameters declared by the peer are available. Each endpoint validates the values provided by its peer.
QUICには、暗号化ハンドシェイクの符号化されたトランスポートパラメータが含まれています。ハンドシェイクが完了すると、ピアによって宣言されたトランスポートパラメータが利用可能です。各エンドポイントは、そのピアによって提供される値を検証します。
Definitions for each of the defined transport parameters are included in Section 18.2.
定義された各トランスポートパラメータの定義はセクション18.2に含まれています。
An endpoint MUST treat receipt of a transport parameter with an invalid value as a connection error of type TRANSPORT_PARAMETER_ERROR.
エンドポイントは、TRANSPORT_PARAMETER_ERROR 型の接続エラーとして無効な値を持つトランスポートパラメータの受信を扱う必要があります。
An endpoint MUST NOT send a parameter more than once in a given transport parameters extension. An endpoint SHOULD treat receipt of duplicate transport parameters as a connection error of type TRANSPORT_PARAMETER_ERROR.
エンドポイントは、指定されたトランスポートパラメータの拡張子に複数のパラメータを複数回送信してはなりません。エンドポイントは、TRANSPORT_PARAMETER_ERROR 型の接続エラーとしての重複トランスポートパラメータの受信を扱う必要があります。
Endpoints use transport parameters to authenticate the negotiation of connection IDs during the handshake; see Section 7.3.
エンドポイントは、ハンドシェイク中の接続IDのネゴシエーションを認証するためにトランスポートパラメータを使用します。7.3節を参照してください。
ALPN (see [ALPN]) allows clients to offer multiple application protocols during connection establishment. The transport parameters that a client includes during the handshake apply to all application protocols that the client offers. Application protocols can recommend values for transport parameters, such as the initial flow control limits. However, application protocols that set constraints on values for transport parameters could make it impossible for a client to offer multiple application protocols if these constraints conflict.
ALPN（[ALPN]参照）は、接続確立中にクライアントが複数のアプリケーションプロトコルを提供できるようにします。ハンドシェイク中にクライアントが含まれるトランスポートパラメータは、クライアントが提供するすべてのアプリケーションプロトコルに適用されます。アプリケーションプロトコルは、最初のフロー制御の制限などのトランスポートパラメータの値を推奨することができます。ただし、トランスポートパラメータの値に対して制約を設定するアプリケーションプロトコルは、これらの制約が競合すると、クライアントが複数のアプリケーションプロトコルを提供することが不可能になる可能性があります。
Using 0-RTT depends on both client and server using protocol parameters that were negotiated from a previous connection. To enable 0-RTT, endpoints store the values of the server transport parameters with any session tickets it receives on the connection. Endpoints also store any information required by the application protocol or cryptographic handshake; see Section 4.6 of [QUIC-TLS]. The values of stored transport parameters are used when attempting 0-RTT using the session tickets.
0-RTTを使用すると、以前の接続からネゴシエートされたプロトコルパラメータを使用して、クライアントとサーバーの両方によって異なります。0-RTTを有効にするには、エンドポイントは、接続を受け取るセッションチケットとサーバー転送パラメータの値を格納します。エンドポイントは、アプリケーションプロトコルまたは暗号化ハンドシェイクに必要な情報も保存します。[QUIC-TLS]のセクション4.6を参照してください。保存されたトランスポートパラメータの値は、セッションチケットを使用して0-RTTを試行するときに使用されます。
Remembered transport parameters apply to the new connection until the handshake completes and the client starts sending 1-RTT packets. Once the handshake completes, the client uses the transport parameters established in the handshake. Not all transport parameters are remembered, as some do not apply to future connections or they have no effect on the use of 0-RTT.
ハンドシェイクが完了し、クライアントが1-RTTパケットの送信を開始するまで、トランスポートパラメータが新しい接続に適用されます。ハンドシェイクが完了すると、クライアントはハンドシェイクで確立されたトランスポートパラメータを使用します。すべてのトランスポートパラメータが覚えているわけではありませんが、将来の接続には適用されないか、0-RTTの使用に影響を与えません。
The definition of a new transport parameter (Section 7.4.2) MUST specify whether storing the transport parameter for 0-RTT is mandatory, optional, or prohibited. A client need not store a transport parameter it cannot process.
新しいトランスポートパラメータの定義（7.4.2節）は、0-RTTのトランスポートパラメータを格納するかどうかを必須、オプション、または禁止されているかを指定する必要があります。クライアントは処理できないトランスポートパラメータを保存する必要はありません。
A client MUST NOT use remembered values for the following parameters: ack_delay_exponent, max_ack_delay, initial_source_connection_id, original_destination_connection_id, preferred_address, retry_source_connection_id, and stateless_reset_token. The client MUST use the server's new values in the handshake instead; if the server does not provide new values, the default values are used.
クライアントは、次のパラメーターに記憶された値を使用してはなりません：ack_delay_exponent、max_ack_delay、initial_source_connection_id、original_destination_connection_id、preferred_address、retry_source_connection_id、およびstateless_reset_token。クライアントは、代わりにハンドシェイクでサーバーの新しい値を使用する必要があります。サーバーが新しい値を提供しない場合は、デフォルト値が使用されます。
A client that attempts to send 0-RTT data MUST remember all other transport parameters used by the server that it is able to process. The server can remember these transport parameters or can store an integrity-protected copy of the values in the ticket and recover the information when accepting 0-RTT data. A server uses the transport parameters in determining whether to accept 0-RTT data.
0-RTTデータを送信しようとするクライアントは、サーバーが処理できるように使用される他のすべてのトランスポートパラメータを覚えている必要があります。サーバーはこれらのトランスポートパラメータを覚えておくことができ、あるいはチケット内の値の完全性保護されたコピーを保存し、0-RTTデータを受け入れるときに情報を回復することができます。サーバは、0-RTTデータを受け入れるかどうかを判断する際にトランスポートパラメータを使用します。
If 0-RTT data is accepted by the server, the server MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT set values for the following parameters (Section 18.2) that are smaller than the remembered values of the parameters.
0-RTTデータがサーバーによって受け入れられると、サーバーは制限を減らしてはいけません.0-RTTデータを使用してクライアントによって違反する可能性のある値を変更してはいけません。特に、0-RTTデータを受け入れるサーバーは、パラメータの記憶されている値よりも小さい以下のパラメータ（セクション18.2）に値を設定してはなりません。
* active_connection_id_limit
* active_connection_id_limit
* initial_max_data
* initial_max_data
* initial_max_stream_data_bidi_local
* initial_max_stream_data_bidi_local
* initial_max_stream_data_bidi_remote
* initial_max_stream_data_bidi_remote
* initial_max_stream_data_uni
* initial_max_stream_data_uni
* initial_max_streams_bidi
* initial_max_streams_bidi
* initial_max_streams_uni
* initial_max_streams_uni
Omitting or setting a zero value for certain transport parameters can result in 0-RTT data being enabled but not usable. The applicable subset of transport parameters that permit the sending of application data SHOULD be set to non-zero values for 0-RTT. This includes initial_max_data and either (1) initial_max_streams_bidi and initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni and initial_max_stream_data_uni.
特定のトランスポートパラメータのゼロ値を省略または設定すると、0-RTTデータが有効になりますが、使用できなくなる可能性があります。 アプリケーションデータの送信を許可するトランスポートパラメータの該当するサブセットは、0-RTTに対してゼロ以外の値に設定する必要があります。 これには、initial_max_dataと、（1）initial_max_streams_bidiとinitial_max_stream_data_bidi_remote、または（2）initial_max_streams_uniとinitial_max_stream_data_uniのいずれかが含まれます。
A server might provide larger initial stream flow control limits for streams than the remembered values that a client applies when sending 0-RTT. Once the handshake completes, the client updates the flow control limits on all sending streams using the updated values of initial_max_stream_data_bidi_remote and initial_max_stream_data_uni.
サーバーは、0-RTTを送信するときにクライアントが適用する記憶された値よりも大きい初期ストリームフロー制御制限をストリームに提供する場合があります。 ハンドシェイクが完了すると、クライアントは、initial_max_stream_data_bidi_remoteおよびinitial_max_stream_data_uniの更新された値を使用して、すべての送信ストリームのフロー制御制限を更新します。
A server MAY store and recover the previously sent values of the max_idle_timeout, max_udp_payload_size, and disable_active_migration parameters and reject 0-RTT if it selects smaller values. Lowering the values of these parameters while also accepting 0-RTT data could degrade the performance of the connection. Specifically, lowering the max_udp_payload_size could result in dropped packets, leading to worse performance compared to rejecting 0-RTT data outright.
サーバーは、以前に送信されたmax_idle_timeout、max_udp_payload_size、およびdisable_active_migrationパラメータの値を保存および回復し、小さい値を選択した場合は0-RTTを拒否してもよい[MAY]。 0-RTTデータも受け入れながらこれらのパラメーターの値を下げると、接続のパフォーマンスが低下する可能性があります。 具体的には、max_udp_payload_sizeを下げると、パケットがドロップされ、0-RTTデータを完全に拒否する場合に比べてパフォーマンスが低下する可能性があります。
A server MUST reject 0-RTT data if the restored values for transport parameters cannot be supported.
トランスポートパラメータの復元された値をサポートできない場合、サーバーは0-RTTデータを棄却する必要があります。
When sending frames in 0-RTT packets, a client MUST only use remembered transport parameters; importantly, it MUST NOT use updated values that it learns from the server's updated transport parameters or from frames received in 1-RTT packets. Updated values of transport parameters from the handshake apply only to 1-RTT packets. For instance, flow control limits from remembered transport parameters apply to all 0-RTT packets even if those values are increased by the handshake or by frames sent in 1-RTT packets. A server MAY treat the use of updated transport parameters in 0-RTT as a connection error of type PROTOCOL_VIOLATION.
0-RTTパケットでフレームを送信する場合、クライアントは記憶されたトランスポートパラメータのみを使用する必要があります。 重要なのは、サーバーの更新されたトランスポートパラメータまたは1-RTTパケットで受信されたフレームから学習した更新された値を使用してはならないということです。 ハンドシェイクからのトランスポートパラメータの更新された値は、1-RTTパケットにのみ適用されます。 たとえば、記憶されたトランスポートパラメータからのフロー制御制限は、ハンドシェイクまたは1-RTTパケットで送信されたフレームによって値が増加した場合でも、すべての0-RTTパケットに適用されます。 サーバーは、0-RTTで更新されたトランスポートパラメータの使用を、PROTOCOL_VIOLATIONタイプの接続エラーとして扱うことができます。
New transport parameters can be used to negotiate new protocol behavior. An endpoint MUST ignore transport parameters that it does not support. The absence of a transport parameter therefore disables any optional protocol feature that is negotiated using the parameter. As described in Section 18.1, some identifiers are reserved in order to exercise this requirement.
新しいトランスポートパラメータを使用して新しいプロトコル動作をネゴシエートできます。エンドポイントは、サポートされていないトランスポートパラメータを無視する必要があります。したがって、トランスポートパラメータがないことで、パラメータを使用してネゴシエートされたオプションのプロトコル機能を無効にします。セクション18.1に記載されているように、この要件を行使するためにいくつかの識別子が予約されています。
A client that does not understand a transport parameter can discard it and attempt 0-RTT on subsequent connections. However, if the client adds support for a discarded transport parameter, it risks violating the constraints that the transport parameter establishes if it attempts 0-RTT. New transport parameters can avoid this problem by setting a default of the most conservative value. Clients can avoid this problem by remembering all parameters, even those not currently supported.
トランスポートパラメータを理解していないクライアントはそれを破棄し、後続の接続で0-RTTを試みることができます。ただし、クライアントが破棄されたトランスポートパラメータのサポートを追加した場合、トランスポートパラメータが0-RTTであれば確立された制約に違反します。新しいトランスポートパラメータは、最も保守的な値のデフォルトを設定することでこの問題を回避できます。現在サポートされていないすべてのパラメータを記憶することで、クライアントはこの問題を回避できます。
New transport parameters can be registered according to the rules in Section 22.3.
セクション22.3の規則に従って新しいトランスポートパラメータを登録できます。
Implementations need to maintain a buffer of CRYPTO data received out of order. Because there is no flow control of CRYPTO frames, an endpoint could potentially force its peer to buffer an unbounded amount of data.
実装は、順不同で受信された暗号データのバッファを維持する必要があります。暗号フレームのフロー制御がないため、エンドポイントはそのピアが無制限の量のデータをバッファリングする可能性があります。
Implementations MUST support buffering at least 4096 bytes of data received in out-of-order CRYPTO frames. Endpoints MAY choose to allow more data to be buffered during the handshake. A larger limit during the handshake could allow for larger keys or credentials to be exchanged. An endpoint's buffer size does not need to remain constant during the life of the connection.
実装は、順不同暗号フレームで受信された少なくとも4096バイトのデータをバッファリングする必要があります。エンドポイントは、ハンドシェイク中により多くのデータをバッファリングすることを許可することを選択できます。ハンドシェイク中により大きな制限が大きいほど、より大きなキーや資格情報を交換することができます。エンドポイントのバッファサイズは、接続の寿命の間に一定のままである必要はありません。
Being unable to buffer CRYPTO frames during the handshake can lead to a connection failure. If an endpoint's buffer is exceeded during the handshake, it can expand its buffer temporarily to complete the handshake. If an endpoint does not expand its buffer, it MUST close the connection with a CRYPTO_BUFFER_EXCEEDED error code.
ハンドシェイク中に暗号フレームをバッファすることができないことは、接続障害につながる可能性があります。ハンドシェイク中にエンドポイントのバッファを超えると、ハンドシェイクを完了するためにバッファを一時的に拡張できます。エンドポイントがそのバッファを展開しない場合は、CRYPTO_BUFFER_EXCEEDED エラーコードとの接続を閉じる必要があります。
Once the handshake completes, if an endpoint is unable to buffer all data in a CRYPTO frame, it MAY discard that CRYPTO frame and all CRYPTO frames received in the future, or it MAY close the connection with a CRYPTO_BUFFER_EXCEEDED error code. Packets containing discarded CRYPTO frames MUST be acknowledged because the packet has been received and processed by the transport even though the CRYPTO frame was discarded.
ハンドシェイクが完了すると、エンドポイントが暗号フレーム内のすべてのデータをバッファすることができない場合、その暗号フレームと将来受信されたすべての暗号フレームを破棄するか、または CRYPTO_BUFFER_EXCEEDED エラーコードと接続を閉じることがあります。暗号フレームが破棄されていても、パケットがトランスポートによって受信され処理されているため、廃棄された暗号フレームを含むパケットを承認する必要があります。
Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own.
アドレス検証により、エンドポイントをトラフィック増幅攻撃に使用できないようにします。このような攻撃では、パケットは被害者を識別する偽装された送信元アドレス情報を含むサーバーに送信されます。サーバーがそのパケットに応答してより多くのパケットを生成した場合、攻撃者はサーバーを使用して自分自身で送信できるよりも多くのデータを犠牲にすることができます。
The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.
増幅攻撃に対する一次防御は、ピアがそれが主張する輸送アドレスでパケットを受信することができることを検証している。したがって、まだ検証されていないアドレスからパケットを受信した後、エンドポイントは、そのアドレスから受信したデータ量の3倍に送信されていないアドレスに送信されたデータの量を制限する必要があります。応答の大きさのこの制限は、増幅防止限界として知られています。
Address validation is performed both during connection establishment (see Section 8.1) and during connection migration (see Section 8.2).
アドレス検証は、接続確立中、および接続移行中に両方ともの両方で行われます（セクション8.2を参照）。
Connection establishment implicitly provides address validation for both endpoints. In particular, receipt of a packet protected with Handshake keys confirms that the peer successfully processed an Initial packet. Once an endpoint has successfully processed a Handshake packet from the peer, it can consider the peer address to have been validated.
接続確立は暗黙的に両方のエンドポイントに対してアドレス検証を提供します。特に、ハンドシェイクキーで保護されたパケットの受信は、ピアが初期パケットを正常に処理したことを確認します。エンドポイントがピアからハンドシェイクパケットを正常に処理したら、それは検証されたピアアドレスを検討することができます。
Additionally, an endpoint MAY consider the peer address validated if the peer uses a connection ID chosen by the endpoint and the connection ID contains at least 64 bits of entropy.
さらに、エンドポイントは、ピアがエンドポイントによって選択された接続IDを使用し、接続IDに少なくとも64ビットのエントロピーが含まれている場合に検証されたピアアドレスを検討することができます。
For the client, the value of the Destination Connection ID field in its first Initial packet allows it to validate the server address as a part of successfully processing any packet. Initial packets from the server are protected with keys that are derived from this value (see Section 5.2 of [QUIC-TLS]). Alternatively, the value is echoed by the server in Version Negotiation packets (Section 6) or included in the Integrity Tag in Retry packets (Section 5.8 of [QUIC-TLS]).
クライアントの最初の初期パケット内の宛先接続IDフィールドの値は、パケットを正常に処理した部分としてサーバーアドレスを検証できます。サーバーからの初期パケットは、この値から派生したキーで保護されています（[QUIC-TLSのセクション5.2を参照）。あるいは、値は、バージョンネゴシエーションパケット（セクション6）でサーバーによってエコーされるか、再試行パケットのIntegrityタグに含まれます（[QUIC-TLS]のセクション5.8）。
Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received. This limits the magnitude of any amplification attack that can be mounted using spoofed source addresses. For the purposes of avoiding amplification prior to address validation, servers MUST count all of the payload bytes received in datagrams that are uniquely attributed to a single connection. This includes datagrams that contain packets that are successfully processed and datagrams that contain packets that are all discarded.
クライアントアドレスを検証する前に、サーバーは受信したバイト数と同じ3回以上のバイトを送信してはなりません。これにより、偽装された送信元アドレスを使用してマウントできる増幅攻撃の大きさが制限されます。アドレス検証の前に増幅を回避する目的で、サーバーは、単一の接続に一意に帰属しているデータグラムで受信されたペイロードバイトのすべてをカウントしなければなりません。これには、正常に処理されたパケットと、すべて破棄されたパケットを含むデータグラムを含むデータグラムが含まれます。
Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, adding PADDING frames as necessary. A client that sends padded datagrams allows the server to send more data prior to completing address validation.
クライアントは、初期パケットを含むUDPデータグラムに少なくとも1200バイトのUDPペイロードがあることを確認し、必要に応じてパディングフレームを追加してください。パディングされたデータグラムを送信するクライアントは、アドレス検証を完了する前にサーバーがより多くのデータを送信することを可能にします。
Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial or Handshake packets. A deadlock could occur when the server reaches its anti-amplification limit and the client has received acknowledgments for all the data it has sent. In this case, when the client has no reason to send additional packets, the server will be unable to send more data because it has not validated the client's address. To prevent this deadlock, clients MUST send a packet on a Probe Timeout (PTO); see Section 6.2 of [QUIC-RECOVERY]. Specifically, the client MUST send an Initial packet in a UDP datagram that contains at least 1200 bytes if it does not have Handshake keys, and otherwise send a Handshake packet.
サーバーからの最初またはハンドシェイクパケットの損失は、クライアントが追加の初期またはハンドシェイクパケットを送信しない場合、デッドロックを引き起こす可能性があります。サーバーがそのアンチアンプの制限に達し、クライアントが送信したすべてのデータに対して承認を受信したときにデッドロックが発生する可能性があります。この場合、クライアントに追加のパケットを送信する理由がない場合、クライアントのアドレスが検証されていないため、サーバーはより多くのデータを送信できません。このデッドロックを防ぐために、クライアントはプローブタイムアウト（PTO）にパケットを送信する必要があります。[QUIC-RECOVERY]の6.2項を参照してください。具体的には、クライアントはハンドシェイクキーがない場合は少なくとも1200バイトを含むUDPデータグラムに初期パケットを送信しなければならず、そうでなければハンドシェイクパケットを送信する必要があります。
A server might wish to validate the client address before starting the cryptographic handshake. QUIC uses a token in the Initial packet to provide address validation prior to completing the handshake. This token is delivered to the client during connection establishment with a Retry packet (see Section 8.1.2) or in a previous connection using the NEW_TOKEN frame (see Section 8.1.3).
サーバーは、暗号化ハンドシェイクを開始する前にクライアントアドレスを検証したい場合があります。QUICは、ハンドシェイクを完了する前にアドレス検証を提供するために、最初のパケット内のトークンを使用します。このトークンは、リトライパケット（セクション8.1.2参照）またはNEW_TOKENフレームを使用した以前の接続で接続確立中にクライアントに配信されます（セクション8.1.3を参照）。
In addition to sending limits imposed prior to address validation, servers are also constrained in what they can send by the limits set by the congestion controller. Clients are only constrained by the congestion controller.
アドレス検証の前に課された制限を送信することに加えて、サーバーは輻輳コントローラによって設定された制限によって送信できるものにも制約されます。クライアントは輻輳コントローラによってのみ制限されます。
A token sent in a NEW_TOKEN frame or a Retry packet MUST be constructed in a way that allows the server to identify how it was provided to a client. These tokens are carried in the same field but require different handling from servers.
NEW_TOKENフレームまたは再試行パケットで送信されたトークンは、サーバーがクライアントに提供された方法を識別できるようにするような方法で構築する必要があります。これらのトークンは同じ分野で実行されますが、サーバーから異なる処理が必要です。
Upon receiving the client's Initial packet, the server can request address validation by sending a Retry packet (Section 17.2.5) containing a token. This token MUST be repeated by the client in all Initial packets it sends for that connection after it receives the Retry packet.
クライアントの初期パケットを受信すると、サーバはトークンを含むリトライパケット（セクション17.2.5）を送信することによってアドレス検証を要求することができる。このトークンは、リトライパケットを受信した後に送信されたすべての初期パケットでクライアントによって繰り返されなければなりません。
In response to processing an Initial packet containing a token that was provided in a Retry packet, a server cannot send another Retry packet; it can only refuse the connection or permit it to proceed.
再試行パケットに提供されたトークンを含む初期パケットを処理することに応答して、サーバは別の再試行パケットを送信することができない。接続を拒否したり、続行することができます。
As long as it is not possible for an attacker to generate a valid token for its own address (see Section 8.1.4) and the client is able to return that token, it proves to the server that it received the token.
攻撃者が独自のアドレスの有効なトークンを生成できない限り（セクション8.1.4を参照）、クライアントはそのトークンを返すことができるため、トークンを受信したサーバーに証明されています。
A server can also use a Retry packet to defer the state and processing costs of connection establishment. Requiring the server to provide a different connection ID, along with the original_destination_connection_id transport parameter defined in Section 18.2, forces the server to demonstrate that it, or an entity it cooperates with, received the original Initial packet from the client. Providing a different connection ID also grants a server some control over how subsequent packets are routed. This can be used to direct connections to a different server instance.
サーバは、リトライパケットを使用して、接続施設の状態と処理コストを延期することもできる。セクション18.2で定義されているoriginal_destination_connection_idトランスポートパラメータとともに、サーバーに異なる接続IDを提供する必要があり、サーバーにそれを実証したり、クライアントと協働しているエンティティとは、クライアントから元の初期パケットを受信します。さまざまな接続IDを提供すると、サーバーは後続のパケットのルーティング方法を制御します。これは、別のサーバーインスタンスへの接続を直接接続するために使用できます。
If a server receives a client Initial that contains an invalid Retry token but is otherwise valid, it knows the client will not accept another Retry token. The server can discard such a packet and allow the client to time out to detect handshake failure, but that could impose a significant latency penalty on the client. Instead, the server SHOULD immediately close (Section 10.2) the connection with an INVALID_TOKEN error. Note that a server has not established any state for the connection at this point and so does not enter the closing period.
サーバーが無効な再試行トークンを含むが有効なクライアントの初期を受信した場合、クライアントは別のリトライトークンを受け入れないことがわかります。サーバーはそのようなパケットを破棄し、クライアントがハンドシェイクの失敗を検出するためにタイムアウトすることができますが、それはクライアントに大きな待ち時間のペナルティを課す可能性があります。代わりに、サーバーはINVALID_TOKENエラーとの接続をすぐに閉じるべきです（セクション10.2）。サーバーはこの時点で接続の状態を確立していないため、クローズ期間に入りません。
A flow showing the use of a Retry packet is shown in Figure 9.
リトライパケットの使用を示すフローを図9に示す。
Client Server
Initial[0]: CRYPTO[CH] ->
<- Retry+Token
Initial+Token[1]: CRYPTO[CH] ->
Initial[0]: CRYPTO[SH] ACK[1]
Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."]
Figure 9: Example Handshake with Retry
図9：リトライとのハンドシェイクの例
A server MAY provide clients with an address validation token during one connection that can be used on a subsequent connection. Address validation is especially important with 0-RTT because a server potentially sends a significant amount of data to a client in response to 0-RTT data.
サーバは、後続の接続で使用できる1つの接続中にアドレス検証トークンをクライアントに提供することができる。0-RTTデータに応答して、サーバーがクライアントに大量のデータを送信する可能性があるため、アドレス検証は0-RTTでは特に重要です。
The server uses the NEW_TOKEN frame (Section 19.7) to provide the client with an address validation token that can be used to validate future connections. In a future connection, the client includes this token in Initial packets to provide address validation. The client MUST include the token in all Initial packets it sends, unless a Retry replaces the token with a newer one. The client MUST NOT use the token provided in a Retry for future connections. Servers MAY discard any Initial packet that does not carry the expected token.
サーバーはNEW_TOKENフレーム（セクション19.7）を使用して、将来の接続を検証するために使用できるアドレス検証トークンをクライアントに提供します。将来の接続では、クライアントはアドレス検証を提供するために初期パケット内のこのトークンを含む。再試行が新しい1つを持つトークンを置き換えない限り、クライアントは送信されたすべてのパケット内のトークンを送信する必要があります。クライアントは、将来の接続のために再試行に提供されているトークンを使用してはいけません。サーバーは、予想されるトークンを持たない初期パケットを破棄することがあります。
Unlike the token that is created for a Retry packet, which is used immediately, the token sent in the NEW_TOKEN frame can be used after some period of time has passed. Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time. A server can store the expiration time or include it in an encrypted form in the token.
すぐに使用されているリトライパケットに対して作成されたトークンとは異なり、NEW_TOKEN フレームで送信されたトークンは何らかの期間が経過した後に使用できます。したがって、トークンは有効期限を持つべきであり、これは明示的な有効期限または有効期限を動的に計算するために使用され得る発行タイムスタンプのいずれかであり得る。サーバーは有効期限を保存するか、またはトークンの暗号化された形式に含めることができます。
A token issued with NEW_TOKEN MUST NOT include information that would allow values to be linked by an observer to the connection on which it was issued. For example, it cannot include the previous connection ID or addressing information, unless the values are encrypted. A server MUST ensure that every NEW_TOKEN frame it sends is unique across all clients, with the exception of those sent to repair losses of previously sent NEW_TOKEN frames. Information that allows the server to distinguish between tokens from Retry and NEW_TOKEN MAY be accessible to entities other than the server.
NEW_TOKENで発行されたトークンには、値を発行した接続にオブザーバによってリンクをリンクできるようにするための情報は含まれていません。たとえば、値が暗号化されていない限り、以前の接続IDまたはアドレス指定情報を含めることはできません。サーバーは、それが送信するすべての NEW_TOKEN フレームがすべてのクライアントにわたって一意であることを確認しなければなりません。サーバーを再試行から区別できるようにする情報は、サーバー以外のエンティティにアクセスできます。
It is unlikely that the client port number is the same on two different connections; validating the port is therefore unlikely to be successful.
クライアントポート番号が2つの異なる接続で同じになる可能性は低いです。したがって、ポートを検証することは成功する可能性は低いです。
A token received in a NEW_TOKEN frame is applicable to any server that the connection is considered authoritative for (e.g., server names included in the certificate). When connecting to a server for which the client retains an applicable and unused token, it SHOULD include that token in the Token field of its Initial packet. Including a token might allow the server to validate the client address without an additional round trip. A client MUST NOT include a token that is not applicable to the server that it is connecting to, unless the client has the knowledge that the server that issued the token and the server the client is connecting to are jointly managing the tokens. A client MAY use a token from any previous connection to that server.
NEW_TOKEN フレームで受信されたトークンは、接続が信頼できるもの（例えば、証明書に含まれるサーバー名）と見なされる任意のサーバーに適用されます。クライアントが該当するトークンと未使用のトークンを保持するサーバーに接続するときは、その初期パケットのトークンフィールドにそのトークンを含める必要があります。トークンを含めると、サーバーが追加のラウンドトリップなしでクライアントアドレスを検証できるようにする可能性があります。クライアントが、トークンを発行したサーバーとクライアントが接続しているサーバーが接続されていることをクライアントに接続していない限り、クライアントに接続しているトークンを含めてはいけません。クライアントは、そのサーバーへの以前の接続からトークンを使用できます。
A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. Clients that want to break continuity of identity with a server can discard tokens provided using the NEW_TOKEN frame. In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection attempts.
トークンを使用すると、サーバーはトークンが発行された接続と使用されている接続との間のアクティビティを関連付けることができます。サーバーとの識別の継続性を壊したいクライアントは、NEW_TOKEN フレームを使用して提供されるトークンを廃棄できます。比較すると、リトライパケットで取得されたトークンは接続試行中にすぐに使用されなければならず、後続の接続試行では使用できません。
A client SHOULD NOT reuse a token from a NEW_TOKEN frame for different connection attempts. Reusing a token allows connections to be linked by entities on the network path; see Section 9.5.
クライアントは、接続試行のために NEW_TOKEN フレームからトークンを再利用しないでください。トークンを再利用することで、接続をネットワークパス上のエンティティによってリンクすることができます。9.5節を参照してください。
Clients might receive multiple tokens on a single connection. Aside from preventing linkability, any token can be used in any connection attempt. Servers can send additional tokens to either enable address validation for multiple connection attempts or replace older tokens that might become invalid. For a client, this ambiguity means that sending the most recent unused token is most likely to be effective. Though saving and using older tokens have no negative consequences, clients can regard older tokens as being less likely to be useful to the server for address validation.
クライアントは単一の接続で複数のトークンを受信する可能性があります。リンク性を防ぐことを目的とした場合、どんな接続試行でもトークンを使用できます。サーバーは追加のトークンを送信でき、複数の接続試行のためのアドレス検証を有効にするか、無効になる可能性のある古いトークンを置き換えることができます。クライアントの場合、このあいまいさは、最新の未使用のトークンを送信することが最も効果的である可能性が最も高いことを意味します。古いトークンを保存して使用することは悪影響を及ぼしませんが、クライアントは古いトークンをアドレス検証のためにサーバーに役立つ可能性が低いものとして考えることができます。
When a server receives an Initial packet with an address validation token, it MUST attempt to validate the token, unless it has already completed address validation. If the token is invalid, then the server SHOULD proceed as if the client did not have a validated address, including potentially sending a Retry packet. Tokens provided with NEW_TOKEN frames and Retry packets can be distinguished by servers (see Section 8.1.1), and the latter can be validated more strictly. If the validation succeeds, the server SHOULD then allow the handshake to proceed.
サーバーがアドレス検証トークンを使用して最初のパケットを受信すると、すでにアドレス検証が完了していない限り、トークンの検証を試みる必要があります。トークンが無効な場合、サーバーは、クライアントに検証済みアドレスがないかのようになり、再試行パケットを送信することもできます。NEW_TOKENフレームとリトライパケットを備えたトークンは、サーバーによって区別できます（セクション8.1.1を参照）、後者はより厳密に検証できます。検証が成功すると、サーバーはハンドシェイクを進めることができます。
Note: The rationale for treating the client as unvalidated rather than discarding the packet is that the client might have received the token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if the packet is discarded.
注：クライアントをパケットを破棄するのではなく未検証として扱う理由は、クライアントがNEW_TOKENフレームを使用した以前の接続でトークンを受信した可能性があり、サーバーが状態を失った場合、でトークンを検証できない可能性があるためです。 すべて、パケットが破棄されると接続障害につながります。
In a stateless design, a server can use encrypted and authenticated tokens to pass information to clients that the server can later recover and use to validate a client address. Tokens are not integrated into the cryptographic handshake, and so they are not authenticated. For instance, a client might be able to reuse a token. To avoid attacks that exploit this property, a server can limit its use of tokens to only the information needed to validate client addresses.
ステートレス設計では、サーバーは暗号化され認証されたトークンを使用して、サーバーが後で回復してクライアントアドレスを検証するために使用できるクライアントに情報を渡すことができます。トークンは暗号化ハンドシェイクに統合されていないため、認証されません。たとえば、クライアントはトークンを再利用できる可能性があります。このプロパティを利用する攻撃を避けるために、サーバーはクライアントアドレスを検証するために必要な情報のみにトークンの使用を制限できます。
Clients MAY use tokens obtained on one connection for any connection attempt using the same version. When selecting a token to use, clients do not need to consider other properties of the connection that is being attempted, including the choice of possible application protocols, session tickets, or other connection properties.
クライアントは、同じバージョンを使用している接続の試みについて、1つの接続で取得されたトークンを使用することができます。使用するトークンを選択するとき、クライアントは、可能なアプリケーションプロトコル、セッションチケット、またはその他の接続プロパティの選択を含む、試行されている接続の他のプロパティを考慮する必要はありません。
An address validation token MUST be difficult to guess. Including a random value with at least 128 bits of entropy in the token would be sufficient, but this depends on the server remembering the value it sends to clients.
アドレス検証トークンは推測するのが難しい必要があります。トークン内の少なくとも128ビットのエントロピーを持つランダムな値を含めても十分ですが、これはそれがクライアントに送信する値を記憶するサーバーによって異なります。
A token-based scheme allows the server to offload any state associated with validation to the client. For this design to work, the token MUST be covered by integrity protection against modification or falsification by clients. Without integrity protection, malicious clients could generate or guess values for tokens that would be accepted by the server. Only the server requires access to the integrity protection key for tokens.
トークンベースの方式では、サーバーは検証に関連付けられている状態をクライアントにオフロードできます。この設計が機能するためには、トークンはクライアントによる修正または改ざんに対する完全性保護によってカバーされなければなりません。完全性保護なしで、悪意のあるクライアントは、サーバーによって受け入れられるトークンの値を生成または推測する可能性があります。サーバーだけが、トークンの完全性保護キーへのアクセスを必要とします。
There is no need for a single well-defined format for the token because the server that generates the token also consumes it. Tokens sent in Retry packets SHOULD include information that allows the server to verify that the source IP address and port in client packets remain constant.
トークンを生成するサーバーもそれを消費するので、トークンに単一の明確なフォーマットが必要ではありません。再試行パケットで送信されたトークンには、サーバーがクライアントパケットの送信元IPアドレスとポートが一定のままであることを確認できるようにする必要があります。
Tokens sent in NEW_TOKEN frames MUST include information that allows the server to verify that the client IP address has not changed from when the token was issued. Servers can use tokens from NEW_TOKEN frames in deciding not to send a Retry packet, even if the client address has changed. If the client IP address has changed, the server MUST adhere to the anti-amplification limit; see Section 8. Note that in the presence of NAT, this requirement might be insufficient to protect other hosts that share the NAT from amplification attacks.
NEW_TOKENフレームで送信されたトークンには、サーバーがトークンが発行されたときにクライアントのIPアドレスが変更されていないことをサーバーが検証できるようにする必要があります。クライアントアドレスが変更されていても、サーバーは、NEW_TOKENフレームからトークンを使用できます。クライアントのIPアドレスが変更された場合、サーバーは増幅対策制限に従わなければなりません。セクション8. NATの存在下では、この要件は、Amplification AttacksからNATを共有する他のホストを保護するのに不十分な場合があります。
Attackers could replay tokens to use servers as amplifiers in DDoS attacks. To protect against such attacks, servers MUST ensure that replay of tokens is prevented or limited. Servers SHOULD ensure that tokens sent in Retry packets are only accepted for a short time, as they are returned immediately by clients. Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to be valid for longer but SHOULD NOT be accepted multiple times. Servers are encouraged to allow tokens to be used only once, if possible; tokens MAY include additional information about clients to further narrow applicability or reuse.
攻撃者は、DDoS攻撃の増幅器としてサーバーを使用するようにトークンを再生することができます。このような攻撃から保護するために、サーバーはトークンの再生が防止されているか、または制限されていることを確認する必要があります。サーバーは、再試行パケットで送信されたトークンが短時間でのみ受け入れられていることを確認する必要があります。NEW_TOKENフレーム（セクション19.7）に提供されるトークンは、より長い間有効である必要がありますが、複数回受け入れられないでください。可能であれば、サーバーは一度だけトークンを使用できるようにすることをお勧めします。トークンは、適用可能性または再利用をさらに狭めるためのクライアントに関する追加の情報を含み得る。
Path validation is used by both peers during connection migration (see Section 9) to verify reachability after a change of address. In path validation, endpoints test reachability between a specific local address and a specific peer address, where an address is the 2-tuple of IP address and port.
パスの変更中は、アドレスの変更後に到達可能性を確認するために、パスの検証は両方のピアによって使用されます（セクション9を参照）。PATH検証では、特定のローカルアドレスと特定のピアアドレスとの間のテスト到達可能性をエンドポイントします。ここで、アドレスはIPアドレスとポートの2タプルです。
Path validation tests that packets sent on a path to a peer are received by that peer. Path validation is used to ensure that packets received from a migrating peer do not carry a spoofed source address.
パス検証ピアへのパス上で送信されたパケットがそのピアによって受信されます。パス検証は、移行ピアから受信されたパケットが偽造された送信元アドレスを持たないようにするために使用されます。
Path validation does not validate that a peer can send in the return direction. Acknowledgments cannot be used for return path validation because they contain insufficient entropy and might be spoofed. Endpoints independently determine reachability on each direction of a path, and therefore return reachability can only be established by the peer.
パス検証は、ピアが戻り方向に送信できることを検証しません。承認は、エントロピーが不十分でスプーフされている可能性があるため、リターンパスの検証には使用できません。エンドポイントは、パスの各方向の到達可能性を独立して決定するため、リターンの到達可能性はピアによってのみ確立できます。
Path validation can be used at any time by either endpoint. For instance, an endpoint might check that a peer is still in possession of its address after a period of quiescence.
パス検証は、どちらのエンドポイントでいつでも使用できます。たとえば、エンドポイントは、ピアが静止状態の後にそのアドレスを所有していることを確認することがあります。
Path validation is not designed as a NAT traversal mechanism. Though the mechanism described here might be effective for the creation of NAT bindings that support NAT traversal, the expectation is that one endpoint is able to receive packets without first having sent a packet on that path. Effective NAT traversal needs additional synchronization mechanisms that are not provided here.
パス検証は、NATトラバーサルメカニズムとして設計されていません。ここで説明されているメカニズムは、NATトラバーサルをサポートするNATバインディングの作成に有効であるかもしれませんが、期待は1つのエンドポイントが最初にそのパス上にパケットを送信したことなくパケットを受信できることです。効果的なNATトラバーサルは、ここで提供されていない追加の同期メカニズムを必要とします。
An endpoint MAY include other frames with the PATH_CHALLENGE and PATH_RESPONSE frames used for path validation. In particular, an endpoint can include PADDING frames with a PATH_CHALLENGE frame for Path Maximum Transmission Unit Discovery (PMTUD); see Section 14.2.1. An endpoint can also include its own PATH_CHALLENGE frame when sending a PATH_RESPONSE frame.
エンドポイントは、PATH_CHALLENGEとPATH_RESPONSEフレームを持つ他のフレームを含めることができます。特に、エンドポイントは、経路最大伝送ユニットディスカバリ（PMTUD）のためのPATH_CHALLENGEフレームを有するパディングフレームを含むことができる。14.2.1項を参照してください。エンドポイントは、PATH_RESPONSEフレームを送信するときにそれ自身のPATH_CHALLENGEフレームを含めることもできます。
An endpoint uses a new connection ID for probes sent from a new local address; see Section 9.5. When probing a new path, an endpoint can ensure that its peer has an unused connection ID available for responses. Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in the same packet, if the peer's active_connection_id_limit permits, ensures that an unused connection ID will be available to the peer when sending a response.
エンドポイントは、新しいローカルアドレスから送信されたプローブの新しい接続IDを使用します。9.5節を参照してください。新しいパスを調べるとき、エンドポイントは、そのピアに応答に使用可能な未使用の接続IDがあることを確認できます。Peerのactive_connection_id_limitが許可されている場合は、同じパケット内のNEW_CONNECTION_IDとPATH_CHALLENGEフレームを送信すると、応答を送信するときに未使用の接続IDがピアに使用可能になるようにします。
An endpoint can choose to simultaneously probe multiple paths. The number of simultaneous paths used for probes is limited by the number of extra connection IDs its peer has previously supplied, since each new local address used for a probe requires a previously unused connection ID.
エンドポイントは、複数のパスを同時にプローブすることを選択できます。プローブに使用される同時経路の数は、プローブに使用された各ローカルアドレスに以前に未使用の接続IDを必要とするため、そのピアが以前に提供された追加の接続IDの数によって制限されます。
To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing an unpredictable payload on the path to be validated.
パス検証を開始するために、エンドポイントは、検証されるべきパス上の予測不可能なペイロードを含むPATH_CHALLENGEフレームを送信します。
An endpoint MAY send multiple PATH_CHALLENGE frames to guard against packet loss. However, an endpoint SHOULD NOT send multiple PATH_CHALLENGE frames in a single packet.
エンドポイントは、パケット損失を防ぐために複数のPATH_CHALLENGEフレームを送信することができます。ただし、エンドポイントは複数のPATH_CHALLENGEフレームを単一のパケットに送信しないでください。
An endpoint SHOULD NOT probe a new path with packets containing a PATH_CHALLENGE frame more frequently than it would send an Initial packet. This ensures that connection migration is no more load on a new path than establishing a new connection.
エンドポイントは、初期パケットを送信するよりも頻繁にPATH_CHALLENGEフレームを含むパケットを使用して新しいパスを調べてはなりません。これにより、接続の移行は新しいパスをオンにしても新しいパスにロードされないようになります。
The endpoint MUST use unpredictable data in every PATH_CHALLENGE frame so that it can associate the peer's response with the corresponding PATH_CHALLENGE.
エンドポイントは、ピアの応答を対応するPATH_CHALLENGEに関連付けることができるように、すべてのPATH_CHALLENGEフレームで予測不可能なデータを使用する必要があります。
An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame to at least the smallest allowed maximum datagram size of 1200 bytes, unless the anti-amplification limit for the path does not permit sending a datagram of this size. Sending UDP datagrams of this size ensures that the network path from the endpoint to the peer can be used for QUIC; see Section 14.
エンドポイントは、パスのデータグラムのデータグラムを送信することを許可しない限り、PATH_CHALLENGEフレームを少なくとも最小の許可された最大データグラム・サイズ1200バイトに含むデータグラムを展開する必要があります。このサイズのUDPデータグラムを送信すると、エンドポイントからピアへのネットワークパスをQUICに使用できるようになります。14を参照してください。
When an endpoint is unable to expand the datagram size to 1200 bytes due to the anti-amplification limit, the path MTU will not be validated. To ensure that the path MTU is large enough, the endpoint MUST perform a second path validation by sending a PATH_CHALLENGE frame in a datagram of at least 1200 bytes. This additional validation can be performed after a PATH_RESPONSE is successfully received or when enough bytes have been received on the path that sending the larger datagram will not result in exceeding the anti-amplification limit.
アンチアンプの制限のためにデータグラムサイズを1200バイトに拡張できない場合、パスMTUは検証されません。経路MTUが十分に大きいことを確認するために、エンドポイントは、少なくとも1200バイトのデータグラム内のPATH_CHALLENGEフレームを送信することによって第2のパス検証を実行しなければならない。この追加の検証は、PATH_RESPONSEが正常に受信された後、またはより大きなデータグラムを送信するパスで十分なバイトが受信された後に実行できます。
Unlike other cases where datagrams are expanded, endpoints MUST NOT discard datagrams that appear to be too small when they contain PATH_CHALLENGE or PATH_RESPONSE.
データグラムが拡張されている他の場合とは異なり、エンドポイントは、PATH_CHALLENGEまたはPATH_RESPONSEを含むときに小さすぎるように見えるデータグラムを破棄してはいけません。
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control.
PATH_CHALLENGEフレームを受信すると、PATH_CHALLENGEフレームに含まれているデータをPATH_RESPONSEフレームにエコーすることでエンドポイントが応答する必要があります。エンドポイントは、輻輳制御によって制約されない限り、PATH_RESPONSEフレームを含むパケットの送信を遅らせるべきではありません。
A PATH_RESPONSE frame MUST be sent on the network path where the PATH_CHALLENGE frame was received. This ensures that path validation by a peer only succeeds if the path is functional in both directions. This requirement MUST NOT be enforced by the endpoint that initiates path validation, as that would enable an attack on migration; see Section 9.3.3.
PATH_CHALLENGEフレームが受信されたネットワークパスでPATH_RESPONSEフレームを送信する必要があります。これにより、パスが両方向に機能している場合、ピアによるパス検証は成功することができます。この要件は、移行への攻撃を可能にするように、パス検証を開始するエンドポイントによって強制されてはいけません。セクション9.3.3を参照してください。
An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame to at least the smallest allowed maximum datagram size of 1200 bytes. This verifies that the path is able to carry datagrams of this size in both directions. However, an endpoint MUST NOT expand the datagram containing the PATH_RESPONSE if the resulting data exceeds the anti-amplification limit. This is expected to only occur if the received PATH_CHALLENGE was not sent in an expanded datagram.
エンドポイントは、PATH_RESPONSEフレームを含むデータグラムを少なくとも最小の許容最大データグラムサイズ1200バイトに展開する必要があります。これにより、パスがこのサイズのデータグラムを両方向に搬送できることを確認します。ただし、エンドポイントは、結果のデータがアンプアンチアンプリミットを超えると、PATH_RESPONSEを含むデータグラムを展開してはなりません。これは、受信したPATH_CHALLENGEが拡張されたデータグラムで送信されなかった場合にのみ発生すると予想されます。
An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see Section 13.3. The peer is expected to send more PATH_CHALLENGE frames as necessary to evoke additional PATH_RESPONSE frames.
エンドポイントは、1つのPATH_CHALLENGEフレームに応答して複数のPATH_RESPONSEフレームを送信してはいけません。13.3項を参照してください。追加のPATH_RESPONSEフレームを呼び出すために、ピアは必要に応じてより多くのPATH_CHALLENGEフレームを送信すると予想されます。
Path validation succeeds when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame. A PATH_RESPONSE frame received on any network path validates the path on which the PATH_CHALLENGE was sent.
PATH検証は、前のPATH_CHALLENGEフレームで送信されたデータを含むPATH_RESPONSEフレームを受信したときに成功します。ネットワークパスで受信されたPATH_RESPONSEフレームは、PATH_CHALLENGEが送信されたパスを検証します。
If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not expanded to at least 1200 bytes and if the response to it validates the peer address, the path is validated but not the path MTU. As a result, the endpoint can now send more than three times the amount of data that has been received. However, the endpoint MUST initiate another path validation with an expanded datagram to verify that the path supports the required MTU.
エンドポイントが少なくとも1200バイトに展開されていないデータグラムにPATH_CHALLENGEフレームを送信し、それに応答がピアアドレスを検証した場合、パスは検証されますが、パスMTUは検証されます。その結果、エンドポイントは受信されたデータ量の3倍を超えると送信できます。ただし、エンドポイントは、パスが必要なMTUをサポートすることを確認するために、拡張データグラムを使用して別のパス検証を開始する必要があります。
Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer.
Acknowledgementは悪意のあるピアによってスピードされる可能性があるため、PATH_CHALLENGEフレームフレームを含むパケットの確認応答の受信は適切な検証ではありません。
Path validation only fails when the endpoint attempting to validate the path abandons its attempt to validate the path.
パス検証は、エンドポイントがパスを検証しようとしているパスポイントを検証しようとしたときにのみ失敗します。
Endpoints SHOULD abandon path validation based on a timer. When setting this timer, implementations are cautioned that the new path could have a longer round-trip time than the original. A value of three times the larger of the current PTO or the PTO for the new path (using kInitialRtt, as defined in [QUIC-RECOVERY]) is RECOMMENDED.
エンドポイントは、タイマーに基づいてパス検証を放棄する必要があります。このタイマーを設定するとき、実装には新しいパスが元の往復時間が長い可能性があることが注意されます。現在のPTOまたは新しいパスのPTOの3倍の値（[QUIC-Recovery]で定義されているように、KinitialRTTを使用）の値をお勧めします。
This timeout allows for multiple PTOs to expire prior to failing path validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE frame does not cause path validation failure.
このタイムアウトでは、パスの検証が失敗する前に複数のPTOが期限切れになるため、単一のPATH_CHALLENGEまたはPATH_RESPONSEフレームの損失はパス検証の失敗を引き起こさないようにします。
Note that the endpoint might receive packets containing other frames on the new path, but a PATH_RESPONSE frame with appropriate data is required for path validation to succeed.
エンドポイントは、新しいパス上の他のフレームを含むパケットを受信することができますが、パス検証に成功するために適切なデータを持つPATH_RESPONSEフレームが必要です。
When an endpoint abandons path validation, it determines that the path is unusable. This does not necessarily imply a failure of the connection -- endpoints can continue sending packets over other paths as appropriate. If no paths are available, an endpoint can wait for a new path to become available or close the connection. An endpoint that has no valid network path to its peer MAY signal this using the NO_VIABLE_PATH connection error, noting that this is only possible if the network path exists but does not support the required MTU (Section 14).
エンドポイントがパスの検証の場合、パスが使用できないと判断します。これは必ずしも接続の失敗を意味するわけではありません。エンドポイントは、必要に応じて他のパスを介してパケットを送信し続けることができます。パスが利用可能な場合、エンドポイントは新しいパスが利用可能になるのを待つことができます。そのピアへの有効なネットワークパスを持たないエンドポイントは、ネットワークパスが存在するが要求されたMTUをサポートしていない場合にのみ可能であることだけであることに注目して、NO_VIABLE_PATH接続エラーを使用してこれをシグナリングすることができる。
A path validation might be abandoned for other reasons besides failure. Primarily, this happens if a connection migration to a new path is initiated while a path validation on the old path is in progress.
失敗以外の他の理由でパス検証は放棄される可能性があります。主に、古いパスのパス検証が進行中に新しいパスへの接続移行が開始された場合に発生します。
The use of a connection ID allows connections to survive changes to endpoint addresses (IP address and port), such as those caused by an endpoint migrating to a new network. This section describes the process by which an endpoint migrates to a new address.
接続IDを使用すると、接続が新しいネットワークに移行するエンドポイントによって引き起こされたものなど、エンドポイントアドレス（IPアドレスとポート）の変更を生き残ることができます。このセクションでは、エンドポイントが新しいアドレスに移行するプロセスについて説明します。
The design of QUIC relies on endpoints retaining a stable address for the duration of the handshake. An endpoint MUST NOT initiate connection migration before the handshake is confirmed, as defined in Section 4.1.2 of [QUIC-TLS].
QUICの設計は、ハンドシェイクの間安定したアドレスを保持するエンドポイントに依存しています。[QUIC-TLS]のセクション4.1.2で定義されているように、エンドポイントはハンドシェイクが確認される前に接続移行を開始してはなりません。
If the peer sent the disable_active_migration transport parameter, an endpoint also MUST NOT send packets (including probing packets; see Section 9.1) from a different local address to the address the peer used during the handshake, unless the endpoint has acted on a preferred_address transport parameter from the peer. If the peer violates this requirement, the endpoint MUST either drop the incoming packets on that path without generating a Stateless Reset or proceed with path validation and allow the peer to migrate. Generating a Stateless Reset or closing the connection would allow third parties in the network to cause connections to close by spoofing or otherwise manipulating observed traffic.
ピアがdisable_active_migrationトランスポートパラメータを送信した場合、エンドポイントが推奨されていない限り、エンドポイントがハンドシェイク中に使用されているピアのアドレスからアドレスに、エンドポイントを送信してはいけません（セクション9.1参照）。ピアから。ピアがこの要件に違反した場合、エンドポイントはステートレスリセットを生成することなく、そのパス上の着信パケットをドロップしたり、パス検証を続行したり、ピアを移行できるようにしてください。ステートレスリセットまたは閉じる接続を閉じると、ネットワーク内の第三者が、観測されたトラフィックのスプーフィングや操作によって接続を閉じることができます。
Not all changes of peer address are intentional, or active, migrations. The peer could experience NAT rebinding: a change of address due to a middlebox, usually a NAT, allocating a new outgoing port or even a new outgoing IP address for a flow. An endpoint MUST perform path validation (Section 8.2) if it detects any change to a peer's address, unless it has previously validated that address.
ピアアドレスのすべての変更が意図的な、またはアクティブな移行ではありません。ピアはNATの再バインドを経験できます。ミドルボックス、通常はNAT、またはフローの新しい発信IPアドレスを割り当てるためのアドレスの変更。そのアドレスを以前に検証していない限り、エンドポイントはPATHのアドレスへの変更を検出した場合は、PATH検証を実行する必要があります（セクション8.2）。
When an endpoint has no validated path on which to send packets, it MAY discard connection state. An endpoint capable of connection migration MAY wait for a new path to become available before discarding connection state.
エンドポイントには、パケットを送信するための検証されたパスがない場合、接続状態を破棄する可能性があります。接続移行が可能なエンドポイントは、接続状態を廃棄する前に新しいパスが利用可能になるのを待つことがあります。
This document limits migration of connections to new client addresses, except as described in Section 9.6. Clients are responsible for initiating all migrations. Servers do not send non-probing packets (see Section 9.1) toward a client address until they see a non-probing packet from that address. If a client receives packets from an unknown server address, the client MUST discard these packets.
このドキュメントは、セクション9.6で説明されている場合を除き、新しいクライアントアドレスへの接続の移行を制限しています。クライアントはすべての移行を開始する責任があります。サーバーは、そのアドレスから以外のプローブパケットが表示されるまで、プロービングパケット（セクション9.1参照）をクライアントアドレスに向かって送信しません。クライアントが未知のサーバーアドレスからパケットを受信した場合、クライアントはこれらのパケットを破棄する必要があります。
An endpoint MAY probe for peer reachability from a new local address using path validation (Section 8.2) prior to migrating the connection to the new local address. Failure of path validation simply means that the new path is not usable for this connection. Failure to validate a path does not cause the connection to end unless there are no valid alternative paths available.
エンドポイントは、新しいローカルアドレスへの接続を移行する前に、パス検証を使用して新しいローカルアドレスからピア到達可能性をプローブすることができます（セクション8.2）。パス検証の失敗は、新しいパスがこの接続に使用できないことを意味します。パスの検証に失敗しても、有効な代替パスがない限り接続は終了しません。
PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames are "probing frames", and all other frames are "non-probing frames". A packet containing only probing frames is a "probing packet", and a packet containing any other frame is a "non-probing packet".
PATH_CHALLENGE、PATH_RESPONSE、NEW_CONNECTION_ID、およびパディングフレームは「プロービングフレーム」であり、他のすべてのフレームは「非プロービングフレーム」です。プローブフレームのみを含むパケットは「プロービングパケット」であり、他のフレームを含むパケットは「非プロービングパケット」である。
An endpoint can migrate a connection to a new local address by sending packets containing non-probing frames from that address.
エンドポイントは、そのアドレスから非プロービングフレームを含むパケットを送信することによって、新しいローカルアドレスへの接続を移行できます。
Each endpoint validates its peer's address during connection establishment. Therefore, a migrating endpoint can send to its peer knowing that the peer is willing to receive at the peer's current address. Thus, an endpoint can migrate to a new local address without first validating the peer's address.
各エンドポイントは、接続確立中にピアのアドレスを検証します。したがって、移行エンドポイントは、ピアがピアの現在のアドレスで受信しても構わないと思っていることを知ってそのピアに送信できます。したがって、エンドポイントは、最初にピアのアドレスを検証せずに新しいローカルアドレスに移行できます。
To establish reachability on the new path, an endpoint initiates path validation (Section 8.2) on the new path. An endpoint MAY defer path validation until after a peer sends the next non-probing frame to its new address.
新しいパスで到達可能性を確立するために、エンドポイントは新しいパス上のパス検証（セクション8.2）を開始します。エンドポイントは、ピアが次の非プロービングフレームを新しいアドレスに送信するまでの経路検証を延期することがあります。
When migrating, the new path might not support the endpoint's current sending rate. Therefore, the endpoint resets its congestion controller and RTT estimate, as described in Section 9.4.
移行すると、新しいパスはエンドポイントの現在の送信レートをサポートしない可能性があります。したがって、エンドポイントは、9.4節で説明されているように、その輻輳コントローラとRTT推定値をリセットします。
The new path might not have the same ECN capability. Therefore, the endpoint validates ECN capability as described in Section 13.4.
新しいパスには同じECN機能がない可能性があります。したがって、エンドポイントはセクション13.4で説明されているようにECN機能を検証します。
Receiving a packet from a new peer address containing a non-probing frame indicates that the peer has migrated to that address.
非プロービングフレームを含む新しいピアアドレスからパケットを受信すると、ピアがそのアドレスに移行されたことを示します。
If the recipient permits the migration, it MUST send subsequent packets to the new peer address and MUST initiate path validation (Section 8.2) to verify the peer's ownership of the address if validation is not already underway. If the recipient has no unused connection IDs from the peer, it will not be able to send anything on the new path until the peer provides one; see Section 9.5.
受信者が移行を許可する場合は、後続のパケットを新しいピアアドレスに送信し、検証がまだ進行していない場合は、アドレスのピアの所有権を確認するには、パス検証を開始する必要があります（セクション8.2）。受信者には、ピアから未使用の接続IDがない場合は、ピアが表示されるまで新しいパスに何も送信できません。9.5節を参照してください。
An endpoint only changes the address to which it sends packets in response to the highest-numbered non-probing packet. This ensures that an endpoint does not send packets to an old peer address in the case that it receives reordered packets.
エンドポイントは、最上位の非プロービングパケットに応答してパケットを送信するアドレスのみを変更します。これにより、並べ替えパケットを受信した場合には、エンドポイントが古いピアアドレスにパケットを送信しないことが保証されます。
An endpoint MAY send data to an unvalidated peer address, but it MUST protect against potential attacks as described in Sections 9.3.1 and 9.3.2. An endpoint MAY skip validation of a peer address if that address has been seen recently. In particular, if an endpoint returns to a previously validated path after detecting some form of spurious migration, skipping address validation and restoring loss detection and congestion state can reduce the performance impact of the attack.
エンドポイントは、未検証のピアアドレスにデータを送信することができますが、セクション9.3.1および9.3.2の説明に従って潜在的な攻撃から保護する必要があります。そのアドレスが最近見られた場合、エンドポイントはピアアドレスの検証をスキップすることがあります。特に、エンドポイントが何らかの形式のスプリアスマイグレーションを検出した後に以前に検証されたパスに戻った場合、アドレス検証と損失検出および輻輳状態を復元し、攻撃の性能影響を減らすことができます。
After changing the address to which it sends non-probing packets, an endpoint can abandon any path validation for other addresses.
非プロービングパケットを送信するアドレスを変更した後、エンドポイントは他のアドレスのパス検証をすべて放棄できます。
Receiving a packet from a new peer address could be the result of a NAT rebinding at the peer.
新しいピアアドレスからパケットを受信することは、ピアでのNATリファイルの結果になる可能性があります。
After verifying a new client address, the server SHOULD send new address validation tokens (Section 8) to the client.
新しいクライアントアドレスを確認した後、サーバーは新しいアドレス検証トークン（セクション8）をクライアントに送信する必要があります。
It is possible that a peer is spoofing its source address to cause an endpoint to send excessive amounts of data to an unwilling host. If the endpoint sends significantly more data than the spoofing peer, connection migration might be used to amplify the volume of data that an attacker can generate toward a victim.
ピアがその送信元アドレスを偽装して、エンドポイントが不要なホストに過剰な量のデータを送信させる可能性があります。エンドポイントがスプーフィングピアよりもかなり多くのデータを送信すると、接続移行を使用して攻撃者が被害者に向かって生成できるデータの量を増幅することがあります。
As described in Section 9.3, an endpoint is required to validate a peer's new address to confirm the peer's possession of the new address. Until a peer's address is deemed valid, an endpoint limits the amount of data it sends to that address; see Section 8. In the absence of this limit, an endpoint risks being used for a denial-of-service attack against an unsuspecting victim.
セクション9.3で説明されているように、ピアの新しいアドレスを検証するためにエンドポイントが必要です。ピアのアドレスが有効であると見なされるまで、エンドポイントはそれがそのアドレスに送信するデータ量を制限します。セクション8.この制限がない場合は、疑わしい被害者に対するサービス拒否攻撃に使用されているエンドポイントリスクが使用されています。
If an endpoint skips validation of a peer address as described above, it does not need to limit its sending rate.
エンドポイントが上記のようにピアアドレスの検証をスキップすると、送信レートを制限する必要はありません。
An on-path attacker could cause a spurious connection migration by copying and forwarding a packet with a spoofed address such that it arrives before the original packet. The packet with the spoofed address will be seen to come from a migrating connection, and the original packet will be seen as a duplicate and dropped. After a spurious migration, validation of the source address will fail because the entity at the source address does not have the necessary cryptographic keys to read or respond to the PATH_CHALLENGE frame that is sent to it even if it wanted to.
オンパス攻撃者は、オリジナルのパケットの前に到着するように、偽装されたアドレスでパケットをコピーして転送することによってスプリアス接続移行を引き起こす可能性があります。偽造されたアドレスを持つパケットは移行接続から来るように見られ、元のパケットは重複して削除されます。スプリアスマイグレーションの後、送信元アドレスのエンティティには、それが望んでいても送信されたPATH_CHALLENGEフレームに必要な暗号化キーを読み取るか応答するために必要な暗号化キーがないため、送信元アドレスの検証は失敗します。
To protect the connection from failing due to such a spurious migration, an endpoint MUST revert to using the last validated peer address when validation of a new peer address fails. Additionally, receipt of packets with higher packet numbers from the legitimate peer address will trigger another connection migration. This will cause the validation of the address of the spurious migration to be abandoned, thus containing migrations initiated by the attacker injecting a single packet.
そのようなスプリアスマイグレーションのために接続を障害から保護するために、新しいピアアドレスの検証が失敗したときに最後に検証されたピアアドレスを使用するようにエンドポイントを元に戻す必要があります。さらに、正当なピアアドレスからのパケット番号が高いパケットの受信は、別の接続移行を引き起こします。これにより、スプリアスマイグレーションのアドレスの検証が放棄されるため、攻撃者が単一のパケットを注入する移行を含みます。
If an endpoint has no state about the last validated peer address, it MUST close the connection silently by discarding all connection state. This results in new packets on the connection being handled generically. For instance, an endpoint MAY send a Stateless Reset in response to any further incoming packets.
エンドポイントに最後に検証されたピアアドレスについての状態がない場合は、すべての接続状態を破棄することでサイレントをサイレントに閉じる必要があります。これにより、接続上の新しいパケットが総称的に処理されます。たとえば、エンドポイントは、さらなる受信パケットに応答してステートレスリセットを送信することがあります。
An off-path attacker that can observe packets might forward copies of genuine packets to endpoints. If the copied packet arrives before the genuine packet, this will appear as a NAT rebinding. Any genuine packet will be discarded as a duplicate. If the attacker is able to continue forwarding packets, it might be able to cause migration to a path via the attacker. This places the attacker on-path, giving it the ability to observe or drop all subsequent packets.
パケットを観察できるオフパス攻撃者は、本物のパケットのコピーをエンドポイントに転送する可能性があります。コピーされたパケットが純正パケットの前に到着すると、これはNATリファイルとして表示されます。純正パケットは重複として破棄されます。攻撃者がパケットを転送することができる場合、それは攻撃者を介してパスへの移行を引き起こす可能性があります。これにより、攻撃者のパスが経路に配置され、後続のすべてのパケットを監視または削除する能力があります。
This style of attack relies on the attacker using a path that has approximately the same characteristics as the direct path between endpoints. The attack is more reliable if relatively few packets are sent or if packet loss coincides with the attempted attack.
このスタイルの攻撃は、エンドポイント間の直接パスとほぼ同じ特性を持つパスを使用して攻撃者に依存しています。比較的少数のパケットが送信された場合、またはパケット損失が試みられた攻撃と一致する場合は、攻撃はより信頼性があります。
A non-probing packet received on the original path that increases the maximum received packet number will cause the endpoint to move back to that path. Eliciting packets on this path increases the likelihood that the attack is unsuccessful. Therefore, mitigation of this attack relies on triggering the exchange of packets.
最大受信したパケット番号を増加させる元のパスで受信された非プロービングパケットは、エンドポイントをそのパスに戻します。このパス上のパケットを誘発すると、攻撃が失敗した可能性が高まります。したがって、この攻撃の緩和は、パケットの交換を引き起こすことに依存しています。
In response to an apparent migration, endpoints MUST validate the previously active path using a PATH_CHALLENGE frame. This induces the sending of new packets on that path. If the path is no longer viable, the validation attempt will time out and fail; if the path is viable but no longer desired, the validation will succeed but only results in probing packets being sent on the path.
見かけの移行に応答して、エンドポイントはPATH_CHALLENGEフレンジを使用して以前にアクティブなパスを検証する必要があります。これにより、そのパス上の新しいパケットの送信が誘導されます。パスが実行可能でない場合、検証の試行はタイムアウトして失敗します。パスが実行可能であるが望まれなくなった場合、検証は成功しますが、パス上で送信されているパケットのプロービングのみが得られます。
An endpoint that receives a PATH_CHALLENGE on an active path SHOULD send a non-probing packet in response. If the non-probing packet arrives before any copy made by an attacker, this results in the connection being migrated back to the original path. Any subsequent migration to another path restarts this entire process.
アクティブパス上のPATH_CHALLENGEを受信するエンドポイントは、非プロービングパケットを応答して送信する必要があります。非プロービングパケットが攻撃者によって行われたコピーの前に到着すると、これにより接続が元のパスに移行されます。その後の別のパスへの移行は、このプロセス全体を再起動します。
This defense is imperfect, but this is not considered a serious problem. If the path via the attack is reliably faster than the original path despite multiple attempts to use that original path, it is not possible to distinguish between an attack and an improvement in routing.
この防衛は不完全ですが、これは深刻な問題とは見なされません。そのオリジナルのパスを使用しようとした複数のパスを使用しても、攻撃によるパスが元のパスよりも確実に速くなると、攻撃とルーティングの改善を区別することはできません。
An endpoint could also use heuristics to improve detection of this style of attack. For instance, NAT rebinding is improbable if packets were recently received on the old path; similarly, rebinding is rare on IPv6 paths. Endpoints can also look for duplicated packets. Conversely, a change in connection ID is more likely to indicate an intentional migration rather than an attack.
エンドポイントはヒューリスティックを使用してこのスタイルの攻撃の検出を改善することができます。たとえば、Packetsが古いパスで最近受信された場合は、NATの再バインドが起動できません。同様に、リファイルはIPv6パスではまれです。エンドポイントは複製されたパケットを探すこともできます。逆に、接続IDの変更は、攻撃ではなく意図的な移行を示す可能性が高いです。
The capacity available on the new path might not be the same as the old path. Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path.
新しいパスで利用可能な容量は古いパスと同じではない可能性があります。古いパスで送信されたパケットは、新しいパスの輻輳制御またはRTT推定に貢献してはなりません。
On confirming a peer's ownership of its new address, an endpoint MUST immediately reset the congestion controller and round-trip time estimator for the new path to initial values (see Appendices A.3 and B.3 of [QUIC-RECOVERY]) unless the only change in the peer's address is its port number. Because port-only changes are commonly the result of NAT rebinding or other middlebox activity, the endpoint MAY instead retain its congestion control state and round-trip estimate in those cases instead of reverting to initial values. In cases where congestion control state retained from an old path is used on a new path with substantially different characteristics, a sender could transmit too aggressively until the congestion controller and the RTT estimator have adapted. Generally, implementations are advised to be cautious when using previous values on a new path.
新しいアドレスのピアの所有権を確認すると、エンドポイントが新しいパスを最初の値への新しいパスに輻輳コントローラと往復時間推定量を直ちにリセットする必要があります（[QUIC-Recoveryの付録A.3、B.3を参照）。ピアのアドレスの変更のみはそのポート番号です。ポートのみの変更は一般的にNATの再バインドまたは他のミドルボックスのアクティビティの結果であるため、エンドポイントは、初期値に戻るのではなく、その輻輳制御状態と往復の推定値を保持することができます。古いパスから保持されている輻輳制御状態が実質的に異なる特性を有する新しい経路で使用される場合、送信者は輻輳コントローラとRTT推定器が適応するまで積極的に過ぎることができる。一般的に、新しいパス上で前の値を使用するときに実装は慎重になると推奨されます。
There could be apparent reordering at the receiver when an endpoint sends data and probes from/to multiple addresses during the migration period, since the two resulting paths could have different round-trip times. A receiver of packets on multiple paths will still send ACK frames covering all received packets.
エンドポイントがマイグレーション期間中にデータおよびプローブを送信するときには、受信機で明らかな並べ替えがあり、移行期間中に複数のアドレスからの複数のアドレスを送信してもよい。複数のパス上のパケットの受信機は、すべての受信パケットをカバーするACKフレームを送信します。
While multiple paths might be used during connection migration, a single congestion control context and a single loss recovery context (as described in [QUIC-RECOVERY]) could be adequate. For instance, an endpoint might delay switching to a new congestion control context until it is confirmed that an old path is no longer needed (such as the case described in Section 9.3.3).
接続移行中に複数のパスを使用することができますが、単一の輻輳制御コンテキストと単一の損失回復コンテキスト（[QUIC-RECOVERY]で説明されているように）が適切であり得る。たとえば、エンドポイントは、古いパスが不要になったことが確認されるまで（セクション9.3.3で説明されている場合など）、新しい輻輳制御コンテキストへの切り替えを遅らせる可能性があります。
A sender can make exceptions for probe packets so that their loss detection is independent and does not unduly cause the congestion controller to reduce its sending rate. An endpoint might set a separate timer when a PATH_CHALLENGE is sent, which is canceled if the corresponding PATH_RESPONSE is received. If the timer fires before the PATH_RESPONSE is received, the endpoint might send a new PATH_CHALLENGE and restart the timer for a longer period of time. This timer SHOULD be set as described in Section 6.2.1 of [QUIC-RECOVERY] and MUST NOT be more aggressive.
送信者はプローブパケットの例外を作成することができ、それらの損失検出は独立しており、輻輳コントローラがその送信速度を低下させることを過度に引き起こさない。PATH_CHALLENGEが送信されたときにエンドポイントが別々のタイマーを設定します。これは、対応するPATH_RESPONSEが受信された場合にキャンセルされます。PATH_RESPONSEが受信される前にタイマーが発生すると、エンドポイントは新しいPATH_CHALLENGEを送信し、より長い期間タイマーを再起動することがあります。このタイマーは、[QUIC-Recovery]のセクション6.2.1に記載されているように設定する必要があります。また、より積極的にすることはできません。
Using a stable connection ID on multiple network paths would allow a passive observer to correlate activity between those paths. An endpoint that moves between networks might not wish to have their activity correlated by any entity other than their peer, so different connection IDs are used when sending from different local addresses, as discussed in Section 5.1. For this to be effective, endpoints need to ensure that connection IDs they provide cannot be linked by any other entity.
複数のネットワークパスで安定した接続IDを使用すると、パッシブオブザーバーがそれらのパス間のアクティビティを相関させることができます。ネットワーク間で移動するエンドポイントは、それらのピア以外のすべてのエンティティによってそれらのアクティビティを相関させたくないかもしれないので、セクション5.1で説明されているように、さまざまなローカルアドレスから送信するときに異なる接続IDが使用されます。これが効果的であるため、エンドポイントは、それらが提供する接続IDを他のエンティティによってリンクできないことを確認する必要があります。
At any time, endpoints MAY change the Destination Connection ID they transmit with to a value that has not been used on another path.
いつでも、エンドポイントは、送信先の接続IDを他のパスで使用されていない値に変更することがあります。
An endpoint MUST NOT reuse a connection ID when sending from more than one local address -- for example, when initiating connection migration as described in Section 9.2 or when probing a new network path as described in Section 9.1.
セクション9.2で説明されているように、2つ以上のローカルアドレスから送信するとき、またはセクション9.1で説明されているように新しいネットワークパスを調べるときに、エンドポイントが複数のローカルアドレスから送信してはいけません。
Similarly, an endpoint MUST NOT reuse a connection ID when sending to more than one destination address. Due to network changes outside the control of its peer, an endpoint might receive packets from a new source address with the same Destination Connection ID field value, in which case it MAY continue to use the current connection ID with the new remote address while still sending from the same local address.
同様に、エンドポイントは、複数の宛先アドレスに送信するときに接続IDを再利用してはなりません。ネットワークの変更がそのピアの制御の外部では、エンドポイントは同じ宛先接続IDフィールド値を持つ新しい送信元アドレスからパケットを受信することができます。その場合は、送信中に現在の接続IDを使用して現在の接続IDを使用し続けることができます。同じローカルアドレスから。
These requirements regarding connection ID reuse apply only to the sending of packets, as unintentional changes in path without a change in connection ID are possible. For example, after a period of network inactivity, NAT rebinding might cause packets to be sent on a new path when the client resumes sending. An endpoint responds to such an event as described in Section 9.3.
接続IDの再利用に関するこれらの要件は、接続IDの変更なしには意図しないパスの変更が可能であるため、パケットの送信にのみ適用されます。たとえば、ネットワークの非アクティブの期間の後、クライアントが送信を再開すると、NATの再バインドは新しいパスでパケットを送信させることがあります。エンドポイントは、セクション9.3に記載されているようなイベントに応答します。
Using different connection IDs for packets sent in both directions on each new network path eliminates the use of the connection ID for linking packets from the same connection across different network paths. Header protection ensures that packet numbers cannot be used to correlate activity. This does not prevent other properties of packets, such as timing and size, from being used to correlate activity.
新しいネットワーク経路ごとに両方向に送信されたパケットの異なる接続IDを使用すると、異なるネットワークパスにわたって同じ接続からパケットをリンクするための接続IDの使用が排除されます。ヘッダー保護により、パケット番号を使用してアクティビティを相関させることができないようにします。これは、タイミングやサイズなどのパケットの他のプロパティを妨げません。
An endpoint SHOULD NOT initiate migration with a peer that has requested a zero-length connection ID, because traffic over the new path might be trivially linkable to traffic over the old one. If the server is able to associate packets with a zero-length connection ID to the right connection, it means that the server is using other information to demultiplex packets. For example, a server might provide a unique address to every client -- for instance, using HTTP alternative services [ALTSVC]. Information that might allow correct routing of packets across multiple network paths will also allow activity on those paths to be linked by entities other than the peer.
エンドポイントは、新しいパスの上のトラフィックが古いものを介してトラフィックに著しくリンク可能である可能性があるため、長さゼロの接続IDを要求したピアでの移行を開始しないでください。サーバーがゼロ長の接続IDを右の接続に関連付けてパケットを関連付けることができる場合は、サーバーが他の情報をDemultiplexパケットに使用していることを意味します。たとえば、サーバーは、たとえばHTTP代替サービス[ALTSVC]を使用して、すべてのクライアントに固有のアドレスを提供することがあります。複数のネットワークパスにわたるパケットの正しいルーティングを許可する可能性のある情報によっても、それらのパス上のアクティビティがピア以外のエンティティによってリンクされることができます。
A client might wish to reduce linkability by switching to a new connection ID, source UDP port, or IP address (see [RFC8981]) when sending traffic after a period of inactivity. Changing the address from which it sends packets at the same time might cause the server to detect a connection migration. This ensures that the mechanisms that support migration are exercised even for clients that do not experience NAT rebindings or genuine migrations. Changing address can cause a peer to reset its congestion control state (see Section 9.4), so addresses SHOULD only be changed infrequently.
非活動の後にトラフィックを送信するときに、新しい接続ID、ソースUDPポート、またはIPアドレスに切り替えることによってリンク可能性を低下させることができます（[RFC8981]参照）。同時にパケットを送信するアドレスを変更すると、サーバーが接続移行を検出する可能性があります。これにより、NATの再バインドや本物の移行を経験しないクライアントでも、移行をサポートするメカニズムが実行されます。アドレスを変更すると、ピアがその輻輳制御状態をリセットさせる可能性があるため、アドレスはまれに変更されるだけです。
An endpoint that exhausts available connection IDs cannot probe new paths or initiate migration, nor can it respond to probes or attempts by its peer to migrate. To ensure that migration is possible and packets sent on different paths cannot be correlated, endpoints SHOULD provide new connection IDs before peers migrate; see Section 5.1.1. If a peer might have exhausted available connection IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in all packets sent on a new network path.
利用可能な接続IDを排気するエンドポイントは、新しいパスを調べることも、移行を開始することも、プローブまたはそのピアによる移行に対応することもできません。マイグレーションが可能であり、異なるパスで送信されたパケットを相関させることができないようにするには、エンドポイントはピアが移行する前に新しい接続IDを提供する必要があります。セクション5.1.1を参照してください。ピアが利用可能な接続IDを使い果たした場合、移行エンドポイントは、新しいネットワークパスで送信されたすべてのパケット内のNEW_CONNECTION_IDフレームを含めることができます。
QUIC allows servers to accept connections on one IP address and attempt to transfer these connections to a more preferred address shortly after the handshake. This is particularly useful when clients initially connect to an address shared by multiple servers but would prefer to use a unicast address to ensure connection stability. This section describes the protocol for migrating a connection to a preferred server address.
QUICは、サーバーが1つのIPアドレスで接続を受け入れ、ハンドシェイクの直後にこれらの接続をより好ましいアドレスに転送しようとします。これは、クライアントが最初に複数のサーバーによって共有されているアドレスに最初に接続するときに特に役立ちますが、接続安定性を確保するためにユニキャストアドレスを使用することをお勧めします。このセクションでは、接続を優先サーバーアドレスに移行するためのプロトコルについて説明します。
Migrating a connection to a new server address mid-connection is not supported by the version of QUIC specified in this document. If a client receives packets from a new server address when the client has not initiated a migration to that address, the client SHOULD discard these packets.
新しいサーバーアドレスへの接続をマイグレーションするには、このドキュメントで指定されているQUICのバージョンではサポートされていません。クライアントが新しいサーバーアドレスからパケットを受信した場合、クライアントがそのアドレスへの移行を開始していない場合、クライアントはこれらのパケットを破棄する必要があります。
A server conveys a preferred address by including the preferred_address transport parameter in the TLS handshake.
サーバーは、TLSハンドシェイクにpreferred_addressトランスポートパラメーターを含めることにより、優先アドレスを伝達します。
Servers MAY communicate a preferred address of each address family (IPv4 and IPv6) to allow clients to pick the one most suited to their network attachment.
サーバーは、各アドレスファミリ（IPv4とIPv6）の優先アドレスを通信して、クライアントがネットワーク添付ファイルに最も適したものを選択できるようにします。
Once the handshake is confirmed, the client SHOULD select one of the two addresses provided by the server and initiate path validation (see Section 8.2). A client constructs packets using any previously unused active connection ID, taken from either the preferred_address transport parameter or a NEW_CONNECTION_ID frame.
ハンドシェイクが確認されると、クライアントはサーバーによって提供された2つのアドレスのいずれかを選択してパス検証を開始する必要があります（セクション8.2を参照）。クライアントは、preferred_address Transportパラメータまたは NEW_CONNECTION_ID フレームのいずれかから撮影された、以前に未使用のアクティブ接続IDを使用してパケットを構築します。
As soon as path validation succeeds, the client SHOULD begin sending all future packets to the new server address using the new connection ID and discontinue use of the old server address. If path validation fails, the client MUST continue sending all future packets to the server's original IP address.
PATH検証が成功するとすぐに、クライアントは新しい接続IDを使用して新しいサーバーアドレスにすべての将来のパケットを送信し、古いサーバーアドレスの使用を中止します。パス検証が失敗した場合、クライアントは将来のすべてのパケットをサーバーの元のIPアドレスに送信し続ける必要があります。
A client that migrates to a preferred address MUST validate the address it chooses before migrating; see Section 21.5.3.
優先アドレスに移行するクライアントは、移行する前に選択されたアドレスを検証する必要があります。21.5.3項を参照してください。
A server might receive a packet addressed to its preferred IP address at any time after it accepts a connection. If this packet contains a PATH_CHALLENGE frame, the server sends a packet containing a PATH_RESPONSE frame as per Section 8.2. The server MUST send non-probing packets from its original address until it receives a non-probing packet from the client at its preferred address and until the server has validated the new path.
サーバーは、接続を受け入れた後はいつでもその優先IPアドレス宛てのパケットを受信することがあります。このパケットがPATH_CHALLENGEフレームを含む場合、サーバはセクション8.2に従ってPATH_RESPONSEフレームを含むパケットを送信する。サーバーは、クライアントからの非プロービングパケットをその優先アドレスで受信し、サーバーが新しいパスを検証するまで、以外のアドレスから非プロービングパケットを送信する必要があります。
The server MUST probe on the path toward the client from its preferred address. This helps to guard against spurious migration initiated by an attacker.
サーバーは、その優先アドレスからクライアントに向かってパスをプローブする必要があります。これは、攻撃者によって開始された偽の移行を防ぐのに役立ちます。
Once the server has completed its path validation and has received a non-probing packet with a new largest packet number on its preferred address, the server begins sending non-probing packets to the client exclusively from its preferred IP address. The server SHOULD drop newer packets for this connection that are received on the old IP address. The server MAY continue to process delayed packets that are received on the old IP address.
サーバーがそのパス検証を完了し、その優先アドレスで新しい最大のパケット番号を持つ非プロービングパケットを受信したら、サーバーはその優先IPアドレスから排他的に非プロービングパケットの送信を開始します。サーバーは、古いIPアドレスで受信されたこの接続の新しいパケットをドロップする必要があります。サーバーは、古いIPアドレスで受信された遅延パケットを処理し続けることがあります。
The addresses that a server provides in the preferred_address transport parameter are only valid for the connection in which they are provided. A client MUST NOT use these for other connections, including connections that are resumed from the current connection.
サーバーがprefersy_addressトランスポートパラメータに提供するアドレスは、提供されている接続にのみ有効です。クライアントは、現在の接続から再開される接続を含む他の接続にこれらを使用してはいけません。
A client might need to perform a connection migration before it has migrated to the server's preferred address. In this case, the client SHOULD perform path validation to both the original and preferred server address from the client's new address concurrently.
クライアントは、サーバーの優先アドレスに移行する前に接続移行を実行する必要があるかもしれません。この場合、クライアントはクライアントの新しいアドレスから同時に元のサーバーアドレスと優先サーバーアドレスの両方にパス検証を実行する必要があります。
If path validation of the server's preferred address succeeds, the client MUST abandon validation of the original address and migrate to using the server's preferred address. If path validation of the server's preferred address fails but validation of the server's original address succeeds, the client MAY migrate to its new address and continue sending to the server's original address.
サーバーの優先アドレスのパス検証が成功した場合、クライアントは元のアドレスの検証を放棄し、サーバーの優先アドレスの使用に移行する必要があります。サーバーの優先アドレスのパスの検証が失敗したが、サーバの元のアドレスの検証が成功した場合、クライアントはその新しいアドレスに移行し、サーバーの元のアドレスに送信を続けます。
If packets received at the server's preferred address have a different source address than observed from the client during the handshake, the server MUST protect against potential attacks as described in Sections 9.3.1 and 9.3.2. In addition to intentional simultaneous migration, this might also occur because the client's access network used a different NAT binding for the server's preferred address.
サーバーの優先アドレスで受信されたパケットがハンドシェイク中にクライアントから観測された元の送信元アドレスを持つ場合、サーバーはセクション9.3.1および9.3.2の説明に従って潜在的な攻撃から保護しなければなりません。意図的な同時移行に加えて、これはクライアントのアクセスネットワークがサーバーの優先アドレスに対して異なるNATバインディングを使用したためにも発生する可能性があります。
Servers SHOULD initiate path validation to the client's new address upon receiving a probe packet from a different address; see Section 8.
サーバーは、異なるアドレスからプローブパケットを受信したときに、クライアントの新しいアドレスへのパス検証を開始する必要があります。セクション8を参照してください。
A client that migrates to a new address SHOULD use a preferred address from the same address family for the server.
新しいアドレスに移行するクライアントは、サーバーの同じアドレスファミリから優先アドレスを使用する必要があります。
The connection ID provided in the preferred_address transport parameter is not specific to the addresses that are provided. This connection ID is provided to ensure that the client has a connection ID available for migration, but the client MAY use this connection ID on any path.
repordy_addressトランスポートパラメータに提供されている接続IDは、提供されているアドレスに固有のものではありません。この接続IDは、クライアントがマイグレーションに使用可能な接続IDを確実にするために提供されていますが、クライアントは任意のパスでこの接続IDを使用できます。
Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label in compliance with [RFC6437], unless the local API does not allow setting IPv6 flow labels.
IPv6を使用してデータを送信するエンドポイントローカルAPIがIPv6フローラベルを設定しない限り、[RFC6437]に準拠してIPv6フローラベルを適用する必要があります。
The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see Section 9.5.
安定したフローラベルが複数の経路でのアクティビティを相関させることを可能にするので、フローラベルの生成は、以前に使用されたフローラベルとのリンク性の可能性を最小限に抑えるように設計されなければならない。9.5節を参照してください。
[RFC6437] suggests deriving values using a pseudorandom function to generate flow labels. Including the Destination Connection ID field in addition to source and destination addresses when generating flow labels ensures that changes are synchronized with changes in other observable identifiers. A cryptographic hash function that combines these inputs with a local secret is one way this might be implemented.
[RFC6437]フローラベルを生成するために疑似ランダム関数を使用して値を導出することを提案します。フローラベルを生成するときに、送信元アドレスおよび宛先アドレスに加えて宛先接続IDフィールドを含めることにより、他の観察可能な識別子の変更と同期されることが保証される。これらの入力をローカルシークレットと組み合わせた暗号化ハッシュ関数は、これが実装される可能性がある1つの方法です。
An established QUIC connection can be terminated in one of three ways:
確立されたQUIC接続は、3つの方法のいずれかで終了できます。
* idle timeout (Section 10.1)
* アイドルタイムアウト（セクション10.1）
* immediate close (Section 10.2)
* 即時の閉鎖（セクション10.2）
* stateless reset (Section 10.3)
* ステートレスリセット（セクション10.3）
An endpoint MAY discard connection state if it does not have a validated path on which it can send packets; see Section 8.2.
エンドポイントは、パケットを送信できる検証されたパスがない場合、接続状態を破棄することがあります。セクション8.2を参照してください。
If a max_idle_timeout is specified by either endpoint in its transport parameters (Section 18.2), the connection is silently closed and its state is discarded when it remains idle for longer than the minimum of the max_idle_timeout value advertised by both endpoints.
MAX_IDLE_TIMEOUTがそのトランスポートパラメータのいずれかのエンドポイントで指定されている場合（セクション18.2）、接続は静かに閉じられ、その状態は両方のエンドポイントによってアドバタイズされたMAX_IDLE_TIMEOUT値の最小値より長いときにその状態を破棄します。
Each endpoint advertises a max_idle_timeout, but the effective value at an endpoint is computed as the minimum of the two advertised values (or the sole advertised value, if only one endpoint advertises a non-zero value). By announcing a max_idle_timeout, an endpoint commits to initiating an immediate close (Section 10.2) if it abandons the connection prior to the effective value.
各エンドポイントはMAX_IDLE_TIMEOUTをアドバタイズしますが、エンドポイントの有効値は2つのアドバタイズされた値の最小値（または1つのエンドポイントだけがゼロ以外の値をアドバタイズしている場合は唯一のアドバタイズ値）として計算されます。MAX_IDLE_TIMEOUTを発表することで、エンドポイントが有効値の前に接続に停止している場合は、即時の閉鎖（セクション10.2）の開始をコミットします。
An endpoint restarts its idle timer when a packet from its peer is received and processed successfully. An endpoint also restarts its idle timer when sending an ack-eliciting packet if no other ack-eliciting packets have been sent since last receiving and processing a packet. Restarting this timer when sending a packet ensures that connections are not closed after new activity is initiated.
ピアからのパケットを受信して処理したときにエンドポイントはアイドルタイマーを再起動します。エンドポイントは、最後の受信およびパケットを処理して以降、他のACKエリチチャットパケットが送信されていない場合にACK誘発パケットを送信するときに、アイドルタイマーを再起動します。パケットを送信するときにこのタイマーを再起動すると、新しいアクティビティが開始された後に接続が閉じられないことが保証されます。
To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the current Probe Timeout (PTO). This allows for multiple PTOs to expire, and therefore multiple probes to be sent and lost, prior to idle timeout.
アイドルタイムアウト期間が過度に小さい回避するために、エンドポイントはアイドルタイムアウト期間を現在のプローブタイムアウト（PTO）の少なくとも3倍になる必要があります。これにより、アイドルタイムアウトの前に複数のPTOが期限切れ、したがって複数のプローブを送信および失われることができます。
An endpoint that sends packets close to the effective timeout risks having them be discarded at the peer, since the idle timeout period might have expired at the peer before these packets arrive.
アイドルタイムアウト期間は、これらのパケットが到着する前にアイドルタイムアウト期間がピアで期限切れになっている可能性があるため、それらをピアで破棄するエンドポイントを廃棄するエンドポイント。
An endpoint can send a PING or another ack-eliciting frame to test the connection for liveness if the peer could time out soon, such as within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially useful if any available application data cannot be safely retried. Note that the application determines what data is safe to retry.
エンドポイントは、PTO内などのように、ピアがすぐにタイムアウトすることができれば、Lightsの接続をテストするためにpingまたは別のACKエリチコートフレームを送信できます。[QUIC-RECOVERY]の6.2項を参照してください。これは、利用可能なアプリケーションデータを安全に再試行できない場合に特に便利です。アプリケーションは、再試行しても安全なデータを決定することに注意してください。
An endpoint might need to send ack-eliciting packets to avoid an idle timeout if it is expecting response data but does not have or is unable to send application data.
エンドポイントは、応答データを期待しているがアプリケーションデータを持たないかまたは送信できない場合は、アイドルタイムアウトを回避するようにACKエリチコートパケットを送信する必要があるかもしれません。
An implementation of QUIC might provide applications with an option to defer an idle timeout. This facility could be used when the application wishes to avoid losing state that has been associated with an open connection but does not expect to exchange application data for some time. With this option, an endpoint could send a PING frame (Section 19.2) periodically, which will cause the peer to restart its idle timeout period. Sending a packet containing a PING frame restarts the idle timeout for this endpoint also if this is the first ack-eliciting packet sent since receiving a packet. Sending a PING frame causes the peer to respond with an acknowledgment, which also restarts the idle timeout for the endpoint.
QUICの実装は、アイドルタイムアウトを延期するためのオプションを使用してアプリケーションを提供するかもしれません。この機能は、アプリケーションが開いている接続に関連付けられているがしばらくの間アプリケーションデータを交換することを期待しない場合に、アプリケーションが使用する場合に使用できます。このオプションを使用すると、エンドポイントは定期的にpingフレーム（セクション19.2）を送信でき、ピアはアイドルタイムアウト期間を再開します。PINGフレームを含むパケットを送信すると、このエンドポイントのアイドルタイムアウトがパケットを受信して以降に送信された最初のACK誘発パケットである場合にも、アイドルタイムアウトを再起動します。PINGフレームを送信すると、ピアは確認応答で応答します。これはまたエンドポイントのアイドルタイムアウトを再起動します。
Application protocols that use QUIC SHOULD provide guidance on when deferring an idle timeout is appropriate. Unnecessary sending of PING frames could have a detrimental effect on performance.
QUICを使用するアプリケーションプロトコルは、アイドルタイムアウトを延期するときにガイダンスを提供する必要があります。Pingフレームの不要な送信は、パフォーマンスに有害な影響を与える可能性があります。
A connection will time out if no packets are sent or received for a period longer than the time negotiated using the max_idle_timeout transport parameter; see Section 10. 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 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows [GATEWAY].
MAX_IDLE_TIMEOUTトランスポートパラメータを使用してネゴシエートされた時間より長い期間のパケットが送受信されない場合は、接続がタイムアウトします。ただし、ミドルボックスの状態はそれより早くタイムアウトすることがあります。[RFC4787]のREQ-5は2分のタイムアウト間隔を推奨していますが、MiddleBoxがUDPフロー[Gateway]の状態が失われないようにするには、30秒ごとにパケットを送信する必要があることがわかります。
An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to terminate the connection immediately. A CONNECTION_CLOSE frame causes all streams to immediately become closed; open streams can be assumed to be implicitly reset.
エンドポイントはCONNECTION_CLOSEフレーム（セクション19.19）を送信して直ちに接続を終了します。CONNECTION_CLOSEフレームは、すべてのストリームをすぐに閉じます。オープンストリームは暗黙的にリセットされると仮定することができます。
After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the closing state; see Section 10.2.1. After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state; see Section 10.2.2.
CONNECTION_CLOSEフレームを送信した後、エンドポイントは閉じられた状態になります。10.2.1項を参照してください。CONNECTION_CLOSEフレームを受信した後、エンドポイントは排水状態を入力します。10.2.2項を参照してください。
Violations of the protocol lead to an immediate close.
プロトコルの違反は即座に閉じることにつながります。
An immediate close can be used after an application protocol has arranged to close a connection. This might be after the application protocol negotiates a graceful shutdown. The application protocol can exchange messages that are needed for both application endpoints to agree that the connection can be closed, after which the application requests that QUIC close the connection. When QUIC consequently closes the connection, a CONNECTION_CLOSE frame with an application-supplied error code will be used to signal closure to the peer.
アプリケーションプロトコルが接続を閉じるように配置された後に、即時の閉じることができます。これは、アプリケーションプロトコルが優雅なシャットダウンを交渉した後にあるかもしれません。アプリケーションプロトコルは、アプリケーションエンドポイントの両方に必要なメッセージを交換でき、その後、アプリケーションはQUICを閉じることを要求します。その結果、接続を閉じると、アプリケーション提供のエラーコードを持つCONNECTION_CLOSEフレームがピアにクロージャーを送信するために使用されます。
The closing and draining connection states exist to ensure that connections close cleanly and that delayed or reordered packets are properly discarded. These states SHOULD persist for at least three times the current PTO interval as defined in [QUIC-RECOVERY].
接続状態と排出の接続状態は、接続がきれいに閉じられ、遅延されたまたは並べ替えされたパケットが正しく廃棄されるように存在します。これらの状態は、[QUIC-Recovery]で定義されているように、現在のPTO間隔の少なくとも3倍持続する必要があります。
Disposing of connection state prior to exiting the closing or draining state could result in an endpoint generating a Stateless Reset unnecessarily when it receives a late-arriving packet. Endpoints that have some alternative means to ensure that late-arriving packets do not induce a response, such as those that are able to close the UDP socket, MAY end these states earlier to allow for faster resource recovery. Servers that retain an open socket for accepting new connections SHOULD NOT end the closing or draining state early.
閉鎖状態または排出状態を終了する前に接続状態を廃棄すると、遅延到着パケットを受信したときに不必要にステートレスリセットを生成するエンドポイントが発生する可能性があります。遅く到着したパケットがUDPソケットを閉じることができるような応答を誘発しないようにするためのいくつかの代替手段を持つエンドポイントは、より速いリソース回復を可能にするためにこれらの状態を早く終了することがあります。新しい接続を受け入れるためのオープンソケットを保持するサーバーは、閉鎖状態または排水状態を早期に終了するべきではありません。
Once its closing or draining state ends, an endpoint SHOULD discard all connection state. The endpoint MAY send a Stateless Reset in response to any further incoming packets belonging to this connection.
閉じた状態または排水状態が終了すると、エンドポイントはすべての接続状態を破棄する必要があります。エンドポイントは、この接続に属するさらなる着信パケットに応答してステートレスリセットを送信することができます。
An endpoint enters the closing state after initiating an immediate close.
エンドポイントは、即時の閉鎖を開始した後に終了状態になります。
In the closing state, an endpoint retains only enough information to generate a packet containing a CONNECTION_CLOSE frame and to identify packets as belonging to the connection. An endpoint in the closing state sends a packet containing a CONNECTION_CLOSE frame in response to any incoming packet that it attributes to the connection.
クローズ状態では、エンドポイントは、CONNECTION_CLOSEフレームを含むパケットを生成し、接続に属するパケットを識別するのに十分な情報だけを保持します。クローズ状態のエンドポイントは、接続に属性が属性になっている着信パケットに応答してCONNECTION_CLOSEフレームを含むパケットを送信します。
An endpoint SHOULD limit the rate at which it generates packets in the closing state. For instance, an endpoint could wait for a progressively increasing number of received packets or amount of time before responding to received packets.
エンドポイントは、閉じられた状態でパケットを生成するレートを制限する必要があります。例えば、エンドポイントは、受信したパケットに応答する前に、漸進的に増加した受信されたパケット数または時間を待つことができる。
An endpoint's selected connection ID and the QUIC version are sufficient information to identify packets for a closing connection; the endpoint MAY discard all other connection state. An endpoint that is closing is not required to process any received frame. An endpoint MAY retain packet protection keys for incoming packets to allow it to read and process a CONNECTION_CLOSE frame.
エンドポイントの選択された接続IDとQUICバージョンは、クローズ接続のためのパケットを識別するのに十分な情報です。エンドポイントは、他のすべての接続状態を破棄する可能性があります。閉じるエンドポイントは、受信したフレームを処理する必要はありません。エンドポイントは、着信パケットのパケット保護キーを保持して、CONNECTION_CLOSEフレームを読み書きすることを可能にします。
An endpoint MAY drop packet protection keys when entering the closing state and send a packet containing a CONNECTION_CLOSE frame in response to any UDP datagram that is received. However, an endpoint that discards packet protection keys cannot identify and discard invalid packets. To avoid being used for an amplification attack, such endpoints MUST limit the cumulative size of packets it sends to three times the cumulative size of the packets that are received and attributed to the connection. To minimize the state that an endpoint maintains for a closing connection, endpoints MAY send the exact same packet in response to any received packet.
エンドポイントは、閉じられた状態を入力し、受信されたUDPデータグラムに応答してCONNECTION_CLOSEフレームを含むパケットを送信するときにパケット保護キーを削除することができる。ただし、パケット保護キーを破棄するエンドポイントは、無効なパケットを識別して廃棄することはできません。増幅攻撃に使用されることを回避するために、そのようなエンドポイントは、受信されたパケットの累積サイズの3倍に送信され、接続に帰属するパケットの累積サイズを制限する必要があります。終点が閉鎖接続を維持する状態を最小限に抑えるために、エンドポイントは受信したパケットに応答してまったく同じパケットを送信することができる。
Note: Allowing retransmission of a closing packet is an exception to the requirement that a new packet number be used for each packet; see Section 12.3. 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.
注：終了パケットの再送信を許可することは、各パケットに新しいパケット番号を使用するという要件の例外です。 セクション12.3を参照してください。 新しいパケット番号を送信することは、主に損失回復と輻輳制御に有利です。これらは、閉じた接続には関係がないと予想されます。 最終パケットを再送信すると、必要な状態が少なくなります。
While in the closing state, an endpoint could receive packets from a new source address, possibly indicating a connection migration; see Section 9. An endpoint in the closing state MUST either discard packets received from an unvalidated address or limit the cumulative size of packets it sends to an unvalidated address to three times the size of packets it receives from that address.
閉鎖状態では、エンドポイントは新しい送信元アドレスからパケットを受信でき、おそらく接続移行を示している可能性があります。セクション9を参照してください。クランディング状態のエンドポイントは、未検証アドレスから受信したパケットを破棄するか、またはそれが未検証アドレスに送信されたパケットの累積サイズをそのアドレスから受け取るパケットのサイズの3倍に制限する必要があります。
An endpoint is not expected to handle key updates when it is closing (Section 6 of [QUIC-TLS]). A key update might prevent the endpoint from moving from the closing state to the draining state, as the endpoint will not be able to process subsequently received packets, but it otherwise has no impact.
エンドポイントは、終了しているときにキーの更新を処理することは期待されていません（[QUIC-TLS]のセクション6）。エンドポイントがその後受信されたパケットを処理することができないので、キーアップデートは終点が閉状態から排出状態への移動を妨げる可能性がありますが、それ以外の場合は影響はありません。
The draining state is entered once an endpoint receives a CONNECTION_CLOSE frame, which indicates that its peer is closing or draining. While otherwise identical to the closing state, an endpoint in the draining state MUST NOT send any packets. Retaining packet protection keys is unnecessary once a connection is in the draining state.
エンドポイントがCONNECTION_CLOSEフレームを受信すると、排水状態が入力されます。これは、そのピアが終了または排出であることを示します。それ以外の場合は、閉じられた状態と同じですが、排水状態のエンドポイントはパケットを送信してはなりません。接続が排水状態にあると、パケット保護キーを保持する必要はありません。
An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a NO_ERROR code if appropriate. An endpoint MUST NOT send further packets. Doing so could result in a constant exchange of CONNECTION_CLOSE frames until one of the endpoints exits the closing state.
CONNECTION_CLOSEフレームを受信するエンドポイントは、適切な場合にNO_ERRORコードを使用して、DRANING状態を入力する前にCONNECTION_CLOSEフレームを含む単一のパケットを送信することができます。エンドポイントはそれ以上のパケットを送信してはいけません。そのエンドポイントの1つが終了状態を終了するまで、CONNECTION_CLOSEフレームの交換を行う可能性があります。
An endpoint MAY enter the draining state from the closing state if it receives a CONNECTION_CLOSE frame, which indicates that the peer is also closing or draining. In this case, the draining state ends when the closing state would have ended. In other words, the endpoint uses the same end time but ceases transmission of any packets on this connection.
エンドポイントは、CONNECTION_CLOSEフレームを受信した場合、閉じた状態から排出状態を入力することができます。これは、ピアが閉鎖または排出であることを示しています。この場合、閉状態が終了したときに排水状態が終了します。言い換えれば、エンドポイントは同じ終了時刻を使用しますが、この接続上のパケットの送信を中止します。
When sending a CONNECTION_CLOSE frame, the goal is to ensure that the peer will process the frame. Generally, this means sending the frame in a packet with the highest level of packet protection to avoid the packet being discarded. After the handshake is confirmed (see Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to confirming the handshake, it is possible that more advanced packet protection keys are not available to the peer, so another CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower packet protection level. More specifically:
CONNECTION_CLOSEフレームを送信するとき、目標は、ピアがフレームを処理するようにすることです。一般に、これは、パケットが破棄されないようにするために、最高レベルのパケット保護を有するパケット内のフレームを送信することを意味する。ハンドシェイクが確認された後（[QUIC-TLS]のセクション4.1.2参照）、エンドポイントは1 RTTパケットにCONNECTION_CLOSEフレームを送信する必要があります。ただし、ハンドシェイクを確認する前に、より高度なパケット保護キーがピアに使用できないため、低いパケット保護レベルを使用するパケットで別のCONNECTION_CLOSEフレームを送信できます。すなわち：
* A client will always know whether the server has Handshake keys (see Section 17.2.2.1), but it is possible that a server does not know whether the client has Handshake keys. Under these circumstances, a server SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at least one of them is processable by the client.
* クライアントは常にサーバーにハンドシェイクキーを持っているかどうかがわかります（セクション17.2.2.2.1を参照）が、サーバーがクライアントがハンドシェイクキーを持っているかどうかわからない可能性があります。このような状況下で、サーバーは、それらの少なくとも1つがクライアントによって処理可能であることを確認するために、ハンドシェイクと初期パケットの両方でCONNECTION_CLOSEフレームを送信する必要があります。
* A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet cannot be assured that the server has accepted 0-RTT. Sending a CONNECTION_CLOSE frame in an Initial packet makes it more likely that the server can receive the close signal, even if the application error code might not be received.
* 0-RTTパケットにCONNECTION_CLOSEフレームを送信するクライアントは、サーバーが0-RTTを受け入れたことを保証できません。最初のパケットにCONNECTION_CLOSEフレームを送信すると、アプリケーションエラーコードが受信されなくても、サーバーが閉じる信号を受信できる可能性が高くなります。
* Prior to confirming the handshake, a peer might be unable to process 1-RTT packets, so an endpoint SHOULD send a CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. A server SHOULD also send a CONNECTION_CLOSE frame in an Initial packet.
* ハンドシェイクを確認する前に、ピアは1-RTTパケットを処理できないため、エンドポイントはHandshakeと1-RTTパケットの両方にCONNECTION_CLOSEフレームを送信する必要があります。サーバーは、最初のパケットにCONNECTION_CLOSEフレームを送信する必要があります。
Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake packet could expose application state or be used to alter application state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or Handshake packets. Otherwise, information about the application state might be revealed. Endpoints MUST clear the value of the Reason Phrase field and SHOULD use the APPLICATION_ERROR code when converting to a CONNECTION_CLOSE of type 0x1c.
最初またはハンドシェイクパケットにType 0x1dのconnection_closeを送信すると、アプリケーションの状態が表示されるか、またはアプリケーションの状態を変更するために使用できます。タイプ0x1dのconnection_closeは、最初のまたはハンドシェイクパケットのフレームを送信するときに、タイプ0x1cのconnection_closeに置き換えなければなりません。それ以外の場合は、アプリケーションの状態に関する情報が表示されることがあります。エンドポイントは、Reason Phressフィールドの値をクリアする必要があり、APPREST_ERRORコードを使用すると、Type 0x1cのconnection_closeに変換する必要があります。
CONNECTION_CLOSE frames sent in multiple packet types can be coalesced into a single UDP datagram; see Section 12.2.
複数のパケットタイプで送信されたCONNECTION_CLOSEフレームは、単一のUDPデータグラムに合体することができます。12.2項を参照してください。
An endpoint can send a CONNECTION_CLOSE frame in an Initial packet. This might be in response to unauthenticated information received in Initial or Handshake packets. Such an immediate close might expose legitimate connections to a denial of service. QUIC does not include defensive measures for on-path attacks during the handshake; see Section 21.2. However, at the cost of reducing feedback about errors for legitimate peers, some forms of denial of service can be made more difficult for an attacker if endpoints discard illegal packets rather than terminating a connection with CONNECTION_CLOSE. For this reason, endpoints MAY discard packets rather than immediately close if errors are detected in packets that lack authentication.
エンドポイントは、最初のパケットにCONNECTION_CLOSEフレームを送信できます。これは、最初またはハンドシェイクパケットで受信されていない情報に応答している可能性があります。そのような即時の近くは、正当な接続をサービス拒否に公開するかもしれません。QUICには、ハンドシェイク中の経路上の攻撃に対する防御的な措置は含まれていません。21.2項を参照してください。しかしながら、正当なピアのエラーに関するフィードバックを減らすためのコストでは、Endpointsがconnection_closeとの接続を終了するのではなく、不正なパケットを破棄する場合、いくつかの形態のサービス拒否を攻撃者にとってより困難にすることができます。このため、エンドポイントは、認証を欠いているパケットでエラーが検出された場合は、直ちに閉じるのではなくパケットを破棄することがあります。
An endpoint that has not established state, such as a server that detects an error in an Initial packet, does not enter the closing state. An endpoint that has no state for the connection does not enter a closing or draining period on sending a CONNECTION_CLOSE frame.
初期パケット内のエラーを検出するサーバなどの状態を確立していないエンドポイントは、クローズ状態に入りません。接続の状態がないエンドポイントは、CONNECTION_CLOSEフレームを送信するときに閉鎖または排出期間を入力しません。
A stateless reset is provided as an option of last resort for an endpoint that does not have access to the state of a connection. A crash or outage might result in peers continuing to send data to an endpoint that is unable to properly continue the connection. An endpoint MAY send a Stateless Reset in response to receiving a packet that it cannot associate with an active connection.
ステートレスリセットは、接続の状態にアクセスできないエンドポイントの最後のリゾートのオプションとして提供されています。クラッシュまたは停止は、接続を正しく続行できないエンドポイントにデータを送信し続けることになる可能性があります。エンドポイントは、アクティブな接続に関連付けることができないパケットを受信することに応答してステートレスリセットを送信することができます。
A stateless reset is not appropriate for indicating errors in active connections. An endpoint that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE frame if it is able.
ステートレスリセットは、アクティブ接続のエラーを示すには適していません。致命的な接続エラーを伝達したいエンドポイントは、有効な場合はCONNECTION_CLOSEフレームを使用する必要があります。
To support this process, an endpoint issues a stateless reset token, which is a 16-byte value that is hard to guess. If the peer subsequently receives a Stateless Reset, which is a UDP datagram that ends in that stateless reset token, the peer will immediately end the connection.
このプロセスをサポートするために、エンドポイントはステートレスリセットトークンを発行します。これは、推測するのが難しい16バイトの値です。その後ピアがステートレスリセットを受信した場合、そのステートレスリセットトークンで終わるUDPデータグラムである場合、ピアは直ちに接続を終了します。
A stateless reset token is specific to a connection ID. An endpoint issues a stateless reset token by including the value in the Stateless Reset Token field of a NEW_CONNECTION_ID frame. Servers can also issue a stateless_reset_token transport parameter during the handshake that applies to the connection ID that it selected during the handshake. These exchanges are protected by encryption, so only client and server know their value. Note that clients cannot use the stateless_reset_token transport parameter because their transport parameters do not have confidentiality protection.
ステートレスリセットトークンは接続IDに固有のものです。エンドポイントは、NEW_CONNECTION_IDフレームのステートレスリセットトークンフィールドに値を含めることによってステートレスリセットトークンを発行します。サーバーは、ハンドシェイク中に選択された接続IDに適用されるハンドシェイク中にStateless_RESET_TOKENトランスポートパラメータを発行することもできます。これらの交換は暗号化によって保護されているため、クライアントとサーバーのみが自分の値を知っています。トランスポートパラメータには機密保護がないため、クライアントはstateless_reset_tokenトランスポートパラメータを使用できません。
Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (Section 19.16).
トークンは、それらの関連接続IDがRETIRE_CONNECTION_IDフレームを介して引退されたときに無効化されます（セクション19.16）。
An endpoint that receives packets that it cannot process sends a packet in the following layout (see Section 1.3):
処理できないパケットを受信するエンドポイントは、次のレイアウトでパケットを送信します（セクション1.3を参照）。
Stateless Reset {
Fixed Bits (2) = 1,
Unpredictable Bits (38..),
Stateless Reset Token (128),
}
Figure 10: Stateless Reset
図10：ステートレスリセット
This design ensures that a Stateless Reset is -- to the extent possible -- indistinguishable from a regular packet with a short header.
この設計により、ステートレスリセットが可能な限り、短いヘッダーを持つ通常のパケットと区別できない程度までのようになります。
A Stateless Reset uses an entire UDP datagram, starting with the first two bits of the packet header. The remainder of the first byte and an arbitrary number of bytes following it are set to values that SHOULD be indistinguishable from random. The last 16 bytes of the datagram contain a stateless reset token.
ステートレスリセットは、パケットヘッダーの最初の2ビットから始めて、UDPデータグラム全体を使用します。最初のバイトの残りの部分とそれに続く任意のバイト数は、ランダムと区別できない値に設定されます。データグラムの最後の16バイトには、ステートレスリセットトークンが含まれています。
To entities other than its intended recipient, a Stateless Reset will appear to be a packet with a short header. For the Stateless Reset to appear as a valid QUIC packet, the Unpredictable Bits field needs to include at least 38 bits of data (or 5 bytes, less the two fixed bits).
意図された受信者以外のエンティティには、ステートレスリセットが短いヘッダーを持つパケットのように見えます。ステートレスリセットが有効なQUICパケットとして表示されるためには、予測不可能なビットフィールドには少なくとも38ビットのデータ（または5バイト、2つの固定ビットが少なく）を含める必要があります。
The resulting minimum size of 21 bytes does not guarantee that a Stateless Reset is difficult to distinguish from other packets if the recipient requires the use of a connection ID. To achieve that end, the endpoint SHOULD ensure that all packets it sends are at least 22 bytes longer than the minimum connection ID length that it requests the peer to include in its packets, adding PADDING frames as necessary. This ensures that any Stateless Reset sent by the peer is indistinguishable from a valid packet sent to the endpoint. An endpoint that sends a Stateless Reset in response to a packet that is 43 bytes or shorter SHOULD send a Stateless Reset that is one byte shorter than the packet it responds to.
結果として生じる最小サイズ21バイトは、受信者が接続IDの使用を必要とする場合、ステートレスリセットが他のパケットと区別するのが困難であることを保証しません。その最後を達成するために、エンドポイントは、それが送信するすべてのパケットが、ピアにパケットに含めることを要求し、必要に応じてパディングフレームを追加する最小接続ID長より少なくとも22バイトであることを確認する必要があります。これにより、ピアによって送信されたステートレスリセットは、エンドポイントに送信された有効なパケットと区別がつかないようになります。43バイトまたは短いパケットに応答してステートレスリセットを送信するエンドポイントは、それが応答するパケットより1バイト短いステートレスリセットを送信する必要があります。
These values assume that the stateless reset token is the same length as the minimum expansion of the packet protection AEAD. Additional unpredictable bytes are necessary if the endpoint could have negotiated a packet protection scheme with a larger minimum expansion.
これらの値は、ステートレスリセットトークンがパケット保護AEADの最小展開と同じ長さであると仮定します。エンドポイントが最小拡張の大きいパケット保護方式をネゴシエートした可能性がある場合、追加の予期しないバイトが必要です。
An endpoint MUST NOT send a Stateless Reset that is three times or more larger than the packet it receives to avoid being used for amplification. Section 10.3.3 describes additional limits on Stateless Reset size.
エンドポイントは、増幅に使用されないように、受信したパケットよりも3倍以上のステートレスリセットを送信してはなりません。セクション10.3.3では、ステートレスリセットサイズの追加の制限について説明します。
Endpoints MUST discard packets that are too small to be valid QUIC packets. To give an example, with the set of AEAD functions defined in [QUIC-TLS], short header packets that are smaller than 21 bytes are never valid.
エンドポイントは、有効なQUICパケットになるには小さすぎるパケットを破棄する必要があります。例を与えるには、[QUIC-TLS]で定義されているAEAD関数のセットを使用して、21バイトより小さい短いヘッダーパケットは有効ではありません。
Endpoints MUST send Stateless Resets formatted as a packet with a short header. However, endpoints MUST treat any packet ending in a valid stateless reset token as a Stateless Reset, as other QUIC versions might allow the use of a long header.
エンドポイントは、パケットとしてフォーマットされたステートレスリセットを短いヘッダーで送信する必要があります。ただし、他のQUICバージョンがロングヘッダーを使用できるように、エンドポイントは有効なステートレスリセットトークンで終了したパケットをステートレスリセットとして扱う必要があります。
An endpoint MAY send a Stateless Reset in response to a packet with a long header. Sending a Stateless Reset is not effective prior to the stateless reset token being available to a peer. In this QUIC version, packets with a long header are only used during connection establishment. Because the stateless reset token is not available until connection establishment is complete or near completion, ignoring an unknown packet with a long header might be as effective as sending a Stateless Reset.
エンドポイントは、長いヘッダーを持つパケットに応答してステートレスリセットを送信することがあります。ステートレスリセットの送信は、ステートレスリセットトークンがピアに使用可能になる前に有効ではありません。このQUICバージョンでは、長いヘッダーを持つパケットは接続確立中にのみ使用されます。ステートレスリセットトークンは、接続確立が完了または近づいているまで使用できないため、長いヘッダーを持つ不明なパケットを無視すると、ステートレスリセットを送信するのと同じくらい効果的です。
An endpoint cannot determine the Source Connection ID from a packet with a short header; therefore, it cannot set the Destination Connection ID in the Stateless Reset. The Destination Connection ID will therefore differ from the value used in previous packets. A random Destination Connection ID makes the connection ID appear to be the result of moving to a new connection ID that was provided using a NEW_CONNECTION_ID frame; see Section 19.15.
エンドポイントは、短いヘッダーを持つパケットからソース接続IDを決定できません。したがって、ステートレスリセットに宛先接続IDを設定できません。したがって、宛先接続IDは以前のパケットで使用されている値と異なります。ランダムな宛先接続IDは、NEW_CONNECTION_IDフレームを使用して提供された新しい接続IDに移行した結果を接続IDに表示させる。セクション19.15を参照してください。
Using a randomized connection ID results in two problems:
ランダム化された接続IDを使用すると、2つの問題が発生します。
* The packet might not reach the peer. If the Destination Connection ID is critical for routing toward the peer, then this packet could be incorrectly routed. This might also trigger another Stateless Reset in response; see Section 10.3.3. A Stateless Reset that is not correctly routed is an ineffective error detection and recovery mechanism. In this case, endpoints will need to rely on other methods -- such as timers -- to detect that the connection has failed.
* パケットはピアに届かない可能性があります。宛先接続IDがピアに向かってルーティングするために重要である場合、このパケットは誤ってルーティングされる可能性があります。これに応答して別のステートレスリセットをトリガすることもあります。10.3.3項を参照してください。正しくルーティングされていないステートレスリセットは、無効なエラー検出および回復メカニズムです。この場合、エンドポイントは、接続が失敗したことを検出するために、タイマーなどの他の方法に頼る必要があります。
* The randomly generated connection ID can be used by entities other than the peer to identify this as a potential Stateless Reset. An endpoint that occasionally uses different connection IDs might introduce some uncertainty about this.
* ランダムに生成された接続IDは、これを潜在的なステートレスリセットとして識別するためにピア以外のエンティティで使用できます。異なる接続IDを使用する場合には、これについての不確実性が発生する可能性があります。
This stateless reset design is specific to QUIC version 1. An endpoint that supports multiple versions of QUIC needs to generate a Stateless Reset that will be accepted by peers that support any version that the endpoint might support (or might have supported prior to losing state). Designers of new versions of QUIC need to be aware of this and either (1) reuse this design or (2) use a portion of the packet other than the last 16 bytes for carrying data.
このステートレスリセット設計は、QUICバージョン1に固有のものです。。これを認識する必要がある新しいバージョンの設計者は、このデザインを再利用する必要があるか（2）データを搬送するための最後の16バイト以外のパケットの一部を使用してください。
An endpoint detects a potential Stateless Reset using the trailing 16 bytes of the UDP datagram. An endpoint remembers all stateless reset tokens associated with the connection IDs and remote addresses for datagrams it has recently sent. This includes Stateless Reset Token field values from NEW_CONNECTION_ID frames and the server's transport parameters but excludes stateless reset tokens associated with connection IDs that are either unused or retired. The endpoint identifies a received datagram as a Stateless Reset by comparing the last 16 bytes of the datagram with all stateless reset tokens associated with the remote address on which the datagram was received.
エンドポイントは、UDPデータグラムの末尾の16バイトを使用して潜在的なステートレスリセットを検出します。エンドポイントは、最近送信されたデータグラムの接続IDとリモートアドレスに関連付けられているすべてのステートレスリセットトークンを記憶します。これには、NEW_CONNECTION_IDフレームとサーバーのトランスポートパラメータからのステートレスリセットトークンフィールド値が含まれますが、未使用または引退した接続IDに関連付けられているステートレスリセットトークンを除外します。エンドポイントは、データグラムが受信したリモートアドレスに関連するリモートアドレスに関連付けられているすべてのステートレスリセットトークンとの最後の16バイトと、受信したデータグラムをステートレスリセットとして識別します。
This comparison can be performed for every inbound datagram. Endpoints MAY skip this check if any packet from a datagram is successfully processed. However, the comparison MUST be performed when the first packet in an incoming datagram either cannot be associated with a connection or cannot be decrypted.
この比較は、インバウンドデータグラムごとに実行できます。エンドポイントは、データグラムからのパケットが正常に処理された場合にこのチェックをスキップすることができます。ただし、受信データグラムの最初のパケットを接続に関連付けることもできない場合、または復号化できない場合は、比較を実行する必要があります。
An endpoint MUST NOT check for any stateless reset tokens associated with connection IDs it has not used or for connection IDs that have been retired.
エンドポイントは、使用していない接続IDに関連付けられているステートレスリセットトークンをチェックしてはいけません。
When comparing a datagram to stateless reset token values, endpoints MUST perform the comparison without leaking information about the value of the token. For example, performing this comparison in constant time protects the value of individual stateless reset tokens from information leakage through timing side channels. Another approach would be to store and compare the transformed values of stateless reset tokens instead of the raw token values, where the transformation is defined as a cryptographically secure pseudorandom function using a secret key (e.g., block cipher, Hashed Message Authentication Code (HMAC) [RFC2104]). An endpoint is not expected to protect information about whether a packet was successfully decrypted or the number of valid stateless reset tokens.
データグラムをステートレスリセットトークン値と比較するとき、エンドポイントはトークンの値に関する情報を漏らさずに比較を実行する必要があります。たとえば、この比較を一定に実行すると、タイミングサイドチャネルを介して個々のステートレスリセットトークンの値が情報漏洩から保護します。別のアプローチは、RAWトークン値の代わりにステートレスリセットトークンの変換された値を保存して比較することです。ここで、変換は、秘密鍵を使用して暗号的に安全な疑似乱数関数として定義されます（例：ブロック暗号、ハッシュメッセージ認証コード（HMAC））。[RFC2104]）。エンドポイントは、パケットが正常に復号化されたかどうか、または有効なステートレスリセットトークンの数に関する情報を保護することは期待されていません。
If the last 16 bytes of the datagram are identical in value to a stateless reset token, the endpoint MUST enter the draining period and not send any further packets on this connection.
Datagramの最後の16バイトがステートレスリセットトークンに同じ値で同じである場合、エンドポイントは排水期間を入力し、この接続でそれ以上のパケットを送信しなければなりません。
The stateless reset token MUST be difficult to guess. In order to create a stateless reset token, an endpoint could randomly generate [RANDOM] a secret for every connection that it creates. However, this presents a coordination problem when there are multiple instances in a cluster or a storage problem for an endpoint that might lose state. Stateless reset specifically exists to handle the case where state is lost, so this approach is suboptimal.
ステートレスリセットトークンは推測するのが難しい必要があります。ステートレスリセットトークンを作成するために、エンドポイントがランダムに[ランダム]を作成することができます。ただし、クラスタ内に複数のインスタンスや状態が失われる可能性があるエンドポイントのストレージの問題がある場合に調整の問題が表示されます。ステートレスリセットは、状態が失われた場合を処理するために特に存在しますので、このアプローチは最適です。
A single static key can be used across all connections to the same endpoint by generating the proof using a pseudorandom function that takes a static key and the connection ID chosen by the endpoint (see Section 5.1) as input. An endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, connection_id)) or the HMAC-based Key Derivation Function (HKDF) [RFC5869] (for example, using the static key as input keying material, with the connection ID as salt). The output of this function is truncated to 16 bytes to produce the stateless reset token for that connection.
単一の静的キーは、静的キーとエンドポイントによって選択された接続ID（セクション5.1を参照）を使用して、疑似キーと入力として選択された接続IDを使用して、同じエンドポイントへのすべての接続にわたって使用できます。エンドポイントは、HMAC [RFC2104]（たとえば、HMAC（static_key、connection_id））またはHMACベースのキー派生関数（HKDF）[RFC5869]（たとえば、静的キーを使用して、接続IDを使用して塩として）。この関数の出力は16バイトに切り捨てられ、その接続のステートレスリセットトークンを生成します。
An endpoint that loses state can use the same method to generate a valid stateless reset token. The connection ID comes from the packet that the endpoint receives.
状態を失うエンドポイントは、同じ方法で有効なステートレスリセットトークンを生成できます。接続IDは、エンドポイントが受信するパケットからのものです。
This design relies on the peer always sending a connection ID in its packets so that the endpoint can use the connection ID from a packet to reset the connection. An endpoint that uses this design MUST either use the same connection ID length for all connections or encode the length of the connection ID such that it can be recovered without state. In addition, it cannot provide a zero-length connection ID.
このデザインは、エンドポイントがパケットから接続IDを使用して接続をリセットできるように、ピアに常に接続IDを送信するように依存しています。この設計を使用するエンドポイントは、すべての接続に対して同じ接続ID長を使用するか、接続IDの長さを順次符号化する必要があります。また、長さゼロの接続IDを提供することはできません。
Revealing the stateless reset token allows any entity to terminate the connection, so a value can only be used once. This method for choosing the stateless reset token means that the combination of connection ID and static key MUST NOT be used for another connection. A denial-of-service attack is possible if the same connection ID is used by instances that share a static key or if an attacker can cause a packet to be routed to an instance that has no state but the same static key; see Section 21.11. A connection ID from a connection that is reset by revealing the stateless reset token MUST NOT be reused for new connections at nodes that share a static key.
ステートレスリセットトークンを明らかにすると、任意のエンティティが接続を終了することができるので、値は一度使用できます。ステートレスリセットトークンを選択するためのこの方法は、接続IDとスタティックキーの組み合わせが別の接続に使用されてはならないことを意味します。静的キーを共有するインスタンスによって同じ接続IDが使用されている場合、または攻撃者がSTATICキーを持たないインスタンスへのルーティングされる可能性がある場合は、サービス拒否攻撃が可能です。21.11節を参照してください。ステートレスリセットトークンを明示してリセットされた接続からの接続IDは、静的キーを共有するノードで新しい接続のために再利用されてはいけません。
The same stateless reset token MUST NOT be used for multiple connection IDs. Endpoints are not required to compare new values against all previous values, but a duplicate value MAY be treated as a connection error of type PROTOCOL_VIOLATION.
同じステートレスリセットトークンを複数の接続IDに使用しないでください。エンドポイントは、新しい値をすべての以前の値と比較する必要はありませんが、重複した値はPROTOCOL_VIOLATION型の接続エラーとして扱われることがあります。
Note that Stateless Resets do not have any cryptographic protection.
ステートレスリセットには暗号保護がありません。
The design of a Stateless Reset is such that without knowing the stateless reset token it is indistinguishable from a valid packet. For instance, if a server sends a Stateless Reset to another server, it might receive another Stateless Reset in response, which could lead to an infinite exchange.
ステートレスリセットの設計は、ステートレスリセットトークンを知らずに有効なパケットと区別がつかないようなものです。たとえば、サーバーが他のサーバーにステートレスリセットを送信した場合、それに応答して別のステートレスリセットを受信する可能性があります。これは無限のExchangeにつながる可能性があります。
An endpoint MUST ensure that every Stateless Reset that it sends is smaller than the packet that triggered it, unless it maintains state sufficient to prevent looping. In the event of a loop, this results in packets eventually being too small to trigger a response.
エンドポイントは、それがループを防ぐのに十分な状態を維持しない限り、それが送信するすべてのステートレスリセットがそれをトリガーしたパケットよりも小さいことを確認する必要があります。ループが発生した場合、この結果は最終的には応答を引き起こすには小さすぎることがあります。
An endpoint can remember the number of Stateless Resets that it has sent and stop generating new Stateless Resets once a limit is reached. Using separate limits for different remote addresses will ensure that Stateless Resets can be used to close connections when other peers or connections have exhausted limits.
エンドポイントは、限界に達すると、送信されたステートレスリセットの数を送信し、新しいステートレスリセットの生成を停止することができます。さまざまなリモートアドレスに別々の制限を使用すると、他のピアや接続が排出された制限があるときに、ステートレスリセットを使用してステートレスリセットを使用できます。
A Stateless Reset that is smaller than 41 bytes might be identifiable as a Stateless Reset by an observer, depending upon the length of the peer's connection IDs. Conversely, not sending a Stateless Reset in response to a small packet might result in Stateless Resets not being useful in detecting cases of broken connections where only very small packets are sent; such failures might only be detected by other means, such as timers.
41バイトより小さいステートレスリセットは、ピアの接続IDの長さに応じて、オブザーバによるステートレスリセットとして識別可能です。逆に、小さなパケットに応答してステートレスリセットを送信しないことは、非常に小さなパケットのみが送信される壊れた接続のケースを検出するのに役立たない可能性があります。そのような障害は、タイマーのような他の手段によってのみ検出されるかもしれません。
An endpoint that detects an error SHOULD signal the existence of that error to its peer. Both transport-level and application-level errors can affect an entire connection; see Section 11.1. Only application-level errors can be isolated to a single stream; see Section 11.2.
エラーを検出するエンドポイントは、そのエラーの存在をそのピアにシグナリングする必要があります。トランスポートレベルとアプリケーションレベルのエラーの両方が接続全体に影響を与える可能性があります。11.1項を参照してください。アプリケーションレベルのエラーのみを単一のストリームに分離できます。11.2項を参照してください。
The most appropriate error code (Section 20) SHOULD be included in the frame that signals the error. Where this specification identifies error conditions, it also identifies the error code that is used; though these are worded as requirements, different implementation strategies might lead to different errors being reported. In particular, an endpoint MAY use any applicable error code when it detects an error condition; a generic error code (such as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place of specific error codes.
最も適切なエラーコード（セクション20）は、エラーを知らせるフレームに含める必要があります。この仕様がエラー状態を識別する場合は、使用されるエラーコードも識別します。これらは要件として言及されていますが、さまざまな実装戦略が報告された異なるエラーにつながる可能性があります。特に、エンドポイントは、エラー状態を検出したときに適用可能なエラーコードを使用することがあります。一般的なエラーコード（PROTOCOL_VIOLATIONやINTERNAL_ERRORなど）は、特定のエラーコードの代わりに常に使用できます。
A stateless reset (Section 10.3) is not suitable for any error that can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A stateless reset MUST NOT be used by an endpoint that has the state necessary to send a frame on the connection.
ステートレスリセット（セクション10.3）は、CONNECTION_CLOSEまたはRESET_STREAMフレームでシグナリングできるエラーには適していません。ステートレスリセットは、接続にフレームを送信するために必要な状態を持つエンドポイントで使用しないでください。
Errors that result in the connection being unusable, such as an obvious violation of protocol semantics or corruption of state that affects an entire connection, MUST be signaled using a CONNECTION_CLOSE frame (Section 19.19).
コネクション全体のプロトコルセマンティクスの明らかな違反または接続全体に影響を与える状態の破損など、接続をもたらすエラーは、CONNECTION_CLOSEフレームを使用してシグナリングする必要があります（セクション19.19）。
Application-specific protocol errors are signaled using the CONNECTION_CLOSE frame with a frame type of 0x1d. Errors that are specific to the transport, including all those described in this document, are carried in the CONNECTION_CLOSE frame with a frame type of 0x1c.
アプリケーション固有のプロトコルエラーは、フレームタイプの0x1Dを持つCONNECTION_CLOSEフレームを使用してシグナリングされます。この文書で説明されているすべてのものを含むトランスポートに固有のエラーは、CONNECTION_CLOSEフレームでフレームタイプの0x1cを持ちます。
A CONNECTION_CLOSE frame could be sent in a packet that is lost. An endpoint SHOULD be prepared to retransmit a packet containing a CONNECTION_CLOSE frame if it receives more packets on a terminated connection. Limiting the number of retransmissions and the time over which this final packet is sent limits the effort expended on terminated connections.
CONNECTION_CLOSEフレームは、失われたパケットで送信できます。終端接続でより多くのパケットを受信した場合、CONNECTION_CLOSEフレームを含むパケットを再送信するようにエンドポイントを準備する必要があります。再送信数とこの最終パケットが送信される時間を制限すると、終了接続に費やされた努力が制限されます。
An endpoint that chooses not to retransmit packets containing a CONNECTION_CLOSE frame risks a peer missing the first such packet. The only mechanism available to an endpoint that continues to receive data for a terminated connection is to attempt the stateless reset process (Section 10.3).
CONNECTION_CLOSEフレームを含むパケットを再送信しないことを選択したエンドポイントは、ピアが最初にそのようなパケットを欠出しています。終了した接続のデータを受信し続けるエンドポイントで利用可能な唯一のメカニズムは、ステートレスリセットプロセスを試みることです（セクション10.3）。
As the AEAD for Initial packets does not provide strong authentication, an endpoint MAY discard an invalid Initial packet. Discarding an Initial packet is permitted even where this specification otherwise mandates a connection error. An endpoint can only discard a packet if it does not process the frames in the packet or reverts the effects of any processing. Discarding invalid Initial packets might be used to reduce exposure to denial of service; see Section 21.2.
初期パケットのためのAEADが強力な認証を提供しないので、エンドポイントは無効な初期パケットを破棄する可能性があります。この仕様でも接続エラーを義務付ける場合でも、最初のパケットを破棄することは許可されます。エンドポイントは、パケット内のフレームを処理しない場合にのみパケットを破棄したり、処理の効果を元に戻すことができます。無効な初期パケットを破棄することで、サービス拒否へのエクスポージャーを軽減することができます。21.2項を参照してください。
If an application-level error affects a single stream but otherwise leaves the connection in a recoverable state, the endpoint can send a RESET_STREAM frame (Section 19.4) with an appropriate error code to terminate just the affected stream.
アプリケーションレベルのエラーが単一のストリームに影響を及ぼすが、回復可能な状態で接続を残すと、エンドポイントはRESET_STREAMフレーム（セクション19.4）を適切なエラーコードで送信して、影響を受けるストリームだけを終了させることができます。
Resetting a stream without the involvement of the application protocol could cause the application protocol to enter an unrecoverable state. RESET_STREAM MUST only be instigated by the application protocol that uses QUIC.
アプリケーションプロトコルの関与なしにストリームをリセットすると、アプリケーションプロトコルが回復不能状態になります。RESET_STREAMは、QUICを使用するアプリケーションプロトコルによってのみインセットされている必要があります。
The semantics of the application error code carried in RESET_STREAM are defined by the application protocol. Only the application protocol is able to cause a stream to be terminated. A local instance of the application protocol uses a direct API call, and a remote instance uses the STOP_SENDING frame, which triggers an automatic RESET_STREAM.
RESET_STREAMで搭載されているアプリケーションエラーコードのセマンティクスは、アプリケーションプロトコルによって定義されています。ストリームを終了させることができるアプリケーションプロトコルだけです。アプリケーションプロトコルのローカルインスタンスはDirect API呼び出しを使用し、リモートインスタンスはSTOP_SENDINGフレームを使用します。これは自動reset_streamをトリガします。
Application protocols SHOULD define rules for handling streams that are prematurely canceled by either endpoint.
アプリケーションプロトコルは、どちらのエンドポイントによって時期尚早にキャンセルされているストリームを処理するためのルールを定義する必要があります。
QUIC endpoints communicate by exchanging packets. Packets have confidentiality and integrity protection; see Section 12.1. Packets are carried in UDP datagrams; see Section 12.2.
QUICのエンドポイントは、パケットを交換することによって通信します。パケットには機密性と完全性の保護があります。12.1項を参照してください。パケットはUDPデータグラムで運ばれます。12.2項を参照してください。
This version of QUIC uses the long packet header during connection establishment; see Section 17.2. Packets with the long header are Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation uses a version-independent packet with a long header; see Section 17.2.1.
このバージョンのQUICは、接続確立中にロングパケットヘッダーを使用します。17.2節を参照してください。ロングヘッダーを持つパケットは初期（セクション17.2.2）、0-RTT（17.2.3項）、ハンドシェイク（第17.2.4項）、および再試行（セクション17.2.5）です。バージョンネゴシエーションは、長いヘッダーを持つバージョンに依存しないパケットを使用します。17.2.1項を参照してください。
Packets with the short header are designed for minimal overhead and are used after a connection is established and 1-RTT keys are available; see Section 17.3.
短いヘッダーを持つパケットは、最小限のオーバーヘッド用に設計されており、接続が確立され、1-RTTキーが利用可能になります。17.3節を参照してください。
QUIC packets have different levels of cryptographic protection based on the type of packet. Details of packet protection are found in [QUIC-TLS]; this section includes an overview of the protections that are provided.
QUICパケットは、パケットの種類に基づいて異なるレベルの暗号保護を有する。パケット保護の詳細は[QUIC-TLS]にあります。このセクションには、提供されている保護の概要が含まれています。
Version Negotiation packets have no cryptographic protection; see [QUIC-INVARIANTS].
バージョンネゴシエーションパケットには暗号保護はありません。[QUIC-INVARIANTS]を参照してください。
Retry packets use an AEAD function [AEAD] to protect against accidental modification.
再試行パケットは、偶発的な修正から保護するためにAEAD機能[AEAD]を使用してください。
Initial packets use an AEAD function, the keys for which are derived using a value that is visible on the wire. Initial packets therefore do not have effective confidentiality protection. Initial protection exists to ensure that the sender of the packet is on the network path. Any entity that receives an Initial packet from a client can recover the keys that will allow them to both read the contents of the packet and generate Initial packets that will be successfully authenticated at either endpoint. The AEAD also protects Initial packets against accidental modification.
初期パケットはAEAD機能を使用します。キーは、ワイヤに表示される値を使用して導出されます。したがって、初期パケットは効果的な機密保護を保護していません。パケットの送信者がネットワークパス上にあることを確認するために、最初の保護が存在します。クライアントから初期パケットを受信するエンティティは、それらがパケットの内容を読み取り、どちらのエンドポイントで正常に認証される初期パケットを生成することもできるというキーを回復できます。AEDはまた、偶発的な変更に対して初期パケットを保護します。
All other packets are protected with keys derived from the cryptographic handshake. The cryptographic handshake ensures that only the communicating endpoints receive the corresponding keys for Handshake, 0-RTT, and 1-RTT packets. Packets protected with 0-RTT and 1-RTT keys have strong confidentiality and integrity protection.
他のすべてのパケットは暗号ハンドシェイクから派生したキーで保護されています。暗号化ハンドシェイクは、通信エンドポイントのみがハンドシェイク、0-RTT、および1-RTTパケットの対応するキーを受信することを保証します。0-RTTキーと1-RTTキーで保護されているパケットには、強い機密性と完全性保護があります。
The Packet Number field that appears in some packet types has alternative confidentiality protection that is applied as part of header protection; see Section 5.4 of [QUIC-TLS] for details. The underlying packet number increases with each packet sent in a given packet number space; see Section 12.3 for details.
一部のパケットタイプに表示されるパケット番号フィールドには、ヘッダー保護の一部として適用される代替機密保持保護があります。詳細については、[QUIC-TLS]のセクション5.4を参照してください。基礎となるパケット番号は、特定のパケット番号スペースで送信された各パケットと共に増加します。詳細については12.3項を参照してください。
Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake (Section 17.2.4) packets contain a Length field that determines the end of the packet. The length includes both the Packet Number and Payload fields, both of which are confidentiality protected and initially of unknown length. The length of the Payload field is learned once header protection is removed.
Initial（17.2.2項）、0-RTT（17.2.3項）、および Handshake（17.2.4節）パケットには、パケットの終わりを決定する長さフィールドが含まれています。長さには、パケット番号とペイロードフィールドの両方が含まれていますが、どちらも保護されている機密性が保護され、最初は未知の長さの両方です。ペイロードフィールドの長さは、ヘッダー保護が削除されると、頻繁に学習されます。
Using the Length field, a sender can coalesce multiple QUIC packets into one UDP datagram. This can reduce the number of UDP datagrams needed to complete the cryptographic handshake and start sending data. This can also be used to construct Path Maximum Transmission Unit (PMTU) probes; see Section 14.4.1. Receivers MUST be able to process coalesced packets.
長さフィールドを使用して、送信者は複数のQUICパケットを1つのUDPデータグラムに接続できます。これにより、暗号化ハンドシェイクを完了し、データの送信を開始するために必要なUDPデータグラムの数を減らすことができます。これは、経路最大伝送ユニット（PMTU）プローブを構築するためにも使用され得る。第14.4.1項を参照してください。受信機は合体パケットを処理できなければなりません。
Coalescing packets in order of increasing encryption levels (Initial, 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it more likely that the receiver will be able to process all the packets in a single pass. A packet with a short header does not include a length, so it can only be the last packet included in a UDP datagram. An endpoint SHOULD include multiple frames in a single packet if they are to be sent at the same encryption level, instead of coalescing multiple packets at the same encryption level.
暗号化レベルを上げる順にパケットを合体する（初期、0-RTT、ハンドシェイク、1-RTT; [QUIC-TLS]のセクション4.1.4）、受信機がすべてのパケットを処理できる可能性が高くなります。シングルパス短いヘッダーを持つパケットには長さが含まれていないため、UDPデータグラムに含まれている最後のパケットにのみ可能です。同じ暗号化レベルで複数のパケットを合体するのではなく、同じ暗号化レベルで送信される場合は、エンドポイントに複数のフレームを含める必要があります。
Receivers MAY route based on the information in the first packet contained in a UDP datagram. Senders MUST NOT coalesce QUIC packets with different connection IDs into a single UDP datagram. Receivers SHOULD ignore any subsequent packets with a different Destination Connection ID than the first packet in the datagram.
受信機は、UDPデータグラムに含まれる最初のパケット内の情報に基づいてルーティングすることができる。送信者は、異なる接続IDを持つQUICパケットを単一のUDPデータグラムに接続してはなりません。受信者は、データグラムの最初のパケットとは異なる宛先接続IDを持つ後続のパケットを無視してください。
Every QUIC packet that is coalesced into a single UDP datagram is separate and complete. The receiver of coalesced QUIC packets MUST individually process each QUIC packet and separately acknowledge them, as if they were received as the payload of different UDP datagrams. For example, if decryption fails (because the keys are not available or for any other reason), the receiver MAY either discard or buffer the packet for later processing and MUST attempt to process the remaining packets.
単一のUDPデータグラムに合体しているすべてのQUICパケットは別々かつ完全です。合体QUICパケットの受信機は、各QUICパケットを個別に処理し、それらが異なるUDPデータグラムのペイロードとして受信されたかのようにそれらを別々に認識しなければならない。たとえば、復号化が失敗した場合（キーが利用できない、またはその他の理由ではないため）、受信側は後で処理するためにパケットを破棄またはバッファすることができ、残りのパケットの処理を試みる必要があります。
Retry packets (Section 17.2.5), Version Negotiation packets (Section 17.2.1), and packets with a short header (Section 17.3) do not contain a Length field and so cannot be followed by other packets in the same UDP datagram. Note also that there is no situation where a Retry or Version Negotiation packet is coalesced with another packet.
再試行パケット（第17.2.5項）、バージョンネゴシエーションパケット（17.2.1項）、および短いヘッダーを備えたパケット（セクション17.3）には長さフィールドが含まれておらず、同じUDPデータグラム内の他のパケットが続くことはできません。リトライまたはバージョンネゴシエーションパケットが別のパケットと合体する状況がないことにも注意してください。
The packet number is an integer in the range 0 to 2^62-1. This number is used in determining the cryptographic nonce for packet protection. Each endpoint maintains a separate packet number for sending and receiving.
パケット番号は、0 ~ 2^62-1の範囲の整数です。この数は、パケット保護のための暗号化ノンスの決定に使用されます。各エンドポイントは、送受信のための別々のパケット番号を維持します。
Packet numbers are limited to this range because they need to be representable in whole in the Largest Acknowledged field of an ACK frame (Section 19.3). When present in a long or short header, however, packet numbers are reduced and encoded in 1 to 4 bytes; see Section 17.1.
パケット番号は、ACKフレームの最大の確認されたフィールドで全体として表現可能である必要があるため、この範囲に制限されています（セクション19.3）。しかしながら、長いまたは短いヘッダに存在する場合、パケット番号は減少し、1から4バイトで符号化される。セクション17.1を参照してください。
Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) packets do not include a packet number.
バージョンネゴシエーション（第17.2.1項）および再試行（17.2.5項）パケットはパケット番号を含まない。
Packet numbers are divided into three spaces in QUIC:
パケット番号はQUICの3つのスペースに分割されています。
Initial space: All Initial packets (Section 17.2.2) are in this space.
初期スペース：すべての初期パケット（セクション17.2.2）はこのスペースにあります。
Handshake space: All Handshake packets (Section 17.2.4) are in this space.
ハンドシェイクスペース：すべてのハンドシェイクパケット（17.2.4項）はこのスペースにあります。
Application data space: All 0-RTT (Section 17.2.3) and 1-RTT (Section 17.3.1) packets are in this space.
アプリケーションデータスペース：すべて0-RTT（セクション17.2.3）および1-RTT（セクション17.3.1）パケットはこのスペースにあります。
As described in [QUIC-TLS], each packet type uses different protection keys.
[QUIC-TLS]で説明されているように、各パケットタイプは異なる保護キーを使用します。
Conceptually, a packet number space is the context in which a packet can be processed and acknowledged. Initial packets can only be sent with Initial packet protection keys and acknowledged in packets that are also Initial packets. Similarly, Handshake packets are sent at the Handshake encryption level and can only be acknowledged in Handshake packets.
概念的には、パケット番号スペースは、パケットを処理して確認することができるコンテキストです。初期パケットは、初期パケット保護キーを使用してのみ送信され、初期パケットでもあるパケットで確認できます。同様に、ハンドシェイクパケットはハンドシェイクの暗号化レベルで送信され、ハンドシェイクパケットでのみ確認できます。
This enforces cryptographic separation between the data sent in the different packet number spaces. Packet numbers in each space start at packet number 0. Subsequent packets sent in the same packet number space MUST increase the packet number by at least one.
これにより、異なるパケット番号スペースで送信されたデータ間の暗号分離が強制されます。各スペース内のパケット番号はパケット番号0で始まります。同じパケット番号スペースで送信された後続のパケットは、パケット番号を少なくとも1つだけ増やす必要があります。
0-RTT and 1-RTT data exist in the same packet number space to make loss recovery algorithms easier to implement between the two packet types.
2つのパケットタイプ間で損失回復アルゴリズムを実装しやすくするために、0-RTTデータと1-RTTデータが同じパケット番号スペースに存在します。
A QUIC endpoint MUST NOT reuse a packet number within the same packet number space in one connection. If the packet number for sending reaches 2^62-1, the sender MUST close the connection without sending a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send a Stateless Reset (Section 10.3) in response to further packets that it receives.
QUICエンドポイントは、1つの接続で同じパケット番号スペース内でパケット番号を再利用してはなりません。送信のパケット番号が2^62-1に達すると、送信側はCONNECTION_CLOSEフレームまたはそれ以上のパケットを送信せずに接続を閉じる必要があります。エンドポイントは、それが受信したさらなるパケットに応答してステートレスリセット（セクション10.3）を送信することがあります。
A receiver MUST discard a newly unprotected packet unless it is certain that it has not processed another packet with the same packet number from the same packet number space. Duplicate suppression MUST happen after removing packet protection for the reasons described in Section 9.5 of [QUIC-TLS].
受信機は、同じパケット番号スペースから同じパケット番号を持つ別のパケットを処理していないことが確実でない限り、新たに保護されていないパケットを破棄しなければなりません。[QUIC-TLS]のセクション9.5で説明されている理由で、パケット保護を削除した後に、重複抑制が必要です。
Endpoints that track all individual packets for the purposes of detecting duplicates are at risk of accumulating excessive state. The data required for detecting duplicates can be limited by maintaining a minimum packet number below which all packets are immediately dropped. Any minimum needs to account for large variations in round-trip time, which includes the possibility that a peer might probe network paths with much larger round-trip times; see Section 9.
重複を検出する目的で、すべての個々のパケットを追跡するエンドポイントは、過剰な状態を蓄積する危険性があります。重複を検出するために必要なデータは、すべてのパケットがすぐにドロップされる最小パケット番号を維持することによって制限され得る。往復時間の大きなバリエーションを考慮する必要がある最低限の必要性は、ピアがネットワークパスをはるかに大きいラウンドトリップタイムでプローブする可能性を含みます。セクション9を参照してください。
Packet number encoding at a sender and decoding at a receiver are described in Section 17.1.
受信機での送信者および復号化でのパケット番号は、セクション17.1に記載されている。
The payload of QUIC packets, after removing packet protection, consists of a sequence of complete frames, as shown in Figure 11. Version Negotiation, Stateless Reset, and Retry packets do not contain frames.
パケット保護を削除した後、QUICパケットのペイロードは、図11に示すように、一連の完全フレームで構成されています。バージョンネゴシエーション、ステートレスリセット、およびリトライパケットにはフレームが含まれていません。
Packet Payload {
Frame (8..) ...,
}
Figure 11: QUIC Payload
図11：QUICペイロード
The payload of a packet that contains frames MUST contain at least one frame, and MAY contain multiple frames and multiple frame types. An endpoint MUST treat receipt of a packet containing no frames as a connection error of type PROTOCOL_VIOLATION. Frames always fit within a single QUIC packet and cannot span multiple packets.
フレームを含むパケットのペイロードは少なくとも1つのフレームを含み、複数のフレームと複数のフレームタイプを含めることができます。エンドポイントは、PROTOCOL_VIOLATION型の接続エラーとしてフレームを含まないパケットの受信を扱う必要があります。フレームは常に単一のQUICパケット内に収まり、複数のパケットにまたがることはできません。
Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields:
各フレームはフレームタイプから始まり、そのタイプを示し、その後に追加のタイプ依存フィールドが続きます。
Frame {
Frame Type (i),
Type-Dependent Fields (..),
}
Figure 12: Generic Frame Layout
図12：一般的なフレームのレイアウト
Table 3 lists and summarizes information about each frame type that is defined in this specification. A description of this summary is included after the table.
表3は、この仕様で定義されている各フレームタイプに関する情報を示してまとめたものです。この概要の説明は、表の後に含まれています。
+============+======================+===============+======+======+
| Type Value | Frame Type Name | Definition | Pkts | Spec |
+============+======================+===============+======+======+
| 0x00 | PADDING | Section 19.1 | IH01 | NP |
+------------+----------------------+---------------+------+------+
| 0x01 | PING | Section 19.2 | IH01 | |
+------------+----------------------+---------------+------+------+
| 0x02-0x03 | ACK | Section 19.3 | IH_1 | NC |
+------------+----------------------+---------------+------+------+
| 0x04 | RESET_STREAM | Section 19.4 | __01 | |
+------------+----------------------+---------------+------+------+
| 0x05 | STOP_SENDING | Section 19.5 | __01 | |
+------------+----------------------+---------------+------+------+
| 0x06 | CRYPTO | Section 19.6 | IH_1 | |
+------------+----------------------+---------------+------+------+
| 0x07 | NEW_TOKEN | Section 19.7 | ___1 | |
+------------+----------------------+---------------+------+------+
| 0x08-0x0f | STREAM | Section 19.8 | __01 | F |
+------------+----------------------+---------------+------+------+
| 0x10 | MAX_DATA | Section 19.9 | __01 | |
+------------+----------------------+---------------+------+------+
| 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | |
+------------+----------------------+---------------+------+------+
| 0x12-0x13 | MAX_STREAMS | Section 19.11 | __01 | |
+------------+----------------------+---------------+------+------+
| 0x14 | DATA_BLOCKED | Section 19.12 | __01 | |
+------------+----------------------+---------------+------+------+
| 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | |
+------------+----------------------+---------------+------+------+
| 0x16-0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | |
+------------+----------------------+---------------+------+------+
| 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P |
+------------+----------------------+---------------+------+------+
| 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | |
+------------+----------------------+---------------+------+------+
| 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P |
+------------+----------------------+---------------+------+------+
| 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P |
+------------+----------------------+---------------+------+------+
| 0x1c-0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N |
+------------+----------------------+---------------+------+------+
| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | |
+------------+----------------------+---------------+------+------+
Table 3: Frame Types
表3：フレームの種類
The format and semantics of each frame type are explained in more detail in Section 19. The remainder of this section provides a summary of important and general information.
各フレームタイプのフォーマットとセマンティクスはセクション19でより詳細に説明されています。このセクションの残りの部分は、重要情報と一般的な情報の概要を示しています。
The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and CONNECTION_CLOSE frames is used to carry other frame-specific flags. For all other frames, the Frame Type field simply identifies the frame.
ACK、STREAM、MAX_STREAMS、STREAMS_BLOCKED、およびCONNECTION_CLOSEフレームのフレームタイプは、他のフレーム固有のフラグを伝送するために使用されます。他のすべてのフレームの場合、フレームタイプフィールドはフレームを単純に識別します。
The "Pkts" column in Table 3 lists the types of packets that each frame type could appear in, indicated by the following characters:
表3の「PKTS」列には、各フレームタイプが表示される可能性があるパケットの種類を次の文字で示しています。
I: Initial (Section 17.2.2)
I：イニシャル（セクション17.2.2）
H: Handshake (Section 17.2.4)
H：Handshake（セクション17.2.4）
0: 0-RTT (Section 17.2.3)
0：0-RTT（セクション17.2.3）
1: 1-RTT (Section 17.3.1)
1：1-RTT（セクション17.3.1）
ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial or Handshake packets.
ih：タイプ0x1cのCONNECTION_CLOSEフレームのみが初期またはハンドシェイクパケットに表示される可能性があります。
For more details about these restrictions, see Section 12.5. Note that all frames can appear in 1-RTT packets. An endpoint MUST treat receipt of a frame in a packet type that is not permitted as a connection error of type PROTOCOL_VIOLATION.
これらの制限の詳細については、12.5項を参照してください。すべてのフレームが1-RTTパケットに表示できることに注意してください。エンドポイントは、Type PROTOCOL_VIOLATIONの接続エラーとして許可されていないパケットタイプ内のフレームの受信を扱う必要があります。
The "Spec" column in Table 3 summarizes any special rules governing the processing or generation of the frame type, as indicated by the following characters:
表3の「SPEC」列は、次の文字で示すように、処理またはフレームタイプの生成を管理する特別な規則をまとめたものです。
N: Packets containing only frames with this marking are not ack-eliciting; see Section 13.2.
N：このマーキングを持つフレームのみを含むパケットはACKエリケーションではありません。13.2節を参照してください。
C: Packets containing only frames with this marking do not count toward bytes in flight for congestion control purposes; see [QUIC-RECOVERY].
C：このマーキングを持つフレームのみを含むパケットは、輻輳制御の目的でフライトでバイトにカウントされません。[QUIC-RECOVERY]を参照してください。
P: Packets containing only frames with this marking can be used to probe new network paths during connection migration; see Section 9.1.
P：このマーキングを持つフレームのみを含むパケットは、接続移行中に新しいネットワークパスをプローブするために使用できます。セクション9.1を参照してください。
F: The contents of frames with this marking are flow controlled; see Section 4.
F：このマーキングを持つフレームの内容はフロー制御されています。セクション4を参照してください。
The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA registry; see Section 22.4.
表3の「PKTS」および「SPEC」列はIANAレジストリの一部を形成しない。22.4節を参照してください。
An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR.
エンドポイントは、Unknown Typeのフレームの受信を FRAME_ENCODING_ERROR 型の接続エラーとして扱う必要があります。
All frames are idempotent in this version of QUIC. That is, a valid frame does not cause undesirable side effects or errors when received more than once.
このバージョンのQUICでは、すべてのフレームがべき等です。 つまり、有効なフレームは、複数回受信されたときに望ましくない副作用やエラーを引き起こしません。
The Frame Type field uses a variable-length integer encoding (see Section 16), with one exception. To ensure simple and efficient implementations of frame parsing, a frame type MUST use the shortest possible encoding. For frame types defined in this document, this means a single-byte encoding, even though it is possible to encode these values as a two-, four-, or eight-byte variable-length integer. For instance, though 0x4001 is a legitimate two-byte encoding for a variable-length integer with a value of 1, PING frames are always encoded as a single byte with the value 0x01. This rule applies to all current and future QUIC frame types. An endpoint MAY treat the receipt of a frame type that uses a longer encoding than necessary as a connection error of type PROTOCOL_VIOLATION.
フレームタイプフィールドは、1つの例外を除いて、可変長整数エンコーディング（セクション16を参照）を使用します。 フレーム解析のシンプルで効率的な実装を確実にするために、フレームタイプは可能な限り短いエンコーディングを使用しなければなりません（MUST）。 このドキュメントで定義されているフレームタイプの場合、これらの値を2バイト、4バイト、または8バイトの可変長整数としてエンコードすることは可能ですが、これは1バイトのエンコードを意味します。 たとえば、0x4001は値1の可変長整数の正当な2バイトエンコーディングですが、PINGフレームは常に値0x01のシングルバイトとしてエンコードされます。 このルールは、現在および将来のすべてのQUICフレームタイプに適用されます。 エンドポイントは、必要以上に長いエンコーディングを使用するフレームタイプの受信を、タイプPROTOCOL_VIOLATIONの接続エラーとして扱うことができます。
Some frames are prohibited in different packet number spaces. The rules here generalize those of TLS, in that frames associated with establishing the connection can usually appear in packets in any packet number space, whereas those associated with transferring data can only appear in the application data packet number space:
いくつかのフレームは異なるパケット番号スペースで禁止されています。ここでの規則は、接続を確立することに関連するフレームが通常、パケット番号スペース内のパケットに表示されることができるため、アプリケーションデータパケット番号スペースにのみ表示できるのに対し、TLSのものが一般的に表示されます。
* PADDING, PING, and CRYPTO frames MAY appear in any packet number space.
* パディング、PING、および暗号フレームは、パケット番号スペースに表示されることがあります。
* CONNECTION_CLOSE frames signaling errors at the QUIC layer (type 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE frames signaling application errors (type 0x1d) MUST only appear in the application data packet number space.
* QUICレイヤー（タイプ0x1c）でエラーを通知するCONNECTION_CLOSEフレームは、任意のパケット番号スペースに表示される場合があります。 アプリケーションエラー（タイプ0x1d）を通知するCONNECTION_CLOSEフレームは、アプリケーションデータパケット番号スペースにのみ表示されなければなりません。
* ACK frames MAY appear in any packet number space but can only acknowledge packets that appeared in that packet number space. However, as noted below, 0-RTT packets cannot contain ACK frames.
* ACKフレームは任意のパケット番号スペースに表示されますが、そのパケット番号スペースに表示されているパケットのみを確認できます。ただし、以下のように、0-RTTパケットにACKフレームを含めることはできません。
* All other frame types MUST only be sent in the application data packet number space.
* 他のすべてのフレームタイプは、アプリケーションデータパケット番号スペースでのみ送信されなければなりません。
Note that it is not possible to send the following frames in 0-RTT packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt of these frames in 0-RTT packets as a connection error of type PROTOCOL_VIOLATION.
ACK、Crypto、HANDSHAKE_DONE、New_Token、PATH_RESPONSE、およびRETIRE_CONNECTION_IDさまざまな理由で、0-RTTパケットに次のフレームを送信することはできません。サーバは、Type PROTOCOL_VIOLATIONの接続エラーとして、0-RTTパケット内のこれらのフレームの受信を扱うことがあります。
A sender sends one or more frames in a QUIC packet; see Section 12.4.
送信者は、1つ以上のフレームをQUICパケットに送信します。12.4項を参照してください。
A sender can minimize per-packet bandwidth and computational costs by including as many frames as possible in each QUIC packet. A sender MAY wait for a short period of time to collect multiple frames before sending a packet that is not maximally packed, to avoid sending out large numbers of small packets. An implementation MAY use knowledge about application sending behavior or heuristics to determine whether and for how long to wait. This waiting period is an implementation decision, and an implementation should be careful to delay conservatively, since any delay is likely to increase application-visible latency.
送信者は、各QUICパケットにおいてできるだけ多くのフレームを含めることによって、パケットごとの帯域幅および計算コストを最小化することができる。送信者は、多数の小さなパケットの送信を避けるために、最大限梱包されていないパケットを送信する前に複数のフレームを収集するために短期間待つことができます。実装は、動作を送信するためのアプリケーションの送信についての知識を使用して、待機するかどうかを判断することができます。この待機期間は実装決定であり、遅延が適用可視レイテンシを増大させる可能性が高いため、実装は遅滞遅延に注意してください。
Stream multiplexing is achieved by interleaving STREAM frames from multiple streams into one or more QUIC packets. A single QUIC packet can include multiple STREAM frames from one or more streams.
ストリーム多重化は、複数のストリームから1つまたは複数のQUICパケットへのストリームフレームをインターリーブすることによって達成される。単一のQUICパケットは、1つまたは複数のストリームから複数のストリームフレームを含むことができる。
One of the benefits of QUIC is avoidance of head-of-line blocking across multiple streams. When a packet loss occurs, only streams with data in that packet are blocked waiting for a retransmission to be received, while other streams can continue making progress. Note that when data from multiple streams is included in a single QUIC packet, loss of that packet blocks all those streams from making progress. Implementations are advised to include as few streams as necessary in outgoing packets without losing transmission efficiency to underfilled packets.
QUICの利点の1つは、複数のストリームにわたるラインブロックの回避です。パケット損失が発生すると、そのパケット内のデータをストリーミングするだけで、再送信が受信されるのを待ってブロックされ、他のストリームは進行を続けることができる。複数のストリームからのデータが単一のQUICパケットに含まれている場合、そのパケットの損失はすべてのストリームを進行からブロックします。実装は、受信パケットに送信効率を低下させることなく、送信パケットで必要な少数のストリームを含むことをお勧めします。
A packet MUST NOT be acknowledged until packet protection has been successfully removed and all frames contained in the packet have been processed. For STREAM frames, this means the data has been enqueued in preparation to be received by the application protocol, but it does not require that data be delivered and consumed.
パケット保護が正常に削除され、パケットに含まれるすべてのフレームが処理されるまで、パケットを確認しないでください。ストリームフレームの場合、これはアプリケーションプロトコルによって受信される準備でデータがエンキューされていることを意味しますが、データを配信して消費する必要はありません。
Once the packet has been fully processed, a receiver acknowledges receipt by sending one or more ACK frames containing the packet number of the received packet.
パケットが完全に処理されると、受信機は受信パケットのパケット番号を含む1つまたは複数のACKフレームを送信することによって受信を確認する。
An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition. For further discussion of how this might be achieved, see Section 21.4.
エンドポイントは、それが状態を検出することができるならば、Pactachの接続エラーとして送信されなかったパケットに対する確認応答の受信を扱うべきです。これがどのように達成され得るかについてのさらなる議論については、21.4項を参照のこと。
Endpoints acknowledge all packets they receive and process. However, only ack-eliciting packets cause an ACK frame to be sent within the maximum ack delay. Packets that are not ack-eliciting are only acknowledged when an ACK frame is sent for other reasons.
エンドポイントは、受信して処理したすべてのパケットを確認します。ただし、ACK誘発パケットのみがACKフレームを最大ACK遅延内に送信させます。ACKエリケーションではないパケットは、ACKフレームが他の理由で送信されたときにのみ認識されます。
When sending a packet for any reason, an endpoint SHOULD attempt to include an ACK frame if one has not been sent recently. Doing so helps with timely loss detection at the peer.
何らかの理由でパケットを送信するとき、最近送信されていない場合は、エンドポイントがACKフレームを含めるようにしてください。そうすることは、ピアでのタイムリーな損失検出を助けます。
In general, frequent feedback from a receiver improves loss and congestion response, but this has to be balanced against excessive load generated by a receiver that sends an ACK frame in response to every ack-eliciting packet. The guidance offered below seeks to strike this balance.
一般に、受信機からの頻繁なフィードバックは損失および輻輳応答を改善するが、これはACK誘発パケットごとにACKフレームを送る受信機によって発生する過度の負荷とバランスをとる必要がある。以下に提供されるガイダンスはこのバランスを打つことを求めています。
Every packet SHOULD be acknowledged at least once, and ack-eliciting packets MUST be acknowledged at least once within the maximum delay an endpoint communicated using the max_ack_delay transport parameter; see Section 18.2. max_ack_delay declares an explicit contract: an endpoint promises to never intentionally delay acknowledgments of an ack-eliciting packet by more than the indicated value. If it does, any excess accrues to the RTT estimate and could result in spurious or delayed retransmissions from the peer. A sender uses the receiver's max_ack_delay value in determining timeouts for timer-based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY].
すべてのパケットは少なくとも1回確認応答され、ACK EILICTINGパケットはMAX_ACK_DELAYトランスポートパラメータを使用してエンドポイントが通信しているエンドポイントが最大遅延に1回承認されなければなりません。18.2節を参照してください。MAX_ACK_DELAYは、明示的な契約を宣言します。エンドポイントは、指示された値を超えてACK誘発パケットの確認応答を意図的に遅らせることを決して遅らせないことを約束します。もしそうであれば、RTT推定値を推定することができ、ピアからのスプリアスまたは遅延の再送信をもたらす可能性がある。送信者は、[QUIC-Recovery]のセクション6.2のセクション6.2に詳述されているように、タイマーベースの再送信のタイムアウトを決定する際の受信機のMAX_ACK_DELAY値を使用します。
An endpoint MUST acknowledge all ack-eliciting Initial and Handshake packets immediately and all ack-eliciting 0-RTT and 1-RTT packets within its advertised max_ack_delay, with the following exception. Prior to handshake confirmation, an endpoint might not have packet protection keys for decrypting Handshake, 0-RTT, or 1-RTT packets when they are received. It might therefore buffer them and acknowledge them when the requisite keys become available.
エンドポイントは、すぐにACK誘発初期パケットとハンドシェイクパケットを承認する必要があります。これは、次の例外を除いて、アドバタイズされたmax_ack_delay内のすべてのACK誘発0-RTTパケットと1-RTTパケットと1-RTTパケットを承認する必要があります。ハンドシェイクの確認の前に、エンドポイントは、受信したときにハンドシェイク、0-RTT、または1-RTTパケットを復号化するためのパケット保護キーを持たない可能性があります。したがって、必要なキーが利用可能になったときにそれらを緩めてそれらを確認することができます。
Since packets containing only ACK frames are not congestion controlled, an endpoint MUST NOT send more than one such packet in response to receiving an ack-eliciting packet.
ACKフレームのみを含むパケットは輻輳制御されていないため、ACK誘発パケットの受信に応答してエンドポイントがそのようなパケットを送信してはなりません。
An endpoint MUST NOT send a non-ack-eliciting packet in response to a non-ack-eliciting packet, even if there are packet gaps that precede the received packet. This avoids an infinite feedback loop of acknowledgments, which could prevent the connection from ever becoming idle. Non-ack-eliciting packets are eventually acknowledged when the endpoint sends an ACK frame in response to other events.
受信したパケットの前にパケットギャップがある場合でも、エンドポイントは、非ACK誘発パケットに応答して非ACK誘発パケットを送信してはなりません。これにより、承認の無限フィードバックループが回避され、接続がアイドル状態になるのを防ぐことができます。Endpointが他のイベントに応答してACKフレームを送信すると、非ACK ELICITINGパケットが最終的に認識されます。
An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgments are included in packets with ack-eliciting frames. An endpoint SHOULD send an ACK frame with other frames when there are new ack-eliciting packets to acknowledge. When only non-ack-eliciting packets need to be acknowledged, an endpoint MAY choose not to send an ACK frame with outgoing frames until an ack-eliciting packet has been received.
ACKフレームのみを送信しているエンドポイントは、それらの確認応答がACK誘発フレームを持つパケットに含まれていない限り、そのピアからの確認応答を受け取りません。エンドポイントは、確認するための新しいACK誘発パケットがあるときに、ACKフレームを他のフレームと送信する必要があります。非ACKエリチョンパケットのみを確認する必要がある場合、エンドポイントは、ACK誘発パケットが受信されるまでACKフレームを送信フレームで送信しないことを選択することができる。
An endpoint that is only sending non-ack-eliciting packets might choose to occasionally add an ack-eliciting frame to those packets to ensure that it receives an acknowledgment; see Section 13.2.4. In that case, an endpoint MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgments.
非ACK誘発パケットを送信しているエンドポイントは、確認応答を確認するために、それらのパケットにACK誘発フレームを追加することを選択できます。13.2.4項を参照してください。その場合、エンドポイントは、肯定応答の無限のフィードバックループを回避するために、そうでなければ非ACK誘発されているであろうすべてのパケットにACK誘発フレームを送信してはなりません。
In order to assist loss detection at the sender, an endpoint SHOULD generate and send an ACK frame without delay when it receives an ack-eliciting packet either:
送信者での損失検出を支援するために、エンドポイントはACK誘発パケットを受信したときに遅延なしにACKフレームを生成して送信する必要があります。
* when the received packet has a packet number less than another ack-eliciting packet that has been received, or
* 受信したパケットに受信された別のACK誘発パケットよりも小さいパケット番号がある場合
* when the packet has a packet number larger than the highest-numbered ack-eliciting packet that has been received and there are missing packets between that packet and this packet.
* パケットが受信された最大番号付きACK誘発パケットよりも大きいパケット番号を有する場合、そのパケットとこのパケットとの間にパケットがない。
Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events.
同様に、IPヘッダー内のECN輻輳経験豊富なCodePointでマークされたパケットは、ピアの応答時間を輻輳イベントに短縮するためにすぐに確認されるべきです。
The algorithms in [QUIC-RECOVERY] are expected to be resilient to receivers that do not follow the guidance offered above. However, an implementation should only deviate from these requirements after careful consideration of the performance implications of a change, for connections made by the endpoint and for other users of the network.
[QUIC-RECOVERY]のアルゴリズムは、上記のガイダンスに従わない受信機に弾力があると予想されます。ただし、エンドポイントによって行われた接続のための、およびネットワークの他のユーザーのための接続の性能の影響を慎重に考慮した後に、実装はこれらの要件からのみ逸脱する必要があります。
A receiver determines how frequently to send acknowledgments in response to ack-eliciting packets. This determination involves a trade-off.
受信者は、ACK誘発パケットに応答して確認応答を送信する頻度を決定する。この決定はトレードオフを含みます。
Endpoints rely on timely acknowledgment to detect loss; see Section 6 of [QUIC-RECOVERY]. Window-based congestion controllers, such as the one described in Section 7 of [QUIC-RECOVERY], rely on acknowledgments to manage their congestion window. In both cases, delaying acknowledgments can adversely affect performance.
エンドポイントは、損失を検出するためにタイムリーに確認応答に依存しています。[QUIC-Recovery]のセクション6を参照してください。[QUIC-RECOVERY]のセクション7のようなウィンドウベースの輻輳コントローラは、輻輳ウィンドウを管理するための確認応答に依存しています。どちらの場合も、承認を遅らせることはパフォーマンスに悪影響を及ぼす可能性があります。
On the other hand, reducing the frequency of packets that carry only acknowledgments reduces packet transmission and processing cost at both endpoints. It can improve connection throughput on severely asymmetric links and reduce the volume of acknowledgment traffic using return path capacity; see Section 3 of [RFC3449].
一方、承認のみを運ぶパケットの周波数を減らすと、両方のエンドポイントでのパケットの伝送と処理コストが削減されます。それは厳しく非対称なリンクで接続スループットを向上させ、戻りパス容量を使用して確認応答トラフィックの量を減らすことができます。[RFC3449]のセクション3を参照してください。
A receiver SHOULD send an ACK frame after receiving at least two ack-eliciting packets. This recommendation is general in nature and consistent with recommendations for TCP endpoint behavior [RFC5681]. Knowledge of network conditions, knowledge of the peer's congestion controller, or further research and experimentation might suggest alternative acknowledgment strategies with better performance characteristics.
受信機は、少なくとも2つのACK誘発パケットを受信した後にACKフレームを送信する必要があります。この推奨事項は本質的に一般的であり、TCPエンドポイントの動作に関する推奨事項と一致しています[RFC5681]。ネットワーク条件の知識、ピアの輻輳コントローラの知識、またはさらなる研究および実験は、より良い性能特性を有する代替の確認応答戦略を示唆している可能性があります。
A receiver MAY process multiple available packets before determining whether to send an ACK frame in response.
受信機は、応答においてACKフレームを送信するかどうかを判断する前に、複数の利用可能なパケットを処理することができる。
When an ACK frame is sent, one or more ranges of acknowledged packets are included. Including acknowledgments for older packets reduces the chance of spurious retransmissions caused by losing previously sent ACK frames, at the cost of larger ACK frames.
ACKフレームが送信されると、承認されたパケットの1つ以上の範囲が含まれます。古いパケットの承認を含むことは、以前に送信されたACKフレームを失うことによって引き起こされるスプリアスの再送信の可能性をより大きなACKフレームのコストで減少させる。
ACK frames SHOULD always acknowledge the most recently received packets, and the more out of order the packets are, the more important it is to send an updated ACK frame quickly, to prevent the peer from declaring a packet as lost and spuriously retransmitting the frames it contains. An ACK frame is expected to fit within a single QUIC packet. If it does not, then older ranges (those with the smallest packet numbers) are omitted.
ACKフレームは常に最後に受信したパケットを承認する必要があります。パケットが故障しているのは、パケットが紛失し、誤ったフレームを再送信するのを防ぐために、更新されたACKフレームをすばやく送信することが重要です。含まれています。ACKフレームは、単一のQUICパケット内に収まると予想されます。そうでなければ、古い範囲（最小のパケット番号のもの）は省略されます。
A receiver limits the number of ACK Ranges (Section 19.3.1) it remembers and sends in ACK frames, both to limit the size of ACK frames and to avoid resource exhaustion. After receiving acknowledgments for an ACK frame, the receiver SHOULD stop tracking those acknowledged ACK Ranges. Senders can expect acknowledgments for most packets, but QUIC does not guarantee receipt of an acknowledgment for every packet that the receiver processes.
受信者はACK範囲の数を制限し（19.3.1節）ACKフレームで送信し、ACKフレームのサイズを制限し、リソースの枯渇を回避するために、ACKフレームで送信します。ACKフレームに対して確認応答を受け取った後、受信機はそれらの確認されたACK範囲を追跡するのを停止する必要があります。送信者はほとんどのパケットの承認を期待できますが、QUICは受信者がプロセスするすべてのパケットに対する確認応答の受信を保証するものではありません。
It is possible that retaining many ACK Ranges could cause an ACK frame to become too large. A receiver can discard unacknowledged ACK Ranges to limit ACK frame size, at the cost of increased retransmissions from the sender. This is necessary if an ACK frame would be too large to fit in a packet. Receivers MAY also limit ACK frame size further to preserve space for other frames or to limit the capacity that acknowledgments consume.
多くのACK範囲を保持すると、ACKフレームが大きくなりすぎる可能性があります。受信機は、送信者からの再送信のために、ACKフレームサイズを制限するために未確認のACK範囲を破棄することができる。これは、ACKフレームがパケットに収まるには大きすぎる場合に必要です。受信者はまた、ACKフレームサイズをさらに制限して他のフレームのスペースを保持するか、確認応答が消費される容量を制限することができる。
A receiver MUST retain an ACK Range unless it can ensure that it will not subsequently accept packets with numbers in that range. Maintaining a minimum packet number that increases as ranges are discarded is one way to achieve this with minimal state.
それが続いてその範囲内の数字を持つパケットを受け入れないようにしない限り、受信機はACK範囲を保持しなければなりません。範囲が廃棄されるにつれて増加する最小パケット番号を維持することは、最小限の状態でこれを達成する1つの方法です。
Receivers can discard all ACK Ranges, but they MUST retain the largest packet number that has been successfully processed, as that is used to recover packet numbers from subsequent packets; see Section 17.1.
受信者はすべてのACK範囲を破棄することができますが、後続のパケットからパケット番号を回復するために使用されたのと同じように、最大のパケット番号を保持する必要があります。セクション17.1を参照してください。
A receiver SHOULD include an ACK Range containing the largest received packet number in every ACK frame. The Largest Acknowledged field is used in ECN validation at a sender, and including a lower value than what was included in a previous ACK frame could cause ECN to be unnecessarily disabled; see Section 13.4.2.
受信機は、すべてのACKフレーム内で最大の受信パケット番号を含むACK範囲を含むべきです。最大の確認されたフィールドは、送信者のECN検証で使用され、前のACKフレームに含まれていたものより低い値を含めることは、ECNを不必要に無効にする可能性があります。13.4.2項を参照してください。
Section 13.2.4 describes an exemplary approach for determining what packets to acknowledge in each ACK frame. Though the goal of this algorithm is to generate an acknowledgment for every packet that is processed, it is still possible for acknowledgments to be lost.
セクション13.2.4は、各ACKフレームにおいてどのパケットを承認するかを決定するための例示的なアプローチを説明する。このアルゴリズムの目的は、処理されるすべてのパケットに対して確認応答を生成することですが、確認応答が失われる可能性があります。
When a packet containing an ACK frame is sent, the Largest Acknowledged field in that frame can be saved. When a packet containing an ACK frame is acknowledged, the receiver can stop acknowledging packets less than or equal to the Largest Acknowledged field in the sent ACK frame.
ACKフレームを含むパケットが送信されると、そのフレーム内の最大の確認フィールドを保存できます。ACKフレームを含むパケットが確認された場合、受信機は、送信されたACKフレーム内の最大の確認されたフィールド以下のパケットを停止するのを停止することができる。
A receiver that sends only non-ack-eliciting packets, such as ACK frames, might not receive an acknowledgment for a long period of time. This could cause the receiver to maintain state for a large number of ACK frames for a long period of time, and ACK frames it sends could be unnecessarily large. In such a case, a receiver could send a PING or other small ack-eliciting frame occasionally, such as once per round trip, to elicit an ACK from the peer.
ACKフレームなどの非ACK誘発パケットのみを送信する受信機は、長期間にわたって確認応答を受信しない可能性があります。これにより、受信側に長期間にわたって多数のACKフレームの状態を維持させる可能性があり、それが送信するACKフレームは不必要に大きくなる可能性があります。そのような場合、受信機は、ピアからACKを引き出すために、往復のようにPINまたは他の小さなACK誘発フレームを時折往復することがある。
In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT of reordering. In cases with ACK frame loss and reordering, this approach does not guarantee that every acknowledgment is seen by the sender before it is no longer included in the ACK frame. Packets could be received out of order, and all subsequent ACK frames containing them could be lost. In this case, the loss recovery algorithm could cause spurious retransmissions, but the sender will continue making forward progress.
ACKフレームの損失なしの場合、このアルゴリズムは最低1 RTTの並べ替えを可能にします。ACKフレームの損失と並べ替えの場合、このアプローチは、ACKフレームに含まれなくなった前に、すべての確認応答が送信者によって見られることを保証しません。パケットを順不同で受信することができ、それらを含む後続のACKフレームはすべて失われる可能性があります。この場合、損失回復アルゴリズムはスプリアスの再送信を引き起こす可能性がありますが、送信者は将来の進捗状況を継続します。
An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the time an acknowledgment is sent. The endpoint encodes this acknowledgment delay in the ACK Delay field of an ACK frame; see Section 19.3. This allows the receiver of the ACK frame to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed.
エンドポイントは、最大のパケット番号を持つパケットが受信され、確認応答が送信される時間の間に意図的に導入された遅延を測定します。エンドポイントは、ACKフレームのACK遅延フィールドのこの確認応答遅延を符号化します。19.3節を参照してください。これにより、ACKフレームの受信機は任意の意図的な遅延に対して調整することができ、承認が遅れると経路RTTの見積もりを得ることが重要である。
A packet might be held in the OS kernel or elsewhere on the host before being processed. An endpoint MUST NOT include delays that it does not control when populating the ACK Delay field in an ACK frame. However, endpoints SHOULD include buffering delays caused by unavailability of decryption keys, since these delays can be large and are likely to be non-repeating.
処理される前に、パケットはOSカーネルまたはホスト上の他の場所に保持される可能性があります。エンドポイントには、ACKフレーム内のACK遅延フィールドを入力するときに制御しない遅延を含めてはなりません。ただし、エンドポイントには、復号化キーの使用不可能性によって引き起こされるバッファリング遅延を含める必要があります。これらの遅延は大きく、非繰り返しがある可能性があります。
When the measured acknowledgment delay is larger than its max_ack_delay, an endpoint SHOULD report the measured delay. This information is especially useful during the handshake when delays might be large; see Section 13.2.1.
測定された確認応答遅延がそのMAX_ACK_DELAYより大きい場合、エンドポイントは測定された遅延を報告する必要があります。この情報は、遅延が大きくなる可能性がある場合、ハンドシェイク中に特に便利です。13.2.1項を参照してください。
ACK frames MUST only be carried in a packet that has the same packet number space as the packet being acknowledged; see Section 12.1. For instance, packets that are protected with 1-RTT keys MUST be acknowledged in packets that are also protected with 1-RTT keys.
ACKフレームは、承認されているパケットと同じパケット番号スペースを持つパケットでのみ実行する必要があります。12.1項を参照してください。たとえば、1-RTTキーで保護されているパケットは、1-RTTキーで保護されているパケットで確認応答する必要があります。
Packets that a client sends with 0-RTT packet protection MUST be acknowledged by the server in packets protected by 1-RTT keys. This can mean that the client is unable to use these acknowledgments if the server cryptographic handshake messages are delayed or lost. Note that the same limitation applies to other data sent by the server protected by the 1-RTT keys.
クライアントが0-RTTパケット保護で送信するパケットは、1-RTTキーによって保護されているパケット内のサーバーによって確認されなければなりません。これは、サーバーの暗号化ハンドシェイクメッセージが遅延または失われている場合、クライアントがこれらの確認応答を使用できないことを意味します。同じ制限は、1 RTTキーによって保護されているサーバーによって送信された他のデータにも適用されます。
Packets containing PADDING frames are considered to be in flight for congestion control purposes [QUIC-RECOVERY]. Packets containing only PADDING frames therefore consume congestion window but do not generate acknowledgments that will open the congestion window. To avoid a deadlock, a sender SHOULD ensure that other frames are sent periodically in addition to PADDING frames to elicit acknowledgments from the receiver.
パディングフレームを含むパケットは、輻輳制御の目的で飛行中のと考えられています[QUIC-Recovery]。したがって、パディングフレームのみを含むパケットは輻輳ウィンドウを消費しますが、輻輳ウィンドウを開く謝辞を生成しません。デッドロックを回避するために、送信者は受信者からの承認を誘発するためにパディングフレームに加えて、他のフレームが定期的に送信されることを保証するべきである。
QUIC packets that are determined to be lost are not retransmitted whole. The same applies to the frames that are contained within lost packets. Instead, the information that might be carried in frames is sent again in new frames as needed.
失われていると判断されたQUICパケットは全体の全体ではありません。同じことが、紛失したパケット内に含まれるフレームにも当てはまります。代わりに、必要に応じてフレーム内で持ち運ばれる可能性がある情報が新しいフレームで再度送信されます。
New frames and packets are used to carry information that is determined to have been lost. In general, information is sent again when a packet containing that information is determined to be lost, and sending ceases when a packet containing that information is acknowledged.
新しいフレームとパケットは、失われたと判断された情報を運ぶために使用されます。一般に、その情報を含むパケットが失われると決定されたときに情報が送信され、その情報を含むパケットが確認されたときに停止する。
* Data sent in CRYPTO frames is retransmitted according to the rules in [QUIC-RECOVERY], until all data has been acknowledged. Data in CRYPTO frames for Initial and Handshake packets is discarded when keys for the corresponding packet number space are discarded.
* Cryptoフレームで送信されたデータは、すべてのデータが確認されるまで、[QUIC-Recovery]の規則に従って再送信されます。初期パケットおよびハンドシェイクパケット用の暗号フレーム内のデータは、対応するパケット番号スペースのキーが破棄されると破棄されます。
* Application data sent in STREAM frames is retransmitted in new STREAM frames unless the endpoint has sent a RESET_STREAM for that stream. Once an endpoint sends a RESET_STREAM frame, no further STREAM frames are needed.
* ストリームフレームで送信されたアプリケーションデータは、エンドポイントがそのストリームのRESET_STREMを送信していない限り、新しいストリームフレームで再送信されます。エンドポイントがRESET_STREAMフレームを送信すると、それ以上のストリームフレームは必要ありません。
* ACK frames carry the most recent set of acknowledgments and the acknowledgment delay from the largest acknowledged packet, as described in Section 13.2.1. Delaying the transmission of packets containing ACK frames or resending old ACK frames can cause the peer to generate an inflated RTT sample or unnecessarily disable ECN.
* ACKフレームは、セクション13.2.1で説明されているように、最も最新の確認応答と最大の確認されたパケットからの確認応答遅延を担います。ACKフレームを含むパケットの送信を遅らせるか、または古いACKフレームを再送信すると、ピアに膨張したRTTサンプルを生成したり、不必要にECNを無効にしたりする可能性があります。
* Cancellation of stream transmission, as carried in a RESET_STREAM frame, is sent until acknowledged or until all stream data is acknowledged by the peer (that is, either the "Reset Recvd" or "Data Recvd" state is reached on the sending part of the stream). The content of a RESET_STREAM frame MUST NOT change when it is sent again.
* RESET_STREAMフレームで運ばれるように、ストリーム送信のキャンセルは、確認されるまで、またはすべてのストリームデータがピアによって確認されるまで（つまり、「リセットRECVD」または「Data Recvd」の状態のいずれかが送信側に到達するまで送信される。ストリーム）。RESET_STREAMフレームの内容は、再度送信されたときに変更しないでください。
* Similarly, a request to cancel stream transmission, as encoded in a STOP_SENDING frame, is sent until the receiving part of the stream enters either a "Data Recvd" or "Reset Recvd" state; see Section 3.5.
* 同様に、STOP_SENDINGフレームでエンコードされたストリーム送信をキャンセルする要求は、ストリームの受信部分が「Data Recvd」または「RESET RECVD」状態のいずれかに入るまで送信される。セクション3.5を参照してください。
* Connection close signals, including packets that contain CONNECTION_CLOSE frames, are not sent again when packet loss is detected. Resending these signals is described in Section 10.
* CONNECTION_CLOSEフレームを含むパケットを含む接続閉じる信号は、パケット損失が検出されたときに再び送信されません。これらの信号を再送信することは、セクション10で説明されている。
* The current connection maximum data is sent in MAX_DATA frames. An updated value is sent in a MAX_DATA frame if the packet containing the most recently sent MAX_DATA frame is declared lost or when the endpoint decides to update the limit. Care is necessary to avoid sending this frame too often, as the limit can increase frequently and cause an unnecessarily large number of MAX_DATA frames to be sent; see Section 4.2.
* 現在の接続最大データはMAX_DATAフレームで送信されます。最後に送信されたMAX_DATAフレームを含むパケットが失われた場合、またはエンドポイントが制限を更新することを決定した場合、更新された値がMAX_DATAフレームで送信されます。限界が頻繁に増加し、不必要に多数のMAX_DATAフレームを送信する可能性があるため、このフレームを送信しないように注意が必要です。セクション4.2を参照してください。
* The current maximum stream data offset is sent in MAX_STREAM_DATA frames. Like MAX_DATA, an updated value is sent when the packet containing the most recent MAX_STREAM_DATA frame for a stream is lost or when the limit is updated, with care taken to prevent the frame from being sent too often. An endpoint SHOULD stop sending MAX_STREAM_DATA frames when the receiving part of the stream enters a "Size Known" or "Reset Recvd" state.
* 現在の最大ストリームデータオフセットはMAX_STREAM_DATAフレームで送信されます。MAX_DATAと同様に、ストリームの最新のMAX_STREAM_DATAフレームを含むパケットが失われたとき、または制限が更新されたとき、フレームが送信されないように慎重にされた場合には、更新された値が送信されます。ストリームの受信部分が「サイズ既知」または「RESET RECVD」状態に入ると、エンドポイントはMAX_STREAM_DATAフレームの送信を停止する必要があります。
* The limit on streams of a given type is sent in MAX_STREAMS frames. Like MAX_DATA, an updated value is sent when a packet containing the most recent MAX_STREAMS for a stream type frame is declared lost or when the limit is updated, with care taken to prevent the frame from being sent too often.
* 特定の型のストリームの制限はMAX_STREAMSフレームで送信されます。MAX_DATAと同様に、ストリーム型フレームの最新のMAX_STREAMSを含むパケットが紛失した場合、または制限が更新されたとき、フレームが送信されるのを防ぎ、フレームが送信されるのを防ぎます。
* Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection scope, STREAM_DATA_BLOCKED frames have stream scope, and STREAMS_BLOCKED frames are scoped to a specific stream type. A new frame is sent if a packet containing the most recent frame for a scope is lost, but only while the endpoint is blocked on the corresponding limit. These frames always include the limit that is causing blocking at the time that they are transmitted.
* ブロックされた信号は、data_blocked、stream_data_blocked、およびSTREAMS_BLOCKEDフレームで搬送されます。DATA_BLOCKEDフレームに接続スコープ、STREAM_DATA_BLOCKEDフレームはストリームスコープを持ち、STREAMS_BLOCKEDフレームは特定のストリームタイプにスコープされます。スコープの最新のフレームを含むパケットが失われた場合は、新しいフレームが送信されますが、エンドポイントが対応する制限でブロックされている間だけ送信されます。これらのフレームは常にそれらが送信される時点でブロッキングを引き起こしている制限を含みます。
* A liveness or path validation check using PATH_CHALLENGE frames is sent periodically until a matching PATH_RESPONSE frame is received or until there is no remaining need for liveness or path validation checking. PATH_CHALLENGE frames include a different payload each time they are sent.
* PATH_CHALLENGEフレンジを使用したLIVISIVESまたはPATH検証チェックは、一致するPATH_RESPONSEフレームが受信されるまで、またはLightsまたはPath検証チェックの必要性が残ってくるまで定期的に送信されます。PATH_CHALLENGEフレームには、送信されるたびに異なるペイロードが含まれます。
* Responses to path validation using PATH_RESPONSE frames are sent just once. The peer is expected to send more PATH_CHALLENGE frames as necessary to evoke additional PATH_RESPONSE frames.
* PATH_RESPONSEフレームを使用したパス検証に対する応答は、一度だけ送信されます。追加のPATH_RESPONSEフレームを呼び出すために、ピアは必要に応じてより多くのPATH_CHALLENGEフレームを送信すると予想されます。
* New connection IDs are sent in NEW_CONNECTION_ID frames and retransmitted if the packet containing them is lost. Retransmissions of this frame carry the same sequence number value. Likewise, retired connection IDs are sent in RETIRE_CONNECTION_ID frames and retransmitted if the packet containing them is lost.
* 新しい接続IDはNEW_CONNECTION_IDフレームで送信され、それらを含むパケットが失われた場合に再送信されます。このフレームの再送信は同じシーケンス番号値を搬送します。同様に、引退した接続IDはRETIRE_CONNECTION_IDフレームで送信され、それらを含むパケットが失われた場合に再送信されます。
* NEW_TOKEN frames are retransmitted if the packet containing them is lost. No special support is made for detecting reordered and duplicated NEW_TOKEN frames other than a direct comparison of the frame contents.
* それらを含むパケットが失われた場合、NEW_TOKENフレームは再送信されます。フレーム内容の直接比較以外の並べ替えられた新しいNEW_TOKENフレームを検出するための特別なサポートはできません。
* PING and PADDING frames contain no information, so lost PING or PADDING frames do not require repair.
* PINGフレームとパディングフレームには情報が含まれていないため、Lost Pingフレームやパディングフレームは修復を必要としません。
* The HANDSHAKE_DONE frame MUST be retransmitted until it is acknowledged.
* HANDSHAKE_DONEフレームは、確認されるまで再送信する必要があります。
Endpoints SHOULD prioritize retransmission of data over sending new data, unless priorities specified by the application indicate otherwise; see Section 2.3.
エンドポイントは、アプリケーションによって指定された優先順位がそれ以外の場合を示していない限り、エンドポイントは新しいデータを送信する上でデータの再送信を優先する必要があります。セクション2.3を参照してください。
Even though a sender is encouraged to assemble frames containing up-to-date information every time it sends a packet, it is not forbidden to retransmit copies of frames from lost packets. A sender that retransmits copies of frames needs to handle decreases in available payload size due to changes in packet number length, connection ID length, and path MTU. A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data value than one found in an older packet.
送信者がパケットを送信するたびに最新の情報を含むフレームを組み立てることをお勧めしていても、失われたパケットからフレームのコピーを再送信することは禁止されていません。フレームのコピーを再送信する送信者は、パケット番号の長さ、接続IDの長さ、およびパスMTUの変化により、使用可能なペイロードサイズの到達を処理する必要がある送信者。受信機は、古いパケットに見られるものよりも小さい最大データ値を搬送するMAX_DATAフレームのような古いフレームを含むパケットを受け入れる必要があります。
A sender SHOULD avoid retransmitting information from packets once they are acknowledged. This includes packets that are acknowledged after being declared lost, which can happen in the presence of network reordering. Doing so requires senders to retain information about packets after they are declared lost. A sender can discard this information after a period of time elapses that adequately allows for reordering, such as a PTO (Section 6.2 of [QUIC-RECOVERY]), or based on other events, such as reaching a memory limit.
送信者は、確認されたら、パケットから情報を再送信するのを避けるべきです。これには、紛失した後に認められたパケットが含まれています。これはネットワークの並べ替えの存在下で発生する可能性があります。そうすることは、送信者が宣言された後にパケットに関する情報を保持することを要求します。送信者は、PTO（QUIC回復のセクション6.2）などの並べ替えを適切に許可する、またはメモリ制限に到達するなどの他のイベントに基づいて、この情報を破棄することができます。
Upon detecting losses, a sender MUST take appropriate congestion control action. The details of loss detection and congestion control are described in [QUIC-RECOVERY].
損失を検出すると、送信者は適切な輻輳制御動作を取らなければなりません。損失検出および輻輳制御の詳細は[QUIC回復]で説明されている。
QUIC endpoints can use ECN [RFC3168] to detect and respond to network congestion. ECN allows an endpoint to set an ECN-Capable Transport (ECT) codepoint in the ECN field of an IP packet. A network node can then indicate congestion by setting the ECN-CE codepoint in the ECN field instead of dropping the packet [RFC8087]. Endpoints react to reported congestion by reducing their sending rate in response, as described in [QUIC-RECOVERY].
QUICのエンドポイントはECN [RFC3168]を使用してネットワークの輻輳を検出して応答できます。ECNにより、エンドポイントがIPパケットのECNフィールドにECN対応トランスポート（ECT）コードポイントを設定できます。その後、ネットワークノードは、パケットをドロップするのではなく、ECNフィールドにECN-CEコードポイントを設定することによって輻輳を示すことができます[RFC8087]。「QUIC回復」に記載されているように、エンドポイントは、応答の送信速度を減らすことによって報告された輻輳に反応します。
To enable ECN, a sending QUIC endpoint first determines whether a path supports ECN marking and whether the peer reports the ECN values in received IP headers; see Section 13.4.2.
ECNを有効にするために、送信QUICエンドポイントは最初に、パスがECNマーキングをサポートしているかどうか、およびピアが受信したIPヘッダー内のECN値を報告するかどうかを決定します。13.4.2項を参照してください。
The use of ECN requires the receiving endpoint to read the ECN field from an IP packet, which is not possible on all platforms. If an endpoint does not implement ECN support or does not have access to received ECN fields, it does not report ECN counts for packets it receives.
ECNの使用には、IPパケットからECNフィールドを読み取るための受信エンドポイントが必要です。これはすべてのプラットフォームでは不可能です。エンドポイントがECNサポートを実装しないか、受信したECNフィールドにアクセスできない場合は、受信したパケットのECNカウントを報告しません。
Even if an endpoint does not set an ECT field in packets it sends, the endpoint MUST provide feedback about ECN markings it receives, if these are accessible. Failing to report the ECN counts will cause the sender to disable the use of ECN for this connection.
エンドポイントが送信されたパケットにECTフィールドを設定していなくても、エンドポイントは受信できるECNマーキングに関するフィードバックを提供する必要があります。ECNカウントを報告することに失敗すると、送信者はこの接続のためのECNの使用を無効にします。
On receiving an IP packet with an ECT(0), ECT(1), or ECN-CE codepoint, an ECN-enabled endpoint accesses the ECN field and increases the corresponding ECT(0), ECT(1), or ECN-CE count. These ECN counts are included in subsequent ACK frames; see Sections 13.2 and 19.3.
ECT（0）、ECT（1）、またはECN-CEコードポイントを持つIPパケットを受信すると、ECN対応エンドポイントはECNフィールドにアクセスし、対応するICT（0）、ECT（1）、またはECN-CEを増やします。カウント。これらのECNカウントは後続のACKフレームに含まれています。セクション13.2と19.3を参照してください。
Each packet number space maintains separate acknowledgment state and separate ECN counts. Coalesced QUIC packets (see Section 12.2) share the same IP header so the ECN counts are incremented once for each coalesced QUIC packet.
各パケット番号スペースは、別々の確認応答状態と別々のECNカウントを維持します。合体QUICパケット（セクション12.2を参照）同じIPヘッダーを共有するため、ECNカウントは各合素化されたQUICパケットに対して一度インクリメントされます。
For example, if one each of an Initial, Handshake, and 1-RTT QUIC packet are coalesced into a single UDP datagram, the ECN counts for all three packet number spaces will be incremented by one each, based on the ECN field of the single IP header.
例えば、初期、ハンドシェイク、および1 - RTTのQUICパケットのそれぞれが単一のUDPデータグラムに合体している場合、シングルのECNフィールドに基づいて、3つのパケット番号スペースすべてのECNカウントがそれぞれ1つずつ増加されるであろう。IPヘッダー
ECN counts are only incremented when QUIC packets from the received IP packet are processed. As such, duplicate QUIC packets are not processed and do not increase ECN counts; see Section 21.10 for relevant security concerns.
ECNカウントは、受信したIPパケットからのQUICパケットが処理されたときにのみインクリメントされます。そのため、重複したQUICパケットは処理されず、ECNカウントを増加させません。関連するセキュリティ上の懸念については、セクション21.10を参照してください。
It is possible for faulty network devices to corrupt or erroneously drop packets that carry a non-zero ECN codepoint. To ensure connectivity in the presence of such devices, an endpoint validates the ECN counts for each network path and disables the use of ECN on that path if errors are detected.
誤ったネットワークデバイスが、ゼロ以外のECNコードポイントを持つパケットを破損または誤って削除することが可能です。そのようなデバイスの存在下での接続を確実にするために、エンドポイントは各ネットワークパスのECNカウントを検証し、エラーが検出された場合、そのパス上のECNの使用を無効にします。
To perform ECN validation for a new path:
新しいパスのECN検証を実行するには
* The endpoint sets an ECT(0) codepoint in the IP header of early outgoing packets sent on a new path to the peer [RFC8311].
* エンドポイントは、Peer [RFC8311]への新しいパスで送信された早期発信パケットのIPヘッダーにECT（0）コードポイントを設定します。
* The endpoint monitors whether all packets sent with an ECT codepoint are eventually deemed lost (Section 6 of [QUIC-RECOVERY]), indicating that ECN validation has failed.
* エンドポイントは、ECTコードポイントで送信されたすべてのパケットが最終的に失われたと見なされるかどうかを監視します（[QUIC-Recovery]のセクション6）、ECN検証が失敗したことを示します。
If an endpoint has cause to expect that IP packets with an ECT codepoint might be dropped by a faulty network element, the endpoint could set an ECT codepoint for only the first ten outgoing packets on a path, or for a period of three PTOs (see Section 6.2 of [QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints are subsequently lost, it can disable marking on the assumption that the marking caused the loss.
エンドポイントにECTコードポイントを持つIPパケットが故障したネットワーク要素によってドロップされる可能性があるという原因がある場合、エンドポイントは、パス上の最初の10個の発信パケットのみまたは3つのPTOの期間の場合はECTポイントを設定できます。[QUIC-RECOVERY]のセクション6.2）。ゼロ以外のECNコードポイントでマークされているすべてのパケットがその後失われた場合、マーキングが損失を引き起こした仮定のマーキングを無効にすることができます。
An endpoint thus attempts to use ECN and validates this for each new connection, when switching to a server's preferred address, and on active connection migration to a new path. Appendix A.4 describes one possible algorithm.
したがって、エンドポイントはECNを使用しようとし、サーバーの優先アドレスに切り替え、新しいパスへのアクティブな接続移行で、新しい接続ごとにこれを検証します。付録A.4に1つの可能なアルゴリズムについて説明します。
Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations MAY use other methods defined in RFCs; see [RFC8311]. Implementations that use the ECT(1) codepoint need to perform ECN validation using the reported ECT(1) counts.
さまざまなマーキング戦略のように、ECNサポートのためのパスをプロービングする方法の他の方法も可能です。実装はRFCで定義されている他の方法を使用することがあります。[RFC8311]を参照してください。ECT（1）コードポイントを使用する実装は、報告されたECT（1）カウントを使用してECN検証を実行する必要があります。
Erroneous application of ECN-CE markings by the network can result in degraded connection performance. An endpoint that receives an ACK frame with ECN counts therefore validates the counts before using them. It performs this validation by comparing newly received counts against those from the last successfully processed ACK frame. Any increase in the ECN counts is validated based on the ECN markings that were applied to packets that are newly acknowledged in the ACK frame.
ネットワークによるECN-CEマーキングの誤ったアプリケーションは、接続性能を低下させる可能性があります。したがって、ECNカウントでACKフレームを受信するエンドポイントは、それらを使用する前にカウントを検証します。これは、最後に正常に処理されたACKフレームからのものに対して新しく受信されたカウントをそれらに対して比較することによってこの検証を実行します。ECNカウントの増加は、ACKフレームに新しく認識されているパケットに適用されたECNマーキングに基づいて検証されます。
If an ACK frame newly acknowledges a packet that the endpoint sent with either the ECT(0) or ECT(1) codepoint set, ECN validation fails if the corresponding ECN counts are not present in the ACK frame. This check detects a network element that zeroes the ECN field or a peer that does not report ECN markings.
ACKフレームが新たにECT（0）またはECT（1）コードポイントセットで送信されたエンドポイントが送信されたパケットを新たに確認すると、対応するECNカウントがACKフレームに存在しない場合はECN検証が失敗します。このチェックは、ECNフィールドまたはECNマーキングを報告しないピアをゼロにするネットワーク要素を検出します。
ECN validation also fails if the sum of the increase in ECT(0) and ECN-CE counts is less than the number of newly acknowledged packets that were originally sent with an ECT(0) marking. Similarly, ECN validation fails if the sum of the increases to ECT(1) and ECN-CE counts is less than the number of newly acknowledged packets sent with an ECT(1) marking. These checks can detect remarking of ECN-CE markings by the network.
ECT（0）およびECN-CEカウントの増加の合計が、もともとECT（0）マーキングで送信された新しく確認されたパケットの数より少ない場合、ECN検証は失敗します。同様に、ECT（1）およびECN-CEカウントへの増加の合計が、ECT（1）マーキングで送信された新しく確認されたパケットの数より少ない場合、ECN検証は失敗します。これらのチェックは、ネットワークによるECN-CEマーキングの除去を検出できます。
An endpoint could miss acknowledgments for a packet when ACK frames are lost. It is therefore possible for the total increase in ECT(0), ECT(1), and ECN-CE counts to be greater than the number of packets that are newly acknowledged by an ACK frame. This is why ECN counts are permitted to be larger than the total number of packets that are acknowledged.
エンドポイントは、ACKフレームが失われたときにパケットの確認応答を見逃す可能性があります。したがって、ECT（0）、ECT（1）、およびECN - CEの総増加は、ACKフレームによって新たに認識されているパケットの数よりも大きくなる可能性がある。これが、ECNカウントが認められたパケットの総数より大きくなることが許可されている理由です。
Validating ECN counts from reordered ACK frames can result in failure. An endpoint MUST NOT fail ECN validation as a result of processing an ACK frame that does not increase the largest acknowledged packet number.
並べ替えられたACKフレームからのECNカウントを検証すると、失敗する可能性があります。最大の確認されたパケット番号を増やさないACKフレームを処理した結果として、エンドポイントはECN検証に失敗してはなりません。
ECN validation can fail if the received total count for either ECT(0) or ECT(1) exceeds the total number of packets sent with each corresponding ECT codepoint. In particular, validation will fail when an endpoint receives a non-zero ECN count corresponding to an ECT codepoint that it never applied. This check detects when packets are remarked to ECT(0) or ECT(1) in the network.
ECT（0）またはECT（1）の受信合計数が、対応する各ECTコードポイントで送信されたパケットの総数を超えると、ECN検証は失敗する可能性があります。特に、エンドポイントが入力されたことがないECTコードポイントに対応する非ゼロのECNカウントを受信したときに検証は失敗します。このチェックは、ネットワーク内のECT（0）またはECT（1）にパケットを述べるかを検出します。
If validation fails, then the endpoint MUST disable ECN. It stops setting the ECT codepoint in IP packets that it sends, assuming that either the network path or the peer does not support ECN.
検証が失敗した場合、エンドポイントはECNを無効にする必要があります。ネットワークパスまたはピアがECNをサポートしていないと仮定して、送信するIPパケット内のECTコードポイントの設定を停止します。
Even if validation fails, an endpoint MAY revalidate ECN for the same path at any later time in the connection. An endpoint could continue to periodically attempt validation.
検証が失敗したとしても、エンドポイントは、接続内の常に同じパスに対してECNを再検証することがあります。エンドポイントは定期的に検証を試みるように続けることができます。
Upon successful validation, an endpoint MAY continue to set an ECT codepoint in subsequent packets it sends, with the expectation that the path is ECN capable. Network routing and path elements can change mid-connection; an endpoint MUST disable ECN if validation later fails.
検証が成功すると、エンドポイントはそれが送信する後続のパケットでECTコードポイントを設定し続けることができます。ネットワークルーティングとパス要素は中間接続を変更できます。検証後に検証が失敗した場合、エンドポイントはECNを無効にする必要があります。
A UDP datagram can include one or more QUIC packets. The datagram size refers to the total UDP payload size of a single UDP datagram carrying QUIC packets. The datagram size includes one or more QUIC packet headers and protected payloads, but not the UDP or IP headers.
UDPデータグラムは1つ以上のQUICパケットを含めることができます。データグラム・サイズとは、QUICパケットを伝える単一のUDPデータグラムの総UDPペイロードサイズを指します。データグラム・サイズには、1つ以上のQUICのパケットヘッダーと保護されたペイロードが含まれていますが、UDPまたはIPヘッダーは含まれていません。
The maximum datagram size is defined as the largest size of UDP payload that can be sent across a network path using a single UDP datagram. QUIC MUST NOT be used if the network path cannot support a maximum datagram size of at least 1200 bytes.
最大データグラム・サイズは、単一のUDPデータグラムを使用してネットワーク・パスを介して送信できる最大サイズのUDPペイロードとして定義されています。ネットワークパスが最大1200バイトの最大データグラムサイズをサポートできない場合は、QUICを使用しないでください。
QUIC assumes a minimum IP packet size of at least 1280 bytes. This is the IPv6 minimum size [IPv6] and is also supported by most modern IPv4 networks. Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are expected to be able to support QUIC.
QUICは、少なくとも1280バイトの最小IPパケットサイズを想定しています。これはIPv6最小サイズ[IPv6]で、ほとんどの最新のIPv4ネットワークでもサポートされています。IPv6およびIPv4の場合は40バイトの最小IPヘッダーサイズと8バイトのUDPヘッダーサイズであると、これにより、IPv6用の最大データグラムサイズが最大1232バイト、IPv4の場合は1252バイトです。したがって、最新のIPv4とすべてのIPv6ネットワークパスはQUICをサポートできると予想されます。
Note: This requirement to support a UDP payload of 1200 bytes limits the space available for IPv6 extension headers to 32 bytes or IPv4 options to 52 bytes if the path only supports the IPv6 minimum MTU of 1280 bytes. This affects Initial packets and path validation.
注：1200バイトのUDPペイロードをサポートするこの要件は、パスが1280バイトのIPv6最小MTUのみをサポートする場合、IPv6拡張ヘッダーに使用できるスペースを32バイトに制限するか、IPv4オプションを52バイトに制限します。 これは、初期パケットとパス検証に影響します。
Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD) (see Section 14.2.1) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD) (see Section 14.3).
1200バイトを超える最大データグラムサイズは、パス最大伝送単位検出（PMTUD）またはデータグラムパケット化レイヤPMTUディスカバリ（DPLPMTUD）を使用して検出できます（14.3項を参照）。
Enforcement of the max_udp_payload_size transport parameter (Section 18.2) might act as an additional limit on the maximum datagram size. A sender can avoid exceeding this limit, once the value is known. However, prior to learning the value of the transport parameter, endpoints risk datagrams being lost if they send datagrams larger than the smallest allowed maximum datagram size of 1200 bytes.
MAX_UDP_PAYLOAD_SIZEトランスポートパラメータ（セクション18.2）の施行は、最大データグラムサイズの追加制限として機能する可能性があります。値がわかったら、送信者はこの制限を超えることを避けることができます。ただし、トランスポートパラメータの値を学習する前に、エンドポイントのリスクデータグラムが、最小の許可された最大データグラムサイズの1200バイトよりも大きいデータグラムを送信すると失われます。
UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 [IPv4], the Don't Fragment (DF) bit MUST be set if possible, to prevent fragmentation on the path.
UDPデータグラムはIP層で断片化されてはいけません。IPv4 [IPv4]では、パス上の断片化を防ぐために、できない場合は、しないフラグメント（DF）ビットを設定する必要があります。
QUIC sometimes requires datagrams to be no smaller than a certain size; see Section 8.1 as an example. However, the size of a datagram is not authenticated. That is, if an endpoint receives a datagram of a certain size, it cannot know that the sender sent the datagram at the same size. Therefore, an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints; the endpoint MAY discard such datagrams.
QUICでは、データグラムが特定のサイズより小さくないことが必要です。例としてセクション8.1を参照してください。ただし、データグラムのサイズは認証されていません。つまり、エンドポイントが特定のサイズのデータグラムを受信した場合、送信者がデータグラムを同じサイズで送信したことを知ることができません。したがって、サイズの制約を満たさないデータグラムを受信したときにエンドポイントは接続を閉じてはいけません。エンドポイントはそのようなデータグラムを破棄することがあります。
A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see Section 12.2. Initial packets can even be coalesced with invalid packets, which a receiver will discard. Similarly, a server MUST expand the payload of all UDP datagrams carrying ack-eliciting Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes.
クライアントは、初期パケットを最初のパケットに追加することによって、または初期パケットを合体することによって、初期パケットを搬送するすべてのUDPデータグラムのペイロードを少なくとも最小の許可された最大データグラムサイズで1200バイトに拡張する必要があります。12.2項を参照してください。初期パケットは無効なパケットでも合体することさえできます。これは、受信者が破棄されます。同様に、サーバーは、ACKエリチョン初期パケットを持ち運ぶすべてのUDPデータグラムのペイロードを少なくとも最小の許容最大データグラムサイズ1200バイトに拡張する必要があります。
Sending UDP datagrams of this size ensures that the network path supports a reasonable Path Maximum Transmission Unit (PMTU), in both directions. Additionally, a client that expands Initial packets helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see Section 8.
このサイズのUDPデータグラムの送信は、ネットワークパスが妥当なパス最大伝送ユニット（PMTU）を両方向にサポートすることを保証します。さらに、初期パケットを拡張するクライアントは、サーバーの応答によって発生した未確認のクライアントアドレスへの増幅攻撃の振幅を減らすのに役立ちます。セクション8を参照してください。
Datagrams containing Initial packets MAY exceed 1200 bytes if the sender believes that the network path and peer both support the size that it chooses.
送信者がネットワークパスとピアが選択したサイズをサポートしていると、送信側が1200バイトを超えるデータグラムを超えることがあります。
A server MUST discard an Initial packet that is carried in a UDP datagram with a payload that is smaller than the smallest allowed maximum datagram size of 1200 bytes. A server MAY also immediately close the connection by sending a CONNECTION_CLOSE frame with an error code of PROTOCOL_VIOLATION; see Section 10.2.3.
サーバーは、1200バイトの最小の許容最大データグラムサイズより小さいペイロードを使用してUDPデータグラムで実行される初期パケットを破棄する必要があります。サーバーはまた、ERROR_VIOLATIONのエラーコードを持つCONNECTION_CLOSEフレームを送信することによって接続を閉じることができます。10.2.3項を参照してください。
The server MUST also limit the number of bytes it sends before validating the address of the client; see Section 8.
サーバーは、クライアントのアドレスを検証する前に送信するバイト数も制限する必要があります。セクション8を参照してください。
The PMTU is the maximum size of the entire IP packet, including the IP header, UDP header, and UDP payload. The UDP payload includes one or more QUIC packet headers and protected payloads. The PMTU can depend on path characteristics and can therefore change over time. The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum datagram size.
PMTUは、IPヘッダー、UDPヘッダー、およびUDPペイロードなど、IPパケット全体の最大サイズです。UDPペイロードには、1つ以上のQUICパケットヘッダーと保護されたペイロードが含まれています。PMTUは経路特性に依存し、したがって時間とともに変化することができる。最大のUDPペイロードのエンドポイントは任意の時間に送信されます。エンドポイントの最大データグラム・サイズと呼びます。
An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD (Section 14.2.1) to determine whether the path to a destination will support a desired maximum datagram size without fragmentation. In the absence of these mechanisms, QUIC endpoints SHOULD NOT send datagrams larger than the smallest allowed maximum datagram size.
エンドポイントは、DPLPMTUD（セクション14.3）またはPMTUD（第14.2.1項）を使用して、宛先へのパスが断片化なしで希望の最大データグラム・サイズをサポートするかどうかを判断する必要があります。これらのメカニズムがない場合、QUICのエンドポイントは、最小の許容最大データグラムサイズよりも大きいデータグラムを送信しないでください。
Both DPLPMTUD and PMTUD send datagrams that are larger than the current maximum datagram size, referred to as PMTU probes. All QUIC packets that are not sent in a PMTU probe SHOULD be sized to fit within the maximum datagram size to avoid the datagram being fragmented or dropped [RFC8085].
DPLPMTUDとPMTUDの両方とも、PMTUプローブと呼ばれる現在の最大データグラムサイズよりも大きいデータグラムを送信します。PMTUプローブで送信されていないすべてのQUICパケットは、データグラムが断片化またはドロップされている[RFC8085]を回避するために、最大データグラムサイズ内に収まるようにサイズ設定されるべきです。
If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses cannot support the smallest allowed maximum datagram size of 1200 bytes, it MUST immediately cease sending QUIC packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path. An endpoint MAY terminate the connection if an alternative path cannot be found.
QUICエンドポイントが、ローカルIPアドレスとリモートIPアドレスのペア間のPMTUが1200バイトの最小許容最大データグラムサイズをサポートできない場合は、PMTUプローブまたはCONNECTION_CLOSEフレームを含むものを除き、すぐにQUICパケットの送信を中止する必要があります。影響を受けるパス。代替パスが見つからない場合、エンドポイントは接続を終了することがあります。
Each pair of local and remote addresses could have a different PMTU. QUIC implementations that implement any kind of PMTU discovery therefore SHOULD maintain a maximum datagram size for each combination of local and remote IP addresses.
ローカルアドレスとリモートアドレスの各ペアは、異なるPMTUを持つことができます。したがって、あらゆる種類のPMTUディスカバリを実装するQUIC実装は、ローカルIPアドレスとリモートIPアドレスとリモートIPアドレスの各組み合わせに対して最大のデータグラムサイズを維持する必要があります。
A QUIC implementation MAY be more conservative in computing the maximum datagram size to allow for unknown tunnel overheads or IP header options/extensions.
不明なトンネルのオーバーヘッドまたはIPヘッダーオプション/拡張機能を可能にするために、最大データグラムサイズを計算するのに厳密な実装がより保守的であり得る。
PMTUD [RFC1191] [RFC8201] relies on reception of ICMP messages (that is, IPv6 Packet Too Big (PTB) messages) that indicate when an IP packet is dropped because it is larger than the local router MTU. DPLPMTUD can also optionally use these messages. This use of ICMP messages is potentially vulnerable to attacks by entities that cannot observe packets but might successfully guess the addresses used on the path. These attacks could reduce the PMTU to a bandwidth-inefficient value.
PMTUD [RFC1191] [RFC8201]は、ローカルルータMTUより大きいため、IPパケットが削除されたときにICMPメッセージ（つまり、IPv6パケットが大きすぎる（PTB）メッセージ）の受信に依存しています。DPLPMTUDはオプションでこれらのメッセージを使用することもできます。ICMPメッセージの使用は、パケットを監視できないが、パスで使用されているアドレスを正常に推測する可能性があるエンティティによる攻撃に対して潜在的に脆弱です。これらの攻撃はPMTUを帯域幅非効率的な値に減らすことができます。
An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below QUIC's smallest allowed maximum datagram size.
エンドポイントは、PMTUがQUICの最小の最大データグラムサイズを下回って減少したことを主張するICMPメッセージを無視する必要があります。
The requirements for generating ICMP [RFC1812] [RFC4443] state that the quoted packet should contain as much of the original packet as possible without exceeding the minimum MTU for the IP version. The size of the quoted packet can actually be smaller, or the information unintelligible, as described in Section 1.1 of [DPLPMTUD].
ICMP [RFC1812] [RFC4443] [RFC4443] [RFC4443] [RFC4443]は、IPバージョンの最小MTUを超えずにできるだけ多くのオリジナルのパケットを含める必要があります。[DPLPMTUD]のセクション1.1で説明されているように、引用符付きパケットのサイズは、実際には小さく、または無感覚を実現できます。
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect from packet injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. This validation SHOULD use the quoted packet supplied in the payload of an ICMP message to associate the message with a corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). ICMP message validation MUST include matching IP addresses and UDP ports [RFC8085] and, when possible, connection IDs to an active QUIC session. The endpoint SHOULD ignore all ICMP messages that fail validation.
PMTUDを使用したQUICのエンドポイント[RFC8201]と[RFC8085]のセクション5.2で指定されているように、パケット注入から保護するためにICMPメッセージを検証する必要があります。この検証は、メッセージを対応するトランスポート接続と関連付けるために、ICMPメッセージのペイロードで提供されている引用符付きパケットを使用する必要があります（[DPLPMTUD]のセクション4.6.1参照）。ICMPメッセージの検証には、IPアドレスとUDPポートとの一致（RFC8085]と、可能であれば接続IDをアクティブなQUICセッションに含める必要があります。エンドポイントは、検証に失敗するすべてのICMPメッセージを無視します。
An endpoint MUST NOT increase the PMTU based on ICMP messages; see Item 6 in Section 3 of [DPLPMTUD]. Any reduction in QUIC's maximum datagram size in response to ICMP messages MAY be provisional until QUIC's loss detection algorithm determines that the quoted packet has actually been lost.
エンドポイントは、ICMPメッセージに基づいてPMTUを増やしてはいけません。[dplpmtud]のセクション3の項目6を参照してください。ICMPメッセージに応答して、QUICの最大データグラムサイズを縮小することは、QUICの損失検出アルゴリズムが実際に失われたと判断するまで暫定的なものになることがあります。
DPLPMTUD [DPLPMTUD] relies on tracking loss or acknowledgment of QUIC packets that are carried in PMTU probes. PMTU probes for DPLPMTUD that use the PADDING frame implement "Probing using padding data", as defined in Section 4.1 of [DPLPMTUD].
DPLPMTUD [DPLPMTUD]は、PMTUプローブで運ばれるQUICパケットのトラッキング損失または確認応答に依存しています。DPLPMTUDのPMTUプローブ[DPLPMTUD]のセクション4.1で定義されているように、「パディングデータを使用してプロービング」を実装します。
Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of [DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum datagram size. The MIN_PLPMTU is the same as the BASE_PLPMTU.
エンドポイントは、Quicの最小の最大データグラムサイズと一致するように、base_plpmtu（dplpmtud]のセクション5.1）の初期値を設定する必要があります。min_plpmtuはbase_plpmtuと同じです。
QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum Packet Size (MPS) (Section 4.4 of [DPLPMTUD]) for each combination of local and remote IP addresses. This corresponds to the maximum datagram size.
LOCAL IPアドレスとリモートIPアドレスの組み合わせごとに、DPLPMTUDの実装のQUICのエンドポイント（DPLPMTUDのセクション4.4）を維持します。これは最大データグラムサイズに対応しています。
From the perspective of DPLPMTUD, QUIC is an acknowledged Packetization Layer (PL). A QUIC sender can therefore enter the DPLPMTUD BASE state (Section 5.2 of [DPLPMTUD]) when the QUIC connection handshake has been completed.
DPLPMTUDの観点から、QUICは認証されたパケット化層（PL）です。したがって、QUIC接続ハンドシェイクが完了したときに、QUIC送信者はDPLPMTUD基本状態（[DPLPMTUD]のセクション5.2）を入力できます。
QUIC is an acknowledged PL; therefore, a QUIC sender does not implement a DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of [DPLPMTUD].
QUICは承認されたPLです。したがって、Quic Senderはsearch_complete状態にある間にDPLPMTUD confirn_timerを実装しません。[DPLPMTUD]のセクション5.2を参照してください。
An endpoint using DPLPMTUD requires the validation of any received ICMP PTB message before using the PTB information, as defined in Section 4.6 of [DPLPMTUD]. In addition to UDP port validation, QUIC validates an ICMP message by using other PL information (e.g., validation of connection IDs in the quoted packet of any received ICMP message).
DPLPMTUDを使用したエンドポイントでは、[DPLPMTUD]のセクション4.6で定義されているように、PTB情報を使用する前に、受信したICMP PTBメッセージの検証が必要です。UDPポート検証に加えて、QUICは他のPL情報を使用してICMPメッセージを検証します（例えば、受信したICMPメッセージの引用符dパケット内の接続IDの検証）。
The considerations for processing ICMP messages described in Section 14.2.1 also apply if these messages are used by DPLPMTUD.
セクション14.2.1で説明されているICMPメッセージを処理するための考慮事項も、これらのメッセージがDPLPMTUDによって使用されている場合に適用されます。
PMTU probes are ack-eliciting packets.
PMTUプローブはACKエリチコットパケットです。
Endpoints could limit the content of PMTU probes to PING and PADDING frames, since packets that are larger than the current maximum datagram size are more likely to be dropped by the network. Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT trigger a congestion control reaction; see Item 7 in Section 3 of [DPLPMTUD]. However, PMTU probes consume congestion window, which could delay subsequent transmission by an application.
現在の最大データグラムサイズよりも大きいパケットはネットワークによってドロップされる可能性が高いため、エンドポイントはPMTUプローブのコンテンツをpingフレームとパディングフレームに制限する可能性があります。したがって、PMTUプローブで運ばれるQUICパケットの損失は、輻輳の信頼性の高い表示ではなく、輻輳制御反応を引き起こすべきではありません。[DPLPMTUD]のセクション7の項目7を参照してください。しかしながら、PMTUプローブは輻輳ウィンドウを消費し、それはアプリケーションによるその後の送信を遅らせる可能性がある。
Endpoints that rely on the Destination Connection ID field for routing incoming QUIC packets are likely to require that the connection ID be included in PMTU probes to route any resulting ICMP messages (Section 14.2.1) back to the correct endpoint. However, only long header packets (Section 17.2) contain the Source Connection ID field, and long header packets are not decrypted or acknowledged by the peer once the handshake is complete.
着信QUICパケットをルーティングするための宛先接続IDフィールドに依存するエンドポイントは、接続IDをPMTUプローブに含める必要がある可能性があります（セクション14.2.1）、（セクション14.2.1）を正しいエンドポイントに戻します。ただし、長いヘッダーパケット（セクション17.2）のみがソース接続IDフィールドを含み、ハンドシェイクが完了したら、ロングヘッダーパケットはピアによって復号化または確認されません。
One way to construct a PMTU probe is to coalesce (see Section 12.2) a packet with a long header, such as a Handshake or 0-RTT packet (Section 17.2), with a short header packet in a single UDP datagram. If the resulting PMTU probe reaches the endpoint, the packet with the long header will be ignored, but the short header packet will be acknowledged. If the PMTU probe causes an ICMP message to be sent, the first part of the probe will be quoted in that message. If the Source Connection ID field is within the quoted portion of the probe, that could be used for routing or validation of the ICMP message.
PMTUプローブを構築する1つの方法は、単一のUDPデータグラムに短いヘッダパケットを備えた、ハンドシェイクまたは0-RTTパケット（セクション17.2）などの長いヘッダ（セクション17.2）を有するパケットを共演することである（セクション12.2参照）。結果のPMTUプローブがエンドポイントに達すると、ロングヘッダーを持つパケットは無視されますが、短いヘッダーパケットは確認されます。PMTUプローブがICMPメッセージを送信させると、プローブの最初の部分がそのメッセージ内で引用されます。ソース接続IDフィールドがプローブの引用符付き部分内にある場合、それはICMPメッセージのルーティングまたは検証に使用できます。
Note: The purpose of using a packet with a long header is only to ensure that the quoted packet contained in the ICMP message contains a Source Connection ID field. This packet does not need to be a valid packet, and it can be sent even if there is no current use for packets of that type.
注：長いヘッダーを持つパケットを使用する目的は、ICMPメッセージに含まれる引用符で囲まれたパケットにソース接続IDフィールドが含まれていることを確認することだけです。 このパケットは有効なパケットである必要はなく、そのタイプのパケットが現在使用されていない場合でも送信できます。
QUIC versions are identified using a 32-bit unsigned number.
QUICバージョンは、32ビットの符号なし番号を使用して識別されます。
The version 0x00000000 is reserved to represent version negotiation. This version of the specification is identified by the number 0x00000001.
バージョン0x00000000はバージョンネゴシエーションを表すために予約されています。このバージョンの仕様は、数値0x00000001で識別されます。
Other versions of QUIC might have different properties from this version. The properties of QUIC that are guaranteed to be consistent across all versions of the protocol are described in [QUIC-INVARIANTS].
QUICの他のバージョンでは、このバージョンから異なるプロパティがあります。プロトコルのすべてのバージョンにわたって一貫性があることが保証されているQUICのプロパティは、[QUIC-INVARIANTS]に記載されています。
Version 0x00000001 of QUIC uses TLS as a cryptographic handshake protocol, as described in [QUIC-TLS].
[QUIC-TLS]で説明されているように、QUICのバージョン0x00000001は暗号化ハンドシェイクプロトコルとしてTLSを使用します。
Versions with the most significant 16 bits of the version number cleared are reserved for use in future IETF consensus documents.
クリアされたバージョン番号の最も重要な16ビットのバージョンは、将来のIETFコンセンサス文書で使用するために予約されています。
Versions that follow the pattern 0x?a?a?a?a are reserved for use in forcing version negotiation to be exercised -- that is, any version number where the low four bits of all bytes is 1010 (in binary). A client or server MAY advertise support for any of these reserved versions.
パターン0x?a?a?a?aは、実行されるべきバージョンネゴシエーションを強制するために予約されています。つまり、すべてのバイトの4ビットの低い4ビットが1010（バイナリ）である任意のバージョン番号です。クライアントまたはサーバーは、これらの予約済みバージョンのいずれかについてのサポートを宣伝することができます。
Reserved version numbers will never represent a real protocol; a client MAY use one of these version numbers with the expectation that the server will initiate version negotiation; a server MAY advertise support for one of these versions and can expect that clients ignore the value.
予約バージョン番号は実際のプロトコルを表すことはありません。クライアントは、サーバーがバージョンネゴシエーションを開始することを期待してこれらのバージョン番号の1つを使用できます。サーバーは、これらのバージョンの1つに対してサポートを宣伝することができ、クライアントが値を無視することを期待できます。
QUIC packets and frames commonly use a variable-length encoding for non-negative integer values. This encoding ensures that smaller integer values need fewer bytes to encode.
QUICパケットとフレームは、負の負の整数値に対して可変長エンコーディングを使用します。このエンコーディングにより、整数値が小さくなると、エンコードするバイト数が少ない必要があります。
The QUIC variable-length integer encoding reserves the two most significant bits of the first byte to encode the base-2 logarithm of the integer encoding length in bytes. The integer value is encoded on the remaining bits, in network byte order.
QUICの可変長整数符号化は、整数符号化長の基底2の対数をバイト単位で符号化するために第1バイトの2つの最上位ビットを予約します。整数値は、ネットワークバイト順で、残りのビットにエンコードされます。
This means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values, respectively. Table 4 summarizes the encoding properties.
つまり、整数は1,2,4または8バイトでエンコードされ、6,14,30または62ビットの値をそれぞれ符号化できます。表4は符号化特性を要約しています。
+======+========+=============+=======================+
| 2MSB | Length | Usable Bits | Range |
+======+========+=============+=======================+
| 00 | 1 | 6 | 0-63 |
+------+--------+-------------+-----------------------+
| 01 | 2 | 14 | 0-16383 |
+------+--------+-------------+-----------------------+
| 10 | 4 | 30 | 0-1073741823 |
+------+--------+-------------+-----------------------+
| 11 | 8 | 62 | 0-4611686018427387903 |
+------+--------+-------------+-----------------------+
Table 4: Summary of Integer Encodings
表4：整数エンコーディングの概要
An example of a decoding algorithm and sample encodings are shown in Appendix A.1.
復号化アルゴリズムおよびサンプルエンコーディングの例を付録A.1に示す。
Values do not need to be encoded on the minimum number of bytes necessary, with the sole exception of the Frame Type field; see Section 12.4.
フレームタイプフィールドを単独で例外した状態で、必要な最小バイト数で値を符号化する必要はありません。12.4項を参照してください。
Versions (Section 15), packet numbers sent in the header (Section 17.1), and the length of connection IDs in long header packets (Section 17.2) are described using integers but do not use this encoding.
バージョン（セクション15）、ヘッダで送信されたパケット番号（セクション17.1）、およびロングヘッダーパケット内の接続IDの長さ（セクション17.2）は、整数を使用して説明されていますが、このエンコードは使用しません。
All numeric values are encoded in network byte order (that is, big endian), and all field sizes are in bits. Hexadecimal notation is used for describing the value of fields.
すべての数値はネットワークバイト順（つまり、大きなエンディアン）でエンコードされ、すべてのフィールドサイズはビットです。フィールドの値を記述するために16進数の表記が使用されます。
Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). When present in long or short packet headers, they are encoded in 1 to 4 bytes. The number of bits required to represent the packet number is reduced by including only the least significant bits of the packet number.
パケット番号は、0から2^62-1の範囲の整数です（セクション12.3）。長いパケットヘッダーまたは短いパケットヘッダーに存在する場合、それらは1から4バイトでエンコードされます。パケット番号の表現に必要なビット数は、パケット番号の最下位ビットのみを含めることによって減少します。
The encoded packet number is protected as described in Section 5.4 of [QUIC-TLS].
符号化パケット番号は、[QUIC-TLS]のセクション5.4に記載されているように保護されています。
Prior to receiving an acknowledgment for a packet number space, the full packet number MUST be included; it is not to be truncated, as described below.
パケット番号スペースに対して確認応答を受信する前に、フルパケット番号を含める必要があります。後述するように、切り捨てないではない。
After an acknowledgment is received for a packet number space, the sender MUST use a packet number size able to represent more than twice as large a range as the difference between the largest acknowledged packet number and the packet number being sent. A peer receiving the packet will then correctly decode the packet number, unless the packet is delayed in transit such that it arrives after many higher-numbered packets have been received. An endpoint SHOULD use a large enough packet number encoding to allow the packet number to be recovered even if the packet arrives after packets that are sent afterwards.
肯定応答がパケット番号スペースに対して受信された後、送信者は、最大の確認されたパケット番号と送信されているパケット番号との間の差の2倍以上の大きな範囲を表すことができるパケット番号サイズを使用する必要があります。パケットを受信したピアは、パケットが遷移が遅延されていない限り、パケット番号を正しく復号して、多くの上位のパケットが受信された後に到着する。エンドポイントは、パケットが後で送信された後にパケットが到着したとしても、パケット番号を回復できるように、十分なパケット番号エンコードを使用する必要があります。
As a result, the size of the packet number encoding is at least one bit more than the base-2 logarithm of the number of contiguous unacknowledged packet numbers, including the new packet. Pseudocode and an example for packet number encoding can be found in Appendix A.2.
その結果、パケット番号符号化のサイズは、新しいパケットを含む、連続していない未確認パケット番号の数のBASE - 2対数より少なくとも1ビットである。疑似コードとパケット番号エンコードの例は、付録A.2にあります。
At a receiver, protection of the packet number is removed prior to recovering the full packet number. The full packet number is then reconstructed based on the number of significant bits present, the value of those bits, and the largest packet number received in a successfully authenticated packet. Recovering the full packet number is necessary to successfully complete the removal of packet protection.
受信機では、フルパケット番号を回復する前にパケット番号の保護が削除されます。次に、全パケット番号、存在する有効ビット数、それらのビットの値、および正常に認証されたパケットで受信された最大パケット番号に基づいて再構築される。フルパケット番号を回復するには、パケット保護の削除を正常に完了するために必要です。
Once header protection is removed, the packet number is decoded by finding the packet number value that is closest to the next expected packet. The next expected packet is the highest received packet number plus one. Pseudocode and an example for packet number decoding can be found in Appendix A.3.
ヘッダ保護が削除されると、次の予想されるパケットに最も近いパケット番号値を見つけることによってパケット番号が復号されます。次の予想されるパケットは、最高の受信パケット番号と1つになります。疑似コードとパケット番号復号化の例は付録A.3にあります。
Long Header Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2),
Type-Specific Bits (4),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Type-Specific Payload (..),
}
Figure 13: Long Header Packet Format
図13：ロングヘッダーパケットフォーマット
Long headers are used for packets that are sent prior to the establishment of 1-RTT keys. Once 1-RTT keys are available, a sender switches to sending packets using the short header (Section 17.3). The long form allows for special packets -- such as the Version Negotiation packet -- to be represented in this uniform fixed-length packet format. Packets that use the long header contain the following fields:
長いヘッダーは、1-RTTキーを確立する前に送信されるパケットに使用されます。1-RTTキーが利用可能になると、送信側は短いヘッダーを使用してパケットの送信を切り替えます（セクション17.3）。長い形式は、この均一な固定長パケット形式で表されるバージョンネゴシエーションパケットのような特別なパケットを可能にする。ロングヘッダーを使用するパケットには、次のフィールドが含まれています。
Header Form: The most significant bit (0x80) of byte 0 (the first byte) is set to 1 for long headers.
ヘッダフォーム：長いヘッダに対してバイト0の最上位ビット（0x80）は1に設定されています。
Fixed Bit: The next bit (0x40) of byte 0 is set to 1, unless the packet is a Version Negotiation packet. Packets containing a zero value for this bit are not valid packets in this version and MUST be discarded. A value of 1 for this bit allows QUIC to coexist with other protocols; see [RFC7983].
固定ビット：パケットがバージョンネゴシエーションパケットでない限り、バイト0の次のビット（0x40）は1に設定されます。このビットのゼロ値を含むパケットは、このバージョンでは無効なパケットではなく、破棄する必要があります。このビットの値1の値は、QUICが他のプロトコルと共存することを可能にします。[RFC7983]を参照してください。
Long Packet Type: The next two bits (those with a mask of 0x30) of byte 0 contain a packet type. Packet types are listed in Table 5.
長いパケットタイプ：バイト0の次の2ビット（マスク0x30のもの）はパケットタイプを含みます。パケットタイプを表5に示します。
Type-Specific Bits: The semantics of the lower four bits (those with a mask of 0x0f) of byte 0 are determined by the packet type.
タイプ固有ビット：バイト0の下位4ビット（マスク0x0fのマスク）の意味はパケットタイプによって決まります。
Version: The QUIC Version is a 32-bit field that follows the first byte. This field indicates the version of QUIC that is in use and determines how the rest of the protocol fields are interpreted.
バージョン：QUICバージョンは、最初のバイトに続く32ビットフィールドです。このフィールドは、使用中のQUICのバージョンを示し、プロトコルフィールドの残りの部分がどのように解釈されるかを決定します。
Destination Connection ID Length: The byte following the version contains the length in bytes of the Destination Connection ID field that follows it. This length is encoded as an 8-bit unsigned integer. In QUIC version 1, this value MUST NOT exceed 20 bytes. Endpoints that receive a version 1 long header with a value larger than 20 MUST drop the packet. In order to properly form a Version Negotiation packet, servers SHOULD be able to read longer connection IDs from other QUIC versions.
宛先接続ID長：バージョンに続くバイトには、それに続く宛先接続IDフィールドの長さが含まれています。この長さは8ビットの符号なし整数としてエンコードされています。QUICバージョン1では、この値は20バイトを超えてはいけません。20より大きい値を持つバージョン1ロングヘッダーを受信するエンドポイントは、パケットをドロップする必要があります。バージョンネゴシエーションパケットを正しく形成するために、サーバーは他のQUICのバージョンからの長い接続IDを読み取ることができるはずです。
Destination Connection ID: The Destination Connection ID field follows the Destination Connection ID Length field, which indicates the length of this field. Section 7.2 describes the use of this field in more detail.
宛先接続ID：[宛先接続ID]フィールドは[宛先接続IDの長さ]フィールドに従います。これはこのフィールドの長さを示します。セクション7.2はこのフィールドの使用方法をより詳細に説明しています。
Source Connection ID Length: The byte following the Destination Connection ID contains the length in bytes of the Source Connection ID field that follows it. This length is encoded as an 8-bit unsigned integer. In QUIC version 1, this value MUST NOT exceed 20 bytes. Endpoints that receive a version 1 long header with a value larger than 20 MUST drop the packet. In order to properly form a Version Negotiation packet, servers SHOULD be able to read longer connection IDs from other QUIC versions.
ソース接続IDの長さ：宛先接続IDに続くバイトには、それに続くソース接続IDフィールドのバイト数が含まれています。この長さは8ビットの符号なし整数としてエンコードされています。QUICバージョン1では、この値は20バイトを超えてはいけません。20より大きい値を持つバージョン1ロングヘッダーを受信するエンドポイントは、パケットをドロップする必要があります。バージョンネゴシエーションパケットを正しく形成するために、サーバーは他のQUICのバージョンからの長い接続IDを読み取ることができるはずです。
Source Connection ID: The Source Connection ID field follows the Source Connection ID Length field, which indicates the length of this field. Section 7.2 describes the use of this field in more detail.
ソース接続ID：[ソース接続ID]フィールドは、[ソース接続IDの長さ]フィールドになります。これはこのフィールドの長さを示します。セクション7.2はこのフィールドの使用方法をより詳細に説明しています。
Type-Specific Payload: The remainder of the packet, if any, is type specific.
タイプ固有のペイロード：パケットの残りの部分があればタイプ固有のものです。
In this version of QUIC, the following packet types with the long header are defined:
このバージョンのQUICでは、ロングヘッダーを持つ次のパケットタイプが定義されています。
+======+===========+================+
| Type | Name | Section |
+======+===========+================+
| 0x00 | Initial | Section 17.2.2 |
+------+-----------+----------------+
| 0x01 | 0-RTT | Section 17.2.3 |
+------+-----------+----------------+
| 0x02 | Handshake | Section 17.2.4 |
+------+-----------+----------------+
| 0x03 | Retry | Section 17.2.5 |
+------+-----------+----------------+
Table 5: Long Header Packet Types
表5：長いヘッダーパケットの種類
The header form bit, Destination and Source Connection ID lengths, Destination and Source Connection ID fields, and Version fields of a long header packet are version independent. The other fields in the first byte are version specific. See [QUIC-INVARIANTS] for details on how packets from different versions of QUIC are interpreted.
長いヘッダーパケットのヘッダーフォームビット、宛先および送信元接続IDの長さ、宛先および送信元接続IDフィールド、およびバージョンフィールドはバージョンに依存しません。 最初のバイトの他のフィールドはバージョン固有です。 異なるバージョンのQUICからのパケットがどのように解釈されるかの詳細については、[QUIC-INVARIANTS]を参照してください。
The interpretation of the fields and the payload are specific to a version and packet type. While type-specific semantics for this version are described in the following sections, several long header packets in this version of QUIC contain these additional fields:
フィールドの解釈とペイロードは、バージョンとパケットの種類に固有のものです。このバージョンのタイプ固有のセマンティクスは、次のセクションで説明されていますが、このバージョンのQUICにはこれらの追加フィールドがいくつか含まれています。
Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are reserved across multiple packet types. These bits are protected using header protection; see Section 5.4 of [QUIC-TLS]. The value included prior to protection MUST be set to 0. An endpoint MUST treat receipt of a packet that has a non-zero value for these bits after removing both packet and header protection as a connection error of type PROTOCOL_VIOLATION. Discarding such a packet after only removing header protection can expose the endpoint to attacks; see Section 9.5 of [QUIC-TLS].
予約ビット：バイト0の2ビット（マスク0x0cのマスク）は、複数のパケットタイプにわたって予約されています。これらのビットはヘッダー保護を使用して保護されています。[QUIC-TLS]のセクション5.4を参照してください。保護の前に含まれている値は0に設定する必要があります。エンドポイントは、パケットとヘッダー保護の両方をプロトコルの接続エラーとして削除した後、ゼロ以外のパケットの受信をPROTOCOL_VIOLATION型の接続エラーとして扱う必要があります。ヘッダー保護を削除した後にそのようなパケットを破棄すると、エンドポイントが攻撃にさらされる可能性があります。[QUIC-TLS]のセクション9.5を参照してください。
Packet Number Length: In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain the length of the Packet Number field, encoded as an unsigned two-bit integer that is one less than the length of the Packet Number field in bytes. That is, the length of the Packet Number field is the value of this field plus one. These bits are protected using header protection; see Section 5.4 of [QUIC-TLS].
パケット番号長：パケット番号フィールドを含むパケットタイプでは、バイト0の最下位2ビット（マスク0x03のマスク）は、1つの符号なし2ビット整数としてエンコードされたパケット番号フィールドの長さを含みます。パケット番号フィールドの長さがバイト単位で小さい。つまり、パケット番号フィールドの長さはこのフィールドの値と1つの値です。これらのビットはヘッダー保護を使用して保護されています。[QUIC-TLS]のセクション5.4を参照してください。
Length: This is the length of the remainder of the packet (that is, the Packet Number and Payload fields) in bytes, encoded as a variable-length integer (Section 16).
長さ：これは、可変長整数としてエンコードされた、パケットの残りの部分（つまり、パケット番号とペイロードフィールド）の長さです（つまり、セクション16）。
Packet Number: This field is 1 to 4 bytes long. The packet number is protected using header protection; see Section 5.4 of [QUIC-TLS]. The length of the Packet Number field is encoded in the Packet Number Length bits of byte 0; see above.
パケット番号：このフィールドは1~4バイトの長さです。パケット番号はヘッダー保護を使用して保護されています。[QUIC-TLS]のセクション5.4を参照してください。パケット番号フィールドの長さは、バイト0のパケット番号長ビットでエンコードされます。上記を参照。
Packet Payload: This is the payload of the packet -- containing a sequence of frames -- that is protected using packet protection.
パケットペイロード：これは、パケット保護を使用して保護されているフレームのシーケンスを含むパケットのペイロードです。
A Version Negotiation packet is inherently not version specific. Upon receipt by a client, it will be identified as a Version Negotiation packet based on the Version field having a value of 0.
バージョンネゴシエーションパケットは本質的にバージョン固有ではありません。クライアントによって受信されると、それは値が0のバージョンフィールドに基づいてバージョンネゴシエーションパケットとして識別されるであろう。
The Version Negotiation packet is a response to a client packet that contains a version that is not supported by the server. It is only sent by servers.
バージョンネゴシエーションパケットは、サーバーでサポートされていないバージョンを含むクライアントパケットに対する応答です。サーバーによってのみ送信されます。
The layout of a Version Negotiation packet is:
バージョンネゴシエーションパケットのレイアウトは次のとおりです。
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 14: Version Negotiation Packet
図14：バージョンネゴシエーションパケット
The value in the Unused field is set to an arbitrary value by the server. Clients MUST ignore the value of this field. Where QUIC might be multiplexed with other protocols (see [RFC7983]), servers SHOULD set the most significant bit of this field (0x40) to 1 so that Version Negotiation packets appear to have the Fixed Bit field. Note that other versions of QUIC might not make a similar recommendation.
未使用フィールドの値は、サーバーによって任意の値に設定されます。クライアントはこのフィールドの値を無視する必要があります。QUICが他のプロトコルと多重化される可能性がある（[RFC7983]参照）、サーバーはこのフィールド（0x40）の最上位ビットを1に設定して、バージョンネゴシエーションパケットが固定ビットフィールドを持つように見えます。QUICの他のバージョンも同様の推奨事項を作成しない可能性があることに注意してください。
The Version field of a Version Negotiation packet MUST be set to 0x00000000.
バージョンネゴシエーションパケットのバージョンフィールドは0x00000000に設定する必要があります。
The server MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID field. The value for Source Connection ID MUST be copied from the Destination Connection ID 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 entity that did not observe the Initial packet.
サーバーには、宛先接続IDフィールドに受信したパケットの送信元接続IDフィールドから値を含める必要があります。ソース接続IDの値は、受信したパケットの宛先接続IDからコピーする必要があります。これは最初はクライアントによってランダムに選択されます。両方の接続IDは、サーバーがパケットを受信し、バージョンネゴシエーションパケットが最初のパケットを監視しなかったエンティティによって生成されていないことをクライアントにします。
Future versions of QUIC could have different requirements for the lengths of connection IDs. In particular, connection IDs might have a smaller minimum length or a greater maximum length. Version-specific rules for the connection ID therefore MUST NOT influence a decision about whether to send a Version Negotiation packet.
QUICの将来のバージョンは、接続IDの長さに対して異なる要件を持つ可能性があります。特に、接続IDは、最小長さまたはより大きい最大長を有する可能性がある。したがって、接続IDのバージョン固有の規則は、バージョンネゴシエーションパケットを送信するかどうかについての決定に影響を与えてはなりません。
The remainder of the Version Negotiation packet is a list of 32-bit versions that the server supports.
バージョンネゴシエーションパケットの残りは、サーバーがサポートする32ビットバージョンのリストです。
A Version Negotiation packet is not acknowledged. It is only sent in response to a packet that indicates an unsupported version; see Section 5.2.2.
バージョンネゴシエーションパケットは認識されません。サポートされていないバージョンを示すパケットに応答して送信されます。セクション5.2.2を参照してください。
The Version Negotiation packet does not include the Packet Number and Length fields present in other packets that use the long header form. Consequently, a Version Negotiation packet consumes an entire UDP datagram.
バージョンネゴシエーションパケットには、長いヘッダフォームを使用する他のパケットに存在するパケット番号と長さフィールドは含まれていません。その結果、バージョンネゴシエーションパケットはUDPデータグラム全体を消費します。
A server MUST NOT send more than one Version Negotiation packet in response to a single UDP datagram.
サーバーは、単一のUDPデータグラムに応答して複数のバージョンネゴシエーションパケットを送信してはいけません。
See Section 6 for a description of the version negotiation process.
バージョンネゴシエーションプロセスの説明については、セクション6を参照してください。
An Initial packet uses long headers with a type value of 0x00. It carries the first CRYPTO frames sent by the client and server to perform key exchange, and it carries ACK frames in either direction.
初期パケットは、タイプ値0x00で長いヘッダを使用します。キー交換を実行するためにクライアントとサーバーによって送信された最初の暗号フレームを運び、どちらの方向にACKフレームを運びます。
Initial Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 0,
Reserved Bits (2),
Packet Number Length (2),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Token Length (i),
Token (..),
Length (i),
Packet Number (8..32),
Packet Payload (8..),
}
Figure 15: Initial Packet
図15：初期パケット
The Initial packet contains a long header as well as the Length and Packet Number fields; see Section 17.2. The first byte contains the Reserved and Packet Number Length bits; see also Section 17.2. Between the Source Connection ID and Length fields, there are two additional fields specific to the Initial packet.
初期パケットには、長さおよびパケット番号フィールドと同様に長いヘッダが含まれています。17.2節を参照してください。最初のバイトには、予約済みおよびパケット番号の長さのビットが含まれています。セクション17.2も参照してください。ソース接続IDと長さフィールドの間には、初期パケットに固有の2つの追加フィールドがあります。
Token Length: A variable-length integer specifying the length of the Token field, in bytes. This value is 0 if no token is present. Initial packets sent by the server MUST set the Token Length field to 0; clients that receive an Initial packet with a non-zero Token Length field MUST either discard the packet or generate a connection error of type PROTOCOL_VIOLATION.
トークン長さ：トークンフィールドの長さをバイト単位で指定する可変長整数。トークンが存在しない場合、この値は0です。サーバーによって送信された初期パケットは、トークン長フィールドを0に設定する必要があります。ゼロ以外のトークン長フィールドで初期パケットを受信するクライアントは、パケットを破棄するか、PROTOCOL_VIOLATION型の接続エラーを生成する必要があります。
Token: The value of the token that was previously provided in a Retry packet or NEW_TOKEN frame; see Section 8.1.
トークン：以前に再試行パケットまたはNEW_TOKENフレームで提供されていたトークンの値。セクション8.1を参照してください。
In order to prevent tampering by version-unaware middleboxes, Initial packets are protected with connection- and version-specific keys (Initial keys) as described in [QUIC-TLS]. This protection does not provide confidentiality or integrity against attackers that can observe packets, but it does prevent attackers that cannot observe packets from spoofing Initial packets.
バージョン情報 - アンウェアミドルボックスによる改ざんを防ぐために、初期パケットは[QUIC-TLS]で説明されているように、接続およびバージョン固有のキー（初期キー）で保護されています。この保護は、パケットを観察することができる攻撃者に対して機密性や完全性を提供しませんが、初期パケットのスプーフィンからパケットを観察できない攻撃者を防ぎます。
The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message. This includes all cases where a new packet containing the initial cryptographic message needs to be created, such as the packets sent after receiving a Retry packet; see Section 17.2.5.
クライアントとサーバーは、初期暗号化ハンドシェイクメッセージを含む任意のパケットの最初のパケットタイプを使用します。これには、再試行パケットを受信した後に送信されたパケットなど、初期暗号メッセージを含む新しいパケットを作成する必要があるすべてのケースが含まれます。17.2.5項を参照してください。
A server sends its first Initial packet in response to a client Initial. A server MAY send multiple Initial packets. The cryptographic key exchange could require multiple round trips or retransmissions of this data.
サーバーはクライアントのイニシャルに応答して最初の初期パケットを送信します。サーバーは複数の初期パケットを送信することができます。暗号鍵交換は、このデータの複数の往復または再送信を必要とする可能性があります。
The payload of an Initial packet includes a CRYPTO frame (or frames) containing a cryptographic handshake message, ACK frames, or both. PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also permitted. An endpoint that receives an Initial packet containing other frames can either discard the packet as spurious or treat it as a connection error.
初期パケットのペイロードは、暗号化ハンドシェイクメッセージ、ACKフレーム、またはその両方を含む暗号フレーム（またはフレーム）を含む。PING、PADDING、およびCONNECTION_CLOSE 0x1Cのフレームも許可されています。他のフレームを含む初期パケットを受信するエンドポイントは、パケットをスプリアスとして破棄するか、または接続エラーとして扱うことができる。
The first packet sent by a client always includes a CRYPTO frame that contains the start or all of the first cryptographic handshake message. The first CRYPTO frame sent always begins at an offset of 0; see Section 7.
クライアントによって送信された最初のパケットは常に最初の暗号化ハンドシェイクメッセージの開始またはすべてを含む暗号フレームを含む。送信された最初の暗号フレームは常に0のオフセットで始まります。セクション7を参照してください。
Note that if the server sends a TLS HelloRetryRequest (see Section 4.7 of [QUIC-TLS]), the client will send another series of Initial packets. These Initial packets will continue the cryptographic handshake and will contain CRYPTO frames starting at an offset matching the size of the CRYPTO frames sent in the first flight of Initial packets.
サーバーがTLS HelloretryRequestを送信する場合（[QUIC-TLS]のセクション4.7を参照）、クライアントは別のシリーズの最初のパケットを送信します。これらの初期パケットは暗号化ハンドシェイクを継続し、最初のパケットの最初のフライトで送信された暗号フレームのサイズを一致させるオフセットから始まる暗号フレームを含みます。
A client stops both sending and processing Initial packets when it sends its first Handshake packet. A server stops sending and processing Initial packets when it receives its first Handshake packet. Though packets might still be in flight or awaiting acknowledgment, no further Initial packets need to be exchanged beyond this point. Initial packet protection keys are discarded (see Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and congestion control state; see Section 6.4 of [QUIC-RECOVERY].
クライアントは、最初のハンドシェイクパケットを送信すると、初期パケットの送信と処理の両方を停止します。サーバーは、最初のハンドシェイクパケットを受信したときに初期パケットの送信と処理を停止します。パケットはまだ飛行中または承認を待っているかもしれませんが、この点を超えてそれ以上の最初のパケットを交換する必要はありません。初期パケット保護キーは、損失回復および輻輳制御状態とともに、破棄されます（[QUIC-TLSのセクション4.9.1）。[QUIC-RECOVERY]のセクション6.4を参照してください。
Any data in CRYPTO frames is discarded -- and no longer retransmitted -- when Initial keys are discarded.
初期キーが破棄されると、CRYPTOフレーム内のデータは破棄され、再送信されなくなります。
A 0-RTT packet uses long headers with a type value of 0x01, followed by the Length and Packet Number fields; see Section 17.2. The first byte contains the Reserved and Packet Number Length bits; see Section 17.2. A 0-RTT packet is used to carry "early" data from the client to the server as part of the first flight, prior to handshake completion. As part of the TLS handshake, the server can accept or reject this early data.
0-RTTパケットは、タイプ値0x01の長さのヘッダーを使用し、その後に長さとパケット番号フィールドが続きます。17.2節を参照してください。最初のバイトには、予約済みおよびパケット番号の長さのビットが含まれています。17.2節を参照してください。ハンドシェイクの完了の前に、クライアントからサーバーへの「早期」データを実行するために、0-RTTパケットが使用されます。TLSハンドシェイクの一部として、サーバーはこの初期のデータを受け入れるか拒否できます。
See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its limitations.
0-RTTデータとその制限については、[TLS13]のセクション2.3を参照してください。
0-RTT Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 1,
Reserved Bits (2),
Packet Number Length (2),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Length (i),
Packet Number (8..32),
Packet Payload (8..),
}
Figure 16: 0-RTT Packet
図16：0-RTTパケット
Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected packets.
0-RTT保護パケットのパケット番号は、1 RTT保護パケットと同じスペースを使用します。
After a client receives a Retry packet, 0-RTT packets are likely to have been lost or discarded by the server. A client SHOULD attempt to resend data in 0-RTT packets after it sends a new Initial packet. New packet numbers MUST be used for any new packets that are sent; as described in Section 17.2.5.3, reusing packet numbers could compromise packet protection.
クライアントがリトライパケットを受信した後、0-RTTパケットはサーバーによって失われたか破棄された可能性があります。クライアントは、新しい初期パケットを送信した後に0-RTTパケットでデータを再送信しようとします。送信された新しいパケットに新しいパケット番号を使用する必要があります。セクション17.2.5.3で説明されているように、パケット番号の再利用はパケット保護を危険にさらす可能性があります。
A client only receives acknowledgments for its 0-RTT packets once the handshake is complete, as defined in Section 4.1.1 of [QUIC-TLS].
[QUIC-TLS]のセクション4.1.1で定義されているように、ハンドシェイクが完了すると、クライアントは0-RTTパケットの承認を受信します。
A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server. This means that 0-RTT packets cannot contain any response to frames from 1-RTT packets. For instance, a client cannot send an ACK frame in a 0-RTT packet, because that can only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.
サーバーから1-RTTパケットの処理を開始すると、クライアントは0-RTTパケットを送信してはなりません。これは、0-RTTパケットに1-RTTパケットからフレームに対する応答を含めることができないことを意味します。たとえば、クライアントは0-RTTパケットにACKフレームを送信できません。なぜなら、1-RTTパケットのみを確認できます。1-RTTパケットの確認応答は1 RTTパケットで搬送されなければなりません。
A server SHOULD treat a violation of remembered limits (Section 7.4.1) as a connection error of an appropriate type (for instance, a FLOW_CONTROL_ERROR for exceeding stream data limits).
サーバーは、適切なタイプの接続エラーとして、記憶された制限（7.4.1項）の違反（例えば、ストリームデータ制限を超えるためのFLOW_CONTROL_ERROR）を扱います。
A Handshake packet uses long headers with a type value of 0x02, followed by the Length and Packet Number fields; see Section 17.2. The first byte contains the Reserved and Packet Number Length bits; see Section 17.2. It is used to carry cryptographic handshake messages and acknowledgments from the server and client.
ハンドシェイクパケットは、タイプ値0x02の長さのヘッダーを使用し、その後に長さとパケット番号フィールドが続きます。17.2節を参照してください。最初のバイトには、予約済みおよびパケット番号の長さのビットが含まれています。17.2節を参照してください。それは、サーバーとクライアントから暗号化されたハンドシェイクメッセージと確認応答を携帯するために使用されます。
Handshake Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 2,
Reserved Bits (2),
Packet Number Length (2),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Length (i),
Packet Number (8..32),
Packet Payload (8..),
}
Figure 17: Handshake Protected Packet
図17：ハンドシェイク保護パケット
Once a client has received a Handshake packet from a server, it uses Handshake packets to send subsequent cryptographic handshake messages and acknowledgments to the server.
クライアントがサーバーからハンドシェイクパケットを受信したら、ハンドシェイクパケットを使用して後続の暗号ハンドシェイクメッセージと承認をサーバーに送信します。
The Destination Connection ID field in a Handshake packet contains a connection ID that is chosen by the recipient of the packet; the Source Connection ID includes the connection ID that the sender of the packet wishes to use; see Section 7.2.
ハンドシェイクパケット内の宛先接続IDフィールドには、パケットの受信者によって選択される接続IDが含まれています。ソース接続IDには、パケットの送信者が使用したい接続IDが含まれています。セクション7.2を参照してください。
Handshake packets have their own packet number space, and thus the first Handshake packet sent by a server contains a packet number of 0.
ハンドシェイクパケットには独自のパケット番号スペースがあり、したがってサーバーによって送信された最初のハンドシェイクパケットにはパケット番号が含まれています。
The payload of this packet contains CRYPTO frames and could contain PING, PADDING, or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt of Handshake packets with other frames as a connection error of type PROTOCOL_VIOLATION.
このパケットのペイロードには暗号フレームが含まれており、PING、パディング、またはACKフレームを含めることができます。ハンドシェイクパケットには、Type 0x1cのCONNECTION_CLOSEフレームを含めることができます。エンドポイントは、PROTOCOL_VIOLATION型タイプの接続エラーとして、ハンドシェイクパケットの受信を他のフレームと扱う必要があります。
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames for Handshake packets is discarded -- and no longer retransmitted -- when Handshake protection keys are discarded.
初期パケット（セクション17.2.2.1を参照）と同様に、ハンドシェイク保護キーが破棄されると、ハンドシェイクパケットのCRYPTOフレーム内のデータは破棄され、再送信されなくなります。
As shown in Figure 18, a Retry packet uses a long packet header with a type value of 0x03. It carries an address validation token created by the server. It is used by a server that wishes to perform a retry; see Section 8.1.
図18に示すように、リトライパケットは、タイプ値0x03を有する長いパケットヘッダを使用する。サーバーによって作成されたアドレス検証トークンを搭載しています。再試行を実行したいサーバーによって使用されます。セクション8.1を参照してください。
Retry Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 3,
Unused (4),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Retry Token (..),
Retry Integrity Tag (128),
}
Figure 18: Retry Packet
図18：再試行パケット
A Retry packet does not contain any protected fields. The value in the Unused field is set to an arbitrary value by the server; a client MUST ignore these bits. In addition to the fields from the long header, it contains these additional fields:
再試行パケットには保護されたフィールドが含まれていません。未使用フィールドの値は、サーバーによって任意の値に設定されます。クライアントはこれらのビットを無視する必要があります。ロングヘッダーのフィールドに加えて、これらの追加フィールドが含まれています。
Retry Token: An opaque token that the server can use to validate the client's address.
リトライトークン：サーバーがクライアントのアドレスを検証するために使用できる不透明なトークン。
Retry Integrity Tag: Defined in Section 5.8 ("Retry Packet Integrity") of [QUIC-TLS].
Integrity Tag：[QUIC-TLS]のセクション5.8（「リトライパケットの完全性」）で定義されています。
The server populates the Destination Connection ID with the connection ID that the client included in the Source Connection ID of the Initial packet.
サーバは、クライアントが初期パケットの送信元接続IDに含まれている接続IDを宛先接続IDに移行します。
The server includes a connection ID of its choice in the Source Connection ID field. This value MUST NOT be equal to the Destination Connection ID field of the packet sent by the client. A client MUST discard a Retry packet that contains a Source Connection ID field that is identical to the Destination Connection ID field of its Initial packet. The client MUST use the value from the Source Connection ID field of the Retry packet in the Destination Connection ID field of subsequent packets that it sends.
サーバーには、Source Connection IDフィールドにその選択の接続IDが含まれています。この値は、クライアントによって送信されたパケットの宛先接続IDフィールドと同じでなければなりません。クライアントは、初期パケットの宛先接続IDフィールドと同じ送信元接続IDフィールドを含む再試行パケットを破棄する必要があります。クライアントは、送信した後続のパケットの宛先接続IDフィールドに、再試行パケットのソース接続IDフィールドから値を使用する必要があります。
A server MAY send Retry packets in response to Initial and 0-RTT packets. A server can either discard or buffer 0-RTT packets that it receives. A server can send multiple Retry packets as it receives Initial or 0-RTT packets. A server MUST NOT send more than one Retry packet in response to a single UDP datagram.
サーバは、初期および0 - RTTパケットに応答して再試行パケットを送信することができる。サーバーは、受信した0-RTTパケットを破棄またはバッファすることができます。サーバーは、初期または0-RTTパケットを受信すると、複数の再試行パケットを送信できます。サーバーは、単一のUDPデータグラムに応答して複数の再試行パケットを送信してはいけません。
A client MUST accept and process at most one Retry packet for each connection attempt. After the client has received and processed an Initial or Retry packet from the server, it MUST discard any subsequent Retry packets that it receives.
接続試行ごとに、クライアントはほとんどの再試行パケットを受け入れて処理する必要があります。クライアントがサーバーから初期パケットまたは再試行パケットを受信して処理した後、それが受信した後続の再試行パケットを破棄する必要があります。
Clients MUST discard Retry packets that have a Retry Integrity Tag that cannot be validated; see Section 5.8 of [QUIC-TLS]. This diminishes an attacker's ability to inject a Retry packet and protects against accidental corruption of Retry packets. A client MUST discard a Retry packet with a zero-length Retry Token field.
クライアントは、検証できない再試行完全性タグを持つリトライパケットを廃棄する必要があります。[QUIC-TLS]のセクション5.8を参照してください。これにより、攻撃者が再試行パケットを挿入し、再試行パケットの偶発的な破損から保護する能力が低下します。クライアントは、長さゼロのリトライトークンフィールドを持つリトライパケットを破棄する必要があります。
The client responds to a Retry packet with an Initial packet that includes the provided Retry token to continue connection establishment.
クライアントは、接続確立を継続するために提供された再試行トークンを含む初期パケットを含む再試行パケットに応答する。
A client sets the Destination Connection ID field of this Initial packet to the value from the Source Connection ID field in the Retry packet. Changing the Destination Connection ID field also results in a change to the keys used to protect the Initial packet. It also sets the Token field to the token provided in the Retry packet. The client MUST NOT change the Source Connection ID because the server could include the connection ID as part of its token validation logic; see Section 8.1.4.
クライアントは、この初期パケットの宛先接続IDフィールドを再試行パケットの[ソース接続ID]フィールドから値に設定します。[宛先接続ID]フィールドを変更すると、初期パケットの保護に使用されるキーに変更が発生します。また、リトライパケットに提供されているトークンにトークンフィールドを設定します。サーバーにはトークン検証ロジックの一部として接続IDを含めることができるため、クライアントはソース接続IDを変更してはなりません。セクション8.1.4を参照してください。
A Retry packet does not include a packet number and cannot be explicitly acknowledged by a client.
再試行パケットにはパケット番号は含まれず、クライアントによって明示的に認識されません。
Subsequent Initial packets from the client include the connection ID and token values from the Retry packet. The client copies the Source Connection ID field from the Retry packet to the Destination Connection ID field and uses this value until an Initial packet with an updated value is received; see Section 7.2. The value of the Token field is copied to all subsequent Initial packets; see Section 8.1.2.
クライアントからの後続の初期パケットには、リトライパケットからの接続IDとトークン値が含まれます。クライアントは、ソース接続IDフィールドを再試行パケットから宛先接続IDフィールドにコピーし、更新された値の初期パケットが受信されるまでこの値を使用する。セクション7.2を参照してください。トークンフィールドの値は、後続のすべての初期パケットにコピーされます。セクション8.1.2を参照してください。
Other than updating the Destination Connection ID and Token fields, the Initial packet sent by the client is subject to the same restrictions as the first Initial packet. A client MUST use the same cryptographic handshake message it included in this packet. A server MAY treat a packet that contains a different cryptographic handshake message as a connection error or discard it. Note that including a Token field reduces the available space for the cryptographic handshake message, which might result in the client needing to send multiple Initial packets.
宛先接続IDおよびトークンフィールドを更新する以外に、クライアントによって送信された初期パケットは、最初の初期パケットと同じ制限を受ける。クライアントは、このパケットに含まれているのと同じ暗号化ハンドシェイクメッセージを使用する必要があります。サーバは、異なる暗号化ハンドシェイクメッセージを含むパケットを接続エラーとして扱うか、またはそれを破棄することができる。トークンフィールドを含めることで、暗号化ハンドシェイクメッセージの使用可能なスペースが減少することに注意してください。これにより、クライアントが複数の初期パケットを送信する必要がある可能性があります。
A client MAY attempt 0-RTT after receiving a Retry packet by sending 0-RTT packets to the connection ID provided by the server.
クライアントは、0-RTTパケットをサーバによって提供された接続IDに送信することによって再試行パケットを受信した後に0 - RTTを試みることができる。
A client MUST NOT reset the packet number for any packet number space after processing a Retry packet. In particular, 0-RTT packets contain confidential information that will most likely be retransmitted on receiving a Retry packet. The keys used to protect these new 0-RTT packets will not change as a result of responding to a Retry packet. However, the data sent in these packets could be different than what was sent earlier. Sending these new packets with the same packet number is likely to compromise the packet protection for those packets because the same key and nonce could be used to protect different content. A server MAY abort the connection if it detects that the client reset the packet number.
再試行パケットを処理した後、クライアントはパケット番号スペースのパケット番号をリセットしてはいけません。特に、0-RTTパケットには、リトライパケットを受信すると再送信される可能性が高い機密情報が含まれています。これらの新しい0-RTTパケットを保護するために使用されるキーは、再試行パケットに応答した結果として変わりません。ただし、これらのパケットで送信されたデータは、以前に送信されたものとは異なる可能性があります。同じパケット番号を持つこれらの新しいパケットを送信することは、異なるコンテンツを保護するために同じキーとNONCEを使用できるため、それらのパケットのパケット保護を犠牲にする可能性があります。クライアントがパケット番号をリセットしたことを検出した場合、サーバーは接続を中止する可能性があります。
The connection IDs used in Initial and Retry packets exchanged between client and server are copied to the transport parameters and validated as described in Section 7.3.
クライアントとサーバ間で交換される初期および再試行パケットで使用されている接続IDは、トランスポートパラメータにコピーされ、7.3項で説明されているように検証されます。
This version of QUIC defines a single packet type that uses the short packet header.
このバージョンのQUICは、短いパケットヘッダーを使用する単一のパケットタイプを定義します。
A 1-RTT packet uses a short packet header. It is used after the version and 1-RTT keys are negotiated.
1-RTTパケットは短いパケットヘッダーを使用します。バージョンと1-RTTキーがネゴシエートされた後に使用されます。
1-RTT Packet {
Header Form (1) = 0,
Fixed Bit (1) = 1,
Spin Bit (1),
Reserved Bits (2),
Key Phase (1),
Packet Number Length (2),
Destination Connection ID (0..160),
Packet Number (8..32),
Packet Payload (8..),
}
Figure 19: 1-RTT Packet
図19：1-RTTパケット
1-RTT packets contain the following fields:
1-RTTパケットには、次のフィールドが含まれています。
Header Form: The most significant bit (0x80) of byte 0 is set to 0 for the short header.
ヘッダーフォーム：短いヘッダーには、バイト0の最上位ビット（0x80）が0に設定されています。
Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets containing a zero value for this bit are not valid packets in this version and MUST be discarded. A value of 1 for this bit allows QUIC to coexist with other protocols; see [RFC7983].
固定ビット：バイト0の次のビット（0x40）が1に設定されています。このビットのゼロ値を含むパケットは、このバージョンでは無効なパケットではなく、破棄する必要があります。このビットの値1の値は、QUICが他のプロトコルと共存することを可能にします。[RFC7983]を参照してください。
Spin Bit: The third most significant bit (0x20) of byte 0 is the latency spin bit, set as described in Section 17.4.
スピンビット：バイト0の3番目の最上位ビット（0x20）はレイテンシスピンビットで、セクション17.4で説明されているように設定されています。
Reserved Bits: The next two bits (those with a mask of 0x18) of byte 0 are reserved. These bits are protected using header protection; see Section 5.4 of [QUIC-TLS]. The value included prior to protection MUST be set to 0. An endpoint MUST treat receipt of a packet that has a non-zero value for these bits, after removing both packet and header protection, as a connection error of type PROTOCOL_VIOLATION. Discarding such a packet after only removing header protection can expose the endpoint to attacks; see Section 9.5 of [QUIC-TLS].
予約ビット：バイト0の次の2ビット（マスク0x18のもの）が予約されています。これらのビットはヘッダー保護を使用して保護されています。[QUIC-TLS]のセクション5.4を参照してください。保護の前に含まれている値は0に設定する必要があります。エンドポイントは、パケットとヘッダー保護の両方を削除した後、PROTOCOL_VIOLATION型の接続エラーとして、ゼロ以外の値を持つパケットの受信を扱う必要があります。ヘッダー保護を削除した後にそのようなパケットを破棄すると、エンドポイントが攻撃にさらされる可能性があります。[QUIC-TLS]のセクション9.5を参照してください。
Key Phase: The next bit (0x04) of byte 0 indicates the key phase, which allows a recipient of a packet to identify the packet protection keys that are used to protect the packet. See [QUIC-TLS] for details. This bit is protected using header protection; see Section 5.4 of [QUIC-TLS].
キーフェーズ：バイト0の次のビット（0x04）はキーフェーズを示します。これにより、パケットの受信者がパケットの保護に使用されるパケット保護キーを識別できます。詳細は[QUIC-TLS]を参照してください。このビットはヘッダー保護を使用して保護されています。[QUIC-TLS]のセクション5.4を参照してください。
Packet Number Length: The least significant two bits (those with a mask of 0x03) of byte 0 contain the length of the Packet Number field, encoded as an unsigned two-bit integer that is one less than the length of the Packet Number field in bytes. That is, the length of the Packet Number field is the value of this field plus one. These bits are protected using header protection; see Section 5.4 of [QUIC-TLS].
パケット番号の長さ：バイト0の最下位2ビット（マスク0x03のマスク）は、パケット番号フィールドの長さを含み、パケット番号フィールドの長さよりも1つ下の符号なし2ビット整数としてエンコードされます。バイトつまり、パケット番号フィールドの長さはこのフィールドの値と1つの値です。これらのビットはヘッダー保護を使用して保護されています。[QUIC-TLS]のセクション5.4を参照してください。
Destination Connection ID: The Destination Connection ID is a connection ID that is chosen by the intended recipient of the packet. See Section 5.1 for more details.
宛先接続ID：宛先接続IDは、パケットの意図された受信者によって選択された接続IDです。詳細については5.1項を参照してください。
Packet Number: The Packet Number field is 1 to 4 bytes long. The packet number is protected using header protection; see Section 5.4 of [QUIC-TLS]. The length of the Packet Number field is encoded in Packet Number Length field. See Section 17.1 for details.
パケット番号：パケット番号フィールドは1~4バイトの長さです。パケット番号はヘッダー保護を使用して保護されています。[QUIC-TLS]のセクション5.4を参照してください。パケット番号フィールドの長さは、Packet Number Lengthフィールドにエンコードされます。詳細については17.1項を参照してください。
Packet Payload: 1-RTT packets always include a 1-RTT protected payload.
パケットペイロード：1-RTTパケットには常に1 RTT保護ペイロードが含まれています。
The header form bit and the Destination Connection ID field of a short header packet are version independent. The remaining fields are specific to the selected QUIC version. See [QUIC-INVARIANTS] for details on how packets from different versions of QUIC are interpreted.
短いヘッダーパケットのヘッダーフォームビットと宛先接続IDフィールドは、バージョンに依存しません。残りのフィールドは、選択されたQUICバージョンに固有のものです。さまざまなバージョンのQUICからのパケットがどのように解釈されるかについての詳細については、[QUIC-INVARIANTS]を参照してください。
The latency spin bit, which is defined for 1-RTT packets (Section 17.3.1), enables passive latency monitoring from observation points on the network path throughout the duration of a connection. The server reflects the spin value received, while the client "spins" it after one RTT. On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection.
1-RTTパケットに定義されているレイテンシスピンビット（セクション17.3.1）は、接続の期間を通してネットワーク経路上の観測点からの受動待ち時間監視を可能にします。サーバーは受信したスピン値を反映し、クライアントは1つのRTTの後にそれを「スピン」します。オンパスオブザーバは、接続の終了阻止率を推定するために、イベントの2つのスピンビットトグルイベント間の時間を測定できます。
The spin bit is only present in 1-RTT packets, since it is possible to measure the initial RTT of a connection by observing the handshake. Therefore, the spin bit is available after version negotiation and connection establishment are completed. On-path measurement and use of the latency spin bit are further discussed in [QUIC-MANAGEABILITY].
ハンドシェイクを観察することによって接続の初期RTTを測定することが可能であるため、スピンビットは1-RTTパケットにのみ存在する。したがって、バージョン交渉後にスピンビットは利用可能で、接続確立が完了した後に利用可能です。待ち時間スピンビットのオンパス測定と使用は、[QUIC管理性]でさらに説明される。
The spin bit is an OPTIONAL feature of this version of QUIC. An endpoint that does not support this feature MUST disable it, as defined below.
スピンビットはこのバージョンのQUICのオプション機能です。以下に定義されているように、この機能をサポートしていないエンドポイントは無効にする必要があります。
Each endpoint unilaterally decides if the spin bit is enabled or disabled for a connection. Implementations MUST allow administrators of clients and servers to disable the spin bit either globally or on a per-connection basis. Even when the spin bit is not disabled by the administrator, endpoints MUST disable their use of the spin bit for a random selection of at least one in every 16 network paths, or for one in every 16 connection IDs, in order to ensure that QUIC connections that disable the spin bit are commonly observed on the network. As each endpoint disables the spin bit independently, this ensures that the spin bit signal is disabled on approximately one in eight network paths.
各エンドポイントは、スピンビットが接続に対して有効または無効になっているかどうかを一方的に決定します。実装では、クライアントやサーバーの管理者がグローバルにまたは接続ごとにスピンビットを無効にする必要があります。スピンビットが管理者によって無効になっていなくても、エンドポイントは、QUICが確実にするために、16個のネットワークパスごとに少なくとも1つのランダムな選択のスピンビットの使用を無効にする必要があります。スピンビットを無効にする接続は、ネットワーク上で一般的に観察されます。各エンドポイントがスピンビットを独立して無効にしているため、スピンビット信号が8つのネットワーク経路で約1で無効にされます。
When the spin bit is disabled, endpoints MAY set the spin bit to any value and MUST ignore any incoming value. It is RECOMMENDED that endpoints set the spin bit to a random value either chosen independently for each packet or chosen independently for each connection ID.
スピンビットが無効になっている場合、エンドポイントはスピンビットを任意の値に設定し、着信値を無視する必要があります。エンドポイントは、各パケットごとに独立して選択された、または接続IDごとに独立して選択されたかのいずれかのランダム値にスピンビットを設定することをお勧めします。
If the spin bit is enabled for the connection, the endpoint maintains a spin value for each network path and sets the spin bit in the packet header to the currently stored value when a 1-RTT packet is sent on that path. The spin value is initialized to 0 in the endpoint for each network path. Each endpoint also remembers the highest packet number seen from its peer on each path.
スピンビットが接続に対して有効になっている場合、エンドポイントは各ネットワークパスのスピン値を維持し、1-RTTパケットがそのパスで送信されると、パケットヘッダーのスピンビットを現在格納されている値に設定します。スピン値は、各ネットワークパスのエンドポイントで0に初期化されます。各エンドポイントはまた、各パスのピアから見た最高のパケット番号を記憶します。
When a server receives a 1-RTT packet that increases the highest packet number seen by the server from the client on a given network path, it sets the spin value for that path to be equal to the spin bit in the received packet.
サーバーが、特定のネットワークパス上のクライアントからサーバーから見られた最高のパケット番号を増加させる1-RTTパケットを受信すると、受信したパケットのスピンビットと等しくなるようにそのパスのスピン値を設定します。
When a client receives a 1-RTT packet that increases the highest packet number seen by the client from the server on a given network path, it sets the spin value for that path to the inverse of the spin bit in the received packet.
クライアントが、特定のネットワークパス上のサーバーからクライアントから見た最高のパケット番号を増加させる1-RTTパケットを受信すると、受信したパケット内のスピンビットの逆数へのそのパスのスピン値を設定します。
An endpoint resets the spin value for a network path to 0 when changing the connection ID being used on that network path.
エンドポイントは、そのネットワークパスで使用されている接続IDを変更するときに、ネットワークパスのスピン値を0にリセットします。
The extension_data field of the quic_transport_parameters extension defined in [QUIC-TLS] contains the QUIC transport parameters. They are encoded as a sequence of transport parameters, as shown in Figure 20:
[QUIC-TLS]で定義されているQUIC_TRANSPORT_PARAMETERS拡張機能のextension_dataフィールドには、QUICトランスポートパラメータが含まれています。図20に示すように、それらは一連のトランスポートパラメータとしてエンコードされています。
Transport Parameters {
Transport Parameter (..) ...,
}
Figure 20: Sequence of Transport Parameters
図20：輸送パラメータのシーケンス
Each transport parameter is encoded as an (identifier, length, value) tuple, as shown in Figure 21:
各トランスポートパラメータは、図21に示すように、（ID、長さ、値）タプルとしてエンコードされています。
Transport Parameter {
Transport Parameter ID (i),
Transport Parameter Length (i),
Transport Parameter Value (..),
}
Figure 21: Transport Parameter Encoding
図21：トランスポートパラメータエンコーディング
The Transport Parameter Length field contains the length of the Transport Parameter Value field in bytes.
トランスポートパラメータ長フィールドには、トランスポートパラメータ値フィールドの長さがバイト単位で含まれています。
QUIC encodes transport parameters into a sequence of bytes, which is then included in the cryptographic handshake.
QUICはトランスポートパラメータを一連のバイトにエンコードします。これは暗号化ハンドシェイクに含まれます。
Transport parameters with an identifier of the form "31 * N + 27" for integer values of N are reserved to exercise the requirement that unknown transport parameters be ignored. These transport parameters have no semantics and can carry arbitrary values.
nの整数値の場合は、nの識別子の識別子を指定したトランスポートパラメータは、未知のトランスポートパラメータが無視されるという要件を実行するために予約されています。これらの輸送パラメータは意味論を持たず、任意の値を搬送することができます。
This section details the transport parameters defined in this document.
このセクションでは、このドキュメントで定義されているトランスポートパラメータについて詳しく説明します。
Many transport parameters listed here have integer values. Those transport parameters that are identified as integers use a variable-length integer encoding; see Section 16. Transport parameters have a default value of 0 if the transport parameter is absent, unless otherwise stated.
ここにリストされている多くのトランスポートパラメータは整数値を持ちます。整数として識別されるそれらのトランスポートパラメータは、可変長整数エンコーディングを使用します。特に明記しない限り、トランスポートパラメータはデフォルト値0を持ちます。
The following transport parameters are defined:
次のトランスポートパラメータが定義されています。
original_destination_connection_id (0x00): This parameter is the value of the Destination Connection ID field from the first Initial packet sent by the client; see Section 7.3. This transport parameter is only sent by a server.
original_destination_connection_id（0x00）：このパラメータは、クライアントによって送信された最初の初期パケットからの宛先接続IDフィールドの値です。7.3節を参照してください。このトランスポートパラメータはサーバーによってのみ送信されます。
max_idle_timeout (0x01): The maximum idle timeout is a value in milliseconds that is encoded as an integer; see (Section 10.1). Idle timeout is disabled when both endpoints omit this transport parameter or specify a value of 0.
max_idle_timeout（0x01）：最大アイドルタイムアウトは、整数としてエンコードされているミリ秒単位の値です。（10.1項）を参照してください。両方のエンドポイントがこのトランスポートパラメータを省略するか0の値を指定した場合、アイドルタイムアウトは無効になります。
stateless_reset_token (0x02): A stateless reset token is used in verifying a stateless reset; see Section 10.3. This parameter is a sequence of 16 bytes. This transport parameter MUST NOT be sent by a client but MAY be sent by a server. A server that does not send this transport parameter cannot use stateless reset (Section 10.3) for the connection ID negotiated during the handshake.
stateless_reset_token（0x02）：ステートレスリセットの検証にはステートレスリセットトークンが使用されます。セクション10.3を参照してください。このパラメータは16バイトのシーケンスです。このトランスポートパラメータはクライアントによって送信されてはいけませんが、サーバーによって送信される可能性があります。このトランスポートパラメータを送信しないサーバーは、ハンドシェイク中にネゴシエートされた接続IDのステートレスリセット（セクション10.3）を使用できません。
max_udp_payload_size (0x03): The maximum UDP payload size parameter is an integer value that limits the size of UDP payloads that the endpoint is willing to receive. UDP datagrams with payloads larger than this limit are not likely to be processed by the receiver.
max_udp_payload_size（0x03）：最大UDPペイロードサイズパラメータは、エンドポイントが受信しても構わないと思われるUDPペイロードのサイズを制限する整数値です。この制限よりも大きいペイロードを持つUDPデータグラムは、受信者によって処理される可能性は低いです。
The default for this parameter is the maximum permitted UDP payload of 65527. Values below 1200 are invalid.
このパラメータのデフォルトは、65527の最大許容UDPペイロードです.1200以下の値は無効です。
This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the endpoint and not the path; see Section 14. It is expected that this is the space an endpoint dedicates to holding incoming packets.
この制限は、パスMTUと同じ方法でデータグラム・サイズに対する追加の制約として機能しますが、パスではなくエンドポイントのプロパティです。セクション14を参照してください。これは、着信パケットを保持するためのエンドポイントが専用のスペースであると予想されます。
initial_max_data (0x04): The initial maximum data parameter is an integer value that contains the initial value for the maximum amount of data that can be sent on the connection. This is equivalent to sending a MAX_DATA (Section 19.9) for the connection immediately after completing the handshake.
initial_max_data（0x04）：初期最大データパラメータは、接続で送信できる最大量のデータ量の初期値を含む整数値です。これは、ハンドシェイクを完了した直後の接続のMAX_DATA（セクション19.9）を送信するのと同じです。
initial_max_stream_data_bidi_local (0x05): This parameter is an integer value specifying the initial flow control limit for locally initiated bidirectional streams. This limit applies to newly created bidirectional streams opened by the endpoint that sends the transport parameter. In client transport parameters, this applies to streams with an identifier with the least significant two bits set to 0x00; in server transport parameters, this applies to streams with the least significant two bits set to 0x01.
initial_max_stream_data_bidi_local（0x05）：このパラメータは、ローカルに開始された双方向ストリームの初期フロー制御制限を指定する整数値です。この制限は、トランスポートパラメータを送信するエンドポイントによって開かれた新しく作成された双方向ストリームに適用されます。クライアントトランスポートパラメータでは、これは0x00に設定された最下位2ビットを持つ識別子を持つストリームに適用されます。サーバーのトランスポートパラメータでは、これは0x01に設定されている最下位2ビットのストリームに適用されます。
initial_max_stream_data_bidi_remote (0x06): This parameter is an integer value specifying the initial flow control limit for peer-initiated bidirectional streams. This limit applies to newly created bidirectional streams opened by the endpoint that receives the transport parameter. In client transport parameters, this applies to streams with an identifier with the least significant two bits set to 0x01; in server transport parameters, this applies to streams with the least significant two bits set to 0x00.
initial_max_stream_data_bidi_remote（0x06）：このパラメータは、ピア開始双方向ストリームの初期フロー制御制限を指定する整数値です。この制限は、トランスポートパラメータを受信するエンドポイントによって開かれた新しく作成された双方向ストリームに適用されます。クライアントトランスポートパラメータでは、これは0x01に設定されている最下位2ビットを持つ識別子を持つストリームに適用されます。サーバートランスポートパラメータでは、これは最下位2ビットが0x00に設定されているストリームに適用されます。
initial_max_stream_data_uni (0x07): This parameter is an integer value specifying the initial flow control limit for unidirectional streams. This limit applies to newly created unidirectional streams opened by the endpoint that receives the transport parameter. In client transport parameters, this applies to streams with an identifier with the least significant two bits set to 0x03; in server transport parameters, this applies to streams with the least significant two bits set to 0x02.
initial_max_stream_data_uni（0x07）：このパラメータは、一方向ストリームの初期フロー制御制限を指定する整数値です。この制限は、トランスポートパラメータを受信するエンドポイントによって開かれた新しく作成された一方向ストリームに適用されます。クライアントトランスポートパラメータでは、これは0x03に設定されている最下位2ビットを持つ識別子を持つストリームに適用されます。サーバーのトランスポートパラメータでは、これは0x02に設定されている最下位2ビットのストリームに適用されます。
initial_max_streams_bidi (0x08): The initial maximum bidirectional streams parameter is an integer value that contains the initial maximum number of bidirectional streams the endpoint that receives this transport parameter is permitted to initiate. If this parameter is absent or zero, the peer cannot open bidirectional streams until a MAX_STREAMS frame is sent. Setting this parameter is equivalent to sending a MAX_STREAMS (Section 19.11) of the corresponding type with the same value.
initial_max_streams_bidi（0x08）：初期双方向Streamsパラメータは、双方向ストリームの初期最大数を含む整数値で、このトランスポートパラメータを受信するエンドポイントが開始されます。このパラメータが存在しない場合、またはゼロの場合、MAX_STREAMSフレームが送信されるまでピアは双方向ストリームを開くことができません。このパラメータを設定することは、対応するタイプのMAX_STREAMS（セクション19.11）を同じ値で送信するのと同じです。
initial_max_streams_uni (0x09): The initial maximum unidirectional streams parameter is an integer value that contains the initial maximum number of unidirectional streams the endpoint that receives this transport parameter is permitted to initiate. If this parameter is absent or zero, the peer cannot open unidirectional streams until a MAX_STREAMS frame is sent. Setting this parameter is equivalent to sending a MAX_STREAMS (Section 19.11) of the corresponding type with the same value.
initial_max_streams_uni（0x09）：初期最大単一rementional streamsパラメータは、初期最大数の単一の最大数を含む整数値で、このトランスポートパラメータを受信するエンドポイントが開始されます。このパラメータが存在しない場合、またはゼロの場合、MAX_STREAMSフレームが送信されるまでピアは一方向ストリームを開くことができません。このパラメータを設定することは、対応するタイプのMAX_STREAMS（セクション19.11）を同じ値で送信するのと同じです。
ack_delay_exponent (0x0a): The acknowledgment delay exponent is an integer value indicating an exponent used to decode the ACK Delay field in the ACK frame (Section 19.3). If this value is absent, a default value of 3 is assumed (indicating a multiplier of 8). Values above 20 are invalid.
ack_delay_exponent（0x0a）：確認応答遅延指数は、ACKフレーム内のACK遅延フィールドを復号するために使用される指数を示す整数値です（セクション19.3）。この値が存在しない場合は、デフォルト値3が想定されます（8の乗数を示す）。20以上の値は無効です。
max_ack_delay (0x0b): The maximum acknowledgment delay is an integer value indicating the maximum amount of time in milliseconds by which the endpoint will delay sending acknowledgments. This value SHOULD include the receiver's expected delays in alarms firing. For example, if a receiver sets a timer for 5ms and alarms commonly fire up to 1ms late, then it should send a max_ack_delay of 6ms. If this value is absent, a default of 25 milliseconds is assumed. Values of 2^14 or greater are invalid.
max_ack_delay（0x0B）：最大確認応答遅延は、エンドポイントが承認を送信するのを遅らせるミリ秒単位の最大時間を示す整数値です。この値には、アラーム発射の受信者の予想される遅延を含める必要があります。たとえば、受信側が5msのタイマーを5msとアラームを遅くすると、遅く1msまでのタイマーを設定した場合、6msのmax_ack_delayを送信する必要があります。この値が存在しない場合は、デフォルトの25ミリ秒が想定されます。2^14以上の値は無効です。
disable_active_migration (0x0c): The disable active migration transport parameter is included if the endpoint does not support active connection migration (Section 9) on the address being used during the handshake. An endpoint that receives this transport parameter MUST NOT use a new local address when sending to the address that the peer used during the handshake. This transport parameter does not prohibit connection migration after a client has acted on a preferred_address transport parameter. This parameter is a zero-length value.
disable_active_migration（0x0c）：ハンドシェイク中に使用されているアドレスのアクティブな接続移行（セクション9）がサポートされていない場合は、アクティブな移行トランスポートパラメータを無効にします。このトランスポートパラメータを受信するエンドポイントは、ハンドシェイク中に使用したアドレスに送信するときに新しいローカルアドレスを使用してはいけません。このトランスポートパラメータは、クライアントが推奨されている推奨トランスポートパラメータに行動した後に接続移行を禁止しません。このパラメータは長さゼロの値です。
preferred_address (0x0d): The server's preferred address is used to effect a change in server address at the end of the handshake, as described in Section 9.6. This transport parameter is only sent by a server. Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or [::]:0) for the other family. IP addresses are encoded in network byte order.
preferse_address（0x0d）：セクション9.6で説明されているように、サーバーの優先アドレスは、ハンドシェイクの最後にあるサーバーアドレスの変更を実行するために使用されます。このトランスポートパラメータはサーバーによってのみ送信されます。サーバーは、他のファミリのためにすべてのゼロのアドレスとポート（0.0.0.0:0 または [::]:0）を送信することによって、あるアドレスファミリの優先アドレスのみを送信することを選択できます。IPアドレスはネットワークバイト順にエンコードされています。
The preferred_address transport parameter contains an address and port for both IPv4 and IPv6. The four-byte IPv4 Address field is followed by the associated two-byte IPv4 Port field. This is followed by a 16-byte IPv6 Address field and two-byte IPv6 Port field. After address and port pairs, a Connection ID Length field describes the length of the following Connection ID field. Finally, a 16-byte Stateless Reset Token field includes the stateless reset token associated with the connection ID. The format of this transport parameter is shown in Figure 22 below.
推奨されているものは、IPv4とIPv6の両方のアドレスとポートを含みます。4バイトのIPv4アドレスフィールドの後には、関連付けられている2バイトのIPv4ポートフィールドが続きます。これに続いて16バイトのIPv6アドレスフィールドと2バイトのIPv6ポートフィールドが続きます。アドレスとポートのペアの後、接続IDの長さフィールドは、次の接続IDフィールドの長さを表します。最後に、16バイトのステートレスリセットトークンフィールドには、接続IDに関連付けられているステートレスリセットトークンが含まれています。このトランスポートパラメータのフォーマットは、下の図22に示されています。
The Connection ID field and the Stateless Reset Token field contain an alternative connection ID that has a sequence number of 1; see Section 5.1.1. Having these values sent alongside the preferred address ensures that there will be at least one unused active connection ID when the client initiates migration to the preferred address.
接続IDフィールドとステートレスリセットトークンフィールドには、シーケンス番号1を持つ代替の接続IDが含まれています。セクション5.1.1を参照してください。これらの値を好みのアドレスに沿って送信させることは、クライアントが優先アドレスへの移行を開始するときに、未使用のアクティブ接続IDが少なくとも1つの未使用のアクティブ接続IDがあることを保証します。
The Connection ID and Stateless Reset Token fields of a preferred address are identical in syntax and semantics to the corresponding fields of a NEW_CONNECTION_ID frame (Section 19.15). A server that chooses a zero-length connection ID MUST NOT provide a preferred address. Similarly, a server MUST NOT include a zero-length connection ID in this transport parameter. A client MUST treat a violation of these requirements as a connection error of type TRANSPORT_PARAMETER_ERROR.
好ましいアドレスの接続IDおよびステートレスリセットトークンフィールドは、シンタックスおよびセマンティクスがNEW_CONNECTION_IDフレームの対応するフィールドに同じである（セクション19.15）。長さゼロの接続IDを選択するサーバーは、優先アドレスを提供してはいけません。同様に、サーバーはこのトランスポートパラメータに長さゼロの接続IDを含めてはなりません。クライアントは、TARSPORT_PARAMETER_ERROR型の接続エラーとしてこれらの要件の違反を扱う必要があります。
Preferred Address {
IPv4 Address (32),
IPv4 Port (16),
IPv6 Address (128),
IPv6 Port (16),
Connection ID Length (8),
Connection ID (..),
Stateless Reset Token (128),
}
Figure 22: Preferred Address Format
図22：優先アドレスフォーマット
active_connection_id_limit (0x0e): This is an integer value specifying the maximum number of connection IDs from the peer that an endpoint is willing to store. This value includes the connection ID received during the handshake, that received in the preferred_address transport parameter, and those received in NEW_CONNECTION_ID frames. The value of the active_connection_id_limit parameter MUST be at least 2. An endpoint that receives a value less than 2 MUST close the connection with an error of type TRANSPORT_PARAMETER_ERROR. If this transport parameter is absent, a default of 2 is assumed. If an endpoint issues a zero-length connection ID, it will never send a NEW_CONNECTION_ID frame and therefore ignores the active_connection_id_limit value received from its peer.
active_connection_id_limit（0x0e）：エンドポイントが保存しても構わないと思われるピアからの接続IDの最大数を指定する整数値です。この値は、handshakeの間に受信された接続ID、reced_connection_IDフレームで受信されたものです。active_connection_id_limitパラメーターの値は少なくとも2以上でなければなりません.2未満の値を受け取るエンドポイントは、TRANSPORT_PARAMETER_ERROR型のエラーとの接続を閉じる必要があります。このトランスポートパラメータが存在しない場合は、デフォルトの2が想定されます。エンドポイントが長さゼロの接続IDを発行すると、NEW_CONNECTION_IDフレームを送信することは決してないので、そのピアから受信したactive_connection_id_limit値を無視します。
initial_source_connection_id (0x0f): This is the value that the endpoint included in the Source Connection ID field of the first Initial packet it sends for the connection; see Section 7.3.
initial_source_connection_id（0x0f）：これは、接続を送信する最初の初期パケットのソース接続IDフィールドに含まれるエンドポイントが含まれる値です。7.3節を参照してください。
retry_source_connection_id (0x10): This is the value that the server included in the Source Connection ID field of a Retry packet; see Section 7.3. This transport parameter is only sent by a server.
retry_source_connection_id（0x10）：これは、サーバーが再試行パケットのソース接続IDフィールドに含まれる値です。7.3節を参照してください。このトランスポートパラメータはサーバーによってのみ送信されます。
If present, transport parameters that set initial per-stream flow control limits (initial_max_stream_data_bidi_local, initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on every stream of the corresponding type immediately after opening. If the transport parameter is absent, streams of that type start with a flow control limit of 0.
存在する場合、初期のフロー制御制限（initial_max_stream_data_bidi_local, initial_max_stream_data_bidi_remote, initial_max_stream_data_uni）を設定するトランスポートパラメータは、開く直後に、対応するタイプのすべてのストリームにMAX_STREAM_DATAフレーム（セクション19.10）を送信するのと同じです。トランスポートパラメータが存在しない場合、その型のストリームはフロー制御制限0で始まります。
A client MUST NOT include any server-only transport parameter: original_destination_connection_id, preferred_address, retry_source_connection_id, or stateless_reset_token. A server MUST treat receipt of any of these transport parameters as a connection error of type TRANSPORT_PARAMETER_ERROR.
クライアントは、original_destination_connection_id、reporte_address、retry_source_connection_id、またはstateless_reset_tokenを含めてはいけません。サーバーは、TRANSPORT_PARAMETER_ERROR型の接続エラーとして、これらのトランスポートパラメータのいずれかを受信する必要があります。
As described in Section 12.4, packets contain one or more frames. This section describes the format and semantics of the core QUIC frame types.
セクション12.4で説明されているように、パケットは1つ以上のフレームを含む。このセクションでは、コアのQUICフレームタイプのフォーマットとセマンティクスについて説明します。
A PADDING frame (type=0x00) has no semantic value. PADDING frames can be used to increase the size of a packet. Padding can be used to increase an Initial packet to the minimum required size or to provide protection against traffic analysis for protected packets.
パディングフレーム（Type = 0x00）の値には意味がありません。PADDINGフレームを使用してパケットのサイズを大きくすることができます。パディングを使用して、初期パケットを最小の必要サイズに拡大することも、保護されたパケットのトラフィック分析に対する保護を提供するために使用できます。
PADDING frames are formatted as shown in Figure 23, which shows that PADDING frames have no content. That is, a PADDING frame consists of the single byte that identifies the frame as a PADDING frame.
パディングフレームは図23に示すようにフォーマットされており、パディングフレームはコンテンツがないことを示しています。すなわち、パディングフレームは、パディングフレームとしてフレームを識別する1バイトからなる。
PADDING Frame {
Type (i) = 0x00,
}
Figure 23: PADDING Frame Format
図23：パディングフレームフォーマット
Endpoints can use PING frames (type=0x01) to verify that their peers are still alive or to check reachability to the peer.
エンドポイントは、Ping Frames（Type = 0x01）を使用して、ピアがまだ生きているか、ピアへの到達可能性を確認することを確認できます。
PING frames are formatted as shown in Figure 24, which shows that PING frames have no content.
PINGフレームは図24に示すようにフォーマットされており、これはPINGフレームがコンテンツがないことを示しています。
PING Frame {
Type (i) = 0x01,
}
Figure 24: PING Frame Format
図24：PINGフレームフォーマット
The receiver of a PING frame simply needs to acknowledge the packet containing this frame.
PINGフレームの受信機は、このフレームを含むパケットを承認するだけでよい。
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; see Section 10.1.2.
PINGフレームは、アプリケーションまたはアプリケーションプロトコルがタイムアウトから接続を防止したいときに接続を保つために使用できます。10.1.2項を参照してください。
Receivers send ACK frames (types 0x02 and 0x03) to inform senders of packets they have received and processed. The ACK frame contains one or more ACK Ranges. ACK Ranges identify acknowledged packets. If the frame type is 0x03, ACK frames also contain the cumulative count of QUIC packets with associated ECN marks received on the connection up until this point. QUIC implementations MUST properly handle both types, and, if they have enabled ECN for packets they send, they SHOULD use the information in the ECN section to manage their congestion state.
受信側受信機は、受信および処理したパケットの送信者に通知するためにACKフレーム（タイプ0x02および0x03）を送信します。ACKフレームには1つ以上のACK範囲が含まれています。ACK Ranges承認されたパケットを識別します。フレームタイプが0x03の場合、ACKフレームには、この時点まで接続で受信された関連ECNマークを持つQUICパケットの累積カウントも含まれています。QUICの実装は両方のタイプを正しく処理し、それらが送信するパケットにECNを有効にしている場合、それらはECNセクション内の情報を使用してそれらの輻輳状態を管理する必要があります。
QUIC acknowledgments are irrevocable. Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK frame. This is unlike reneging for TCP Selective Acknowledgments (SACKs) [RFC2018].
熟練した承認は復元できます。確認されたら、将来のACKフレームに表示されなくても、パケットは認められたままになります。これはTCP選択認識（SACKS）のリニングとは異なります[RFC2018]。
Packets from different packet number spaces can be identified using the same numeric value. An acknowledgment for a packet needs to indicate both a packet number and a packet number space. This is accomplished by having each ACK frame only acknowledge packet numbers in the same space as the packet in which the ACK frame is contained.
異なるパケット番号スペースからのパケットは、同じ数値を使用して識別できます。パケットの確認応答は、パケット番号とパケット番号スペースの両方を示す必要があります。これは、各ACKフレームが、ACKフレームが含まれているパケットと同じスペース内のパケット番号のみを確認することによって達成される。
Version Negotiation and Retry packets cannot be acknowledged because they do not contain a packet number. Rather than relying on ACK frames, these packets are implicitly acknowledged by the next Initial packet sent by the client.
パケット番号が含まれていないため、バージョンネゴシエーションと再試行パケットは確認できません。ACKフレームに頼るのではなく、これらのパケットはクライアントによって送信された次の最初のパケットによって暗黙的に認識されます。
ACK frames are formatted as shown in Figure 25.
ACKフレームは図25に示すようにフォーマットされています。
ACK Frame {
Type (i) = 0x02..0x03,
Largest Acknowledged (i),
ACK Delay (i),
ACK Range Count (i),
First ACK Range (i),
ACK Range (..) ...,
[ECN Counts (..)],
}
Figure 25: ACK Frame Format
図25：ACKフレームフォーマット
ACK frames contain the following fields:
ACKフレームには、次のフィールドが含まれています。
Largest Acknowledged: A variable-length integer representing the largest packet number the peer is acknowledging; this is usually the largest packet number that the peer has received prior to generating the ACK frame. Unlike the packet number in the QUIC long or short header, the value in an ACK frame is not truncated.
最大ACK：最大パケット番号を表す可変長整数ピアは承認されています。これは通常、ピアがACKフレームを生成する前に受信した最大のパケット番号です。QUIC長または短いヘッダーのパケット番号とは異なり、ACKフレーム内の値は切り捨てられません。
ACK Delay: A variable-length integer encoding the acknowledgment delay in microseconds; see Section 13.2.5. It is decoded by multiplying the value in the field by 2 to the power of the ack_delay_exponent transport parameter sent by the sender of the ACK frame; see Section 18.2. Compared to simply expressing the delay as an integer, this encoding allows for a larger range of values within the same number of bytes, at the cost of lower resolution.
ACK遅延：肯定応答遅延をマイクロ秒単位でエンコードする可変長整数。13.2.5項を参照してください。フィールド内の値を2バイブ秒のACKフレームの送信者によって送信されたACK_DELAY_EXPONENTトランスポートパラメータの電源に掛けることによって復号されます。18.2節を参照してください。単に遅延を整数として表現すると比較して、この符号化は低い解像度のコストで、同じバイト数のより大きな範囲の値を可能にする。
ACK Range Count: A variable-length integer specifying the number of ACK Range fields in the frame.
ACK Range Countフレーム内のACKレンジフィールドの数を指定する可変長整数。
First ACK Range: A variable-length integer indicating the number of contiguous packets preceding the Largest Acknowledged that are being acknowledged. That is, the smallest packet acknowledged in the range is determined by subtracting the First ACK Range value from the Largest Acknowledged field.
最初のACK範囲：認証されている最大の認識されている最大の確認先の連続パケットの数を示す可変長整数。すなわち、範囲内で確認された最小パケットは、最大の確認されたフィールドから第1のACK範囲値を減算することによって決定される。
ACK Ranges: Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see Section 19.3.1.
ACK範囲：交互に確認されていない（ギャップ）、確認されている（ACK範囲）の追加範囲のパケットが含まれています。セクション19.3.1を参照してください。
ECN Counts: The three ECN counts; see Section 19.3.2.
ECNカウント：3つのECNカウント。セクション19.3.2を参照してください。
Each ACK Range consists of alternating Gap and ACK Range Length values in descending packet number order. ACK Ranges can be repeated. The number of Gap and ACK Range Length values is determined by the ACK Range Count field; one of each value is present for each value in the ACK Range Count field.
各ACK範囲は、降順のパケット番号の順序で交流ギャップとACK範囲長の値からなる。ACK範囲を繰り返すことができます。ギャップ範囲長の値の数は、ACK範囲カウントフィールドによって決まります。各値の1つは、ACK Range Countフィールドの各値に対して存在します。
ACK Ranges are structured as shown in Figure 26.
ACK範囲は図26に示すように構成されています。
ACK Range {
Gap (i),
ACK Range Length (i),
}
Figure 26: ACK Ranges
図26：ACK範囲
The fields that form each ACK Range are:
各ACK範囲を形成するフィールドは次のとおりです。
Gap: A variable-length integer indicating the number of contiguous unacknowledged packets preceding the packet number one lower than the smallest in the preceding ACK Range.
GAP：前のACK範囲の最小値より低いパケット番号1の連続した未確認パケットの数を示す可変長整数。
ACK Range Length: A variable-length integer indicating the number of contiguous acknowledged packets preceding the largest packet number, as determined by the preceding Gap.
ACK範囲長さ：前のギャップによって決定される最大のパケット番号の前にある隣接確認されたパケットの数を示す可変長整数。
Gap and ACK Range Length values use a relative integer encoding for efficiency. Though each encoded value is positive, the values are subtracted, so that each ACK Range describes progressively lower-numbered packets.
GAPとACKの範囲の長さの値は、効率の相対整数符号化を使用します。各符号化値は正であるが、値は減算されるので、各ACK範囲は漸進的に番号の小さいパケットを記述する。
Each ACK Range acknowledges a contiguous range of packets by indicating the number of acknowledged packets that precede the largest packet number in that range. A value of 0 indicates that only the largest packet number is acknowledged. Larger ACK Range values indicate a larger range, with corresponding lower values for the smallest packet number in the range. Thus, given a largest packet number for the range, the smallest value is determined by the following formula:
各ACK範囲は、その範囲内の最大のパケット番号の前にある確認されたパケットの数を示すことによって、連続したパケットの範囲を確認します。値0は、最大のパケット番号のみが確認されていることを示します。ACK範囲値が大きいほど、範囲内の最小のパケット番号に対して対応する低い値が大きい方の範囲を示します。したがって、範囲の最大のパケット番号を考えると、最小値は次の式によって決定されます。
smallest = largest - ack_range
An ACK Range acknowledges all packets between the smallest packet number and the largest, inclusive.
ACK範囲は、最小のパケット番号と最大のパケットの間のすべてのパケットを確認します。
The largest value for an ACK Range is determined by cumulatively subtracting the size of all preceding ACK Range Lengths and Gaps.
ACK範囲の最大値は、前のACK範囲長とギャップのすべてのサイズを累積的に差し引くことによって決定されます。
Each Gap indicates a range of packets that are not being acknowledged. The number of packets in the gap is one higher than the encoded value of the Gap field.
各ギャップは、確認されていないパケットの範囲を示します。ギャップ内のパケットの数は、ギャップフィールドの符号化された値よりも高い。
The value of the Gap field establishes the largest packet number value for the subsequent ACK Range using the following formula:
GAPフィールドの値は、次の式を使用して後続のACK範囲の最大パケット番号値を確立します。
largest = previous_smallest - gap - 2
If any computed packet number is negative, an endpoint MUST generate a connection error of type FRAME_ENCODING_ERROR.
計算されたパケット番号が負の場合、エンドポイントはframe_encoding_error型の接続エラーを生成する必要があります。
The ACK frame uses the least significant bit of the type value (that is, type 0x03) to indicate ECN feedback and report receipt of QUIC packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE in the packet's IP header. ECN counts are only present when the ACK frame type is 0x03.
ACKフレームは、ECNフィードバックと、ECT（0）、ECT（1）、またはECN-CEのECNコードポイントを持つQUICのフィードバックとレポートの受信を示すために、タイプ値の最下位ビット（つまり、0x03）を使用します。パケットのIPヘッダーECNカウントは、ACKフレームタイプが0x03の場合にのみ存在します。
When present, there are three ECN counts, as shown in Figure 27.
存在する場合、図27に示すように、3つのECNカウントがあります。
ECN Counts {
ECT0 Count (i),
ECT1 Count (i),
ECN-CE Count (i),
}
Figure 27: ECN Count Format
図27：ECN COUNTフォーマット
The ECN count fields are:
ECNカウントフィールドは次のとおりです。
ECT0 Count: A variable-length integer representing the total number of packets received with the ECT(0) codepoint in the packet number space of the ACK frame.
ECT0 COUNT：ACKフレームのパケット番号スペース内のECT（0）コードポイントで受信されたパケットの総数を表す可変長整数。
ECT1 Count: A variable-length integer representing the total number of packets received with the ECT(1) codepoint in the packet number space of the ACK frame.
ECT1 COUNT：ACKフレームのパケット番号スペース内のECT（1）コードポイントで受信されたパケットの総数を表す可変長整数。
ECN-CE Count: A variable-length integer representing the total number of packets received with the ECN-CE codepoint in the packet number space of the ACK frame.
ECN-CE COUNT：ACKフレームのパケット番号スペースにECN-CEコードポイントを使用して受信したパケットの総数を表す可変長整数。
ECN counts are maintained separately for each packet number space.
ECNカウントは各パケット番号スペースに対して別々に維持されます。
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly terminate the sending part of a stream.
エンドポイントはRESET_STREAMフレーム（type = 0x04）を使用してストリームの送信部分を急に終了させます。
After sending a RESET_STREAM, an endpoint ceases transmission and retransmission of STREAM frames on the identified stream. A receiver of RESET_STREAM can discard any data that it already received on that stream.
RESET_STREAMを送信した後、エンドポイントは識別されたストリーム上のストリームフレームの送信および再送信を中止します。RESET_STREAMの受信機は、それがそのストリーム上で既に受信されているデータを破棄することができます。
An endpoint that receives a RESET_STREAM frame for a send-only stream MUST terminate the connection with error STREAM_STATE_ERROR.
送信専用ストリームのRESET_STREAMフレームを受信するエンドポイントは、エラーSTREAM_STATE_ERRORとの接続を終了する必要があります。
RESET_STREAM frames are formatted as shown in Figure 28.
RESET_STREAMフレームは図28に示すようにフォーマットされています。
RESET_STREAM Frame {
Type (i) = 0x04,
Stream ID (i),
Application Protocol Error Code (i),
Final Size (i),
}
Figure 28: RESET_STREAM Frame Format
図28：RESET_STREAMフレームフォーマット
RESET_STREAM frames contain the following fields:
RESET_STREAMフレームには、次のフィールドが含まれています。
Stream ID: A variable-length integer encoding of the stream ID of the stream being terminated.
ストリームID：終了しているストリームのストリームIDの可変長整数符号化。
Application Protocol Error Code: A variable-length integer containing the application protocol error code (see Section 20.2) that indicates why the stream is being closed.
アプリケーションプロトコルエラーコード：ストリームがクローズされている理由を示すアプリケーションプロトコルエラーコード（セクション20.2参照）を含む可変長整数。
Final Size: A variable-length integer indicating the final size of the stream by the RESET_STREAM sender, in units of bytes; see Section 4.5.
最終サイズ：reset_stream送信者によるストリームの最終サイズを示す可変長整数。バイト単位。セクション4.5を参照してください。
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that incoming data is being discarded on receipt per application request. STOP_SENDING requests that a peer cease transmission on a stream.
エンドポイントはSTOP_SENDING frame（type = 0x05）を使用して、着信データがアプリケーション要求ごとに受信時に破棄されていることを通信します。STOP_SENDINGピアがストリームで送信を中止する要求を要求します。
A STOP_SENDING frame can be sent for streams in the "Recv" or "Size Known" states; see Section 3.2. Receiving a STOP_SENDING frame for a locally initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR. An endpoint that receives a STOP_SENDING frame for a receive-only stream MUST terminate the connection with error STREAM_STATE_ERROR.
STOP_SENDINGフレームは、「RECV」または「サイズ既知」状態でストリームの送信を送信できます。セクション3.2を参照してください。まだ作成されていないローカルに開始されたストリームのSTOP_SENDINGフレームを受信する必要があります。STREAM_STATE_ERROR型の接続エラーとして扱う必要があります。受信専用ストリームのSTOP_SENDINGフレームを受信するエンドポイントは、エラーSTREAM_STATE_ERRORとの接続を終了する必要があります。
STOP_SENDING frames are formatted as shown in Figure 29.
STOP_SENDINGフレームは図29に示すようにフォーマットされています。
STOP_SENDING Frame {
Type (i) = 0x05,
Stream ID (i),
Application Protocol Error Code (i),
}
Figure 29: STOP_SENDING Frame Format
図29：STOP_SENDINGフレームフォーマット
STOP_SENDING frames contain the following fields:
STOP_SENDINGフレームには、次のフィールドが含まれています。
Stream ID: A variable-length integer carrying the stream ID of the stream being ignored.
ストリームID：無視されているストリームのストリームIDを搬送する可変長整数。
Application Protocol Error Code: A variable-length integer containing the application-specified reason the sender is ignoring the stream; see Section 20.2.
アプリケーションプロトコルエラーコード：送信者がストリームを無視しているアプリケーション指定の理由を含む可変長整数。20.2を参照してください。
A CRYPTO frame (type=0x06) is used to transmit cryptographic handshake messages. It can be sent in all packet types except 0-RTT. The CRYPTO frame offers the cryptographic protocol an in-order stream of bytes. CRYPTO frames are functionally identical to STREAM frames, except that they do not bear a stream identifier; they are not flow controlled; and they do not carry markers for optional offset, optional length, and the end of the stream.
暗号ハンドシェイクメッセージを送信するために、暗号フレーム（type = 0x06）が使用されます。0-RTTを除くすべてのパケットタイプで送信できます。暗号フレームは暗号プロトコルを提供しています。暗号フレームは、ストリーム識別子を持たないことを除いて、ストリームフレームと機能的に同じです。それらは流動制御されていません。また、オプションのオフセット、オプションの長さ、およびストリームの終わりにマーカーを持ちません。
CRYPTO frames are formatted as shown in Figure 30.
暗号フレームは図30に示すようにフォーマットされています。
CRYPTO Frame {
Type (i) = 0x06,
Offset (i),
Length (i),
Crypto Data (..),
}
Figure 30: CRYPTO Frame Format
図30：暗号フレームフォーマット
CRYPTO frames contain the following fields:
暗号フレームには、次のフィールドが含まれています。
Offset: A variable-length integer specifying the byte offset in the stream for the data in this CRYPTO frame.
オフセット：この暗号フレーム内のデータのストリーム内のバイトオフセットを指定する可変長整数。
Length: A variable-length integer specifying the length of the Crypto Data field in this CRYPTO frame.
長さ：この暗号フレーム内の暗号データフィールドの長さを指定する可変長整数。
Crypto Data: The cryptographic message data.
暗号データ：暗号メッセージデータ。
There is a separate flow of cryptographic handshake data in each encryption level, each of which starts at an offset of 0. This implies that each encryption level is treated as a separate CRYPTO stream of data.
各暗号化レベルで暗号化ハンドシェイクデータの独立したフローがあり、各暗号化レベルは0のオフセットで始まります。これは、各暗号化レベルが別々の暗号ストリームとして扱われることを意味します。
The largest offset delivered on a stream -- the sum of the offset and data length -- cannot exceed 2^62-1. Receipt of a frame that exceeds this limit MUST be treated as a connection error of type FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED.
ストリームで提供される最大のオフセット (オフセットとデータ長の合計) は2^62-1を超えることはできません。この制限を超えるフレームの受信は、FRAME_ENCODING_ERRORまたはCRYPTO_BUFFER_EXCEEDEDの型の接続エラーとして扱われなければなりません。
Unlike STREAM frames, which include a stream ID indicating to which stream the data belongs, the CRYPTO frame carries data for a single stream per encryption level. The stream does not have an explicit end, so CRYPTO frames do not have a FIN bit.
データがどのストリームに属するかを示すストリームIDを含むストリームフレームとは異なり、暗号フレームは暗号化レベルごとに単一のストリームのデータを搬送する。ストリームに明示的な端を持たないため、暗号フレームにはFINビットがありません。
A server sends a NEW_TOKEN frame (type=0x07) to provide the client with a token to send in the header of an Initial packet for a future connection.
サーバーはNEW_TOKENフレーム（Type = 0x07）を送信して、将来の接続のために最初のパケットのヘッダーに送信するクライアントにトークンを提供します。
NEW_TOKEN frames are formatted as shown in Figure 31.
NEW_TOKENフレームは図31に示すようにフォーマットされています。
NEW_TOKEN Frame {
Type (i) = 0x07,
Token Length (i),
Token (..),
}
Figure 31: NEW_TOKEN Frame Format
図31：NEW_TOKENフレーム形式
NEW_TOKEN frames contain the following fields:
NEW_TOKENフレームには、次のフィールドが含まれています。
Token Length: A variable-length integer specifying the length of the token in bytes.
トークン長：トークンの長さをバイト単位で指定する可変長整数。
Token: An opaque blob that the client can use with a future Initial packet. The token MUST NOT be empty. A client MUST treat receipt of a NEW_TOKEN frame with an empty Token field as a connection error of type FRAME_ENCODING_ERROR.
トークン：クライアントが将来の初期パケットで使用できる不透明なBLOB。トークンは空にしてはいけません。クライアントは、タイプframe_encoding_error型の接続エラーとして、空のトークンフィールドを持つNEW_TOKENフレームの受信を扱う必要があります。
A client might receive multiple NEW_TOKEN frames that contain the same token value if packets containing the frame are incorrectly determined to be lost. Clients are responsible for discarding duplicate values, which might be used to link connection attempts; see Section 8.1.3.
フレームを含むパケットが誤って失われたと判断された場合、クライアントは同じトークン値を含む複数のNEW_TOKENフレームを受信する可能性があります。クライアントは、接続試行をリンクするために使用される可能性がある重複値を破棄する責任があります。セクション8.1.3を参照してください。
Clients MUST NOT send NEW_TOKEN frames. A server MUST treat receipt of a NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION.
クライアントはNEW_TOKENフレームを送信してはいけません。サーバーは、PROTOCOL_VIOLATION型の接続エラーとしてNEW_TOKENフレームの受信を扱う必要があります。
STREAM frames implicitly create a stream and carry stream data. The Type field in the STREAM frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f). The three low-order bits of the frame type determine the fields that are present in the frame:
ストリームフレームは暗黙的にストリームを作成し、ストリームデータを搬送する。ストリームフレームのTypeフィールドは、0B00001xxx（または0x08から0x0fのセットのセット）を取ります。フレームタイプの3つの下位ビットは、フレーム内に存在するフィールドを決定します。
* The OFF bit (0x04) in the frame type is set to indicate that there is an Offset field present. When set to 1, the Offset field is present. When set to 0, the Offset field is absent and the Stream Data starts at an offset of 0 (that is, the frame contains the first bytes of the stream, or the end of a stream that includes no data).
* フレームタイプのオフビット（0x04）は、オフセットフィールドが存在することを示すために設定されています。1に設定すると、オフセットフィールドが存在します。0に設定すると、オフセットフィールドは存在しなくなり、ストリームデータは0のオフセットで起動します（つまり、フレームにはストリームの最初のバイト、またはデータを含まないストリームの終わり）。
* The LEN bit (0x02) in the frame type is set to indicate that there is a Length field present. If this bit is set to 0, the Length field is absent and the Stream Data field extends to the end of the packet. If this bit is set to 1, the Length field is present.
* フレームタイプのLENビット（0x02）は、長さフィールドが存在することを示すために設定されています。このビットが0に設定されている場合、長さフィールドは存在しなくなり、ストリームデータフィールドはパケットの最後まで拡張されます。このビットが1に設定されていると、長さフィールドが存在します。
* The FIN bit (0x01) indicates that the frame marks the end of the stream. The final size of the stream is the sum of the offset and the length of this frame.
* FINビット（0x01）は、フレームがストリームの終わりをマークすることを示します。ストリームの最後のサイズは、オフセットとこのフレームの長さの合計です。
An endpoint MUST terminate the connection with error STREAM_STATE_ERROR if it receives a STREAM frame for a locally initiated stream that has not yet been created, or for a send-only stream.
まだ作成されていないローカルに開始されたストリームのストリームフレームを受信した場合、または送信専用のストリームのストリームフレームを受信した場合、エンドポイントはエラーSTREAM_STATE_ERRORとの接続を終了する必要があります。
STREAM frames are formatted as shown in Figure 32.
図32に示すように、ストリームフレームはフォーマットされています。
STREAM Frame {
Type (i) = 0x08..0x0f,
Stream ID (i),
[Offset (i)],
[Length (i)],
Stream Data (..),
}
Figure 32: STREAM Frame Format
図32：ストリームフレームフォーマット
STREAM frames contain the following fields:
ストリームフレームには、次のフィールドが含まれています。
Stream ID: A variable-length integer indicating the stream ID of the stream; see Section 2.1.
ストリームID：ストリームのストリームIDを示す可変長整数。セクション2.1を参照してください。
Offset: A variable-length integer specifying the byte offset in the stream for the data in this STREAM frame. This field is present when the OFF bit is set to 1. When the Offset field is absent, the offset is 0.
オフセット：このストリームフレーム内のデータのストリーム内のバイトオフセットを指定する可変長整数。このフィールドは、オフビットが1に設定されているときに存在します。オフセットフィールドが存在しない場合、オフセットは0です。
Length: A variable-length integer specifying the length of the Stream Data field in this STREAM frame. This field is present when the LEN bit is set to 1. When the LEN bit is set to 0, the Stream Data field consumes all the remaining bytes in the packet.
長さ：このストリームフレーム内のストリームデータフィールドの長さを指定する可変長整数。このフィールドは、LENビットが1に設定されているときに存在します.LENビットが0に設定されると、ストリームデータフィールドはパケット内のすべての残りのバイトを消費します。
Stream Data: The bytes from the designated stream to be delivered.
ストリームデータ：指定されたストリームからのバイト数。
When a Stream Data field has a length of 0, the offset in the STREAM frame is the offset of the next byte that would be sent.
ストリームデータフィールドに長さが0のとき、ストリームフレーム内のオフセットは送信される次のバイトのオフセットです。
The first byte in the stream has an offset of 0. The largest offset delivered on a stream -- the sum of the offset and data length -- cannot exceed 2^62-1, as it is not possible to provide flow control credit for that data. Receipt of a frame that exceeds this limit MUST be treated as a connection error of type FRAME_ENCODING_ERROR or FLOW_CONTROL_ERROR.
ストリーム内の最初のバイトは0のオフセットを持ちます。ストリームで提供される最大のオフセット - オフセットとデータ長の合計 - フロー制御クレジットを提供することはできませんので、2^62-1を超えることはできません。そのデータ。この制限を超えるフレームの受信は、frame_encoding_errorまたはFLOW_CONTROL_ERROR型の接続エラーとして扱われなければなりません。
A MAX_DATA frame (type=0x10) is used in flow control to inform the peer of the maximum amount of data that can be sent on the connection as a whole.
MAX_DATAフレーム（TYPE = 0x10）はフロー制御で使用して、接続で送信できる最大データのピア全体を全体として送信できます。
MAX_DATA frames are formatted as shown in Figure 33.
MAX_DATAフレームは図33に示すようにフォーマットされています。
MAX_DATA Frame {
Type (i) = 0x10,
Maximum Data (i),
}
Figure 33: MAX_DATA Frame Format
図33：MAX_DATAフレームフォーマット
MAX_DATA frames contain the following field:
MAX_DATAフレームには、次のフィールドが含まれています。
Maximum Data: A variable-length integer indicating the maximum amount of data that can be sent on the entire connection, in units of bytes.
最大データ：接続全体で送信できるデータの最大量（バイト単位）を示す可変長整数。
All data sent in STREAM frames counts toward this limit. The sum of the final sizes on all streams -- including streams in terminal states -- MUST NOT exceed the value advertised by a receiver. An endpoint MUST terminate a connection with an error of type FLOW_CONTROL_ERROR if it receives more data than the maximum data value that it has sent. This includes violations of remembered limits in Early Data; see Section 7.4.1.
ストリームフレームで送信されたすべてのデータはこの制限に向かってカウントされます。端末状態のストリームを含むすべてのストリームの最終的なサイズの合計 - 受信者によってアドバタイズされた値を超えてはいけません。エンドポイントは、送信された最大データ値よりも多くのデータを受信した場合、FLOW_CONTROL_ERROR型のエラーとの接続を終了する必要があります。これには、初期データの覚え具の違反が含まれます。7.4.1項を参照してください。
A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform a peer of the maximum amount of data that can be sent on a stream.
MAX_STREAM_DATAフレーム（TYPE = 0x11）は、ストリーム上で送信できる最大量のデータのピアに通知するためにフロー制御で使用されます。
A MAX_STREAM_DATA frame can be sent for streams in the "Recv" state; see Section 3.2. Receiving a MAX_STREAM_DATA frame for a locally initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR. An endpoint that receives a MAX_STREAM_DATA frame for a receive-only stream MUST terminate the connection with error STREAM_STATE_ERROR.
MAX_STREAM_DATAフレームは、「RECV」状態でストリームを送信することができます。セクション3.2を参照してください。まだ作成されていないローカルに開始されたストリームのMAX_STREAM_DATAフレームを受信する必要があります.STREAM_STATE_ERROR型の接続エラーとして扱う必要があります。受信専用ストリームのMAX_STREAM_DATAフレームを受信するエンドポイントは、エラーSTREAM_STATE_ERRORとの接続を終了する必要があります。
MAX_STREAM_DATA frames are formatted as shown in Figure 34.
MAX_STREAM_DATAフレームは図34に示すようにフォーマットされています。
MAX_STREAM_DATA Frame {
Type (i) = 0x11,
Stream ID (i),
Maximum Stream Data (i),
}
Figure 34: MAX_STREAM_DATA Frame Format
図34：MAX_STREAM_DATAフレームフォーマット
MAX_STREAM_DATA frames contain the following fields:
MAX_STREAM_DATAフレームには、次のフィールドが含まれています。
Stream ID: The stream ID of the affected stream, encoded as a variable-length integer.
ストリームID：影響を受けるストリームのストリームIDは、可変長整数としてエンコードされました。
Maximum Stream Data: A variable-length integer indicating the maximum amount of data that can be sent on the identified stream, in units of bytes.
最大ストリームデータ：識別されたストリームで送信できる最大データの最大量をバイト単位で示す可変長整数。
When counting data toward this limit, an endpoint accounts for the largest received offset of data that is sent or received on the stream. Loss or reordering can mean that the largest received offset on a stream can be greater than the total size of data received on that stream. Receiving STREAM frames might not increase the largest received offset.
この制限に向かうデータをカウントするとき、エンドポイントはストリーム上で送受信されるデータの最大のデータのオフセットを占めます。損失または並べ替えは、ストリーム上の最大の受信オフセットがそのストリーム上で受信されたデータの合計サイズよりも大きくなる可能性があることを意味します。受信ストリームフレームは、最大の受信オフセットを増加させない可能性があります。
The data sent on a stream MUST NOT exceed the largest maximum stream data value advertised by the receiver. An endpoint MUST terminate a connection with an error of type FLOW_CONTROL_ERROR if it receives more data than the largest maximum stream data that it has sent for the affected stream. This includes violations of remembered limits in Early Data; see Section 7.4.1.
ストリームで送信されたデータは、受信者によってアドバタイズされた最大の最大ストリームデータ値を超えてはなりません。エンドポイントは、影響を受けるストリームに対して送信された最大の最大ストリームデータよりも多くのデータを受信した場合、Type FLOW_CONTROL_ERRORのエラーとの接続を終了する必要があります。これには、初期データの覚え具の違反が含まれます。7.4.1項を参照してください。
A MAX_STREAMS frame (type=0x12 or 0x13) informs the peer of the cumulative number of streams of a given type it is permitted to open. A MAX_STREAMS frame with a type of 0x12 applies to bidirectional streams, and a MAX_STREAMS frame with a type of 0x13 applies to unidirectional streams.
MAX_STREAMSフレーム（Type = 0x12または0x13）は、開くことが許可されている特定のタイプの累積ストリーム数のピアに通知します。0x12のタイプのMAX_STREAMフレームは双方向ストリームに適用され、0x13のタイプのMAX_STREAMSフレームは単方向ストリームに適用されます。
MAX_STREAMS frames are formatted as shown in Figure 35.
MAX_STREAMSフレームは図35に示すようにフォーマットされています。
MAX_STREAMS Frame {
Type (i) = 0x12..0x13,
Maximum Streams (i),
}
Figure 35: MAX_STREAMS Frame Format
図35：MAX_STREAMSフレームフォーマット
MAX_STREAMS frames contain the following field:
MAX_STREAMSフレームには、次のフィールドが含まれています。
Maximum Streams: A count of the cumulative number of streams of the corresponding type that can be opened over the lifetime of the connection. This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^62-1. Receipt of a frame that permits opening of a stream larger than this limit MUST be treated as a connection error of type FRAME_ENCODING_ERROR.
最大ストリーム：接続の有効期間にわたって開くことができる対応するタイプの累積ストリーム数の数。2^62-1より大きいストリームIDを符号化することはできないので、この値は2 ^ 60を超えることはできません。この制限よりも大きいストリームを開くことを可能にするフレームの受信は、frame_encoding_error型の接続エラーとして扱われなければなりません。
Loss or reordering can cause an endpoint to receive a MAX_STREAMS frame with a lower stream limit than was previously received. MAX_STREAMS frames that do not increase the stream limit MUST be ignored.
損失または並べ替えは、以前に受信されたよりも低いストリーム制限を持つMAX_STREAMフレームを受信することができます。Streamの制限を上げないMAX_STREAMSフレームは無視される必要があります。
An endpoint MUST NOT open more streams than permitted by the current stream limit set by its peer. For instance, a server that receives a unidirectional stream limit of 3 is permitted to open streams 3, 7, and 11, but not stream 15. An endpoint MUST terminate a connection with an error of type STREAM_LIMIT_ERROR if a peer opens more streams than was permitted. This includes violations of remembered limits in Early Data; see Section 7.4.1.
エンドポイントは、ピアによって設定された現在のストリーム制限によって許可されているよりも多くのストリームを開くことはできません。たとえば、1の単方向ストリーム制限を受信するサーバーは、ストリーム3,7、および11を開くがストリーム15を開くことは許可されています。許可されています。これには、初期データの覚え具の違反が含まれます。7.4.1項を参照してください。
Note that these frames (and the corresponding transport parameters) do not describe the number of streams that can be opened concurrently. The limit includes streams that have been closed as well as those that are open.
これらのフレーム（および対応するトランスポートパラメータ）は、同時に開くことができるストリームの数を記述しないことに注意してください。制限には、開いているものと同様に閉じられたストリームが含まれます。
A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes to send data but is unable to do so due to connection-level flow control; see Section 4. DATA_BLOCKED frames can be used as input to tuning of flow control algorithms; see Section 4.2.
送信者はデータを送信したいが、接続レベルのフロー制御のためにそうすることができないときにDATA_BLOCKED Frame（Type = 0x14）を送信する必要があります。セクション4. 4. DATA_BLOCKEDフレームは、フロー制御アルゴリズムの調整への入力として使用できます。セクション4.2を参照してください。
DATA_BLOCKED frames are formatted as shown in Figure 36.
DATA_BLOCKEDフレームは図36に示すようにフォーマットされています。
DATA_BLOCKED Frame {
Type (i) = 0x14,
Maximum Data (i),
}
Figure 36: DATA_BLOCKED Frame Format
図36：DATA_BLOCKEDフレームフォーマット
DATA_BLOCKED frames contain the following field:
DATA_BLOCKEDフレームには、次のフィールドが含まれています。
Maximum Data: A variable-length integer indicating the connection-level limit at which blocking occurred.
最大データ：ブロッキングが発生した接続レベル制限を示す可変長整数。
A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it wishes to send data but is unable to do so due to stream-level flow control. This frame is analogous to DATA_BLOCKED (Section 19.12).
送信者は、データを送信したいがストリームレベルのフロー制御のためにそうすることができない場合、送信者はSTREAM_DATA_BLOCKEDフレーム（Type = 0x15）を送信する必要があります。このフレームはDATA_BLOCKEDに似ています（セクション19.12）。
An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only stream MUST terminate the connection with error STREAM_STATE_ERROR.
送信専用ストリームのSTREAM_DATA_BLOCKEDフレームを受信するエンドポイントは、エラーSTREAM_STATE_ERRORとの接続を終了する必要があります。
STREAM_DATA_BLOCKED frames are formatted as shown in Figure 37.
STREAM_DATA_BLOCKEDフレームは、図37に示すようにフォーマットされています。
STREAM_DATA_BLOCKED Frame {
Type (i) = 0x15,
Stream ID (i),
Maximum Stream Data (i),
}
Figure 37: STREAM_DATA_BLOCKED Frame Format
図37：STREAM_DATA_BLOCKEDフレームフォーマット
STREAM_DATA_BLOCKED frames contain the following fields:
STREAM_DATA_BLOCKEDフレームには、次のフィールドが含まれています。
Stream ID: A variable-length integer indicating the stream that is blocked due to flow control.
ストリームID：フロー制御によりブロックされているストリームを示す可変長整数。
Maximum Stream Data: A variable-length integer indicating the offset of the stream at which the blocking occurred.
最大ストリームデータ：ブロッキングが発生したストリームのオフセットを示す可変長整数。
A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when it wishes to open a stream but is unable to do so due to the maximum stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED frame of type 0x16 is used to indicate reaching the bidirectional stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to indicate reaching the unidirectional stream limit.
送信者は、ストリームを開きたいが、そのピアによって設定された最大ストリーム制限のためにそうすることができないときにSTREAMS_BLOCKED Frame（Type = 0x16または0x17）を送信する必要があります。19.11節を参照してください。タイプ0x16のSTREAMS_BLOCKEDフレームは、双方向ストリーム制限に達することを示すために使用され、タイプ0x17のSTREAMS_BLOCKEDフレームが単方向ストリーム制限に達することを示すために使用されます。
A STREAMS_BLOCKED frame does not open the stream, but informs the peer that a new stream was needed and the stream limit prevented the creation of the stream.
STREAMS_BLOCKEDフレームはストリームを開かないが、新しいストリームが必要であることをピアに知らせ、ストリーム制限はストリームの作成を妨げた。
STREAMS_BLOCKED frames are formatted as shown in Figure 38.
STREAMS_BLOCKEDフレームは、図38に示すようにフォーマットされています。
STREAMS_BLOCKED Frame {
Type (i) = 0x16..0x17,
Maximum Streams (i),
}
Figure 38: STREAMS_BLOCKED Frame Format
図38：STREAMS_BLOCKEDフレームフォーマット
STREAMS_BLOCKED frames contain the following field:
STREAMS_BLOCKEDフレームには、次のフィールドが含まれています。
Maximum Streams: A variable-length integer indicating the maximum number of streams allowed at the time the frame was sent. This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^62-1. Receipt of a frame that encodes a larger stream ID MUST be treated as a connection error of type STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR.
最大ストリーム：フレームが送信されたときに許可されたストリームの最大数を示す可変長整数。2^62-1より大きいストリームIDを符号化することはできないので、この値は2 ^ 60を超えることはできません。より大きなストリームIDをエンコードするフレームの受信は、STREAM_LIMIT_ERRORまたはframe_encoding_error型の接続エラーとして扱われなければなりません。
An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide its peer with alternative connection IDs that can be used to break linkability when migrating connections; see Section 9.5.
エンドポイントはNEW_CONNECTION_IDフレーム（type = 0x18）を送信して、接続を移行するときにリンク可能性を遮断するために使用できる代替の接続IDを使用してそのピアを提供します。9.5節を参照してください。
NEW_CONNECTION_ID frames are formatted as shown in Figure 39.
NEW_CONNECTION_IDフレームは図39に示すようにフォーマットされています。
NEW_CONNECTION_ID Frame {
Type (i) = 0x18,
Sequence Number (i),
Retire Prior To (i),
Length (8),
Connection ID (8..160),
Stateless Reset Token (128),
}
Figure 39: NEW_CONNECTION_ID Frame Format
図39：NEW_CONNECTION_IDフレームフォーマット
NEW_CONNECTION_ID frames contain the following fields:
NEW_CONNECTION_IDフレームには、次のフィールドが含まれています。
Sequence Number: The sequence number assigned to the connection ID by the sender, encoded as a variable-length integer; see Section 5.1.1.
シーケンス番号：送信側で接続IDに割り当てられたシーケンス番号は、可変長整数としてエンコードされます。セクション5.1.1を参照してください。
Retire Prior To: A variable-length integer indicating which connection IDs should be retired; see Section 5.1.2.
前に引退する：どの接続IDを引退させるべきかを示す可変長整数。5.1.2項を参照してください。
Length: An 8-bit unsigned integer containing the length of the connection ID. Values less than 1 and greater than 20 are invalid and MUST be treated as a connection error of type FRAME_ENCODING_ERROR.
長さ：接続IDの長さを含む8ビットの符号なし整数。1未満の値が20未満の値は無効であり、frame_encoding_error型の接続エラーとして扱われる必要があります。
Connection ID: A connection ID of the specified length.
接続ID：指定された長さの接続ID。
Stateless Reset Token: A 128-bit value that will be used for a stateless reset when the associated connection ID is used; see Section 10.3.
ステートレスリセットトークン：関連接続IDが使用されているときにステートレスリセットに使用される128ビット値。セクション10.3を参照してください。
An endpoint MUST NOT send this frame if it currently requires that its peer send packets with a zero-length Destination Connection ID. Changing the length of a connection ID to or from zero length makes it difficult to identify when the value of the connection ID changed. An endpoint that is sending packets with a zero-length Destination Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a connection error of type PROTOCOL_VIOLATION.
エンドポイントが現在、長さ宛先接続IDを持つピア送信パケットを送信する必要がある場合は、このフレームを送信してはなりません。接続IDの長さをゼロの長さに変更すると、接続IDの値が変更されたときに識別することが困難になります。長さゼロの宛先接続IDを持つパケットを送信しているエンドポイントは、PROTOCOL_VIOLATION型の接続エラーとして、NEW_CONNECTION_IDフレームの受信を扱う必要があります。
Transmission errors, timeouts, and retransmissions might cause the same NEW_CONNECTION_ID frame to be received multiple times. Receipt of the same frame multiple times MUST NOT be treated as a connection error. A receiver can use the sequence number supplied in the NEW_CONNECTION_ID frame to handle receiving the same NEW_CONNECTION_ID frame multiple times.
送信エラー、タイムアウト、および再送信により、同じNEW_CONNECTION_IDフレームを複数回受信することがあります。同じフレームの受信複数回接続エラーとして扱わないでください。受信機は、NEW_CONNECTION_IDフレームで提供されたシーケンス番号を使用して、同じNEW_CONNECTION_IDフレームを複数回受信することを処理できます。
If an endpoint receives a NEW_CONNECTION_ID frame that repeats a previously issued connection ID with a different Stateless Reset Token field value or a different Sequence Number field value, or if a sequence number is used for different connection IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION.
エンドポイントが、異なるステートレスリセットトークンフィールド値または異なるシーケンス番号フィールド値を持つ以前に発行された接続IDを繰り返すNEW_CONNECTION_IDフレームを受信する場合、またはシーケンス番号が異なる接続IDに使用されている場合、エンドポイントはそのレシートをAとして扱うことがあります。PROTOCOL_VIOLATION型の接続エラー
The Retire Prior To field applies to connection IDs established during connection setup and the preferred_address transport parameter; see Section 5.1.2. The value in the Retire Prior To field MUST be less than or equal to the value in the Sequence Number field. Receiving a value in the Retire Prior To field that is greater than that in the Sequence Number field MUST be treated as a connection error of type FRAME_ENCODING_ERROR.
フィールドの前の引退は、接続設定中に確立された接続IDに適用され、推奨されています。5.1.2項を参照してください。フィールドの前の引退の値は、シーケンス番号フィールドの値以下でなければなりません。配列番号フィールドのそれよりも大きいフィールド以前のリタイア内の値を受信する必要があります。FRAME_ENCODING_ERROR型の接続エラーとして扱う必要があります。
Once a sender indicates a Retire Prior To value, smaller values sent in subsequent NEW_CONNECTION_ID frames have no effect. A receiver MUST ignore any Retire Prior To fields that do not increase the largest received Retire Prior To value.
送信者が値の前に引退を示したら、後続のNEW_CONNECTION_IDフレームで送信された値が小さくありません。受信機は、値の前に最大の受信リタイアを増加させないフィールドの前に任意の引退を無視する必要があります。
An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number smaller than the Retire Prior To field of a previously received NEW_CONNECTION_ID frame MUST send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID, unless it has already done so for that sequence number.
以前に受信したNEW_CONNECTION_IDフレームのフィールドの前に、retaileよりも小さいシーケンス番号を有するNEW_CONNECTION_IDフレームを受信するエンドポイントは、それがすでにそのシーケンス番号に対して既に行われていない限り、新しく受信された接続IDを引退する対応するRETIRE_CONNECTION_IDフレームを送信する必要がある。
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to indicate that it will no longer use a connection ID that was issued by its peer. This includes the connection ID provided during the handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a request to the peer to send additional connection IDs for future use; see Section 5.1. New connection IDs can be delivered to a peer using the NEW_CONNECTION_ID frame (Section 19.15).
エンドポイントは、そのピアによって発行された接続IDを使用しなくなったことを示すために、RETIRE_CONNECTION_IDフレーム（type = 0x19）を送信します。これには、ハンドシェイク中に提供された接続IDが含まれます。RETIRE_CONNECTION_IDフレームを送信すると、将来の使用のために追加の接続IDを送信するためのピアへの要求としても機能します。セクション5.1を参照してください。新しい接続IDは、NEW_CONNECTION_IDフレームを使用してピアに配信できます（セクション19.15）。
Retiring a connection ID invalidates the stateless reset token associated with that connection ID.
接続IDの停止接続IDに関連付けられているステートレスリセットトークンを無効にします。
RETIRE_CONNECTION_ID frames are formatted as shown in Figure 40.
RETIRE_CONNECTION_IDフレームは図40に示すようにフォーマットされています。
RETIRE_CONNECTION_ID Frame {
Type (i) = 0x19,
Sequence Number (i),
}
Figure 40: RETIRE_CONNECTION_ID Frame Format
図40：RETIRE_CONNECTION_IDフレーム形式
RETIRE_CONNECTION_ID frames contain the following field:
RETIRE_CONNECTION_IDフレームには、次のフィールドが含まれています。
Sequence Number: The sequence number of the connection ID being retired; see Section 5.1.2.
シーケンス番号：引退している接続IDのシーケンス番号。5.1.2項を参照してください。
Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number greater than any previously sent to the peer MUST be treated as a connection error of type PROTOCOL_VIOLATION.
ピアに以前に送信された順序番号を含むRETIRE_CONNECTION_IDフレームの受信ピアには、PROTOCOL_VIOLATION型の接続エラーとして扱われなければなりません。
The sequence number specified in a RETIRE_CONNECTION_ID frame MUST NOT refer to the Destination Connection ID field of the packet in which the frame is contained. The peer MAY treat this as a connection error of type PROTOCOL_VIOLATION.
RETIRE_CONNECTION_IDフレームに指定されたシーケンス番号は、フレームが含まれているパケットの宛先接続IDフィールドを参照してはいけません。ピアはこれをtype PROTOCOL_VIOLATIONの接続エラーとして扱うことができます。
An endpoint cannot send this frame if it was provided with a zero-length connection ID by its peer. An endpoint that provides a zero-length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID frame as a connection error of type PROTOCOL_VIOLATION.
そのピアによって長さゼロの接続IDを指定した場合、エンドポイントはこのフレームを送信できません。長さゼロの接続IDを提供するエンドポイントは、TYPE PROTOCOL_VIOLATION型の接続エラーとしてRETIRE_CONNECTION_IDフレームの受信を扱う必要があります。
Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check reachability to the peer and for path validation during connection migration.
エンドポイントは、PATH_CHALLENGEフレーム（TYPE = 0x1A）を使用して、接続移行中のピアへの到達可能性とパス検証を確認できます。
PATH_CHALLENGE frames are formatted as shown in Figure 41.
PATH_CHALLENGEフレームは図41に示すようにフォーマットされています。
PATH_CHALLENGE Frame {
Type (i) = 0x1a,
Data (64),
}
Figure 41: PATH_CHALLENGE Frame Format
図41：PATH_CHALLENGEフレームフォーマット
PATH_CHALLENGE frames contain the following field:
PATH_CHALLENGEフレームには、次のフィールドが含まれています。
Data: This 8-byte field contains arbitrary data.
データ：この8バイトフィールドには任意のデータが含まれています。
Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that it is easier to receive the packet than it is to guess the value correctly.
PATH_CHALLENGEフレームで64ビットのエントロピーを含めることで、値を正しく推測することよりもパケットを受け取ることがより簡単なことを保証します。
The recipient of this frame MUST generate a PATH_RESPONSE frame (Section 19.18) containing the same Data value.
このフレームの受信者は、同じデータ値を含むPATH_RESPONSEフレーム（セクション19.18）を生成する必要があります。
A PATH_RESPONSE frame (type=0x1b) is sent in response to a PATH_CHALLENGE frame.
PATH_RESPONSEフレーム（Type = 0x1b）は、PATH_CHALLENGEフレームに応答して送信されます。
PATH_RESPONSE frames are formatted as shown in Figure 42. The format of a PATH_RESPONSE frame is identical to that of the PATH_CHALLENGE frame; see Section 19.17.
PATH_RESPONSEフレームは、図42に示すようにフォーマットされています.PATH_RESPONSEフレームのフォーマットはPATH_CHALLENGEフレームのフォーマットと同じです。19.17節を参照してください。
PATH_RESPONSE Frame {
Type (i) = 0x1b,
Data (64),
}
Figure 42: PATH_RESPONSE Frame Format
図42：PATH_RESPONSEフレームフォーマット
If the content of a PATH_RESPONSE frame does not match the content of a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint MAY generate a connection error of type PROTOCOL_VIOLATION.
PATH_RESPONSEフレームの内容が、エンドポイントによって以前に送信されたPATH_CHALLENGEフレームの内容と一致しない場合、エンドポイントはPROTOCOL_VIOLATION型の接続エラーを生成することがあります。
An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to notify its peer that the connection is being closed. The CONNECTION_CLOSE frame with a type of 0x1c is used to signal errors at only the QUIC layer, or the absence of errors (with the NO_ERROR code). The CONNECTION_CLOSE frame with a type of 0x1d is used to signal an error with the application that uses QUIC.
エンドポイントは、接続が閉じられていることをピアに通知するために、CONNECTION_CLOSEフレーム（type = 0x1cまたは0x1d）を送信します。0x1cのタイプのCONNECTION_CLOSEフレームは、QUICレイヤのみのエラー、またはエラーがない（NO_ERRORコードを使用して）エラーの信号を送信するために使用されます。0x1dのタイプのCONNECTION_CLOSEフレームは、QUICを使用するアプリケーションでエラーを通知するために使用されます。
If there are open streams that have not been explicitly closed, they are implicitly closed when the connection is closed.
明示的に閉じられていないオープンストリームがある場合は、接続が閉じられていると暗黙的に閉じられます。
CONNECTION_CLOSE frames are formatted as shown in Figure 43.
CONNECTION_CLOSEフレームは図43に示すようにフォーマットされています。
CONNECTION_CLOSE Frame {
Type (i) = 0x1c..0x1d,
Error Code (i),
[Frame Type (i)],
Reason Phrase Length (i),
Reason Phrase (..),
}
Figure 43: CONNECTION_CLOSE Frame Format
図43：CONNECTION_CLOSEフレームフォーマット
CONNECTION_CLOSE frames contain the following fields:
CONNECTION_CLOSEフレームには、次のフィールドが含まれています。
Error Code: A variable-length integer that indicates the reason for closing this connection. A CONNECTION_CLOSE frame of type 0x1c uses codes from the space defined in Section 20.1. A CONNECTION_CLOSE frame of type 0x1d uses codes defined by the application protocol; see Section 20.2.
エラーコード：この接続を閉じる理由を示す可変長整数。Type 0x1cのCONNECTION_CLOSEフレームは、セクション20.1で定義されているスペースのコードを使用します。Type 0x1DのCONNECTION_CLOSEフレームは、アプリケーションプロトコルによって定義されたコードを使用します。20.2を参照してください。
Frame Type: A variable-length integer encoding the type of frame that triggered the error. A value of 0 (equivalent to the mention of the PADDING frame) is used when the frame type is unknown. The application-specific variant of CONNECTION_CLOSE (type 0x1d) does not include this field.
フレームタイプ：エラーをトリガーしたフレームの種類をエンコードする可変長整数。フレームタイプが不明である場合は、値0（パディングフレームの説明と同等）が使用されます。connection_close（type 0x1d）のアプリケーション固有のバリアントには、このフィールドは含まれていません。
Reason Phrase Length: A variable-length integer specifying the length of the reason phrase in bytes. Because a CONNECTION_CLOSE frame cannot be split between packets, any limits on packet size will also limit the space available for a reason phrase.
理由句の長さ：理由フレーズの長さをバイト単位で指定する可変長整数。CONNECTION_CLOSEフレームはパケット間で分割できないため、パケットサイズの任意の制限も理由フレーズに使用可能なスペースを制限します。
Reason Phrase: Additional diagnostic information for the closure. This can be zero length if the sender chooses not to give details beyond the Error Code value. This SHOULD be a UTF-8 encoded string [RFC3629], though the frame does not carry information, such as language tags, that would aid comprehension by any entity other than the one that created the text.
理由句：クロージャーの追加の診断情報。送信者がエラーコード値を超えて詳細を与えないと選択した場合、これは長さゼロになる可能性があります。これはUTF-8エンコード文字列[RFC3629]でなければなりませんが、フレームは言語タグなどの情報を持ちません。
The application-specific variant of CONNECTION_CLOSE (type 0x1d) can only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an application wishes to abandon a connection during the handshake, an endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error code of APPLICATION_ERROR in an Initial or Handshake packet.
connection_close（タイプ0x1d）のアプリケーション固有のバリアントは、0-RTTまたは1-RTTパケットを使用してのみ送信できます。12.5項を参照してください。アプリケーションがハンドシェイク中に接続を放棄したい場合、エンドポイントは、最初のまたはハンドシェイクパケット内のAPPLICATION_ERRORのエラーコードでCONNECTION_CLOSEフレーム（タイプ0x1C）を送信できます。
The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal confirmation of the handshake to the client.
サーバーは、ハンドシェイクを使用して、ハンドシェイクの確認をクライアントに送信するために使用します。
HANDSHAKE_DONE frames are formatted as shown in Figure 44, which shows that HANDSHAKE_DONE frames have no content.
HANDSHAKE_DONEフレームは図44に示すようにフォーマットされています。これは、HANDSHAKE_DONEフレームにコンテンツがないことを示しています。
HANDSHAKE_DONE Frame {
Type (i) = 0x1e,
}
Figure 44: HANDSHAKE_DONE Frame Format
図44：HANDSHAKE_DONEフレームフォーマット
A HANDSHAKE_DONE frame can only be sent by the server. Servers MUST NOT send a HANDSHAKE_DONE frame before completing the handshake. A server MUST treat receipt of a HANDSHAKE_DONE frame as a connection error of type PROTOCOL_VIOLATION.
HANDSHAKE_DONEフレームはサーバーによってのみ送信できます。ハンドシェイクを完了する前に、サーバーはHANDSHAKE_DONEフレームを送信してはいけません。サーバーは、PROTOCOL_VIOLATION型の接続エラーとしてHANDSHAKE_DONEフレームの受信を扱う必要があります。
QUIC frames do not use a self-describing encoding. An endpoint therefore needs to understand the syntax of all frames before it can successfully process a packet. This allows for efficient encoding of frames, but it means that an endpoint cannot send a frame of a type that is unknown to its peer.
QUICフレームは、自己記述符号化を使用しません。したがって、エンドポイントは、パケットを正常に処理する前に、すべてのフレームの構文を理解する必要があります。これにより、フレームの効率的なエンコーディングが可能になりますが、エンドポイントがピアに不明のタイプのフレームを送信できないことを意味します。
An extension to QUIC that wishes to use a new type of frame MUST first ensure that a peer is able to understand the frame. An endpoint can use a transport parameter to signal its willingness to receive extension frame types. One transport parameter can indicate support for one or more extension frame types.
新しいタイプのフレームを使用することを望むQUICへの拡張は、最初にピアがフレームを理解できるようにする必要があります。エンドポイントは、トランスポートパラメータを使用して、拡張フレームタイプを受信するためのその意欲を知らせることができます。1つのトランスポートパラメータは、1つ以上の拡張フレームタイプのサポートを示すことができます。
Extensions that modify or replace core protocol functionality (including frame types) will be difficult to combine with other extensions that modify or replace the same functionality unless the behavior of the combination is explicitly defined. Such extensions SHOULD define their interaction with previously defined extensions modifying the same protocol components.
コアプロトコル機能（フレームタイプを含む）を変更または置換する拡張機能は、組み合わせの動作が明示的に定義されていない限り、同じ機能を変更または置き換える他の拡張と組み合わせることは困難になります。そのような拡張機能は、同じプロトコルコンポーネントを修正する以前に定義された拡張機能との対話を定義する必要があります。
Extension frames MUST be congestion controlled and MUST cause an ACK frame to be sent. The exception is extension frames that replace or supplement the ACK frame. Extension frames are not included in flow control unless specified in the extension.
拡張フレームは輻輳制御されなければならず、ACKフレームを送信させる必要があります。例外は、ACKフレームを置き換えるか補足する拡張フレームです。拡張子に指定されていない限り、拡張フレームはフロー制御に含まれていません。
An IANA registry is used to manage the assignment of frame types; see Section 22.4.
IANAレジストリは、フレームタイプの割り当てを管理するために使用されます。22.4節を参照してください。
QUIC transport error codes and application error codes are 62-bit unsigned integers.
QUICのトランスポートエラーコードとアプリケーションエラーコードは62ビットの符号なし整数です。
This section lists the defined QUIC transport error codes that can be used in a CONNECTION_CLOSE frame with a type of 0x1c. These errors apply to the entire connection.
このセクションでは、0x1cのタイプのCONNECTION_CLOSEフレームで使用できる定義済みのQUICトランスポートエラーコードをリストします。これらのエラーは接続全体に適用されます。
NO_ERROR (0x00): An endpoint uses this with CONNECTION_CLOSE to signal that the connection is being closed abruptly in the absence of any error.
NO_ERROR（0x00）：エンドポイントはこれをconnection_closeで使用して、エラーがない場合に接続が急激に閉じられていることを示します。
INTERNAL_ERROR (0x01): The endpoint encountered an internal error and cannot continue with the connection.
INTERNAL_ERROR（0x01）：エンドポイントが内部エラーを検出し、接続を続行できません。
CONNECTION_REFUSED (0x02): The server refused to accept a new connection.
CONNECTION_REFUSED（0x02）：サーバーは新しい接続を受け入れることを拒否しました。
FLOW_CONTROL_ERROR (0x03): An endpoint received more data than it permitted in its advertised data limits; see Section 4.
FLOW_CONTROL_ERROR（0x03）：エンドポイントは、そのアドバタイズされたデータ制限で許可されているよりも多くのデータを受信しました。セクション4を参照してください。
STREAM_LIMIT_ERROR (0x04): An endpoint received a frame for a stream identifier that exceeded its advertised stream limit for the corresponding stream type.
STREAM_LIMIT_ERROR（0x04）：エンドポイントは、対応するストリームタイプのアドバタイズされたストリーム制限を超えたストリーム識別子のフレームを受信しました。
STREAM_STATE_ERROR (0x05): An endpoint received a frame for a stream that was not in a state that permitted that frame; see Section 3.
STREAM_STATE_ERROR（0x05）：エンドポイントは、そのフレームを許可した状態にないストリームのフレームを受信しました。セクション3を参照してください。
FINAL_SIZE_ERROR (0x06): (1) An endpoint received a STREAM frame containing data that exceeded the previously established final size, (2) an endpoint received a STREAM frame or a RESET_STREAM frame containing a final size that was lower than the size of stream data that was already received, or (3) an endpoint received a STREAM frame or a RESET_STREAM frame containing a different final size to the one already established.
FINAL_SIZE_ERROR（0x06）：（1）以前に確立された最終サイズを超えたデータを含むストリームフレームを受信しました。（2）エンドポイントがストリームフレームまたはストリームデータのサイズより低い最終サイズを含むRESET_STREAMフレームを受信しました。これはすでに受信されていました。
FRAME_ENCODING_ERROR (0x07): An endpoint received a frame that was badly formatted -- for instance, a frame of an unknown type or an ACK frame that has more acknowledgment ranges than the remainder of the packet could carry.
FRAME_ENCODING_ERROR（0x07）：エンドポイントは、不明なフォーマットされたフレームを受信しました - 例えば、パケットの残りの部分よりも多くの確認応答範囲を持つ、未知のタイプまたはACKフレームのフレームを受け取りました。
TRANSPORT_PARAMETER_ERROR (0x08): An endpoint received transport parameters that were badly formatted, included an invalid value, omitted a mandatory transport parameter, included a forbidden transport parameter, or were otherwise in error.
TRANSPORT_PARAMETER_ERROR（0x08）：不正なフォーマットされたエンドポイントにアクセスされたトランスポートパラメータは、無効な値を含め、必須のトランスポートパラメータを省略し、禁止されたトランスポートパラメータを含めて、またはエラーにあった。
CONNECTION_ID_LIMIT_ERROR (0x09): The number of connection IDs provided by the peer exceeds the advertised active_connection_id_limit.
CONNECTION_ID_LIMIT_ERROR（0x09）：ピアによって提供される接続IDの数がアドバタイズされたactive_connection_id_limitを超えています。
PROTOCOL_VIOLATION (0x0a): An endpoint detected an error with protocol compliance that was not covered by more specific error codes.
PROTOCOL_VIOLATION（0x0a）：エンドポイントが、より具体的なエラーコードでカバーされていないプロトコルコンプライアンスのエラーを検出しました。
INVALID_TOKEN (0x0b): A server received a client Initial that contained an invalid Token field.
INVALID_TOKEN（0x0b）：無効なトークンフィールドを含むクライアントのイニシャルを受信しました。
APPLICATION_ERROR (0x0c): The application or application protocol caused the connection to be closed.
APPLICATION_ERROR（0x0c）：アプリケーションプロトコルまたはアプリケーションプロトコルは、接続を閉じました。
CRYPTO_BUFFER_EXCEEDED (0x0d): An endpoint has received more data in CRYPTO frames than it can buffer.
CRYPTO_BUFFER_EXCEEDED（0x0d）：エンドポイントは、バッファをバッファすることができるよりも暗号フレームでデータを受信しました。
KEY_UPDATE_ERROR (0x0e): An endpoint detected errors in performing key updates; see Section 6 of [QUIC-TLS].
KEY_UPDATE_ERROR（0x0e）：キーアップデートを実行する際のエンドポイントがエラーを検出しました。[QUIC-TLS]の6項を参照してください。
AEAD_LIMIT_REACHED (0x0f): An endpoint has reached the confidentiality or integrity limit for the AEAD algorithm used by the given connection.
AEAD_LIMIT_REACHED（0x0f）：エンドポイントが、与えられた接続によって使用されるAEDアルゴリズムの機密性または完全性の制限に達しました。
NO_VIABLE_PATH (0x10): An endpoint has determined that the network path is incapable of supporting QUIC. An endpoint is unlikely to receive a CONNECTION_CLOSE frame carrying this code except when the path does not support a large enough MTU.
NO_VIAULE_PATH（0x10）：ネットワークパスがQUICをサポートすることができないと判断しました。エンドポイントは、パスが十分なMTUをサポートしていない場合を除いて、このコードを搬送するCONNECTION_CLOSEフレームを受信することはほとんどありません。
CRYPTO_ERROR (0x0100-0x01ff): The cryptographic handshake failed. A range of 256 values is reserved for carrying error codes specific to the cryptographic handshake that is used. Codes for errors occurring when TLS is used for the cryptographic handshake are described in Section 4.8 of [QUIC-TLS].
CRYPTO_ERROR（0x0100-0x01ff）：暗号化ハンドシェイクが失敗しました。256の値の範囲は、使用される暗号化ハンドシェイクに固有のエラーコードを伝送するために予約されています。暗号化ハンドシェイクにTLSを使用した場合に発生するエラーのコードは、[QUIC-TLS]のセクション4.8で説明されています。
See Section 22.5 for details on registering new error codes.
新しいエラーコードの登録の詳細については、セクション22.5を参照してください。
In defining these error codes, several principles are applied. Error conditions that might require specific action on the part of a recipient are given unique codes. Errors that represent common conditions are given specific codes. Absent either of these conditions, error codes are used to identify a general function of the stack, like flow control or transport parameter handling. Finally, generic errors are provided for conditions where implementations are unable or unwilling to use more specific codes.
これらのエラーコードを定義する際には、いくつかの原則が適用されます。受信者の側で特定のアクションを必要とする可能性のあるエラー条件には、固有のコードが与えられます。一般的な条件を表すエラーは特定のコードを与えられます。これらの条件のいずれもなく、エラーコードは、フロー制御またはトランスポートパラメータの処理のように、スタックの一般関数を識別するために使用されます。最後に、実装がより多くの特定のコードを使用することができないか、または不本意な条件に一般的なエラーが提供されます。
The management of application error codes is left to application protocols. Application protocol error codes are used for the RESET_STREAM frame (Section 19.4), the STOP_SENDING frame (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d (Section 19.19).
アプリケーションエラーコードの管理はアプリケーションプロトコルに残されています。アプリケーションプロトコルエラーコードは、RESET_STREAMフレーム（セクション19.4）、STOP_SENDINGフレーム（セクション19.5）、および0x1DのタイプのCONNECTION_CLOSEフレームに使用されます（セクション19.19）。
The goal of QUIC is to provide a secure transport connection. Section 21.1 provides an overview of those properties; subsequent sections discuss constraints and caveats regarding these properties, including descriptions of known attacks and countermeasures.
QUICの目的は安全なトランスポート接続を提供することです。セクション21.1にそれらのプロパティの概要を説明します。後続のセクションでは、既知の攻撃や対策の説明を含む、これらのプロパティに関する制約と警告について説明します。
A complete security analysis of QUIC is outside the scope of this document. This section provides an informal description of the desired security properties as an aid to implementers and to help guide protocol analysis.
QUICの完全なセキュリティ分析はこの文書の範囲外です。このセクションでは、実装者への援助として、およびプロトコル分析のガイドを支援するための希望のセキュリティプロパティの非公式の説明を提供します。
QUIC assumes the threat model described in [SEC-CONS] and provides protections against many of the attacks that arise from that model.
QUICは[SEC-CONS]に記載されている脅威モデルを想定し、そのモデルから発生する多くの攻撃に対する保護を提供します。
For this purpose, attacks are divided into passive and active attacks. Passive attackers have the ability to read packets from the network, while active attackers also have the ability to write packets into the network. However, a passive attack could involve an attacker with the ability to cause a routing change or other modification in the path taken by packets that comprise a connection.
この目的のために、攻撃は受動的および能動的な攻撃に分けられます。受動的な攻撃者はネットワークからパケットを読み取る能力を持っていますが、アクティブな攻撃者もパケットをネットワークに書き込むことができます。しかしながら、受動的な攻撃は、接続を構成するパケットによって取られた経路内でルーティング変更またはその他の変更を引き起こす能力を持つ攻撃者を含み得る。
Attackers are additionally categorized as either on-path attackers or off-path attackers. An on-path attacker can read, modify, or remove any packet it observes such that the packet no longer reaches its destination, while an off-path attacker observes the packets but cannot prevent the original packet from reaching its intended destination. Both types of attackers can also transmit arbitrary packets. This definition differs from that of Section 3.5 of [SEC-CONS] in that an off-path attacker is able to observe packets.
攻撃者は、On-Path攻撃者またはオフパスの攻撃者としてさらに分類されています。オンパス攻撃者は、オフパス攻撃者がパケットを監視しているが、オフパス攻撃者がパケットを監視するが、元のパケットが意図された目的地に到達するのを防ぐことができないように、任意のパケットを読み、変更、または削除することができる。両方のタイプの攻撃者は任意のパケットを送信することもできます。オフパスの攻撃者がパケットを観察できるという点で、この定義は[SEC-CONS]のセクション3.5のセクション3.5とは異なります。
Properties of the handshake, protected packets, and connection migration are considered separately.
ハンドシェイク、保護パケット、および接続移行のプロパティは別々に見なされます。
The QUIC handshake incorporates the TLS 1.3 handshake and inherits the cryptographic properties described in Appendix E.1 of [TLS13]. Many of the security properties of QUIC depend on the TLS handshake providing these properties. Any attack on the TLS handshake could affect QUIC.
QUICハンドシェイクはTLS 1.3ハンドシェイクを組み込んでおり、[TLS13]の付録E.1に記載されている暗号プロパティを継承します。QUICのセキュリティプロパティの多くは、これらのプロパティを提供するTLSハンドシェイクによって異なります。TLSハンドシェイクへの攻撃はQUICに影響を与える可能性があります。
Any attack on the TLS handshake that compromises the secrecy or uniqueness of session keys, or the authentication of the participating peers, affects other security guarantees provided by QUIC that depend on those keys. For instance, migration (Section 9) depends on the efficacy of confidentiality protections, both for the negotiation of keys using the TLS handshake and for QUIC packet protection, to avoid linkability across network paths.
セッションキーの秘密または一意性を損なうTLSハンドシェイク、または参加者の認証を犠牲にするTLSハンドシェイクでの攻撃は、それらのキーに依存するQUICによって提供される他のセキュリティ保証に影響します。たとえば、移行（セクション9）は、ネットワークパスを越えたリンク性を避けるために、TLSハンドシェイクを使用したキーのネゴシエーションとQUICのパケット保護の両方を使用するための機密保護の有効性に依存します。
An attack on the integrity of the TLS handshake might allow an attacker to affect the selection of application protocol or QUIC version.
TLSハンドシェイクの完全性に対する攻撃により、攻撃者はアプリケーションプロトコルまたはQUICバージョンの選択に影響を与える可能性があります。
In addition to the properties provided by TLS, the QUIC handshake provides some defense against DoS attacks on the handshake.
TLSによって提供されるプロパティに加えて、QUICハンドシェイクはハンドシェイクに対するDOS攻撃に対していくつかの防御を提供します。
Address validation (Section 8) is used to verify that an entity that claims a given address is able to receive packets at that address. Address validation limits amplification attack targets to addresses for which an attacker can observe packets.
アドレス検証（セクション8）は、特定のアドレスを主張するエンティティがそのアドレスでパケットを受信できることを確認するために使用されます。アドレス検証は、攻撃者がパケットを観察できるアドレスに増幅攻撃ターゲットを制限します。
Prior to address validation, endpoints are limited in what they are able to send. Endpoints cannot send data toward an unvalidated address in excess of three times the data received from that address.
アドレス検証の前に、エンドポイントは送信できるもので制限されています。エンドポイントは、そのアドレスから受信したデータの3倍を超えることを超えてデータを送信することはできません。
Note: The anti-amplification limit only applies when an endpoint responds to packets received from an unvalidated address. The anti-amplification limit does not apply to clients when establishing a new connection or when initiating connection migration.
注：アンプ攻撃の防止制限は、エンドポイントが未検証のアドレスから受信したパケットに応答する場合にのみ適用されます。増幅防止の制限は、新しい接続を確立するとき、または接続の移行を開始するときのクライアントには適用されません。
Computing the server's first flight for a full handshake is potentially expensive, requiring both a signature and a key exchange computation. In order to prevent computational DoS attacks, the Retry packet provides a cheap token exchange mechanism that allows servers to validate a client's IP address prior to doing any expensive computations at the cost of a single round trip. After a successful handshake, servers can issue new tokens to a client, which will allow new connection establishment without incurring this cost.
フルハンドシェイクのサーバーの最初のフライトを計算することは潜在的に高価であり、署名と鍵交換計算の両方を必要とします。計算DOS攻撃を防ぐために、再試行パケットは、1回のラウンドトリップの費用で高価な計算を行う前に、サーバーがクライアントのIPアドレスを検証することを可能にする安価なトークン交換メカニズムを提供します。ハンドシェイクが成功したら、サーバーはクライアントに新しいトークンを発行できます。これにより、このコストを招くことなく新しい接続確立が可能になります。
An on-path or off-path attacker can force a handshake to fail by replacing or racing Initial packets. Once valid Initial packets have been exchanged, subsequent Handshake packets are protected with the Handshake keys, and an on-path attacker cannot force handshake failure other than by dropping packets to cause endpoints to abandon the attempt.
オンパスまたはオフパスの攻撃者は、最初のパケットを置き換えるかまたはレーシングすることによってハンドシェイクを失敗させることができます。有効な初期パケットが交換されたら、後続のハンドシェイクパケットがハンドシェイクキーで保護され、オンパス攻撃者はパケットをドロップすること以外にハンドシェイクの失敗を強制することはできません。エンドポイントが試みを放棄することができます。
An on-path attacker can also replace the addresses of packets on either side and therefore cause the client or server to have an incorrect view of the remote addresses. Such an attack is indistinguishable from the functions performed by a NAT.
オンパス攻撃者は、両側のパケットのアドレスを置き換えることができ、したがって、クライアントまたはサーバーにリモートアドレスの誤ったビューを持つことができます。そのような攻撃は、NATによって実行される機能と区別がつかないです。
The entire handshake is cryptographically protected, with the Initial packets being encrypted with per-version keys and the Handshake and later packets being encrypted with keys derived from the TLS key exchange. Further, parameter negotiation is folded into the TLS transcript and thus provides the same integrity guarantees as ordinary TLS negotiation. An attacker can observe the client's transport parameters (as long as it knows the version-specific salt) but cannot observe the server's transport parameters and cannot influence parameter negotiation.
ハンドシェイク全体は暗号的に保護されており、初期パケットはバージョンごとのキーとハンドシェイク以降のパケットがTLSキー交換から派生したキーで暗号化されている。さらに、パラメータネゴシエーションはTLSトランスクリプトに折り畳まれ、したがって通常のTLSネゴシエーションと同じ完全性保証を提供する。攻撃者は（バージョン固有の塩を知っている限り）クライアントのトランスポートパラメータを観察することができますが、サーバーのトランスポートパラメータを監視できず、パラメータネゴシエーションに影響を与えることはできません。
Connection IDs are unencrypted but integrity protected in all packets.
接続IDは暗号化されていませんが、すべてのパケットで保護されています。
This version of QUIC does not incorporate a version negotiation mechanism; implementations of incompatible versions will simply fail to establish a connection.
このバージョンのQUICにはバージョンネゴシエーションメカニズムが組み込まれていません。互換性のないバージョンの実装は、単に接続を確立することができません。
Packet protection (Section 12.1) applies authenticated encryption to all packets except Version Negotiation packets, though Initial and Retry packets have limited protection due to the use of version-specific keying material; see [QUIC-TLS] for more details. This section considers passive and active attacks against protected packets.
パケット保護（セクション12.1）は、バージョン固有の鍵生成マテリアルの使用により、最初とリトライパケットがバージョンネゴシエーションパケットを除くすべてのパケットに認証された暗号化を適用します。詳細については[QUIC-TLS]を参照してください。このセクションでは、保護されたパケットに対するパッシブとアクティブな攻撃を考慮しています。
Both on-path and off-path attackers can mount a passive attack in which they save observed packets for an offline attack against packet protection at a future time; this is true for any observer of any packet on any network.
オンパス攻撃者とオフパスの両方の攻撃者は、将来のパケット保護に対するオフライン攻撃のために観測されたパケットを保存する受動攻撃をマウントできます。これは、任意のネットワーク上の任意のパケットの任意のオブザーバにも当てはまります。
An attacker that injects packets without being able to observe valid packets for a connection is unlikely to be successful, since packet protection ensures that valid packets are only generated by endpoints that possess the key material established during the handshake; see Sections 7 and 21.1.1. Similarly, any active attacker that observes packets and attempts to insert new data or modify existing data in those packets should not be able to generate packets deemed valid by the receiving endpoint, other than Initial packets.
パケット保護は、有効なパケットがハンドシェイク中に確立されたキーマテリアルを持つエンドポイントによってのみ生成されることを保証するため、接続のための有効なパケットを監視することはできません。セクション7と21.1.1を参照してください。同様に、パケットを監視し、それらのパケット内の新しいデータを挿入するか、またはそれらのパケット内の既存のデータを変更しようとするアクティブな攻撃者は、最初のパケット以外の受信エンドポイントによって有効なパケットを生成することはできません。
A spoofing attack, in which an active attacker rewrites unprotected parts of a packet that it forwards or injects, such as the source or destination address, is only effective if the attacker can forward packets to the original endpoint. Packet protection ensures that the packet payloads can only be processed by the endpoints that completed the handshake, and invalid packets are ignored by those endpoints.
アクティブな攻撃者が、送信元または宛先アドレスなどの侵入が推奨されていないパケットの保護されていない部分を書き換える偽装攻撃は、攻撃者がパケットを元のエンドポイントに転送できる場合にのみ有効です。パケット保護は、パケットペイロードがハンドシェイクを完了したエンドポイントによってのみ処理できるようにし、無効なパケットはそれらのエンドポイントによって無視されます。
An attacker can also modify the boundaries between packets and UDP datagrams, causing multiple packets to be coalesced into a single datagram or splitting coalesced packets into multiple datagrams. Aside from datagrams containing Initial packets, which require padding, modification of how packets are arranged in datagrams has no functional effect on a connection, although it might change some performance characteristics.
攻撃者はまた、パケットとUDPデータグラムの間の境界を変更することができ、複数のパケットを単一のデータグラムに合体するか、合体パケットを複数のデータグラムに分割することができます。パディングが必要な初期パケットを含むデータグラムを含むデータグラムは、データグラムにパケットがどのように配置されているかの変更は、ある程度の性能特性を変更する可能性がありますが、接続に機能的な影響を与えません。
Connection migration (Section 9) provides endpoints with the ability to transition between IP addresses and ports on multiple paths, using one path at a time for transmission and receipt of non-probing frames. Path validation (Section 8.2) establishes that a peer is both willing and able to receive packets sent on a particular path. This helps reduce the effects of address spoofing by limiting the number of packets sent to a spoofed address.
接続移行（セクション9）は、非プロービングフレームの送信と受信のために、1つのパスを使用して、1つのパスを使用して、複数のパス上のIPアドレスとポート間の遷移機能を持つエンドポイントを提供します。PATH検証（セクション8.2）ピアが特定のパスで送信されたパケットを受信できることを両方とも受信できることを確立します。これにより、偽装アドレスに送信されたパケットの数を制限することで、アドレスのスプーフィングの影響を少なくするのが役立ちます。
This section describes the intended security properties of connection migration under various types of DoS attacks.
このセクションでは、さまざまな種類のDOS攻撃の下での接続移行の意図されたセキュリティプロパティについて説明します。
An attacker that can cause a packet it observes to no longer reach its intended destination is considered an on-path attacker. When an attacker is present between a client and server, endpoints are required to send packets through the attacker to establish connectivity on a given path.
目的の目的地に到達しなくなるという観察を妨げる可能性がある攻撃者は、On-Path攻撃者と見なされます。クライアントとサーバーの間に攻撃者が存在する場合、エンドポイントは攻撃者を介してパケットを送信して特定のパスで接続を確立する必要があります。
An on-path attacker can:
オンパス攻撃者は次のことができます。
* Inspect packets
* パケットを検査します
* Modify IP and UDP packet headers
* IPとUDPのパケットヘッダーを変更します
* Inject new packets
* 新しいパケットを注入します
* Delay packets
* パケットを遅らせる
* Reorder packets
* パケットを並べ替える
* Drop packets
* ドロップパケット
* Split and merge datagrams along packet boundaries
* パケットの境界線に沿ってデータグラムを分割してマージします
An on-path attacker cannot:
オンパス攻撃者は次のことができません：
* Modify an authenticated portion of a packet and cause the recipient to accept that packet
* パケットの認証された部分を変更し、受信者にそのパケットを受け入れる原因となります。
An on-path attacker has the opportunity to modify the packets that it observes; however, any modifications to an authenticated portion of a packet will cause it to be dropped by the receiving endpoint as invalid, as packet payloads are both authenticated and encrypted.
オンパス攻撃者は、それが観察するパケットを修正する機会を持っています。しかしながら、パケットペイロードが認証され暗号化されているので、パケットの認証部分に対する修正は無効として受信エンドポイントによってドロップされることになる。
QUIC aims to constrain the capabilities of an on-path attacker as follows:
QUICは、オンパス攻撃者の機能を次のように制限することを目的としています。
1. An on-path attacker can prevent the use of a path for a connection, causing the connection to fail if it cannot use a different path that does not contain the attacker. This can be achieved by dropping all packets, modifying them so that they fail to decrypt, or other methods.
1. オンパス攻撃者は、接続のパスの使用を防ぐことができ、攻撃者を含まない別のパスを使用できない場合に接続が失敗する可能性があります。これは、すべてのパケットを削除し、それらが復号化できないようにそれらを修正することによって達成することができます。
2. An on-path attacker can prevent migration to a new path for which the attacker is also on-path by causing path validation to fail on the new path.
2. オンパス攻撃者は、パス検証を新しいパスで失敗させることによって、攻撃者がオンパスである新しいパスへの移行を防ぐことができます。
3. An on-path attacker cannot prevent a client from migrating to a path for which the attacker is not on-path.
3. オンパス攻撃者は、クライアントが攻撃者がパス上ではないパスに移行するのを防ぐことはできません。
4. An on-path attacker can reduce the throughput of a connection by delaying packets or dropping them.
4. オンパス攻撃者は、パケットを遅らせるか削除することによって、接続のスループットを低下させる可能性があります。
5. An on-path attacker cannot cause an endpoint to accept a packet for which it has modified an authenticated portion of that packet.
5. オンパス攻撃者は、エンドポイントがそのパケットの認証された部分を変更したパケットを受け入れることができません。
An off-path attacker is not directly on the path between a client and server but could be able to obtain copies of some or all packets sent between the client and the server. It is also able to send copies of those packets to either endpoint.
オフパスの攻撃者は、クライアントとサーバー間のパスに直接ありませんが、クライアントとサーバー間で送信された一部またはすべてのパケットのコピーを取得できる可能性があります。それらのパケットのコピーをどちらかのエンドポイントに送信することもできます。
An off-path attacker can:
オフパスの攻撃者は次のことができます：
* Inspect packets
* パケットを検査します
* Inject new packets
* 新しいパケットを注入します
* Reorder injected packets
* 注入されたパケットを並べ替えます
An off-path attacker cannot:
オフパスの攻撃者は次のことができません：
* Modify packets sent by endpoints
* エンドポイントによって送信されたパケットを変更します
* Delay packets
* パケットを遅らせる
* Drop packets
* ドロップパケット
* Reorder original packets
* オリジナルのパケットを並べ替える
An off-path attacker can create modified copies of packets that it has observed and inject those copies into the network, potentially with spoofed source and destination addresses.
オフパス攻撃者は、スプーフィングされた送信元アドレスと宛先アドレスを使用して、観察してそれらのコピーをネットワークに注入したパケットの変更コピーを作成できます。
For the purposes of this discussion, it is assumed that an off-path attacker has the ability to inject a modified copy of a packet into the network that will reach the destination endpoint prior to the arrival of the original packet observed by the attacker. In other words, an attacker has the ability to consistently "win" a race with the legitimate packets between the endpoints, potentially causing the original packet to be ignored by the recipient.
この説明の目的のために、オフパス攻撃者は、攻撃者によって観察された元のパケットの到着前に宛先エンドポイントに到達するネットワークへのパケットの変更されたコピーを注入することができると仮定される。言い換えれば、攻撃者は、エンドポイント間の合法的なパケットと一貫して「勝つ」という能力を有し、元のパケットが受信者によって無視される可能性がある。
It is also assumed that an attacker has the resources necessary to affect NAT state. In particular, an attacker can cause an endpoint to lose its NAT binding and then obtain the same port for use with its own traffic.
攻撃者がNAT状態に影響を与えるために必要なリソースを持っていると仮定されています。特に、攻撃者は、エンドポイントがそのNATバインディングを失い、次にそれ自身のトラフィックで使用するために同じポートを取得する可能性があります。
QUIC aims to constrain the capabilities of an off-path attacker as follows:
QUICは、オフパス攻撃者の機能を次のように制限することを目的としています。
1. An off-path attacker can race packets and attempt to become a "limited" on-path attacker.
1. オフパスの攻撃者は、パケットをレースにして、「限られた」オンパス攻撃者になることを試みることができます。
2. An off-path attacker can cause path validation to succeed for forwarded packets with the source address listed as the off-path attacker as long as it can provide improved connectivity between the client and the server.
2. オフパス攻撃者は、クライアントとサーバー間の接続性が向上する限り、オフパス攻撃者としてリストされている送信元アドレスを持つ転送パケットに対してパス検証を成功させる可能性があります。
3. An off-path attacker cannot cause a connection to close once the handshake has completed.
3. ハンドシェイクが完了すると、オフパスの攻撃者が接続を閉じることはできません。
4. An off-path attacker cannot cause migration to a new path to fail if it cannot observe the new path.
4. オフパス攻撃者は、新しいパスを監視できない場合に新しいパスへの移行を失敗させることはできません。
5. An off-path attacker can become a limited on-path attacker during migration to a new path for which it is also an off-path attacker.
5. オフパス攻撃者は、オフパス攻撃者である新しいパスへの移行中に、制限されたオンパス攻撃者になる可能性があります。
6. An off-path attacker can become a limited on-path attacker by affecting shared NAT state such that it sends packets to the server from the same IP address and port that the client originally used.
6. オフパスの攻撃者は、クライアントが最初に使用されたのと同じIPアドレスとポートからパケットをサーバーに送信するように、共有NAT状態に影響を与えることで、制限されたオンパス攻撃者になることがあります。
A limited on-path attacker is an off-path attacker that has offered improved routing of packets by duplicating and forwarding original packets between the server and the client, causing those packets to arrive before the original copies such that the original packets are dropped by the destination endpoint.
制限されたオンパス攻撃者は、サーバーとクライアントの間の元のパケットを複製して転送することによってパケットのルーティングを改善したオフパス攻撃者で、元のパケットがドロップされるように元のコピーの前に到着する。宛先エンドポイント
A limited on-path attacker differs from an on-path attacker in that it is not on the original path between endpoints, and therefore the original packets sent by an endpoint are still reaching their destination. This means that a future failure to route copied packets to the destination faster than their original path will not prevent the original packets from reaching the destination.
制限されたオンパス攻撃者は、エンドポイント間の元のパスにはないという点で、オンパスの攻撃者とは異なります。したがって、エンドポイントによって送信された元のパケットはまだ目的地に到達しています。つまり、コピーされたパケットを元のパスよりも早く宛先にルーティングすることに失敗したことは、元のパケットが宛先に到達するのを妨げることはありません。
A limited on-path attacker can:
制限されたオンパス攻撃者は次のことができます：
* Inspect packets
* パケットを検査します
* Inject new packets
* 新しいパケットを注入します
* Modify unencrypted packet headers
* 暗号化されていないパケットヘッダーを変更します
* Reorder packets
* パケットを並べ替える
A limited on-path attacker cannot:
制限されたオンパス攻撃者は次のことができません：
* Delay packets so that they arrive later than packets sent on the original path
* オリジナルのパスで送信されたパケットより後に到着するようにパケットを遅らせること
* Drop packets
* パケットの破棄
* Modify the authenticated and encrypted portion of a packet and cause the recipient to accept that packet
* パケットの認証済みおよび暗号化部分を変更し、受信者にそのパケットを受け入れるように変更すること
A limited on-path attacker can only delay packets up to the point that the original packets arrive before the duplicate packets, meaning that it cannot offer routing with worse latency than the original path. If a limited on-path attacker drops packets, the original copy will still arrive at the destination endpoint.
制限されたオンパス攻撃者は、元のパケットが重複したパケットの前に到着するという点までの間だけパケットを遅らせることができます。つまり、元のパスよりも悪い待ち時間でルーティングを提供することはできません。制限されたオンパス攻撃者がパケットを削除すると、元のコピーは宛先エンドポイントに到着します。
QUIC aims to constrain the capabilities of a limited off-path attacker as follows:
QUICは、制限されたオフパス攻撃者の機能を次のように制限することを目的としています。
1. A limited on-path attacker cannot cause a connection to close once the handshake has completed.
1. ハンドシェイクが完了したら、制限されたオンパス攻撃者が閉じることはできません。
2. A limited on-path attacker cannot cause an idle connection to close if the client is first to resume activity.
2. クライアントが最初にアクティビティを再開した場合に、制限されたオンパス攻撃者がアイドル接続を閉じることはできません。
3. A limited on-path attacker can cause an idle connection to be deemed lost if the server is the first to resume activity.
3. 制限されたオンパス攻撃者は、サーバーが最初のアクティビティの最初のものである場合、アイドル接続が失われると見なされる可能性があります。
Note that these guarantees are the same guarantees provided for any NAT, for the same reasons.
これらの保証は、同じ理由で、NATのために提供されるのと同じ保証です。
As an encrypted and authenticated transport, QUIC provides a range of protections against denial of service. Once the cryptographic handshake is complete, QUIC endpoints discard most packets that are not authenticated, greatly limiting the ability of an attacker to interfere with existing connections.
暗号化され認証されたトランスポートとして、QUICはサービス拒否に対する範囲の保護を提供します。暗号化ハンドシェイクが完了すると、QUICエンドポイントは認証されていないほとんどのパケットを破棄し、攻撃者が既存の接続を妨害する機能を大幅に制限します。
Once a connection is established, QUIC endpoints might accept some unauthenticated ICMP packets (see Section 14.2.1), but the use of these packets is extremely limited. The only other type of packet that an endpoint might accept is a stateless reset (Section 10.3), which relies on the token being kept secret until it is used.
接続が確立されると、QUICのエンドポイントはいくつかの未認証されていないICMPパケットを受け入れることがあります（セクション14.2.1を参照）、これらのパケットの使用は非常に限られています。エンドポイントが受け入れる可能性があるパケットの唯一のパケットは、ステートレスリセット（セクション10.3）です。これは、それが使用されるまで秘密にされているトークンに依存しています。
During the creation of a connection, QUIC only provides protection against attacks from off the network path. All QUIC packets contain proof that the recipient saw a preceding packet from its peer.
接続の作成中に、QUICはネットワークパスからの攻撃に対してのみ保護するだけです。すべてのQUICパケットには、受信者がそのピアから前のパケットを見たという証明が含まれています。
Addresses cannot change during the handshake, so endpoints can discard packets that are received on a different network path.
アドレスはハンドシェイク中に変更できないため、エンドポイントは別のネットワークパスで受信されたパケットを破棄できます。
The Source and Destination Connection ID fields are the primary means of protection against an off-path attack during the handshake; see Section 8.1. These are required to match those set by a peer. Except for Initial and Stateless Resets, an endpoint only accepts packets that include a Destination Connection ID field that matches a value the endpoint previously chose. This is the only protection offered for Version Negotiation packets.
送信元と宛先接続IDフィールドは、ハンドシェイク中のオフパス攻撃に対する保護の主な手段です。セクション8.1を参照してください。これらはピアによって設定されたものと一致する必要があります。初期リセットとステートレスリセットを除いて、エンドポイントは、以前に選択した値と一致する宛先接続IDフィールドを含むパケットのみを受け入れます。これはバージョンネゴシエーションパケットのために提供される唯一の保護です。
The Destination Connection ID field in an Initial packet is selected by a client to be unpredictable, which serves an additional purpose. The packets that carry the cryptographic handshake are protected with a key that is derived from this connection ID and a salt specific to the QUIC version. This allows endpoints to use the same process for authenticating packets that they receive as they use after the cryptographic handshake completes. Packets that cannot be authenticated are discarded. Protecting packets in this fashion provides a strong assurance that the sender of the packet saw the Initial packet and understood it.
初期パケット内の宛先接続IDフィールドは、予測不可能なクライアントによって選択され、追加の目的を果たす。暗号化ハンドシェイクを運ぶパケットは、この接続IDとQUICバージョンに固有の塩を派生させるキーで保護されています。これにより、エンドポイントは、暗号化ハンドシェイクが完了した後に使用するパケットを認証するために同じプロセスを使用することができます。認証できないパケットは破棄されます。この方法でパケットを保護すると、パケットの送信者が初期パケットを見て理解したという強力な保証が提供されます。
These protections are not intended to be effective against an attacker that is able to receive QUIC packets prior to the connection being established. Such an attacker can potentially send packets that will be accepted by QUIC endpoints. This version of QUIC attempts to detect this sort of attack, but it expects that endpoints will fail to establish a connection rather than recovering. For the most part, the cryptographic handshake protocol [QUIC-TLS] is responsible for detecting tampering during the handshake.
これらの保護は、接続が確立される前にQUICパケットを受信できる攻撃者に対して効果的であることを意図していません。そのような攻撃者は、QUICのエンドポイントによって受け入れられるパケットを潜在的に送信することができます。このバージョンのQUICはこの種の攻撃を検出しようとしていますが、エンドポイントが回復ではなく接続を確立できないことを期待しています。ほとんどの場合、暗号化ハンドシェイクプロトコル[QUIC-TLS]はハンドシェイク中に改ざんを検出する責任があります。
Endpoints are permitted to use other methods to detect and attempt to recover from interference with the handshake. Invalid packets can be identified and discarded using other methods, but no specific method is mandated in this document.
エンドポイントは、他の方法を使用してハンドシェイクとの干渉から回復を試みることができます。無効なパケットは他のメソッドを使用して識別して破棄できますが、このドキュメントでは特定のメソッドは義務付けられていません。
An attacker might be able to receive an address validation token (Section 8) from a server and then release the IP address it used to acquire that token. At a later time, the attacker can initiate a 0-RTT connection with a server by spoofing this same address, which might now address a different (victim) endpoint. The attacker can thus potentially cause the server to send an initial congestion window's worth of data towards the victim.
攻撃者は、サーバーからアドレス検証トークン（セクション8）を受信してから、そのトークンを取得するために使用したIPアドレスを解放することができます。後で、攻撃者はこの同じアドレスを偽装することによってサーバーとの0-RTT接続を開始することができます。これは、異なる（被害者）エンドポイントに対処する可能性があります。攻撃者はしたがって、サーバーに最初の輻輳ウィンドウの価値のあるデータを被害者に向けて送信させる可能性があります。
Servers SHOULD provide mitigations for this attack by limiting the usage and lifetime of address validation tokens; see Section 8.1.3.
アドレス検証トークンの使用法と有効期間を制限することで、サーバーはこの攻撃に対して軽減する必要があります。セクション8.1.3を参照してください。
An endpoint that acknowledges packets it has not received might cause a congestion controller to permit sending at rates beyond what the network supports. An endpoint MAY skip packet numbers when sending packets to detect this behavior. An endpoint can then immediately close the connection with a connection error of type PROTOCOL_VIOLATION; see Section 10.2.
受信していないパケットを確認するエンドポイントは、輻輳コントローラがネットワークがサポートするものを超えたレートで送信を許可する可能性があります。エンドポイントは、この動作を検出するためにパケットを送信するときにパケット番号をスキップすることがあります。その後、エンドポイントは直ちにTYPE PROTOCOL_VIOLATION型の接続エラーとの接続を閉じます。10.2項を参照してください。
A request forgery attack occurs where an endpoint causes its peer to issue a request towards a victim, with the request controlled by the endpoint. Request forgery attacks aim to provide an attacker with access to capabilities of its peer that might otherwise be unavailable to the attacker. For a networking protocol, a request forgery attack is often used to exploit any implicit authorization conferred on the peer by the victim due to the peer's location in the network.
エンドポイントがそのピアが被害者に向けて要求を発行すると、要求がエンドポイントによって制御されているため、要求偽造攻撃が発生します。偽造攻撃を要求すると、そうでなければ攻撃者に利用できない可能性があるそのピアの機能へのアクセスを攻撃者に提供することを目的としています。ネットワーキングプロトコルの場合、ネットワーク内のピアの場所が原因で、被害者によって契約者に授与された暗黙の認証を悪用するために、要求偽造攻撃がよく使用されます。
For request forgery to be effective, an attacker needs to be able to influence what packets the peer sends and where these packets are sent. If an attacker can target a vulnerable service with a controlled payload, that service might perform actions that are attributed to the attacker's peer but are decided by the attacker.
要求の偽造が効果的であるためには、攻撃者はピアが送信するパケットとこれらのパケットが送信される場所に影響を与える必要があります。攻撃者が制御されたペイロードで脆弱なサービスをターゲットにすることができる場合、そのサービスは攻撃者のピアに起因するが攻撃者によって決定されるアクションを実行する可能性があります。
For example, cross-site request forgery [CSRF] exploits on the Web cause a client to issue requests that include authorization cookies [COOKIE], allowing one site access to information and actions that are intended to be restricted to a different site.
たとえば、クロスサイトリクエストForgery [CSRF] Web上でクライアントを利用して、許可Cookie [Cookie]を含むリクエストを発行して、別のサイトに制限されることを目的とした情報とアクションに1つのサイトアクセスが可能になります。
As QUIC runs over UDP, the primary attack modality of concern is one where an attacker can select the address to which its peer sends UDP datagrams and can control some of the unprotected content of those packets. As much of the data sent by QUIC endpoints is protected, this includes control over ciphertext. An attack is successful if an attacker can cause a peer to send a UDP datagram to a host that will perform some action based on content in the datagram.
QUICがUDPを介して実行されるように、懸念の主な攻撃モダリティは、攻撃者がそのピアがUDPデータグラムを送信するアドレスを選択でき、それらのパケットの保護されていないコンテンツの一部を制御できます。QUICエンドポイントによって送信されたデータの多くは保護されているため、暗号文の制御を含みます。攻撃者がピアがピアにUDPデータグラムをUDPデータグラムに送信しても、データグラム内のコンテンツに基づいて実行されるホストに送信されます。
This section discusses ways in which QUIC might be used for request forgery attacks.
このセクションでは、要求偽造攻撃にQUICが使用される可能性がある方法について説明します。
This section also describes limited countermeasures that can be implemented by QUIC endpoints. These mitigations can be employed unilaterally by a QUIC implementation or deployment, without potential targets for request forgery attacks taking action. However, these countermeasures could be insufficient if UDP-based services do not properly authorize requests.
このセクションでは、QUICのエンドポイントによって実装できる制限された対策についても説明します。これらの軽減は、求められている指標または展開によって一方的に雇用され、潜在的なターゲットが行動を取っている要求のターゲットを標的にすることはできません。ただし、UDPベースのサービスが要求を正しく認証しない場合、これらの対策は不十分である可能性があります。
Because the migration attack described in Section 21.5.4 is quite powerful and does not have adequate countermeasures, QUIC server implementations should assume that attackers can cause them to generate arbitrary UDP payloads to arbitrary destinations. QUIC servers SHOULD NOT be deployed in networks that do not deploy ingress filtering [BCP38] and also have inadequately secured UDP endpoints.
21.5.4項に記載されている移行攻撃は非常に強力で、適切な対策を持たないため、攻撃者が任意の宛先への任意のUDPペイロードを生成させることができると仮定する必要があります。Ingress Filtering [BCP38]を展開しないネットワークにQUICサーバーをデプロイしないでください。また、不適切なUDPエンドポイントもあります。
Although it is not generally possible to ensure that clients are not co-located with vulnerable endpoints, this version of QUIC does not allow servers to migrate, thus preventing spoofed migration attacks on clients. Any future extension that allows server migration MUST also define countermeasures for forgery attacks.
クライアントが脆弱なエンドポイントで同じ場所に配置されていないことを一般的には可能ではありませんが、このバージョンのQUICはサーバーを移行することを許可しないため、クライアントに対する偽装された移行攻撃が防止されます。サーバーの移行を許可する将来の拡張子は、偽造攻撃の対策も定義する必要があります。
QUIC offers some opportunities for an attacker to influence or control where its peer sends UDP datagrams:
QUICは、攻撃者がそのピアがUDPデータグラムを送信する場所に影響を及ぼしたり制御する機会を提供しています。
* initial connection establishment (Section 7), where a server is able to choose where a client sends datagrams -- for example, by populating DNS records;
* サーバーがデータグラムがデータグラムを送信する場所を選択できる最初の接続確立（セクション7）。たとえば、DNSレコードを入力します。
* preferred addresses (Section 9.6), where a server is able to choose where a client sends datagrams;
* サーバーがデータグラムを送信する場所を選択できるようにするには、優先アドレス（セクション9.6）。
* spoofed connection migrations (Section 9.3.1), where a client is able to use source address spoofing to select where a server sends subsequent datagrams; and
* スプーフィングされた接続移行（9.3.1項）。クライアントが送信元アドレスのスプーフィングを使用してサーバーが後続のデータグラムを送信する場所を選択することができます。そして
* spoofed packets that cause a server to send a Version Negotiation packet (Section 21.5.5).
* サーバーにバージョンネゴシエーションパケットを送信させる偽装パケット（セクション21.5.5）。
In all cases, the attacker can cause its peer to send datagrams to a victim that might not understand QUIC. That is, these packets are sent by the peer prior to address validation; see Section 8.
すべての場合において、攻撃者はそのピアが熟達しないかもしれない被害者にデータグラムを送ることができます。つまり、これらのパケットはアドレス検証の前にピアによって送信されます。セクション8を参照してください。
Outside of the encrypted portion of packets, QUIC offers an endpoint several options for controlling the content of UDP datagrams that its peer sends. The Destination Connection ID field offers direct control over bytes that appear early in packets sent by the peer; see Section 5.1. The Token field in Initial packets offers a server control over other bytes of Initial packets; see Section 17.2.2.
パケットの暗号化部分の外側では、QUICは、そのピアが送信するUDPデータグラムの内容を制御するためのいくつかのオプションを提供します。宛先接続IDフィールドは、ピアによって送信されたパケットの早い段階で表示されるバイトを直接制御します。セクション5.1を参照してください。初期パケットのトークンフィールドは、初期パケットの他のバイトのサーバ制御を提供します。17.2.2項を参照してください。
There are no measures in this version of QUIC to prevent indirect control over the encrypted portions of packets. It is necessary to assume that endpoints are able to control the contents of frames that a peer sends, especially those frames that convey application data, such as STREAM frames. Though this depends to some degree on details of the application protocol, some control is possible in many protocol usage contexts. As the attacker has access to packet protection keys, they are likely to be capable of predicting how a peer will encrypt future packets. Successful control over datagram content then only requires that the attacker be able to predict the packet number and placement of frames in packets with some amount of reliability.
このバージョンのパケットの暗号化部分に対する間接的な制御を防ぐために、このバージョンのQUICには尺度はありません。エンドポイントが、ピア送信が送信されるフレームの内容、特にストリームフレームのようなアプリケーションデータを伝達するフレームの内容を制御できるとする必要があります。これはアプリケーションプロトコルの詳細によってある程度依存していますが、多くのプロトコル使用状況においていくつかの制御が可能です。攻撃者がパケット保護キーにアクセスできるため、ピアが将来のパケットを暗号化する方法を予測できる可能性があります。その後、データグラムのコンテンツに対する制御の成功は、攻撃者がパケット番号を予測し、パケット内のフレームのフレームの配置が可能であることだけです。
This section assumes that limiting control over datagram content is not feasible. The focus of the mitigations in subsequent sections is on limiting the ways in which datagrams that are sent prior to address validation can be used for request forgery.
このセクションでは、データグラムのコンテンツに対する制御を制限することが実行不可能であると想定しています。後続のセクションでの軽減の焦点は、アドレス検証の前に送信されるデータグラムをリクエスト偽造に使用できる方法を制限することです。
An attacker acting as a server can choose the IP address and port on which it advertises its availability, so Initial packets from clients are assumed to be available for use in this sort of attack. The address validation implicit in the handshake ensures that -- for a new connection -- a client will not send other types of packets to a destination that does not understand QUIC or is not willing to accept a QUIC connection.
サーバーとして機能する攻撃者は、その可用性をアドバタイズしているIPアドレスとポートを選択できます。そのため、クライアントからの初期パケットはこの種の攻撃で使用できると見なされます。ハンドシェイクに暗黙的に表示されるアドレス検証は、新しい接続のために - クライアントが他のタイプのパケットをQUICを理解していない、またはQUIC接続を受け入れることを意図していないパケットを送信しません。
Initial packet protection (Section 5.2 of [QUIC-TLS]) makes it difficult for servers to control the content of Initial packets sent by clients. A client choosing an unpredictable Destination Connection ID ensures that servers are unable to control any of the encrypted portion of Initial packets from clients.
初期パケット保護（[QUIC-TLS]のセクション5.2）は、サーバーがクライアントによって送信された初期パケットの内容を制御することを困難にします。予測不可能な宛先接続IDを選択するクライアントは、サーバーが最初のパケットの暗号化部分をクライアントから制御できないことを保証します。
However, the Token field is open to server control and does allow a server to use clients to mount request forgery attacks. The use of tokens provided with the NEW_TOKEN frame (Section 8.1.3) offers the only option for request forgery during connection establishment.
ただし、トークンフィールドはサーバーコントロールに開かれており、サーバーがクライアントを使用してリクエストの偽造攻撃をマウントできるようにします。NEW_TOKENフレーム（セクション8.1.3）に付属のトークンの使用は、接続確立中の要求偽造の唯一のオプションを提供します。
Clients, however, are not obligated to use the NEW_TOKEN frame. Request forgery attacks that rely on the Token field can be avoided if clients send an empty Token field when the server address has changed from when the NEW_TOKEN frame was received.
ただし、クライアントはNEW_TOKENフレームを使用する義務がありません。NEW_TOKENフレームが受信されたときにサーバーアドレスが変更されたときにクライアントが空のトークンフィールドを送信した場合、トークンフィールドに依存する偽造攻撃を回避できます。
Clients could avoid using NEW_TOKEN if the server address changes. However, not including a Token field could adversely affect performance. Servers could rely on NEW_TOKEN to enable the sending of data in excess of the three-times limit on sending data; see Section 8.1. In particular, this affects cases where clients use 0-RTT to request data from servers.
サーバーアドレスが変更された場合、クライアントはNEW_TOKENを使用しないでください。ただし、トークンフィールドを含まないことはパフォーマンスに悪影響を及ぼす可能性があります。サーバーはNEW_TOKENに依存してデータの送信データの3倍の制限を超えるデータの送信を可能にすることができます。セクション8.1を参照してください。特に、これは、クライアントがサーバーからデータを要求するためにクライアントが0-RTTを使用する場合に影響します。
Sending a Retry packet (Section 17.2.5) offers a server the option to change the Token field. After sending a Retry, the server can also control the Destination Connection ID field of subsequent Initial packets from the client. This also might allow indirect control over the encrypted content of Initial packets. However, the exchange of a Retry packet validates the server's address, thereby preventing the use of subsequent Initial packets for request forgery.
再試行パケットの送信（セクション17.2.5）は、トークンフィールドを変更するオプションをサーバに提供します。再試行を送信した後、サーバはクライアントから後続の初期パケットの宛先接続IDフィールドを制御することもできる。これにより、初期パケットの暗号化コンテンツに対する間接制御が可能になる可能性もあります。ただし、リトライパケットの交換はサーバーのアドレスを検証し、それによって要求偽造のための後続の初期パケットの使用を防ぎます。
Servers can specify a preferred address, which clients then migrate to after confirming the handshake; see Section 9.6. The Destination Connection ID field of packets that the client sends to a preferred address can be used for request forgery.
サーバーは優先アドレスを指定できます。このアドレスは、ハンドシェイクを確認した後に移行することができます。セクション9.6を参照してください。クライアントが優先アドレスに送信するパケットの宛先接続IDフィールドは、要求偽造に使用できます。
A client MUST NOT send non-probing frames to a preferred address prior to validating that address; see Section 8. This greatly reduces the options that a server has to control the encrypted portion of datagrams.
そのアドレスを検証する前に、クライアントは非プロービングフレームを優先アドレスに送信してはなりません。セクション8を参照してください。これにより、サーバーがデータグラムの暗号化部分を制御する必要があるオプションが大幅に減少します。
This document does not offer any additional countermeasures that are specific to the use of preferred addresses and can be implemented by endpoints. The generic measures described in Section 21.5.6 could be used as further mitigation.
この文書は、優先アドレスの使用に特有の追加の対策を提供し、エンドポイントによって実装できます。セクション21.5.6に記載されている一般的な測定は、さらなる緩和として使用することができます。
Clients are able to present a spoofed source address as part of an apparent connection migration to cause a server to send datagrams to that address.
クライアントは、サーバーにデータグラムをそのアドレスに送信させるために、見かけの接続移行の一部として偽装された送信元アドレスを提示できます。
The Destination Connection ID field in any packets that a server subsequently sends to this spoofed address can be used for request forgery. A client might also be able to influence the ciphertext.
サーバがその後この偽造アドレスに送信するパケット内の宛先接続IDフィールドは、要求偽造に使用できます。クライアントは暗号文に影響を与えることもできます。
A server that only sends probing packets (Section 9.1) to an address prior to address validation provides an attacker with only limited control over the encrypted portion of datagrams. However, particularly for NAT rebinding, this can adversely affect performance. If the server sends frames carrying application data, an attacker might be able to control most of the content of datagrams.
アドレス検証の前にプロービングパケット（セクション9.1）をアドレスに送信するサーバは、データグラムの暗号化部分を制限した制御のみを伴う攻撃者を提供する。ただし、特にNATの再バインドの場合、これはパフォーマンスに悪影響を及ぼす可能性があります。サーバーがアプリケーションデータを運ぶフレームを送信すると、攻撃者はデータグラムのほとんどのコンテンツを制御できる可能性があります。
This document does not offer specific countermeasures that can be implemented by endpoints, aside from the generic measures described in Section 21.5.6. However, countermeasures for address spoofing at the network level -- in particular, ingress filtering [BCP38] -- are especially effective against attacks that use spoofing and originate from an external network.
この文書は、セクション21.5.6で説明されている一般的な測定値から、エンドポイントによって実装できる特定の対策を提供していません。ただし、ネットワークレベルでのアドレススプーフィングの対策は、特に、入力フィルタリング[BCP38]では、スプーフィングを使用して外部ネットワークに起因する攻撃に対して特に効果的です。
Clients that are able to present a spoofed source address on a packet can cause a server to send a Version Negotiation packet (Section 17.2.1) to that address.
パケット上に偽造された送信元アドレスを提示できるクライアントは、サーバーにそのアドレスにバージョンネゴシエーションパケット（セクション17.2.1）を送信させる可能性があります。
The absence of size restrictions on the connection ID fields for packets of an unknown version increases the amount of data that the client controls from the resulting datagram. The first byte of this packet is not under client control and the next four bytes are zero, but the client is able to control up to 512 bytes starting from the fifth byte.
未知のバージョンのパケットの接続IDフィールドに対するサイズ制限がないと、クライアントが結果のデータグラムからコントロールするデータ量が増えます。このパケットの最初のバイトはクライアントコントロールの下にあり、次の4バイトはゼロですが、クライアントは5バイトから最大512バイトまで制御できます。
No specific countermeasures are provided for this attack, though generic protections (Section 21.5.6) could apply. In this case, ingress filtering [BCP38] is also effective.
一般的な保護（セクション21.5.6）が適用されるが、この攻撃に対して特別な対策は提供されていない。この場合、入口フィルタリング[BCP38]も有効です。
The most effective defense against request forgery attacks is to modify vulnerable services to use strong authentication. However, this is not always something that is within the control of a QUIC deployment. This section outlines some other steps that QUIC endpoints could take unilaterally. These additional steps are all discretionary because, depending on circumstances, they could interfere with or prevent legitimate uses.
要求偽造攻撃に対する最も効果的な防御は、強力な認証を使用するために脆弱なサービスを変更することです。ただし、これは常にQUICの展開の制御内にあるものではありません。このセクションでは、QUICのエンドポイントが一方的に取ることができる他のいくつかのステップについて説明します。これらの追加のステップは、状況によっては合法的な用途を妨害または防止することができるため、すべて裁量的です。
Services offered over loopback interfaces often lack proper authentication. Endpoints MAY prevent connection attempts or migration to a loopback address. Endpoints SHOULD NOT allow connections or migration to a loopback address if the same service was previously available at a different interface or if the address was provided by a service at a non-loopback address. Endpoints that depend on these capabilities could offer an option to disable these protections.
ループバックインタフェースを介して提供されるサービスは、適切な認証を欠いています。エンドポイントは、接続試行またはループバックアドレスへの移行を防ぐことができます。同じサービスが異なるインターフェイスで以前に利用可能である場合、またはアドレスが非ループバックアドレスでサービスによって提供されていた場合、エンドポイントはループバックアドレスへの接続または移行を許可しないでください。これらの機能に依存するエンドポイントは、これらの保護を無効にするオプションを提供できます。
Similarly, endpoints could regard a change in address to a link-local address [RFC4291] or an address in a private-use range [RFC1918] from a global, unique-local [RFC4193], or non-private address as a potential attempt at request forgery. Endpoints could refuse to use these addresses entirely, but that carries a significant risk of interfering with legitimate uses. Endpoints SHOULD NOT refuse to use an address unless they have specific knowledge about the network indicating that sending datagrams to unvalidated addresses in a given range is not safe.
同様に、エンドポイントは、グローバル、固有のローカル[RFC4193]、または非プライベートアドレスから、潜在的な試みとして、エンドポイントがリンクローカルアドレス[RFC4291]またはプライベート使用範囲[RFC1918]にアドレスの変更を考慮することができます。要求の偽造で。エンドポイントは、これらのアドレスを完全に使用することを拒否することができますが、正当な用途に干渉するという大きなリスクを占めます。ネットワークについての特定の知識がある限り、エンドポイントはアドレスを使用することを拒否してはいけません。ネットワークについての特定の知識があることを示しています。
Endpoints MAY choose to reduce the risk of request forgery by not including values from NEW_TOKEN frames in Initial packets or by only sending probing frames in packets prior to completing address validation. Note that this does not prevent an attacker from using the Destination Connection ID field for an attack.
エンドポイントは、初期パケット内のNEW_TOKENフレームからの値を含まない、またはアドレス検証を完了する前にパケット内のプロービングフレームを送信することによって、要求偽造のリスクを減らすことを選択することができます。これにより、攻撃者が攻撃の宛先接続IDフィールドを使用するのを妨げないことに注意してください。
Endpoints are not expected to have specific information about the location of servers that could be vulnerable targets of a request forgery attack. However, it might be possible over time to identify specific UDP ports that are common targets of attacks or particular patterns in datagrams that are used for attacks. Endpoints MAY choose to avoid sending datagrams to these ports or not send datagrams that match these patterns prior to validating the destination address. Endpoints MAY retire connection IDs containing patterns known to be problematic without using them.
エンドポイントは、要求偽造攻撃の脆弱なターゲットである可能性があるサーバーの場所に関する特定の情報を持つことが期待されていません。ただし、攻撃に使用されるデータグラムの攻撃または特定のパターンの一般的なターゲットである特定のUDPポートを識別することは、時間が経つにつれて可能かもしれません。エンドポイントは、宛先アドレスを検証する前にこれらのポートにデータグラムを送信しないようにすることを選択できます。エンドポイントは、それらを使用せずに問題があることが知られているパターンを含む接続IDを遅らせることができる。
Note: Modifying endpoints to apply these protections is more efficient than deploying network-based protections, as endpoints do not need to perform any additional processing when sending to an address that has been validated.
注：これらの保護を適用するようにエンドポイントを変更すると、検証済みのアドレスに送信するときにエンドポイントで追加の処理を実行する必要がないため、ネットワークベースの保護を展開するよりも効率的です。
The attacks commonly known as Slowloris [SLOWLORIS] try to keep many connections to the target endpoint open and hold them open as long as possible. These attacks can be executed against a QUIC endpoint by generating the minimum amount of activity necessary to avoid being closed for inactivity. This might involve sending small amounts of data, gradually opening flow control windows in order to control the sender rate, or manufacturing ACK frames that simulate a high loss rate.
一般的に急速に知られている攻撃[Slylloris]ターゲットエンドポイントへの多くの接続を開いて、できるだけ長く開いたままにしてください。これらの攻撃は、不活動のために閉鎖されないようにするのに必要な最小の活動量を生成することによって、QUICのエンドポイントに対して実行することができます。これは、送信者レートを制御するために、少量のデータを徐々に開くこと、または高損失率をシミュレートするACKフレームの製造を行うことを含むかもしれません。
QUIC deployments SHOULD provide mitigations for the Slowloris attacks, such as increasing the maximum number of clients the server will allow, limiting the number of connections a single IP address is allowed to make, imposing restrictions on the minimum transfer speed a connection is allowed to have, and restricting the length of time an endpoint is allowed to stay connected.
QUICの展開は、サーバーが許可するクライアントの最大数の増加、単一のIPアドレスができるようにするためのクライアントの最大数を増やすなどの緩和攻撃を提供する必要があります。エンドポイントが接続されている時間の長さを制限する。
An adversarial sender might intentionally not send portions of the stream data, causing the receiver to commit resources for the unsent data. This could cause a disproportionate receive buffer memory commitment and/or the creation of a large and inefficient data structure at the receiver.
敵対的な送信者は、意図的にストリームデータの一部を送信しない可能性があり、受信側は送信者のデータのリソースをコミットさせます。これは、不均衡な受信バッファメモリのコミットメントおよび/または受信機における大きな非効率的なデータ構造の生成を引き起こす可能性がある。
An adversarial receiver might intentionally not acknowledge packets containing stream data in an attempt to force the sender to store the unacknowledged stream data for retransmission.
敵対的な受信機は、送信者に再送信のために未確認のストリームデータを保存するために、ストリームデータを含むパケットを意図的に承認しない可能性があります。
The attack on receivers is mitigated if flow control windows correspond to available memory. However, some receivers will overcommit memory and advertise flow control offsets in the aggregate that exceed actual available memory. The overcommitment strategy can lead to better performance when endpoints are well behaved, but renders endpoints vulnerable to the stream fragmentation attack.
フロー制御ウィンドウが利用可能なメモリに対応すると、受信機への攻撃が軽減されます。ただし、受信側ではメモリを克服し、実際の使用可能なメモリを超える集計内のフロー制御オフセットをアドバタイズします。エンドポイントがうまく動作しているが、エンドポイントをストリームフラグメンテーション攻撃に対して脆弱にすると、過剰契約戦略が得られる可能性があります。
QUIC deployments SHOULD provide mitigations for stream fragmentation attacks. Mitigations could consist of avoiding overcommitting memory, limiting the size of tracking data structures, delaying reassembly of STREAM frames, implementing heuristics based on the age and duration of reassembly holes, or some combination of these.
QUICの展開は、ストリームの断片化攻撃に対して軽減を提供する必要があります。緩和は、メモリを過度に阻止すること、追跡データ構造のサイズを制限し、ストリームフレームの再組み立てを遅らせること、再組み立て穴の年齢および持続期間に基づくヒューリスティック、またはこれらの組み合わせを制限することができます。
An adversarial endpoint can open a large number of streams, exhausting state on an endpoint. The adversarial endpoint could repeat the process on a large number of connections, in a manner similar to SYN flooding attacks in TCP.
敵対的なエンドポイントは、大量のストリームを開くことができ、エンドポイントで消耗します。敵対的なエンドポイントは、TCPのSYNフラッディング攻撃と同様の方法で、多数の接続でプロセスを繰り返すことができます。
Normally, clients will open streams sequentially, as explained in Section 2.1. However, when several streams are initiated at short intervals, loss or reordering can cause STREAM frames that open streams to be received out of sequence. On receiving a higher-numbered stream ID, a receiver is required to open all intervening streams of the same type; see Section 3.2. Thus, on a new connection, opening stream 4000000 opens 1 million and 1 client-initiated bidirectional streams.
通常、セクション2.1で説明されているように、クライアントはストリームを順番に開きます。しかしながら、いくつかのストリームが短い間隔で開始されるとき、損失または並べ替えは、ストリームを開いたストリームをシーケンスから受信するストリームフレームを引き起こす可能性がある。より高い番号のストリームIDを受信すると、同じタイプのすべての介在のストリームを開くために受信機が必要とされる。セクション3.2を参照してください。したがって、新しい接続では、オープンストリーム4000000は100万個のクライアント開始双方向ストリームを開きます。
The number of active streams is limited by the initial_max_streams_bidi and initial_max_streams_uni transport parameters as updated by any received MAX_STREAMS frames, as explained in Section 4.6. If chosen judiciously, these limits mitigate the effect of the stream commitment attack. However, setting the limit too low could affect performance when applications expect to open a large number of streams.
アクティブストリームの数は、セクション4.6で説明されているように、受信したMAX_STREAMSフレームによって更新されたinitial_max_streams_bidiおよびinitial_max_streams_uniトランスポートパラメータによって制限されます。慎重に選択された場合、これらの制限はストリームコミットメント攻撃の影響を軽減します。ただし、制限を設定すると、アプリケーションが多数のストリームを開くと予想されるときのパフォーマンスに影響を与える可能性があります。
QUIC and TLS both contain frames or messages that have legitimate uses in some contexts, but these frames or messages can be abused to cause a peer to expend processing resources without having any observable impact on the state of the connection.
QUICとTLSは両方とも、いくつかのコンテキストで正当な使用を持つフレームまたはメッセージを含みますが、これらのフレームまたはメッセージは、接続の状態に観察可能な影響を与えることなく、処理リソースを処理するためにピアに処理を費やすことができます。
Messages can also be used to change and revert state in small or inconsequential ways, such as by sending small increments to flow control limits.
メッセージを変更して、フロー制御制限に小さい増分を送信するなど、ほとんどまたは重要な方法で状態を変更して戻すこともできます。
If processing costs are disproportionately large in comparison to bandwidth consumption or effect on state, then this could allow a malicious peer to exhaust processing capacity.
帯域幅の消費や状態への影響と比較して処理コストが不均衡に大きくなると、悪意のあるピアが処理能力を排気することができます。
While there are legitimate uses for all messages, implementations SHOULD track cost of processing relative to progress and treat excessive quantities of any non-productive packets as indicative of an attack. Endpoints MAY respond to this condition with a connection error or by dropping packets.
すべてのメッセージに合法的な用途がありますが、実装は進行状況と比較して過度の数量の攻撃を示すものとして処理するための処理のコストを追跡する必要があります。エンドポイントは、接続エラーまたはパケットをドロップすることによってこの状態に応答することがあります。
An on-path attacker could manipulate the value of ECN fields in the IP header to influence the sender's rate. [RFC3168] discusses manipulations and their effects in more detail.
オンパス攻撃者は、送信者の率に影響を与えるためにIPヘッダー内のECNフィールドの値を操作することができます。[RFC3168]より詳細に操作とその効果について説明します。
A limited on-path attacker can duplicate and send packets with modified ECN fields to affect the sender's rate. If duplicate packets are discarded by a receiver, an attacker will need to race the duplicate packet against the original to be successful in this attack. Therefore, QUIC endpoints ignore the ECN field in an IP packet unless at least one QUIC packet in that IP packet is successfully processed; see Section 13.4.
制限されたオンパス攻撃者は、送信者の率に影響を与えるために修正されたECNフィールドを含むパケットを複製して送信することができます。複製パケットが受信機によって破棄された場合、攻撃者はこの攻撃で成功するために原本に対して重複したパケットをレースする必要があります。したがって、そのIPパケット内の少なくとも1つのQUICパケットが正常に処理されない限り、QUICエンドポイントはIPパケット内のECNフィールドを無視します。13.4項を参照してください。
Stateless resets create a possible denial-of-service attack analogous to a TCP reset injection. This attack is possible if an attacker is able to cause a stateless reset token to be generated for a connection with a selected connection ID. An attacker that can cause this token to be generated can reset an active connection with the same connection ID.
ステートレスリセットTCPリセット噴射に類似した可能性のあるサービス拒否攻撃を作成します。攻撃者が選択した接続IDとの接続に対してステートレスリセットトークンを生成することができる場合、この攻撃は可能です。このトークンを生成させる可能性がある攻撃者は、同じ接続IDを持つアクティブな接続をリセットできます。
If a packet can be routed to different instances that share a static key -- for example, by changing an IP address or port -- then an attacker can cause the server to send a stateless reset. To defend against this style of denial of service, endpoints that share a static key for stateless resets (see Section 10.3.2) MUST be arranged so that packets with a given connection ID always arrive at an instance that has connection state, unless that connection is no longer active.
たとえば、IPアドレスまたはポートを変更することによって、パケットを静的キーを共有する異なるインスタンスにルーティングできる場合は、サーバーにステートレスリセットを送信させることができます。このスタイルのサービス拒否に対して守るために、ステートレスリセットの静的キーを共有するエンドポイント（セクション10.3.2を参照）を配置する必要があります。もはやアクティブではありません。
More generally, servers MUST NOT generate a stateless reset if a connection with the corresponding connection ID could be active on any endpoint using the same static key.
より一般的には、対応する接続IDとの接続が同じ静的キーを使用して任意のエンドポイントでアクティブになる可能性がある場合、サーバーはステートレスリセットを生成してはいけません。
In the case of a cluster that uses dynamic load balancing, it is possible that a change in load-balancer configuration could occur while an active instance retains connection state. Even if an instance retains connection state, the change in routing and resulting stateless reset will result in the connection being terminated. If there is no chance of the packet being routed to the correct instance, it is better to send a stateless reset than wait for the connection to time out. However, this is acceptable only if the routing cannot be influenced by an attacker.
動的負荷分散を使用するクラスタの場合、アクティブインスタンスが接続状態を保持している間にロードバランサ構成の変更が発生する可能性があります。インスタンスが接続状態を保持していても、ルーティングの変更と結果のステートレスリセットの変更は接続が終了します。パケットが正しいインスタンスにルーティングされる可能性がない場合は、接続がタイムアウトするのを待つよりもステートレスリセットを送信することをお勧めします。ただし、これはルーティングが攻撃者の影響を受けることができない場合にのみ受け入れられます。
This document defines QUIC Version Negotiation packets (Section 6), which can be used to negotiate the QUIC version used between two endpoints. However, this document does not specify how this negotiation will be performed between this version and subsequent future versions. In particular, Version Negotiation packets do not contain any mechanism to prevent version downgrade attacks. Future versions of QUIC that use Version Negotiation packets MUST define a mechanism that is robust against version downgrade attacks.
このドキュメントは、2つのエンドポイント間で使用されるQUICバージョンをネゴシエートするために使用できるQUICバージョンネゴシエーションパケット（セクション6）を定義します。ただし、このドキュメントでは、このバージョンとその後の将来のバージョン間でこのネゴシエーションが実行される方法は指定されていません。特に、バージョンネゴシエーションパケットには、バージョンのダウングレード攻撃を防ぐためのメカニズムは含まれていません。バージョンネゴシエーションパケットを使用するQUICの将来のバージョンは、バージョンダウングレード攻撃に対して堅牢なメカニズムを定義しなければなりません。
Deployments should limit the ability of an attacker to target a new connection to a particular server instance. Ideally, routing decisions are made independently of client-selected values, including addresses. Once an instance is selected, a connection ID can be selected so that later packets are routed to the same instance.
展開は、攻撃者が特定のサーバーインスタンスへの新しい接続をターゲティングする機能を制限する必要があります。理想的には、ルーティング決定は、アドレスを含む、クライアント選択値とは無関係に行われます。インスタンスが選択されると、後のパケットが同じインスタンスにルーティングされるように接続IDを選択できます。
The length of QUIC packets can reveal information about the length of the content of those packets. The PADDING frame is provided so that endpoints have some ability to obscure the length of packet content; see Section 19.1.
QUICパケットの長さは、それらのパケットの内容の長さに関する情報を明らかにすることができます。パディングフレームは、エンドポイントがパケット内容の長さを曖昧にする能力を持つように設けられています。セクション19.1を参照してください。
Defeating traffic analysis is challenging and the subject of active research. Length is not the only way that information might leak. Endpoints might also reveal sensitive information through other side channels, such as the timing of packets.
交通分析を破ることは困難で積極的な研究の主題です。長さは、情報が漏れる可能性がある唯一の方法ではありません。エンドポイントは、パケットのタイミングなど、他のサイドチャンネルを介して機密情報を明らかにする可能性があります。
This document establishes several registries for the management of codepoints in QUIC. These registries operate on a common set of policies as defined in Section 22.1.
このドキュメントは、QUICのCodePointsの管理のためのいくつかのレジストリを確立します。これらのレジストリは、セクション22.1で定義されているような一般的なポリシーのセットで動作します。
All QUIC registries allow for both provisional and permanent registration of codepoints. This section documents policies that are common to these registries.
すべてのQUICレジストリは、コードポイントの暫定登録と永続的登録の両方を可能にします。このセクションでは、これらのレジストリに共通のポリシーを文書化しています。
Provisional registrations of codepoints are intended to allow for private use and experimentation with extensions to QUIC. Provisional registrations only require the inclusion of the codepoint value and contact information. However, provisional registrations could be reclaimed and reassigned for another purpose.
コードポイントの暫定登録は、QUICへの拡張を用いた個人的な使用と実験を可能にすることを目的としています。暫定登録は、コードポイント値と連絡先情報を含めるだけで済みます。ただし、暫定的な登録は、別の目的のために再生および再割り当てされる可能性があります。
Provisional registrations require Expert Review, as defined in Section 4.5 of [RFC8126]. The designated expert or experts are advised that only registrations for an excessive proportion of remaining codepoint space or the very first unassigned value (see Section 22.1.2) can be rejected.
[RFC8126]のセクション4.5で定義されているように、暫定登録にはエキスパートレビューが必要です。指定されたエキスパートまたは専門家は、残りのコードポイントスペースの過剰な割合の登録のみ、または最初の最初の未割り当て値（セクション22.1.2参照）を拒否できることをお勧めします。
Provisional registrations will include a Date field that indicates when the registration was last updated. A request to update the date on any provisional registration can be made without review from the designated expert(s).
暫定登録には、登録が最後に更新されたかを示す日付フィールドが含まれます。指定されたエキスパートからのレビューなしに、暫定登録の日付を更新する要求を行うことができます。
All QUIC registries include the following fields to support provisional registration:
すべてのQUICレジストリには、暫定登録をサポートするための以下のフィールドが含まれています。
Value: The assigned codepoint. Status: "permanent" or "provisional". Specification: A reference to a publicly available specification for the value. Date: The date of the last update to the registration. Change Controller: The entity that is responsible for the definition of the registration. Contact: Contact details for the registrant. Notes: Supplementary notes about the registration.
値：割り当てられたコードポイント。ステータス：「恒久的」または「暫定」。指定：値の公的に利用可能な仕様への参照。日付：登録の最後の更新日。変更コントローラ：登録の定義を担当するエンティティ。連絡先：登録者の連絡先の詳細。注意：登録に関する付記の付記メモ。
Provisional registrations MAY omit the Specification and Notes fields, plus any additional fields that might be required for a permanent registration. The Date field is not required as part of requesting a registration, as it is set to the date the registration is created or updated.
暫定登録は、仕様フィールドおよびNotesフィールドを省略することで、恒久的な登録に必要な追加のフィールドを省くことができます。日付フィールドは、登録の要求の一部として必要とされません。登録が作成または更新された日付に設定されています。
New requests for codepoints from QUIC registries SHOULD use a randomly selected codepoint that excludes both existing allocations and the first unallocated codepoint in the selected space. Requests for multiple codepoints MAY use a contiguous range. This minimizes the risk that differing semantics are attributed to the same codepoint by different implementations.
QUICレジストリからのCodePointsに対する新しい要求は、既存の割り当てと選択されたスペース内の最初の未割り当てコードポイントの両方を除外するランダムに選択されたコードポイントを使用する必要があります。複数のコードポイントに対する要求は、隣接する範囲を使用する可能性があります。これにより、異なるセマンティクスが異なる実装によって同じコードポイントに起因するリスクが最小限に抑えられます。
The use of the first unassigned codepoint is reserved for allocation using the Standards Action policy; see Section 4.9 of [RFC8126]. The early codepoint assignment process [EARLY-ASSIGN] can be used for these values.
最初の未割り当てコードポイントの使用は、標準アクションポリシーを使用して割り当て用に予約されています。[RFC8126]のセクション4.9を参照してください。これらの値には、初期のコードポイント割り当てプロセス[elege-ansarge]を使用できます。
For codepoints that are encoded in variable-length integers (Section 16), such as frame types, codepoints that encode to four or eight bytes (that is, values 2^14 and above) SHOULD be used unless the usage is especially sensitive to having a longer encoding.
フレームタイプなどの可変長整数（セクション16）でエンコードされているCEDEPOINTの場合は、使用が特に持つのに特に敏感でない限り、4~8バイト（つまり、値2 ^ 14以降）を使用する必要があります。より長い符号化。
Applications to register codepoints in QUIC registries MAY include a requested codepoint as part of the registration. IANA MUST allocate the selected codepoint if the codepoint is unassigned and the requirements of the registration policy are met.
QUICレジストリ内のコードポイントを登録するアプリケーションは、登録の一部として要求されたコードポイントを含み得る。CodePointが割り当てられていない場合、IANAは選択されたコードポイントを割り当て、登録ポリシーの要件が満たされている必要があります。
A request might be made to remove an unused provisional registration from the registry to reclaim space in a registry, or a portion of the registry (such as the 64-16383 range for codepoints that use variable-length encodings). This SHOULD be done only for the codepoints with the earliest recorded date, and entries that have been updated less than a year prior SHOULD NOT be reclaimed.
レジストリから未使用の暫定登録を削除するために未使用の暫定登録を削除して、レジストリ内のスペースを再利用したり、レジストリの一部（可変長エンコーディングを使用するCEDEPOINTSの64-16383範囲など）です。これは、最も早い記録された日付を持つコードポイントに対してのみ行われるべきです、そして1年以内に更新されたエントリは再生されるべきではありません。
A request to remove a codepoint MUST be reviewed by the designated experts. The experts MUST attempt to determine whether the codepoint is still in use. Experts are advised to contact the listed contacts for the registration, plus as wide a set of protocol implementers as possible in order to determine whether any use of the codepoint is known. The experts are also advised to allow at least four weeks for responses.
コードポイントを削除する要求は指定された専門家によって確認されなければなりません。エキスパートは、コードポイントがまだ使用されているかどうかを判断しようとしなければなりません。専門家は、コードポイントの使用がわかっているかどうかを判断するために、登録のためにリストされている連絡先に連絡することをお勧めします。専門家はまた、応答に対して少なくとも4週間を許容することをお勧めします。
If any use of the codepoints is identified by this search or a request to update the registration is made, the codepoint MUST NOT be reclaimed. Instead, the date on the registration is updated. A note might be added for the registration recording relevant information that was learned.
この検索または登録を更新する要求によってコードポイントを使用する場合は、コードポイントを再生してはいけません。代わりに、登録上の日付が更新されます。学習された登録録音関連情報に注意してください。
If no use of the codepoint was identified and no request was made to update the registration, the codepoint MAY be removed from the registry.
コードポイントを使用しなかった場合、登録を更新するために要求がなされていない場合は、コードポイントをレジストリから削除できます。
This review and consultation process also applies to requests to change a provisional registration into a permanent registration, except that the goal is not to determine whether there is no use of the codepoint but to determine that the registration is an accurate representation of any deployed usage.
このレビューおよび協議プロセスは、暫定登録を永続的登録に変更する要求にも適用されます。これは、コードポイントを使用していないが登録が展開された使用法の正確な表現であると判断することを除いて、目標が永続的な登録に適用されます。
Permanent registrations in QUIC registries use the Specification Required policy (Section 4.6 of [RFC8126]), unless otherwise specified. The designated expert or experts verify that a specification exists and is readily accessible. Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing or architecturally dubious). The creation of a registry MAY specify additional constraints on permanent registrations.
QUICレジストリの永続的登録は、特に指定のない限り、指定されたポリシー（[RFC8126]のセクション4.6）を使用します。指定された専門家または専門家は、仕様が存在し、容易にアクセス可能であることを確認します。専門家は、虐待的、軽微な、または積極的に有害でない限り承認登録に偏っていることを奨励されています（単に審美的に避難または建築的に疑わしい）。レジストリの作成は、永続的登録に追加の制約を指定することができます。
The creation of a registry MAY identify a range of codepoints where registrations are governed by a different registration policy. For instance, the "QUIC Frame Types" registry (Section 22.4) has a stricter policy for codepoints in the range from 0 to 63.
レジストリの作成は、登録が異なる登録ポリシーによって管理されている範囲のコードポイントを識別することができます。たとえば、「QUICのフレームタイプ」レジストリ（セクション22.4）は、0から63の範囲のCodePointsのための厳密なポリシーを持っています。
Any stricter requirements for permanent registrations do not prevent provisional registrations for affected codepoints. For instance, a provisional registration for a frame type of 61 could be requested.
永続的登録のための厳密な要件は、影響を受けるコードポイントの暫定的な登録を妨げません。例えば、フレームタイプの暫定登録61を要求することができる。
All registrations made by Standards Track publications MUST be permanent.
標準トラックの出版物によって行われたすべての登録は永続的でなければなりません。
All registrations in this document are assigned a permanent status and list a change controller of the IETF and a contact of the QUIC Working Group (quic@ietf.org).
この文書内のすべての登録には、恒久的なステータスが割り当てられ、IETFの変更コントローラと、QUICのワーキンググループ（QUIC@IETF.ORG）の連絡先をリストします。
IANA has added a registry for "QUIC Versions" under a "QUIC" heading.
IANAは、「QUIC」見出しの下にある「QUICバージョン」のためのレジストリを追加しました。
The "QUIC Versions" registry governs a 32-bit space; see Section 15. This registry follows the registration policy from Section 22.1. Permanent registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [RFC8126]).
「QUICバージョン」レジストリは32ビットスペースを管理します。このレジストリはセクション22.1からの登録ポリシーに従います。このレジストリの永続的登録は、指定されたポリシー（[RFC8126]のセクション4.6）を使用して割り当てられています。
The codepoint of 0x00000001 for the protocol is assigned with permanent status to the protocol defined in this document. The codepoint of 0x00000000 is permanently reserved; the note for this codepoint indicates that this version is reserved for version negotiation.
プロトコルの0x00000001のCodePointには、このドキュメントで定義されているプロトコルに永続的なステータスが割り当てられています。0x00000000のコードポイントは永久に予約されています。このコードポイントのメモは、このバージョンがバージョンネゴシエーション用に予約されていることを示しています。
All codepoints that follow the pattern 0x?a?a?a?a are reserved, MUST NOT be assigned by IANA, and MUST NOT appear in the listing of assigned values.
パターン0xに続くすべてのコードポイント？A？A？Aは予約されていて、IANAによって割り当てられてはいけません、そして割り当てられた値のリストには表示されません。
IANA has added a registry for "QUIC Transport Parameters" under a "QUIC" heading.
IANAは「QUIC」見出しの下にある「QUICのトランスポートパラメータ」のレジストリを追加しました。
The "QUIC Transport Parameters" registry governs a 62-bit space. This registry follows the registration policy from Section 22.1. Permanent registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal), inclusive, which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
「QUICトランスポートパラメータ」レジストリは62ビットスペースを管理します。このレジストリは、セクション22.1からの登録ポリシーに従います。このレジストリの永続的登録は、セクション4.9で定義されている標準アクションまたはIESG承認を使用して割り当てられている0x00から0x3F（16進数）の間の値を除いて、仕様必要なポリシー（[RFC8126]）を使用して割り当てられます。[RFC8126]の4.10。
In addition to the fields listed in Section 22.1.1, permanent registrations in this registry MUST include the following field:
22.1.1項に記載されているフィールドに加えて、このレジストリ内の永続的登録には、次のフィールドを含める必要があります。
Parameter Name: A short mnemonic for the parameter.
パラメータ名：パラメータの短いニーモニック。
The initial contents of this registry are shown in Table 6.
このレジストリの初期内容を表6に示す。
+=======+=====================================+===============+
| Value | Parameter Name | Specification |
+=======+=====================================+===============+
| 0x00 | original_destination_connection_id | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x01 | max_idle_timeout | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x02 | stateless_reset_token | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x03 | max_udp_payload_size | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x04 | initial_max_data | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x05 | initial_max_stream_data_bidi_local | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x07 | initial_max_stream_data_uni | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x08 | initial_max_streams_bidi | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x09 | initial_max_streams_uni | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x0a | ack_delay_exponent | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x0b | max_ack_delay | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x0c | disable_active_migration | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x0d | preferred_address | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x0e | active_connection_id_limit | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x0f | initial_source_connection_id | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x10 | retry_source_connection_id | Section 18.2 |
+-------+-------------------------------------+---------------+
Table 6: Initial QUIC Transport Parameters Registry Entries
表6：Initial QUICトランスポートパラメータレジストリエントリ
Each value of the form "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
nのn（つまり27,58,89、...）の整数値の「31 * N 27」の各値は予約されています。これらの値はIANAによって割り当てられてはならず、割り当てられた値のリストには表示されないでください。
IANA has added a registry for "QUIC Frame Types" under a "QUIC" heading.
IANAは「QUIC」見出しの下にある「QUICのフレームタイプ」のレジストリを追加しました。
The "QUIC Frame Types" registry governs a 62-bit space. This registry follows the registration policy from Section 22.1. Permanent registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal), inclusive, which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
「QUICフレームタイプ」レジストリは62ビットスペースを管理します。このレジストリは、セクション22.1からの登録ポリシーに従います。このレジストリの永続的登録は、セクション4.9で定義されている標準アクションまたはIESG承認を使用して割り当てられている0x00から0x3F（16進数）の間の値を除いて、仕様必要なポリシー（[RFC8126]）を使用して割り当てられます。[RFC8126]の4.10。
In addition to the fields listed in Section 22.1.1, permanent registrations in this registry MUST include the following field:
22.1.1項に記載されているフィールドに加えて、このレジストリ内の永続的登録には、次のフィールドを含める必要があります。
Frame Type Name: A short mnemonic for the frame type.
フレームタイプ名：フレームタイプの短いニーモニック。
In addition to the advice in Section 22.1, specifications for new permanent registrations SHOULD describe the means by which an endpoint might determine that it can send the identified type of frame. An accompanying transport parameter registration is expected for most registrations; see Section 22.3. Specifications for permanent registrations also need to describe the format and assigned semantics of any fields in the frame.
セクション22.1のアドバイスに加えて、新しい永続的登録の仕様は、識別されたフレームの種類を送信できるとエンドポイントが決定できる手段を説明する必要があります。付随する輸送パラメータ登録は、ほとんどの登録に期待されています。22.3節を参照してください。永続的登録の仕様はまた、フレーム内の任意のフィールドのフォーマットと割り当てられたセマンティクスを記述する必要があります。
The initial contents of this registry are tabulated in Table 3. Note that the registry does not include the "Pkts" and "Spec" columns from Table 3.
このレジストリの初期内容を表3にまとめた内容を表3にまとめています。
IANA has added a registry for "QUIC Transport Error Codes" under a "QUIC" heading.
IANAは、「QUIC」見出しの下にある「QUICトランスポートエラーコード」のレジストリを追加しました。
The "QUIC Transport Error Codes" registry governs a 62-bit space. This space is split into three ranges that are governed by different policies. Permanent registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal), inclusive, which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
「QUICトランスポートエラーコード」レジストリは62ビットスペースを管理します。このスペースは、さまざまなポリシーによって管理されている3つの範囲に分割されています。このレジストリの永続的登録は、セクション4.9で定義されている標準アクションまたはIESG承認を使用して割り当てられている0x00から0x3F（16進数）の間の値を除いて、仕様必要なポリシー（[RFC8126]）を使用して割り当てられます。[RFC8126]の4.10。
In addition to the fields listed in Section 22.1.1, permanent registrations in this registry MUST include the following fields:
セクション22.1.1にリストされているフィールドに加えて、このレジストリ内の永続的登録には、次のフィールドを含める必要があります。
Code: A short mnemonic for the parameter.
コード：パラメータの短いニーモニック。
Description: A brief description of the error code semantics, which MAY be a summary if a specification reference is provided.
説明：仕様参照が提供されている場合、概要である可能性があるエラーコードセマンティクスの簡単な説明。
The initial contents of this registry are shown in Table 7.
このレジストリの初期内容を表7に示す。
+=======+===========================+================+==============+
|Value | Code |Description |Specification |
+=======+===========================+================+==============+
|0x00 | NO_ERROR |No error |Section 20 |
+-------+---------------------------+----------------+--------------+
|0x01 | INTERNAL_ERROR |Implementation |Section 20 |
| | |error | |
+-------+---------------------------+----------------+--------------+
|0x02 | CONNECTION_REFUSED |Server refuses a|Section 20 |
| | |connection | |
+-------+---------------------------+----------------+--------------+
|0x03 | FLOW_CONTROL_ERROR |Flow control |Section 20 |
| | |error | |
+-------+---------------------------+----------------+--------------+
|0x04 | STREAM_LIMIT_ERROR |Too many streams|Section 20 |
| | |opened | |
+-------+---------------------------+----------------+--------------+
|0x05 | STREAM_STATE_ERROR |Frame received |Section 20 |
| | |in invalid | |
| | |stream state | |
+-------+---------------------------+----------------+--------------+
|0x06 | FINAL_SIZE_ERROR |Change to final |Section 20 |
| | |size | |
+-------+---------------------------+----------------+--------------+
|0x07 | FRAME_ENCODING_ERROR |Frame encoding |Section 20 |
| | |error | |
+-------+---------------------------+----------------+--------------+
|0x08 | TRANSPORT_PARAMETER_ERROR |Error in |Section 20 |
| | |transport | |
| | |parameters | |
+-------+---------------------------+----------------+--------------+
|0x09 | CONNECTION_ID_LIMIT_ERROR |Too many |Section 20 |
| | |connection IDs | |
| | |received | |
+-------+---------------------------+----------------+--------------+
|0x0a | PROTOCOL_VIOLATION |Generic protocol|Section 20 |
| | |violation | |
+-------+---------------------------+----------------+--------------+
|0x0b | INVALID_TOKEN |Invalid Token |Section 20 |
| | |received | |
+-------+---------------------------+----------------+--------------+
|0x0c | APPLICATION_ERROR |Application |Section 20 |
| | |error | |
+-------+---------------------------+----------------+--------------+
|0x0d | CRYPTO_BUFFER_EXCEEDED |CRYPTO data |Section 20 |
| | |buffer | |
| | |overflowed | |
+-------+---------------------------+----------------+--------------+
|0x0e | KEY_UPDATE_ERROR |Invalid packet |Section 20 |
| | |protection | |
| | |update | |
+-------+---------------------------+----------------+--------------+
|0x0f | AEAD_LIMIT_REACHED |Excessive use of|Section 20 |
| | |packet | |
| | |protection keys | |
+-------+---------------------------+----------------+--------------+
|0x10 | NO_VIABLE_PATH |No viable |Section 20 |
| | |network path | |
| | |exists | |
+-------+---------------------------+----------------+--------------+
|0x0100-| CRYPTO_ERROR |TLS alert code |Section 20 |
|0x01ff | | | |
+-------+---------------------------+----------------+--------------+
Table 7: Initial QUIC Transport Error Codes Registry Entries
表7：Initial QUICトランスポートエラーコードレジストリエントリ
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. <https://www.rfc-editor.org/info/bcp38>
[BCP38] Ferguson、P.およびD. Senie、「ネットワーク入力フィルタリング：IP送信元アドレスのなりすましを採用するサービス拒否拒否」、BCP 38、RFC 2827、2000年5月。<https://www.rfc-editor.org/info/bcp38>
[DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[DPLPMTUD] FairHurst、G.、Jones、T.、T.、T.、Tüxen、M.、Rüngeler、I.、およびT.Völker、「データグラムトランスポートのパケット化層パスMTUディスカバリー」、RFC 8899、DOI 10.17487 / RFC8899、2020年9月<https://www.rfc-editor.org/info/rfc8899>。
[EARLY-ASSIGN] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.
[早期割り当て]コットン、M。、「早期IANAの順番トラックの配分」、BCP 100、RFC 7120、DOI 10.17487 / RFC7120、2014年1月、<https://www.rfc-editor.org/info/RFC7120>。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[IPv4] Postel、J.、 "Internet Protocol"、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, <https://www.rfc-editor.org/info/rfc8999>.
[QUIC-INVARIANTS] Thomson、M.、「QUICのバージョン非依存のプロパティ」、RFC 8999、DOI 10.17487 / RFC8999、2021年5月、<https://www.rfc-editor.org/info/rfc8999>。
[QUIC-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/info/rfc9002>.
[QUIC回復] Iyngar、J.、ED。I.SWETT、ED。、「QUICの損失検出および輻輳制御」、RFC 9002、DOI 10.17487 / RFC9002、2021年5月、<https://www.rfc-editor.org/info/rfc9002>。
[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>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J.およびS.Theering、 "Path Mtu Discovery"、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https://www.rfc-editor.org/info/rfc1191>。
[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>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168] Ramakrishnan、K.、Floyd、S.、およびD. Black、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https:// www。rfc-editor.org/info/rfc3168>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/RFC3629>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、およびJ.Rajahalme、「IPv6フローラベル仕様」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https://www.rfc-editor.org/info/rfc6437>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] eggert、L.、Fairhurst、G.、およびG.Shepherd、 "UDP使用ガイドライン"、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https://www.rfc-editor.org/ info / rfc8085>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS:// WWW.rfc-editor.org / info / rfc8126>。
[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>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Theer、S.、Mogul、J.、およびR. Hinden、Ed。、「IPバージョン6のためのパスMTUディスカバリー」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.
[RFC8311]ブラック、D.、「明示的輻輳通知（ECN）実験（ECN）実験に関するリラックス制限」、RFC 8311、DOI 10.17487 / RFC8311、2018年1月、<https://www.rfc-editor.org/info/rfc8311>。
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[TLS13] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[UDP] Postel、J.、 "User Datagram Protocol"、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[AEAD] MCGREW、D。、「認証された暗号化のためのインタフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<https://www.rfc-editor.org/info/rfc5116>。
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[ALPN] Friedl、S.、Popov、A.、Langley、A.、およびE.Stethan、「トランスポート層セキュリティ（TLS）アプリケーション層プロトコルネゴシエーション拡張」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、<https://www.rfc-editor.org/info/rfc7301>。
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[ALTSVC]ノッティンガム、M.、McManus、P.、J.Reschke、「HTTP代替サービス」、RFC 7838、DOI 10.17487 / RFC7838、2016年4月、<https://www.rfc-editor.org/info/RFC7838>。
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[Cookie] Barth、A.、「HTTP状態管理メカニズム」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<https://www.rfc-editor.org/info/rfc6265>。
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust defenses for cross-site request forgery", Proceedings of the 15th ACM conference on Computer and communications security - CCS '08, DOI 10.1145/1455770.1455782, 2008, <https://doi.org/10.1145/1455770.1455782>.
[CSRF] Barth、A.、Jackson、C.、およびJ.Mitchell、「クロスサイトリクエスト偽造のための堅牢な防御」、コンピュータ通信および通信の第15回ACM会議の手続き - CCS '08、DOI 10.1145 / 1455770.14557822008年、<https://doi.org/10.1145/1455770.1455782>。
[EARLY-DESIGN] Roskind, J., "QUIC: Multiplexed Stream Transport Over UDP", 2 December 2013, <https://docs.google.com/document/ d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/ edit?usp=sharing>.
[早期デザイン] Roskind、J.、「QUIC：多重化ストリームトランスポートオーバーUDP」、2013年12月2日、<https://docs.google.com/document/ D / 1RNHKX_VVKWYWG6RR8SZ-SAQSQX7RFV-EV2JRFUOVD34 /編集？USP =共有>。
[GATEWAY] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and M. Kojo, "An experimental study of home gateway characteristics", Proceedings of the 10th ACM SIGCOMM conference on Internet measurement - IMC '10, DOI 10.1145/1879141.1879174, November 2010, <https://doi.org/10.1145/1879141.1879174>.
[ゲートウェイ]Hätönen、S.、Nyrhinen、A.、Eggert、L.、Strowes、S.、Sarolahti、P.、およびM. kojo、「ホームゲートウェイの実験的研究」、第10回ACM SIGCOMM会議の手続きインターネット測定について - IMC '10、DOI 10.1145 / 1879141.1879174、2010年11月、<https://doi.org/10.1145/187914141.1879174>。
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[http2] Belshe、M.、Peon、R.、およびM.Thomson、Ed。、「Hypertext Transfer Protocol Version 2（HTTP/2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https://www.rfc-editor.org/info/rfc7540>。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[IPv6] Theering、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org/ info / rfc8200>。
[QUIC-MANAGEABILITY] Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Transport Protocol", Work in Progress, Internet-Draft, draft-ietf-quic-manageability-11, 21 April 2021, <https://tools.ietf.org/html/draft-ietf-quic-manageability-11>.
[熟練性] Kuehlewind、M.およびB. Trammell、「QUICトランスポートプロトコルの管理性」、進行中の作業、インターネットドラフト、ドラフト-IETF-QUIC-Managemility-11,21 4月21日、<https://Tools.ietf.org/html/draft-ietf-quic-manageability-11>。
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[ランダム]イーストレイク3RD、D.、Schiller、J.、S. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https:///www.rfc-編集者.org / info / rfc4086>。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <https://www.rfc-editor.org/info/rfc1812>.
[RFC1812] Baker、F.、ED。、「IPバージョン4ルータの要件」、RFC 1812、DOI 10.17487 / RFC1812、1995年6月、<https://www.rfc-editor.org/info/rfc1812>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、DE GROUT、GJ、およびE. Lear、「プライベートインターネットの住所配分」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S.、およびA. Romanow、「TCP選択認証オプション」、RFC 2018、DOI 10.17487 / RFC2018、<https:///www.rfc-editor.org/info/rfc2018>
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR. Canetti、 "HMAC：メッセージ認証用keyed-hashing"、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https://www.rfc-編集者.org / info / rfc2104>。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[RFC3449] Balakrishnan、H.、Padmanabhan、V.、Fairhurst、G.、およびM.Sooriyabandara、「ネットワーク経路非対称性のTCP性能の意味」、BCP 69、RFC 3449、DOI 10.17487 / RFC3449、2002年12月、<https://www.rfc-editor.org/info/rfc3449>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R.およびB.B.Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https://www.rfc-editor.org/info/rfc4193>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://www.rfc-editor.org/info/rfc4291>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Theering、S.およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[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>.
[RFC4787] Audet、F、ED。Jennings、「ユニキャストUDPのネットワークアドレス翻訳（NAT）行動要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<https://www.rfc-editor.org/info/rfc4787>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V.およびE.Blanton、「TCP輻輳制御」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<https://www.rfc-editor.org/info/RFC5681>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H.およびP. Eronen、「HMACベースの抽出と拡張キー派生機能（HKDF）」、RFC 5869、DOI 10.17487 / RFC 5869、2010年5月、<https://www.rfc-編集者.org / info / rfc5869>。
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, <https://www.rfc-editor.org/info/rfc7983>.
[RFC7983] Petit-Huguenin、M.およびG.Salgueiro、データグラムトランスポート層セキュリティ（DTLS）拡張（DTLS）拡張（DTLS）拡張（DTLS））、RFC 7983、DOI 10.17487 / RFC7983、2016年9月、<https://www.rfc-editor.org/info/rfc7983>。
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.
[RFC8087] FairHurst、G.およびM. Welzl、「明示的輻輳通知（ECN）を使用する利点」、RFC 8087、DOI 10.17487 / RFC8087、2017年3月、<https://www.rfc-editor.org/info/ RFC8087>。
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.
[RFC8981] Gont、F.、Krishnan、S.、Narten、T.、およびR. Draves、「IPv6のステートレスアドレス自動設定のための一時アドレス拡張機能」、RFC 8981、DOI 10.17487 / RFC8981、2021年2月、<https://www.rfc-editor.org/info/rfc8981>。
[SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[SEC-CONS] Rescorla、E.およびB.Korver、「セキュリティに関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<https://www.rfc-編集者。ORG / INFO / RFC3552>。
[SLOWLORIS] "RSnake" Hansen, R., "Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client!", June 2009, <https://web.archive.org/web/20150315054838/ http://ha.ckers.org/slowloris/>.
[Slowloris]「RSNAKE」ハンセン、R。、「スローロリスへようこそ - 低帯域幅、まだ貪欲で有毒なhttpクライアント！」、2009年6月、<https://web.archive.org/web/20150315054838/ http：//ha.ckers.org/slowloris/>。
The pseudocode in this section describes sample algorithms. These algorithms are intended to be correct and clear, rather than being optimally performant.
このセクションの疑似コードでは、サンプルアルゴリズムについて説明します。これらのアルゴリズムは、最適に実行されるのではなく、正しいかつ明確であることを意図しています。
The pseudocode segments in this section are licensed as Code Components; see the Copyright Notice.
このセクションの疑似コードセグメントはコードコンポーネントとしてライセンスされています。著作権表示を参照してください。
The pseudocode in Figure 45 shows how a variable-length integer can be read from a stream of bytes. The function ReadVarint takes a single argument -- a sequence of bytes, which can be read in network byte order.
図45の疑似コードは、可変長整数をバイトのストリームから読み取ることができる方法を示しています。関数ReadVarintは単一の引数を取ります - ネットワークバイト順序で読み取ることができます。
ReadVarint(data):
// The length of variable-length integers is encoded in the
// first two bits of the first byte.
v = data.next_byte()
prefix = v >> 6
length = 1 << prefix
// Once the length is known, remove these bits and read any
// remaining bytes.
v = v & 0x3f
repeat length-1 times:
v = (v << 8) + data.next_byte()
return v
Figure 45: Sample Variable-Length Integer Decoding Algorithm
図45：サンプル可変長整数復号化アルゴリズム
For example, the eight-byte sequence 0xc2197c5eff14e88c decodes to the decimal value 151,288,809,941,952,652; the four-byte sequence 0x9d7f3e7d decodes to 494,878,333; the two-byte sequence 0x7bbd decodes to 15,293; and the single byte 0x25 decodes to 37 (as does the two-byte sequence 0x4025).
たとえば、8バイトのシーケンス0xc2197c5eff14e88cは10進値151,288,809,941,952,652に復号されます。4バイトシーケンス0x9d7f3e7dは494,878,333に復号されます。2バイトシーケンス0x7bbdは15,293にデコードします。単一バイト0x25は37にデコードします（2バイトのシーケンス0x4025と同様）。
The pseudocode in Figure 46 shows how an implementation can select an appropriate size for packet number encodings.
図46の疑似コードは、実装がパケット番号エンコーディングに適切なサイズを選択できる方法を示しています。
The EncodePacketNumber function takes two arguments:
EncodePacketNumber関数は2つの引数を取ります。
* full_pn is the full packet number of the packet being sent.
* full_pnは送信されているパケットのフルパケット番号です。
* largest_acked is the largest packet number that has been acknowledged by the peer in the current packet number space, if any.
* largest_akkedは、現在のパケット番号スペースのピアによって確認された最大のパケット番号です。
EncodePacketNumber(full_pn, largest_acked):
// The number of bits must be at least one more
// than the base-2 logarithm of the number of contiguous
// unacknowledged packet numbers, including the new packet.
if largest_acked is None:
num_unacked = full_pn + 1
else:
num_unacked = full_pn - largest_acked
min_bits = log(num_unacked, 2) + 1
num_bytes = ceil(min_bits / 8)
// Encode the integer value and truncate to
// the num_bytes least significant bytes.
return encode(full_pn, num_bytes)
Figure 46: Sample Packet Number Encoding Algorithm
図46：サンプルパケット番号エンコードアルゴリズム
For example, if an endpoint has received an acknowledgment for packet 0xabe8b3 and is sending a packet with a number of 0xac5c02, there are 29,519 (0x734f) outstanding packet numbers. In order to represent at least twice this range (59,038 packets, or 0xe69e), 16 bits are required.
たとえば、エンドポイントがパケット0xabe8b3の確認応答を受信し、数の0xac5c02のパケットを送信している場合は、29,519（0x734F）未処理パケット番号があります。この範囲（59,038パケット、または0xE69e）を少なくとも2倍にするためには、16ビットが必要です。
In the same state, sending a packet with a number of 0xace8fe uses the 24-bit encoding, because at least 18 bits are required to represent twice the range (131,222 packets, or 0x020096).
同じ状態で、少なくとも18ビットの範囲（131,222パケット、または0x020096）を表すためには、少なくとも18ビットが必要とされるため、24ビット符号化を使用するパケットを使用します。
The pseudocode in Figure 47 includes an example algorithm for decoding packet numbers after header protection has been removed.
図47の擬似コードは、ヘッダ保護が解除された後にパケット番号を復号するための例示的なアルゴリズムを含む。
The DecodePacketNumber function takes three arguments:
DecodePacketNumber関数は3つの引数を取ります。
* largest_pn is the largest packet number that has been successfully processed in the current packet number space.
* largest_pnは、現在のパケット番号スペースで正常に処理された最大のパケット番号です。
* truncated_pn is the value of the Packet Number field.
* truncated_pnはパケット番号フィールドの値です。
* pn_nbits is the number of bits in the Packet Number field (8, 16, 24, or 32).
* pn_nbitsは、パケット番号フィールド（8,16,24または32）のビット数です。
DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
expected_pn = largest_pn + 1
pn_win = 1 << pn_nbits
pn_hwin = pn_win / 2
pn_mask = pn_win - 1
// The incoming packet number should be greater than
// expected_pn - pn_hwin and less than or equal to
// expected_pn + pn_hwin
//
// This means we cannot just strip the trailing bits from
// expected_pn and add the truncated_pn because that might
// yield a value outside the window.
//
// The following code calculates a candidate value and
// makes sure it's within the packet number window.
// Note the extra checks to prevent overflow and underflow.
candidate_pn = (expected_pn & ~pn_mask) | truncated_pn
if candidate_pn <= expected_pn - pn_hwin and
candidate_pn < (1 << 62) - pn_win:
return candidate_pn + pn_win
if candidate_pn > expected_pn + pn_hwin and
candidate_pn >= pn_win:
return candidate_pn - pn_win
return candidate_pn
Figure 47: Sample Packet Number Decoding Algorithm
図47：パケット番号復号化アルゴリズムのサンプル
For example, if the highest successfully authenticated packet had a packet number of 0xa82f30ea, then a packet containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32.
たとえば、最も高い認証されたパケットが0xa82F3EAのパケット番号を持っていた場合、16ビット値の0x9B32を含むパケットは0xA82F9B32としてデコードされます。
Each time an endpoint commences sending on a new network path, it determines whether the path supports ECN; see Section 13.4. If the path supports ECN, the goal is to use ECN. Endpoints might also periodically reassess a path that was determined to not support ECN.
エンドポイントが新しいネットワークパス上で送信を開始するたびに、パスがECNをサポートするかどうかを決定します。13.4項を参照してください。パスがECNをサポートしている場合、目標はECNを使用することです。エンドポイントはまた、ECNをサポートしていないと判断されたパスを定期的に再保存する可能性があります。
This section describes one method for testing new paths. This algorithm is intended to show how a path might be tested for ECN support. Endpoints can implement different methods.
このセクションでは、新しいパスをテストするための1つの方法について説明します。このアルゴリズムは、経路がECNサポートについてどのようにテストされる可能性があるかを示すことを目的としています。エンドポイントはさまざまなメソッドを実装できます。
The path is assigned an ECN state that is one of "testing", "unknown", "failed", or "capable". On paths with a "testing" or "capable" state, the endpoint sends packets with an ECT marking -- ECT(0) by default; otherwise, the endpoint sends unmarked packets.
パスには、「テスト」、「不明」、「故障」、「有能な」のいずれかであるECN状態が割り当てられています。「テスト」または「対応」状態のパスでは、エンドポイントはデフォルトでECTマーキングを持つパケットを送信します。それ以外の場合、エンドポイントはマークされていないパケットを送信します。
To start testing a path, the ECN state is set to "testing", and existing ECN counts are remembered as a baseline.
パスのテストを開始するために、ECN状態は「テスト」に設定され、既存のECNカウントはベースラインとして記憶されています。
The testing period runs for a number of packets or a limited time, as determined by the endpoint. The goal is not to limit the duration of the testing period but to ensure that enough marked packets are sent for received ECN counts to provide a clear indication of how the path treats marked packets. Section 13.4.2 suggests limiting this to ten packets or three times the PTO.
テスト期間は、エンドポイントによって決定されるように、いくつかのパケットまたは限られた時間の間実行されます。目標は、テスト期間の期間を制限することではなく、十分なマークされたパケットが受信されたECNカウントに対して送信され、パスがパケットのマークされたパケットの扱いを明確に示すことを確実にすることです。セクション13.4.2これを10パケットまたはPTOの3倍に制限することをお勧めします。
After the testing period ends, the ECN state for the path becomes "unknown". From the "unknown" state, successful validation of the ECN counts in an ACK frame (see Section 13.4.2.1) causes the ECN state for the path to become "capable", unless no marked packet has been acknowledged.
テスト期間が終了した後、パスのECN状態は「不明」になります。「不明」状態から、ACKフレーム内のECNカウントの検証が成功しました（セクション13.4.2.1を参照）マークされたパケットが確認されていない限り、パスのECN状態が「対応」になります。
If validation of ECN counts fails at any time, the ECN state for the affected path becomes "failed". An endpoint can also mark the ECN state for a path as "failed" if marked packets are all declared lost or if they are all ECN-CE marked.
ECNカウントの検証がいつでも失敗した場合、影響を受けるパスのECN状態は「失敗」になります。エンドポイントは、マークされたパケットがすべて失われた場合、またはそれらがすべてECN-CEのマークされている場合に、パスのECN状態を「失敗」としてマークすることもできます。
Following this algorithm ensures that ECN is rarely disabled for paths that properly support ECN. Any path that incorrectly modifies markings will cause ECN to be disabled. For those rare cases where marked packets are discarded by the path, the short duration of the testing period limits the number of losses incurred.
このアルゴリズムに続いて、ECNが正しくサポートされている経路に対してECNが無効にされることを保証します。マーキングを誤って変更するパスは、ECNを無効にします。マークされたパケットが経路によって廃棄されるまれな場合には、テスト期間の短い期間が発生した損失の数を制限します。
Contributors
貢献者
The original design and rationale behind this protocol draw significantly from work by Jim Roskind [EARLY-DESIGN].
この議定書の後ろのオリジナルのデザインと根拠は、Jim Roskind [早期デザイン]による作業から大きく描きます。
The IETF QUIC Working Group received an enormous amount of support from many people. The following people provided substantive contributions to this document:
IETF熟練したワーキンググループは、多くの人々から膨大な量のサポートを受けました。以下の人々はこの文書への実質的な貢献を提供しました：
* Alessandro Ghedini * Alyssa Wilk * Antoine Delignat-Lavaud * Brian Trammell * Christian Huitema * Colin Perkins * David Schinazi * Dmitri Tikhonov * Eric Kinnear * Eric Rescorla * Gorry Fairhurst * Ian Swett * Igor Lubashev * 奥 一穂 (Kazuho Oku) * Lars Eggert * Lucas Pardue * Magnus Westerlund * Marten Seemann * Martin Duke * Mike Bishop * Mikkel Fahnøe Jørgensen * Mirja Kühlewind * Nick Banks * Nick Harper * Patrick McManus * Roberto Peon * Ryan Hamilton * Subodh Iyengar * Tatsuhiro Tsujikawa * Ted Hardie * Tom Jones * Victor Vasiliev
* Alessandro Ghedini * Alyssa Wilk * Antoine Delignat-Lavaud * Brian Trammell * Christian Huitema * Colin Perkins * David Schinazi * Dmitri Tikhonov * Eric Kinnear * Eric Rescorla * Gorry Fairhurst * Ian Swett * Igor Lubashev * 奥 一穂 (Kazuho Oku) * Lars Eggert * Lucas Pardue * Magnus Westerlund * Marten Seemann * Martin Duke * Mike Bishop * Mikkel Fahnøe Jørgensen * Mirja Kühlewind * Nick Banks * Nick Harper * Patrick McManus * Roberto Peon * Ryan Hamilton * Subodh Iyengar * Tatsuhiro Tsujikawa * Ted Hardie * Tom Jones * Victor Vasiliev
Authors' Addresses
著者の住所
Jana Iyengar (editor) Fastly
Jana Iyengar（編集者）Fastly
Email: jri.ietf@gmail.com
Martin Thomson (editor) Mozilla
Martin Thomson（編集）Mozilla.
Email: mt@lowentropy.net