Addressing Recommendations for SRv6

Segment Routing over IPv6 (SRv6) enables the creation of source routing policies by encoding instructions in the form of IPv6 addresses, known as Segment Identifiers (SIDs). To efficiently manage SRv6 deployments at scale, it is critical to design a structured and summarizable addressing plan. This document provides addressing recommendations for SRv6 deployments using the NEXT-CSID and REPLACE-CSID compression formats defined in [RFC9800]. It specifies addressing structures based on a 32-bit Locator-Block and either a 16-bit CSID (F3216 for NEXT-CSID) or a 32-bit CSID (F3232 for REPLACE-CSID), and provides operational guidelines for service-provider networks of different sizes.

This document leverages the terms defined in , , , , and , in particular segment, segment list, Segment Identifier (SID), SID list, SR policy, prefix segment, adjacency segment, SRH, SR domain, SR source node, SR segment endpoint node, transit node, SRv6 endpoint behavior, flavor, SID block, locator, function, and argument, IGP Flexible Algorithm (FA), Locator-Block, Locator-Node, Compressed-SID (CSID), CSID container, CSID length, compressed SID list, Global Identifier Block (GIB), and Local Identifier Block (LIB). The reader is assumed to be familiar with this terminology. This document introduces the following new terms:

Node ID:: Identifier for a specific network node within a block or set
F3216:: A short-hand notation that refers to the format of NEXT-CSID flavor SID with a 32-bit Locator-Block and a 16-bit CSID. NEXT-CSID () implementations must support this format.
F3232:: A short-hand notation that refers to the format of a REPLACE-CSID flavor SID with a 32-bit Locator-Block and a 32-bit CSID. REPLACE-CSID implementations must support a 32-bit CSID length ().
Set ID:: Identifier for subdivision of the block providing summarization boundaries
SID Space:: Common prefix covering all Block prefixes in a network

SRv6 locator is a routable prefix allocated to a node and associated with a single algorithm. An SRv6 locator is often called simply "locator".

Simplicity:: A simple consistent addressing plan eases allocation and operations
Hierarchical and aggregatable:: A hierarchical addressing plan enables simple and efficient summarization which is fundamental for SRv6 scalability.
SID list compression efficiency:: The addressing plan should offer efficient SID list compression, minimizing the number of CSID containers required for any TE policy.
Extensibility:: The addressing plan must be able to adapt as the organization and the network evolves.

Infrastructure addresses and SRv6 locators serve different purposes and perform different roles in the network. Therefore, SRv6 locators must be allocated from a separate address range to facilitate network operation and security. Since SRv6 locators have different allocation requirements and constraints, they should be allocated using a dedicated SRv6 addressing plan. An existing IPv6 addressing plan should not be a constraint for the SRv6 addressing plan. This document uses the SRv6 SID address block 5f00::/16 (), but the same principles are applicable when using ULA or GUA address ranges. This document provides specific addressing recommendations for the F3216 locator format used with NEXT-CSID and the F3232 locator format used with REPLACE-CSID. Unless explicitly stated otherwise, these recommendations are generally applicable to other SRv6 locator formats as well. It is valuable to use nibble boundaries whenever possible to improve human readability.

structures an SRv6 locator as the combination Locator-Block:Locator-Node. For simplicity, we will use the terms Block ID and CSID to refer to Locator-Block and Locator-Node respectively. Format F3216 uses 32 bits for the Block ID and 16 bits for the CSID. This results in a 16-bit Locator-Node length. This locator structure can be represented as follows, using one character for each 4 bits:

BBBB:BBBB:NNNN::/48 Where:

BBBB:BBBB: = 32-bit Block ID
NNNN: = 16-bit CSID

specifies the Global ID Block (GIB) and Local ID Block (LIB) as two non-overlapping sub-spaces of the CSID numbering space. As stated in :

"The CSID values that are allocated from the GIB have a global semantic within the Locator-Block, while those that are allocated from the LIB have a local semantic on an SR segment endpoint node and within the scope of the Locator-Block."

states that, for a CSID allocated from the GIB:

"The tuple (Locator-Block, CSID) identifies the same segment across all nodes of the SR domain."

And, for a CSID allocated from the LIB:

"The tuple (Locator-Block, CSID) identifies a different segment on each node of the SR domain."

CSID values allocated from the GIB represent globally unique segments and can be included as part of the locator. On the other hand, CSID values allocated from the LIB represent segments that are locally significant to each node and, as a such, cannot be used as part of a locator. This separation is fundamental to ensuring fully deterministic behavior for TE. The boundary between the GIB and LIB is flexible, but it must be consistent across all nodes of the SR domain. The industry-accepted default sub-spaces for the F3216 format uses the uSID values 0x0001 to 0xdfff for GIB and the SIDs 0xe000 to 0xffff for LIB. This implies that for each Block there are 57,344 global SIDs (excluding CSID value 0, which is reserved to mark the end-of-container) and 8,192 local SIDs.

To organize address spaces more efficiently, the CSID numbering space within a block is divided into smaller, equally sized sections called sets. Each set has a unique Set ID. The remaining less significant bits of the CSID space are used for Node IDs, to uniquely identify each node within a set. The combination of the Block ID and Set ID creates a subnet prefix. This subnet can be assigned to a specific routing area or domain. This approach makes logical address assignment and address summarization much simpler and more efficient. A Set ID can be any length, but for human readability it is recommended to use sizes that align with nibble (4-bit) boundaries. The most common size for a Set ID is 8 bits. The locator structure is as follows:

BBBB:BBBB:SSNN:: Where:

BBBB:BBBB: = 32-bit Block ID
SS: = 8-bit Set ID
NN: = 8-bit Node ID

This structure supports 256 different sets within each block. Each set can contain up to 256 unique Node IDs. The set with Set ID 0x00 has only 255 usable Node IDs because CSID value 0x0000 is reserved. When using the default split between GIB and LIB, then Set IDs from 0x00 to 0xdf are used for locators (globally significant) and Set IDs from 0xe0 to 0xff are used for local functions.

An area is any part of the network with defined boundaries where address summarization can be performed (such as an ISIS level or an OSPF area). The number of devices in an area can vary, typically containing anywhere from a few hundred to several thousand devices. Operators assign an appropriate number of sets to each area, based on the number of devices it needs to support. Set Assignment Example: Block ID: 5f00:0000::/32 Area 1 - 500 devices:

Assigned 2 Sets (IDs 0x00 and 0x01) providing a total of 511 global SIDs:

5f00:0000:0000::/40 (255 locators)
5f00:0000:0100::/40 (256 locators)

Area 2 - 1500 devices:

Assigned 6 Sets (IDs 0x04, 0x05, 0x06, 0x07, 0x11, 0x12) for a total of 1536 global SIDs:

5f00:0000:0400::/40 (256 locators)
5f00:0000:0500::/40 (256 locators)
5f00:0000:0600::/40 (256 locators)
5f00:0000:0700::/40 (256 locators)
5f00:0000:1100::/40 (256 locators)
5f00:0000:1200::/40 (256 locators)

Sets assigned to single area do not have to be consecutive. (See the Summarization section for more details.)

Summarizing locators is essential for achieving virtually unlimited scalability in an SRv6 network. The need for summarization depends on the size of the network and the scalability of individual devices. In very small networks, summarization may not be necessary. It proves to be operationally very beneficial to use a unified summarization scheme across the entire network. No matter the area size, always summarize at set boundaries. This approach keeps routing tables simple, clean, and structured, while still providing strong summarization benefits. It also eases the preservation of addressing space for future growth. Summarization Example: Area 1 - summaries:

5f00:0000:0000::/40
5f00:0000:0100::/40

Area 2 - summaries:

5f00:0000:0400::/40
5f00:0000:0500::/40
5f00:0000:0600::/40
5f00:0000:0700::/40
5f00:0000:1100::/40
5f00:0000:1200::/40

It is technically possible to advertise larger blocks, such as 5f00:0000:0000::/39 for Area 1 or 5f00:0000:0400::/38 for Area 2 (together with the remaining /40 prefixes). However, the summarization gain here is negligible, while increasing operational complexity.

A small network is any network where every device can be assigned a locator from a single block. Theoretically, a single block can support up to 57,343 SRv6 devices. In practice it is suitable for networks with up to around 35,000 devices. In this scenario, only one block is used to address all devices in the network. This is the optimal option for TE, because all SIDs in any policy will come from the same block. As a result, a headend can use the minimal possible number of containers in its TE policies. A small network is divided into areas, depending on the scalability of devices and the routing protocol. Each area is assigned the appropriate number of sets based on its current size. Devices within each area are assigned locators from the sets of the area. Example: Block ID: 5f00:0000::/32 Area 1 - 500 devices - 2 sets 0x00 and 0x01 First device locator: 5f00:0000:0001::/48 Last device Locator: 5f00:0000:01ff::/48

A large network is any network with more than approximately 35,000 devices. In this case, a single block is not enough to assign a unique locator to each device. Therefore, the network is divided into regions, with each region able to contain up to about 35,000 devices. The number of regions depends on the total network size. It is important to make each region as large as possible to minimize the number of block boundaries, which benefits efficient TE. Note that a "region" here is a logical grouping and is not limited to a geographical area. Within each region, sets are assigned following the same principles as in small network addressing. For a network with up to approximately 500,000 SRv6 devices, up to 16 regions may be needed. The addressing format is the following:

BBBB:BBBR:SSNN:: Where:

BBBB:BBB: = 28-bit SRv6 Space
R: = 4-bit Region ID
SS: = 8-bit Set ID
NN: = 8-bit Node ID

Example: In a network using SRv6 Space 5f00:0000::/28, the locator of a device with Node ID 0x43 in region 0x5, set 0x75, is: 5f00:0005:7543::/48 For a very large network with more than 500,000 SRv6 devices, more regions are needed. In this case, allocate 8 bits (2 nibbles) for the Region ID, allowing to scale up to approximately 8 million SRv6 devices. The addressing format becomes:

BBBB:BBRR:SSNN:: Where:

BBBB:BB: = 24-bit SRv6 Space
RR: = 8-bit Region ID
SS: = 8-bit Set ID
NN: = 8-bit Node ID

Example: In a network using SRv6 Space 5f00:0000::/24, the locator of a device with Node ID 0x43 in region 0x11, set 0x75, is: 5f00:0011:7543::/48

Using Flexible Algorithms (FAs) in SRv6 networks requires assigning multiple independent locators to single device, one for each algorithm. To ensure efficient summarization schema and operational simplicity, follow these guidelines:

Never use the same block for different algorithms: If two locators share the same block, they will share the same LIB, which reduces scalability. Therefore, the FA ID should always be encoded in the Block ID.
Encode FA in the highest-order bits of the network addressing plan: This approach makes summarization efficient. Locators for different algorithms cannot be summarized together, so summarization should happen at the level of sets (or at the region level in large networks).
For a given device, use the same Node ID across all algorithms: This simplifies operations and device management.

Typically, a single nibble (4 bits) is enough for the FA ID. It is very unlikely that a service provider will use more than 16 flexible algorithms. Locator Structure for small networks:

BBBB:BBBF:SSNN:: Where:

BBBB:BBB: = 28-bit SRv6 space
F: = 4-bit Flexible Algorithm ID
SS: = 8-bit Set ID
NN: = 8-bit Node ID

Locator Structure for large networks:

BBBB:BBFR:SSNN:: Where:

BBBB:BB: = 24-bit SRv6 space
F: = 4-bit Flexible Algorithm ID
R: = 4-bit Region ID
SS: = 8-bit Set ID
NN: = 8-bit Node ID

Locator Structure for very large networks:

BBBB:BFRR:SSNN:: Where:

BBBB:B: = 20-bit SRv6 space
F: = 4-bit Flexible Algorithm ID
RR: = 8-bit Region ID
SS: = 8-bit Set ID
NN: = 8-bit Node ID

Example Small Network: In a network using the default algorithm (Algorithm 0) and two flexible algorithms, using SRv6 Space 5f00:0000::/28, the locators of a device with Node ID 0x43 in set 0x75 are:

Locator for default algorithm - 5f00:0000:7543::/48
Locator for FA ID 128 - 5f00:0001:7543::/48
Locator for FA ID 129 - 5f00:0002:7543::/48

Example Large Network: In a network using the default algorithm and two flexible algorithms, using SRv6 Space 5f00:0000::/24, the locators of a device with Node ID 0x43 in region 0x5, set 0x75 are:

Locator for default algorithm - 5f00:0005:7543::/48
Locator for FA128 - 5f00:0015:7543::/48
Locator for FA129 - 5f00:0025:7543::/48

