File: rfc8799.html

package info (click to toggle)
doc-rfc 20201128-1
links: PTS, VCS
area: non-free
in suites: bullseye
size: 1,307,124 kB
file content (2569 lines) | stat: -rw-r--r-- 147,448 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 8799: Limited Domains and Internet Protocols</title>
<meta content="Brian Carpenter" name="author">
<meta content="Bing Liu" name="author">
<meta content='
       There is a noticeable trend towards network behaviors
      and semantics that are specific to a particular set of requirements
      applied within a limited region of the Internet. Policies, default parameters,
      the options supported, the style of network management, and security
      requirements may vary between such limited regions. This document reviews
      examples of such limited domains (also known as controlled environments),
      notes emerging solutions, and includes a related taxonomy. It then
      briefly discusses the standardization of protocols for limited domains.
      Finally, it shows the need for a precise definition of "limited domain membership"
      and for mechanisms to allow nodes to join a domain securely and to find other
      members, including boundary nodes. 
       
       This document is the product of the research of the authors. It has
      been produced through discussions and consultation within the IETF
      but is not the product of IETF consensus. 
    ' name="description">
<meta content="xml2rfc 2.46.0" name="generator">
<meta content="8799" name="rfc.number">
<link href="rfc8799.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 {
  background-color: #f9f9f9;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8799" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-carpenter-limited-domains-13" 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 8799</td>
<td class="center">Limited Domains</td>
<td class="right">July 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Carpenter &amp; Liu</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8799" class="eref">8799</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-07" class="published">July 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">B. Carpenter</div>
<div class="org">Univ. of Auckland</div>
</div>
<div class="author">
      <div class="author-name">B. Liu</div>
<div class="org">Huawei Technologies</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8799</h1>
<h1 id="title">Limited Domains and Internet Protocols</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">There is a noticeable trend towards network behaviors
      and semantics that are specific to a particular set of requirements
      applied within a limited region of the Internet. Policies, default parameters,
      the options supported, the style of network management, and security
      requirements may vary between such limited regions. This document reviews
      examples of such limited domains (also known as controlled environments),
      notes emerging solutions, and includes a related taxonomy. It then
      briefly discusses the standardization of protocols for limited domains.
      Finally, it shows the need for a precise definition of "limited domain membership"
      and for mechanisms to allow nodes to join a domain securely and to find other
      members, including boundary nodes.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document is the product of the research of the authors. It has
      been produced through discussions and consultation within the IETF
      but is not the product of IETF consensus.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8799">https://www.rfc-editor.org/info/rfc8799</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.<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" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-failure-modes-in-todays-int" class="xref">Failure Modes in Today's Internet</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-examples-of-limited-domain-" class="xref">Examples of Limited Domain Requirements</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-examples-of-limited-domain-s" class="xref">Examples of Limited Domain Solutions</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</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-the-scope-of-protocols-in-l" class="xref">The Scope of Protocols in Limited Domains</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-functional-requirements-of-" class="xref">Functional Requirements of Limited Domains</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</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>
</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>
</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-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</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-taxonomy-of-limited-domains" class="xref">Taxonomy of Limited Domains</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-domain-as-a-whole" class="xref">Domain as a Whole</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-individual-nodes" class="xref">Individual Nodes</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-a.3" class="xref">A.3</a>.  <a href="#name-domain-boundary" class="xref">Domain Boundary</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.4">
                <p id="section-toc.1-1.10.2.4.1"><a href="#section-a.4" class="xref">A.4</a>.  <a href="#name-topology" class="xref">Topology</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.5">
                <p id="section-toc.1-1.10.2.5.1"><a href="#section-a.5" class="xref">A.5</a>.  <a href="#name-technology" class="xref">Technology</a><a href="#section-toc.1-1.10.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.6">
                <p id="section-toc.1-1.10.2.6.1"><a href="#section-a.6" class="xref">A.6</a>.  <a href="#name-connection-to-the-internet" class="xref">Connection to the Internet</a><a href="#section-toc.1-1.10.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.7">
                <p id="section-toc.1-1.10.2.7.1"><a href="#section-a.7" class="xref">A.7</a>.  <a href="#name-security-trust-and-privacy-" class="xref">Security, Trust, and Privacy Model</a><a href="#section-toc.1-1.10.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.8">
                <p id="section-toc.1-1.10.2.8.1"><a href="#section-a.8" class="xref">A.8</a>.  <a href="#name-operations" class="xref">Operations</a><a href="#section-toc.1-1.10.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.9">
                <p id="section-toc.1-1.10.2.9.1"><a href="#section-a.9" class="xref">A.9</a>.  <a href="#name-making-use-of-this-taxonomy" class="xref">Making Use of This Taxonomy</a><a href="#section-toc.1-1.10.2.9.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</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"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</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-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
      As the Internet continues to grow and diversify, with a realistic
      prospect of tens of billions of nodes being connected directly and
      indirectly, there is a noticeable trend towards network-specific and
      local requirements, behaviors, and semantics.  The word "local" should
      be understood in a special sense, however. In some cases, it may refer to
      geographical and physical locality -- all the nodes in a single building,
      on a single campus, or in a given vehicle.  In other cases, it may refer
      to a defined set of users or nodes distributed over a much wider area,
      but drawn together by a single virtual network over the Internet, or a
      single physical network running in parallel with the Internet. We expand
      on these possibilities below. To capture the topic, this document refers
      to such networks as "limited domains". Of course, a similar situation may
      arise for a network that is completely disconnected from the Internet,
      but that is not our direct concern here. However, it should not be
      forgotten that interoperability is needed even within a disconnected
      network.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Some people have concerns about splintering of the Internet along political
     or linguistic boundaries by mechanisms that block the free flow of information.
     That is not the topic of this document, which does not discuss filtering mechanisms
     (see <span>[<a href="#RFC7754" class="xref">RFC7754</a>]</span>) and does not apply to protocols that
     are designed for use across the whole Internet. It is only concerned with domains
     that have specific technical requirements.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">The word "domain" in this document does not refer to naming domains in the DNS,
     although in some cases, a limited domain might incidentally be congruent with
     a DNS domain. In particular, with a "split horizon" DNS configuration 
     <span>[<a href="#RFC6950" class="xref">RFC6950</a>]</span>, the split might be at the edge of a limited domain.
     A recent proposal for defining definite perimeters within the DNS namespace
     <span>[<a href="#I-D.dcrocker-dns-perimeter" class="xref">DNS-PERIMETER</a>]</span> might also be considered to be a limited
     domain mechanism.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Another term that has been used in some contexts is "controlled
      environment".  For example, <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>
      uses this to delimit the operational scope within which a particular
      tunnel encapsulation might be used. A specific example is GRE-in-UDP
      encapsulation <span>[<a href="#RFC8086" class="xref">RFC8086</a>]</span>, which
      explicitly states that "The controlled environment has less restrictive
      requirements than the general Internet." For example,
      non-congestion-controlled traffic might be acceptable within the
      controlled environment. The same phrase has been used to delimit the
      useful scope of quality-of-service protocols <span>[<a href="#RFC6398" class="xref">RFC6398</a>]</span>.  It is not necessarily the case that protocols will
      fail to operate outside the controlled environment, but rather that they
      might not operate optimally. In this document, we assume that "limited
      domain" and "controlled environment" mean the same thing in
      practice. The term "managed network" has been used in a similar way,
      e.g., <span>[<a href="#RFC6947" class="xref">RFC6947</a>]</span>.  In the context of
      secure multicast, a "group domain of interpretation" is defined by <span>[<a href="#RFC6407" class="xref">RFC6407</a>]</span>.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">Yet more definitions of types of domains are to be found in the routing area,
     such as <span>[<a href="#RFC4397" class="xref">RFC4397</a>]</span>, <span>[<a href="#RFC4427" class="xref">RFC4427</a>]</span>, and <span>[<a href="#RFC4655" class="xref">RFC4655</a>]</span>.
     We conclude that the notion of a limited domain is very widespread in many aspects
     of Internet technology.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">The requirements of limited domains will depend on the deployment
      scenario.  Policies, default parameters, and the options supported may
      vary. Also, the style of network management may vary between a
      completely unmanaged network, one with fully autonomic management, one
      with traditional central management, and mixtures of the above. Finally,
      the requirements and solutions for security and privacy may vary.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">
     This document analyzes and discusses some of the consequences of this
     trend and how it may impact the idea of universal interoperability in the
     Internet. First, we list examples of limited domain scenarios and of
     technical solutions for limited domains, with the main focus being
     the Internet layer of the protocol stack. An appendix provides a taxonomy
     of the features to be found in limited domains. With this background, we
     discuss the resulting challenge to the idea that all Internet standards
     must be universal in scope and applicability. To the contrary, we assert
     that some protocols, although needing to be standardized and interoperable,
     also need to be specifically limited in their applicability.
     This implies that the concepts of a limited domain, and of its membership, need
     to be formalized and supported by secure mechanisms. While this document does
     not propose a design for such mechanisms, it does outline some
     functional requirements.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">This document is the product of the research of the authors. It has
      been produced through discussions and consultation within the IETF
      but is not the product of IETF consensus.<a href="#section-1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="fail">
<section id="section-2">
      <h2 id="name-failure-modes-in-todays-int">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-failure-modes-in-todays-int" class="section-name selfRef">Failure Modes in Today's Internet</a>
      </h2>
<p id="section-2-1">Today, the Internet does not have a well-defined concept of limited
      domains. One result of this is that certain protocols and features fail
      on certain paths.  Earlier analyses of this topic have focused either on
      the loss of transparency of the Internet <span>[<a href="#RFC2775" class="xref">RFC2775</a>]</span> <span>[<a href="#RFC4924" class="xref">RFC4924</a>]</span> or on the
      middleboxes responsible for that loss <span>[<a href="#RFC3234" class="xref">RFC3234</a>]</span> <span>[<a href="#RFC7663" class="xref">RFC7663</a>]</span> <span>[<a href="#RFC8517" class="xref">RFC8517</a>]</span>.  Unfortunately, the problems
      persist both in application protocols and even in very fundamental
      mechanisms. For example, the Internet is not transparent to IPv6
      extension headers <span>[<a href="#RFC7872" class="xref">RFC7872</a>]</span>, and Path
      MTU Discovery has been unreliable for many years <span>[<a href="#RFC2923" class="xref">RFC2923</a>]</span> <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>.  IP
      fragmentation is also unreliable <span>[<a href="#I-D.ietf-intarea-frag-fragile" class="xref">FRAG-FRAGILE</a>]</span>, and problems
      in TCP MSS negotiation have been reported <span>[<a href="#I-D.andrews-tcp-and-ipv6-use-minmtu" class="xref">IPV6-USE-MINMTU</a>]</span>.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">On the security side, the widespread insertion of firewalls at domain
      boundaries that are perceived by humans but unknown to protocols results
      in arbitrary failure modes as far as the application layer is
      concerned. There are operational recommendations and practices that
      effectively guarantee arbitrary failures in realistic scenarios <span>[<a href="#I-D.ietf-opsec-ipv6-eh-filtering" class="xref">IPV6-EXT-HEADERS</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">Domain boundaries that are defined administratively (e.g., by address
      filtering rules in routers) are prone to leakage caused by human error,
      especially if the limited domain traffic appears otherwise normal to the
      boundary routers. In this case, the network operator needs to take
      active steps to protect the boundary. This form of leakage is much less
      likely if nodes must be explicitly configured to handle a given
      limited-domain protocol, for example, by installing a specific protocol
      handler.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">Investigations of the unreliability of IP fragmentation
    <span>[<a href="#I-D.ietf-intarea-frag-fragile" class="xref">FRAG-FRAGILE</a>]</span>
    and the filtering of IPv6 extension headers <span>[<a href="#RFC7872" class="xref">RFC7872</a>]</span>
    strongly suggest that at least for
    some protocol elements, transparency is a lost cause and middleboxes are here to stay.
    In the following two sections, we show that some application environments require
    protocol features that cannot, or should not, cross the whole Internet.<a href="#section-2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="example-req">
