WIDEプロジェクトと最新インターネット技術研究動向:4.IPv6-Fix: IPv6普及期に向けた取り組み

全文

(1)プロジェクトと最新インターネット技術研究動向. 特集. IPv6-Fix : IPv6 普及期に向けた取り組み. 4. 吉藤英明. 慶應義塾大学大学院政策・メディア研究科 [email protected]. 廣海緑里. （株）インテック・ネットコア [email protected]. 次世代インターネットプロトコルとして検討されてきたIPv6（Internet Protocol Version 6）の技術開発はほぼ終了し，実用フェーズに入りつつある．すでに，種々のアプリケーションがIPv6に対応し，多くのOSがIPv6スタックを搭載して出荷するなど，エンドユーザへの潜在的普及は着実に進んでいる．本格的な普及を真近に控え，誰もが使えるための機能検証が必要な時期にあるが，これまで異常系の検討は十分とはいえなかった．本稿では，WIDEプロジェクトで行っている，IPv6移行の過渡期において問題となり得る事例を中心とした，異常系の分析と対策の検討について紹介・解説する．. いと考えられている．. 普及期を迎えるIPv6. ちょっとした契機によって IPv6 が爆発的に普及することは，次世代を俯瞰したときに避けがたく，現在は，. 次世代インターネットプロトコルとして IETF（Internet. 技術レベルや利用目的を問わずに，誰もが使えるための. Engineering Task Force）において 1990 年頃から検討が. 機能検証が必要な時期にきている．. されてきた IPv6（Internet Protocol Version 6）は実験的. 新しい技術の採用には，その技術そのものの開発とと. な実装・運用を経て，実用フェーズに入ろうとしてい. もに，旧技術との共存と，新技術への移行の問題がある．. る．現在では，Web ブラウザやメールクライアントな. この面で IPv6 技術開発を考察すると，技術開発はほぼ. どのアプリケーションの IPv6 対応も進み，各種 BSD HP-UX. ☆2. , 各種 Linux. ☆3. , MacOS. ☆4. , Solaris. ☆5. ☆1. , Windows. ,. 終了し，通常の使用（正常系）には問題ないレベルにな. ☆6. っているが，エラーケース（異常系）の検討はいまだ十. など，（必ずしも既定で有効にされていないとしても）. 分とはいえない．. 多くの OS が IPv6 スタックを搭載して出荷するようにな. WIDE プロジェクトでは，2004 年 9 月から，IPv6 移. った．エンドユーザへの潜在的普及は着実に進んでいる．現在 IPv4 インターネットが問題なく稼働している状況を見て IPv6 への移行の必然性を疑問視する声もある．とはいえ，よく言われていることだが，IPv4 に比べて豊富なアドレススペースや，プラグアンドプレイやセキュリティなど，プロトコルとして標準機能となっている機能が増えたことで，これまで以上に安全かつ安心して使えるようになるなど，主に運用面で IPv6 化の効果は高. ☆1 ☆2 ☆3. ☆4 ☆5. ☆6. BSD は Berkeley Software Design, Inc. の登録商標． HP-UX は，米国 Hewlett-Packard 社の登録商標． Linux は，Linus Torvalds の米国およびその他の国における登録商標あるいは商標． MacOS は，米国 Apple Computer, Inc. の登録商標． Solaris は，米国およびその他の国における米国 Sun Microsystems, Inc. の登録商標． Windows は，米国 Microsoft Corporation の米国およびその他の国における登録商標．. IPSJ Magazine Vol.46 No.8 Aug. 2005. 887.

