File: rfc8928.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 (2913 lines) | stat: -rw-r--r-- 167,226 bytes
parent folder | download | duplicates (2)
<!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 8928: Address-Protected Neighbor Discovery for Low-Power and Lossy Networks</title>
<meta content="Pascal Thubert" name="author">
<meta content="Behcet Sarikaya" name="author">
<meta content="Mohit Sethi" name="author">
<meta content="Rene Struik" name="author">
<meta content="
       
    This document updates the IPv6 over Low-Power Wireless
    Personal Area Network (6LoWPAN) Neighbor Discovery (ND)
    protocol defined in RFCs 6775 and 8505.  The new extension
    is called Address-Protected Neighbor Discovery (AP-ND), and
    it protects the owner of an address against address theft
    and impersonation attacks in a Low-Power and Lossy Network
    (LLN).  Nodes supporting this extension compute a
    cryptographic identifier (Crypto-ID), and use it with one
    or more of their Registered Addresses. The Crypto-ID
    identifies the owner of the Registered Address and can be
    used to provide proof of ownership of the Registered
    Addresses. Once an address is registered with the Crypto-ID
    and a proof of ownership is provided, only the owner of
    that address can modify the registration information,
    thereby enforcing Source Address Validation.
       
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="8928" 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="rfc8928.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/rfc8928" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd-23" 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 8928</td>
<td class="center">Address Protection ND for LLN</td>
<td class="right">November 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Thubert, 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/rfc8928" class="eref">8928</a></dd>
<dt class="label-updates">Updates:</dt>
<dd class="updates">
<a href="https://www.rfc-editor.org/rfc/rfc8505" class="eref">8505</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-11" class="published">November 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">P. Thubert, <span class="editor">Ed.</span>
</div>
<div class="org">Cisco</div>
</div>
<div class="author">
      <div class="author-name">B. Sarikaya</div>
</div>
<div class="author">
      <div class="author-name">M. Sethi</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">R. Struik</div>
<div class="org">Struik Security Consultancy</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8928</h1>
<h1 id="title">Address-Protected Neighbor Discovery for Low-Power and Lossy Networks</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
    This document updates the IPv6 over Low-Power Wireless
    Personal Area Network (6LoWPAN) Neighbor Discovery (ND)
    protocol defined in RFCs 6775 and 8505.  The new extension
    is called Address-Protected Neighbor Discovery (AP-ND), and
    it protects the owner of an address against address theft
    and impersonation attacks in a Low-Power and Lossy Network
    (LLN).  Nodes supporting this extension compute a
    cryptographic identifier (Crypto-ID), and use it with one
    or more of their Registered Addresses. The Crypto-ID
    identifies the owner of the Registered Address and can be
    used to provide proof of ownership of the Registered
    Addresses. Once an address is registered with the Crypto-ID
    and a proof of ownership is provided, only the owner of
    that address can modify the registration information,
    thereby enforcing Source Address Validation.<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/rfc8928">https://www.rfc-editor.org/info/rfc8928</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="ulEmpty toc compact">
<li class="ulEmpty toc compact" 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="ulEmpty toc compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-background" class="xref">Background</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-abbreviations" class="xref">Abbreviations</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-updating-rfc-8505" class="xref">Updating RFC 8505</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" 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-new-fields-and-options" class="xref">New Fields and Options</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" 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-new-crypto-id" class="xref">New Crypto-ID</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" 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-updated-earo" class="xref">Updated EARO</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-crypto-id-parameters-option" class="xref">Crypto-ID Parameters Option</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-ndp-signature-option" class="xref">NDP Signature Option</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-extensions-to-the-capabilit" class="xref">Extensions to the Capability Indication Option</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" 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-protocol-scope" class="xref">Protocol Scope</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" 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-protocol-flows" class="xref">Protocol Flows</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-first-exchange-with-a-6lr" class="xref">First Exchange with a 6LR</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-ndpso-generation-and-verifi" class="xref">NDPSO Generation and Verification</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-multi-hop-operation" class="xref">Multi-Hop Operation</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-brown-field" class="xref">Brown Field</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-threats-identified-in-rfc-3" class="xref">Threats Identified in RFC 3971</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-related-to-6lowpan-nd" class="xref">Related to 6LoWPAN ND</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-compromised-6lr" class="xref">Compromised 6LR</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.5">
                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-rovr-collisions" class="xref">ROVR Collisions</a><a href="#section-toc.1-1.7.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.6">
                <p id="section-toc.1-1.7.2.6.1"><a href="#section-7.6" class="xref">7.6</a>.  <a href="#name-implementation-attacks" class="xref">Implementation Attacks</a><a href="#section-toc.1-1.7.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.7">
                <p id="section-toc.1-1.7.2.7.1"><a href="#section-7.7" class="xref">7.7</a>.  <a href="#name-cross-algorithm-and-cross-p" class="xref">Cross-Algorithm and Cross-Protocol Attacks</a><a href="#section-toc.1-1.7.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.8">
                <p id="section-toc.1-1.7.2.8.1"><a href="#section-7.8" class="xref">7.8</a>.  <a href="#name-public-key-validation" class="xref">Public Key Validation</a><a href="#section-toc.1-1.7.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.9">
                <p id="section-toc.1-1.7.2.9.1"><a href="#section-7.9" class="xref">7.9</a>.  <a href="#name-correlating-registrations" class="xref">Correlating Registrations</a><a href="#section-toc.1-1.7.2.9.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-cga-message-type" class="xref">CGA Message Type</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-crypto-type-subregistry" class="xref">Crypto-Type Subregistry</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-ipv6-nd-option-types" class="xref">IPv6 ND Option Types</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-new-6lowpan-capability-bit" class="xref">New 6LoWPAN Capability Bit</a><a href="#section-toc.1-1.8.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-requirements-addressed-in-t" class="xref">Requirements Addressed in This Document</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-representation-conventions" class="xref">Representation Conventions</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-b.1" class="xref">B.1</a>.  <a href="#name-signature-schemes" class="xref">Signature Schemes</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-b.2" class="xref">B.2</a>.  <a href="#name-representation-of-ecdsa-sig" class="xref">Representation of ECDSA Signatures</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.11.2.3">
                <p id="section-toc.1-1.11.2.3.1"><a href="#section-b.3" class="xref">B.3</a>.  <a href="#name-representation-of-public-ke" class="xref">Representation of Public Keys Used with ECDSA</a><a href="#section-toc.1-1.11.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.11.2.4">
                <p id="section-toc.1-1.11.2.4.1"><a href="#section-b.4" class="xref">B.4</a>.  <a href="#name-alternative-representations" class="xref">Alternative Representations of Curve25519</a><a href="#section-toc.1-1.11.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.11.2.5">
                <p id="section-toc.1-1.11.2.5.1"><a href="#section-b.5" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.11.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<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">
     Neighbor Discovery optimizations for 6LoWPAN networks (aka 6LoWPAN ND) <span>[<a href="#RFC6775" class="xref">RFC6775</a>]</span> adapts the original IPv6 Neighbor Discovery protocols defined in <span>[<a href="#RFC4861" class="xref">RFC4861</a>]</span> and <span>[<a href="#RFC4862" class="xref">RFC4862</a>]</span> for constrained
     Low-Power and Lossy Networks (LLNs). In particular, 6LoWPAN ND introduces a unicast host Address Registration mechanism that reduces the use of multicast compared to the Duplicate Address Detection (DAD) mechanism defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration Option (ARO) that is carried in the unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages exchanged between a 6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). It also defines the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC)
     messages between the 6LR and the 6LoWPAN Border Router (6LBR). In LLNs, the 6LBR is the central repository of all the Registered Addresses in its domain.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
     The registration mechanism in "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" <span>[<a href="#RFC6775" class="xref">RFC6775</a>]</span> prevents the use of an address if that address
     is already registered in the subnet (first come, first served). In order to validate address ownership, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> defines a Registration Ownership Verifier (ROVR) field. <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> enables a 6LR and 6LBR to validate the association between the Registered Address of a node and its ROVR. The ROVR can be derived from the link-layer address of the device (using the 64-bit Extended Unique Identifier (EUI-64) address format specified by IEEE). However, the EUI-64 can be spoofed; therefore, any node connected to the subnet and aware of a registered-address-to-ROVR mapping could effectively fake the ROVR. This would allow an attacker to steal the address and redirect traffic for that address. <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> defines an Extended Address Registration Option (EARO) that transports alternate forms of ROVRs and is a prerequisite for this specification.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
   In this specification, a 6LN generates a cryptographic identifier (Crypto-ID) and places it in the ROVR field during the registration of one (or more) of its addresses with the 6LR(s). Proof of ownership of the Crypto-ID is passed with the first registration exchange to a new 6LR and enforced at the 6LR. The 6LR validates ownership of the
   Crypto-ID before it creates any new registration state or changes existing information.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
   The protected address registration protocol proposed in this document provides the same conceptual benefit as Source Address Validation Improvement (SAVI) <span>[<a href="#RFC7039" class="xref">RFC7039</a>]</span> in that only the owner of an IPv6 address may source packets with that address. As opposed to <span>[<a href="#RFC7039" class="xref">RFC7039</a>]</span>, which relies on snooping protocols, the protection provided by this document is based on a state that is installed and maintained in the network by the owner of the address. With this specification, a 6LN may use a 6LR for forwarding an IPv6 packet if and only if it has registered the address used as the source of the packet with that 6LR.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">

   With the 6LoWPAN adaptation layer in <span>[<a href="#RFC4944" class="xref">RFC4944</a>]</span> and <span>[<a href="#RFC6282" class="xref">RFC6282</a>]</span>, a
   6LN can obtain better compression for an IPv6
   address with an Interface ID (IID) that is derived
   from a Layer 2 (L2) address. Such compression is incompatible with "SEcure Neighbor Discovery (SEND") <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span> and "Cryptographically Generated Addresses (CGAs)" <span>[<a href="#RFC3972" class="xref">RFC3972</a>]</span>, since they derive the IID from cryptographic keys. This specification, on the other hand, separates the IID generation from cryptographic computations and can enable better compression.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<div id="bcp">
<section id="section-2.1">
        <h3 id="name-requirements-language">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-2.1-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-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lo">
<section id="section-2.2">
        <h3 id="name-background">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-background" class="section-name selfRef">Background</a>
        </h3>
<p id="section-2.2-1">
 The reader may get additional context for this specification from the following references:<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.2-2.1"> "SEcure Neighbor Discovery (SEND)" <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span>,<a href="#section-2.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-2.2"> "Cryptographically Generated Addresses (CGA)" <span>[<a href="#RFC3972" class="xref">RFC3972</a>]</span>,<a href="#section-2.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-2.3"> "Neighbor Discovery for IP version 6 (IPv6)" <span>[<a href="#RFC4861" class="xref">RFC4861</a>]</span> ,<a href="#section-2.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-2.4"> "IPv6 Stateless Address Autoconfiguration" <span>[<a href="#RFC4862" class="xref">RFC4862</a>]</span>, and<a href="#section-2.2-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-2.5"> "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" <span>[<a href="#RFC4919" class="xref">RFC4919</a>]</span>.<a href="#section-2.2-2.5" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="acronyms">
