要約

  • 正の確認が証明するのは、識別されたプローブが、その大きさで、その時に使った経路を通り、遠端のパケット化層へ届いたことである。
  • RFC 8201 は経路 MTU を変化する状態として扱い、RFC 8899 は再確認と、マルチパスまたはマルチホーミング時の経路別状態を求める。
  • 運用上の受領証には、端点、フローまたは経路識別子、カプセル化の負担、フィードバック、時刻、実データの配送結果が必要になる。

正しい観測でも範囲を誤れば危険になる

データグラムサービスが 1,450 バイトに埋めたプローブを送り、受信側がそのプローブを確認したとする。送信側は PLPMTU を引き上げる。その直後、同じ大きさのアプリケーションデータが別の ECMP メンバーへ送られる。そこではトンネルヘッダーが大きいか、途中のリンク MTU が小さく、パケットが通らない。

最初の結果は覆らない。特定の一パケットが特定時点の実経路で届いたという証拠である。しかし、並行する全メンバーや経路変更後まで測ったわけではない。「MTU 合格」という一つの表示にすると、プローブ ID、フローキー、経路世代、ヘッダー量、確認からの経過時間が失われる。

IPv6 PMTUD が保持するのは推定値

RFC 8201 は、送信元と宛先の間にあるリンク MTU の最小値を経路 MTU と定義する。送信元は最初のリンク MTUから始め、対応する ICMPv6 Packet Too Big を検証して推定値を下げる。さらに先に小さい制約があれば、複数回の送信と PTB が必要になる。

経路トポロジーが変われば PMTU も変わり得る。低下は PTB で知り、上昇は一定間隔で大きいサイズを試して知る。低下後の上方試行について、RFC 8201 は 5 分に 1 回を超えない頻度を推奨する。キャッシュ値には期限と更新方針があり、宛先に固有の永久値ではない。

検証済み PTB も、対応する送信が制約に遭遇したことを示すにすぎない。どの経路変更やトンネルが原因か、並行経路の上限が同じかまでは証明しない。

DPLPMTUD の確認が意味するもの

RFC 8899 では、データグラムを組み立てる層がプローブサイズを選び、遠端で特定プローブを受信したというフィードバックを得る。確認されると、そのサイズを現在の PLPMTU にできる。

これは沈黙から成功を推測するより強いが、射程は限定される。プローブ一回の損失だけでは MTU 障害とはいえない。輻輳、誤り、並べ替えもある。一回の成功も Search Complete を永久保証にはしない。他の配送情報がない非確認型の層は、確認タイマーで現在サイズを再試験する。

仕様は、経路変更、矛盾する情報、遅延、複製、並べ替え、複数経路への分散に耐えることを求める。マルチパスやマルチホーミングを扱うなら、経路ごとに状態機械が要る。宛先単位の緑ランプでは足りない。

ヘッダー予算を測定値に含める

ネットワーク層 PMTU とアプリケーションが使える大きさは同じではない。IP、拡張、トランスポート、暗号化、トンネルの各ヘッダーが領域を使う。物理リンクの MTU が不変でも、新しいカプセル化で最大メッセージサイズは小さくなる。

したがって、測定した層とヘッダー予算を記録しなければならない。サイズに相関する連続損失は安全側へ下げる根拠にはなるが、原因の断定ではない。フィルター、輻輳、受信側状態、通常損失は別に調べる必要がある。

出典