File: rfc8683.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 (3464 lines) | stat: -rw-r--r-- 201,813 bytes
parent folder | download | duplicates (2)
<!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 8683: Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks</title>
<meta content="Jordi Palet Martinez" name="author">
<meta content="
       This document describes how Network Address and Protocol 
   Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed 
 in an IPv6 network -- whether it's cellular ISP, broadband ISP, 
 or enterprise -- and the possible
 optimizations.
 This document also discusses issues to be considered when having 
 IPv6-only connectivity, such as:
 a) DNS64, 
 b) applications or devices that use literal IPv4 addresses or 
 non-IPv6-compliant APIs, 
 and c) IPv4-only hosts or applications. 
    " name="description">
<meta content="xml2rfc 2.35.0" name="generator">
<meta content="IPv6" name="keyword">
<meta content="DNSSEC" name="keyword">
<meta content="NAT64" name="keyword">
<meta content="DNS64" name="keyword">
<meta content="464XLAT" name="keyword">
<meta content="CLAT" name="keyword">
<meta content="NAT46" name="keyword">
<meta content="PLAT" name="keyword">
<meta content="8683" name="rfc.number">
<link href="rfc8683.xml" type="application/rfc+xml" rel="alternate">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* 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: 0 0 0.25em 0;
  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;
}
/* 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 {
  .sourcecode {
    margin-bottom: 1em;
  }
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8683" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment-08" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8683</td>
<td class="center">NAT64/464XLAT Deployment</td>
<td class="right">November 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Palet Martinez</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/rfc8683" class="eref">8683</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2019-11" class="published">November 2019</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">J. Palet Martinez</div>
<div class="org">The IPv6 Company</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8683</h1>
<h1 id="title">Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes how Network Address and Protocol 
   Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed 
 in an IPv6 network -- whether it's cellular ISP, broadband ISP, 
 or enterprise -- and the possible
 optimizations.
 This document also discusses issues to be considered when having 
 IPv6-only connectivity, such as:
 a) DNS64, 
 b) applications or devices that use literal IPv4 addresses or 
 non-IPv6-compliant APIs, 
 and c) IPv4-only hosts or applications.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for 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/rfc8683">https://www.rfc-editor.org/info/rfc8683</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) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-nat64-deployment-scenarios" class="xref">NAT64 Deployment Scenarios</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-known-to-work" class="xref">Known to Work</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.1.2.1">
                    <p id="section-toc.1-1.3.2.1.2.1.1"><a href="#section-3.1.1" class="xref">3.1.1</a>.  <a href="#name-service-provider-nat64-with" class="xref">Service Provider NAT64 with DNS64</a><a href="#section-toc.1-1.3.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.3.2.1.2.2">
                    <p id="section-toc.1-1.3.2.1.2.2.1"><a href="#section-3.1.2" class="xref">3.1.2</a>.  <a href="#name-service-provider-offering-4" class="xref">Service Provider Offering 464XLAT Using DNS64</a><a href="#section-toc.1-1.3.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.3.2.1.2.3">
                    <p id="section-toc.1-1.3.2.1.2.3.1"><a href="#section-3.1.3" class="xref">3.1.3</a>.  <a href="#name-service-provider-offering-46" class="xref">Service Provider Offering 464XLAT,     without Using DNS64</a><a href="#section-toc.1-1.3.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-known-to-work-under-special" class="xref">Known to Work under Special Conditions</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-service-provider-nat64-witho" class="xref">Service Provider NAT64 without DNS64</a><a href="#section-toc.1-1.3.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.3.2.2.2.2">
                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="xref">3.2.2</a>.  <a href="#name-service-provider-nat64-dns6" class="xref">Service-Provider NAT64; DNS64 in IPv6 Hosts</a><a href="#section-toc.1-1.3.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.3.2.2.2.3">
                    <p id="section-toc.1-1.3.2.2.2.3.1"><a href="#section-3.2.3" class="xref">3.2.3</a>.  <a href="#name-service-provider-nat64-dns64" class="xref">Service-Provider NAT64; DNS64 in the IPv4-Only     Remote Network</a><a href="#section-toc.1-1.3.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-comparing-the-scenarios" class="xref">Comparing the Scenarios</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-issues-to-be-considered" class="xref">Issues to be Considered</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-dnssec-considerations-and-p" class="xref">DNSSEC Considerations and Possible Approaches</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc 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="xref">4.1.1</a>.  <a href="#name-not-using-dns64" class="xref">Not Using DNS64</a><a href="#section-toc.1-1.4.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.1.2.2">
                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-dnssec-validator-aware-of-d" class="xref">DNSSEC Validator Aware of DNS64</a><a href="#section-toc.1-1.4.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.1.2.3">
                    <p id="section-toc.1-1.4.2.1.2.3.1"><a href="#section-4.1.3" class="xref">4.1.3</a>.  <a href="#name-stub-validator" class="xref">Stub Validator</a><a href="#section-toc.1-1.4.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.1.2.4">
                    <p id="section-toc.1-1.4.2.1.2.4.1"><a href="#section-4.1.4" class="xref">4.1.4</a>.  <a href="#name-clat-with-dns-proxy-and-val" class="xref">CLAT with DNS Proxy and Validator</a><a href="#section-toc.1-1.4.2.1.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.1.2.5">
                    <p id="section-toc.1-1.4.2.1.2.5.1"><a href="#section-4.1.5" class="xref">4.1.5</a>.  <a href="#name-acl-of-clients" class="xref">ACL of Clients</a><a href="#section-toc.1-1.4.2.1.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.1.2.6">
                    <p id="section-toc.1-1.4.2.1.2.6.1"><a href="#section-4.1.6" class="xref">4.1.6</a>.  <a href="#name-mapping-out-ipv4-addresses" class="xref">Mapping Out IPv4 Addresses</a><a href="#section-toc.1-1.4.2.1.2.6.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-dns64-and-reverse-mapping" class="xref">DNS64 and Reverse Mapping</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc 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="xref">4.3</a>.  <a href="#name-using-464xlat-with-without-" class="xref">Using 464XLAT with/without DNS64</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc 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="xref">4.4</a>.  <a href="#name-foreign-dns" class="xref">Foreign DNS</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc 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="xref">4.4.1</a>.  <a href="#name-manual-configuration-of-dns" class="xref">Manual Configuration of DNS</a><a href="#section-toc.1-1.4.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc 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="xref">4.4.2</a>.  <a href="#name-dns-privacy-encryption-mech" class="xref">DNS Privacy/Encryption Mechanisms</a><a href="#section-toc.1-1.4.2.4.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc 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="xref">4.4.3</a>.  <a href="#name-split-dns-and-vpns" class="xref">Split DNS and VPNs</a><a href="#section-toc.1-1.4.2.4.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc 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="xref">4.5</a>.  <a href="#name-well-known-prefix-wkp-vs-ne" class="xref">Well-Known Prefix (WKP) vs. Network-Specific Prefix (NSP)</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc 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="xref">4.6</a>.  <a href="#name-ipv4-literals-and-non-ipv6-" class="xref">IPv4 Literals and Non-IPv6-Compliant APIs</a><a href="#section-toc.1-1.4.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc 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="xref">4.7</a>.  <a href="#name-ipv4-only-hosts-or-applicat" class="xref">IPv4-Only Hosts or Applications</a><a href="#section-toc.1-1.4.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc 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="xref">4.8</a>.  <a href="#name-clat-translation-considerat" class="xref">CLAT Translation Considerations</a><a href="#section-toc.1-1.4.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.4.2.9">
                <p id="section-toc.1-1.4.2.9.1"><a href="#section-4.9" class="xref">4.9</a>.  <a href="#name-eam-considerations" class="xref">EAM Considerations</a><a href="#section-toc.1-1.4.2.9.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.4.2.10">
                <p id="section-toc.1-1.4.2.10.1"><a href="#section-4.10" class="xref">4.10</a>. <a href="#name-incoming-connections" class="xref">Incoming Connections</a><a href="#section-toc.1-1.4.2.10.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-summary-of-deployment-recom" class="xref">Summary of Deployment Recommendations for NAT64/464XLAT</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-deployment-of-464xlat-nat64" class="xref">Deployment of 464XLAT/NAT64 in Enterprise Networks</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-example-of-broadband-deploy" class="xref">Example of Broadband Deployment with 464XLAT</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-clat-implementation" class="xref">CLAT Implementation</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.c" class="xref">Appendix C</a>.  <a href="#name-benchmarking" class="xref">Benchmarking</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.e" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Stateful NAT64 <span>[<a href="#RFC6146" class="xref">RFC6146</a>]</span> describes a stateful IPv6-to-IPv4 
 translation mechanism that allows IPv6-only hosts to communicate with 
 IPv4-only servers using unicast UDP, TCP, or ICMP by means of IPv4 public 
 address sharing among multiple IPv6-only 
 hosts. Unless otherwise stated, references
 to NAT64 (function) in this document should be interpreted as Stateful NAT64.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The translation of the packet headers is done using the IP/ICMP 
 translation algorithm defined in <span>[<a href="#RFC7915" class="xref">RFC7915</a>]</span>;  
 algorithmically translating the IPv4 addresses to IPv6 addresses, 
 and vice versa, is done following <span>[<a href="#RFC6052" class="xref">RFC6052</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">DNS64 <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span> is in charge of the synthesis 
 of AAAA records from the A records, so it only works for applications 
 making use of DNS. It was designed to avoid changes in both 
 the IPv6-only hosts and the IPv4-only server, so they can use 
 a NAT64 function. As discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc6147#section-5.5" class="relref">Section 5.5</a> of [<a href="#RFC6147" class="xref">RFC6147</a>]</span>, 
 a security-aware and validating host has to perform the 
 DNS64 function locally.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">However, the use of NAT64 and/or DNS64 presents three drawbacks:<a href="#section-1-4" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-1-5">
        <li id="section-1-5.1">Because DNS64 <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span> modifies DNS answers, 
 and DNSSEC is designed to detect such modifications, DNS64 
 <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span> may potentially break DNSSEC, depending on 
 a number of factors such as the location of the DNS64 
 function (at a DNS server or validator, at the end host, ...), how it 
 has been configured, if the end hosts are validating, etc.<a href="#section-1-5.1" class="pilcrow">¶</a>
</li>
        <li id="section-1-5.2">Because of the need to use DNS64 <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span> or 
 an alternative "host/application built-in" mechanism for address synthesis, 
 there may be an issue for NAT64 <span>[<a href="#RFC6146" class="xref">RFC6146</a>]</span>
 because it doesn't work when IPv4 literal addresses or non-IPv6-compliant 
 APIs are being used.<a href="#section-1-5.2" class="pilcrow">¶</a>
</li>
        <li id="section-1-5.3">NAT64 alone was not designed to provide a solution for 
 IPv4-only hosts or applications that are located within a network 
 and connected to a service provider IPv6-only access link, 
 as it was designed for a very specific
 scenario (see <span><a href="https://www.rfc-editor.org/rfc/rfc6144#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC6144" class="xref">RFC6144</a>]</span>).<a href="#section-1-5.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-1-6">The drawbacks discussed above may come into play if part of an enterprise network
 is connected to other parts of the same network or to third-party networks 
 by means of IPv6-only connectivity. This is just an example that may 
 apply to many other similar cases. All of them are deployment specific.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">Accordingly, the use of "operator", 
 "operator network", "service provider", and similar terms in this document 
 are interchangeable with equivalent cases of enterprise networks; other cases may be similar as well. This may be also the case for "managed end-user 
 networks".<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">Note that if all the hosts in a network were performing address synthesis, 
 as described in <span><a href="https://www.rfc-editor.org/rfc/rfc6147#section-7.2" class="relref">Section 7.2</a> of [<a href="#RFC6147" class="xref">RFC6147</a>]</span>, some of the drawbacks 
 may not apply. However, it is unrealistic to expect
 that in today's world, considering 
 the high number of devices and applications that aren't yet IPv6 enabled. 
 In this document, the case in which all hosts provide synthesis will be considered only for specific scenarios 
 that can guarantee it.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">An analysis of stateful IPv4/IPv6 mechanisms is provided in 
 <span>[<a href="#RFC6889" class="xref">RFC6889</a>]</span>.<a href="#section-1-9" class="pilcrow">¶</a></p>
<p id="section-1-10">This document looks into different possible NAT64 <span>[<a href="#RFC6146" class="xref">RFC6146</a>]</span> 
 deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and similar ones 
 that were not documented in <span>[<a href="#RFC6144" class="xref">RFC6144</a>]</span>, such as 464XLAT 
 <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span> in operator (broadband and cellular) and 
 enterprise networks; it provides guidelines to avoid operational issues.<a href="#section-1-10" class="pilcrow">¶</a></p>
<p id="section-1-11">This document also explores the possible NAT64 deployment 
 scenarios (split in "known to work" and "known to work under special conditions"), 
 providing a quick and generic comparison table among them. 
 Then, the document describes the issues that an operator needs to understand, which
         will allow the best 
 approach/scenario to be defined for each specific network case. A summary provides some 
 recommendations and decision points.

 A section with clarifications 
 on the usage of this document for enterprise networks is also provided. 
 Finally, <a href="#AppendixA" class="xref">Appendix A</a> provides an example of a broadband deployment using 464XLAT
 and hints for a customer-side translator (CLAT) implementation.<a href="#section-1-11" class="pilcrow">¶</a></p>
<p id="section-1-12"><span>[<a href="#RFC7269" class="xref">RFC7269</a>]</span> already provides information about 
 NAT64 deployment options and experiences. This document and 
 <span>[<a href="#RFC7269" class="xref">RFC7269</a>]</span> are complementary; they both look into 
 different deployment considerations. Furthermore, this document considers the updated deployment experience and newer standards.<a href="#section-1-12" class="pilcrow">¶</a></p>
<p id="section-1-13">The target deployment scenarios in this document
 may also be covered by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. Note that this is 
 true only for broadband networks; in the case of cellular 
 networks, the only supported solution is the use of NAT64/464XLAT.
 So, it is out of scope of this document to provide a comparison among the 
 different IPv4aaS transition mechanisms, which are analyzed
 in <span>[<a href="#I-D.lmhp-v6ops-transition-comparison" class="xref">IPv6-TRANSITION</a>]</span>.<a href="#section-1-13" class="pilcrow">¶</a></p>
<p id="section-1-14">Consequently, this document should not be used as a guide for 
 an operator or enterprise to decide which IPv4aaS is the best one for 
 its own network. Instead, it should be used as a tool for understanding 
 all the implications, including relevant documents (or even specific 
 parts of them) for the deployment of NAT64/464XLAT and for facilitating 
 the decision process regarding specific deployment details.<a href="#section-1-14" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-requirements-language">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
      </h2>
<p id="section-2-1">    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-3">
      <h2 id="name-nat64-deployment-scenarios">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-nat64-deployment-scenarios" class="section-name selfRef">NAT64 Deployment Scenarios</a>
      </h2>
<p id="section-3-1">DNS64 (see <span><a href="https://www.rfc-editor.org/rfc/rfc6147#section-7" class="relref">Section 7</a> of [<a href="#RFC6147" class="xref">RFC6147</a>]</span>) provides three deployment scenarios, 
 depending on the location of the DNS64 function. However, since the publication 
 of that document, other deployment scenarios and NAT64 use cases need to 
 be considered in actual networks, despite the fact that some of them were specifically 
 ruled out by the original NAT64/DNS64 work.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Consequently, the perspective in this document is
 to broaden those scenarios and
 include a few new ones. However, in order to reduce the number 
 of possible cases, we work under the assumption that the service 
 provider wants to make sure that all the customers have a service 
 without failures. This means considering the following assumptions 
 for the worst possible case:<a href="#section-3-2" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal" id="section-3-3">
        <li id="section-3-3.1">There are hosts that will be validating DNSSEC.<a href="#section-3-3.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-3.2">IPv4 literal addresses and non-IPv6-compliant APIs are being used.<a href="#section-3-3.2" class="pilcrow">¶</a>
</li>
        <li id="section-3-3.3">There are IPv4-only hosts or applications beyond the 
 IPv6-only link (e.g., tethering in cellular networks).<a href="#section-3-3.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-3-4">This document uses a common set of possible "participant entities":<a href="#section-3-4" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-3-5">
        <li id="section-3-5.1">An IPv6-only access network (IPv6).<a href="#section-3-5.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-5.2">An IPv4-only remote network/server/service (IPv4).<a href="#section-3-5.2" class="pilcrow">¶</a>
</li>
        <li id="section-3-5.3">A NAT64 function (NAT64) in the service provider.<a href="#section-3-5.3" class="pilcrow">¶</a>
</li>
        <li id="section-3-5.4">A DNS64 function (DNS64) in the service provider.<a href="#section-3-5.4" class="pilcrow">¶</a>
</li>
        <li id="section-3-5.5">An external service provider offering the NAT64 function and/or the 
 DNS64 function (extNAT64/extDNS64).<a href="#section-3-5.5" class="pilcrow">¶</a>
</li>
        <li id="section-3-5.6">A 464XLAT customer-side translator (CLAT).<a href="#section-3-5.6" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-3-6">Note that the nomenclature used in parentheses is the one that, for short, 
 will be used in the figures. Note: for simplicity, the boxes in 
 the figures don't mean they are actually a single device; they represent 
 one or more functions as located in that part of the network (i.e., a single box 
 with NAT64 and DNS64 functions can actually be several devices, not just one).<a href="#section-3-6" class="pilcrow">¶</a></p>
<p id="section-3-7">The possible scenarios are split in two general categories:<a href="#section-3-7" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-3-8">
        <li id="section-3-8.1">Known to work.<a href="#section-3-8.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-8.2">Known to work under special conditions.<a href="#section-3-8.2" class="pilcrow">¶</a>
</li>
      </ol>
<section id="section-3.1">
        <h3 id="name-known-to-work">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-known-to-work" class="section-name selfRef">Known to Work</a>
        </h3>
<p id="section-3.1-1">The scenarios in this category are known to work, as there are well-known 
 existing deployments from different operators using them. Each one may have 
 different pros and cons, and in some cases, the trade-offs 
 may be acceptable for some operators.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div id="spnatdns64">
<section id="section-3.1.1">
          <h4 id="name-service-provider-nat64-with">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-service-provider-nat64-with" class="section-name selfRef">Service Provider NAT64 with DNS64</a>
          </h4>
<p id="section-3.1.1-1">In this scenario (<a href="#sp-nat64-dns64" class="xref">Figure 1</a>), the service 
 provider offers both the NAT64 and DNS64 functions.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1.1-2">This is the most common scenario as originally considered by
 the designers of NAT64 <span>[<a href="#RFC6146" class="xref">RFC6146</a>]</span> and 
 DNS64 <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span>; however, 
 it may also have the implications related to the DNSSEC.<a href="#section-3.1.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1.1-3">This scenario may also fail to solve the issues of 
 IPv4 literal addresses, non-IPv6-compliant APIs, or
 IPv4-only hosts or applications behind the 
 IPv6-only access network.<a href="#section-3.1.1-3" class="pilcrow">¶</a></p>
<span id="name-nat64-with-dns64"></span><div id="sp-nat64-dns64">
<figure id="figure-1">
            <div class="artwork art-text alignCenter" id="section-3.1.1-4.1">
<pre>
+----------+        +----------+        +----------+
|          |        |  NAT64   |        |          |
|   IPv6   +--------+    +     +--------+   IPv4   |
|          |        |  DNS64   |        |          |
+----------+        +----------+        +----------+</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-nat64-with-dns64" class="selfRef">NAT64 with DNS64</a>
            </figcaption></figure>
</div>
<p id="section-3.1.1-5">A similar scenario (<a href="#sp-dns64-e-nat64" class="xref">Figure 2</a>) exists if 
 the service provider offers only the
 DNS64 function; the NAT64 
 function is provided by an outsourcing agreement with 
 an external provider. 
 All the considerations in the previous paragraphs of this 
 section are the same for this sub-case.<a href="#section-3.1.1-5" class="pilcrow">¶</a></p>
<span id="name-nat64-in-an-external-servic"></span><div id="sp-dns64-e-nat64">
<figure id="figure-2">
            <div class="artwork art-text alignCenter" id="section-3.1.1-6.1">
<pre>
                    +----------+        +----------+
                    |          |        |          |
                    | extNAT64 +--------+   IPv4   |
                    |          |        |          |
                    +----+-----+        +----------+
                         |
                         |
+----------+        +----+-----+
|          |        |          |
|   IPv6   +--------+  DNS64   +
|          |        |          |
+----------+        +----------+</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-nat64-in-an-external-servic" class="selfRef">NAT64 in an External Service Provider</a>
            </figcaption></figure>
</div>
<p id="section-3.1.1-7">This is equivalent to the scenario (<a href="#e-nat64-dns64" class="xref">Figure 3</a>) 
 where the outsourcing 
 agreement with the external provider is to provide both the 
 NAT64 and DNS64 functions. Once more, all the considerations 
 in the previous paragraphs of this section are the same 
 for this sub-case.<a href="#section-3.1.1-7" class="pilcrow">¶</a></p>
<span id="name-nat64-and-dns64-in-an-exter"></span><div id="e-nat64-dns64">
<figure id="figure-3">
            <div class="artwork art-text alignCenter" id="section-3.1.1-8.1">
<pre>
                    +----------+       +----------+
                    | extNAT64 |       |          |
                    |    +     +-------+   IPv4   |
                    | extDNS64 |       |          |
                    +----+-----+       +----------+
                         |
+----------+             |
|          |             |
|   IPv6   +-------------+
|          |
+----------+</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-nat64-and-dns64-in-an-exter" class="selfRef">NAT64 and DNS64 in an External Provider</a>
            </figcaption></figure>
</div>
<p id="section-3.1.1-9">One additional equivalent scenario (<a href="#sp-nat64-e-dns64" class="xref">Figure 4</a>) 
 exists if the service provider 
 only offers the NAT64 function; the DNS64 function is from an 
 external provider with or without a specific agreement among them. 
 This is a common scenario today, as 
 several "global" service providers provide free DNS/DNS64 
 services, and users often configure their DNS manually. This 
 will only work if both the NAT64 and DNS64 functions are using the  
 Well-Known Prefix (WKP) or the same Network-Specific Prefix (NSP). 
 All the considerations in the previous paragraphs 
 of this section are the same for this sub-case.<a href="#section-3.1.1-9" class="pilcrow">¶</a></p>
<p id="section-3.1.1-10">Of course, if the external DNS64 function is agreed with the 
 service provider, then this case is similar to the  
 ones already depicted in this scenario.<a href="#section-3.1.1-10" class="pilcrow">¶</a></p>
<span id="name-nat64-dns64-by-an-external-"></span><div id="sp-nat64-e-dns64">
<figure id="figure-4">
            <div class="artwork art-text alignCenter" id="section-3.1.1-11.1">
<pre>
                    +----------+
                    |          |
                    | extDNS64 |
                    |          |
                    +----+-----+
                         |
                         |
+----------+        +----+-----+        +----------+
|          |        |          |        |          |
|   IPv6   +--------+  NAT64   +--------+   IPv4   |
|          |        |          |        |          |
+----------+        +----------+        +----------+</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-nat64-dns64-by-an-external-" class="selfRef">NAT64; DNS64 by an External Provider</a>
            </figcaption></figure>
</div>
</section>
</div>
<section id="section-3.1.2">
          <h4 id="name-service-provider-offering-4">
<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-service-provider-offering-4" class="section-name selfRef">Service Provider Offering 464XLAT Using DNS64</a>
          </h4>
<p id="section-3.1.2-1">464XLAT <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span> describes an architecture that 
 provides IPv4 connectivity across a network, or part of it, 
 when it is only natively transporting IPv6. 
 The need to support the CLAT function in order to 
 ensure the IPv4 service continuity in IPv6-only cellular deployments has been suggested in <span>[<a href="#RFC7849" class="xref">RFC7849</a>]</span>.<a href="#section-3.1.2-1" class="pilcrow">¶</a></p>
<p id="section-3.1.2-2">In order to do that, 464XLAT <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span> relies on the 
 combination of existing protocols:<a href="#section-3.1.2-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-3.1.2-3">
            <li id="section-3.1.2-3.1">The CLAT is a stateless IPv4-to-IPv6 
 translator (NAT46) <span>[<a href="#RFC7915" class="xref">RFC7915</a>]</span> implemented in the 
 end-user device or Customer Edge Router (CE), located at the 
 "customer edge" of the network.<a href="#section-3.1.2-3.1" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.2-3.2">The provider-side translator (PLAT) is a stateful NAT64 
 <span>[<a href="#RFC6146" class="xref">RFC6146</a>]</span>, implemented typically in 
 the operator network.<a href="#section-3.1.2-3.2" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.2-3.3">Optionally, DNS64 <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span> may allow 
 an optimization: a single translation at the NAT64, instead 
 of two translations (NAT46+NAT64), when the application at 
 the end-user device supports IPv6 DNS (uses AAAA 
 Resource Records).<a href="#section-3.1.2-3.3" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-3.1.2-4">Note that even if the provider-side translator is referred to as PLAT in the 
                        464XLAT terminology <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span>, for simplicity and 
 uniformity across this document, it is always referred to as NAT64 (function).<a href="#section-3.1.2-4" class="pilcrow">¶</a></p>
<p id="section-3.1.2-5">In this scenario (<a href="#sp-464xlat-dns64" class="xref">Figure 5</a>), the service provider 
 deploys 464XLAT with a DNS64 function.<a href="#section-3.1.2-5" class="pilcrow">¶</a></p>
<p id="section-3.1.2-6">As a consequence, the DNSSEC issues remain, unless the host 
 is doing the address synthesis.<a href="#section-3.1.2-6" class="pilcrow">¶</a></p>
<p id="section-3.1.2-7">464XLAT <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span> is a very simple approach to cope 
 with the major NAT64+DNS64 drawback: not working with applications or 
 devices that use literal IPv4 addresses or non-IPv6-compliant APIs.<a href="#section-3.1.2-7" class="pilcrow">¶</a></p>
<p id="section-3.1.2-8">464XLAT <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span> has been used mainly in 
 IPv6-only cellular networks. By supporting a CLAT function, end-user 
 device applications can access IPv4-only end networks / applications, 
 despite the fact that those applications or devices use literal IPv4 addresses 
 or non-IPv6-compliant APIs.<a href="#section-3.1.2-8" class="pilcrow">¶</a></p>
<p id="section-3.1.2-9">In addition, in the cellular network example above,
 if the User Equipment (UE) provides tethering, other devices behind it 
 will be presented with a traditional Network Address Translation from IPv4 to IPv4 (NAT44), in addition to the native 
 IPv6 support, so clearly it allows IPv4-only hosts behind the IPv6-only 
 access network.<a href="#section-3.1.2-9" class="pilcrow">¶</a></p>
<p id="section-3.1.2-10">Furthermore, as discussed in <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span>, 464XLAT 
 can be used in broadband IPv6 network architectures, 
 by implementing the CLAT function at the CE.<a href="#section-3.1.2-10" class="pilcrow">¶</a></p>
<p id="section-3.1.2-11">The support of this scenario in a network offers two additional advantages:<a href="#section-3.1.2-11" class="pilcrow">¶</a></p>
<ul>
<li id="section-3.1.2-12.1">DNS load optimization: A CLAT should implement a DNS proxy 
 (per <span>[<a href="#RFC5625" class="xref">RFC5625</a>]</span>) so that only IPv6-native queries 
 and AAAA records are sent to the DNS64 server. Otherwise, 
 doubling the number of queries may impact the DNS infrastructure.<a href="#section-3.1.2-12.1" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.2-12.2">Connection establishment delay optimization: If the UE/CE 
 implementation is detecting the presence of a DNS64 function, 
 it may issue only the AAAA query, instead of both the AAAA 
 and A queries.<a href="#section-3.1.2-12.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.1.2-13">In order to understand all the communication possibilities, let's 
 assume the following representation of two
   dual-stack (DS) peers:<a href="#section-3.1.2-13" class="pilcrow">¶</a></p>
<div class="artwork art-text alignCenter" id="section-3.1.2-14">
<pre>
               +-------+     .-----.                     .-----.
               |       |    /       \                   /       \
   .-----.     | Res./ |   /  IPv6-  \     .-----.     /  IPv4-  \
  / Local \    | SOHO  +--(   only    )---( NAT64 )---(   only    )
 /         \   |       |   \  flow   /\    `-----'     \  flow   /
(   Dual-   )--+ IPv6  |    \       /  \              / \       /
 \  Stack  /   |  CE   |     `--+--'    \   .-----.  /   `--+--'
  \ Peer  /    | with  |        |        \ / Remote\/       |
   `-----'     | CLAT  |    +---+----+    /         \    +---+----+
               |       |    |DNS/IPv6|   (   Dual-   )   |DNS/IPv4|
               +-------+    |  with  |    \  Stack  /    +--------+
                            | DNS64  |     \ Peer  /
                            +--------+      `-----'

  Figure A: Representation of 464XLAT among Two Peers with DNS64

</pre><a href="#section-3.1.2-14" class="pilcrow">¶</a>
</div>
<p id="section-3.1.2-15">In this case, the possible communication paths, among the IPv4/IPv6 stacks of 
 both peers, are as follows:<a href="#section-3.1.2-15" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal" id="section-3.1.2-16">
            <li id="section-3.1.2-16.1">Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.<a href="#section-3.1.2-16.1" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.2-16.2">Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.<a href="#section-3.1.2-16.2" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.2-16.3">Local-IPv4 to Remote-IPv6: Not possible unless the CLAT 
 implements Explicit Address Mappings (EAMs) as indicated by 
 <a href="#EAM" class="xref">Section 4.9</a>. In principle, 
 it is not expected that services are deployed in the Internet when using 
 IPv6 only, unless there is certainty that peers will also be 
 IPv6 capable.<a href="#section-3.1.2-16.3" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.2-16.4">Local-IPv4 to Remote-IPv4: DNS64, CLAT, and NAT64 translations.<a href="#section-3.1.2-16.4" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.2-16.5">Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT 
 implements EAM as indicated by <a href="#EAM" class="xref">Section 4.9</a>, instead of 
 using the path d. above, NAT64 translation is avoided, and the 
 flow will use IPv6 from the CLAT to the destination.<a href="#section-3.1.2-16.5" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-3.1.2-17">The rest of the figures in this section show different choices for placing 
 the different elements.<a href="#section-3.1.2-17" class="pilcrow">¶</a></p>
<span id="name-464xlat-with-dns64"></span><div id="sp-464xlat-dns64">
<figure id="figure-5">
            <div class="artwork art-text alignCenter" id="section-3.1.2-18.1">
<pre>
+----------+        +----------+        +----------+
|   IPv6   |        |  NAT64   |        |          |
|     +    +--------+    +     +--------+   IPv4   |
|   CLAT   |        |  DNS64   |        |          |
+----------+        +----------+        +----------+ </pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-464xlat-with-dns64" class="selfRef">464XLAT with DNS64</a>
            </figcaption></figure>
</div>
<p id="section-3.1.2-19">A similar scenario (<a href="#ext-nat64-464xlatdns64" class="xref">Figure 6</a>) exists
 if the service provider only 
 offers the DNS64 function; the NAT64 function is provided by 
 an outsourcing agreement with an external provider. 
 All the considerations in the previous paragraphs of this 
 section are the same for this sub-case.<a href="#section-3.1.2-19" class="pilcrow">¶</a></p>
<span id="name-464xlat-with-dns64-nat64-in"></span><div id="ext-nat64-464xlatdns64">
<figure id="figure-6">
            <div class="artwork art-text alignCenter" id="section-3.1.2-20.1">
<pre>
                    +----------+        +----------+
                    |          |        |          |
                    | extNAT64 +--------+   IPv4   |
                    |          |        |          |
                    +----+-----+        +----------+
                         |
                         |
+----------+        +----+-----+
|   IPv6   |        |          |
|     +    +--------+  DNS64   +
|   CLAT   |        |          |
+----------+        +----------+</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-464xlat-with-dns64-nat64-in" class="selfRef">464XLAT with DNS64; NAT64 in an External Provider</a>
            </figcaption></figure>
</div>
<p id="section-3.1.2-21">In addition, it is equivalent to the scenario (<a href="#ext-nat64-dns64-464xlatdns64" class="xref">Figure 7</a>) 
 where the outsourcing 
 agreement with the external provider is to provide both the 
 NAT64 and DNS64 functions. Once more, all the considerations 
 in the previous paragraphs of this section are the same 
 for this sub-case.<a href="#section-3.1.2-21" class="pilcrow">¶</a></p>
<span id="name-464xlat-with-dns64-nat64-an"></span><div id="ext-nat64-dns64-464xlatdns64">
<figure id="figure-7">
            <div class="artwork art-text alignCenter" id="section-3.1.2-22.1">
<pre>
                    +----------+        +----------+
                    | extNAT64 |        |          |
                    |    +     +--------+   IPv4   |
                    | extDNS64 |        |          |
                    +----+-----+        +----------+
                         |
+----------+             |
|   IPv6   |             |
|     +    +-------------+
|   CLAT   |
+----------+</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-464xlat-with-dns64-nat64-an" class="selfRef">464XLAT with DNS64; NAT64 and DNS64 in an External Provider</a>
            </figcaption></figure>
</div>
</section>
<div id="xlat-dns64">
<section id="section-3.1.3">
          <h4 id="name-service-provider-offering-46">
<a href="#section-3.1.3" class="section-number selfRef">3.1.3. </a><a href="#name-service-provider-offering-46" class="section-name selfRef">Service Provider Offering 464XLAT,     without Using DNS64</a>
          </h4>
<p id="section-3.1.3-1">The major advantage of this scenario (<a href="#sp-464xlat" class="xref">Figure 8</a>), 
 using 464XLAT without DNS64, 
 is that the service provider ensures that DNSSEC is never broken, even 
 if the user modifies the DNS configuration. Nevertheless, some 
 CLAT implementations or applications may impose an extra delay, which 
 is induced by the dual A/AAAA queries (and the wait for both responses), 
 unless Happy Eyeballs v2 <span>[<a href="#RFC8305" class="xref">RFC8305</a>]</span> is also present.<a href="#section-3.1.3-1" class="pilcrow">¶</a></p>
<p id="section-3.1.3-2">A possible variation of this scenario is when DNS64 is 
 used only for the discovery of the NAT64 prefix. In the rest of the document, 
 it is not considered a different scenario because once the prefix 
 has been discovered, the DNS64 function is not used, so it behaves as if 
 the DNS64 synthesis function is not present.<a href="#section-3.1.3-2" class="pilcrow">¶</a></p>
<p id="section-3.1.3-3">In this scenario, as in the previous one, there are no 
 issues related to IPv4-only hosts (or IPv4-only applications) 
 behind the IPv6-only access network, as neither are related to the 
 usage of IPv4 literals or non-IPv6-compliant APIs.<a href="#section-3.1.3-3" class="pilcrow">¶</a></p>
<p id="section-3.1.3-4">The support of this scenario in a network offers one advantage:<a href="#section-3.1.3-4" class="pilcrow">¶</a></p>
<ul>
<li id="section-3.1.3-5.1">DNS load optimization: A CLAT should implement a DNS proxy 
 (per <span>[<a href="#RFC5625" class="xref">RFC5625</a>]</span>) so that only IPv6 native queries 
 are sent to the DNS64 server. Otherwise, doubling the number of 
 queries may impact the DNS infrastructure.<a href="#section-3.1.3-5.1" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.1.3-6">As indicated earlier, the connection establishment delay optimization 
 is achieved only in the case of devices, Operating Systems, or applications 
 that use Happy Eyeballs v2 <span>[<a href="#RFC8305" class="xref">RFC8305</a>]</span>, which is very common.<a href="#section-3.1.3-6" class="pilcrow">¶</a></p>
<p id="section-3.1.3-7">As in the previous case, let's assume the representation of two dual-stack peers:<a href="#section-3.1.3-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignCenter" id="section-3.1.3-8">
<pre>
               +-------+     .-----.                     .-----.
               |       |    /       \                   /       \
   .-----.     | Res./ |   /  IPv6-  \     .-----.     /  IPv4-  \
  / Local \    | SOHO  +--(   only    )---( NAT64 )---(   only    )
 /         \   |       |   \  flow   /\    `-----'     \  flow   /
(   Dual-   )--+ IPv6  |    \       /  \              / \       /
 \  Stack  /   |  CE   |     `--+--'    \   .-----.  /   `--+--'
  \ Peer  /    | with  |        |        \ / Remote\/       |
   `-----'     | CLAT  |    +---+----+    /         \    +---+----+
               |       |    |DNS/IPv6|   (   Dual-   )   |DNS/IPv4|
               +-------+    +--------+    \  Stack  /    +--------+
                                           \ Peer  /
                                            `-----'

 Figure B: Representation of 464XLAT among Two Peers without DNS64

</pre><a href="#section-3.1.3-8" class="pilcrow">¶</a>
</div>
<p id="section-3.1.3-9">In this case, the possible communication paths, among the IPv4/IPv6 stacks of 
 both peers, are as follows:<a href="#section-3.1.3-9" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal" id="section-3.1.3-10">
            <li id="section-3.1.3-10.1">Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.<a href="#section-3.1.3-10.1" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.3-10.2">Local-IPv6 to Remote-IPv4: Regular DNS, CLAT, and NAT64 translations.<a href="#section-3.1.3-10.2" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.3-10.3">Local-IPv4 to Remote-IPv6: Not possible unless the CLAT 
 implements EAM as indicated by <a href="#EAM" class="xref">Section 4.9</a>. In principle, 
 it is not expected that services are deployed in the Internet using 
 IPv6 only, unless there is certainty that peers will also be 
 IPv6-capable.<a href="#section-3.1.3-10.3" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.3-10.4">Local-IPv4 to Remote-IPv4: Regular DNS, CLAT, and NAT64 translations.<a href="#section-3.1.3-10.4" class="pilcrow">¶</a>
</li>
            <li id="section-3.1.3-10.5">Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT 
 implements EAM as indicated by <a href="#EAM" class="xref">Section 4.9</a>, instead of 
 using the path d. above, NAT64 translation is avoided, and the flow 
 will use IPv6 from the CLAT to the destination.<a href="#section-3.1.3-10.5" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-3.1.3-11">Notice that this scenario works while the local 
 hosts/applications are dual stack (which is the current situation) 
 because the connectivity from a local IPv6 to a remote IPv4 is not possible 
 without a AAAA synthesis. This aspect is important only when there are IPv6-only hosts in the LANs behind the CLAT and they need to 
 communicate with remote IPv4-only hosts. However, it is not a sensible 
 approach from an Operating System or application vendor 
 perspective to provide IPv6-only support unless, 
 similar to case c above, there is certainty of peers supporting 
 IPv6 as well. An approach to a solution for this is also presented 
 in <span>[<a href="#I-D.palet-v6ops-464xlat-opt-cdn-caches" class="xref">OPT-464XLAT</a>]</span>.<a href="#section-3.1.3-11" class="pilcrow">¶</a></p>
<p id="section-3.1.3-12">The following figures show different choices for placing 
 the different elements.<a href="#section-3.1.3-12" class="pilcrow">¶</a></p>
<span id="name-464xlat-without-dns64"></span><div id="sp-464xlat">
<figure id="figure-8">
            <div class="artwork art-text alignCenter" id="section-3.1.3-13.1">
<pre>
+----------+        +----------+        +----------+
|   IPv6   |        |          |        |          |
|     +    +--------+  NAT64   +--------+   IPv4   |
|   CLAT   |        |          |        |          |
+----------+        +----------+        +----------+</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-464xlat-without-dns64" class="selfRef">464XLAT without DNS64</a>
            </figcaption></figure>
</div>
<p id="section-3.1.3-14">This is equivalent to the scenario (<a href="#ext-nat64-464xlat" class="xref">Figure 9</a>) 
 where there is an 
 outsourcing agreement with an external provider for the 
 NAT64 function. All the considerations in the previous 
 paragraphs of this section are the same for this sub-case.<a href="#section-3.1.3-14" class="pilcrow">¶</a></p>
<span id="name-464xlat-without-dns64-nat64"></span><div id="ext-nat64-464xlat">
<figure id="figure-9">
            <div class="artwork art-text alignCenter" id="section-3.1.3-15.1">
<pre>
                    +----------+        +----------+
                    |          |        |          |
                    | extNAT64 +--------+   IPv4   |
                    |          |        |          |
                    +----+-----+        +----------+
                         |
+----------+             |
|   IPv6   |             |
|     +    +-------------+
|   CLAT   |
+----------+</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-464xlat-without-dns64-nat64" class="selfRef">464XLAT without DNS64; NAT64 in an External Provider</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
<section id="section-3.2">
        <h3 id="name-known-to-work-under-special">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-known-to-work-under-special" class="section-name selfRef">Known to Work under Special Conditions</a>
        </h3>
<p id="section-3.2-1">The scenarios in this category are known
 not to work unless significant 
 effort is devoted to solving the issues or they are intended to solve problems 
 across "closed" networks instead of as a general Internet access usage. 

 Even though some of the different pros, cons, and trade-offs
 may be acceptable, operators have implementation 
 difficulties, as their expectations of
 NAT64/DNS64 are beyond the original intent.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="onlynat64">
<section id="section-3.2.1">
          <h4 id="name-service-provider-nat64-witho">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-service-provider-nat64-witho" class="section-name selfRef">Service Provider NAT64 without DNS64</a>
          </h4>
<p id="section-3.2.1-1">In this scenario (<a href="#only-nat64" class="xref">Figure 10</a>), 
 the service provider offers a NAT64 function; 
 however, there is no DNS64 function support at all.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<p id="section-3.2.1-2">As a consequence, an IPv6 host in the IPv6-only 
 access network will not be able to detect the presence 
 of DNS64 by means of <span>[<a href="#RFC7050" class="xref">RFC7050</a>]</span> or learn the 
 IPv6 prefix to be used for the NAT64 function.<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
<p id="section-3.2.1-3">This can be sorted out as indicated in <a href="#nodns64" class="xref">Section 4.1.1</a>.<a href="#section-3.2.1-3" class="pilcrow">¶</a></p>
<p id="section-3.2.1-4">Regardless, because of the lack of the DNS64 
 function, the IPv6 host will not be able to obtain 
 AAAA synthesized records, so the NAT64 function becomes useless.<a href="#section-3.2.1-4" class="pilcrow">¶</a></p>
<p id="section-3.2.1-5">An exception to this "useless" scenario is to 
 manually configure mappings between the A records of each 
 of the IPv4-only remote hosts and the corresponding AAAA records 
 with the WKP or NSP 
 used by the service-provider NAT64 function, 
 as if they were synthesized by a DNS64 function.<a href="#section-3.2.1-5" class="pilcrow">¶</a></p>
<p id="section-3.2.1-6">This mapping could be done by several means, typically 
 at the authoritative DNS server or at the service-provider 
 resolvers by means of DNS Response Policy Zones (RPZs) 
 <span>[<a href="#I-D.vixie-dnsop-dns-rpz" class="xref">DNS-RPZ</a>]</span> or equivalent functionality. 
 DNS RPZ may have implications in DNSSEC if the zone is signed.
 Also, if the service provider is using an NSP, having the mapping 
 at the authoritative server may create troubles for other parties 
 trying to use a different NSP or WKP, unless multiple DNS "views" 
 (split-DNS) are also being used at the authoritative servers.<a href="#section-3.2.1-6" class="pilcrow">¶</a></p>
<p id="section-3.2.1-7">Generally, the mappings alternative will only make sense 
 if a few sets of IPv4-only remote hosts need to be accessed  
 by a single network (or a small number of them), which supports 
 IPv6 only in the access.
                                This will require some kind of mutual 
 agreement for using this procedure; this should not be a problem because it won't interfere with Internet use (which is a "closed service").<a href="#section-3.2.1-7" class="pilcrow">¶</a></p>
<p id="section-3.2.1-8">In any case, this scenario doesn't solve the issue of 
 IPv4 literal addresses, non-IPv6-compliant APIs, or IPv4-only 
                                hosts within that IPv6-only access network.<a href="#section-3.2.1-8" class="pilcrow">¶</a></p>
<span id="name-nat64-without-dns64"></span><div id="only-nat64">
<figure id="figure-10">
            <div class="artwork art-text alignCenter" id="section-3.2.1-9.1">
<pre>
+----------+        +----------+        +----------+
|          |        |          |        |          |
|   IPv6   +--------+  NAT64   +--------+   IPv4   |
|          |        |          |        |          |
+----------+        +----------+        +----------+</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-nat64-without-dns64" class="selfRef">NAT64 without DNS64</a>
            </figcaption></figure>
</div>
</section>
</div>
<section id="section-3.2.2">
          <h4 id="name-service-provider-nat64-dns6">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-service-provider-nat64-dns6" class="section-name selfRef">Service-Provider NAT64; DNS64 in IPv6 Hosts</a>
          </h4>
<p id="section-3.2.2-1">In this scenario (<a href="#sp-nat64-h-dns64" class="xref">Figure 11</a>), 
 the service provider offers the 
 NAT64 function but not the DNS64 function. However, the IPv6 hosts 
 have a built-in DNS64 function.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2.2-2">This may become common if the DNS64 function is 
 implemented in all the IPv6 hosts/stacks. 
 This is not common at the
 time of writing but may become more
 common in the near future.
 This way, the DNSSEC validation is performed on the A record, 
 and then the host can use the DNS64 function in order to 
 use the NAT64 function without any DNSSEC issues.<a href="#section-3.2.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2.2-3">This scenario fails to solve the issue of 
 IPv4 literal addresses or non-IPv6-compliant APIs, unless 
 the IPv6 hosts also support Happy Eyeballs v2 
 (<span><a href="https://www.rfc-editor.org/rfc/rfc8305#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC8305" class="xref">RFC8305</a>]</span>).<a href="#section-3.2.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2.2-4">Moreover, this scenario also fails to solve the problem 
 of IPv4-only hosts or applications behind the IPv6-only 
 access network.<a href="#section-3.2.2-4" class="pilcrow">¶</a></p>
<span id="name-nat64-dns64-in-ipv6-hosts"></span><div id="sp-nat64-h-dns64">
<figure id="figure-11">
            <div class="artwork art-text alignCenter" id="section-3.2.2-5.1">
<pre>
+----------+        +----------+        +----------+
|   IPv6   |        |          |        |          |
|     +    +--------+  NAT64   +--------+   IPv4   |
|   DNS64  |        |          |        |          |
+----------+        +----------+        +----------+</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-nat64-dns64-in-ipv6-hosts" class="selfRef">NAT64; DNS64 in IPv6 Hosts</a>
            </figcaption></figure>
</div>
</section>
<div id="sprdns64">
<section id="section-3.2.3">
          <h4 id="name-service-provider-nat64-dns64">
<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-service-provider-nat64-dns64" class="section-name selfRef">Service-Provider NAT64; DNS64 in the IPv4-Only     Remote Network</a>
          </h4>
<p id="section-3.2.3-1">In this scenario (<a href="#sp-nat64-r-dns64" class="xref">Figure 12</a>), the service provider offers the 
 NAT64 function only. The IPv4-only remote network offers the 
 DNS64 function.<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
<p id="section-3.2.3-2">This is not common, and it doesn't make sense 
 that a remote network, not deploying IPv6, is providing a DNS64 
 function. Like the scenario depicted in 
 <a href="#onlynat64" class="xref">Section 3.2.1</a>, it will only work if both sides are 
 using the WKP or the same NSP, so the same considerations apply. 
 It can also be tuned to behave as in <a href="#spnatdns64" class="xref">Section 3.1.1</a>.<a href="#section-3.2.3-2" class="pilcrow">¶</a></p>
<p id="section-3.2.3-3">This scenario fails to solve the issue of 
 IPv4 literal addresses or non-IPv6-compliant APIs.<a href="#section-3.2.3-3" class="pilcrow">¶</a></p>
<p id="section-3.2.3-4">Moreover, this scenario also fails to solve the problem 
 of IPv4-only hosts or applications behind the IPv6-only 
 access network.<a href="#section-3.2.3-4" class="pilcrow">¶</a></p>
<span id="name-nat64-dns64-in-ipv4-only-ho"></span><div id="sp-nat64-r-dns64">
<figure id="figure-12">
            <div class="artwork art-text alignCenter" id="section-3.2.3-5.1">
<pre>
+----------+        +----------+        +----------+
|          |        |          |        |   IPv4   |
|   IPv6   +--------+  NAT64   +--------+     +    |
|          |        |          |        |   DNS64  |
+----------+        +----------+        +----------+</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-nat64-dns64-in-ipv4-only-ho" class="selfRef">NAT64; DNS64 in IPv4-Only Hosts</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
<section id="section-3.3">
        <h3 id="name-comparing-the-scenarios">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-comparing-the-scenarios" class="section-name selfRef">Comparing the Scenarios</a>
        </h3>
<p id="section-3.3-1">This section compares the different scenarios, including 
 possible variations (each one represented in the previous sections 
 by a different figure), while considering the following criteria:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal" id="section-3.3-2">
          <li id="section-3.3-2.1">DNSSEC: Are there hosts validating DNSSEC?<a href="#section-3.3-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-3.3-2.2">Literal/APIs: Are there applications using IPv4 literals or 
                                non-IPv6-compliant APIs?<a href="#section-3.3-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-3.3-2.3">IPv4 only: Are there hosts or applications using IPv4 only?<a href="#section-3.3-2.3" class="pilcrow">¶</a>
</li>
          <li id="section-3.3-2.4">Foreign DNS: Does the scenario survive if the user, Operating System, 
 applications, or devices change the DNS?<a href="#section-3.3-2.4" class="pilcrow">¶</a>
</li>
          <li id="section-3.3-2.5">DNS load opt. (DNS load optimization): Are there extra queries that 
    may impact the DNS infrastructure?<a href="#section-3.3-2.5" class="pilcrow">¶</a>
</li>
          <li id="section-3.3-2.6">Connect. opt. (connection establishment delay optimization): 
    Is the UE/CE only issuing the AAAA query or also the A query and 
    waiting for both responses?<a href="#section-3.3-2.6" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-3.3-3">In the table below, the columns represent each of the scenarios from the 
 previous sections by the figure number. The
 possible values are as follows:<a href="#section-3.3-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-3.3-4.1">
            <dl class="dlParallel" id="section-3.3-4.1.1">
              <dt id="section-3.3-4.1.1.1">"-"</dt>
              <dd style="margin-left: 3.0em" id="section-3.3-4.1.1.2">means the scenario is "bad" for that criterion.<a href="#section-3.3-4.1.1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3-4.1.1.3">"+"</dt>
              <dd style="margin-left: 3.0em" id="section-3.3-4.1.1.4">means the scenario is "good" for that criterion.<a href="#section-3.3-4.1.1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3-4.1.1.5">"*"</dt>
              <dd style="margin-left: 3.0em" id="section-3.3-4.1.1.6">means the scenario is "bad" for that criterion; however, it is typically 
 resolved with the support of Happy Eyeballs v2 <span>[<a href="#RFC8305" class="xref">RFC8305</a>]</span>.<a href="#section-3.3-4.1.1.6" class="pilcrow">¶</a>
</dd>
</dl>
</li>
        </ul>
<p id="section-3.3-5">In some cases, "countermeasures", alternative or 
 special configurations, may be available for the criterion designated 
 as "bad". So, this comparison is considering a generic 
 case as a quick comparison guide. In some cases, a "bad" criterion is 
 not necessarily a negative aspect; it all depends on the specific 
 needs/characteristics of the network where the deployment will 
 take place.

                        For instance, in a network that only has IPv6-only hosts and 
 apps using DNS and IPv6-compliant APIs, there is no impact using 
 only NAT64 and DNS64, but if the hosts validate DNSSEC, 
 that criterion is still relevant.<a href="#section-3.3-5" class="pilcrow">¶</a></p>
<span id="name-scenario-comparison"></span><div id="comparing">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-scenario-comparison" class="selfRef">Scenario Comparison</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Item / Figure</th>
              <th class="text-left" rowspan="1" colspan="1">1</th>
              <th class="text-left" rowspan="1" colspan="1">2</th>
              <th class="text-left" rowspan="1" colspan="1">3</th>
              <th class="text-left" rowspan="1" colspan="1">4</th>
              <th class="text-left" rowspan="1" colspan="1">5</th>
              <th class="text-left" rowspan="1" colspan="1">6</th>
              <th class="text-left" rowspan="1" colspan="1">7</th>
              <th class="text-left" rowspan="1" colspan="1">8</th>
              <th class="text-left" rowspan="1" colspan="1">9</th>
              <th class="text-left" rowspan="1" colspan="1">10</th>
              <th class="text-left" rowspan="1" colspan="1">11</th>
              <th class="text-left" rowspan="1" colspan="1">12</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DNSSEC</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Literal/APIs</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv4-only</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Foreign DNS</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DNS load opt.</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Connect. opt.</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">*</td>
              <td class="text-left" rowspan="1" colspan="1">*</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
              <td class="text-left" rowspan="1" colspan="1">+</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.3-7">As a general conclusion, we should note if the network 
 must support applications using any of the following:<a href="#section-3.3-7" class="pilcrow">¶</a></p>
<ul>
<li id="section-3.3-8.1">IPv4 literals<a href="#section-3.3-8.1" class="pilcrow">¶</a>
</li>
          <li id="section-3.3-8.2">non-IPv6-compliant APIs<a href="#section-3.3-8.2" class="pilcrow">¶</a>
</li>
          <li id="section-3.3-8.3">IPv4-only hosts or applications<a href="#section-3.3-8.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.3-9">Then, only the scenarios with 464XLAT, a CLAT function, 
 or equivalent built-in local address synthesis features 
 will provide a valid solution. Furthermore, those scenarios will also 
 keep working if the DNS configuration is modified. Clearly, 
 depending on if DNS64 is used or not, DNSSEC may be broken for 
 those hosts doing DNSSEC validation.<a href="#section-3.3-9" class="pilcrow">¶</a></p>
<p id="section-3.3-10">All the scenarios are good in terms of DNS load optimization, 
 and in the case of 464XLAT, it may provide an extra degree 
 of optimization. Finally, all of the scenarios are also good in terms of 
 connection establishment delay optimization. 
 However, in the case of 464XLAT without DNS64, the 
 usage of Happy Eyeballs v2 is required. This is not an issue as it is commonly available 
 in actual Operating Systems.<a href="#section-3.3-10" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-4">
      <h2 id="name-issues-to-be-considered">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-issues-to-be-considered" class="section-name selfRef">Issues to be Considered</a>
      </h2>
<p id="section-4-1">This section reviews the different issues that an operator needs 
 to consider for a NAT64/464XLAT deployment, as they may develop 
 specific decision points about how to approach that deployment.<a href="#section-4-1" class="pilcrow">¶</a></p>
<section id="section-4.1">
        <h3 id="name-dnssec-considerations-and-p">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-dnssec-considerations-and-p" class="section-name selfRef">DNSSEC Considerations and Possible Approaches</a>
        </h3>
<p id="section-4.1-1">As indicated in the security considerations for DNS64 (see
 <span><a href="https://www.rfc-editor.org/rfc/rfc6147#section-8" class="relref">Section 8</a> of [<a href="#RFC6147" class="xref">RFC6147</a>]</span>) 
                        because DNS64 modifies DNS answers and DNSSEC is designed 
 to detect such modifications, DNS64 may break DNSSEC.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">When a device connected to an IPv6-only access network queries 
 for a domain name in a signed zone, by means of a recursive name server 
 that supports DNS64, the result may be a synthesized AAAA record. In that case, 
 if the recursive name server is configured to perform DNSSEC validation and has 
 a valid chain of trust to the zone in question, it will 
 cryptographically validate the negative response from the authoritative 
 name server. This is the expected DNS64 behavior: the recursive name 
 server actually "lies" to the client device. However, in most of the cases, 
 the client will not notice it, because generally, they don't perform 
 validation themselves; instead, they rely on the recursive name servers.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">In fact, a validating DNS64 resolver increases the confidence on 
 the synthetic AAAA, as it has validated that a non-synthetic AAAA 
 doesn't exist. However, if the client device is oblivious to NAT64 
 (the most common case) and performs DNSSEC validation on the AAAA record, 
 it will fail as it is a synthesized record.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">The best possible scenario from a DNSSEC point of view is when the 
 client requests that the DNS64 server perform the DNSSEC validation 
 (by setting the DNSSEC OK (DO) bit to 1 and the CD bit to 0). In this case, 
 the DNS64 server validates the data; thus, tampering may only happen 
 inside the DNS64 server (which is considered as a trusted part, 
 thus, its likelihood is low) or between the DNS64 server and the 
 client. All other parts of the system (including transmission 
 and caching) are protected by DNSSEC <span>[<a href="#Threat-DNS64" class="xref">Threat-DNS64</a>]</span>.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">Similarly, if the client querying the recursive name server is another 
 name server configured to use it as a forwarder, and it is performing DNSSEC 
 validation, it will also fail on any synthesized AAAA record.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">All those considerations are extensively covered in
 Sections
 <a href="https://www.rfc-editor.org/rfc/rfc6147#section-3" class="relref">3</a>,
 <a href="https://www.rfc-editor.org/rfc/rfc6147#section-5.5" class="relref">5.5</a>,
 and
 <a href="https://www.rfc-editor.org/rfc/rfc6147#section-6.2" class="relref">6.2</a> of
 <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span>.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1-7">DNSSEC issues could be avoided if all the signed zones provide IPv6 connectivity together with the 
 corresponding AAAA records. However, this is out of the control 
 of the operator needing to deploy a NAT64 function. This has been 
 proposed already in <span>[<a href="#I-D.bp-v6ops-ipv6-ready-dns-dnssec" class="xref">DNS-DNSSEC</a>]</span>.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<p id="section-4.1-8">An alternative solution, which was considered 
 while developing <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span>, is that the validators 
 will be DNS64 aware.  Then, they can perform the necessary discovery 
 and do their own synthesis. Since that was standardized sufficiently early in the validator deployment 
 curve, the expectation was that it would be okay to break certain DNSSEC assumptions 
 for networks that were stuck and really needing NAT64/DNS64.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<p id="section-4.1-9">As already indicated, the scenarios in the previous section
 are simplified to look at the worst possible case and for the most perfect approach. 
         A DNSSEC breach will not happen if the end host 
 is not doing validation.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
<p id="section-4.1-10">The figures in previous studies indicate that DNSSEC 
 broken by using DNS64 makes up about 1.7% 
 <span>[<a href="#About-DNS64" class="xref">About-DNS64</a>]</span> of the cases. However, we can't negate 
 that this may increase as DNSSEC deployment grows. 


 Consequently, a decision point for the operator must depend on 
 the following question: Do I really care about that percentage of cases and the impact on 
 my help desk, or can I provide alternative solutions for them?
 Some possible solutions may be exist, as depicted in the next sections.<a href="#section-4.1-10" class="pilcrow">¶</a></p>
<div id="nodns64">
<section id="section-4.1.1">
          <h4 id="name-not-using-dns64">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-not-using-dns64" class="section-name selfRef">Not Using DNS64</a>
          </h4>
<p id="section-4.1.1-1">One solution is to avoid using DNS64, but as already 
 indicated, this is not possible in all the scenarios.<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1.1-2">The use of DNS64 is a key component for some networks, in order 
 to comply with traffic performance metrics, monitored by some 
 governmental bodies and other institutions <span>[<a href="#FCC" class="xref">FCC</a>]</span> <span>[<a href="#ARCEP" class="xref">ARCEP</a>]</span>.<a href="#section-4.1.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1.1-3">One drawback of not having a DNS64 on the network side 
 is that it's not possible to heuristically discover 
 NAT64 <span>[<a href="#RFC7050" class="xref">RFC7050</a>]</span>. 
 Consequently, an IPv6 host behind the IPv6-only access network will not 
 be able to detect the presence of the NAT64 function, nor learn the 
 IPv6 prefix to be used for it, unless it is configured by alternative 
 means.<a href="#section-4.1.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1.1-4">The discovery of the IPv6 prefix could be solved, 
 as described in <span>[<a href="#RFC7050" class="xref">RFC7050</a>]</span>, by means 
 of adding the relevant AAAA records to the ipv4only.arpa. zone 
 of the service-provider recursive servers, i.e., if 
 using the WKP (64:ff9b::/96):<a href="#section-4.1.1-4" class="pilcrow">¶</a></p>
<div class="artwork art-text alignCenter" id="section-4.1.1-5">
<pre>
ipv4only.arpa.  SOA     . . 0 0 0 0 0
ipv4only.arpa.  NS      .
ipv4only.arpa.  AAAA    64:ff9b::192.0.0.170
ipv4only.arpa.  AAAA    64:ff9b::192.0.0.171
ipv4only.arpa.  A       192.0.0.170
ipv4only.arpa.  A       192.0.0.171

</pre><a href="#section-4.1.1-5" class="pilcrow">¶</a>
</div>
<p id="section-4.1.1-6">An alternative option is the use of DNS RPZ 
 <span>[<a href="#I-D.vixie-dnsop-dns-rpz" class="xref">DNS-RPZ</a>]</span> or equivalent functionalities. Note 
 that this may impact DNSSEC if the zone is signed.<a href="#section-4.1.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1.1-7">Another alternative, only valid in environments with support from the Port Control Protocol (PCP) (for 
 both the hosts or CEs and for the service-provider network), is to follow 
 "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)" <span>[<a href="#RFC7225" class="xref">RFC7225</a>]</span>.<a href="#section-4.1.1-7" class="pilcrow">¶</a></p>
<p id="section-4.1.1-8">Other alternatives may be available in the future. All them are 
 extensively discussed in <span>[<a href="#RFC7051" class="xref">RFC7051</a>]</span>;
 however, due to the deployment evolution, many considerations
 from that document have changed. New options are being documented, such as using Router 
 Advertising <span>[<a href="#I-D.ietf-6man-ra-pref64" class="xref">PREF64</a>]</span> or DHCPv6 options 
 <span>[<a href="#I-D.li-intarea-nat64-prefix-dhcp-option" class="xref">DHCPv6-OPTIONS</a>]</span>.<a href="#section-4.1.1-8" class="pilcrow">¶</a></p>
<p id="section-4.1.1-9">Simultaneous support of several of the 
 possible approaches is convenient and will ensure that clients with different 
 ways to configure the NAT64 prefix successfully obtain it. 
 This is also convenient even if DNS64 is being used.<a href="#section-4.1.1-9" class="pilcrow">¶</a></p>
<p id="section-4.1.1-10">Also of special relevance to this section is <span>[<a href="#I-D.cheshire-sudn-ipv4only-dot-arpa" class="xref">IPV4ONLY-ARPA</a>]</span>.<a href="#section-4.1.1-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dns64-aware">
<section id="section-4.1.2">
          <h4 id="name-dnssec-validator-aware-of-d">
<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-dnssec-validator-aware-of-d" class="section-name selfRef">DNSSEC Validator Aware of DNS64</a>
          </h4>
<p id="section-4.1.2-1">In general, by default, DNS servers with DNS64 function will not 
 synthesize AAAA responses if the DO flag was set in the query.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
<p id="section-4.1.2-2">In this case, since only an A record is available, if a CLAT function 
 is present, the CLAT will, 
 as in the case of literal IPv4 addresses, keep that traffic 
 flow end to end as IPv4 so DNSSEC is not broken.<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
<p id="section-4.1.2-3">However, this will not work if a CLAT function is not present 
 because the hosts will not be able to use IPv4 (which is the case for all the 
 scenarios without 464XLAT).<a href="#section-4.1.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="stub">
<section id="section-4.1.3">
          <h4 id="name-stub-validator">
<a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-stub-validator" class="section-name selfRef">Stub Validator</a>
          </h4>
<p id="section-4.1.3-1">If the DO flag is set and the client device performs DNSSEC validation, 
 and the Checking Disabled (CD) flag is set for a query, the DNS64 
 recursive server will not synthesize AAAA responses.
                        In this case, 
 the client could perform the DNSSEC validation with the A record 
 and then synthesize the AAAA responses <span>[<a href="#RFC6052" class="xref">RFC6052</a>]</span>. 
 For that to be possible, the client must have learned  
 the NAT64 prefix beforehand using any of the available methods 
 (see <span>[<a href="#RFC7050" class="xref">RFC7050</a>]</span>, <span>[<a href="#RFC7225" class="xref">RFC7225</a>]</span>, 
 <span>[<a href="#I-D.ietf-6man-ra-pref64" class="xref">PREF64</a>]</span>, and <span>[<a href="#I-D.li-intarea-nat64-prefix-dhcp-option" class="xref">DHCPv6-OPTIONS</a>]</span>). 
 This allows the client device to avoid using the DNS64 function and still 
 use NAT64 even with DNSSEC.<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
<p id="section-4.1.3-2">If the end host is IPv4 only, this will not work if a CLAT function is 
 not present (which is the case for all scenarios without 464XLAT).<a href="#section-4.1.3-2" class="pilcrow">¶</a></p>
<p id="section-4.1.3-3">Instead of a CLAT, some devices or Operating Systems may implement
 an equivalent function by using Bump-in-the-Host <span>[<a href="#RFC6535" class="xref">RFC6535</a>]</span>
                        as part of Happy Eyeballs v2 (see 
 <span><a href="https://www.rfc-editor.org/rfc/rfc8305#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC8305" class="xref">RFC8305</a>]</span>). 
 In this case, the considerations in the above paragraphs are 
 also applicable.<a href="#section-4.1.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dns-proxy">
<section id="section-4.1.4">
          <h4 id="name-clat-with-dns-proxy-and-val">
<a href="#section-4.1.4" class="section-number selfRef">4.1.4. </a><a href="#name-clat-with-dns-proxy-and-val" class="section-name selfRef">CLAT with DNS Proxy and Validator</a>
          </h4>
<p id="section-4.1.4-1">If a CE includes CLAT support and also a DNS proxy, as indicated in 
 <span><a href="https://www.rfc-editor.org/rfc/rfc6877#section-6.4" class="relref">Section 6.4</a> of [<a href="#RFC6877" class="xref">RFC6877</a>]</span>, the CE could behave as a stub 
 validator on behalf of the client devices. Then, following the same approach 
 described in <a href="#stub" class="xref">Section 4.1.3</a>, the DNS proxy 
         will actually "lie" to the client devices, which, in most cases, will 
 not be noticed unless they perform validation by themselves. Again, this 
 allows the client devices to avoid the use of
 the DNS64 function but to still use NAT64 
 with DNSSEC.<a href="#section-4.1.4-1" class="pilcrow">¶</a></p>
<p id="section-4.1.4-2">Once more, this will not work without a CLAT function (which is the case for all scenarios without 464XLAT).<a href="#section-4.1.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="acl-client">
<section id="section-4.1.5">
          <h4 id="name-acl-of-clients">
<a href="#section-4.1.5" class="section-number selfRef">4.1.5. </a><a href="#name-acl-of-clients" class="section-name selfRef">ACL of Clients</a>
          </h4>
<p id="section-4.1.5-1">In cases of dual-stack clients, AAAA queries typically take 
 preference over A queries. If DNS64 is enabled for those clients, 
 it will never get A records, even for IPv4-only servers.<a href="#section-4.1.5-1" class="pilcrow">¶</a></p>
<p id="section-4.1.5-2">As a consequence, in cases where there are IPv4-only servers, 
 and those are located in the path before the NAT64 function, 
 the clients will not be able to reach them. If DNSSEC is being 
 used for all those flows, specific addresses or prefixes can be 
 left out of the DNS64 synthesis by means of Access Control Lists (ACLs).<a href="#section-4.1.5-2" class="pilcrow">¶</a></p>
<p id="section-4.1.5-3">Once more, this will not work without a CLAT function (which is the case for all scenarios without 464XLAT).<a href="#section-4.1.5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="mapping-out">
<section id="section-4.1.6">
          <h4 id="name-mapping-out-ipv4-addresses">
<a href="#section-4.1.6" class="section-number selfRef">4.1.6. </a><a href="#name-mapping-out-ipv4-addresses" class="section-name selfRef">Mapping Out IPv4 Addresses</a>
          </h4>
<p id="section-4.1.6-1">If there are well-known specific IPv4 addresses or prefixes 
 using DNSSEC, they can be mapped out of the DNS64 synthesis.<a href="#section-4.1.6-1" class="pilcrow">¶</a></p>
<p id="section-4.1.6-2">Even if this is not related to DNSSEC, this "mapping-out" feature 
 is quite commonly used to ensure that 
 addresses <span>[<a href="#RFC1918" class="xref">RFC1918</a>]</span> (for example, used by LAN servers) are not synthesized to 
 AAAA.<a href="#section-4.1.6-2" class="pilcrow">¶</a></p>
<p id="section-4.1.6-3">Once more, this will not work without a CLAT function (which is the case for all scenarios without 464XLAT).<a href="#section-4.1.6-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-4.2">
        <h3 id="name-dns64-and-reverse-mapping">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-dns64-and-reverse-mapping" class="section-name selfRef">DNS64 and Reverse Mapping</a>
        </h3>
<p id="section-4.2-1">When a client device using DNS64 tries to reverse-map a 
 synthesized IPv6 address, the name server responds with a CNAME record 
 that points the domain name used to reverse-map the 
 synthesized IPv6 address (the one under ip6.arpa) to the domain name 
 corresponding to the embedded IPv4 address (under in-addr.arpa).<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">This is the expected behavior, so no issues need to be considered 
 regarding DNS reverse mapping.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
</section>
<div id="xlatwwdns64">
<section id="section-4.3">
        <h3 id="name-using-464xlat-with-without-">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-using-464xlat-with-without-" class="section-name selfRef">Using 464XLAT with/without DNS64</a>
        </h3>
<p id="section-4.3-1">In case the client device is IPv6 only (either because the stack or 
 application is IPv6 only or because it is connected via an IPv6-only LAN) 
 and the remote server is IPv4 only (either because the stack is IPv4 only
 or because it is connected via an IPv4-only LAN), only NAT64 combined 
 with DNS64 will be able to provide access between both. Because DNS64 is 
 then required, DNSSEC validation will only be possible if the recursive 
 name server is validating the negative response from the authoritative 
 name server, and the client is not performing validation.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">Note that at this stage of the transition, it is not expected 
 that applications, devices, or Operating Systems are IPv6 only. It will 
 not be a sensible decision for a developer to work on that direction, 
 unless it is clear that the deployment scenario fully supports it.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">On the other hand, an end user or enterprise network may decide to 
 run IPv6 only in the LANs. In case there is any chance for 
 applications to be IPv6 only, the Operating System may be 
 responsible for either doing a local address synthesis or 
 setting up some kind of on-demand VPN (IPv4-in-IPv6), 
 which needs to be supported by that network. This may become 
 very common in enterprise networks, where "Unique IPv6 Prefix 
 per Host" <span>[<a href="#RFC8273" class="xref">RFC8273</a>]</span> is supported.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<p id="section-4.3-4">However, when the client device is dual stack and/or connected in a 
 dual-stack LAN by means of a CLAT function (or has a built-in 
 CLAT function), DNS64 is an option.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-4.3-5">
          <li id="section-4.3-5.1">With DNS64: If DNS64 is used, most of the IPv4 traffic 
 (except if using literal IPv4 addresses or non-IPv6-compliant APIs) 
 will not use the CLAT and will instead use the IPv6 path, so only one 
 translation will be done at the NAT64. This may break DNSSEC, 
 unless measures as described in the previous sections are taken.<a href="#section-4.3-5.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.3-5.2">Without DNS64: If DNS64 is not used, all the IPv4 traffic 
 will make use of the CLAT, so two translations are required (NAT46 
 at the CLAT and NAT64 at the PLAT), which adds some overhead in 
 terms of the extra NAT46 translation. However, this avoids the AAAA 
 synthesis and consequently will never break DNSSEC.<a href="#section-4.3-5.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-4.3-6">Note that the extra translation, when DNS64 is not used, takes place 
 at the CLAT, which means no extra overhead for the operator. 
 However, it adds potential extra delays to establish the connections and has no 
 perceptible impact for a CE in a broadband network, but it may have 
 some impact on a battery-powered device. The cost for a battery-powered 
 device is possibly comparable to the cost when the device is doing a 
 local address synthesis (see
 <span><a href="https://www.rfc-editor.org/rfc/rfc8305#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC8305" class="xref">RFC8305</a>]</span>).<a href="#section-4.3-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="foreignDNS">
<section id="section-4.4">
        <h3 id="name-foreign-dns">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-foreign-dns" class="section-name selfRef">Foreign DNS</a>
        </h3>
<p id="section-4.4-1">Clients, devices, or applications in a service-provider network 
 may use DNS servers from other networks. This may be the case
 if individual applications use their own DNS server, the 
 Operating System itself or even the CE, or combinations of the above.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">Those "foreign" DNS servers may not support DNS64; as a consequence, 
 those scenarios that require a DNS64 may not work. 
 However, if a CLAT function is available, the considerations in 
 <a href="#xlatwwdns64" class="xref">Section 4.3</a> will apply.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">If the foreign DNS supports the DNS64 function, incorrect configuration parameters may be provided that, 
                           for example, cause WKP or NSP to become unmatched or result in a case such as the one described in <a href="#sprdns64" class="xref">Section 3.2.3</a>.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">Having a CLAT function, even if using foreign DNS 
 without a DNS64 function, ensures that everything will work, 
 so the CLAT must be considered to be an advantage despite
 user configuration errors.
                        As a result, all the 
 traffic will use a double translation (NAT46 at the CLAT 
 and NAT64 at the operator network), unless there is 
 support for EAM (<a href="#EAM" class="xref">Section 4.9</a>).<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<p id="section-4.4-5">An exception is the case where there is a CLAT function 
 at the CE that is not able to obtain the correct configuration 
 parameters (again, causing WKP or NSP to become unmatched).<a href="#section-4.4-5" class="pilcrow">¶</a></p>
<p id="section-4.4-6">However, it needs to be emphasized that if there is no CLAT function 
 (which is the case for all scenarios without 464XLAT), an external DNS without DNS64 support 
 will disallow any access to IPv4-only destination networks and will 
 not guarantee the correct DNSSEC validation, 
 so it will behave as in <a href="#onlynat64" class="xref">Section 3.2.1</a>.<a href="#section-4.4-6" class="pilcrow">¶</a></p>
<p id="section-4.4-7">In summary, the consequences of using
 foreign DNS depends on each specific case. However, in general, 
 if a CLAT function is present, most of the time there will not be any issues. 
 In the other cases, the access to IPv6-enabled services 
 is still guaranteed for IPv6-enabled hosts, but it is not guaranteed for IPv4-only hosts 
 nor is the access to IPv4-only services for any hosts in the network.<a href="#section-4.4-7" class="pilcrow">¶</a></p>
<p id="section-4.4-8">The causes of "foreign DNS" could be classified in three main categories, 
 as depicted in the following subsections.<a href="#section-4.4-8" class="pilcrow">¶</a></p>
<section id="section-4.4.1">
          <h4 id="name-manual-configuration-of-dns">
<a href="#section-4.4.1" class="section-number selfRef">4.4.1. </a><a href="#name-manual-configuration-of-dns" class="section-name selfRef">Manual Configuration of DNS</a>
          </h4>
<p id="section-4.4.1-1">It is becoming increasingly common that end users, or even devices 
 or applications, configure alternative DNS in their Operating Systems 
 and sometimes in CEs.<a href="#section-4.4.1-1" class="pilcrow">¶</a></p>
</section>
<div id="dnspriv">
<section id="section-4.4.2">
          <h4 id="name-dns-privacy-encryption-mech">
<a href="#section-4.4.2" class="section-number selfRef">4.4.2. </a><a href="#name-dns-privacy-encryption-mech" class="section-name selfRef">DNS Privacy/Encryption Mechanisms</a>
          </h4>
<p id="section-4.4.2-1">Clients or applications may use mechanisms for 
 DNS privacy/encryption, such as DNS over TLS (DoT)
 <span>[<a href="#RFC7858" class="xref">RFC7858</a>]</span>, DNS over DTLS <span>[<a href="#RFC8094" class="xref">RFC8094</a>]</span>, 
 DNS queries over HTTPS (DoH) <span>[<a href="#RFC8484" class="xref">RFC8484</a>]</span>, or 
 DNS over QUIC (DoQ) <span>[<a href="#I-D.huitema-quic-dnsoquic" class="xref">QUIC-CONNECTIONS</a>]</span>.<a href="#section-4.4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.4.2-2">Currently, those DNS privacy/encryption options are typically 
 provided by the applications, not the Operating System vendors. 
 At the time this document was written, the DoT and DoH standards 
 have declared DNS64 (and consequently NAT64) out of their scope, so 
 an application using them may break NAT64, unless a correctly configured 
 CLAT function is used.<a href="#section-4.4.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SplitDNS">
<section id="section-4.4.3">
          <h4 id="name-split-dns-and-vpns">
<a href="#section-4.4.3" class="section-number selfRef">4.4.3. </a><a href="#name-split-dns-and-vpns" class="section-name selfRef">Split DNS and VPNs</a>
          </h4>
<p id="section-4.4.3-1">When networks or hosts use "split-DNS" (also called Split Horizon, 
 DNS views, or private DNS), the successful use of DNS64 is not guaranteed. 
 This case is analyzed in <span><a href="https://www.rfc-editor.org/rfc/rfc6950#section-4" class="relref">Section 4</a> of [<a href="#RFC6950" class="xref">RFC6950</a>]</span>.<a href="#section-4.4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.4.3-2">A similar situation may happen with VPNs that force all 
 the DNS queries through the VPN and ignore the operator DNS64 function.<a href="#section-4.4.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="WKP-NSP">
<section id="section-4.5">
        <h3 id="name-well-known-prefix-wkp-vs-ne">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-well-known-prefix-wkp-vs-ne" class="section-name selfRef">Well-Known Prefix (WKP) vs. Network-Specific Prefix (NSP)</a>
        </h3>
<p id="section-4.5-1">Section 3 of "IPv6 Addressing of IPv4/IPv6 Translator" <span>[<a href="#RFC6052" class="xref">RFC6052</a>]</span> 
 discusses some considerations that are useful to an operator when deciding if 
 a WKP or an NSP should be used.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">Considering that discussion and other issues, we can 
 summarize the possible decision points to as follows:<a href="#section-4.5-2" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal" id="section-4.5-3">
          <li id="section-4.5-3.1">The WKP <span class="bcp14">MUST NOT</span> be used to represent non-global IPv4 addresses. 
 If this is required because the network to be translated uses 
 non-global addresses, then an NSP is required.<a href="#section-4.5-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.5-3.2">The WKP <span class="bcp14">MAY</span> appear in interdomain routing tables, if the operator 
 provides a NAT64 function to peers. However, in this case, special 
 considerations related to BGP filtering are required, and IPv4-embedded 
 IPv6 prefixes longer than the WKP <span class="bcp14">MUST NOT</span> be advertised (or accepted) 
 in BGP. An NSP may be a more appropriate option in those cases.<a href="#section-4.5-3.2" class="pilcrow">¶</a>
</li>
          <li id="section-4.5-3.3">If several NAT64s use the same prefix, packets from the same 
 flow may be routed to a different NAT64 in case of routing changes. 
 This can be avoided by either using different prefixes for each NAT64 
 function or ensuring that all the NAT64s coordinate their state. 
 Using an NSP could simplify that.<a href="#section-4.5-3.3" class="pilcrow">¶</a>
</li>
          <li id="section-4.5-3.4">If DNS64 is required and users, devices, Operating Systems, or 
 applications may change their DNS configuration and deliberately 
 choose an alternative DNS64 function, the alternative 
 DNS64 will most likely use the WKP by default. In that case, if an NSP is used by 
 the NAT64 function, clients will not be able to use the operator 
 NAT64 function, which will break connectivity to 
 IPv4-only destinations.<a href="#section-4.5-3.4" class="pilcrow">¶</a>
</li>
        </ol>
</section>
</div>
<div id="literals">
<section id="section-4.6">
        <h3 id="name-ipv4-literals-and-non-ipv6-">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-ipv4-literals-and-non-ipv6-" class="section-name selfRef">IPv4 Literals and Non-IPv6-Compliant APIs</a>
        </h3>
<p id="section-4.6-1">A host or application using literal IPv4 addresses or older APIs, 
 which aren't IPv6 compliant, behind a network with IPv6-only access 
 will not work unless any of the following alternatives are provided:<a href="#section-4.6-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-4.6-2.1">CLAT (or an equivalent function).<a href="#section-4.6-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.6-2.2">Happy Eyeballs v2 (Section 7.1 of <span>[<a href="#RFC8305" class="xref">RFC8305</a>]</span>).<a href="#section-4.6-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-4.6-2.3">Bump-in-the-Host <span>[<a href="#RFC6535" class="xref">RFC6535</a>]</span> with a DNS64 function.<a href="#section-4.6-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.6-3">Those alternatives will solve the problem for an end host. 
 However, if the end host is providing "tethering" or an equivalent 
 service to other hosts, that needs to be considered as well.
                        In other 
 words, in a cellular network, these alternatives resolve the issue for 
 the UE itself, but this may not be the case for hosts connected via the tethering.<a href="#section-4.6-3" class="pilcrow">¶</a></p>
<p id="section-4.6-4">Otherwise, the support of 464XLAT is the only valid and complete 
 approach to resolve this issue.<a href="#section-4.6-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ipv4-only">
<section id="section-4.7">
        <h3 id="name-ipv4-only-hosts-or-applicat">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-ipv4-only-hosts-or-applicat" class="section-name selfRef">IPv4-Only Hosts or Applications</a>
        </h3>
<p id="section-4.7-1">IPv4-only hosts or an application behind a network with IPv6-only access 
 will not work unless a CLAT function is present.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
<p id="section-4.7-2">464XLAT is the only valid approach to resolve this issue.<a href="#section-4.7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="CLAT">
<section id="section-4.8">
        <h3 id="name-clat-translation-considerat">
<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-clat-translation-considerat" class="section-name selfRef">CLAT Translation Considerations</a>
        </h3>
<p id="section-4.8-1">As described in "IPv6 Prefix 
 Handling" (see <span><a href="https://www.rfc-editor.org/rfc/rfc6877#section-6.3" class="relref">Section 6.3</a> of [<a href="#RFC6877" class="xref">RFC6877</a>]</span>), if the CLAT function 
                        can be configured with a dedicated /64 prefix 
 for the NAT46 translation, then it will be possible to do a more  
 efficient stateless translation.<a href="#section-4.8-1" class="pilcrow">¶</a></p>
<p id="section-4.8-2">Otherwise, if this dedicated prefix is not available, the CLAT function will 
 need to do a stateful translation, for example, perform stateful NAT44 
 for all the IPv4 LAN packets so they appear as coming from a single 
 IPv4 address; in turn, the CLAT function will perform a stateless translation to a single IPv6 
 address.<a href="#section-4.8-2" class="pilcrow">¶</a></p>
<p id="section-4.8-3">A possible setup, in order to maximize the CLAT 
 performance, is to configure the dedicated translation prefix. This 
 can be easily achieved automatically, if the broadband CE or 
 end-user device is able to obtain a shorter prefix by means 
 of DHCPv6-PD <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span> or other alternatives. 
 The CE can then use a specific /64 for the translation. This is also 
 possible when broadband is provided by a cellular access.<a href="#section-4.8-3" class="pilcrow">¶</a></p>
<p id="section-4.8-4">The above recommendation is often not possible for cellular networks, 
 when connecting smartphones (as UEs): generally they don't use DHCPv6-PD 
 <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>. Instead, a single /64 is provided for 
 each Packet Data Protocol (PDP) context, and prefix sharing <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span> is used. 
 In this case, the UEs typically have a build-in CLAT function that 
 is performing a stateful NAT44 translation before the stateless NAT46.<a href="#section-4.8-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="EAM">
<section id="section-4.9">
        <h3 id="name-eam-considerations">
<a href="#section-4.9" class="section-number selfRef">4.9. </a><a href="#name-eam-considerations" class="section-name selfRef">EAM Considerations</a>
        </h3>
<p id="section-4.9-1">"Explicit Address Mappings for Stateless IP/ICMP Translation" 
 <span>[<a href="#RFC7757" class="xref">RFC7757</a>]</span> provides a way to configure explicit 
 mappings between IPv4 and IPv6 prefixes of any length. 
 When this is used, for example, in a CLAT function, it may provide a 
 simple mechanism in order to avoid traffic flows between 
 IPv4-only nodes or applications and dual-stack destinations 
 to be translated twice (NAT46 and NAT64), by creating mapping 
 entries with the Global Unicast Address (GUA) of the IPv6-reachable destination. 
 This optimization of NAT64 usage is very useful in 
 many scenarios, including Content Delivery Networks (CDNs) and caches, as described in 
 <span>[<a href="#I-D.palet-v6ops-464xlat-opt-cdn-caches" class="xref">OPT-464XLAT</a>]</span>.<a href="#section-4.9-1" class="pilcrow">¶</a></p>
<p id="section-4.9-2">In addition, it may also provide a way for IPv4-only 
 nodes or applications to communicate with IPv6-only destinations.<a href="#section-4.9-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="incoming">
<section id="section-4.10">
        <h3 id="name-incoming-connections">
<a href="#section-4.10" class="section-number selfRef">4.10. </a><a href="#name-incoming-connections" class="section-name selfRef">Incoming Connections</a>
        </h3>
<p id="section-4.10-1">The use of NAT64, in principle, disallows IPv4 incoming connections, 
 which may still be needed for IPv4-only peer-to-peer applications. 
 However, there are several alternatives that resolve this issue:<a href="#section-4.10-1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal" id="section-4.10-2">
          <li id="section-4.10-2.1">Session Traversal Utilities for NAT (STUN) <span>[<a href="#RFC5389" class="xref">RFC5389</a>]</span>, Traversal Using Relays around NAT (TURN) <span>[<a href="#RFC5766" class="xref">RFC5766</a>]</span>, and 
 Interactive Connectivity Establishment (ICE) <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> are commonly used by peer-to-peer 
 applications in order to allow incoming connections with IPv4 NAT. In the case of NAT64, they
                        work as well.<a href="#section-4.10-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.10-2.2">The Port Control Protocol (PCP) <span>[<a href="#RFC6887" class="xref">RFC6887</a>]</span> allows a host to control how incoming 
 IPv4 and IPv6 packets are translated and forwarded. A NAT64 may implement 
 PCP to allow this service.<a href="#section-4.10-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-4.10-2.3">EAM <span>[<a href="#RFC7757" class="xref">RFC7757</a>]</span> may also be used in order to configure 
 explicit mappings for customers that require them. This is used, for example, 
 by Stateless IP/ICMP Translation for IPv6 Data Center Environments (SIIT-DC) <span>[<a href="#RFC7755" class="xref">RFC7755</a>]</span> and SIIT-DC Dual Translation Mode (SIIT-DC-DTM) <span>[<a href="#RFC7756" class="xref">RFC7756</a>]</span>.<a href="#section-4.10-2.3" class="pilcrow">¶</a>
</li>
        </ol>
</section>
</div>
</section>
<section id="section-5">
      <h2 id="name-summary-of-deployment-recom">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-summary-of-deployment-recom" class="section-name selfRef">Summary of Deployment Recommendations for NAT64/464XLAT</a>
      </h2>
<p id="section-5-1">It has been demonstrated that NAT64/464XLAT is a valid choice in several 
 scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the predominant mechanism 
 in the majority of the cellular networks, which account for hundreds 
 of millions of users <span>[<a href="#ISOC" class="xref">ISOC</a>]</span>. 
 NAT64/464XLAT offer different choices of deployment, 
 depending on each network case, needs, and requirements. Despite that, 
 this document is not an explicit recommendation for using this choice 
 versus other IPv4aaS transition mechanisms. Instead, this document 
 is a guide that facilitates evaluating a possible implementation 
 of NAT64/464XLAT and key decision points about specific design 
 considerations for its deployment.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Depending on the specific requirements of each deployment case, 
 DNS64 may be a required function, while in other cases, the 
 adverse effects may be counterproductive. 
 Similarly, in some cases, a NAT64 function, together with a DNS64 function, 
 may be a valid solution when there is a certainty that IPv4-only hosts 
 or applications do not need to be supported
 (see Sections <a href="#literals" class="xref">4.6</a> and
        <a href="#ipv4-only" class="xref">4.7</a>). However, in other cases (i.e., IPv4-only devices 
 or applications that need to be supported), the limitations of NAT64/DNS64
 may indicate that the operator needs to look into 464XLAT as a more complete solution.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">For broadband-managed networks (where the CE is provided or 
 suggested/supported by the operator), in order to fully support 
 the actual user's needs (i.e., IPv4-only devices and applications and the 
 usage of IPv4 literals and non-IPv6-compliant APIs), the 464XLAT scenario 
 should be considered. In that case, it must support a CLAT function.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">If the operator provides DNS services, they may support a DNS64 function to avoid, as much as possible, breaking DNSSEC.  This will also increase performance, 
 by reducing the double translation for all the IPv4 traffic.  In this case, if the DNS service 
 is offering DNSSEC validation, then it must be in such a way that it is 
 aware of the DNS64. This is considered the simpler and safer approach, 
 and it may be combined with other recommendations described 
 in this document:<a href="#section-5-4" class="pilcrow">¶</a></p>
<ul>
<li id="section-5-5.1">DNS infrastructure <span class="bcp14">MUST</span> be aware of DNS64 (<a href="#dns64-aware" class="xref">Section 4.1.2</a>).<a href="#section-5-5.1" class="pilcrow">¶</a>
</li>
        <li id="section-5-5.2">Devices running CLAT <span class="bcp14">SHOULD</span> follow the indications in "Stub Validator"
 (see <a href="#stub" class="xref">Section 4.1.3</a>). However, this may be out of the 
 control of the operator.<a href="#section-5-5.2" class="pilcrow">¶</a>
</li>
        <li id="section-5-5.3">CEs <span class="bcp14">SHOULD</span> include a DNS proxy and validator (<a href="#dns-proxy" class="xref">Section 4.1.4</a>).<a href="#section-5-5.3" class="pilcrow">¶</a>
</li>
        <li id="section-5-5.4">"ACL of Clients" (see <a href="#acl-client" class="xref">Section 4.1.5</a>) and "Mapping Out IPv4 Addresses"
 (see <a href="#mapping-out" class="xref">Section 4.1.6</a>) <span class="bcp14">MAY</span> be considered by 
 operators, depending on their own infrastructure.<a href="#section-5-5.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-6">This "increased performance" approach has the disadvantage of 
 potentially breaking DNSSEC for a small percentage of validating 
 end hosts versus the small impact of a double translation taking place 
 in the CE. If CE performance is not an issue, which is the most frequent 
 case, then a much safer approach is to not use DNS64 at all, 
 and consequently, ensure that all the IPv4 traffic 
 is translated at the CLAT (<a href="#xlatwwdns64" class="xref">Section 4.3</a>).<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">If DNS64 is not used, at least one of the alternatives 
 described in <a href="#nodns64" class="xref">Section 4.1.1</a> must be followed in order 
 to learn the NAT64 prefix.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">The operator needs to consider that if the DNS configuration is
 modified (see Sections <a href="#foreignDNS" class="xref">4.4</a>, <a href="#dnspriv" class="xref">4.4.2</a>, and
 <a href="#SplitDNS" class="xref">4.4.3</a>), which most likely 
 cannot be avoided, a foreign non-DNS64 could be used instead of configuring a DNS64. In a scenario with only a 
 NAT64 function, an IPv4-only remote host will no longer be accessible. 
 Instead, it will continue to work in the case of 464XLAT.<a href="#section-5-8" class="pilcrow">¶</a></p>
<p id="section-5-9">Similar considerations need to be made regarding the usage of 
   a NAT64 WKP vs. NSP (<a href="#WKP-NSP" class="xref">Section 4.5</a>), as they must match 
 the configuration of DNS64. When using foreign DNS, 
 they may not match. 
 If there is a CLAT and the configured foreign DNS is not a DNS64, the 
 network will keep working only if other means of learning the NAT64 
 prefix are available.<a href="#section-5-9" class="pilcrow">¶</a></p>
<p id="section-5-10">For broadband networks, as described in <a href="#CLAT" class="xref">Section 4.8</a>,  
 the CEs supporting a CLAT function <span class="bcp14">SHOULD</span>
 support DHCPv6-PD <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span> or alternative means for 
 configuring a shorter prefix. The CE <span class="bcp14">SHOULD</span> internally reserve 
 one /64 for the stateless NAT46 translation. The operator must ensure 
 that the customers are allocated prefixes shorter than /64 in order 
 to support this optimization. One way or another, this is not 
 impacting the performance of the operator network.<a href="#section-5-10" class="pilcrow">¶</a></p>
<p id="section-5-11">Operators may follow "Deployment Considerations" (Section 7 of <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span>) for suggestions on how to 
 take advantage of traffic-engineering requirements.<a href="#section-5-11" class="pilcrow">¶</a></p>
<p id="section-5-12">For cellular networks, the considerations regarding DNSSEC 
 may appear to be out of scope because UEs' Operating Systems 
 commonly don't support DNSSEC. However, applications running on them 
 may, or it may be an Operating System "built-in" support in the 
 future. Moreover, if those devices offer tethering, 
 other client devices behind the UE may be doing the validation; 
 hence, proper DNSSEC support by the operator network is relevant.<a href="#section-5-12" class="pilcrow">¶</a></p>
<p id="section-5-13">Furthermore, cellular networks supporting 464XLAT 
 <span>[<a href="#RFC6877" class="xref">RFC6877</a>]</span> and "Discovery of the IPv6 Prefix Used for 
 IPv6 Address Synthesis" <span>[<a href="#RFC7050" class="xref">RFC7050</a>]</span> allow a progressive 
 IPv6 deployment, with a single Access Point Name (APN) supporting all types of PDP context 
 (IPv4, IPv6, and IPv4v6). This approach allows the network to 
 automatically serve every possible combination of UEs.<a href="#section-5-13" class="pilcrow">¶</a></p>
<p id="section-5-14">If the operator chooses to provide validation for the DNS64 
 prefix discovery, it must follow the advice from "Validation of Discovered Pref64::/n" (see
 <span><a href="https://www.rfc-editor.org/rfc/rfc7050#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC7050" class="xref">RFC7050</a>]</span>).<a href="#section-5-14" class="pilcrow">¶</a></p>
<p id="section-5-15">One last consideration is that many networks may have a mix of different 
 complex scenarios at the same time; for example, customers that require 464XLAT
                        and those that don't, 
 customers that require DNS64 and those that don't, etc. In 
 general, the different issues and the approaches described in this document 
 can be implemented at the same time for different customers or parts of 
 the network. That mix of approaches doesn't present any problem or 
 incompatibility; they work well together as a matter of 
 appropriate and differentiated provisioning. In fact, the NAT64/464XLAT 
 approach facilitates an operator offering both cellular and broadband 
 services to have a single IPv4aaS for both networks while differentiating 
 the deployment key decisions to optimize each case. It's even possible to
 use hybrid CEs that have a main broadband access link and a backup via 
 the cellular network.<a href="#section-5-15" class="pilcrow">¶</a></p>
<p id="section-5-16">In an ideal world, we could safely use DNS64 if the approach 
 proposed in <span>[<a href="#I-D.bp-v6ops-ipv6-ready-dns-dnssec" class="xref">DNS-DNSSEC</a>]</span> 
 were followed, avoiding the cases where DNSSEC may be broken. 
 However, this will not solve the issues related to DNS privacy 
 and split DNS.<a href="#section-5-16" class="pilcrow">¶</a></p>
<p id="section-5-17">The only 100% safe solution that also resolves all the issues
 is, in addition to having a CLAT function, not using a DNS64 but 
 instead making sure that the hosts have a built-in address 
 synthesis feature. Operators could manage to provide CEs with 
 the CLAT function; however, the built-in address 
 synthesis feature is out of their control. If the synthesis is 
 provided by either the Operating System (via its DNS resolver API) 
 or the application (via its own DNS resolver) in such way that 
 the prefix used for the NAT64 function is reachable for the host, 
 the problem goes away.<a href="#section-5-17" class="pilcrow">¶</a></p>
<p id="section-5-18">Whenever feasible, using EAM <span>[<a href="#RFC7757" class="xref">RFC7757</a>]</span> 
 as indicated in <a href="#EAM" class="xref">Section 4.9</a> provides a very relevant 
 optimization, avoiding double translations.<a href="#section-5-18" class="pilcrow">¶</a></p>
<p id="section-5-19">Applications that require incoming connections typically 
 provide a means for that already. However, PCP and EAM, as indicated in 
 <a href="#incoming" class="xref">Section 4.10</a>, are valid alternatives, even for 
 creating explicit mappings for customers that require them.<a href="#section-5-19" class="pilcrow">¶</a></p>
</section>
<section id="section-6">
      <h2 id="name-deployment-of-464xlat-nat64">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-deployment-of-464xlat-nat64" class="section-name selfRef">Deployment of 464XLAT/NAT64 in Enterprise Networks</a>
      </h2>
<p id="section-6-1">The recommendations in this document can also be used in 
 enterprise networks, campuses, and other similar scenarios (including 
 managed end-user networks).<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">This includes scenarios where the NAT64 function 
 (and DNS64 function, if available) are under 
 the control of that network (or can be configured manually according 
 to that network's specific requirements), and there is a need  
 to provide IPv6-only access to any part of that 
 network, or it is IPv6 only connected to third-party networks.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">An example is the IETF meeting network itself, 
 where both NAT64 and DNS64 functions are provided, presenting in this case 
 the same issues as per <a href="#spnatdns64" class="xref">Section 3.1.1</a>. If there 
 is a CLAT function in the IETF network, then there is no 
 need to use DNS64, and it falls under the considerations of 
 <a href="#xlat-dns64" class="xref">Section 3.1.3</a>. Both scenarios have been tested and 
 verified already in the IETF network.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">The following figures represent a few of the possible 
 scenarios.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5"><a href="#enterprise-nat64-dns64" class="xref">Figure 13</a> provides an example of an 
 IPv6-only enterprise network connected with a dual stack to 
 the Internet using local NAT64 and DNS64 functions.<a href="#section-6-5" class="pilcrow">¶</a></p>
<span id="name-ipv6-only-enterprise-with-n"></span><div id="enterprise-nat64-dns64">
<figure id="figure-13">
        <div class="artwork art-text alignCenter" id="section-6-6.1">
<pre>
+----------------------------------+
|       Enterprise Network         |
| +----------+        +----------+ |       +----------+
| |   IPv6-  |        |  NAT64   | |       |   IPv4   |
| |   only   +--------+    +     | +-------+     +    |
| |   LANs   |        |  DNS64   | |       |   IPv6   |
| +----------+        +----------+ |       +----------+
+----------------------------------+</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-ipv6-only-enterprise-with-n" class="selfRef">IPv6-Only Enterprise with NAT64 and DNS64</a>
        </figcaption></figure>
</div>
<p id="section-6-7"><a href="#enterprise-464xlat" class="xref">Figure 14</a> provides an example of a 
 DS enterprise network connected with DS 
 to the Internet using a CLAT function, without a DNS64 function.<a href="#section-6-7" class="pilcrow">¶</a></p>
<span id="name-ds-enterprise-with-clat-ds-"></span><div id="enterprise-464xlat">
<figure id="figure-14">
        <div class="artwork art-text alignCenter" id="section-6-8.1">
<pre>
+----------------------------------+
|       Enterprise Network         |
| +----------+        +----------+ |       +----------+
| |   IPv6   |        |          | |       |   IPv4   |
| |     +    +--------+  NAT64   | +-------+     +    |
| |   CLAT   |        |          | |       |   IPv6   |
| +----------+        +----------+ |       +----------+
+----------------------------------+</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-ds-enterprise-with-clat-ds-" class="selfRef">DS Enterprise with CLAT, DS Internet, without DNS64</a>
        </figcaption></figure>
</div>
<p id="section-6-9">Finally, <a href="#enterprise-own-clat" class="xref">Figure 15</a> provides an example of an 
 IPv6-only provider with a NAT64 function, and a DS enterprise 
 network by means of their own CLAT function, without a DNS64 function.<a href="#section-6-9" class="pilcrow">¶</a></p>
<span id="name-ds-enterprise-with-clat-and"></span><div id="enterprise-own-clat">
<figure id="figure-15">
        <div class="artwork art-text alignCenter" id="section-6-10.1">
<pre>
+----------------------------------+
|       Enterprise Network         |
| +----------+        +----------+ |        +----------+
| |   IPv6   |        |          | |  IPv6  |          |
| |     +    +--------+   CLAT   | +--------+   NAT64  |
| |   IPv4   |        |          | |  only  |          |
| +----------+        +----------+ |        +----------+
+----------------------------------+</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-ds-enterprise-with-clat-and" class="selfRef">DS Enterprise with CLAT and IPv6-Only Access, without DNS64</a>
        </figcaption></figure>
</div>
</section>
<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">This document does not have new specific security considerations beyond 
 those already reported by each of the documents cited. For example, DNS64 
 <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span> already describes the DNSSEC issues.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">As already described in <a href="#foreignDNS" class="xref">Section 4.4</a>, note that there 
 may be undesirable interactions, especially if using VPNs or DNS privacy, 
 which may impact the correct performance of DNS64/NAT64.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">Note that the use of a DNS64 function has
 privacy considerations that are equivalent to regular DNS, and they are located 
 in either the service provider or an external service provider.<a href="#section-7-3" class="pilcrow">¶</a></p>
</section>
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1"> This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC1918">[RFC1918]</dt>
        <dd>
<span class="refAuthor">Rekhter, Y.</span><span class="refAuthor">, Moskowitz, B.</span><span class="refAuthor">, Karrenberg, D.</span><span class="refAuthor">, de Groot, G. J.</span><span class="refAuthor">, and E. Lear</span>, <span class="refTitle">"Address Allocation for Private Internets"</span>, <span class="seriesInfo">BCP 5</span>, <span class="seriesInfo">RFC 1918</span>, <span class="seriesInfo">DOI 10.17487/RFC1918</span>, <time datetime="1996-02">February 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1918">https://www.rfc-editor.org/info/rfc1918</a>&gt;</span>. </dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dt id="RFC5389">[RFC5389]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Mahy, R.</span><span class="refAuthor">, Matthews, P.</span><span class="refAuthor">, and D. Wing</span>, <span class="refTitle">"Session Traversal Utilities for NAT (STUN)"</span>, <span class="seriesInfo">RFC 5389</span>, <span class="seriesInfo">DOI 10.17487/RFC5389</span>, <time datetime="2008-10">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5389">https://www.rfc-editor.org/info/rfc5389</a>&gt;</span>. </dd>
<dt id="RFC5625">[RFC5625]</dt>
        <dd>
<span class="refAuthor">Bellis, R.</span>, <span class="refTitle">"DNS Proxy Implementation Guidelines"</span>, <span class="seriesInfo">BCP 152</span>, <span class="seriesInfo">RFC 5625</span>, <span class="seriesInfo">DOI 10.17487/RFC5625</span>, <time datetime="2009-08">August 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5625">https://www.rfc-editor.org/info/rfc5625</a>&gt;</span>. </dd>
<dt id="RFC5766">[RFC5766]</dt>
        <dd>
<span class="refAuthor">Mahy, R.</span><span class="refAuthor">, Matthews, P.</span><span class="refAuthor">, and J. Rosenberg</span>, <span class="refTitle">"Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"</span>, <span class="seriesInfo">RFC 5766</span>, <span class="seriesInfo">DOI 10.17487/RFC5766</span>, <time datetime="2010-04">April 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5766">https://www.rfc-editor.org/info/rfc5766</a>&gt;</span>. </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><span class="refAuthor">, and 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">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>
<dt id="RFC6144">[RFC6144]</dt>
        <dd>
<span class="refAuthor">Baker, F.</span><span class="refAuthor">, Li, X.</span><span class="refAuthor">, Bao, C.</span><span class="refAuthor">, and K. Yin</span>, <span class="refTitle">"Framework for IPv4/IPv6 Translation"</span>, <span class="seriesInfo">RFC 6144</span>, <span class="seriesInfo">DOI 10.17487/RFC6144</span>, <time datetime="2011-04">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6144">https://www.rfc-editor.org/info/rfc6144</a>&gt;</span>. </dd>
<dt id="RFC6146">[RFC6146]</dt>
        <dd>
<span class="refAuthor">Bagnulo, M.</span><span class="refAuthor">, Matthews, P.</span><span class="refAuthor">, and 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">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>
<dt id="RFC6147">[RFC6147]</dt>
        <dd>
<span class="refAuthor">Bagnulo, M.</span><span class="refAuthor">, Sullivan, A.</span><span class="refAuthor">, Matthews, P.</span><span class="refAuthor">, and 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">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>
<dt id="RFC6535">[RFC6535]</dt>
        <dd>
<span class="refAuthor">Huang, B.</span><span class="refAuthor">, Deng, H.</span><span class="refAuthor">, and T. Savolainen</span>, <span class="refTitle">"Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)"</span>, <span class="seriesInfo">RFC 6535</span>, <span class="seriesInfo">DOI 10.17487/RFC6535</span>, <time datetime="2012-02">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6535">https://www.rfc-editor.org/info/rfc6535</a>&gt;</span>. </dd>
<dt id="RFC6877">[RFC6877]</dt>
        <dd>
<span class="refAuthor">Mawatari, M.</span><span class="refAuthor">, Kawashima, M.</span><span class="refAuthor">, and 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">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>
<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><span class="refAuthor">, and 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">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>
<dt id="RFC7050">[RFC7050]</dt>
        <dd>
<span class="refAuthor">Savolainen, T.</span><span class="refAuthor">, Korhonen, J.</span><span class="refAuthor">, and 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">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>
<dt id="RFC7225">[RFC7225]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span>, <span class="refTitle">"Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)"</span>, <span class="seriesInfo">RFC 7225</span>, <span class="seriesInfo">DOI 10.17487/RFC7225</span>, <time datetime="2014-05">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7225">https://www.rfc-editor.org/info/rfc7225</a>&gt;</span>. </dd>
<dt id="RFC7757">[RFC7757]</dt>
        <dd>
<span class="refAuthor">Anderson, T.</span><span class="refAuthor"> and 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">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>
<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><span class="refAuthor">, and 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">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>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dt id="RFC8273">[RFC8273]</dt>
        <dd>
<span class="refAuthor">Brzozowski, J.</span><span class="refAuthor"> and G. Van de Velde</span>, <span class="refTitle">"Unique IPv6 Prefix per Host"</span>, <span class="seriesInfo">RFC 8273</span>, <span class="seriesInfo">DOI 10.17487/RFC8273</span>, <time datetime="2017-12">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8273">https://www.rfc-editor.org/info/rfc8273</a>&gt;</span>. </dd>
<dt id="RFC8305">[RFC8305]</dt>
        <dd>
<span class="refAuthor">Schinazi, D.</span><span class="refAuthor"> and T. Pauly</span>, <span class="refTitle">"Happy Eyeballs Version 2: Better Connectivity Using Concurrency"</span>, <span class="seriesInfo">RFC 8305</span>, <span class="seriesInfo">DOI 10.17487/RFC8305</span>, <time datetime="2017-12">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8305">https://www.rfc-editor.org/info/rfc8305</a>&gt;</span>. </dd>
<dt id="RFC8375">[RFC8375]</dt>
        <dd>
<span class="refAuthor">Pfister, P.</span><span class="refAuthor"> and T. Lemon</span>, <span class="refTitle">"Special-Use Domain 'home.arpa.'"</span>, <span class="seriesInfo">RFC 8375</span>, <span class="seriesInfo">DOI 10.17487/RFC8375</span>, <time datetime="2018-05">May 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8375">https://www.rfc-editor.org/info/rfc8375</a>&gt;</span>. </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><span class="refAuthor">, and 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">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>
<dt id="RFC8445">[RFC8445]</dt>
        <dd>
<span class="refAuthor">Keranen, A.</span><span class="refAuthor">, Holmberg, C.</span><span class="refAuthor">, and J. Rosenberg</span>, <span class="refTitle">"Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal"</span>, <span class="seriesInfo">RFC 8445</span>, <span class="seriesInfo">DOI 10.17487/RFC8445</span>, <time datetime="2018-07">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8445">https://www.rfc-editor.org/info/rfc8445</a>&gt;</span>. </dd>
<dt id="RFC8484">[RFC8484]</dt>
      <dd>
<span class="refAuthor">Hoffman, P.</span><span class="refAuthor"> and P. McManus</span>, <span class="refTitle">"DNS Queries over HTTPS (DoH)"</span>, <span class="seriesInfo">RFC 8484</span>, <span class="seriesInfo">DOI 10.17487/RFC8484</span>, <time datetime="2018-10">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8484">https://www.rfc-editor.org/info/rfc8484</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="About-DNS64">[About-DNS64]</dt>
        <dd>
<span class="refAuthor">Linkova, J.</span>, <span class="refTitle">"Let's talk about IPv6 DNS64 &amp; DNSSEC"</span>, <time datetime="2016-06">June 2016</time>, <span>&lt;<a href="https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/">https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/</a>&gt;</span>. </dd>
<dt id="ARCEP">[ARCEP]</dt>
        <dd>
<span class="refAuthor">ARCEP</span>, <span class="refTitle">"Service client des operateurs : les mesures de qualite de service"</span>, <time datetime="2018-04">April 2018</time>, <span>&lt;<a href="https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/service-client-des-operateurs-mesures-de-la-qualite-de-service/service-client-des-operateurs-les-mesures-de-qualite-de-service.html">https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/service-client-des-operateurs-mesures-de-la-qualite-de-service/service-client-des-operateurs-les-mesures-de-qualite-de-service.html</a>&gt;</span>. </dd>
<dt id="I-D.li-intarea-nat64-prefix-dhcp-option">[DHCPv6-OPTIONS]</dt>
        <dd>
<span class="refAuthor">Li, L.</span><span class="refAuthor">, Cui, Y.</span><span class="refAuthor">, Liu, C.</span><span class="refAuthor">, Wu, J.</span><span class="refAuthor">, Baker, F.</span><span class="refAuthor">, and J. Palet</span>, <span class="refTitle">"DHCPv6 Options for Discovery NAT64 Prefixes"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-li-intarea-nat64-prefix-dhcp-option-02</span>, <time datetime="2019-04-20">20 April 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-li-intarea-nat64-prefix-dhcp-option-02">https://tools.ietf.org/html/draft-li-intarea-nat64-prefix-dhcp-option-02</a>&gt;</span>. </dd>
<dt id="I-D.bp-v6ops-ipv6-ready-dns-dnssec">[DNS-DNSSEC]</dt>
        <dd>
<span class="refAuthor">Byrne, C.</span><span class="refAuthor"> and J. Palet</span>, <span class="refTitle">"IPv6-Ready DNS/DNSSSEC Infrastructure"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-bp-v6ops-ipv6-ready-dns-dnssec-00</span>, <time datetime="2018-10-10">10 October 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00">https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00</a>&gt;</span>. </dd>
<dt id="I-D.vixie-dnsop-dns-rpz">[DNS-RPZ]</dt>
        <dd>
<span class="refAuthor">Vixie, P.</span><span class="refAuthor"> and V. Schryver</span>, <span class="refTitle">"DNS Response Policy Zones (RPZ)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-vixie-dnsop-dns-rpz-00</span>, <time datetime="2018-06-23">23 June 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz-00">https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz-00</a>&gt;</span>. </dd>
<dt id="DNS64-Benchm">[DNS64-Benchm]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span><span class="refAuthor"> and Y. Kadobayashi</span>, <span class="refTitle">"Benchmarking DNS64 Implementations: Theory and Practice"</span>, <span class="refContent">pp. 61-74, no. 1, vol. 127, Computer Communications</span>, <span class="seriesInfo">DOI 10.1016/j.comcom.2018.05.005</span>, <time datetime="2018-09">September 2018</time>, <span>&lt;<a href="https://www.sciencedirect.com/science/article/pii/S0140366418302184?via%3Dihub">https://www.sciencedirect.com/science/article/pii/S0140366418302184?via%3Dihub</a>&gt;</span>. </dd>
<dt id="DNS64-BM-Meth">[DNS64-BM-Meth]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span><span class="refAuthor">, Georgescu, M.</span><span class="refAuthor">, and Y. Kadobayashi</span>, <span class="refTitle">"Benchmarking Methodology for DNS64 Servers"</span>, <span class="refContent">pp. 162-175, no. 1, vol. 109, Computer Communications</span>, <span class="seriesInfo">DOI 10.1016/j.comcom.2017.06.004</span>, <time datetime="2017-09">September 2017</time>, <span>&lt;<a href="https://www.sciencedirect.com/science/article/pii/S0140366416305904?via%3Dihub">https://www.sciencedirect.com/science/article/pii/S0140366416305904?via%3Dihub</a>&gt;</span>. </dd>
<dt id="FCC">[FCC]</dt>
        <dd>
<span class="refAuthor">FCC</span>, <span class="refTitle">"Measuring Broadband America Mobile 2013-2018 Coarsened Data"</span>, <time datetime="2018-12">December 2018</time>, <span>&lt;<a href="https://www.fcc.gov/reports-research/reports/measuring-broadband-america/measuring-broadband-america-mobile-2013-2018">https://www.fcc.gov/reports-research/reports/measuring-broadband-america/measuring-broadband-america-mobile-2013-2018</a>&gt;</span>. </dd>
<dt id="I-D.cheshire-sudn-ipv4only-dot-arpa">[IPV4ONLY-ARPA]</dt>
        <dd>
<span class="refAuthor">Cheshire, S.</span><span class="refAuthor"> and D. Schinazi</span>, <span class="refTitle">"Special Use Domain Name 'ipv4only.arpa'"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-cheshire-sudn-ipv4only-dot-arpa-14</span>, <time datetime="2018-11-03">3 November 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa-14">https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa-14</a>&gt;</span>. </dd>
<dt id="I-D.lmhp-v6ops-transition-comparison">[IPv6-TRANSITION]</dt>
        <dd>
<span class="refAuthor">Lencse, G.</span><span class="refAuthor">, Palet, J.</span><span class="refAuthor">, Howard, L.</span><span class="refAuthor">, Patterson, R.</span><span class="refAuthor">, and I. Farrer</span>, <span class="refTitle">"Pros and Cons of IPv6 Transition Technologies for IPv4aaS"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-lmhp-v6ops-transition-comparison-03</span>, <time datetime="2019-07-06">6 July 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-03">https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-03</a>&gt;</span>. </dd>
<dt id="ISOC">[ISOC]</dt>
        <dd>
<span class="refAuthor">ISOC</span>, <span class="refTitle">"State of IPv6 Deployment 2018"</span>, <time datetime="2018-06">June 2018</time>, <span>&lt;<a href="https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/">https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/</a>&gt;</span>. </dd>
<dt id="I-D.palet-v6ops-464xlat-opt-cdn-caches">[OPT-464XLAT]</dt>
        <dd>
<span class="refAuthor">Palet, J.</span><span class="refAuthor"> and A. D'Egidio</span>, <span class="refTitle">"464XLAT Optimization"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-palet-v6ops-464xlat-opt-cdn-caches-03</span>, <time datetime="2019-07-08">8 July 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-cdn-caches-03">https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-cdn-caches-03</a>&gt;</span>. </dd>
<dt id="I-D.ietf-6man-ra-pref64">[PREF64]</dt>
        <dd>
<span class="refAuthor">Colitti, L.</span><span class="refAuthor"> and J. Linkova</span>, <span class="refTitle">"Discovering PREF64 in Router Advertisements"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-6man-ra-pref64-06</span>, <time datetime="2019-10-03">3 October 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-6man-ra-pref64-06">https://tools.ietf.org/html/draft-ietf-6man-ra-pref64-06</a>&gt;</span>. </dd>
<dt id="I-D.huitema-quic-dnsoquic">[QUIC-CONNECTIONS]</dt>
        <dd>
<span class="refAuthor">Huitema, C.</span><span class="refAuthor">, Shore, M.</span><span class="refAuthor">, Mankin, A.</span><span class="refAuthor">, Dickinson, S.</span><span class="refAuthor">, and J. Iyengar</span>, <span class="refTitle">"Specification of DNS over Dedicated QUIC Connections"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-huitema-quic-dnsoquic-07</span>, <time datetime="2019-09-07">7 September 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07">https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07</a>&gt;</span>. </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><span class="refAuthor">, and 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">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>
<dt id="RFC6950">[RFC6950]</dt>
        <dd>
<span class="refAuthor">Peterson, J.</span><span class="refAuthor">, Kolkman, O.</span><span class="refAuthor">, Tschofenig, H.</span><span class="refAuthor">, and B. Aboba</span>, <span class="refTitle">"Architectural Considerations on Application Features in the DNS"</span>, <span class="seriesInfo">RFC 6950</span>, <span class="seriesInfo">DOI 10.17487/RFC6950</span>, <time datetime="2013-10">October 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6950">https://www.rfc-editor.org/info/rfc6950</a>&gt;</span>. </dd>
<dt id="RFC7051">[RFC7051]</dt>
        <dd>
<span class="refAuthor">Korhonen, J., Ed.</span><span class="refAuthor"> and T. Savolainen, Ed.</span>, <span class="refTitle">"Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix"</span>, <span class="seriesInfo">RFC 7051</span>, <span class="seriesInfo">DOI 10.17487/RFC7051</span>, <time datetime="2013-11">November 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7051">https://www.rfc-editor.org/info/rfc7051</a>&gt;</span>. </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><span class="refAuthor">, and 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">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>
<dt id="RFC7755">[RFC7755]</dt>
        <dd>
<span class="refAuthor">Anderson, T.</span>, <span class="refTitle">"SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments"</span>, <span class="seriesInfo">RFC 7755</span>, <span class="seriesInfo">DOI 10.17487/RFC7755</span>, <time datetime="2016-02">February 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7755">https://www.rfc-editor.org/info/rfc7755</a>&gt;</span>. </dd>
<dt id="RFC7756">[RFC7756]</dt>
        <dd>
<span class="refAuthor">Anderson, T.</span><span class="refAuthor"> and S. Steffann</span>, <span class="refTitle">"Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode"</span>, <span class="seriesInfo">RFC 7756</span>, <span class="seriesInfo">DOI 10.17487/RFC7756</span>, <time datetime="2016-02">February 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7756">https://www.rfc-editor.org/info/rfc7756</a>&gt;</span>. </dd>
<dt id="RFC7849">[RFC7849]</dt>
        <dd>
<span class="refAuthor">Binet, D.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, Vizdal, A.</span><span class="refAuthor">, Chen, G.</span><span class="refAuthor">, Heatley, N.</span><span class="refAuthor">, Chandler, R.</span><span class="refAuthor">, Michaud, D.</span><span class="refAuthor">, Lopez, D.</span><span class="refAuthor">, and W. Haeffner</span>, <span class="refTitle">"An IPv6 Profile for 3GPP Mobile Devices"</span>, <span class="seriesInfo">RFC 7849</span>, <span class="seriesInfo">DOI 10.17487/RFC7849</span>, <time datetime="2016-05">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7849">https://www.rfc-editor.org/info/rfc7849</a>&gt;</span>. </dd>
<dt id="RFC7858">[RFC7858]</dt>
        <dd>
<span class="refAuthor">Hu, Z.</span><span class="refAuthor">, Zhu, L.</span><span class="refAuthor">, Heidemann, J.</span><span class="refAuthor">, Mankin, A.</span><span class="refAuthor">, Wessels, D.</span><span class="refAuthor">, and P. Hoffman</span>, <span class="refTitle">"Specification for DNS over Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 7858</span>, <span class="seriesInfo">DOI 10.17487/RFC7858</span>, <time datetime="2016-05">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7858">https://www.rfc-editor.org/info/rfc7858</a>&gt;</span>. </dd>
<dt id="RFC8094">[RFC8094]</dt>
        <dd>
<span class="refAuthor">Reddy, T.</span><span class="refAuthor">, Wing, D.</span><span class="refAuthor">, and P. Patil</span>, <span class="refTitle">"DNS over Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">RFC 8094</span>, <span class="seriesInfo">DOI 10.17487/RFC8094</span>, <time datetime="2017-02">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8094">https://www.rfc-editor.org/info/rfc8094</a>&gt;</span>. </dd>
<dt id="RFC8219">[RFC8219]</dt>
        <dd>
<span class="refAuthor">Georgescu, M.</span><span class="refAuthor">, Pislaru, L.</span><span class="refAuthor">, and 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">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>
<dt id="RFC8585">[RFC8585]</dt>
        <dd>
<span class="refAuthor">Palet Martinez, J.</span><span class="refAuthor">, Liu, H. M.-H.</span><span class="refAuthor">, and M. Kawashima</span>, <span class="refTitle">"Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service"</span>, <span class="seriesInfo">RFC 8585</span>, <span class="seriesInfo">DOI 10.17487/RFC8585</span>, <time datetime="2019-05">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8585">https://www.rfc-editor.org/info/rfc8585</a>&gt;</span>. </dd>
<dt id="RIPE-690">[RIPE-690]</dt>
        <dd>
<span class="refAuthor">RIPE</span>, <span class="refTitle">"Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose"</span>, <time datetime="2017-10">October 2017</time>, <span>&lt;<a href="https://www.ripe.net/publications/docs/ripe-690">https://www.ripe.net/publications/docs/ripe-690</a>&gt;</span>. </dd>
<dt id="Threat-DNS64">[Threat-DNS64]</dt>
      <dd>
<span class="refAuthor">Lencse, G.</span><span class="refAuthor"> and 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">pp. 397-411, no. 1, vol. 77, Computers &amp; Security</span>, <span class="seriesInfo">DOI 10.1016/j.cose.2018.04.012</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.sciencedirect.com/science/article/pii/S0167404818303663?via%3Dihub">https://www.sciencedirect.com/science/article/pii/S0167404818303663?via%3Dihub</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="AppendixA">
<section id="section-appendix.a">
      <h2 id="name-example-of-broadband-deploy">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-example-of-broadband-deploy" class="section-name selfRef">Example of Broadband Deployment with 464XLAT</a>
      </h2>
<p id="section-appendix.a-1">This section summarizes how an operator may deploy an IPv6-only 
      network for residential/SOHO customers, supporting IPv6 inbound 
      connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">Note that an equivalent setup could also be provided for enterprise 
      customers. If they need to support IPv4 inbound connections, several 
      mechanisms, depending on specific customer needs, allow it; see 
      <span>[<a href="#RFC7757" class="xref">RFC7757</a>]</span>.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">Conceptually, most of the operator network could be IPv6 only 
   (represented in the next figures as "IPv6-only flow"), or even if 
   part of the network is actually dual stack, only IPv6 access 
   is available for some customers (i.e., residential customers). 
   This part of the network connects the IPv6-only subscribers 
   (by means of IPv6-only access links) to the IPv6 upstream providers 
   and to the IPv4-Internet by means of NAT64 (PLAT 
   in the 464XLAT terminology).<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">The traffic flow from and back to the CE to services available in the 
   IPv6 Internet (or even dual-stack remote services, when IPv6 is being used) 
   is purely native IPv6 traffic, so there are no special considerations about it.<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<p id="section-appendix.a-5">From the DNS perspective, there are remote 
   networks with IPv4 only that will typically have only IPv4 DNS 
   (DNS/IPv4) or will at least be seen as IPv4 DNS from the CE perspective. 
   On the operator side, the DNS, as seen from the CE, is 
   only IPv6 (DNS/IPv6), and it also has a DNS64 function.<a href="#section-appendix.a-5" class="pilcrow">¶</a></p>
<p id="section-appendix.a-6">On the customer LANs side, there is actually one network, which of course 
   could be split into different segments. The most common setup will be 
   dual-stack segments, using global IPv6 addresses and <span>[<a href="#RFC1918" class="xref">RFC1918</a>]</span> 
   for IPv4, in any regular residential / Small Office, Home Office (SOHO) IPv4 network. 
   In the figure below, it is represented as tree segments to show that the 
   three possible setups are valid (IPv6 only, IPv4 only, and dual stack).<a href="#section-appendix.a-6" class="pilcrow">¶</a></p>
<span id="name-ce-setup-with-built-in-clat"></span><div id="clat-CE-DNS64">
<figure id="figure-16">
        <div class="artwork art-text alignCenter" id="section-appendix.a-7.1">
<pre>
    .-----.    +-------+     .-----.                   .-----.
   / IPv6- \   |       |    /       \                 /       \
  (  only   )--+ Res./ |   /  IPv6-  \    .-----.    /  IPv4-  \
   \ LANs  /   | SOHO  +--(   only    )--( NAT64 )--(   only    )
    `-----'    |       |   \  flow   /    `-----'    \  flow   /
    .-----.    | IPv6  |    \       /                 \       /
   / IPv4- \   |  CE   |     `--+--'                   `--+--'
  (  only   )--+ with  |        |                         |
   \ LANs  /   | CLAT  |    +---+----+                +---+----+
    `-----'    |       |    |DNS/IPv6|                |DNS/IPv4|
    .-----.    +---+---+    |  with  |                +--------+
   / Dual- \       |        | DNS64  |
  (  Stack  )------|        +--------+
   \ LANs  /
    `-----' </pre>
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
<a href="#name-ce-setup-with-built-in-clat" class="selfRef">CE Setup with Built-In CLAT, with DNS64</a>
        </figcaption></figure>
</div>
<p id="section-appendix.a-8">In addition to the regular CE setup, which typically will be
   access-technology dependent, the steps for the CLAT function 
   configuration can be summarized as follows:<a href="#section-appendix.a-8" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-appendix.a-9">
        <li id="section-appendix.a-9.1">Discovery of the PLAT (NAT64) prefix: It may be done 
 using <span>[<a href="#RFC7050" class="xref">RFC7050</a>]</span>, <span>[<a href="#RFC7225" class="xref">RFC7225</a>]</span> in those networks where PCP 
 is supported, or other 
 alternatives that may be available in the future, such as Router 
 Advertising <span>[<a href="#I-D.ietf-6man-ra-pref64" class="xref">PREF64</a>]</span> or 
 DHCPv6 options <span>[<a href="#I-D.li-intarea-nat64-prefix-dhcp-option" class="xref">DHCPv6-OPTIONS</a>]</span>.<a href="#section-appendix.a-9.1" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.a-9.2">If the CLAT function allows stateless NAT46 translation, a /64 from 
 the pool typically provided to the CE by means of DHCPv6-PD 
 <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span> needs to be set aside for that translation. 
 Otherwise, the CLAT is forced to perform an intermediate stateful 
 NAT44 before the stateless NAT46, as described in <a href="#CLAT" class="xref">Section 4.8</a>.<a href="#section-appendix.a-9.2" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-appendix.a-10">A more detailed configuration approach is described in 
   <span>[<a href="#RFC8585" class="xref">RFC8585</a>]</span>.<a href="#section-appendix.a-10" class="pilcrow">¶</a></p>
<p id="section-appendix.a-11">The operator network needs to ensure that the correct responses are provided 
   for the discovery of the PLAT prefix. It is highly recommended 
   that <span>[<a href="#RIPE-690" class="xref">RIPE-690</a>]</span> be followed in order to ensure that multiple /64s 
   are available, including the one needed for the NAT46 stateless translation.<a href="#section-appendix.a-11" class="pilcrow">¶</a></p>
<p id="section-appendix.a-12">The operator needs to understand other issues, as described throughout this document, 
   in order to make relevant decisions. For example, if several NAT64 functions 
   are needed in the context of scalability / high availability, an NSP should be 
   considered (see <a href="#WKP-NSP" class="xref">Section 4.5</a>).<a href="#section-appendix.a-12" class="pilcrow">¶</a></p>
<p id="section-appendix.a-13">More complex scenarios are possible, for example, if a network offers 
   multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.<a href="#section-appendix.a-13" class="pilcrow">¶</a></p>
<p id="section-appendix.a-14">If the operator decides not to provide a DNS64 function, then this 
   setup will be the same as the following figure. This will also be
   the setup that will be seen from the perspective 
   of the CE, if a foreign DNS is used and consequently is 
   not the operator-provided DNS64 function.<a href="#section-appendix.a-14" class="pilcrow">¶</a></p>
<span id="name-ce-setup-with-built-in-clat-"></span><div id="clat-CE">
<figure id="figure-17">
        <div class="artwork art-text alignCenter" id="section-appendix.a-15.1">
<pre>
    .-----.    +-------+     .-----.                   .-----.
   / IPv6- \   |       |    /       \                 /       \
  (  only   )--+ Res./ |   /  IPv6-  \    .-----.    /  IPv4-  \
   \ LANs  /   | SOHO  +--(   only    )--( NAT64 )--(   only    )
    `-----'    |       |   \  flow   /    `-----'    \  flow   /
    .-----.    | IPv6  |    \       /                 \       /
   / IPv4- \   |  CE   |     `--+--'                   `--+--'
  (  only   )--+ with  |        |                         |
   \ LANs  /   | CLAT  |    +---+----+                +---+----+
    `-----'    |       |    |DNS/IPv6|                |DNS/IPv4|
    .-----.    +---+---+    +--------+                +--------+
   / Dual- \       |
  (  Stack  )------|
   \ LANs  /
    `-----'</pre>
</div>
<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
<a href="#name-ce-setup-with-built-in-clat-" class="selfRef">CE Setup with Built-In CLAT, without DNS64</a>
        </figcaption></figure>
</div>
<p id="section-appendix.a-16">In this case, the discovery of the PLAT prefix needs to be arranged as 
   indicated in <a href="#nodns64" class="xref">Section 4.1.1</a>.<a href="#section-appendix.a-16" class="pilcrow">¶</a></p>
<p id="section-appendix.a-17">In addition, if the CE doesn't have a built-in CLAT function, the customer can 
   choose to set up the IPv6 operator-managed CE in bridge mode (and optionally 
   use an external router).  Or, for example, if there is an access technology 
   that requires some kind of media converter (Optical Network Termination (ONT) for 
          fiber to the home (FTTH), Cable Modem 
   for Data-Over-Cable Service Interface Specification (DOCSIS), etc.), the complete 
          setup will look like <a href="#clat-bridge" class="xref">Figure 18</a>. 

   Obviously, there will be some intermediate configuration steps for the 
   bridge, depending on the specific access technology/protocols, which 
   should not modify the steps already described in the previous cases 
   for the CLAT function configuration.<a href="#section-appendix.a-17" class="pilcrow">¶</a></p>
<span id="name-ce-setup-with-bridged-clat-"></span><div id="clat-bridge">
<figure id="figure-18">
        <div class="artwork art-text alignCenter" id="section-appendix.a-18.1">
<pre>
               +-------+     .-----.                   .-----.
               |       |    /       \                 /       \
               | Res./ |   /  IPv6-  \    .-----.    /  IPv4-  \
               | SOHO  +--(   only    )--( NAT64 )--(   only    )
               |       |   \  flow   /    `-----'    \  flow   /
               | IPv6  |    \       /                 \       /
               |  CE   |     `--+--'                   `--+--'
               | Bridge|        |                         |
               |       |    +---+----+                +---+----+
               |       |    |DNS/IPv6|                |DNS/IPv4|
               +---+---+    +--------+                +--------+
                   |
    .-----.    +---+---+
   / IPv6- \   |       |
  (  only   )--+ IPv6  |
   \ LANs  /   | Router|
    `-----'    |       |
    .-----.    | with  |
   / IPv4- \   | CLAT  |
  (  only   )--+       |
   \ LANs  /   |       |
    `-----'    |       |
    .-----.    +---+---+
   / Dual- \       |
  (  Stack  )------|
   \ LANs  /
    `-----'</pre>
</div>
<figcaption><a href="#figure-18" class="selfRef">Figure 18</a>:
<a href="#name-ce-setup-with-bridged-clat-" class="selfRef">CE Setup with Bridged CLAT, without DNS64</a>
        </figcaption></figure>
</div>
<p id="section-appendix.a-19">Several routers (i.e., the operator-provided
                 CE and the downstream user-provided router) that enable
                 simultaneous routing and/or CLAT should be avoided to ensure that  multiple NAT44
                 and NAT46 levels are not used and that the operation of
                 multiple IPv6 subnets is correct.  In those cases, 
  the use of the Home Networking Control Protocol (HNCP) <span>[<a href="#RFC8375" class="xref">RFC8375</a>]</span> is suggested.<a href="#section-appendix.a-19" class="pilcrow">¶</a></p>
<p id="section-appendix.a-20">Note that the procedure described here for the CE setup can be simplified 
 if the CE follows <span>[<a href="#RFC8585" class="xref">RFC8585</a>]</span>.<a href="#section-appendix.a-20" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-appendix.b">
      <h2 id="name-clat-implementation">
<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-clat-implementation" class="section-name selfRef">CLAT Implementation</a>
      </h2>
<p id="section-appendix.b-1">In addition to the regular set of features for a CE, a CLAT CE 
 implementation requires support for:<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-appendix.b-2.1">
          <span>[<a href="#RFC7915" class="xref">RFC7915</a>]</span> for the NAT46 function.<a href="#section-appendix.b-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.b-2.2">
          <span>[<a href="#RFC7050" class="xref">RFC7050</a>]</span> for the PLAT prefix discovery.<a href="#section-appendix.b-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.b-2.3">
          <span>[<a href="#RFC7225" class="xref">RFC7225</a>]</span> for the PLAT prefix discovery if PCP is supported.<a href="#section-appendix.b-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.b-2.4">
          <span>[<a href="#I-D.ietf-6man-ra-pref64" class="xref">PREF64</a>]</span> for the PLAT prefix 
   discovery by means of Router Advertising.<a href="#section-appendix.b-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.b-2.5">
          <span>[<a href="#I-D.li-intarea-nat64-prefix-dhcp-option" class="xref">DHCPv6-OPTIONS</a>]</span> for the PLAT prefix 
   discovery by means of DHCP.<a href="#section-appendix.b-2.5" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.b-2.6">If stateless NAT46 is supported, a mechanism to ensure that 
   multiple /64 are available, such as DHCPv6-PD <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>, must be used.<a href="#section-appendix.b-2.6" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-appendix.b-3">There are several Open Source implementations of CLAT, such as:<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
<ul>
<li id="section-appendix.b-4.1">Android: <span><a href="https://github.com/ddrown/android_external_android-clat">https://github.com/ddrown/android_external_android-clat</a></span><a href="#section-appendix.b-4.1" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.b-4.2">Jool: <span><a href="https://www.jool.mx">https://www.jool.mx</a></span><a href="#section-appendix.b-4.2" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.b-4.3">Linux: <span><a href="https://github.com/toreanderson/clatd">https://github.com/toreanderson/clatd</a></span><a href="#section-appendix.b-4.3" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.b-4.4">OpenWRT: <span><a href="https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&amp;a=search&amp;h=refs%2Ftags%2Fv19.07.0-rc1&amp;st=commit&amp;s=464xlat">https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&amp;a=search&amp;h=refs%2Ftags%2Fv19.07.0-rc1&amp;st=commit&amp;s=464xlat</a></span><a href="#section-appendix.b-4.4" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.b-4.5">VPP: <span><a href="https://git.fd.io/vpp/tree/src/plugins/nat">https://git.fd.io/vpp/tree/src/plugins/nat</a></span><a href="#section-appendix.b-4.5" class="pilcrow">¶</a>
</li>
      </ul>
</section>
<section id="section-appendix.c">
      <h2 id="name-benchmarking">
<a href="#section-appendix.c" class="section-number selfRef">Appendix C. </a><a href="#name-benchmarking" class="section-name selfRef">Benchmarking</a>
      </h2>
<p id="section-appendix.c-1">A benchmarking methodology for IPv6 
 transition technologies has been defined in <span>[<a href="#RFC8219" class="xref">RFC8219</a>]</span>. NAT64 and 464XLAT are addressed 
                among the single- and 
 double-translation technologies, respectively. DNS64 is addressed in 
 Section <a href="https://www.rfc-editor.org/rfc/rfc8219#section-9" class="relref">9</a>, and the methodology is elaborated in
      <span>[<a href="#DNS64-BM-Meth" class="xref">DNS64-BM-Meth</a>]</span> of that document.<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<p id="section-appendix.c-2">Several documents provide references to benchmarking results, for example, 
 for DNS64 <span>[<a href="#DNS64-Benchm" class="xref">DNS64-Benchm</a>]</span>.<a href="#section-appendix.c-2" class="pilcrow">¶</a></p>
</section>
<section id="section-appendix.d">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.d-1">The author would like to acknowledge the inputs of Gabor Lencse, 
 Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, 
 Mohamed Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson, 
 and Eric Vyncke.<a href="#section-appendix.d-1" class="pilcrow">¶</a></p>
<p id="section-appendix.d-2">Conversations with Marcelo Bagnulo, one of the coauthors of NAT64 and 
 DNS64, and email correspondence via the IETF mailing lists with Mark Andrews
 have been very useful for this work.<a href="#section-appendix.d-2" class="pilcrow">¶</a></p>
<p id="section-appendix.d-3">Work on this document was inspired by Christian Huitema, who suggested 
 that DNS64 should never be used when deploying CLAT
 in the IETF network.<a href="#section-appendix.d-3" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.e">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<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>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>