2011年、IPv6元年
村田篤紀
Ｉ T 業界では喫緊の課題となっているIPv6 への対応について、解説してもらった。
災害情報とメディア
特集がソーシャルメディアということで、どうしようかと思っていたが、今回の震災にからんでFacebook やTwitter 経由で、情報が入ってきたり発信したりという流れがあったのでまずは記載しておこうと思う。
震災の情報を見て思ったことは、出てくる情報が少なすぎることと、何を信用したらよいか分からないことだった。
テレビのチャンネルはどこを回しても震災被害についての報道だらけで、それはそれで大事なのであるが、原発の報道についてはかなり限られたものしか見当たらなかったし、ジャーナリストがウェブで書き込みしたり、Ustream で記者会見を編集なしでそのまま流したり、という流れがあって、おぼろげながら何か起こりつつあることに気づいた読者は多かろう。
情報の出し手側は、素人には分からないから絞っているとか、混乱がないようにしているという言い分をするが、大半の人には分からなくても、分かる人間もいる。そういう人間に対して、データ公開することは大事であり、それがなければ判断できる人も判断できないことになる。
マスコミの報道は別として、活躍したメディアは以下のものだろう。
• ブログ
•Facebook、mixi といったSNS
• Ustream（ライブ）、YouTube（録画）といった動画サイト
• Yahoo! やGoogle といった検索サイト
•OKWave などの質問、返答サイト
報道が信じられないから現地にまで出向いてデータを取ってきて公開した方々もいる。頭が下がる思いだ。
Google の東日本大震災のパーソンファインダーも、まさにネットならではの素晴らしい試みだ。
マスコミでは個別の安否確認には向かないのだ。エリア単位での様子の把握までで、結局は個別の通信に頼らないと安否確認にまではいけない。ネット上の知り合いの安否はFacebook、不特定多数の情報提供・収集はTwitter という人も多かったようである。
各通信キャリアも災害用伝言板を準備して、対応している。ちなみに「携帯・PHS版災害用伝言板サービス」は2010年3月1日から全社一括で横断的に検索できるようになっている。
ＳＮＳとクラウド
一方で、災害情報をウェブで公開したサイトは、アクセス過多に陥り、ここで、クラウド事業者・データセンタ事業者が活躍した。
アカマイがCDNを無償提供したり、さくらインターネットがミラーサイトを立ち上げたりといった流れだ（他の事業者も手早く動いた）。
拠点が複数に分かれているクラウド事業者は、まさに今回のようなアクセス集中時にでも、リソース増強が素早くできる。クラウドサービスはバズワードだと言う人もいるが、それでもメリットは確実にあり、なんと呼ぶかは別としても、認めるべきサービスである。
さて、そうした災害時でも活躍したクラウドサービスであるが、SNSとも相性は抜群だ。
SNSに連携したサービスは、ユーザの口コミが急激に広まると、途端にアクセス過多に陥る。リソース見積りなんてできない代物だ。であれば、いつでもリソースの調整ができるクラウドサービスにしか解を求められないであろうことは想像に難くない。
また、震災時もそうだが、SNSにアクセスしてくる端末のほとんどはＰＣではないモバイル端末が多い。これもクラウドとの相性は高いと言ってよいだろう。
昔のクライアントサーバモデルがインターネット全体を通して極端に大きなモデルになったとも考えられる。
クライアントもサーバもIP（インターネットプロトコル）さえ喋れば、サービスの提供・受容が可能になるというものだ。セキュリティ面は別のレイヤの話として横に置いておいて、サービス提供自体には、IPというものがキーワードとなっている。
世界人口とＩＰアドレス
唐突であるが、IPv6 の話題になる。
前述のIPとは主としてIPv4 のことである。IPv5 やIPv7 もあるのか？と言われれば、ある（あった）が、忘れてしまってよいだろう。現在広く皆さんが使っているのはIPv4（のはず）である。
IPv6 は別に革命的な技術ではないし、過去20年くらい言われている次世代のIPプロトコル体系のことだ。
では、IPv6 とはなんであろうか？
誤解を恐れずに単純化すると、これまで32ビットだったIPアドレスを128ビットにまで広げたものだ。つまり、住所にあたるIPアドレスがそれまで約2の32剰（＝約43億弱）個であったものが、約2の128剰（＝約340澗）個まで使えるようになったのが大きな特徴の一つである。340澗個のアドレスとは想像もつかないが、ものすごーく大きな数まで扱えるようになったと思えばよいだろう。
43億というと途方もない数字に思えるが、実際にはそうではない。地球の人口は約60億人。IPv4 では、すべての人にIPアドレスは割り当てられないのだ。
インターネットは、個人のPCだけでは成り立たないし、他にもたくさんのコンピュータが必要になる。会社のPCもインターネットにつながっているし、携帯電話もインターネットに接続できるのが当たり前になってきている。そうすると、ひとりで何個ものIPアドレスが必要になるわけだ。そう考えていくと、4
3億は決して余裕のある数字ではないことが分かるであろう。
世界中で多くの端末がIPを利用するにつれて、IPアドレスの枯渇が起こったことが、IPv6 が騒がれてきた要因である。かなり昔からIPv6 は言われてはいたが、今年をIPv6 元年と私が呼んでいるのは、以下の2つの理由による。
（1）2011年2月3日にIANAにプールされていたIPv4 アドレスが「在庫切れ」となったため、日本でのIPv4 アドレスは2011年夏前に枯渇するものとみられること
（2）World IPv6 Day があること「在庫切れ」による影響「在庫切れ」になるということは、新規でIPv4 のグローバルIPアドレスを割り振ることができなくなることを意味する。
これまでも「在庫切れ」については言われてきていたが、NATの技術の普及でなんとかここまで生き延びてきた。しかし、とうとうIANAで「在庫切れ」（枯渇）してしまったのだ。
IANAでの枯渇の後、日本が含まれるAPNIC（JPNICも同時期）も枯渇し、データセンタやISPレベルで在庫がなくなると、以下の問題が出てくる。
○ サーバなどはグローバルIPアドレスと紐づいていないと外と通信できないため、既存のサーバは問題ないが、追加する際に問題が出てくる。プライベートIPアドレスを使う分には影響はない。
○ISPとの接続でも、グローバルIPアドレスと紐づいていないと外部と通信できなくなるため、新規の顧客の加入ができなくなる。
つまり、既存のサービスについては問題がすぐに起きることはないが、新規のサーバ追加、ユーザの追加時には影響が出てくるということである。
クラウドをベースとしたサービス追加、モバイル端末を主とした端末数の増加はこれからもどんどん出てくるなかで、「在庫切れ」が足かせとなるのは、ICTが必要インフラとなっている現在では避けなければならない重要問題であることは、論を待たないと思う。
IPv4 を用いたインターネットが停止することはないが、成長できなくなったのである。そこで、今後のインターネットの成長を担うものとして、設計・開発されたのが、IPv6 なのである。
I P v 6 とその影響について
IPv6 とIPv4 は基本的な仕組みはほとんど変わらないが、相互接続という意味で互換性があるわけではない。
IPv6 は、プロトコル的には、自動IPアドレス割り当て機能がある、原則的にはNATが不要でP2Pと相性がよい、標準でセキュリティがプロトコルに内包されている、などのメリットがあるが、やはりIPアドレス数が膨大であることが一番のメリットである。
また、後継であるとはいえ、どちらが上位などというものではないため、まったく新しいネットワークに向けてサービスするという観点が必要になる。
つまり、「IPv6 対応すれば、IPv4 ユーザにもサービス提供できます」というものではない。
これらを念頭に置くと、インターネットは当分の間、IPv4 のネットワークとIPv6 のネットワークが共存していくことになると分かるだろう。
既存のIPv4 ネットワークに対し、まったく新しいIPv6 ネットワークがインターネットに現れるのである（既に一部でIPv6 でのインターネット接続は行われているので、既にIPv6 のネットワークとIPv4 のネットワークはつながってはいる）。
互換性がない中で、どのようにユーザの混乱なく、IPv6 のサービスを広めていくか、ここが、各ＩＳＰやデータセンタの悩みどころである。迫られるI P v 6 への対応
これは公衆インターネットだけの問題ではなく、クラウドを含めたサーバ側のサービスを提供するデータセンタ事業者、オフィスや自宅そしてインターネット技術を用いたモバイル機器などでも問題となるため、SI事業者や端末開発者・アプリケーション開発者にも影響が出てくる。
トレーニング、管理、サポート業務・体制、課金、セキュリティ、アプリケーション開発など、すべてにおいてIPv6 への対応準備を進めなければならないのだ。
理想としては、IPv4 の枯渇やIPv6のサービスをユーザに意識させないことが大事であり、現在、ISPやデータセンタ事業者、またIPを用いてシステムを作るSI事業者などはどのように動いているかをやや専門的ではあるが、述べてみたいと思う。
基本スタンスは、（1）IPv6 アドレスで直接やりとりする環境を作る前に、トンネル環境を作って実験、（2）できるところからまずやって、ノウハウを貯める、である。似てはいるが互換性があるわけではないIPv4 とIPv6、求められるノウハウにも相違があるからだ。
ネットワークエンジニアの視点
ネットワークの作り方はIPv4 とほぼ等価でできる。細かな仕組みは違うが、設計思想は同じでよいと思われる。
ICMPについてはIPv6 ではルータでのパケット分割は許されなくなったため、有効化することを見落としがちなところが注意点である。ICMPはパスMTU探索で利用されるため、フラグメントが起こったり、通信ができなくなる可能性もある。また、DNSはアドレスの桁数が増えることから、UDPの512オクテットの制限を超えてしまうこともあり得るし、今回は述べないが別の理由からもTCPを使うことにする必要がある。
つまり、ルータやファイアウォールの設定の見直しも必要になる。
IPアドレスを自動的に付与する仕組みであるRAではDNS情報は入ってこないから、別途DHCPv6 サーバを用意するか手動での設定となる。しかしDHCPv6 サーバの提供なしでもアドレスを端末に自動設定できるメリットは大きいはずであり、特にセンサー機器やモバイル端末ではメリットが出ると思われる。
IPv4 とIPv6 との接続のために、いくつかのやり方があるが、エンジニアとしてはそれぞれに向き不向きがあることと、使えるサービスが限られていることもあるため、環境に合わせることが必要である。
一方で、ユーザ側の問題はほとんど出てこないはずだが、フレッツ光ネクストを使う場合、NTT東西のNGNのマルチプレフィックス問題があるため、どのISPを使うかで対処方法が変わる。接続時PPPoE を使うのがトンネル接続、IPoE を使うのがネイティブ接続であることは覚えておいた方がよい。
トンネルなら複数のISPを使い分ける（v4 含めて2つ）こともできるが、トンネル方式を使う前提として、アダプターが必要になる。本稿執筆時点ではサービス提供前のため不明点も多いが、詳細は各ISPに問い合わせてもらいたい。
サーバエンジニアとしての注意点
デュアルスタック（IPv4 とIPv6の両方のサービスを提供）として準備するのが現実的と思われる。IPv4 が枯渇したからといって、v4 からのアクセスがなくなるわけではないからだ。
また、外部のサーバとの連携をサーバレベルで行っている場合は、相手サーバがIPv4 でしかサービスしていない場合はIPv4 としてアクセスする必要があるため、簡単にIPv6 オンリーにはできないであろう。
IPv6 がメインになったときは逆にIPv4 をトンネルする、ということも出てくると思われる。
ただし、エンジニアとしてIPv4 とIPv6 のどちらを優先するかは、別途検討の余地がある。タイムアウトを待ったり、ICMPの到達性チェックだったり、提供サービスに合わせて、手直しを強いられる。フレームワークを使っている場合も、どのように実装されているのかのチェックが必要である。
ここでもIPv4 とIPv6 はまったく別のネットワークであることを忘れないことだ。また、サーバプロセスをIPv4 とIPv6 それぞれで待ち受けるか、1つのプロセスで両方を待つか、も実装に依存する。
OSについてはほぼ対応しているが、デフォルト設定がIPv4 のみとなっている場合があるので、見直しが必要である。
一方でアプリケーション側が一番問題を孕んでいる。コーディング次第ではあるが、IPアドレスを入れておく変数のサイズは見過ごしがちなのでチェックが必要になる。
また、スクリプト言語（LL）を使っている場合は処理系やライブラリが対応していれば、問題となるところだけを修正すればよいが、アドレスが長くなるので、ログデータは大きくなってしまうことは考慮すべき点である。意外と忘れがちなので、要注意である。
マッシュアップ関連はホスト名で名前解決をやっていると思われるため、IPv6 でのサービスとなっても影響はそれほど出ないだろうが、アプリ依存の部分もあるため確認は必要であろう。相手先がIPv6 でサービスしているのかIPv4 でサービスしているのかも確認が必要だと思われる。
DNSサーバについては、現在でも、IPv6 のアドレスを示す、AAAAアドレスで登録はできるが、逆引きの設定は、長いアドレスを個別に確認しながら手動で書くかなんらかの自動化ツールを使わないと間違ったりするこ
とになるから要注意だ。
監視サービスに使われるプロトコルやソフトウェアについては、各機器をチェックして対応を探る必要がある。
一方で、LSN（Large Scale NAT）配下のユーザからのアクセスについては、セッション管理やアクセス制限、ログ集計で問題が出る可能性もあるため、サービスにどれだけの影響が出るかなどの見直しは必要であろう。
現在のI P v 6 への対応状況
端末の対応状況
PCの一般的なOSやMac は対応済み。モバイル端末についてはメーカーに問い合わせが必要であるが、携帯キャリアがまだIPv6 での網を作っていないため、影響は軽微と思われる。
ただ、スマートフォンなどWiFi でアクセスすることもある機器については、個別にチェックが必要である。とはいえ、WiFi のキャリアがIPv6 サ
ービスをやるようになった後で確認すれば十分である。
ネットワーク機器の対応状況
IPv6 レディのロゴがついていればまずは大丈夫であるが、一度メーカーに問い合わせた方がよい。
ＩＳＰの対応状況
ブロードバンドアクセス回線（フレッツなど）とISP（インターネット接続プロバイダ）のサービスがIPv6に対応することが必要だが、IPv6 サービスをうたっているところに申し込めば利用は可能である。データセンタについてもIPv6 でサービスをしているところもあるため、問い合わせればよい。
サービスの対応状況
単純なウェブサーバやメールサーバについては、サーバプログラム自体は対応済みであるが、カスタマイズ部分などはサーバエンジニアの項で記載したように、見直しが必要である。
以上のように、端末側のモバイル通信とサーバ側のウェブシステム（クラウドと考えてよい）という、今のキーとなる2つをとってしても、IPv6 への道のりは長い。チェックするところがたくさんあるためだ。
Wo r l d I P v 6 D a y って？
「World IPv6 Day」は、2011年6月8日、24時間に渡り実施される予定のIPv6 トライアルである。サービスの提供者が一斉にある1日（24時間）だけ自社のサービスをIPv6 対応にして、影響を探ってみようという試みであり、参加はそれぞれの事業者や個人が自主的に決めるものである。
初回は6月8日0時UTC（日本時間で午前9時）から24時間を予定しており、これまででもっとも大規模なIPv6 の実験となる。Google やFacebook、Yahoo! に加え、アカマイやライムライトネットワークスといったCDN事業者も参加する。
また、ネットワーク機器ベンダや、国内のISPなども参加するという大規模なものである。既に専用でIPv6サービスをやっているところも、既存のサービスをIPv6 向けに変更して、実際の稼働実験をするわけである。
IPv4 とIPv6 の両方でサービスするため、ほとんどのユーザには問題は起こらないと思われるが、設定ミスや動作に不具合のあるネットワーク機器を見つけ出したり、想定外のバグを洗い出したりするにはよいきっかけになると思う。
読者の皆さんも、IPv6 でアクセスしたらどうなる？というのを試すには、http://test-ipv6.com/
というＵＲＬでテストすることができるので、ぜひ試してみてほしいし、イベントの結果も発表されるはずであるから、注視しておいてほしい。
