Share
Embed
Transcript
99 slides
-
自己紹介 松久裕保(@hmatsu47) • https://qiita.com/hmatsu47 • 現在: ◦ 名古屋で Web インフラのお守り係をしています
◦ SRE チームに所属しつつ技術検証の支援をしています ◦ 普段カンファレンス・勉強会では DB の話しかしていません (ほぼ) 2 -
自己紹介 松久裕保(@hmatsu47) • https://qiita.com/hmatsu47 • 現在: ◦ 名古屋で Web インフラのお守り係をしています
◦ SRE チームに所属しつつ技術検証の支援をしています ◦ 普段カンファレンス・勉強会では DB の話しかしていません (ほぼ)でした 3 -
おしながき(1/2) • IP アドレス(グローバルアドレス)利用の現況について • セッションで使用する VPC・リソースについて • ①IPv4 環境の作成(初期状態)と
IPv4 についておさらい • ②サーバー環境の IPv6 対応 • ③クライアント環境の IPv6 対応(デュアルスタック編) • ④クライアント環境の IPv6 対応(NAT64/DNS64 編) 6 別資料(Zenn)→ -
おしながき(2/2) • ⑤サーバー環境のターゲットを IPv6(ULA)化 (オプション) • その他 AWS サービスの IPv6
対応状況など • おわりに 7 142130 別資料(Zenn)→ -
新規割り当て用のアドレスブロックはほぼ枯渇 10 • 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 -
• 「割り当て済みだが未使用」のアドレスブロックを移転 現在は新規割り当て<移転 11 • 当初は RIR 内のみ移転可 出典 :
https://www.nro.net/wp-content/uploads/NRO-Number-Resource-Status-Report-Q3-2025-FINAL.pdf -
• 「割り当て済みだが未使用」のアドレスブロックを移転 現在は新規割り当て<移転 12 • 現在は RIR 間も移転可 • 総量は横ばい〜微減傾向
出典 : https://www.nro.net/wp-content/uploads/NRO-Number-Resource-Status-Report-Q3-2025-FINAL.pdf -
• ルート未広告のアドレスブロックは 2024 年末に大幅減 「割り当て済みだが不使用」アドレスの状況は? 13 • このとき Amazon が広告ルート追加
• すぐに放出できるアドレスブロックが 減ったとすれば、移転についても当面は 増加が期待できない雰囲気 出典 : https://blog.apnic.net/2025/01/13/ip-addresses-through-2024/ -
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 などはサービス本体の料金以外に課金なし 14 142345 -
IPv6 アドレスの割り当て状況 16 • 地域差はあるがそれなりに進んでいる • LACNIC(ラテンアメリカおよび カリブ海地域)が先行 ◦ 割り当て済み
/48 ブロック 数も LACNIC が突出 • 全 RIR 合計で 1,500 万個以上 の /48 ブロックが割り当て済 み(2025Q3 時点) 出典 : https://www.nro.net/wp-content/uploads/NRO-Number-Resource-Status-Report-Q3-2025-FINAL.pdf -
肝心の利用状況は? 17 • 見えないところで利用が進んでいる(日本のケース) • 2023 年に 50% を超えた •
ここ 2 年で IPv6 Capable が 60% に迫っている データの出典 : APNIC Labs Measurements and Data / https://labs.apnic.net/measurements/ IPv6 Capable は「IPv6 に到達できた端末の割合」・IPv6 Preferred は「デュアルスタックで IPv6 が選ばれた割合」 -
肝心の利用状況は? 18 • モバイルは 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 が選ばれた割合」 -
ここまでのまとめ(1/2) • IPv4 アドレスブロックの新規割り当ては(RIR レベルでは) ほぼ終了。現在は移転の割合が大きくなっている ◦ 移転も横ばい〜微減傾向 • AWS
では 2 年前からすべてのパブリック IPv4 アドレス に対して課金されるようになった ◦ CloudFront などは除く 19 -
①IPv4 VPC 環境(初期状態) 23 • 2 種類の VPC 環境を作成 ◦
サーバー用 VPC 環境 ▪ VPC・ALB・EC2(Web サーバー)など ◦ クライアント用 VPC 環境 ▪ VPC・VPC エンドポイント ・EC2(クライアント)な ど -
④クライアント環境の IPv6 対応(NAT64/DNS64) 27 VPCエンドポイント 付け替え IPv6(GUA)専用サブネット作成 &ルートテーブル作成・ IPv6デフォルトルート追加 EC2(クライアント)作成
サブネット・EC2作成後、 ・NAT64用ルートをルートテーブ ルに追加 ・サブネットでDNS64有効化 -
IPv4 VPC 環境(初期状態) 30 • 2 種類の VPC 環境を作成 ◦
サーバー用 VPC 環境 ▪ VPC・ALB・EC2(Web サーバー)など ◦ クライアント用 VPC 環境 ▪ VPC・VPC エンドポイント ・EC2(クライアント)な ど -
サーバー用 VPC および関連リソース作成(2/4) 32 EC2インスタンス起動 ・Webサーバーx2 →ユーザーデータで nginx+PHPの起動を指定 (HTTP_X_FORWARDED_FOR を表示)
AWS 日本語版ハンズオン(当 スライド最終ページ参考資料 を参照)の手順を借用 -
サーバー用 VPC および関連リソース作成(4/4) 34 • ブラウザからアクセスして動作確認 ◦ ALB の DNS
名をコピー ◦ http://【コピーしたパス】/index2.php でアクセス -
クライアント用 VPC・関連リソース作成(4/4) 38 • 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 -
IPv4 アドレスの構成 40 • 全 32 ビット・8 ビットずつ「.」区切り・十進表記 ◦ ネットワーク部とホスト部に分かれる
◦ クラスレスアドレス表記では「/」で区切ってネットワーク部の ビット長を記す(CIDR 表記) • 例:192.168.0.1/24 -
IPv4 アドレスの種類(セッション関係分のみ) 41 • プライベートアドレス ◦ 組織内で自由に割り当てて使うアドレス ◦ 10.0.0.0/8・172.16.0.0/12・192.168.0.0/16 の範囲
• リンクローカルアドレス ◦ AWS の VPC では本来とは違う用途で利用(IMDS・リゾルバなど) • グローバルアドレス(インターネット直接接続可) ◦ IP アドレス管理組織(RIR など)から割り当てを受けて使う -
IPv4 アドレスの種類(セッション関係分のみ) 42 • プライベートアドレス ◦ 組織内で自由に割り当てて使うアドレス ◦ 10.0.0.0/8・172.16.0.0/12・192.168.0.0/16 の範囲
• リンクローカルアドレス ◦ AWS の VPC では本来とは違う用途で利用(IMDS・リゾルバなど) • グローバルアドレス(インターネット直接接続可) ◦ IP アドレス管理組織(RIR など)から割り当てを受けて使う AWSでは 「パブリックIPアドレス」 と表現 -
NAT(ネットワークアドレス変換) 44 • プライベートアドレスとグローバルアドレスを変換し、 プライベートアドレスしか持たないホストからのイン ターネットアクセスを可能にする技術 ◦ 静的 NAT :
Elastic IP アドレス ◦ 動的 NAT(の一種): 通常のパブリック IP アドレス ◦ NAPT : NAT ゲートウェイ ▪ 複数のプライベートアドレスから 1 つのパブリックアドレスを共用 143040 -
構成変更のねらい • ALB をデュアルスタック化することで、インターネット から IPv4・IPv6 の両方でアクセス可能にする ◦ Web サーバーについては
IPv4 のまま変更なし ◦ ただしアプリケーション側での IPv6 アドレス対応は必要 ▪ 画面表示、データ保存領域、アドレスの比較など 46 -
1. IPv6(GUA)割り当て 48 • VPC に IPv6 CIDR ブロックを追加 •
パブリックサブネットに IPv6 CIDR ブロックの一部を割 り当て ◦ 2 つの AZ で -
ALB のデュアルスタック化? 53 • IPv6 は IPv4 とは互換性がない ◦ IPv6
と IPv4 は直接通信を行うことができない • 両方が動作する状態に構成=デュアルスタック ◦ ALB をデュアルスタック化しておけばターゲット Web サーバー を IPv6 対応にする必要はない ▪ ただしアプリケーション側の対応は必要(後述) -
IPv6 アドレスの構成 54 • 全 128 ビット・16 ビットずつ「:」区切り・十六進表記 ◦ 前半
64 ビットをサブネットプレフィックス、後半 64 ビットを インターフェース識別子(IID)と呼ぶ ◦ 長くなるので省略ルールがある ▪ 16 ビット区切りのフィールドの先頭で連続する 0 は省略可 ▪ 連続する 16 ビットフィールドの 0 は「::」で省略可(1 か所のみ) • 例:2001:db8::2:0:1/64 -
IPv6 グローバルユニキャストアドレス(GUA) 55 • 全世界で一意に割り当てられたアドレス ◦ IPv4 のグローバルアドレス相当 • IPv4
のプライベートアドレスに相当するアドレスとして ユニークローカルユニキャストアドレス(ULA)がある ◦ ただし IPv6 ULA と GUA の間での NAT は非推奨 ▪ AWS の NAT ゲートウェイでも非サポート ▪ インターネットアクセスが必要なら GUA を割り当てる必要がある -
アプリケーション側で必要な対応 56 • 文字数が増える分の表示領域・データサイズ調整が必要 ◦ IPv4 ならサブネット長なしで最大 15 文字、ありで最大 18
文字 ◦ IPv6 ではサブネット長なしで最大 39 文字、ありで最大 43 文字 ◦ DB で IP アドレス専用のデータ型を使わない場合も注意 • 文字列として IPv6 を比較する場合、一意な表記(または 省略なしの表記)にしないと正しく比較できない ◦ RFC 5952 で一意に表記する方法が示されている -
ここまでのまとめ(1/2) • サーバー環境を IPv6 対応にするには境界で中継する箇所 をデュアルスタック化する ◦ ALB など ◦
パブリック側サブネットに IPv6 アドレス(GUA)を割り当てる • アプリケーション側での IPv6 アドレス対応を忘れずに ◦ 最大文字数、一意な表記(または省略なし)での比較など 57 -
構成変更のねらい • プライベートサブネットおよび EC2 クライアントをデュ アルスタック化し、インターネットに IPv6 アクセス可能 にする ◦
IPv6 用経路として Egress Only インターネットゲートウェイを 作成 60 -
1. IPv6(GUA)割り当て(その 1) • 対象サブネットのパブリック/プライベートの違いを除 いてサーバー環境と同じ手順 ◦ VPC に IPv6
CIDR ブロックを追加 ◦ プライベートサブネットに IPv6 CIDR ブロックの一部を割り当て 62 -
2. Egress Only インターネットゲートウェイを作成 • • • • • IPv4
プライベートサブネットの NAT ゲートウェイと同じ立ち位置 63 -
4. IPv6(GUA)割り当て(その 2) • EC2(クライアント)に IPv6 アドレスを追加→完成! ◦ EC2 を停止
◦ IPv6 アドレス(GUA)を割り当て ◦ EC2 を起動(開始) 65 -
5. curl コマンドで接続テスト(1/2) 66 • 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 -
5. curl コマンドで接続テスト(2/2) 67 • 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 -
クライアント環境のデュアルスタック化 • クライアント自身が 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 -
構成変更のねらい • IPv6 専用プライベートサブネットからインターネットに IPv4 アクセス可能にする ◦ NAT64/DNS64 を使って NAT
ゲートウェイで IPv6 to IPv4 変換 75 -
1. IPv6(GUA)専用サブネット作成 • プライベートサブネットを追加 ◦ IPv6 CIDR ブロックのみを割り当て(IPv4 を割り当てない) •
ルートテーブルを作成して同サブネットにアタッチ ◦ IPv6 デフォルトルート(::/0)を追加(EIGW へ) 77 -
4. curl コマンドで接続テスト • EC2(クライアント)から ALB に接続テスト ◦ この段階では IPv6
のみ通信可能で IPv4 には通信できない • GitHub にも接続してみる ◦ GitHub が IPv6 非対応→アクセスできない(2025 年 12 月現在) 80 $ curl https://github.com/hmatsu47 curl: (7) Failed to connect to github.com port 443 after 1 ms: Could not connect to server 144330 -
クライアント環境の IPv6 対応(NAT64/DNS64) 81 VPCエンドポイント 付け替え IPv6(GUA)専用サブネット作成 &ルートテーブル作成・ IPv6デフォルトルート追加 EC2(クライアント)作成
サブネット・EC2作成後、 ・NAT64用ルートをルートテーブ ルに追加 ・サブネットでDNS64有効化 -
5. ルートテーブルに NAT64 用のルートを追加 • 64:ff9b::/96 宛てを NAT ゲートウェイへ ◦
NAT ゲートウェイで IPv4 に変換(NAT64) 82 -
6. プライベートサブネットの DNS64 を有効化 • 「DNS64 を有効化に」チェック→完成! ◦ Route 53
VPC Resolver : IPv4(A)を 64:ff9b::/96 に変換 (DNS64) 83 -
7. curl コマンドで接続テスト • EC2(クライアント)から再び ALB に接続テスト ◦ やはり curl
-v4 では通信できない • GitHub にも再度接続してみる ◦ 今度はアクセスできた(IPv4 への NAT が成功) 84 $ 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 -
NAT64/DNS64 での通信 • EC2(クライアント)から Route 53 VPC Resolver に正引 き
◦ AAAA レコード→そのまま IPv6 アドレスを返す ◦ A レコードのみ→「64:ff9b::」に IPv4 アドレスを合成して返す • ルートテーブルにしたがって通信を各ゲートウェイへ ◦ NAT ゲートウェイで「64:ff9b」で始まるアドレス宛ての通信を IPv4 に変換して宛先へ 85 -
curl -v4 が失敗するのは? • EC2(クライアント)自身が IPv4 で NAT ゲートウェイに通 信できるわけではないから
◦ Route 53 VPC 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 -
各サービスの 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) ◦ パブリック IP
に関するインサイト 95 144850 -
AWS の IPv6、意外と簡単かも? • IPv4 とあまり変わらない使い勝手になっている ◦ 「IPv6 同士の NAT
がない」点を除いて • AWS は「IPv6 の難しいところ」をいい感じに隠蔽 ◦ 例えば ▪ ホストへの IPv6 アドレスの割り当て方 ▪ 利用可能なルーターの探索 ▪ 近隣ホストの探索(ARP の代わりに ICMPv6 を使う) など 97 -
参考資料 • 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