path: root/doc/rfc/rfc8992.txt

Internet Engineering Task Force (IETF)                     S. Jiang, Ed.
Request for Comments: 8992                  Huawei Technologies Co., Ltd
Category: Informational                                            Z. Du
ISSN: 2070-1721                                             China Mobile
                                                            B. Carpenter
                                                       Univ. of Auckland
                                                                  Q. Sun
                                                           China Telecom
                                                                May 2021


     Autonomic IPv6 Edge Prefix Management in Large-Scale Networks

Abstract

   This document defines two autonomic technical objectives for IPv6
   prefix management at the edge of large-scale ISP networks, with an
   extension to support IPv4 prefixes.  An important purpose of this
   document is to use it for validation of the design of various
   components of the Autonomic Networking Infrastructure.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8992.

Copyright Notice

   Copyright (c) 2021 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 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.  Terminology
   3.  Problem Statement
     3.1.  Intended User and Administrator Experience
     3.2.  Analysis of Parameters and Information Involved
       3.2.1.  Parameters Each Device Can Define for Itself
       3.2.2.  Information Needed from Network Operations
       3.2.3.  Comparison with Current Solutions
     3.3.  Interaction with Other Devices
       3.3.1.  Information Needed from Other Devices
       3.3.2.  Monitoring, Diagnostics, and Reporting
   4.  Autonomic Edge Prefix Management Solution
     4.1.  Behavior of a Device Requesting a Prefix
     4.2.  Behavior of a Device Providing a Prefix
     4.3.  Behavior after Successful Negotiation
     4.4.  Prefix Logging
   5.  Autonomic Prefix Management Objectives
     5.1.  Edge Prefix Objective Option
     5.2.  IPv4 Extension
   6.  Prefix Management Parameters
     6.1.  Example of Prefix Management Parameters
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Appendix A.  Deployment Overview
     A.1.  Address and Prefix Management with DHCP
     A.2.  Prefix Management with ANI/GRASP
   Acknowledgements
   Authors' Addresses

1.  Introduction

   The original purpose of this document was to validate the design of
   the Autonomic Networking Infrastructure (ANI) for a realistic use
   case.  It shows how the ANI can be applied to IP prefix delegation,
   and it outlines approaches to build a system to do this.  A fully
   standardized solution would require more details, so this document is
   informational in nature.

   This document defines two autonomic technical objectives for IPv6
   prefix management in large-scale networks, with an extension to
   support IPv4 prefixes.  The background to Autonomic Networking is
   described in [RFC7575] and [RFC7576].  The GeneRic Autonomic
   Signaling Protocol (GRASP) is specified by [RFC8990] and can make use
   of the technical objectives to provide a solution for autonomic
   prefix management.  An important purpose of the present document is
   to use it for validation of the design of GRASP and other components
   of the ANI as described in [RFC8993].

   This document is not a complete functional specification of an
   autonomic prefix management system, and it does not describe all
   detailed aspects of the GRASP objective parameters and Autonomic
   Service Agent (ASA) procedures necessary to build a complete system.
   Instead, it describes the architectural framework utilizing the
   components of the ANI, outlines the different deployment options and
   aspects, and defines GRASP objectives for use in building the system.
   It also provides some basic parameter examples.

   This document is not intended to solve all cases of IPv6 prefix
   management.  In fact, it assumes that the network's main
   infrastructure elements already have addresses and prefixes.  This
   document is dedicated to how to make IPv6 prefix management at the
   edges of large-scale networks as autonomic as possible.  It is
   specifically written for Internet Service Provider (ISP) networks.
   Although there are similarities between ISPs and large enterprise
   networks, the requirements for the two use cases differ.  In any
   case, the scope of the solution is expected to be limited, like any
   Autonomic Network, to a single management domain.

   However, the solution is designed in a general way.  Its use for a
   broader scope than edge prefixes, including some or all
   infrastructure prefixes, is left for future discussion.

   A complete solution has many aspects that are not discussed here.
   Once prefixes have been assigned to routers, they need to be
   communicated to the routing system as they are brought into use.
   Similarly, when prefixes are released, they need to be removed from
   the routing system.  Different operators may have different policies
   regarding prefix lifetimes, and they may prefer to have centralized
   or distributed pools of spare prefixes.  In an Autonomic Network,
   these are properties decided upon by the design of the relevant ASAs.
   The GRASP objectives are simply building blocks.

   A particular risk of distributed prefix allocation in large networks
   is that over time, it might lead to fragmentation of the address
   space and an undesirable increase in the size of the interior routing
   protocol tables.  The extent of this risk depends on the algorithms
   and policies used by the ASAs.  Mitigating this risk might even
   become an autonomic function in itself.

2.  Terminology

   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.

   This document uses terminology defined in [RFC7575].

3.  Problem Statement

   The Autonomic Networking use case considered here is autonomic IPv6
   prefix management at the edge of large-scale ISP networks.

   Although DHCPv6-PD (DHCPv6 Prefix Delegation) [RFC8415] supports
   automated delegation of IPv6 prefixes from one router to another,
   prefix management still largely depends on human planning.  In other
   words, there is no basic information or policy to support autonomic
   decisions on the prefix length that each router should request or be
   delegated, according to its role in the network.  Roles could be
   defined separately for individual devices or could be generic (edge
   router, interior router, etc.).  Furthermore, IPv6 prefix management
   by humans tends to be rigid and static after initial planning.

   The problem to be solved by Autonomic Networking is how to
   dynamically manage IPv6 address space in large-scale networks, so
   that IPv6 addresses can be used efficiently.  Here, we limit the
   problem to assignment of prefixes at the edge of the network, close
   to access routers that support individual fixed-line subscribers,
   mobile customers, and corporate customers.  We assume that the core
   infrastructure of the network has already been established with
   appropriately assigned prefixes.  The Autonomic Networking approach
   discussed in this document is based on the assumption that there is a
   generic discovery and negotiation protocol that enables direct
   negotiation between intelligent IP routers.  GRASP [RFC8990] is
   intended to be such a protocol.

3.1.  Intended User and Administrator Experience

   The intended experience is, for the administrators of a large-scale
   network, that the management of IPv6 address space at the edge of the
   network can be run with minimum effort, as devices at the edge are
   added and removed and as customers of all kinds join and leave the
   network.  In the ideal scenario, the administrators only have to
   specify a single IPv6 prefix for the whole network and the initial
   prefix length for each device role.  As far as users are concerned,
   IPv6 prefix assignment would occur exactly as it does in any other
   network.

   The actual prefix usage needs to be logged for potential offline
   management operations, including audit and security incident tracing.

3.2.  Analysis of Parameters and Information Involved

   For specific purposes of address management, each edge device will
   implement several parameters.  (Some of them can be preconfigured
   before they are connected.)  They include the following:

   *  Identity, authentication, and authorization of this device.  This
      is expected to use the Autonomic Networking secure bootstrap
      process [RFC8995], following which the device could safely take
      part in autonomic operations.

   *  Role of this device.  Some example roles are discussed in
      Section 6.1.

   *  An IPv6 prefix length for this device.

   *  An IPv6 prefix that is assigned to this device and its downstream
      devices.

   The network as a whole will implement the following parameters:

   *  Identity of a trust anchor, which is a certification authority
      (CA) maintained by the network administrators, used during the
      secure bootstrap process.

   *  Total IPv6 address space available for edge devices.  It is a pool
      of one or several IPv6 prefixes.

   *  The initial prefix length for each device role.

3.2.1.  Parameters Each Device Can Define for Itself

   This section identifies those of the above parameters that do not
   need external information in order for the devices concerned to set
   them to a reasonable default value after bootstrap or after a network
   disruption.  They are as follows:

   *  Default role of this device.

   *  Default IPv6 prefix length for this device.

   *  Cryptographic identity of this device, as needed for secure
      bootstrapping [RFC8995].

   The device may be shipped from the manufacturer with a preconfigured
   role and default prefix length, which could be modified by an
   autonomic mechanism.  Its cryptographic identity will be installed by
   its manufacturer.

3.2.2.  Information Needed from Network Operations

   This section identifies those parameters that might need operational
   input in order for the devices concerned to set them to a non-default
   value.

   *  Non-default value for the IPv6 prefix length for this device.
      This needs to be decided based on the role of this device.

   *  The initial prefix length for each device role.

   *  Whether to allow the device to request more address space.

   *  The policy regarding when to request more address space -- for
      example, if the address usage reaches a certain limit or
      percentage.

3.2.3.  Comparison with Current Solutions

   This section briefly compares the above use case with current
   solutions.  Currently, the address management is still largely
   dependent on human planning.  It is rigid and static after initial
   planning.  Address requests will fail if the configured address space
   is used up.

   Some autonomic and dynamic address management functions may be
   achievable by extending the existing protocols -- for example,
   extending DHCPv6-PD [RFC8415] to request IPv6 prefixes according to
   the device role.  However, defining uniform device roles may not be a
   practical task, as some functions cannot be configured on the basis
   of role using existing prefix delegation protocols.

   Using a generic autonomic discovery and negotiation protocol instead
   of specific solutions has the advantage that additional parameters
   can be included in the autonomic solution without creating new
   mechanisms.  This is the principal argument for a generic approach.

