IPv6デュアルスタック段階移行｜既存サービス影響評価から切り替えとロールバック計画

なぜ今、段階移行なのか――IPv6デュアルスタックの現在地

IPv4アドレス枯渇問題が現実のものとなって久しいですが、多くの現場ではいまだに「IPv4専用のまま運用を続けている」か、「デュアルスタックを有効にしたものの、実質的にIPv4しか使っていない」という状態が散見されます。2026年現在、クラウドプロバイダー各社がIPv4パブリックIPの有料化や廃止方針を打ち出すなか、IPv6への移行は選択肢から必須事項へと位置づけが変わりつつあります。

しかし、「一気にIPv6へ切り替える」という方針は現場のリスクを不必要に高めます。デュアルスタック段階移行とは、IPv4とIPv6を並走させながら、サービス単位・ネットワーク経路単位で検証を重ねつつ移行を進める手法です。この手法を正しく実施するには、切り替え前の影響評価・手順の明確化・ロールバック計画の三つが揃っていることが前提になります。本稿ではこの三点を軸に、実務で使える手順を整理します。

切り替え前の影響評価――何が壊れるかを先に知る

移行作業を始める前に、既存サービスのIPv6対応状況を棚卸しすることが不可欠です。主な確認対象は次の三層です。

• アプリケーション層：ソケットの生成時にAF_INETを明示しているコードはIPv6では動作しません。PythonやJavaであればsocket.AF_INET6またはAF_UNSPECへの変更が必要です。また、ログやACLに埋め込まれたIPv4アドレスのハードコードも移行後に問題となります。
• ミドルウェア・デーモン層：nginxやApache httpdのListen設定、PostgreSQLのpg_hba.conf、MySQLのbind-addressなど、設定ファイル内でIPv4を明示している箇所を洗い出します。nginxの場合、listen 80;は暗黙的にIPv4のみを指します。
• ネットワーク・フィルタ層：iptablesルールはip6tablesに引き継がれません。nftablesへ移行済みの環境ではfamilyの指定を確認します。また、監視ツール（Prometheus exporterやSNMPポーラー）がIPv6エンドポイントへの接続に対応しているかも事前確認が必要です。

棚卸しのコマンドとして、ss -tlnpで現在リッスンしているソケットのプロトコルファミリを確認できます。出力の「Local Address」欄が0.0.0.0の場合はIPv4のみ、::の場合はIPv6（またはデュアルスタック）です。grep -r 'AF_INET[^6]' /path/to/appでコード内のIPv4決め打ちを抽出するのも有効です。

影響評価の結果は「対応済み」「設定変更で対応可」「コード改修が必要」「移行不可（IPv4固定継続）」の四段階に分類し、サービスごとにシートに落とします。「移行不可」のサービスについては、IPv4専用NATルールで継続運用する方針を明確にしておきます。

段階的切り替え手順――ホスト・サービス・経路の順で進める

ステップ1：ホストへのIPv6アドレス付与

Ubuntu 22.04以降やRHEL 9系ではNetworkManagerがデフォルトになっています。nmcliを使ってデュアルスタックを有効にする場合、ipv6.method autoでSLAAC（ステートレスアドレス自動設定）を有効にするか、ipv6.method manualでアドレスを固定します。本番環境では固定アドレスが推奨です。

nmcli con modify eth0 ipv6.method manual \
  ipv6.addresses "2001:db8::10/64" \
  ipv6.gateway "2001:db8::1" \
  ipv6.dns "2001:4860:4860::8888"
nmcli con up eth0

Debian系で/etc/network/interfacesを使う環境では、既存のiface定義はそのままに、同一インターフェースに対してinetとinet6の両エントリを記述します。systemd-networkdを使う環境では.networkファイルに[Network]セクション内でAddress=を二行並べることでデュアルスタックになります。

ステップ2：サービスのIPv6対応を有効化する

nginxのデュアルスタック化は設定ファイルへの追記で済みます。listen [::]:80;を追加するだけですが、Linuxカーネルのデフォルト設定（net.ipv6.bindv6only=0）の場合、IPv6ソケットがIPv4も兼ねるため重複バインドエラーが発生することがあります。この場合はlisten 80;を残しつつlisten [::]:80 ipv6only=on;とするか、/etc/sysctl.d/以下でnet.ipv6.bindv6only=1を設定してから両方を個別に宣言します。

SSHについては、OpenSSH 8.x以降はデフォルトでデュアルスタックに対応しています。sshd_configのListenAddressが指定されていない場合はそのままで動作します。明示的に指定している場合は0.0.0.0と::の両行を記述します。

ステップ3：DNSへのAAAAレコード追加とGlue設定

アプリケーションの対応が完了したら、DNSにAAAAレコードを追加します。Aレコードはそのまま残し、AAAAを追加する形にします。TTLは短め（300秒程度）に設定しておくと、問題発生時の切り戻しが早くなります。クライアントはHappy EyeballsアルゴリズムによってIPv6を優先しますが、IPv6到達性がない場合は自動的にIPv4にフォールバックします。

AAAAレコード追加後、dig AAAA example.comおよびcurl -6 https://example.comで疎通を確認します。到達性の確認にはping6（またはping -6）も使えますが、ICMPv6がファイアウォールで遮断されている環境では疎通があってもpingが通らないことがあるため、上位層でのアプリケーション確認を優先します。

