IPアドレスが枯渇することによる影響は,人の立場や業務内容によって違うはず。ライブドアの通信環境技術研究室に所属する伊勢室長と門馬氏は,中でもアプリケーションの開発者がいちばん影響を受けると予測する。同社は既に,IPv6対応アプリケーションを検証できる実験環境の整備など,IPv6対応のプロジェクトに着手している。同社のIPv6対応への考え方と取り組みについて聞いた。

(聞き手は山崎 洋一=日経NETWORK


ライブドア 通信環境技術研究室 伊勢幸一氏(右),門馬優子氏(左)
ライブドア 通信環境技術研究室 伊勢幸一氏(右),門馬優子氏(左)
[画像のクリックで拡大表示]

IPv4アドレスの枯渇が話題に上るようになってきました。貴社ではこの問題に関して,どういったことに注目していますか。

 IPv4アドレスの枯渇について,こうした話題が出てきた歴史的背景や,国内外の通信事業者の具体的な取り組み,事例をまとめた資料や文献は,まだないと思っています。すべての問題点を整理して,それぞれにどう対応すべきかをまとめたものもありません。さらにこの問題に関して今ある情報は,もっぱら通信事業者の中の人たちに向けたものです。

 つまり,WebのプログラマやICT業界の経営陣など,いわゆるインターネット技術の専門家以外の人に向けられた情報がありません。こうした人々にとって,IPアドレスの枯渇は「最近騒がれているけど本当なの?」という感じだと思います。我々は,こうした人々に情報を提供しようと考えました。

 そこで,当社の社内,付き合いがあるWebのサービスの関係者,プログラマといった人々がIPv4アドレス枯渇問題の大枠を把握できる文書を作りました。これは報告書にして(著者は門馬氏),「IPv6普及・高度化推進協議会」のWebサイトで公開されています。

Webサービスの関係者やプログラマにアドレス枯渇の実態があまり伝わっていないというのは,例えばどういう場面で感じますか。

 この報告書を作るときに大変だったのは,「実際のサービス上でどのような問題が起こるか」についての情報収集でした。「Google マップと,それを表示するWebブラウザの間で何が起こるか」といったことを論じたレポートはほとんど出ていません。

 こうした情報はWebでも公開されていません。シンポジウムやイベントなどに参加して聞かないと中々わからないものなのです。今回の報告書の中には,先日参加したJANOGのミーティングで紹介されたスライドを借用させてもらいました。

 このミーティングに参加してみて,「ネットワーク側とWebコンテンツを作っている側との間には,かなりの意識のギャップがある」ということがわかりました。ライブドアはポータル・サイトとデータ・センター,プロバイダ事業を一つの会社で運営しており,1社でネットワーク運用とサーバーの運用,アプリケーション開発を手がけています。

 例えばデータ・センターは,ネットワーク接続をインターネット接続事業者(ISP)から提供してもらいます。ISPが提供してくれない限り,データ・センターは何もできませんし,何もできなければホスティングしていただいている顧客に何かを提供するという話になりません。しかしISPは,「こういったサービスをぜひ提供して下さい」と言われない限り,つまり需要がない限り,サービスを提供することは考えません。ここに,一つの「断絶」が生まれます。

 そしてデータ・センターは,顧客に対して特に何も言いません。そのため,顧客側もアプリケーションを開発する上でIPv6とIPv4のデュアル・スタックを考慮するわけがありません。そういう状況がずっと続いています。

アプリを新たに作るタイミングを逃さないことが重要

こうした現状が続くと,アドレス枯渇の影響を最も受けるのはどういう人々でしょうか。

 アプリケーションを開発して提供するASP(application service provider)のような人たちだと思います。デュアル・スタックのアプリケーションやシステムは,最初から作れば全然難しくありません。IPv4で作っても,IPv4とIPv6のデュアル・スタックで作っても,手間は同じです。ただし,IPv4だけに対応するものをデュアル・スタックにするのは,作り直すのと同じです。

 つまり,今後作るアプリケーションをデュアル・スタックに対応させておけば,ASPが困ることはないでしょう。しかし今この時点でも,多くの開発者はデュアル・スタックでは作っていないのが現状だと思います。3年くらいあとになって「やはりデュアル・スタックにしなくてはならない」となると,投資がかさむかもしれません。「デュアル・スタックのアプリケーションは作ったことがない。どうしよう」ということになれば,詳しい人たちに任せるためさらに投資がかさむかもしれません。

アプリケーションをデュアル・スタック対応にするとは,例えばどういうことなのでしょうか。

 Webサイトのトップページで,ユニーク・ユーザー数をカウントすることがあると思います。そのユニーク・ユーザーを,送信元IPアドレスを基に判定することがあります。このとき,ソースIPアドレスを処理するルーチンが,「xxx.xxx.xxx.xxx」というIPアドレスのピリオド(.)をセパレータにしてプログラミングされていたとします。

 ところがIPv6アドレスは,ピリオドではなくコロン(:)で区切ります。ですからここは,ピリオドとコロンとのどちらでも動くように書き換えなくてはいけません。また,IPv4アドレスを構成する4組の数字を四つのリストに格納して管理していたりすると,それはIPv6アドレスに合わせて増やさなくてはならないわけです。つまり,IPv4アドレスしか考慮せず作っていたアプリケーションは,書き直さなくてはいけなくなります。

 しかし,もともと長さが決まっていないリストを作っておいて,そこにコロンかドットのセパレータがあったら順にリストに詰めて入れていくようにしておけばいいわけです。