NewsInsight

IPv4アドレス枯渇にともなう現実問題を議論

枯渇後もリッチアプリケーションを使い続けるなら「IPv6は必要」

2008/10/08

　IPv4アドレス枯渇タスクフォースは10月6日、「IPv4アドレス枯渇対応テクニカルセミナー」を開催した。

　日本ネットワークインフォメーションセンター（JPNIC）などの試算によると、IPv4アドレスの消費は増大を続けており、早ければ2011年にはアドレスブロックの在庫が枯渇する見込みだ。IPv4アドレス枯渇タスクフォースはこの課題に対処することを目的に2008年9月に発足した業界団体だ。IPv6普及・高度化推進協議会など14のテレコム／インターネット関連団体が参加しており、IPv6への移行をはじめとするアドレス枯渇への対処策に取り組んでいる。

キャリアグレードNATの限界

　セミナーの中でNTTコミュニケーションズの宮川晋氏は、完全なIPv6化に向けた段階的な移行ステップについてプレゼンテーションを行った。現在、移行期の技術として「キャリアグレードNAT」（ISP側で提供するNAT）が着目されている。宮川氏は、「キャリアグレードNATがあればIPv6に移行する必要はない」という考え方は誤解であるとしつつも、IPv4が完全になくなるまでの「つなぎ」としての役割には期待できると述べた。

　「IPv4は間違いなく足りなくなる。いずれIPv6を使わざるをえないだろう。だが、世の中には古いマシンがたくさんある。Windows XPでも、Service Pack 3以前ではDNSの通信にIPv4を使っている。こういったことを考え合わせると、日本全国から本当にIPv4が消滅するのには10年くらいかかる」（宮川氏）

　こうした移行期に、古いマシンも含め、サービスをある程度のレベルで利用できるようにする技術がキャリアグレードNATだ。従来、主に手元のブロードバンドルータで実施していたNATをISP側で実施し、IPv6アドレスとIPv4プライベートアドレスを変換することで、接続を継続でいる。

　ただ宮川氏は、「キャリアグレードNATがあればIPv6が不要になるわけではない」と釘を刺した。その理由は技術的に明快だ。NATではポートを活用するが、そのポート数には上限がある。「つまり、NATを透過できるセッション数には上限がある」（宮川氏）

　セッション数に上限があると何が起こるかというと、Webアプリケーションの利用に支障が生じる。特に、Google Mapsなど、Ajaxを活用したリッチなWebアプリケーションでは、一度に多数のセッションを張ってデータを持ってくる仕組みを採用しているため、セッション数を制限した環境ではこれまで通りに利用できない。Google Mapsなどは穴だらけの地図になってしまう。

　宮川氏によると、OCNで統計を取ってみたところ、1ユーザー当たり平均で500セッションを利用している。特に何もしていなくても、アップデート確認のためなどに10〜20セッションが利用されるし、iTunesに至っては300セッション近く消費する。

　キャリアグレードNATではセッション数の制限があることを考えると、「要するにIPv6は必要だ。特に、AjaxやRSS、P2Pといったリッチコンテンツには必要だ」（同氏）。

　その上で宮川氏は、IPv6への移行は段階的に進むであろうという青写真を描いた。まずはバックボーンのデュアルスタック化からはじまり、キャリアグレードNATの導入とソフトワイヤの活用、さらに顧客側ルータの入れ替えといった作業を経ることになるが、「2010年から2020年にかけての10年間は、IPv4とIPv6が共存するだろう」（同氏）。そして、キャリアグレードNATがあるからといってIPv6が不要となるわけではないが、IPv4アドレスの消費を抑え、その移行を行うための時間的余裕を稼ぐことはできると説明した。

IPv6対応は本当に進んでいるのか？

　IPv6普及・高度化推進協議会の工藤真吾氏（IPv4/IPv6共存WG サービス移行サブWG・主査）は、9月3日から5日にかけて実施した、IPv6での動作検証結果を報告した。

　サーバの場合、Linux（Ubuntu、CentOS）上でBIND、Apacheといった標準で入っているパッケージの動作を検証した。多少設定ファイルの記述に工夫を要する点もあったが、IPv6環境でも普通に動作し、リバースプロキシも同様だったという。またWindows Server 2008とIISの組み合わせも同様だった。

　ただ「セキュリティアップデートのサイトにアクセスできないという課題があった。IPv4での通信環境がない場合、サーバの設置場所について考慮する必要があるだろう」（工藤氏）。また、DNSという仕組み自体には問題がなかったが、レジストラ側の対応がまだ不十分で、IPv6に対応したAAAAレコードでの登録ができなかったり、Authority側のDNSサーバがIPv6非対応だったりするという問題も浮上した。

　ルータやトランスレータ、ロードバランサといったネットワーク機器では対応が進んでおり、IPv4と同様に動作することが実証された。また、クライアントもほぼ問題なく接続できた。

　ただ「実は、検証を実施するのにIPv4アドレスが必要だ。IPv4アドレスが残っている段階で検証をしないと実験環境でアドレスが足りなくなって、検証中に枯渇対策が必要になる」（工藤氏）という皮肉な状況も明らかになった。

　工藤氏はまた「低いレイヤでの対応は比較的進んでいるとし、コンテンツ側がそうしたレイヤを意識して作っていく必要もあるだろう」と述べている。

　これを受けて小山哲志氏（ビート・クラフト／日本UNIXユーザ会）は、ホスティングサービスやWebアプリケーションサービスを作っている側のIPv6対応が遅れており、アドレス枯渇問題に対する認識も薄いと警鐘を鳴らした。

　Webをベースとしたサービスの多くは、長年かけて少しずつ改良を加え、現在の姿に至っている。「それと同じものが、短期間のうちにIPv6でできるのかという疑問がある」（小山氏）。どのくらい影響があり、どんな対応が必要なのかを見極めるためにも、いま必要なのは、データセンターによるIPv6のテスト環境だという。「実際に気楽に試せる環境がない」（小山氏）

　小山氏は、Webアプリケーションはさまざまな要素技術が組み合わさっており、複雑な仕組みであることに触れ、「単純に『ApacheがIPv6対応しているから大丈夫』というわけにはいかない。Apacheのモジュールやそこで使われている軽量言語がIPv6でちゃんと動くかどうか、実は誰もきちんと検証していない」と指摘した。実サービスでの運用をにらむと、ほかにも検証すべき要素は多々ある。外部サービスの呼び出し部分やOpenIDをはじめとする認証技術、あるいはサーバの運用に目を向けるとハイアベイラビリティの確保やログ収集・解析など、まだまだ検証が必要な部分が残されているという。

　「いまは『鶏が先か、卵が先か』という状態だ。ユーザーが少なくてアクセスも少ないからインセンティブがなく、ゆえにやるメリットが見いだせずデータセンター側もIPv6メニューがない、だからユーザーが少ない……という、2000年ごろの歴史を繰り返している」（小山氏）。しかし、当時と異なるのは、デッドラインが目の前に迫っていることだ。「まだIPv4枯渇問題はあまり知られていない。何らかの形でインセンティブを作らないと、問題を知らないままデッドエンドの日を迎えてしまう」とし、その前に「Web屋」が安価にIPv6を試せる環境が必要だと述べている。