【入門編】 IPv6環境におけるNAT64およびDNS64の役割とパケット変換仕様 – クラウド＆コンテナネットワーク実践ガイド

みなさん、こんにちは！クラウドやコンテナのネットワークと日々格闘しているSRE（サイト信頼性エンジニア）の「なかの人」です。

近年、AWSやGCPといったメガクラウドだけでなく、Kubernetesなどで構築するプライベートなコンテナ環境でも「IPv6シングルスタック（IPv6だけを使う環境）」の導入が急速に進んでいます。

「IPアドレスが枯渇するから、これからはIPv6だ！」

そんな言葉を耳にして、意気揚々と「完全なIPv6プライベートサブネット」を作ってみたものの、大きな壁にぶつかることがあります。そう、「インターネット上の世の中のサイトやAPIは、まだまだIPv4にしか対応していないところがたくさんある」という現実です。

「IPv6しか喋れない私のサーバーから、IPv4しか喋れないAPIにどうやってアクセスすればいいの？」

この絶望的なすれ違いを、まるでお互いが同じ言語で話しているかのようにスムーズに解決してくれる魔法のコンビがいます。それが、今回ご紹介する「DNS64」と「NAT64」です。

難しそうなアルファベットや数字が並んでいますが、心配いりません！今回は、ネットワークの難しい仕組みを「郵便配達」や「通訳さん」といった身近な例えに置き換えて、一歩ずつ丁寧に紐解いていきましょう。

—

なぜIPv6からIPv4への通信は難しいのか？

まずは、なぜこの2つが直接おしゃべりできないのかを整理しておきましょう。

IPv4とIPv6は、名前こそ似ていますが、「全く異なる言語」です。
例えるなら、IPv4が「日本語」、IPv6が「英語」のようなものです。

  • IPv4（日本語）しか喋れないサーバーに、
  • IPv6（英語）しか喋れないあなたのサーバーが、

直接「こんにちは！」と話しかけても、相手は「？？？」となってしまい、手紙（パケット）を受け取ることすらできません。

「それなら、IPv6のサーバーにIPv4のアドレスも両方持たせればいいじゃない（デュアルスタック）」と思うかもしれません。しかし、それだと貴重なIPv4アドレスを消費してしまいますし、管理も2倍になってしまいます。

そこで、「あなたのサーバーはIPv6（英語）のままでいいよ。途中で私たちが完璧に通訳して、IPv4（日本語）の相手に届けてあげるからね！」と名乗りを上げたのが、今回の主役である「DNS64」と「NAT64」のペアなのです。

—

郵便配達で理解する「DNS64」と「NAT64」の役割

この2つの技術は、常にタッグを組んで仕事をします。
彼らの連携プレーを、海外へ手紙を送る「郵便配達」に例えて見てみましょう。

あなたのサーバー（IPv6オンリー）を「Aさん」、届けたい相手のIPv4サーバーを「Bさん」とします。

[ Aさん (IPv6専用) ] ──(手紙を書きたい)──> [ Bさん (IPv4専用) ]

1. DNS64の役割：住所録の「翻訳屋さん」

AさんはBさんに手紙を書きたいのですが、Bさんの「IPv6の住所（AAAAレコード）」が分かりません。そこで、住所録の管理者である「DNS64さん」に問い合わせます。

  • Aさん：「BさんのIPv6の住所を教えてください！」
  • DNS64さん：（うーん、BさんはIPv4の住所しか持っていないな……。よし、IPv4の住所の頭に『翻訳センター行き』という目印をつけて、IPv6の住所っぽく仕立てて教えよう！）
  • DNS64さん：「はい、Bさんの住所（擬似的なIPv6アドレス）はこれですよ！」

このように、IPv4の住所をIPv6の形に「おめかし」して教えてくれるのがDNS64の役割です。

2. NAT64の役割：国境の「通訳・書き換え職人」

Aさんは、教えてもらった「おめかしされた住所」に向けて手紙（パケット）を書き、ポストに投函します。

