要約

  • RFC 1918の三つのIPv4ブロックは、IANAやレジストリとの調整なしに再利用できる。その番号が一意なのは、一企業または共同で調整する企業群の内側に限られる。
  • 二社が同じ私用アドレスを使っていても、隔離中は双方が正しい。合併や接続によって一意性を保つべき範囲が広がると、重複が顕在化し、リナンバリングなどの選択が必要になる。
  • 経路、変換、名前、認証、サービス結果は別々の証拠である。通信が成立したという表示だけでは、意図した相手に届いたと証明できない。

台帳を綴じると番号が曖昧になる

A社では 10.6.7.8 が勤怠サーバーを表し、B社では同じ値が工場の制御端末を表すとする。各社の経路表には一つの行き先しかなく、内部DNSも利用者に正しい答えを返す。両社とも、世界的な割り当てを二重に主張しているわけではない。そもそもRFC 1918は、この空間を複数の組織が使うことを予定している。

接続前の実際の識別子は「A社の範囲にある 10.6.7.8」だった。A社という前半を日常的に書かずに済んだのは、物理的・運用的な境界が代わりに保持していたからである。二社のネットワークを接続すると、ルーターには同じ宛先が二つ現れる。番号は壊れていない。省略していた範囲が必要になった。

RFC 1918の歴史は、単なる暗記表ではない。世界的な一意性が不要な機器には、局所的な一意性だけを確保するという協調費用の配分である。導入時の調整を軽くし、将来の境界変更時に整合費用を払う設計だった。

採用より先に反論があった

1994年3月のRFC 1597は、企業内のホストを外部接続の必要性で分けた。レジ、事務端末、表示装置、内部ルーターのインターフェースなど、多くの機器は組織内だけで通信できればよい。そこへ世界で一つしかない番号を配ることは、局所問題に世界的資源を使うことになる。

同年7月のRFC 1627は、この発想に異議を唱えた。今日閉じているホストが明日も閉じているとは限らない。企業は共同開発を行い、合併もする。既知のサービス、ライセンス、構成がアドレスへ固定されれば、変更は単純な再設定では終わらない。同文書はAppleでのリナンバリング例も挙げるが、本稿の資料だけではホスト数や費用、結果を独立に確認できない。ここで確実なのは、合併時の衝突が当時すでに論点だったことである。

1996年2月、RFC 1918はBCP 5としてRFC 1597とRFC 1627の双方を置き換えた。RFC 1627の著者だったEliot Learも新文書の著者に加わっている。最終文書は反論を消したのではない。私用空間の利点を選びながら、互いに調整していなかった私設インターネットを統合すると一部のアドレスが一意でなくなり、ホストのリナンバリングが必要になる、と明記した。

つまり、後年の事故から初めて分かった欠点ではない。リスクを把握したうえで採用された交換条件だった。

Private-Useは所有権の印ではない

対象は 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 の三ブロックである。企業はIANAやインターネット・レジストリと調整せずに使える。同じ空間を多くの企業が利用でき、番号は企業内、またはその空間を共同調整する企業群の内側でのみ一意になる。

現在のIANA特別用途レジストリも三つをPrivate-Useとし、Globally Reachableではないと記録している。これは最初に使った企業へ排他的権利を与える記録ではない。A社とB社のどちらが「本物の 10/8」か、という問い自体が制度に合わない。

一方、再利用を安全に保つには境界が揃っていなければならない。RFC 1918は私用経路を企業間リンクへ伝播させず、私用の送信元・宛先を持つパケットを越境させず、DNSレコードなど間接参照も企業内に留めるよう求めた。アドレスの範囲、経路の範囲、名前を見せる範囲が食い違えば、同じ番号に別の意味が流れ込む。

なお、RFC 1918は私用アドレスをセキュリティ機能とは位置づけていない。Security Considerationsは、セキュリティ問題を扱わないとする。外から経路がないことは、相手が誰かを確かめる認証とは別である。

合併条項が将来費用を示す

