要約

  • RFC 4193の40ビットのグローバルIDは、独立に作られたULAプレフィックスが同じ値になる確率を極めて小さくする。登録機関による割り当てや認証ではない。
  • 「グローバル」は一意性を目指す範囲を表し、インターネット全体への到達性を表さない。経路交換にはサイト間の明示的な合意と境界フィルターが必要だ。
  • 合併やVPN接続では、双方の全プレフィックスを実値で照合し、DNSと経路の範囲を限定し、セキュリティを別に設計し、衝突時の改番または切り戻しを決めておく必要がある。

ネットワークを接続する会議で、「どちらもULAだが、プレフィックスは違って見える」という報告が出る。fdで始まる長い文字列を二つ見比べれば、偶然同じ番号を使う危険は消えたように思える。

RFC 4193が提供したのは、その結論ではない。結論に到達するまでの負担を大きく減らす仕組みである。

2005年10月に公開されたRFC 4193は、Robert HindenとBrian Habermanによる標準化過程のProposed Standardである。IPv6 Unique Local Address（ULA）をFC00::/7に定め、1ビットのL、40ビットのグローバルID、16ビットのサブネットID、64ビットのインターフェースIDという構造を示した。L=1がローカル割り当てを意味するため、現在定義されている生成形式はFD00::/8に現れる。

運用者はグローバルIDを中央機関から受け取らない。連番や広く知られた値を避け、擬似乱数として作る。RFCの例は、現在時刻とシステム固有の識別情報を組み合わせ、SHA-1を計算し、下位40ビットを使う。

ここでハッシュ関数に安全保障上の意味を持たせてはいけない。この手順は運用者を認証せず、プレフィックスを秘密にせず、所有権も証明しない。独立した選択を広い空間に分散させるための方法である。

RFCは確率を具体的に示す。独立に生成したIDが二つある場合、衝突確率の例は約1.81 × 10^-12。1万個では約4.54 × 10^-5となる。これは数理モデルの値であり、現在使われているULAを測定した数字ではない。事前に世界中と調整する必要をなくすには十分に小さいが、既知の二組織が接続するときに照合を省く根拠にはならない。

グローバルIDという名称も、経路の性質とは切り離す必要がある。グローバルなのは一意性の目標であり、到達範囲ではない。IANAの現行IPv6 Special-Purpose Address Registryでは、fc00::/7は送信元、宛先として使用でき、転送も可能だが、グローバル到達性はないとされる。特別用途として登録されているだけで、個別の環境におけるルーティングが保証されるわけでもない。

境界は設定によって成立する

RFC 4193が想定する経路範囲は、一つのサイト内、または接続を明示的に合意したサイト間である。インターネット側のルーティングはFC00::/7を既定で無視する。サイト境界ではULAの経路とパケットを双方向にフィルターする。サイト間で必要な例外は、範囲全体ではなく、特定の/48またはさらに具体的な経路として記述する。

したがって、ULAを「外に出ないアドレス」と理解するのは危うい。ルーターは転送でき、VPNは運べる。誤った再配送は別の管理域に伝える。境界を作るのはプレフィックスの見た目ではなく、経路ポリシー、フィルター、トポロジーと合意である。

DNSにも固有の境界がある。RFCは、一意性が完全には保証されないため、ULAのAAAAやPTRをグローバルDNSへ公開しないよう勧告する。逆引き問い合わせもグローバルDNS基盤へ送ってはならない。企業統合の台帳には、内部の権威ゾーン、スプリットビュー、フォワーダー、逆引きゾーン、アプリケーションの名前依存を含める必要がある。

ULAプレフィックスだけで端末の設定が完了するわけでもない。Router Advertisement、DHCPv6、手動設定、サブネット設計、名前登録は別々の判断である。RFC 5375は、ULAとグローバルIPv6アドレスを併用できると説明し、この方式がIPv6のNATを要求するものではないと明確にする。

