要約

  • LISPはEIDとRLOCの役割を分ける一方、到達性を、認可されたETR登録、Mapping Systemでの解決、有効なITRキャッシュ、許可されたRLOC選択、アンダーレイ経路、ETR以後の配送という連言に変える。
  • David MeyerはRFC 6830とRFC 9300の共同著者の一人である。人物として興味深いのは、場所を不要にしたからではなく、抽象的な分離が期限、信頼、更新、撤退手順を備えた共同運用へ成熟する過程に関わったからだ。

キャッシュにない宛先へ最初の一個を送る

LISPの実像は、二個目のパケットより最初の一個に現れる。送信側のITRが宛先EIDをMap-Cacheで見つけられなければ、RFC 9301の制御プレーンを通じて対応するRLOCを問い合わせる。その間、パケットを捨てるか一時保存するかは配備側が決める。アーキテクチャは同じでも、初回遅延と障害時の振る舞いは運用方針で変わる。

この問い合わせが必要なのは、EIDそのものが「どこへ送るか」を持たないからである。RFC 9299によれば、EIDとRLOCはどちらもIPv4またはIPv6アドレスと同じ構文を使うが、意味が異なる。EIDはトポロジー上の位置から独立してノードを識別し、RLOCはアンダーレイの接続点を示す。Mapping Systemが両者の対応を保存する。

背景にはルーティング規模の問題があった。2006年のIABワークショップを記録したRFC 4984は、一つのIPアドレスに識別子とロケーターの意味を重ねることが拡張性を難しくすると報告した。参加者は分離の必要性を認めたが、実装方式までは決めなかった。しかも文書は参加者の見解であり、IABの公式解決策ではない。

LISPはその空白を埋める一案になった。ただし、分離を実装すると「場所」は単純な属性ではなくなる。誰が書き、誰が読み、いつまで有効で、どの経路が実際に使えるかという運用台帳になる。

同じEIDの下で変わるもの

RFC 9300は、公開インターネットで用いるEIDについて一意性を要求し、サイトに関連付けられたEID-Prefixから割り当てるとする。この条件を所有権や本人性へ広げてはならない。一意な番号は、Map-Serverへの登録、利用者の正当性、事業者をまたぐ可搬性、現在の到達性を証明しない。

ETRはEID-Prefixと一つ以上のRLOCをMap-RegisterでMap-Serverへ送る。ITRはMap-Resolverを通じてその対応を取得する。得られたLocator-SetはローカルのMap-Cacheに入り、TTLで失効する。TTLがゼロなら直ちに削除され、特別な値なら保存期間を受信側が決める。権威側の変更時刻と各ITRの利用状態は一致しない可能性がある。

RLOCを複数登録しただけでも配送先は自動的に決まらない。Priorityが小さいロケーターが選ばれ、255は転送に使えない。同じ優先度ならWeightが負荷配分を決める。EIDが固定されたままWeightだけが変わり、トラフィックが別の地点へ移ることもある。

さらに、選ばれたRLOCへのアンダーレイ経路が必要だ。外側パケットがETRへ着いた後、ETRはカプセルを外し、内側パケットを宛先EIDへ送らなければならない。マッピングが正しくてもアンダーレイが切れていれば失敗する。RLOCまで到達してもサイト内部が壊れていれば失敗する。「EIDが存在する」と「サービスに届く」の間には少なくとも二つのネットワークがある。

登録は申告ではなく権限行使

RFC 9301はETRとMap-Serverに事前共有秘密を求め、登録認証鍵の導出に使う。Map-Serverは、各ETRが登録を許されたEID-Prefixも保持すべきだ。これを照合しなければ、単純なプレフィックス乗っ取りが可能になる。つまり、EID-to-RLOC対応は単なる技術データではなく、範囲を限定された発言権である。

