Encoding Network Slice Identification for SRv6
draft-cheng-spring-srv6-encoding-network-sliceid-13
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Weiqiang Cheng , Peiyong Ma , Fenghua Ren , Changwang Lin , Liyan Gong , Shay Zadok , Mingyu Wu , xuewei wang | ||
| Last updated | 2026-07-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cheng-spring-srv6-encoding-network-sliceid-13
SPRING W. Cheng
Internet-Draft China Mobile
Intended status: Standards Track P. Ma
Expires: 4 January 2027 China Telecom
F. Ren
China Unicom
C. Lin
New H3C Technologies
L. Gong
China Mobile
S. Zadok
Broadcom
M. Wu
CentecNetworks
X. Wang
Ruijie Networks Co., Ltd.
3 July 2026
Encoding Network Slice Identification for SRv6
draft-cheng-spring-srv6-encoding-network-sliceid-13
Abstract
A Network Resource Partition (NRP) is a subset of the network
resources and associated policies on each of a connected set of links
in the underlay network. An NRP could be used as the underlay to
support one or a group of enhanced VPN services. For packet
forwarding in a specific NRP, some fields in the data packet are used
to identify the NRP the packet belongs to, so that NRP-specific
processing can be performed on each node along a path in the NRP.
At the data plane, use the NRP Selector ID to map and differentiate
between different NRPs. How to map to NRP via Selector ID is not
within the scope of this document.
This document describes a novel method to encode NRP Selector 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Cheng, et al. Expires 4 January 2027 [Page 1]
Internet-Draft Encoding Network Slice Identification fo July 2026
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 4 January 2027.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. NRP Selector Identifier Assignment . . . . . . . . . . . . . 4
3. Per-NRP Forwarding . . . . . . . . . . . . . . . . . . . . . 6
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
SRv6 Network Programming [RFC8986] enables the creation of overlays
with underlay optimization to be deployed in an SR domain [RFC8402].
Cheng, et al. Expires 4 January 2027 [Page 2]
Internet-Draft Encoding Network Slice Identification fo July 2026
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.
In a network that provides NRP services, the NRP Selector ID can be
carried in the packet. In the process of packet forwarding, the
routers on the forwarding path can extract NRP Selector 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.
1.1. Requirements Language
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
[RFC2119] (Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997) and [RFC8174]
(Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017).
1.2. Terminology
The key terms used in this document are defined below.
Network Resource Partition (NRP): a subset of the network resources
and associated policies on each of a connected set of links in the
underlay network. This term is defined in [RFC9543].
NRP Identifier (NRP-ID): an identifier that is globally unique within
an NRP domain and that can be used in the control or management plane
to identify the resources associated with the NRP. [RFC9543].
NRP Selector: one or more fields (markings) in a packet's network
layer header that are used to map the packet to an NRP.
[draft-ietf-teas-ns-ip-mpls]
NRP Selector Identifier (NRP Selector ID): a dedicated identifier
that acts as an NRP Selector. [draft-ietf-teas-ns-ip-mpls]
Cheng, et al. Expires 4 January 2027 [Page 3]
Internet-Draft Encoding Network Slice Identification fo July 2026
2. NRP Selector Identifier Assignment
One approach to improve the data plane scalability of NRPs is to
introduce a dedicated NRP Selector ID in data packets, which is used
to identify the set of network resources allocated to an NRP. This
way, packets mapped to an NRP can be processed and forwarded using
the NRP-specific network resources, which could help to provide
guaranteed performance for the packets. An NRP Selector ID can be
used to identify a subset of the resources (e.g., bandwidth, buffer,
and queuing resources) allocated on the set of links and nodes
involved in the NRP. [draft-ietf-teas-ns-ip-mpls]
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 NRP Presence Indicator (NPI) and the NRP Selector
Identifier. This policy includes the method to encode the NPI and
the number of bits reserved for the NRP Selector Identifier. 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 NRP and set the NRP identifier as follows:
o Allocate a source IPv6 address for the outer header from a
configured address block designated for NRP.
o Encode the NRP Selector Identifier in the least significant bits of
this source address.
o Set the NRP Presence Indicator (NPI) in the outer IPv6 header to
inform transit nodes that a valid NRP Selector Identifier is present.
The NPI is a local designation within the SR domain. There are two
proposed options for encoding the NPI, chosen by domain-wide policy:
o NPI 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 NPI. If this option is used, all nodes within the SR
domain participating in NRP-aware forwarding MUST be upgraded to
interpret this bit correctly. Packets with the NPI bit set may not
be forwarded correctly by legacy nodes that are unaware of this new
semantic for the Traffic Class field.
Traffic Class
+---------------+
| .....NPI Bit. |
+---------------+
Figure 1: NPI Option A
Cheng, et al. Expires 4 January 2027 [Page 4]
Internet-Draft Encoding Network Slice Identification fo July 2026
o NPI 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 "NPI Prefix". This prefix is
allocated from the operator's existing address space and is used
exclusively as the network prefix for source addresses carrying NRP
Selector Identifiers. The NPI is effectively indicated by the source
address falling within this pre-defined prefix. The NRP Selector
Identifier 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 NRP-enabled traffic. This
option can provide better backward compatibility (see Section 6).
Source Address
+------------+---------+---------+------------+
| NPI Prefix | Node ID | Padding | SelectorID |
+------------+---------+---------+------------+
Figure 2: NPI Option B
The format for the NRP Selector Identifier and NPI 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 (NPI Opt A) | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Source Address (NPI Opt B) |
+ (NPI Prefix + NRP Selector Identifier) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Destination Address |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Encoding of NRP Selector Identifier and NPI Option
Cheng, et al. Expires 4 January 2027 [Page 5]
Internet-Draft Encoding Network Slice Identification fo July 2026
3. Per-NRP Forwarding
Any router within the SR domain that forwards a packet with NPI set
uses the NRP Selector Identifier to select a NRP and apply per-NRP
policies.
The most significant bit of NRP Selector Identifier 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 NRP
Selector Identifier. When the network resource associated with the
NRP Selector Identifier 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 NRP Selector Identifier.
+------------------------------+
|S| NRP Selector Identifier |
+------------------------------+
Figure 4: The NRP Selector Identifier with S bit
4. Example
Figure 5 shows an example of network NRP packet forwarding using the
proposed encoding method. Assume the NPI is encoded using option B
as the NPI prefix in Source Address.
NPI prefix: AA::/64
+--------------+--------------+
| | |
v v v
+---+ +---+ +---+ +---+ +---+
|CE1|------|PE1|----------|P1 |----------|PE2|-----|CE2|
+---+ +---+ +---+ +---+ +---+
^
|
IPv6 Addr: AA::1:0:0 (Lowest 32 bits reserved for NRP Selector Identifier)
+------------+ +------------+
| IPv6 | | IPv6 |
|SA=AA::1:0:5| |SA=AA::1:0:5|
+------------+ +------------+
| SRH | | SRH |
+-------+ +------------+ +------------+ +-------+
|Payload| --> | Payload | --> | Payload | --> |Payload|
+-------+ PE1 +------------+ P1 +------------+ PE2 +-------+
Cheng, et al. Expires 4 January 2027 [Page 6]
Internet-Draft Encoding Network Slice Identification fo July 2026
Figure 5: Packet Forwarding for Network NRP
The PE and P routers are configured to use the prefix AA::/64 as NPI.
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 NRP Selector Identifier.
PE1 encapsulates the network NRP 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 NRP Selector
Identifier 5. P1 checks the Source Address and finds it matching the
NPI prefix AA::/64. So, P1 parses NRP Selector Identifier 5 from the
Source Address, and uses the network resources associated with NRP
Selector Identifier 5 to forward the packet. PE2 decapsulates the
outer IPv6 header and SRH.
5. Backward Compatibility
Backward compatibility differs based on the chosen NPI encoding
method:
o For NPI 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
NRP-specific processing. Successful end-to-end NRP forwarding
requires all routers along the path to be upgraded and configured to
interpret the NPI bit correctly.
o For NPI 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 NRP
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 NPI prefix will
inspect the source address, extract the NRP Selector Identifier from
its lower bits, and apply NRP-specific forwarding policies. This
allows for incremental deployment within an SR domain.
In both cases, ingress PEs that are not NRP-aware will not set the
NPI or encode a NRP Selector Identifier. NRP-aware transit routers
will not attempt to classify such packets into a NRP and will forward
them using default resources.
Cheng, et al. Expires 4 January 2027 [Page 7]
Internet-Draft Encoding Network Slice Identification fo July 2026
6. 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 (NPI Option A): If NPI 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 NRP consistency must
ensure path continuity, which may involve upgrading legacy nodes or
selecting paths that exclude them.
o Address Space Management (NPI Option B): The need to carefully
manage the address block used as the NPI 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.
7. IANA Considerations
TBD
8. References
8.1. 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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
Cheng, et al. Expires 4 January 2027 [Page 8]
Internet-Draft Encoding Network Slice Identification fo July 2026
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
8.2. Informative References
[draft-ietf-teas-ns-ip-mpls]
Saad, A., Ed., Beeram, V., Ed., Dong, J., and J. Halpern,
"Realizing Network Slices in IP/MPLS Networks", Work in
Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-08,
DOI 10.17487/draft-ietf-teas-ns-ip-mpls-08, June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-
ip-mpls-08>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L., and J. Tantsura, "A
Framework for Network Slices in Networks Built from IETF
Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
<https://www.rfc-editor.org/rfc/rfc9543>.
Authors' Addresses
Weiqiang Cheng
China Mobile
Beijing
China
Email: chengweiqiang@chinamobile.com
Peiyong Ma
China Telecom
Guangzhou
China
Email: mapeiy@chinatelecom.cn
Cheng, et al. Expires 4 January 2027 [Page 9]
Internet-Draft Encoding Network Slice Identification fo July 2026
Fenghua Ren
China Unicom
Beijing
China
Email: renfh3@chinaunicom.cn
Changwang Lin
New H3C Technologies
Beijing
China
Email: linchangwang.04414@h3c.com
Liyan Gong
China Mobile
Beijing
China
Email: gongliyan@chinamobile.com
Shay Zadok
Broadcom
Israel
Email: shay.zadok@broadcom.com
Mingyu Wu
CentecNetworks
China
Email: wumy@centec.com
Xuewei Wang
Ruijie Networks Co., Ltd.
Beijing
China
Email: wangxuewei1@ruijie.com.cn
Cheng, et al. Expires 4 January 2027 [Page 10]
