要約

  • 個人提出の HCGA 草案は、運用者が管理する集約プレフィックスと /64 の間のサブネットビットを公開鍵から導く。既存の RFC 3972 が扱うインターフェース識別子より上の領域に踏み込む。
  • /48 配下の対象ビットは16個しかない。別の鍵による一致は約2^16回の試行で起こり得るため、/64 の排他的な受け入れ記録と送信元の強制管理が不可欠になる。

公開鍵が住所を作る。では同じ住所を示す鍵が二つ現れたら、誰が入居者を決めるのか。Hierarchical Cryptographically Generated Addresses の核心はそこにある。草案はマルチテナント環境のワークロードやエージェントに、鍵と結び付く IPv6 /64 を与えようとする。計算式は関係を照合できるが、入居審査までは代行しない。

RFC 3972 の暗号学的生成アドレスでは、公開鍵から下位のインターフェース識別子を導き、/64 プレフィックスはネットワーク側が提供する。HCGA は境界を上げ、運用者が持つ集約プレフィックスから /64 までのビットを鍵とプレフィックス修飾子で生成する。後から検証する人は、鍵だけでなく生成時の修飾子と衝突回数も必要だ。

安全性の章は数字を隠していない。集約が /48 ならサブネット部分は16ビット。別の鍵や修飾子で同じ /64 を得るには、おおむね2^16回の試行で足りる。この数字はサブネットビットの衝突であり、128ビットの IPv6 アドレス全体や秘密鍵をその回数で偽造できるという意味ではない。下位のインターフェース識別子には別の大きなハッシュ出力境界がある。それでも /64 だけで鍵を一意に指すことはできなくなる。

草案は周辺の仕組みに、各 /64 で採用した鍵と修飾子を記録し、別の候補を排除する役割を求める。パケットに記載されたアドレスも、送信者の証明にはならない。対応する秘密鍵の署名か、ネットワークによる送信元アドレス制御が必要だ。ローカルリンクの外から調査する場合、生成パラメータが保存され、取得できなければ照合が止まる。記録を失えば、暗号学的な住所から正規の入居者を復元できない。

経路の証拠は対象が違う。運用者が BGP で告知するのは集約プレフィックスで、RPKI ROA がその告知権限を扱う。内部の /64 経路は外部に告知しない。集約の正しい ROA から、個々の /64 に採用されたワークロード鍵は分からない。その判断を握るのはローカルの受け入れ記録だ。

住所を安定させると別の値札が付く。草案では下位識別子を変えても /64 が固定され、活動を結び付けやすくなる。RFC 8981 の一時 IPv6 アドレスは異なるプライバシー目的で設計された。また HCGA の計算は、鍵がハードウェアで守られているかソフトウェアだけかを示さない。RATS は別途、証明資料を扱う枠組みを定めている。

IETF Datatracker は10月27日付の個人提出 Standards Track 草案を「I-D Exists」と記す。検証するなら、試験用 /48 の下で同じ16ビットを生む二つの鍵を作り、後者の登録を拒み、遠隔の検証者に先着の鍵・生成パラメータ・送信元証拠を再構成させればよい。問われるのは住所の計算と、その住所を誰に渡したかの記録の両方だ。