<section id="section-3">
      <h2 id="name-examples-of-limited-domain-">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-examples-of-limited-domain-" class="section-name selfRef">Examples of Limited Domain Requirements</a>
      </h2>
<p id="section-3-1">This section describes various examples where limited domain requirements can
    easily be identified, either based on an application scenario or on a
    technical imperative. It is, of course, not a complete list, and it is
    presented in an arbitrary order, loosely from smaller to bigger.<a href="#section-3-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3-2">
        <li id="section-3-2.1">A home network. It will be mainly unmanaged, constructed by a non-specialist.
      It must work with devices "out of the box" as shipped by their manufacturers
      and must create adequate security by default. Remote access may be required.
      The requirements and applicable principles are summarized in <span>[<a href="#RFC7368" class="xref">RFC7368</a>]</span>.<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.2">A small office network. This is sometimes very similar to a home network, if whoever
      is in charge has little or no specialist knowledge, but may have
      differing security and privacy requirements. In other cases, it may be professionally
      constructed using recommended products and configurations but operate unmanaged.
      Remote access may be required.<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.3">A vehicle network. This will be designed by the vehicle
        manufacturer but may include devices added by the vehicle's owner or
        operator. Parts of the network will have demanding performance and
        reliability requirements with implications for human safety.  Remote
        access may be required to certain functions but absolutely forbidden
        for others. Communication with other vehicles, roadside
        infrastructure, and external data sources will be required. See <span>[<a href="#I-D.ietf-ipwave-vehicular-networking" class="xref">IPWAVE-NETWORKING</a>]</span> for a
        survey of use cases.<a href="#section-3-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.4">Supervisory Control And Data Acquisition (SCADA) networks and other hard
 real-time networks. These will exhibit specific technical requirements,
 including tough real-time performance targets. See, for example, <span>[<a href="#RFC8578" class="xref">RFC8578</a>]</span> for numerous use cases. An example is a
 building services network. This will be designed specifically for a
 particular building but using standard components. Additional devices may
 need to be added at any time. Parts of the network may have demanding
 reliability requirements with implications for human safety.  Remote access
 may be required to certain functions but absolutely forbidden for others. An
 extreme example is a network used for virtual reality or augmented reality
 applications where the latency requirements are very stringent.<a href="#section-3-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.5">Sensor networks. The two preceding cases will all include sensors,
        but some networks may be specifically limited to sensors and the
        collection and processing of sensor data.  They may be in remote or
        technically challenging locations and installed by
        non-specialists.<a href="#section-3-2.5" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.6">Internet-of-Things (IoT) networks. While this term is very
        flexible and covers many innovative types of networks, including ad hoc
        networks that are formed spontaneously and some applications of 5G
        technology, it seems reasonable to expect that IoT edge networks will
        have special requirements and protocols that are useful only within a
        specific domain, and that these protocols cannot, and for security
        reasons should not, run over the Internet as a whole.<a href="#section-3-2.6" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.7">Constrained Networks. An important subclass of IoT networks consists of constrained
        networks <span>[<a href="#RFC7228" class="xref">RFC7228</a>]</span> in which the nodes
        are limited in power consumption and communications bandwidth and are
        therefore limited to using very frugal protocols.<a href="#section-3-2.7" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.8">Delay-tolerant networks. These may consist of domains that are relatively
        isolated and constrained in power (e.g., deep space networks) and are
        connected only intermittently to the outside, with a very long latency
        on such connections <span>[<a href="#RFC4838" class="xref">RFC4838</a>]</span>. Clearly,
        the protocol requirements and possibilities are very specialized in
        such networks.<a href="#section-3-2.8" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.9">"Traditional" enterprise and campus networks, which may be spread
        over many kilometers and over multiple separate sites, with multiple
        connections to the Internet.  Interestingly, the IETF appears never to
        have analyzed this long-established class of networks in a general
        way, except in connection with IPv6 deployment (e.g., <span>[<a href="#RFC7381" class="xref">RFC7381</a>]</span>).<a href="#section-3-2.9" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.10">Unsuitable standards. A situation that can arise in an enterprise
        network is that the Internet-wide solution for a particular
        requirement may either fail locally or be much more complicated than
        is necessary. An example is that the complexity induced by a mechanism
        such as Interactive Connectivity Establishment (ICE) <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> is not justified within such a
        network.  Furthermore, ICE cannot be used in some cases because
        candidate addresses are not known before a call is established, so a
        different local solution is essential <span>[<a href="#RFC6947" class="xref">RFC6947</a>]</span>.<a href="#section-3-2.10" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.11">Managed wide-area networks run by service providers for enterprise
        services such as Layer 2 (Ethernet, etc.) point-to-point pseudowires,
        multipoint Layer 2 Ethernet VPNs using Virtual Private LAN Service
        (VPLS) or Ethernet VPN (EVPN), and Layer 3 IP VPNs. These are generally characterized
        by service-level agreements for availability, packet loss, and
        possibly multicast service. These are different from the previous
        case in that they mostly run over MPLS infrastructures, and the
        requirements for these services are well defined by the IETF.<a href="#section-3-2.11" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.12">Data centers and hosting centers, or distributed services acting
        as such centers.  These will have high performance, security, and
        privacy requirements and will typically include large numbers of
        independent "tenant" networks overlaid on shared infrastructure.<a href="#section-3-2.12" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.13">Content Delivery Networks (CDNs), comprising distributed data centers and the paths
      between them, spanning thousands of kilometers, with numerous connections to the Internet.<a href="#section-3-2.13" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.14">Massive Web Service Provider Networks. This is a small class of
        networks with well-known trademarked names, combining aspects of
        distributed enterprise networks, data centers, and CDNs. They have
        their own international networks bypassing the generic carriers. Like
        CDNs, they have numerous connections to the Internet, typically
        offering a tailored service in each economy.<a href="#section-3-2.14" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-3-3">Three other aspects, while not tied to specific network types, also strongly
    depend on the concept of limited domains:<a href="#section-3-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3-4">
        <li id="section-3-4.1">Many of the above types of networks may be extended throughout
    the Internet by a variety of virtual private network (VPN) techniques.
    Therefore, we argue that limited domains may overlap each other in an arbitrary
    fashion by use of virtualization techniques. As noted above in the discussion of
    controlled environments, specific tunneling and encapsulation techniques may
    be tailored for use within a given domain.<a href="#section-3-4.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-4.2">Intent-Based Networking. In this concept, a network domain is
        configured and managed in accordance with an abstract policy known as
        "Intent" to ensure that the network performs as required <span>[<a href="#I-D.irtf-nmrg-ibn-concepts-definitions" class="xref">IBN-CONCEPTS</a>]</span>.

        Whatever technologies are used to support this will be applied
        within the domain boundary, even if the services supported in the
        domain are globally accessible.<a href="#section-3-4.2" class="pilcrow">¶</a>
</li>
        <li id="section-3-4.3">Network Slicing. A network slice is a form of virtual network that
        consists of a managed set of resources carved off from a larger
        network <span>[<a href="#I-D.ietf-teas-enhanced-vpn" class="xref">ENHANCED-VPN</a>]</span>.
        This is expected to be significant in 5G deployments <span>[<a href="#I-D.ietf-dmm-5g-uplane-analysis" class="xref">USER-PLANE-PROTOCOL</a>]</span>. Whatever
        technologies are used to support slicing will require a clear
        definition of the boundary of a given slice within a larger
        domain.<a href="#section-3-4.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-3-5">While it is clearly desirable to use common solutions, and therefore common standards,
    wherever possible, it is increasingly difficult to do so while satisfying the widely varying
    requirements outlined above.
    However, there is a tendency when new protocols and protocol extensions are
    proposed to always ask the question "How will this work across the open Internet?"
    This document suggests that this is not always the best question. There are
    protocols and extensions that are not intended to work across the open Internet.
    On the contrary, their requirements and semantics are specifically limited (in the
    sense defined above).<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">A common argument is that if a protocol is intended for limited use, the chances are
    very high that it will in fact be used (or misused) in other scenarios including the
    so-called open Internet. This is undoubtedly true and means that limited use is not
    an excuse for bad design or poor security. In fact, a limited use requirement potentially
    adds complexity to both the protocol and its security design, as discussed later.<a href="#section-3-6" class="pilcrow">¶</a></p>
<p id="section-3-7">Nevertheless, because of the diversity of limited domains with
      specific requirements that is now emerging, specific standards (and ad
      hoc standards) will probably emerge for different types of domains. There
      will be attempts to capture each market sector, but the market will
      demand standardized solutions within each sector.  In addition,
      operational choices will be made that can in fact only work within a
      limited domain. The history of RSVP <span>[<a href="#RFC2205" class="xref">RFC2205</a>]</span> illustrates that a standard defined as if it could
      work over the open Internet might not in fact do so. In general, we can
      no longer assume that a protocol designed according to classical
      Internet guidelines will in fact work reliably across the network as a
      whole. However, the "open Internet" must remain as the universal method
      of interconnection. Reconciling these two aspects is a major
      challenge.<a href="#section-3-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="example-sol">
<section id="section-4">
      <h2 id="name-examples-of-limited-domain-s">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-examples-of-limited-domain-s" class="section-name selfRef">Examples of Limited Domain Solutions</a>
      </h2>
<p id="section-4-1">This section lists various examples of specific limited domain
      solutions that have been proposed or defined. It intentionally does not
      include Layer 2 technology solutions, which by definition apply to
      limited domains. It is worth noting, however, that with recent
      developments such as Transparent Interconnection of Lots of Links
      (TRILL) <span>[<a href="#RFC6325" class="xref">RFC6325</a>]</span> or Shortest Path
      Bridging <span>[<a href="#SPB" class="xref">SPB</a>]</span>, Layer 2 domains may
      become very large.<a href="#section-4-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4-2">
        <li id="section-4-2.1">Differentiated Services. This mechanism <span>[<a href="#RFC2474" class="xref">RFC2474</a>]</span>
    allows a network to assign locally significant
    values to the 6-bit Differentiated Services Code Point
    field in any IP packet. 


Although there are some recommended code point values for specific per-hop
queue management behaviors, these are specifically intended to be
domain-specific code points with traffic being classified, conditioned, and
mapped or re-marked at domain boundaries (unless there is an inter-domain
agreement that makes mapping or re-marking unnecessary).<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.2">Integrated Services. Although it is not intrinsic in
    the design of RSVP <span>[<a href="#RFC2205" class="xref">RFC2205</a>]</span>, it is clear
    from many years' experience that Integrated Services can only
    be deployed successfully within a limited domain that is
    configured with adequate equipment and resources.<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.3">Network function virtualization. As described in
    <span>[<a href="#RFC8568" class="xref">RFC8568</a>]</span>,
    this general concept is an open research topic in which
    virtual network functions are orchestrated as part of
    a distributed system. Inevitably, such orchestration applies
    to an administrative domain of some kind, even though
    cross-domain orchestration is also a research area.<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.4">Service Function Chaining (SFC). This technique <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span> assumes that services within a
        network are constructed as sequences of individual service functions
        within a specific SFC-enabled domain such as a 5G domain. As that RFC
        states: "Specific features may need to be enforced at the boundaries
        of an SFC-enabled domain, for example to avoid leaking SFC
        information". A Network Service Header (NSH) <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> is used to encapsulate packets flowing through the
        service function chain: "The intended scope of the NSH is for use
        within a single provider's operational domain."<a href="#section-4-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.5">
<div id="fast">Firewall and Service Tickets (FAST). Such tickets would accompany a packet
    to claim the right to traverse a network or request a specific network
    service <span>[<a href="#I-D.herbert-fast" class="xref">FAST</a>]</span>.
    They would only be meaningful within a particular domain.<a href="#fast" class="pilcrow">¶</a>
</div>
        </li>
<li id="section-4-2.6">Data Center Network Virtualization Overlays. A common requirement in data
    centers that host many tenants (clients) is to provide each one with a secure
    private network, all running over the same physical infrastructure.
    <span>[<a href="#RFC8151" class="xref">RFC8151</a>]</span> describes various use cases for this, and specifications
    are under development. These include
    use cases in which the tenant network is physically split over several data
    centers, but which must appear to the user as a single secure domain.<a href="#section-4-2.6" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.7">Segment Routing. This is a technique that "steers a packet through
    an ordered list of instructions, called segments"
    <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>. The semantics of
    these instructions are explicitly local to a segment routing domain
    or even to a single node. Technically, these segments or instructions
    are represented as an MPLS label or an IPv6 address, which clearly
    adds a semantic interpretation to them within the domain.<a href="#section-4-2.7" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.8">Autonomic Networking. As explained in <span>[<a href="#I-D.ietf-anima-reference-model" class="xref">REF-MODEL</a>]</span>,
    an autonomic network is also a security domain within which an autonomic
    control plane <span>[<a href="#I-D.ietf-anima-autonomic-control-plane" class="xref">ACP</a>]</span>
    is used by autonomic service agents. These agents manage technical objectives,
    which may be locally defined, subject to domain-wide policy. Thus, the domain
    boundary is important for both security and protocol purposes.<a href="#section-4-2.8" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.9">Homenet. As shown in <span>[<a href="#RFC7368" class="xref">RFC7368</a>]</span>, a home networking
    domain has specific protocol needs that differ from those in an enterprise
    network or the Internet as a whole. These include the Home Network Control
    Protocol (HNCP) <span>[<a href="#RFC7788" class="xref">RFC7788</a>]</span> and a naming and discovery solution
    <span>[<a href="#I-D.ietf-homenet-simple-naming" class="xref">HOMENET-NAMING</a>]</span>.<a href="#section-4-2.9" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.10">
          <p id="section-4-2.10.1">Creative uses of IPv6 features.
    As IPv6 enters more general use, engineers notice that it has much more flexibility
    than IPv4. Innovative suggestions have been made for:<a href="#section-4-2.10.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-2.10.2.1">The flow label, e.g., <span>[<a href="#RFC6294" class="xref">RFC6294</a>]</span>.<a href="#section-4-2.10.2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4-2.10.2.2">Extension headers, e.g., for segment routing <span>[<a href="#RFC8754" class="xref">RFC8754</a>]</span> or Operations, Administration,
            and Maintenance (OAM) marking <span>[<a href="#I-D.ietf-6man-ipv6-alt-mark" class="xref">IPV6-ALT-MARK</a>]</span>.<a href="#section-4-2.10.2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4-2.10.2.3">Meaningful address bits, e.g., <span>[<a href="#I-D.jiang-semantic-prefix" class="xref">EMBEDDED-SEMANTICS</a>]</span>. Also,
            segment routing uses IPv6 addresses as segment identifiers with
            specific local meanings <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>.<a href="#section-4-2.10.2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4-2.10.2.4">If segment routing is used for network programming <span>[<a href="#I-D.ietf-spring-srv6-network-programming" class="xref">SRV6-NETWORK</a>]</span>, IPv6 extension headers can support rather
            complex local functionality.<a href="#section-4-2.10.2.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4-2.10.3">
    The case of the extension header is particularly interesting, since its
    existence has been a major "selling point" for IPv6, but new extension
    headers are notorious for being virtually impossible to deploy across the whole Internet <span>[<a href="#RFC7045" class="xref">RFC7045</a>]</span> <span>[<a href="#RFC7872" class="xref">RFC7872</a>]</span>.  It is worth noting that extension header filtering is
    considered an important security issue <span>[<a href="#I-D.ietf-opsec-ipv6-eh-filtering" class="xref">IPV6-EXT-HEADERS</a>]</span>.  There is
    considerable appetite among vendors or operators to have flexibility in
    defining extension headers for use in limited or specialized domains,
    e.g., <span>[<a href="#I-D.voyer-6man-extension-header-insertion" class="xref">IPV6-SRH</a>]</span>, <span>[<a href="#BIGIP" class="xref">BIGIP</a>]</span>, and <span>[<a href="#I-D.li-6man-app-aware-ipv6-network" class="xref">APP-AWARE</a>]</span>.  Locally
    significant hop-by-hop options are also envisaged, that would be
    understood by routers inside a domain but not elsewhere, e.g., <span>[<a href="#I-D.ietf-ippm-ioam-ipv6-options" class="xref">IN-SITU-OAM</a>]</span>.<a href="#section-4-2.10.3" class="pilcrow">¶</a></p>
</li>
        <li id="section-4-2.11">Deterministic Networking (DetNet). The Deterministic Networking Architecture
    <span>[<a href="#RFC8655" class="xref">RFC8655</a>]</span> and encapsulation
    <span>[<a href="#I-D.ietf-detnet-data-plane-framework" class="xref">DETNET-DATA-PLANE</a>]</span>
    aim to support flows
    with extremely low data loss rates and bounded latency but only
    within a part of the network that is "DetNet aware". Thus, as for
    Differentiated Services above, the concept of a domain is fundamental.<a href="#section-4-2.11" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.12">Provisioning Domains (PvDs). An architecture for Multiple Provisioning
    Domains has been defined <span>[<a href="#RFC7556" class="xref">RFC7556</a>]</span> to allow hosts attached
    to multiple networks to learn explicit details about the services
    provided by each of those networks.<a href="#section-4-2.12" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.13">Address Scopes. For completeness, we mention that, particularly in IPv6,
    some addresses have explicitly limited scope. In particular, link-local addresses
    are limited to a single physical link <span>[<a href="#RFC4291" class="xref">RFC4291</a>]</span>, and
    Unique Local Addresses <span>[<a href="#RFC4193" class="xref">RFC4193</a>]</span> are limited
    to a somewhat loosely defined local site scope. Previously, site-local addresses
    were defined, but they were obsoleted precisely because of
    "the fuzzy nature of the site concept" <span>[<a href="#RFC3879" class="xref">RFC3879</a>]</span>. Multicast
    addresses also have explicit scoping <span>[<a href="#RFC4291" class="xref">RFC4291</a>]</span>.<a href="#section-4-2.13" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.14">As an application-layer example, consider streaming services
    such as IPTV infrastructures that rely on standard protocols,
    but for which access is not globally available.<a href="#section-4-2.14" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-4-3">All of these suggestions are only viable within a specified domain. Nevertheless,
    all of them are clearly intended for multivendor implementation on thousands
    or millions of network domains, so interoperable standardization would be
    beneficial. This argument might seem irrelevant to private or proprietary
    implementations, but these have a strong tendency to become de facto
    standards if they succeed, so the arguments of this document still apply.<a href="#section-4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="scope">
<section id="section-5">
      <h2 id="name-the-scope-of-protocols-in-l">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-the-scope-of-protocols-in-l" class="section-name selfRef">The Scope of Protocols in Limited Domains</a>
      </h2>
<p id="section-5-1">One consequence of the deployment of limited domains in the Internet
      is that some protocols will be designed, extended, or configured so that
      they only work correctly between end systems in such domains.  This is
      to some extent encouraged by some existing standards and by the
      assignment of code points for local or experimental use. In any case, it
      cannot be prevented. Also, by endorsing efforts such as Service Function
      Chaining, Segment Routing, and Deterministic Networking, the IETF is in
      effect encouraging such deployments. Furthermore, it seems inevitable,
      if the Internet of Things becomes reality, that millions of edge
      networks containing completely novel types of nodes will be connected to
      the Internet; each one of these edge networks will be a limited
      domain.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">It is therefore appropriate to discuss whether protocols or protocol
      extensions should sometimes be standardized to interoperate only within
      a limited-domain boundary. Such protocols would not be required to
      interoperate across the Internet as a whole. Various scenarios could
      then arise if there are multiple domains using the limited-domain
      protocol in question:<a href="#section-5-2" class="pilcrow">¶</a></p>
<ol start="1" type="A" class="normal type-A" id="section-5-3">
        <li id="section-5-3.1">
          <p id="section-5-3.1.1"> If a domain is split into two parts connected over the Internet
directly at the IP layer (i.e., with no tunnel encapsulating the packets), a
limited-domain protocol could be operated between those two parts regardless
of its special nature, as long as it respects standard IP formats and is not
arbitrarily blocked by firewalls.  A simple example is any protocol using a
port number assigned to a specific non-IETF protocol.<a href="#section-5-3.1.1" class="pilcrow">¶</a></p>
<p id="section-5-3.1.2">Such a protocol could reasonably be described as an "inter-domain"
protocol because the Internet is transparent to it, even if it is meaningless
except in the two limited domains. This is, of course, nothing new in the
Internet architecture.<a href="#section-5-3.1.2" class="pilcrow">¶</a></p>
</li>
        <li id="section-5-3.2">
          <p id="section-5-3.2.1">If a limited-domain protocol does not respect standard IP formats (for
example, if it includes a non-standard IPv6 extension header), it could not be
operated between two domains connected over the Internet directly at the IP
layer.<a href="#section-5-3.2.1" class="pilcrow">¶</a></p>
<p id="section-5-3.2.2">
Such a protocol could reasonably be described as an "intra-domain" protocol,
and the Internet is opaque to it.<a href="#section-5-3.2.2" class="pilcrow">¶</a></p>
</li>
        <li id="section-5-3.3">
          <p id="section-5-3.3.1">
