File: rfc9065.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 (3483 lines) | stat: -rw-r--r-- 220,559 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 9065: Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols</title>
<meta content="Godred Fairhurst" name="author">
<meta content="Colin Perkins" name="author">
<meta content="
       To protect user data and privacy, Internet transport protocols have
      supported payload encryption and authentication for some time. Such
      encryption and authentication are now also starting to be applied to the
      transport protocol headers. This helps avoid transport protocol
      ossification by middleboxes, mitigate attacks against the transport
      protocol, and protect metadata about the communication. Current
      operational practice in some networks inspect transport header
      information within the network, but this is no longer possible when
      those transport headers are encrypted. 
       This document discusses the possible impact when network traffic uses
      a protocol with an encrypted transport header. It suggests issues to
      consider when designing new transport protocols or features. 
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="transport design" name="keyword">
<meta content="operations and management" name="keyword">
<meta content="9065" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9065.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;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9065" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt-21" 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 9065</td>
<td class="center">Transport Header Encryption</td>
<td class="right">July 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Fairhurst &amp; Perkins</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 Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9065" class="eref">9065</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-07" class="published">July 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">G. Fairhurst</div>
<div class="org">University of Aberdeen</div>
</div>
<div class="author">
      <div class="author-name">C. Perkins</div>
<div class="org">University of Glasgow</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9065</h1>
<h1 id="title">Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">To protect user data and privacy, Internet transport protocols have
      supported payload encryption and authentication for some time. Such
      encryption and authentication are now also starting to be applied to the
      transport protocol headers. This helps avoid transport protocol
      ossification by middleboxes, mitigate attacks against the transport
      protocol, and protect metadata about the communication. Current
      operational practice in some networks inspect transport header
      information within the network, but this is no longer possible when
      those transport headers are encrypted.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document discusses the possible impact when network traffic uses
      a protocol with an encrypted transport header. It suggests issues to
      consider when designing new transport protocols or features.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are 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/rfc9065">https://www.rfc-editor.org/info/rfc9065</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="ulEmpty compact toc ulBare">
<li class="ulEmpty compact toc ulBare" 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="ulEmpty compact toc ulBare" 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-current-uses-of-transport-h" class="xref">Current Uses of Transport Headers within the Network</a></p>
<ul class="ulBare compact toc ulEmpty">
<li class="ulBare compact toc 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-to-separate-flows-in-networ" class="xref">To Separate Flows in Network Devices</a></p>
</li>
              <li class="ulBare compact toc 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-to-identify-transport-proto" class="xref">To Identify Transport Protocols and Flows</a></p>
</li>
              <li class="ulBare compact toc 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-to-understand-transport-pro" class="xref">To Understand Transport Protocol Performance</a></p>
</li>
              <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-to-support-network-operatio" class="xref">To Support Network Operations</a></p>
</li>
              <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.2.2.5">
                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="xref">2.5</a>.  <a href="#name-to-mitigate-the-effects-of-" class="xref">To Mitigate the Effects of Constrained Networks</a></p>
</li>
              <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.2.2.6">
                <p id="section-toc.1-1.2.2.6.1"><a href="#section-2.6" class="xref">2.6</a>.  <a href="#name-to-verify-sla-compliance" class="xref">To Verify SLA Compliance</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc ulBare" 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-research-development-and-de" class="xref">Research, Development, and Deployment</a></p>
<ul class="ulBare compact toc ulEmpty">
<li class="ulBare compact toc 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-independent-measurement" class="xref">Independent Measurement</a></p>
</li>
              <li class="ulBare compact toc 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-measurable-transport-protoc" class="xref">Measurable Transport Protocols</a></p>
</li>
              <li class="ulBare compact toc 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-other-sources-of-informatio" class="xref">Other Sources of Information</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc ulBare" 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-encryption-and-authenticati" class="xref">Encryption and Authentication of Transport Headers</a></p>
</li>
          <li class="ulEmpty compact toc ulBare" 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-intentionally-exposing-tran" class="xref">Intentionally Exposing Transport Information to the Network</a></p>
<ul class="ulBare compact toc ulEmpty">
<li class="ulBare compact toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-exposing-transport-informat" class="xref">Exposing Transport Information in Extension Headers</a></p>
</li>
              <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-common-exposed-transport-in" class="xref">Common Exposed Transport Information</a></p>
</li>
              <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-considerations-for-exposing" class="xref">Considerations for Exposing Transport Information</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc ulBare" 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-addition-of-transport-oam-i" class="xref">Addition of Transport OAM Information to Network-Layer Headers</a></p>
<ul class="ulBare compact toc ulEmpty">
<li class="ulBare compact toc ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-use-of-oam-within-a-mainten" class="xref">Use of OAM within a Maintenance Domain</a></p>
</li>
              <li class="ulBare compact toc ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-use-of-oam-across-multiple-" class="xref">Use of OAM across Multiple Maintenance Domains</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc ulBare" 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-conclusions" class="xref">Conclusions</a></p>
</li>
          <li class="ulEmpty compact toc ulBare" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="ulEmpty compact toc ulBare" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="ulEmpty compact toc ulBare" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
          <li class="ulEmpty compact toc ulBare" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="ulEmpty compact toc ulBare" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The transport layer supports the end-to-end flow of data across a
      network path, providing features such as connection establishment,
      reliability, framing, ordering, congestion control, flow control, etc.,
      as needed to support applications. One of the core functions of an
      Internet transport is to discover and adapt to the characteristics of
      the network path that is currently being used.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">For some years, it has been common for the transport-layer payload to
      be protected by encryption and authentication but for the transport-layer 
      headers to be sent unprotected. Examples of protocols that behave
      in this manner include Transport Layer Security
      (TLS) over TCP <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>, Datagram TLS <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span> <span>[<a href="#I-D.ietf-tls-dtls13" class="xref">DTLS</a>]</span>, the Secure
      Real-time Transport Protocol <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span>, and tcpcrypt <span>[<a href="#RFC8548" class="xref">RFC8548</a>]</span>. The use of unencrypted transport headers has led some
      network operators, researchers, and others to develop tools and
      processes that rely on observations of transport headers both in
      aggregate and at the flow level to infer details of the network's
      behaviour and inform operational practice.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Transport protocols are now being developed that encrypt some or all
      of the transport headers, in addition to the transport payload data. The
      QUIC transport protocol <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span>
      is an example of such a protocol. Such transport header encryption makes
      it difficult to observe transport protocol behaviour from the vantage
      point of the network. This document discusses some implications of
      transport header encryption for network operators and researchers that
      have previously observed transport headers, and it highlights some issues
      to consider for transport protocol designers.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">As discussed in <span>[<a href="#RFC7258" class="xref">RFC7258</a>]</span>, the IETF has
      concluded that Pervasive Monitoring (PM) is a technical attack that
      needs to be mitigated in the design of IETF protocols. This document
      supports that conclusion. It also recognises that <span>[<a href="#RFC7258" class="xref">RFC7258</a>]</span>
      states, "Making networks unmanageable to mitigate PM is not an acceptable outcome, but
      ignoring PM would go against the consensus documented here. An
      appropriate balance will emerge over time as real instances of this
      tension are considered." This document is written to provide input to
      the discussion around what is an appropriate balance by highlighting
      some implications of transport header encryption.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">Current uses of transport header information by network devices on
      the Internet path are explained. These uses can be beneficial or
      malicious. This is written to provide input to the discussion around
      what is an appropriate balance by highlighting some implications of
      transport header encryption.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
<div id="Current">
<section id="section-2">
      <h2 id="name-current-uses-of-transport-h">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-current-uses-of-transport-h" class="section-name selfRef">Current Uses of Transport Headers within the Network</a>
      </h2>
<p id="section-2-1">In response to pervasive surveillance <span>[<a href="#RFC7624" class="xref">RFC7624</a>]</span>
      revelations and the IETF consensus that "Pervasive Monitoring Is an
      Attack" <span>[<a href="#RFC7258" class="xref">RFC7258</a>]</span>, efforts are underway to increase
      encryption of Internet traffic. Applying confidentiality to transport
      header fields can improve privacy and can help to mitigate certain
      attacks or manipulation of packets by devices on the network path, but
      it can also affect network operations and measurement <span>[<a href="#RFC8404" class="xref">RFC8404</a>]</span>.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">When considering what parts of the transport headers should be
      encrypted to provide confidentiality and what parts should be visible
      to network devices (including unencrypted but authenticated headers),
      it is necessary to consider both the impact on network operations and
      management and the implications for ossification and user privacy <span>[<a href="#Measurement" class="xref">Measurement</a>]</span>. Different parties will view the relative
      importance of these concerns differently. For some, the benefits of
      encrypting all the transport headers outweigh the impact of doing so;
      others might analyse the security, privacy, and ossification impacts and
      arrive at a different trade-off.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">This section reviews examples of the observation of transport-layer
      headers within the network by using devices on the network path or by using
      information exported by an on-path device. Unencrypted transport headers
      provide information that can support network operations and management,
      and this section notes some ways in which this has been done.
      Unencrypted transport header information also contributes metadata that
      can be exploited for purposes unrelated to network transport
      measurement, diagnostics, or troubleshooting (e.g., to block or to
      throttle traffic from a specific content provider), and this section
      also notes some threats relating to unencrypted transport headers.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">Exposed transport information also provides a source of information
      that contributes to linked data sets, which could be exploited to deduce
      private information, e.g., user patterns, user location, tracking
      behaviour, etc. This might reveal information the parties did not intend
      to be revealed. <span>[<a href="#RFC6973" class="xref">RFC6973</a>]</span> aims to make designers,
      implementers, and users of Internet protocols aware of privacy-related
      design choices in IETF protocols.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">This section does not consider intentional modification of transport
      headers by middleboxes, such as devices performing Network Address
      Translation (NAT) or firewalls.<a href="#section-2-5" class="pilcrow">¶</a></p>
<section id="section-2.1">
        <h3 id="name-to-separate-flows-in-networ">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-to-separate-flows-in-networ" class="section-name selfRef">To Separate Flows in Network Devices</a>
        </h3>
<p id="section-2.1-1">Some network-layer mechanisms separate network traffic by flow
        without resorting to identifying the type of traffic: hash-based
        load sharing across paths (e.g., Equal-Cost Multipath
        (ECMP)); sharing across a group of links (e.g., using a Link Aggregation
        Group (LAG)); ensuring equal access to link capacity (e.g., Fair
        Queuing (FQ)); or distributing traffic to servers (e.g., load
        balancing). To prevent packet reordering, forwarding engines can
        consistently forward the same transport flows along the same
        forwarding path, often achieved by calculating a hash using an n-tuple
        gleaned from a combination of link header information through to
        transport header information. This n-tuple can use the Media Access Control 
 (MAC) address and IP
        addresses and can include observable transport header information.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">When transport header information cannot be observed, there can be
        less information to separate flows at equipment along the path. 
 Flow
        separation might not be possible when a transport forms traffic
        into an encrypted aggregate. For IPv6, the Flow Label <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span> can be used even when all transport
        information is encrypted, enabling Flow Label-based ECMP <span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span> and load sharing <span>[<a href="#RFC7098" class="xref">RFC7098</a>]</span>.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
</section>
<div id="Current-demux">
<section id="section-2.2">
        <h3 id="name-to-identify-transport-proto">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-to-identify-transport-proto" class="section-name selfRef">To Identify Transport Protocols and Flows</a>
        </h3>
<p id="section-2.2-1">Information in exposed transport-layer headers can be used by the
        network to identify transport protocols and flows <span>[<a href="#RFC8558" class="xref">RFC8558</a>]</span>. The ability to identify transport protocols,
        flows, and sessions is a common function performed, for example, by
        measurement activities, Quality of Service (QoS) classifiers, and
        firewalls. These functions can be beneficial and performed with the
        consent of, and in support of, the end user. Alternatively, the same
        mechanisms could be used to support practises that might be
        adversarial to the end user, including blocking, deprioritising, and
        monitoring traffic without consent.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">Observable transport header information, together with information
        in the network header, has been used to identify flows and their
        connection state, together with the set of protocol options being
        used. Transport protocols, such as TCP <span>[<a href="#RFC7414" class="xref">RFC7414</a>]</span>
        and the Stream Control Transmission Protocol (SCTP) <span>[<a href="#RFC4960" class="xref">RFC4960</a>]</span>, specify a standard base header that includes
        sequence number information and other data. They also have the
        possibility to negotiate additional headers at connection setup,
        identified by an option number in the transport header.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">In some uses, an assigned transport port (e.g., 0..49151) can
        identify the upper-layer protocol or service <span>[<a href="#RFC7605" class="xref">RFC7605</a>]</span>. However, port information alone is not
        sufficient to guarantee identification. Applications can use arbitrary
        ports and do not need to use assigned port numbers. The use of an
        assigned port number is also not limited to the protocol for which the
        port is intended. Multiple sessions can also be multiplexed on a
        single port, and ports can be reused by subsequent sessions.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
<p id="section-2.2-4">Some flows can be identified by observing signalling data 
        (e.g., see <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span> and <span>[<a href="#RFC8837" class="xref">RFC8837</a>]</span>) or
        through the use of magic numbers placed in the first byte(s) of a
        datagram payload <span>[<a href="#RFC7983" class="xref">RFC7983</a>]</span>.<a href="#section-2.2-4" class="pilcrow">¶</a></p>
<p id="section-2.2-5">When transport header information cannot be observed, this removes
        information that could have been used to classify flows by passive
        observers along the path. More ambitious ways could be used to
        collect, estimate, or infer flow information, including heuristics
        based on the analysis of traffic patterns, such as classification of
        flows relying on timing, volumes of information, and correlation
        between multiple flows. For example, an operator that cannot access
        the Session Description Protocol (SDP) session descriptions <span>[<a href="#RFC8866" class="xref">RFC8866</a>]</span> to classify a flow as audio traffic might
        instead use (possibly less-reliable) heuristics to infer that short
        UDP packets with regular spacing carry audio traffic. Operational
        practises aimed at inferring transport parameters are out of scope for
        this document, and are only mentioned here to recognise that
        encryption does not prevent operators from attempting to apply
        practises that were used with unencrypted transport headers.<a href="#section-2.2-5" class="pilcrow">¶</a></p>
<p id="section-2.2-6">The IAB <span>[<a href="#RFC8546" class="xref">RFC8546</a>]</span> has provided a summary of
        expected implications of increased encryption on network functions
        that use the observable headers and describe the expected benefits of
        designs that explicitly declare protocol-invariant header information
        that can be used for this purpose.<a href="#section-2.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="stats">
<section id="section-2.3">
        <h3 id="name-to-understand-transport-pro">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-to-understand-transport-pro" class="section-name selfRef">To Understand Transport Protocol Performance</a>
        </h3>
<p id="section-2.3-1">This subsection describes use by the network of exposed transport-layer headers to
 understand transport protocol performance and
        behaviour.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<section id="section-2.3.1">
          <h4 id="name-using-information-derived-f">
<a href="#section-2.3.1" class="section-number selfRef">2.3.1. </a><a href="#name-using-information-derived-f" class="section-name selfRef">Using Information Derived from Transport-Layer Headers</a>
          </h4>
<p id="section-2.3.1-1">Observable transport headers enable explicit measurement and
          analysis of protocol performance and detection of network anomalies
          at any point along the Internet path. Some operators use passive
          monitoring to manage their portion of the Internet by characterising
          the performance of link/network segments. Inferences from transport
          headers are used to derive performance metrics:<a href="#section-2.3.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.3.1-2">
            <dt id="section-2.3.1-2.1">Traffic Rate and Volume:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.1-2.2">
              <p id="section-2.3.1-2.2.1">Per-application traffic
              rate and volume measures can be used to characterise the traffic
              that uses a network segment or the pattern of network usage.
              Observing the protocol sequence number and packet size offers
              one way to measure this (e.g., measurements observing counters
              in periodic reports, such as RTCP <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span> <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span>, or measurements observing
              protocol sequence numbers in statistical samples of packet
              flows or specific control packets, such as those observed at
              the start and end of a flow).<a href="#section-2.3.1-2.2.1" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.2.2">Measurements can be per endpoint or for an
              endpoint aggregate. These could be used to assess usage or for
              subscriber billing.<a href="#section-2.3.1-2.2.2" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.2.3">Such measurements can be used to trigger traffic
              shaping and to associate QoS support within the network and
              lower layers. This can be done with consent and in support of an
              end user to improve quality of service or could be used by the
              network to deprioritise certain flows without user consent.<a href="#section-2.3.1-2.2.3" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.2.4">The traffic rate and volume can be determined,
              providing that the packets belonging to individual flows can be
              identified, but there might be no additional information about a
              flow when the transport headers cannot be observed.<a href="#section-2.3.1-2.2.4" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-2.3.1-2.3">Loss Rate and Loss Pattern:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.1-2.4">
              <p id="section-2.3.1-2.4.1">Flow loss rate can be
              derived (e.g., from transport sequence numbers or inferred from
              observing transport protocol interactions) and has been used as
              a metric for performance assessment and to characterise
              transport behaviour. Network operators have used the variation
              in patterns to detect changes in the offered service.
              Understanding the location and root cause of loss can help an
              operator determine whether this requires corrective action.<a href="#section-2.3.1-2.4.1" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.4.2">There are various causes of loss, including: corruption of
              link frames (e.g., due to interference on a radio link);
              buffering loss (e.g., overflow due to congestion, Active Queue
              Management (AQM) <span>[<a href="#RFC7567" class="xref">RFC7567</a>]</span>, or inadequate
              provision following traffic preemption), and policing (e.g., traffic
              management <span>[<a href="#RFC2475" class="xref">RFC2475</a>]</span>). Understanding flow
              loss rates requires maintaining the per-flow state (flow
              identification often requires transport-layer information) and
              either observing the increase in sequence numbers in the network
              or transport headers or comparing a per-flow packet counter
              with the number of packets that the flow actually sent. Per-hop
              loss can also sometimes be monitored at the interface level by
              devices on the network path or by using in-situ methods operating
              over a network segment (see <a href="#other-sources" class="xref">Section 3.3</a>).<a href="#section-2.3.1-2.4.2" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.4.3">The pattern of loss can provide insight into the cause of
              loss. Losses can often occur as bursts, randomly timed events,
              etc. It can also be valuable to understand the conditions under
              which loss occurs. This usually requires relating loss to the
              traffic flowing at a network node or segment at the time of
              loss. Transport header information can help identify cases where
              loss could have been wrongly identified or where the transport
              did not require retransmission of a lost packet.<a href="#section-2.3.1-2.4.3" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-2.3.1-2.5">Throughput and Goodput:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.1-2.6">Throughput is the amount
              of payload data sent by a flow per time interval. Goodput (the
              subset of throughput consisting of useful traffic; see <span><a href="https://www.rfc-editor.org/rfc/rfc7928#section-2.5" class="relref">Section 2.5</a> of [<a href="#RFC7928" class="xref">RFC7928</a>]</span> and <span>[<a href="#RFC5166" class="xref">RFC5166</a>]</span>) is
       a measure of useful data exchanged.
              The throughput of a flow can be determined in the absence of
              transport header information, providing that the individual flow
              can be identified, and the overhead known. Goodput requires the
              ability to differentiate loss and retransmission of packets, for
              example, by observing packet sequence numbers in the TCP or RTP
              headers <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>.<a href="#section-2.3.1-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-2.3.1-2.7">Latency:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.1-2.8">
              <p id="section-2.3.1-2.8.1">Latency is a key performance metric that
              impacts application and user-perceived response times. It often
              indirectly impacts throughput and flow completion time. This
              determines the reaction time of the transport protocol itself,
              impacting flow setup, congestion control, loss recovery, and
              other transport mechanisms. The observed latency can have many
              components <span>[<a href="#Latency" class="xref">Latency</a>]</span>. Of these,
              unnecessary/unwanted queueing in buffers of the network devices
              on the path has often been observed as a significant factor
              <span>[<a href="#bufferbloat" class="xref">bufferbloat</a>]</span>. Once the cause of unwanted
              latency has been identified, this can often be eliminated.<a href="#section-2.3.1-2.8.1" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.8.2">To measure latency across a part of a path, an observation
              point <span>[<a href="#RFC7799" class="xref">RFC7799</a>]</span> can measure the experienced
              round-trip time (RTT) by using packet sequence numbers and
              acknowledgements or by observing header timestamp information.
              Such information allows an observation point on the network path
              to determine not only the path RTT but also allows measurement
              of the upstream and downstream contribution to the RTT. This
              could be used to locate a source of latency, e.g., by observing
              cases where the median RTT is much greater than the minimum RTT
              for a part of a path.<a href="#section-2.3.1-2.8.2" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.8.3">The service offered by network operators can benefit from
              latency information to understand the impact of configuration
              changes and to tune deployed services. Latency metrics are key
              to evaluating and deploying AQM <span>[<a href="#RFC7567" class="xref">RFC7567</a>]</span>,
              Diffserv <span>[<a href="#RFC2474" class="xref">RFC2474</a>]</span>, and 
       Explicit Congestion
              Notification (ECN) <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span> <span>[<a href="#RFC8087" class="xref">RFC8087</a>]</span>. Measurements could identify
              excessively large buffers, indicating where to deploy or
              configure AQM. An AQM method is often deployed in combination
              with other techniques, such as scheduling <span>[<a href="#RFC7567" class="xref">RFC7567</a>]</span> <span>[<a href="#RFC8290" class="xref">RFC8290</a>]</span>, and
              although parameter-less methods are desired <span>[<a href="#RFC7567" class="xref">RFC7567</a>]</span>, current methods often require tuning
              <span>[<a href="#RFC8290" class="xref">RFC8290</a>]</span> <span>[<a href="#RFC8289" class="xref">RFC8289</a>]</span>
                <span>[<a href="#RFC8033" class="xref">RFC8033</a>]</span> because they cannot scale across
              all possible deployment scenarios.<a href="#section-2.3.1-2.8.3" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.8.4">Latency and round-trip time information can potentially
              expose some information useful for approximate geolocation, as
              discussed in <span>[<a href="#PAM-RTT" class="xref">PAM-RTT</a>]</span>.<a href="#section-2.3.1-2.8.4" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-2.3.1-2.9">Variation in Delay:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.1-2.10">Some network applications are
              sensitive to (small) changes in packet timing (jitter). Short-
              and long-term delay variation can impact the latency of a
              flow and hence the perceived quality of applications using a
              network path. For example, jitter metrics are often cited when
              characterising paths supporting real-time traffic. The expected
              performance of such applications can be inferred from a measure
              of the variation in delay observed along a portion of the path
              <span>[<a href="#RFC3393" class="xref">RFC3393</a>]</span> <span>[<a href="#RFC5481" class="xref">RFC5481</a>]</span>.
              The requirements resemble those for the measurement of
              latency.<a href="#section-2.3.1-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-2.3.1-2.11">Flow Reordering:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.1-2.12">
              <p id="section-2.3.1-2.12.1">Significant packet reordering
              within a flow can impact time-critical applications and can be
              interpreted as loss by reliable transports. Many transport
              protocol techniques are impacted by reordering (e.g., triggering
              TCP retransmission or rebuffering of real-time applications).
              Packet reordering can occur for many reasons, e.g., from equipment
              design to misconfiguration of forwarding rules. Flow
              identification is often required to avoid significant packet
              misordering (e.g., when using ECMP, or LAG). Network tools can
              detect and measure unwanted/excessive reordering and the impact
              on transport performance.<a href="#section-2.3.1-2.12.1" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.12.2">There have been initiatives in the IETF transport area to
              reduce the impact of reordering within a transport flow,
              possibly leading to a reduction in the requirements for
              preserving ordering. These have potential to simplify network
              equipment design as well as the potential to improve robustness
              of the transport service. Measurements of reordering can help
              understand the present level of reordering and inform decisions
              about how to progress new mechanisms.<a href="#section-2.3.1-2.12.2" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2.12.3">Techniques for measuring reordering typically observe packet
              sequence numbers. Metrics have been defined that evaluate
              whether a network path has maintained packet order on a
              packet-by-packet basis <span>[<a href="#RFC4737" class="xref">RFC4737</a>]</span> <span>[<a href="#RFC5236" class="xref">RFC5236</a>]</span>. Some protocols provide in-built
              monitoring and reporting functions. Transport fields in the RTP
              header <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span> <span>[<a href="#RFC4585" class="xref">RFC4585</a>]</span> can be observed to derive traffic
              volume measurements and provide information on the progress and
              quality of a session using RTP. Metadata assists in
              understanding the context under which the data was collected,
              including the time, observation point <span>[<a href="#RFC7799" class="xref">RFC7799</a>]</span>, and
       way in which metrics were
              accumulated. The RTCP protocol directly reports some of this
              information in a form that can be directly visible by devices on
              the network path.<a href="#section-2.3.1-2.12.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-2.3.1-3">In some cases, measurements could involve active injection of
          test traffic to perform a measurement (see <span><a href="https://www.rfc-editor.org/rfc/rfc7799#section-3.4" class="relref">Section 3.4</a> of [<a href="#RFC7799" class="xref">RFC7799</a>]</span>). However, most operators do not have
          access to user equipment; therefore, the point of test is normally
          different from the transport endpoint. Injection of test traffic can
          incur an additional cost in running such tests (e.g., the
          implications of capacity tests in a mobile network segment are
          obvious). Some active measurements <span>[<a href="#RFC7799" class="xref">RFC7799</a>]</span>
          (e.g., response under load or particular workloads) perturb other
          traffic and could require dedicated access to the network
          segment.<a href="#section-2.3.1-3" class="pilcrow">¶</a></p>
<p id="section-2.3.1-4">Passive measurements (see <span><a href="https://www.rfc-editor.org/rfc/rfc7799#section-3.6" class="relref">Section 3.6</a> of [<a href="#RFC7799" class="xref">RFC7799</a>]</span>)
   can have advantages in terms of
          eliminating unproductive test traffic, reducing the influence of
          test traffic on the overall traffic mix, and having the ability to choose
          the point of observation (see <a href="#point" class="xref">Section 2.4.1</a>).
          Measurements can rely on observing packet headers, which is not
          possible if those headers are encrypted, but could utilise
          information about traffic volumes or patterns of interaction to
          deduce metrics.<a href="#section-2.3.1-4" class="pilcrow">¶</a></p>
<p id="section-2.3.1-5">Passive packet sampling techniques are also often used to scale
          the processing involved in observing packets on high-rate links.
          This exports only the packet header information of (randomly)
          selected packets. Interpretation of the exported information relies
          on understanding of the header information. The utility of these
          measurements depends on the type of network segment/link and number
          of mechanisms used by the network devices. Simple routers are
          relatively easy to manage, but a device with more complexity demands
          understanding of the choice of many system parameters.<a href="#section-2.3.1-5" class="pilcrow">¶</a></p>
</section>
<div id="tunlhf">
<section id="section-2.3.2">
          <h4 id="name-using-information-derived-fr">
<a href="#section-2.3.2" class="section-number selfRef">2.3.2. </a><a href="#name-using-information-derived-fr" class="section-name selfRef">Using Information Derived from Network-Layer Header Fields</a>
          </h4>
<p id="section-2.3.2-1">Information from the transport header can be used by a
          multi-field (MF) classifier as a part of policy framework. Policies
          are commonly used for management of the QoS or Quality of Experience
          (QoE) in resource-constrained networks or by firewalls to implement
          access rules (see also <span><a href="https://www.rfc-editor.org/rfc/rfc8404#section-2.2.2" class="relref">Section 2.2.2</a> of [<a href="#RFC8404" class="xref">RFC8404</a>]</span>).
   Policies can support user
          applications/services or protect against unwanted or lower-priority
          traffic (<a href="#Implic-Unknown" class="xref">Section 2.4.4</a>).<a href="#section-2.3.2-1" class="pilcrow">¶</a></p>
<p id="section-2.3.2-2">Transport-layer information can also be explicitly carried in
          network-layer header fields that are not encrypted, serving as a
          replacement/addition to the exposed transport header information
          <span>[<a href="#RFC8558" class="xref">RFC8558</a>]</span>. This information can enable a
          different forwarding treatment by the devices forming the network
          path, even when a transport employs encryption to protect other
          header information.<a href="#section-2.3.2-2" class="pilcrow">¶</a></p>
<p id="section-2.3.2-3">On the one hand, the user of a transport that multiplexes
          multiple subflows might want to obscure the presence and
          characteristics of these subflows. On the other hand, an encrypted
          transport could set the network-layer information to indicate the
          presence of subflows and to reflect the service requirements of
          individual subflows. There are several ways this could be done:<a href="#section-2.3.2-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.3.2-4">
            <dt id="section-2.3.2-4.1">IP Address:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.2-4.2">Applications normally expose the
              endpoint addresses used in the forwarding decisions in network
              devices. Address and other protocol information can be used by an
              MF classifier to determine how traffic is treated <span>[<a href="#RFC2475" class="xref">RFC2475</a>]</span> and hence affects the quality of
              experience for a flow. Common issues concerning IP address
              sharing are described in <span>[<a href="#RFC6269" class="xref">RFC6269</a>]</span>.<a href="#section-2.3.2-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-2.3.2-4.3">Using the IPv6 Network-Layer Flow Label:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.2-4.4">
              <p id="section-2.3.2-4.4.1">A number
              of Standards Track and Best Current Practice RFCs (e.g., <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>, <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span>, and <span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span>) encourage endpoints to set the IPv6
              Flow Label field of the network-layer header. 
       As per <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span>, IPv6 source nodes "<span class="bcp14">SHOULD</span> assign each
       unrelated transport connection and application data stream to a
       new flow."
       A multiplexing transport could choose
              to use multiple flow labels to allow the network to
              independently forward subflows. <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span> provides further
              guidance on choosing a flow label value, stating these
              "should be chosen such that their bits exhibit a high
              degree of variability" and chosen so that "third
              parties should be unlikely to be able to guess the next value
              that a source of flow labels will choose."<a href="#section-2.3.2-4.4.1" class="pilcrow">¶</a></p>
<p id="section-2.3.2-4.4.2">Once set, a flow label can provide information
              that can help inform network-layer queueing and forwarding,
              including use with IPsec <span>[<a href="#RFC6294" class="xref">RFC6294</a>]</span>,
              Equal-Cost Multipath routing, and Link Aggregation <span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span>.<a href="#section-2.3.2-4.4.2" class="pilcrow">¶</a></p>
<p id="section-2.3.2-4.4.3">The choice of how to assign a flow label needs to
              avoid introducing linkages between flows that a network device
              could not otherwise observe. Inappropriate use by the transport
              can have privacy implications (e.g., assigning the same label to
              two independent flows that ought not to be classified similarly).<a href="#section-2.3.2-4.4.3" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-2.3.2-4.5">Using the Network-Layer Differentiated Services Code Point:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.2-4.6">Applications
              can expose their delivery expectations to network devices by
              setting the Differentiated Services Code Point (DSCP) field of
              IPv4 and IPv6 packets <span>[<a href="#RFC2474" class="xref">RFC2474</a>]</span>. For
              example, WebRTC applications identify different forwarding
              treatments for individual subflows (audio vs. video) based on
              the value of the DSCP field <span>[<a href="#RFC8837" class="xref">RFC8837</a>]</span>). This provides
              explicit information to inform network-layer queueing and
              forwarding, rather than an operator inferring traffic
              requirements from transport and application headers via a
              multi-field classifier. Inappropriate use by the transport can
              have privacy implications (e.g., assigning a different DSCP to a
              subflow could assist in a network device discovering the traffic
              pattern used by an application). The field is mutable, i.e.,
              some network devices can be expected to change this field. Since
              the DSCP value can impact the quality of experience for a flow,
              observations of service performance have to consider this field
              when a network path supports differentiated service
              treatment.<a href="#section-2.3.2-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-2.3.2-4.7">Using Explicit Congestion Notification:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.2-4.8">
              <p id="section-2.3.2-4.8.1">Explicit Congestion Notification (ECN) <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span> is a transport mechanism that uses the
              ECN field in the network-layer header. Use of ECN explicitly
              informs the network layer that a transport is ECN capable and
              requests ECN treatment of the flow. An ECN-capable transport can
              offer benefits when used over a path with equipment that
              implements an AQM method with Congestion Experienced (CE) marking of IP packets <span>[<a href="#RFC8087" class="xref">RFC8087</a>]</span>, since it can react to congestion
              without also having to recover from lost packets.<a href="#section-2.3.2-4.8.1" class="pilcrow">¶</a></p>
<p id="section-2.3.2-4.8.2">ECN exposes the presence of congestion. The reception of
              CE-marked packets can be used to estimate the level of incipient
              congestion on the upstream portion of the path from the point of
              observation (<span><a href="https://www.rfc-editor.org/rfc/rfc8087#section-2.5" class="relref">Section 2.5</a> of [<a href="#RFC8087" class="xref">RFC8087</a>]</span>).
              Interpreting the marking behaviour (i.e., assessing congestion
              and diagnosing faults) requires context from the transport
              layer, such as path RTT.<a href="#section-2.3.2-4.8.2" class="pilcrow">¶</a></p>
<p id="section-2.3.2-4.8.3">AQM and ECN offer a range of algorithms and configuration
              options. Tools therefore have to be available to network
              operators and researchers to understand the implication of
              configuration choices and transport behaviour as the use of ECN
              increases and new methods emerge <span>[<a href="#RFC7567" class="xref">RFC7567</a>]</span>.<a href="#section-2.3.2-4.8.3" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-2.3.2-4.9">Network-Layer Options:</dt>
            <dd style="margin-left: 1.5em" id="section-2.3.2-4.10">
              <p id="section-2.3.2-4.10.1">Network protocols can carry
              optional headers (see <a href="#EH" class="xref">Section 5.1</a>). These can
              explicitly expose transport header information to on-path
              devices operating at the network layer (as discussed further in
              <a href="#OAM" class="xref">Section 6</a>).<a href="#section-2.3.2-4.10.1" class="pilcrow">¶</a></p>
<p id="section-2.3.2-4.10.2">IPv4 <span>[<a href="#RFC0791" class="xref">RFC0791</a>]</span> has provisions
              for optional header fields. IP routers can examine these headers
              and are required to ignore IPv4 options that they do not
              recognise. Many current paths include network devices that
              forward packets that carry options on a slower processing path.
              Some network devices (e.g., firewalls) can be (and are)
              configured to drop these packets <span>[<a href="#RFC7126" class="xref">RFC7126</a>]</span>.
              BCP 186 <span>[<a href="#RFC7126" class="xref">RFC7126</a>]</span> provides
              guidance on how operators should treat IPv4 packets
              that specify options.<a href="#section-2.3.2-4.10.2" class="pilcrow">¶</a></p>
<p id="section-2.3.2-4.10.3">IPv6 can encode optional network-layer
              information in separate headers that may be placed between the
              IPv6 header and the upper-layer header <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>
       (e.g., the IPv6 Alternate Marking
              Method <span>[<a href="#I-D.ietf-6man-ipv6-alt-mark" class="xref">IPV6-ALT-MARK</a>]</span>, which
              can be used to measure packet loss and delay metrics). The
              Hop-by-Hop Options header, when present, immediately follows the
              IPv6 header. IPv6 permits this header to be examined by any node
              along the path if explicitly configured <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>.<a href="#section-2.3.2-4.10.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-2.3.2-5">Careful use of the network-layer features (e.g., extension
          headers can; see <a href="#EH2" class="xref">Section 5</a>) help provide similar
          information in the case where the network is unable to inspect
          transport protocol headers.<a href="#section-2.3.2-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Measure">
<section id="section-2.4">
        <h3 id="name-to-support-network-operatio">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-to-support-network-operatio" class="section-name selfRef">To Support Network Operations</a>
        </h3>
<p id="section-2.4-1">Some network operators make use of on-path observations of
        transport headers to analyse the service offered to the users of a
        network segment and inform operational practice and can help
        detect and locate network problems. <span>[<a href="#RFC8517" class="xref">RFC8517</a>]</span>
        gives an operator's perspective about such use.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4-2">When observable transport header information is not available,
        those seeking an understanding of transport behaviour and dynamics
        might learn to work without that information. Alternatively, they
        might use more limited measurements combined with pattern inference
        and other heuristics to infer network behaviour (see <span><a href="https://www.rfc-editor.org/rfc/rfc8404#section-2.1.1" class="relref">Section 2.1.1</a> of [<a href="#RFC8404" class="xref">RFC8404</a>]</span>). Operational practises aimed at
        inferring transport parameters are out of scope for this document and
        are only mentioned here to recognise that encryption does not
        necessarily stop operators from attempting to apply practises that
        have been used with unencrypted transport headers.<a href="#section-2.4-2" class="pilcrow">¶</a></p>
<p id="section-2.4-3">This section discusses topics concerning observation of transport
        flows, with a focus on transport measurement.<a href="#section-2.4-3" class="pilcrow">¶</a></p>
<div id="point">
<section id="section-2.4.1">
          <h4 id="name-problem-location">
<a href="#section-2.4.1" class="section-number selfRef">2.4.1. </a><a href="#name-problem-location" class="section-name selfRef">Problem Location</a>
          </h4>
<p id="section-2.4.1-1">Observations of transport header information can be used to
          locate the source of problems or to assess the performance of a
          network segment. Often issues can only be understood in the context
          of the other flows that share a particular path, particular device
          configuration, interface port, etc. A simple example is monitoring
          of a network device that uses a scheduler or active queue management
          technique <span>[<a href="#RFC7567" class="xref">RFC7567</a>]</span>, where it could be
          desirable to understand whether the algorithms are correctly
          controlling latency or if overload protection is working. This
          implies knowledge of how traffic is assigned to any subqueues used
          for flow scheduling but can require information about how the
          traffic dynamics impact active queue management, starvation
          prevention mechanisms, and circuit breakers.<a href="#section-2.4.1-1" class="pilcrow">¶</a></p>
<p id="section-2.4.1-2">Sometimes correlating observations of headers at multiple points
          along the path (e.g., at the ingress and egress of a network
          segment) allows an observer to determine the contribution of a
          portion of the path to an observed metric (e.g., to locate a source
          of delay, jitter, loss, reordering, or congestion marking).<a href="#section-2.4.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-2.4.2">
          <h4 id="name-network-planning-and-provis">
<a href="#section-2.4.2" class="section-number selfRef">2.4.2. </a><a href="#name-network-planning-and-provis" class="section-name selfRef">Network Planning and Provisioning</a>
          </h4>
<p id="section-2.4.2-1">Traffic rate and volume measurements are used to help plan
          deployment of new equipment and configuration in networks. Data is
          also valuable to equipment vendors who want to understand traffic
          trends and patterns of usage as inputs to decisions about planning
          products and provisioning for new deployments.<a href="#section-2.4.2-1" class="pilcrow">¶</a></p>
<p id="section-2.4.2-2">Trends in aggregate traffic can be observed and can be related to
          the endpoint addresses being used, but when transport header
          information is not observable, it might be impossible to correlate
          patterns in measurements with changes in transport protocols. This
          increases the dependency on other indirect sources of information to
          inform planning and provisioning.<a href="#section-2.4.2-2" class="pilcrow">¶</a></p>
</section>
<div id="Compliance">
<section id="section-2.4.3">
          <h4 id="name-compliance-with-congestion-">
<a href="#section-2.4.3" class="section-number selfRef">2.4.3. </a><a href="#name-compliance-with-congestion-" class="section-name selfRef">Compliance with Congestion Control</a>
          </h4>
<p id="section-2.4.3-1">The traffic that can be observed by on-path network devices (the
          "wire image") is a function of transport protocol design/options,
          network use, applications, and user characteristics. In general,
          when only a small proportion of the traffic has a specific
          (different) characteristic, such traffic seldom leads to operational
          concern, although the ability to measure and monitor it is lower.
          The desire to understand the traffic and protocol interactions
          typically grows as the proportion of traffic increases. The
          challenges increase when multiple instances of an evolving protocol
          contribute to the traffic that share network capacity.<a href="#section-2.4.3-1" class="pilcrow">¶</a></p>
<p id="section-2.4.3-2">Operators can manage traffic load (e.g., when the network is
          severely overloaded) by deploying rate limiters, traffic shaping, or
          network transport circuit breakers <span>[<a href="#RFC8084" class="xref">RFC8084</a>]</span>.
          The information provided by observing transport headers is a source
          of data that can help to inform such mechanisms.<a href="#section-2.4.3-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.4.3-3">
            <dt id="section-2.4.3-3.1">Congestion Control Compliance of Traffic:</dt>
            <dd style="margin-left: 1.5em" id="section-2.4.3-3.2">
              <p id="section-2.4.3-3.2.1">Congestion control is a key transport function <span>[<a href="#RFC2914" class="xref">RFC2914</a>]</span>. Many network operators implicitly
              accept that TCP traffic complies with a behaviour that is
              acceptable for the shared Internet. TCP algorithms have been
              continuously improved over decades and have reached a level of
              efficiency and correctness that is difficult to match in custom
              application-layer mechanisms <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>.<a href="#section-2.4.3-3.2.1" class="pilcrow">¶</a></p>
<p id="section-2.4.3-3.2.2">A standards-compliant TCP stack provides congestion control
              that is judged safe for use across the Internet. Applications
              developed on top of well-designed transports can be expected to
              appropriately control their network usage, reacting when the
              network experiences congestion, by backing off and reducing the load
              placed on the network. This is the normal expected behaviour for
              IETF-specified transports (e.g., TCP and SCTP).<a href="#section-2.4.3-3.2.2" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-2.4.3-3.3">Congestion Control Compliance for UDP Traffic:</dt>
            <dd style="margin-left: 1.5em" id="section-2.4.3-3.4">
              <p id="section-2.4.3-3.4.1">UDP
              provides a minimal message-passing datagram transport that has
              no inherent congestion control mechanisms. Because congestion
              control is critical to the stable operation of the Internet,
              applications and other protocols that choose to use UDP as a
              transport have to employ mechanisms to prevent collapse, avoid
              unacceptable contributions to jitter/latency, and establish
              an acceptable share of capacity with concurrent traffic <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>.<a href="#section-2.4.3-3.4.1" class="pilcrow">¶</a></p>
<p id="section-2.4.3-3.4.2">UDP flows that expose a well-known header can be observed to
              gain understanding of the dynamics of a flow and its congestion
              control behaviour. For example, tools exist to monitor various
              aspects of RTP header information and RTCP reports for real-time
              flows (see <a href="#stats" class="xref">Section 2.3</a>). The Secure RTP and
              RTCP extensions <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span> were explicitly
              designed to expose some header information to enable such
              observation while protecting the payload data.<a href="#section-2.4.3-3.4.2" class="pilcrow">¶</a></p>
<p id="section-2.4.3-3.4.3">A network operator can observe the headers of transport
              protocols layered above UDP to understand if the datagram flows
              comply with congestion control expectations. This can help
              inform a decision on whether it might be appropriate to deploy
              methods, such as rate limiters, to enforce acceptable usage. The
              available information determines the level of precision with
              which flows can be classified and the design space for
              conditioning mechanisms (e.g., rate-limiting, circuit breaker
              techniques <span>[<a href="#RFC8084" class="xref">RFC8084</a>]</span>, or blocking
              uncharacterised traffic) <span>[<a href="#RFC5218" class="xref">RFC5218</a>]</span>.<a href="#section-2.4.3-3.4.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-2.4.3-4">When anomalies are detected, tools can interpret the transport
          header information to help understand the impact of specific
          transport protocols (or protocol mechanisms) on the other traffic
          that shares a network. An observer on the network path can gain an
          understanding of the dynamics of a flow and its congestion control
          behaviour. Analysing observed flows can help to build confidence
          that an application flow backs off its share of the network load
          under persistent congestion and hence to understand whether the
          behaviour is appropriate for sharing limited network capacity. For
          example, it is common to visualise plots of TCP sequence numbers
          versus time for a flow to understand how a flow shares available
          capacity, deduce its dynamics in response to congestion, etc.<a href="#section-2.4.3-4" class="pilcrow">¶</a></p>
<p id="section-2.4.3-5">The ability to identify sources and flows that contribute to
          persistent congestion is important to the safe operation of network
          infrastructure and can inform configuration of network devices to
          complement the endpoint congestion avoidance mechanisms <span>[<a href="#RFC7567" class="xref">RFC7567</a>]</span> <span>[<a href="#RFC8084" class="xref">RFC8084</a>]</span> to avoid a
          portion of the network being driven into congestion collapse <span>[<a href="#RFC2914" class="xref">RFC2914</a>]</span>.<a href="#section-2.4.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Implic-Unknown">
<section id="section-2.4.4">
          <h4 id="name-to-characterise-unknown-net">
<a href="#section-2.4.4" class="section-number selfRef">2.4.4. </a><a href="#name-to-characterise-unknown-net" class="section-name selfRef">To Characterise "Unknown" Network Traffic</a>
          </h4>
<p id="section-2.4.4-1">The patterns and types of traffic that share Internet capacity
          change over time as networked applications, usage patterns, and
          protocols continue to evolve.<a href="#section-2.4.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4.4-2">Encryption can increase the volume of "unknown" or
          "uncharacterised" traffic seen by the network. If these traffic
          patterns form a small part of the traffic aggregate passing through
          a network device or segment of the network path, the dynamics of the
          uncharacterised traffic might not have a significant collateral
          impact on the performance of other traffic that shares this network
          segment. Once the proportion of this traffic increases, monitoring
          the traffic can determine if appropriate safety measures have to be
          put in place.<a href="#section-2.4.4-2" class="pilcrow">¶</a></p>
<p id="section-2.4.4-3">Tracking the impact of new mechanisms and protocols requires
          traffic volume to be measured and new transport behaviours to be
          identified. This is especially true of protocols operating over a
          UDP substrate. The level and style of encryption needs to be
          considered in determining how this activity is performed.<a href="#section-2.4.4-3" class="pilcrow">¶</a></p>
<p id="section-2.4.4-4">Traffic that cannot be classified typically receives a default
          treatment. Some networks block or rate-limit traffic that cannot be
          classified.<a href="#section-2.4.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-2.4.5">
          <h4 id="name-to-support-network-security">
<a href="#section-2.4.5" class="section-number selfRef">2.4.5. </a><a href="#name-to-support-network-security" class="section-name selfRef">To Support Network Security Functions</a>
          </h4>
<p id="section-2.4.5-1">On-path observation of the transport headers of packets can be
          used for various security functions. For example, Denial of Service
          (DoS) and Distributed DoS (DDoS) attacks against the infrastructure
          or against an endpoint can be detected and mitigated by
          characterising anomalous traffic (see <a href="#Implic-Unknown" class="xref">Section 2.4.4</a>) on a shorter timescale. Other uses
          include support for security audits (e.g., verifying the compliance
          with cipher suites), client and application fingerprinting for
          inventory, and alerts provided for network intrusion detection and
          other next generation firewall functions.<a href="#section-2.4.5-1" class="pilcrow">¶</a></p>
<p id="section-2.4.5-2">When using an encrypted transport, endpoints can directly provide
          information to support these security functions. Another method, if
          the endpoints do not provide this information, is to use an on-path
          network device that relies on pattern inferences in the traffic and
          heuristics or machine learning instead of processing observed header
          information. An endpoint could also explicitly cooperate with an
          on-path device (e.g., a QUIC endpoint could share information about
          current uses of connection IDs).<a href="#section-2.4.5-2" class="pilcrow">¶</a></p>
</section>
<div id="Current-diag">
<section id="section-2.4.6">
          <h4 id="name-network-diagnostics-and-tro">
<a href="#section-2.4.6" class="section-number selfRef">2.4.6. </a><a href="#name-network-diagnostics-and-tro" class="section-name selfRef">Network Diagnostics and Troubleshooting</a>
          </h4>
<p id="section-2.4.6-1">Operators monitor the health of a network segment to support a
          variety of operational tasks <span>[<a href="#RFC8404" class="xref">RFC8404</a>]</span>,
          including procedures to provide early warning and trigger action, e.g., to
          diagnose network problems, to manage security threats (including
          DoS), to evaluate equipment or protocol performance, or to respond
          to user performance questions. Information about transport flows can
          assist in setting buffer sizes and help identify whether
          link/network tuning is effective. Information can also support
          debugging and diagnosis of the root causes of faults that concern a
          particular user's traffic and can support postmortem investigation
          after an anomaly. Sections <a href="https://www.rfc-editor.org/rfc/rfc8404#section-3.1.2" class="relref">3.1.2</a>
   and <a href="https://www.rfc-editor.org/rfc/rfc8404#section-5" class="relref">5</a> of <span>[<a href="#RFC8404" class="xref">RFC8404</a>]</span> provide further examples.<a href="#section-2.4.6-1" class="pilcrow">¶</a></p>
<p id="section-2.4.6-2">Network segments vary in their complexity. The design trade-offs
          for radio networks are often very different from those of wired
          networks <span>[<a href="#RFC8462" class="xref">RFC8462</a>]</span>. A radio-based network
          (e.g., cellular mobile, enterprise Wireless LAN (WLAN), satellite
          access/backhaul, point-to-point radio) adds a subsystem that
          performs radio resource management, with impact on the available
          capacity and potentially loss/reordering of packets. This impact
          can differ by traffic type and can be correlated with link
          propagation and interference. These can impact the cost and
          performance of a provided service and is expected to increase in
          importance as operators bring together heterogeneous types of
          network equipment and deploy opportunistic methods to access a shared
          radio spectrum.<a href="#section-2.4.6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Implic-Cost">
<section id="section-2.4.7">
          <h4 id="name-tooling-and-network-operati">
<a href="#section-2.4.7" class="section-number selfRef">2.4.7. </a><a href="#name-tooling-and-network-operati" class="section-name selfRef">Tooling and Network Operations</a>
          </h4>
<p id="section-2.4.7-1">A variety of open source and proprietary tools have been deployed
          that use the transport header information observable with widely
          used protocols, such as TCP or RTP/UDP/IP. Tools that dissect network
          traffic flows can alert to potential problems that are hard to
          derive from volume measurements, link statistics, or device
          measurements alone.<a href="#section-2.4.7-1" class="pilcrow">¶</a></p>
<p id="section-2.4.7-2">Any introduction of a new transport protocol, protocol feature,
          or application might require changes to such tools and could
          impact operational practice and policies. Such changes have
          associated costs that are incurred by the network operators that
          need to update their tooling or develop alternative practises that
          work without access to the changed/removed information.<a href="#section-2.4.7-2" class="pilcrow">¶</a></p>
<p id="section-2.4.7-3">The use of encryption has the desirable effect of preventing
          unintended observation of the payload data, and these tools seldom
          seek to observe the payload or other application details. A flow
          that hides its transport header information could imply "don't
          touch" to some operators. This might limit a trouble-shooting
          response to "can't help, no trouble found".<a href="#section-2.4.7-3" class="pilcrow">¶</a></p>