3.3.  Interaction with Other Devices

3.3.1.  Information Needed from Other Devices

   This section identifies those of the above parameters that need
   external information from neighbor devices (including the upstream
   devices).  In many cases, two-way dialogue with neighbor devices is
   needed to set or optimize them.

   *  Information regarding the identity of a trust anchor is needed.

   *  The device will need to discover another device from which it can
      acquire IPv6 address space.

   *  Information regarding the initial prefix length for the role of
      each device is needed, particularly for its own downstream
      devices.

   *  The default value of the IPv6 prefix length may be overridden by a
      non-default value.

   *  The device will need to request and acquire one or more IPv6
      prefixes that can be assigned to this device and its downstream
      devices.

   *  The device may respond to prefix delegation requests from its
      downstream devices.

   *  The device may require the assignment of more IPv6 address space
      if it used up its assigned IPv6 address space.

3.3.2.  Monitoring, Diagnostics, and Reporting

   This section discusses what role devices should play in monitoring,
   fault diagnosis, and reporting.

   *  The actual address assignments need to be logged for potential
      offline management operations.

   *  In general, the usage situation regarding address space should be
      reported to the network administrators in an abstract way -- for
      example, statistics or a visualized report.

   *  A forecast of address exhaustion should be reported.

4.  Autonomic Edge Prefix Management Solution

   This section introduces the building blocks for an autonomic edge
   prefix management solution.  As noted in Section 1, this is not a
   complete description of a solution, which will depend on the detailed
   design of the relevant Autonomic Service Agents (ASAs).  It uses the
   generic discovery and negotiation protocol defined by [RFC8990].  The
   relevant GRASP objectives are defined in Section 5.

   The procedures described below are carried out by an ASA in each
   device that participates in the solution.  We will refer to this as
   the PrefixManager ASA.

4.1.  Behavior of a Device Requesting a Prefix

   If the device containing a PrefixManager ASA has used up its address
   pool, it can request more space according to its requirements.  It
   should decide the length of the requested prefix and request it via
   the mechanism described in Section 6.  Note that although the
   device's role may define certain default allocation lengths, those
   defaults might be changed dynamically, and the device might request
   more, or less, address space due to some local operational heuristic.

   A PrefixManager ASA that needs additional address space should
   firstly discover peers that may be able to provide extra address
   space.  The ASA should send out a GRASP Discovery message that
   contains a PrefixManager Objective option (see Section 2 of [RFC8650]
   and Section 5.1) in order to discover peers also supporting that
   option.  Then, it should choose one such peer, most likely the first
   to respond.

   If the GRASP Discovery Response message carries a Divert option
   pointing to an off-link PrefixManager ASA, the requesting ASA may
   initiate negotiation with that ASA-diverted device to find out
   whether it can provide the requested length of the prefix.

   In any case, the requesting ASA will act as a GRASP negotiation
   initiator by sending a GRASP Request message with a PrefixManager
   Objective option.  The ASA indicates in this option the length of the
   requested prefix.  This starts a GRASP negotiation process.

   During the subsequent negotiation, the ASA will decide at each step
   whether to accept the offered prefix.  That decision, and the
   decision to end the negotiation, are implementation choices.

   The ASA could alternatively initiate GRASP discovery in rapid mode
   with an embedded negotiation request, if it is implemented.