検証フェーズ――サービスの動作を多角的に確認する

切り替え後の検証は、ネットワーク層・アプリケーション層・監視層の三つの観点で行います。

ネットワーク層では、ip -6 route showでデフォルトルートが正しく設定されているか確認します。また、traceroute6 8.8.8.8で実際のパスを確認し、意図しないIPv4変換（NAT64など）が挟まっていないかを見ます。

アプリケーション層では、実際のエンドポイントへのHTTPリクエストをcurlの-6オプション付きで実行し、レスポンスコード・レイテンシ・エラーログを確認します。nginxやApacheのアクセスログに::ffff:プレフィックスが付いたアドレスが記録されている場合、IPv4マップドIPv6アドレスを介した接続であることを意味します。これは正常動作ですが、ログ集計ツールやIPベースのACLが誤動作する可能性があるため、フィルタ側の対応が必要な場合があります。

監視層では、PrometheusやZabbixのターゲット定義がIPv6アドレスに対応しているかを確認します。PrometheusのScrape対象URLをIPv6アドレスで記述する場合は[2001:db8::10]:9100のようにブラケットで囲む必要があります。Node exporterはデフォルトでデュアルスタックに対応しています。

ロールバック計画――切り戻しを「儀式」ではなく「手順」にする

ロールバックは「問題が起きたら考える」ではなく、移行前に手順を確定させておくものです。段階移行の利点のひとつは、IPv4の設定を消さずに並走させているため、ロールバックがシンプルになる点です。

DNSレベルのロールバックは、AAAAレコードを削除または無効化するだけです。TTLを短く設定していれば、変更がDNSキャッシュに伝播するまでの時間を最小化できます。クライアント側のDNSキャッシュにはsystemd-resolvedのフラッシュ（resolvectl flush-caches）が有効です。

サービスのロールバックは、設定ファイルの変更を元に戻してサービスを再起動するだけです。nginxならnginx -tで設定を事前検証してからsystemctl reload nginxで反映できます。設定ファイルはgitで管理しておくと、git diffとgit stashだけで素早く切り戻せます。

ネットワーク層のロールバックでは、IPv6アドレスの削除はip -6 addr del 2001:db8::10/64 dev eth0で即時実行できます。NetworkManager経由で設定した場合はnmcli con modify eth0 ipv6.method disabledを実行した後に接続を再起動します。カーネルパラメータnet.ipv6.conf.all.disable_ipv6=1をsysctlで一時的に適用する方法もありますが、これはすべてのインターフェースに影響するため慎重に使います。

ロールバックの実施判断基準も事前に定義しておくことが重要です。「IPv6経由での接続エラー率が5%を超えた場合」「特定サービスのレイテンシが通常の200%を超えた場合」といった数値基準を設けると、現場での判断が素早くなります。

2026年の現行環境における差分と注意点

2026年現在、主要ディストリビューションにおけるIPv6関連の挙動でとくに注意が必要な点をいくつか挙げます。

Ubuntu 24.04（Noble Numbat）以降では、systemd-networkdがデフォルトのネットワーク管理デーモンとして採用されるケースが増えています。NetworkManagerとsystemd-networkdが混在している環境では、インターフェースの管理主体がどちらかをnetworkctl statusで確認してから設定を変更します。両者が同一インターフェースを管理しようとすると競合が発生します。

RHEL 9系（およびAlmaLinux・Rocky Linux 9系）では、nftablesがデフォルトのパケットフィルタとなっており、iptablesはnftablesのラッパーとして動作します。IPv6のフィルタルールを追加する際はnft add rule ip6 filter INPUT ...の形式を使うか、firewalldを経由して設定します。firewall-cmd --zone=public --add-service=http --permanentはIPv4とIPv6の両方に自動的にルールを追加するため、firewalldを使っている環境では個別に気にする必要はありません。

コンテナ環境（Dockerおよびcontainerd）では、IPv6のデフォルト対応が環境によって大きく異なります。Docker Engineはデフォルトでは/etc/docker/daemon.jsonに"ipv6": trueと"fixed-cidr-v6"を明示しないとIPv6を有効にしません。KubernetesのデュアルスタックはIPAMの設定に加え、kube-proxyのmode設定によっても挙動が変わるため、クラスタ単位での移行計画が必要です。

クラウド環境では、AWSのVPCはデュアルスタック設定がサブネット単位でコントロールされており、既存のIPv4専用サブネットにIPv6 CIDRを後付けで割り当てることができます。ただし、セキュリティグループのルールはIPv4とIPv6で独立しているため、IPv4側のルールをIPv6側にも複製する必要があります。この点を見落とすと、IPv6経由でのアクセスがすべて拒否される状態になります。

IPv6デュアルスタック移行は、ネットワーク・アプリケーション・監視の各層を横断する作業です。影響評価・段階的手順・検証・ロールバック計画の四つを揃えることで、既存サービスへの影響を最小化しながら移行を進められます。現行環境の差分を把握したうえで、まず開発環境や非本番ホストでの検証から始めることが、現場での安定した移行の第一歩になります。