rfc8992xml2.original.xml   rfc8992.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- This can be converted using the Web service at https://xml2rfc.tools.ietf.o <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
rg/ --> ensus="true" docName="draft-ietf-anima-prefix-management-07" indexInclude="true"
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> ipr="trust200902" number="8992" prepTime="2021-05-20T22:52:53" scripts="Common,
<?rfc toc="yes"?> Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocIncl
<!-- You want a table of contents --> ude="true" xml:lang="en">
<?rfc symrefs="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-managemen
<!-- Use symbolic labels for references --> t-07" rel="prev"/>
<?rfc sortrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc8992" rel="alternate"/>
<!-- This sorts the references --> <link href="urn:issn:2070-1721" rel="alternate"/>
<?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 in
serts the appropriate IETF boilerplate -->
<rfc category="info" docName="draft-ietf-anima-prefix-management-07" ipr="trust2
00902">
<front> <front>
<title abbrev="Auto IPv6 Prefix Management">Autonomic IPv6 Edge Prefix <title abbrev="Auto IPv6 Prefix Management">Autonomic IPv6 Edge Prefix Manag
Management in Large-scale Networks</title> ement in Large-Scale Networks</title>
<seriesInfo name="RFC" value="8992" stream="IETF"/>
<author fullname="Sheng Jiang" initials="S." role="editor" surname="Jiang"> <author fullname="Sheng Jiang" initials="S." role="editor" surname="Jiang">
<organization>Huawei Technologies Co., Ltd</organization> <organization showOnFrontPage="true">Huawei Technologies Co., Ltd</organiz
ation>
<address> <address>
<postal> <postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street> <street>No. 156 Beiqing Road</street>
<extaddr>Q14, Huawei Campus</extaddr>
<city>Hai-Dian District, Beijing, 100095</city> <city>Hai-Dian District, Beijing</city>
<code>100095</code>
<country>P.R. China</country> <country>China</country>
</postal> </postal>
<email>jiangsheng@huawei.com</email> <email>jiangsheng@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Zongpeng Du" initials="Z." surname="Du"> <author fullname="Zongpeng Du" initials="Z." surname="Du">
<organization>Huawei Technologies Co., Ltd</organization> <organization showOnFrontPage="true">China Mobile</organization>
<address> <address>
<postal> <postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street> <street>32 Xuanwumen West St</street>
<city>Xicheng District, Beijing</city>
<city>Hai-Dian District, Beijing, 100095</city> <code>100053</code>
<country>China</country>
<country>P.R. China</country>
</postal> </postal>
<email>duzongpeng@chinamobile.com</email>
<email>duzongpeng@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Brian Carpenter" initials="B." surname="Carpenter">
<author fullname="Brian Carpenter" initials="B. E." surname="Carpenter"> <organization abbrev="Univ. of Auckland" showOnFrontPage="true">University
<organization abbrev="Univ. of Auckland"/> of Auckland</organization>
<address> <address>
<postal> <postal>
<street>Department of Computer Science</street> <extaddr>School of Computer Science</extaddr>
<street>University of Auckland</street>
<street>PB 92019</street> <street>PB 92019</street>
<city>Auckland</city> <city>Auckland</city>
<region/> <region/>
<code>1142</code> <code>1142</code>
<country>New Zealand</country> <country>New Zealand</country>
</postal> </postal>
<email>brian.e.carpenter@gmail.com</email> <email>brian.e.carpenter@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Qiong Sun" initials="Q." surname="Sun"> <author fullname="Qiong Sun" initials="Q." surname="Sun">
<organization>China Telecom</organization> <organization showOnFrontPage="true">China Telecom</organization>
<address> <address>
<postal> <postal>
<street>No.118, Xizhimennei Street</street> <street>118 Xizhimennei St</street>
<city>Beijing</city> <city>Beijing</city>
<code>100035</code> <code>100035</code>
<country>China</country>
<country>P. R. China</country>
</postal> </postal>
<email>sunqiong@chinatelecom.cn</email>
<email>sunqiong@ctbri.com.cn</email>
</address> </address>
</author> </author>
<date month="05" year="2021"/>
<date day="" month="" year="2017"/>
<area>Operations and Management</area> <area>Operations and Management</area>
<workgroup>ANIMA</workgroup>
<workgroup>ANIMA WG</workgroup> <keyword>Autonomic Networking</keyword>
<keyword>Prefix Management</keyword>
<keyword>Autonomic Networking, Prefix Management</keyword> <abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">This document defines two autonomic
<abstract> technical objectives for IPv6 prefix
<t>This document defines two autonomic technical objectives for IPv6 prefi
x
management at the edge of large-scale ISP networks, management at the edge of large-scale ISP networks,
with an extension to support IPv4 prefixes. An important purpose with an extension to support IPv4 prefixes. An important purpose
of the document is to use it for validation of the design of various of this document is to use it for validation of the design of various
components of the autonomic networking infrastructure.</t> components of the Autonomic Networking Infrastructure.</t>
</abstract> </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 i
s
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="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" 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" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="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 der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-problem-statement">Problem Stateme
nt</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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-in
tended-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 derived
Content="" 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="se
ction-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 derived
Content="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 derived
Content="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-informatio
n-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 derived
Content="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 derived
Content="" 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="se
ction-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 derived
Content="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-informatio
n-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 derived
Content="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" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-autonomic-edge-prefix-manag">Auton
omic Edge Prefix Management Solution</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-behavior-of-a-device-r
eques">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 derived
Content="" format="title" sectionFormat="of" target="name-behavior-of-a-device-p
rovid">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 derived
Content="" format="title" sectionFormat="of" target="name-behavior-after-success
ful-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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-autonomic-prefix-management">Auton
omic Prefix Management Objectives</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" format="title" sectionFormat="of" target="name-ipv4-extension">IPv4 E
xtension</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" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-prefix-management-parameter">Prefi
x Management Parameters</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-example-of-prefix-mana
gemen">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" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" 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="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-deployment-over
view">Deployment Overview</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derive
dContent="" format="title" sectionFormat="of" target="name-address-and-prefix-ma
nageme">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 derive
dContent="" format="title" sectionFormat="of" target="name-prefix-management-wit
h-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="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
="section-1">
<t>The original purpose of this document was to validate the design of th <name slugifiedName="name-introduction">Introduction</name>
e <t indent="0" pn="section-1-1">The original purpose of this document was t
o validate the design of the
Autonomic Networking Infrastructure (ANI) for a realistic use case. It sho ws Autonomic Networking Infrastructure (ANI) for a realistic use case. It sho ws
how the ANI can be applied to IP prefix delegation how the ANI can be applied to IP prefix delegation,
and it outlines approaches to build a system to do this. A fully and it outlines approaches to build a system to do this. A fully
standardized solution would require more details, so this document standardized solution would require more details, so this document
is informational in nature.</t> is informational in nature.</t>
<t indent="0" pn="section-1-2">This document defines two autonomic technic
<t>This document defines two autonomic technical objectives for IPv6 prefi al objectives for IPv6 prefix
x
management in large-scale networks, with an extension to support IPv4 pref ixes. management in large-scale networks, with an extension to support IPv4 pref ixes.
The background to Autonomic Networking (AN) is described in <xref target=" The background to Autonomic Networking is described in <xref target="RFC75
RFC7575"/> 75" format="default" sectionFormat="of" derivedContent="RFC7575"/>
and <xref target="RFC7576"/>. The GeneRic Autonomic Signaling Protocol (GR and <xref target="RFC7576" format="default" sectionFormat="of" derivedCont
ASP) is ent="RFC7576"/>. The GeneRic Autonomic Signaling Protocol (GRASP) is
specified by <xref target="I-D.ietf-anima-grasp"/> and can make use of specified by <xref target="RFC8990" format="default" sectionFormat="of" de
the proposed technical objectives to provide a solution for autonomic rivedContent="RFC8990"/> and can make use of
the technical objectives to provide a solution for autonomic
prefix management. An important purpose prefix management. An important purpose
of the present document is to use it for validation of the design of of the present document is to use it for validation of the design of
GRASP and other components of the autonomic networking infrastructure GRASP and other components of the ANI as
described in <xref target="I-D.ietf-anima-reference-model"/>.</t> described in <xref target="RFC8993" format="default" sectionFormat="of" de
rivedContent="RFC8993"/>.</t>
<t>This document is not a complete functional specification of an <t indent="0" pn="section-1-3">This document is not a complete functional
autonomic prefix management system and it does not describe all specification of an
autonomic prefix management system, and it does not describe all
detailed aspects of the GRASP objective parameters and Autonomic Service detailed aspects of the GRASP objective parameters and Autonomic Service
Agent (ASA) procedures necessary to build a complete system. Instead, it Agent (ASA) procedures necessary to build a complete system. Instead, it
describes the architectural framework utilizing the components of the describes the architectural framework utilizing the components of the
ANI, outlines the different ANI, outlines the different
deployment options and aspects, and defines GRASP objectives for use in deployment options and aspects, and defines GRASP objectives for use in
building the system. It also provides some basic parameter examples.</t> building the system. It also provides some basic parameter examples.</t>
<t indent="0" pn="section-1-4">This document is not intended to solve all
<t>This document is not intended to solve all cases of IPv6 prefix cases of IPv6 prefix
management. In fact, it assumes that the network's main infrastructure management. In fact, it assumes that the network's main infrastructure
elements already have addresses and prefixes. The document is dedicated elements already have addresses and prefixes. This document is dedicated
to how to make IPv6 prefix management at the edges of large-scale to how to make IPv6 prefix management at the edges of large-scale
networks as autonomic as possible. It is specifically written for networks as autonomic as possible. It is specifically written for
service provider (ISP) networks. Although there are similarities between Internet Service Provider (ISP) networks. Although there are similarities between
ISPs and large enterprise networks, the requirements for the two use ISPs and large enterprise networks, the requirements for the two use
cases differ. In any case, the scope of the solution is expected cases differ. In any case, the scope of the solution is expected
to be limited, like any autonomic network, to a single management to be limited, like any Autonomic Network, to a single management
domain.</t> domain.</t>
<t indent="0" pn="section-1-5">However, the solution is designed in a gene
<t>However, the solution is designed in a general way. Its use for a ral way. Its use for a
broader scope than edge prefixes, including some or all infrastructure broader scope than edge prefixes, including some or all infrastructure
prefixes, is left for future discussion.</t> prefixes, is left for future discussion.</t>
<t indent="0" pn="section-1-6">A complete solution has many aspects that a
<t>A complete solution has many aspects that are not discussed here. re not discussed here.
Once prefixes have been assigned to routers, they need to be Once prefixes have been assigned to routers, they need to be
communicated to the routing system as they are brought into use. Similarly , communicated to the routing system as they are brought into use. Similarly ,
when prefixes are released, they need to be removed from the routing syste m. when prefixes are released, they need to be removed from the routing syste m.
Different operators may have different policies about prefix lifetimes, Different operators may have different policies regarding prefix lifetimes ,
and they may prefer to have centralized or distributed pools of spare and they may prefer to have centralized or distributed pools of spare
prefixes. In an autonomic network, these are properties decided by the prefixes. In an Autonomic Network, these are properties decided upon by th e
design of the relevant ASAs. The GRASP objectives are simply building design of the relevant ASAs. The GRASP objectives are simply building
blocks. blocks.
</t> </t>
<t indent="0" pn="section-1-7">A particular risk of distributed prefix all
<t>A particular risk of distributed prefix allocation in large networks ocation in large networks
is that over time, it might lead to fragmentation of the address space is that over time, it might lead to fragmentation of the address space
and an undesirable increase in the interior routing protocol tables. The and an undesirable increase in the size of the interior routing protocol t
extent of this risk depends on the algorithms and policies used by the ASA ables.
s. 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 > Mitigating this risk might even become an autonomic function in itself.</t >
</section> </section>
<section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn
<!-- intro --> ="section-2">
<name slugifiedName="name-terminology">Terminology</name>
<section anchor="terms" title="Terminology"> <t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 4>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> "<bcp14>SHOULD NOT</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<t>This document uses terminology defined in <xref target="RFC7575"/>.</t> are to be interpreted as described in BCP 14
<xref target="RFC2119" format="default" sectionFormat="of" derivedContent
="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedC
ontent="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t indent="0" pn="section-2-2">This document uses terminology defined in <
xref target="RFC7575" format="default" sectionFormat="of" derivedContent="RFC757
5"/>.</t>
</section> </section>
<section anchor="problem" numbered="true" toc="include" removeInRFC="false"
<!-- term --> pn="section-3">
<name slugifiedName="name-problem-statement">Problem Statement</name>
<section anchor="problem" title="Problem Statement"> <t indent="0" pn="section-3-1">The Autonomic Networking use case considere
<t>The autonomic networking use case considered here is autonomic IPv6 d here is autonomic IPv6
prefix management at the edge of large-scale ISP networks.</t> prefix management at the edge of large-scale ISP networks.</t>
<t indent="0" pn="section-3-2">Although DHCPv6-PD (DHCPv6 Prefix Delegatio
<t>Although DHCPv6 Prefix Delegation <xref target="RFC3633"/> supports n) <xref target="RFC8415" format="default" sectionFormat="of" derivedContent="RF
C8415"/> supports
automated delegation of IPv6 prefixes from one router to another, prefix automated delegation of IPv6 prefixes from one router to another, prefix
management still largely depends on human planning. In other words, management still largely depends on human planning. In other words,
there is no basic information or policy to support autonomic decisions there is no basic information or policy to support autonomic decisions
on the prefix length that each router should request or be delegated, on the prefix length that each router should request or be delegated,
according to its role in the network. Roles could be defined separately according to its role in the network. Roles could be defined separately
for individual devices or for individual devices or
could be generic (edge router, interior router, etc.). Furthermore, IPv6 could be generic (edge router, interior router, etc.). Furthermore, IPv6
prefix management by humans tends to be rigid and static after initial prefix management by humans tends to be rigid and static after initial
planning.</t> planning.</t>
<t indent="0" pn="section-3-3">The problem to be solved by Autonomic Netwo
<t>The problem to be solved by autonomic networking is how to rking is how to
dynamically manage IPv6 address space in large-scale networks, so that dynamically manage IPv6 address space in large-scale networks, so that
IPv6 addresses can be used efficiently. Here, we limit the problem to IPv6 addresses can be used efficiently. Here, we limit the problem to
assignment of prefixes at the edge of the network, close to access assignment of prefixes at the edge of the network, close to access
routers that support individual fixed-line subscribers, mobile routers that support individual fixed-line subscribers, mobile
customers, and corporate customers. We assume that the core customers, and corporate customers. We assume that the core
infrastructure of the network has already been established with infrastructure of the network has already been established with
appropriately assigned prefixes. The AN approach discussed in this appropriately assigned prefixes. The Autonomic Networking approach discuss ed in this
document is based on the assumption that there is a generic discovery document is based on the assumption that there is a generic discovery
and negotiation protocol that enables direct negotiation between and negotiation protocol that enables direct negotiation between
intelligent IP routers. GRASP <xref target="I-D.ietf-anima-grasp"/> is intelligent IP routers. GRASP <xref target="RFC8990" format="default" sect ionFormat="of" derivedContent="RFC8990"/> is
intended to be such a protocol.</t> intended to be such a protocol.</t>
<section anchor="experience" numbered="true" toc="include" removeInRFC="fa
<section anchor="experience" title="Intended User and Administrator Experi lse" pn="section-3.1">
ence"> <name slugifiedName="name-intended-user-and-administr">Intended User and
<t>The intended experience is, for the administrators of a Administrator Experience</name>
<t indent="0" pn="section-3.1-1">The intended experience is, for the adm
inistrators of a
large-scale network, that the management of IPv6 address space at the 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 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 edge are added and removed and as customers of all kinds join and
leave the network. In the ideal scenario, the administrators only leave the network. In the ideal scenario, the administrators only
have to specify a single IPv6 prefix for the whole network and the 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 initial prefix length for each device role. As far as users are
concerned, IPv6 prefix assignment would occur exactly as it does in concerned, IPv6 prefix assignment would occur exactly as it does in
any other network.</t> any other network.</t>
<t indent="0" pn="section-3.1-2">The actual prefix usage needs to be log
<t>The actual prefix usage needs to be logged for potential offline ged for potential offline
management operations including audit and security incident management operations, including audit and security incident
tracing.</t> tracing.</t>
</section> </section>
<section anchor="params" numbered="true" toc="include" removeInRFC="false"
<section anchor="params" title="Analysis of Parameters and Information Inv pn="section-3.2">
olved"> <name slugifiedName="name-analysis-of-parameters-and-">Analysis of Param
<t>For specific purposes of address management, a few parameters are eters and Information Involved</name>
involved on each edge device (some of them can be pre-configured <t indent="0" pn="section-3.2-1">For specific purposes of address manage
before they are connected). They include:</t> ment, each edge device will implement
several parameters. (Some of them can be preconfigured
<t><list style="symbols"> before they are connected.) They include the following:</t>
<t>Identity, authentication and authorization of this device. This <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
is expected to use the autonomic networking secure bootstrap .2-2">
process <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>, <li pn="section-3.2-2.1">Identity, authentication, and authorization o
f this device. This
is expected to use the Autonomic Networking secure bootstrap
process <xref target="RFC8995" format="default" sectionFormat="of" d
erivedContent="RFC8995"/>,
following which the device could safely take part in autonomic following which the device could safely take part in autonomic
operations.</t> operations.</li>
<li pn="section-3.2-2.2">Role of this device. Some example roles are d
<t>Role of this device. Some example roles are discussed in <xref ta iscussed in <xref target="exparam" format="default" sectionFormat="of" derivedCo
rget="exparam"/>.</t> ntent="Section 6.1"/>.</li>
<li pn="section-3.2-2.3">An IPv6 prefix length for this device.</li>
<t>An IPv6 prefix length for this device.</t> <li pn="section-3.2-2.4">An IPv6 prefix that is assigned to this devic
e and its
<t>An IPv6 prefix that is assigned to this device and its downstream devices.</li>
downstream devices.</t> </ul>
</list>A few parameters are involved in the network as a whole. They <t indent="0" pn="section-3.2-3">The network as a whole will implement t
are:</t> he following parameters:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<t><list style="symbols"> .2-4">
<t>Identity of a trust anchor, which is a certification authority <li pn="section-3.2-4.1">Identity of a trust anchor, which is a certif
ication authority
(CA) maintained by the network administrators, used during the (CA) maintained by the network administrators, used during the
secure bootstrap process.</t> secure bootstrap process.</li>
<li pn="section-3.2-4.2">Total IPv6 address space available for edge d
<t>Total IPv6 address space available for edge devices. It is a pool evices. It is a pool
of one or several IPv6 prefixes.</t> of one or several IPv6 prefixes.</li>
<li pn="section-3.2-4.3">The initial prefix length for each device rol
<t>The initial prefix length for each device role.</t> e.</li>
</list></t> </ul>
<section anchor="device" numbered="true" toc="include" removeInRFC="fals
<section anchor="device" title="Parameters each device can define for it e" pn="section-3.2.1">
self"> <name slugifiedName="name-parameters-each-device-can-">Parameters Each
<t>This section identifies those of the above parameters that do not Device Can Define for Itself</name>
<t indent="0" pn="section-3.2.1-1">This section identifies those of th
e above parameters that do not
need external information in order for the devices concerned to set need external information in order for the devices concerned to set
them to a reasonable default value after bootstrap or after a network them to a reasonable default value after bootstrap or after a network
disruption. There are few of these:</t> disruption. They are as follows:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t><list style="symbols"> -3.2.1-2">
<t>Default role of this device.</t> <li pn="section-3.2.1-2.1">Default role of this device.</li>
<li pn="section-3.2.1-2.2">Default IPv6 prefix length for this devic
<t>Default IPv6 prefix length for this device.</t> e.</li>
<li pn="section-3.2.1-2.3">Cryptographic identity of this device, as
<t>Cryptographic identity of this device, as needed for secure boo needed for secure bootstrapping
tstrapping <xref target="RFC8995" format="default" sectionFormat="of" derived
<xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t> Content="RFC8995"/>.</li>
</list>The device may be shipped from the manufacturer with </ul>
pre-configured role and default prefix length, which could be <t indent="0" pn="section-3.2.1-3">The device may be shipped from the
manufacturer with a
preconfigured role and default prefix length, which could be
modified by an autonomic mechanism. Its cryptographic identity will be installed modified by an autonomic mechanism. Its cryptographic identity will be installed
by its manufacturer.</t> by its manufacturer.</t>
</section> </section>
<section anchor="opparams" numbered="true" toc="include" removeInRFC="fa
<!-- device --> lse" pn="section-3.2.2">
<name slugifiedName="name-information-needed-from-net">Information Nee
<section anchor="opparams" title="Information needed from network operat ded from Network Operations</name>
ions"> <t indent="0" pn="section-3.2.2-1">This section identifies those param
<t>This section identifies those parameters that might need eters that might need
operational input in order for the devices concerned to set them to operational input in order for the devices concerned to set them to
a non-default value.</t> a non-default value.</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t><list style="symbols"> -3.2.2-2">
<t>Non-default value for the IPv6 prefix length for this device. <li pn="section-3.2.2-2.1">Non-default value for the IPv6 prefix len
This needs to be decided based on the role of this device.</t> gth for this device.
This needs to be decided based on the role of this device.</li>
<t>The initial prefix length for each device role.</t> <li pn="section-3.2.2-2.2">The initial prefix length for each device
role.</li>
<t>Whether to allow the device to request more address <li pn="section-3.2.2-2.3">Whether to allow the device to request mo
space.</t> re address
space.</li>
<t>The policy when to request more address space, for example, <li pn="section-3.2.2-2.4">The policy regarding when to request more
if the address usage reaches a certain limit or percentage.</t> address space -- for example,
</list></t> if the address usage reaches a certain limit or percentage.</li>
</ul>
</section> </section>
<section anchor="compare" numbered="true" toc="include" removeInRFC="fal
<section anchor="compare" title="Comparison with current solutions"> se" pn="section-3.2.3">
<t>This section briefly compares the above use case with current <name slugifiedName="name-comparison-with-current-sol">Comparison with
Current Solutions</name>
<t indent="0" pn="section-3.2.3-1">This section briefly compares the a
bove use case with current
solutions. Currently, the address management is still largely solutions. Currently, the address management is still largely
dependent on human planning. It is rigid and static after initial dependent on human planning. It is rigid and static after initial
planning. Address requests will fail if the configured address space planning. Address requests will fail if the configured address space
is used up.</t> is used up.</t>
<t indent="0" pn="section-3.2.3-2">Some autonomic and dynamic address
<t>Some autonomic and dynamic address management functions may be management functions may be
achievable by extending the existing protocols, for example, achievable by extending the existing protocols -- for example,
extending DHCPv6-PD (DHCPv6 Prefix Delegation, <xref target="RFC3633"/ extending DHCPv6-PD <xref target="RFC8415" format="default" sectionFor
>) mat="of" derivedContent="RFC8415"/>
to request IPv6 prefixes according to the device to request IPv6 prefixes according to the device
role. However, defining uniform device roles may not be a practical role. However, defining uniform device roles may not be a practical
task. Some functions are not suitable to be achieved by any existing task, as some functions cannot be configured on the basis of role usin
protocols.</t> g
existing prefix delegation protocols.</t>
<t>Using a generic autonomic discovery and negotiation protocol <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 instead of specific solutions has the advantage that additional
parameters can be included in the autonomic solution without parameters can be included in the autonomic solution without
creating new mechanisms. This is the principal argument for a creating new mechanisms. This is the principal argument for a
generic approach.</t> generic approach.</t>
</section> </section>
</section> </section>
<section anchor="interact" numbered="true" toc="include" removeInRFC="fals
<section anchor="interact" title="Interaction with other devices"> e" pn="section-3.3">
<section anchor="peers" title="Information needed from other devices"> <name slugifiedName="name-interaction-with-other-devi">Interaction with
<t>This section identifies those of the above parameters that need Other Devices</name>
<section anchor="peers" numbered="true" toc="include" removeInRFC="false
" pn="section-3.3.1">
<name slugifiedName="name-information-needed-from-oth">Information Nee
ded from Other Devices</name>
<t indent="0" pn="section-3.3.1-1">This section identifies those of th
e above parameters that need
external information from neighbor devices (including the upstream external information from neighbor devices (including the upstream
devices). In many cases, two-way dialogue with neighbor devices is devices). In many cases, two-way dialogue with neighbor devices is
needed to set or optimize them.</t> needed to set or optimize them.</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t><list style="symbols"> -3.3.1-2">
<t>Identity of a trust anchor.</t> <li pn="section-3.3.1-2.1">Information regarding the identity of a t
rust anchor is needed.</li>
<t>The device will need to discover a device, from which it can <li pn="section-3.3.1-2.2">The device will need to discover another
acquire IPv6 address space.</t> device from which it can
acquire IPv6 address space.</li>
<t>The initial prefix length for each device role, particularly <li pn="section-3.3.1-2.3">Information regarding the initial prefix
for its own downstream devices.</t> length for the role of each device is needed, particularly
for its own downstream devices.</li>
<t>The default value of the IPv6 prefix length may be overridden <li pn="section-3.3.1-2.4">The default value of the IPv6 prefix leng
by a non-default value.</t> th may be overridden
by a non-default value.</li>
<t>The device will need to request and acquire one or more IPv6 pr <li pn="section-3.3.1-2.5">The device will need to request and acqui
efixes that re one or more IPv6 prefixes that
can be assigned to this device and its downstream devices.</t> can be assigned to this device and its downstream devices.</li>
<li pn="section-3.3.1-2.6">The device may respond to prefix delegati
<t>The device may respond to prefix delegation requests from its on requests from its
downstream devices.</t> downstream devices.</li>
<li pn="section-3.3.1-2.7">The device may require the assignment of
<t>The device may require to be assigned more IPv6 address more IPv6 address
space, if it used up its assigned IPv6 address space.</t> space if it used up its assigned IPv6 address space.</li>
</list></t> </ul>
</section> </section>
<section anchor="monitor" numbered="true" toc="include" removeInRFC="fal
<!-- peers --> se" pn="section-3.3.2">
<name slugifiedName="name-monitoring-diagnostics-and-">Monitoring, Dia
<section anchor="monitor" title="Monitoring, diagnostics and reporting"> gnostics, and Reporting</name>
<t>This section discusses what role devices should play in <t indent="0" pn="section-3.3.2-1">This section discusses what role de
vices should play in
monitoring, fault diagnosis, and reporting.</t> monitoring, fault diagnosis, and reporting.</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t><list style="symbols"> -3.3.2-2">
<t>The actual address assignments need to be logged for <li pn="section-3.3.2-2.1">The actual address assignments need to be
potential offline management operations.</t> logged for
potential offline management operations.</li>
<t>In general, the usage situation of address space should be <li pn="section-3.3.2-2.2">In general, the usage situation regarding
reported to the network administrators, in an abstract way, for address space should be
example, statistics or visualized report.</t> reported to the network administrators in an abstract way -- for
example, statistics or a visualized report.</li>
<t>A forecast of address exhaustion should be reported.</t> <li pn="section-3.3.2-2.3">A forecast of address exhaustion should b
</list></t> e reported.</li>
</ul>
</section> </section>
<!-- monitor -->
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
<section title="Autonomic Edge Prefix Management Solution"> <name slugifiedName="name-autonomic-edge-prefix-manag">Autonomic Edge Pref
<t>This section introduces the building blocks for ix Management Solution</name>
<t indent="0" pn="section-4-1">This section introduces the building blocks
for
an autonomic edge prefix management solution. an autonomic edge prefix management solution.
As noted in <xref target="intro"/>, this is not a complete description of As noted in <xref target="intro" format="default" sectionFormat="of" deriv edContent="Section 1"/>, this is not a complete description of
a solution, which will depend on the detailed design of the relevant a solution, which will depend on the detailed design of the relevant
Autonomic Service Agents. Autonomic Service Agents (ASAs).
It uses the generic discovery and negotiation protocol defined It uses the generic discovery and negotiation protocol defined
by <xref target="I-D.ietf-anima-grasp"/>. The relevant GRASP objectives by <xref target="RFC8990" format="default" sectionFormat="of" derivedConte
are defined in <xref target="prefixNegoOptions"/>.</t> nt="RFC8990"/>. The relevant GRASP objectives
are defined in <xref target="prefixNegoOptions" format="default" sectionFo
<t>The procedures described below are carried out by an Autonomic rmat="of" derivedContent="Section 5"/>.</t>
Service Agent (ASA) in each device that participates in the solution. We <t indent="0" pn="section-4-2">The procedures described below are carried
out by an ASA in each device that participates in the solution. We
will refer to this as the PrefixManager ASA.</t> will refer to this as the PrefixManager ASA.</t>
<section anchor="reqbehave" numbered="true" toc="include" removeInRFC="fal
<section anchor="reqbehave" title="Behaviors on prefix requesting device"> se" pn="section-4.1">
<t>If the device containing a PrefixManager ASA has used up its <name slugifiedName="name-behavior-of-a-device-reques">Behavior of a Dev
ice Requesting a Prefix</name>
<t indent="0" pn="section-4.1-1">If the device containing a PrefixManage
r ASA has used up its
address pool, it can request more space according to its requirements. address pool, it can request more space according to its requirements.
It should decide the length of the requested prefix and request it by It should decide the length of the requested prefix and request it via
the mechanism described in <xref target="prefixManageParams"/>. Note tha the mechanism described in <xref target="prefixManageParams" format="def
t ault" sectionFormat="of" derivedContent="Section 6"/>. Note that
although the device's role may define certain default allocation lengths , although the device's role may define certain default allocation lengths ,
those defaults might be changed dynamically, and those defaults might be changed dynamically, and
the device might request more, or less, address space due to the device might request more, or less, address space due to
some local operational heuristic.</t> some local operational heuristic.</t>
<t indent="0" pn="section-4.1-2">A PrefixManager ASA that needs addition
<t>A PrefixManager ASA that needs additional address space should al address space should
firstly discover peers that may be able to provide extra address firstly discover peers that may be able to provide extra address
space. The ASA should send out a GRASP Discovery message that contains space. The ASA should send out a GRASP Discovery message that contains
a PrefixManager Objective option (see <xref target="prefixObjOption"/>) a PrefixManager Objective option (see <xref target="RFC8650" section="2"
in relative="figure-1" format="default" sectionFormat="of" derivedLink="https://rf
order to discover peers also supporting that option. Then it should c-editor.org/rfc/figure-1" derivedContent="RFC8650"/> and <xref target="prefixOb
jOption" format="default" sectionFormat="of" derivedContent="Section 5.1"/>) in
order to discover peers also supporting that option. Then, it should
choose one such peer, most likely the first to respond.</t> choose one such peer, most likely the first to respond.</t>
<t indent="0" pn="section-4.1-3">If the GRASP Discovery Response message
<t>If the GRASP discovery Response message carries a divert option carries a Divert option
pointing to an off-link PrefixManager ASA, the requesting ASA may pointing to an off-link PrefixManager ASA, the requesting ASA may
initiate negotiation with that ASA diverted device to find out whether initiate negotiation with that ASA-diverted device to find out whether
it can provide the requested length prefix.</t> it can provide the requested length of the prefix.</t>
<t indent="0" pn="section-4.1-4">In any case, the requesting ASA will ac
<t>In any case, the requesting ASA will act as a GRASP negotiation t as a GRASP negotiation
initiator by sending a GRASP Request message with a PrefixManager initiator by sending a GRASP Request message with a PrefixManager
Objective option. The ASA indicates in this option the length of Objective option. The ASA indicates in this option the length of
the requested prefix. the requested prefix.
<!--and whether the ASA supports the DHCPv6 Prefix
Delegation (PD) function <xref target="RFC3633"/>.-->
This starts a GRASP negotiation process.</t> This starts a GRASP negotiation process.</t>
<t indent="0" pn="section-4.1-5">During the subsequent negotiation, the
<t>During the subsequent negotiation, the ASA will decide at each step ASA will decide at each step
whether to accept the offered prefix. That decision, and the decision whether to accept the offered prefix. That decision, and the decision
to end negotiation, is an implementation choice.</t> to end the negotiation, are implementation choices.</t>
<t indent="0" pn="section-4.1-6">The ASA could alternatively initiate GR
<t>The ASA could alternatively initiate rapid mode GRASP discovery ASP discovery in rapid mode
with an embedded negotiation request, if it is implemented.</t> with an embedded negotiation request, if it is implemented.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
<section title="Behaviors on prefix providing device"> ">
<t>At least one device on the network must be configured with <name slugifiedName="name-behavior-of-a-device-provid">Behavior of a Dev
the initial pool of available prefixes mentioned in <xref target="params ice Providing a Prefix</name>
"/>. <t indent="0" pn="section-4.2-1">At least one device on the network must
Apart from that requirement, any device may act as a prefix providing de be configured with
vice.</t> the initial pool of available prefixes mentioned in <xref target="params
" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.
<t>A device that receives a Discovery message with a PrefixManager Apart from that requirement, any device may act as a provider of prefixe
s.</t>
<t indent="0" pn="section-4.2-2">A device that receives a Discovery mess
age with a PrefixManager
Objective option should respond with a GRASP Response message if it Objective option should respond with a GRASP Response message if it
contains a PrefixManager ASA. Further details of the discovery contains a PrefixManager ASA. Further details of the discovery
process are described in <xref target="I-D.ietf-anima-grasp"/>. When process are described in <xref target="RFC8990" format="default" section Format="of" derivedContent="RFC8990"/>. When
this ASA receives a subsequent Request message, it should conduct a this ASA receives a subsequent Request message, it should conduct a
GRASP negotiation sequence, using Negotiate, Confirm-waiting, and GRASP negotiation sequence, using Negotiate, Confirm Waiting, and
Negotiation-ending messages as appropriate. The Negotiate messages Negotiation End messages as appropriate. The Negotiate messages
carry a PrefixManager Objective option, <!--. This will indicate whether carry a PrefixManager Objective option,
the sending device supports the PD function. More importantly, it-->
which will indicate the prefix and its length offered to the requesting ASA. As which will indicate the prefix and its length offered to the requesting ASA. As
described in <xref target="I-D.ietf-anima-grasp"/>, negotiation will described in <xref target="RFC8990" format="default" sectionFormat="of"
continue until either end stops it with a Negotiation-ending message. derivedContent="RFC8990"/>, negotiation will
If the negotiation succeeds, the prefix providing ASA will remove the continue until either end stops it with a Negotiation End message.
If the negotiation succeeds, the ASA that provides the prefix will remov
e the
negotiated prefix from its pool, and the requesting ASA will add it. negotiated prefix from its pool, and the requesting ASA will add it.
If the negotiation fails, the party sending the Negotiation-ending If the negotiation fails, the party sending the Negotiation End
message may include an error code string.</t> message may include an error code string.</t>
<t indent="0" pn="section-4.2-3">During the negotiation, the ASA will de
<t>During the negotiation, the ASA will decide at each step how large cide at each step how large
a prefix to offer. That decision, and the decision to end negotiation, a prefix to offer. That decision, and the decision to end the negotiatio
is an implementation choice.</t> n,
are implementation choices.</t>
<t>The ASA could alternatively negotiate in response to rapid mode <t indent="0" pn="section-4.2-4">The ASA could alternatively negotiate i
GRASP discovery, if it is implemented.</t> n response to GRASP discovery in rapid mode, if it is implemented.</t>
<t indent="0" pn="section-4.2-5">This specification is independent of wh
<t>This specification is independent of whether the PrefixManager ASAs ether the PrefixManager ASAs
are all embedded in routers, but that would be a rather natural are all embedded in routers, but that would be a rather natural
scenario. In a hierarchical network topology, a given router typically scenario. In a hierarchical network topology, a given router typically
provide prefixes for routers below it in the hierarchy, and it is provides prefixes for routers below it in the hierarchy, and it is
also likely to contain the first PrefixManager ASA discovered by those d ownstream also likely to contain the first PrefixManager ASA discovered by those d ownstream
routers. However, the GRASP discovery model, including its Redirect routers. However, the GRASP discovery model, including its redirection
feature, means that this is not an exclusive scenario, and a feature, means that this is not an exclusive scenario, and a
downstream PrefixManager ASA could negotiate a new prefix with a downstream PrefixManager ASA could negotiate a new prefix with a
device other than its upstream router.</t> device other than its upstream router.</t>
<t indent="0" pn="section-4.2-6">A resource shortage may cause the gatew
<t>A resource shortage may cause the gateway router to request more ay router to request more
resource in turn from its own upstream device. This would be another resources in turn from its own upstream device. This would be another
independent GRASP discovery and negotiation process. During the independent GRASP discovery and negotiation process. During the
processing time, the gateway router should send a Confirm-waiting processing time, the gateway router should send a Confirm Waiting
Message to the initial requesting router, to extend its timeout. When message to the initial requesting router, to extend its timeout. When
the new resource becomes available, the gateway router responds with a the new resource becomes available, the gateway router responds with a
GRASP Negotiate message with a prefix length matching the request.</t> GRASP Negotiate message with a prefix length matching the request.</t>
<t indent="0" pn="section-4.2-7">The algorithm used to choose which pref
<t>The algorithm to choose which prefixes to assign on the prefix ixes to assign on the devices that
providing devices is an implementation choice.</t> provide prefixes is an implementation choice.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.3
<section title="Behavior after Successful Negotiation"> ">
<t>Upon receiving a GRASP Negotiation-ending message that indicates <name slugifiedName="name-behavior-after-successful-n">Behavior after Su
ccessful Negotiation</name>
<t indent="0" pn="section-4.3-1">Upon receiving a GRASP Negotiation End
message that indicates
that an acceptable prefix length is available, the requesting device that an acceptable prefix length is available, the requesting device
may use the negotiated prefix without further messages.</t> may use the negotiated prefix without further messages.</t>
<t indent="0" pn="section-4.3-2">There are use cases where the ANI/GRASP
<t>There are use cases where the ANI/GRASP based prefix -based prefix
management approach can work together with DHCPv6-PD <xref target="RFC36 management approach can work together with DHCPv6-PD <xref target="RFC84
33"/> 15" format="default" sectionFormat="of" derivedContent="RFC8415"/>
as a complement. For example, the ANI/GRASP based as a complement. For example, the ANI/GRASP-based
method can be used intra-domain, while the DHCPv6-PD method works inter- domain 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 (i.e., across an administrative boundary). Also, ANI/GRASP can be used
inside the domain, and DHCP/DHCPv6-PD be used on the edge of the inside the domain, and DHCP/DHCPv6-PD can be used on the edge of the
domain to client (non-ANI devices). Another similar use case would be domain to clients (non-ANI devices). Another similar use case would be
ANI/GRASP inside the domain, with ANI/GRASP inside the domain, with
RADIUS <xref target="RFC2865"/> providing prefixes to client devices.</t RADIUS <xref target="RFC2865" format="default" sectionFormat="of" derive
> dContent="RFC2865"/> providing prefixes to client devices.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.4
<section title="Prefix logging"> ">
<t>Within the autonomic prefix management, all the prefix assignment <name slugifiedName="name-prefix-logging">Prefix Logging</name>
is done by devices without human intervention. It may be required <t indent="0" pn="section-4.4-1">Within the autonomic prefix management
to record all the prefix assignment history, for example to detect system, all prefix assignments are
or trace lost prefixes after outages, or to meet legal requirements. done by devices without human intervention. It may be required
that all prefix assignment history be recorded -- for example, to detect
or trace lost prefixes after outages or to meet legal requirements.
However, the logging and reporting process is out of scope for this However, the logging and reporting process is out of scope for this
document.</t> document.</t>
</section> </section>
</section> </section>
<section anchor="prefixNegoOptions" numbered="true" toc="include" removeInRF
<section anchor="prefixNegoOptions" title="Autonomic Prefix Management Objec C="false" pn="section-5">
tives"> <name slugifiedName="name-autonomic-prefix-management">Autonomic Prefix Ma
<t>This section defines the GRASP technical objective options that are use nagement Objectives</name>
d to support <t indent="0" pn="section-5-1">This section defines the GRASP technical ob
jective options that are used to support
autonomic prefix management.</t> autonomic prefix management.</t>
<section anchor="prefixObjOption" numbered="true" toc="include" removeInRF
<section anchor="prefixObjOption" title="Edge Prefix Objective Option"> C="false" pn="section-5.1">
<t>The PrefixManager Objective option is a GRASP objective option <name slugifiedName="name-edge-prefix-objective-optio">Edge Prefix Objec
conforming to <xref target="I-D.ietf-anima-grasp"/>. Its name is tive Option</name>
"PrefixManager" (see <xref target="iana"/>) and it carries the following <t indent="0" pn="section-5.1-1">The PrefixManager Objective option is a
data items as its value: <!-- the PD support flag, -->the prefix length, GRASP Objective option
and conforming to the GRASP specification <xref target="RFC8990" format="def
the actual prefix bits. Since GRASP is based on CBOR (Concise Binary Obj ault" sectionFormat="of" derivedContent="RFC8990"/>. Its name is
ect Representation "PrefixManager" (see <xref target="iana" format="default" sectionFormat=
<xref target="RFC7049"/>), the format of the PrefixManager Objective "of" derivedContent="Section 8"/>), and it carries the following
option is described as follows in CBOR data definition language (CDDL) data items as its value: the prefix length and
<xref target="I-D.ietf-cbor-cddl"/>:</t> the actual prefix bits. Since GRASP is based on CBOR (Concise Binary Obj
ect Representation)
<figure> <xref target="RFC8949" format="default" sectionFormat="of" derivedConten
<artwork><![CDATA[ t="RFC8949"/>, the format of the PrefixManager Objective
option is described in the Concise Data Definition Language (CDDL)
<xref target="RFC8610" format="default" sectionFormat="of" derivedConten
t="RFC8610"/> as follows:</t>
<sourcecode type="cddl" markers="false" pn="section-5.1-2">
objective = ["PrefixManager", objective-flags, loop-count, objective = ["PrefixManager", objective-flags, loop-count,
[length, ?prefix]] [length, ?prefix]]
loop-count = 0..255 ; as in the GRASP specification loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification objective-flags /= ; as in the GRASP specification
length = 0..128 ; requested or offered prefix length length = 0..128 ; requested or offered prefix length
prefix = bytes .size 16 ; offered prefix in binary format prefix = bytes .size 16 ; offered prefix in binary format
]]></artwork> </sourcecode>
</figure> <t indent="0" pn="section-5.1-3">The use of the "dry run" mode of GRASP
<t>The use of the 'dry run' mode of GRASP is NOT RECOMMENDED for this ob is <bcp14>NOT RECOMMENDED</bcp14> for this objective, because it
jective, because it would require both ASAs to store state information about the correspondi
would require both ASAs to store state about the corresponding negotiati ng negotiation, to no real
on, to no real benefit -- the requesting ASA cannot base any decisions on the result of
benefit - the requesting ASA cannot base any decisions on the result of a successful
a successful dry-run negotiation.</t>
dry run negotiation.</t>
</section> </section>
<section anchor="ipv4" title="IPv4 extension"> <section anchor="ipv4" numbered="true" toc="include" removeInRFC="false" p
<t>This section presents an extended version of the n="section-5.2">
PrefixManager Objective that supports IPv4 by adding an extra flag: <name slugifiedName="name-ipv4-extension">IPv4 Extension</name>
<figure> <t indent="0" pn="section-5.2-1">This section presents an extended versi
<artwork><![CDATA[ on of the
PrefixManager objective that supports IPv4 by adding an extra flag:
</t>
<sourcecode type="cddl" markers="false" pn="section-5.2-2">
objective = ["PrefixManager", objective-flags, loop-count, prefval] objective = ["PrefixManager", objective-flags, loop-count, prefval]
loop-count = 0..255 ; as in the GRASP specification loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification objective-flags /= ; as in the GRASP specification
prefval /= pref6val prefval /= pref6val
pref6val = [version6, length, ?prefix] pref6val = [version6, length, ?prefix]
version6 = 6 version6 = 6
length = 0..128 ; requested or offered prefix length length = 0..128 ; requested or offered prefix length
prefix = bytes .size 16 ; offered prefix in binary format prefix = bytes .size 16 ; offered prefix in binary format
prefval /= pref4val prefval /= pref4val
pref4val = [version4, length4, ?prefix4] pref4val = [version4, length4, ?prefix4]
version4 = 4 version4 = 4
length4 = 0..32 ; requested or offered prefix length length4 = 0..32 ; requested or offered prefix length
prefix4 = bytes .size 4 ; offered prefix in binary format prefix4 = bytes .size 4 ; offered prefix in binary format
]]></artwork> </sourcecode>
</figure> </t> <t indent="0" pn="section-5.2-3">Prefix and address management for IPv4
is considerably more difficult
<t>Prefix and address management for IPv4 is considerably more difficult than for IPv6, due to the prevalence of NAT, ambiguous addresses <xref t
than for IPv6, due to the prevalence of NAT, ambiguous addresses <xref t arget="RFC1918" format="default" sectionFormat="of" derivedContent="RFC1918"/>,
arget="RFC1918"/>, and address sharing <xref target="RFC6346" format="default" sectionForma
and address sharing <xref target="RFC6346"/>. These complexities might r t="of" derivedContent="RFC6346"/>. These complexities might require further exte
equire further extending nding
the objective with additional fields which are not defined by this docum the objective with additional fields that are not defined by this docume
ent.</t> nt.</t>
</section> </section>
</section> </section>
<section anchor="prefixManageParams" numbered="true" toc="include" removeInR
<section anchor="prefixManageParams" title="Prefix Management Parameters"> FC="false" pn="section-6">
<t>An implementation of a prefix manager MUST include default settings <name slugifiedName="name-prefix-management-parameter">Prefix Management P
arameters</name>
<t indent="0" pn="section-6-1">An implementation of a prefix manager <bcp1
4>MUST</bcp14> include default settings
of all necessary parameters. However, within a single administrative of all necessary parameters. However, within a single administrative
domain, the network operator MAY change default parameters for all domain, the network operator <bcp14>MAY</bcp14> change default parameters
devices with a certain role. Thus it would be possible to apply an for all
devices with a certain role. Thus, it would be possible to apply an
intended policy for every device in a simple way, without traditional intended policy for every device in a simple way, without traditional
configuration files. As noted in <xref target="reqbehave"/>, individual configuration files. As noted in <xref target="reqbehave" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, individual
autonomic devices may also change their own behavior dynamically.</t> autonomic devices may also change their own behavior dynamically.</t>
<t indent="0" pn="section-6-2">For example, the network operator could cha
<t>For example, the network operator could change the default prefix nge the default prefix
length for each type of role. A prefix management parameters objective, length for each type of role. A prefix management parameters objective,
which contains mapping information of device roles and their default which contains mapping information of device roles and their default
prefix lengths, MAY be flooded in the network, through the Autonomic prefix lengths, <bcp14>MAY</bcp14> be flooded in the network, through the
Control Plane (ACP) <xref target="I-D.ietf-anima-autonomic-control-plane"/ Autonomic
>. Control Plane (ACP) <xref target="RFC8994" format="default" sectionFormat=
"of" derivedContent="RFC8994"/>.
The objective is defined in CDDL as follows:</t> The objective is defined in CDDL as follows:</t>
<sourcecode type="cddl" markers="false" pn="section-6-3">
<figure>
<artwork><![CDATA[
objective = ["PrefixManager.Params", objective-flags, any] objective = ["PrefixManager.Params", objective-flags, any]
loop-count = 0..255 ; as in the GRASP specification loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification objective-flags /= ; as in the GRASP specification
</sourcecode>
]]></artwork> <t indent="0" pn="section-6-4">The "any" object would be the relevant para
</figure> meter definitions (such as
<t>The 'any' object would be the relevant parameter definitions (such as
the example below) transmitted as a CBOR object in an appropriate the example below) transmitted as a CBOR object in an appropriate
format.</t> format.</t>
<t indent="0" pn="section-6-5">This could be flooded to all nodes, and any
<t>This could be flooded to all nodes, and any PrefixManager ASA that PrefixManager ASA that
did not receive it for some reason could obtain a copy using GRASP did not receive it for some reason could obtain a copy using GRASP
unicast synchronization. Upon receiving the prefix management unicast synchronization. Upon receiving the prefix management
parameters, every device can decide its default prefix length by parameters, every device can decide its default prefix length by
matching its own role.</t> matching its own role.</t>
<section anchor="exparam" numbered="true" toc="include" removeInRFC="false
<section anchor="exparam" title="Example of Prefix Management Parameters"> " pn="section-6.1">
<t>The parameters comprise mapping information of device roles and <name slugifiedName="name-example-of-prefix-managemen">Example of Prefix
Management Parameters</name>
<t indent="0" pn="section-6.1-1">The parameters comprise mapping informa
tion of device roles and
their default prefix lengths in an autonomic domain. For example, their default prefix lengths in an autonomic domain. For example,
suppose an IPRAN (IP Radio Access Network) operator wants to configure suppose an IPRAN (IP Radio Access Network) operator wants to configure
the prefix length of Radio Network Controller Site Gateway (RSG) as 34, the prefix length of a Radio Network Controller Site Gateway (RSG) as 34
the prefix length , the prefix length
of Aggregation Site Gateway (ASG) as 44, and the prefix length of Cell of an Aggregation Site Gateway (ASG) as 44, and the prefix length of a C
ell
Site Gateway (CSG) as 56. This could be described in the value of the Site Gateway (CSG) as 56. This could be described in the value of the
PrefixManager.Params objective as:</t> PrefixManager.Params objective as:</t>
<sourcecode type="json" markers="false" pn="section-6.1-2">
<figure>
<artwork><![CDATA[
[ [
[["role", "RSG"],["prefix_length", 34]], [["role", "RSG"],["prefix_length", 34]],
[["role", "ASG"],["prefix_length", 44]], [["role", "ASG"],["prefix_length", 44]],
[["role", "CSG"],["prefix_length", 56]] [["role", "CSG"],["prefix_length", 56]]
] ]
]]></artwork> </sourcecode>
</figure> <t indent="0" pn="section-6.1-3">This example is expressed in JSON <xref
target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/>
<t>This example is expressed in JSON notation <xref target="RFC7159"/>, , which is easy to represent in CBOR.</t>
which is easy to represent in CBOR.</t> <t indent="0" pn="section-6.1-4">An alternative would be to express the
parameters in YANG <xref target="RFC7950" format="default" sectionFormat="of" de
<t>An alternative would be to express the parameters in YANG <xref targe rivedContent="RFC7950"/> using the YANG-to-CBOR mapping <xref target="CORE-YANG-
t="RFC7950"/> using the YANG-to-CBOR mapping <xref target="I-D.ietf-core-yang-cb CBOR" format="default" sectionFormat="of" derivedContent="CORE-YANG-CBOR"/>.</t>
or"/>.</t> <t indent="0" pn="section-6.1-5">For clarity, the background of the exam
ple is introduced below
<t>For clarity, the background of the example is introduced below, and can also be regarded as a use case for the mechanism defined in
which can also be regarded as a use case of the mechanism proposed in
this document.</t> this document.</t>
<t indent="0" pn="section-6.1-6">An IPRAN is used for mobile backhaul, i
<t>An IPRAN network is used for mobile backhaul, including radio ncluding radio
stations, RNC (in 3G) or the packet core (in LTE), and the IP network stations, RNCs (Radio Network Controllers) (in 3G) or the packet core (i
between them as shown in Figure 1. The eNB (Evolved Node B), RNC n LTE), and the IP network
(Radio Network Controller), SGW (Service Gateway), and MME (Mobility between them, as shown in <xref target="IPRAN-topology" format="default"
sectionFormat="of" derivedContent="Figure 1"/>. The eNB (Evolved Node B) entiti
es, the RNC, the SGW (Serving Gateway), and the MME (Mobility
Management Entity) are mobile network entities defined in 3GPP. The Management Entity) are mobile network entities defined in 3GPP. The
CSG, ASG, and RSG are entities defined in the IPRAN solution.</t> CSGs, ASGs, and RSGs are entities defined in the IPRAN solution.</t>
<t indent="0" pn="section-6.1-7">The IPRAN topology shown in <xref targe
<t>The IPRAN topology shown in Figure 1 includes Ring1 which is the t="IPRAN-topology" format="default" sectionFormat="of" derivedContent="Figure 1"
circle following ASG1-&gt;RSG1-&gt;RSG2-&gt;ASG2-&gt;ASG1, Ring2 />
following CSG1-&gt;ASG1-&gt;ASG2-&gt;CSG2-&gt;CSG1, and Ring3 includes Ring1, which is the
following CSG3-&gt;ASG1-&gt;ASG2-&gt;CSG3. In a real deployment of circle following ASG1-&gt;RSG1-&gt;RSG2-&gt;ASG2-&gt;ASG1; Ring2,
following CSG1-&gt;ASG1-&gt;ASG2-&gt;CSG2-&gt;CSG1; and 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, IPRAN, there may be more stations, rings, and routers in the topology,
and normally the network is highly dependent on human design and and normally the network is highly dependent on human design and
configuration, which is neither flexible nor cost-effective.</t> configuration, which is neither flexible nor cost-effective.</t>
<figure anchor="IPRAN-topology" align="left" suppress-title="false" pn="
<t><figure> figure-1">
<artwork><![CDATA[ <name slugifiedName="name-ipran-topology-example">IPRAN Topology Examp
le</name>
<artwork name="" type="" align="left" alt="" pn="section-6.1-8.1">
+------+ +------+ +------+ +------+
| eNB1 |---| CSG1 |\ | eNB1 |---| CSG1 |\
+------+ +------+ \ +-------+ +------+ +-------+ +------+ +------+ \ +-------+ +------+ +-------+
| \ | ASG1 |-------| RSG1 |-----------|SGW/MME| | \ | ASG1 |-------| RSG1 |-----------|SGW/MME|
| Ring2 +-------+ +------+ \ /+-------+ | Ring2 +-------+ +------+ \ /+-------+
+------+ +------+ / | | \ / +------+ +------+ / | | \ /
| eNB2 |---| CSG2 | \ / | Ring1 | \/ | eNB2 |---| CSG2 | \ / | Ring1 | \/
+------+ +------+ \ Ring3| | /\ +------+ +------+ \ Ring3| | /\
/ \ | | / \ / \ | | / \
+------+ +------+ / \ +-------+ +------+/ \+-------+ +------+ +------+ / \ +-------+ +------+/ \+-------+
| eNB3 |---| CSG3 |--------| ASG2 |------| RSG2 |---------| RNC | | eNB3 |---| CSG3 |--------| ASG2 |------| RSG2 |---------| RNC |
+------+ +------+ +-------+ +------+ +-------+ +------+ +------+ +-------+ +------+ +-------+
</artwork>
Figure 1: IPRAN Topology Example]]></artwork> </figure>
</figure></t> <t indent="0" pn="section-6.1-9">If ANI/GRASP is supported in the IPRAN,
the network nodes
<t>If ANI/GRASP is supported in the IPRAN network, the network nodes should be able to negotiate with each other and make some autonomic
should be able to negotiate with each other, and make some autonomic
decisions according to their own status and the information decisions according to their own status and the information
collected from the network. The Prefix Management Parameters should be collected from the network. The prefix management parameters should be
part of the information they communicate.</t> part of the information they communicate.</t>
<t indent="0" pn="section-6.1-10">The routers should know the role of th
<t>The routers should know the role of their neighbors, the default eir neighbors, the default
prefix length for each type of role, etc. An ASG should be able to prefix length for each type of role, etc. An ASG should be able to
request prefixes from an RSG, and an CSG should be able to request prefi xes from request prefixes from an RSG, and a CSG should be able to request prefix es from
an ASG. In each request, the ASG/CSG should indicate the required prefix length, or its role, 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> which implies what length it needs by default.</t>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="include" removeInRFC="false"
<section anchor="security" title="Security Considerations"> pn="section-7">
<t>Relevant security issues are discussed in <xref target="I-D.ietf-anima- <name slugifiedName="name-security-considerations">Security Considerations
grasp"/>. The preferred security model is that </name>
devices are trusted following the secure bootstrap procedure <xref target= <t indent="0" pn="section-7-1">Relevant security issues are discussed in <
"I-D.ietf-anima-bootstrapping-keyinfra"/> and that a secure xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC899
Autonomic Control Plane (ACP) <xref target="I-D.ietf-anima-autonomic-contr 0"/>. The preferred security model is that
ol-plane"/> is in place.</t> devices are trusted following the secure bootstrap procedure <xref target=
"RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/> and tha
<t>It is RECOMMENDED that DHCPv6-PD, if used, should be operated using t a secure
Autonomic Control Plane (ACP) <xref target="RFC8994" format="default" sect
ionFormat="of" derivedContent="RFC8994"/> is in place.</t>
<t indent="0" pn="section-7-2">It is <bcp14>RECOMMENDED</bcp14> that DHCPv
6-PD, if used, should be implemented using
DHCPv6 authentication or Secure DHCPv6.</t> DHCPv6 authentication or Secure DHCPv6.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn=
<!-- security --> "section-8">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section anchor="iana" title="IANA Considerations"> <t indent="0" pn="section-8-1">This document defines two new GRASP Objecti
<t>This document defines two new GRASP Objective Option names, ve option names:
"PrefixManager" and "PrefixManager.Params". The IANA is requested to add "PrefixManager" and "PrefixManager.Params". The IANA has added
these to the GRASP Objective Names Table registry defined by <xref target= these to the "GRASP Objective Names" registry defined by <xref target="RFC
"I-D.ietf-anima-grasp"/> (if approved).</t> 8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>.</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 the xml2rfc tool <xref target="RF
C7749"/>.</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 and
coauthor Zongpeng Du, 2015-05-04.</t>
<t>draft-jiang-anima-prefix-management-02: update references and the
format 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, update
d 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-1
8.</t>
</section> </section>
<!-- changes -->
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-9">
<?rfc include='reference.I-D.ietf-anima-grasp'?> <name slugifiedName="name-references">References</name>
<references pn="section-9.1">
<?rfc include='reference.I-D.ietf-cbor-cddl'?> <name slugifiedName="name-normative-references">Normative References</na
me>
<?rfc include='reference.I-D.ietf-anima-bootstrapping-keyinfra'?> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<?rfc include='reference.I-D.ietf-anima-autonomic-control-plane'?> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
<?rfc include='reference.RFC.3633'?> le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<?rfc include='reference.RFC.2119'?> <organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.8174'?> </author>
<date year="1997" month="March"/>
<?rfc include='reference.RFC.7159'?> <abstract>
<t indent="0">In many standards track documents several words are
<?rfc include='reference.RFC.7950'?> used to signify the requirements in the specification. These words are often ca
</references> pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
<references title="Informative References"> e Internet Community, and requests discussion and suggestions for improvements.<
/t>
<?rfc include='reference.RFC.1918'?> </abstract>
</front>
<?rfc include='reference.RFC.6346'?> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<?rfc include='reference.RFC.2865'?> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<?rfc include='reference.I-D.ietf-core-yang-cbor'?> <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
950" quoteTitle="true" derivedAnchor="RFC7950">
<?rfc include='reference.RFC.7575'?> <front>
<title>The YANG 1.1 Data Modeling Language</title>
<?rfc include='reference.RFC.7576'?> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<?rfc include='reference.RFC.3046'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.6221'?> <date year="2016" month="August"/>
<abstract>
<?rfc include='reference.RFC.7049'?> <t indent="0">YANG is a data modeling language used to model confi
guration data, state data, Remote Procedure Calls, and notifications for network
<?rfc include='reference.I-D.ietf-anima-reference-model'?> management protocols. This document describes the syntax and semantics of vers
ion 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the
<?rfc include='reference.I-D.liu-dhc-dhcp-yang-model'?> YANG language, addressing ambiguities and defects in the original specification.
There are a small number of backward incompatibilities from YANG version 1. T
his document also specifies the YANG mappings to the Network Configuration Proto
col (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/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</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/rfc8
259" 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 t
he ECMAScript Programming Language Standard. JSON defines a small set of format
ting rules for the portable representation of structured data.</t>
<t indent="0">This document removes inconsistencies with other spe
cifications of JSON, repairs specification errors, and offers experience-based i
nteroperability 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/rfc8
415" 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 Configurati
on Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes wit
h network configuration parameters, IP addresses, and prefixes. Parameters can b
e provided statelessly, or in combination with stateful assignment of one or mor
e 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 or
iginal DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stat
eless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a clie
nt should wait before refreshing information (RFC 4242), a mechanism for throttl
ing DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay ag
ent handling of unknown messages (RFC 7283). In addition, this document clarifi
es the interactions between models of operation (RFC 7550). As such, this docum
ent obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RF
C 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/rfc8
610" quoteTitle="true" derivedAnchor="RFC8610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</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 ex
press Concise Binary Object Representation (CBOR) data structures (RFC 7049). I
ts 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/rfc8
990" 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/rfc8
994" quoteTitle="true" derivedAnchor="RFC8994">
<front>
<title>An Autonomic Control Plane (ACP)</title>
<author initials="T" surname="Eckert" fullname="Toerless Eckert" rol
e="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 Bjarnas
on">
<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/rfc8
995" 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 Richards
on">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Eckert" fullname="Toerless Eckert">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Behringer" fullname="Michael Behringe
r">
<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://too
ls.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://to
ols.ietf.org/html/draft-liu-dhc-dhcp-yang-model-07" derivedAnchor="DHCP-YANG-MOD
EL">
<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/rfc1
918" 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 priva
te internets. This document specifies an Internet Best Current Practices for th
e 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/rfc2
865" 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 auth
entication, authorization, and configuration information between a Network Acces
s Server which desires to authenticate its links and a shared Authentication Ser
ver. [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/rfc3
046" 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 o
ne or more customer premise hosts. It is advantageous to use the Dynamic Host C
onfiguration Protocol (DHCP) as defined in RFC 2131 to assign customer premise h
ost 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/rfc6
221" quoteTitle="true" derivedAnchor="RFC6221">
<front>
<title>Lightweight DHCPv6 Relay Agent</title>
<author initials="D." surname="Miles" fullname="D. Miles" role="edit
or">
<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 Ag
ent (LDRA) that is used to insert relay agent options in DHCPv6 message exchange
s 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. [STAN
DARDS-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/rfc6
346" quoteTitle="true" derivedAnchor="RFC6346">
<front>
<title>The Address plus Port (A+P) Approach to the IPv4 Address Shor
tage</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 I
P address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully r
eplace 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 IP
v4 world without assigning a unique globally routable IPv4 address to each of th
em is a challenging problem.</t>
<t indent="0">This document proposes an IPv4 address sharing schem
e, treating some of the port number bits as part of an extended IPv4 address (Ad
dress plus Port, or A+P). Instead of assigning a single IPv4 address to a singl
e 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, thu
s leaving a reduced range of ports available to applications. This means assign
ing 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 i
s needed, the end-user should be in control of the translation process -- not so
me 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/rfc7
575" 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-optimiz
ation, self-healing, and self-protection. This is achieved by an autonomic func
tion having minimal dependencies on human administrators or centralized manageme
nt systems. It usually implies distribution across network elements.</t>
<t indent="0">This document defines common language and outlines d
esign goals (and what are not design goals) for autonomic functions. A high-lev
el reference model illustrates how functional elements in an Autonomic Network i
nteract. This document is a product of the IRTF's Network Management Research G
roup.</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/rfc7
576" 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 gener
al gap analysis for an IP-based Autonomic Network that is mainly based on distri
buted network devices. The document provides background by reviewing the curren
t status of autonomic aspects of IP networks and the extent to which current net
work management depends on centralization and human administrators. Finally, th
e document outlines the general features that are missing from current network a
bilities and are needed in the ideal Autonomic Network concept.</t>
<t indent="0">This document is a product of the IRTF's Network Man
agement 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/rfc8
650" quoteTitle="true" derivedAnchor="RFC8650">
<front>
<title>Dynamic Subscription to YANG Events and Datastores over RESTC
ONF</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-N
ygaard">
<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 dyn
amic 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/rfc8
949" 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 a
data format whose design goals include the possibility of extremely small code
size, fairly small message size, and extensibility without the need for version
negotiation. These design goals make it different from earlier binary serializat
ions such as ASN.1 and MessagePack.</t>
<t indent="0">This document obsoletes RFC 7049, providing editoria
l improvements, new details, and errata fixes while keeping full compatibility w
ith the interchange format of RFC 7049. It does not create a new version of the
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/rfc8
993" 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> </references>
<section numbered="true" toc="include" removeInRFC="false" pn="section-appen
<section title="Deployment Overview"> dix.a">
<t>This Appendix includes logical deployment models, and explanations of <name slugifiedName="name-deployment-overview">Deployment Overview</name>
the target deployment models. The purpose is to help in understanding <t indent="0" pn="section-appendix.a-1">This appendix includes logical dep
the mechanism of the document.</t> loyment models and explanations of
the target deployment models. Its purpose is to help in understanding
<t>This Appendix includes two sub-sections: A.1 for the two most common the mechanism described in this document.</t>
DHCP deployment models, and A.2 for the proposed PD deployment model. It <t indent="0" pn="section-appendix.a-2">This appendix includes two subsect
ions:
<xref target="app-a1" format="default" sectionFormat="of" derivedContent="
Appendix A.1"/> for the two most common
DHCP deployment models and <xref target="app-a2" format="default" sectionF
ormat="of" derivedContent="Appendix A.2"/> for the PD deployment model described
in this document. It
should be noted that these are just examples, and there are many more should be noted that these are just examples, and there are many more
deployment models.</t> deployment models.</t>
<section anchor="app-a1" numbered="true" toc="include" removeInRFC="false"
<section title="Address &amp; Prefix management with DHCP"> pn="section-a.1">
<t>Edge DHCP server deployment requires every edge router connecting <name slugifiedName="name-address-and-prefix-manageme">Address and Prefi
to CPE to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and x Management with DHCP</name>
optionally IPv6 prefixes via DHCPv6-PD for IPv6 capable CPE that are <t indent="0" pn="section-a.1-1">Edge DHCP server deployment requires ev
router and have LANs behind them.</t> ery edge router connecting
to a Customer Premises Equipment (CPE) device to be a DHCP server assign
<figure> ing IPv4/IPv6 addresses to CPEs -- and,
<artwork><![CDATA[ optionally, IPv6 prefixes via DHCPv6-PD for IPv6-capable CPEs that are
routers and have LANs behind them.</t>
<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 edge
dynamic, "netconf/YANG" interfaces dynamic, "NETCONF/YANG" interfaces
<---------------> +-------------+ &lt;---------------&gt; +-------------+
+------+ <- telemetry | edge router/|-+ ----- +-----+ +------+ &lt;- telemetry | edge router/|-+ ----- +-----+
|config| .... Domain ... | DHCP server | | ... | CPE |+ LANs |config| .... domain ... | DHCP server | | ... | CPE |+ LANs
|server| +-------------+ | ----- +-----+| (---| ) |server| +-------------+ | ----- +-----+| (---| )
+------+ +--------------+ DHCP/ +-----+ +------+ +--------------+ DHCP/ +-----+
DHCPv6 / PD DHCPv6-PD
</artwork>
Figure 2: DHCP Deployment Model without a Central DHCP Server
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-a.1-3">This requires various coordination func
<t>This requires various coordination functions via some backend tions via some backend
system depicted as "config server": The address prefixes on the edge system (depicted as the "config server" in <xref target="fig2" format="d
efault" sectionFormat="of" derivedContent="Figure 2"/>): the address prefixes on
the edge
interfaces should be slightly larger than required for the number of interfaces should be slightly larger than required for the number of
CPEs connected so that the overall address space is best used.</t> CPEs connected so that the overall address space is best used.</t>
<t indent="0" pn="section-a.1-4">The config server needs to provision ed
<t>The config server needs to provision edge interface address ge interface address
prefixes and DHCP parameters for every edge router. If too fine prefixes and DHCP parameters for every edge router. If prefixes that are
grained prefixes are used, this will result in large routing tables too fine-grained are used, this will result in large routing tables
across the "Domain". If too coarse grained prefixes are used, address across the domain shown in the figure. If prefixes that are too coarse-g
rained are used, address
space is wasted. (This is less of a concern for IPv6, but if the space is wasted. (This is less of a concern for IPv6, but if the
model includes IPv4, it is a very serious concern.)</t> model includes IPv4, it is a very serious concern.)</t>
<t indent="0" pn="section-a.1-5">There is no standard that describes alg
<t>There is no standard describing algorithms for how configuration serv orithms for how configuration servers
ers
would best perform this ongoing dynamic provisioning to optimize would best perform this ongoing dynamic provisioning to optimize
routing table size and address space utilization.</t> routing table size and address space utilization.</t>
<t indent="0" pn="section-a.1-6">There are currently no complete YANG da
<t>There are currently no complete YANG models that a config server ta models that a config server
could use to perform these actions (including telemetry of assigned could use to perform these actions (including telemetry of assigned
addresses from such distributed DHCP servers).</t> addresses from such distributed DHCP servers). For example, a YANG data
model for controlling DHCP server operations is
<t>For example, a YANG model for controlling DHCP server operations is still being developed <xref target="DHCP-YANG-MODEL" format="default" se
still in draft <xref target="I-D.liu-dhc-dhcp-yang-model"/>.</t> ctionFormat="of" derivedContent="DHCP-YANG-MODEL"/>.</t>
<t indent="0" pn="section-a.1-7">Due to these and other problems related
<t>Due to these and other problems of the above model, the more common to the above model, the more common
DHCP deployment model is as follows:</t> DHCP deployment model is as follows:</t>
<figure align="left" suppress-title="false" pn="figure-3">
<figure> <name slugifiedName="name-dhcp-deployment-model-with-">DHCP Deployment
<artwork><![CDATA[ Model with a Central DHCP Server</name>
<artwork name="" type="" align="left" alt="" pn="section-a.1-8.1">
+------+ edge +------+ edge
|config| initial, "CLI" interfaces |config| initial, "CLI" interfaces
|server| ----------------> +-------------+ |server| ----------------&gt; +-------------+
+------+ | edge router/|-+ ----- +-----+ +------+ | edge router/|-+ ----- +-----+
| .... Domain ... | DHCP relay | | ... | CPE |+ LANs | .... domain ... | DHCP relay | | ... | CPE |+ LANs
+------+ +-------------+ | ----- +-----+| (---| ) +------+ +-------------+ | ----- +-----+| (---| )
|DHCP | +--------------+ DHCP/ +-----+ |DHCP | +--------------+ DHCP/ +-----+
|server| DHCPv6 / PD |server| DHCPv6-PD
+------+ +------+
</artwork>
Figure 3: DHCP Deployment Model with a Central DHCP Server
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-a.1-9">Dynamic provisioning changes to edge ro
<t>Dynamic provisioning changes to edge routers are avoided by using a uters are avoided by using a
central DHCP server and reducing the edge router from DHCP server to central DHCP server and reducing the edge router from DHCP server to
DHCP relay. The "configuration" on the edge routers is static, the DHCP relay. The "configuration" on the edge routers is static. The
DHCP relay function inserts "edge interface" and/or subscriber DHCP relay function inserts an "edge interface" and/or
identifying options into DHCP requests from CPE (e.g., <xref target="RFC subscriber-identifying options into DHCP requests from CPEs (e.g., <xref
3046"/>, <xref target="RFC6221"/>), the DHCP server has target="RFC3046" format="default" sectionFormat="of" derivedContent="RFC3046"/>
complete policies for address assignments and prefixes useable on <xref target="RFC6221" format="default" sectionFormat="of" derivedContent="RFC6
every edge-router/interface/subscriber-group. When the DHCP relay sees 221"/>), and the DHCP server has
complete policies for address assignments and prefixes usable on
every edge router / interface / subscriber group. When the DHCP relay se
es
the DHCP reply, it inserts static routes for the assigned the DHCP reply, it inserts static routes for the assigned
address/address-prefix into the routing table of the edge router which address / address prefix into the routing table of the edge router; thes e routes
are then to be distributed by the IGP (or BGP) inside the domain to are then to be distributed by the IGP (or BGP) inside the domain to
make the CPE and LANs reachable across the Domain.</t> make the CPE and LANs reachable across the domain shown in the figure.</
t>
<t>There is no comprehensive standardization of these solutions. <xref t <t indent="0" pn="section-a.1-10">There is no comprehensive standardizat
arget="RFC3633"/> section 14, for example, simply refers to "a ion of these solutions. For example, <xref target="RFC8415" sectionFormat="comma
[non-defined] protocol or other out-of-band communication to add " section="19.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8
routing information for delegated prefixes into the provider edge 415#section-19.1.3" derivedContent="RFC8415"/> simply
router".</t> refers to "a [non-defined] protocol or other out-of-band communication t
o
configure routing information for delegated prefixes on any router
through which the client may forward traffic."</t>
</section> </section>
<section anchor="app-a2" numbered="true" toc="include" removeInRFC="false"
<section title="Prefix management with ANI/GRASP"> pn="section-a.2">
<t>With the proposed use of ANI and Prefix-management ASAs using <name slugifiedName="name-prefix-management-with-ani-">Prefix Management
GRASP, the deployment model is intended to look as follows:</t> with ANI/GRASP</name>
<t indent="0" pn="section-a.2-1">Using the ANI and prefix management ASA
<figure> s (PM-ASAs) using GRASP, the deployment
<artwork><![CDATA[ model is intended to look as follows:</t>
|<............ ANI Domain / ACP............>| (...) ........-> <figure anchor="fig4" align="left" suppress-title="false" pn="figure-4">
<name slugifiedName="name-deployment-model-using-ani-">Deployment Mode
l Using ANI/GRASP</name>
<artwork name="" type="" align="left" alt="" pn="section-a.2-2.1">
|&lt;............ ANI domain / ACP............&gt;| (...) ........-&gt;
Roles Roles
| |
v "Edge routers" v "Edge routers"
GRASP parameter +----------+ GRASP parameter +----------+
Network wide | PM-ASA | downstream Network-wide | PM-ASA | downstream
parameters/policies | (DHCP- | interfaces parameters/policies | (DHCP | interfaces
| |functions)| ------ | |functions)| ------
v "central device" +----------+ v "central device" +----------+
+------+ ^ +--------+ +------+ ^ +--------+
|PM-ASA| <............GRASP .... .... | CPE |-+ (LANs) |PM-ASA| &lt;............GRASP .... .... | CPE |-+ (LANs)
+------+ . v |(PM-ASA)| | ---| +------+ . v |(PM-ASA)| | ---|
. +........+ +----------+ +--------+ | . +........+ +----------+ +--------+ |
+...........+ . PM-ASA . | PM-ASA | ------ +---------+ +...........+ . PM-ASA . | PM-ASA | ------ +---------+
.DHCP server. +........+ | (DHCP- | SLAAC/ .DHCP server. +........+ | (DHCP | SLAAC/
+...........+ "intermediate |functions)| DHCP/DHCP-PD +...........+ "intermediate |functions)| DHCP/DHCP-PD
router" +----------+ router" +----------+
</artwork>
Figure 4: Proposed Deployment Model using ANI/GRASP
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-a.2-3">The network runs an ANI domain with an
<t>The network runs an ANI domain with ACP <xref target="I-D.ietf-anima- ACP <xref target="RFC8994" format="default" sectionFormat="of" derivedContent="R
autonomic-control-plane"/> between some central FC8994"/> between some central
device (e.g., router or ANI enabled management device) and the edge device (e.g., a router or an ANI-enabled management device) and the edge
routers. ANI/ACP provides a secure, zero-touch communication channel routers. ANI/ACP provides a secure, zero-touch communication channel
between the devices and enables the use of GRASP<xref target="I-D.ietf-a nima-grasp"> </xref> not only for p2p communication, between the devices and enables the use of GRASP <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"> </xref> not only f or peer-to-peer communication
but also for distribution/flooding.</t> but also for distribution/flooding.</t>
<t indent="0" pn="section-a.2-4">The central devices and edge routers ru
<t>The central devices and edge routers run software n software
in the form of "Autonomic Service Agents" (ASA) to support this in the form of ASAs to support this document's autonomic IPv6 edge prefi
document's autonomic IPv6 edge prefix management (PM). x management. PM-ASAs as discussed below
The ASAs for prefix management are called PM-ASAs below, together comprise the Autonomic Prefix Management Function.</t>
and together comprise the Autonomic Prefix Management Function.</t> <t indent="0" pn="section-a.2-5">Edge routers can have different roles b
ased on the type and number
<t>Edge routers can have different roles based on the type and number of CPEs attaching to them. Each edge router could be an RSG, ASG, or CSG
of CPE attaching to them. Each edge router could be an RSG, ASG, or CSG in mobile aggregation networks (see <xref target="exparam" format="defau
in mobile aggregation networks (see Section 6.1). Mechanisms outside lt" sectionFormat="of" derivedContent="Section 6.1"/>). Mechanisms outside
the scope of this document make routers aware of their roles.</t> the scope of this document make routers aware of their roles.</t>
<t indent="0" pn="section-a.2-6">Some considerations related to the depl
<t>Some considerations about the proposed deployment model are listed oyment model are
as follows.</t> as follows.</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-a.
<t>1. In a minimum Prefix Management solution, the central device uses 2-7">
the "PrefixManager.Params" GRASP Objective introduced in this document <li pn="section-a.2-7.1" derivedCounter="1.">
to disseminate network wide, per-role parameters to edge routers. The <t indent="0" pn="section-a.2-7.1.1">In a minimum prefix management
PM-ASA uses the parameters applying to its role to locally solution, the central device uses
configure pre-existing addressing functions. Because PM-ASA does the PrefixManager.Params GRASP objective introduced in this document
to disseminate network-wide, per-role parameters to edge routers. The
PM-ASA uses the parameters that apply to its own role to locally
configure preexisting addressing functions. Because the PM-ASA does
not manage the dynamic assignment of actual IPv6 address prefixes in not manage the dynamic assignment of actual IPv6 address prefixes in
this case, the following options can be considered:</t> this case, the following options can be considered:</t>
<ol spacing="normal" type="1.%c" indent="adaptive" start="1" pn="sec
<t>1.a The edge router connects via downstream interfaces to (host) tion-a.2-7.1.2">
CPE that each requires an address. The PM-ASA sets up for each such <li pn="section-a.2-7.1.2.1" derivedCounter="1.a">The edge router connec
interface a DHCP requesting router (according to <xref target="RFC3633"/ ts via downstream interfaces to each (host)
>) CPE that requires an address. The PM-ASA sets up for each such
interface a DHCP requesting router (according to <xref target="RFC8415"
format="default" sectionFormat="of" derivedContent="RFC8415"/>)
to request an IPv6 prefix for the interface. The to request an IPv6 prefix for the interface. The
router's address on the downstream interface can be another parameter router's address on the downstream interface can be another parameter
from the GRASP Objective. The CPEs assign addresses in the prefix via from the GRASP objective. The CPEs assign addresses in the prefix via
RAs from the router or the PM-ASA manages a local DHCPv6 server to Router Advertisements (RAs), or the PM‑ASA manages a local DHCPv6 server
to
assign addresses to the CPEs. A central DHCP server acting as the DHCP assign addresses to the CPEs. A central DHCP server acting as the DHCP
delegating router (according to <xref target="RFC3633"/>) is required. delegating router (according to <xref target="RFC8415" format="default"
Its address can be another parameter from the GRASP Objective.</t> sectionFormat="of" derivedContent="RFC8415"/>) is required.
Its address can be another parameter from the GRASP objective.</li>
<t>1.b The edge router also connects via downstream interfaces to <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 (customer managed) CPEs that are routers and act as DHCPv6 requesting
routers. The need to support this could be derived from role and/or routers. The need to support this could be derived from role or
GRASP parameters and the PM-ASA sets up a DHCP relay function to pass GRASP parameters, and the PM‑ASA sets up a DHCP relay function to pass
on requests to the central DHCP server as in 1.a.</t> on requests to the central DHCP server as in point 1.a.</li>
</ol>
<t>2. In a solution without a central DHCP server, the PM-ASA on the </li>
edge routers not only learn parameters from "PrefixManager.Params" <li pn="section-a.2-7.2" derivedCounter="2.">
but also utilize GRASP to request/negotiate actual IPv6 prefix <t indent="0" pn="section-a.2-7.2.1">In a solution without a central
delegation via the GRASP "PrefixManager" objective described in more DHCP server, the PM-ASA on the
detail below. In the most simple case, these prefixes are delegated edge routers not only learns parameters from PrefixManager.Params
but also utilizes GRASP to request/negotiate actual IPv6 prefix
delegation via the GRASP PrefixManager objective, as described in more
detail below. In the simplest case, these prefixes are delegated
via this GRASP objective from the PM-ASA in the central device. via this GRASP objective from the PM-ASA in the central device.
This device must be provisioned initially with a large pool of This device must be provisioned initially with a large pool of
prefixes. The delegated prefixes. The delegated
prefixes are then used by the PM-ASA on the edge routers to edge prefixes are then used by the PM-ASA on the edge routers to configure pr
routers to configure prefixes on their downstream interfaces to assign efixes on their downstream interfaces to assign
addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local
DHCP servers (as in 1.a) to assign addresses via DHCP to CPE from the DHCP servers (as in point 1.a) to assign addresses via DHCP to the CPEs from the
prefixes it received. This includes both host CPEs requesting IPv6 prefixes it received. This includes both host CPEs requesting IPv6
addresses as well as router CPEs that request IPv6 prefixes. The addresses and router CPEs that request IPv6 prefixes. The
PM-ASA needs to manage the address pool(s) it has requested via GRASP 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 and allocate sub-address pools to interfaces and the local DHCP
servers it starts. It needs to monitor the address utilization and servers it starts. It needs to monitor the address utilization and
accordingly request more address prefixes if its existing prefixes are accordingly request more address prefixes if its existing prefixes are
exhausted, or return address prefixes when they are unneeded.</t> exhausted, or return address prefixes when they are unneeded.</t>
<t indent="0" pn="section-a.2-7.2.2">This solution is quite similar
<t>This solution is quite similar to the initial described IPv6 DHCP to the previous IPv6 DHCP
deployment model without central DHCP server, and ANI/ACP/GRASP and 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 the PM-ASA do provide the automation to make this approach work more
easily than it is possible today.</t> easily than is possible today.</t>
</li>
<t>3. The address pool(s) from which prefixes are allocated does not <li pn="section-a.2-7.3" derivedCounter="3.">The address pools from wh
need to be taken all from one central location. Edge router PM-ASA ich prefixes are allocated do not all
need to be taken from one central location. An edge-router PM‑ASA
that received a big (short) prefix from a central PM-ASA could offer that received a big (short) prefix from a central PM-ASA could offer
smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be smaller sub-prefixes to a neighboring edge-router PM‑ASA. GRASP could be
used in such a way that the PM-ASA would find and select the objective used in such a way that the PM-ASA would find and select the objective
from the closest neighboring PM-ASA, therefore allowing to maximize from the closest neighboring PM‑ASA, therefore allowing aggregation to b
aggregation: A PM-ASA would only request further (smaller/shorter) e maximized: a PM‑ASA would only request further smaller
prefixes when it exhausts its own poll (from the central location) and prefixes when it exhausts its own pool (from the central location) and
can not get further large prefixes from that central location anymore. cannot get further large prefixes from that central location anymore.
Because the overflow prefixes taken from a topological nearby PM-ASA, Because the overflow prefixes taken from a topologically nearby PM‑ASA,
the number of longer prefixes that have to be injected into the the number of longer prefixes that have to be injected into the
routing tables is limited and the topological proximity increases the routing tables is limited and the topological proximity increases the
chances that aggregation of prefixes in the IGP can most likely limit chances that aggregation of prefixes in the IGP can most likely limit
the geography in which the longer prefixes need to be routed.</t> the geography in which the longer prefixes need to be routed.</li>
<li pn="section-a.2-7.4" derivedCounter="4.">Instead of peer-to-peer o
<t>4. Instead of peer-to-peer optimization of prefix delegation, a ptimization of prefix delegation, a
hierarchy of PM-ASA can be built (indicated in the picture via a hierarchy of PM-ASAs can be built (indicated in <xref target="fig4" form
at="default" sectionFormat="of" derivedContent="Figure 4"/> via a
dotted intermediate router). This would require additional parameters dotted intermediate router). This would require additional parameters
to the "PrefixManager" objective to allow creating a hierarchy of in the PrefixManager objective to allow the creation of a hierarchy of
PM-ASA across which the prefixes can be delegated. This is not PM-ASAs across which the prefixes can be delegated.</li>
detailed further below.</t> <li pn="section-a.2-7.5" derivedCounter="5.">In cases where CPEs are a
lso part of the ANI domain (e.g.,
<t>5. In cases where CPEs are also part of the ANI Domain (e.g., "managed CPEs"), then GRASP will extend into the actual customer sites
"Managed CPE"), then GRASP will extend into the actual customer sites and can also run a PM-ASA. All the options described in points 1 to
and can equally run a PM-ASA. All the options described in points 1 to 4 above would then apply to the CPE as the edge router, with the major
4 above would then apply to the CPE as the edge router with the mayor changes being that (a) a CPE router will most likely not need to run
changes being that a) a CPE router will most likley not need to run DHCPv6-PD itself, but only DHCP address assignment and (b) the edge
DHCPv6-PD itself, but only DHCP address assignment, b) The edge routers to which the CPE connects would most likely become ideal places
routers to which the CPE connect would most likely become ideal places on which to run a hierarchical instance of PD-ASAs, as outlined in
to run a hierarchical instance of PD-ASAs on as outlined in point point 1.</li>
1.</t> </ol>
</section> </section>
</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 fr
om
<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</organ
ization>
<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">Universi
ty 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> </back>
</rfc> </rfc>
 End of changes. 166 change blocks. 
748 lines changed or deleted 1637 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/