File: rfc9032.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 (1858 lines) | stat: -rw-r--r-- 70,683 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9032: Encapsulation of 6TiSCH Join and Enrollment Information Elements</title>
<meta content="Diego Dujovne" name="author">
<meta content="Michael Richardson" name="author">
<meta content="
       In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4, 
opportunities for broadcasts are limited to
specific times and specific channels.  Routers in a 
TSCH network
transmit Enhanced Beacon (EB) frames to announce the presence of the
network.  This document provides a mechanism by which additional information critical
for new nodes (pledges) and long-sleeping nodes may be carried within the
EB in order to conserve use of broadcast opportunities. 
    " name="description">
<meta content="xml2rfc 3.8.0" name="generator">
<meta content="BRSKI" name="keyword">
<meta content="enroll" name="keyword">
<meta content="zero-touch" name="keyword">
<meta content="DODAG balancing" name="keyword">
<meta content="LLN balancing" name="keyword">
<meta content="9032" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.8.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9032.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9032" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon-14" 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 9032</td>
<td class="center">Enroll Beacon</td>
<td class="right">May 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Dujovne &amp; Richardson</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/rfc9032" class="eref">9032</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="2021-05" class="published">May 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">D. Dujovne, <span class="editor">Ed.</span>
</div>
<div class="org">Universidad Diego Portales</div>
</div>
<div class="author">
      <div class="author-name">M. Richardson</div>
<div class="org">Sandelman Software Works</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9032</h1>
<h1 id="title">Encapsulation of 6TiSCH Join and Enrollment Information Elements</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4, 
opportunities for broadcasts are limited to
specific times and specific channels.  Routers in a 
TSCH network
transmit Enhanced Beacon (EB) frames to announce the presence of the
network.  This document provides a mechanism by which additional information critical
for new nodes (pledges) and long-sleeping nodes may be carried within the
EB in order to conserve use of broadcast opportunities.<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/rfc9032">https://www.rfc-editor.org/info/rfc9032</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-layer-2-synchronization" class="xref">Layer 2 Synchronization</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-layer-3-synchronization-ipv" class="xref">Layer 3 Synchronization: IPv6 Router Solicitations and Advertisements</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.1.2.4">
                <p id="section-toc.1-1.1.2.4.1"><a href="#section-1.4" class="xref">1.4</a>.  <a href="#name-layer-2-selection" class="xref">Layer 2 Selection</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" 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-protocol-definition" class="xref">Protocol Definition</a></p>
</li>
          <li class="toc compact ulEmpty" 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" 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-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="toc compact ulEmpty" 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-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="problems">
<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"><span>[<a href="#RFC7554" class="xref">RFC7554</a>]</span> describes the use of the Time-Slotted Channel Hopping (TSCH) mode of <span>[<a href="#IEEE.802.15.4" class="xref">IEEE.802.15.4</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">In TSCH mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to
specific times and specific channels.
Routers in a TSCH network
transmit Enhanced Beacon (EB) frames during broadcast slots in order to
announce the time and channel schedule.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">This document defines a new IETF Information Element (IE) subtype to place
into the EB to provide join and enrollment information to prospective
pledges in a more efficient way.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The following subsections explain the problem being solved, which
justifies carrying the join and enrollment information in the EB.<a href="#section-1-4" class="pilcrow">¶</a></p>
<div id="Terminology">
<section id="section-1.1">
        <h3 id="name-terminology">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-1.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-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">Other terminology can be found in <span><a href="https://www.rfc-editor.org/rfc/rfc9030#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC9030" class="xref">RFC9030</a>]</span>.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="layer-2-synchronization">
<section id="section-1.2">
        <h3 id="name-layer-2-synchronization">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-layer-2-synchronization" class="section-name selfRef">Layer 2 Synchronization</a>
        </h3>
<p id="section-1.2-1">As explained in <span><a href="https://www.rfc-editor.org/rfc/rfc8180#section-4.5.2" class="relref">Section 4.5.2</a> of [<a href="#RFC8180" class="xref">RFC8180</a>]</span>, the EB
has a number of purposes: it carries synchronization information such as the 
   Absolute Slot Number (ASN) and Join Metric and identifiers for 
   the timeslot template and the channel hopping sequence, and it 
   indicates the TSCH slotframe.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2">An EB announces the existence of a TSCH network and the nodes