The F3232 addressing scheme for 32-bit REPLACE-CSID uses the same logical addressing hierarchy as F3216 for NEXT-CSID. The differences result from the use of a 32-bit CSID in F3232, rather than a 16-bit CSID in F3216. Block ID consistency: Both schemes use a 32-bit Block ID. The allocation of Block IDs, Flexible Algorithm IDs, and Region IDs is identical. Difference 1: CSID allocation. In both schemes, the CSID space is divided equally between Set IDs and per-Set identifiers. Because the REPLACE-CSID is 32 bits rather than 16 bits, both fields have four nibbles (16 bits) in F3232, rather than two nibbles (8 bits) in F3216. For example, the bits can be assigned as follows for a very large network:

Where:

BBBB:B: 20-bit SRv6 Space
F: 4-bit Flexible Algorithm ID
RR: 8-bit Region ID
SSSS: 16-bit Set ID
NNNN: 16-bit Node-and-Function ID

Operators may allocate the Node-and-Function ID space in contiguous ranges per node, or subdivide it further according to their operational requirements. Consequently, the Block-plus-Set aggregation boundary is a /48 prefix in F3232, rather than a /40 prefix in F3216. Difference 2: GIB/LIB allocation. As with F3216, the GIB/LIB boundary is a deployment choice. This document recommends preserving the same 7/8 GIB and 1/8 LIB proportion:

Equivalently, Set IDs from 0x0000 through 0xdfff are used for the GIB (except that CSID value 0x00000000 is reserved), and Set IDs from 0xe000 through 0xffff are used for the LIB, in F3232. In NEXT-CSID deployments, the GIB is normally used for globally significant node SIDs, while REPLACE-CSID can use the GIB for globally significant node and function SIDs. This is the primary driver for utilizing a 32-bit CSID for REPLACE-CSID. This F3232 addressing scheme maximizes addressing consistency between REPLACE-CSID and NEXT-CSID, ensuring that address planning does not become a complicating factor when choosing between them. Operators can select REPLACE-CSID for its larger, more flexible CSID space, or NEXT-CSID for its higher compression efficiency, while retaining an almost identical logical addressing hierarchy. To allow operators to focus on 32-bit REPLACE-CSID and 16-bit NEXT-CSID, this document intentionally omits an addressing scheme for 16-bit REPLACE-CSID. This avoids introducing additional options that could complicate operator planning.

The addressing of interfaces and loopbacks is independent of locator addressing. If the network already uses IPv6 addressing, there is no need to change it. However some coordinated addressing strategies can simplify network operations and increase scalability.

Assigning loopback addresses from the node's locator space has several advantages:

Simpler summarization rules: all loopback addresses can be summarized with locators.
Smaller IGP database: fewer unique prefixes are advertised.
Simpler addressing plan: no separate loopback addressing plan required.
Using loopback as encapsulation source simplifies configuration and troubleshooting.

Although loopback addresses can technically be assigned from any algorithm's locator, it is most logical and common to use the default algorithm's locator. Example: For a device with Node ID 0x43 in set 0x75:

Locator for default algorithm: 5f00:0000:7543::/48
Loopback address: 5f00:0000:7543::1/128

Each IPv6 interface has a Link-Local unicast address (). Link-local addresses are sufficient to establish routing adjacencies and build a fully functional IPv6 and SRv6 network. Therefore, it is possible to use only link-local addresses on infrastructure links between routers (). This simplifies the overall addressing plan and reduces the IGP database but comes with the drawback that interfaces with only link-local addresses cannot be reached remotely, which may cause operational challenges. AOne possible mitigation is to allocate an End.X SID for each interface for which remote liveness verification is required. If supported by the implementation and permitted by the local ICMP policy, an operator can send ICMP Echo Requests to these SIDs. Because the SIDs are associated with routable SRv6 locators, the probes can be originated from remote nodes. The exact liveness semantics of such probes are implementation-dependent.

IP Address Management (IPAM) is a critical component of SRv6 network planning, providing structured allocation, tracking, and auditing of IP address space. For operators, IPAM ensures hierarchical and non-overlapping assignments, supports route summarization, and enables automation for large-scale deployments. In this context, LIRs (Local Internet Registries) play a central role: they receive IPv6 allocations from Regional Internet Registries under policies such as RIPE-212, allowing operators to plan locator blocks and SID assignments systematically while ensuring scalability, address conservation, and alignment with network topology.

This document does not introduce new security issues beyond those existing in SRv6 and IPv6.

This document makes no IANA requests.

The authors would like to acknowledge the contribution of Francois Clad, Clarence Filsfils and Ketan Talaulikar for their valuable input and review of this document.

Cisco Systems

Montreal Canada davoyer@cisco.com