要約

  • draft-munizaga-quic-alternative-server-address-02 は、連番で置き換える完全な候補集合と、CURRENT_PATH を境にした優先・予備グループを提案する。現状は正式なIETF上の地位を持たない個人Internet-Draftである。
  • アドレスの通知だけでは経路は生まれない。優先度は助言であり、クライアントはローカル方針で無視でき、通常データを送る前に方向ごとの経路検証が要る。
  • 多数のクライアントが同じ助言へ同時に反応すれば別の宛先を圧迫できるため、通知、採用、検証、実利用、集団効果を一つの成功表示にまとめてはならない。

この草案が扱うのは、ハンドシェイク後にサーバー側の都合が変わる場面だ。現在の優先アドレスは接続開始時に渡す。新しいALTERNATIVE_ADDRESSフレームなら、長い接続の途中で候補を差し替えられる。

フレームはSequence Numberを持つ。より大きい番号の集合が以前の集合を原子的に置き換え、遅れて届いた古いフレームは無視される。新しい集合から消えたアドレスは、拡張上もう通知されていない。これはサーバーの状態更新を明確にするが、クライアント側の古いプローブや送信待ちデータが消えた証拠にはならない。

一覧には一つだけCURRENT_PATHが入る。Multipathでなければ、その前は現行経路より優先、その後は予備である。同じ側では小さいPriority Hintが上位だが、反対側の数値とは比較できない。同じ値ならサーバーは順番を指定していない。数字だけを取り出して世界共通の順位と読むのは誤りだ。

クライアントはどれを検証するか、並列に試すか、検証済みのどれを使うかを決める。ローカル方針で優先度を無視してよい。プライベートIPv4やULAは、同じ管理領域では有効でも外部からは届かない。NAT、企業規則、電力、利用可能なConnection IDも、サーバーからは見えない制約になる。

経路検証にも貸し借りできない境界がある。候補へ送ったPATH_CHALLENGEに一致するPATH_RESPONSEは、別経路から戻っても挑戦を送った側の経路を検証する。一方、未通知の送信元から認証済みのプローブが届いた事実は、その送信元自体を検証しない。記録すべきなのは挑戦値、対象4タプル、方向、時刻、結果である。

サーバーも新経路で非プローブデータを送る前に送信方向を検証する。その後で初めて、単一路線への移行、Multipathへの追加、予備保持、未使用という選択が生まれる。Multipath仕様はアプリのスケジューラを定めない。検証済みという状態と、実際にRTTや損失を背負った状態は異なる。

最大の注意点は一台の経路ではなく群れだ。悪意あるサーバーは、多数の接続へ同じ被害アドレスを上位候補として送れる。各クライアントが正しく認証し、正しく検証しても、同時移行は標的を過負荷にし得る。草案はランダム遅延を示すだけで、全体の上限、標的の同意、到着予定数を共有する仕組みまでは定めない。

Heng Luの最小仕様とローカル判断の考え方は、この設計を読み違えないために役立つ。共通層は候補と更新順序を交換できればよい。採用はリスクを負うクライアントに残し、結果は実際の経路とアプリから得る。文書、コードポイント、実装、運用はそれぞれ別の現実層である。

2026年9月25日版は改訂02の個人草案で、Datatracker上はI-D Exists、streamも担当ADもない。保存したIANAレジストリには申請中の値が見当たらない。製品実装、相互接続、普及率、性能改善、攻撃発生を示す資料も今回の証拠集合にはない。

情報源