File: rfc8947.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 (2427 lines) | stat: -rw-r--r-- 113,772 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 8947: Link-Layer Address Assignment Mechanism for DHCPv6</title>
<meta content="Bernie Volz" name="author">
<meta content="Tomek Mrugalski" name="author">
<meta content="Carlos J. Bernardos" name="author">
<meta content="
       In certain environments, e.g., large-scale virtualization
      deployments, new devices are created in an automated manner. Such
      devices may have their link-layer addresses assigned in an automated
      fashion. With sufficient scale, the likelihood of a collision using
      random assignment without duplication detection is not
      acceptable.    
      Therefore, an allocation mechanism is required. This document proposes
      an extension to DHCPv6 that allows a scalable approach to link-layer
      address assignments
      where preassigned link-layer address assignments (such as by a
      manufacturer) are not possible or are unnecessary. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="DHCPv6" name="keyword">
<meta content="DHCP" name="keyword">
<meta content="Link-layer" name="keyword">
<meta content="assignment" name="keyword">
<meta content="8947" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.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="rfc8947.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";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8947" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign-09" 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 8947</td>
<td class="center">DHCPv6 Link-Layer Address Assignment</td>
<td class="right">December 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Volz, et al.</td>
<td class="center">Standards Track</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/rfc8947" class="eref">8947</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-12" class="published">December 2020</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">B. Volz</div>
<div class="org">Cisco</div>
</div>
<div class="author">
      <div class="author-name">T. Mrugalski</div>
<div class="org">ISC</div>
</div>
<div class="author">
      <div class="author-name">CJ. Bernardos</div>
<div class="org">UC3M</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8947</h1>
<h1 id="title">Link-Layer Address Assignment Mechanism for DHCPv6</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">In certain environments, e.g., large-scale virtualization
      deployments, new devices are created in an automated manner. Such
      devices may have their link-layer addresses assigned in an automated
      fashion. With sufficient scale, the likelihood of a collision using
      random assignment without duplication detection is not
      acceptable.    
      Therefore, an allocation mechanism is required. This document proposes
      an extension to DHCPv6 that allows a scalable approach to link-layer
      address assignments
      where preassigned link-layer address assignments (such as by a
      manufacturer) are not possible or are unnecessary.<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 is an Internet Standards Track document.<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).  Further
            information on Internet Standards is available in 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/rfc8947">https://www.rfc-editor.org/info/rfc8947</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) 2020 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="compact toc ulEmpty">
<li class="compact toc ulEmpty" 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><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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-deployment-scenarios" class="xref">Deployment Scenarios</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" 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-scenario-proxy-client-mode" class="xref">Scenario: Proxy Client Mode</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" 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-scenario-direct-client-mode" class="xref">Scenario: Direct Client Mode</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" 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-mechanism-overview" class="xref">Mechanism Overview</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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-design-assumptions" class="xref">Design Assumptions</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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-information-encoding" class="xref">Information Encoding</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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-requesting-addresses" class="xref">Requesting Addresses</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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-renewing-addresses" class="xref">Renewing Addresses</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-releasing-addresses" class="xref">Releasing Addresses</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-option-definitions" class="xref">Option Definitions</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-identity-association-for-li" class="xref">Identity Association for Link-Layer Addresses Option</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-link-layer-addresses-option" class="xref">Link-Layer Addresses Option</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-selecting-link-layer-addres" class="xref">Selecting Link-Layer Addresses for Assignment to an IA_LL</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-14" class="xref">14</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-15" class="xref">15</a>. <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#section-16" class="xref">16</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.16.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.16.2.1">
                <p id="section-toc.1-1.16.2.1.1"><a href="#section-16.1" class="xref">16.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.16.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.16.2.2">
                <p id="section-toc.1-1.16.2.2.1"><a href="#section-16.2" class="xref">16.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.16.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-ieee-802c-summary" class="xref">IEEE 802c Summary</a><a href="#section-toc.1-1.17.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.18">
            <p id="section-toc.1-1.18.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.18.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.19">
            <p id="section-toc.1-1.19.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.19.1" class="pilcrow">¶</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">There are several deployment types that deal with a large number
      of devices that need to be initialized. One of them is a scenario
      where virtual machines (VMs) are created on a massive scale.
      Typically, the new VM instances are assigned a link-layer address,
      but random assignment does not scale well due to the risk of a collision
      (see <span><a href="https://www.rfc-editor.org/rfc/rfc4429#appendix-A.1" class="relref">Appendix A.1</a> of [<a href="#RFC4429" class="xref">RFC4429</a>]</span>). Another
      use case is Internet of Things (IoT) devices (see
      <span>[<a href="#RFC7228" class="xref">RFC7228</a>]</span>). The huge number of such devices could
      strain the IEEE's available Organizationally Unique Identifier (OUI)
      global address space. While there is typically no need to provide
      global link-layer address uniqueness for such devices, a link-layer
      assignment mechanism allows for conflicts to be avoided
      inside an administrative domain. For those reasons, it is desired to
      have some form of mechanism that would be able to assign locally
      unique Media Access Control (MAC) addresses.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This document proposes a new mechanism that extends DHCPv6
      operation to handle link-layer address assignments.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Since DHCPv6 <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span> is a protocol
      that can allocate various types of resources (non-temporary
      addresses, temporary addresses, prefixes, as well as many options)
      and has the necessary infrastructure to maintain such allocations
      (numerous server and client implementations, large deployed
      relay infrastructure, and supportive solutions such as leasequery
      and failover), it is a good candidate to address the desired
      functionality.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">While this document presents a design that should be usable for
      any link-layer address type, some of the details are specific to
      IEEE 802 48-bit MAC addresses <span>[<a href="#IEEEStd802" class="xref">IEEEStd802</a>]</span>. Future
      documents may provide specifics for other link-layer address
      types.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">IEEE 802 originally set aside half of the 48-bit MAC address
      space for local use (where the Universal/Local (U/L) bit is set to 1). In 2017,
      IEEE published an amendment <span>[<a href="#IEEEStd802c" class="xref">IEEEStd802c</a>]</span> that
      divides this space into quadrants with differentiated address rules.
      More details are in <a href="#IEEE802cSummary" class="xref">Appendix A</a>.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">IEEE is also developing protocols and procedures for
      assignment of locally unique addresses (IEEE 802.1CQ). This work may
      serve as an alternative protocol for assignment. For additional
      background, see <span>[<a href="#IEEE-P802.1CQ-Project" class="xref">IEEE-P802.1CQ-Project</a>]</span>.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="requirements">
<section id="section-2">
      <h2 id="name-requirements-language">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</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>
</section>
</div>
<div id="terminology">
<section id="section-3">
      <h2 id="name-terminology">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-3-1">The DHCP terminology relevant to this specification from
      <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span> applies here. The following definitions
      either modify those definitions as to how they are used in this
      document or define new terminology used herein.<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-2">
        <dt id="section-3-2.1">address</dt>
        <dd style="margin-left: 8.0em" id="section-3-2.2">Unless specified otherwise, a link-layer (or MAC) address, as specified in
          <span>[<a href="#IEEEStd802" class="xref">IEEEStd802</a>]</span>. The
          address is typically six octets long, but some network
          architectures may use different lengths.<a href="#section-3-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.3">address block</dt>
        <dd style="margin-left: 8.0em" id="section-3-2.4">A number of consecutive link-layer
          addresses. An address block is expressed as a first address
          plus a number that designates the number of additional (extra)
          addresses. A single address can be represented by the address
          itself and zero extra addresses.<a href="#section-3-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.5">client</dt>
        <dd style="margin-left: 8.0em" id="section-3-2.6">A node that is interested in obtaining
          link-layer addresses. It implements the basic DHCP mechanisms
          needed by a DHCP
          client, as described in <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>, and
          supports the new options specified in this document (IA_LL and LLADDR). The client may or may not support IPv6
          address assignment and prefix delegation, as specified in
          <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>.<a href="#section-3-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.7">IA_LL</dt>
        <dd style="margin-left: 8.0em" id="section-3-2.8">Identity Association for Link-Layer Address,
          an identity association (IA) used to request or assign
          link-layer addresses. See <a href="#IA_LL" class="xref">Section 11.1</a> for details on
          the IA_LL option.<a href="#section-3-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.9">LLADDR</dt>
        <dd style="margin-left: 8.0em" id="section-3-2.10">Link-layer address option that is used to
          request or assign a block of link-layer addresses. See
          <a href="#LLADDR" class="xref">Section 11.2</a> for details on the LLADDR option.<a href="#section-3-2.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.11">server</dt>
        <dd style="margin-left: 8.0em" id="section-3-2.12">A node that manages link-layer address allocation
          and is able to respond to client queries. It implements basic DHCP
          server functionality, as described in <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>, and
          supports the new options specified in this document
          (IA_LL and LLADDR). The server may or
          may not support IPv6 address assignment and prefix delegation as
          specified in <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>.<a href="#section-3-2.12" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="overview">
<section id="section-4">
      <h2 id="name-deployment-scenarios">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-deployment-scenarios" class="section-name selfRef">Deployment Scenarios</a>
      </h2>
<p id="section-4-1">This mechanism is designed to be generic and usable in many
      deployments, but there are two scenarios it attempts to address in
      particular: (i) proxy client mode and (ii) direct client mode.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="proxy">
<section id="section-4.1">
        <h3 id="name-scenario-proxy-client-mode">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-scenario-proxy-client-mode" class="section-name selfRef">Scenario: Proxy Client Mode</a>
        </h3>
<p id="section-4.1-1">This mode is used when an entity acts as a DHCP client that
 requests that available DHCP servers assign one or more
        addresses (an address block) for the DHCP client to then
 assign to the final end devices to use. Large-scale virtualization is one
        application scenario for proxy client mode. In such
        environments, this entity is often called a "hypervisor" and is
        frequently required to spawn new VMs. The hypervisor needs to
        assign new addresses to those machines. The hypervisor does
        not use those addresses for itself, but rather it uses them to
        create new VMs with appropriate addresses. It is worth
        pointing out the cumulative nature of this scenario. Over
        time, the hypervisor is likely to increase its address
        use. Some obsolete VMs will be deleted; their addresses
        are potentially eligible for reuse by new VMs.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="direct">
<section id="section-4.2">
        <h3 id="name-scenario-direct-client-mode">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-scenario-direct-client-mode" class="section-name selfRef">Scenario: Direct Client Mode</a>
        </h3>
<p id="section-4.2-1">This mode can be used when an entity acts as a DHCP client that
        requests that available DHCP servers assign one or more addresses
        (an address block) for its own use. This usage scenario is related to
        IoT (see <a href="#intro" class="xref">Section 1</a>). Upon first
        boot, for each interface, the device uses a temporary address, as
        described in <span>[<a href="#IEEEStd802.11" class="xref">IEEEStd802.11</a>]</span> and
        IEEE 802.1CQ <span>[<a href="#IEEE-P802.1CQ-Project" class="xref">IEEE-P802.1CQ-Project</a>]</span>, to send
        initial DHCP packets to available DHCP servers wherein the device
        requests a single address for that network interface. Once the
        server assigns an address, the device abandons its
        temporary address and uses the assigned (leased) address.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">Note that a client that operates as above that does not have a
        globally unique link-layer address on any of its interfaces <span class="bcp14">MUST NOT</span> use a link-layer-based DHCP Unique Identifier (DUID). For more
        details, refer to <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-11" class="relref">Section 11</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">Also, a client that operates as above may run into issues if
        the switch it is connected to prohibits or restricts link-layer
        address changes. This may limit where this capability can be used
        or may require the administrator to adjust the configuration of
        the switch(es) to allow a change in address.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="mechanism">
<section id="section-5">
      <h2 id="name-mechanism-overview">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-mechanism-overview" class="section-name selfRef">Mechanism Overview</a>
      </h2>
<p id="section-5-1">In the scenarios described in <a href="#overview" class="xref">Section 4</a>, the protocol operates in fundamentally the
        same way.

 The device requesting an address, acting as a DHCP
        client, will send a Solicit message with an IA_LL option to all
        available DHCP servers. That IA_LL option <span class="bcp14">MUST</span> include an LLADDR
        option specifying the link-layer-type and
        link-layer-len, and it may include a specific address or address
        block as a hint for the server. Each available server responds
        with either a Reply message with committed address(es) (if Rapid
        Commit was requested and honored) or an Advertise message with
        offered address(es). The client selects a server's response, as
        governed by <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>. If necessary, the client
        sends a Request message; the target server will then assign the
        address(es) and send a Reply message. Once a Reply is received,
        the client can start using those address(es).<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Normal DHCP mechanisms are in use. The client is expected to
        periodically renew the addresses as governed by T1 and T2 timers
        and to stop using the address once the valid lifetime expires.
        Renewals can be administratively disabled by the server
        sending "infinity" as the T1 and T2 values (see <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-7.7" class="relref">Section 7.7</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>). An administrator may make the
 address assignment permanent by specifying use of the "infinity" valid
        lifetime, as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-7.7" class="relref">Section 7.7</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">The client can release addresses when they are no longer
        needed by sending a Release message (see <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-18.2.7" class="relref">Section 18.2.7</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>).<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">Figure 9 in <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span> shows
        a timeline diagram of the messages exchanged between a client and
        two servers for the typical life cycle of one or more leases.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">Confirm and Information-request messages are not used in
        link-layer address assignment. Decline should technically
        never be needed, but see <a href="#selecting-addresses" class="xref">Section 12</a> for
        one situation where this message is needed.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">Clients implementing this mechanism <span class="bcp14">SHOULD</span> use the Rapid Commit
        option, as specified in Sections <a href="https://www.rfc-editor.org/rfc/rfc8415#section-5.1" class="relref">5.1</a> and <a href="https://www.rfc-editor.org/rfc/rfc8415#section-18.2.1" class="relref">18.2.1</a> of <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>, to obtain addresses
 with a two-message exchange when possible.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">Devices supporting this proposal <span class="bcp14">MAY</span> support the reconfigure
        mechanism, as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-18.2.11" class="relref">Section 18.2.11</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>. If supported by both server and client, 
        the reconfigure mechanism allows the administrator to immediately
        notify clients that the configuration has changed and triggers
        retrieval of relevant changes immediately, rather than after the
        T1 timer elapses. Since this mechanism requires implementation of
        Reconfiguration Key Authentication Protocol (see <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-20.4" class="relref">Section 20.4</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>), small-footprint devices may
 choose not to support it.<a href="#section-5-7" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-6">
      <h2 id="name-design-assumptions">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-design-assumptions" class="section-name selfRef">Design Assumptions</a>
      </h2>
<p id="section-6-1">One of the essential aspects of this mechanism is its cumulative
      nature, especially in the hypervisor scenario. The server-client
      relationship does not look like other DHCP transactions in the
      hypervisor scenario. In a typical environment, there would be one
      server and a rather small number of hypervisors, possibly
      even only one. However, over time, the number of addresses requested
      by the hypervisor(s) will increase as more VMs are spawned.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Another aspect crucial for efficient design is the observation
      that a single client acting as hypervisor will likely use thousands
      of addresses. An approach similar to what is used for IPv6
      address or prefix assignment (IA container with all assigned
      addresses listed, one option for each address) would not work well.
      Therefore, the mechanism should operate on address blocks rather
      than single values. A single address can be treated as an address
      block with just one address.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">The DHCP mechanisms are reused to a large degree, including message
      and option formats, transmission mechanisms, relay infrastructure,
      and others. However, a device wishing to support only link-layer
      address assignment is not required to support full DHCP. In other
      words, the device may support only assignment of link-layer
      addresses but not IPv6 addresses or prefixes.<a href="#section-6-3" class="pilcrow">¶</a></p>
</section>
<div id="Information-Encoding">
<section id="section-7">
      <h2 id="name-information-encoding">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-information-encoding" class="section-name selfRef">Information Encoding</a>
      </h2>
<p id="section-7-1">A client <span class="bcp14">MUST</span> send an LLADDR option encapsulated in an IA_LL
      option to specify the link-layer-type and link-layer-len values. For
      link-layer-type 1 (Ethernet) and 6 (IEEE 802 Networks), a client
      sets the link-layer-address field to:<a href="#section-7-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7-2">
        <li id="section-7-2.1">All zeroes if the client has
          no hint as to the starting address of the unicast address block.
          This address has the IEEE 802 individual/group bit set to 0
          (individual).<a href="#section-7-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-7-2.2">Any other value to request a specific block of
        address starting with the specified address.<a href="#section-7-2.2" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-7-3">Encoding information for other link-layer-types may be added in
      the future by publishing an RFC that specifies those values.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">A client sets the extra-addresses field to either 0 for a single
      address or the size of the requested address block minus 1.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">A client <span class="bcp14">MUST</span> set the valid-lifetime field to 0 (this field
      <span class="bcp14">MUST</span> be ignored by the server).<a href="#section-7-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8">
      <h2 id="name-requesting-addresses">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-requesting-addresses" class="section-name selfRef">Requesting Addresses</a>
      </h2>
<p id="section-8-1">The addresses are assigned in blocks. The smallest block is a
      single address. To request an assignment, the client sends a Solicit
      message with an IA_LL option inside. The IA_LL option <span class="bcp14">MUST</span>
      contain an LLADDR option, as specified in
      <a href="#Information-Encoding" class="xref">Section 7</a>.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">The server, upon receiving an IA_LL option, inspects its content
      and may offer an address or addresses for each LLADDR option
      according to its policy. The server <span class="bcp14">MAY</span> take into consideration the
      address block requested by the client in the LLADDR option. However,
      the server <span class="bcp14">MAY</span> choose to ignore some or all parameters of the
      requested address block. In particular, the server may send
      either a
      different starting address or a smaller number of
      addresses than requested. The server sends back an Advertise
      message with an IA_LL option containing an LLADDR option that
      specifies the addresses being offered. If the server is unable to 
      provide any addresses, it <span class="bcp14">MUST</span> return the IA_LL option containing a
      Status Code option (see <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-21.13" class="relref">Section 21.13</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>) with status set to NoAddrsAvail.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Note that servers that do not support the IA_LL option will ignore
      the option and not return it in Advertise (and Reply) messages.
      Clients that send IA_LL options <span class="bcp14">MUST</span> treat this as if the server
      returned the NoAddrsAvail status for these IA_LL option(s).<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">The client waits for available servers to send Advertise
      responses and picks one server, as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-18.2.9" class="relref">Section 18.2.9</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>. The client then sends a Request 
      message that includes the IA_LL container option with the LLADDR
      option copied from the Advertise message sent by the chosen
      server.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">The client <span class="bcp14">MUST</span> process the address block(s) returned in the
      Advertise, rather than what it included in the Solicit message, and may 
      consider the offered address block(s) in selecting the Advertise
      message to
      accept. The server may offer a smaller number of addresses or
      different addresses from those requested. A client <span class="bcp14">MUST NOT</span> use
      resources returned in an Advertise message except to select a server
      and in sending the Request message to that server; resources are only
      useable by a client when returned in a Reply message.<a href="#section-8-5" class="pilcrow">¶</a></p>
<p id="section-8-6">Upon reception of a Request message with the IA_LL container option,
      the server assigns the requested addresses. The server allocates a
      block of addresses according to its configured policy. The server
      <span class="bcp14">MAY</span> assign a different block or smaller block size than requested in
      the Request message. The server then generates and sends a Reply
      message back to the client.<a href="#section-8-6" class="pilcrow">¶</a></p>
<p id="section-8-7">Upon receiving a Reply message, the client parses the IA_LL
      container option and may start using all provided addresses. It <span class="bcp14">MUST</span> 
      restart its T1 and T2 timers using the values specified in the IA_LL
      option.<a href="#section-8-7" class="pilcrow">¶</a></p>
<p id="section-8-8">The client <span class="bcp14">MUST</span> use the address block(s) returned in the Reply
      message, which may be a smaller block(s) or may have a different address(es)
      than requested.<a href="#section-8-8" class="pilcrow">¶</a></p>
<p id="section-8-9">A client that has included a Rapid Commit option in the Solicit
      message may receive a Reply in response to the Solicit message and skip the
      Advertise and Request message steps above (see <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-18.2.1" class="relref">Section 18.2.1</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>).<a href="#section-8-9" class="pilcrow">¶</a></p>
<p id="section-8-10">A client that changes its link-layer address on an interface
      <span class="bcp14">SHOULD</span> follow the recommendations in <span><a href="https://www.rfc-editor.org/rfc/rfc4861#section-7.2.6" class="relref">Section 7.2.6</a> of [<a href="#RFC4861" class="xref">RFC4861</a>]</span> to inform its
      neighbors of the new link-layer address quickly.<a href="#section-8-10" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-renewing-addresses">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-renewing-addresses" class="section-name selfRef">Renewing Addresses</a>
      </h2>
<p id="section-9-1">Address renewals follow the normal DHCP renewals processing
      described in <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-18.2.4" class="relref">Section 18.2.4</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>. Once the T1
      timer elapses, the client starts sending Renew messages with the
      IA_LL option containing an LLADDR option for the address block being
      renewed. The server responds with a Reply message that contains the
      renewed address block. The server <span class="bcp14">MUST NOT</span> shrink or expand the
      address block. Once a block is assigned and has a non-zero valid
      lifetime, its size, starting address, and ending address <span class="bcp14">MUST NOT</span>
      change.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">If the requesting client needs additional addresses (e.g., in
      the hypervisor scenario because addresses need to be assigned to new
      VMs), it <span class="bcp14">MUST</span> send an IA_LL option with a different
      Identity Association IDentifier (IAID) to create
      another "container" for more addresses.<a href="#section-9-2" class="pilcrow">¶</a></p>
<p id="section-9-3">If the client is unable to renew before the T2 timer elapses, it
      starts sending Rebind messages, as described in
      <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-18.2.5" class="relref">Section 18.2.5</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>.<a href="#section-9-3" class="pilcrow">¶</a></p>
</section>
<section id="section-10">
      <h2 id="name-releasing-addresses">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-releasing-addresses" class="section-name selfRef">Releasing Addresses</a>
      </h2>
<p id="section-10-1">The client may decide to release a leased address block. A client
      <span class="bcp14">MUST</span> release the block in its entirety. A client releases an
      address block by sending a Release message that includes an IA_LL
      option containing the LLADDR option for the address block to
      release. The Release transmission mechanism is described in <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-18.2.7" class="relref">Section 18.2.7</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">Note that if the client is releasing the link-layer address it is
      using, it <span class="bcp14">MUST</span> stop using this address before sending the
      Release message (as per <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>). In order to send
      the Release message, the client <span class="bcp14">MUST</span> use another address (such as
      the one originally used to initiate DHCPv6 to provide an allocated
      link-layer address).<a href="#section-10-2" class="pilcrow">¶</a></p>
</section>
<div id="option">
<section id="section-11">
      <h2 id="name-option-definitions">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-option-definitions" class="section-name selfRef">Option Definitions</a>
      </h2>
<p id="section-11-1">This mechanism uses an approach similar to the existing
      mechanisms in DHCP. There is one container option (the IA_LL option)
      that contains the actual address or addresses, represented by an
      LLADDR option. Each LLADDR option represents an address block, which
      is expressed as a first address with a number that specifies how
      many additional addresses are included.<a href="#section-11-1" class="pilcrow">¶</a></p>
<div id="IA_LL">
<section id="section-11.1">
        <h3 id="name-identity-association-for-li">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-identity-association-for-li" class="section-name selfRef">Identity Association for Link-Layer Addresses Option</a>
        </h3>
<p id="section-11.1-1">The Identity Association for Link-Layer Addresses option
 (the IA_LL
   option) is used to carry an IA_LL, the parameters
   associated with the IA_LL, and the address blocks associated with
   the IA_LL.<a href="#section-11.1-1" class="pilcrow">¶</a></p>
<p id="section-11.1-2">The format of the IA_LL option is:<a href="#section-11.1-2" class="pilcrow">¶</a></p>
<span id="name-ia_ll-option-format"></span><div id="ia-ll-syntax">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-11.1-3.1">
<pre>
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          OPTION_IA_LL         |          option-len           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IAID (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          T1 (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          T2 (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .                                                               .
  .                         IA_LL-options                         .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-ia_ll-option-format" class="selfRef">IA_LL Option Format</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-11.1-4">
          <dt id="section-11.1-4.1">option-code</dt>
          <dd style="margin-left: 8.0em" id="section-11.1-4.2">OPTION_IA_LL (138).<a href="#section-11.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-4.3">option-len</dt>
          <dd style="margin-left: 8.0em" id="section-11.1-4.4">12 + length of IA_LL-options field.<a href="#section-11.1-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-4.5">IAID</dt>
          <dd style="margin-left: 8.0em" id="section-11.1-4.6">The unique identifier for this IA_LL; the
                           IAID must be unique among the identifiers for
                           all of this client's IA_LLs.  The number
                           space for IA_LL IAIDs is separate from the
                           number space for other IA option types (i.e.,
                           IA_NA, IA_TA, and IA_PD). A 4-octet field
                           containing an unsigned integer.<a href="#section-11.1-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-4.7">T1</dt>
          <dd style="margin-left: 8.0em" id="section-11.1-4.8">The time interval after which the client
                           should contact the server from which the
                           addresses in the IA_LL were obtained to extend
                           the valid lifetime of the addresses assigned to
                           the IA_LL; T1 is a time duration relative to
                           the current time expressed in units of seconds.
                           A 4-octet field containing an unsigned integer.<a href="#section-11.1-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-4.9">T2</dt>
          <dd style="margin-left: 8.0em" id="section-11.1-4.10">The time interval after which the client
                           should contact any available server to extend
                           the valid lifetime of the addresses assigned to
                           the IA_LL; T2 is a time duration relative to
                           the current time expressed in units of seconds.
                           A 4-octet field containing an unsigned integer.<a href="#section-11.1-4.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-4.11">IA_LL-options</dt>
          <dd style="margin-left: 8.0em" id="section-11.1-4.12">Options associated with this
                           IA_LL. A variable-length field (12 octets less
                           than the value in the option-len field).<a href="#section-11.1-4.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-11.1-5">An IA_LL option may only appear in the options area of a DHCP
        message.  A DHCP message may contain multiple IA_LL options
        (though each must have a unique IAID).<a href="#section-11.1-5" class="pilcrow">¶</a></p>
<p id="section-11.1-6">The status of any operations involving this IA_LL is indicated
        in a Status Code option (see <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-21.13" class="relref">Section 21.13</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>) in the IA_LL-options field.<a href="#section-11.1-6" class="pilcrow">¶</a></p>
<p id="section-11.1-7">Note that an IA_LL has no explicit "lifetime" or "lease length"
        of its own. When the valid lifetimes of all of the addresses in an
        IA_LL have expired, the IA_LL can be considered to be expired.
        T1 and T2 are included to give servers explicit control over when
        a client recontacts the server about a specific IA_LL.<a href="#section-11.1-7" class="pilcrow">¶</a></p>
<p id="section-11.1-8">In a message sent by a client to a server, the T1 and T2 fields
        <span class="bcp14">MUST</span> be set to 0.  The server <span class="bcp14">MUST</span> ignore any values in these
        fields in messages received from a client.<a href="#section-11.1-8" class="pilcrow">¶</a></p>
<p id="section-11.1-9">In a message sent by a server to a client, the client <span class="bcp14">MUST</span> use
        the values in the T1 and T2 fields for the T1 and T2 times, unless
        those values in those fields are 0.  The values in the T1 and T2
        fields are the number of seconds until T1 and T2.<a href="#section-11.1-9" class="pilcrow">¶</a></p>
<p id="section-11.1-10">As per <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-7.7" class="relref">Section 7.7</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>,
        the value 0xffffffff is taken to mean "infinity" and should be
        used carefully.<a href="#section-11.1-10" class="pilcrow">¶</a></p>
<p id="section-11.1-11">The server selects the T1 and T2 times to allow the client to
        extend the lifetimes of any address block in the IA_LL before the
        lifetimes expire, even if the server is unavailable for some short
        period of time.  Recommended values for T1 and T2 are .5 and .8
        times the shortest valid lifetime of the address blocks in the IA
        that the server is willing to extend, respectively.  If the
        "shortest" valid lifetime is 0xffffffff ("infinity"), the
        recommended T1 and T2 values are also 0xffffffff.  If the time at
        which the addresses in an IA_LL are to be renewed is to be left to
        the discretion of the client, the server sets T1 and T2 to 0.  The
        client <span class="bcp14">MUST</span> follow the rules defined in
        <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-14.2" class="relref">Section 14.2</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>.<a href="#section-11.1-11" class="pilcrow">¶</a></p>
<p id="section-11.1-12">If a client receives an IA_LL with T1 greater than T2, and both
        T1 and T2 are greater than 0, the client discards the IA_LL option
        and processes the remainder of the message as though the server
        had not included the invalid IA_LL option.<a href="#section-11.1-12" class="pilcrow">¶</a></p>
<p id="section-11.1-13">The IA_LL-options field typically contains one or more LLADDR
        options (see <a href="#LLADDR" class="xref">Section 11.2</a>). If a client does not include
        an LLADDR option in a Solicit or Request message, the server <span class="bcp14">MUST</span>
        treat this as a request for a single address and that the
        client has no hint as to the address it would like.<a href="#section-11.1-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="LLADDR">
<section id="section-11.2">
        <h3 id="name-link-layer-addresses-option">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-link-layer-addresses-option" class="section-name selfRef">Link-Layer Addresses Option</a>
        </h3>
<p id="section-11.2-1">The Link-Layer Addresses option is used to specify an address block
   associated with an IA_LL. The option must be encapsulated in the
   IA_LL-options field of an IA_LL option.  The LLaddr-options field
   encapsulates those options that are specific to this address block.<a href="#section-11.2-1" class="pilcrow">¶</a></p>
<p id="section-11.2-2">The format of the Link-Layer Addresses option is:<a href="#section-11.2-2" class="pilcrow">¶</a></p>
<span id="name-lladdr-option-format"></span><div id="lladdr-syntax">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-11.2-3.1">
<pre>
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          OPTION_LLADDR        |          option-len           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       link-layer-type         |        link-layer-len         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .                                                               .
  .                     link-layer-address                        .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      extra-addresses                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      valid-lifetime                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .                                                               .
  .                      LLaddr-options                           .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-lladdr-option-format" class="selfRef">LLADDR Option Format</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-11.2-4">
          <dt id="section-11.2-4.1">option-code</dt>
          <dd style="margin-left: 10.5em" id="section-11.2-4.2">OPTION_LLADDR (139).<a href="#section-11.2-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-4.3">option-len</dt>
          <dd style="margin-left: 10.5em" id="section-11.2-4.4">12 + link-layer-len field value
            + length of LLaddr-options field. Assuming a 
            link-layer-address length of 6 and no extra options, the
            option-len would be 18.<a href="#section-11.2-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-4.5">link-layer-type</dt>
          <dd style="margin-left: 10.5em" id="section-11.2-4.6">The link-layer type <span class="bcp14">MUST</span> be a
            valid hardware type assigned by IANA, as described in
            <span>[<a href="#RFC5494" class="xref">RFC5494</a>]</span>, and registered in the "Hardware Types" registry at
            <span>&lt;<a href="https://www.iana.org/assignments/arp-parameters">https://www.iana.org/assignments/arp-parameters</a>&gt;</span>.
            A 2-octet field containing an unsigned integer.<a href="#section-11.2-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-4.7">link-layer-len</dt>
          <dd style="margin-left: 10.5em" id="section-11.2-4.8">Specifies the length, in octets,
            of the link-layer-address field (typically 6 for a
            link-layer-type of 1 (Ethernet) and 6 (IEEE 802 Networks)).
            This is to accommodate link layers that may have
            variable-length addresses. A 2-octet field containing an
            unsigned integer.<a href="#section-11.2-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-4.9">link-layer-address</dt>
          <dd style="margin-left: 10.5em" id="section-11.2-4.10">Specifies the address of
            the first link-layer address that is being requested or
            assigned depending on the message. A client <span class="bcp14">MAY</span> send a
            special value to request any address.

     For link-layer
            types 1 and 6, see
            <a href="#Information-Encoding" class="xref">Section 7</a> for details on this
            field. A link-layer-len length octet field containing an
            address.<a href="#section-11.2-4.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-4.11">extra-addresses</dt>
          <dd style="margin-left: 10.5em" id="section-11.2-4.12">Specifies the number of
            additional addresses that follow the address specified in
            link-layer-address. For a single address, 0 is used.
            For example, link-layer-address 02:04:06:08:0a and
            extra-addresses 3 designate a block of four addresses,
            starting from 02:04:06:08:0a and ending with
            02:04:06:08:0d (inclusive). A 4-octet field containing an
            unsigned integer.<a href="#section-11.2-4.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-4.13">valid-lifetime</dt>
          <dd style="margin-left: 10.5em" id="section-11.2-4.14">The valid lifetime for the
            address(es) in the option, expressed in units of seconds.
            A 4-octet field containing an unsigned integer.<a href="#section-11.2-4.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-4.15">LLaddr-options</dt>
          <dd style="margin-left: 10.5em" id="section-11.2-4.16">Any encapsulated options that
            are specific to this particular address block. Currently, there
            are no such options defined, but there may be in the future.<a href="#section-11.2-4.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-11.2-5">In a message sent by a client to a server, the valid
        lifetime field <span class="bcp14">MUST</span> be set to 0.  The server <span class="bcp14">MUST</span> ignore any
        received value.<a href="#section-11.2-5" class="pilcrow">¶</a></p>
<p id="section-11.2-6">In a message sent by a server to a client, the client <span class="bcp14">MUST</span> use
        the value in the valid lifetime field for the valid lifetime for
        the address block. The value in the valid lifetime field is the
        number of seconds remaining in the lifetime.<a href="#section-11.2-6" class="pilcrow">¶</a></p>
<p id="section-11.2-7">As per <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-7.7" class="relref">Section 7.7</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>,
        the valid lifetime of 0xffffffff is taken to mean "infinity" and
        should be used carefully.<a href="#section-11.2-7" class="pilcrow">¶</a></p>
<p id="section-11.2-8">More than one LLADDR option can appear in an IA_LL option.<a href="#section-11.2-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="selecting-addresses">
<section id="section-12">
      <h2 id="name-selecting-link-layer-addres">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-selecting-link-layer-addres" class="section-name selfRef">Selecting Link-Layer Addresses for Assignment to an IA_LL</a>
      </h2>
<p id="section-12-1">A server selects link-layer addresses to be assigned to an IA_LL
      according to the assignment policies determined by the server
      administrator and the requirements of that address space.<a href="#section-12-1" class="pilcrow">¶</a></p>
<p id="section-12-2">Link-layer addresses are typically specific to a link and the
      server <span class="bcp14">SHOULD</span> follow the steps in <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-13.1" class="relref">Section 13.1</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span> to determine the client's link.<a href="#section-12-2" class="pilcrow">¶</a></p>
<p id="section-12-3">For IEEE 802 MAC addresses (see <span>[<a href="#IEEEStd802" class="xref">IEEEStd802</a>]</span> as
      amended by <span>[<a href="#IEEEStd802c" class="xref">IEEEStd802c</a>]</span>):<a href="#section-12-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-12-4">
        <li id="section-12-4.1">Server administrators <span class="bcp14">SHOULD</span> follow the IEEE 802
        Specifications with regard to the unicast address pools made
        available for assignment (see <a href="#IEEE802cSummary" class="xref">Appendix A</a> and
        <span>[<a href="#IEEEStd802c" class="xref">IEEEStd802c</a>]</span>) -- only address space reserved for
        local use or with the authorization of the assignee may be used.<a href="#section-12-4.1" class="pilcrow">¶</a>
</li>
        <li id="section-12-4.2">Servers <span class="bcp14">MUST NOT</span> allow administrators to
        configure address pools that would cross the boundary of 2<sup>42</sup> bits
        (for 48-bit MAC addresses) to avoid issues with changes in the
        first octet of the address and the special bits therein (see
        <a href="#IEEE802cSummary" class="xref">Appendix A</a>). Clients <span class="bcp14">MUST</span> reject assignments
        where the assigned block would cross this boundary (they <span class="bcp14">MUST</span>
        decline the allocation -- see <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-18.2.8" class="relref">Section 18.2.8</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>).<a href="#section-12-4.2" class="pilcrow">¶</a>
</li>
        <li id="section-12-4.3">A server <span class="bcp14">MAY</span> use options supplied by a
        relay agent or client to select the quadrant (see
        <a href="#IEEE802cSummary" class="xref">Appendix A</a>) from which addresses are to be
        assigned. This <span class="bcp14">MAY</span> include options like those specified in
        <span>[<a href="#RFC8948" class="xref">RFC8948</a>]</span>.<a href="#section-12-4.3" class="pilcrow">¶</a>
</li>
      </ol>
</section>
</div>
<div id="iana">
<section id="section-13">
      <h2 id="name-iana-considerations">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-13-1">IANA has assigned the OPTION_IA_LL (138)
   option code from the "Option Codes" subregistry of the
   "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at
   <span>&lt;<a href="http://www.iana.org/assignments/dhcpv6-parameters">http://www.iana.org/assignments/dhcpv6-parameters</a>&gt;</span>:<a href="#section-13-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-13-2">
        <dt id="section-13-2.1">Value:</dt>
        <dd style="margin-left: 7.0em" id="section-13-2.2">138<a href="#section-13-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-13-2.3">Description:</dt>
        <dd style="margin-left: 7.0em" id="section-13-2.4">OPTION_IA_LL<a href="#section-13-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-13-2.5">Client ORO:</dt>
        <dd style="margin-left: 7.0em" id="section-13-2.6">No<a href="#section-13-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-13-2.7">Singleton Option:</dt>
        <dd style="margin-left: 7.0em" id="section-13-2.8">No<a href="#section-13-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-13-2.9">Reference:</dt>
        <dd style="margin-left: 7.0em" id="section-13-2.10">RFC 8947<a href="#section-13-2.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-13-3">IANA has assigned the OPTION_LLADDR (139)
      option code from the "Option Codes" subregistry of the
   "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at
   <span>&lt;<a href="http://www.iana.org/assignments/dhcpv6-parameters">http://www.iana.org/assignments/dhcpv6-parameters</a>&gt;</span>:<a href="#section-13-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-13-4">
        <dt id="section-13-4.1">Value:</dt>
        <dd style="margin-left: 7.0em" id="section-13-4.2">139<a href="#section-13-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-13-4.3">Description:</dt>
        <dd style="margin-left: 7.0em" id="section-13-4.4">OPTION_LLADDR<a href="#section-13-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-13-4.5">Client ORO:</dt>
        <dd style="margin-left: 7.0em" id="section-13-4.6">No<a href="#section-13-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-13-4.7">Singleton Option:</dt>
        <dd style="margin-left: 7.0em" id="section-13-4.8">No<a href="#section-13-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-13-4.9">Reference:</dt>
        <dd style="margin-left: 7.0em" id="section-13-4.10">RFC 8947<a href="#section-13-4.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="security">
<section id="section-14">
      <h2 id="name-security-considerations">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-14-1">See <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-22" class="relref">Section 22</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span> and
      <span><a href="https://www.rfc-editor.org/rfc/rfc7227#section-23" class="relref">Section 23</a> of [<a href="#RFC7227" class="xref">RFC7227</a>]</span> for
      the DHCP security considerations. See <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>
      for the IPv6 security considerations.<a href="#section-14-1" class="pilcrow">¶</a></p>
<p id="section-14-2">As discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-22" class="relref">Section 22</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>:<a href="#section-14-2" class="pilcrow">¶</a></p>
<blockquote id="section-14-3">
        <p id="section-14-3.1">DHCP
      lacks end-to-end encryption between clients and servers; thus,
      hijacking, tampering, and eavesdropping attacks are all possible as
      a result.<a href="#section-14-3.1" class="pilcrow">¶</a></p>
</blockquote>
<p id="section-14-4">In some network environments, it is possible to secure
      them, as discussed later in <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-22" class="relref">Section 22</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>.<a href="#section-14-4" class="pilcrow">¶</a></p>
<p id="section-14-5">If not all parties on a link use this mechanism to obtain an address from the space assigned to the DHCP server, there is the possibility of the same link-layer address being used by more than one device.


      Note that this issue would exist on these networks
      even if DHCP were not used to obtain the address.<a href="#section-14-5" class="pilcrow">¶</a></p>
<p id="section-14-6">Server implementations <span class="bcp14">SHOULD</span> consider configuration options to
      limit the maximum number of addresses to allocate (both in a single
      request and in total) to a client. However, note that this does not
      prevent a bad client actor from pretending to be many different
      clients and consuming all available addresses.<a href="#section-14-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="privacy">
<section id="section-15">
      <h2 id="name-privacy-considerations">
<a href="#section-15" class="section-number selfRef">15. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-15-1">See <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-23" class="relref">Section 23</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span> for the
      DHCP privacy considerations.<a href="#section-15-1" class="pilcrow">¶</a></p>
<p id="section-15-2">For a client requesting a link-layer address directly from
      a server, as the address assigned to a client will
      likely be used by the client to communicate on the link, the
      address will be exposed to those able to listen in on this
      communication. For those peers on the link that are able to
      listen in on the DHCP exchange, they would also be able to
      correlate the client's identity (based on the DUID used) with the
      assigned address. Additional mechanisms, such as the ones described
      in <span>[<a href="#RFC7844" class="xref">RFC7844</a>]</span>, can also be used to improve
      anonymity by minimizing what is exposed.<a href="#section-15-2" class="pilcrow">¶</a></p>
<p id="section-15-3">As discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc8415#section-23" class="relref">Section 23</a> of [<a href="#RFC8415" class="xref">RFC8415</a>]</span>, DHCP
      servers and hypervisors may need to consider the implications of
      assigning addresses sequentially. Though in general, this is only
      of link-local concern unlike for IPv6 address assignment and
      prefix delegation, as these may be used for communication over the
      Internet.<a href="#section-15-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-16">
      <h2 id="name-references">
<a href="#section-16" class="section-number selfRef">16. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-16.1">
        <h3 id="name-normative-references">
<a href="#section-16.1" class="section-number selfRef">16.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="RFC4861">[RFC4861]</dt>
        <dd>
<span class="refAuthor">Narten, T.</span><span class="refAuthor">, Nordmark, E.</span><span class="refAuthor">, Simpson, W.</span><span class="refAuthor">, and H. Soliman</span>, <span class="refTitle">"Neighbor Discovery for IP version 6 (IPv6)"</span>, <span class="seriesInfo">RFC 4861</span>, <span class="seriesInfo">DOI 10.17487/RFC4861</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4861">https://www.rfc-editor.org/info/rfc4861</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="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><span class="refAuthor">, and 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>
</dl>
</section>
<section id="section-16.2">
        <h3 id="name-informative-references">
<a href="#section-16.2" class="section-number selfRef">16.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="IEEE-P802.1CQ-Project">[IEEE-P802.1CQ-Project]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"P802.1CQ - Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment"</span>, <span>&lt;<a href="https://standards.ieee.org/project/802_1CQ.html">https://standards.ieee.org/project/802_1CQ.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEEStd802">[IEEEStd802]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, IEEE Std 802"</span>, <span class="refContent">IEEE STD 802-2014</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2014.6847097</span>, <span>&lt;<a href="https://doi.org/10.1109/IEEESTD.2014.6847097">https://doi.org/10.1109/IEEESTD.2014.6847097</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEEStd802.11">[IEEEStd802.11]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications"</span>, <span class="refContent">IEEE Std 802.11</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2016.7786995</span>, <span>&lt;<a href="https://doi.org/10.1109/IEEESTD.2016.7786995">https://doi.org/10.1109/IEEESTD.2016.7786995</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEEStd802c">[IEEEStd802c]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Local and Metropolitan Area Networks:Overview and Architecture--Amendment 2: Local Medium Access Control (MAC) Address Usage"</span>, <span class="refContent">IEEE Std 802c-2017</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2017.8016709</span>, <span>&lt;<a href="https://doi.org/10.1109/IEEESTD.2017.8016709">https://doi.org/10.1109/IEEESTD.2017.8016709</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2464">[RFC2464]</dt>
        <dd>
<span class="refAuthor">Crawford, M.</span>, <span class="refTitle">"Transmission of IPv6 Packets over Ethernet Networks"</span>, <span class="seriesInfo">RFC 2464</span>, <span class="seriesInfo">DOI 10.17487/RFC2464</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2464">https://www.rfc-editor.org/info/rfc2464</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4429">[RFC4429]</dt>
        <dd>
<span class="refAuthor">Moore, N.</span>, <span class="refTitle">"Optimistic Duplicate Address Detection (DAD) for IPv6"</span>, <span class="seriesInfo">RFC 4429</span>, <span class="seriesInfo">DOI 10.17487/RFC4429</span>, <time datetime="2006-04" class="refDate">April 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4429">https://www.rfc-editor.org/info/rfc4429</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5494">[RFC5494]</dt>
        <dd>
<span class="refAuthor">Arkko, J.</span><span class="refAuthor"> and C. Pignataro</span>, <span class="refTitle">"IANA Allocation Guidelines for the Address Resolution Protocol (ARP)"</span>, <span class="seriesInfo">RFC 5494</span>, <span class="seriesInfo">DOI 10.17487/RFC5494</span>, <time datetime="2009-04" class="refDate">April 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5494">https://www.rfc-editor.org/info/rfc5494</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7227">[RFC7227]</dt>
        <dd>
<span class="refAuthor">Hankins, D.</span><span class="refAuthor">, Mrugalski, T.</span><span class="refAuthor">, Siodelski, M.</span><span class="refAuthor">, Jiang, S.</span><span class="refAuthor">, and S. Krishnan</span>, <span class="refTitle">"Guidelines for Creating New DHCPv6 Options"</span>, <span class="seriesInfo">BCP 187</span>, <span class="seriesInfo">RFC 7227</span>, <span class="seriesInfo">DOI 10.17487/RFC7227</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7227">https://www.rfc-editor.org/info/rfc7227</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7228">[RFC7228]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span><span class="refAuthor">, Ersue, M.</span><span class="refAuthor">, and A. Keranen</span>, <span class="refTitle">"Terminology for Constrained-Node Networks"</span>, <span class="seriesInfo">RFC 7228</span>, <span class="seriesInfo">DOI 10.17487/RFC7228</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7228">https://www.rfc-editor.org/info/rfc7228</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7844">[RFC7844]</dt>
        <dd>
<span class="refAuthor">Huitema, C.</span><span class="refAuthor">, Mrugalski, T.</span><span class="refAuthor">, and S. Krishnan</span>, <span class="refTitle">"Anonymity Profiles for DHCP Clients"</span>, <span class="seriesInfo">RFC 7844</span>, <span class="seriesInfo">DOI 10.17487/RFC7844</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7844">https://www.rfc-editor.org/info/rfc7844</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8200">[RFC8200]</dt>
        <dd>
<span class="refAuthor">Deering, S.</span><span class="refAuthor"> and R. Hinden</span>, <span class="refTitle">"Internet Protocol, Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 86</span>, <span class="seriesInfo">RFC 8200</span>, <span class="seriesInfo">DOI 10.17487/RFC8200</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8200">https://www.rfc-editor.org/info/rfc8200</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8948">[RFC8948]</dt>
      <dd>
<span class="refAuthor">Bernardos, CJ.</span><span class="refAuthor"> and A. Mourad</span>, <span class="refTitle">"Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6"</span>, <span class="seriesInfo">RFC 8948</span>, <span class="seriesInfo">DOI 10.17487/RFC8948</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8948">https://www.rfc-editor.org/info/rfc8948</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="IEEE802cSummary">
<section id="section-appendix.a">
      <h2 id="name-ieee-802c-summary">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-ieee-802c-summary" class="section-name selfRef">IEEE 802c Summary</a>
      </h2>
<p id="section-appendix.a-1">This appendix provides a brief summary of IEEE 802c
           <span>[<a href="#IEEEStd802c" class="xref">IEEEStd802c</a>]</span>.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">The original IEEE 802 specifications assigned half of the 48-bit
      MAC address space to local use -- these addresses have the U/L bit
      set to 1 and are locally administered with no imposed structure.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">In 2017, the IEEE issued the IEEE Std 802c specification, which
      defines a new optional "Structured Local Address Plan (SLAP) that
      specifies different assignment approaches in four specified regions
      of the local MAC address space". Under this plan, there are four SLAP
      quadrants that use different assignment policies.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">The first octet of the MAC address Z and Y bits define the
      quadrant for locally assigned addresses (X-bit is 1). In IEEE
      representation, these bits are as follows:<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<p id="section-appendix.a-5" class="keepWithNext"></p>
<span id="name-slap-bits"></span><div id="SLAP-Bits">
<figure id="figure-3">
        <div class="artwork art-text alignLeft" id="section-appendix.a-6.1">
<pre>
    LSB                MSB
    M  X  Y  Z  -  -  -  -
    |  |  |  |
    |  |  |  +------------ SLAP Z-bit
    |  |  +--------------- SLAP Y-bit
    |  +------------------ X-bit (U/L) = 1 for locally assigned
    +--------------------- M-bit (I/G) (unicast/group)
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-slap-bits" class="selfRef">SLAP Bits</a>
        </figcaption></figure>
</div>
<p id="section-appendix.a-7" class="keepWithPrevious"></p>
<p id="section-appendix.a-8">The SLAP quadrants are:<a href="#section-appendix.a-8" class="pilcrow">¶</a></p>
<span id="name-slap-quadrants"></span><table class="center" id="table-1">
        <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-slap-quadrants" class="selfRef">SLAP Quadrants</a>
        </caption>
<thead>
          <tr>
            <th class="text-right" rowspan="1" colspan="1">Quadrant</th>
            <th class="text-left" rowspan="1" colspan="1">Y-bit</th>
            <th class="text-left" rowspan="1" colspan="1">Z-bit</th>
            <th class="text-left" rowspan="1" colspan="1">Local Identifier Type</th>
            <th class="text-left" rowspan="1" colspan="1">Local Identifier</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">01</td>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">Extended Local</td>
            <td class="text-left" rowspan="1" colspan="1">ELI</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">11</td>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">Standard Assigned</td>
            <td class="text-left" rowspan="1" colspan="1">SAI</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">00</td>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">Administratively Assigned</td>
            <td class="text-left" rowspan="1" colspan="1">AAI</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">10</td>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved</td>
          </tr>
        </tbody>
      </table>
<p id="section-appendix.a-10">MAC addresses derived from an Extended Local Identifier (ELI) are based
      on an assigned Company ID (CID), which is 24 bits (including the M,
      X, Y, and Z bits) for 48-bit MAC addresses. This leaves 24 bits for
      the locally assigned address for each CID for unicast (M-bit = 0)
      and also for multicast (M-bit = 1). The CID is assigned by the IEEE
      Registration Authority (RA).<a href="#section-appendix.a-10" class="pilcrow">¶</a></p>
<p id="section-appendix.a-11">MAC addresses derived from a Standard Assigned Identifier (SAI) are
      assigned by a protocol specified in an IEEE 802 standard. For
      48-bit MAC addresses, 44 bits are available. Multiple protocols
      for assigning SAIs may be specified in IEEE standards. Coexistence
      of multiple protocols may be supported by limiting the subspace
      available for assignment by each protocol.<a href="#section-appendix.a-11" class="pilcrow">¶</a></p>
<p id="section-appendix.a-12">MAC addresses derived from an Administratively Assigned Identifier (AAI)
      are assigned locally. Administrators manage the space as needed.
      Note that multicast IPv6 packets <span>[<a href="#RFC2464" class="xref">RFC2464</a>]</span> use a
      destination address starting in 33-33, so AAI addresses in that
      range should not be assigned. For 48-bit MAC addresses, 44 bits are
      available.<a href="#section-appendix.a-12" class="pilcrow">¶</a></p>
<p id="section-appendix.a-13">The last quadrant is reserved for future use. While this quadrant
      may also be used similar to AAI space, administrators should be
      aware that future specifications may define alternate uses that
      could be incompatible.<a href="#section-appendix.a-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="acknowledgements">
<section id="section-appendix.b">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.b-1">Thanks to the DHC Working Group participants that reviewed this
      document and provided comments and support. With special thanks to
      <span class="contact-name">Ian Farrer</span> for his thorough reviews and shepherding of this
      document through the IETF process. Thanks also to directorate reviewers
      <span class="contact-name">Samita Chakrabarti</span>, <span class="contact-name">Roni       Even</span>, and <span class="contact-name">Tianran Zhou</span> and IESG members
      <span class="contact-name">Martin Duke</span>, <span class="contact-name">Benjamin Kaduk</span>,
      <span class="contact-name">Murray Kucherawy</span>, <span class="contact-name">Warren       Kumari</span>, <span class="contact-name">Barry Leiba</span>, <span class="contact-name">Alvaro       Retana</span>, <span class="contact-name">Éric Vyncke</span>, and <span class="contact-name">Robert Wilton</span> for their 
      suggestions. And thanks to <span class="contact-name">Roger Marks</span>, <span class="contact-name">Robert Grow</span>, and <span class="contact-name">Antonio de la       Oliva</span>
      for comments related to IEEE work and references.<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">Bernie Volz</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">300 Beaver Brook Rd</span></div>
<div dir="auto" class="left">
<span class="locality">Boxborough</span>, <span class="region">MA</span> <span class="postal-code">01719</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:volz@cisco.com" class="email">volz@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Tomek Mrugalski</span></div>
<div dir="auto" class="left"><span class="org">Internet Systems Consortium, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">PO Box 360</span></div>
<div dir="auto" class="left">
<span class="locality">Newmarket</span>, <span class="region">NH</span> <span class="postal-code">03857</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:tomasz.mrugalski@gmail.com" class="email">tomasz.mrugalski@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Carlos J. Bernardos</span></div>
<div dir="auto" class="left"><span class="org">Universidad Carlos III de Madrid</span></div>
<div dir="auto" class="left"><span class="street-address">Av. Universidad, 30</span></div>
<div dir="auto" class="left">
<span class="postal-code">28911</span> <span class="locality">Leganes, Madrid</span> </div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34%2091624%206236" class="tel">+34 91624 6236</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:cjbc@it.uc3m.es" class="email">cjbc@it.uc3m.es</a>
</div>
<div class="url">
<span>URI:</span>
<a href="http://www.it.uc3m.es/cjbc/" class="url">http://www.it.uc3m.es/cjbc/</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>