<p id="section-2.4.7-4">An alternative that does not require access to an observable
          transport headers is to access endpoint diagnostic tools or to
          include user involvement in diagnosing and troubleshooting unusual
          use cases or to troubleshoot nontrivial problems. Another approach
          is to use traffic pattern analysis. Such tools can provide useful
          information during network anomalies (e.g., detecting significant
          reordering, high or intermittent loss); however, indirect
          measurements need to be carefully designed to provide information
          for diagnostics and troubleshooting.<a href="#section-2.4.7-4" class="pilcrow">¶</a></p>
<p id="section-2.4.7-5">If new protocols, or protocol extensions, are made to closely
          resemble or match existing mechanisms, then the changes to tooling
          and the associated costs can be small. Equally, more extensive
          changes to the transport tend to require more extensive, and more
          expensive, changes to tooling and operational practice. Protocol
          designers can mitigate these costs by explicitly choosing to expose
          selected information as invariants that are guaranteed not to change
          for a particular protocol (e.g., the header invariants and the
          spin bit in QUIC <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span>).
          Specification of common log formats and development of alternative
          approaches can also help mitigate the costs of transport
          changes.<a href="#section-2.4.7-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-2.5">
        <h3 id="name-to-mitigate-the-effects-of-">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-to-mitigate-the-effects-of-" class="section-name selfRef">To Mitigate the Effects of Constrained Networks</a>
        </h3>
<p id="section-2.5-1">Some link and network segments are constrained by the capacity they
        can offer by the time it takes to access capacity (e.g., due to
        underlying radio resource management methods) or by asymmetries in
        the design (e.g., many link are designed so that the capacity
        available is different in the forward and return directions; some
        radio technologies have different access methods in the forward and
        return directions resulting from differences in the power budget).<a href="#section-2.5-1" class="pilcrow">¶</a></p>
<p id="section-2.5-2">The impact of path constraints can be mitigated using a proxy
        operating at or above the transport layer to use an alternate
        transport protocol.<a href="#section-2.5-2" class="pilcrow">¶</a></p>
<p id="section-2.5-3">In many cases, one or both endpoints are unaware of the
        characteristics of the constraining link or network segment, and
        mitigations are applied below the transport layer. Packet
        classification and QoS methods (described in various sections) can be
        beneficial in differentially prioritising certain traffic when there
        is a capacity constraint or additional delay in scheduling link
        transmissions. Another common mitigation is to apply header
        compression over the specific link or subnetwork (see <a href="#HC" class="xref">Section 2.5.1</a>).<a href="#section-2.5-3" class="pilcrow">¶</a></p>
<div id="HC">
<section id="section-2.5.1">
          <h4 id="name-to-provide-header-compressi">
<a href="#section-2.5.1" class="section-number selfRef">2.5.1. </a><a href="#name-to-provide-header-compressi" class="section-name selfRef">To Provide Header Compression</a>
          </h4>
<p id="section-2.5.1-1">Header compression saves link capacity by compressing network and
          transport protocol headers on a per-hop basis. This has been widely
          used with low bandwidth dial-up access links and still finds
          application on wireless links that are subject to capacity
          constraints. These methods are effective for bit-congestive links
          sending small packets (e.g., reducing the cost for sending control
          packets or small data packets over radio links).<a href="#section-2.5.1-1" class="pilcrow">¶</a></p>
<p id="section-2.5.1-2">Examples of header compression include use with TCP/IP and
          RTP/UDP/IP flows <span>[<a href="#RFC2507" class="xref">RFC2507</a>]</span> <span>[<a href="#RFC6846" class="xref">RFC6846</a>]</span> <span>[<a href="#RFC2508" class="xref">RFC2508</a>]</span> <span>[<a href="#RFC5795" class="xref">RFC5795</a>]</span> <span>[<a href="#RFC8724" class="xref">RFC8724</a>]</span>. Successful
          compression depends on observing the transport headers and
          understanding the way fields change between packets and is hence
          incompatible with header encryption. Devices that compress transport
          headers are dependent on a stable header format, implying
          ossification of that format.<a href="#section-2.5.1-2" class="pilcrow">¶</a></p>
<p id="section-2.5.1-3">Introducing a new transport protocol, or changing the format of
          the transport header information, will limit the effectiveness of
          header compression until the network devices are updated. Encrypting
          the transport protocol headers will tend to cause the header
          compression to fall back to compressing only the network-layer
          headers, with a significant reduction in efficiency. This can limit
          connectivity if the resulting flow exceeds the link capacity or if
          the packets are dropped because they exceed the link Maximum 
   Transmission Unit (MTU).<a href="#section-2.5.1-3" class="pilcrow">¶</a></p>
<p id="section-2.5.1-4">The Secure RTP (SRTP) extensions <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span>
          were explicitly designed to leave the transport protocol headers
          unencrypted, but authenticated, since support for header compression
          was considered important.<a href="#section-2.5.1-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-2.6">
        <h3 id="name-to-verify-sla-compliance">
<a href="#section-2.6" class="section-number selfRef">2.6. </a><a href="#name-to-verify-sla-compliance" class="section-name selfRef">To Verify SLA Compliance</a>
        </h3>
<p id="section-2.6-1">Observable transport headers coupled with published transport
        specifications allow operators and regulators to explore and verify
        compliance with Service Level Agreements (SLAs). It can also be used
        to understand whether a service is providing differential treatment to
        certain flows.<a href="#section-2.6-1" class="pilcrow">¶</a></p>
<p id="section-2.6-2">When transport header information cannot be observed, other methods
        have to be found to confirm that the traffic produced conforms to the
        expectations of the operator or developer.<a href="#section-2.6-2" class="pilcrow">¶</a></p>
<p id="section-2.6-3">Independently verifiable performance metrics can be utilised to
        demonstrate regulatory compliance in some jurisdictions and as a
        basis for informing design decisions. This can bring assurance to
        those operating networks, often avoiding deployment of complex
        techniques that routinely monitor and manage Internet traffic flows
        (e.g., avoiding the capital and operational costs of deploying flow
        rate-limiting and network circuit breaker methods <span>[<a href="#RFC8084" class="xref">RFC8084</a>]</span>).<a href="#section-2.6-3" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="Implic">
<section id="section-3">
      <h2 id="name-research-development-and-de">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-research-development-and-de" class="section-name selfRef">Research, Development, and Deployment</a>
      </h2>
<p id="section-3-1">Research and development of new protocols and mechanisms need to be
      informed by measurement data (as described in the previous section).
      Data can also help promote acceptance of proposed standards
      specifications by the wider community (e.g., as a method to judge the
      safety for Internet deployment).<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Observed data is important to ensure the health of the research and
      development communities and provides data needed to evaluate new
      proposals for standardisation. Open standards motivate a desire to
      include independent observation and evaluation of performance and
      deployment data. Independent data helps compare different methods, judge
      the level of deployment, and ensure the wider applicability of the
      results. This is important when considering when a protocol or mechanism
      should be standardised for use in the general Internet. This, in turn,
      demands control/understanding about where and when measurement samples
      are collected. This requires consideration of the methods used to
      observe information and the appropriate balance between encrypting all
      and no transport header information.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">There can be performance and operational trade-offs in exposing
      selected information to network tools. This section explores key
      implications of tools and procedures that observe transport protocols
      but does not endorse or condemn any specific practises.<a href="#section-3-3" class="pilcrow">¶</a></p>
<div id="Implic-Independent">
<section id="section-3.1">
        <h3 id="name-independent-measurement">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-independent-measurement" class="section-name selfRef">Independent Measurement</a>
        </h3>
<p id="section-3.1-1">Encrypting transport header information has implications on the way
        network data is collected and analysed. Independent observations by
        multiple actors is currently used by the transport community to
        maintain an accurate understanding of the network within transport
        area working groups, IRTF research groups, and the broader research
        community. This is important to be able to provide accountability and
        demonstrate that protocols behave as intended; although, when providing
        or using such information, it is important to consider the privacy of
        the user and their incentive for providing accurate and detailed
        information.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">Protocols that expose the state of the transport protocol in their
        header (e.g., timestamps used to calculate the RTT, packet numbers
        used to assess congestion, and requests for retransmission) provide an
        incentive for a sending endpoint to provide consistent information,
        because a protocol will not work otherwise. An on-path observer can
        have confidence that well-known (and ossified) transport header
        information represents the actual state of the endpoints when this
        information is necessary for the protocol's correct operation.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">Encryption of transport header information could reduce the range
        of actors that can observe useful data. This would limit the
        information sources available to the Internet community to understand
        the operation of new transport protocols, reducing information to
        inform design decisions and standardisation of the new protocols and
        related operational practises. The cooperating dependence of network,
        application, and host to provide communication performance on the
        Internet is uncertain when only endpoints (i.e., at user devices and
        within service platforms) can observe performance and when
        performance cannot be independently verified by all parties.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Implic-design">
<section id="section-3.2">
        <h3 id="name-measurable-transport-protoc">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-measurable-transport-protoc" class="section-name selfRef">Measurable Transport Protocols</a>
        </h3>
<p id="section-3.2-1">Transport protocol evolution and the ability to measure and
        understand the impact of protocol changes have to proceed
        hand-in-hand. A transport protocol that provides observable headers
        can be used to provide open and verifiable measurement data.
        Observation of pathologies has a critical role in the design of
        transport protocol mechanisms and development of new mechanisms and
        protocols and aides in understanding the interactions between
        cooperating protocols and network mechanisms, the implications of
        sharing capacity with other traffic, and the impact of different
        patterns of usage. The ability of other stakeholders to review
        transport header traces helps develop insight into the performance and
        the traffic contribution of specific variants of a protocol.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">Development of new transport protocol mechanisms has to consider
        the scale of deployment and the range of environments in which the
        transport is used. Experience has shown that it is often difficult to
        correctly implement new mechanisms <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span> and
        that mechanisms often evolve as a protocol matures or in response to
        changes in network conditions, in network traffic, or
        to application usage. Analysis is especially valuable when based on
        the behaviour experienced across a range of topologies, vendor
        equipment, and traffic patterns.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">Encryption enables a transport protocol to choose which internal
        state to reveal to devices on the network path, what information to
        encrypt, and what fields to grease <span>[<a href="#RFC8701" class="xref">RFC8701</a>]</span>. A
        new design can provide summary information regarding its performance,
        congestion control state, etc., or make explicit
        measurement information available. For example, <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span>
 specifies a way for a QUIC
        endpoint to optionally set the spin bit to explicitly reveal the RTT
        of an encrypted transport session to the on-path network devices.
        There is a choice of what information to expose. For some operational
        uses, the information has to contain sufficient detail to understand,
        and possibly reconstruct, the network traffic pattern for further
        testing. The interpretation of the information needs to consider
        whether this information reflects the actual transport state of the
        endpoints. This might require the trust of transport protocol
        implementers to correctly reveal the desired information.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">New transport protocol formats are expected to facilitate an
        increased pace of transport evolution and with it the possibility to
        experiment with and deploy a wide range of protocol mechanisms. At the
        time of writing, there has been interest in a wide range of new
        transport methods, e.g., larger initial window, Proportional Rate
        Reduction (PRR), congestion control methods based on measuring
        bottleneck bandwidth and round-trip propagation time, the introduction
        of AQM techniques, and new forms of ECN response (e.g., Data Centre
        TCP, DCTCP, and methods proposed for Low Latency Low Loss Scalable throughput (L4S)). The growth and diversity of
        applications and protocols using the Internet also continues to
        expand. For each new method or application, it is desirable to build a
        body of data reflecting its behaviour under a wide range of deployment
        scenarios, traffic load, and interactions with other
        deployed/candidate methods.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="other-sources">
<section id="section-3.3">
        <h3 id="name-other-sources-of-informatio">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-other-sources-of-informatio" class="section-name selfRef">Other Sources of Information</a>
        </h3>
<p id="section-3.3-1">Some measurements that traditionally rely on observable transport
        information could be completed by utilising endpoint-based logging
        (e.g., based on <span><a href="#Quic-Trace" class="xref">QUIC trace</a> [<a href="#Quic-Trace" class="xref">Quic-Trace</a>]</span> and
        <span><a href="#I-D.ietf-quic-qlog-main-schema" class="xref">qlog</a> [<a href="#I-D.ietf-quic-qlog-main-schema" class="xref">QLOG</a>]</span>). Such information
        has a diversity of uses, including developers wishing to
        debug/understand the transport/application protocols with which they
        work, researchers seeking to spot trends and anomalies, and
        to characterise variants of protocols. A standard format for endpoint
        logging could allow these to be shared (after appropriate
        anonymisation) to understand performance and pathologies.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">When measurement datasets are made available by servers or client
        endpoints, additional metadata, such as the state of the network and
        conditions in which the system was observed, is often necessary to
        interpret this data to answer questions about network performance or
        understand a pathology. Collecting and coordinating such metadata is
        more difficult when the observation point is at a different location
        to the bottleneck or device under evaluation <span>[<a href="#RFC7799" class="xref">RFC7799</a>]</span>.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">Despite being applicable in some scenarios, endpoint logs do not
        provide equivalent information to on-path measurements made by devices
        in the network. In particular, endpoint logs contain only a part of
        the information to understand the operation of network devices and
        identify issues, such as link performance or capacity sharing between
        multiple flows. An analysis can require coordination between actors at
        different layers to successfully characterise flows and correlate the
        performance or behaviour of a specific mechanism with an equipment
        configuration and traffic using operational equipment along a network
        path (e.g., combining transport and network measurements to explore
        congestion control dynamics to understand the implications of traffic
        on designs for active queue management or circuit breakers).<a href="#section-3.3-3" class="pilcrow">¶</a></p>
<p id="section-3.3-4">Another source of information could arise from Operations,
        Administration, and Maintenance (OAM) (see <a href="#OAM" class="xref">Section 6</a>).
        Information data records could be embedded into header information at
        different layers to support functions, such as performance evaluation,
        path tracing, path verification information, classification, and a
        diversity of other uses.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
<p id="section-3.3-5">In-situ OAM (IOAM) data fields <span>[<a href="#I-D.ietf-ippm-ioam-data" class="xref">IOAM-DATA</a>]</span> can be encapsulated into a
        variety of protocols to record operational and telemetry information
        in an existing packet while that packet traverses a part of the path
        between two points in a network (e.g., within a particular IOAM
        management domain). IOAM-Data-Fields are independent from the
        protocols into which IOAM-Data-Fields are encapsulated. For example, IOAM 
        can provide proof that a traffic flow takes a
        predefined path, SLA verification for the live data traffic, and
        statistics relating to traffic distribution.<a href="#section-3.3-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Transport-encrypt">
<section id="section-4">
      <h2 id="name-encryption-and-authenticati">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-encryption-and-authenticati" class="section-name selfRef">Encryption and Authentication of Transport Headers</a>
      </h2>
<p id="section-4-1">There are several motivations for transport header encryption.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">One motive to encrypt transport headers is to prevent network
      ossification from network devices that inspect well-known transport
      headers. Once a network device observes a transport header and becomes
      reliant upon using it, the overall use of that field can become
      ossified, preventing new versions of the protocol and mechanisms from
      being deployed. Examples include:<a href="#section-4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-3.1">During the development of TLS 1.3 <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>,
          the design needed to function in the presence of deployed
          middleboxes that relied on the presence of certain header fields
          exposed in TLS 1.2 <span>[<a href="#RFC5426" class="xref">RFC5426</a>]</span>.<a href="#section-4-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.2">The design of Multipath TCP (MPTCP) <span>[<a href="#RFC8684" class="xref">RFC8684</a>]</span> had to account for middleboxes (known as
          "TCP Normalizers") that monitor the evolution of the window
          advertised in the TCP header and then reset connections when the
          window did not grow as expected.<a href="#section-4-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.3">TCP Fast Open <span>[<a href="#RFC7413" class="xref">RFC7413</a>]</span> can experience
          problems due to middleboxes that modify the transport header of
          packets by removing "unknown" TCP options. Segments with
          unrecognised TCP options can be dropped, segments that contain data
          and set the SYN bit can be dropped, and some middleboxes that
          disrupt connections can send data before completion of the
          three-way handshake.<a href="#section-4-3.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.4">Other examples of TCP ossification have included middleboxes that
          modify transport headers by rewriting TCP sequence and
          acknowledgement numbers but are unaware of the (newer) TCP
          selective acknowledgement (SACK) option and therefore fail to
          correctly rewrite the SACK information to match the changes made to
          the fixed TCP header, preventing correct SACK operation.<a href="#section-4-3.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-4">In all these cases, middleboxes with a hard-coded, but incomplete,
      understanding of a specific transport behaviour (i.e., TCP) interacted
      poorly with transport protocols after the transport behaviour was
      changed. In some cases, the middleboxes modified or replaced information
      in the transport protocol header.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">Transport header encryption prevents an on-path device from observing
      the transport headers and therefore stops ossified mechanisms being
      used that directly rely on or infer semantics of the transport header
      information. This encryption is normally combined with authentication of
      the protected information. <span>[<a href="#RFC8546" class="xref">RFC8546</a>]</span> summarises this
      approach, stating
      that "[t]he wire image, not the protocol's specification, determines
      how third parties on the network paths among protocol participants will
      interact with that protocol" (<span><a href="https://www.rfc-editor.org/rfc/rfc8546#section-1" class="relref">Section 1</a> of [<a href="#RFC8546" class="xref">RFC8546</a>]</span>), and it can be expected that header information that is not
      encrypted will become ossified.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">Encryption does not itself prevent ossification of the network
      service. People seeking to understand or classify network traffic could
      still come to rely on pattern inferences and other heuristics or machine
      learning to derive measurement data and as the basis for network
      forwarding decisions <span>[<a href="#RFC8546" class="xref">RFC8546</a>]</span>. This can also
      create dependencies on the transport protocol or the patterns of
      traffic it can generate, also resulting in ossification of the
      service.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">Another motivation for using transport header encryption is to
      improve privacy and to decrease opportunities for surveillance. Users
      value the ability to protect their identity and location and defend
      against analysis of the traffic. Revelations about the use of pervasive
      surveillance <span>[<a href="#RFC7624" class="xref">RFC7624</a>]</span> have, to some extent, eroded
      trust in the service offered by network operators and have led to an
      increased use of encryption. Concerns have also been voiced about the
      addition of metadata to packets by third parties to provide analytics,
      customisation, advertising, cross-site tracking of users, 
      customer billing, or selectively allowing or blocking content.<a href="#section-4-7" class="pilcrow">¶</a></p>
