AWS で試して学ぶ IPv6
822 Views
January 08, 26
スライド概要
BuriKaigi 2026
2026/1/9 14:20- Room 203（マス）
AI による要約（一部調整）：
本セッションでは、IPv6 の現状と利用状況を踏まえ、AWS の VPC 環境を段階的に構築し、サーバーとクライアントのIPv6 対応（デュアルスタック、NAT64/DNS64 対応）までを実践的に学びます（ULA 割り当てについてはオプション）。IPv4 アドレスの枯渇と AWS 課金状況、IPv6 アドレスの割り当てと日本における利用率の上昇も解説し、環境構築手順は別資料で提供しています。
Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book https://speakerdeck.com/hmatsu47
関連スライド
各ページのテキスト
AWS で試して学ぶ IPv6 BuriKaigi 2026 2026/1/9 14:20- Room 203（マス） まつひさ（hmatsu47）
自己紹介 松久裕保（@hmatsu47） ● https://qiita.com/hmatsu47 ● 現在： ○ 名古屋で Web インフラのお守り係をしています ○ SRE チームに所属しつつ技術検証の支援をしています ○ 普段カンファレンス・勉強会では DB の話しかしていません （ほぼ） 2
自己紹介 松久裕保（@hmatsu47） ● https://qiita.com/hmatsu47 ● 現在： ○ 名古屋で Web インフラのお守り係をしています ○ SRE チームに所属しつつ技術検証の支援をしています ○ 普段カンファレンス・勉強会では DB の話しかしていません （ほぼ）でした 3
本日のお題 ● すでに身近なところで使われているのに、あまり馴染み のない IPv6 について、AWS で VPC 環境を作り、変更を 加えながら学んでいきます 4
ただし ● セッションの場でハンズオンを進行すると 30 分では足り ないので、環境の構築手順は別資料（Zenn）で示します ○ https://zenn.dev/hmatsu47/books/burikaigi2026-aws-ipv6-study 5
おしながき（1/2） 別資料（Zenn）→ ● IP アドレス（グローバルアドレス）利用の現況について ● セッションで使用する VPC・リソースについて ● ①IPv4 環境の作成（初期状態）と IPv4 についておさらい ● ②サーバー環境の IPv6 対応 ● ③クライアント環境の IPv6 対応（デュアルスタック編） ● ④クライアント環境の IPv6 対応（NAT64/DNS64 編） 6
おしながき（2/2） 別資料（Zenn）→ ● ⑤サーバー環境のターゲットを IPv6（ULA）化 （オプション） ● その他 AWS サービスの IPv6 対応状況など ● おわりに 142130 7
IP アドレス（グローバルアドレス） 利用の現況について 8
1. IPv4 アドレスの現況 9
新規割り当て用のアドレスブロックはほぼ枯渇 ● RIR（地域インターネットレジストリ）の IPv4 アドレス在庫 ● AFRINIC（アフリカ地域） ・APNIC（アジア太平洋地域）を 除くと利用可能（Available）な アドレスの在庫はすでに 0 ● AFRINIC・APNIC 合計で残り 約 400 万個（2025Q3 時点） 出典 : https://www.nro.net/wp-content/uploads/NRO-Number-Resource-Status-Report-Q3-2025-FINAL.pdf 10
現在は新規割り当て＜移転 ● 「割り当て済みだが未使用」のアドレスブロックを移転 ● 当初は RIR 内のみ移転可 出典 : https://www.nro.net/wp-content/uploads/NRO-Number-Resource-Status-Report-Q3-2025-FINAL.pdf 11
現在は新規割り当て＜移転 ● 「割り当て済みだが未使用」のアドレスブロックを移転 ● 現在は RIR 間も移転可 ● 総量は横ばい〜微減傾向 出典 : https://www.nro.net/wp-content/uploads/NRO-Number-Resource-Status-Report-Q3-2025-FINAL.pdf 12
「割り当て済みだが不使用」アドレスの状況は？ ● ルート未広告のアドレスブロックは 2024 年末に大幅減 ● このとき Amazon が広告ルート追加 ● すぐに放出できるアドレスブロックが 減ったとすれば、移転についても当面は 増加が期待できない雰囲気 出典 : https://blog.apnic.net/2025/01/13/ip-addresses-through-2024/ 13
AWS では？ ● すべてのパブリック IPv4 アドレスの利用に対して 1 IP アドレスあたり 0.005 USD/hour が課金されるように ○ 2024 年 2 月 1 日より ○ https://aws.amazon.com/jp/blogs/news/new-aws-public-ipv4-address-cha rge-public-ip-insights/ ○ CloudFront などはサービス本体の料金以外に課金なし 142345 14
2. IPv6 アドレスの現況 15
IPv6 アドレスの割り当て状況 ● 地域差はあるがそれなりに進んでいる ● LACNIC（ラテンアメリカおよび カリブ海地域）が先行 ○ ● 割り当て済み /48 ブロック 数も LACNIC が突出 全 RIR 合計で 1,500 万個以上 の /48 ブロックが割り当て済 み（2025Q3 時点） 出典 : https://www.nro.net/wp-content/uploads/NRO-Number-Resource-Status-Report-Q3-2025-FINAL.pdf 16
肝心の利用状況は？ ● 見えないところで利用が進んでいる（日本のケース） ● 2023 年に 50% を超えた ● ここ 2 年で IPv6 Capable が 60% に迫っている データの出典 : APNIC Labs Measurements and Data / https://labs.apnic.net/measurements/ IPv6 Capable は「IPv6 に到達できた端末の割合」・IPv6 Preferred は「デュアルスタックで IPv6 が選ばれた割合」 17
肝心の利用状況は？ ● モバイルは MNO 4 社中 3 社が 80% 超え ● AS 番号で判断しているので Softbank は非モバイル回線が 対象に含まれているかも？ ● 手元の端末で当セッションの サーバー環境にアクセスして 実際に試すと（手元になかった 楽天を除く） MNO 3 社とも IPv6 アドレスが表示された データの出典 : APNIC Labs Measurements and Data / https://labs.apnic.net/measurements/ IPv6 Capable は「IPv6 に到達できた端末の割合」・IPv6 Preferred は「デュアルスタックで IPv6 が選ばれた割合」 18
ここまでのまとめ（1/2） ● IPv4 アドレスブロックの新規割り当ては（RIR レベルでは） ほぼ終了。現在は移転の割合が大きくなっている ○ 移転も横ばい〜微減傾向 ● AWS では 2 年前からすべてのパブリック IPv4 アドレス に対して課金されるようになった ○ CloudFront などは除く 19
ここまでのまとめ（2/2） ● IPv6 アドレスの利用は年々増えている ○ 日本では特にモバイル回線での利用が進んでいる 142530 20
セッションで使用する VPC・リソースについて 21
IPv4 VPC から 段階的に IPv6 対応していく 22
①IPv4 VPC 環境（初期状態） ● 2 種類の VPC 環境を作成 ○ サーバー用 VPC 環境 ■ VPC・ALB・EC2（Web サーバー）など ○ クライアント用 VPC 環境 ■ VPC・VPC エンドポイント ・EC2（クライアント）な ど 23
②サーバー環境の IPv6 対応 IPv6（GUA）割り当て ALBデュアルスタック化 IPv6デフォルトルート追加 24
③クライアント環境の IPv6 対応（デュアルスタック） IPv6（GUA）割り当て EIGW作成 IPv6デフォルトルート追加 25
④クライアント環境の IPv6 対応（NAT64/DNS64） まずはIPv6(GUA)専用環境を作成 VPCエンドポイント 付け替え EC2（クライアント）作成 IPv6（GUA）専用サブネット作成 ＆ルートテーブル作成・ IPv6デフォルトルート追加 26
④クライアント環境の IPv6 対応（NAT64/DNS64） VPCエンドポイント 付け替え サブネット・EC2作成後、 ・NAT64用ルートをルートテーブ ルに追加 ・サブネットでDNS64有効化 EC2（クライアント）作成 IPv6（GUA）専用サブネット作成 ＆ルートテーブル作成・ IPv6デフォルトルート追加 27
⑤サーバー環境のターゲットを IPv6（ULA）化 IPv6（ULA） 割り当て 注：この構成はセッションで説明しません ULA プール 作成 ALBターゲット変更 IPv6（ULA）専用サブネット 作成＆ルートテーブル作成 ＆EC2（サーバー）作成 142700 28
①IPv4 環境の作成（初期状態）と IPv4 についておさらい 29
IPv4 VPC 環境（初期状態） ● 2 種類の VPC 環境を作成 ○ サーバー用 VPC 環境 ■ VPC・ALB・EC2（Web サーバー）など ○ クライアント用 VPC 環境 ■ VPC・VPC エンドポイント ・EC2（クライアント）な ど 30
サーバー用 VPC および関連リソース作成（1/4） VPCをウィザードで作成 ・パブリックサブネット x2 ・プライベートサブネット x2 ・インターネット GW ・その他（RT・SG・NACL） 31
サーバー用 VPC および関連リソース作成（2/4） EC2インスタンス起動 ・Webサーバーx2 →ユーザーデータで nginx+PHPの起動を指定 （HTTP_X_FORWARDED_FOR を表示） AWS 日本語版ハンズオン（当 スライド最終ページ参考資料 を参照）の手順を借用 32
サーバー用 VPC および関連リソース作成（3/4） ALB作成 ・IPv4のみ ・ターゲットグループ作成 ・ターゲット登録 33
サーバー用 VPC および関連リソース作成（4/4） ● ブラウザからアクセスして動作確認 ○ ALB の DNS 名をコピー ○ http://【コピーしたパス】/index2.php でアクセス 34
クライアント用 VPC・関連リソース作成（1/4） VPCをウィザードで作成 ・プライベートサブネット x2 ・インターネット GW ・NAT GW（Regional） ・その他（RT・SG・NACL） 35
クライアント用 VPC・関連リソース作成（2/4） EC2接続用 VPCエンドポイント作成 36
クライアント用 VPC・関連リソース作成（3/4） EC2インスタンス起動 ・SSH用キーペアあり （ED25519） 37
クライアント用 VPC・関連リソース作成（4/4） ● curl コマンド（curl -v4）で接続テスト ○ EC2 Instance Connect で EC2 クライアントにプライベート IP 接続 $ curl -v4 http://【先ほどコピーしたパス】 /index2.php * Host ipv4-to-dualstack-XXXXXXXX.ap-northeast-3.elb.amazonaws.com:80 was resolved. * IPv6: (none) * IPv4: 15.XX.XX.95, 15.XX.XX.67 * Trying 15.XX.XX.95:80... * Connected to ipv4-to-dualstack-XXXXXXXX.ap-northeast-3.elb.amazonaws.com (15.XX.XX.95) port 80 （中略） <html><h1>HTTP_X_FORWARDED_FOR: 56.XX.XX.235</html></h1> * Connection #0 to host ipv4-to-dualstack-XXXXXXXX.ap-northeast-3.elb.amazonaws.com left intact 142840 38
IPv4 について（軽く）おさらい 39
IPv4 アドレスの構成 ● 全 32 ビット・8 ビットずつ「.」区切り・十進表記 ○ ネットワーク部とホスト部に分かれる ○ クラスレスアドレス表記では「/」で区切ってネットワーク部の ビット長を記す（CIDR 表記） ● 例：192.168.0.1/24 40
IPv4 アドレスの種類（セッション関係分のみ） ● プライベートアドレス ○ 組織内で自由に割り当てて使うアドレス ○ 10.0.0.0/8・172.16.0.0/12・192.168.0.0/16 の範囲 ● リンクローカルアドレス ○ AWS の VPC では本来とは違う用途で利用（IMDS・リゾルバなど） ● グローバルアドレス（インターネット直接接続可） ○ IP アドレス管理組織（RIR など）から割り当てを受けて使う 41
IPv4 アドレスの種類（セッション関係分のみ） ● プライベートアドレス ○ 組織内で自由に割り当てて使うアドレス AWSでは 「パブリックIPアドレス」 と表現 ○ 10.0.0.0/8・172.16.0.0/12・192.168.0.0/16 の範囲 ● リンクローカルアドレス ○ AWS の VPC では本来とは違う用途で利用（IMDS・リゾルバなど） ● グローバルアドレス（インターネット直接接続可） ○ IP アドレス管理組織（RIR など）から割り当てを受けて使う 42
IPv4 アドレスの割り当て方法 ● 固定割り当て（ユーザー自身による） ● DHCP(v4) ○ デフォルトゲートウェイ・DNS サーバー（リゾルバ）などのアドレ スも DHCP サーバーから取得 43
NAT（ネットワークアドレス変換） ● プライベートアドレスとグローバルアドレスを変換し、 プライベートアドレスしか持たないホストからのイン ターネットアクセスを可能にする技術 ○ 静的 NAT : Elastic IP アドレス ○ 動的 NAT（の一種）: 通常のパブリック IP アドレス ○ NAPT : NAT ゲートウェイ ■ 143040 複数のプライベートアドレスから 1 つのパブリックアドレスを共用 44
②サーバー環境の IPv6 対応 45
構成変更のねらい ● ALB をデュアルスタック化することで、インターネット から IPv4・IPv6 の両方でアクセス可能にする ○ Web サーバーについては IPv4 のまま変更なし ○ ただしアプリケーション側での IPv6 アドレス対応は必要 ■ 画面表示、データ保存領域、アドレスの比較など 46
サーバー環境の IPv6 対応 IPv6（GUA）割り当て ALBデュアルスタック化 IPv6デフォルトルート追加 47
1. IPv6（GUA）割り当て ● VPC に IPv6 CIDR ブロックを追加 ● パブリックサブネットに IPv6 CIDR ブロックの一部を割 り当て ○ 2 つの AZ で 48
2. ALB デュアルスタック化（1/2） ● 新規セキュリティグループ作成 49
2. ALB デュアルスタック化（2/2） ● ALB に新規セキュリティグループを割り当て ● ALB をデュアルスタック化 50
3. IPv6 デフォルトルート追加 ● パブリックサブネットのルートテーブルに追加→完成！ 143230 51
サーバー環境の IPv6 対応 補足説明 52
ALB のデュアルスタック化？ ● IPv6 は IPv4 とは互換性がない ○ IPv6 と IPv4 は直接通信を行うことができない ● 両方が動作する状態に構成＝デュアルスタック ○ ALB をデュアルスタック化しておけばターゲット Web サーバー を IPv6 対応にする必要はない ■ ただしアプリケーション側の対応は必要（後述） 53
IPv6 アドレスの構成 ● 全 128 ビット・16 ビットずつ「:」区切り・十六進表記 ○ 前半 64 ビットをサブネットプレフィックス、後半 64 ビットを インターフェース識別子（IID）と呼ぶ ○ 長くなるので省略ルールがある ■ 16 ビット区切りのフィールドの先頭で連続する 0 は省略可 ■ 連続する 16 ビットフィールドの 0 は「::」で省略可（1 か所のみ） ● 例：2001:db8::2:0:1/64 54
IPv6 グローバルユニキャストアドレス（GUA） ● 全世界で一意に割り当てられたアドレス ○ IPv4 のグローバルアドレス相当 ● IPv4 のプライベートアドレスに相当するアドレスとして ユニークローカルユニキャストアドレス（ULA）がある ○ ただし IPv6 ULA と GUA の間での NAT は非推奨 ■ AWS の NAT ゲートウェイでも非サポート ■ インターネットアクセスが必要なら GUA を割り当てる必要がある 55
アプリケーション側で必要な対応 ● 文字数が増える分の表示領域・データサイズ調整が必要 ○ IPv4 ならサブネット長なしで最大 15 文字、ありで最大 18 文字 ○ IPv6 ではサブネット長なしで最大 39 文字、ありで最大 42 文字 ○ DB で IP アドレス専用のデータ型を使わない場合も注意 ● 文字列として IPv6 を比較する場合、一意な表記（または 省略なしの表記）にしないと正しく比較できない ○ RFC 5952 で一意に表記する方法が示されている 56
ここまでのまとめ（1/2） ● サーバー環境を IPv6 対応にするには境界で中継する箇所 をデュアルスタック化する ○ ALB など ○ パブリック側サブネットに IPv6 アドレス（GUA）を割り当てる ● アプリケーション側での IPv6 アドレス対応を忘れずに ○ 最大文字数、一意な表記（または省略なし）での比較など 57
ここまでのまとめ（2/2） ● セキュリティグループやルートテーブルも忘れずに IPv6 の通信を流せるようにしておく ○ NACL を使っている場合は NACL も 143440 58
③クライアント環境の IPv6 対応 （デュアルスタック編） 59
構成変更のねらい ● プライベートサブネットおよび EC2 クライアントをデュ アルスタック化し、インターネットに IPv6 アクセス可能 にする ○ IPv6 用経路として Egress Only インターネットゲートウェイを 作成 60
クライアント環境の IPv6 対応（デュアルスタック） IPv6（GUA）割り当て EIGW作成 IPv6デフォルトルート追加 61
1. IPv6（GUA）割り当て（その 1） ● 対象サブネットのパブリック／プライベートの違いを除 いてサーバー環境と同じ手順 ○ VPC に IPv6 CIDR ブロックを追加 ○ プライベートサブネットに IPv6 CIDR ブロックの一部を割り当て 62
2. Egress Only インターネットゲートウェイを作成 ● ● ● ● ● IPv4 プライベートサブネットの NAT ゲートウェイと同じ立ち位置 63
3. IPv6 デフォルトルート追加 ● プライベートサブネットのルートテーブルに追加 64
4. IPv6（GUA）割り当て（その 2） ● EC2（クライアント）に IPv6 アドレスを追加→完成！ ○ EC2 を停止 ○ IPv6 アドレス（GUA）を割り当て ○ EC2 を起動（開始） 65
5. curl コマンドで接続テスト（1/2） ● IPv4（curl -v4）で試す ○ ALB の URL 宛てにアクセス $ curl -v4 http://【ALBのパス】 /index2.php * Host ipv4-to-dualstack-XXXXXXXX.ap-northeast-3.elb.amazonaws.com:80 was resolved. * IPv6: (none) * IPv4: 15.XX.XX.95, 15.XX.XX.67 * Trying 15.XX.XX.95:80... * Connected to ipv4-to-dualstack-XXXXXXXX.ap-northeast-3.elb.amazonaws.com (15.XX.XX.95) port 80 （中略） <html><h1>HTTP_X_FORWARDED_FOR: 56.XX.XX.235</html></h1> * Connection #0 to host ipv4-to-dualstack-XXXXXXXX.ap-northeast-3.elb.amazonaws.com left intact 66
5. curl コマンドで接続テスト（2/2） ● IPv6（curl -v6）で試す ○ ALB の URL 宛てにアクセス $ curl -v4 http://【ALBのパス】 /index2.php * Host ipv4-to-dualstack-XXXXXXXX.ap-northeast-3.elb.amazonaws.com:80 was resolved. * IPv6: 2406:XX:XX:6401:42fc:d75a:1696:583c, 2406:XX:XX:6400:16de:a21e:34f6:e1ab * IPv4: (none) * Trying [2406:XX:XX:6401:42fc:d75a:1696:583c]:80... * Connected to ipv4-to-dualstack-XXXXXXXX.ap-northeast-3.elb.amazonaws.com (2406:XX:XX:6401:42fc:d75a:1696:583c) port 80 （中略） <html><h1>HTTP_X_FORWARDED_FOR: 2406:XX:XX:4b00:ba1d:1fff:c7e0:a236</html></h1> * Connection #0 to host ipv4-to-dualstack-XXXXXXXX.ap-northeast-3.elb.amazonaws.com left intact 143820 67
クライアント環境の IPv6 対応 （デュアルスタック編） 補足説明 68
クライアント環境のデュアルスタック化 ● クライアント自身が IPv4・IPv6 それぞれの通信スタック を使って相手のホストと通信する ○ 外部の IPv4 ホスト宛ての通信は IPv4 デフォルトルートで NAT ゲートウェイに流す ○ 外部の IPv6 ホスト宛ての通信は IPv6 デフォルトルートで Egress Only インターネットゲートウェイ（EIGW）に流す ■ Egress Only インターネットゲートウェイで外からアクセスできないように 69
EC2 への IPv6 アドレスの割り当て ● 固定割り当て（ユーザー自身による） ● DHCP(v6) ● IPv6 の仕組みには、ほかにも SLAAC などがある ○ IID を MAC アドレスから生成する方法とランダムなものを一定時 間で切り替える Temporary ID 方式がある ○ DHCP を使う方法にもステートレス・ステートフルがある ○ IPv4 より複雑 70
IPv4・IPv6 のどちらを優先する？ ● 現在は「IPv4・IPv6 の両方（ほぼ）同時にアクセスを試 行して、最初に応答したほうを選択する」仕組みが主流 ○ Happy Eyeballs ■ 現在は RFC 8305 によるバージョン 2 が広く使われる ■ 実質的に IPv6 が優先される ■ QUIC 対応を意図したバージョン 3 の策定も進行中 71
ここまでのまとめ（1/2） ● クライアント環境をデュアルスタック化すると、クライ アント自身が IPv4・IPv6 の通信を使い分ける形になる ○ IPv4 は NAT ゲートウェイ、IPv6 は Egress Only インターネット ゲートウェイに流す形でルーティングする ● Egress Only インターネットゲートウェイは IPv4 におけ る NAT ゲートウェイと同等の使い勝手を提供する 72
ここまでのまとめ（2/2） ● デュアルスタック環境のクライアントは「Happy Eyeballs」などの仕組みを使って IPv4・IPv6 のどちらを 使うかを決める 144200 73
④クライアント環境の IPv6 対応 （NAT64/DNS64 編） 74
構成変更のねらい ● IPv6 専用プライベートサブネットからインターネットに IPv4 アクセス可能にする ○ NAT64/DNS64 を使って NAT ゲートウェイで IPv6 to IPv4 変換 75
クライアント環境の IPv6 対応（NAT64/DNS64） まずはIPv6(GUA)専用環境を作成 VPCエンドポイント 付け替え EC2（クライアント）起動 IPv6（GUA）専用サブネット作成 ＆ルートテーブル作成・ IPv6デフォルトルート追加 76
1. IPv6（GUA）専用サブネット作成 ● プライベートサブネットを追加 ○ IPv6 CIDR ブロックのみを割り当て（IPv4 を割り当てない） ● ルートテーブルを作成して同サブネットにアタッチ ○ IPv6 デフォルトルート（::/0）を追加（EIGW へ） 77
2. VPC エンドポイントを付け替え ● EC2 インスタンス接続用エンドポイントを削除して新規 作成したサブネット上に作成 ○ クォータ上限に達していなければ削除せず作成だけで OK 78
3. EC2（クライアント）インスタンスを起動 ● 「高度なネットワーク設定」でプライマリ IPv6 IP を割 り当てる ○ セキュリティグループはこのインスタンス用に新規作成 79
4. curl コマンドで接続テスト ● EC2（クライアント）から ALB に接続テスト ○ この段階では IPv6 のみ通信可能で IPv4 には通信できない ● GitHub にも接続してみる ○ GitHub が IPv6 非対応→アクセスできない（2025 年 12 月現在） $ curl https://github.com/hmatsu47 curl: (7) Failed to connect to github.com port 443 after 1 ms: Could not connect to server 144330 80
クライアント環境の IPv6 対応（NAT64/DNS64） VPCエンドポイント 付け替え サブネット・EC2作成後、 ・NAT64用ルートをルートテーブ ルに追加 ・サブネットでDNS64有効化 EC2（クライアント）作成 IPv6（GUA）専用サブネット作成 ＆ルートテーブル作成・ IPv6デフォルトルート追加 81
5. ルートテーブルに NAT64 用のルートを追加 ● 64:ff9b::/96 宛てを NAT ゲートウェイへ ○ NAT ゲートウェイで IPv4 に変換（NAT64） 82
6. プライベートサブネットの DNS64 を有効化 ● 「DNS64 を有効化に」チェック→完成！ ○ Route 53 Resolver : IPv4（A）を 64:ff9b::/96 に変換（DNS64） 83
7. curl コマンドで接続テスト ● EC2（クライアント）から再び ALB に接続テスト ○ やはり curl -v4 では通信できない ● GitHub にも再度接続してみる ○ 今度はアクセスできた（IPv4 への NAT が成功） $ curl https://github.com/hmatsu47 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-0 <!DOCTYPE html> （中略） </html> 144500 84
NAT64/DNS64 での通信 ● EC2（クライアント）から Route 53 Resolver に正引き ○ AAAA レコード→そのまま IPv6 アドレスを返す ○ A レコードのみ→「64:ff9b::」に IPv4 アドレスを合成して返す ● ルートテーブルにしたがって通信を各ゲートウェイへ ○ NAT ゲートウェイで「64:ff9b」で始まるアドレス宛ての通信を IPv4 に変換して宛先へ 85
curl -v4 が失敗するのは？ ● EC2（クライアント）自身が IPv4 で NAT ゲートウェイに通 信できるわけではないから ○ Route 53 Resolver への問い合わせは IPv6 専用サブネット上の EC2 でも 169.254.169.253 に届く ■ https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/AmazonDNS-concepts.html#A mazonDNS ○ curl -v4 指定の場合 A レコード（IPv4 アドレス）がそのまま返る ■ NAT ゲートウェイ宛てには IPv4 で接続できない→エラー 86
ここまでのまとめ（1/2） ● IPv6 専用サブネットからインターネット上の IPv4 ホス トにアクセスするには NAT64/DNS64 の有効化を行う ○ DNS64 では A レコードの IPv4 アドレスを「64:ff9b」で始まる 特殊な IPv6 アドレスに変換して返す ○ NAT64 では「64:ff9b」で始まる IPv6 アドレス宛ての通信を IPv4 に変換して宛先に流す 87
ここまでのまとめ（2/2） ● IPv6 専用の VPC サブネットに置かれた EC2 でも IPv4 リンクローカルアドレス（IMDS・リゾルバ用）は有効になっ ている 144710 88
⑤サーバー環境のターゲットを IPv6（ULA）化 （オプション） 89
サーバー環境のターゲットを IPv6（ULA）化 IPv6（ULA） 割り当て 概要は別資料（右上QRコード）で ULA プール 作成 ALBターゲット変更 IPv6（ULA）専用サブネット 作成＆ルートテーブル作成 ＆EC2（サーバー）作成 90
概要は別資料にて ● IP Adress Manager（IPAM）を使ってユニークローカルユ ニキャストアドレス（ULA）をプライベートサブネットに 割り当て 144750 91
その他 AWS サービスの IPv6 対応状況など 92
各サービスの IPv6 対応状況 ● AWS 公式ユーザーガイドで確認 ○ AWS services that support IPv6（English） ■ https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-support.html ■ 「Dual stack support」が「Yes」→ IPv4・IPv6 の両方でアクセスが可能 ■ IPv6 専用エンドポイントをサポートするサービスも増えている ○ ここ数年で IPv6 をサポートするサービスは増加 93
実際にパブリック IP(v4) アドレスは節約できる？ ● 「接続先が固定的」なサービスについては IPv6 化による パブリック IP(v4) アドレスの節約は可能 ○ Site-to-Site VPN など ● 実際にはデュアルスタック VPC が必要なケースも残る ○ IPv4 全廃はもちろん IPv4 料金の掛からないマネージドサービス への完全移行も難しいケースはまだある 94
パブリック IP(v4) アドレス使用状況の確認方法は？ ● IP Address Manager（IPAM） ○ 144850 パブリック IP に関するインサイト 95
おわりに 96
AWS の IPv6、意外と簡単かも？ ● IPv4 とあまり変わらない使い勝手になっている ○ 「IPv6 同士の NAT がない」点を除いて ● AWS は「IPv6 の難しいところ」をいい感じに隠蔽 ○ 例えば ■ ホストへの IPv6 アドレスの割り当て方 ■ 利用可能なルーターの探索 ■ 近隣ホストの探索（ARP の代わりに ICMPv6 を使う） など 97
まずは ● 難しい部分を抜きにして当セッションを「入口」として 活用していただければ幸いです 98
参考資料 ● Internet Number Resource Status Report As of 30 September 2025（NRO RIR Statistics） ● IP addresses through 2024（APNIC Blog） ● APNIC Labs Measurements and Data ● AWS IPv6 Hands On (japanese) ● ほかに EKS などをカバーする英語版ワークショップ （Get hands-on with IPv6）もあり 99
- https://www.nro.net/wp-content/uploads/NRO-Number-Resource-Status-Report-Q3-2025-FINAL.pdf
- https://www.nro.net/about/rirs/statistics/
- https://blog.apnic.net/2025/01/13/ip-addresses-through-2024/
- https://blog.apnic.net/
- https://labs.apnic.net/measurements/
- https://catalog.us-east-1.prod.workshops.aws/workshops/025ae486-39d3-4de4-a12b-049970983d18/ja-JP
- https://catalog.workshops.aws/ipv6-on-aws/en-US