File: rfc8992.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2446 lines) | stat: -rw-r--r-- 114,548 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8992: Autonomic IPv6 Edge Prefix Management in Large-Scale Networks</title>
<meta content="Sheng Jiang" name="author">
<meta content="Zongpeng Du" name="author">
<meta content="Brian Carpenter" name="author">
<meta content="Qiong Sun" name="author">
<meta content="
       This document defines two autonomic technical objectives for IPv6 prefix
      management at the edge of large-scale ISP networks,
      with an extension to support IPv4 prefixes. An important purpose
      of this document is to use it for validation of the design of various
      components of the Autonomic Networking Infrastructure. 
    " name="description">
<meta content="xml2rfc 3.8.0" name="generator">
<meta content="Autonomic Networking" name="keyword">
<meta content="Prefix Management" name="keyword">
<meta content="8992" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.8.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8992.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8992" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management-07" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8992</td>
<td class="center">Auto IPv6 Prefix Management</td>
<td class="right">May 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Jiang, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8992" class="eref">8992</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-05" class="published">May 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">S. Jiang, <span class="editor">Ed.</span>
</div>
<div class="org">Huawei Technologies Co., Ltd</div>
</div>
<div class="author">
      <div class="author-name">Z. Du</div>
<div class="org">China Mobile</div>
</div>
<div class="author">
      <div class="author-name">B. Carpenter</div>
<div class="org">Univ. of Auckland</div>
</div>
<div class="author">
      <div class="author-name">Q. Sun</div>
