IPv6化の壁（DualStack対応とTunnelの課題）

こんにちは、IPv6プロジェクトスタッフの松本拓也です。
今回は、私共も含めContents Service Provider (以下、CSP)がなぜ安易にDualStack対応できない理由とその背景にかかわるTunnelの問題について具体的に説明したいと思います。

DualStack対応時の問題点

サーバーをDualStack化した場合、下記の2つの問題が発生する恐れがあります。

• 一点目は、Clientからサーバーへのアクセスが不可になってしまう。
• 二点目は、ClientからサーバーへのアクセスがTunnel経由のIPv6アクセスとなってしまう。

それぞれについて、下記に説明いたします。

Clientからサーバーへのアクセスが不可になってしまう（もしくは遅延が発生）

過去のBeaconテストの結果により下記の結果が出ております。

• 0.23％ のユーザーがアクセス不可
• Opera以外の原因により、0.17％のユーザーがアクセス不可

実際にどのような場合にこのようなことが起きるのかを考察してみたいと思います。

サーバー側がDual Stack化することにより、ユーザーがアクセス不可となる原因は、ユーザーの環境、アクセス環境に よってさまざまであるため、すべてを把握しきれているわけではありませんが、以下のようなケースが想定されます。

• Closed な IPv6 network 問題
  • ユーザー側による問題
    

    

    ユーザーのネットワークもしくはホスト側でIPv6 Globalアドレスを割り当てているにもかかわらず、IPv6 Internetに接続できない場合。
    ⇒ユーザーの設定ミスや設定不備による場合が考えられます。
  • アクセス網側の問題
    

    

    Clientに対して、アクセス網側からRAによりIPv6 Globalアドレスが割り当てられているにもかかわらず、IPv6 Internetに接続されていない場合。
    ⇒ユーザーが意識せずにこのような状態となっている可能性があります。
  • その他
    • IPv6 Transport経由でDNSが解決できないなど。

• アプリケーション、基本ソフト(OS)による問題
  • アプリケーションによる問題（Operaなど）
    ⇒IPv6に未対応なアプリケーションが悪影響を及ぼすケース
  • OSによる問題（Mac OS X）など
    ⇒RFCに従っていない実装を持つOSがIPv4よりもTunnel経由のIPv6を優先するケースなど

ClientからサーバーへのアクセスがTunnel経由のIPv6アクセスとなってしまう

一般的な環境では、rfc3484のアルゴリズムに基づき、デュアルスタックのサーバーに対しては、
基本的にIPv4アクセスの方が、Tunnel（6to4, Teredo）経由のアクセスよりも優先されます。以下に例を挙げて説明いたします。

