1 Internet Week ショーケース in 広島 世界で進む IPv4 の品質劣化と IPv6 の導入 ところで企業の IPv6 対応は? 2018.5.31 日本インターネットエクスチェンジ 日本インターネットエクスチェンジ株式会社日本ネットワークイネイブラー株式会社日本インターネットエクスチェンジ Akira (JPNE) Nakagawa (JPIX) 中川あきら中川あきら
会社概要 社名 日本インターネットエクスチェンジ株式会社 (JPIX) 設立 資本金 株主 1997 年 7 月 10 日 451 百万円 KDDI 株式会社 株式会社ブロードバンドタワー ソフトバンク株式会社 ソニーネットワークコミュニケーションズ株式会社 ビッグローブ株式会社 富士通株式会社 株式会社朝日ネット 株式会社ケイ オプティコム 三菱電機インフォメーションネットワーク株式会社 日本初商用 IX ISP 等 9 社出資 中立 IX 専業 顧客数日本最大約 170 社 トラヒック増 地方 / 海外顧客増 2
自己紹介 氏名 中川あきら 所属 2010 年 4 月 2017 年 3 月 JPIXとJPNEを兼務 2017 年 4 月 JPIX 本日の講演に関する主な活動 RFC6888 CGN Co-author Internet Week 2017 プログラム委員 (IPv6 担当 ) IPv6 Summit 運営 インターネット協会 JPOPF 運営 JPOPF 運営チーム ( 旧ポリシー WG) (JPOPF Steering Team:JPOPF-ST) 3
広島とわたし 2009 年 IPv6 セミナー (1 回目 ) IETF76 実行委員で広島に何度も通う < 期間が空く > 2017 IPv6 セミナー (2 回目 ) 2018 IPv6 セミナー (3 回目 ) JANOG41 IW ショーケース ( 本日 ) 4
Internet Week 2017 での試み 法人 の IPv6 を採り入れました IPv6を導入している企業は極めて少ない 業界にノウハウが乏しい 興味を持つ人は少ない しかし 少しでもきっかけが必要 集客できなくても良い やるべきだ!! 5
IW2017 IPv6 セッション登壇者 6 IPv6 の普及状況中川あきら ( 日本インターネットエクスチェンジ株式会社 (JPIX)) IPv6 の普及状況とセキュリティ対策の必要性 IPv6 セキュリティ概説 - 運用編 - 藤崎智宏さん ( 日本電信電話株式会社 ) IPv6 セキュリティ概説 - プロトコル編 - 北口善明さん ( 東京工業大学学術国際情報センター ) 企業ネットワークの IPv6 対応廣海緑里さん ( 株式会社インテック ) 本日の資料の構成順
本セッションについて 7 各発表を忠実に再現するものではありません 各発表内容を自分の言葉に置き換え アレンジしました 講師の資料を切り貼りしたスライドも存在しますが その際には出典 URL を記載しました
目次 8 IPv6 普及状況 IPv6 のセキュリティー 法人の IPv6
国内で進む IPv6 NGN における IPv6 対応状況 IPv6 契約数 ( 百万 ) IPv6 User (Million Accounts) IPv6 普及率 今頃 50%! 今頃 1 千万契約! 平均世帯人数を2.5 人とすると 今頃 2 千 5 百万人! IPv6 高度推進 普及委員会 http://v6pc.jp/jp/spread/ipv6spread_03.phtml 9
国内で進む IPv6 モバイル 3 社 本格対応開始!! Source : 総務省 http://www.soumu.go.jp/main_content/000517037.pdf 10
国内で進む IPv6 CATV の IPv6 ドコモ光タイプ C のサービス提供が IPv6 対応の新しいモチベーションとなっている ドコモ光タイプ C とは ケーブルテレビの設備を使ってドコモが提供する光インターネットサービス ( 卸サービス ) CATV 事業者がドコモにサービスを卸す際に IPv6 対応が条件となっている Source : ドコモ https://www.nttdocomo.co.jp/hikari/charge/type_c/ 増加中 11
US の主要プレーヤーの IPv6 対応状況 各プレーヤーが すさまじいスピードで IPv6 対応中 多くのプレーヤーは世界進出しているため各国でもこの傾向! 大手コンテンツ事業者 Google Apple Dropbox Facebook Linked-in Wikipedia Amazon AWS Netflix Instagram Microsoft Azure Yahoo.com CNN / NBC 大手 NW 事業者 ( 固定 移動 ) ATT 65% Comcast 65% Verizon Wireless 84% T-Mobile 93% 大手端末メーカー / OS 固定 Microsoft Win MAC iphone ipad Android モバイル 普及率は IPv6 launch より 12
クラウドの IPv6 対応 (Facebook 社 ) 2017 年 1 月 18 日 Facebook Data Center(DC) 内 Dual Stack から IPv6-only へ 全アプリとサービスを IPv6 対応へ 現在 DC 内部の 99% は IPv6 内半分は IPv6-only 数年後に IPv4 廃止へ Internet からのアクセス 15% が IPv6 85% が IPv4 IPv4 アクセスは Load Balancer で IPv6 に Source: Facebook https://code.facebook.com/posts/635645183305089/legacy-support-on-ipv6-only-infra/ 13
IAB (*1) の声明 ( IETF ) IAB は 標準化団体の IETF において今後の新しいプロトコルでは IPv4 への後方互換を廃止し IPv6 で最適化するよう期待 Source : https://de.wikipedia.org/wiki/internet_society Source : https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ (*1) IAB : インターネットの技術コミュニティ全体の方向性やインターネット全体のアーキテクチャについての議論を行う技術者の集団 14
IPv6 優先に関する標準化 Happy Eyeballs v2 (RFC8305) により IPv6 IPv4 の両接続がある場合 IPv6 を優先 Fallback Happy Eyeballs (RFC6555 2012) Happy Eyeballs (Apple 独自仕様 2015) Happy Eyeballs v2 (RFC8305 2017.12) Server Server Server Server IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 Try Timeout Retry 同時接続先にセッションを確立した方で通信 IPv4 にハンディ 25ms 先にセッションを確立した方で通信 IPv4 にハンディ 50ms 先にセッションを確立した方で通信 名前解決に +25ms 名前解決に +50ms IPv4 での接続時に Timeout を待つ必要があった 改善 意図的に IPv4 に +25ms +50ms へ Clientは Resolution Delay を待つこと (Should) Resolution Delayは 50ms (Recommended) 15
IPv4 の現状 : 速度が極めて遅い例 アメリカにおけるモバイル商用回線の IPv4 のパフォーマンスの悪さを指摘 (Facebook 社プレゼンより ) Source : NANOG64 https://www.nanog.org/sites/default/files//meetings/nanog64/1033/20150602_huston_the_benefits_of_v3.pdf 16
IPv4 の現状 : アドレス共有に関連する問題提起 Europol より CGN 配下の 犯人を特定できない といった問題提起が出ている!! Europol : 欧州刑事警察機構 https://www.europol.europa.eu/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-forend-of-carrier-grade-nat-cgn-to-increase-accountability-online 17
ベルギーの事例 : IPv4 1 個当たりの最大共有数 警察を含む各組織で 最大 16 加入者としている May.2017 IAP: Internet Access Provider Source: https://ripe74.ripe.net/presentations/125-cgn-presentation-greg-mounier-ec3-ripe-74-budapest.pdf 18
国内大手事業者の事情 PPPoE 方式の現状 = 輻輳 2017 年 1 月 総務省のパブコメにおいて 個人 企業 業界団体等の多くが PPPoE 方式の網終端装置における輻輳 ( 混雑 ) について指摘 Source : http://www.soumu.go.jp/main_content/000467068.pdf 19
PPPoE 方式輻輳の理由 網終端装置の増設基準が セッション数 であるため トラフィックが増えても ISP の判断で増設できない Source : http://www.soumu.go.jp/main_content/000478903.pdf 20
PPPoE の輻輳度合い 21 年々 PPPoE( IPv4) の輻輳は悪化している 帯域は一定 1 契約当たりのトラフィックは年々増加中 総務省算出の 1 契約当たりのトラヒック 2017 年 11 月 : 276kbps ( 参考 ) NTT 東西社の増設基準は中型網終端装置の場合 IPv4 IPv6 それぞれ 1Gbps IF に 8,000 セッション 130kbps / セッション ( 換算 ) http://www.soumu.go.jp/main_content/000535404.pdf http://www.soumu.go.jp/main_content/000478907.pdf
アドレス共有による IPv4 の劣化 ( 一つのシナリオ ) 各国の JSP による IPv4 アドレス共有によって エンド端末やアプリで 3 つの注意が必要 ( 主として海外では大きな影響が出るのではないか ) 初期 ( イマココ ) アドレス共有装置導入 中期詰め込む (*1) 末期 NAT タイマーを短くし (*1) ポート番号を確保 1 アドレス共有そのものによる影響 2 ポート番号不足による影響 3 短時間でのセッション切断による影響 IPv4 Global アドレス共有装置 IPv4 Global アドレス共有装置 IPv4 Global アドレス共有装置 End Users (*1) MAP-E/MAP-T 等の Stateless 方式の場合は 最初からある一定数のポート数が確保されているため この影響は出ない 22
クラウド事業者や端末メーカー SE 等から見た IPv4 23 世界に市場を持つクラウド事業者や端末 /OS メーカー等は 以下を実行中 IPv4 通信できるようにクラウドや製品等をチューニング デグレしない IPv6 へのドライブ IPv6 は追加コストだった IPv4 IPv6 US 等はもうココイマココ 主副主副 複数種類の IPv4 への対応は追加コスト チューニング 1 ( ポート数 ) MAP-E NAT444 ISP1 ISP2 MAP-T DS-Lite 464XLAT IO-DATA バッファロー ISP3 ISP4 ISP5 v6 プラス チューニング 2 IPv6 ( セッション ISP6 ISP7 ISP8 ISP9 ISP10 タイマー ) チューニング n ISP11 ISP12 ISP13 ISP14 ISP16
国内の IPv6 普及で悩ましいこと 国内での IPv4 の質が秀逸であるために 日本人が世界的な IPv4 のデグレや IPv4 離れに気付きにくいこと IPv4 アドレスの購入により従来の品質を維持 IPv4-only 機器にも投資 IPv4 over IPv6 の高い品質 十分な帯域確保 十分なポート数確保 NAT における十分なセッション保持時間確保 国内コンテンツ事業者はフレッツ PPPoE(IPv4) 利用者から 遅い と苦情を受け IPv4 に懸念を持ち始めた ( イマココ ) 24
目次 25 IPv6 普及状況 IPv6 のセキュリティー 法人の IPv6
IPv6 に関するセキュリティ報告申告件数 https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s03/s3-fujisaki.pdf 26
IPv6 セキュリティ対策の必要性 https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s03/s3-fujisaki.pdf 27
IPv6 におけるセキュリティ https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s03/s3-fujisaki.pdf 28
(Path MTU Discovery) 技術的背景 29 インターネットの通信において 長いパケットが通らない場所が存在することがある トンネル区間の例 流せる最大データ長 1,500Bytes 1,500Bytes 1,500Bytes 未満 トンネルのヘッダが入るため 流せる最大長は短くなる 1,500Bytes Tunnel Ethernet Router Router Router Ethernet Ethernet Server Ethernet ここで言うトンネルとは PPPoE IPv4 over IPv6 IPv6 over IPv4 など 流せる最大データ長 = MTU (Maximum Transmission Unit)
(Path MTU Discovery) 長いパケットを通す手段 IPv4 vs IPv6 IPv4 では 中継ルーターがパケットを分割 ( フラグメンテーション ) していた IPv6 では 送信端末が分割して送る IPv4 Long Packet Long Packet 分割 + Tunnel Router Router Router Server + IPv6 分割 + + + Tunnel Router Router Router Server + なぜ 送信端末は流せるパケットの最大長を知っている? 30
(Path MTU Discovery) 送信端末が流せるパケットの最大長を知っている理由 31 事前に ICMPv6 を使って流せる長さを調査するため この調査の仕組みを Path MTU Discovery という Ethernet パケット長 1,500 の ICMPv6 Tunnel Router Router Router Ethernet Ethernet Ethernet Server 最大長は 1,500 です パケット長 1,500 の ICMPv6 最大長は 1,280 です パケット長 1,280 の ICMPv6 以下 繰り返し 数字は例
(Path MTU Discovery) Path MTU とセキュリティーの関係は? 32 仮に セキュリティー面で ICMPv6 をフィルターするべき という方針があったとしても 全ての ICMPv6 をフィルターアウトするべきではない IPv4 と違い 主信号に影響が出ることがあるため
33 IPv4 と IPv6 のアドレス払い出しの考え方 ISP が払い出すアドレスの場所とアドレスの種類が異なる (IPv4) 家庭用ルータの WAN 側 (ISP に隣接するインタフェース ) アドレスを 1 つ ISP 4G 家庭用ルータ [NAT] (IPv6) 家庭用ルータの LAN 側 (ISP から見ると 1 ホップ先 ) プレフィックス ( アドレス群 ) ISP 家庭用ルータ プレフィックス /48 /64 [NAT] プライベートアドレス プレフィックス (/64 n 個 )
アドレス等自動設定のためのプロトコル 多くの場合 端末に各種の情報を自動設定するために複数のプロトコルが併用されている 以下は典型的な例 ISP DHCPv6-PD (/48 /56 等 ) (PD : Prefix Delegation) ( 例 ) 2001:0db8:1234::/48 家庭用ルータ Default Route IPv6 Address DNS Proxy 等の IPv6 Address SLAAC 方式 (*1) RA (/64 の Prefix Default) DHCPv6 (DNS の IP 等 ) を併用して自動設定 ( 例 ) 2001:0db8:1234:5678::/64 (*1) SLAAC : Stateless Address Auto Configuration 34
35 宅内アドレス等の設定動作例 (SLAAC の例 ) RA : プレフィックス (IPアドレス) デフォルトルート DHCPv6 : DNS ProxyのIPアドレス等を設定 家庭用ルータ ISP DHCPv6-PD (/56 /48 etc.) DNS Proxy サーバ機能 DHCPv6 サーバ機能 IPv6 ルータ機能 DHCPv6 で払い出し DNS Proxy サーバの IP アドレス NTP サーバの etc. RA で払い出し IPv6 プレフィックス (/64) デフォルトルート 端末は両プロトコルでパラメーターをかき集める
36 RA と DHCPv6 で払い出せる情報 多くの端末は RA と DHCPv6 を併用して IP Address 等の情報を自動設定している RA の機能 DHCPv6 の機能 ISP プレフィックス ( 端末がアドレスを自動生成 ) 家庭用ルータ アドレス デフォルト経路 RA DHCPv6 DNS サーバのアドレス (*1) (RFC5006 後追いで標準化 ) 各種サーバのアドレス (RDNSS, etc.) (*1) (RFC6106 8106 後追いで標準化 (*1) ) 特記事項 市場に出回っている製品の全てが (*1) に対応しているわけではないため デフォルト経路を払い出せないため RA との併用が前提
IP Address 等自動設定のシーケンスイメージ (SLAAC の例 ) NS : Neighbor Solicitation IP(LLA (*1) ) と MAC は? 家庭用ルータ NDP Neighbor Discovery Protocol 注 (*1) Link Local Address (*2) Global Unicast Address DHCPv6 NA : Neighbor Advertisement IP(LLA (*1) ) と MAC は これ RS : Router Solicitation だれかルーターの人いる? RA : Router Advertisement 私ルーター IP(GUA (*2) ) と Default GW は RA から DNS のアドレスは DHCPv6 から入手せよ Prefix と Default GW はこれ Request DNS のアドレスは? DNS サーバの IP アドレスは これ 主信号の通信 37
不正 RA (Router Advertisement) 38 不正な RA により 正常な通信ができなくなる NW 管理者が NW を IPv4-only にしても PC 等は IPv6 が初期設定 ON のために LAN 内では IPv6 が動く! GW-Router 正しい RA 私ルーター 正常な通信 不正な RA で Prefix( IP Add) や Default GW を通知 誘導された通信 不正な Router
不正 RA の対策例 39 RA-Guard (RFC6105) を実装しているルーターであれば不正な RA をブロック! RA-Guard の実装手法が整理されている (RFC7113) GW-Router Switch (RA-Guard) 不正な RA 正しい RA 不正な Router
同様に不正 DHCPv6 の対策例 40 DHCPv6 においても同様の不正が考えられる DHCPv6-Shield (RFC7610) を実装しているルーターであれば不正な DHCPv6 をブロック! GW-Router 正しい DHCPv6 Switch (DHCPv6 -Shield) 不正な DHCPv6 不正な Router
SLAAC 以外の IPv6 アドレス自動設定 国内では 少なくとも 3 つの方式が使われている 1SLAAC 世界で大多数 2 局から RA NGN 光電話なし 3 局から DHCPv6 一部のケーブル事業者 ISP DHCPv6-PD ISP 6G RA で Prefix (*1) ISP 6G DHCPv6 IP n 個 家庭用ルータ Bridge Bridge 6G RA で Prefix (*1) 6G 6G 6G 6G 6G 6G (*1) IPv6 2 の 64 乗個 またの機会に 課題は? 41
DHCPv6 の課題 RFC8273 へ!! 2017.12 https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s03/s3-kitaguchi.pdf 42
43 ( プライバシーの問題 ) 典型的な IPv6 アドレス生成 (EUI-64 方式 ) 各端末は ISP から払い出された Prefix と自インタフェースの MAC アドレスを組み合わせて 自ら IP アドレスを自動生成する MAC アドレスを 2 つに割って真ん中に ff:fe を機械的に挿入 IP Address = 128 bit 2001:0db8:1234:5678:0211:11ff:fe22:2222 Prefix = 64 bit Interface ID = 64 bit IPv6 アドレスの下位 64bit が分かれば 端末 ( 端末保有者 ) を特定できる
( プライバシーの問題 ) EUI-64 の問題点 端末保有者はサーバ事業者に訪問先を特定されてしまう Server Internet Interface ID: 下位 64bit 固定 Interface ID: 下位 64bit 固定 Interface ID: 下位 64bit 固定 自宅勤務先内緒の場所 持ち歩き 持ち歩き 44
( プライバシーの問題 ) Privacy Extensions for SLAAC サーバ事業者に端末保有者の訪問先を特定されないために Privacy Extensions あるタイミングで下位 64bit が変わる 複数 RFC 化されている (RFC4941 7217 ) サーバ管理者は端末の特定が不可 自宅や会社等を特定するためのPrefix( 上位 64bit) は変わらないため 法執行機関には影響が及ばない 45
IPv6 アドレスの運用管理とプライバシの問題 https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s03/s3-kitaguchi.pdf 46
目次 47 IPv6 普及状況 IPv6 のセキュリティー 法人の IPv6
Google への IPv6 アクセス率 Google への全世界からの IPv6アクセス率は 22% 日本からのIPv6アクセス率は 24% 正月のIPv6 率は高め 2018 年の正月 ( 参考 ) 正月明け IPv6 率 down 法人が IPv6 未対応のため!? Source : Google https://www.google.com/intl/ja/ipv6/statistics.html https://www.google.com/intl/ja/ipv6/statistics.html#tab=per-country-ipv6-adoption 48
(RFC7381 の紹介 ) RFC7381 について 49 IW2017 においては 企業 NW について語られている RFC7381 に関する紹介がありました
(RFC7381 の紹介 ) IPv6 導入の最も大きなドライバー プロバイダー ( 固定通信 移動通信 ) の IPv4 枯渇 ネイティブ IPv6 及び非ネイティブ IPv4 の開始 非ネイティブ IPv4 通信は以下が考えられる NAT64 NAT444 DS-Lite (Dual-Stack Lite) MAP-T (Mapping of Address and Port using Translation) MAP-E (Mapping of Address and Port using Encapsulation) その他 IPv4 IPv4 Internet センター装置 IPv6 非ネイティブ IPv4 IPv4 Router 等 IPv6 Internet IPv6 ISP (IPv6) ネイティブ IPv6 50
(RFC7381 の紹介 ) IPv4 が好ましくない要因 補足 性能面 パフォーマンスが悪い 信頼性で劣る 運用面 管理が複雑 トラブルシューティングが複雑 Happy Eyeballs 2 による IPv4 へのペナルティー 国内の場合 フレッツは PPPoE の輻輳で 結果的に IPv4 が遅い アドレス共有していると通らないアプリが有る ( 法人の例 : 一部の TV 会議システムが使えない ) 途中で様々な技術が割り込まれることが多い トンネル アドレス共有 アドレス変換 51
(RFC7381 の紹介 ) IPv6 導入にかかわらず IPv4 での留意点 - 1/2 公開サーバーで IPv4 アクセスのログ取得が必要 (RFC6302 Logging Recommendations for Internet-Facing Servers より ) ログ取得の理由 犯罪捜査等のためにアドレス共有装置の裏にいる人を特定するため アドレス共有装置とは NAT444 MAP DS-Lite 等を指す 取得項目 ソースポート番号 タイムスタンプ プロトコル ログ取得の際に守るべきこと これらのログは確実に守られていること プライバシーが守られていること 定期的にログ保持に関する規則に基づき削除されること 52
(RFC7381 の紹介 ) IPv6 導入にかかわらず IPv4 での留意点 - 2/2 53 IPv6 による影響も考慮するべき IPv4-only ネットワークにおいて IPv6 が動いている場合は注意 最近の端末は初期設定で IPv6 対応している 例えば 不正 RA の問題 ( 前述 ) は IPv4-only ネットワークで問題を起こす (RFC6104 参照 ) IPv4 ネットワークにおける IPv6 セキュリティーについては RFC7123 を参照
(RFC7381 の紹介 ) IPv6 対応の際に段階的アプローチを行うと良い 1. 準備 アセスメントフェーズ 全ての管理者にとって必須 後々の失敗や複雑化を防ぐために必要 2. 外部接続フェーズ enabling IPv6 for Internet-facing systems, as recommended in [RFC5211] 参照 3. 内部接続フェーズ 管理者は 2 と 3 のどちらから取り組むかを決めなければならない 54
(RFC7381 の紹介 ) 外部接続の IPv6 対応 内部接続の IPv6 対応の優先順位 多くの場合 外部接続を先に実施 たとえ部分的でも外部向けには IPv6 対応しておきたい 理由 IPv6 の方が Tunnel や Translate を経由してくる IPv4 よりパフォーマンスが良い エンタープライズへ通信はシンプルで頑強な IPv6 通信が好ましい 55
総務省のガイドラインの紹介 総務省の HP で各種のガイドラインが公開されている http://www.soumu.go.jp/menu_seisaku/ictseisaku/ipv6/index.html 56
( 総務省のドキュメント紹介 ) ガイドライン と 仕様書調達モデル の位置付け 両ドキュメントは IPv6 対応計画立案及び製品等の調達の際に有用 http://www.soumu.go.jp/main_content/000301466.pdf 57
( 総務省のドキュメント紹介 ) ガイドライン と 仕様書調達モデル の内容 セットで利用することを想定している ガイドライン IPv6 対応の方法や検討上の留意点等を説明している 基本計画を作成することができるようになっている 仕様書調達モデル 調達仕様書のモデルを提示している それぞれの企業に応じた調達仕様書を作成できると考えている 58
( 総務省のドキュメント紹介 ) IPv6 対応ガイドライン 企業編 より抜粋 自らが必要な情報を抜粋して得ることが可能 http://www.soumu.go.jp/main_content/000301464.pdf 59
( 総務省のドキュメント紹介 ) ガイドライン 具体的内容 ( 抜粋 ) IPv6 アドレスの調達方法 A) ISP から 上位 ISP のグローバルアドレスの一部 一般的な組織であればこれで十分 B) JPNIC 等から 組織専用のグローバルアドレス 上位 ISP に依存せずに自ら NW を運用する場合や特殊な NW を運用する場合など その他幅広く記載されている 組織内でのアドレスの使い方 アドレスの管理方法 DMZ におけるアドレスの使い方の留意点などなど http://www.soumu.go.jp/main_content/000301464.pdf 60
( 総務省のドキュメント紹介 ) IPv6 対応調達仕様書モデル 企業編 より抜粋 機器毎の調達仕様のモデルが記載されている ( ができること などのリスト ) http://www.soumu.go.jp/main_content/000301466.pdf 61
( 総務省のドキュメント紹介 ) 調達仕様モデル 具体的内容 ( 抜粋 ) ロードバランサーの例 : ロードバランサーとして備えるべき基本機能を有すること IPv4/IPv6 通信が可能であること 外部からの IPv4/IPv6 によるアクセスをウェブサーバに振り分ける際に ウェブサーバに対する通信を IPv4 及び IPv6 のいずれかを選択できること IPv4 通信と IPv6 通信が同等のスループットを処理できる能力を有すること IPv4 通信と IPv6 通信が同等の TLS/SSL のアクセラレータの性能を有すること 冗長構成を取ることで IPv4/IPv6 通信の冗長化を可能とする機能を有すること IPv4/IPv6 通信による運用管理端末からのリモート保守を可能とする機能を有すること IPv4/IPv6 通信による時刻設定を常時正しい状態に保つことを可能とする機能を有すること IPv4/IPv6 通信の情報をログ出力できること ログ出力の通信に IPv4/IPv6 通信が利用できること OP IPv4/IPv6 通信による構成定義情報のバックアップを可能とする機能を有すること 運用管理を行うネットワークで IPv6 対応を行う場合 http://www.soumu.go.jp/main_content/000301466.pdf 62
最後に 63
現在の IPv6 と IPv4 64 世界において IPv6 対応と IPv4 の劣化は同時に起きています IPv6 導入 US を中心とする大手クラウド事業者の IPv6 対応急加速 US を中心とする大手 PC モバイル OS の IPv6 対応急加速 上記事業者の世界進出 各国 NW 事業者の IPv6 対応 IPv4 劣化 標準化団体による IPv4 劣化 IPv4 アドレス共有による技術的課題 無数に存在する IPv4 の共有方式に対応するためのクラウド 端末 アプリのコスト増 国内においては フレッツ IPv4 PPPoE の輻輳
企業ネットワークの 2 つの IPv6 アプローチ ( 話者の見解 ) 多くの場合 2 つのアプローチの混在になるであろう 中小の企業はアプローチ 2 のみでの IPv6 自然対応へ 従来 アプローチ 1 アプローチ 2 Internet Internet Internet 公開 Web のクラウド化 (IPv6 対応 ) 社内システムのクラウド化 (IPv6 対応 ) 企業 公開 Web 社内システム IPv6 対応 公開 Web IPv6 対応 社内システム IPv4-only 強い意思を持って IPv6 対応 IPv6 対応しているクラウドへの移行に伴い 結果的に IPv6 対応 65
まずは 公開 Web だけでも まずは お客様視点で公開 Webから IPv6 対応を 但し 目的をIPv6とすると 社内でのIPv6 化は撃沈となります クラウド化のタイミングがチャ ンス!! 貴社 IPv4-only 公開 Web 貴社の競合 IPv6 対応 公開 Web Happy Eyeballs 2 PPPoE の輻輳 etc. 一定数の Web 閲覧者は IPv4 でイライラ IPv6 で従来の品質を維持 IPv6 対応 Web 閲覧者 ( お客様等 ) 66
本質的には今後の企業 NW には IPv6 が適している 社内システムのクラウド化に伴い 従業員のクリックや入力に伴う全ての通信がクラウドを往復する 社内システム ( クラウド ) 社内システム ( クラウド ) Happy Eyeballs 2 PPPoE の輻輳 etc. IPv4-only IPv4 でイライラ 企業や外出先テレワーク先 IPv6 (+IPv4) IPv6 で従来の業務効率を維持 67
68