RFC8986 Segment Routing over IPv6 (SRv6) Network Programming
はじめに
この文書は RFC8986 Segment Routing over IPv6 (SRv6) Network Programming の翻訳です。
翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献、RFC2119のやつ等は省略しています。
この文書はドラフトであるため、用語や表記が統一されていなかったり、仕様の内容について曖昧な部分がありますが、原文に忠実になるように訳しています。
免責
この翻訳を信用して不利益を被っても責任取れません的なやつ。
目次
- はじめに
- 目次
- 概要
- 1. はじめに
- 2. 用語
- 3. SRv6 SID
- 4. SR Endpoint Behavior
- 4.1. End: エンドポイント
- 4.2. End.X: L3クロスコネクト
- 4.3. End.T: 特定のIPv6テーブルのルックアップ
- 4.4. End.DX6: カプセル化解除とIPv6クロスコネクト
- 4.5. End.DX4: カプセル化解除とIPv4クロスコネクト
- 4.6. End.DT6: カプセル化の解除と特定のIPv6テーブルのルックアップ
- 4.7. End.DT4: カプセル化の解除と特定のIPv4テーブルのルックアップ
- 4.7. End.DT46: カプセル化の解除と特定のIPテーブルのルックアップ
- 4.9. End.DX2: カプセル化解除とL2クロスコネクト
- 4.10. End.DX2V: カプセル化解除とVLAN L2テーブルルックアップ
- 4.11. End.DT2U: カプセル化解除とユニキャストMAC L2テーブルルックアップ
- 4.13. End.B6.Envaps: カプセル化を伴うSRv6 Policyに紐付けられたエンドポイント
- 4.16. Flavor
- 5. SR Policy Headend Behavior
- 6. カウンター
- 7. フローベースのハッシュ計算
- 8. コントロールプレーン
- 9. セキュリティに関する考察
- 10. IANAに関する考察
- 11. 参考文献
概要
Segment Routing over IPv6 (SRv6) Network ProgrammingフレームワークではIPv6パケットヘッダーにInstructionのシーケンスをエンコードすることによってネットワーク運用者やアプリケーションがパケット処理プログラムを指定する事が可能になります。
それぞれのInstructionはネットワーク中の1つ以上のノードで実装され、パケット中のSRv6 Segment Identifierによって識別されます。
この文書ではSRv6 Network Programming のコンセプトについて定義し、アンダーレイの最適化を伴った相互運用可能なオーバーレイを実現するための一連の基礎的なSRv6のBehaviorについて定めます。
1. はじめに
Segment Routing [RFC8402] はソースルーティングのパラダイムを活用しています。Ingressノードは「セグメント」と呼ばれるInstructionの順序リストを通じてパケットを導きます。それぞれのInstructionはネットワーク内の特定の位置で実行されるFunctionを表現しています。Functionは実行されるノードにおいてローカルで定義され、セグメントリストの中で単に次に進めるようなものからあらゆる複雑なユーザ定義の動作までに渡ることができます。Network ProgrammingはSegment Routingの単純なものと複雑なものの両方のFunctionを組み合わせて、単なるパケットルーティングを超えるネットワーキングの目標を達成します。
この文書はSRv6 Network Programmingのコンセプトを定義し、アンダーレイの最適化を伴った相互運用可能なオーバーレイを作成することを可能にする主要なSegment Routingの動作の定めます。
[SRV6-NET-PGM-ILLUST] ではこの文書で定義されるコンセプトを図示しています。
読者が Segment Routing Header [RFC8754] に慣れていることを期待しています。
2. 用語
この文書で使用される次の用語はRFC8402で定義されています: Segment Routing (SR)、SR Domain、Segment ID (SID)、SRv6、SRv6 SID、SR Policy、Prefix-SID、Adj-SID
この文書で使用される次の用語はRFC8754で定義されています: Segment Routing Header (SRH)、SR source node、transit node、SR Segment Endpoint Node、Reduced SRH、Segments Left、Last Entry
この文書で使用される次の単語は以下のように定義されます:
FIB: Forwarding Information Base。FIBルックアップはフォワーディングテーブル内でのルックアップです。
SA: 送信元アドレス(Source Address)
DA: 宛先アドレス(Destination Address)
L3: レイヤー3
L2: レイヤー2
ESI: Ethernet Segment Identifier
Per-CE VPNラベル: 同一の「出力接続回線(Outgoing Attachment Circuit)」のすべての経路で共有される接続回線ごとの単一のラベル(RFC4364の4.3.2節)。
Per-VRF VPNラベル: あるVRF(VPN Routing and Forwarding)からのすべての経路で共有されるVRFテーブル全体のための単一のラベル(RFC4364の4.3.2節)。
SL: SRHのSegments Leftフィールド
SRv6 SID Function: SIDのFunction部はそのSIDに結び付けられたローカル動作の不明確な識別子です。これはこの文書の3.1節で公式に定義されます。
SRv6 Endpoint Behavior: SRv6 Segment Endpoint Nodeで実行されるパケット処理動作。この文書の4節でトラフィックエンジニアリングとオーバーレイのユースケースに関連するSRv6 Endpoint Behaviorが定義されます。他のBehavior(サービスプログラミング等)はこの文書の範囲外とします。
SR PolicyはSIDリストに解決されます。SRパスに沿ってS1が最初に訪れるべきSIDで、S2が次に訪れるべきSIDでS3が最後に訪れるべきSIDである時、SIDリストは<S1, S2, S3>のように表現されます。
(SA,DA) (S3, S2, S1; SL)はIPv6パケットを表現していて:
- 送信元アドレス(SA)、宛先アドレス(DA)、次ヘッダーが(SRH)
- SIDリストが<S1, S2, S3>のSRHでSegment LeftがSL
シンボルの<>と()の違いに注意してください。<S1, S2, S3>はS1が最初でS3が最後にたどるべきSIDリストを表現しています。(S3, S2, S1; SL)は同じSIDリストを表現していますが、一番右のSIDがSRHの先頭のSIDで一番左のSIDが末尾のSIDであるSRHフォーマットにエンコードされています。ハイレベルのユースケースでSR Policyを参照するときは簡単のため<S1, S2, S3>の表記を使用します。パケットの詳細な振る舞いについての図を参照するときは(S3, S2, S1; SL)の表記のほうが便利です。
- パケットのペイロードは省略されています。
3. SRv6 SID
RFC8402ではSRv6 Segment Identifierがセグメントと明示的に関連付けられたIPv6アドレスとして定義されています。
SRv6 SIDがIPv6パケットのヘッダーの宛先アドレスフィールドにあるとき、IPv6アドレスとしてIPv6ネットワーク内のトランジットノードを経由してルーティングされます。
この処理はRFC8754の4.3節で定義されていますが、忘備としてここに再掲しておきます
実装の詳細について制約を課すことなく、SRセグメントエンドポイントノードはローカルSIDのためにForwarding Information Base (FIB)エントリーを作成します。 SRv6対応のノードがIPv6パケットを受信したとき、パケットの宛先アドレスに基づいてlongest-prefix-matchのルックアップを実行します。 ルックアップにより次のエントリーが得られます: - ローカルでインスタンス化されたSRv6 SIDを表現するFIBエントリー - ローカルインスタンスを表現するがローカルSRv6 SIDとしてでインスタンス化されているわけではないFIBエントリー - ローカルでない経路を表現するFIBエントリー - マッチしなかった
この文書の4節ではRFC8754の4.3.1節で定義されたものに加えた新しいSRv6 SID Behaviorを定義します。
3.1. SIDフォーマット
この文書ではSRv6 SIDをLOC:FUNCT:ARGで構成されるものであると定義します。Locator (LOC)がSIDの最上位のLビットに、続いてFビットのFunction (FUNCT)、AビットのArgument (ARG)がエンコードされます。Locator長のLは可変で、運用者はLocator長を自由に選択して使用します。FとAはL+F+A<128を満たす限り任意の値を取りえます。L+F+Aが128より小さい場合、SIDの残りのビットはゼロでなければなりません(MUST)。
LocatorはB:Nの形式で表現されることがあります。ここでBはSRv6 SIDブロック(運用者によってSRv6 SIDのために割り振られたIPv6プレフィックス)でNはSIDをインスタンス化した親ノードの識別子です。
SRv6 SIDのLOC部がルーティング可能であるとき、そのSIDをインスタンス化したノードに至ります。
FUNCTはSIDに紐付けられたローカルのBehaviorの不明確な識別子です。
「Function」という単語はSRv6 SID中のビット列を参照します。「Behavior」という単語はそのSIDに紐付けられた振る舞いを識別します。いくつかのBehaviorがこの文書の4節で定義されています。
SRv6 Endpoint Behaviorは処理のために追加の情報(flowやサービスに関連するものなど)を必要とするかもしれません。この情報はSIDのARGビットにエンコードすることができます。
このような場合、ARGビットのセマンティクスとフォーマットはSRv6 Endpoint Behaviorの仕様の一部として定義されるでしょう。
ルーティングされるSIDのARG値は与えられたフロー中のすべてのパケットにおいて不変にしておくべきです(SHOULD)。あるフロー中のパケットでARG値が変化すると、異なるECPMハッシュの結果になり順序逆転が発生する原因となるでしょう。
3.2. SRドメイン内でのSID割り振り
LocatorはIPv6基盤の割り振りと一貫して割り当てられます。
たとえばネットワーク運用者は:
例としてあるモバイルサービスプロバイダは1000台以上の商業ルータと1800台以上のホワイトボックスルータにまたがってSRv6を商用デプロイしています。これらすべての機器はSRv6が有効になっており、SRv6 SIDを広告しています。このプロバイダは歴史的にIPv6をデプロイしており、Unique Local Address (ULA)空間[RFC4193]から基盤アドレスを割り当てていました。彼らはSRv6基盤をサポートするために特に3つの/48プレフィックス(X国、Y国、Z国)を割り振りました。それらの/48プレフィックスから、それぞれのルータには/64プレフィックスを割り当て、そのルータのすべてのSIDがこの中から割り振られました。
もう一つ別の例では、巨大なモバイルと固定回線のサービスプロバイダが国全体に渡るネットワークにSRv6を商用でプロイしています。このプロバイダはRegional Internet Registry(RIR)によって/20のプレフィックスを割り当てられています。彼らはその中からいくつかの/48のプレフィックスをSRv6をデプロイするために基盤に割り振っています。それぞれのルータには/64プレフィックスを割り当て、そのルータのすべてのSIDがこの中から割り振られました。
両方の例でIPv6アドレス消費は最小で、それぞれ利用可能なアドレス空間の10億分の1、100万分の1以下でした。
現在最小の/32のプレフィックスの割り振りをRIRから受けているサービスプロバイダでは、/48のプレフィックスをSRv6をデプロイしている基盤に割り当て、そしてその後/64プレフィックスをそれぞれのSRv6ノードでSIDのために割り振ることができます。
運用者がノードでSIDをインスタンス化したとき、SID値 B:N:FUNCT とそのSIDに紐付けられるBehaviorをこの文書で定義されているレジストリのSRv6 Endpoint Behaviorのコードポイント(表6を参照)から指定します。
このノードはこのSID、B:N:FUNCT をこのSIDのBehaviorを識別するSRv6 Endpoint Behaviorコードポイントとともにコントロールプレーンで広告します(8節を参照)。
SR SourceノードはSIDのFUNCT値を検査してもそのBehaviorを推測することはできません。
そのためSRv6 Endpoint BehaviorコードポイントはコントロールプレーンでSIDとともに広告されます。
SR SourceノードはSRv6 Endpoint Behaviorコードポイントを使用して受信したSID (B:N:FUNCT) とBehaviorをマップします。
SR Sourceノードは望ましいBehaviorとともに広告されているSID (B:N:FUNCT)を選択することで、広告しているノードにおける望ましいBehaviorを選択します。
例として:
ネットワーク運用者がSRv6基盤のために手持ちのブロックからSRv6 SIDブロック2001:db8:bbbb::/48を割り当てます。
ネットワーク運用者はSRv6 Locator 2001:db8:bbbb:3::/64をSR Domain中のあるルータ、例えばRouter 3に割り当てます。
Router 3において、Locator 2001:db8:bbbb:3::/64の中から、ネットワーク運用者またはルータが動的割当を行います:
Router 3とそこに接続された隣接ルータ(Router 4)の間のEnd.X(L3クロスコネクトを伴うEndpoint) BehaviorをFunction 0x0100に関連付けます。このFunctionは16ビットの値でエンコードされ、引数を持ちません(F=16、A=0)。
このSIDはコントロールプレーンでSRv6 Endpoint Behaviorコードポイント値5を持つ 2001:db8:bbbb:3:100:: として広告されます。Router 3とそこに接続された隣接ルータ(Router 2)の間のEnd.X(L3クロスコネクトを伴うEndpoint) BehaviorをFunction 0x0101に関連付けます。このFunctionは16ビットの値でエンコードされ、引数を持ちません(F=16、A=0)。
このSIDはコントロールプレーンでSRv6 Endpoint Behaviorコードポイント値5を持つ 2001:db8:bbbb:3:101:: として広告されます。
これらの例は他のIPv6アドレス割り振りスキームを妨げるものではありません。
3.3. SID到達性
ほとんどの場合でノードNは、そのSIDや、より短いマスクのプレフィックスをカバーするLOC部にマッチするようなIPv6プレフィックスを広告するでしょう。これらの広告の配布やそれらの到達性の計算は使用されるルーティングプロトコル固有のものであるためこの文書の範囲外です。
もしSIDがルーティングプロトコルによって広告されるIPv6プレフィックスに所属するのであれば、SRv6 SIDはルーティングされる(routed)ということができます。この条件を満たさないSRv6 SIDはルーティングされません(non-routed)。
典型的な例で説明しましょう:
ノードNにおいて2つのSID、2001:db8:b:1:100::と2001:db8:b:2:101::が明示的に設定されています。
ネットワークは2001:db8:b:1::/64宛のパスをIGPで学習します。そのため2001:db8:b:1:100::宛のパケットはNへルーティングされます。ネットワークは2001:db8:b:2::/64宛のパスをIGPで学習しません。そのため2001:db8:b:2:101::宛のパケットはNへルーティングされません。
パケットはnon-routed SIDの前に同じノードでのrouted SIDがあるようなSIDリスト<...,2001:db8:b:1:100::,2001:db8:b:2:101::,...>を使用してnon-routedなSIDである2001:db8:b:2:101::を経由して導くことができます。また、パケットをnon-routed SIDをインスタンス化したノードへと、SIDリストでそのノードへのAdj-SIDを先行させることによって導くこともできます。routed SRv6 SIDとnon-routed SRv6 SIDはそれぞれグローバルセグメントとローカルセグメントのSRv6インスタンス化したものです[RFC8402]。
4. SR Endpoint Behavior
SIDに関連付けることができるwell-knownなBehaviorを次に示します。
+-------------------+---------------------------------------------+ | End | Endpoint | | | エンドポイント | | | | | | Prefix-SID[RFC8402]をSRv6インスタンス化した | | | もの | +-------------------+---------------------------------------------+ | End.X | Endpoint with L3 cross-connect | | | L3クロスコネクトのエンドポイント | | | | | | Adj-SID[RFC8402]をSRv6インスタンス化したもの| +-------------------+---------------------------------------------+ | End.T | Endpoint with specific IPv6 table lookup | | | 特定のIPv6テーブルをルックアップするエンド | | | ポイント | +-------------------+---------------------------------------------+ | End.DX6 | Endpoint with decapsulation and IPv6 cross- | | | connect | | | カプセル化を解除してIPv6クロスコネクトを | | | 行うエンドポイント | | | | | | 例: IPv6-L3VPN (per-CE VPNラベルと等価) | +-------------------+---------------------------------------------+ | End.DX4 | Endpoint with decapsulation and IPv4 cross- | | | connect | | | カプセル化を解除してIPv4クロスコネクトを | | | 行うエンドポイント | | | | | | 例: IPv4-L3VPN (per-CE VPNラベルと等価) | +-------------------+---------------------------------------------+ | End.DT6 | Endpoint with decapsulation and specific | | | IPv6 table lookup | | | カプセル化を解除して特定のIPv6テーブルを | | | ルックアップするエンドポイント | | | | | | 例: IPv6-L3VPN (per-VRF VPNラベルと等価) | +-------------------+---------------------------------------------+ | End.DT4 | Endpoint with decapsulation and specific | | | IPv4 table lookup | | | カプセル化を解除して特定のIPv4テーブルを | | | ルックアップするエンドポイント | | | | | | 例: IPv4-L3VPN (per-VRF VPNラベルと等価) | +-------------------+---------------------------------------------+ | End.DT46 | Endpoint with decapsulation and specific IP | | | table lookup | | | カプセル化を解除して特定のIPテーブルを | | | ルックアップするエンドポイント | | | | | | 例: IP-L3VPN (per-VRF VPNラベルと等価) | +-------------------+---------------------------------------------+ | End.DX2 | Endpoint with decapsulation and L2 cross- | | | connect | | | カプセル化を解除してL2クロスコネクトを | | | 行うエンドポイント | | | | | | 例: L2VPNユースケース | +-------------------+---------------------------------------------+ | End.DX2V | Endpoint with decapsulation and VLAN L2 | | | table lookup | | | カプセル化を解除してVLAN L2テーブルを | | | ルックアップするエンドポイント | | | | | | 例: EVPN Flexible Cross-connectの | | | ユースケース | +-------------------+---------------------------------------------+ | End.DT2U | Endpoint with decapsulation and unicast MAC | | | L2 table lookup | | | カプセル化を解除してユニキャストMAC L2 | | | テーブルをルックアップするエンドポイント | | | | | | 例: EVPN Bridging Unicastのユースケース | +-------------------+---------------------------------------------+ | End.DT2M | Endpoint with decapsulation and L2 table | | | flooding | | | カプセル化を解除してL2テーブルで | | | フラッディングするエンドポイント | | | | | | 例: EVPN BridgingのBroadcast、Unknown | | | Unicast、Multicast (BUM)のユースケースで | | | Ethernet Segment Identifier (ESI) | | | フィルタリングを行う | +-------------------+---------------------------------------------+ | End.B6.Encaps | Endpoint bound to an SRv6 Policy with | | | encapsulation | | | カプセル化を伴うSRv6 Policyに紐付けられた | | | エンドポイント | | | | | | Binding SIDをSRv6インスタンス化したもの | +-------------------+---------------------------------------------+ | End.B6.Encaps.Red | End.B6.Encaps with reduced SRH | | | Reduced SRHを行うEnd.B6.Encaps | | | | | | Binding SIDをSRv6インスタンス化したもの | +-------------------+---------------------------------------------+ | End.BM | Endpoint bound to an SR-MPLS Policy | | | SR-MPLS Policyに紐付けられたエンドポイント | | | | | | SR-MPLS Binding SIDをSRv6インスタンス化した | | | もの | +-------------------+---------------------------------------------+
表1: Endpoint Behavior
このリストは完全ではありません。実際にはいかなるBehaviorでもローカルSIDに関連付けることができます。例えば、SRv6 Endpoint Behaviorコードポイントが割り振られていれば、あるノードNはSIDをローカルの仮想マシン(VM)やコンテナに紐づけて複雑なパケット処理を行うようなことができます。
SRv6対応のノード(N)がIPv6パケットを受信して、その宛先アドレスがローカルでインスタンス化されたSRv6 SID (S)を表現するFIBエントリーとマッチしたとき、IPv6ヘッダーチェインはRFC8200の4節に定義されているように処理されます。この文書で定義されているEndpoint Behaviorと関連付けられているSRv6 SIDに対しては、SRHとUpper-Layerヘッダは次の小節で定義されているように処理されます。
4.16節ではこれらのBehaviorのうちのいくつかのフレーバーを定義しています。
この文書の10.2節ではこれらすべてのBehaviorに加えて他の文書で定義される将来的なBehaviorを管理するために使用されるIANAレジストリについて定義しています。
4.1. End: エンドポイント
Endpoint Behavior (略して「End」)は最も基本的なBehaviorです。これはPrefix-SID [RFC8402]をインスタンス化したものです。
NがIPv6 DAがSであるパケットを受信して、そのSがローカルのEnd SIDであるとき、Nは次のようにします:
S01. SRHが処理されたとき { S02. If (Segments Left == 0) { S03. SRHの処理を停止して、ルーティングヘッダのNext Headerフィールドで 識別されるタイプのネクストヘッダの処理に進む S04. } S05. If (IPv6 Hop Limit <= 1) { S06. 送信元アドレスに、Codeが0 (Hop limit exceeded in transit)の ICMP Time Exceededメッセージを送信し、パケット処理を中断し、 パケットを破棄する。 S07. } S08. max_LE = (Hdr Ext Len / 2) - 1 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { S10. 送信元アドレスに、Codeを0 (Erroneous header field encountered)、 PointerをSegment Leftフィールドに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する。 S11. } S12. IPv6 Hop Limitを1減らす S13. Segments Leftを1減らす S14. IPv6 DAをSegment List[Segments Left]で更新する S15. 新しい宛先に転送するためのEgress IPv6 FIBルックアップにパケットを渡す S16. }
注意:
End Behaviorはパケットに関連付けられた同じFIBテーブル(例えば VRFやL3リレーIDで識別されるもの)で実行されます。そのためS15行目のFIBルックアップはIngressインターフェイスと同じFIBテーブルで行われます。
4.1.1. Upper-Layerヘッダ
End SIDとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理するとき、Nは次のようにします:
S01. If (Upper-Layerヘッダタイプがローカルの設定で許可されている) { S02. Upper-Layerヘッダの処理に進む S03. } Else { S04. 送信元アドレスに、Codeを4 (SR Upper-layer Header Error)、 PointerをUpper-Layerヘッダのオフセットに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する。 S05 }
特定のUpper-Layerヘッダタイプの処理を許可することは運用・管理・維持 (OAM)のために有用です。例として、運用者がSIDへのpingを許可することが挙げられます。このためにはUpper-Layerヘッダタイプ58 (ICMPv6)を許可するローカルの設定を有効化します。
パケットが転送されない結果になるタイプ(例えばICMPv6)のUpper-Layerヘッダ処理だけが許可されるようなローカル設定の実装が推奨されます(RECOMMENDED)。
4.2. End.X: L3クロスコネクト
「L3クロスコネクトのエンドポイント」のBehavior (略して「End.X」)はEnd Behaviorの派生です。
これはAdj-SID [RFC8402]をSRv6インスタンス化したものであり、トラフィックエンジニアリングのポリシーのために主に使用されます。
このBehaviorのいずれのSIDインスタンスも、一つ以上のL3隣接性の集合Jと関連付けられます。
NがS宛のパケットを受信して、このSがローカルのEnd.X SIDであるとき、End処理のS15行目が次のように置き換えられます。
S15. 新しい宛先にJの要素を経由して転送するためのIPv6モジュールに パケットを提出します
注意:
S15. もし集合Jが複数のL3隣接性を含んでいた場合、パケットのヘッダのハッシュに基づいて集合のうち一つの要素が選ばれます(7節を参照)。
もしノードNが30個のネイバーに向かう30個の出力インターフェイスを持っていたとき、運用者は通常明示的に30個のEnd.X SIDをNでインスタンス化するでしょう。潜在的にはそれ以上の数のEnd.Xを明示的に定義することができます(同じネイバーや異なるネイバーへのL3隣接性のグループ)。
もしNがネイバーQに対する10本のメンバーリンクでできたバンドルIを出力インターフェイスとして持っていた場合、Nは最大11個のEnd.XローカルSIDを割り振るでしょう。1つがバンドルそのものに対するもので、それぞれのL2メンバーリンクについて最大1つです。バンドルそのものに対応するEnd.X SIDを使用して導かれるフローはハッシュされてメンバーリンク間でロードバランスされます。一方で個別のメンバーリンクに対応するEnd.X SIDを使用して導かれるフローはその特定のメンバーリンクだけを通じて導かれます。
End.X BehaviorがBGP Next-Hopと関連付けられているとき、これはBGPピアリングセグメント[RFC8402]をSRv6インスタンス化したものです。
End.X SIDとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合は4.1.1節に従ってパケットを処理します。
4.3. End.T: 特定のIPv6テーブルのルックアップ
「特定のIPv6テーブルをルックアップするエンドポイント」のBehavior (略して「End.DX6」)はEnd.X Behaviorの派生です。
End.T Behaviorはコアにおけるマルチテーブルの運用で使用されます。この理由から、End.T BehaviorのインスタンスはIPv6 FIBテーブルTに関連付けられます。
NがS宛のパケットを受信して、そのSがローカルのEnd.T SIDであったとき、End処理のS15行目は次のように置き換えられます:
S15.1. パケットに関連付けられたFIBテーブルをTに設定する S15.2. 新しい宛先に転送するためパケットをEgress IPv6 FIBルックアップに渡す
End.T SIDとしてローカルでインスタンス化されたFIB エントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合は4.1.1節に従ってパケットを処理します。
4.4. End.DX6: カプセル化解除とIPv6クロスコネクト
「カプセル化を解除して特定のIPv6テーブルをルックアップするエンドポイント」のBehavior(略して「End.DX6」)はEnd.X Behaviorの派生です。
End.DX6 Behaviorの応用の一つとして、Egress Providor Edge(PE)においてFIBルックアップを特定のテナントのテーブルで行う必要がないL3VPNv6のユースケースがあります。これはMPLSのper-CE VPNラベル[RFC4364]と等価です。
End.DX6 SIDはSR Policyの末尾のセグメントでなければなりません(MUST)。そして一つ以上のL3 IPv6隣接性Jと関連付けられています。
NがS宛のパケットを受信して、そのSがローカルのEnd.DX6 SIDであるとき、Nは次のようにします:
S01. SRHが処理されたとき { S02. If (Segments Left != 0) { S03. 送信元アドレスに、Codeを0 (Erroneous header field encountered)、 PointerをSegments Leftフィールドに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する S04. } S05. パケットのネクストヘッダの処理に進む S06. }
End.DX6 SIDとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合、Nは次のようにします:
S01. If (Upper-Layer header type == 41(IPv6) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. 露わになったIPv6パケットをL3隣接性Jに転送する S04. } Else { S05. 4.1.1節に従って処理する S06. }
注意
S01. 「41」はIANAの「Assigned Internet Protocol Numbers」レジストリに定義されているように「IPv6カプセル化」を参照しています。
S03. End.DX6 SIDがL3隣接性の配列に紐付けられている場合、その配列の1つのエントリーがパケットのヘッダのハッシュに基づいて選択されます(7節を参照)。
4.5. End.DX4: カプセル化解除とIPv4クロスコネクト
「カプセル化を解除してIPv4クロスコネクトを行うエンドポイント」のBehavior (略して「End.DX4」)はEnd.X Behaviorの派生です。
End.DX4 Behaviorの応用の一つとして、Egress Providor Edge(PE)においてFIBルックアップを特定のテナントのテーブルで行う必要がないL3VPNv4のユースケースがあります。これはMPLSのper-CE VPNラベル[RFC4364]と等価です。
End.DX4 SIDはSR Policyの末尾のセグメントでなければなりません(MUST)。そして一つ以上のL3 IPv4隣接性Jと関連付けられています。
NがS宛のパケットを受信して、そのSがローカルのEnd.DX4 SIDであるとき、Nは次のようにします:
S01. SRHが処理されたとき { S02. If (Segments Left != 0) { S03. 送信元アドレスに、Codeを0 (Erroneous header field encountered)、 PointerをSegments Leftフィールドに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する S04. } S05. パケットのネクストヘッダの処理に進む S06. }
End.DX4 SIDとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合、Nは次のようにします:
S01. If (Upper-Layer header type == 41(IPv6) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. 露わになったIPv4パケットをL3隣接性Jに転送する S04. } Else { S05. 4.1.1節に従って処理する S06. }
注意
S01. 「4」はIANAの「Assigned Internet Protocol Numbers」レジストリに定義されているように「IPv4カプセル化」を参照しています。
S03. End.DX4 SIDがL3隣接性の配列に紐付けられている場合、その配列の1つのエントリーがパケットのヘッダのハッシュに基づいて選択されます(7節を参照)。
4.6. End.DT6: カプセル化の解除と特定のIPv6テーブルのルックアップ
「カプセル化を解除して特定のIPv6テーブルをルックアップするエンドポイント」のBehavior (略して「End.DT6」)はEnd.T Behaviorの派生です。
End.DT6 Behaviorの応用の一つとして、Egress PEにおいて特定のテナントのテーブルでFIBルックアップをする必要があるL3VPNv6のユースケースが挙げられます。これはMPLSにおけるper-VRF VPNラベル[RFC4364]と等価です。
End.DT6はメインのIPv6テーブルのために定義されるかもしれないことに留意してください。この場合End.DT6はIPv6-in-IPv6の(VPN/テナントの関与しない)カプセル化解除と等価なものをサポートします。
End.DT6 SIDはSR Policyにおいて末尾のセグメントでなければなりません(MUST)。そしてSIDインスタンスはIPv6 FIBテーブルTに関連付けられます。
NがS宛のパケットを受信して、そのSがローカルのEnd.DT6 SIDであるとき、Nは次のようにします:
S01. SRHが処理されたとき { S02. If (Segments Left != 0) { S03. 送信元アドレスに、Codeを0 (Erroneous header field encountered)、 PointerをSegments Leftフィールドに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する S04. } S05. パケットのネクストヘッダの処理に進む S06. }
End.DT6 SIDとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合、Nは次のようにします:
S01. If (Upper-Layer header type == 41(IPv6) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. パケットの関連付けれられるFIBテーブルをTに設定する S04. 新しい宛先に転送するためパケットをEgress IPv6 FIBルックアップに渡す S05. } Else { S06. 4.1.1節に従って処理する S07. }
4.7. End.DT4: カプセル化の解除と特定のIPv4テーブルのルックアップ
「カプセル化を解除して特定のIPv4テーブルをルックアップするエンドポイント」のBehavior (略して「End.DT4」)はEnd.T Behaviorの派生です。
End.DT4 Behaviorの応用の一つとして、Egress PEにおいて特定のテナントのテーブルでFIBルックアップをする必要があるL3VPNv4のユースケースが挙げられます。これはMPLSにおけるper-VRF VPNラベル[RFC4364]と等価です。
End.DT4はメインのIPv4テーブルのために定義されるかもしれないことに留意してください。この場合End.DT4はIPv4-in-IPv6の(VPN/テナントの関与しない)カプセル化解除と等価なものをサポートします。
End.DT4 SIDはSR Policyにおいて末尾のセグメントでなければなりません(MUST)。そしてSIDインスタンスはIPv4 FIBテーブルTに関連付けられます。
NがS宛のパケットを受信して、そのSがローカルのEnd.DT4 SIDであるとき、Nは次のようにします:
S01. SRHが処理されたとき { S02. If (Segments Left != 0) { S03. 送信元アドレスに、Codeを0 (Erroneous header field encountered)、 PointerをSegments Leftフィールドに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する S04. } S05. パケットのネクストヘッダの処理に進む S06. }
End.DT6 SIDとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合、Nは次のようにします:
S01. If (Upper-Layer header type == 4(IPv4) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. パケットの関連付けれられるFIBテーブルをTに設定する S04. 新しい宛先に転送するためパケットをEgress IPv4 FIBルックアップに渡す S05. } Else { S06. 4.1.1節に従って処理する S07. }
4.7. End.DT46: カプセル化の解除と特定のIPテーブルのルックアップ
「カプセル化を解除して特定のIPテーブルをルックアップするエンドポイント」のBehavior (略して「End.DT46」)はEnd.DT4 BehaviorとEnd.DT6 Behaviorの派生です。
End.DT46 Behaviorの応用の一つとして、Egress PEにおいて特定のIPテナントのテーブルでFIBルックアップをする必要があるL3VPNv4のユースケースが挙げられます。これはMPLSにおける(IPv4とIPv6のための)per-VRF VPNラベル[RFC4364]と等価です。
End.DT46はメインのIPテーブルのために定義されるかもしれないことに留意してください。この場合End.DT46はIP-in-IPv6の(VPN/テナントの関与しない)カプセル化解除と等価なものをサポートします。
End.DT46 SIDはSR Policyにおいて末尾のセグメントでなければなりません(MUST)。そしてSIDインスタンスはIPv4 FIBテーブルT4とIPv6 FIBテーブルT6に関連付けられます。
NがS宛のパケットを受信して、そのSがローカルのEnd.DT46 SIDであるとき、Nは次のようにします:
S01. SRHが処理されたとき { S02. If (Segments Left != 0) { S03. 送信元アドレスに、Codeを0 (Erroneous header field encountered)、 PointerをSegments Leftフィールドに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する S04. } S05. パケットのネクストヘッダの処理に進む S06. }
End.DT46 SIDとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合、Nは次のようにします:
S01. If (Upper-Layer header type == 4(IPv4) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. パケットの関連付けれられるFIBテーブルをT4に設定する S04. 新しい宛先に転送するためパケットをEgress IPv4 FIBルックアップに渡す S05. } Else if (Upper-Layer header type == 41(IPv6) ) { S06. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S07. パケットの関連付けれられるFIBテーブルをT6に設定する S08. 新しい宛先に転送するためパケットをEgress IPv6 FIBルックアップに渡す S09. } Else { S10. 4.1.1節に従って処理する S11. }
4.9. End.DX2: カプセル化解除とL2クロスコネクト
「カプセル化を解除してL2クロスコネクトを行うエンドポイント」のBehavior (略して「End.DX2」)はEndpoint Behaviorの派生です。
End.DX2 Behaviorの応用の一つとして、L2VPN[RFC4664] / EVPN Virtual Private Wire Service (VPWS) [RFC7432] [RFC8214] のユースケースが挙げられます。
End.DX2 SIDはSR Policyにおいて末尾のセグメントでなければなりません(MSUT)。そして一つの出力インターフェイスIに関連付けられなければなりません。
NがS宛てのパケットを受信して、そのSがローカルのEnd.DX2 SIDであるとき、Nは次のようにします:
S01. SRHが処理されたとき { S02. If (Segments Left != 0) { S03. 送信元アドレスに、Codeを0 (Erroneous header field encountered)、 PointerをSegments Leftフィールドに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する S04. } S05. パケットのネクストヘッダの処理に進む S06. }
End.DX2 SIDとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合、Nは次のようにします:
S01. If (Upper-Layer header type == 143(Ethernet) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. イーサネットフレームをOIF Iに転送する S04. } Else { S05. 4.1.1節に従って処理する S06. }
注意:
S01. IANAによって「Assigned Internet Protocol Numbers」レジストリで値「143」が「Ethernet」[IEEE.802.3_2018]に割り振られています(10.1節を参照)。
S03. End.DX2 Behaviorは特定のIEEEヘッダ(例えばVLANタグなど)を期待して、出力インターフェイスで転送する前にEgress IEEEヘッダを書き換えるようにカスタマイズすることができます。
End.DX2 SIDは出力インターフェイスのバンドルにも関連付けられるかもしれないことに留意してください。
4.10. End.DX2V: カプセル化解除とVLAN L2テーブルルックアップ
「カプセル化を解除してVLAN L2テーブルをルックアップするエンドポイント」のBahavior (略して「End.DX2V」)はEnd.DX2 Behaviorの派生です。
End.DX2V Behaviorの応用の一つとして、EVPN Flexible Cross-connectのユースケースが挙げられます。End.DX2V Behaviorは、特定のL2テーブルに置いてイーサネットフレームのVLANのルックアップを行うために使用されます。このBehaviorのいずれのSIDインスタンスもL2テーブルTと関連付けられます。
NがIPv6 DAがSであるパケットを受信して、そのSがローカルのEnd.DX2 SID(訳注: 正しくはEnd.DX2V SIDだと思われる)である場合、End.DX2 Behaviorに固有の処理はUpper-Layerヘッダの処理を除いて次のように修正されます:
S03. 露わになったMAC宛先アドレスをL2テーブルTでルックアップして マッチしたテーブルTのエントリーで転送する
注意:
S03. End.DX2V Bahaviorは特定のVLANフォーマットを期待して、Egress VLANヘッダを出力インターフェイスで転送する前に書き換えるようにカスタマイズすることができます。
4.11. End.DT2U: カプセル化解除とユニキャストMAC L2テーブルルックアップ
「カプセル化を解除してユニキャストMAC L2テーブルをルックアップするエンドポイント」のBahavior(略して「End.DT2U」)はEnd Behaviorの派生です。
End.DT2U Behaviorの応用の一つとして、EVPN Bridging Unicast [RFC7432] が挙げられます。End.DT2U BehaviorのいずれのSIDインスタンスもL2テーブルTと関連付けれられます。
NがIPv6 DAがSであるパケットを受信して、そのSがローカルのEnd.DT2U SIDである場合、End.DX2 Behaviorに固有の処理のうちUpper-Layerヘッダの処理を除いて次のようになります:
S01. If (Upper-Layer header type == 143(Ethernet) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. 露わになったMAC送信元アドレスをL2テーブルTで学習する S04. 露わになったMAC宛先アドレスをL2テーブルTでルックアップする S05. If (Tでマッチした) { S06. マッチしたテーブルTのエントリーで転送する S07. } Else { S08. テーブルTのすべてのOIFで転送する S09. } S10. } Else { S11. 4.1.1節に従って処理する S12. } ``` > 注意: > > S01. IANAによって「Assigned Internet Protocol Numbers"」レジストリで値「143」が「Ethernet」[[IEEE.802.3_2018](https://ieeexplore.ieee.org/document/8457469)]に割り振られています(10.1節を参照)。 > > S03. EVPN [[RFC7432](https://www.rfc-editor.org/info/rfc7432)] において、露わになったMAC送信元アドレスの学習はコントロールプレーンで行われます。L2VPN Virtual Private LAN Service (VPLS) [[RFC4761](https://www.rfc-editor.org/info/rfc4761)] [[RFC4762](https://www.rfc-editor.org/info/rfc4762)] において、到達性はデータプレーンの標準的な学習ブリッジ機能によって得られます。 ## 4.12. End.DT2M: カプセル化解除L2テーブルフラッディング 「カプセル化を解除してL2テーブルでフラッディングするエンドポイント」のBehavior(略して「End.DT2M」) はEnd.DT2U Behaviorの派生です。 End.DT2M Behaviorの応用は2つ上げることができます。Ethernet Segment Identifier (ESI)フィルタリングを行うBroadcast、Unknown Unicast、Multicast (BUM)トラフィックのEVPN BridgingのユースケースとEVPN Ethernet-Tree (E-Tree)のユースケースです。 このBehaviorのいかなるSIDインスタンスもL2テーブルTと関連付けられます。このBehaviorは引数「Arg.FE2」を取ります。この引数は、受信したトラフィックのL2テーブルTでのフラッディングから特定のOIF(または複数のOIF)を除外するスプリットホライズンフィルタリングのためのESIのローカルマッピングを提供します。この引数の割り振りはこのBehaviorをインスタンス化するSR Segment Endpoint Nodeでローカルです。EVPNの機能のために他のノードへコントロールプレーンでこの引数を伝達します。 NがIPv6 DAがSであるパケットを受信して、そのSがローカルのEnd.DT2M SIDである場合、End.DX2 Behaviorに固有の処理のうちUpper-Layerヘッダの処理を除いて次のようになります:
S01. If (Upper-Layer header type == 143(Ethernet) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. 露わになったMAC送信元アドレスをL2テーブルTで学習する S04. 識別子Arg.FE2に関連付けられたOIFを除く全てのL2 OIFで転送する S05. } Else { S06. 4.1.1節に従って処理する S07. } ```
注意:
S01. IANAによって「Assigned Internet Protocol Numbers"」レジストリで値「143」が「Ethernet」[IEEE.802.3_2018]に割り振られています(10.1節を参照)。
S03. EVPN [RFC7432] において、露わになったMAC送信元アドレスの学習はコントロールプレーンで行われます。L2VPN Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762] において、到達性はデータプレーンの標準的な学習ブリッジ機能によって得られます。
4.13. End.B6.Envaps: カプセル化を伴うSRv6 Policyに紐付けられたエンドポイント
これはEnd Behaviorの派生です。
この応用の一つとして、複数のドメインにまたがったスケーラブルなトラフィックエンジニアリングポリシーを表現することが挙げられます。これはBinding SID [RFC8402] をSRv6インスタンス化したものの一つです。
このBehaviorのいずれのSID インスタンスもSR Policy Bと送信元アドレスAに関連付けられます。
NがIPv6 DAがSであるパケットを受信して、そのSがローカルのEnd.B6.Encapsである場合、Nは次のようにします:
S01. When an SRH is processed { S02. If (Segments Left == 0) { S03. SRHの処理を停止して、ルーティングヘッダのNext Headerフィールドで 識別されるタイプのネクストヘッダの処理に進む S04. } S05. If (IPv6 Hop Limit <= 1) { S06. 送信元アドレスに、Codeが0 (Hop limit exceeded in transit)の ICMP Time Exceededメッセージを送信し、パケット処理を中断し、 パケットを破棄する S07. } S08. max_LE = (Hdr Ext Len / 2) - 1 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { S10. 送信元アドレスに、Codeを0 (Erroneous header field encountered)、 PointerをSegment Leftフィールドに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する S11. } S12. IPv6 Hop Limitを1減らす S13. Segments Leftを1減らす S14. IPv6 DAをSegment List[Segments Left]で更新する S15. Bを含む自分自身のSRHを持った新しいIPv6ヘッダをPushする S16. 外側のIPv6 SAをAに設定する S17. 外側のIPv6 DAをBの先頭のSIDに設定する S18. 外側のPayload Length、Traffic Class、Flow Label、Hop Limit、 Next Headerフィールドを設定する S19. 新しい宛先に転送するためのEgress IPv6 FIBルックアップにパケットを渡す S20. } ``` > 注意: > > S15. SRv6 Policy Bが一つのSIDを含んでいるだけでフラグやタグやTLVを使用する必要がないとき、SRHは省略することができます(MAY) > > S18. Payload Length、Traffic Class、Hop Limit、Next Headerフィールドは[[RFC2473](https://www.rfc-editor.org/info/rfc2473>)]に従って設定されます。Flow Labelは[[RFC6437](https://www.rfc-editor.org/info/rfc6437)]に従って計算されます。 End.B6.Encapsとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合、4.1.1節に従ってパケットを処理します。 ## 4.14. End.B6.Encaps.Red: Reduced SRHを行うEnd.B6.Encaps これはEnd.B6.Encaps Behaviorを最適化したものです。 End.B6.Encaps.Redは新しいIPv6ヘッダのSRH中の先頭ののSIDを除外することでSRHのサイズをSID 1つ分減らします。そのため最初のセグメントは新しいIPv6ヘッダのIPv6宛先アドレスにだけ存在し、パケットはそれに従って転送されます。 SRH Last EntryフィールドはRFC8754の4.1.1節に従って設定されます。 SRv6 Policy Bが一つのSIDを含んでいるだけでフラグやタグやTLVを使用する必要がないとき、SRHは省略することができます(MAY) ## 4.15. End.BM: SR-MPLS Policyに紐付けられたエンドポイント 「SR-MPLS Policyに紐付けられたエンドポイント」のBehavior(略して「End.BM」)はEnd Behaviorの派生です。 End.BM Behaviorは複数のドメインのうちいくつかのドメインがSegment RoutingのMPLSインスタンス化をサポートするようなドメインにまたがった、スケーラブルなトラフィックエンジニアリングポリシーを表現するために必要です。これはSR-MPLS Binding SID [[RFC8402](https://www.rfc-editor.org/info/rfc8402)]のSRv6インスタンス化です。 このBehaviorのいずれのSIDインスタンスもSR-MPLS Policy Bに関連付けられます。 NがIPv6 DAがSであるパケットを受信して、そのSがローカルのEnd.BMである場合、Nは次のようにします:
S01. When an SRH is processed { S02. If (Segments Left == 0) { S03. SRHの処理を停止して、ルーティングヘッダのNext Headerフィールドで 識別されるタイプのネクストヘッダの処理に進む S04. } S05. If (IPv6 Hop Limit <= 1) { S06. 送信元アドレスに、Codeが0 (Hop limit exceeded in transit)の ICMP Time Exceededメッセージを送信し、パケット処理を中断し、 パケットを破棄する S07. } S08. max_LE = (Hdr Ext Len / 2) - 1 S09. If *1 { S10. 送信元アドレスに、Codeを0 (Erroneous header field encountered)、 PointerをSegment Leftフィールドに設定したICMP Parameter Problemを送信し、パケット処理を中断し、パケットを破棄する S11. } S12. IPv6 Hop Limitを1減らす S13. Segments Leftを1減らす S14. IPv6 DAをSegment List[Segments Left]で更新する S15. BのためのMPLSラベルスタックをPushする S16. 転送のためパケットをMPLSエンジンに渡す S17. } ```
End.BMとしてローカルでインスタンス化されたFIBエントリーにマッチしたパケットのUpper-Layerヘッダを処理する場合、4.1.1節に従ってパケットを処理します。
4.16. Flavor
SRHのPenultimate Segment Pop (PSP)、Ultimate Segment Pop (USP)、Ultimate Segment DecapsulationなどのFlavorはEnd、End.X、End.T Behaviorの派生です。End、End.X、End.T BehaviorはこれらのFlavorを個別または組み合わせてサポートすることができます。
4.16.1. PSP: SRHのPenultimate Segment Pop
4.16.1.1. ガイドライン
SR Segment Endpoint Nodeは8節に記述するようにインスタンス化したSIDをコントロールプレーンで広告します。Flavored SIDとUnflavored SIDのそれぞれに異なるIDが割り振られます(表6参照)。
PSP-flavored Behaviorとnon-PSP-flavored Behaviorの両方に対応できるSR Segment Endpoint Nodeは異なる2つのSIDとしてこれらを広告します。
運用者がこのCapabilityをそのノードにおいて有効化した場合、SR Segment Endpoint NodeはPSP Flavorだけを広告します。
PSPの実施はSR Source Nodeにおいて決定的に制御されます。
IPv6ヘッダからSRHを削除するために、SRHでリストされたPenultimate SR Segment Endpoint Nodeを指示する必要があるとき、PSP-flavored SIDはSR Source Nodeで使用されます。
4.16.1.2. 定義
SR Segment Endpoint NodeはIPv6ヘッダの宛先アドレスフィールドがそのSIDアドレスと等しいIPv6パケットを受信します。
Penultimate SR Segment Endpoint Nodeは、SID処理の一部として、末尾のSIDをSRHからIPv6宛先アドレスにコピーし、Segment Leftの値を1からゼロに減らすようなノードです。
PSPはPenultimate SR Segment Endpoint Nodeにおいてだけ実施され、いかなるTransit Nodeにおいても実施されません。PSP FlavorのSIDがPenultimate SR Segment Endpoint Nodeでないノードで処理されるとき、Segment Leftがゼロにならないため下記の擬似コードに記載するようにPSP Behaviorは実行されません。
End、End.X、End.TのBehaviorのSRH処理は次のように修正されます: 「S14. IPv6 DAをSegment List[Segments Left]で更新する」の命令が実行されたあと、次の命令が加えて実行されなければなりません:
S14.1. If (Segments Left == 0) { S14.2. 後続のヘッダのNext Headerフィールドを更新して、 SRHのNext Header値にする S14.3. IPv6ヘッダのPayload Lengthを8*(Hdr Ext Len+1)だけ減らす S14.4. IPv6拡張ヘッダのチェインからSRHを削除する S14.5. }
PSPの使用によってIPv6パケットのMTUが増えることはありません。そのためPath MTU(PMTU) Discovery機構への影響はありません。
忘備として、RFC8754の5節ではSR Domain [RFC8402]内でのSR Deployment Modelについて定義しています。このフレームワークにおいてApplication Header (AH)はRFC8754の7.5節に記載されているようにSRHを確保するためには使用されません。そのためAHを伴ったPSPの適用可能性についての議論はこの文書の範囲外とします。
この仕様のコンテキストにおいて、PSPを行うEnd、End.X、End.TのBehaviorはRFC8200の4節に違反しません。なぜなら到着するパケットの宛先アドレスはBehaviorを実行するノードのアドレスだからです。
4.16.1.3. ユースケース
PSP機能のユースケースの一つとして、Egressボーダールータの運用を効率化することが挙げられます。
+----------------------------------------------------+ | | +-+-+ +--+ +--+ +--+ +-+-+ |iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE| | R1| +--+ +--+ +--+ |R5 | +-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+ | |IPv6 | |IPv6 | |IPv6 | |IPv6 | | | |DA=R3| |DA=R3| |DA=R5| |DA=R5| | | +-----+ +-----+ +-----+ +-----+ | | | SRH | | SRH | | IP | | IP | | | |SL=1 | |SL=1 | +-----+ +-----+ | | | R5 | | R5 | | | +-----+ +-----+ | | | IP | | IP | | | +-----+ +-----+ | | | +----------------------------------------------------+
上記の図において、パケットはIngress Provider Edge (iPE)からEgress Provider Edge (ePE)へ送信されたパケットについて、ノードR3は中間のトラフィックエンジニアリング地点であり、Penultimate Segment Endpointルータでもあります。このノードが末尾のセグメントをSRHからIPv6宛先アドレスにコピーし、Segments Leftを0に減らします。Software-Defined Networking (SDN)コントローラはR3以降の他のノードがSRHを検査しないことを知っており、R3に使用済みのSRHをパケットから削除するように、PSP-flavored SIDを使用して命令します。
Egress PEにとっての利点は明快です:
カプセル化解除の処理の一部として、Egress PEがパースして削除するパケットのバイト数が少なくなります。
もし上位レイヤのIPヘッダのルックアップが必要である場合(たとえばper-VRF VPN)、転送ASIC(Application-Specific Integrated Circuit)のルックアップエンジンにとって、ヘッダがよりメモリでアクセスしやすいようになります。
4.16.2. USP: SRHのUltimate Segment Pop
End、End.X、End.TのBehaviorのSRH処理が修正されます: S02からS04の命令が次のものに置き換えられます:
S02. If (Segments Left == 0) { S03.1. 後続のヘッダのNext Headerフィールドを更新して、 SRHのNext Header値にする S03.2. IPv6ヘッダのPayload Lengthを8*(Hdr Ext Len+1)だけ減らす S03.3. IPv6拡張ヘッダのチェインからSRHを削除する S03.4. パケットのネクストヘッダの処理に進む S04. }
USP Flavorの応用の一つとして、SRHを持ったパケットがSRv6を実装した smartNIC ("Smart Network Interface Cards") を搭載しているホスト上のアプリケーション宛になっているときです。USP Flavorはパケットをホストに転送する前に使用済みのSRHを拡張ヘッダのチェインから削除します。
4.16.3. USD: Ultimate Segment Decapsulation
End、End.X、End.TのBehaviorのUpper-Layerヘッダの処理が次のように修正されます:
End:
S01. If (Upper-Layer header type == 41(IPv6) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. 新しい宛先に転送するためパケットをEgress IPv6 FIBルックアップに渡す S04. } Else if (Upper-Layer header type == 4(IPv4) ) { S05. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S06. 新しい宛先に転送するためパケットをEgress IPv4 FIBルックアップに渡す S07. Else { S08. 4.1.1節に従って処理する S09. }
End.T:
S01. If (Upper-Layer header type == 41(IPv6) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. パケットの関連付けれられるFIBテーブルをTに設定する S04. 新しい宛先に転送するためパケットをEgress IPv6 FIBルックアップに渡す S05. } Else if (Upper-Layer header type == 4(IPv4) ) { S06. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S07. パケットの関連付けれられるFIBテーブルをTに設定する S08. 新しい宛先に転送するためパケットをEgress IPv4 FIBルックアップに渡す S09. Else { S10. 4.1.1節に従って処理する S11. }
End.X:
S01. If (Upper-Layer header type == 41(IPv6) || Upper-Layer header type == 4(IPv4) ) { S02. 外側のIPv6ヘッダを拡張ヘッダも含めてすべて削除する S03. 露わになったIPパケットをL3隣接性Jに転送する S04. } Else { S05. 4.1.1節に従って処理する S06. }
USD Flavorの応用の一つとして、カプセル化されているときのPルータにおけるTopology Independent Loop-Free Alternate (TI-LFA)のケースが挙げられます。USD Flavorによって修復パスリストの末尾のSR Segment Endpoint Nodeが、Local RepairのTI-LFA Pointで加えられたIPv6ヘッダのカプセル化を解除して内側のパケットを転送することができます。
5. SR Policy Headend Behavior
この節ではSRv6 Policy Headend [RFC8402]の一連のBehaviorについて記述します。
+-----------------+-----------------------------------------------+ | H.Encaps | SR Headend with Encapsulation in an SR Policy | | | SRポリシーにカプセル化されるSR Headend | +-----------------+-----------------------------------------------+ | H.Encaps.Red | H.Encaps with Reduced Encapsulation | | | Reduced Encapsulationを行うH.Encaps | +-----------------+-----------------------------------------------+ | H.Encaps.L2 | H.Encaps Applied to Received L2 Frames | | | 受信したL2フレームに適用するH.Encaps | +-----------------+-----------------------------------------------+ | H.Encaps.L2.Red | H.Encaps.Red Applied to Received L2 Frames | | | 受信したL2フレームに適用するH.Encaps.Red | +-----------------+-----------------------------------------------+
Table 2: SR Policy HeadendのBehavior
このリストは完全ではなく、将来の文書が追加のBehaviorを定義する可能性があります。
5.1. H.Encaps: SRポリシーにカプセル化されるSR Headend
ノードNが2つのパケット、P1=(A, B2)とP2=(A,B2)(B3, B2, B1; SL=1)を受信します。B2はローカルアドレスでもNのSIDでもありません。
ノードNにはIPv6アドレスTが(例えばループバックアドレスとして)設定されています。
Nは通過パケットであるP1とP2を、送信元アドレスをT、セグメントリストを<S1, S2, S3>としてSRv6 Policyに導きます。
H.Encapsのカプセル化Behaviorは次のように定義されます:
S01. IPv6ヘッダを自分自身のSRHとともにPushする S02. 外側のSAをT、外側のDAをセグメントリストの先頭のSIDに設定する S03. 外側のPayload Length、Traffic Class、Hop Limit、Flow Label フィールドを設定する S04. 外側のNext Headerの値を設定する S05. 内側のIPv6Hop LimitまたはIPv4 TTLを1減らす S06. S1へ転送するためのIPv6モジュールにパケットを渡す
注意:
H.Encaps Behaviorのあと、P1'とP2'はそれぞれこのようになります:
- (T, S1) (S3, S2, S1; SL=2) (A, B2)
- (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1)
受信されたパケットはカプセル化され、修正されません(RFC2473に記述されているようにIPv4 TTLとIPv6 Hop Limitがデクリメントされることを除く)。
H.Encaps Behaviorはいかなる種類のL3トラフィックについても有効です。このBehaviorは一般的にはL3VPNをIPv4とIPv6でデプロイするために使用されます。Local RepairのPointにおけるTI-LFA [SR-TI-LFA]のためにも使用することができます。
SRv6 Policyが一つのセグメントを含んでいるだけでフラグやタグやTLVを使用する必要がないとき、SRHのPushは省略することができます(MAY)。
5.2. H.Encaps.Red: Reduced Encapsulationを行うH.Encaps
H.Encaps.Red BehaviorはH.Encaps Behaviorを最適化したものです。
H.Encaps.RedはPushされたIPv6ヘッダのSRH中の先頭のSIDを除外することによってSRHの長さを減らします。先頭のSIDはPushされたIPv6ヘッダの宛先アドレスフィールドにだけ存在します。
H.Encaps.Red Behaviorのあと、P1'とP2'はそれぞれこのようになります:
(T, S1) (S3, S2; SL=2) (A, B2)
(T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1)
SRv6 Policyが一つのセグメントを含んでいるだけでフラグやタグやTLVを使用する必要がないとき、SRHのPushは省略することができます(MAY)。
5.3. H.Encaps.L2: 受信したL2フレームに適用するH.Encaps
H.Encaps.L2 Behaviorは受信したイーサネットフレーム [IEEE.802.3_2018] と、もしあれば付属するVLANヘッダをSRHのついたIPv6パケットにカプセル化します。イーサネットフレームは新しいIPv6パケットのペイロードになります。
SRHのNext Headerフィールドは143に設定されなければなりません(MUST)。
SRv6 Policyが一つのセグメントを含んでいるだけでフラグやタグやTLVを使用する必要がないとき、SRHのPushは省略することができます(MAY)。
このカプセル化を行うノードはカプセル化の際にイーサネットフレームのプリアンブルとフレームチェックサムシーケンス(FCS)を削除しなければなりません(MUST)。カプセル化を解除するノードはこのイーサネットフレームを送信する前にプリアンブルとFCSを必要に応じて再生成しなければなりません(MSUT)。
5.4. H.Encaps.L2.Red: 受信したL2フレームに適用するH.Encaps.Red
H.Encaps.L2.Red BehaviorはH.Encaps.L2 Behaviorを最適化したものです。
H.Encaps.L2.RedはPushされたIPv6ヘッダのSRH中の先頭のSIDを除外することによってSRHの長さを減らします。先頭のSIDはPushされたIPv6ヘッダの宛先アドレスフィールドにだけ存在します。
SRv6 Policyが一つのセグメントを含んでいるだけでフラグやタグやTLVを使用する必要がないとき、SRHのPushは省略することができます(MAY)。
6. カウンター
この文書をサポートするノードは、ローカルSIDエントリーごとに、そのSIDエントリーにマッチして処理に成功した(例えばICMP Error Messagesを生成したり破棄されるパケットは数えない)トラフィックのトラフィックカウンタのペア(パケット数とバイト数)を実装するべきです(SHOULD)。これらのカウンタをMIBやNETCONF/YANGやその他のデータ構造で取得する方法についてはこの文書の範囲外とします。
7. フローベースのハッシュ計算
ある集合内でフローベースの選択を実行することが必要であるとき、外側のIPv6パケットのIPv6送信元アドレス、IPv6宛先アドレス、IPv6 Flow Labelがフローベースのハッシュに含まれなければなりません(MUST)。
これは次のシナリオのいずれにおいても発生します:
FIBルックアップが実行されて、更新された宛先アドレスに対して複数のECMPパスが存在する
End.X、End.DX4、End.DX6が隣接性の配列に紐付けられる
複数のSIDリストを持つパスが選択されたSR Policyに従ってパケットが導かれる
加えて、SRv6ドメインの中継ルータはECMPフローベースのハッシュ[RFC6437]において外側のフローラベルを含めます。
8. コントロールプレーン
SDNの環境下において、コントローラが明示的にSIDをプロビジョニングしたりサービスディスカバリ機能の一部としてSIDを発見することが期待されます。コントローラの上位にあるアプリケーションは、これにより必要なSIDを発見し、それらを組み合わせて分散されたネットワークプログラムを作成します。
「SRv6 Network Programming」のコンセプトはアプリケーションが、いかなる複雑なプログラムでもネットワークを通じて分散された個別の機能の集合にエンコードできる能力を指しています。これらの機能はアンダーレイのSLA、オーバーレイやテナント、VMやコンテナ内にある複雑なアプリケーションに関連したものです。
SDNコントロールプレーンには必要ありませんが、この節の残りではコントロールプレーンのプロトコルがSRv6と連携しうるのかについて、その概要をハイレベルで紹介します。これらの仕様についてはこの文書の範囲外です。
8.1. IGP
End、End.T、End.XのSIDはトポロジーのBehaviorを表現しています。そのためIGPにおいてPSP、USP、USDのFlavorとともに伝達されることが期待されています。このIGPはそれぞれの種類のSRv6動作についてノードのMaximum SID Depth (MSD)のCapabilityを広告するべきです。特にSR Source(H.Encapsなど)、中間エンドポイント(ENdやEnd.Xなど)、最終エンドポイント(End.DX4やEnd.DT6など)のBehaviorです。これらのCapabilityはSR Policy計算においてSR Sourceノード(またはコントローラ)によって考慮されます。
IGPにSIDが存在することは、これらのSIDで表現されるアドレスに対するいかなるルーティングのセマンティクスも含みません。IPv6アドレスへのルーティングの到達性はSIDに関係のないLocatorを含んだIGPプレフィックスの到達性情報によってのみ決定されます。IGPにおけるSID広告によって、いかなる方法においてもルーティングが決定されたり影響を受けたりすることはありません。
これらのSIDは、IGPがTI-LFA [SR-TI-LFA]ベースのFast Reroute (FRR)ソリューションを構築するためや、SR Policyを構築するためにIGPトポロジーデータベースに頼っているTEプロセスのために、重要なトポロジーのBehaviorを提供します。
8.2. BGP-LS
BGP-LSはトポロジー発見のための機能を提供します。これにはノードのSRv6 CapabilityやLocatorやローカルでインスタンス化されたSIDを含みます。これによってコントローラやアプリケーションは、SRv6 SIDを使ったSR Policyの計算に使用することができるインタードメインなトポロジーを構築することができます。
8.3. BGP IP/VPN/EVPN
End.DX4、End.DX6、End.DT4、End.DT6、End.DT46、End.DX2、End.DX2V、End.DT2U、End.DT2MのSIDはBGPで伝達することができます。
いくつかのシナリオにおいて、VPN経路を広告するEgress PEは、Ingress PEやネットワーク内の他のルータからのSIDに紐付けられた特定のBehaviorを抽象化したいと望むでしょう。このようなケースでは、表6に定義されているOpaque SRv6 Endpoint Behaviorコードポイントを使用してSIDを広告することができます。このようなコントロールプレーンの伝達機構はこの文書の範囲外です。
8.4. まとめ
次の表でどのSID Behaviorがどのコントロールプレーンのプロトコルで伝達可能であるかをまとめます。
+=======================+=====+========+=================+ | | IGP | BGP-LS | BGP IP/VPN/EVPN | +=======================+=====+========+=================+ | End (PSP, USP, USD) | X | X | | +-----------------------+-----+--------+-----------------+ | End.X (PSP, USP, USD) | X | X | | +-----------------------+-----+--------+-----------------+ | End.T (PSP, USP, USD) | X | X | | +-----------------------+-----+--------+-----------------+ | End.DX6 | X | X | X | +-----------------------+-----+--------+-----------------+ | End.DX4 | X | X | X | +-----------------------+-----+--------+-----------------+ | End.DT6 | X | X | X | +-----------------------+-----+--------+-----------------+ | End.DT4 | X | X | X | +-----------------------+-----+--------+-----------------+ | End.DT46 | X | X | X | +-----------------------+-----+--------+-----------------+ | End.DX2 | | X | X | +-----------------------+-----+--------+-----------------+ | End.DX2V | | X | X | +-----------------------+-----+--------+-----------------+ | End.DT2U | | X | X | +-----------------------+-----+--------+-----------------+ | End.DT2M | | X | X | +-----------------------+-----+--------+-----------------+ | End.B6.Encaps | | X | | +-----------------------+-----+--------+-----------------+ | End.B6.Encaps.Red | | X | | +-----------------------+-----+--------+-----------------+ | End.B6.BM | | X | | +-----------------------+-----+--------+-----------------+
表3: ローカルでインスタンス化されたSRv6 SIDの伝達
次の表でどのSR Policy Headend Capabilityがどのコントロールプレーンのプロトコルで伝達可能であるかをまとめます。
+=================+=====+========+=================+ | | IGP | BGP-LS | BGP IP/VPN/EVPN | +=================+=====+========+=================+ | H.Encaps | X | X | | +-----------------+-----+--------+-----------------+ | H.Encaps.Red | X | X | | +-----------------+-----+--------+-----------------+ | H.Encaps.L2 | | X | | +-----------------+-----+--------+-----------------+ | H.Encaps.L2.Red | | X | | +-----------------+-----+--------+-----------------+
表4: SRv6 Policy Headend Behaviorの伝達
前の表では一般的なCapabilityについて記載しています。特定のインスタンス化されたSR Policyについて記載したものではありません。
例えば、H.Encaps BehaviorのBGP-LS広告はノードNがH.Encaps Behaviorを実行するCapabilityを記述しています。特に、Nによって重大なパフォーマンスの劣化を伴わずにどれだけのSIDがPush可能であるかについて記述しているでしょう。
忘備として、SR PolicyはBinding SID [RFC8402]に常に割り当てられています。Binding SIDも表3に示されている通り、BGP-LSによって広告されます。そのため表4はH.Encapsに関連する一般的なCapabilityについてのみ注目しています。
9. セキュリティに関する考察
Segment Routingについてのセキュリティの考察はRFC8402で議論されています。RFC8754の5節ではSR Deployment ModelとSR Domainをセキュアにする要件について述べています。RFC8754のセキュリティに関する考察では、この文書で紹介されたBehaviorにも適用できる攻撃ベクタやその低減の仕組みのような話題をカバーしています。さらに、SR Domainの信頼性を確立するために要求されるセキュリティ機構についても記載しています。このようなwell-definedな信頼性境界を持つことは、外部トラフィックがSRv6ベースのサービスにアクセスしたり不当に利用したりすることを防ぐ一方で、内部トラフィックに対してSRv6ベースのサービスを運用するために必要不可欠です。SRv6 SID割り振りとネットワーク基盤アドレスの用途のためのIPv6アドレス割り振りを注意深く厳格に行うことで、(RFC8754の5.1節に説明されているように)エンドユーザやシステムに対してIPv6アドレスを割り振ることとは異なり、SRv6 Domainの完全性とセキュリティを維持するために必要な内部アドレス空間と外部アドレス空間の明確な区別を提供することができます。加えてRFC8754では、SR DomainのSR Segment Endpoint Nodesがパケットに適用されたSRHが認証された関係者によって選択されていることを検証し、セグメントリストがセグメントリスト中のセグメントの数を除いて生成後に変更されていないことを確実にすることを可能にするHashed Message Authentication Code (HMAC) TLVを定義しています。これがローカルの設定で有効化されたとき、RFC8754の2.1.2.1セグに定義されているように、SRH処理の最初にHMACの処理が実行されます。
この文書ではネットワーク中のSRv6 Capableなノードで実装できるSRv6 EndpointのBehaviorとSR Policy HeadendのBehaviorを導入しました。SR Policy Headendの定義は(4.1.1節で定めたように)使用される特定のBehaviorやいかなるローカルの設定とも一貫しているべきです。そのためこの文書ではセキュリティについての新しい考察は導入しません。
この文書で定められているSIDのBehaviorは、RFC8754に定められているSIDのBehaviorと同様に、HMAC TLVの処理と、FlagとTagとSegment Listのフィールドについての可変属性を有しています。
10. IANAに関する考察
10.1. Ethernet Next Header Type
IANAでは「Ethernet」(値143)が「Assigned Internet Protocol Numbers」レジストリで割り振られています。IPv6ヘッダや他の拡張ヘッダのNext Headerフィールド中の値143は、ペイロードがイーサネットフレーム[IEEE.802.3_2018]であることを示しています。
10.2. SRv6 Endpoint Behaviorsレジストリ
IANAは新たに「Segment Routing」と呼ばれるトップレベルのレジストリ(https://www.iana.org/assignments/segment-routing/ を参照)を作成しました。このレジストリはSegment Rougingのすべてのサブレジストリに対するトップレベルのレジストリとして扱われます。
加えて、IANAはトップレベルの「Segment Rouing」レジストリの下に、新たに「SRv6 Endpoint Behaviors」サブレジストリを作成しました。このサブレジストリはSRv6 Endpoint Behaviorのために16ビットの識別子を管理します。このレジストリはこれらのBehaviorを参照する必要があるコントロールプレーンのプロトコルの一貫性を提供するために設立されます。これらの値はSID中のFunctionビットにエンコードされるわけではありません。
10.2.1. 登録プロトコル
レジストリの範囲は0から65535 (0x0000-0xFFFF)です。下記の表では割り振り範囲と登録ポリシー[RFC8126]がそれぞれ含まれています:
+=============+===============+=========================+===========+ | Range | Range (Hex) | Registration | Note | | | | Procedures | | +=============+===============+=========================+===========+ | 0 | 0x0000 | Reserved | Not to be | | | | | allocated | +-------------+---------------+-------------------------+-----------+ | 1-32767 | 0x0001-0x7FFF | First Come | | | | | First Served | | +-------------+---------------+-------------------------+-----------+ | 32768-34815 | 0x8000-0x87FF | Private Use | | +-------------+---------------+-------------------------+-----------+ | 34816-65534 | 0x8800-0xFFFE | Reserved | | +-------------+---------------+-------------------------+-----------+ | 65535 | 0xFFFF | Reserved | Opaque | +-------------+---------------+-------------------------+-----------+
表5: 登録手順
10.2.2. 初期登録
このサブレジストリの初期登録は次のとおりです:
+=============+===============+=========================+===========+ | Value | Hex | Endpoint Behavior | Reference | +=============+===============+=========================+===========+ | 0 | 0x0000 | Reserved | | +-------------+---------------+-------------------------+-----------+ | 1 | 0x0001 | End | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 2 | 0x0002 | End with PSP | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 3 | 0x0003 | End with USP | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 4 | 0x0004 | End with PSP & USP | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 5 | 0x0005 | End.X | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 6 | 0x0006 | End.X with PSP | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 7 | 0x0007 | End.X with USP | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 8 | 0x0008 | End.X with PSP & USP | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 9 | 0x0009 | End.T | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 10 | 0x000A | End.T with PSP | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 11 | 0x000B | End.T with USP | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 12 | 0x000C | End.T with PSP & USP | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 13 | 0x000D | Unassigned | | +-------------+---------------+-------------------------+-----------+ | 14 | 0x000E | End.B6.Encaps | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 15 | 0x000F | End.BM | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 16 | 0x0010 | End.DX6 | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 17 | 0x0011 | End.DX4 | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 18 | 0x0012 | End.DT6 | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 19 | 0x0013 | End.DT4 | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 20 | 0x0014 | End.DT46 | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 21 | 0x0015 | End.DX2 | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 22 | 0x0016 | End.DX2V | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 23 | 0x0017 | End.DT2U | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 24 | 0x0018 | End.DT2M | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 25 | 0x0019 | Reserved | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 26 | 0x001A | Unassigned | | +-------------+---------------+-------------------------+-----------+ | 27 | 0x001B | End.B6.Encaps.Red | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 28 | 0x001C | End with USD | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 29 | 0x001D | End with PSP & USD | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 30 | 0x001E | End with USP & USD | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 31 | 0x001F | End with PSP, USP & | RFC 8986 | | | | USD | | +-------------+---------------+-------------------------+-----------+ | 32 | 0x0020 | End.X with USD | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 33 | 0x0021 | End.X with PSP & USD | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 34 | 0x0022 | End.X with USP & USD | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 35 | 0x0023 | End.X with PSP, USP | RFC 8986 | | | | & USD | | +-------------+---------------+-------------------------+-----------+ | 36 | 0x0024 | End.T with USD | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 37 | 0x0025 | End.T with PSP & USD | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 38 | 0x0026 | End.T with USP & USD | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 39 | 0x0027 | End.T with PSP, USP | RFC 8986 | | | | & USD | | +-------------+---------------+-------------------------+-----------+ | 40-32766 | 0x0028-0x7FFE | Unassigned | | +-------------+---------------+-------------------------+-----------+ | 32767 | 0x7FFF | The SID defined in | RFC 8986, | | | | RFC 8754 | RFC 8754 | +-------------+---------------+-------------------------+-----------+ | 32768-34815 | 0x8000-0x87FF | Reserved for Private | RFC 8986 | | | | Use | | +-------------+---------------+-------------------------+-----------+ | 34816-65534 | 0x8800-0xFFFE | Reserved | RFC 8986 | +-------------+---------------+-------------------------+-----------+ | 65535 | 0xFFFF | Opaque | RFC 8986 | +-------------+---------------+-------------------------+-----------+
表6: 初期登録
11. 参考文献
省略
*1:Last Entry > max_LE) or (Segments Left > Last Entry+1