2011

Transcription

1 2011 年の インターネット Kanazawa Tomoya (tomo) Yoshida yoshida@nttv6.jp Yoshinobu (maz) Matsuzaki maz@iij.ad.jp 2011/1/21 maz&tomo 1

2 概要 2011 年は IANA での IPv4 アドレスが遂に枯渇し IPv6 インターネットの本格導入が進むと言われており また日本国内でも NGN による IPv6 インターネットサービスの開始 JP ドメイン名サービスへ DNSSEC 導入と インターネット全体でも日本国内にとっても大きく変わる年 (?) かもしれません オペレーターはなにを考えて なにを行動しなくては行けないのでしょうか? 今年やらなくちゃいけないことを会場の皆さんと一緒に考えます 2011/1/21 maz&tomo 2

3 進行 ルーティングネットワーク 分 (tomo) 発表 30 分 質疑 議論 20 分 DNS2011 (+IPv6) 40 分 (maz) 発表 25 分 質疑 議論 15 分 2011/1/21 maz&tomo 3

4 ルーティングネットワーク /1/21 maz&tomo 4

5 IPv4 経路数の推移 このあたりが一般的な経路数 /1/21 maz&tomo 5

6 経路数 IPv4 経路数比較 (1) 末 : 末 : 末 : 末 : 末 : 末 : 末 : 末 : /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 /11 /12 /13 /14 /15 / 末 末 末 末 末 末 末 末 /1/21 maz&tomo 6

7 経路数 IPv4 経路数比較 (2) 末 : 末 : 末 : 末 : 末 : 末 : 末 : 末 : /17 /18 /19 /20 /21 /22 /23 /24 /25 /26 /27 /28 /29 /30 /31 / 末 末 末 末 末 末 末 末 /1/21 maz&tomo 7

8 RIR 毎の IPv4 アドレス配分状況 Historial 空間を除き APNIC 地域の /8 の保有数が 2009 年より最大 IANA Reserve RIPE ARIN APNIC 2011/1/21 maz&tomo 8

9 AP 地域の国別 IPv4 アドレス配分状況 中国 日本 韓国の伸びが大きい 韓国 日本 中国 /1/21 maz&tomo 9

10 IPv4 アドレス まだあると安心している人はもう居ませんよね? IANA プールはもうすぐなくなります 2011/1/21 maz&tomo 10

11 2005 年 8 月の IPv4 フルルート 2011/1/21 maz&tomo 11

12 2006 年 8 月の IPv4 フルルート 2011/1/21 maz&tomo 12

13 2007 年 8 月の IPv4 フルルート 2011/1/21 maz&tomo 13

14 2008 年 11 月の IPv4 フルルート 2011/1/21 maz&tomo 14

15 2010 年 1 月の IPv4 フルルート 2011/1/21 maz&tomo 15

16 2010 年 11 月の IPv4 フルルート 2011/1/21 maz&tomo 16

17 IRR fltr-unallocated object $whois h jpirr.nic.ad.jp fltr-unallocated 未割り振りの /8 を表す IRR の Object 2009 年 11 月 2011 年 1 月 21 日 filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes. filter: { /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+, /8^+} 26 個 filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes. filter: { /8^+, /8^+, /8^+, /8^+, 7 個 /8^+, /8^+, /8^+} 1 年 2 カ月で /8x19 消費 2011/1/21 maz&tomo 17

18 IPv6 経路数の推移 2010 年中の IPv6 経路の伸びが著しいアドレス配布の促進 2010 年 /1/21 maz&tomo 18

19 経路数 IPv6 経路数比較 (1) 末 : 末 : 尐し真面目に経路制御しはじめた? 0 /16 /17 /18 /19 /20 /21 /22 /23 /24 /25 /26 /27 /28 /29 /30 /31 /32 /33 /34 /35 /36 /37 /38 /39 / 末 末 /1/21 maz&tomo 19

20 経路数 IPv6 経路数比較 (2) 末 : 末 : /41 /42 /43 /44 /45 /46 /47 /48 /49 /50 /51 /52 /53 /54 /55 /56 /57 /58 /59 /60 /61 /62 /63 / 末 末 /1/21 maz&tomo 20

21 AP 地域の国別 IPv6 アドレス配分状況 分配ポリシー改定に伴い各国の申請数が急増 日本 中国 オーストラリア /1/21 maz&tomo 21

