4. DPLPMTUDメカニズム

このセクションは、この仕様で使用されるプロトコルメカニズムをリストします。

4.1. PLPMTUプローブパケット

DPLPMTUD方法は、PL送信者が特定のサイズのプローブパケットを生成できることに依存しています。TCPは、送信されるデータの適切なセグメントを選択することにより、これらのプローブパケットを生成できます[RFC4821]。対照的に、プローブパケットを構築するデータグラムPLは、アプリケーションによって生成されたものより大きいデータブロックの送信をアプリケーションに要求するか、パディング機能を利用してアプリケーションデータブロックのサイズを超えてデータグラムを拡張する必要があります。制御メッセージ（アプリケーションデータブロックなし）の交換を許可するプロトコルは、制御メッセージをパディングデータで拡張することによりプローブパケットを生成できます。プローブパケットの合計サイズには、送信されるペイロードデータに追加されたすべてのヘッダーとパディングが含まれます（プロトコルオプションフィールド、AEADタグやTLSレコード層パディングなどのセキュリティ関連フィールドを含む）。

必須: 受信者は、インバンドデータブロックと追加されたパディングを区別できる必要があります。これは、追加されたパディングが受信アプリケーションに渡されないことを保証するために必要です。

プローブパケットを作成する3つの方法

1. パディングデータを使用したプローブ

プローブパケットのサイズまでデータグラムの長さを膨張させるために必要なパディングと共に制御情報のみを含むプローブパケット。これらのプローブパケットはアプリケーション提供のデータブロックを運ばないため、通常は再送信を必要としませんが、ネットワーク容量を消費し、エンドポイント処理を発生させます。

2. アプリケーションデータとパディングデータを使用したプローブ

アプリケーションによって提供されたデータブロックを含み、プローブパケットのサイズまでデータグラムの長さを膨張させるためにパディングと組み合わされたプローブパケット。

3. アプリケーションデータを使用したプローブ

プローブパケットのサイズに一致するアプリケーションによって提供されたデータブロックを含むプローブパケット。この方法は、アプリケーションに希望するプローブサイズのデータブロックを発行するよう要求します。

プローブパケットの保護

このプローブパケットの損失に対して耐性が必要なアプリケーションデータを運ぶプローブパケットを使用するPLは、データブロックのトランスポート層再送信/修復を実行できます（例：損失が検出された後の再送信、またはパディングデータなしでデータグラム内のデータブロックを複製することにより）。この再送信されたデータブロックは、より小さいPLPMTUを使用して送信する必要がある場合があり、これによりPLはエンドツーエンドパスを横断するためにより小さいパケットサイズを使用することを強制される可能性があります（これは、エンドポイントネットワーク層フラグメンテーションを利用するか、PLによってデータブロックを複数のデータグラムにセグメント化する可能性があります）。

DPLPMTUDは、実装を簡素化するためにこれらの方法の1つのみを使用することを選択してもよいです (MAY)。

プローブパケットの識別

PLによって送信されるプローブメッセージは、最大セグメント寿命内でプローブを一意に識別するのに十分な情報を含まなければならず (MUST)（PLまたはDPLPMTUD実装からの一意の識別子を含む）、プローブ応答とPTBメッセージの並べ替えと再生に対して堅牢でなければなりません。

4.2. プローブされたパケットサイズの確認

PLは、プローブパケットがネットワークパス全体でエンドツーエンドで正常に受信されたときを判断（確認）する方法を必要とします。

トランスポートプロトコルには、送信する特定のデータグラムの受信を検出して報告するエンドツーエンド方法を含めることができます（例：DCCP、SCTP、およびQUICはキープアライブ/ハートビート機能を提供します）。サポートされている場合、このメカニズムもプローブパケットの受信を確認するためにDPLPMTUDによって使用されてもよいです (MAY)。

