IETF106報告会
IPv6関連WG
2020.1.9
⻄塚 要 NTT Communications@__kaname__IPv6標準化最新動向@IETF106
n IETF106• SRv6 (IPv6 Segment Routing)• 拡張ヘッダ挿⼊問題

IPv6の仕様(RFC8200)と、現在実装されているSRv6の⼀⽅式(ヘッダ挿⼊)の不⼀致を解消するための第⼀歩

2

IETF106n IETF106• シンガポール• 11/16 – 11/22

n IETFとは• インターネット技術の標準化を推進する任意団体• 会合: 年3回
• IETF⼊⾨(ISOC-JP)IETFのソーシャルイベントで泳いでいたKAME→
3

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

4

6man WG IETF106 アジェンダ(2枠⽬)

5拡張ヘッダ挿⼊問題

66

7

(HBHオプションを除く)拡張ヘッダは、パケットの通るパス上のいかなるノードでも処理・挿⼊・除去されない。IPv6ヘッダの宛先アドレスに指定されたノードに到達するまでは。(意訳)89ヘッダの除去が、単⼀故障点(Single Point of Failure)となる(と主張)
10

NOTE: これらを理由としてプロトコルを議論するのはフェアだろうか？

11

SRv6
ヘッダ挿⼊について12

12

IPv6 Segment Routing

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

IPv6 Segment Routing

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

Segment Routing Header 標準化状況
n IPv6 Segment Routing Header (SRH)• RFC-Editor Queueへ (RFC化間近)• 会場では拍⼿n ヘッダ挿⼊については別のドラフトで議論をする• draft-voyer-6man-extension-header-insertion• SRv6提案者が中⼼15現在のデプロイメント⽅式では、SRドメインにパケットが⼊った時には、元のパケットをカプセル化してSRパケット化している

ヘッダ挿⼊は、SRドメインの中のノードでだけ起こる。
挿⼊箇所はカプセルの外側のIPv6ヘッダ。
カプセルの外の宛先は必ずSRドメインの中のノードである。

IPv6(RFC8200) v.s. SRH挿⼊という話なのか？
n 前者のドラフトが指摘する点は、現状のSRH挿⼊の実装/使われ⽅には当てはまらない
n ただし、SRドメインの中に限定しているからとはいえ、RFC8200との整合性は考えないといけない• またMTUの問題は現存する

ü SRドメイン内にSR unawareなトランジットがあるケース？

n 対⽴ではなく、今後起こりうるかもしれないことを含めて、issueを起こして、議論していく

22

その他の提案について

23

23

6man
ステータス タイトル

筆者

Working Next Steps in RFC8200 Fragmentation
Group Drafts Errata

Bob Hinden /Ole Trøan

概要

Next Step

RFC8200のフラグメント 新しいErrataを起こしに関するErrata(修正)が て、既存を廃止する
間違っていたPath MTU Hop-by-Hop Option Update Gorry
Path MTU探索にHop- 実験を継続
Fairhurst / Bob by-Hopオプションを利用
Hindenする実験
Operations, Administration andZafar Ali
SRv6ドメインでpingがで spring WGのnetwork
Maintenance (OAM) in Segment Routing
きるように。
programabilityのドラ
Networks with IPv6 Data plane (SRv6)
フトの後に続いて進める
ActiveGratuitous Neighbor Discovery: Creating Jen Linkova(v6opsでも発表)(v6opsでも発表)
Individual Neighbor Cache Entries on First-Hop
DraftsRouters
IPv6 Extension Header for the Alternate Giuseppe
拡張ヘッダを利用して計 継続議論
Marking Method
Fioccala
測をする
IPv6 Formal Anycast Addresses andMark Smith
IPv6 anycastのアドレス 継続議論
Functional Anycast Addresses
帯を決める
New
Asymmetric IPv6 for IoT Networks
Guangpeng Li 特定のドメインでIPv6の (筋悪の反応)
Individual
アドレス長を短くする
Drafts (as Support Postcard-Based Telemetry for Haoyu Song
新しいSRv6の測定方法 (筋悪の反応)
time allows) SRv6 OAM

24

v6opsステータス タイトル
WorkingGroupDrafts

筆者

Gratuitous Neighbor Discovery:Jen Linkova
Creating Neighbor Cache Entries onFirst-Hop Routers

概要

Next Step

アドレス取得したあと、 解決すべき課題であサーバからの最初の返 るとHum事のときにルータ側にNeighbor Cacheがない件
Active Default IPv6 Local Only Addressing Mark Smith
ULA/LLAだけしかリッス 反対多数
Individual for Non-Internet Devices
ンしないデバイスはセDrafts
キュアではないか？
464XLAT Optimization
Jordi Palet
464XLAT環境下での議論少数CDN配信の最適化手法
IPv6 Point-to-Point Links
Jordi PaletP2Pリンクでのプレフィッ 特にコメントなし
クス長についてReaction of Stateless Address
Fernando Gont CPEリブート時などリナ サポート意見多数
Autoconfiguration (SLAAC) to Flashンバが発生した時のRenumbering Events
SLAACの問題を記述
Improving the Reaction of Customer Fernando Gont 上記に対して、古いRA 継続議論
Edge Routers to Renumberingをどうするか、などの推Events
奨対応を記載25

まとめn SRv6のRFC化間近• 実装先⾏n それ以外の提案については、あまり議論が活発ではなかった• IETF106は、筋の悪い提案が多かったため

26