Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 9602 Cisco
Category: Informational October 2024
ISSN: 2070-1721
Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. This document allocates and makes a dedicated prefix available for SRv6 SIDs.
IPv6を介したセグメントルーティング（SRV6）は、IPv6を基礎となるデータプレーンとして使用します。したがって、SRV6が使用するセグメント識別子（SIDS）は、IPv6アドレスに似ており、状況によってはわずかに異なる動作を示しながら、それらのように動作する可能性があります。このドキュメントでは、SRV6 SIDSの特性を調査し、SRV6 SIDとIPv6アドレス指定アーキテクチャとの関係に焦点を当てています。このドキュメントは、SRV6 SIDSに専用のプレフィックスを割り当て、使用できるようにします。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9602.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9602で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. SRv6 SIDs and the IPv6 Addressing Architecture
4. Special Considerations for Compressed SIDs
5. Allocation of a Prefix for SIDs
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Author's Address
Segment Routing over IPv6 (SRv6) [RFC8754] uses IPv6 as the underlying data plane. In SRv6, SR source nodes initiate packets with a Segment Identifier (SID) in the Destination Address of the IPv6 header, and SR segment endpoint nodes process a local segment present in the Destination Address of an IPv6 header. Thus, SIDs in SRv6 can, and do, appear in the Destination Address of IPv6 datagrams by design. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture [RFC4291]. This document allocates and makes a dedicated prefix available for SRv6 SIDs.
IPv6（SRV6）[RFC8754]のセグメントルーティングは、IPv6を基礎となるデータプレーンとして使用します。SRV6では、SRソースノードは、IPv6ヘッダーの宛先アドレスにセグメント識別子（SID）でパケットを開始し、SRセグメントエンドポイントノードはIPv6ヘッダーの宛先アドレスに存在するローカルセグメントを処理します。したがって、SRV6のSIDSは、設計によりIPv6データグラムの宛先アドレスに表示される可能性があります。このドキュメントでは、SRV6 SIDSの特性を調査し、SRV6 SIDSとIPv6アドレス指定アーキテクチャ[RFC4291]との関係に焦点を当てています。このドキュメントは、SRV6 SIDSに専用のプレフィックスを割り当て、使用できるようにします。
The following terms are used as defined in [RFC8402].
次の用語は、[RFC8402]で定義されているように使用されます。
* Segment Routing (SR)
* セグメントルーティング（SR）
* SR Domain
* SRドメイン
* Segment
* セグメント
* Segment Identifier (SID)
* セグメント識別子（SID）
* SRv6
* SRV6
* SRv6 SID
* SRV6 SID
The following terms are used as defined in [RFC8754].
次の用語は、[RFC8754]で定義されているように使用されます。
* Segment Routing Header (SRH)
* セグメントルーティングヘッダー（SRH）
* SR Source Node
* SRソースノード
* Transit Node
* トランジットノード
* SR Segment Endpoint Node
* SRセグメントエンドポイントノード
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
[RFC8754] defines the Segment List of the SRH as a contiguous array of 128-bit IPv6 addresses; further, it states that each of the elements in this list are SIDs. But all of these elements are not necessarily made equal. Some of these elements may represent a local interface as described in Section 4.3 of [RFC8754] as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID". It follows that not all the SIDs that appear in the SRH are SRv6 SIDs as defined by [RFC8402].
[RFC8754]は、SRHのセグメントリストを128ビットIPv6アドレスの連続配列として定義します。さらに、このリストの各要素はSIDSであると述べています。しかし、これらの要素はすべて、必ずしも等しくなるとは限りません。これらの要素の一部は、[RFC8754]のセクション4.3で説明されているように、「SRV6 SIDとして局所的にインスタンス化されていないローカルインターフェイスを表すFIBエントリ」としてローカルインターフェイスを表す場合があります。SRHに表示されるすべてのSIDが[RFC8402]で定義されているようにSRV6 SIDSであるわけではありません。
As stated above, the non-SRv6-SID elements that appear in the SRH SID list are simply IPv6 addresses assigned to local interfaces, and they need to conform to [RFC4291]. So, the following discussions are applicable solely to SRv6 SIDs that are not assigned to local interfaces.
上記のように、SRH SIDリストに表示される非SRV6-SID要素は、ローカルインターフェイスに割り当てられたIPv6アドレスであり、[RFC4291]に準拠する必要があります。したがって、次の議論は、ローカルインターフェイスに割り当てられていないSRV6 SIDにのみ適用されます。
One of the key questions to address is how these SRv6 SIDs appearing as IPv6 Destination Addresses are perceived and treated by "transit nodes" (that are not required to be capable of processing a Segment or the Segment Routing Header).
対処すべき重要な質問の1つは、IPv6の宛先アドレスとして表示されるこれらのSRV6 SIDが、「トランジットノード」（セグメントまたはセグメントルーティングヘッダーの処理が必要である必要はない）によってどのように知覚および扱われるかです。
Section 3.1 of [RFC8986] describes the format of an SRv6 SID as being composed of three parts, LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID followed by F bits of function (FUNCT) and A bits of arguments (ARG). If L+F+A < 128, the ARG is followed by enough zero bits to fill the 128-bit SID. Such an SRv6 SID is assigned to a node within a prefix defined as a Locator of length L. When an SRv6 SID occurs in the IPv6 Destination Address of an IPv6 header, only the longest matching prefix corresponding to the Locator [BCP198] is used by the transit node to forward the packet to the node identified by the Locator.
[RFC8986]のセクション3.1は、SRV6 SIDの形式を3つの部分で構成されていると説明しています。Loc：funct：arg、ここで、ロケーター（loc）がsidの最も重要なビットでエンコードされ、その後の機能のビットが続きます（funct）および一連の議論（arg）。L+F+A <128の場合、ARGの後に128ビットSIDを埋めるのに十分なゼロビットが続きます。このようなSRV6 SIDは、長さLのロケーターとして定義されたプレフィックス内のノードに割り当てられます。SRV6SIDがIPv6ヘッダーのIPv6宛先アドレスで発生すると、ロケーター[BCP198]に対応する最長の一致するプレフィックスのみが使用されます。トランジットノードは、ロケーターによって識別されたノードにパケットを転送します。
It is clear that this format for SRv6 SIDs is not compliant with the requirements set forth in [RFC4291] for IPv6 addresses, but it is also clear that SRv6 SIDs are not intended for assignment onto interfaces on end hosts. They look and act like other mechanisms that use IPv6 addresses with different formats, such as those described in "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] and "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)" [RFC7343].
SRV6 SIDSのこの形式は、IPv6アドレスの[RFC4291]に記載されている要件に準拠していないことは明らかですが、SRV6 SIDSがエンドホストのインターフェイスへの割り当てを意図していないことも明らかです。彼らは、「IPv4/IPv6翻訳者のIPv6アドレス指定」[RFC6052]や「オーバーレイルーティング可能な暗号化ハッシュ識別子バージョンバージョン2（orchidv2）」の「IPv4/IPv6翻訳者のアドレス指定」[RFC6052] [RFC6052]に記載されているような、さまざまな形式でIPv6アドレスを使用する他のメカニズムのように見えます。RFC7343]。
While looking at the transit nodes, it becomes apparent that these addresses are used purely for forwarding and not for packet delivery to end hosts. Hence, the relevant specification to apply here is [BCP198], which requires implementations to support the use of variable-length prefixes in forwarding while explicitly decoupling IPv6 routing and forwarding from the IPv6 address/prefix semantics described in [RFC4291]. Please note that [BCP198] does not override the rules in [RFC4291]: it merely limits where their impact is observed.
トランジットノードを見ている間、これらのアドレスは純粋に転送に使用され、ホストを終了するためのパケット配信ではなく使用されることが明らかになります。したがって、ここで適用するための関連する仕様は[BCP198]です。これは、[RFC4291]で説明されているIPv6アドレス/プレフィックスセマンティクスからのIPv6ルーティングと転送を明示的に分離しながら、転送に変数長のプレフィックスの使用をサポートするための実装が必要です。[BCP198]は[RFC4291]のルールを無効にしないことに注意してください。それは、その影響が観察される場所を制限するだけです。
Furthermore, in the SRv6 specifications, all SIDs assigned within a given Locator prefix are located inside the node identified by Locator. Therefore, there does not appear to be a conflict with Section 2.6.1 of [RFC4291] since subnet-router anycast addresses are neither required nor useful within a node.
さらに、SRV6仕様では、特定のロケータープレフィックス内に割り当てられたすべてのSIDは、ロケーターによって識別されるノード内にあります。したがって、サブネットルーターのaycastアドレスはノード内では必要でも有用でもないため、[RFC4291]のセクション2.6.1との競合はないようです。
[CSID] introduces an encoding for Compressed-SIDs (C-SIDs), and describes how to use a single entry in the Segment List as a container for multiple SIDs. A node taking part in this mechanism accomplishes this by using the ARG part [RFC8986] of the Destination Address of the IPv6 header to derive a new Destination Address. That is, the Destination Address field of the packet changes at a segment endpoint in a way similar to how the address changes as the result of processing a segment in the SRH.
[CSID]は、圧縮されたSID（C-SIDS）のエンコーディングを導入し、セグメントリストの単一のエントリを複数のSIDのコンテナとして使用する方法について説明します。このメカニズムに参加しているノードは、IPv6ヘッダーの宛先アドレスのArg部分[RFC8986]を使用して新しい宛先アドレスを導出することにより、これを達成します。つまり、パケットの宛先アドレスフィールドは、SRHのセグメントを処理した結果としてアドレスがどのように変化するかと同様に、セグメントエンドポイントで変更されます。
One key thing to note here is that the Locator Block at the beginning of the address does not get modified by the operations needed for supporting C-SIDs. As we have established that the SRv6 SIDs are being treated simply as routing prefixes on transit nodes within the SR Domain, this does not constitute a modification to the IPv6 data plane on such transit nodes: any changes are restricted to SR-aware nodes.
ここで注意すべき重要なことの1つは、アドレスの先頭にあるロケーターブロックが、C-SIDをサポートするために必要な操作によって変更されないことです。SRV6 SIDSがSRドメイン内のトランジットノードのルーティングプレフィックスとして単純に扱われていることを確認したため、これはそのようなトランジットノードのIPv6データプレーンの変更を構成するものではありません。変更はSR-Awareノードに制限されています。
All of the SRv6-related specifications discussed above are intended to be applicable to a contained SR Domain or between collaborating SR Domains. Nodes either inside or outside the SR Domains that are not SR-aware will not perform any special behavior for SRv6 SIDs and will treat them solely as IPv6 routing prefixes.
上記のすべてのSRV6関連の仕様は、含まれているSRドメインに適用されることを目的としています。SR-AwareではないSRドメインの内側または外側のノードは、SRV6 SIDSの特別な動作を実行せず、IPv6ルーティングのプレフィックスとしてのみ扱います。
As an added factor of security, it is desirable to allocate some address space that explicitly signals that the addresses within that space cannot be expected to comply with [RFC4291]. As described in Section 3, there is precedent for mechanisms that use IPv6 addresses in a manner different from that specified in [RFC4291]. This would be useful in identifying and potentially filtering packets at the edges of the SR Domains to make it simpler for the SR Domain to fail closed.
セキュリティの追加要因として、そのスペース内のアドレスが[RFC4291]に準拠することが期待できないことを明示的に信号するいくつかのアドレス空間を割り当てることが望ましい。セクション3で説明されているように、[RFC4291]で指定されているものとは異なる方法でIPv6アドレスを使用するメカニズムの先例があります。これは、SRドメインのエッジでパケットを識別し、潜在的にフィルタリングして、SRドメインが閉じたままになるようにするのに役立ちます。
At the time of writing, global DNS [RFC9499] SHOULD NOT reference addresses assigned from this block. Further specifications are needed to describe the conventions and guidelines for the use of this newly allocated address block. The SRv6 operational community, which is the first intended user of this block, is requested to come up with such conventions and guidelines in line with their requirements.
執筆時点では、グローバルDNS [RFC9499]は、このブロックから割り当てられたアドレスを参照するべきではありません。この新しく割り当てられたアドレスブロックを使用するための規則とガイドラインを説明するために、さらなる仕様が必要です。このブロックの最初の意図されたユーザーであるSRV6 Operational Communityは、要件に沿ってそのような慣習とガイドラインを考案するように要求されています。
IANA has assigned the following /16 address block for the purposes described in Section 5 and recorded the allocation in the "IANA IPv6 Special-Purpose Address Registry" [SPECIAL] as follows:
IANAは、セクション5で説明されている目的のために次の /16アドレスブロックを割り当て、「IANA IPv6 Special-Purposeアドレスレジストリ」[Special]の割り当てを次のように記録しました。
Address Block:
アドレスブロック：
5f00::/16
5F00 ::/16
Name:
名前：
Segment Routing (SRv6) SIDs
セグメントルーティング（SRV6）SIDS
RFC:
RFC:
RFC 9602
RFC 9602
Allocation Date:
割り当て日：
2024-04
2024-04
Termination Date:
終了日：
N/A
n/a
Source:
ソース：
True
真実
Destination:
行き先：
True
真実
Forwardable:
フォローダブル：
True
真実
Globally Reachable:
グローバルに到達可能：
False
間違い
Reserved-by-Protocol:
プロトコルごとに予約済み：
False
間違い
The security considerations for the use of Segment Routing [RFC8402], SRv6 [RFC8754], and SRv6 network programming [RFC8986] apply to the use of these addresses. The use of IPv6 tunneling mechanisms (including SRv6) also brings up additional concerns such as those described in [RFC6169]. The usage of the prefix allocated by this document improves security by making it simpler to filter traffic at the edge of the SR Domains.
セグメントルーティング[RFC8402]、SRV6 [RFC8754]、およびSRV6ネットワークプログラミング[RFC8986]の使用に関するセキュリティ上の考慮事項は、これらのアドレスの使用に適用されます。IPv6トンネルメカニズム（SRV6を含む）の使用は、[RFC6169]に記載されているような追加の懸念をもたらします。このドキュメントによって割り当てられたプレフィックスの使用は、SRドメインの端でトラフィックをフィルタリングするように簡単にすることにより、セキュリティを改善します。
In case the deployments do not use this allocated prefix, additional care needs to be exercised at network ingress and egress points so that SRv6 packets do not leak out of SR Domains and do not accidentally enter SR-unaware Domains. Similarly, as stated in Section 5.1 of [RFC8754], the SR Domain needs to be configured to filter out packets entering that use the selected prefix.
展開がこの割り当てられたプレフィックスを使用しない場合、SRV6パケットがSRドメインから漏れなくなり、誤ってSR-Unawareドメインに入らないように、ネットワークイングレスポイントと出力ポイントで追加のケアを行使する必要があります。同様に、[RFC8754]のセクション5.1で述べたように、選択したプレフィックスを使用するパケットをフィルタリングするようにSRドメインを構成する必要があります。
[BCP198] Best Current Practice 198,
<https://www.rfc-editor.org/info/bcp198>.
At the time of writing, this BCP comprises the following:
Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015,
<https://www.rfc-editor.org/info/rfc7608>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[CSID] Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, "Compressed SRv6 Segment List Encoding", Work in
Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
compression-18, 22 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-srh-compression-18>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169,
DOI 10.17487/RFC6169, April 2011,
<https://www.rfc-editor.org/info/rfc6169>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
2014, <https://www.rfc-editor.org/info/rfc7343>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[SPECIAL] IANA, "IANA IPv6 Special-Purpose Address Registry",
<https://www.iana.org/assignments/iana-ipv6-special-
registry>.
The author would like to extend a special note of thanks to Brian Carpenter and Erik Kline for their precisely summarized thoughts on this topic that provided the seed of this document. The author would also like to thank Andrew Alston, Fred Baker, Ron Bonica, Nick Buraglio, Bruno Decraene, Dhruv Dhody, Darren Dukes, Linda Dunbar, Reese Enghardt, Adrian Farrel, Clarence Filsfils, Jim Guichard, Joel Halpern, Ted Hardie, Bob Hinden, Murray Kucherawy, Cheng Li, Acee Lindem, Jen Linkova, Gyan Mishra, Yingzhen Qu, Robert Raszuk, Alvaro Retana, Michael Richardson, John Scudder, Petr Spacek, Mark Smith, Dirk Steinberg, Ole Troan, Eduard Vasilenko, Éric Vyncke, Rob Wilton, Jingrong Xie, Chongfeng Xie, and Juan Carlos Zuniga for their ideas and comments to improve this document.
著者は、このドキュメントの種を提供するこのトピックに関する正確に要約された考えについて、ブライアン・カーペンターとエリック・クラインに感謝の特別なメモを拡張したいと思います。著者はまた、アンドリュー・アルストン、フレッド・ベイカー、フレッド・ベイカー、ロン・ボニカ、ニック・ブラグリオ、ニック・ブラグリオ、ブルーノ・デクレエン、ドルフ・ドディ、ドゥルフ・ドディ、ダレン・デュークス、ダレン・デューク、リンダ・ダンバル、リース・エンガルト、リース・エンガルト、エイドリアン・ファレル、クラレンス・フィルズ、ジミー・グイチャード、ジム・グイチャード、ジム・グイチャード、ジム・ギチャード、ボブ・ボブ・ボブ・ボブ・ボブ、ヒンデン、マレー・クチェラウィ、チェン・リー、エイシー・リンデム、ジェン・リンカバ、ギャン・ミシュラ、インズヘン・ク、ロバート・ラシュク、アルバロ・レターナ、マイケル・リチャードソン、ジョン・スカダー、ペトル・スペースこの文書を改善するためのアイデアとコメントについて、ロブ・ウィルトン、ジングロン・シー、チョンフェン・Xie、およびフアン・カルロス・ズニガ。
Suresh Krishnan
Cisco
Email: suresh.krishnan@gmail.com