セキュリティも別の制御面に置く。利用者とサービスの認証、通信の認可、ファイアウォール、経路情報の信頼、監査ログは、アドレス種別とは独立して必要だ。RFC 4193はULAに固有のセキュリティがないと述べる。ローカルな範囲から来たように見えるパケットが、信頼できる主体を示すことはない。

「サイト」の曖昧さからの修復

RFC 3879が廃止したsite-localアドレスは、なぜ別の識別子が必要だったかを示す。「サイト」は建物なのか、企業全体なのか、提携先を含むのかが一定しない。複数拠点を持つ組織ではスコープの判断が揺れ、プレフィックスの漏出やアプリケーションの誤選択が起き、別々のネットワークが同じローカル範囲を持つこともあった。

40ビットの生成IDは、万能な割り当て機関を新設せずに、独立したネットワークへ識別の差を与える。RFC 5375が合併や漏出への耐性を利点として挙げるのはこのためだ。接続時に直ちに改番する可能性を減らせる。

しかし、改番が不要になるとは書かれていない。RFC 4193は、ULAを世界規模で経路化することを勧めない。唯一性を保証する機関がなく、集約もできないからだ。実際に同じIDが接続境界の両側にあれば、通信不能だけでなく誤配送も起こり得る。発生がまれでも、影響まで小さいとは限らない。

Brian Habermanの位置づけにも同じ慎重さが要る。RFCはHindenとの共著であり、多数の貢献者を謝辞に記す。IETFの公式IPv6ワーキンググループ写真ページはHaberman本人を識別し、Hindenとともに終了した同グループの議長だったことを示す。Internet Societyは2026年8月、同氏を理事会議長、FastlyのDistinguished Engineer、NetDevの運営メンバー、長年のIETF参加者として紹介した。人物の経歴は設計の背景を示すが、技術上の境界を証明するのはRFCである。

接続時に作るべき証跡

合併時の第一資料は、両側にある全てのULA /48一覧だ。本番だけでなく、検証環境、クラウド、災害復旧、休止中のVPN、予約済み範囲、設定ファイルに直書きされた値まで含める。値を実際に突き合わせる。確率は未知の相手に対する見通しであって、手元にある台帳を見ない理由ではない。

第二に、各プレフィックスの生成経緯を残す。生成時期、方法、システム識別子の種類、管理責任者があれば、後の重複を診断できる。機微な機器情報そのものを共有する必要はない。ただし、独立生成と、子会社へ同じテンプレートをコピーした状態は区別しなければならない。

第三に、経路の許可を個別化する。接続名、許可するプレフィックス、ネクストホップ、import/exportフィルター、監視担当、撤回手順を記録する。FC00::/7の残りが拒否され、インターネットのピアへULAが出ないことを試験する。

第四に、DNSとアドレス選択を確認する。両側のグローバルIDが異なっても、内部ゾーン名は衝突し得る。到達不能なULAをアプリケーションがグローバルアドレスより優先すれば、プレフィックスが異なっても障害になる。権威DNS、ビュー、リゾルバ経路、逆引き、選択ポリシーを接続判定に含める。

第五に、セキュリティ証跡を別欄に置く。誰を認証するのか、どの規則が許可するのか、どの経路源を信じるのか、どのログで追跡するのか。「ULAである」は、どの問いへの回答にもならない。

最後に切り戻し条件を先に定める。同一IDが見つかれば片側を改番する。外部への経路漏出なら広告を止める。逆引きが外へ出ればリゾルバ経路を隔離する。直書きアドレスを修正できなければ接続自体を延期する。低確率の例外を扱えることが、実行可能な設計の条件だ。

Heng LuのRunning-Code Primacyに従えば、台帳や構成図は管理上の証拠にすぎず、実際の経路表、パケット経路、DNS応答、アプリケーション試験が動作を決める。Minimum Initial Specificationが示すのは、そのために共有すべき最小限の情報である。ローカル設計を奪わず、接続の可逆性だけは共同で証明する。

40ビットは中央集権の代用品ではない。自治したネットワーク同士が高い確率で共存できるようにし、実際に境界を共有する瞬間だけ、具体的な調整を要求する設計なのである。

情報源