If a limited-domain protocol is clearly specified to be invalid outside its
domain of origin, neither scenario A nor B applies. The only solution would be
a single virtual domain. For example, an encapsulating tunnel between two
domains could be used to create the virtual domain. Also, nodes at the domain
boundary must drop all packets using the limited-domain protocol.<a href="#section-5-3.3.1" class="pilcrow">¶</a></p>
</li>
        <li id="section-5-3.4">
          <p id="section-5-3.4.1">
If a limited-domain protocol has domain-specific variants, such that
implementations in different domains could not interoperate if those domains
were unified by some mechanism as in scenario C, the protocol is not
interoperable in the normal sense.  If two domains using it were merged, the
protocol might fail unpredictably.  A simple example is any protocol using a
port number assigned for experimental use. Related issues are discussed in
<span>[<a href="#RFC5704" class="xref">RFC5704</a>]</span>, including the complex example of
Transport MPLS.<a href="#section-5-3.4.1" class="pilcrow">¶</a></p>
</li>
      </ol>
<p id="section-5-4">To provide a widespread example, consider Differentiated Services
      <span>[<a href="#RFC2474" class="xref">RFC2474</a>]</span>. A packet containing any value
      whatsoever in the 6 bits of the Differentiated Services Code Point (DSCP)
      is well formed and falls into scenario A. However, because the semantics
      of DSCP values are locally significant, the packet also falls into
      scenario D. In fact, Differentiated Services are only interoperable
      across domain boundaries if there is a corresponding agreement between
      the operators; otherwise, a specific gateway function is required for
      meaningful interoperability.  Much more detailed discussion is
      found in <span>[<a href="#RFC2474" class="xref">RFC2474</a>]</span> and <span>[<a href="#RFC8100" class="xref">RFC8100</a>]</span>.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">To provide a provocative example, consider the proposal in
    <span>[<a href="#I-D.voyer-6man-extension-header-insertion" class="xref">IPV6-SRH</a>]</span> that the restrictions
    in <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span> should be relaxed to allow IPv6 extension headers to
    be inserted on the fly in IPv6 packets. If this is done in such a way that
    the affected packets can never leave the specific limited domain in which they
    were modified, scenario C applies. If the semantic content of the inserted
    headers is locally defined, scenario D also applies. In neither case is
    the Internet outside the limited domain disturbed. However, inside the
    domain, nodes must understand the variant protocol. Unless it is standardized
    as a formal version, with all the complexity that implies <span>[<a href="#RFC6709" class="xref">RFC6709</a>]</span>,
    the nodes must all be non-standard to the extent of understanding
    the variant protocol. For the example of IPv6 header insertion, that
    means non-compliance with <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span> within the domain, even if the
    inserted headers are themselves fully compliant. Apart from the issue
    of formal compliance, such deviations from documented standard behavior
    might lead to significant debugging issues. The possible practical impact
    of the header insertion example is explored in
    <span>[<a href="#I-D.smith-6man-in-flight-eh-insertion-harmful" class="xref">IN-FLIGHT-IPV6</a>]</span>.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">The FAST proposal mentioned in <a href="#fast" class="xref">Section 4, Paragraph 2, Item 5</a> 

    is also an interesting case study.  The semantics of FAST tickets <span>[<a href="#I-D.herbert-fast" class="xref">FAST</a>]</span> have limited scope.  However,
    they are designed in a way that, in principle, allows them to traverse the
    open Internet, as standardized IPv6 hop-by-hop options or even as a
    proposed form of IPv4 extension header <span>[<a href="#I-D.herbert-ipv4-eh" class="xref">IPV4-EXT-HEADERS</a>]</span>. Whether such options can be used reliably across the
    open Internet remains unclear <span>[<a href="#I-D.ietf-opsec-ipv6-eh-filtering" class="xref">IPV6-EXT-HEADERS</a>]</span>.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">We conclude that it is reasonable to explicitly define limited-domain protocols, either
    as standards or as proprietary mechanisms, as long as they describe
    which of the above scenarios apply and they clarify how the domain is defined.
    As long as all relevant standards are respected outside
    the domain boundary, a well-specified limited-domain protocol need not
    damage the rest of the Internet. However, as described in the next section, mechanisms are
    needed to support domain membership operations.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">Note that this conclusion is not a recommendation to abandon the normal
    goal that a standardized protocol should be global in scope and able to
    interoperate across the open Internet. It is simply a recognition
    that this will not always be the case.<a href="#section-5-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="func">
<section id="section-6">
      <h2 id="name-functional-requirements-of-">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-functional-requirements-of-" class="section-name selfRef">Functional Requirements of Limited Domains</a>
      </h2>
<p id="section-6-1">Noting that limited-domain protocols have been defined in the past,
    and that others will undoubtedly be defined in the future, it is useful to consider
    how a protocol can be made aware of the domain within which it operates and how
    the domain boundary nodes can be identified. As the taxonomy in <a href="#taxo" class="xref">Appendix A</a>
    shows, there are numerous aspects to a domain. However,
    we can identify some generally required features and functions that would
    apply partially or completely to many cases.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Today, where limited domains exist, they are essentially created by careful
    configuration of boundary routers and firewalls. If a domain is
    characterized by one or more address prefixes, address assignment to hosts
    must also be carefully managed. This is an error-prone method, and a combination
    of configuration errors and default routing can lead to unwanted traffic escaping
    the domain. Our basic assumption is therefore that it should be possible for domains
    to be created and managed
    automatically, with minimal human configuration. We now discuss
    requirements for automating domain creation and management.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">First, if we drew a topology map, any given domain -- virtual or
      physical -- will have a well-defined boundary between "inside" and
      "outside".  However, that boundary in itself has no technical meaning.
      What matters in reality is whether a node is a member of the
      domain and whether it is at the boundary between the domain and
      the rest of the Internet. Thus, the boundary in itself does not need to
      be identified, but boundary nodes face both inwards and outwards. Inside
      the domain, a sending node needs to know whether it is sending to an
      inside or outside destination, and a receiving node needs to know
      whether a packet originated inside or outside. Also, a boundary node
      needs to know which of its interfaces are inward facing or
      outward facing.  It is irrelevant whether the interfaces involved are
      physical or virtual.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">To underline that domain boundaries need to be identifiable, consider
      the statement from the Deterministic Networking Problem Statement <span>[<a href="#RFC8557" class="xref">RFC8557</a>]</span> that "there is still a lack of
      clarity regarding the limits of a domain where a deterministic path can
      be set up". This remark can certainly be generalized.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">With this perspective, we can list some general functional requirements.
    An underlying assumption here is that domain membership operations should be cryptographically
    secured; a domain without such security cannot be reliably protected from attack.<a href="#section-6-5" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-6-6">
        <li id="section-6-6.1">Domain Identity. A domain must have a unique and verifiable identifier;
    effectively, this should be a public key for the domain. Without this,
    there is no way to secure domain operations and domain membership.
    The holder of the corresponding private key becomes the trust anchor for the domain.<a href="#section-6-6.1" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.2">Nesting. It must be possible for domains to be nested (see, for example, the
    network-slicing example mentioned above).<a href="#section-6-6.2" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.3">Overlapping. It must be possible for nodes and links to be in more than one domain
    (see, for example, the case of PvDs mentioned above).<a href="#section-6-6.3" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.4">Node Eligibility. It must be possible for a node to determine which domain(s)
    it can potentially join and on which interface(s).<a href="#section-6-6.4" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.5">Secure Enrollment. A node must be able to enroll in a given domain
        via secure node identification and to acquire relevant security
        credentials (authorization) for operations within the domain. If a
        node has multiple physical or virtual interfaces, individual
        enrollment for each interface may be required.<a href="#section-6-6.5" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.6">Withdrawal. A node must be able to cancel enrollment in a given
domain.<a href="#section-6-6.6" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.7">Dynamic Membership. Optionally, a node should be able to
        temporarily leave or rejoin a domain (i.e., enrollment is persistent
        but membership is intermittent).<a href="#section-6-6.7" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.8">Role, implying authorization to perform a certain set of actions.
    A node must have a verifiable role. In the simplest case,
    the role choices are "interior node" and "boundary node". In a boundary
    node, individual interfaces may have different roles, e.g., "inward
    facing" and "outward facing".<a href="#section-6-6.8" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.9">Peer Verification. A node must be able to verify whether another
        node is a member of the domain.<a href="#section-6-6.9" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.10">Role Verification. A node should be able to learn the verified role of another node.
    In particular, it should be possible for a node to find boundary nodes (interfacing
    to the Internet).<a href="#section-6-6.10" class="pilcrow">¶</a>
</li>
        <li id="section-6-6.11">Domain Data. In a domain with management requirements, it must
    be possible for a node to acquire domain policy and/or
    domain configuration data. This would include, for example, filtering policy
    to ensure that inappropriate packets do not leave the domain.<a href="#section-6-6.11" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-6-7">These requirements could form the basis for further analysis and solution design.<a href="#section-6-7" class="pilcrow">¶</a></p>
<p id="section-6-8">Another aspect is whether individual packets within a limited domain need to
    carry any sort of indicator that they belong to that domain or whether this
    information will be implicit in the IP addresses of the packet. A related question
    is whether individual packets need cryptographic authentication. This topic is
    for further study.<a href="#section-6-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">As noted above, a protocol intended for limited use may well be
      inadvertently used on the open Internet, so limited use is not an excuse for
      poor security. In fact, a limited use requirement potentially adds
      complexity to the security design.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">Often, the boundary of a limited domain will also act as a security boundary.
      In particular, it will serve as a trust boundary and as a boundary of
      authority for defining capabilities. For example, segment routing <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>
      explicitly uses the concept of a "trusted domain" in this way. Within the boundary,
      limited-domain protocols or protocol features will be useful, but they will in
      many cases be meaningless or harmful if they enter or leave the domain.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">The boundary also serves to provide confidentiality and privacy for operational
      parameters that the operator does not wish to reveal. Note that this is distinct from
      privacy protection for individual users within the domain.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">The security model for a limited-scope protocol must allow for the
      boundary and in particular for a trust model that changes at the
      boundary. Typically, credentials will need to be signed by a
      domain-specific authority.<a href="#section-7-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2"></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-informative-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="I-D.ietf-anima-autonomic-control-plane">[ACP]</dt>
      <dd>
<span class="refAuthor">Eckert, T.</span><span class="refAuthor">, Behringer, M.</span><span class="refAuthor">, and S. Bjarnason</span>, <span class="refTitle">"An Autonomic Control Plane (ACP)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-anima-autonomic-control-plane-27</span>, <time datetime="2020-07-02" class="refDate">2 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-27">https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-27</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.li-6man-app-aware-ipv6-network">[APP-AWARE]</dt>
      <dd>
<span class="refAuthor">Li, Z.</span><span class="refAuthor">, Peng, S.</span><span class="refAuthor">, Li, C.</span><span class="refAuthor">, Xie, C.</span><span class="refAuthor">, Voyer, D.</span><span class="refAuthor">, Li, X.</span><span class="refAuthor">, Liu, P.</span><span class="refAuthor">, Liu, C.</span><span class="refAuthor">, and K. Ebisawa</span>, <span class="refTitle">"Application-aware IPv6 Networking (APN6) Encapsulation"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-li-6man-app-aware-ipv6-network-02</span>, <time datetime="2020-07-02" class="refDate">2 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02">https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="BIGIP">[BIGIP]</dt>
      <dd>