<section id="section-2.3">
        <h3 id="name-abbreviations">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-abbreviations" class="section-name selfRef">Abbreviations</a>
        </h3>
<p id="section-2.3-1"> This document uses the following abbreviations:<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-2.3-2">
          <dt id="section-2.3-2.1">6BBR:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.2"> 6LoWPAN Backbone Router<a href="#section-2.3-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.3">6LBR:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.4"> 6LoWPAN Border Router<a href="#section-2.3-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.5">6LN:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.6"> 6LoWPAN Node<a href="#section-2.3-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.7">6LR:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.8"> 6LoWPAN Router<a href="#section-2.3-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.9">AP-ND:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.10"> Address-Protected Neighbor Discovery<a href="#section-2.3-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.11">CGA:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.12"> Cryptographically Generated Address<a href="#section-2.3-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.13">DAD:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.14"> Duplicate Address Detection<a href="#section-2.3-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.15">EARO:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.16"> Extended Address Registration Option<a href="#section-2.3-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.17">ECC:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.18"> Elliptic Curve Cryptography<a href="#section-2.3-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.19">ECDH:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.20"> Elliptic Curve Diffie-Hellman<a href="#section-2.3-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.21">ECDSA:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.22"> Elliptic Curve Digital Signature Algorithm<a href="#section-2.3-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.23">EDAC:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.24"> Extended Duplicate Address Confirmation<a href="#section-2.3-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.25">EDAR:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.26"> Extended Duplicate Address Request<a href="#section-2.3-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.27">CIPO:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.28">Crypto-ID Parameters Option<a href="#section-2.3-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.29">LLN:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.30"> Low-Power and Lossy Network<a href="#section-2.3-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.31">NA:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.32">  Neighbor Advertisement<a href="#section-2.3-2.32" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.33">ND:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.34">  Neighbor Discovery<a href="#section-2.3-2.34" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.35">NDP:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.36">  Neighbor Discovery Protocol<a href="#section-2.3-2.36" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.37">NDPSO:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.38"> Neighbor Discovery Protocol Signature Option<a href="#section-2.3-2.38" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.39">NS:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.40">  Neighbor Solicitation<a href="#section-2.3-2.40" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.41">ROVR:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.42"> Registration Ownership Verifier<a href="#section-2.3-2.42" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.43">RA:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.44"> Router Advertisement<a href="#section-2.3-2.44" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.45">RS:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.46"> Router Solicitation<a href="#section-2.3-2.46" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.47">RSAO:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.48"> RSA Signature Option<a href="#section-2.3-2.48" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.49">SHA:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.50"> Secure Hash Algorithm<a href="#section-2.3-2.50" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.51">SLAAC:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.52"> Stateless Address Autoconfiguration<a href="#section-2.3-2.52" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-2.53">TID:</dt>
          <dd style="margin-left: 5.0em" id="section-2.3-2.54"> Transaction ID<a href="#section-2.3-2.54" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
<section id="section-3">
      <h2 id="name-updating-rfc-8505">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-updating-rfc-8505" class="section-name selfRef">Updating RFC 8505</a>
      </h2>
<p id="section-3-1">
       <span><a href="https://www.rfc-editor.org/rfc/rfc8505#section-5.3" class="relref">Section 5.3</a> of [<a href="#RFC8505" class="xref">RFC8505</a>]</span> introduces the ROVR that is used to detect and reject duplicate registrations in the DAD process. The ROVR is a generic object that is designed for both backward compatibility and the capability to introduce new computation methods in the future. Using a Crypto-ID per this specification is the <span class="bcp14">RECOMMENDED</span> method. <a href="#sec-col" class="xref">Section 7.5</a> discusses collisions when heterogeneous methods to compute the ROVR field coexist inside a network.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
        This specification introduces a new identifier called a Crypto-ID that is transported in the ROVR field and used to indirectly prove the ownership of an address that is being registered by means of <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>. The
        Crypto-ID is derived from a cryptographic public key and additional parameters.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">
        The overall mechanism requires the support of Elliptic Curve Cryptography (ECC) and a hash function as detailed in <a href="#ndpso-generation" class="xref">Section 6.2</a>. To enable the verification of the proof, the Registering Node needs to supply certain parameters including a nonce and a signature that will demonstrate that the node possesses the private key corresponding to the public key used to build the Crypto-ID.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4"> The elliptic curves and the hash functions listed in <a href="#cryptotypetable" class="xref">Table 1</a> in <a href="#cryptotypereg" class="xref">Section 8.2</a> can
    be used with this specification; more may be added in the future
    to the corresponding IANA registry. The cryptographic algorithms used (including the curve and the representation conventions) are signaled by the Crypto-Type field in a new IPv6 ND Crypto-ID Parameters Option (CIPO) (see <a href="#cryptoidopt" class="xref">Section 4.3</a>) that contains the parameters that are necessary for address validation.
    A new NDP Signature Option (<a href="#ndpso" class="xref">Section 4.4</a>) is also specified in this document to carry the resulting signature. A Nonce Option <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span> is added in the NA(EARO) that is used to request the validation, and all three options are needed in the NS(EARO) that provides the validation.<a href="#section-3-4" class="pilcrow">¶</a></p>
</section>
<div id="cryptoifldg">
<section id="section-4">
      <h2 id="name-new-fields-and-options">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-new-fields-and-options" class="section-name selfRef">New Fields and Options</a>
      </h2>
<div id="cryptoidalg">
<section id="section-4.1">
        <h3 id="name-new-crypto-id">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-new-crypto-id" class="section-name selfRef">New Crypto-ID</a>
        </h3>
<p id="section-4.1-1">
 The Crypto-ID is transported in the ROVR field of the EARO and the Extended Duplicate Address Request (EDAR) message and is associated with the Registered Address at the 6LR and the 6LBR.
 The ownership of a Crypto-ID can be demonstrated by cryptographic mechanisms, and by association, the ownership of the Registered Address can be ascertained.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">
 A node in possession of the necessary cryptographic primitives <span class="bcp14">SHOULD</span> use Crypto-ID by default as ROVR in its registrations. Whether a ROVR is a Crypto-ID is indicated by a new "C" flag in the EARO of the NS(EARO) message.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">

   The Crypto-ID is derived from the public key and a modifier as follows:<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4.1-4">
   <li id="section-4.1-4.1">The hash function used internally by the signature scheme and indicated by the Crypto-Type (see <a href="#cryptotypetable" class="xref">Table 1</a> in <a href="#cryptotypereg" class="xref">Section 8.2</a>)
   is applied to the CIPO. Note that all the reserved and padding bits <span class="bcp14">MUST</span> be set to zero.<a href="#section-4.1-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.1-4.2"> The leftmost bits of the resulting hash, up to the desired size, are used as the Crypto-ID.<a href="#section-4.1-4.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-4.1-5">
   At the time of this writing, a minimal size for the Crypto-ID of 128 bits is <span class="bcp14">RECOMMENDED</span> unless backward compatibility is needed <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> (in which case it is at least 64 bits). The size of the Crypto-ID is likely to increase in the future.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cryptoEARO">
<section id="section-4.2">
        <h3 id="name-updated-earo">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-updated-earo" class="section-name selfRef">Updated EARO</a>
        </h3>
<p id="section-4.2-1">
    This specification updates the EARO to enable the use of the ROVR field to transport the Crypto-ID. The resulting format is as follows:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<span id="name-enhanced-address-registrati"></span><div id="crypto-fig">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-4.2-2.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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Length    |    Status     |    Opaque     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Rsvd |C| I |R|T|     TID       |     Registration Lifetime     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
 ...            Registration Ownership Verifier (ROVR)           ...
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-enhanced-address-registrati" class="selfRef">Enhanced Address Registration Option</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4.2-3">
          <dt id="section-4.2-3.1">Type:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.2">
     33<a href="#section-4.2-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.3">Length:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.4">
      Defined in <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> and copied in the "EARO Length"
        field in the associated CIPO.<a href="#section-4.2-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.5">Status:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.6">
      Defined in <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>.<a href="#section-4.2-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.7">Opaque:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.8">
      Defined in <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>.<a href="#section-4.2-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.9">Rsvd (Reserved):</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.10">3-bit unsigned integer.
        It <span class="bcp14">MUST</span> be set to zero by the sender and <span class="bcp14">MUST</span> be ignored by the receiver.<a href="#section-4.2-3.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.11">C:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.12">
       This "C" flag is set to indicate that the ROVR field contains a Crypto-ID and that the 6LN <span class="bcp14">MAY</span> be challenged for ownership as specified in this document.<a href="#section-4.2-3.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.13">I, R, T:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.14">
     Defined in <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>.<a href="#section-4.2-3.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.15">TID and Registration Lifetime:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.16">
     Defined in <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>.<a href="#section-4.2-3.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.17">Registration Ownership Verifier (ROVR):</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.18">
     When the "C" flag is set, this field contains a Crypto-ID.<a href="#section-4.2-3.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.2-4">
 This specification uses the status codes "Validation Requested" and
 "Validation Failed", which are defined in <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">
 This specification does not define any new status codes.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cryptoidopt">
<section id="section-4.3">
        <h3 id="name-crypto-id-parameters-option">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-crypto-id-parameters-option" class="section-name selfRef">Crypto-ID Parameters Option</a>
        </h3>