already joined to that network.  Receiving an EB allows a Joining Node
(pledge) to learn about the network and to synchronize with it.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
<p id="section-1.2-3">The EB may also be used as a means for a node already part of the network to
resynchronize <span>[<a href="#RFC7554" class="xref">RFC7554</a>]</span>.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
<p id="section-1.2-4">There are a limited number of timeslots designated as broadcast slots by each
router in the network.
Considering 10 ms slots and a slotframe length of 100, these slots are rare
and could result in only 1 slot per second for broadcasts, which needs to be
used for the beacon.
Additional broadcasts for Router Advertisements (RA) or Neighbor Discovery
(ND) could be even more scarce.<a href="#section-1.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="layer-3-synchronization-ipv6-router-solicitations-and-advertisements">
<section id="section-1.3">
        <h3 id="name-layer-3-synchronization-ipv">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-layer-3-synchronization-ipv" class="section-name selfRef">Layer 3 Synchronization: IPv6 Router Solicitations and Advertisements</a>
        </h3>
<p id="section-1.3-1">At Layer 3, <span>[<a href="#RFC4861" class="xref">RFC4861</a>]</span> defines a mechanism by which nodes learn about
routers by receiving multicast RAs.
If no RA is received within a set time, then a Router Solicitation (RS) may be
transmitted as a multicast, to which an RA will be received, usually unicast.<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<p id="section-1.3-2">Although <span>[<a href="#RFC6775" class="xref">RFC6775</a>]</span> reduces the amount of multicast necessary for address
resolution via Neighbor Solicitation (NS) messages, it still requires multicast
of either RAs or RSes.
This is an expensive operation for two reasons: there
are few multicast timeslots for unsolicited RAs; and if a pledge node does not
receive an RA, and decides to transmit an RS,
a broadcast Aloha slot (see <span><a href="https://www.rfc-editor.org/rfc/rfc7554#appendix-A.5" class="relref">Appendix A.5</a> of [<a href="#RFC7554" class="xref">RFC7554</a>]</span>) is consumed with
unencrypted traffic.
<span>[<a href="#RFC6775" class="xref">RFC6775</a>]</span> already allows for a unicast reply to such an RS.<a href="#section-1.3-2" class="pilcrow">¶</a></p>
<p id="section-1.3-3">This is a particularly acute issue for the join process for the following
reasons:<a href="#section-1.3-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1.3-4">
          <li id="section-1.3-4.1">Use of a multicast slot by even a non-malicious unauthenticated node for
a Router Solicitation (RS) may overwhelm that timeslot.<a href="#section-1.3-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-1.3-4.2">It may require many seconds of on-time before a new pledge receives a
Router Advertisement (RA) that it can use.<a href="#section-1.3-4.2" class="pilcrow">¶</a>
</li>
          <li id="section-1.3-4.3">A new pledge may have to receive many EBs before it can pick an
appropriate network and/or closest Join Proxy to attach to.
If it must remain in the receive state for an RA as well as find the
EB, then the process may take dozens of seconds, even minutes for each
enrollment attempt that it needs to make.<a href="#section-1.3-4.3" class="pilcrow">¶</a>
</li>
        </ol>
</section>
</div>
<div id="layer-2-selection">
<section id="section-1.4">
        <h3 id="name-layer-2-selection">
<a href="#section-1.4" class="section-number selfRef">1.4. </a><a href="#name-layer-2-selection" class="section-name selfRef">Layer 2 Selection</a>
        </h3>
<p id="section-1.4-1">In a complex Low-power and Lossy Network (LLN), multiple LLNs may 
be connected together by Backbone Routers (technology such as 
<span>[<a href="#RFC8929" class="xref">RFC8929</a>]</span>), resulting in an area that is 
serviced by multiple, distinct Layer 2 instances.
These are called Personal Area Networks (PANs).
Each instance will have a separate Layer 2 security profile and will be distinguished by a different PANID.