(2) プロジェクトと最新インターネット技術研究動向. 特集. 行の過渡期における問題点を具体的に調査・分析し，解. よらずに利用できることが求められる．これには，同. 決することを目的として，IPv6-Fix と呼ばれる活動（以下，. 一の名前に複数のアドレスを結び付けることのできる. IPv6-Fix）を行っている．. 仕組みが利用され，DNS では，同一名に IPv4 アドレス. IPv6-Fix では，IPv6 に関係すると思われる種々の具体. を示す A RR（Resource Record）と，IPv6 アドレスを示. 的問題事例を収集し，分析している．IPv6 と IPv4 の共. す AAAA RR が記述されることになる．IPv4 と IPv6 の両. 存期における利用シナリオで起こり得る問題に関して. 方に対応するアプリケーションでは，典型的には，（1）. は，関係各機関等と協力の上，その解決を図るととも. において目的の名前に結び付けられた複数のアドレスを. に，移行を円滑に促進するために必要な対策も検討して. すべて取得した上で，（2）において可能な接続を試行. いる．さらに，各種カンファレンス等を通じて，啓蒙活. することにより，利用者に利用ネットワークの種別や状. 動も行っている．. 態を意識させることなく動作可能となる．. IPv6-Fix の全活動については，公開文書および Web コ. この典型的な動作は，インターネットの構成要素が正. ンテンツを参照されたい．本稿では，IPv6-Fix の成果を. しく動作している限りにおいてうまく機能する．しかし，. 報告する公開文書. 1）. をもとに，典型的な利用シナリオ. そうでない場合がいくつかあり，中でも特に重要な手順. を示し，いくつかの問題に関して IPv6-Fix での解析，対. （1）∼（3）の段階で知られている問題を列挙する．. 策などの活動について紹介する．. （1）名前に対するアドレスの検索目的の名前に対応するアドレスを取得する段階で，. IPv6移行期の典型的利用シナリオと問題点. AAAA RR の問合せに対して不適切な動作をする DNS サーバがあり，目的の名前に対応するアドレスを適切に取. IPv4 から IPv6 への移行は短期間で完了するものではなく，相当の期間，両者が共存することになる．その過. 得できないことや，円滑な動作が妨げられることがある．（2）コネクションの確立. 程は円滑でなければならず，一般の利用者がその違い. 得られたアドレス群それぞれに対して，順次接続とコ. をことさら認識する必要はない．そのため，アプリケー. ネクションの確立を試みる．この段階において，On-link. ションは IPv4 と IPv6 の両方に対応することが求められ，. Assumption 問題や TCP の対エラー反応問題（詳しくは. また，それらが透過的に利用されることが重要である．. 後述）により，円満な動作が妨げられることがある．. 特に，TCP を用いるアプリケーションは利用が多く，. （3）データの送受信. 重要である．ここでは，その移行のシナリオと問題点に. 実際のデータ送受信において快適な通信を行うために. ついて説明する．. は，最適な経路と適切な MTU（Maximum Transfer Unit）を使うことが必要である．また，実際のネットワーク. 典型的 TCP アプリケーションの通信モデル. 設計に合致しないトンネルは大きな遅延などの原因と. 典型的な TCP アプリケーションの利用では，DNS. なることがある．また制御メッセージ（ICMP（Internet. （Domain Name System）に登録された名前を用いて，目. Control Message Protocol）や ICMPv6（ICMP for IPv6））. 的の通信相手方に対する通信を行う．. を遮断するようなファイアウォールにより，適切な経路. 以下に，典型的な通信モデルを示す．. MTU 調整が妨げられ，大きなデータの送受信時に，通信が途絶することがある．. （1）名前に対するアドレスの検索. 次に，それぞれの問題に関して，詳しく述べる．. （2）コネクションの確立（3）データの送受信（4）コネクションの切断. 名前に対するアドレスの検索における問題前述のように，IPv4 と IPv6 の共存期においては，同一の名前に複数のアドレスを結び付けることのできる仕. 円滑な通信のためには，これらの過程のうち，特に実. 組みが利用される．典型的には，この段階において，ア. 際に通信を開始するための（1）および（2）を迅速に. プリケーションは目的の名前に結び付けられた複数のア. 完了することが重要である．また，コネクションの確立. ドレスをすべて取得する．この仕組み自体は IPv6 の登. の結果として（3）で実際に利用される経路は，利用に. 場による新しいものというわけではない．. 適しているものでなければならない．. 一般に，要求された名前と RR に対応するものがない. IPv4 と IPv6 の共存期において，一般に，アプリケー. 場合，正常終了（応答コード（Response Code）0）でかつ. ションは，IPv4 や IPv6 の接続性の有無といった環境に. 回答部（Answer Section）が空であるような応答をするよ. 888. 46巻8号情報処理 2005年8月.

