NTT IPv6閉域網フォールバック問題

2012/3/28-1

NTTのIPv6閉域網におけるフォールバック問題の解説です。同問題に対する正式な名称があるわけではありませんが、ここでは「NTT IPv6閉域網フォールバック問題」と表現しています。

当初、NTT NGN IPv6マルチプレフィックス問題の解説から書き始めていたのですが、色々考えているうちにNTT NGN IPv6マルチプレフィックス問題とNTT IPv6閉域網フォールバック問題に関してゴチャゴチャな文章になってしまったので、切り分けるためにあえてIPv6閉域網フォールバック問題だけにフォーカスした文章にしました。

個人的な感想として、背景となる環境等を考えるとNTT NGNがIPv6を利用して実装されていることそのものに関して「設計が悪い」とは思ってません。また、NTT IPv6閉域網に関連する各種問題はNTT NGNに限った話ではなく、NTT NGNではないBフレッツ等でも発生する問題であるため、IPv6閉域網フォールバック問題の話をしているときにNTT NGNがIPv6で構築されていることを批判する意見は多少ピントがボケてしまっている気がしています。

それらに関してはまたの機会に書きたいと思います。

「IPv6からIPv4へのフォールバック」とは

NTT IPv6閉域網フォールバック問題を理解するには、その前提となるIPv6からIPv4へのフォールバックを理解する必要があります。 IPv6からIPv4へのフォールバックは、現時点におけるIPv4/IPv6デュアルスタック環境では一般的に発生し得る現象です。

IPv4とIPv6の間には互換性がありませんが、DNSを利用して名前解決を行う部分は共通です。権威DNSサーバにIPv4とIPv6両方が登録されていれば、FQDNからIPv4アドレスとIPv6アドレスの両方が得られます。 DNSへの問い合わせそのものはIPv4とIPv6のどちらを利用する事も可能なので、IPv4しか利用できない環境でFQDNに対するIPv6アドレスを取得出来てしまいます。

現在、IPv6対応をした多くのアプリケーションは、以下の手順で通信を開始します。

名前解決を行う(たとえば、getaddrinfo)
IPv6とIPv4のIPアドレスが存在していた場合IPv6での接続を先に試みる
IPv6での接続が失敗したらIPv4での接続を試みる

IPv6での通信が成功すれば問題がないのですが、IPv6での接続が失敗した場合にIPv4を試みることから、この手順を経てIPv4での通信を行うことが「IPv6からIPv4へとフォールバックしている」と表現されることもあります。

IPv4へのフォールバックにおける問題点の一つに通信開始までの遅延があげられます。 IPv6を試みて失敗したのちにIPv4での通信を試みるため、はじめからIPv4だけで通信を開始する場合よりも通信開始が遅くなります。 IPv6での接続が失敗し、IPv4での接続が確立するまでに数十秒も遅くなる可能性すらあります。

さらに大きな問題は、IPv6での接続に失敗してしまうと通信そのものをあきらめてしまうアプリケーションも存在している点です。

できるだけ高速にサイトを表示することが非常に大事であるとされるWebコンテンツ事業者にとっては、IPv6からIPv4へのフォールバックによって表示速度が遅くなったり、そもそも表示されなくなるというのは避けたい事象とも言えます。

NTT IPv6閉域網におけるフォールバック問題

「NTT IPv6閉域網フォールバック問題」とは、Bフレッツ、フレッツ光ネクスト、NTT西日本の光プレミアムにおいてユーザセグメントにIPv6アドレスが配布されるものの、そのIPv6アドレスではIPv6インターネットと通信ができないというものです。

NTT IPv6閉域網で配布されるIPv6アドレスは、割り振りとしてはグローバルIPv6アドレスですが、そのIPv6アドレスはIPv6インターネットと接続されていないので、そのIPv6アドレスを利用してIPv6インターネットと通信することはできません。

