[要約] RFC 9308は、QUICトランスポートプロトコルの適用性に焦点を当て、QUIC上でのアプリケーションプロトコル開発と展開に影響を与える注意点について説明しています。この文書の目的は、QUICへのアプリケーションプロトコルのマッピングを設計する者やこれらのアプリケーションプロトコルの実装者を対象としています。
Internet Engineering Task Force (IETF) M. Kühlewind
Request for Comments: 9308 Ericsson
Category: Informational B. Trammell
ISSN: 2070-1721 Google Switzerland GmbH
September 2022
Applicability of the QUIC Transport Protocol
QUIC輸送プロトコルの適用可能性
Abstract
概要
This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols.
このドキュメントでは、QUIC輸送プロトコルの適用性について説明し、アプリケーションプロトコルの開発とQUICを介した展開に影響を与える警告に焦点を当てています。意図したオーディエンスは、これらのアプリケーションプロトコルのQUICへのアプリケーションプロトコルマッピングおよび実装者の設計者です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9308.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9308で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. The Necessity of Fallback
3. 0-RTT
3.1. Replay Attacks
3.2. Session Resumption versus Keep-Alive
4. Use of Streams
4.1. Stream versus Flow Multiplexing
4.2. Prioritization
4.3. Ordered and Reliable Delivery
4.4. Flow Control Deadlocks
4.5. Stream Limit Commitments
5. Packetization and Latency
6. Error Handling
7. Acknowledgment Efficiency
8. Port Selection and Application Endpoint Discovery
8.1. Source Port Selection
9. Connection Migration
10. Connection Termination
11. Information Exposure and the Connection ID
11.1. Server-Generated Connection ID
11.2. Mitigating Timing Linkability with Connection ID Migration
11.3. Using Server Retry for Redirection
12. Quality of Service (QoS) and Diffserv Code Point (DSCP)
13. Use of Versions and Cryptographic Handshake
14. Enabling Deployment of New Versions
15. Unreliable Datagram Service over QUIC
16. IANA Considerations
17. Security Considerations
18. References
18.1. Normative References
18.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
QUIC [QUIC] is a new transport protocol providing a number of advanced features. While initially designed for the HTTP use case, it provides capabilities that can be used with a much wider variety of applications. QUIC is encapsulated in UDP. QUIC version 1 integrates TLS 1.3 [TLS13] to encrypt all payload data and most control information. The version of HTTP that uses QUIC is known as HTTP/3 [QUIC-HTTP].
QUIC [QUIC]は、多くの高度な機能を提供する新しいトランスポートプロトコルです。最初はHTTPユースケース向けに設計されていますが、はるかに幅広いアプリケーションで使用できる機能を提供します。QUICはUDPにカプセル化されています。QUICバージョン1は、TLS 1.3 [TLS13]を統合して、すべてのペイロードデータとほとんどの制御情報を暗号化します。QUICを使用するHTTPのバージョンは、HTTP/3 [QUIC-HTTP]として知られています。
This document provides guidance for application developers who want to use the QUIC protocol without implementing it on their own. This includes general guidance for applications operating over HTTP/3 or directly over QUIC.
このドキュメントは、QUICプロトコルを独自に実装せずに使用したいアプリケーション開発者向けのガイダンスを提供します。これには、HTTP/3またはQUICで直接動作するアプリケーションの一般的なガイダンスが含まれます。
In the following sections, we discuss specific caveats to QUIC's applicability and issues that application developers must consider when using QUIC as a transport for their applications.
次のセクションでは、QUICの適用可能性と、アプリケーション開発者がアプリケーションのトランスポートとしてQUICを使用する際に考慮しなければならない問題に対する特定の注意事項について説明します。
QUIC uses UDP as a substrate. This enables userspace implementation and permits traversal of network middleboxes (including NAT) without requiring updates to existing network infrastructure.
QuicはUDPを基板として使用します。これにより、ユーザースペースの実装が可能になり、既存のネットワークインフラストラクチャの更新を必要とせずに、ネットワークミドルボックス（NATを含む）の移動を許可します。
Measurement studies have shown between 3% [Trammell16] and 5% [Swett16] of networks block all UDP traffic, though there is little evidence of other forms of systematic disadvantage to UDP traffic compared to TCP [Edeline16]. This blocking implies that all applications running on top of QUIC must either be prepared to accept connectivity failure on such networks or be engineered to fall back to some other transport protocol. In the case of HTTP, this fallback is TLS over TCP.
測定研究では、ネットワークの3％[Trammell16]と5％[SWETT16]の間ですべてのUDPトラフィックをブロックしていますが、TCP [Edeline16]と比較してUDPトラフィックに対する他の形態の形態の不利な点はほとんどありません。このブロッキングは、QUICに加えて実行されているすべてのアプリケーションを、そのようなネットワークで接続障害を受け入れるために準備するか、他の輸送プロトコルに戻るように設計されている必要があることを意味します。HTTPの場合、このフォールバックはTCPを超えるTLSです。
The IETF Transport Services (TAPS) specifications [TAPS-ARCH] describe a system with a common API for multiple protocols. This is particularly relevant for QUIC as it addresses the implications of fallback among multiple protocols.
IETF Transport Services（TAPS）仕様[TAPS-ARCH]は、複数のプロトコルの一般的なAPIを持つシステムを説明しています。これは、複数のプロトコル間のフォールバックの意味に対処するため、QUICに特に関連しています。
Specifically, fallback to insecure protocols or to weaker versions of secure protocols needs to be avoided. In general, an application that implements fallback needs to consider the security consequences. A fallback to TCP and TLS exposes control information to modification and manipulation in the network. Additionally, downgrades to TLS versions older than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection. For example, the results of protocol negotiation [RFC7301] only have confidentiality protection if TLS 1.3 is used.
具体的には、安全なプロトコルまたは安全なプロトコルの弱いバージョンへのフォールバックを避ける必要があります。一般に、フォールバックを実装するアプリケーションは、セキュリティの結果を考慮する必要があります。TCPおよびTLSへのフォールバックは、コントロール情報をネットワーク内の変更と操作に公開します。さらに、QUICバージョン1で使用されている1.3を超えるTLSバージョンの格下げは、暗号化保護が大幅に弱くなる可能性があります。たとえば、プロトコル交渉の結果[RFC7301]には、TLS 1.3が使用されている場合のみ機密保護があります。
These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the fallback protocol. For fallback to TLS over TCP, the most obvious difference is that TCP does not provide stream multiplexing, and therefore stream multiplexing would need to be implemented in the application layer if needed. Further, TCP implementations and network paths often do not support the TCP Fast Open (TFO) option [RFC7413], which enables sending of payload data together with the first control packet of a new connection as also provided by 0-RTT session resumption in QUIC. Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see [PaaschNanog]). And even if Fast Open successfully operates end to end, it is limited to a single packet of TLS handshake and application data, unlike QUIC 0-RTT.
これらのアプリケーションは、おそらく機能障害のある場合、FALLBACKプロトコルに存在しないQUICによって提供される機能がない場合に動作する必要があります。TCPを介したTLSへのフォールバックの場合、最も明らかな違いは、TCPがストリーム多重化を提供しないため、必要に応じてアプリケーションレイヤーにストリームマルチプレックスを実装する必要があることです。さらに、TCPの実装とネットワークパスは、多くの場合、TCP Fast Open（TFO）オプション[RFC7413]をサポートしていません。。TFOが正常にネゴシエートされたとしても、Synデータをブロックするミドルボックスの証拠があることに注意してください（[Paaschnanog]を参照）。また、Fast Openがエンドツーエンドの動作に正常に動作する場合でも、QUIC 0-RTTとは異なり、TLSハンドシェイクとアプリケーションデータの単一パケットに制限されます。
Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked. If TLS over TCP cannot be supported, the connection should be aborted, and the application then ought to present a suitable prompt to the user that secure communication is unavailable.
さらに、暗号化（この場合はTLS）はQUICと不可分に統合されていますが、TCPを介したTLS交渉をブロックできます。TCPを介したTLSをサポートできない場合、接続を中止する必要があり、アプリケーションはユーザーに適切なプロンプトを提示する必要があります。
In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not silently violate the application's expectation of confidentiality or integrity of its payload data.
要約すると、フォールバックメカニズムはパフォーマンスの低下を課す可能性が高く、セキュリティを分解する可能性があります。ただし、Fallbackは、アプリケーションの機密性やペイロードデータの整合性に対する期待に静かに違反してはなりません。
QUIC provides for 0-RTT connection establishment. Though the same facility exists in TLS 1.3 with TCP, 0-RTT presents opportunities and challenges for applications using QUIC.
QUICは、0-RTT接続確立を提供します。同じ施設はTLS 1.3にTCPを搭載していますが、0-RTTはQUICを使用したアプリケーションの機会と課題を提示します。
A transport protocol that provides 0-RTT connection establishment is qualitatively different from one that does not provide 0-RTT from the point of view of the application using it. Relative trade-offs between the cost of closing and reopening a connection and trying to keep it open are different; see Section 3.2.
0-RTT接続確立を提供するトランスポートプロトコルは、アプリケーションを使用しているアプリケーションの観点から0-RTTを提供しないものと定性的に異なります。接続の閉鎖と再開のコストとそれを開いたままにしようとすることの間の相対的なトレードオフは異なります。セクション3.2を参照してください。
An application needs to deliberately choose to use 0-RTT, as 0-RTT carries a risk of replay attack. Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent. For HTTP, this profile is described in [HTTP-REPLAY].
0-RTTには再生攻撃のリスクがあるため、アプリケーションは0-RTTを使用することを意図的に選択する必要があります。0-RTTを使用するアプリケーションプロトコルには、安全に送信できる情報の種類を説明するプロファイルが必要です。HTTPの場合、このプロファイルは[http-replay]で説明されています。
Retransmission or malicious replay of data contained in 0-RTT packets could cause the server side to receive multiple copies of the same data.
0-RTTパケットに含まれるデータの再送信または悪意のあるリプレイにより、サーバー側が同じデータの複数のコピーを受信する可能性があります。
Application data sent by the client in 0-RTT packets could be processed more than once if it is replayed. Applications need to be aware of what is safe to send in 0-RTT. Application protocols that seek to enable the use of 0-RTT need a careful analysis and a description of what can be sent in 0-RTT; see Section 5.6 of [QUIC-TLS].
クライアントが0-RTTパケットで送信したアプリケーションデータは、再生された場合に複数回処理できます。アプリケーションは、0-RTTで安全なものを送信するものを認識する必要があります。0-RTTの使用を可能にしようとするアプリケーションプロトコルには、慎重な分析と0-RTTで送信できるものの説明が必要です。[quic-tls]のセクション5.6を参照してください。
In some cases, it might be sufficient to limit application data sent in 0-RTT to data that does not cause actions with lasting effects at a server. Initiating data retrieval or establishing configuration are examples of actions that could be safe. Idempotent operations -- those for which repetition has the same net effect as a single operation -- might be safe. However, it is also possible to combine individually idempotent operations into a non-idempotent sequence of operations.
場合によっては、0-RTTで送信されたアプリケーションデータを、サーバーで持続的な効果を持つアクションを引き起こさないデータに制限するだけで十分かもしれません。データの取得を開始するか、構成の確立は、安全なアクションの例です。iDempotent操作 - 繰り返しが単一の操作と同じ正味効果を持っている操作は安全かもしれません。ただし、個々の等容量操作を非強力な操作シーケンスに組み合わせることもできます。
Once a server accepts 0-RTT data, there is no means of selectively discarding data that is received. However, protocols can define ways to reject individual actions that might be unsafe if replayed.
サーバーが0-RTTデータを受け入れると、受信されるデータを選択的に破棄する手段はありません。ただし、プロトコルは、再生された場合に安全でない可能性のある個々のアクションを拒否する方法を定義できます。
Some TLS implementations and deployments might be able to provide partial or even complete replay protection, which could be used to manage replay risk.
一部のTLS実装と展開は、リプレイリスクを管理するために使用できる部分的または完全なリプレイ保護を提供できる場合があります。
Because QUIC is encapsulated in UDP, applications using QUIC must deal with short network idle timeouts. Deployed stateful middleboxes will generally establish state for UDP flows on the first packet sent and keep state for much shorter idle periods than for TCP. [RFC5382] suggests a TCP idle period of at least 124 minutes, though there is no evidence of widespread implementation of this guideline in the literature. However, short network timeout for UDP is well-documented. According to a 2010 study ([Hatonen10]), UDP applications can assume that any NAT binding or other state entry can expire after just thirty seconds of inactivity. Section 3.5 of [RFC8085] further discusses keep-alive intervals for UDP: it requires that there is a minimum value of 15 seconds, but recommends larger values, or that keep-alive is omitted entirely.
QUICはUDPにカプセル化されているため、QUICを使用したアプリケーションは、短いネットワークのアイドルタイムアウトを処理する必要があります。展開されたステートフルミドルボックスは、通常、送信された最初のパケットでUDPフローの状態を確立し、TCPよりもはるかに短いアイドル期間にわたって状態を維持します。[RFC5382]は、少なくとも124分のTCPアイドル期間を示唆していますが、文献におけるこのガイドラインの広範な実装の証拠はありません。ただし、UDPの短いネットワークタイムアウトは十分に文書化されています。2010年の調査（[hatonen10]）によると、UDPアプリケーションは、わずか30秒の不活動後にNAT結合または他の状態のエントリが期限切れになる可能性があると想定できます。[RFC8085]のセクション3.5は、UDPのキープアライブ間隔についてさらに説明します。最小値は15秒である必要がありますが、より大きな値を推奨するか、キープアライブを完全に省略します。
By using a connection ID, QUIC is designed to be robust to NAT rebinding after a timeout. However, this only helps if one endpoint maintains availability at the address its peer uses and the peer is the one to send after the timeout occurs.
接続IDを使用することにより、QUICは、タイムアウト後のNATリバインドに対して堅牢になるように設計されています。ただし、これは、1つのエンドポイントがピアの使用アドレスで可用性を維持し、ピアがタイムアウトが発生した後に送信する場合にのみ役立ちます。
Some QUIC connections might not be robust to NAT rebinding because the routing infrastructure (in particular, load balancers) uses the address/port 4-tuple to direct traffic. Furthermore, middleboxes with functions other than address translation could still affect the path. In particular, some firewalls do not admit server traffic for which the firewall has no recent state for a corresponding packet sent from the client.
ルーティングインフラストラクチャ（特に、ロードバランサー）がアドレス/ポート4タプルを使用してトラフィックを直接使用するため、一部のQUIC接続はNATのリバインディングに対して堅牢ではない場合があります。さらに、アドレス変換以外の機能を備えたミドルボックスは、パスに依然として影響する可能性があります。特に、一部のファイアウォールは、クライアントから送信される対応するパケットの最近の状態がファイアウォールにないサーバートラフィックを認めていません。
QUIC applications can adjust idle periods to manage the risk of timeout. Idle periods and the network idle timeout are distinct from the connection idle timeout, which is defined as the minimum of either endpoint's idle timeout parameter; see Section 10.1 of [QUIC]. There are three options:
QUICアプリケーションは、タイムアウトのリスクを管理するためにアイドル期間を調整できます。アイドル期間とネットワークのアイドルタイムアウトは、接続アイドルタイムアウトとは異なります。これは、エンドポイントのアイドルタイムアウトパラメーターの最小値として定義されます。[quic]のセクション10.1を参照してください。3つのオプションがあります。
* Ignore the issue if the application-layer protocol consists only of interactions with no or very short idle periods or if the protocol's resistance to NAT rebinding is sufficient.
* アプリケーション層プロトコルが、無効または非常に短いアイドル期間との相互作用のみで構成されている場合、またはNATリバインディングに対するプロトコルの抵抗で十分である場合、問題を無視してください。
* Ensure there are no long idle periods.
* 長いアイドル期間がないことを確認してください。
* Resume the session after a long idle period, using 0-RTT resumption when appropriate.
* 必要に応じて0-RTT再開を使用して、長いアイドル期間後にセッションを再開します。
The first strategy is the easiest, but it only applies to certain applications.
最初の戦略は最も簡単ですが、特定のアプリケーションにのみ適用されます。
Either the server or the client in a QUIC application can send PING frames as keep-alives to prevent the connection and any on-path state from timing out. Recommendations for the use of keep-alives are application specific, mainly depending on the latency requirements and message frequency of the application. In this case, the application mapping must specify whether the client or server is responsible for keeping the application alive. While [Hatonen10] suggests that 30 seconds might be a suitable value for the public Internet when a NAT is on path, larger values are preferable if the deployment can consistently survive NAT rebinding or is known to be in a controlled environment (e.g., data centers) in order to lower network and computational load.
QUICアプリケーションのサーバーまたはクライアントのいずれかが、接続とパス上の状態がタイミングを出すのを防ぐために、Keep-AlivesとしてPingフレームを送信できます。キープアリブの使用に関する推奨事項は、主にアプリケーションのレイテンシ要件とメッセージ頻度に応じて、アプリケーション固有です。この場合、アプリケーションマッピングは、クライアントまたはサーバーがアプリケーションを生かし続ける責任があるかどうかを指定する必要があります。[hatonen10]は、NATがパス上にある場合、30秒がパブリックインターネットに適した値になる可能性があることを示唆していますが、展開が一貫してNATの再バンディングに耐えることができる場合、または制御された環境にあることが知られている場合（例：データセンター）、より大きな値が望ましいことが示唆されています。）ネットワークと計算の負荷を下げるため。
Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations and unacceptable power usage for power-constrained (mobile) devices. Additionally, timeouts shorter than 30 seconds can make it harder to handle transient network interruptions, such as Virtual Machine (VM) migration or coverage loss during mobility. See [RFC8085], especially Section 3.5.
長いアイドル期間にわたって30秒ごとにPingフレームを頻繁に送信すると、状況によっては過度の非生産的なトラフィックが発生し、電力制約のある（モバイル）デバイスの容認できない電力使用量が生じる可能性があります。さらに、30秒未満のタイムアウトにより、仮想マシン（VM）の移行やモビリティ中のカバレッジ損失など、一時的なネットワーク中断を処理するのが難しくなります。[RFC8085]、特にセクション3.5を参照してください。
Alternatively, the client (but not the server) can use session resumption instead of sending keep-alive traffic. In this case, a client that wants to send data to a server over a connection that has been idle longer than the server's idle timeout (available from the idle_timeout transport parameter) can simply reconnect. When possible, this reconnection can use 0-RTT session resumption, reducing the latency involved with restarting the connection. Of course, this approach is only valid in cases in which it is safe to use 0-RTT and when the client is the restarting peer.
または、クライアント（サーバーではなく）は、キープアライブトラフィックを送信する代わりにセッション再開を使用できます。この場合、サーバーのアイドルタイムアウトよりも長くアイドル状態になっている接続を介してサーバーにデータを送信したいクライアント（IDLE_Timeout Transportパラメーターから利用可能）は、単に再接続できます。可能な場合、この再接続は0-RTTセッション再開を使用して、接続の再起動に伴うレイテンシを減らすことができます。もちろん、このアプローチは、0-RTTを使用しても安全である場合や、クライアントが再起動のピアである場合にのみ有効です。
The trade-offs between resumption and keep-alives need to be evaluated on a per-application basis. In general, applications should use keep-alives only in circumstances where continued communication is highly likely; [QUIC-HTTP], for instance, recommends using keep-alives only when a request is outstanding.
再開とキープアリブの間のトレードオフは、アプリケーションごとに評価する必要があります。一般に、アプリケーションは、継続的なコミュニケーションが可能性が高い状況でのみKeep-Alivesを使用する必要があります。たとえば、[quic-http]は、リクエストが発行された場合にのみキープアリブを使用することをお勧めします。
QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection without head-of-line blocking between streams. Stream data is carried within frames where one QUIC packet on the wire can carry one or multiple stream frames.
QUICのストリームマルチプレックス機能により、アプリケーションは、ストリーム間の頭のブロックなしに、単一の接続で複数のストリームを実行できます。ストリームデータは、ワイヤー上の1つのQUICパケットが1つまたは複数のストリームフレームを運ぶことができるフレーム内で運ばれます。
Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server. Only the initiator of a unidirectional stream can send data on it.
ストリームは一方向または双方向である可能性があり、クライアントまたはサーバーによってストリームが開始される場合があります。単方向ストリームのイニシエーターのみがデータを送信できます。
Streams and connections can each carry a maximum of 2^62-1 bytes in each direction due to encoding limitations on stream offsets and connection flow control limits. In the presently unlikely event that this limit is reached by an application, a new connection would need to be established.
ストリームと接続は、ストリームオフセットと接続フロー制御制限のエンコード制限により、それぞれ各方向に最大2^62-1バイトを運ぶことができます。この制限がアプリケーションによって到達される可能性が低い場合、新しい接続を確立する必要があります。
Streams can be independently opened and closed, gracefully or abruptly. An application can gracefully close the egress direction of a stream by instructing QUIC to send a FIN bit in a STREAM frame. It cannot gracefully close the ingress direction without a peer-generated FIN, much like in TCP. However, an endpoint can abruptly close the egress direction or request that its peer abruptly close the ingress direction; these actions are fully independent of each other.
ストリームは、独立して開閉できます。優雅に、または突然閉じます。アプリケーションは、QUICにストリームフレームにFINビットを送信するように指示することにより、ストリームの出口方向を優雅に閉じることができます。TCPのように、ピア生成フィンなしでは侵入方向を優雅に閉じることはできません。ただし、エンドポイントは出口方向を突然閉じたり、ピアが突然侵入方向を閉じることを要求したりする可能性があります。これらのアクションは、互いに完全に独立しています。
QUIC does not provide an interface for exceptional handling of any stream. If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually terminate the QUIC connection.
QUICは、ストリームの例外的な取り扱いのためのインターフェイスを提供しません。アプリケーションにとって重要なストリームが閉じられている場合、アプリケーションはアプリケーションレイヤーにエラーメッセージを生成して反対側および/または高レイヤーを通知し、最終的にQUIC接続を終了できます。
Mapping of application data to streams is application specific and described for HTTP/3 in [QUIC-HTTP]. There are a few general principles to apply when designing an application's use of streams:
アプリケーションデータのストリームへのマッピングはアプリケーション固有であり、[quic-http]のHTTP/3について説明します。アプリケーションのストリームの使用を設計する際に適用すべき一般原則がいくつかあります。
* A single stream provides ordering. If the application requires certain data to be received in order, that data should be sent on the same stream. There is no guarantee of transmission, reception, or delivery order across streams.
* 単一のストリームが順序付けを提供します。アプリケーションで特定のデータを順番に受信する必要がある場合、そのデータは同じストリームで送信する必要があります。ストリーム全体で送信、受信、または配達順序の保証はありません。
* Multiple streams provide concurrency. Data that can be processed independently, and therefore would suffer from head-of-line blocking if forced to be received in order, should be transmitted over separate streams.
* 複数のストリームは同時性を提供します。独立して処理できるため、順番に受け取ることを余儀なくされた場合、頭のブロックに悩まされるデータは、別々のストリームを介して送信する必要があります。
* Streams can provide message orientation and allow messages to be canceled. If one message is mapped to a single stream, resetting the stream to expire an unacknowledged message can be used to emulate partial reliability for that message.
* ストリームはメッセージの向きを提供し、メッセージをキャンセルできるようにします。1つのメッセージが単一のストリームにマッピングされている場合、ストリームをリセットして未承認のメッセージを期限切れにすることを使用して、そのメッセージの部分的な信頼性をエミュレートできます。
If a QUIC receiver has opened the maximum allowed concurrent streams, and the sender indicates that more streams are needed, it does not automatically lead to an increase of the maximum number of streams by the receiver. Therefore, an application should consider the maximum number of allowed, currently open, and currently used streams when determining how to map data to streams.
QUICレシーバーが最大許可された同時ストリームを開き、送信者がより多くのストリームが必要であることを示している場合、レシーバーによる最大ストリーム数の増加に自動的に増加しません。したがって、アプリケーションは、データをストリームにマッピングする方法を決定する際に、許可されている、現在開いており、現在使用されている最大数、現在使用されているストリームを考慮する必要があります。
QUIC assigns a numerical identifier, called the stream ID, to each stream. While the relationship between these identifiers and stream types is clearly defined in version 1 of QUIC, future versions might change this relationship for various reasons. QUIC implementations should expose the properties of each stream (which endpoint initiated the stream, whether the stream is unidirectional or bidirectional, the stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the stream ID.
QUICは、ストリームIDと呼ばれる数値識別子を各ストリームに割り当てます。これらの識別子とストリームタイプの関係は、QUICのバージョン1で明確に定義されていますが、将来のバージョンはさまざまな理由でこの関係を変更する可能性があります。QUIC実装では、各ストリームのプロパティを公開する必要があります（このエンドポイントは、ストリームが単方向であろうと双方向であろうと、ストリームに使用されるストリームIDであろうと、ストリームを開始しました）。アプリケーションは、ストリームIDからそれらを推測しようとするのではなく、これらのプロパティを照会する必要があります。
The method of allocating stream identifiers to streams opened by the application might vary between transport implementations. Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated. For example, HTTP/3 uses stream IDs to refer to streams that have already been opened but makes no assumptions about future stream IDs or the way in which they are assigned (see Section 6 of [QUIC-HTTP]).
アプリケーションによって開かれたストリームにストリーム識別子を割り当てる方法は、輸送の実装によって異なる場合があります。したがって、アプリケーションは、特定のストリームIDがまだ割り当てられていないストリームに割り当てられると仮定してはなりません。たとえば、HTTP/3は、ストリームIDを使用して、すでに開いているが、将来のストリームIDまたはそれらの割り当て方法について仮定しないストリームを参照しています（[quic-http]のセクション6を参照）。
Streams are meaningful only to the application; since stream information is carried inside QUIC's encryption boundary, a given packet exposes no information about which stream(s) are carried within the packet. Therefore, stream multiplexing is not intended to be used for differentiating streams in terms of network treatment. Application traffic requiring different network treatment should therefore be carried over different 5-tuples (i.e., multiple QUIC connections). Given QUIC's ability to send application data in the first RTT of a connection (if a previous connection to the same host has been successfully established to provide the necessary credentials), the cost of establishing another connection is extremely low.
ストリームはアプリケーションにのみ意味があります。Stream情報はQuicの暗号化境界内に運ばれるため、特定のパケットはパケット内でどのストリームが運ばれるかについての情報を公開しません。したがって、ストリームマルチプレックスは、ネットワーク処理の観点からストリームを区別するために使用することを意図していません。したがって、異なるネットワーク処理を必要とするアプリケーショントラフィックは、異なる5タプル（つまり、複数のQUIC接続）に携帯する必要があります。接続の最初のRTTにアプリケーションデータを送信するQUICの機能（同じホストへの以前の接続が必要な資格情報を提供するために正常に確立されている場合）を考えると、別の接続を確立するコストは非常に低くなります。
Stream prioritization is not exposed to either the network or the receiver. Prioritization is managed by the sender, and the QUIC transport should provide an interface for applications to prioritize streams [QUIC]. Applications can implement their own prioritization scheme on top of QUIC: an application protocol that runs on top of QUIC can define explicit messages for signaling priority, such as those defined in [RFC9218] for HTTP. An application protocol can define rules that allow an endpoint to determine priority based on context or can provide a higher-level interface and leave the determination to the application on top.
ストリームの優先順位付けは、ネットワークまたは受信機のいずれにもさらされません。優先順位付けは送信者によって管理され、QUICトランスポートは、ストリーム[QUIC]を優先するアプリケーションのインターフェイスを提供する必要があります。アプリケーションは、QUICに加えて独自の優先順位付けスキームを実装できます。QUICに加えて実行されるアプリケーションプロトコルは、HTTPの[RFC9218]で定義されているものなど、シグナリング優先度の明示的なメッセージを定義できます。アプリケーションプロトコルは、エンドポイントがコンテキストに基づいて優先度を決定できるようにするルールを定義したり、高レベルのインターフェイスを提供したり、適用を最上部に決定したりすることができます。
Priority handling of retransmissions can be implemented by the sender in the transport layer. [QUIC] recommends retransmitting lost data before new data, unless indicated differently by the application. When a QUIC endpoint uses fully reliable streams for transmission, prioritization of retransmissions will be beneficial in most cases, filling in gaps and freeing up the flow control window. For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable. For such streams, QUIC could either provide an explicit interface to control prioritization or derive the prioritization decision from the reliability level of the stream.
再送信の優先処理は、輸送層の送信者が実装できます。[QUIC]は、アプリケーションによって異なる方法で示されない限り、新しいデータの前に失われたデータを再送信することをお勧めします。QUICエンドポイントが送信に完全に信頼性の高いストリームを使用する場合、ほとんどの場合、再送信の優先順位付けは有益であり、ギャップを埋めてフロー制御ウィンドウを解放します。部分的に信頼性の高いストリームまたは信頼性の低いストリームの場合、より優先順位のストリームのデータに対する再送信の優先スケジューリングは望ましくない場合があります。このようなストリームの場合、QUICは、優先順位付けを制御するための明示的なインターフェイスを提供するか、ストリームの信頼性レベルから優先順位付け決定を導き出すことができます。
QUIC streams enable ordered and reliable delivery. Though it is possible for an implementation to provide options that use streams for partial reliability or out-of-order delivery, most implementations will assume that data is reliably delivered in order.
QUICストリームは、注文された信頼性の高い配送を有効にします。実装は、部分的な信頼性または秩序外配信にストリームを使用するオプションを提供することが可能ですが、ほとんどの実装では、データが確実に配信されると仮定します。
Under this assumption, an endpoint that receives stream data might not make forward progress until data that is contiguous with the start of a stream is available. In particular, a receiver might withhold flow control credit until contiguous data is delivered to the application; see Section 2.2 of [QUIC]. To support this receive logic, an endpoint will send stream data until it is acknowledged, ensuring that data at the start of the stream is sent and acknowledged first.
この仮定では、ストリームデータを受信するエンドポイントは、ストリームの開始と隣接するデータが利用可能になるまで、前進しない場合があります。特に、レシーバーは、隣接するデータがアプリケーションに配信されるまで、フロー制御クレジットを差し控える可能性があります。[quic]のセクション2.2を参照してください。これをサポートするために、ロジックを受信するために、エンドポイントは認識されるまでストリームデータを送信し、ストリームの開始時にデータが送信され、最初に確認されるようにします。
An endpoint that uses a different sending behavior and does not negotiate that change with its peer might encounter performance issues or deadlocks.
異なる送信動作を使用し、その変化を同業者と交渉しないエンドポイントは、パフォーマンスの問題やデッドロックに遭遇する可能性があります。
QUIC flow control (Section 4 of [QUIC]) provides a means of managing access to the limited buffers that endpoints have for incoming data. This mechanism limits the amount of data that can be in buffers in endpoints or in transit on the network. However, there are several ways in which limits can produce conditions that can cause a connection to either perform suboptimally or become deadlocked.
QUICフロー制御（[QUIC]のセクション4）は、エンドポイントが着信データに持っている限られたバッファーへのアクセスを管理する手段を提供します。このメカニズムは、エンドポイントのバッファーまたはネットワーク上のトランジットにある可能性のあるデータの量を制限します。ただし、制限が条件を生成して、接続を引き起こす可能性のある条件を生成する方法があります。
Deadlocks in flow control are possible for any protocol that uses QUIC, though whether they become a problem depends on how implementations consume data and provide flow control credit. Understanding what causes deadlocking might help implementations avoid deadlocks.
QUICを使用するプロトコルでは、フロー制御のデッドロックが可能ですが、問題になるかどうかは、実装がデータを消費し、フロー制御クレジットを提供する方法に依存します。デッドロックの原因を理解することは、実装がデッドロックを避けるのに役立つ可能性があります。
The size and rate of updates to flow control credit can affect performance. Applications that use QUIC often have a data consumer that reads data from transport buffers. Some implementations might have independent receive buffers at the transport layer and application layer. Consuming data does not always imply it is immediately processed. However, a common implementation technique is to extend flow control credit to the sender by emitting MAX_DATA and/ or MAX_STREAM_DATA frames as data is consumed. Delivery of these frames is affected by the latency of the back channel from the receiver to the data sender. If credit is not extended in a timely manner, the sending application can be blocked, effectively throttling the sender.
フロー制御クレジットへの更新の規模とレートは、パフォーマンスに影響を与える可能性があります。QUICを使用するアプリケーションには、多くの場合、輸送バッファーからデータを読み取るデータ消費者がいます。一部の実装では、輸送層とアプリケーション層で独立した受信バッファーがある場合があります。データを消費することは、常にそれがすぐに処理されることを意味するとは限りません。ただし、一般的な実装手法は、データが消費されるときにMAX_DATAおよび/またはMAX_STREAM_DATAフレームを発することにより、フロー制御クレジットを送信者に拡張することです。これらのフレームの配信は、受信機からデータ送信者へのバックチャネルの遅延の影響を受けます。クレジットがタイムリーに拡張されていない場合、送信アプリケーションをブロックし、効果的に送信者を調整できます。
Large application messages can produce deadlocking if the recipient does not read data from the transport incrementally. If the message is larger than the flow control credit available and the recipient does not release additional flow control credit until the entire message is received and delivered, a deadlock can occur. This is possible even where stream flow control limits are not reached because connection flow control limits can be consumed by other streams.
大規模なアプリケーションメッセージは、受信者が輸送のデータを徐々に読み取らない場合、デッドロックを生成できます。メッセージが利用可能なフロー制御クレジットよりも大きく、受信者がメッセージ全体が受信および配信されるまで追加のフロー制御クレジットをリリースしない場合、デッドロックが発生する可能性があります。これは、接続フロー制御制限が他のストリームによって消費される可能性があるため、ストリームフロー制御制限に到達しない場合でも可能です。
A length-prefixed message format makes it easier for a data consumer to leave data unread in the transport buffer and thereby withhold flow control credit. If flow control limits prevent the remainder of a message from being sent, a deadlock will result. A length prefix might also enable the detection of this sort of deadlock. Where application protocols have messages that might be processed as a single unit, reserving flow control credit for the entire message atomically makes this style of deadlock less likely.
長さが埋められたメッセージ形式により、データ消費者はトランスポートバッファーでデータを未読のままにしておくと簡単になり、フロー制御クレジットを差し控えます。フロー制御制限が残りのメッセージの送信を防ぐと、デッドロックが生じます。長さのプレフィックスは、この種のデッドロックの検出を可能にする場合があります。アプリケーションプロトコルに単一のユニットとして処理される可能性のあるメッセージがある場合、メッセージ全体のフロー制御クレジットを留保すると、このスタイルのデッドロックが可能性が低くなります。
A data consumer can eagerly read all data as it becomes available in order to make the receiver extend flow control credit and reduce the chances of a deadlock. However, such a data consumer might need other means for holding a peer accountable for the additional state it keeps for partially processed messages.
データ消費者は、レシーバーがフロー制御クレジットを拡張し、デッドロックの可能性を減らすために利用可能になると、すべてのデータを熱心に読み取ることができます。ただし、そのようなデータ消費者は、部分的に処理されたメッセージのために保持する追加の状態に対して、ピアに責任を負わせるために他の手段を必要とするかもしれません。
Deadlocking can also occur if data on different streams is interdependent. Suppose that data on one stream arrives before the data on a second stream on which it depends. A deadlock can occur if the first stream is left unread, preventing the receiver from extending flow control credit for the second stream. To reduce the likelihood of deadlock for interdependent data, the sender should ensure that dependent data is not sent until the data it depends on has been accounted for in both stream- and connection-level flow control credit.
異なるストリームのデータが相互依存している場合、デッドロックも発生する可能性があります。1つのストリームのデータが、それが依存する2番目のストリームのデータの前に到着すると仮定します。最初のストリームが未読のままになっている場合、デッドロックが発生する可能性があり、受信機が2番目のストリームのフロー制御クレジットを拡張できないようにします。相互依存データのデッドロックの可能性を減らすために、送信者は、依存するデータがストリームレベルと接続レベルのフロー制御クレジットの両方で説明されるまで、依存データが送信されないようにする必要があります。
Some deadlocking scenarios might be resolved by canceling affected streams with STOP_SENDING or RESET_STREAM. Canceling some streams results in the connection being terminated in some protocols.
いくつかのデッドロックシナリオは、stop_sendingまたはreset_streamを使用して影響を受けるストリームをキャンセルすることにより解決される場合があります。一部のストリームをキャンセルすると、一部のプロトコルで接続が終了します。
QUIC endpoints are responsible for communicating the cumulative limit of streams they would allow to be opened by their peer. Initial limits are advertised using the initial_max_streams_bidi and initial_max_streams_uni transport parameters. As streams are opened and closed, they are consumed, and the cumulative total is incremented. Limits can be increased using the MAX_STREAMS frame, but there is no mechanism to reduce limits. Once stream limits are reached, no more streams can be opened, which prevents applications using QUIC from making further progress. At this stage, connections can be terminated via idle timeout or explicit close; see Section 10.
QUICエンドポイントは、ピアによって開くことができるストリームの累積制限を伝える責任があります。初期制限は、initial_max_streams_bidiおよびinitial_max_streams_uniトランスポートパラメーターを使用して宣伝されます。ストリームが開閉すると、それらは消費され、累積合計が増加します。MAX_STREAMSフレームを使用して制限を増やすことができますが、制限を減らすメカニズムはありません。ストリーム制限に到達すると、ストリームが開かれることはありません。これにより、QUICを使用してアプリケーションがさらに進行することができなくなります。この段階では、接続をアイドルタイムアウトまたは明示的な閉じることで終了できます。セクション10を参照してください。
An application that uses QUIC and communicates a cumulative stream limit might require the connection to be closed before the limit is reached, e.g., to stop the server in order to perform scheduled maintenance. Immediate connection close causes abrupt closure of actively used streams. Depending on how an application uses QUIC streams, this could be undesirable or detrimental to behavior or performance.
QUICを使用して累積ストリーム制限を通知するアプリケーションは、制限に達する前に接続を閉じる必要がある場合があります。たとえば、スケジュールされたメンテナンスを実行するためにサーバーを停止するためです。即時接続の閉鎖により、アクティブに使用されたストリームが急激に閉鎖されます。アプリケーションがQUICストリームをどのように使用するかに応じて、これは行動やパフォーマンスに望ましくないか、有害である可能性があります。
A more graceful closure technique is to stop sending increases to stream limits and allow the connection to naturally terminate once remaining streams are consumed. However, the period of time it takes to do so is dependent on the peer, and an unpredictable closing period might not fit application or operational needs. Applications using QUIC can be conservative with open stream limits in order to reduce the commitment and indeterminism. However, being overly conservative with stream limits affects stream concurrency. Balancing these aspects can be specific to applications and their deployments.
より優雅な閉鎖技術は、ストリーム制限に増加を送信するのを止め、残りのストリームが消費されると接続が自然に終了するようにすることです。ただし、そうするのにかかる期間はピアに依存しており、予測不可能な閉鎖期間では、アプリケーションや運用上のニーズに合わない可能性があります。QUICを使用したアプリケーションは、コミットメントと不確定性を減らすために、オープンストリームの制限で保守的です。ただし、ストリーム制限で過度に保守的であることは、ストリームの同時性に影響します。これらの側面のバランスをとることは、アプリケーションとその展開に固有のものです。
Instead of relying on stream limits to avoid abrupt closure, an application layer's graceful close mechanism can be used to communicate the intention to explicitly close the connection at some future point. HTTP/3 provides such a mechanism using the GOAWAY frame. In HTTP/3, when the GOAWAY frame is received by a client, it stops opening new streams even if the cumulative stream limit would allow. Instead, the client would create a new connection on which to open further streams. Once all streams are closed on the old connection, it can be terminated safely by a connection close or after expiration of the idle timeout (see Section 10).
急激な閉鎖を避けるためにストリーム制限に依存する代わりに、アプリケーションレイヤーの優雅な緊密なメカニズムを使用して、将来のポイントで接続を明示的に閉じる意図を伝えることができます。HTTP/3は、GoAwayフレームを使用してそのようなメカニズムを提供します。HTTP/3では、クライアントがGOAWAYフレームを受信すると、累積ストリームの制限が許可されていても、新しいストリームの開設を停止します。代わりに、クライアントはさらにストリームを開くための新しい接続を作成します。古い接続ですべてのストリームが閉じられたら、接続が近づくか、アイドルタイムアウトの有効期限が切れた後に安全に終了できます（セクション10を参照）。
QUIC exposes an interface that provides multiple streams to the application; however, the application usually cannot control how data transmitted over those streams is mapped into frames or how those frames are bundled into packets.
QUICは、アプリケーションに複数のストリームを提供するインターフェイスを公開します。ただし、通常、アプリケーションは、これらのストリームに送信されるデータがフレームにマッピングされる方法や、それらのフレームがパケットにバンドルされる方法を制御することはできません。
By default, many implementations will try to pack STREAM frames from one or more streams into each QUIC packet, in order to minimize bandwidth consumption and computational costs (see Section 13 of [QUIC]). If there is not enough data available to fill a packet, an implementation might wait for a short time to optimize bandwidth efficiency instead of latency. This delay can either be preconfigured or dynamically adjusted based on the observed sending pattern of the application.
デフォルトでは、多くの実装では、帯域幅の消費と計算コストを最小限に抑えるために、1つ以上のストリームから各QUICパケットにストリームフレームをパックしようとします（[QUIC]のセクション13を参照）。パケットを埋めるのに十分なデータがない場合、実装がレイテンシではなく帯域幅効率を最適化するために短時間待つことができます。この遅延は、アプリケーションの観測された送信パターンに基づいて、事前に設定されるか、動的に調整することができます。
If the application requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data should be sent out immediately. Alternatively, if the application expects to use a specific sending pattern, it can also provide a suggested delay to QUIC for how long to wait before bundling frames into a packet.
アプリケーションが低遅延を必要とし、送信するデータのごく一部のみが必要な場合、すべてのデータをすぐに送信する必要があることをQUICに示すことが価値があるかもしれません。あるいは、アプリケーションが特定の送信パターンを使用することを期待している場合、フレームをパケットにバンドルするまで待つまで待機する時間について、QUICに提案された遅延を提供することもできます。
Similarly, an application usually has no control over the length of a QUIC packet on the wire. QUIC provides the ability to add a PADDING frame to arbitrarily increase the size of packets. Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size during the handshake (see Sections 8.1 and 14.1 of [QUIC]) and for path validation after connection migration (see Section 8.2 of [QUIC]) as well as for Datagram Packetization Layer PMTU Discovery (DPLPMTUD) (see Section 14.3 of [QUIC]).
同様に、アプリケーションは通常、ワイヤ上のQUICパケットの長さを制御できません。QUICは、パケットのサイズを任意に増やすためにパディングフレームを追加する機能を提供します。パディングは、パスが握手中に少なくとも特定のサイズのデータグラムを転送できることを確認するためにQUICによって使用されます（[QUIC]のセクション8.1および14.1を参照）、接続移行後のパス検証の場合（[QUIC]のセクション8.2を参照してください。）データグラムのパケット化レイヤーPMTUディスカバリー（DPLPMTUD）（[QUIC]のセクション14.3を参照）。
Padding can also be used by an application to reduce leakage of information about the data that is sent. A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding.
パディングは、送信されるデータに関する情報の漏れを減らすためにアプリケーションでも使用できます。QUIC実装では、アプリケーションレイヤーがパディングを適用する方法を指定できるインターフェイスを公開できます。
QUIC recommends that endpoints signal any detected errors to the peer. Errors can occur at the transport layer and the application layer. Transport errors, such as a protocol violation, affect the entire connection. Applications that use QUIC can define their own error detection and signaling (see, for example, Section 8 of [QUIC-HTTP]). Application errors can affect an entire connection or a single stream.
QUICは、エンドポイントが検出されたエラーをピアに通知することを推奨しています。エラーは、輸送層とアプリケーション層で発生する可能性があります。プロトコル違反などの輸送エラーは、接続全体に影響します。QUICを使用するアプリケーションは、独自のエラー検出とシグナル伝達を定義できます（たとえば、[Quic-HTTP]のセクション8を参照）。アプリケーションエラーは、接続全体または単一のストリームに影響を与える可能性があります。
QUIC defines an error code space that is used for error handling at the transport layer. QUIC encourages endpoints to use the most specific code, although any applicable code is permitted, including generic ones.
QUICは、トランスポートレイヤーでのエラー処理に使用されるエラーコードスペースを定義します。QUICは、一般的なコードを含む該当するコードは許可されていますが、エンドポイントが最も特定のコードを使用することを奨励しています。
Applications using QUIC define an error code space that is independent of QUIC or other applications (see, for example, Section 8.1 of [QUIC-HTTP]). The values in an application error code space can be reused across connection-level and stream-level errors.
QUICを使用したアプリケーションは、QUICまたは他のアプリケーションに依存しないエラーコードスペースを定義します（たとえば、[QUIC-HTTP]のセクション8.1を参照）。アプリケーションエラーコードスペースの値は、接続レベルとストリームレベルのエラー全体で再利用できます。
Connection errors lead to connection termination. They are signaled using a CONNECTION_CLOSE frame, which contains an error code and a reason field that can be zero length. Different types of CONNECTION_CLOSE frames are used to signal transport and application errors.
接続エラーは接続終了につながります。それらは、connection_closeフレームを使用して信号されます。これには、エラーコードと長さがゼロになる可能性のある理由フィールドが含まれています。さまざまなタイプのConnection_Closeフレームを使用して、輸送エラーとアプリケーションエラーを信号します。
Stream errors lead to stream termination. These are signaled using STOP_SENDING or RESET_STREAM frames, which contain only an error code.
ストリームエラーは、ストリーム終了につながります。これらは、stop_sendingまたはreset_streamフレームを使用してシグナルがあり、エラーコードのみが含まれています。
QUIC version 1 without extensions uses an acknowledgment strategy adopted from TCP (see Section 13.2 of [QUIC]). That is, it recommends that every other packet is acknowledged. However, generating and processing QUIC acknowledgments consumes resources at a sender and receiver. Acknowledgments also incur forwarding costs and contribute to link utilization, which can impact performance over some types of network. Applications might be able to improve overall performance by using alternative strategies that reduce the rate of acknowledgments. [QUIC-ACK-FREQUENCY] describes an extension to signal the desired delay of acknowledgments and discusses use cases as well as implications for congestion control and recovery.
拡張機能のないQUICバージョン1では、TCPから採用された承認戦略を使用します（[QUIC]のセクション13.2を参照）。つまり、他のすべてのパケットが認められることをお勧めします。ただし、生成および処理QUIC謝辞は、送信者とレシーバーでリソースを消費します。また、謝辞は転送コストを負い、リンクの使用率に貢献します。これは、ある種のネットワーク上のパフォーマンスに影響を与える可能性があります。アプリケーションは、謝辞率を下げる代替戦略を使用することにより、全体的なパフォーマンスを改善できる場合があります。[Quic-ack-frequency]は、承認の望ましい遅延を示す拡張を説明し、ユースケースと混雑制御と回復への影響について説明します。
In general, port numbers serve two purposes: "first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes connect" (Section 3 of [RFC6335]). The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation and mechanisms for dynamic port assignments, as noted in [RFC6335].
一般に、ポート番号は2つの目的を果たしています。「第一に、同じエンドポイントのペア間の輸送セッションを区別するための非複数の識別子を提供し、第二に、プロセスが接続するアプリケーションプロトコルと関連サービスを識別することもできます」（のセクション3のセクション3[RFC6335]）。[RFC6335]に記載されているように、ダイナミックポート割り当てのカプセル化とメカニズムにより、ポート番号に基づいてネットワークでアプリケーションを識別できるという仮定は、今日の真実ではありません。
As QUIC is a general-purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC. For an application with a fallback to TCP that does not already have an alternate mapping to UDP, it is usually appropriate to register (if necessary) and use the UDP port number corresponding to the TCP port already registered for the application. For example, the default port for HTTP/3 [QUIC-HTTP] is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP.
QUICは汎用輸送プロトコルであるため、サーバーが特定のUDPポートをQUICに使用する要件はありません。UDPへの代替マッピングがまだないTCPへのフォールバックを備えたアプリケーションの場合、通常（必要に応じて）登録し、アプリケーションに登録されているTCPポートに対応するUDPポート番号を使用することが適切です。たとえば、HTTP/3 [QUIC-HTTP]のデフォルトポートはUDPポート443で、TCPを超えるTLSを超えるHTTP/1.1またはHTTP/2に類似しています。
Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name might lead to blocking or other changes to the forwarding behavior by network elements such as firewalls that use the port number for application identification.
ポート番号がアプリケーションを明確にマッピングするというネットワーク管理慣行における仮定の有病率を考えると、登録されたサービス名に簡単にマッピングできないポートの使用は、ブロッキングまたはその他のネットワーク要素による転送動作の他の変更につながる可能性があります。アプリケーション識別にポート番号を使用するファイアウォール。
Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default. For example, HTTP/3 (Sections 3.2 and 3.3 of [QUIC-HTTP]) specifies the use of HTTP Alternative Services [RFC7838] for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using "h3" as the Application-Layer Protocol Negotiation (ALPN) [RFC7301] token.
アプリケーションは、デフォルト以外のポートを使用できるように、代替エンドポイントディスカバリーメカニズムを定義できます。たとえば、HTTP/3（[QUIC-HTTP]のセクション3.2および3.3）は、HTTPオリジンのHTTP代替サービス[RFC7838]の使用を指定して、特定のUDPポートの同等のHTTP/3エンドポイントの可用性を宣伝し、アプリケーション層プロトコル交渉（ALPN）[RFC7301]トークンとしての「H3」。
ALPN permits the client and server to negotiate which of several protocols will be used on a given connection. Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered. Applications using QUIC are required to register an ALPN token for use in the TLS handshake.
ALPNは、クライアントとサーバーが特定の接続で使用されるいくつかのプロトコルのどれをネゴシエートすることを許可します。したがって、提供されるALPNトークンに基づいて、単一のUDPポートで複数のアプリケーションがサポートされる場合があります。QUICを使用するアプリケーションは、TLSハンドシェイクで使用するためにALPNトークンを登録するために必要です。
As QUIC version 1 deferred defining a complete version negotiation mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token ("h3") to only apply to that version. So far, no single approach has been selected for managing the use of different QUIC versions, neither in HTTP/3 nor in general. Application protocols that use QUIC need to consider how the protocol will manage different QUIC versions. Decisions for those protocols might be informed by choices made by other protocols, like HTTP/3.
QUICバージョン1が完全なバージョンネゴシエーションメカニズムを定義する延期されたため、HTTP/3はQUICバージョン1を必要とし、そのバージョンにのみ適用するためにALPNトークン（ "H3"）を定義します。これまでのところ、異なるQUICバージョンの使用を管理するための単一のアプローチは選択されていません。これは、HTTP/3でも一般的でもありません。QUICを使用するアプリケーションプロトコルは、プロトコルが異なるQUICバージョンをどのように管理するかを検討する必要があります。これらのプロトコルの決定は、HTTP/3のような他のプロトコルによって行われた選択によって通知される場合があります。
Some UDP protocols are vulnerable to reflection attacks, where an attacker is able to direct traffic to a third party as a denial of service. For example, these source ports are associated with applications known to be vulnerable to reflection attacks, often due to server misconfiguration:
一部のUDPプロトコルは、攻撃者がサービスの拒否として第三者にトラフィックを向けることができるリフレクション攻撃に対して脆弱です。たとえば、これらのソースポートは、多くの場合、サーバーの誤解が原因で、反射攻撃に対して脆弱であることが知られているアプリケーションに関連付けられています。
* port 53 - DNS [RFC1034]
* ポート53 -DNS [RFC1034]
* port 123 - NTP [RFC5905]
* ポート123 -NTP [RFC5905]
* port 1900 - SSDP [SSDP]
* ポート1900 -SSDP [SSDP]
* port 5353 - mDNS [RFC6762]
* ポート5353 -MDNS [RFC6762]
* port 11211 - memcache
* ポート11211 -memcache
Services might block source ports associated with protocols known to be vulnerable to reflection attacks to avoid the overhead of processing large numbers of packets. However, this practice has negative effects on clients -- not only does it require establishment of a new connection but in some instances might cause the client to avoid using QUIC for that service for a period of time and downgrade to a non-UDP protocol (see Section 2).
サービスは、多数のパケットを処理するオーバーヘッドを回避するために、反射攻撃に対して脆弱であることが知られているプロトコルに関連するソースポートをブロックする可能性があります。ただし、このプラクティスはクライアントにマイナスの影響を及ぼします。新しい接続の確立が必要であるだけでなく、場合によっては、クライアントがそのサービスにQUICを一定期間使用することを避け、非DUPプロトコルにダウングレードする可能性があります（セクション2を参照）。
As a result, client implementations are encouraged to avoid using source ports associated with protocols known to be vulnerable to reflection attacks. Note that following the general guidance for client implementations given in [RFC6335], to use ephemeral ports in the range 49152-65535, has the effect of avoiding these ports. Note that other source ports might be reflection vectors as well.
その結果、クライアントの実装は、反射攻撃に対して脆弱であることが知られているプロトコルに関連するソースポートの使用を避けるために推奨されます。[RFC6335]に与えられたクライアントの実装の一般的なガイダンスに従って、範囲49152-65535のはかないポートを使用することは、これらのポートを回避する効果があることに注意してください。他のソースポートも反射ベクターである可能性があることに注意してください。
QUIC supports connection migration by the client. If the client's IP address changes, a QUIC endpoint can still associate packets with an existing transport connection using the Destination Connection ID field (see Section 11) in the QUIC header. This supports cases where the address information changes, such as NAT rebinding, the intentional change of the local interface, the expiration of a temporary IPv6 address [RFC8981], or the indication from the server of a preferred address (Section 9.6 of [QUIC]).
QUICは、クライアントによる接続移行をサポートします。クライアントのIPアドレスが変更された場合、QUICエンドポイントは、QUICヘッダーの宛先接続IDフィールド（セクション11を参照）を使用して、既存のトランスポート接続にパケットを関連付けることができます。これは、NATリバインディング、ローカルインターフェイスの意図的な変更、一時的なIPv6アドレスの有効期限[RFC8981]、または優先アドレスのサーバーからの表示など、アドレス情報が変更される場合をサポートします（[QUIC]のセクション9.6）。
Use of a non-zero-length connection ID for the server is strongly recommended if any clients are or could be behind a NAT. A non-zero-length connection ID is also strongly recommended when active migration is supported. If a connection is intentionally migrated to a new path, a new connection ID is used to minimize linkability by network observers. The other QUIC endpoint uses the connection ID to link different addresses to the same connection and entity if a non-zero-length connection ID is provided.
サーバーにゼロ以外の接続IDの使用は、クライアントがNATの背後にいる、または後ろにいる可能性がある場合は、強くお勧めします。アクティブな移行がサポートされている場合は、非ゼロの長さの接続IDも強くお勧めします。接続が意図的に新しいパスに移行された場合、ネットワークオブザーバーによるリンク性を最小限に抑えるために新しい接続IDが使用されます。もう1つのQUICエンドポイントは、接続IDを使用して、非ゼロレングス接続IDが提供されている場合、異なるアドレスを同じ接続とエンティティにリンクします。
The base specification of QUIC version 1 only supports the use of a single network path at a time, which enables failover use cases. Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks. Path validation takes at least one RTT, and congestion control will also be reset after path migration. Therefore, migration usually has a performance impact.
QUICバージョン1のベース仕様は、一度に単一のネットワークパスの使用のみをサポートしているため、フェールオーバーユースケースが可能になります。エンドポイントが使用する前にパスを検証するためにパス検証が必要です。パス検証には少なくとも1つのRTTが必要であり、混雑制御もパス移行後にリセットされます。したがって、移行には通常、パフォーマンスの影響があります。
QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path characteristics. Probing packets cannot carry application data but likely contain padding frames. Endpoints can use information about their receipt as input to congestion control for that path. Applications could use information learned from probing to inform a decision to switch paths.
一度に複数のパスで送信できるQUICプロービングパケットは、アドレス検証を実行し、パスの特性を測定するために使用されます。プローブパケットはアプリケーションデータを運ぶことはできませんが、パディングフレームが含まれている可能性があります。エンドポイントは、領収書に関する情報を、そのパスの混雑制御への入力として使用できます。アプリケーションは、調査から学んだ情報を使用して、パスを切り替える決定を通知することができます。
Only the client can actively migrate in version 1 of QUIC. However, servers can indicate during the handshake that they prefer to transfer the connection to a different address after the handshake. For instance, this could be used to move from an address that is shared by multiple servers to an address that is unique to the server instance. The server can provide an IPv4 and an IPv6 address in a transport parameter during the TLS handshake, and the client can select between the two if both are provided. See Section 9.6 of [QUIC].
QUICのバージョン1で積極的に移行できるのはクライアントのみです。ただし、サーバーは、握手中に、握手後に接続を別のアドレスに転送することを好むことを示すことができます。たとえば、これは、複数のサーバーによって共有されているアドレスから、サーバーインスタンスに固有のアドレスに移動するために使用できます。サーバーは、TLSハンドシェイク中にトランスポートパラメーターにIPv4とIPv6アドレスを提供でき、クライアントは両方が提供されている場合は2つを選択できます。[QUIC]のセクション9.6を参照してください。
QUIC connections are terminated in one of three ways: implicit idle timeout, explicit immediate close, or explicit stateless reset.
QUIC接続は、暗黙のアイドルタイムアウト、明示的な即時閉鎖、または明示的なステートレスリセットの3つの方法のいずれかで終了します。
QUIC does not provide any mechanism for graceful connection termination; applications using QUIC can define their own graceful termination process (see, for example, Section 5.2 of [QUIC-HTTP]).
QUICは、優雅な接続終了のメカニズムを提供しません。QUICを使用したアプリケーションは、独自の優雅な終了プロセスを定義できます（たとえば、[QUIC-HTTP]のセクション5.2を参照）。
QUIC idle timeout is enabled via transport parameters. The client and server announce a timeout period, and the effective value for the connection is the minimum of the two values. After the timeout period elapses, the connection is silently closed. An application therefore should be able to configure its own maximum value, as well as have access to the computed minimum value for this connection. An application may adjust the maximum idle timeout for new connections based on the number of open or expected connections since shorter timeout values may free up resources more quickly.
QUICアイドルタイムアウトは、輸送パラメーターを介して有効になります。クライアントとサーバーはタイムアウト期間を発表し、接続の実効値は2つの値の最小値です。タイムアウト期間が経過した後、接続は静かに閉じられます。したがって、アプリケーションは、独自の最大値を構成し、この接続の計算された最小値にアクセスできる必要があります。アプリケーションは、より短いタイムアウト値がより迅速にリソースを解放する可能性があるため、オープン接続または予想される接続の数に基づいて、新しい接続の最大アイドルタイムアウトを調整できます。
Application data exchanged on streams or in datagrams defers the QUIC idle timeout. Applications that provide their own keep-alive mechanisms will therefore keep a QUIC connection alive. Applications that do not provide their own keep-alive can use transport-layer mechanisms (see Section 10.1.2 of [QUIC] and Section 3.2). However, QUIC implementation interfaces for controlling such transport behavior can vary, affecting the robustness of such approaches.
ストリームまたはデータグラムで交換されるアプリケーションデータは、QUICアイドルタイムアウトを廃止します。したがって、独自のキープアライブメカニズムを提供するアプリケーションは、QUIC接続を生かし続けます。独自のKeep-Aliveを提供しないアプリケーションは、輸送層メカニズムを使用できます（[QUIC]のセクション10.1.2およびセクション3.2を参照）。ただし、このような輸送挙動を制御するためのQUIC実装インターフェイスはさまざまであり、そのようなアプローチの堅牢性に影響します。
An immediate close is signaled by a CONNECTION_CLOSE frame (see Section 6). Immediate close causes all streams to become immediately closed, which may affect applications; see Section 4.5.
すぐに閉じることは、Connection_Closeフレームによって通知されます（セクション6を参照）。すぐに近いため、すべてのストリームがすぐに閉じられ、アプリケーションに影響を与える可能性があります。セクション4.5を参照してください。
A stateless reset is an option of last resort for an endpoint that does not have access to connection state. Receiving a stateless reset is an indication of an unrecoverable error distinct from connection errors in that there is no application-layer information provided.
ステートレスリセットは、接続状態にアクセスできないエンドポイントの最後の手段のオプションです。ステートレスリセットを受信することは、アプリケーションレイヤー情報が提供されていないという点で、接続エラーとは異なる回復不可能なエラーを示しています。
QUIC exposes some information to the network in the unencrypted part of the header either before the encryption context is established or because the information is intended to be used by the network. For more information on manageability of QUIC, see [QUIC-MANAGEABILITY]. QUIC has a long header that exposes some additional information (the version and the source connection ID), while the short header exposes only the destination connection ID. In QUIC version 1, the long header is used during connection establishment, while the short header is used for data transmission in an established connection.
QUICは、暗号化コンテキストが確立される前、またはネットワークで使用されることを意図しているため、ヘッダーの非暗号化されていない部分のネットワークにいくつかの情報を公開します。QUICの管理可能性の詳細については、[quic-manageability]を参照してください。QUICには、いくつかの追加情報（バージョンとソース接続ID）を公開する長いヘッダーがあり、短いヘッダーは宛先接続IDのみを公開します。QUICバージョン1では、接続確立中に長いヘッダーが使用され、短いヘッダーは確立された接続でのデータ送信に使用されます。
The connection ID can be zero length. Zero-length connection IDs can be chosen on each endpoint individually and on any packet except the first packets sent by clients during connection establishment.
接続IDは長さがゼロになる場合があります。ゼロレングス接続IDは、接続確立中にクライアントから送信された最初のパケットを除く各エンドポイントとパケットで個別に選択できます。
An endpoint that selects a zero-length connection ID will receive packets with a zero-length destination connection ID. The endpoint needs to use other information, such as the source and destination IP address and port number to identify which connection is referred to. This could mean that the endpoint is unable to match datagrams to connections successfully if these values change, making the connection effectively unable to survive NAT rebinding or migrate to a new path.
ゼロ長接続IDを選択するエンドポイントは、ゼロ長宛先接続IDを持つパケットを受信します。エンドポイントは、ソースや宛先IPアドレスやポート番号など、他の情報を使用して、どの接続が参照されているかを特定する必要があります。これは、これらの値が変更された場合、エンドポイントがデータグラムを接続に正常に一致させることができないことを意味し、接続がNATのリベンディングを実質的に生き残るか、新しいパスに移行できないことを意味します。
QUIC supports a server-generated connection ID that is transmitted to the client during connection establishment (see Section 7.2 of [QUIC]). Servers behind load balancers may need to change the connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support stateless load balancing.
QUICは、接続確立中にクライアントに送信されるサーバー生成接続IDをサポートします（[QUIC]のセクション7.2を参照）。ロードバランサーの背後にあるサーバーは、ハンドシェイク中に接続IDを変更する必要がある場合があります。つまり、ステートレスロードバランシングをサポートするために、サーバーのIDまたはその負荷分散プールに関する情報をエンコードする必要があります。
Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently routes packets to the server instance that has the connection state, even if addresses, ports, or connection IDs change. This might require coordination between servers and infrastructure. One method of achieving this involves encoding routing information into the connection ID. For an example of this technique, see [QUIC-LB].
ロードバランサーやその他のルーティングインフラストラクチャを使用したサーバーの展開では、このインフラストラクチャが、アドレス、ポート、または接続IDが変更された場合でも、接続状態を持つサーバーインスタンスにパケットを一貫してルーティングすることを確認する必要があります。これには、サーバーとインフラストラクチャ間の調整が必要になる場合があります。これを達成する1つの方法には、ルーティング情報を接続IDにエンコードすることが含まれます。この手法の例については、[quic-lb]を参照してください。
If QUIC endpoints do not issue fresh connection IDs, then clients cannot reduce the linkability of address migration by using them. Choosing values that are unlinkable to an outside observer ensures that activity on different paths cannot be trivially correlated using the connection ID.
QUICエンドポイントが新鮮な接続IDを発行しない場合、クライアントはアドレス移行のリンク可能性を使用して低下させることはできません。外部オブザーバーにリンクできない値を選択すると、接続IDを使用して異なるパスでのアクティビティを簡単に相関させることができないことが保証されます。
While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of 6-tuples (source and destination addresses as well as the migrated Connection ID) may expose these links anyway.
十分に堅牢な接続ID生成スキームは、リンク可能性の問題を軽減しますが、完全な保護は提供されません。6タプルの寿命（ソースおよび宛先アドレス、および移行された接続ID）の分析は、とにかくこれらのリンクを公開する可能性があります。
In the case where connection migration in a server pool is rare, it is trivial for an observer to associate two connection IDs. Conversely, where every server handles multiple simultaneous migrations, even an exposed server mapping may be insufficient information.
サーバープールでの接続移行がまれな場合、オブザーバーが2つの接続IDを関連付けることは些細なことです。逆に、すべてのサーバーが複数の同時移行を処理する場合、露出したサーバーマッピングでさえ情報が不十分な場合があります。
The most efficient mitigations for these attacks are through network design and/or operational practices, by using a load-balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations in an attempt to increase the number of simultaneous migrations at a given time, or by using other means.
これらの攻撃の最も効率的な緩和は、ネットワーク設計および/または運用プラクティスを通じて、単一のサーバー側のアドレスにフローをロードする負荷バランスアーキテクチャを使用し、移行のタイミングを調整することにより、移動のタイミングを調整することにより、特定の時間における同時移動、または他の手段を使用することにより。
QUIC provides a Retry packet that can be sent by a server in response to the client Initial packet. The server may choose a new connection ID in that packet, and the client will retry by sending another client Initial packet with the server-selected connection ID. This mechanism can be used to redirect a connection to a different server, e.g., due to performance reasons or when servers in a server pool are upgraded gradually and therefore may support different versions of QUIC.
QUICは、クライアントの初期パケットに応じてサーバーによって送信できる再試行パケットを提供します。サーバーは、そのパケットで新しい接続IDを選択する場合があり、クライアントは、サーバー選択の接続IDを使用して別のクライアントの初期パケットを送信することで再試行します。このメカニズムを使用して、パフォーマンスの理由により、またはサーバープールのサーバーが徐々にアップグレードされるため、さまざまなバージョンのQUICをサポートする可能性があるため、別のサーバーへの接続をリダイレクトできます。
In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load balancers that forward the traffic based on the connection ID. A server can choose the connection ID in the Retry packet such that the load balancer will redirect the next Initial packet to a different server in that pool. Alternatively, the load balancer can directly offer a Retry offload as further described in [QUIC-RETRY].
この場合、特定のプールに属するすべてのサーバーが、接続IDに基づいてトラフィックを転送するロードバランサーと協力して提供されると想定されています。サーバーは、[再[再生]パケットの接続IDを選択して、ロードバランサーが次の初期パケットをそのプールの別のサーバーにリダイレクトするようにすることができます。あるいは、[quic-retry]でさらに説明されているように、ロードバランサーは直接再試行を提供できます。
The approach described in Section 4 of [RFC5077] for constructing TLS resumption tickets provides an example that can be also applied to validation tokens. However, the use of more modern cryptographic algorithms is highly recommended.
TLS再開チケットを構築するための[RFC5077]のセクション4で説明されているアプローチは、検証トークンにも適用できる例を提供します。ただし、より最新の暗号化アルゴリズムの使用を強くお勧めします。
QUIC, as defined in [QUIC], has a single congestion controller and recovery handler. This design assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, that have the same Diffserv Code Point (DSCP) [RFC2475] will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion controller. Therefore, packets belonging to the same connection should use a single DSCP. Section 5.1 of [RFC7657] provides a discussion of Diffserv interactions with datagram transport protocols [RFC7657] (in this respect, the interactions with QUIC resemble those of Stream Control Transmission Protocol (SCTP)).
[QUIC]で定義されているQUICには、単一の混雑コントローラーと回復ハンドラーがあります。この設計では、QUIC接続のすべてのパケット、または少なくとも同じ5タプル{Dest Addr、Source Addr、Protocol、Dest Port、Source Port}が同じであることを前提としています。各パケットの損失または遅延に関するフィードバックは、混雑コントローラーへの入力として使用されるため、同様のネットワーク処理を受けます。したがって、同じ接続に属するパケットは、単一のDSCPを使用する必要があります。[RFC7657]のセクション5.1は、データグラムトランスポートプロトコル[RFC7657]との拡散的な相互作用の議論を示しています（この点で、QUICとの相互作用は、ストリーム制御伝送プロトコル（SCTP）の相互作用に似ています）。
When multiplexing multiple flows over a single QUIC connection, the selected DSCP value should be the one associated with the highest priority requested for all multiplexed flows.
単一のQUIC接続で複数のフローを多重化する場合、選択したDSCP値は、すべての多重化されたフローに対してリクエストされた最高の優先度に関連するものである必要があります。
If differential network treatment is desired, e.g., by the use of different DSCPs, multiple QUIC connections to the same server may be used. In general, it is recommended to minimize the number of QUIC connections to the same server to avoid increased overhead and, more importantly, competing congestion control.
異なるDSCPを使用することにより、微分ネットワーク処理が必要な場合は、同じサーバーへの複数のQUIC接続を使用できます。一般に、オーバーヘッドの増加、さらに重要なことに競合する混雑制御を避けるために、同じサーバーへのQUIC接続の数を最小限に抑えることをお勧めします。
As in other uses of Diffserv, when a packet enters a network segment that does not support the DSCP value, this could result in the connection not receiving the network treatment it expects. The DSCP value in this packet could also be remarked as the packet travels along the network path, changing the requested treatment.
diffservの他の使用法と同様に、パケットがDSCP値をサポートしないネットワークセグメントに入ると、これにより、接続が予想されるネットワーク処理を受信しない可能性があります。このパケットのDSCP値は、パケットがネットワークパスに沿って移動し、要求されたトリートメントを変更するときにも声を出すことができます。
Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher version number will not necessarily provide a better service but might simply provide a different feature set. As such, an application needs to be able to select which versions of QUIC it wants to use.
QUICでのバージョン化は、不変であると宣言されたいくつかのヘッダーフィールドの意味を除いて、プロトコルの動作を完全に変更する可能性があります[quic-invariants]。バージョン番号が高いQUICのバージョンは、必ずしもより良いサービスを提供するわけではありませんが、単に異なる機能セットを提供する可能性があります。そのため、アプリケーションは、使用するQUICのバージョンを選択できる必要があります。
A new version could use an encryption scheme other than TLS 1.3 or higher. [QUIC] specifies requirements for the cryptographic handshake as currently realized by TLS 1.3 and described in a separate specification [QUIC-TLS]. This split is performed to enable lightweight versioning with different cryptographic handshakes.
新しいバージョンでは、TLS 1.3以外の暗号化スキームを使用できます。[QUIC] TLS 1.3で現在実現されており、別の仕様[QUIC-TLS]で説明されているように、暗号化の握手の要件を指定します。この分割は、異なる暗号化の握手で軽量バージョンを有効にするために実行されます。
The "QUIC Versions" registry established in [QUIC] allows for provisional registrations for experimentation. Registration, also of experimental versions, is important to avoid collision. Experimental versions should not be used long-term or registered as permanent to minimize the risk of fingerprinting based on the version number.
[QUIC]で確立された「QUICバージョン」レジストリは、実験のための暫定的な登録を可能にします。また、実験バージョンの登録は、衝突を避けるために重要です。実験バージョンは、バージョン番号に基づいてフィンガープリントのリスクを最小限に抑えるために、長期的に使用したり、永久として登録したりしないでください。
QUIC version 1 does not specify a version negotiation mechanism in the base specification, but [QUIC-VERSION-NEGOTIATION] proposes an extension that provides compatible version negotiation.
QUICバージョン1は、ベース仕様のバージョンネゴシエーションメカニズムを指定するのではなく、[QUIC-version-negotiation]は、互換性のあるバージョンネゴシエーションを提供する拡張機能を提案します。
This approach uses a three-stage deployment mechanism, enabling progressive rollout and experimentation with multiple versions across a large server deployment. In this approach, all servers in the deployment must accept connections using a new version (stage 1) before any server advertises it (stage 2), and authentication of the new version (stage 3) only proceeds after advertising of that version is completely deployed.
このアプローチでは、3段階の展開メカニズムを使用して、大規模なサーバー展開全体でプログレッシブロールアウトと複数のバージョンを実験します。このアプローチでは、展開内のすべてのサーバーは、サーバーがそれを宣伝する前に新しいバージョン（ステージ1）を使用して接続を受け入れる必要があり、新しいバージョンの認証（ステージ3）は、そのバージョンの広告が完全に展開された後にのみ進行します。
See Section 5 of [QUIC-VERSION-NEGOTIATION] for details.
詳細については、[quic-version-negotiation]のセクション5を参照してください。
[RFC9221] specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC. Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per [RFC8085], as QUIC datagrams are congestion controlled.
[RFC9221]は、QUICを介して信頼できないデータグラムを送信および受信できるようにするためのQUIC拡張機能を指定します。UDPを介して直接動作するのとは異なり、QUICデータグラムがQUICデータグラムが混雑制御されているため、QUICデータグラムサービスを使用するアプリケーションは独自の混雑制御を実装する必要はありません。
QUIC datagrams are not flow controlled, and as such data chunks may be dropped if the receiver is overloaded. While the reliable transmission service of QUIC provides a stream-based interface to send and receive data in order over multiple QUIC streams, the datagram service has an unordered message-based interface. If needed, an application-layer framing can be used on top to allow separate flows of unreliable datagrams to be multiplexed on one QUIC connection.
QUICデータグラムはフロー制御されておらず、そのようなデータとして、受信機が過負荷になった場合、チャンクが削除される可能性があります。QUICの信頼できる送信サービスは、複数のQUICストリームを順番に送信および受信するためのストリームベースのインターフェイスを提供しますが、Datagramサービスには順序付けられていないメッセージベースのインターフェイスがあります。必要に応じて、アプリケーション層フレーミングを上に使用して、信頼性の低いデータグラムの個別のフローを1つのQUIC接続で多重化することができます。
This document has no actions for IANA; however, note that Section 8 recommends that an application that has already registered a TCP port but wants to specify QUIC as a transport should register a UDP port analogous to their existing TCP registration.
このドキュメントには、IANAに対するアクションはありません。ただし、セクション8では、既にTCPポートを登録しているが、輸送が既存のTCP登録に類似したUDPポートを登録するためにQUICを指定したいアプリケーションを推奨していることに注意してください。
See the security considerations in [QUIC] and [QUIC-TLS]; the security considerations for the underlying transport protocol are relevant for applications using QUIC. Considerations on linkability, replay attacks, and randomness discussed in [QUIC-TLS] should be taken into account when deploying and using QUIC.
[quic]および[quic-tls]のセキュリティ上の考慮事項を参照してください。基礎となる輸送プロトコルのセキュリティ上の考慮事項は、QUICを使用したアプリケーションに関連しています。[QUIC-TLS]で議論されているリンク可能性、リプレイ攻撃、およびランダム性に関する考慮事項は、QUICを展開および使用する際に考慮する必要があります。
Further, migration to a new address exposes a linkage between client addresses to the server and may expose this linkage also to the path if the connection ID cannot be changed or flows can otherwise be correlated. When migration is supported, this needs to be considered with respective to user privacy.
さらに、新しいアドレスへの移行は、クライアントアドレス間のリンクをサーバーに公開し、接続IDを変更できない場合、またはフローを相関させることができない場合、このリンクもパスに公開する場合があります。移行がサポートされている場合、これはそれぞれユーザーのプライバシーを考慮する必要があります。
Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee the same security properties as QUIC. If this is not possible, the connection should fail to allow the application to explicitly handle fallback to a less-secure alternative. See Section 2.
アプリケーション開発者は、UDPのネットワークブロッキングのためにQUICを使用できない場合に使用するフォールバックは、QUICと同じセキュリティプロパティを保証する必要があることに注意する必要があります。これが不可能な場合、接続により、アプリケーションがあまり安全でない代替品へのフォールバックを明示的に処理できるようにすることができないはずです。セクション2を参照してください。
Further, [QUIC-HTTP] provides security considerations specific to HTTP. However, discussions such as on cross-protocol attacks, traffic analysis and padding, or migration might be relevant for other applications using QUIC as well.
さらに、[quic-http]は、HTTPに固有のセキュリティ上の考慮事項を提供します。ただし、クロスプロトコル攻撃、トラフィック分析、パディング、または移行などの議論は、QUICを使用した他のアプリケーションにも関連する可能性があります。
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[Quic] Iyengar、J.、ed。and M. Thomson、ed。、「Quic：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487/RFC9000、2021年5月、<https://www.rfc-editor.org/info/rfc9000>
[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-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]トムソン、M。、編and S. Turner、ed。、「TLSを使用してQUICを確保する」、RFC 9001、DOI 10.17487/RFC9001、2021年5月、<https://www.rfc-editor.org/info/rfc9001>。
[Edeline16] Edeline, K., Kühlewind, M., Trammell, B., Aben, E., and B. Donnet, "Using UDP for Internet Transport Evolution", DOI 10.48550/arXiv.1612.07816, 22 December 2016, <https://arxiv.org/abs/1612.07816>.
[Edeline16] Edeline、K.、Kühlewind、M.、Trammell、B.、Aben、E.、およびB. Donnet、「インターネット輸送の進化にUDPを使用」、DOI 10.48550/arxiv.1612.07816、2016 12月22日、<https：//arxiv.org/abs/1612.07816>。
[Hatonen10] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and M. Kojo, "An Experimental Study of Home Gateway Characteristics", Proc. ACM IMC 2010, November 2010, <https://conferences.sigcomm.org/imc/2010/papers/ p260.pdf>.
[Hatonen10]Hätönen、S.、Nyrhinen、A.、Eggert、L.、Strowes、S.、Sarolahti、P。、およびM. Kojo、「ホームゲートウェイ特性の実験的研究」、Proc。ACM IMC 2010、2010年11月、<https://conferences.sigcomm.org/imc/2010/papers/ p260.pdf>。
[HTTP-REPLAY] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.
[HTTP-Replay] Thomson、M.、Nottingham、M.、およびW. Tarreau、「HTTPでの初期データの使用」、RFC 8470、DOI 10.17487/RFC8470、2018年9月、<https：//www.rfc-edtuter。org/info/rfc8470>。
[PaaschNanog] Paasch, C., "Network support for TCP Fast Open", NANOG 67 Presentation, 13 June 2016, <https://www.nanog.org/sites/default/files/ Paasch_Network_Support.pdf>.
[Paaschnanog] Paasch、C。、「TCP Fast Openのネットワークサポート」、Nanog 67プレゼンテーション、2016年6月13日、<https://www.nanog.org/sites/default/files/ paasch_network_support.pdf>。
[QUIC-ACK-FREQUENCY] Iyengar, J. and I. Swett, "QUIC Acknowledgement Frequency", Work in Progress, Internet-Draft, draft-ietf-quic-ack-frequency-02, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-02>.
[quic-ack-frequency] iyengar、J。and I. swett、「quic承認頻度」、作業中の作業、インターネットドラフト、ドラフト-iitf-quic-frequency-02、2022年7月11日、<https：//datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-02>。
[QUIC-HTTP] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[Quic-http] Bishop、M.、ed。、 "http/3"、RFC 9114、doi 10.17487/rfc9114、2022年6月、<https://www.rfc-editor.org/info/rfc9114>。
[QUIC-LB] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating Routable QUIC Connection IDs", Work in Progress, Internet-Draft, draft-ietf-quic-load-balancers-14, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers-14>.
[Quic-LB] Duke、M.、Banks、N.、およびC. Huitema、「Quic-LB：Routable Quic Connection IDS」、進行中の作業、インターネットドラフト、ドラフト-ITF-Quic-load-balancers-14、2022年7月11日、<https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers-14>。
[QUIC-MANAGEABILITY] Kühlewind, M. and B. Trammell, "Manageability of the QUIC Transport Protocol", RFC 9312, DOI 10.17487/RFC9312, September 2022, <https://www.rfc-editor.org/info/rfc9312>.
[Quic-Manageability]Kühlewind、M。and B. Trammell、「Quic Transport Protocolの管理可能性」、RFC 9312、DOI 10.17487/RFC9312、2022年9月、<https://www.rfc-editor.org/info/rfc9312>。
[QUIC-RETRY] Duke, M. and N. Banks, "QUIC Retry Offload", Work in Progress, Internet-Draft, draft-ietf-quic-retry-offload-00, 25 May 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-quic-retry-offload-00>.
[Quic-Retry] Duke、M。and N. Banks、「Quic Retry offload」、Work in Progress、Internet-Draft、Draft-Itic-Quic-retry-Offload-00、25 5月25日、<https：// datatracker.ietf.org/doc/html/draft-yietf-quic-retry-offload-00>。
[QUIC-VERSION-NEGOTIATION] Schinazi, D. and E. Rescorla, "Compatible Version Negotiation for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-version-negotiation-10, 27 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-version-negotiation-10>.
[Quic-version-negotiation] Schinazi、D。and E. Rescorla、「互換性のあるquicの交渉」、進行中の作業、インターネットドラフト、ドラフト-ITIC-QUIC-version-negotiation-10、2022年9月27日、<https：//datatracker.ietf.org/doc/html/draft-ietf-quic-version-negotiation-10>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、DOI 10.17487/RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、DOI 10.17487/RFC2475、12月1998、<https://www.rfc-editor.org/info/rfc2475>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「サーバー側の状態なしの輸送層セキュリティ（TLS）セッション再開」、RFC 5077、DOI 10.17487/RFC5077、2008年1月<https://www.rfc-editor.org/info/rfc5077>。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>.
[RFC5382] Guha、S.、Ed。、Biswas、K.、Ford、B.、Sivakumar、S.、およびP. Srisuresh、「TCPのNat行動要件」、BCP 142、RFC 5382、DOI 10.17487/RFC5382、2008年10月、<https://www.rfc-editor.org/info/rfc5382>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様」、RFC 5905、DOI 10.17487/RFC5905、2010年6月、<https://www.rfc-editor.org/info/rfc5905>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335] Cotton、M.、Eggert、L.、Touch、J.、Westerlund、M。、およびS. Cheshire、「インターネット割り当て番号局（IANA）手順サービス名と輸送プロトコルポート番号レジストリの管理のための手順"、BCP 165、RFC 6335、DOI 10.17487/RFC6335、2011年8月、<https://www.rfc-editor.org/info/rfc635>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S。およびM. Krochmal、「Multicast DNS」、RFC 6762、DOI 10.17487/RFC6762、2013年2月、<https://www.rfc-editor.org/info/rfc6762>
[RFC7301] 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>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「輸送層セキュリティ（TLS）アプリケーション層プロトコル交渉拡張」、RFC 7301、DOI 10.17487/RFC7301、2014年7月、<https://www.rfc-editor.org/info/rfc7301>。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S.、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487/RFC7413、2014年12月、<https：//www.rfc-editor.org/info/rfc7413>。
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.
[RFC7657] Black、D.、ed。およびP.ジョーンズ、「差別化されたサービス（DIFFSERV）およびリアルタイム通信」、RFC 7657、DOI 10.17487/RFC7657、2015年11月、<https://www.rfc-editor.org/info/rfc7657>。
[RFC7838] 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>.
[RFC7838]ノッティンガム、M.、McManus、P。、およびJ. Reschke、「HTTP代替サービス」、RFC 7838、DOI 10.17487/RFC7838、2016年4月、<https://www.rfc-editor.org/info/RFC7838>。
[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>。
[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、2月2021年、<https：/<https：/<https：//www.rfc-editor.org/info/rfc8981>。
[RFC9218] Oku, K. and L. Pardue, "Extensible Prioritization Scheme for HTTP", RFC 9218, DOI 10.17487/RFC9218, June 2022, <https://www.rfc-editor.org/info/rfc9218>.
[RFC9218] Oku、K。およびL. Pardue、「HTTPの拡張可能な優先順位付けスキーム」、RFC 9218、DOI 10.17487/RFC9218、2022年6月、<https://www.rfc-editor.org/info/rfc9218>
[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022, <https://www.rfc-editor.org/info/rfc9221>.
[RFC9221] Pauly、T.、Kinnear、E。、およびD. Schinazi、「QUICへの信頼できないデータグラム拡張」、RFC 9221、DOI 10.17487/RFC9221、2022年3月、<https：//www.rfc-ed.org/info/rfc9221>。
[SSDP] Donoho, A., Roe, B., Bodlaender, M., Gildred, J., Messer, A., Kim, Y., Fairman, B., and J. Tourzan, "UPnP Device Architecture 2.0", 17 April 2020, <https://openconnectivity.org/upnp-specs/UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf>.
[SSDP] Donoho、A.、Roe、B.、Bodlaender、M.、Gildred、J.、Messer、A.、Kim、Y.、Fairman、B。、およびJ. Tourzan、 "UPNPデバイスアーキテクチャ2.0"、2020年4月17日、<https://openconnectivity.org/upnp-specs/upnp-arch-devicearchitecture-v2.0-20200417.pdf>。
[Swett16] Swett, I., "QUIC Deployment Experience @Google", IETF96 QUIC BoF Presentation, 20 July 2016, <https://www.ietf.org/proceedings/96/slides/slides-96- quic-3.pdf>.
[Swett16] Swett、I。、「Quic Deployment Experience @Google」、IETF96 QUIC BOFプレゼンテーション、2016年7月20日、<https://www.ietf.org/proceedings/96/slides/slides-96- quic-3。pdf>。
[TAPS-ARCH] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and C. Perkins, "An Architecture for Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-arch-14, 27 September 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-taps-arch-14>.
[Taps-arch] Pauly、T.、Trammell、B.、Brunstrom、A.、Fairhurst、G。、およびC. Perkins、「輸送サービスのアーキテクチャ」、進行中の作業、インターネットドラフト、Draft-Itf-TAPS-arch-14、2022年9月27日、<https://datatracker.ietf.org/doc/html/ draft-ietf-taps-arch-14>。
[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/rfc846>
[Trammell16] Trammell, B. and M. Kühlewind, "Internet Path Transparency Measurements using RIPE Atlas", RIPE 72 MAT Presentation, 25 May 2016, <https://ripe72.ripe.net/wp-content/uploads/ presentations/86-atlas-udpdiff.pdf>.
[Trammell16] Trammell、B。およびM.Kühlewind、「Ripe Atlasを使用したインターネットパス透明性測定」、RIPE 72 MATプレゼンテーション、2016年5月25日、<https://ripe72.ripe.net/wp-content/uploads/ presentations/86-Atlas-udpdiff.pdf>。
Acknowledgments
謝辞
Special thanks to Last Call reviewers Chris Lonvick and Ines Robles.
最後のコールレビュアーChris LonvickとInes Roblesに感謝します。
This work was partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI) and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement.
この作業は、Horizon 2020 Grant契約の下で欧州委員会によって部分的にサポートされていました。688421ミドルボックス化されたインターネット（MAMI）および契約書に基づく教育、研究、イノベーションのためのスイス州事務局による測定とアーキテクチャ。15.0268。このサポートは、承認を意味するものではありません。
Contributors
貢献者
The following people have contributed significant text to or feedback on this document:
次の人々は、このドキュメントに重要なテキストまたはフィードバックを提供しました。
Gorry Fairhurst
ゴリーフェアハースト
Ian Swett
イアン・スウェット
Igor Lubashev
Igor Lubashev
Lucas Pardue
ルーカス・パルド
Mike Bishop
マイク・ビショップ
Mark Nottingham
マーク・ノッティンガム
Martin Duke
マーティンデューク
Martin Thomson
マーティン・トムソン
Sean Turner
ショーン・ターナー
Tommy Pauly
トミーポーリー
Authors' Addresses
著者のアドレス
Mirja Kühlewind Ericsson Email: mirja.kuehlewind@ericsson.com
MirjaKühlewindEricssonメール：mirja.kuehlewind@ericsson.com
Brian Trammell Google Switzerland GmbH Gustav-Gull-Platz 1 CH-8004 Zurich Switzerland Email: ietf@trammell.ch
Brian Trammell Google Switzerland GmbH Gustav-Gull-Platz 1 CH-8004 Zurich Switzerlandメール：ietf@trammell.ch