SRv6 Addressing Guidelines

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 December 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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.¶

Table of Contents

1. Introduction

IPv6 offers a vast 128‑bit space, allowing operators to build hierarchical address plans that align with their physical and operational topology. When each byte has a clear meaning—Domain‑ID, Region, Flex‑Algo, Site‑Set, Node—summaries fall naturally at region borders and troubleshooting becomes visual.¶

A well‑designed SRv6 addressing plan underpins summarisation, fast convergence, traffic‑engineering flexibility and security filtering. For operators migrating from legacy MPLS or flat IPv6 (brown‑field environments), renumbering entire domains is rarely feasible. The scheme described here overlays gracefully on top of existing allocations: individual domain and regions or sites can migrate incrementally without a network‑wide flag‑day.¶

Using Unique Local Address (ULA) space keeps infrastructure SIDs off the public Internet, limiting the blast‑radius of route leaks or spoofing. A Global‑Unicast scheme is possible but demands airtight RPKI and strict ingress filters; it is therefore NOT RECOMMENDED unless strong business drivers outweigh the risk. RFC9602 specifies 5F00::/16 for operators willing to deploy new strict at their border and edge ACLs ROA is also a viable option.¶

The C‑SID paradigm compresses 16‑bit Segment Identifiers inside a /48 locator—balancing header overhead with FIB scale while allowing deterministic summarisation.¶

2. Conventions and Definitions

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.¶

3. Terminology

This glossary maps each field or acronym to its role in the hierarchical IPv6 structure so readers can follow subsequent sections without ambiguity.¶

• C‑SID: 16‑bit Compressed Segment Identifier¶

• Locator‑Block: Uppermost bits that identify an SRv6 domain¶

• Flex‑Algo: IGP Flexible Algorithm ID¶

• Region‑ID: 8‑bit value (bits 17‑24) grouping sites¶

• Set (SS): 256 C‑SIDs (one /40) sizing a site; even = GIB, odd = LIB¶

• GIB: Global‑ID Block — even‑indexed Sets carrying global C‑SIDs¶

• LIB: Local‑ID Block — odd‑indexed Sets filtered at Region edge¶

• SRv6 Site‑ID: Byte‑sized identifier for a POP cluster¶

• End.LBS: Endpoint behaviour performing Locator‑Block Swap¶

4. Design Goals and Requirements

The five goals below justify every bit choice in the locator. They translate generic IPv6 abundance into a practical, byte‑aligned hierarchy that scales smoothly from small POPs to continental C‑SID domains.¶

• G1: – Scalable Aggregation ≤ 3 new routes in the core after any failure.¶

• G2: – Per‑Node /48 Locator Preserves /64 for services and /96 for locals while capping FIB size.¶

• G3: – Flex‑Algo Plane Parity Bit positions identical across planes.¶

• G4: – Global vs Local Split Even Sets = Global C‑SIDs, odd Sets = Local C‑SIDs.¶

• G5: – Seamless Domain Stitching End.LBS swaps blocks without SRH growth.¶

5. CSID Address‑Encoding Framework (F3216)

This section converts theory into byte boundaries, showing exactly how IPv6 bit‑richness is partitioned into a multi‑level hierarchy (Global‑ID → Region → Flex‑Algo → Site‑Set → Node).¶

The 128‑bit SRv6 locator is split into a 64‑bit network part and a 64‑bit host part. The network part encodes Domain‑ID, Region‑ID, Flex‑Algo, Set and Node‑ID in byte‑aligned fields.¶

6. Deployment Profiles

The Set (SS) byte lets planners scale by powers of 256: one even Set supports up to 256 node locators. Sizing logic:¶

 • Small POP (≤256 nodes): 1 even Set  → summary /40
 • Medium POP (257‑512 nodes): 2 even Sets → summary /39
 • Large POP (513‑1024 nodes): 4 even Sets → summary /38

The examples below show the Sets allocated and the summary route that each Region injects into IS‑IS Level 2.¶

7. Ultra-Scale ISP Deployment with End.LBS

When the node count is beyond 50k, a single Global‑ID Block (GIB) may no longer be enough. ultra-scale Operators with 300k nodes can allocate one /32 Locator‑Block per Region, then use the End.LBS behaviour to swap blocks at the border router. The SRH carries only one extra SID (the End.LBS C‑SID) regardless of hop‑count.¶