22 IPv4 から IPv6 へ 1. v4 2. v4+v6 3. v4/v6 4. v6+v4 5. v6 v4 v4 v4 v6 v6 v6 v4 v6 ここを考えてみる 2011/1/21 maz&tomo 22

23 V4 主流の時代から V6 へ V4 経路 着々と伸び続けていく 2 年後に 40 万 4~5 年後に 50 万 割り振りされた後もなお伸び続ける空間が多い 枯渇を契機とした経路の増加も考えられる 移転に伴う細かい経路の増加 V6 経路は粛々と伸びていく 移転に伴う問題 IPv4 経路フィルタを割り振り空間や最小割り振りサイズ等をベースに実施している場合は影響あり 統計の集計問題 2011/1/21 maz&tomo 23

24 IPv4 経路数推移予測 倍より下降 1.11 倍維持 1.13 倍維持 /1/21 maz&tomo 24

25 v4 経路の増加は継続する 現在の要因 2011 年以降の要因 1. 新規アドレスの増加 1. 未利用アドレスの新規利用増 2. 割り振り済み空間の細分化 2. 割り振り済み空間の細分化 RIR pool 枯渇後は 現在よりは多尐ゆるかやな増加になると思われるが しばらく増加は続くだろうと予想フルルートの半分以上が / /1/21 maz&tomo 25

26 AP 地域の /24 の推移 (1) 1999 年 2000 年 2001 年 2002 年 2003 年 2004 年 2005 年 2006 年 2007 年 2008 年 2009 年 2010 年 202/8 203/8 210/8 211/8 061/8 218/8 219/8 220/8 221/8 222/8 060/8 058/8 059/8 124/8 125/8 126/8 121/8 122/8 123/8 114/8 115/8 116/8 117/8 118/8 119/8 120/8 112/8 113/8 110/8 111/8 180/8 183/8 175/8 182/8 001/8 027/8 014/8 223/8 049/8 101/8 036/8 042/8 2011/1/21 maz&tomo 26

27 AP 地域における /24 の経路数 AP 地域の /24 の推移 (2) フルルート全体の中での /24 の増加率は 倍なので AP 地域は他地域に比べて /24 がより増加傾向にある 年 2000 年 2001 年 2002 年 2003 年 2004 年 2005 年 2006 年 2007 年 2008 年 2009 年 2010 年 /24の数 年増加率 /1/21 maz&tomo 27

28 V4 フルルートの意味の変化 基本は複数の上流から聞こえてくる BGP 経路に従い最適にルーティング フルルートに基づいた最適な経路制御の意味合いが徐々に薄れていく デフォルトルートを利用したり 安い回線を単に利用するような使い方が多くなっている 今の IPv4 経路は既に 33 万超でメモリの問題やスケーラビリティの問題もある ただ IPv4 の通信は当面長い間暫くつづくことを想定しておく必要はある 2011/1/21 maz&tomo 28

29 IPv6 本格到来への準備の年 2011/1/21 maz&tomo 29

30 v6 ネットワークの構築 コネクティビティの充実化 BGP のトポロジーや Peer が確立されている region が まだまだ v4 と異なる いつなんどきコンテンツが v6 へ移行しても良いように準備が必要 2011 年には v4 同等相当の品質を確保できるネットワークを構築していく必要がある 日本のピアリングも充実させていく 自分のネットワークから様々な v6 サイトへの到達性や遅延などを確認しておく必要がある 2011/1/21 maz&tomo 30

31 traceroute to v /1/21 maz&tomo 31

32 traceroute to v4 > traceroute traceroute to ( ), 64 hops max, 40 byte packets ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ( ) ms 10 otejbb204.kddnet.ad.jp ( ) ms 11 otecbb103.kddnet.ad.jp ( ) ms ms 12 tr-ote119.kddnet.ad.jp ( ) ms ms ms ( ) ms ms ms 14 i siko-core01.bi.reach.com ( ) ms ms ms 15 i-5-1.sydp-core02.bx.reach.com ( ) ms ms ms 16 TenGigabitEthernet pad-gw2.Sydney.telstra.net ( ) ms ms ms 17 Bundle-Ether3.ken-core4.Sydney.telstra.net ( ) ms ms ms 18 Pos cha-core4.Brisbane.telstra.net ( ) ms ms ms 19 TenGigabitEthernet8-1.cha23.Brisbane.telstra.net ( ) ms ms ms resolvers.Brisbane.telstra.net ( ) ms ms ms 2011/1/21 maz&tomo 32

