Skip to main content

Distribute SRv6 Locator by DHCP
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-05

Document Type Active Internet-Draft (spring WG)
Authors Weiqiang Cheng , Ruibo Han , Changwang Lin , Daniel Voyer , Yuanxiang Qiu , Geng Zhang
Last updated 2024-11-14
Replaces draft-cheng-spring-distribute-srv6-locator-by-dhcp
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to aretana.ietf@gmail.com
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-05
SPRING                                                         W. Cheng
Internet Draft                                                   R. Han
Intended status: Standards Track                           China Mobile
Expires: May 15, 2025                                            C. Lin
                                                   New H3C Technologies
                                                               D. Voyer
                                                            Bell Canada
                                                                 Y. Qiu
                                                   New H3C Technologies
                                                               G. Zhang
                                                           China Mobile
                                                      November 15, 2024

                      Distribute SRv6 Locator by DHCP
           draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-05

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 May 15, 2025.

Cheng, et al.             Expire May, 2025                    [Page 1]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

Copyright Notice

   Copyright (c) 2024 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
   2. Terminology....................................................4
   3. Scenario for SRv6 Locator......................................4
   4. DHCPv6 extension...............................................6
      4.1. Identity Association for SRv6 Locator Option..............6
      4.2. IA SRv6 Locator Option....................................8
   5. Process of Assigning SRv6 Locator.............................10
         5.1.1. DHCP Client Behavior................................10
         5.1.2. DHCP Server Behavior................................11
         5.1.3. DHCP Relay Agent Behavior...........................12
   6. Implementation Status.........................................13
      6.1. New H3C Technologies.....................................14
      6.2. Raisecom Corporation.....................................14
   7. IANA Considerations...........................................15
   8. Security Considerations.......................................15
   9. Privacy Considerations........................................16
   10. Acknowledgements.............................................16
   11. References...................................................16
      11.1. Normative References....................................16
      11.2. Informative References..................................17
   Authors' Addresses...............................................18

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

Cheng, et al.             Expires May, 2025                   [Page 2]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   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 assigning SRv6 locators to SRv6 Segment Endpoint Nodes
   through DHCPv6. It follows the existing process of DHCPv6,
   simplifying the allocation of SRv6 locators and route distribution.

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.

Cheng, et al.             Expires May, 2025                   [Page 3]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

2. Terminology

   This document leverages the terms defined in [RFC8415] and
   [RFC8986]. The reader is assumed to be familiar with this
   terminology.

3. Scenario for SRv6 Locator

   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 (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.

                               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 apply for DHCPv6 Prefix

Cheng, et al.             Expires May, 2025                   [Page 4]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   Delegation (PD) from a DHCPv6 server. The DHCPv6 server is usually
   enabled on the BRAS.

   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.

   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 Broadband Remote Access Server (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.

Cheng, et al.             Expires May, 2025                   [Page 5]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   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 extension

4.1. Identity Association for SRv6 Locator Option

   The Identify 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 format of the IA_SRV6_LOCATOR option is:

       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: Identify Association for SRv6 Locator Option Format

   Where:

    - Option-Code: OPTION_IA_SRV6_LOCATOR, the option code for the
      Identify 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.,

Cheng, et al.             Expires May, 2025                   [Page 6]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

      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).

   The IA_SRV6_LOCATOR-Options field encapsulates those options that
   are specific to this IA_SRV6_LOCATOR.  For example, all of the IA
   SRv6 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 [RFC8415])
   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

Cheng, et al.             Expires May, 2025                   [Page 7]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   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 [RFC8415].

   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.

4.2. IA SRv6 Locator Option

   The IA SRv6 Locator option is used to specify an SRv6 locator
   associated with an IA_SRV6_LOCATOR. The IA SRv6 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 SRv6 Locator Option Format

Cheng, et al.             Expires May, 2025                   [Page 8]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   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 [RFC8415]). 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.

    - 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: 1-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 (28 octets less than the value in the
      Option-Len field).

   The SRv6 SID Locator length (LOC-Len) is LB-Len plus LN-Len.

   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 these values for assigned SRv6 locators are the same as
   the ones specified for prefix delegation in Section 18.2.10.1 of
   [RFC8415].

