_IPv6summit_nishizuka.pptx

Transcription

1 IPv6 Summit in Tokyo 2018 IPv6 標準化最新状況 塚要 NTT kaname

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

3 IPv6 標準化最新状況 n IPv6 仕様の再整理 RFC8200 (2017/7) n 仕様整理の残課題 マルチホーム問題 有線から無線へ メディア / 端末の変化への対応 ü IoT デバイスへの対応も含まれる IPv4 からの移 ( 技術 / 運 ) 拡張ヘッダ挿 問題 Path MTU Discovery 再考 n 新技術への期待 SRv6(IPv6 Segment Routing) 3

4 1. IPv6 仕様の再整理 4 4

5 IPv6 仕様の再整理 n IPv6 の基本仕様を規定した RFC 2460 (1998 年 ) を廃 RFC8200 5

6 IPv6 仕様再整理の要点 n 仕様を きく変更するものではなく 曖昧な 章の排除や 参照の整理など 読みやすさを改善したもの 基本プロトコル ü RFC2460 RFC8200 (STD86) IPv6 Path MTU 探索 ü RFC1981 RFC8201 (STD87) IPv6 をサポートするための DNS 拡張 ü RFC3596(STD88) ICMPv6 ü RFC4443(STD89) n IETF では整理のために 2 年かけて議論 JANOG39.5 IPv6 RFC 改版の提案はなぜ論紛糾したのか? 佐原具幸 (IIJ) RFC4941 SLAAC のプライバシー拡張 RFC4291 IPv6 アドレス体系 整理の対象外に n 紛糾した議論点が 残課題として現在も引き続き議論されている 6

7 2. 仕様整理の残課題 7 7

8 仕様整理の残課題 n 仕様整理の残課題 マルチホーム問題 有線から無線へ メディア / 端末の変化への対応 ü IoT デバイスへの対応も含まれる IPv4 からの移 ( 技術 / 運 ) 拡張ヘッダ挿 問題 Path MTU Discovery 再考 8

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

10 IPv6 Router Advertisement IPv6-Only Flag n 的 ネットワークに接続したホストが IPv4 を使おうとするのを抑えること n ドラフトの状況 WG アイテムとして採 ü IPv6 Router Advertisement IPv4 Unavailable Flag から名前の変更 賛否両論 ü しかし チェアのドラフトのため WG アイテムに n 主な反論 この RA を受け取ったホストが IPv4 の利 をやめる 悪意のある第三者に不意に IPv4 を使えなくされてしまう 10

11 拡張ヘッダ挿 問題 n RFC8200 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 中間ノードでは拡張ヘッダの挿 はされない n 今後の制約になるのではないか? ヘッダ挿 については新しいドラフトで議論をする ü draft-voyer-6man-extension-header-insertion ü SRv6 提案者が中 ü SRv6 において 中間ノードでヘッダ挿 をする実装がすでにでているため ( 後述 ) 11

12 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 メッセージが 送信元のサーバに返らない問題 12

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

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

15 ( 参考 ) 切り捨てる提案 15

16 3. 新技術への期待 16 16

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

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

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

20 IPv6 Segment Routing Header (SRH) n draft-ietf-6man-segment-routing-header SRH の仕様を策定する WG ドラフト 20

21 IPv6 Segment Routing Header (SRH) n 実装が先 している 21

22 IPv6 Segment Routing Header (SRH) n SR のアーキテクチャに関する RFC8402(7 に RFC 化 ) を参照 この IPv6 Segment Routing Header (SRH) の RFC 化を先に進めて SRv6 Network Programming はそれを参照する RFC8402 Segment Routing Architecture

23 IPv6 Segment Routing Header (SRH) n ドキュメントのステータス ヘッダのフォーマットはほぼ決定 HMAC と TLV 関連の課題整理が残りタスク n 実装も進み商 での利 も えてきたので 早く標準化プロセスを進めたい という意 が占める SRv6 の RFC 化間近? 23

24 まとめ n IPv6 仕様の再整理 紛糾した議論点は据え置きにして publish 現在は積み残しを重点的に議論 ü Path MTU Discovery 再考がありそう n まだ決着の えない RA v.s. DHCPv6 論争 今回の資料では触れません n SRv6 への期待 実装先 注 点 : 拡張ヘッダ挿 の実装が IPv6 仕様とどう折り合いつけるか 24