データ受信を確認しないPL（例：UDPおよびUDP-Lite）は、そのサイズが実際のPMTUより大きいために送信したパケットが破棄されたときを自身で検出できません。これらのPLは、この損失を検出するためにアプリケーションプロトコルに依存する必要があります。

セクション6は、IETF指定プロトコルのセットに対してこの機能を指定しています。

4.3. ブラックホール検出とPLPMTUの削減

以下の説明は、セクション5.1.2で定義されている定数セットとセクション5.1.3で定義されている変数を使用します。

ブラックホール検出は、ネットワークパスが現在のPLPMTUサイズをサポートできない可能性があることを示す兆候によってトリガーされます。

3つのブラックホール検出指標

1. PTBメッセージ指標

現在のPLPMTUより小さいPL_PTB_SIZEを示す検証されたPTBメッセージを受信できます。DPLPMTUD方法は、この方法のみに依存してはなりません (MUST NOT)。

2. 定期的プローブ

PLは、DPLPMTUDプローブメカニズムを使用して、現在のPLPMTUサイズのプローブパケットを定期的に生成できます（例：CONFIRMATION_TIMERを使用、セクション5.1.1）。タイマーは、確認応答が受信されるかどうかを追跡します。連続したプローブの損失は、現在のパスがPLPMTUをもはやサポートしていないことの兆候です（例：確認応答を受信せずに送信されたプローブパケットの数PROBE_COUNTがMAX_PROBESより大きくなる場合）。

3. PLイベント指標

PLは、ネットワークパスが送信者のPLPMTUサイズをもはやサポートしていないことを示すイベントを利用できます。これは、特定のパケットサイズで送信されたデータの過度の損失を検出するためにPL内に実装されたメカニズムを使用して検出でき、次にこの過度の損失が無効なPLPMTUの結果である可能性があることを推定できます（TCPのPLPMTUDの場合[RFC4821]）。

プローブパターンの違い

これら3つの方法は、プローブとして使用されるパケットに対して異なる送信パターンをもたらす可能性があり、実際のPMTU変更後に異なる応答性をもたらすことが期待されます。

プローブ抑制

MAY: PLは、最後のプローブパケット以降にアプリケーションがデータを送信していない場合、プローブパケットの送信を抑制できます。

ユーザーデータの送信を再開するPLは、各パスに対してPLPMTU発見を引き続き使用してもよいです (MAY)。これにより、最新のPLPMTUを使用できます。ただし、これにより追加のパケットが送信される可能性があります。

PLPMTUの削減

方法が現在のPLPMTUがサポートされていないことを検出すると、DPLPMTUDはより低いPLPMTUとより低いMPSを設定します。次にPLは、新しいPLPMTUがパスに対して正常に使用できることを確認します。プローブパケットは、アプリケーションによって生成されたデータブロックのサイズより小さくする必要がある場合があります。

4.4. 最大パケットサイズ (MPS)

プローブの結果は、利用可能なPLPMTUを決定し、これはアプリケーションによって使用されるMPSを設定するために使用されます。MPSは、PLヘッダーのサイズ（AEADタグやTLSレコード層パディングなどのセキュリティ関連フィールドのオーバーヘッドを含む）によって削減されるため、PLPMTUより小さくなります。

MPSとPLPMTUの関係

|<----- PLPMTU ----->|
|<-- MPS -->|  PLヘッダー  |  IPヘッダー  |
| アプリデータ | トランスポート | セキュリティ | ネットワーク |

PLは、現在のPLPMTUより大きいネットワーク層でのサイズを持つパケット（プローブパケット以外）を送信できません。これを回避するために、PLはMPSより大きいデータブロックを複数のデータグラムにセグメント化するように設計されてもよいです (MAY)。

DPLPMTUDは、IPフラグメンテーションを回避しようとします。PLがデータをセグメント化できない場合、MPSより大きいデータブロックを送信する試みは失敗します。送信できる最大のデータブロックを決定するために、PLは、現在のPLPMTUから派生したMPSを返すプリミティブをアプリケーションに提供すべきです (SHOULD)。

