Microsoft PowerPoint - t1-Miya Kohno-MK_IPv4v6_IW2011

Size: px

Start display at page:

Download "Microsoft PowerPoint - t1-Miya Kohno-MK_IPv4v6_IW2011"

えいしろういさやま
4 years ago
Views:

1 IPV4/V6 移行共存技術について 30 Nov 河野美也 Miya Kohno,

2 AGENDA 1. 現状のアップデート 1 11 IPv6 普及状況 1 2 その他の環境変化 2. 共存移行技術 2 1 基本となる要素技術 2 2 共存移行のためのツール現在検討されている共存移行ツール一覧ツール選択のためのガイドライン共存移行ツールへの補足 3. 共存移行のデザイン 3 1 アドレス集約 (NAPT) 構成に関する考慮点 3 2 対象別シナリオ例 3 3 (APPENDIX) IETF82よりアップデート 4. まとめ 2

3 IPV6 普及状況 (1) IPV6 対応 ALEXAトップランクサイト Top 1000 Webサイト中 21% 2.1% net 3

4 IPV6 普及状況 (2) IPV6 対応トップランクサイト詳細 Top 1M Web サイト中 1.3% 4

5 IPV6 普及状況 (3) DNS QUERY V4 DNS Query に対する割合 2% 5

6 IPV6 普及状況 (4) 経路数 V4 経路に対する割合 7573/ =1.9% 6

7 IPV6 普及状況 (5) イノヴェーション理論と普及曲線普及率が16% あたりを越えると positive feedback kloop による相乗効果により一気に普及する新技術への移行のためには Chasm( 市場の移行を阻害する深い溝 ) を越えなくてはならない普及曲線 % t Diffusion of Innovations E.M. Rogers Chasm Geoffrey A. Moore 7

8 その他の環境変化 (1) 仮想化抽象化クラウド化物理構成に近い概念 Software Services Storage Applications Servers/ Computers Layers of Complexity Network Virtualized Workloads Shared Storage 8 物理構成にはとらわれない柔軟なサーヴィスコンテンツ提供

その他の環境変化 (2) サーヴィスとインフラの関係変化 IP Services Plane SERVICES INFRA Priva ate services Lea ased Lines, Fram me

IPenabled mobile handsets ) Infrastructure Control Plane MPLS Data Plane (P2P, P2MP, MP2P, MP2MP) IP VP

istribution (separate n/w w) IaaS サーヴィスとしてのインフラが支えるサーヴィスとしてのインフラ.

9 その他の環境変化 (2) サーヴィスとインフラの関係変化 IP Services Plane SERVICES INFRA Priva ate services Lea ased Lines, Fram me Rela ay ATM, POTS LEGACY / OTN SW rnet, ATM, FR PWs LS/VPWS) Ether (VPL DTV IMS (services delivered to IPenabled mobile handsets ) Infrastructure Control Plane MPLS Data Plane (P2P, P2MP, MP2P, MP2MP) IP VP PNs VoIP VoIP Peering Internet (search, e- commerce, advertising, video, IM, over-the-top ) IPT TV/VoD istribution (separate n/w w) IaaS サーヴィスとしてのインフラが支えるサーヴィスとしてのインフラ... が支えるサーヴィス Ethernet Framing TV Di OTN Muxing (G.709, FEC, OAM) DWDM Fiber インフラがありそれがサーヴィスを支える 9

10 その他の環境変化 (3) L7 AWARE NETWORK!! SP/ISP networks DNS CSPs CPEs example.com Service Provider CMC GSLB SLB DB Cache Cache Origin Servers Cache Management Content /L7 Awareness 10

11 その他の環境変化 (4) 仮想化アーキテクチャと多様性 Translate Customer A Internet (IPv4) Tunnel Network A (IPv6) Customer B Network B1 (VPN IPv6) Network B3 (IPv6) Internet (IPv6) B1 B2 Network B2 (IPv4) B3 11

12 ここまでのまとめ今のネットワーク環境はもはや一枚岩ではない仮想化抽象化再帰性多様性普及度を議論することの意味はあまり大きくなくなった Rogers, Mooreらの普及理論はマーケットが一枚岩であることを前提としている IPv4 も IPv6 もルーティングインスタンスの一つに過ぎない相互接続が必要なところに相互接続を推進する続目的と状況に応じた相互接続方法の適用重要なのはコンテンツ L7 Aware Network!! 12

13 AGENDA 1. 現状のアップデート 1 11 IPv6 普及状況 1 2 その他の環境変化 2. 共存移行技術 2 1 基本となる要素技術 2 2 共存移行のためのツール現在検討されている共存移行ツール一覧ツール選択のためのガイドライン共存移行ツールへの補足 3. 共存移行のデザイン 3 1 アドレス集約 (NAPT) 構成に関する考慮点 3 2 対象別シナリオ例 3 3 (APPENDIX) IETF82よりアップデート 4. まとめ 13

14 基本となる要素技術 (1/2) Dual Stack TCP/UDPv4 TCP/UDPv6 TCP/UDPv4 各 L3 ノードが IPv4 と IPv6 の双方をサポートする IPv4 PHY/Data Link IPv6 Dual Stack の特記事項ルーティングドメイン内の全ノードが Dual Stack 対応する必要がある一面 (single control plane) に異なるAddress Familyが混在するアドレス選択のポリシー IPv4とIPv6の優先度は状況により異なるトポロジー設計のポリシー IPv4とIPv6のトポロジー : 相似にするか別物にするか IPv4アドレスの節約にはならない共存移行時には扱いにくい両者の仮想化的な分離とアドレス節約ための方策が別途必要 14

15 基本となる要素技術 (2/2) Tunneling/ Encapsulation パケットを任意のヘッダでカプセル化しカットスルーする内側パケットの情報はそのまま保持される用語 (Tunnel( (p2p), p), Encap (any2any)) y)) を使い分ける場合もある 44 over 6, 6 over 4 Translation IPv4 <-> v6 のプロトコル変換を行う Tunnel によるオーヴァヘッドや隠蔽性はないアプリケーションによっては ALG が必要になる 6 4, NAPT binding (+PCP) IPv4のアドレス部とポート部を使い N:1のアドレス集約を行うアプリケーションによっては NAT 越え技術 ALGが必要になるネットワークサーヴィス側に置かれる場合 CGN/LSN と呼ばれる 4(private) 4(public) 15

16 現在検討されている主な共存ツール一覧 (1/3) 名称概要標準化状況 (2011 年 11 月現在 ) 基本要素技術 NAT44(4) IPv4 接続性の提供 draft ietf behave lsn itfbh NAPT(CGN/LS 関連 : Carrier/ISP 側でNAPTを実施する requirement 04 (WG draft) N) RFC4787, RFC5382, RFC5508 DS Lite IPv6インフラ上での IPv4 接続性の提供 Carrier/ISP 側でNAPTを実施する 4 over 6 IPv6 インフラ上での IPv4 接続性の提供 RFC6333 (Proposed Standard) draft ietf softwirepublic 4over6 00 (WG draft) Tunnel NAPT(CGN/LS N) 備考関連 : GW INIT DSLITE Tunnel 関連 : Stateless 4 over6 用語の補足 IPv4/v6 接続性 IPv4/v6サーヴィス(3VPN 的 ) IPv6 v4プロトコル変換 IPv4/v6インターネットへの接続性とトランスポートの提供 IP/MPLS 網を介した別サイト (IPv4/v6) とのVPNの提供プロトコル変換による IPv4インターネットの接続性提供 16

17 現在検討されている主な共存ツール一覧 (2/3) 名称概要標準化状況 (2011 年 11 月現在 ) 基本要素技術 4d 4rd IPv6 インフラ上での draft murakami EncapsulationE l A+P(RFC6346, (stateless IPv4 接続性の提供 softwire 4rd NAPT(CPE) Experimental) も 4v6 tunnel CPE 側でNAPTを実施す 00(individual draft) Stateless Tunnel る depres softwire approach mode) draft depres softwire 4rd addmapping 01(individual draft) stateless IPv6 インフラ上での draft dec stateless dec Translation 4v6 IPv4 接続性の提供 4v 00(individual draft) NAPT(CPE) translation CPE 側でNAPTを実施す draft murakami る softwire 4v6 mode) translation 00(individual draft) SA46T IPv6インフラ上での IPv4 サーヴィス (L3VPN 的 ) 提供 draft matsuhirasa46t spec 03(individual draft) Encapsulation SA46T AS AS の場合 : NAPT(CPE or Server) 備考 L3VPN over IPv6 infrastructure 17