(3) IPv6-Fix : IPv6 普及期に向けた取り組み. ICMP Type 3 （Destination Unreachable）. ICMPv6 Type 1 (Destination Unreachable). ハードエラー. Code 2 (Protocol Unreachable) Code 3 (Port Unreachable) Code 4 (Fragmentation Needed and DF Set)*. Code 1 (Communication with Destination Administratively Prohibited) Code 4 (Port Unreachable). ソフトエラー. Code 0 (Net Unreachable) Code 1 (Host Unreachable) Code 5 (Source Route Failed). Code 9 (No Route to Destination) Code 3 (Address Unreachable). *：Path MTU Discovery未対応の場合表-1 ICMP/ICMPv6のエラー分類. うに定められている．これにより，DNS クライアントは直. クライアントは，IPv4 アドレスの解決にも失敗する．. ちに別の RR の要求などといった処理に移行できる．. A RR を返す. しかし，一部の DNS サーバは誤った反応をすること. AAAA RR の要求に対して，たとえば，必ず特定の A. が明らかになっている．このような DNS サーバを利. RR を返す DNS サーバがある．通常，要求に適合しない. 用すると，名前解決に失敗したり，時間がかかったり. 応答は利用されないが，一部の DNS クライアントでは. し，結果的に，たとえば，IPv6 対応前は表示できていた. これを利用してしまい，目的のホストに正しく接続でき. Web ページが表示できなかったり，表示されるまでに. なくなってしまう．. 2）. 長時間待たされたり，といった症状が発生する．以下に，これまでに明らかになっている重篤な例を示す．. On-link Assumption 問題. AAAA RR の問合せを無視する. IPv6 の近隣探索仕様は，ノードにデフォルト経路がな. 多くの DNS クライアント実装は最初に AAAA RR を要. い場合，宛先は同一リンクにあるものと見なす（On-link. 求し，その回答を待って，A RR を要求する．このため，. Assumption），としている．これは，ルータなしの環境. 要求が無視されると，タイムアウトまで多大な時間を要. において異なるプレフィクスをつけられたノード同士が. することになる．. 互いに通信する場合に有効であると考えられているから. 応答コード 3（名前エラー（Name Error））を返す. である．しかし，この規定は，特に，移行期においては. 名前エラーとは，要求された名前に関して，要求され. 有害であることが次第に明らかとなってきた．. たもの以外を含め，RR がまったくないことを意味する．. これは，IPv6 対応ノードが IPv4 への接続性のない環. たとえば，IPv6 アドレスの登録はないが，IPv4 アドレス. 境から IPv4 および IPv6 の両方が DNS に登録されている. が登録されている場合に，この応答をすることは誤りで. サーバへアクセスする場合に発生する．この場合，IPv6. ある．この応答をキャッシュしてしまう DNS キャッシ. での接続試行の際，宛先に対する近隣要請（Neighbor. ュサーバは，一定期間，DNS クライアントからの IPv4. Solicitation）が失敗するまでに数秒を要し，円滑な接続. アドレスの要求に対しても名前エラーを返す．このよう. 試行動作が妨げられてしまう．. なサーバを参照している DNS クライアントは，結果的に通信できる可能性のある IPv4 アドレスを得ることが. TCP の対エラー反応問題. できない．. TCP では，ICMP のエラーを致命的なもの（ハードエ. 不正な権限委譲（Lame Delegation）になる. ラー）とそうでないもの（ソフトエラー）に分類し，ネ. DNS サーバの中には，本来は管理権限を持つ. ットワークの一時的なエラーで接続が切断されないよう. （Authoritative）にもかかわらず，管理権限がない. にしている．ICMPv6 の取り扱いも同様の考え方が踏襲. （Inauthoritative）とする応答を AAAA RR の問合せに対. されている（表 -1）．. して返すものがある．一部の DNS キャッシュサーバは，. TCP のコネクション確立の試行においては，名前に対. このような場合を不正な権限委譲だと見なし，そのよう. 応するアドレスに対して順次コネクションの確立を試み. な応答をする DNS サーバを一定期間利用せず，DNS ク. る．この過程において，通信相手からリセットが返った. ライアントからの要求に対して応答コード 2（サーバ障. り，ハードエラーが返ったりする場合は，TCP は直ちに. 害（Server Failure））を返してしまう．その結果，DNS. コネクションの確立を失敗として，迅速に接続試行動作. IPSJ Magazine Vol.46 No.8 Aug. 2005. 889.

