要約

  • IPv6再番号付けは一つの経路コマンドではない。旧・新プレフィックスを重ね、経路、フィルター、アドレス、DNS、アプリケーション依存をそれぞれの速度で移す「先行構成後の切替」である。
  • 運用上の推論：優先・有効存続期間、DHCPv6の委任プレフィックスの存続期間、RDNSS/DNSSL、DNSの正・負キャッシュ、送信元選択、長時間セッションは一つの変更境界を作る。撤去は、宣言した依存のうち最も遅いものの収束が証明されてから承認すべきである。
  • 切り戻しはプロトコルが保証する原子的処理ではない。旧プレフィックス、逆引きゾーン、両方の通信経路を管理できる間に実地で証明する必要がある。

すでに分裂している切り替え

上位接続を変える支店を考える。新しい集約経路は外部から見え、権威DNSには新AAAAレコードがある。監視プローブも新アドレスへ到達する。それでも支店ルーターは旧委任プレフィックスを保持し、ある再帰リゾルバーは旧回答をキャッシュし、データベースの確立済みセッションは旧アドレスに結び付いている。旧アドレスが非推奨になれば新規フローはそれを避けるが、既存セッションは自動移動しない。

各サブシステムの報告は正しい。経路は動き、DNSは変わり、クライアントには新アドレスがあり、サービスにも届く。それでも全体が危険なのは、報告が異なる時計を見ているからだ。

RFC 4192は、旧プレフィックスを稼働させたまま新プレフィックスを配備し、安定した二重状態を作り、利用を移し、最後に旧側を外す手順を示す。同文書は環境に合わせる骨格であり、万能の自動化ではない。機構が存在しても、変更の完了証明は運用者に残る。

プレフィックスは経路以外にも埋まる

IPv6アドレスはリンク設計、ルーターIF、Router Advertisement、DHCPv6、プレフィックス委任、ingress/egressフィルター、ACL、サービス設定、正引き・逆引きDNS、許可リスト、監視先、アプリケーションキャッシュに現れる。RFC 6879は、手動設定、長時間セッション、担当チームの直接管理外にあるシステムも問題になると整理している。

したがってインベントリーは証拠である。リテラル検索が空でも十分ではない。アドレスはプレフィックスから生成され、プロセスのメモリーに残り、取引先のフィルターに複製され、移行中ずっと停止していた拠点に眠ることがある。記録には、どの面を誰がどの変更版に対して確認し、何が例外として残るかが要る。

優先状態、有効状態、使用中は別の状態

RFC 4862は自動設定アドレスに優先存続期間と有効存続期間を置く。前者が切れると非推奨、後者が切れると無効になる。RFC 6724の既定送信元選択は、利用可能な優先アドレスがあれば非推奨アドレスを避ける。

つまり旧プレフィックスを「非推奨」にすると新規通信の選択は変わるが、既存セッションの終了、保存済み相手先の更新、外部クライアントの古いAAAAキャッシュ消滅までは証明しない。一方で旧アドレスを有効なまま保つことは復旧面を残すが、プレフィックス別・通信の経過時間別に計測しなければ隠れた依存を温存する。

RFC 4862の2時間ルールは、認証されていないRAが残存する有効存続期間を急減させる動作も制限する。偽RAによるDoSを抑える保護だが、緊急指示が全ホストで一斉停止スイッチになるとは限らない。運用手順書はコントローラーの意図ではなくホストの実動作に合わせるべきだ。

拠点とリゾルバーは異なる時計を持つ

RFC 8415はDHCPv6アドレスと委任プレフィックスに優先・有効存続期間を持たせ、更新と再バインドも定める。顧客側ルーターが旧IA_PDを保持したまま、上位経路、SLAACホスト、権威ゾーンだけが移ることはあり得る。重複期間中に停止していた拠点は、未検証の状態で後から戻る。

RFC 8978は、急な再番号付けの後にSLAACの古いプレフィックスが残り得ることを扱う。RFC 9096は、委任プレフィックスの残存有効期間に合わせて、関連するRouter Advertisementの存続期間を調整することを勧める。これは運用上の考慮であり、全ての顧客側ルーターが同じように振る舞うという主張ではない。

DNSにはさらに複数の時計がある。AAAA/PTRのTTL、権威サーバー間の反映時間、RAで得るリゾルバーと検索リストの寿命は別々だ。RFC 8106はRDNSS/DNSSLに固有のlifetimeを定める。サービスを再番号付けすることと、そのサービスを探すDNSサーバーを再番号付けすることは別の移行である。

正の回答だけでは足りない。RFC 2308の負のキャッシュにより、新レコード作成前に問い合わせたリゾルバーは、公開後も期限まで「存在しない」と返し得る。AAAAのTTLだけを下げた変更票ではこの障害を囲えない。

RFC 4472は、長時間動作するアプリケーションがDNSの回答をレコードTTLより長く保持し得ることも指摘する。この観察はアプリケーションの実測を要請するが、普遍的なキャッシュ期間を定めるものではない。

RFC 4861が示すRouter Advertisementのルーター・プレフィックス情報も、ホストが時間をかけて解釈する。確認対象はルーターの送信設定ではなく、各ホストが実際に学んだ状態である。

収束は平均ではなく最大値で決まる

運用上の推論：有効なモデルは、未解決の経路、フィルター、PIO、IA_PD、RDNSS、正キャッシュ、負キャッシュ、アプリケーションのキャッシュ、セッション各時計の最大値に、そもそもタイマーを持たない静的例外を加えたものだ。

平均値では、停止中の支店、長い負キャッシュ、チケットでしか変えられない取引先ACL、起動時にしか名前解決しない機器が消える。分母は期間中に応答した装置ではなく、宣言済みの全依存と全観測地点でなければならない。

経路プローブは新プレフィックスの到達性、DNS問い合わせは一つのリゾルバーの現在回答、フローログは観測した利用を証明する。単独では撤去権限にならない。同じ変更版と例外台帳に結び付いて初めて判断材料になる。

情報源