こんにちは、Yahoo! JAPAN IPv6 PJ スタッフです。
これまでの検証からサービスを IPv6 に対応させる事によって接続が遅延する、もしくはそもそも接続できないと言った現象が起きる事がわかりました。特に現在明確に発生する事がわかっている深刻な問題は、端末のネットワークに対する接続において到達性の異なる網の混在によってTCP接続が遅延する(もしくは遅延しているように見える)現象です。
この現象は、サービスにとってページの表示が遅くなるといった障害を引き起こし、われわれのサービスにとって非常に重大な障害となります。
今回は、この現象について詳しく説明したいと思います。
内容として過去のblogと被る内容があります。こちらの blog も参照しつつお読みいただけければと思います。
プロトコルとネットワークとインターネット
IPv4 や IPv6 と呼ばれるものは通信プロトコルです。通信プロトコルは通信を確立するための規定(ルール)であり、IPv6 と IPv4 は全く異なるプロトコルです。IPv4 と IPv6 はそのままでは相互に通信する事はできません。
通信ネットワークは通信を行うインフラとして構成された通信網を指します。その通信網で IPv6 や IPv4 というプロトコルが用いられ通信そのものを実現しています。
インターネット(と呼ばれるネットワーク)は数多ある通信ネットワークの一つに過ぎません。ただし、現状では最も巨大で利用者が多い通信ネットワークとなっており、その上では多種多様なサービスが全世界広域に提供されています。また IPv6 が用いられているインターネットと呼ばれるネットワークと、IPv4 が用いられているインターネットと呼ばれるネットワークはそのネットワークの IPv4/IPv6 Address や DNS の名前空間が同一管理団体で管理されているだけで、存在としては全く異なる存在になります。
以上は技術的厳密に正しい説明ではありませんが、以降の説明の前提とする概念としてご理解ください。
アドレス枯渇問題とは
もう一つの整理として アドレス枯渇問題 と呼ばれる問題を取り上げたいと思います。
通信は相手を識別する必要があります。その識別子とする ID として アドレス があります。原則としてこのアドレスは一つのネットワークの中に同一のアドレスが(別の対象として)重複してはいけません。アドレスが枯渇するという状態はそのネットワークに対して全ての IP アドレスが利用されており新規に追加できない状況と言われています。この問題は IP アドレスが有限である限り IPv4 であっても IPv6 であっても起こりうる問題であり、アーキテクチャとしての限界になります。
現在騒がれている アドレス枯渇問題 とは前述の内容とは少し違います。インターネットと呼ばれるネットワークにおける IP アドレスはインターネットと呼ばれるネットワークで利用される IP アドレスを管理する管理団体から 割り当て という手続きを経て利用す事が可能になります。今現在言われている アドレス枯渇問題 とは、そのインターネットと呼ばれるネットワークで利用される IP アドレスを管理する管理団体の割り当ての在庫が枯渇した状態になります。
つまり、現在騒がれている アドレス枯渇問題 はインターネットと呼ばれるネットワークで利用される IP アドレスを管理する管理団体の在庫が無くなり新規の割り当てが行う事が出来ない状態を指します。
IPv6 アドレスは枯渇しないのか ?
アドレスは IPv4 で 2の32乗つまり4,294,967,296 (43億)だけの数があり、IPv6 が 2の128乗 340,282,366,920,938,463,463,374,607,431,768,211,456 (320澗)だけの数があります。この絶対数だけ見れば IPv6 アドレスは IPv4 アドレスに比較し前述の枯渇と言う問題に対する耐性がきわめて高いように見えます。
本当でしょうか ?
今現在言われているアドレス枯渇問題と言うのは、割り当て によって起こったものと説明しました。つまり、割り当ての消費速度によって枯渇と言う状態に陥ることとなります。
まず IPv6 のアーキテクチャとしての最小割り当て単位は原則(現実的に) /64 になります。一つの LAN はそこに何台繋がっていようとも原則 /64 のアドレスを消費します。128bit の IPv6 アドレスに対して /64 という mask-length のアドレスの量は 2の 64乗、で 32bit 幅の IPv4 アドレスを 43億回枯渇させる量になります。IPv6 は一つの LAN (Segment/Broadcast Domain)に対してこれだけの量が割り当てる必要があります。
これで IPv6 アドレスの割り当て可能幅は 64bit になりました。さて、この 64bit はどう割り当てられるのでしょうか。IPv6 アドレス管理当初の2001年頃 /48 を End User Network に割り当てる 事を推奨していました。では /48 がどの程度の量かを考えてみます。現在の IPv4 インターネットでは一般に /32、つまり一つだけのアドレスが End User に割り当てられます。逆にいえば 32bit のアドレスが割り当て可能であるともいえます。それに対し、/48 つまり 48bit が割り当て可能であるという事は 16bit つまり 65536 倍の量になります。
この量はどう見られたのでしょうか。2001年に出されていた(RFC3177) /48 の推奨値はBest Current Practiceにカテゴライズされた RFC6177 で更新されています。
重要な事は、今現在あるアドレス枯渇問題は必ずしも構成の限界に達した訳ではなく、ある特定ネットワークのアドレス管理の限界に達したという事です。また、IPv6 のアドレス空間が IPv4 アドレスに比較し広大とはいえ結局はアドレス自体の絶対数ではなく、その管理によって枯渇と呼ばれる状態までの寿命が決定します。
インターネットと呼ばれるネットワークで利用される IPv4 アドレスは、アドレス枯渇問題によってこれまでの管理団体からの割り当てが難しくもしくは不可能になります。現在起きているのは管理団体ではなく、既に割り当てられた組織間での 移管 によってアドレスの再割り当てが進んでいるようです。これは既に割り当てられているアドレスで利用されていないものを、それを必要とする組織に管理を移譲するものです。こういった対応により管理団体のアドレスの在庫が枯渇した後で管理団体の在庫以外からの割り当ての調整が行う事によって割り当てと利用とを結びつける最適化が進んでいるようです。
IPv4 インターネットとIPv6 インターネットは異なるネットワークです。
さて、IPv6 に移行する(と呼ばれる行為)を行う事でアドレス枯渇問題は解消するのでしょうか ? インターネットと呼ばれるネットワーク全体を見ればこれは正しいかもしれません。
まず、IPv6 と呼ばれるプロトコルと IPv4 と呼ばれるプロトコルには互換性はありません。互換性が無いというのは、IPv6 アドレスを持ち IPv6 というプロトコルに対応した host と IPv4 アドレスを持ち IPv4 というプロトコルに対応した host が直接相互に通信する事は出来ないという意味です。これは IPv4 というプロトコルを用いて構成されたネットワークと IPv6 というプロトコルを用いて構成されたネットワークはそれぞれ独立であり、同時に IPv6 インターネットと IPv4 インターネットもまたそれぞれ独立でそのままでは相互に通信する事は出来ないという意味です。
多くの場合、一般的にはインターネットを利用すると呼ばれる行為はインターネットと呼ばれるネットワークに接続されその上に存在する情報やサービスを利用する事を指します。IPv6 インターネットはこのインターネットと呼ばれるネットワークがもう一つ新たに出来たと考えてください。新たに出来たのですからその上には何もありません。この新たに出来たまっさらなネットワークにインターネットと呼ばれるネットワークを既存の(IPv4)インターネットと互換性の無いプロトコルに対応させた上で接続し 引っ越す 事を一般に 移行 と呼んでいるようです。
過渡期には、IPv4 インターネットにしか無い資源、IPv4 インターネットと IPv6 インターネットの両方に在る資源、IPv6 インターネットにしか無い資源が存在する状態になります。この時 IPv6 インターネットからは IPv4 インターネットにしか無い資源はそのままでは利用する事が出来ません。ですので、その資源を IPv4 インターネットに加え IPv6 インターネットにも接続すると言った対応を行うか、IPv6 インターネットから IPv4 インターネットへの接続を中継するような仕組みを用いて IPv6 インターネットが既存の IPv4 インターネットと等価である(かのように)見せる事を行います。
さて、後者のIPv6 インターネットから IPv4 インターネットへの接続を中継するような仕組みを用いる場合、IPv4 インターネットでの IPv4 プロトコルでの通信を行うため IPv4 アドレスを必要とします。インターネットのアドレス管理団体の地域単位(RIR)における最後の /8 に対する在庫の割り当ては、このようなプロトコルの中継に利用されるものに対してのみ一組織に対して /22 が割り当てられます。/8 に対して /22 ですので地域単位(例えば Asia Pacific Region 程度の地域単位)で2の14乗、つまり理論値で 16,384 の組織に対してのみになります。(参考:JPNIC IANAにおけるIPv4アドレス在庫枯渇、およびJPNICの今後のアドレス分配について )
発生する問題と解説
発生する問題をIPv4 インターネットに加え IPv6 インターネットにも接続する対応の流れを踏まえながらご説明したいと思います。
まず、サービスに接続する流れをおさらいします。例えば、ある端末からインターネット上の https://www.yahoo.co.jp/ の web ページを表示するというシチュエーションを例にします。
- 1. 端末はURL を指定したりブックマーク等の操作によってブラウザーに https://www.yahoo.co.jp/ のページを表示するよう指示します
- 2. 端末のブラウザーは、指定された http:.//www.yahoo.co.jp/ から、まず www.yahoo.co.jp という名前に対応する IP Address を DNS を用いて調べます。
- 3, DNS から www.yahoo.co.jp に対応した IP Address を取得し、その IP Address に対して TCP の接続を開始します。
- 4. 端末とサーバーの間で TCP の接続を確立し、端末は HTTP でのリクエストをサーバーに送ります。
- 5. サーバーは端末からの要求に従って要求に対応するコンテンツを返します。
- 6. 端末のブラウザーはサーバーから送られてきたコンテンツを整形し表示します。
これを踏まえてサービスが IPv6 に対応するまでの流れとその内容をご説明します。
サービスが IPv6 に対応すると言う事
次に http:.//www.yahoo.co.jp/ が IPv6 に対応する事を説明します。ここでの IPv6 に対応する と言う表現は、www.yahoo.co.jp という既存の IPv4 インターネットで利用されている DNS 名を IPv6 インターネットと呼ばれるネットワークで利用可能とし、それが指す IPv6 アドレスに対し IPv6 インターネットと呼ばれるネットワークで接続可能とする状況を作るという作業になり、正確には IPv4 インターネットと同一 DNS 名で IPv6 インターネットで利用可能とする 事になります。
ですので上記内容を 移行 と表現するのは実際に行われる内容からは全く間違った表現になります。
から
という構成変更を行います。具体的には
- 1. www.yahoo.co.jp のサーバーを IPv6 に対応させる
- 2. 1 のサーバーに IPv6 Address を設定し IPv6 インターネットというネットワーク網に接続する
- 3. www.yahoo.co.jp という名前に 2 で設定した IPv6 Address を登録する
これによって、www.yahoo.co.jp という名前に対し DNS を用いて IPv6 Address を取得する事が出来、IPv6 インターネットを介して接続する事が可能となります。
この作業後 www.yahoo.co.jp という名前は IPv6/IPv4 両方の Address を持つ事になります。
これで www.yahoo.co.jp というサーバーが提供するサービスは IPv4 に加えて IPv6 にも対応しました。
さて、次に問題が起きる状況をご説明します
問題の発生(その1)
まず、IPv6 の仕様では IPv6 は IPv4 よりも優先される仕様となっています。
"優先される" というのは、ある名前例えば www.yahoo.co.jp という名前に対し、IPv6 と IPv4 両方のアドレスが DNS よって解決される場合、 IPv6 での接続を優先するという意味になります。
さて、もしある端末が IPv4 インターネットと IPv6 インターネットではない IPv6 のネットワークに接続されている状態だとどうなるでしょう。
- 端末は www.yahoo.co.jp という名前に対応する IP Address を DNS を用いて取得します。
- yahoo.co.jp に対応する IP Address は IPv6/IPv4 両方があり、IPv6 の仕様から IPv6 のネットワークの接続を優先しサービスに接続しようとします
- 端末は IPv6 のネットワークに接続されていますが、接続しているネットワークは www.yahoo.co.jp が存在する IPv6 インターネットと呼ばれるネットワークではありません。
- このため、端末は IPv6 を用いて www.yahoo.co.jp に接続できないネットワークを通じて www.yahoo.co.jp に接続を試みます。
- 当然、IPv6 ネットワークを介しては接続できません。また接続できないと端末が認識するまで時間がかかります。
- 端末は IPv6 ネットワークで接続が出来ないと認識すると次に IPv4 ネットワーク、つまり IPv4 インターネットでの接続を試みます。
- IPv4 は既存のインターネット接続であるため問題無く接続する事が可能となります。
このとき、"IPv6 ネットワークを介した接続できない接続の試み" が遅延となり、"ページの表示が遅れる" といった現象が起こります。
IPv6 は IPv4 よりも優先されると言う事
IPv6 と IPv4 の両方が利用可能な状態は Dual Stack と呼ばれます。Dual Stack の状態で IPv4 は IPv6 射影アドレスにマップされ IPv6 として扱う事が可能となります。
これによってアプリケーションは IPv4 と IPv6 をほぼ一つの実装で利用する事を可能としています。詳しくは RFC4038 Application Aspects of IPv6 Transition 4. Description of Transition Scenarios and Guidelines で規定/説明されています。
IPv6 は端末が(より正確には一つのインターフェースが)複数のアドレスを持ち、複数のネットワークに接続する事を許しています。
DNS は一つの名前に対して IPv6 と IPv4 の両方の IP Address を同時に扱う事を許しています。
これによって、IPv6 は一つの名前に対する複数の Address のどれを選択し複数のネットワークのどれを選択するかを決定する必要があり、それを優先順位のルールを用いて試行するという仕様になっています。
優先順位のルールは RFC3484 で規定されていますが、この規定の内容は接続される各々のネットワークの到達性の違いに対しては何の保証もされていません。
つまり、IPv6 が有効な端末では接続されるネットワーク(IPv4 も含みます)全てが単一の DNS 名に対して同一の到達性を持たない限り前述のような接続の遅延が発生する可能性があります。
これまで端末やサーバーに用いられる OS のネットワーク機能は IPv6 に対応しました。現在では多くの OS ではデフォルトで IPv6 が enable となっています。
IPv6 は自動設定機能があり、利用者は特に設定を必要とせずに IPv6 のネットワークに接続する事が出来ます。
逆に言えば、利用者は特に意識せず、つまり知らないうちに IPv6 ネットワークに接続されてしまう事もありえます。
その接続された IPv6 ネットワークは IPv6 インターネットである保証は何処にもありません。
この状況であっても IPv4 のみを用いたインターネットでのサービスには影響は起きません。
IPv4/IPv6 の両方に対応し、サービスが用いる DNS 名が IPv6/IPv4 両方のアドレスを返すようになった瞬間から IPv6 が IPv4 よりも優先されるため接続の遅延という現象が必ず起こります。
複数のネットワークと二つのインターネットと一つの DNS 名前空間
DNS は一つの名前に対して IPv6 と IPv4 のアドレスの解決を提供します。IPv6 に対応した端末は複数のネットワークに接続する事が可能ですが、そのネットワーク毎の DNS の名前空間を分離する事が出来ません。
また、IPv6 インターネットと IPv4 インターネットは異なるネットワークですが、その二つのネットワークに対する DNS の名前空間は統合されてしまっています。
ある名前が返すアドレスがどのネットワークで有効なのかを端末は到達性を踏まえた適切な判断を行う事が出来ません。IPv4 インターネットで用いている DNS 名に IPv6 アドレスを付加する時、そのアドレスがどの IPv6 ネットワークでのアドレスかを端末は知る事が出来ません。IPv4 インターネットの DNS 名に IPv6 アドレスを付加すると言う事は、その DNS 名に対するアドレスの到達性をサーバー側と端末側の両方で確立する必要がありますが、サーバー側では端末の接続性を制御する事が出来ないのです。
そこに在る問題
最初にご説明したように、プロトコルとネットワークとインターネットはそれぞれ異なります。プロトコルはネットワークを構成する際に利用され、インターネットは構成されたネットワークの一つでしかありません。この認識をもう一度整理したいと思います。
- IPv6 や IPv4 はプロトコルであり、インターネットそのものとは違うものです。
- インターネットはある特定のネットワークを指し、ネットワークの全てがインターネットではありません。同時に IPv4 で構成されているインターネットと呼ばれるネットワークと、IPv6 で構成されているインターネットと呼ばれるネットワークは異なるネットワークです。
- IPv6 や IPv4 というプロトコルが用いられるサービスはインターネット上のみにあるわけではありません。現在では様々な機能に IPv4 や IPv6 が利用されています。
接続キャリアは物理的な接続を提供します。また、接続キャリアと ISP が同一であるとは限りません。 キャリアは CATV や電話といったサービスを行う事があります。このサービスはキャリア自身が持つネットワークの範囲内に提供されインターネットと関係がありません。
ISP はキャリアのネットワークを利用し、インターネット接続を提供します。利用者はキャリアとISPの両方と契約しキャリアの接続を利用しインターネットに接続します。
さて、キャリアが電話や CATV 等の自営サービスで IPv6 というプロトコルを利用するとします。
キャリアは自身が持つ接続に有効な IPv6 というプロトコルをその規定に従い正しくネットワークを構築します。その構築したネットワークに IP電話やストリーミングといったサービスを載せます。
キャリアを利用している利用者の端末が IPv6 に対応していた場合、その端末はキャリアのIPv6ネットワークに接続されます。 キャリアの IPv6 ネットワークは IPv6 インターネットではありません。
この結果、利用者は ISP によって提供される IPv4 インターネットとキャリアの IPv6 ネットワークという到達性の異なるネットワークに接続される事になります。
問題の発生(その2)
さて、前述のように IPv6 が有効な端末では接続されるネットワーク(IPv4 も含みます)全てが単一のDNS名に対して同一の到達性を持たない限り前述のような接続の遅延が発生する可能性がありますと説明しました。そして前述の問題は端末が接続するネットワークが IPv4 インターネットと呼ばれるネットワークと、ある IPv6 アドレスに対して異なる到達性を持つ IPv6 ネットワークに接続されているシチュエーションに対するものでした。
IPv6 が有効な端末が IPv6 インターネットと、ある DNS 名が指す IPv6 アドレスに対して異なる到達性を持つ IPv6 ネットワークに接続されている場合を考えてみます。
結論から言えば端末は到達性の異なる複数のネットワークに接続される状況となり同じ問題が起こり得ます。更に厄介なのは IPv4 インターネットと IPv6 ネットワークという比較的明確な分類では無く、RFC3484 に従ってそれぞれのネットワークから割り当てられたアドレスと宛先アドレスとの数値としての距離によってどのネットワークを利用するかが決まってしまうので、どの宛先アドレスで遅延が発生するという状況になるのかが個々の端末の状況によってまちまちになってしまい、非常に混乱する状況になり得ます。
つまり、IPv4 を無くせば問題が解決するわけでは無く、IPv6 単体でも問題が発生する可能性があると言う事です。
source address selection と destination address selection
問題その1 と問題その2 の違いはなんでしょう ?
RFC3484 には source address selection と destination address selection という二つの動作が規定されています。これらは、接続を行う際に (それが複数ある場合)端末のどのアドレスを選択するか と (それが複数ある場合)宛先のどのアドレスを選択するか という選択に対する(デフォルトの)優先順位を規定しています。
Dual Stack Host は IPv4 Address を IPv4 Mapped Address として扱います。冒頭でも紹介した以前松本のblogでも解説されていますが、RFC3484 では Policy Table というものを定義しその Policy Table に従って優先順位が決定します。さて RFC3484 2.1 Policy Table ではデフォルトの Policy Table が規定されています。
If an implementation is not configurable or has not been configured,
then it SHOULD operate according to the algorithms specified here in
conjunction with the following default policy table:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
とあります。この policy table は ::ffff:0:0/96 という IPv4 Mapped Address の Precedence が 10 であり最も優先順位が低くなっています。これが IPv6 は IPv4 よりも優先されるという実装根拠になっています。
問題その1は destination address selection によって引き起こされます。まず複数の宛先アドレスがある状態というのは、ある一つの DNS 名に対して IPv4(A)/IPv6(AAAA) 関係無く複数のアドレスがある状態を指します。TCP のクライアントプログラムの実装例は RFC4038 6.3.2. Example of TCP Client Application で示されており
struct addrinfo hints, *res, *aip;
int sockfd, error;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
for (aip=res; aip; aip=aip->ai_next) {
sockfd = socket(aip->ai_family,
aip->ai_socktype,
aip->ai_protocol);
if (sockfd < 0) {
switch errno {
case EAFNOSUPPORT:
case EPROTONOSUPPORT:
/*
* e.g., skip the errors until
* the last address family,
* see section 4.4.
*/
if (aip->ai_next)
continue;
else {
/* handle unknown protocol errors */
break;
}
default:
/* handle other socket errors */
;
}
} else {
if (connect(sockfd, aip->ai_addr, aip->ai_addrlen) == 0)
break;
/* handle connect errors */
close(sockfd);
sockfd=-1;
}
}
if (sockfd > 0) {
/* socket connected to server address */
/* ... */
}
freeaddrinfo(res);
となっています。
ここで重要なのは、getaddrinfo が返す struct addrinfo **res の内容になります。addrinfo は自己参照リストの構造を持ち、そのリストが RFC3484 のルールに従って一つの DNS 名に対する複数のアドレスを優先順位に従って並んでいます。それを for (aip=res; aip; aip=aip->ai_next) のループで connect() を試行するという実装での動作になります。
これがフォールバック(failed back)と呼ばれる動作の実体です。フォールバックはアプリケーションの実装によって動作が行われています。
問題その2 は source address selection によって引き起こされる問題です。IPv6 において発信元アドレスが複数あるという状態は RFC4291 2.1 Addressing Model で規定されており
A single interface may also have multiple IPv6 addresses of any type (unicast, anycast, and multicast) or scope.と記述されています。一つのインターフェースに複数のアドレスがある状態と言うのは例えば
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx
inet addr:192.0.2.130 Bcast:192.0.2.255 Mask:255.255.255.0
inet6 addr: 2001:db8::1/64 Scope:Global
inet6 addr: 2001:db8:8000::1/64 Scope:Global
inet6 addr: fe80::5652:ff:xxxx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33659 errors:0 dropped:0 overruns:0 frame:0
TX packets:448344 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3231264 (3.0 MiB) TX bytes:18830680 (17.9 MiB)
Interrupt:10 Base address:0x8000
$
といった状態になります。この状態では 2001:db8::1,2001:db8:8000::1 の2つの IPv6 Global Unicast Address が Interface eth0 に設定されている状態です。
IPv6 は自動設定が提供されています。これは RFC2462 IPv6 Stateless Address Autoconfiguration で規定されており、ルータと端末が接続されている LAN を通して割り当てられたアドレスを設定します。
さて一つの LAN(Segment/Broadcast Domain) に複数の Router が繋がり、それぞれが別々の Network であった場合、一つの LAN 上に複数の Network のアドレスが割り当てられる事になります。この様な場合、その LAN に接続されている端末は複数の IPv6 Address が自動的に設定される事になります。
これが IPv6 は一つの端末が複数のネットワークに接続する事を許すという状態になります。1対1の通信はそれぞれの ID を用いられて個別化され、その ID が IPv4 や IPv6 ではアドレスとなります。ですので、通信をする際に自分の ID たるアドレスが複数ある場合、そのどれを使うかを選択しなければなりません。
また、端末は初期化を受けた Router を default gateway として設定します。つまり、接続された Network の数だけ default gateway が存在する事になります。
実際には
# netstat -nrA inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
2001:db8::/64 :: UA 256 16845 0 eth0
2001:db8:8000::/64 :: UA 256 16812 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 fe80::5054:ff:yyyy:yyyy UGDA 1024 2 0 eth0
::/0 fe80::5054:ff:zzzz:zzzz UGDA 1024 0 0 eth0
::1/128 :: U 0 1 1 lo
2001:db8::5652:ff:xxxx:xxxx/128 :: U 0 0 1 lo
2001:db8:8000:0:5652:ff:xxxx:xxxx/128 :: U 0 0 1 lo
fe80::5652:ff:xxxx:xxxx/128 :: U 0 0 1 lo
ff00::/8 :: U 256 0 0 eth0
#
と言った状態になります。この場合は fe80::5054:ff:yyyy:yyyy と fe80::5054:ff:zzzz:zzzz によって初期化され default gatway として端末は設定しています。
この様に、端末は発見されアドレスを割り当てたルーターに対して default gateway を設定しているという事は、 実際の構成はどうであれ 端末はそのどちらのルーターを選択しても、つまりどちらのネットワークを選択してもどこにでも行けると認識しているという事になります。
どれを選択してもどちらに行けるネットワークに接続されていると端末は認識しているのですから、どの宛先アドレスに対しても端末は接続されているネットワーク全てを選択候補として扱います。あとは RFC3484 のルールに従って端末自身に設定されている発信元アドレスを選択し通信を行おうとします。RFC3484 では複数の IPv6 Global Unicast Address の発信元がある場合、宛先アドレスと数値的に近い方を選択する事になります。その選択が実際の構成を認識していない端末で到達性のあるネットワークが選択されるかどうかはわからないと言った状態になります。
この挙動は前述の TCP クライアントプログラムでは connect() というシステムコールで発生します。ですので、source address selection はフォールバックしません。規定された選択アルゴリズムで到達性の無いネットワークが選択されてしまうと、遅延するのではなく、接続できないという状態になります。
遅延するという現象
"接続が遅延する" という現象は実際どう起こっているかを解説します。
ある対象となる DNS 名に対して TCP 接続する状況を観測します。対象となる DNS 名は IPv6 のアドレスを2つ、IPv4 アドレスを1つ持ちます。接続元となる端末は IPv4 インターネットと IPv6 インターネットではない IPv6 ネットワークに接続されており、IPv6 ネットワークを経由して対象となる DNS 名の IPv6 アドレスに対して接続する事はできません。IPv4 はインターネットに接続されており、対象となる DNS 名に対する IPv4 アドレスへ接続する事は可能です。
端末の OS は Windows Vista を用います。
| 端末の IPv6 Address | IPv6 Source 1 |
| 端末の IPv4 Address | IPv4 Source 1 |
| サーバーの IPv6 Address 1 | IPv6 Destination 1 |
| サーバーの IPv6 Address 2 | IPv6 Destination 2 |
| サーバーの IPv4 Address | IPv4 Destination 1 |
ご存じのように TCP 接続は 3way handshake で行われます。対象となるアドレスに到達できないという事は、TCP SYN を送ってもそれがサーバーに到達せず SYN ACK が返ってこない状況になります。端末は TCP SYN を送った後、接続先からの SYN-ACK を待ちます。端末は SYN-ACK が最大待ち時間(timeout)を経過しても宛先サーバーから返ってこなければ実装されている回数リトライを繰り返し SYN を送ります。最大リトライ回数に達すると端末は接続の失敗として扱います。
今回取得したデータから Windows Vista はサーバーもしくはネットワークから何かしらのエラーを受け取らない限り
- 3回リトライを行う
- 3回リトライでSYN-ACKを3,6,12秒待つ
今回の場合、対象となる DNS 名に2つの IPv6 アドレスが付いているので 42 秒 IPv6 での接続を試みた後 IPv4 のアドレスに対して接続を行う事になります。
この timeout の規定は RFC2988 や RFC6298 にあります。
また、「もっと短くすれば良いのに」と思わる方も多いかもしれません。極端に短くすると何が起こるかを考えてみましょう。
光は1秒に地球を7周半回る速度で進みます。ですので、地球の反対側と通信するにはあらゆるオーバーヘッドや通信に載る情報量を除いても少なくとも片道で 133ms、往復で 266ms の RTT (Round Trip Time)が発生することになります。これより短くするとそもそも物理的に通信できないという状況になります。もちろん、実際には途中の機器や構成やパケット長にも影響を受けるのでもっと長い時間が必要になります。余談ですが月までは 1.28光秒の距離があるので、少なくとも2.56秒以上返事を待たなければなりません。
これは最短距離をあらゆるオーバヘッドを無視した値です。この値をどうするかは使われ方に強く依存するため安易にまた極端に小さくすれば良いという判断をしにくい要素になります。
今更 ?
この問題はいつ頃から認識されていたのでしょうか ?
実はかなり古くから認識されていました。少なくとも 2006年にネットワークに携わるエンジニアが会す JANOG17 という Meeting でこの問題が指摘されています(URL)。IPv6 PJ 内でも IPv6 への対応を考慮する上でこの問題は幾度となく話題に上がっています。その時点から数えても既に 6年が経過していますが残念ながらこの問題を解決する具体的な解決策はまだ確立していないようです。
この状態のまま IPv4 インターネットと呼ばれるネットワークで利用される IPv4 アドレスを管理する団体の割り当て在庫が枯渇し、新たな割り当てが出来なくなりました。俗に言うアドレス枯渇と呼ばれている状況です。さらに IPv6Day や IPv6Launch というイベントが行われ、既存の IPv4 インターネットに加え、IPv6 インターネットを利用する状況が生まれ問題がより具体的に顕在化しました。
この状況に対し、少なくとも問題となる現象を回避するための施策の検討が進んでいます。
IPアドレス選択時に使用するポリシーテーブルの設定
まず、IPv6 の仕様において規定されている端末の優先順位を変更する対応をご説明します。この対応は前述の RFC3484 にある Prefix Policy Table の設定の変更によって実現します。
上記の送信元アドレスの選択にて発生する問題の解決策として、一部のOSでは、ユーザーの手によるポリシーテーブルの設定が可能となっており、これによって優先順位を設定することが可能です。
まず、設定されている Prefixpolicy の状態を確認します。
C:\>netsh interface ipv6 show prefixpolicies
アクティブ状態を照会しています...
優先順位 ラベル プレフィックス
---------- ----- --------------------------------
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
20 3 ::/96
10 4 ::ffff:0:0/96
5 5 2001::/32
C:\>優先順位(precedence)は数値が大きいほど高くなり、ラベルは断片化したアドレス集合(Prefix)をまとめるための ID となります。 ここで、以下の二つのネットワークは、そのアドレス空間に対してのみ到達性が保障されている独立したネットワークとします。
- 1. 2001:db8::/38
- 2. 2001:db8:f000::/40
- Source Address Selection Rule 6
Rule 6: Prefer matching label. If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then prefer SB. - Destination Address Selection Rule 5
Rule 5: Prefer matching label. If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) = Label(DB), then prefer DB.
以下にWindowsでの設定コマンドを記載します。
netsh interface ipv6 add prefixpolicy 2001:db8::/40 40 6
netsh interface ipv6 add prefixpolicy 2001:db8:100::/40 40 6
netsh interface ipv6 add prefixpolicy 2001:db8:200::/40 40 6
netsh interface ipv6 add prefixpolicy 2001:db8:300::/40 40 6
netsh interface ipv6 add prefixpolicy 2001:db8:f000::/40 40 6また、この設定を行うに当たっては、それぞれのPCにおいて接続されるネットワークの到達性を全て把握した上で、各自設定する必要があります。
さて設定を行ったら設定内容を確認します。
C:\>netsh interface ipv6 show prefixpolicies
アクティブ状態を照会しています...
優先順位 ラベル プレフィックス
---------- ----- --------------------------------
50 0 ::1/128
40 1 ::/0
40 6 2001:db8:300::/40
40 6 2001:db8:200::/40
40 6 2001:db8:100::/40
40 6 2001:db8:f000::/40
40 6 2001:db8::/40
30 2 2002::/16
20 3 ::/96
10 4 ::ffff:0:0/96
5 5 2001::/32
C:\>もし、間違えた設定があればそのプレフィックスを指定し削除します。
例えば 2001:db8:f000::/40 を削除するのであれば
C:\>netsh interface ipv6 delete prefixpolicy 2001:db8:f000::/40
OK
C:\>netsh interface ipv6 show prefixpolicies
アクティブ状態を照会しています...
優先順位 ラベル プレフィックス
---------- ----- --------------------------------
50 0 ::1/128
40 1 ::/0
40 6 2001:db8:200::/40
40 6 2001:db8:100::/40
40 6 2001:db8::/40
40 6 2001:db8:300::/40
30 2 2002::/16
20 3 ::/96
10 4 ::ffff:0:0/96
5 5 2001::/32
C:\>この様に複数のネットワークに接続しその優先順位を制御したい場合、IPv6 の仕様ではそのネットワークの構成(プレフィックスの集合)を把握しその端末の利用者が個々に手動で設定する必要があります。残念ながら、Prefix Policy Table の設定を自動化する仕組みはありません。
また、一般的に利用されている全ての環境で設定が可能ではないのも大きな問題かと思われます。実際にはMacOSXおよびiOS、Androidではユーザが設定を行うインターフェースがありません。
以上を考えると、この操作を必要とする全てのユーザーに対してこの対応を行うのは設定難易度の高さ、設定に必要とする情報、環境の問題等を踏まえ現実的ではないと言わざるを得ません。
TCP RST で遅延時間を小さくする
一部のキャリアでは具体的に接続の遅延の問題に対する施策を行っているようです。その一つに TCP RST を送る事で端末の接続失敗の判断を早めるという手段をとっています。その接続シーケンスを実際に採ってみました。
このように、ネットワークから能動的に TCP-RST を送る事によって端末の connect() を失敗させフォールバックを早めるという対応が行われているキャリアが存在するようです。
ICMPv6 ではなく TCP-RST が使われるのは恐らく ICMPv6 Error に対する挙動が OS によってまちまちであり確実に connect() を失敗させる方法として TCP-RST を利用している苦肉の策と思われます。
AAAA filter (DNS 名に対する IPv6 アドレスを filter する)
AAAA filter は IPv4 (A) と IPv6 (AAAA) の両方を持つDNS 名に対する 問い合わせに対し、端末からの問い合わせにが IPv4 での DNS Request であれば IPv6 Address (AAAA)を返さないというものです。この対応が行われるとある DNS 名に対してそれを管理する組織が IPv6 Address (AAAA) を設定しても、AAAA filter が設定されている DNS Server は端末からの IPv4 での DNS Request に対して IPv6 Address を返さず IPv4 Address (A) のみしか返しません。端末はその DNS 名に対して IPv6 Address が存在しないと認識し、IPv6 での接続(の試行)が行われず遅延が発生しないという状態になります。
逆にいえば、DNS の問い合わせが IPv4 で行われる限り IPv4 (A) と IPv6 (AAAA) の両方を持つ DNS 名に対して IPv6 で接続される事は無いという事になります。
端末の IPv6 機能を無効にする
仮に端末がキャリアサービスを利用しないのであれば IPv6 を無効にすると言う手段があります。ただし、残念ながら一部の OS ではその端末の利用者が IPv6 を無効にできないように実装されているようです。
特に日本で多く発覚している問題なのか
解説した問題は IPv6 というプロトコルをある構成で利用すると問題となる事象が発生するというものでどこで起きてもおかしくは無いものです。これらの問題とそれを回避する努力は特に日本で多くある事象と言われています。多分に憶測になってしまいますが何故特に日本でこういった事が起きるのでしょうか。
IPv6 を利用/活用すると言う事
まず、IPv6 というプロトコルを利用/活用する とはどういうことかを考えてみます。これは何らかのネットワークに依存しない話になります。まず、通信キャリアが自営網の中でのサービス事業で IPv6 という プロトコル を利用するという努力が行われ、IPv6 という プロトコル を活用したサービスとネットワークが出来あがったとします。
その後で IPv6 インターネットと呼ばれるネットワークが広がりキャリアや CSP 等がその上でサービスを繋ぎ始めたとします。さらに、DNS の名前空間が既存の IPv4 インターネットと呼ばれるネットワークと混ぜられたとします。
この時点で、前述の問題その1、俗に言われるフォールバック問題や閉域網問題と呼ばれる事象が発生し遅延すると言う問題が 発覚 します。問題そのものは IPv6 の仕様に潜在していました。それが、IPv6 と呼ばれる技術を検証/活用が日本が先行した結果 後から来た IPv6 インターネットによって露呈した という事です。
この仮説は日本では IPv6 というプロトコルの活用が IPv6 インターネットと呼ばれるネットワークが広がる前から進んでおり、利用者が意識していない中で着実に IPv6 というプロトコルの利用が広がっていた事が IPv6 の仕様によって IPv6 インターネットと呼ばれるネットワークの広がりによって問題となる事象が発生したというものという推測です。
今日の IPv6 と、明日の IPv6
現状の IPv6 というプロトコルはそのアーキテクチャそのものを原因として、ある構成での利用で通信における接続で問題となる事象が発生すると考えています。それは構成を制限する事で 回避 する事は出来るかもしれませんが、あくまでも 回避 であって 解決 ではありません。
この状態でサービスを IPv6 インターネットに接続し提供するのは、より後に引けない状態を作り 将来の IPv6 と呼ばれるものの本来の可能性を閉じる事になりかねないと考えています。
同時に、前提としている 守るべきはサービスを満足に提供し続ける事である というスタンスでも 現状の IPv6 インターネットでのサービスの提供を急く事が肯定されません。
今行うべきは 現状の IPv6 と呼ばれるものそのものの問題を変に煽られず誰かのせいにするのではなく正しく認識し、きちんと向かい合いながら 将来の IPv6 での解決とそこまでに結び付く現実的な回避策の両方を模索するものと考えています。
今後この問題は、接続キャリアや ISP の協力を仰ぎ連携を行い検証/検討を行いながら具体的な実験等を行い問題点のより具体的な整理と解決方法の模索を行っていきます。
また、その内容はこちらの Blog でも紹介していきたいと考えております。
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました
