IPv6オンリー環境の「最後の壁」を突破せよ：NAT64/DNS64によるパケット変換の深淵
クラウドネイティブなインフラを構築していると、一度は夢見るのが「IPv6オンリーのクリーンなネットワーク」です。プライベートサブネットをすべてIPv6で統一できれば、あの忌々しいRFC 1918のIP枯渇や、NATゲートウェイのポート不足問題から解放される……はずでした。
しかし、現実は厳しい。どれだけモダンなマイクロサービスを構築しても、外部のレガシーなAPIや、IPv4しか喋れないパートナー企業のWebサーバーに接続しなければならない瞬間は必ず訪れます。
ここで我々を救うのが、NAT64とDNS64のコンビネーションです。今回は、この技術がいかにしてパケットを魔法のように変換し、IPv6の世界からIPv4のインターネットを覗き込んでいるのか、その裏側の泥臭い挙動を紐解いていきましょう。
—
1. なぜ「DNS64」と「NAT64」のペアが必要なのか
まず大前提として、IPv6のクライアントはIPv4のパケットを生成する術を持ちません。ここで直面する最大の壁は「名前解決」です。
- DNS64の役割: IPv6クライアントがIPv4のみのドメインを問い合わせた際、そのAレコード（IPv4アドレス）を、NAT64が扱うプレフィックス（通常は
64:ff9b::/96）でラップした「合成IPv6アドレス」としてクライアントに返します。 - NAT64の役割: クライアントがその合成アドレス宛に送信したパケットを受け取り、IPv6ヘッダーを剥がしてIPv4ヘッダーに付け替える（変換する）役割を担います。
この二つが揃って初めて、クライアントは「自分はIPv6で通信しているつもりなのに、実はIPv4の世界に接続できている」というマジックを体験できるわけです。
—
2. パケット変換のシーケンス：何が起きているのか
通信フローを追うと、パケットの「変身」がよくわかります。
1. DNS Query: クライアントが api.legacy-service.com をDNS64サーバーに問い合わせる。
2. 合成: DNS64が 93.184.216.34 (IPv4) を見つけ、64:ff9b::5db8:d822 というIPv6アドレスに変換して返送。
3. パケット生成: クライアントはこのアドレス宛にTCP SYNを送信。
4. NAT64変換: NAT64ゲートウェイがパケットを受け取り、以下の処理を行います。
- IPv6ヘッダーの除去。
- 送信元IP（クライアントのIPv6）をNAT64自身の持つIPv4アドレスに変換。
- 宛先IPを
64:ff9b::/96を取り除いた93.184.216.34に復元。
5. 往復: 戻りパケットも同様に、NAT64がIPv4からIPv6へ再変換し、クライアントへ届けます。
—
3. 実践：クライアント側でこの通信をデバッグする
実務において、この変換が正しく行われているかを確認するのは重要です。トラブルシューティングの現場では、まず curl での挙動を追うのが鉄則です。
# -6 オプションで明示的にIPv6経由の通信を強制する
# DNS64経由で合成されたアドレスが正しく解決されているか確認
curl -v -6 https://api.legacy-service.com
# もし通信が失敗する場合、DNS64が機能していないか、
# NAT64のルーティングプレフィックスが間違っている可能性が高いまた、Pythonで同様のクライアントを書く場合、特別な設定は不要です。OSのネットワークスタックがDNS64を認識していれば、標準的なライブラリが自動的に合成アドレスを利用します。
import requests
# URLはIPv4のみをサポートしているが、DNS64環境下では
# 透過的にIPv6パケットとしてネットワークを駆け巡る
url = "https://api.legacy-service.com/v1/data"
try:
response = requests.get(url, timeout=5)
print(f"Status Code: {response.status_code}")
except Exception as e:
# タイムアウトや接続拒否の場合、NAT64側のセッションテーブル枯渇や
# プレフィックスの不一致を疑う
print(f"Network Error: {e}")—
4. インフラ屋がハマる落とし穴：MTUとフラグメント
NAT64環境で最も厄介なのが「MTU問題」です。IPv6の最小MTUは 1280 バイトですが、IPv4のインターネット標準は 1500 です。ヘッダー変換の過程でパケットサイズが微妙に変化し、稀にドロップが発生します。
クラウド環境（AWSのNAT Gatewayなど）で設定を組む際は、以下の iptables や nftables 的な考え方を意識してください。
- MSSクランプ: もし自前でNAT64を構築するなら、TCPの
MSSを小さめに調整してあげるのが、地味ですが最も安定する解決策です。 - プレフィックスの固定: Well-Knownプレフィックス
64:ff9b::/96以外を使う場合、クライアント側のルーティングテーブル設定を忘れると、パケットがゲートウェイに到達せず「沈黙の障害」になります。
—
最後に：SREとしての心構え
NAT64/DNS64は、レガシーなIPv4資産と未来のIPv6ネットワークを繋ぐ「翻訳機」です。しかし、翻訳機は往々にして故障し、あるいは誤訳をします。
トラブルシューティングの際は、必ず「名前解決（DNS64）で正しいIPが返っているか」と「パケット変換（NAT64）で宛先が正しく変換されているか」の2軸で切り分けてください。この視点を持つだけで、障害解決のスピードは劇的に向上します。
IPv6オンリーの理想郷へ向かう道は険しいですが、パケットの流れる先を理解していれば、恐れることはありません。それでは、また次回の深掘りでお会いしましょう。
コメント