Cheng, et al.             Expires May, 2025                   [Page 9]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   An IA SRv6 Locator option may appear only in an IA_SRV6_LOCATOR
   option. More than one IA SRv6 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
   [RFC8415]) in the IALocator-Options field.

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 [RFC8415].

5.1.1. 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].

   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,
   Confirm, Renew, or Rebind message, the client MUST process the Reply

Cheng, et al.             Expires May, 2025                  [Page 10]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   message according to the requirements of Section 18.2.10 of
   [RFC8415], 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 [RFC8415].

   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.

5.1.2. 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

Cheng, et al.             Expires May, 2025                  [Page 11]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   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.

   The IA_SRV6_LOCATOR option fills 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 BRAS
   device acts as a DHCPv6 server, the server also MUST 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.

5.1.3. 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 4 are part of
   a single trusted SR domain.

Cheng, et al.             Expires May, 2025                  [Page 12]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

                              DHCP Relay
   +------+     +------+       +------+      +-----+
   | Host +-----+ CPE  +-------+Router+------+ BRAS|
   +------+     +------+       +------+      +--+--+
                                                |
                                                |
                                         +------+-----+
                                         |  Backbone  |
                                         |  Network   |
                                         +------------+
              Figure 4: 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. and generates SRv6 locator route
   locally. The outgoing interface of the route is the access interface
   connecting the client.

   After receiving the DHCPv6 Release and Decline messages from the
   client, or the valid lifetime of SRv6 Locator prefix expires, the
   DHCPv6 relay agent MUST 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 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

Cheng, et al.             Expires May, 2025                  [Page 13]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   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 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

   *  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.

Cheng, et al.             Expires May, 2025                  [Page 14]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

   *  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
8. Security Considerations

   See Section 22 of [RFC8415] and Section 23 of [RFC7227] for the DHCP
   security considerations. See [RFC8200] for the IPv6 security
   considerations.

   As discussed in Section 22 of [RFC8415]: 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 22 of [RFC8415].

   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.

Cheng, et al.             Expires May, 2025                  [Page 15]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

9. Privacy Considerations

   See Section 23 of [RFC8415] 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 using the method defined in this document to assign SRv6
   locators to SRv6 Segment Endpoint Nodes through DHCPv6, it is
   important to ensure that CPEs and BRAS devices 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 and Liyan Gong for their comments to this
   document.

11. References

11.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7550] Troan, O., Volz, B., Siodelski, M., "Issues and
             Recommendations with Multiple Stateful DHCPv6 Options",
             RFC 7550, DOI 10.17487/RFC7550, May 2015,
             <https://www.rfc-editor.org/info/rfc7550>.

   [RFC8168] Li, T., Liu, C., Cui, Y., "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, May 2017.

Cheng, et al.             Expires May, 2025                  [Page 16]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

    [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir,
              "SegmentRouting Architecture", RFC 8402, DOI
              10.17487/RFC8402,July 2018, <https://www.rfc-
              editor.org/info/rfc8402>.

   [RFC8415] Mrugalski, T., Siodelski, M ., Volz, B., Yourtchenko, A.,
             Richardson, M., Jiang, S., Lemon, T., and Winters, T.,
             "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
             RFC 8415, DOI 10.17487/RFC8415, November 2018,
             <https://www.rfc-editor.org/info/rfc8415>.

   [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>.

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>.

Cheng, et al.             Expires May, 2025                  [Page 17]
Internet-Draft       Distribute SRv6 Locator by DHCP      November 2024

Authors' Addresses

   Weiqiang Cheng
   China Mobile

   Email: chengweiqiang@chinamobile.com

   Ruibo Han
   China Mobile

   Email: hanruibo@chinamobile.com

   Changwang Lin
   New H3C Technologies

   Email: linchangwang.04414@h3c.com

   Daniel Voyer
   Bell Canada
   Canada
   Email: daniel.voyer@bell.ca

   Yuanxiang Qiu
   New H3C Technologies

   Email: qiuyuanxiang@h3c.com

   Geng Zhang
   China Mobile

   Email: zhanggeng@chinamobile.com

Cheng, et al.             Expires May, 2025                  [Page 18]