要約

  • 対応する PATH_RESPONSE は、PATH_CHALLENGE を送った経路と特定の IP アドレス・ポートの組について到達性を検証する。
  • 新経路は旧経路の容量や RTT を受け継がず、小さい検証パケットではアドレスだけが確認され、経路 MTU が未確認のこともある。
  • 運用では経路検証とアプリケーション準備状態を別々に保持し、広い証拠で結び付ける必要がある。

正しい応答にも境界がある

RFC 9000 の PATH_CHALLENGE には予測できないデータが入る。相手は受信した経路上で同じデータを PATH_RESPONSE に入れて返す。一致する応答が届けば、検証対象のアドレスの組を通る交換が成立したと判断できる。送信元を偽装した第三者への増幅を抑えるための、価値ある証拠である。

問題は、監視画面が「検証済み」を「健全」と読み替えるときに起きる。反増幅制限のため PATH_CHALLENGE を 1200 バイト以上に広げられなかった場合、相手のアドレスは検証できても、経路 MTU は検証されていない。仕様はより大きなデータグラムでの再検証を要求する。

1200 バイトの往復が成功しても、安定して使える最大サイズ、継続帯域、アプリケーション遅延までは分からない。狭い意味を守るからこそ PATH_RESPONSE は有用である。

移行先では性能を学び直す

接続移行は暗号上の接続を維持するが、旧経路の物理条件を移送しない。RFC 9000 は、新経路が現在の送信速度を支えられない可能性を明記する。新しい相手アドレスを確認したら、ポートだけが変わった場合を除き、輻輳制御器と RTT 推定器を初期値へ戻す。

旧経路のパケットは新経路の輻輳制御や RTT 推定に使えない。ECN の利用可否も別に検証する。仕様自身が到達性と容量を同一視していない。

RFC 9002 が扱う回復と輻輳制御は、ACK、損失、時間を重ねて送信余力を探る。PATH_RESPONSE の返す短い値には、その履歴がない。検証成功後に大きなデータグラムだけが失われたり、初期の保守的な送信状態が続いたりしても矛盾しない。

出典