要約

  • draft-ietf-lisp-site-external-connectivity-05は、外部、未知、または既知だが未登録の宛先に対して、空でないpETR RLOC集合を返せるようにする。
  • この応答が示すのは、あるIIDとポリシーの下で試すべき出口である。宛先そのものの識別、pETR以降のネイティブルート、アプリケーションの完了は別の証拠を要する。
  • 登録、選択、キャッシュ投入、デカプセル化、外部転送、サービス結果を一つの「解決済み」に畳むと、障害位置も責任も見えなくなる。

RFC 9301では、登録のないEIDに対してlocatorを含まないNegative Map-Replyを返し、ネイティブ転送や破棄などの動作を示せる。2026年9月30日付の改訂05は、その負の解決手順でnon-LISPの「hole」を求めながら、応答には非ゼロのRLOC数を要求する。中身は外部へ出るpETRだ。

つまり、空白だった宛先がLISP EIDとして登録されたわけではない。「より具体的なマッピングがないトラフィックを、どの出口に渡すか」というルールが見つかったのである。default routeに近いが、pETR登録、優先度、重み、通知によって動的に更新できる。

holeに出口を付けても、holeは知識にならない

保存すべき状態は destination_resolved ではなく、unknown_or_unregistered と external_exit_selected の組み合わせだ。前者を消すと、Map-Replyが正しかったのに通信が失敗する状況を説明できない。

パケットはpETRまで到達しても、その先で外部ルートが消えているかもしれない。上流フィルター、遠端ACL、輻輳、停止中のサービスも考えられる。同じ問い合わせを繰り返して同じ出口を得ても、制御面の判断が再現されたにすぎない。

証拠は少なくとも五つに分ける。pETR登録は候補の申告、マッピング応答はサーバーの選択、map-cache readbackはITRの意図状態、デカプセル化カウンターはゲートウェイ到達、アプリケーションreceiptは遠端結果を示す。前段の成功は後段の署名ではない。

登録は適格性の主張である

草案では、外部接続を持つpETRがVPN Instance IDごとに登録できる。設定可能なDistinguished Name、RLOC集合、必要に応じたVPN表現を含む。さらにvendor-specific LCAFで、場所、resource availability、performanceに関する値を運べる。

認証済み登録が証明するのは、あるprincipalがそのデータを送り、admission policyが受け入れたことだ。現在も外部へ転送できることまでは証明しない。誰がどのIIDに出口を登録できるか、RLOCを管理しているか、外部経路をいつ確認したか、どの条件で撤回するかを別々に残す必要がある。

RFC 9306はvendor formatの器を定めるが、「performance」の共通単位や測定法は作らない。設定値、controller estimate、古い観測が同じフィールド名を持ち得る。producer、schema、単位、時刻、window、confidence、validityがない値は、可逆なpolicy hintとして扱うべきだ。

priorityとweightは配分指示

RFC 9300では低いpriorityが優先され、同じpriorityのRLOC間はweightで相対配分される。これはITRの選択規則であって、容量、遅延、経路独立性、実際の配分の証明ではない。

異なるRLOCが同じchassisやproviderへ収束することもある。70対30という設定は契約上の意図かもしれず、測定結果とは限らない。候補集合、除外理由、metadata snapshot、policy version、tie-break、期待配分を保存し、pETR別のencapsulation、decapsulation、native-forward counterで実績と比較するべきだ。

Map-Notify-Ackの射程

RFC 9437はMap-Notifyによる更新、nonce、安全なassociation、Map-Notify-Ackを定義する。改訂05はpETR変更の配布にこれを使い、利用できない場合は短いTTLを提案する。

ACKは制御メッセージの確認であり、全転送表へのprogramming、次のpacketの一致、外部配送を証明しない。短いTTLもstateの許容年齢を狭めるだけで、refresh成功を保証しない。

運用自動化は、通知認証、scope validation、write、readback、pETRまでのdata-plane canary、外部canary、application completionを段階ごとに記録する必要がある。最初に失敗した段階が、現在の調査境界になる。

defaultは最も広い変更である

ITRはhole prefixまたはdefault map-cache entryを置ける。草案はknown EID blockをmore-specific entryとして持ち、必ずMap-Requestを発生させるよう勧める。これは外部defaultが通常のEID解決を飲み込まないための隔離である。

defaultは設定を減らすが、一回の変更で無関係な多くの通信を動かす。可用性だけでなく、観測点、費用、jurisdiction、security policyも変わり得る。導入は狭いIID、保護されたspecific prefix、canary ITR、短い有効期間から始め、rollbackは対象pETRだけをdemoteまたはwithdrawすべきだ。

Datatracker上ではExperimental Internet-Draftであり、RFCでもdeployment reportでもない。AI infrastructureの記述はuse caseであり、特定製品の実装証拠ではない。

Lu HengのReality Layersに沿えば、Distinguished Nameは記号、Map-Replyは判断、cacheは状態、packetは作用、remote responseは結果だ。信頼できる設計は、それらを一つの緑色表示にまとめず、接続関係を検証可能に保つ。

情報源