<p id="section-4.3-1">
 This specification defines the CIPO.
    The CIPO carries the parameters used to form a Crypto-ID.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">
    In order to provide cryptographic agility <span>[<a href="#RFC7696" class="xref">BCP201</a>]</span>, this specification supports different elliptic-curve-based signature schemes,
 indicated by a Crypto-Type field:<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-3.1">
    The ECDSA256 signature scheme, which uses ECDSA with the NIST P-256 curve <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span> and the hash function SHA-256 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span> internally,
 <span class="bcp14">MUST</span> be supported by all implementations.<a href="#section-4.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.2">
    The Ed25519 signature scheme, which uses the Pure Edwards-Curve Digital Signature Algorithm (PureEdDSA) <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span> with the twisted Edwards curve Edwards25519
 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span> and the hash function SHA-512 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span> internally, <span class="bcp14">MAY</span> be supported as an alternative.<a href="#section-4.3-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.3">
    The ECDSA25519 signature scheme, which uses ECDSA <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span> with the Weierstrass curve Wei25519 (see <a href="#curves" class="xref">Appendix B.4</a>) and the hash function
 SHA-256 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span> internally, <span class="bcp14">MAY</span> also be supported.<a href="#section-4.3-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.3-4"> This specification uses signature schemes that target similar cryptographic strength but rely on different curves, hash functions, signature algorithms, and/or
 representation conventions. Future specification may extend this to different cryptographic algorithms and key sizes, e.g., to provide better security properties or a
 simpler implementation.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<span id="name-crypto-id-parameters-option-2"></span><div id="cgapar-fig">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-4.3-5.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |Reserved1|  Public Key Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Crypto-Type  | Modifier      |  EARO Length  |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               |
   .                                                               .
   .                  Public Key (variable length)                 .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                           Padding                             .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-crypto-id-parameters-option-2" class="selfRef">Crypto-ID Parameters Option</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4.3-6">
          <dt id="section-4.3-6.1">Type:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-6.2"> 8-bit unsigned integer.
       IANA has assigned value 39; see <a href="#nexndopt" class="xref">Table 2</a>.<a href="#section-4.3-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-6.3">Length:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-6.4">
       8-bit unsigned integer. The length of the option in units of 8 octets.<a href="#section-4.3-6.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-6.5">Reserved1:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-6.6"> 5-bit unsigned integer.
        It <span class="bcp14">MUST</span> be set to zero by the sender and <span class="bcp14">MUST</span> be ignored by the receiver.<a href="#section-4.3-6.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-6.7">Public Key Length:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-6.8">
       11-bit unsigned integer. The length of the Public Key field in bytes. The actual length depends on the Crypto-Type value and how the public key is represented.
 The valid values with this document are provided in <a href="#cryptotypetable" class="xref">Table 1</a>.<a href="#section-4.3-6.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-6.9">Crypto-Type:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-6.10">8-bit unsigned integer.
       The type of cryptographic algorithm used in calculation of the Crypto-ID
        indexed by IANA in the "Crypto-Types" subregistry in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry
        (see <a href="#cryptotypereg" class="xref">Section 8.2</a>).<a href="#section-4.3-6.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-6.11">Modifier:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-6.12">
       8-bit unsigned integer. Set to an arbitrary value by the creator of the Crypto-ID. The role of the modifier is to enable the formation of multiple Crypto-IDs from the same key pair. This reduces the traceability and, thus, improves the privacy of a constrained node without requiring many key pairs.<a href="#section-4.3-6.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-6.13">EARO Length:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-6.14"> 8-bit unsigned integer.
      The option length of the EARO that contains the Crypto-ID associated with the CIPO.<a href="#section-4.3-6.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-6.15">Public Key:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-6.16"> A variable-length field; the size is indicated in the Public Key Length field.<a href="#section-4.3-6.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-6.17">Padding:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-6.18">
        A variable-length field that completes the Public Key field to align to the next 8-byte boundary. It <span class="bcp14">MUST</span> be set to zero by the sender and <span class="bcp14">MUST</span> be ignored by the receiver.<a href="#section-4.3-6.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.3-7">
 The implementation of multiple hash functions in a constrained device may
 consume excessive amounts of program memory. This specification enables the use of the same hash function SHA-256 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span> for two of the three supported ECC-based signature schemes.
    Some code factorization is also possible for the ECC computation itself.<a href="#section-4.3-7" class="pilcrow">¶</a></p>
<p id="section-4.3-8">
 <span>[<a href="#I-D.ietf-lwig-curve-representations" class="xref">CURVE-REPR</a>]</span> provides information
 on how to represent Montgomery curves and (twisted) Edwards curves as curves in short-Weierstrass form, and it illustrates how this can be used to implement elliptic curve computations using existing implementations that already provide, e.g., ECDSA and ECDH using NIST <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span> prime curves. For more details on representation conventions, refer to
 <a href="#reprconv" class="xref">Appendix B</a>.<a href="#section-4.3-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ndpso">
<section id="section-4.4">
        <h3 id="name-ndp-signature-option">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-ndp-signature-option" class="section-name selfRef">NDP Signature Option</a>
        </h3>
<p id="section-4.4-1">
 This specification defines the NDP Signature Option (NDPSO). The NDPSO carries the signature that proves the ownership of the Crypto-ID and validates the address being registered. The format of the NDPSO is illustrated in <a href="#ndpso-fig" class="xref">Figure 3</a>.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
    As opposed to the RSA Signature Option (RSAO) defined in <span><a href="https://www.rfc-editor.org/rfc/rfc3971#section-5.2" class="relref">Section 5.2</a> of SEND [<a href="#RFC3971" class="xref">RFC3971</a>]</span>, the NDPSO does not have a key hash field. Instead, the leftmost 128 bits of the ROVR field in the EARO are used as hash to retrieve the CIPO that contains the key material used for signature verification, left-padded if needed.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">
    Another difference is that the NDPSO signs a fixed set of fields as opposed to all options that appear prior to it in the ND message that bears the signature. This allows a CIPO that the 6LR already received to be omitted, at the expense of the capability to add arbitrary options that would be signed with an RSAO.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">
    An ND message that carries an NDPSO <span class="bcp14">MUST</span> have one and only one EARO. The EARO <span class="bcp14">MUST</span> contain a Crypto-ID in the ROVR field, and the Crypto-ID <span class="bcp14">MUST</span> be associated with the key pair used for the digital signature in the NDPSO.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<p id="section-4.4-5">
    The CIPO may be present in the same message as the NDPSO. If it is not present, it can be found in an abstract table that was created by a previous message and indexed by the hash.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
<span id="name-ndp-signature-option-2"></span><div id="ndpso-fig">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-4.4-6.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |Reserved1|  Signature Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Reserved2                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .          Digital Signature  (variable length)                 .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                           Padding                             .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-ndp-signature-option-2" class="selfRef">NDP Signature Option</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4.4-7">
          <dt id="section-4.4-7.1">Type:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-7.2">
       IANA has assigned value 40; see <a href="#nexndopt" class="xref">Table 2</a>.<a href="#section-4.4-7.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-7.3">Length:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-7.4">
       8-bit unsigned integer. The length of the option in units of 8 octets.<a href="#section-4.4-7.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-7.5">Reserved1:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-7.6"> 5-bit unsigned integer.
        It <span class="bcp14">MUST</span> be set to zero by the sender and <span class="bcp14">MUST</span> be ignored by the receiver.<a href="#section-4.4-7.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-7.7">Digital Signature Length:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-7.8">
       11-bit unsigned integer. The length of the Digital Signature field in bytes.<a href="#section-4.4-7.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-7.9">Reserved2:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-7.10"> 32-bit unsigned integer.
        It <span class="bcp14">MUST</span> be set to zero by the sender and <span class="bcp14">MUST</span> be ignored by the receiver.<a href="#section-4.4-7.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-7.11">Digital Signature:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-7.12">
       A variable-length field containing the digital signature. The length and computation of the digital signature both depend on the Crypto-Type, which is found in the associated CIPO; see <a href="#reprconv" class="xref">Appendix B</a>.
        For the values of the Crypto-Type defined in this specification, and for future values of the Crypto-Type unless specified otherwise, the signature is computed as detailed in <a href="#ndpso-generation" class="xref">Section 6.2</a>.<a href="#section-4.4-7.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-7.13">Padding:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-7.14">
        A variable-length field completing the Digital Signature field to align to the next 8-byte boundary. It <span class="bcp14">MUST</span> be set to zero by the sender and <span class="bcp14">MUST</span> be ignored by the receiver.<a href="#section-4.4-7.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="CIO">
<section id="section-4.5">
        <h3 id="name-extensions-to-the-capabilit">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-extensions-to-the-capabilit" class="section-name selfRef">Extensions to the Capability Indication Option</a>
        </h3>
<p id="section-4.5-1">
 This specification defines one new capability bit in the 6LoWPAN Capability Indication Option (6CIO),
 as defined by <span>[<a href="#RFC7400" class="xref">RFC7400</a>]</span>, for use by the 6LR and 6LBR in IPv6 ND RA messages.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<span id="name-new-capability-bit-in-the-6"></span><div id="fig6CIO">
<figure id="figure-4">
          <div class="artwork art-text alignLeft" id="section-4.5-2.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length = 1  |   Reserved      |A|D|L|B|P|E|G|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-new-capability-bit-in-the-6" class="selfRef">New Capability Bit in the 6CIO</a>
          </figcaption></figure>
</div>
<p id="section-4.5-3"> New Option Field:<a href="#section-4.5-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.5-4">
          <dt id="section-4.5-4.1">A:</dt>
          <dd style="margin-left: 1.5em" id="section-4.5-4.2"> 1-bit flag. Set to indicate that AP-ND is globally activated in the network.<a href="#section-4.5-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.5-5">
    The "A" flag is set by the 6LBR that serves the network and is propagated by the 6LRs.
    It is typically turned on when all 6LRs are migrated to this specification.<a href="#section-4.5-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-5">
      <h2 id="name-protocol-scope">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-protocol-scope" class="section-name selfRef">Protocol Scope</a>
      </h2>
<p id="section-5-1">
      The scope of the protocol specified here is a 6LoWPAN LLN, typically a stub network connected to a larger IP network via a border router called a 6LBR per <span>[<a href="#RFC6775" class="xref">RFC6775</a>]</span>. A 6LBR has sufficient capability to satisfy the needs of DAD.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
      The 6LBR maintains registration state for all devices in its attached LLN.  Together with the first-hop router (the 6LR), the 6LBR assures uniqueness and grants ownership of an IPv6 address before it can be used in the LLN. This is in contrast to a traditional network that relies on IPv6 address autoconfiguration <span>[<a href="#RFC4862" class="xref">RFC4862</a>]</span>, where there is no guarantee of ownership from the network, and each IPv6 Neighbor Discovery packet must be individually secured <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span>.<a href="#section-5-2" class="pilcrow">¶</a></p>
<span id="name-basic-configuration"></span><div id="figco">
<figure id="figure-5">
        <div class="artwork art-text alignLeft" id="section-5-3.1">
<pre>
              ---+-------- ............
                 |      External Network
                 |
              +-----+
              |     | 6LBR
              +-----+
            o    o   o
     o     o   o     o
        o   o LLN   o    o     o
           o     o
      o       o    o(6LR)
                   ^
    o      o       | LLN link
         o     o   v
                   o(6LN)
           o
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-basic-configuration" class="selfRef">Basic Configuration</a>
        </figcaption></figure>
</div>
<p id="section-5-4">
      In a mesh network, the 6LR is directly connected to the host device. This specification mandates that the peer-wise L2 security is deployed so that all the packets from a particular host are protected. The 6LR may be multiple hops away from the 6LBR. Packets are routed between the 6LR and the 6LBR via other 6LRs.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">
       This specification mandates that all the LLN links between the 6LR and the 6LBR are protected so that a packet that was validated by the first 6LR can be safely routed by other on-path 6LRs to the 6LBR.<a href="#section-5-5" class="pilcrow">¶</a></p>
</section>
<section id="section-6">
      <h2 id="name-protocol-flows">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-protocol-flows" class="section-name selfRef">Protocol Flows</a>
      </h2>
<p id="section-6-1">
  The 6LR/6LBR ensures first come, first served by storing the ROVR associated to the address being registered upon the first registration and rejecting a registration with a different ROVR value. A 6LN can claim any address as long as it is the first to make that claim. After a successful registration, the 6LN becomes the owner of the Registered Address, and the address is bound to the ROVR value in the 6LR/6LBR registry.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
    This specification protects the ownership of the address at the
    first hop (the edge). Its use in a network is signaled by the "A"
    flag in the 6CIO. The flag is set by the 6LBR and propagated
    unchanged by the 6LRs. Once every node in the network is upgraded to support this specification, the "A" flag can be set to turn the protection on globally.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">
  The 6LN places a cryptographic identifier, the Crypto-ID, in the ROVR that is associated with the address at the first registration, enabling the 6LR to later challenge it to verify that it is the original Registering Node. The challenge may happen at any time at the discretion of the 6LR and the 6LBR. A valid registration in the 6LR or the 6LBR <span class="bcp14">MUST NOT</span> be altered until the challenge is complete.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">
     When the "A" flag in a subnet is set, the 6LR <span class="bcp14">MUST</span> challenge the 6LN before it creates a Binding with the "C" flag set in the EARO. The 6LR <span class="bcp14">MUST</span> also challenge the 6LN when a new registration attempts to change a parameter of an already validated Binding for that 6LN, for instance, its Source link-layer address. Such verification protects against an attacker that attempts to steal the address of an honest node.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">
     The 6LR <span class="bcp14">MUST</span> indicate to the 6LBR that it performed a successful validation by setting a status code of 5 ("Validation Requested") in the EDAR. Upon a subsequent EDAR from a new 6LR with a status code that is not 5 for a validated Binding, the 6LBR <span class="bcp14">MUST</span> indicate to the new 6LR that it needs to challenge the 6LN using a status code of 5 in the Extended Duplicate Address Confirmation (EDAC).<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">

     The 6LR <span class="bcp14">MUST</span> challenge the 6LN when the 6LBR signals to do so, which is done with an EDAC message with a status code of 5. The EDAC is echoed by the 6LR in the NA(EARO) back to the Registering Node. The 6LR <span class="bcp14">SHOULD</span> also challenge all its attached 6LNs at the time the 6LBR turns the "A" flag on in the 6CIO in orders to detect an issue immediately.<a href="#section-6-6" class="pilcrow">¶</a></p>
<p id="section-6-7">If the 6LR does not support the Crypto-Type, it <span class="bcp14">MUST</span> reply with an EARO status code of 10 "Validation Failed" without a challenge. In that case, the 6LN may try another Crypto-Type until it falls back to Crypto-Type 0, which <span class="bcp14">MUST</span> be supported by all 6LRs.<a href="#section-6-7" class="pilcrow">¶</a></p>
<p id="section-6-8">
     A node may use more than one IPv6 address at the same time. The separation of the address and the cryptographic material avoids the need for the constrained device to compute multiple keys for multiple addresses. The 6LN <span class="bcp14">MAY</span> use the same Crypto-ID to prove the ownership of multiple IPv6 addresses. The 6LN <span class="bcp14">MAY</span> also derive multiple Crypto-IDs from the same key pair by changing the modifier.<a href="#section-6-8" class="pilcrow">¶</a></p>
<div id="first">
<section id="section-6.1">
        <h3 id="name-first-exchange-with-a-6lr">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-first-exchange-with-a-6lr" class="section-name selfRef">First Exchange with a 6LR</a>
        </h3>
<p id="section-6.1-1">
     A 6LN registers to a 6LR that is one hop away from it with the "C" flag set in the EARO, indicating that the ROVR field contains a Crypto-ID. The Target Address in the NS message indicates the IPv6 address that the 6LN is trying to register <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>. The on-link (local) protocol interactions are shown in <a href="#Dynamic-fig" class="xref">Figure 6</a>. If the 6LR does not have a state with the 6LN that is consistent with the NS(EARO), then it replies with a challenge NA(EARO, status=Validation Requested) that contains a Nonce Option (shown as NonceLR in <a href="#Dynamic-fig" class="xref">Figure 6</a>).<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<span id="name-on-link-protocol-operation"></span><div id="Dynamic-fig">
<figure id="figure-6">
          <div class="artwork art-text alignLeft" id="section-6.1-2.1">
<pre>
    6LN                                                     6LR
     |                                                       |
     |&lt;------------------------- RA -------------------------|
     |                                                       | ^
     |---------------- NS with EARO (Crypto-ID) ------------&gt;| |
     |                                                       | option
     |&lt;- NA with EARO(status=Validation Requested), NonceLR  | |
     |                                                       | v
     |------- NS with EARO, CIPO, NonceLN and NDPSO --------&gt;|
     |                                                       |
     |&lt;------------------- NA with EARO ---------------------|
     |                                                       |
                               ...
     |                                                       |
     |--------------- NS with EARO (Crypto-ID) -------------&gt;|
     |                                                       |
     |&lt;------------------- NA with EARO ---------------------|
     |                                                       |
                               ...
     |                                                       |
     |--------------- NS with EARO (Crypto-ID) -------------&gt;|
     |                                                       |
     |&lt;------------------- NA with EARO ---------------------|
     |                                                       |
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-on-link-protocol-operation" class="selfRef">On-Link Protocol Operation</a>
          </figcaption></figure>
</div>
<p id="section-6.1-3">
        The Nonce Option contains a nonce value that, to the extent  possible for the implementation, was never used before. This specification inherits the idea from <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span> that the nonce is a random value. Ideally, an implementation uses an unpredictable cryptographically random value <span>[<a href="#RFC4086" class="xref">BCP106</a>]</span>. But that may be impractical in some LLN scenarios with resource-constrained devices.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4"> Alternatively, the device may use an always-incrementing value saved in the same stable storage as the key, so they are lost together, and start at a best-effort random value as either the nonce value or a component to its computation.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">
     The 6LN replies to the challenge with an NS(EARO) that includes the Nonce Option (shown as NonceLN in <a href="#Dynamic-fig" class="xref">Figure 6</a>), the CIPO (<a href="#cryptoidopt" class="xref">Section 4.3</a>), and the NDPSO containing the signature. Both nonces are included in the signed material. This provides a "contributory behavior" that results in better security even when the nonces of one party are not generated as specified.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<p id="section-6.1-6">
        The 6LR <span class="bcp14">MUST</span> store the information associated with a Crypto-ID on the first NS exchange where it appears in a fashion that the CIPO parameters can be retrieved from the Crypto-ID alone.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
<p id="section-6.1-7">The steps for the registration to the 6LR are as follows:<a href="#section-6.1-7" class="pilcrow">¶</a></p>
<p id="section-6.1-8">
            Upon the first exchange with a 6LR, a 6LN will be challenged to prove ownership of the Crypto-ID and the Target Address being registered in the Neighbor Solicitation message. When a 6LR receives an NS(EARO) registration with a new Crypto-ID as a ROVR, and unless the registration is rejected for another reason, it <span class="bcp14">MUST</span> challenge by responding with an NA(EARO) with a status code of "Validation Requested".<a href="#section-6.1-8" class="pilcrow">¶</a></p>
<p id="section-6.1-9">
            Upon receiving a first NA(EARO) with a status code of "Validation Requested" from a 6LR, the Registering Node <span class="bcp14">SHOULD</span> retry its registration with a CIPO (<a href="#cryptoidopt" class="xref">Section 4.3</a>) that contains all the necessary material for building the Crypto-ID, the NonceLN that it generated, and the NDP Signature Option (<a href="#ndpso" class="xref">Section 4.4</a>) that proves its ownership of the Crypto-ID and intent of registering the Target Address. In subsequent revalidation with the same 6LR, the 6LN <span class="bcp14">MAY</span> try to omit the CIPO to save bandwidth, with the expectation that the 6LR saved it. If the validation fails and it gets challenged again, then it <span class="bcp14">SHOULD</span> add the CIPO again.<a href="#section-6.1-9" class="pilcrow">¶</a></p>
<p id="section-6.1-10">
            In order to validate the ownership, the 6LR performs the
     same steps as the 6LN and rebuilds the Crypto-ID based on
     the parameters in the CIPO. If the rebuilt Crypto-ID
     matches the ROVR, the 6LN also verifies the signature
     contained in the NDPSO. At that point, if the signature in the NDPSO can be verified, then the validation succeeds. Otherwise, the validation fails.<a href="#section-6.1-10" class="pilcrow">¶</a></p>
<p id="section-6.1-11">
            If the 6LR fails to validate the signed NS(EARO), it responds with a status code of "Validation Failed". After receiving an NA(EARO) with a status code of "Validation Failed",
            the Registering Node <span class="bcp14">SHOULD</span> try an alternate Crypto-Type; even if Crypto-Type 0 fails, it may try to register a different address in the NS message.<a href="#section-6.1-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ndpso-generation">
<section id="section-6.2">
        <h3 id="name-ndpso-generation-and-verifi">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-ndpso-generation-and-verifi" class="section-name selfRef">NDPSO Generation and Verification</a>
        </h3>
<p id="section-6.2-1">
      The signature generated by the 6LN to provide proof of ownership of the
  private key is carried in the NDPSO.
  It is generated by the 6LN in a fashion that depends on the Crypto-Type
  (see <a href="#cryptotypetable" class="xref">Table 1</a> in
  <a href="#cryptotypereg" class="xref">Section 8.2</a>) chosen by the 6LN as follows:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-2.1">
            <p id="section-6.2-2.1.1"> Form the message to be signed, by concatenating the following byte-strings in the order listed:<a href="#section-6.2-2.1.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-6.2-2.1.2">
         <li id="section-6.2-2.1.2.1">The 128-bit Message Type tag <span>[<a href="#RFC3972" class="xref">RFC3972</a>]</span> (in network byte order).
                For this specification, the tag is given in <a href="#cgam" class="xref">Section 8.1</a>.
               (The tag value has been generated by the editor of this specification on <span>&lt;<a href="https://www.random.org">https://www.random.org</a>&gt;</span>.)<a href="#section-6.2-2.1.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-2.1.2.2">The CIPO.<a href="#section-6.2-2.1.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-2.1.2.3">The 16-byte Target Address (in network byte order) sent in the NS message. It is the address that the 6LN is registering with the 6LR and 6LBR.<a href="#section-6.2-2.1.2.3" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-2.1.2.4">The NonceLR received from the 6LR (in
 network byte order) in the NA message. The
 nonce is at least 6 bytes long as defined in <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span>.<a href="#section-6.2-2.1.2.4" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-2.1.2.5">The NonceLN sent from the 6LN (in network
 byte order). The nonce is at least 6 bytes long as defined in <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span>.<a href="#section-6.2-2.1.2.5" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-2.1.2.6">The 1-byte option length of the EARO containing the Crypto-ID.<a href="#section-6.2-2.1.2.6" class="pilcrow">¶</a>
</li>
            </ol>
</li>
          <li class="normal" id="section-6.2-2.2">
          Apply the signature algorithm specified by the Crypto-Type using the private key.<a href="#section-6.2-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.2-3">
      Upon receiving the NDPSO and CIPO options, the 6LR first checks that the EARO Length in the CIPO matches the length of the EARO. If so, it regenerates the Crypto-ID based on the CIPO to make sure that the leftmost bits up to the size of the ROVR match.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
<p id="section-6.2-4">
         If, and only if, the check is successful, it tries to verify
  the signature in the NDPSO using the following steps:<a href="#section-6.2-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-5.1">
            <p id="section-6.2-5.1.1">Form the message to be verified, by concatenating the following byte-strings in the order listed:<a href="#section-6.2-5.1.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-6.2-5.1.2">
                <li id="section-6.2-5.1.2.1">The 128-bit Message Type tag given in <a href="#cgam" class="xref">Section 8.1</a> (in network byte order).<a href="#section-6.2-5.1.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-5.1.2.2">The CIPO.<a href="#section-6.2-5.1.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-5.1.2.3">The 16-byte Target Address (in network byte order) received in the NS message. It is the address that the 6LN is registering with the 6LR and 6LBR.<a href="#section-6.2-5.1.2.3" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-5.1.2.4">The NonceLR sent in the NA message. The nonce is
 at least 6 bytes long as defined in <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span>.<a href="#section-6.2-5.1.2.4" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-5.1.2.5">The NonceLN received from the 6LN (in network byte
 order) in the NS message. The nonce is at least 6 bytes long as defined in <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span>.<a href="#section-6.2-5.1.2.5" class="pilcrow">¶</a>
