IPv6/IPv4 フォールバック問題への対応

化している

6man WG (IPv6 Maintenance WG) (

当時は

ipv6 WG)

にて提案説 明，議論の実施，また，オペレーションに関係するということから，

v6ops WG (IPv6 Operations WG)

での議論とたらい回しとなり，標準としての議論が進展し なかった．

このため，マルチプレフィックス環境に課題の整理，及び，解法の必要要件を はっきりさせることを目的とし，

2006

年

12

月に，マルチプレフィックス環境にお けるアドレス選択に関する問題提起についての文書

[29]

を提案した．この文書は，

v6ops WG

にて取り上げられ，

WG

での議論アイテムとなり

[30]

，また，同時に，

解法としてのアドレス選択ポリシ配付機構の要件定義について提案

[31]

した．両文 書は，問題提起文書

[32],

解決に当たる要件提起文書

[33]

として

RFC

化され，

2010

年

6

月に，

DHCP

アドレス選択ポリシ配布オプションについても，

6man WG

に て正式な議論アイテムとなった．

この後，筆者所属組織内の体制変更により，標準化作業を第二著者に引き継ぎ，

最終的に

DHCPv6

オプション定義

[34]

標準として規定された．

通信を開始する際，ノードは，通信相手が

IPv6

ノードか

IPv4

ノードかによって，

利用するプロトコルを選択して通信を実施する．インターネットにおいては，ネッ トワーク中のサーバなどのノードは，

FQDN

（

Fully Qualified Domain Name

）と いう階層的な名前にて識別される．

IPv6

と

IPv4

では，この

FQDN

は同一の名前 空間を利用しており，一つの名前に対して，

IPv6

アドレスと

IPv4

アドレスの両 方，もしくはどちらかが対応づけられている．ノードは，通信を開始する際，ド メインネームシステム（

DNS

）を利用し通信相手の

FQDN

に対応づけられている

IP

アドレスを取得する．通信相手のアドレスとして，

IPv6

アドレス（

AAAA

レ コード）と

IPv4

アドレス（

A

レコード）のどちらか，または両方が得られること になる．通信相手のアドレスとして，

IPv4

，

IPv6

の両方のアドレスが得られた場 合には，ノードの初期動作として，

IPv6

通信を先に実施することが

RFC6724

に て規定されている．

図

5.5

に，デュアルスタックノードが，

IPv6

ノード，

IPv4

ノード，および

IPv6/IPv4

デュアルスタックノードと通信する様子を示す．前述のように，通信相手がデュア ルスタックノードの場合，ノードはまず

IPv6

を使った通信を実施しようとする．

何らかの原因で，この

IPv6

通信が失敗したときに，ノードは

IPv4

での通信を試 す．この，

IPv6

通信から

IPv4

通信への切り替わりを「

IPv6

から

IPv4

へのフォー ルバック」と呼ぶ．

IPv6

から，

IPv4

へのフォールバックは，プロトコル非依存プ ログラミング

[35]

で推奨されているプログラミングスタイルをとったアプリケー ションの標準的な動作である．

図

5.5 IPv6/IPv4

フォールバック

IPv6/IPv4

フォールバックの発生原因

IPv6/IPv4

フォールバックは，

IPv6

接続性が安定していない場合や，障害など

により

IPv6

通信ができない場合に発生する．以下に，その例を挙げる．

•

管理されていない

IPv6/IPv4

共存・移行メカニズム（

6to4[4]

などの自動トン ネル）など，品質の悪い

IPv6

接続性を利用している場合

•

サーバが，

IPv6

アドレス（

AAAA

レコード）を

DNS

に登録しているが，

IPv6

での接続性を持っていない場合

• IPv6

グローバルインターネットへの接続性がないネットワークを用いてい る場合（

VPN

や，外部と通信できない社内ネットワーク，閉域ネットワーク など）

フォールバックが発生した場合，

IPv6

通信から

IPv4

通信への切り替わりに時間 がかかることがある．例えば，

Web

アクセスをしているユーザにとっては，

Web

ページが表示されるまでに

20

秒程度待たされる場合があり，ネットワークのユー ザビリティに大きく影響する．

IP

を利用している場合，ネットワークに障害があった場合など，通信に問題があ る場合には，

ICMP

（

Internet Control Message Protocol

）により，障害情報がネッ トワークからノードに通知されることが一般的である．

IPv6

では，

ICMPv6[36]

が 利用される．図

5.6

に，

IPv6

通信経路がない場合に，通信の始点ノードに障害が 通知される例を示す．

図

5.6 ICMPv6

によるエラー通知

インターネットノードが

TCP

通信を実施している際に，ネットワークから

ICMP

エラーを受け取った場合の動作は，

RFC1122[37]

に規定されている．この

RFC

で は，

ICMP

メッセージをネットワークの一時的通信障害（経路異常など）であり，

回復の可能性のある「ソフトエラー」と，恒久的な通信障害である「ハードエラー」

に分類し，ハードエラーを受信した場合には

TCP

通信を切断するが，ソフトエラー を受信した場合は

TCP

通信を切断してはいけないと定義している．しかしながら，

これは

IPv4

の

ICMP

（以下，

ICMPv4

）に対する定義であり，現状，

ICMPv6

に 対する

TCP

通信の動作に関する定義は存在しなかった．

図

5.7

に，

2007

年当時の

OS

実装における

, ICMPv6

受信時にフォールバックに かかった時間を示す．この時間は，

IPv6/IPv4

デュアルスタックネットワークに接 続した

PC

において，

IPv6/IPv4

デュアルスタック

Web

サーバに通信する際，中 間の機器にて，

PC

が開始した

IPv6

通信に対して，以下を実施し，

PC

が

IPv6

通 信から

IPv4

通信に切り替えるのにかかる時間を測定したものである．

•

エラーを通知せずに通信を遮断した場合

•

コード

0

〜

6

までの

ICMPv6

終点到達不可能メッセージを返答した場合

• TCP

の

Reset

を実施した場合

それぞれの値は，

PC

が最初の

IPv6 TCP SYN

パケットを送出してから，フォー ルバックが発生し，最初の

IPv4 TCP SYN

パケットを送出するまでにかかった時 間

(

秒

)

である．

図

5.7

機器の

ICMPv6

に対する反応

図

5.7

からわかるように，ネットワークエラーを通知する

ICMPv6

に対する端 末機器の反応は実装依存となり，統一的な対応が困難であった．

この課題に対し，根本的な解決を図るため，

WIDE IPv6 fix

³プロジェクトで も提起されていた

TCP

の

ICMPv6

に対する動作を正式に規定すべく，

IETF

に 提案を実施した

[38]

．また，同時に，このフォールバック問題が発生することを

APRICOT

などの運用コミュニティ，学会等で広報を実施した

[39][40]

．

IETF

への提案は，当時の

IETF Transport Area

の

Area Director

からも支持さ れていたが，同時に別な提案があがっており，協議の結果，そちらの提案を優先する 事となった．この提案は，

RFC5461[41]

として発行されている（

Acknowledgments

に名前が上げられている）．

現在は，より高度な実装として，

IPv4/IPv6

通信の品質を考慮に入れて利用す るプロトコルを選択する

Happy Eyeballs[42]

が標準化されており，いくつかのブ ラウザにて実装され，この問題の解決が図られている．

ドキュメント内 インターネットにおけるIPv6の導入に関する考察 : IPv4からのプロトコルマイグレーションの実現(本文) (ページ 62-66)