20120516 v6opsf-ngn final

Copyright © 2012 INTEC Inc.

IPv6Launch に向けたNGNの課題と対策について

平成２４年５月１６日株式会社インテック

廣海緑里[email protected]

Copyright © 2012 INTEC Inc. 2/11

2012 年 6 月 6 日以降

IPv4

IPv6

：

通信事業者

ユーザ環境通信環境コンテンツ環境

ユーザ環境と通信環境の IPv6 対応は進んでいるので、残すはコンテンツの IPv6 対応と言われていたが

…

IPv6 でアクセスできるサイトが増える！

「三方良し」なのでは？


日本は鎖国？鎖国回避は NTT 次第？

Your eyes only


クライアント

クライアントからみた IPv6 対応時の動作概要と注意点

• IPv4/IPv6 デュアルスタックのクライアントの挙動

WEBサーバ192.0.2.812001:DB8::80

ネームサーバ192.0.2.532001:DB8::53

ロードバランサファイアウォール等

IPv4 IPv6

www.example.com IN A 192.0.2.80 IN AAAA 2001:DB8::80

1. 接続先の名前解決をする2. 接続先リストを作り、リストに従って接続を試みる3. 接続できるまで、順にリストを辿る4. 応答があった接続先とデータコネクションを確立す

る

①

②

マルチプレフィックスという前提

[TCP] IPv6-IPv4 フォールバックの概念の導入③

[DNS] IPv6-IPv4 フォールバックの概念の導入


観測されている問題発生箇所と問題点

クライアント

WEBサーバ192.0.2.812001:DB8::80

ネームサーバ192.0.2.532001:DB8::53


IPv4 IPv6


① ②

③

④

① 名前解決における問題 EDNS0未対応、複数レコード登録による参照上限値との不具合 A/AAAAの追加とCNAMEによる間違った参照 IPv6の実装上の問題（ v6トランスポート未サポート、壊れた応答）

② クライアントの問題 DNS参照のフォールバックに問題のあるリゾルバやリゾルバ結果を使わないプログラム優先順序処理やRFC3484デフォルトポリシーテーブルを持たないクライアントマルチプレフィックス未対応、 IPv6未対応のプログラム

③ 接続性とTCPフォールバックの問題到達性のない IPv6ネットワーク（閉域網や ULA）の存在と接続遅延

④ コネクション確立上の問題 TCPソフトエラーの扱いによるフォールバック遅延（ RFC5461で Informational RFC として遅延対策が提案）

⑤ 古い実装や問題を抱えた運用による問題 Neighbor Discovery の失敗を待つonlink assamption 仕様 6to4などのトンネルプロトコル利用 Path MTU ディスカバリを阻害するミドルボックス、 Path MTU調整ができない端末 VPNやウィルスチェック機構などによる IPv6 通信の阻害や遅延 Happy Eyeball など新しい提案対応

⑤


フォールバック問題と接続環境

IPv4 サーバ IPv4/IPv6 サーバ

IPv4 環境 IPv4/IPv6 環境

IPv4 環境 IPv4/IPv6 環境

IPv4 端末 IPv4 IPv4 IPv4 IPv4

IPv4/IPv6 端末 IPv4 IPv4 IPv6→IPv4 IPv6 優先

■ 標準的な繋ぎ方

！

サーバと端末がデュアルスタックの場合、接続環境（ IPv4+IPv6 ）もデュアルスタックになっていれば問題は少ない

IPv4 と IPv6 の接続環境を提供する事が解決策


IPv6 対応サービス提供中の通信事業社別の状況

NTT 東西 KDDI SoftBank NTT ドコモ

トンネル？フレッツ光ネクスト(NGN/PPPoE)

Yahoo!BB 光/Yahoo!BB ADSL(6RD)

ネイティブ？フレッツ光ネクスト (NGN/IPoE)

AU ひかり Yahoo!BB 光 with フレッツ( 光ネクスト )

LTE( ＋ mopera U)

ISP 等の状況の一例

・OCN IPv6IPv4

