Azure VMware Solution(AVS) で NSX-T を使っていると、IPv6 をセグメントに割り当てたり、IPv6 クライアントから公開したりできるのかが気になります。結論から言うと、AVS は現時点で IPv6 をフルサポートとは言えず、設計は IPv4 前提で考えるのが安全です。
結論：AVS は IPv6 を「公式にフルサポート」とは言えない
まず押さえておきたいのは、「AVS は Azure 上で動く VMware だから、Azure の IPv6 機能をそのまま使える」とは限らない点です。AVS はマネージドサービスとして vCenter/NSX などの管理プレーンが提供され、ネットワークも Microsoft 側がプロビジョニング・制御する領域があります。そのため、製品としての NSX-T が持つ機能と、AVS としてサポートされる機能は同一ではありません。
公式情報としては、Azure Migrate の AVS アセスメント計算にて「AVS はエンドツーエンドの IPv6 インターネットアドレッシングを現在サポートしていない」と明記され、IPv6 が検出されたサーバーは Unsupported IPv6 として扱われます。
同じく Azure Migrate のトラブルシュートでも「AVS は IPv6 インターネットアドレスをサポートしない」とし、検出時は AVS チームへ連絡してガイダンスを受けるよう案内されています。
さらに Microsoft Q&A でも、NSX-T 利用を前提にした質問に対し「AVS は現時点で IPv6 をフルサポートしていない」と回答され、IPv6 が必須要件なら具体的なユースケースを添えてサポートに相談することが推奨されています。
「IPv6 対応」の論点を整理する：どの範囲を求めているかで答えが変わる
IPv6 は、議論のレイヤーがズレると結論もズレます。AVS で混ざりやすい論点を先に表で整理します。
| 論点 | 何を指すか | 設計で困りやすいポイント | AVS での現実的な扱い |
|---|---|---|---|
| ゲストOSのIPv6 | VM の OS に IPv6 アドレスを設定し、アプリが IPv6 を使う | 疎通できても「障害時にサポートされるか」は別問題 | 検証は可能でも、標準サポートの前提には置きにくい |
| NSX-T セグメントの IPv6 | NSX の論理セグメントや分散ルータで IPv6 を扱う | T0/T1、DNS、FW、LB、NAT など周辺機能が絡む | AVS の制御領域があるため、自由度とサポート範囲の確認が必要 |
| インターネット公開のIPv6 | IPv6 クライアントがインターネット経由で AVS 内ワークロードへ到達する | Public IP、WAF/LB、DNAT、ログ、DDoS、証明書が一気に絡む | “エンドツーエンド IPv6 インターネットアドレッシングは非サポート” と明記 |
| オンプレ/拠点とのIPv6接続 | ExpressRoute/VPN で IPv6 を経路交換し、相互通信する | ゲートウェイや Route Server、FW などの IPv6 対応差分 | 基盤側は IPv6 手段があるが、組み合わせ制約が多い |
| 管理プレーンのIPv6 | vCenter/NSX Manager/ESXi 管理ネットワーク自体が IPv6 を使う | マネージド領域で変更できない／サポート外になりやすい | AVS は RFC1918 の IPv4 ブロックを前提に計画される |
質問の多くは「インターネット公開（IPv6 クライアントからの到達）」に集約します。そしてこの部分は、公式情報でも Unsupported IPv6 として扱われています。
公式情報から読み解く：IPv6 は“制限事項”として扱うのが妥当
「AVS の公式ドキュメントに IPv6 の可否が明示されていない」という声は多いですが、実務では “書かれていない＝使える” ではありません。マネージドサービスは特に、周辺ドキュメントの制限記載（アセスメント/トラブルシュート/設計指針）から前提を読み解く方が確実です。
| 情報源 | 記載の趣旨 | 読み取りポイント（実務向け） |
|---|---|---|
| Azure Migrate：AVS アセスメント計算 | 「AVS はエンドツーエンドの IPv6 インターネットアドレッシングをサポートしない」 | 移行前提の適合判定で “Unsupported” 扱い＝サポート境界のシグナル |
| Azure Migrate：アセスメントのトラブルシュート | 「AVS は IPv6 インターネットアドレスをサポートしない。検出時は AVS チームへ」 | 運用上も “まずサポートへ” の扱い＝標準構成では想定外 |
| Microsoft Q&A（NSX-T 利用の質問） | 「AVS は IPv6 をフルサポートしていない。必須ならサポートへ」 | 現場の質問に対する公式コミュニティ回答として、判断材料になる |
| AVS ネットワーク計画チェックリスト | /22 のアドレスブロックや RFC1918 を前提にネットワークを計画 | 少なくとも AVS の基本設計は IPv4 前提で組まれている |
特にアセスメント系ドキュメントは「移行してもサポートされた状態で動くか」を判定する目的があるため、そこに IPv6 が Unsupported として出てくるのは重い事実です。
なぜ AVS では IPv6 が難しくなるのか：設計上の“境界”がある
AVS は VMware SDDC を Azure 上に提供しますが、オンプレ vSphere のように「ネットワークも自分でゼロから自由に構築できる」わけではありません。Tier-0 ルータが既定で提供されること、AVS と Azure の接続が ExpressRoute ベースであること、インターネットブレイクアウトやパブリック IP 周りが AVS 固有の実装になることなど、境界条件が複数あります。
その結果、「IPv6 を入れるとどこで終端するのか」「どの装置が IPv6 を理解し、ログを出し、サポートしてくれるのか」が曖昧になりやすいのが実態です。さらに Azure 側のネットワーク機能ですら、IPv6 は “デュアルスタック前提（IPv4 併存）” が残り、IPv6-only を許さない制約が明記されています。
よくある勘違い：Azure が IPv6 対応＝AVS も同じ、ではない
Azure Virtual Network は IPv6 機能を提供しており、ExpressRoute もプライベートピアリングに IPv6 を追加する手順が公開されています。
しかし、これらは「Azure のネットワーク基盤として IPv6 を扱える」という話であり、AVS の NSX-T セグメント～インターネットまでを エンドツーエンド に IPv6 でつなげ、問題が起きたときにサポートされるかは別問題です。AVS 側は少なくとも “IPv6 インターネットアドレスはサポートしない” という扱いが明記されています。
IPv6 が必須要件のときの現実解：IPv6 は Azure 側で終端し、AVS は IPv4 前提で運用する
業務要件として「対外的に IPv6 で公開しないといけない」「IPv6-only クライアントが存在する」という場合、AVS の中で無理に IPv6 を完結させようとすると、サポート境界を踏み抜くリスクが上がります。そこで実務で採られやすいのが、入口（フロントエンド）だけ IPv6 を受け、内部（AVS）へは IPv4 で流す という分離設計です。
ここで重要なのが「L4 と L7 でできることが違う」点です。Azure の IPv6 ロードバランサーは便利ですが、ロードバランシング自体はプロトコル変換（NAT64）をしない、と明記されています。つまり IPv6 の L4 入口を作っても、バックエンドが IPv4 だけだとそのままではつながりません。
一方で、L7 のプロキシ（HTTP/HTTPS）であれば、フロントで IPv6 を受けてバックエンドへ IPv4 で接続する構成が現実的です。例えば Azure Front Door は “エンドツーエンド IPv6” をうたいつつ、IPv6 クライアントからの要求を IPv4-only バックエンドへプロキシできる旨が、設計ガイダンスでも説明されています。
また Azure Application Gateway も、IPv6 フロントエンド（デュアルスタック）をサポートしつつ、バックエンド IPv6 アドレスは未サポート＝バックエンドは IPv4 前提、という制約が明記されています。結果として “IPv6→IPv4 の橋渡し” 役として使いやすいケースがあります。
IPv6 終端の選定早見表（AVS を IPv4 のまま使う前提）
| 入口の種類 | 代表例 | IPv6→IPv4 の“変換” | AVS との相性 |
|---|---|---|---|
| L7（HTTP/HTTPS プロキシ） | Azure Front Door、Application Gateway(v2) | 可能（プロキシとして IPv6 で受け、IPv4 で接続） | Web/API の公開に強い。AVS 側を IPv4 のまま維持しやすい |
| L4（ロードバランサ） | Standard Load Balancer | 不可（NAT64 しない） | バックエンドも IPv6（デュアルスタック）を受けられる構成なら検討 |
| NVA（自前ゲートウェイ） | デュアルスタック NVA、NAT64/プロキシ | 可能（NVA が翻訳） | 柔軟だが運用負荷が増える。サポート境界を設計で明確化する必要 |
構成イメージ（L7 終端の例）
インターネット（IPv6/IPv4）
↓（HTTPS）
Azure Front Door / Application Gateway（IPv6 で受ける・WAF/証明書/ログ）
↓（バックエンド接続は IPv4）
ExpressRoute 経由で AVS（NSX-T セグメントは IPv4）
↓
ワークロード
この方針なら「IPv6 を要求するのは Azure 側の公開ポイントまで」で止められます。AVS の中は IPv4 のままなので、AVS のサポート前提から大きく外れにくいのがメリットです。
| 設計パターン | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| Azure 側で IPv6 終端（推奨） | L7 で IPv6 を受け、AVS へは IPv4 で接続 | Web/API を IPv6 クライアントへ公開したい、AVS は IPv4 のまま | 選定するサービスの制約を要確認（例：Application Gateway は新規作成/デュアルスタック必須、IPv6 backend 非対応など） |
| AVS 内に NVA/Proxy を置いて翻訳 | AVS 側に NAT64/プロキシ等を置き、IPv6→IPv4 を吸収 | 非 HTTP 系プロトコル、アプリ改修が難しい | 運用負荷が増える。障害時の切り分けが難しく、サポート境界も要確認 |
| IPv6 必須ワークロードを別基盤へ分離 | IPv6 コア要件のシステムは Azure IaaS/PaaS 等で再設計 | 長期運用で IPv6 を前提に拡張したい | 移行コストは上がるが、将来の制約を抱え込みにくい |
ポイントは「IPv6 が必須＝AVS の中も IPv6 にする」ではなく、“どこで IPv6 を要求されているか” を分解して最小範囲で満たすことです。
Azure サポートに相談するときのチェックリスト
公式情報でも「IPv6 が検出されたら AVS チームに連絡しガイダンスを受ける」「IPv6 が必須なら相談する」旨が案内されています。
問い合わせを短距離で解決するために、最初から整理して伝えると効果的な項目をまとめます。
| 項目 | 具体例 | なぜ必要か |
|---|---|---|
| IPv6 が必要な理由 | IPv6-only 回線のユーザー、B2B 接続要件、IPv4 枯渇対策など | 代替策（終端/プロキシ/別サービス）を提案しやすくなる |
| 通信方向 | インバウンド（外→AVS）、アウトバウンド（AVS→外）、双方向 | “インターネットアドレス” の範囲に該当するかが変わる |
| 対象ワークロード | Web、API、メール、VPN、特定プロトコル、NVA など | L7/L4 の違いで適切な終端や翻訳方式が変わる |
| 公開/到達方式 | Azure 側で終端する、WAF が必要、DDoS/ログ要件など | 依存サービス（FW/Route Server/ER）の IPv6 制約が露出する |
| リージョン/構成 | リージョン名、AVS ノード種別、接続方式（ER/VPN/Global Reach） | 機能差・プレビュー・制限はリージョン差が出ることがある |
| “サポート”の定義 | 「動けばOK」なのか「障害時に Microsoft がサポートする」なのか | ここが曖昧だと、検証結果と期待値が噛み合わない |
検証・運用で詰まりやすいポイント
IPv6 を含むネットワークは、設計段階では成立しているように見えても、運用で詰まることが多いです。AVS の場合は特に「どこまでが自分の責任範囲か」を意識しておくと、トラブル時に楽になります。
- 切り分けの線引き：問題が AVS 側（NSX/Edge/ER）なのか、Azure 側の公開ポイントなのか、オンプレ側の経路/フィルタなのか。
- 周辺サービスの IPv6 制約：Azure Route Server や Azure Firewall など、IPv6 が未対応・制限ありのサービスが残っています。設計に混ぜると、IPv6 だけ“最後の一手前”で詰まります。
- IPv6-only を目指さない：Azure の IPv6 はデュアルスタック前提が残っており、NIC に IPv4 を必ず持たせる必要があるケースが明記されています。
- “インターネット公開”は L7 で考える：L4 のロードバランサーは NAT64 しないため、IPv6→IPv4 をしたいなら L7 プロキシ（Front Door/Application Gateway など）を候補に入れるのが現実的です。
もし “どうしても AVS 内で IPv6 を完結させたい” 場合は、検証前にサポートへ確認し、サポートされる構成かどうかを文面で残すのが安全策です。
まとめ：AVS の前提は IPv4。IPv6 は最小範囲で満たす
- AVS は公式情報上、IPv6 をエンドツーエンドでフルサポートとは言えず、IPv6 は制限事項として扱うのが妥当です。
- ネットワーク計画も RFC1918 の IPv4 ブロックを前提にしており、基本設計は IPv4 ベースです。
- IPv6 が必須のときは「フロントエンドのみ Azure 側で IPv6 を終端し、AVS 内は IPv4」で分離設計するのが現実的です（特に Web/API は L7 で）。
- 例外的に IPv6 を求める場合は、ユースケースと“サポートの定義”を明確にして Azure サポートへ相談するのが近道です。
コメント