～IPv6が身近にやってくる今、越えなければならない壁
IPv6普及高度化推進協議会 IPv6端末OS評価SWG
株式会社リコー ソフトウェア研究開発本部 大平浩貴
Windows VistaによるIPv6端末の急増
昔話で恐縮ですが、今のような安価で小型コンピュータがなかった頃、タンスのような大きなコンピュータを、ユーザはどのように利用していたのでしょうか？ ユーザーが大きなコンピュータ本体に直接触れることはあまりなく、コンピュータ本体と対話するための機器を介して使用していました。ユーザが直接触れるこの機器を端末と呼んでいました。
当時の端末はディスプレイ、キーボード、そしてシリアルインターフェースを持っていました。そして、端末にはキーボードから入力された文字をシリアルからコンピュータに送信する機能と、コンピュータから到着したキャラクタデータを表示する機能がありました（さも見てきたかのように書いてしまいましたが、正直に言うと、私はそのような端末の雄であるVT100の実物をみたことがありません。今Googleのイメージ検索を使って初めてそのデザインを知りました。こういう歴史的な機器を直接触ったことのある方が羨ましいですね）。
そんな端末が幅をきかせていた頃から幾星霜。現在、ユーザにとってフロントエンドである端末は、コンピュータとしての高度な処理機能を持ち、汎用のOSが搭載されるに至りました。ですから、現在のコンピュータを端末と呼ぶのは不適切かも知れません。しかし、現在のPCは、自身が高度な演算能力、通信能力、サービス提供能力を持ちつつも、Webサーバなどを利用する端末的な機能も持っています。そこで本稿では、通常のPCもユーザが直接触るという観点から端末と呼ばせて頂きます。
さて、私たちが直接触れるPCにインストールされるOS、つまり私たちが直接触れる端末OSは、ここにきてIPv6化の潮流に乗ってきました。この端末OSの最たる例がWindowsです。既にWindows XPからIPv6対応が進められていましたが、Windows Vistaからは本格的なIPv6対応OSとなります。また、Windowsだけでなく、MacOS Xや、Solaris、Linux、*BSDなど、メジャーなOSも既にIPv6に対応しております。
このような私たちが直接触れる端末OSはPCの工場出荷時点ですでにインストールされており、さらにそれが初期状態でIPv6機能が動作するようになりつつあります。買ってきたPCを起動してネットワークに接続すれば、何もしなくてもそのPCにIPv6 アドレスが割り振られている、そんなことがあたりまえになりつつあるのです。
WIDE v6fix WGという先達の実績とともに、端末OSの動作を考える
IPv6端末OSの本格的な普及が始まりました。これによって、ネットワークの透過的なアドレッシングができるようになり、様々なデバイスがIPアドレスを持てるようになり、より高度なサービスを実現する基盤ができたと言えます。でも、喜んでばかりはいられません。
今はまだ、IPv6に対応した端末を使用したことのない方が多いと思います。端末がIPv6化されていても、それは先端ユーザなどの一部だけであり、例えば学内・社内の多くの端末をIPv6に対応させることは少なかったと思います。ところが、これからは端末の多くがIPv6化されるようになります。組織内のコンピュータがどんどんIPv6化していくのです。
新品のPCを買ってきて電源を入れただけで、ユーザが気付かないうちにICMPv6のパケットが飛び、ステートレスアドレス自動設定のやり取りをはじめ、ネットワークインターフェースにIPv6アドレスが割り振られ、DNSの名前引きではAAAAの名前引きが発生します。
このように、端末PCがこれまでなかったIPv6パケットの送受信を始めるのです。この時、何か問題が発生するかも知れません。特に、ユーザ一人一人が直接扱う端末です。数が多いですし、いろいろな人がいろいろな使い方をするでしょうから、障害が発生したときの対応も大変であろうと思います。
実は、このような端末OSのIPv6化に付随した問題は既に発生しています。もっとも有名な例がキャプティブポータル問題です。詳細は後述しますが、この問題は既にWIDEのv6fix WGで原因が追求されました。優秀な方々が調査した結果、この問題はIPv6の仕様そのものの問題と言うよりは、DNSサーバの実装に最大の原因があったことが判っています。
しかし、一般ユーザから見ると、この問題は「Windows XPのIPv6スタックを有効にしていると発生する問題」にしか見えません。実際、場所によっては「IPv6をアンインストールすれば通信できるようになりますよ」と説明されてしまい、まるでIPv6が原因で障害が出ているように見えてしまうこともあったそうです。
このキャプティブポータル問題はIPv6への適切な移行を阻害する問題の一つです。将来、Internetの健全なアーキテクチャにのっとった成長を目指す上で、このような問題は回避していかなければなりません。この様に、端末OSがIPv6化された場合、特に移行期である現状では、無視できない問題が発生しかねません。ましてや、日本はこれまで、先進的にIPv6を導入してきました。既にIPv6が導入されたネットワークも少なくありません。このような中に新たなIPv6対応の端末OSが流行する場合、新たな問題が発生してもおかしくないでしょう。
今、端末OSがIPv6化することによりどのような問題が考えられるのでしょうか。この起りえる問題について、IPv6 普及高度化推進協議会の移行WG、IPv6端末OS評価SWGにおいて、検討を行っています。このSWGでは、InternetのIPv6化を望む各社の、優秀な技術者様にご参加頂き、日々この問題について精力的に調査して頂いております。
この会議体で調査している、IPv6端末OSが流行した際に発生し得る問題について、以下にいくつか列挙してみました。
具体的におこりえる問題
キャプティブポータル問題
キャプティブポータルとは、ホテルの客室などで採用されているインターネット接続サービスの認証、課金システムです。ユーザがホテルなどのネットワークに接続し、Webブラウザで任意のページにアクセスすると、強制的にサービス提供者のページにリダイレクトされます。そして、そのページで認証や課金処理が行われます。その後は、Webページアクセスをリダイレクトされることなく、ユーザは自由にウェブページにアクセスできるようになるものです。ネットワーク的にはいささかムチャな実装をしていると言えるかも知れませんが、ユーザにとってはなかなか便利で合理的なシステムでしょう。
この環境で、デュアルスタックに対応している端末がキャプティブポータルをうまく利用できないという現象がありました。デュアルスタックに対応したWindows XPのPCがWebアクセスをすると、キャプティブポータルのトップページにジャンプしようとしますが、認証＆課金ページがいつまで経っても表示されず、結果としてネットワークが利用できないという現象です。
この障害は、キャプティブポータル提供者が利用しているDNSサーバと端末OSの両方に問題があったため起きたものでした。具体的には、この問題を発生させるDNSサーバは存在しないリソースレコードに対して，常に特定のA応答を返す実装になっていました。つまりデュアルスタック対応の端末OSが、AAAAレコードのクエリを出しているのに、DNSサーバがAレコードの応答を返しているのです。くわえてデュアルスタック対応OSが、DNSサーバが送ってくる要求していないレコードの情報を受理してしまうということも問題でした。詳細のパケット送受信の様子は下記の通り、v6fixの皆様のご尽力により解析されています（http://v6fix.net/docs/hotel.html.ja）。
さて、ではこのキャプティブポータル、どうすれば使えるようになるのでしょうか？ 特に、Windows VistaのようにIPv6がデフォルトでONとなっているような先進的なOSにとってこの問題は深刻です。これについて、前述したIPv6普及高度化推進協議会の移行SWG IPv6端末OS評価SWGにおいてVistaの評価を行いました。結果として、調査したVista（Build 5600）はこの問題を解決していました。
具体的には、Vista（Build 5600）のDNSリゾルバはWindows XPなどとは違い、InterfaceがRAなどによるIPv6アドレスを持たないときはAAAAレコードの問い合わせをしないという実装になりました（Teredoアドレスは除外しています）。リゾルバでInterfaceの状況を知り、その内容に応じてAAAAの名前引きを抑制するという実装上の手間はかかっているのですが、この対策によりキャプティブポータルの問題をWindows Vistaは見事に回避していました。
マルチプレフィクス時の問題
外部のネットワークに接続することをホーミングと呼びます。ホーミングの一番の例がISPへの接続でしょう。具体的には、ある組織がインターネットに接続するために、ISPへの接続口を持ちます。これをホーミングと呼びます。そして、その接続口の先のネットワーク（つまりインターネット）にあるサービスを利用するため、そのネットワークで通用するIPアドレスの配布を受け、組織内の機器に設定します。
ISPへの接続とはことなるホーミングもあり得ます。例えば、Internetではない、動画配信を行うクローズドなマルチキャスト網のサービスを受けたい場合などです。その場合、このマルチキャスト網にホーミングすると同時に、このマルチキャスト網上のサービスを利用するために、ISPからもらったアドレスとは別の、マルチキャスト網で通用するIPアドレスの配布を受けます。そして、このアドレスを、マルチキャスト網のサービスを受け取るために組織内のコンピュータに付与します。
このように、複数の外部への接続口を持つとことを、マルチホーミングと呼びます。そして、ホーミング先のサービスを利用するためのIPアドレスが配布されます。つまり、組織内のコンピュータにホーミング数に応じた種類のプレフィクスが分配され、1台のPCに異なるプレフィクスの複数のIPアドレスが設定されることになります。これをマルチプレフィクスと呼びます。
このような状態になることはかなり昔から想定されており、実際にWindows XPやその他のOSでも、異なるプレフィクスを持つRAを受けて、自身に複数のIPアドレスが付与できるようになっています。しかしこの場合、アドレス付与だけでなく運用上の問題が発生します。
例えば、前述のInternetとマルチキャストストリーミング専用ネットの二つのアドレスを付与されている場合を考えてみましょう。この時、ユーザがインターネット上にあるWebサーバにTCPのパケットを送出したとします。そのパケットにはソースアドレスとディスティネーションアドレスが書き込まれています。ディスティネーションアドレスは、当然、Internet上の通信したいWebサーバのアドレスです。ではソースアドレスは何が書き込まれるのでしょう？
ソースアドレスは自分のIPアドレスが書き込まれるわけですが、自分には二つのアドレスが割り振られています。ではどちらのアドレスが書き込まれるのでしょうか。たとえば、ソースアドレスに、もしマルチキャストストリーミングを受けるための、インターネットでは通用しないアドレスが書き込まれたらどうなるのでしょう？
そのパケットはインターネット上のWebサーバまでは到達します。そして、Webサーバが応答を返します。応答パケットの宛先は元のパケットのソースアドレスです。ですが、そのアドレスはインターネット上では通用しません。結果としてWebサーバからの応答パケットはルーティング不能に陥ってしまいます。
いやいや、もしかしたら、Webサーバまでパケットが到達しないかも知れません。というのも、インターネット上では無効なソースアドレスが書かれているパケットは経路の途中でカットオフされるかもしれないためです。このようなフィルタをIngress Filterと呼びます。
この問題を解決するためには「各端末が適切なソースアドレスを選ぶ」ということが必要でしょう。この解決を目指しているものの一つが、RFC 3484で提案されているLongest Matchという方策です。Longest Matchは、ディスティネーションアドレスと、自身が持つ複数のIPアドレスを上位ビットから順に比較して、もっとも長く一致したIPアドレスをソースアドレスとして選ぶという方策です。この機能はBSDやWindows XPでも採用されているものです。
確に、これは高い確率でこの様な問題を解決してくれるようになるでしょう。しかしこの方法が、確実にこの問題を回避してくれるわけではありません。このため、RFC3484では、宛先アドレスブロック-ソースアドレス選択テーブルを実装するという方策が提案されています。つまり、宛先アドレスブロックに適したソースアドレスを定義しておくということです。これについても当該SWGで、FreeBSD、Windows XP、Windows Vista（β版）において検証しました。
しかし、このテーブルを各端末のユーザが管理するのは難しいといえるでしょう。このため本件については、今後の運用方策も含めた検討を注視していくべきでしょう。
DNSサーバのクエリ量が増加する問題
今更取り上げるまでもなく、IPv6への対応とは、IPv6で通信できるようになるというだけではありません。IPv4/IPv6のどちらでも通信できるようになるということを目指すのが普通です。ですから、IPv6に対応したホストが通信を行う際には、宛先ホスト名からIPv4アドレスとIPv6アドレスの両方を得ようとすることになります。そして、その両方でサーバへの接続を試みることになるでしょう。名前引きはIPv4とIPv6の二つになる。つまりDNSサーバのへの問い合わせ回数が、2倍になるということです。
実は、IPv6化されていない環境でも、通信を開始する際に発生するDNSクエリは1回だけではありません。Windowsにおいては、システムのプロパティで指定するドメイン名、DHCPから配布されるドメイン名、そして、I/Fのプロパティで指定されるドメイン名がある場合、それらを利用した名前解決ができるかどうかを検証する機能があります。
例えば、ある端末に上記のような三つのドメインが指定されているときに、あるホストの名前引きをしようとすると、その端末は宛先ホストの文字列に順に三つのドメインを付加して、それぞれの文字列による名前引きをトライします。つまり3種のドメインそれぞれについてDNSクエリを発生させます。
加えて、アプリケーションによっては入力されたホスト名に「.com」「.net」などのありがちなgTLDや、場合によっては「.jp」「.co.jp」などを付与して名前引きを試す機能もあります。これによって、DNSのクエリ送出数はさらに増えます。さらに、Webブラウザは、指定されたホスト名を検索文字列と見做して、検索サイトで勝手に検索してユーザに結果を提示する機能もあります。この場合、検索サイトの名前引きも発生します。
以上のように、最近のOSやWebブラウザは、ユーザが意識しないうちに、多数のDNSクエリが創出されるようになっています。この状況でIPv6化されると、全てのクエリがAレコードとAAAAレコードの2回分発生することになり、DNSサーバの負荷はさらに上昇してしまいます。
既にリリースされているWindows XP SP2では、前述の名前引きの対象となる、考えられるドメイン名を全てDNSで解決していました。例えば、www.example.jpのホスト名を引く場合、www.example.jp、www.example.jp.co.jp、www.example.jp.example.jp、www.example.jp.com といったホスト名に対して、AAAAレコードを引いていました。さらにAAAAレコードの名前引きのあとに、今度は上記のホスト名に対してAレコードを引きます。
しかし、Windows Vista RC1（Build 5600）では、この動作は改良されました。上記のような候補となるドメイン名について、最初にAで名前引きを行うように改造されました。そして、Aレコードの名前引きでNXDOMAINが帰ってきたらそのドメインは存在しないものと判断して、AAAAレコードの名前引きをしないという方策をとるようになりました。
これにより、ありもしないドメイン名について、AAAAとAの両方のクエリを出すと言うことは回避されるようになっています。また、古いBINDでは、Aのレコードがあっても、AAAAのクエリに対してはNXDOMAINを返すそうです。これについても、ドメインがあるのなら確実に登録されているであろうAから順番にクエリを出すことによって、存在しているドメインのIPv4名前引きをあきらめてしまうことがないようにしています。
この、Windows Vistaで採用しているクエリの送出手順はBCPといえるでしょう。ただし、今後、古いBINDが駆逐され、さらにAAAAレコードの登録数が増加すれば、このようなAレコードを先に検索する手法よりも、AAAAレコードを先に検索する手法の方が高効率であるといえるようになります。
Windows Vistaは現状を意識した上で、DNSサーバの負荷をできる限り削減するBCPといえる実装でしょう。そして、今後は社会の動向に応じて、このBCPの変化をウォッチし、実装も時代に合わせて変化していくべきと言えると思います。
そのほかにも、まだまだ考えられる問題
そのほかにも、考えるべき事柄はたくさんあります。例えば、Windowsのような高機能なOSでは、6to4やTeredo機能も持っています。これらの機能がアクティベートされるタイミングを知っておいた方が良いでしょう。そうすることで、気付かないうちにInternetからのIPv6パケットが到着するという、危険なことを避けることができます。
また、端末OS自身がIPv6に対応していても、サーバがIPv6に対応していないということが往々にしてあります。この様な場合のIPv6で通信しようとして失敗し、IPv4出通信して成功するという、fallbackはどのように行なわれるのかも考慮すべきでしょう。現状のVistaでは、かなり高度なタイムアウトの判断を行いつつ、IPv4へのfallbackを行っているようです。
そのほかにも、IPv6端末OSに対して、下記のような疑問があるでしょう。
- ICMPの取り扱いはどうなっているか？
- 初期状態でオープンしているIPv6ポートには何があるか？
- DDNS Updateはどうなっているのか？
- DNSディスカバリ手法は結局何が優勢なのか？
- マルチプレフィクス時のデフォルトゲートウェイはどうなるのか？
- IPsecではマルチキャストをどう扱うか？ ND、NAの扱いはどうなるか？
これらの問題に対して、現在、IPv6普及高度化推進協議会 移行WG IPv6端末OS検討SWGで検討・調査を続けており、その調査成果の発表を行うための準備を進めております。
端末のIPv6化によって、IPv6普及マイルストンの一つを通過する
今回とりあげた端末OSのIPv6化は、Internet/IntranetをIPv6に対応させる上で、長い道程における、1個の通過点と言えるでしょう。しかし、端末OSがIPv6化されるということは、IPv6ネットワーク環境を整備する上で非常に大きな一歩であり、大改革であると言えます。
改革に痛みが伴うというのは政治の世界のだけではありません。ネットワークの業界においても同じことは言え、この改革によって、従来にない障害が発生しうると思います。
Windows Vistaのリリースにより、またその他のOSの進歩により、IPv6がいよいよ身近にやってきます。このために我々が乗り越えなければならない壁があるのは確でしょう。ただし、今回確認したWindows Vistaはかなり頑張って壁を乗り越えようとしていたと思います。
IPv6普及高度化推進協議会の 移行WG IPv6端末OS評価 SWGでは、このような技術的課題の調査・検討・検証を行っております。このSWGでは、メンバーとなっている多くの有能な方々のご尽力で、多数の問題を調査しております。今後調査を続けて、皆様に調査成果の報告を行いたいと思っております。
