IPv6 Onlyの荒野を駆ける：NAT64/DNS64が隠蔽するパケット変換の深淵
クラウドネイティブな環境において「IPv4枯渇」はもはや遠い未来の話ではない。EKSやGKEのポッドネットワークを完全なIPv6 Only（Dual-stackすら捨てた純粋なIPv6環境）へと移行させるアーキテクトにとって、避けて通れないのが「IPv4のみを話す外の世界」との対話だ。
そこで登場するのが NAT64 と DNS64 という名の通訳者である。彼らは単にパケットを右から左へ流しているわけではない。今回は、パケットレベルの内部挙動から、パフォーマンスを極限まで引き出すためのチューニングまで、ネットワークの深層を解剖していこう。
—
1. DNS64が仕掛ける「アドレス合成」のトリック
通信は常に名前解決から始まる。IPv6 Onlyのクライアントが api.legacy-service.com（IPv4のみ）へアクセスしようとした際、DNS64サーバーはまず A レコードを問い合わせる。ここで返ってきた 192.0.2.1 というIPv4アドレスを、DNS64はあらかじめ設定された Well-Known Prefix（例: 64:ff9b::/96）と合成し、64:ff9b::c000:201 という擬似IPv6アドレスとしてクライアントに返す。
クライアントは「相手はIPv6だ」と信じ込み、このアドレスに向けてTCP SYNを打ち込む。ここからがNAT64の真骨頂だ。
—
2. NAT64：ヘッダー変換という名の錬金術
NAT64ゲートウェイに届いたパケットは、カーネルの netfilter 領域、具体的には TPROXY や DNAT のような処理を通過する。ここで実行される変換は、単なるアドレス置換ではない。
パケット変換の内部挙動
1. IPv6ヘッダーの剥離: 送信元 2001:db8::10、宛先 64:ff9b::c000:201 のパケットからIPv6ヘッダーを解体する。
2. IPv4ヘッダーの再構築:
- 送信元をNAT64自身のIPv4アドレス（パブリック側）に書き換える。
- 宛先を
192.0.2.1に展開する。 - チェックサムの再計算が不可欠となる。特にTCP/UDPヘッダー内の擬似ヘッダーチェックサムは、IPv6とIPv4で計算方法が異なるため、この変換コストがジッターの要因となり得る。
パフォーマンス最適化のヒント
この変換処理によるオーバーヘッドを最小化するため、Linuxカーネルレベルでは nf_conntrack_ipv4 と nf_conntrack_ipv6 のハッシュテーブルサイズを拡張し、キャッシュミスを防ぐ必要がある。
# sysctlでの最適化例
# NAT変換テーブルのハッシュサイズを拡張
sysctl -w net.netfilter.nf_conntrack_buckets=262144
# タイムアウトを短縮し、古いコネクションのゴミを掃き出す
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600—
3. トランスポート層の罠：MSSとMTUの断片化
IPv6は最小MTUが 1280 バイトである一方、IPv4は 1500 バイトが一般的だ。NAT64を通る際、IPv6ヘッダーの分だけペイロードサイズが圧迫される。ここでMTUの不一致によるパケット断片化が発生すると、パフォーマンスは劇的に悪化する。
これを回避するためには、MSS Clamping をゲートウェイ側で強制するのが鉄則だ。
# iptablesによるMSSクランプの例
# IPv4側でMSSを調整し、断片化を未然に防ぐ
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360—
4. TLSハンドシェイクとセキュリティの盲点
NAT64環境下では、中間ボックス（NAT64ゲートウェイ）が存在するため、エンド・ツー・エンドの可視性が損なわれる。だが、TLS 1.3以降であれば、SNI（Server Name Indication）は暗号化されないままであることが多く、NAT64はこれを透過できる。
ただし、TCPバッファチューニングは疎かにしてはならない。NAT64ゲートウェイを通過する通信は、往復の変換オーバーヘッドがあるため、TCPウィンドウサイズを大きめに設定し、帯域遅延積（BDP）を稼ぐことが重要だ。
# LinuxカーネルのTCPウィンドウサイズを最適化する設定（sysctl.conf）
# ネットワークの遅延が大きい環境では必須の調整
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216—
5. 終わりに：技術的負債としてのNAT64
NAT64は、レガシーなIPv4リソースを延命させるための「強力な劇薬」だ。しかし、この変換過程にはステートフルな追跡が必要であり、ゲートウェイが単一障害点（SPOF）となるリスクを常に内包している。
真に堅牢なクラウドインフラを目指すのであれば、NAT64を「一時的な橋渡し」と認識し、可能な限りアプリケーション側でのIPv6ネイティブ対応を進めるべきだ。しかし、どうしても避けられないレガシー接続が必要な時、この記事で触れたチューニングが、あなたのパケットをよりスムーズに、よりセキュアに目的地まで届ける助けとなれば幸いだ。
ネットワークエンジニアの仕事は、いつだって「見えない場所でいかに効率を最大化するか」に集約されるのだから。
コメント