The PANID is part of the Layer 2 header as defined in <span>[<a href="#IEEE.802.15.4" class="xref">IEEE.802.15.4</a>]</span>:
it is a 16-bit value that is chosen to be unique, and 
it contributes context to the Layer 2 security mechanisms.
The PANID provides a context similar to the Extended Service Set ID (ESSID) 
in 802.11 networking and can be considered similar to 
the 802.3 Ethernet VLAN tag in that it provides context for all Layer 2 addresses.<a href="#section-1.4-1" class="pilcrow">¶</a></p>
<p id="section-1.4-2">A device that is already enrolled in a network may find after 
a long sleep that it needs to resynchronize with the Layer 2 network.
The device's enrollment keys will be specific to a PANID, but the device may have more than one set of keys.
Such a device may wish to connect to a PAN that is experiencing less congestion or that has a shallower
Routing Protocol for LLNs (RPL) tree <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span>.
It may even observe PANs for which it does not have keys, but for which 
it believes it may have credentials that would allow it to join.<a href="#section-1.4-2" class="pilcrow">¶</a></p>
<p id="section-1.4-3">In order to identify which PANs are part of the same backbone network, the network ID is introduced in this extension.
PANs that are part of the same backbone will be configured to use the same network ID.
For RPL networks <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span>, configuration of the network ID can be done with a configuration option, which is the subject of future work.<a href="#section-1.4-3" class="pilcrow">¶</a></p>
<p id="section-1.4-4">In order to provide some input to the choice of which PAN to use, the PAN priority field has been added.
This lists the relative priority for the PAN among different PANs.
Every EB from a given PAN will likely have the same PAN priority.
Determination of the PAN priority is the subject of future work; 
but it is expected that it will be calculated by an algorithm in the 
6LoWPAN Border Router (6LBR), possibly involving communication between 6LBRs over the backbone network.<a href="#section-1.4-4" class="pilcrow">¶</a></p>
<p id="section-1.4-5">The parent selection process <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span> 
can only operate within a single PAN because it depends upon receiving RPL DIO messages from all available parents.
As part of the PAN selection process, the device may wish to know how deep 
in the LLN mesh it will be if it joins a particular PAN, and the rank 
priority field provides an estimation of each announcer's rank.
Once the device synchronizes with a particular PAN's TSCH schedule,  
it may receive DIOs that are richer in their diversity than this value.
The use of this value in practice is the subject of future research, and the interpretation of this
value of the structure is considered experimental.<a href="#section-1.4-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="protocol-definition">
<section id="section-2">
      <h2 id="name-protocol-definition">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-protocol-definition" class="section-name selfRef">Protocol Definition</a>
      </h2>
<p id="section-2-1"><span>[<a href="#RFC8137" class="xref">RFC8137</a>]</span> creates a registry for new IETF IE subtypes.
This document allocates a new subtype.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">The new IE subtype structure is as follows.  As explained in
<span>[<a href="#RFC8137" class="xref">RFC8137</a>]</span>, the length of the subtype content can be calculated from the
container, so no length information is necessary.<a href="#section-2-2" class="pilcrow">¶</a></p>
<span id="name-ie-subtype-structure"></span><div id="iesubtype">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-2-3.1">
<pre>
                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       2       |R|P| res |  proxy prio |    rank priority      |
+-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+
| PAN priority  |                                               |
+---------------+                                               +
|                     Join Proxy Interface ID                   |
+                        (present if P=1)                       +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                           network ID                          |
+                   variable length, up to 16 bytes             +
~                                                               ~
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-ie-subtype-structure" class="selfRef">IE Subtype Structure</a>
        </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-2-4">
        <dt id="section-2-4.1">res:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.2">
  Reserved bits <span class="bcp14">MUST</span> be ignored upon receipt and <span class="bcp14">SHOULD</span> be set to 0 when sending.<a href="#section-2-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.3">R:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.4">
  The RA R-flag is set if the sending node will act as a router for host-only nodes relying on stateless address auto-configuration (SLAAC) to get their global IPv6 address.
Those hosts <span class="bcp14">MUST</span> send a unicast RS message in order to receive an RA with the Prefix Information Option.<a href="#section-2-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.5"></dt>
        <dd style="margin-left: 1.5em" id="section-2-4.6">In most cases, every node sending a beacon will set this flag, and in a
typical mesh, this will be every single node.  When this bit is not set, it
might indicate that this node may be under provisioned or that it may have no additional
slots for additional nodes.  This could make this node more interesting to an
attacker.<a href="#section-2-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.7">P:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.8">
  If the Proxy Address P-flag is set, then the Join Proxy Interface ID bit field
is present.  Otherwise, it is not provided.<a href="#section-2-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.9"></dt>
        <dd style="margin-left: 1.5em" id="section-2-4.10">This bit only indicates if another part of the structure is present, and
it has little security or privacy impact.<a href="#section-2-4.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.11">proxy prio (proxy priority):</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.12">
  This field indicates the willingness of the sender to act as a Join Proxy.
Lower value indicates greater willingness to act as a Join Proxy as described in
<span>[<a href="#RFC9031" class="xref">RFC9031</a>]</span>.
Values range from 0x00 (most willing) to 0x7e (least willing).
A priority of 0x7f indicates that the announcer should never be considered as a viable Join Proxy.
Only unenrolled pledges look at this value.<a href="#section-2-4.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.13"></dt>
        <dd style="margin-left: 1.5em" id="section-2-4.14">Lower values in this field indicate that the transmitter may have more
capacity to handle unencrypted traffic.
A higher value may indicate that the transmitter is low on neighbor cache entries or other resources.
Ongoing work such as <span>[<a href="#I-D.ietf-roll-enrollment-priority" class="xref">NETWORK-ENROLLMENT</a>]</span> documents one way to set this field.<a href="#section-2-4.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.15">rank priority:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.16">
  The rank priority is set by the IPv6 LLN Router (6LR) that sent the beacon and is an
indication of how willing this 6LR is to serve as a RPL parent <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span> within a
particular network ID.
Lower values indicate more willingness, and higher values indicate less willingness.
This value is calculated by each 6LR according to algorithms specific to the
routing metrics used by the RPL <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span>.
The exact process is a subject of significant research work.
It will typically be calculated from the RPL rank, and it may include some modifications
based upon current number of children or the number of neighbor cache entries
available.
Pledges <span class="bcp14">MUST</span> ignore this value.
It helps enrolled devices only to compare connection points.<a href="#section-2-4.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.17"></dt>
        <dd style="margin-left: 1.5em" id="section-2-4.18">An attacker can use this value to determine which nodes are potentially
more interesting.
Nodes that are less willing to be parents likely have more traffic, and an
attacker could use this information to determine which nodes would be more
interesting to attack or disrupt.<a href="#section-2-4.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.19">PAN priority:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.20">
  The PAN priority is a value set by the Destination-Oriented Directed
Acyclic Graph (DODAG) root (see <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span>, typically the 6LBR) to indicate the relative
priority of this LLN compared to those with different PANIDs that the
operator might control.
This value may be used as part of the enrollment priority, but typically it is used by devices
that have already enrolled and need to determine which PAN to pick when
resuming from a long sleep.
Unenrolled pledges <span class="bcp14">MAY</span> consider this value when selecting a PAN to join.
Enrolled devices <span class="bcp14">MAY</span> consider this value when looking for an eligible parent
device.
Lower values indicate more willingness to accept new nodes.<a href="#section-2-4.20" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.21"></dt>
        <dd style="margin-left: 1.5em" id="section-2-4.22">An attacker can use this value, along with the observed PANID in the EB 
to determine which PANIDs have more network resources, and may have more
interesting traffic.<a href="#section-2-4.22" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.23">Join Proxy Interface ID:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.24">
  If the P bit is set, then 64 bits (8 bytes) of address are present.
This field provides the Interface ID (IID) of the link-local address of the Join Proxy.
The associated prefix is well-known as fe80::/64.  If this field is not
present, then IID is derived from the Layer 2 address of the sender per
SLAAC <span>[<a href="#RFC4862" class="xref">RFC4862</a>]</span>.<a href="#section-2-4.24" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.25"></dt>
        <dd style="margin-left: 1.5em" id="section-2-4.26">This field communicates the IID bits that should be used for this node's
Layer 3 address, if it should not be derived from the Layer 2 address.
Communication with the Join Proxy occurs in the clear.
This field avoids the need for an additional service-discovery process for the case where the Layer 3
address is not derived from the Layer 2 address.
An attacker will see both Layer 2 and Layer 3 addresses, so this field provides no new information.<a href="#section-2-4.26" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.27">network ID:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.28">
  This is a variable length field, up to 16-bytes in size that uniquely identifies
this network, potentially among many networks that are operating in the same
frequencies in overlapping physical space.  The length of this field can be
calculated as being whatever is left in the IE.<a href="#section-2-4.28" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.29"></dt>
        <dd style="margin-left: 1.5em" id="section-2-4.30">In a 6TiSCH network, where RPL <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span> is used as the mesh routing protocol, the
network ID can be constructed from a truncated SHA-256 hash of the prefix (/64) of the
network.  This will be done by the RPL DODAG root and communicated by the RPL
Configuration Option payloads, so it is not calculated more than once.
This is just a suggestion for a default algorithm: it may be set in any
convenient way that results in a non-identifying value.
In some LLNs where multiple PANIDs may lead to the same management device
(the Join Registrar/Coordinator (JRC)), then a common value that is the same across all the PANs <span class="bcp14">MUST</span> be
configured.
Pledges that see the same network ID will not waste time
attempting to enroll multiple times with the same network when the network has multiple attachment points.<a href="#section-2-4.30" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.31"></dt>
        <dd style="margin-left: 1.5em" id="section-2-4.32">If the network ID is derived as suggested, then it will be an opaque,