• Default Address Selection
  Windows系のOSではデフォルトで下記のような、Prefix policy tableを持っており、RFC3484のルールとこの Tableに基づき、Destination と Source アドレスを決定します。
  つまり、Source address selection のルールにより、すべてのDestinationに対するSourceアドレスを決定し（あるDestinationに対するSourceをSource（D）とします）、 Source（D）からDestination address selectionのルールにより、Destinationアドレスを決定します。
  • Windows系ClientのPrefix policy table

    Precedence   Label     Prefix
    ----------   -----   --------------------------------
    5              5          2001::/32 ←Teredoアドレス
    10             4          ::ffff:0:0/96　←IPv4-Mapped Address（=IPv4アドレス）
    20             3          ::/96
    30             2          2002::/16 ←6to4アドレス
    40             1          ::/0　 ←IPv6アドレス
    50             0          ::1/128

  • RFC3484 の source address selection アルゴリズム

    Rule 1:  Prefer same address.
    Rule 2:  Prefer appropriate scope.
    Rule 3:  Avoid deprecated addresses.
    Rule 4:  Prefer home addresses.
    Rule 5:  Prefer outgoing interface.
    Rule 6:  Prefer matching label.
    Rule 7:  Prefer public addresses.
    Rule 8:  Use longest matching prefix.

  • RFC3484 の destination address selection アルゴリズム

    Rule 1:  Avoid unusable destinations.
    Rule 2:  Prefer matching scope.
    Rule 3:  Avoid deprecated addresses.
    Rule 4:  Prefer home addresses.
    Rule 5:  Prefer matching label.
    Rule 6:  Prefer higher precedence.
    Rule 7:  Prefer native transport.
    Rule 8:  Prefer smaller scope.
    Rule 9:  Use longest matching prefix.
    Rule 10: Otherwise, leave the order unchanged.

  • 例
    • Destination アドレス
      下記のようにAとAAAAを持つデュアルスタックサーバーを仮定します。

      v46.my.yahoo.co.jp.     15M IN A       124.83.175.156
      v46.my.yahoo.co.jp.     15M IN AAAA     2400:7e00:1:1607:1181:5100:25:4057

    • 例1：Source アドレスがIPv4 Global / IPv6 Global の場合　⇒IPv6が優先

      IPv4: IPv4 Global
      IPv6: IPv6 Global

      この場合は、Destination address selection の Rule1～5まででは
      Rule6 の "Prefer higher precedence" と、Prefix policy tableにより（Precedenceが IPv6=40 に対して IPv4=10）IPv6のDestinationアドレスが優先されます。

    • 例2：Source アドレスがIPv4 Global / 6to4 の場合　⇒IPv4が優先

      IPv4: IPv4 Global
      IPv6: 6to4 （2002::/16）

      この場合は、Destination address selection の Rule5の "Prefer matching label" により、IPv4が優先されます。
      具体的には、

      label	Source（D）	Destination
      4	IPv4 Global	124.83.175.156
      2	6to4	－
      1	－	2400:7e00:1:1607:1181:5100:25:4057

      以上のように、Source（D） と Destination のlabelが一致しているのが、IPv4のみとなりますので、Rule5によりIPv4の通信が優先されることになります。

    • 例3：Source アドレスがIPv4 Private / 6to4 の場合　⇒IPv6が優先
      通常、6to4による通信は間にNATが入った場合には動作しません。しかしながら、最近のブロードバンドルーターでは、ルーター側で6to4 Tunnelをサポート
      しているものもあり、NAT配下でも6to4が利用できる環境が出てきています。6to4対応のルーターの例としては、Apple社のTime Capsuleなどがあります。

      IPv4: IPv4 Private
      IPv6: 6to4 （2002::/16）

      この場合は、Destination address selection の Rule2 の Prefer matching scope により、IPv6が優先されます（RFC上は）
      IPv4およびIPv6のScopeは具体的には下記のようになっています。

      scope	IPv4	IPv6
      link-local	169.254/16, 127/8	FE80::/10, ::1
      site-local	10/8, 172.16/12, 192.168/16	FEC0::/10 （Deprecated）
      global	上記以外のアドレス	上記以外のアドレス

      この例では、

      scope	Source（D）	Destination
      site-local	IPv4 Private	－
      global	－	124.83.175.156
      global	6to4 （2002::/16）	2400:7e00:1:1607:1181:5100:25:4057

      ということで、Source（D） と Destination のscopeが一致しているのが、IPv6のみとなりますので、Rule2によりIPv6の通信が優先されることになります。 しかしながら、site-local scope はIPv6では廃止 （Deprecated） されており、その辺が関係しているのか（確認は取れてませんが）、 OSによって、実際に挙動（解釈）が異なり、具体的には下記のような動作をしていました。
      ※Time Capsule配下のユーザー環境でのテスト結果。ユーザー環境や設定によって優先度が変わる恐れがあります。

  • 各OSにおける6to4アドレスが付与されている環境化における、IPv4/IPv6 通信の優先度

    環境	Windows 7	Mac OS X 10.6	Ubuntu 10.04	FreeBSD-8.0
    IPv4グローバル/6to4アドレスの環境下	IPv4グローバルを優先	6to4アドレスを優先	IPv4グローバルを優先	IPv4グローバルを優先
    IPv4プライベート/6to4アドレスの環境下	IPv4プライベートを優先	6to4アドレスを優先	6to4アドレスを優先	IPv4プライベートを優先

    ※ 赤字がRFCと異なる挙動
    この結果を見ると、Ubuntu はRFCに厳密に基づいて動作しているように見え、WindowsとFreeBSDは、"IPv4プライベート/6to4アドレスの環境下" においてはRFCに反した挙動を、Max OS X においては、"IPv4グローバル/6to4環境下" においてはRFCに反した挙動を示していました。とはいえ、IPv4のプライベート・グローバル環境にかかわらず、現状では6to4のTunnel経由の通信よりもIPv4の通信の方が信頼性・品質面で有利であると言えるため、WindowsやFreeBSDはより実践的な挙動をしていると言えます。

アクセス不可となる前者の場合と比べて、Tunnel経由の通信になるだけだったら大した問題ではないのではないか、と思われるかもしれません。確かに通信内容によっては、例えば遅延や速度をあまり気にする必要がないような通信であれば、Tunnel経由でも問題ないかもしれません。しかしながら、私共のようにコンテンツの表示速度の品質が求められるようなサイトにおいては、致命的になる恐れがあります。以前は早かったのに、急に遅くなった場合（IPv4からTunnel経由のIPv6の通信に切り替わった場合など）ユーザーから見れば、CSPのサービス品質が低下したと思われてしまうでしょう。下記に具体的な問題点についてまとめます。

• 遅延が大きくなる。
  ⇒例えば6to4による通信の場合は、プロトコルの仕様上、ベストパスで通信する可能性が低いため、IPv4よりも遅延が大きくなってしまう。
• オーバヘッドが大きくなる。
  ⇒Tunnelの場合、IPv4でカプセリングされるため、余計なオーバヘッドが大きくなり、結果として体感的に遅く感じる場合がある。
• MTU問題
  ⇒上記と関連しますが、Tunnelにより、MTUが変わり、Fragmentが発生する可能性があります。
• そもそも通信できない
  ⇒6to4やTeredoなどでは第三者のTunnelサーバーを経由して通信を行うため、Tunnelサーバーの設定や状況によっては、日本への経路を
  絞っている可能性もあり、実際に通信できなくなったケースもあります。
• セキュリティ
  ⇒第三者が立てたトンネルサーバー経由の通信の中身を見ることは、暗号化された通信でない限り、そのサーバーの管理者であれば容易にできてしまいます。

まとめ

今回、サーバーをデュアルスタック化した場合とその際に発生する可能性があるTunnelの問題点について述べさせていただきました。このような問題の解決策については、私共でも模索中の段階ですが、引き続き原因の調査と改善策の検討を行っております。しかしながら、ユーザーやアクセス環境が壁になっている場合もあり、それを改善していく取り組みも必要ではないかと思います。そのようなIPv6化の壁となっている部分を取り除くためにも、業界関係者と連携を取りながら、IPv6化を進めていきたいと思います。