IETF103報告会
IPv6関連WG
v6man, v6ops

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

2

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

3

IPv6関連 各WGと主な領域
n IETF IPv6関連 WGについて• v6ops WG
IPv6全般の運⽤上の課題と、プロトコルの改良• 6man WG••••

IPv4アドレスの枯渇と移⾏技術は、主に6manとv6opsで議論される最近の傾向

6lo(6lowpan) WG
6tisch WG
lpwan WG
ipwave WG

IoTにおけるIPv6• homenet WG

マルチホームする家庭内におけるIPv64

1. 6man

55

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

66man Agendan ハイライト(WGドラフト)
1.SRv6のヘッダ定義

2.IPv6-only flag in RA

3. Path MTU問題

7

チェアスライドより
n 新しい6manのマイルストーン• More documents to Internet Standard• Internet layer PMTU discovery improvements• Segment routing• IPv6 only flag
• Universal deployment of IPv6n ウォッチすべき関連WG• MAPRG

ü IPv6関連の計測の報告がある• TSVWGü MTU問題との関連• SPRING

ü Segment Routing(SRv6)関連
8

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

2. IPv6 only flag in RA
n draft-ietf-6man-ipv6only-flag• IPv6 onlyのネットワークであることを⽰すフラグをRAに追加

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

2. IPv6 only flag in RAn ドラフトの状況• チェアが推しているためにWGLCに(9⽉)ü しかし、その後もML上で議論噴出
ü 主な反論: セキュリティ⾯での副作⽤ 「このRAを受け取ったホストがIPv4の利⽤をやめる→悪意のある第三者に不意にIPv4を使えなくされてしまう」

n 実装• FreeBSDの実装でのテストでは問題なかった
n IETF103での議論• チェアでもあり提案者のBob Hinden⽒が、反対意⾒に対して、逐⼀「問題ない」理由を説明• しかし、会場でも議論噴出
ü 新しいバージョンのIPが出たらどうするのか？→”その時はその時”• ML上はコンセンサスがない→OS実装者がどうするか• Google(Android)は、反対しない
11• MUSTではなくSHOULDであればコンセンサスか！？

3. Path MTU 問題
n Path MTU問題の解決⽅法の模索• いまのPath MTU Discoveryの仕組みには問題がある• Path MTU Solution Space• draft-troan-6man-pmtu-solution-spacen 解決策の提案の⼀部• 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2. v6ops

13

13

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

v6ops Agendan ハイライトゲストスピーカ
中国の学術ネットにおけるIPv6
only バックボーンとIPv4aaS

その他は⼤した議論なし

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

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

18中国の学術ネットにおけるIPv6バックボーンとIPv4aaS
n 質疑• IPv6 only flagは有⽤だと思うか？
ü かもしれない• NAT64 prefixのdiscoveryはどうしているのか？Androidのはうまく動いているのか？PREF64が/96にしか対応しないのはいいのか？

ü /96以外も使えると嬉しい。 MAP-T を導⼊する場合には、さらに別の⽅法が必要になるだろう

n RAが複雑になるので、6manではPREF64を/96に限定する提案がでているので、それにそぐわないユースケースが説明されたということ• もしかしたら6manの議論に影響があるかもしれない19

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

3. SRv6とヘッダ挿⼊とPathMTU

side meeting: 6MAN/TSVWG Path MTU
Discovery Discussion

21

IPv6 Segment Routing

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

IPv6 Segment Routing

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

IPv6 Segment Routing

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

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 deletedby any node along a packet's delivery path”• 再整理の議論で中間ノードにおけるヘッダ挿⼊は集中的に議論されたが、ヘッダ挿⼊については別のドラフトで議論をすることにü draft-voyer-6man-extension-header-insertion
ü SRv6提案者が中⼼n ヘッダ挿⼊をすると、PathMTU Discoveryに問題が…
• PathMTU Discoveryの問題を解決しないと25

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

26

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

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

ü RFC4821: Packetization Layer Path MTU Discovery

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

(参考) Truncation提案

29

(参考) Recording提案

30

まとめ
n 6man WG• 新しいマイルストーン• IPv6-Only Flagの提案• SRv6への期待の⾼まり• さて、ヘッダ挿⼊問題どうする？
n v6ops WG• ゲストスピーカー枠の定着• APAC地域の回はあまり有益な議論なし
n Path MTU Discovery 再考• 仕組みに⼤幅な変更が加わる可能性あり

ü コンテンツ、ルータ、クライアントOSのビッグプレイヤーの動向
はいかに？

31