本記事では、企業ネットワークにおける IPv6 移行プロジェクトの進め方を、デュアルスタック構成や設計の落とし穴を交えて詳しく解説します。IPv4 アドレス枯渇への対応だけでなく、将来のネットワーク拡張やクラウド連携を見据えて、IPv6 導入の基本方針を整理したい方におすすめの内容です。
IPv6移行プロジェクトの全体像
IPv6移行は「計画 → 検証 → 段階移行 → 運用定着」の4フェーズで進めるのが最も安全です。
IPv6はIPv4と構造が大きく異なるため、単純置き換えではなく段階的な導入が必要です。特に、デュアルスタック導入時のファイアウォール・DNS・RA の扱いを適切に管理しないと、意図しない経路選択や通信障害が発生することがあります。
IPv6移行の4フェーズ
- ① 調査フェーズ：現行機器の IPv6 対応状況を棚卸し
- ② 設計フェーズ：デュアルスタック方針、アドレス設計、DNS・ルーティング設計
- ③ 移行フェーズ：拠点・サービス単位で段階的に IPv6 を有効化
- ④ 運用フェーズ：監視・ログ・セキュリティ対応を IPv6 向けに拡張
特に重要なのが「フェーズ1の調査」です。IPv6 に未対応の機器が 1 台でもあると、通信断や片方向通信が発生し、業務影響につながるためです。
デュアルスタック方式が最も採用される理由
デュアルスタックは「IPv4 と IPv6 を併存させる」移行方式で、最も安全で業務影響を最小化します。
企業ネットワークでは、IPv6-only はまだ利用が難しく、DNS・アプリケーション・セキュリティ製品の多くが IPv4 向けに最適化されています。そのため、段階的な並行運用が現実的です。
デュアルスタックのメリット
- 段階移行ができ、業務影響を最小化できる
- IPv4-only のアプリケーションとも共存できる
- アドレス不足問題を即解消できる
- クラウド (AWS/Azure/GCP) の IPv6 サービスを利用しやすい
デュアルスタックの注意点（落とし穴）
- IPv6 が優先されるため、意図せず IPv6 経路で外部通信する場合がある
- FW/ACL の IPv6 ルールを作り忘れると通信が素通り or 完全遮断される
- DNS の AAAA レコードが不適切だとアプリが遅延する
- 帯域監視や NetFlow が IPv6 を拾えない場合がある
- RA（Router Advertisement）の誤配布でセグメント全体が混乱する
IPv6 導入時のトラブルの多くは、IPv6 のフィルタリング漏れ と DNS の設計不備 が原因です。
IPv6アドレス設計の基本
IPv6は 64ビットの固定プレフィックスが推奨され、セグメントごとに /64 を割り当てるのが基本設計です。
IPv6プレフィックス設計のポイント
- /48 または /56 を ISP から取得（企業ネットワークの標準）
- 各 VLAN に /64 を割り当てる（DHCPv6/SLAAC と相性がよい）
- サーバゾーンは静的 SLAAC を禁止し DHCPv6 固定割り当てにする
- RA ガードを設定し、不正ルータ広告を防ぐ
サーバ・FW・ネットワーク機器のアドレス設計
サーバや FW のアドレス体系は、以下を基本とします。
- FW の「外側インターフェース」に /64
- FW の「内側 VLAN」に /64 単位で割り当て
- サーバは DHCPv6 もしくは手動で固定割り当て
IPv6 はリンクローカルアドレスによるルーティングも可能ですが、運用の可観測性が低くなるため、サーバや FW ではグローバルユニキャストアドレス（GUA）の利用が推奨です。
DNS設計の落とし穴
IPv6 移行では DNS 設計が最重要項目です。 ここが不適切だとアプリケーションの遅延や接続失敗が頻発します。
DNSで必ず対応すべき項目
- AAAA レコードの登録は必要最小限にする
- 内部 DNS では IPv4/IPv6 の優先度を明確に設定する
- DNS フォワーダ設定が IPv6 に対応しているか確認
- DNSSEC の動作を確認（IPv6 との組み合わせで遅延が発生しやすい）
特にクラウドサービス（Microsoft 365 / Google Workspace）は AAAA レコードが優先されるため、途中の FW が対応していない場合はアクセス不能になります。
ファイアウォールとセキュリティ対策
IPv6 では IPv4 とは異なるセキュリティリスクがあるため、FW/UTM の設定を刷新する必要があります。
IPv6セキュリティのポイント
- IPv6アドレスは基本的にグローバルでインターネット到達可能
- ステートフルFWで IPv6 のアウトバウンドルールを必ず作る
- SLAAC を使う場合は RA ガードを有効にする
- DHCPv6 と RA の両方が動作する場合は競合を防ぐ
- ICMPv6 のフィルタリングは慎重に（遮断すると通信不能になる）
IPv6 は ICMPv6 に大きく依存しているため、IPv4 の感覚で ICMP を遮断すると通信断に直結します。
IPv6移行プロジェクトの具体的ステップ
1. 現環境の棚卸し
- ルータ・FW・L3SW の IPv6 対応状況
- サーバ・OS・アプリケーションの IPv6 対応
- 管理システム（監視、ログ、認証）
2. 設計（最重要フェーズ）
- アドレス計画（/48, /56, /64）
- デュアルスタックの VLAN 割り当て
- RA、DHCPv6 の方式決定
- FW/ACL の IPv6 ポリシー定義
- DNS（AAAA）登録の範囲決め
3. 検証
ラボ環境で以下を必ず検証します：
- IPv6 経路と IPv4 経路の優先度が意図通りになっているか
- IPv6 でのクラウドサービス利用可否
- FW のログが IPv6 パケットを取得できているか
- ICMPv6 の扱い、PMTU の動作
4. 段階移行
- まずは「管理外セグメント」から導入
- 次に「クライアント VLAN」へ展開
- 最後に「サーバ VLAN」へ展開
5. 運用体制の整備
- 監視ツールの IPv6 対応
- ログの保存・可視化（NetFlow v9, IPFIX）
- トラブルシューティング手順の更新
- 運用メンバの教育
よくあるIPv6移行の失敗例
- AAAA レコードを追加した瞬間サービスが遅くなる
- FW の IPv6 ルールが未設定で通信が素通り
- RA が複数機器から配布され VLAN 全体が混乱
- ICMPv6 を遮断し外部通信が不安定になる
- 監視が IPv6 パケットを拾えず障害検知が遅れる
これらはすべて、事前設計と検証で回避できます。
まとめ：IPv6移行は段階的に安全に進めるのが最適
IPv6移行は、デュアルスタックを採用し、DNS・FW・アドレス設計を適切に構築すれば、安全に段階移行できます。
特に注意すべきは以下の3点です：
- DNS（AAAA）を慎重に扱う
- FW/ACL の IPv6 ルールを必ず作る
- RA・DHCPv6 の方式を統一する
IPv6移行は一度きりの大規模プロジェクトではなく、数年スパンでの段階的な取り組みです。将来の拡張性と安定性を見据えて、着実に進めていきましょう。