そのため、同環境下でIPv6を使える設定のPCを使用している場合、インターネットと通信を行う際にIPv6からIPv4へのフォールバックが必ず発生してしまいます。 ISPでIPv6サービスを申し込んでいない場合、つまりユーザPCにおいてIPv6でのインターネット接続性がなくNTT IPv6閉域網によるIPv6アドレスが設定されている場合を図にすると以下のようになります。

NTT IPv6閉域網では、フォールバックにかかる時間を短縮するための対策として、NTT IPv6閉域網ではないIPv6アドレスへのTCP通信に対してTCP RSTパケットが送付されます。それにより、ユーザが開始しようとしたIPv6でのTCP接続が早期に確立失敗し、IPv4へとフォールバックする速度が早められます。

ただし、この対策はあくまでTCPに対してのみであることや、IPv6でTCP RSTを受け取って「接続失敗」となった場合にIPv4でTCP接続を再度試みるかどうかはアプリケーションの実装依存となっているので注意が必要です。

NTT IPv6閉域網フォールバック問題は新しい問題ではない

NTT IPv6閉域網におけるフォールバック問題は昔から存在していました。

NTT東日本がBフレッツ回線にIPv6アドレスを割り当て始めたのは2007年2月です(参考1, 参考2)。 2007年時点でNTT東日本のWebサイトに以下のような注意事項が記載されています。

インターネット上には、IPv6とIPv4の両方で公開されているホームページが存在しており、このようなホームページへアクセスする場合には、初回表示に数十秒かかる場合がございます
...(中略)...

【対処方法2】
IPv6をはずすことで回避可能です。設定手順は、以下のとおりです。

BフレッツやNTT西日本のフレッツ・光プレミアムだけでなく、2008年に開始されたNTT NGNサービスであるフレッツ光ネクストでもNTT IPv6閉域網のIPv6アドレス割り当てが行われています。

最近になって、この問題が騒がれるようになったのは、IPv4アドレス在庫枯渇が現実のものとなり、IPv6に関する取り組みが増えたためです。これまでは、NTT IPv6閉域網フォールバック問題が発生し得る環境であったとしても、インターネット上にあるサーバ側がIPv6対応をしていなかったので、ユーザ側がIPv6による接続を試みることがありませんでした。

具体的には、昨年のWorld IPv6 Dayにおいて多くのコンテンツ事業者(Webサイト)が期間限定でIPv6によるサービスを提供したことによって、NTT IPv6閉域網フォールバック問題が実際に発生したということがあげられます。しかし、多くの権威DNSサーバにAAAAレコード(IPv6アドレスを示すレコード)が登録されたことで、ユーザ側がIPv6での接続を試みるような状況が発生すると同時に、AAAAレコードを登録したWebサーバ側でも通信確立までの遅延が観測されたため、NTT IPv6閉域網フォールバック問題が世界的に有名になりました。

世界中で多くのサーバによるIPv6対応が行われた(というよりも権威DNSサーバにAAAAが登録された)ことで、かなり前から存在していた問題が顕著に現れるというのは、NTT IPv6閉域網フォールバック問題に限らず、今後は色々とあるのかも知れないと予想しています。

クライアントサイドでの対処

NTT IPv6閉域網におけるフォールバック問題では、IPv6によるインターネットへのアクセスが必ず失敗します。

しかし、そもそもフォールバック問題は、NTT IPv6閉域網固有の問題ではなく、IPv4とIPv6のデュアルスタック環境においてどこでも発生し得る問題です。

極端な話、NTT IPv6閉域網におけるフォールバック問題は、「IPv6インターネットへの通信が必ず失敗する」のと「NTT IPv6閉域網側からTCP RSTが送信されて早期フォールバックが実現できる場合もある」という分だけ、これから増えるであろうフォールバック問題よりは、まだマシという解釈も可能です。

たとえば、6to4などの自動トンネル技術などが途中経路に介在してIPv6側が「繋がるけど品質が著しく低い」という状況の場合は、デフォルトでIPv6が選択されてしまうと通信品質が低くなってしまいます。

