File: rfc9170.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2268 lines) | stat: -rw-r--r-- 109,853 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9170: Long-Term Viability of Protocol Extension Mechanisms</title>
<meta content="Martin Thomson" name="author">
<meta content="Tommy Pauly" name="author">
<meta content="
       The ability to change protocols depends on exercising the extension
      and version-negotiation mechanisms that support change.  This document
      explores how regular use of new protocol features can ensure that it
      remains possible to deploy changes to a protocol. Examples are given
      where lack of use caused changes to be more difficult or costly. 
    " name="description">
<meta content="xml2rfc 3.12.0" name="generator">
<meta content="Extensions" name="keyword">
<meta content="versions" name="keyword">
<meta content="grease" name="keyword">
<meta content="9170" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.0
    Python 3.6.13
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9170.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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#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: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9170" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-iab-use-it-or-lose-it-04" 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 9170</td>
<td class="center">Use It or Lose It</td>
<td class="right">December 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Thomson &amp; Pauly</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Architecture Board (IAB)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9170" class="eref">9170</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-12" class="published">December 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">M. Thomson</div>
</div>
<div class="author">
      <div class="author-name">T. Pauly</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9170</h1>
<h1 id="title">Long-Term Viability of Protocol Extension Mechanisms</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The ability to change protocols depends on exercising the extension
      and version-negotiation mechanisms that support change.  This document
      explores how regular use of new protocol features can ensure that it
      remains possible to deploy changes to a protocol. Examples are given
      where lack of use caused changes to be more difficult or costly.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Architecture Board
            (IAB) and represents information that the IAB has deemed valuable
            to provide for permanent record.  It represents the consensus of the Internet
            Architecture Board (IAB).  Documents approved for publication
            by the IAB 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/rfc9170">https://www.rfc-editor.org/info/rfc9170</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-imperfect-implementations-l" class="xref">Imperfect Implementations Limit Protocol Evolution</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-good-protocol-design-is-not" class="xref">Good Protocol Design Is Not Itself Sufficient</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-disuse-can-hide-problems" class="xref">Disuse Can Hide Problems</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-multi-party-interactions-an" class="xref">Multi-party Interactions and Middleboxes</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-active-use" class="xref">Active Use</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-dependency-is-better" class="xref">Dependency Is Better</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-version-negotiation" class="xref">Version Negotiation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-falsifying-active-use" class="xref">Falsifying Active Use</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-examples-of-active-use" class="xref">Examples of Active Use</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-restoring-active-use" class="xref">Restoring Active Use</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-complementary-techniques" class="xref">Complementary Techniques</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-fewer-extension-points" class="xref">Fewer Extension Points</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-invariants" class="xref">Invariants</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-limiting-participation" class="xref">Limiting Participation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-effective-feedback" class="xref">Effective Feedback</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-examples" class="xref">Examples</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#appendix-A.1" class="xref">A.1</a>.  <a href="#name-dns" class="xref">DNS</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#appendix-A.2" class="xref">A.2</a>.  <a href="#name-http" class="xref">HTTP</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#appendix-A.3" class="xref">A.3</a>.  <a href="#name-ip" class="xref">IP</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#appendix-A.4" class="xref">A.4</a>.  <a href="#name-snmp" class="xref">SNMP</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.5">
                <p id="section-toc.1-1.8.2.5.1"><a href="#appendix-A.5" class="xref">A.5</a>.  <a href="#name-tcp" class="xref">TCP</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.6">
                <p id="section-toc.1-1.8.2.6.1"><a href="#appendix-A.6" class="xref">A.6</a>.  <a href="#name-tls" class="xref">TLS</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-B" class="xref"></a><a href="#name-iab-members-at-the-time-of-" class="xref">IAB Members at the Time of Approval</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-C" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-D" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<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">A successful protocol <span>[<a href="#RFC5218" class="xref">SUCCESS</a>]</span> needs
      to change in ways that allow it to continue to fulfill the changing
      needs of its users.  New use cases, conditions, and constraints on the
      deployment of a protocol can render a protocol that does not change
      obsolete.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Usage patterns and requirements for a protocol shift over time.  In response,
implementations might adjust usage patterns within the constraints of the
protocol, the protocol could be extended, or a replacement protocol might be
developed.  Experience with Internet-scale protocol deployment shows that each
option comes with different costs.  <span>[<a href="#RFC8170" class="xref">TRANSITIONS</a>]</span> examines the
problem of protocol evolution more broadly.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">An extension point is a mechanism that allows a protocol to be changed or
enhanced.  This document examines the specific conditions that determine whether
protocol maintainers have the ability to design and deploy new or modified
protocols via their specified extension points.  <a href="#implementations" class="xref">Section 2</a> highlights
some historical examples of difficulties in transitions to new protocol
features.  <a href="#use-it" class="xref">Section 3</a> argues that ossified protocols are more difficult to
update and describes how successful protocols make frequent use of new
extensions and code points.  <a href="#other" class="xref">Section 4</a> outlines several additional strategies
that might aid in ensuring that protocol changes remain possible over time.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The experience that informs this document is predominantly at "higher" layers of
the network stack, in protocols with limited numbers of participants.  Though
similar issues are present in many protocols that operate at scale, the
trade-offs involved with applying some of the suggested techniques can be more
complex when there are many participants, such as at the network layer or in
routing systems.<a href="#section-1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="implementations">
<section id="section-2">
      <h2 id="name-imperfect-implementations-l">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-imperfect-implementations-l" class="section-name selfRef">Imperfect Implementations Limit Protocol Evolution</a>
      </h2>
<p id="section-2-1">It can be extremely difficult to deploy a change to a protocol if
      implementations with which the new deployment needs to interoperate do
      not operate predictably.  Variation in how new code points or extensions
      are handled can be the result of bugs in implementation or
      specifications.

      Unpredictability can manifest as errors, crashes, timeouts, abrupt
      termination of sessions, or disappearances of endpoints.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">The risk of interoperability problems can in turn make it infeasible
      to deploy certain protocol changes.  If deploying a new code point or
      extension makes an implementation less reliable than others, even if
      only in rare cases, it is far less likely that implementations will
      adopt the change.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">Deploying a change to a protocol could require implementations to fix
      a substantial proportion of the bugs that the change exposes.  This can
      involve a difficult process that includes identifying the cause of these
      errors, finding the responsible implementation(s), coordinating a bug
      fix and release plan, contacting users and/or the operator of affected
      services, and waiting for the fix to be deployed.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">Given the effort involved in fixing problems, the existence of these
      sorts of bugs can outright prevent the deployment of some types of
      protocol changes, especially for protocols involving multiple parties or
      that are considered critical infrastructure (e.g., IP, BGP, DNS, or
      TLS).  It could even be necessary to come up with a new protocol design
      that uses a different method to achieve the same result.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">This document only addresses cases where extensions are not deliberately
blocked.  Some deployments or implementations apply policies that explicitly
prohibit the use of unknown capabilities.  This is especially true of functions
that seek to make security guarantees, like firewalls.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">The set of interoperable features in a protocol is often the subset of its
features that have some value to those implementing and deploying the protocol.
It is not always the case that future extensibility is in that set.<a href="#section-2-6" class="pilcrow">¶</a></p>
<div id="not-good-enough">
<section id="section-2.1">
        <h3 id="name-good-protocol-design-is-not">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-good-protocol-design-is-not" class="section-name selfRef">Good Protocol Design Is Not Itself Sufficient</a>
        </h3>