18 現在検討されている主な共存ツール一覧 (3/3) 名称概要標準化状況 (2011 年 11 月現在 ) 基本要素技術 6d 6rd IPv4 インフラ上での Proposed dstandard d TunnelT l RFC5969 IPv6 接続性の提供 6PE, 6VPE Softwire Mesh NAT64 IPv4インフラ上での IPv6 サーヴィス (L3VPN 的 ) 提供 IPv4 or IPv6インフラ上での IPv6 or IPv4サーヴィス (L3VPN 的 ) 提供 IPv6からIPv4へのプロトコル変換備考 Proposed Standard Encapsulation RFC4798(6PE) RFC4659(6VPE) Proposed Standard Encapsulation RFC5565(softwir e framework) Proposed Standard Translation RFC6146 Yet to come 標準化状況への補足 Proposed Standard RFC Experimental RFC WG draft Individual draft 標準へと提唱されたRFC 実験的 RFC IETF 作業部会 (Working Group) で認められたドラフト個人提案のドラフト 18

19 共存移行ツールの方式まとめ Customer Access/Aggregation/Core Backbone Global Public Network CPE IPv4 IPv4 NAT444 CGN/LSN IPv4 IPv4 IPv4 6rd CE 6 over 4 tunnel 6rd IPv6 IPv4/IPv6 IPv6 CPE IPv4 IPv6 IPv6 IPv6 BR NAT64 IPv6 IPv6/IPv4 IPv4 4rd CE 4 over 6 tunnel 4rd IPv4 IPv6/IPv4 IPv4 DS LITE B4 IPv6 IPv4 IPv6/IPv4 IPv4 BR 4 over 6 tunnel DS LITE AFTR 19

20 ツール選択のためのガイドライン (1/5) 選択のクライテリア (a) 目的 (b) ネットワークインフラ (c) サーヴィス形態 (d) Translation Binding の場所 20

21 ツール選択のためのガイドライン (2/5) (a) 目的 1. IPv4 接続性の提供アドレス共用必要 2. IPv4 接続性の提供アドレス共用なし 3. IPv4(L3VPN 的 ) サーヴィス提供 4. IPv6 接続性の提供 5. IPv6(L3VPN 的 ) サーヴィス提供 6. IPv6 >IPv4 プロトコル変換サーヴィス提供 (*) Public IPv4 枯渇対策としてアドレスの節約をしたい場合はアドレス共用必要 21

22 ツール選択のためのガイドライン (3/5) (b) ネットワークインフラ 1. IPv4 2. IPv6 (*) Dual Stack の場合もどちらの Address Family を使用するかで二者に分けられる 22

23 ツール選択のためのガイドライン (4/5) (c) サーヴィス形態 1. Managed 2. Unmanaged (*) Managed M dservice の場合は CPE やモバイル端末をサーヴィス提供者の管理下におくことができるこのことは端末側の機能の追加変更が比較的容易管理情報 ( 例えば NAPT 機能で使用するアドレスやポートレンジ ) の配布が比較的容易といった特徴につながる Unmanaged Service の場合もその機能が十分に成熟して標準として定着し市場に普及すれば実現可能であるがそれまでにはかなりの時間がかかる 23

24 ツール選択のためのガイドライン (5/5) (d) Translation Binding の場所 1. ネットワーク側 2. ユーザ側 Data Center 1. ネットワーク側 Backbone Access Network CPE CPE 2. ユーザ側 24 (*) Translation, Bindingが専らユーザ側で行われる場合ネットワーク側でTranslation Stateを保持する必要が無いため Stateless 方式と呼ばれる

25 (A) 1 IPv4 接続性の提供アドレス共用必要 (b) ネットワークインフラ (c) Managed Service? b1: IPv4 b2: IPv6 c1: Managed c2: Unmanaged c1: Managed c2: Unmanaged (d) NAT Binding の場所 (d1: ネットワーク側 d2: ユーザ側 ) d1 d2 d1 d2 d1 d2 d1 d2 NAT44(4) DS Lite 4rd, 4v6 25

26 (A) 2 IPv4 接続性の提供アドレス共用なし (b) ネットワークインフラ (c) Managed Service? b1: IPv4 b2: IPv6 c1: Managed c2: Unmanaged c1: Managed c2: Unmanaged 現行 IPv4 接続サーヴィス 4 over 6 26