(4) プロジェクトと最新インターネット技術研究動向. 特集. を継続できる．しかし，そうでない場合，すなわち，ソ. AAAA RR の問合せの限定. フトエラーが返ったり，そもそもエラーが返らなかった. IPv6・IPv4 両対応クライアントにおける名前に対する. りする場合は，再送の回数制限やタイムアウトに達する. アドレスの検索は，IPv6 および IPv4 のアドレス両方を. まで接続のための再送を繰り返し，円滑な接続試行動作. 検索することが一般的に行われてきた．しかし，自らに. が妨げられてしまう．. IPv6 の接続性のない環境下で相手方に対して IPv6 通信. この問題の本質は，頑健性を確保しつつ接続試行の迅. を試みることは，実用的にはほとんど意味がない．. 速性を確保しなければならないという，相反的な要求の. このような場合には，IPv6 アドレスの名前検索を割愛. 実現の困難さにある．近年では，同一のサービスを行う. して IPv4 アドレスのみを検索し，コネクションの確立. 複数のアドレスを同一の名前に関連づける運用も広く行. の試行をすれば十分であると考えられる．. われており，IPv6 の対応に限った問題ではない．. ここで，IPv6 の接続性のない IPv6 環境，とは，具体的には，ループバック（loopback）およびリンクローカ. 通信経路の品質問題. ル（link-local）アドレス以外に IPv6 アドレスを持たない. 実際のデータの送受信においては，その品質の確保が. 環境，と定義できる．. 重要である．. 多くの IPv6・IPv4 両対応アプリケーションは，名前解. IPv6 は，その普及の促進のために，トンネル接続など. 決にプロトコル非依存な名前アドレス変換関数である. の手軽な接続手段を提供してきた．トンネルは IPv6 の. getaddrinfo() を用いており，これに対策を施すこと. 導入に欠かせない技術であるが，同様に不適切な利用も. によって，特に IPv6 アドレスの検索に対して誤った反. 簡単にできてしまう．特に，たとえば，国内の通信が海. 応をする DNS サーバの問題を回避し，円滑に接続の試. 外のトンネルサービスを経由するといった，ネットワー. 行を行うことができるようになる．. クのトポロジを無視したトンネルは，利用可能帯域の減. AAAA RR の問合せ待ち時間の短縮. 少や応答時間の増大といった，通信品質が低下する問題. IPv6 の接続性を持った環境においては，名前検索にお. の大きな要因となっている．トンネルで構成されたネッ. ける IPv6 アドレスの検索と，接続の試行を省略するこ. トワークは診断も難しく，障害などによる品質低下を招. とはできない．しかし，特に AAAA RR の問合せを無視. きやすい．. するサーバに対しては，以下のような方法により，問題. また，経路上のファイアウォールなどが ICMPv6 など. の影響を軽減できる．. の制御メッセージを遮断すると，大きなデータの送受信. （1）問合せの順序を，A RR，AAAA RR の順とする．. 時にデータが過大なサイズであることを検知できずに通. （2）A RR の問合せが成功した場合，その応答までに要. 信が停止したり，接続の試行が円滑に進まなくなったり. した時間（T）をもとに適応的なタイムアウト（たと. する原因となる．. えば，max（2T, 1）秒）を算出し，AAAA の問合せに適用する．. 移行期における問題に対する対策の検討. これにより，AAAA RR に対する問合せが無視される場合においても，より迅速に検索結果を得て，接続の試. ここまでに示してきた問題の多くは，IPv6 そのものの. 行を行うことができるようになる．. 問題ではなく，本来は仕様に準拠しない実装を修正する必要のある問題である．とはいえ，この状況を放置する. On-link Assumption 問題への対策. ことは，利用者が IPv6 に対応した際の，IPv6 対応機能や. On-link Assumption 問題は，IPv6 関連仕様そのものが. IPv6 技術そのものの印象を悪くする可能性がある．IPv6-. 移行の妨げとなる可能性のある，現在知られている唯一. Fix では，それらの影響をできるだけ軽減するため，解析. の問題である．この問題は IETF でも認識され，次の仕. によって明らかになった問題への対策も検討している．こ. 様改訂の際には解決される予定である．. れまでにあげた問題への対策内容を以下に紹介する．. この問題は，新しい仕様に沿った IPv6 関連機能の更新のほか，名前に対するアドレスの検索における問題の. 名前に対するアドレスの検索における問題への対策. 項で示した AAAA RR の問合せの限定を適用することに. 名前に対するアドレスの検索における問題は，多くの. 入されるデフォルトの経路を意図的に削除することで，. 場合，名前解決の方法を工夫することによって問題を回. 対応が可能な場合がある．. 避することができる．. 890. 46巻8号情報処理 2005年8月. よって解決できる．また，実装によっては，自動的に挿.

