要約

  • RFC 1900は、アドレスを変更する権限と、そのアドレスを参照する全システムを発見して直す能力とを切り分けた。
  • ドメイン名はハードコードを減らせるが、キャッシュの失効、再名前解決、ACLの更新、外部管理者の対応までを証明するものではない。
  • 後続RFCは、リナンバリングをルーター、DNS、DHCP、セキュリティ関連付け、管理ツール、アプリケーションAPI、組織外依存を横断する棚卸しへと具体化した。

変更命令より依存関係の方が大きい

RFC 1900が挙げたきっかけは日常的だった。ホストが別のサブネットへ移る。混雑したサブネットを分割する。組織がアドレス設計を改める。そして公共的な意味を持ったのがCIDRによる経路集約だった。プロバイダーは多数の顧客経路を一つの大きなブロックとして広報できる。顧客が離脱した後も旧ブロックの一部を使い続ければ、より詳細な経路を世界のルーティングシステムに保持させることになる。リナンバリングは、全体の集約性を守る代わりに、局所的な移行作業を引き受ける選択だった。

しかし、新プレフィックスを割り当て、旧プレフィックスを止める権限があっても、移行を完了させる単一の命令は存在しない。運用者はインターフェースと経路を変更できる。それでも、昔の担当者がファイアウォール規則、監視先、プリンター設定、ライセンスファイル、取引先の許可リストに旧アドレスを書いた事実までは自動的に見えない。

「リナンバリング」という短い語は、この非対称性を覆い隠す。変更判断は中央にあり、参照グラフは分散し、しかも列挙できるとは限らない。割当記録は番号の使用権を示す。経路はプレフィックスの到達可能性を示す。機器設定は一台の意図を示す。サービス試験は一度の実行結果を示す。互いに関連していても、どれか一つが残りすべてを内包するわけではない。

RFC 1900は当時の作業を、高価で、退屈で、誤りやすいと記し、ツールと文書化された経験が乏しいとも述べた。これは単にソフトウェアが未成熟だったという話ではない。発見できない参照は更新できず、アドレスの割当主体は、独立したシステムが作った参照の総索引を持たないという知識の限界だった。

DNSは結合を弱めるが、完了印は押さない

RFC 1900の最も長く残った助言は、名前とアドレスを分けることだった。DNSの名前空間はアドレス空間とは別物である。名前は比較的安定した機能や組織上の役割を表し、アドレスはインターフェースをトポロジー上に置く。設定が名前を保持し、利用時に解決すれば、変更を各ファイルへ複写せず、権威DNSへ集約できる。

ただし、それは状態の削減であって消滅ではない。権威DNSは自分のレコードを管理する。再帰リゾルバーは有効期間中の答えを保持する。アプリケーションは再解決するか、昨日の答えを握り続けるかを決める。逆引きはプロバイダー側にあるかもしれない。セキュリティ製品が結果をACLへ写し、取引先が運用者から見えない装置に番号を保存することもある。

動的DNS更新にも認証が必要で、変更を伝播できないシステムが残る。RFC 1900が勧めたのは、アドレス・リテラルを避け、可能ならFQDNを使い、DHCP、ルーター発見、サービス発見、認証済み動的更新を利用する設計だった。IPアドレスに結び付いたライセンスを避け、古い設定は管理されたデータ源から生成する。DNSを万能視するのではなく、変わり得る座標を同一性として埋め込む箇所を減らす考え方である。

セキュリティの関連付けにも寿命がある。成立時の条件が保たれて初めて同じ意味を持つ。アドレスが変わったのに、既存セッション、IPsec方針、送信元ベースの認証が以前と同じ主体を表すと決めつけることはできない。

警告はやがて棚卸し表になった

RFC 2071は、機器、DNS、SNMP、フィルター、アクセスリストを洗い出し、猶予期間を置くよう求めた。RFC 2072は計画範囲をさらに広げ、ネットワークがルーターだけではなく、サービス、管理系、手順にもアドレスを抱えていることを示した。

RFC 4192の「先に作り、後で壊す」手順は、IPv6サイトで新旧プレフィックスを一時的に併存させた。これは停止を減らす実行窓にはなるが、全参照の移行証明にはならない。DNSのTTL、管理境界、一つの設定しか持てない機器は例外を残す。併存期間と完了は別の事実である。

2010年のRFC 5887は、なお「リナンバリングには作業が必要」と題された。静的なホスト一台が移行を止め得る。読み取り専用媒体、URL、Cookie、プロキシ、ソケットAPI、ライセンス、独自ソフトにアドレスが埋まり、キャッシュが無期限に残る場合もある。257仕様中34件の明示的依存という調査は、標準中の存在を示したが、稼働中ソフトウェアすべての台帳ではない。非公開実装の中身は外から数えられなかった。

RFC 6879はFQDN、サービス発見、パラメーター化、体系的なDNS利用を改めて強調した。RFC 7010は自動化をプロビジョニング、発見、設定、監視の四群に分けたが、全体を更新する「一か所」は見つからなかった。送信元IPを機器の身元として扱うログ収集器さえあり、番号変更が運用履歴を別人の記録のように分断する可能性も指摘された。

歴史が示した完了条件は明快だ。文字列を置換するだけではない。関係する各面で参照を改め、サービス、セキュリティ、観測可能性が保たれたことを確かめる。新アドレスは移行できることを示すにすぎない。棚卸しと実測結果を結合して初めて、旧アドレスから離れたと言える。

出典