6. プロトコル固有メソッドの仕様
DPLPMTUDを使用する各PLに対して、プロトコル固有の詳細を指定する必要があります。
最初のサブセクションでは、UDPまたはUDP-Liteを使用するアプリケーションの一部としてDPLPMTUDメソッドを実装する方法に関するガイダンスを提供します。このガイダンスは、特定のトランスポートプロトコルを含まない他のデータグラムサービス(トンネルカプセル化など)にも適用できます。以下のサブセクションでは、トランスポートサービスの一部としてDPLPMTUDを実装する方法を説明し、このサービスを使用するアプリケーションがSCTPおよびQUICを使用する際に、このメソッドを自分で実装する必要なくPLPMTUの発見から利益を得られるようにします。
6.1. UDPまたはUDP-LiteによるDPLPMTUDのアプリケーションサポート
UDP[RFC0768]およびUDP-Lite[RFC3828]の現在の仕様では、PLPMTUDをサポートするRFCシリーズのメソッドは定義されていません。特に、UDPトランスポートは、データグラムPLPMTUDを実装するために必要なトランスポート機能を提供しません。
DPLPMTUDメソッドは、UDPまたはUDP-Liteに直接または間接的に構築されたアプリケーションの一部として実装できますが、メソッドを実装するために上位層プロトコル機能に依存します[BCP145]。
DPLPMTUDで使用される一部のプリミティブは、データグラムAPI経由では利用できない場合があります(例えば、IP層キャッシュからPLPMTUにアクセスする機能や、受信したPTBメッセージを解釈する機能など)。
さらに、PMTU発見が複数のプロトコル層によって実行されないことが推奨されます。基盤となるトランスポートシステムがこの機能を提供する場合、アプリケーションはDPLPMTUDの使用を避けるべきです。プロセス間で状態を共有し、異なるPLインスタンスのプロービングを調整する点で、PLPMTUを管理する汎用メソッドには利点があります。
6.1.1. アプリケーション要求
アプリケーションには、宛先エンドポイントからの応答を要求するためのアプリケーション層プロトコルメカニズム(メッセージ確認応答メソッドなど)が必要です。このメソッドは、送信者が応答で返される値をチェックして、パス外からのデータ注入に対する追加の保護を提供できるようにするべきです[BCP145]。適切なメソッドには、セッションIDや初期化されたシーケンス番号など、2つのエンドポイントのみが知るパラメータが含まれます。
6.1.2. アプリケーション応答
アプリケーションには、宛先エンドポイントからの応答を通信するためのアプリケーション層プロトコルメカニズムが必要です。この応答は、プローブがパスを正常に横断したことを示すことができますが、一部(またはすべて)のパケットが宛先に到達できなかったことを示すこともできます。
6.1.3. アプリケーションプローブパケットの送信
プローブパケットはアプリケーションデータブロックを運ぶことができますが、プロービングに使用した場合、このデータの正常な送信が危険にさらされるリスクがあります。一部のアプリケーションは、データ送信の中断を避けるために、アプリケーションデータブロックを運ばないプローブパケットを使用することを好む場合があります。
6.1.4. 初期接続性
リモートピアとの接続性を確認する他の上位層情報がないアプリケーションは、BASE状態に入る前に、確認応答されたプローブパケットを使用して接続するメカニズムを実装するべきです。
6.1.5. パスの検証
データグラムが正しく配信されていることを確認する他の上位層情報がないアプリケーションは、SEARCH_COMPLETE状態にあるときにプローブパケットを定期的に送信するために、CONFIRMATION_TIMERを実装するべきです。
6.1.6. PTBメッセージの処理
PTBメッセージを受信できる、および受信を希望するアプリケーションは、[BCP145]のセクション5.2で指定されたICMP検証を実行しなければなりません。これには、アプリケーションが受信した各PTBメッセージをチェックして、送信されたトラフィックに応答して受信されたことを検証し、報告されたPL_PTB_SIZEが現在プロービングされているサイズよりも小さいことを検証する必要があります(セクション4.6.2を参照)。検証されたPTBメッセージは、DPLPMTUDアルゴリズムへの入力として利用してもよいですが、PLPMTUを直接設定するために使用してはなりません。
6.2. SCTPのためのDPLPMTUD
[RFC4821]のセクション10.2では、SCTPの推奨PLPMTUDプロービング方法を規定しており、[RFC4960]のセクション7.3では、エンドポイントがRFC 4821の技術を宛先アドレスごとに適用することを推奨しています。DPLPMTUD仕様は、PLがPMTUを発見する実践を継続しますが、RFC4960を更新して、この文書で指定されたメソッドの使用を推奨します:プローブを生成する推奨メソッドは、パディングのみで構成されるチャンクをSCTPメッセージに追加することです。[RFC4820]で定義されたPADチャンクは、プローブパケットを構築するために、最小長のHEARTBEAT(HB)チャンクに付加すべきです。これにより、プロービングがユーザーメッセージの転送から独立し、輻輳制御またはフロー制御から独立します。これは、DATAチャンク(必要に応じて他の制御チャンクとバンドル)をパスプローブとして使用するよりも好ましいです。
[RFC4960]のセクション6.9では、SCTPを使用する際にPL送信者がユーザーメッセージをDATAチャンクにセグメント化することを説明しています。これは、SCTPメッセージが送信されると、再セグメント化できないことを示しています。[RFC4960]は、MPSが削減されたときにDATAチャンクを再送信する方法を説明しており、[RFC4960]のセクション6.9は、この場合にIP断片化を使用することを説明しています。この文書では、これに変更を加えません。
6.2.1. SCTP/IPv4およびSCTP/IPv6
6.2.1.1. 初期接続性
基本プロトコルは[RFC4960]で指定されています。これは、確認応答されたPLを提供します。したがって、送信者は、アソシエーションが確認されるとBASE状態に入ることができます。
6.2.1.2. SCTPプローブパケットの送信
プローブパケットは、SCTP共通ヘッダー、HEARTBEATチャンク、およびPADチャンクで構成されます。PADチャンクは、プローブパケットの長さを制御するために使用されます。HEARTBEATチャンクは、HEARTBEAT ACKチャンクの送信をトリガーするために使用されます。HEARTBEAT ACKチャンクの受信は、成功したプローブの受信を確認します。成功したプローブはアソシエーションとパスカウンターを更新しますが、失敗したプローブは無視されます(PLPMTUが大きすぎることを選択した結果と見なされます)。
SCTP送信者は、プローブパケットの合計サイズを決定できる必要があります。HEARTBEATチャンクは、[RFC4960]で提案された情報に加えて、実装がHEARTBEAT ACKを送信されたプローブのサイズと関連付けるのに役立つプローブのサイズも含むハートビート情報パラメータを運ぶことができます。乱数を送信し、返された情報にも対応する乱数が含まれていることを検証するなど、他のメソッドも可能です。
PADチャンクの長さは、SCTP共通ヘッダーとHEARTBEATチャンクのサイズを減らすことによって計算されます。PADチャンクのペイロードには、任意のデータが含まれます。IP経由で送信する場合、PMTUサイズにはIPv4またはIPv6ヘッダーも含まれます。
プロービングは、PLハンドシェイクの直後に開始できます。これは、データが送信される前に実行できます。この動作(つまり、PMTUがインターフェースMTU以下である)を想定すると、このプロセスには、送信されたDPLPMTUDプローブの数に応じて、複数のラウンドトリップタイム期間が必要になります。ハートビートタイマーは、PROBE_TIMERを実装するために使用できます。
6.2.1.3. SCTPによるパスの検証
SCTPは確認応答されたPLを提供するため、送信者はSEARCH_COMPLETE状態にあるときにCONFIRMATION_TIMERを実装してはなりません。
6.2.1.4. SCTPによるPTBメッセージの処理
[RFC4960]の付録Cで指定されているように、通常のICMP検証を実行しなければなりません。これには、PTBメッセージのペイロードでSCTP共通ヘッダーの最初の8バイトが引用される必要があり、これはICMPv4の場合に該当し、通常はICMPv6の場合に該当します。
PTBメッセージが検証されると、PTBメッセージで報告されたPTB_SIZEから計算されたPL_PTB_SIZEは、報告されたPL_PTB_SIZEが現在のプローブサイズよりも小さい場合、DPLPMTUDアルゴリズムで使用すべきです(セクション4.6を参照)。
6.2.2. SCTP/UDPのためのDPLPMTUD
SCTPのUDPカプセル化は[RFC6951]で指定されています。
この仕様は、RFC 6951のセクション5.6のRFC 4821への参照を、この文書(RFC 8899)を参照するように更新します。RFC 6951は、RFC 6951のセクション5.6の最後に以下の文を追加することによって更新されます:
パスMTUを決定する推奨メソッドは、RFC 8899で指定されています。
6.2.2.1. 初期接続性
送信者は、SCTPアソシエーションが確認されるとBASE状態に入ることができます。
6.2.2.2. SCTP/UDPプローブパケットの送信
データグラムプロービングは、セクション6.2.1.2で指定されているように実行できます。プローブパケットのサイズには、8バイトのUDPヘッダーが含まれます。これは、PADチャンクを使用してプローブパケットをパディングするときに考慮する必要があります。
6.2.2.3. SCTP/UDPによるパスの検証
SCTPは確認応答されたPLを提供します。したがって、送信者はSEARCH_COMPLETE状態にあるときにCONFIRMATION_TIMERを実装しません。
6.2.2.4. SCTP/UDPによるPTBメッセージの処理
[RFC4960]の付録Cで指定されているように、PTBメッセージのICMP検証を実行しなければなりません。これには、PTBメッセージにSCTP共通ヘッダーの最初の8バイトが存在する必要があり、これはICMPv4の場合に該当する可能性があります(ただし、UDPヘッダーが引用されたパケットヘッダーの一部を消費することに注意してください)、通常はICMPv6の場合に該当します。検証が完了すると、PTBメッセージのPTB_SIZEから計算されたPL_PTB_SIZEは、報告されたPL_PTB_SIZEが現在のプローブサイズよりも小さい場合、DPLPMTUDで使用すべきです。
6.2.3. SCTP/DTLSのためのDPLPMTUD
SCTPのデータグラムトランスポート層セキュリティ(DTLS)カプセル化は[RFC8261]で指定されています。これは、WebRTC実装のデータチャネルで使用されます。この仕様は、RFC 8261のセクション5のRFC 4821への参照を、この文書(RFC 8899)を参照するように更新します。
6.2.3.1. 初期接続性
送信者は、SCTPアソシエーションが確認されるとBASE状態に入ることができます。
6.2.3.2. SCTP/DTLSプローブパケットの送信
データグラムプロービングは、セクション6.2.1.2で指定されているように実行できます。最大ペイロードは、DTLSヘッダーのサイズだけ削減され、PADチャンクを使用してパディングするときに考慮する必要があります。プローブパケットのサイズには、DTLS PLヘッダーが含まれます。これは、PADチャンクを使用してプローブパケットをパディングするときに考慮する必要があります。
6.2.3.3. SCTP/DTLSによるパスの検証
SCTPは確認応答されたPLを提供するため、送信者はSEARCH_COMPLETE状態にあるときにCONFIRMATION_TIMERを実装してはなりません。
6.2.3.4. SCTP/DTLSによるPTBメッセージの処理
[RFC4960]は、SCTP/DTLS ICMPメッセージペイロードの検証メソッドを指定しておらず、この文書もそうです。これにより、PLでのPTBメッセージの処理が妨げられます。
6.3. QUICのためのDPLPMTUD
QUIC[QUIC]は、受信フィードバックを提供するUDPベースのPLです。UDPペイロードには、QUICパケットヘッダー、保護されたペイロード、および認証フィールドが含まれます。プローブパケットを構築するために使用できるパディングとパケット合体をサポートします。DPLPMTUDの観点から、QUICは確認応答されたPLとして機能できます。[QUIC]は、QUICパケットでDPLPMTUDを使用する方法を説明しています。
実装上の考慮事項
特定のプロトコルに対してDPLPMTUDを実装する場合:
- 適切なプローブメソッドを選択 - プロトコルの特性に基づいて、最も効率的なプローブパケットタイプを選択します
- 既存のメカニズムを活用 - 可能な限り、組み込みの確認応答およびハートビートメカニズムを使用します
- カプセル化オーバーヘッドを考慮 - 各層でのヘッダーのサイズを正しく計算します
- 状態管理を調整 - PLPMTU状態がプロトコル接続状態と同期することを保証します
- プロトコル固有の制限を処理 - 各プロトコルの固有の制約と要件を考慮します
これらのプロトコル固有の実装ガイドラインにより、DPLPMTUDがさまざまなトランスポートプロトコルと効果的に統合できるようになります。