File: rfc8900.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 (2746 lines) | stat: -rw-r--r-- 147,784 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC BCP">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8900: IP Fragmentation Considered Fragile</title>
<meta content="Ron Bonica" name="author">
<meta content="Fred Baker" name="author">
<meta content="Geoff Huston" name="author">
<meta content="Robert M. Hinden" name="author">
<meta content="Ole Troan" name="author">
<meta content="Fernando Gont" name="author">
<meta content="
       This document describes IP fragmentation and explains how it
      introduces fragility to Internet communication. 
       This document also proposes alternatives to IP fragmentation and
      provides recommendations for developers and network operators. 
    " name="description">
<meta content="xml2rfc 3.0.0" name="generator">
<meta content="IPv6" name="keyword">
<meta content="Fragmentation" name="keyword">
<meta content="8900" name="rfc.number">
<link href="rfc8900.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8900" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile-17" 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 8900</td>
<td class="center">IP Fragmentation Fragile</td>
<td class="right">September 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Bonica, et al.</td>
<td class="center">Best Current Practice</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/rfc8900" class="eref">8900</a></dd>
<dt class="label-bcp">BCP:</dt>
<dd class="bcp">230</dd>
<dt class="label-category">Category:</dt>
<dd class="category">Best Current Practice</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-09" class="published">September 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">R. Bonica</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">F. Baker</div>
<div class="org">Unaffiliated</div>
</div>
<div class="author">
      <div class="author-name">G. Huston</div>
<div class="org">APNIC</div>
</div>
<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">O. Troan</div>
<div class="org">Cisco</div>
</div>
<div class="author">
      <div class="author-name">F. Gont</div>
<div class="org">SI6 Networks</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8900</h1>
<h1 id="title">IP Fragmentation Considered Fragile</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes IP fragmentation and explains how it
      introduces fragility to Internet communication.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document also proposes alternatives to IP fragmentation and
      provides recommendations for developers and network operators.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This memo documents an Internet Best Current Practice.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further information
            on BCPs is available in Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8900">https://www.rfc-editor.org/info/rfc8900</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-ip-fragmentation" class="xref">IP Fragmentation</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-links-paths-mtu-and-pmtu" class="xref">Links, Paths, MTU, and PMTU</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-fragmentation-procedures" class="xref">Fragmentation Procedures</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-upper-layer-reliance-on-ip-" class="xref">Upper-Layer Reliance on IP Fragmentation</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-increased-fragility" class="xref">Increased Fragility</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-virtual-reassembly" class="xref">Virtual Reassembly</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-policy-based-routing" class="xref">Policy-Based Routing</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-network-address-translation" class="xref">Network Address Translation (NAT)</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-stateless-firewalls" class="xref">Stateless Firewalls</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-equal-cost-multipath-link-a" class="xref">Equal-Cost Multipath, Link Aggregate Groups, and Stateless Load Balancers</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-ipv4-reassembly-errors-at-h" class="xref">IPv4 Reassembly Errors at High Data Rates</a><a href="#section-toc.1-1.3.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.7">
                <p id="section-toc.1-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>.  <a href="#name-security-vulnerabilities" class="xref">Security Vulnerabilities</a><a href="#section-toc.1-1.3.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.8">
                <p id="section-toc.1-1.3.2.8.1"><a href="#section-3.8" class="xref">3.8</a>.  <a href="#name-pmtu-black-holing-due-to-ic" class="xref">PMTU Black-Holing Due to ICMP Loss</a><a href="#section-toc.1-1.3.2.8.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.8.2.1">
                    <p id="section-toc.1-1.3.2.8.2.1.1"><a href="#section-3.8.1" class="xref">3.8.1</a>.  <a href="#name-transient-loss" class="xref">Transient Loss</a><a href="#section-toc.1-1.3.2.8.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.8.2.2">
                    <p id="section-toc.1-1.3.2.8.2.2.1"><a href="#section-3.8.2" class="xref">3.8.2</a>.  <a href="#name-incorrect-implementation-of" class="xref">Incorrect Implementation of Security Policy</a><a href="#section-toc.1-1.3.2.8.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.8.2.3">
                    <p id="section-toc.1-1.3.2.8.2.3.1"><a href="#section-3.8.3" class="xref">3.8.3</a>.  <a href="#name-persistent-loss-caused-by-a" class="xref">Persistent Loss Caused by Anycast</a><a href="#section-toc.1-1.3.2.8.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.8.2.4">
                    <p id="section-toc.1-1.3.2.8.2.4.1"><a href="#section-3.8.4" class="xref">3.8.4</a>.  <a href="#name-persistent-loss-caused-by-u" class="xref">Persistent Loss Caused by Unidirectional Routing</a><a href="#section-toc.1-1.3.2.8.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.9">
                <p id="section-toc.1-1.3.2.9.1"><a href="#section-3.9" class="xref">3.9</a>.  <a href="#name-black-holing-due-to-filteri" class="xref">Black-Holing Due to Filtering or Loss</a><a href="#section-toc.1-1.3.2.9.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-alternatives-to-ip-fragment" class="xref">Alternatives to IP Fragmentation</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-transport-layer-solutions" class="xref">Transport-Layer Solutions</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-application-layer-solutions" class="xref">Application-Layer Solutions</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-applications-that-rely-on-i" class="xref">Applications That Rely on IPv6 Fragmentation</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-domain-name-service-dns" class="xref">Domain Name Service (DNS)</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-open-shortest-path-first-os" class="xref">Open Shortest Path First (OSPF)</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-packet-in-packet-encapsulat" class="xref">Packet-in-Packet Encapsulations</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-udp-applications-enhancing-" class="xref">UDP Applications Enhancing Performance</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-recommendations" class="xref">Recommendations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-for-application-and-protoco" class="xref">For Application and Protocol Developers</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-for-system-developers" class="xref">For System Developers</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact 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-for-middlebox-developers" class="xref">For Middlebox Developers</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-for-ecmp-lag-and-load-balan" class="xref">For ECMP, LAG, and Load-Balancer Developers And Operators</a><a href="#section-toc.1-1.6.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-for-network-operators" class="xref">For Network Operators</a><a href="#section-toc.1-1.6.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact 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-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Operational experience <span>[<a href="#Kent" class="xref">Kent</a>]</span>
        <span>[<a href="#Huston" class="xref">Huston</a>]</span> <span>[<a href="#RFC7872" class="xref">RFC7872</a>]</span> 
      reveals that IP fragmentation
      introduces fragility to Internet communication. This document describes
      IP fragmentation and explains the fragility it introduces. It also
      proposes alternatives to IP fragmentation and provides recommendations
      for developers and network operators.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">While this document identifies issues associated with IP
      fragmentation, it does not recommend deprecation. Legacy protocols that
      depend upon IP fragmentation would do well to be updated to remove that dependency.
      However, some applications and environments (see <a href="#rely" class="xref">Section 5</a>)
      require IP fragmentation.  In these cases, the protocol will continue 
      to rely on IP fragmentation, but the designer should be aware that 
      fragmented packets may result in black holes.  A design should include 
      appropriate safeguards.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Rather than deprecating IP fragmentation, this document recommends
      that upper-layer protocols address the problem of fragmentation at their
      layer, reducing their reliance on IP fragmentation to the greatest
      degree possible.<a href="#section-1-3" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-requirements-language">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-1.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>",
    "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be
    interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals, as
    shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-2">
      <h2 id="name-ip-fragmentation">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-ip-fragmentation" class="section-name selfRef">IP Fragmentation</a>
      </h2>
<div id="pmtu">
<section id="section-2.1">
        <h3 id="name-links-paths-mtu-and-pmtu">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-links-paths-mtu-and-pmtu" class="section-name selfRef">Links, Paths, MTU, and PMTU</a>
        </h3>
<p id="section-2.1-1">An Internet path connects a source node to a destination node. A
        path may contain links and routers. If a path contains more than one
        link, the links are connected in series, and a router connects each
        link to the next.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">Internet paths are dynamic. Assume that the path from one node
        to another contains a set of links and routers. If a link or a
        router fails, the path can also change so that it includes a
        different set of links and routers.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">
    Each link is constrained by the number of octets that it can convey in
    a single IP packet.  This constraint is called the link Maximum
    Transmission Unit (MTU). <span><a href="#RFC0791" class="xref">IPv4</a> [<a href="#RFC0791" class="xref">RFC0791</a>]</span> 
    requires every link to support an MTU of 68 octets or greater (see <a href="#note-1" class="xref">NOTE 1</a>). 
    <span><a href="#RFC8200" class="xref">IPv6</a> [<a href="#RFC8200" class="xref">RFC8200</a>]</span> similarly requires every link to 
    support an MTU of 1280 octets or greater. These are called the IPv4 and IPv6 minimum link MTUs.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1-4">Some links, and some ways of using links, result in
 additional variable overhead. For the simple case of tunnels,
 this document defers to other documents.  For other cases,
 such as MPLS, this document considers the link MTU to include
 appropriate allowance for any such overhead.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<p id="section-2.1-5">Likewise, each Internet path is constrained by the number of octets
        that it can convey in a single IP packet. This constraint is called
        the Path MTU (PMTU). For any given path, the PMTU is equal to the
        smallest of its link MTUs. Because Internet paths are dynamic, PMTU
        is also dynamic.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
<p id="section-2.1-6">For reasons described below, source nodes estimate the PMTU between
        themselves and destination nodes. A source node can produce extremely
        conservative PMTU estimates in which:<a href="#section-2.1-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.1-7.1">The estimate for each IPv4 path is equal to the IPv4 minimum
            link MTU.<a href="#section-2.1-7.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-7.2">The estimate for each IPv6 path is equal to the IPv6 minimum
            link MTU.<a href="#section-2.1-7.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.1-8">While these conservative estimates are guaranteed to be less
        than or equal to the actual PMTU, they are likely to be much less than
        the actual PMTU. This may adversely affect upper-layer protocol
        performance.<a href="#section-2.1-8" class="pilcrow">¶</a></p>
<p id="section-2.1-9">By executing Path MTU Discovery (PMTUD) procedures <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span>
          <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span>, a source node can
        maintain a less conservative estimate of the PMTU between itself and a
        destination node. In PMTUD, the source node produces an initial PMTU
        estimate. This initial estimate is equal to the MTU of the first link
        along the path to the destination node. It can be greater than the
        actual PMTU.<a href="#section-2.1-9" class="pilcrow">¶</a></p>
<p id="section-2.1-10">Having produced an initial PMTU estimate, the source node sends
        non-fragmentable IP packets to the destination node (see <a href="#note-2" class="xref">NOTE 2</a>). If
        one of these packets is larger than the actual PMTU, a downstream
        router will not be able to forward the packet through the next link
        along the path. Therefore, the downstream router drops the packet and
        sends an Internet Control Message Protocol (ICMP)
        <span>[<a href="#RFC0792" class="xref">RFC0792</a>]</span> <span>[<a href="#RFC4443" class="xref">RFC4443</a>]</span> Packet Too Big (PTB) message to
        the source node (see <a href="#note-3" class="xref">NOTE 3</a>). The ICMP PTB message indicates the MTU
        of the link through which the packet could not be forwarded. The
        source node uses this information to refine its PMTU estimate.<a href="#section-2.1-10" class="pilcrow">¶</a></p>
<p id="section-2.1-11">PMTUD produces a running estimate of the PMTU between a source node
        and a destination node. Because PMTU is dynamic, the PMTU estimate can
        be larger than the actual PMTU. In order to detect PMTU increases,
        PMTUD occasionally resets the PMTU estimate to its initial value and
        repeats the procedure described above.<a href="#section-2.1-11" class="pilcrow">¶</a></p>
<p id="section-2.1-12">Ideally, PMTUD operates as described above. However, in some
        scenarios, PMTUD fails. For example:<a href="#section-2.1-12" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.1-13.1">PMTUD relies on the network's ability to deliver ICMP PTB
            messages to the source node. If the network cannot deliver ICMP
            PTB messages to the source node, PMTUD fails.<a href="#section-2.1-13.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-13.2">PMTUD is susceptible to attack because ICMP messages are easily
            <span><a href="#RFC5927" class="xref">forged</a> [<a href="#RFC5927" class="xref">RFC5927</a>]</span> and not authenticated by the
            receiver. Such attacks can cause PMTUD to produce unnecessarily
            conservative PMTU estimates.<a href="#section-2.1-13.2" class="pilcrow">¶</a>
</li>
        </ul>
<span class="break"></span><dl class="dlParallel" id="section-2.1-14">
          <dt id="section-2.1-14.1">
<div id="note-1">NOTE 1:</div>
          </dt>
<dd style="margin-left: 1.5em" id="section-2.1-14.2">In IPv4, every host must be able to reassemble a packet 
        whose length is less than or equal to 576 octets. However, the IPv4 minimum 
        link MTU is not 576. Section <a href="https://www.rfc-editor.org/rfc/rfc791#section-3.2" class="relref">3.2</a>
        of <span><a href="#RFC0791" class="xref">RFC 791</a> [<a href="#RFC0791" class="xref">RFC0791</a>]</span> explicitly states 
        that the IPv4 minimum link MTU is 68 octets.<a href="#section-2.1-14.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-14.3">
<div id="note-2">NOTE 2:</div>
          </dt>
<dd style="margin-left: 1.5em" id="section-2.1-14.4">A non-fragmentable packet can be fragmented at its source.
        However, it cannot be fragmented by a downstream node. An IPv4 packet
        whose Don't Fragment (DF) bit is set to 0 is fragmentable. An IPv4 packet whose
        DF bit is set to 1 is non-fragmentable. All IPv6 packets are also
        non-fragmentable.<a href="#section-2.1-14.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-14.5">
<div id="note-3">NOTE 3:</div>
          </dt>
<dd style="margin-left: 1.5em" id="section-2.1-14.6">The ICMP PTB message has two instantiations. In <span><a href="#RFC0792" class="xref">ICMPv4</a> [<a href="#RFC0792" class="xref">RFC0792</a>]</span>, the ICMP PTB message is a Destination
        Unreachable message with Code equal to 4 (fragmentation needed and DF 
        set). This message was augmented by <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> to
        indicate the MTU of the link through which the packet could not be
        forwarded. In <span><a href="#RFC4443" class="xref">ICMPv6</a> [<a href="#RFC4443" class="xref">RFC4443</a>]</span>, the ICMP PTB
        message is a Packet Too Big Message with Code equal to 0. This
        message also indicates the MTU of the link through which the packet
        could not be forwarded.<a href="#section-2.1-14.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<section id="section-2.2">
        <h3 id="name-fragmentation-procedures">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-fragmentation-procedures" class="section-name selfRef">Fragmentation Procedures</a>
        </h3>
<p id="section-2.2-1">When an upper-layer protocol submits data to the underlying IP
        module, and the resulting IP packet's length is greater than the PMTU,
        the packet is divided into fragments. Each fragment includes an IP
        header and a portion of the original packet.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2"><span>[<a href="#RFC0791" class="xref">RFC0791</a>]</span> describes IPv4 fragmentation procedures.
        An IPv4 packet whose DF bit is set to 1 may be fragmented by the
        source node, but may not be fragmented by a downstream router. An IPv4
        packet whose DF bit is set to 0 may be fragmented by the source
        node or by a downstream router. When an IPv4 packet is fragmented, all
        IP options (which are within the IPv4 header) appear in the first fragment, but only options whose "copy"
        bit is set to 1 appear in subsequent fragments.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3"><span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>, notably in 
        Section <a href="https://www.rfc-editor.org/rfc/rfc8200#section-4.5" class="relref">4.5</a>, describes
 IPv6 fragmentation procedures.  An IPv6 packet may be
 fragmented only at the source node. When an IPv6 packet is
 fragmented, all extension headers appear in the first
 fragment, but only per-fragment headers appear in subsequent
 fragments. Per-fragment headers include the following:<a href="#section-2.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.2-4.1">The IPv6 header.<a href="#section-2.2-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-4.2">The Hop-by-Hop Options header (if present).<a href="#section-2.2-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-4.3">The Destination Options header (if present and if it precedes a
            Routing header).<a href="#section-2.2-4.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-4.4">The Routing header (if present).<a href="#section-2.2-4.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-4.5">The Fragment header.<a href="#section-2.2-4.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.2-5">In IPv4, the upper-layer header usually appears in the 
        first fragment, due to the sizes of the headers involved. 
        In IPv6, the upper-layer header must appear in the first fragment.<a href="#section-2.2-5" class="pilcrow">¶</a></p>
</section>
<div id="upper">
<section id="section-2.3">
        <h3 id="name-upper-layer-reliance-on-ip-">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-upper-layer-reliance-on-ip-" class="section-name selfRef">Upper-Layer Reliance on IP Fragmentation</a>
        </h3>
<p id="section-2.3-1">Upper-layer protocols can operate in the following modes:<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3-2.1">Do not rely on IP fragmentation.<a href="#section-2.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.3-2.2">Rely on IP fragmentation by the source node only.<a href="#section-2.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.3-2.3">Rely on IP fragmentation by any node.<a href="#section-2.3-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.3-3">Upper-layer protocols running over IPv4 can operate in all of the
        above-mentioned modes. Upper-layer protocols running over IPv6 can
        operate in the first and second modes only.<a href="#section-2.3-3" class="pilcrow">¶</a></p>
<p id="section-2.3-4">Upper-layer protocols that operate in the first two modes (above)
        require access to the PMTU estimate. In order to fulfill this
        requirement, they can:<a href="#section-2.3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3-5.1">Estimate the PMTU to be equal to the IPv4 or IPv6 minimum link
            MTU.<a href="#section-2.3-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.3-5.2">Access the estimate that PMTUD produced.<a href="#section-2.3-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.3-5.3">Execute PMTUD procedures themselves.<a href="#section-2.3-5.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.3-5.4">Execute Packetization Layer PMTUD (PLPMTUD) procedures
            <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>
            <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span>.<a href="#section-2.3-5.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.3-6">According to PLPMTUD procedures, the upper-layer protocol
        maintains a running PMTU estimate. It does so by sending probe packets
        of various sizes to its upper-layer peer and receiving
        acknowledgements. This strategy differs from PMTUD in that it relies
        on acknowledgement of received messages, as opposed to ICMP PTB
        messages concerning dropped messages. Therefore, PLPMTUD does not rely
        on the network's ability to deliver ICMP PTB messages to the
        source.<a href="#section-2.3-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-3">
      <h2 id="name-increased-fragility">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-increased-fragility" class="section-name selfRef">Increased Fragility</a>
      </h2>
<p id="section-3-1">This section explains how IP fragmentation introduces fragility to
      Internet communication.<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="virtualreassembly">
<section id="section-3.1">
        <h3 id="name-virtual-reassembly">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-virtual-reassembly" class="section-name selfRef">Virtual Reassembly</a>
        </h3>
<p id="section-3.1-1">Virtual reassembly is a procedure in which a device
 conceptually reassembles a packet, forwards its fragments, and discards
 the reassembled copy. In <span><a href="#RFC6346" class="xref">Address plus Port (A+P)</a> [<a href="#RFC6346" class="xref">RFC6346</a>]</span> 
        and <span><a href="#RFC6888" class="xref">Carrier Grade NAT (CGN)</a> [<a href="#RFC6888" class="xref">RFC6888</a>]</span>, virtual reassembly
 is required in order to correctly translate fragment
 addresses.  It could be useful to address the problems in Sections
 <a href="#mb" class="xref">3.2</a>, <a href="#nat" class="xref">3.3</a>, 
        <a href="#statelessfirewall" class="xref">3.4</a>, and <a href="#ecmp" class="xref">3.5</a>.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">Virtual reassembly is computationally expensive and holds 
        state for indeterminate periods of time. Therefore, it is prone 
        to errors and <span><a href="#at" class="xref">attacks</a> (<a href="#at" class="xref">Section 3.7</a>)</span>.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="mb">
<section id="section-3.2">
        <h3 id="name-policy-based-routing">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-policy-based-routing" class="section-name selfRef">Policy-Based Routing</a>
        </h3>
<p id="section-3.2-1">IP fragmentation causes problems for routers that implement
        policy-based routing.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">When a router receives a packet, it identifies the next hop on
        route to the packet's destination and forwards the packet to that
        next hop. In order to identify the next hop, the router interrogates a
        local data structure called the Forwarding Information Base (FIB).<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">Normally, the FIB contains destination-based entries that map a
        destination prefix to a next hop. Policy-based routing allows
        destination-based and policy-based entries to coexist in the same FIB.
        A policy-based FIB entry maps multiple fields, drawn from either the
        IP or transport-layer header, to a next hop.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4"></p>