4.2.  Behavior of a Device Providing a Prefix

   At least one device on the network must be configured with the
   initial pool of available prefixes mentioned in Section 3.2.  Apart
   from that requirement, any device may act as a provider of prefixes.

   A device that receives a Discovery message with a PrefixManager
   Objective option should respond with a GRASP Response message if it
   contains a PrefixManager ASA.  Further details of the discovery
   process are described in [RFC8990].  When this ASA receives a
   subsequent Request message, it should conduct a GRASP negotiation
   sequence, using Negotiate, Confirm Waiting, and Negotiation End
   messages as appropriate.  The Negotiate messages carry a
   PrefixManager Objective option, which will indicate the prefix and
   its length offered to the requesting ASA.  As described in [RFC8990],
   negotiation will continue until either end stops it with a
   Negotiation End message.  If the negotiation succeeds, the ASA that
   provides the prefix will remove the negotiated prefix from its pool,
   and the requesting ASA will add it.  If the negotiation fails, the
   party sending the Negotiation End message may include an error code
   string.

   During the negotiation, the ASA will decide at each step how large a
   prefix to offer.  That decision, and the decision to end the
   negotiation, are implementation choices.

   The ASA could alternatively negotiate in response to GRASP discovery
   in rapid mode, if it is implemented.

   This specification is independent of whether the PrefixManager ASAs
   are all embedded in routers, but that would be a rather natural
   scenario.  In a hierarchical network topology, a given router
   typically provides prefixes for routers below it in the hierarchy,
   and it is also likely to contain the first PrefixManager ASA
   discovered by those downstream routers.  However, the GRASP discovery
   model, including its redirection feature, means that this is not an
   exclusive scenario, and a downstream PrefixManager ASA could
   negotiate a new prefix with a device other than its upstream router.

   A resource shortage may cause the gateway router to request more
   resources in turn from its own upstream device.  This would be
   another independent GRASP discovery and negotiation process.  During
   the processing time, the gateway router should send a Confirm Waiting
   message to the initial requesting router, to extend its timeout.
   When the new resource becomes available, the gateway router responds
   with a GRASP Negotiate message with a prefix length matching the
   request.

   The algorithm used to choose which prefixes to assign on the devices
   that provide prefixes is an implementation choice.

4.3.  Behavior after Successful Negotiation

   Upon receiving a GRASP Negotiation End message that indicates that an
   acceptable prefix length is available, the requesting device may use
   the negotiated prefix without further messages.

   There are use cases where the ANI/GRASP-based prefix management
   approach can work together with DHCPv6-PD [RFC8415] as a complement.
   For example, the ANI/GRASP-based method can be used intra-domain,
   while the DHCPv6-PD method works inter-domain (i.e., across an
   administrative boundary).  Also, ANI/GRASP can be used inside the
   domain, and DHCP/DHCPv6-PD can be used on the edge of the domain to
   clients (non-ANI devices).  Another similar use case would be ANI/
   GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to
   client devices.

4.4.  Prefix Logging

   Within the autonomic prefix management system, all prefix assignments
   are done by devices without human intervention.  It may be required
   that all prefix assignment history be recorded -- for example, to
   detect or trace lost prefixes after outages or to meet legal
   requirements.  However, the logging and reporting process is out of
   scope for this document.

5.  Autonomic Prefix Management Objectives

   This section defines the GRASP technical objective options that are
   used to support autonomic prefix management.

5.1.  Edge Prefix Objective Option

   The PrefixManager Objective option is a GRASP Objective option
   conforming to the GRASP specification [RFC8990].  Its name is
   "PrefixManager" (see Section 8), and it carries the following data
   items as its value: the prefix length and the actual prefix bits.
   Since GRASP is based on CBOR (Concise Binary Object Representation)
   [RFC8949], the format of the PrefixManager Objective option is
   described in the Concise Data Definition Language (CDDL) [RFC8610] as
   follows:

     objective = ["PrefixManager", objective-flags, loop-count,
                  [length, ?prefix]]

     loop-count = 0..255         ; as in the GRASP specification
     objective-flags /=          ; as in the GRASP specification
     length = 0..128             ; requested or offered prefix length
     prefix = bytes .size 16     ; offered prefix in binary format

   The use of the "dry run" mode of GRASP is NOT RECOMMENDED for this
   objective, because it would require both ASAs to store state
   information about the corresponding negotiation, to no real benefit
   -- the requesting ASA cannot base any decisions on the result of a
   successful dry-run negotiation.

5.2.  IPv4 Extension

   This section presents an extended version of the PrefixManager
   objective that supports IPv4 by adding an extra flag:

     objective = ["PrefixManager", objective-flags, loop-count, prefval]

     loop-count = 0..255         ; as in the GRASP specification
     objective-flags /=          ; as in the GRASP specification

     prefval /= pref6val
     pref6val = [version6, length, ?prefix]
     version6 = 6
     length = 0..128             ; requested or offered prefix length
     prefix = bytes .size 16     ; offered prefix in binary format

     prefval /= pref4val
     pref4val = [version4, length4, ?prefix4]
     version4 = 4
     length4 = 0..32             ; requested or offered prefix length
     prefix4 = bytes .size 4     ; offered prefix in binary format

   Prefix and address management for IPv4 is considerably more difficult
   than for IPv6, due to the prevalence of NAT, ambiguous addresses
   [RFC1918], and address sharing [RFC6346].  These complexities might
   require further extending the objective with additional fields that
   are not defined by this document.