<p id="section-2.1-1">It is often argued that the careful design of a protocol extension
        point or version-negotiation capability is critical to the freedom
        that it ultimately offers.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">RFC 6709 <span>[<a href="#RFC6709" class="xref">EXTENSIBILITY</a>]</span> contains a great
        deal of well-considered advice on designing for extensions.  It
        includes the following advice:<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<blockquote id="section-2.1-3">
          <p id="section-2.1-3.1">
  This means that, to be useful, a protocol version-negotiation mechanism
  should be simple enough that it can reasonably be assumed that all the
  implementers of the first protocol version at least managed to implement the
  version-negotiation mechanism correctly.<a href="#section-2.1-3.1" class="pilcrow">¶</a></p>
</blockquote>
<p id="section-2.1-4">There are a number of protocols for which this has proven to be insufficient in
practice.  These protocols have imperfect implementations of these mechanisms.
Mechanisms that aren't used are the ones that fail most often.  The same
paragraph from RFC 6709 acknowledges the existence of this problem but does not
offer any remedy:<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<blockquote id="section-2.1-5">
          <p id="section-2.1-5.1">
    The nature of protocol version-negotiation mechanisms is that, by
    definition, they don't get widespread real-world testing until
    <strong>after</strong> the base protocol has been deployed for a while, and its
    deficiencies have become evident.<a href="#section-2.1-5.1" class="pilcrow">¶</a></p>
</blockquote>
<p id="section-2.1-6">Indeed, basic interoperability is considered critical early in the deployment of
a protocol.  A desire to deploy can result in early focus on a reduced feature
set, which could result in deferring implementation of version-negotiation and
extension mechanisms.  This leads to these mechanisms being particularly
affected by this problem.<a href="#section-2.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="disuse">
<section id="section-2.2">
        <h3 id="name-disuse-can-hide-problems">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-disuse-can-hide-problems" class="section-name selfRef">Disuse Can Hide Problems</a>
        </h3>
<p id="section-2.2-1">There are many examples of extension points in protocols that have been either
completely unused or their use was so infrequent that they could no longer be
relied upon to function correctly.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2"><a href="#examples" class="xref">Appendix A</a> includes examples of disuse in a number of widely deployed Internet
protocols.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">Even where extension points have multiple valid values, if the set
        of permitted values does not change over time, there is still a risk
        that new values are not tolerated by existing implementations.  If the
        set of values for a particular field of a protocol or the order in which these
        values appear remains fixed over a long period, some
        implementations might not correctly handle a new value when it is
        introduced.  For example, implementations of TLS broke when new values
        of the signature_algorithms extension were introduced.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="middleboxes">
<section id="section-2.3">
        <h3 id="name-multi-party-interactions-an">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-multi-party-interactions-an" class="section-name selfRef">Multi-party Interactions and Middleboxes</a>
        </h3>
<p id="section-2.3-1">One of the key challenges in deploying new features is ensuring compatibility
with all actors that could be involved in the protocol.  Even the most
superficially simple protocols can often involve more actors than is immediately
apparent.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">The design of extension points needs to consider what actions middleboxes
might take in response to a protocol change as well as the effect those actions
could have on the operation of the protocol.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<p id="section-2.3-3">Deployments of protocol extensions also need to consider the impact
of the changes on entities beyond protocol participants and middleboxes.
Protocol changes can affect the behavior of applications or systems
that don't directly interact with the protocol, such as when a protocol
change modifies the formatting of data delivered to an application.<a href="#section-2.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="use-it">
<section id="section-3">
      <h2 id="name-active-use">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-active-use" class="section-name selfRef">Active Use</a>
      </h2>
<p id="section-3-1">The design of a protocol for extensibility and eventual replacement
      <span>[<a href="#RFC6709" class="xref">EXTENSIBILITY</a>]</span> does not guarantee the ability
      to exercise those options.  The set of features that enable future
      evolution need to be interoperable in the first implementations and
      deployments of the protocol.  Implementation of mechanisms that support
      evolution is necessary to ensure that they remain available for new
      uses, and history has shown this occurs almost exclusively through
      active mechanism use.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Only by using the extension capabilities of a protocol is the
      availability of that capability assured. "Using" here includes
      specifying, implementing, and deploying capabilities that rely on the
      extension capability.  Protocols that fail to use a mechanism, or a
      protocol that only rarely uses a mechanism, could lead to that mechanism
      being unreliable.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">Implementations that routinely see new values are more likely to
      correctly handle new values.  More frequent changes will improve the
      likelihood that incorrect handling or intolerance is discovered and
      rectified.  The longer an intolerant implementation is deployed, the
      more difficult it is to correct.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">Protocols that routinely add new extensions and code points rarely
      have trouble adding additional ones especially when the handling of new
      versions or extensions are well defined.  The definition of mechanisms
      alone is insufficient; it is the assured implementation and active use
      of those mechanisms that determines their availability.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">What constitutes "active use" can depend greatly on the environment
      in which a protocol is deployed.  The frequency of changes necessary to
      safeguard some mechanisms might be slow enough to attract ossification
      in another protocol deployment, while being excessive in others.<a href="#section-3-5" class="pilcrow">¶</a></p>
<div id="need-it">
<section id="section-3.1">
        <h3 id="name-dependency-is-better">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-dependency-is-better" class="section-name selfRef">Dependency Is Better</a>
        </h3>
<p id="section-3.1-1">The easiest way to guarantee that a protocol mechanism is used is
        to make the handling of it critical to an endpoint participating in
        that protocol.  This means that implementations must rely on both the
        existence of extension mechanisms and their continued, repeated
        expansion over time.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">For example, the message format in SMTP relies on header fields for most of its
functions, including the most basic delivery functions.  A deployment of SMTP
cannot avoid including an implementation of header field handling.  In addition
to this, the regularity with which new header fields are defined and used
ensures that deployments frequently encounter header fields that they do not yet
(and may never) understand.  An SMTP implementation therefore needs to be able
to both process header fields that it understands and ignore those that it does
not.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">In this way, implementing the extensibility mechanism is not merely mandated by
the specification, it is crucial to the functioning of a protocol deployment.
Should an implementation fail to correctly implement the mechanism, that failure
would quickly become apparent.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">Caution is advised to avoid assuming that building a dependency on an extension
mechanism is sufficient to ensure availability of that mechanism in the long
term.  If the set of possible uses is narrowly constrained and deployments do
not change over time, implementations might not see new variations or assume a
narrower interpretation of what is possible.  Those implementations might still
exhibit errors when presented with new variations.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="version-negotiation">
<section id="section-3.2">
        <h3 id="name-version-negotiation">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-version-negotiation" class="section-name selfRef">Version Negotiation</a>
        </h3>