33 traceroute to v /1/21 maz&tomo 33

34 traceroute to v6 > traceroute6 traceroute6 to (2001:dc0:2001:11::213) from 2402:c800:ff06:136::141, 64 hops max, 12 byte packets :c800:ff06:136:: ms ms ms :c800:ff06:160:: ms ms ms :c800:ca:6:: ms ms ms :c800:bb:11:: ms ms ms :218:2000:5000::a ms ms ms 6 ae-6.r21.tokyjp01.jp.bb.gin.ntt.net ms ms ms 7 p r21.newthk01.hk.bb.gin.ntt.net ms ms ms 8 po-3.a04.newthk01.hk.ra.gin.ntt.net ms ms ms 9 po-3.a04.newthk01.hk.ra.gin.ntt.net ms hurricaneelectric-rge.hkix.net ms ms 10 v1026.core1.sjc1.he.net ms ms ms 11 10g-2-1.core1.sjc2.ipv6.he.net ms v1026.core1.sjc1.he.net ms ms :7800:100:1::d ms 10g-2-1.core1.sjc2.ipv6.he.net ms 2402:7800:100:1::d ms :7800:100:1::d ms ms ms 14 ge bdr01.bne02.qld.vocus.net.au ms 2402:7800:0:1:: ms ms 15 ge bdr01.bne02.qld.vocus.net.au ms ge bdr01.bne01.qld.vocus.net.au ms ms 16 ge bdr01.bne01.qld.vocus.net.au ms ms ms 17 * 2001:dc0:2001:11:: ms ms 2011/1/21 maz&tomo 34

35 traceroute to v4 > traceroute traceroute to ( ), 64 hops max, 40 byte packets ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms 4 ge-8-19.a15.tokyjp01.jp.ra.gin.ntt.net ( ) ms ms ms 5 ae-6.r20.tokyjp01.jp.bb.gin.ntt.net ( ) ms ms ms 6 as-1.r20.snjsca04.us.bb.gin.ntt.net ( ) ms ms ms 7 as-1.r21.asbnva01.us.bb.gin.ntt.net ( ) ms ms ms 8 as-0.r23.amstnl02.nl.bb.gin.ntt.net ( ) ms ms ms 9 xe-7-4.r00.amstnl02.nl.bb.gin.ntt.net ( ) ms ms ms ( ) ms ms ms 11 * 2011/1/21 maz&tomo 35

36 traceroute to v6 > traceroute6 traceroute6 to (2001:610:240:22::c100:68b) from 2402:c800:ff06:136::141, 64 hops max, 12 byte packets :c800:ff06:136:: ms ms ms :c800:ff06:160:: ms ms ms :c800:ca:6:: ms ms ms :c800:bb:11:: ms ms ms :218:2000:5000::a ms ms ms 6 ae-6.r20.tokyjp01.jp.bb.gin.ntt.net ms ms ms 7 as-1.r20.snjsca04.us.bb.gin.ntt.net ms ms ae-3.r20.osakjp01.jp.bb.gin.ntt.net ms 8 as-2.r20.snjsca04.us.bb.gin.ntt.net ms ms as-1.r21.asbnva01.us.bb.gin.ntt.net ms 9 as-1.r21.asbnva01.us.bb.gin.ntt.net ms as-0.r23.amstnl02.nl.bb.gin.ntt.net ms as- 1.r21.asbnva01.us.bb.gin.ntt.net ms 10 as-0.r23.amstnl02.nl.bb.gin.ntt.net ms ms ms 11 XSR03.Asd001A.surf.net ms ae-1.r22.amstnl02.nl.bb.gin.ntt.net ms ms 12 XSR03.Asd001A.surf.net ms * ms 13 * ヨーロッパ方面は地理的要因で比較的 v4 と同じような状況 2011/1/21 maz&tomo 36

37 Niigata to Tokyo v4 (janog25) 新潟 市民プラザ 東京 /1/21 maz&tomo 37

