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 5 January 2026.¶

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 summarization, 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¶

• Site-seT (ST): 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¶

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

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

0             15             31             47          63
|             |              |              |           |
+-------+-------+-------+-------+-------+-------+----------+
|  fd   |   D   |  Reg  |   FA  |   ST  |   NN  | host‑64  |
+-------+-------+-------+-------+-------+-------+----------+
     <-----------  network / locator (48 bits) ---------->|

0              15              31              47         63
|              |               |               |          |
+--------+--------+--------+--------+--------+--------+----------+
|  5F    |  00    |  D  R  |   FA   |   ST   |   NN   | host‑64  |
+--------+--------+--------+--------+--------+--------+----------+
                        ^  ^                                   ^
                        |  |                                   |
                        |  +-- Region‑ID (4 bits)              |
                        +----- Domain‑ID (4 bits)              |
<------------------------ network / locator (48 bits) ----->---+

6. Deployment Profiles

The Site-seT (ST) 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. 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 summarize at every 8‑bit field boundary so the mask aligns to a full byte.¶

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

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

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

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

9. Security Considerations

The hierarchical IP addressing plan proposed here offers natural ACL boundaries—and operators should leverage them to minimize security risk:¶

• Byte-Aligned Summaries as ACL Anchors¶

  Because locators and summaries align on full-byte boundaries (e.g., /32 for Region, /48 for Site), ACLs can match on these exact prefixes. For example, an ACL permitting fd00:0500::/32 automatically allows all Site- and Node-level prefixes under Region 05 but denies anything outside. Maintaining ACLs at each Region border is therefore straightforward and less error-prone than arbitrary masks.¶

• Locator->Loopback Consistency Checks¶

  Loopbacks derive directly from the /48 locator, e.g., fd00:0500:0a13::1. If an operator misassings a locator, a simple script can detect mismatches between the advertised /48 and the loopback's low-order 32-bit value. This check helps prevent accidental duplicate identifiers that could be exploited for spoofing.¶

• Logging and Periodic Audits¶

  Log locator assignments and summary changes at each aggregation level. Periodically audit ACLs to ensure they align with the current hierarchy (e.g., confirm that all allowed /48s fall under their parent /32). This catch-all approach helps identify any unauthorized or stale entries before they compromise security.¶

By combining byte-aligned summarization with simple ACL rules at Region or Site boundaries, operators can enforce strict filtering with minimal complexity, leveraging the hierarchical plan to make ACL configuration both robust and scalable.¶

10. IANA Considerations

TBD¶

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

Appendix A. Acknowledgments

TBD¶

Authors' Addresses