(5) IPv6-Fix : IPv6 普及期に向けた取り組み. ドメイン. DNSサーバ. AAAA RR の問合せを無視する. 4.7%. 名前エラーを返す. 4.7% 8.5%. 問題あり. 0.04%. 0.11%. 問題なし. 82.16%. 84.39%. 正常終了，名前エラー以外の応答コードを返す. 不明. 17.80%. 15.50%. 不正な権限委譲になる. 表-2 JPドメインにおけるDNSの挙動（文献1）より引用）. TCP の対エラー反応問題への対策. 82.1%. 表-3 問題ありとなったサーバの挙動分類（文献1）より引用）. 果は限定的である．. TCP の対エラー反応問題に関しては，本来は，DNS に. このように，ネットワークから何も情報が得られずタ. 登録されたすべてのアドレスは到達可能とし，また，そ. イムアウトする場合，現実的な解決策は難しい．. れらでは同一のサービスを提供すべきであって，そうなっていないホストやネットワークを修正すべきである．. 調査ツールによる問題の蔓延度測定. とはいえ，これらの問題を解決することは必ずしも容易ではないため，現実的には，TCP における接続試行の遅. これまで挙げてきた諸問題は，いくつかの事例が報. 延を低減することが必要である．. 告されているものの，それらの問題が実際にどれほど蔓. この対策は，元来の頑健性を保ちつつ接続試行の迅速. 延し，深刻であるかは明らかでなかった．IPv6-Fix では，. 性を確保することが重要である．. これまで挙げてきた諸問題の実世界における蔓延度の調. コネクション確立の試行に対して ICMP ソフトエラーが返. 査を行っている．. る場合 ICMP ソフトエラーが返る場合には，コネクション確. DNS サーバの挙動に関する調査. 立時に限りこれをハードエラーと同様に見なして接続を. IPv6 移行期の典型的利用シナリオと問題点の中で示し. 中断する方法があり，実際に効果が知られている．外. たような，不正な挙動をする DNS サーバの存在とその. 部からの攻撃に対する懸念に対しては，すでにハードエ. 影響の広さを測定するために，DNS サーバの挙動を調. ラーを用いれば同様の攻撃が可能であるために，頑健性. 査するツールを作成し，状況を調査した．. に大きな影響はないと考えられている．一方，再送，別. この調査は，（株）日本レジストリサービス（JPRS）. アドレスへの移行に関しては，ネットワークにより接続. との共同研究として，2004 年 11 月現在の JP ドメイン. 性の状況が異なるため，議論がある．. リストを対象に，5 日間かけて実施した．. コネクション確立の試行に対して反応がない場合. 調査方法としては，“www”や“ftp”などの典型的. コネクション確立の SYN パケットに対してまったく. なホスト名をドメイン名に付加し，そのドメイン名を管. 応答がない場合，タイムアウト以外に利用できるイベン. 理する DNS サーバから A RR と AAAA RR の取得を試み. トはないが，いくつかの対策は考えられる．. る，という方法を用いた．. 3）. 以下にその結果を示す． • タイムアウトを極端に短くする手法．. 表 -2 は，調査対象となったドメインおよびサーバに. ただし，頑健性を損うため，問題である．. 対して，問題であると考えられる挙動を示した割合であ. • 複数のアドレスに並列に接続を試みる手法．. る．サーバの一時的ダウンや，ホスト名の誤推測などに. ただし，種々の無駄が多く，また，既存の機構への変. よる不明部分を除くと，問題のある挙動をするドメイン. 更が非常に大きいことが問題である． • 到達できないアドレス情報を保持し，その宛先につい. やサーバは，全体の 0.1% 程度であることが分かった．表 -3 は，問題があると判定されたうちの，原因の分. て，それ以降利用しないようにする手法．. 析結果である．かなり多数の不正な権限委譲が観測され. 最初のコネクション確立には時間がかかるが，2 度目. ている．. 以降のアクセスには効果がある．. 今後はこうした，不正な挙動をする DNS サーバの実. しかし，実現に必要な変更の大きさのわりに，その効. 装を特定するために，ドメイン管理者へ聞き取り調査を. IPSJ Magazine Vol.46 No.8 Aug. 2005. 891.

