Internet Engineering Task Force (IETF) H. Wang
Request for Comments: 9723 J. Dong
Category: Informational Huawei Technologies
ISSN: 2070-1721 K. Talaulikar
Cisco Systems
T. Han
Huawei Technologies
R. Chen
ZTE Corporation
May 2025
This document describes a mechanism to advertise IPv6 prefixes in BGP that are associated with Color Extended Communities to establish end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called "Colored Prefix Routing" (CPR). In SRv6 networks, the Colored Prefixes are the SRv6 locators associated with different intents. SRv6 services (e.g., SRv6 VPN services) with a specific intent could be assigned with SRv6 Segment Identifiers (SIDs) under the corresponding SRv6 locators, which are advertised as Colored Prefixes.
このドキュメントでは、IPv6（SRV6）サービスを介したセグメントルーティングのエンドツーエンドの意図対応パスを確立するために、色の拡張コミュニティに関連付けられているBGPでIPv6プレフィックスを宣伝するメカニズムについて説明します。このようなIPv6プレフィックスは「色付きのプレフィックス」と呼ばれ、このメカニズムは「色付きプレフィックスルーティング」（CPR）と呼ばれます。SRV6ネットワークでは、色付きのプレフィックスは、異なる意図に関連付けられたSRV6ロケーターです。特定の意図を持つSRV6サービス（例：SRV6 VPNサービス）は、対応するSRV6ロケーターの下にあるSRV6セグメント識別子（SIDS）で割り当てることができます。
This operational methodology allows the SRv6 service traffic to be steered into end-to-end intent-aware paths based on the longest prefix matching of SRv6 Service SIDs to the Colored Prefixes. The existing IPv6 Address Family and Color Extended Community are reused to advertise IPv6 Colored Prefixes without new BGP extensions; thus, this mechanism is easy to interoperate and can be deployed incrementally in multi-Autonomous System (AS) networks that belong to the same trusted domain.
この運用方法により、SRV6サービストラフィックは、SRV6サービスSIDの色付きプレフィックスへの最長の接頭辞マッチングに基づいて、エンドツーエンドの意図対応パスに操縦できます。既存のIPv6アドレスファミリと色の拡張コミュニティは、新しいBGP拡張機能なしでIPv6色のプレフィックスを宣伝するために再利用されます。したがって、このメカニズムは相互操作が容易であり、同じ信頼できるドメインに属する多自律システム（AS）ネットワークに段階的に展開できます。
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/rfc9723.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9723で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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. BGP CPR
2.1. Colored Prefix Allocation
2.2. Colored Prefix Advertisement
2.3. CPR to Intra-Domain Path Resolution
2.4. SRv6 Service Route Advertisement
2.5. SRv6 Service Steering
3. Encapsulation and Forwarding Process
3.1. CPR over SRv6 Intra-Domain Paths
3.2. CPR over MPLS Intra-Domain Paths
4. Operational Considerations
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
With the trend of using one common network to carry multiple types of services, each service type can have different requirements for the network. Such requirements are usually considered the "intent" of the service or customer, which is represented as an abstract notion called "color".
1つの一般的なネットワークを使用して複数の種類のサービスを運ぶ傾向により、各サービスタイプにはネットワークに異なる要件があります。このような要件は通常、「色」と呼ばれる抽象的な概念として表されるサービスまたは顧客の「意図」と見なされます。
In network scenarios where the services are delivered across multiple Autonomous Systems (ASes), there is a need to provide the services with different end-to-end paths to meet the intent. [INTENTAWARE] describes the problem statements and requirements for inter-domain intent-aware routing.
複数の自律システム（ASE）でサービスが提供されるネットワークシナリオでは、意図を満たすためにさまざまなエンドツーエンドパスをサービスに提供する必要があります。[IntentAware]は、ドメイン間の意図を認識しているルーティングの問題の声明と要件について説明しています。
The inter-domain path can be established using either Multi-Protocol Label Switching (MPLS) or the IP data plane. In MPLS-based networks, the usual inter-domain approach is to establish an end-to-end Label Switched Path (LSP) based on the mechanism defined in [RFC8277] (which is usually referred to as BGP-LU (BGP Labeled Unicast)). Each domain's ingress border node needs to perform label swapping for the end-to-end LSP, and impose the label stack that is used for the LSP within its own domain.
ドメイン間パスは、マルチプロトコルラベルスイッチング（MPLS）またはIPデータプレーンのいずれかを使用して確立できます。MPLSベースのネットワークでは、通常のドメイン間アプローチは、[RFC8277]（通常はBGP-LU（BGPラベルユニキャストと呼ばれる）と呼ばれるメカニズムに基づいて、エンドツーエンドラベルスイッチドパス（LSP）を確立することです。各ドメインのイングレスボーダーノードは、エンドツーエンドのLSPのラベルスワッピングを実行し、独自のドメイン内のLSPに使用されるラベルスタックを課す必要があります。
In IP-based networks, the IP reachability information can be advertised to network nodes in different domains using BGP, so that all the domain border nodes can obtain the routes to the IP prefixes of the destination nodes in other domains. With the introduction of SRv6 [RFC8402] [RFC8754] [RFC8986], BGP services are assigned with SRv6 Service SIDs [RFC9252], which are routable in the network according to its SRv6 locator prefix. Thus, the inter-domain path can be established simply based on the inter-domain routes to the prefix. Inter-domain LSPs based on the BGP-LU mechanism are not necessary for IPv6- and SRv6-based networks.
IPベースのネットワークでは、IPリーチビリティ情報をBGPを使用して異なるドメインのネットワークノードに宣伝することができ、すべてのドメイン境界ノードが他のドメインの宛先ノードのIPプレフィックスへのルートを取得できます。SRV6 [RFC8402] [RFC8754] [RFC8986]の導入により、BGPサービスはSRV6サービスSIDS [RFC9252]で割り当てられます。したがって、ドメイン間パスは、プレフィックスへのドメイン間ルートに基づいて単純に確立できます。BGP-LUメカニズムに基づくドメイン間LSPは、IPv6およびSRV6ベースのネットワークには必要ありません。
This document describes a mechanism to advertise IPv6 prefixes that are associated with the Color Extended Community to establish end-to-end intent-aware paths for SRv6 services. The color value in the Color Extended Community indicates the intent [RFC9256]. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the Colored Prefixes are the SRv6 locators associated with different intents. BGP services over SRv6 (e.g., SRv6 VPN services) [RFC9252] with specific intent could be assigned with SRv6 SIDs under the corresponding SRv6 locators, which are advertised as Colored Prefixes. This allows the SRv6 service traffic to be steered (as specified in [RFC9252]) into end-to-end intent-aware paths based on the longest prefix matching of SRv6 Service SIDs to the Colored Prefixes. In the data plane, the dedicated transport label or SID for the inter-domain path is not needed, resulting in smaller encapsulation overhead than with other options.
このドキュメントでは、Color Extendedコミュニティに関連付けられているIPv6プレフィックスを宣伝するメカニズムについて説明し、SRV6サービスのエンドツーエンドの意図対応パスを確立します。色拡張コミュニティの色値は、意図[RFC9256]を示しています。このようなIPv6プレフィックスは「色付きプレフィックス」と呼ばれ、このメカニズムは色付きプレフィックスルーティング（CPR）と呼ばれます。SRV6ネットワークでは、色付きのプレフィックスは、異なる意図に関連付けられたSRV6ロケーターです。SRV6を介したBGPサービス（例：SRV6 VPNサービス）[RFC9252]は、特定のSRV6 Locatorsの下のSRV6 SIDSで、色付きのプレフィックスとして宣伝されているSRV6 SIDSで割り当てることができます。これにより、SRV6サービストラフィックを（[RFC9252]で指定して）操縦することができます。データプレーンでは、ドメイン間パスの専用トランスポートラベルまたはSIDは必要ありません。その結果、他のオプションよりも小さなカプセル化オーバーヘッドがあります。
The existing IPv6 Address Family and Color Extended Community could be reused to advertise IPv6 Colored Prefixes without new BGP extensions; thus, this mechanism is easy to interoperate and can be deployed incrementally in multi-AS networks that belong to the same trusted domain (in the sense used by Section 8 of [RFC8402]).
既存のIPv6アドレスファミリと色の拡張コミュニティを再利用して、新しいBGP拡張機能なしでIPv6色のプレフィックスを宣伝することができます。したがって、このメカニズムは相互操作が容易であり、同じ信頼できるドメインに属するマルチASネットワークに段階的に展開できます（[RFC8402]のセクション8で使用される意味で）。
In SRv6 networks, an SRv6 locator needs to be allocated for each node. In order to distinguish N different intents, a Provider Edge (PE) node needs to be allocated with N SRv6 locators, each of which is associated a different intent that is identified by a color value. One way to achieve this is by splitting the base SRv6 locator of the node into N sub-locators, whereby these sub-locators are Colored Prefixes associated with different intents.
SRV6ネットワークでは、各ノードにSRV6ロケーターを割り当てる必要があります。n異なる意図を区別するには、プロバイダーエッジ（PE）ノードをn Srv6ロケーターに割り当てる必要があります。それぞれは、色の値によって識別される異なる意図に関連付けられています。これを達成する1つの方法は、ノードのベースSRV6ロケーターをNサブロケーターに分割することです。これにより、これらのサブロケーターは異なる意図に関連付けられた色付きのプレフィックスです。
For example, a PE node is allocated with the base SRv6 Locator 2001:db8:aaaa:1::/64. In order to provide 16 different intents, this base SRv6 Locator is split into 16 sub-locators from 2001:db8:aaaa:1:0000::/68 to 2001:db8:aaaa:1:F000::/68; each of these sub-locators is associated with a different intent, such as low-delay, high-bandwidth, etc.
たとえば、PEノードは、ベースSRV6ロケーター2001：DB8：AAAA：1 ::/64で割り当てられます。16の異なる意図を提供するために、このベースSRV6ロケーターは2001年まで16のサブロケーターに分割されます。DB8：AAAA：1：0000 ::/68から2001：DB8：AAAA：1：F000 ::/68;これらのサブロケーターはそれぞれ、低遅延、高帯域幅など、異なる意図に関連付けられています。
After the allocation of Colored Prefixes on a PE node, routes to these Colored Prefixes need to be advertised both in the local domain and also to other domains using BGP, so that the BGP SRv6 services routes could be resolved using the corresponding CPR route.
PEノードに色付きのプレフィックスが割り当てられた後、これらの色付きプレフィックスへのルートは、BGPを使用してローカルドメインと他のドメインの両方で宣伝する必要があり、対応するCPRルートを使用してBGP SRV6サービスルートを解決できるようにする必要があります。
In a multi-AS IPv6 network, the mechanism for IPv6 unicast routing as defined in [RFC2545] is used for the advertisement of the Colored Prefix routes, in which the Address Family / Subsequent Address Family (AFI/SAFI = 2/1) is used. The Color Extended Community [RFC9012] is carried with the Colored Prefix route with the color value indicating the intent [RFC9256]. The procedure of Colored Prefix advertisement is described using an example with the following topology:
Multi-AS IPv6ネットワークでは、[RFC2545]で定義されているIPv6ユニキャストルーティングのメカニズムが、住所ファミリ/その後のアドレスファミリ（AFI/SAFI = 2/1）が使用される色付きプレフィックスルートの広告に使用されます。Color Extended Community [RFC9012]は、目的を示す色の値を備えた色付きのプレフィックスルートで運ばれます[RFC9256]。色付きのプレフィックス広告の手順については、次のトポロジーの例を使用して説明されています。
Consistent Color Domain:
C1, C2, ...
+--------------+ +--------------+ +-------------+
| | | | | |
| [ASBR11]---[ASBR21] [ASBR23]---[ASBR31] |
--[PE1] [P1] | X | [P2] | X | [P3] [PE3]--
| [ASBR12]---[ASBR22] [ASBR24]---[ASBR32] |
| | | | | |
+--------------+ +--------------+ +-------------+
AS1 AS2 AS3
Colored Prefixes of PE3:
Low delay: PE3:CL1::
High bandwidth: PE3:CL2::
...
Figure 1: Example Topology for CPR Route Illustration
図1：CPRルートイラストのトポロジの例
Assume PE3 is provisioned with two different Colored Prefixes CLP-1 and CLP-2 for two different intents such as "low-delay" and "high-bandwidth" respectively. In this example, It is assumed that the color representing a specific intent is consistent throughout all the domains.
PE3に、それぞれ「低遅延」と「高帯域幅」などの2つの異なる意図に対して、2つの異なる色の接頭辞CLP-1とCLP-2がプロビジョニングされていると仮定します。この例では、特定の意図を表す色がすべてのドメイン全体で一貫していると想定されています。
* PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the Colored Prefixes PE3:CL1:: and PE3:CL2::. Each route should carry the corresponding Color Extended Community C1 or C2. PE3 also advertises a route for the base SRv6 Locator prefix PE3:BL, and there is no Color Extended Community carried with this route.
* PE3は、色付きのプレフィックスPE3：Cl1 ::およびPE3：Cl2 ::のBGP IPv6ユニキャスト（AFI/SAFI = 2/1）ルートを発信します。各ルートは、対応する色の拡張コミュニティC1またはC2を運ぶ必要があります。PE3は、ベースSRV6ロケータープレフィックスPE3：BLのルートも宣伝しています。また、このルートで運ばれる色の拡張コミュニティはありません。
* ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise the CPR routes further to ASBR23 and ASBR24 with next-hop set to itself.
* ASBR31とASBR32は、PE3のCPRルートを受け取り、次のホップセットを使用してCPRルートをASBR23とASBR24にさらに宣伝します。
* ASBR23 and ASBR24 receive the CPR routes of PE3. Since the color-to-intent mapping in AS2 is consistent with that in AS3, the Color Extended Community in the received CPR routes are kept unchanged. ASBR23 and ASBR24 advertise the CPR routes further in AS2 with the next hop set to itself.
* ASBR23およびASBR24は、PE3のCPRルートを受け取ります。AS2の色から目的のマッピングはAS3の色と一致するため、受信したCPRルートの色拡張コミュニティは変更されていません。ASBR23とASBR24は、次のホップセット自体でAS2でCPRルートをさらに宣伝します。
* The behavior of ASBR21 and ASBR22 are similar to the behavior of ASBR31 and ASBR32.
* ASBR21およびASBR22の挙動は、ASBR31およびASBR32の挙動に似ています。
* The behavior of ASBR11 and ASBR12 are similar to the behavior of ASBR23 and ASBR24.
* ASBR11およびASBR12の挙動は、ASBR23およびASBR24の挙動に似ています。
In normal cases, the color value in the Color Extended Community associated with the CPR route is consistent through all the domains, so that the Color Extended Community in the CPR routes is kept unchanged. In some special cases, one intent may be represented as a different color value in different domains. If this is the case, then the Color Extended Community in the CPR routes needs to be updated at the border nodes of the domains based on the color-mapping policy. For example, in AS1, the intent "low latency" is represented by the color "red", while the same intent is represented by color "blue" in AS2. When a CPR route is sent from AS1 to AS2, the Color Extended Community in the CPR routes needs to be updated from "red" to "blue" at the border nodes based on the color-mapping policy.
通常の場合、CPRルートに関連付けられた色の拡張コミュニティの色値はすべてのドメインを介して一貫しているため、CPRルートの拡張コミュニティは変更されません。特別な場合には、1つの意図が異なるドメインで異なる色の値として表される場合があります。この場合、CPRルートの色拡張コミュニティは、カラーマッピングポリシーに基づいてドメインの境界ノードで更新する必要があります。たとえば、AS1では、意図「低レイテンシ」は「赤」の色で表されますが、同じ意図はAS2の「青」の色で表されます。CPRルートがAS1からAS2に送信されると、CPRルートの色拡張コミュニティは、カラーマッピングポリシーに基づいて境界ノードで「赤」から「青」に更新する必要があります。
In network scenarios where some of the intermediate autonomous systems are MPLS based, the CPR routes may still be advertised using the IPv6 unicast address family (AFI/SAFI=2/1) in the MPLS-based intermediate domains; at the MPLS domain border nodes, some route resolution policy could be used to make the CPR routes resolve to intra-domain intent-aware MPLS LSPs. Another possible mechanism is to use the IPv6 LU address family (AFI/SAFI=2/4) to advertise the CPR routes in the MPLS domains, the detailed procedure is described in Section 7.1.2.1 of [SRv6-INTERWORK].
中間自律システムの一部がMPLSベースであるネットワークシナリオでは、MPLSベースの中間ドメインのIPv6ユニキャストアドレスファミリー（AFI/SAFI = 2/1）を使用してCPRルートを宣伝することができます。MPLSドメインの境界ノードでは、いくつかのルート解像度ポリシーを使用して、CPRルートをドメイン内の意図認識MPLS LSPに解決することができます。別の可能なメカニズムは、IPv6 Luアドレスファミリー（AFI/SAFI = 2/4）を使用してMPLSドメインのCPRルートを宣伝することです。詳細な手順については、[SRV6インターワーク]のセクション7.1.2.1で説明します。
A domain border node that receives a CPR route can resolve the CPR route to an intra-domain color-aware path based on the tuple (N, C), where N is the next hop of the CPR route, and C is the Color Extended Community of the CPR route. The intra-domain color-aware path could be built with any of the following mechanisms:
CPRルートを受信するドメイン境界ノードは、タプル（n、c）に基づいたドメイン内の色認識パスへのCPRルートを解決できます。ここで、nはCPRルートの次のホップであり、CはCPRルートの色拡張コミュニティです。ドメイン内の色認識パスは、次のメカニズムのいずれかで構築できます。
* SRv6 Policy
* SRV6ポリシー
* SR-MPLS Policy
* SR-MPLSポリシー
* SRv6 Flex-Algo
* SRV6フレックスアルゴ
* SR-MPLS Flex-Algo
* SR-MPLS Flex-Algo
* RSVP-TE
* RSVP-TE
For example, if PE1 receives a CPR route to PE3:CL1:: with the color C1 and next hop ASBR11, it can resolve the CPR routes to an intra-domain SRv6 Policy based on the tuple (ASBR11, C1).
たとえば、PE1がPE3：Cl1 :: Color C1およびNext Hop ASBR11のCPRルートを受信した場合、Tuple（ASBR11、C1）に基づくドメイン内SRV6ポリシーへのCPRルートを解決できます。
The intra-domain path resolution scheme could be based on any existing tunnel resolution policy, and new tunnel resolution mechanisms could be introduced if needed.
ドメイン内パス解像度スキームは、既存のトンネル解像度ポリシーに基づいている可能性があり、必要に応じて新しいトンネル解像度メカニズムを導入できます。
For an SRv6 service that is associated with a specific intent, the SRv6 Service SID could be allocated under the corresponding Colored locator prefix. For example, on PE3 in the example topology, an SRv6 VPN service with the low-delay intent can be allocated with the SRv6 End.DT4 SID PE3:CL1:DT::, where PE3:CL1:: is the SRv6 Colored Prefix for low-delay service.
特定の意図に関連付けられているSRV6サービスの場合、SRV6サービスSIDは、対応する色のロケータープレフィックスの下で割り当てることができます。たとえば、サンプルトポロジのPE3では、低遅延の意図を持つSRV6 VPNサービスは、SRV6 END.DT4 SID PE3：CL1：DT ::で割り当てることができます。ここで、PE3：CL1 ::は低遅延サービス用のSRV6色のプレフィックスです。
The SRv6 service routes are advertised using the mechanism defined in [RFC9252]. The inter-domain VPN Option C is used, which means the next hop of the SRv6 service route is set to the originating PE and is not changed. Since the intent of the service is embedded in the SRv6 service SID, the SRv6 service route does not need to carry the Color Extended Community.
SRV6サービスルートは、[RFC9252]で定義されたメカニズムを使用して宣伝されます。ドメイン間VPNオプションCが使用されます。つまり、SRV6サービスルートの次のホップは発信元のPEに設定されており、変更されません。サービスの意図はSRV6サービスSIDに組み込まれているため、SRV6サービスルートはColor Extendedコミュニティを運ぶ必要はありません。
With the CPR routing mechanism, the ingress PE node that receives the SRv6 service routes follows the behavior of SRv6 shortest path forwarding (refer to Sections 5 and 6 of [RFC9252]). The SRv6 service SID carried in the service route is used as the destination address in the outer IPv6 header that encapsulates the service packet. If the corresponding CPR route has been received and installed, longest prefix matching of SRv6 service SIDs to the Colored Prefixes is performed. As a result of this prefix matching, the next hop found is an intra-domain color-aware path, which will be used for forwarding the SRv6 service traffic. This process repeats at the border node of each domain the packet traverses, until it reaches its destination.
CPRルーティングメカニズムを使用すると、SRV6サービスルートを受信するIngress PEノードは、SRV6の最短パス転送の動作に従います（[RFC9252]のセクション5および6を参照）。サービスルートに掲載されたSRV6サービスSIDは、サービスパケットをカプセル化する外側IPv6ヘッダーの宛先アドレスとして使用されます。対応するCPRルートを受信してインストールした場合、SRV6サービスSIDの色付きプレフィックスに最長のプレフィックスマッチングが実行されます。このプレフィックスマッチングの結果、次のホップはドメイン内の色認識パスで、SRV6サービストラフィックの転送に使用されます。このプロセスは、各ドメインの境界ノードで、宛先に到達するまでパケットが横断するまで繰り返されます。
This section describes the encapsulation and forwarding process of data packets which are matched with the corresponding CPR route.
このセクションでは、対応するCPRルートと一致するデータパケットのカプセル化と転送プロセスについて説明します。
The topology of Figure 1 is used in each example.
図1のトポロジーは、各例で使用されています。
Following is an illustration of the packet encapsulation and forwarding process of CPR over SRv6 Policy. The abstract representation of IPv6 and the Segment Routing Header (SRH) described in Section 6 of [RFC8754] is used.
以下は、SRV6ポリシーを介したCPRのパケットカプセル化と転送プロセスの図です。[RFC8754]のセクション6で説明されているIPv6とセグメントルーティングヘッダー（SRH）の抽象表現を使用します。
PE3 is provisioned with a Colored Prefix PE3:CL1:: for "low-delay".
PE3には、「低遅延」用の色付きプレフィックスPE3：Cl1 ::をプロビジョニングします。
In AS1, the SRv6 Policy on PE1 for (ASBR11, C1) is represented with SID list <P1, ASBR11>.
AS1では、（ASBR11、C1）のPE1に関するSRV6ポリシーは、SIDリスト<P1、ASBR11>で表されます。
In AS2, the SRv6 Policy on ASBR21 for (ASBR23, C1) is represented with the SID list <P2, ASBR23>.
AS2では、（ASBR23、C1）のASBR21に関するSRV6ポリシーは、SIDリスト<P2、ASBR23>で表されます。
In AS3, the SRv6 Policy on ASBR31 for (PE3, C1) is represented with the SID list <P3, PE3>.
AS3では、（PE3、C1）のASBR31に関するSRV6ポリシーは、SIDリスト<P3、PE3>で表されます。
C-pkt is the customer packet PE1 received from its attaching CE.
C-PKTは、添付のCEから受け取った顧客パケットPE1です。
For packets that belong to an SRv6 VPN service associated with the SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding process using H.Encaps.Red behavior [RFC8986] is shown as below:
SRV6サービスSID PE3：CL1.DT6に関連付けられたSRV6 VPNサービスに属するパケットの場合、h.encaps.red行動[RFC8986]を使用したパケットカプセル化と転送プロセスを以下に示します。
PE1 ->P1: (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt)
P1 ->ASBR11: (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt)
ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR21->P2: (ASBR21, P2)(ASBR23; SL=1)(PE1, PE3:CL1.DT6)(C-pkt)
P2->ASBR23: (ASBR21, ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR31->P3: (ASBR31, P3)(PE3; SL=1)(PE1, PE3:CL1.DT6)(C-pkt)
P3->PE3: (ASBR31, PE3)(PE1, PE3:CL1.DT6)(C-pkt)
Figure 2
In some autonomous systems, SRv6 Flex-Algo may be used to provide intent-aware intra-domain paths. The encapsulation is similar to the case with SRv6 Policy.
一部の自律システムでは、SRV6 Flex-Algoを使用して、意図的なドメイン内パスを提供する場合があります。カプセル化は、SRV6ポリシーの場合に似ています。
In network scenarios where some of the autonomous systems use the MPLS-based data plane, the CPR route can be resolved over a color-aware intra-domain MPLS LSP. Such an intra-domain MPLS LSP may be established using SR-MPLS Policy, SR-MPLS Flex-Algo, or RSVP-TE.
一部の自律システムがMPLSベースのデータプレーンを使用するネットワークシナリオでは、CPRルートを色認識ドメイン内MPLS LSPで解決できます。このようなドメイン内MPLS LSPは、SR-MPLSポリシー、SR-MPLS Flex-Algo、またはRSVP-TEを使用して確立できます。
The encapsulation and forwarding of SRv6 service packets (which are actually IPv6 packets) over an intra-domain MPLS LSP is based on the MPLS mechanisms as defined in [RFC3031], [RFC3032] and [RFC8660]. The behavior is similar to that of IPv6 Provider Edge Routers (6PEs) [RFC4798].
ドメイン内MPLS LSPを介したSRV6サービスパケット（実際にはIPv6パケットである）のカプセル化と転送は、[RFC3031]、[RFC3032]、[RFC8660]で定義されているMPLSメカニズムに基づいています。動作は、IPv6プロバイダーエッジルーター（6PES）[RFC4798]の動作に似ています。
In AS1, the SR-MPLS Policy on PE1 for (ASBR11, C1) is represented with the SID list <P1, ASBR11>.
AS1では、（ASBR11、C1）のPE1に関するSR-MPLSポリシーは、SIDリスト<P1、ASBR11>で表されます。
In AS2, the SR-MPLS Flex-Algo on ASBR21 for (ASBR23, C1) is represented with SID list <ASBR23>.
AS2では、（ASBR23、C1）のASBR21のSR-MPLS Flex-Algoは、SIDリスト<ASBR23>で表されます。
In AS3, the SR-MPLS Policy on ASBR31 for (PE3, C1) is represented with SID list <P3, PE3>.
AS3では、（PE3、C1）のASBR31に関するSR-MPLSポリシーは、SIDリスト<P3、PE3>で表されます。
C-pkt is the customer packet PE-1 received from its attaching CE.
C-PKTは、添付のCEから受け取った顧客パケットPE-1です。
For packets that belong to an SRv6 VPN service associated with the SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding process is shown as below:
SRV6サービスSID PE3：CL1.DT6に関連付けられたSRV6 VPNサービスに属するパケットの場合、パケットのカプセル化と転送プロセスを以下に示します。
PE1-> P1: Label-stack(P1, ASBR11)(PE1, PE3:CL1.DT6)(C-pkt)
P1->ASBR11: Label-stack(ASBR11)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR21->P2: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
P2->ASBR23: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR31->P3: Label-stack(P3, PE3)(PE1, PE3:CL1.DT6)(C-pkt)
P3->PE3: Label-stack(PE3)(PE1, PE3:CL1.DT6)(C-pkt)
Figure 3
The CPR mechanism can be used in network scenarios where multiple inter-connected ASes belong to the same operator, or where there is an operational trust model between the ASes of different operators which means they belong to the same trusted domain (in the sense used by Section 8 of [RFC8402]).
CPRメカニズムは、複数の相互接続されたASEが同じ演算子に属しているネットワークシナリオ、または異なる演算子のASEの間にオペレーショナルトラストモデルがある場合、同じ信頼できるドメインに属することを意味するネットワークシナリオで使用できます（[RFC8402]セクション8で使用される意味で）。
As described in Section 5 of [INTENTAWARE], inter-domain intent-aware routing may be achieved with a logical tunnel created by an SR Policy that applies to multiple ASes. In addition, service traffic with specific intent can be steered to the inter-domain SR Policy based on the intent signaled by Color Extended Community. An operator may prefer a BGP routing-based solution for the reasons described in [INTENTAWARE]. The operator may also consider the availability of an inter-domain controller for end-to-end intent-aware path computation. This document proposes an alternate solution to signal the intent with IPv6 Colored Prefixes using BGP.
[IntententAware]のセクション5で説明されているように、複数のASEに適用されるSRポリシーによって作成された論理トンネルでは、ドメイン間の意図的なルーティングが達成される場合があります。さらに、特定の意図を持つサービストラフィックは、色の拡張コミュニティによって合図された意図に基づいて、ドメイン間SRポリシーに導くことができます。オペレーターは、[IntentAware]に記載されている理由により、BGPルーティングベースのソリューションを好む場合があります。また、オペレーターは、エンドツーエンドの意図対応パス計算のためのドメイン間コントローラーの可用性を検討することもできます。このドキュメントは、BGPを使用してIPv6色のプレフィックスを使用して意図を信号する代替ソリューションを提案します。
When Colored Prefixes are assigned as sub-locators of the node's base SRv6 locator, the IPv6 unicast route of the base locator prefix is the prefix that covers all of the Colored locator prefixes. To make sure the Colored locator prefixes can be distributed to the ingress PE nodes along the border nodes, it is required that route aggregation be disabled for IPv6 unicast routes that carry the Color Extended Community.
色付きのプレフィックスがノードのベースSRV6ロケーターのサブローケーターとして割り当てられている場合、ベースロケータープレフィックスのIPv6ユニキャストルートは、すべての色のロケータープレフィックスをカバーするプレフィックスです。色付きのロケーターのプレフィックスを境界ノードに沿った侵入PEノードに分配できるようにするには、色の拡張コミュニティを運ぶIPv6ユニキャストルートのルート集約を無効にする必要があります。
With the CPR mechanism, at the prefix originator, each Colored Prefix is associated with one specific intent (i.e., color). In each domain, according to the color mapping policy, the same CPR route is always updated with the same color. The case where there are multiple copies of CPR routes with the same Colored Prefix but different Color Extended Community is considered a misconfiguration.
CPRメカニズムを使用すると、プレフィックスオリジネーターでは、各色のプレフィックスが1つの特定の意図（つまり、色）に関連付けられています。各ドメインでは、カラーマッピングポリシーによると、同じCPRルートが常に同じ色で更新されます。同じ色の接頭辞を持つCPRルートの複数のコピーがあるが、異なる色の拡張コミュニティがある場合は、誤った構成と見なされます。
All the border nodes and the ingress PE nodes need to install the Colored locator prefixes in the RIB and FIB. For transit domains that support the CPR mechanism, the border nodes can use the tuple (N, C), where N is the next hop and C is the color, to resolve the CPR routes to intent-aware intra-domain paths. For transit domains that do not support the CPR mechanism, the border nodes would ignore the Color Extended Community and resolve the CPR routes over a best-effort intra-domain path to the next-hop N, while the CPR route will be advertised further to the downstream domains with only the next hop changed to itself. This allows the CPR routes to resolve to intent-aware intra-domain paths in any autonomous systems that support the CPR mechanism, while the CPR routes can fall back to resolve over best-effort intra-domain paths in the legacy autonomous systems.
すべての境界ノードとイングレスPEノードは、リブとFIBに色付きのロケータープレフィックスを取り付ける必要があります。CPRメカニズムをサポートするトランジットドメインの場合、境界線ノードはタプル（n、c）を使用します。ここで、nは次のホップであり、cは色です。CPRメカニズムをサポートしていないトランジットドメインの場合、境界ノードは色の拡張コミュニティを無視し、次のホップNへの最高のエフォルト領域内パス上のCPRルートを解決しますが、CPRルートは次のホップのみが変更されてダウンストリームドメインにさらに宣伝されます。これにより、CPRルートは、CPRメカニズムをサポートするあらゆる自律システムで意図的に認識されるドメイン内パスに解決できますが、CPRルートは、レガシー自律システムのベストエフォートのドメイン内パスを解決するために後退することができます。
There may be multiple inter-domain links between the adjacent autonomous systems, and a border node BGP speaker may receive CPR routes from multiple peering BGP speakers in another domain via External BGP (EBGP). The local policy of a BGP speaker may take the attributes of the inter-domain links and the attributes of the received CPR routes into consideration when selecting the best path for specific Colored Prefixes to better meet the intent. The detailed local policy is outside the scope of this document. In a multi-AS environment, the policy of BGP speakers in different domains needs to be consistent.
隣接する自律システム間には複数のドメイン間リンクがあり、BorderノードBGPスピーカーは、外部BGP（EBGP）を介して別のドメインの複数のピアリングBGPスピーカーからCPRルートを受け取る場合があります。BGPスピーカーのローカルポリシーは、ドメイン間リンクの属性と、特定の色のプレフィックスに最適なパスを選択して意図をより適切に満たすために、受信したCPRルートの属性を考慮に入れることができます。詳細なローカルポリシーは、このドキュメントの範囲外です。マルチAS環境では、さまざまなドメインのBGPスピーカーのポリシーを一貫性を保つ必要があります。
In this document, the IPv6 Unicast Address Family is used for the advertisement of IPv6 Colored Prefixes. The primary advantage of this approach is the improved interoperability with legacy networks that lack support for intent-aware paths, and the facilitation of incremental deployment of intent-aware routing mechanisms. One potential concern arises regarding the need to separate Colored Prefixes from public IPv6 unicast routes. Because the IP prefixes and SRv6 locators of network infrastructure are usually advertised as part of the IP unicast routes, and appropriate filters are configured at the boundaries of network administration, this concern is not considered to be a significant issue. [RFC9602] allocates the prefix 5f00::/16 for SRv6 SIDs. By common agreement among participants in the trusted domain, the filters can be configured to by default drop all traffic from 5f00::/16 but permit the Colored Prefixes in use in these domains. The proposal in [BGP-CAR] provides a complementary solution that is also based on the notion of color indicating the intent and where the SRv6 Locator prefix itself signifies the intent; the difference is that a separate SAFI is used.
このドキュメントでは、IPv6ユニキャストアドレスファミリは、IPv6色のプレフィックスの広告に使用されます。このアプローチの主な利点は、意図的なパスのサポートを欠いているレガシーネットワークとの相互運用性の向上、および意図的なルーティングメカニズムの増分展開の促進です。色付きのプレフィックスをパブリックIPv6ユニキャストルートから分離する必要性に関して、1つの潜在的な懸念が生じます。ネットワークインフラストラクチャのIPプレフィックスとSRV6ロケーターは通常、IPユニキャストルートの一部として宣伝されており、適切なフィルターがネットワーク管理の境界で構成されているため、この懸念は重要な問題とは見なされません。[RFC9602]は、SRV6 SIDSにプレフィックス5F00 ::/16を割り当てます。信頼できるドメインの参加者間の一般的な一致により、フィルターはデフォルトですべてのトラフィックを5F00 ::/16からドロップするように構成できますが、これらのドメインで使用されている色付きのプレフィックスを許可します。[BGP-CAR]の提案は、意図とSRV6ロケーターの接頭辞自体が意図を意味する色の概念にも基づいた補完的なソリューションを提供します。違いは、別のSAFIが使用されることです。
[BGP-CT] describes another mechanism for intent-aware routing, in which the SRv6 service SIDs are not directly associated with the intent (additional SRv6 transport SIDs are required to steer traffic to the inter-domain intent-aware paths), and an SRv6 operation similar to MPLS label swapping is needed on the border nodes of autonomous systems.
[BGP-CT]は、SRV6サービスSIDSが意図に直接関連付けられていない意図対応ルーティングの別のメカニズムについて説明します（追加のSRV6トランスポートSIDは、ドメイン間の意図を目覚めるパスへのトラフィックを導く必要があります）、およびMPLSラベルと同様のSRV6操作は、自動式の吸引体に必要です。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
The mechanism described in this document provides an approach for inter-domain intent-aware routing based on existing BGP protocol mechanisms. The existing BGP IPv6 Unicast Address Family and existing Color Extended Community are reused without further BGP extensions. With this approach, the number of IPv6 Colored Prefixes advertised by PE nodes is proportionate to the number of intents it supports. This may introduce additional routes to the BGP IPv6 routing table. Because these are infrastructure routes, the number of Colored Prefixes is only a small portion of the total amount of IPv6 prefixes. Thus, the impact to the required routing table size is considered acceptable.
このドキュメントで説明されているメカニズムは、既存のBGPプロトコルメカニズムに基づいたドメイン間の意図的なルーティングのアプローチを提供します。既存のBGP IPv6ユニキャストアドレスファミリと既存の色の拡張コミュニティは、BGP拡張機能をさらに拡張せずに再利用されます。このアプローチでは、PEノードによって宣伝されているIPv6色の接頭辞の数は、サポートする意図の数に比例します。これにより、BGP IPv6ルーティングテーブルに追加のルートが導入される場合があります。これらはインフラストラクチャルートであるため、色付きのプレフィックスの数は、IPv6プレフィックスの総量のごく一部にすぎません。したがって、必要なルーティングテーブルサイズへの影響は許容可能であると見なされます。
As the CPR routes are distributed across multiple ASes that belong to a trusted domain, the mapping relationship between the intent and the IPv6 Colored Prefixes are observable to BGP nodes in those ASes. It is possible for an on-path attacker in the trusted domain to identify packets associated with a particular intent.
CPRルートは、信頼できるドメインに属する複数のASESに分布するため、意図とIPv6色のプレフィックスの間のマッピング関係は、それらのASEのBGPノードに観察可能です。信頼できるドメイン内のパス上の攻撃者が特定の意図に関連するパケットを特定することができます。
The security considerations as described in [RFC4271], [RFC4272], and [RFC8754] apply to this document.
[RFC4271]、[RFC4272]、および[RFC8754]で説明されているセキュリティ上の考慮事項は、このドキュメントに適用されます。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
DOI 10.17487/RFC2545, March 1999,
<https://www.rfc-editor.org/info/rfc2545>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[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>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[BGP-CAR] Rao, D., Ed. and S. Agrawal, Ed., "BGP Color-Aware Routing
(CAR)", Work in Progress, Internet-Draft, draft-ietf-idr-
bgp-car-16, 20 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
car-16>.
[BGP-CT] Vairavakkalai, K., Ed. and N. Venkataraman, Ed., "BGP
Classful Transport Planes", Work in Progress, Internet-
Draft, draft-ietf-idr-bgp-ct-39, 28 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
ct-39>.
[INTENTAWARE]
Hegde, S., Rao, D., Uttaro, J., Bogdanov, A., and L.
Jalil, "Problem statement for Inter-domain Intent-aware
Routing using Color", Work in Progress, Internet-Draft,
draft-hr-spring-intentaware-routing-using-color-04, 31
January 2025, <https://datatracker.ietf.org/doc/html/
draft-hr-spring-intentaware-routing-using-color-04>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798,
DOI 10.17487/RFC4798, February 2007,
<https://www.rfc-editor.org/info/rfc4798>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC9602] Krishnan, S., "Segment Routing over IPv6 (SRv6) Segment
Identifiers in the IPv6 Addressing Architecture",
RFC 9602, DOI 10.17487/RFC9602, October 2024,
<https://www.rfc-editor.org/info/rfc9602>.
[SRv6-INTERWORK]
Agrawal, S., Ed., Filsfils, C., Voyer, D., Dawra, G., Li,
Z., and S. Hegde, "SRv6 and MPLS interworking", Work in
Progress, Internet-Draft, draft-ietf-spring-srv6-mpls-
interworking-00, 17 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-mpls-interworking-00>.
The authors would like to thank Shunwan Zhuang, Zhibo Hu, Zhenbin Li, Dhananjaya Rao, and Dhruv Dhody for their reviews and valuable discussion.
著者は、彼らのレビューと貴重な議論をしてくれたShunwan Zhuang、Zhibo Hu、Zhenbin Li、Dhananjaya Rao、Dhruv Dhodyに感謝したいと思います。
The following people contributed significantly to the content of this document and should be considered co-authors:
次の人々は、このドキュメントの内容に大きく貢献し、共著者と見なされるべきです。
Xinjun Chen
Email: ifocus.chen@huawei.com
Jingrong Xie
Email: xiejingrong@huawei.com
Zhenqiang Li
Email: li_zhenqiang@hotmail.com
Haibo Wang
Huawei Technologies
China
Email: rainsword.wang@huawei.com
Jie Dong
Huawei Technologies
China
Email: jie.dong@huawei.com
Ketan Talaulikar
Cisco Systems
India
Email: ketant.ietf@gmail.com
Tao Han
Huawei Technologies
China
Email: hantao@huawei.com
Ran Chen
ZTE Corporation
China
Email: chen.ran@zte.com.cn