IPv4アドレスのままだと・・・

IPv4アドレスの枯渇

IPv4は、32ビットでアドレスを定義しています。「32ビットのアドレス空間」
なんていう表現もよく使われます。アドレス空間とは、どれだけのアドレスが
利用できるのかということを、アドレスのビット数で表す表現方法と考えると
いいでしょう。

32ビットのアドレス空間は、TCP/IPが標準化されはじめた1980年代は十分な数
のように思われていました。単純に計算すると32ビットなので、アドレスの総
数は4,294,967,296個です。面倒なので約43億としておきます。ただし、43億
個のアドレスをすべて使えるわけではありません。IPv4アドレスは、クラスA
~クラスEの5つのクラスに分けられ、実際にコンピュータやルータなどのTCP/IP
ホストに設定できるのは、クラスA~クラスCのアドレスだけです。クラスA~
クラスCのうちでも、利用できないアドレス(0.0.0.0/8、127.0.0.0/8、プライ
ベートアドレス)などがあり、割り当て可能なアドレスは全体の約86%です。
つまり、最大で43億×0.86=約37億個のアドレスをホストに割り当てることが
できます。

現在の地球の全人口は64億人を越えています。仮に一人に一つIPアドレスを使
うとしたらまったく足りません。世界中の人々が一つずつIPアドレスを使う状
況は現実的ではないかもしれませんが、日本やアメリカ、中国などのIT先進国
の人々が一人当たり何十個ものIPアドレスを使う状況は十分に想像できます。
コンピュータだけでなく、カーナビなどのクルマの車載器、携帯電話、PDA、
家電製品、IP電話器などIPアドレスを必要とする、あるいはこれから必要とす
るであろうデバイスが数多くあります。

また、クラス分けによってアドレスの割り当てが効率よくできないということ
も合わせて、現在のIPv4アドレスは2010年ごろまでには枯渇してしまうだろう
と予測されています。(この時期には諸説があります)

IPv4アドレスの枯渇への対応

IPv4アドレスが枯渇するだろうという予測を受けて、その解決方法のアプロー
チが2つあります。

  1. アドレスの総数そのままで何とかしよう
    →CIDR、NAT(プライベートアドレスとの組み合わせ)
  2. アドレスの総数を増やせばいいじゃん!
    →IPv6

1.はいわば、対症療法で根本的な解決策ではありません。とりあえず、枯渇す
る時期を先延ばしにしようっていう考え方ですね。根本的な解決は、2.のアド
レスの総数を増やすということになります。そのために開発されたのがIPv6で
す。

1.のアドレス枯渇の時期を先延ばしにするための技術について簡単に触れてお
きます。
CIDR(Classless Inter Domain Routing)は、アドレスクラスにとらわれずに柔
軟にIPアドレスを割り当てるための集約技術です。たとえば、300個のIPアド
レスが必要な場合、クラスCではまかないきれません。かといって、クラスBを
割り当ててしまうとアドレスの利用効率が悪くなります。
そこで、複数の連続するクラスCアドレスを割り当ててひとつのネットワーク
として利用できるようにすることがCIDRです。

そして、NAT(Network Address Translation)は、1つのグローバルアドレスを
共有するという発想です。企業内LANや家庭内LAN上のコンピュータにはプライ
ベートアドレスを割り当て、それらがインターネットと通信するときは、NAT
によって、1つあるいは複数のグローバルアドレスを共有することによって、
IPアドレスの消費を抑えることができます。
いま、IPアドレスが枯渇するだろうと言われ続けても、まだそんな兆しがほと
んど見えないのは、このNATによるアドレス変換の仕組みがうまくいっている
ことが大きな理由でしょう。

ただ、NATによるIPアドレス枯渇の対策は、デメリットがあります。

NATの制限

NATによるIPアドレス枯渇の対策が、どのようなデメリットを引き起こすかと
いうことを簡単に解説します。

  • IPのエンドツーエンドモデルを壊してしまう。
    IPはそもそも、ホストとサーバ間などのエンドーツーエンドのデバイスのみ
    が処理をすればいいように設計されています。間にあるネットワークデバイ
    スは、基本的にルーティングすればいいだけです。ですが、NATはエンドー
    ツーエンドの経路上のデバイスがアドレス変換処理をしなければいけなくな
    ってしまいます。
  • アドレス変換のステートを維持する必要がある
    通信は通常、双方向で行われるので、行きのパケットのアドレス変換を行う
    とその戻りパケットのアドレス変換も行わなければいけません。つまり、ア
    ドレス変換のステートを管理する必要があります。
    NATのアドレス変換のステートを管理することで、パフォーマンス上の制限
    が出てきます。また、冗長構成時にNATのステートを引き継ぐためのメカニ
    ズムも必要になります。
  • NAT非対応のアプリケーションプロトコルがある
    NATは、本来、IPヘッダのアドレス情報を変換するための技術です。FTPなど
    一部のアプリケーションプロトコルは、アプリケーションそのもののデータ
    の中にアドレス情報を記述しています。そのようなアプリケーションプロト
    コルには、NATが対応できないケースがあります。最も現在は、そのような
    問題点はほとんど解消されていますが、追加の処理が必要なのでパフォーマ
    ンス上の制限が出てきます。
  • 重複したアドレッシングの問題
    NATはプライベートアドレスと組み合わせて利用します。もし、同じプライ
    ベートアドレスを利用する組織が、相互に通信をしなければいけないとき、
    アドレス重複の問題が発生する可能性があります。双方の組織で相互にNAT
    の変換を行うことで、重複したアドレッシングの問題を解決することもでき
    ますが、複雑な処理が必要です。

NATによるアドレス変換がうまく行き過ぎ、「IPv6は要らない。いまのままで
これからも十分つかえるだろう」という主張があります。ですが、NATによっ
て本来のIPの設計思想であるエンドツーエンドモデルが機能しなくなります。
また、複雑な処理が必要なことでパフォーマンス上の問題点が発生することを
考えると、NATはあくまでも短期的なソリューションです。根本的なIPv6の導
入によるアドレスの総数を増やすというソリューションが求められています。

こちらも参考にどうぞ↓
IPv4からIPv6へ! リクルート「キーマンズネット」

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA