IPv4/IPv6時代のルーティングとセキュリティ

Size: px

Start display at page:

Download "IPv4/IPv6時代のルーティングとセキュリティ"

あゆみうすい
5 years ago
Views:

1 IPv6/IPv4 時代のルーティングとセキュリティ Tomoya Yoshida NTT

2 2 アブストラクト IPv4 枯渇がいよいよ近づいているだが枯渇した後も IPv4 の世界は暫く続くだろうし IPv6 時代あるいは IPv4 との併用時代に向けて考えないといけないことも様々あるだろうこれまでの IPv4 を振り返った際これから本格化する IPv6 時代にはそのまま継続すれば良いものと綺麗にスタートしていきたいものがあるだろう特に後者については例えば BOGON フィルタの問題や経路増大の問題ルーティングセキュリティの問題など様々あるまたこれらの問題を解決するために IPv6 ルーティングプロトコルや関連技術が設計段階から様々検討されている一方運用者の立場として考えなければいけないことも多くあるそんな中先日 ISOC 主催の workshop が開催され将来のルーティングセキュリティに関する議論を運用者の間で行いアジアの立場で参加をしてきた今回の JANOG ではその内容も含めて将来の IPv6/IPv4 時代に向けての課題を共有し IPv6/IPv4 時代のルーティングとセキュリティに関してどうあるべきかあるいはどうなると幸せか JANOG のコミュニティの皆さんと一緒に議論したい

3 3 内容 v4 の現状 v4/v6 混在時代の課題ルーティングセキュリティの今後議論

4 4 IPv4 アドレスまだあると安心している人いませんか? 本当になくなります残り 10%

5 2005 Copyright 年月の NTT IPv4フルルート 5

6 2006 Copyright 年月の NTT IPv4フルルート 6

7 2007 Copyright 年月の NTT IPv4フルルート 7

8 2008 年 Copyright 月の NTT IPv4フルルート 8

9 2010 Copyright 年月の NTT IPv4フルルート 9

10 10 v4 から v6 へ 1. v4 2. v4+v6 3. v4/v6 4. v6+v4 5. v6 v4 v4 v4 v6 v6 v6 v4 v6 主にこのあたりを考えてみる

11 11 V4 主流の時代 V4 経路着々と伸び続けていく 2~3 年後に 40 万 5 年後に 50 万割り振りされた後もなお伸び続ける空間が多い枯渇を契機とした経路の増加も考えられる LSN 等の NAT グローバルアドレスホスティングサービス V6 経路は粛々と伸びていく将来どうなるのか? おまけ : 移転に伴う問題 IPv4 経路フィルタを割り振り空間や最小割り振りサイズ等をベースに実施している場合は影響あり統計の集計問題

12 12 IPv4 経路数の推移

13 13 IPv4 経路数推移予測倍より下降 1.11 倍維持 1.13 倍維持

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

15 15 AP 地域の /24 の推移年 2000 年 2001 年 2002 年 2003 年 2004 年 2005 年 2006 年 2007 年 2008 年 2009 年 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

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

17 17 アジア地域のBGP fullrouteの利用状況 % mixed use default 60 default-free JP TW AU KR CN

18 18 V4 と v6 のネットワークトポロジー V4 は v6 はまだまだ異なる V6 で通信すると遅い問題なので v4 を使ってしまうという人が多いのでは?

19 19 traceroute to v4

20 20 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

21 21 traceroute to v6

22 22 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