<p id="section-4-8">Whatever the reasons, the IETF is designing protocols that include
      transport header encryption (e.g., QUIC <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span>) to supplement the already
      widespread payload encryption and to further limit exposure of
      transport metadata to the network.<a href="#section-4-8" class="pilcrow">¶</a></p>
<p id="section-4-9">If a transport protocol uses header encryption, the designers have to
      decide whether to encrypt all or a part of the transport-layer
      information. <span><a href="https://www.rfc-editor.org/rfc/rfc8558#section-4" class="relref">Section 4</a> of [<a href="#RFC8558" class="xref">RFC8558</a>]</span> states,
      "Anything exposed to the path should be done with the intent that it be
      used by the network elements on the path."<a href="#section-4-9" class="pilcrow">¶</a></p>
<p id="section-4-10">Certain transport header fields can be made observable to on-path
      network devices or can define new fields designed to explicitly expose
      observable transport-layer information to the network. Where exposed
      fields are intended to be immutable (i.e., can be observed but not
      modified by a network device), the endpoints are encouraged to use
      authentication to provide a cryptographic integrity check that can
      detect if these immutable fields have been modified by network devices.
      Authentication can help to prevent attacks that rely on sending packets
      that fake exposed control signals in transport headers (e.g., TCP RST
      spoofing). Making a part of a transport header observable or exposing
      new header fields can lead to ossification of that part of a header as
      network devices come to rely on observations of the exposed fields.<a href="#section-4-10" class="pilcrow">¶</a></p>
<p id="section-4-11">The use of transport header authentication and encryption therefore
      exposes a tussle between middlebox vendors, operators, researchers,
      applications developers, and end users:<a href="#section-4-11" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-12.1">On the one hand, future Internet protocols that support transport
          header encryption assist in the restoration of the end-to-end nature
          of the Internet by returning complex processing to the endpoints.
          Since middleboxes cannot modify what they cannot see, the use of
          transport header encryption can improve application and end-user
          privacy by reducing leakage of transport metadata to operators that
          deploy middleboxes.<a href="#section-4-12.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-12.2">On the other hand, encryption of transport-layer information has
          implications for network operators and researchers seeking to
          understand the dynamics of protocols and traffic patterns, since it
          reduces the information that is available to them.<a href="#section-4-12.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-13">The following briefly reviews some security design options for
      transport protocols. "A Survey of the Interaction between Security
      Protocols and Transport Services" <span>[<a href="#RFC8922" class="xref">RFC8922</a>]</span> provides
      more details concerning commonly used encryption methods at the
      transport layer.<a href="#section-4-13" class="pilcrow">¶</a></p>
<p id="section-4-14">Security work typically employs a design technique that seeks to
      expose only what is needed <span>[<a href="#RFC3552" class="xref">RFC3552</a>]</span>. This approach
      provides incentives to not reveal any information that is not necessary
      for the end-to-end communication. The IETF has provided guidelines for
      writing security considerations for IETF specifications <span>[<a href="#RFC3552" class="xref">RFC3552</a>]</span>.<a href="#section-4-14" class="pilcrow">¶</a></p>
<p id="section-4-15">Endpoint design choices impacting privacy also need to be considered
      as a part of the design process <span>[<a href="#RFC6973" class="xref">RFC6973</a>]</span>. The IAB
      has provided guidance for analysing and documenting privacy
      considerations within IETF specifications <span>[<a href="#RFC6973" class="xref">RFC6973</a>]</span>.<a href="#section-4-15" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-4-16">
        <dt id="section-4-16.1">Authenticating the Transport Protocol Header:</dt>
        <dd style="margin-left: 1.5em" id="section-4-16.2">
          <p id="section-4-16.2.1">Transport-layer header information can be authenticated. An example transport
          authentication mechanism is TCP Authentication Option (TCP-AO) <span>[<a href="#RFC5925" class="xref">RFC5925</a>]</span>. This TCP option authenticates the IP
          pseudo-header, TCP header, and TCP data. TCP-AO protects the
          transport layer, preventing attacks from disabling the TCP
          connection itself and provides replay protection. Such
          authentication might interact with middleboxes, depending on their
          behaviour <span>[<a href="#RFC3234" class="xref">RFC3234</a>]</span>.<a href="#section-4-16.2.1" class="pilcrow">¶</a></p>
<p id="section-4-16.2.2">The IPsec Authentication Header (AH) <span>[<a href="#RFC4302" class="xref">RFC4302</a>]</span> was designed to work at the network layer and authenticate
          the IP payload. This approach authenticates all transport headers
          and verifies their integrity at the receiver, preventing
          modification by network devices on the path. The IPsec Encapsulating
          Security Payload (ESP) <span>[<a href="#RFC4303" class="xref">RFC4303</a>]</span> can also
          provide authentication and integrity without confidentiality using
          the NULL encryption algorithm <span>[<a href="#RFC2410" class="xref">RFC2410</a>]</span>. SRTP
          <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span> is another example of a transport
          protocol that allows header authentication.<a href="#section-4-16.2.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-4-16.3">Integrity Check:</dt>
        <dd style="margin-left: 1.5em" id="section-4-16.4">Transport protocols usually employ
          integrity checks on the transport header information. Security
          methods usually employ stronger checks and can combine this with
          authentication. An integrity check that protects the immutable
          transport header fields, but can still expose the transport header
          information in the clear, allows on-path network devices to observe
          these fields. An integrity check is not able to prevent modification
          by network devices on the path but can prevent a receiving endpoint
          from accepting changes and avoid impact on the transport protocol
          operation, including some types of attack.<a href="#section-4-16.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-16.5">Selectively Encrypting Transport Headers and Payload:</dt>
        <dd style="margin-left: 1.5em" id="section-4-16.6">
          <p id="section-4-16.6.1">A
          transport protocol design that encrypts selected header fields
          allows specific transport header fields to be made observable by
          network devices on the path. This information is explicitly exposed
          either in a transport header field or lower layer protocol header. A
          design that only exposes immutable fields can also perform
          end-to-end authentication of these fields across the path to prevent
          undetected modification of the immutable transport headers.<a href="#section-4-16.6.1" class="pilcrow">¶</a></p>
<p id="section-4-16.6.2">Mutable fields in the transport header provide opportunities
          where on-path network devices can modify the transport behaviour
          (e.g., the extended headers described in <span>[<a href="#I-D.trammell-plus-abstract-mech" class="xref">PLUS-ABSTRACT-MECH</a>]</span>). An example of a
          method that encrypts some, but not all, transport header information
          is GRE-in-UDP <span>[<a href="#RFC8086" class="xref">RFC8086</a>]</span> when used with GRE
          encryption.<a href="#section-4-16.6.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-4-16.7">Optional Encryption of Header Information:</dt>
        <dd style="margin-left: 1.5em" id="section-4-16.8">There are
          implications to the use of optional header encryption in the design
          of a transport protocol, where support of optional mechanisms can
          increase the complexity of the protocol and its implementation and
          in the management decisions that have to be made to use variable
          format fields. Instead, fields of a specific type ought to be sent
          with the same level of confidentiality or integrity protection.<a href="#section-4-16.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-16.9">Greasing:</dt>
        <dd style="margin-left: 1.5em" id="section-4-16.10">
          <p id="section-4-16.10.1">Protocols often provide extensibility
          features, reserving fields or values for use by future versions of a
          specification. The specification of receivers has traditionally
          ignored unspecified values; however, on-path network devices have
          emerged that ossify to require a certain value in a field or reuse
          a field for another purpose. When the specification is later
          updated, it is impossible to deploy the new use of the field and
          forwarding of the protocol could even become conditional on a
          specific header field value.<a href="#section-4-16.10.1" class="pilcrow">¶</a></p>
<p id="section-4-16.10.2">A protocol can intentionally vary the value, format,
          and/or presence of observable transport header fields at random
          <span>[<a href="#RFC8701" class="xref">RFC8701</a>]</span>. This prevents a network device
          ossifying the use of a specific observable field and can ease future
          deployment of new uses of the value or code point. This is not a
          security mechanism, although the use can be combined with an
          authentication mechanism.<a href="#section-4-16.10.2" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-4-17">Different transports use encryption to protect their header
      information to varying degrees. The trend is towards increased
      protection.<a href="#section-4-17" class="pilcrow">¶</a></p>
</section>
</div>
<div id="EH2">
<section id="section-5">
      <h2 id="name-intentionally-exposing-tran">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-intentionally-exposing-tran" class="section-name selfRef">Intentionally Exposing Transport Information to the Network</a>
      </h2>
<p id="section-5-1">A transport protocol can choose to expose certain transport
      information to on-path devices operating at the network layer by sending
      observable fields. One approach is to make an explicit choice not to
      encrypt certain transport header fields, making this transport
      information observable by an on-path network device. Another approach is
      to expose transport information in a network-layer extension header (see
      <a href="#EH" class="xref">Section 5.1</a>). Both are examples of explicit information
      intended to be used by network devices on the path <span>[<a href="#RFC8558" class="xref">RFC8558</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Whatever the mechanism used to expose the information, a decision to
      expose only specific information places the transport endpoint in
      control of what to expose outside of the encrypted transport header.
      This decision can then be made independently of the transport protocol
      functionality. This can be done by exposing part of the transport header
      or as a network-layer option/extension.<a href="#section-5-2" class="pilcrow">¶</a></p>
<div id="EH">
<section id="section-5.1">
        <h3 id="name-exposing-transport-informat">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-exposing-transport-informat" class="section-name selfRef">Exposing Transport Information in Extension Headers</a>
        </h3>
<p id="section-5.1-1">At the network layer, packets can carry optional headers that
        explicitly expose transport header information to the on-path devices
        operating at the network layer (<a href="#tunlhf" class="xref">Section 2.3.2</a>). For
        example, an endpoint that sends an IPv6 hop-by-hop option <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span> can provide explicit transport-layer
        information that can be observed and used by network devices on the
        path. New hop-by-hop options are not recommended in <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span> "because nodes may be configured to
        ignore the Hop-by-Hop Options header, drop packets containing a
        Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop
        Options header to a slow processing path. Designers considering
        defining new hop-by-hop options need to be aware of this likely
        behavior."<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">Network-layer optional headers explicitly indicate the information
        that is exposed, whereas use of exposed transport header information
        first requires an observer to identify the transport protocol and its
        format. See <a href="#Current-demux" class="xref">Section 2.2</a>.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">An arbitrary path can include one or more network devices that drop
        packets that include a specific header or option used for this purpose
        (see <span>[<a href="#RFC7872" class="xref">RFC7872</a>]</span>). This could impact the proper
        functioning of the protocols using the path. Protocol methods can be
        designed to probe to discover whether the specific option(s) can be
        used along the current path, enabling use on arbitrary paths.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-5.2">
        <h3 id="name-common-exposed-transport-in">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-common-exposed-transport-in" class="section-name selfRef">Common Exposed Transport Information</a>
        </h3>
<p id="section-5.2-1">There are opportunities for multiple transport protocols to
        consistently supply common observable information <span>[<a href="#RFC8558" class="xref">RFC8558</a>]</span>. A common approach can result in an open
        definition of the observable fields. This has the potential that the
        same information can be utilised across a range of operational and
        analysis tools.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
</section>
<div id="exposing">
<section id="section-5.3">
        <h3 id="name-considerations-for-exposing">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-considerations-for-exposing" class="section-name selfRef">Considerations for Exposing Transport Information</a>
        </h3>
<p id="section-5.3-1">Considerations concerning what information, if any, it is
        appropriate to expose include:<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.3-2.1">On the one hand, explicitly exposing derived fields containing
            relevant transport information (e.g., metrics for loss, latency,
            etc.) can avoid network devices needing to derive this information
            from other header fields. This could result in development and
            evolution of transport-independent tools around a common
            observable header and permit transport protocols to also evolve
            independently of this ossified header <span>[<a href="#RFC8558" class="xref">RFC8558</a>]</span>.<a href="#section-5.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.3-2.2">On the other hand, protocols and implementations might be
            designed to avoid consistently exposing external information that
            corresponds to the actual internal information used by the
            protocol itself. An endpoint/protocol could choose to expose
            transport header information to optimise the benefit it gets from
            the network <span>[<a href="#RFC8558" class="xref">RFC8558</a>]</span>. The value of this
            information for analysing operation of the transport layer would
            be enhanced if the exposed information could be verified to match
            the transport protocol's observed behavior.<a href="#section-5.3-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.3-3">The motivation to include actual transport header information and
        the implications of network devices using this information has to be
        considered when proposing such a method. <span>[<a href="#RFC8558" class="xref">RFC8558</a>]</span>
 summarises this as:<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<blockquote id="section-5.3-4">
        When signals from endpoints to the path are independent from the
        signals used by endpoints to manage the flow's state mechanics, they
        may be falsified by an endpoint without affecting the peer's
        understanding of the flow's state. For encrypted flows, this
        divergence is not detectable by on-path devices.<a href="#section-5.3-4" class="pilcrow">¶</a>
</blockquote>
</section>
</div>
</section>
</div>
<div id="OAM">
<section id="section-6">
      <h2 id="name-addition-of-transport-oam-i">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-addition-of-transport-oam-i" class="section-name selfRef">Addition of Transport OAM Information to Network-Layer Headers</a>
      </h2>
<p id="section-6-1">Even when the transport headers are encrypted, on-path devices can
      make measurements by utilising additional protocol headers carrying OAM
      information in an additional packet header. OAM information can be
      included with packets to perform functions, such as identification of
      transport protocols and flows, to aide understanding of network or
      transport performance or to support network operations or mitigate the
      effects of specific network segments.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Using network-layer approaches to reveal information has the
      potential that the same method (and hence same observation and analysis
      tools) can be consistently used by multiple transport protocols. This
      approach also could be applied to methods beyond OAM (see <a href="#EH2" class="xref">Section 5</a>). There can also be less desirable implications
      from separating the operation of the transport protocol from the
      measurement framework.<a href="#section-6-2" class="pilcrow">¶</a></p>
<section id="section-6.1">
        <h3 id="name-use-of-oam-within-a-mainten">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-use-of-oam-within-a-mainten" class="section-name selfRef">Use of OAM within a Maintenance Domain</a>
        </h3>
<p id="section-6.1-1">OAM information can be restricted to a maintenance domain,
        typically owned and operated by a single entity. OAM information can
        be added at the ingress to the maintenance domain (e.g., an Ethernet
        protocol header with timestamps and sequence number information using
        a method such as 802.11ag or in-situ OAM <span>[<a href="#I-D.ietf-ippm-ioam-data" class="xref">IOAM-DATA</a>]</span> or as a part of the
        encapsulation protocol). This additional header information is not
        delivered to the endpoints and is typically removed at the egress of
        the maintenance domain.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">Although some types of measurements are supported, this approach
        does not cover the entire range of measurements described in this
        document. In some cases, it can be difficult to position measurement
        tools at the appropriate segments/nodes, and there can be challenges in
        correlating the downstream/upstream information when in-band OAM data
        is inserted by an on-path device.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-6.2">
        <h3 id="name-use-of-oam-across-multiple-">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-use-of-oam-across-multiple-" class="section-name selfRef">Use of OAM across Multiple Maintenance Domains</a>
        </h3>
<p id="section-6.2-1">OAM information can also be added at the network layer by the
        sender as an IPv6 extension header or an IPv4 option or in an
        encapsulation/tunnel header that also includes an extension header or
        option. This information can be used across multiple network segments
        or between the transport endpoints.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">One example is the IPv6 Performance and Diagnostic Metrics (PDM)
        destination option <span>[<a href="#RFC8250" class="xref">RFC8250</a>]</span>. This allows a
        sender to optionally include a destination option that carries header
        fields that can be used to observe timestamps and packet sequence
        numbers. This information could be authenticated by a receiving
        transport endpoint when the information is added at the sender and
        visible at the receiving endpoint, although methods to do this have
        not currently been proposed. This needs to be explicitly enabled at
        the sender.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="section-7">
      <h2 id="name-conclusions">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-conclusions" class="section-name selfRef">Conclusions</a>
      </h2>
<p id="section-7-1">Header authentication and encryption and strong integrity checks are being incorporated
      into new transport protocols and have important benefits. The pace of the
      development of transports using the WebRTC data channel and the rapid
      deployment of the QUIC transport protocol can both be attributed to
      using the combination of UDP as a substrate while providing
      confidentiality and authentication of the encapsulated transport headers
      and payload.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">This document has described some current practises, and the
      implications for some stakeholders, when transport-layer header
      encryption is used. It does not judge whether these practises are
      necessary or endorse the use of any specific practise. Rather, the
      intent is to highlight operational tools and practises to consider when
      designing and modifying transport protocols, so protocol designers can
      make informed choices about what transport header fields to encrypt and
      whether it might be beneficial to make an explicit choice to expose
      certain fields to devices on the network path. In making such a
      decision, it is important to balance:<a href="#section-7-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-7-3">
        <dt id="section-7-3.1">User Privacy:</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.2">The less transport header information that is
          exposed to the network, the lower the risk of leaking metadata that
          might have user privacy implications. Transports that chose to
          expose some header fields need to make a privacy assessment to
          understand the privacy cost versus benefit trade-off in making that
          information available. The design of the QUIC spin bit to the
          network is an example of such considered analysis.<a href="#section-7-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.3">Transport Ossification:</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.4">Unencrypted transport header fields are
          likely to ossify rapidly, as network devices come to rely on their
          presence, making it difficult to change the transport in future.
          This argues that the choice to expose information to the network is
          made deliberately and with care, since it is essentially defining a
          stable interface between the transport and the network. Some
          protocols will want to make that interface as limited as possible;
          other protocols might find value in exposing certain information to
          signal to the network or in allowing the network to change certain
          header fields as signals to the transport. The visible wire image of
          a protocol should be explicitly designed.<a href="#section-7-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.5">Network Ossification:</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.6">While encryption can reduce ossification of
          the transport protocol, it does not itself prevent ossification of
          the network service. People seeking to understand network traffic
          could still come to rely on pattern inferences and other heuristics
          or machine learning to derive measurement data and as the basis for
          network forwarding decisions <span>[<a href="#RFC8546" class="xref">RFC8546</a>]</span>. This
          creates dependencies on the transport protocol or the patterns of
          traffic it can generate, resulting in ossification of the
          service.<a href="#section-7-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.7">Impact on Operational Practice:</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.8">The network operations community
          has long relied on being able to understand Internet traffic
          patterns, both in aggregate and at the flow level, to support
          network management, traffic engineering, and troubleshooting.
          Operational practice has developed based on the information
          available from unencrypted transport headers. The IETF has supported
          this practice by developing operations and management specifications, interface 
   specifications, and associated Best
          Current Practices. Widespread deployment of transport protocols that
          encrypt their information will impact network operations unless
          operators can develop alternative practises that work without access
          to the transport header.<a href="#section-7-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.9">Pace of Evolution:</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.10">Removing obstacles to change can enable an
          increased pace of evolution. If a protocol changes its transport
          header format (wire image) or its transport behaviour, this can
          result in the currently deployed tools and methods becoming no
          longer relevant. Where this needs to be accompanied by development
          of appropriate operational support functions and procedures, it can
          incur a cost in new tooling to catch up with each change. Protocols
          that consistently expose observable data do not require such
          development but can suffer from ossification and need to consider
          if the exposed protocol metadata has privacy implications. There is
          no single deployment context; therefore, designers need to
          consider the diversity of operational networks (ISPs, enterprises,
          DDoS mitigation and firewall maintainers, etc.).<a href="#section-7-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.11">Supporting Common Specifications:</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.12">Common, open, transport
          specifications can stimulate engagement by developers, users,
          researchers, and the broader community. Increased protocol diversity
          can be beneficial in meeting new requirements, but the ability to
          innovate without public scrutiny risks point solutions that optimise
          for specific cases and that can accidentally disrupt operations
          of/in different parts of the network. The social contract that
          maintains the stability of the Internet relies on accepting common
          transport specifications and on it being possible to detect
          violations. The existence of independent measurements, transparency,
          and public scrutiny of transport protocol behaviour helps the
          community to enforce the social norm that protocol implementations
          behave fairly and conform (at least mostly) to the specifications.
          It is important to find new ways of maintaining that community trust
          as increased use of transport header encryption limits visibility
          into transport behaviour (see also <a href="#exposing" class="xref">Section 5.3</a>).<a href="#section-7-3.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.13">Impact on Benchmarking and Understanding Feature Interactions:</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.14">An appropriate vantage point for observation, coupled with timing
          information about traffic flows, provides a valuable tool for
          benchmarking network devices, endpoint stacks, and/or
          configurations. This can help understand complex feature
          interactions. An inability to observe transport header information
          can make it harder to diagnose and explore interactions between
          features at different protocol layers, a side effect of not allowing
          a choice of vantage point from which this information is observed.
          New approaches might have to be developed.<a href="#section-7-3.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.15">Impact on Research and Development:</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.16">Hiding transport header
          information can impede independent research into new mechanisms,
          measurements of behaviour, and development initiatives. Experience
          shows that transport protocols are complicated to design and complex
          to deploy and that individual mechanisms have to be evaluated while
          considering other mechanisms across a broad range of network
          topologies and with attention to the impact on traffic sharing the
          capacity. If increased use of transport header encryption results in
          reduced availability of open data, it could eliminate the
          independent checks to the standardisation process that have
          previously been in place from research and academic contributors
          (e.g., the role of the IRTF Internet Congestion Control Research
          Group (ICCRG) and research publications in reviewing new transport
          mechanisms and assessing the impact of their deployment).<a href="#section-7-3.16" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-7-4">Observable transport header information might be useful to various
      stakeholders. Other sets of stakeholders have incentives to limit what
      can be observed. This document does not make recommendations about what
      information ought to be exposed, to whom it ought to be observable, or
      how this will be achieved. There are also design choices about where
      observable fields are placed. For example, one location could be a part
      of the transport header outside of the encryption envelope; another
      alternative is to carry the information in a network-layer option or
      extension header. New transport protocol designs ought to explicitly
      identify any fields that are intended to be observed, consider if there
      are alternative ways of providing the information, and reflect on the
      implications of observable fields being used by on-path network devices
      and how this might impact user privacy and protocol evolution when these
      fields become ossified.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">As <span>[<a href="#RFC7258" class="xref">RFC7258</a>]</span> notes, "Making networks
      unmanageable to mitigate PM is not an acceptable
      outcome, but ignoring PM would go against the
      consensus documented here." Providing explicit information can help
      avoid traffic being inappropriately classified, impacting application
      performance. An appropriate balance will emerge over time as real
      instances of this tension are analysed <span>[<a href="#RFC7258" class="xref">RFC7258</a>]</span>.
      This balance between information exposed and information hidden ought to
      be carefully considered when specifying new transport protocols.<a href="#section-7-5" class="pilcrow">¶</a></p>
</section>
<div id="Security">
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">This document is about design and deployment considerations for
      transport protocols. Issues relating to security are discussed
      throughout this document.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">Authentication, confidentiality protection, and integrity protection
      are identified as transport features by <span>[<a href="#RFC8095" class="xref">RFC8095</a>]</span>.
      As currently deployed in the Internet, these features are generally
      provided by a protocol or layer on top of the transport protocol <span>[<a href="#RFC8922" class="xref">RFC8922</a>]</span>.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Confidentiality and strong integrity checks have properties that can
      also be incorporated into the design of a transport protocol or to
      modify an existing transport. Integrity checks can protect an endpoint
      from undetected modification of protocol fields by on-path network
      devices, whereas encryption and obfuscation or greasing can further
      prevent these headers being utilised by network devices <span>[<a href="#RFC8701" class="xref">RFC8701</a>]</span>. Preventing observation of headers provides an
      opportunity for greater freedom to update the protocols and can ease
      experimentation with new techniques and their final deployment in
      endpoints. A protocol specification needs to weigh the costs of
      ossifying common headers versus the potential benefits of exposing
      specific information that could be observed along the network path to
      provide tools to manage new variants of protocols.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">Header encryption can provide confidentiality of some or all of the
      transport header information. This prevents an on-path device from
      gaining knowledge of the header field. It therefore prevents mechanisms
      being built that directly rely on the information or seeks to infer
      semantics of an exposed header field. Reduced visibility into transport
      metadata can limit the ability to measure and characterise traffic and
      conversely can provide privacy benefits.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">Extending the transport payload security context to also include the
      transport protocol header protects both types of information with the
      same key. A privacy concern would arise if this key was shared with a
      third party, e.g., providing access to transport header information to
      debug a performance issue would also result in exposing the transport
      payload data to the same third party. Such risks would be mitigated
      using a layered security design that provides one domain of protection
      and associated keys for the transport payload and encrypted transport
      headers and a separate domain of protection and associated keys for any
      observable transport header fields.<a href="#section-8-5" class="pilcrow">¶</a></p>
<p id="section-8-6">Exposed transport headers are sometimes utilised as a part of the
      information to detect anomalies in network traffic. As stated in <span>[<a href="#RFC7258" class="xref">RFC7258</a>]</span>, "While PM is an
      attack, other forms of monitoring that might fit the definition of PM
      can be beneficial and not part of any attack, e.g., network management
      functions monitor packets or flows and anti-spam mechanisms need to see
      mail message content." This can be used
      as the first line of defence to identify potential threats from DoS or
      malware and redirect suspect traffic to dedicated nodes responsible for
      DoS analysis, for malware detection, or to perform packet "scrubbing" (the
      normalisation of packets so that there are no ambiguities in
      interpretation by the ultimate destination of the packet). These
      techniques are currently used by some operators to also defend from
      distributed DoS attacks.<a href="#section-8-6" class="pilcrow">¶</a></p>
<p id="section-8-7">Exposed transport header fields can also form a part of the
      information used by the receiver of a transport protocol to protect the
      transport layer from data injection by an attacker. In evaluating this
      use of exposed header information, it is important to consider whether
      it introduces a significant DoS threat. For example, an attacker could
      construct a DoS attack by sending packets with a sequence number that
      falls within the currently accepted range of sequence numbers at the
      receiving endpoint. This would then introduce additional work at the
      receiving endpoint, even though the data in the attacking packet might
      not finally be delivered by the transport layer. This is sometimes known
      as a "shadowing attack". An attack can, for example, disrupt
      receiver processing, trigger loss and retransmission, or make a
      receiving endpoint perform unproductive decryption of packets that
      cannot be successfully decrypted (forcing a receiver to commit
      decryption resources, or to update and then restore protocol state).<a href="#section-8-7" class="pilcrow">¶</a></p>
<p id="section-8-8">One mitigation to off-path attacks is to deny knowledge of what header
      information is accepted by a receiver or obfuscate the accepted header
      information, e.g., setting a nonpredictable initial value for a
      sequence number during a protocol handshake, as in <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>
      and <span>[<a href="#RFC6056" class="xref">RFC6056</a>]</span>, or a port
      value that cannot be predicted (see <span><a href="https://www.rfc-editor.org/rfc/rfc8085#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC8085" class="xref">RFC8085</a>]</span>). A receiver could also require additional
      information to be used as a part of a validation check before accepting
      packets at the transport layer, e.g., utilising a part of the sequence
      number space that is encrypted or by verifying an encrypted token not
      visible to an attacker. This would also mitigate against on-path
      attacks. An additional processing cost can be incurred when decryption
      is attempted before a receiver discards an injected packet.<a href="#section-8-8" class="pilcrow">¶</a></p>
<p id="section-8-9">The existence of open transport protocol standards and a research
      and operations community with a history of independent observation and
      evaluation of performance data encourage fairness and conformance to
      those standards. This suggests careful consideration will be made over
      where, and when, measurement samples are collected. An appropriate
      balance between encrypting some or all of the transport header
      information needs to be considered. Open data and accessibility to
      tools that can help understand trends in application deployment, network
      traffic, and usage patterns can all contribute to understanding security
      challenges.<a href="#section-8-9" class="pilcrow">¶</a></p>
<p id="section-8-10">The security and privacy considerations in "A Framework for
      Large-Scale Measurement of Broadband Performance (LMAP)" <span>[<a href="#RFC7594" class="xref">RFC7594</a>]</span> contain considerations for Active and Passive
      measurement techniques and supporting material on measurement
      context.<a href="#section-8-10" class="pilcrow">¶</a></p>
<p id="section-8-11">Addition of observable transport information to the path increases
      the information available to an observer and may, when this information
      can be linked to a node or user, reduce the privacy of the user. See the
      security considerations of <span>[<a href="#RFC8558" class="xref">RFC8558</a>]</span>.<a href="#section-8-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-9-1">This document has no IANA actions.<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10">
      <h2 id="name-informative-references">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="bufferbloat">[bufferbloat]</dt>
      <dd>
<span class="refAuthor">Gettys, J.</span> and <span class="refAuthor">K. Nichols</span>, <span class="refTitle">"Bufferbloat: Dark Buffers in the Internet"</span>, <span class="refContent">Communications of the ACM, Vol. 55, no. 1, pp. 57-65</span>, <span class="seriesInfo">DOI 10.1145/2063176.2063196</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://doi.org/10.1145/2063176.2063196">https://doi.org/10.1145/2063176.2063196</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-tls-dtls13">[DTLS]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tls-dtls13-43</span>, <time datetime="2021-04-30" class="refDate">30 April 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43">https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-ippm-ioam-data">[IOAM-DATA]</dt>
      <dd>
<span class="refAuthor">Brockners, F.</span>, <span class="refAuthor">Bhandari, S.</span>, and <span class="refAuthor">T. Mizrahi</span>, <span class="refTitle">"Data Fields for In-situ OAM"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ippm-ioam-data-12</span>, <time datetime="2021-02-21" class="refDate">21 February 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-12">https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-12</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-6man-ipv6-alt-mark">[IPV6-ALT-MARK]</dt>
      <dd>
<span class="refAuthor">Fioccola, G.</span>, <span class="refAuthor">Zhou, T.</span>, <span class="refAuthor">Cociglio, M.</span>, <span class="refAuthor">Qin, F.</span>, and <span class="refAuthor">R. Pang</span>, <span class="refTitle">"IPv6 Application of the Alternate Marking Method"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-6man-ipv6-alt-mark-06</span>, <time datetime="2021-05-31" class="refDate">31 May 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-06">https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Latency">[Latency]</dt>
      <dd>
<span class="refAuthor">Briscoe, B.</span>, <span class="refAuthor">Brunstrom, A.</span>, <span class="refAuthor">Petlund, A.</span>, <span class="refAuthor">Hayes, D.</span>, <span class="refAuthor">Ros, D.</span>, <span class="refAuthor">Tsang, I.</span>, <span class="refAuthor">Gjessing, S.</span>, <span class="refAuthor">Fairhurst, G.</span>, <span class="refAuthor">Griwodz, C.</span>, and <span class="refAuthor">M. Welzl</span>, <span class="refTitle">"Reducing Internet Latency: A Survey of Techniques and Their Merits"</span>, <span class="refContent">IEEE Communications Surveys &amp; Tutorials, vol. 18, no. 3, pp. 2149-2196,
 thirdquarter 2016</span>, <span class="seriesInfo">DOI 10.1109/COMST.2014.2375213</span>, <time datetime="2014-11" class="refDate">November 2014</time>, <span>&lt;<a href="https://doi.org/10.1109/COMST.2014.2375213">https://doi.org/10.1109/COMST.2014.2375213</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Measurement">[Measurement]</dt>
      <dd>
<span class="refAuthor">Fairhurst, G.</span>, <span class="refAuthor">Kuehlewind, M.</span>, and <span class="refAuthor">D. Lopez</span>, <span class="refTitle">"Measurement-based Protocol Design"</span>, <span class="refContent">European Conference on Networks and Communications, Oulu, Finland.</span>, <time datetime="2017-06" class="refDate">June 2017</time>. </dd>
<dd class="break"></dd>
<dt id="PAM-RTT">[PAM-RTT]</dt>
      <dd>
<span class="refAuthor">Trammell, B.</span> and <span class="refAuthor">M. Kuehlewind</span>, <span class="refTitle">"Revisiting the Privacy Implications of Two-Way Internet Latency Data"</span>, <span class="refContent">Passive and Active Measurement</span>, <time datetime="2018-03" class="refDate">March 2018</time>. </dd>
<dd class="break"></dd>
<dt id="I-D.trammell-plus-abstract-mech">[PLUS-ABSTRACT-MECH]</dt>
      <dd>
<span class="refAuthor">Trammell, B.</span>, <span class="refTitle">"Abstract Mechanisms for a Cooperative Path Layer under Endpoint Control"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-trammell-plus-abstract-mech-00</span>, <time datetime="2016-09-28" class="refDate">28 September 2016</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-trammell-plus-abstract-mech-00">https://datatracker.ietf.org/doc/html/draft-trammell-plus-abstract-mech-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-quic-qlog-main-schema">[QLOG]</dt>
      <dd>
<span class="refAuthor">Marx, R.</span>, <span class="refAuthor">Niccolini, L.</span>, and <span class="refAuthor">M. Seemann</span>, <span class="refTitle">"Main logging schema for qlog"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-qlog-main-schema-00</span>, <time datetime="2021-06-10" class="refDate">10 June 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-quic-qlog-main-schema-00">https://datatracker.ietf.org/doc/html/draft-ietf-quic-qlog-main-schema-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Quic-Trace">[Quic-Trace]</dt>
      <dd>
<span class="refTitle">"QUIC trace utilities"</span>, <span class="refContent">Commit 413c3a4</span>, <span>&lt;<a href="https://github.com/google/quic-trace">https://github.com/google/quic-trace</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="RFC2410">[RFC2410]</dt>
      <dd>
<span class="refAuthor">Glenn, R.</span> and <span class="refAuthor">S. Kent</span>, <span class="refTitle">"The NULL Encryption Algorithm and Its Use With IPsec"</span>, <span class="seriesInfo">RFC 2410</span>, <span class="seriesInfo">DOI 10.17487/RFC2410</span>, <time datetime="1998-11" class="refDate">November 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2410">https://www.rfc-editor.org/info/rfc2410</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2474">[RFC2474]</dt>
      <dd>
<span class="refAuthor">Nichols, K.</span>, <span class="refAuthor">Blake, S.</span>, <span class="refAuthor">Baker, F.</span>, and <span class="refAuthor">D. Black</span>, <span class="refTitle">"Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers"</span>, <span class="seriesInfo">RFC 2474</span>, <span class="seriesInfo">DOI 10.17487/RFC2474</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2474">https://www.rfc-editor.org/info/rfc2474</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2475">[RFC2475]</dt>
      <dd>
<span class="refAuthor">Blake, S.</span>, <span class="refAuthor">Black, D.</span>, <span class="refAuthor">Carlson, M.</span>, <span class="refAuthor">Davies, E.</span>, <span class="refAuthor">Wang, Z.</span>, and <span class="refAuthor">W. Weiss</span>, <span class="refTitle">"An Architecture for Differentiated Services"</span>, <span class="seriesInfo">RFC 2475</span>, <span class="seriesInfo">DOI 10.17487/RFC2475</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2475">https://www.rfc-editor.org/info/rfc2475</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2507">[RFC2507]</dt>
      <dd>
<span class="refAuthor">Degermark, M.</span>, <span class="refAuthor">Nordgren, B.</span>, and <span class="refAuthor">S. Pink</span>, <span class="refTitle">"IP Header Compression"</span>, <span class="seriesInfo">RFC 2507</span>, <span class="seriesInfo">DOI 10.17487/RFC2507</span>, <time datetime="1999-02" class="refDate">February 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2507">https://www.rfc-editor.org/info/rfc2507</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2508">[RFC2508]</dt>
      <dd>
<span class="refAuthor">Casner, S.</span> and <span class="refAuthor">V. Jacobson</span>, <span class="refTitle">"Compressing IP/UDP/RTP Headers for Low-Speed Serial Links"</span>, <span class="seriesInfo">RFC 2508</span>, <span class="seriesInfo">DOI 10.17487/RFC2508</span>, <time datetime="1999-02" class="refDate">February 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2508">https://www.rfc-editor.org/info/rfc2508</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2914">[RFC2914]</dt>
      <dd>
<span class="refAuthor">Floyd, S.</span>, <span class="refTitle">"Congestion Control Principles"</span>, <span class="seriesInfo">BCP 41</span>, <span class="seriesInfo">RFC 2914</span>, <span class="seriesInfo">DOI 10.17487/RFC2914</span>, <time datetime="2000-09" class="refDate">September 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2914">https://www.rfc-editor.org/info/rfc2914</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3168">[RFC3168]</dt>
      <dd>
<span class="refAuthor">Ramakrishnan, K.</span>, <span class="refAuthor">Floyd, S.</span>, and <span class="refAuthor">D. Black</span>, <span class="refTitle">"The Addition of Explicit Congestion Notification (ECN) to IP"</span>, <span class="seriesInfo">RFC 3168</span>, <span class="seriesInfo">DOI 10.17487/RFC3168</span>, <time datetime="2001-09" class="refDate">September 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3168">https://www.rfc-editor.org/info/rfc3168</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3234">[RFC3234]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span> and <span class="refAuthor">S. Brim</span>, <span class="refTitle">"Middleboxes: Taxonomy and Issues"</span>, <span class="seriesInfo">RFC 3234</span>, <span class="seriesInfo">DOI 10.17487/RFC3234</span>, <time datetime="2002-02" class="refDate">February 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3234">https://www.rfc-editor.org/info/rfc3234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3261">[RFC3261]</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="RFC3393">[RFC3393]</dt>
      <dd>
<span class="refAuthor">Demichelis, C.</span> and <span class="refAuthor">P. Chimento</span>, <span class="refTitle">"IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)"</span>, <span class="seriesInfo">RFC 3393</span>, <span class="seriesInfo">DOI 10.17487/RFC3393</span>, <time datetime="2002-11" class="refDate">November 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3393">https://www.rfc-editor.org/info/rfc3393</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3550">[RFC3550]</dt>
      <dd>
<span class="refAuthor">Schulzrinne, H.</span>, <span class="refAuthor">Casner, S.</span>, <span class="refAuthor">Frederick, R.</span>, and <span class="refAuthor">V. Jacobson</span>, <span class="refTitle">"RTP: A Transport Protocol for Real-Time Applications"</span>, <span class="seriesInfo">STD 64</span>, <span class="seriesInfo">RFC 3550</span>, <span class="seriesInfo">DOI 10.17487/RFC3550</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3550">https://www.rfc-editor.org/info/rfc3550</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3552">[RFC3552]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">B. Korver</span>, <span class="refTitle">"Guidelines for Writing RFC Text on Security Considerations"</span>, <span class="seriesInfo">BCP 72</span>, <span class="seriesInfo">RFC 3552</span>, <span class="seriesInfo">DOI 10.17487/RFC3552</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3552">https://www.rfc-editor.org/info/rfc3552</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3711">[RFC3711]</dt>
      <dd>
<span class="refAuthor">Baugher, M.</span>, <span class="refAuthor">McGrew, D.</span>, <span class="refAuthor">Naslund, M.</span>, <span class="refAuthor">Carrara, E.</span>, and <span class="refAuthor">K. Norrman</span>, <span class="refTitle">"The Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 3711</span>, <span class="seriesInfo">DOI 10.17487/RFC3711</span>, <time datetime="2004-03" class="refDate">March 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3711">https://www.rfc-editor.org/info/rfc3711</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4302">[RFC4302]</dt>
      <dd>
<span class="refAuthor">Kent, S.</span>, <span class="refTitle">"IP Authentication Header"</span>, <span class="seriesInfo">RFC 4302</span>, <span class="seriesInfo">DOI 10.17487/RFC4302</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4302">https://www.rfc-editor.org/info/rfc4302</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4303">[RFC4303]</dt>
      <dd>
<span class="refAuthor">Kent, S.</span>, <span class="refTitle">"IP Encapsulating Security Payload (ESP)"</span>, <span class="seriesInfo">RFC 4303</span>, <span class="seriesInfo">DOI 10.17487/RFC4303</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4303">https://www.rfc-editor.org/info/rfc4303</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4585">[RFC4585]</dt>
      <dd>
<span class="refAuthor">Ott, J.</span>, <span class="refAuthor">Wenger, S.</span>, <span class="refAuthor">Sato, N.</span>, <span class="refAuthor">Burmeister, C.</span>, and <span class="refAuthor">J. Rey</span>, <span class="refTitle">"Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"</span>, <span class="seriesInfo">RFC 4585</span>, <span class="seriesInfo">DOI 10.17487/RFC4585</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4585">https://www.rfc-editor.org/info/rfc4585</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4737">[RFC4737]</dt>
      <dd>
<span class="refAuthor">Morton, A.</span>, <span class="refAuthor">Ciavattone, L.</span>, <span class="refAuthor">Ramachandran, G.</span>, <span class="refAuthor">Shalunov, S.</span>, and <span class="refAuthor">J. Perser</span>, <span class="refTitle">"Packet Reordering Metrics"</span>, <span class="seriesInfo">RFC 4737</span>, <span class="seriesInfo">DOI 10.17487/RFC4737</span>, <time datetime="2006-11" class="refDate">November 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4737">https://www.rfc-editor.org/info/rfc4737</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4960">[RFC4960]</dt>
      <dd>
<span class="refAuthor">Stewart, R., Ed.</span>, <span class="refTitle">"Stream Control Transmission Protocol"</span>, <span class="seriesInfo">RFC 4960</span>, <span class="seriesInfo">DOI 10.17487/RFC4960</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4960">https://www.rfc-editor.org/info/rfc4960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5166">[RFC5166]</dt>
      <dd>
<span class="refAuthor">Floyd, S., Ed.</span>, <span class="refTitle">"Metrics for the Evaluation of Congestion Control Mechanisms"</span>, <span class="seriesInfo">RFC 5166</span>, <span class="seriesInfo">DOI 10.17487/RFC5166</span>, <time datetime="2008-03" class="refDate">March 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5166">https://www.rfc-editor.org/info/rfc5166</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5218">[RFC5218]</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="RFC5236">[RFC5236]</dt>
      <dd>
<span class="refAuthor">Jayasumana, A.</span>, <span class="refAuthor">Piratla, N.</span>, <span class="refAuthor">Banka, T.</span>, <span class="refAuthor">Bare, A.</span>, and <span class="refAuthor">R. Whitner</span>, <span class="refTitle">"Improved Packet Reordering Metrics"</span>, <span class="seriesInfo">RFC 5236</span>, <span class="seriesInfo">DOI 10.17487/RFC5236</span>, <time datetime="2008-06" class="refDate">June 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5236">https://www.rfc-editor.org/info/rfc5236</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5426">[RFC5426]</dt>
      <dd>
<span class="refAuthor">Okmianski, A.</span>, <span class="refTitle">"Transmission of Syslog Messages over UDP"</span>, <span class="seriesInfo">RFC 5426</span>, <span class="seriesInfo">DOI 10.17487/RFC5426</span>, <time datetime="2009-03" class="refDate">March 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5426">https://www.rfc-editor.org/info/rfc5426</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5481">[RFC5481]</dt>
      <dd>
<span class="refAuthor">Morton, A.</span> and <span class="refAuthor">B. Claise</span>, <span class="refTitle">"Packet Delay Variation Applicability Statement"</span>, <span class="seriesInfo">RFC 5481</span>, <span class="seriesInfo">DOI 10.17487/RFC5481</span>, <time datetime="2009-03" class="refDate">March 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5481">https://www.rfc-editor.org/info/rfc5481</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5795">[RFC5795]</dt>
      <dd>
<span class="refAuthor">Sandlund, K.</span>, <span class="refAuthor">Pelletier, G.</span>, and <span class="refAuthor">L-E. Jonsson</span>, <span class="refTitle">"The RObust Header Compression (ROHC) Framework"</span>, <span class="seriesInfo">RFC 5795</span>, <span class="seriesInfo">DOI 10.17487/RFC5795</span>, <time datetime="2010-03" class="refDate">March 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5795">https://www.rfc-editor.org/info/rfc5795</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5925">[RFC5925]</dt>
      <dd>
<span class="refAuthor">Touch, J.</span>, <span class="refAuthor">Mankin, A.</span>, and <span class="refAuthor">R. Bonica</span>, <span class="refTitle">"The TCP Authentication Option"</span>, <span class="seriesInfo">RFC 5925</span>, <span class="seriesInfo">DOI 10.17487/RFC5925</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5925">https://www.rfc-editor.org/info/rfc5925</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6056">[RFC6056]</dt>
      <dd>
<span class="refAuthor">Larsen, M.</span> and <span class="refAuthor">F. Gont</span>, <span class="refTitle">"Recommendations for Transport-Protocol Port Randomization"</span>, <span class="seriesInfo">BCP 156</span>, <span class="seriesInfo">RFC 6056</span>, <span class="seriesInfo">DOI 10.17487/RFC6056</span>, <time datetime="2011-01" class="refDate">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6056">https://www.rfc-editor.org/info/rfc6056</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6269">[RFC6269]</dt>
      <dd>
<span class="refAuthor">Ford, M., Ed.</span>, <span class="refAuthor">Boucadair, M.</span>, <span class="refAuthor">Durand, A.</span>, <span class="refAuthor">Levis, P.</span>, and <span class="refAuthor">P. Roberts</span>, <span class="refTitle">"Issues with IP Address Sharing"</span>, <span class="seriesInfo">RFC 6269</span>, <span class="seriesInfo">DOI 10.17487/RFC6269</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6269">https://www.rfc-editor.org/info/rfc6269</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6294">[RFC6294]</dt>
      <dd>
<span class="refAuthor">Hu, Q.</span> and <span class="refAuthor">B. Carpenter</span>, <span class="refTitle">"Survey of Proposed Use Cases for the IPv6 Flow Label"</span>, <span class="seriesInfo">RFC 6294</span>, <span class="seriesInfo">DOI 10.17487/RFC6294</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6294">https://www.rfc-editor.org/info/rfc6294</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6347">[RFC6347]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"Datagram Transport Layer Security Version 1.2"</span>, <span class="seriesInfo">RFC 6347</span>, <span class="seriesInfo">DOI 10.17487/RFC6347</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6347">https://www.rfc-editor.org/info/rfc6347</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6437">[RFC6437]</dt>
      <dd>
<span class="refAuthor">Amante, S.</span>, <span class="refAuthor">Carpenter, B.</span>, <span class="refAuthor">Jiang, S.</span>, and <span class="refAuthor">J. Rajahalme</span>, <span class="refTitle">"IPv6 Flow Label Specification"</span>, <span class="seriesInfo">RFC 6437</span>, <span class="seriesInfo">DOI 10.17487/RFC6437</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6437">https://www.rfc-editor.org/info/rfc6437</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6438">[RFC6438]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span> and <span class="refAuthor">S. Amante</span>, <span class="refTitle">"Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels"</span>, <span class="seriesInfo">RFC 6438</span>, <span class="seriesInfo">DOI 10.17487/RFC6438</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6438">https://www.rfc-editor.org/info/rfc6438</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6846">[RFC6846]</dt>
      <dd>
<span class="refAuthor">Pelletier, G.</span>, <span class="refAuthor">Sandlund, K.</span>, <span class="refAuthor">Jonsson, L-E.</span>, and <span class="refAuthor">M. West</span>, <span class="refTitle">"RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)"</span>, <span class="seriesInfo">RFC 6846</span>, <span class="seriesInfo">DOI 10.17487/RFC6846</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6846">https://www.rfc-editor.org/info/rfc6846</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6973">[RFC6973]</dt>
      <dd>
<span class="refAuthor">Cooper, A.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Aboba, B.</span>, <span class="refAuthor">Peterson, J.</span>, <span class="refAuthor">Morris, J.</span>, <span class="refAuthor">Hansen, M.</span>, and <span class="refAuthor">R. Smith</span>, <span class="refTitle">"Privacy Considerations for Internet Protocols"</span>, <span class="seriesInfo">RFC 6973</span>, <span class="seriesInfo">DOI 10.17487/RFC6973</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6973">https://www.rfc-editor.org/info/rfc6973</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7098">[RFC7098]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span>, <span class="refAuthor">Jiang, S.</span>, and <span class="refAuthor">W. Tarreau</span>, <span class="refTitle">"Using the IPv6 Flow Label for Load Balancing in Server Farms"</span>, <span class="seriesInfo">RFC 7098</span>, <span class="seriesInfo">DOI 10.17487/RFC7098</span>, <time datetime="2014-01" class="refDate">January 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7098">https://www.rfc-editor.org/info/rfc7098</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7126">[RFC7126]</dt>
      <dd>
<span class="refAuthor">Gont, F.</span>, <span class="refAuthor">Atkinson, R.</span>, and <span class="refAuthor">C. Pignataro</span>, <span class="refTitle">"Recommendations on Filtering of IPv4 Packets Containing IPv4 Options"</span>, <span class="seriesInfo">BCP 186</span>, <span class="seriesInfo">RFC 7126</span>, <span class="seriesInfo">DOI 10.17487/RFC7126</span>, <time datetime="2014-02" class="refDate">February 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7126">https://www.rfc-editor.org/info/rfc7126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7258">[RFC7258]</dt>
      <dd>
<span class="refAuthor">Farrell, S.</span> and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Pervasive Monitoring Is an Attack"</span>, <span class="seriesInfo">BCP 188</span>, <span class="seriesInfo">RFC 7258</span>, <span class="seriesInfo">DOI 10.17487/RFC7258</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7258">https://www.rfc-editor.org/info/rfc7258</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7413">[RFC7413]</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="RFC7414">[RFC7414]</dt>
      <dd>
<span class="refAuthor">Duke, M.</span>, <span class="refAuthor">Braden, R.</span>, <span class="refAuthor">Eddy, W.</span>, <span class="refAuthor">Blanton, E.</span>, and <span class="refAuthor">A. Zimmermann</span>, <span class="refTitle">"A Roadmap for Transmission Control Protocol (TCP) Specification Documents"</span>, <span class="seriesInfo">RFC 7414</span>, <span class="seriesInfo">DOI 10.17487/RFC7414</span>, <time datetime="2015-02" class="refDate">February 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7414">https://www.rfc-editor.org/info/rfc7414</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7567">[RFC7567]</dt>
      <dd>
<span class="refAuthor">Baker, F., Ed.</span> and <span class="refAuthor">G. Fairhurst, Ed.</span>, <span class="refTitle">"IETF Recommendations Regarding Active Queue Management"</span>, <span class="seriesInfo">BCP 197</span>, <span class="seriesInfo">RFC 7567</span>, <span class="seriesInfo">DOI 10.17487/RFC7567</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7567">https://www.rfc-editor.org/info/rfc7567</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7594">[RFC7594]</dt>
      <dd>
<span class="refAuthor">Eardley, P.</span>, <span class="refAuthor">Morton, A.</span>, <span class="refAuthor">Bagnulo, M.</span>, <span class="refAuthor">Burbridge, T.</span>, <span class="refAuthor">Aitken, P.</span>, and <span class="refAuthor">A. Akhter</span>, <span class="refTitle">"A Framework for Large-Scale Measurement of Broadband Performance (LMAP)"</span>, <span class="seriesInfo">RFC 7594</span>, <span class="seriesInfo">DOI 10.17487/RFC7594</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7594">https://www.rfc-editor.org/info/rfc7594</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7605">[RFC7605]</dt>
      <dd>
<span class="refAuthor">Touch, J.</span>, <span class="refTitle">"Recommendations on Using Assigned Transport Port Numbers"</span>, <span class="seriesInfo">BCP 165</span>, <span class="seriesInfo">RFC 7605</span>, <span class="seriesInfo">DOI 10.17487/RFC7605</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7605">https://www.rfc-editor.org/info/rfc7605</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7624">[RFC7624]</dt>
      <dd>
<span class="refAuthor">Barnes, R.</span>, <span class="refAuthor">Schneier, B.</span>, <span class="refAuthor">Jennings, C.</span>, <span class="refAuthor">Hardie, T.</span>, <span class="refAuthor">Trammell, B.</span>, <span class="refAuthor">Huitema, C.</span>, and <span class="refAuthor">D. Borkmann</span>, <span class="refTitle">"Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement"</span>, <span class="seriesInfo">RFC 7624</span>, <span class="seriesInfo">DOI 10.17487/RFC7624</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7624">https://www.rfc-editor.org/info/rfc7624</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7799">[RFC7799]</dt>
      <dd>
<span class="refAuthor">Morton, A.</span>, <span class="refTitle">"Active and Passive Metrics and Methods (with Hybrid Types In-Between)"</span>, <span class="seriesInfo">RFC 7799</span>, <span class="seriesInfo">DOI 10.17487/RFC7799</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7799">https://www.rfc-editor.org/info/rfc7799</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7872">[RFC7872]</dt>
      <dd>
<span class="refAuthor">Gont, F.</span>, <span class="refAuthor">Linkova, J.</span>, <span class="refAuthor">Chown, T.</span>, and <span class="refAuthor">W. Liu</span>, <span class="refTitle">"Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World"</span>, <span class="seriesInfo">RFC 7872</span>, <span class="seriesInfo">DOI 10.17487/RFC7872</span>, <time datetime="2016-06" class="refDate">June 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7872">https://www.rfc-editor.org/info/rfc7872</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7928">[RFC7928]</dt>
      <dd>
<span class="refAuthor">Kuhn, N., Ed.</span>, <span class="refAuthor">Natarajan, P., Ed.</span>, <span class="refAuthor">Khademi, N., Ed.</span>, and <span class="refAuthor">D. Ros</span>, <span class="refTitle">"Characterization Guidelines for Active Queue Management (AQM)"</span>, <span class="seriesInfo">RFC 7928</span>, <span class="seriesInfo">DOI 10.17487/RFC7928</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7928">https://www.rfc-editor.org/info/rfc7928</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7983">[RFC7983]</dt>
      <dd>
<span class="refAuthor">Petit-Huguenin, M.</span> and <span class="refAuthor">G. Salgueiro</span>, <span class="refTitle">"Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">RFC 7983</span>, <span class="seriesInfo">DOI 10.17487/RFC7983</span>, <time datetime="2016-09" class="refDate">September 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7983">https://www.rfc-editor.org/info/rfc7983</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8033">[RFC8033]</dt>
      <dd>
<span class="refAuthor">Pan, R.</span>, <span class="refAuthor">Natarajan, P.</span>, <span class="refAuthor">Baker, F.</span>, and <span class="refAuthor">G. White</span>, <span class="refTitle">"Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem"</span>, <span class="seriesInfo">RFC 8033</span>, <span class="seriesInfo">DOI 10.17487/RFC8033</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8033">https://www.rfc-editor.org/info/rfc8033</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8084">[RFC8084]</dt>
      <dd>
<span class="refAuthor">Fairhurst, G.</span>, <span class="refTitle">"Network Transport Circuit Breakers"</span>, <span class="seriesInfo">BCP 208</span>, <span class="seriesInfo">RFC 8084</span>, <span class="seriesInfo">DOI 10.17487/RFC8084</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8084">https://www.rfc-editor.org/info/rfc8084</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8085">[RFC8085]</dt>
      <dd>
<span class="refAuthor">Eggert, L.</span>, <span class="refAuthor">Fairhurst, G.</span>, and <span class="refAuthor">G. Shepherd</span>, <span class="refTitle">"UDP Usage Guidelines"</span>, <span class="seriesInfo">BCP 145</span>, <span class="seriesInfo">RFC 8085</span>, <span class="seriesInfo">DOI 10.17487/RFC8085</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8085">https://www.rfc-editor.org/info/rfc8085</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8086">[RFC8086]</dt>
      <dd>
<span class="refAuthor">Yong, L., Ed.</span>, <span class="refAuthor">Crabbe, E.</span>, <span class="refAuthor">Xu, X.</span>, and <span class="refAuthor">T. Herbert</span>, <span class="refTitle">"GRE-in-UDP Encapsulation"</span>, <span class="seriesInfo">RFC 8086</span>, <span class="seriesInfo">DOI 10.17487/RFC8086</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8086">https://www.rfc-editor.org/info/rfc8086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8087">[RFC8087]</dt>
      <dd>
<span class="refAuthor">Fairhurst, G.</span> and <span class="refAuthor">M. Welzl</span>, <span class="refTitle">"The Benefits of Using Explicit Congestion Notification (ECN)"</span>, <span class="seriesInfo">RFC 8087</span>, <span class="seriesInfo">DOI 10.17487/RFC8087</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8087">https://www.rfc-editor.org/info/rfc8087</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8095">[RFC8095]</dt>
      <dd>
<span class="refAuthor">Fairhurst, G., Ed.</span>, <span class="refAuthor">Trammell, B., Ed.</span>, and <span class="refAuthor">M. Kuehlewind, Ed.</span>, <span class="refTitle">"Services Provided by IETF Transport Protocols and Congestion Control Mechanisms"</span>, <span class="seriesInfo">RFC 8095</span>, <span class="seriesInfo">DOI 10.17487/RFC8095</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8095">https://www.rfc-editor.org/info/rfc8095</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8200">[RFC8200]</dt>
      <dd>
<span class="refAuthor">Deering, S.</span> and <span class="refAuthor">R. Hinden</span>, <span class="refTitle">"Internet Protocol, Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 86</span>, <span class="seriesInfo">RFC 8200</span>, <span class="seriesInfo">DOI 10.17487/RFC8200</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8200">https://www.rfc-editor.org/info/rfc8200</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8250">[RFC8250]</dt>
      <dd>
<span class="refAuthor">Elkins, N.</span>, <span class="refAuthor">Hamilton, R.</span>, and <span class="refAuthor">M. Ackermann</span>, <span class="refTitle">"IPv6 Performance and Diagnostic Metrics (PDM) Destination Option"</span>, <span class="seriesInfo">RFC 8250</span>, <span class="seriesInfo">DOI 10.17487/RFC8250</span>, <time datetime="2017-09" class="refDate">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8250">https://www.rfc-editor.org/info/rfc8250</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8289">[RFC8289]</dt>
      <dd>
<span class="refAuthor">Nichols, K.</span>, <span class="refAuthor">Jacobson, V.</span>, <span class="refAuthor">McGregor, A., Ed.</span>, and <span class="refAuthor">J. Iyengar, Ed.</span>, <span class="refTitle">"Controlled Delay Active Queue Management"</span>, <span class="seriesInfo">RFC 8289</span>, <span class="seriesInfo">DOI 10.17487/RFC8289</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8289">https://www.rfc-editor.org/info/rfc8289</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8290">[RFC8290]</dt>
      <dd>
<span class="refAuthor">Hoeiland-Joergensen, T.</span>, <span class="refAuthor">McKenney, P.</span>, <span class="refAuthor">Taht, D.</span>, <span class="refAuthor">Gettys, J.</span>, and <span class="refAuthor">E. Dumazet</span>, <span class="refTitle">"The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm"</span>, <span class="seriesInfo">RFC 8290</span>, <span class="seriesInfo">DOI 10.17487/RFC8290</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8290">https://www.rfc-editor.org/info/rfc8290</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8404">[RFC8404]</dt>
      <dd>
<span class="refAuthor">Moriarty, K., Ed.</span> and <span class="refAuthor">A. Morton, Ed.</span>, <span class="refTitle">"Effects of Pervasive Encryption on Operators"</span>, <span class="seriesInfo">RFC 8404</span>, <span class="seriesInfo">DOI 10.17487/RFC8404</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8404">https://www.rfc-editor.org/info/rfc8404</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</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="RFC8462">[RFC8462]</dt>
      <dd>
<span class="refAuthor">Rooney, N.</span> and <span class="refAuthor">S. Dawkins, Ed.</span>, <span class="refTitle">"Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)"</span>, <span class="seriesInfo">RFC 8462</span>, <span class="seriesInfo">DOI 10.17487/RFC8462</span>, <time datetime="2018-10" class="refDate">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8462">https://www.rfc-editor.org/info/rfc8462</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8517">[RFC8517]</dt>
      <dd>
<span class="refAuthor">Dolson, D., Ed.</span>, <span class="refAuthor">Snellman, J.</span>, <span class="refAuthor">Boucadair, M., Ed.</span>, and <span class="refAuthor">C. Jacquenet</span>, <span class="refTitle">"An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective"</span>, <span class="seriesInfo">RFC 8517</span>, <span class="seriesInfo">DOI 10.17487/RFC8517</span>, <time datetime="2019-02" class="refDate">February 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8517">https://www.rfc-editor.org/info/rfc8517</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8546">[RFC8546]</dt>
      <dd>
<span class="refAuthor">Trammell, B.</span> and <span class="refAuthor">M. Kuehlewind</span>, <span class="refTitle">"The Wire Image of a Network Protocol"</span>, <span class="seriesInfo">RFC 8546</span>, <span class="seriesInfo">DOI 10.17487/RFC8546</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8546">https://www.rfc-editor.org/info/rfc8546</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8548">[RFC8548]</dt>
      <dd>
<span class="refAuthor">Bittau, A.</span>, <span class="refAuthor">Giffin, D.</span>, <span class="refAuthor">Handley, M.</span>, <span class="refAuthor">Mazieres, D.</span>, <span class="refAuthor">Slack, Q.</span>, and <span class="refAuthor">E. Smith</span>, <span class="refTitle">"Cryptographic Protection of TCP Streams (tcpcrypt)"</span>, <span class="seriesInfo">RFC 8548</span>, <span class="seriesInfo">DOI 10.17487/RFC8548</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8548">https://www.rfc-editor.org/info/rfc8548</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8558">[RFC8558]</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="RFC8684">[RFC8684]</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="RFC8701">[RFC8701]</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="RFC8724">[RFC8724]</dt>
      <dd>
<span class="refAuthor">Minaburo, A.</span>, <span class="refAuthor">Toutain, L.</span>, <span class="refAuthor">Gomez, C.</span>, <span class="refAuthor">Barthel, D.</span>, and <span class="refAuthor">JC. Zúñiga</span>, <span class="refTitle">"SCHC: Generic Framework for Static Context Header Compression and Fragmentation"</span>, <span class="seriesInfo">RFC 8724</span>, <span class="seriesInfo">DOI 10.17487/RFC8724</span>, <time datetime="2020-04" class="refDate">April 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8724">https://www.rfc-editor.org/info/rfc8724</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8837">[RFC8837]</dt>
      <dd>
<span class="refAuthor">Jones, P.</span>, <span class="refAuthor">Dhesikan, S.</span>, <span class="refAuthor">Jennings, C.</span>, and <span class="refAuthor">D. Druta</span>, <span class="refTitle">"Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS"</span>, <span class="seriesInfo">RFC 8837</span>, <span class="seriesInfo">DOI 10.17487/RFC8837</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8837">https://www.rfc-editor.org/info/rfc8837</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8866">[RFC8866]</dt>
      <dd>
<span class="refAuthor">Begen, A.</span>, <span class="refAuthor">Kyzivat, P.</span>, <span class="refAuthor">Perkins, C.</span>, and <span class="refAuthor">M. Handley</span>, <span class="refTitle">"SDP: Session Description Protocol"</span>, <span class="seriesInfo">RFC 8866</span>, <span class="seriesInfo">DOI 10.17487/RFC8866</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8866">https://www.rfc-editor.org/info/rfc8866</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8922">[RFC8922]</dt>
      <dd>
<span class="refAuthor">Enghardt, T.</span>, <span class="refAuthor">Pauly, T.</span>, <span class="refAuthor">Perkins, C.</span>, <span class="refAuthor">Rose, K.</span>, and <span class="refAuthor">C. Wood</span>, <span class="refTitle">"A Survey of the Interaction between Security Protocols and Transport Services"</span>, <span class="seriesInfo">RFC 8922</span>, <span class="seriesInfo">DOI 10.17487/RFC8922</span>, <time datetime="2020-10" class="refDate">October 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8922">https://www.rfc-editor.org/info/rfc8922</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9000">[RFC9000]</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>
</dl>
</section>
<div id="Acknowledgements">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">The authors would like to thank <span class="contact-name">Mohamed Boucadair</span>, <span class="contact-name">Spencer Dawkins</span>, <span class="contact-name">Tom Herbert</span>, <span class="contact-name">Jana       Iyengar</span>, <span class="contact-name">Mirja Kühlewind</span>, <span class="contact-name">Kyle Rose</span>,
      <span class="contact-name">Kathleen Moriarty</span>, <span class="contact-name">Al Morton</span>, <span class="contact-name">Chris Seal</span>, <span class="contact-name">Joe Touch</span>, <span class="contact-name">Brian       Trammell</span>, <span class="contact-name">Chris Wood</span>,
      <span class="contact-name">Thomas Fossati</span>, <span class="contact-name">Mohamed Boucadair</span>, <span class="contact-name">Martin Thomson</span>, <span class="contact-name">David Black</span>, <span class="contact-name">Martin       Duke</span>, <span class="contact-name">Joel Halpern</span>, and members of TSVWG for their comments and
      feedback.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">This work has received funding from the European Union's
      Horizon 2020 research and innovation programme under grant agreement No
      688421 and the EU Stand ICT Call 4. The opinions expressed and
      arguments employed reflect only the authors' views. The European
      Commission is not responsible for any use that might be made of that
      information.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">This work has received funding from the UK Engineering and Physical
      Sciences Research Council under grant EP/R04144X/1.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Godred Fairhurst</span></div>
<div dir="auto" class="left"><span class="org">University of Aberdeen</span></div>
<div dir="auto" class="left"><span class="extended-address">Department of Engineering</span></div>
<div dir="auto" class="left"><span class="street-address">Fraser Noble Building</span></div>
<div dir="auto" class="left"><span class="locality">Aberdeen, Scotland</span></div>
<div dir="auto" class="left"><span class="postal-code">AB24 3UE</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:gorry@erg.abdn.ac.uk" class="email">gorry@erg.abdn.ac.uk</a>
</div>
<div class="url">
<span>URI:</span>
<a href="http://www.erg.abdn.ac.uk/" class="url">http://www.erg.abdn.ac.uk/</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Colin Perkins</span></div>
<div dir="auto" class="left"><span class="org">University of Glasgow</span></div>
<div dir="auto" class="left"><span class="extended-address">School of Computing Science</span></div>
<div dir="auto" class="left"><span class="locality">Glasgow, Scotland</span></div>
<div dir="auto" class="left"><span class="postal-code">G12 8QQ</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:csp@csperkins.org" class="email">csp@csperkins.org</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://csperkins.org/" class="url">https://csperkins.org/</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>