<span class="refAuthor">Li, R.</span>, <span class="refTitle">"HUAWEI - Big IP Initiative"</span>, <time datetime="2018" class="refDate">2018</time>, <span>&lt;<a href="https://www.iaria.org/announcements/HuaweiBigIP.pdf">https://www.iaria.org/announcements/HuaweiBigIP.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-detnet-data-plane-framework">[DETNET-DATA-PLANE]</dt>
      <dd>
<span class="refAuthor">Varga, B.</span><span class="refAuthor">, Farkas, J.</span><span class="refAuthor">, Berger, L.</span><span class="refAuthor">, Malis, A.</span><span class="refAuthor">, and S. Bryant</span>, <span class="refTitle">"DetNet Data Plane Framework"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-detnet-data-plane-framework-06</span>, <time datetime="2020-05-06" class="refDate">6 May 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-06">https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.dcrocker-dns-perimeter">[DNS-PERIMETER]</dt>
      <dd>
<span class="refAuthor">Crocker, D.</span><span class="refAuthor"> and T. Adams</span>, <span class="refTitle">"DNS Perimeter Overlay"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-dcrocker-dns-perimeter-01</span>, <time datetime="2019-06-11" class="refDate">11 June 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-dcrocker-dns-perimeter-01">https://tools.ietf.org/html/draft-dcrocker-dns-perimeter-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.jiang-semantic-prefix">[EMBEDDED-SEMANTICS]</dt>
      <dd>
<span class="refAuthor">Jiang, S.</span><span class="refAuthor">, Qiong, Q.</span><span class="refAuthor">, Farrer, I.</span><span class="refAuthor">, Bo, Y.</span><span class="refAuthor">, and T. Yang</span>, <span class="refTitle">"Analysis of Semantic Embedded IPv6 Address Schemas"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-jiang-semantic-prefix-06</span>, <time datetime="2013-07-15" class="refDate">15 July 2013</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-jiang-semantic-prefix-06">https://tools.ietf.org/html/draft-jiang-semantic-prefix-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-teas-enhanced-vpn">[ENHANCED-VPN]</dt>
      <dd>
<span class="refAuthor">Dong, J.</span><span class="refAuthor">, Bryant, S.</span><span class="refAuthor">, Li, Z.</span><span class="refAuthor">, Miyasaka, T.</span><span class="refAuthor">, and Y. Lee</span>, <span class="refTitle">"A Framework for Enhanced Virtual Private Networks (VPN+) Service"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-teas-enhanced-vpn-06</span>, <time datetime="2020-07-13" class="refDate">13 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-06">https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.herbert-fast">[FAST]</dt>
      <dd>
<span class="refAuthor">Herbert, T.</span>, <span class="refTitle">"Firewall and Service Tickets"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-herbert-fast-04</span>, <time datetime="2019-04-10" class="refDate">10 April 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-herbert-fast-04">https://tools.ietf.org/html/draft-herbert-fast-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-intarea-frag-fragile">[FRAG-FRAGILE]</dt>
      <dd>
<span class="refAuthor">Bonica, R.</span><span class="refAuthor">, Baker, F.</span><span class="refAuthor">, Huston, G.</span><span class="refAuthor">, Hinden, R.</span><span class="refAuthor">, Troan, O.</span><span class="refAuthor">, and F. Gont</span>, <span class="refTitle">"IP Fragmentation Considered Fragile"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-intarea-frag-fragile-17</span>, <time datetime="2019-09-30" class="refDate">30 September 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17">https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-homenet-simple-naming">[HOMENET-NAMING]</dt>
      <dd>
<span class="refAuthor">Lemon, T.</span><span class="refAuthor">, Migault, D.</span><span class="refAuthor">, and S. Cheshire</span>, <span class="refTitle">"Homenet Naming and Service Discovery Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-homenet-simple-naming-03</span>, <time datetime="2018-10-23" class="refDate">23 October 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-03">https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.irtf-nmrg-ibn-concepts-definitions">[IBN-CONCEPTS]</dt>
      <dd>
<span class="refAuthor">Clemm, A.</span><span class="refAuthor">, Ciavaglia, L.</span><span class="refAuthor">, Granville, L.</span><span class="refAuthor">, and J. Tantsura</span>, <span class="refTitle">"Intent-Based Networking - Concepts and Definitions"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-irtf-nmrg-ibn-concepts-definitions-01</span>, <time datetime="2020-03-09" class="refDate">9 March 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-irtf-nmrg-ibn-concepts-definitions-01">https://tools.ietf.org/html/draft-irtf-nmrg-ibn-concepts-definitions-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.smith-6man-in-flight-eh-insertion-harmful">[IN-FLIGHT-IPV6]</dt>
      <dd>
<span class="refAuthor">Smith, M.</span><span class="refAuthor">, Kottapalli, N.</span><span class="refAuthor">, Bonica, R.</span><span class="refAuthor">, Gont, F.</span><span class="refAuthor">, and T. Herbert</span>, <span class="refTitle">"In-Flight IPv6 Extension Header Insertion Considered Harmful"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-smith-6man-in-flight-eh-insertion-harmful-02</span>, <time datetime="2020-05-30" class="refDate">30 May 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-smith-6man-in-flight-eh-insertion-harmful-02">https://tools.ietf.org/html/draft-smith-6man-in-flight-eh-insertion-harmful-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-ippm-ioam-ipv6-options">[IN-SITU-OAM]</dt>
      <dd>
<span class="refAuthor">Bhandari, S.</span><span class="refAuthor">, Brockners, F.</span><span class="refAuthor">, Pignataro, C.</span><span class="refAuthor">, Gredler, H.</span><span class="refAuthor">, Leddy, J.</span><span class="refAuthor">, Youell, S.</span><span class="refAuthor">, Mizrahi, T.</span><span class="refAuthor">, Kfir, A.</span><span class="refAuthor">, Gafni, B.</span><span class="refAuthor">, Lapukhov, P.</span><span class="refAuthor">, Spiegel, M.</span><span class="refAuthor">, Krishnan, S.</span><span class="refAuthor">, and R. Asati</span>, <span class="refTitle">"In-situ OAM IPv6 Options"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-02</span>, <time datetime="2020-07-13" class="refDate">13 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-02">https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.herbert-ipv4-eh">[IPV4-EXT-HEADERS]</dt>
      <dd>
<span class="refAuthor">Herbert, T.</span>, <span class="refTitle">"IPv4 Extension Headers and Flow Label"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-herbert-ipv4-eh-01</span>, <time datetime="2019-05-02" class="refDate">2 May 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-herbert-ipv4-eh-01">https://tools.ietf.org/html/draft-herbert-ipv4-eh-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-6man-ipv6-alt-mark">[IPV6-ALT-MARK]</dt>
      <dd>
<span class="refAuthor">Fioccola, G.</span><span class="refAuthor">, Zhou, T.</span><span class="refAuthor">, Cociglio, M.</span><span class="refAuthor">, Qin, F.</span><span class="refAuthor">, and R. Pang</span>, <span class="refTitle">"IPv6 Application of the Alternate Marking Method"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-6man-ipv6-alt-mark-01</span>, <time datetime="2020-06-22" class="refDate">22 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-01">https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-opsec-ipv6-eh-filtering">[IPV6-EXT-HEADERS]</dt>
      <dd>
<span class="refAuthor">Gont, F.</span><span class="refAuthor"> and W. LIU</span>, <span class="refTitle">"Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-opsec-ipv6-eh-filtering-06</span>, <time datetime="2018-07-02" class="refDate">2 July 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06">https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.voyer-6man-extension-header-insertion">[IPV6-SRH]</dt>
      <dd>
<span class="refAuthor">Voyer, D.</span><span class="refAuthor">, Filsfils, C.</span><span class="refAuthor">, Dukes, D.</span><span class="refAuthor">, Matsushima, S.</span><span class="refAuthor">, Leddy, J.</span><span class="refAuthor">, Li, Z.</span><span class="refAuthor">, and J. Guichard</span>, <span class="refTitle">"Deployments With Insertion of IPv6 Segment Routing Headers"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-voyer-6man-extension-header-insertion-09</span>, <time datetime="2020-05-19" class="refDate">19 May 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-09">https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-09</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.andrews-tcp-and-ipv6-use-minmtu">[IPV6-USE-MINMTU]</dt>
      <dd>
<span class="refAuthor">Andrews, M.</span>, <span class="refTitle">"TCP Fails To Respect IPV6_USE_MIN_MTU"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-andrews-tcp-and-ipv6-use-minmtu-04</span>, <time datetime="2015-10-18" class="refDate">18 October 2015</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-andrews-tcp-and-ipv6-use-minmtu-04">https://tools.ietf.org/html/draft-andrews-tcp-and-ipv6-use-minmtu-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-ipwave-vehicular-networking">[IPWAVE-NETWORKING]</dt>
      <dd>
<span class="refAuthor">Jeong, J.</span>, <span class="refTitle">"IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ipwave-vehicular-networking-16</span>, <time datetime="2020-07-07" class="refDate">7 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-16">https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-16</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-anima-reference-model">[REF-MODEL]</dt>
      <dd>
<span class="refAuthor">Behringer, M.</span><span class="refAuthor">, Carpenter, B.</span><span class="refAuthor">, Eckert, T.</span><span class="refAuthor">, Ciavaglia, L.</span><span class="refAuthor">, and J. Nobre</span>, <span class="refTitle">"A Reference Model for Autonomic Networking"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-anima-reference-model-10</span>, <time datetime="2018-11-22" class="refDate">22 November 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-anima-reference-model-10">https://tools.ietf.org/html/draft-ietf-anima-reference-model-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2205">[RFC2205]</dt>
      <dd>
<span class="refAuthor">Braden, R., Ed.</span><span class="refAuthor">, Zhang, L.</span><span class="refAuthor">, Berson, S.</span><span class="refAuthor">, Herzog, S.</span><span class="refAuthor">, and S. Jamin</span>, <span class="refTitle">"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"</span>, <span class="seriesInfo">RFC 2205</span>, <span class="seriesInfo">DOI 10.17487/RFC2205</span>, <time datetime="1997-09" class="refDate">September 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2205">https://www.rfc-editor.org/info/rfc2205</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2474">[RFC2474]</dt>
      <dd>
<span class="refAuthor">Nichols, K.</span><span class="refAuthor">, Blake, S.</span><span class="refAuthor">, Baker, F.</span><span class="refAuthor">, and D. Black</span>, <span class="refTitle">"Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers"</span>, <span class="seriesInfo">RFC 2474</span>, <span class="seriesInfo">DOI 10.17487/RFC2474</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2474">https://www.rfc-editor.org/info/rfc2474</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2775">[RFC2775]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span>, <span class="refTitle">"Internet Transparency"</span>, <span class="seriesInfo">RFC 2775</span>, <span class="seriesInfo">DOI 10.17487/RFC2775</span>, <time datetime="2000-02" class="refDate">February 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2775">https://www.rfc-editor.org/info/rfc2775</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2923">[RFC2923]</dt>
      <dd>
