_ietf103_update_ipv6_nishizuka.pptx

Transcription

1 IETF103 報告会 IPv6 関連 WG v6man, v6ops Kaname kaname

2 紹介 n 2006 年 NTT コミュニケーションズ 社 n OCN アクセス系ネットワークの設計に従事した後 規模 ISP 向けのトータル保守運 サービスを担当 n メインフィールド トラフィック分析 DDoS 対策ソリューション IPv4 枯渇対策関連技術 n IETF 提案活動 DOTS WG n JPNIC IPv6 教育専 家チーム 2

3 における IPv6 関連ホットトピック アジェンダ 1. 6man WG 2. v6ops WG 3. SRv6 とヘッダ挿 と PathMTU と side meeting: 6MAN/TSVWG Path MTU Discovery Discussion 3 3

4 IPv6 関連各 WG と主な領域 n IETF IPv6 関連 WG について v6ops WG 6man WG 6lo(6lowpan) WG 6tisch WG lpwan WG ipwave WG IPv6 全般の運 上の課題と プロトコルの改良 IPv4 アドレスの枯渇と 移 技術は 主に 6man と v6ops で議論される最近の傾向 IoT における IPv6 homenet WG マルチホームする家庭内における IPv6 4

5 1. 6man 5 5

6 6man WG n IPv6 Maintenance WG n 設 :2007 年 n チェア :Bob Hinden, Ole Troan n 6man WG は IPv6 の仕様とアーキテクチャのメンテナンスと最新化を う ただし IPv6 の仕様に きな変化を与えるものではない IPv6 の展開や運 で発 された制限や問題を解決する n IETF における IPv6 関連トピックの受け となり IPv6 の仕様の拡張や変更に関して 責任を持つ 6

7 6man Agenda n ハイライト (WG ドラフト ) 1.SRv6 のヘッダ定義 2.IPv6-only flag in RA 3. Path MTU 問題 7

8 チェアスライドより n 新しい6manのマイルストーン More documents to Internet Standard Internet layer PMTU discovery improvements Segment routing IPv6 only flag Universal deployment of IPv6 n ウォッチすべき関連 WG MAPRG ü IPv6 関連の計測の報告がある TSVWG ü MTU 問題との関連 SPRING ü Segment Routing(SRv6) 関連 8

9 1. SRv6 標準化最新状況 n draft-ietf-6man-segment-routing-header SRH の仕様を策定する WG ドラフト issue を順調に 付け中 ( 残り 8 issue) ü HMAC や security consideration については記載が進んだ ü RFC5095 で指摘された Type 0 Routing Header (RH0) を いた増幅攻撃を抑えるために メッセージ認証が必要 (HMAC を いる ) ü TLV について まだいくつか issue が残っているので それに集中して今後解決していく 発表者は 12 末までに解決したいと発 n カプセルモード (encapsulation) と ヘッダ挿 モード (insertion) があり 本ドラフトはカプセルモードについて記述 しかし 世の中にはヘッダ挿 モードの実装もある なぜ全てカプセルモードに統 しないのか という質問も 9

10 2. IPv6 only flag in RA n draft-ietf-6man-ipv6only-flag IPv6 only のネットワークであることを すフラグを RA に追加 補 : 提案中の Bit の名前は ʼ6ʼ ではなく ʼSʼ に 10

11 2. IPv6 only flag in RA n ドラフトの状況 n 実装 チェアが推しているために WGLC に (9 ) ü しかし その後も ML 上で議論噴出 ü 主な反論 : セキュリティ での副作 この RA を受け取ったホストが IPv4 の利 をやめる 悪意のある第三者に不意に IPv4 を使えなくされてしまう FreeBSD の実装でのテストでは問題なかった n IETF103 での議論 チェアでもあり提案者の Bob Hinden が 反対意 に対して 逐 問題ない 理由を説明 しかし 会場でも議論噴出 ü 新しいバージョンの IP が出たらどうするのか? その時はその時 ML 上はコンセンサスがない OS 実装者がどうするか Google(Android) は 反対しない MUSTではなくSHOULDであればコンセンサスか 11!?

12 3. Path MTU 問題 n Path MTU 問題の解決 法の模索 いまのPath MTU Discoveryの仕組みには問題がある Path MTU Solution Space draft-troan-6man-pmtu-solution-space n 解決策の提案の 部 Path MTU Hop-by-Hop Option, draft-hinden-6man-mtuoption Destination Originates Internet Control Message Protocol (ICMP) Packet Too Big (PTB) Messages, draftleddy-6man-truncate n 曜 のサイドミーティングで集中議論 ( 後述 ) 12

13 2. v6ops 13 13

14 v6ops WG n IPv6 Operations WG n 設 :2002 年 n チェア :Fred Baker, Ron Bonica, Lee Howard n v6ops WG は IPv6 を全世界に展開するにあたっての緊急の課題 特に運 上の課題に対処することに焦点を当てた WG n 新しいネットワーク / 既存の IPv4 ネットワークに IPv6 を導 するためのガイドラインや IPv4/IPv6 共存ネットワークの運 ガイドラインを作成することも 的としている 14