(6) プロジェクトと最新インターネット技術研究動向. 特集. トンネル発見図 -2 は，IPv4 と IPv6 がデュアルスタックで運用. IPv6 response time (msec). 1,000. されているいくつかのホストに対して，Euro6 から. 800. Traceroute ツールによる通信経路の検出を行った結果を. 600. 整理したものである．. 400. プでも特に遅延が発生している部分がみられる．これら. IPv4 と IPv6 で 1 ホップの遅延を比較すると，1 ホッ. 0. はトポロジを無視したトンネルであると推測される．. jp apnic arin ripe. 200. 0. 200. 400. 600. 800. 1,000. IPv4 response time (msec). 図-1 WIDEからのIPv6/IPv4 RTT分布（文献4）より引用). 今後の取り組みここまでをまとめると，結局，IPv6 の一般的普及までには，その仕様，実装，運用のそれぞれの局面において若干の問題があがってきている．この若干の問題が， IPv6 の移行の過渡期では重要であり，見過ごすわけにはいかない．その中でも，一番問題であるのは，DNS の名前検索に. 行い，その結果をベンダへ報告する予定である．また，. おける問題である．それは，現在，実際に多くのアプリ. 調査範囲を JP ドメイン以外にも拡げるべく，その際の. ケーションが IPv6 に対応し DNS の A RR および AAAA. 調査方法を検討している．. RR の問合せを送信するためである．DNS の検索では，A RR，AAAA RR の問合せがいずれも正確に処理されるこ. 品質調査ツール. とが大前提であるが，現実には，これらの前提が成り立. 移行期における問題に対しては，前述したいくつかの. たない場合があることは，ここまでに報告した通りであ. 対策を講じることで，接続できないといった致命的な問. る．結果として，Web ブラウジングの例で言えば，表. 題は回避することができる．. 示できるはずのページが表示できなかったり，ページが. しかし，インターネットが社会基盤の 1 つとなった現. 表示されるまでに長時間待たされたり，といった症状が. 在，単に接続できるだけでなく，サービスの提供が円満. 現れることがある．IPv6-Fix では，これらの問題に対処. で，ユーザが魅力を感じるものでなければならず，IPv6. するための手法を検討・実装している．. の普及のためには，その品質を適切に維持することも重. 品質の問題に関しては，バックボーンについては，大. 要である．. きな問題は見あたらない．しかし，バックボーンにおい. 一般に，インターネットの品質の尺度としては，パケ. ても，IPv6 対応の IX（Internet eXchange）はまだ数が少. ットロス率や応答時間（RTT（Round Trip Time））などが. なく，ピアリングも十分になされていないことや，構成. ある．IPv6-Fix では，このうち，RTT を中心とした品質. 機器の制約等で IPv6 で利用できるパスが限定されてい. 調査を継続的に実施している．. ることも事実である．また，一部にはトポロジに沿って. 遅延. いないトンネル接続や接続性のないホストの存在も確認. 図 -1 は，IPv4 と IPv6 がデュアルスタックで運用され. されており，利用可能帯域の減少や応答時間の増大とい. ているいくつかのホストに対して，WIDE プロジェクト. った通信品質の低下の大きな要因となっている．IPv6 普. から Ping による RTT の計測を行った結果を示している．. 及促進のためには，IPv6 ネットワークの品質の向上がそ. IPv6 と IPv4 の RTT には正の相関関係が認められ，お. の課題の 1 つである．しかし，品質の問題は必ずしも. おむね問題はないと考えられる．特に，調査対象が属し. 把握が容易ではないため，ネットワーク運用者も問題を. ているネットワークの種類によって，傾向に著しい差異. 認識していないことが多い．IPv6-Fix では，調査結果を. がないことから，バックボーンについては特に問題はな. 分かりやすく運用者にフィードバックし，IPv6 ネットワ. いと言える．とはいえ，IPv6 の方が RTT が少ないホスト. ークの品質改善につなげていくことも重要であると考え. がある一方で，一部には IPv6 での遅延が IPv4 に比べて. ている．. 突出しているホストも見られ，改善が必要な場合も実際. IPv6-Fix は，これまで述べてきたような IPv6 移行の過. に存在することが確認できた．. 渡期や運用における問題点を調査・分析し，解決をはか. 4）. 892. 46巻8号情報処理 2005年8月.

