IPv6 Fix

Author(s): 国武功一、下條敏男、神明達哉、竹内奏吾、長健二朗、山本和彦
Created: 2005/01/10
Modified: 2005/11/18

概要

IPv6 は、その仕様、実装、運用の大部分が健全であるが、少しの欠点により、 ユーザへ悪い印象を与えている可能性がある。たとえば、 あるユーザが試しにIPv6 を使い始めた際に、IPv4 を利用する場合と比べ、 ささいな欠点のために快適さが大幅に劣っているなら、IPv4 へ後戻りしてしまうだろう。

少しの欠点のせいで、このようなことが実際に起っている。 そこで、WIDE プロジェクトでは、 IPv6 の仕様、実装、運用の欠点を修正する活動を始めた。 これを取り扱う分科会の名前は、IPv6 Fix (v6fix) である。

IPv6 Fix は、以下のような成果を出すことを目的とする。


目次


第1章 動機と全体像

1.1 背景

IPv6 Fix を始めるきっかけとなった、ユーザに悪印象を与えている事件を2 つ示す。

1.2 全体像

アプリケーションが通信を開始する際は、以下のような段階を踏む。

名前に対し DNS を索く
終点アドレスが得られる。
コネクションの確立を試みる
始点アドレスと終点アドレスの組み合わせを探す。
データのやり取り
経路 MTU などを調整する。

これらの手続きがスムーズに処理されることが重要である。 また、利用できる IPv6 の終点アドレスと始点アドレスの組合わせが見付からない場合は、速やかに IPv4 へ遷移すべきである。 以下、それぞれの段階で見付かっている欠点について説明する。

1.2.1 名前に対し DNS を索く

IPv4 と IPv6 が両方利用できる場合は、名前に対し A RR と AAAA RR を検索すべきである。

問題のあるリゾルバは、IPv6 が利用できないのに AAAA RR を索く。 (IPv6 が利用できないから AAAA RR を索いても無駄であるし、 IPv6 アドレスを得ることにより、利用できないのに利用しようと試みる間違いをアプリケーションが起す可能性がある。)

DNS サーバ側に問題がある場合もある。たとえば、AAAA RR を問い合わせると、誤った返答をする DNS サーバが存在する。

またたとえば、利用できない 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
mail.example.com.   IN A     192.0.2.1
                    IN AAAA  2001:DB8::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 のネットワークの到達性がない場合の試行順序が以下のようになっているため、あるノードへアクセスする際の遅延は発生しない。

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サーバの不正な挙動については、文献[RFC-AAAA]で詳述している。これらについては、3.2節と3.3節でも述べる。

一方、上で述べたgetaddrinfo()ライブラリに代表されるDNSクライアント(リゾルバ)の挙動を工夫することで、問題を回避あるいは軽減できる可能性もある。これについては3.4節で説明する。

なお、文献[RFC-AAAA]でも述べられているように、一般に「DNSサーバ」と呼ばれているサーバは、その機能によって権威(authoritative)DNSサーバとキャッシュサーバに分類される。本章では、とくに断りのない限り、「DNSサーバ」とは権威DNSサーバを指すものとする。

3.2 不正な挙動をするDNSサーバの事例

本節では、不正な挙動をするDNSサーバについて述べる。詳細は、文献[RFC-AAAA]に記述されている。

あるホストの A RR が存在し、AAAA RR が存在しない場合、AAAA RR の問い合わせに対してDNSサーバは、以下のような応答を返す必要がある。

この応答を受け取ったキャッシュサーバやリゾルバは、スムーズで正しい処理を継続できる。これ以外の応答を返して、問題を引き起こす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") が返ってきた場合、多くのリゾルバはA RRの問い合わせにフォールバックする。 しかし、正しい応答の場合と違い、キャッシュサーバは、 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つの方法を提案する。

以下では、それぞれの方法について詳述し、その実装を紹介する。

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 の問い合わせをだす。同様にそれが成功するか時間切れになった時点で、両方の結果を併せた最終的な応答をアプリケーションに返す。この方法では、問い合わせ先のDNSサーバがAAAA RRの問い合わせを無視している場合、最初の段階で1分程度の待ち時間を要した上、結果的には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秒程度で再送回数が閾値を越えコネクション確立が失敗する。

仕様[RFC-TCP]が書かれた時点ではICMPv6はまだ存在しなかったが、 ICMPv6 Destination Unreachableメッセージのうち、

の2種類がソフトエラーに対応する。

なお、ICMP のソフトエラーは Destination Unreachableメッセージのうち、以下の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年12月)では双方の意見を採り入れる形で、この手法を実装上のテクニックとしてドキュメント化し、その優位性と問題点を中立的な立場で紹介し、実装者の判断に委ねるという方向に進んでいる。このドキュメントは Informational RFCとして発行される予定である。

実装に関しては、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 リーフサイトにおける問題点

実験的なIPv6導入
IPv6を実験的に導入してみたものの、本格運用にいたらない場合。 日常的にはIPv6を利用していないため、問題があっても自分達は気がつかない。 多くの場合、IPv6アドレスがDNSに登録されたままになる。
不適切なトンネル
トンネルはIPv6の導入には欠かせない技術であるが、同様に過った利用も簡単にできてしまう。 なかでも、物理的なトポロジを無視したトンネルによる利用可能帯域の減少や応答時間の増大は、IPv6を使うと通信品質が低下する問題の大きな要因である。 例えば、6bone時代の古いトンネルが残っている場合や、国内間の通信が海外のトンネルブローカーを経由する場合も見られる。 物理トポロジが変わってしまっているのに、トンネル設定はそのままにされがちで、また、トンネルで構成されたネットワークは障害診断が難しいため、結果的にトンネルの利用は品質低下を招きやすい。

5.2 バックボーンにおける問題点

我々の調査では、バックボーンには比較的問題が少ないが、IPv4と比較するとまだまだ改善すべき点があることが確認できた。 また、バックボーンの場合、ボトルネックとなっている部分を改善することで大きな効果が期待できる。

ピアリング不足、パス不足
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 のパケットのタイプとして、次のものが存在する。

上記の 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 などのツールは、最小の HopLimit をパケットに設定して送信するため全く機能しなくなる。
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 インターネットにおい て、ファイアウォールの調査を進めていく。


参考文献


Copyright (C) WIDE Project (2005). All Rights Reserved.