要約

  • RFC 5338 の LSI は、一台のホストが Host Identity を旧式ソケット API に載せるためのローカル表現であり、別ホストへ同じ意味を委譲する値ではない。
  • 名前解決、LSI 割当、HIT 対応、ロケータ、経路選択、HIP 関連付け、アプリケーション結果、監査記録を別々の証跡として残す必要がある。

値は同じでも、名前空間が違う

ホスト甲は、ある相手を LSI 42 で表す。旧式アプリケーションはその値をアドレスとして受け取り、同じホストの connect() に渡す。HIP 層が表を引き、HIT と現在のロケータを扱うため、通信は成立する。

アプリケーションが 42 をホスト乙へ紹介すると事情が変わる。乙は甲の表を持たない。乙自身の 42 が別の Host Identity に割り当てられていれば、ビット列は正しくコピーされたまま対象だけが変わる。これはパケット破損ではなく、名前空間の取り違えである。

RFC 5338 は、アドレス利用を短時間のローカルハンドル、長期関連、コールバック、紹介、同一性比較に分けて考える。最初の用途で安全な互換方式が、残りにも安全だとは限らない。見た目の型が同じでも、解釈権を持つ主体が異なるからだ。

LSI は転送先ではなく、変換を始める鍵だ

RFC 5338 で LSI は、IPv4 または IPv6 API において Host Identity をローカルに表す 32 ビットまたは 128 ビットの値である。RFC 9063 は、32 ビット LSI が HIP 層やソケット処理部で HIT と相互変換され、ワイヤ上へロケータとして送られないことを説明する。

したがって「特殊な IP アドレス」という理解は弱い。「ローカル変換表のキー」と考える方がよい。意味を確定するには、割当ホスト、表の世代、対応する HIT、作成時刻と有効期限が要る。裸の数値だけでは、過去の主体を復元できない。

LSI を使った connect() が成功しても、証明されるのは、その時点で同じホストが自分のキーを解釈できたことまでである。再起動後にも同じ対応が残ること、別ホストが解釈できること、あるいはアプリケーションの要求が完了したことは含まれない。

DNS 代理は表現を変えるが、世界の表を変えない

RFC 5338 は、HIP 対応のローカル DNS エージェントが、通常の IP アドレスを期待するアプリケーションへ LSI または HIT を返す方式を述べる。エージェントとスタックが対応関係を保持し、システムコール付近で変換する。

ここには連続する別の判断がある。DNS やディレクトリから身元情報を得た。ローカルな表現を選んだ。ハンドルを割り当てた。利用可能なロケータを解決した。HIP または非 HIP の試行を選んだ。関連付けを完成させ、データを運び、アプリケーションが応答した。先頭の一件は末尾の結果を証明しない。

複数の結果が返る場合、HIP の識別子を先頭に置いても、アプリケーションが接続を並行開始すれば通常 IP の経路が先に成功し得る。並び順は方針の提示であり、実行経路の領収書ではない。HIP を必須にするなら、候補を制限するか、勝った試行を観測しなければならない。

さらに ping のような診断用途は、アドレスそのものを求める。あらゆる問い合わせに LSI を差し込めば、観測ツールが見ている値とワイヤ上のロケータが食い違う。互換層は、変更した意味を隠すのではなく記録すべきである。

紹介はローカルキーを外部契約へ変えてしまう

三者間の紹介では、B が A の「アドレス」を C に渡し、C が A へ接続する。B の値が LSI なら、C が受け取るのは A のグローバルな名前ではなく、B の表にある行番号である。

明確な失敗なら原因を追える。厄介なのは偶然の成功である。C が同じ値を通常の IPv4 として配送する、または別の Host Identity の LSI として解釈する。フォーマット検証はすべて通り、違う主体へ到達する。

解決策は LSI を無理にグローバル化することではない。紹介プロトコルが、受信者の解決できる名前と範囲を運ぶべきだ。HIT と解決方法、DNS 名と検証規則、あるいは発行者と期限を含む参照オブジェクトが候補になる。観測目的で LSI を含める場合も、割当ノードと世代を付ける。

RFC 9063 が NAT との類似を指摘するのは重要である。ローカルアドレスをアプリケーションメッセージへ埋める設計は、既に NAT で壊れやすい。HIP は新しい欠陥を作るというより、位置と身元を一つの欄へ押し込んだ古い前提を露出させる。

キャッシュが表の世代をまたぐ

旧式アプリケーションは、名前解決結果を HIP 実装の想定より長く保持することがある。RFC 5338 は、このため LSI 対応のガベージコレクション時期が難しくなると述べる。古いプロセスが値を持ったまま再利用されれば、同じ数値が新しい相手を示す。

監査でも同じ罠がある。昨日のログに LSI 42 があり、今日の表で 42 が Y に対応しているからといって、昨日の相手が Y とは限らない。現在の表を過去へ適用することは、証拠の復元ではなく履歴の書き換えである。

RFC 5338 は HIT、LSI、対応 IP アドレス、FQDN 関連情報を一緒に記録するよう勧める。実運用では、ローカルホスト、起動または割当世代、プロセス、ソケット、時刻、選択方針も必要だ。この組は、互換層が当時何を知っていたかを残す。

ただし監査組もサービス完了の証拠ではない。名前の対応、HIP 関連付け、保護データ、アプリケーション応答は別イベントである。一つの「接続成功」フラグにまとめると、どの境界で意味が変わったか説明できない。

HIT を明示しても、結果までは予約できない

通常の connect(ip) は、「現在そのアドレスで到達できるシステムへ接続する」という程度の意図かもしれない。ローカル方針が HIP を試しても、アプリケーションが最初から特定 Host Identity を強く指定したとは限らない。

HIT を明示すれば命名は強くなる。暗号学的なホスト名を要求するからだ。それでもロケータ解決、基本交換、保護状態、データ到着、アプリケーション受理は別に必要である。HIT の存在だけで現在の秘密鍵保持、利用者の権限、サービス稼働を結論できない。

この論点は、既に扱われた RVS 中継、HIP DNS の鮮度、移動ロケータ、ESP 経路とは異なる。対象は、旧 API へ渡された記号がどの範囲で誰を名指せるのか、そしてその範囲を越えた時に何が失われるかである。

ワイルドカード待受けにも身元選択が残る

サーバー側では、旧式サービスがワイルドカードへ bind し、ホストが複数の Host Identity を持つことがある。アプリケーションが特定 HIT を選ばないなら、ローカル方針が身元を選ぶ。RFC 5338 の UDP 例では、recvfrom() 後の sendto() がクライアントの想定と違う HIT を使い、応答が捨てられ得る。

待受け成功はポートの状態を示すだけで、受信と送信の身元連続性を示さない。到着時のローカル HIT、送信時に選んだ HIT、適用方針を記録する必要がある。多重身元に対応できないサービスなら、既定の送信 HIT と一致する公開鍵だけを告知するという制約が現実的である。

情報源と証拠の限界

以下は仕様、宣言されたアーキテクチャ、過去の実験報告を裏付ける。現在の製品、導入率、組織、事故、測定された故障率を示すものではない。