(7) IPv6-Fix : IPv6 普及期に向けた取り組み. beaglems.rnet.missouri.edu (128.206.116.90, 2001:468:1fc:4::3) 23 196ms MTU:1280 13 350ms ns4.indiana.edu (129.79.6.120, 2001:468:402:4:203:baff:fe2b:5f2c) 20 170ms MTU:1280 11 350ms ns-i2.nyser.net (199.109.32.33, 2001:468:901:1:250:daff:fe20:5b03) 20 171ms MTU:1280 12 387ms route-views6.routeviews.org (128.223.60.194, 2001:468:d01:3c::80df:3c6d) 23 230ms MTU:1280 14 346ms hpcfns1.hpcf.upr.edu (136.145.54.10, 2001:468:1300::10) 22 275ms MTU:1280 11 409ms ipv6.internet2.edu (207.75.164.64, 2001:468:1420::1500) 15 229ms MTU:1280 11 356ms noc.gigapop.gen.tx.us (198.32.236.242, 2001:468:1a00::242) 17!L 203ms MTU:1280 13 370ms 0. 100. !L. SATEC CERN COGENT Qwest MORENET. IPv4 to dst IPv6 to dst ABRARED BT-CIN-AND-ADASTRAL BT. 200. 300. response time (msec) ABILENE Level3 INDIANAGIGAPOP INDIANA-AS NYSERNET3-AS-3. NERO-NET UONET VERIO INTEGRATED-SYSTEMS UPRENET. 400 MICHNET-ASN. 図-2 Euro6からのホップ数およびRTT（Tracerouteによる）（文献4）より引用）. 日付. イベント. 詳細情報. 2004.11.10. IETF61 v6ops wg. http://www.ietf.org. 2004.12.01. Internet Week 2004. http://www.internetweek.jp. 2005.01.20. JANOG 15. http://www.janog.gr.jp. 2005.01.27. APAN 19. http://apan.net. 2005.02.23. APRICOT 2005 IPv6 Fix BOF. http://www.apricot.net. 2005.03.09. IETF62 v6ops wg. http://www.ietf.org. 2005.06.07. Interop Tokyo 2005. http://interop.jp. 表-4 啓蒙活動イベント. るとともに，その成果を啓蒙することを目的としてきた．. Web サイト http://v6fix.net. その成果は文書として公開している．また，問題解決. 電子メール [email protected]. 1）. 策については標準化団体，運用コミュニティ，ベンダなどへ働きかけ，IPv6-Fix の成果についてインターネット関連イベントで発表してきた（表 -4）．今後もその取り組みを継続していく． IPv6-Fix では，引き続き，症例や問題のあると思われる製品情報を募集しているので，情報をお持ちの方は，ぜひ IPv6-Fix までお寄せいただきたい．. 参考文献 1）国武功一，下條敏男，神明達哉，竹内奏吾，長健二朗，山本和彦: 2004年度WIDEプロジェクト研究報告書, pp.499-511(2005). 2）Morishita, Y. and Jinmei, T. : Common Misbehavior Against DNS Queries for IPv6 Addresses, IETF RFC4074 (2005). 3）Gont, F. : TCP's Reaction to Soft Errors, IETF Internet-Draft draft-gonttcpm-tcp-soft-errors-01.txt（2005）. 4）Cho, K. Luckie, M. and Huffaker, B.: Identifying IPv6 Network Problems in the Dual-Stack World, SIGCOMM'04 Network Troubleshooting Workshop, Portland, Oregon, U.S.A.（2004）. （平成17年6月28日受付）. IPSJ Magazine Vol.46 No.8 Aug. 2005. 893.

(8)