コンテンツプロバイダこそがIPv6に対応しておいた方がいい１つの理由

要約：NATによるIPv4アドレス枯渇対策には限界があり、Webサービスのパフォーマンスの低下を引き起こす可能性があるので、自衛のためにもIPv6に対応しておいたほうが良い

コンテンツプロバイダからするとIPv6に対応してもコストがかかるだけで売上は上がらず、対応する意味のないもので、私もそのように感じていたのですが、色々なカンファレンスネットワークでCGNやIPv4-IPv6移行・共存技術の検証を行っていた結果、ISP側でできる努力の限界が見えてきて、コンテンツプロバイダがさっさとIPv6に対応したほうがインターネット的にもコンテンツプロバイダ自身も幸せになるんじゃないかなと、いちネットワークエンジニア＆ソフトウェアエンジニアとして感じたのでこの記事を書きました。

IPv4アドレスの枯渇

IPv4アドレスは枯渇しました。2015年12月時点で各RIR(地域インターネットレジストリ)の/8のアドレス保有数は次のとおりです(IPv4枯渇時計より)。

地域	RIR	残り/8数
アフリカ	AfriNIC	2.14
アジア・パシフィック	APNIC	0.64
北米・中米	ARIN	0
南米	LACNIC	0.4
欧州・中東	RIPE NCC	1.01

日本を管轄しているAPNICでも既に最後の/8に手を付けており、IPv4アドレスの通常割り振りは終了しています。現在では最大でも/22(1024アドレス)の割り振りしか行われません。

NATによるIPv4アドレス枯渇対策の仕組み

おもに一般家庭向けISPの視点で話を進めます。

NAT(正確にはNAPTですがこの記事ではNATとします)を行うことでIPv4アドレスを節約することができます。通常のISPのユーザだと宅内ではプライベートIPv4アドレスを利用しており、ルータで割り当てられた1つのグローバルIPv4アドレスにNATすることでインターネットへアクセスすることができます。

通常は通信ホストの識別を32-bitのIPv4アドレスだけで行うのですが、NATではこれに加えて16-bitのTCP/UDPのポート番号を使用することで、同じIPv4アドレスを持っていても通信ホストの識別を行うことを可能にしています。これにより通信の識別に使えるbit数はAddress 32bit + Port 16bit の 48bit になります。この考え方はA+Pと呼ばれます。

しかしながらアドレス枯渇により各家庭にそれぞれグローバルIPv4アドレスを割り当てることも難しくなってきました。そこで登場するのがCGN(NAT444), DS-Lite, MAP-EなどのIPv4枯渇対策技術です。

これらの技術の詳細は私の過去の講演資料をご覧頂くとして、共通する基本的なコンセプトは 「複数のご家庭をまとめて１つのIPv4アドレスにNATする」 ということです。つまり同じグローバルIPv4アドレスを複数の家庭で共有することになります(ここでは「家庭」を加入者=subscriberの意味で使用しています)。特にCGN(Career Grade NAT)では各家庭のルータでNATした後に、ISPでNATをする多段NATになります。

これらの技術は全てNATを利用しています。つまり 各家庭の識別子にポート番号を利用します。この時ISPは各家庭に何ポート割り当てるかを設計する必要があります。仮に256ポートとしましょう。すると１つのグローバルIPv4アドレスに対して65536/256 = 256の家庭を収容することができます。このようにすることでISPはアドレスの利用効率を256倍にすることができます。

これ以降の文脈ではNATは主にISPによって提供され複数の家庭を１つのIPv4グローバルアドレスに収容するNAT(狭義のCGN, DS-Lite, MAP-E, NAT64等の技術のNAT機能)を指すことにします。

NATの２つのパラーメータにまつわる問題

ポート割当数

さて、ここで問題になるのはISPは１家庭あたり何ポートを割り当てるべきかということです。総務省のレポートVol.1, Vol.2によると端末当たり平均50ポート、最大500ポートぐらいのポート消費があるため、設計値としては1000ポートを推奨と書かれています。この推奨値に従って１家庭あたり1024ポートを割り当てた場合、アドレスの利用効率は65536/1024 = 64倍になります。この値は大きいでしょうか？小さいでしょうか？