<p id="section-3.2-1">As noted in <a href="#not-good-enough" class="xref">Section 2.1</a>,
        protocols that provide version-negotiation mechanisms might not be
        able to test that feature until a new version is deployed.  One
        relatively successful design approach has been to use the protocol
        selection mechanisms built into a lower-layer protocol to select the
        protocol.  This could allow a version-negotiation mechanism to benefit
        from active use of the extension point by other protocols.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">For instance, all published versions of IP contain a version number
        as the four high bits of the first header byte.  However, version
        selection using this field proved to be unsuccessful. Ultimately,
        successful deployment of IPv6 over Ethernet <span>[<a href="#RFC2464" class="xref">RFC2464</a>]</span> required a different EtherType from IPv4.  This
        change took advantage of the already diverse usage of EtherType.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">Other examples of this style of design include Application-Layer
        Protocol Negotiation (<span>[<a href="#RFC7301" class="xref">ALPN</a>]</span>) and
        HTTP content negotiation (<span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19#section-12" class="relref">Section 12</a> of [<a href="#I-D.ietf-httpbis-semantics" class="xref">HTTP</a>]</span>).<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">This technique relies on the code point being usable.  For instance,
        the IP protocol number is known to be unreliable and therefore not
        suitable <span>[<a href="#NEW-PROTOCOLS" class="xref">NEW-PROTOCOLS</a>]</span>.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="grease">
<section id="section-3.3">
        <h3 id="name-falsifying-active-use">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-falsifying-active-use" class="section-name selfRef">Falsifying Active Use</a>
        </h3>
<p id="section-3.3-1">"Grease" was originally defined for TLS <span>[<a href="#RFC8701" class="xref">GREASE</a>]</span> but has been adopted by other protocols such as
 QUIC <span>[<a href="#RFC9000" class="xref">QUIC</a>]</span>.  Grease identifies
 lack of use as an issue (protocol mechanisms "rusting" shut) and
 proposes reserving values for extensions that have no semantic value
 attached.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">The design in <span>[<a href="#RFC8701" class="xref">GREASE</a>]</span> is aimed at
        the style of negotiation most used in TLS, where one endpoint offers a
        set of options and the other chooses the one that it most prefers from
        those that it supports.  An endpoint that uses grease randomly offers
        options, usually just one, from a set of reserved values.  These
        values are guaranteed to never be assigned real meaning, so its peer
        will never have cause to genuinely select one of these values.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">More generally, greasing is used to refer to any attempt to
        exercise extension points without changing endpoint behavior other
        than to encourage participants to tolerate new or varying values of
        protocol elements.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
<p id="section-3.3-4">The principle that grease operates on is that an implementation
        that is regularly exposed to unknown values is less likely to be
        intolerant of new values when they appear.  This depends largely on
        the assumption that the difficulty of implementing the extension
        mechanism correctly is as easy or easier than implementing code to
        identify and filter out reserved values.  Reserving random or unevenly
        distributed values for this purpose is thought to further discourage
        special treatment.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
<p id="section-3.3-5">Without reserved greasing code points, an implementation can use
        code points from spaces used for private or experimental use if such a
        range exists.  In addition to the risk of triggering participation in
        an unwanted experiment, this can be less effective.  Incorrect
        implementations might still be able to identify these code points and
        ignore them.<a href="#section-3.3-5" class="pilcrow">¶</a></p>
<p id="section-3.3-6">In addition to advertising bogus capabilities, an endpoint might
        also selectively disable noncritical protocol elements to test the
        ability of peers to handle the absence of certain capabilities.<a href="#section-3.3-6" class="pilcrow">¶</a></p>
<p id="section-3.3-7">This style of defensive design is limited because it is only
        superficial.  As greasing only mimics active use of an extension
        point, it only exercises a small part of the mechanisms that support
        extensibility.  More critically, it does not easily translate to all
        forms of extension points.  For instance, highest mutually supported
        version (HMSV) negotiation cannot be greased in this fashion.  Other
        techniques might be necessary for protocols that don't rely on the
        particular style of exchange that is predominant in TLS.<a href="#section-3.3-7" class="pilcrow">¶</a></p>
<p id="section-3.3-8">Grease is deployed with the intent of quickly revealing errors in implementing
the mechanisms it safeguards.  Though it has been effective at revealing
problems in some cases with TLS, the efficacy of greasing isn't proven more
generally.  Where implementations are able to tolerate a non-zero error rate in
their operation, greasing offers a potential option for safeguarding future
extensibility.  However, this relies on there being a sufficient proportion of
participants that are willing to invest the effort and tolerate the risk of
interoperability failures.<a href="#section-3.3-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ex-active">
<section id="section-3.4">
        <h3 id="name-examples-of-active-use">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-examples-of-active-use" class="section-name selfRef">Examples of Active Use</a>
        </h3>
<p id="section-3.4-1">Header fields in email <span>[<a href="#RFC5321" class="xref">SMTP</a>]</span>,
        HTTP <span>[<a href="#I-D.ietf-httpbis-semantics" class="xref">HTTP</a>]</span>, and SIP <span>[<a href="#RFC3261" class="xref">SIP</a>]</span> all derive from the same basic
        design, which amounts to a list of name/value pairs.  There is no
        evidence of significant barriers to deploying header fields with new
        names and semantics in email and HTTP as clients and servers generally
        ignore headers they do not understand or need.  The widespread
        deployment of SIP back-to-back user agents (B2BUAs), which generally
        do not ignore unknown fields, means that new SIP header fields do not
        reliably reach peers.  This does not necessarily cause
        interoperability issues in SIP but rather causes features to remain
        unavailable until the B2BUA is updated.  All three protocols are still
        able to deploy new features reliably, but SIP features are deployed
        more slowly due to the larger number of active participants that need
        to support new features.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">As another example, the attribute-value pairs (AVPs) in Diameter
<span>[<a href="#RFC6733" class="xref">DIAMETER</a>]</span> are fundamental to the design of the protocol.  Any use of
Diameter requires exercising the ability to add new AVPs.  This is routinely
done without fear that the new feature might not be successfully deployed.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<p id="section-3.4-3">These examples show extension points that are heavily used are also being
relatively unaffected by deployment issues preventing addition of new values
for new use cases.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<p id="section-3.4-4">These examples show that a good design is not required for success.  On the
contrary, success is often despite shortcomings in the design.  For instance,
the shortcomings of HTTP header fields are significant enough that there are
ongoing efforts to improve the syntax <span>[<a href="#RFC8941" class="xref">HTTP-HEADERS</a>]</span>.<a href="#section-3.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="restoring-active-use">
<section id="section-3.5">
        <h3 id="name-restoring-active-use">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-restoring-active-use" class="section-name selfRef">Restoring Active Use</a>
        </h3>
<p id="section-3.5-1">With enough effort, active use can be used to restore capabilities.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">Extension Mechanisms for DNS (<span>[<a href="#RFC6891" class="xref">EDNS</a>]</span>) was defined to provide extensibility in DNS.
        Intolerance of the extension in DNS servers resulted in a fallback
        method being widely deployed (see <span><a href="https://www.rfc-editor.org/rfc/rfc6891#section-6.2.2" class="relref">Section 6.2.2</a> of [<a href="#RFC6891" class="xref">EDNS</a>]</span>).  This
        fallback resulted in EDNS being disabled for affected servers.  Over
        time, greater support for EDNS and increased reliance on it for
        different features motivated a flag day <span>[<a href="#DNSFLAGDAY" class="xref">DNSFLAGDAY</a>]</span> where the workaround was removed.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<p id="section-3.5-3">The EDNS example shows that effort can be used to restore capabilities.  This is
in part because EDNS was actively used with most resolvers and servers.  It was
therefore possible to force a change to ensure that extension capabilities would
always be available.  However, this required an enormous coordination effort.  A
small number of incompatible servers and the names they serve also became
inaccessible to most clients.<a href="#section-3.5-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="other">
<section id="section-4">
      <h2 id="name-complementary-techniques">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-complementary-techniques" class="section-name selfRef">Complementary Techniques</a>
      </h2>
<p id="section-4-1">The protections to protocol evolution that come from <span><a href="#use-it" class="xref">active use</a> (<a href="#use-it" class="xref">Section 3</a>)</span> can
be improved through the use of other defensive techniques. The techniques listed
here might not prevent ossification on their own, but they can make active use more
effective.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="fewer-extension-points">
<section id="section-4.1">
        <h3 id="name-fewer-extension-points">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-fewer-extension-points" class="section-name selfRef">Fewer Extension Points</a>
        </h3>
<p id="section-4.1-1">A successful protocol will include many potential types of
        extensions.  Designing multiple types of extension mechanisms, each
        suited to a specific purpose, might leave some extension points less
        heavily used than others.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">Disuse of a specialized extension point might render it unusable.
        In contrast, having a smaller number of extension points with wide
        applicability could improve the use of those extension points.  Use of
        a shared extension point for any purpose can protect rarer or more
        specialized uses.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">Both extensions and core protocol elements use the same extension
        points in protocols like HTTP <span>[<a href="#I-D.ietf-httpbis-semantics" class="xref">HTTP</a>]</span> and DIAMETER <span>[<a href="#RFC6733" class="xref">DIAMETER</a>]</span>; see <a href="#ex-active" class="xref">Section 3.4</a>.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="invariants">
<section id="section-4.2">
        <h3 id="name-invariants">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-invariants" class="section-name selfRef">Invariants</a>
        </h3>
<p id="section-4.2-1">Documenting aspects of the protocol that cannot or will not change as extensions
or new versions are added can be a useful exercise. <span><a href="https://www.rfc-editor.org/rfc/rfc5704#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC5704" class="xref">RFC5704</a>]</span>
defines invariants as:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<blockquote id="section-4.2-2">
          <p id="section-4.2-2.1">
    Invariants are core properties that are consistent across the network and
    do not change over extremely long time-scales.<a href="#section-4.2-2.1" class="pilcrow">¶</a></p>
