パスMTU検出
パスMTUD（PMTUD ）は、コンピュータネットワークにおける標準化された技術であり、2つのインターネットプロトコル（IP）ホスト間のネットワークパス上の最大転送単位（MTU）サイズを決定するもので、通常はIPフラグメンテーションを回避することを目的としています。PMTUDはもともとインターネットプロトコルバージョン4（IPv4）のルーター向けに設計されました。 [ 1 ]しかし、最近のオペレーティングシステムはすべてエンドポイントでPMTUDを使用しています。IPv6では、この機能は通信セッションのエンドポイントに明示的に委任されています。[ 2 ] 標準パスMTU検出の拡張として、パケット化層パスMTU検出と呼ばれる技術がICMPのサポートなしで動作します。[ 3 ]
実装
IPv4パケットの場合、パスMTUディスカバリは、送信パケットのIPヘッダーにDon't Fragment （DF）フラグビットを設定することで機能します。すると、パス上のデバイスのうち、パケットのMTUよりも小さいMTUを持つデバイスは、そのパケットを破棄し、そのMTUを含むインターネット制御メッセージプロトコル（ICMP）のFragmentation Needed（タイプ3、コード4）メッセージを返送します。これにより、送信元ホストはパスMTUを適切に削減できます。このプロセスは、MTUが十分に小さくなり、パス全体を断片化せずに通過できるようになるまで繰り返されます。
IPv6ルーターはパケットを断片化しないため、 IPv6ヘッダーには「Don't Fragment」オプションはありません。IPv6では、パスMTU検出は、最初にパスMTUがトラフィックの送信元となるリンク層インターフェースのMTUと同じであると想定して機能します。その後、IPv4と同様に、パス上のデバイスのうち、パケットのMTUよりも小さいMTUを持つデバイスは、パケットを破棄し、そのMTUを含むICMPv6 Packet Too Big (Type 2)メッセージを返送します。これにより、送信元ホストはパスMTUを適切に削減できます。このプロセスは、MTUが十分に小さくなり、断片化せずにパス全体を通過できるようになるまで繰り返されます。[ 4 ]
接続確立後にパスMTUが変更され、以前に決定されたパスMTUよりも小さくなった場合、最初の大きなパケットはICMPエラーを引き起こし、新しい、より小さいパスMTUが見つかります。パスが変更され、新しいパスMTUが大きくなった場合、送信元は増加を認識しません。これは、新しいパス上のすべてのルーターが、送信元が最初に決定したより小さいパスMTUを使用して送信するすべてのパケットを中継できるためです。[ 5 ] [ 6 ] [ 4 ]
問題
多くのネットワークセキュリティデバイスは、セキュリティ上の利点を理由に、PMTUDの適切な動作に必要なエラーを含むすべてのICMPメッセージをブロックします。その結果、TCPの3ウェイハンドシェイクは正常に完了しても、データ転送を試みると接続がハングアップすることがあります。この状態はブラックホール接続と呼ばれます。[ 7 ]
PMTUDの実装の中には、大きなペイロードパケットがリンク輻輳ではなくMTUのせいでドロップされたと推測することでこの問題を回避しようとするものがあります。そのような仕組みの1つがRFC 8899「データグラムパケット化層パスMTU探索（DPLPMTUD）」で標準化されています。[ 3 ]接続が失われると、DPLPMTUDは制御されたサイズのプローブパケットを使用してパスのMTUを調べます。プローブパケットの確認応答は、パスMTUが少なくともそのパケットのサイズであることを示します。DPLPMTUDの使用法はQUICで標準化されています。[ 8 ]ただし、トランスポート層プロトコルが最も効率的に動作するためには、ICMP到達不能メッセージ（タイプ3）を許可する必要があります。
Linuxカーネル[ 9 ]やCisco [ 10 ]などの一部のルータでは、回避策としてTCPハンドシェイクで通知される最大セグメントサイズ（MSS）を減らすオプションを提供しています。これはMSSクランプとして知られています。
隣接する2つのレイヤー3ホップ間のリンクが複数のレイヤー2セグメントで構成され、その間にスイッチが介在している場合、ネットワーク管理者がそれらのホップ間のMTUを適切に更新しないと、別の問題が発生します。通常、送信L3インターフェースのMTUは最初のL2セグメントから取得されます。しかし、2番目以降のセグメントのMTUがそれよりも低い場合、その間にあるスイッチはICMPを報告せずにパケットを破棄します（レイヤー3ホップのみがICMPの「パケットが大きすぎる」というメッセージを生成するため）。この場合、管理者は各送信L3インターフェースのMTUを、次のL3ホップまで使用されるレイヤー2セグメントの最小MTUに更新する必要があります。[ 11 ]
参考文献
- ^ J. Mogul; S. Deering (1990年11月).パスMTU検出. ネットワークワーキンググループ. doi : 10.17487/RFC1191 . RFC 1191 .ドラフト標準。 RFC 1063 は廃止されます。
- ^ J. McCann; S. Deering ; J. Mogul (2017年7月). R. Hinden (編). IPバージョン6のパスMTU検出.インターネット技術タスクフォース. doi : 10.17487/RFC8201 . STD 87. RFC 8201 .インターネット標準 87。RFC 1981 は 廃止されます。
- ^ a b G. Fairhurst; T. Jones; M. Tüxen; I. Rüngeler; T. Völker (2020年9月).データグラムトランスポートにおけるパケット化層パスMTU検出.インターネット技術タスクフォース. doi : 10.17487/RFC8899 . ISSN 2070-1721 . RFC 8899 . 提案された標準。RFC 4821、4960、6951、8085、8261 を更新し ます。
- ^ a bデイヴィス、ジョセフ (2012). 『IPv6を理解する』（第3版）. レドモンド: マイクロソフト・プレス. pp. 146– 147. ISBN 978-0735659148. OCLC 810455372 .
- ^ E. Comer, Douglas (2014). Internetworking with TCP/IP Volume 1 (6th ed.). Pearson. pp. 133– 134. ISBN 978-0-13-608530-0。
- ^ Linuxソースコード（IPv4）およびLinuxソースコード（IPv6）の「mtu_expires」の行を参照（10 * 60秒）
- ^ K. Lahey (2000年9月). TCPにおけるパスMTU探索の問題. ネットワークワーキンググループ. doi : 10.17487/RFC2923 . RFC 2923 .情報提供。
- ^ J. Iyengar、M . Thomson編（2021年5月）。QUIC ：UDPベースの多重化および安全なトランスポート。インターネット技術タスクフォース。doi ：10.17487/ RFC9000。ISSN 2070-1721。RFC 9000。 提案された標準。
- ^ 「パケットヘッダーのマングリング - nftables wiki」 . wiki.nftables.org . 2024年7月3日閲覧。
- ^ 「PPPoE接続におけるイーサネットMTUとTCP MSSの調整コンセプト」 Cisco . 2024年7月3日閲覧。
- ^