6.  Prefix Management Parameters

   An implementation of a prefix manager MUST include default settings
   of all necessary parameters.  However, within a single administrative
   domain, the network operator MAY change default parameters for all
   devices with a certain role.  Thus, it would be possible to apply an
   intended policy for every device in a simple way, without traditional
   configuration files.  As noted in Section 4.1, individual autonomic
   devices may also change their own behavior dynamically.

   For example, the network operator could change the default prefix
   length for each type of role.  A prefix management parameters
   objective, which contains mapping information of device roles and
   their default prefix lengths, MAY be flooded in the network, through
   the Autonomic Control Plane (ACP) [RFC8994].  The objective is
   defined in CDDL as follows:

     objective = ["PrefixManager.Params", objective-flags, any]

     loop-count = 0..255         ; as in the GRASP specification
     objective-flags /=          ; as in the GRASP specification

   The "any" object would be the relevant parameter definitions (such as
   the example below) transmitted as a CBOR object in an appropriate
   format.

   This could be flooded to all nodes, and any PrefixManager ASA that
   did not receive it for some reason could obtain a copy using GRASP
   unicast synchronization.  Upon receiving the prefix management
   parameters, every device can decide its default prefix length by
   matching its own role.

6.1.  Example of Prefix Management Parameters

   The parameters comprise mapping information of device roles and their
   default prefix lengths in an autonomic domain.  For example, suppose
   an IPRAN (IP Radio Access Network) operator wants to configure the
   prefix length of a Radio Network Controller Site Gateway (RSG) as 34,
   the prefix length of an Aggregation Site Gateway (ASG) as 44, and the
   prefix length of a Cell Site Gateway (CSG) as 56.  This could be
   described in the value of the PrefixManager.Params objective as:

   [
      [["role", "RSG"],["prefix_length", 34]],
      [["role", "ASG"],["prefix_length", 44]],
      [["role", "CSG"],["prefix_length", 56]]
   ]

   This example is expressed in JSON [RFC8259], which is easy to
   represent in CBOR.

   An alternative would be to express the parameters in YANG [RFC7950]
   using the YANG-to-CBOR mapping [CORE-YANG-CBOR].

   For clarity, the background of the example is introduced below and
   can also be regarded as a use case for the mechanism defined in this
   document.

   An IPRAN is used for mobile backhaul, including radio stations, RNCs
   (Radio Network Controllers) (in 3G) or the packet core (in LTE), and
   the IP network between them, as shown in Figure 1.  The eNB (Evolved
   Node B) entities, the RNC, the SGW (Serving Gateway), and the MME
   (Mobility Management Entity) are mobile network entities defined in
   3GPP.  The CSGs, ASGs, and RSGs are entities defined in the IPRAN
   solution.

   The IPRAN topology shown in Figure 1 includes Ring1, which is the
   circle following ASG1->RSG1->RSG2->ASG2->ASG1; Ring2, following
   CSG1->ASG1->ASG2->CSG2->CSG1; and Ring3, following
   CSG3->ASG1->ASG2->CSG3.  In a real deployment of an IPRAN, there may
   be more stations, rings, and routers in the topology, and normally
   the network is highly dependent on human design and configuration,
   which is neither flexible nor cost-effective.

   +------+   +------+
   | eNB1 |---| CSG1 |\
   +------+   +------+  \   +-------+       +------+           +-------+
                  |       \ |  ASG1 |-------| RSG1 |-----------|SGW/MME|
                  |  Ring2  +-------+       +------+ \        /+-------+
   +------+   +------+     /     |              |      \    /
   | eNB2 |---| CSG2 | \  /      |      Ring1   |        \/
   +------+   +------+   \  Ring3|              |        /\
                        / \      |              |      /   \
   +------+   +------+ /    \ +-------+      +------+/       \+-------+
   | eNB3 |---| CSG3 |--------|  ASG2 |------| RSG2 |---------|  RNC  |
   +------+   +------+        +-------+      +------+         +-------+

                      Figure 1: IPRAN Topology Example

   If ANI/GRASP is supported in the IPRAN, the network nodes should be
   able to negotiate with each other and make some autonomic decisions
   according to their own status and the information collected from the
   network.  The prefix management parameters should be part of the
   information they communicate.

   The routers should know the role of their neighbors, the default
   prefix length for each type of role, etc.  An ASG should be able to
   request prefixes from an RSG, and a CSG should be able to request
   prefixes from an ASG.  In each request, the ASG/CSG should indicate
   the required prefix length, or its role, which implies what length it
   needs by default.

