Summary

  • draft-ietf-rtgwg-dst-src-routing-revive-06では、送信元プレフィックスが経路の識別と検索の一部になる。付加情報ではない。
  • 混在環境では、表に経路があるだけでは次ホップが送信元条件を守ると証明できない。能力の連続、旧式ノードを通っても前進する根拠、または明示的な破棄が必要である。

Aは送信元Sから宛先DへのパケットをBへ渡す。BはDだけを見てAへ戻す。どちらの経路表も、それぞれの検索規則では自然に見える。二つをつなぐと、同じパケットが異なる「最長一致」の間を回り続ける。

2026年9月16日付のRTGWG草案は、まだRFCではない。意味上、すべての経路は送信元プレフィックスを持ち、従来の経路は ::/0 を持つものとして扱う。検索はまず最長の宛先を選び、その宛先に属する候補から最長の送信元一致を選ぶ。一致する送信元がなければ、より短い宛先へ戻って検索を続ける。順序を逆にすれば、別の転送規則になる。

受信した制御情報は転送能力ではない

非対応ルータは必ずしもエラーを返さない。送信元条件を捨てた粗い規則で正常に処理できるため、意味の劣化が見えにくい。

草案はプロトコル拡張にループ回避を求める。次ホップを対応トポロジー内に限定する、非対応の隣接を使うならメトリック等でDへの前進を証明する、または到達不能として破棄する、という三つの方向だ。明示的なブラックホールは失敗を限定する。ループは帯域と装置資源を消費し、負荷次第で故障の形まで変える。

距離ベクトル型では、経路を伝えた隣接がその情報に沿って転送するため、能力交渉や未対応形式の非伝播が役立つ。ただし制御経路とデータ経路が一致する場合に限る。リンクステート型では、情報をfloodingした事実が転送対応を意味しない。対応ノードだけの別SPFを計算するか、非対応ノードを横切る経路をブラックホールへ変える必要がある。

能力を先に配り、経路を後で有効にする

第06版は、対応ソフトウェアの配備と、実際の送信元条件付き経路の投入を分ける。新しい経路がなければ対応ルータは従来どおり振る舞う。したがって全域へ能力を展開し、確認してから新しい意味を有効にできる。ロールバックは逆であり、まず経路を外し、その後で能力を取り除く。

バージョン一覧だけでは不十分だ。稼働中のbuild、機能状態、表の上限、隣接能力、再帰解決、FIB動作、S–D試験を残す必要がある。実装状況の付録はLinuxの CONFIG_IPV6_SUBTREES、FRRouting、babeld、実験網、CERNETの20台を挙げるが、これは草案著者の報告であり独立した本番測定ではない。

経路表は証拠鎖の入口にすぎない。仕様、実行能力、隣接またはトポロジー能力、経路とポリシー時点、再帰とFIB、連続した能力島または意図した破棄、パケット観測、サービス結果を別々に保存する。送信元を記録しないDへのprobeは、別の経路問題を質問している。

Heng Luの枠組みで言えば、共通層は経路識別、検索順序、ループ回避という最小の決定規則だけを固定すればよい。採用時期は運用者が決める。しかし複数装置をまたぐ互換性は、一方の宣言ではなく、稼働コードと転送結果で証明しなければならない。

Sources