</blockquote>
<p id="section-4.2-3">Understanding what aspects of a protocol are invariant can help guide the
process of identifying those parts of the protocol that might change.
<span>[<a href="#RFC8999" class="xref">QUIC-INVARIANTS</a>]</span> and <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-9.3" class="relref">Section 9.3</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span> are both examples of
documented invariants.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">As a means of protecting extensibility, a declaration of protocol
        invariants is useful only to the extent that protocol participants are
        willing to allow new uses for the protocol.  A protocol that declares
        protocol invariants relies on implementations understanding and
        respecting those invariants.  If active use is not possible for all
        non-invariant parts of the protocol, greasing (<a href="#grease" class="xref">Section 3.3</a>) might be used to improve the chance that
        invariants are respected.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">Protocol invariants need to be clearly and concisely documented.
        Including examples of aspects of the protocol that are not invariant,
        such as <span><a href="https://www.rfc-editor.org/rfc/rfc8999#appendix-A" class="relref">Appendix A</a> of [<a href="#RFC8999" class="xref">QUIC-INVARIANTS</a>]</span>, can be
        used to clarify intent.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="limiting-participation">
<section id="section-4.3">
        <h3 id="name-limiting-participation">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-limiting-participation" class="section-name selfRef">Limiting Participation</a>
        </h3>
<p id="section-4.3-1">Reducing the number of entities that can participate in a protocol
        or limiting the extent of participation can reduce the number of
        entities that might affect extensibility.  Using TLS or other
        cryptographic tools can therefore reduce the number of entities that
        can influence whether new features are usable.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2"><span>[<a href="#RFC8558" class="xref">PATH-SIGNALS</a>]</span> also recommends the use
        of encryption and integrity protection to limit participation.  For
        example, encryption is used by the QUIC protocol <span>[<a href="#RFC9000" class="xref">QUIC</a>]</span> to limit the information that is
        available to middleboxes and integrity protection prevents
        modification.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="effective-feedback">
<section id="section-4.4">
        <h3 id="name-effective-feedback">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-effective-feedback" class="section-name selfRef">Effective Feedback</a>
        </h3>
<p id="section-4.4-1">While not a direct means of protecting extensibility mechanisms,
        feedback systems can be important to discovering problems.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">The visibility of errors is critical to the success of techniques like
        grease (see <a href="#grease" class="xref">Section 3.3</a>).  The grease
        design is most effective if a deployment has a means of detecting and
        reporting errors.  Ignoring errors could allow problems to become
        entrenched.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">Feedback on errors is more important during the development and
        early deployment of a change.  It might also be helpful to disable
        automatic error recovery methods during development.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">Automated feedback systems are important for automated systems, or
        where error recovery is also automated.  For instance, connection
        failures with HTTP alternative services <span>[<a href="#RFC7838" class="xref">ALT-SVC</a>]</span> are not permitted to affect the outcome of
        transactions.  An automated feedback system for capturing failures in
        alternative services is therefore necessary for failures to be
        detected.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<p id="section-4.4-5">How errors are gathered and reported will depend greatly on the
        nature of the protocol deployment and the entity that receives the
        report.  For instance, end users, developers, and network operations
        each have different requirements for how error reports are created,
        managed, and acted upon.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
<p id="section-4.4-6">Automated delivery of error reports can be critical for rectifying
        deployment errors as early as possible, as seen in <span>[<a href="#RFC7489" class="xref">DMARC</a>]</span> and <span>[<a href="#RFC8460" class="xref">SMTP-TLS-REPORTING</a>]</span>.<a href="#section-4.4-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="security-considerations">
<section id="section-5">
      <h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-5-1">Many of the problems identified in this document are not the result
      of deliberate actions by an adversary but more the result of mistakes,
      decisions made without sufficient context, or simple neglect, i.e.,
      problems therefore not the result of opposition by an adversary.  In
      response, the recommended measures generally assume that other protocol
      participants will not take deliberate action to prevent protocol
      evolution.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">The use of cryptographic techniques to exclude potential participants is the
only strong measure that the document recommends.  However, authorized protocol
peers are most often responsible for the identified problems, which can mean
that cryptography is insufficient to exclude them.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">The ability to design, implement, and deploy new protocol mechanisms can be
critical to security.  In particular, it is important to be able to replace
cryptographic algorithms over time <span>[<a href="#RFC7696" class="xref">AGILITY</a>]</span>.  For example,
preparing for the replacement of weak hash algorithms was made more difficult
through misuse <span>[<a href="#HASH" class="xref">HASH</a>]</span>.<a href="#section-5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-6-1">This document has no IANA actions.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-7">
      <h2 id="name-informative-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="RFC7696">[AGILITY]</dt>
      <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms"</span>, <span class="seriesInfo">BCP 201</span>, <span class="seriesInfo">RFC 7696</span>, <span class="seriesInfo">DOI 10.17487/RFC7696</span>, <time datetime="2015-11" class="refDate">November 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7696">https://www.rfc-editor.org/info/rfc7696</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7301">[ALPN]</dt>
      <dd>
<span class="refAuthor">Friedl, S.</span>, <span class="refAuthor">Popov, A.</span>, <span class="refAuthor">Langley, A.</span>, and <span class="refAuthor">E. Stephan</span>, <span class="refTitle">"Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension"</span>, <span class="seriesInfo">RFC 7301</span>, <span class="seriesInfo">DOI 10.17487/RFC7301</span>, <time datetime="2014-07" class="refDate">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7301">https://www.rfc-editor.org/info/rfc7301</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7838">[ALT-SVC]</dt>
      <dd>
<span class="refAuthor">Nottingham, M.</span>, <span class="refAuthor">McManus, P.</span>, and <span class="refAuthor">J. Reschke</span>, <span class="refTitle">"HTTP Alternative Services"</span>, <span class="seriesInfo">RFC 7838</span>, <span class="seriesInfo">DOI 10.17487/RFC7838</span>, <time datetime="2016-04" class="refDate">April 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7838">https://www.rfc-editor.org/info/rfc7838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6733">[DIAMETER]</dt>
      <dd>
<span class="refAuthor">Fajardo, V., Ed.</span>, <span class="refAuthor">Arkko, J.</span>, <span class="refAuthor">Loughney, J.</span>, and <span class="refAuthor">G. Zorn, Ed.</span>, <span class="refTitle">"Diameter Base Protocol"</span>, <span class="seriesInfo">RFC 6733</span>, <span class="seriesInfo">DOI 10.17487/RFC6733</span>, <time datetime="2012-10" class="refDate">October 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6733">https://www.rfc-editor.org/info/rfc6733</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7489">[DMARC]</dt>
      <dd>
<span class="refAuthor">Kucherawy, M., Ed.</span> and <span class="refAuthor">E. Zwicky, Ed.</span>, <span class="refTitle">"Domain-based Message Authentication, Reporting, and Conformance (DMARC)"</span>, <span class="seriesInfo">RFC 7489</span>, <span class="seriesInfo">DOI 10.17487/RFC7489</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7489">https://www.rfc-editor.org/info/rfc7489</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DNSFLAGDAY">[DNSFLAGDAY]</dt>
      <dd>
<span class="refTitle">"DNS Flag Day 2019"</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://dnsflagday.net/2019/">https://dnsflagday.net/2019/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6891">[EDNS]</dt>
      <dd>
<span class="refAuthor">Damas, J.</span>, <span class="refAuthor">Graff, M.</span>, and <span class="refAuthor">P. Vixie</span>, <span class="refTitle">"Extension Mechanisms for DNS (EDNS(0))"</span>, <span class="seriesInfo">STD 75</span>, <span class="seriesInfo">RFC 6891</span>, <span class="seriesInfo">DOI 10.17487/RFC6891</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6891">https://www.rfc-editor.org/info/rfc6891</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="EXT-TCP">[EXT-TCP]</dt>
      <dd>
<span class="refAuthor">Honda, M.</span>, <span class="refAuthor">Nishida, Y.</span>, <span class="refAuthor">Raiciu, C.</span>, <span class="refAuthor">Greenhalgh, A.</span>, <span class="refAuthor">Handley, M.</span>, and <span class="refAuthor">H. Tokuda</span>, <span class="refTitle">"Is it still possible to extend TCP?"</span>, <span class="refContent">IMC '11: Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference</span>, <span class="seriesInfo">DOI 10.1145/2068816.2068834</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://doi.org/10.1145/2068816.2068834">https://doi.org/10.1145/2068816.2068834</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6709">[EXTENSIBILITY]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span>, <span class="refAuthor">Aboba, B., Ed.</span>, and <span class="refAuthor">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="RFC8701">[GREASE]</dt>
      <dd>
<span class="refAuthor">Benjamin, D.</span>, <span class="refTitle">"Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility"</span>, <span class="seriesInfo">RFC 8701</span>, <span class="seriesInfo">DOI 10.17487/RFC8701</span>, <time datetime="2020-01" class="refDate">January 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8701">https://www.rfc-editor.org/info/rfc8701</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="HASH">[HASH]</dt>
      <dd>
<span class="refAuthor">Bellovin, S.</span> and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"Deploying a New Hash Algorithm"</span>, <span class="refContent">Proceedings of NDSS</span>, <time datetime="2006" class="refDate">2006</time>, <span>&lt;<a href="https://www.cs.columbia.edu/~smb/papers/new-hash.pdf">https://www.cs.columbia.edu/~smb/papers/new-hash.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-httpbis-semantics">[HTTP]</dt>
      <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP Semantics"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-httpbis-semantics-19</span>, <time datetime="2021-09" class="refDate">September 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19">https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8941">[HTTP-HEADERS]</dt>
      <dd>
<span class="refAuthor">Nottingham, M.</span> and <span class="refAuthor">P-H. Kamp</span>, <span class="refTitle">"Structured Field Values for HTTP"</span>, <span class="seriesInfo">RFC 8941</span>, <span class="seriesInfo">DOI 10.17487/RFC8941</span>, <time datetime="2021-02" class="refDate">February 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8941">https://www.rfc-editor.org/info/rfc8941</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-httpbis-messaging">[HTTP11]</dt>
      <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP/1.1"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-httpbis-messaging-19</span>, <time datetime="2021-09" class="refDate">September 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-messaging-19">https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-messaging-19</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="INTOLERANCE">[INTOLERANCE]</dt>
      <dd>
<span class="refAuthor">Kario, H.</span>, <span class="refTitle">"Re: [TLS] Thoughts on Version Intolerance"</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://mailarchive.ietf.org/arch/msg/tls/bOJ2JQc3HjAHFFWCiNTIb0JuMZc">https://mailarchive.ietf.org/arch/msg/tls/bOJ2JQc3HjAHFFWCiNTIb0JuMZc</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8684">[MPTCP]</dt>
      <dd>
<span class="refAuthor">Ford, A.</span>, <span class="refAuthor">Raiciu, C.</span>, <span class="refAuthor">Handley, M.</span>, <span class="refAuthor">Bonaventure, O.</span>, and <span class="refAuthor">C. Paasch</span>, <span class="refTitle">"TCP Extensions for Multipath Operation with Multiple Addresses"</span>, <span class="seriesInfo">RFC 8684</span>, <span class="seriesInfo">DOI 10.17487/RFC8684</span>, <time datetime="2020-03" class="refDate">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8684">https://www.rfc-editor.org/info/rfc8684</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MPTCP-HOW-HARD">[MPTCP-HOW-HARD]</dt>
      <dd>
