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

1. はじめに

IETFは、UDP、ストリーム制御伝送プロトコル (Stream Control Transmission Protocol, SCTP)、およびデータグラム輻輳制御プロトコル (Datagram Congestion Control Protocol, DCCP) を使用したデータグラム転送、ならびにこれらのトランスポートの上に階層化されたプロトコル (例: SCTP/UDP、DCCP/UDP、QUIC/UDP) およびIPネットワーク層上の直接データグラム転送を規定しています。この文書は、これらのトランスポートプロトコル (またはそのトランスポートサービスを使用するアプリケーション) と共に使用できる、インターネットパス上で使用する適切なパケットサイズを発見するための堅牢な経路MTU発見 (Path MTU Discovery, PMTUD) 方法を説明します。

1.1. 古典的経路MTU発見 (Classical Path MTU Discovery)​

古典的経路最大伝送単位発見 (Classical Path Maximum Transmission Unit Discovery, PMTUD) は、ICMPパケット過大 (Packet Too Big, PTB) メッセージを処理できる任意のトランスポートで使用できます (例: [RFC1191]および[RFC8201])。この文書では、PTBメッセージという用語は、フラグメンテーション必要 (Fragmentation Needed) エラー (タイプ3、コード4) [RFC0792]を伝送するIPv4 ICMP到達不能メッセージ (タイプ3) とICMPv6パケット過大メッセージ (タイプ2) [RFC4443]の両方に適用されます。送信者がPTBメッセージを受信すると、有効MTUをPTBメッセージ内のリンクMTUとして報告された値に削減します。古典的PMTUDは、サポートされるPMTUの増加を発見するために、定期的にパケットサイズを増加させる方法を規定しています。現在の有効PMTUより大きいサイズで送信されるパケットは、プローブパケットとして知られています。

プローブパケットとして意図されていないパケットは、現在の有効PMTUにフラグメント化されるか、送信の試みがエラーコードで失敗します。アプリケーションには、現在の有効PMTUから派生した最大パケットサイズ (Maximum Packet Size, MPS) を読み取るプリミティブを提供できます。

古典的PMTUDは、プロトコルの失敗の対象となります。1つの失敗は、実際のPMTUより大きいパケットサイズを使用するトラフィックがブラックホール化される場合に発生します (実際のPMTUより大きいすべてのデータグラムが破棄されます)。これは、何らかの理由でPTBメッセージが送信者に返送されない場合に発生する可能性があります (例: [RFC2923]参照)。

PTBメッセージが配信されない例には、以下が含まれます:

  • ICMPメッセージの生成は通常レート制限されます。これにより、送信者にPTBメッセージが生成されない可能性があります ([RFC4443]セクション2.4参照)。

  • ICMPメッセージは、ファイアウォール[RFC4890]を含むミドルボックスによってフィルタリングされる可能性があります。ファイアウォールは、着信ICMPメッセージをブロックするポリシーで設定される可能性があり、このファイアウォールの背後にある送信エンドポイントによるPTBメッセージの受信を防ぎます。

  • ICMPメッセージを発行するルーターがトンネル化されたパケットをドロップすると、結果として生成されるICMPメッセージはトンネル入口に向けられます。このトンネルエンドポイントは、ICMPメッセージを転送し、ペイロードフィールド内の引用パケットを処理してトンネルの影響を除去し、正しくフォーマットされたICMPメッセージを送信者に返す責任があります[TUNNELS]。これを行わないと、PTBメッセージが元の送信者に到達しません。

  • 転送の非対称性により、元の送信者への復路がない可能性があり、ICMPメッセージが送信者に配信されません。この問題は、ポリシーベースまたは等コストマルチパス (Equal-Cost Multipath, ECMP) ルーティングが使用される場合、またはミドルボックスがアプリケーションロードバランサーとして機能する場合にも発生する可能性があります。その一例は、ECMPルーターがIPペイロード内のバイトに基づいてサーバーへのパスを選択することです。この場合、サーバーによって送信されたパケットがECMPルーター後に問題に遭遇した場合、ECMPルーターは結果として生じるICMPメッセージを元の送信者に向ける必要があります。

  • ネクストホップ宛先がそのサイズのためにパケットを受信できない追加のケースがあります。これは、ノード間のレイヤ2パスの設定ミス、例えばレイヤ2スイッチで設定されたMTU、または最大受信単位 (Maximum Receive Unit, MRU) の設定ミスが原因である可能性があります。パケットがリンクによってドロップされた場合、これは元の送信者にPTBメッセージを送信させません。

