秒でサイトのIPv6対応ができる！サーバサイド Open NAT64を公開した話

というわけで、NAT64を公開しました

この企画の趣旨は、Open な誰でも使えるNAT64をインターネット上に公開することです。
これは、IPv4 Onlyのサーバを運用している人を対象として、IPv6対応する手段を提供します。
対応するDNS64も合わせて公開しました。

NAT64 prefix:
2402:c800:fe01:64::/96

Pool IPv4:
163.138.237.48/28

DNS64:
2402:c800:fe01:a10::53

これが世界初/日本初か、というと全然そんなわけはなく、NAT64/DNS64の公開実験自体は何年も前からすでに、いくつもあります。

ただ、それらは主にアクセス回線のIPv6対応の文脈で使われるものでした。今回はDNS64を必須とせず、「NAT64 + 対応するAAAAレコードの登録」でできる簡易なサーバサイドのIPv6対応を主な実験対象としています。

また、2019年12月現在、公開で行っている実験は、日本国内では他にはないようです¹。国内にあるので、遅延が少なくていいぞ。

IPv4はお金がかかる

先月、欧州地域のIPv4アドレス在庫が枯渇した件で、にわかにIPv4アドレスの枯渇問題に注目が集まりました。
限りある資源であるIPv4アドレスは手に入りにくくなっているのは事実で、JPNICへのIPv4アドレスの新規割り振り申請も、最大割り振りサイズが/22(1,024アドレス)から/23(512アドレス)に変更されています。
IPv4アドレスは中古取引市場が成立しており、IPv4アドレスオークションサイトもあります。
現在は1アドレスあたり20ドルくらいですが、全世界で価格は上昇傾向にあります。

IPv6は速い!?

IPv4アドレスの入手コストも潜在的な問題ですが、一部のコンテンツ事業者では別の理由でIPv6化を開始しています。
特に、AbemaTVが動画配信でのIPv6対応を2019年1月より開始したのは記憶に新しいです。
ニュースリリースによると、

IPv6に対応することにより、多くの利用者の環境において、より快適な視聴が可能になります。現時点で、既に「AbemaTV」を利用しているユーザーの約3分の1が、IPv6でインターネット接続をしております。

とのことですがIPv6に対応することでより快適な視聴が可能とはどういうことでしょうか？

先に宣言しておくと、プロトコルとしてIPv6がIPv4より速いということはありません²。

日本国内においては、フレッツ 光ネクストでのインターネットの提供形態に理由があります。
PPPoE方式とIPoE方式がありますが、(非常に乱暴な言い方ですが)回線の混雑具合が以下のように違います。

今は2のPPPoE IPv4のユーザーが多いですが、通信品質(特に夜間の品質差が顕著)を理由として、3、4のIPv6 IPoE (+IPv4 over IPv6)に契約変更していく流れがあります。
例えば、私スプラトゥーンが好きなのですが、ゲーム攻略サイトに「IPv6対応の光回線で通信ラグ解消！」などと書かれている場合があります。
IPv6 IPoEへの契約変更の際には、ぜひOCN 光 v6アルファをよろしくお願いします。

この状況を背景として、IPv6ユーザが増えていますので、サーバのIPv6対応をした場合、日本国内からのアクセスの約20%がIPv6からになる、と言われています。
では、IPv4 OnlyのサーバのIPv6対応を実施してみましょう。

Open NAT64を利用したIPv6対応レシピ (所要時間: 1分)

STEP1. IPv6 NAT64 prefix 2402:c800:fe01:64::/96の末尾に、対象サイトのAレコード(IPv4)を、付け足して、NAT64用IPv6アドレスを作ります³。

> dig A ocn.ne.jp +short
153.254.170.142

# IPv6 NAT64 prefix(96bit) + IPv4アドレス(32bit)
2402:c800:fe01:64:: + 153.254.170.142

# -> NAT64用IPv6アドレス(128bit)
2402:c800:fe01:64::153.254.170.142
(16進数表記に直すと、2402:c800:fe01:64::99fe:aa8e)

STEP2. このNAT64用IPv6アドレスを Route53などに AAAAで登録してください。

以上で、IPv6ユーザからのアクセスが可能になります。

サーバにIPv6アドレスをつけるのではなく、DNSのAAAAリソースレコードにインターネットから到達可能なIPv6アドレスをつけることによって簡易なIPv6対応を実現しています。

動作説明

このNAT64用IPv6アドレスに対しては、IPv6空間からping疎通が確認できます。
以下は、Google の public DNS 8.8.8.8 に対して、IPv6空間からpingを打った例です。

>ping6 2402:c800:fe01:64::8.8.8.8
16 bytes from 2402:c800:fe01:64::808:808, icmp_seq=0 hlim=50 time=3.269 ms
16 bytes from 2402:c800:fe01:64::808:808, icmp_seq=1 hlim=50 time=3.052 ms
16 bytes from 2402:c800:fe01:64::808:808, icmp_seq=2 hlim=50 time=3.100 ms

--- 2402:c800:fe01:64::8.8.8.8 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 3.052/3.140/3.269/0.093 ms

末尾の808:808が、IPv6アドレスに埋め込まれたIPv4アドレス(32bit/16進数表記)です。
ping6など多くのプログラムはIPv6の末尾にIPv4アドレスを(.)ドット表記で追加するだけで16進数に直してくれます。

