InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

枯渇するIPv4。IPv6はどこに?

作者 Alex Blewitt , 翻訳者 笹井 崇司 投稿日 2010年2月7日

セクション
運用/インフラ,
エンタープライズ・アーキテクチャ,
設計/アーキテクチャ
トピック
テクノロジー ,
マネジメント ,
Architecture ,
Web 2.0

原文(投稿日:2010/01/29)へのリンク

今週、IPアドレスの割り当てを監督している5つの地域インターネットレジストリの代表機関であるNRO(Number Resource Organisation)は、未割り当てのIPv4アドレスが10%を切ったことを発表した。これはインターネットを使っている誰もが懸念すべき問題なのだが、こうした数字(および、発表)は誇張されていることが多く、解決する責任は他の人にあると全員が思っている。しかし、近い将来に解決されなければ、その影響は計り知れない。

IPv4アドレスとは何か?

まずはその背景について知っておこう。インターネットと会話できるすべてのコンピュータもしくはモバイル機器には、ユニークでグローバルなアドレスが必要になる。これによりデバイスは離れたホスト(例えば、www.infoq.com)に対してデータを送ることができ、正しくデータを取得することができる。DNS(Domain Name Service)は、このようなアドレスを、人間にとってわかりやすい馴染みのある名前に変換してくれる。例えば、この www.infoq.com をブラウズするとき、DNSはユニークでグローバルな63.246.7.184というアドレスに変換するものだ。また、ブラウザがリクエストを送るときには、216.239.59.99といった「戻り」アドレスを必ず残している。

これら4つの数はIPv4アドレスと呼ばれ、単にIPアドレスと呼ばれることもある。4つの数はそれぞれ0から255までの値のいずれかになるので、可能なIPアドレスには43億個あることになる。明らかに、デバイスの数には上限がある。 – それに対して、地球上には67億の人間がいる。理想的に世界中に配布しても、平均で2人に1つのIPアドレスしかないということだ。しかも、西洋社会にはネットワークに接続可能なデバイスがたくさんある(携帯電話の数は言うまでもないだろう。すでに40億を超えていると推定されている)

すべてのIPアドレスが、グローバルにルーティング可能であるわけではない。10.0.0.0 - 10.255.255.255は、プライベートにルーティング可能なアドレス範囲として定義されている。172.16.0.0 - 172.31.255.255192.168.0.0 - 192.168.255.255 も同様だ。最後に挙げたアドレス範囲は、ローカルネットワークで自動的に割り当てられるアドレスとしてなじみがあるかもしれない。さらに、マルチキャストに割り当てられているアドレスもある。224.x.x.x232.0.0.x233.0.0.xはマルチキャストのためのアドレス空間として定義されている。

これらを考慮すると、実際に使えるIPv4アドレスは40億個以下になる。NROはこれらのアドレスを配布するローカルな地域インターネットレジストリ(RIR)を監督しており、RIRはこれらのIPアドレスをあなたがインターネットに接続するISPに順次配布している。

このニュースは基本的に、そのアドレス空間において未割り当てのまま残っているアドレスが10%を切った、すなわち約4億個になったということだ。まだたくさんあるように見えるかもしれないが、IPアドレスは増やせるリソースではなく、なくなってしまえばそれっきりだ。もちろん、いくつかのブロックは再利用できるかもしれない。でも、それには(法的にも現実的にも)莫大な労力がかかり、問題を数か月ほど先送りするだけだ。最終的にIPアドレスが枯渇する日を推測するカウンターがあるのだが、2012-2013といった時期になると予想している。中央レジストリが枯渇しても、地域レジストリは(需要によるが)あと1年ほどは何とかやっていけるだろう。もちろん、IPv4アドレスの最後の残りを求めるゴールドラッシュのような殺到が起こらずに、需要がこれまで通りであればだ。

IPv4アドレスが足らなくなるとどうなるのか?

簡単な答えはこうだ。たいしたことはない。インターネットはほとんどこれまで同様に機能し続ける。あなたは新しいサイトをブラウズすることもできるだろう。しかし、ネット上では新しいビジネスが生まれなくなるだろう。少なくとも、既存のIPアドレス上に複数のサイトをホストしない限りは。要するに、過去10年でふくらんだインターネット経済は減速するということだ。

NATがクライアント側のアドレス不足を解決すると主張する人たちもいる(NATとは、1つのルーティング可能なグローバルなIPアドレスの背後に、ルーティング不可能なアドレスを隠すという技術である)。しかし、NATにも限界がある。各コンピュータが25個のポートを開いてインターネットに接続して同時に動いているとしよう(Webページをいくつか開いて、時々メールクライアントやソーシャルネットワークアプケーションを動かしていれば、そう難しい数ではない)。たいていのNAT可能なルータは、同時に50,000ポートまでしか対応できない、つまり、1つのルーティング可能なグローバルなIPアドレスは高々50,000個分しかさばけないことと合わせて考えてみよう。

