IPv4アドレス枯渇がWebアドミンに与えるかも知れない影響

   このエントリをはてなブックマークに登録    2008/7/28-1

IPv4アドレス枯渇とIPv6化がネットワーク管理者に与える影響は比較的わかりやすいのですが、今回はIPv4アドレス枯渇がWebアドミン(Web屋?)に与えるかもしれない影響を考えてみました。 細かいところを含むと意外とありそうだと考えています。

IPv4のNAT化による回避作があるため、IPv6化は2000年問題のように「ある日突然」というようなXデーがなく、「乗り遅れ」「早すぎ」になってしまう可能性があってタイミングを計るのが非常に難しいと思われます。

以下、思いつきを列挙していますが、抜け等も多いと思うのでお気づきの方はご指摘頂ければ幸いです。

IPv4 NAT化による影響

まず、ISPによるIPv4グローバルアドレス配布が減っていき、ISPによるNATが一般的に行われるようになると発生するかも知れない影響を考えてみました。

ユニークユーザの推測が難しくなる

ISPがNATを開始すると、i-mode等の携帯電話インターネットサービスからのアクセスのように、アグリゲートされたアクセスに見えます。 そのため、同じIPv4アドレスからのアクセスであったとしても、一人なのか複数人なのかわかりません。

アクセス解析におけるcookie依存度合いが上昇するかも知れません。

掲示板への書き込み

掲示板への書き込みの個人を特定しにくくなります。 個人の特定をするには、IPv4アドレスだけではなく、アクセスに利用されたTCPポート番号(Source Port)も必要になりそうです。

ISPがNATを行っている場合、書き込みを行った個人を特定するためには、IPv4アドレスとTCPポート番号の両方をISPに提出する必要がありそうです。

アクセスログでポート番号を記録しなければいけない

アクセスログでポート番号も保存しなければならなくなるかも知れません。

現状ではTCPのポート番号まで保存しているアクセスログは非常に稀であり、様々な設定等が影響を受けると思われます。 場合によってはアクセスログのフォーマットが変わり、スクリプト等の書き換えが発生するかも知れません。

AJAXによるセッション数を考慮しなければならない

NATの変換テーブルは有限な資源であるため、ISPが行うキャリアグレードNATでは、各家庭が同時に使えるセッション数は制限されます。 この同時セッション数はISPによって設定が違うという状況が予想されます。 これは、各ISP毎に利用可能なグローバルIPv4アドレスや、利用してるNAT機器や、運営思想が異なるためです。

同時セッション数を越えるような通信を行うと、成立しない通信が発生してしまいます。 AJAXアプリケーションを制作して多量のセッションを消費してしまうと、条件によってはそれ以上の通信ができなくなる可能性もあります。

そのため、「このWebサイトは○○というISPからは繋がりにくい」というわかりにくいバグレポートが出てくるかも知れません。

IPv4→IPv6による影響

次に、IPv6ユーザが登場する事による影響を考えてみました。 この話はまだまだ先でしょうが、3〜5年後ぐらいにIPv6ユーザが徐々に増えた場合を想定した話になっています。

テスト環境の増加

ブラウザのバージョン違いのテスト等に加えて、IPv4の場合とIPv6の場合という場合分けも同時にテストしなければならない場合もありそうです。

さらに、「HTMLの表示はIPv4だけどAJAXはIPv6で」というような環境が発生する場合も考慮しなければならないかどうかなど、あまり考えたくないぐらいテストパターンが増えるかも知れません。

IPv4を内部で使っているCGIの処理



^(.*)\.(.*)\.(.*)\.(.*)$

^([^\.]*)\.([^\.]*)\.([^\.]*)\.([^\.]*)$

^(\d+)\.(\d+)\.(\d+)\.(\d+)$


とかをやった後に0〜255に収まっているか確認したり、その他方法を使ったりしてますか? 間に「:」が来るアドレスの事を考えていますか?

なお、学生時代のバイト等を含めると、私は今まで結構な数の未対応コードをこの世に発生させています。 そして、そのコードがその後誰の手に渡って、どのように利用されているのかされていないのかは知りません。 orz

データベースのテーブルにIPv4が入っている

CGI等の中にコードとして埋め込まれている場合もあれば、データベースのテーブルにIPv4アドレスが含まれている場合もあります。

そもそもIPv4を想定して書いている部分がどれだけあるかの調査

今まで書いた膨大なCGIやServelt等にどれだけIPv4を想定したコードが含まれているのかを調査しなければ、修正にどれだけの工数が必要かわかりません。

IPv4用アクセスログとIPv6アクセスログが別々になる可能性

システムや設定によっては、IPv4用のアクセスログとIPv6用のアクセスログが別ファイルとして用意されるかも知れません。

その場合、複数ファイルを読み込んで結果をまとめるような作業が発生するかも知れません。

顧客対応

「(顧客)Webが見られないのですが?」「(ヘルプデスク)ご利用のIPバージョンを教えて下さい」

最後に

とは言え、、、


「IPv6に関して準備を進めましょう!」

「で、IPv6ユーザって今はどれだけいるの?」

「....」

この会話が続く限りは、IPv6対応に動くのは難しいのかも知れません。 大手ISPがNAT化し、IPv6サービスがデフォルトになったりするまでは、対岸の火事状態は続くような気もします。

準備開始のタイミングを考える事を考えるというメタメタ(meta meta)な状態が続くのでしょうか。 数年後、どうなっているかですね。。。

* ここでは、簡単のためにNAPTを含めてNATと表現しています。

関連

   このエントリをはてなブックマークに登録