<span class="refAuthor">Raiciu, C.</span>, <span class="refAuthor">Paasch, C.</span>, <span class="refAuthor">Barre, S.</span>, <span class="refAuthor">Ford, A.</span>, <span class="refAuthor">Honda, M.</span>, <span class="refAuthor">Duchene, F.</span>, <span class="refAuthor">Bonaventure, O.</span>, and <span class="refAuthor">M. Handley</span>, <span class="refTitle">"How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP"</span>, <time datetime="2012-04" class="refDate">April 2012</time>, <span>&lt;<a href="https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu">https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NEW-PROTOCOLS">[NEW-PROTOCOLS]</dt>
      <dd>
<span class="refAuthor">Barik, R.</span>, <span class="refAuthor">Welzl, M.</span>, <span class="refAuthor">Fairhurst, G.</span>, <span class="refAuthor">Elmokashfi, A.</span>, <span class="refAuthor">Dreibholz, T.</span>, and <span class="refAuthor">S. Gjessing</span>, <span class="refTitle">"On the usability of transport protocols other than TCP: A home gateway and internet path traversal study"</span>, <span class="refContent">Computer Networks, Vol. 173, pp. 107211</span>, <span class="seriesInfo">DOI 10.1016/j.comnet.2020.107211</span>, <time datetime="2020-05" class="refDate">May 2020</time>, <span>&lt;<a href="https://doi.org/10.1016/j.comnet.2020.107211">https://doi.org/10.1016/j.comnet.2020.107211</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8558">[PATH-SIGNALS]</dt>
      <dd>
<span class="refAuthor">Hardie, T., Ed.</span>, <span class="refTitle">"Transport Protocol Path Signals"</span>, <span class="seriesInfo">RFC 8558</span>, <span class="seriesInfo">DOI 10.17487/RFC8558</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8558">https://www.rfc-editor.org/info/rfc8558</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9000">[QUIC]</dt>
      <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="seriesInfo">RFC 9000</span>, <span class="seriesInfo">DOI 10.17487/RFC9000</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9000">https://www.rfc-editor.org/info/rfc9000</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8999">[QUIC-INVARIANTS]</dt>
      <dd>
<span class="refAuthor">Thomson, M.</span>, <span class="refTitle">"Version-Independent Properties of QUIC"</span>, <span class="seriesInfo">RFC 8999</span>, <span class="seriesInfo">DOI 10.17487/RFC8999</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8999">https://www.rfc-editor.org/info/rfc8999</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2113">[RAv4]</dt>
      <dd>
<span class="refAuthor">Katz, D.</span>, <span class="refTitle">"IP Router Alert Option"</span>, <span class="seriesInfo">RFC 2113</span>, <span class="seriesInfo">DOI 10.17487/RFC2113</span>, <time datetime="1997-02" class="refDate">February 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2113">https://www.rfc-editor.org/info/rfc2113</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2711">[RAv6]</dt>
      <dd>
<span class="refAuthor">Partridge, C.</span> and <span class="refAuthor">A. Jackson</span>, <span class="refTitle">"IPv6 Router Alert Option"</span>, <span class="seriesInfo">RFC 2711</span>, <span class="seriesInfo">DOI 10.17487/RFC2711</span>, <time datetime="1999-10" class="refDate">October 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2711">https://www.rfc-editor.org/info/rfc2711</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0791">[RFC0791]</dt>
      <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 791</span>, <span class="seriesInfo">DOI 10.17487/RFC0791</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc791">https://www.rfc-editor.org/info/rfc791</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1112">[RFC1112]</dt>
      <dd>
<span class="refAuthor">Deering, S.</span>, <span class="refTitle">"Host extensions for IP multicasting"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 1112</span>, <span class="seriesInfo">DOI 10.17487/RFC1112</span>, <time datetime="1989-08" class="refDate">August 1989</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1112">https://www.rfc-editor.org/info/rfc1112</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2464">[RFC2464]</dt>
      <dd>
<span class="refAuthor">Crawford, M.</span>, <span class="refTitle">"Transmission of IPv6 Packets over Ethernet Networks"</span>, <span class="seriesInfo">RFC 2464</span>, <span class="seriesInfo">DOI 10.17487/RFC2464</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2464">https://www.rfc-editor.org/info/rfc2464</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5704">[RFC5704]</dt>
      <dd>
<span class="refAuthor">Bryant, S., Ed.</span>, <span class="refAuthor">Morrow, M., Ed.</span>, and <span class="refAuthor">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="RFC3597">[RRTYPE]</dt>
      <dd>
<span class="refAuthor">Gustafsson, A.</span>, <span class="refTitle">"Handling of Unknown DNS Resource Record (RR) Types"</span>, <span class="seriesInfo">RFC 3597</span>, <span class="seriesInfo">DOI 10.17487/RFC3597</span>, <time datetime="2003-09" class="refDate">September 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3597">https://www.rfc-editor.org/info/rfc3597</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3261">[SIP]</dt>
      <dd>
<span class="refAuthor">Rosenberg, J.</span>, <span class="refAuthor">Schulzrinne, H.</span>, <span class="refAuthor">Camarillo, G.</span>, <span class="refAuthor">Johnston, A.</span>, <span class="refAuthor">Peterson, J.</span>, <span class="refAuthor">Sparks, R.</span>, <span class="refAuthor">Handley, M.</span>, and <span class="refAuthor">E. Schooler</span>, <span class="refTitle">"SIP: Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 3261</span>, <span class="seriesInfo">DOI 10.17487/RFC3261</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5321">[SMTP]</dt>
      <dd>
<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Simple Mail Transfer Protocol"</span>, <span class="seriesInfo">RFC 5321</span>, <span class="seriesInfo">DOI 10.17487/RFC5321</span>, <time datetime="2008-10" class="refDate">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5321">https://www.rfc-editor.org/info/rfc5321</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8460">[SMTP-TLS-REPORTING]</dt>
      <dd>
<span class="refAuthor">Margolis, D.</span>, <span class="refAuthor">Brotman, A.</span>, <span class="refAuthor">Ramakrishnan, B.</span>, <span class="refAuthor">Jones, J.</span>, and <span class="refAuthor">M. Risher</span>, <span class="refTitle">"SMTP TLS Reporting"</span>, <span class="seriesInfo">RFC 8460</span>, <span class="seriesInfo">DOI 10.17487/RFC8460</span>, <time datetime="2018-09" class="refDate">September 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8460">https://www.rfc-editor.org/info/rfc8460</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SNI">[SNI]</dt>
      <dd>
<span class="refAuthor">Langley, A.</span>, <span class="refTitle">"[TLS] Accepting that other SNI name types will never work."</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc">https://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1157">[SNMPv1]</dt>
      <dd>
<span class="refAuthor">Case, J.</span>, <span class="refAuthor">Fedor, M.</span>, <span class="refAuthor">Schoffstall, M.</span>, and <span class="refAuthor">J. Davin</span>, <span class="refTitle">"Simple Network Management Protocol (SNMP)"</span>, <span class="seriesInfo">RFC 1157</span>, <span class="seriesInfo">DOI 10.17487/RFC1157</span>, <time datetime="1990-05" class="refDate">May 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1157">https://www.rfc-editor.org/info/rfc1157</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7208">[SPF]</dt>
      <dd>
