File: rfc9221.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 (1831 lines) | stat: -rw-r--r-- 65,227 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9221: An Unreliable Datagram Extension to QUIC</title>
<meta content="Tommy Pauly" name="author">
<meta content="Eric Kinnear" name="author">
<meta content="David Schinazi" name="author">
<meta content="
       This document defines an extension to the QUIC transport protocol to add support
for sending and receiving unreliable datagrams over a QUIC connection. 
    " name="description">
<meta content="xml2rfc 3.12.2" name="generator">
<meta content="quic" name="keyword">
<meta content="datagram" name="keyword">
<meta content="9221" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.2
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9221.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9221" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-quic-datagram-10" 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 9221</td>
<td class="center">QUIC Datagrams</td>
<td class="right">March 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Pauly, et al.</td>
<td class="center">Standards Track</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/rfc9221" class="eref">9221</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-03" class="published">March 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">T. Pauly</div>
<div class="org">Apple Inc.</div>
</div>
<div class="author">
      <div class="author-name">E. Kinnear</div>
<div class="org">Apple Inc.</div>
</div>
<div class="author">
      <div class="author-name">D. Schinazi</div>
<div class="org">Google LLC</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9221</h1>
<h1 id="title">An Unreliable Datagram Extension to QUIC</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines an extension to the QUIC transport protocol to add support
for sending and receiving unreliable datagrams over a QUIC connection.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<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 Internet Standards 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/rfc9221">https://www.rfc-editor.org/info/rfc9221</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-specification-of-requiremen" class="xref">Specification of Requirements</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-motivation" class="xref">Motivation</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-transport-parameter" class="xref">Transport Parameter</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-datagram-frame-types" class="xref">Datagram Frame Types</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-behavior-and-usage" class="xref">Behavior and Usage</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-multiplexing-datagrams" class="xref">Multiplexing Datagrams</a></p>
</li>
              <li class="compact toc ulBare 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-acknowledgement-handling" class="xref">Acknowledgement Handling</a></p>
</li>
              <li class="compact toc ulBare 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-flow-control" class="xref">Flow Control</a></p>
</li>
              <li class="compact toc ulBare 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-congestion-control" class="xref">Congestion Control</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-quic-transport-parameter" class="xref">QUIC Transport Parameter</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-quic-frame-types" class="xref">QUIC Frame Types</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The QUIC transport protocol <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span> provides a secure, multiplexed
connection for transmitting reliable streams of application data. QUIC uses
various frame types to transmit data within packets, and each frame type
defines whether the data it contains will be retransmitted. Streams of reliable
application data are sent using STREAM frames.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Some applications, particularly those that need to transmit real-time data,
prefer to transmit data unreliably. In the past, these applications have built
directly upon UDP <span>[<a href="#RFC0768" class="xref">RFC0768</a>]</span> as a transport and have often added security
with DTLS <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span>. Extending QUIC to support transmitting unreliable
application data provides another option for secure datagrams with the added
benefit of sharing the cryptographic and authentication context used for
reliable streams.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">This document defines two new DATAGRAM QUIC frame types that carry application
data without requiring retransmissions.<a href="#section-1-3" class="pilcrow">¶</a></p>
<div id="specification-of-requirements">
<section id="section-1.1">
        <h3 id="name-specification-of-requiremen">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-specification-of-requiremen" class="section-name selfRef">Specification of Requirements</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>
</div>
</section>
</div>
<div id="motivation">
<section id="section-2">
      <h2 id="name-motivation">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-motivation" class="section-name selfRef">Motivation</a>
      </h2>
<p id="section-2-1">Transmitting unreliable data over QUIC provides benefits over existing solutions:<a href="#section-2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-2.1">Applications that want to use both a reliable stream and an unreliable flow to
the same peer can benefit by sharing a single handshake and authentication
context between a reliable QUIC stream and a flow of unreliable QUIC
datagrams. This can reduce the latency required for handshakes compared to
opening both a TLS connection and a DTLS connection.<a href="#section-2-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.2">QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake. This
can allow loss recovery to occur more quickly for QUIC data.<a href="#section-2-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.3">QUIC datagrams are subject to QUIC congestion control. Providing a single
congestion control for both reliable and unreliable data can be more effective
and efficient.<a href="#section-2-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-3">These features can be useful for optimizing audio/video streaming applications,
gaming applications, and other real-time network applications.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">Unreliable QUIC datagrams can also be used to implement an IP packet tunnel over
      QUIC, such as for a Virtual Private Network (VPN). Internet-layer tunneling
