要約

  • RFC 9962 は参加する xTR が LISP の EID-to-RLOC マップを共同維持できるようにする。push 型はマルチキャストで登録を複製し、pull 型は一貫した変換と DNS で Map-Server 群を見つける。
  • マップ、認証済み登録、処理通知は、いずれも制御プレーン上の限定された出来事の証拠である。RFC 9301 は RLOC の状態が要求者の視点からの経路到達性を表さないと明記する。

LISP は、オーバーレイで宛先を指す Endpoint Identifier（EID）と、カプセル化されたトラフィックを運ぶ Routing Locator（RLOC）を分ける。両者の間には対応付けの仕組みが必要になる。従来は、独立した Mapping System Provider が Map-Resolver と Map-Server を運用し、データプレーンの xTR がそこで対応を登録または照会する。RFC 9962 が変えるのは、マップを「誰の判断も要らない事実」にすることではない。その限定的な記録を誰が保存し、提供するかである。マップを使う xTR が、その記録を支えるピアにもなれる。

これは依存構造の変更であって、現実の結果に対する包括的な証明ではない。RFC 9301 では、ETR は EID プレフィックスと RLOC の集合を Map-Register として Map-Server に送る。Map-Notify を求めれば、サーバーがその登録を受信し処理したという確認を受ける。「受信」「処理」「確認」は制御プレーンの行為を表す。すべての要求者がその RLOC へ到達できること、帰路が成り立つこと、あるいはアドレスの先のサービスが今も運用上の義務に適していることを意味しない。

RFC 9301 が置く境界は重要である。RLOC の状態は到達可能性を伝え得るが、要求者の視点からの経路到達可能性は伝えない。経路には別のテストが必要だ。出発地点、カプセル化、フィルタ、逆方向の経路、輻輳、フェイルオーバー、サービス方針によって、同じマップでも結果は変わる。正しい対応記録が使えない経路へ導くことはある。パケットが一つのアドレスに着くことも、本人性、事業上の権限、または運用上の受容を解決しない。

RFC 9962 の二つの設計は、その境界をよく示す。push 型では xTR が同じマルチキャスト・グループに参加し、Map-Register はグループ内のすべての Map-Server へ配送でき、各サーバーは登録済み状態を複製して持つ。冗長性は得られるが、実際に使えるマルチキャスト基盤が要る。pull 型では、決定的な変換が EID を DNS 名に変え、対象となる Map-Server の集合を探す。複製状態は少ないが、関数、名称、モジュラス、拡張条件について継続的な一致が必要になる。両者は自由に組み合わせる二つの「より分散的な」部品ではない。RFC 9962 はどちらかを選ぶよう求め、共存しても相互互換を約束しない別個のマッピング・システムとして扱う。

認証にも範囲がある。RFC 9962 は xTR 間の信頼に RFC 9301 と ECDSA-AUTH を参照する。RFC 9301 は Map-Register の送信元と完全性を保護し、nonce で再送を扱い、鍵または方針を満たさない登録を Map-Server が拒否できるようにする。これで「誰がどの登録を提出し、システムは何をしたか」は追跡しやすくなる。端点の身元、顧客へ提供する権限、経路の品質、将来の配送を証明するわけではない。鍵の証明が扱うのはプロトコル上の行為であり、全結果ではない。

最小の初期メカニズムと将来の判断を当事者の近くに置くという Lu Heng の考えから見れば、RFC 9962 の価値は、協調機能を参加者へ近づけながら、彼らの代わりに決める権力を与えないことにある。共有マップは発見と登録のコストを下げられる。それだけでトラフィック、顧客露出、障害許容、離脱の選択権を得るべきではない。経営上の問いは「分散」という言葉の響きではなく、どの依存が変わり、どの記録を監査でき、誰が最終判断を保持するかである。

出典