<span class="refAuthor">Kitterman, S.</span>, <span class="refTitle">"Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1"</span>, <span class="seriesInfo">RFC 7208</span>, <span class="seriesInfo">DOI 10.17487/RFC7208</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7208">https://www.rfc-editor.org/info/rfc7208</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5218">[SUCCESS]</dt>
      <dd>
<span class="refAuthor">Thaler, D.</span> and <span class="refAuthor">B. Aboba</span>, <span class="refTitle">"What Makes for a Successful Protocol?"</span>, <span class="seriesInfo">RFC 5218</span>, <span class="seriesInfo">DOI 10.17487/RFC5218</span>, <time datetime="2008-07" class="refDate">July 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5218">https://www.rfc-editor.org/info/rfc5218</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0793">[TCP]</dt>
      <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7413">[TFO]</dt>
      <dd>
<span class="refAuthor">Cheng, Y.</span>, <span class="refAuthor">Chu, J.</span>, <span class="refAuthor">Radhakrishnan, S.</span>, and <span class="refAuthor">A. Jain</span>, <span class="refTitle">"TCP Fast Open"</span>, <span class="seriesInfo">RFC 7413</span>, <span class="seriesInfo">DOI 10.17487/RFC7413</span>, <time datetime="2014-12" class="refDate">December 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7413">https://www.rfc-editor.org/info/rfc7413</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6066">[TLS-EXT]</dt>
      <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Transport Layer Security (TLS) Extensions: Extension Definitions"</span>, <span class="seriesInfo">RFC 6066</span>, <span class="seriesInfo">DOI 10.17487/RFC6066</span>, <time datetime="2011-01" class="refDate">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6066">https://www.rfc-editor.org/info/rfc6066</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5246">[TLS12]</dt>
      <dd>
<span class="refAuthor">Dierks, T.</span> and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.2"</span>, <span class="seriesInfo">RFC 5246</span>, <span class="seriesInfo">DOI 10.17487/RFC5246</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5246">https://www.rfc-editor.org/info/rfc5246</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[TLS13]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8170">[TRANSITIONS]</dt>
    <dd>
<span class="refAuthor">Thaler, D., Ed.</span>, <span class="refTitle">"Planning for Protocol Adoption and Subsequent Transitions"</span>, <span class="seriesInfo">RFC 8170</span>, <span class="seriesInfo">DOI 10.17487/RFC8170</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8170">https://www.rfc-editor.org/info/rfc8170</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<div id="examples">
<section id="appendix-A">
      <h2 id="name-examples">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
      </h2>
<p id="appendix-A-1">This appendix contains a brief study of problems in a range of
      Internet protocols at different layers of the stack.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<div id="dns">
<section id="appendix-A.1">
        <h3 id="name-dns">
<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-dns" class="section-name selfRef">DNS</a>
        </h3>
<p id="appendix-A.1-1">Ossified DNS code bases and systems resulted in new Resource Record
        Codes (RRCodes) being unusable. A new code point would take years of
        coordination between implementations and deployments before it could
        be relied upon.

 Consequently, use of the TXT record was overloaded in order to avoid
 the effort and delays involved in allocating new code points; this
 approach was used in the Sender Policy Framework <span>[<a href="#RFC7208" class="xref">SPF</a>]</span> and other protocols.<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.1-2">It was not until after the standard mechanism for dealing with new
        RRCodes <span>[<a href="#RFC3597" class="xref">RRTYPE</a>]</span> was considered
        widely deployed that new RRCodes could be safely created and used.<a href="#appendix-A.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="HTTP">
<section id="appendix-A.2">
        <h3 id="name-http">
<a href="#appendix-A.2" class="section-number selfRef">A.2. </a><a href="#name-http" class="section-name selfRef">HTTP</a>
        </h3>
