皆さん、こんにちは!技術の最前線でパケットと日々格闘しているSRE兼クラウドアーキテクトの〇〇(筆者名)です。
今回は、最近耳にすることが多くなった「IPv6」というキーワードと、それがもたらす新しいネットワークの世界、そして「IPv6オンリー」な環境で「IPv4の世界」とどうやってつながるのか?という、ちょっと未来感あふれるテーマに挑戦してみたいと思います。特に、「NAT64」と「DNS64」という二つの強力な味方に焦点を当てて、皆さんの目の前でパケットが実際にどう動くのかを、現実世界の例えを交えながら、優しく丁寧に紐解いていきますね。
「ネットワークは苦手…」と感じている方も、ご安心ください!難しい専門用語は極力噛み砕き、一歩ずつ、一緒に理解を深めていきましょう。
—
🚀 IPv6時代の幕開けと、まだ残るIPv4の世界の「壁」
皆さん、インターネットの住所である「IPアドレス」には、大きく分けて「IPv4」と「IPv6」の二種類がある、ということはご存知ですよね。
IPv4アドレスは「192.168.1.1」のようにドットで区切られた数字の羅列で、世界中で使える数が約43億個と限りがあります。実はもうずいぶん前にこのIPv4アドレスは枯渇してしまっていて、新しい機器やサービスをインターネットにつなぐのが難しくなっています。
そこで登場したのが「IPv6」です!IPv6アドレスは「2001:0db8:85a3:0000:0000:8a2e:0370:7334」のように、コロンで区切られた英数字の羅列で、その数はなんと約340澗(かん)個!宇宙の星の数よりも多い、まさに無限とも言えるアドレス空間を提供してくれます。
なぜ今、IPv6オンリー環境が注目されるのか?
IPv6はこれからのインターネットの標準となる技術であり、クラウドの世界でもその流れは顕実に加速しています。特に、AWSやGCPのようなメガクラウドプロバイダーは、リソースの効率的な利用や将来を見据えて、IPv6のみを割り当てられた仮想サーバー(EC2インスタンスなど)を簡単に作成できるようになっています。これを「IPv6オンリーインスタンス」と呼びます。
この「IPv6オンリーインスタンス」のメリットはたくさんあります。
- アドレス管理の簡素化: もうIPv4アドレスの枯渇を心配する必要がありません。
- ネットワーク設計の効率化: IPv4とIPv6両方のアドレスを考慮する「デュアルスタック」よりもシンプルに設計できます。
- セキュリティの向上: IPv6のプロトコルレベルで提供されるセキュリティ機能を利用できます。
しかし、ここで一つの大きな課題に直面します。
世の中のサービスやウェブサイトの中には、まだIPv4アドレスでしかアクセスできないものがたくさん残っている、という現実です。
「IPv6オンリーのインスタンスから、IPv4しか対応していない外部のウェブサービスにアクセスしたい…」
「でも、住所の形式が違うから直接は届かない!」
まるで、日本語しか話せない人が、英語しか話せない相手とコミュニケーションを取ろうとするような状況ですよね。この「言語の壁」をどう乗り越えるか、というのが今回のテーマです。
📬 郵便配達で理解する「デュアルスタック」と「NAT64/DNS64」
この「IPv4とIPv6の壁」を乗り越える方法はいくつかありますが、大きく分けて二つの考え方があります。
1. デュアルスタック(二ヶ国語対応):
- これは、インスタンス自身がIPv4アドレスとIPv6アドレスの両方を持つ、という状態です。
- 例えるなら、日本語も英語もペラペラな郵便配達員さんです。日本語の手紙も英語の手紙も、どちらの住所形式でも配達できます。
- メリットはシンプルで分かりやすいこと。デメリットは、インスタンスにIPv4アドレスを割り当てる必要があるため、IPv4アドレス枯渇問題の根本的な解決にはならないことです。
2. NAT64とDNS64(通訳と住所変換のプロ集団):
- 今回ご紹介する、IPv6オンリーインスタンスのための強力なソリューションです。
- 例えるなら、IPv6しか話せないインスタンス(日本人)のために、英語の住所をIPv6形式に変換してくれる「賢い電話帳(DNS64)」と、日本語で書かれた手紙を英語の宛先に書き換えてくれる「通訳兼郵便局員(NAT64)」が協力して、英語圏(IPv4の世界)に手紙を届けてくれるようなものです。
想像してみてください。あなたはIPv6オンリーのインスタンス。手元には、友達(IPv4しか対応していないウェブサービス)に送りたい手紙があります。でも、友達の住所はIPv4形式(英語)で書かれていて、あなたはIPv6形式(日本語)の住所しか理解できません。どうすればいいでしょうか?
ここで、DNS64とNAT64という二人のプロフェッショナルが活躍するんです!
—
📞 DNS64の役割:賢い電話帳、IPv4アドレスをIPv6形式で教えてくれる!
まずは、宛先を知る必要がありますよね。あなたは友達のウェブサイトのアドレス(例えば www.example.com)を知っていますが、それは名前でしかありません。実際の手紙を送るためには、具体的な住所(IPアドレス)が必要です。
① 友達の「名前」を「住所」に変換したい!
あなたは www.example.com にアクセスしたいとします。そこで、電話帳に当たる「DNSサーバー」に問い合わせます。
「ねえ、DNSさん、www.example.com の住所を教えて!」
② DNS64の魔法:IPv4住所を”見せかけの”IPv6住所に変換!
通常のDNSサーバーなら、もし www.example.com がIPv4アドレスしか持っていなければ、そのままIPv4アドレス(例: 198.51.100.1)を返してくるでしょう。しかし、あなたはIPv6しか理解できません。
ここで登場するのが「DNS64」です!
DNS64は、ちょっと特別な機能を持ったDNSサーバーです。
1. あなたが www.example.com の住所を問い合わせると、まず通常のDNSサーバーに問い合わせます。
2. もし www.example.com がIPv6アドレス(AAAAレコード)を持っていれば、それをそのままあなたに教えてくれます。
3. しかし、もし www.example.com がIPv4アドレス(Aレコード)しか持っていなかった場合、DNS64はすごいことをします!
- 取得したIPv4アドレス(例:
198.51.100.1)を、「見せかけのIPv6アドレス」に変換してあなたに返してくれるんです。 - この「見せかけのIPv6アドレス」は、特定のIPv6プレフィックス(通常は
64:ff9b::/96という特別な範囲)と、元のIPv4アドレスを組み合わせた形をしています。 - 例えば、
198.51.100.1は64:ff9b::c633:6401のようなIPv6アドレスに変換されて返ってきます。(c6は198、33は51、64は100、01は1を16進数に変換したものです)
あなたは「お、IPv6アドレスが返ってきた!これなら理解できるぞ!」と、この「見せかけのIPv6アドレス」を宛先として手紙(パケット)を書き始めます。
—
🚚 NAT64の役割:住所変換のプロフェッショナル!
あなたはDNS64から教えてもらった「見せかけのIPv6アドレス」を宛先として、手紙(パケット)を作成しました。
「よし、この手紙を 64:ff9b::c633:6401 (見せかけのIPv6住所)に送るぞ!」
この手紙は、ネットワークを旅して「NAT64ゲートウェイ」という特別な郵便局に到着します。
NAT64ゲートウェイは、まさに「通訳兼住所変換のプロフェッショナル」です!
① IPv6の手紙がNAT64に到着!
あなたのインスタンスから送られた手紙(IPv6パケット)は、宛先が 64:ff9b::/96 の範囲にあるため、あらかじめ設定されたルート(経路)を通ってNAT64ゲートウェイにルーティングされます。
② NAT64の仕事:IPv6パケットをIPv4パケットに変換!
NAT64ゲートウェイは、手紙を受け取ると、その中身をチェックします。
1. 宛先アドレスの変換:
- 手紙の宛先が「見せかけのIPv6アドレス」(
64:ff9b::c633:6401)であることを認識します。 - このIPv6アドレスの中から、元のIPv4アドレス(
198.51.100.1)を正確に抽出し、手紙の宛先をそのIPv4アドレスに書き換えます。
2. 送信元アドレスの変換:
- あなたのインスタンスの送信元IPv6アドレス(例:
2001:db8::10)を、NAT64ゲートウェイが持つIPv4アドレス(例:203.0.113.50)に書き換えます。 - これは、返事が来たときに、その返事をあなたのインスタンスまで正確に届けるために必要です。
3. パケットヘッダーの変換:
- IPv6パケットの構造をIPv4パケットの構造に変換します。これは、手紙のフォーマットを日本語から英語のフォーマットに完全に書き換えるような作業です。
この変換作業を経て、手紙は完全にIPv4形式に生まれ変わります。
③ IPv4の世界へ手紙を投函!
IPv4パケットに変換された手紙は、晴れてIPv4の世界(インターネット)へ旅立ち、無事に 198.51.100.1 の友達(ウェブサービス)のもとへ届きます。
④ 返事もバッチリ、元のインスタンスへ!
友達(ウェブサービス)は、届いた手紙の送信元がNAT64ゲートウェイのIPv4アドレス(203.0.113.50)だと認識し、そのアドレス宛に返事を出します。
この返事もNAT64ゲートウェイに到着すると、NAT64ゲートウェイは以前の変換情報を覚えていて、その返事を元のあなたのインスタンスのIPv6アドレス(2001:db8::10)宛のIPv6パケットに再度変換して、あなたに届けてくれるんです!
これで、IPv6オンリーのインスタンスでも、IPv4しか対応していない外部リソースと問題なく通信できるようになる、というわけです。素晴らしい連携プレイですよね!
—
🤝 NAT64とDNS64の協調動作:二人三脚でインターネットへ!
ここまでの話をまとめると、IPv6オンリーのインスタンスがIPv4サービスにアクセスする際の、DNS64とNAT64の二人三脚の旅は、以下のようになります。
1. インスタンス: 「www.example.com にアクセスしたいな。住所を教えて、DNSさん!」(IPv6リクエスト)
2. DNS64: 「了解! www.example.com はIPv4アドレスしか持ってないけど、君のために『見せかけのIPv6アドレス』(64:ff9b::c633:6401) に変換して教えてあげるよ!」
3. インスタンス: 「ありがとう!よし、このIPv6アドレス宛にパケットを送るぞ!」(送信元:インスタンスのIPv6、宛先:64:ff9b::c633:6401)
4. NAT64ゲートウェイ: 「やあ、手紙が届いたね!宛先は『見せかけのIPv6アドレス』だ。これはIPv4の世界に行く手紙だね!」
5. NAT64ゲートウェイ: 「じゃあ、宛先を元のIPv4アドレス(198.51.100.1)に、送信元を僕のIPv4アドレス(203.0.113.50)に書き換えて、IPv4パケットに変換だ!」
6. NAT64ゲートウェイ: 「さあ、IPv4の世界へ行ってらっしゃい!」(IPv4パケットをインターネットへ送信)
7. IPv4サービス: 「お、NAT64ゲートウェイさんから返事が来たぞ。返事を送ろう!」(IPv4パケットをNAT64ゲートウェイへ返信)
8. NAT64ゲートウェイ: 「お帰り!この返事は、さっきのインスタンス宛だね。元のインスタンスのIPv6アドレス宛に変換して送り返してあげよう!」
9. インスタンス: 「やった!無事に返事が来たぞ!」
この一連の流れが、皆さんのクラウド環境の裏側で、瞬時に行われているわけです。
—
🛠️ AWSでの具体的な設定イメージ:IPv6 Only Subnetの魔法
では、実際にAWS環境でこのNAT64とDNS64の仕組みをどう使うのか、少しだけ具体的に見ていきましょう。
AWSでは、このNAT64とDNS64の仕組みは「IPv6 Only Subnet」という機能を使うことで、非常に簡単に利用できるようになっています。
① IPv6 Only VPCの作成
まず、IPv6 CIDRブロックが関連付けられたVPC(仮想プライベートクラウド)を作成します。
# IPv6 Only Subnetを作成するために、IPv6 CIDRブロックを持つVPCを作成
aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--amazon-provided-ipv6-cidr-block \
--tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=MyIPv6OnlyVPC}]'
*補足:IPv6 Only SubnetはIPv4 CIDRブロックを持つVPC内でも作成可能ですが、ここでは理解のためIPv6 CIDRブロックを付与したVPCとしています。
② IPv6 Only Subnetの作成
最も重要なステップです。--ipv6-native オプションを指定してサブネットを作成すると、そのサブネットにはIPv4 CIDRブロックが割り当てられず、IPv6アドレスのみを持つインスタンスを起動できるようになります。
そして、AWSのすごいところは、このIPv6 Only Subnetを作成するだけで、自動的にDNS64とNAT64の機能が有効になる、という点です!ユーザーが明示的にNAT64ゲートウェイをプロビジョニングする必要はありません。
# 例: /64のIPv6 CIDRブロックを持つIPv6 Only Subnetを作成
# ※ VPCのIPv6 CIDRブロックの中から/64の範囲を指定します
aws ec2 create-subnet \
--vpc-id vpc-xxxxxxxxxxxxxxxxx \
--ipv6-cidr-block 2001:db8:abcd:1::/64 \
--ipv6-native \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=MyIPv6OnlySubnet}]'
③ Egress Only Internet Gateway (EIGW) の作成
IPv6 Only Subnet内のインスタンスがインターネット(IPv6の世界)へ出ていくためには、IPv6専用のゲートウェイが必要です。それが「Egress Only Internet Gateway (EIGW)」です。IPv4におけるNAT Gatewayに似ていますが、EIGWは「出ていく(Egress)」通信のみを許可し、外部からの直接の「入ってくる(Ingress)」通信はブロックします(セキュリティグループ等で制御しない限り)。
# Egress Only Internet Gatewayを作成
aws ec2 create-egress-only-internet-gateway \
--vpc-id vpc-xxxxxxxxxxxxxxxxx \
--tag-specifications 'ResourceType=egress-only-internet-gateway,Tags=[{Key=Name,Value=MyEIGW}]'
④ ルートテーブルの設定
最後に、IPv6 Only Subnetのトラフィックを適切にルーティングするためのルートテーブルを設定します。
- IPv6インターネット向けルート:
::/0(すべてのIPv6トラフィック) をEIGWに向けます。 - IPv4サービス向けルート (NAT64): ここがポイントです!AWSのIPv6 Only Subnetでは、自動的に有効になったNAT64機能を利用するために、
64:ff9b::/96宛のトラフィックをEIGWに向けます。 EIGWがこのプレフィックス宛のトラフィックを内部のNAT64サービスに転送してくれます。
# サブネットに紐づけるルートテーブルを作成
aws ec2 create-route-table \
--vpc-id vpc-xxxxxxxxxxxxxxxxx \
--tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=MyIPv6OnlyRouteTable}]'
# 作成したルートテーブルにIPv6インターネット向けのルートを追加
aws ec2 create-route \
--route-table-id rtb-xxxxxxxxxxxxxxxxx \
--destination-ipv6-cidr-block ::/0 \
--egress-only-internet-gateway-id eigw-xxxxxxxxxxxxxxxxx
# 重要: IPv4サービス (NAT64) 向けのルートを追加
# 64:ff9b::/96 宛のトラフィックはEIGWを介して内部のNAT64サービスにルーティングされる
aws ec2 create-route \
--route-table-id rtb-xxxxxxxxxxxxxxxxx \
--destination-ipv6-cidr-block 64:ff9b::/96 \
--egress-only-internet-gateway-id eigw-xxxxxxxxxxxxxxxxx
# サブネットとルートテーブルを関連付け
aws ec2 associate-route-table \
--subnet-id subnet-xxxxxxxxxxxxxxxxx \
--route-table-id rtb-xxxxxxxxxxxxxxxxx
これで、あなたのIPv6 Only Subnet内のインスタンスは、IPv6インターネットにはもちろん、IPv4専用の外部サービスにもアクセスできるようになります!
⑤ インスタンスの起動と確認
あとは、このIPv6 Only SubnetにEC2インスタンスを起動するだけです。
インスタンスには自動的にIPv6アドレスが割り当てられ、IPv4アドレスは割り当てられません。
# IPv6 Only SubnetにEC2インスタンスを起動 (AMI IDなどは環境に合わせてください)
aws ec2 run-instances \
--image-id ami-xxxxxxxxxxxxxxxxx \
--instance-type t3.micro \
--subnet-id subnet-xxxxxxxxxxxxxxxxx \
--count 1 \
--ipv6-address-count 1 \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=MyIPv6OnlyInstance}]'
インスタンスにSSHで接続し、curl -6 ipv6.google.com でIPv6インターネットへの接続を、curl -6 ipv4.google.com (もしIPv4オンリーのサービスがあればそれ) でNAT64経由のIPv4サービスへの接続を確認してみてください。きっと感動するはずです!
—
💡 まとめ:IPv6の未来を恐れず、楽しもう!
今回は、IPv6オンリーな環境でも、まだ残るIPv4の世界とシームレスにつながるための強力な技術「NAT64」と「DNS64」について、郵便配達の例えを交えながら、その仕組みとAWSでの具体的な設定イメージをご紹介しました。
- IPv6 Only Subnet: IPv4アドレスを持たないインスタンスのためのサブネット。
- DNS64: IPv4アドレスしか持たないサービスのドメイン名を、見せかけのIPv6アドレスに変換して返してくれる賢い電話帳。
- NAT64: その見せかけのIPv6アドレス宛のパケットを、実際のIPv4アドレス宛のIPv4パケットに変換してくれる通訳兼郵便局員。
- AWSでは: IPv6 Only Subnetを作成するだけで、DNS64とNAT64の機能が自動的に有効になり、Egress Only Internet Gatewayを介して利用できる。
IPv6は、これからのインターネットを支える非常に重要な技術です。IPv4アドレス枯渇の課題を解決し、より広大なアドレス空間と効率的な通信を提供してくれます。
今回ご紹介したNAT64とDNS64は、そんなIPv6への移行期間において、既存のIPv4サービスとの互換性を保ちながら、スムーズな移行を可能にするための素晴らしいソリューションです。
最初は少し難しく感じるかもしれませんが、パケットがどんな旅をしているのか、どんな役割分担があるのか、想像しながら読み進めていただけたなら嬉しいです。この知識が、皆さんのこれからのインフラ構築やネットワーク設計の一助となれば幸いです。
これからも、一緒にクラウドとネットワークの奥深い世界を探求していきましょう!
それでは、また次回の記事でお会いしましょう!
コメント