38 show route v4 Tracing route to [ ] 1 2 ms 1 ms <1 ms ms 8 ms 5 ms flbsni05.nplus-net.jp [ ] 3 6 ms 8 ms 5 ms flrtni01.nplus-net.jp [ ] 4 6 ms 5 ms 6 ms egrt03.nplus-net.jp [ ] 5 8 ms 5 ms 5 ms crrt01.nplus-net.jp [ ] 6 7 ms 5 ms 5 ms bdrt01.nplus-net.jp [ ] 7 13 ms 13 ms 17 ms * 14 ms 12 ms kotcbb201.kddnet.ad.jp [ ] 9 13 ms 13 ms 11 ms otejbb203.kddnet.ad.jp [ ] ms 12 ms 12 ms ix-ote202.kddnet.ad.jp [ ] ms 72 ms 97 ms ms 14 ms 14 ms ms 17 ms 13 ms ms 16 ms 17 ms ms 16 ms 14 ms ms 17 ms 21 ms ms 16 ms 16 ms ms 16 ms 16 ms ms 16 ms 16 ms [ ] 2011/1/21 maz&tomo 38

39 Niigata to Tokyo v6 (janog25) 新潟 市民プラザ 東京 /1/21 maz&tomo 39

40 show route v6 Tracing route to [2402:c800:ff06:152::157] 1 2 ms 1 ms 1 ms 2400:e000:5:203::1 2 7 ms 7 ms 7 ms 2400:e000:5:100::1 3 8 ms 6 ms 5 ms 2400:e000:0:910::9 4 6 ms 6 ms 7 ms 2400:e000:0:59::5 5 6 ms 6 ms 6 ms 2400:e000:0:56::6 6 5 ms 5 ms 5 ms 2400:e000:0:46:: ms * 25 ms 2001:278:0:2201:: ms * 22 ms STOsrn03V41.nw.v6.odn.ne.jp [2001:278:0:2001::1] 9 21 ms 25 ms 11 ms 2001:278:0:2009:: ms 119 ms 121 ms 2001:278:0:2020::7 11 * * * Request timed out ms 122 ms 116 ms ae-1.r20.snjsca04.us.bb.gin.ntt.net [2001:418:0:2000::1a2] ms 244 ms 247 ms as-1.r20.osakjp01.jp.bb.gin.ntt.net [2001:218:0:2000::7e] ms 331 ms 238 ms po-1.a15.tokyjp01.jp.ra.gin.ntt.net [2001:218:0:6000::10e] ms 265 ms 237 ms 2001:218:2000:5000::a ms 249 ms 273 ms 2402:c800:bb:11:: ms 246 ms 236 ms 2402:c800:ca:6:: ms 247 ms 246 ms 2402:c800:ca:6:: ms 252 ms 258 ms 2402:c800:ff06:168:: ms 239 ms 251 ms [2402:c800:ff06:152::157] 2011/1/21 maz&tomo 40

41 Kanazawa to v6 金沢石川県立音楽堂 /1/21 maz&tomo 41

42 traceroute to v6 C: >tracert -d Tracing route to [2001:380:516:4220::1:1] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms 2001:308:1::1 2 1 ms 1 ms 2 ms 2001:308:0:1999:: ms 17 ms 15 ms 2001:308:0:10:: ms 16 ms 16 ms 2001:380:0:2310:: ms 16 ms 16 ms 2001:380:8080:7:: ms 16 ms 16 ms 2001:380:8150:8:: ms 18 ms 16 ms 2001:380:8020:26:: ms 17 ms 17 ms 2001:380:8020:29:: ms 15 ms 15 ms 2001:380:8100:c:: ms 22 ms 22 ms 2001:380:0:2603::2 11 * * * 2011/1/21 maz&tomo 42

43 Kanazawa to v6 金沢石川県立音楽堂 (v6) 2011/1/21 maz&tomo 43

44 traceroute to v6 C: >tracert -d Tracing route to [2001:240:bb42:b000::1:80] over a maximum of 30 hops: 1 1 ms 1 ms 9 ms 2001:308:1::1 2 5 ms 5 ms 3 ms 2001:308:0:1999::1 3 1 ms 1 ms 1 ms 2001:308:0:20:: ms 2 ms 7 ms 2001:240:bb58:1000::edfa 5 1 ms * 1 ms 2001:240:bb18:2::b8 6 6 ms 5 ms 6 ms 2001:240:bb00:8044:: ms 10 ms 15 ms 2001:240:bb00:904e:: ms 18 ms 18 ms 2001:240:bb00:906d:: ms 16 ms 16 ms 2001:240:bb00:9040:: ms 25 ms 22 ms 2001:240:bb02:b:: ms 17 ms 18 ms 2001:240:bb42:b000::1: /1/21 maz&tomo 44

45 From Kanazawa to v /1/21 maz&tomo 45

46 traceroute to v4 C: >tracert -d -4 Tracing route to [ ] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms ms 1 ms 1 ms ms 1 ms 1 ms ms 47 ms 47 ms ms 2 ms 2 ms ms 6 ms 6 ms ms 6 ms 5 ms ms 15 ms 16 ms ms 17 ms 17 ms ms 31 ms 14 ms ms 15 ms 15 ms ms 15 ms 15 ms ms 128 ms 128 ms ms 128 ms 128 ms ms 129 ms 129 ms ms 145 ms 145 ms ms 145 ms 145 ms ms 144 ms 145 ms ms 144 ms 145 ms /1/21 maz&tomo 46

47 From Kanazawa to v /1/21 maz&tomo 47

48 traceroute to v6 Tracing route to [2001:dc0:2001:11::230] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms 2001:308:1::1 2 1 ms 1 ms 1 ms 2001:308:0:1999::1 3 1 ms 1 ms 1 ms 2001:308:0:10:: ms 1 ms 1 ms 2001:240:bb58:1000::edfa 5 2 ms * 1 ms 2001:240:bb18:2::b8 6 6 ms 5 ms 5 ms 2001:240:bb00:8044:: ms 6 ms 5 ms 2001:240:bb00:904f::7a 8 15 ms 50 ms 15 ms 2001:240:bb00:906e:: ms 133 ms 119 ms 2001:48b0:bb00:8021:: ms 133 ms 134 ms 2001:450:2002:d6:: ms 281 ms 280 ms 2402:7800:0:1:: ms 293 ms 293 ms 2402:7800:0:1:: ms 293 ms 293 ms 2402:7800:10:1:: ms 293 ms 367 ms 2402:7800:10:1:: ms 313 ms 294 ms 2402:7800:10:1:: ms 295 ms 293 ms 2001:7fa:9:: ms 293 ms 293 ms 2001:dc0:2001:11:: /1/21 maz&tomo 48

49 つまり クライアントが IPv6 環境になると 従来よりも接続環境が悪くなる懸念がある この状況は回避すべし 自分の上流や その上流にも頑張って貰う必要がある 2011/1/21 maz&tomo 49

50 ある時 某 J NIC の whois がきちんと引けないということが結構多くなった 調べてみると IPv6 対応したらしい IPv4 だとうまくいくなぁ IPv4/IPv6 各々での確認が必要 常日頃から IPv6 で生活していないとわからないので 準備をしましょう 2011/1/21 maz&tomo 50

51 変化 v6 トラフィック制御 エンドユーザ (Client サイド ) の v6 対応 サービス (Server サイド ) の v6 対応 備え いつ何時メジャーサイトが v6 になるかわからない 突然 v6 トラフィックが増加し 既存の v4 制御とは異なる制御方式やネットワークトポロジーの場合は 急激な変化が発生する可能性あり Client サイドの v6 化が普及しつつ メジャーサイトが突如 v6 化 通信品質の確保 ネットワークトポロジーの維持 2011/1/21 maz&tomo 51

52 v4+v6 ルーティング ISP-A 6G 6G 7G v4 v4 v4(6g)+v6(1g) 急に v4 から v6 にトラフィックがシフトすると焦げる ISP-B 2011/1/21 maz&tomo 52

53 v4/v6 ルーティング ISP-A p p p ISP-B ibgp multipath ibgp マルチパスで制御が出来れば 1prefix の交換でも問題ない p Prefix 2011/1/21 maz&tomo 53

54 v4/v6 ルーティング ISP-A ISP-B p1 p ISP-C p p2 そもそもちぎれる設計になっている? 2011/1/21 maz&tomo 54

55 v6 ルーティング設計 きちんと冗長化できる設計を /32のアドレス設計 /32の中のフロー分析が必要 /33で分割してはたしてうまくいく? ボリューム毎にPrefixを切りだすような形? そもそも細切れ経路制御はありえない? /32もおかわりする?(HD ratioを満たす必要あり ) 見直すなら今年が最後です! 2011/1/21 maz&tomo 55

56 /32 の使い方 /32 BB U1 U2 U3 U4 U5 U6 U7 U8 BB /32 BB U1 U2 U2 ほとんどのトラフィックが後半に集中 2011/1/21 maz&tomo 56

57 v4 v6 prefix size v4 v6(1) v6(2) v6(3) /32 /64 /56 /48 /24 /56 /48 /40 /16 /48 /40 /32 /8 /40 /32 /24 /22(min size) /32 /8 /16? どこまで許容するか?/48? 2011/1/21 maz&tomo 57