15 v6ops Agenda n ハイライト ゲストスピーカ 中国の学術ネットにおける IPv6 only バックボーンと IPv4aaS その他は した議論なし 15

16 中国の学術ネットにおける IPv6 バックボーンと IPv4aaS n ゲストプレゼンテーション CERNET2 IPv6-only Practice: Backbone, Servers, Clients and 4aaS CERNET2 Congxiao Bao 中国の学術ネットである CERNET2 における経験 16

17 中国の学術ネットにおける IPv6 バックボーンと IPv4aaS n IETF プロトコルの利 17

18 中国の学術ネットにおける IPv6 バックボーンと IPv4aaS n IVI を NAT64 ライクに利 18

19 中国の学術ネットにおける IPv6 バックボーンと IPv4aaS n 質疑 IPv6 only flag は有 だと思うか? ü かもしれない NAT64 prefix の discovery はどうしているのか?Android のはうまく動いているのか?PREF64 が /96 にしか対応しないのはいいのか? ü /96 以外も使えると嬉しい MAP-T を導 する場合には さらに別の 法が必要になるだろう n RA が複雑になるので 6man では PREF64 を /96 に限定する提案がでているので それにそぐわないユースケースが説明されたということ もしかしたら 6man の議論に影響があるかもしれない 19

20 その他ドラフトについて n NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks 分量が多くレビューが少ない ( ガイドライン系のドラフトにありがち ) 継続議論 n IPv6-Ready DNS/DNSSSEC Infrastructure TLD の v6 DNSSEC 対応 誰がドライブすべきか BCP とすべきか -> No Hum n IPv6 Address Assignment to End-Sites エンドユーザには /48 がいいのでは話 そもそもアドレスの使い を強制しない というのが IPv6 のいいことなので 反対多数 IETF は recommend するだけ RIR が決めること n Pros and Cons of IPv6 Transition Technologies for IPv4aaS ただ 4over6 技術を列挙して分析しただけ 20

21 3. SRv6 とヘッダ挿 と PathMTU side meeting: 6MAN/TSVWG Path MTU Discovery Discussion 21

22 IPv6 Segment Routing IPv6 Summit in TOKYO 2017 最近のIPv6 標準化に思うこと 神明達哉 22

23 IPv6 Segment Routing 規模サービスを えるネットワークインフラの全貌 LINE Developer meetup #45 in Kyoto 23

24 IPv6 Segment Routing IETFでは dmm WGにて3GPP CT4からのリエゾンリクエストに応えて プロトコル アーキテクチャ分析などを実施 "SRv6の現状と展望" ENOG53 上越 24

25 SRv6 とヘッダ挿 と PathMTU n SRv6 で先 している実装はヘッダ挿 を利 ( 例 : Juniper) n 中間ノードにおけるヘッダ挿 は RFC8200 で禁 IPv6 仕様の再整理の結果 RFC8200 が IPv6 基本プロトコルとして 2017 年に STD86 として発 Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path 再整理の議論で中間ノードにおけるヘッダ挿 は集中的に議論されたが ヘッダ挿 については別のドラフトで議論をすることに ü draft-voyer-6man-extension-header-insertion ü SRv6 提案者が中 n ヘッダ挿 をすると PathMTU Discovery に問題が PathMTU Discovery の問題を解決しないと 25

26 Path MTU Discovery 再考 n Path MTU Discovery の問題を集中討議 n 現 の Path MTU Discovery の問題点 送信元へのフィードバックがロバストではない ü ICMPv6 エラーの送出がルータで絞られているケース ü ICMPv6 がフィルタされているケース ü ホストが無視するケース ü ロードバランサ / エニーキャストがあるケース パケットが何往復もしないといけない MTU の判別が flow 単位ではなく宛先単位 26

27 Path MTU Discovery 再考 n RFC 7690: Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB) by Joel Jaeggli (Fastly) ロードバランサやエニーキャスト環境で Packet Too Big メッセージが 送信元のサーバに返らない問題 27

28 Path MTU Discovery 再考 n 解決策 1. トランスポートレイヤに任せる ü RFC4821: Packetization Layer Path MTU Discovery 2. 現状維持 3. 途中のルータでのフラグメント 4. MTU=1280 に固定 5. 途中のルータで 切り捨てる (Truncation) 6. 途中の MTU を記録する新しいパケット (Hop-by-hop option) を定義 (Recording) 7.. n 今後 Path MTU Discovery の仕様に関して 幅な 直しが る 込み 28

29 ( 参考 ) Truncation 提案 29

30 ( 参考 ) Recording 提案 30

31 まとめ n 6man WG 新しいマイルストーン IPv6-Only Flag の提案 SRv6 への期待の まり さて ヘッダ挿 問題どうする? n v6ops WG ゲストスピーカー枠の定着 APAC 地域の回はあまり有益な議論なし n Path MTU Discovery 再考 仕組みに 幅な変更が加わる可能性あり ü コンテンツ ルータ クライアント OS のビッグプレイヤーの動向はいかに? 31