Skip to main content

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

Document Type Active Internet-Draft (spring WG)
Authors Weiqiang Cheng , Ruibo Han , Changwang Lin , Yuanxiang Qiu , Geng Zhang
Last updated 2024-05-20 (Latest revision 2024-04-29)
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-01
SPRING                                                         W. Cheng
Internet Draft                                                   R. Han
Intended status: Standards Track                           China Mobile
Expires: October 30, 2024                                        C. Lin
                                                                 Y. Qiu
                                                   New H3C Technologies
                                                               G. Zhang
                                                           China Mobile
                                                         April 30, 2024

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

Abstract

   In a SRv6 network, each SRv6 Segment Endpoint Node must be assigned
   a locator, and segment IDs are generated within the address space of
   this locator. This document describes a method for assigning
   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), 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 October 30, 2024.

Cheng, et al.          Expire October,2024                  [Page 1]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 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
   (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 October,2024                 [Page 2]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

Table of Contents

   1. Introduction...................................................4
      1.1. Requirements Language.....................................4
   2. Terminology....................................................4
   3. Scenario for Locator...........................................5
   4. DHCPv6 extension...............................................6
      4.1. Identity Association for SRv6 Locator Option..............6
      4.2. IA SRv6 Locator Option....................................9
   5. Process of Assigning Locator..................................11
         5.1.1. DHCP Client Behavior................................11
         5.1.2. DHCP Server Behavior................................12
         5.1.3. DHCP Relay Agent Behavior...........................13
   6. IANA Considerations...........................................14
   7. Security Considerations.......................................14
   8. Acknowledgements..............................................15
   9. References....................................................15
      9.1. Normative References.....................................15
   Authors' Addresses...............................................16

Cheng, et al.          Expires October,2024                 [Page 3]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

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.

   When implementing SRv6, each SRv6 Segment Endpoint Node should be
   assigned a unique IPv6 prefix, known as a locator. The locator
   serves as the endpoint's identity and can be distributed to other
   IPv6 nodes within the SRv6 domain through IGP advertisement. This
   allows other nodes to learn the locator route. The SRv6 Segment
   Endpoint Node then allocates SIDs with various behaviors based on
   its locator.

   CPE devices often do not support IGP protocol, which makes it
   impossible to advertise locator routes for SRv6 Segment Endpoint
   Nodes through IGP. In such scenarios, SIDs can only be configured
   manually on CPEs, and Locator routes can only be statically
   distributed.

   To address this issue, this document proposes a method of
   dynamically assigning locators to SRv6 Segment Endpoint Nodes
   through DHCPv6. It follows the existing process of DHCPv6,
   simplifying the allocation of 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.

2. Terminology

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

   This document introduces the following new terms:

Cheng, et al.          Expires October,2024                 [Page 4]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

   IA_SRV6_LOCATOR: Identity Association for SRv6 Locator, an IA that
   carries delegated SRv6 locator prefixes. See Section 4.1 for detail
   on the IA_SRV6_LOCATOR option.

3. Scenario for 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 MAN in various ways.
   CPEs are responsible for assigning addresses to access users, so
   CPEs apply for DHCPv6 PD from DHCPv6 server. DHCPv6 server is
   usually enabled on BRAS.

Cheng, et al.          Expires October,2024                 [Page 5]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

   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 traffic
   from Host1 to Host2 as an example, CPE1 is the SRv6 ingress node and
   CPE2 is the SRv6 egress node.

   To deploy SRv6 tunnels, an SRv6 locator should be configured on the
   CPE to uniquely identify the CPE. Other devices learn the locator
   route of the CPE. 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 the IPv6 address of CPE cannot be fixed.

   At present, SRv6 locator can only be configured on each CPE through
   the controller or CLI, which increases the configuration complexity.

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

Cheng, et al.          Expires October,2024                 [Page 6]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

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

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

Cheng, et al.          Expires October,2024                 [Page 7]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

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

Cheng, et al.          Expires October,2024                 [Page 8]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

   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.

   If the device does not support IA_SRV6_LOCATOR, this IA_SRV6_LOCATOR
   option should be ignored.

4.2. IA SRv6 Locator Option

   The IA SRv6 Locator option is used to specify a 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                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    LOC-len    |   Func-len    |    Args-len   |    LB-len     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     |                                                               |
     |                         SRv6-Locator                          |
     |                         (16 octets)                           |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                       IALocator-options                       .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 3: IA SRv6 Locator Option Format

   Where:

     - Option-code: OPTION_IALOCATOR (TBD).

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

Cheng, et al.          Expires October,2024                 [Page 9]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

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

     - LOC-len: The locator (LOC) length of SRv6 SID in bits. A 1-octet
   unsigned integer.

     - Func-len: The function (FUNCT) length of SRv6 SID in bits. A 1-
   octet unsigned integer.

     - Args-len: The arguments (ARG) length of SRv6 SID in bits. A 1-
   octet unsigned integer.

     - LB-len: The Locator Block length of SRv6 SID in bits. A 1-octet
   unsigned integer.

     - SRv6-locator: A SRv6 locator prefix. A 16-octet field.

     - IALocator-options: Options associated with this SRv6 locator. A
   variable-length field (28 octets less than the value in the Option-
   len field).

   For compressible SID, the length of Locator Node is LOC-len minus
   LB-len.

   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
   "LOC-len" field (and an unspecified value (::) in the "SRv6-Locator"
   field). A client MAY send a non-zero value in the "LOC-len" field
   and the unspecified value (::) in the "SRv6-Locator" field to
   indicate a preference for the size of the SRv6 locator to be
   delegated. The LOC-len hint of IA_SRV6_LOCATOR is the same as
   prefix-length hint of IA_PD. For further details on LOC-len hints,
   see [RFC8168].

   The client MUST discard any SRv6 locators for which the preferred
   lifetime is greater than the valid lifetime.

   The values in the preferred-lifetime and valid-lifetime fields are
   the number of seconds remaining in each lifetime. For more details
   on how these values are used to assign locators, see section
   18.2.10.1 of [RFC8415], which is the same as prefix delegation.

Cheng, et al.          Expires October,2024                [Page 10]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

   As per Section 7.7 of [RFC8415], the value of 0xffffffff for the
   preferred lifetime or the valid lifetime is taken to mean "infinity"
   and should be used carefully.

   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 Locator

   This document assumes that a client SHOULD use a single transaction
   for all of the IA options required on an interface. This simplifies
   the client implementation and reduces the potential number of
   transactions required (for the background on this design choice,
   refer to Section 4 of [RFC7550]). If a client requests multiple IA
   option types, follow [RFC7550].

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 and Release messages during
   the normal lifecycle of addresses and delegated prefixes.

   The process of applying for SRv6 locator is the same as that of
   applying for PD. When applying for 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 SHOULD process the
   Reply message according to the requirements of Section 18.2 of
   [RFC8415], and configure the delegated locator in the client device
   automatically.

   When the client uses a delegated locator prefix to configure SRv6
   locator locally, the preferred and valid lifetimes of those locators
   MUST be no longer than the remaining preferred and valid lifetimes
   respectively for the delegated SRv6 locator at any time.

Cheng, et al.          Expires October,2024                [Page 11]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

   To extend the preferred and valid lifetimes for the leases assigned
   to the IAs and obtain new delegated SRv6 locators for IAs, the
   client sends a Renew/Rebind message to the server with
   IA_SRV6_LOCATOR option. When the valid lifetime of the SRv6 locator
   expires, or the new lifetime replied by the server is 0, delete the
   corresponding SRv6 locator.

   If the client no longer uses the delegated SRv6 locator, the client
   can actively send a Release message to notify the server to reclaim
   locator prefixes and delete the corresponding SRv6 locator. The
   client MUST include options containing the IAs for the 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).

   In principle, DHCP allows a client to request new Locator prefixes
   to be delegated by sending additional new IA_SRV6_LOCATOR options.
   However, a typical operator usually prefers to delegate a single,
   larger prefix. In most deployments, it is recommended that the
   client request a larger Locator prefix in its initial transmissions
   rather than request additional Locator prefixes later on.

