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/

というＵＲＬでテストすることができるので、ぜひ試してみてほしいし、イベントの結果も発表されるはずであるから、注視しておいてほしい。