IPv6対応への道しるべ

第2回 単なるIPv6対応と,使えるレベルの対応はまったく別の話─Tokyo6to4プロジェクト 白畑真氏,大久保修一氏

この記事を読むのに必要な時間:およそ 3 分

6to4技術の行方

――Tokyo6to4は6to4以外の活動もしていますか?

Tokyo6to4では,6to4だけではなく,TeredoのRelay Routerも運用しています。Teredo Serverはマイクロソフトが運用しています。6to4はNAT下では利用できませんが,TeredoはUDPを利用してNATを越えることができるという特徴があります。ただし,セッション開始まで数秒かかることもあるという欠点があります。

――Tokyo6to4の運用形態を教えてください

Tokyo6to4プロジェクトは,非商用のプロジェクトです。お金が儲からないどころか,赤字にしかなりません。現状は,複数の組織からのドネーションで成り立っています。

Tokyo6to4が何故商用で成り立たないかというと,6to4利用者のトラフィックに対するコスト負担を行っているからです。Tokyo6to4が運用しているRelay Routerは,IPv4とIPv6の世界を繋げているわけですが,それぞれの世界に接続してトラフィックを捌かなければなりません。6to4を通じてIPv6インターネットに接続するコストを,実験的ということでご提供いただいているのが現状です。

なので,Tokyo6to4はボランティアプロジェクトとなっています。

画像

そういった問題もあり,6to4はISP等がIPv6接続サービスを提供するまでの過渡的な技術といえます。日本国内でも,ISPによるユーザへのIPv6サービスが徐々に開始されつつあり,Tokyo6to4もサービス終了の時期を模索しています。

実際,IETFでも6to4のRFCを「既に古いもの」という意味を持つhistoricalにするという議論がほぼ決まりかけていました。ただ,まだ時期尚早との意見もあり,その議論は一度白紙に戻って再度議論が続いているようです。

――Tokyo6to4運用の経験からわかった「ユーザがIPv6を利用するときに気をつけるべき点」を教えてください

最新のソフトウェアを利用してIPv6を利用することが大事だと思います。たとえば,Windows Updateを行ったり,最新バージョンのソフトウェアを利用したり,最新版のパッチを導入するなどが挙げられます。

IPv6関連は,これから利用される技術であるということもあり,まだバグも多いので,バグフィックスが行われている最新版であることが重要です。IPv4と違って枯れていない部分が多いです。

画像

パワーユーザに関してですが,よく理解して使うというのが重要です。たとえば,IPv4とIPv6が両方とも利用できるような環境では,あえてDNSを使わないでIPアドレス直打ちでテストを行うと自分がどのような通信をしているのかわかります。nslookupやdigで得られた結果のうち,自分が望むプロトコルスタックのIPアドレスを使うという方法です。

DNSを避けて,POPサーバやHTTPサーバと通信を行うことで,DNSの結果によるIPアドレスの自動選択によるテスト結果のばらつきを避けられます。AAAAしか持たないホスト名を作成するなど,IPv6とIPv4で名前を分けるのも一つの方法だと思います。

IPv4とIPv6混在環境でのDNSは,本当に難しいです。

「対応さえすればそれで終わり」ではない

――これからIPv6をバリバリ試してみようと思うヘビーユーザは,何を気をつけるべきでしょうか?

ユーザというよりもプログラマに対してのメッセージがあります。

今,多くの資料を見ていると「IPv6対応」として単純にgetaddrinfoを利用するように推奨しています。確かに,gethostbynameをgetaddrinfoにするだけで簡単にIPv6対応は可能ではありますが,快適な通信を行うという意味では,それだけでは不十分です。

たとえば,設定ミスやネットワークの問題によって6to4やTeredoを利用した通信が「つながらない」という状況が発生した場合でも,IPv6側が優先されてしまう状況が挙げられます。これは,IPv6を利用する部分から正常にフォールバックすればIPv4での通信ができます。

フォールバックによって通信開始まで時間がかかってしまいますが,これよりもさらにタチが悪い問題があります。IPv6での通信品質が悪く,スループットなどが十分に出ない環境で,通信ができるけど滅茶苦茶遅いという状況でIPv6でつながってしまって通信品質全体が悪化してしまうという問題もあります。その一方で,IPv4がサクサク動くという環境では「どちらを使うべきなんですか?」と。

一般的なプログラミング手法では「IPv6が使えればIPv6を使う」というのが正しいのでしょうけど,エンドユーザの視点から見れば「スカスカよく動く方」を使って欲しいわけです。そういう意味で,実際にはエラーハンドリングだけではなく,実際の通信品質まで見て通信を行わないと,プログラムの動作としては問題ないかも知れませんが,ユーザビリティという意味では厳しいと思います。

通信で応答が早い方を採用したり,通信品質が良い方を使ったりと,そういった手の込んだことをしないとユーザエクスペリエンスとしてのサクサク感は実現できません。

単にIPv6対応すれば良いというものでもないのかも知れません。逆に,そういうところまで考えないと,IPv6対応したときにトラブルに巻き込まれてしまう可能性があります。自分が利用しているのが6to4やTeredoを経由したIPv6なのか,ネイティブなIPv6なのか,それともIPv4なのかによってトラブル解決手法が変わってしまいます。

単にIPv6対応するということと,使えるレベルでのIPv6対応するというのは全く別の話であり,今後さまざまな取り組みが必要でしょう。

画像

最後に(インタビューアの感想)

「通信品質のどちらが良いか」ということを計測するためには,同時に複数TCPセッションを張ったうえでどちらの方がスループットが良いかを推定する必要がありそうですが,確かに今後は必要な技術だと思いました。

Tokyo6to4を運用する立場からの知見で得られた「今後必要になりそうな機能」というのは,非常に参考になりました。

著者プロフィール

あきみち

「Geekなぺーじ」を運営するブロガー。

慶應義塾大学SFC研究所上席所員。全日本剣道連盟 情報小委員会委員。通信技術,プログラミング,ネットコミュニティ,熱帯魚などに興味を持っている。

近著「インターネットのカタチ - もろさが織り成す粘り強い世界」

Twitter IDgeekpage

インターネットってなんだろう?(てくらぼ)