<p id="appendix-A.2-1">HTTP has a number of very effective extension points in addition to
        the aforementioned header fields.  It also has some examples of
        extension points that are so rarely used that it is possible that they
        are not at all usable.<a href="#appendix-A.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2-2">Extension points in HTTP that might be unwise to use include the
        extension point on each chunk in the chunked transfer coding (<span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-messaging-19#section-7.1" class="relref">Section 7.1</a> of [<a href="#I-D.ietf-httpbis-messaging" class="xref">HTTP11</a>]</span>),
        the ability to use transfer codings other than the chunked coding, and
        the range unit in a range request (<span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19#section-14" class="relref">Section 14</a> of [<a href="#I-D.ietf-httpbis-semantics" class="xref">HTTP</a>]</span>).<a href="#appendix-A.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ip">
<section id="appendix-A.3">
        <h3 id="name-ip">
<a href="#appendix-A.3" class="section-number selfRef">A.3. </a><a href="#name-ip" class="section-name selfRef">IP</a>
        </h3>
<p id="appendix-A.3-1">The version field in IP was rendered useless when encapsulated over
        Ethernet, requiring a new EtherType with IPv6 <span>[<a href="#RFC2464" class="xref">RFC2464</a>]</span>, due in part to Layer 2 devices making
        version-independent assumptions about the structure of the IPv4
        header.<a href="#appendix-A.3-1" class="pilcrow">¶</a></p>
<p id="appendix-A.3-2">Protocol identifiers or code points that are reserved for future use
        can be especially problematic.  Reserving values without attributing
        semantics to their use can result in diverse or conflicting semantics
        being attributed without any hope of interoperability.

 An example of this is the 224/3 address space in IPv4 that <span>[<a href="#RFC0791" class="xref">RFC0791</a>]</span> reserved without assigning any semantics. <span>[<a href="#RFC1112" class="xref">RFC1112</a>]</span> partially reclaimed that reserved address space for
 use in multicast (224/4), but the remaining address space (240/4) has
 not been successfully reclaimed for any purpose.<a href="#appendix-A.3-2" class="pilcrow">¶</a></p>
<p id="appendix-A.3-3">For protocols that can use negotiation to attribute semantics to
        values, it is possible that unused code points can be reclaimed for
        active use, though this requires that the negotiation include all
        protocol participants.  For something as fundamental as addressing,
        negotiation is difficult or even impossible, as all nodes on the
        network path plus potential alternative paths would need to be
        involved.<a href="#appendix-A.3-3" class="pilcrow">¶</a></p>
<p id="appendix-A.3-4">IP Router Alerts <span>[<a href="#RFC2113" class="xref">RAv4</a>]</span><span>[<a href="#RFC2711" class="xref">RAv6</a>]</span> use IP options or extension
        headers to indicate that data is intended for consumption by the next-hop 
        router rather than the addressed destination.  In part, the
        deployment of router alerts was unsuccessful due to the realities of
        processing IP packets at line rates, combined with bad assumptions in
        the protocol design about these performance constraints.  However,
        this was not exclusively down to design problems or bugs, as the
        capability was also deliberately blocked at some routers.<a href="#appendix-A.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="snmp">
<section id="appendix-A.4">
        <h3 id="name-snmp">
<a href="#appendix-A.4" class="section-number selfRef">A.4. </a><a href="#name-snmp" class="section-name selfRef">SNMP</a>
        </h3>
<p id="appendix-A.4-1">As a counter example, the first version of the Simple Network Management
Protocol (SNMP) <span>[<a href="#RFC1157" class="xref">SNMPv1</a>]</span> states that unparseable or unauthenticated
messages are simply discarded without response:<a href="#appendix-A.4-1" class="pilcrow">¶</a></p>
<blockquote id="appendix-A.4-2">
          <p id="appendix-A.4-2.1">It then verifies the version number of the SNMP message. If
            there is a mismatch, it discards the datagram and performs no
            further actions.<a href="#appendix-A.4-2.1" class="pilcrow">¶</a></p>
</blockquote>
<p id="appendix-A.4-3">When SNMP versions 2, 2c, and 3 came along, older agents did exactly
        what the protocol specifies.  Deployment of new versions was likely
        successful because the handling of newer versions was both clear and
        simple.<a href="#appendix-A.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tcp">
<section id="appendix-A.5">
        <h3 id="name-tcp">
<a href="#appendix-A.5" class="section-number selfRef">A.5. </a><a href="#name-tcp" class="section-name selfRef">TCP</a>
        </h3>
<p id="appendix-A.5-1">Extension points in TCP <span>[<a href="#RFC0793" class="xref">TCP</a>]</span>
        have been rendered difficult to use largely due to middlebox
        interactions; see <span>[<a href="#EXT-TCP" class="xref">EXT-TCP</a>]</span>.<a href="#appendix-A.5-1" class="pilcrow">¶</a></p>
<p id="appendix-A.5-2">
For instance, multipath TCP (<span>[<a href="#RFC8684" class="xref">MPTCP</a>]</span>) can
only be deployed opportunistically; see <span>[<a href="#MPTCP-HOW-HARD" class="xref">MPTCP-HOW-HARD</a>]</span>. Since MPTCP is a protocol enhancement that doesn't impair
the connection if it is blocked, network path intolerance of the extension
only results in the multipath functionality becoming unavailable.<a href="#appendix-A.5-2" class="pilcrow">¶</a></p>
<p id="appendix-A.5-3">In comparison, the deployment of TCP Fast Open (<span>[<a href="#RFC7413" class="xref">TFO</a>]</span>) critically depends on extension
        capability being widely available.  Though very few network paths were
        intolerant of the extension in absolute terms, TCP Fast Open could not
        be deployed as a result.<a href="#appendix-A.5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tls">
<section id="appendix-A.6">
        <h3 id="name-tls">
<a href="#appendix-A.6" class="section-number selfRef">A.6. </a><a href="#name-tls" class="section-name selfRef">TLS</a>
        </h3>
<p id="appendix-A.6-1">Transport Layer Security (TLS) <span>[<a href="#RFC5246" class="xref">TLS12</a>]</span> provides examples of where a
design that is objectively sound fails when incorrectly implemented.  TLS
provides examples of failures in protocol version negotiation and extensibility.<a href="#appendix-A.6-1" class="pilcrow">¶</a></p>
<p id="appendix-A.6-2">Version negotiation in TLS 1.2 and earlier uses the "Highest mutually supported
version (HMSV)" scheme exactly as it is described in <span>[<a href="#RFC6709" class="xref">EXTENSIBILITY</a>]</span>.
However, clients are unable to advertise a new version without causing a
non-trivial proportion of sessions to fail due to bugs in server and middlebox
implementations.<a href="#appendix-A.6-2" class="pilcrow">¶</a></p>
<p id="appendix-A.6-3">Intolerance to new TLS versions is so severe <span>[<a href="#INTOLERANCE" class="xref">INTOLERANCE</a>]</span> that TLS 1.3
<span>[<a href="#RFC8446" class="xref">TLS13</a>]</span> abandoned HMSV version negotiation for a new mechanism.<a href="#appendix-A.6-3" class="pilcrow">¶</a></p>
<p id="appendix-A.6-4">The server name indication (SNI) <span>[<a href="#RFC6066" class="xref">TLS-EXT</a>]</span> in TLS is another
excellent example of the failure of a well-designed extensibility point.  SNI
uses the same technique for extensions that is used successfully in other parts
of the TLS protocol.  The original design of SNI anticipated the ability to
include multiple names of different types.<a href="#appendix-A.6-4" class="pilcrow">¶</a></p>
<p id="appendix-A.6-5">SNI was originally defined with just one type of name: a domain name.  No other
type has ever been standardized, though several have been proposed.  Despite an
otherwise exemplary design, SNI is so inconsistently implemented that any hope
for using the extension point it defines has been abandoned <span>[<a href="#SNI" class="xref">SNI</a>]</span>.<a href="#appendix-A.6-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="appendix-B">
      <h2 id="name-iab-members-at-the-time-of-">
<a href="#name-iab-members-at-the-time-of-" class="section-name selfRef">IAB Members at the Time of Approval</a>
      </h2>
<p id="appendix-B-1">
 Internet Architecture Board members at the time this document was
 approved for publication were:<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty">
<li class="compact ulEmpty" id="appendix-B-2.1">
          <p id="appendix-B-2.1.1"><span class="contact-name">Jari Arkko</span><a href="#appendix-B-2.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.2">
          <p id="appendix-B-2.2.1"><span class="contact-name">Deborah Brungard</span><a href="#appendix-B-2.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.3">
          <p id="appendix-B-2.3.1"><span class="contact-name">Ben Campbell</span><a href="#appendix-B-2.3.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.4">
          <p id="appendix-B-2.4.1"><span class="contact-name">Lars Eggert</span><a href="#appendix-B-2.4.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.5">
          <p id="appendix-B-2.5.1"><span class="contact-name">Wes Hardaker</span><a href="#appendix-B-2.5.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.6">
          <p id="appendix-B-2.6.1"><span class="contact-name">Cullen Jennings</span><a href="#appendix-B-2.6.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.7">
          <p id="appendix-B-2.7.1"><span class="contact-name">Mirja Kühlewind</span><a href="#appendix-B-2.7.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.8">
          <p id="appendix-B-2.8.1"><span class="contact-name">Zhenbin Li</span><a href="#appendix-B-2.8.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.9">
          <p id="appendix-B-2.9.1"><span class="contact-name">Jared Mauch</span><a href="#appendix-B-2.9.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.10">
          <p id="appendix-B-2.10.1"><span class="contact-name">Tommy Pauly</span><a href="#appendix-B-2.10.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.11">
          <p id="appendix-B-2.11.1"><span class="contact-name">David Schinazi</span><a href="#appendix-B-2.11.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.12">
          <p id="appendix-B-2.12.1"><span class="contact-name">Russ White</span><a href="#appendix-B-2.12.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="appendix-B-2.13">
          <p id="appendix-B-2.13.1"><span class="contact-name">Jiankang Yao</span><a href="#appendix-B-2.13.1" class="pilcrow">¶</a></p>
</li>
      </ul>
</section>
<div id="acknowledgments">
<section id="appendix-C">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-C-1"><span class="contact-name">Toerless Eckert</span>, <span class="contact-name">Wes Hardaker</span>, <span class="contact-name">Mirja Kühlewind</span>, <span class="contact-name">Eliot Lear</span>, <span class="contact-name">Mark Nottingham</span>, and
<span class="contact-name">Brian Trammell</span> made significant contributions to this document.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="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">Martin Thomson</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mt@lowentropy.net" class="email">mt@lowentropy.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Tommy Pauly</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:tpauly@apple.com" class="email">tpauly@apple.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>