要約

  • Robert MoskowitzとPekka Nikanderが2006年に記したHIPアーキテクチャは、公鍵に基づくホスト識別子で通信相手を示し、IPアドレスを経路上のロケーターとして残す。
  • 両端がHIPを使えば、アドレス変更後も関連付けを維持できることがある。ただし、アドレス登録を移転したり、すべてのアプリケーションのアクセス規則を更新したりする仕組みではない。

ノートPCが別のネットワークにつながり、新しいIPアドレスを受け取る。パケットの経路は変わるが、通信相手のホストは同じだ。従来のプロトコルでは、一つの数字がネットワーク上の場所と通信エンドポイントの両方を表すことが多かった。Robert MoskowitzとPekka Nikanderは、RFC 4423でこの役割の重なりを設計上の問題として取り上げた。

Host Identity Protocolは、インターネット層とトランスポート層の間に別の識別空間を置く。Host Identifierは公開鍵であり、それが表すHost Identityは抽象的な身元を指す。Host Identity Tag（HIT）は識別子のハッシュを使った128ビットの表現だ。IPアドレスの役割はなくならない。ルーターがパケットを届ける先を知るには必要だ。ただし、どのホストにトランスポートの関連付けが属するかまで、IPアドレスだけに背負わせなくてよい。

この結び付けの変更がHIPの核心だ。RFC 4423は、トランスポートの関連付けをHost Identityに結び付ける構想を記す。移動、新しい接続、再番号付けでホストのアドレスが変わるとき、HIP対応の相手はロケーターを更新し、身元に結び付いた関連付けを維持できる。複数インターフェースから同じホストに到達する構成も想定される。継続性の一部を、参加する両端が持つ暗号学的状態に移す考え方である。

標準化の経緯はMoskowitzの役割を正確に位置付ける。RFC 4423は2006年5月にInformationalとして公開された。本文は2003年秋時点の著者の考えを写したスナップショットと説明し、アーキテクチャがその後変わった可能性にも触れる。Internet Standardを定める仕様ではない。Moskowitzらが編集したRFC 7401はHIP version 2をStandards Trackで規定し、参加に同意したホスト同士がIP層の状態を作る方法を示す。2021年のRFC 9063はMoskowitzとMiika KomuによるInformationalな改訂で、RFC 4423をobsoletesとし、RFC 7401の実装経験や暗号アルゴリズムの切り替え、初回接続時の信頼などを取り込んだ。

この文書の連なりは、技術案が精緻化されたことを示す。インターネット全体がアドレス依存から解放されたことは示さない。HIPが維持するのは、両端が管理するHIP関連付けだ。ファイアウォールが特定の送信元IPだけを許可していることはある。DNSが古いアドレスを返すこともある。相手側にHIP実装がない場合もある。アプリケーションが設定ファイルや評判判定にIPアドレスを使っていれば、関連付けの維持だけでそれらは変わらない。

Heng LuのNote 68は別の経済的な視点を与える。顧客、取引先、セキュリティ担当者が一つのアドレスを前提にすると、そのアドレスが企業の記憶になることがある。これはHIPの説明でも、導入状況を示す証拠でもない。二種類の継続性を見分けるための視点だ。HIPはプロトコル内のホスト識別子と経路ロケーターを分けるが、アドレスの周囲に積み上がった外部の関係までは書き換えない。

Moskowitzの仕事は、一つのアーキテクチャ境界を引いたものとして読むのがよい。「経路は変わるかもしれないが、認証されたエンドポイントの身元は別の状態として保つ」。この境界は、対象を絞るからこそ役に立つ。移動やマルチホームで固定アドレスへの依存を減らせても、DNS、ルーティング、資源管理、アプリケーションの方針、顧客向けの継続計画はそれぞれ別に必要だ。

出典