seemingly random value and will not directly reveal any information about the network.
An attacker can match this value across many transmissions to map the extent
of a network beyond what the PANID might already provide.<a href="#section-2-4.32" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="security-considerations">
<section id="section-3">
      <h2 id="name-security-considerations">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-3-1">All of the contents of this IE are transmitted in the clear.
The content of the EB is not encrypted.
This is a restriction in the cryptographic architecture of the 802.15.4 mechanism.
In order to decrypt or do integrity checking of Layer 2 frames in TSCH, the
TSCH ASN is needed.
The EB provides the ASN to new (and long-sleeping) nodes.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">The sensitivity of each field is described within the description of each field.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">The EB is authenticated at the Layer 2 level using 802.15.4
mechanisms using the network-wide keying material.  Nodes that are enrolled
will have the network-wide keying material and can validate the beacon.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">Pledges that have not yet enrolled are unable to authenticate the beacons
and will be forced to temporarily take the contents on faith.
After enrollment, a newly enrolled node will be able to return to the beacon and
validate it.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">In addition to the enrollment and join information described in this
document, the EB contains a description of the TSCH schedule to
be used by the transmitter of this packet.
The schedule can provide an attacker with a list of channels and frequencies
on which communication will occur.
Knowledge of this can help an attacker to more efficiently jam
communications, although there is future work being considered to make some
of the schedule less visible.
Encrypting the schedule does not prevent an attacker from jamming, but rather
increases the energy cost of doing that jamming.<a href="#section-3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="privacy-considerations">
<section id="section-4">
      <h2 id="name-privacy-considerations">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-4-1">The use of a network ID may reveal information about the network.
The use of a SHA-256 hash of the DODAGID (see <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span>), rather than using the DODAGID itself
directly provides some privacy for the addresses used within the network,
as the DODAGID is usually the IPv6 address of the root of the RPL mesh.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">An interloper with a radio sniffer would be able to use the network ID to map
out the extent of the mesh network.<a href="#section-4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-5">
      <h2 id="name-iana-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-5-1">IANA has assigned the following value in the 
