5.2. Storing PMTU Information (PMTU情報の保存)

理想的には、PMTU値は、送信元ノードと宛先ノードの間でパケットが通過する特定のパスに関連付けられるべきです。しかし、ほとんどの場合、ノードはそのようなパスを完全かつ正確に識別するための十分な情報を持っていません。むしろ、ノードはPMTU値をパスの何らかのローカル表現に関連付けなければなりません。パスのローカル表現を選択することは実装に委ねられています。複数のインターフェースを持つノードの場合、Path MTU情報は各IPv6リンクに対して維持されるべきです (should)。

マルチキャスト宛先アドレスの場合、パケットのコピーは多くの異なるノードに到達するために多くの異なるパスを通過する可能性があります。マルチキャスト宛先への「パス」のローカル表現は、潜在的に大きなパスのセットを表す必要があります。

最小限の実装では、ノードから発信されるすべてのパケットに使用される単一のPMTU値を維持できます。このPMTU値は、ノードが使用するすべてのパスのセット全体で学習された最小PMTUになります。このアプローチは、多くのパスに対して必要以上に小さいパケットの使用につながる可能性があります。マルチパスルーティング (例えば、Equal-Cost Multipath Routing (ECMP))の場合、単一の送信元と宛先のペアに対してもパスのセットが存在する可能性があります。

実装では、宛先アドレスをパスのローカル表現として使用できます。宛先に関連付けられたPMTU値は、その宛先への使用中のすべてのパスのセット全体で学習された最小PMTUになります。このアプローチは、宛先ごとに最適なサイズのパケットの使用につながります。このアプローチは、[ND] で説明されているホストの概念モデルとうまく統合されます。PMTU値は、宛先キャッシュ内の対応するエントリとともに保存できます。

フロー [RFC8200] が使用されている場合、実装ではフローIDをパスのローカル表現として使用できます。特定の宛先に送信されるが、異なるフローに属するパケットは、ECMPと同様に、異なるパスを使用する可能性があり、パスの選択はフローIDに依存する可能性があります。このアプローチは、フローごとに最適なサイズのパケットの使用につながる可能性があり、宛先ごとに維持されるPMTU値よりも細かい粒度を提供します。

送信元ルーティングされたパケット (すなわち、IPv6 Routing header [RFC8200] を含むパケット)の場合、送信元ルートはパスのローカル表現をさらに修飾する可能性があります。

最初は、パスのPMTU値は最初のホップリンクの (既知の)MTUであると仮定されます。

Packet Too Bigメッセージを受信すると、ノードはメッセージの内容に基づいて、メッセージが適用されるパスを決定します。例えば、宛先アドレスがパスのローカル表現として使用される場合、元のパケットからの宛先アドレスが、メッセージが適用されるパスを決定するために使用されます。

注記: 元のパケットにRouting headerが含まれていた場合、Routing headerを使用して、元のパケット内の宛先アドレスの場所を決定する必要があります。Segments Leftがゼロに等しい場合、宛先アドレスはIPv6ヘッダーのDestination Addressフィールドにあります。Segments Leftがゼロより大きい場合、宛先アドレスはRouting header内の最後のアドレス (Address[n])です。

次に、ノードはPacket Too BigメッセージのMTUフィールドの値を暫定PMTU値として、またはそれより大きい場合はIPv6最小リンクMTUを使用し、暫定PMTUを既存のPMTUと比較します。暫定PMTUが既存のPMTU推定値より小さい場合、暫定PMTUはパスのPMTU値として既存のPMTUを置き換えます。

パケット化層は、PMTUの減少について通知される必要があります。パスをアクティブに使用している任意のパケット化層インスタンス (例えば、TCP接続)は、PMTU推定値が減少した場合に通知される必要があります。

注記: Packet Too BigメッセージにUDPパケットを参照するOriginal Packet Headerが含まれている場合でも、その接続が指定されたパスを使用している場合、TCP層に通知される必要があります。

また、Packet Too Bigメッセージを引き出したパケットを送信したインスタンスは、PMTU推定値が変更されていない場合でも、そのパケットが破棄されたことを通知される必要があります。これにより、破棄されたデータを再送信できます。

注記: 実装は、PMTU減少のための非同期通知メカニズムの使用を回避できます。これは、PMTU推定値より大きいパケットを送信する次の試みまで通知を延期することによります。このアプローチでは、PMTU推定値より大きいパケットを送信しようとする試みが行われた場合、SEND関数は失敗し、適切なエラー表示を返すべきです。このアプローチは、コネクションレスのパケット化層 (UDPを使用するものなど)により適している可能性があります。これは、(一部の実装では)ICMPv6層から「通知」することが困難な場合があります。この場合、通常のタイムアウトベースの再送信メカニズムが、破棄されたパケットから回復するために使用されます。

パスを使用しているパケット化層インスタンスへのPMTUの変化の通知と、パケットが破棄されたことの特定のインスタンスへの通知が異なることを理解することが重要です。後者は、できるだけ早く (すなわち、パケット化層インスタンスの視点から非同期的に)行われるべきです。一方、前者は、パケット化層インスタンスがパケットを作成したいときまで遅延させることができます。