5.1.2. DHCP Server Behavior

   As described in [RFC8415], 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 locator as the prefix of prefix pool,
   which is similar to the prefix allocation process. Upon the receipt
   of the IA_SRV6_LOCATOR option, the server searches locator prefix
   pool and allocates appropriate locators for the client.

   If there is an assignable locator prefix, the server records the
   locator binding entry and encapsulates the locator information into
   the DHCPv6 Reply message. The IA_SRV6_LOCATOR option fills with the
   locator prefix information assigned to the client. The IA SRv6
   Locator option populates the SRv6 locator length, function length,
   arguments length and Locator Block length of SRv6 SID specified by
   the DHCPv6 server.

Cheng, et al.          Expires October,2024                [Page 12]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

   For the scenario described in Section 2 where the BRAS device acts
   as a DHCPv6 server, after the locator is successfully delegated, the
   server generates a locator subnet route locally, and the outgoing
   interface of the route is the access interface connecting the client.

   Upon receiving the Release message from the client or when the
   locator lease expires, the server reclaims the locator prefix
   resource and deletes the locator binding entry. If the BRAS device
   acts as a DHCPv6 server, the server also SHOULD delete the
   corresponding locator subnet route locally.

   For any IA_SRV6_LOCATOR option in the request message to which the
   server cannot assign any delegated SRv6 locator prefixes, the server
   MUST return the IA_SRV6_LOCATOR option in the Reply message with no
   prefixes in the IA_SRV6_LOCATOR and with a Status Code option
   containing status code NoPrefixAvail 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
   Locator prefixes 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 locators, the DHCPv6 relay agent
   service needs to be enabled on the layer 3 network nodes close to
   CPE. As shown in the figure below, the DHCP relay function is
   enabled on the router directly connected to CPE. This deployment
   assumes that all of the relevant components in Figure 4 are part of
   a single trusted SR domain.

                              DHCP Relay
   +------+     +------+       +------+      +-----+
   | Host +-----+ CPE  +-------+Router+------+ BRAS|
   +------+     +------+       +------+      +--+--+
                                                |
                                                |
                                         +------+-----+
                                         |  Backbone  |
                                         |  Network   |
                                         +------------+
              Figure 4: CPE accessed through DHCP relay

   When the first hop DHCPv6 relay agent device connected to the DHCPv6
   PD client receives DHCPv6 Relay-reply messages, it extracts the
   IA_SRV6_LOCATOR option from the Relay Message option, and obtains
   the locator delegated by the DHCPv6 server according to IA SRv6