58 V6 トラフィックの可視化 v4/v6 混在の時代 今はあまりきにしていないかもしれない 今年から本格的に把握していく必要がある xflow IPv6 トラフィックの可視化が必要! まだフロー情報でネットワークの可視化をしていない人は是非この機会に対応しましょう 2011/1/21 maz&tomo 58

59 フローの種類 Netflow (v1/5/7/8/9) Cisco によって開発された技術でルータで良く使われている UDP(Default:2055/9991 など ) でフローデータを送信 Cisco, Juniper, Alaxala などが実装 sflow (v2/4/5) InMon によって開発された技術でスイッチなどで使われている UDP(Default:6343) でフローデータを送信 Brocade Alaxala Force10 などが実装 IPFIX(IP Flow Information export) Netflow v9 をベースとして IETF で標準化 RFC5101(Proposed Standard) SCTP を使ってフローデータを送信 一部ベンダが実装 主なベンダは未対応 2011/1/21 maz&tomo 59

60 Netflow Ver sflow 特徴 フローの種類 5 現在 最もよく使われているバージョン 固定のフォーマットで情報を転送 BGP の AS 情報を含む 9 RFC3954(Informational) で公開 Template を使い柔軟に効率的に 情報を送信可能 IPv6 MPLS などの情報を保持し 主流になると予想される 参考 : Ver 特徴 4 RFC3176(Informational) で公開 ヘッダ情報を先頭から切り取って MIB とともに転送 BGP のルーティング情報などを含めることができる 5 sflow.org で Pha 04 を公開 v4 と大きく変わらない 2011/1/21 maz&tomo 60

61 v6 対応 Flow 種別バージョン IPv6 対応備考 NetFlow 5 固定フォーマットに IPv6 アドレスを含まない 9 IPv6 のテンプレートをもつ sflow 2 IPv4/IPv6 ともに対応 IPFIX 4 5 IPv6 のテンプレートをもつ 現用される機器を用いた場合 Netflow v9 sflow で IPv6 の解析が可能商用のコレクタは対応済み 2011/1/21 maz&tomo 61

62 IPv4/IPv6 トラフィック解析 IPv6 IPv6 IPv4 IPv4 NTTCom SAMURAI( トラフィック解析装置 ) 2011/1/21 maz&tomo 62

63 約 24M bps 2011/1/21 maz&tomo 63

64 約 24M bps IPv6 トラフィックはゼロ 2011/1/21 maz&tomo 64

65 ACL-based sflow 約 12k bps 通常のサンプリングでは失われてしまう IPv6 トラフィックを解析できた 2011/1/21 maz&tomo 65

66 Per flow Per destination トラフィックバランス 802.3ad LAG でうまくいくのか? v6 が今の v4 相当になっているか確認が必要 突然ボリュームが多くなってアンバランスにならなように 2011/1/21 maz&tomo 66

67 IPv4/IPv6 混在運用 問い合わせの対応 ネットワークの障害時の確認 IPv4 通信の問題? IPv6 通信の問題? クライアントはIPv4?IPv6? サーバはIPv4?IPv6? 2011/1/21 maz&tomo 67

68 connected via IPv6 各社が表示 ブラウザ側に表示が必要かもしれない 2011/1/21 maz&tomo 68

69 2011/1/21 maz&tomo 69

70 が もしも こんな場合 あくまで仮の話です ネットワークトポロジーやクライアント環境の違いによってエンドユーザ毎に見え方が事なる可能性がある v4/v6 v4/v6 各々での切り分けが必要になる v4 v6 2011/1/21 maz&tomo 70

71 ルーティングセキュリティ 多くは今の v4 と同等のものを v6 でも実施していくことになる 今の v4 で起きていて v6 では FIX したいもの きちんと設計なり運用をしていく V6 が本格化してわかる問題 これは都度対処していくしかない 2011/1/21 maz&tomo 71

72 Bogon フィルタ Bogon ルート bogus( 偽りの ) という言葉から派生したもので Bogon ルートとは 本来広告されてはならない Prefix のこと Bogon フィルタ Bogon ルートを GW ルータ等でフィルタし 本来広告されるべきではない経路をフィルタすること 用途 Prefix プライベートアドレス / / /16 ループバックアドレス /8 リンクローカルアドレス /16 TEST-NET /24 TEST-NET /24 TEST-NET /24 ベンチマークテスト /15 マルチキャストアドレス /3 IANA Reserve 現在 /8 x7 RFC /1/21 maz&tomo 72