23 23 show route v4 > show route inet.0: destinations, routes ( active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both /24 *[BGP/170] 9w1d 02:28:07, MED 0, localpref 100 AS path: I > to via ge-1/0/5.0 [BGP/170] 9w1d 02:27:52, MED 11, localpref 100 AS path: I > to via ge-1/0/3.0

24 24 show route v6 > show route 2001:dc0:2001:11::213 inet6.0: 1997 destinations, 3911 routes (1997 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2001:dc0:2000::/35 *[BGP/170] 1w4d 20:48:54, MED 0, localpref 100 AS path: I > to 2001:218:2000:5000::a5 via ge-1/0/3.0 [BGP/170] 6d 07:02:40, MED 0, localpref 100 AS path: I > to 2001:380:0:2505::1 via ge-1/0/5.0 v4: I

25 25 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 *

26 26 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 *

27 27 Niigata to Tokyo v4 新潟市民プラザ東京

28 28 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 [ ]

29 29 Niigata to Tokyo v6 新潟市民プラザ東京

30 30 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]

31 31

32 特に問題なし v4(g) v4/v 特に問題なし v4(g)-1 v6(g)-1 2. v4/v6 部分の初期表示に時間がかかる v4(g) v6(p) v4/v v4/v6 部分の遅延が大きい v4(g)-2 v6(g)-2

33 33 v6 ネットワークコネクティビティは確実に充実 BGP のトポロジーや Peer が確立されている region がまだまだ異なる今からきちんと v4 同等相当の品質を確保できるネットワークを構築していく必要がある日本のピアリングも充実させていく

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

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

36 36 v4+v6 ルーティング ISP-A 6G 6G 7G v4 v4 v4+v6 急に v4 から v6 にトラフィックがシフトすると焦げる ISP-B

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

38 38 v4/v6 東西のルーティング例西 ISP-A 東東は太いけど西は細いマルチパス出来ない ISP-B 制御できる Prefix が豊富にあれば OK Prefix 分割?

39 39 V6 ルーティング設計きちんと冗長化できる設計を心掛ける /32 のアドレス設計 /32 の中のフロー分析が必要 /33 で分割してはたしてうまくいく? ボリューム毎に Prefix を切りだすような形?

40 40 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 /18 /48 まで最初から許す? というのはやめたいコンセンサスづくりが必要

41 41 V6 トラフィックボリュームの確認 v4/v6 混在時今はあまりきにしていないかもしれない多くなってきた場合にどちらがどの程度なのかをきちんと把握する必要がある xflow そもそも皆さんの ISP 網では飛ばしてますか? Netflow v5 の人が多かったりしません?

42 42 トラフィックバランス Per flow Per dest v6 が今の v4 相当になっているか確認が必要

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

44 44 ルーティングセキュリティ V6 が本格化してわかる問題これは都度対処していくしかない今の v4 で起きていて v6 では FIX したいものきちんと設計なり運用をしていく

45 45 ISOC Roundtable 2009 Sep Routing security の問題は昔からの長年の問題 route hijacking はインターネットでしばし観測されている IETF の SIDR(Secure Inter-Domain Routing)WG によって着実に一歩一歩検討が進んでいる一方これからは network operator による deployment へとシフトしていくことが必要となってきている今回の Meeting では network operator に着眼最終的には network operator が運用するという点を踏まえ Internet Security を改善するには Network operator の将来の見通しが極めて重要 Network operator における現状の課題や将来の見通しを共有レポートを公開する今回の Meeting では operator の view をまとめたものでありルータベンダや RIR の関係者は含まれていない

46 Excecutive Summary A roundtable discussion of the current state and prospective solutions for securing routing information elicited a wide variety of observations, many shared views and some

RPKI is seen as an important step toward improving routing security, although it directly solves only the small part of the problems with respect to address origination, not AS paths.

46 46 Excecutive Summary A roundtable discussion of the current state and prospective solutions for securing routing information elicited a wide variety of observations, many shared views and some differences of opinion. Operators are aware of the risks and have mechanisms, at different levels of automation, to deal with route hijacking and errors that advertise false routes. RPKI is seen as an important step toward improving routing security, although it directly solves only the small part of the problems with respect to address origination, not AS paths. The suspect quality of the data on which validity of address prefix announcement is based is a serious problem that requires immediate attention, and will probably take some time to address. Efforts were identified as either short or long term.

47 47 Consensus needs and priorities RPKI for origin validation should be pursued for both IPv4 and IPv6 Uniqueness of IP address certification at the global level is required IPv6 data cleanup now because it is easier IPv4 harder and later Authentication of resource holders (local solutions) Need open source tools for certificate distribution and validation Cost of (safe) business needs to be reduced, shared software tools would help What can be done about path validation (short term: without changing BGP long term: fix BGP) should be investigated How invalidation of authority to route is done (including disputes) needs to be resolved

48 48 Short/Long term solution Short term (2-4 years) Cert-validation widget Open software tools Origin protection Clean IPv6 data Partial implementation Revocation Path protection - w/o protocol changes Long term (3-6 years) Hardware changes Path protection with protocol changes AS path relationships Protocol changes Clean IPv4 data Bootstrapping-exception handling

49 49 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 x24 RFC5737

50 Copyright NTT object IRR: fltr-unallocated $whois h jpirr.nic.ad.jp fltr-unallocated 未割り振りの /8 を表す IRR の Object filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes. filter: { 5.

50 50 Copyright NTT object IRR: fltr-unallocated $whois h jpirr.nic.ad.jp fltr-unallocated 未割り振りの /8 を表す IRR の Object 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^+} 24 個 admin-c: tech-c: remarks: TY6070JP TY6070JP For the complete set of bogons, please see: fltr-martian - special use and reserved prefixes. fltr-bogons - fltr-unallocated + fltr-martian. notify: irr-admin@nic.ad.jp mnt-by: MAINT-JPIRR changed: irr-admin@nic.ad.jp changed: irr-admin@nic.ad.jp #RIPEx3 changed: irr-admin@nic.ad.jp #ARINx4 changed: irr-admin@nic.ad.jp #APNICx5 changed: irr-admin@nic.ad.jp #RIPEx2 changed: irr-admin@nic.ad.jp #RIPEx2 changed: irr-admin@nic.ad.jp #LACNICx2 changed: irr-admin@nic.ad.jp #APNICx2 changed: irr-admin@nic.ad.jp #ARINx2 changed: irr-admin@nic.ad.jp #add 014/8 changed: irr-admin@nic.ad.jp #APNIC 112/8 113/8 changed: irr-admin@nic.ad.jp #AfriNIC 197/8 changed: irr-admin@nic.ad.jp #APNIC 110/8 111/8 changed: irr-admin@nic.ad.jp #ARIN 108/8 184/8 changed: irr-admin@nic.ad.jp #RIPE NCC 109/8 178/8 changed: irr-admin@nic.ad.jp #APNIC 180/8 183/8 changed: irr-admin@nic.ad.jp #APNIC 175/8 182/8 changed: irr-admin@nic.ad.jp #RIPE 2/8 46/8 changed: irr-admin@nic.ad.jp #APNIC 1/8 27/8 source: JPIRR Allocation されていない /8 を記載した IRR のオブジェクト現在 JPNIC にて本オブジェクトを随時更新 V4 枯渇時にお役御免

51 51 最近特に bogon フィルタ問題が顕著フィルタが未更新のために新規アドレス空間払い出し後に該当経路がきちんと利用できない IPv4 アドレスが残り少なくなってきているため IANA- >RIR への新規 /8 の割り振り後それほど時間が経過せずに LIR へアドレスが配布フィルタ更新時間の猶予が徐々に短くなってきており残りが少なくなるに従いより顕著になる可能性があるフィルタを逆にかけすぎる形になってしまうので到達性に問題が発生する実施の際には適切なタイミングでの更新が必要

52 52 現在の対応策自分側のフィルタ更新新規割り振り時にはきちんと更新する相手側のフィルタ更新問題到達出来ないサイトに直接コンタクトしてみる xnog の ML 等に投稿大抵他の人も同じ問題に遭遇している NANOG への IANA からのリマインダ On 09/10/2009 4:22, "Matthew Walster" <matthew at walster.org> wrote: > A customer of mine is reporting that there are a large number of addresses > he can not reach with his addresses in the 109/8 range. This was > declassified as a BOGON and assigned by IANA to RIPE in January > > If you have a manually updated BOGON list, can I please ask that you review > it and update it as soon as possible please? His addresses in 89/8 and 83/8 > work just fine, hence this presumption of BOGON filtering. This might be a good moment to list all the /8s allocated so far this year. 046/8 RIPE NCC whois.ripe.net ALLOCATED 002/8 RIPE NCC whois.ripe.net ALLOCATED 182/8 APNIC whois.apnic.net ALLOCATED 175/8 APNIC whois.apnic.net ALLOCATED 183/8 APNIC whois.apnic.net ALLOCATED 180/8 APNIC whois.apnic.net ALLOCATED 178/8 RIPE NCC whois.ripe.net ALLOCATED 109/8 RIPE NCC whois.ripe.net ALLOCATED Also, I'd like to mention that if you ever want to check your filters against the registry, we have made the columns sortable. It's now nice and easy to identify newly allocated /8s. Regards, Leo Vegoda

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

54 54 その他ルーティングセキュリティインフラアドレスの経路非広告 V4 の場合特定のブロックをインフラブロックにアサインし該当経路を広告しないケースもある V6 の場合細かく分割するかあらかじめ特定の空間のみをインフラ用にしておけば対応はできるが本来的に良いかどうかは別 DDoS 攻撃 V4 なのか v6 なのか

55 55 ディスカッション IPv4 ルーティングこれから v4 フルルートどうしますか? どこまで真面目にやり続けますか? メモリが枯渇しない限り頑張りますか? IPv6 ネットワークとルーティングきちんと準備は進んでいますか? IPv6 の経路集約は頑張りますよね? IPv6 bogon filtering やります? やってます? IPv6 は空間が大きいためホワイトリスト方式? 他に名案は? その他 OSPFv3 のセキュリティは? ボーダーでフィルタ?

BGP属性に関するインシデント事例紹介 Bogonフィルタ未更新問題について

BGP属性に関するインシデント事例紹介 Bogonフィルタ未更新問題について BGP 属性に関するインシデント事例紹介 Bogonフィルタ未更新問題について NTT Communications Tomoya Yoshida 2 内容 BGPパス属性関連のインシデント事例 2007 年 2009 年に発生した 4 つの事例 Bogon フィルタに関する問題新規割り振りアドレスに対するフィルタが更新されず特定のサイトへ到達性がない 3

IPv4/IPv6時代の ルーティングとセキュリティ

IPv4/IPv6時代のルーティングとセキュリティ