ION Tokyo

Panel Discussion - IPv6 in Asia Pacific: Untangling the Web

2014.11.17Kaname Nishizukakaname@nttv6.jp / @__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