73 IPv6 時代の Bogon フィルタ IPv4 と同じ事を出来れば繰り返したくない Secure BGP Routing が確立されれば 誤った経路情報が流入しないため 水際でのフィルタ設定は必要ない? 段階的な実装では恐らく何らかしばらく必要 現状 reserve 空間のほうが断然多いので はじめの段階ではホワイトリストを許可するのが良さそう ただその場合でも 適切にフィルタが更新されないと同じ問題が発生するので 悩ましい 2011/1/21 maz&tomo 73

74 v6/v4 時代 ( 尐し先の話し ) v6 通信が強くなってきた時代 v4 はどうする? フルルートが本当に必要なところは? 徐々にフルルートの伝搬対象が尐なくなっていく? トラフィックのボリュームもないことから 細切れにする意味もなくなるのでは? トラフィックボリュームに応じた経路制御方式を再考する必要があるかもしれない でも あえて今の経路制御をかえてまで細かい経路が減るとは思えない 2011/1/21 maz&tomo 74

75 v6 主流時代 ( さらに先の話し ) v4 相当の経路制御 V6 フルルート交換 一部は default を利用 v4 の経路制御 Tier-1 の間では full-route がルーティング 自 ISP の CIDR を広告 Peer の経路はお互い交換 エッジの BGP スピーカーは CIDR/PI を上流に広告する程度? フロー解析用にフルルートを調達? 2011/1/21 maz&tomo 75

76 ディスカッション v4とv6のネットワークトポロジー v6アドレス設計 v6 許容 prefixサイズ v6トラフィックの把握 / 確認 トラフィックバランス v4/v6 混在オペレーション v6ルーティングセキュリティ 2011/1/21 maz&tomo 76

77 DNS2011 (+IPv6) 2011/1/21 maz&tomo 77

78 DNS みんな使ってる DNS dns query server dns reply dns cache root-servers dns query enduser dns reply dns cache dns contents tomop&maz 78

79 目下の DNSSEC 対応目標 DNS サーバ ( コンテンツ キャッシュ ) dns query server dns reply dns cache root-servers dns query enduser dns reply dns cache dns contents tomop&maz 79

80 この意味する所 ドメイン管理の対応 DS 鍵の受付 登録申請 コンテンツ DNS での対応 実装の対応 署名運用 鍵管理 キャッシュ DNS での対応 実装の対応 トラストアンカーの維持 tomop&maz 80

81 ドメイン関連のサービス 登録 更新 ドメインホスティング セカンダリ DNS 鍵管理等に課題が残るものの まあ粛々と進める類のもの tomop&maz 81

82 ISP のキャッシュ DNS サーバ 実は 用途別にいっぱいある dns cache dns cache dns cache dns cache server dns cache dns cache dns cache dns cache enduser internal server tomop&maz NOC office 82

83 メール配送が利用するキャッシュ DNS DNSSEC の嬉しさ 署名する側のモチベーションが高まる うまくいけば偽のホストに誘導されない DNSSEC の怖さ メール配送が失敗する 署名やゾーン公開の失敗 検証側の失敗 tomop&maz 83

84 メール配送が利用するキャッシュ DNS ポイント 1) 標準仕様はいつ どっち? プロモーションに利用する手段はあるかもなあ ポイント 2) 検証失敗はどうする? 大規模になったら気にする? 署名検証サービスでもやっとく? tomop&maz 84

85 コンシューマ向けキャッシュ DNS DNSSEC の嬉しさ 署名する側のモチベーションが高まる うまくいけば偽のホストに誘導されない メール web などなど様々なサービス DNSSEC の怖さ 誰かの失敗で ( より ) 名前解決できくなる 署名やゾーン公開の失敗 検証側の失敗 名前解決できない場合のユーザサポート tomop&maz 85

86 コンシューマ向けキャッシュ DNS ポイント 1) 選択肢必要? DNSSEC 検証が有効なサーバ DNSSEC 検証しないサーバ ポイント 2) 標準仕様はいつ どっち? 参照先 DNS を手動設定しているユーザは尐ない ポイント 3) 検証失敗はどうする? 基本的に気にしない 大規模になったら気にする? tomop&maz 86

87 忘れていること この辺って気を付けてる? dns query server dns reply dns cache root-servers dns query enduser dns reply dns cache dns contents tomop&maz 87