</li>
              <li id="section-6.2-5.1.2.6">The 1-byte EARO Length received in the CIPO.<a href="#section-6.2-5.1.2.6" class="pilcrow">¶</a>
</li>
            </ol>
</li>
          <li class="normal" id="section-6.2-5.2">
          Verify the signature on this message with the public key in the CIPO and the locally computed values using the signature algorithm specified by the Crypto-Type. If the verification succeeds, the 6LR propagates the information to the 6LBR using an EDAR/EDAC flow.<a href="#section-6.2-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-5.3">
          Due to the first-come, first-served nature of the registration, if the address is not registered to the 6LBR, then flow succeeds and both the 6LR and 6LBR add the state information about the Crypto-ID and Target Address being registered to their respective abstract databases.<a href="#section-6.2-5.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="mhopo">
<section id="section-6.3">
        <h3 id="name-multi-hop-operation">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-multi-hop-operation" class="section-name selfRef">Multi-Hop Operation</a>
        </h3>
<p id="section-6.3-1">
     A new 6LN that joins the network autoconfigures an address and performs an initial registration to a neighboring 6LR with an NS message that carries an EARO <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">
     In a multi-hop 6LoWPAN, the registration with Crypto-ID is propagated to 6LBR as shown in <a href="#figReg" class="xref">Figure 7</a>, which illustrates the
     registration flow all the way to a 6LoWPAN Backbone Router (6BBR)
    <span>[<a href="#RFC8929" class="xref">RFC8929</a>]</span>.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
<span id="name-re-registration-flow"></span><div id="figReg">
<figure id="figure-7">
          <div class="artwork art-text alignLeft" id="section-6.3-3.1">
<pre>
     6LN              6LR             6LBR            6BBR
      |                |               |                |
      |   NS(EARO)     |               |                |
      |---------------&gt;|               |                |
      |                | Extended DAR  |                |
      |                |--------------&gt;|                |
      |                |               | proxy NS(EARO) |
      |                |               |---------------&gt;|
      |                |               |                | NS(DAD)
      |                |               |                | ------&gt;
      |                |               |                |
      |                |               |                | &lt;wait&gt;
      |                |               |                |
      |                |               | proxy NA(EARO) |
      |                |               |&lt;---------------|
      |                | Extended DAC  |                |
      |                |&lt;--------------|                |
      |   NA(EARO)     |               |                |
      |&lt;---------------|               |                |
      |                |               |                |
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-re-registration-flow" class="selfRef">(Re-)Registration Flow</a>
          </figcaption></figure>
</div>
<p id="section-6.3-4">
     The 6LR and the 6LBR communicate using ICMPv6 EDAR and EDAC messages <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> as shown in <a href="#figReg" class="xref">Figure 7</a>.
     This specification extends EDAR/EDAC messages to carry cryptographically generated ROVR.<a href="#section-6.3-4" class="pilcrow">¶</a></p>
<p id="section-6.3-5">
     The assumption is that the 6LR and the 6LBR maintain a security association to authenticate and protect the integrity of the EDAR and EDAC messages, so there is no need to propagate the proof of ownership to the 6LBR. The 6LBR implicitly trusts that the 6LR performs the verification when the 6LBR requires it, and if there is no further exchange from the 6LR to remove the state, the verification succeeded.<a href="#section-6.3-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-brown-field">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-brown-field" class="section-name selfRef">Brown Field</a>
        </h3>
<p id="section-7.1-1">
    Only 6LRs that are upgraded to this specification are capable of challenging a registration and avoiding an attack. In a brown (mixed) network, an attacker may attach to a legacy 6LR and fool the 6LBR. So even if the "A" flag could be set at any time to
    test the protocol operation, the security will only be effective when all the 6LRs are upgraded.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-7.2">
        <h3 id="name-threats-identified-in-rfc-3">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-threats-identified-in-rfc-3" class="section-name selfRef">Threats Identified in RFC 3971</a>
        </h3>
<p id="section-7.2-1">
        Observations regarding the following threats to the local network in <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span> also apply to this specification.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.2-2">
          <dt id="section-7.2-2.1">Neighbor Solicitation/Advertisement Spoofing:</dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.2">
         Threats in <span><a href="https://www.rfc-editor.org/rfc/rfc3971#section-9.2.1" class="relref">Section 9.2.1</a> of [<a href="#RFC3971" class="xref">RFC3971</a>]</span> apply. AP-ND counters the threats on NS(EARO) messages by requiring that the NDPSO and CIPO be present in these solicitations.<a href="#section-7.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.2-2.3">Duplicate Address Detection DoS Attack:</dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.4">
        Inside the LLN, duplicate addresses are sorted out using the ROVR. A different ROVR for the same Registered Address entails a rejection of the second registration <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>. DADs coming from the backbone network are not forwarded over the LLN to provide some protection against DoS attacks inside the resource-constrained part of the network. However, the EARO is present in the NS/NA messages exchanged over the backbone network. This protects against misinterpreting node movement as a duplication and enables the Backbone Routers to determine which subnet has the most recent registration <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> and is thus the best candidate to validate the registration <span>[<a href="#RFC8929" class="xref">RFC8929</a>]</span>.<a href="#section-7.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.2-2.5">Router Solicitation and Advertisement Attacks:</dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.6">
         This specification does not change the protection of RS and RA, which can still be protected by SEND.<a href="#section-7.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.2-2.7">Replay Attacks:</dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.8">
         Nonces should never repeat but they do not need to be unpredictable for secure operation. Using nonces (NonceLR and NonceLN) generated by both the 6LR and 6LN ensures a contributory behavior that provides an efficient protection against replay attacks of the challenge/response flow. The quality of the protection by a random nonce depends on the random number generator.<a href="#section-7.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.2-2.9">Neighbor Discovery DoS Attack:</dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.10">
         A rogue node that can access the L2 network may form many addresses and register them using AP-ND. The perimeter of the attack is all the 6LRs in range of the attacker. The 6LR <span class="bcp14">MUST</span> protect itself against overflows and reject excessive registration with a status code of 2 "Neighbor Cache Full". This effectively blocks another (honest) 6LN from registering to the same 6LR, but the 6LN may register to other 6LRs that are in its range but not in that of the attacker.<a href="#section-7.2-2.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<section id="section-7.3">
        <h3 id="name-related-to-6lowpan-nd">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-related-to-6lowpan-nd" class="section-name selfRef">Related to 6LoWPAN ND</a>
        </h3>
<p id="section-7.3-1">
     The threats and mitigations discussed in 6LoWPAN ND
 <span>[<a href="#RFC6775" class="xref">RFC6775</a>]</span> <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> also
 apply here, in particular, denial-of-service (DoS) attacks against the registry at the 6LR or 6LBR.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2">
            Secure ND <span>[<a href="#RFC3971" class="xref">RFC3971</a>]</span> forces the IPv6 address to be cryptographic since it integrates the CGA as the IID in the IPv6 address. In contrast, this specification saves about 1 KB in every NS/NA message. Also, this specification separates the cryptographic identifier from the registered IPv6 address so that a node can have more than one IPv6 address protected by the same cryptographic identifier.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
<p id="section-7.3-3">
            With this specification, the 6LN can freely form its IPv6 address(es) in any fashion, thereby enabling either 6LoWPAN compression for IPv6 addresses that are derived from L2 addresses or temporary addresses that cannot be compressed, e.g., formed pseudorandomly and released in relatively short cycles for privacy reasons <span>[<a href="#RFC8064" class="xref">RFC8064</a>]</span><span>[<a href="#RFC8065" class="xref">RFC8065</a>]</span>.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
<p id="section-7.3-4">
            This specification provides added protection for addresses that are obtained following due procedure <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> but does not constrain the way the addresses are formed or the number of addresses that are used in parallel by a same entity. An attacker may still perform a DoS attack against the registry at the 6LR or 6LBR or attempt to deplete the pool of available addresses at L2 or L3.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
</section>
<section id="section-7.4">
        <h3 id="name-compromised-6lr">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-compromised-6lr" class="section-name selfRef">Compromised 6LR</a>
        </h3>
<p id="section-7.4-1">
        This specification distributes the challenge and its validation at the edge of the network, between the 6LN and its 6LR. This protects against DoS attacks targeted at that central 6LBR. This also saves back-and-forth exchanges across a potentially large and constrained network.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2">
        The downside is that the 6LBR needs to trust the 6LR to perform the checking adequately, and the communication between the 6LR and the 6LBR must be protected to avoid tampering with the result of the validation.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
<p id="section-7.4-3">
       If a 6LR is compromised, and provided that it knows the ROVR field used by the real owner of the address, the 6LR may pretend that the owner has moved, is now attached to it, and has successfully passed the Crypto-ID validation. The 6LR may then attract and inject traffic at will on behalf of that address, or let an attacker take ownership of the address.<a href="#section-7.4-3" class="pilcrow">¶</a></p>
</section>
<div id="sec-col">
<section id="section-7.5">
        <h3 id="name-rovr-collisions">
<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-rovr-collisions" class="section-name selfRef">ROVR Collisions</a>
        </h3>
<p id="section-7.5-1">

     A collision of ROVRs (i.e., the Crypto-ID in this specification) is possible, but it is a rare event. Assuming that the hash used for calculating the Crypto-ID is a well-behaved cryptographic hash, and, thus, random collisions are the only ones possible, if n = 2<sup>k</sup> is the maximum number of hash values (i.e., a k-bit hash) and p is the number of nodes, then (assuming one Crypto-ID per node) the formula 1 - e<sup>-p<sup>2</sup>/(2n)</sup> provides an approximation of the probability that there is at least one collision (birthday paradox).<a href="#section-7.5-1" class="pilcrow">¶</a></p>
<p id="section-7.5-2">
        If the Crypto-ID is 64 bits (the least possible size allowed), the chance of a collision is 0.01% for a network of 66 million nodes. Moreover, the collision is only relevant when this happens within one stub network (6LBR). In the case of such a collision, an honest node might accidentally claim the Registered Address of another legitimate node (with the same Crypto-ID). To prevent such rare events, it is <span class="bcp14">RECOMMENDED</span> that nodes do not derive the address being registered from the ROVR.<a href="#section-7.5-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-7.6">
        <h3 id="name-implementation-attacks">
<a href="#section-7.6" class="section-number selfRef">7.6. </a><a href="#name-implementation-attacks" class="section-name selfRef">Implementation Attacks</a>
        </h3>
<p id="section-7.6-1"> The signature schemes referenced in this specification comply with NIST <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span> or Crypto Forum Research Group (CFRG) standards <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span> and offer strong algorithmic security at roughly a 128-bit security level. These signature schemes use elliptic curves that either were specifically designed with exception-free and constant-time arithmetic in mind <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span> or have extensive implementation experience of resistance
 to timing attacks <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>.<a href="#section-7.6-1" class="pilcrow">¶</a></p>
<p id="section-7.6-2">
        However, careless implementations of the signing operations could nevertheless leak information on private keys. For example,
 there are micro-architectural side channel attacks that implementors should be aware of <span>[<a href="#breaking-ed25519" class="xref">breaking-ed25519</a>]</span>.
        Implementors should be particularly aware that
 a secure implementation of Ed25519 requires a protected implementation of the hash function SHA-512, whereas this is not required with implementations of the hash function
 SHA-256 used with ECDSA256 and ECDSA25519.<a href="#section-7.6-2" class="pilcrow">¶</a></p>
</section>
<section id="section-7.7">
        <h3 id="name-cross-algorithm-and-cross-p">
<a href="#section-7.7" class="section-number selfRef">7.7. </a><a href="#name-cross-algorithm-and-cross-p" class="section-name selfRef">Cross-Algorithm and Cross-Protocol Attacks</a>
        </h3>
<p id="section-7.7-1">
        The key pair used in this specification can be self-generated, and the public key does not need to be exchanged, e.g., through certificates, with a third party before it is used.<a href="#section-7.7-1" class="pilcrow">¶</a></p>
<p id="section-7.7-2">
        New key pairs can be formed for new registrations if the node desires. However, the same private key <span class="bcp14">MUST NOT</span> be reused with more than one instantiation of the signature scheme in this specification. Also, the same private key <span class="bcp14">MUST NOT</span> be used for anything other than computing NDPSO signatures per this specification.<a href="#section-7.7-2" class="pilcrow">¶</a></p>
<p id="section-7.7-3"> ECDSA shall be used strictly as specified in <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>. In particular, each signing operation of ECDSA <span class="bcp14">MUST</span> use randomly generated ephemeral private keys and <span class="bcp14">MUST NOT</span> reuse the ephemeral private key k across signing operations. This precludes the use of deterministic ECDSA without a random input for the determination of k, which is deemed dangerous for the intended applications this document aims to serve.<a href="#section-7.7-3" class="pilcrow">¶</a></p>
</section>
<section id="section-7.8">
        <h3 id="name-public-key-validation">
<a href="#section-7.8" class="section-number selfRef">7.8. </a><a href="#name-public-key-validation" class="section-name selfRef">Public Key Validation</a>
        </h3>
<p id="section-7.8-1">Public keys contained in the CIPO field (which are used for signature verification) shall be verified to be correctly formed, by checking that this public key is indeed a
 point of the elliptic curve indicated by the Crypto-Type and that this point does have the proper order.<a href="#section-7.8-1" class="pilcrow">¶</a></p>
<p id="section-7.8-2">
        For points used with the signature scheme Ed25519, one <span class="bcp14">MUST</span> check
 that this point is not in the small subgroup (see <span><a href="https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-14#appendix-B.1" class="relref">Appendix B.1</a> of [<a href="#I-D.ietf-lwig-curve-representations" class="xref">CURVE-REPR</a>]</span>); for points used with the signature scheme
 ECDSA (i.e., both ECDSA256 and ECDSA25519), one <span class="bcp14">MUST</span> check that the point has the same order as the base point of the curve in question. This is commonly called
 "full public key validation" (again, see <span><a href="https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-14#appendix-B.1" class="relref">Appendix B.1</a> of [<a href="#I-D.ietf-lwig-curve-representations" class="xref">CURVE-REPR</a>]</span>).<a href="#section-7.8-2" class="pilcrow">¶</a></p>
</section>
<section id="section-7.9">
        <h3 id="name-correlating-registrations">
<a href="#section-7.9" class="section-number selfRef">7.9. </a><a href="#name-correlating-registrations" class="section-name selfRef">Correlating Registrations</a>
        </h3>
<p id="section-7.9-1">
          The ROVR field in the EARO introduced in <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> extends the EUI-64 field of the ARO defined in <span>[<a href="#RFC6775" class="xref">RFC6775</a>]</span>. One of the drawbacks of using an EUI-64 as ROVR is that an attacker that is aware of the registrations can correlate traffic for the same 6LN across multiple addresses. <span><a href="https://www.rfc-editor.org/rfc/rfc8505#section-3" class="relref">Section 3</a> of [<a href="#RFC8505" class="xref">RFC8505</a>]</span> indicates that the ROVR and the address being registered are decoupled. A 6LN may use the same ROVR for multiple registrations or a different ROVR per registration, and the IID must not be derived from the ROVR. In theory, different 6LNs could use the same ROVR as long as they do not attempt to register the same address.<a href="#section-7.9-1" class="pilcrow">¶</a></p>
<p id="section-7.9-2">
          The modifier used in the computation of the Crypto-ID enables a 6LN to build different Crypto-IDs for different addresses with the same key pair. Using that facility improves the privacy of the 6LN at the expense of storage in the 6LR, which will need to store multiple CIPOs that contain the same public key. Note that if an attacker gains access to the 6LR, then the modifier alone does not provide protection, and the 6LN would need to generate different key pairs and link-layer addresses in an attempt to obfuscate its multiple ownership.<a href="#section-7.9-2" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="cgam">
<section id="section-8.1">
        <h3 id="name-cga-message-type">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-cga-message-type" class="section-name selfRef">CGA Message Type</a>
        </h3>
<p id="section-8.1-1">

    This document defines a new 128-bit CGA Extension Type Tag under the "CGA Extension Type Tags" subregistry of the
Cryptographically Generated Addresses (CGA) Message Type Name Space created by <span>[<a href="#RFC3972" class="xref">RFC3972</a>]</span>.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">
Tag: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cryptotypereg">
<section id="section-8.2">
        <h3 id="name-crypto-type-subregistry">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-crypto-type-subregistry" class="section-name selfRef">Crypto-Type Subregistry</a>
        </h3>
<p id="section-8.2-1">
 IANA has created the "Crypto-Types" subregistry in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry.  The registry is indexed by
 an integer in the interval 0..255 and contains an elliptic curve, a hash function, a signature algorithm, representation conventions,
        public key size, and signature size, as shown in
 <a href="#cryptotypetable" class="xref">Table 1</a>, which together specify a signature scheme. Detailed explanations are provided in <a href="#reprconv" class="xref">Appendix B</a>.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">The following Crypto-Type values are defined in this document:<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<span id="name-crypto-types"></span><div id="cryptotypetable">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-crypto-types" class="selfRef">Crypto-Types</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Crypto-Type Value</th>
              <th class="text-center" rowspan="1" colspan="1"> 0 (ECDSA256) </th>
              <th class="text-center" rowspan="1" colspan="1"> 1 (Ed25519) </th>
              <th class="text-center" rowspan="1" colspan="1"> 2 (ECDSA25519) </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Elliptic Curve</td>
              <td class="text-center" rowspan="1" colspan="1"> NIST P-256 <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"> Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"> Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Hash Function</td>
              <td class="text-center" rowspan="1" colspan="1"> SHA-256 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"> SHA-512 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"> SHA-256 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Signature Algorithm</td>
              <td class="text-center" rowspan="1" colspan="1"> ECDSA <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"> Ed25519 <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"> ECDSA <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Representation Conventions</td>
              <td class="text-center" rowspan="1" colspan="1"> Weierstrass, (un)compressed, MSB/msb-order, <span>[<a href="#SEC1" class="xref">SEC1</a>]</span> </td>
              <td class="text-center" rowspan="1" colspan="1"> Edwards, compressed, LSB/lsb-order, <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"> Weierstrass, (un)compressed, MSB/msb-order, <span>[<a href="#I-D.ietf-lwig-curve-representations" class="xref">CURVE-REPR</a>]</span>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Public Key Size</td>
              <td class="text-center" rowspan="1" colspan="1"> 33/65 bytes (compressed/uncompressed)</td>
              <td class="text-center" rowspan="1" colspan="1"> 32 bytes (compressed)</td>
              <td class="text-center" rowspan="1" colspan="1"> 33/65 bytes (compressed/uncompressed) </td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Signature Size</td>
              <td class="text-center" rowspan="1" colspan="1"> 64 bytes </td>
              <td class="text-center" rowspan="1" colspan="1"> 64 bytes </td>
              <td class="text-center" rowspan="1" colspan="1"> 64 bytes </td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Reference</td>
              <td class="text-center" rowspan="1" colspan="1">RFC 8928</td>
              <td class="text-center" rowspan="1" colspan="1">RFC 8928</td>
              <td class="text-center" rowspan="1" colspan="1">RFC 8928</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-8.2-4">
 New Crypto-Type values providing similar or better security may be defined in the future.<a href="#section-8.2-4" class="pilcrow">¶</a></p>
<p id="section-8.2-5">
    Assignment of values for new Crypto-Type <span class="bcp14">MUST</span> be done through IANA with either "Specification Required" or "IESG Approval" as defined in <span><a href="#RFC8126" class="xref">BCP 26</a> [<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-8.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ndopt">
<section id="section-8.3">
        <h3 id="name-ipv6-nd-option-types">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-ipv6-nd-option-types" class="section-name selfRef">IPv6 ND Option Types</a>
        </h3>
<p id="section-8.3-1">
    This document registers two new ND option types under the subregistry "IPv6 Neighbor Discovery Option Formats":<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<span id="name-new-nd-options"></span><div id="nexndopt">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-new-nd-options" class="selfRef">New ND Options</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-center" rowspan="1" colspan="1">Type</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Crypto-ID Parameters Option (CIPO)</td>
              <td class="text-center" rowspan="1" colspan="1">39</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8928</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NDP Signature Option (NDPSO)</td>
              <td class="text-center" rowspan="1" colspan="1">40</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8928</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<section id="section-8.4">
        <h3 id="name-new-6lowpan-capability-bit">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-new-6lowpan-capability-bit" class="section-name selfRef">New 6LoWPAN Capability Bit</a>
        </h3>
<p id="section-8.4-1">
     IANA has made an addition to the subregistry for
     "6LoWPAN Capability Bits" created for <span>[<a href="#RFC7400" class="xref">RFC7400</a>]</span>
        as follows:<a href="#section-8.4-1" class="pilcrow">¶</a></p>
<span id="name-new-6lowpan-capability-bit-2"></span><div id="CIOdat">
<table class="center" id="table-3">
          <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-new-6lowpan-capability-bit-2" class="selfRef">New 6LoWPAN Capability Bit</a>
          </caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1">Bit</th>
              <th class="text-left" rowspan="1" colspan="1">Description </th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">9</td>
              <td class="text-left" rowspan="1" colspan="1">AP-ND Enabled (1 bit)</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8928</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</section>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="FIPS186-4">[FIPS186-4]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Digital Signature Standard (DSS)"</span>, <span class="seriesInfo">FIPS 186-4</span>, <span class="seriesInfo">DOI 10.6028/NIST.FIPS.186-4</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.186-4.pdf">https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.186-4.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<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="RFC3971">[RFC3971]</dt>
        <dd>
<span class="refAuthor">Arkko, J., Ed.</span><span class="refAuthor">, Kempf, J.</span><span class="refAuthor">, Zill, B.</span><span class="refAuthor">, and P. Nikander</span>, <span class="refTitle">"SEcure Neighbor Discovery (SEND)"</span>, <span class="seriesInfo">RFC 3971</span>, <span class="seriesInfo">DOI 10.17487/RFC3971</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3971">https://www.rfc-editor.org/info/rfc3971</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6234">[RFC6234]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor"> and T. Hansen</span>, <span class="refTitle">"US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)"</span>, <span class="seriesInfo">RFC 6234</span>, <span class="seriesInfo">DOI 10.17487/RFC6234</span>, <time datetime="2011-05" class="refDate">May 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6234">https://www.rfc-editor.org/info/rfc6234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6775">[RFC6775]</dt>
        <dd>
