Distribute SRv6 Locator by DHCP
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-10
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 10038.
|
|
|---|---|---|---|
| Authors | Weiqiang Cheng , Ruibo Han , Changwang Lin , Daniel Voyer , Geng Zhang | ||
| Last updated | 2025-10-13 (Latest revision 2025-07-04) | ||
| Replaces | draft-cheng-spring-distribute-srv6-locator-by-dhcp | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | Nick Buraglio | ||
| Shepherd write-up | Show Last changed 2025-09-09 | ||
| IESG | IESG state | Became RFC 10038 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | aretana.ietf@gmail.com, buraglio@forwardingplane.net |
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-10
SPRING W. Cheng, Ed.
Internet-Draft R. Han
Intended status: Standards Track China Mobile
Expires: 16 April 2026 C. Lin, Ed.
New H3C Technologies
D. Voyer
Bell Canada
G. Zhang
China Mobile
13 October 2025
Distribute SRv6 Locator by DHCP
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-10
Abstract
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 for
assigning SRv6 Locators to SRv6 Segment Endpoint Nodes through
DHCPv6.
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 16 April 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.
Cheng, et al. Expires 16 April 2026 [Page 1]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. DHCPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Identity Association for SRv6 Locator Option . . . . . . 5
4.2. IA Locator Option . . . . . . . . . . . . . . . . . . . . 8
5. Process of Assigning SRv6 Locator . . . . . . . . . . . . . . 10
5.1. Procedure of SRv6 Locator . . . . . . . . . . . . . . . . 10
5.2. Advertisement of SRv6 Locator Route . . . . . . . . . . . 12
5.3. DHCP Client Behavior . . . . . . . . . . . . . . . . . . 12
5.4. DHCP Server Behavior . . . . . . . . . . . . . . . . . . 14
5.5. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . 15
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
6.1. New H3C Technologies . . . . . . . . . . . . . . . . . . 16
6.2. Raisecom Corporation . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The Segment Routing (SR) architecture [RFC8402] specifies how a node
can steer a packet using an ordered list of instructions called
segments. These segments are identified using Segment Identifiers
(SIDs).
SR can be instantiated on the IPv6 data plane through the use of the
Segment Routing Header (SRH) defined in [RFC8754]. SR instantiation
on the IPv6 data plane is referred to as SRv6.
Cheng, et al. Expires 16 April 2026 [Page 2]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
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.
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 for
assigning SRv6 Locators to SRv6 Segment Endpoint Nodes through
DHCPv6.
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
This document leverages the terms defined in
[I-D.ietf-dhc-rfc8415bis] and [RFC8986]. The reader is assumed to be
familiar with this terminology.
3. Motivation
Telecom providers can use its IP Metro and Backbone networks to
establish connectivity between access users who are located in
different regions.
As shown in Figure 1, in the IP backbone network, access network
devices are deployed for access users in different regions. This
deployment assumes that all of the relevant components in Figure 1
are part of a single trusted SR domain. The IP network customer
provider edge (CPE) must be managed by the operator providing
services or by a trusted partner.
Cheng, et al. Expires 16 April 2026 [Page 3]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
Metropolitan area network
+---------------------------+
| |
+------+ +------+ | +-----+ +-------+ |
|Host1 +-----+ CPE1 +----+--+BRAS1+--------+Router1| |
+------+ +------+ | +-----+ +---+---+ |
| | |
+---------------------+-----+
|
+--------+-------------+
| |
| Backbone Network |
| |
+--------+-------------+
|
+---------------------+-----+
| | |
+------+ +------+ | +-----+ +--+----+|
|Host2 +-----+ CPE2 +----+--+BRAS2+---------+Router2||
+------+ +------+ | +-----+ +-------+|
+---------------------------+
Figure 1: Telecom IPv6 Network
CPEs for access users are connected to the local metropolitan area
network (MAN) in various ways. CPEs are responsible for assigning
addresses to access users by requesting DHCPv6 Prefix Delegation (PD)
from a DHCPv6 server, as specified in Section 6.3 of
[I-D.ietf-dhc-rfc8415bis]. The DHCPv6 server is usually enabled on
or relayed by the BRAS(Broadband Remote Access Server).
After the DHCPv6 server allocates PD, BRAS will add a network route
corresponding to PD to local routing table and distribute the network
route to the upstream routers.
In this network, operators hope to achieve interconnection between
access users through End-to-End SRv6 tunnels. Taking the service
traffic from Host1 to Host2 as an example, CPE1 is the SRv6 ingress
node and CPE2 is the SRv6 egress node. The SRv6 Locator should be
configured on CPE. Other devices in the network learn the SRv6
Locator route of the CPE.
At the same time, SRv6 policies needs to be configured on CPEs to
steer the service traffic between CPEs to the specified SRv6
forwarding path. The SRv6 policy can be manually configured
statically or issued through the controller, and its specific
configuration method is out of the scope of this document.
Cheng, et al. Expires 16 April 2026 [Page 4]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
However, due to the following reasons, it is difficult to achieve
these requirements currently.
* The configuration is very complex.
In Metro network, the number of CPEs is very large and widely
distributed geographically. Moreover, the mobility requirements of
CPE are relatively high, and the access location of the same CPE
often changes, so its IPv6 address cannot be fixed.
At present, an SRv6 Locator can only be configured on each CPE
through a controller or the Command Line Interface (CLI), which
increases the configuration complexity.
* SRv6 Locator routes cannot be dynamically distributed.
CPE can be connected to the BRAS of local MAN through various types
of networks, such as leased line, optical fiber, etc. Due to the
diversity of connections, IGP is usually only enabled within the MAN,
that is, IGP will not be deployed between CPE and BRAS.
As a result, the SRv6 Locator route of CPE could not be distributed
to the BRAS node through IGP, and the static route can only be
configured manually on the BRAS or the controller. However, CPE and
BRAS often belong to different administration domains. Configuring
routes to CPE on BRAS increases the cost and workload of
communication and coordination.
To solve these difficulties this document proposes a method to
allocate SRv6 Locators to CPE through DHCPv6 and distribute SRv6
Locator routes by using the workflow of DHCPv6.
4. DHCPv6 Extensions
4.1. Identity Association for SRv6 Locator Option
The Identity Association for SRv6 Locator (IA_SRV6_LOCATOR) option is
used to carry an IA_SRV6_LOCATOR, the parameters associated with the
IA_SRV6_LOCATOR, and the SRv6 Locator associated with the
IA_SRV6_LOCATOR.
The IA_SRV6_LOCATOR option can be carried in DHCPv6 Solicit,
Advertise, Request, Reply, Renew, and Release messages.
The format of the IA_SRV6_LOCATOR option is:
Cheng, et al. Expires 16 April 2026 [Page 5]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_SRV6_LOCATOR | Option-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IA_SRV6_LOCATOR-Options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Identity Association for SRv6 Locator Option Format
Where:
- Option-Code: OPTION_IA_SRV6_LOCATOR, the option code for the
Identity Association for SRv6 Locator. The current value early
assigned by IANA is 149.
- Option-Len: 12 + length of IA_SRV6_LOCATOR-Options field.
- IAID: The unique identifier for this IA_SRV6_LOCATOR. The IAID
MUST be unique among the identifiers for all of this client's
IA_SRV6_LOCATORs. The number space for IA_SRV6_LOCATOR IAIDs
is separate from the number space for other IA option types
(i.e., IA_TA, IA_NA and IA_PD). A 4-octet field containing an
unsigned integer.
- T1: The time interval after which the client should contact the
server from which the SRv6 Locators in the IA_SRV6_LOCATOR were
obtained to extend the lifetimes of the SRv6 Locators to the
IA_SRV6_LOCATOR. T1 is a time duration relative to the message
reception time expressed in units of seconds. A 4-octet field
containing an unsigned integer.
- T2: The time interval after which the client should contact any
available server to extend the lifetimes of the SRv6 Locators
assigned to the IA_SRV6_LOCATOR. T2 is a time duration
relative to the message reception time expressed in units of
seconds. A 4- octet field containing an unsigned integer.
- IA_SRV6_LOCATOR-Options: Options associated with this
IA_SRV6_LOCATOR. A variable-length field (12 octets less than
the value in the Option-Len field).
Cheng, et al. Expires 16 April 2026 [Page 6]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
The IA_SRV6_LOCATOR-Options field encapsulates those options that are
specific to this IA_SRV6_LOCATOR. For example, all of the IA Locator
options (see Section 4.2) carrying the SRv6 Locators associated with
this IA_SRV6_LOCATOR are in the IA_SRV6_LOCATOR- Options field.
An IA_SRV6_LOCATOR option may only appear in the options area of a
DHCP message. A DHCP message may contain multiple IA_SRV6_LOCATOR
Options (though each must have a unique IAID).
The status of any operations involving this IA_SRV6_LOCATOR is
indicated in a Status Code option (see Section 21.13 of
[I-D.ietf-dhc-rfc8415bis]) in the IA_SRV6_LOCATOR-Options field.
Note that an IA_SRV6_LOCATOR has no explicit "lifetime" or "lease
length" of its own. When the valid lifetimes of all of the SRv6
Locators in an IA_SRV6_LOCATOR have expired, the IA_SRV6_LOCATOR can
be considered as having expired. T1 and T2 fields are included to
give the server explicit control over when a client should contact
the server about a specific IA_SRV6_LOCATOR.
In a message sent by a client to a server, the T1 and T2 fields
SHOULD be set to 0. The server MUST ignore any values in these
fields in messages received from a client.
In a message sent by a server to a client, the client MUST use the
values in the T1 and T2 fields for the T1 and T2 timers, unless
values in those fields are 0. The values in the T1 and T2 fields are
the number of seconds until T1 and T2.
The server selects the T1 and T2 times to allow the client to extend
the lifetimes of any SRv6 Locators in the IA_SRV6_LOCATOR before the
lifetimes expire, even if the server is unavailable for some short
period of time. Recommended values for T1 and T2 are 0.5 and 0.8
times the shortest preferred lifetime of the SRv6 Locators in the
IA_SRV6_LOCATOR that the server is willing to extend, respectively.
If the time at which the SRv6 Locators in an IA_SRV6_LOCATOR are to
be renewed is to be left to the discretion of the client, the server
sets T1 and T2 to 0. The client MUST follow the rules defined in
Section 14.2 of [I-D.ietf-dhc-rfc8415bis].
If a client receives an IA_SRV6_LOCATOR with T1 greater than T2 and
both T1 and T2 are greater than 0, the client discards the
IA_SRV6_LOCATOR option and processes the remainder of the message as
though the server had not included the IA_SRV6_LOCATOR option.
Cheng, et al. Expires 16 April 2026 [Page 7]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
4.2. IA Locator Option
The IA Locator option is used to specify an SRv6 Locator associated
with an IA_SRV6_LOCATOR. The IA Locator option MUST be encapsulated
in the IA_SRV6_LOCATOR-Options field of an IA_SRV6_LOCATOR option
(see Section 4.1). The terms Locator Block and Locator Node
correspond to the B and N parts, respectively, of the SRv6 Locator
that is defined in Section 3.1 of [RFC8986].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IALOCATOR | Option-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB-Len | LN-Len | Fun-Len | Arg-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. SRv6-Locator .
. (up to 16 octets) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IALocator-Options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IA Locator Option Format
Where:
- Option-code: OPTION_IALOCATOR, the option code for
IA_SRv6_Locator option. The current value early assigned by
IANA is 150.
- Option-Len: 28 + length of IALocator-Options field.
- Preferred-lifetime: The preferred lifetime for the SRv6 Locator
in the option, expressed in units of seconds. A value of
0xffffffff represents "infinity" (see Section 7.7 of
[I-D.ietf-dhc-rfc8415bis]). A 4-octet field containing an
unsigned integer.
- Valid-lifetime: The valid lifetime for the SRv6 Locator in the
option, expressed in units of seconds. A value of 0xffffffff
represents "infinity". A 4-octet field containing an unsigned
integer.
Cheng, et al. Expires 16 April 2026 [Page 8]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
- LB-Len: SRv6 SID Locator Block (LB) length in bits. A 1-octet
unsigned integer.
- LN-Len: SRv6 SID locator Node (LN) length in bits. A 1-octet
unsigned integer.
- Fun-Len: SRv6 SID function (FUNCT) length in bits. A 1-octet
unsigned integer.
- Arg-Len: SRv6 SID arguments (ARG) length in bits. A 1-octet
unsigned integer.
- SRv6-Locator: 0-16 octets. This field encodes the SRv6
Locator. The SRv6 Locator is encoded in the minimal number of
octets for the given number of bits. Trailing bits MUST be set
to zero and ignored when received.
- IALocator-Options: Options associated with this SRv6 Locator.
A variable-length field (determined by subtracting the length
of the SRv6-Locator from the Option-Len minus 12). The Status
code "NoSRv6LocatorAvail" indicate the server has no locators
available to assign to the IA_SRv6_Locator(s).
The SRv6 SID Locator length (LOC-Len) is LB-Len plus LN-Len.
The sum of LB-Len, LN-Len, Fun-Len, and Arg-Len MUST NOT exceed 128
bits. If the sum exceeds 128 bits, the IA_SRV6_LOCATOR option MUST
be marked as invalid, and the remainder of the message SHOULD be
processed as if the packet did not include this option.
The values in the preferred-lifetime and valid-lifetime fields are
the number of seconds remaining in each lifetime. The value of
0xffffffff for the preferred lifetime or the valid lifetime is taken
to mean "infinity" and should be used carefully. The details about
the use of lifetime values for assigned SRv6 Locators are the same as
the ones specified for prefix delegation in Section 18.2.10.1 of
[I-D.ietf-dhc-rfc8415bis].
An IA Locator option may appear only in an IA_SRV6_LOCATOR option.
More than one IA Locator option can appear in a single
IA_SRV6_LOCATOR option.
The status of any operations involving this IA_SRv6_Locator option is
indicated in a Status Code option (see Section 21.13 of
[I-D.ietf-dhc-rfc8415bis]) in the IALocator-Options field.
Cheng, et al. Expires 16 April 2026 [Page 9]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
5. Process of Assigning SRv6 Locator
This document assumes that a single transaction for all of the IA
options required on an interface is used, as recommended in
Section 18.1 of [I-D.ietf-dhc-rfc8415bis].
5.1. Procedure of SRv6 Locator
Consistent with Prefix Delegation mechanism
[I-D.ietf-dhc-rfc8415bis], the CPE obtains an SRv6 Locator via
DHCPv6. The key message exchanges involved are Solicit, Request,
Advertise, and Reply. Once the DHCPv6 Server assigns an SRv6 Locator
to the CPE, it automatically adds the associated SRv6 Locator routes.
Figure 2 illustrates the process of SRv6 Locator allocation through
DHCPv6.
CPE DHCP Server
v v
| |
| |
____________ |\ |
____________ | +-----------+ |
| Solicit \|
| EmptyIALocator|
| |
| /|
| +----------+ |
| / Advertise |
|/ IALocator |
| |
|\ |
| +-----------+ |
| Request \|
| IALocator |
| /|
| +----------+ |
| / Reply |
|/ IALocator |
end of | |
4-message | |
exchange | | Issue Locator Route Locally
Use Locator to | | Distribute Locator Route
alloc SRv6 SID | |
Figure 4: SRv6 Locator Exchange
Cheng, et al. Expires 16 April 2026 [Page 10]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
As specified in Sections 18.2.1 of [I-D.ietf-dhc-rfc8415bis], DHCP
client sends a Solicit message containing an IA_SRV6_LOCATOR option
to request a locator. The client may include its preferred locator
value within the IA_SRV6_LOCATOR option.
DHCP Server processes the Solicit message, assigns a locator to the
client, and returns the allocated locator in an Advertise message
with the IA_SRV6_LOCATOR option.
As specified in Sections 18.2.2 of [I-D.ietf-dhc-rfc8415bis], upon
receiving the Advertise message, client accepts the assigned locator
and sends a Request message with the IA_SRV6_LOCATOR option to
confirm the requested locator.
The server processes the Request message, confirms the locator
assignment, and responds with a Reply message containing the
IA_SRV6_LOCATOR option with the allocated locator.
As described in Sections 18.2.4 of [I-D.ietf-dhc-rfc8415bis], client
periodically sends a Renew message with the IA_SRV6_LOCATOR option to
refresh the lease. The server processes the Renew message, updates
the lease, and replies with a Reply message containing the
IA_SRV6_LOCATOR option.
As described in Sections 18.2.5 of [I-D.ietf-dhc-rfc8415bis], if the
client does not receive a Reply message before the T2 timer expires,
it sends a Rebind message with the IA_SRV6_LOCATOR option to attempt
lease renewal.
If the server responds with a Reply message, the client retains its
allocated locator.
If no response is received, the client considers the lease expired
and restarts the process by sending a new Solicit message.
As described in Sections 18.2.7 of [I-D.ietf-dhc-rfc8415bis], if the
client is about to go offline, it sends a Release message with the
IA_SRV6_LOCATOR option to relinquish the locator.
Upon receiving the Release message, the server MUST removes the lease
and frees the locator, making it available for allocation to other
clients.
For the advertisement of SRv6 locator routes, if the DHCP Relay or
DHCP Server device that assigns SRv6 Locators to CPEs is also a BRAS
device, it MAY locally advertise the CPE's SRv6 Locator route via the
IGP protocol, enabling other SRv6 nodes to obtain the CPE's SRv6
Locator route.
Cheng, et al. Expires 16 April 2026 [Page 11]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
5.2. Advertisement of SRv6 Locator Route
This section describes the processing of SRv6 Locator routes.
As shown in Figure 5, when a BRAS device (functioning as a DHCP relay
or DHCP server) receives an SRv6 Locator allocation request from a
client, it MAY assign an SRv6 Locator to the client and install a
corresponding SRv6 Locator route locally. The next hop of this route
SHOULD point to the requesting client. The BRAS MAY then advertise
this route via traditional routing protocols (e.g., an IGP) to allow
other routers to learn it.
Upon receiving an SRv6 Locator release request from the client, the
BRAS MUST release the allocated SRv6 Locator, remove the local SRv6
Locator route, and withdraw the previously advertised SRv6 Locator
route via the IGP.
Client---------------BRAS(Relay/Server)-------------Router
Alloc Locator --> Add SRv6 locator route
Advertise SRv6 Locator route -->
Release Locator--> Del SRv6 locator route
Withdraw SRv6 Locator route -->
Figure 5: Advertisement of SRv6 Locator Route
5.3. DHCP Client Behavior
A client uses the Solicit message to discover DHCPv6 servers
configured to assign leases or return other configuration parameters
on the link to which the client is attached.
A client uses Request, Renew, Rebind, Release and Decline messages
during the normal lifecycle of SRv6 Locator assignment.
In a message sent by a client to a server, the preferred-lifetime and
valid-lifetime fields SHOULD be set to 0. The server MUST ignore any
received values in these lifetime fields.
The client SHOULD NOT send an IA_SRv6_Locator option with 0 in the
"LB-Len" and "LN-Len" fields (and an unspecified value (::) in the
"SRv6-Locator" field). The client MAY send non-zero values in the
"LB-Len" and "LN-Len" fields, and the unspecified value (::) in the
"SRv6-Locator" field to indicate a preference for the size of the
SRv6 Locator to be assigned. The LOC-Len (LB-Len + LN-Len) hint
provided by a client is similar to the prefix-length hint in an
IA_PD. Clients and servers are expected to follow the guidance
provided in [RFC8168].
Cheng, et al. Expires 16 April 2026 [Page 12]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
The client MUST discard any SRv6 Locators for which the preferred
lifetime is greater than the valid lifetime.
The process of requesting an SRv6 Locator is the same as that of
requesting prefixes. When requesting an SRv6 Locator, the DHCPv6
client sends a request message carrying the IA_SRV6_LOCATOR option to
the DHCPv6 server.
Upon the receipt of a valid Reply message with IA_SRV6_LOCATOR option
in response to a Solicit with a Rapid Commit option, Request, Renew,
or Rebind message, the client MUST process the Reply message
according to the requirements of Section 18.2.10 of
[I-D.ietf-dhc-rfc8415bis], and configure the assigned SRv6 Locator in
the client device automatically.
After obtaining the SRv6 Locator assigned by the DHCPv6 server, how
to assign local SRv6 SIDs based on this SRv6 Locator, how to use
multiple assigned SRv6 Locators, and how to advertise these SRv6 SIDs
to the rest of the network are not within the scope of this document.
If the client uses the assigned SRv6 Locator to configure local SRv6
SIDs, the preferred and valid lifetimes of those SRv6 Locators MUST
NOT be longer than the remaining preferred and valid lifetimes
respectively for the assigned SRv6 Locator at any time.
To extend the preferred and valid lifetimes for the assigned SRv6
Locators or obtain new assigned SRv6 Locators, the client sends a
Renew/Rebind message to the server with IA_SRV6_LOCATOR option as
specified in Sections 18.2.4 and 18.2.5 of [I-D.ietf-dhc-rfc8415bis].
If the client no longer uses the SRv6 Locator, the client can
actively send a Release message to notify the server to reclaim SRv6
Locator and delete the corresponding SRv6 Locator. The client MUST
include options containing the IAs for the SRv6 Locators it is
releasing in the IA_SRV6_LOCATOR-options of IA_SRV6_LOCATOR option.
A client can explicitly request multiple SRv6 Locator prefixes by
sending multiple IA_SRV6_LOCATOR options. A client can send multiple
IA_SRV6_LOCATOR options in its initial transmissions. Alternatively,
it can send an extra Request message with additional new
IA_SRV6_LOCATOR options (or include them in a Renew message).
DHCP allows a client to request new SRv6 Locators to be assigned by
sending additional new IA_SRV6_LOCATOR options. However, a typical
operator usually prefers to assign a single, larger prefix. In most
deployments, it is recommended that the client request a larger SRv6
Locator in its initial transmissions rather than request additional
SRv6 Locators later on.
Cheng, et al. Expires 16 April 2026 [Page 13]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
5.4. DHCP Server Behavior
When the server receives a valid Request message or a valid Solicit
message with a Rapid Commit option, the server creates the bindings
for that client according to the server's policy and configuration
information and records the IAs and other information requested by
the client.
The DHCPv6 server treats the SRv6 Locator as the prefix of prefix
pool. Upon the receipt of the IA_SRV6_LOCATOR option, the server
searches SRv6 Locator prefix pool and allocates appropriate SRv6
Locators for the client.
If there is an assignable SRv6 Locator, the server creates the SRv6
Locator binding entry for that client according to the server's
policy and configuration information and constructs a Reply message
that includes an IA_SRV6_LOCATOR option with the SRv6 Locator
information (including LB-Len, LN-Len, Fun-Len, and Arg-Len) assigned
to the client.
When operating as a BRAS device, the DHCPv6 server MAY install a
local SRv6 Locator route pointing to the CPE and advertise this route
via an IGP upon assigning an SRv6 Locator to the CPE.
The IA_SRV6_LOCATOR option is filled with the SRv6 Locator
information assigned to the client. The IA_SRV6_LOCATOR option
populates the SRv6 Locator block length, locator node length,
function length, and arguments length.
Upon receiving the Release message from the client or when the SRv6
Locator lease expires, the server reclaims the SRv6 Locator prefix
resource and deletes the SRv6 Locator binding entry. If the DHCPv6
server functions as a BRAS device, the server also MAY delete the
corresponding SRv6 Locator route locally.
For any IA_SRV6_LOCATOR option in the Request message to which the
server cannot assign any SRv6 Locators, the server MUST return the
IA_SRV6_LOCATOR option in the Reply message with no SRv6 Locator
prefixes in the IA_SRV6_LOCATOR and with a Status Code option
containing status code NoSRv6LocatorAvail in the IA_SRV6_LOCATOR.
After receiving a DHCP message with multiple IA_SRV6_LOCATOR options
at the same time, whether the server can assign multiple SRv6
Locators to the client depends on the server policy, which is out of
scope for this document. Note that the configuration behavior of the
server and client SHOULD be consistent (e.g., "Clients and Servers
SHOULD assign a single locator unless explicitly configured").
Cheng, et al. Expires 16 April 2026 [Page 14]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
5.5. DHCP Relay Agent Behavior
For the scenario described in Section 2, if an external DHCPv6 server
is deployed to allocate SRv6 Locators, the DHCPv6 relay agent service
needs to be enabled on the layer 3 network nodes close to the CPE.
As shown in the figure below, the DHCP relay function is enabled on
the router directly connected to the CPE. This deployment assumes
that all of the relevant components in Figure 6 are part of a single
trusted SR domain.
Client DHCP Relay DHCPv6 Server
+------+ +------+ +------+ +-----------+
| Host +-----+ CPE +-------+Router+-----+ BRAS |
+------+ +------+ +--+---+ +-----------+
|
|
+------+-----+
| Backbone |
| Network |
+------------+
Figure 6: CPE accessed through DHCP relay
When the last DHCPv6 relay agent in the return path to the client
receives DHCPv6 Relay-Reply messages, it extracts the IA_SRV6_LOCATOR
option from the Reply message, and obtains the SRv6 Locator assigned
by the DHCPv6 server according to IA_SRv6_Locator option. The first
DHCPv6 relay agent needs to record the SRv6 Locator assigned by the
DHCPv6 server, including SRv6 Locator information, lifetime, etc. If
the DHCPv6 Relay is directly connected to the CPE device, a
corresponding SRv6 Locator route MAY also be added locally and
advertised via IGP.. The outgoing interface of the route is the
access interface connecting the client.
After receiving the DHCPv6 Release or Decline messages from the
client, or the valid lifetime of SRv6 Locator prefix expires, If the
DHCPv6 relay is a BRAS device, the DHCPv6 relay agent MAY delete the
SRv6 Locator route locally.
6. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to [RFC7942].
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
Cheng, et al. Expires 16 April 2026 [Page 15]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
6.1. New H3C Technologies
* Organization: New H3C Technologies.
* Implementation: H3C CR16000, CR19000 series routers implementation
of Distribute SRv6 Locator by DHCP.
* Description: All sections including all the "MUST" and "SHOULD"
clauses have been implemented in above-mentioned New H3C
Products(running Version 7.1.099 and above).
* Maturity Level: Product
* Coverage: All sections.
* Version: Draft-04
* Licensing: N/A
* Implementation experience: Nothing specific.
* Contact: linchangwang.04414@h3c.com
* Last updated: October 22, 2024
6.2. Raisecom Corporation
* Organization: Raisecom Corporation.
* Implementation: Raisecom's RaizSec-VNF RaizSec-VNF Series SD-WAN
Gateway implementation of Distribute SRv6 Locator by DHCP
Cheng, et al. Expires 16 April 2026 [Page 16]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
* Description: All sections including all the "MUST" and "SHOULD"
clauses have been implemented in Raisecom RaizSec-VNF series SD-
WAN Gateway.
* Maturity Level: GA
* Coverage: ALL
* Version: Draft-04
* Licensing: N/A
* Implementation experience: Nothing specific.
* Contact: jiarongbin@raisecom.com
* Last updated: October 10, 2024
7. IANA Considerations
IANA has early assigned the following new DHCPv6 Option Codes in the
"Option Codes" registry maintained at
https://www.iana.org/assignments/dhcpv6-parameters.
+=======+========================+========+===========+===========+
| Value | Description | Client | Singleton | Reference |
| | | ORO | Option | |
+=======+========================+========+===========+===========+
| 149 | OPTION_IA_SRV6_LOCATOR | NO | No | [ This |
| | | | | Document ]|
+-------+------------------------+--------+-----------+-----------+
| 150 | OPTION_IALOCATOR | NO | No | [ This |
| | | | | Document ]|
+-------+------------------------+--------+-----------+-----------+
Table 1
IANA is requested to assign a value for the following new DHCPv6
Status code in the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters:
* NoSRv6LocatorAvail (TBD)
8. Security Considerations
See Section 23 of [I-D.ietf-dhc-rfc8415bis] and Section 23 of
[RFC7227] for the DHCP security considerations. See [RFC8200] for
the IPv6 security considerations.
Cheng, et al. Expires 16 April 2026 [Page 17]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
As discussed in Section 23 of [I-D.ietf-dhc-rfc8415bis]: DHCP lacks
end-to-end encryption between clients and servers; thus, hijacking,
tampering, and eavesdropping attacks are all possible as a result.
In some network environments, it is possible to secure them, as
discussed later in Section 23 of [I-D.ietf-dhc-rfc8415bis].
If not all parties use this mechanism to obtain an SRv6 Locator from
the DHCPv6 server, there is the possibility of the same SRv6 Locator
being used by more than one device. Note that this issue would exist
on these networks even if DHCP were not used to obtain the SRv6
Locator.
Server implementations SHOULD consider configuration options to limit
the maximum number of SRv6 Locators to allocate (both in a single
request and in total) to a client. However, note that this does not
prevent a bad client actor from pretending to be many different
clients and consuming all available SRv6 Locators.
9. Privacy Considerations
See Section 24 of [I-D.ietf-dhc-rfc8415bis] for the DHCP privacy
considerations.
The SR domain is a trusted domain, as defined in [RFC8402], Sections
2 and 8.2. Having such a well-defined trust boundary is necessary in
order to operate SRv6-based services for internal traffic while
preventing any external traffic from accessing or exploiting the
SRv6-based services. Care and rigor in IPv6 address allocation for
use for SRv6 SID allocations and network infrastructure addresses, as
distinct from IPv6 addresses allocated for end users and systems (as
illustrated in Section 5.1 of [RFC8754]), can provide the clear
distinction between internal and external address space that is
required to maintain the integrity and security of the SRv6 Domain.
When assigning SRv6 Locators to SRv6 Segment Endpoint Nodes using
DHCPv6 as specified in this document, CPEs and BRAS devices MUST
operate within a single trusted SR domain.
10. Acknowledgements
The authors would like to thank Chongfeng Xie, Joel Halpern, Robert
Raszuk, Aihua Liu, Cheng Li, Xuewei Wang, Hao Li, Junjie Wang,
Mengxiao Chen, Fang Gao, Aijun Wang, Xinxin Yi, Shenchao Xu, Yisong
Liu, Xueshun Wang, Min Xiao, Liyan Gong, Linda Dunbar, Quan Xiong,
Adrian Farrel and Bernie Volz for their comments to this document.
11. References
Cheng, et al. Expires 16 April 2026 [Page 18]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
11.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/info/rfc2119>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<https://www.rfc-editor.org/info/rfc7227>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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/info/rfc8200>.
[RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint
Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017,
<https://www.rfc-editor.org/info/rfc8168>.
[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/info/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/info/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/info/rfc8986>.
[I-D.ietf-dhc-rfc8415bis]
Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", Work in Progress, Internet-Draft, draft-ietf-
dhc-rfc8415bis-12, 4 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
rfc8415bis-12>.
Cheng, et al. Expires 16 April 2026 [Page 19]
Internet-Draft Distribute SRv6 Locator by DHCP October 2025
11.2. Informative References
[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/info/rfc8754>.
Contributors
Yuanxiang Qiu
New H3C Technologies
Email: qiuyuanxiang@h3c.com
Authors' Addresses
Weiqiang Cheng (editor)
China Mobile
Email: chengweiqiang@chinamobile.com
Ruibo Han
China Mobile
Email: hanruibo@chinamobile.com
Changwang Lin (editor)
New H3C Technologies
Email: linchangwang.04414@h3c.com
Daniel Voyer
Bell Canada
Email: danvoyerwork@gmail.com
Geng Zhang
China Mobile
Email: zhanggeng@chinamobile.com
Cheng, et al. Expires 16 April 2026 [Page 20]