File: rfc9313.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 (3018 lines) | stat: -rw-r--r-- 167,009 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 9313: Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)</title>
<meta content="Gábor Lencse" name="author">
<meta content="Jordi Palet Martinez" name="author">
<meta content="Lee Howard" name="author">
<meta content="Richard Patterson" name="author">
<meta content="Ian Farrer" name="author">
<meta content="
       Several IPv6 transition technologies have been developed to
      provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an
      IPv6-only access and/or core network. These technologies have their
      advantages and disadvantages. Depending on existing topology, skills,
      strategy, and other preferences, one of these technologies may be the
      most appropriate solution for a network operator. 
       This document examines the five most prominent
      IPv4aaS technologies and considers a number of different aspects
      to provide network operators with an easy-to-use reference to assist in
      selecting the technology that best suits their needs. 
    " name="description">
<meta content="xml2rfc 3.15.0" name="generator">
<meta content="IPv6" name="keyword">
<meta content="Transition Technologies" name="keyword">
<meta content="Comparison" name="keyword">
<meta content="IPv4aaS" name="keyword">
<meta content="IPv6-only" name="keyword">
<meta content="464XLAT" name="keyword">
<meta content="DNS64" name="keyword">
<meta content="Dual-Stack Lite" name="keyword">
<meta content="Lightweight 4over6" name="keyword">
<meta content="MAP-E" name="keyword">
<meta content="MAP-T" name="keyword">
<meta content="9313" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.15.0
    Python 3.9.13
    appdirs 1.4.4
    ConfigArgParse 1.5.3
    google-i18n-address 2.5.1
    html5lib 1.1
    intervaltree 3.1.0
    Jinja2 3.1.2
    kitchen 1.2.6
    lxml 4.9.0
    MarkupSafe 2.1.1
    pycountry 22.3.5
    PyYAML 6.0
    requests 2.28.0
    setuptools 44.1.1
    six 1.16.0
    weasyprint 56.1
-->
<link href="rfc9313.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr {
  break-inside: avoid;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9313" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison-04" rel="prev">
  </head>
<body class="xml2rfc">
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9313</td>
<td class="center">Pros and Cons of IPv4aaS Technologies</td>
<td class="right">October 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Lencse, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9313" class="eref">9313</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-10" class="published">October 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">G. Lencse</div>
<div class="org">BUTE</div>
</div>
<div class="author">
      <div class="author-name">J. Palet Martinez</div>
<div class="org">The IPv6 Company</div>
</div>
<div class="author">
      <div class="author-name">L. Howard</div>
<div class="org">Retevia</div>
</div>
<div class="author">
      <div class="author-name">R. Patterson</div>
<div class="org">Sky UK</div>
</div>
<div class="author">
      <div class="author-name">I. Farrer</div>
<div class="org">Deutsche Telekom AG</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9313</h1>
<h1 id="title">Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Several IPv6 transition technologies have been developed to
      provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an
      IPv6-only access and/or core network. These technologies have their
      advantages and disadvantages. Depending on existing topology, skills,
      strategy, and other preferences, one of these technologies may be the
      most appropriate solution for a network operator.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document examines the five most prominent
      IPv4aaS technologies and considers a number of different aspects
      to provide network operators with an easy-to-use reference to assist in
      selecting the technology that best suits their needs.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9313">https://www.rfc-editor.org/info/rfc9313</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="auto internal xref">1</a>.  <a href="#name-introduction" class="internal xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="auto internal xref">2</a>.  <a href="#name-overview-of-the-technologie" class="internal xref">Overview of the Technologies</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="auto internal xref">2.1</a>.  <a href="#name-464xlat" class="internal xref">464XLAT</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="auto internal xref">2.2</a>.  <a href="#name-dual-stack-lite" class="internal xref">Dual-Stack Lite</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="auto internal xref">2.3</a>.  <a href="#name-lightweight-4over6" class="internal xref">Lightweight 4over6</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="auto internal xref">2.4</a>.  <a href="#name-map-e" class="internal xref">MAP-E</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5">
                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="auto internal xref">2.5</a>.  <a href="#name-map-t" class="internal xref">MAP-T</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>.  <a href="#name-high-level-architectures-an" class="internal xref">High-Level Architectures and Their Consequences</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="auto internal xref">3.1</a>.  <a href="#name-service-provider-network-tr" class="internal xref">Service Provider Network Traversal</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>.  <a href="#name-network-address-translation" class="internal xref">Network Address Translation among the Different IPv4aaS Technologies</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="auto internal xref">3.3</a>.  <a href="#name-ipv4-address-sharing" class="internal xref">IPv4 Address Sharing</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="auto internal xref">3.4</a>.  <a href="#name-ipv4-pool-size-consideratio" class="internal xref">IPv4 Pool Size Considerations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="auto internal xref">3.5</a>.  <a href="#name-ce-provisioning-considerati" class="internal xref">CE Provisioning Considerations</a></p>
</li>
              <li class="compact toc ulBare 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="auto internal xref">3.6</a>.  <a href="#name-support-for-multicast" class="internal xref">Support for Multicast</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>.  <a href="#name-detailed-analysis" class="internal xref">Detailed Analysis</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="auto internal xref">4.1</a>.  <a href="#name-architectural-differences" class="internal xref">Architectural Differences</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1.2.1">
                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="auto internal xref">4.1.1</a>.  <a href="#name-basic-comparison" class="internal xref">Basic Comparison</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="auto internal xref">4.2</a>.  <a href="#name-trade-off-between-port-numb" class="internal xref">Trade-Off between Port Number Efficiency and Stateless Operation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="auto internal xref">4.3</a>.  <a href="#name-support-for-public-server-o" class="internal xref">Support for Public Server Operation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="auto internal xref">4.4</a>.  <a href="#name-support-and-implementations" class="internal xref">Support and Implementations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.1">
                    <p id="section-toc.1-1.4.2.4.2.1.1"><a href="#section-4.4.1" class="auto internal xref">4.4.1</a>.  <a href="#name-vendor-support" class="internal xref">Vendor Support</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.2">
                    <p id="section-toc.1-1.4.2.4.2.2.1"><a href="#section-4.4.2" class="auto internal xref">4.4.2</a>.  <a href="#name-support-in-cellular-and-bro" class="internal xref">Support in Cellular and Broadband Networks</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.3">
                    <p id="section-toc.1-1.4.2.4.2.3.1"><a href="#section-4.4.3" class="auto internal xref">4.4.3</a>.  <a href="#name-implementation-code-sizes" class="internal xref">Implementation Code Sizes</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="auto internal xref">4.5</a>.  <a href="#name-typical-deployment-and-traf" class="internal xref">Typical Deployment and Traffic Volume Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.1">
                    <p id="section-toc.1-1.4.2.5.2.1.1"><a href="#section-4.5.1" class="auto internal xref">4.5.1</a>.  <a href="#name-deployment-possibilities" class="internal xref">Deployment Possibilities</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.2">
                    <p id="section-toc.1-1.4.2.5.2.2.1"><a href="#section-4.5.2" class="auto internal xref">4.5.2</a>.  <a href="#name-cellular-networks-with-464x" class="internal xref">Cellular Networks with 464XLAT</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.3">
                    <p id="section-toc.1-1.4.2.5.2.3.1"><a href="#section-4.5.3" class="auto internal xref">4.5.3</a>.  <a href="#name-wireline-networks-with-464x" class="internal xref">Wireline Networks with 464XLAT</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="auto internal xref">4.6</a>.  <a href="#name-load-sharing" class="internal xref">Load Sharing</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="auto internal xref">4.7</a>.  <a href="#name-logging" class="internal xref">Logging</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.8">
                <p id="section-toc.1-1.4.2.8.1"><a href="#section-4.8" class="auto internal xref">4.8</a>.  <a href="#name-optimization-for-ipv4-only-" class="internal xref">Optimization for IPv4-Only Devices and Applications</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>.  <a href="#name-performance-comparison" class="internal xref">Performance Comparison</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="auto internal xref">6</a>.  <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref">7</a>.  <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="auto internal xref">8</a>.  <a href="#name-references" class="internal 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="auto internal xref">8.1</a>.  <a href="#name-normative-references" class="internal 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="auto internal xref">8.2</a>.  <a href="#name-informative-references" class="internal 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="auto internal xref"></a><a href="#name-acknowledgements" class="internal xref">Acknowledgements</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="auto internal xref"></a><a href="#name-authors-addresses" class="internal xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">As the deployment of IPv6 continues to be prevalent, it becomes clearer
      that network operators will move to building single-stack IPv6 core
      and access networks to simplify network planning and operations.
      However, providing customers with IPv4 services continues to be a
      requirement for the foreseeable future. To meet this need, the IETF
      has standardized a number of different IPv4aaS technologies
      for this (see <span>[<a href="#LEN2019" class="cite xref">LEN2019</a>]</span>) based on differing requirements and
      deployment scenarios.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The number of technologies that have been developed makes it 
   time-consuming for a network operator to identify the most appropriate
      mechanism for their specific deployment. This document provides a
      comparative analysis of the most commonly used mechanisms to assist
      operators with this problem.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Five different IPv4aaS solutions are considered:<a href="#section-1-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1-4">
<li id="section-1-4.1">464XLAT <span>[<a href="#RFC6877" class="cite xref">RFC6877</a>]</span><a href="#section-1-4.1" class="pilcrow">¶</a>
</li>
        <li id="section-1-4.2">Dual-Stack Lite <span>[<a href="#RFC6333" class="cite xref">RFC6333</a>]</span><a href="#section-1-4.2" class="pilcrow">¶</a>
</li>
        <li id="section-1-4.3">Lightweight 4over6 (lw4o6) <span>[<a href="#RFC7596" class="cite xref">RFC7596</a>]</span><a href="#section-1-4.3" class="pilcrow">¶</a>
</li>
        <li id="section-1-4.4">Mapping of Address and Port with Encapsulation (MAP-E) <span>[<a href="#RFC7597" class="cite xref">RFC7597</a>]</span><a href="#section-1-4.4" class="pilcrow">¶</a>
</li>
        <li id="section-1-4.5">Mapping of Address and Port using Translation (MAP-T) <span>[<a href="#RFC7599" class="cite xref">RFC7599</a>]</span><a href="#section-1-4.5" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-1-5">We note that <span>[<a href="#RFC6180" class="cite xref">RFC6180</a>]</span> gives
      guidelines for using IPv6 transition mechanisms during IPv6 deployment;
      that document addresses a much broader topic, whereas this document
      focuses on a small part of it.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="overview">
<section id="section-2">
      <h2 id="name-overview-of-the-technologie">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-overview-of-the-technologie" class="section-name selfRef">Overview of the Technologies</a>
      </h2>
<p id="section-2-1">The following sections introduce the different technologies analyzed
      in this document and describe some of their most important characteristics.<a href="#section-2-1" class="pilcrow">¶</a></p>
<div id="xlat_ov">
<section id="section-2.1">
        <h3 id="name-464xlat">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-464xlat" class="section-name selfRef">464XLAT</a>
        </h3>
<p id="section-2.1-1">464XLAT may use double translation (stateless NAT46 + stateful
        NAT64) or single translation (stateful NAT64) depending on different
        factors, such as the use of DNS by the applications and the
        availability of a DNS64 function (in the host or service
        provider network).<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">The customer-side translator (CLAT) is located in the customer's
        device, and it performs stateless NAT46 translation <span>[<a href="#RFC7915" class="cite xref">RFC7915</a>]</span> (more precisely, a stateless
        IP/ICMP translation from IPv4 to IPv6).  IPv4-embedded IPv6 addresses
        <span>[<a href="#RFC6052" class="cite xref">RFC6052</a>]</span> are used for both source and
        destination addresses. Commonly, a /96 prefix (either the 64:ff9b::/96
        Well-Known Prefix (WKP) or a Network-Specific Prefix) is used as the
        IPv6 destination for the IPv4-embedded client traffic.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">In deployments where NAT64 load balancing (see <span><a href="https://www.rfc-editor.org/rfc/rfc7269#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC7269" class="cite xref">RFC7269</a>]</span>) is enabled, multiple WKPs <span>[<a href="#RFC8215" class="cite xref">RFC8215</a>]</span> may be used.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1-4">In the operator's network, the provider-side translator (PLAT)
        performs stateful NAT64 <span>[<a href="#RFC6146" class="cite xref">RFC6146</a>]</span> to translate the
        traffic. The destination IPv4 address is extracted from the
        IPv4-embedded IPv6 packet destination address, and the source address is
        from a pool of public IPv4 addresses.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<p id="section-2.1-5">Alternatively, when a dedicated /64 is not available for translation,
        the CLAT device uses a stateful NAT44 translation before the stateless
        NAT46 translation.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
<p id="section-2.1-6">In general, keeping state in devices close to the end-user network (i.e., at the CE (Customer Edge) router) is not perceived to be as problematic as keeping state in the operator's network.<a href="#section-2.1-6" class="pilcrow">¶</a></p>
<p id="section-2.1-7">In typical deployments, 464XLAT is used together with DNS64 
 <span>[<a href="#RFC6147" class="cite xref">RFC6147</a>]</span>; see <span><a href="https://www.rfc-editor.org/rfc/rfc8683#section-3.1.2" class="relref">Section 3.1.2</a> of [<a href="#RFC8683" class="cite xref">RFC8683</a>]</span>.
        When an IPv6-only client or application communicates with an IPv4-only
        server, the DNS64 server returns the IPv4-embedded IPv6 address of the
        IPv4-only server. In this case, the IPv6-only client sends out IPv6
        packets, the CLAT functions as an IPv6 router, and the PLAT performs a
        stateful NAT64 for these packets. There is a single
        translation.<a href="#section-2.1-7" class="pilcrow">¶</a></p>
<p id="section-2.1-8">Similarly, when an IPv4-only client or application communicates
        with an IPv4-only server, the CLAT will statelessly translate to IPv6
        so it can traverse the ISP network up to the PLAT (NAT64), which in
        turn will translate to IPv4.<a href="#section-2.1-8" class="pilcrow">¶</a></p>
<p id="section-2.1-9">Alternatively, one can say that DNS64 + stateful NAT64 is
        used to carry the traffic of the IPv6-only client and the IPv4-only
        server, and the CLAT is used only for the IPv4 traffic from applications
        or devices that use literal IPv4 addresses or non-IPv6-compliant APIs.<a href="#section-2.1-9" class="pilcrow">¶</a></p>
<span id="name-overview-of-the-464xlat-arc"></span><div id="xlatarch">
<figure id="figure-1">
          <div class="alignLeft art-text artwork" id="section-2.1-10.1">
<pre>
          Private +----------+ Translated  +----------+     _______
  +------+  IPv4  |   CLAT   |    4-6-4    |   PLAT   |    ( IPv4  )
  | IPv4 |-------&gt;| Stateless|------------&gt;| Stateful +--( Internet )
  |Device|&lt;-------|   NAT46  |&lt;------------|   NAT64  |   (________)
  +------+        +----------+      ^      +----------+
                                    |
                              Operator IPv6
                                Network</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-overview-of-the-464xlat-arc" class="selfRef">Overview of the 464XLAT Architecture</a>
          </figcaption></figure>
</div>
<p id="section-2.1-11">Note: In mobile networks, the CLAT is commonly implemented in the
        user equipment (UE) or smartphone; please refer to Figure 2 in <span>[<a href="#RFC6877" class="cite xref">RFC6877</a>]</span>.<a href="#section-2.1-11" class="pilcrow">¶</a></p>
<p id="section-2.1-12">Some NAT64 vendors support direct communication (that is, without translation) 
 between two CLATs by means of hairpinning through the NAT64.<a href="#section-2.1-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dslite_ov">
<section id="section-2.2">
        <h3 id="name-dual-stack-lite">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-dual-stack-lite" class="section-name selfRef">Dual-Stack Lite</a>
        </h3>
<p id="section-2.2-1">Dual-Stack Lite (DS-Lite) <span>[<a href="#RFC6333" class="cite xref">RFC6333</a>]</span> was the first
        of the considered transition mechanisms to be developed. DS-Lite uses a
        Basic Bridging BroadBand (B4) function in the customer's CE router
        that encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native
        service provider network to an Address Family Transition
        Router (AFTR). The AFTR performs encapsulation/decapsulation of the
        4in6 <span>[<a href="#RFC2473" class="cite xref">RFC2473</a>]</span> traffic and translates the IPv4 source 
 address in the inner IPv4 packet to a public IPv4 source address using 
 a stateful NAPT44 <span>[<a href="#RFC2663" class="cite xref">RFC2663</a>]</span> function.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<span id="name-overview-of-the-ds-lite-arc"></span><div id="dslitearch">
<figure id="figure-2">
          <div class="alignLeft art-text artwork" id="section-2.2-2.1">
<pre>
                                         +-------------+
        Private +----------+ IPv4-in-IPv6|Stateful AFTR|
+------+  IPv4  |    B4    |    Tunnel   |------+------+     _______
| IPv4 |-------&gt;| Encap./  |------------&gt;|Encap.|      |    ( IPv4  )
|Device|&lt;-------|  Decap.  |&lt;------------|  /   | NAPT +--( Internet )
+------+        +----------+      ^      |Decap.|  44  |   (________)
                                  |      +------+------+
                            Operator IPv6
                              Network</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-overview-of-the-ds-lite-arc" class="selfRef">Overview of the DS-Lite Architecture</a>
          </figcaption></figure>
</div>
<p id="section-2.2-3">Some AFTR vendors support direct communication 
 between two B4s by means of hairpinning through the AFTR.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lw4o6_ov">
<section id="section-2.3">
        <h3 id="name-lightweight-4over6">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-lightweight-4over6" class="section-name selfRef">Lightweight 4over6</a>
        </h3>
<p id="section-2.3-1">Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main
        difference is that the stateful NAPT44 function is relocated from the
        centralized AFTR to the customer's B4 element (called an "lwB4"). The
        AFTR (called an "lwAFTR") function therefore only performs A+P
        (Address plus Port) routing <span>[<a href="#RFC6346" class="cite xref">RFC6346</a>]</span> and 4in6
        encapsulation/decapsulation.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">Routing to the correct client and IPv4 address sharing are achieved
        using the A+P model <span>[<a href="#RFC6346" class="cite xref">RFC6346</a>]</span> of
        provisioning each lwB4 with a unique tuple of IPv4 address and a unique range
        of transport-layer ports. The client uses these for NAPT44.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<p id="section-2.3-3">The lwAFTR implements a binding table, which has a per-client
        entry linking the customer's source IPv4 address and an allocated range of
        transport-layer ports to their IPv6 tunnel endpoint address. The binding table
        allows egress traffic from customers to be validated (to prevent 
        spoofing) and ingress traffic to be correctly encapsulated and
        forwarded. As there needs to be a per-client entry, an lwAFTR
        implementation needs to be optimized for performing a per-packet
        lookup on the binding table.<a href="#section-2.3-3" class="pilcrow">¶</a></p>
<p id="section-2.3-4">Direct communication (that is, without translation) between two lwB4s is performed by hairpinning
        traffic through the lwAFTR.<a href="#section-2.3-4" class="pilcrow">¶</a></p>
<span id="name-overview-of-the-lw4o6-archi"></span><div id="lw4o6arch">
<figure id="figure-3">
          <div class="alignLeft art-text artwork" id="section-2.3-5.1">
<pre>
                +-------------+             +----------+
        Private |    lwB4     | IPv4-in-IPv6| Stateless|
+------+  IPv4  |------+------|    Tunnel   |  lwAFTR  |     _______
| IPv4 |-------&gt;|      |Encap.|------------&gt;|(encap/A+P|    ( IPv4  )
|Device|&lt;-------| NAPT |  /   |&lt;------------|bind. tab +--( Internet )
+------+        |  44  |Decap.|      ^      | routing) |   (________)
                +------+------+      |      +----------+
                              Operator IPv6
                                  Network</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-overview-of-the-lw4o6-archi" class="selfRef">Overview of the lw4o6 Architecture</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="map_e_ov">
<section id="section-2.4">
        <h3 id="name-map-e">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-map-e" class="section-name selfRef">MAP-E</a>
        </h3>
<p id="section-2.4-1">Like 464XLAT (<a href="#xlat_ov" class="auto internal xref">Section 2.1</a>), MAP-E and MAP-T use 
 IPv4-embedded IPv6 addresses <span>[<a href="#RFC6052" class="cite xref">RFC6052</a>]</span> to represent IPv4 
 hosts outside the MAP domain.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4-2">MAP-E and MAP-T use a stateless algorithm to embed portions of the customer's
        allocated IPv4 address (or part of an address with A+P routing) into the
        IPv6 prefix delegated to the client. This allows for large numbers of
        clients to be provisioned using a single MAP rule (called a "MAP domain").
        The algorithm also allows direct IPv4 peer-to-peer communication
        between hosts provisioned with common MAP rules.<a href="#section-2.4-2" class="pilcrow">¶</a></p>
<p id="section-2.4-3">The CE router typically performs stateful NAPT44 
        <span>[<a href="#RFC2663" class="cite xref">RFC2663</a>]</span> to translate the private IPv4 source addresses
        and source ports into an address and port range defined by applying
        the MAP rule to the delegated IPv6 prefix. The client
        address/port allocation size is a configuration parameter. The CE router then
        encapsulates the IPv4 packet in an IPv6 packet <span>[<a href="#RFC2473" class="cite xref">RFC2473</a>]</span>
        and sends it directly to another host in the MAP domain
        (for peer-to-peer) or to a Border Router (BR) if the IPv4 destination is
        not covered in one of the CE's MAP rules.<a href="#section-2.4-3" class="pilcrow">¶</a></p>
<p id="section-2.4-4">The MAP BR is provisioned with the set of MAP rules for the MAP
        domains it serves. These rules determine how the MAP BR is to decapsulate
        traffic that it receives from the client, validate the source IPv4
        address and transport-layer ports assigned, and calculate the
        destination IPv6 address for ingress IPv4 traffic.<a href="#section-2.4-4" class="pilcrow">¶</a></p>
<span id="name-overview-of-the-map-e-archi"></span><div id="map-e-arch">
<figure id="figure-4">
          <div class="alignLeft art-text artwork" id="section-2.4-5.1">
<pre>
                +-------------+             +----------+
        Private |   MAP CE    | IPv4-in-IPv6| Stateless|
+------+  IPv4  |------+------|    tunnel   |  MAP BR  |     _______
| IPv4 |-------&gt;|      |Encap.|------------&gt;|(encap/A+P|    ( IPv4  )
|Device|&lt;-------| NAPT |  /   |&lt;------------|algorithm +--( Internet )
+------+        |  44  |Decap.|      ^      | routing) |   (________)
                +------+------+      |      +----------+
                              Operator IPv6
                                  Network</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-overview-of-the-map-e-archi" class="selfRef">Overview of the MAP-E Architecture</a>
          </figcaption></figure>
</div>
<p id="section-2.4-6">Some BR vendors support direct communication 
 between two MAP CEs by means of hairpinning through the BR.<a href="#section-2.4-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="map_t_ov">
<section id="section-2.5">
        <h3 id="name-map-t">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-map-t" class="section-name selfRef">MAP-T</a>
        </h3>
<p id="section-2.5-1">MAP-T uses the same mapping algorithm as MAP-E. The major difference
        is that double stateless translation (NAT46 in the CE and NAT64 in the
        BR) is used to traverse the ISP's IPv6 single-stack network. MAP-T can
        also be compared to 464XLAT when there is a double translation.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
<p id="section-2.5-2">A MAP CE router typically performs stateful NAPT44 to translate traffic to a public
        IPv4 address and port range calculated by applying the provisioned 
        Basic MAP Rule (BMR), which is a set of inputs to the algorithm, to the delegated
        IPv6 prefix. The CE then performs stateless translation from IPv4 to
        IPv6 <span>[<a href="#RFC7915" class="cite xref">RFC7915</a>]</span>.
   The MAP BR is
   provisioned with the same BMR as the client, enabling the received
   IPv6 traffic to be translated (using stateless NAT64) back to the public
   IPv4 source address used by the client.<a href="#section-2.5-2" class="pilcrow">¶</a></p>
<p id="section-2.5-3">Using translation instead of encapsulation also allows IPv4-only
        nodes to correspond directly with IPv6 nodes in the MAP-T domain
        that have IPv4-embedded IPv6 addresses.<a href="#section-2.5-3" class="pilcrow">¶</a></p>
<span id="name-overview-of-the-map-t-archi"></span><div id="map-t-arch">
<figure id="figure-5">
          <div class="alignLeft art-text artwork" id="section-2.5-4.1">
<pre>
                +-------------+             +----------+
        Private |   MAP CE    |  Translated | Stateless|
+------+  IPv4  |------+------|    4-6-4    |  MAP BR  |     _______
| IPv4 |-------&gt;|      |State-|------------&gt;|(NAT64/A+P|    ( IPv4  )
|Device|&lt;-------| NAPT | less |&lt;------------|algorithm +--( Internet )
+------+        |  44  |NAT46 |      ^      | routing) |   (________)
                +------+------+      |      +----------+
                              Operator IPv6
                                  Network</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-overview-of-the-map-t-archi" class="selfRef">Overview of the MAP-T Architecture</a>
          </figcaption></figure>
</div>
<p id="section-2.5-5">Some BR vendors support direct communication 
 between two MAP CEs by means of hairpinning through the BR.<a href="#section-2.5-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="hl_arch">
<section id="section-3">
      <h2 id="name-high-level-architectures-an">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-high-level-architectures-an" class="section-name selfRef">High-Level Architectures and Their Consequences</a>
      </h2>
<div id="sp_net_trav">
<section id="section-3.1">
        <h3 id="name-service-provider-network-tr">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-service-provider-network-tr" class="section-name selfRef">Service Provider Network Traversal</a>
        </h3>
<p id="section-3.1-1">For the data plane, there are two approaches for traversing
        the IPv6 provider network:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1-2.1">4-6-4 translation<a href="#section-3.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-2.2">4in6 encapsulation<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<span id="name-available-traversal-mechani"></span><div id="net_trav_table">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-available-traversal-mechani" class="selfRef">Available Traversal Mechanisms</a>
          </caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1"></th>
              <th class="text-center" rowspan="1" colspan="1">464XLAT</th>
              <th class="text-center" rowspan="1" colspan="1">DS-Lite</th>
              <th class="text-center" rowspan="1" colspan="1">lw4o6</th>
              <th class="text-center" rowspan="1" colspan="1">MAP-E</th>
              <th class="text-center" rowspan="1" colspan="1">MAP-T</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4-6-4 translation</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4in6 encapsulation</td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1"></td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.1-4">In the scope of this document, all of the encapsulation-based
        mechanisms use IP-in-IP tunneling <span>[<a href="#RFC2473" class="cite xref">RFC2473</a>]</span>.
        This is a stateless tunneling mechanism that does not require any
        additional overhead.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">It should be noted that both of these approaches result in an
        increase in the size of the packet that needs to be transported across
        the operator's network when compared to native IPv4. 4-6-4
        translation adds a 20-byte overhead (the 20-byte IPv4 header is
        replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte
        overhead (an IPv6 header is prepended to the IPv4 header).<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">The increase in packet size can become a significant problem if there
        is a link with a smaller MTU in the traffic path. This may result in the need for
        traffic to be fragmented at the ingress point to the IPv6 only
        domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may also
        result in the need to implement buffering and fragment reassembly
        in the PLAT/AFTR/lwAFTR/BR node.<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<p id="section-3.1-7">The advice given in <span><a href="https://www.rfc-editor.org/rfc/rfc7597#section-8.3.1" class="relref">Section 8.3.1</a> of [<a href="#RFC7597" class="cite xref">RFC7597</a>]</span> is applicable to all of these mechanisms: 

 It is
        strongly recommended that the MTU in the IPv6-only domain be well
        managed (it should have sufficiently large MTU to support tunneling
        and/or translation) and that the IPv6 MTU on the CE WAN-side interface
        be set so that no fragmentation occurs within the boundary of the
        IPv6-only domain.<a href="#section-3.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nat">
<section id="section-3.2">
        <h3 id="name-network-address-translation">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-network-address-translation" class="section-name selfRef">Network Address Translation among the Different IPv4aaS Technologies</a>
        </h3>
<p id="section-3.2-1">
  For the high-level solution of IPv6 service provider network traversal,
  MAP-T uses double stateless translation. The first translation is from IPv4
  to IPv6 (NAT46) at the CE, and the second translation is from IPv6 to IPv4
  (NAT64) at the service provider network.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">464XLAT may use double translation (stateless NAT46 + stateful
        NAT64) or single translation (stateful NAT64) depending on different
        factors, such as the use of DNS by the applications and the availability
        of a DNS64 function (in the host or in the service provider network).
        For deployment guidelines, please refer to <span>[<a href="#RFC8683" class="cite xref">RFC8683</a>]</span>.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">The first step for the double translation mechanisms is a stateless
        NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP
        Translation Algorithm) <span>[<a href="#RFC7915" class="cite xref">RFC7915</a>]</span>,
        which does not translate IPv4 header options and/or multicast IP/ICMP
        packets. With encapsulation-based technologies, the header is
        transported intact, and multicast can also be carried.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">Single and double translation results in native IPv6 traffic with a
        transport-layer next header. The fields in these headers can be used
        for functions such as hashing across equal-cost multipaths or Access
        Control List (ACL) filtering. Encapsulation technologies, in contrast,
        may hinder hashing algorithms or other functions relying on header
        inspection.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">Solutions using double translation can only carry port-aware IP
        protocols (e.g., TCP and UDP) and ICMP when they are used with IPv4
        address sharing (please refer to <a href="#pub_serv" class="auto internal xref">Section 4.3</a> for more details).  Encapsulation-based solutions
        can also carry any other protocols over IP.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6">An in-depth analysis of stateful NAT64 can be found in <span>[<a href="#RFC6889" class="cite xref">RFC6889</a>]</span>.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.2-7">As stateful NAT interferes with the port numbers, <span>[<a href="#I-D.ietf-tsvwg-natsupp" class="cite xref">NAT-SUPP</a>]</span> explains how NATs
        can handle SCTP (Stream Control Transmission Protocol).<a href="#section-3.2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ipv4_sharing">
<section id="section-3.3">
        <h3 id="name-ipv4-address-sharing">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-ipv4-address-sharing" class="section-name selfRef">IPv4 Address Sharing</a>
        </h3>
<p id="section-3.3-1">As public IPv4 address exhaustion is a common motivation for
        deploying IPv6, transition technologies need to provide a solution that
        allows public IPv4 address sharing.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">In order to fulfill this requirement, a stateful NAPT function is
        a necessary function in all of the mechanisms. The major differentiator
        is where in the architecture this function is located.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">The solutions compared by this document fall into two categories:<a href="#section-3.3-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.3-4.1">Approaches based on Carrier-Grade NAT (CGN) (DS-Lite, 464XLAT)<a href="#section-3.3-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-4.2">Approaches based on A+P (lw4o6, MAP-E, MAP-T)<a href="#section-3.3-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.3-5">In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs
        the NAPT44 function and maintains per-session state for all of the
        active client's traffic. The customer's device does not require 
        per-session state for NAPT.<a href="#section-3.3-5" class="pilcrow">¶</a></p>
<p id="section-3.3-6">In the A+P-based model, a device (usually a CE) performs stateful
        NAPT44 and maintains per-session state only for co-located devices,
        e.g., in the customer's home network. Here, the centralized network
        function (lwAFTR or BR) only needs to perform stateless
        encapsulation/decapsulation or NAT64.<a href="#section-3.3-6" class="pilcrow">¶</a></p>
<p id="section-3.3-7">Issues related to IPv4 address-sharing mechanisms are described 
        in <span>[<a href="#RFC6269" class="cite xref">RFC6269</a>]</span> and should also be considered.<a href="#section-3.3-7" class="pilcrow">¶</a></p>
<p id="section-3.3-8">The address-sharing efficiency of the five technologies is
        significantly different and is discussed in 
        <a href="#port_num_eff" class="auto internal xref">Section 4.2</a>.<a href="#section-3.3-8" class="pilcrow">¶</a></p>
<p id="section-3.3-9">Lw4o6, MAP-E, and MAP-T can also be configured without IPv4 address sharing;
        see the details in <a href="#pub_serv" class="auto internal xref">Section 4.3</a>. However, in that case, there is no advantage in
        terms of public IPv4 address saving.
 In the case of 464XLAT, one-to-one mapping can also
        be achieved through EAMT (Explicit Address Mapping Table)
        <span>[<a href="#RFC7757" class="cite xref">RFC7757</a>]</span>.<a href="#section-3.3-9" class="pilcrow">¶</a></p>
<p id="section-3.3-10">Conversely, both MAP-E and MAP-T may be configured to provide more
        than one public IPv4 address (i.e., an address with an IPv4 prefix shorter than a /32)
        to customers.<a href="#section-3.3-10" class="pilcrow">¶</a></p>
<p id="section-3.3-11">Dynamic DNS issues in address-sharing contexts and their possible
 solutions using PCP (Port Control Protocol) are discussed in detail 
 in <span>[<a href="#RFC7393" class="cite xref">RFC7393</a>]</span>.<a href="#section-3.3-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ipv4_pool">
<section id="section-3.4">
        <h3 id="name-ipv4-pool-size-consideratio">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-ipv4-pool-size-consideratio" class="section-name selfRef">IPv4 Pool Size Considerations</a>
        </h3>
<p id="section-3.4-1">In this section, we do some simple calculations regarding port
        numbers. However, technical limitations are not the only point to
        consider for port sharing; there are also local regulations and
        best current practices.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">Note: By "port numbers", we mean TCP/UDP port numbers or ICMP
        identifiers.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<p id="section-3.4-3">In most networks, it is possible to use existing data about flows to
   Content Delivery Networks (CDNs), caches, or other well-known
   IPv6-enabled destinations to calculate the percentage of traffic that
   would turn into IPv6 if IPv6 is enabled on that network or on part of it.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<p id="section-3.4-4">Knowing that, it is possible to calculate the IPv4 pool size
        required for a given number of subscribers, depending on the IPv4aaS
        technology being used.<a href="#section-3.4-4" class="pilcrow">¶</a></p>
<p id="section-3.4-5">According to <span>[<a href="#MIY2010" class="cite xref">MIY2010</a>]</span>, each
        user device (computer, tablet, smartphone) behind a NAT could
        simultaneously use up to 300 ports.  (Table 1 of <span>[<a href="#MIY2010" class="cite xref">MIY2010</a>]</span> lists the port number usage of
        various applications. According to <span>[<a href="#REP2014" class="cite xref">REP2014</a>]</span>, the downloading of some web pages may consume up to
        200 port numbers.) If the extended NAPT algorithm is used, which
        includes the full 5-tuple into the connection tracking table, then
        the port numbers are reused when the destinations are
        different. Therefore, we need to consider the number of "port-hungry"
        applications that are accessing the same destination simultaneously.
        We estimate that in the case of a residential subscriber, there will
        be typically no more than four port-hungry applications communicating
        with the same destination simultaneously, which is a total of 1,200
        ports.<a href="#section-3.4-5" class="pilcrow">¶</a></p>
<p id="section-3.4-6">For example, if 80% of the traffic is expected towards IPv6
        destinations, only 20% will actually be using IPv4 ports. Thus, in our
        example, 240 ports are required for each subscriber.<a href="#section-3.4-6" class="pilcrow">¶</a></p>
<p id="section-3.4-7">From the 65,535 ports available per IPv4 address, we could even
   consider reserving 1,024 ports for customers that need
   EAMT entries for incoming connections to System ports (0-1023, also
   called "well-known ports") <span>[<a href="#RFC7605" class="cite xref">RFC7605</a>]</span>.
        This means that 64,511 ports are actually available for each IPv4 address.<a href="#section-3.4-7" class="pilcrow">¶</a></p>
<p id="section-3.4-8">According to this, a /22 (1.024 public IPv4 addresses) will be sufficient 
 for over 275,000 subscribers (1,024x64,511/240=275,246.93).<a href="#section-3.4-8" class="pilcrow">¶</a></p>
<p id="section-3.4-9">Similarly, a /18 (16,384 public IPv4 addresses) will be sufficient
        for over 4,403,940 subscribers, and so on.<a href="#section-3.4-9" class="pilcrow">¶</a></p>
<p id="section-3.4-10">This is a conservative approach, which is valid in the case of
        464XLAT because ports are assigned dynamically by the NAT64. Therefore, it is
        not necessary to consider if one user is actually using more or fewer
        ports; average values work well.<a href="#section-3.4-10" class="pilcrow">¶</a></p>
<p id="section-3.4-11">As the deployment of IPv6 progresses, the use of NAT64, and
        therefore of public IPv4 addresses, decreases (more IPv6 ports, fewer
        IPv4 ports). Thus, either more subscribers can be accommodated with the
        same number of IPv4 addresses or some of those addressed can be
        retired from the NAT64.<a href="#section-3.4-11" class="pilcrow">¶</a></p>
<p id="section-3.4-12">For comparison, if dual-stack is being used, any given number of
        users will require the same number of public IPv4 addresses. For
        instance, a /14 will provide 262,144 IPv4 public addresses for 262,144
        subscribers, versus 275,000 subscribers being served with only a
        /22.<a href="#section-3.4-12" class="pilcrow">¶</a></p>
<p id="section-3.4-13">In the other IPv4aaS technologies, this calculation will only match
        if the assignment of ports per subscriber can be done dynamically,
        which is not always the case (depending on the vendor
        implementation).<a href="#section-3.4-13" class="pilcrow">¶</a></p>
<p id="section-3.4-14">  When dynamic assignment of addresses is not possible, an
  alternative approximation for the other IPv4aaS technologies must ensure a
  sufficient number of ports per subscriber.
 That means 1,200 ports, and
        typically, it comes to 2,000 ports in many deployments.
   In that case, assuming 80% is IPv6 traffic (as above), only 30 subscribers
   will be allowed per each IPv4 address; thus, the closer approximation to
   275,000 subscribers per our example with 464XLAT (with a /22) will be using
   a /19, which serves 245,760 subscribers (a /19 has 8,192 addresses and 30
   subscribers with 2,000 ports each per address).<a href="#section-3.4-14" class="pilcrow">¶</a></p>
<p id="section-3.4-15">If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, MAP-E,
        and MAP-T) make use of a 5-tuple for tracking the NAT connections, the
        number of ports required per subscriber can be limited as low as four
        ports per subscriber.  However, the practical limit depends on the
        desired limit for parallel connections that any single host behind the
        NAT can have to the same address and port in Internet. Note that it is
        becoming more common that applications use AJAX (Asynchronous
        JavaScript and XML) and similar mechanisms, so taking that extreme
        limit is probably not a safe choice.<a href="#section-3.4-15" class="pilcrow">¶</a></p>
<p id="section-3.4-16">This feature of extremely reduced number of ports could also be used in 
 case the CLAT-enabled CE with 464XLAT makes use of tracking the 5-tuple NAT 
 connections and could also be further extended 
 if the NAT64 also uses the 5-tuple.<a href="#section-3.4-16" class="pilcrow">¶</a></p>
<p id="section-3.4-17">Please also refer to <span>[<a href="#RFC6888" class="cite xref">RFC6888</a>]</span> for in-depth information about 
 the requirements for sizing CGN gateways.<a href="#section-3.4-17" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ce_prov">