MPS変更の処理

DPLPMTUDがMPSの変更をもたらす場合、アプリケーションは新しいMPSに適応する必要があります。特定のケースは、パケットがMPSより小さいサイズで送信され、その後PLPMTUが削減される場合に発生する可能性があります。これらのパケットが失われた場合、PLは新しいMPSを使用してデータをセグメント化してもよいです (MAY)。

PLが以前に送信されたデータグラムを再セグメント化できない場合（例：[RFC4960]）、送信者はデータグラムを破棄するか、ネットワーク層フラグメンテーションを使用してPLPMTUより大きくない複数のIPパケットを形成する再送信を実行できます。IPv4の場合、送信者はIPv4ヘッダーのDFビットをクリアするよりも、エンドポイントフラグメンテーションを使用します。運用経験は、IPフラグメンテーションがインターネット通信の信頼性を低下させる可能性があることを示しており[RFC8900]、これは再送信の成功確率を低下させる可能性があります。

4.5. PMTUDの効果の無効化

この仕様を実装するPLは、DPLPMTUDを使用する各フローに対して発信パケットのネットワーク層処理のためのPMTU[RFC1191][RFC8201]の強制を中断し (MUST)、代わりにDPLPMTUDを使用してフローが送信するパケットのサイズを制御しなければなりません。これにより、ネットワーク層がPMTUより大きいサイズの送信パケットをドロップまたはフラグメント化する必要性が排除されます。

4.6. PTBメッセージへの応答

この方法は、DPLPMTUD送信者がPTB情報を使用する前に受信したPTBメッセージを検証することを要求します。PTBメッセージへの応答は、PTBメッセージのPTB_SIZEから計算されたPL_PTB_SIZE、PLPMTUDステートマシンの状態、および使用中のIPプロトコルに依存します。

セクション4.6.1は、IPv4 ICMP到達不能メッセージ（タイプ3）とICMPv6パケット過大メッセージの両方の検証を説明しており、両方ともこの文書ではPTBメッセージと呼ばれます。

4.6.1. PTBメッセージの検証

このセクションは、PTBメッセージの利用と検証を指定します。

実装オプション

• シンプルな実装: 受信したPTBメッセージを無視してもよく (MAY)、この場合、PTBメッセージが受信されたときにPLPMTUは更新されません。

• PTBをサポートするPL: これらのメッセージをさらに処理する前に検証しなければなりません (MUST)。

検証プロセス

ルーターまたはミドルボックスからPTBメッセージを受信するPLは、ICMP検証を実行します（[RFC8201]のセクション4および[BCP145]のセクション5.2を参照）。DPLPMTUDはPLで動作するため、PLは受信した各PTBメッセージをチェックして、DPLPMTUDを実行しているエンドポイントPLによって発信されたパケットに応答して受信されたかどうかを判断する必要があります。

PLは、ICMP PTBメッセージペイロードに運ばれる引用パケット内のプロトコル情報をチェックして、メッセージが送信ノードから発信されたことを検証しなければなりません (MUST)。この検証には、引用パケットで返されるIPアドレス、プロトコル、ソースポート、および宛先ポートの組み合わせが一致することの判断が含まれます -- これは、PTBメッセージが対応するPLに渡されるためにも必要です。

検証は、パス外攻撃者が容易に利用できない情報を利用すべきです (SHOULD)[BCP145]。例えば、2つのPLエンドポイントにのみ知られているプロトコルヘッダーフィールドの値をチェックできます。よく知られたソースおよび宛先ポートを使用するデータグラムアプリケーションは、この検証を完了するために他の情報にも依存すべきです。