また、家庭という単位も問題になります。一人暮らしの家庭とビッグダディみたいな方の家庭では同じ１回線でも接続する端末の数が異なります。端末が多いご家庭では1024ポートの割当でも足りないかもしれません。

ポートが足りなくなるとどのようになるかというと、少し古い資料ですがNTT Comの宮川さんの発表資料にGoogle Mapsが穴あきになってしまう例が示されています。

ポート割当数を多くすれば通信不能になるセッションを減らすことはできますし、ISPとしても通信の劣化に繋がるようなことはしたくありませんから、なるべくポート数を多く割り当てたいです。しかし、もともとアドレスが足りなくてこのようなことをやっているので、あまり大きな値を設定することはできませんし、アドレスが足りなくなってくるとやむを得ずポート割当数を減らす事になるかもしれません。そうなった時には 空いているポートがなくて通信ができないセッションが発生するかもしれません。

まとめると、 ポート割当数を多くすればアドレスの利用効率が落ちてアドレス枯渇が早くなり、少なくすれば通信できないセッションの発生確率が上がるというトレードオフが存在します。

タイムアウト値

Skypeや対戦ゲームなどのP2P通信を可能にするためには通信が終わった後も一定時間NATのセッションテーブルを持ち続けなければなりません。これをどれぐらいの時間保持するのかがタイムアウト値です。

タイムアウト値を大きくすればポートの利用効率が悪くなり、早くポート割当数の上限に達してしまい、通信できないセッションが発生する可能性が高くなります。短くすればポートを効率よく使うことができますが、P2P通信に失敗する可能性がありますし、その他にも次のような弊害があります。

Keepaliveをしているアプリケーションが利用できなくなる：制御用のセッションを張りっぱなしにして一定の間隔でKeepaliveを送るようなアプリがあります。例えばGoogle Hangoutは15分間隔でKeepaliveを送ります。このため、TCPのタイムアウトが15分以下になっているとこのアプリケーションは利用できないということになります。これを回避するためには十分長いタイムアウト値を設定する必要があります。他にもAndroidやiPhoneなどモバイル端末のKeepaliveもあります。一部のNAT機器にはポート番号ごとにタイムアウト値を設定できるものもありますが、全てのISPが世の中に存在する全てのアプリケーションに対してカスタマイズされた十分なタイムアウト値を設定することは難しいでしょう。

NAT機器でのポートの再利用周期とサーバ側のタイムアウト値の関係：NAT機器で空いているポートをどのように使用していくかは実装依存です。TCPのFINが来ていないポートの再利用禁止期間はRFC6888で２分間と決められていますが、FINが来て一度開放されたポートがすぐに再利用されてしまって、しかも同じ宛先サーバの同じポートに通信しようとした場合、 サーバ側のソケットがまだ閉じていなくて通信できない ということが起きる可能性があります。ISP側とサーバ側とのタイムアウト設定値の相性問題ですので、これを回避するためには世の中の全てのサーバに対して十分だと思われる時間ポートの再利用を行わないようにする必要があります。しかしあるISPが全てのコンテンツのサーバに対して問題が起きない十分なタイムアウト値を設定することは不可能ですし、またコンテンツプロバイダもNATを使用する全てのISPに対して正常に動作するサービスを提供することも難しいでしょう。

NATの限界

全てのアプリケーションを快適に動作させるにはNATのタイムアウト値を長く設定する必要があります。しかしそうするとポートの消費効率が悪くなるため、１家庭当たりたくさんのポート数を割り当てる必要が出てきます。たくさんのポート数を割り当てると１グローバルIPv4アドレスに収容できる家庭の数が減ってきます。

逆に言うと収容する端末が増えてきたにもかかわらず、IPv4アドレスがこれ以上入手不可能になった場合には、ISPは１家庭あたりのポート割当数を減らしたりタイムアウト値を短くしたりする必要に迫られるわけです。その分サービス品質は低下しますが、IPv4を生かすことに迫られている間は他に選択肢はありません。

