この記事はわりとコンピュータ専門家向きです。ただし、IT企業経営者やコンサルタントの方であれば、わかりにくい点があっても読んで頂くとよろしいかもしれません。
この記事の著者はネットワークの専門家ではありません。開発者・経営者・システム運用者としての観点から述べているものであり、ネットワークの専門的内容には誤りが含まれている可能性があることをご了承ください。
さて先述の記事のようにIPv6がダメというだけでは意味がありません。では、IPv4枯渇対策としてどのような方法が考えられるのかを列挙してみましょう。
* IPv4ヘッダのオプション導入 (難易度: いまさら遅い)
前の記事にも書きましたが、アドレス枯渇対策としては、IPv6のような互換性のないプロトコルではなく、IPv4ヘッダのオプションとして拡張アドレスを導入するという方法でアドレス空間を拡張する手法をとるべきでした。
IPv4ヘッダのオプションであれば、途中経由するルータが未対応であっても、そのまま通してもらうことができます。発信元と発信先の最終目的地部分だけが拡張アドレスに対応していれば良いのです。
10.1.1.1.256のように記述されたアドレスの場合、10.1.1.1までは通常のIPv4アドレスと同じように送信され、10.1.1.1のルータが256番のコンピュータへ送信を行います。この場合、末端のコンピュータが本形式に非対応であればアドレス変換を行ってもいいでしょうし、そうでなければそのままの形式で送ることができます。
この方法であれば上位互換性がありますので、OS、ブラウザやルータが新しいものに置き換わっていけば自然と対応が広がっていきます。ネットワークも末端部分だけを置き換えれば良いので、非常に容易に対応ができます。
P2P通信を使うようなSkypeなどのソフトウェアから徐々に有用性が認知されて広がっていったことでしょう。
いまさら普及が間に合わないので、枯渇対策としては時既に遅しですが、この方法であれば上位互換性を持ったままアドレス空間を十分に広げることができたので非常に残念です。
* プロバイダでのユーザ向けNATの導入 (難易度: 低)
ユーザの接続に関しては、NAT(ネットワークアドレス変換)を利用することで、TCPやUDPのポート番号を使ってアドレス空間を拡張することができます。
大規模NATではポート番号が足りなくなるという説がありますが、宛先アドレスごとに65536個のポートがあることを考えると、実際にはすぐに足りなくなることは考えにくいでしょう。
ただし、大規模NATを行うためのルータへの投資額はそれなりに大きなものになりそうです。
外から内への通信に関しては、NATを超えた通信を行う仕様の標準化さえ行われれば問題ないでしょう。またサーバ側に多少負荷はかかりますが、サーバを経由して通信することには何ら問題はありません。
この方法は、実際に行われていくだろうと考えられます。
* サーバへのNATの導入 (難易度: 低)
では、サーバにはNATが導入できないのでしょうか？
サーバへのNATの導入には、いくつかの問題があります。例えば、メール送信に使うSMTPはポート番号が固定されていますので、現状ではNATを利用することはできません。
ウェブ閲覧に使うHTTPであれば、ポート番号を自由に変更することができますが、URLが「http://example.com:4000」のようにダサい感じになってしまいます。これは顧客を直接相手にするサイトにとってはユーザの安心感や信頼度を下げてしまう大問題です。そのため、使われるとしてもアドレスバーに表示されないサーバ(画像やコンテンツの配信サーバ等)への適用になるでしょう。
他のプロトコルに関しても、多少ダサくなったり、多少設定が面倒だったりする以外は、何とかなるのではないかと思います。またトラフィックの大多数を占めているHTTP/HTTPSが何とかなるだけで、大きく状況はマシになると考えられます。
サーバネットワークにNATを導入している事例はまだ少ないと考えられるので、対応したネットワークスイッチが存在しないか、存在しても高価で設定が難しいかもしれません(調べてないけど)。ヤマハなどのルータには本方式を実現できる機能がありますが、速度的にはスイッチよりもだいぶ劣ると思われます。そのため現時点では実現可能性に難があります。
* サーバNATのためのSRVレコードへの対応 (難易度: 中)
サーバNATは、サーバ側におけるIPアドレス節約の王道ですが、先に述べたようにURLがダサくなってしまうことが難点です。これではメインのウェブサーバをNAT内に置くことができません。
ブラウザがhttp://example.comのような通常のアドレスを見たときに、ポート番号まで合わせてDNSで取得するように実装を変更されれば、サーバNATも普通に利用できるようになります。
このためにはブラウザがHTTPでアクセスするときにもDNSのSRVレコードに対応するようになればOKですが、これにはだいぶ時間がかかりそうです。
またHTTP以外の他のプロトコルに関してもNAT対応の標準化を急ぐべきでしょう。全てのプロトコルのNAT対応が完了すれば、実質的にIPアドレスは数万倍となり、当面は枯渇問題をしのぐことができます。
* SNI(Server Name Indication)の導入 (難易度: 低)
HTTPでは、サーバ側が一つのIPアドレスであっても複数のURLを割り当てることにより複数のサーバがあるかのように振る舞うことができます。これをVirtual Hostと言います。
これを利用することによりサーバやIPアドレスを集約して、アドレスを節約することできます。しかし、それには障壁がありVirtual HostではHTTPSが使えないのです。HTTPSでは、一つのサーバ名ごとに必ず一つのIPアドレスが必要となっていました。
それを解決するのがServer Name Indicationです。SNIが実装されると、HTTPSでもVirtual Hostを利用することができます。それによってIPアドレスが多少節約できる場合があると考えられます。但し、あくまでVirtual Hostにしか有効ではないので、アドレス枯渇の救世主とはならないように思われます。
SNIは実装が進められていますが、Windows XPのInternet Explorerには実装されない見通しなのが残念です。
* IPアドレス保有を有料にする (難易度: 高)
IPv4アドレスの枯渇には政治的な側面もあります。
IPv4アドレスの分配は市場メカニズムではなく、管理団体により恣意的に行われています。
たとえば、昔にIPv4アドレスを取得した団体ほど審査は緩く、容易に(ムダに)多数のアドレスを取得することができました。そのためアメリカには膨大な数(数千万)のIPアドレスを保有する組織がいくつもあります。
また自分でIPアドレスを保有申請できるプロバイダは容易にIPアドレスを取得出来るのにたいして、プロバイダを介して保有申請しなければいけないエンドユーザは、たった32～256個程度のIPアドレスを取得するにも毎月多額の接続料を支払わなければなりません。
アドレス枯渇のトレンドが明確になってからも、IPアドレス自体に課金することは行われていません。そのためIPアドレス取得が容易な組織にとってはIPアドレスを節約するインセンティブはありませんでした。
それどころか、IPアドレスを多量に消費すれば、もっとIPアドレスを所有する申請ができるのですから、IPアドレスを浪費するインセンティブがあることになります。
このような間違ったインセンティブと不公平な分配がIPアドレス枯渇を加速させた一因となっていることは間違いありません。
枯渇が心配された早期の段階でIPアドレス取得を有料にするべきでしたし、今からでも遅くはないのでIPアドレス保有を有料にするべきでしょう。しかしながら、それは政治的に難しいのかもしれません。
* まとめ
以上のように、IPアドレス枯渇対策には色々な手があります。もう枯渇が差し迫った今となっては、姑息的な打ち手しかないのが残念です。
またIPアドレスが米国において実際に逼迫するまでは、これらの実装は進まないと考えられるので、そうなると米国よりも先にIPアドレスが枯渇する諸国にとっては苦難の時期となることも考えられます。
日本としてはこうした手段がスムースに実装されるように努力しなければなりませんね。
0 件のコメント:
コメントを投稿