ネットワークパス上にないノードが、送信者に有効PMTUを変更させようとするPTBメッセージを送信する場合、別の失敗が発生する可能性があります[RFC8201]。送信者は、PTBメッセージペイロード内の引用パケットを利用して、受信したPTBメッセージが実際に送信者から発信されたパケットに応答して生成されたことを検証することで、そのようなメッセージへの反応から自身を保護できます。ただし、送信者がこの検証を提供できない状況があります。

PTBメッセージの検証が不可能な例には、以下が含まれます:

  • ICMPメッセージを発行するルーターがRFC 792 [RFC0792]を実装している場合、引用ペイロード内にパケットのIPペイロードの最初の64ビットのみを含めることが要求されます。送信者が引用トランスポート情報を解釈するために残りのバイトが不足している可能性があります。

    注: RFC 1812 [RFC1812]の推奨事項は、IPv4ルーターが、ICMPデータグラムの長さが576バイトを超えないように、元のデータグラムの可能な限り多くの引用パケットを返すことです。IPv6ルーターは、ICMPv6パケットが1280バイトを超えないように、可能な限り多くの呼び出しパケットを含めます[RFC4443]。

  • トンネルおよび/または暗号化の使用は、元のソースアドレスに返される引用パケットのサイズを削減し、送信者が引用トランスポート情報を解釈するために残りのバイトが不足するリスクを高める可能性があります。

  • PTBメッセージに引用パケットの十分なバイトが含まれている場合でも、検証がエンドポイントノードでのアクティブなトランスポートフローに関する情報 (使用されているソケット/アドレスペアやその他のプロトコルヘッダー情報など) に依存するため、ネットワーク層がメッセージを検証するための十分なコンテキストを欠いている可能性があります。

  • パケットが暗号化されたトランスポート上でカプセル化/トンネル化されている場合、トンネル/カプセル化入口は、検証の実行に必要なトランスポートヘッダーを再構築するための十分なコンテキストまたは計算能力を持たない可能性があります。

  • パケットにヘッダーを挿入したネットワークセグメント内のルーターによってICMPメッセージが生成される場合、引用パケットには、元の送信パケットに含まれておらず、PL送信者が処理しない、または処理方法を知らない可能性のある追加のプロトコルヘッダー情報が含まれている可能性があります。これにより、送信者がこのPTBメッセージを検証する能力が妨げられる可能性があります。

  • パケットヘッダーを変換するネットワークアドレス変換 (Network Address Translation, NAT) デバイスは、ICMPメッセージも変換し、そのメッセージ内のICMP引用パケットを更新する必要があります[RFC5508]。これが正しく変換されていない場合、送信者はメッセージをパケットを発信したPLに関連付けることができず、したがってこのICMPメッセージは検証できません。

1.2. パケット化層経路MTU発見 (Packetization Layer Path MTU Discovery)​

パケット化層 (Packetization Layer, PL) という用語は、データブロックをIPパケットのペイロードに配置し、適切なMPSを選択する責任を持つ層を説明するために導入されました。この機能は、トランスポートプロトコル (例: DCCP、RTP、SCTP、QUIC) によって実行されることが多いですが、トランスポート層の上で動作する他のカプセル化方法によっても実行できます。

PMTUDとは対照的に、パケット化層経路MTU発見 (Packetization Layer Path MTU Discovery, PLPMTUD) [RFC4821]は、PTBメッセージの受信と検証に依存しない方法を導入します。したがって、古典的PMTUDよりも堅牢です。これは、PMTUの発見を実装するための推奨アプローチになっています[BCP145]。