Cheng, et al.          Expires October,2024                [Page 13]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

   Locator option. The first DHCPv6 relay agent needs to record the
   locator delegated by the DHCPv6 server, including locator
   information, lifetime, etc. and generates locator route locally. The
   outgoing interface of the route is the access interface connecting
   the client.

   After receiving the DHCPv6 message releasing the locator prefix from
   the client or the valid lifetime of Locator prefix expires, the
   first DHCPv6 relay agent device SHOULD delete the locator route
   locally.

6. IANA Considerations

   IANA is kindly requested to assign new values for
   OPTION_IA_SRV6_LOCATOR (TBD) and OPTION_IALOCATOR (TBD) and add the
   values to the DHCPv6 Option Codes registry maintained at
   http://www.iana.org/assignments/dhcpv6-parameters.

    +=======+========================+========+===========+===========+
    | Value |      Description       | Client | Singleton | Reference |
    |       |                        | ORO    | Option    |           |
    +=======+========================+========+===========+===========+
    | TBA1  | OPTION_IA_SRV6_LOCATOR |  NO    |   No      | [ This    |
    |       |                        |        |           | Document ]|
    +-------+------------------------+--------+-----------+-----------+
    | TBA2  |  OPTION_IALOCATOR      |  NO    |   No      | [ This    |
    |       |                        |        |           | Document ]|
    +-------+------------------------+--------+-----------+-----------+
                             Table 1
7. Security Considerations

   See [RFC8415] for the DHCPv6 security 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 locators to
   SRv6 Segment Endpoint Nodes through DHCPv6, it is important to

Cheng, et al.          Expires October,2024                [Page 14]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 2024

   ensure that CPEs and BRAS devices operate within a single trusted SR
   domain.

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

9. References

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

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

Cheng, et al.          Expires October,2024                [Page 15]
Internet-Draft       Distribute SRv6 Locator by DHCP        April, 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

   Yuanxiang Qiu
   New H3C Technologies

   Email: qiuyuanxiang@h3c.com

   Geng Zhang
   China Mobile

   Email: zhanggeng@chinamobile.com

Cheng, et al.          Expires October,2024                [Page 16]