SPRING W. Cheng Internet Draft R. Han Intended status: Standards Track China Mobile Expires: June 05, 2025 C. Lin Y. Qiu New H3C Technologies December 04, 2025 Distribute SRv6 Locator by IPv6 Stateless Address Autoconfiguration draft-cheng-spring-stateless-nd-srv6-locator-02 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 IPv6 stateless address autoconfiguration. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on June 05, 2026. Cheng, et al. Expire June, 2026 [Page 1] Internet-Draft Distribute SRv6 Locator by NDRA December 2025 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Cheng, et al. Expires June, 2026 [Page 2] Internet-Draft Distribute SRv6 Locator by NDRA December 2025 Table of Contents 1. Introduction...................................................4 1.1. Requirements Language.....................................5 2. Terminology....................................................5 3. Scenario for SRv6 Locator......................................5 4. Extension of IPv6 Neighbor Discovery Options...................7 5. Process of Advertising SRv6 Locator by Router Advertisement....8 5.1. Router Behavior...........................................9 5.2. Host Behavior............................................10 6. IANA Considerations...........................................10 7. Security Considerations.......................................11 8. Acknowledgements..............................................11 9. References....................................................11 9.1. Normative References.....................................11 9.2. Informative References...................................11 Authors' Addresses...............................................12 Cheng, et al. Expires June, 2026 [Page 3] Internet-Draft Distribute SRv6 Locator by NDRA December 2025 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. An SRv6 SID [RFC8986] is as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). L, the locator length, is flexible, and an operator is free to use the locator length of their choice. F and A may be any value as long as L+F+A <= 128. A locator may be represented as B:N where B is the SRv6 SID block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the identifier of the parent node instantiating the SID. When the LOC part of the SRv6 SIDs is routable, it leads to the node, which instantiates the SID. The SRv6 locator can be distributed to other IPv6 nodes within the SRv6 domain through IGP advertisement. This allows other nodes to learn the locator's route. The SRv6 Segment Endpoint Node then allocates SIDs with various behaviors based on its locator. In IP network 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. In such scenarios, SIDs can only be configured manually on CPEs, and SRv6 Locator routes can only be statically distributed. To address this issue, this document proposes a method of dynamically advertising SRv6 locators to SRv6 Segment Endpoint Nodes through IPv6 stateless address configuration method. It follows the existing process of IPv6 stateless address configuration, simplifying the allocation of SRv6 locators and route distribution. Cheng, et al. Expires June, 2026 [Page 4] Internet-Draft Distribute SRv6 Locator by NDRA December 2025 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 [RFC4861] and [RFC8986]. The reader is assumed to be familiar with this terminology. 3. Scenario for SRv6 Locator The application scenario for obtaining SRv6 Locator through IPv6 stateless address autoconfiguration is similar to that of [I-D.ietf- spring-dhc-distribute-srv6-locator-dhcp]. In the IP backbone network, 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, access network devices (CPE) 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 CPE must be operator-managed and is only applicable when different arms of the same company operate their portions of the network separately, but must trust each other. Cheng, et al. Expires June, 2026 [Page 5] Internet-Draft Distribute SRv6 Locator by NDRA December 2025 Metropolitan area network +---------------------------+ | | +------+ +------+ | +-----+ +------+ | |Host1 +-----+ CPE1 +----+--+BRAS1+--------+ CR1 | | +------+ +------+ | +-----+ +---+--+ | | | | +---------------------+-----+ | +--------+-------------+ | | | Backbone Network | | | +--------+-------------+ | +---------------------+-----+ | | | +------+ +------+ | +-----+ +--+---+ | |Host2 +-----+ CPE2 +----+--+BRAS2+---------+ CR2 | | +------+ +------+ | +-----+ +------+ | +---------------------------+ 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, so CPEs usually apply for IPv6 subnet prefix through DHCPv6 or stateless address autoconfiguration from BRAS. 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. However, 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. Cheng, et al. Expires June, 2026 [Page 6] Internet-Draft Distribute SRv6 Locator by NDRA December 2025 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. To solve the difficulties this document proposes a method to allocate SRv6 locators to CPE through IPv6 stateless address autoconfiguration. 4. Extension of IPv6 Neighbor Discovery Options The SRv6 Locator option is used to specify the SRv6 locators that are used for stateless address autoconfiguration. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Leng