ION Tokyo
Panel Discussion - IPv6 in Asia Pacific: Untangling the Web
2014.11.17Kaname [email protected] / @__kaname__
自己紹介
2006 年 NTT コミュニケーションズ入社。 OCN アクセス系ネットワークの設計に従事した後、 大規模 ISP 向けのトータル保守運用サービスを担当。 現在、 DDoS 対策ソリューションの開発および、 CGN 関連技術の IETF 標準化活動に従事
【社外活動】 JANOG28 実行委員長 JANOG30 会場運営委員長 JANOG32 「 HTTP 2.0 のインパクト」登壇 HTML5 Conference 2013 NW チーム Interop2014 「 IPv6 ホットトピックス」登壇
2
IPv4 アドレスに依存した世界の延命方法
IPv4 アドレス移転• 市場が既に存在する• 市場価値は、 約 1000 円 /IP
3
IPv4 アドレス共有• Carrier Grade NAT
(CGN)• すでに主にモバイル
事業で使われている。
4
CGN Update
実網 (特にモバイル /MVNO事業 )でディプロイが進む
RFC発行 [RFC6888]
ポート消費傾向の変化
2010 年～
2013 年 4 月
2010 年～
モバイル事業者 (docomo, au, softbank) ： CGN 導入済
5
NTTdocomo テクニカルジャーナル Vol.18https://www.nttdocomo.co.jp/binary/pdf/corporate/technology/rd/technical_journal/bn/vol18_3/vol18_3_038jp.pdf
※2010 年当時は CGN は LSN(Large Scale NAT) とも呼ばれていました。今では、 CGN/LSN と併記するケースが多いです。
MVNO 事業者：一部で CGN 導入2013.07.22
MVNO 事業者のワンコイン SIM も、プライベートアドレスで提供
6
MVNO 事業者：一部で CGN 導入
OCN では固定・モバイル含めて、 CGN は現在導入しておりません。 ※実験・検証は継続しております。
7
8
RFC発行 [RFC6888]
2013 年 4 月
広義の CGN ： AFTR(DS-lite) ・ NAT64 ・ PLAT(464XLAT) を含む。狭義の CGN ： NAT444 を指す。本プレゼンでは NAT444 について話すが RFC のスコープは、広義の CGN である。
RFC の発行 (2013.04)
RFC6888 (BCP127)Common Requirements for Carrier-Grade NATs(CGNs)
CGN = 大規模 Source NAT(NAPT) 装置• キャリアクラスのキャパシティを持つこと
巨大なプールアドレスと NAT テーブルを持てる 冗長構成が取れる
• アプリケーションに対して ( 可能な限り ) 透過であること ALG(Application Gateway) 機能を持つ Fullcone NAT である
• ユーザ特定が可能であること NAT ログを保持 ( 動的割当 ) または 静的割当
• ユーザの公平利用が担保できること 公平なアドレス・ポートの割当9
10
ポート消費傾向の変化2010 年～
ポート消費傾向の変化
11
http://www.nttv6.jp/~miyakawa/IETF72/IETF-IAB-TECH-PLENARY-NTT-miyakawa-extended.pdf
2009 年
次世代 Web 技術による状況の変化
12
SPDY
SPDY 対応による消費セッション数の減少
SPDY( および HTTP/2) : 複数のリソースダウンロードを1 つの TCP セッションで行う。
Google MAP 閲覧時の同時セッション数
13
非 SPDY(IE10) vs SPDY(firefox21.0)
1 10 19 28 37 46 55 64 73 82 91 100 109 118 127 136 145 154 163 172 181 190 199 208 217 226 235 244 253 2620
10
20
30
40
50
60
70
80
IE10.pcap
firefox.pcap
[sec]
[同時セッション数 ]
3分の 1以下
モバイルアプリケーション NAT 消費数
対象アプリケーションiPhone Android SPDY対応
TCP UDP TCP UDP Line 6 11- - ×Skype 10 177 40 199 ×Google Map 6 0 6 0 △Gmail 10 0 4 0 △Google Search(Voice) 18 0 11 0 〇Twitter 11 0 19 0 △Facebook MSG 10 0 10 0 △Facebook App 38 0 22 0 〇Dropbox 8 0 21 0 ×Evernote 9 0 21 0 ×Puzzdra 10 0 5 0 ×Navitime 15 0 11 0 ×Apple.com 20 0 15 0 ×Mizuho bank 25 0 30 0 ×Amazon 26 0 28 0 ×iTunes store 43 0- - ×Yahoo.co.jp 53 0 55 0 ×Rakuten 64 0 48 0 ×Youtube 25 0 32 0 △Niconico Douga 69 0 30 0 ×Ustream 160 0 123 0 ×
SPDY が CGN に与えたインパクト
1 アプリケーションあたりの NAT エントリ消費数は、SPDY 対応によって減少• IPv4 アドレス共有技術の設計に大きな影響を与え
ている。 CGN の収容効率の向上
1IPv4 アドレスあたりの NAT エントリ消費数は、• 固定網
Ave. 100 Max. 1000
• モバイル網 Ave. 50 Max. 500
15
16
モバイル網におけるモデル
1 ユーザあたり 200,000 ユーザ
平均ポート数： 50
上限ポート数： 500
CPS ： 0.1 ～ 0.2(Connection/Sec)
ログ /day ： 5MB
必要セッション性能： 10M
プールアドレス数： 200 個※ 固定割当の場合は、 10倍
CPS ： 20k ～ 40k(Connection/Sec)
ログ /day ： 1TB
CGN に求められる性能
17
ここまでが、前半 (5 分 ) の” CGN 賛成派としての”ポジションペーパです。
以下は、パネルの際の予備スライドです。
CGN のアプリケーションへのインパクト
18
CGNは次世代Web技術による革新を阻害する
CGN による通信影響
Google Cloud Messaging問題https://groups.google.com/forum/#!topic/android-gcm/IC2ovQhgBJA
19
Googleハングアウトが切れ
る
NAT タイムアウト値とセッションキープ
HTML5 Conference における NAT タイムアウト値設計• TCP アイドル 300秒 / UDP 300秒 / DNS 3秒
アプリケーションのセッションキープ• 更新の有無を確認するセッションが存在し、定期的
に特定のパケットが通信されて、セッションを維持し続ける。 Facebook ：約 50秒 Google Cloud Messaging ：約 15 分 (!)
CGN を導入している事業者では、 GCM の使用ポート(5528 ～ 5530) のみ、 NAT タイムアウト値を長くしている。※その他のポートは約 60秒
20
WebSocket
WebSocket• リアルタイム Web• 双方向性通信 ( サーバからの PUSH通信可能 )
NATや Firewall がある状況で、長時間接続を継続するサービスを実現するには、一定間隔でデータを送信(ping) ・返信 (pong) してセッションをキープしなければならない。※ クライアントからでもサーバからでも ping pong 可能
21
22
PUSH と端末電池消費 (WebSocket)
時間 5 10 15 20 25 30 35 40 45 50 55 60 6580
85
90
95
100
001HT001HT-WINFOBARINFOBAR-WISW11HTISW11HT-WXOOMXOOM-WXperia AcroXperia Acro-W
※１ 概ね単位時間あたり 5%程度の消費増。しかし、データサンプルが少ないため、参考程度の信頼度。※２ Websocket通信部は 60秒に一回サーバ側から ping送信を行う。
[％]
[ 分]
23
WebRTC
http://www.slideshare.net/nttwestcon/20140805-technical-descriptionofwebrtcpublicedition
24
WebRTC over IPv6
http://www.internetsociety.org/deploy360/blog/2014/08/webrtc-just-works-over-ipv6/
CGN の運用上の課題
25
法的対応・セキュリティ面には依然として問題がある
プロバイダ制限責任法と NAT ログ
(権利侵害をした ) 発信者情報の開示請求に対して、 NAT ログに基づいてユーザを特定する
CGN におけるポート割当手法とユーザ特定• 動的割当
NAT ログが必要 宛先アドレスと時間を正確に記録しておけば、送信元ポート情報
が無くても特定できる可能性がある。
• 静的割当 NAT ログが不要 送信元ポート情報が必要 ( サーバ側アプリケーションでの対応
[RFC6302])
⇒いずれにしろ、ユーザの同定が困難
26
静的割当・ポートブロック割当の問題
27
静的割当・ポートブロック割当• 通信先サーバがポート情報を保持 (RFC6302 対応 ) していな
い場合、ユーザの特定が不可能
宛先アドレスを取得すれば、同定が可能ではないか？• 結局、通信ごとのログが必要になり、動的割当の場合と同じだ
け NAT ログが必要となる。そのため、収容効率の悪い静的割当には現状ではインセンティブがない。
通信先サーバ X(RFC6302 対応 )
通信先サーバ Y(非対応 )
CGN
送信元ユーザ A
送信元ユーザ B
アドレス : ポート =A:a
B:b
変換後 P:a’
プールアドレスP
変換後 P:b’
P:a’ を通知。→ユーザ A を同定可能
P のみを通知。→ユーザ B の同定不可能
CGN とセキュリティ
28
CGN の内側から外側への攻撃に関する問題• 攻撃を受けている側からすると攻撃者の同定ができ
ない• NAT プールアドレスに対するフィルタリングにより無関係なユーザが巻き込まれる。
CGN の外側から内側への攻撃に関する問題• 1 アドレスに大量にユーザが含まれるので、攻撃の
効率が良い• NAT 後のポート番号は予測される可能性が高まる
IPv6 と CGN
29
IPv6提供によりCGNのインパクトを 30～ 40%軽減できる
HTML5 conference 2013
開催概要• 開催日： 2013 年 11 月 30日（土）
• 会場： NTT中央研修センタ• 参加人数： 1300人程度
会場ネットワークのポイント• CGN(Carrier Grade NAT) の導入• IPv6通信環境の提供
30
31
IPv6通信の割合
IPv6 の利用率• 最大 61.24%• 平均 30 ～ 40%
最大接続数• 946台
(WLC Assoc 数より )
ユーザあたりセッション数
32
8:24:00 9:36:00 10:48:00 12:00:00 13:12:00 14:24:00 15:36:00 16:48:00 18:00:00 19:12:00 20:24:000.00
5.00
10.00
15.00
20.00
25.00
30.00 sessions per user
TCP per user
UDP per user
ユーザ ( ユニーク IPv4 アドレス )毎の IPv4 セッション数は最大 30程度 【予測】
IPv4通信 : 30 port (60%)IPv6通信 : 20 port (40%)
まとめ (CGN の今後 )
33
最終的な解決策は IPv6
CGN に関する真実• 「 NAT が IPv4枯渇問題を救うわけではない」
CGN が有る世界でどのようなことができなくなっているのかを知っていただく
最終的な解決策は、端末側とアプリケーション側双方がIPv6 に対応すること
34
推奨モデル
CGN(NAT444) + IPv6 モデルの推奨 NAT444• 他の移行技術 (DS-lite, MAP-E など ) と比較して、ア
プリケーションへの影響が少ない ( と考えられる ) トンネルや v6⇔v4 変換が無い フラグメントの問題が起こらない アプリケーション側で NAT越え対策が採用されている
IPv6 の導入• 30 ～ 40% のトラフィックが IPv6通信に移行する。• NAT タイムアウト問題の回避
真のリアルタイム・双方向性通信が可能になる
• CGN ・周辺システム (NAT ログ収集 ) の負荷が減少• 使えないアプリケーションに対するクレームが減少
する。35