さらに、NATは他から接続される必要のあるサーバやWebサイトなどには使えない。サーバやWebサイトに接続するクライアント側にのみ適用することができるのだ。ますます増加するクライアントの問題を解決できるかどうかによらず、IPv4アドレスがなくなると新規のサーバもなくなるだろう。

IPv6に参加する

IPv6はIPv4の枯渇問題を解決するとともに、いろいろな機能を追加するために作られた。IPv4アドレスは32ビットで構成されていたが、IPv6アドレスは128ビットで構成されている。それを考慮すると、地球上の1ミリ四方に100万の100万個分以上のIPv6アドレスがあることになる。その上、これは終端デバイスで利用できるIPv6アドレスのサイズにマイナスの影響を与えずに、ルーティング情報をアドレス空間に追加することができる。しかも、ローカルネットワークがデバイスのMACアドレスを使って自動的にサブネットからアドレスを割り当てることも可能になる。

だが、移行はそう容易なことではない。IPv6デバイスはIPv6デバイスとお話しでき、IPv4デバイスはIPv4デバイスとお話しできる。幸運なことに、最近の主要なOSやハードウェアはみな最初からIPv6をサポートしており、IPv6が使えるネットワークに追加されると自動的にIPv6が有効になる。したがって、最も簡単に移行するには、コンピュータがIPv4かIPv6のいずれかを話して目的地に到達できるよう、デュアルホスティングを提供することだ。

しかし、IPv4上でしか利用できないサービスもある。例えば、Googleのwww.google.comはIPv4でしか利用できない。彼らには別のWebサイトipv6.google.comがあり、こちらはIPv6ネットワークからしか見えない(もしIPv6のサイトをブラウズできれば、あなたのコンピュータはすでにIPv6でつながっている)。

この引き継ぎを簡単にするために、IPv4アドレス空間をIPv6アドレス空間のサブネットに対応付けるための仕組みが2つある。6to4は、IPv4とIPv6の両方のネットワークにあるホスト間を自動的に対応付けるもので、IPv6マシン群を1つのIPv4アドレスでやり取りするために使うことができる。(ブリッジの相手側がプライベートなIPv4アドレスの代わりにIPv6アドレスであることを除いて、これはNATがやっていることに似ている。)これはAppleが採用しているアプローチであり、インターネットに接続したルータ(実際にはOS)は、ISPがサポートしていれば自動的に適切な6to4ゲートウェイを検出する。Googleによる2008年のRIPEでのプレゼンテーションは、Mac OS XがIPv6の導入をリードしていることを示している(これは主に、クライアントをセットアップすることなく有効になるためだ)。AppleのAirport Extremeもまた自動的にIPv6アドレスを設定する。 – そして、ローカルネットワークにサブネットを配布する – つまり、ほとんどのユーザはすでにIPv6アドレスがあることを知りさえしないかもしれない。

Windowsシステムは一般的にTeredoトンネリングを使うのが好まれている。Vistaでは利用可能であれば自動的にIPv6を有効にする。つまり、私たちはいつの間にかIPv6への移行フェーズにいるということだ。

6to4とTeredoはいずれも移行のためにある。つまり、10年以上続くようなものではない(とにかく、ネイティブでIPv6になればなくなるだろう)。最終的になくなるにはいくらか時間はかかるだろうが、その時点でIPv4インターネットはリタイアする。

現状

あなたは残りのIPv4アドレス空間がほとんどなくなっても、インターネット接続を監督している人たちがうまく面倒をみてくれると考えているだろう。しかし、ISPの大部分はIPv6について知らないし、大規模Webサイトや主要なインフラストラクチャサービス(例えば、www.direct.gov.uk)のほとんどもそうだ。これらは6to4クライアントが変換してくれない限り、IPv6の世界になるとアクセスできなくなるのだが、そういう切迫感はまったくない。BTの21CNのように、巨大な電話会社でさえも、英国の電子頭脳に対してIPv4アップグレードを展開することを考えていて、依然として20世紀にしがみついている。

ISPは打撃を受ける最初の場所になるだろう。したがって理想的には、彼らがIPv6展開の最前線に立つべきだ。フランスのように中央のIPv6トンネルプロバイダのおかげで浸透率が増えている国もあるが、現在のところ、IPv6のユーザは全体で1%にも満たない。

中国は2008年に、IPv6を使ってオリンピックをホストすると表明した。中国人ユーザの増加に伴って、IPv6を展開するという国家戦略が本格化している。国別のIPv6デプロイメントのリストがあるが、多くのアーリームーバー(early mover)がIPv6ネットワーキングの推進を目指している。

まとめ

IPv4アドレスは有限であって、近いうちに枯渇するリソースである。「ダークな」IP空間の回収や未使用IPアドレスの再利用といった暫定的な解決策をとっても、不可避なことを数か月ほど先送りするだけだろう。IPv6は大規模なデプロイメントへの動きが見られており、すでにすべてのOSでサポートされている。したがって、IPv6展開の遂行は今やISPの手の中にある。ちなみに、彼らはこの移行によって得るものも失うものも多い。しかし、報告によると、まだIPv6のホストの浸透率は1%にすぎず、依然として前途多難であることを示唆している。

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。