7.  Security Considerations

   Relevant security issues are discussed in [RFC8990].  The preferred
   security model is that devices are trusted following the secure
   bootstrap procedure [RFC8995] and that a secure Autonomic Control
   Plane (ACP) [RFC8994] is in place.

   It is RECOMMENDED that DHCPv6-PD, if used, should be implemented
   using DHCPv6 authentication or Secure DHCPv6.

8.  IANA Considerations

   This document defines two new GRASP Objective option names:
   "PrefixManager" and "PrefixManager.Params".  The IANA has added these
   to the "GRASP Objective Names" registry defined by [RFC8990].

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

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

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/info/rfc8990>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/info/rfc8994>.

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.

9.2.  Informative References

   [CORE-YANG-CBOR]
              Veillette, M., Ed., Petrov, I., Ed., and A. Pelov, "CBOR
              Encoding of Data Modeled with YANG", Work in Progress,
              Internet-Draft, draft-ietf-core-yang-cbor-15, 24 January
              2021, <https://tools.ietf.org/html/draft-ietf-core-yang-
              cbor-15>.

   [DHCP-YANG-MODEL]
              Liu, B., Ed., Lou, K., and C. Chen, "Yang Data Model for
              DHCP Protocol", Work in Progress, Internet-Draft, draft-
              liu-dhc-dhcp-yang-model-07, 12 October 2018,
              <https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-
              model-07>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/info/rfc1918>.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <https://www.rfc-editor.org/info/rfc2865>.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, DOI 10.17487/RFC3046, January 2001,
              <https://www.rfc-editor.org/info/rfc3046>.

   [RFC6221]  Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
              Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
              DOI 10.17487/RFC6221, May 2011,
              <https://www.rfc-editor.org/info/rfc6221>.

   [RFC6346]  Bush, R., Ed., "The Address plus Port (A+P) Approach to
              the IPv4 Address Shortage", RFC 6346,
              DOI 10.17487/RFC6346, August 2011,
              <https://www.rfc-editor.org/info/rfc6346>.

   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015,
              <https://www.rfc-editor.org/info/rfc7575>.

   [RFC7576]  Jiang, S., Carpenter, B., and M. Behringer, "General Gap
              Analysis for Autonomic Networking", RFC 7576,
              DOI 10.17487/RFC7576, June 2015,
              <https://www.rfc-editor.org/info/rfc7576>.

   [RFC8650]  Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and
              A. Bierman, "Dynamic Subscription to YANG Events and
              Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650,
              November 2019, <https://www.rfc-editor.org/info/rfc8650>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [RFC8993]  Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
              L., and J. Nobre, "A Reference Model for Autonomic
              Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
              <https://www.rfc-editor.org/info/rfc8993>.

Appendix A.  Deployment Overview

   This appendix includes logical deployment models and explanations of
   the target deployment models.  Its purpose is to help in
   understanding the mechanism described in this document.

   This appendix includes two subsections: Appendix A.1 for the two most
   common DHCP deployment models and Appendix A.2 for the PD deployment
   model described in this document.  It should be noted that these are
   just examples, and there are many more deployment models.