この手紙は、途中の国境にある「NAT64ゲートウェイ（通訳・書き換え職人）」に届きます。

  • NAT64さん：「お、この手紙の宛先には『翻訳センター行き』の目印がついているな。ということは、IPv4の世界へ届ける手紙だな」
  • NAT64さんの仕事：

1. 手紙の封筒（IPv6ヘッダー）を破り捨てる。
2. 中身を取り出して、新しいIPv4用の封筒に入れ直す。
3. 差出人の名前を、NAT64自身の「IPv4アドレス」に書き換える。
4. IPv4のインターネットへ発送する！

こうして、無事にIPv4しか喋れないBさんの元へ手紙が届きます。
Bさんから返事が戻ってきたときも、NAT64さんが逆の手順でIPv6の封筒に入れ直してAさんに届けてくれます。

ね？とてもスマートで、温かみのある連携プレイだと思いませんか？

—

パケットが旅するステップバイステップ

それでは、もう少しだけエンジニアらしく、実際のネットワーク上でパケットがどう動いているのか、具体的なIPアドレスの動きを追いかけてみましょう。

ここでも難しい計算は不要です。数字の流れを追うだけで、仕組みがスッキリ理解できますよ。

[IPv6専用インスタンス]
      │ (1) "example.com のIPv6アドレスは？"
      ▼
[ DNS64サーバー ] (2) AAAAレコードがないので、Aレコード(IPv4)を取得して合成！
      │ (3) "64:ff9b::192.0.2.1 です！"
      ▼
[IPv6専用インスタンス]
      │ (4) 送信先: 64:ff9b::192.0.2.1 へパケット送信
      ▼
[ NAT64ゲートウェイ ] (5) IPv6ヘッダーを剥ぎ、送信元を自身のIPv4に変換
      │ (6) 送信元: NAT64のIPv4 ──> 送信先: 192.0.2.1
      ▼
[ IPv4インターネット (example.com) ]

ステップ1：DNS64による「アドレスの合成（Synthesize）」

あなたのサーバーが example.com（IPv4にしか対応していないサイト）にアクセスしようとします。

1. あなたのサーバーは、DNS64サーバーに「example.com の AAAAレコード（IPv6アドレス）を頂戴！」とリクエストします。
2. DNS64サーバーは、世界中のDNSに問い合わせますが、example.com はIPv4のアドレス（例：192.0.2.1）しか持っていません。
3. そこでDNS64は、特別なプレフィックス（AWSなどでは、標準的な 64:ff9b::/96 という値がよく使われます）の末尾に、IPv4アドレスをガッチャンコと結合します。
4. 結果として、64:ff9b::192.0.2.1 という「IPv6の仮の姿」を作り出し、あなたのサーバーに返します。

ステップ2：NAT64による「パケットの変換」

あなたのサーバーは、返ってきた 64:ff9b::192.0.2.1 宛てにパケットを送信します。

1. このパケットは、ルーターの設定（ルートテーブル）によって、NAT64ゲートウェイに吸い込まれます。
2. NAT64ゲートウェイはパケットを見て、「あ、宛先が 64:ff9b:: で始まっているな。これは私がIPv4に変換するやつだ」と判断します。
3. NAT64は、IPv6ヘッダーを取り外し、宛先を本来のIPv4アドレスである 192.0.2.1 に書き換えます。
4. 同時に、送信元（送り主）を、自分自身（NAT64ゲートウェイ）のIPv4アドレスに書き換えて、IPv4インターネットへ送り出します。

これで、完全なIPv6環境から、IPv4の海へとパケットが漕ぎ出すことができました！

—

クラウド（AWS）での具体的な設定例を見てみよう！

「理屈は分かったけれど、これを自分で構築するのは大変そう……」

そう思った方も多いのではないでしょうか？でも、安心してください。
現在のパブリッククラウド（例えばAWS）では、このDNS64とNAT64の機能がマネージドサービス（NAT Gateway）に最初から組み込まれており、簡単な設定だけで利用できるようになっています。

ここでは、AWSを例に、どのように設定するのかをコードと合わせて見てみましょう。

1. サブネットでの「DNS64」の有効化