このようにNAT64で使われるIPv6アドレスには、末尾の32bitにIPv4アドレスがそのまま埋め込まれていますので、NAT64装置で、そのIPv4アドレスを取り出して、IPv6空間からIPv4空間に通信をしています。
この方法でIPv6対応した場合の通信の様子が以下です(twitter.comを例としています)。
この方法によるIPv6対応では、当然証明書の対応は不要です。

サーバ側からすると、IPv6ユーザからの通信は、NATプールアドレスからのIPv4通信のように見えることになります。

DNS64について

NAT64用IPv6アドレスの導出を自動的にできないでしょうか？
2402:c800:fe01:a10::53をDNSサーバとして指定することによっても、対象ドメインのNAT64用IPv6アドレスを入手することができます。
このDNSサーバは、Aレコードしかない場合に、NAT64用IPv6アドレスを返します。すでにAAAAレコードがある場合はそちらを優先して返します。

$ dig <ドメイン> @2402:c800:fe01:a10::53 AAAA

# Aレコードしかないサイトの場合
$ dig twitter.com @2402:c800:fe01:a10::53 AAAA +short
2402:c800:fe01:64::68f4:2a01
2402:c800:fe01:64::68f4:2ac1

# すでにAAAAレコードのあるサイトの場合
$ dig ocn.ne.jp @2402:c800:fe01:a10::53 AAAA +short
2001:218:200d:253:153:254:170:142

iOS Appにおいて「IPv6 DNS64/NAT64 ネットワークをサポートする」ことが必須になっていますが、このNAT64とDNS64を使って、その検証用ネットワークを構成することも可能です。

IPv6対応シナリオ

本機能を用いることで、AAAAレコードを付与するだけで、IPv6対応を経験をすることができます。
この技術はどんなユーザを想定しているでしょうか？それを知るために他の方法と比較してみましょう。

GCPなどのクラウドでIPv6対応する場合

GCPはIPv6対応を謳っておりますが、インスタンスにIPv6アドレスをつけることはできません。
ロードバランサを利用して、IPv6アクセスを実現しています。

IPv6からIPv4に変換する機能を持ったロードバランサを、SLB64(サーバロードバランサ64)と呼びます。
NAT64を利用する方法は、この構成に非常に似ています。SLB64をNAT64に入れ替えたもの、と言えるでしょう。

CDN(コンテンツデリバリネットワーク)でIPv6対応する場合

CDNを使ってIPv6対応をすることが可能です。AbemaTVが利用しているのもこの方法です。
オリジンサーバをIPv6化する必要がありません。

外部のサービスを利用している点で、Open NAT64の対応イメージに似ています。

Open NAT64でIPv6対応する場合(New)

Open NAT64を利用して、IPv6対応をした場合のイメージです。

CDNの場合と異なり、HTTPやTCPを終端しません。単純にアドレス変換をする装置なので、CDNよりも安価に構成できる可能性があります。

実験参加者募集中

この実験は、だれでも利用開始できます。
アンケートフォームを作りましたので、こちらで使ってみたフィードバックをください。
また、実験に協力したいという人は連絡ください。

フィードバックはこちらへ

実験に協力いただいた方には、該当のNAT64ログなどのレポートを提供する予定です。
また、NAT64と同じプラットフォームでSLB64として動かすことも考えており、利用してみたいという方はご連絡ください。

サーバにIPv6をつける、真のIPv6対応にむけて

IPv6対応は、フロントの対応だけの問題ではありません。
IPv4アドレスの枯渇を理由として、DC内のIPv6化を検討している事業者もいると思います。
DC内のサーバのIPv6 Only化、と言っても、IPv4サーバと通信する必要がどうしてもでてきます。
インターネット上のOS/パッケージの取得や、IPv6対応していないミドルウェアなどがそうです。特に HadoopとかHadoopとかHadoopとか。

そのために将来的には、IPv6 Onlyのサーバインフラに対しては、自前でNAT64/DNS64を準備しなければいけないのではないかと考えています。

今回、DNS64も合わせて提供しているのは、IPv6 Onlyサーバインフラに対してもこの仕組みを使ってほしいと思っているからです。そのようなユースケースでも使ってフィードバックいただけると幸いです⁴。

FAQ

帯域はどのくらいですか？
・上下計で1Gbps。トラフィックが増えた場合は10Gへの増速を検討します

設置場所は？
・大手町です

期間は？
・2020年春までを予定2020年8月末まで

問い合わせ先
・アンケートフォーム

苦労した点

実験にあたり、Path MTU問題にはまったりしました。そちらの顛末は、同時公開のこちらの記事をどうぞ。

Path MTU Blackhole で阿部寛様のご尊顔が表示されない！

機材提供スポンサー

本実験は、A10ネットワークス株式会社様から機材をお借りして提供しています。多謝！

免責事項

あくまで実験構成ですので、商用での利用はお控えください。
IPv6で通信できない場合はIPv4にフォールバックすると思いますが、本実験利用時に金銭的な被害が発生したとしても責任は負いません。トラフィックの多いサイトの対応をする場合はフォームにてご連絡いただければと思います。

それでは、Happy IPv6 life!