Encoding Network Slice Identification for SRv6

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 17 July 2026.¶

Copyright Notice

Copyright (c) 2026 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

SRv6 Network Programming [RFC8986] enables the creation of overlays with underlay optimization to be deployed in an SR domain [RFC8402].¶

As defined in [RFC8754], all inter-domain packets are encapsulated for the part of the packet journey that is within the SR domain. The outer IPv6 header [RFC8200] is originated by a node of the SR domain and is destined to a node of the SR domain.¶

Network slicing provides the ability to partition a physical network into multiple isolated logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. [RFC9543] defines the term "IETF Network Slice" and establishes the general principles of network slicing in the IETF context.¶

In a network that provides slicing services, the NRP-ID can be carried in the packet. In the process of packet forwarding, the routers on the forwarding path can extract NRP-ID from the packet, determine the NRP to which the packet belongs, and then forward the packet using the resources associated with the NRP.¶

This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP.¶

2. Slice Identifier

The Slice identifier (SLID) is a network slicing identifier encoded within the IPv6 packet that allows transit routers to apply the proper forwarding treatment with associated network resources.¶

[RFC9543] defines the network resource mapped to the network slice as NRP (Network Resource Partition). A NRP may be associated with a unique IETF network slice or a group of slices. In this document, SLID also refers to NRP-ID, which is used to identify the network resource used in the forwarding process.¶

3. SLID Assignment

When an SR domain enables network slicing, a local policy MUST be defined and uniformly applied within the domain to govern the encoding of the Slice Presence Indicator (SPI) and the Slice Identifier (SLID). This policy includes the method to encode the SPI and the number of bits reserved for the SLID. When a packet enters the SR domain, the ingress PE encapsulates the packet with an outer IPv6 header and optional Segment Routing Header (SRH) as defined in [RFC8754]. The ingress PE MAY classify the packet into a slice and set the slice identifier as follows:¶

o Allocate a source IPv6 address for the outer header from a configured address block designated for network slicing.¶

o Encode the SLID in the least significant bits of this source address.¶

o Set the Slice Presence Indicator (SPI) in the outer IPv6 header to inform transit nodes that a valid SLID is present.¶

The SPI is a local designation within the SR domain. There are two proposed options for encoding the SPI, chosen by domain-wide policy:¶

o SPI Option A - Using a Bit in the Traffic Class Field: A specific, agreed-upon bit within the Traffic Class field of the IPv6 header is used as the SPI. If this option is used, all nodes within the SR domain participating in slice-aware forwarding MUST be upgraded to interpret this bit correctly. Packets with the SPI bit set may not be forwarded correctly by legacy nodes that are unaware of this new semantic for the Traffic Class field.¶

  Traffic Class
+---------------+
| .....SPI Bit. |
+---------------+

o SPI Option B - Using a Designated Address Prefix in the Source Address: A specific IPv6 address prefix is configured and uniformly recognized within the SR domain as the "SPI Prefix". This prefix is allocated from the operator's existing address space and is used exclusively as the network prefix for source addresses carrying SLIDs. The SPI is effectively indicated by the source address falling within this pre-defined prefix. The SLID is encoded in the least significant bits of the interface identifier portion of the address. This method does not alter the structure of the IPv6 address field itself; it simply designates a subset of the operator's address space for slice-enabled traffic. This option can provide better backward compatibility (see Section 6).¶

                Source Address
+------------+---------+---------+------+
| SPI Prefix | Node ID | Padding | SLID |
+------------+---------+---------+------+

The format for the SLID and SPI options in the IPv6 header is shown in Figure 3.¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class (SPI Opt A)     | Flow Label            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                Source Address (SPI Opt B)                     |
+                           (SPI Prefix + SLID)                 +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                   Destination Address                         |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4. Per-Slice Forwarding

Any router within the SR domain that forwards a packet with SPI set uses the SLID to select a slice and apply per-slice policies.¶

The most significant bit of SLID may be used to carry an S-flag, which is used to indicate whether the packet MUST be forwarded strictly using the network resource associated with the SLID. When the network resource associated with the SLID does not exist or is not available, if the S-flag is set to 1, the packet MUST be discarded, otherwise the packet SHOULD be forwarded using the default network resource or ignoring the SLID.¶

+------------+
|S|   SLID   |
+------------+

5. Example

Figure 5 shows an example of network slice packet forwarding using the proposed encoding method. Assume the SPI is encoded using option B as the SPI prefix in Source Address.¶

                       SPI prefix: AA::/64
                  +--------------+--------------+
                  |              |              |
                  v              v              v
     +---+      +---+          +---+          +---+     +---+
     |CE1|------|PE1|----------|P1 |----------|PE2|-----|CE2|
     +---+      +---+          +---+          +---+     +---+
                  ^
                  |
         IPv6 Addr: AA::1:0:0 (Lowest 32 bits reserved for SLID)


                 +------------+     +------------+
                 |    IPv6    |     |    IPv6    |
                 |SA=AA::1:0:5|     |SA=AA::1:0:5|
                 +------------+     +------------+
                 |     SRH    |     |     SRH    |
   +-------+     +------------+     +------------+     +-------+
   |Payload| --> |   Payload  | --> |   Payload  | --> |Payload|
   +-------+ PE1 +------------+ P1  +------------+ PE2 +-------+

The PE and P routers are configured to use the prefix AA::/64 as SPI. The IPv6 address AA::1:0:0 is assigned to PE1 as the source address used for network slicing. And the lowest 32 bits of the address is reserved for SLID.¶

PE1 encapsulates the network slice packet with an outer IPv6 header along with an SRH. The Source Address in the outer header is AA::1:0:5, in which the lowest 32 bits carries the SLID 5. P1 checks the Source Address and finds it matching the SPI prefix AA::/64. So, P1 parses SLID 5 from the Source Address, and uses the network resources associated with SLID 5 to forward the packet. PE2 decapsulates the outer IPv6 header and SRH.¶

6. Backward Compatibility

Backward compatibility differs based on the chosen SPI encoding method:¶

o For SPI Option A (Traffic Class bit): This method is not backward compatible. Legacy routers that do not recognize the new semantic of the designated Traffic Class bit will forward packets based on the standard interpretation of the header fields. They will not perform slice-specific processing. Successful end-to-end slice forwarding requires all routers along the path to be upgraded and configured to interpret the SPI bit correctly.¶

o For SPI Option B (Source Address Prefix): This method offers better backward compatibility. Legacy routers forward packets based on the destination address and standard routing rules. They treat the source address as a regular IPv6 address and ignore any slice semantics. Therefore, packets can traverse legacy nodes without issue, provided the path is otherwise valid. Only nodes that are explicitly configured to recognize the designated SPI prefix will inspect the source address, extract the SLID from its lower bits, and apply slice-specific forwarding policies. This allows for incremental deployment within an SR domain.¶

In both cases, ingress PEs that are not slice-aware will not set the SPI or encode a SLID. Slice-aware transit routers will not attempt to classify such packets into a slice and will forward them using default resources.¶

7. Security Considerations

The encoding mechanism defined in this document does not introduce new vulnerabilities or attack vectors to the SRv6 architecture. The security considerations discussed herein are inherent to the operation of network slicing and the use of source routing within a trusted domain, and they map to existing security paradigms for IPv6 and Segment Routing.¶

o Interaction with Legacy Nodes (SPI Option A): If SPI Option A (Traffic Class bit) is deployed, the risk of misforwarding by legacy nodes stems from reusing an existing field in a new way. This is a well-understood interoperability and incremental deployment consideration. Networks requiring end-to-end slice consistency must ensure path continuity, which may involve upgrading legacy nodes or selecting paths that exclude them.¶

o Address Space Management (SPI Option B): The need to carefully manage the address block used as the SPI Prefix to avoid overlap is a standard network planning requirement for any IPv6 deployment. It does not represent a new security flaw but emphasizes operational best practices.¶

8. IANA Considerations

TBD¶

9. References

Authors' Addresses