登録は定期更新され、有効なMap-Registerが途絶えれば削除され得る。ロケーター数ゼロのNegative Map-Replyは、未登録、ポリシー拒否、認証失敗を区別し、ネイティブ転送、再問い合わせ、何もしない、破棄といった動作を伝えられる。障害の原因とフォールバックの種類はプロトコル上すでに別項目だ。

ETRが対応を変更すると、Solicit-Map-Requestにより、以前の対応をキャッシュしている遠隔ITRへ再問い合わせを促せる。送受信双方にレート制限があり、該当キャッシュのないITRは問い合わせる必要がない。全ノードを一斉に書き換える仕組みではなく、利用中のコピーを段階的に更新する仕組みである。

閉じた信頼環境向けのRFC 9302は、十二ビットのMap-Versionを任意で加える。RLOCの追加・削除、PriorityやWeightの変更、ローカル到達性の変化が版を進める。番号は循環するため、古い版が新しく見えないよう、少なくとも以前のTTLを待つなどの配慮が要る。ただし公開インターネットでは、RFC 9300がMap-Versioning、gleaning、Locator-Status-Bits、Echo-Nonceを更新や到達性判断に使うことを禁じ、制御プレーンを要求する。閉域で有効な近道を公開環境へ持ち出してはならない。

マップを守る仕組みの前提

RFC 9301のセキュリティ節は、Mapping Systemを安全で信頼できる一要素とみなし、ETRとの信頼関係が事前設定され、どのEIDを広告できるか既知であると仮定する。鍵と権限をどう成立させるかは範囲外だ。仕様は組織が決めるべき正当性を自動生成しない。

公開インターネット用途で必須とされるRFC 9303のLISP-SECは、検索で運ばれるマッピングへ送信元認証、完全性、リプレイ防止を与え、EID-Prefixの過剰主張を検証する。偽のMap-Replyによる転送先変更を防ぐためである。それでも、Mapping System内で要求が正しいETRへ届き、Map-Serverが登録権限を確認できるという前提は残る。

守られるのはEIDという文字列ではなく、EIDとRLOCの関係、そしてそれを主張する権利だ。長寿命EIDには別の問題もある。RFC 9301は、RLOCの変化と結び付けば利用者のトポロジー上の移動を追跡できると指摘する。番号の継続性が高いほど、相関可能性も長くなる場合がある。

Meyerを一人の発明者にしない

RFC 9300の著者はDino Farinacci、Vince Fuller、Dave Meyer、Darrel Lewis、編集者Albert Cabellosである。Meyerは元のRFC 6830にも名を連ねるが、LISPを単独所有したわけではない。IETFの審査、共同著者、実装者、Mapping System運用者、サイトとアンダーレイの事業者が別々の権限を持つ。

ONUGの歴史的な人物ページには、CiscoとBrocadeでの経歴、IAB、NANOGのプログラム委員会、オレゴン大学のRouteViewsへの関与が記録されている。現在の勤務先を示す資料ではない。ここから読み取れるのは、Meyerがルーティング状態を観測可能にする仕事と、新しい制御抽象を実装へ下ろす仕事の両方に長く接していたことだ。

既存のMeyer記事はRouteViews、RPSL、OpenDaylightを通じて公開制御プレーンを論じる。本稿は違う。LISPのマッピングを誰が更新でき、コピーがいつ失効し、解決後に何を実測しなければならないかを扱う。人物が同じでも、運用対象は重ならない。

RFC 7215のExperimentalな配備ガイドは、この区別を現場へ戻す。移行時にOS、設定、MTU、プレフィックス、RLOC到達性、Map-Server登録、認証鍵、プロキシキャッシュ、BGPポリシー、外部可視性、実トラフィックを確認する。2014年の移行方式を現在の普及証明には使えないが、確認項目の多さは「EIDが変わらない」だけでは何も完了しないことを示す。

LISPの価値は、場所を消すことではなく、変化する場所を別の記録として管理できることにある。その価値は、記録を期限付き、権限付き、観測可能に保つ運用で初めて現れる。

出典