<span id="name-policy-based-routing-fib"></span><div id="FIB">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-policy-based-routing-fib" class="selfRef">Policy-Based Routing FIB</a>
          </caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1">Entry</th>
              <th class="text-left" rowspan="1" colspan="1">Type</th>
              <th class="text-left" rowspan="1" colspan="1">Dest. Prefix</th>
              <th class="text-left" rowspan="1" colspan="1">Next Hdr / Dest. Port</th>
              <th class="text-left" rowspan="1" colspan="1">Next Hop</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">Destination-based</td>
              <td class="text-left" rowspan="1" colspan="1">2001:db8::1/128</td>
              <td class="text-left" rowspan="1" colspan="1">Any / Any</td>
              <td class="text-left" rowspan="1" colspan="1">2001:db8:2::2</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Policy-based</td>
              <td class="text-left" rowspan="1" colspan="1">2001:db8::1/128</td>
              <td class="text-left" rowspan="1" colspan="1">TCP / 80</td>
              <td class="text-left" rowspan="1" colspan="1">2001:db8:3::3</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.2-6">Assume that a router maintains the FIB in <a href="#FIB" class="xref">Table 1</a>. The
        first FIB entry is destination-based. It maps a destination prefix
        2001:db8::1/128 to a next hop 2001:db8:2::2. The second FIB entry is
        policy-based. It maps the same destination prefix 2001:db8::1/128
        and a destination port (TCP / 80) to a different next hop
        (2001:db8:3::3). The second entry is more specific than the first.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.2-7">When the router receives the first fragment of a packet that is
        destined for TCP port 80 on 2001:db8::1, it interrogates the FIB. Both
        FIB entries satisfy the query. The router selects the second FIB entry
        because it is more specific and forwards the packet to
        2001:db8:3::3.<a href="#section-3.2-7" class="pilcrow">¶</a></p>
<p id="section-3.2-8">When the router receives the second fragment of the packet, it
        interrogates the FIB again. This time, only the first FIB entry
        satisfies the query, because the second fragment contains no
        indication that the packet is destined for TCP port 80. Therefore, the
        router selects the first FIB entry and forwards the packet to
        2001:db8:2::2.<a href="#section-3.2-8" class="pilcrow">¶</a></p>
<p id="section-3.2-9">Policy-based routing is also known as filter-based forwarding.<a href="#section-3.2-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nat">
<section id="section-3.3">
        <h3 id="name-network-address-translation">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-network-address-translation" class="section-name selfRef">Network Address Translation (NAT)</a>
        </h3>
<p id="section-3.3-1">IP fragmentation causes problems for Network Address Translation
        (NAT) devices. When a NAT device detects a new, outbound flow, it maps
        that flow's source port and IP address to another source port and IP
        address. Having created that mapping, the NAT device translates:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.3-2.1">The source IP address and source port on each outbound
            packet.<a href="#section-3.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-2.2">The destination IP address and destination port on each inbound
            packet.<a href="#section-3.3-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.3-3"></p>
<p id="section-3.3-4"><span><a href="#RFC6346" class="xref">A+P</a> [<a href="#RFC6346" class="xref">RFC6346</a>]</span> and 
        <span><a href="#RFC6888" class="xref">Carrier Grade NAT (CGN)</a> [<a href="#RFC6888" class="xref">RFC6888</a>]</span> 
        are two common NAT strategies. In both approaches, the NAT device must virtually
        reassemble fragmented packets in order to translate and forward each
        fragment.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="statelessfirewall">
<section id="section-3.4">
        <h3 id="name-stateless-firewalls">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-stateless-firewalls" class="section-name selfRef">Stateless Firewalls</a>
        </h3>
<p id="section-3.4-1">As discussed in more detail in <a href="#at" class="xref">Section 3.7</a>, IP
        fragmentation causes problems for stateless firewalls whose rules
        include TCP and UDP ports. Because port information is only
 available in the first fragment and not available
        in the subsequent fragments, the firewall is limited to the following
        options:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.4-2.1">Accept all subsequent fragments, possibly admitting certain
            classes of attack.<a href="#section-3.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.4-2.2">Block all subsequent fragments, possibly blocking legitimate
            traffic.<a href="#section-3.4-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.4-3">Neither option is attractive.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ecmp">
<section id="section-3.5">
        <h3 id="name-equal-cost-multipath-link-a">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-equal-cost-multipath-link-a" class="section-name selfRef">Equal-Cost Multipath, Link Aggregate Groups, and Stateless Load Balancers</a>
        </h3>
<p id="section-3.5-1">IP fragmentation causes problems for Equal-Cost Multipath (ECMP),
        Link Aggregate Groups (LAG), and other stateless load-distribution
        technologies. In order to assign a packet or packet fragment to a
        link, an intermediate node executes a hash (i.e., load-distributing)
        algorithm. The following paragraphs describe a commonly deployed hash
        algorithm.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">If the packet or packet fragment contains a transport-layer header,
        the algorithm accepts the following 5-tuple as input:<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5-3.1">IP Source Address.<a href="#section-3.5-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-3.2">IP Destination Address.<a href="#section-3.5-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-3.3">IPv4 Protocol or IPv6 Next Header.<a href="#section-3.5-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-3.4">transport-layer source port.<a href="#section-3.5-3.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-3.5">transport-layer destination port.<a href="#section-3.5-3.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.5-4">If the packet or packet fragment does not contain a
        transport-layer header, the algorithm accepts only the following
        3-tuple as input:<a href="#section-3.5-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5-5.1">IP Source Address.<a href="#section-3.5-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-5.2">IP Destination Address.<a href="#section-3.5-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-5.3">IPv4 Protocol or IPv6 Next Header.<a href="#section-3.5-5.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.5-6">Therefore, non-fragmented packets belonging to a flow can be
        assigned to one link while fragmented packets belonging to the same
        flow can be divided between that link and another. This can cause
        suboptimal load distribution.<a href="#section-3.5-6" class="pilcrow">¶</a></p>
<p id="section-3.5-7"><span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span> offers a partial solution to this problem
        for IPv6 devices only. According to <span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span>:<a href="#section-3.5-7" class="pilcrow">¶</a></p>
<blockquote id="section-3.5-8">At intermediate routers that perform load distribution, the hash
        algorithm used to determine the outgoing component-link in an ECMP
        and/or LAG toward the next hop <span class="bcp14">MUST</span> minimally include the 3-tuple
        {dest addr, source addr, flow label} and <span class="bcp14">MAY</span> also include the
        remaining components of the 5-tuple.<a href="#section-3.5-8" class="pilcrow">¶</a>
</blockquote>
<p id="section-3.5-9">If the algorithm includes only the 3-tuple {dest addr, source addr,
        flow label}, it will assign all fragments belonging to a packet to the
        same link. (See <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span> and <span>[<a href="#RFC7098" class="xref">RFC7098</a>]</span>).<a href="#section-3.5-9" class="pilcrow">¶</a></p>
<p id="section-3.5-10">In order to avoid the problem described above, implementations
        <span class="bcp14">SHOULD</span> implement the recommendations provided in <a href="#lagrec" class="xref">Section 6.4</a> of this document.<a href="#section-3.5-10" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.6">
        <h3 id="name-ipv4-reassembly-errors-at-h">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-ipv4-reassembly-errors-at-h" class="section-name selfRef">IPv4 Reassembly Errors at High Data Rates</a>
        </h3>
<p id="section-3.6-1">IPv4 fragmentation is not sufficiently robust for use under some
        conditions in today's Internet. At high data rates, the 16-bit IP
        identification field is not large enough to prevent duplicate IDs, resulting in frequent
        incorrectly assembled IP fragments, and the TCP and UDP checksums are
        insufficient to prevent the resulting corrupted datagrams from being
        delivered to upper-layer protocols. <span>[<a href="#RFC4963" class="xref">RFC4963</a>]</span>
        describes some easily reproduced experiments demonstrating the
        problem and discusses some of the operational implications of these
        observations.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<p id="section-3.6-2">These reassembly issues do not occur as frequently in IPv6 because
        the IPv6 identification field is 32 bits long.<a href="#section-3.6-2" class="pilcrow">¶</a></p>
</section>
<div id="at">
<section id="section-3.7">
        <h3 id="name-security-vulnerabilities">
<a href="#section-3.7" class="section-number selfRef">3.7. </a><a href="#name-security-vulnerabilities" class="section-name selfRef">Security Vulnerabilities</a>
        </h3>
<p id="section-3.7-1">Security researchers have documented several attacks that exploit
        IP fragmentation. The following are examples:<a href="#section-3.7-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.7-2.1">Overlapping fragment attacks <span>[<a href="#RFC1858" class="xref">RFC1858</a>]</span>
            <span>[<a href="#RFC3128" class="xref">RFC3128</a>]</span> <span>[<a href="#RFC5722" class="xref">RFC5722</a>]</span>.<a href="#section-3.7-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.7-2.2">Resource exhaustion attacks.<a href="#section-3.7-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.7-2.3">Attacks based on predictable fragment identification values
            <span>[<a href="#RFC7739" class="xref">RFC7739</a>]</span>.<a href="#section-3.7-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.7-2.4">Evasion of Network Intrusion Detection Systems (NIDS) <span>[<a href="#Ptacek1998" class="xref">Ptacek1998</a>]</span>.<a href="#section-3.7-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.7-3">In the overlapping fragment attack, an attacker constructs a series
        of packet fragments. The first fragment contains an IP header, a
        transport-layer header, and some transport-layer payload. This
        fragment complies with local security policy and is allowed to pass
        through a stateless firewall. A second fragment, having a nonzero
        offset, overlaps with the first fragment. The second fragment also
        passes through the stateless firewall. When the packet is reassembled,
        the transport-layer header from the first fragment is overwritten by
        data from the second fragment. The reassembled packet does not comply
        with local security policy. Had it traversed the firewall in one
        piece, the firewall would have rejected it.<a href="#section-3.7-3" class="pilcrow">¶</a></p>
<p id="section-3.7-4">A stateless firewall cannot protect against the overlapping
        fragment attack. However, destination nodes can protect against the
        overlapping fragment attack by implementing the procedures described
        in RFC 1858, RFC 3128, and RFC 8200. These reassembly procedures detect
        the overlap and discard the packet.<a href="#section-3.7-4" class="pilcrow">¶</a></p>
<p id="section-3.7-5">The fragment reassembly algorithm is a stateful procedure in an
        otherwise stateless protocol. Therefore, it can be exploited by
        resource exhaustion attacks. An attacker can construct a series of
        fragmented packets with one fragment missing from each packet so that
        the reassembly is impossible. Thus, this attack causes resource
        exhaustion on the destination node, possibly denying reassembly
        services to other flows. This type of attack can be mitigated by
        flushing fragment reassembly buffers when necessary, at the expense of
        possibly dropping legitimate fragments.<a href="#section-3.7-5" class="pilcrow">¶</a></p>
<p id="section-3.7-6">Each IP fragment contains an "Identification" field that
        destination nodes use to reassemble fragmented packets. Some
        implementations set the Identification field to a predictable value,
        thus making it easy for an attacker to forge malicious IP fragments
        that would cause the reassembly procedure for legitimate packets to
        fail.<a href="#section-3.7-6" class="pilcrow">¶</a></p>
<p id="section-3.7-7">NIDS aims at identifying malicious activity by analyzing network
        traffic. Ambiguity in the possible result of the fragment reassembly
        process may allow an attacker to evade these systems. Many of these
        systems try to mitigate some of these evasion techniques (e.g., by
        computing all possible outcomes of the fragment reassembly process, at
        the expense of increased processing requirements).<a href="#section-3.7-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="PTB">
<section id="section-3.8">
        <h3 id="name-pmtu-black-holing-due-to-ic">
<a href="#section-3.8" class="section-number selfRef">3.8. </a><a href="#name-pmtu-black-holing-due-to-ic" class="section-name selfRef">PMTU Black-Holing Due to ICMP Loss</a>
        </h3>
<p id="section-3.8-1">As mentioned in <a href="#upper" class="xref">Section 2.3</a>, upper-layer protocols can
        be configured to rely on PMTUD. Because PMTUD relies upon the network
        to deliver ICMP PTB messages, those protocols also rely on the
        networks to deliver ICMP PTB messages.<a href="#section-3.8-1" class="pilcrow">¶</a></p>
<p id="section-3.8-2">According to <span>[<a href="#RFC4890" class="xref">RFC4890</a>]</span>, ICMPv6 PTB messages must not
        be filtered. However, ICMP PTB delivery is not reliable. It is subject
        to both transient and persistent loss.<a href="#section-3.8-2" class="pilcrow">¶</a></p>
<p id="section-3.8-3">Transient loss of ICMP PTB messages can cause transient PMTU black
        holes. When the conditions contributing to transient loss abate, the
        network regains its ability to deliver ICMP PTB messages and
        connectivity between the source and destination nodes is restored.
        <a href="#transLoss" class="xref">Section 3.8.1</a> of this document describes conditions that
        lead to transient loss of ICMP PTB messages.<a href="#section-3.8-3" class="pilcrow">¶</a></p>
<p id="section-3.8-4">Persistent loss of ICMP PTB messages can cause persistent black
        holes. Sections <a href="#CPE" class="xref">3.8.2</a>, <a href="#Anycast" class="xref">3.8.3</a>, 
        and <a href="#unidirectional" class="xref">3.8.4</a> of this document describe conditions that
        lead to persistent loss of ICMP PTB messages.<a href="#section-3.8-4" class="pilcrow">¶</a></p>
<p id="section-3.8-5">The problem described in this section is specific to PMTUD. It does
        not occur when the upper-layer protocol obtains its PMTU estimate from
        PLPMTUD or from any other source.<a href="#section-3.8-5" class="pilcrow">¶</a></p>
<div id="transLoss">
<section id="section-3.8.1">
          <h4 id="name-transient-loss">
<a href="#section-3.8.1" class="section-number selfRef">3.8.1. </a><a href="#name-transient-loss" class="section-name selfRef">Transient Loss</a>
          </h4>
<p id="section-3.8.1-1">The following factors can contribute to transient loss of ICMP
          PTB messages:<a href="#section-3.8.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.8.1-2.1">Network congestion.<a href="#section-3.8.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.1-2.2">Packet corruption.<a href="#section-3.8.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.1-2.3">Transient routing loops.<a href="#section-3.8.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.1-2.4">ICMP rate limiting.<a href="#section-3.8.1-2.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.8.1-3">The effect of rate limiting may be severe, as RFC 4443 recommends
          strict rate limiting of ICMPv6 traffic.<a href="#section-3.8.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="CPE">
<section id="section-3.8.2">
          <h4 id="name-incorrect-implementation-of">
<a href="#section-3.8.2" class="section-number selfRef">3.8.2. </a><a href="#name-incorrect-implementation-of" class="section-name selfRef">Incorrect Implementation of Security Policy</a>
          </h4>
<p id="section-3.8.2-1">Incorrect implementation of security policy can cause persistent
          loss of ICMP PTB messages.<a href="#section-3.8.2-1" class="pilcrow">¶</a></p>
<p id="section-3.8.2-2">For example, assume that a Customer Premises Equipment (CPE) router implements
          the following zone-based security policy:<a href="#section-3.8.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.8.2-3.1">Allow any traffic to flow from the inside zone to the outside
              zone.<a href="#section-3.8.2-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.2-3.2">Do not allow any traffic to flow from the outside zone to the
              inside zone unless it is part of an existing flow (i.e., it was
              elicited by an outbound packet).<a href="#section-3.8.2-3.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.8.2-4">When a correct implementation of the above-mentioned
          security policy receives an ICMP PTB message, it examines the ICMP
          PTB payload in order to determine whether the original packet (i.e.,
          the packet that elicited the ICMP PTB message) belonged to an
          existing flow. If the original packet belonged to an existing flow,
          the implementation allows the ICMP PTB to flow from the outside zone
          to the inside zone. If not, the implementation discards the ICMP PTB
          message.<a href="#section-3.8.2-4" class="pilcrow">¶</a></p>
<p id="section-3.8.2-5">When an incorrect implementation of the above-mentioned security
          policy receives an ICMP PTB message, it discards the packet because
          its source address is not associated with an existing flow.<a href="#section-3.8.2-5" class="pilcrow">¶</a></p>
<p id="section-3.8.2-6">The security policy described above has been implemented incorrectly on
             many consumer CPE routers.<a href="#section-3.8.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Anycast">
<section id="section-3.8.3">
          <h4 id="name-persistent-loss-caused-by-a">
<a href="#section-3.8.3" class="section-number selfRef">3.8.3. </a><a href="#name-persistent-loss-caused-by-a" class="section-name selfRef">Persistent Loss Caused by Anycast</a>
          </h4>
<p id="section-3.8.3-1">Anycast can cause persistent loss of ICMP PTB messages. Consider
          the example below:<a href="#section-3.8.3-1" class="pilcrow">¶</a></p>
<p id="section-3.8.3-2">A DNS client sends a request to an anycast address. The network
          routes that DNS request to the nearest instance of that anycast
          address (i.e., a DNS server). The DNS server generates a response
          and sends it back to the DNS client. While the response does not
          exceed the DNS server's PMTU estimate, it does exceed the actual
          PMTU.<a href="#section-3.8.3-2" class="pilcrow">¶</a></p>
<p id="section-3.8.3-3">A downstream router drops the packet and sends an ICMP PTB
          message the packet's source (i.e., the anycast address). The network
          routes the ICMP PTB message to the anycast instance closest to the
          downstream router. That anycast instance may not be the DNS server
          that originated the DNS response. It may be another DNS server with
          the same anycast address. The DNS server that originated the
          response may never receive the ICMP PTB message and may never update
          its PMTU estimate.<a href="#section-3.8.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="unidirectional">
<section id="section-3.8.4">
          <h4 id="name-persistent-loss-caused-by-u">
<a href="#section-3.8.4" class="section-number selfRef">3.8.4. </a><a href="#name-persistent-loss-caused-by-u" class="section-name selfRef">Persistent Loss Caused by Unidirectional Routing</a>
          </h4>
<p id="section-3.8.4-1">Unidirectional routing can cause persistent loss of ICMP PTB
          messages. Consider the example below:<a href="#section-3.8.4-1" class="pilcrow">¶</a></p>
<p id="section-3.8.4-2">A source node sends a packet to a destination node. All
          intermediate nodes maintain a route to the destination node but do
          not maintain a route to the source node. In this case, when an
          intermediate node encounters an MTU issue, it cannot send an ICMP
          PTB message to the source node.<a href="#section-3.8.4-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-3.9">
        <h3 id="name-black-holing-due-to-filteri">
<a href="#section-3.9" class="section-number selfRef">3.9. </a><a href="#name-black-holing-due-to-filteri" class="section-name selfRef">Black-Holing Due to Filtering or Loss</a>
        </h3>
<p id="section-3.9-1">In RFC 7872, researchers sampled Internet paths to determine
        whether they would convey packets that contain IPv6 extension headers.
        Sampled paths terminated at popular Internet sites (e.g., popular web,
        mail, and DNS servers).<a href="#section-3.9-1" class="pilcrow">¶</a></p>
<p id="section-3.9-2">The study revealed that at least 28% of the sampled paths did not
        convey packets containing the IPv6 Fragment extension header. In most
        cases, fragments were dropped in the destination autonomous system. In
        other cases, the fragments were dropped in transit autonomous
        systems.<a href="#section-3.9-2" class="pilcrow">¶</a></p>
<p id="section-3.9-3">Another <span><a href="#Huston" class="xref">study</a> [<a href="#Huston" class="xref">Huston</a>]</span> confirmed this
        finding. It reported that 37% of sampled endpoints used IPv6-capable
        DNS resolvers that were incapable of receiving a fragmented IPv6
        response.<a href="#section-3.9-3" class="pilcrow">¶</a></p>
<p id="section-3.9-4">It is difficult to determine why network operators drop fragments.
        Possible causes follow:<a href="#section-3.9-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.9-5.1">Hardware inability to process fragmented packets.<a href="#section-3.9-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.9-5.2">Failure to change vendor defaults.<a href="#section-3.9-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.9-5.3">Unintentional misconfiguration.<a href="#section-3.9-5.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.9-5.4">Intentional configuration (e.g., network operators consciously
            chooses to drop IPv6 fragments in order to address the issues
            raised in Sections <a href="#mb" class="xref">3.2</a> through <a href="#PTB" class="xref">3.8</a>,
            above.)<a href="#section-3.9-5.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</section>
<section id="section-4">
      <h2 id="name-alternatives-to-ip-fragment">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-alternatives-to-ip-fragment" class="section-name selfRef">Alternatives to IP Fragmentation</a>
      </h2>
<p id="section-4-1"></p>
<section id="section-4.1">
        <h3 id="name-transport-layer-solutions">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-transport-layer-solutions" class="section-name selfRef">Transport-Layer Solutions</a>
        </h3>
<p id="section-4.1-1">The <span><a href="#RFC0793" class="xref">Transport Control Protocol (TCP)</a> [<a href="#RFC0793" class="xref">RFC0793</a>]</span>)
        can be operated in a mode that does not require IP fragmentation.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">Applications submit a stream of data to TCP. TCP divides that
        stream of data into segments, with no segment exceeding the TCP
        Maximum Segment Size (MSS). Each segment is encapsulated in a TCP
        header and submitted to the underlying IP module. The underlying IP
        module prepends an IP header and forwards the resulting packet.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">If the TCP MSS is sufficiently small, then the underlying IP module
        never produces a packet whose length is greater than the actual PMTU.
        Therefore, IP fragmentation is not required.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">TCP offers the following mechanisms for MSS management:<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-5.1">Manual configuration.<a href="#section-4.1-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-5.2">PMTUD.<a href="#section-4.1-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-5.3">PLPMTUD.<a href="#section-4.1-5.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-6">Manual configuration is always applicable. If the MSS is configured
        to a sufficiently low value, the IP layer will never produce a packet
        whose length is greater than the protocol minimum link MTU. However,
        manual configuration prevents TCP from taking advantage of larger link
        MTUs.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1-7">Upper-layer protocols can implement PMTUD in order to discover and
        take advantage of larger Path MTUs. However, as mentioned in 
        <a href="#pmtu" class="xref">Section 2.1</a>, PMTUD relies upon the network to deliver ICMP PTB
        messages. Therefore, PMTUD can only provide an estimate of the PMTU in
        environments where the risk of ICMP PTB loss is acceptable (e.g.,
        known to not be filtered).<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<p id="section-4.1-8">By contrast, PLPMTUD does not rely upon the network's ability to
        deliver ICMP PTB messages. It utilizes probe messages sent as TCP
        segments to determine whether the probed PMTU can be successfully used
        across the network path. In PLPMTUD, probing is separated from
        congestion control, so that loss of a TCP probe segment does not cause
        a reduction of the congestion control window. <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span>
        defines PLPMTUD procedures for TCP.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<p id="section-4.1-9">While TCP will never knowingly cause the underlying IP module to
        emit a packet that is larger than the PMTU estimate, it can cause the
        underlying IP module to emit a packet that is larger than the actual
        PMTU. For example, if routing changes and as a result the PMTU becomes
        smaller, TCP will not know until the ICMP PTB message arrives. If this
        occurs, the packet is dropped, the PMTU estimate is updated, the
        segment is divided into smaller segments, and each smaller segment is
        submitted to the underlying IP module.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
<p id="section-4.1-10">The <span><a href="#RFC4340" class="xref">Datagram Congestion Control Protocol
        (DCCP)</a> [<a href="#RFC4340" class="xref">RFC4340</a>]</span> and the <span><a href="#RFC4960" class="xref">Stream Control Transmission
        Protocol (SCTP)</a> [<a href="#RFC4960" class="xref">RFC4960</a>]</span> also can be operated in a mode that does not
        require IP fragmentation. They both accept data from an application
        and divide that data into segments, with no segment exceeding a
        maximum size.<a href="#section-4.1-10" class="pilcrow">¶</a></p>
<p id="section-4.1-11">DCCP offers manual configuration,
        PMTUD, and PLPMTUD as mechanisms for managing that maximum size.
        Datagram protocols can also implement PLPMTUD to estimate the PMTU
        via <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span>. This proposes
        procedures for performing PLPMTUD with UDP, UDP options, SCTP, QUIC,
        and other datagram protocols.<a href="#section-4.1-11" class="pilcrow">¶</a></p>
<p id="section-4.1-12">Currently, <span><a href="#RFC0768" class="xref">User Datagram Protocol (UDP)</a> [<a href="#RFC0768" class="xref">RFC0768</a>]</span>
        lacks a fragmentation mechanism of its own and relies on IP
        fragmentation. However, <span>[<a href="#I-D.ietf-tsvwg-udp-options" class="xref">UDP-OPTIONS</a>]</span>
        proposes a fragmentation mechanism for UDP.<a href="#section-4.1-12" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2">
        <h3 id="name-application-layer-solutions">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-application-layer-solutions" class="section-name selfRef">Application-Layer Solutions</a>
        </h3>
<p id="section-4.2-1"><span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span> recognizes that IP fragmentation reduces
        the reliability of Internet communication. It also recognizes that UDP
        lacks a fragmentation mechanism of its own and relies on IP
        fragmentation. Therefore, <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span> offers the
        following advice regarding applications the run over the UDP:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<blockquote id="section-4.2-2">An application <span class="bcp14">SHOULD NOT</span> send UDP datagrams that result in IP
        packets that exceed the Maximum Transmission Unit (MTU) along the path
        to the destination. Consequently, an application <span class="bcp14">SHOULD</span> either use the
        path MTU information provided by the IP layer or implement Path MTU
        Discovery (PMTUD) itself <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span>
          <span>[<a href="#RFC1981" class="xref">RFC1981</a>]</span> <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span> to determine whether the path to a
        destination will support its desired message size without
        fragmentation.<a href="#section-4.2-2" class="pilcrow">¶</a>
</blockquote>
<p id="section-4.2-3">RFC 8085 continues:<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<blockquote id="section-4.2-4">Applications that do not follow the recommendation to do
        PMTU/PLPMTUD discovery <span class="bcp14">SHOULD</span> still avoid sending UDP datagrams that
        would result in IP packets that exceed the path MTU. Because the
        actual path MTU is unknown, such applications <span class="bcp14">SHOULD</span> fall back to
        sending messages that are shorter than the default effective MTU for
        sending (EMTU_S in <span>[<a href="#RFC1122" class="xref">RFC1122</a>]</span>). For IPv4, EMTU_S is the
        smaller of 576 bytes and the first-hop MTU <span>[<a href="#RFC1122" class="xref">RFC1122</a>]</span>.  For IPv6, EMTU_S is 1280
        bytes <span>[<a href="#RFC2460" class="xref">RFC2460</a>]</span>. The effective PMTU for a directly
        connected destination (with no routers on the path) is the configured
        interface MTU, which could be less than the maximum link payload size.
        Transmission of minimum-sized UDP datagrams is inefficient over paths
        that support a larger PMTU, which is a second reason to implement PMTU
        discovery.<a href="#section-4.2-4" class="pilcrow">¶</a>
</blockquote>
<p id="section-4.2-5">RFC 8085 assumes that for IPv4 an EMTU_S of 576 is sufficiently
        small to be supported by most current Internet
        paths, even though the IPv4 minimum link MTU is 68 octets.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<p id="section-4.2-6">This advice applies equally to any application that runs directly
        over IP.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
</section>
</section>
<div id="rely">
<section id="section-5">
      <h2 id="name-applications-that-rely-on-i">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-applications-that-rely-on-i" class="section-name selfRef">Applications That Rely on IPv6 Fragmentation</a>
      </h2>
<p id="section-5-1">The following applications rely on IPv6 fragmentation:<a href="#section-5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-2.1">
          <span><a href="#RFC1035" class="xref">DNS</a> [<a href="#RFC1035" class="xref">RFC1035</a>]</span>.<a href="#section-5-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.2">
          <span><a href="#RFC2328" class="xref">OSPFv2</a> [<a href="#RFC2328" class="xref">RFC2328</a>]</span>.<a href="#section-5-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.3">
          <span><a href="#RFC5340" class="xref">OSPFv3</a> [<a href="#RFC5340" class="xref">RFC5340</a>]</span>.<a href="#section-5-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.4">Packet-in-packet encapsulations.<a href="#section-5-2.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-3">Each of these applications relies on IPv6 fragmentation to a
      varying degree. In some cases, that reliance is essential and cannot be
      broken without fundamentally changing the protocol. In other cases, that
      reliance is incidental, and most implementations already take
      appropriate steps to avoid fragmentation.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">This list is not comprehensive, and other protocols that rely on IP
      fragmentation may exist. They are not specifically considered in the
      context of this document.<a href="#section-5-4" class="pilcrow">¶</a></p>
<section id="section-5.1">
        <h3 id="name-domain-name-service-dns">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-domain-name-service-dns" class="section-name selfRef">Domain Name Service (DNS)</a>
        </h3>
<p id="section-5.1-1">DNS relies on UDP for efficiency, and the consequence is the use of
        IP fragmentation for large responses, as permitted by the Extension Mechanisms for DNS (EDNS0)
        options in the query. It is possible to mitigate the issue of
        fragmentation-based packet loss by having queries use smaller EDNS0
        UDP buffer sizes or by having the DNS server limit the size of its
        UDP responses to some self-imposed maximum packet size that may be
        less than the preferred EDNS0 UDP buffer size. In both cases, large
        responses are truncated in the DNS, signaling to the client to
        re-query using TCP to obtain the complete response. However, the
        operational issue of the partial level of support for DNS over TCP,
        particularly in the case where IPv6 transport is being used, becomes a
        limiting factor of the efficacy of this approach <span>[<a href="#Damas" class="xref">Damas</a>]</span>.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">Larger DNS responses can normally be avoided by aggressively
        pruning the Additional section of DNS responses. One scenario where
        such pruning is ineffective is in the use of DNSSEC, where large key
        sizes act to increase the response size to certain DNS queries. There
        is no effective response to this situation within the DNS other than
        using smaller cryptographic keys and adopting of DNSSEC administrative
        practices that attempt to keep DNS response as short as possible.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-5.2">
        <h3 id="name-open-shortest-path-first-os">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-open-shortest-path-first-os" class="section-name selfRef">Open Shortest Path First (OSPF)</a>
        </h3>
<p id="section-5.2-1">OSPF implementations can emit messages large enough to cause
        fragmentation. However, in order to optimize performance, most OSPF
        implementations restrict their maximum message size to a value that
        will not cause fragmentation.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.3">
        <h3 id="name-packet-in-packet-encapsulat">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-packet-in-packet-encapsulat" class="section-name selfRef">Packet-in-Packet Encapsulations</a>
        </h3>
<p id="section-5.3-1"> This document acknowledges that in some cases, packets must
 be fragmented within IP-in-IP tunnels.  Therefore, this document
 makes no additional recommendations regarding IP-in-IP
 tunnels.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">In this document, packet-in-packet encapsulations include 
        <span><a href="#RFC2003" class="xref">IP-in-IP</a> [<a href="#RFC2003" class="xref">RFC2003</a>]</span>, 
        <span><a href="#RFC2784" class="xref">Generic Routing Encapsulation (GRE)</a> [<a href="#RFC2784" class="xref">RFC2784</a>]</span>, 
        <span><a href="#RFC8086" class="xref">GRE-in-UDP</a> [<a href="#RFC8086" class="xref">RFC8086</a>]</span>, and 
        <span><a href="#RFC2473" class="xref">Generic Packet Tunneling in IPv6</a> [<a href="#RFC2473" class="xref">RFC2473</a>]</span>. 
        <span>[<a href="#RFC4459" class="xref">RFC4459</a>]</span> describes
        fragmentation issues associated with all of the above-mentioned
        encapsulations.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<p id="section-5.3-3">The fragmentation strategy described for GRE in 
        <span>[<a href="#RFC7588" class="xref">RFC7588</a>]</span> has been deployed for all of the above-mentioned
        encapsulations. This strategy does not rely on IP fragmentation except
        in one corner case. 
        (See <span><a href="https://www.rfc-editor.org/rfc/rfc7588#section-3.3.2.2" class="relref">Section 3.3.2.2</a> of [<a href="#RFC7588" class="xref">RFC7588</a>]</span> 
        and <span><a href="https://www.rfc-editor.org/rfc/rfc2473#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC2473" class="xref">RFC2473</a>]</span>.) 
        <span><a href="https://www.rfc-editor.org/rfc/rfc7676#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC7676" class="xref">RFC7676</a>]</span> further
        describes this corner case.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<p id="section-5.3-4">See <span>[<a href="#I-D.ietf-intarea-tunnels" class="xref">TUNNELS</a>]</span> for further
        discussion.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
</section>
<section id="section-5.4">
        <h3 id="name-udp-applications-enhancing-">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-udp-applications-enhancing-" class="section-name selfRef">UDP Applications Enhancing Performance</a>
        </h3>
<p id="section-5.4-1">Some UDP applications rely on IP fragmentation to achieve
        acceptable levels of performance. These applications use UDP datagram
        sizes that are larger than the Path MTU so that more data can be
        conveyed between the application and the kernel in a single system
        call.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">To pick one example, the <span><a href="#RFC5326" class="xref">Licklider
        Transmission Protocol (LTP)</a> [<a href="#RFC5326" class="xref">RFC5326</a>]</span>, which is in current use on the
        International Space Station (ISS), uses UDP datagram sizes larger than
        the Path MTU to achieve acceptable levels of performance even though
        this invokes IP fragmentation. More generally, SNMP and video
        applications may transmit an application-layer quantum of data,
        depending on the network layer to fragment and reassemble as
        needed.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<p id="section-5.4-3"></p>
</section>
</section>
</div>
<section id="section-6">
      <h2 id="name-recommendations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-recommendations" class="section-name selfRef">Recommendations</a>
      </h2>
<p id="section-6-1"></p>
<section id="section-6.1">
        <h3 id="name-for-application-and-protoco">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-for-application-and-protoco" class="section-name selfRef">For Application and Protocol Developers</a>
        </h3>
<p id="section-6.1-1">Developers <span class="bcp14">SHOULD NOT</span> develop new protocols or applications that
        rely on IP fragmentation. When a new protocol or application is
        deployed in an environment that does not fully support IP
        fragmentation, it <span class="bcp14">SHOULD</span> operate correctly, either in its default
        configuration or in a specified alternative configuration.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">While there may be controlled environments where IP
 fragmentation 
        works reliably, this is a deployment issue and can not be known
        to someone developing a new protocol or application.  It is not
        recommended that new protocols or applications be developed that
        rely on IP fragmentation.   
 Protocols and
        applications that rely on IP fragmentation will work less
        reliably on the Internet.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">Legacy protocols that depend upon IP fragmentation <span class="bcp14">SHOULD</span> be
        updated to break that dependency. However, in some cases, there may be
        no viable alternative to IP fragmentation (e.g., IPSEC tunnel mode,
        IP-in-IP encapsulation).
        Applications and protocols cannot necessarily know or control
 whether they use lower layers or network paths that rely on such
 fragmentation. 
 In these cases, the protocol will continue to
        rely on IP fragmentation but should only be used in environments where
        IP fragmentation is known to be supported.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">Protocols may be able to avoid IP fragmentation by using a
        sufficiently small MTU (e.g., The protocol minimum link MTU), disabling
        IP fragmentation, and ensuring that the transport protocol in use
        adapts its segment size to the MTU. Other protocols may deploy a
        sufficiently reliable PMTU discovery mechanism (e.g., PLPMTUD).<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">UDP applications <span class="bcp14">SHOULD</span> abide by the recommendations stated in
        <span><a href="https://www.rfc-editor.org/rfc/rfc8085#section-3.2" class="relref">Section 3.2</a> of [<a href="#RFC8085" class="xref">RFC8085</a>]</span>.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
</section>
<section id="section-6.2">
        <h3 id="name-for-system-developers">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-for-system-developers" class="section-name selfRef">For System Developers</a>
        </h3>
<p id="section-6.2-1">Software libraries <span class="bcp14">SHOULD</span> include provision for PLPMTUD for each
        supported transport protocol.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-6.3">
        <h3 id="name-for-middlebox-developers">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-for-middlebox-developers" class="section-name selfRef">For Middlebox Developers</a>
        </h3>
<p id="section-6.3-1">Middleboxes, which are systems that "transparently"
 perform policy functions on passing traffic but do not
 participate in the routing system, should process IP fragments
 in a manner that is consistent with <span>[<a href="#RFC0791" class="xref">RFC0791</a>]</span>
 and <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>.  In many cases, middleboxes
 must maintain state in order to achieve this goal.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">Price and performance considerations frequently motivate network
        operators to deploy stateless middleboxes. These stateless middleboxes
        may perform suboptimally, process IP fragments in a manner that is not
        compliant with RFC 791 or RFC 8200, or even discard IP fragments
        completely. Such behaviors are <span class="bcp14">NOT RECOMMENDED</span>. If a
        middlebox implements nonstandard behavior with respect to IP
        fragmentation, then that behavior <span class="bcp14">MUST</span> be clearly
        documented.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
</section>
<div id="lagrec">
<section id="section-6.4">
        <h3 id="name-for-ecmp-lag-and-load-balan">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-for-ecmp-lag-and-load-balan" class="section-name selfRef">For ECMP, LAG, and Load-Balancer Developers And Operators</a>
        </h3>
<p id="section-6.4-1">In their default configuration, when the IPv6 Flow Label is not
        equal to zero, IPv6 devices that implement Equal-Cost Multipath (ECMP)
        Routing as described in <span><a href="#RFC2328" class="xref">OSPF</a> [<a href="#RFC2328" class="xref">RFC2328</a>]</span>
        and other routing protocols, <span><a href="#RFC7424" class="xref">Link
        Aggregation Grouping (LAG)</a> [<a href="#RFC7424" class="xref">RFC7424</a>]</span>, or other load-distribution
        technologies <span class="bcp14">SHOULD</span> accept only the following fields as input to their
        hash algorithm:<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.4-2.1">IP Source Address.<a href="#section-6.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.4-2.2">IP Destination Address.<a href="#section-6.4-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.4-2.3">Flow Label.<a href="#section-6.4-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.4-3">Operators <span class="bcp14">SHOULD</span> deploy these devices in their
        default configuration.<a href="#section-6.4-3" class="pilcrow">¶</a></p>
<p id="section-6.4-4">These recommendations are similar to those presented in <span>[<a href="#RFC6438" class="xref">RFC6438</a>]</span> and <span>[<a href="#RFC7098" class="xref">RFC7098</a>]</span>. They differ in that
        they specify a default configuration.<a href="#section-6.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-6.5">
        <h3 id="name-for-network-operators">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-for-network-operators" class="section-name selfRef">For Network Operators</a>
        </h3>
<p id="section-6.5-1">Operators <span class="bcp14">MUST</span> ensure proper PMTUD operation in their network,
        including making sure the network generates PTB packets when
        dropping packets too large compared to outgoing interface
        MTU. However, implementations <span class="bcp14">MAY</span> rate limit the generation of
        ICMP messages per <span>[<a href="#RFC1812" class="xref">RFC1812</a>]</span> and <span>[<a href="#RFC4443" class="xref">RFC4443</a>]</span>.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<p id="section-6.5-2">As per RFC 4890, network operators <span class="bcp14">MUST NOT</span> filter ICMPv6 PTB
        messages unless they are known to be forged or otherwise illegitimate.
        As stated in <a href="#PTB" class="xref">Section 3.8</a>, filtering ICMPv6 PTB packets causes
        PMTUD to fail. Many upper-layer protocols rely on PMTUD.<a href="#section-6.5-2" class="pilcrow">¶</a></p>
<p id="section-6.5-3">As per RFC 8200, network operators <span class="bcp14">MUST NOT</span> deploy IPv6 links whose
        MTU is less than 1280 octets.<a href="#section-6.5-3" class="pilcrow">¶</a></p>
<p id="section-6.5-4">Network operators <span class="bcp14">SHOULD NOT</span> filter IP fragments if they are known
        to have originated at a domain name server or be destined for a domain
        name server. This is because domain name services are critical to
        operation of the Internet.<a href="#section-6.5-4" class="pilcrow">¶</a></p>
</section>
</section>
<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">This document has no IANA actions.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">This document mitigates some of the security considerations
      associated with IP fragmentation by discouraging its use. It does not
      introduce any new security vulnerabilities, because it does not
      introduce any new alternatives to IP fragmentation. Instead, it
      recommends well-understood alternatives.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC0768">[RFC0768]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"User Datagram Protocol"</span>, <span class="seriesInfo">STD 6</span>, <span class="seriesInfo">RFC 768</span>, <span class="seriesInfo">DOI 10.17487/RFC0768</span>, <time datetime="1980-08" class="refDate">August 1980</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc768">https://www.rfc-editor.org/info/rfc768</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0791">[RFC0791]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 791</span>, <span class="seriesInfo">DOI 10.17487/RFC0791</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc791">https://www.rfc-editor.org/info/rfc791</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0792">[RFC0792]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Control Message Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 792</span>, <span class="seriesInfo">DOI 10.17487/RFC0792</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc792">https://www.rfc-editor.org/info/rfc792</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0793">[RFC0793]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1035">[RFC1035]</dt>
        <dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - implementation and specification"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1035</span>, <span class="seriesInfo">DOI 10.17487/RFC1035</span>, <time datetime="1987-11" class="refDate">November 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1191">[RFC1191]</dt>
        <dd>
<span class="refAuthor">Mogul, J.</span><span class="refAuthor"> and 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="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="RFC4443">[RFC4443]</dt>
        <dd>
<span class="refAuthor">Conta, A.</span><span class="refAuthor">, Deering, S.</span><span class="refAuthor">, and 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><span class="refAuthor"> and J. Heffner</span>, <span class="refTitle">"Packetization Layer Path MTU Discovery"</span>, <span class="seriesInfo">RFC 4821</span>, <span class="seriesInfo">DOI 10.17487/RFC4821</span>, <time datetime="2007-03" class="refDate">March 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4821">https://www.rfc-editor.org/info/rfc4821</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6437">[RFC6437]</dt>
        <dd>
<span class="refAuthor">Amante, S.</span><span class="refAuthor">, Carpenter, B.</span><span class="refAuthor">, Jiang, S.</span><span class="refAuthor">, and J. Rajahalme</span>, <span class="refTitle">"IPv6 Flow Label Specification"</span>, <span class="seriesInfo">RFC 6437</span>, <span class="seriesInfo">DOI 10.17487/RFC6437</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6437">https://www.rfc-editor.org/info/rfc6437</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6438">[RFC6438]</dt>
        <dd>
<span class="refAuthor">Carpenter, B.</span><span class="refAuthor"> and 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="RFC8085">[RFC8085]</dt>
        <dd>
<span class="refAuthor">Eggert, L.</span><span class="refAuthor">, Fairhurst, G.</span><span class="refAuthor">, and G. Shepherd</span>, <span class="refTitle">"UDP Usage Guidelines"</span>, <span class="seriesInfo">BCP 145</span>, <span class="seriesInfo">RFC 8085</span>, <span class="seriesInfo">DOI 10.17487/RFC8085</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8085">https://www.rfc-editor.org/info/rfc8085</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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><span class="refAuthor"> and R. Hinden</span>, <span class="refTitle">"Internet Protocol, Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 86</span>, <span class="seriesInfo">RFC 8200</span>, <span class="seriesInfo">DOI 10.17487/RFC8200</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8200">https://www.rfc-editor.org/info/rfc8200</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8201">[RFC8201]</dt>
        <dd>
<span class="refAuthor">McCann, J.</span><span class="refAuthor">, Deering, S.</span><span class="refAuthor">, Mogul, J.</span><span class="refAuthor">, and 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>
<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><span class="refAuthor">, and 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>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="Damas">[Damas]</dt>
        <dd>
<span class="refAuthor">Damas, J.</span><span class="refAuthor"> and G. Huston</span>, <span class="refTitle">"Measuring ATR"</span>, <time datetime="2018-04" class="refDate">April 2018</time>, <span>&lt;<a href="http://www.potaroo.net/ispcol/2018-04/atr.html">http://www.potaroo.net/ispcol/2018-04/atr.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Huston">[Huston]</dt>
        <dd>
<span class="refAuthor">Huston, G.</span>, <span class="refTitle">"IPv6, Large UDP Packets and the DNS"</span>, <time datetime="2017-08" class="refDate">August 2017</time>, <span>&lt;<a href="http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html">http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Kent">[Kent]</dt>
        <dd>
<span class="refAuthor">Kent, C.</span><span class="refAuthor"> and J. Mogul</span>, <span class="refTitle">"Fragmentation Considered Harmful"</span>, <span class="refContent">SIGCOMM '87: Proceedings of the ACM workshop on Frontiers in computer communications technology</span>, <span class="seriesInfo">DOI 10.1145/55482.55524</span>, <time datetime="1987-08" class="refDate">August 1987</time>, <span>&lt;<a href="http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf">http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Ptacek1998">[Ptacek1998]</dt>
        <dd>
<span class="refAuthor">Ptacek, T. H.</span><span class="refAuthor"> and T. N. Newsham</span>, <span class="refTitle">"Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection"</span>, <time datetime="1998" class="refDate">1998</time>, <span>&lt;<a href="http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps">http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1122">[RFC1122]</dt>
        <dd>
<span class="refAuthor">Braden, R., Ed.</span>, <span class="refTitle">"Requirements for Internet Hosts - Communication Layers"</span>, <span class="seriesInfo">STD 3</span>, <span class="seriesInfo">RFC 1122</span>, <span class="seriesInfo">DOI 10.17487/RFC1122</span>, <time datetime="1989-10" class="refDate">October 1989</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1122">https://www.rfc-editor.org/info/rfc1122</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1812">[RFC1812]</dt>
        <dd>
<span class="refAuthor">Baker, F., Ed.</span>, <span class="refTitle">"Requirements for IP Version 4 Routers"</span>, <span class="seriesInfo">RFC 1812</span>, <span class="seriesInfo">DOI 10.17487/RFC1812</span>, <time datetime="1995-06" class="refDate">June 1995</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1812">https://www.rfc-editor.org/info/rfc1812</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1858">[RFC1858]</dt>
        <dd>
<span class="refAuthor">Ziemba, G.</span><span class="refAuthor">, Reed, D.</span><span class="refAuthor">, and P. Traina</span>, <span class="refTitle">"Security Considerations for IP Fragment Filtering"</span>, <span class="seriesInfo">RFC 1858</span>, <span class="seriesInfo">DOI 10.17487/RFC1858</span>, <time datetime="1995-10" class="refDate">October 1995</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1858">https://www.rfc-editor.org/info/rfc1858</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1981">[RFC1981]</dt>
        <dd>
<span class="refAuthor">McCann, J.</span><span class="refAuthor">, Deering, S.</span><span class="refAuthor">, and J. Mogul</span>, <span class="refTitle">"Path MTU Discovery for IP version 6"</span>, <span class="seriesInfo">RFC 1981</span>, <span class="seriesInfo">DOI 10.17487/RFC1981</span>, <time datetime="1996-08" class="refDate">August 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1981">https://www.rfc-editor.org/info/rfc1981</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2003">[RFC2003]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span>, <span class="refTitle">"IP Encapsulation within IP"</span>, <span class="seriesInfo">RFC 2003</span>, <span class="seriesInfo">DOI 10.17487/RFC2003</span>, <time datetime="1996-10" class="refDate">October 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2003">https://www.rfc-editor.org/info/rfc2003</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2328">[RFC2328]</dt>
        <dd>
<span class="refAuthor">Moy, J.</span>, <span class="refTitle">"OSPF Version 2"</span>, <span class="seriesInfo">STD 54</span>, <span class="seriesInfo">RFC 2328</span>, <span class="seriesInfo">DOI 10.17487/RFC2328</span>, <time datetime="1998-04" class="refDate">April 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2328">https://www.rfc-editor.org/info/rfc2328</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2460">[RFC2460]</dt>
        <dd>
<span class="refAuthor">Deering, S.</span><span class="refAuthor"> and R. Hinden</span>, <span class="refTitle">"Internet Protocol, Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">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="RFC2473">[RFC2473]</dt>
        <dd>
<span class="refAuthor">Conta, A.</span><span class="refAuthor"> and S. Deering</span>, <span class="refTitle">"Generic Packet Tunneling in IPv6 Specification"</span>, <span class="seriesInfo">RFC 2473</span>, <span class="seriesInfo">DOI 10.17487/RFC2473</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2473">https://www.rfc-editor.org/info/rfc2473</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2784">[RFC2784]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span><span class="refAuthor">, Li, T.</span><span class="refAuthor">, Hanks, S.</span><span class="refAuthor">, Meyer, D.</span><span class="refAuthor">, and P. Traina</span>, <span class="refTitle">"Generic Routing Encapsulation (GRE)"</span>, <span class="seriesInfo">RFC 2784</span>, <span class="seriesInfo">DOI 10.17487/RFC2784</span>, <time datetime="2000-03" class="refDate">March 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2784">https://www.rfc-editor.org/info/rfc2784</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3128">[RFC3128]</dt>
        <dd>
<span class="refAuthor">Miller, I.</span>, <span class="refTitle">"Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)"</span>, <span class="seriesInfo">RFC 3128</span>, <span class="seriesInfo">DOI 10.17487/RFC3128</span>, <time datetime="2001-06" class="refDate">June 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3128">https://www.rfc-editor.org/info/rfc3128</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4340">[RFC4340]</dt>
        <dd>
<span class="refAuthor">Kohler, E.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and S. Floyd</span>, <span class="refTitle">"Datagram Congestion Control Protocol (DCCP)"</span>, <span class="seriesInfo">RFC 4340</span>, <span class="seriesInfo">DOI 10.17487/RFC4340</span>, <time datetime="2006-03" class="refDate">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4340">https://www.rfc-editor.org/info/rfc4340</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4459">[RFC4459]</dt>
        <dd>
<span class="refAuthor">Savola, P.</span>, <span class="refTitle">"MTU and Fragmentation Issues with In-the-Network Tunneling"</span>, <span class="seriesInfo">RFC 4459</span>, <span class="seriesInfo">DOI 10.17487/RFC4459</span>, <time datetime="2006-04" class="refDate">April 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4459">https://www.rfc-editor.org/info/rfc4459</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4890">[RFC4890]</dt>
        <dd>
<span class="refAuthor">Davies, E.</span><span class="refAuthor"> and J. Mohacsi</span>, <span class="refTitle">"Recommendations for Filtering ICMPv6 Messages in Firewalls"</span>, <span class="seriesInfo">RFC 4890</span>, <span class="seriesInfo">DOI 10.17487/RFC4890</span>, <time datetime="2007-05" class="refDate">May 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4890">https://www.rfc-editor.org/info/rfc4890</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4960">[RFC4960]</dt>
        <dd>
<span class="refAuthor">Stewart, R., Ed.</span>, <span class="refTitle">"Stream Control Transmission Protocol"</span>, <span class="seriesInfo">RFC 4960</span>, <span class="seriesInfo">DOI 10.17487/RFC4960</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4960">https://www.rfc-editor.org/info/rfc4960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4963">[RFC4963]</dt>
        <dd>
<span class="refAuthor">Heffner, J.</span><span class="refAuthor">, Mathis, M.</span><span class="refAuthor">, and B. Chandler</span>, <span class="refTitle">"IPv4 Reassembly Errors at High Data Rates"</span>, <span class="seriesInfo">RFC 4963</span>, <span class="seriesInfo">DOI 10.17487/RFC4963</span>, <time datetime="2007-07" class="refDate">July 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4963">https://www.rfc-editor.org/info/rfc4963</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5326">[RFC5326]</dt>
        <dd>
<span class="refAuthor">Ramadas, M.</span><span class="refAuthor">, Burleigh, S.</span><span class="refAuthor">, and S. Farrell</span>, <span class="refTitle">"Licklider Transmission Protocol - Specification"</span>, <span class="seriesInfo">RFC 5326</span>, <span class="seriesInfo">DOI 10.17487/RFC5326</span>, <time datetime="2008-09" class="refDate">September 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5326">https://www.rfc-editor.org/info/rfc5326</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5340">[RFC5340]</dt>
        <dd>
<span class="refAuthor">Coltun, R.</span><span class="refAuthor">, Ferguson, D.</span><span class="refAuthor">, Moy, J.</span><span class="refAuthor">, and A. Lindem</span>, <span class="refTitle">"OSPF for IPv6"</span>, <span class="seriesInfo">RFC 5340</span>, <span class="seriesInfo">DOI 10.17487/RFC5340</span>, <time datetime="2008-07" class="refDate">July 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5340">https://www.rfc-editor.org/info/rfc5340</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5722">[RFC5722]</dt>
        <dd>
<span class="refAuthor">Krishnan, S.</span>, <span class="refTitle">"Handling of Overlapping IPv6 Fragments"</span>, <span class="seriesInfo">RFC 5722</span>, <span class="seriesInfo">DOI 10.17487/RFC5722</span>, <time datetime="2009-12" class="refDate">December 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5722">https://www.rfc-editor.org/info/rfc5722</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5927">[RFC5927]</dt>
        <dd>
<span class="refAuthor">Gont, F.</span>, <span class="refTitle">"ICMP Attacks against TCP"</span>, <span class="seriesInfo">RFC 5927</span>, <span class="seriesInfo">DOI 10.17487/RFC5927</span>, <time datetime="2010-07" class="refDate">July 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5927">https://www.rfc-editor.org/info/rfc5927</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6346">[RFC6346]</dt>
        <dd>
<span class="refAuthor">Bush, R., Ed.</span>, <span class="refTitle">"The Address plus Port (A+P) Approach to the IPv4 Address Shortage"</span>, <span class="seriesInfo">RFC 6346</span>, <span class="seriesInfo">DOI 10.17487/RFC6346</span>, <time datetime="2011-08" class="refDate">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6346">https://www.rfc-editor.org/info/rfc6346</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6888">[RFC6888]</dt>
        <dd>
<span class="refAuthor">Perreault, S., Ed.</span><span class="refAuthor">, Yamagata, I.</span><span class="refAuthor">, Miyakawa, S.</span><span class="refAuthor">, Nakagawa, A.</span><span class="refAuthor">, and H. Ashida</span>, <span class="refTitle">"Common Requirements for Carrier-Grade NATs (CGNs)"</span>, <span class="seriesInfo">BCP 127</span>, <span class="seriesInfo">RFC 6888</span>, <span class="seriesInfo">DOI 10.17487/RFC6888</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6888">https://www.rfc-editor.org/info/rfc6888</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7098">[RFC7098]</dt>
        <dd>
<span class="refAuthor">Carpenter, B.</span><span class="refAuthor">, Jiang, S.</span><span class="refAuthor">, and W. Tarreau</span>, <span class="refTitle">"Using the IPv6 Flow Label for Load Balancing in Server Farms"</span>, <span class="seriesInfo">RFC 7098</span>, <span class="seriesInfo">DOI 10.17487/RFC7098</span>, <time datetime="2014-01" class="refDate">January 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7098">https://www.rfc-editor.org/info/rfc7098</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7424">[RFC7424]</dt>
        <dd>
<span class="refAuthor">Krishnan, R.</span><span class="refAuthor">, Yong, L.</span><span class="refAuthor">, Ghanwani, A.</span><span class="refAuthor">, So, N.</span><span class="refAuthor">, and B. Khasnabish</span>, <span class="refTitle">"Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks"</span>, <span class="seriesInfo">RFC 7424</span>, <span class="seriesInfo">DOI 10.17487/RFC7424</span>, <time datetime="2015-01" class="refDate">January 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7424">https://www.rfc-editor.org/info/rfc7424</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7588">[RFC7588]</dt>
        <dd>
<span class="refAuthor">Bonica, R.</span><span class="refAuthor">, Pignataro, C.</span><span class="refAuthor">, and J. Touch</span>, <span class="refTitle">"A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem"</span>, <span class="seriesInfo">RFC 7588</span>, <span class="seriesInfo">DOI 10.17487/RFC7588</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7588">https://www.rfc-editor.org/info/rfc7588</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7676">[RFC7676]</dt>
        <dd>
<span class="refAuthor">Pignataro, C.</span><span class="refAuthor">, Bonica, R.</span><span class="refAuthor">, and S. Krishnan</span>, <span class="refTitle">"IPv6 Support for Generic Routing Encapsulation (GRE)"</span>, <span class="seriesInfo">RFC 7676</span>, <span class="seriesInfo">DOI 10.17487/RFC7676</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7676">https://www.rfc-editor.org/info/rfc7676</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7739">[RFC7739]</dt>
        <dd>
<span class="refAuthor">Gont, F.</span>, <span class="refTitle">"Security Implications of Predictable Fragment Identification Values"</span>, <span class="seriesInfo">RFC 7739</span>, <span class="seriesInfo">DOI 10.17487/RFC7739</span>, <time datetime="2016-02" class="refDate">February 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7739">https://www.rfc-editor.org/info/rfc7739</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7872">[RFC7872]</dt>
        <dd>
<span class="refAuthor">Gont, F.</span><span class="refAuthor">, Linkova, J.</span><span class="refAuthor">, Chown, T.</span><span class="refAuthor">, and W. Liu</span>, <span class="refTitle">"Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World"</span>, <span class="seriesInfo">RFC 7872</span>, <span class="seriesInfo">DOI 10.17487/RFC7872</span>, <time datetime="2016-06" class="refDate">June 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7872">https://www.rfc-editor.org/info/rfc7872</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8086">[RFC8086]</dt>
        <dd>
<span class="refAuthor">Yong, L., Ed.</span><span class="refAuthor">, Crabbe, E.</span><span class="refAuthor">, Xu, X.</span><span class="refAuthor">, and T. Herbert</span>, <span class="refTitle">"GRE-in-UDP Encapsulation"</span>, <span class="seriesInfo">RFC 8086</span>, <span class="seriesInfo">DOI 10.17487/RFC8086</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8086">https://www.rfc-editor.org/info/rfc8086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-intarea-tunnels">[TUNNELS]</dt>
        <dd>
<span class="refAuthor">Touch, J.</span><span class="refAuthor"> and M. Townsley</span>, <span class="refTitle">"IP Tunnels in the Internet Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-intarea-tunnels-10</span>, <time datetime="2019-09-12" class="refDate">12 September 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10">https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-tsvwg-udp-options">[UDP-OPTIONS]</dt>
      <dd>
<span class="refAuthor">Touch, J.</span>, <span class="refTitle">"Transport Options for UDP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tsvwg-udp-options-08</span>, <time datetime="2019-09-12" class="refDate">12 September 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-08">https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-08</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">Thanks to <span class="contact-name">Mikael Abrahamsson</span>, 
      <span class="contact-name">Brian Carpenter</span>, <span class="contact-name">Silambu Chelvan</span>,
      <span class="contact-name">Lorenzo Colitti</span>, 
      <span class="contact-name">Gorry Fairhurst</span>, 
      <span class="contact-name">Joel Halpern</span>, 
      <span class="contact-name">Mike Heard</span>,
      <span class="contact-name">Tom Herbert</span>, <span class="contact-name">Tatuya Jinmei</span>, 
      <span class="contact-name">Suresh Krishnan</span>, <span class="contact-name">Jen Linkova</span>, 
      <span class="contact-name">Paolo Lucente</span>, <span class="contact-name">Manoj Nayak</span>, 
      <span class="contact-name">Eric Nygren</span>, <span class="contact-name">Fred Templin</span>, and 
      <span class="contact-name">Joe Touch</span> for their comments.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ron Bonica</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div dir="auto" class="left"><span class="street-address">2251 Corporate Park Drive</span></div>
<div dir="auto" class="left">
<span class="locality">Herndon</span>, <span class="region">Virginia</span> <span class="postal-code">20171</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:rbonica@juniper.net" class="email">rbonica@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Fred Baker</span></div>
<div dir="auto" class="left"><span class="org">Unaffiliated</span></div>
<div dir="auto" class="left">
<span class="locality">Santa Barbara</span>, <span class="region">California</span> <span class="postal-code">93117</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:FredBaker.IETF@gmail.com" class="email">FredBaker.IETF@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Geoff Huston</span></div>
<div dir="auto" class="left"><span class="org">APNIC</span></div>
<div dir="auto" class="left"><span class="street-address">6 Cordelia St</span></div>
<div dir="auto" class="left">
<span class="locality">Brisbane</span> <span class="region">4101 QLD</span> </div>
<div dir="auto" class="left"><span class="country-name">Australia</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:gih@apnic.net" class="email">gih@apnic.net</a>
</div>
</address>
<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">California</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">Ole Troan</span></div>
<div dir="auto" class="left"><span class="org">Cisco</span></div>
<div dir="auto" class="left"><span class="street-address">Philip Pedersens vei 1</span></div>
<div dir="auto" class="left"><span class="locality">N-1366 Lysaker</span></div>
<div dir="auto" class="left"><span class="country-name">Norway</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ot@cisco.com" class="email">ot@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Fernando Gont</span></div>
<div dir="auto" class="left"><span class="org">SI6 Networks</span></div>
<div dir="auto" class="left"><span class="street-address">Evaristo Carriego 2644</span></div>
<div dir="auto" class="left"><span class="locality">Haedo</span></div>
<div dir="auto" class="left"><span class="region">Provincia de Buenos Aires</span></div>
<div dir="auto" class="left"><span class="country-name">Argentina</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:fgont@si6networks.com" class="email">fgont@si6networks.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>