protocols generally require a reliable and authenticated handshake followed by
unreliable secure transmission of IP packets. This can, for example, require a
TLS connection for the control data and DTLS for tunneling IP packets. A single
QUIC connection could support both parts with the use of unreliable datagrams
      in addition to reliable streams.<a href="#section-2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="transport-parameter">
<section id="section-3">
      <h2 id="name-transport-parameter">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-transport-parameter" class="section-name selfRef">Transport Parameter</a>
      </h2>
<p id="section-3-1">Support for receiving the DATAGRAM frame types is advertised by means of a QUIC
transport parameter (name=max_datagram_frame_size, value=0x20). The
max_datagram_frame_size transport parameter is an integer value (represented as
a variable-length integer) that represents the maximum size of a DATAGRAM frame
(including the frame type, length, and payload) the endpoint is willing to
receive, in bytes.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">The default for this parameter is 0, which indicates that the endpoint does not
support DATAGRAM frames. A value greater than 0 indicates that the endpoint
supports the DATAGRAM frame types and is willing to receive such frames on this
connection.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">An endpoint <span class="bcp14">MUST NOT</span> send DATAGRAM frames until it has received the
max_datagram_frame_size transport parameter with a non-zero value during the
handshake (or during a previous handshake if 0-RTT is used). An endpoint <span class="bcp14">MUST NOT</span> send DATAGRAM frames that are larger than the max_datagram_frame_size value
it has received from its peer. An endpoint that receives a DATAGRAM frame when
it has not indicated support via the transport parameter <span class="bcp14">MUST</span> terminate the
connection with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint that
receives a DATAGRAM frame that is larger than the value it sent in its
max_datagram_frame_size transport parameter <span class="bcp14">MUST</span> terminate the connection with
an error of type PROTOCOL_VIOLATION.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">For most uses of DATAGRAM frames, it is <span class="bcp14">RECOMMENDED</span> to send a value of 65535 in
the max_datagram_frame_size transport parameter to indicate that this endpoint
will accept any DATAGRAM frame that fits inside a QUIC packet.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">The max_datagram_frame_size transport parameter is a unidirectional limit and
indication of support of DATAGRAM frames. Application protocols that use
DATAGRAM frames <span class="bcp14">MAY</span> choose to only negotiate and use them in a single direction.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">When clients use 0-RTT, they <span class="bcp14">MAY</span> store the value of the server's
max_datagram_frame_size transport parameter. Doing so allows the client to send
DATAGRAM frames in 0-RTT packets. When servers decide to accept 0-RTT data,
they <span class="bcp14">MUST</span> send a max_datagram_frame_size transport parameter greater than or
equal to the value they sent to the client in the connection where they sent
them the NewSessionTicket message. If a client stores the value of the
max_datagram_frame_size transport parameter with their 0-RTT state, they <span class="bcp14">MUST</span>
validate that the new value of the max_datagram_frame_size transport parameter
sent by the server in the handshake is greater than or equal to the stored
value; if not, the client <span class="bcp14">MUST</span> terminate the connection with error
PROTOCOL_VIOLATION.<a href="#section-3-6" class="pilcrow">¶</a></p>
<p id="section-3-7">Application protocols that use datagrams <span class="bcp14">MUST</span> define how they react to the
absence of the max_datagram_frame_size transport parameter. If datagram support
is integral to the application, the application protocol can fail the handshake
if the max_datagram_frame_size transport parameter is not present.<a href="#section-3-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="datagram-frame-types">
<section id="section-4">
      <h2 id="name-datagram-frame-types">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-datagram-frame-types" class="section-name selfRef">Datagram Frame Types</a>
      </h2>
<p id="section-4-1">DATAGRAM frames are used to transmit application data in an unreliable manner.
The Type field in the DATAGRAM frame takes the form 0b0011000X (or the values
0x30 and 0x31). The least significant bit of the Type field in the DATAGRAM
frame is the LEN bit (0x01), which indicates whether there is a Length field
present: if this bit is set to 0, the Length field is absent and the Datagram
Data field extends to the end of the packet; if this bit is set to 1, the
Length field is present.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">DATAGRAM frames are structured as follows:<a href="#section-4-2" class="pilcrow">¶</a></p>
<span id="name-datagram-frame-format"></span><div id="datagram-format">
<figure id="figure-1">
        <div class="alignLeft art-text artwork" id="section-4-3.1">
<pre>
DATAGRAM Frame {
  Type (i) = 0x30..0x31,
  [Length (i)],
  Datagram Data (..),
}
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-datagram-frame-format" class="selfRef">DATAGRAM Frame Format</a>
        </figcaption></figure>
</div>
<p id="section-4-4">DATAGRAM frames contain the following fields:<a href="#section-4-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4-5">
        <dt id="section-4-5.1">
Length:  </dt>
        <dd style="margin-left: 1.5em" id="section-4-5.2">
          <p id="section-4-5.2.1">A variable-length integer specifying the length of the Datagram Data field in
bytes. This field is present only when the LEN bit is set to 1. When the LEN bit
is set to 0, the Datagram Data field extends to the end of the QUIC packet. Note
that empty (i.e., zero-length) datagrams are allowed.<a href="#section-4-5.2.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-4-5.3">
Datagram Data:  </dt>
        <dd style="margin-left: 1.5em" id="section-4-5.4">
          <p id="section-4-5.4.1">The bytes of the datagram to be delivered.<a href="#section-4-5.4.1" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="behavior-and-usage">
<section id="section-5">
      <h2 id="name-behavior-and-usage">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-behavior-and-usage" class="section-name selfRef">Behavior and Usage</a>
      </h2>
<p id="section-5-1">When an application sends a datagram over a QUIC connection, QUIC will generate
a new DATAGRAM frame and send it in the first available packet. This frame
<span class="bcp14">SHOULD</span> be sent as soon as possible (as determined by factors like congestion
control, described below) and <span class="bcp14">MAY</span> be coalesced with other frames.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">When a QUIC endpoint receives a valid DATAGRAM frame, it <span class="bcp14">SHOULD</span> deliver the data
to the application immediately, as long as it is able to process the frame and
can store the contents in memory.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">Like STREAM frames, DATAGRAM frames contain application data and <span class="bcp14">MUST</span> be
protected with either 0-RTT or 1-RTT keys.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">Note that while the max_datagram_frame_size transport parameter places a limit
on the maximum size of DATAGRAM frames, that limit can be further reduced by the
max_udp_payload_size transport parameter and the Maximum Transmission Unit
(MTU) of the path between endpoints. DATAGRAM frames cannot be fragmented;
therefore, application protocols need to handle cases where the maximum
datagram size is limited by other factors.<a href="#section-5-4" class="pilcrow">¶</a></p>
<div id="multiplexing-datagrams">
<section id="section-5.1">
        <h3 id="name-multiplexing-datagrams">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-multiplexing-datagrams" class="section-name selfRef">Multiplexing Datagrams</a>
        </h3>
<p id="section-5.1-1">DATAGRAM frames belong to a QUIC connection as a whole and are not associated
with any stream ID at the QUIC layer. However, it is expected that applications
will want to differentiate between specific DATAGRAM frames by using
identifiers, such as for logical flows of datagrams or to distinguish between
different kinds of datagrams.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">Defining the identifiers used to multiplex different kinds of datagrams or flows of datagrams is the responsibility of the application protocol running over QUIC. The application defines the semantics of the Datagram Data field and
how it is parsed.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">If the application needs to support the coexistence of multiple flows of
datagrams, one recommended pattern is to use a variable-length integer at the
beginning of the Datagram Data field. This is a simple approach that allows a
large number of flows to be encoded using minimal space.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<p id="section-5.1-4">QUIC implementations <span class="bcp14">SHOULD</span> present an API to applications to assign relative
priorities to DATAGRAM frames with respect to each other and to QUIC streams.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="acknowledgement-handling">
<section id="section-5.2">
        <h3 id="name-acknowledgement-handling">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-acknowledgement-handling" class="section-name selfRef">Acknowledgement Handling</a>
        </h3>
<p id="section-5.2-1">Although DATAGRAM frames are not retransmitted upon loss detection, they are
ack-eliciting (<span>[<a href="#RFC9002" class="xref">RFC9002</a>]</span>). Receivers <span class="bcp14">SHOULD</span> support delaying ACK frames
(within the limits specified by max_ack_delay) in response to receiving packets
that only contain DATAGRAM frames, since the sender takes no action if these
packets are temporarily unacknowledged. Receivers will continue to send ACK
frames when conditions indicate a packet might be lost, since the packet's
payload is unknown to the receiver, and when dictated by max_ack_delay or other
protocol components.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">As with any ack-eliciting frame, when a sender suspects that a packet containing
only DATAGRAM frames has been lost, it sends probe packets to elicit a faster
acknowledgement as described in <span><a href="https://www.rfc-editor.org/rfc/rfc9002#section-6.2.4" class="relref">Section 6.2.4</a> of [<a href="#RFC9002" class="xref">RFC9002</a>]</span>.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">If a sender detects that a packet containing a specific DATAGRAM frame might
have been lost, the implementation <span class="bcp14">MAY</span> notify the application that it believes
the datagram was lost.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<p id="section-5.2-4">Similarly, if a packet containing a DATAGRAM frame is acknowledged, the
implementation <span class="bcp14">MAY</span> notify the sender application that the datagram was
successfully transmitted and received. Due to reordering, this can include a
DATAGRAM frame that was thought to be lost but, at a later point, was
received and acknowledged. It is important to note that acknowledgement of a
DATAGRAM frame only indicates that the transport-layer handling on the receiver
processed the frame and does not guarantee that the application on the receiver
successfully processed the data. Thus, this signal cannot replace
application-layer signals that indicate successful processing.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="flow-control">
<section id="section-5.3">
        <h3 id="name-flow-control">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-flow-control" class="section-name selfRef">Flow Control</a>
        </h3>
<p id="section-5.3-1">DATAGRAM frames do not provide any explicit flow control signaling and do not
contribute to any per-flow or connection-wide data limit.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">The risk associated with not providing flow control for DATAGRAM frames is that
a receiver might not be able to commit the necessary resources to process the
frames. For example, it might not be able to store the frame contents in memory.
However, since DATAGRAM frames are inherently unreliable, they <span class="bcp14">MAY</span> be dropped by
the receiver if the receiver cannot process them.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="congestion-control">
<section id="section-5.4">
        <h3 id="name-congestion-control">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-congestion-control" class="section-name selfRef">Congestion Control</a>
        </h3>
<p id="section-5.4-1">DATAGRAM frames employ the QUIC connection's congestion controller. As a result,
a connection might be unable to send a DATAGRAM frame generated by the
application until the congestion controller allows it <span>[<a href="#RFC9002" class="xref">RFC9002</a>]</span>. The sender
<span class="bcp14">MUST</span> either delay sending the frame until the controller allows it or drop the
frame without sending it (at which point it <span class="bcp14">MAY</span> notify the application).
Implementations that use packet pacing (<span><a href="https://www.rfc-editor.org/rfc/rfc9002#section-7.7" class="relref">Section 7.7</a> of [<a href="#RFC9002" class="xref">RFC9002</a>]</span>) can also
 delay the sending of DATAGRAM frames to maintain consistent packet pacing.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">Implementations can optionally support allowing the application to specify a
sending expiration time beyond which a congestion-controlled DATAGRAM frame
ought to be dropped without transmission.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="security-considerations">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">The DATAGRAM frame shares the same security properties as the rest of the data
transmitted within a QUIC connection, and the security considerations of
<span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span> apply accordingly. All application data transmitted with the
DATAGRAM frame, like the STREAM frame, <span class="bcp14">MUST</span> be protected either by 0-RTT or
1-RTT keys.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Application protocols that allow DATAGRAM frames to be sent in 0-RTT require a
profile that defines acceptable use of 0-RTT; see <span><a href="https://www.rfc-editor.org/rfc/rfc9001#section-5.6" class="relref">Section 5.6</a> of [<a href="#RFC9001" class="xref">RFC9001</a>]</span>.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">The use of DATAGRAM frames might be detectable by an adversary on path that is
capable of dropping packets. Since DATAGRAM frames do not use transport-level
retransmission, connections that use DATAGRAM frames might be distinguished from
other connections due to their different response to packet loss.<a href="#section-6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<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>
<div id="quic-transport-parameter">
<section id="section-7.1">
        <h3 id="name-quic-transport-parameter">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-quic-transport-parameter" class="section-name selfRef">QUIC Transport Parameter</a>
        </h3>
<p id="section-7.1-1">This document registers a new value in the "QUIC Transport Parameters" registry
maintained at
<span>&lt;<a href="https://www.iana.org/assignments/quic">https://www.iana.org/assignments/quic</a>&gt;</span>.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-7.1-2">
          <dt id="section-7.1-2.1">
Value:  </dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.2">
            0x20<a href="#section-7.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.3">
Parameter Name:  </dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.4">
            max_datagram_frame_size<a href="#section-7.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.5">
Status:  </dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.6">
            permanent<a href="#section-7.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.7">
Specification:  </dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.8">
           RFC 9221<a href="#section-7.1-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="quic-frame-types">
<section id="section-7.2">
        <h3 id="name-quic-frame-types">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-quic-frame-types" class="section-name selfRef">QUIC Frame Types</a>
        </h3>
<p id="section-7.2-1">This document registers two new values in the "QUIC Frame Types" registry
maintained at
<span>&lt;<a href="https://www.iana.org/assignments/quic">https://www.iana.org/assignments/quic</a>&gt;</span>.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-7.2-2">
          <dt id="section-7.2-2.1">
Value:  </dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.2">
            0x30-0x31<a href="#section-7.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.2-2.3">
Frame Name:  </dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.4">
           DATAGRAM<a href="#section-7.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.2-2.5">
Status:  </dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.6">
            permanent<a href="#section-7.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.2-2.7">
Specification:  </dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.8">
            RFC 9221<a href="#section-7.2-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9000">[RFC9000]</dt>
        <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="seriesInfo">RFC 9000</span>, <span class="seriesInfo">DOI 10.17487/RFC9000</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9000">https://www.rfc-editor.org/info/rfc9000</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9001">[RFC9001]</dt>
        <dd>
<span class="refAuthor">Thomson, M., Ed.</span> and <span class="refAuthor">S. Turner, Ed.</span>, <span class="refTitle">"Using TLS to Secure QUIC"</span>, <span class="seriesInfo">RFC 9001</span>, <span class="seriesInfo">DOI 10.17487/RFC9001</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9001">https://www.rfc-editor.org/info/rfc9001</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9002">[RFC9002]</dt>
      <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">I. Swett, Ed.</span>, <span class="refTitle">"QUIC Loss Detection and Congestion Control"</span>, <span class="seriesInfo">RFC 9002</span>, <span class="seriesInfo">DOI 10.17487/RFC9002</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9002">https://www.rfc-editor.org/info/rfc9002</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative 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="RFC6347">[RFC6347]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"Datagram Transport Layer Security Version 1.2"</span>, <span class="seriesInfo">RFC 6347</span>, <span class="seriesInfo">DOI 10.17487/RFC6347</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6347">https://www.rfc-editor.org/info/rfc6347</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acknowledgments">
<section id="appendix-A">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-A-1">The original proposal for this work came from <span class="contact-name">Ian Swett</span>.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">This document had reviews and input from many contributors in the IETF QUIC
Working Group, with substantive input from <span class="contact-name">Nick Banks</span>, <span class="contact-name">Lucas Pardue</span>, <span class="contact-name">Rui Paulo</span>,
<span class="contact-name">Martin Thomson</span>, <span class="contact-name">Victor Vasiliev</span>, and <span class="contact-name">Chris Wood</span>.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Tommy Pauly</span></div>
<div dir="auto" class="left"><span class="org">Apple Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">One Apple Park Way</span></div>
<div dir="auto" class="left">
<span class="locality">Cupertino</span>, <span class="region">CA</span> <span class="postal-code">95014</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:tpauly@apple.com" class="email">tpauly@apple.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Eric Kinnear</span></div>
<div dir="auto" class="left"><span class="org">Apple Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">One Apple Park Way</span></div>
<div dir="auto" class="left">
<span class="locality">Cupertino</span>, <span class="region">CA</span> <span class="postal-code">95014</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:ekinnear@apple.com" class="email">ekinnear@apple.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">David Schinazi</span></div>
<div dir="auto" class="left"><span class="org">Google LLC</span></div>
<div dir="auto" class="left"><span class="street-address">1600 Amphitheatre Parkway</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>, <span class="region">CA</span> <span class="postal-code">94043</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:dschinazi.ietf@gmail.com" class="email">dschinazi.ietf@gmail.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>