8. パスMTU/DF処理 (Path MTU/DF Processing)
アウトバウンドパケットへのAHまたはESPの適用は、パケットのサイズを増加させ、したがってパケットが通過するSAのPMTUを超える可能性があります。IPsec実装は、保護されていないICMP PMTUメッセージを受信する場合もあり、メッセージに基づいて行動することを選択した場合、その結果はアウトバウンドトラフィック処理に影響します。
8.1. DFビット (DF Bit)
トンネルモードSAを介してトラフィックが運ばれる場合、すべてのIPsec実装は、アウトバウンドパケットからDFビットをそれが発行するトンネルモードヘッダーにコピーするオプションをサポートしなければなりません(MUST)。これは、各SAについてDFビットの実装の処理(設定、クリア、内部ヘッダーからコピー)を構成できなければならない(MUST)ことを意味します。
8.2. パスMTU (PMTU)発見 (Path MTU Discovery)
このセクションでは、保護されていないパスMTU発見メッセージのIPsec処理について説明します。
IPv4 (RFC 792 [Pos81b]):
- Type = 3 (宛先到達不可能)
- Code = 4 (フラグメンテーションが必要でDFが設定されている)
- ICMPヘッダーの2番目のワードの下位16ビットの次ホップMTU
IPv6 (RFC 2463 [CD98]):
- Type = 2 (パケットが大きすぎる)
- Code = 0 (フラグメンテーションが必要)
- ICMP6メッセージの32ビットMTUフィールドの次ホップMTU
8.2.1. PMTUの伝播 (Propagation of PMTU)
IPsec実装が認証されていないPMTUメッセージを受信し、そのようなメッセージを処理する(無視するのではなく)ように構成されている場合、それは対応するSAにメッセージをマップします。このマッピングは、PMTUメッセージのペイロードからヘッダー情報を抽出し、セクション5.2で説明されている手順を適用することによって実現されます。
アウトバウンドトラフィックがSADエントリにマップされるのを待つべきです(SHOULD)。そのようなトラフィックが到着したとき、トラフィックが更新されたPMTU値を超える場合、トラフィックは次のように処理されなければなりません(MUST):
ケース1: 元の(平文)パケットがIPv4でDFビットが設定されている。実装はパケットを破棄し、PMTU ICMPメッセージを送信すべきです(SHOULD)。
ケース2: 元の(平文)パケットがIPv4でDFビットがクリアされている。実装は(構成に従って暗号化の前または後に)フラグメント化し、フラグメントを転送すべきです(SHOULD)。
ケース3: 元の(平文)パケットがIPv6である。実装はパケットを破棄し、PMTU ICMPメッセージを送信すべきです(SHOULD)。
8.2.2. PMTUエージング (PMTU Aging)
すべてのIPsec実装において、SAに関連付けられたPMTUは「エージング」されなければならず(MUST)、特に現在のネットワーク条件で必要とされるよりもPMTUが小さいかどうかを発見するために、PMTUをタイムリーに更新するメカニズムが必要です。
実装は、パスMTU発見ドキュメント(RFC 1191 [MD90]、セクション6.3)で説明されているアプローチを使用すべきです(SHOULD)。これは、PMTUを定期的に最初のホップデータリンクMTUにリセットし、その後通常のPMTU発見プロセスが必要に応じてPMTUを更新することを提案しています。
関連セクション: