12. リナンバリングに関する考慮事項 (Renumbering Considerations)
IPv6 ネットワークは、インターネットサービスプロバイダー（ISP）の変更、企業合併、ネットワーク再編成など、さまざまな理由でリナンバリングが必要になる場合があります。近隣探索には、スムーズなリナンバリング操作を容易にする機能が含まれています。このセクションでは、IPv6 ネットワークのリナンバリングに関する考慮事項について説明します。
12.1. リナンバリングの概要 (Renumbering Overview)
ネットワークリナンバリングには、ネットワーク上のホストが使用する IPv6 アドレスプレフィックスを変更することが含まれます。IPv6 でのリナンバリングの主なメカニズムは以下の通りです：
- 新しいプレフィックスを持つ Router Advertisement: ルータは適切なライフタイムを持つ新しいプレフィックスをアドバタイズし、古いプレフィックスを段階的に廃止します。
- DHCPv6: IPv6 用の動的ホスト構成プロトコルも、リナンバリング中のアドレス割り当てを管理できます。
- ステートレスアドレス自動構成 (SLAAC): ホストは、ルータによってアドバタイズされた新しいプレフィックスに基づいて自動的に新しいアドレスを生成します。
12.2. Router Advertisement ベースのリナンバリング (Router Advertisement-Based Renumbering)
近隣探索の Router Advertisement メカニズムは、優雅なリナンバリングをサポートするように設計されています：
12.2.1. 新しいプレフィックスの導入 (Introducing New Prefixes)
新しいプレフィックスを導入する場合：
-
初期アドバタイズメント: ルータは以下を含む新しいプレフィックスのアドバタイズを開始します：
- Valid Lifetime: 妥当な期間に設定（例：2時間以上）
- Preferred Lifetime: 初期は Valid Lifetime と等しく設定
- A (Autonomous) フラグ: ホストが SLAAC を使用すべきことを示すために設定
-
共存期間: 古いプレフィックスと新しいプレフィックスの両方が同時にアドバタイズされ、以下が可能になります：
- 新しい接続が新しいアドレスを使用
- 既存の接続が古いアドレスを引き続き使用
- サービス中断なしの段階的移行
12.2.2. 古いプレフィックスの非推奨化 (Deprecating Old Prefixes)
古いプレフィックスを段階的に廃止するには：
-
Preferred Lifetime をゼロに設定: これにより、ホストは以下を行います：
- 新しい接続に古いプレフィックスの使用を停止
- 古いアドレスでの既存の接続を継続
- 非推奨のプレフィックスから新しいアドレスを生成しない
-
Valid Lifetime を削減: 既存の接続が完了できるように、Valid Lifetime を段階的に減少させます。
-
最終削除: Valid Lifetime が期限切れになるかゼロに設定されると、ホストはアドレスとプレフィックスを構成から削除します。
12.2.3. タイムラインの推奨事項 (Timeline Recommendations)
典型的なリナンバリングタイムラインは以下のようになります：
- 第0週: 古いプレフィックスと並行して新しいプレフィックスのアドバタイズを開始（両方とも優先）
- 第1-2週: 古いプレフィックスを非推奨化（Preferred Lifetime = 0、Valid Lifetime = 1週間）
- 第2-3週: 古いプレフィックスの Valid Lifetime の削減を継続
- 第3週以降: 古いプレフィックスのアドバタイズを完全に停止
正確なタイムラインは、ネットワーク要件、アプリケーション、および接続の性質に依存します。
12.3. 実装に関する考慮事項 (Implementation Considerations)
12.3.1. ホストの動作 (Host Behavior)
ホストは以下を行うべきです (SHOULD)：
- Router Advertisement を監視: 新しいプレフィックスとライフタイムの変更を学習するために、Router Advertisement を継続的に処理します。
- ライフタイムを尊重: 新しい接続の送信元アドレスを選択する際、Preferred および Valid Lifetime を尊重します。
- 優雅に非推奨化: プレフィックスが非推奨になった場合（Preferred Lifetime = 0）、新しい接続には使用しませんが、既存の接続は維持します。
- 期限切れのアドレスを削除: Valid Lifetime が期限切れになったときにアドレスを削除します。
12.3.2. ルータの動作 (Router Behavior)
ルータは以下を行うべきです (SHOULD)：
- リナンバリングを調整: リンク上のすべてのルータは、一貫したプレフィックス情報をアドバタイズする必要があります。
- 保守的なタイマーを使用: サービスを中断することなくリナンバリングが完了するのに十分な時間を確保します。
- 進捗を監視: ネットワーク管理者は、スムーズな移行を確保するためにリナンバリングの進捗を監視する必要があります。
12.3.3. アプリケーションに関する考慮事項 (Application Considerations)
アプリケーションは以下のように設計すべきです：
- アドレス変更の処理: 長時間実行されるアプリケーションの存続期間中にアドレスが変更される可能性に備えます。
- 一時アドレスを優先: プライバシーに敏感なアプリケーションの場合、定期的に変更される一時アドレス [RFC4941] を使用します。
- Happy Eyeballs を実装: 移行期間中に古いアドレスと新しいアドレスの両方をサポートします [RFC8305]。
12.4. DHCPv6 とリナンバリング (DHCPv6 and Renumbering)
アドレス割り当てに DHCPv6 を使用する場合：
- リース時間: DHCPv6 サーバーは、古いアドレスと新しいアドレスのリース時間を調整することでリナンバリングを制御できます。
- RECONFIGURE メッセージ: サーバーは、RECONFIGURE メッセージを使用してクライアントに構成の更新と新しいアドレスの取得を指示できます。
- RA との調整: DHCPv6 ベースのリナンバリングは、一貫性を確保するために Router Advertisement と調整する必要があります。
12.5. DNS に関する考慮事項 (DNS Considerations)
リナンバリング中、DNS レコードを更新する必要があります：
- 新しいレコードを追加: 新しいアドレスの AAAA レコードを作成します。
- TTL を削減: キャッシュの問題を最小限に抑えるために、リナンバリング前に DNS レコードの Time-To-Live (TTL) を下げます。
- 古いレコードを維持: 移行期間中は古い AAAA レコードを利用可能に保ちます。
- 古いレコードを削除: リナンバリングが完了し、古いアドレスが使用されなくなった後、古い DNS レコードを削除します。
動的 DNS (DDNS) は、これをサポートするホストのこのプロセスを自動化できます。
12.6. 運用上の推奨事項 (Operational Recommendations)
ネットワークオペレーターは以下を行うべきです：
- 慎重に計画: タイムラインとロールバック手順を含む詳細なリナンバリング計画を作成します。
- コミュニケーション: リナンバリングスケジュールについてユーザーと利害関係者に通知します。
- 監視: ネットワーク監視ツールを使用してリナンバリングの進捗を追跡し、問題を特定します。
- テスト: 可能であれば、本番環境に展開する前にラボ環境でリナンバリング手順をテストします。
- 文書化: プレフィックス割り当てとリナンバリング履歴の文書を維持します。
12.7. マルチホーミングとリナンバリング (Multi-Homing and Renumbering)
マルチホームネットワーク（複数の ISP に接続）は、追加の課題に直面します：
- 複数のプレフィックス: ホストは複数のプレフィックスからのアドレスを同時に持つ場合があります。
- 送信元アドレス選択: 適切な送信元アドレス選択 (RFC 6724) は、アウトバウンド接続に適切なアドレスを選択するために重要です。
- プロバイダーフェイルオーバー: あるプロバイダーのプレフィックスが利用できなくなった場合、ホストは他のプレフィックスからのアドレスの使用にシームレスに移行する必要があります。
12.8. エンタープライズに関する考慮事項 (Enterprise Considerations)
エンタープライズネットワークの場合：
- 内部ナンバリング: 内部アドレス割り当ては、エッジプレフィックスよりも頻繁に変更する必要がない場合があります。
- ULA の使用: ユニークローカルアドレス（ULA、RFC 4193）は、ISP の変更とは独立した安定した内部アドレッシングを提供できます。
- NAT66: 一般的には推奨されませんが、一部のエンタープライズは NAT66 を使用して内部リナンバリングを外部の変更から分離する場合がありますが、これには重大な欠点があります。
12.9. 自動化とツール (Automation and Tools)
リナンバリングを容易にするために：
- 構成管理: 自動化された構成管理ツールを使用してルータ構成を更新します。
- 監視システム: リナンバリング関連の問題を検出するための監視を実装します。
- スクリプトと API: DNS 更新およびその他のリナンバリングタスクを自動化するためのスクリプトを開発するか API を使用します。
12.10. まとめ (Summary)
近隣探索の Router Advertisement メカニズムは、IPv6 ネットワークのリナンバリングに対する堅牢なサポートを提供します。プレフィックスライフタイムを慎重に管理し、ルータ、DHCPv6 サーバー、および DNS 間で変更を調整することにより、ネットワークオペレーターは最小限のサービス中断でスムーズな移行を達成できます。適切な計画、コミュニケーション、および監視は、成功したリナンバリング操作に不可欠です。