要約

  • 送信側は REQ に4オクテットのトークンを入れ、EOL で選んだサイズまで埋める。対応する RES は、そのプローブが UDP Options 受信側へ届いたことを示す。
  • 結果の範囲は 5-tuple、経路、時点に限られる。ECMP やマルチホーミングでは経路別の状態と定期的な再検証が必要になる。
  • RES の遅れには複数の原因がある。復路トラフィックへの同梱、レート制限、応答損失によって、通過可能な経路が小さく見えることもある。

成功は一回の試行に結び付く

RFC 9869 は RFC 8899 の DPLPMTUD を UDP Options に適用する。REQ のトークンと EOL のパディングで試験サイズを作り、受信側が最後に受け取ったトークンを RES で返す。プローブは現在の PLPMTU 推定値を超えてよいが、インターフェース MTU を超えてはならず、IP で分割してはならない。

トークンが一致すれば、そのプローブが遠隔の UDP Options 受信処理まで届いたと分かる。しかし、アプリケーションへの配送や受理は証明しない。復路の最大サイズも測らない。次のパケットが同じ経路を選ぶという保証もない。

PLPMTU を引き上げるプローブにアプリケーションデータを載せないのはこのためだ。大きすぎる候補の損失は探索に織り込まれている。ペイロードがゼロのプローブは上位層へ渡されない。データを持つパケットは現在値の確認や再検証には使えても、引き上げ探索には向かない。

トークンの寿命が帰属を守る

同じ 5-tuple では Maximum Segment Lifetime の間、トークンを一意に保ち、再利用してはならない。ランダムな初期値と予測しにくい更新は、経路外からの偽応答を難しくする。それでも、最終的な PLPMTU だけを保存すれば、サイズ、経路、送受信時刻、再試行、実装版という根拠は失われる。

両端のアプリケーションによる明示的な有効化も必要だ。受信側は有効化前に RES を返してはならない。トランスポートサービスと上位プロトコルが同時に探索するなら、トークン空間を調整または分離しなければ、正しい応答が別の状態機械に渡り得る。

対象は主にユニキャストで、マルチキャストは対象外である。受信側は進行を早めるため空の応答を生成できるが、応答だけの送信にはレート制限が必要になる。

測っていない経路へ値を移さない

ECMP、複数経路、マルチホーミングでは、RFC 9869 は経路ごとの独立状態を求める。ボトルネックは宛先名ではなく実際に通ったリンク列に属する。一経路の成功値を他へコピーすれば、測定が推測に変わる。

時間も状態を古くする。経路変更やトンネル追加、一時的な制約の解消で限界は変わる。現在の PLPMTU を定期的に検証することは保守作業ではなく、過去の成功が恒久的な権限を持つのを防ぐ制御である。

沈黙は経路の診断名ではない

受信側は、予定されている復路データグラムに RES を同梱するまで待てる。その間に複数のプローブが届くと、最新トークンだけが返され、以前の到達済みプローブが失敗に見える場合がある。復路トラフィックが少なければ、実際より小さい PLPMTU、場合によっては最小値に留まり得る。

専用の空応答は遅延を減らす一方、レート制限を受ける。したがってタイムアウトは、往路損失、応答方針、待ち行列、制限、復路損失のいずれでも起こる。状態機械が保守的に扱うことと、原因を断定することは別だ。

ICMP Packet Too Big の利用は任意である。利用時は引用されたプロトコルを検証し、可能なら REQ トークンも照合する。検証できないメッセージは無視しなければならない。予測困難なトークンは経路外の注入を抑えるが、経路上の妨害までは排除しない。

出典