「ＩＰアドレス枯渇問題」から冗長系を見直そうという脈絡のない結論に達してみました（苦笑）
本日は時事問題を離れてコラムでございます。
なんか最近時事問題を書くとなると全て年金問題ばっかになってしまってちょっと書く方としても辟易してきちゃいまして（苦笑）、息抜きというかリフレッシュして閑話休題であります。
私は本業のＩＴ関連零細業のかたわら、週に一度工業系の学校の講師とか、不定期ですが年に１０回ほどですか自治体や商工会主催のＩＴセミナーの講師とかさせていただいております。
宿泊・食事・足代付きの地方のセミナーが特に大好きなのであります（苦笑）が、それはさておき、セミナー講師をしていてつくづく感じるのは、最近一昔前に比べて一般の人のパソコンやインターネットに関する知識の深くなったことでございます。
ＩＴ関連のセミナーしててもちょっと難しいところの説明をはしょって手を抜いてごまかしたりすると、すぐに専門的な突っ込み質問をいただちゃったりして、やりづらいったらありません（苦笑
ここまでインターネットが職場や家庭に普及しているわけですから、一般の人々の知識も深くなるわけでありますが、それでも大半の人はユーザーとしての知識の範疇でありまして、たとえばインターネットのプロトコル（通信規約のことです）であるＴＣＰ／ＩＰの話とかになりますと、ＩＴ関連技術者以外の人で関心を持たれている人の割合はぐんと少数派になるようです。
もちろん、このブログを読まれている方の中には私よりもお詳しい専門家の方もたくさんおられるでしょうが、大抵の読者をプロトコルの知識のあまりない一般人の人と想定してこのあとの話は進めていきたいと思います。
・・・
●インターネットの通信のお約束ごとであるＴＣＰ／ＩＰプロトコル
さて、世界中で広く普及しているインターネットでありますが、それが採用している通信プロトコル、通信のお約束ごとであるＴＣＰ／ＩＰプロトコルでありますが、これは正確に言うとＴＣＰ／ＩＰプロトコルスイートと称しまして、ＴＣＰやＩＰなどのプロトコルの集団・グループの総称なのでありますね。
例えば当ブログのＵＲＬですが、
http://d.hatena.ne.jp/kibashiri/
こいつの先頭のhttpですが、こいつもＴＣＰ／ＩＰプロトコルスイートの仲間のプロトコルでありまして、本名はHyperText Transfer Protocol、つまりWebサーバとクライアント(Webブラウザなど)がデータを送受信するのに使われるプロトコルでありますね。
このブログやホームページなどのHTML文書や、文書に関連付けられている画像、音声、動画などのファイルを、表現形式などの情報を含めてやり取りできるお約束ごとなのであります。
このお約束事は、IETFという国際組織によって、例えばHTTP/1.0はRFC 1945として、HTTP/1.1はRFC 2616として規格化されているのであります。
でね、あなたのＰＣで木走日記をご覧になっているのはブラウザソフト（大抵の人はウィンドウズのＩＥをそのままお使いでしょうが、通はfirefoxとかも使っていますでしょう）がhttpプロトコルを利用してインターネットの//d.hatena.ne.jp/kibashiri/
というＵＲＬをたどってこの日記の情報を取得しているのでございます。
ホームページを扱うこのhttpプロトコルやショートメールを扱うsmtpプロトコル、ファイルのダウンロード等に利用するftpプロトコルなどは、ＴＣＰ／ＩＰプロトコルスイートの中でも最も人間（ユーザー）に近い上位層・アプリケーション層に位置しています。
ＴＣＰ／ＩＰプロトコルスイートは、４つのレイヤー（層）から構成されていますが、上位のレイヤーのプロトコルは下位のレイヤーのプロトコルにサービスを要求して機能を実現しているのです。
例えば、あなたがブラウザ上でhttp://d.hatena.ne.jp/kibashiri/と当日記のＵＲＬを指定して表示要求をしたら、ブラウザはアプリケーション層のhttpプロトコルにサービス要求し、httpプロトコルは第２層のトランスポート層のTCPプロトコルにサービス要求し、TCPプロトコルは第３層のインターネットワーク層のIPプロトコルにサービス要求し、さらにIPプロトコルは最下層のネットワークインターフェース層に要求する、といった案配です。
●「ＩＰアドレス枯渇問題」
で、実際のインターネット上の住所でありますhttp://d.hatena.ne.jp/kibashiri/ですが、これ人間に解りやすいドメイン名でありますが、これ扱えるのは上位層のプロトコルだけでありましてＩＰプロトコル以下肝心の通信に実際関わるところではＩＰアドレスという無味乾燥の数字に置き換わってやり取りしています。
現在のＩＰアドレスは２進数３２桁、４バイトの大きさなんですが、これで表現できるアドレス空間は理論上00000000000000000000000000000000から11111111111111111111111111111111まで、２の３２乗つまり４２９４９６７２９６通り、約４３億個なのであります。
ま、２進数という０と１の固まりを３２桁連ねても目がおかしくなっちゃうので、一般的には８ビットずつ４つに区切りしかも人間に馴染みやすい１０進数表記で、255.255.0.1なんて感じで表記されるのであります。
早い話が理論的には現在のインターネットは４３億人までが定員なんでありまして、そいつを越えるとＩＰアドレスが振られなくなっちゃって、インターネットに参加できない、というゆゆしき問題が発生するのでありますね。
これが俗にいう「ＩＰアドレス枯渇問題」であります。
・・・
●実はペンタゴンが利用した軍事通信のプロトコルだったＴＣＰ／ＩＰ
なんだよ足らなくなるのがわかってたなら最初から３２桁じゃなくて６４桁とかにしとけばよかったじゃんか、と思うかも知れませんが、ＴＣＰ／ＩＰの歴史を紐解けばご理解いただけると思いますが、その３０年余りの歴史をＴＣＰ／ＩＰ誕生までさかのぼれば、別にＴＣＰ／ＩＰプロトコルはインターネットのために生まれたわけではないんですよね。
たまたまインターネットのほうが通信プロトコルとしてＴＣＰ／ＩＰを採用しただけで、まさか世界中の人々がここまで参加するとは思っても見なかったわけですから、ＴＣＰ／ＩＰプロトコル自体には何も罪はないのであります（苦笑
ちょと簡単にＴＣＰ／ＩＰの誕生と歴史に触れておきましょう。
１９６０年代に遡ります。
１９６３年イリノイ州で大停電が発生したのですが、その影響で全世界の米軍の軍事通信システムが３日間に渡りダウンしてしまいました。
事態を重視したペンタゴンは、敵の攻撃からも強靱な軍事通信システムの構築開発を目指した研究を支援していきます。
そこで、アメリカの国防総省はARPANETという通信ネットワークの構築を支援していきました。
ARPANETは軍関連機関、大学、研究機関などを結び、軍事技術、計算機科学などの共同研究に利用されていました。
そのARPANETのデータ通信のために研究開発された通信プロトコルの一つがＴＣＰ／ＩＰだったのです。
ARPANETでは軍事目的を想定し、核戦争などによりネットワー クの一部が破壊されても、残された部分で機能する通信ネットワークを求めていました。
このため、ＴＣＰ／ＩＰではネットワーク全体を特定のサイトが制御するような中央集権的なアプローチを避け（中央が破壊されたらシステム全体がダウンしちゃいますからね）、すべてのコンピュータや部分ネットワークが自律的に動くことによってデータ通信を実現します。
これね、今日のインターネット、ＷＷＷ、つまりＷｏｒｌｄでＷｉｄｅなＷｅｂ（世界的規模の蜘蛛の巣）の実態に正にぴったりでしょ。
今日のインターネットもまさに蜘蛛の巣のように入り組んだ通信網が世界中に拡大・拡散されていて、ここが中心といったコアは存在しませんよね。
だからどっかの国のどっかのネットワークがダウンしたり破壊されちゃっても、インターネット全体がダウンすることはあり得ないのです。
これはＴＣＰ／ＩＰという優れたプロトコルを採用したおかげなのであります。
・・・
●ＩＰｖ４からＩＰｖ６へのバージョンアップがままならない
少し話を戻しますと、現在約４３億個のアドレス空間を有するＩＰアドレスですが、近年の急速なインターネットの普及と利用者増加により、「ＩＰアドレス枯渇問題」が急浮上してまいりました。
そこでこのままじゃまずいということで、現在のＩＰｖ４つまりインターネットプロトコルバージョン４から、ＩＰｖ６インターネットプロトコルバージョン６が考案されたのであります。
ＩＰｖ６では現在の４バイト２進数３２桁のＩＰアドレスを１６バイト２進数１２８桁に拡張しちゃおう、って野心的な改良が施されました。
１２８桁もあれば２の１２８乗、それこそほぼ無限にアドレス空間が増えるわけですからこれで一気にインターネットの定員も無限に近くなり、「ＩＰアドレス枯渇問題」も解消されるのであります。
ところがみなさん、このＩＰｖ４からＩＰｖ６へのバージョンアップがままならないのであります。
世界中のインターネット参加ノード（ネットワークに参加する機器のことを一般にノードといいます。ま、ＰＣと置き換えてもらってもけっこうです）をある日、いっせいにＩＰｖ６対応に置き換えることができるならいいんですが、そんなこたあできるわけもありません。
そこでしばらくはＩＰｖ４を使いながら少しづつＩＰｖ６ネットワークをＩＰｖ４ネットワークの居候（いそうろう）のような位置づけでちょこちょこっと増やしてこう、とこういうことになったわけです。
当たり前ですが、現在の世界中のインターネットの参加ノード達、ルーターやＰＣ内の通信ボードなどは３２桁のＩＰアドレスにしか対応していないのでありますから、ＩＰｖ４からＩＰｖ６へのバージョンアップがままならないのは仕方のないところではあります。
一気に置き換えることなど不可能ですし、費用面だけでなく大規模な通信障害の発生リスクも議論されているのであります。
難儀な問題なのであります。
・・・
●とても興味深かった「ＩＰアドレス枯渇問題」論争
さてこのなんとも難儀な「ＩＰアドレス枯渇問題」なのですが、最近ネット上でこの問題がちょっとした論争になっておりましてとても興味深く拝見したのでした。
まず私も尊敬している池田信夫氏が通説に逆らうエントリーをして議論を巻き起こします。
池田信夫 blog
IPアドレスは枯渇していない
http://blog.goo.ne.jp/ikedanobuo/e/f0a92ba1bbd8a6510afb2d02b4f79f29
「IPアドレスは枯渇していない」とは何とも驚きのタイトルなんでありますが、失礼して冒頭部分を引用
コメントで教えてもらったが、総務省はIPアドレスの「枯渇対策会議」を今月中に立ち上げるそうだ。アドレスの配分を検討するのはいいが、それが枯渇するという事実認識は間違いである。IPv4のアドレスは約43億個、全世界のユーザー（約11億人）ひとり当たり4個もある。これに対して、現在のホスト数は約4億3000万なので、アドレスはまだ1割しか使われていないのだ。
うーん、これは全文は是非あちらにてお読みいただくとしてちょっとびっくりする内容なのでした。
要するに「現在のホスト数は約4億3000万なので、アドレスはまだ1割しか使われていない」つまり、枯渇どころかスカスカじゃんかってことなんですね。
なるほどなあと頷きつつ、私が授業やセミナー会場で講義してた「もうすぐＩＰアドレスがたんなくなっちゃうから大変なのよ」って内容が大嘘つきってことになっちゃうんでこれはちとまずいなあ（苦笑
などと唸っていたら、こちらも私も尊敬していて当ブログのことを取り上げていただいたこともある弾先生が反論エントリーを起こしたのでございます。
404 Blog Not Found
IPアドレスはいつ枯渇してもおかしくない
http://blog.livedoor.jp/dankogai/archives/50849028.html
さすが弾先生、仕事が速い（笑
失礼してポイント部分を引用。
池田先生、ちょっとこれはひどすぎ。
ホスト数 < 必要なIPアドレス数
まず、なぜ「たった一割」しかIPアドレスが使われていないのに、ネットワーク屋さんたちがそわそわしているのか。その理由は、IPのルーティングの仕組みにある。IPでは、ネットワークの指定を２のベキ乗でまとめないと出来ないのだ。
これは「アドレスはまだ1割しか使われていない」という池田先生の主張をいやいや「IPでは、ネットワークの指定を２のベキ乗でまとめないと出来ないのだ」からスカスカなんじゃなくて運用上どうしても隙間だらけになっちゃうんだよ、って反論なんでありますね。
うん、なるほどとても納得であります。
クラスとかややこしい話を除いて簡単にお話するとこういうことです。
たとえばある会社がＩＰアドレスを１３０個取得したいとします。
そうすると例えば、さっきＩＰアドレスの説明で４つの十進数に区切るとお話しましたが、２５５．２５５．２５５．０から２５５．２５５．２５５．１２９まで、例えばつまり最下位の数字を連続して１３０取得すればいいわけです。
ところが実際は、２５５．２５５．２５５．０から２５５．２５５．２５５．２５５まで、２５６個割り当てられちゃうんですね、その会社に、これが。
そうすると実際に使われているアドレスは１３０個で未使用なアドレスが１２６個発生しちゃうのであります。
で、その未使用領域のアドレスを他者に使ってもらうことは、今のインターネットの経路制御の技術的問題から不可能なのだ、というのであります。
「ホスト単位でIPアドレスがスカスカでも、ネットワーク単位ではIPアドレスはかつかつになりうる、そして実際にそうなりつつある理由がそこにある。」わけです。
・・・
まあ池田先生の実はスカスカじゃんというのも事実なのでしょうが、実際にネットワーク上じゃカツカツなんだよ、という弾先生の言い分に分があると私も思いましたです。
ただこの論争そのものがとても勉強になったのでありがたかったですね、やっぱりインターネットは素晴らしい（笑）。
●冗長系を見直そう
どうも最近の風潮で何でもかんでもやれ合理化だの無駄をなくせだのというスローガンがはやっているようですが、どうもいちいち御説御もっともなれど、合理化一辺倒じゃいろいろ問題があるよねってまとめにしたいと思います。
先ほど「ＩＰアドレス枯渇問題」はＴＣＰ／ＩＰそれ自体には何も罪はないという話をしましたが、それはそうなんですが、もしＴＣＰ／ＩＰプロトコル創生期に将来の使用者数の拡大を意識して当時から３２桁ではなく例えば６４桁のアドレス空間で設計していたらこの「ＩＰアドレス枯渇問題」はここまで騒がれてはいなかったことでしょう。
もちろんこれは結果論で、３０年前とかに今日のインターネットの普及を想定してプロトコルを作成することなんて無理なことだったでしょう。
そんな遠い将来に備えて冗長なアドレスを採用するなんて選択は当時の技術者達にはありえなかったでしょうね、パケットのヘッド部も冗長になっちゃうし、各ノードのアドレステーブルも冗長になっちゃうし影響大きいですもんね。
でもね、一見無駄な冗長な存在が実はシステム全体の信頼性（Reliability）を将来に渡って担保してくれるのでありまして、この「ＩＰアドレス枯渇問題」ですが、やっぱ物事は余裕を持って少し無駄を残しておくことも大切なんだということを示唆してくれてると、強引に結び付けたいですね、私としては（苦笑
コンピュータのシステムの世界では、この一見何もしない無駄な存在である冗長系が実はシステムの信頼性（Reliability）を高めているのであります。
例えば稼働率０．９のＰＣがあったとします。
稼働率０．９の意味は、９０時間稼動したら１０時間故障するというとんでもない粗悪品を意味しますから、実際はそんなＰＣ誰も買わないでしょう（苦笑）けど、例ですから気にしないでください。
で、そんな稼働率０．９のＰＣ、パソコンＡ、パソコンＢの２台でシステムを作成するとします。
素人は遊んでいるパソコンを発生させないでＡ、Ｂ２台とも活用するシステムを開発します。
資源を無駄にしないという発想から一見正しいのですが、システムの信頼性という意味ではこの無駄なパソコンを発生させないという合理主義はリスクを高めます。
なぜならば、このシステムはパソコンＡも動いてかつパソコンＢも動いて初めて稼動できることになるからです。
この場合のシステム全体の稼働率ですが、
０．９ ＊ ０．９ ＝ ０．８１
つまり８１％にまで落ちてしまうのです。
この場合プロはあえて冗長系を用意してパソコンＡだけで動くシステムを開発し、パソコンＢは冗長系（つまり予備機ですね）としてあえて遊ばせます。
こうすれば このシステムはパソコンＡが動いているか、もしくは予備機のパソコンＢが動いてれば稼動できることになるからです。
この場合のシステム全体の稼働率ですが、逆に考えればこの場合のシステム停止してしまうケースは、パソコンＡも故障してなおかつパソコンＢも同時に故障する場合だけですから
１ − （１ − ０．９） ＊ （１ −０．９）
＝ １− ０．０１ ＝ ０．９９
つまり稼働率は９９％まで向上するのであります。
ね、冗長系の存在って信頼性の面ではとっても重要なんです。
コストばかり追求しちゃうと信頼性とか大切なものを見失っちゃうってことであります。
本日は「ＩＰアドレス枯渇問題」から冗長系を見直そうという脈絡のない結論に達したコラムでございました（←何だこりゃ）
ジャンジャン。
（木走まさみず）