A.1.  Address and Prefix Management with DHCP

   Edge DHCP server deployment requires every edge router connecting to
   a Customer Premises Equipment (CPE) device to be a DHCP server
   assigning IPv4/IPv6 addresses to CPEs -- and, optionally, IPv6
   prefixes via DHCPv6-PD for IPv6-capable CPEs that are routers and
   have LANs behind them.

                                                edge
           dynamic, "NETCONF/YANG"            interfaces
            <---------------> +-------------+
   +------+    <- telemetry   | edge router/|-+  -----  +-----+
   |config|  .... domain ...  | DHCP server | |  ...    | CPE |+  LANs
   |server|                   +-------------+ |  -----  +-----+| (---| )
   +------+                    +--------------+  DHCP/   +-----+
                                                DHCPv6-PD

       Figure 2: DHCP Deployment Model without a Central DHCP Server

   This requires various coordination functions via some backend system
   (depicted as the "config server" in Figure 2): the address prefixes
   on the edge interfaces should be slightly larger than required for
   the number of CPEs connected so that the overall address space is
   best used.

   The config server needs to provision edge interface address prefixes
   and DHCP parameters for every edge router.  If prefixes that are too
   fine-grained are used, this will result in large routing tables
   across the domain shown in the figure.  If prefixes that are too
   coarse-grained are used, address space is wasted.  (This is less of a
   concern for IPv6, but if the model includes IPv4, it is a very
   serious concern.)

   There is no standard that describes algorithms for how configuration
   servers would best perform this ongoing dynamic provisioning to
   optimize routing table size and address space utilization.

   There are currently no complete YANG data models that a config server
   could use to perform these actions (including telemetry of assigned
   addresses from such distributed DHCP servers).  For example, a YANG
   data model for controlling DHCP server operations is still being
   developed [DHCP-YANG-MODEL].

   Due to these and other problems related to the above model, the more
   common DHCP deployment model is as follows:

   +------+                                      edge
   |config|    initial, "CLI"                   interfaces
   |server| ----------------> +-------------+
   +------+                   | edge router/|-+  -----  +-----+
      |     .... domain ...   | DHCP relay  | |  ...    | CPE |+  LANs
   +------+                   +-------------+ |  -----  +-----+| (---| )
   |DHCP  |                    +--------------+  DHCP/   +-----+
   |server|                                     DHCPv6-PD
   +------+

         Figure 3: DHCP Deployment Model with a Central DHCP Server

   Dynamic provisioning changes to edge routers are avoided by using a
   central DHCP server and reducing the edge router from DHCP server to
   DHCP relay.  The "configuration" on the edge routers is static.  The
   DHCP relay function inserts an "edge interface" and/or subscriber-
   identifying options into DHCP requests from CPEs (e.g., [RFC3046]
   [RFC6221]), and the DHCP server has complete policies for address
   assignments and prefixes usable on every edge router / interface /
   subscriber group.  When the DHCP relay sees the DHCP reply, it
   inserts static routes for the assigned address / address prefix into
   the routing table of the edge router; these routes are then to be
   distributed by the IGP (or BGP) inside the domain to make the CPE and
   LANs reachable across the domain shown in the figure.

   There is no comprehensive standardization of these solutions.  For
   example, [RFC8415], Section 19.1.3 simply refers to "a [non-defined]
   protocol or other out-of-band communication to configure routing
   information for delegated prefixes on any router through which the
   client may forward traffic."