この他にも、NATを通した時に特定のWebサイトに対してうまく通信ができずパフォーマンスに問題が出るような事例が見つかっていますが、未だ原因を解明できていません。特に１画面に多量に画像などを表示するサイトでは問題が出る可能性が高いです。

このような状況が発生したに我々が提供するWebサービスは快適に利用できるでしょうか？

もしそのようなISPのユーザに対しても 自分のWebサービスだけに対しては高いパフォーマンスでアクセスできるようにしたいのであれば、IPv4でアクセスさせることを避けるべきです。

IPv6に対応する

ここまで読んでいただいた皆様には なぜGoogleやFacebookやApple、それにCDN事業者がIPv6対応に本気を出しているのかがお分かりいただけるかと思います。

我々が提供しているWebサービスで画面の読み込みが遅くなったりできなくなったりして、ユーザから遅くて使えないサービスだと思われるのが問題になったり、そのパフォーマンス低下が損益に直結したりするような場合であれば、 ISPのNATに頼るのではなくコンテンツプロバイダ側で根本的な対策が必要になるでしょう。その 自衛方法の１つがIPv6対応になるでしょう。

特に中国、インド、東南アジアなどの地域でサービス提供を目指すコンテンツプロバイダにはIPv4の枯渇は死活問題になります。JANOG35で発表された人口あたりのIPv4アドレス数を考えると日本が一人あたり1.5アドレス以上あるのに対して、中国では0.24、インドでは0.02です。こういった国々に対してサービスを提供したい場合にはこのIPv4アドレス枯渇問題に対して真剣に取り組む必要があります。これらの国々ではIPv6のインターネットが主流になる可能性が十分にあります。

AppleはNAT64環境下で動作しないアプリはAppStoreで承認しないという方針を発表しました。これ自体はAppleがMVNOをIPv6+NAT64で提供しようと考えているからだと推測されますが、これに対応するだけでは不十分です。なぜならNAT64もIPv4へのNATを行う技術ですので、これまで述べてきた問題が同様に発生します。今年10月に総務省から発表された携帯キャリア３社の「モバイルネットワークのIPv6推進に向けた取り組み」も、おそらくこのIPv4 NATの限界問題を認識してのことではないかと思います。

IPv6に一気に対応するコストを払うのはコンテンツプロバイダにとって多大な負担になるので、今のうちから徐々にIPv6に対応することをオススメいたします。単純にフロントエンドのサーバにIPv6の到達性を持たせればいいわけではないですし、自前でネットワークを持っている規模のコンテンツプロバイダであればネットワーク機器もIPv6に対応したものにする必要があり、その検証から導入に時間もコストもかかります。もしあなたが今からサービスを立ち上げるのであればIPv6に対応したクラウドで、IPv4に依存しないアプリケーション設計を行うことをオススメいたします。

別の方向のアプローチとしてHTTP2に対応するという方法もあります。HTTP2では１つのTCPセッションの上で複数のHTTPセッションを通信させる機能が提供されています。Google, FacebookはSPDY/HTTP2に対応しています。HTTP2では１サイトに対して基本的には１ポートしか使わないのでポート数を節約することができ、NATの負荷を軽減することができます。ただし他のWebサービスが多数のポートを使った結果ポート枯渇が発生して、自分のWebサービスHTTP2のセッション自体が張れないという可能性は残ります。

まとめ

しばらくの間はNATによりIPv4インターネットは生き続けますが、NATにも限界があります。その限界に達した時に我々のWebサービスのパフォーマンスが低下しているように見えるユーザが現れ、サービスが重いと思われるリスクがあります。これに対してIPv6に対応することは効果的な対策になるでしょう。問題が起きる前に早いうちからIPv6に対応するためのコストを積み立てておいたほうが良いででしょう。

以上がコンテンツプロバイダこそがIPv6に対応しておいたほうがいい理由です。