IPv6はIPv4アドレス枯渇を直接解決するものではない
来年にはIANAのIPv4アドレスプールが枯渇すると思われます。 それに伴い、IPv6に関連する話題が増えてきました。
しかし、IPv6はIPv4アドレス枯渇を直接解決するものではありません。 IPv6とIPv4は、互換性がない別々のプロトコルです。 今の状況でIPv6への移行を自分一人が準備したとしても、世界がIPv4を利用している限りはIPv4アドレス枯渇による被害を自分が受けなくなるというわけではありません。
「IPv4アドレスが枯渇するからIPv6の準備をしないと」というロジックになり、「IPv4が枯渇するけど、IPv6間に合うの?」という表現を良く見るのですが、IPv4アドレス枯渇に伴う対策としてIPv6だけを考えるのは危険です。
「IPv6が間に合うか?」「IPv6が間に合わないか?」という表現をするのであれば、 個人的な感想では、IPv4アドレスが枯渇している時点で「IPv6への移行は間に合わなかった」のだろうと思います。 もし、「間に合って」いるのであれば、世界中のインターネットユーザの多くは既にIPv6へと移行していてIPv4の利用が減っている筈なので、IPv4アドレスは枯渇しなかった可能性があります。 ということもあり、「間に合う」という表現は微妙だというのが最近の私の考え方です。
と、こうやって書くと「何を言ってるんだ?頭おかしいんじゃない?」という感想をうけるかたもいらっしゃると思います。 実際、多少ややこしい話です。
ちょっと長めになりますが、ここでは、「IPv6への移行」と「IPv4アドレス枯渇対策」の違いを紹介したいと思います。 この二つは、似てるようで大きく異なります。
IPv6への移行と、IPv4アドレス枯渇対策は似て非なる物
広義では、IPv6への移行はIPv4アドレス枯渇対策です。 しかし、狭義ではIPv4アドレス枯渇対策は、IPv4上で行わなければいけません。
現時点のインターネットはIPv4で動いており、ユーザもIPv4を使っています。 そのため、IPv6で何かをしても、ほとんどのIPv4ユーザは使ってくれません。 今のインターネットを利用している今のユーザと、インターネットを使って通信を行うには、少なくともユーザ側はIPv4で行われる通信を使う必要があります。
IPv4アドレスが枯渇するということは、IPv4アドレスをこれ以上新たに割り当てられなくなるということであり、それでも規模を拡大したい場合には今あるIPv4アドレスをどうやって使い回すかという話になってきます。 そして、今あるIPv4アドレスを使い回すために、一部のIPv4アドレスの利用を圧縮して他にまわすようなことが要求されるようになります。 このようなことを考えたり、準備をするのが、IPv4アドレス枯渇対策です。
一方で、IPv6への移行というのは、IPv4との互換性がないIPv6を多くのユーザに使ってもらうようにしていく活動です。 これ以上IPアドレススペースを拡大出来ないIPv4ではなく、IPアドレススペースが巨大なIPv6へと引っ越してもらうことです。 みんながIPv4の世界に居て、IPv6の世界に居ない状態で、自分だけIPv6へと引っ越してもあまり意味がありません。
「IPv4アドレスが枯渇したから対策としてIPv6へと移行を急ぐべきだ!」というのは、マクロな視点で見た場合は、確かに解決策です。 インターネット全体や、国としてという視点で見た時には、IPv6への移行が「解決策」と言えそうです。
しかし、IPv4アドレス枯渇が実際にトリガーされた後に、痛みを伴う個々の事業者やユーザを主体として見た時には、IPv4アドレス枯渇対策というのは「限られたIPv4の世界でどうやって規模拡大を実現するか?」という話になります。
IPv4か?IPv6か?という二元論ではない
このように書くと「じゃあ、IPv6ってイラネ」と言ってるの?と突っ込まれそうですが、個人的な推測としては、IPv6は世界中で運用されると考えています。
現時点で、IPv6対応ネットワークは世界中で急激に増えていますし、IPv6をユーザへ提供する動きも活発になってきています。 キャリアやISPなどのインターネットインフラに関わる事業者などが、ユーザをIPv6へとシフトさせる必要があるので、徐々にIPv6へとユーザは移行するように促されると推測しています。
しかし、同時にIPv4は利用され続けるとも考えています。 これだけ広がっているIPv4が急激に縮小するとは思えません。 現時点でIPv6に取り組んでいる方々で、いきなりIPv6へとユーザ全部が移動すると思っている人に会った事はありません。
総務省報告書(総務省によるIPv6によるインターネットの利用高度化に関する研究会取りまとめ(案/2010年1月), p.14)を見ると、次のように2015年時点でのIPv6利用可能世帯数は1550万世帯〜1940万世帯と試算しています。
平成22年度版の情報通信白書によると平成21年末時点でのブロードバンド契約数は3171万契約です。
しかも、これは「回線としてはIPv6が利用可能」という数値であり、実際のユーザ数よりも多めな数値となってます。 この推測値を見る限り、今から5年後になってもインターネットユーザの半分以上がIPv6を使わず、今から10年経ってもIPv6への完全な移行は行われないだろと思われます。
とはいえ、IPv6が利用可能な環境は確実に増えて行きそうです。 アメリカやヨーロッパでは、急激にIPv6の話題が増えるとともに、IPv6ネットワークも増えています。 中国では2012からIPv6商用サービスが開始し、2015年には移行する計画があります(China Telecom Issues Complete IPv6 Schedule, Commercial Launch Set for 2012)。 インドでも2012年にIPv6サービスが開始されるようです(India Mandates Switch to IPv6 by March 2012)。
このように、IPv4とIPv6は1と0の関係のように「どっちか?」という話ではありません。 問題はもうちょっと複雑で、両方ともごちゃ混ぜな混在環境が今後構築されていきます。 いわゆるIPv4とIPv6のデュアルスタック環境という状態です。
「IPv4アドレスが枯渇したからIPv6だよ」という風に単純に全てを切り替えられるのであれば、様々な部分で楽なのでしょうが、そうは問屋が下ろさないでしょう。
恐らくIPv4は使われ続けます。 ただし、IPv6への移行も粛々と試みられるというのが現状での私の推測です(参考)。
IPv6懐疑論は世界中で言われていますが、特に日本では数値に現れるぐらい根強いようです。 OECDで発表されたIPv6アドレス割り当てグラフを見ると面白いです(OECDレポートから垣間見える「日本のIPv6」)。
ホスティング屋さんとIPv4アドレス枯渇
9月2日に行われたIRS22で、さくらインターネット研究所の大久保氏が発表されていた「データセンター屋さんのIPv4アドレス枯渇対策」に書かれている内容が切実です。
IPv4アドレス枯渇後のIPv4アドレス確保とプロトコルトランスレーションサービスが死活問題となっているのがわかります。 IPv4アドレス枯渇後に、何らかの形でサーバを増やして行く方法を模索しなければ、事業範囲の拡大ができなくなってしまいます。
資料中で、現在さくらインターネットが毎月4C分(約1024個)のIPv4アドレス新規割り当てを行っていると述べられています。 その状況下では、APNICプールが枯渇してさくらインターネットが新規IPv4アドレスを受け取れなくなると、さくらインターネットはその1年後に新規IPv4アドレスを提供できなくなります(「APNICプールが枯渇」と表現しているのは、JPNICは事業者からのIPv4アドレス要求をAPNICに出す形となっており、JPNICはプールを持っていないためです)。 その事実を述べた資料の次ページで、2011年竣工予定となっている石狩のデータセンターが紹介されています。 「最終的には60万台のサーバを稼働可能!60万個のIPv4アドレス!?(え」と書いてあるのが印象的です。
で、さらに次のようなスライドもあります。
IPv4アドレス枯渇対策
では、実際にIPv4アドレス枯渇対策として短期的に行えることとしてどのようなことがあるかというと、実はそんなに方法があるわけではありません。
考えられるのは、以下の方法です。
- 他者からのIPv4アドレスの確保(IPv4アドレス移転など)
- 現在利用しているIPv4アドレス数の圧縮と、圧縮した分の再利用
- ALG(Application Level Gateway)等を活用して一つのIPv4アドレスで複数サービス
(トランスレータに関しては今回は割愛)
他者からの確保:予想されるIPv4アドレス争奪戦
IPv4アドレス移転や、事実上のIPv4アドレス売買は行われるだろうと思います(APNICなどのRIRが認めているのは「移転」です。移転に伴って金銭などのやり取りがあるかないかはRIRの管轄の範疇外です)。
(続く:次へ)
最近のエントリ
- 日本のIPv6採用状況が50%を超えている件について
- 「ピアリング戦記」の英訳版EPUBを無料配布します!
- IPv4アドレス移転の売買価格推移および移転組織ランキング100
- 例示用IPv6アドレス 3fff::/20 が新たに追加
- ShowNet 2024のL2L3
- ShowNet 2024 ローカル5G
過去記事