MPLS Japan 2022

SRv6 and IPv6 evolution

Miya Kohno, Cisco Systems (mkohno@cisco.com)
1• SRv6 は IP技術に基づくとともに、IP技術そのものに進化をもたらしている• そこで本セッションでは、SRv6とその進化可能性を下記の観点から検討し、-アドレスの意味論（Address Semantics）
セキュリティ（Security）
ドメイン スペシフィック プログラミング（Domain Specific Declarative Programming）
スケーリングとコンヴァージェンス（Scaling and Convergence）• アーキテクチャ進化について展望する

2

SRv6 and iPv6 evolution• Introduction

Agenda• Address Semantics• Security• Domain Specific DeclarativeProgramming• Scaling and Convergence3•1998 RFC2460*1 発行、IPv6 Forum発足•

2000 e-Japan構想•

2002 IPv6 address policy発行•2008 IPv4枯渇タスクフォース発足•

2009 総務省IPv6研究会発足•

2011 IANA在庫枯渇 (2月)
APNIC在庫枯渇 (4月)

Date (2000-2022)

IPv6経路数
https://bgp.potaroo.net/v6/as2.0/index.html•

2011 IPv6 IPoE開始•

2012 World IPv6 Launch•2018 IPoE PoI 拡大•

2020 RFC8754*2 発行、Covid-19•

2021 RFC8986*3 発行*1 RFC2460 (IPv6)*2 RFC8754 (SRv6 SRH)
*3 RFC8986 (SRv6 Network Programming)4

••

企業よりも家庭の方が、IPv6利用が進んでいる
Covid-19でHybrid Workが普及したために、IPv6利用が進んだと考えられる

https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption

5保守的立場

進歩的立場

6man

6LoWPAN, SRv6

• 安定性が重要• ひたすら普及を奨励する• 革新する• まずは特定の分野への適用* RAW: Reliable and Available Wireless
RPL: Routing over Lower Power and Lossy Network•••••••

6LoWPAN Routing Header (6LoRH) for easy forwarding
6LoWPAN ND for reliable address presence
DetNet IPv6 Extension Headers for delivery guarantees
RAW / RPL IPv6 Extension Headers for dynamic steering
RPL + SR attempts to use flow label, limited domains
SRv6 Segment Routing Header, steering and more
SRv6 semantic address for network programming
6SRv6 and iPv6 evolution• IntroductionAgenda• Address Semantics• Security• Domain Specific Declarative
Programming• Scaling and Convergence

7

[RFC8754]• Segment ID (128-bit IPv6 address)• Locator• Function• Argument• SR node の処理• “Segment Left”を 1 減らす• SRHの Segment List [#Segments Left] を
IPv6ヘッダの宛先アドレス (DA) にコピーする8[draft-ietf-spring-srv6-srh-compression][draft-filsfils-spring-net-pgm-extension-srv6-usid] • SID Structure (NEXT-C-SID Flavor)• Locator-Block (B)• Combined locator and function (NF)
• Argument (A) ← ここに一連のNFが入る• SR node の処理• DA.Argumentの値を DA のビット[B...(B+A-1)]にコピーする。
• 残りの DA のビット[(B+A)...127]を0に設定する。
• “Hop Limit” を 1 減らす

9

SRv6 Base Encapsulation

SRv6 uSID Encapsulation

SA:2001::1
DA:2001:db8:0:4:1:0:0:0
NH:RH

SA:2001::1
DA:2001:db8:100:200:300:400:500::
NH:IPv4

Type:4(SRH)
NH:IPv4|SL:1
Segment List:[0]: 2001:db8:0:5:45:0:0:0[1]: 2001:db8:0:4:1:0:0:0[2]: 2001:db8:0:3:48:0:0:0[3]: 2001:db8:0:2:1:0:0:0[4]: 2001:db8:0:1:42:0:0:0

Shift &Forward !!

UDP Header/Data

SRv6 uSID Carrier

SA:7.5.4.3
DA:11.6.19.71
Port:UDP
UDP Header/Data

Longestmatch

SA:7.5.4.3
DA:11.6.19.71
Port:UDP

2001 :0db8 : 0100 : 0200 : 0300 : 0400 : 0500 : 0000
SRv6 uSID
BlockuSID
1uSID
2uSID
3uSID
4uSID
5EoC
610•

SRv6 SID は IPv6 アドレスアーキテクチャ (RFC4291) に違反しているのではないか ?

•••SID は RFC4291 IPv6 アドレスとは異なる
エンドホストのインターフェースに割り当てられるものではない
SIDはIPv6 DAに現れるが、中継ノードは単にBCP198/RFC7608に基づき、longest matchでフォワードするだけ•

C-SID の操作は、IPv6 data plane の概念を変えるものではないか ?

•DAを書き換えるのは、SR aware nodeのみ。（通常のSIDの動作と同様）•

今後必要なこと:• RFC8754, RFC8200のSegment Left Field の定義を更新する必要あり• SRHを必要とせず、C-SIDだけでSRポリシーを表現できる場合もある。 この場合、SRv6 SIDのLOC部分に基づく 何らかの形式のフィルタリングが必要である• ICMPv6処理（RFC8754, section 5.4）のC-SID版が必要
11
Work in Progress -- https://datatracker.ietf.org/doc/draft-ietf-6man-sids/

SRv6 and iPv6 evolution• Introduction

Agenda• Address Semantics• Security• Domain Specific Declarative
Programming• Scaling and Convergence12[draft-ietf-spring-srv6-srh-compression][draft-filsfils-spring-net-pgm-extension-srv6-usid]

https://twitter.com/tschaeferm/status/1526204035539378176

13

[draft-filsfils-spring-net-pgm-extension-srv6-usid][draft-ietf-spring-srv6-srh-compression]• SRv6 is applicable to a contained SR Domain or between collaborating SR Domains
SRv6は限られたSR domain内、または協調するドメイン間に適用される• Nodes outside the SR domain are not trusted [RFC8754, 5.1 Securing SR Domain]
SR domain外のノードは Trust されない、信頼されるべきではない• SRv6 SID allocations and network infrastructure addresses, as distinct from IPv6addresses allocated for end users and systems can provide the clear distinction
between internal and external address space that is required to maintain theintegrity and security of the SRv6 Domain [RFC8986, 9 Security Consideration]
SRv6 SID と インフラストラクチャのアドレスは、エンドユーザやシステムに割り振られるアドレスとは区別されるべき。このことにより、外部と内部のアドレスは明確に区別され、SRv6ドメインのインテグリティとセキュリティが保持される。

14

SRv6 and iPv6 evolution• Introduction

Agenda• Address Semantics• Security• Domain Specific Declarative
Programming• Scaling and Convergence15][draft-filsfils-spring-net-pgm-extension-srv6-usid]• SRv6 Network Programming は Domain Specific• ドメイン内では自由に機能を設定できる• すべてのSRv6ネットワークプログラミング
操作は外部ヘッダに適用される（Ingress PEでプッシュされ、Egress PEで削除される）
ため、End to End の整合性を提供し、顧客パケットが変更されることはない

16
https://blog.apnic.net/2020/05/01/what-is-srv6-network-programming/

[draft-filsfils-spring-net-pgm-extension-srv6-usid][draft-ietf-spring-srv6-srhion]

ドメインスペシフィックプログラミング言語とは ?

なぜそれを使うべきなのか ?

特定領域に特化した、表現力は限定される、コンピュータプログラミング言語

Declarative だから！
https://speakerdeck.com/rahulmalik/writing-domain-specific-languages-in-swift17Declarative

Procedure/Imperative逐一指示するモデル：

意図する結果を予め合意するモデル：

指示の一部が失われたり、Ackが届かなかった
り、処理に誤りがあったりすると、指示の意図と結果が異なる可能性がある。

方法の指示でなく、結果を合意しているため、不確定性の高い環境においても頑健である。

18
https://www.linuxjournal.com/content/promise-theory%E2%80%94what-itetf-spring-srv6-srh-compression]usid]** T(Transit behavior) is now defined as H(Headend behavior)

19
https://p4.org/assets/p4-ws-2017-the-extensible-network.pdf

SRv6 and iPv6 evolution• Introduction

Agenda• Address Semantics• Security• Domain Specific Declarative
Programming• Scaling and Convergence20

tf-spring-srv6-ompression]usid]
SRv6 の最大の特長は、シンプル性とスケーラビリティ
・サマライゼーションと End-to-End 到達性-Prefix summarization (MPLSでは不可能だった)-

広大なアドレス空間とEnd-to-End 到達性-

SRv6 micro SIDs (uSIDs) によるさらなるスケールとMTU最適化

・IP の基本に戻る-

Summarization と Longest Match-

BGP Inter-AS Option A/B/C の必要なし

21

•

SRv6 の強みは IPv6サマライゼーション によるスケーラビリティ•

しかし、inter-area/domain サマライゼーションにより、特定の prefix 障害時にFast Convergence できない
(e.g. Remote domain の PEに障害が起きても、BGP PICが動作しない)
à Unreachable Prefix Announcement••

I-D : draft-ppsenak-lsr-igp-ureach-prefix-announce
Demo : https://www.youtube.com/watch?v=i28RgnUcD4w

22

SRv6 and iPv6 evolution• SRv6は、IoT関連プロトコルとともに、IP技術とアーキテクチャに進化をもたらしている。

Conclusion• Address Semantic, Security, Domain
Specific Declarative Language, Scaling andConvergence という側面からSRv6による進化を考察した• Domain Specific性が、進化を促進する一つのキーかもしれない。

23

• Design Pattern のひとつ•

より大きな領域をモデル化しようとすると、単一の統一されたモデルを構築することは次第に難しくなる•

その結果、モデリングの精度は急速に低下し、しばしば多くの混乱を招くことになる

まずはドメインを区切って、その中で反復的に深化させて行く••“Domain-Driven Design: Tackling Complexity in the Heart of Software”, Eric Evans, Addison-Wesley
24
https://martinfowler.com/bliki/BoundedContext.html

GlobalDomain Specific•

25
Image from https://levelup.gitconnected.com/three-ways-to-make-an-infinite-loop-3d073fac5547