RFC 9723 describes how to deliver intent-aware (color-aware) SRv6 services across multiple ASes without any new BGP extension. The trick is to put the intent into the locator: each PE splits its base locator into sub-locators, one per intent (low delay, high bandwidth, ...). These Colored Prefixes are advertised in plain BGP IPv6 unicast (AFI/SAFI 2/1) with a Color Extended Community.
Service SIDs are then allocated from the colored sub-locator that matches the service's intent — e.g., a low-latency VPN gets its End.DT4 SID from the low-delay locator. Service routes are advertised as usual (RFC 9252, Option C, next hop unchanged) and need no color of their own. Ingress PEs and border routers simply do longest-prefix match of the service SID against the colored prefix, and resolve that route onto an intra-domain path for the tuple (next hop, color) — an SRv6 Policy, SRv6 Flex-Algo, or even an SR-MPLS/RSVP-TE LSP in MPLS transit domains.
Because the packet's destination is always the service SID, no inter-domain transport label or SID is needed, keeping encapsulation small.
CPR assumes all participating ASes are one trusted domain (same operator or a formal trust model). Colored locators are ordinary IPv6 unicast routes, so boundary filters must keep them from leaking.
Disable aggregation for IPv6 unicast routes carrying a Color Extended Community; otherwise the base locator swallows the colored sub-locators.
If one intent uses different color values in different ASes, borders must rewrite the Color EC according to a consistent mapping policy. The same colored prefix appearing with two colors is a misconfiguration.
Domains that do not support CPR fall back to best-effort resolution — the service still works, but the intent is not honored in that AS.
With 5f00::/16 (RFC 9602) blocked by default at boundaries, explicitly permit the colored prefixes in use within the trusted domain.