88 DNS でトラヒックエンジニアリング DNS はみんな使ってる ユーザ側 コンテンツ提供側 その間にいる キャッシュサーバで頑張ればトラヒックコントロールが可能かも 特にコンテンツ元がいっぱいある CDN 関係 レコードを書き換えるのは邪悪なので 別な手段 tomop&maz 88

89 ( 一部の )CDN な仕組み キャッシュ DNS サーバの IP アドレスに応じて コンテンツサーバの IP アドレスを応答 そのために独自のデータベースを運用 コンテンツ IP = map( キャッシュ DNS の IP) tomop&maz 89

90 つまり 問い合わせに使う IP アドレス dns query enduser dns reply dns cache enduser dns query dns reply dns cache dns contents tomop&maz 90

91 夢は広がる キャッシュ DNS に収容するユーザを分散 キャッシュDNS 毎に配信経路を変えてもらう CDN 事業者側と調整が必要 その IP アドレスはユーザに見せる必要はない がんがん変えても大丈夫 でもまあ 運用は大変 CDN 事業者側との握りが必要 tomop&maz 91

92 ピアリング交渉? いえ トラヒック制御交渉です 通常時や迂回時 トラブル時のトラヒックの流れを交渉しておく 特に巨大なコンテンツプロバイダと握っておくのは重要 その制御の実装は いろいろあるかも 経路による制御 DNS による制御 キャッシュによる制御 tomop&maz 92

93 IPv6 僕が自宅でふつーに使える時代がやってくる 今でもできるけど より尐ない労力でいける! 一方で サービスを IPv6 対応することに不安を抱えている人も アクセスできない人とか サポートとか 何にせよ IPv6 対応のサービスはやってくる tomop&maz 93

94 falling sky tomop&maz 94

95 falling sky tomop&maz 95

96 2011 年 6 月 8 日 ( 水 ) tomop&maz 96

97 World IPv6 day 概要 IPv6トライアル 主にコンテンツ事業者が24 時間 IPv6 対応してみる 2011 年 6 月 8 日 00:00-23:59(UTC) -> 09:00JST~ 英語 : 日本語 : tomop&maz 97

98 想定される影響 ほとんど問題ないはず 半分ぐらいの端末はIPv6を理解しない IPv6 接続性が無かったら IPv6でアクセスしない 品質の悪い IPv6 接続な人は要注意 ダメなトンネル 悪い到達性 tomop&maz 98

99 日本的事情 IPv6 閉域網 tomop&maz 99

100 ちなみに NTT NGN の仕様 IP 通信網サービスのインタフェース NTT 東 フレッツシリーズ - 第三分冊 第 11 版 2.4 レイヤ 3 仕様 NTT 西 フレッツシリーズ 第 37 版 ネットワークレイヤ ( レイヤ 3) 仕様 IP 通信網内に存在しない宛先に送信されるパケットについては IP 通信網において応答なくパケット破棄される場合や RFC793 に規定される RST ビットをセットした TCP パケットを返信する場合があります tomop&maz 100

101 事前検証 当日に問題ある 無い? でも実は既にdual stackになってるサイトあるよね とか とか もうちょっと詳しい端末の状況を知りたいよね tomop&maz 101

102 tomop&maz 102

103 tomop&maz 103

104 事前準備 日本語サイトの充実 一般ユーザ向けの情報とか絵とか テスト環境の容易? があれば大丈夫? 参加コンテンツプロバイダの募集 いざって時の連絡先とかも欲しい 関係者で議論中 tomop&maz 104

105 注意点 行けそうだったら そのまま IPv6 を有効のままにしちゃうかもってサイトもあります まあ 今だってどこかのサイトが IPv6 付けるかもしれないし 止められないよねえ tomop&maz 105

106 ディスカッション DNS DNSSEC 対応の時期とかどうですか? トラヒック制御との絡みってどうだろう? World IPv6 Day 何か必要な準備ってありますか? 参加表明できるコンテンツ事業者っていますか? tomop&maz 106

107 まとめ 2011 年 v4 アドレスはついに枯渇します 当面の IPv4/IPv6 共存時代に向けて 様々な準備をしていく必要があります IPv6 インターネットの本格構築 DNSSEC 導入 World IPv6 Day 日々オペレーション情報を引き続き交換し よりよいインターネット環境を皆で作っていきましょう! 2011/1/21 maz&tomo 107