The following topology provides an example (hex abbreviated):¶

``` West Region (fd20::/32) East Region (fd21::/32)¶

fd20:..:0600:: fd20:..:0601:: fd21:..:0a00:: +----+ +----+ +----+ |WP1|-------------->|WP2|------------------------>|EP1| +----+ C-SID_W1 +----+ C-SID_W2 +----+ \ / \ / \ / +------------------------------+ | End.LBS Border Router (BR) | +------------------------------+ C-SID fd20:..:00ff:: ``` Legend: WP1, WP2 = West‑region provider routers EP1 = East‑region provider router¶

Segment List example (SRH left→right):¶

 `[C‑SID_W1, C‑SID_W2, fd20:..:00ff:: (End.LBS), C‑SID_E3]`

• At hop 3 the border router executes End.LBS: it rewrites the destination address from fd20:xxxx:yyzz::/32 to the equivalent fd21:xxxx:yyzz::/32 while leaving the C‑SID suffix unchanged.¶

• No additional SID is needed per hop; header growth is constant.¶

• Each Region advertises only its own /32 into the core, keeping FIB size flat even at continental scale.¶

8. Summarisation Best Practices

IPv6 gives ample room to carve hierarchical blocks, but the hierarchy is only useful if each layer advertises exactly one summary into the layer above. The guiding rule is summarise at every 8‑bit field boundary so the mask aligns to a full byte.¶

┌─────────────┬────────────┬────────────┐ │ Topology │ Field mask │ Prefix │ ├─────────────┼────────────┼────────────┤ │ Core AS │ /32 │ Reg+FA │ │ Region POPs │ /38–/40 │ Set range │ │ Single node │ /48 │ Node (NN) │ └─────────────┴────────────┴────────────┘¶

How the summarization flow¶

## Region → Core (IS‑IS L2): Every Region advertises one /32 per Flex‑Algo. The prefix is derived by masking after the FA byte so all downstream Sets collapse naturally. A 300 k‑node continental backbone therefore injects at most 3 × Regions routes into the core.¶

## Site → Region (IS‑IS L1): Each Site advertises a summary that stops at the Set byte: /40 if it needs 1 Set (Small), /39 if it needs 2 Sets (Medium), /38 if it needs 4 Sets (Large). These prefixes never leave the Region.¶

## Core → Region (downward): The core leaks only the /32s back into all Regions. Routers discard any packet whose destination is outside those blocks—protecting against accidental leaks.¶

Provider‑wide Aggregate. ASBRs SHOULD also originate a single prefix that covers the entire ISP address block (e.g., fd00::/20 or the equivalent GUA). Advertising this grand summary into the core and to upstream transit providers adds a final safety net—any stray Internet route leak that re‑enters the network will be suppressed at Region borders because it can never be more specific than the /32s already authorised inside the domain.¶

TE exception. Operators may temporarily leak a specific /39 into the core for traffic‑engineering. Automation MUST withdraw the prefix after use to prevent FIB bloat.¶

Error containment. Because the summary masks are byte‑aligned, a single mis‑originated /48 cannot cross a Region boundary—either the packet is caught by a default‑drop rule or it is outside the /32 admitted by the core.¶

9. Other Operational Considerations

In an IPv6‑only backbone the control‑plane still needs several legacy 32‑bit identifiers—IS‑IS NET‑ID, BGP router‑ID, IS‑IS System‑ID—that were traditionally filled with an IPv4 loopback. Deriving these values directly from the hierarchical locator0 eliminates manual spreadsheets and guarantees internal consistency. The examples below use the medium‑site case from Section 5.1.2:¶

 • Region‑ID 0x05, Flex‑Algo 0
 • Set 0x0A10, Node 0x13B
 • locator0 → **fd00:0500:0a13::/48**
 • L2 summary → **fd00:0500:0a00::/39**

10. Security Considerations

TODO Security¶

11. IANA Considerations

This document has no IANA actions.¶

12. Normative References

[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/rfc/rfc2119>.

[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/rfc/rfc8174>.

Acknowledgments

TODO acknowledge.¶

Author's Address