<span class="refAuthor">Shelby, Z., Ed.</span><span class="refAuthor">, Chakrabarti, S.</span><span class="refAuthor">, Nordmark, E.</span><span class="refAuthor">, and C. Bormann</span>, <span class="refTitle">"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"</span>, <span class="seriesInfo">RFC 6775</span>, <span class="seriesInfo">DOI 10.17487/RFC6775</span>, <time datetime="2012-11" class="refDate">November 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6775">https://www.rfc-editor.org/info/rfc6775</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7400">[RFC7400]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refTitle">"6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"</span>, <span class="seriesInfo">RFC 7400</span>, <span class="seriesInfo">DOI 10.17487/RFC7400</span>, <time datetime="2014-11" class="refDate">November 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7400">https://www.rfc-editor.org/info/rfc7400</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7748">[RFC7748]</dt>
        <dd>
<span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg, M.</span><span class="refAuthor">, and S. Turner</span>, <span class="refTitle">"Elliptic Curves for Security"</span>, <span class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI 10.17487/RFC7748</span>, <time datetime="2016-01" class="refDate">January 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7748">https://www.rfc-editor.org/info/rfc7748</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8032">[RFC8032]</dt>
        <dd>
<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I. Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span class="seriesInfo">DOI 10.17487/RFC8032</span>, <time datetime="2017-01" class="refDate">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8032">https://www.rfc-editor.org/info/rfc8032</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="RFC8505">[RFC8505]</dt>
        <dd>
<span class="refAuthor">Thubert, P., Ed.</span><span class="refAuthor">, Nordmark, E.</span><span class="refAuthor">, Chakrabarti, S.</span><span class="refAuthor">, and C. Perkins</span>, <span class="refTitle">"Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery"</span>, <span class="seriesInfo">RFC 8505</span>, <span class="seriesInfo">DOI 10.17487/RFC8505</span>, <time datetime="2018-11" class="refDate">November 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8505">https://www.rfc-editor.org/info/rfc8505</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SEC1">[SEC1]</dt>
      <dd>
<span class="refAuthor">Standards for Efficient Cryptography</span>, <span class="refTitle">"SEC 1: Elliptic Curve Cryptography"</span>, <span class="refContent">Version 2</span>, <time datetime="2009-05" class="refDate">May 2009</time>, <span>&lt;<a href="https://www.secg.org/sec1-v2.pdf">https://www.secg.org/sec1-v2.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC4086">[BCP106]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor">, Schiller, J.</span><span class="refAuthor">, and S. Crocker</span>, <span class="refTitle">"Randomness Requirements for Security"</span>, <span class="seriesInfo">BCP 106</span>, <span class="seriesInfo">RFC 4086</span>, <span class="seriesInfo">DOI 10.17487/RFC4086</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4086">https://www.rfc-editor.org/info/rfc4086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7696">[BCP201]</dt>
        <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms"</span>, <span class="seriesInfo">BCP 201</span>, <span class="seriesInfo">RFC 7696</span>, <span class="seriesInfo">DOI 10.17487/RFC7696</span>, <time datetime="2015-11" class="refDate">November 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7696">https://www.rfc-editor.org/info/rfc7696</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="breaking-ed25519">[breaking-ed25519]</dt>
        <dd>
<span class="refAuthor">Samwel, N.</span><span class="refAuthor">, Batina, L.</span><span class="refAuthor">, Bertoni, G.</span><span class="refAuthor">, Daemen, J.</span><span class="refAuthor">, and R. Susella</span>, <span class="refTitle">"Breaking Ed25519 in WolfSSL"</span>, <span class="refContent">Topics in Cryptology - CT-RSA, pp. 1-20</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://link.springer.com/chapter/10.1007/978-3-319-76953-0_1">https://link.springer.com/chapter/10.1007/978-3-319-76953-0_1</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-lwig-curve-representations">[CURVE-REPR]</dt>
        <dd>
<span class="refAuthor">Struik, R.</span>, <span class="refTitle">"Alternative Elliptic Curve Representations"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-lwig-curve-representations-14</span>, <time datetime="2020-11-15" class="refDate">15 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-14">https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-14</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3972">[RFC3972]</dt>
        <dd>
<span class="refAuthor">Aura, T.</span>, <span class="refTitle">"Cryptographically Generated Addresses (CGA)"</span>, <span class="seriesInfo">RFC 3972</span>, <span class="seriesInfo">DOI 10.17487/RFC3972</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3972">https://www.rfc-editor.org/info/rfc3972</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="RFC4862">[RFC4862]</dt>
        <dd>
<span class="refAuthor">Thomson, S.</span><span class="refAuthor">, Narten, T.</span><span class="refAuthor">, and T. Jinmei</span>, <span class="refTitle">"IPv6 Stateless Address Autoconfiguration"</span>, <span class="seriesInfo">RFC 4862</span>, <span class="seriesInfo">DOI 10.17487/RFC4862</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4862">https://www.rfc-editor.org/info/rfc4862</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4919">[RFC4919]</dt>
        <dd>
<span class="refAuthor">Kushalnagar, N.</span><span class="refAuthor">, Montenegro, G.</span><span class="refAuthor">, and C. Schumacher</span>, <span class="refTitle">"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals"</span>, <span class="seriesInfo">RFC 4919</span>, <span class="seriesInfo">DOI 10.17487/RFC4919</span>, <time datetime="2007-08" class="refDate">August 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4919">https://www.rfc-editor.org/info/rfc4919</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4944">[RFC4944]</dt>
        <dd>
<span class="refAuthor">Montenegro, G.</span><span class="refAuthor">, Kushalnagar, N.</span><span class="refAuthor">, Hui, J.</span><span class="refAuthor">, and D. Culler</span>, <span class="refTitle">"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</span>, <span class="seriesInfo">RFC 4944</span>, <span class="seriesInfo">DOI 10.17487/RFC4944</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4944">https://www.rfc-editor.org/info/rfc4944</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6282">[RFC6282]</dt>
        <dd>
<span class="refAuthor">Hui, J., Ed.</span><span class="refAuthor"> and P. Thubert</span>, <span class="refTitle">"Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"</span>, <span class="seriesInfo">RFC 6282</span>, <span class="seriesInfo">DOI 10.17487/RFC6282</span>, <time datetime="2011-09" class="refDate">September 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6282">https://www.rfc-editor.org/info/rfc6282</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7039">[RFC7039]</dt>
        <dd>
<span class="refAuthor">Wu, J.</span><span class="refAuthor">, Bi, J.</span><span class="refAuthor">, Bagnulo, M.</span><span class="refAuthor">, Baker, F.</span><span class="refAuthor">, and C. Vogt, Ed.</span>, <span class="refTitle">"Source Address Validation Improvement (SAVI) Framework"</span>, <span class="seriesInfo">RFC 7039</span>, <span class="seriesInfo">DOI 10.17487/RFC7039</span>, <time datetime="2013-10" class="refDate">October 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7039">https://www.rfc-editor.org/info/rfc7039</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7217">[RFC7217]</dt>
        <dd>
<span class="refAuthor">Gont, F.</span>, <span class="refTitle">"A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"</span>, <span class="seriesInfo">RFC 7217</span>, <span class="seriesInfo">DOI 10.17487/RFC7217</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7217">https://www.rfc-editor.org/info/rfc7217</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8064">[RFC8064]</dt>
        <dd>
<span class="refAuthor">Gont, F.</span><span class="refAuthor">, Cooper, A.</span><span class="refAuthor">, Thaler, D.</span><span class="refAuthor">, and W. Liu</span>, <span class="refTitle">"Recommendation on Stable IPv6 Interface Identifiers"</span>, <span class="seriesInfo">RFC 8064</span>, <span class="seriesInfo">DOI 10.17487/RFC8064</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8064">https://www.rfc-editor.org/info/rfc8064</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8065">[RFC8065]</dt>
        <dd>
<span class="refAuthor">Thaler, D.</span>, <span class="refTitle">"Privacy Considerations for IPv6 Adaptation-Layer Mechanisms"</span>, <span class="seriesInfo">RFC 8065</span>, <span class="seriesInfo">DOI 10.17487/RFC8065</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8065">https://www.rfc-editor.org/info/rfc8065</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8929">[RFC8929]</dt>
      <dd>
<span class="refAuthor">Thubert, P., Ed.</span><span class="refAuthor">, Perkins, C.E.</span><span class="refAuthor">, and E. Levy-Abegnoli</span>, <span class="refTitle">"IPv6 Backbone Router"</span>, <span class="seriesInfo">RFC 8929</span>, <span class="seriesInfo">DOI 10.17487/RFC8929</span>, <time datetime="2020-11" class="refDate">November 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8929">https://www.rfc-editor.org/info/rfc8929</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="ps">
<section id="section-appendix.a">
      <h2 id="name-requirements-addressed-in-t">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-requirements-addressed-in-t" class="section-name selfRef">Requirements Addressed in This Document</a>
      </h2>
<p id="section-appendix.a-1">
      In this section, the requirements of a secure Neighbor Discovery protocol for LLNs are stated.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-appendix.a-2.1">
       The protocol <span class="bcp14">MUST</span> be based on the Neighbor Discovery Optimization for the LLN protocol defined in <span>[<a href="#RFC6775" class="xref">RFC6775</a>]</span>. RFC 6775 utilizes optimizations such as host-initiated interactions for sleeping resource-constrained hosts and the elimination of multicast address resolution.<a href="#section-appendix.a-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.2">
        New options to be added to Neighbor Solicitation messages <span class="bcp14">MUST</span> lead to small packet sizes, especially compared with existing protocols such as SEND. Smaller packet sizes facilitate low-power transmission by resource-constrained nodes on lossy links.<a href="#section-appendix.a-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.3">
        The registration mechanism <span class="bcp14">SHOULD</span> be extensible to other LLN links and not be limited to IEEE 802.15.4 only. LLN links for which a 6lo "IPv6 over foo" specification exist, as well as low-power Wi-Fi, <span class="bcp14">SHOULD</span> be supported.<a href="#section-appendix.a-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.4">
        As part of this protocol, a mechanism to compute a unique identifier should be provided with the capability to form a Link Local Address that <span class="bcp14">SHOULD</span> be unique at least within the LLN connected to a 6LBR.<a href="#section-appendix.a-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.5">
        The Address Registration Option used in the ND registration <span class="bcp14">SHOULD</span> be extended to carry the relevant forms of the
        unique identifier.<a href="#section-appendix.a-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.6">
        The Neighbor Discovery should specify the formation of a site-local address that follows the security recommendations from <span>[<a href="#RFC7217" class="xref">RFC7217</a>]</span>.<a href="#section-appendix.a-2.6" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="reprconv">