"IEEE Std 802.15.4 IETF IE Subtype IDs" registry, as defined by <span>[<a href="#RFC8137" class="xref">RFC8137</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="iana">
<table class="center" id="table-1">
        <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Value</th>
            <th class="text-left" rowspan="1" colspan="1">Subtype ID</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">2</td>
            <td class="text-left" rowspan="1" colspan="1">6tisch-Join-Info</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 9032</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<section id="section-6">
      <h2 id="name-references">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-6.1">
        <h3 id="name-normative-references">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="IEEE.802.15.4">[IEEE.802.15.4]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Low-Rate Wireless Networks"</span>, <span class="seriesInfo">IEEE Standard 802.15.4-2015</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2016.7460875</span>, <time datetime="2016-04" class="refDate">April 2016</time>, <span>&lt;<a href="https://ieeexplore.ieee.org/document/7460875">https://ieeexplore.ieee.org/document/7460875</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="RFC4861">[RFC4861]</dt>
        <dd>
<span class="refAuthor">Narten, T.</span>, <span class="refAuthor">Nordmark, E.</span>, <span class="refAuthor">Simpson, W.</span>, and <span class="refAuthor">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="RFC6775">[RFC6775]</dt>
        <dd>
<span class="refAuthor">Shelby, Z., Ed.</span>, <span class="refAuthor">Chakrabarti, S.</span>, <span class="refAuthor">Nordmark, E.</span>, and <span class="refAuthor">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="RFC8137">[RFC8137]</dt>
        <dd>
<span class="refAuthor">Kivinen, T.</span> and <span class="refAuthor">P. Kinney</span>, <span class="refTitle">"IEEE 802.15.4 Information Element for the IETF"</span>, <span class="seriesInfo">RFC 8137</span>, <span class="seriesInfo">DOI 10.17487/RFC8137</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8137">https://www.rfc-editor.org/info/rfc8137</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="RFC9031">[RFC9031]</dt>
      <dd>
<span class="refAuthor">Vučinić, M., Ed.</span>, <span class="refAuthor">Simon, J.</span>, <span class="refAuthor">Pister, K.</span>, and <span class="refAuthor">M. Richardson</span>, <span class="refTitle">"Constrained Join Protocol (CoJP) for 6TiSCH"</span>, <span class="seriesInfo">RFC 9031</span>, <span class="seriesInfo">DOI 10.17487/RFC9031</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9031">https://www.rfc-editor.org/info/rfc9031</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-6.2">
        <h3 id="name-informative-references">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-roll-enrollment-priority">[NETWORK-ENROLLMENT]</dt>
        <dd>
<span class="refAuthor">Richardson, M.</span>, <span class="refAuthor">Jadhav, R. A.</span>, <span class="refAuthor">Thubert, P.</span>, and <span class="refAuthor">H. She</span>, <span class="refTitle">"Controlling Secure Network Enrollment in RPL networks"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-roll-enrollment-priority-04</span>, <time datetime="2021-02-07" class="refDate">7 February 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-roll-enrollment-priority-04">https://tools.ietf.org/html/draft-ietf-roll-enrollment-priority-04</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>, and <span class="refAuthor">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="RFC6550">[RFC6550]</dt>
        <dd>
<span class="refAuthor">Winter, T., Ed.</span>, <span class="refAuthor">Thubert, P., Ed.</span>, <span class="refAuthor">Brandt, A.</span>, <span class="refAuthor">Hui, J.</span>, <span class="refAuthor">Kelsey, R.</span>, <span class="refAuthor">Levis, P.</span>, <span class="refAuthor">Pister, K.</span>, <span class="refAuthor">Struik, R.</span>, <span class="refAuthor">Vasseur, JP.</span>, and <span class="refAuthor">R. Alexander</span>, <span class="refTitle">"RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"</span>, <span class="seriesInfo">RFC 6550</span>, <span class="seriesInfo">DOI 10.17487/RFC6550</span>, <time datetime="2012-03" class="refDate">March 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6550">https://www.rfc-editor.org/info/rfc6550</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7554">[RFC7554]</dt>
        <dd>
<span class="refAuthor">Watteyne, T., Ed.</span>, <span class="refAuthor">Palattella, M.</span>, and <span class="refAuthor">L. Grieco</span>, <span class="refTitle">"Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement"</span>, <span class="seriesInfo">RFC 7554</span>, <span class="seriesInfo">DOI 10.17487/RFC7554</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7554">https://www.rfc-editor.org/info/rfc7554</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8180">[RFC8180]</dt>
        <dd>
<span class="refAuthor">Vilajosana, X., Ed.</span>, <span class="refAuthor">Pister, K.</span>, and <span class="refAuthor">T. Watteyne</span>, <span class="refTitle">"Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration"</span>, <span class="seriesInfo">BCP 210</span>, <span class="seriesInfo">RFC 8180</span>, <span class="seriesInfo">DOI 10.17487/RFC8180</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8180">https://www.rfc-editor.org/info/rfc8180</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>, and <span class="refAuthor">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>
<dt id="RFC9030">[RFC9030]</dt>
      <dd>
<span class="refAuthor">Thubert, P., Ed.</span>, <span class="refTitle">"An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)"</span>, <span class="seriesInfo">RFC 9030</span>, <span class="seriesInfo">DOI 10.17487/RFC9030</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9030">https://www.rfc-editor.org/info/rfc9030</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acknowledgements">
<section id="section-appendix.a">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.a-1"><span class="contact-name">Thomas Watteyne</span> provided extensive editorial comments on the document.
<span class="contact-name">Carles Gomez Montenegro</span> generated a detailed review of the document at Working Group Last Call.
<span class="contact-name">Tim Evens</span> provided a number of useful editorial suggestions.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <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">Diego Dujovne (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Universidad Diego Portales</span></div>
<div dir="auto" class="left"><span class="street-address">Escuela de Informática y Telecomunicaciones<br>Av. Ejército 441</span></div>
<div dir="auto" class="left"><span class="locality">Santiago</span></div>
<div dir="auto" class="left"><span class="region">Región Metropolitana</span></div>
<div dir="auto" class="left"><span class="country-name">Chile</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+56%20(2)%20676-8121" class="tel">+56 (2) 676-8121</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:diego.dujovne@mail.udp.cl" class="email">diego.dujovne@mail.udp.cl</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Michael Richardson</span></div>
<div dir="auto" class="left"><span class="org">Sandelman Software Works</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mcr+ietf@sandelman.ca" class="email">mcr+ietf@sandelman.ca</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>