AWSのVPC環境において、特定のIPv6サブネットでDNS64を有効にするには、サブネットの属性を変更します。

以下は、AWS CLIを使ってDNS64を有効にするコマンドの例です。

# 対象のIPv6プライベートサブネットのIDを指定して、DNS64を有効化します
aws ec2 modify-subnet-attribute \
    --subnet-id "subnet-0123456789abcdef0" \
    --enable-dns64

*※Terraformを使用している場合は、以下のようにシンプルに記述できます。*

# Terraformでのサブネット設定例
resource "aws_subnet" "ipv6_private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24" # 必要に応じてIPv4 CIDRも定義
  ipv6_cidr_block   = "2001:db8:1234:1a00::/64"
  
  # 【ここが重要！】DNS64を有効にします
  enable_dns64      = true

  tags = {
    Name = "IPv6-Only-Private-Subnet"
  }
}

2. ルートテーブルで「NAT64」への道を切り開く

DNS64が返してくれた「仮の住所（64:ff9b::/96）」宛ての通信を、NATゲートウェイに運ぶための道路（ルート）を作ってあげましょう。

# ルートテーブルにNAT64（NAT Gateway）への経路を追加する例
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id

  # 通常のIPv6インターネット宛て（対応しているサイト用）
  route {
    ipv6_cidr_block = "::/0"
    egress_only_internet_gateway_id = aws_egress_only_internet_gateway.eigw.id
  }

  # 【ここが重要！】IPv4宛ての通信（DNS64で変換された宛先）をNATゲートウェイへ流す
  route {
    ipv6_cidr_block = "64:ff9b::/96"
    nat_gateway_id  = aws_nat_gateway.nat.id
  }
}

このわずか数行の設定だけで、あなたのIPv6プライベートサブネットは、世界中のIPv4ウェブサイトと自由に通信できるようになります！

—

現場のSREが語る！「動かない！」ときの泥臭いチェックポイント

インフラの構築にトラブルはつきものです。設定したはずなのに「通信が通らない！」というときに、現場のプロが真っ先にチェックするポイントを伝授します。

チェック1：DNSサーバーの参照先は正しいか？

DNS64は、DNSサーバー（リゾルバー）がその役割を担っています。あなたのサーバーの /etc/resolv.conf やネットワーク設定で、クラウドが提供するDNSサーバー（AWSなら 169.254.169.253 や、VPC CIDR+2のIP）を正しく参照しているか確認してください。
外部のパブリックDNS（8.8.8.8 など）を直接参照していると、DNS64の翻訳プロセスがスキップされてしまいます！

チェック2：ルートテーブルの「宛先」は 64:ff9b::/96 になっているか？

よくある間違いが、ルートテーブルの宛先を ::/0（すべてのIPv6）だけにして、NATゲートウェイに向けてしまうことです。
通常のIPv6宛ては「Egress-Only Internet Gateway（送信専用インターネットゲートウェイ）」へ逃がし、64:ff9b::/96 だけを「NAT Gateway」へ向けるのが正しいセオリーです。

チェック3：セキュリティグループがIPv6を通すようになっているか？

ファイアウォール（セキュリティグループやネットワークACL）の設定で、アウトバウンド（送信）のルールに ::/0 への通信が許可されているか、今一度見直してみましょう。

—

まとめ：一歩ずつ、モダンなインフラへ！

今回は、IPv6環境のマイルストーンとなる「DNS64」と「NAT64」について、その役割と動きを優しく紐解いてきました。

  • DNS64：IPv4の住所を、IPv6っぽく「翻訳（合成）」して教えてくれる。
  • NAT64：送られてきたパケットの封筒を、IPv4用に「書き換えて」届けてくれる。

一見すると複雑なパケットの世界も、こうして1つずつの役割を分解して見ていけば、決して恐れるものではありません。

IPv6への完全移行は、これからのモダンなインフラを支える上で避けて通れない、エキサイティングな挑戦です。この記事が、みなさんのネットワーク構築の第一歩を照らす灯火になれば幸いです。

これからも、一歩ずつ一緒に理解を深めていきましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました