File: rfc9268.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 (2581 lines) | stat: -rw-r--r-- 124,849 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 9268: IPv6 Minimum Path MTU Hop-by-Hop Option</title>
<meta content="Robert M. Hinden" name="author">
<meta content="Godred Fairhurst" name="author">
<meta content="
       This document specifies a new IPv6 Hop-by-Hop Option that is used to
      record the Minimum Path MTU (PMTU) along the forward path between a source host
      to a destination host. The recorded value can then be communicated back
      to the source using the return Path MTU field in the Option. 
    " name="description">
<meta content="xml2rfc 3.14.2" name="generator">
<meta content="DPLPMTUD" name="keyword">
<meta content="PMTUD" name="keyword">
<meta content="9268" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.14.2
    Python 3.9.13
    appdirs 1.4.4
    ConfigArgParse 1.5.3
    google-i18n-address 2.5.1
    html5lib 1.1
    intervaltree 3.1.0
    Jinja2 3.1.2
    kitchen 1.2.6
    lxml 4.9.0
    MarkupSafe 2.1.1
    pycountry 22.3.5
    PyYAML 6.0
    requests 2.28.0
    setuptools 44.1.1
    six 1.16.0
    weasyprint 56.1
-->
<link href="rfc9268.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 {
  display: table;
  border: none;
  margin: 0 auto;
}

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

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

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

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

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

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

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

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

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

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  pre.breakable {
    break-inside: auto;
  }
  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 {
  break-inside: avoid;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9268" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option-15" 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 9268</td>
<td class="center">Path MTU Option</td>
<td class="right">August 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Hinden &amp; Fairhurst</td>
<td class="center">Experimental</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/rfc9268" class="eref">9268</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Experimental</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-08" class="published">August 2022</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">R. Hinden</div>
<div class="org">Check Point Software</div>
</div>
<div class="author">
      <div class="author-name">G. Fairhurst</div>
<div class="org">University of Aberdeen</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9268</h1>
<h1 id="title">IPv6 Minimum Path MTU Hop-by-Hop Option</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document specifies a new IPv6 Hop-by-Hop Option that is used to
      record the Minimum Path MTU (PMTU) along the forward path between a source host
      to a destination host. The recorded value can then be communicated back
      to the source using the return Path MTU field in the Option.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  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/rfc9268">https://www.rfc-editor.org/info/rfc9268</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) 2022 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised 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="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-example-operation" class="xref">Example Operation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-use-of-the-ipv6-hop-by-hop-" class="xref">Use of the IPv6 Hop-by-Hop Options Header</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-motivation-and-problem-solv" class="xref">Motivation and Problem Solved</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-applicability-statements" class="xref">Applicability Statements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-ipv6-minimum-path-mtu-hop-b" class="xref">IPv6 Minimum Path MTU Hop-by-Hop Option</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-router-host-and-transport-l" class="xref">Router, Host, and Transport Layer Behaviors</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-router-behavior" class="xref">Router Behavior</a></p>
</li>
              <li class="compact toc ulBare 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-host-operating-system-behav" class="xref">Host Operating System Behavior</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-transport-layer-behavior" class="xref">Transport  Layer Behavior</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3.2.1">
                    <p id="section-toc.1-1.6.2.3.2.1.1"><a href="#section-6.3.1" class="xref">6.3.1</a>.  <a href="#name-including-the-option-in-an-" class="xref">Including the Option in an Outgoing Packet</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3.2.2">
                    <p id="section-toc.1-1.6.2.3.2.2.1"><a href="#section-6.3.2" class="xref">6.3.2</a>.  <a href="#name-validation-of-the-packet-th" class="xref">Validation of the Packet that Includes the Option</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3.2.3">
                    <p id="section-toc.1-1.6.2.3.2.3.1"><a href="#section-6.3.3" class="xref">6.3.3</a>.  <a href="#name-receiving-the-option" class="xref">Receiving the Option</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3.2.4">
                    <p id="section-toc.1-1.6.2.3.2.4.1"><a href="#section-6.3.4" class="xref">6.3.4</a>.  <a href="#name-using-the-rtn-pmtu-field" class="xref">Using the Rtn-PMTU Field</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3.2.5">
                    <p id="section-toc.1-1.6.2.3.2.5.1"><a href="#section-6.3.5" class="xref">6.3.5</a>.  <a href="#name-detecting-path-changes" class="xref">Detecting Path Changes</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3.2.6">
                    <p id="section-toc.1-1.6.2.3.2.6.1"><a href="#section-6.3.6" class="xref">6.3.6</a>.  <a href="#name-detection-of-dropping-packe" class="xref">Detection of Dropping Packets that Include the Option</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-router-option-processing" class="xref">Router Option Processing</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-network-layer-host-processi" class="xref">Network-Layer Host Processing</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-validating-use-of-the-optio" class="xref">Validating Use of the Option Data</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-direct-use-of-the-rtn-pmtu-" class="xref">Direct Use of the Rtn-PMTU Value</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.5">
                <p id="section-toc.1-1.8.2.5.1"><a href="#section-8.5" class="xref">8.5</a>.  <a href="#name-using-the-rtn-pmtu-value-as" class="xref">Using the Rtn-PMTU Value as a Hint for Probing</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.6">
                <p id="section-toc.1-1.8.2.6.1"><a href="#section-8.6" class="xref">8.6</a>.  <a href="#name-impact-of-middleboxes" class="xref">Impact of Middleboxes</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-experiment-goals" class="xref">Experiment Goals</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-implementation-status" class="xref">Implementation Status</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-examples-of-usage" class="xref">Examples of Usage</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-B" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-C" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="Intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This document specifies a new IPv6 Hop-by-Hop (HBH) Option to record the
      minimum Maximum Transmission Unit (MTU) along the forward path between a
      source and a destination host. The source host creates a packet with
      this Option and initializes the Min-PMTU field with the value of the MTU
      for the outbound link that will be used to forward the packet towards
      the destination host.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">At each subsequent hop where the Option is processed, the router
      compares the value of the Min-PMTU field in the Option and the MTU of
      its outgoing link. If the MTU of the link is less than the Min-PMTU, it
      rewrites the value in the Option Data with the smaller value. When the
      packet arrives at the destination host, the host can send the value of
      the minimum Reported MTU for the path back to the source host using the
      Rtn-PMTU field in the Option. The source host can then use this value as
      input to the method that sets the Path MTU (PMTU) used by upper-layer
      protocols.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">The IPv6 Minimum Path MTU Hop-by-Hop (MinPMTU HBH) Option
      is designed to work with packet sizes that can be
      specified in the IPv6 header. The maximum packet size that can be
      specified in an IPv6 header is 65,535 octets (2<sup>16</sup>).<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">This method has the potential to complete Path MTU Discovery (PMTUD) in a
      single round-trip time, even over paths that have successive links, each
      with a lower MTU.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">The mechanism defined in this document is focused on unicast; it does
      not describe multicast. That is left for future work.<a href="#section-1-5" class="pilcrow">¶</a></p>
<div id="Intro1">
<section id="section-1.1">
        <h3 id="name-example-operation">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-example-operation" class="section-name selfRef">Example Operation</a>
        </h3>
<p id="section-1.1-1">The figure below illustrates the operation of the method. In this
        case, the path between the source host and the destination host
        comprises three links: the source has a link MTU of size MTU-S, the
        link between routers R1 and R2 has an MTU of size 9000 bytes, and the
        final link to the destination has an MTU of size MTU-D.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<span id="name-an-example-path-between-the"></span><div id="fig1">
<figure id="figure-1">
          <div class="alignCenter art-text artwork" id="section-1.1-2.1">
<pre>
+--------+         +----+        +----+         +-------+
|        |         |    |        |    |         |       |
| Sender +---------+ R1 +--------+ R2 +-------- + Dest. |
|        |         |    |        |    |         |       |
+--------+  MTU-S  +----+  9000B +----+  MTU-D  +-------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-an-example-path-between-the" class="selfRef">An Example Path between the Source Host and the Destination Host</a>
          </figcaption></figure>
</div>
<p id="section-1.1-3">Three scenarios are described:<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.1-4.1">
            <p id="section-1.1-4.1.1">Scenario 1 considers all links to have a 9000 byte MTU, and
            the method is supported by both routers. The initial Min-PMTU is
            not modified along the path. Therefore, the PMTU is 9000
            bytes.<a href="#section-1.1-4.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="section-1.1-4.2">
            <p id="section-1.1-4.2.1">Scenario 2 considers the link between R2 and the destination host
            (MTU-D) to have an MTU of 1500 bytes. This is the smallest MTU.
            Router R2 updates the Min-PMTU to 1500 bytes, and the method
            correctly updates the PMTU to 1500 bytes. Had there been another
            smaller MTU at a link further along the path that also supports
            the method, the lower MTU would also have been detected.<a href="#section-1.1-4.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="section-1.1-4.3">
            <p id="section-1.1-4.3.1">Scenario 3 considers the case where the router preceding the
            smallest link (R2) does not support the method, and the link to
            the destination host (MTU-D) has an MTU of 1500 bytes. Therefore,
            router R2 does not update the Min-PMTU to 1500 bytes. The method
            then fails to detect the actual PMTU.<a href="#section-1.1-4.3.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-1.1-5">In Scenarios 2 and 3, a lower PMTU would also fail to be detected
        in the case where PMTUD had been used and an ICMPv6 Packet Too Big
        (PTB) message had not been delivered to the sender <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span>.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
<p id="section-1.1-6">These scenarios are summarized in the table below. "H" in R1 and/or
        R2 columns means the router understands the MinPMTU HBH Option.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
<span id="name-three-scenarios-that-arise-"></span><table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-three-scenarios-that-arise-" class="selfRef">Three Scenarios That Arise from Using the Path Shown in Figure 1</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1"></th>
              <th class="text-left" rowspan="1" colspan="1">MTU-S</th>
              <th class="text-left" rowspan="1" colspan="1">MTU-D</th>
              <th class="text-left" rowspan="1" colspan="1">R1</th>
              <th class="text-left" rowspan="1" colspan="1">R2</th>
              <th class="text-left" rowspan="1" colspan="1">Rec PMTU</th>
              <th class="text-left" rowspan="1" colspan="1">Note</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">9000 B</td>
              <td class="text-left" rowspan="1" colspan="1">9000 B</td>
              <td class="text-left" rowspan="1" colspan="1">H</td>
              <td class="text-left" rowspan="1" colspan="1">H</td>
              <td class="text-left" rowspan="1" colspan="1">9000 B</td>
              <td class="text-left" rowspan="1" colspan="1">Endpoints attempt to use a 9000 B PMTU.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">9000 B</td>
              <td class="text-left" rowspan="1" colspan="1">1500 B</td>
              <td class="text-left" rowspan="1" colspan="1">H</td>
              <td class="text-left" rowspan="1" colspan="1">H</td>
              <td class="text-left" rowspan="1" colspan="1">1500 B</td>
              <td class="text-left" rowspan="1" colspan="1">Endpoints attempt to use a 1500 B PMTU.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3</td>
              <td class="text-left" rowspan="1" colspan="1">9000 B</td>
              <td class="text-left" rowspan="1" colspan="1">1500 B</td>
              <td class="text-left" rowspan="1" colspan="1">H</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">9000 B</td>
              <td class="text-left" rowspan="1" colspan="1">Endpoints attempt to use a 9000 B PMTU but
       need to implement a method to fall back to discover
       and use a 1500 B PMTU.</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<div id="Intro2">
<section id="section-1.2">
        <h3 id="name-use-of-the-ipv6-hop-by-hop-">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-use-of-the-ipv6-hop-by-hop-" class="section-name selfRef">Use of the IPv6 Hop-by-Hop Options Header</a>
        </h3>
<p id="section-1.2-1">As specified in <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>, IPv6
        allows nodes to optionally process the Hop-by-Hop header.
        Specifically, from <span><a href="https://www.rfc-editor.org/rfc/rfc8200#section-4" class="relref">Section 4</a> of [<a href="#RFC8200" class="xref">RFC8200</a>]</span>:<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<blockquote id="section-1.2-2">
          <p id="section-1.2-2.1">The Hop-by-Hop Options header is not inserted or deleted, but
            may be examined or processed by any node along a packet's delivery
            path, until the packet reaches the node (or each of the set of
            nodes, in the case of multicast) identified in the Destination
            Address field of the IPv6 header. The Hop-by-Hop Options header,
            when present, must immediately follow the IPv6 header. Its
            presence is indicated by the value zero in the Next Header field
            of the IPv6 header.<a href="#section-1.2-2.1" class="pilcrow">¶</a></p>
<p id="section-1.2-2.2">NOTE: While <span>[<a href="#RFC2460" class="xref">RFC2460</a>]</span> required
            that all nodes must examine and process the Hop-by-Hop Options
            header, it is now expected that nodes along a packet's delivery
            path only examine and process the Hop-by-Hop Options header if
            explicitly configured to do so.<a href="#section-1.2-2.2" class="pilcrow">¶</a></p>
</blockquote>
<p id="section-1.2-3">The Hop-by-Hop Option defined in this document is designed to take
        advantage of this property of how Hop-by-Hop Options are processed.
        Nodes that do not support this Option <span class="bcp14">SHOULD</span> ignore them. This can
        mean that the Min-PMTU value does not account for all links along a
        path.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="motivation">
<section id="section-2">
      <h2 id="name-motivation-and-problem-solv">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-motivation-and-problem-solv" class="section-name selfRef">Motivation and Problem Solved</a>
      </h2>
<p id="section-2-1">The current state of Path MTU Discovery on the Internet is
      problematic. The mechanisms defined in <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span> are known to not work well in all environments. It
      fails to work in various cases, including when nodes in the middle of
      the network do not send ICMPv6 PTB messages or rate-limited ICMPv6
      messages or do not have a return path to the source host. This results in many transport-layer connections being configured to
      use smaller packets (e.g., 1280 bytes) by default and makes it difficult
      to take advantage of paths with a larger PMTU where they do exist.
      Applications that send large packets are forced to use IPv6
      fragmentation <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>, which can
      reduce the reliability of Internet communication <span>[<a href="#RFC8900" class="xref">RFC8900</a>]</span>.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">Encapsulations and network-layer tunnels further reduce the payload
      size available for a transport protocol to use. Also, some use cases
      increase packet overhead, for example, Network Virtualization Using
      Generic Routing Encapsulation (NVGRE) <span>[<a href="#RFC7637" class="xref">RFC7637</a>]</span> encapsulates Layer 2 (L2) packets in an outer IP header and
      does not allow IP fragmentation.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">Sending larger packets can improve host performance, e.g., avoiding
      limits to packet processing by the packet rate. An example of this is how the
      packet-per-second
      rate required to reach wire speed on a 10G link with 1280
      byte packets is about 977K packets per second (pps) vs. 139K pps for
      9000 byte packets.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">The purpose of this document is to improve the situation by defining
      a mechanism that does not rely on reception of ICMPv6 PTB
      messages from nodes in the middle of the network. Instead, this provides
      information to the destination host about the Minimum Path MTU and
      sends this information back to the source host. This is expected to work
      better than the current mechanisms based on <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span>.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">A similar mechanism was proposed in 1988 for IPv4 in <span>[<a href="#RFC1063" class="xref">RFC1063</a>]</span> by Jeff Mogul, C. Kent, Craig
      Partridge, and Keith McCloghire. It was later obsoleted in 1990 by <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span>, which is the current deployed approach to
      Path MTU Discovery. In contrast, the method described in this document
      uses the Hop-by-Hop Option of IPv6. It does not replace PMTUD <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span>, Packetization Layer Path MTU Discovery
      (PLPMTUD) <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>, or Datagram Packetization Layer PMTU Discovery (DPLPMTUD) <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span> but rather is designed to compliment these
      methods.<a href="#section-2-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3">
      <h2 id="name-requirements-language">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
      </h2>
<p id="section-3-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
      "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>",
      "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>",
      "<span class="bcp14">NOT RECOMMENDED</span>", "<span class="bcp14">MAY</span>", and
      "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as described in
      BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals, as
      shown here.<a href="#section-3-1" class="pilcrow">¶</a></p>
</section>
<div id="app-state">
<section id="section-4">
      <h2 id="name-applicability-statements">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-applicability-statements" class="section-name selfRef">Applicability Statements</a>
      </h2>
<p id="section-4-1">The Path MTU Option is designed for environments where there is
      control over the hosts and nodes that connect them and where there is
      more than one MTU size in use, for example, in data centers and on paths
      between data centers to allow hosts to better take advantage of a path
      that is able to support a large PMTU.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">The design of the Option is so sufficiently simple that it can be
      executed on a router's fast path. A successful experiment depends on
      both implementation by host and router vendors and deployment by
      operators. The contained use case of connections within and between data
      centers could be a driver for deployment.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">The method could also be useful in other environments, including the
      general Internet, and offers an advantage when this Hop-by-Hop Option is
      supported on all paths. The method is more robust when used to probe the
      path using packets that do not carry application data and when also
      paired with a method like Packetization Layer PMTUD <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span> or Datagram Packetization Layer PMTU Discovery (DPLPMTUD) <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span>.<a href="#section-4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="HBH">
<section id="section-5">
      <h2 id="name-ipv6-minimum-path-mtu-hop-b">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-ipv6-minimum-path-mtu-hop-b" class="section-name selfRef">IPv6 Minimum Path MTU Hop-by-Hop Option</a>
      </h2>
<p id="section-5-1">The Minimum Path MTU Hop-by-Hop Option has the following format:<a href="#section-5-1" class="pilcrow">¶</a></p>
<span id="name-format-of-the-minimum-path-"></span><figure id="figure-2">
        <div class="alignCenter art-text artwork" id="section-5-2.1">
<pre>
 Option    Option    Option
  Type    Data Len   Data
+--------+--------+--------+--------+---------+-------+-+
|BBCTTTTT|00000100|     Min-PMTU    |     Rtn-PMTU    |R|
+--------+--------+--------+--------+---------+-------+-+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-format-of-the-minimum-path-" class="selfRef">Format of the Minimum Path MTU Hop-by-Hop Option</a>
        </figcaption></figure>
<p id="section-5-3">Option Type (see <span><a href="https://www.rfc-editor.org/rfc/rfc8200#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC8200" class="xref">RFC8200</a>]</span>):<a href="#section-5-3" class="pilcrow">¶</a></p>
<div class="alignCenter art-text artwork" id="section-5-4">
<pre>
  BB     00   Skip over this Option and continue processing.

  C       1   Option Data can change en route to the packet's final
              destination.

  TTTTT 10000 Option Type assigned from IANA [IANA-HBH].

  Length:  4  The size of the value field in Option Data
              field supports PMTU values from 0 to 65,534
              octets, the maximum size represented by the
              Path MTU Option.


  Min-PMTU: n 16-bits.  The minimum MTU recorded along the path
              in octets, reflecting the smallest link MTU that
              the packet experienced along the path.
              A value less than the IPv6 minimum link
              MTU [RFC8200] MUST be ignored.

  Rtn-PMTU: n 15-bits.  The returned Path MTU field, carrying the 15
              most significant bits of the latest received Min-PMTU
              field for the forward path.  The value zero means that
              no Reported MTU is being returned.

  R        n  1-bit.  R-Flag.   Set by the source to signal that
              the destination host should include the received
              Rtn-PMTU field updated by the reported Min-PMTU value
              when the destination host is to send a PMTU Option back
              to the source host.
</pre><a href="#section-5-4" class="pilcrow">¶</a>
</div>
<p id="section-5-5">NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag)
      could be implemented by a mask of the latest received Min-PMTU value
      with 0xFFFE, discarding the right-most bit and then performing a logical
      'OR' with the R-Flag value of the sender. This encoding fits in the
      minimum-sized Hop-by-Hop Option header.<a href="#section-5-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Behavior">
<section id="section-6">
      <h2 id="name-router-host-and-transport-l">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-router-host-and-transport-l" class="section-name selfRef">Router, Host, and Transport Layer Behaviors</a>
      </h2>
<div id="router">
<section id="section-6.1">
        <h3 id="name-router-behavior">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-router-behavior" class="section-name selfRef">Router Behavior</a>
        </h3>
<p id="section-6.1-1">Routers that are not configured to support Hop-by-Hop Options are
        not expected to examine or process the contents of this Option <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">Routers that support Hop-by-Hop Options but are not configured to
        support this Option <span class="bcp14">SHOULD</span> skip over this Option and continue to
        process the header <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">Routers that support this Option <span class="bcp14">MUST</span> compare the value of the
        Min-PMTU field with the MTU configured for the outgoing link. If the
        MTU of the outgoing link is less than the Min-PMTU, the router
        rewrites the Min-PMTU in the Option to use the smaller value. (The
        router processing is performed without checking the valid range of the
        Min-PMTU or the Rtn-PMTU fields.)<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">A router <span class="bcp14">MUST</span> ignore and <span class="bcp14">MUST NOT</span> change the
 Rtn-PMTU field or the R-Flag in the Option.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="host-os">
<section id="section-6.2">
        <h3 id="name-host-operating-system-behav">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-host-operating-system-behav" class="section-name selfRef">Host Operating System Behavior</a>
        </h3>
<p id="section-6.2-1">The PMTU entry associated with the destination in the host's
        destination cache <span>[<a href="#RFC4861" class="xref">RFC4861</a>]</span>
          <span class="bcp14">SHOULD</span> be
        updated after detecting a change using the IPv6 Minimum Path MTU
        Hop-by-Hop Option. This cached value can be used by other flows that
        share the host's destination cache.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">The value in the host destination cache <span class="bcp14">SHOULD</span> be used by
 PLPMTUD to select an initial PMTU for a flow. The cached PMTU is only
        increased by PLPMTUD when the Packetization Layer determines the path
        actually supports a larger PMTU <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span> <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span>.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
<p id="section-6.2-3">When requested to send an IPv6 packet with the MinPMTU HBH
        Option, the source host includes the Option in an outgoing packet. The
        source host <span class="bcp14">MUST</span> fill the Min-PMTU field with the MTU
 configured for the link over which it will send the packet on the next hop towards
        the destination host.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
<p id="section-6.2-4">When a host includes the Option in a packet it sends, the host
        <span class="bcp14">SHOULD</span> set the Rtn-PMTU field to the previously cached value of the
        received Minimum Path MTU for the flow in the Rtn-PMTU field (see
        <a href="#transportrec" class="xref">Section 6.3.3</a>). If this value is not set (for
        example, because there is no cached reported Min-PMTU value), the
        Rtn-PMTU field value <span class="bcp14">MUST</span> be set to zero.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
<p id="section-6.2-5">The source host <span class="bcp14">MAY</span> request the destination host to return the
        reported Min-PMTU value by setting the R-Flag in the Option of an
        outgoing packet. The R-Flag <span class="bcp14">SHOULD NOT</span> be set when the MinPMTU
 HBH Option was sent solely to provide requested feedback on the return
        Path MTU to avoid each response generating another response.<a href="#section-6.2-5" class="pilcrow">¶</a></p>
<p id="section-6.2-6">The destination host controls when to send a packet with this
        Option in response to an R-Flag, as well as which packets to include
        it in. The destination host <span class="bcp14">MAY</span> limit the rate at which it sends these
        packets.<a href="#section-6.2-6" class="pilcrow">¶</a></p>
<p id="section-6.2-7">A destination host only sets the R-Flag if it wishes the source
        host to also return the discovered PMTU value for the path from the
        destination to the source.<a href="#section-6.2-7" class="pilcrow">¶</a></p>
<p id="section-6.2-8">The normal sequence of operation of the R-Flag using the
        terminology from the diagram in <a href="#fig1" class="xref">Figure 1</a> is:<a href="#section-6.2-8" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-6.2-9">
          <li id="section-6.2-9.1">
            <p id="section-6.2-9.1.1">The source sends a probe to the destination. The sender sets
            the R-Flag.<a href="#section-6.2-9.1.1" class="pilcrow">¶</a></p>
</li>
          <li id="section-6.2-9.2">
            <p id="section-6.2-9.2.1">The destination responds by sending a probe including the
            received Min-PMTU as the Rtn-PMTU. A destination that does not
            wish to probe the return path sets the R-Flag to 0.<a href="#section-6.2-9.2.1" class="pilcrow">¶</a></p>
</li>
        </ol>
</section>
</div>
<div id="Transport">
<section id="section-6.3">
        <h3 id="name-transport-layer-behavior">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-transport-layer-behavior" class="section-name selfRef">Transport  Layer Behavior</a>
        </h3>
<p id="section-6.3-1">This Hop-by-Hop Option is intended to be used with a Path MTU
        Discovery method.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">PLPMTUD <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span> uses probe
        packets for two distinct functions:<a href="#section-6.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.3-3.1">Probe packets are used to confirm connectivity. Such probes can
          be of any size up to the Packetization Layer Path MTU (PLPMTU). These
   probe packets are sent to
          solicit a response using the path to the remote node. These probe
          packets can carry the Hop-by-Hop PMTU Option, providing the final
          size of the packet does not exceed the current PLPMTU. After
          validating that the packet originates from the path (<span><a href="https://www.rfc-editor.org/rfc/rfc8899#section-4.6.1" class="relref">Section 4.6.1</a> of [<a href="#RFC8899" class="xref">RFC8899</a>]</span>),
          the PLPMTUD method can use the reported size from the Hop-by-Hop Option as
          the next search point when it resumes the search algorithm. (This
          use resembles the use of the PTB_SIZE information in <span><a href="https://www.rfc-editor.org/rfc/rfc8899#section-4.6.2" class="relref">Section 4.6.2</a> of [<a href="#RFC8899" class="xref">RFC8899</a>]</span>.)<a href="#section-6.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.3-3.2">A second use of probe packets is to explore if a path supports a
          packet size greater than the current PLPMTU. If this probe packet is
          successfully delivered (as determined by the source host), then the
          PLPMTU is raised to the size of the successful probe. These probe
          packets do not usually set the Path MTU Hop-by-Hop Option. See
          <span><a href="https://www.rfc-editor.org/rfc/rfc8899#section-1.2" class="relref">Section 1.2</a> of [<a href="#RFC8899" class="xref">RFC8899</a>]</span>. <span><a href="https://www.rfc-editor.org/rfc/rfc8899#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC8899" class="xref">RFC8899</a>]</span> also
   describes ways that a probe packet can be constructed, depending on whether
          the probe packets carry application data.<a href="#section-6.3-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.3-4">The PMTU Hop-by-Hop Option probe can be sent on packets that
          include application data but needs to be robust to potential loss
          of the packet (i.e., with the possibility that retransmission might
          be needed if the packet is lost).<a href="#section-6.3-4" class="pilcrow">¶</a></p>
<p id="section-6.3-5">Using a PMTU probe on packets that do not carry application data
          will avoid the need for loss recovery if a router on the path drops
          packets that set this Option. (This avoids the transport needing to
          retransmit a lost packet that includes this Option.) This is the
          normal default format for both uses of probes.<a href="#section-6.3-5" class="pilcrow">¶</a></p>
<div id="transportsend">
<section id="section-6.3.1">
          <h4 id="name-including-the-option-in-an-">
<a href="#section-6.3.1" class="section-number selfRef">6.3.1. </a><a href="#name-including-the-option-in-an-" class="section-name selfRef">Including the Option in an Outgoing Packet</a>
          </h4>
<p id="section-6.3.1-1">The upper-layer protocol can request the MinPMTU HBH Option
          to be included in an outgoing IPv6 packet. A transport protocol (or
          upper-layer protocol) can include this Option only on specific
          packets used to test the path. This Option does not need to be
          included in all packets belonging to a flow.<a href="#section-6.3.1-1" class="pilcrow">¶</a></p>
<p id="section-6.3.1-2">NOTE: Including this Option in a large packet (e.g., one larger
          than the present PMTU) is not likely to be useful, since the large
          packet would itself be dropped by any link along the path with a
          smaller MTU, preventing the Min-PMTU information from reaching the
          destination host.<a href="#section-6.3.1-2" class="pilcrow">¶</a></p>
<p id="section-6.3.1-3">Discussion:<a href="#section-6.3.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.3.1-4.1">
              <p id="section-6.3.1-4.1.1">In the case of TCP, the Option could be included in a packet
              that carries a TCP segment sent after the connection is
              established. A segment without data could be used to avoid the
              need to retransmit this data if the probe packet is lost. The
              discovered value can be used to inform PLPMTUD <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>.<a href="#section-6.3.1-4.1.1" class="pilcrow">¶</a></p>
<p id="section-6.3.1-4.1.2">NOTE: A TCP SYN can also negotiate the Maximum Segment Size
              (MSS), which acts as an upper limit to the packet size that can
              be sent by a TCP sender. If this Option were to be included in a
              TCP SYN, it could increase the probability that the SYN segment
              is lost when routers on the path drop packets with this Option
              (see <a href="#HBHblackhole" class="xref">Section 6.3.6</a>), which could have an
              unwanted impact on the result of racing Options <span>[<a href="#I-D.ietf-taps-arch" class="xref">TAPS-ARCH</a>]</span> or feature
              negotiation.<a href="#section-6.3.1-4.1.2" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-6.3.1-4.2">
              <p id="section-6.3.1-4.2.1">The use with datagram transport protocols (e.g., UDP) is
              harder to characterize because applications using datagram
              transports range from very short-lived (low data-volume
              applications) exchanges to longer (bulk) exchanges of packets
              between the source and destination hosts <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>.<a href="#section-6.3.1-4.2.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-6.3.1-4.3">
              <p id="section-6.3.1-4.3.1">Simple-exchange protocols (i.e., low data-volume applications
              <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span> that only send one or
              a few packets per transaction) might assume that the PMTU is
              symmetrical. That is, the PMTU is the same in both directions
              or at least not smaller for the return path. This optimization
              does not hold when the paths are not symmetric.<a href="#section-6.3.1-4.3.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-6.3.1-4.4">
              <p id="section-6.3.1-4.4.1">The MinPMTU HBH Option can be used with ICMPv6
              <span>[<a href="#RFC4443" class="xref">RFC4443</a>]</span>. This requires a
              response from the remote node and therefore is restricted to use
              with ICMPv6 echo messages. The MinPMTU HBH Option
              could provide additional information about the PMTU that might
              be supported by a path. This could be used as a diagnostic tool
              to measure the PMTU of a path. As with other uses, the actual
              supported PMTU is only confirmed after receiving a response to a
              subsequent probe of the PMTU size.<a href="#section-6.3.1-4.4.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-6.3.1-4.5">
              <p id="section-6.3.1-4.5.1">A datagram transport can utilize DPLPMTUD <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span>. For
       example, QUIC (see <span><a href="https://www.rfc-editor.org/rfc/rfc9000#section-14.3" class="relref">Section 14.3</a> of [<a href="#RFC9000" class="xref">RFC9000</a>]</span>) can
              use DPLPMTUD to determine whether the path to a destination will
              support a desired maximum datagram size. When using the IPv6
              MinPMTU HBH Option, the Option could be added to an
              additional QUIC PMTU probe that is of minimal size (or one no
              larger than the currently supported PMTU size). Once the return
              Path MTU value in the MinPMTU HBH Option has been
              learned, DPLPMTUD can be triggered to test for a larger PLPMTU
              using an appropriately sized PLPMTU probe packet (see <span><a href="https://www.rfc-editor.org/rfc/rfc8899#section-5.3.1" class="relref">Section 5.3.1</a> of [<a href="#RFC8899" class="xref">RFC8899</a>]</span>).<a href="#section-6.3.1-4.5.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-6.3.1-4.6">
              <p id="section-6.3.1-4.6.1">The use of this Option with DNS and DNSSEC over UDP is
              expected to work for paths where the PMTU is symmetric. The DNS
              server will learn the PMTU from the DNS query messages. If the
              Rtn-PMTU value is smaller, then a large DNSSEC response might be
              dropped and the known problems with PMTUD will then occur. DNS
              and DNSSEC over transport protocols that can carry the PMTU
              ought to work.<a href="#section-6.3.1-4.6.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-6.3.1-4.7">
              <p id="section-6.3.1-4.7.1">This method also can be used with anycast to discover the
              PMTU of the path, but the use needs to be aware that the anycast
              binding might change.<a href="#section-6.3.1-4.7.1" class="pilcrow">¶</a></p>
</li>
          </ul>
</section>
</div>
<div id="transportvalid">
<section id="section-6.3.2">
          <h4 id="name-validation-of-the-packet-th">
<a href="#section-6.3.2" class="section-number selfRef">6.3.2. </a><a href="#name-validation-of-the-packet-th" class="section-name selfRef">Validation of the Packet that Includes the Option</a>
          </h4>
<p id="section-6.3.2-1">An upper-layer protocol (e.g., transport endpoint) using this
          Option needs to provide protection from data injection attacks by
          off-path devices <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>. This
          requires a method to assure that the information in the Option Data
          is provided by a node on the path. This validates that the packet
          forms a part of an existing flow, using context available at the
          upper layer. For example, a TCP connection or UDP application that
          maintains the related state and uses a randomized ephemeral port
          would provide this basic validation to protect from off-path data
          injection; 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>. IPsec <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span> and TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> provide greater assurance.<a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
<p id="section-6.3.2-2">The upper layer discards any received packet when the packet
          validation fails. When packet validation fails, the upper layer <span class="bcp14">MUST</span>
          also discard the associated Option Data from the MinPMTU HBH
          Option without further processing.<a href="#section-6.3.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="transportrec">
<section id="section-6.3.3">
          <h4 id="name-receiving-the-option">
<a href="#section-6.3.3" class="section-number selfRef">6.3.3. </a><a href="#name-receiving-the-option" class="section-name selfRef">Receiving the Option</a>
          </h4>
<p id="section-6.3.3-1">For a connection-oriented upper-layer protocol, caching of the
          received Min-PMTU could be implemented by saving the value in the
          connection context at the transport layer. A connectionless upper
          layer (e.g., one using UDP) requires the upper-layer protocol to
          cache the value for each flow it uses.<a href="#section-6.3.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3.3-2">A destination host that receives a MinPMTU HBH Option with
          the R-Flag <span class="bcp14">SHOULD</span> include the MinPMTU HBH Option in the next
          outgoing IPv6 packet for the corresponding flow.<a href="#section-6.3.3-2" class="pilcrow">¶</a></p>
<p id="section-6.3.3-3">A simple mechanism could only include this Option (with the
          Rtn-PMTU field set) the first time this Option is received or when
          it notifies a change in the Minimum Path MTU. This limits the number
          of packets, including the Option packets, that are sent. However, this
          does not provide robustness to packet loss or recovery after a
          sender loses state.<a href="#section-6.3.3-3" class="pilcrow">¶</a></p>
<p id="section-6.3.3-4">Discussion:<a href="#section-6.3.3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.3.3-5.1">
              <p id="section-6.3.3-5.1.1">Some upper-layer protocols send packets less frequently than
              the rate at which the host receives packets. This provides less
              frequent feedback of the received Rtn-PMTU value. However, a
              host always sends the most recent Rtn-PMTU value.<a href="#section-6.3.3-5.1.1" class="pilcrow">¶</a></p>
</li>
          </ul>
</section>
</div>
<div id="Rtn-MTU">
<section id="section-6.3.4">
          <h4 id="name-using-the-rtn-pmtu-field">
<a href="#section-6.3.4" class="section-number selfRef">6.3.4. </a><a href="#name-using-the-rtn-pmtu-field" class="section-name selfRef">Using the Rtn-PMTU Field</a>
          </h4>
<p id="section-6.3.4-1">The Rtn-PMTU field provides an indication of the PMTU from
          on-path routers. It does not necessarily reflect the actual PMTU
          between the source and destination hosts. Care therefore needs to be
          exercised in using the Rtn-PMTU value. Specifically:<a href="#section-6.3.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.3.4-2.1">The actual PMTU can be lower than the Rtn-PMTU value because
            the Min-PMTU field was not updated by a router on the path that
            did not process the Option.<a href="#section-6.3.4-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.4-2.2">The actual PMTU may be lower than the Rtn-PMTU value because
            there is a Layer 2 device with a lower MTU.<a href="#section-6.3.4-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.4-2.3">The actual PMTU may be larger than the Rtn-PMTU value because
            of a corrupted, delayed, or misordered response. A source host
            <span class="bcp14">MUST</span> ignore a Rtn-PMTU value larger than the MTU configured for
            the outgoing link.<a href="#section-6.3.4-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.4-2.4">The path might have changed between the time when the probe
            was sent and when the Rtn-PMTU value received.<a href="#section-6.3.4-2.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.3.4-3">IPv6 requires that every link in the Internet have an MTU of 1280
          octets or greater. A node <span class="bcp14">MUST</span> ignore a Rtn-PMTU value less than
          1280 octets <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>.<a href="#section-6.3.4-3" class="pilcrow">¶</a></p>
<p id="section-6.3.4-4">To avoid unintentional dropping of packets that exceed the actual
          PMTU (e.g., Scenario 3 in <a href="#Intro1" class="xref">Section 1.1</a>), the source host
          can delay increasing the PMTU until a probe packet with the size of
          the Rtn-PMTU value has been successfully acknowledged by the upper
          layer, confirming that the path supports the larger PMTU. This
          probing increases robustness but adds one additional path round-trip 
          time before the PMTU is updated. This use resembles that of PTB
          messages in <span><a href="https://www.rfc-editor.org/rfc/rfc8899#section-4.6" class="relref">Section 4.6</a> of DPLPMTUD [<a href="#RFC8899" class="xref">RFC8899</a>]</span> (with the important difference
   being that a PTB
          message can only seek to lower the PMTU, whereas this Option could
          trigger a probe packet to seek to increase the PMTU).<a href="#section-6.3.4-4" class="pilcrow">¶</a></p>
<p id="section-6.3.4-5"><span><a href="https://www.rfc-editor.org/rfc/rfc8201#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC8201" class="xref">RFC8201</a>]</span>
          provides guidance on the caching of PMTU information and also the
          relation to IPv6 flow labels. Implementations should consider the
          impact of Equal-Cost Multipath (ECMP) <span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span>, specifically, whether a PMTU ought to be
          maintained for each transport endpoint or for each network
          address.<a href="#section-6.3.4-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-6.3.5">
          <h4 id="name-detecting-path-changes">
<a href="#section-6.3.5" class="section-number selfRef">6.3.5. </a><a href="#name-detecting-path-changes" class="section-name selfRef">Detecting Path Changes</a>
          </h4>
<p id="section-6.3.5-1">Path characteristics can change, and the actual PMTU could
          increase or decrease over time, for instance, following a path
          change when packets are forwarded over a link with a different MTU
          than that previously used. To bound the delay in discovering an
          increase in the actual PMTU, a host with a link MTU larger than the
          current PMTU <span class="bcp14">SHOULD</span> periodically send the MinPMTU HBH Option
          with the R-bit set. DPLPMTUD provides recommendations concerning how
          this could be implemented (see <span><a href="https://www.rfc-editor.org/rfc/rfc8899#section-5.3" class="relref">Section 5.3</a> of [<a href="#RFC8899" class="xref">RFC8899</a>]</span>). Since the Option consumes less capacity
   than a full-sized probe packet, there can be an advantage in using this to
          detect a change in the path characteristics.<a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
</section>
<div id="HBHblackhole">
<section id="section-6.3.6">
          <h4 id="name-detection-of-dropping-packe">
<a href="#section-6.3.6" class="section-number selfRef">6.3.6. </a><a href="#name-detection-of-dropping-packe" class="section-name selfRef">Detection of Dropping Packets that Include the Option</a>
          </h4>
<p id="section-6.3.6-1">There is evidence that some middleboxes drop packets that include
          Hop-by-Hop Options. For example, a firewall might drop a packet that
          carries an unknown extension header or Option. This practice is
          expected to decrease as an Option becomes more widely used. It could
          result in the generation of an ICMPv6 message that indicates the problem.
          This could be used to (temporarily) suspend use of this Option.<a href="#section-6.3.6-1" class="pilcrow">¶</a></p>
<p id="section-6.3.6-2">A middlebox that silently discards a packet with this Option
          results in the dropping of any packet using the Option. This dropping
          can be avoided by appropriate configuration in a controlled
          environment, such as within a data center, but it needs to be
          considered for Internet usage. <a href="#host-os" class="xref">Section 6.2</a> recommends
          that this Option is not used on packets where loss might adversely
          impact performance.<a href="#section-6.3.6-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="IANA">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">IANA has registered an IPv6 Hop-by-Hop Option type 
      in the "Destination Options and Hop-by-Hop Options"
      registry within the "Internet Protocol Version 6 (IPv6) Parameters" registry group <span>[<a href="#IANA-HBH" class="xref">IANA-HBH</a>]</span>. This assignment is
      shown in <a href="#HBH" class="xref">Section 5</a>.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<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 section discusses the security considerations. It first reviews
      router Option processing. It then reviews host processing when receiving
      this Option at the network layer. It then considers two ways in which
      the Option Data can be processed, followed by two approaches for using
      the Option Data. Finally, it discusses middlebox implications related to
      use in the general Internet.<a href="#section-8-1" class="pilcrow">¶</a></p>
<div id="Security-router">
<section id="section-8.1">
        <h3 id="name-router-option-processing">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-router-option-processing" class="section-name selfRef">Router Option Processing</a>
        </h3>
<p id="section-8.1-1">This Option shares the characteristics of all other IPv6 Hop-by-Hop
        Options, in that, if not supported at line rate, it could be used to
        degrade the performance of a router. This Option, while simple, is no
        different than other uses of IPv6 Hop-by-Hop Options.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">It is common for routers to ignore the Hop-by-Hop Option header or
        to drop packets containing a Hop-by-Hop Option header. Routers
        implementing IPv6 according to <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span> only examine and process the Hop-by-Hop Options
        header if explicitly configured to do so.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security-net">
<section id="section-8.2">
        <h3 id="name-network-layer-host-processi">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-network-layer-host-processi" class="section-name selfRef">Network-Layer Host Processing</a>
        </h3>
<p id="section-8.2-1">A malicious attacker can forge a packet directed at a host that
        carries the MinPMTU HBH Option. By design, the fields of this IP
        Option can be modified by the network.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">For comparison, the ICMPv6 PTB message used in Path MTU Discovery <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span> and the source
        host have an inherent trust relationship with the destination host
        including this Option. This trust relationship can be used to help
        verify the Option. ICMPv6 PTB messages are sent from any
        router on the path to the destination host. The source host has no
        prior knowledge of these routers (except for the first hop
        router).<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<p id="section-8.2-3">Reception of this packet will require processing as the network
        stack parses the packet before the packet is delivered to the 
        upper-layer protocol. This network-layer Option processing is normally
        completed before any upper-layer protocol delivery checks are
        performed.<a href="#section-8.2-3" class="pilcrow">¶</a></p>
<p id="section-8.2-4">The network layer does not normally have sufficient information to
        validate that the packet carrying an Option originated from the
        destination (or an on-path node). It also does not typically have
        sufficient context to demultiplex the packet to identify the related
        transport flow. This can mean that any changes resulting from
        reception of the Option applies to all flows between a pair of
        endpoints.<a href="#section-8.2-4" class="pilcrow">¶</a></p>
<p id="section-8.2-5">These considerations are no different than other uses of Hop-by-Hop
        Options, and this is the use case for PMTUD. The following section
        describes a mitigation for this attack.<a href="#section-8.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security-upp">
<section id="section-8.3">
        <h3 id="name-validating-use-of-the-optio">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-validating-use-of-the-optio" class="section-name selfRef">Validating Use of the Option Data</a>
        </h3>
<p id="section-8.3-1">Transport protocols should be designed to provide protection from
        data injection attacks by off-path devices, and mechanisms should be
        described in the Security Considerations section for each transport
        specification (see <span><a href="https://www.rfc-editor.org/rfc/rfc8085#section-5.1" class="relref">Section 5.1</a> of "UDP Usage Guidelines" [<a href="#RFC8085" class="xref">RFC8085</a>]</span>). For example, a TCP or UDP
        application that maintains the related state and uses a randomized
        ephemeral port would provide basic protection. TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> or IPsec <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span> provide cryptographic authentication. An upper-layer 
        protocol that validates each received packet discards any packet
        when this validation fails. In this case, the host <span class="bcp14">MUST</span> also discard
        the associated Option Data from the MinPMTU HBH Option without
        further processing (<a href="#Transport" class="xref">Section 6.3</a>).<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<p id="section-8.3-2">A network node on the path has visibility of all packets it
        forwards. By observing the network packet payload, the node might be
        able to construct a packet that might be validated by the destination
        host. Such a node would also be able to drop or limit the flow in
        other ways that could be potentially more disruptive. Authenticating
        the packet, for example, using IPsec <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span> or TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>
        mitigates this attack. Note that the authentication style of the Authentication
 Header (AH)
 <span>[<a href="#RFC4302" class="xref">RFC4302</a>]</span>, while authenticating the payload
        and outer IPv6 header, does not check Hop-by-Hop Options that change
        on route.<a href="#section-8.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security-pmtud">
<section id="section-8.4">
        <h3 id="name-direct-use-of-the-rtn-pmtu-">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-direct-use-of-the-rtn-pmtu-" class="section-name selfRef">Direct Use of the Rtn-PMTU Value</a>
        </h3>
<p id="section-8.4-1">The simplest way to utilize the Rtn-PMTU value is to directly use
        this to update the PMTU. This approach results in a set of security
        issues when the Option carries malicious data:<a href="#section-8.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.4-2.1">
            <p id="section-8.4-2.1.1">A direct update of the PMTU using the Rtn-PMTU value could
            result in an attacker inflating or reducing the size of the host
            PMTU for the destination. Forcing a reduction in the PMTU can
            decrease the efficiency of network use, might increase the number
            of packets/fragments required to send the same volume of payload
            data, and can prevent sending an unfragmented datagram larger than
            the PMTU. Increasing the PMTU can result in a path silently dropping packets
            (described as a black hole in <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span>) when
            the source host sends packets larger than the actual PMTU. This
            persists until the PMTU is next updated.<a href="#section-8.4-2.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="section-8.4-2.2">
            <p id="section-8.4-2.2.1">The method can be used to solicit a response from the
            destination host. A malicious attacker could forge a packet that
            causes the destination to add the Option to a packet sent to the
            source host. A forged value of Rtn-PMTU in the Option Data might
            also impact the remote endpoint, as described in the previous
            bullet. This persists until a valid MinPMTU HBH Option is
            received. This attack could be mitigated by limiting the sending
            of the MinPMTU HBH Option in reply to incoming packets that
            carry the Option.<a href="#section-8.4-2.2.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</section>
</div>
<div id="Security-dplpmtud">
<section id="section-8.5">
        <h3 id="name-using-the-rtn-pmtu-value-as">
<a href="#section-8.5" class="section-number selfRef">8.5. </a><a href="#name-using-the-rtn-pmtu-value-as" class="section-name selfRef">Using the Rtn-PMTU Value as a Hint for Probing</a>
        </h3>
<p id="section-8.5-1">Another way to utilize the Rtn-PMTU value is to indirectly trigger
        a probe to determine if the path supports a PMTU of size Rtn-PMTU.
        This approach needs context for the flow and hence assumes an upper-layer 
        protocol that validates the packet that carries the Option (see
        <a href="#Security-upp" class="xref">Section 8.3</a>). This is the case when used in
        combination with DPLPMTUD <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span>.
        A set of security considerations result when an Option carries
        malicious data:<a href="#section-8.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.5-2.1">If the forged packet carries a validated Option with a non-zero
          Rtn-PMTU field, the upper-layer protocol could utilize the
          information in the Rtn-PMTU field. A Rtn-PMTU larger than the
          current PMTU can trigger a probe for a new size.<a href="#section-8.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.5-2.2">If the forged packet carries a non-zero Min-PMTU field, the
          upper-layer protocol would change the cached information about the
          path from the source. The cached information at the destination host
          will be overwritten when the host receives another packet that
          includes a MinPMTU HBH Option corresponding to the flow.<a href="#section-8.5-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.5-2.3">Processing of the Option could cause a destination host to add
          the MinPMTU HBH Option to a packet sent to the source host.
          This Option will carry a Rtn-PMTU value that could have been updated
          by the forged packet. The impact of the source host receiving this
          resembles that discussed previously.<a href="#section-8.5-2.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="Security-mbox">
<section id="section-8.6">
        <h3 id="name-impact-of-middleboxes">
<a href="#section-8.6" class="section-number selfRef">8.6. </a><a href="#name-impact-of-middleboxes" class="section-name selfRef">Impact of Middleboxes</a>
        </h3>
<p id="section-8.6-1">There is evidence that some middleboxes drop packets that include
        Hop-by-Hop Options. For example, a firewall might drop a packet that
        carries an unknown extension header or Option. This practice is
        expected to decrease as the Option becomes more widely used. Methods
        to address this are discussed in <a href="#HBHblackhole" class="xref">Section 6.3.6</a>.<a href="#section-8.6-1" class="pilcrow">¶</a></p>
<p id="section-8.6-2">When a forged packet causes a packet that includes the MinPMTU HBH 
        Option to be sent and the return path does not forward packets with 
        this Option, the packet will be dropped (see <a href="#HBHblackhole" class="xref">Section 6.3.6</a>). This attack is mitigated by validating the
        Option Data before use and by limiting the rate of responses
        generated. An upper layer could further mitigate the impact by
        responding to an R-Flag by including the Option in a packet that does
        not carry application data.<a href="#section-8.6-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="EXP">
<section id="section-9">
      <h2 id="name-experiment-goals">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-experiment-goals" class="section-name selfRef">Experiment Goals</a>
      </h2>
<p id="section-9-1">This section describes the experimental goals of this
      specification.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">A successful deployment of the method depends upon several components
      being implemented and deployed:<a href="#section-9-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9-3.1">Support in the sending node (see <a href="#host-os" class="xref">Section 6.2</a>). This also requires corresponding support in
        upper-layer protocols (see <a href="#Transport" class="xref">Section 6.3</a>).<a href="#section-9-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-3.2">Router support in nodes (see <a href="#router" class="xref">Section 6.1</a>). The IETF continues to provide recommendations on
        the use of IPv6 Hop-by-Hop Options, for example, see <span><a href="https://www.rfc-editor.org/rfc/rfc9099#section-2.2.2" class="relref">Section 2.2.2</a> of [<a href="#RFC9099" class="xref">RFC9099</a>]</span>. This document does not update the
        way router implementations configure support for Hop-by-Hop Options.<a href="#section-9-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-3.3">Support in the receiving node (see <a href="#transportrec" class="xref">Section 6.3.3</a>).<a href="#section-9-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-9-4">Experience from deployment is an expected input to any decision to
      progress this specification from Experimental to IETF Standards Track.
      Appropriate inputs might include:<a href="#section-9-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9-5.1">reports of implementation experience,<a href="#section-9-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-5.2">measurements of the number paths where the method can be
        used, or<a href="#section-9-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-5.3">measurements showing the benefit realized or the implications of
        using specific methods over specific paths.<a href="#section-9-5.3" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="IMP">
<section id="section-10">
      <h2 id="name-implementation-status">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-implementation-status" class="section-name selfRef">Implementation Status</a>
      </h2>
<p id="section-10-1">At the time this document was published, there are two known
      implementations of the Path MTU Hop-by-Hop Option. These are:<a href="#section-10-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10-2.1">Wireshark dissector. This is shipping in production in Wireshark
        version 3.2 <span>[<a href="#WIRESHARK" class="xref">WIRESHARK</a>]</span>.<a href="#section-10-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-10-2.2">A prototype in the open source version of the FD.io Vector Packet
        Processing (VPP) technology <span>[<a href="#VPP" class="xref">VPP</a>]</span>. At
        the time this document was published, the source code can be found
        <span>[<a href="#VPP_SRC" class="xref">VPP_SRC</a>]</span>.<a href="#section-10-2.2" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<section id="section-11">
      <h2 id="name-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-11.1">
        <h3 id="name-normative-references">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="IANA-HBH">[IANA-HBH]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Destination Options and Hop-by-Hop Options"</span>, <span>&lt;<a href="https://www.iana.org/assignments/ipv6-parameters/">https://www.iana.org/assignments/ipv6-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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="RFC8201">[RFC8201]</dt>
      <dd>
<span class="refAuthor">McCann, J.</span>, <span class="refAuthor">Deering, S.</span>, <span class="refAuthor">Mogul, J.</span>, and <span class="refAuthor">R. Hinden, Ed.</span>, <span class="refTitle">"Path MTU Discovery for IP version 6"</span>, <span class="seriesInfo">STD 87</span>, <span class="seriesInfo">RFC 8201</span>, <span class="seriesInfo">DOI 10.17487/RFC8201</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8201">https://www.rfc-editor.org/info/rfc8201</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-11.2">
        <h3 id="name-informative-references">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC1063">[RFC1063]</dt>
        <dd>
<span class="refAuthor">Mogul, J.</span>, <span class="refAuthor">Kent, C.</span>, <span class="refAuthor">Partridge, C.</span>, and <span class="refAuthor">K. McCloghrie</span>, <span class="refTitle">"IP MTU discovery options"</span>, <span class="seriesInfo">RFC 1063</span>, <span class="seriesInfo">DOI 10.17487/RFC1063</span>, <time datetime="1988-07" class="refDate">July 1988</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1063">https://www.rfc-editor.org/info/rfc1063</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1191">[RFC1191]</dt>
        <dd>
<span class="refAuthor">Mogul, J.</span> and <span class="refAuthor">S. Deering</span>, <span class="refTitle">"Path MTU discovery"</span>, <span class="seriesInfo">RFC 1191</span>, <span class="seriesInfo">DOI 10.17487/RFC1191</span>, <time datetime="1990-11" class="refDate">November 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1191">https://www.rfc-editor.org/info/rfc1191</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2460">[RFC2460]</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">RFC 2460</span>, <span class="seriesInfo">DOI 10.17487/RFC2460</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2460">https://www.rfc-editor.org/info/rfc2460</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4301">[RFC4301]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span> and <span class="refAuthor">K. Seo</span>, <span class="refTitle">"Security Architecture for the Internet Protocol"</span>, <span class="seriesInfo">RFC 4301</span>, <span class="seriesInfo">DOI 10.17487/RFC4301</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4301">https://www.rfc-editor.org/info/rfc4301</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="RFC4443">[RFC4443]</dt>
        <dd>
<span class="refAuthor">Conta, A.</span>, <span class="refAuthor">Deering, S.</span>, and <span class="refAuthor">M. Gupta, Ed.</span>, <span class="refTitle">"Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 89</span>, <span class="seriesInfo">RFC 4443</span>, <span class="seriesInfo">DOI 10.17487/RFC4443</span>, <time datetime="2006-03" class="refDate">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4443">https://www.rfc-editor.org/info/rfc4443</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4821">[RFC4821]</dt>
        <dd>
<span class="refAuthor">Mathis, M.</span> and <span class="refAuthor">J. Heffner</span>, <span class="refTitle">"Packetization Layer Path MTU Discovery"</span>, <span class="seriesInfo">RFC 4821</span>, <span class="seriesInfo">DOI 10.17487/RFC4821</span>, <time datetime="2007-03" class="refDate">March 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4821">https://www.rfc-editor.org/info/rfc4821</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4861">[RFC4861]</dt>
        <dd>
<span class="refAuthor">Narten, T.</span>, <span class="refAuthor">Nordmark, E.</span>, <span class="refAuthor">Simpson, W.</span>, and <span class="refAuthor">H. Soliman</span>, <span class="refTitle">"Neighbor Discovery for IP version 6 (IPv6)"</span>, <span class="seriesInfo">RFC 4861</span>, <span class="seriesInfo">DOI 10.17487/RFC4861</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4861">https://www.rfc-editor.org/info/rfc4861</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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="RFC7637">[RFC7637]</dt>
        <dd>
<span class="refAuthor">Garg, P., Ed.</span> and <span class="refAuthor">Y. Wang, Ed.</span>, <span class="refTitle">"NVGRE: Network Virtualization Using Generic Routing Encapsulation"</span>, <span class="seriesInfo">RFC 7637</span>, <span class="seriesInfo">DOI 10.17487/RFC7637</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7637">https://www.rfc-editor.org/info/rfc7637</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="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="RFC8899">[RFC8899]</dt>
        <dd>
<span class="refAuthor">Fairhurst, G.</span>, <span class="refAuthor">Jones, T.</span>, <span class="refAuthor">Tüxen, M.</span>, <span class="refAuthor">Rüngeler, I.</span>, and <span class="refAuthor">T. Völker</span>, <span class="refTitle">"Packetization Layer Path MTU Discovery for Datagram Transports"</span>, <span class="seriesInfo">RFC 8899</span>, <span class="seriesInfo">DOI 10.17487/RFC8899</span>, <time datetime="2020-09" class="refDate">September 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8899">https://www.rfc-editor.org/info/rfc8899</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8900">[RFC8900]</dt>
        <dd>
<span class="refAuthor">Bonica, R.</span>, <span class="refAuthor">Baker, F.</span>, <span class="refAuthor">Huston, G.</span>, <span class="refAuthor">Hinden, R.</span>, <span class="refAuthor">Troan, O.</span>, and <span class="refAuthor">F. Gont</span>, <span class="refTitle">"IP Fragmentation Considered Fragile"</span>, <span class="seriesInfo">BCP 230</span>, <span class="seriesInfo">RFC 8900</span>, <span class="seriesInfo">DOI 10.17487/RFC8900</span>, <time datetime="2020-09" class="refDate">September 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8900">https://www.rfc-editor.org/info/rfc8900</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>
<dt id="RFC9099">[RFC9099]</dt>
        <dd>
<span class="refAuthor">Vyncke, É.</span>, <span class="refAuthor">Chittimaneni, K.</span>, <span class="refAuthor">Kaeo, M.</span>, and <span class="refAuthor">E. Rey</span>, <span class="refTitle">"Operational Security Considerations for IPv6 Networks"</span>, <span class="seriesInfo">RFC 9099</span>, <span class="seriesInfo">DOI 10.17487/RFC9099</span>, <time datetime="2021-08" class="refDate">August 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9099">https://www.rfc-editor.org/info/rfc9099</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-taps-arch">[TAPS-ARCH]</dt>
        <dd>
<span class="refAuthor">Pauly, T., Ed.</span>, <span class="refAuthor">Trammell, B., Ed.</span>, <span class="refAuthor">Brunstrom, A.</span>, <span class="refAuthor">Fairhurst, G.</span>, and <span class="refAuthor">C. Perkins</span>, <span class="refTitle">"An Architecture for Transport Services"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-taps-arch-12</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-taps-arch.xml">https://datatracker.ietf.org/doc/bibxml3/draft-ietf-taps-arch.xml</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="VPP">[VPP]</dt>
        <dd>
<span class="refAuthor">FD.io</span>, <span class="refTitle">"VPP/What is VPP?"</span>, <span>&lt;<a href="https://wiki.fd.io/view/VPP/What_is_VPP%3F">https://wiki.fd.io/view/VPP/What_is_VPP%3F</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="VPP_SRC">[VPP_SRC]</dt>
        <dd>
<span class="refTitle">"vpp"</span>, <span class="refContent">commit 21948, ip: HBH MTU recording for IPv6</span>, <span>&lt;<a href="https://gerrit.fd.io/r/c/vpp/+/21948">https://gerrit.fd.io/r/c/vpp/+/21948</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="WIRESHARK">[WIRESHARK]</dt>
      <dd>
<span class="refTitle">"Wireshark Network Protocol Analyzer"</span>, <span>&lt;<a href="https://www.wireshark.org">https://www.wireshark.org</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="appendix">
<section id="appendix-A">
      <h2 id="name-examples-of-usage">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-examples-of-usage" class="section-name selfRef">Examples of Usage</a>
      </h2>
<p id="appendix-A-1">This section provides examples that illustrate a use of the MinPMTU
      HBH Option by a source using DPLPMTUD to discover the PLPMTU supported
      by a path. They consider a path where the on-path router has been
      configured with an outgoing MTU of d'. The source starts by transmission
      of packets of size a and then uses DPLPMTUD to seek to increase the
      size in steps resulting in sizes of b, c, d, e, etc. (chosen by the search
      algorithm used by DPLPMTUD). The search algorithm terminates with a
      PLPMTU that is at least d and is less than or equal to d'.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">The first example considers DPLPMTUD without using the MinPMTU HBH
      Option. In this case, DPLPMTUD searches using a probe packet that increases in
      size. Probe packets of size e are sent, which are larger than
      the actual PMTU. In this example, PTB messages are not received from the
      routers, and repeated unsuccessful probes result in the search phase
      completing. Packets of data are never sent with a size larger than the
      size of the last confirmed probe packet. Acknowledgments (ACKs) of data packets
      are not shown.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<figure id="figure-3">
        <div class="alignCenter art-text artwork" id="appendix-A-3.1">
<pre>
----Packets of data size a ------------------------------&gt;
----Probe size b ----------------------------------------&gt;
 &lt;---------------------------------- ACK of probe --------
----Packets of data size b ------------------------------&gt;
----Probe size c ----------------------------------------&gt;
 &lt;---------------------------------- ACK of probe --------
----Packets of data size c ------------------------------&gt;
----Probe size d ----------------------------------------&gt;
 &lt;---------------------------------- ACK of probe --------
----Packets of data size d ------------------------------&gt;
 &lt;---------------------------------- ACK of probe --------
...
----Probe size e --------------X
        X----ICMPv6 PTB d' ----|
----Packets of data size d ------------------------------&gt;
----Probe size e --------------X (again)
        X----ICMPv6 PTB d' ----|
----Packets of data size d ------------------------------&gt;
...
etc. until MaxProbes are unsuccessful and search phase completes.
----Packets of data size d ------------------------------&gt;
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a></figcaption></figure>
<p id="appendix-A-4">The second example considers DPLPMTUD with the MinPMTU HBH Option set
      on a connectivity probe packet.<a href="#appendix-A-4" class="pilcrow">¶</a></p>
<p id="appendix-A-5">The IPv6 Option is sent end to end, and the Min-PMTU is updated by a
      router on the path to d', which is returned in a response that also sets
      the MinPMTU HBH Option. Upon receiving the Rtn-PMTU value,
      DPLPMTUD immediately sends a probe packet of the target size d'. If
      the probe packet is confirmed for the path, the PLPMTU is updated,
      allowing the source to use data packets up to size d'. (The search
      algorithm is allowed to continue to probe to see if the path supports a
      larger size.) 
      Packets of data are never sent with a size larger than the last
      confirmed probe size d'.<a href="#appendix-A-5" class="pilcrow">¶</a></p>
<figure id="figure-4">
        <div class="alignCenter art-text artwork" id="appendix-A-6.1">
<pre>
----Packets of data size a ------------------------------&gt;
----Connectivity probe with MinPMTU-
                            +--updated to minPMTU=d'-----&gt;
 &lt;-----------------ACK with Rtn-PMTU=d'--------------------
----Packets of data size a ------------------------------&gt;
----Probe size d' ---------------------------------------&gt;
 &lt;---------------------------------- ACK of probe ---------
-----Packets of data size d' ----------------------------&gt;
Search phase completes.
-----Packets of data size d' ----------------------------&gt;
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a></figcaption></figure>
<p id="appendix-A-7">The final example considers DPLPMTUD with the MinPMTU HBH Option set
      on a connectivity probe packet but shows the effect when this
      connectivity probe packet is dropped.<a href="#appendix-A-7" class="pilcrow">¶</a></p>
<p id="appendix-A-8">In this case, the packet with the MinPMTU HBH Option is not received.
      DPLPMTUD searches using probe packets of increasing size, increasing the
      PLPMTU when the probes are confirmed. An ICMPv6 PTB message is received
      when the probed size exceeds the actual PMTU, indicating a PTB_SIZE of
      d'. DPLPMTUD immediately sends a probe packet of the target size d'.
      If the probe packet is confirmed for the path, the PLPMTU is updated,
      allowing the source to use data packets up to size d'. If the ICMPv6 PTB
      message is not received, the DPLPMTU will be the last confirmed probe
      size, which is d.<a href="#appendix-A-8" class="pilcrow">¶</a></p>
<figure id="figure-5">
        <div class="Dropped HBH MinPMTU Option alignCenter art-DPLPMTUD art-text artwork with" id="appendix-A-9.1">
<pre>
----Packets of data size a -------------------------------&gt;
----Connectivity probe with MinPMTU --------X
----Packets of data size a -------------------------------&gt;
----Probe size b -----------------------------------------&gt;
 &lt;---------------------------------- ACK of probe --------
----Packets of data size b -------------------------------&gt;
----Probe size c -----------------------------------------&gt;
 &lt;---------------------------------- ACK of probe --------
----Packets of data size c -------------------------------&gt;
----Probe size d -----------------------------------------&gt;
 &lt;---------------------------------- ACK of probe --------
----Packets of data size d -------------------------------&gt;
----Probe size e ------------X
 &lt;--ICMPv6 PTB PTB_SIZE d' --|
----Packets of data size d -------------------------------&gt;
----Probe size d' using target set by PTB_SIZE -----------&gt;
 &lt;---------------------------------- ACK of probe --------
 Search phase completes.
----Packets of data size d' ------------------------------&gt;
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a></figcaption></figure>
<p id="appendix-A-10">The number of probe rounds depends on the number of steps needed by
      the search algorithm and is typically larger for a larger PMTU.<a href="#appendix-A-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Ack">
<section id="appendix-B">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-B-1">Helpful comments were received from <span class="contact-name">Tom Herbert</span>,
      <span class="contact-name">Tom Jones</span>, <span class="contact-name">Fred       Templin</span>, <span class="contact-name">Ole Troan</span>, <span class="contact-name">Tianran Zhou</span>,
      <span class="contact-name">Jen Linkova</span>, <span class="contact-name">Brian Carpenter</span>,
      <span class="contact-name">Peng Shuping</span>, <span class="contact-name">Mark Smith</span>,
      <span class="contact-name">Fernando Gont</span>, <span class="contact-name">Michael Dougherty</span>,
      <span class="contact-name">Erik Kline</span>, and
      other members of the 6MAN Working Group.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-C">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Robert M. Hinden</span></div>
<div dir="auto" class="left"><span class="org">Check Point Software</span></div>
<div dir="auto" class="left"><span class="street-address">959 Skyway Road</span></div>
<div dir="auto" class="left">
<span class="locality">San Carlos</span>, <span class="region">CA</span> <span class="postal-code">94070</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:bob.hinden@gmail.com" class="email">bob.hinden@gmail.com</a>
</div>
</address>
<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">School 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</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>
</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>