Advertise SRv6 Locator Information by IPv6 Neighbor Discovery
draft-gong-spring-nd-advertise-srv6-locator-04
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 | Liyan Gong , Changwang Lin , Acee Lindem | ||
| Last updated | 2026-02-25 | ||
| 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-gong-spring-nd-advertise-srv6-locator-04
SPRING L. Gong
Internet-Draft China Mobile
Intended status: Standards Track C. Lin
Expires: 29 August 2026 New H3C Technologies
A. Lindem
Arrcus, Inc.
25 February 2026
Advertise SRv6 Locator Information by IPv6 Neighbor Discovery
draft-gong-spring-nd-advertise-srv6-locator-04
Abstract
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6
Locator. Through the SRv6 locator routes, other SRv6 segment nodes
can steer traffic to that node. This document describes a method for
an SRv6 endpoint (e.g., a host or a customer provider edge (CPE)) to
advertise its SRv6 locator to a neighboring SRv6-aware router using
extensions to the IPv6 Neighbor Discovery (ND) protocol. This
approach eliminates the need to run a full routing protocol stack on
simple endpoints, facilitating SRv6 deployment in controlled, trusted
domains such as data centers and managed access networks.
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 29 August 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gong, et al. Expires 29 August 2026 [Page 1]
Internet-Draft Advertise SRv6 Locator by ND February 2026
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. Motivation and Applicability . . . . . . . . . . . . . . . . 3
3. Process of Advertising SRv6 Locator by IPv6 ND . . . . . . . 5
4. Extension of IPv6 Neighbor Discovery Options . . . . . . . . 7
4.1. Source SRv6 Locator Information Option . . . . . . . . . 7
4.2. Source SRv6 Capability Option . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Segment Routing (SR) [RFC8402] allows a node to steer a packet flow
along any path. The headend is a node where the instructions for
source routing (i.e., segments) are written into the packet.It hence
becomes the starting node for a specific segment routing path.
Intermediate per-path states are eliminated thanks to source routing.
A Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of
segments (i.e., instructions) that represent a source-routed policy.
The headend node is said to steer a flow into an SR Policy. The
packets steered into an SR Policy have an ordered list of segments
associated with that SR Policy written into them.
[RFC8402] defines an SRv6 Segment Identifier (SID) as an IPv6 address
explicitly associated with the segment. When an SRv6 SID is in the
Destination Address field of an IPv6 header of a packet, it is routed
through transit nodes in an IPv6 network as an IPv6 address.
The network programming paradigm for SRv6 is specified in [RFC8986].
It describes how any behavior can be bound to a SID and how any
network program can be expressed as a combination of SIDs. It also
describes several well-known behaviors that can be bound to SRv6
SIDs.
Gong, et al. Expires 29 August 2026 [Page 2]
Internet-Draft Advertise SRv6 Locator by ND February 2026
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned
an SRv6 Locator, and segment IDs are generated within the address
space of this SRv6 Locator. This document describes a method of
advertising SRv6 locator to neighboring SRv6 Segment Endpoint nodes
through IPv6 Neighbor Discovery protocol.
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
This document leverages the terms defined in [RFC4861] and [RFC8986].
The reader is assumed to be familiar with this terminology.
2. Motivation and Applicability
The SRv6 locator is typically distributed within a network domain
using IGP or BGP protocols, enabling other nodes to steer traffic
towards the endpoint. However, there are deployment scenarios where
an SRv6 segment endpoint (e.g., a server host, a lightweight CPE
device) cannot or should not run a complex routing protocol suite.
Manually configuring static routes for each such endpoint on the
network side is operationally burdensome and does not scale. The
following two typical scenarios illustrate this challenge:
* Scenario 1: Deploying SRv6 on Hosts in a Data Center
+----+ +------+ IGP +------+BGP +------+
|Host+-----+Access+-----+ Spine+----+ Core +
+----+ +------+ +------+ +------+
Figure 1
As shown in Figure 1, the SRv6 network comprises Host, Access, Spine,
and Core segments. Information is exchanged between Access and Spine
through IGP, and between Spine and Core using BGP.
Gong, et al. Expires 29 August 2026 [Page 3]
Internet-Draft Advertise SRv6 Locator by ND February 2026
The SRv6 Locator information is transmitted between Access and Spine
using the IGP protocol, and between Spine and Core using the BGP
protocol. However, since Hosts generally do not support complex
routing protocols, they cannot automatically transmit their SRv6
Locator information to the devices.This limitation complicates the
deployment of SRv6 networks.
* Scenario 2: Static Manual Configuration at Customer Edges
Metropolitan area network
+---------------------------+
| |
+------+ +------+ | +-----+ +------+ |
|Host1 +-----+ CPE1 +----+--+BRAS1+--------+ CR1 | |
+------+ +------+ | +-----+ +---+--+ |
| | |
+---------------------+-----+
|
+--------+-------------+
| |
| Backbone Network |
| |
+--------+-------------+
|
+---------------------+-----+
| | |
+------+ +------+ | +-----+ +--+---+ |
|Host2 +-----+ CPE2 +----+--+BRAS2+---------+ CR2 | |
+------+ +------+ | +-----+ +------+ |
+---------------------------+
Figure 2
In IP networks, customer provider edge (CPE) devices often do not
support an IGP protocol, which makes it impossible to advertise SRv6
locator routes for SRv6 Segment Endpoint Nodes through IGP. As shown
in Figure 2, SIDs can only be configured manually on CPEs, and SRv6
Locator routes can only be statically distributed, leading to
operational overhead.
This document addresses this gap by specifying a lightweight method
for SRv6 locator advertisement using the IPv6 Neighbor Discovery
protocol.The key advantages are:
o Zero Additional Protocol Stack: Leverages the existing, mandatory
IPv6 ND stack present on all IPv6 nodes, imposing no new protocol
implementation burden on simple endpoints.
Gong, et al. Expires 29 August 2026 [Page 4]
Internet-Draft Advertise SRv6 Locator by ND February 2026
o Operational Simplicity: Allows network operators to bring SRv6
endpoints into the routing domain without configuring routing
protocols or numerous static routes on the access router.
o Scalable Signaling: ND provides an efficient, link-local signaling
mechanism suitable for a large number of endpoints on a shared
segment.
Applicability Scope: The mechanism defined in this document is
designed for use within a single, trusted, and administratively
controlled SR domain, as illustrated in the scenarios above. Primary
use cases include:
o Data center networks (Figure 1) where servers (hosts) are under the
control of the same operator as the network fabric.
o Managed access or enterprise networks (Figure 2) where CPE devices
are provisioned and secured by the network operator.
It is NOT RECOMMENDED for use in environments where attached nodes
are untrusted (e.g., general public Internet access).
3. Process of Advertising SRv6 Locator by IPv6 ND
By extending the Neighbor Solicit (NS) and Neighbor Advertisement
(NA) packets of the IPv6 Neighbor Discovery protocol to carry SRv6
locator information, SRv6 segment endpoint nodes can advertise their
own SRv6 locator information to neighboring SRv6 nodes, and can also
obtain the SRv6 locator information of neighboring SRv6 nodes,
thereby achieving the exchange of SRv6 locator information and
facilitating the deployment of SRv6.
Taking the scenario of deploying SRv6 on a host in Section 1 as an
example, illustrate the process flow of exchanging SRv6 Locator
information through IPv6 ND.
By extending the IPv6 ND protocol to carry SRv6 Locator information,
Hosts and Access devices can exchange all SRv6 Locator information
within an SRv6 network, facilitating the deployment of SRv6.
The SRv6 locators are advertised in IPv6 ND NS and NA packets between
the host and access, and are advertised via IGP within the domain.
This information is collected by the controller using NETCONF or BGP-
LS.
Gong, et al. Expires 29 August 2026 [Page 5]
Internet-Draft Advertise SRv6 Locator by ND February 2026
+----------+ BGP-LS
|Controller|<-----------------+
+----------+ |
^ ^ |
NETCONF | | NETCONF |
| +----------+ |
| | |
FC00:0:11::/48 | | |
+----+ +------+ IGP +------+BGP +------+
|Host+-----+Access+-----+ Spine +---+ Core +
+----+ +------+ +------+ +------+
^ ^
| |
+---- ND ---+
SRv6 Locator
Figure 3
The process, illustrated in Figure 3, is as follows: (1)An SRv6
locator is configured on the Host.
(2)The Host advertises its SRv6 locator(FC00:0:11::/48) and
capability in IPv6 ND packets (NS/NA) to the Access router.
(3)The Access router receives the ND packets, extracts and validates
the SRv6 locator information(FC00:0:11::/48).
(4)Using IGP, the Access router re-advertises the learned SRv6
locator to the Spine device.To enhance scalability in deployments
with a large number of endpoints, the Access router MAY aggregate
multiple fine-grained locators (e.g., into a shorter prefix) before
advertising.This design ensures that the fine-grained locator
information from many endpoints is contained at the edge, while the
core routing infrastructure deals only with aggregated prefixes.
(5)The Spine device learns the SRv6 locator (FC00:0:11::/48) route
through IGP.
(6)A BGP neighbor relationship is established between the Spine and
Core devices, and the learned SRv6 locator (FC00:0:11::/48) is sent
to the Core using BGP-LS routes.
(7)The Core device learns the SRv6 locator (FC00:0:11::/48) via BGP-
LS.
(8)A BGP neighbor relationship is established between the Core device
and the controller, and the SRv6 locator (FC00:0:11::/48) is sent to
the controller via BGP-LS routes.
Gong, et al. Expires 29 August 2026 [Page 6]
Internet-Draft Advertise SRv6 Locator by ND February 2026
4. Extension of IPv6 Neighbor Discovery Options
4.1. Source SRv6 Locator Information Option
The Source SRv6 Locator Information (SSLI) option is used to
advertise the SRv6 locator information of the sending node to IPv6
neighbor.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |R|R|R|R| MTID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC Size | Locator (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
* Type: 8 bits, identifier of the type of option. The value is TBA
by IANA.
* Length: 8 bits, unsigned integer. The length of the option
(including the type and length fields) in units of 8 octets. The
value 0 is invalid. Nodes MUST silently discard an ND packet that
contains an option with length zero.
* R: 4 bits, reserved field. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
* MTID: 12 bits, Multi-Topology Identifier.
* Metric: 32 bits, Cost.
* Flags: 8 bits, Reserved.
* Algorithm: 8 bits Algorithm:
* - 0: Shortest Path First (SPF).
* - 1: Strict Shortest Path First (Strict SPF).
* LOC Size: 8 bits, Locator Length.
Gong, et al. Expires 29 August 2026 [Page 7]
Internet-Draft Advertise SRv6 Locator by ND February 2026
* Locator (variable): Variable length, indicates the advertised SRv6
Locator.
* Sub-TLVs (variable): Variable length, contains Sub-TLVs such as
SRv6 End SID Sub-TLV.
The option only may appear in Neighbor Solicit message and Neighbor
Advertisement message.
Neighbor Solicit message and Neighbor Advertisement message can
include zero or more Source SRv6 Locator Information options.If
multiple SRv6 Locators need to be advertised, multiple Source SRv6
Locator Information options MUST be encapsulated in the same Neighbor
Discovery message.The Source SRv6 Locator Information
Option should be padded when necessary to ensure that it end on its
natural 64-bit boundary.
Receivers MUST silently ignore the option if they can't recognize and
continue processing the message.
4.2. Source SRv6 Capability Option
To support the SRv6 functionality, the source node also needs to
advertise SRv6-related capabilities through IPv6 ND packets.The
Source SRv6 Capability (SSC) option is used to advertise the SRv6
capability information of the sending node to IPv6 neighbor.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* Type: 8 bits, identifier of the type of option. The value is TBA
by IANA.
* Length: 8 bit, unsigned integer. The length of the option
(including the type and length fields) in units of 8 octets. The
value 0 is invalid. Nodes MUST silently discard an ND packet that
contains an option with length zero.
* Flags: 8 bits, Reserved.
Gong, et al. Expires 29 August 2026 [Page 8]
Internet-Draft Advertise SRv6 Locator by ND February 2026
* Sub-TLVs: Variable length, contains Sub-TLVs such as MSD sub-TLV.
For optional MSD sub-sub-TLVs, the format is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* sub-Type: 8 bits, The sub-TLV Type value for MSD is TBA.
* Length: 8 bits, variable.
* MSD-Type: 8 bits.
* MSD-Value: 8 bits.
The option only may appear in Neighbor Solicit message and Neighbor
Advertisement message.
Neighbor Solicit message and Neighbor Advertisement message can only
include a maximum of one Source SRv6 Capability option. The Source
SRv6 Capability Option should be padded when necessary to ensure that
it end on its natural 64-bit boundary.
Receivers MUST silently ignore the option if they can't recognize and
continue processing the message.
5. IANA Considerations
IANA is asked to assign a new value for the "IPv6 Neighbor Discovery
Option Formats" registry under the heading "Internet Control Message
Protocol version 6 (ICMPv6) Parameters", as follows:
Gong, et al. Expires 29 August 2026 [Page 9]
Internet-Draft Advertise SRv6 Locator by ND February 2026
+========+========================================+===============+
| Value | Description | Reference |
+--------+----------------------------------------+---------------+
| TBA | Source SRv6 Locator Information Option | This document |
+--------+----------------------------------------+---------------+
| TBA | Source SRv6 Capability Option | This document |
+--------+----------------------------------------+---------------+
Table 1
6. Security Considerations
The security considerations of IPv6 Neighbor Discovery [RFC4861]
fully apply. This specification introduces new ND options that carry
routing information (SRv6 locators), and therefore MUST be used
within a well-defined trust boundary. The mechanism defined in this
document is designed for use within a single, trusted, and
administratively controlled SRv6 domain. This domain is a network
segment or realm where:
o All nodes (including hosts or CPEs that advertise SRv6 locators)
are under the control of a single administrative authority.
o The software and configuration of these endpoints are authorized
and managed by the network operator (e.g., they are considered
managed network edge devices, not untrusted end-user devices).
o Access to the link layer is controlled to prevent unauthorized
nodes from attaching.
Primary applicable scenarios include operator-controlled data centers
(Scenario 1 in Section 2) and managed access networks (Scenario 2 in
Section 2).It is NOT RECOMMENDED for use in environments where
attached nodes are not trusted (e.g., general Internet access
points).
7. 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>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>.
Gong, et al. Expires 29 August 2026 [Page 10]
Internet-Draft Advertise SRv6 Locator by ND February 2026
[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>.
[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>.
[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>.
Authors' Addresses
Liyan Gong
China Mobile
China
Email: gongliyan@chinamobile.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Acee Lindem
Arrcus, Inc.
United States of America
Email: acee.ietf@gmail.com
Gong, et al. Expires 29 August 2026 [Page 11]