<?xml version="1.0" encoding="US-ASCII"?>
<!-- This can be converted using the Web service at https://xml2rfc.tools.ietf.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate --> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-anima-prefix-management-07" ipr="trust200902"> indexInclude="true" ipr="trust200902" number="8992" prepTime="2021-05-20T22:52:53" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8992" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Auto IPv6 Prefix Management">Autonomic IPv6 Edge Prefix Management in Large-scale Large-Scale Networks</title>
    <seriesInfo name="RFC" value="8992" stream="IETF"/>
    <author fullname="Sheng Jiang" initials="S." role="editor" surname="Jiang">
      <organization>Huawei
      <organization showOnFrontPage="true">Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156
          <street>No. 156 Beiqing Road</street>
          <extaddr>Q14, Huawei Campus</extaddr>
          <city>Hai-Dian District, Beijing, 100095</city>

          <country>P.R. China</country> Beijing</city>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>jiangsheng@huawei.com</email>
      </address>
    </author>
    <author fullname="Zongpeng Du" initials="Z." surname="Du">
      <organization>Huawei Technologies Co., Ltd</organization>
      <organization showOnFrontPage="true">China Mobile</organization>
      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 Beiqing Road</street>

          <city>Hai-Dian
          <street>32 Xuanwumen West St</street>
          <city>Xicheng District, Beijing, 100095</city>

          <country>P.R. China</country> Beijing</city>
          <code>100053</code>
          <country>China</country>
        </postal>

        <email>duzongpeng@huawei.com</email>
        <email>duzongpeng@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Brian Carpenter" initials="B. E." initials="B." surname="Carpenter">
      <organization abbrev="Univ. of Auckland"/> Auckland" showOnFrontPage="true">University of Auckland</organization>
      <address>
        <postal>
          <street>Department
          <extaddr>School of Computer Science</street>

          <street>University of Auckland</street> Science</extaddr>
          <street>PB 92019</street>
          <city>Auckland</city>
          <region/>
          <code>1142</code>
          <country>New Zealand</country>
        </postal>
        <email>brian.e.carpenter@gmail.com</email>
      </address>
    </author>
    <author fullname="Qiong Sun" initials="Q." surname="Sun">
      <organization>China
      <organization showOnFrontPage="true">China Telecom</organization>
      <address>
        <postal>
          <street>No.118,
          <street>118 Xizhimennei Street</street> St</street>
          <city>Beijing</city>
          <code>100035</code>

          <country>P. R. China</country>
          <country>China</country>
        </postal>

        <email>sunqiong@ctbri.com.cn</email>
        <email>sunqiong@chinatelecom.cn</email>
      </address>
    </author>
    <date day="" month="" year="2017"/> month="05" year="2021"/>
    <area>Operations and Management</area>

    <workgroup>ANIMA WG</workgroup>
    <workgroup>ANIMA</workgroup>
    <keyword>Autonomic Networking, Prefix Networking</keyword>
    <keyword>Prefix Management</keyword>

    <abstract>
      <t>This
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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 the this document is to use it for validation of the design of various
      components of the autonomic networking infrastructure.</t> Autonomic Networking Infrastructure.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8992" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-problem-statement">Problem Statement</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-user-and-administr">Intended User and Administrator Experience</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-analysis-of-parameters-and-">Analysis of Parameters and Information Involved</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-parameters-each-device-can-">Parameters Each Device Can Define for Itself</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-information-needed-from-net">Information Needed from Network Operations</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.3.1"><xref derivedContent="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-comparison-with-current-sol">Comparison with Current Solutions</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-other-devi">Interaction with Other Devices</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-information-needed-from-oth">Information Needed from Other Devices</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.2.1"><xref derivedContent="3.3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-monitoring-diagnostics-and-">Monitoring, Diagnostics, and Reporting</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-autonomic-edge-prefix-manag">Autonomic Edge Prefix Management Solution</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-behavior-of-a-device-reques">Behavior of a Device Requesting a Prefix</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-behavior-of-a-device-provid">Behavior of a Device Providing a Prefix</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-behavior-after-successful-n">Behavior after Successful Negotiation</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-prefix-logging">Prefix Logging</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-autonomic-prefix-management">Autonomic Prefix Management Objectives</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-edge-prefix-objective-optio">Edge Prefix Objective Option</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipv4-extension">IPv4 Extension</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-prefix-management-parameter">Prefix Management Parameters</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-of-prefix-managemen">Example of Prefix Management Parameters</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment-overview">Deployment Overview</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-address-and-prefix-manageme">Address and Prefix Management with DHCP</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-prefix-management-with-ani-">Prefix Management with ANI/GRASP</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" title="Introduction">

       <t>The numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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 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.</t>

      <t>This
      <t indent="0" pn="section-1-2">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 (AN) is described in <xref target="RFC7575"/> target="RFC7575" format="default" sectionFormat="of" derivedContent="RFC7575"/>
      and <xref target="RFC7576"/>. target="RFC7576" format="default" sectionFormat="of" derivedContent="RFC7576"/>. The GeneRic Autonomic Signaling Protocol (GRASP) is
      specified by <xref target="I-D.ietf-anima-grasp"/> target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/> and can make use of
      the proposed 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 autonomic networking infrastructure ANI as
      described in <xref target="I-D.ietf-anima-reference-model"/>.</t>

      <t>This target="RFC8993" format="default" sectionFormat="of" derivedContent="RFC8993"/>.</t>
      <t indent="0" pn="section-1-3">This document is not a complete functional specification of an
      autonomic prefix management system 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.</t>

      <t>This
      <t indent="0" pn="section-1-4">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. The 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
      service provider
      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, Autonomic Network, to a single management
      domain.</t>

      <t>However,
      <t indent="0" pn="section-1-5">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.</t>

     <t>A
      <t indent="0" pn="section-1-6">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 about regarding prefix lifetimes,
      and they may prefer to have centralized or distributed pools of spare
      prefixes. In an autonomic network, Autonomic Network, these are properties decided upon by the
      design of the relevant ASAs. The GRASP objectives are simply building
      blocks.
      </t>

      <t>A
      <t indent="0" pn="section-1-7">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.</t>
    </section>

    <!-- intro -->
    <section anchor="terms" title="Terminology">
      <t>The numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP 14
       <xref target="RFC2119"/> <xref target="RFC8174"/> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>

      <t>This
      <t indent="0" pn="section-2-2">This document uses terminology defined in <xref target="RFC7575"/>.</t> target="RFC7575" format="default" sectionFormat="of" derivedContent="RFC7575"/>.</t>
    </section>

    <!-- term -->
    <section anchor="problem" title="Problem Statement">
      <t>The autonomic networking numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-problem-statement">Problem Statement</name>
      <t indent="0" pn="section-3-1">The Autonomic Networking use case considered here is autonomic IPv6
      prefix management at the edge of large-scale ISP networks.</t>

      <t>Although DHCPv6
      <t indent="0" pn="section-3-2">Although DHCPv6-PD (DHCPv6 Prefix Delegation Delegation) <xref target="RFC3633"/> target="RFC8415" format="default" sectionFormat="of" derivedContent="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.</t>

      <t>The
      <t indent="0" pn="section-3-3">The problem to be solved by autonomic networking 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 AN 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 <xref target="I-D.ietf-anima-grasp"/> target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/> is
      intended to be such a protocol.</t>
      <section anchor="experience" title="Intended numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-intended-user-and-administr">Intended User and Administrator Experience">
        <t>The Experience</name>
        <t indent="0" pn="section-3.1-1">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.</t>

        <t>The
        <t indent="0" pn="section-3.1-2">The actual prefix usage needs to be logged for potential offline
        management operations operations, including audit and security incident
        tracing.</t>
      </section>
      <section anchor="params" title="Analysis numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-analysis-of-parameters-and-">Analysis of Parameters and Information Involved">
        <t>For Involved</name>
        <t indent="0" pn="section-3.2-1">For specific purposes of address management, a few parameters are
        involved on each edge device (some will implement
        several parameters. (Some of them can be pre-configured preconfigured
        before they are connected). connected.) They include:</t>

        <t><list style="symbols">
            <t>Identity, authentication include the following:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-2">
          <li pn="section-3.2-2.1">Identity, authentication, and authorization of this device. This
            is expected to use the autonomic networking Autonomic Networking secure bootstrap
            process <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>, target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>,
            following which the device could safely take part in autonomic
            operations.</t>

            <t>Role
            operations.</li>
          <li pn="section-3.2-2.2">Role of this device. Some example roles are discussed in <xref target="exparam"/>.</t>

            <t>An target="exparam" format="default" sectionFormat="of" derivedContent="Section 6.1"/>.</li>
          <li pn="section-3.2-2.3">An IPv6 prefix length for this device.</t>

            <t>An device.</li>
          <li pn="section-3.2-2.4">An IPv6 prefix that is assigned to this device and its
            downstream devices.</t>
          </list>A few parameters are involved in the devices.</li>
        </ul>
        <t indent="0" pn="section-3.2-3">The network as a whole. They
        are:</t>

        <t><list style="symbols">
            <t>Identity whole will implement the following parameters:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-4">
          <li pn="section-3.2-4.1">Identity of a trust anchor, which is a certification authority
            (CA) maintained by the network administrators, used during the
            secure bootstrap process.</t>

            <t>Total process.</li>
          <li pn="section-3.2-4.2">Total IPv6 address space available for edge devices. It is a pool
            of one or several IPv6 prefixes.</t>

            <t>The prefixes.</li>
          <li pn="section-3.2-4.3">The initial prefix length for each device role.</t>
          </list></t> role.</li>
        </ul>
        <section anchor="device" title="Parameters each device can define for itself">
          <t>This numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-parameters-each-device-can-">Parameters Each Device Can Define for Itself</name>
          <t indent="0" pn="section-3.2.1-1">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. There They are few of these:</t>

          <t><list style="symbols">
              <t>Default as follows:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.1-2">
            <li pn="section-3.2.1-2.1">Default role of this device.</t>

              <t>Default device.</li>
            <li pn="section-3.2.1-2.2">Default IPv6 prefix length for this device.</t>

              <t>Cryptographic device.</li>
            <li pn="section-3.2.1-2.3">Cryptographic identity of this device, as needed for secure bootstrapping
              <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t>
            </list>The target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.</li>
          </ul>
          <t indent="0" pn="section-3.2.1-3">The device may be shipped from the manufacturer with
          pre-configured a
          preconfigured role and default prefix length, which could be
          modified by an autonomic mechanism. Its cryptographic identity will be installed
          by its manufacturer.</t>
        </section>

        <!-- device -->
        <section anchor="opparams" title="Information needed numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2">
          <name slugifiedName="name-information-needed-from-net">Information Needed from network operations">
          <t>This Network Operations</name>
          <t indent="0" pn="section-3.2.2-1">This section identifies those parameters that might need
          operational input in order for the devices concerned to set them to
          a non-default value.</t>

          <t><list style="symbols">
              <t>Non-default
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.2-2">
            <li pn="section-3.2.2-2.1">Non-default value for the IPv6 prefix length for this device.
              This needs to be decided based on the role of this device.</t>

              <t>The device.</li>
            <li pn="section-3.2.2-2.2">The initial prefix length for each device role.</t>

              <t>Whether role.</li>
            <li pn="section-3.2.2-2.3">Whether to allow the device to request more address
              space.</t>

              <t>The
              space.</li>
            <li pn="section-3.2.2-2.4">The policy regarding when to request more address space, space -- for example,
              if the address usage reaches a certain limit or percentage.</t>
            </list></t> percentage.</li>
          </ul>
        </section>
        <section anchor="compare" title="Comparison numbered="true" toc="include" removeInRFC="false" pn="section-3.2.3">
          <name slugifiedName="name-comparison-with-current-sol">Comparison with current solutions">
          <t>This Current Solutions</name>
          <t indent="0" pn="section-3.2.3-1">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.</t>

          <t>Some
          <t indent="0" pn="section-3.2.3-2">Some autonomic and dynamic address management functions may be
          achievable by extending the existing protocols, protocols -- for example,
          extending DHCPv6-PD (DHCPv6 Prefix Delegation, <xref target="RFC3633"/>) target="RFC8415" format="default" sectionFormat="of" derivedContent="RFC8415"/>
          to request IPv6 prefixes according to the device
          role. However, defining uniform device roles may not be a practical
          task. Some
          task, as some functions are not suitable to cannot be achieved by any configured on the basis of role using
          existing prefix delegation protocols.</t>

          <t>Using
          <t indent="0" pn="section-3.2.3-3">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.</t>
        </section>
      </section>
      <section anchor="interact" title="Interaction numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-interaction-with-other-devi">Interaction with other devices"> Other Devices</name>
        <section anchor="peers" title="Information needed numbered="true" toc="include" removeInRFC="false" pn="section-3.3.1">
          <name slugifiedName="name-information-needed-from-oth">Information Needed from other devices">
          <t>This Other Devices</name>
          <t indent="0" pn="section-3.3.1-1">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.</t>

          <t><list style="symbols">
              <t>Identity
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3.1-2">
            <li pn="section-3.3.1-2.1">Information regarding the identity of a trust anchor.</t>

              <t>The anchor is needed.</li>
            <li pn="section-3.3.1-2.2">The device will need to discover a device, another device from which it can
              acquire IPv6 address space.</t>

              <t>The space.</li>
            <li pn="section-3.3.1-2.3">Information regarding the initial prefix length for the role of each device role, is needed, particularly
              for its own downstream devices.</t>

              <t>The devices.</li>
            <li pn="section-3.3.1-2.4">The default value of the IPv6 prefix length may be overridden
              by a non-default value.</t>

              <t>The value.</li>
            <li pn="section-3.3.1-2.5">The device will need to request and acquire one or more IPv6 prefixes that
              can be assigned to this device and its downstream devices.</t>

              <t>The devices.</li>
            <li pn="section-3.3.1-2.6">The device may respond to prefix delegation requests from its
              downstream devices.</t>

              <t>The devices.</li>
            <li pn="section-3.3.1-2.7">The device may require to be assigned the assignment of more IPv6 address
              space,
              space if it used up its assigned IPv6 address space.</t>
            </list></t> space.</li>
          </ul>
        </section>

        <!-- peers -->
        <section anchor="monitor" title="Monitoring, diagnostics and reporting">
          <t>This numbered="true" toc="include" removeInRFC="false" pn="section-3.3.2">
          <name slugifiedName="name-monitoring-diagnostics-and-">Monitoring, Diagnostics, and Reporting</name>
          <t indent="0" pn="section-3.3.2-1">This section discusses what role devices should play in
          monitoring, fault diagnosis, and reporting.</t>

          <t><list style="symbols">
              <t>The
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3.2-2">
            <li pn="section-3.3.2-2.1">The actual address assignments need to be logged for
              potential offline management operations.</t>

              <t>In operations.</li>
            <li pn="section-3.3.2-2.2">In general, the usage situation of regarding address space should be
              reported to the network administrators, administrators in an abstract way, way -- for
              example, statistics or a visualized report.</t>

              <t>A report.</li>
            <li pn="section-3.3.2-2.3">A forecast of address exhaustion should be reported.</t>
            </list></t> reported.</li>
          </ul>
        </section>

        <!-- monitor -->
      </section>
    </section>
    <section title="Autonomic numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-autonomic-edge-prefix-manag">Autonomic Edge Prefix Management Solution">
      <t>This Solution</name>
      <t indent="0" pn="section-4-1">This section introduces the building blocks for
      an autonomic edge prefix management solution.
      As noted in <xref target="intro"/>, target="intro" format="default" sectionFormat="of" derivedContent="Section 1"/>, this is not a complete description of
      a solution, which will depend on the detailed design of the relevant
      Autonomic Service Agents. Agents (ASAs).
      It uses the generic discovery and negotiation protocol defined
      by <xref target="I-D.ietf-anima-grasp"/>. target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>. The relevant GRASP objectives
      are defined in <xref target="prefixNegoOptions"/>.</t>

      <t>The target="prefixNegoOptions" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
      <t indent="0" pn="section-4-2">The procedures described below are carried out by an Autonomic
      Service Agent (ASA) ASA in each device that participates in the solution. We
      will refer to this as the PrefixManager ASA.</t>
      <section anchor="reqbehave" title="Behaviors on prefix requesting device">
        <t>If numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-behavior-of-a-device-reques">Behavior of a Device Requesting a Prefix</name>
        <t indent="0" pn="section-4.1-1">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 by via
        the mechanism described in <xref target="prefixManageParams"/>. target="prefixManageParams" format="default" sectionFormat="of" derivedContent="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.</t>

        <t>A
        <t indent="0" pn="section-4.1-2">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 <xref target="prefixObjOption"/>) target="RFC8650" section="2" relative="figure-1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/figure-1" derivedContent="RFC8650"/> and <xref target="prefixObjOption" format="default" sectionFormat="of" derivedContent="Section 5.1"/>) in
        order to discover peers also supporting that option. Then Then, it should
        choose one such peer, most likely the first to respond.</t>

        <t>If
        <t indent="0" pn="section-4.1-3">If the GRASP discovery Discovery Response message carries a divert Divert option
        pointing to an off-link PrefixManager ASA, the requesting ASA may
        initiate negotiation with that ASA diverted ASA-diverted device to find out whether
        it can provide the requested length of the prefix.</t>

        <t>In
        <t indent="0" pn="section-4.1-4">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.
        <!--and whether the ASA supports the DHCPv6 Prefix
        Delegation (PD) function <xref target="RFC3633"/>.-->
        This starts a GRASP negotiation process.</t>

        <t>During
        <t indent="0" pn="section-4.1-5">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, is an are implementation choice.</t>

        <t>The choices.</t>
        <t indent="0" pn="section-4.1-6">The ASA could alternatively initiate rapid mode GRASP discovery in rapid mode
        with an embedded negotiation request, if it is implemented.</t>
      </section>
      <section title="Behaviors on prefix providing device">
        <t>At numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-behavior-of-a-device-provid">Behavior of a Device Providing a Prefix</name>
        <t indent="0" pn="section-4.2-1">At least one device on the network must be configured with
        the initial pool of available prefixes mentioned in <xref target="params"/>. target="params" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.
        Apart from that requirement, any device may act as a prefix providing device.</t>

        <t>A provider of prefixes.</t>
        <t indent="0" pn="section-4.2-2">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 <xref target="I-D.ietf-anima-grasp"/>. target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>. When
        this ASA receives a subsequent Request message, it should conduct a
        GRASP negotiation sequence, using Negotiate, Confirm-waiting, Confirm Waiting, and
        Negotiation-ending
        Negotiation End messages as appropriate. The Negotiate messages
        carry a PrefixManager Objective option, <!--. This will indicate whether
        the sending device supports the PD function. More importantly, it-->
        which will indicate the prefix and its length offered to the requesting ASA. As
        described in <xref target="I-D.ietf-anima-grasp"/>, target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>, negotiation will
        continue until either end stops it with a Negotiation-ending Negotiation End message.
        If the negotiation succeeds, the prefix providing 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-ending Negotiation End
        message may include an error code string.</t>

        <t>During
        <t indent="0" pn="section-4.2-3">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,
        is an
        are implementation choice.</t>

        <t>The choices.</t>
        <t indent="0" pn="section-4.2-4">The ASA could alternatively negotiate in response to rapid mode GRASP discovery, discovery in  rapid mode, if it is implemented.</t>

        <t>This
        <t indent="0" pn="section-4.2-5">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
        provide
        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 Redirect 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.</t>

        <t>A
        <t indent="0" pn="section-4.2-6">A resource shortage may cause the gateway router to request more
        resource
        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 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.</t>

        <t>The
        <t indent="0" pn="section-4.2-7">The algorithm used to choose which prefixes to assign on the prefix
        providing devices that
        provide prefixes is an implementation choice.</t>
      </section>
      <section title="Behavior numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-behavior-after-successful-n">Behavior after Successful Negotiation">
        <t>Upon Negotiation</name>
        <t indent="0" pn="section-4.3-1">Upon receiving a GRASP Negotiation-ending Negotiation End message that indicates
        that an acceptable prefix length is available, the requesting device
        may use the negotiated prefix without further messages.</t>

        <t>There
        <t indent="0" pn="section-4.3-2">There are use cases where the ANI/GRASP based ANI/GRASP-based prefix
        management approach can work together with DHCPv6-PD <xref target="RFC3633"/> target="RFC8415" format="default" sectionFormat="of" derivedContent="RFC8415"/>
        as a complement. For example, the ANI/GRASP based 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 client clients (non-ANI devices). Another similar use case would be
        ANI/GRASP inside the domain, with
        RADIUS <xref target="RFC2865"/> target="RFC2865" format="default" sectionFormat="of" derivedContent="RFC2865"/> providing prefixes to client devices.</t>
      </section>
      <section title="Prefix logging">
        <t>Within numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-prefix-logging">Prefix Logging</name>
        <t indent="0" pn="section-4.4-1">Within the autonomic prefix management, management system, all the prefix assignment
        is assignments are
        done by devices without human intervention. It may be required
        to record
        that all the prefix assignment history, history be recorded -- for example example, to detect
        or trace lost prefixes after outages, outages or to meet legal requirements.
        However, the logging and reporting process is out of scope for this
        document.</t>
      </section>
    </section>
    <section anchor="prefixNegoOptions" title="Autonomic numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-autonomic-prefix-management">Autonomic Prefix Management Objectives">
      <t>This Objectives</name>
      <t indent="0" pn="section-5-1">This section defines the GRASP technical objective options that are used to support
      autonomic prefix management.</t>
      <section anchor="prefixObjOption" title="Edge numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-edge-prefix-objective-optio">Edge Prefix Objective Option">
        <t>The Option</name>
        <t indent="0" pn="section-5.1-1">The PrefixManager Objective option is a GRASP objective Objective option
        conforming to the GRASP specification <xref target="I-D.ietf-anima-grasp"/>. target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>. Its name is
        "PrefixManager" (see <xref target="iana"/>) target="iana" format="default" sectionFormat="of" derivedContent="Section 8"/>), and it carries the following
        data items as its value: <!-- the PD support flag, -->the prefix length, length and
        the actual prefix bits. Since GRASP is based on CBOR (Concise Binary Object Representation Representation)
        <xref target="RFC7049"/>), target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>, the format of the PrefixManager Objective
        option is described as follows in CBOR data definition language the Concise Data Definition Language (CDDL)
        <xref target="I-D.ietf-cbor-cddl"/>:</t>

        <figure>
          <artwork><![CDATA[ target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> as follows:</t>
        <sourcecode type="cddl" markers="false" pn="section-5.1-2">
  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
  ]]></artwork>
        </figure>
        <t>The
</sourcecode>
        <t indent="0" pn="section-5.1-3">The use of the 'dry run' "dry run" mode of GRASP is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> 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
        dry-run negotiation.</t>
      </section>
      <section anchor="ipv4" title="IPv4 extension">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-ipv4-extension">IPv4 Extension</name>
        <t indent="0" pn="section-5.2-1">This section presents an extended version of the
      PrefixManager Objective objective that supports IPv4 by adding an extra flag:
      <figure>
          <artwork><![CDATA[
        </t>
        <sourcecode type="cddl" markers="false" pn="section-5.2-2">
  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
  ]]></artwork>
        </figure> </t>

        <t>Prefix
</sourcecode>
        <t indent="0" pn="section-5.2-3">Prefix and address management for IPv4 is considerably more difficult
        than for IPv6, due to the prevalence of NAT, ambiguous addresses <xref target="RFC1918"/>, target="RFC1918" format="default" sectionFormat="of" derivedContent="RFC1918"/>,
        and address sharing <xref target="RFC6346"/>. target="RFC6346" format="default" sectionFormat="of" derivedContent="RFC6346"/>. These complexities might require further extending
        the objective with additional fields which that are not defined by this document.</t>
      </section>
    </section>
    <section anchor="prefixManageParams" title="Prefix numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-prefix-management-parameter">Prefix Management Parameters">
      <t>An Parameters</name>
      <t indent="0" pn="section-6-1">An implementation of a prefix manager MUST <bcp14>MUST</bcp14> include default settings
      of all necessary parameters. However, within a single administrative
      domain, the network operator MAY <bcp14>MAY</bcp14> change default parameters for all
      devices with a certain role. Thus Thus, it would be possible to apply an
      intended policy for every device in a simple way, without traditional
      configuration files. As noted in <xref target="reqbehave"/>, target="reqbehave" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, individual
      autonomic devices may also change their own behavior dynamically.</t>

      <t>For
      <t indent="0" pn="section-6-2">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 <bcp14>MAY</bcp14> be flooded in the network, through the Autonomic
      Control Plane (ACP) <xref target="I-D.ietf-anima-autonomic-control-plane"/>. target="RFC8994" format="default" sectionFormat="of" derivedContent="RFC8994"/>.
      The objective is defined in CDDL as follows:</t>

      <figure>
        <artwork><![CDATA[
      <sourcecode type="cddl" markers="false" pn="section-6-3">
  objective = ["PrefixManager.Params", objective-flags, any]

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

    ]]></artwork>
      </figure>

      <t>The 'any'
</sourcecode>
      <t indent="0" pn="section-6-4">The "any" object would be the relevant parameter definitions (such as
      the example below) transmitted as a CBOR object in an appropriate
      format.</t>

      <t>This
      <t indent="0" pn="section-6-5">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.</t>
      <section anchor="exparam" title="Example numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-example-of-prefix-managemen">Example of Prefix Management Parameters">
        <t>The Parameters</name>
        <t indent="0" pn="section-6.1-1">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:</t>

        <figure>
          <artwork><![CDATA[
        <sourcecode type="json" markers="false" pn="section-6.1-2">
[
   [["role", "RSG"],["prefix_length", 34]],
   [["role", "ASG"],["prefix_length", 44]],
   [["role", "CSG"],["prefix_length", 56]]
]
]]></artwork>
        </figure>

        <t>This
</sourcecode>
        <t indent="0" pn="section-6.1-3">This example is expressed in JSON notation <xref target="RFC7159"/>, target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/>, which is easy to represent in CBOR.</t>

        <t>An
        <t indent="0" pn="section-6.1-4">An alternative would be to express the parameters in YANG <xref target="RFC7950"/> target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> using the YANG-to-CBOR mapping <xref target="I-D.ietf-core-yang-cbor"/>.</t>

        <t>For target="CORE-YANG-CBOR" format="default" sectionFormat="of" derivedContent="CORE-YANG-CBOR"/>.</t>
        <t indent="0" pn="section-6.1-5">For clarity, the background of the example is introduced below,
        which below
        and can also be regarded as a use case of for the mechanism proposed defined in
        this document.</t>

        <t>An
        <t indent="0" pn="section-6.1-6">An IPRAN network is used for mobile backhaul, including radio
        stations, RNC RNCs (Radio Network Controllers) (in 3G) or the packet core (in LTE), and the IP network
        between them them, as shown in Figure 1. <xref target="IPRAN-topology" format="default" sectionFormat="of" derivedContent="Figure 1"/>. The eNB (Evolved Node B), RNC
        (Radio Network Controller), B) entities, the RNC, the SGW (Service (Serving Gateway), and the MME (Mobility
        Management Entity) are mobile network entities defined in 3GPP. The
        CSG, ASG,
        CSGs, ASGs, and RSG RSGs are entities defined in the IPRAN solution.</t>

        <t>The
        <t indent="0" pn="section-6.1-7">The IPRAN topology shown in Figure 1 <xref target="IPRAN-topology" format="default" sectionFormat="of" derivedContent="Figure 1"/>
        includes Ring1 Ring1, which is the
        circle following ASG1-&gt;RSG1-&gt;RSG2-&gt;ASG2-&gt;ASG1, Ring2 ASG1-&gt;RSG1-&gt;RSG2-&gt;ASG2-&gt;ASG1; Ring2,
        following CSG1-&gt;ASG1-&gt;ASG2-&gt;CSG2-&gt;CSG1, CSG1-&gt;ASG1-&gt;ASG2-&gt;CSG2-&gt;CSG1; and Ring3 Ring3,
        following CSG3-&gt;ASG1-&gt;ASG2-&gt;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.</t>

        <t><figure>
            <artwork><![CDATA[
        <figure anchor="IPRAN-topology" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-ipran-topology-example">IPRAN Topology Example</name>
          <artwork name="" type="" align="left" alt="" pn="section-6.1-8.1">
+------+   +------+
| eNB1 |---| CSG1 |\
+------+   +------+  \   +-------+       +------+           +-------+
               |       \ |  ASG1 |-------| RSG1 |-----------|SGW/MME|
               |  Ring2  +-------+       +------+ \        /+-------+
+------+   +------+     /     |              |      \    /
| eNB2 |---| CSG2 | \  /      |      Ring1   |        \/
+------+   +------+   \  Ring3|              |        /\
                     / \      |              |      /   \
+------+   +------+ /    \ +-------+      +------+/       \+-------+
| eNB3 |---| CSG3 |--------|  ASG2 |------| RSG2 |---------|  RNC  |
+------+   +------+        +-------+      +------+         +-------+

                Figure 1: IPRAN Topology Example]]></artwork>
          </figure></t>

        <t>If
</artwork>
        </figure>
        <t indent="0" pn="section-6.1-9">If ANI/GRASP is supported in the IPRAN network, IPRAN, the network nodes
        should be able to negotiate with each other, other and make some autonomic
        decisions according to their own status and the information
        collected from the network. The Prefix Management Parameters prefix management parameters should be
        part of the information they communicate.</t>

        <t>The
        <t indent="0" pn="section-6.1-10">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 an 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.</t>
      </section>
    </section>
    <section anchor="security" title="Security Considerations">
      <t>Relevant numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">Relevant security issues are discussed in <xref target="I-D.ietf-anima-grasp"/>. target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>. The preferred security model is that
      devices are trusted following the secure bootstrap procedure <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/> and that a secure
      Autonomic Control Plane (ACP) <xref target="I-D.ietf-anima-autonomic-control-plane"/> target="RFC8994" format="default" sectionFormat="of" derivedContent="RFC8994"/> is in place.</t>

      <t>It
      <t indent="0" pn="section-7-2">It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that DHCPv6-PD, if used, should be operated implemented using
      DHCPv6 authentication or Secure DHCPv6.</t>
    </section>

    <!-- security -->
    <section anchor="iana" title="IANA Considerations">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">This document defines two new GRASP Objective Option names, option names:
      "PrefixManager" and "PrefixManager.Params". The IANA "PrefixManager.Params". The IANA has added
      these to the "GRASP Objective Names" registry defined by <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>.</t>
    </section>
  </middle>
  <back>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" quoteTitle="true" derivedAnchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" quoteTitle="true" derivedAnchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="December"/>
            <abstract>
              <t indent="0">JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t indent="0">This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC8415" target="https://www.rfc-editor.org/info/rfc8415" quoteTitle="true" derivedAnchor="RFC8415">
          <front>
            <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
            <author initials="T." surname="Mrugalski" fullname="T. Mrugalski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Siodelski" fullname="M. Siodelski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Volz" fullname="B. Volz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Yourtchenko" fullname="A. Yourtchenko">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Richardson" fullname="M. Richardson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Jiang" fullname="S. Jiang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Lemon" fullname="T. Lemon">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Winters" fullname="T. Winters">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="November"/>
            <abstract>
              <t indent="0">This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes.  DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).</t>
              <t indent="0">This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283).  In addition, this document clarifies the interactions between models of operation (RFC 7550).  As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8415"/>
          <seriesInfo name="DOI" value="10.17487/RFC8415"/>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author initials="H." surname="Birkholz" fullname="H. Birkholz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Vigano" fullname="C. Vigano">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="June"/>
            <abstract>
              <t indent="0">This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC8990" target="https://www.rfc-editor.org/info/rfc8990" quoteTitle="true" derivedAnchor="RFC8990">
          <front>
            <title>GeneRic Autonomic Signaling Protocol (GRASP)</title>
            <author initials="C" surname="Bormann" fullname="Carsten Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B" surname="Carpenter" fullname="Brian Carpenter" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B" surname="Liu" fullname="Bing Liu" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8990"/>
          <seriesInfo name="DOI" value="10.17487/RFC8990"/>
        </reference>
        <reference anchor="RFC8994" target="https://www.rfc-editor.org/info/rfc8994" quoteTitle="true" derivedAnchor="RFC8994">
          <front>
            <title>An Autonomic Control Plane (ACP)</title>
            <author initials="T" surname="Eckert" fullname="Toerless Eckert" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Behringer" fullname="Michael Behringer" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Bjarnason" fullname="Steinthor Bjarnason">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8994"/>
          <seriesInfo name="DOI" value="10.17487/RFC8994"/>
        </reference>
        <reference anchor="RFC8995" target="https://www.rfc-editor.org/info/rfc8995" quoteTitle="true" derivedAnchor="RFC8995">
          <front>
            <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
            <author initials="M" surname="Pritikin" fullname="Max Pritikin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Richardson" fullname="Michael Richardson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Eckert" fullname="Toerless Eckert">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Behringer" fullname="Michael Behringer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="Kent Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8995"/>
          <seriesInfo name="DOI" value="10.17487/RFC8995"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="CORE-YANG-CBOR" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-core-yang-cbor-15" derivedAnchor="CORE-YANG-CBOR">
          <front>
            <title>CBOR Encoding of Data Modeled with YANG</title>
            <author initials="M" surname="Veillette" fullname="Michel Veillette" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I" surname="Petrov" fullname="Ivaylo Petrov" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A" surname="Pelov" fullname="Alexander Pelov">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" day="24" year="2021"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-yang-cbor-15"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="DHCP-YANG-MODEL" quoteTitle="true" target="https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-07" derivedAnchor="DHCP-YANG-MODEL">
          <front>
            <title>Yang Data Model for DHCP Protocol</title>
            <author initials="B" surname="Liu" fullname="Bing Liu" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K" surname="Lou" fullname="Kunkun Lou">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Chen" fullname="Chin Chen">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="October" day="12" year="2018"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-liu-dhc-dhcp-yang-model-07"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC1918" target="https://www.rfc-editor.org/info/rfc1918" quoteTitle="true" derivedAnchor="RFC1918">
          <front>
            <title>Address Allocation for Private Internets</title>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Moskowitz" fullname="B. Moskowitz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Karrenberg" fullname="D. Karrenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G. J." surname="de Groot" fullname="G. J. de Groot">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Lear" fullname="E. Lear">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="February"/>
            <abstract>
              <t indent="0">This document describes address allocation for private internets.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="5"/>
          <seriesInfo name="RFC" value="1918"/>
          <seriesInfo name="DOI" value="10.17487/RFC1918"/>
        </reference>
        <reference anchor="RFC2865" target="https://www.rfc-editor.org/info/rfc2865" quoteTitle="true" derivedAnchor="RFC2865">
          <front>
            <title>Remote Authentication Dial In User Service (RADIUS)</title>
            <author initials="C." surname="Rigney" fullname="C. Rigney">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Willens" fullname="S. Willens">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Rubens" fullname="A. Rubens">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Simpson" fullname="W. Simpson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000" month="June"/>
            <abstract>
              <t indent="0">This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2865"/>
          <seriesInfo name="DOI" value="10.17487/RFC2865"/>
        </reference>
        <reference anchor="RFC3046" target="https://www.rfc-editor.org/info/rfc3046" quoteTitle="true" derivedAnchor="RFC3046">
          <front>
            <title>DHCP Relay Agent Information Option</title>
            <author initials="M." surname="Patrick" fullname="M. Patrick">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2001" month="January"/>
            <abstract>
              <t indent="0">Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts.  It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment.  However, a number of security and scaling problems arise with such "public" DHCP use.  This document describes a new DHCP option to address these issues.  This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3046"/>
          <seriesInfo name="DOI" value="10.17487/RFC3046"/>
        </reference>
        <reference anchor="RFC6221" target="https://www.rfc-editor.org/info/rfc6221" quoteTitle="true" derivedAnchor="RFC6221">
          <front>
            <title>Lightweight DHCPv6 Relay Agent</title>
            <author initials="D." surname="Miles" fullname="D. Miles" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Ooghe" fullname="S. Ooghe">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Dec" fullname="W. Dec">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Krishnan" fullname="S. Krishnan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Kavanagh" fullname="A. Kavanagh">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="May"/>
            <abstract>
              <t indent="0">This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces.  The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6221"/>
          <seriesInfo name="DOI" value="10.17487/RFC6221"/>
        </reference>
        <reference anchor="RFC6346" target="https://www.rfc-editor.org/info/rfc6346" quoteTitle="true" derivedAnchor="RFC6346">
          <front>
            <title>The Address plus Port (A+P) Approach to the IPv4 Address Shortage</title>
            <author initials="R." surname="Bush" fullname="R. Bush" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="August"/>
            <abstract>
              <t indent="0">We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses.  Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.</t>
              <t indent="0">This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P).  Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications.  This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range.  In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host.  If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core.  This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6346"/>
          <seriesInfo name="DOI" value="10.17487/RFC6346"/>
        </reference>
        <reference anchor="RFC7575" target="https://www.rfc-editor.org/info/rfc7575" quoteTitle="true" derivedAnchor="RFC7575">
          <front>
            <title>Autonomic Networking: Definitions and Design Goals</title>
            <author initials="M." surname="Behringer" fullname="M. Behringer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Bjarnason" fullname="S. Bjarnason">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Clemm" fullname="A. Clemm">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Jiang" fullname="S. Jiang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Ciavaglia" fullname="L. Ciavaglia">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t indent="0">Autonomic systems were first described in 2001.  The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection.  This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems.  It usually implies distribution across network elements.</t>
              <t indent="0">This document defines common language and outlines design goals (and what are not design goals) for autonomic functions.  A high-level reference model illustrates how functional elements in an Autonomic Network interact.  This document is a product of the IRTF's Network Management Research Group.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7575"/>
          <seriesInfo name="DOI" value="10.17487/RFC7575"/>
        </reference>
        <reference anchor="RFC7576" target="https://www.rfc-editor.org/info/rfc7576" quoteTitle="true" derivedAnchor="RFC7576">
          <front>
            <title>General Gap Analysis for Autonomic Networking</title>
            <author initials="S." surname="Jiang" fullname="S. Jiang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Behringer" fullname="M. Behringer">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t indent="0">This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices.  The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators.  Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.</t>
              <t indent="0">This document is a product of the IRTF's Network Management Research Group.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7576"/>
          <seriesInfo name="DOI" value="10.17487/RFC7576"/>
        </reference>
        <reference anchor="RFC8650" target="https://www.rfc-editor.org/info/rfc8650" quoteTitle="true" derivedAnchor="RFC8650">
          <front>
            <title>Dynamic Subscription to YANG Events and Datastores over RESTCONF</title>
            <author initials="E." surname="Voit" fullname="E. Voit">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Rahman" fullname="R. Rahman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Nilsen-Nygaard" fullname="E. Nilsen-Nygaard">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Clemm" fullname="A. Clemm">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="November"/>
            <abstract>
              <t indent="0">This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8650"/>
          <seriesInfo name="DOI" value="10.17487/RFC8650"/>
        </reference>
        <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true" derivedAnchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="December"/>
            <abstract>
              <t indent="0">The Concise Binary Object Representation (CBOR) is requested to add
      these to a data format whose design goals include the GRASP Objective Names Table registry defined by <xref target="I-D.ietf-anima-grasp"/> (if approved).</t>
    </section>

    <!-- iana -->

    <section anchor="ack" title="Acknowledgements">
      <t>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.</t>

      <!-- <t>This document was produced using possibility of extremely small code size, fairly small message size, and extensibility without the xml2rfc tool <xref target="RFC7749"/>.</t> -->
    </section>

    <!-- ack -->

    <section anchor="changes" title="Change log [RFC Editor: Please remove]">
      <t>draft-jiang-anima-prefix-management-00: original version,
      2014-10-25.</t>

      <t>draft-jiang-anima-prefix-management-01: add intent example need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and
      coauthor Zongpeng Du, 2015-05-04.</t>

      <t>draft-jiang-anima-prefix-management-02: update references MessagePack.</t>
              <t indent="0">This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049.  It does not create a new version of the prefix management intent, 2015-10-14.</t>

      <t>draft-ietf-anima-prefix-management-00: WG adoption, clarify scope and
      purpose, update text to match latest GRASP spec, 2016-01-11.</t>

      <t>draft-ietf-anima-prefix-management-01: minor update, 2016-07-08.</t>

      <t>draft-ietf-anima-prefix-management-02: replaced intent discussion by
      parameter setting, 2017-01-10.</t>

      <t>draft-ietf-anima-prefix-management-03: corrected object format,
      improved parameter setting example, 2017-03-10.</t>

      <t>draft-ietf-anima-prefix-management-04: add more explanations about
      the solution, add IPv4 options, removed PD flag, 2017-06-23.</t>

      <t>draft-ietf-anima-prefix-management-05: selected one IPv4 option, updated references, 2017-08-14.</t>

      <t>draft-ietf-anima-prefix-management-06: handled IETF Last Call comments, 2017-10-18.</t>

      <t>draft-ietf-anima-prefix-management-07: handled IESG comments, 2017-12-18.</t>
    </section>

    <!-- changes -->
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.I-D.ietf-anima-grasp'?>

      <?rfc include='reference.I-D.ietf-cbor-cddl'?>

            <?rfc include='reference.I-D.ietf-anima-bootstrapping-keyinfra'?>

      <?rfc include='reference.I-D.ietf-anima-autonomic-control-plane'?>

      <?rfc include='reference.RFC.3633'?>

      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.7159'?>

      <?rfc include='reference.RFC.7950'?> format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="RFC8993" target="https://www.rfc-editor.org/info/rfc8993" quoteTitle="true" derivedAnchor="RFC8993">
          <front>
            <title>A Reference Model for Autonomic Networking</title>
            <author initials="M" surname="Behringer" fullname="Michael Behringer" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B" surname="Carpenter" fullname="Brian Carpenter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T" surname="Eckert" fullname="Toerless Eckert">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L" surname="Ciavaglia" fullname="Laurent Ciavaglia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J" surname="Nobre" fullname="Jeferson Nobre">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8993"/>
          <seriesInfo name="DOI" value="10.17487/RFC8993"/>
        </reference>
      </references>

    <references title="Informative References">

      <?rfc include='reference.RFC.1918'?>

      <?rfc include='reference.RFC.6346'?>

      <?rfc include='reference.RFC.2865'?>

      <?rfc include='reference.I-D.ietf-core-yang-cbor'?>

      <?rfc include='reference.RFC.7575'?>

      <?rfc include='reference.RFC.7576'?>

      <?rfc include='reference.RFC.3046'?>

      <?rfc include='reference.RFC.6221'?>

      <?rfc include='reference.RFC.7049'?>

      <?rfc include='reference.I-D.ietf-anima-reference-model'?>

      <?rfc include='reference.I-D.liu-dhc-dhcp-yang-model'?>
    </references>
    <section title="Deployment Overview">
      <t>This Appendix numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-deployment-overview">Deployment Overview</name>
      <t indent="0" pn="section-appendix.a-1">This appendix includes logical deployment models, models and explanations of
      the target deployment models. The Its purpose is to help in understanding
      the mechanism of the described in this document.</t>

      <t>This Appendix
      <t indent="0" pn="section-appendix.a-2">This appendix includes two sub-sections: A.1 subsections:
      <xref target="app-a1" format="default" sectionFormat="of" derivedContent="Appendix A.1"/> for the two most common
      DHCP deployment models, models and A.2 <xref target="app-a2" format="default" sectionFormat="of" derivedContent="Appendix A.2"/> for the proposed PD deployment model. model described in this document. It
      should be noted that these are just examples, and there are many more
      deployment models.</t>
      <section title="Address &amp; anchor="app-a1" numbered="true" toc="include" removeInRFC="false" pn="section-a.1">
        <name slugifiedName="name-address-and-prefix-manageme">Address and Prefix management Management with DHCP">
        <t>Edge DHCP</name>
        <t indent="0" pn="section-a.1-1">Edge DHCP server deployment requires every edge router connecting
        to CPE a Customer Premises Equipment (CPE) device to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and
        optionally CPEs -- and,
        optionally, IPv6 prefixes via DHCPv6-PD for IPv6 capable CPE IPv6-capable CPEs that are
        router
        routers and have LANs behind them.</t>

        <figure>
          <artwork><![CDATA[
        <figure anchor="fig2" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-dhcp-deployment-model-witho">DHCP Deployment Model without a Central DHCP Server</name>
          <artwork name="" type="" align="left" alt="" pn="section-a.1-2.1">
                                             edge
        dynamic, "netconf/YANG" "NETCONF/YANG"            interfaces
         <--------------->
         &lt;---------------&gt; +-------------+
+------+    <-    &lt;- telemetry   | edge router/|-+  -----  +-----+
|config|  .... Domain domain ...  | DHCP server | |  ...    | CPE |+  LANs
|server|                   +-------------+ |  -----  +-----+| (---| )
+------+                    +--------------+  DHCP/   +-----+
                                           DHCPv6 / PD

   Figure 2: DHCP Deployment Model without a Central DHCP Server
]]></artwork>
                                             DHCPv6-PD
