「サーバー・ソフトのIPv6対応はたやすい。だが，DNSやアクセス環境の整備など，Web開発者の立場からは見落としがちな盲点がある。IPv6化実践プロジェクトに取り組んだ結果，いくつかの確認ポイントが判明した」---。2009年2月23日，ライブドア執行役員CTA情報環境技術研究室長の伊勢幸一氏はITproテクノロジ・カンファレンス「プロバイダ/データセンターのIPv4アドレス枯渇対策」で講演し，自身が取り組んだIPv6化プロジェクトの成果を発表した。
Webコンテンツ・プロバイダとしての立場から，伊勢氏は2つのWebアプリケーションについてIPv4/v6デュアル・スタック化事例に取り組んだ。その1つは，2008年7月に立ち上げた，インターネット掲示板「2ちゃんねる」のIPv6掲示板「ipv6.2ch.net」である（AAAAレコードは2407:3000:6:175::12，Aレコードは125.6.175.12）。プロジェクトの開始は5月22日。データセンター内のIPv6対応，Webサーバー環境のv6対応，上位ネットワークとの接続などを経て，7月28日にIPv6掲示板を開設した。
「2ちゃんねるは，うまく事が運んだ事例」と伊勢氏は振り返る。2ちゃんねるのサーバーOSはFreeBSD，Webサーバー・ソフトはApache 2.0であり，ともにIPv6に対応済みだった。OSの設定ファイルとWebサーバーの設定ファイルである/etc/rc/confとhttpd.confにIPv6向けの設定を多少施すだけでIPv6対応が済んでしまった。アプリケーションで書き換えたのは，IPアドレスなどをハッシュにかけてIDを作成する部分だけである。加えて，本来は必要ないものの，CGI経由で環境変数「$ENV{REMOTE_ADDR}」を取得し，IPv6アドレスから来ているかどうかを判別できるようにした。
既存サービスのIPv6化にも取り組む
2ちゃんねるのIPv6掲示板に引き続き，2008年11月19日には，ライブドアが手がけるサービスのデュアル・スタック化にもとりかかった。対象としたのは，社内/社外にいるWeb開発者向けの，Webサービス運用プラットフォーム・サービス「EDGE Co.Lab」である。まずはタスク共有アプリケーション「fixdap」をIPv6化した。18日間のプロジェクトを経て，2008年12月15日にIPv6化した「EDGE Co.lab v6」と「fixdap v6」をリリース。Webサービスのプログラムの改修作業は正味2日である。
EDGE Co.Labのサーバー資源はプライベート・アドレス空間に存在しており，インターネットからはリバース・プロキシ経由で利用する。このため，IPv6対応を施す個所は，リバース・プロキシ部分となる。内部アドレスからのアクセスとなるため，リバース・プロキシ側でIPv6かIPv4かに応じてリクエスト・ヘッダー情報を独自に付与し，Webサーバー側のCGI経由で取得するようにした。
ところが，2ちゃんねるの掲示板とは異なり，EDGE Co.LabではIPv6化を完了するまでに，いくつかの課題にぶつかった。具体的には，18日間のIPv6化プロジェクトを通じて，7つのチェックポイントが見えたという。講演では，同プロジェクト18日間のすべてとチェックポイントを記した別冊子を配布した。冊子に書かれていた7つのチェックポイントは，それぞれ以下の通り。
- サーバーOSはIPv6対応しているか？
- HTTPサーバーはIPv6対応しているか？
- SSL証明書にはv4，v6の区別は無い（ホスト名だけでよい）
- ロギングのIPアドレス長は十分か？
- （ログの解析時に必要な）IPアドレスparserは対応しているか？
- 端末側UNI（User Network Innterface）はIPv6に対応しているか？
- DNSサーバーはIPv6対応か？
ポイントとして指摘したのは，同社はWeb開発が主体であったため，サーバー側アプリケーションのデュアル・スタック化に気を取られて意外な落とし穴にはまったこと。具体的には，アプリケーション開発者向けの端末側のIPv6対応が遅れていた。例えば，同社の社内LANがIPv6未対応だったため，ユーザーの端末からのアクセスができない状態だった。もう1つは，livedoorポータルのDNS（tcpserverとdjbdnsの組み合わせ）がIPv6対応していなかったこと。このため，代替案の用意などに1週間程度を費やした。
新たに作る分だけデュアル・スタック化しよう
IPv6対応の難しさについて，技術面で新規サービスは問題がなく，すでにサービスを提供済みのものについては若干の注意が必要だ，という。問題なのはビジネス面で，IPv6化による収益向上は皆無であること，IPv6への投資額は大きいこと，現状では需要が薄いこと，と指摘する。これらの諸問題に対して，どう対処するのかが問われる。
IPv6需要が少ない点について伊勢氏は，IPv6掲示板とfixdapのアクセス数を紹介した。IPv6掲示板は，サービス開始当初の2008年8月が1日あたり1万5000PV，うちIPv6経由は1500PVで10％がIPv6経由だった。それが，10月には全体のアクセス数は1万5000PVと変わらないもののIPv6経由は250PVに減り，2009年1月にはさらに全体が2万PVに対してIPv6経由は50PVになってしまった。直近の2009年2月では，2万PVに対してIPv6経由は250PVである。fixdapもアクセスは少ない。全体で2300PVに対して，IPv6経由は10PVである。「100万PV単位でモノを見ているWeb開発者にとって，この数値は存在していないのに等しい」（伊勢氏）。
このように，Web開発者にとって，IPv6対応は現時点では何のメリットも生まない。だが，IPv4アドレスはいずれは枯渇する。では，どうすればよいのか。この現実解として伊勢氏は，すでにあるアプリケーションやすでにある設備をIPv6化するのは止めようと訴える。「新規開発や新規機器の導入/ファームウエアのアップグレードといった，機能の更新時点において，コストをかけずにIPv6/v4のデュアル・スタックにしておくことが大切」と結論付けた。スクラッチで新規開発する際に，IPv4だけに対応するのと，デュアル・スタック対応にするのとで，コストはほとんど変わらないからだ。
一方，ネットワーク機器の購入に関しては，ベンダー選びが重要と説く。「IPv6対応のために特別なコストがかかるベンダーは，選ばない方がよい。同じ値段でデュアル・スタックが組める機器や保守サポートを選ぼう」とした。