<span class="refAuthor">Lahey, K.</span>, <span class="refTitle">"TCP Problems with Path MTU Discovery"</span>, <span class="seriesInfo">RFC 2923</span>, <span class="seriesInfo">DOI 10.17487/RFC2923</span>, <time datetime="2000-09" class="refDate">September 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2923">https://www.rfc-editor.org/info/rfc2923</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3234">[RFC3234]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span><span class="refAuthor"> and S. Brim</span>, <span class="refTitle">"Middleboxes: Taxonomy and Issues"</span>, <span class="seriesInfo">RFC 3234</span>, <span class="seriesInfo">DOI 10.17487/RFC3234</span>, <time datetime="2002-02" class="refDate">February 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3234">https://www.rfc-editor.org/info/rfc3234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3879">[RFC3879]</dt>
      <dd>
<span class="refAuthor">Huitema, C.</span><span class="refAuthor"> and B. Carpenter</span>, <span class="refTitle">"Deprecating Site Local Addresses"</span>, <span class="seriesInfo">RFC 3879</span>, <span class="seriesInfo">DOI 10.17487/RFC3879</span>, <time datetime="2004-09" class="refDate">September 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3879">https://www.rfc-editor.org/info/rfc3879</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4193">[RFC4193]</dt>
      <dd>
<span class="refAuthor">Hinden, R.</span><span class="refAuthor"> and B. Haberman</span>, <span class="refTitle">"Unique Local IPv6 Unicast Addresses"</span>, <span class="seriesInfo">RFC 4193</span>, <span class="seriesInfo">DOI 10.17487/RFC4193</span>, <time datetime="2005-10" class="refDate">October 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4193">https://www.rfc-editor.org/info/rfc4193</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4291">[RFC4291]</dt>
      <dd>
<span class="refAuthor">Hinden, R.</span><span class="refAuthor"> and S. Deering</span>, <span class="refTitle">"IP Version 6 Addressing Architecture"</span>, <span class="seriesInfo">RFC 4291</span>, <span class="seriesInfo">DOI 10.17487/RFC4291</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4291">https://www.rfc-editor.org/info/rfc4291</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4397">[RFC4397]</dt>
      <dd>
<span class="refAuthor">Bryskin, I.</span><span class="refAuthor"> and A. Farrel</span>, <span class="refTitle">"A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture"</span>, <span class="seriesInfo">RFC 4397</span>, <span class="seriesInfo">DOI 10.17487/RFC4397</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4397">https://www.rfc-editor.org/info/rfc4397</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4427">[RFC4427]</dt>
      <dd>
<span class="refAuthor">Mannie, E., Ed.</span><span class="refAuthor"> and D. Papadimitriou, Ed.</span>, <span class="refTitle">"Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"</span>, <span class="seriesInfo">RFC 4427</span>, <span class="seriesInfo">DOI 10.17487/RFC4427</span>, <time datetime="2006-03" class="refDate">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4427">https://www.rfc-editor.org/info/rfc4427</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4655">[RFC4655]</dt>
      <dd>
<span class="refAuthor">Farrel, A.</span><span class="refAuthor">, Vasseur, J.-P.</span><span class="refAuthor">, and J. Ash</span>, <span class="refTitle">"A Path Computation Element (PCE)-Based Architecture"</span>, <span class="seriesInfo">RFC 4655</span>, <span class="seriesInfo">DOI 10.17487/RFC4655</span>, <time datetime="2006-08" class="refDate">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4655">https://www.rfc-editor.org/info/rfc4655</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4821">[RFC4821]</dt>
      <dd>
<span class="refAuthor">Mathis, M.</span><span class="refAuthor"> and J. Heffner</span>, <span class="refTitle">"Packetization Layer Path MTU Discovery"</span>, <span class="seriesInfo">RFC 4821</span>, <span class="seriesInfo">DOI 10.17487/RFC4821</span>, <time datetime="2007-03" class="refDate">March 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4821">https://www.rfc-editor.org/info/rfc4821</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4838">[RFC4838]</dt>
      <dd>
<span class="refAuthor">Cerf, V.</span><span class="refAuthor">, Burleigh, S.</span><span class="refAuthor">, Hooke, A.</span><span class="refAuthor">, Torgerson, L.</span><span class="refAuthor">, Durst, R.</span><span class="refAuthor">, Scott, K.</span><span class="refAuthor">, Fall, K.</span><span class="refAuthor">, and H. Weiss</span>, <span class="refTitle">"Delay-Tolerant Networking Architecture"</span>, <span class="seriesInfo">RFC 4838</span>, <span class="seriesInfo">DOI 10.17487/RFC4838</span>, <time datetime="2007-04" class="refDate">April 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4838">https://www.rfc-editor.org/info/rfc4838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4924">[RFC4924]</dt>
      <dd>
<span class="refAuthor">Aboba, B., Ed.</span><span class="refAuthor"> and E. Davies</span>, <span class="refTitle">"Reflections on Internet Transparency"</span>, <span class="seriesInfo">RFC 4924</span>, <span class="seriesInfo">DOI 10.17487/RFC4924</span>, <time datetime="2007-07" class="refDate">July 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4924">https://www.rfc-editor.org/info/rfc4924</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5704">[RFC5704]</dt>
      <dd>
<span class="refAuthor">Bryant, S., Ed.</span><span class="refAuthor">, Morrow, M., Ed.</span><span class="refAuthor">, and IAB</span>, <span class="refTitle">"Uncoordinated Protocol Development Considered Harmful"</span>, <span class="seriesInfo">RFC 5704</span>, <span class="seriesInfo">DOI 10.17487/RFC5704</span>, <time datetime="2009-11" class="refDate">November 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5704">https://www.rfc-editor.org/info/rfc5704</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6294">[RFC6294]</dt>
      <dd>
<span class="refAuthor">Hu, Q.</span><span class="refAuthor"> and B. Carpenter</span>, <span class="refTitle">"Survey of Proposed Use Cases for the IPv6 Flow Label"</span>, <span class="seriesInfo">RFC 6294</span>, <span class="seriesInfo">DOI 10.17487/RFC6294</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6294">https://www.rfc-editor.org/info/rfc6294</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6325">[RFC6325]</dt>
      <dd>
<span class="refAuthor">Perlman, R.</span><span class="refAuthor">, Eastlake 3rd, D.</span><span class="refAuthor">, Dutt, D.</span><span class="refAuthor">, Gai, S.</span><span class="refAuthor">, and A. Ghanwani</span>, <span class="refTitle">"Routing Bridges (RBridges): Base Protocol Specification"</span>, <span class="seriesInfo">RFC 6325</span>, <span class="seriesInfo">DOI 10.17487/RFC6325</span>, <time datetime="2011-07" class="refDate">July 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6325">https://www.rfc-editor.org/info/rfc6325</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6398">[RFC6398]</dt>
      <dd>
<span class="refAuthor">Le Faucheur, F., Ed.</span>, <span class="refTitle">"IP Router Alert Considerations and Usage"</span>, <span class="seriesInfo">BCP 168</span>, <span class="seriesInfo">RFC 6398</span>, <span class="seriesInfo">DOI 10.17487/RFC6398</span>, <time datetime="2011-10" class="refDate">October 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6398">https://www.rfc-editor.org/info/rfc6398</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6407">[RFC6407]</dt>
      <dd>
<span class="refAuthor">Weis, B.</span><span class="refAuthor">, Rowles, S.</span><span class="refAuthor">, and T. Hardjono</span>, <span class="refTitle">"The Group Domain of Interpretation"</span>, <span class="seriesInfo">RFC 6407</span>, <span class="seriesInfo">DOI 10.17487/RFC6407</span>, <time datetime="2011-10" class="refDate">October 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6407">https://www.rfc-editor.org/info/rfc6407</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6709">[RFC6709]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span><span class="refAuthor">, Aboba, B., Ed.</span><span class="refAuthor">, and S. Cheshire</span>, <span class="refTitle">"Design Considerations for Protocol Extensions"</span>, <span class="seriesInfo">RFC 6709</span>, <span class="seriesInfo">DOI 10.17487/RFC6709</span>, <time datetime="2012-09" class="refDate">September 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6709">https://www.rfc-editor.org/info/rfc6709</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6947">[RFC6947]</dt>
      <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor">, Kaplan, H.</span><span class="refAuthor">, Gilman, R.</span><span class="refAuthor">, and S. Veikkolainen</span>, <span class="refTitle">"The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute"</span>, <span class="seriesInfo">RFC 6947</span>, <span class="seriesInfo">DOI 10.17487/RFC6947</span>, <time datetime="2013-05" class="refDate">May 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6947">https://www.rfc-editor.org/info/rfc6947</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6950">[RFC6950]</dt>
      <dd>
<span class="refAuthor">Peterson, J.</span><span class="refAuthor">, Kolkman, O.</span><span class="refAuthor">, Tschofenig, H.</span><span class="refAuthor">, and B. Aboba</span>, <span class="refTitle">"Architectural Considerations on Application Features in the DNS"</span>, <span class="seriesInfo">RFC 6950</span>, <span class="seriesInfo">DOI 10.17487/RFC6950</span>, <time datetime="2013-10" class="refDate">October 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6950">https://www.rfc-editor.org/info/rfc6950</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7045">[RFC7045]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span><span class="refAuthor"> and S. Jiang</span>, <span class="refTitle">"Transmission and Processing of IPv6 Extension Headers"</span>, <span class="seriesInfo">RFC 7045</span>, <span class="seriesInfo">DOI 10.17487/RFC7045</span>, <time datetime="2013-12" class="refDate">December 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7045">https://www.rfc-editor.org/info/rfc7045</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7228">[RFC7228]</dt>
      <dd>
<span class="refAuthor">Bormann, C.</span><span class="refAuthor">, Ersue, M.</span><span class="refAuthor">, and A. Keranen</span>, <span class="refTitle">"Terminology for Constrained-Node Networks"</span>, <span class="seriesInfo">RFC 7228</span>, <span class="seriesInfo">DOI 10.17487/RFC7228</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7228">https://www.rfc-editor.org/info/rfc7228</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7368">[RFC7368]</dt>
      <dd>
<span class="refAuthor">Chown, T., Ed.</span><span class="refAuthor">, Arkko, J.</span><span class="refAuthor">, Brandt, A.</span><span class="refAuthor">, Troan, O.</span><span class="refAuthor">, and J. Weil</span>, <span class="refTitle">"IPv6 Home Networking Architecture Principles"</span>, <span class="seriesInfo">RFC 7368</span>, <span class="seriesInfo">DOI 10.17487/RFC7368</span>, <time datetime="2014-10" class="refDate">October 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7368">https://www.rfc-editor.org/info/rfc7368</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7381">[RFC7381]</dt>
      <dd>
<span class="refAuthor">Chittimaneni, K.</span><span class="refAuthor">, Chown, T.</span><span class="refAuthor">, Howard, L.</span><span class="refAuthor">, Kuarsingh, V.</span><span class="refAuthor">, Pouffary, Y.</span><span class="refAuthor">, and E. Vyncke</span>, <span class="refTitle">"Enterprise IPv6 Deployment Guidelines"</span>, <span class="seriesInfo">RFC 7381</span>, <span class="seriesInfo">DOI 10.17487/RFC7381</span>, <time datetime="2014-10" class="refDate">October 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7381">https://www.rfc-editor.org/info/rfc7381</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7556">[RFC7556]</dt>
      <dd>
<span class="refAuthor">Anipko, D., Ed.</span>, <span class="refTitle">"Multiple Provisioning Domain Architecture"</span>, <span class="seriesInfo">RFC 7556</span>, <span class="seriesInfo">DOI 10.17487/RFC7556</span>, <time datetime="2015-06" class="refDate">June 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7556">https://www.rfc-editor.org/info/rfc7556</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7663">[RFC7663]</dt>
      <dd>
<span class="refAuthor">Trammell, B., Ed.</span><span class="refAuthor"> and M. Kuehlewind, Ed.</span>, <span class="refTitle">"Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)"</span>, <span class="seriesInfo">RFC 7663</span>, <span class="seriesInfo">DOI 10.17487/RFC7663</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7663">https://www.rfc-editor.org/info/rfc7663</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7665">[RFC7665]</dt>
      <dd>
<span class="refAuthor">Halpern, J., Ed.</span><span class="refAuthor"> and C. Pignataro, Ed.</span>, <span class="refTitle">"Service Function Chaining (SFC) Architecture"</span>, <span class="seriesInfo">RFC 7665</span>, <span class="seriesInfo">DOI 10.17487/RFC7665</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7665">https://www.rfc-editor.org/info/rfc7665</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7754">[RFC7754]</dt>
      <dd>
<span class="refAuthor">Barnes, R.</span><span class="refAuthor">, Cooper, A.</span><span class="refAuthor">, Kolkman, O.</span><span class="refAuthor">, Thaler, D.</span><span class="refAuthor">, and E. Nordmark</span>, <span class="refTitle">"Technical Considerations for Internet Service Blocking and Filtering"</span>, <span class="seriesInfo">RFC 7754</span>, <span class="seriesInfo">DOI 10.17487/RFC7754</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7754">https://www.rfc-editor.org/info/rfc7754</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7788">[RFC7788]</dt>
      <dd>
<span class="refAuthor">Stenberg, M.</span><span class="refAuthor">, Barth, S.</span><span class="refAuthor">, and P. Pfister</span>, <span class="refTitle">"Home Networking Control Protocol"</span>, <span class="seriesInfo">RFC 7788</span>, <span class="seriesInfo">DOI 10.17487/RFC7788</span>, <time datetime="2016-04" class="refDate">April 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7788">https://www.rfc-editor.org/info/rfc7788</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7872">[RFC7872]</dt>
      <dd>
<span class="refAuthor">Gont, F.</span><span class="refAuthor">, Linkova, J.</span><span class="refAuthor">, Chown, T.</span><span class="refAuthor">, and W. Liu</span>, <span class="refTitle">"Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World"</span>, <span class="seriesInfo">RFC 7872</span>, <span class="seriesInfo">DOI 10.17487/RFC7872</span>, <time datetime="2016-06" class="refDate">June 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7872">https://www.rfc-editor.org/info/rfc7872</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8085">[RFC8085]</dt>
      <dd>
<span class="refAuthor">Eggert, L.</span><span class="refAuthor">, Fairhurst, G.</span><span class="refAuthor">, and G. Shepherd</span>, <span class="refTitle">"UDP Usage Guidelines"</span>, <span class="seriesInfo">BCP 145</span>, <span class="seriesInfo">RFC 8085</span>, <span class="seriesInfo">DOI 10.17487/RFC8085</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8085">https://www.rfc-editor.org/info/rfc8085</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8086">[RFC8086]</dt>
      <dd>
<span class="refAuthor">Yong, L., Ed.</span><span class="refAuthor">, Crabbe, E.</span><span class="refAuthor">, Xu, X.</span><span class="refAuthor">, and T. Herbert</span>, <span class="refTitle">"GRE-in-UDP Encapsulation"</span>, <span class="seriesInfo">RFC 8086</span>, <span class="seriesInfo">DOI 10.17487/RFC8086</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8086">https://www.rfc-editor.org/info/rfc8086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8100">[RFC8100]</dt>
      <dd>
<span class="refAuthor">Geib, R., Ed.</span><span class="refAuthor"> and D. Black</span>, <span class="refTitle">"Diffserv-Interconnection Classes and Practice"</span>, <span class="seriesInfo">RFC 8100</span>, <span class="seriesInfo">DOI 10.17487/RFC8100</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8100">https://www.rfc-editor.org/info/rfc8100</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8151">[RFC8151]</dt>
      <dd>
<span class="refAuthor">Yong, L.</span><span class="refAuthor">, Dunbar, L.</span><span class="refAuthor">, Toy, M.</span><span class="refAuthor">, Isaac, A.</span><span class="refAuthor">, and V. Manral</span>, <span class="refTitle">"Use Cases for Data Center Network Virtualization Overlay Networks"</span>, <span class="seriesInfo">RFC 8151</span>, <span class="seriesInfo">DOI 10.17487/RFC8151</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8151">https://www.rfc-editor.org/info/rfc8151</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8200">[RFC8200]</dt>
      <dd>
<span class="refAuthor">Deering, S.</span><span class="refAuthor"> and R. Hinden</span>, <span class="refTitle">"Internet Protocol, Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 86</span>, <span class="seriesInfo">RFC 8200</span>, <span class="seriesInfo">DOI 10.17487/RFC8200</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8200">https://www.rfc-editor.org/info/rfc8200</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8300">[RFC8300]</dt>
      <dd>
<span class="refAuthor">Quinn, P., Ed.</span><span class="refAuthor">, Elzur, U., Ed.</span><span class="refAuthor">, and C. Pignataro, Ed.</span>, <span class="refTitle">"Network Service Header (NSH)"</span>, <span class="seriesInfo">RFC 8300</span>, <span class="seriesInfo">DOI 10.17487/RFC8300</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8300">https://www.rfc-editor.org/info/rfc8300</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8402">[RFC8402]</dt>
      <dd>
<span class="refAuthor">Filsfils, C., Ed.</span><span class="refAuthor">, Previdi, S., Ed.</span><span class="refAuthor">, Ginsberg, L.</span><span class="refAuthor">, Decraene, B.</span><span class="refAuthor">, Litkowski, S.</span><span class="refAuthor">, and R. Shakir</span>, <span class="refTitle">"Segment Routing Architecture"</span>, <span class="seriesInfo">RFC 8402</span>, <span class="seriesInfo">DOI 10.17487/RFC8402</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8402">https://www.rfc-editor.org/info/rfc8402</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8445">[RFC8445]</dt>
      <dd>
<span class="refAuthor">Keranen, A.</span><span class="refAuthor">, Holmberg, C.</span><span class="refAuthor">, and J. Rosenberg</span>, <span class="refTitle">"Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal"</span>, <span class="seriesInfo">RFC 8445</span>, <span class="seriesInfo">DOI 10.17487/RFC8445</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8445">https://www.rfc-editor.org/info/rfc8445</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8517">[RFC8517]</dt>
      <dd>
<span class="refAuthor">Dolson, D., Ed.</span><span class="refAuthor">, Snellman, J.</span><span class="refAuthor">, Boucadair, M., Ed.</span><span class="refAuthor">, and C. Jacquenet</span>, <span class="refTitle">"An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective"</span>, <span class="seriesInfo">RFC 8517</span>, <span class="seriesInfo">DOI 10.17487/RFC8517</span>, <time datetime="2019-02" class="refDate">February 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8517">https://www.rfc-editor.org/info/rfc8517</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8557">[RFC8557]</dt>
      <dd>
<span class="refAuthor">Finn, N.</span><span class="refAuthor"> and P. Thubert</span>, <span class="refTitle">"Deterministic Networking Problem Statement"</span>, <span class="seriesInfo">RFC 8557</span>, <span class="seriesInfo">DOI 10.17487/RFC8557</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8557">https://www.rfc-editor.org/info/rfc8557</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8568">[RFC8568]</dt>
      <dd>
<span class="refAuthor">Bernardos, CJ.</span><span class="refAuthor">, Rahman, A.</span><span class="refAuthor">, Zuniga, JC.</span><span class="refAuthor">, Contreras, LM.</span><span class="refAuthor">, Aranda, P.</span><span class="refAuthor">, and P. Lynch</span>, <span class="refTitle">"Network Virtualization Research Challenges"</span>, <span class="seriesInfo">RFC 8568</span>, <span class="seriesInfo">DOI 10.17487/RFC8568</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8568">https://www.rfc-editor.org/info/rfc8568</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8578">[RFC8578]</dt>
      <dd>
<span class="refAuthor">Grossman, E., Ed.</span>, <span class="refTitle">"Deterministic Networking Use Cases"</span>, <span class="seriesInfo">RFC 8578</span>, <span class="seriesInfo">DOI 10.17487/RFC8578</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8578">https://www.rfc-editor.org/info/rfc8578</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8655">[RFC8655]</dt>
      <dd>
<span class="refAuthor">Finn, N.</span><span class="refAuthor">, Thubert, P.</span><span class="refAuthor">, Varga, B.</span><span class="refAuthor">, and J. Farkas</span>, <span class="refTitle">"Deterministic Networking Architecture"</span>, <span class="seriesInfo">RFC 8655</span>, <span class="seriesInfo">DOI 10.17487/RFC8655</span>, <time datetime="2019-10" class="refDate">October 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8655">https://www.rfc-editor.org/info/rfc8655</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8754">[RFC8754]</dt>
      <dd>
<span class="refAuthor">Filsfils, C., Ed.</span><span class="refAuthor">, Dukes, D., Ed.</span><span class="refAuthor">, Previdi, S.</span><span class="refAuthor">, Leddy, J.</span><span class="refAuthor">, Matsushima, S.</span><span class="refAuthor">, and D. Voyer</span>, <span class="refTitle">"IPv6 Segment Routing Header (SRH)"</span>, <span class="seriesInfo">RFC 8754</span>, <span class="seriesInfo">DOI 10.17487/RFC8754</span>, <time datetime="2020-03" class="refDate">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8754">https://www.rfc-editor.org/info/rfc8754</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SPB">[SPB]</dt>
      <dd>
<span class="refTitle">"IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks"</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2018.8403927</span>, <span class="seriesInfo">IEEE 802.1Q-2018</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://ieeexplore.ieee.org/document/8403927">https://ieeexplore.ieee.org/document/8403927</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-spring-srv6-network-programming">[SRV6-NETWORK]</dt>
      <dd>
<span class="refAuthor">Filsfils, C.</span><span class="refAuthor">, Camarillo, P.</span><span class="refAuthor">, Leddy, J.</span><span class="refAuthor">, Voyer, D.</span><span class="refAuthor">, Matsushima, S.</span><span class="refAuthor">, and Z. Li</span>, <span class="refTitle">"SRv6 Network Programming"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-spring-srv6-network-programming-16</span>, <time datetime="2020-06-27" class="refDate">27 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16">https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-dmm-5g-uplane-analysis">[USER-PLANE-PROTOCOL]</dt>
    <dd>