上に L2TP トンネルを用いて IPv6 サービスを提供 (http://www.ocn.ne.jp/ipv6/)・ DTI Feel6

http://start.feel6.jp/・ 6to4 （無償サービス）

Tokyo 6to4(http://www.tokyo6to4.net/) 等で提供・グローバル・固定 IPv6 アドレス割当型トンネル接続実験サービス（無償サービス）

http://v6ip.tsukuba.wide.ad.jp/regist/terms.aspx

NGNv6系サービスか、 ISPの v6サービスへの加入が伸びていれば問題ない


国内インターネットアクセス構造ざっくり版

KDDI-NGN

SOFTBANK-NGN

NTTドコモ

NTT東西-NGN

VNE

CATV系

電力系FTTH

ADSLPSTNISDN

AUソフトバンク

モバイル

ISP

インターネット

固定

移動体

インターネット事業者接続

ユーザ

ISPインターネット接続

ISP ISP

※　 KDDI や softbank ネイティブサービスは、 NTT の NGN 回線+VNE+ISP

IPv6でのアクセスに問題のある区間がある！

＝無問題


回線ごとの IPv6 対応サービス状況とシェア

• 真の IPv6 ユーザは、 720/17265.9(4%)– 人口を超える回線に影響

回線種別法人向け個人向け影響（個人）

専用線 , イーサ接続など ○

FTTH ○ ○ IPv4 ： 1400万回線 /2020万回線IPv6 ： 720万回線/2020万回線(FTTH,2011/3)

ADSL,ISDN,PSTN ○( トンネル ) ○( トンネル ) 706万回線 (DSL)3284万回線(PSTN/ISDN)

CATV 591万回線

携帯電話系 ○(WiFi及び LTE ） ○(WiFi及び LTE ） 10474万回線

WiFi 、 WIMAX 0.9万回線 (FWA)190万回線 (BWA)

VPNサービス ○ ○

既存通信＋トンネル（ 6to4 など）

○ ○

○：それぞれ主たる対象として提供中のもの（ 2011 年 12 月現在、 FTTH のみ 3 月）


NTT の NGN のマルチプレフィックス問題とは

クライアント

WEBサーバ192.0.2.812001:DB8::80

ネームサーバ192.0.2.532001:DB8::53


IPv4 IPv6


① ②

③

④

① 名前解決における問題 EDNS0未対応 A/AAAAの追加とCNAMEによる間違った参照 IPv6の実装上の問題（ v6トランスポート未サポート、壊れた応答）

② クライアントの問題 DNS参照のフォールバックに問題のあるリゾルバやリゾルバ結果を使わないプログラム優先順序処理やRFC3484デフォルトポリシーテーブルを持たないクライアントマルチプレフィックス未対応、 IPv6未対応のプログラム

③ 接続性とTCPフォールバックの問題到達性のない IPv6ネットワーク（閉域網や ULA）の存在と接続遅延

④ コネクション確立上の問題 TCPソフトエラーの扱いによるフォールバック遅延（ RFC5461で Informational RFC として遅延対策が提案）

⑤ 古い実装や問題を抱えた運用による問題 Neighbor Discovery の失敗を待つonlink assamption 仕様 6to4などのトンネルプロトコル利用 Path MTU ディスカバリを阻害するミドルボックス、調整ができない端末 VPNやウィルスチェック機構などによる IPv6 通信の阻害や遅延 Happy Eyeball など新しい提案対応

⑤

主にフォールバックに時間がかかることを問題視


回線種別サービス名称基本対策

ISDN フレッツISDN

TCP リセット

ADSL フレッツADSL

TCP リセット

FTTH フレッツ光 TCP リセット

・ IPoE(NTT 閉域網のアドレスを使わない )・ PPPoE(ISP アドレスと NTT 閉域網アドレスを NAT66変換 )・ TCP リセット

NTT 東日本のサービスと対象

• NTT 東日本が展開する従来のフレッツサービスで発生– 「フレッツドットネット」サービス用の IPv6 アドレスが割

り当てられ、グローバル IPv6 インターネットに接続できない

IPv6Internet

IPv4Internet

IPv6 閉域網

IPv4Internet

IPv4Internet

IPv4Internet

IPv6 閉域網

IPv6 閉域網

IPv6Internet

IPv4Internet


いろいろな対策• NTT東西

– フレッツ ISDN/フレッツADSL/Bフレッツについては、 TCPリセットを返し、強制的に IPv4にフォールバックさせる（①）

– フレッツ光ネクスト (IPoE) では、NTT閉域網の IPv6アドレスを使わせない– フレッツ光ネクスト (PPPoE) では、アダプタでNAT66変換を行う

• ISP– ISPのスタブDNSでAAAA フィルタ適用（ IPv4でAAAA を問い合わせた場合に IPv6アドレスを返さない。 IPv6

トランスポートでの参照には応答する BIND9.7.0b2 等で実装されている。）（②）• コンフィグオプション（ -enable-filter-aaaa ）と named.conf の filter-aaaa-on-IPv4

– ユーザに参照させるDNSサーバをサービス毎に分けて、必要なユーザのみ AAAA フィルタをする（③）• CPE/HGW

– DNS中継においてAAAA フィルタ機能のあるCPE の導入（④）• クライアントに対して AAAAの応答を返さない

• Googleなど（⑤）– IPv6ホワイトリストで、品質の良い（Google基準） IPv6接続には IPv6での通信を許可する仕組みを導入– トランスポートが IPv4しかないスタブ DNSからのAAAA クエリをフィルタ

• Happy Eyeball手法（⑥）– アプリケーションで IPv6の応答が返ってくる前に IPv4も試す

• ポリシーテーブル変更（⑦）– IPv4枯渇タスクフォース等から変更ツール提供– コマンドラインから変更できるOSもある（ Windows のnetsh 等）

• カスタマーサポート等– JAIPAから対応指針など

IPv6Internet

IPv4Internet

IPv6 閉域網

DNS

DNS

DNS

CPECDNS

NTT 東西

CSP

DNS

ISP

ISP

DNS

① ②③

④ ⑤⑥⑦


継続されると思われる問題（ IPv6 運用研鑚が必要）

• NTT-NGN 以外の IPv6 が閉域網の場合 (ULA)– ULA の規定では、 RCODE 3(NXDOMAIN) を返す仕様なのでフォールバックできないかも

• ロードバランサなどのミドルウェアの DNS の実装不具合の影響によってフォールバックできないことがある– AAAA がくると無応答になったり、 NXDomain や ServFail を返し、フォールバックできな

い• フォールバックしないアプリケーション、開発言語もある

– シングルスタックで稼働する「 IPv6 モード」、そして IPv4 優先• 「 Happy Eyeball 」の限界

• Chrome 11 や Firefox10 で実装• Unhappy な事例もある（ https://labs.ripe.net/Members/emileaben/hampered-eyeballs ）

や、 IPv4 で接続後は IPv4 が選択され続けるものや、名前解決結果まで IPv4 優先になるもの• WEB アクセス以外のサービスではこの手法導入が難しいケースもある

• TCP ソフトエラーの場合のフォールバック遅延

・W6L対応にあたっては、暫定解による対応・ IPv6の導入促進の根本的な解決　　　　　　　　　　を上手に組み合わせる必要がある


フィルタすることの責任

・きちんとした管理と運用のもとで導入・必要なくなったら速やかに運用停止・トラブルシュート？・運用監視の複雑化？


STOP! ガラパゴスSTOP! 無理が通れば道理引っ込む

World IPv6 Launch を迎えるにあたって、各事業者本当のところはどうするのか？

それでも IPv6 対応には積極的になれないのだろうか？

NTT 東西はULA （相当）に

リナンバできないのか？

ISP は IPv6 サービス展開をどう考えているのか？

今後も無理な運用技術をはさんでIPv4 を維持するのは健全なのか？

サービス設計ミスは是正されない？

RIPE のデュアルスタックなし、一足飛びに IPv6 導入というのは日本では無理？

制度設計は見直しされない？

Technology

20120516 v6opsf-ngn final