27 (A) 3 IPV4(L3VPN 的 ) サーヴィス提供 (b) ネットワークインフラ (c) Managed Service? b1: IPv4 b2: IPv6 c1: Managed c2: Unmanaged c1: Managed c2: Unmanaged 27 現行 L3VPN サーヴィス (e.g. RFC4364, BGP/MPLS VPN) Softwire Mesh, SA46T

28 (A) 4 IPV6 接続性の提供 (b) ネットワークインフラ (c) Managed Service? b1: IPv4 b2: IPv6 c1: Managed c2: Unmanaged c1: Managed c2: Unmanaged 6rd, IP tunneling IPv6 接続サーヴィス 28

29 (A) 5 IPV6(L3VPN 的 ) サーヴィス提供 (b) ネットワークインフラ (c) Managed Service? b1: IPv4 b2: IPv6 c1: Managed c2: Unmanaged c1: Managed c2: Unmanaged 6PE, 6VPE 29

30 (A) 6 IPV6 IPV4 プロトコル変換サーヴィス (b) ネットワークインフラ (c) Managed Service? b1: IPv4 b2: IPv6 c1: Managed c2: Unmanaged c1: Managed c2: Unmanaged (d) NAT Binding の場所 (d1: ネットワーク側 d2: ユーザ側 ) d1 d2 d1 d2 d1 d2 d1 d2 NAT64(CPE 側 ) NAT64(Server 側 ), SLB, Cache 30

31 共存移行ツールへの補足 PCP アプリケーションによる NAPT の制御 NAPT によるアプリケーション制限の緩和可能性 Virtual CPE CPE 機能の仮想化クラウド化可能性 CPE 機能を高度化することに伴う高コスト化管理負荷の軽減可能性 L7 awareness ネットワークにおけるL7 機能取り込み L7 awareコミュニケーション (NAT64+ALG, キャッシュ, ロードバランサーなど ) ユーザ側やサーヴィス側は IPv4/v6 を意識せずにユーザが目的のコンテンツにアクセスできるようになる可能性 31

32 PCP (1/3) PCP: Port Control Protocol NAPT のポートを制御する技術 PCP は STUN/TURN/ICE などの NAT 越え技術とは異なりアプリケーションと NAT との明示的なやりとりであるホームルータでの UPnP IGD や NAT PMP の SP 版拡張とも捉えられる IETF PCP WGにて標準化作業中 (*) UPnP IGD :Universal Plug and Play Internet Gateway Device NAT PMP : NAT Port Mapping Protocol PCP WG chairs: Alain Durand (Juniper) & Dave Thaler (Microsoft) 32

33 PCP (2/3) 使用イメージの例 : PCP を用いて ISP NAT に対し使用ポートのネゴシエーションを行う CPEは PCPによるUPnP NAT PMPのリレーを行うまたは端末のPCP 要求を中継する PCP ISP network CPE NAT IPv4 UPnP or NAT PMP or PCP PCP (*) () (*) ISP NATを PCPを使用するユーザへの Web Portal として設定することも可能 33

34 PCP (3/3) 実装モデル UPnP IGD CPE UPnP IGD proxy PCP Client PCP Server CPE NAT PMP NAT PMP proxy PCP Client PCP Server HTTP CPE HTTP managed PCP Client PCP Server CPE PCP Server 34 PCP Client

35 VIRTUAL CPE (1/2) CPE 機能の高度化 Typical CPE Functions α NAT Routing / IP Forwarding Firewall DHCP + 各種共存移行技術仮想化技術など MoCA/ HPAV/ HPNA3 Voice Access Point Switch Modem / ONT 35

36 VIRTUAL CPE (2/2) Virtual CPE による機能サーヴィス高度化と管理負荷軽減コスト削減 Layer 2 CPE Connectivity / Switching Wireless AP Zero Touch Provision p/q Portability Mobile/Remote VPN Members C CPE Context Internet Virtual CPE Routing (IP Forwarding), SFW NAT, DHCP Server/Relay Dynamic Service Activation via RADIUS / DHCP interaction Dynamic VLAN Assignment Dynamic Policy & Profiles; Qos, Accounting, Traffic Mgmt Captive Portal Redirection My Home VPN services Client Delivery Client Termination SP Data Center Wii 36 In Home Services My Home VPN SP Cloud Services Private IP Address Domain Public/Private IP Address Domain

