Title: IPv6 Fix Author(s): 国武功一, 下條敏男, 神明達哉, 竹内奏吾, 長健二朗, 山本和彦 Date: 2005/1/24 概要 IPv6 は、その仕様、実装、運用の大部分が健全であるが、少しの欠点により、 ユーザへ悪い印象を与えている可能性がある。たとえば、あるユーザが試し にIPv6 を使い始めた際に、IPv4 を利用する場合と比べ、ささいな欠点のた めに快適さが大幅に劣っているなら、IPv4 へ後戻りしてしまうだろう。 少しの欠点のせいで、このようなことが実際に起っている。そこで、WIDE プ ロジェクトでは、IPv6 の仕様、実装、運用の欠点を修正する活動を始めた。 これを取り扱う分科会の名前は、IPv6 Fix (v6fix) である。 IPv6 Fix は、以下のような成果を出すことを目的とする。 - 仕様に問題がある場合は、仕様を修正する - 実装に問題がある場合、自分達で直せるものは直し、直せないもの はベンダに通知する。また、どの欠点が修正され、どれがまだであ るかという状況を把握できるようにする。 - 運用に問題がある場合は、運用者に通知する。 - 以上を解説した、文章を日本語と英語の両方で書き公開する。 目次 第1章 動機と全体像 山本和彦 第2章 IPv6 の仕様の不備 国武功一 第3章 DNS サーバ とリゾルバ 神明達哉、竹内奏吾 第4章 TCP のコネクション確立 長健二朗 第5章 IPv6インターネットの品質 長健二朗 第6章 ファイアウォール 下條敏男 第1章 動機と全体像 1.1 背景 IPv6 Fix を始めるきっかけとなった、ユーザに悪印象を与えている事件を 2 つ示す。 1) あるユーザがあるホテルに宿泊した。"ipv6 install" を実行した Windows XP をインターネットに繋ごうとしたが、接続できなかった。そ のため、ホテルに問い合わせたところ、「"ipv6 uninstall" して下さい」 と言われた。実際に実行してみると、接続できるようになった。 これは、おそらく AAAA RR (Resource Record) を索くとおかしな返答を 返す DNS サーバの問題であろう(3.2節参照)。 2) ある ISP で BIND 9 をサービスに投入したところ、ユーザから「ブラウ ザでページにアクセスする際の快適さが失われた」という苦情を受けた。 これは、BIND 9 が利用できない IPv6 トランスポートを利用しようと試 みているのが原因である。 1.2 全体像 アプリケーションが通信を開始する際は、以下のような段階を踏む。 1) 名前に対し DNS を索く 終点アドレスが得られる。 2) コネクションの確立を試みる 始点アドレスと終点アドレスの組み合わせを探す。 3) データのやり取り 経路 MTU などを調整する。 これらの手続きがスムーズに処理されることが重要である。また、利用でき るIPv6 の終点アドレスと始点アドレスの組合わせが見付からない場合は、速 やかに IPv4 へ遷移すべきである。 以下、それぞれの段階で見付かっている欠点について説明する。 1.2.1 名前に対し DNS を索く IPv4 と IPv6 が両方利用できる場合は、名前に対し A RR と AAAA RR を検 索すべきである。 問題のあるリゾルバは、IPv6 が利用できないのに AAAA RR を索く。 (IPv6 が利用できないから AAAA RR を索いても無駄であるし、IPv6 アド レスを得ることにより、利用できないのに利用しようと試みる間違いをア プリケーションが起す可能性がある。) DNS サーバ側に問題がある場合もある。たとえば、AAAA RR を問い合わせる と、誤った返答をする DNS サーバが存在する。前述のように、これがホテル の事件の原因だと考えられている(3.2節参照)。 またたとえば、利用できない IPv6 トランスポートで検索を試みる DNS サー バも存在する。前記の BIND 9 がこれにあたる。 1.2.2 コネクションの確立を試みる 次に利用できる終点アドレスと始点アドレスの組を探すべきである。DNS を 索いて終点アドレスのリストが得られている。そのリスト中のある終点アド レスに対し、最適な始点アドレスを選択し、コネクションの確立を試みる。 成功すれば、その時点で組合わせの探索を終了する。失敗すれば、他の終点 アドレスを対象し、同じ動作を繰り返す。 この過程に関し、IPv6 の仕様上の欠点が指摘されている。それは、RFC 2461 の 5.2 節で定められている "onlink assumption" である。規定して ある動作は次の通り。すなわち、デフォルトルートがない場合、終点アドレ スが IPv6 のグローバルアドレスであるなら、その通信相手は同一リンクに 存在すると仮定して、通信を試みる。現実的には、多くの場合通信相手は同 一リンクに存在しないため、TCP がタイムアウトするまで待たされる(2章参 照)。 また、通信相手に運用上の問題がある場合がある。たとえば、あるサーバが メールと web のサービスを提供しているとする。メールは IPv6 に対応済み であるが、web がまだである。そして、以下のように CNAME を使って設定し てしまったとする。 server.example.com. IN A 192.0.2.1 IN AAAA 2001:DB8::1 www.example.com. IN CNAME server.example.com. mail.example.com. IN CNAME server.example.com. サーバへは IPv6 の到達性はある。しかし、web のサービスは IPv6 で提供 されていないため、コネクションを張ろうとすると、TCP の RST が返ってく るまで待たされる。この待ち時間は短いため問題視する必要はないかもしれ ないが、別の深刻な問題も引き起こす。それは、IPv6 → IPv4 トランスレー タの裏からコネクションが張れなくなることである。 この場合、サーバの管理者は、以下のように設定すべきである。 www.example.com. IN A 192.0.2.1 IN AAAA 2001:DB8::1 mail.example.com. IN A 192.0.2.1 1.2.3 データのやり取り コネクションが確立された後、快適な通信となるためには、最適な経路を使 うことと、ICMPv6 が送受信できることが必要である。 IPv6 in IPv4 トンネルが不適切に敷設されていると、他にもっと速い経路が あるにも関わらず、遅い IPv6 in IPv4 トンネルを利用してしまう場合があ る(5章参照)。 また、ICMPv6 を落すような実装のファイアウォールや、落すように設定され たファイアウォールが存在すれば、経路 MTU を調整できないなどの問題が発 生する(6章参照)。 第2章 IPv6 の仕様の不備 IPv6 は、IPv4からのスムーズな移行を踏まえ、慎重に議論が重ねられ、その 仕様が固められていったはずだが、実際の運用にあたり、不具合が発見され た。その代表例が onlink assumption の問題である。 2.1 onlink assumption 概要 RFC 2461 の 5.2 節は、もしデフォルトルートが存在しない場合、IPv6ノー ドは、すべての宛先が、同一のリンクにいると仮定せよと規定している。こ れは、手動で異なるプレフィクスをつけられた2つのノードが、互いに通信す る場合に有用だとされてきた。 2.2 onlink assumptionの問題点 2.1 で挙げた通り、onlink assumption が有用である場合が想定されてはい たが、移行時期においては有害であることが分かってきた。 たとえば、A レコードおよびAAAAレコードが登録されているようなサーバへ アクセスする場合を考える。この場合、IPv6の接続性が存在しているときは 問題ないが、移行時期においては、ノードが IPv6 に対応していても、接続 しているネットワークが IPv6 に対応しておらず、IPv4 での接続性しかない 場合が多々ある。 このような場合、ユーザとしては、あるノードへアクセスする際は、IPv6 で の試行に時間を掛けることなく、IPv4で接続して欲しい。しかし仕様では、 デフォルトルートが存在しない場合は、すべての宛先が同一のリンクに存在 すると仮定せよと定義されている。そのため、IPv6 でのアクセスを試みる。 すると、そのノードは、その宛先に対する Neighbour Discovery が失敗する までの間、IPv4 での接続を試みない。このため、IPv4 にフォールバックす るまでに、数秒の遅延が発生することになる。 2.3 それぞれの実装の状況 2.3.1 WindowsXP SP1 および SP2 onlink assumption が実装されてはいるが、IPv6 のネットワークの到達性が ない場合の試行順序が 1) IPv4 で試行 2) IPv4 で失敗した際には、IPv6 で試行 となっているため、あるノードへアクセスする際の遅延は発生しない。 2.3.1 Linux この問題は、Linux 2.4系および Linux 2.6.9 以前の カーネルでは、 onlink assumption に起因する問題が発生する。この問題の回避方法として は、IPv6 の経路が存在しない状態において、各インターフェース毎に設定さ れている "::/0" な経路を手動で削除することが挙げられる。 2.3.2 BSD 通常の使用においては、問題は発生しない。 2.3.3 MacOS X 対処済であり、問題は発生しない。 2.3.4 Solaris9 onlink assumptionが有効となっており、問題が発生する。 2.4 解決策 すでに IETF ではこの問題点が指摘され、仕様の改定に向けて作業が進めら れており、RFC 2461 の改訂の際に、仕様に反映される予定となっている [ID-NDBIS]。 第3章 DNS サーバとリゾルバ 3.1 問題点 現在、多くのアプリケーションがIPv6に対応しており、その多くは getaddrinfo()ライブラリを利用してDNSの A RR および AAAA RRの問い合わ せを送信する。その結果として得られたアドレスに対し順次コネクション確 立を試みて、成功したアドレスを使って以後の通信を進めるというのが典型 的な動作である。この際、IPv4とIPv6の両方のアドレスが得られている場合 には、先にIPv6アドレスによるコネクション確立を試みる実装が一般的であ る。 これらの動作は、A RR、AAAA RRの問い合わせがいずれも正確に処理され、 接続性のないアドレスへのコネクション確立を試みた場合にはそれがただ ちに失敗して接続性のあるアドレスとのコネクションを迅速に確立できる、 という仮定に依存している。しかし、実運用上においては、仕様に反する DNS サーバ(後述)や、IPv6プロトコル仕様上の不具合(2章参照)、TCPの仕 様および実装上の性質(4章参照)等によって、これらの仮定が成り立たな い場合がある。そのような場合には、接続性のあるアドレスとのコネクショ ンが成立するまでに長い待ち時間を要したり、接続できるはずのアドレス とのコネクション確立に失敗したりといった問題を引き起こす。Webブラ ウジングの例で言えば、ページが表示されるまでに長時間待たされたり、 表示できるはずのページが表示できない、といった症状として現れる。 AAAAの問い合わせに関するDNSサーバの不正な挙動については、文献 [ID-AAAA]で詳述している。これらについては、3.2節と3.3節でも述べる。 一方、上で述べたgetaddrinfo()ライブラリに代表されるDNSクライアント(リ ゾルバ)の挙動を工夫することで、問題を回避あるいは軽減できる可能性もあ る。これについては3.4節で説明する。 なお、文献[ID-AAAA]でも述べられているように、一般に「DNSサーバ」と 呼ばれているサーバは、その機能によって権威(authoritative)DNSサーバ とキャッシュサーバに分類される。本章では、とくに断りのない限り、 「DNSサーバ」とは権威DNSサーバを指すものとする。 3.2 不正な挙動をするDNSサーバの事例 本節では、不正な挙動をするDNSサーバについて述べる。詳細は、文献 [ID-AAAA]に記述されている。 あるホストの A RR が存在し、AAAA RR が存在しない場合、AAAA RR の問い 合わせに対してDNSサーバは、以下のような応答を返す必要がある。 - response code(RCODE) が 0 (つまり no error) - answer section は空 この応答を受け取ったキャッシュサーバやリゾルバは、スムーズで正しい 処理を継続できる。これ以外の応答を返して、問題を引き起こすDNSサー バの事例を以下に述べる。 A) AAAA RR の問い合わせを無視する IPv6をサポートした多くのリゾルバは、最初に AAAA RR を問い合わせ、 解決できない場合 A RR を問い合わせるフォールバックの機能をもって いる。AAAA RR の問い合わせが無視されると、名前解決に多大な時間を 要し、ユーザに影響をおよぼす。 B) RCODE 3("Name Error"、"NXDOMAIN") を返す "Name Error" は、問い合わせたホスト名に関する RR が一つも存在しな いことを意味している。この応答を受け取ったリゾルバは、すぐに名前 解決をあきらめるため、A RR の問い合わせにフォールバックしない。し たがって、本来なら IPv4 の通信が可能である場合でも、通信不能になっ てしまう。 C) "Name Error" 以外の RCODE を返す RCODE 4("Not Implemented")、RCODE 2("Server Failure")、RCODE 1("Format Error") が返ってきた場合、リゾルバは正しい処理をする。 キャッシュサーバは、AAAA RRが存在しなかったことをキャッシュしない ため、後のリゾルバからの問い合わせの度に問い合わせるため、DNSサー バの負荷をあげ、ネットワークの帯域を浪費する。 D) 壊れた応答を返す たとえば、AAAA RRの問い合わせの答えを入れるフィールドに IPv4 アド レスが入った応答が返る場合がある。キャッシュサーバはリゾルバに対 して、そのまま答えを渡すものや、RCODE 2("Server Failure")にして返 すものがある。後者の場合、前項と同様の悪影響がある。 E) Lame Delegation になる A RR の問い合わせには Authoritative 応答を返すが、AAAA RR には Inauthoritative 応答を返す。あるキャッシュサーバは、あるDNSの ゾーンについて、一度 lame と認識したDNSサーバに対してはその後 一定期間問い合わせをしないようになる。また、その期間中は、その ゾーン内の問い合わせに対してリゾルバに無条件にRCODE 2("Server Failure")を返す。この場合は、たとえリゾルバが A RRにフォールバッ クしても名前解決に失敗する。 3.3 不正な挙動をするDNSサーバの調査 前節で述べたように、不正な挙動をするDNSサーバの存在がユーザにまで影響 を与え、IPv6へのスムーズな移行を妨げる原因の一つとなっている。IPv6 Fixでは、このようなDNSサーバをインターネットから排除し、健全なIPv6環 境の構築を目指している。本節では、そのための活動内容について述べる。 不正な挙動をするDNSサーバを削減していくために、以下のような方策をとる。 1. 不正な挙動をするDNSサーバを探し出すツールの作成 2. 調査の実施 3. 利用しているDNSサーバの種類をサイト管理者へインタビュー 4. ベンダへ調査結果を報告し、実装の改善を求める 2004年には、調査ツールを作成し、JPドメインを調査した。なお、JP ドメイ ンの調査は株式会社日本レジストリサービス(JPRS)との共同研究である。 * 調査ツール 調査ツールは perl で作成され、調査のためのパケットをDNSサーバに対 して送信し、返ってきたパケットを解析して、結果を出力する。 調査は、以下の手順を提供されたドメイン名の数分繰り返す。 1. 対象となるドメイン名を決定する example.jp 2. 当該ドメインを管理するDNSサーバの特定 ns.example.jp, ns.wide.ad.jp 3. 調査に用いるホスト名の決定。入力がドメイン名のため、"www" や "ftp" 等、典型的なホスト名をドメイン名に付加し、A RRを問い 合わせて存在するかを確認 www.example.jp の A RR を ns.example.jp へ 4. 3. で調査に用いるホストが特定できた場合、当該ホストの AAAA RRを 2.で見つかった各DNSサーバに問い合わせて挙動をチェッ クし、結果を出力 www.example.jp の AAAA RR を ns.example.jp へ www.example.jp の AAAA RR を ns.wide.ad.jp へ * JPドメインの調査 JPドメインの調査は、JPRSが本調査のために用意したサーバマシンと 2004/11時点でのJPドメインリストを用いて、5日間かけて実施した。 以下にJPドメインの調査結果について述べる(プライバシ等の問題から、 結果の統計情報についてのみ述べる)。 ドメイン DNSサーバ 問題あり 0.04% 0.11% 問題なし 82.16% 84.39% 不明 17.80% 15.50% ドメインの視点とDNS サーバの視点の両方で集計した。上記の例では、 それぞれ example.jp、および ns.example.jp/ns.wide.ad.jp に相当す る。 不明である理由として、サーバが一時的にダウンしている場合や、上記 調査方法 3 にて調査に用いるホスト名を推測しているため、見つからな い場合等が挙げられる。 問題のあるサーバ内の分類: A) AAAA RR の問い合わせを無視する: 4.7% B) RCODE 3("Name Error")を返す: 4.7% C) "Name Error"以外の RCODE を返す: 8.5% D) 壊れた応答を返す: 0.0% E) Lame Delegationになる: 82.1% 今後は、不正な挙動をするDNSサーバの実装を特定するために、サイト管理者 へインタビューし、その結果をベンダへ報告する。また、調査範囲をJPドメ イン以外にも拡げ、その際の調査方法を検討する。 3.4 リゾルバ側での解決案と実装 3.1節で述べたDNSリゾルバの典型的な動作は、すべてのDNSサーバが仕様 に忠実に振る舞い、またIPv6のコネクション確立が失敗した場合にIPv4に 迅速にフォールバックできている限り、本来は問題を引き起こす原因には ならない。しかし、これまでに見てきたように、実際の運用環境において はこれらの仮定が成り立たない場面も多く、それが問題を生んでいるのが 実情である。さらに、こうした問題がIPv6への移行を妨げる原因の一つと もなっている。 本節では、DNSリゾルバ側の動作を工夫することによる対処法について述べる。 ここでは、以下の2つの方法を提案する。 a. AAAA RRの問い合わせをそれが必要な場面に限定する b. AAAA RRの問い合わせの待ち時間をある条件のもとで短縮する 以下では、それぞれの方法について詳述し、その実装を紹介する。 3.4.1 AAAA RRの問い合わせを限定する DNSに関連した問題は、AAAA RRの問い合わせをそれが必要な場面に限定する ことでその相当部分を軽減または回避できる。たとえば、IPv6の接続性をまっ たく持っていない環境においては、IPv6による通信は不要であり、したがっ て一般ユーザにとってAAAA RRの問い合わせも不要である。そのような場合に は、A RR のみを問い合わせ、得られたIPv4アドレスを使って通信することで、 これまでに述べてきた問題をすべて回避できる。 そこで、ここでは「AAAA RRの問い合わせを必要な場面」を「リンクローカル アドレス以外のIPv6アドレスを持っている場面(注)」と定義し、その状況で のみAAAA RRを問い合わせるという変更を提案する。これは、事実上は「グロー バルIPv6アドレスを持っている場面」とほぼ同義である。(注: ここでは、表 現を簡単にするために、ループバックアドレス(::1)はリンクローカルアドレ スの一種であるとみなすことにする) リンクローカル以外のIPv6アドレスを持たないホストにとっては、実際的な アプリケーションを用いたIPv6での通信にはほとんど意味がない。したがっ て、リンクローカルアドレス以外のアドレスの有無による判定は現実的な観 点から有効だといえる。また実際、リンクローカルアドレスのみを持つIPv6 ホストという環境は、IPv6に対応したOSを稼働させている非IPv6ユーザにとっ ての典型的な設定である。これらのユーザに対して、AAAA RRの問い合わせに 起因した問題点の回避策を提供することで、IPv6に対して短絡的な悪印象を 与えずに済み、間接的にIPv6への移行を円滑にすることに寄与できるであろ う。 この方式は、getaddrinfo()ライブラリに対しては、第3引数のhints構造体に へ AF_UNSPEC ファミリが指定された場合に、リンクローカルアドレス以外の IPv6アドレスがなければDNSのAAAA RR問い合わせを出さないようにすること で実現できる。 なお、RFC3493(IPv6のAPI仕様)の6章によれば、hints構造体における AF_UNSPECの指定は、呼び出し側においてすべてのファミリに対応しているこ とを示しているのみであり、ライブラリ側での具体的な挙動は特定されてい ない。したがって、条件に応じてAAAA RRの問い合わせを省略したとしても仕 様には反しない。 ところで、提案方式は、getaddrinfo()ライブラリの結果をその後の通信先の アドレスとして利用するということを前提としている。仮にたとえば、この ライブラリをDNSの運用・診断ツールの一部として利用し、AF_UNSPEC ファミ リを指定した場合にA RRとAAAA RRの両方の問い合わせがなされることが期待 されていたとすると、その仮定には反する挙動となる。しかし、上述のよう に、APIの仕様上は、アプリケーション側で問い合わせ結果にこのような仮定 をおくことはできないはずである。すなわち、両方の問い合わせが必要なら AF_INETとAF_INET6を指定して二度getaddrinfo()を呼び出すといった処理が、 API仕様上は正しいアプリケーション実装であり、問題のある場合に修正すべ き対象は本来はアプリケーション側である。また、こうした運用ツールでは getaddrinfo()よりも低レベルのインタフェースを用いることが普通であり、 上述の変更が実際に問題になる場面は少ないと考えられる。 3.4.2. AAAA RRの問い合わせ待ち時間を短縮する IPv6の接続性を持った環境においては、AAAA RRの問い合わせは必須であり、 3.4.1節で述べた方法は適用できない。ここでは、そのような場合の中で、と くにAAAAの問い合わせを無視するDNS サーバに対応するリゾルバ側の対応方 法を提案する。 一般に広く使われているISC BIND[BIND]に由来したリゾルバの実装では、まずAAAA RRの問い合わせを出す。それが成功するか時間切れになるかした時点でA RR の問い合わせを出し、同様に成功するか時間切れになるかした時点で、AAAA RRの問い合わせ結果と併せた最終的な応答をアプリケーションに返す。この 方法では、問い合わせ先のDNSサーバがAAAA RRの問い合わせを無視している 場合、最初の段階で1分程度の待ち時間を要した上、結果的にはA RRの問い合 わせのみが有効だったということになる。 これに対し、提案方式では、以下のようにして不要な待ち時間を軽減する: - まずA RRの問い合わせを出す - 次にAAAA RRの問い合わせを出す。ここで、A RRの問い合わせが成功し ていた場合には、待ち時間を短縮し、問い合わせが無視されていても 不必要に長く待たないようにする この方式によれば、「A RRには正しく応答するがAAAA RRは無視する」DNSサー バへの問い合わせについて、最初の段階では正しい応答が迅速に得られる。 したがって、AAAA RRの問い合わせについては短縮した待ち時間が適用され、 AAAA RRの問い合わせが無視されている期間中、不必要に待たずに済むように なる。 3.4.3. 提案方式の実装 前の2つの小節で述べた提案方式を、KAMEプロジェクトから提供しているスナッ プショットのFreeBSD用getaddrinfo()ライブラリとして実装した。この実装 は2004年11月29日版以降のスナップショットで利用できる。 この実装では、3.4.2節における短縮待ち時間を max(1秒, T * 2) (ただしT はA RRの問い合わせが成功した場合に、それに要した時間)としている。これ により、問い合わせ先のDNSサーバが遠隔地にあるなどの理由でもともと遅延 が大きい場合にも妥当な長さの待ち時間を設定できると考えられる。すなわ ち、「A RRにもAAAA RRにも正しく応答するが、応答までの遅延が大きい」 DNSサーバへの問い合わせの場合にも、A RRとAAAA RRの両方の応答が正しく 得られると期待できる。 なお、RFC3484で規定されている、「アドレス選択の既定順序」を実現するた めには、一般的なgetaddrinfo()ライブラリはIPv6アドレスを先に、IPv4 ア ドレスを後に返す必要がある。3.4.2節で述べた方式では、DNSの問い合わせ についてはA RRを先行させているが、実際の実装においては、その後の処理 でアドレスを並べ替え、RFC3484で規定された順序となることを保証している。 第4章 TCPのコネクション確立 4.1 問題点 TCPのコネクション確立においても、IPv4へのフォールバックに時間がかかる 場合がある。第3章で述べたように、通常のIPv6対応アプリケーションでは、 通信相手のアドレスをgetaddrinfo()ライブラリにより取得し、複数のアドレ スが得られた場合はそれぞれに対して順次コネクションの確立を試みる。多 くの実装では、相手がIPv4とIPv6のデュアルスタックであれば、IPv6アドレ スが優先されるため、IPv6での接続を先に試み、失敗した場合にIPv4での接 続にフォールバックする。相手に複数のIPv6アドレスがあれば、そのそれぞ れに対しても接続を試みることになる。 通信相手からリセットが返る、あるいは、ICMPv6ハードエラーが返る場合は、 たたちにコネクションの確立が失敗し、RTT約1回分の時間で迅速に次のアド レスにフォールバックできる。しかし、コネクションの確立が、再送回数が 閾値を越えて、または、タイムアウトで失敗するような場合にはフォールバッ クに長い時間を要することになる。 TCPがコネクション確立の失敗に時間がかかるケースは、主に2通りに分類で きる。 (1) 再送回数が閾値を越える場合 これは、ICMPv6ソフトエラーが返ってくる場合に起こる。TCPの仕様[RFC-TCP] では、一部のICMPエラーをソフトエラーとし、ネットワークの一時的な 障害の可能性があるため、接続を中断してはいけないことにしている。 そのため、TCPはICMPv6によるエラーが返ってきているにも関わらずこれ を無視して再送を続ける。4.4BSD由来のTCPコードでは、コネクション確 立前の再送回数に制限を持つため、通常10秒程度で再送回数が閾値を越 えコネクション確立が失敗する。 なお、ソフトエラーは ICMP Destination Unreachableメッセージのうち、 コード0 (network unreachable)、 コード1 (host unreachable)、 コード5 (source route failed) の3種類となっている。 (2) タイムアウトする場合 こちらは、コネクション確立の試みに全く応答がない場合に起こる。 4.4BSD由来のTCPコードでは、コネクション確立用にタイマーを持ち、デ フォルトでは75秒経ってもコネクションが確立できないとタイムアウト する。 問題の本質は、複数のアドレスに対してコネクション確立を試みて、問題が あれば透過的にフォールバックする手法の実現の難しさである。最近では、 IPv4だけの世界でも、ひとつのDNSホスト名が複数のミラーサーバーのアドレ スにマップされるような使い方が見受けられ、同様の問題を含んでいる。し かしながら、現状のデュアルスタック・インターネットでは、DNSにIPv6アド レスを登録しているにも関わらず、IPv6で到達できないホストが少なからず 存在する。そのため、ユーザにはIPv6を利用可能にすると接続に時間がかか るかのような印象を与えてしまう。 本来は、DNSに登録されたすべてのアドレスは到達可能であるべきであり、到 達できないホストやネットワークを修正するのが筋である。そちらに関して は第5章で述べる。しかし、通信相手側の問題を解決することは難しく、現実 的には、TCPのフォールバックの高速化に関して、何らかの対策を取って問題 を軽減することが求められる。 4.2 対策 TCPのフォールバックの高速化は、接続性問題の対処療法にすぎない。ここで は、IPv6普及の障害を減らすという観点から、IPv6からIPv4にフォールバッ クする場合を中心に対策を述べる。 (1) 再送回数が閾値を越える場合 ICMPソフトエラーが返る場合には、コネクション確立時に限りこれを ハードエラーと同様にみなして迅速にフォールバックする方法が提案 されている[ID-SOFTERROR]。ソフトエラーに対する対応が仕様に定め られた当時は、通常のホストはひとつのIPアドレスしか持たなかった ため、ネットワークやホストに到達できないというICMPエラーが返っ て来ても、接続性の回復を期待して再送を繰り返すしか手段がなかっ た。しかし、IPv4とIPv6の両方のアドレスを持つことが普通になった 現在では、ICMPソフトエラーによって接続性の問題が明らかになれば 即時に次のアドレスにフォールバックすることもできる。 難しいのは、再送により接続性が回復する可能性とフォールバックによ り迅速に接続性が得られる可能性のバランスを見つけることである。こ れは通信環境で大きく異なる。IPv6接続性に問題の多いデュアルスタッ ク環境では、ICMPソフトエラーで即座にフォールバックするのは有効で ある。一方、物理層において非常に不安定な通信環境では、再送の方が 有効であろう。4.4BSD 由来のTCPでも、ICMPソフトエラーが返ると、コ ネクション確立前に限って、通常より早期に終了するという中間的な方 法を取っている。通信環境が大きく変わった現在では、これよりは積極 的ななフォールバックが妥当だと思われるが、不安定な通信環境でも動 作するTCPの利点を損なわないよう注意することも必要である。また、今 後IPv6接続性をめぐる状況が変化しても柔軟に対応できるように考慮し ておく必要もあるだろう。 (2) タイムアウトする場合 コネクション確立のSYNパケットにまったく応答がなくタイムアウトする 場合にはあまり有効な対策はない。この場合は、タイムアウト以外のイ ベントがなく、かつ、タイムアウトは極端に短くすることはできない。 多少タイムアウトを短くしても、あまり効果は期待できない。 他の方法として、複数のアドレスに並列に接続を試みることも考えられ るが、この方法はリソースの無駄使いが多く、また、既存のコードへの 変更も大きいためあまり現実的ではないと思われる。 また、到達できないアドレス情報をキャッシュして、それ以降利用しな いようにすることも考えられる。最初のコネクション確立は時間がかか るが、2度目以降のアクセスには効果がある。しかし、この方法も必要な 変更の大きさの割りに、その効果に疑問がある。 このように、ネットワークから何も情報が得られずタイムアウトする場 合には、TCP側ではあまり細工のしようがないため、ネットワークの問題 を解決することが必要になる。 4.3 標準化および実装状況 ICMPソフトエラーを、コネクション確立前に限り、ハードエラーと同様に扱 う提案がされており [ID-SOFTERROR]、IETF TCP Maintenance and Minor Extensions (tcpm) ワーキンググループで議論されている。IPv6コミュニティには、 IPv6普及のために必要だという意見が多いが、TCPコミュニティには既存の TCPの挙動を変えることに慎重な意見があり、本原稿の執筆時点(2005年1月) では合意は形成されていない。 議論となっているのは、まず、ICMPソフトエラーに対する挙動を、システム グローバルな変数とするべきか、ソケットオプション等でアプリケーション 毎に制御できるようにするべきかという点である。前者は既存のアプリケー ションを変更せずに導入できる。それに対し、後者は必要なアプリケーショ ンを変更するべきだという立場である。そして、デフォルトの挙動がどうあ るべきか、また、それらを仕様で定めるべきか実装にまかせるべきかという 議論もある。これらの議論は、IPv6の普及促進という立場と、TCPは本来どう あるべきかという立場で大きな隔たりがあり、収束には時間がかかりそうで ある。 実装に関しては、Linuxでは1996年のカーネルバージョン2.0.0より、ICMPエ ラーでただちにフォールバックするようになっている。KAMEによる実装でも 2004年12月からこの方式を採用している。 4.4 セキュリティへの考慮 ICMPソフトエラーでフォールバックを速くしてもDoS攻撃の危険性は従来と変 わらない。現在でも、ICMPハードエラーが返ればコネクション確立に失敗す るので、これと同じ挙動になるだけで危険性が拡大することはない。 第5章 IPv6インターネットの品質 本格的なIPv6への移行を実現するには、IPv6インターネットがIPv4インター ネットと同等以上の品質を持つことが必要条件である。IPv6インターネッ トがIPv4より劣っていれば、普通のユーザはコストと労力を使って移行す るはずがない。しかし現実的に、IPv6インターネットの品質はまだIPv4に 遠く及ばない。 ユーザはIPv6を使っていて、ごく一部の問題のあるサイトに出会うとIPv6自 体の問題だと考えてしまう。そのことがIPv6普及の大きなハードルになって きている。問題の原因としては、実験的な運用、ピアリング不足、不適切な トンネルなど、さまざまな要因がある。 そして、IPv6普及の抱えるジレンマとして、普及促進のために手軽なIPv6接 続を提供することが、実験的な利用を増やして、結果的にIPv6インターネッ トの品質を低下させることも挙げられる。さらに、IPv6の透過的な設計が問 題解決を難しくしている一因になっている。IPv6はIPv4と共存し、もしIPv6 での通信に問題があれば自動的にIPv4にフォールバックするようになってい る。そのため、利用者が気がつかないうちにIPv4 で通信できてしまうので、 IPv6ネットワークの問題はしばしば見過ごされることになる。 我々は日常的にIPv6を使っていて、問題があるのは一部であり、ほとんどの サイトには問題がないことを直観的に知っている。もし、一部のサイトが問 題を起こしているだけなら、それらを直せばIPv6インターネットの品質を大 きく全体的に改善できる。 我々はこのように考えて、IPv6インターネットの品質の現状を把握するため、 2004年の1月からIPv6インターネットとIPv4インターネットのの品質比較調査 を行なっている。調査の詳細については [DUALSTACK] を参照されたい。 5.1 問題点 リーフサイトにおける問題点。 (1) 実験的なIPv6導入 IPv6を実験的に導入してみたものの、本格運用にいたらない場合。日常 的にはIPv6を利用していないため、問題があっても自分達は気がつかな い。多くの場合、IPv6アドレスがDNSに登録されたままになる。 (2) 不適切なトンネル トンネルはIPv6の導入には欠かせない技術であるが、同様に過った利用 も簡単にできてしまう。なかでも、物理的なトポロジを無視したトンネ ルによる利用可能帯域の減少や応答時間の増大は、IPv6を使うと通信品 質が低下する問題の大きな要因である。例えば、6bone時代の古いトンネ ルが残っている場合や、国内間の通信が海外のトンネルブローカーを経 由する場合も見られる。物理トポロジが変わってしまっているのに、ト ンネル設定はそのままにされがちで、また、トンネルで構成されたネッ トワークは障害診断が難しいため、結果的にトンネルの利用は品質低下 を招きやすい。 我々の調査では、バックボーンには比較的問題が少ないが、IPv4と比較する とまだまだ改善すべき点があることが確認できた。また、バックボーンの場 合、ボトルネックとなっている部分を改善することで大きな効果が期待でき る。 (3) ピアリング不足、パス不足 IPv6対応のIXはまだ数が少なく、ピアリングも十分になされていない。 また、構成機器の制約等でIPv6で利用できるパスも限られているため、 IPv6での通信はIPv4に比べて迂回する場合が多い。 品質問題に関しては、問題の把握が容易ではないため、ネットワーク運用者 も問題に気づいていないことが多い。我々の調査結果をわかりやすく運用者 にフィードバックして、IPv6ネットワークの品質改善に繋げていくことが課 題である。 第6章 ファイアウォール 現在の IPv4 インターネットにおいて、一般的に組織のネットワークをイン ターネットに接続する際、組織内部のネットワークを組織外の攻撃から防御 するために、組織内部ネットワークとインターネットの境界にファイアウォー ルと呼ばれる装置を設置する。一般的に組織内部からインターネットへの通 信は可能であるが、ファイアウォールによる制限のためインターネットから 組織内部へは特定の通信のみが通過できる。このため、インターネットに公 開するサーバは、インターネットからアクセス可能なネットワークに配置す る。 セキュリティに関して慎重な組織では、インターネット上で公開しているサー バに対してもファイアウォールを配置している。さらに、公開サーバを ICMPv4 を用いた DoS 攻撃から防御することを想定して ICMPv4 パケットを 通過させないよう設定している場合がある。このため、IPv6によるインター ネット接続においても同様に DoS 攻撃を想定して、ICMPv6 パケットを遮断 するよう設定している可能性がある。また製品や実装によっては、デフォル トの設定が ICMPv6 パケットを通過させないようになっている可能性がある。 IPv6 ネットワークにおいてICMPv6 を遮断すると、IPv6 の通信制御上に問題 が発生する可能性が存在する。 また、通常よりも大きい DNS パケットを通過しないファイアウォールが 存在する。この種のDNS パケット典型例は EDNS0[RFC-EDNS0] である。こ れらのファイアウォールの問題から、IPv6 の通信制御が阻害され、IPv6 で適切に通信ができなくなっている。 6.1 ファイアウォールに起因する問題点 遮断されると問題となる ICMPv6 のパケットのタイプとして、次のものが 存在する。 - Destination Unreachable (Type = 1) - Packet Too Big (Type = 2) - Time Exceeded (Type = 3) 上記の ICMPv6 のタイプのパケットが遮断されると、それぞれ以下の現象 が発生して通信上の問題になる。 - Destination Unreachable 実際の通信の終点アドレスのまで到達したのか、通常のパケットが途 中で破棄されたのか、経路が無いのか、もしくは通信相手のトランス ポートのポートが無いのかが分からない。このため、TCPで通信する場 合に、前記の原因でパケットが不到達となっても、早期に対処できず、 送信元のアプリケーションは TCP のタイムアウトなどを待ってから処 理することになる(4.1節参照)。 - Packet Too Big 送信パケットが経路 MTU より大きい場合、この Packet Too Big の ICMPv6パケットが返ってこないと、経路 MTU を検知できない。そのた め、IPv6では途中の通信路上でフラグメント処理を実施しないので最 終的に通信できない。 - Time Exceeded 送信するパケットの Hop Limit よりも通信相手までのホップ数が多い 場合に、Time Exceeded の ICMPv6 パケットが返ってこないと、送信 パケットのHop Limit を調整する手段が失われて通信ができない場合 が存在する。例えば、traceroute などのツールは、最小の Hop Limit をパケットに設定して送信するため全く機能しなくなる。 - EDNS0 ICMPv6 パケットではないが、EDNS0 などの通常の DNS パケットよりも サイズの大きなパケットを通過させない場合に、IPv6 におけるDNS によ り名前が解決できないという問題も存在する。これは、BIND 9.3 実装を 用いた (FreeBSD-R5.3 などの)OS であれば、"edns-udp-size" オプショ ンを設定することで回避可能ではある。しかし、これは対処療法であっ て、本質的な解決のためにはファイアウォールを修正しなければならな い。 6.2 ファイアウォール検査ツール 前節の問題点を調査するために、ファイアウォールの ICMPv6 とサイズの長 い DNS パケットの遮断問題を検査するツールを作成し、実際のIPv6インター ネット上で動作させて、問題がどのネットワークにおいて存在するのかを調 査することになった。また、製品個別の問題点の調査のために、作成したファ イアウォール検査ツールを公開することとなった。 本検査ツールは、ファイアウォールの ICMPv6 パケット通過の検査を目的 として、前節で述べた ICMPv6 パケットが返るようなパケットを意図的に 生成し、ファイアウォールを通過するように送信し、通信相手もしくはファ イアウォールの ICMPv6 パケット応答を検査する。本ツールの仕様は、次 の通りである。 - Destination Unreachable このタイプの ICMPv6 パケットには、port unreachable と destination unreachable という 2 つのサブタイプが存在し、これら を別々の手法で検査する。サブタイプの port unreachable を検査す る場合には、ファイアウォールの先に存在するホストにて使用してい ないポート番号をパケットに設定して送信する。その後、ファイア ウォールか、その先にあるホストからの ICMPv6 パケット応答を検査 する。また、サブタイプのdestination unreachable を検査する場合 には、ファイアウォールの先の存在するアドレスプレフィックスで実 際には存在しないアドレスを送信するパケットの終点アドレスに設定 して送信する。その後、ファイアウォールもしくは、その先にあるホ ストからの ICMPv6 パケット応答を検査する。 - Packet Too Big 検査対象のファイアウォールを通過する通信路上の経路 MTU よりサイズ の大きいパケットを、ファイアウォールの先にあるホスト宛に送信する。 その後、ファイアウォールもしくは、その先にあるホストからの ICMPv6 パケット応答を検査する。 - Time Exceeded 検査対象のファイアウォールの先にあるホストまでのホップ数より小さ いHop Limit を送信するパケットに設定して送信する。その後、ファイ アウォールもしくは、その先にあるホストからの ICMPv6 パケット応答 を検査する。 - EDNS0 模擬的な DNS Query をファイアウォールの先にある DNS サーバに送信 し、DNS サーバもしくは、ファイアウォールからの応答を検査する。 6.3 今後の活動 現在、ファイアウォール検査ツールを作成中であり、完成後に一般に公開し たい考えている。また、本検査ツールは FreeBSD 上に実装しているが、一般 の方に広く使用していただくために Windows へ移植したいと考えている。さ らに、ファイアウォールベンダの方々に使用して頂いて、その結果を報告し ていただき、結果をまとめて公開していきたいと考えている。また、公開し て使用してもらうだけではなく、自身で独自に IPv6 インターネットにおい て、ファイアウォールの調査を進めていく。 参考文献 [ID-NDBIS] T. Narten at el, "Neighbor Discovery for IP version 6 (IPv6)", Internet-Draft, draft-ietf-ipv6-2461bis-01.txt, October 2004. [ID-AAAA] Y. Morishita and T. Jinmei, "Common Misbehavior against DNS Queries for IPv6 Addresses", Internet-Draft, draft-ietf-dnsop-misbehavior-against-aaaa-02.txt, October 2004. [BIND] ISC BIND web page. http://www.isc.org/ [RFC-TCP] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [ID-SOFTERROR] F. Gont., "TCP's Reaction to Soft Errors", Internet-Draft, draft-gont-tcpm-tcp-soft-errors-01.txt, April 2005. [DUALSTACK] Kenjiro Cho, Matthew Luckie and Bradley Huffaker, "Identifying IPv6 Network Problems in the Dual-Stack World", SIGCOMM'04 Network Troubleshooting Workshop, Portland, Oregon, September 2004. [RFC-EDNS0] P. Vixie, "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. Copyright Notice Copyright (C) WIDE Project (2005). All Rights Reserved.