</artwork>
        </figure>

        <t>This
        <t indent="0" pn="section-a.1-3">This requires various coordination functions via some backend
        system depicted (depicted as the "config server": The server" in <xref target="fig2" format="default" sectionFormat="of" derivedContent="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.</t>

        <t>The
        <t indent="0" pn="section-a.1-4">The config server needs to provision edge interface address
        prefixes and DHCP parameters for every edge router. If too fine
        grained prefixes that are too fine-grained are used, this will result in large routing tables
        across the "Domain". domain shown in the figure. If too coarse grained 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.)</t>

        <t>There
        <t indent="0" pn="section-a.1-5">There is no standard describing that describes algorithms for how configuration servers
        would best perform this ongoing dynamic provisioning to optimize
        routing table size and address space utilization.</t>

        <t>There
        <t indent="0" pn="section-a.1-6">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).</t>

        <t>For servers). For example, a YANG data model for controlling DHCP server operations is
        still in draft being developed <xref target="I-D.liu-dhc-dhcp-yang-model"/>.</t>

        <t>Due target="DHCP-YANG-MODEL" format="default" sectionFormat="of" derivedContent="DHCP-YANG-MODEL"/>.</t>
        <t indent="0" pn="section-a.1-7">Due to these and other problems of related to the above model, the more common
        DHCP deployment model is as follows:</t>

        <figure>
          <artwork><![CDATA[
        <figure align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-dhcp-deployment-model-with-">DHCP Deployment Model with a Central DHCP Server</name>
          <artwork name="" type="" align="left" alt="" pn="section-a.1-8.1">
+------+                                      edge
|config|    initial, "CLI"                   interfaces
|server| ----------------> ----------------&gt; +-------------+
+------+                   | edge router/|-+  -----  +-----+
   |     .... Domain domain ...   | DHCP relay  | |  ...    | CPE |+  LANs
+------+                   +-------------+ |  -----  +-----+| (---| )
|DHCP  |                    +--------------+  DHCP/   +-----+
|server|                                   DHCPv6 / PD                                     DHCPv6-PD
+------+

    Figure 3: DHCP Deployment Model with a Central DHCP Server
]]></artwork>
</artwork>
        </figure>

        <t>Dynamic
        <t indent="0" pn="section-a.1-9">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 static. The
        DHCP relay function inserts an "edge interface" and/or subscriber
        identifying
        subscriber-identifying options into DHCP requests from CPE CPEs (e.g., <xref target="RFC3046"/>, <xref target="RFC6221"/>), target="RFC3046" format="default" sectionFormat="of" derivedContent="RFC3046"/> <xref target="RFC6221" format="default" sectionFormat="of" derivedContent="RFC6221"/>), and the DHCP server has
        complete policies for address assignments and prefixes useable usable on
        every edge-router/interface/subscriber-group. edge router / interface / subscriber group. When the DHCP relay sees
        the DHCP reply, it inserts static routes for the assigned
        address/address-prefix
        address / address prefix into the routing table of the edge router which 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.</t>

        <t>There domain shown in the figure.</t>
        <t indent="0" pn="section-a.1-10">There is no comprehensive standardization of these solutions. <xref target="RFC3633"/> section 14, for For example, <xref target="RFC8415" sectionFormat="comma" section="19.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8415#section-19.1.3" derivedContent="RFC8415"/> simply
        refers to "a [non-defined] protocol or other out-of-band communication to add
        configure routing information for delegated prefixes into on any router
        through which the provider edge
        router".</t> client may forward traffic."</t>
      </section>
      <section title="Prefix management anchor="app-a2" numbered="true" toc="include" removeInRFC="false" pn="section-a.2">
        <name slugifiedName="name-prefix-management-with-ani-">Prefix Management with ANI/GRASP">
        <t>With ANI/GRASP</name>
        <t indent="0" pn="section-a.2-1">Using the proposed use of ANI and Prefix-management prefix management ASAs (PM-ASAs) using GRASP, the deployment
model is intended to look as follows:</t>

        <figure>
          <artwork><![CDATA[
|<............
        <figure anchor="fig4" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-deployment-model-using-ani-">Deployment Model Using ANI/GRASP</name>
          <artwork name="" type="" align="left" alt="" pn="section-a.2-2.1">
|&lt;............ ANI Domain domain / ACP............>| ACP............&gt;| (...) ........-> ........-&gt;

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

       Figure 4: Proposed Deployment Model using ANI/GRASP
]]></artwork>
</artwork>
        </figure>

        <t>The
        <t indent="0" pn="section-a.2-3">The network runs an ANI domain with an ACP <xref target="I-D.ietf-anima-autonomic-control-plane"/> target="RFC8994" format="default" sectionFormat="of" derivedContent="RFC8994"/> between some central
        device (e.g., a router or ANI enabled 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<xref target="I-D.ietf-anima-grasp"> GRASP <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"> </xref> not only for p2p communication, peer-to-peer communication
        but also for distribution/flooding.</t>

        <t>The
        <t indent="0" pn="section-a.2-4">The central devices and edge routers run software
        in the form of "Autonomic Service Agents" (ASA) ASAs to support this document's autonomic IPv6 edge prefix management (PM).
        The ASAs for prefix management are called management. PM-ASAs below,
        and as discussed below
        together comprise the Autonomic Prefix Management Function.</t>

        <t>Edge
        <t indent="0" pn="section-a.2-5">Edge routers can have different roles based on the type and number
        of CPE CPEs attaching to them. Each edge router could be an RSG, ASG, or CSG
        in mobile aggregation networks (see Section 6.1). <xref target="exparam" format="default" sectionFormat="of" derivedContent="Section 6.1"/>). Mechanisms outside
        the scope of this document make routers aware of their roles.</t>

        <t>Some
        <t indent="0" pn="section-a.2-6">Some considerations about related to the proposed deployment model are listed
        as follows.</t>

        <t>1. In
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-a.2-7">
        <li pn="section-a.2-7.1" derivedCounter="1.">
            <t indent="0" pn="section-a.2-7.1.1">In a minimum Prefix Management prefix management solution, the central device uses
        the "PrefixManager.Params" PrefixManager.Params GRASP Objective objective introduced in this document
        to disseminate network wide, network-wide, per-role parameters to edge routers. The
        PM-ASA uses the parameters applying that apply to its own role to locally
        configure pre-existing 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:</t>

        <t>1.a The
            <ol spacing="normal" type="1.%c" indent="adaptive" start="1" pn="section-a.2-7.1.2">
        <li pn="section-a.2-7.1.2.1" derivedCounter="1.a">The edge router connects via downstream interfaces to each (host)
        CPE that each requires an address. The PM-ASA sets up for each such
        interface a DHCP requesting router (according to <xref target="RFC3633"/>) target="RFC8415" format="default" sectionFormat="of" derivedContent="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. objective. The CPEs assign addresses in the prefix via
        RAs from the router
        Router Advertisements (RAs), or the PM-ASA 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 <xref target="RFC3633"/>) target="RFC8415" format="default" sectionFormat="of" derivedContent="RFC8415"/>) is required.
        Its address can be another parameter from the GRASP Objective.</t>

        <t>1.b The objective.</li>
              <li pn="section-a.2-7.1.2.2" derivedCounter="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 and/or or
        GRASP parameters parameters, and the PM-ASA PM‑ASA sets up a DHCP relay function to pass
        on requests to the central DHCP server as in 1.a.</t>

        <t>2. In point 1.a.</li>
            </ol>
          </li>
          <li pn="section-a.2-7.2" derivedCounter="2.">
            <t indent="0" pn="section-a.2-7.2.1">In a solution without a central DHCP server, the PM-ASA on the
        edge routers not only learn learns parameters from "PrefixManager.Params" PrefixManager.Params
        but also utilize utilizes GRASP to request/negotiate actual IPv6 prefix
        delegation via the GRASP "PrefixManager" objective PrefixManager objective, as described in more
        detail below. In the most simple 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 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 CPE the CPEs from the
        prefixes it received. This includes both host CPEs requesting IPv6
        addresses as well as 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.</t>

        <t>This
            <t indent="0" pn="section-a.2-7.2.2">This solution is quite similar to the initial described 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 it is possible today.</t>

        <t>3. The
          </li>
          <li pn="section-a.2-7.3" derivedCounter="3.">The address pool(s) pools from which prefixes are allocated does do not all
        need to be taken all from one central location. Edge router PM-ASA 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. 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, PM‑ASA, therefore allowing aggregation to maximize
        aggregation: A PM-ASA be maximized: a PM‑ASA would only request further (smaller/shorter) smaller
        prefixes when it exhausts its own poll pool (from the central location) and
        can not
        cannot get further large prefixes from that central location anymore.
        Because the overflow prefixes taken from a topological topologically nearby PM-ASA, 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.</t>

        <t>4. Instead routed.</li>
          <li pn="section-a.2-7.4" derivedCounter="4.">Instead of peer-to-peer optimization of prefix delegation, a
        hierarchy of PM-ASA PM-ASAs can be built (indicated in the picture <xref target="fig4" format="default" sectionFormat="of" derivedContent="Figure 4"/> via a
        dotted intermediate router). This would require additional parameters
        to
        in the "PrefixManager" PrefixManager objective to allow creating the creation of a hierarchy of
        PM-ASA
        PM-ASAs across which the prefixes can be delegated. This is not
        detailed further below.</t>

        <t>5. In delegated.</li>
          <li pn="section-a.2-7.5" derivedCounter="5.">In cases where CPEs are also part of the ANI Domain domain (e.g.,
        "Managed CPE"),
        "managed CPEs"), then GRASP will extend into the actual customer sites
        and can equally 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 router, with the mayor major
        changes being that a) (a) a CPE router will most likley likely not need to run
        DHCPv6-PD itself, but only DHCP address assignment, b) The assignment and (b) the edge
        routers to which the CPE connect connects would most likely become ideal places
        on which to run a hierarchical instance of PD-ASAs on PD-ASAs, as outlined in
        point
        1.</t> 1.</li>
        </ol>
      </section>
    </section>
    <section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">Valuable comments were received from
      <contact fullname="William Atwood"/>,
      <contact fullname="Fred Baker"/>,
      <contact fullname="Michael Behringer"/>,
      <contact fullname="Ben Campbell"/>,
      <contact fullname="Laurent Ciavaglia"/>,
      <contact fullname="Toerless Eckert"/>,
      <contact fullname="Joel Halpern"/>,
      <contact fullname="Russ Housley"/>,
      <contact fullname="Geoff Huston"/>,
      <contact fullname="Warren Kumari"/>,
      <contact fullname="Dan Romascanu"/>,
      and <contact fullname="Chongfeng Xie"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Sheng Jiang" initials="S." role="editor" surname="Jiang">
        <organization showOnFrontPage="true">Huawei Technologies Co., Ltd</organization>
        <address>
          <postal>
            <street>No. 156 Beiqing Road</street>
            <extaddr>Q14, Huawei Campus</extaddr>
            <city>Hai-Dian District, Beijing</city>
            <code>100095</code>
            <country>China</country>
          </postal>
          <email>jiangsheng@huawei.com</email>
        </address>
      </author>
      <author fullname="Zongpeng Du" initials="Z." surname="Du">
        <organization showOnFrontPage="true">China Mobile</organization>
        <address>
          <postal>
            <street>32 Xuanwumen West St</street>
            <city>Xicheng District, Beijing</city>
            <code>100053</code>
            <country>China</country>
          </postal>
          <email>duzongpeng@chinamobile.com</email>
        </address>
      </author>
      <author fullname="Brian Carpenter" initials="B." surname="Carpenter">
        <organization abbrev="Univ. of Auckland" showOnFrontPage="true">University of Auckland</organization>
        <address>
          <postal>
            <extaddr>School of Computer Science</extaddr>
            <street>PB 92019</street>
            <city>Auckland</city>
            <region/>
            <code>1142</code>
            <country>New Zealand</country>
          </postal>
          <email>brian.e.carpenter@gmail.com</email>
        </address>
      </author>
      <author fullname="Qiong Sun" initials="Q." surname="Sun">
        <organization showOnFrontPage="true">China Telecom</organization>
        <address>
          <postal>
            <street>118 Xizhimennei St</street>
            <city>Beijing</city>
            <code>100035</code>
            <country>China</country>
          </postal>
          <email>sunqiong@chinatelecom.cn</email>
        </address>
      </author>
    </section>
  </back>
</rfc>