<span class="refAuthor">Homma, S.</span><span class="refAuthor">, Miyasaka, T.</span><span class="refAuthor">, Matsushima, S.</span><span class="refAuthor">, and D. Voyer</span>, <span class="refTitle">"User Plane Protocol and Architectural Analysis on 3GPP 5G System"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-dmm-5g-uplane-analysis-03</span>, <time datetime="2019-11-03" class="refDate">3 November 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-dmm-5g-uplane-analysis-03">https://tools.ietf.org/html/draft-ietf-dmm-5g-uplane-analysis-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<div id="taxo">
<section id="section-appendix.a">
      <h2 id="name-taxonomy-of-limited-domains">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-taxonomy-of-limited-domains" class="section-name selfRef">Taxonomy of Limited Domains</a>
      </h2>
<p id="section-appendix.a-1">This appendix develops a taxonomy for describing limited domains.
    Several major aspects are considered in this taxonomy:<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-appendix.a-2.1">The domain as a whole<a href="#section-appendix.a-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.2">The individual nodes<a href="#section-appendix.a-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.3">The domain boundary<a href="#section-appendix.a-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.4">The domain's topology<a href="#section-appendix.a-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.5">The domain's technology<a href="#section-appendix.a-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.6">How the domain connects to the Internet<a href="#section-appendix.a-2.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.7">The security, trust, and privacy model<a href="#section-appendix.a-2.7" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.a-2.8">Operations<a href="#section-appendix.a-2.8" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-appendix.a-3">The following sub-sections analyze each of these aspects.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<div id="tax-whole">
<section id="section-a.1">
        <h2 id="name-domain-as-a-whole">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-domain-as-a-whole" class="section-name selfRef">Domain as a Whole</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-a.1-1.1">Why does the domain exist? (e.g., human choice, administrative policy,
         orchestration requirements, technical requirements such as
         operational partitioning for scaling reasons)<a href="#section-a.1-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.1-1.2">If there are special requirements, are they at Layer 2,
         Layer 3, or an upper layer?<a href="#section-a.1-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.1-1.3">Where does the domain lie on the spectrum between completely managed by humans and completely autonomic?<a href="#section-a.1-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.1-1.4">If managed, what style of management applies? (Manual configuration,
         automated configuration, orchestration?)<a href="#section-a.1-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.1-1.5">Is there a policy model? (Intent, configuration policies?)<a href="#section-a.1-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.1-1.6">Does the domain provide controlled or paid service or open access?<a href="#section-a.1-1.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="tax-nodes">
<section id="section-a.2">
        <h2 id="name-individual-nodes">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-individual-nodes" class="section-name selfRef">Individual Nodes</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-a.2-1.1">Is a domain member a complete node or only one interface of a node?<a href="#section-a.2-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.2-1.2">Are nodes permanent members of a given domain, or are join and
          leave operations possible?<a href="#section-a.2-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.2-1.3">Are nodes physical or virtual devices?<a href="#section-a.2-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.2-1.4">Are virtual nodes general purpose or limited to specific
          functions, applications, or users?<a href="#section-a.2-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.2-1.5">Are nodes constrained (by battery, etc.)?<a href="#section-a.2-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.2-1.6">Are devices installed "out of the box" or pre-configured?<a href="#section-a.2-1.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="tax-boundary">
<section id="section-a.3">
        <h2 id="name-domain-boundary">
<a href="#section-a.3" class="section-number selfRef">A.3. </a><a href="#name-domain-boundary" class="section-name selfRef">Domain Boundary</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-a.3-1.1">How is the domain boundary identified or defined?<a href="#section-a.3-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.3-1.2">Is the domain boundary fixed or dynamic?<a href="#section-a.3-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.3-1.3">Are boundary nodes special, or can any node be at the boundary?<a href="#section-a.3-1.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="tax-topo">
<section id="section-a.4">
        <h2 id="name-topology">
<a href="#section-a.4" class="section-number selfRef">A.4. </a><a href="#name-topology" class="section-name selfRef">Topology</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-a.4-1.1">Is the domain a subset of a Layer 2 or 3 connectivity domain?<a href="#section-a.4-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-1.2">Does the domain overlap other domains? (In other words, is a
   node allowed to be a member of multiple domains?)<a href="#section-a.4-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-1.3">Does the domain match physical topology, or does it have a virtual (overlay) topology?<a href="#section-a.4-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-1.4">Is the domain in a single building, vehicle, or campus? Or is it
          distributed?<a href="#section-a.4-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-1.5">If distributed, are the interconnections private or over the Internet?<a href="#section-a.4-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-1.6">In IP addressing terms, is the domain Link local, Site local, or Global?<a href="#section-a.4-1.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-1.7">Does the scope of IP unicast or multicast addresses map to the domain boundary?<a href="#section-a.4-1.7" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="tax-tech">
<section id="section-a.5">
        <h2 id="name-technology">
<a href="#section-a.5" class="section-number selfRef">A.5. </a><a href="#name-technology" class="section-name selfRef">Technology</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-a.5-1.1">What routing protocol(s) or different forwarding mechanisms
          (MPLS or other non-IP mechanism) are used?<a href="#section-a.5-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.5-1.2">In an overlay domain, what overlay technique is used (L2VPN,
   L3VPN, etc.)?<a href="#section-a.5-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.5-1.3">Are there specific QoS requirements?<a href="#section-a.5-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.5-1.4">Link latency - Normal or long latency links?<a href="#section-a.5-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.5-1.5">Mobility - Are nodes mobile? Is the whole network mobile?<a href="#section-a.5-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.5-1.6">Which specific technologies, such as those in <a href="#example-sol" class="xref">Section 4</a>,
      are applicable?<a href="#section-a.5-1.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="tax-connect">
<section id="section-a.6">
        <h2 id="name-connection-to-the-internet">
<a href="#section-a.6" class="section-number selfRef">A.6. </a><a href="#name-connection-to-the-internet" class="section-name selfRef">Connection to the Internet</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-a.6-1.1">Is the Internet connection permanent or intermittent?
      (Never connected is out of scope.)<a href="#section-a.6-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.6-1.2">What traffic is blocked, in and out?<a href="#section-a.6-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.6-1.3">What traffic is allowed, in and out?<a href="#section-a.6-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.6-1.4">What traffic is transformed, in and out?<a href="#section-a.6-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.6-1.5">Is secure and privileged remote access needed?<a href="#section-a.6-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.6-1.6">Does the domain allow unprivileged remote sessions?<a href="#section-a.6-1.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="tax-sec">
<section id="section-a.7">
        <h2 id="name-security-trust-and-privacy-">
<a href="#section-a.7" class="section-number selfRef">A.7. </a><a href="#name-security-trust-and-privacy-" class="section-name selfRef">Security, Trust, and Privacy Model</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-a.7-1.1">Must domain members be authorized?<a href="#section-a.7-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.7-1.2">Are all nodes in the domain at the same trust level?<a href="#section-a.7-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.7-1.3">Is traffic authenticated?<a href="#section-a.7-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.7-1.4">Is traffic encrypted?<a href="#section-a.7-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.7-1.5">What is hidden from the outside?<a href="#section-a.7-1.5" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="tax-ops">
<section id="section-a.8">
        <h2 id="name-operations">
<a href="#section-a.8" class="section-number selfRef">A.8. </a><a href="#name-operations" class="section-name selfRef">Operations</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-a.8-1.1">Safety level - Does the domain have a critical (human) safety role?<a href="#section-a.8-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.8-1.2">Reliability requirement - Normal or 99.999%?<a href="#section-a.8-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.8-1.3">Environment - Hazardous conditions?<a href="#section-a.8-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.8-1.4">Installation - Are specialists needed?<a href="#section-a.8-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.8-1.5">Service visits - Easy, difficult, or impossible?<a href="#section-a.8-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.8-1.6">Software/firmware updates - Possible or impossible?<a href="#section-a.8-1.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="tax-usage">
<section id="section-a.9">
        <h2 id="name-making-use-of-this-taxonomy">
<a href="#section-a.9" class="section-number selfRef">A.9. </a><a href="#name-making-use-of-this-taxonomy" class="section-name selfRef">Making Use of This Taxonomy</a>
        </h2>
<p id="section-a.9-1">This taxonomy could be used to design or analyze a specific type of limited domain.
      For the present document, it is intended only to form a background to the 
      scope of protocols used in limited domains and the mechanisms
      required to securely define domain membership and properties.<a href="#section-a.9-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="ack">
<section id="section-appendix.b">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.b-1">Useful comments were received from
      <span class="contact-name">Amelia Andersdotter</span>,
      <span class="contact-name">Edward Birrane</span>,
      <span class="contact-name">David Black</span>,
      <span class="contact-name">Ron Bonica</span>,
      <span class="contact-name">Mohamed Boucadair</span>,
      <span class="contact-name">Tim Chown</span>,
      <span class="contact-name">Darren Dukes</span>,
      <span class="contact-name">Donald Eastlake</span>,
      <span class="contact-name">Adrian Farrel</span>,
      <span class="contact-name">Tom Herbert</span>,
      <span class="contact-name">Ben Kaduk</span>,
      <span class="contact-name">John Klensin</span>,
      <span class="contact-name">Mirja Kuehlewind</span>,
      <span class="contact-name">Warren Kumari</span>,
      <span class="contact-name">Andy Malis</span>,
      <span class="contact-name">Michael Richardson</span>,
      <span class="contact-name">Mark Smith</span>,
      <span class="contact-name">Rick Taylor</span>,
      <span class="contact-name">Niels ten Oever</span>, 
      and others.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="contr">
<section id="section-appendix.c">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Sheng Jiang</span></div>
<div dir="auto" class="left"><span class="org">Huawei Technologies</span></div>
<div dir="auto" class="left"><span class="extended-address">Q14, Huawei Campus</span></div>
<div dir="auto" class="left"><span class="street-address">No. 156 Beiqing Road</span></div>
<div dir="auto" class="left"><span class="locality">Hai-Dian District, Beijing</span></div>
<div dir="auto" class="left"><span class="postal-code">100095</span></div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jiangsheng@huawei.com" class="email">jiangsheng@huawei.com</a>
</div>
</address>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.d">
      <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">Brian Carpenter</span></div>
<div dir="auto" class="left"><span class="org">The University of Auckland</span></div>
<div dir="auto" class="left"><span class="extended-address">School of Computer Science<br>University of Auckland</span></div>
<div dir="auto" class="left"><span class="street-address">PB 92019</span></div>
<div dir="auto" class="left">
<span class="locality">Auckland</span> <span class="postal-code">1142</span>
</div>
<div dir="auto" class="left"><span class="country-name">New Zealand</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:brian.e.carpenter@gmail.com" class="email">brian.e.carpenter@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Bing Liu</span></div>
<div dir="auto" class="left"><span class="org">Huawei Technologies</span></div>
<div dir="auto" class="left"><span class="extended-address">Q14, Huawei Campus</span></div>
<div dir="auto" class="left"><span class="street-address">No. 156 Beiqing Road</span></div>
<div dir="auto" class="left"><span class="locality">Hai-Dian District, Beijing</span></div>
<div dir="auto" class="left"><span class="postal-code">100095</span></div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:leo.liubing@huawei.com" class="email">leo.liubing@huawei.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>