<div class="org">China Telecom</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8992</h1>
<h1 id="title">Autonomic IPv6 Edge Prefix Management in Large-Scale Networks</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines two autonomic technical objectives for IPv6 prefix
      management at the edge of large-scale ISP networks,
      with an extension to support IPv4 prefixes. An important purpose
      of this document is to use it for validation of the design of various
      components of the Autonomic Networking Infrastructure.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="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
            <span><a href="https://www.rfc-editor.org/info/rfc8992">https://www.rfc-editor.org/info/rfc8992</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-problem-statement" class="xref">Problem Statement</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-intended-user-and-administr" class="xref">Intended User and Administrator Experience</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-analysis-of-parameters-and-" class="xref">Analysis of Parameters and Information Involved</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-parameters-each-device-can-" class="xref">Parameters Each Device Can Define for Itself</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.2">
                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="xref">3.2.2</a>.  <a href="#name-information-needed-from-net" class="xref">Information Needed from Network Operations</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.3">
                    <p id="section-toc.1-1.3.2.2.2.3.1"><a href="#section-3.2.3" class="xref">3.2.3</a>.  <a href="#name-comparison-with-current-sol" class="xref">Comparison with Current Solutions</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-interaction-with-other-devi" class="xref">Interaction with Other Devices</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.3.2.1">
                    <p id="section-toc.1-1.3.2.3.2.1.1"><a href="#section-3.3.1" class="xref">3.3.1</a>.  <a href="#name-information-needed-from-oth" class="xref">Information Needed from Other Devices</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.3.2.3.2.2">
                    <p id="section-toc.1-1.3.2.3.2.2.1"><a href="#section-3.3.2" class="xref">3.3.2</a>.  <a href="#name-monitoring-diagnostics-and-" class="xref">Monitoring, Diagnostics, and Reporting</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-autonomic-edge-prefix-manag" class="xref">Autonomic Edge Prefix Management Solution</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-behavior-of-a-device-reques" class="xref">Behavior of a Device Requesting a Prefix</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-behavior-of-a-device-provid" class="xref">Behavior of a Device Providing a Prefix</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-behavior-after-successful-n" class="xref">Behavior after Successful Negotiation</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-prefix-logging" class="xref">Prefix Logging</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-autonomic-prefix-management" class="xref">Autonomic Prefix Management Objectives</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-edge-prefix-objective-optio" class="xref">Edge Prefix Objective Option</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-ipv4-extension" class="xref">IPv4 Extension</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-prefix-management-parameter" class="xref">Prefix Management Parameters</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-example-of-prefix-managemen" class="xref">Example of Prefix Management Parameters</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-deployment-overview" class="xref">Deployment Overview</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-address-and-prefix-manageme" class="xref">Address and Prefix Management with DHCP</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-prefix-management-with-ani-" class="xref">Prefix Management with ANI/GRASP</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The original purpose of this document was to validate the design of the
      Autonomic Networking Infrastructure (ANI) for a realistic use case. It shows
      how the ANI can be applied to IP prefix delegation,
      and it outlines approaches to build a system to do this. A fully
      standardized solution would require more details, so this document
      is informational in nature.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This document defines two autonomic technical objectives for IPv6 prefix
      management in large-scale networks, with an extension to support IPv4 prefixes.
      The background to Autonomic Networking is described in <span>[<a href="#RFC7575" class="xref">RFC7575</a>]</span>
      and <span>[<a href="#RFC7576" class="xref">RFC7576</a>]</span>. The GeneRic Autonomic Signaling Protocol (GRASP) is
      specified by <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span> and can make use of
      the technical objectives to provide a solution for autonomic
      prefix management. An important purpose
      of the present document is to use it for validation of the design of
      GRASP and other components of the ANI as 
      described in <span>[<a href="#RFC8993" class="xref">RFC8993</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">This document is not a complete functional specification of an
      autonomic prefix management system, and it does not describe all
      detailed aspects of the GRASP objective parameters and Autonomic Service
      Agent (ASA) procedures necessary to build a complete system. Instead, it
      describes the architectural framework utilizing the components of the
      ANI, outlines the different
      deployment options and aspects, and defines GRASP objectives for use in
      building the system. It also provides some basic parameter examples.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">This document is not intended to solve all cases of IPv6 prefix
      management. In fact, it assumes that the network's main infrastructure
      elements already have addresses and prefixes. This document is dedicated
      to how to make IPv6 prefix management at the edges of large-scale
      networks as autonomic as possible. It is specifically written for
      Internet Service Provider (ISP) networks. Although there are similarities between
      ISPs and large enterprise networks, the requirements for the two use
      cases differ. In any case, the scope of the solution is expected
      to be limited, like any Autonomic Network, to a single management
      domain.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">However, the solution is designed in a general way. Its use for a
      broader scope than edge prefixes, including some or all infrastructure
      prefixes, is left for future discussion.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">A complete solution has many aspects that are not discussed here.
      Once prefixes have been assigned to routers, they need to be
      communicated to the routing system as they are brought into use. Similarly,
      when prefixes are released, they need to be removed from the routing system.
      Different operators may have different policies regarding prefix lifetimes,
      and they may prefer to have centralized or distributed pools of spare
      prefixes. In an Autonomic Network, these are properties decided upon by the
      design of the relevant ASAs. The GRASP objectives are simply building
      blocks.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">A particular risk of distributed prefix allocation in large networks
      is that over time, it might lead to fragmentation of the address space
      and an undesirable increase in the size of the interior routing protocol tables.
 The extent of this risk depends on the algorithms and policies used by the ASAs.
      Mitigating this risk might even become an autonomic function in itself.<a href="#section-1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="terms">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
       "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>",
       "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>",
       "<span class="bcp14">SHOULD NOT</span>",
       "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
       "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document
       are to be interpreted as described in BCP 14
       <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only
       when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">This document uses terminology defined in <span>[<a href="#RFC7575" class="xref">RFC7575</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="problem">
<section id="section-3">
      <h2 id="name-problem-statement">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-problem-statement" class="section-name selfRef">Problem Statement</a>
      </h2>
<p id="section-3-1">The Autonomic Networking use case considered here is autonomic IPv6
      prefix management at the edge of large-scale ISP networks.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Although DHCPv6-PD (DHCPv6 Prefix Delegation) <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span> supports
      automated delegation of IPv6 prefixes from one router to another, prefix
      management still largely depends on human planning. In other words,
      there is no basic information or policy to support autonomic decisions
      on the prefix length that each router should request or be delegated,
      according to its role in the network. Roles could be defined separately
      for individual devices or
      could be generic (edge router, interior router, etc.). Furthermore, IPv6
      prefix management by humans tends to be rigid and static after initial
      planning.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">The problem to be solved by Autonomic Networking is how to
      dynamically manage IPv6 address space in large-scale networks, so that
      IPv6 addresses can be used efficiently. Here, we limit the problem to
      assignment of prefixes at the edge of the network, close to access
      routers that support individual fixed-line subscribers, mobile
      customers, and corporate customers. We assume that the core
      infrastructure of the network has already been established with
      appropriately assigned prefixes. The Autonomic Networking approach discussed in this
      document is based on the assumption that there is a generic discovery
      and negotiation protocol that enables direct negotiation between
      intelligent IP routers. GRASP <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span> is
      intended to be such a protocol.<a href="#section-3-3" class="pilcrow">¶</a></p>
<div id="experience">
<section id="section-3.1">
        <h3 id="name-intended-user-and-administr">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-intended-user-and-administr" class="section-name selfRef">Intended User and Administrator Experience</a>
        </h3>
<p id="section-3.1-1">The intended experience is, for the administrators of a
        large-scale network, that the management of IPv6 address space at the
        edge of the network can be run with minimum effort, as devices at the
        edge are added and removed and as customers of all kinds join and
        leave the network. In the ideal scenario, the administrators only
        have to specify a single IPv6 prefix for the whole network and the
        initial prefix length for each device role. As far as users are
        concerned, IPv6 prefix assignment would occur exactly as it does in
        any other network.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">The actual prefix usage needs to be logged for potential offline
        management operations, including audit and security incident
        tracing.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="params">
<section id="section-3.2">
        <h3 id="name-analysis-of-parameters-and-">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-analysis-of-parameters-and-" class="section-name selfRef">Analysis of Parameters and Information Involved</a>
        </h3>
<p id="section-3.2-1">For specific purposes of address management, each edge device will implement
        several parameters. (Some of them can be preconfigured
        before they are connected.) They include the following:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-2.1">Identity, authentication, and authorization of this device. This
            is expected to use the Autonomic Networking secure bootstrap
            process <span>[<a href="#RFC8995" class="xref">RFC8995</a>]</span>,
            following which the device could safely take part in autonomic
            operations.<a href="#section-3.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-2.2">Role of this device. Some example roles are discussed in <a href="#exparam" class="xref">Section 6.1</a>.<a href="#section-3.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-2.3">An IPv6 prefix length for this device.<a href="#section-3.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-2.4">An IPv6 prefix that is assigned to this device and its
            downstream devices.<a href="#section-3.2-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.2-3">The network as a whole will implement the following parameters:<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-4.1">Identity of a trust anchor, which is a certification authority
            (CA) maintained by the network administrators, used during the
            secure bootstrap process.<a href="#section-3.2-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-4.2">Total IPv6 address space available for edge devices. It is a pool
            of one or several IPv6 prefixes.<a href="#section-3.2-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-4.3">The initial prefix length for each device role.<a href="#section-3.2-4.3" class="pilcrow">¶</a>
</li>
        </ul>
<div id="device">
<section id="section-3.2.1">
          <h4 id="name-parameters-each-device-can-">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-parameters-each-device-can-" class="section-name selfRef">Parameters Each Device Can Define for Itself</a>
          </h4>
<p id="section-3.2.1-1">This section identifies those of the above parameters that do not
          need external information in order for the devices concerned to set
          them to a reasonable default value after bootstrap or after a network
          disruption. They are as follows:<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.1-2.1">Default role of this device.<a href="#section-3.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-2.2">Default IPv6 prefix length for this device.<a href="#section-3.2.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-2.3">Cryptographic identity of this device, as needed for secure bootstrapping
              <span>[<a href="#RFC8995" class="xref">RFC8995</a>]</span>.<a href="#section-3.2.1-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="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
          by its manufacturer.<a href="#section-3.2.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="opparams">
<section id="section-3.2.2">
          <h4 id="name-information-needed-from-net">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-information-needed-from-net" class="section-name selfRef">Information Needed from Network Operations</a>
          </h4>
<p id="section-3.2.2-1">This section identifies those parameters that might need
          operational input in order for the devices concerned to set them to
          a non-default value.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.2-2.1">Non-default value for the IPv6 prefix length for this device.
              This needs to be decided based on the role of this device.<a href="#section-3.2.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.2-2.2">The initial prefix length for each device role.<a href="#section-3.2.2-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.2-2.3">Whether to allow the device to request more address
              space.<a href="#section-3.2.2-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.2-2.4">The policy regarding when to request more address space -- for example,
              if the address usage reaches a certain limit or percentage.<a href="#section-3.2.2-2.4" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="compare">
<section id="section-3.2.3">
          <h4 id="name-comparison-with-current-sol">
<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-comparison-with-current-sol" class="section-name selfRef">Comparison with Current Solutions</a>
          </h4>
<p id="section-3.2.3-1">This section briefly compares the above use case with current
          solutions. Currently, the address management is still largely
          dependent on human planning. It is rigid and static after initial
          planning. Address requests will fail if the configured address space
          is used up.<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
<p id="section-3.2.3-2">Some autonomic and dynamic address management functions may be
          achievable by extending the existing protocols -- for example,
          extending DHCPv6-PD <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>
          to request IPv6 prefixes according to the device
          role. However, defining uniform device roles may not be a practical 
          task, as some functions cannot be configured on the basis of role using 
          existing prefix delegation protocols.<a href="#section-3.2.3-2" class="pilcrow">¶</a></p>
<p id="section-3.2.3-3">Using a generic autonomic discovery and negotiation protocol
          instead of specific solutions has the advantage that additional
          parameters can be included in the autonomic solution without
          creating new mechanisms. This is the principal argument for a
          generic approach.<a href="#section-3.2.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="interact">
<section id="section-3.3">
        <h3 id="name-interaction-with-other-devi">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-interaction-with-other-devi" class="section-name selfRef">Interaction with Other Devices</a>
        </h3>
<div id="peers">
<section id="section-3.3.1">
          <h4 id="name-information-needed-from-oth">
<a href="#section-3.3.1" class="section-number selfRef">3.3.1. </a><a href="#name-information-needed-from-oth" class="section-name selfRef">Information Needed from Other Devices</a>
          </h4>
<p id="section-3.3.1-1">This section identifies those of the above parameters that need
          external information from neighbor devices (including the upstream
          devices). In many cases, two-way dialogue with neighbor devices is
          needed to set or optimize them.<a href="#section-3.3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.3.1-2.1">Information regarding the identity of a trust anchor is needed.<a href="#section-3.3.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.3.1-2.2">The device will need to discover another device from which it can
              acquire IPv6 address space.<a href="#section-3.3.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.3.1-2.3">Information regarding the initial prefix length for the role of each device is needed, particularly
              for its own downstream devices.<a href="#section-3.3.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.3.1-2.4">The default value of the IPv6 prefix length may be overridden
              by a non-default value.<a href="#section-3.3.1-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.3.1-2.5">The device will need to request and acquire one or more IPv6 prefixes that
              can be assigned to this device and its downstream devices.<a href="#section-3.3.1-2.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.3.1-2.6">The device may respond to prefix delegation requests from its
              downstream devices.<a href="#section-3.3.1-2.6" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.3.1-2.7">The device may require the assignment of more IPv6 address
              space if it used up its assigned IPv6 address space.<a href="#section-3.3.1-2.7" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="monitor">
<section id="section-3.3.2">
          <h4 id="name-monitoring-diagnostics-and-">
<a href="#section-3.3.2" class="section-number selfRef">3.3.2. </a><a href="#name-monitoring-diagnostics-and-" class="section-name selfRef">Monitoring, Diagnostics, and Reporting</a>
          </h4>
<p id="section-3.3.2-1">This section discusses what role devices should play in
          monitoring, fault diagnosis, and reporting.<a href="#section-3.3.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.3.2-2.1">The actual address assignments need to be logged for
              potential offline management operations.<a href="#section-3.3.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.3.2-2.2">In general, the usage situation regarding address space should be
              reported to the network administrators in an abstract way -- for
              example, statistics or a visualized report.<a href="#section-3.3.2-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.3.2-2.3">A forecast of address exhaustion should be reported.<a href="#section-3.3.2-2.3" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
</section>
</div>
<section id="section-4">
      <h2 id="name-autonomic-edge-prefix-manag">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-autonomic-edge-prefix-manag" class="section-name selfRef">Autonomic Edge Prefix Management Solution</a>
      </h2>
<p id="section-4-1">This section introduces the building blocks for
      an autonomic edge prefix management solution.
      As noted in <a href="#intro" class="xref">Section 1</a>, this is not a complete description of
      a solution, which will depend on the detailed design of the relevant
      Autonomic Service Agents (ASAs).
      It uses the generic discovery and negotiation protocol defined
      by <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span>. The relevant GRASP objectives
      are defined in <a href="#prefixNegoOptions" class="xref">Section 5</a>.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-4-2" class="pilcrow">¶</a></p>
<div id="reqbehave">
<section id="section-4.1">
        <h3 id="name-behavior-of-a-device-reques">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-behavior-of-a-device-reques" class="section-name selfRef">Behavior of a Device Requesting a Prefix</a>
        </h3>
<p id="section-4.1-1">If the device containing a PrefixManager ASA has used up its
        address pool, it can request more space according to its requirements.
        It should decide the length of the requested prefix and request it via 
        the mechanism described in <a href="#prefixManageParams" class="xref">Section 6</a>. Note that
        although the device's role may define certain default allocation lengths,
        those defaults might be changed dynamically, and
        the device might request more, or less, address space due to
        some local operational heuristic.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">A PrefixManager ASA that needs additional address space should
        firstly discover peers that may be able to provide extra address
        space. The ASA should send out a GRASP Discovery message that contains
        a PrefixManager Objective option (see <span><a href="https://www.rfc-editor.org/rfc/figure-1" class="relref">Section 2</a> of [<a href="#RFC8650" class="xref">RFC8650</a>]</span> and <a href="#prefixObjOption" class="xref">Section 5.1</a>) in
        order to discover peers also supporting that option. Then, it should
        choose one such peer, most likely the first to respond.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">If the GRASP Discovery Response message carries a Divert option
        pointing to an off-link PrefixManager ASA, the requesting ASA may
        initiate negotiation with that ASA-diverted device to find out whether
        it can provide the requested length of the prefix.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">In any case, the requesting ASA will act as a GRASP negotiation
        initiator by sending a GRASP Request message with a PrefixManager
        Objective option. The ASA indicates in this option the length of
        the requested prefix.
        This starts a GRASP negotiation process.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">During the subsequent negotiation, the ASA will decide at each step
        whether to accept the offered prefix. That decision, and the decision
        to end the negotiation, are implementation choices.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">The ASA could alternatively initiate GRASP discovery in rapid mode 
        with an embedded negotiation request, if it is implemented.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.2">
        <h3 id="name-behavior-of-a-device-provid">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-behavior-of-a-device-provid" class="section-name selfRef">Behavior of a Device Providing a Prefix</a>
        </h3>
<p id="section-4.2-1">At least one device on the network must be configured with
        the initial pool of available prefixes mentioned in <a href="#params" class="xref">Section 3.2</a>. 
        Apart from that requirement, any device may act as a provider of prefixes.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">A device that receives a Discovery message with a PrefixManager
        Objective option should respond with a GRASP Response message if it
        contains a PrefixManager ASA. Further details of the discovery
        process are described in <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span>. When
        this ASA receives a subsequent Request message, it should conduct a
        GRASP negotiation sequence, using Negotiate, Confirm Waiting, and
        Negotiation End messages as appropriate. The Negotiate messages
        carry a PrefixManager Objective option, 
        which will indicate the prefix and its length offered to the requesting ASA. As
        described in <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span>, negotiation will
        continue until either end stops it with a Negotiation End message.
        If the negotiation succeeds, the ASA that provides the prefix will remove the
        negotiated prefix from its pool, and the requesting ASA will add it.
        If the negotiation fails, the party sending the Negotiation End
        message may include an error code string.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">During the negotiation, the ASA will decide at each step how large
        a prefix to offer. That decision, and the decision to end the negotiation,
        are implementation choices.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">The ASA could alternatively negotiate in response to GRASP discovery in  rapid mode, if it is implemented.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">This specification is independent of whether the PrefixManager ASAs
        are all embedded in routers, but that would be a rather natural
        scenario. In a hierarchical network topology, a given router typically
        provides prefixes for routers below it in the hierarchy, and it is
        also likely to contain the first PrefixManager ASA discovered by those downstream
        routers. However, the GRASP discovery model, including its redirection
        feature, means that this is not an exclusive scenario, and a
        downstream PrefixManager ASA could negotiate a new prefix with a
        device other than its upstream router.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<p id="section-4.2-6">A resource shortage may cause the gateway router to request more
        resources in turn from its own upstream device. This would be another
        independent GRASP discovery and negotiation process. During the
        processing time, the gateway router should send a Confirm Waiting
        message to the initial requesting router, to extend its timeout. When
        the new resource becomes available, the gateway router responds with a
        GRASP Negotiate message with a prefix length matching the request.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
<p id="section-4.2-7">The algorithm used to choose which prefixes to assign on the devices that
        provide prefixes is an implementation choice.<a href="#section-4.2-7" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3">
        <h3 id="name-behavior-after-successful-n">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-behavior-after-successful-n" class="section-name selfRef">Behavior after Successful Negotiation</a>
        </h3>
<p id="section-4.3-1">Upon receiving a GRASP Negotiation End message that indicates
        that an acceptable prefix length is available, the requesting device
        may use the negotiated prefix without further messages.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">There are use cases where the ANI/GRASP-based prefix
        management approach can work together with DHCPv6-PD <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>
        as a complement. For example, the ANI/GRASP-based
        method can be used intra-domain, while the DHCPv6-PD method works inter-domain
        (i.e., across an administrative boundary). Also, ANI/GRASP can be used
        inside the domain, and DHCP/DHCPv6-PD can be used on the edge of the
        domain to clients (non-ANI devices). Another similar use case would be
        ANI/GRASP inside the domain, with
        RADIUS <span>[<a href="#RFC2865" class="xref">RFC2865</a>]</span> providing prefixes to client devices.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4">
        <h3 id="name-prefix-logging">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-prefix-logging" class="section-name selfRef">Prefix Logging</a>
        </h3>
<p id="section-4.4-1">Within the autonomic prefix management system, all prefix assignments are
        done by devices without human intervention. It may be required
        that all prefix assignment history be recorded -- for example, to detect
        or trace lost prefixes after outages or to meet legal requirements.
        However, the logging and reporting process is out of scope for this
        document.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
</section>
</section>
<div id="prefixNegoOptions">
<section id="section-5">
      <h2 id="name-autonomic-prefix-management">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-autonomic-prefix-management" class="section-name selfRef">Autonomic Prefix Management Objectives</a>
      </h2>
<p id="section-5-1">This section defines the GRASP technical objective options that are used to support
      autonomic prefix management.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="prefixObjOption">
<section id="section-5.1">
        <h3 id="name-edge-prefix-objective-optio">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-edge-prefix-objective-optio" class="section-name selfRef">Edge Prefix Objective Option</a>
        </h3>
<p id="section-5.1-1">The PrefixManager Objective option is a GRASP Objective option
        conforming to the GRASP specification <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span>. Its name is
        "PrefixManager" (see <a href="#iana" class="xref">Section 8</a>), and it carries the following
        data items as its value: the prefix length and
        the actual prefix bits. Since GRASP is based on CBOR (Concise Binary Object Representation)
        <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span>, the format of the PrefixManager Objective
        option is described in the Concise Data Definition Language (CDDL)
        <span>[<a href="#RFC8610" class="xref">RFC8610</a>]</span> as follows:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<div id="section-5.1-2">
<pre class="sourcecode lang-cddl">
  objective = ["PrefixManager", objective-flags, loop-count,
               [length, ?prefix]]

  loop-count = 0..255         ; as in the GRASP specification
  objective-flags /=          ; as in the GRASP specification
  length = 0..128             ; requested or offered prefix length
  prefix = bytes .size 16     ; offered prefix in binary format
</pre><a href="#section-5.1-2" class="pilcrow">¶</a>
</div>
<p id="section-5.1-3">The use of the "dry run" mode of GRASP is <span class="bcp14">NOT RECOMMENDED</span> for this objective, because it
        would require both ASAs to store state information about the corresponding negotiation, to no real
        benefit -- the requesting ASA cannot base any decisions on the result of a successful
        dry-run negotiation.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ipv4">
<section id="section-5.2">
        <h3 id="name-ipv4-extension">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-ipv4-extension" class="section-name selfRef">IPv4 Extension</a>
        </h3>
<p id="section-5.2-1">This section presents an extended version of the
      PrefixManager objective that supports IPv4 by adding an extra flag:<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<div id="section-5.2-2">
<pre class="sourcecode lang-cddl">
  objective = ["PrefixManager", objective-flags, loop-count, prefval]

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

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

  prefval /= pref4val
  pref4val = [version4, length4, ?prefix4]
  version4 = 4
  length4 = 0..32             ; requested or offered prefix length
  prefix4 = bytes .size 4     ; offered prefix in binary format
</pre><a href="#section-5.2-2" class="pilcrow">¶</a>
</div>
<p id="section-5.2-3">Prefix and address management for IPv4 is considerably more difficult
        than for IPv6, due to the prevalence of NAT, ambiguous addresses <span>[<a href="#RFC1918" class="xref">RFC1918</a>]</span>,
        and address sharing <span>[<a href="#RFC6346" class="xref">RFC6346</a>]</span>. These complexities might require further extending
        the objective with additional fields that are not defined by this document.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="prefixManageParams">
<section id="section-6">
      <h2 id="name-prefix-management-parameter">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-prefix-management-parameter" class="section-name selfRef">Prefix Management Parameters</a>
      </h2>
<p id="section-6-1">An implementation of a prefix manager <span class="bcp14">MUST</span> include default settings
      of all necessary parameters. However, within a single administrative
      domain, the network operator <span class="bcp14">MAY</span> change default parameters for all
      devices with a certain role. Thus, it would be possible to apply an
      intended policy for every device in a simple way, without traditional
      configuration files. As noted in <a href="#reqbehave" class="xref">Section 4.1</a>, individual
      autonomic devices may also change their own behavior dynamically.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">For example, the network operator could change the default prefix
      length for each type of role. A prefix management parameters objective,
      which contains mapping information of device roles and their default
      prefix lengths, <span class="bcp14">MAY</span> be flooded in the network, through the Autonomic
      Control Plane (ACP) <span>[<a href="#RFC8994" class="xref">RFC8994</a>]</span>.
      The objective is defined in CDDL as follows:<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="section-6-3">
<pre class="sourcecode lang-cddl">
  objective = ["PrefixManager.Params", objective-flags, any]

  loop-count = 0..255         ; as in the GRASP specification
  objective-flags /=          ; as in the GRASP specification
</pre><a href="#section-6-3" class="pilcrow">¶</a>
</div>
<p id="section-6-4">The "any" object would be the relevant parameter definitions (such as
      the example below) transmitted as a CBOR object in an appropriate
      format.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">This could be flooded to all nodes, and any PrefixManager ASA that
      did not receive it for some reason could obtain a copy using GRASP
      unicast synchronization. Upon receiving the prefix management
      parameters, every device can decide its default prefix length by
      matching its own role.<a href="#section-6-5" class="pilcrow">¶</a></p>
<div id="exparam">
<section id="section-6.1">
        <h3 id="name-example-of-prefix-managemen">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-example-of-prefix-managemen" class="section-name selfRef">Example of Prefix Management Parameters</a>
        </h3>
<p id="section-6.1-1">The parameters comprise mapping information of device roles and
        their default prefix lengths in an autonomic domain. For example,
        suppose an IPRAN (IP Radio Access Network) operator wants to configure
        the prefix length of a Radio Network Controller Site Gateway (RSG) as 34, the prefix length
        of an Aggregation Site Gateway (ASG) as 44, and the prefix length of a Cell
        Site Gateway (CSG) as 56. This could be described in the value of the
        PrefixManager.Params objective as:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<div id="section-6.1-2">
<pre class="sourcecode lang-json">
[
   [["role", "RSG"],["prefix_length", 34]],
   [["role", "ASG"],["prefix_length", 44]],
   [["role", "CSG"],["prefix_length", 56]]
]
</pre><a href="#section-6.1-2" class="pilcrow">¶</a>
</div>
<p id="section-6.1-3">This example is expressed in JSON <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>, which is easy to represent in CBOR.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">An alternative would be to express the parameters in YANG <span>[<a href="#RFC7950" class="xref">RFC7950</a>]</span> using the YANG-to-CBOR mapping <span>[<a href="#CORE-YANG-CBOR" class="xref">CORE-YANG-CBOR</a>]</span>.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">For clarity, the background of the example is introduced below
        and can also be regarded as a use case for the mechanism defined in
        this document.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<p id="section-6.1-6">An IPRAN is used for mobile backhaul, including radio
        stations, RNCs (Radio Network Controllers) (in 3G) or the packet core (in LTE), and the IP network
        between them, as shown in <a href="#IPRAN-topology" class="xref">Figure 1</a>. The eNB (Evolved Node B) entities, the RNC, the SGW (Serving Gateway), and the MME (Mobility
        Management Entity) are mobile network entities defined in 3GPP. The
        CSGs, ASGs, and RSGs are entities defined in the IPRAN solution.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
<p id="section-6.1-7">The IPRAN topology shown in <a href="#IPRAN-topology" class="xref">Figure 1</a>
        includes Ring1, which is the
        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,
        and normally the network is highly dependent on human design and
        configuration, which is neither flexible nor cost-effective.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
<span id="name-ipran-topology-example"></span><div id="IPRAN-topology">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-6.1-8.1">
<pre>
+------+   +------+
| eNB1 |---| CSG1 |\
+------+   +------+  \   +-------+       +------+           +-------+
               |       \ |  ASG1 |-------| RSG1 |-----------|SGW/MME|
               |  Ring2  +-------+       +------+ \        /+-------+
+------+   +------+     /     |              |      \    /
| eNB2 |---| CSG2 | \  /      |      Ring1   |        \/
+------+   +------+   \  Ring3|              |        /\
                     / \      |              |      /   \
+------+   +------+ /    \ +-------+      +------+/       \+-------+
| eNB3 |---| CSG3 |--------|  ASG2 |------| RSG2 |---------|  RNC  |
+------+   +------+        +-------+      +------+         +-------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-ipran-topology-example" class="selfRef">IPRAN Topology Example</a>
          </figcaption></figure>
</div>
<p id="section-6.1-9">If ANI/GRASP is supported in the IPRAN, the network nodes
        should be able to negotiate with each other and make some autonomic
        decisions according to their own status and the information
        collected from the network. The prefix management parameters should be
        part of the information they communicate.<a href="#section-6.1-9" class="pilcrow">¶</a></p>
<p id="section-6.1-10">The routers should know the role of their neighbors, the default
        prefix length for each type of role, etc. An ASG should be able to
        request prefixes from an RSG, and a CSG should be able to request prefixes from
        an ASG. In each request, the ASG/CSG should indicate the required prefix length, or its role,
        which implies what length it needs by default.<a href="#section-6.1-10" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="security">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">Relevant security issues are discussed in <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span>. The preferred security model is that
      devices are trusted following the secure bootstrap procedure <span>[<a href="#RFC8995" class="xref">RFC8995</a>]</span> and that a secure
      Autonomic Control Plane (ACP) <span>[<a href="#RFC8994" class="xref">RFC8994</a>]</span> is in place.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">It is <span class="bcp14">RECOMMENDED</span> that DHCPv6-PD, if used, should be implemented using
      DHCPv6 authentication or Secure DHCPv6.<a href="#section-7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">This document defines two new GRASP Objective option names:
      "PrefixManager" and "PrefixManager.Params". The IANA has added
      these to the "GRASP Objective Names" registry defined by <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span>.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7950">[RFC7950]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refTitle">"The YANG 1.1 Data Modeling Language"</span>, <span class="seriesInfo">RFC 7950</span>, <span class="seriesInfo">DOI 10.17487/RFC7950</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7950">https://www.rfc-editor.org/info/rfc7950</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8259">[RFC8259]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8415">[RFC8415]</dt>
        <dd>
<span class="refAuthor">Mrugalski, T.</span>, <span class="refAuthor">Siodelski, M.</span>, <span class="refAuthor">Volz, B.</span>, <span class="refAuthor">Yourtchenko, A.</span>, <span class="refAuthor">Richardson, M.</span>, <span class="refAuthor">Jiang, S.</span>, <span class="refAuthor">Lemon, T.</span>, and <span class="refAuthor">T. Winters</span>, <span class="refTitle">"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"</span>, <span class="seriesInfo">RFC 8415</span>, <span class="seriesInfo">DOI 10.17487/RFC8415</span>, <time datetime="2018-11" class="refDate">November 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8415">https://www.rfc-editor.org/info/rfc8415</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8610">[RFC8610]</dt>
        <dd>
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Vigano, C.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures"</span>, <span class="seriesInfo">RFC 8610</span>, <span class="seriesInfo">DOI 10.17487/RFC8610</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8610">https://www.rfc-editor.org/info/rfc8610</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8990">[RFC8990]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refAuthor">Carpenter, B., Ed.</span>, and <span class="refAuthor">B. Liu, Ed.</span>, <span class="refTitle">"GeneRic Autonomic Signaling Protocol (GRASP)"</span>, <span class="seriesInfo">RFC 8990</span>, <span class="seriesInfo">DOI 10.17487/RFC8990</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8990">https://www.rfc-editor.org/info/rfc8990</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8994">[RFC8994]</dt>
        <dd>
<span class="refAuthor">Eckert, T., Ed.</span>, <span class="refAuthor">Behringer, M., Ed.</span>, and <span class="refAuthor">S. Bjarnason</span>, <span class="refTitle">"An Autonomic Control Plane (ACP)"</span>, <span class="seriesInfo">RFC 8994</span>, <span class="seriesInfo">DOI 10.17487/RFC8994</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8994">https://www.rfc-editor.org/info/rfc8994</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8995">[RFC8995]</dt>
      <dd>
<span class="refAuthor">Pritikin, M.</span>, <span class="refAuthor">Richardson, M.</span>, <span class="refAuthor">Eckert, T.</span>, <span class="refAuthor">Behringer, M.</span>, and <span class="refAuthor">K. Watsen</span>, <span class="refTitle">"Bootstrapping Remote Secure Key Infrastructure (BRSKI)"</span>, <span class="seriesInfo">RFC 8995</span>, <span class="seriesInfo">DOI 10.17487/RFC8995</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8995">https://www.rfc-editor.org/info/rfc8995</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="CORE-YANG-CBOR">[CORE-YANG-CBOR]</dt>
        <dd>
<span class="refAuthor">Veillette, M., Ed.</span>, <span class="refAuthor">Petrov, I., Ed.</span>, and <span class="refAuthor">A. Pelov</span>, <span class="refTitle">"CBOR Encoding of Data Modeled with YANG"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-core-yang-cbor-15</span>, <time datetime="2021-01-24" class="refDate">24 January 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-core-yang-cbor-15">https://tools.ietf.org/html/draft-ietf-core-yang-cbor-15</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DHCP-YANG-MODEL">[DHCP-YANG-MODEL]</dt>
        <dd>
<span class="refAuthor">Liu, B., Ed.</span>, <span class="refAuthor">Lou, K.</span>, and <span class="refAuthor">C. Chen</span>, <span class="refTitle">"Yang Data Model for DHCP Protocol"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-liu-dhc-dhcp-yang-model-07</span>, <time datetime="2018-10-12" class="refDate">12 October 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-07">https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-07</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1918">[RFC1918]</dt>
        <dd>
<span class="refAuthor">Rekhter, Y.</span>, <span class="refAuthor">Moskowitz, B.</span>, <span class="refAuthor">Karrenberg, D.</span>, <span class="refAuthor">de Groot, G. J.</span>, and <span class="refAuthor">E. Lear</span>, <span class="refTitle">"Address Allocation for Private Internets"</span>, <span class="seriesInfo">BCP 5</span>, <span class="seriesInfo">RFC 1918</span>, <span class="seriesInfo">DOI 10.17487/RFC1918</span>, <time datetime="1996-02" class="refDate">February 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1918">https://www.rfc-editor.org/info/rfc1918</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2865">[RFC2865]</dt>
        <dd>
<span class="refAuthor">Rigney, C.</span>, <span class="refAuthor">Willens, S.</span>, <span class="refAuthor">Rubens, A.</span>, and <span class="refAuthor">W. Simpson</span>, <span class="refTitle">"Remote Authentication Dial In User Service (RADIUS)"</span>, <span class="seriesInfo">RFC 2865</span>, <span class="seriesInfo">DOI 10.17487/RFC2865</span>, <time datetime="2000-06" class="refDate">June 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2865">https://www.rfc-editor.org/info/rfc2865</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3046">[RFC3046]</dt>
        <dd>
<span class="refAuthor">Patrick, M.</span>, <span class="refTitle">"DHCP Relay Agent Information Option"</span>, <span class="seriesInfo">RFC 3046</span>, <span class="seriesInfo">DOI 10.17487/RFC3046</span>, <time datetime="2001-01" class="refDate">January 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3046">https://www.rfc-editor.org/info/rfc3046</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6221">[RFC6221]</dt>
        <dd>
<span class="refAuthor">Miles, D., Ed.</span>, <span class="refAuthor">Ooghe, S.</span>, <span class="refAuthor">Dec, W.</span>, <span class="refAuthor">Krishnan, S.</span>, and <span class="refAuthor">A. Kavanagh</span>, <span class="refTitle">"Lightweight DHCPv6 Relay Agent"</span>, <span class="seriesInfo">RFC 6221</span>, <span class="seriesInfo">DOI 10.17487/RFC6221</span>, <time datetime="2011-05" class="refDate">May 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6221">https://www.rfc-editor.org/info/rfc6221</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6346">[RFC6346]</dt>
        <dd>
<span class="refAuthor">Bush, R., Ed.</span>, <span class="refTitle">"The Address plus Port (A+P) Approach to the IPv4 Address Shortage"</span>, <span class="seriesInfo">RFC 6346</span>, <span class="seriesInfo">DOI 10.17487/RFC6346</span>, <time datetime="2011-08" class="refDate">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6346">https://www.rfc-editor.org/info/rfc6346</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7575">[RFC7575]</dt>
        <dd>
<span class="refAuthor">Behringer, M.</span>, <span class="refAuthor">Pritikin, M.</span>, <span class="refAuthor">Bjarnason, S.</span>, <span class="refAuthor">Clemm, A.</span>, <span class="refAuthor">Carpenter, B.</span>, <span class="refAuthor">Jiang, S.</span>, and <span class="refAuthor">L. Ciavaglia</span>, <span class="refTitle">"Autonomic Networking: Definitions and Design Goals"</span>, <span class="seriesInfo">RFC 7575</span>, <span class="seriesInfo">DOI 10.17487/RFC7575</span>, <time datetime="2015-06" class="refDate">June 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7575">https://www.rfc-editor.org/info/rfc7575</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7576">[RFC7576]</dt>
        <dd>
<span class="refAuthor">Jiang, S.</span>, <span class="refAuthor">Carpenter, B.</span>, and <span class="refAuthor">M. Behringer</span>, <span class="refTitle">"General Gap Analysis for Autonomic Networking"</span>, <span class="seriesInfo">RFC 7576</span>, <span class="seriesInfo">DOI 10.17487/RFC7576</span>, <time datetime="2015-06" class="refDate">June 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7576">https://www.rfc-editor.org/info/rfc7576</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8650">[RFC8650]</dt>
        <dd>
<span class="refAuthor">Voit, E.</span>, <span class="refAuthor">Rahman, R.</span>, <span class="refAuthor">Nilsen-Nygaard, E.</span>, <span class="refAuthor">Clemm, A.</span>, and <span class="refAuthor">A. Bierman</span>, <span class="refTitle">"Dynamic Subscription to YANG Events and Datastores over RESTCONF"</span>, <span class="seriesInfo">RFC 8650</span>, <span class="seriesInfo">DOI 10.17487/RFC8650</span>, <time datetime="2019-11" class="refDate">November 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8650">https://www.rfc-editor.org/info/rfc8650</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8949">[RFC8949]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">P. Hoffman</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">STD 94</span>, <span class="seriesInfo">RFC 8949</span>, <span class="seriesInfo">DOI 10.17487/RFC8949</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8949">https://www.rfc-editor.org/info/rfc8949</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8993">[RFC8993]</dt>
      <dd>
<span class="refAuthor">Behringer, M., Ed.</span>, <span class="refAuthor">Carpenter, B.</span>, <span class="refAuthor">Eckert, T.</span>, <span class="refAuthor">Ciavaglia, L.</span>, and <span class="refAuthor">J. Nobre</span>, <span class="refTitle">"A Reference Model for Autonomic Networking"</span>, <span class="seriesInfo">RFC 8993</span>, <span class="seriesInfo">DOI 10.17487/RFC8993</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8993">https://www.rfc-editor.org/info/rfc8993</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-deployment-overview">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-deployment-overview" class="section-name selfRef">Deployment Overview</a>
      </h2>
<p id="section-appendix.a-1">This appendix includes logical deployment models and explanations of
      the target deployment models. Its purpose is to help in understanding
      the mechanism described in this document.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">This appendix includes two subsections: 
      <a href="#app-a1" class="xref">Appendix A.1</a> for the two most common
      DHCP deployment models and <a href="#app-a2" class="xref">Appendix A.2</a> for the PD deployment model described in this document. It
      should be noted that these are just examples, and there are many more
      deployment models.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<div id="app-a1">
<section id="section-a.1">
        <h2 id="name-address-and-prefix-manageme">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-address-and-prefix-manageme" class="section-name selfRef">Address and Prefix Management with DHCP</a>
        </h2>
<p id="section-a.1-1">Edge DHCP server deployment requires every edge router connecting
        to a Customer Premises Equipment (CPE) device to be a DHCP server assigning IPv4/IPv6 addresses to CPEs -- and,
        optionally, IPv6 prefixes via DHCPv6-PD for IPv6-capable CPEs that are
        routers and have LANs behind them.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
<span id="name-dhcp-deployment-model-witho"></span><div id="fig2">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-a.1-2.1">
<pre>
                                             edge
        dynamic, "NETCONF/YANG"            interfaces
         &lt;---------------&gt; +-------------+
+------+    &lt;- telemetry   | edge router/|-+  -----  +-----+
|config|  .... domain ...  | DHCP server | |  ...    | CPE |+  LANs
|server|                   +-------------+ |  -----  +-----+| (---| )
+------+                    +--------------+  DHCP/   +-----+
                                             DHCPv6-PD
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-dhcp-deployment-model-witho" class="selfRef">DHCP Deployment Model without a Central DHCP Server</a>
          </figcaption></figure>
</div>
<p id="section-a.1-3">This requires various coordination functions via some backend
        system (depicted as the "config server" in <a href="#fig2" class="xref">Figure 2</a>): the address prefixes on the edge
        interfaces should be slightly larger than required for the number of
        CPEs connected so that the overall address space is best used.<a href="#section-a.1-3" class="pilcrow">¶</a></p>
<p id="section-a.1-4">The config server needs to provision edge interface address
        prefixes and DHCP parameters for every edge router. If prefixes that are too fine-grained are used, this will result in large routing tables
        across the domain shown in the figure. If prefixes that are too coarse-grained are used, address
        space is wasted. (This is less of a concern for IPv6, but if the
        model includes IPv4, it is a very serious concern.)<a href="#section-a.1-4" class="pilcrow">¶</a></p>
<p id="section-a.1-5">There is no standard that describes algorithms for how configuration servers
        would best perform this ongoing dynamic provisioning to optimize
        routing table size and address space utilization.<a href="#section-a.1-5" class="pilcrow">¶</a></p>
<p id="section-a.1-6">There are currently no complete YANG data models that a config server
        could use to perform these actions (including telemetry of assigned
        addresses from such distributed DHCP servers). For example, a YANG data model for controlling DHCP server operations is
        still being developed <span>[<a href="#DHCP-YANG-MODEL" class="xref">DHCP-YANG-MODEL</a>]</span>.<a href="#section-a.1-6" class="pilcrow">¶</a></p>
<p id="section-a.1-7">Due to these and other problems related to the above model, the more common
        DHCP deployment model is as follows:<a href="#section-a.1-7" class="pilcrow">¶</a></p>
<span id="name-dhcp-deployment-model-with-"></span><figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-a.1-8.1">
<pre>
+------+                                      edge
|config|    initial, "CLI"                   interfaces
|server| ----------------&gt; +-------------+
+------+                   | edge router/|-+  -----  +-----+
   |     .... domain ...   | DHCP relay  | |  ...    | CPE |+  LANs
+------+                   +-------------+ |  -----  +-----+| (---| )
|DHCP  |                    +--------------+  DHCP/   +-----+
|server|                                     DHCPv6-PD
+------+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-dhcp-deployment-model-with-" class="selfRef">DHCP Deployment Model with a Central DHCP Server</a>
          </figcaption></figure>
<p id="section-a.1-9">Dynamic provisioning changes to edge routers are avoided by using a
        central DHCP server and reducing the edge router from DHCP server to
        DHCP relay. The "configuration" on the edge routers is static. The
        DHCP relay function inserts an "edge interface" and/or
        subscriber-identifying options into DHCP requests from CPEs (e.g., <span>[<a href="#RFC3046" class="xref">RFC3046</a>]</span> <span>[<a href="#RFC6221" class="xref">RFC6221</a>]</span>), and the DHCP server has
        complete policies for address assignments and prefixes usable on
        every edge router / interface / subscriber group. When the DHCP relay sees
        the DHCP reply, it inserts static routes for the assigned
        address / address prefix into the routing table of the edge router; these routes
        are then to be distributed by the IGP (or BGP) inside the domain to
        make the CPE and LANs reachable across the domain shown in the figure.<a href="#section-a.1-9" class="pilcrow">¶</a></p>
<p id="section-a.1-10">There is no comprehensive standardization of these solutions. For example, <span>[<a href="#RFC8415" class="xref">RFC8415</a>], <a href="https://www.rfc-editor.org/rfc/rfc8415#section-19.1.3" class="relref">Section 19.1.3</a></span> simply
        refers to "a [non-defined] protocol or other out-of-band communication to
        configure routing information for delegated prefixes on any router
        through which the client may forward traffic."<a href="#section-a.1-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="app-a2">
<section id="section-a.2">
        <h2 id="name-prefix-management-with-ani-">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-prefix-management-with-ani-" class="section-name selfRef">Prefix Management with ANI/GRASP</a>
        </h2>
<p id="section-a.2-1">Using the ANI and prefix management ASAs (PM-ASAs) using GRASP, the deployment
model is intended to look as follows:<a href="#section-a.2-1" class="pilcrow">¶</a></p>
<span id="name-deployment-model-using-ani-"></span><div id="fig4">
<figure id="figure-4">
          <div class="artwork art-text alignLeft" id="section-a.2-2.1">
<pre>
|&lt;............ ANI domain / ACP............&gt;| (...) ........-&gt;

                                   Roles
                                     |
                                     v   "Edge routers"
GRASP parameter               +----------+
 Network-wide                 |  PM-ASA  | downstream
parameters/policies           |  (DHCP   | interfaces
     |                        |functions)| ------
     v  "central device"      +----------+
+------+                            ^             +--------+
|PM-ASA|      &lt;............GRASP ....      ....   |  CPE   |-+ (LANs)
+------+             .              v             |(PM-ASA)| |  ---|
     .           +........+   +----------+        +--------+ |
+...........+    . PM-ASA .   |  PM-ASA  | ------  +---------+
.DHCP server.    +........+   |  (DHCP   | SLAAC/
+...........+  "intermediate  |functions)| DHCP/DHCP-PD
                  router"     +----------+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-deployment-model-using-ani-" class="selfRef">Deployment Model Using ANI/GRASP</a>
          </figcaption></figure>
</div>
<p id="section-a.2-3">The network runs an ANI domain with an ACP <span>[<a href="#RFC8994" class="xref">RFC8994</a>]</span> between some central
        device (e.g., a router or an ANI-enabled management device) and the edge
        routers. ANI/ACP provides a secure, zero-touch communication channel
        between the devices and enables the use of GRASP <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span> not only for peer-to-peer communication 
        but also for distribution/flooding.<a href="#section-a.2-3" class="pilcrow">¶</a></p>
<p id="section-a.2-4">The central devices and edge routers run software 
        in the form of ASAs to support this document's autonomic IPv6 edge prefix management. PM-ASAs as discussed below
        together comprise the Autonomic Prefix Management Function.<a href="#section-a.2-4" class="pilcrow">¶</a></p>
<p id="section-a.2-5">Edge routers can have different roles based on the type and number
        of CPEs attaching to them. Each edge router could be an RSG, ASG, or CSG
        in mobile aggregation networks (see <a href="#exparam" class="xref">Section 6.1</a>). Mechanisms outside
        the scope of this document make routers aware of their roles.<a href="#section-a.2-5" class="pilcrow">¶</a></p>
<p id="section-a.2-6">Some considerations related to the deployment model are 
        as follows.<a href="#section-a.2-6" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-a.2-7">
        <li id="section-a.2-7.1">
            <p id="section-a.2-7.1.1">In a minimum prefix management solution, the central device uses
        the PrefixManager.Params GRASP objective introduced in this document
        to disseminate network-wide, per-role parameters to edge routers. The
        PM-ASA uses the parameters that apply to its own role to locally
        configure preexisting addressing functions. Because the PM-ASA does
        not manage the dynamic assignment of actual IPv6 address prefixes in
        this case, the following options can be considered:<a href="#section-a.2-7.1.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-a.2-7.1.2">
        <dt>1.a</dt>
<dd id="section-a.2-7.1.2.1">The edge router connects via downstream interfaces to each (host)
        CPE that requires an address. The PM-ASA sets up for each such
        interface a DHCP requesting router (according to <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>)
        to request an IPv6 prefix for the interface. The
        router's address on the downstream interface can be another parameter
        from the GRASP objective. The CPEs assign addresses in the prefix via
        Router Advertisements (RAs), or the PM‑ASA manages a local DHCPv6 server to
        assign addresses to the CPEs. A central DHCP server acting as the DHCP
        delegating router (according to <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>) is required.
        Its address can be another parameter from the GRASP objective.<a href="#section-a.2-7.1.2.1" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt>1.b</dt>
<dd id="section-a.2-7.1.2.2">The edge router also connects via downstream interfaces to
        (customer managed) CPEs that are routers and act as DHCPv6 requesting
        routers. The need to support this could be derived from role or
        GRASP parameters, and the PM‑ASA sets up a DHCP relay function to pass
        on requests to the central DHCP server as in point 1.a.<a href="#section-a.2-7.1.2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</li>
          <li id="section-a.2-7.2">
            <p id="section-a.2-7.2.1">In a solution without a central DHCP server, the PM-ASA on the
        edge routers not only learns parameters from PrefixManager.Params
        but also utilizes GRASP to request/negotiate actual IPv6 prefix
        delegation via the GRASP PrefixManager objective, as described in more
        detail below. In the simplest case, these prefixes are delegated
        via this GRASP objective from the PM-ASA in the central device.
        This device must be provisioned initially with a large pool of
        prefixes. The delegated
        prefixes are then used by the PM-ASA on the edge routers to configure prefixes on their downstream interfaces to assign
        addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local
        DHCP servers (as in point 1.a) to assign addresses via DHCP to the CPEs from the
        prefixes it received. This includes both host CPEs requesting IPv6
        addresses and router CPEs that request IPv6 prefixes. The
        PM-ASA needs to manage the address pool(s) it has requested via GRASP
        and allocate sub-address pools to interfaces and the local DHCP
        servers it starts. It needs to monitor the address utilization and
        accordingly request more address prefixes if its existing prefixes are
        exhausted, or return address prefixes when they are unneeded.<a href="#section-a.2-7.2.1" class="pilcrow">¶</a></p>
<p id="section-a.2-7.2.2">This solution is quite similar to the previous IPv6 DHCP
        deployment model without a central DHCP server, and ANI/ACP/GRASP and
        the PM-ASA do provide the automation to make this approach work more
        easily than is possible today.<a href="#section-a.2-7.2.2" class="pilcrow">¶</a></p>
</li>
          <li id="section-a.2-7.3">The address pools from which prefixes are allocated do not all
        need to be taken from one central location. An edge-router PM‑ASA
        that received a big (short) prefix from a central PM-ASA could offer
        smaller sub-prefixes to a neighboring edge-router PM‑ASA. GRASP could be
        used in such a way that the PM-ASA would find and select the objective
        from the closest neighboring PM‑ASA, therefore allowing aggregation to be maximized: a PM‑ASA would only request further smaller 
        prefixes when it exhausts its own pool (from the central location) and
        cannot get further large prefixes from that central location anymore.
        Because the overflow prefixes taken from a topologically nearby PM‑ASA,
        the number of longer prefixes that have to be injected into the
        routing tables is limited and the topological proximity increases the
        chances that aggregation of prefixes in the IGP can most likely limit
        the geography in which the longer prefixes need to be routed.<a href="#section-a.2-7.3" class="pilcrow">¶</a>
</li>
          <li id="section-a.2-7.4">Instead of peer-to-peer optimization of prefix delegation, a
        hierarchy of PM-ASAs can be built (indicated in <a href="#fig4" class="xref">Figure 4</a> via a
        dotted intermediate router). This would require additional parameters
        in the PrefixManager objective to allow the creation of a hierarchy of
        PM-ASAs across which the prefixes can be delegated.<a href="#section-a.2-7.4" class="pilcrow">¶</a>
</li>
          <li id="section-a.2-7.5">In cases where CPEs are also part of the ANI domain (e.g.,
        "managed CPEs"), then GRASP will extend into the actual customer sites
        and can also run a PM-ASA. All the options described in points 1 to
        4 above would then apply to the CPE as the edge router, with the major
        changes being that (a) a CPE router will most likely not need to run
        DHCPv6-PD itself, but only DHCP address assignment and (b) the edge
        routers to which the CPE connects would most likely become ideal places
        on which to run a hierarchical instance of PD-ASAs, as outlined in
        point 1.<a href="#section-a.2-7.5" class="pilcrow">¶</a>
</li>
        </ol>
</section>
</div>
</section>
<div id="ack">
<section id="section-appendix.b">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.b-1">Valuable comments were received from
      <span class="contact-name">William Atwood</span>,
      <span class="contact-name">Fred Baker</span>,
      <span class="contact-name">Michael Behringer</span>,
      <span class="contact-name">Ben Campbell</span>,
      <span class="contact-name">Laurent Ciavaglia</span>,
      <span class="contact-name">Toerless Eckert</span>,
      <span class="contact-name">Joel Halpern</span>,
      <span class="contact-name">Russ Housley</span>,
      <span class="contact-name">Geoff Huston</span>,
      <span class="contact-name">Warren Kumari</span>,
      <span class="contact-name">Dan Romascanu</span>,
      and <span class="contact-name">Chongfeng Xie</span>.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Sheng Jiang (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Huawei Technologies Co., Ltd</span></div>
<div dir="auto" class="left"><span class="extended-address">Q14, Huawei Campus</span></div>
<div dir="auto" class="left"><span class="street-address">No. 156 Beiqing Road</span></div>
<div dir="auto" class="left"><span class="locality">Hai-Dian District, Beijing</span></div>
<div dir="auto" class="left"><span class="postal-code">100095</span></div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jiangsheng@huawei.com" class="email">jiangsheng@huawei.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Zongpeng Du</span></div>
<div dir="auto" class="left"><span class="org">China Mobile</span></div>
<div dir="auto" class="left"><span class="street-address">32 Xuanwumen West St</span></div>
<div dir="auto" class="left"><span class="locality">Xicheng District, Beijing</span></div>
<div dir="auto" class="left"><span class="postal-code">100053</span></div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:duzongpeng@chinamobile.com" class="email">duzongpeng@chinamobile.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Brian Carpenter</span></div>
<div dir="auto" class="left"><span class="org">University of Auckland</span></div>
<div dir="auto" class="left"><span class="extended-address">School of Computer Science</span></div>
<div dir="auto" class="left"><span class="street-address">PB 92019</span></div>
<div dir="auto" class="left">
<span class="locality">Auckland</span> <span class="postal-code">1142</span>
</div>
<div dir="auto" class="left"><span class="country-name">New Zealand</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:brian.e.carpenter@gmail.com" class="email">brian.e.carpenter@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Qiong Sun</span></div>
<div dir="auto" class="left"><span class="org">China Telecom</span></div>
<div dir="auto" class="left"><span class="street-address">118 Xizhimennei St</span></div>
<div dir="auto" class="left"><span class="locality">Beijing</span></div>
<div dir="auto" class="left"><span class="postal-code">100035</span></div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:sunqiong@chinatelecom.cn" class="email">sunqiong@chinatelecom.cn</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>