37 L7 AWARENESS (1/2) IPv6 clients DNS AAAA 2001: IPv6 IPv4 IPv4 address of NAT 64 Translator Cloud Reverse Proxy (Cache) Load Balancer 37

L7 AWARENESS (2/2) L7 Aware Networkの介在によりユーザ側もサーヴィス側もほとんど意識せずにユーザへのサーヴィスを続行できるヴィスを続行できる DNSに www.example.

38 L7 AWARENESS (2/2) L7 Aware Networkの介在によりユーザ側もサーヴィス側もほとんど意識せずにユーザへのサーヴィスを続行できるヴィスを続行できる DNSに Translator (/Load balancer/cache) のIPv6アドレスを追加する Translator 側にて Origin Server( の IPv4 アドレスに戻して通信を行う F5 IPv6 solution A10 networks Interop IPv6 clients IPv6 IPv4 IPv4 address of DNS AAAA 2001: NAT 64 Translator Cloud

39 AGENDA 1. 現状のアップデート 1 11 IPv6 普及状況 1 2 その他の環境変化 2. 共存移行技術 2 1 基本となる要素技術 2 2 共存移行のためのツール現在検討されている共存移行ツール一覧ツール選択のためのガイドライン共存移行ツールへの補足 3. 共存移行のデザイン 3 1 アドレス集約 (NAPT) 構成に関する考慮点 3 2 対象別シナリオ例 3 3 (APPENDIX) IETF82よりアップデート 4. まとめ 39

40 アドレス集約 (NAPT) 構成に関する考慮点 (1/3) IPv4アドレスを節約しながら新規ユーザに対して IPv4 を割り振る場合は NAPT によるアドレス集約が避けられない NAPT の実装にはいくつかのアーキテクチャ選択肢がありそれがネットワークサーヴィスの特性を左右する 40

41 アドレス集約 (NAPT) 構成に関する考慮点 (2/3) ネットワークサーヴィス特性への影響項目運用管理性機器コスト HA 耐障害性アドレス集約効率ログ保管問題内容運用管理の方式機器運用管理アドレスマッピング管理キャパシティ計画管理加入者管理機器導入にかかるコストセッションあたりコスト帯域あたりコストユーザあたりコスト稼働率に関わるポリシー {{ 集中分散 } と影響範囲冗長方式 (1:1, 1:N) 障害切替え方式 (Act Act, Act Sby) アドレスの共有度合い (1つのPublicアドレスを何ユーザでシェアできるか ) 通信元特定のために大量のセッションログを保管しなくてはならない問題アプリケーション制約 Peer to Peer 等一部のアプリケーションが使えなくなる可能性 41

42 アドレス集約 (NAPT) 構成に関する考慮点 (3/3) 主なアーキテクチャ選択肢 Translation Port Management Tunnel 42

43 アーキテクチャ選択肢 TUNNEL Tunnel Tunnel するしない始点終点をどこに置くか運用管理性機器コスト HA ( 耐障害性 ) アドレス集約効率ログ保管問題アプリケーション制約 43

44 アーキテクチャ選択肢 TRANSLATION Translation {protocol translation port translation } {Stateful Stateless} * どこで translation するか * State が必要になるケース Session 情報を使ってマッピングを行う場合 N:1 translation Dynamic translation ただしユーザ側でTranslationを行えばネットワーク側でStateを持つ必要はない運用管理性機器コスト HA ( 耐障害性 ) アドレス集約効率ログ保管問題アプリケーション制約 44

45 アーキテクチャ選択肢 PORT MANAGEMENT Port Management Port Control {Yes No} * Port Allocation ** {Dynamic Bulk lk Dt Deterministic iiti } * Port Control については PCP の項 (p.33 ) 参照 ** Port Allocationについては次ページ以降参照運用管理性機器コスト HA ( 耐障害性 ) アドレス集約効率ログ保管問題アプリケーション制約 45

46 ログ容量問題について送信元特定のために Translationのログを保管しなくてはならないしかしそのままではログ容量が膨大になる多量のストレージ容量 = 高コスト何らかの対策が必要ログの内容を削る ( セッションスタート時のみログし終了時はログしないなど ) Bulk( 塊り ) でポートを割り当てセッション毎のログではなくアロケーション毎のログにする (e.g. Port Bulk Allocation) Binding を static することによりログを不要にする (e.g. deterministic NAT, 4rd) 46

47 PORT ALLOCATION DYNAMIC NAT Amount Of Logging High High High Se ecurity Ratio Us sers/public IP 各セッションに対してポートをランダムに割り当てる (NAPT のデフォルト動作 ) 特徴 (Pros) 高いアドレス集約効率 ( 分割損なし ) セキュリティに強い (Random Port) (Cons) セッション毎のログが必要 Null Low Low 47 Public アドレスの使用ポート : User A User B

48 PORT ALLOCATION PBA (PORT BULK ALLOCATION) High High High セッション生成時に NAPT は連続的なポートをブロックで割り当てる割り当てたブロックの中から実際に使うポートがランダムに選択される ( そのユーザの ) 次のリクエストに対してはポートはそのブロックから割り当てられる Amount Of Logging Se ecurity Ratio Us sers/public IP Null Low Low すべてのポートが未使用になった時点で割り当ては解消されるログはブロック割り当て時と開放時にのみ生成される特徴 (Pros) ログを大きく削減できるアドレス集約効率ログの量セキュリティ度合いの兼合いをチューニング可能 (Cons) ブロックサイズタイマーなどについてチューニング必要 48 Public アドレスの使用ポート : User A User B

49 PORT ALLOCATION DETERMINISTIC NAT Amount Of Logging High High High Se ecurity Ratio Us sers/publi IP Null Low Low ユーザに対して IPアドレスとPORTブロックを固定的に割り当てる新たなセッションに対してそのポートレンジの中からダイナミックに決定される特徴 (Pros) ユーザは常に同じPublic IPアドレスが割り当てられることになるログの必要は無くなる (Cons) アドレス集約効率は低くなる ( 分割損使っていないユーザへも常に割り当てられたまま ) ポートが足りなくなっても新たなブロックをアサインすることはできない 49 Public アドレスの使用ポート : User A User B

50 対象別シナリオ例 ISP, Access Provider Mobile SP 企業 Contents Provider 50

51 対象別シナリオ例 ISP, ACCESS PROVIDER ネットワークの技術基盤を提供する立場状況に応じてできるだけ広い選択肢を提供する {public NATed IPv4} over {native tunnel/translate virtualization} IPv6 over {native tunnel/translate virtualization} 51

対象別シナリオ例 MOBILE SP 垂直ビジネスモデル ( 端末まで Managed) Mobility サポートのため端末からアンカーポイントポイントまでのTunnelが必要端末 {dual stack IPv6 only} PC dongle 等も考えれば少なくとも当面は dual stackが推奨 PDP context {IPv4 IPv6 IPv4/IPv6 } コスト面で

52 対象別シナリオ例 MOBILE SP 垂直ビジネスモデル ( 端末まで Managed) Mobility サポートのため端末からアンカーポイントポイントまでのTunnelが必要端末 {dual stack IPv6 only} PC dongle 等も考えれば少なくとも当面は dual stackが推奨 PDP context {IPv4 IPv6 IPv4/IPv6 } コスト面で IPv4/v6 推奨 {(public) NATed IPv4} over {tunnel/translate} IPv6 over {tunnel/translate} GW INIT DSLITE MPLS VPN などによるトラフィック分離 Backhaul & Packet Core PGW GGSN HA NAT44 NAT64 Mobile SP Service The Internet 52

53 対象別シナリオ例企業ネットワークの提供は本業ではないなるべく手軽な方法が望まれる外部向け情報サーヴィスの IPv6 化 DMZ の IPv6 化 L7 (NAT64, Reverse Proxy, Load balancer) による IPv6 対応 IPv6 サイト同士は 6PE/6VPE などを使って接続バックボーンにMPLSがなければ MPLS over IPを使用可能 53

54 対象別シナリオ例 CONTENT PROVIDER (1/4) 企業と同様ネットワークの提供は本業ではない本業はコンテントの提供と効率的配布という見方もあるが実際に世界のIPv6 化を最も強く牽引しているのは Google そして Akamai, Yahoo, Facebook, Netflix Google IPv6 history > NANOG50 における Lorenzo Colitti 氏資料より 54

の配置も自分たちで行う勝手にCache されたくない ( > http cache control directive)

55 対象別シナリオ例 CONTENT PROVIDER (2/4) 特にGoogle, Akamaiは Analyticや広告主への情報提供のためにユーザの IP 情報を把握したい Global な Cache の配置も自分たちで行う勝手にCache されたくない ( > http cache control directive) SP による NAPT によって IP 情報を隠蔽されたくない IPv6 は IPv4 よりもさらに国地域などが明示的になると期待される Global IPv6 推進! 55

56 対象別シナリオ例 CONTENT PROVIDER (3/4) Content Providerからみた IPv6サーヴィス提供 (AAAA の提供 ) に関する問題点 IPv6でアクセスするかを決めるのはユーザ側なので提供側が予期せず QoE を下げる可能性があるその他もろもろ IPv6 閉域網とフォールバック問題 ( 日本 ) TCP RST AAAA filtering Policy table 書き換え ( table/) PMTUd と ICMP rate limiting World IPv6 Day, World IPv6 Week, World IPv6 Month で徐々に解決 56

57 対象別シナリオ例 CONTENT PROVIDER (4/4) IPv6でわくわくすることをやる Business Incentive を追求する新しいしくみを実現するまたはあまり無理せず状況を愉しむ状況に応じてなるべく手軽な方法を実行する (p.53) 57

58 (APPENDIX) IETF82 UPDATE TREND 各種共存移行技術に関するトレンド A+P/4rd 6to4 Deployed NAT444 6PE,6VPE, 6 Dual stack 6rd NAT PT DS Lite PCP Momentum NAT over6

59 (APPENDIX) IETF82 UPDATE STATELESS に関する議論ネットワーク側で State を持つことに対する懸念と議論ログ容量問題 High Availability のための冗長構成と切り替えの問題スケーリングやコストに関する懸念 Stateless を指向する多くの方式に関する提案と議論 (A+P 4rdとそのVariation divi) IPv4 v6 mapping (tunnel? translation?) CPE への機能追加が大きくなる傾向 ICMP や PPTP のための ALG は必要か fragmented packet をどうするかその他議論渦中 59

60 (APPENDIX) STATELESS DETERMINISTIC NAT Host 1 Host 2 Internal Hosts Customer Premises draft penno softwire sdnat 01 SD CPE SP access SD CPE x SP access SP core SD CPE y IPv4 address n IPv4 address n+1 60

61 (APPENDIX) STATELESS DETERMINISTIC NAT 特徴他のStatelessソリューションの長所を継承 No Logs, No State, t 冗長化構成が容易 CPE への変更は最小化使用可能ポートを限定するのみ [1024 Max] それ以外の CPE 側の変更は一切無い柔軟性アクセスネットワークのリナンバリングの必要なく IPv4グローバルアドレスの配分が可能アクセスネットワークは IPv6でもIPv4でもよい SD NAT for DS Lite, SD NAT for NAT444 61

62 AGENDA 1. 現状のアップデート 1 11 IPv6 普及状況 1 2 その他の環境変化 2. 共存移行技術 2 1 基本となる要素技術 2 2 共存移行のためのツール現在検討されている共存移行ツール一覧ツール選択のためのガイドライン共存移行ツールへの補足 3. 共存移行のデザイン 3 1 アドレス集約 (NAPT) 構成に関する考慮点 3 2 対象別シナリオ例 3 3 (APPENDIX) IETF82よりアップデート 4. まとめ 62

63 まとめ共存は避けられない IPv6 もあるひとつの Routing Instance と捉える共存技術は仮想化技術にも通じる仮想化による多様性への対応新たなしくみやビジネス機会を追求する好機 Diverge and Converge 多様性はよいことしかし発散のあとは収斂も必要 63

Microsoft PowerPoint - ykashimu_dslite_JANOG26_rev

Microsoft PowerPoint - ykashimu_dslite_JANOG26_rev IPv6 時代のを考える ~DS-Lite 8 th July 2010 鹿志村康生 (Yasuo Kashimura) yasuo.kashimura@alcatel-lucent.com DS-Lite ( Dual stack Lite) draft-ietf-softwire-dual-stack-lite Dual-Stack Lite Broadband Deployments Following