<section id="section-3.5">
        <h3 id="name-ce-provisioning-considerati">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-ce-provisioning-considerati" class="section-name selfRef">CE Provisioning Considerations</a>
        </h3>
<p id="section-3.5-1">All of the technologies require some provisioning of customer
        devices. The table below shows which methods currently have
        extensions for provisioning the different mechanisms.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<span id="name-available-provisioning-mech"></span><div id="prov_mech_table">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-available-provisioning-mech" class="selfRef">Available Provisioning Mechanisms</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Provisioning Method</th>
              <th class="text-center" rowspan="1" colspan="1">464XLAT</th>
              <th class="text-center" rowspan="1" colspan="1">DS-Lite</th>
              <th class="text-center" rowspan="1" colspan="1">lw4o6</th>
              <th class="text-center" rowspan="1" colspan="1">MAP-E</th>
              <th class="text-center" rowspan="1" colspan="1">MAP-T</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DHCPv6 <span>[<a href="#RFC8415" class="cite xref">RFC8415</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">RADIUS <span>[<a href="#RFC8658" class="cite xref">RFC8658</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1">
                <span>[<a href="#RFC6519" class="cite xref">RFC6519</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">TR-069 <span>[<a href="#TR-069" class="cite xref">TR-069</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1">*</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">*</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DNS64 <span>[<a href="#RFC7050" class="cite xref">RFC7050</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">YANG <span>[<a href="#RFC7950" class="cite xref">RFC7950</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1">
                <span>[<a href="#RFC8512" class="cite xref">RFC8512</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1">
                <span>[<a href="#RFC8513" class="cite xref">RFC8513</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1">
                <span>[<a href="#RFC8676" class="cite xref">RFC8676</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1">
                <span>[<a href="#RFC8676" class="cite xref">RFC8676</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1">
                <span>[<a href="#RFC8676" class="cite xref">RFC8676</a>]</span>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DHCP 4o6 <span>[<a href="#RFC7341" class="cite xref">RFC7341</a>]</span>
</td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1"></td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1">X</td>
              <td class="text-center" rowspan="1" colspan="1"></td>
            </tr>
          </tbody>
        </table>
</div>
<span class="break"></span><dl class="dlParallel" id="section-3.5-3">
          <dt id="section-3.5-3.1">*:</dt>
          <dd style="margin-left: 1.5em" id="section-3.5-3.2">Work started at Broadband Forum (2021)<a href="#section-3.5-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.5-3.3">X:</dt>
          <dd style="margin-left: 1.5em" id="section-3.5-3.4">Supported by the provisioning method<a href="#section-3.5-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="multicast">
<section id="section-3.6">
        <h3 id="name-support-for-multicast">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-support-for-multicast" class="section-name selfRef">Support for Multicast</a>
        </h3>
<p id="section-3.6-1">The solutions covered in this document are all intended for
        unicast traffic. <span>[<a href="#RFC8114" class="cite xref">RFC8114</a>]</span> describes a method for
        carrying encapsulated IPv4 multicast traffic over an IPv6 multicast
        network. This could be deployed in parallel to any of the operator's
        chosen IPv4aaS mechanism.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-4">
      <h2 id="name-detailed-analysis">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-detailed-analysis" class="section-name selfRef">Detailed Analysis</a>
      </h2>
<section id="section-4.1">
        <h3 id="name-architectural-differences">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-architectural-differences" class="section-name selfRef">Architectural Differences</a>
        </h3>
<section id="section-4.1.1">
          <h4 id="name-basic-comparison">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-basic-comparison" class="section-name selfRef">Basic Comparison</a>
          </h4>
<p id="section-4.1.1-1">The five IPv4aaS technologies can be classified
          based on two aspects:<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1.1-2.1">Technology used for service provider network traversal. 
            It can be single/double translation or encapsulation.<a href="#section-4.1.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.1.1-2.2">Presence or absence of per-flow state in the
            operator network.<a href="#section-4.1.1-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<span id="name-basic-comparison-among-the-"></span><div id="data_plane_table">
<table class="center" id="table-3">
            <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-basic-comparison-among-the-" class="selfRef">Basic Comparison among the Analyzed Technologies</a>
            </caption>
<thead>
              <tr>
                <th class="text-center" rowspan="1" colspan="1"></th>
                <th class="text-center" rowspan="1" colspan="1">464XLAT</th>
                <th class="text-center" rowspan="1" colspan="1">DS-Lite</th>
                <th class="text-center" rowspan="1" colspan="1">lw4o6</th>
                <th class="text-center" rowspan="1" colspan="1">MAP-E</th>
                <th class="text-center" rowspan="1" colspan="1">MAP-T</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Translation (T) or Encapsulation (E) </td>
                <td class="text-center" rowspan="1" colspan="1">T</td>
                <td class="text-center" rowspan="1" colspan="1">E</td>
                <td class="text-center" rowspan="1" colspan="1">E</td>
                <td class="text-center" rowspan="1" colspan="1">E</td>
                <td class="text-center" rowspan="1" colspan="1">T</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"> Presence (+) of Per-Flow State in Operator Network</td>
                <td class="text-center" rowspan="1" colspan="1">+</td>
                <td class="text-center" rowspan="1" colspan="1">+</td>
                <td class="text-center" rowspan="1" colspan="1"></td>
                <td class="text-center" rowspan="1" colspan="1"></td>
                <td class="text-center" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</section>
<div id="port_num_eff">
<section id="section-4.2">
        <h3 id="name-trade-off-between-port-numb">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-trade-off-between-port-numb" class="section-name selfRef">Trade-Off between Port Number Efficiency and Stateless Operation</a>
        </h3>
<p id="section-4.2-1">464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices,
      respectively. This may cause scalability issues for the number of clients
      or volume of traffic, but it does not impose a limitation 
      on the number of ports per user, as they can be allocated dynamically 
      on-demand and the allocation policy can be centrally managed and adjusted.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">A+P-based mechanisms (lw4o6, MAP-E, and MAP-T) avoid using NAPT in the
      service provider network. However, this means that the number of ports
      provided to each user (and hence the effective IPv4 address-sharing ratio)
      must be pre-provisioned to the client.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">Changing the allocated port ranges with A+P-based
      technologies requires more planning and is likely to involve
      reprovisioning both hosts and operator-side equipment. It should be
      noted that due to the per-customer binding table entry used
      by lw4o6, a single customer can be reprovisioned (e.g., if they
      request a full IPv4 address) without needing to change parameters for a
      number of customers as in a MAP domain.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">It is also worth noting that there is a direct relationship between
      the efficiency of public port allocations for customers and the corresponding
      logging overhead that may be necessary to meet data-retention
      requirements. This is considered in <a href="#logging" class="auto internal xref">Section 4.7</a>.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">Determining the optimal number of ports for a fixed port set is not
        an easy task and may also be impacted by local regulatory law (and in
        the Belgian case, it is not a law but more a memorandum of
        understanding or best current practice), which may define a maximum
        number of users per IP address and consequently a minimum number of
        ports per user.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<p id="section-4.2-6">On the one hand, the "lack of ports" situation may cause serious
      problems in the operation of certain applications. For example, Miyakawa
      has demonstrated the consequences of the session number limitation due
      to port number shortage in the example of Google Maps 
      <span>[<a href="#MIY2010" class="cite xref">MIY2010</a>]</span>. When the limit was 15, several blocks of the
      map were missing, and the map was unusable. This study also provided
      several examples for the session numbers of different applications
      (the highest one was Apple's iTunes at 230-270 ports).<a href="#section-4.2-6" class="pilcrow">¶</a></p>
<p id="section-4.2-7">The port number consumption of different applications is highly
        varying. In the case of web browsing, it depends on several
        factors, including the choice of the web page, the web browser, and
        sometimes the operating system <span>[<a href="#REP2014" class="cite xref">REP2014</a>]</span>. For example, under certain conditions, 120-160
        ports were used (URL: sohu.com, browser: Firefox under Ubuntu Linux),
        and in some other cases, only 3-12 ports were used (URL: twitter.com,
        browser: Iceweasel under Debian Linux).<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<p id="section-4.2-8">There may be several users behind a CE router, especially in the
      broadband case (e.g., Internet is used by different members of a family
      simultaneously), so sufficient ports must be allocated to avoid
      impacting user experience.<a href="#section-4.2-8" class="pilcrow">¶</a></p>
<p id="section-4.2-9">In general, assigning too few source port numbers to an end user may 
   result in unexpected and hard-to-debug consequences; therefore, if the 
   number of ports per end user is fixed, then we recommend assigning a 
   conservatively large number of ports. For example, the developers of Jool used 
   2048 ports per user in their example for MAP-T <span>[<a href="#JOOL-MAPT" class="cite xref">JOOL-MAPT</a>]</span>.<a href="#section-4.2-9" class="pilcrow">¶</a></p>
<p id="section-4.2-10">However, assigning too many ports per CE router
      will result in waste of public IPv4 addresses, which are scarce and
      expensive resources. Clearly, this is a big advantage in the case of 464XLAT 
      where they are dynamically managed so that the number of IPv4 addresses 
      for the sharing pool is smaller while the availability of ports per user 
      doesn't need to be pre-defined and is not a limitation.<a href="#section-4.2-10" class="pilcrow">¶</a></p>
<p id="section-4.2-11">There is a direct trade-off between the optimization of client
      port allocations and the associated logging overhead. 
      <a href="#logging" class="auto internal xref">Section 4.7</a> discusses this in more depth.<a href="#section-4.2-11" class="pilcrow">¶</a></p>
<p id="section-4.2-12"> We note that common NAT44 implementations utilizing Netfilter at the
      CE router multiplex active sessions using a 3-tuple (source address,
      destination address, and destination port).  This means that external
      source ports can be reused for unique internal source and destination
      addresses and port sessions. It is also noted that Netfilter cannot
      currently make use of multiple source port ranges (i.e., several blocks
      of ports distributed across the total port space as is common in MAP
      deployments).  This may influence the design when using stateless
      technologies.<a href="#section-4.2-12" class="pilcrow">¶</a></p>
<p id="section-4.2-13">Stateful technologies, 464XLAT, DS-Lite, and NAT444 can
      therefore be much more efficient in terms of port allocation and thus
      public IP address saving. The price is the stateful operation in the
      service provider network, which allegedly does not scale up well.
      It should be noted that, in many cases, all those factors may depend on
      how it is actually implemented.<a href="#section-4.2-13" class="pilcrow">¶</a></p>
<p id="section-4.2-14">Measurements have been started to examine the scalability of a few 
   stateful solutions in two areas:<a href="#section-4.2-14" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2-15.1">How their performance scales up with the number of CPU cores<a href="#section-4.2-15.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-15.2">To what extent their performance degrades with the number of 
 concurrent connections<a href="#section-4.2-15.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.2-16">
      The details of the measurements and their results are available from 
      <span>[<a href="#I-D.lencse-v6ops-transition-scalability" class="cite xref">IPv4aaS-SCALE-TECH</a>]</span>.<a href="#section-4.2-16" class="pilcrow">¶</a></p>
<p id="section-4.2-17">We note that some CGN-type solutions can allocate ports dynamically
      "on the fly". Depending on configuration, this can result in the same
      customer being allocated ports from different source addresses. This can
      cause operational issues for protocols and applications that expect
      multiple flows to be sourced from the same address (e.g., ECMP hashing,
      STUN, gaming, and content delivery networks). However, it should be noted
      that this is the same problem when a network has a NAT44 with multiple
      public IPv4 addresses, or even when applications in a dual-stack case,
      behave wrongly if Happy Eyeballs is flapping the flow address between
      IPv4 and IPv6.<a href="#section-4.2-17" class="pilcrow">¶</a></p>
<p id="section-4.2-18">The consequences of IPv4 address sharing <span>[<a href="#RFC6269" class="cite xref">RFC6269</a>]</span> may
      impact all five technologies. However, when ports are allocated
      statically, more customers may get ports from the same public IPv4
      address, which may result in negative consequences with higher
      probability. For example, many applications and service providers (Sony
      PlayStation Network, OpenDNS, etc.) can permanently block IPv4 ranges
      if they detect that they are used for address sharing.<a href="#section-4.2-18" class="pilcrow">¶</a></p>
<p id="section-4.2-19">Both cases are, again, implementation-dependent.<a href="#section-4.2-19" class="pilcrow">¶</a></p>
<p id="section-4.2-20">We note that although it is not of typical use, one can do
      deterministic, stateful NAT and reserve a fixed set of ports for each
      customer as well.<a href="#section-4.2-20" class="pilcrow">¶</a></p>
</section>
</div>
<div id="pub_serv">
<section id="section-4.3">
        <h3 id="name-support-for-public-server-o">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-support-for-public-server-o" class="section-name selfRef">Support for Public Server Operation</a>
        </h3>
<p id="section-4.3-1">Mechanisms that rely on operator-side per-flow state do not, by
      themselves, offer a way for customers to present services on publicly
      accessible transport-layer ports.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">The Port Control Protocol (PCP) <span>[<a href="#RFC6887" class="cite xref">RFC6887</a>]</span> provides a
      mechanism for a client to request an external public port from a CGN
      device. For server operation, it is required with 464XLAT/NAT64, and 
   it is supported in some DS-Lite AFTR implementations.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">A+P-based mechanisms distribute a public IPv4 address and
        restricted range of transport-layer ports to the client. In this case,
        it is possible for the user to configure their device to offer a
        publicly accessible server on one of their allocated ports. It should
        be noted that operators commonly do not assign the well-known ports to
        users (unless they are allocating a full IPv4 address), so the user
        will need to run the service on an allocated port or configure port
        translation.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<p id="section-4.3-4">Lw4o6, MAP-E, and MAP-T may be configured to allocated clients with 
      a full IPv4 address, allowing exclusive use of all ports and
      non-port-based transport-layer protocols. Thus, they may also be used to support 
      server/services operation on their default ports. However, when public
      IPv4 addresses are assigned to the CE router without address sharing,
      there is obviously no advantage in terms of IPv4 public addresses saving.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<p id="section-4.3-5">It is also possible to configure specific ports mapping in
      464XLAT/NAT64 using EAMT <span>[<a href="#RFC7757" class="cite xref">RFC7757</a>]</span>, which means that only
      those ports are "lost" from the pool of addresses, so there is a higher
      maximization of the total usage of IPv4 port resources.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="supp_imp">
<section id="section-4.4">
        <h3 id="name-support-and-implementations">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-support-and-implementations" class="section-name selfRef">Support and Implementations</a>
        </h3>
<section id="section-4.4.1">
          <h4 id="name-vendor-support">
<a href="#section-4.4.1" class="section-number selfRef">4.4.1. </a><a href="#name-vendor-support" class="section-name selfRef">Vendor Support</a>
          </h4>
<p id="section-4.4.1-1">In general, router vendors support AFTR, MAP-E BR, MAP-T
 BR, and NAT64.  Vendors of load balancers and firewalls usually
 support NAT64 as well while not all of them have support for
 the other protocols.<a href="#section-4.4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.4.1-2">A 464XLAT client (CLAT) is implemented in Windows 10, Linux
          (including Android), Windows Mobile, Chrome OS, and iOS, but it is
          not available in macOS 12.3.1.<a href="#section-4.4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.4.1-3">The remaining four solutions are commonly deployed as functions
          in the CE device only; however, the vendors' support is poor in
          general (except for DS-Lite).<a href="#section-4.4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.4.1-4"> OpenWRT is a Linux-based open-source OS designed for CE devices. It
 offers a number of different 'opkg' packages as part of the distribution:<a href="#section-4.4.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4.1-5.1">'464xlat' enables support for 464XLAT CLAT functionality.<a href="#section-4.4.1-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.4.1-5.2">'ds-lite' enables support for DSLite B4 functionality.<a href="#section-4.4.1-5.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.4.1-5.3">'map' enables support for MAP-E and lw4o6 CE
            functionality.<a href="#section-4.4.1-5.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.4.1-5.4">'map-t' enables support for MAP-T CE functionality.<a href="#section-4.4.1-5.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.4.1-6">At the time of publication, some free open-source implementations 
 exist for the operator-side functionality:<a href="#section-4.4.1-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4.1-7.1">Jool <span>[<a href="#JOOL" class="cite xref">JOOL</a>]</span> (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR)<a href="#section-4.4.1-7.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.4.1-7.2">VPP/fd.io <span>[<a href="#VPP" class="cite xref">VPP</a>]</span> (MAP-BR, lwAFTR, CGN, CLAT, NAT64)<a href="#section-4.4.1-7.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.4.1-7.3">Snabb <span>[<a href="#SNABB" class="cite xref">SNABB</a>]</span> (lwAFTR)<a href="#section-4.4.1-7.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.4.1-7.4">AFTR <span>[<a href="#AFTR" class="cite xref">AFTR</a>]</span> (DSLite AFTR)<a href="#section-4.4.1-7.4" class="pilcrow">¶</a>
</li>
          </ul>
</section>
<div id="cell_broad_supp">
<section id="section-4.4.2">
          <h4 id="name-support-in-cellular-and-bro">
<a href="#section-4.4.2" class="section-number selfRef">4.4.2. </a><a href="#name-support-in-cellular-and-bro" class="section-name selfRef">Support in Cellular and Broadband Networks</a>
          </h4>
<p id="section-4.4.2-1">Several cellular networks use 464XLAT, whereas there are no
        deployments of the four other technologies in cellular networks, as
        they are neither standardized nor implemented in UE devices.<a href="#section-4.4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.4.2-2">In broadband networks, there are some deployments of 464XLAT, MAP-E,
        and MAP-T.
   Lw4o6 and DS-Lite have more deployments, with DS-Lite
   being the most common, but deployments of lw4o6 have been rapidly
   increasing in the last few years.<a href="#section-4.4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.4.2-3">Please refer to Tables 2 and 3 of <span>[<a href="#LEN2019" class="cite xref">LEN2019</a>]</span>
 for a limited set of deployment information.<a href="#section-4.4.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="code_size">
<section id="section-4.4.3">
          <h4 id="name-implementation-code-sizes">
<a href="#section-4.4.3" class="section-number selfRef">4.4.3. </a><a href="#name-implementation-code-sizes" class="section-name selfRef">Implementation Code Sizes</a>
          </h4>
<p id="section-4.4.3-1">As a hint to the relative complexity of the mechanisms, the
        code sizes reported from the OpenWRT
        implementations of each technology are 17 kB, 35 kB, 15 kB, 35 kB, and
        48 kB for 464XLAT, lw4o6,
        DS-Lite, MAP-E, and MAP-T, respectively
        (see <span>&lt;<a href="https://openwrt.org/packages/start">https://openwrt.org/packages/start</a>&gt;</span>).<a href="#section-4.4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.4.3-2">We note that the support for all five technologies requires a much
        smaller code size than the total sum of the above quantities, because
        they contain a lot of common functions (e.g., data plane is shared among
        several of them).<a href="#section-4.4.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-4.5">
        <h3 id="name-typical-deployment-and-traf">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-typical-deployment-and-traf" class="section-name selfRef">Typical Deployment and Traffic Volume Considerations</a>
        </h3>
<section id="section-4.5.1">
          <h4 id="name-deployment-possibilities">
<a href="#section-4.5.1" class="section-number selfRef">4.5.1. </a><a href="#name-deployment-possibilities" class="section-name selfRef">Deployment Possibilities</a>
          </h4>
<p id="section-4.5.1-1">Theoretically, all five IPv4aaS technologies could be
        used together with DNS64 + stateful NAT64, as is done in 464XLAT.
        In this case, the CE router would treat the traffic between an
        IPv6-only client and IPv4-only server as normal IPv6 traffic, and
        the stateful NAT64 gateway would do a single translation, thus
        offloading this kind of traffic from the IPv4aaS technology. The
        cost of this solution would be the need to also deploy DNS64 +
        stateful NAT64.<a href="#section-4.5.1-1" class="pilcrow">¶</a></p>
<p id="section-4.5.1-2">However, this has not been implemented in clients or actual
        deployments, so only 464XLAT always uses this optimization, and the
        other four solutions do not use it at all.<a href="#section-4.5.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.5.2">
          <h4 id="name-cellular-networks-with-464x">
<a href="#section-4.5.2" class="section-number selfRef">4.5.2. </a><a href="#name-cellular-networks-with-464x" class="section-name selfRef">Cellular Networks with 464XLAT</a>
          </h4>
<p id="section-4.5.2-1">Figures from existing deployments (through the end of 2018) show
          the typical traffic volumes in an IPv6-only cellular network when
          464XLAT technology is used together with DNS64:<a href="#section-4.5.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5.2-2.1">75% of traffic is IPv6 end-to-end (no translation).<a href="#section-4.5.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.5.2-2.2">24% of traffic uses DNS64 + NAT64 (one translation).<a href="#section-4.5.2-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.5.2-2.3">Less than 1% of traffic uses the CLAT in addition to NAT64
          (two translations), due to an IPv4 socket and/or IPv4 literal.<a href="#section-4.5.2-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.5.2-3">Without using DNS64, 25% of the traffic would undergo double
        translation.<a href="#section-4.5.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-4.5.3">
          <h4 id="name-wireline-networks-with-464x">
<a href="#section-4.5.3" class="section-number selfRef">4.5.3. </a><a href="#name-wireline-networks-with-464x" class="section-name selfRef">Wireline Networks with 464XLAT</a>
          </h4>
<p id="section-4.5.3-1"> Figures from several existing deployments (through the end of
          2020), mainly with residential customers, show the ranges of typical
          traffic volumes in an IPv6-only network, when 464XLAT is used with
          DNS64:<a href="#section-4.5.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5.3-2.1">65%-85% of traffic is IPv6 end-to-end (no translation).<a href="#section-4.5.3-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.5.3-2.2">14%-34% of traffic uses DNS64 + NAT64 (one translation).<a href="#section-4.5.3-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.5.3-2.3">Less than 1-2% of traffic uses the CLAT in addition to NAT64
          (two translations), due to an IPv4 socket and/or IPv4 literal.<a href="#section-4.5.3-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.5.3-3">Without using DNS64, 16%-35% of the traffic would undergo double
        translation.<a href="#section-4.5.3-3" class="pilcrow">¶</a></p>
<p id="section-4.5.3-4">
This data is consistent with non-public information of actual deployments,
which can be easily explained.  When a wireline ISP has mainly residential
customers, content providers and CDNs that are already IPv6 enabled
(Google/YouTube, Netflix, Facebook, Akamai, etc.) typically account for 65-85%
of the traffic in the network.  Thus, when the subscribers are IPv6 enabled,
about the same percentage of traffic will become IPv6.<a href="#section-4.5.3-4" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-4.6">
        <h3 id="name-load-sharing">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-load-sharing" class="section-name selfRef">Load Sharing</a>
        </h3>
<p id="section-4.6-1">If multiple network-side devices are needed as PLAT/AFTR/BR for
      capacity, then there is a need for a load-sharing mechanism. ECMP
      (Equal-Cost Multipath) load sharing can be used for all
      technologies; however, stateful technologies will be impacted by
      changes in network topology or device failure.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
<p id="section-4.6-2">Technologies utilizing DNS64 can also distribute load across
      PLAT/AFTR devices, evenly or unevenly, by using different prefixes.
      Different network-specific prefixes can be distributed for
      subscribers in appropriately sized segments (like split-horizon DNS,
      also called "DNS views").<a href="#section-4.6-2" class="pilcrow">¶</a></p>
<p id="section-4.6-3">Stateless technologies, due to the lack of per-flow state, can
      make use of anycast routing for load sharing and resiliency across
      network devices, both ingress and egress; flows can take asymmetric
      paths through the network, i.e., in through one lwAFTR/BR and out
      via another.<a href="#section-4.6-3" class="pilcrow">¶</a></p>
<p id="section-4.6-4">Mechanisms with centralized NAPT44 state have a number of challenges
      specifically related to scaling and resilience. As the total amount of
      client traffic exceeds the capacity of a single CGN instance, additional
      nodes are required to handle the load. Each CGN maintains a
      stateful table of active client sessions, and this table may need to be
      synchronized between CGN instances. This is necessary for two reasons:<a href="#section-4.6-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.6-5.1">To prevent all active customer sessions from being dropped in the event
      of a CGN node failure.<a href="#section-4.6-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.6-5.2">To ensure a matching state table entry for an active session in
      the event of asymmetric routing through different egress and ingress
      CGN nodes.<a href="#section-4.6-5.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
<div id="logging">
<section id="section-4.7">
        <h3 id="name-logging">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-logging" class="section-name selfRef">Logging</a>
        </h3>
<p id="section-4.7-1">In the case of 464XLAT and DS-Lite, the user of any given public
      IPv4 address and port combination will vary over time; therefore,
      logging is necessary to meet data-retention laws. Each entry in the
      PLAT/AFTR generates a logging entry. As discussed in 
      <a href="#port_num_eff" class="auto internal xref">Section 4.2</a>, a client may open hundreds of sessions
      during common tasks such as web browsing, each of which needs to be
      logged so the overall logging burden on the network operator is
      significant. In some countries, this level of logging is required to comply
      with data-retention legislation.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
<p id="section-4.7-2">One common optimization available to reduce the logging overhead
      is the allocation of a block of ports to a client for the duration
      of their session. This means that a logging entry only needs to be
      made when the client's port block is released, which dramatically
      reduces the logging overhead. This comes as the cost of less
      efficient public address sharing as clients need to be allocated a
      port block of a fixed size regardless of the actual number of ports
      that they are using.<a href="#section-4.7-2" class="pilcrow">¶</a></p>
<p id="section-4.7-3">Stateless technologies that pre-allocate the IPv4 addresses and
        ports only require that copies of the active MAP rules (for MAP-E and
        MAP-T) or binding table (for lw4o6) are retained along with timestamp
        information of when they have been active. Support tools (e.g., those
        used to serve data-retention requests) may need to be updated to be
        aware of the mechanism in use (e.g., implementing the MAP algorithm so
        that IPv4 information can be linked to the IPv6 prefix delegated to a
        client).  Stateless technologies do not have a centralized stateful
        element that customer traffic needs to pass through, so if
        data-retention laws mandate per-session logging, there is no simple
        way of meeting this requirement with a stateless technology alone.
        Thus, a centralized NAPT44 model may be the only way to meet this
        requirement.<a href="#section-4.7-3" class="pilcrow">¶</a></p>
<p id="section-4.7-4">Deterministic CGN <span>[<a href="#RFC7422" class="cite xref">RFC7422</a>]</span> was proposed as a solution to 
   reduce the resource consumption of logging.<a href="#section-4.7-4" class="pilcrow">¶</a></p>
<p id="section-4.7-5">Please also refer to <span><a href="https://www.rfc-editor.org/rfc/rfc6888#section-4" class="relref">Section 4</a> of [<a href="#RFC6888" class="cite xref">RFC6888</a>]</span> for more information about 
   requirements for logging CGN gateways.<a href="#section-4.7-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="optimization">
<section id="section-4.8">
        <h3 id="name-optimization-for-ipv4-only-">
<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-optimization-for-ipv4-only-" class="section-name selfRef">Optimization for IPv4-Only Devices and Applications</a>
        </h3>
<p id="section-4.8-1">When IPv4-only devices or applications are behind a CE connected with 
      IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily be 
      encapsulated/decapsulated (in the case of DS-Lite, lw4o6, and MAP-E) 
      and will reach the IPv4 address of the destination, even if that 
      service supports dual-stack. This means that the traffic flow will 
      cross through the AFTR, lwAFTR, or BR, depending on the specific 
      transition mechanism being used.<a href="#section-4.8-1" class="pilcrow">¶</a></p>
<p id="section-4.8-2">Even if those services are directly connected to the operator network 
   (e.g., CDNs and caches) or located internally (such as VoIP, etc.), 
   it is not possible to avoid that overhead.<a href="#section-4.8-2" class="pilcrow">¶</a></p>
<p id="section-4.8-3">However, in the case of those mechanisms that use a NAT46 function, in the CE (464XLAT and MAP-T), it is possible to take
        advantage of optimization functionalities, such as the ones described
        in <span>[<a href="#I-D.ietf-v6ops-464xlat-optimization" class="cite xref">OP-464XLAT/MAP-T</a>]</span>.<a href="#section-4.8-3" class="pilcrow">¶</a></p>
<p id="section-4.8-4">
   Because the NAT46 has already translated
   the IPv4-only flow to IPv6 and the services are dual-stack, using these
   optimizations allows the services to
   be reached without the need to translate the flow back to IPv4.<a href="#section-4.8-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<div id="performance">
<section id="section-5">
      <h2 id="name-performance-comparison">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-performance-comparison" class="section-name selfRef">Performance Comparison</a>
      </h2>
<p id="section-5-1">We plan to compare the performances of the most prominent free software 
  implementations of the five IPv6 transition technologies using the 
  methodology described in "Benchmarking Methodology for IPv6 Transition 
  Technologies" <span>[<a href="#RFC8219" class="cite xref">RFC8219</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">The dual Device Under Test (DUT) setup of <span>[<a href="#RFC8219" class="cite xref">RFC8219</a>]</span> makes it possible to use the existing measurement devices compliant with
  "Benchmarking Methodology for Network Interconnect Devices" 
  <span>[<a href="#RFC2544" class="cite xref">RFC2544</a>]</span>; however, 
  this solution has two kinds of limitations:<a href="#section-5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-3.1">Dual DUT setup has the drawback that the performances of the CE 
 and the ISP-side device (e.g., the CLAT and PLAT of 464XLAT) 
 are measured together. In order to measure the performance of 
 only one of them, we need to ensure that the desired one is the 
 bottleneck.<a href="#section-5-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-3.2">Measurement procedures for Packet Delay Variation (PDV)
 and Inter-Packet Delay Variation (IPDV) measurements are
 missing from the legacy devices, and the old measurement
 procedure for latency has been redefined in <span>[<a href="#RFC8219" class="cite xref">RFC8219</a>]</span>.<a href="#section-5-3.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-4">The single DUT setup of <span>[<a href="#RFC8219" class="cite xref">RFC8219</a>]</span>
      makes it possible to benchmark the selected device separately, but
      either special Tester is required or some trick is needed if we want to
      use legacy Testers.  An example for the latter is our stateless NAT64
      measurements testing Throughput and Frame Loss Rate using a legacy
      commercial Tester <span>[<a href="#LEN2020a" class="cite xref">LEN2020a</a>]</span> that is
      compliant with <span>[<a href="#RFC5180" class="cite xref">RFC5180</a>]</span>.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">Siitperf, a DPDK-based 
  software Tester that is compliant with <span>[<a href="#RFC8219" class="cite xref">RFC8219</a>]</span> and used for benchmarking stateless NAT64 gateways, has been 
  developed recently. Siitperf is available from GitHub 
  <span>[<a href="#SIITPERF" class="cite xref">SIITPERF</a>]</span> as free software and is documented in 
  <span>[<a href="#LEN2021" class="cite xref">LEN2021</a>]</span>. Originally, it literally followed the test 
  frame format of <span>[<a href="#RFC2544" class="cite xref">RFC2544</a>]</span>, including "hard-wired" source and 
  destination port numbers, and then it was complemented with the 
  pseudorandom port feature required by <span>[<a href="#RFC4814" class="cite xref">RFC4814</a>]</span>. The new 
  version is documented in <span>[<a href="#LEN2020b" class="cite xref">LEN2020b</a>]</span>.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">Further DPDK-based software Testers that are compliant with <span>[<a href="#RFC8219" class="cite xref">RFC8219</a>]</span>
  are being developed at the Budapest University of Technology and 
  Economics as student projects. They are planned to be released as free 
  software, too.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">Information about the benchmarking tools, measurements, and results will
  be made available in <span>[<a href="#I-D.lencse-v6ops-transition-benchmarking" class="cite xref">IPv4aaS-BENCHMARK-TECH</a>]</span>.<a href="#section-5-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-6-1">This document has no IANA actions.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">As discussed in <a href="#logging" class="auto internal xref">Section 4.7</a>, the different technologies have varying 
  logging capabilities and limitations. Care should be taken when storing, 
  transmitting, and providing access to log entries that may be considered 
  personally identifiable information. However, it should be noted that 
  those issues are not specific to the IPv4aaS IPv6 transition technologies
  but apply to logging functionalities in general.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">For all five technologies, the CE device typically contains a DNS proxy.
     However, the user may change DNS settings. If this happens and lw4o6, MAP-E,
     and MAP-T are used with a significantly restricted port set (which is
     required for efficient public IPv4 address sharing), the entropy of the
     source ports is significantly lowered (e.g., from 16 bits to 10 bits when
     1024 port numbers are assigned to each subscriber), and these
     technologies are thus theoretically less resilient against cache poisoning (see
     <span>[<a href="#RFC5452" class="cite xref">RFC5452</a>]</span>). However, an efficient cache poisoning attack
     requires that the subscriber operates its own caching DNS server and the
     attack is performed in the service provider network. Thus, we consider the
     chance of the successful exploitation of this vulnerability to be low.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">IPv4aaS technologies based on encapsulation have no DNSSEC
      implications.  However, those based on translation may have implications
      as discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc8683#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC8683" class="cite xref">RFC8683</a>]</span>.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">An in-depth security analysis of all five IPv6 transition technologies
     and their most prominent free software implementations according to the
     methodology defined in <span>[<a href="#LEN2018" class="cite xref">LEN2018</a>]</span> is planned.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">As the first step, an initial security analysis of 464XLAT was 
  done in <span>[<a href="#AZZ2021" class="cite xref">AZZ2021</a>]</span>.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">The implementers of any of the five IPv4aaS solutions should consult the 
  Security Considerations of the respective RFCs documenting them.<a href="#section-7-6" class="pilcrow">¶</a></p>
</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="RFC2473">[RFC2473]</dt>
        <dd>
<span class="refAuthor">Conta, A.</span> and <span class="refAuthor">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="RFC2544">[RFC2544]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span> and <span class="refAuthor">J. McQuaid</span>, <span class="refTitle">"Benchmarking Methodology for Network Interconnect Devices"</span>, <span class="seriesInfo">RFC 2544</span>, <span class="seriesInfo">DOI 10.17487/RFC2544</span>, <time datetime="1999-03" class="refDate">March 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2544">https://www.rfc-editor.org/info/rfc2544</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2663">[RFC2663]</dt>
        <dd>
<span class="refAuthor">Srisuresh, P.</span> and <span class="refAuthor">M. Holdrege</span>, <span class="refTitle">"IP Network Address Translator (NAT) Terminology and Considerations"</span>, <span class="seriesInfo">RFC 2663</span>, <span class="seriesInfo">DOI 10.17487/RFC2663</span>, <time datetime="1999-08" class="refDate">August 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2663">https://www.rfc-editor.org/info/rfc2663</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4814">[RFC4814]</dt>
        <dd>
<span class="refAuthor">Newman, D.</span> and <span class="refAuthor">T. Player</span>, <span class="refTitle">"Hash and Stuffing: Overlooked Factors in Network Device Benchmarking"</span>, <span class="seriesInfo">RFC 4814</span>, <span class="seriesInfo">DOI 10.17487/RFC4814</span>, <time datetime="2007-03" class="refDate">March 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4814">https://www.rfc-editor.org/info/rfc4814</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5180">[RFC5180]</dt>
        <dd>
<span class="refAuthor">Popoviciu, C.</span>, <span class="refAuthor">Hamza, A.</span>, <span class="refAuthor">Van de Velde, G.</span>, and <span class="refAuthor">D. Dugatkin</span>, <span class="refTitle">"IPv6 Benchmarking Methodology for Network Interconnect Devices"</span>, <span class="seriesInfo">RFC 5180</span>, <span class="seriesInfo">DOI 10.17487/RFC5180</span>, <time datetime="2008-05" class="refDate">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5180">https://www.rfc-editor.org/info/rfc5180</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5452">[RFC5452]</dt>
        <dd>
<span class="refAuthor">Hubert, A.</span> and <span class="refAuthor">R. van Mook</span>, <span class="refTitle">"Measures for Making DNS More Resilient against Forged Answers"</span>, <span class="seriesInfo">RFC 5452</span>, <span class="seriesInfo">DOI 10.17487/RFC5452</span>, <time datetime="2009-01" class="refDate">January 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5452">https://www.rfc-editor.org/info/rfc5452</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6052">[RFC6052]</dt>
        <dd>
<span class="refAuthor">Bao, C.</span>, <span class="refAuthor">Huitema, C.</span>, <span class="refAuthor">Bagnulo, M.</span>, <span class="refAuthor">Boucadair, M.</span>, and <span class="refAuthor">X. Li</span>, <span class="refTitle">"IPv6 Addressing of IPv4/IPv6 Translators"</span>, <span class="seriesInfo">RFC 6052</span>, <span class="seriesInfo">DOI 10.17487/RFC6052</span>, <time datetime="2010-10" class="refDate">October 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6052">https://www.rfc-editor.org/info/rfc6052</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6146">[RFC6146]</dt>
        <dd>
<span class="refAuthor">Bagnulo, M.</span>, <span class="refAuthor">Matthews, P.</span>, and <span class="refAuthor">I. van Beijnum</span>, <span class="refTitle">"Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"</span>, <span class="seriesInfo">RFC 6146</span>, <span class="seriesInfo">DOI 10.17487/RFC6146</span>, <time datetime="2011-04" class="refDate">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6146">https://www.rfc-editor.org/info/rfc6146</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6147">[RFC6147]</dt>
        <dd>
<span class="refAuthor">Bagnulo, M.</span>, <span class="refAuthor">Sullivan, A.</span>, <span class="refAuthor">Matthews, P.</span>, and <span class="refAuthor">I. van Beijnum</span>, <span class="refTitle">"DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers"</span>, <span class="seriesInfo">RFC 6147</span>, <span class="seriesInfo">DOI 10.17487/RFC6147</span>, <time datetime="2011-04" class="refDate">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6147">https://www.rfc-editor.org/info/rfc6147</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6180">[RFC6180]</dt>
        <dd>
<span class="refAuthor">Arkko, J.</span> and <span class="refAuthor">F. Baker</span>, <span class="refTitle">"Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment"</span>, <span class="seriesInfo">RFC 6180</span>, <span class="seriesInfo">DOI 10.17487/RFC6180</span>, <time datetime="2011-05" class="refDate">May 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6180">https://www.rfc-editor.org/info/rfc6180</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6269">[RFC6269]</dt>
        <dd>
<span class="refAuthor">Ford, M., Ed.</span>, <span class="refAuthor">Boucadair, M.</span>, <span class="refAuthor">Durand, A.</span>, <span class="refAuthor">Levis, P.</span>, and <span class="refAuthor">P. Roberts</span>, <span class="refTitle">"Issues with IP Address Sharing"</span>, <span class="seriesInfo">RFC 6269</span>, <span class="seriesInfo">DOI 10.17487/RFC6269</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6269">https://www.rfc-editor.org/info/rfc6269</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6333">[RFC6333]</dt>
        <dd>
<span class="refAuthor">Durand, A.</span>, <span class="refAuthor">Droms, R.</span>, <span class="refAuthor">Woodyatt, J.</span>, and <span class="refAuthor">Y. Lee</span>, <span class="refTitle">"Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"</span>, <span class="seriesInfo">RFC 6333</span>, <span class="seriesInfo">DOI 10.17487/RFC6333</span>, <time datetime="2011-08" class="refDate">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6333">https://www.rfc-editor.org/info/rfc6333</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="RFC6519">[RFC6519]</dt>
        <dd>
<span class="refAuthor">Maglione, R.</span> and <span class="refAuthor">A. Durand</span>, <span class="refTitle">"RADIUS Extensions for Dual-Stack Lite"</span>, <span class="seriesInfo">RFC 6519</span>, <span class="seriesInfo">DOI 10.17487/RFC6519</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6519">https://www.rfc-editor.org/info/rfc6519</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6877">[RFC6877]</dt>
        <dd>
<span class="refAuthor">Mawatari, M.</span>, <span class="refAuthor">Kawashima, M.</span>, and <span class="refAuthor">C. Byrne</span>, <span class="refTitle">"464XLAT: Combination of Stateful and Stateless Translation"</span>, <span class="seriesInfo">RFC 6877</span>, <span class="seriesInfo">DOI 10.17487/RFC6877</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6877">https://www.rfc-editor.org/info/rfc6877</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6887">[RFC6887]</dt>
        <dd>
<span class="refAuthor">Wing, D., Ed.</span>, <span class="refAuthor">Cheshire, S.</span>, <span class="refAuthor">Boucadair, M.</span>, <span class="refAuthor">Penno, R.</span>, and <span class="refAuthor">P. Selkirk</span>, <span class="refTitle">"Port Control Protocol (PCP)"</span>, <span class="seriesInfo">RFC 6887</span>, <span class="seriesInfo">DOI 10.17487/RFC6887</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6887">https://www.rfc-editor.org/info/rfc6887</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>, and <span class="refAuthor">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="RFC6889">[RFC6889]</dt>
        <dd>
<span class="refAuthor">Penno, R.</span>, <span class="refAuthor">Saxena, T.</span>, <span class="refAuthor">Boucadair, M.</span>, and <span class="refAuthor">S. Sivakumar</span>, <span class="refTitle">"Analysis of Stateful 64 Translation"</span>, <span class="seriesInfo">RFC 6889</span>, <span class="seriesInfo">DOI 10.17487/RFC6889</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6889">https://www.rfc-editor.org/info/rfc6889</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7050">[RFC7050]</dt>
        <dd>
<span class="refAuthor">Savolainen, T.</span>, <span class="refAuthor">Korhonen, J.</span>, and <span class="refAuthor">D. Wing</span>, <span class="refTitle">"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"</span>, <span class="seriesInfo">RFC 7050</span>, <span class="seriesInfo">DOI 10.17487/RFC7050</span>, <time datetime="2013-11" class="refDate">November 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7050">https://www.rfc-editor.org/info/rfc7050</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7269">[RFC7269]</dt>
        <dd>
<span class="refAuthor">Chen, G.</span>, <span class="refAuthor">Cao, Z.</span>, <span class="refAuthor">Xie, C.</span>, and <span class="refAuthor">D. Binet</span>, <span class="refTitle">"NAT64 Deployment Options and Experience"</span>, <span class="seriesInfo">RFC 7269</span>, <span class="seriesInfo">DOI 10.17487/RFC7269</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7269">https://www.rfc-editor.org/info/rfc7269</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7341">[RFC7341]</dt>
        <dd>
<span class="refAuthor">Sun, Q.</span>, <span class="refAuthor">Cui, Y.</span>, <span class="refAuthor">Siodelski, M.</span>, <span class="refAuthor">Krishnan, S.</span>, and <span class="refAuthor">I. Farrer</span>, <span class="refTitle">"DHCPv4-over-DHCPv6 (DHCP 4o6) Transport"</span>, <span class="seriesInfo">RFC 7341</span>, <span class="seriesInfo">DOI 10.17487/RFC7341</span>, <time datetime="2014-08" class="refDate">August 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7341">https://www.rfc-editor.org/info/rfc7341</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7393">[RFC7393]</dt>
        <dd>
<span class="refAuthor">Deng, X.</span>, <span class="refAuthor">Boucadair, M.</span>, <span class="refAuthor">Zhao, Q.</span>, <span class="refAuthor">Huang, J.</span>, and <span class="refAuthor">C. Zhou</span>, <span class="refTitle">"Using the Port Control Protocol (PCP) to Update Dynamic DNS"</span>, <span class="seriesInfo">RFC 7393</span>, <span class="seriesInfo">DOI 10.17487/RFC7393</span>, <time datetime="2014-11" class="refDate">November 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7393">https://www.rfc-editor.org/info/rfc7393</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7422">[RFC7422]</dt>
        <dd>
<span class="refAuthor">Donley, C.</span>, <span class="refAuthor">Grundemann, C.</span>, <span class="refAuthor">Sarawat, V.</span>, <span class="refAuthor">Sundaresan, K.</span>, and <span class="refAuthor">O. Vautrin</span>, <span class="refTitle">"Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments"</span>, <span class="seriesInfo">RFC 7422</span>, <span class="seriesInfo">DOI 10.17487/RFC7422</span>, <time datetime="2014-12" class="refDate">December 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7422">https://www.rfc-editor.org/info/rfc7422</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7596">[RFC7596]</dt>
        <dd>
<span class="refAuthor">Cui, Y.</span>, <span class="refAuthor">Sun, Q.</span>, <span class="refAuthor">Boucadair, M.</span>, <span class="refAuthor">Tsou, T.</span>, <span class="refAuthor">Lee, Y.</span>, and <span class="refAuthor">I. Farrer</span>, <span class="refTitle">"Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture"</span>, <span class="seriesInfo">RFC 7596</span>, <span class="seriesInfo">DOI 10.17487/RFC7596</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7596">https://www.rfc-editor.org/info/rfc7596</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7597">[RFC7597]</dt>
        <dd>
<span class="refAuthor">Troan, O., Ed.</span>, <span class="refAuthor">Dec, W.</span>, <span class="refAuthor">Li, X.</span>, <span class="refAuthor">Bao, C.</span>, <span class="refAuthor">Matsushima, S.</span>, <span class="refAuthor">Murakami, T.</span>, and <span class="refAuthor">T. Taylor, Ed.</span>, <span class="refTitle">"Mapping of Address and Port with Encapsulation (MAP-E)"</span>, <span class="seriesInfo">RFC 7597</span>, <span class="seriesInfo">DOI 10.17487/RFC7597</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7597">https://www.rfc-editor.org/info/rfc7597</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7599">[RFC7599]</dt>
        <dd>
<span class="refAuthor">Li, X.</span>, <span class="refAuthor">Bao, C.</span>, <span class="refAuthor">Dec, W., Ed.</span>, <span class="refAuthor">Troan, O.</span>, <span class="refAuthor">Matsushima, S.</span>, and <span class="refAuthor">T. Murakami</span>, <span class="refTitle">"Mapping of Address and Port using Translation (MAP-T)"</span>, <span class="seriesInfo">RFC 7599</span>, <span class="seriesInfo">DOI 10.17487/RFC7599</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7599">https://www.rfc-editor.org/info/rfc7599</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7605">[RFC7605]</dt>
        <dd>
<span class="refAuthor">Touch, J.</span>, <span class="refTitle">"Recommendations on Using Assigned Transport Port Numbers"</span>, <span class="seriesInfo">BCP 165</span>, <span class="seriesInfo">RFC 7605</span>, <span class="seriesInfo">DOI 10.17487/RFC7605</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7605">https://www.rfc-editor.org/info/rfc7605</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7757">[RFC7757]</dt>
        <dd>
<span class="refAuthor">Anderson, T.</span> and <span class="refAuthor">A. Leiva Popper</span>, <span class="refTitle">"Explicit Address Mappings for Stateless IP/ICMP Translation"</span>, <span class="seriesInfo">RFC 7757</span>, <span class="seriesInfo">DOI 10.17487/RFC7757</span>, <time datetime="2016-02" class="refDate">February 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7757">https://www.rfc-editor.org/info/rfc7757</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7915">[RFC7915]</dt>
        <dd>
<span class="refAuthor">Bao, C.</span>, <span class="refAuthor">Li, X.</span>, <span class="refAuthor">Baker, F.</span>, <span class="refAuthor">Anderson, T.</span>, and <span class="refAuthor">F. Gont</span>, <span class="refTitle">"IP/ICMP Translation Algorithm"</span>, <span class="seriesInfo">RFC 7915</span>, <span class="seriesInfo">DOI 10.17487/RFC7915</span>, <time datetime="2016-06" class="refDate">June 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7915">https://www.rfc-editor.org/info/rfc7915</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7950">[RFC7950]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refTitle">"The YANG 1.1 Data Modeling Language"</span>, <span class="seriesInfo">RFC 7950</span>, <span class="seriesInfo">DOI 10.17487/RFC7950</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7950">https://www.rfc-editor.org/info/rfc7950</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8114">[RFC8114]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span>, <span class="refAuthor">Qin, C.</span>, <span class="refAuthor">Jacquenet, C.</span>, <span class="refAuthor">Lee, Y.</span>, and <span class="refAuthor">Q. Wang</span>, <span class="refTitle">"Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network"</span>, <span class="seriesInfo">RFC 8114</span>, <span class="seriesInfo">DOI 10.17487/RFC8114</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8114">https://www.rfc-editor.org/info/rfc8114</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8215">[RFC8215]</dt>
        <dd>
<span class="refAuthor">Anderson, T.</span>, <span class="refTitle">"Local-Use IPv4/IPv6 Translation Prefix"</span>, <span class="seriesInfo">RFC 8215</span>, <span class="seriesInfo">DOI 10.17487/RFC8215</span>, <time datetime="2017-08" class="refDate">August 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8215">https://www.rfc-editor.org/info/rfc8215</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8219">[RFC8219]</dt>
        <dd>
<span class="refAuthor">Georgescu, M.</span>, <span class="refAuthor">Pislaru, L.</span>, and <span class="refAuthor">G. Lencse</span>, <span class="refTitle">"Benchmarking Methodology for IPv6 Transition Technologies"</span>, <span class="seriesInfo">RFC 8219</span>, <span class="seriesInfo">DOI 10.17487/RFC8219</span>, <time datetime="2017-08" class="refDate">August 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8219">https://www.rfc-editor.org/info/rfc8219</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8415">[RFC8415]</dt>
        <dd>
<span class="refAuthor">Mrugalski, T.</span>, <span class="refAuthor">Siodelski, M.</span>, <span class="refAuthor">Volz, B.</span>, <span class="refAuthor">Yourtchenko, A.</span>, <span class="refAuthor">Richardson, M.</span>, <span class="refAuthor">Jiang, S.</span>, <span class="refAuthor">Lemon, T.</span>, and <span class="refAuthor">T. Winters</span>, <span class="refTitle">"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"</span>, <span class="seriesInfo">RFC 8415</span>, <span class="seriesInfo">DOI 10.17487/RFC8415</span>, <time datetime="2018-11" class="refDate">November 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8415">https://www.rfc-editor.org/info/rfc8415</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8512">[RFC8512]</dt>
        <dd>
<span class="refAuthor">Boucadair, M., Ed.</span>, <span class="refAuthor">Sivakumar, S.</span>, <span class="refAuthor">Jacquenet, C.</span>, <span class="refAuthor">Vinapamula, S.</span>, and <span class="refAuthor">Q. Wu</span>, <span class="refTitle">"A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)"</span>, <span class="seriesInfo">RFC 8512</span>, <span class="seriesInfo">DOI 10.17487/RFC8512</span>, <time datetime="2019-01" class="refDate">January 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8512">https://www.rfc-editor.org/info/rfc8512</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8513">[RFC8513]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span>, <span class="refAuthor">Jacquenet, C.</span>, and <span class="refAuthor">S. Sivakumar</span>, <span class="refTitle">"A YANG Data Model for Dual-Stack Lite (DS-Lite)"</span>, <span class="seriesInfo">RFC 8513</span>, <span class="seriesInfo">DOI 10.17487/RFC8513</span>, <time datetime="2019-01" class="refDate">January 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8513">https://www.rfc-editor.org/info/rfc8513</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8658">[RFC8658]</dt>
        <dd>
<span class="refAuthor">Jiang, S., Ed.</span>, <span class="refAuthor">Fu, Y., Ed.</span>, <span class="refAuthor">Xie, C.</span>, <span class="refAuthor">Li, T.</span>, and <span class="refAuthor">M. Boucadair, Ed.</span>, <span class="refTitle">"RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)"</span>, <span class="seriesInfo">RFC 8658</span>, <span class="seriesInfo">DOI 10.17487/RFC8658</span>, <time datetime="2019-11" class="refDate">November 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8658">https://www.rfc-editor.org/info/rfc8658</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8676">[RFC8676]</dt>
        <dd>
<span class="refAuthor">Farrer, I., Ed.</span> and <span class="refAuthor">M. Boucadair, Ed.</span>, <span class="refTitle">"YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires"</span>, <span class="seriesInfo">RFC 8676</span>, <span class="seriesInfo">DOI 10.17487/RFC8676</span>, <time datetime="2019-11" class="refDate">November 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8676">https://www.rfc-editor.org/info/rfc8676</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8683">[RFC8683]</dt>
      <dd>
<span class="refAuthor">Palet Martinez, J.</span>, <span class="refTitle">"Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks"</span>, <span class="seriesInfo">RFC 8683</span>, <span class="seriesInfo">DOI 10.17487/RFC8683</span>, <time datetime="2019-11" class="refDate">November 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8683">https://www.rfc-editor.org/info/rfc8683</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="AFTR">[AFTR]</dt>
        <dd>
<span class="refAuthor">ISC</span>, <span class="refTitle">"ISC Implementation of AFTR"</span>, <span>&lt;<a href="https://downloads.isc.org/isc/aftr/">https://downloads.isc.org/isc/aftr/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="AZZ2021">[AZZ2021]</dt>
        <dd>
<span class="refAuthor">Al-Azzawi, A.</span> and <span class="refAuthor">G. Lencse</span>, <span class="refTitle">"Identification of the Possible Security Issues of the 464XLAT IPv6 Transition Technology"</span>, <span class="refContent">Infocommunications Journal, Vol. 13, No. 4, pp. 10-18</span>, <span class="seriesInfo">DOI 10.36244/ICJ.2021.4.2</span>, <time datetime="2021-12" class="refDate">December 2021</time>, <span>&lt;<a href="https://www.infocommunications.hu/2021_4_2">https://www.infocommunications.hu/2021_4_2</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.lencse-v6ops-transition-benchmarking">[IPv4aaS-BENCHMARK-TECH]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span>, <span class="refTitle">"Performance Analysis of IPv6 Transition Technologies for IPv4aaS"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-lencse-v6ops-transition-benchmarking-01</span>, <time datetime="2022-05-02" class="refDate">2 May 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-benchmarking-01">https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-benchmarking-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.lencse-v6ops-transition-scalability">[IPv4aaS-SCALE-TECH]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span>, <span class="refTitle">"Scalability of IPv6 Transition Technologies for IPv4aaS"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-lencse-v6ops-transition-scalability-03</span>, <time datetime="2022-06-30" class="refDate">30 June 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-scalability-03">https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-scalability-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="JOOL">[JOOL]</dt>
        <dd>
<span class="refTitle">"Jool: SIIT &amp; NAT64"</span>, <span>&lt;<a href="http://www.jool.mx">http://www.jool.mx</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="JOOL-MAPT">[JOOL-MAPT]</dt>
        <dd>
<span class="refTitle">"MAP-T Run"</span>, <span>&lt;<a href="https://www.jool.mx/en/run-mapt.html">https://www.jool.mx/en/run-mapt.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="LEN2018">[LEN2018]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span> and <span class="refAuthor">Y. Kadobayashi</span>, <span class="refTitle">"Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64"</span>, <span class="refContent">Computers &amp; Security, Vol. 77, No. 1, pp. 397-411</span>, <span class="seriesInfo">DOI 10.1016/j.cose.2018.04.012</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="http://www.hit.bme.hu/~lencse/publications/ECS-2018-Methodology-revised.pdf">http://www.hit.bme.hu/~lencse/publications/ECS-2018-Methodology-revised.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="LEN2019">[LEN2019]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span> and <span class="refAuthor">Y. Kadobayashi</span>, <span class="refTitle">"Comprehensive Survey of IPv6 Transition Technologies: A Subjective Classification for Security Analysis"</span>, <span class="refContent">IEICE Transactions on Communications, Vol. E102-B, No. 10, pp. 2021-2035</span>, <span class="seriesInfo">DOI 10.1587/transcom.2018EBR0002</span>, <time datetime="2019-10" class="refDate">October 2019</time>, <span>&lt;<a href="http://www.hit.bme.hu/~lencse/publications/e102-b_10_2021.pdf">http://www.hit.bme.hu/~lencse/publications/e102-b_10_2021.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="LEN2020a">[LEN2020a]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span>, <span class="refTitle">"Benchmarking stateless NAT64 implementations with a standard tester"</span>, <span class="refContent">Telecommunication Systems, Vol. 75, pp. 245-257</span>, <span class="seriesInfo">DOI 10.1007/s11235-020-00681-x</span>, <time datetime="2020-06" class="refDate">June 2020</time>, <span>&lt;<a href="https://link.springer.com/article/10.1007/s11235-020-00681-x">https://link.springer.com/article/10.1007/s11235-020-00681-x</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="LEN2020b">[LEN2020b]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span>, <span class="refTitle">"Adding RFC 4814 Random Port Feature to Siitperf: Design, Implementation and Performance Estimation"</span>, <span class="refContent">International Journal of Advances in Telecommunications, Electrotechnics, Signals and Systems, Vol. 9, No. 3, pp. 18-26</span>, <span class="seriesInfo">DOI 10.11601/ijates.v9i3.291</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://ijates.org/index.php/ijates/article/view/291">https://ijates.org/index.php/ijates/article/view/291</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="LEN2021">[LEN2021]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span>, <span class="refTitle">"Design and Implementation of a Software Tester for Benchmarking Stateless NAT64 Gateways"</span>, <span class="refContent">IEICE Transactions on Communications, Vol. E104.B, Issue 2, pp. 128-140</span>, <span class="seriesInfo">DOI 10.1587/transcom.2019EBN0010</span>, <time datetime="2021" class="refDate">2021</time>, <span>&lt;<a href="https://doi.org/10.1587/transcom.2019EBN0010">https://doi.org/10.1587/transcom.2019EBN0010</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MIY2010">[MIY2010]</dt>
        <dd>
<span class="refAuthor">Miyakawa, S.</span>, <span class="refTitle">"IPv4 to IPv6 Transformation Schemes"</span>, <span class="refContent">IEICE Transactions on Communications, Vol. E93-B, Issue 5, pp. 1078-1084</span>, <span class="seriesInfo">DOI 10.1587/transcom.E93.B.1078</span>, <time datetime="2010" class="refDate">2010</time>, <span>&lt;<a href="https://www.jstage.jst.go.jp/article/transcom/E93.B/5/E93.B_5_1078/_article">https://www.jstage.jst.go.jp/article/transcom/E93.B/5/E93.B_5_1078/_article</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-tsvwg-natsupp">[NAT-SUPP]</dt>
        <dd>
<span class="refAuthor">Stewart, R. R.</span>, <span class="refAuthor">Tüxen, M.</span>, and <span class="refAuthor">I. Ruengeler</span>, <span class="refTitle">"Stream Control Transmission Protocol (SCTP) Network Address Translation Support"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tsvwg-natsupp-23</span>, <time datetime="2021-10-25" class="refDate">25 October 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-natsupp-23">https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-natsupp-23</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-v6ops-464xlat-optimization">[OP-464XLAT/MAP-T]</dt>
        <dd>
<span class="refAuthor">Palet Martinez, J.</span> and <span class="refAuthor">A. D'Egidio</span>, <span class="refTitle">"464XLAT/MAT-T Optimization"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-v6ops-464xlat-optimization-03</span>, <time datetime="2020-07-28" class="refDate">28 July 2020</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03">https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="REP2014">[REP2014]</dt>
        <dd>
<span class="refAuthor">Répás, S.</span>, <span class="refAuthor">Hajas, T.</span>, and <span class="refAuthor">G. Lencse</span>, <span class="refTitle">"Port Number Consumption of the NAT64 IPv6 Transition Technology"</span>, <span class="refContent">37th International Conference on Telecommunications and Signal Processing</span>, <span class="seriesInfo">DOI 10.1109/TSP.2015.7296411</span>, <time datetime="2014" class="refDate">2014</time>, <span>&lt;<a href="http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf">http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SIITPERF">[SIITPERF]</dt>
        <dd>
<span class="refTitle">"Siitperf: an RFC 8219 compliant SIIT (stateless NAT64) tester"</span>, <span class="refContent">commit bdce0f</span>, <time datetime="2021-02" class="refDate">February 2021</time>, <span>&lt;<a href="https://github.com/lencsegabor/siitperf">https://github.com/lencsegabor/siitperf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SNABB">[SNABB]</dt>
        <dd>
<span class="refTitle">"Snabb implementation of lwAFTR"</span>, <span class="refContent">commit 1ef72ce</span>, <time datetime="2022-01" class="refDate">January 2022</time>, <span>&lt;<a href="https://github.com/Igalia/snabb">https://github.com/Igalia/snabb</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="TR-069">[TR-069]</dt>
        <dd>
<span class="refAuthor">Broadband Forum</span>, <span class="refTitle">"CPE WAN Management Protocol"</span>, <span class="seriesInfo">Technical Report TR-069</span>, <time datetime="2020-06" class="refDate">June 2020</time>, <span>&lt;<a href="https://www.broadband-forum.org/technical/download/TR-069.pdf">https://www.broadband-forum.org/technical/download/TR-069.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="VPP">[VPP]</dt>
      <dd>
<span class="refTitle">"VPP"</span>, <time datetime="2022-07" class="refDate">July 2022</time>, <span>&lt;<a href="https://wiki.fd.io/index.php?title=VPP&amp;oldid=11809">https://wiki.fd.io/index.php?title=VPP&amp;oldid=11809</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">The authors would like to thank <span class="contact-name">Ole Troan</span>,
      <span class="contact-name">Warren Kumari</span>, <span class="contact-name">Dan       Romascanu</span>, <span class="contact-name">Brian Trammell</span>, <span class="contact-name">Joseph Salowey</span>, <span class="contact-name">Roman Danyliw</span>,
      <span class="contact-name">Erik Kline</span>, <span class="contact-name">Lars Eggert</span>,
      <span class="contact-name">Zaheduzzaman Sarker</span>, <span class="contact-name">Robert       Wilton</span>, <span class="contact-name">Éric Vyncke</span> and <span class="contact-name">Martin Duke</span> for their review of this document and acknowledge
      the inputs of <span class="contact-name">Mark Andrews</span>, <span class="contact-name">Edwin Cordeiro</span>, <span class="contact-name">Fred Baker</span>, <span class="contact-name">Alexandre Petrescu</span>, <span class="contact-name">Cameron Byrne</span>,
      <span class="contact-name">Tore Anderson</span>, <span class="contact-name">Mikael       Abrahamsson</span>, <span class="contact-name">Gert Doering</span>, <span class="contact-name">Satoru Matsushima</span>, <span class="contact-name">Yutianpeng (Tim)</span>,
      <span class="contact-name">Mohamed Boucadair</span>, <span class="contact-name">Nick       Hilliard</span>, <span class="contact-name">Joel Jaeggli</span>, <span class="contact-name">Kristian McColm</span>, 
      <span class="contact-name">Tom Petch</span>, <span class="contact-name">Yannis       Nikolopoulos</span>, <span class="contact-name">Havard Eidnes</span>, <span class="contact-name">Yann-Ju Chu</span>, <span class="contact-name">Barbara Stark</span>, <span class="contact-name">Vasilenko Eduard</span>, <span class="contact-name">Chongfeng Xie</span>,
      <span class="contact-name">Henri Alves de Godoy</span>, <span class="contact-name">Magnus       Westerlund</span>, <span class="contact-name">Michael Tüxen</span>, <span class="contact-name">Philipp S. Tiesel</span>, <span class="contact-name">Brian E. Carpenter</span>,
      and <span class="contact-name">Joe Touch</span>.<a href="#appendix-A-1" 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">Gábor Lencse</span></div>
<div dir="auto" class="left"><span class="org">Budapest University of Technology and Economics</span></div>
<div dir="auto" class="left"><span class="locality">Budapest</span></div>
<div dir="auto" class="left"><span class="street-address">Magyar tudósok körútja 2</span></div>
<div dir="auto" class="left"><span class="postal-code">H-1117</span></div>
<div dir="auto" class="left"><span class="country-name">Hungary</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:lencse@hit.bme.hu" class="email">lencse@hit.bme.hu</a>
</div>
<div class="url">
<span>URI:</span>
<a href="http://www.hit.bme.hu/~lencse/index_en.htm" class="url">http://www.hit.bme.hu/~lencse/index_en.htm</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jordi Palet Martinez</span></div>
<div dir="auto" class="left"><span class="org">The IPv6 Company</span></div>
<div dir="auto" class="left"><span class="street-address">Molino de la Navata, 75</span></div>
<div dir="auto" class="left">
<span class="postal-code">28420</span> <span class="locality">La Navata - Galapagar</span> <span class="region">Madrid</span>
</div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jordi.palet@theipv6company.com" class="email">jordi.palet@theipv6company.com</a>
</div>
<div class="url">
<span>URI:</span>
<a href="http://www.theipv6company.com/" class="url">http://www.theipv6company.com/</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Lee Howard</span></div>
<div dir="auto" class="left"><span class="org">Retevia</span></div>
<div dir="auto" class="left"><span class="street-address">9940 Main St., Suite 200</span></div>
<div dir="auto" class="left">
<span class="locality">Fairfax</span>, <span class="region">Virginia</span> <span class="postal-code">22031</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:lee@asgard.org" class="email">lee@asgard.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Richard Patterson</span></div>
<div dir="auto" class="left"><span class="org">Sky UK</span></div>
<div dir="auto" class="left"><span class="street-address">1 Brick Lane</span></div>
<div dir="auto" class="left"><span class="locality">London</span></div>
<div dir="auto" class="left"><span class="postal-code">EQ 6PU</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:richard.patterson@sky.uk" class="email">richard.patterson@sky.uk</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ian Farrer</span></div>
<div dir="auto" class="left"><span class="org">Deutsche Telekom AG</span></div>
<div dir="auto" class="left"><span class="street-address">Landgrabenweg 151</span></div>
<div dir="auto" class="left">
<span class="postal-code">53227</span> <span class="locality">Bonn</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ian.farrer@telekom.de" class="email">ian.farrer@telekom.de</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>