<section id="section-appendix.b">
      <h2 id="name-representation-conventions">
<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-representation-conventions" class="section-name selfRef">Representation Conventions</a>
      </h2>
<section id="section-b.1">
        <h2 id="name-signature-schemes">
<a href="#section-b.1" class="section-number selfRef">B.1. </a><a href="#name-signature-schemes" class="section-name selfRef">Signature Schemes</a>
        </h2>
<p id="section-b.1-1"> The signature scheme ECDSA256 corresponding to Crypto-Type 0 is ECDSA, as specified in <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>, instantiated with the NIST prime curve P-256,
 as specified in Appendix D.1.2 of <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>, and the hash function SHA-256, as specified in <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>, where points of this NIST curve are
 represented as points of a short-Weierstrass curve (see <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>) and are encoded as octet strings in most-significant-bit first (msb) and
 most-significant-byte first (MSB) order. The signature itself consists of two integers (r and s), which are each encoded as fixed-size octet strings in MSB and msb order. For further details, see <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span> for ECDSA, see <a href="#weirepr" class="xref">Appendix B.3</a> for the encoding of public keys, and see
        <a href="#bitrepr" class="xref">Appendix B.2</a> for signature encoding.<a href="#section-b.1-1" class="pilcrow">¶</a></p>
<p id="section-b.1-2"> The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, as specified in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>, instantiated with the Montgomery curve Curve25519, as
 specified in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>, and the hash function SHA-512, as specified in <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>, where points of this Montgomery curve are
 represented as points of the corresponding twisted Edwards
 curve Edwards25519 (see <a href="#curves" class="xref">Appendix B.4</a>) and are
 encoded as octet strings in least-significant-bit first (lsb)
 and least-significant-byte first (LSB) order. The signature itself consists of a bit string that encodes a point of this twisted Edwards curve, in compressed format, and an
 integer encoded in LSB and lsb order. For details on EdDSA and the encoding of public keys and signatures, see the
 specification of pure Ed25519 in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.<a href="#section-b.1-2" class="pilcrow">¶</a></p>
<p id="section-b.1-3"> The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is ECDSA, as specified in <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>, instantiated with the Montgomery curve
 Curve25519, as specified in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>, and the hash function SHA-256, as specified in <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>, where points of this Montgomery
 curve are represented as points of the corresponding short-Weierstrass curve Wei25519 (see <a href="#curves" class="xref">Appendix B.4</a>) and are encoded as octet strings in
 MSB and msb order. The signature itself consists of a bit string that encodes two integers (r and s), which are each encoded as fixed-size
 octet strings in MSB and msb order. For further details, see <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span> for ECDSA, see <a href="#weirepr" class="xref">Appendix B.3</a> for the encoding of
 public keys, and see <a href="#bitrepr" class="xref">Appendix B.2</a> for signature encoding.<a href="#section-b.1-3" class="pilcrow">¶</a></p>
</section>
<div id="bitrepr">
<section id="section-b.2">
        <h2 id="name-representation-of-ecdsa-sig">
<a href="#section-b.2" class="section-number selfRef">B.2. </a><a href="#name-representation-of-ecdsa-sig" class="section-name selfRef">Representation of ECDSA Signatures</a>
        </h2>
<p id="section-b.2-1"> With ECDSA, each signature is an ordered pair (r, s) of integers <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>, where each integer is represented as a 32-octet string according to the
 FieldElement-to-OctetString conversion rules in <span>[<a href="#SEC1" class="xref">SEC1</a>]</span> and where the ordered pair of integers is represented as the right concatenation of these representation
 values (thereby resulting in a 64-octet string). The inverse operation checks that the signature is a 64-octet string and represents the left-side and right-side halves of this
 string (each a 32-octet string) as the integers r and s, respectively, using the OctetString-to-FieldElement conversion rules in <span>[<a href="#SEC1" class="xref">SEC1</a>]</span>. In both cases, the
 field with these conversion rules is the set of integers modulo n, where n is the (prime) order of the base point of the curve in question. (For elliptic curve nomenclature, see
    <span><a href="https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-14#appendix-B.1" class="relref">Appendix B.1</a> of [<a href="#I-D.ietf-lwig-curve-representations" class="xref">CURVE-REPR</a>]</span>.)<a href="#section-b.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="weirepr">
<section id="section-b.3">
        <h2 id="name-representation-of-public-ke">
<a href="#section-b.3" class="section-number selfRef">B.3. </a><a href="#name-representation-of-public-ke" class="section-name selfRef">Representation of Public Keys Used with ECDSA</a>
        </h2>
<p id="section-b.3-1"> ECDSA is specified to be used with elliptic curves in short-Weierstrass form. Each point of such a curve is represented as an octet string using the Elliptic-Curve-Point-to-Octet-String
        conversion rules in <span>[<a href="#SEC1" class="xref">SEC1</a>]</span>, where point compression may be enabled (which is indicated by the leftmost octet of this representation). The inverse
 operation converts an octet string to a point of this curve using the Octet-String-to-Elliptic-Curve-Point conversion rules in <span>[<a href="#SEC1" class="xref">SEC1</a>]</span>, whereby the point is rejected
 if this is the so-called point at infinity. (This is the case if the input to this inverse operation is an octet string of length 1.)<a href="#section-b.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="curves">
<section id="section-b.4">
        <h2 id="name-alternative-representations">
<a href="#section-b.4" class="section-number selfRef">B.4. </a><a href="#name-alternative-representations" class="section-name selfRef">Alternative Representations of Curve25519</a>
        </h2>
<p id="section-b.4-1"> The elliptic curve Curve25519, as specified in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>, is a so-called Montgomery curve. Each point of this curve can also be represented as a point
 of a twisted Edwards curve or as a point of an elliptic curve in short-Weierstrass form, via a coordinate transformation (a so-called isomorphic mapping). The parameters of the
 Montgomery curve and the corresponding isomorphic curves in twisted Edwards curve and short-Weierstrass form are as indicated below. Here, the domain parameters of the Montgomery
 curve Curve25519 and of the twisted Edwards curve Edwards25519 are as specified in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>; the domain parameters of the elliptic curve Wei25519 in
 short-Weierstrass form comply with Section 6.1.1 of <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>. For further details on these curves and on the coordinate transformations referenced above, see
 <span>[<a href="#I-D.ietf-lwig-curve-representations" class="xref">CURVE-REPR</a>]</span>.<a href="#section-b.4-1" class="pilcrow">¶</a></p>
<p id="section-b.4-2"> General parameters (for all curve models):<a href="#section-b.4-2" class="pilcrow">¶</a></p>
<div id="section-b.4-3">
<pre class="sourcecode">
p  2^{255}-19
   (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
   ffffffed)
h  8
n
   723700557733226221397318656304299424085711635937990760600195093828
   5454250989
   (=2^{252} +  0x14def9de a2f79cd6 5812631a 5cf5d3ed)
</pre><a href="#section-b.4-3" class="pilcrow">¶</a>
</div>
<p id="section-b.4-4"> Montgomery curve-specific parameters (for Curve25519):<a href="#section-b.4-4" class="pilcrow">¶</a></p>
<div id="section-b.4-5">
<pre class="sourcecode">
A  486662
B  1
Gu 9 (=0x9)
Gv
   147816194475895447910205935684099868872646061346164752889648818377
   55586237401
   (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2
   7eced3d9)
</pre><a href="#section-b.4-5" class="pilcrow">¶</a>
</div>
<p id="section-b.4-6"> Twisted Edwards curve-specific parameters (for Edwards25519):<a href="#section-b.4-6" class="pilcrow">¶</a></p>
<div id="section-b.4-7">
<pre class="sourcecode">
a  -1 (-0x01)
d  -121665/121666
   (=3709570593466943934313808350875456518954211387984321901638878553
   3085940283555)
   (=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 75eb4dca
   135978a3)
Gx
   151122213495354007725011514095885315114540126930418572060461132839
   49847762202
   (=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2 c9562d60
   8f25d51a)
Gy  4/5
   (=4631683569492647816942839400347516314130799386625622561578303360
   3165251855960)
   (=0x66666666 66666666 66666666 66666666 66666666 66666666 66666666
   66666658)
</pre><a href="#section-b.4-7" class="pilcrow">¶</a>
</div>
<p id="section-b.4-8"> Weierstrass curve-specific parameters (for Wei25519):<a href="#section-b.4-8" class="pilcrow">¶</a></p>
<div id="section-b.4-9">
<pre class="sourcecode">
a
   192986815395526992372618308347813179755449974442734273399095973345
   73241639236
   (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaa98
   4914a144)
b
   557517466698189089076452890782571408182411037279010123152944008379
   56729358436
   (=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 260b5e9c
   7710c864)
GX
   192986815395526992372618308347813179755449974442734273399095973346
   52188435546
   (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa
   aaad245a)
GY
   147816194475895447910205935684099868872646061346164752889648818377
   55586237401
   (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2
   7eced3d9)
</pre><a href="#section-b.4-9" class="pilcrow">¶</a>
</div>
</section>
</div>
<section id="section-b.5">
        <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
        </h2>
<p id="section-b.5-1">
     Many thanks to <span class="contact-name">Charlie Perkins</span> for his in-depth review and constructive
     suggestions. The authors are also especially grateful to <span class="contact-name">Robert Moskowitz</span>
     and <span class="contact-name">Benjamin Kaduk</span> for their comments and discussions that led to many improvements.
     The authors wish to also thank <span class="contact-name">Shwetha Bhandari</span> for actively shepherding this document and <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Alissa Cooper</span>, <span class="contact-name">Mirja Kühlewind</span>, <span class="contact-name">Éric Vyncke</span>, <span class="contact-name">Vijay Gurbani</span>, <span class="contact-name">Al Morton</span>, and <span class="contact-name">Adam Montville</span> for their constructive reviews during the IESG process.
     Finally, many thanks to our INT area ADs, <span class="contact-name">Suresh Krishnan</span> and <span class="contact-name">Erik Kline</span>, who
     supported us along the whole process.<a href="#section-b.5-1" class="pilcrow">¶</a></p>
</section>
</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">Pascal Thubert (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">Building D<br>45 Allee des Ormes - BP1200</span></div>
<div dir="auto" class="left">
<span class="postal-code">06254</span> <span class="locality">MOUGINS - Sophia Antipolis</span>
</div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+33%20497%2023%2026%2034" class="tel">+33 497 23 26 34</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:pthubert@cisco.com" class="email">pthubert@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Behcet Sarikaya</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:sarikaya@ieee.org" class="email">sarikaya@ieee.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mohit Sethi</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">02420</span> <span class="locality">Jorvas</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mohit@piuha.net" class="email">mohit@piuha.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Rene Struik</span></div>
<div dir="auto" class="left"><span class="org">Struik Security Consultancy</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:rstruik.ext@gmail.com" class="email">rstruik.ext@gmail.com</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>