そのような状況を避けるために提案されているのが「Happy Eyeballs」という手法です(現段階ではRFCではなくInternet Draftです)。

Happy Eyeballs: Success with Dual-Stack Hosts (draft-ietf-v6ops-happy-eyeballs-07)

Happy Eyeballsでは、IPv4とIPv6を同時に接続し、先に接続完了した通信を採用するという方法を提案しています。従来はIPv6を試してみて駄目だったらIPv4を試すという手法が基本とされていたため、フォールバック問題が発生していましたが、Happy Eyeballsではそれが発生しません。

デュアルスタック環境において動作するときに、このような手法を採用するアプリケーションが増えればフォールバック問題による害は少なくなると同時に、NTT IPv6閉域網におけるフォールバック問題の発生も抑制されるものと思われます。

AAAAフィルタ

前述した2007年のNTT東日本のWebサイトにもあるように、NTT IPv6閉域網フォールバック問題を避ける方法の一つとして「IPv6をユーザが使わない」というものもあります。

「ユーザがIPv6を使わない」という方法と多少似ていますが、ISPにあるキャッシュDNSサーバでDNS応答に含まれるAAAAレコード(IPv6アドレスを示すレコード)を抜いてしまう「AAAAフィルタ」という手法が2011年のWorld IPv6 Day前後に試験的に実施されました。実施したのは日本国内のISP事業者やIX事業者です。これにより、World IPv6 Day中にNTT IPv6閉域網フォールバック問題の発生がかなり抑えられたようです。

しかし、AAAAフィルタはアドホックな手法であるため、個人的な感想としてあまり多用されると各種障害を発生させるというのが個人的な感想です(参考：JANOG29 - AAAAフィルタとDNSSECは仲良くなれるのか)。

AAAAフィルタに関する説明は別途記事を書きたいと考えています。

追記：World IPv6 LaunchとNTT IPv6閉域網を巡る駆け引き - DNSでのAAAAフィルタ

NTT NGNにおけるIPv6マルチプレフィックス問題

現時点では、NTT NGN環境(フレッツ光ネクスト)のNTT IPv6閉域網におけるフォールバック問題を解決する方法の基本は、IPv6 PPPoE(旧案2)もしくはIPv6 IPoE(旧案4)を利用してユーザがISPによるIPv6環境を家庭内に導入し、IPv6対応することであるとされています。 IPv6 PPPoEもしくはIPv6 IPoEを利用することによって、IPv6インターネットへと到達できるIPv6環境が整うため、NTT IPv6閉域網の影響で「IPv6による通信が必ず失敗する」という状況を回避できるようになります。これらは、NTT NGN IPv6閉域網のIPv6アドレス配布を停止するのではなく、IPv6インターネットとの通信を可能にするという方法です。

このため、最近はNTT IPv6閉域網フォールバック問題とNTT NGN IPv6マルチプレフィックス問題がごちゃごちゃに語られることによって理解しにくくなっている場合があります。 NTT IPv6閉域網フォールバック問題とNTT NGN IPv6マルチプレフィックス問題は、関連はしていますが全くの別問題であるというのが私の認識です。

NTT NGNであるフレッツ光ネクストでしかIPv6 PPPoEもしくはIPv6 IPoEは利用できない点もわかりにくさを増大させる要因と言えます。現時点では、BフレッツやNTT西日本の光プレミアムではNTT IPv6閉域網におけるフォールバック問題を継続的に解決する手法がありません(各ユーザがIPv6をOFFにするなどの方法はありますが)。ユーザがBフレッツやNTT西日本の光プレミアムを契約している場合は、フレッツ光ネクストに乗り換えたうえでIPv6対応する必要があります。

最初はここら辺の話を中心に書き始めたのですが、あり得ないぐらい長くなってしまったので、今回の記事ではあえてout of scopeとしました。 NTT NGNにおけるIPv6マルチプレフィックス問題と、その解決手法等に関して別途記事を書く予定です。

ということで、そのうち続きを書く予定です。

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！