複数の私設インターネットを一つへ統合すると重複が生じ得る、という記述に加え、後から組織間でIP接続を確立する場合にも一意性が破られる危険があるとRFC 1918は警告した。内部サブブロックを無作為に選ぶ勧告は、偶然の一致を減らす工夫にすぎず、保証や優先順位ではない。

意思決定は「どちらが先に使ったか」ではなく、「どの変更を誰が実行し、どの結果を誰が検証できるか」で行う必要がある。リナンバリングする範囲、変換で橋を架ける範囲、プロキシを使うサービス、隔離を続ける領域を分けなければならない。

RFC 1918は、私用と公用の間でホストを移す際、IPアドレスだけでなくDNSや他ホストの構成参照も変わると述べる。DHCPは負担を軽くし得るが、ライセンスやアクセス制御、業務上の依存までを自動的に発見するものではない。

realmという言葉が省略部分を可視化した

RFC 2663は後にaddress realmを、アドレスが対象へ一意に割り当てられ、経路制御によって到達できるネットワーク領域と定義した。この語を使えば、衝突の構造を正確に表現できる。同じ数字は、realmが違う限り別々の識別子として働く。realmを統合したとき、数字だけでは不足する。

Traditional NATは領域の境界で表現を書き換えるが、内部空間と外部空間が重ならないことを前提にする。両側で同じ値が使われている場合、RFC 2663は送信元と宛先の双方を変換するtwice NATを説明する。これは各側から見て経路可能な別名を作る方法であり、元の番号を世界で一意にする方法ではない。

RFC 3022では、Basic NATがアドレス集合を対応づけ、NAPTがポートも対応づける。往路と復路は整合した変換状態を通らなければならず、別装置へ経路が移るとセッションが失敗し得る。ホストを変更せず外部へ接続できる一方、IPアドレスのエンドツーエンドな意味を失わせ、ネットワーク内の状態を増やす。

したがって変換表は単なる設定ではなく、出来事を説明する証拠になる。元のrealm、時刻、プロトコル、内側の表現、外側の表現、状態を保持した装置が揃わなければ、後から同じアドレスを見ても対象を特定できない。

正常応答が誤配送を隠す

RFC 5684は2010年のIndependent Submissionであり、IETF標準化過程の仕様ではない。多段NATや遠隔VPNで私用空間が重なる状況を扱い、mistaken end host identityという失敗を示した。上位ネットワークのDNSリゾルバーと下位のローカルホストが同じ番号なら、問い合わせは上流へ行かずローカルで配送されることがある。スプリットVPNでも、企業側のサービスと現地側のサービスが混同され得る。

この障害は、必ずしも「到達不能」と表示されない。別のホストが応答すれば接続試験は成功する。RFC 5684は対象シナリオについて、通知する重要サーバーへ重ならないアドレスまたは世界的に一意なアドレスを使うこと、送信元IPだけに頼らずエンドツーエンド認証を行うことを勧める。

同文書は発生率を示しておらず、すべての重複が乗っ取りになるとも言っていない。確立できるのは証拠の境界である。構成は本域での番号を、経路は転送先を、変換表は表現の対応を、資格情報は相手を、アプリケーション観測は業務結果を示す。一つの成功を五つの成功へ拡張してはならない。

100.64/10は別の境界契約である

RFC 6598は2012年、事業者のCGNと顧客宅内機器の間で使うShared Address Spaceとして 100.64.0.0/10 を設けた。企業向けのRFC 1918空間とは明確に区別される。IANAの現在の表では両方とも世界的に到達しない特別用途だが、予定された管理範囲が違う。

家庭、企業、事業者は一つの漠然とした「内側」ではない。それぞれ別の運用者と経路、名前、衝突条件を持つ。番号を再利用するなら、その番号が一意である範囲も運ばなければならない。

RFC 1918は一意性を軽視した文書ではない。一意性を必要な場所でだけ維持する文書だった。二つのネットワークは、別々に存在した過去についてどちらも正しい。境界が変わった現在については、realm、変換、認証または新しい番号を使って、共有できる一つの意味を作り直す必要がある。

出典