[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
Dynamic Host Configuration (DHC)                              W. Cheng
Internet Draft                                                  R. Han
Intended status: Standards Track                          China Mobile
Expires: December 12, 2022                                      C. Lin
                                                  New H3C Technologies
                                                         June 10, 2022



                      Distribute SRv6 Locator by DHCP
              draft-cheng-dhc-distribute-srv6-locator-by-dhcp-00


Abstract

   In SRv6 network, locators need to be assigned to each SRv6 Endpoint,
   and segments are created based on locators. This document describes
   the method of assigning locators to SRv6 Endpoints 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 December 12, 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors. All rights reserved.




Cheng, et al.              Expire December, 2022                  [Page 1]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


   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.



Table of Contents


   1. Introduction ................................................ 2
      1.1. Requirements Language .................................. 3
   2. Scenario for Locator......................................... 3
   3. DHCPv6 extension ............................................ 5
      3.1. SRv6 Locator Option .................................... 5
   4. Process of Assigning Locator ................................ 7
         4.1.1. Client Behavior ................................... 7
         4.1.2. Server Behavior ................................... 8
         4.1.3. Relay Agent Behavior .............................. 9
   5. IANA Considerations ......................................... 9
   6. Security Considerations ..................................... 9
   7. References ................................................. 10
      7.1. Normative References .................................. 10
   Authors' Addresses ............................................ 11

1. Introduction

   Segment Routing (SR) allows a headend node to steer a packet flow
   along any path. Per-path states of Intermediate nodes are eliminated
   thanks to source routing.  The headend node steers a flow into an SR
   Policy. The packets steered into an SR Policy carry an ordered list
   of segments associated with that SR Policy.

   When deploying SRv6, each SRv6 endpoint needs to be assigned a
   unique IPv6 prefix, that is, locator. As the identity of the
   endpoint, the locator could be distributed to other IPv6 nodes in
   the SRv6 domain through IGP, so that other IPv6 nodes could learn
   the locator route. SRv6 endpoint allocates segments of various
   behaviors based on its locator.

   In some specific scenarios, some SRv6 endpoints do not deploy IGP
   with other routers. In this case, the locator route cannot be
   distributed in the normal way.

Cheng, et al.              Expires December, 2022                 [Page 2]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


   This document describes a method of assigning locators to SRv6
   Endpoints through DHCPv6. The existing processing flow of DHCPv6 can
   be used to simplify the allocation of locators and route
   distributing.

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. Scenario for Locator

   Telecom provider use the dedicated SD-WAN network, cloud private
   network, to realize the interconnection between access users in
   different regions.

   In the cloud private network, deploy the network PE (PE-N) for
   access users in different regions and the cloud PE (PE-C) for the
   cloud.

   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.

   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 networking environment, it is expected to deploy end-to-end
   SRv6 to realize communication between access users, or access users
   to access the public cloud or private cloud.

   For example, for the traffic from host1 to host2, CPE1 should be the
   SRv6 headend node and CPE2 should be the SRv6 tailend node. When
   accessing the cloud, CPE should be the SRv6 headend node and VCPE
   should be the SRv6 tailend node.

   To deploy SRv6 on CPE, the configuration required by SRv6 needs to
   be configured on CPE, such as locator. The locator of each CPE needs
   to uniquely identify the CPE, and other network nodes need to be
   able to learn the locator route. There are difficulties in achieving
   these requirements for the following reasons:

   o configuration complexity

Cheng, et al.              Expires December, 2022                 [Page 3]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


   In SD-WAN 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 IP address of CPE cannot be fixed.

   In order to simplify the deployment procedure, zero touch
   provisioning (ZTP) deployment technology is often used when
   deploying CPE, such as USB-based deployment. The configuration file
   is recorded in the USB flash disk, and CPE reads the corresponding
   configuration file to complete the basic configuration. In this way,
   the configuration file in the USB flash disk should only contain
   general configuration, and the personalized configuration of the CPE,
   such as IP address, should be avoided as far as possible.

   Usually, the public network side IPv6 address of CPE is applied for
   through the stateless address automatic configuration (SLAAC) of ND
   or through DHCPv6.

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

   o locator route learning

   CPE can be connected to the BRAS of local MAN through various types
   of networks, such as leased line, 4/5G network, 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.

   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. 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 December, 2022                 [Page 4]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


                               Metropolitan area network
                            +---------------------------+
                            |                           |
   +------+     +------+    |  +-----+        +------+  |
   |Host1 +-----+ CPE1 +----+--+BRAS1+--------+  CR1 |  |
   +------+     +------+    |  +-----+        +---+--+  |
                            |                     |     |
                            +---------------------+-----+
                                                  |
                                         +--------+-------------+
                                         |                      |
                                         |   Backbone Network   |
                                         |                      |
                                         +-------+--------+----+
                                                 |        |
                            +--------------------+------+ |
                            |                    |      | |
   +------+     +------+    |  +-----+        +--+---+  | |
   |Host2 +-----+ CPE2 +----+--+BRAS2+--------+  CR2 |  | |
   +------+     +------+    |  +-----+        +------+  | |
                            +---------------------------+ |
                                                          |
                                                       +--+-+
                                                  ,----+vCPE+---.
                                               ,-'     +----+    `-.
                                             ,'                     `.
                                            (                         )
                                             `.        Cloud        ,'
                                               `-.               ,-'
                                                  `-------------'


   To solve these difficulties this document proposes a method to
   allocate locators to CPE through DHCPv6, and distribute locator
   routes by using the workflow of DHCPv6.

3. DHCPv6 extension

3.1. SRv6 Locator Option

   The SRv6 Locator option is used to specify the information of SRv6
   locator prefix associated with an IA prefix. The SRv6 Locator option
   must be encapsulated in the IAprefix-options field of an IA_Prefix
   option (see Section 21.22 of [RFC8415]).





Cheng, et al.              Expires December, 2022                 [Page 5]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


       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_SRV6_LOCATOR       |           Option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   LB-len      |    Func-len   |   Args-len    |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure XX: SRv6 Locator Option Format

   Where:

     - Option-code:  OPTION_SRV6_LOCATOR (TBD).

     - Option-len:  4.

     - LB-len:  Length of locator block of SRv6 compressible SID in bits.
   A 1-octet unsigned integer. For locators with incompressible SIDS,
   the LB-len field is set to 0.

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

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

   If there is a SRv6 locator option in the IAprefix-options field of
   an IA_Prefix option in DHCPv6 message, it indicates this IA_Prefix
   option carries SRv6 locator prefix information. By default, SRv6
   locator option is not encapsulated in IAprefix-options field of an
   IA_Prefix option, that is, IA_Prefix option carries common IPv6
   prefix information.

   The length of locator prefix in bits is filled in the "prefix-
   length" field of IA Prefix option, and the "IPv6-prefix" field of IA
   Prefix option is SRv6 locator prefix.

   The lifetime of SRv6 locator corresponds to the valid-lifetime and
   preferred-lifetime fields of IA Prefix option. See Section 21.22 of
   [RFC8415] for details.

   The processing of prefix-length hints of SRv6 locator is the same as
   that of IPv6 prefix. The client SHOULD NOT send an IA Prefix option
   with 0 in the "prefix-length" field (and an unspecified value (::)
   in the "IPv6-prefix" field) of IA Prefix option.  A client MAY send
   a non-zero value in the "prefix-length" field of IA Prefix option
   and the unspecified value (::) in the "IPv6-prefix" field of IA
   Prefix option to indicate a preference for the size of the prefix to


Cheng, et al.              Expires December, 2022                 [Page 6]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


   be delegated. See [RFC8168] for further details on prefix-length
   hints.

   A SRv6 Locator option may appear only in an IA_Prefix option.
   Multiple IA Prefix options in one IA_PD option can encapsulate one
   SRv6 Locator option respectively.

   If there are multiple SRv6 Locator options in an IA Prefix option,
   it is considered that the IA Prefix option is illegal, and the
   entire IA Prefix option SHOULD be ignored.

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

4.1.1. 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 addresses and delegated prefixes.

   When the client requests to allocate an SRv6 locator, the SRv6
   Locator option MUST be encapsulated in the IAprefix-options field of
   IA Prefix option in DHCPv6 Solicit, Request, Renew, Rebind, Release,
   or Decline message. By default the BL-len, Func-len, and Args-len
   fields in the SRv6 Locator option are filled with 0.

   A client MAY send a non-zero value in the "LB-length" field to
   indicate a preference for the size of SRv6 locator block of
   compressible SID to be delegated in DHCPv6 Solicit message.

   Upon the receipt of a valid Reply message with SRv6 Locator option
   in the IAprefix-options field of IA Prefix 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

Cheng, et al.              Expires December, 2022                 [Page 7]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


   MUST be no longer than the remaining preferred and valid lifetimes
   respectively for the delegated locator prefix at any time.

   To extend the preferred and valid lifetimes for the leases assigned
   to the IAs and obtain new delegated locator prefixes for IAs, the
   client sends a Renew/Rebind message to the server with SRv6 Locator
   option in the IAprefix-options field of IA Prefix option. When the
   valid lifetime of the locator prefix expires, or the new lifetime
   replied by the server is 0, delete the corresponding SRv6 locator.

   If the client no longer uses the delegated locator prefix, the
   client can actively send a Release message to notify the server to
   reclaim locator resources and delete the corresponding SRv6 locator.
   The client MUST include options containing the IAs for the locators
   prefixes it is releasing in the "IA_PD-options" field.

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

   Upon the receipt of the IA Prefix option with SRv6 Locator option,
   the server searches local 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_PD option fills with the locator
   prefix information assigned to the client, and the IAprefix-options
   field of the IA Prefix option encapsulates the SRv6 Locator option.
   The SRv6 Locator option populates the locator block length, function
   length and arguments length of SRv6 SID specified by the DHCPv6
   server.

   For the scenario described in Section 2 where the BRAS device acts
   as a DHCPv6 server, after the locator prefix 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 prefix 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 locator
   subnet route locally.

Cheng, et al.              Expires December, 2022                 [Page 8]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


4.1.3. Relay Agent Behavior

   For the scenario described in Section 2, if an external DHCPv6
   server is deployed to allocate locators, the DHCPv6 relay agent
   function 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.

                              DHCP Relay
   +------+     +------+       +------+      +-----+
   | Host +-----+ CPE  +-------+Router+------+ BRAS|
   +------+     +------+       +------+      +--+--+
                                                |
                                                |
                                         +------+-----+
                                         |  Backbone  |
                                         |  Network   |
                                         +------------+
              Figure XX: 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_PD option from the Relay Message option, and obtains the locator
   prefix delegated by the DHCPv6 server according to IA Prefix option
   and SRv6 Locator option. The first DHCPv6 relay agent needs to
   record the locator prefix 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.

5. IANA Considerations

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

6. Security Considerations

   See [RFC8415] for the DHCPv6 security considerations.




Cheng, et al.              Expires December, 2022                 [Page 9]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


7. References

7.1. Normative References

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

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






























Cheng, et al.              Expires December, 2022                [Page 10]


Internet-Draft     Distribute SRv6 Locator by DHCP             June 2022


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





















Cheng, et al.              Expires December, 2022                [Page 11]