A.2.  Prefix Management with ANI/GRASP

   Using the ANI and prefix management ASAs (PM-ASAs) using GRASP, the
   deployment model is intended to look as follows:

   |<............ ANI domain / ACP............>| (...) ........->

                                      Roles
                                        |
                                        v   "Edge routers"
   GRASP parameter               +----------+
    Network-wide                 |  PM-ASA  | downstream
   parameters/policies           |  (DHCP   | interfaces
        |                        |functions)| ------
        v  "central device"      +----------+
   +------+                            ^             +--------+
   |PM-ASA|      <............GRASP ....      ....   |  CPE   |-+ (LANs)
   +------+             .              v             |(PM-ASA)| |  ---|
        .           +........+   +----------+        +--------+ |
   +...........+    . PM-ASA .   |  PM-ASA  | ------  +---------+
   .DHCP server.    +........+   |  (DHCP   | SLAAC/
   +...........+  "intermediate  |functions)| DHCP/DHCP-PD
                     router"     +----------+

                 Figure 4: Deployment Model Using ANI/GRASP

   The network runs an ANI domain with an ACP [RFC8994] between some
   central device (e.g., a router or an ANI-enabled management device)
   and the edge routers.  ANI/ACP provides a secure, zero-touch
   communication channel between the devices and enables the use of
   GRASP [RFC8990] not only for peer-to-peer communication but also for
   distribution/flooding.

   The central devices and edge routers run software in the form of ASAs
   to support this document's autonomic IPv6 edge prefix management.
   PM-ASAs as discussed below together comprise the Autonomic Prefix
   Management Function.

   Edge routers can have different roles based on the type and number of
   CPEs attaching to them.  Each edge router could be an RSG, ASG, or
   CSG in mobile aggregation networks (see Section 6.1).  Mechanisms
   outside the scope of this document make routers aware of their roles.

   Some considerations related to the deployment model are as follows.

   1.  In a minimum prefix management solution, the central device uses
       the PrefixManager.Params GRASP objective introduced in this
       document to disseminate network-wide, per-role parameters to edge
       routers.  The PM-ASA uses the parameters that apply to its own
       role to locally configure preexisting addressing functions.
       Because the PM-ASA does not manage the dynamic assignment of
       actual IPv6 address prefixes in this case, the following options
       can be considered:

       1.a  The edge router connects via downstream interfaces to each
            (host) CPE that requires an address.  The PM-ASA sets up for
            each such interface a DHCP requesting router (according to
            [RFC8415]) to request an IPv6 prefix for the interface.  The
            router's address on the downstream interface can be another
            parameter from the GRASP objective.  The CPEs assign
            addresses in the prefix via Router Advertisements (RAs), or
            the PM-ASA manages a local DHCPv6 server to assign addresses
            to the CPEs.  A central DHCP server acting as the DHCP
            delegating router (according to [RFC8415]) is required.  Its
            address can be another parameter from the GRASP objective.

       1.b  The edge router also connects via downstream interfaces to
            (customer managed) CPEs that are routers and act as DHCPv6
            requesting routers.  The need to support this could be
            derived from role or GRASP parameters, and the PM-ASA sets
            up a DHCP relay function to pass on requests to the central
            DHCP server as in point 1.a.

   2.  In a solution without a central DHCP server, the PM-ASA on the
       edge routers not only learns parameters from PrefixManager.Params
       but also utilizes GRASP to request/negotiate actual IPv6 prefix
       delegation via the GRASP PrefixManager objective, as described in
       more detail below.  In the simplest case, these prefixes are
       delegated via this GRASP objective from the PM-ASA in the central
       device.  This device must be provisioned initially with a large
       pool of prefixes.  The delegated prefixes are then used by the
       PM-ASA on the edge routers to configure prefixes on their
       downstream interfaces to assign addresses via RA/SLAAC to host
       CPEs.  The PM-ASA may also start local DHCP servers (as in point
       1.a) to assign addresses via DHCP to the CPEs from the prefixes
       it received.  This includes both host CPEs requesting IPv6
       addresses and router CPEs that request IPv6 prefixes.  The PM-ASA
       needs to manage the address pool(s) it has requested via GRASP
       and allocate sub-address pools to interfaces and the local DHCP
       servers it starts.  It needs to monitor the address utilization
       and accordingly request more address prefixes if its existing
       prefixes are exhausted, or return address prefixes when they are
       unneeded.

       This solution is quite similar to the previous IPv6 DHCP
       deployment model without a central DHCP server, and ANI/ACP/GRASP
       and the PM-ASA do provide the automation to make this approach
       work more easily than is possible today.

   3.  The address pools from which prefixes are allocated do not all
       need to be taken from one central location.  An edge-router
       PM-ASA that received a big (short) prefix from a central PM-ASA
       could offer smaller sub-prefixes to a neighboring edge-router
       PM-ASA.  GRASP could be used in such a way that the PM-ASA would
       find and select the objective from the closest neighboring
       PM-ASA, therefore allowing aggregation to be maximized: a PM-ASA
       would only request further smaller prefixes when it exhausts its
       own pool (from the central location) and cannot get further large
       prefixes from that central location anymore.  Because the
       overflow prefixes taken from a topologically nearby PM-ASA, the
       number of longer prefixes that have to be injected into the
       routing tables is limited and the topological proximity increases
       the chances that aggregation of prefixes in the IGP can most
       likely limit the geography in which the longer prefixes need to
       be routed.

   4.  Instead of peer-to-peer optimization of prefix delegation, a
       hierarchy of PM-ASAs can be built (indicated in Figure 4 via a
       dotted intermediate router).  This would require additional
       parameters in the PrefixManager objective to allow the creation
       of a hierarchy of PM-ASAs across which the prefixes can be
       delegated.

   5.  In cases where CPEs are also part of the ANI domain (e.g.,
       "managed CPEs"), then GRASP will extend into the actual customer
       sites and can also run a PM-ASA.  All the options described in
       points 1 to 4 above would then apply to the CPE as the edge
       router, with the major changes being that (a) a CPE router will
       most likely not need to run DHCPv6-PD itself, but only DHCP
       address assignment and (b) the edge routers to which the CPE
       connects would most likely become ideal places on which to run a
       hierarchical instance of PD-ASAs, as outlined in point 1.

Acknowledgements

   Valuable comments were received from William Atwood, Fred Baker,
   Michael Behringer, Ben Campbell, Laurent Ciavaglia, Toerless Eckert,
   Joel Halpern, Russ Housley, Geoff Huston, Warren Kumari, Dan
   Romascanu, and Chongfeng Xie.

Authors' Addresses

   Sheng Jiang (editor)
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No. 156 Beiqing Road
   Hai-Dian District, Beijing
   100095
   China

   Email: jiangsheng@huawei.com


   Zongpeng Du
   China Mobile
   32 Xuanwumen West St
   Xicheng District, Beijing
   100053
   China

   Email: duzongpeng@chinamobile.com


   Brian Carpenter
   University of Auckland
   School of Computer Science
   PB 92019
   Auckland 1142
   New Zealand

   Email: brian.e.carpenter@gmail.com


   Qiong Sun
   China Telecom
   118 Xizhimennei St
   Beijing
   100035
   China

   Email: sunqiong@chinatelecom.cn