この文書は、[RFC4821]を更新して、データグラムPLのPLPMTUD方法を指定し、また[BCP145]を更新して、[RFC4821]の方法ではなく、この文書で指定された方法をUDPデータグラムで使用するように参照します。

PLがプローブパケットを送信して、ネットワークパス上で送信できるフラグメント化されていないデータグラムの最大サイズを検索する一般的な戦略を使用します。プローブパケットは、より大きいパケットサイズを使用して探索するために送信されます。プローブパケットが正常に配信された場合 (PLによって決定される)、PLPMTUは成功したプローブのサイズに引き上げられます。ブラックホールが検出された場合 (例: PLPMTUのサイズのパケットが一貫して受信されない)、方法はPLPMTUを削減します。

データグラムPLPMTUDは、実装の柔軟性を導入します。一方の極端では、古典的PMTUDと比較して堅牢性を高めたブラックホール検出と回復のみを実行するように設定できます。もう一方の極端では、すべてのPTB処理を無効にし、PLPMTUDが古典的PMTUDに取って代わります。

PLPMTUDには、経路MTUを発見するためのプローブ時にデータが失われるリスクを増加させることなく、追加の整合性チェックを含めることもできます。例えば、PLまたは上位層で利用可能な情報により、受信したPTBメッセージを利用する前に検証できます。

1.3. データグラムサービスの経路MTU発見 (Path MTU Discovery for Datagram Services)​

この文書のセクション5は、データグラムプロトコルがネットワークパス上で送信できるフラグメント化されていないデータグラムの最大サイズを発見するためのアルゴリズムセットを提示します。この方法は、セクション3で説明されているPLの機能に依存し、IPv4およびIPv6上で動作するトランスポートプロトコルに適用されます。下位層からの協力は必要ありませんが、これらの受信メッセージがPLに提供される場合、PTBメッセージを利用できます。

UDP使用ガイドライン[BCP145]のセクション3.2のメッセージサイズガイドラインは、「アプリケーションはIP層によって提供される経路MTU情報を使用するか、経路MTU発見 (PMTUD) を実装すべきである (SHOULD)」と述べていますが、ネットワークパス上で使用できるフラグメント化されていないデータグラムの最大サイズを発見するメカニズムを提供していません。本文書は、PLPMTUD [RFC4821]の代わりにこの方法を指定するようにRFC 8085を更新し、発見された最大サイズをMPSとして共有するメカニズムを提供します (セクション4.4参照)。

[RFC4821]セクション10.2は、ストリーム制御伝送プロトコル (Stream Control Transmission Protocol, SCTP) のPLPMTUDプローブ方法を推奨しました。SCTPは、[RFC4820]で定義されている最小サイズのHEARTBEATチャンクとPADチャンクをバンドルしたプローブパケットを利用します。ただし、RFC 4821は完全な仕様を提供していませんでした。本文書は、完全な仕様を提供することにより、その説明を置き換えます。

データグラム輻輳制御プロトコル (Datagram Congestion Control Protocol, DCCP) [RFC4340]は、実装が古典的PMTUDをサポートすることを要求し、DCCP送信者が「各アクティブなDCCPセッションで許可されるMPSを維持しなければならない (MUST)」と述べています。また、ネットワークパスでサポートされる現在の輻輳制御MPS (Current Congestion Control MPS, CCMPS) を定義します。これは、PMTUDの使用を推奨し、アプリケーションデータの損失をリスクにさらさないため、制御パケット (DCCP-Sync) をパスプローブパケットとして使用することを提案しています。この仕様で定義された方法は、DCCPで使用できます。

セクション4およびセクション5は、データグラムパケット化層経路MTU発見 (Datagram Packetization Layer Path MTU Discovery, DPLPMTUD) のプロトコルメカニズムと仕様を定義します。

セクション6は、データグラムトランスポートの方法を指定し、データグラムトランスポートを使用する他のデータグラムトランスポートおよびアプリケーションでPLPMTUDを実装できるようにする情報を提供します。

セクション6は、SCTPエンドポイントの推奨事項も提供し、[RFC4821]の方法ではなく、この文書で指定された方法を使用するように[RFC4960]、[RFC6951]、および[RFC8261]を更新します。

に最終更新