これらのチェックは、ネットワークパス上にないノードから発信されたパケットからの保護を提供することを目的としています。検証を完了していないPTBメッセージは、セキュリティに関する考慮事項セクション（セクション8）で説明されているように、DPLPMTUD方法によってさらに利用してはなりません (MUST NOT)。

セクション4.6.2は、PTBメッセージの処理を説明しています。

4.6.2. PTBメッセージの使用

検証されたPTBメッセージはDPLPMTUDアルゴリズムによって利用されてもよいですが (MAY)、PLPMTUを直接設定するために使用してはなりません (MUST NOT)。

PTBメッセージで報告されたサイズを使用する前に、まずPL_PTB_SIZEに変換する必要があります。PL_PTB_SIZEは、PLパケットに追加されたIPオプションまたは拡張を含む、PLの下のヘッダーによって削減されるため、PTB_SIZEより小さくなります。

これらのPTBメッセージを利用する方法は、タイマーベースの検索アルゴリズムのみに依存する方法と比較して、PL_PTB_SIZE（ネットワーク層パケットサイズがPTB_SIZEになる）に対する即時プローブをトリガーすることにより、アルゴリズムが適切なPLPMTUを検出する速度を改善できます。

一連のチェックは、予期しないPTB_SIZEを報告するルーターからの保護を提供することを目的としています。PLは、示されたPL_PTB_SIZEがプローブパケットによって使用されるサイズより小さく、少なくとも最小受け入れサイズであることもチェックする必要があります。

PTBメッセージ処理の要約

このセクションは、セクション5.1.2で定義されている定数セットを使用して、PTBメッセージがどのように利用されるかの要約を提供します。この処理は、PL_PTB_SIZEと変数セットの現在の値に依存します:

PL_PTB_SIZE < MIN_PLPMTU

• 無効なPL_PTB_SIZE、セクション4.6.1参照
• PTBメッセージは、さらなる処理なしで破棄されるべきです（すなわち、PLPMTUは変更されません）
• この情報は、レジリエンスモードを有効にするトリガーとなる入力として利用される可能性があります（セクション5.3.3参照）

MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU

• 堅牢なPLは、PTBメッセージで報告されたPL_PTB_SIZEが68バイト以上[RFC0791]でBASE_PLPMTU未満の場合、IPv4パスのエラー状態に入ってもよいです (MAY)（セクション5.2参照）
• 堅牢なPLは、PTBメッセージで報告されたPL_PTB_SIZEが1280バイト以上[RFC8200]でBASE_PLPMTU未満の場合、IPv6パスのエラー状態に入ってもよいです (MAY)（セクション5.2参照）

BASE_PLPMTU <= PL_PTB_SIZE < PLPMTU

• これはブラックホールの兆候である可能性があります。PLPMTUはBASE_PLPMTUに設定されるべきです (SHOULD)（ブラックホールに遭遇したときの不必要なパケット損失を避けるためにPLPMTUがBASE_PLPMTUに削減されます）
• PLは、新しいPLPMTUを迅速に発見するための検索を開始すべきです。PTBメッセージで報告されたPL_PTB_SIZEは、検索アルゴリズムを初期化するために使用できます

PLPMTU < PL_PTB_SIZE < PROBED_SIZE

• PLPMTUは引き続き有効ですが、検索に使用されるサイズ（PROBED_SIZE）は実際のPMTUより大きいです
• PLPMTUは更新されません
• 検索アルゴリズムを再開するとき、PLはPTBメッセージで報告されたPL_PTB_SIZEを次の検索ポイントとして使用できます

PL_PTB_SIZE >= PROBED_SIZE

• 一貫性のないネットワーク信号
• PTBメッセージは、さらなる処理なしで破棄されるべきです（すなわち、PLPMTUは変更されません）
• この情報は、レジリエンスモードを有効にするトリガーとなる入力として利用される可能性があります

これらのメカニズムは一緒になって、DPLPMTUDが適切な経路MTUを確実に発見して維持できることを保証します。