メインコンテンツまでスキップ

RFC 9308 - QUIC トランスポートプロトコルの適用性 (Applicability of the QUIC Transport Protocol)

  • ステータス: Informational
  • 発行日: September 2022
  • ストリーム: IETF
  • エラッタ: エラッタなし

概要 (Abstract)​

本文書は QUIC トランスポートプロトコルの適用性について論じ、QUIC 上でのアプリケーションプロトコルの開発と展開に影響する注意点に焦点を当てる。想定読者は、アプリケーションプロトコルを QUIC にマッピングする設計者、およびそれらのアプリケーションプロトコルの実装者である。

本メモの状態 (Status of This Memo)​

本文書は Internet Standards Track の仕様ではない。情報提供の目的で公開される。

本文書は Internet Engineering Task Force (IETF) の成果物である。IETF コミュニティの合意を表す。公開レビューを受け、Internet Engineering Steering Group (IESG) により公開が承認されている。IESG が承認したすべての文書が何らかのレベルの Internet Standard の候補であるわけではない。RFC 7841 の第 2 節を参照。

本文書の現在の状態、エラッタ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9308 で得られる。

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

本文書は BCP 78 および IETF 文書に関する IETF Trust の法的規定 (https://trustee.ietf.org/license-info) のうち、本文書の発行日に有効なものに従う。本文書に関する権利と制限が記載されているため、これらの文書を注意深く確認すること。本文書から抽出されたコードコンポーネントには、Trust Legal Provisions の第 4.e 節に記載の Revised BSD License の文言を含めなければならず、Revised BSD License に記載のとおり無保証で提供される。

目次 (Table of Contents)​

  1. はじめに
  2. フォールバックの必要性
  3. 0-RTT
  4. ストリームの利用
  5. パケット化とレイテンシ
  6. エラー処理
  7. 確認応答の効率
  8. ポート選択とアプリケーションエンドポイントの発見
  9. 接続マイグレーション
  10. 接続の終了
  11. 情報の露出と接続 ID
  12. QoS と DSCP
  13. バージョンと暗号ハンドシェイクの利用
  14. 新バージョンの展開の有効化
  15. QUIC 上の非信頼データグラムサービス
  16. IANA の考慮事項
  17. セキュリティの考慮事項
  18. 参考文献

1. はじめに (Introduction)​

QUIC [QUIC] は多数の高度な機能を提供する新しいトランスポートプロトコルである。当初は HTTP のユースケース向けに設計されたが、はるかに広い種類のアプリケーションで利用できる能力を提供する。QUIC は UDP にカプセル化される。QUIC バージョン 1 は TLS 1.3 [TLS13] を統合し、すべてのペイロードデータと大部分の制御情報を暗号化する。QUIC を使用する HTTP のバージョンは HTTP/3 [QUIC-HTTP] として知られる。

本文書は、QUIC プロトコルを自ら実装することなく利用したいアプリケーション開発者向けの指針を提供する。これには、HTTP/3 上で動作するアプリケーション、および QUIC 上で直接動作するアプリケーションに対する一般的な指針が含まれる。

以降の節では、QUIC の適用性に関する具体的な注意点と、アプリケーションのトランスポートとして QUIC を使用する際にアプリケーション開発者が考慮しなければならない問題を論じる。

2. フォールバックの必要性 (The Necessity of Fallback)​

QUIC は UDP を基盤として使用する。これによりユーザ空間での実装が可能となり、既存のネットワークインフラの更新を必要とせずに、ネットワーク中間箱 (NAT を含む) の通過が可能となる。

測定研究によれば、約 3% [Trammell16] から 5% [Swett16] のネットワークがすべての UDP トラフィックを遮断している。ただし、UDP トラフィックが TCP と比べて他の形態で体系的に不利であるという証拠はほとんどない [Edeline16]。この遮断は、QUIC 上で動作するすべてのアプリケーションが、そのようなネットワーク上での接続失敗を受け入れる準備をするか、何らかの他のトランスポートプロトコルへのフォールバックを設計する必要があることを意味する。HTTP の場合、このフォールバックは TLS over TCP である。

IETF トランスポートサービス (TAPS) 仕様 [TAPS-ARCH] は、複数プロトコル向けの共通 API を持つシステムを記述する。これは複数プロトコル間のフォールバックの影響を扱うため、QUIC に特に関連する。

具体的には、不安全なプロトコルや、より弱いバージョンの安全プロトコルへのフォールバックは避ける必要がある。一般に、フォールバックを実装するアプリケーションはセキュリティ上の結果を考慮する必要がある。TCP と TLS へのフォールバックは、制御情報をネットワーク内での改変と操作にさらす。さらに、QUIC バージョン 1 で使用される TLS 1.3 より古い TLS バージョンへのダウングレードは、著しく弱い暗号保護をもたらす可能性がある。例えば、プロトコル交渉 [RFC7301] の結果は、TLS 1.3 が使用される場合にのみ機密性保護を持つ。

これらのアプリケーションは、フォールバックプロトコルに存在しない QUIC が提供する機能がない状態でも、機能が損なわれた状態でも動作できなければならない。TLS over TCP へのフォールバックでは、最も明白な違いは TCP がストリーム多重化を提供しないことであり、したがって必要であればストリーム多重化をアプリケーション層で実装する必要がある。さらに、TCP 実装とネットワークパスはしばしば TCP Fast Open (TFO) オプション [RFC7413] をサポートせず、これは新しい接続の最初の制御パケットとともにペイロードデータを送信できるようにするもので、QUIC の 0-RTT セッション再開でも提供される。TFO が正常に交渉された場合でも、中間箱が SYN データを遮断する証拠があることに注意 ( [PaaschNanog] を参照)。そして Fast Open がエンドツーエンドで正常に動作する場合でも、TLS ハンドシェイクとアプリケーションデータの単一パケットに限られ、QUIC 0-RTT とは異なる。

さらに、暗号化 (この場合 TLS) は QUIC と不可分に統合されている一方、TCP 上の TLS 交渉は遮断され得る。TLS over TCP をサポートできない場合、接続は中止すべきであり、アプリケーションは安全な通信が利用できないことを示す適切なプロンプトをユーザに提示するのが望ましい。

要約すると、いかなるフォールバック機構も性能の低下を課し、セキュリティを低下させ得る。しかし、フォールバックはアプリケーションのペイロードデータの機密性または完全性に関する期待を静かに侵害してはならない。

3. 0-RTT​

QUIC は 0-RTT 接続確立を提供する。同じ機能は TCP 上の TLS 1.3 にも存在するが、0-RTT は QUIC を使用するアプリケーションに機会と課題の両方をもたらす。

0-RTT 接続確立を提供するトランスポートプロトコルは、アプリケーションの観点からは 0-RTT を提供しないプロトコルと質的に異なる。接続を閉じて再度開くコストと、接続を開いたまま保つ試みの間の相対的なトレードオフは異なる。第 3.2 節を参照。

アプリケーションは 0-RTT を意図的に選択して使用する必要がある。なぜなら 0-RTT はリプレイ攻撃のリスクを伴うからである。0-RTT を使用するアプリケーションプロトコルは、安全に送信できる情報の種類を記述するプロファイルを必要とする。HTTP については、このプロファイルは [HTTP-REPLAY] に記述されている。

3.1. リプレイ攻撃 (Replay Attacks)​

0-RTT パケットに含まれるデータの再送または悪意あるリプレイは、サーバ側が同じデータの複数のコピーを受信する原因となり得る。

クライアントが 0-RTT パケットで送信したアプリケーションデータは、リプレイされると複数回処理され得る。アプリケーションは 0-RTT で何を安全に送信できるかを認識する必要がある。0-RTT の利用を可能にしようとするアプリケーションプロトコルは、0-RTT で何を送信できるかの慎重な分析と記述を必要とする。[QUIC-TLS] の第 5.6 節を参照。

場合によっては、0-RTT で送信するアプリケーションデータを、サーバで持続的な効果を持つアクションを引き起こさないデータに制限すれば十分かもしれない。データ取得の開始や設定の確立は、安全であり得るアクションの例である。冪等操作—反復が単一操作と同じ正味の効果を持つもの—は安全かもしれない。しかし、個別には冪等な操作を組み合わせて非冪等な操作列にすることも可能である。

サーバが 0-RTT データを受け入れると、受信したデータを選択的に破棄する手段はない。しかし、プロトコルはリプレイされた場合に不安全かもしれない個々のアクションを拒否する方法を定義できる。

一部の TLS 実装と展開は、部分的または完全なリプレイ保護を提供でき、それをリプレイリスクの管理に利用できる場合がある。

3.2. セッション再開とキープアライブ (Session Resumption versus Keep-Alive)​

QUIC は UDP にカプセル化されるため、QUIC を使用するアプリケーションは短いネットワークアイドルタイムアウトに対処しなければならない。展開済みのステートフルな中間箱は、一般に送信された最初のパケットで UDP フローの状態を確立し、TCP よりもはるかに短いアイドル期間だけ状態を保持する。[RFC5382] は TCP のアイドル期間を少なくとも 124 分と提案しているが、文献においてこの指針が広く実装されている証拠はない。しかし、UDP の短いネットワークタイムアウトは十分に文書化されている。2010 年の研究 ([Hatonen10]) によれば、UDP アプリケーションは、任意の NAT バインディングや他の状態エントリがわずか 30 秒の非活動後に期限切れになり得ると仮定できる。[RFC8085] の第 3.5 節は UDP のキープアライブ間隔をさらに論じる。最小値 15 秒を要求するが、より大きな値、またはキープアライブを完全に省略することを推奨する。

接続 ID を使用することで、QUIC はタイムアウト後の NAT リバインディングに対して堅牢になるよう設計されている。しかし、これは一方のエンドポイントがピアが使用するアドレスで可用性を維持し、タイムアウト発生後に送信する側がピアである場合にのみ役立つ。

一部の QUIC 接続は NAT リバインディングに対して堅牢でない場合がある。なぜならルーティングインフラ (特にロードバランサ) がアドレス/ポートの 4 タプルを使用してトラフィックを誘導するからである。さらに、アドレス変換以外の機能を持つ中間箱もパスに影響し得る。特に、一部のファイアウォールは、クライアントから送信された対応パケットの最近の状態がないサーバトラフィックを許可しない。

QUIC アプリケーションはアイドル期間を調整してタイムアウトのリスクを管理できる。アイドル期間とネットワークアイドルタイムアウトは、接続アイドルタイムアウトとは異なる。接続アイドルタイムアウトはいずれかのエンドポイントの idle timeout パラメータの最小値として定義される。[QUIC] の第 10.1 節を参照。選択肢は 3 つある。

  • アプリケーション層プロトコルがアイドル期間がないか非常に短い相互作用のみで構成される場合、またはプロトコルの NAT リバインディング耐性が十分な場合は、問題を無視する。
  • 長いアイドル期間がないことを保証する。
  • 長いアイドル期間の後にセッションを再開し、適切な場合は 0-RTT 再開を使用する。

最初の戦略は最も容易だが、特定のアプリケーションにのみ適用される。

QUIC アプリケーションのサーバまたはクライアントは、接続およびパス上の状態がタイムアウトするのを防ぐために、キープアライブとして PING フレームを送信できる。キープアライブの使用に関する推奨はアプリケーション固有であり、主にアプリケーションのレイテンシ要件とメッセージ頻度に依存する。この場合、アプリケーションマッピングは、クライアントとサーバのどちらがアプリケーションを生存させ続ける責任を負うかを指定しなければならない。[Hatonen10] はパス上に NAT がある公衆インターネットでは 30 秒が適切な値かもしれないと示唆するが、展開が NAT リバインディングを一貫して生き延びられる場合、または制御された環境 (例: データセンタ) であることが知られている場合は、ネットワークと計算負荷を下げるために大きな値が好ましい。

長いアイドル期間に 30 秒より頻繁に PING フレームを送信すると、状況によっては過剰な非生産的トラフィックと、電力制約のある (モバイル) デバイスにとって受け入れがたい電力使用につながる場合がある。さらに、30 秒より短いタイムアウトは、仮想マシン (VM) の移行や移動中のカバレッジ損失などの一時的なネットワーク中断の処理を難しくし得る。[RFC8085]、特に第 3.5 節を参照。

あるいは、クライアント (サーバではない) はキープアライブトラフィックを送信する代わりにセッション再開を使用できる。この場合、サーバの idle timeout (idle_timeout トランスポートパラメータから取得可能) より長くアイドルだった接続越しにサーバへデータを送信したいクライアントは、単に再接続できる。可能な場合、この再接続は 0-RTT セッション再開を使用でき、接続の再起動に伴うレイテンシを削減する。もちろん、このアプローチは 0-RTT の使用が安全な場合、およびクライアントが再起動するピアである場合にのみ有効である。

再開とキープアライブの間のトレードオフはアプリケーションごとに評価する必要がある。一般に、アプリケーションは継続的な通信が非常に可能性が高い状況でのみキープアライブを使用すべきである。例えば [QUIC-HTTP] は、リクエストが未処理である場合にのみキープアライブの使用を推奨する。

4. ストリームの利用 (Use of Streams)​

QUIC のストリーム多重化機能により、アプリケーションはストリーム間のヘッドオブラインブロッキングなしに、単一の接続上で複数のストリームを実行できる。ストリームデータはフレーム内で運ばれ、ワイヤ上の 1 つの QUIC パケットは 1 つまたは複数のストリームフレームを運べる。

ストリームは単方向または双方向であり、ストリームはクライアントまたはサーバのいずれかによって開始され得る。単方向ストリームでは、開始者のみがデータを送信できる。

ストリームと接続はそれぞれ、ストリームオフセットと接続フロー制御制限の符号化の制限により、各方向に最大 2^62-1 バイトを運べる。現時点では起こりにくいが、アプリケーションがこの制限に達した場合、新しい接続を確立する必要がある。

ストリームは独立に開閉でき、優雅に、または突然に閉じられる。アプリケーションは STREAM フレームで FIN ビットを送信するよう QUIC に指示することで、ストリームの出力方向を優雅に閉じられる。TCP と同様に、ピアが生成した FIN なしに入力方向を優雅に閉じることはできない。しかし、エンドポイントは出力方向を突然に閉じるか、ピアに入力方向を突然に閉じるよう要求できる。これらの動作は互いに完全に独立である。

QUIC は任意のストリームの例外処理のためのインタフェースを提供しない。アプリケーションにとって重要なストリームが閉じられた場合、アプリケーションはアプリケーション層でエラーメッセージを生成して相手側および/または上位層に通知でき、最終的に QUIC 接続を終了できる。

アプリケーションデータのストリームへのマッピングはアプリケーション固有であり、HTTP/3 については [QUIC-HTTP] に記述されている。アプリケーションのストリーム利用を設計する際に適用する一般原則がいくつかある。

  • 単一のストリームは順序を提供する。アプリケーションが特定のデータを順序どおりに受信することを要求する場合、そのデータは同じストリームで送信すべきである。ストリーム間での送信、受信、または配信の順序の保証はない。
  • 複数のストリームは並行性を提供する。独立に処理でき、したがって順序どおりの受信を強制されるとヘッドオブラインブロッキングに苦しむデータは、別々のストリームで送信すべきである。
  • ストリームはメッセージ指向を提供し、メッセージのキャンセルを可能にし得る。1 つのメッセージが単一のストリームにマッピングされる場合、未確認のメッセージを期限切れにするためにストリームをリセットすることで、そのメッセージの部分的信頼性をエミュレートできる。

QUIC 受信者が許可される最大の同時ストリーム数を開いており、送信者がさらにストリームが必要であることを示す場合、それは自動的に受信者による最大ストリーム数の増加につながるわけではない。したがって、アプリケーションはデータとストリームのマッピングを決定する際に、許可されている最大数、現在開いている数、および現在使用中のストリーム数を考慮すべきである。

QUIC は各ストリームにストリーム ID と呼ばれる数値識別子を割り当てる。これらの識別子とストリーム種別の関係は QUIC バージョン 1 で明確に定義されているが、将来のバージョンは様々な理由でこの関係を変更する可能性がある。QUIC 実装は各ストリームのプロパティ (どのエンドポイントがストリームを開始したか、ストリームが単方向か双方向か、ストリームに使用されるストリーム ID) を公開すべきであり、アプリケーションはストリーム ID から推論しようとするのではなく、これらのプロパティを問い合わせるべきである。

アプリケーションが開いたストリームへのストリーム識別子の割り当て方法は、トランスポート実装間で異なる場合がある。したがって、アプリケーションはまだ割り当てられていないストリームに特定のストリーム ID が割り当てられると仮定すべきではない。例えば、HTTP/3 は既に開かれたストリームを参照するためにストリーム ID を使用するが、将来のストリーム ID やその割り当て方法について仮定しない ([QUIC-HTTP] の第 6 節を参照)。

4.1. ストリーム多重化とフローマルチプレクシング (Stream versus Flow Multiplexing)​

ストリームはアプリケーションにとってのみ意味がある。ストリーム情報は QUIC の暗号化境界の内側で運ばれるため、所与のパケットはパケット内にどのストリームが運ばれているかについての情報を露出しない。したがって、ストリーム多重化は、ネットワーク上の扱いに関してストリームを区別するために使用されることを意図していない。異なるネットワーク上の扱いを必要とするアプリケーショントラフィックは、したがって異なる 5 タプル (すなわち複数の QUIC 接続) 上で運ばれるべきである。QUIC が接続の最初の RTT でアプリケーションデータを送信できる能力 (同じホストへの以前の接続が必要な資格情報を提供するために正常に確立されている場合) を考えると、別の接続を確立するコストは極めて低い。

4.2. 優先度付け (Prioritization)​

ストリームの優先度付けはネットワークにも受信者にも露出しない。優先度付けは送信者によって管理され、QUIC トランスポートはアプリケーションがストリームを優先度付けするためのインタフェースを提供すべきである [QUIC]。アプリケーションは QUIC の上に独自の優先度付け方式を実装できる。QUIC 上で動作するアプリケーションプロトコルは、HTTP 向けに [RFC9218] で定義されたもののような、優先度を通知する明示的なメッセージを定義できる。アプリケーションプロトコルは、エンドポイントがコンテキストに基づいて優先度を決定できる規則を定義するか、より高いレベルのインタフェースを提供して優先度の決定を上位のアプリケーションに委ねることができる。

再送の優先度処理は、トランスポート層で送信者によって実装できる。[QUIC] は、アプリケーションが異なる指示をしない限り、新しいデータより前に失われたデータを再送することを推奨する。QUIC エンドポイントが送信に完全に信頼できるストリームを使用する場合、再送の優先度付けはほとんどの場合有益であり、ギャップを埋め、フロー制御ウィンドウを解放する。部分的に信頼できる、または信頼できないストリームでは、より高優先度のストリームのデータより再送を優先スケジュールすることが望ましくない場合がある。そのようなストリームについて、QUIC は優先度付けを制御する明示的なインタフェースを提供するか、ストリームの信頼性レベルから優先度決定を導出できる。

4.3. 順序付きで信頼できる配信 (Ordered and Reliable Delivery)​

QUIC ストリームは順序付きで信頼できる配信を可能にする。実装が部分的信頼性や順序外配信のためにストリームを使用するオプションを提供することは可能だが、ほとんどの実装はデータが順序どおりに信頼して配信されると仮定する。

この仮定の下では、ストリームデータを受信するエンドポイントは、ストリームの先頭と連続するデータが利用可能になるまで前方に進まない場合がある。特に、受信者は連続するデータがアプリケーションに配信されるまでフロー制御クレジットを差し控える場合がある。[QUIC] の第 2.2 節を参照。この受信ロジックをサポートするため、エンドポイントは確認されるまでストリームデータを送信し、ストリーム先頭のデータが最初に送信され確認されることを保証する。

異なる送信動作を使用し、その変更をピアと交渉しないエンドポイントは、性能問題やデッドロックに遭遇する可能性がある。

4.4. フロー制御のデッドロック (Flow Control Deadlocks)​

QUIC のフロー制御 ([QUIC] の第 4 節) は、エンドポイントが着信データのために持つ有限のバッファへのアクセスを管理する手段を提供する。この機構は、エンドポイントのバッファ内、またはネットワーク上の転送中に存在できるデータの量を制限する。しかし、制限が接続の性能を次善にしたりデッドロックにしたりする条件を生み出す方法がいくつかある。

フロー制御のデッドロックは QUIC を使用する任意のプロトコルで可能であり、それらが問題になるかどうかは、実装がデータを消費しフロー制御クレジットを提供する方法に依存する。デッドロックの原因を理解することは、実装がデッドロックを避けるのに役立ち得る。

フロー制御クレジットの更新のサイズと頻度は性能に影響し得る。QUIC を使用するアプリケーションはしばしば、トランスポートバッファからデータを読み取るデータコンシューマを持つ。一部の実装は、トランスポート層とアプリケーション層に独立した受信バッファを持つ場合がある。データの消費は常に即座の処理を意味するわけではない。しかし、一般的な実装技法は、データが消費されるにつれて MAX_DATA および/または MAX_STREAM_DATA フレームを発行することで、送信者へのフロー制御クレジットを拡張することである。これらのフレームの配信は、受信者からデータ送信者へのバックチャネルのレイテンシに影響される。クレジットが適時に拡張されない場合、送信側アプリケーションはブロックされ、事実上送信者をスロットルできる。

大きなアプリケーションメッセージは、受信者がトランスポートからデータを段階的に読み取らない場合、デッドロックを生み出し得る。メッセージが利用可能なフロー制御クレジットより大きく、受信者がメッセージ全体が受信され配信されるまで追加のフロー制御クレジットを解放しない場合、デッドロックが発生し得る。これは、ストリームフロー制御制限に達していなくても可能である。なぜなら接続フロー制御制限が他のストリームによって消費され得るからである。

長さ接頭辞付きのメッセージ形式は、データコンシューマがトランスポートバッファ内のデータを未読のままにし、それによってフロー制御クレジットを差し控えることを容易にする。フロー制御制限がメッセージの残り部分の送信を妨げる場合、デッドロックが生じる。長さ接頭辞はこの種のデッドロックの検出も可能にし得る。アプリケーションプロトコルが単一の単位として処理される可能性のあるメッセージを持つ場合、メッセージ全体のためにフロー制御クレジットを原子的に予約することで、このスタイルのデッドロックは起こりにくくなる。

データコンシューマは、受信者がフロー制御クレジットを拡張しデッドロックの可能性を減らすために、利用可能になり次第すべてのデータを積極的に読み取ることができる。しかし、そのようなデータコンシューマは、部分的に処理されたメッセージのために保持する追加状態についてピアに責任を負わせる他の手段を必要とする場合がある。

デッドロックは、異なるストリーム上のデータが相互依存している場合にも発生し得る。あるストリーム上のデータが、依存する第 2 のストリーム上のデータより先に到着したとする。第 1 のストリームが未読のまま残され、受信者が第 2 のストリームのフロー制御クレジットを拡張するのを妨げる場合、デッドロックが発生し得る。相互依存データのデッドロックの可能性を減らすため、送信者は、依存するデータがストリームレベルと接続レベルの両方のフロー制御クレジットで計上されるまで、依存データが送信されないようにすべきである。

一部のデッドロックシナリオは、STOP_SENDING または RESET_STREAM で影響を受けたストリームをキャンセルすることで解決できる場合がある。一部のストリームのキャンセルは、一部のプロトコルでは接続の終了につながる。

4.5. ストリーム制限のコミットメント (Stream Limit Commitments)​

QUIC エンドポイントは、ピアが開くことを許可するストリームの累積制限を通信する責任がある。初期制限は initial_max_streams_bidi および initial_max_streams_uni トランスポートパラメータを使用して広告される。ストリームが開閉されると消費され、累積合計が増加する。制限は MAX_STREAMS フレームを使用して増加できるが、制限を減らす機構はない。ストリーム制限に達すると、これ以上ストリームを開けなくなり、QUIC を使用するアプリケーションのさらなる進行が妨げられる。この段階で、接続はアイドルタイムアウトまたは明示的なクローズにより終了できる。第 10 節を参照。

QUIC を使用し累積ストリーム制限を通信するアプリケーションは、制限に達する前に接続を閉じることを要求する場合がある。例えば、予定された保守のためにサーバを停止するためである。即時の接続クローズは、アクティブに使用中のストリームの突然のクローズを引き起こす。アプリケーションが QUIC ストリームをどのように使用するかに応じて、これは望ましくないか、振る舞いや性能に有害であり得る。

より優雅なクローズ技法は、ストリーム制限への増加の送信を停止し、残りのストリームが消費された後に接続が自然に終了するのを許すことである。しかし、それに要する時間はピアに依存し、予測不能なクローズ期間はアプリケーションや運用上のニーズに合わない場合がある。QUIC を使用するアプリケーションは、コミットメントと不確定性を減らすために、開いたストリーム制限について保守的であり得る。しかし、ストリーム制限に過度に保守的であることはストリームの並行性に影響する。これらの側面のバランスは、アプリケーションとその展開に固有であり得る。

突然のクローズを避けるためにストリーム制限に頼る代わりに、アプリケーション層の優雅なクローズ機構を使用して、将来のある時点で接続を明示的に閉じる意図を通信できる。HTTP/3 は GOAWAY フレームを使用してそのような機構を提供する。HTTP/3 では、クライアントが GOAWAY フレームを受信すると、累積ストリーム制限が許す場合でも新しいストリームを開くのを停止する。代わりに、クライアントはさらなるストリームを開くために新しい接続を作成する。古い接続上のすべてのストリームが閉じられた後、接続クローズにより、またはアイドルタイムアウトの期限切れ後に安全に終了できる (第 10 節を参照)。

5. パケット化とレイテンシ (Packetization and Latency)​

QUIC はアプリケーションに複数のストリームを提供するインタフェースを公開するが、アプリケーションは通常、それらのストリーム上で送信されるデータがフレームにどのようにマッピングされるか、またはそれらのフレームがパケットにどのように束ねられるかを制御できない。

デフォルトでは、多くの実装は帯域幅消費と計算コストを最小化するために、1 つまたは複数のストリームからの STREAM フレームを各 QUIC パケットに詰め込もうとする ([QUIC] の第 13 節を参照)。パケットを埋めるのに十分なデータがない場合、実装はレイテンシではなく帯域効率を最適化するために短時間待機する場合がある。この遅延は事前設定されるか、アプリケーションの観測された送信パターンに基づいて動的に調整され得る。

アプリケーションが低いレイテンシを必要とし、送信するデータが小さなチャンクのみである場合、すべてのデータを即座に送信すべきであることを QUIC に示すことが有用であり得る。あるいは、アプリケーションが特定の送信パターンを使用することを期待する場合、フレームをパケットに束ねる前にどれだけ待機するかの推奨遅延を QUIC に提供することもできる。

同様に、アプリケーションは通常、ワイヤ上の QUIC パケットの長さを制御しない。QUIC はパケットサイズを任意に増加させるために PADDING フレームを追加する能力を提供する。パディングは、ハンドシェイク中にパスが少なくともあるサイズのデータグラムを転送できることを保証するため ([QUIC] の第 8.1 節および第 14.1 節)、接続マイグレーション後のパス検証のため ([QUIC] の第 8.2 節)、および Datagram Packetization Layer PMTU Discovery (DPLPMTUD) のため ([QUIC] の第 14.3 節) に QUIC によって使用される。

パディングは、送信されるデータに関する情報の漏洩を減らすためにもアプリケーションによって使用できる。QUIC 実装は、アプリケーション層がパディングの適用方法を指定できるインタフェースを公開できる。

6. エラー処理 (Error Handling)​

QUIC は、検出されたエラーをピアに通知することをエンドポイントに推奨する。エラーはトランスポート層とアプリケーション層で発生し得る。プロトコル違反などのトランスポートエラーは、接続全体に影響する。QUIC を使用するアプリケーションは、独自のエラー検出と通知を定義できる (例えば [QUIC-HTTP] の第 8 節を参照)。アプリケーションエラーは接続全体または単一のストリームに影響し得る。

QUIC はトランスポート層でのエラー処理に使用されるエラーコード空間を定義する。QUIC はエンドポイントに最も具体的なコードの使用を奨励するが、汎用コードを含む任意の適用可能なコードが許される。

QUIC を使用するアプリケーションは、QUIC や他のアプリケーションから独立したエラーコード空間を定義する (例えば [QUIC-HTTP] の第 8.1 節を参照)。アプリケーションエラーコード空間の値は、接続レベルとストリームレベルのエラーにわたって再利用できる。

接続エラーは接続終了につながる。それらは CONNECTION_CLOSE フレームを使用して通知され、エラーコードと長さゼロであり得る reason フィールドを含む。異なる種類の CONNECTION_CLOSE フレームがトランスポートとアプリケーションのエラーを通知するために使用される。

ストリームエラーはストリーム終了につながる。これらは STOP_SENDING または RESET_STREAM フレームを使用して通知され、エラーコードのみを含む。

7. 確認応答の効率 (Acknowledgment Efficiency)​

拡張なしの QUIC バージョン 1 は、TCP から採用された確認応答戦略を使用する ([QUIC] の第 13.2 節を参照)。すなわち、1 つおきのパケットを確認することを推奨する。しかし、QUIC 確認応答の生成と処理は送信者と受信者でリソースを消費する。確認応答は転送コストも発生させ、リンク利用に寄与し、一部の種類のネットワーク上での性能に影響し得る。アプリケーションは、確認応答のレートを下げる代替戦略を使用することで全体の性能を改善できる場合がある。[QUIC-ACK-FREQUENCY] は、確認応答の望ましい遅延を通知する拡張を記述し、ユースケースならびに輻輳制御と回復への影響を論じる。

8. ポート選択とアプリケーションエンドポイントの発見 (Port Selection and Application Endpoint Discovery)​

一般に、ポート番号は 2 つの目的を果たす。「第一に、同じエンドポイント対の間のトランスポートセッションを区別する多重化識別子を提供し、第二に、プロセスが接続するアプリケーションプロトコルと関連サービスを識別する場合がある」([RFC6335] の第 3 節)。アプリケーションをネットワーク上でポート番号に基づいて識別できるという仮定は、カプセル化や動的ポート割り当ての機構により、今日では以前ほど当てはまらない。[RFC6335] で述べられているとおりである。

QUIC は汎用トランスポートプロトコルであるため、サーバが QUIC に特定の UDP ポートを使用するという要件はない。既に UDP への代替マッピングを持たない TCP へのフォールバックがあるアプリケーションでは、通常、アプリケーションに既に登録されている TCP ポートに対応する UDP ポート番号を登録 (必要であれば) して使用することが適切である。例えば、HTTP/3 [QUIC-HTTP] のデフォルトポートは UDP ポート 443 であり、TLS over TCP 上の HTTP/1.1 または HTTP/2 に類似する。

ポート番号が登録されたサービス名に一意にマッピングされるという仮定がネットワーク管理実務で広く存在する中、登録されたサービス名に容易にマッピングできないポートの使用は、アプリケーション識別にポート番号を使用するファイアウォールなどのネットワーク要素による遮断や転送動作の他の変更につながる場合がある。

アプリケーションは、デフォルト以外のポートの利用を可能にするために代替のエンドポイント発見機構を定義できる。例えば、HTTP/3 ([QUIC-HTTP] の第 3.2 節および第 3.3 節) は、HTTP オリジンがある UDP ポート上の同等の HTTP/3 エンドポイントの可用性を広告するために、Application-Layer Protocol Negotiation (ALPN) [RFC7301] トークンとして "h3" を使用する HTTP Alternative Services [RFC7838] の使用を規定する。

ALPN は、クライアントとサーバが所与の接続で使用する複数のプロトコルのうちどれを使用するかを交渉することを許す。したがって、提示された ALPN トークンに基づいて、単一の UDP ポート上で複数のアプリケーションがサポートされ得る。QUIC を使用するアプリケーションは、TLS ハンドシェイクで使用するための ALPN トークンを登録することが要求される。

QUIC バージョン 1 が完全なバージョン交渉機構の定義を延期したため、HTTP/3 は QUIC バージョン 1 を要求し、ALPN トークン ("h3") がそのバージョンにのみ適用されると定義する。これまでのところ、異なる QUIC バージョンの使用を管理するための単一のアプローチは、HTTP/3 でも一般でも選択されていない。QUIC を使用するアプリケーションプロトコルは、プロトコルが異なる QUIC バージョンをどのように管理するかを考慮する必要がある。それらのプロトコルの決定は、HTTP/3 のような他のプロトコルが行った選択から情報を得る場合がある。

8.1. 送信元ポートの選択 (Source Port Selection)​

一部の UDP プロトコルはリフレクション攻撃に脆弱であり、攻撃者がサービス拒否として第三者にトラフィックを向けられる。例えば、次の送信元ポートは、しばしばサーバの誤設定により、リフレクション攻撃に脆弱であることが知られているアプリケーションに関連付けられる。

  • ポート 53 - DNS [RFC1034]
  • ポート 123 - NTP [RFC5905]
  • ポート 1900 - SSDP [SSDP]
  • ポート 5353 - mDNS [RFC6762]
  • ポート 11211 - memcache

サービスは、大量のパケットの処理オーバーヘッドを避けるために、リフレクション攻撃に脆弱であることが知られているプロトコルに関連付けられた送信元ポートを遮断する場合がある。しかし、この慣行はクライアントに負の影響を与える。新しい接続の確立を要求するだけでなく、場合によってはクライアントが一定期間そのサービスに QUIC を使用するのを避け、非 UDP プロトコルにダウングレードする原因となり得る (第 2 節を参照)。

その結果、クライアント実装は、リフレクション攻撃に脆弱であることが知られているプロトコルに関連付けられた送信元ポートの使用を避けることが奨励される。[RFC6335] で与えられたクライアント実装への一般的な指針に従い、範囲 49152-65535 のエフェメラルポートを使用することは、これらのポートを避ける効果があることに注意。他の送信元ポートもリフレクションのベクトルとなり得ることに注意。

9. 接続マイグレーション (Connection Migration)​

QUIC はクライアントによる接続マイグレーションをサポートする。クライアントの IP アドレスが変化しても、QUIC エンドポイントは QUIC ヘッダ内の Destination Connection ID フィールド (第 11 節を参照) を使用して、パケットを既存のトランスポート接続に関連付けることができる。これは、NAT リバインディング、ローカルインタフェースの意図的な変更、一時的な IPv6 アドレスの期限切れ [RFC8981]、またはサーバからの優先アドレスの指示 ([QUIC] の第 9.6 節) など、アドレス情報が変化するケースをサポートする。

いずれかのクライアントが NAT の背後にある、またはその可能性がある場合、サーバに対する非ゼロ長の接続 ID の使用が強く推奨される。アクティブなマイグレーションがサポートされる場合も、非ゼロ長の接続 ID が強く推奨される。接続が意図的に新しいパスにマイグレートされる場合、ネットワーク観測者によるリンク可能性を最小化するために新しい接続 ID が使用される。他の QUIC エンドポイントは、非ゼロ長の接続 ID が提供されている場合、接続 ID を使用して異なるアドレスを同じ接続とエンティティにリンクする。

QUIC バージョン 1 の基本仕様は一度に単一のネットワークパスの使用のみをサポートし、フェイルオーバーのユースケースを可能にする。アドレススプーフィング攻撃を避けるために、エンドポイントが使用前にパスを検証するようパス検証が要求される。パス検証には少なくとも 1 RTT かかり、パスマイグレーション後に輻輳制御もリセットされる。したがって、マイグレーションは通常性能への影響を持つ。

一度に複数のパスで送信できる QUIC プロービングパケットは、アドレス検証およびパス特性の測定に使用される。プロービングパケットはアプリケーションデータを運べないが、おそらくパディングフレームを含む。エンドポイントは、その受信に関する情報をそのパスの輻輳制御への入力として使用できる。アプリケーションは、プロービングから学んだ情報を使用してパス切り替えの決定に情報を与えることができる。

QUIC バージョン 1 では、クライアントのみがアクティブにマイグレートできる。しかし、サーバはハンドシェイク中に、ハンドシェイク後に接続を異なるアドレスに転送することを好むことを示すことができる。例えば、これは複数のサーバで共有されるアドレスから、サーバインスタンスに固有のアドレスへ移動するために使用され得る。サーバは TLS ハンドシェイク中にトランスポートパラメータで IPv4 と IPv6 のアドレスを提供でき、両方が提供された場合クライアントは 2 つの間で選択できる。[QUIC] の第 9.6 節を参照。

10. 接続の終了 (Connection Termination)​

QUIC 接続は 3 つの方法のいずれかで終了する。暗黙のアイドルタイムアウト、明示的な即時クローズ、または明示的なステートレスリセットである。

QUIC は優雅な接続終了のためのいかなる機構も提供しない。QUIC を使用するアプリケーションは独自の優雅な終了プロセスを定義できる (例えば [QUIC-HTTP] の第 5.2 節を参照)。

QUIC のアイドルタイムアウトはトランスポートパラメータ経由で有効になる。クライアントとサーバはタイムアウト期間を告知し、接続の実効値は 2 つの値の最小値である。タイムアウト期間が経過した後、接続は静かに閉じられる。したがって、アプリケーションは自身の最大値を設定でき、またこの接続の計算された最小値にアクセスできるべきである。アプリケーションは、より短いタイムアウト値がリソースをより迅速に解放し得るため、開いている接続数または期待される接続数に基づいて新しい接続の最大アイドルタイムアウトを調整する場合がある。

ストリーム上またはデータグラムで交換されるアプリケーションデータは、QUIC のアイドルタイムアウトを延期する。独自のキープアライブ機構を提供するアプリケーションは、したがって QUIC 接続を生存させ続ける。独自のキープアライブを提供しないアプリケーションは、トランスポート層の機構を使用できる ([QUIC] の第 10.1.2 節および第 3.2 節を参照)。しかし、そのようなトランスポート動作を制御する QUIC 実装のインタフェースは様々であり、そのようなアプローチの堅牢性に影響し得る。

即時クローズは CONNECTION_CLOSE フレームによって通知される (第 6 節を参照)。即時クローズはすべてのストリームを即座に閉じさせ、アプリケーションに影響し得る。第 4.5 節を参照。

ステートレスリセットは、接続状態にアクセスできないエンドポイントのための最後の手段のオプションである。ステートレスリセットの受信は、アプリケーション層情報が提供されない点で接続エラーとは異なる、回復不能なエラーの指示である。

11. 情報の露出と接続 ID (Information Exposure and the Connection ID)​

QUIC は、暗号化コンテキストが確立される前、または情報がネットワークによって使用されることを意図しているために、ヘッダの非暗号化部分でいくつかの情報をネットワークに露出する。QUIC の管理可能性に関する詳細は [QUIC-MANAGEABILITY] を参照。QUIC は追加情報 (バージョンと送信元接続 ID) を露出するロングヘッダを持ち、ショートヘッダは宛先接続 ID のみを露出する。QUIC バージョン 1 では、ロングヘッダは接続確立中に使用され、ショートヘッダは確立された接続でのデータ送信に使用される。

接続 ID はゼロ長であり得る。ゼロ長の接続 ID は各エンドポイントで個別に選択でき、接続確立中にクライアントが送信する最初のパケットを除く任意のパケットで選択できる。

ゼロ長の接続 ID を選択するエンドポイントは、ゼロ長の宛先接続 ID を持つパケットを受信する。エンドポイントは、どの接続が参照されているかを識別するために、送信元および宛先の IP アドレスとポート番号などの他の情報を使用する必要がある。これは、これらの値が変化した場合にエンドポイントがデータグラムを接続に正常に対応付けられないことを意味し、接続が事実上 NAT リバインディングを生き延びたり新しいパスにマイグレートしたりできなくし得る。

11.1. サーバ生成の接続 ID (Server-Generated Connection ID)​

QUIC は、接続確立中にクライアントに送信されるサーバ生成の接続 ID をサポートする ([QUIC] の第 7.2 節を参照)。ロードバランサの背後にあるサーバは、ステートレスなロードバランシングをサポートするために、ハンドシェイク中に接続 ID を変更し、サーバのアイデンティティまたはそのロードバランシングプールに関する情報を符号化する必要がある場合がある。

ロードバランサおよび他のルーティングインフラを持つサーバ展開は、アドレス、ポート、または接続 ID が変化しても、このインフラが接続状態を持つサーバインスタンスにパケットを一貫してルーティングすることを保証する必要がある。これはサーバとインフラの間の調整を必要とする場合がある。これを達成する 1 つの方法は、ルーティング情報を接続 ID に符号化することである。この技法の例については [QUIC-LB] を参照。

11.2. 接続 ID マイグレーションによるタイミングのリンク可能性の緩和 (Mitigating Timing Linkability with Connection ID Migration)​

QUIC エンドポイントが新しい接続 ID を発行しない場合、クライアントはそれらを使用してアドレスマイグレーションのリンク可能性を減らせない。外部観測者にとってリンク不能な値を選択することで、異なるパス上の活動が接続 ID を使用して容易に相関付けられないことを保証する。

十分に堅牢な接続 ID 生成方式はリンク可能性の問題を緩和するが、完全な保護を提供するわけではない。6 タプル (送信元および宛先アドレスならびにマイグレートされた Connection ID) の寿命の分析は、それでもこれらのリンクを露出する場合がある。

サーバプール内での接続マイグレーションがまれな場合、観測者が 2 つの接続 ID を関連付けるのは容易である。逆に、すべてのサーバが複数の同時マイグレーションを処理する場合、露出したサーバマッピングでさえ不十分な情報である場合がある。

これらの攻撃に対する最も効率的な緩和は、ネットワーク設計および/または運用慣行を通じて、より多くのフローを単一のサーバ側アドレスに負荷するロードバランシングアーキテクチャを使用すること、所与の時点での同時マイグレーション数を増やそうとしてマイグレーションのタイミングを調整すること、または他の手段を使用することによる。

11.3. リダイレクションのためのサーバ Retry の使用 (Using Server Retry for Redirection)​

QUIC は、クライアントの Initial パケットに応答してサーバが送信できる Retry パケットを提供する。サーバはそのパケットで新しい接続 ID を選択する場合があり、クライアントはサーバが選択した接続 ID で別のクライアント Initial パケットを送信することでリトライする。この機構は、例えば性能上の理由、またはサーバプール内のサーバが段階的にアップグレードされ、したがって異なるバージョンの QUIC をサポートし得る場合に、接続を異なるサーバにリダイレクトするために使用できる。

この場合、あるプールに属するすべてのサーバが、接続 ID に基づいてトラフィックを転送するロードバランサと協力してサービスされると仮定される。サーバは、ロードバランサが次の Initial パケットをそのプール内の異なるサーバにリダイレクトするよう、Retry パケット内の接続 ID を選択できる。あるいは、ロードバランサは [QUIC-RETRY] でさらに記述されるように Retry オフロードを直接提供できる。

TLS 再開チケットを構築するための [RFC5077] の第 4 節に記述されたアプローチは、検証トークンにも適用できる例を提供する。しかし、より現代的な暗号アルゴリズムの使用が強く推奨される。

12. Quality of Service (QoS) と Diffserv Code Point (DSCP)​

[QUIC] で定義される QUIC は、単一の輻輳制御器と回復ハンドラを持つ。この設計は、同じ Diffserv Code Point (DSCP) [RFC2475] を持つ QUIC 接続のすべてのパケット、または少なくとも同じ 5 タプル {宛先アドレス, 送信元アドレス, プロトコル, 宛先ポート, 送信元ポート} を持つパケットが、各パケットの損失または遅延に関するフィードバックが輻輳制御器への入力として使用されるため、類似のネットワーク上の扱いを受けると仮定する。したがって、同じ接続に属するパケットは単一の DSCP を使用すべきである。[RFC7657] の第 5.1 節は、データグラムトランスポートプロトコルとの Diffserv 相互作用の議論を提供する (この点で、QUIC との相互作用は Stream Control Transmission Protocol (SCTP) のものと類似する)。

単一の QUIC 接続上で複数のフローを多重化する場合、選択される DSCP 値は、多重化されたすべてのフローに要求される最高優先度に関連付けられたものであるべきである。

例えば異なる DSCP の使用により差別化されたネットワーク上の扱いが望ましい場合、同じサーバへの複数の QUIC 接続を使用できる。一般に、増加したオーバーヘッド、そしてより重要なこととして競合する輻輳制御を避けるために、同じサーバへの QUIC 接続数を最小化することが推奨される。

Diffserv の他の利用と同様に、パケットが DSCP 値をサポートしないネットワークセグメントに入ると、接続が期待するネットワーク上の扱いを受けられない結果となり得る。このパケット内の DSCP 値は、パケットがネットワークパスに沿って進むにつれて再マークされ、要求された扱いを変更する場合もある。

13. バージョンと暗号ハンドシェイクの利用 (Use of Versions and Cryptographic Handshake)​

QUIC におけるバージョニングは、不変であると宣言されたいくつかのヘッダフィールドの意味を除き、プロトコルの振る舞いを完全に変更し得る [QUIC-INVARIANTS]。より高いバージョン番号を持つ QUIC のバージョンが必ずしもより良いサービスを提供するわけではなく、単に異なる機能セットを提供する場合がある。そのため、アプリケーションは使用したい QUIC のバージョンを選択できる必要がある。

新しいバージョンは TLS 1.3 以上以外の暗号化方式を使用し得る。[QUIC] は、現在 TLS 1.3 によって実現され別仕様 [QUIC-TLS] に記述されている暗号ハンドシェイクの要件を規定する。この分割は、異なる暗号ハンドシェイクでの軽量なバージョニングを可能にするために行われる。

[QUIC] で確立された "QUIC Versions" レジストリは、実験のための暫定登録を許す。実験バージョンについても登録は衝突を避けるために重要である。実験バージョンは長期に使用したり恒久的に登録したりすべきではなく、バージョン番号に基づくフィンガープリンティングのリスクを最小化する。

14. 新バージョンの展開の有効化 (Enabling Deployment of New Versions)​

QUIC バージョン 1 は基本仕様でバージョン交渉機構を規定しないが、[QUIC-VERSION-NEGOTIATION] は互換バージョン交渉を提供する拡張を提案する。

このアプローチは 3 段階の展開機構を使用し、大規模サーバ展開全体での複数バージョンの段階的ロールアウトと実験を可能にする。このアプローチでは、いずれのサーバもそれを広告する (段階 2) 前に、展開内のすべてのサーバが新しいバージョンを使用する接続を受け入れなければならず (段階 1)、新しいバージョンの認証 (段階 3) は、そのバージョンの広告が完全に展開された後にのみ進行する。

詳細は [QUIC-VERSION-NEGOTIATION] の第 5 節を参照。

15. QUIC 上の非信頼データグラムサービス (Unreliable Datagram Service over QUIC)​

[RFC9221] は、QUIC 上で非信頼データグラムの送受信を可能にする QUIC 拡張を規定する。UDP 上で直接動作するのとは異なり、QUIC データグラムサービスを使用するアプリケーションは、[RFC8085] に従い独自の輻輳制御を実装する必要がない。なぜなら QUIC データグラムは輻輳制御されるからである。

QUIC データグラムはフロー制御されず、そのため受信者が過負荷の場合データチャンクがドロップされ得る。QUIC の信頼できる送信サービスが複数の QUIC ストリーム上でデータを順序どおりに送受信するストリームベースのインタフェースを提供する一方、データグラムサービスは順序なしのメッセージベースのインタフェースを持つ。必要であれば、非信頼データグラムの別々のフローを 1 つの QUIC 接続上で多重化できるように、アプリケーション層のフレーミングを上に使用できる。

16. IANA の考慮事項 (IANA Considerations)​

本文書には IANA へのアクションはない。ただし、第 8 節は、既に TCP ポートを登録しているがトランスポートとして QUIC を指定したいアプリケーションは、既存の TCP 登録に類似した UDP ポートを登録すべきであると推奨していることに注意。

17. セキュリティの考慮事項 (Security Considerations)​

[QUIC] および [QUIC-TLS] のセキュリティの考慮事項を参照。基盤となるトランスポートプロトコルのセキュリティの考慮事項は、QUIC を使用するアプリケーションに関連する。[QUIC-TLS] で論じられるリンク可能性、リプレイ攻撃、および乱数性に関する考慮事項は、QUIC を展開および使用する際に考慮すべきである。

さらに、新しいアドレスへのマイグレーションは、クライアントアドレス間のリンクをサーバに露出し、接続 ID を変更できない場合、またはフローが他の方法で相関付けられる場合、パスにもこのリンクを露出する場合がある。マイグレーションがサポートされる場合、これはユーザプライバシーに関して考慮する必要がある。

アプリケーション開発者は、UDP のネットワーク遮断により QUIC を使用できない場合に使用するフォールバックが、QUIC と同じセキュリティ特性を保証すべきであることに注意すべきである。それが不可能な場合、接続は失敗し、アプリケーションがより安全性の低い代替へのフォールバックを明示的に処理できるようにすべきである。第 2 節を参照。

さらに、[QUIC-HTTP] は HTTP に固有のセキュリティの考慮事項を提供する。しかし、クロスプロトコル攻撃、トラフィック分析とパディング、またはマイグレーションに関する議論などは、QUIC を使用する他のアプリケーションにも関連し得る。

18. 参考文献 (References)​

18.1. 規範的参考文献 (Normative References)​

[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-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, 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.

18.2. 情報的参考文献 (Informative References)​

[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.

[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>.

[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.

[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>.

[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-HTTP] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, 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-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-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-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>.

[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.

[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.

[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.

[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.

[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.

[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.

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, 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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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>.

[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>.

[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>.

[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.

[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>.

謝辞 (Acknowledgments)​

Last Call レビューアの Chris Lonvick および Ines Robles に特に感謝する。

本研究は Horizon 2020 助成契約 no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI) の下で欧州委員会により、および契約 no. 15.0268 の下でスイス連邦教育・研究・イノベーション事務局により部分的に支援された。この支援は推奨を意味しない。

貢献者 (Contributors)​

次の人々が本文書に重要なテキストまたはフィードバックを寄稿した。

Gorry Fairhurst, Ian Swett, Igor Lubashev, Lucas Pardue, Mike Bishop, Mark Nottingham, Martin Duke, Martin Thomson, Sean Turner, Tommy Pauly

著者の住所 (Authors' Addresses)​

Mirja Kühlewind
Ericsson
Email: [email protected]

Brian Trammell
Google Switzerland GmbH
Gustav-Gull-Platz 1
CH-8004 Zurich
Switzerland
Email: [email protected]