IPv6 Summit in Tokyo 2018
IPv6標準化最新状況
2018.11.26
⻄塚 要 NTT Communications@__kaname__⾃⼰紹介
n 2006年 NTTコミュニケーションズ⼊社
n OCNアクセス系ネットワークの設計に従事した後、⼤規模ISP向けのトータル保守運⽤サービスを担当
現在は研究開発組織にて主にデータ分析を担当
n メインフィールド• トラフィック分析• DDoS対策ソリューション
• IPv4枯渇対策関連技術
n IETF提案活動• DOTS WG
n JPNIC「IPv6教育専⾨家チーム」
2

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

1. IPv6仕様の再整理

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

5

IPv6 仕様再整理の要点
n 仕様を⼤きく変更するものではなく、曖昧な⽂章の排除や、参照の整理など、読みやすさを改善したもの• 基本プロトコル
ü RFC2460→RFC8200 (STD86)• IPv6⽤ Path MTU探索ü RFC1981→RFC8201 (STD87)• IPv6をサポートするためのDNS拡張

RFC4941 SLAACのプラ
イバシー拡張RFC4291 IPv6アドレス
体系→整理の対象外に

ü RFC3596(STD88)• ICMPv6

ü RFC4443(STD89)

n IETFでは整理のために2年かけて議論• JANOG39.5 IPv6 RFC改版の提案はなぜ論紛糾したのか?
• 佐原具幸⽒(IIJ)n 紛糾した議論点が、残課題として現在も引き続き議論されている
6

2. 仕様整理の残課題

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

8

IPv4からの移⾏に関する提案
n draft-ietf-6man-ipv6only-flag• IPv6 onlyのネットワークであることを⽰すフラグをRAに追加

補⾜:提案中のBitの名前は、ʼ6ʼではなくʼSʼに9

IPv6 Router Advertisement IPv6-Only Flagn ⽬的
• ネットワークに接続したホストがIPv4を使おうとするのを抑えることn ドラフトの状況• WGアイテムとして採⽤

ü IPv6 Router Advertisement IPv4 Unavailable Flagから名前の変更• 賛否両論ü しかし、チェアのドラフトのためWGアイテムに

n 主な反論• このRAを受け取ったホストがIPv4の利⽤をやめる→悪意のある第三者に不意にIPv4を使えなくされてしまう
10

拡張ヘッダ挿⼊問題
n RFC8200• “Extension headers (except for the Hop-by-Hop Optionsheader) 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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Path MTU Discovery 再考
n サイドミーティング@IETF103(2018/11)• Path MTU Discoveryの問題を集中討議
n 現⾏のPath MTU Discoveryの問題点• 送信元へのフィードバックがロバストではないüüüü

ICMPv6エラーの送出がルータで絞られているケース
ICMPv6がフィルタされているケース
ホストが無視するケース
ロードバランサ/エニーキャストがあるケース• パケットが何往復もしないといけない• MTUの判別が、flow単位ではなく宛先単位

13Path MTU Discovery 再考
n 解決策
1. トランスポートレイヤに任せる
2.
3.
4.
5.
6.

ü RFC4821: Packetization Layer Path MTU Discovery

現状維持
途中のルータでのフラグメント
MTU=1280に固定
途中のルータで、切り捨てる(Truncation)
途中のMTUを記録する新しいパケット(Hop-by-hopoption)を定義
7. ….
n 今後、Path MTU Discoveryの仕様に関して、⼤幅な⾒直しが⼊る⾒込み14

(参考) 切り捨てる提案

15

3. 新技術への期待

16

16

IPv6 Segment Routing

IPv6 Summit in TOKYO 2017
「最近のIPv6標準化に思うこと」神明 達哉 ⽒
http://www.jp.ipv6forum.com/2017/timetable/program/2017112702.pdf
17

IPv6 Segment Routing

⼤規模サービスを⽀えるネットワークインフラの全貌
LINE Developer meetup #45 in Kyoto
https://www.slideshare.net/linecorp/ss-116867631
18

IPv6 Segment Routing

IETFでは、dmm WGにて3GPP CT4からのリエゾンリクエストに応えて、プロトコル＆アーキテクチャ分析などを実施"SRv6の現状と展望" ENOG53＠上越https://www.slideshare.net/kentaroebisawa/srv6-enog53
19

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

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

21

IPv6 Segment Routing Header (SRH)n SRのアーキテクチャに関するRFC8402(7⽉にRFC化)を参照• このIPv6 Segment Routing Header (SRH)のRFC化を先に進めて、SRv6 Network Programmingはそれを参照する
RFC8402 Segment Routing ArchitectureIPv6 Segment Routing Header (SRH)n ドキュメントのステータス• ヘッダのフォーマットはほぼ決定• HMACとTLV関連の課題整理が残りタスク
n 「実装も進み商⽤での利⽤も⾒えてきたので、早く標準化プロセスを進めたい」という意⾒が占める

SRv6のRFC化間近？

23

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

24