rfc8683xml2.original.xml   rfc8683.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc compact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
<?rfc tocdepth="6"?> docName="draft-ietf-v6ops-nat64-deployment-08" submissionType="IETF" consen
<?rfc symrefs="yes"?> sus="true" number="8683" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
<?rfc sortrefs="yes"?> tocInclude="true" tocDepth="6" symRefs="true" sortRefs="true" version="3">
<?rfc autobreaks="no"?> <!-- xml2rfc v2v3 conversion 2.35.0 -->
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" submissionType="IETF" consensus="yes"
docName="draft-ietf-v6ops-nat64-deployment-08">
<front> <front>
<title abbrev="NAT64/464XLAT Deployment"> <title abbrev="NAT64/464XLAT Deployment">
Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Netw Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise
orks</title> Networks</title>
<seriesInfo name="RFC" value="8683"/>
<author fullname="Jordi Palet Martinez" initials="J" surname="Palet Martinez "> <author fullname="Jordi Palet Martinez" initials="J" surname="Palet Martinez ">
<organization>The IPv6 Company</organization> <organization>The IPv6 Company</organization>
<address> <address>
<postal> <postal>
<street>Molino de la Navata, 75</street> <street>Molino de la Navata, 75</street>
<city>La Navata - Galapagar</city> <city>La Navata - Galapagar</city>
<region>Madrid</region> <region>Madrid</region>
<code>28420</code> <code>28420</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>jordi.palet@theipv6company.com</email> <email>jordi.palet@theipv6company.com</email>
<uri>http://www.theipv6company.com/</uri> <uri>http://www.theipv6company.com/</uri>
</address> </address>
</author> </author>
<date year="2019" month="November"/>
<date year="2019"/> <workgroup>v6ops</workgroup>
<workgroup>v6ops</workgroup>
<keyword> <keyword>
IPv6, DNSSEC, NAT64, DNS64, 464XLAT, CLAT, NAT46, PLAT IPv6, DNSSEC, NAT64, DNS64, 464XLAT, CLAT, NAT46, PLAT
</keyword> </keyword>
<abstract>
<abstract> <t>This document describes how Network Address and Protocol
<t>This document describes how NAT64 (including 464XLAT) Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can
can be deployed be deployed
in an IPv6 network, whether cellular ISP, broadband ISP, in an IPv6 network -- whether it's cellular ISP, broadban
or enterprise, and possible optimizations. d ISP,
The document also discusses issues to be considered when or enterprise -- and the possible
having optimizations.
IPv6-only connectivity, regarding: This document also discusses issues to be considered when
having
IPv6-only connectivity, such as:
a) DNS64, a) DNS64,
b) applications or devices that use literal IPv4 addresse s or b) applications or devices that use literal IPv4 addresse s or
non-IPv6 compliant APIs, non-IPv6-compliant APIs,
and c) IPv4-only hosts or applications.</t> and c) IPv4-only hosts or applications.</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<name>Introduction</name>
<section title="Introduction"> <t>Stateful NAT64 <xref target="RFC6146" format="default"/> describes a st
<t>Stateful NAT64 (<xref target="RFC6146"/>) describes a stateful ateful IPv6-to-IPv4
IPv6 to IPv4 translation mechanism that allows IPv6-only hosts to communicate
translation mechanism, which allows IPv6-only hosts to communicat with
e with IPv4-only servers using unicast UDP, TCP, or ICMP by means of IPv
IPv4-only servers using unicast UDP, TCP, or ICMP, by means of IP 4 public
v4 public address sharing among multiple IPv6-only
addresses sharing, among multiple IPv6-only hosts. Unless otherwise stated, references
hosts. Unless otherwise stated, references in the rest of this do to NAT64 (function) in this document should be interpreted as Sta
cument teful NAT64.</t>
to NAT64 (function) should be interpreted as to Stateful NAT64.</ <t>The translation of the packet headers is done using the IP/ICMP
t> translation algorithm defined in <xref target="RFC7915" format="d
efault"/>;
<t>The translation of the packet headers is done using the IP/ICM algorithmically translating the IPv4 addresses to IPv6 addresses,
P and vice versa, is done following <xref target="RFC6052" format="
translation algorithm defined in <xref target="RFC7915"/> and default"/>.</t>
algorithmically translating the IPv4 addresses to IPv6 addresses <t>DNS64 <xref target="RFC6147" format="default"/> is in charge of the syn
and vice versa, following <xref target="RFC6052"/>.</t> thesis
of AAAA records from the A records, so it only works for applicat
<t>DNS64 (<xref target="RFC6147"/>) is in charge of the synthesis ions
of AAAA records from the A records, so only works for application making use of DNS. It was designed to avoid changes in both
s
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 the IPv6-only hosts and the IPv4-only server, so they can use
a NAT64 function. As discussed in Section 5.5 of <xref target="RF a NAT64 function. As discussed in <xref
C6147"/>, target="RFC6147" sectionFormat="of" section="5.5"/>,
a security-aware and validating host has to perform the a security-aware and validating host has to perform the
DNS64 function locally.</t> DNS64 function locally.</t>
<t>However, the use of NAT64 and/or DNS64 presents three drawbacks:</t>
<ol spacing="normal" type="1">
<t>However, the use of NAT64 and/or DNS64 present three drawbacks <li>Because DNS64 <xref target="RFC6147" format="default"/> modifies DNS
:</t> answers,
<t><list style="letters">
<t>Because DNS64 (<xref target="RFC6147"/>) modifies DNS
answers,
and DNSSEC is designed to detect such modifications, DNS6 4 and DNSSEC is designed to detect such modifications, DNS6 4
(<xref target="RFC6147"/>) may potentially break DNSSEC, <xref target="RFC6147" format="default"/> may potentially
depending on break DNSSEC, depending on
a number of factors, such as the location of the DNS64 a number of factors such as the location of the DNS64
function (at a DNS server or validator, at the end host, ...), how it function (at a DNS server or validator, at the end host, ...), how it
has been configured, if the end-hosts is validating, etc. has been configured, if the end hosts are validating, etc
</t> .</li>
<li>Because of the need to use DNS64 <xref target="RFC6147" format="defa
<t>Because the need of using DNS64 (<xref target="RFC6147 ult"/> or
"/>) or
an alternative "host/application built-in" mechanism for address synthesis, an alternative "host/application built-in" mechanism for address synthesis,
there may be an issue for NAT64 (<xref target="RFC6146"/> there may be an issue for NAT64 <xref target="RFC6146" fo
), rmat="default"/>
as it doesn't work when IPv4 literal addresses or non-IPv because it doesn't work when IPv4 literal addresses or no
6 compliant n-IPv6-compliant
APIs are being used.</t> APIs are being used.</li>
<t>NAT64 alone, was not designed to provide a solution fo
r
IPv4-only hosts or applications located within a network
which are connected to a service provider IPv6-only acces
s,
as it was designed for a very specific scenario (<xref ta
rget="RFC6144"/>, Section 2.1).</t>
</list></t>
<t>Above drawbacks may be true if part of, an enterprise network, <li>NAT64 alone was not designed to provide a solution for
is connected to other parts of the same network or third-party ne IPv4-only hosts or applications that are located within a
tworks network
by means of IPv6-only connectivity. This is just an example which and connected to a service provider IPv6-only access link
may ,
apply to many other similar cases. All them are deployment specif as it was designed for a very specific
ic.</t> scenario (see <xref target="RFC6144" sectionFormat="of" section="2.1"/>).
</li>
</ol>
<t>The drawbacks discussed above may come into play if part of an enterpri
se 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 spe
cific.</t>
<t>According to that, across this document, the use of "operator" <t>Accordingly, the use of "operator",
, "operator network", "service provider", and similar terms in this
"operator network", "service provider", and similar ones, document
are interchangeable with equivalent cases of enterprise networks are interchangeable with equivalent cases of enterprise networks;
(and similar ones). This may be also the case for "managed end-us other cases may be similar as well. This may be also the case for "managed end-
er user
networks".</t> networks".</t>
<t>Note that if all the hosts in a network were performing address synthes
<t>Note that if all the hosts in a network were performing the ad is,
dress synthesis, as described in <xref target="RFC6147"
as described in Section 7.2 of <xref target="RFC6147"/>, some of sectionFormat="of" section="7.2"/>, some of the drawbacks
the drawbacks may not apply. However, it is unrealistic to expect
may vanish. However, it is unrealistic today to expect that, cons that in today's world, considering
idering the high number of devices and applications that aren't yet IPv6
the high number of devices and applications that aren't yet IPv6- enabled.
enabled. In this document, the case in which all hosts provide synthesis w
So, in this document, this will be considered only for specific s ill be considered only for specific scenarios
cenarios
that can guarantee it.</t> that can guarantee it.</t>
<t>An analysis of stateful IPv4/IPv6 mechanisms is provided in
<t>An analysis of stateful IPv4/IPv6 mechanisms is provided in <xref target="RFC6889" format="default"/>.</t>
<xref target="RFC6889"/>.</t> <t>This document looks into different possible NAT64 <xref target="RFC6146
" format="default"/>
<t>This document looks into different possible NAT64 (<xref targe deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) an
t="RFC6146"/>) d similar ones
deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) an that were not documented in <xref target="RFC6144" format="defaul
d similar ones, t"/>, such as 464XLAT
which were not documented in <xref target="RFC6144"/>, such as 46 <xref target="RFC6877" format="default"/> in operator (broadband
4XLAT and cellular) and
(<xref target="RFC6877"/>), in operator (broadband and cellular) enterprise networks; it provides guidelines to avoid operational
and issues.</t>
enterprise networks, and provides guidelines to avoid operational <t>This document also explores the possible NAT64 deployment
issues.</t>
<t>Towards that, this document first looks into the possible NAT6
4 deployment
scenarios (split in "known to work" and "known to work under spec ial conditions"), scenarios (split in "known to work" and "known to work under spec ial conditions"),
providing a quick and generic comparison table among them. providing a quick and generic comparison table among them.
Then the document describes the issues that an operator need to u Then, the document describes the issues that an operator needs to
nderstand understand, which
on different matters that will allow to define what is the best will allow the best
approach/scenario for each specific network case. A summary provi approach/scenario to be defined for each specific network case. A
des some summary provides some
recommendations and decision points. A section with clarification recommendations and decision points.
s
on the usage of this document for enterprise networks, is also pr
ovided.
Finally, an annex provides an example of a broadband deployment u
sing 464XLAT
and another annex provides hints for a CLAT implementation.</t>
<t><xref target="RFC7269"/> already provides information about
NAT64 deployment options and experiences. Both, this document and
<xref target="RFC7269"/> are complementary; they are looking into
different deployment considerations and furthermore, this documen
t is
considering the updated deployment experience and newer standards
.</t>
<t>The target deployment scenarios in this document may be covere A section with clarifications
d as well on the usage of this document for enterprise networks is also pro
by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. Note vided.
that this is Finally, <xref target="AppendixA"/> provides an example of a broa
true only for the case of broadband networks, as in the case of c dband deployment using 464XLAT
ellular and hints for a customer-side translator (CLAT) implementation.</
networks the only supported solution is the use of NAT64/464XLAT. t>
<t><xref target="RFC7269" format="default"/> already provides information
about
NAT64 deployment options and experiences. This document and
<xref target="RFC7269" format="default"/> are complementary; they
both look into
different deployment considerations. Furthermore, this document c
onsiders the updated deployment experience and newer standards.</t>
<t>The target deployment scenarios in this document
may also be covered by other IPv4-as-a-Service (IPv4aaS) transiti
on 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 a mong the So, it is out of scope of this document to provide a comparison a mong the
different IPv4aaS transition mechanisms, which is being analyzed different IPv4aaS transition mechanisms, which are analyzed
already in <xref target="I-D.lmhp-v6ops-transition-comparison" format="de
in <xref target="I-D.lmhp-v6ops-transition-comparison"/>.</t> fault"/>.</t>
<t>Consequently, this document should not be used as a guide for
<t>Consequently, this document should not be understood as a guid
e for
an operator or enterprise to decide which IPv4aaS is the best one 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 understa nding its own network. Instead, it should be used as a tool for underst anding
all the implications, including relevant documents (or even speci fic all the implications, including relevant documents (or even speci fic
parts of them), for the deployment of NAT64/464XLAT and facilitat e parts of them) for the deployment of NAT64/464XLAT and for facili tating
the decision process regarding specific deployment details.</t> the decision process regarding specific deployment details.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<b
"SHALL NOT", cp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"MAY", and RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"OPTIONAL" in this document are to be interpreted as desc "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
ribed in be interpreted as
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref tar
when, and only when, they appear in all capitals, as show get="RFC8174" format="default"/>
n here.</t> when, and only when, they appear in all capitals, as shown here.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="NAT64 Deployment Scenarios"> <name>NAT64 Deployment Scenarios</name>
<t>Section 7 of DNS64 (<xref target="RFC6147"/>), provides three <t>DNS64 (see <xref target="RFC6147"
scenarios, sectionFormat="of" section="7"/>) provides three deployment scenarios,
depending on the location of the DNS64 function. However, since t he publication depending on the location of the DNS64 function. However, since t he publication
of that document, other deployment scenarios and NAT64 use cases need to of that document, other deployment scenarios and NAT64 use cases need to
be considered in actual networks, despite some of them were speci fically be considered in actual networks, despite the fact that some of t hem were specifically
ruled out by the original NAT64/DNS64 work.</t> ruled out by the original NAT64/DNS64 work.</t>
<t>Consequently, the perspective in this document is
<t>Consequently, the perspective in this document is to broaden t to broaden those scenarios and
hose scenarios, include a few new ones. However, in order to reduce the number
including a few new ones. However, in order to be able to reduce of possible cases, we work under the assumption that the service
the number
of possible cases, we work under the assumption that typically, t
he service
provider wants to make sure that all the customers have a service provider wants to make sure that all the customers have a service
without failures. This means considering the following assumption s without failures. This means considering the following assumption s
for the worst possible case:</t> for the worst possible case:</t>
<ol spacing="normal" type="a">
<t><list style="letters"> <li>There are hosts that will be validating DNSSEC.</li>
<t>There are hosts that will be validating DNSSEC <li>IPv4 literal addresses and non-IPv6-compliant APIs are being used.</
.</t> li>
<t>IPv4 literal addresses and non-IPv6 compliant <li>There are IPv4-only hosts or applications beyond the
APIs are being used.</t> IPv6-only link (e.g., tethering in cellular netwo
<t>There are IPv4-only hosts or applications beyo rks).</li>
nd the </ol>
IPv6-only link (e.g., tethering in cellular netwo <t>This document uses a common set of possible "participant entities":</t>
rks).</t> <ol spacing="normal" type="1">
</list></t> <li>An IPv6-only access network (IPv6).</li>
<li>An IPv4-only remote network/server/service (IPv4).</li>
<t>The document uses a common set of possible "participant entiti <li>A NAT64 function (NAT64) in the service provider.</li>
es":</t> <li>A DNS64 function (DNS64) in the service provider.</li>
<li>An external service provider offering the NAT64 function and/or the
<t><list style="numbers"> DNS64 function (extNAT64/extDNS64).</li>
<t>An IPv6-only access network (IPv6).</t> <li>A 464XLAT customer-side translator (CLAT).</li>
<t>An IPv4-only remote network/server/service (IP </ol>
v4).</t> <t>Note that the nomenclature used in parentheses is the one that, for sho
<t>A NAT64 function (NAT64) in the service provid rt,
er.</t> will be used in the figures. Note: for simplicity, the boxes in
<t>A DNS64 function (DNS64) in the service provid the figures don't mean they are actually a single device; they re
er.</t> present
<t>An external service provider offering the NAT6 one or more functions as located in that part of the network (i.e
4 function and/or the ., a single box
DNS64 function (extNAT64/extDNS64).</t>
<t>464XLAT customer side translator (CLAT).</t>
</list></t>
<t>Note that the nomenclature used in parenthesis is the one that
, for short,
will be used in the figures. Note also that for simplicity, the b
oxes in
the figures don't mean they are actually a single device; they ju
st 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, n ot just one).</t> with NAT64 and DNS64 functions can actually be several devices, n ot just one).</t>
<t>The possible scenarios are split in two general categories:</t>
<t>The possible scenarios are split in two general categories:<li <ol spacing="normal" type="1">
st style="numbers"> <li>Known to work.</li>
<t>Known to work.</t> <li>Known to work under special conditions.</li>
<t>Known to work under special conditions.</t> </ol>
</list></t> <section numbered="true" toc="default">
<name>Known to Work</name>
<section title="Known to Work"> <t>The scenarios in this category are known to work, as there are well-k
<t>The scenarios in this category are known to work, as t nown
here are well-known
existing deployments from different operators using them. Each one may have existing deployments from different operators using them. Each one may have
different pros and cons, and in some cases the trade-offs different pros and cons, and in some cases, the trade-off
, s
maybe acceptable for some operators.</t> may be acceptable for some operators.</t>
<section anchor="spnatdns64" numbered="true" toc="default">
<section title="Service Provider NAT64 with DNS64" anchor <name>Service Provider NAT64 with DNS64</name>
="spnatdns64"> <t>In this scenario (<xref target="sp-nat64-dns64" format="default"/>)
<t>In this scenario (<xref target="sp-nat64-dns64 , the service
"/>), the service provider offers both the NAT64 and DNS64 function
provider offers both, the NAT64 and the DNS64 fun s.</t>
ctions.</t> <t>This is the most common scenario as originally considered by
the designers of NAT64 <xref target="RFC6146" for
<t>This is the most common scenario as originally mat="default"/> and
considered by DNS64 <xref target="RFC6147" format="default"/>;
the designers of NAT64 (<xref target="RFC6146"/>) however,
and it may also have the implications related to the
DNS64 (<xref target="RFC6147"/>), however DNSSEC.</t>
also may have the implications related the DNSSEC
.</t>
<t>This scenario also may fail to solve the issue <t>This scenario may also fail to solve the issues of
of IPv4 literal addresses, non-IPv6-compliant APIs,
IPv4 literal addresses or non-IPv6 compliant APIs or
, as well as IPv4-only hosts or applications behind the
the issue of IPv4-only hosts or applications behi
nd the
IPv6-only access network.</t> IPv6-only access network.</t>
<figure anchor="sp-nat64-dns64">
<figure align="center" anchor="sp-nat64-dns64" <name>NAT64 with DNS64</name>
title="NAT64 with DNS64"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| | | NAT64 | | | | | | NAT64 | | |
| IPv6 +--------+ + +--------+ IPv4 | | IPv6 +--------+ + +--------+ IPv4 |
| | | DNS64 | | | | | | DNS64 | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+]]></artwork>
]]></artwork>
</figure>
<t>A similar scenario (<xref target="sp-dns64-e-n ----------+ +----------+ <span class="insert">+----------+]]&gt;&l
at64"/>) will be if t;/artwork&gt;</span>
the service provider offers only the DNS64 functi </figure>
on, and the NAT64 <t>A similar scenario (<xref target="sp-dns64-e-nat64"
format="default"/>) exists if
the service provider offers only the
DNS64 function; the NAT64
function is provided by an outsourcing agreement with function is provided by an outsourcing agreement with
an external provider. an external provider.
All the considerations in the previous paragraphs of this All the considerations in the previous paragraphs of this
section, are the same for this sub-case.</t> section are the same for this sub-case.</t>
<figure anchor="sp-dns64-e-nat64">
<figure align="center" anchor="sp-dns64-e-nat64" <name>NAT64 in an External Service Provider</name>
title="NAT64 in external service provider"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| extNAT64 +--------+ IPv4 | | extNAT64 +--------+ IPv4 |
| | | | | | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
| |
+----------+ +----+-----+ +----------+ +----+-----+
| | | | | | | |
| IPv6 +--------+ DNS64 + | IPv6 +--------+ DNS64 +
| | | | | | | |
+----------+ +----------+ +----------+ +----------+]]></artwork>
]]></artwork>
</figure>
<t>This is equivalent to the scenario (<xref targ ----------+ <span class="insert">+----------+]]&gt;&lt;/artwork&gt;</span
et="e-nat64-dns64"/>) >
</figure>
<t>This is equivalent to the scenario (<xref target="e-nat64-dns64" fo
rmat="default"/>)
where the outsourcing where the outsourcing
agreement with the external provider is to provid e both the agreement with the external provider is to provid e both the
NAT64 and DNS64 functions. Once more, all the con siderations NAT64 and DNS64 functions. Once more, all the con siderations
in the previous paragraphs of this section are th e same in the previous paragraphs of this section are th e same
for this sub-case.</t> for this sub-case.</t>
<figure anchor="e-nat64-dns64">
<figure align="center" anchor="e-nat64-dns64" <name>NAT64 and DNS64 in an External Provider</name>
title="NAT64 and DNS64 in external provider"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+----------+ +----------+ +----------+ +----------+
| extNAT64 | | | | extNAT64 | | |
| + +-------+ IPv4 | | + +-------+ IPv4 |
| extDNS64 | | | | extDNS64 | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| | | | | |
| IPv6 +-------------+ | IPv6 +-------------+
| | | |
+----------+ +----------+]]></artwork>
]]></artwork>
</figure>
<t>One additional equivalent scenario (<xref targ </figure>
et="sp-nat64-e-dns64"/>) <t>One additional equivalent scenario (<xref target="sp-nat64-e-dns64"
will be if the service provider format="default"/>)
offers the NAT64 function only, and the DNS64 fun exists if the service provider
ction is from an only offers the NAT64 function; the DNS64 functio
n is from an
external provider with or without a specific agre ement among them. external provider with or without a specific agre ement among them.
This is a scenario already common today, as This is a common scenario today, as
several "global" service providers provide free D NS/DNS64 several "global" service providers provide free D NS/DNS64
services and users often configure manually their services, and users often configure their DNS man
DNS. This ually. This
will only work if both the NAT64 and the DNS64 fu will only work if both the NAT64 and DNS64 functi
nctions are using the ons are using the
WKP (Well-Known Prefix) or the same NSP (Network- Well-Known Prefix (WKP) or the same Network-Speci
Specific Prefix). fic Prefix (NSP).
All the considerations in the previous paragraphs All the considerations in the previous paragraphs
of this section, are the same for this sub-case.< /t> of this section are the same for this sub-case.</ t>
<t>Of course, if the external DNS64 function is a <t>Of course, if the external DNS64 function is agreed with the
greed with the service provider, then this case is similar to th
service provider, then we are in the same case as e
in the previous
ones already depicted in this scenario.</t> ones already depicted in this scenario.</t>
<figure anchor="sp-nat64-e-dns64">
<figure align="center" anchor="sp-nat64-e-dns64" <name>NAT64; DNS64 by an External Provider</name>
title="NAT64; DNS64 by external provider"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+----------+ +----------+
| | | |
| extDNS64 | | extDNS64 |
| | | |
+----+-----+ +----+-----+
| |
| |
+----------+ +----+-----+ +----------+ +----------+ +----+-----+ +----------+
| | | | | | | | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 | | IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | | | | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+]]></artwork>
]]></artwork>
</figure>
</section>
<section title="Service Provider Offering 464XLAT, with DNS64"> ----------+ +----------+ <span class="insert">+----------+]]&gt;&l
<t>464XLAT (<xref target="RFC6877"/>) describes an archit t;/artwork&gt;</span>
ecture that </figure>
</section>
<section numbered="true" toc="default">
<name>Service Provider Offering 464XLAT Using DNS64</name>
<t>464XLAT <xref target="RFC6877" format="default"/> describes an arch
itecture that
provides IPv4 connectivity across a network, or part of i t, provides IPv4 connectivity across a network, or part of i t,
when it is only natively transporting IPv6. <xref target= when it is only natively transporting IPv6.
"RFC7849"/> The need to support the CLAT function in order to
already suggest the need to support the CLAT function in ensure the IPv4 service continuity in IPv6-only cellular
order to deployments has been suggested in <xref target="RFC7849" format="default"/>.</t>
ensure the IPv4 service continuity in IPv6-only cellular <t>In order to do that, 464XLAT <xref target="RFC6877" format="default
deployments.</t> "/> relies on the
<t>In order to do that, 464XLAT (<xref target="RFC6877"/>
) relies on the
combination of existing protocols:</t> combination of existing protocols:</t>
<t><list style="numbers"> <ol spacing="normal" type="1">
<t>The customer-side translator (CLAT) is a state <li>The CLAT is a stateless IPv4-to-IPv6
less IPv4 to IPv6 translator (NAT46) <xref target="RFC7915" format=
translator (NAT46) (<xref target="RFC7915"/>) imp "default"/> implemented in the
lemented in the end-user device or Customer Edge Router (CE), loc
end-user device or CE (Customer Edge Router), loc ated at the
ated at the "customer edge" of the network.</li>
"customer edge" of the network.</t> <li>The provider-side translator (PLAT) is a stateful NAT64
<t>The provider-side translator (PLAT) is a state <xref target="RFC6146" format="default"/>, implem
ful NAT64 ented typically in
(<xref target="RFC6146"/>), implemented typically the operator network.</li>
at in <li>Optionally, DNS64 <xref target="RFC6147" format="default"/> may
the operator network.</t> allow
<t>Optionally, DNS64 (<xref target="RFC6147"/>),
may allow
an optimization: a single translation at the NAT6 4, instead an optimization: a single translation at the NAT6 4, instead
of two translations (NAT46+NAT64), when the appli cation at of two translations (NAT46+NAT64), when the appli cation at
the end-user device supports IPv6 DNS (uses AAAA the end-user device supports IPv6 DNS (uses AAAA
Resource Records).</t> Resource Records).</li>
</list></t> </ol>
<t>Note that even if the provider-side translator is referred to as PL
<t>Note that even if in the 464XLAT (<xref target="RFC687 AT in the
7"/>) terminology, 464XLAT terminology <xref target="RFC6877" format="defau
the provider-side translator is referred as PLAT, for sim lt"/>, for simplicity and
plicity and uniformity across this document, it is always referred to
uniformity, across this document is always referred as NA as NAT64 (function).</t>
T64 (function).</t> <t>In this scenario (<xref target="sp-464xlat-dns64" format="default"/
>), the service provider
<t>In this scenario (<xref target="sp-464xlat-dns64"/>) t
he service provider
deploys 464XLAT with a DNS64 function.</t> deploys 464XLAT with a DNS64 function.</t>
<t>As a consequence, the DNSSEC issues remain, unless the host
<t>As a consequence, the DNSSEC issues remain, unless the
host
is doing the address synthesis.</t> is doing the address synthesis.</t>
<t>464XLAT <xref target="RFC6877" format="default"/> is a very simple
<t>464XLAT (<xref target="RFC6877"/>) is a very simple ap approach to cope
proach to cope with the major NAT64+DNS64 drawback: not working with app
with the major NAT64+DNS64 drawback: Not working with app lications or
lications or devices that use literal IPv4 addresses or non-IPv6-compl
devices that use literal IPv4 addresses or non-IPv6 compl iant APIs.</t>
iant APIs.</t> <t>464XLAT <xref target="RFC6877" format="default"/> has been used mai
nly in
<t>464XLAT (<xref target="RFC6877"/>) has been used initi IPv6-only cellular networks. By supporting a CLAT functio
ally mainly in n, end-user
IPv6-only cellular networks. By supporting a CLAT functio device applications can access IPv4-only end networks / a
n, the end-user pplications,
device applications can access IPv4-only end-networks/app despite the fact that those applications or devices use l
lications, iteral IPv4 addresses
despite those applications or devices use literal IPv4 ad or non-IPv6-compliant APIs.</t>
dresses <t>In addition, in the cellular network example above,
or non-IPv6 compliant APIs.</t>
<t>In addition to that, in the same example of the cellul
ar network above,
if the User Equipment (UE) provides tethering, other devi ces behind it if the User Equipment (UE) provides tethering, other devi ces behind it
will be presented with a traditional NAT44, in addition t o the native will be presented with a traditional Network Address Tran slation from IPv4 to IPv4 (NAT44), in addition to the native
IPv6 support, so clearly it allows IPv4-only hosts behind the IPv6-only IPv6 support, so clearly it allows IPv4-only hosts behind the IPv6-only
access network.</t> access network.</t>
<t>Furthermore, as discussed in <xref target="RFC6877" format="default
<t>Furthermore, as discussed in <xref target="RFC6877"/>, "/>, 464XLAT
464XLAT
can be used in broadband IPv6 network architectures, can be used in broadband IPv6 network architectures,
by implementing the CLAT function at the CE.</t> by implementing the CLAT function at the CE.</t>
<t>The support of this scenario in a network offers two additional adv
<t>The support of this scenario in a network, offers two antages:</t>
additional advantages:</t> <ul spacing="normal">
<t><list style="symbols"> <li>DNS load optimization: A CLAT should implement a DNS proxy
<t>DNS load optimization: A CLAT should implement (per <xref target="RFC5625" format="default"/>) s
a DNS proxy o that only IPv6-native queries
(as per <xref target="RFC5625"/>), so that only I and AAAA records are sent to the DNS64 server. Ot
Pv6 native queries herwise,
and only for AAAA records are sent to the DNS64 s doubling the number of queries may impact the DNS
erver. Otherwise infrastructure.</li>
doubling the number of queries may impact the DNS <li>Connection establishment delay optimization: If the UE/CE
infrastructure.</t>
<t>Connection establishment delay optimization: I
f the UE/CE
implementation is detecting the presence of a DNS 64 function, implementation is detecting the presence of a DNS 64 function,
it may issue only the AAAA query, instead of both the AAAA it may issue only the AAAA query, instead of both the AAAA
and A queries.</t> and A queries.</li>
</list></t> </ul>
<t>In order to understand all the communication possibilities, let's
<t>In order to understand all the communication possibili assume the following representation of two
ties, let's dual-stack (DS) peers:</t>
assume the following representation of two dual-stack pee
rs:</t>
<figure align="center" suppress-title="true" <artwork align="center" name="" type="" alt=""><![CDATA[
title="Figure A: Representation of 464XLAT among two peers with
DNS64">
<artwork align="center"><![CDATA[
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only ) / Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ flow /\ `-----´ \ flow / / \ | | \ flow /\ `-----' \ flow /
( Dual- )--+ IPv6 | \ / \ / \ / ( Dual- )--+ IPv6 | \ / \ / \ /
\ Stack / | CE | `--+--´ \ .-----. / `--+--´ \ Stack / | CE | `--+--' \ .-----. / `--+--'
\ Peer / | with | | \ / Remote\/ | \ Peer / | with | | \ / Remote\/ |
`-----´ | CLAT | +---+----+ / \ +---+----+ `-----' | CLAT | +---+----+ / \ +---+----+
| | |DNS/IPv6| ( Dual- ) |DNS/IPv4| | | |DNS/IPv6| ( Dual- ) |DNS/IPv4|
+-------+ | with | \ Stack / +--------+ +-------+ | with | \ Stack / +--------+
| DNS64 | \ Peer / | DNS64 | \ Peer /
+--------+ `-----´ +--------+ `-----'
]]></artwork>
</figure>
<t>The possible communication paths, among the IPv4/IPv6 Figure A: Representation of 464XLAT among Two Peers with DNS64
stacks of
both peers, in this case, are:</t>
<t><list style="letters">
<t>Local-IPv6 to Remote-IPv6: Regular DNS and nat
ive IPv6 among peers.</t>
<t>Local-IPv6 to Remote-IPv4: DNS64 and NAT64 tra
nslation.</t>
<t>Local-IPv4 to Remote-IPv6: Not possible unless
the CLAT
implements EAM (Explicit Address Mappings) as ind
icated by
<xref target="EAM"/>. In principle,
it is not expected that services are deployed in
Internet using
IPv6-only, unless there is certainty that peers w
ill also be
IPv6-capable.</t>
<t>Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT
64 translations.</t>
<t>Local-IPv4 to Remote-dual-stack using EAM opti
mization: If the CLAT
implements EAM as indicated by <xref target="EAM"
/>, instead of
using the path d. above, NAT64 translation is avo
ided and the
flow will use IPv6 from the CLAT to the destinati
on.</t>
</list></t>
<t>The rest of the figures in this section show different ]]></artwork>
choices for placing
the different elements.</t>
<figure align="center" anchor="sp-464xlat-dns64" <t>In this case, the possible communication paths, among the IPv4/IPv6
title="464XLAT with DNS64"> stacks of
<artwork align="center"><![CDATA[ both peers, are as follows:</t>
<ol spacing="normal" type="a">
<li>Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among pee
rs.</li>
<li>Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.</li>
<li>Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements Explicit Address Mappings (EAMs) as in
dicated by
<xref target="EAM" format="default"/>. In princip
le,
it is not expected that services are deployed in
the Internet when using
IPv6 only, unless there is certainty that peers w
ill also be
IPv6 capable.</li>
<li>Local-IPv4 to Remote-IPv4: DNS64, CLAT, and NAT64 translations.<
/li>
<li>Local-IPv4 to Remote-dual-stack using EAM optimization: If the C
LAT
implements EAM as indicated by <xref target="EAM"
format="default"/>, instead of
using the path d. above, NAT64 translation is avo
ided, and the
flow will use IPv6 from the CLAT to the destinati
on.</li>
</ol>
<t>The rest of the figures in this section show different choices for
placing
the different elements.</t>
<figure anchor="sp-464xlat-dns64">
<name>464XLAT with DNS64</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | NAT64 | | | | IPv6 | | NAT64 | | |
| + +--------+ + +--------+ IPv4 | | + +--------+ + +--------+ IPv4 |
| CLAT | | DNS64 | | | | CLAT | | DNS64 | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ ]]></artwork>
]]></artwork>
</figure>
<t>A similar scenario (<xref target="ext-nat64-46 ----------+ +----------+ +----------+ ]]&gt;&lt;/artwork&gt;
4xlatdns64"/>) will be </figure>
if the service provider <t>A similar scenario (<xref target="ext-nat64-464xlatdns64" format="d
offers only the DNS64 function, and the NAT64 fun efault"/>) exists
ction is provided by if the service provider only
offers the DNS64 function; the NAT64 function is
provided by
an outsourcing agreement with an external provide r. an outsourcing agreement with an external provide r.
All the considerations in the previous paragraphs of this All the considerations in the previous paragraphs of this
section are the same for this sub-case.</t> section are the same for this sub-case.</t>
<figure anchor="ext-nat64-464xlatdns64">
<figure align="center" anchor="ext-nat64-464xlatdns64" <name>464XLAT with DNS64; NAT64 in an External Provider</name>
title="464XLAT with DNS64; NAT64 in external provider"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| extNAT64 +--------+ IPv4 | | extNAT64 +--------+ IPv4 |
| | | | | | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
| |
+----------+ +----+-----+ +----------+ +----+-----+
| IPv6 | | | | IPv6 | | |
| + +--------+ DNS64 + | + +--------+ DNS64 +
| CLAT | | | | CLAT | | |
+----------+ +----------+ +----------+ +----------+]]></artwork>
]]></artwork>
</figure>
<t>As well, is equivalent to the scenario (<xref ----------+ <span class="insert">+----------+]]&gt;&lt;/artwork&gt;</span
target="ext-nat64-dns64-464xlatdns64"/>) >
</figure>
<t>In addition, it is equivalent to the scenario (<xref target="ext-na
t64-dns64-464xlatdns64" format="default"/>)
where the outsourcing where the outsourcing
agreement with the external provider is to provid e both the agreement with the external provider is to provid e both the
NAT64 and DNS64 functions. Once more, all the con siderations NAT64 and DNS64 functions. Once more, all the con siderations
in the previous paragraphs of this section are th e same in the previous paragraphs of this section are th e same
for this sub-case.</t> for this sub-case.</t>
<figure anchor="ext-nat64-dns64-464xlatdns64">
<figure align="center" anchor="ext-nat64-dns64-464xlatdns64" <name>464XLAT with DNS64; NAT64 and DNS64 in an External Provider</n
title="464XLAT with DNS64; NAT64 and DNS64 in external provider" ame>
> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+----------+ +----------+ +----------+ +----------+
| extNAT64 | | | | extNAT64 | | |
| + +--------+ IPv4 | | + +--------+ IPv4 |
| extDNS64 | | | | extDNS64 | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| IPv6 | | | IPv6 | |
| + +-------------+ | + +-------------+
| CLAT | | CLAT |
+----------+ +----------+]]></artwork>
]]></artwork>
</figure>
</section>
<section title="Service Provider Offering 464XLAT, without DNS64" </figure>
anchor="xlat-dns64"> </section>
<t>The major advantage of this scenario (<xref target="sp <section anchor="xlat-dns64" numbered="true" toc="default">
-464xlat"/>), <name>Service Provider Offering 464XLAT, without Using DNS64</name
>
<t>The major advantage of this scenario (<xref target="sp-464xlat" for
mat="default"/>),
using 464XLAT without DNS64, using 464XLAT without DNS64,
is that the service provider ensures that DNSSEC is never broken, even is that the service provider ensures that DNSSEC is never broken, even
in case the user modifies the DNS configuration. Neverthe less, some if the user modifies the DNS configuration. Nevertheless, some
CLAT implementations or applications may impose an extra delay, which CLAT implementations or applications may impose an extra delay, which
is induced by the dual A/AAAA queries (and wait for both is induced by the dual A/AAAA queries (and the wait for b
responses), oth responses),
unless Happy Eyeballs v2 (<xref target="RFC8305"/>) is al unless Happy Eyeballs v2 <xref target="RFC8305" format="d
so present.</t> efault"/> is also present.</t>
<t>A possible variation of this scenario is when DNS64 is
<t>A possible variation of this scenario is the case when used only for the discovery of the NAT64 prefix. In the r
DNS64 is est of the document,
used only for the discovery of the NAT64 prefix. The rest it is not considered a different scenario because once th
of the document e prefix
is not considering it as a different scenario, because on
ce the prefix
has been discovered, the DNS64 function is not used, so i t behaves as if has been discovered, the DNS64 function is not used, so i t behaves as if
the DNS64 synthesis function is not present.</t> the DNS64 synthesis function is not present.</t>
<t>In this scenario, as in the previous one, there are no
<t>In this scenario, as in the previous one, there are no
issues related to IPv4-only hosts (or IPv4-only applicati ons) issues related to IPv4-only hosts (or IPv4-only applicati ons)
behind the IPv6-only access network, neither related to t behind the IPv6-only access network, as neither are relat
he ed to the
usage of IPv4 literals or non-IPv6 compliant APIs.</t> usage of IPv4 literals or non-IPv6-compliant APIs.</t>
<t>The support of this scenario in a network offers one advantage:</t>
<t>The support of this scenario in a network, offers one <ul spacing="normal">
advantage:</t> <li>DNS load optimization: A CLAT should implement a DNS proxy
<t><list style="symbols"> (per <xref target="RFC5625" format="default"/>) s
<t>DNS load optimization: A CLAT should implement o that only IPv6 native queries
a DNS proxy are sent to the DNS64 server. Otherwise, doubling
(as per <xref target="RFC5625"/>), so that only I the number of
Pv6 native queries queries may impact the DNS infrastructure.</li>
are sent to the DNS64 server. Otherwise doubling </ul>
the number of <t>As indicated earlier, the connection establishment delay optimizati
queries may impact the DNS infrastructure.</t> on
</list></t>
<t>As indicated earlier, the connection establishment del
ay optimization
is achieved only in the case of devices, Operating System s, or applications is achieved only in the case of devices, Operating System s, or applications
that use Happy Eyeballs v2 (<xref target="RFC8305"/>), wh that use Happy Eyeballs v2 <xref target="RFC8305" format=
ich is very common.</t> "default"/>, which is very common.</t>
<t>As in the previous case, let's assume the representation of two dua
<t>Let's assume the representation of two dual-stack peer l-stack peers:</t>
s as in the
previous case:</t>
<figure align="center" suppress-title="true" <artwork align="center" name="" type="" alt=""><![CDATA[
title="Figure B: Representation of 464XLAT among two peers witho
ut DNS64">
<artwork align="center"><![CDATA[
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only ) / Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ flow /\ `-----´ \ flow / / \ | | \ flow /\ `-----' \ flow /
( Dual- )--+ IPv6 | \ / \ / \ / ( Dual- )--+ IPv6 | \ / \ / \ /
\ Stack / | CE | `--+--´ \ .-----. / `--+--´ \ Stack / | CE | `--+--' \ .-----. / `--+--'
\ Peer / | with | | \ / Remote\/ | \ Peer / | with | | \ / Remote\/ |
`-----´ | CLAT | +---+----+ / \ +---+----+ `-----' | CLAT | +---+----+ / \ +---+----+
| | |DNS/IPv6| ( Dual- ) |DNS/IPv4| | | |DNS/IPv6| ( Dual- ) |DNS/IPv4|
+-------+ +--------+ \ Stack / +--------+ +-------+ +--------+ \ Stack / +--------+
\ Peer / \ Peer /
`-----´ `-----'
]]></artwork>
</figure>
<t>The possible communication paths, among the IPv4/IPv6 Figure B: Representation of 464XLAT among Two Peers without DNS64
stacks of
both peers, in this case, are:</t>
<t><list style="letters">
<t>Local-IPv6 to Remote-IPv6: Regular DNS and nat
ive IPv6 among peers.</t>
<t>Local-IPv6 to Remote-IPv4: Regular DNS, CLAT a
nd NAT64 translations.</t>
<t>Local-IPv4 to Remote-IPv6: Not possible unless
the CLAT
implements EAM as indicated by <xref target="EAM"
/>. In principle,
it is not expected that services are deployed in
Internet using
IPv6-only, unless there is certainty that peers w
ill also be
IPv6-capable.</t>
<t>Local-IPv4 to Remote-IPv4: Regular DNS, CLAT a
nd NAT64 translations.</t>
<t>Local-IPv4 to Remote-dual-stack using EAM opti
mization: If the CLAT
implements EAM as indicated by <xref target="EAM"
/>, instead of
using the path d. above, NAT64 translation is avo
ided and the flow
will use IPv6 from the CLAT to the destination.</
t>
</list></t>
<t>It needs to be noticed that this scenario works while ]]></artwork>
the local
hosts/applications are dual-stack (which is the current s
ituation),
because the connectivity from a local-IPv6 to a remote-IP
v4 is not possible
without an AAAA synthesis. This aspect is important only
when in the
LANs behind the CLAT there are IPv6-only hosts and they n
eed to
communicate with remote IPv4-only hosts. However, it does
n't look a
sensible approach from an Operating System or application
vendor
perspective, to provide IPv6-only support unless,
similarly to case c above, there is certainty of peers su
pporting
IPv6 as well. A solution approach to this is also present
ed
in <xref target="I-D.palet-v6ops-464xlat-opt-cdn-caches"/
>.</t>
<t>The following figures show different choices for placi <t>In this case, the possible communication paths, among the IPv4/IPv6
ng stacks of
both peers, are as follows:</t>
<ol spacing="normal" type="a">
<li>Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among pee
rs.</li>
<li>Local-IPv6 to Remote-IPv4: Regular DNS, CLAT, and NAT64 translat
ions.</li>
<li>Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements EAM as indicated by <xref target="EAM"
format="default"/>. In principle,
it is not expected that services are deployed in
the Internet using
IPv6 only, unless there is certainty that peers w
ill also be
IPv6-capable.</li>
<li>Local-IPv4 to Remote-IPv4: Regular DNS, CLAT, and NAT64 translat
ions.</li>
<li>Local-IPv4 to Remote-dual-stack using EAM optimization: If the C
LAT
implements EAM as indicated by <xref target="EAM"
format="default"/>, instead of
using the path d. above, NAT64 translation is avo
ided, and the flow
will use IPv6 from the CLAT to the destination.</
li>
</ol>
<t>Notice that this scenario works while the local
hosts/applications are dual stack (which is the current s
ituation)
because the connectivity from a local IPv6 to a remote IP
v4 is not possible
without a AAAA synthesis. This aspect is important only w
hen there are IPv6-only hosts in the LANs behind the CLAT and they need to
communicate with remote IPv4-only hosts. However, it is n
ot 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 supp
orting
IPv6 as well. An approach to a solution for this is also
presented
in <xref target="I-D.palet-v6ops-464xlat-opt-cdn-caches"
format="default"/>.</t>
<t>The following figures show different choices for placing
the different elements.</t> the different elements.</t>
<figure anchor="sp-464xlat">
<figure align="center" anchor="sp-464xlat" <name>464XLAT without DNS64</name>
title="464XLAT without DNS64"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | | | | | IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 | | + +--------+ NAT64 +--------+ IPv4 |
| CLAT | | | | | | CLAT | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+]]></artwork>
]]></artwork>
</figure>
<t>This is equivalent to the scenario (<xref targ ----------+ +----------+ <span class="insert">+----------+]]&gt;&l
et="ext-nat64-464xlat"/>) t;/artwork&gt;</span>
</figure>
<t>This is equivalent to the scenario (<xref target="ext-nat64-464xlat
" format="default"/>)
where there is an where there is an
outsourcing agreement with an external provider f or the outsourcing agreement with an external provider f or the
NAT64 function. All the considerations in the pre vious NAT64 function. All the considerations in the pre vious
paragraphs of this section are the same for this sub-case.</t> paragraphs of this section are the same for this sub-case.</t>
<figure anchor="ext-nat64-464xlat">
<figure align="center" anchor="ext-nat64-464xlat" <name>464XLAT without DNS64; NAT64 in an External Provider</name>
title="464XLAT without DNS64; NAT64 in external provider"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| extNAT64 +--------+ IPv4 | | extNAT64 +--------+ IPv4 |
| | | | | | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| IPv6 | | | IPv6 | |
| + +-------------+ | + +-------------+
| CLAT | | CLAT |
+----------+ +----------+]]></artwork>
]]></artwork>
</figure>
</section>
</section>
<section title="Known to Work Under Special Conditions">
<t>The scenarios in this category are known to not work u
nless significant
effort is devoted to solve the issues, or are intended to
solve problems
across "closed" networks, instead of as a general Interne
t access usage.
In addition to the different pros, cons and trade-offs,
which may be acceptable for some operators, they have imp
lementation
difficulties, as they are beyond the original expectation
s of the
NAT64/DNS64 original intent.</t>
<section title="Service Provider NAT64 without DNS64" anc </figure>
hor="onlynat64"> </section>
<t>In this scenario (<xref target="only-nat64"/>) </section>
, <section numbered="true" toc="default">
the service provider offers a NAT64 function, <name>Known to Work under Special Conditions</name>
however there is no DNS64 function support at all <t>The scenarios in this category are known
.</t> not to work unless significant
effort is devoted to solving the issues or they are inten
ded to solve problems
across "closed" networks instead of as a general Internet
access usage.
<t>As a consequence, an IPv6 host in the IPv6-onl Even though some of the different pros, cons, and trade-o
y ffs
access network, will not be able to detect the pr may be acceptable, operators have implementation
esence difficulties, as their expectations of
of DNS64 by means of <xref target="RFC7050"/>, ne NAT64/DNS64 are beyond the original intent.</t>
ither to learn the <section anchor="onlynat64" numbered="true" toc="default">
<name>Service Provider NAT64 without DNS64</name>
<t>In this scenario (<xref target="only-nat64" format="default"/>),
the service provider offers a NAT64 function;
however, there is no DNS64 function support at al
l.</t>
<t>As a consequence, an IPv6 host in the IPv6-only
access network will not be able to detect the pre
sence
of DNS64 by means of <xref target="RFC7050" forma
t="default"/> or learn the
IPv6 prefix to be used for the NAT64 function.</t > IPv6 prefix to be used for the NAT64 function.</t >
<t>This can be sorted out as indicated in <xref target="nodns64" forma
<t>This can be sorted out as indicated in <xref t t="default"/>.</t>
arget="nodns64"/>.</t> <t>Regardless, because of the lack of the DNS64
<t>However, despite that, because the lack of the
DNS64
function, the IPv6 host will not be able to obtai n function, the IPv6 host will not be able to obtai n
AAAA synthesized records, so the NAT64 function b ecomes useless.</t> AAAA synthesized records, so the NAT64 function b ecomes useless.</t>
<t>An exception to this "useless" scenario is to
<t>An exception to this "useless" scenario will b
e
manually configure mappings between the A records of each manually configure mappings between the A records of each
of the IPv4-only remote hosts and the correspondi of the IPv4-only remote hosts and the correspondi
ng AAAA records, ng AAAA records
with the WKP (Well-Known Prefix) or NSP (Network- with the WKP or NSP
Specific Prefix) used by the service-provider NAT64 function,
used by the service provider NAT64 function,
as if they were synthesized by a DNS64 function.< /t> as if they were synthesized by a DNS64 function.< /t>
<t>This mapping could be done by several means, typically
<t>This mapping could be done by several means, t at the authoritative DNS server or at the service
ypically -provider
at the authoritative DNS server, or at the servic resolvers by means of DNS Response Policy Zones (
e provider RPZs)
resolvers by means of DNS RPZ (Response Policy Zo <xref target="I-D.vixie-dnsop-dns-rpz" format="de
nes, fault"/> or equivalent functionality.
<xref target="I-D.vixie-dns-rpz"/>) or equivalent DNS RPZ may have implications in DNSSEC if the zo
functionality. ne is signed.
DNS RPZ, may have implications in DNSSEC, if the
zone is signed.
Also, if the service provider is using an NSP, ha ving the mapping Also, if the service provider is using an NSP, ha ving the mapping
at the authoritative server, may create troubles at the authoritative server may create troubles f
to other parties or other parties
trying to use different NSP or the WKP, unless mu trying to use a different NSP or WKP, unless mult
ltiple DNS "views" iple DNS "views"
(split-DNS) is also being used at the authoritati (split-DNS) are also being used at the authoritat
ve servers.</t> ive servers.</t>
<t>Generally, the mappings alternative will only
<t>Generally, the mappings alternative, will only make sense
make sense if a few sets of IPv4-only remote hosts need to b
if a few set of IPv4-only remote hosts need to be e accessed
accessed by a single network (or a small number of them),
by a single network (or a small number of them), which supports
which support IPv6 only in the access.
IPv6-only in the access. This will require some k This will require some kind of mutual
ind of mutual agreement for using this procedure; this should n
agreement for using this procedure, so it doesn't ot be a problem because it won't interfere with Internet use (which is a "closed
care if they service").</t>
become a trouble for other parties across Interne <t>In any case, this scenario doesn't solve the issue of
t IPv4 literal addresses, non-IPv6-compliant APIs,
("closed services").</t> or IPv4-only
hosts within that IPv6-only access network.</t>
<t>In any case, this scenario doesn't solve the i <figure anchor="only-nat64">
ssue of <name>NAT64 without DNS64</name>
IPv4 literal addresses or non-IPv6 compliant APIs <artwork align="center" name="" type="" alt=""><![CDATA[
, neither it
solves the problem of IPv4-only hosts within that
IPv6-only
access network.</t>
<figure align="center" anchor="only-nat64"
title="NAT64 without DNS64">
<artwork align="center"><![CDATA[
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| | | | | | | | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 | | IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | | | | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section title="Service Provider NAT64; DNS64 in the IPv6 <section numbered="true" toc="default">
hosts"> <name>Service-Provider NAT64; DNS64 in IPv6 Hosts</name>
<t>In this scenario (<xref target="sp-nat64-h-dns <t>In this scenario (<xref target="sp-nat64-h-dns64" format="default"/
64"/>), >),
the service provider offers the the service provider offers the
NAT64 function, but not the DNS64 function. Howev er, the IPv6 hosts NAT64 function but not the DNS64 function. Howeve r, the IPv6 hosts
have a built-in DNS64 function.</t> have a built-in DNS64 function.</t>
<t>This may become common if the DNS64 function is
<t>This may become common if the DNS64 function i
s
implemented in all the IPv6 hosts/stacks. implemented in all the IPv6 hosts/stacks.
However, commonly this is not the actual This is not common at the
situation, even if it may happen in the medium-te time of writing but may become more
rm. common in the near future.
At this way, the DNSSEC validation is performed o This way, the DNSSEC validation is performed on t
n the A record, he A record,
and then the host can use the DNS64 function so t and then the host can use the DNS64 function in o
o be able rder to
to use the NAT64 function, without any DNSSEC iss use the NAT64 function without any DNSSEC issues.
ues.</t> </t>
<t>This scenario fails to solve the issue of
<t>This scenario fails to solve the issue of IPv4 literal addresses or non-IPv6-compliant APIs
IPv4 literal addresses or non-IPv6 compliant APIs , unless
, unless the IPv6 hosts also support Happy Eyeballs v2
the IPv6 hosts also supports Happy Eyeballs v2 (<xref target="RFC8305"
(<xref target="RFC8305"/>, Section 7.1), which ma sectionFormat="of" section="7.1"/>).</t>
y solve that issue.</t> <t>Moreover, this scenario also fails to solve the problem
<t>However, this scenario still fails to solve th
e problem
of IPv4-only hosts or applications behind the IPv 6-only of IPv4-only hosts or applications behind the IPv 6-only
access network.</t> access network.</t>
<figure anchor="sp-nat64-h-dns64">
<figure align="center" anchor="sp-nat64-h-dns64" <name>NAT64; DNS64 in IPv6 Hosts</name>
title="NAT64; DNS64 in IPv6 hosts"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | | | | | IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 | | + +--------+ NAT64 +--------+ IPv4 |
| DNS64 | | | | | | DNS64 | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+]]></artwork>
]]></artwork>
</figure>
</section>
<section title="Service Provider NAT64; DNS64 in the IPv4 ----------+ +----------+ <span class="insert">+----------+]]&gt;&l
-only t;/artwork&gt;</span>
remote network" anchor="sprdns64"> </figure>
<t>In this scenario (<xref target="sp-nat64-r-dns </section>
64"/>), the service provider offers the <section anchor="sprdns64" numbered="true" toc="default">
NAT64 function only. The remote IPv4-only network <name>Service-Provider NAT64; DNS64 in the IPv4-Only Remote Networ
offers the k</name>
<t>In this scenario (<xref target="sp-nat64-r-dns64" format="default"/
>), the service provider offers the
NAT64 function only. The IPv4-only remote network
offers the
DNS64 function.</t> DNS64 function.</t>
<t>This is not common, and it doesn't make sense
<t>This is not common, and looks like doesn't mak
e too much sense
that a remote network, not deploying IPv6, is pro viding a DNS64 that a remote network, not deploying IPv6, is pro viding a DNS64
function. As in the case of the scenario depicted function. Like the scenario depicted in
in <xref target="onlynat64" format="default"/>, it w
<xref target="onlynat64"/>, it will only work if ill only work if both sides are
both sides are
using the WKP or the same NSP, so the same consid erations apply. using the WKP or the same NSP, so the same consid erations apply.
It can be also tuned to behave as in <xref target It can also be tuned to behave as in <xref target
="spnatdns64"/></t> ="spnatdns64" format="default"/>.</t>
<t>This scenario fails to solve the issue of
<t>This scenario still fails to solve the issue o IPv4 literal addresses or non-IPv6-compliant APIs
f .</t>
IPv4 literal addresses or non-IPv6 compliant APIs <t>Moreover, this scenario also fails to solve the problem
.</t>
<t>This scenario also fails to solve the problem
of IPv4-only hosts or applications behind the IPv 6-only of IPv4-only hosts or applications behind the IPv 6-only
access network.</t> access network.</t>
<figure align="center" anchor="sp-nat64-r-dns64" <figure anchor="sp-nat64-r-dns64">
title="NAT64; DNS64 in the IPv4-only"> <name>NAT64; DNS64 in IPv4-Only Hosts</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| | | | | IPv4 | | | | | | IPv4 |
| IPv6 +--------+ NAT64 +--------+ + | | IPv6 +--------+ NAT64 +--------+ + |
| | | | | DNS64 | | | | | | DNS64 |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+]]></artwork>
]]></artwork>
</figure>
</section>
</section>
<section title="Comparing the Scenarios">
<t>This section compares the different scenarios, includi
ng the
possible variations (each one represented in the preceden
t sections
by a different figure), looking at the following criteria
:</t>
<t><list style="letters">
<t>DNSSEC: Are there hosts validating DNSSEC?</t>
<t>Literal/APIs: Are there applications using IPv
4 literals or non-IPv6
compliant APIs?</t>
<t>IPv4-only: Are there hosts or applications usi
ng IPv4-only?</t>
<t>Foreign DNS: Is the scenario surviving if the
user, Operating System,
applications or devices change the DNS?</t>
<t>DNS load opt. (DNS load optimization): Are the
re extra queries that
may impact DNS infrastructure?</t>
<t>Connect. opt. (Connection establishment delay
optimization):
Is the UE/CE issuing only the AAAA query or also
an A query and
waiting for both responses?</t>
</list></t>
<t>In the next table, the columns represent each of the s ----------+ +----------+ <span class="insert">+----------+]]&gt;&l
cenarios from the t;/artwork&gt;</span>
previous sections, by the figure number. The possible val </figure>
ues are:</t> </section>
<t><list style="symbols"> </section>
<t>"-" Scenario "bad" for that criteria.</t> <section numbered="true" toc="default">
<t>"+" Scenario "good" for that criteria.</t> <name>Comparing the Scenarios</name>
<t>"*" Scenario "bad" for that criteria, however <t>This section compares the different scenarios, including
it is typically possible variations (each one represented in the previous
resolved, with the support of Happy Eyeballs v2 ( sections
<xref target="RFC8305"/>).</t> by a different figure), while considering the following c
</list></t> riteria:</t>
<t>In some cases, "countermeasures", alternative or <ol spacing="normal" type="a">
special configurations, may be available for the criteria <li>DNSSEC: Are there hosts validating DNSSEC?</li>
designated <li>Literal/APIs: Are there applications using IPv4 literals or
non-IPv6-compliant APIs?</li>
<li>IPv4 only: Are there hosts or applications using IPv4 only?</li>
<li>Foreign DNS: Does the scenario survive if the user, Operating Syst
em,
applications, or devices change the DNS?</li>
<li>DNS load opt.&nbsp;(DNS load optimization): Are there extra querie
s that
may impact the DNS infrastructure?</li>
<li>Connect. opt.&nbsp;(connection establishment delay optimization):
Is the UE/CE only issuing the AAAA query or also the A query and
waiting for both responses?</li>
</ol>
<t>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:</t>
<ul empty="true"><li>
<dl spacing="normal" indent="6">
<dt>"-"</dt><dd>means the scenario is "bad" for that criterion.</dd>
<dt>"+"</dt><dd>means the scenario is "good" for that criterion.</dd>
<dt>"*"</dt><dd>means the scenario is "bad" for that criterion; howeve
r, it is typically
resolved with the support of Happy Eyeballs v2 <x
ref target="RFC8305" format="default"/>.</dd>
</dl></li></ul>
<t>In some cases, "countermeasures", alternative or
special configurations, may be available for the criterio
n designated
as "bad". So, this comparison is considering a generic as "bad". So, this comparison is considering a generic
case, as a quick comparison guide. In some cases, a "bad" case as a quick comparison guide. In some cases, a "bad"
criterion is criterion is
not necessarily a negative aspect, all it depends on the not necessarily a negative aspect; it all depends on the
specific specific
needs/characteristics of the network where the deployment will needs/characteristics of the network where the deployment will
take place. For instance, in a network which has only IPv take place.
6-only hosts and
apps using only DNS and IPv6-compliant APIs, there is no
impact using
only NAT64 and DNS64, but if the hosts may validate DNSSE
C,
that item is still relevant.</t>
<figure align="center" anchor="comparing" For instance, in a network that only has IPv6-only hosts
title="Scenario Comparison"> and
<artwork align="center"><![CDATA[ apps using DNS and IPv6-compliant APIs, there is no impac
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ t using
| Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | only NAT64 and DNS64, but if the hosts validate DNSSEC,
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ that criterion is still relevant.</t>
| DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| DNS load opt. | + | + | + | + | + | + | + | + | + | + | + | + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Connect. opt. | + | + | + | + | + | + | + | * | * | + | + | + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
]]></artwork>
</figure>
<t>As a general conclusion, we should note that, if the n <table anchor="comparing">
etwork <name>Scenario Comparison</name>
must support applications using any of the following:</t> <thead>
<t><list style="symbols"> <tr>
<t>IPv4 literals</t> <th>Item / Figure</th>
<t>non-IPv6-compliant APIs</t> <th>1</th>
<t>IPv4-only hosts or applications</t> <th>2</th>
</list></t> <th>3</th>
<th>4</th>
<th>5</th>
<th>6</th>
<th>7</th>
<th>8</th>
<th>9</th>
<th>10</th>
<th>11</th>
<th>12</th>
</tr>
</thead>
<tbody>
<tr>
<td>DNSSEC</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
</tr>
<tr>
<td>Literal/APIs</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>-</td>
<td>-</td>
<td>-</td>
</tr>
<tr>
<td>IPv4-only</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>-</td>
<td>-</td>
<td>-</td>
</tr>
<tr>
<td>Foreign DNS</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>-</td>
<td>+</td>
<td>-</td>
</tr>
<tr>
<td>DNS load opt.</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
</tr>
<tr>
<td>Connect. opt.</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>+</td>
<td>*</td>
<td>*</td>
<td>+</td>
<td>+</td>
<td>+</td>
</tr>
</tbody>
</table>
<t>Then, only the scenarios with 464XLAT, a CLAT function <t>As a general conclusion, we should note if the network
, must support applications using any of the following:</t>
or equivalent built-in local address synthesis features, <ul spacing="normal">
will provide a valid solution. Further to that, those sce <li>IPv4 literals</li>
narios will also <li>non-IPv6-compliant APIs</li>
keep working if the DNS configuration is modified. Clearl <li>IPv4-only hosts or applications</li>
y also, </ul>
<t>Then, only the scenarios with 464XLAT, a CLAT function,
or equivalent built-in local address synthesis features
will provide a valid solution. Furthermore, those scenari
os will also
keep working if the DNS configuration is modified. Clearl
y,
depending on if DNS64 is used or not, DNSSEC may be broke n for depending on if DNS64 is used or not, DNSSEC may be broke n for
those hosts doing DNSSEC validation.</t> those hosts doing DNSSEC validation.</t>
<t>All the scenarios are good in terms of DNS load optimization,
<t>All the scenarios are good in terms of DNS load optimi and in the case of 464XLAT, it may provide an extra degre
zation, e
and in the case of 464XLAT it may provide an extra degree of optimization. Finally, all of the scenarios are also g
of optimization. Finally, all them are also good in terms ood in terms of
of
connection establishment delay optimization. connection establishment delay optimization.
However, in the case of 464XLAT without DNS64, it require However, in the case of 464XLAT without DNS64, the
s the usage of Happy Eyeballs v2 is required. This is not an is
usage of Happy Eyeballs v2. This is not an issue, as comm sue as it is commonly available
only it is available
in actual Operating Systems.</t> in actual Operating Systems.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Issues to be Considered</name>
<t>This section reviews the different issues that an operator needs
<section title="Issues to be Considered"> to consider for a NAT64/464XLAT deployment, as they may d
evelop
<t>This section reviews the different issues that an oper specific decision points about how to approach that deplo
ator needs yment.</t>
to consider towards a NAT64/464XLAT deployment, as they m <section numbered="true" toc="default">
ay bring <name>DNSSEC Considerations and Possible Approaches</name>
to specific decision points about how to approach that de <t>As indicated in the security considerations for DNS64 (see
ployment.</t> <xref target="RFC6147" sectionFormat="of" section="8"/>)
because DNS64 modifies DNS answers and DNSSEC is designe
<section title="DNSSEC Considerations and Possible Approaches"> d
<t>As indicated in Section 8 of <xref target="RFC6147"/>
(DNS64, Security
Considerations), because DNS64 modifies DNS answers and D
NSSEC is designed
to detect such modifications, DNS64 may break DNSSEC.</t> to detect such modifications, DNS64 may break DNSSEC.</t>
<t>If a device connected to an IPv6-only access network, queries <t>When a device connected to an IPv6-only access network queries
for a domain name in a signed zone, by means of a recursi ve name server for a domain name in a signed zone, by means of a recursi ve name server
that supports DNS64, and the result is a synthesized AAAA that supports DNS64, the result may be a synthesized AAAA
record, and the record. In that case,
recursive name server is configured to perform DNSSEC val if the recursive name server is configured to perform DNS
idation and has SEC validation and has
a valid chain of trust to the zone in question, it will a valid chain of trust to the zone in question, it will
cryptographically validate the negative response from the authoritative cryptographically validate the negative response from the authoritative
name server. This is the expected DNS64 behavior: The rec ursive name name server. This is the expected DNS64 behavior: the rec ursive name
server actually "lies" to the client device. However, in most of the cases, server actually "lies" to the client device. However, in most of the cases,
the client will not notice it, because generally, they do n't perform the client will not notice it, because generally, they do n't perform
validation themselves and instead, rely on the recursive validation themselves; instead, they rely on the recursiv
name servers.</t> e name servers.</t>
<t>In fact, a validating DNS64 resolver increases the confidence on
<t>A validating DNS64 resolver in fact, increase the conf
idence on
the synthetic AAAA, as it has validated that a non-synthe tic AAAA the synthetic AAAA, as it has validated that a non-synthe tic AAAA
for sure, doesn't exists. However, if the client device i doesn't exist. However, if the client device is oblivious
s NAT64-oblivious to NAT64
(most common case) and performs DNSSEC validation on the (the most common case) and performs DNSSEC validation on
AAAA record, the AAAA record,
it will fail as it is a synthesized record.</t> it will fail as it is a synthesized record.</t>
<t>The best possible scenario from a DNSSEC point of view is when the
<t>The best possible scenario from DNSSEC point of view, client requests that the DNS64 server perform the DNSSEC
is when the validation
client requests the DNS64 server to perform the DNSSEC va (by setting the DNSSEC OK (DO) bit to 1 and the CD bit to
lidation 0). In this case,
(by setting the DO bit to 1 and the CD bit to 0). In this the DNS64 server validates the data; thus, tampering may
case, only happen
the DNS64 server validates the data, thus tampering may o
nly happen
inside the DNS64 server (which is considered as a trusted part, inside the DNS64 server (which is considered as a trusted part,
thus its likelihood is low) or between the DNS64 server a nd the thus, its likelihood is low) or between the DNS64 server and the
client. All other parts of the system (including transmis sion client. All other parts of the system (including transmis sion
and caching) are protected by DNSSEC (<xref target="Threa and caching) are protected by DNSSEC <xref target="Threat
t-DNS64"/>).</t> -DNS64" format="default"/>.</t>
<t>Similarly, if the client querying the recursive name server is anothe
<t>Similarly, if the client querying the recursive name s r
erver is another name server configured to use it as a forwarder, and it i
name server configured to use it as a forwarder, and is p s performing DNSSEC
erforming DNSSEC
validation, it will also fail on any synthesized AAAA rec ord.</t> validation, it will also fail on any synthesized AAAA rec ord.</t>
<t>All those considerations are extensively covered in
Sections
<xref target="RFC6147" sectionFormat="bare" section="3"/>,
<xref target="RFC6147" sectionFormat="bare" section="5.5"/>,
and
<xref target="RFC6147" sectionFormat="bare" section="6.2"/> of
<xref target="RFC6147"/>.</t>
<t>All those considerations are extensively covered in <t>DNSSEC issues could be avoided if all the signed zones provide IPv6 c
Sections 3, 5.5 and 6.2 of <xref target="RFC6147"/>.</t> onnectivity together with the
<t>A solution to avoid DNSSEC issues, will be that all th
e
signed zones also provide IPv6 connectivity, together wit
h the
corresponding AAAA records. However, this is out of the c ontrol corresponding AAAA records. However, this is out of the c ontrol
of the operator needing to deploy a NAT64 function. This has been of the operator needing to deploy a NAT64 function. This has been
proposed already in <xref target="I-D.bp-v6ops-ipv6-ready proposed already in <xref target="I-D.bp-v6ops-ipv6-ready
-dns-dnssec"/>.</t> -dns-dnssec" format="default"/>.</t>
<t>An alternative solution, which was considered
<t>An alternative solution, which was the one considered while developing <xref target="RFC6147" format="default"/
while developing <xref target="RFC6147"/>, is that valida >, is that the validators
tors will be DNS64 aware. Then, they can perform the necessar
will be DNS64-aware, so could perform the necessary disco y discovery
very and do their own synthesis. Since that was standardized s
and do their own synthesis. That was done under the expec ufficiently early in the validator deployment
tation curve, the expectation was that it would be okay to break
that it was sufficiently early in the validator-deploymen certain DNSSEC assumptions
t for networks that were stuck and really needing NAT64/DNS
curve that it would be ok to break certain DNSSEC assumpt 64.</t>
ions
for networks who were really stuck in a NAT64/DNS64-needi
ng world.</t>
<t>As already indicated, the scenarios in the previous se <t>As already indicated, the scenarios in the previous section
ction, are simplified to look at the worst possible case and for
are in fact somehow simplified, looking at the worst poss the most perfect approach.
ible case. A DNSSEC breach will not happen if the end host
Saying it in a different way: "trying to look for the mos
t perfect
approach". DNSSEC breach will not happen if the end-host
is not doing validation.</t> is not doing validation.</t>
<t>The figures in previous studies indicate that DNSSEC
broken by using DNS64 makes up about 1.7%
<xref target="About-DNS64" format="default"/> of the case
s. However, we can't negate
that this may increase as DNSSEC deployment grows.
<t>Existing previous studies seems to indicate that the f
igures of DNSSEC
actually broken by using DNS64 will be around 1.7%
(<xref target="About-DNS64"/>) of the cases. However, we
can't negate
that this may increase, as DNSSEC deployment grows.
Consequently, a decision point for the operator must depe nd on Consequently, a decision point for the operator must depe nd on
"do I really care for that percentage of cases and the im the following question: Do I really care about that perce
pact in ntage of cases and the impact on
my helpdesk or can I provide alternative solutions for th my help desk, or can I provide alternative solutions for
em?". them?
Some possible solutions may be taken, as depicted in the Some possible solutions may be exist, as depicted in the
next sections.</t> next sections.</t>
<section anchor="nodns64" numbered="true" toc="default">
<section title="Not using DNS64" anchor="nodns64"> <name>Not Using DNS64</name>
<t>A solution will be to avoid using DNS64, but as alread <t>One solution is to avoid using DNS64, but as already
y indicated, this is not possible in all the scenarios.</t>
indicated this is not possible in all the scenarios.</t> <t>The use of DNS64 is a key component for some networks, in order
<t>The use of DNS64 is a key component for some networks,
in order
to comply with traffic performance metrics, monitored by some to comply with traffic performance metrics, monitored by some
governmental bodies and other institutions (<xref target= governmental bodies and other institutions <xref target="
"FCC"/>, <xref target="ARCEP"/>).</t> FCC" format="default"/> <xref target="ARCEP" format="default"/>.</t>
<t>One drawback of not having a DNS64 on the network side
<t>One drawback of not having a DNS64 at the network side is that it's not possible to heuristically discover
, NAT64 <xref target="RFC7050" format="default"/>.
is that is not possible to heuristically discover Consequently, an IPv6 host behind the IPv6-only access ne
the NAT64 (<xref target="RFC7050"/>). twork will not
Consequently, an IPv6 host behind the IPv6-only access ne be able to detect the presence of the NAT64 function, nor
twork, will not learn the
be able to detect the presence of the NAT64 function, nei
ther to learn the
IPv6 prefix to be used for it, unless it is configured by alternative IPv6 prefix to be used for it, unless it is configured by alternative
means.</t> means.</t>
<t>The discovery of the IPv6 prefix could be solved,
<t>The discovery of the IPv6 prefix could be solved, as described in <xref target="RFC7050" format="default"/>
as described in <xref target="RFC7050"/>, by means , by means
of adding the relevant AAAA records to the ipv4only.arpa. of adding the relevant AAAA records to the ipv4only.arpa.
zone, zone
of the service provider recursive servers, i.e., if of the service-provider recursive servers, i.e., if
using the WKP (64:ff9b::/96):</t> using the WKP (64:ff9b::/96):</t>
<figure><artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
ipv4only.arpa. SOA . . 0 0 0 0 0 ipv4only.arpa. SOA . . 0 0 0 0 0
ipv4only.arpa. NS . ipv4only.arpa. NS .
ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 ipv4only.arpa. AAAA 64:ff9b::192.0.0.170
ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171
ipv4only.arpa. A 192.0.0.170 ipv4only.arpa. A 192.0.0.170
ipv4only.arpa. A 192.0.0.171 ipv4only.arpa. A 192.0.0.171
]]></artwork></figure>
<t>An alternative option to the above, is the use of DNS ]]></artwork>
RPZ <t>An alternative option is the use of DNS RPZ
(<xref target="I-D.vixie-dns-rpz"/>) or equivalent functi <xref target="I-D.vixie-dnsop-dns-rpz" format="default"/>
onalities. Note or equivalent functionalities. Note
that this may impact DNSSEC if the zone is signed.</t> that this may impact DNSSEC if the zone is signed.</t>
<t>Another alternative, only valid in environments with support from t
he Port Control Protocol (PCP) (for
both the hosts or CEs and for the service-provider networ
k), is to follow
"Discovering NAT64 IPv6 Prefixes Using the Port Control P
rotocol (PCP)" <xref target="RFC7225" format="default"/>.</t>
<t>One more alternative, only valid in environments with <t>Other alternatives may be available in the future. All them are
PCP support (for extensively discussed in <xref target="RFC7051" format="d
both the hosts or CEs and for the service provider networ efault"/>;
k), is to follow however, due to the deployment evolution, many considerat
<xref target="RFC7225"/> (Discovering NAT64 IPv6 Prefixes ions
using PCP).</t> from that document have changed. New options are being do
cumented, such as using Router
<t>Other alternatives may be available in the future. All Advertising <xref target="I-D.ietf-6man-ra-pref64" format
them are ="default"/> or DHCPv6 options
extensively discussed in <xref target="RFC7051"/>, <xref target="I-D.li-intarea-nat64-prefix-dhcp-option" fo
however the deployment evolution has evolved many conside rmat="default"/>.</t>
rations
from that document. New options are being documented, suc
h using Router
Advertising (<xref target="I-D.ietf-6man-ra-pref64"/>) or
DHCPv6 options
(<xref target="I-D.li-intarea-nat64-prefix-dhcp-option"/>
).</t>
<t>It may be convenient the simultaneous support of sever <t>Simultaneous support of several of the
al of the possible approaches is convenient and will ensure that cl
possible approaches, in order to ensure that clients with ients with different
different ways to configure the NAT64 prefix successfully obtain it
ways to configure the NAT64 prefix, successfully obtain i .
t.
This is also convenient even if DNS64 is being used.</t> This is also convenient even if DNS64 is being used.</t>
<t>Also of special relevance to this section is <xref target="I-D.ches
<t>Of special relevance to this section is also <xref tar hire-sudn-ipv4only-dot-arpa" format="default"/>.</t>
get="I-D.cheshire-sudn-ipv4only-dot-arpa"/>.</t> </section>
</section> <section anchor="dns64-aware" numbered="true" toc="default">
<name>DNSSEC Validator Aware of DNS64</name>
<section title="DNSSEC validator aware of DNS64" anchor="dns64-aw <t>In general, by default, DNS servers with DNS64 function will not
are"> synthesize AAAA responses if the DO flag was set in the q
<t>In general, by default, DNS servers with DNS64 functio uery.</t>
n will not <t>In this case, since only an A record is available, if a CLAT functi
synthesize AAAA responses if the DNSSEC OK (DO) flag was on
set in the query.</t> is present, the CLAT will,
as in the case of literal IPv4 addresses, keep that traff
<t>In this case, as only an A record is available, if a C ic
LAT function flow end to end as IPv4 so DNSSEC is not broken.</t>
is present, it means that the CLAT will take the responsi <t>However, this will not work if a CLAT function is not present
bility, because the hosts will not be able to use IPv4 (which is
as in the case of literal IPv4 addresses, to keep that tr the case for all the
affic
flow end-to-end as IPv4, so DNSSEC is not broken.</t>
<t>However, this will not work if a CLAT function is not
present
as the hosts will not be able to use IPv4 (which is the c
ase for all the
scenarios without 464XLAT).</t> scenarios without 464XLAT).</t>
</section> </section>
<section anchor="stub" numbered="true" toc="default">
<section title="Stub validator" anchor="stub"> <name>Stub Validator</name>
<t>If the DO flag is set and the client device performs D <t>If the DO flag is set and the client device performs DNSSEC validat
NSSEC validation, ion,
and the Checking Disabled (CD) flag is set for a query, t he DNS64 and the Checking Disabled (CD) flag is set for a query, t he DNS64
recursive server will not synthesize AAAA responses. In t recursive server will not synthesize AAAA responses.
his case, In this case,
the client could perform the DNSSEC validation with the A record the client could perform the DNSSEC validation with the A record
and then synthesize the AAAA (<xref target="RFC6052"/>). and then synthesize the AAAA responses <xref target="RFC6
For that to be possible, the client must have learned bef 052" format="default"/>.
orehand For that to be possible, the client must have learned
the NAT64 prefix using any of the available methods the NAT64 prefix beforehand using any of the available me
(<xref target="RFC7050"/>, <xref target="RFC7225"/>, thods
<xref target="I-D.ietf-6man-ra-pref64"/>, <xref target="I (see <xref target="RFC7050" format="default"/>, <xref tar
-D.li-intarea-nat64-prefix-dhcp-option"/>). get="RFC7225" format="default"/>,
<xref target="I-D.ietf-6man-ra-pref64" format="default"/>
, and <xref target="I-D.li-intarea-nat64-prefix-dhcp-option" format="default"/>)
.
This allows the client device to avoid using the DNS64 fu nction and still This allows the client device to avoid using the DNS64 fu nction and still
use NAT64 even with DNSSEC.</t> use NAT64 even with DNSSEC.</t>
<t>If the end host is IPv4 only, this will not work if a CLAT function
<t>If the end-host is IPv4-only, this will not work if a is
CLAT function is not present (which is the case for all scenarios without
not present (scenarios without 464XLAT).</t> 464XLAT).</t>
<t>Instead of a CLAT, some devices or Operating Systems may implement
<t>Some devices or Operating Systems may implement, inste an equivalent function by using Bump-in-the-Host <xref ta
ad of a CLAT, rget="RFC6535" format="default"/>
an equivalent function by using Bump-in-the-Host (<xref t as part of Happy Eyeballs v2 (see
arget="RFC6535"/>), <xref target="RFC8305" sectionFormat="of" section="7.1"/>
implemented as part of Happy Eyeballs v2 (Section 7.1 of ).
<xref target="RFC8305"/>).
In this case, the considerations in the above paragraphs are In this case, the considerations in the above paragraphs are
also applicable.</t> also applicable.</t>
</section> </section>
<section anchor="dns-proxy" numbered="true" toc="default">
<section title="CLAT with DNS proxy and validator" anchor="dns-pr <name>CLAT with DNS Proxy and Validator</name>
oxy"> <t>If a CE includes CLAT support and also a DNS proxy, as indicated in
<t>If a CE includes CLAT support and also a DNS proxy, as <xref target="RFC6877"
indicated in sectionFormat="of" section="6.4"/>, the CE could behave a
Section 6.4 of <xref target="RFC6877"/>, the CE could beh s a stub
ave as a stub
validator on behalf of the client devices. Then, followin g the same approach validator on behalf of the client devices. Then, followin g the same approach
described in the <xref target="stub"/>, the DNS proxy described in <xref target="stub" format="default"/>, the
actually will "lie" to the client devices, which in most DNS proxy
of the cases will will actually "lie" to the client devices, which, in most
not notice it, unless they perform validation by themselv cases, will
es. Again, this not be noticed unless they perform validation by themselv
allow the client devices to avoid using the DNS64 functio es. Again, this
n and still use NAT64 allows the client devices to avoid the use of
the DNS64 function but to still use NAT64
with DNSSEC.</t> with DNSSEC.</t>
<t>Once more, this will not work without a CLAT function (which is the
<t>Once more, this will not work without a CLAT function case for all scenarios without 464XLAT).</t>
(scenarios </section>
without 464XLAT).</t> <section anchor="acl-client" numbered="true" toc="default">
</section> <name>ACL of Clients</name>
<t>In cases of dual-stack clients, AAAA queries typically take
<section title="ACL of clients" anchor="acl-client">
<t>In cases of dual-stack clients, the AAAA queries typic
ally take
preference over A queries. If DNS64 is enabled for those clients, preference over A queries. If DNS64 is enabled for those clients,
will never get A records, even for IPv4-only servers.</t> it will never get A records, even for IPv4-only servers.<
/t>
<t>As a consequence, in cases where there are IPv4-only s <t>As a consequence, in cases where there are IPv4-only servers,
ervers,
and those are located in the path before the NAT64 functi on, and those are located in the path before the NAT64 functi on,
the clients will not be able to reach them. If DNSSEC is being the clients will not be able to reach them. If DNSSEC is being
used for all those flows, specific addresses or prefixes can be used for all those flows, specific addresses or prefixes can be
left-out of the DNS64 synthesis by means of ACLs.</t> left out of the DNS64 synthesis by means of Access Contro
l Lists (ACLs).</t>
<t>Once more, this will not work without a CLAT function <t>Once more, this will not work without a CLAT function (which is the
(scenarios case for all scenarios without 464XLAT).</t>
without 464XLAT).</t> </section>
</section> <section anchor="mapping-out" numbered="true" toc="default">
<name>Mapping Out IPv4 Addresses</name>
<section title="Mapping-out IPv4 addresses" anchor="mapping-out"> <t>If there are well-known specific IPv4 addresses or prefixes
<t>If there are well-known specific IPv4 addresses or pre using DNSSEC, they can be mapped out of the DNS64 synthes
fixes is.</t>
using DNSSEC, they can be mapped-out of the DNS64 synthes <t>Even if this is not related to DNSSEC, this "mapping-out" feature
is.</t> is quite commonly used to ensure that
addresses <xref target="RFC1918" format="default"/> (for
<t>Even if this is not related to DNSSEC, this "mapping-o example, used by LAN servers) are not synthesized to
ut" feature
is actually, quite commonly used to ensure that <xref tar
get="RFC1918"/>
addresses (for example used by LAN servers) are not synth
esized to
AAAA.</t> AAAA.</t>
<t>Once more, this will not work without a CLAT function (which is the
<t>Once more, this will not work without a CLAT function case for all scenarios without 464XLAT).</t>
(scenarios </section>
without 464XLAT).</t> </section>
<section numbered="true" toc="default">
</section> <name>DNS64 and Reverse Mapping</name>
<t>When a client device using DNS64 tries to reverse-map a
</section>
<section title="DNS64 and Reverse Mapping">
<t>When a client device, using DNS64 tries to reverse-map
a
synthesized IPv6 address, the name server responds with a CNAME record synthesized IPv6 address, the name server responds with a CNAME record
pointing the domain name used to reverse-map the that points the domain name used to reverse-map the
synthesized IPv6 address (the one under ip6.arpa), to the synthesized IPv6 address (the one under ip6.arpa) to the
domain name domain name
corresponding to the embedded IPv4 address (under in-addr .arpa).</t> corresponding to the embedded IPv4 address (under in-addr .arpa).</t>
<t>This is the expected behavior, so no issues need to be considered
<t>This is the expected behavior, so no issues need to be
considered
regarding DNS reverse mapping.</t> regarding DNS reverse mapping.</t>
</section>
</section> <section anchor="xlatwwdns64" numbered="true" toc="default">
<name>Using 464XLAT with/without DNS64</name>
<section title="Using 464XLAT with/without DNS64" anchor="xlatwwd <t>In case the client device is IPv6 only (either because the stack or
ns64"> application is IPv6 only or because it is connected via a
<t>In the case the client device is IPv6-only (either bec n IPv6-only LAN)
ause the stack or and the remote server is IPv4 only (either because the st
application is IPv6-only, or because it is connected via ack is IPv4 only
an IPv6-only LAN)
and the remote server is IPv4-only (either because the st
ack is IPv4-only,
or because it is connected via an IPv4-only LAN), only NA T64 combined or because it is connected via an IPv4-only LAN), only NA T64 combined
with DNS64 will be able to provide access among both. Bec with DNS64 will be able to provide access between both. B
ause DNS64 is ecause DNS64 is
then required, DNSSEC validation will be only possible if then required, DNSSEC validation will only be possible if
the recursive the recursive
name server is validating the negative response from the authoritative name server is validating the negative response from the authoritative
name server and the client is not performing validation.< name server, and the client is not performing validation.
/t> </t>
<t>Note that at this stage of the transition, it is not expected
<t>Note that is not expected at this stage of the transit that applications, devices, or Operating Systems are IPv6
ion, only. It will
that applications, devices or Operating Systems are IPv6-
only. It will
not be a sensible decision for a developer to work on tha t direction, not be a sensible decision for a developer to work on tha t direction,
unless it is clear that the deployment scenario fully sup ports it.</t> unless it is clear that the deployment scenario fully sup ports it.</t>
<t>On the other hand, an end user or enterprise network may decide to
<t>On the other hand, an end-user or enterprise network m run IPv6 only in the LANs. In case there is any chance fo
ay decide to r
run IPv6-only in the LANs. In case there is any chance fo applications to be IPv6 only, the Operating System may be
r responsible for either doing a local address synthesis or
applications to be IPv6-only, the Operating System may be setting up some kind of on-demand VPN (IPv4-in-IPv6),
responsible either for doing a local address synthesis, o which needs to be supported by that network. This may bec
r ome
alternatively, setting up some kind of on-demand VPN (IPv
4-in-IPv6),
which need to be supported by that network. This may beco
me
very common in enterprise networks, where "Unique IPv6 Pr efix very common in enterprise networks, where "Unique IPv6 Pr efix
per Host" <xref target="RFC8273"/> is supported.</t> per Host" <xref target="RFC8273" format="default"/> is su
pported.</t>
<t>However, when the client device is dual-stack and/or c <t>However, when the client device is dual stack and/or connected in a
onnected in a
dual-stack LAN by means of a CLAT function (or has a buil t-in dual-stack LAN by means of a CLAT function (or has a buil t-in
CLAT function), DNS64 is an option.</t> CLAT function), DNS64 is an option.</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>With DNS64: If DNS64 is used, most of the IPv4 traffic
(except if using literal IPv4 addresses or non-IP
<t>With DNS64: If DNS64 is used, most of the IPv4 v6-compliant APIs)
traffic will not use the CLAT and will instead use the IP
(except if using literal IPv4 addresses or non-IP v6 path, so only one
v6 compliant APIs)
will not use the CLAT, so will use the IPv6 path
and only one
translation will be done at the NAT64. This may b reak DNSSEC, translation will be done at the NAT64. This may b reak DNSSEC,
unless measures as described in the precedent sec unless measures as described in the previous sect
tions are taken.</t> ions are taken.</li>
<li>Without DNS64: If DNS64 is not used, all the IPv4 traffic
<t>Without DNS64: If DNS64 is not used, all the I
Pv4 traffic
will make use of the CLAT, so two translations ar e required (NAT46 will make use of the CLAT, so two translations ar e required (NAT46
at the CLAT and NAT64 at the PLAT), which adds so me overhead in at the CLAT and NAT64 at the PLAT), which adds so me overhead in
terms of the extra NAT46 translation. However, th is avoids the AAAA terms of the extra NAT46 translation. However, th is avoids the AAAA
synthesis and consequently will never break DNSSE synthesis and consequently will never break DNSSE
C.</t> C.</li>
</ol>
</list></t> <t>Note that the extra translation, when DNS64 is not used, takes place
<t>Note that the extra translation, when DNS64 is not use
d, takes place
at the CLAT, which means no extra overhead for the operat or. at the CLAT, which means no extra overhead for the operat or.
It however adds potential extra delays to establish the c However, it adds potential extra delays to establish the
onnections, and no connections and has no
perceptible impact for a CE in a broadband network, while perceptible impact for a CE in a broadband network, but i
it may have t may have
some impact in a battery powered device. This cost for a some impact on a battery-powered device. The cost for a b
battery powered attery-powered
device, is possibly comparable to the cost when the devic device is possibly comparable to the cost when the device
e is doing a is doing a
local address synthesis (see Section 7.1 of <xref target= local address synthesis (see
"RFC8305"/>).</t> <xref target="RFC8305" sectionFormat="of" section="7.1"/>).</t>
</section>
</section> <section anchor="foreignDNS" numbered="true" toc="default">
<name>Foreign DNS</name>
<section title="Foreign DNS" anchor="foreignDNS"> <t>Clients, devices, or applications in a service-provider network
may use DNS servers from other networks. This may be the
<t>Clients, devices or applications in a service provider case
network,
may use DNS servers from other networks. This may be the
case either
if individual applications use their own DNS server, the if individual applications use their own DNS server, the
Operating System itself or even the CE, or combinations o f the above.</t> Operating System itself or even the CE, or combinations o f the above.</t>
<t>Those "foreign" DNS servers may not support DNS64; as a consequence,
<t>Those "foreign" DNS servers may not support DNS64, whi those scenarios that require a DNS64 may not work.
ch as a consequence,
will mean that those scenarios that require a DNS64 may n
ot work.
However, if a CLAT function is available, the considerati ons in However, if a CLAT function is available, the considerati ons in
<xref target="xlatwwdns64"/> will apply.</t> <xref target="xlatwwdns64" format="default"/> will apply.
</t>
<t>In the case that the foreign DNS supports the DNS64 fu
nction,
we may be in the situation of providing incorrect configu
rations parameters,
for example, un-matching WKP or NSP, or a case such the o
ne described in
<xref target="sprdns64"/>.</t>
<t>Having a CLAT function, even if using foreign DNS <t>If the foreign DNS supports the DNS64 function, incorrect configurat
ion 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 <xref target="sprdns64" format="de
fault"/>.</t>
<t>Having a CLAT function, even if using foreign DNS
without a DNS64 function, ensures that everything will wo rk, without a DNS64 function, ensures that everything will wo rk,
so the CLAT must be considered as an advantage even again so the CLAT must be considered to be an advantage despite
st user configuration errors.
user configuration errors. The cost of this, is that all As a result, all the
the
traffic will use a double translation (NAT46 at the CLAT traffic will use a double translation (NAT46 at the CLAT
and NAT64 at the operator network), unless there is and NAT64 at the operator network), unless there is
support for EAM (<xref target="EAM"/>).</t> support for EAM (<xref target="EAM" format="default"/>).<
/t>
<t>An exception to that is the case when there is a CLAT <t>An exception is the case where there is a CLAT function
function at the CE that is not able to obtain the correct configur
at the CE, which is not able to obtain the correct config ation
uration parameters (again, causing WKP or NSP to become unmatched
parameters (again, un-matching WKP or NSP).</t> ).</t>
<t>However, it needs to be emphasized that if there is no CLAT function
<t>However, it needs to be emphasized, that if there is n (which is the case for all scenarios without 464XLAT), an
ot a CLAT function external DNS without DNS64 support
(scenarios without 464XLAT), an external DNS without DNS6 will disallow any access to IPv4-only destination network
4 support, s and will
will disallow any access to IPv4-only destination network
s, and will
not guarantee the correct DNSSEC validation, not guarantee the correct DNSSEC validation,
so will behave as in the <xref target="onlynat64"/>.</t> so it will behave as in <xref target="onlynat64" format="
default"/>.</t>
<t>In summary, it can be said, that the consequences of t <t>In summary, the consequences of using
he use of foreign DNS depends on each specific case. However, in ge
foreign DNS depend very much in each specific case. Howev neral,
er, in general, if a CLAT function is present, most of the time there wil
if a CLAT function is present, most of the time, there wi l not be any issues.
ll not be any. In the other cases, the access to IPv6-enabled services
In the other cases, generally, the access to IPv6-enabled is still guaranteed for IPv6-enabled hosts, but it is not
services guaranteed for IPv4-only hosts
is still guaranteed for IPv6-enabled hosts, but not for I nor is the access to IPv4-only services for any hosts in
Pv4-only hosts, the network.</t>
neither the access to IPv4-only services for any hosts in <t>The causes of "foreign DNS" could be classified in three main categor
the network.</t> ies,
as depicted in the following subsections.</t>
<t>The causes of "foreign DNS" could be classified in thr <section numbered="true" toc="default">
ee main categories, <name>Manual Configuration of DNS</name>
as depicted in the following sub-sections.</t> <t>It is becoming increasingly common that end users, or even devices
or applications, configure alternative DNS in their Opera
<section title="Manual Configuration of DNS"> ting Systems
<t>It is becoming increasingly common that end-users or e
ven devices
or applications configure alternative DNS in their Operat
ing Systems,
and sometimes in CEs.</t> and sometimes in CEs.</t>
</section>
<section anchor="dnspriv" numbered="true" toc="default">
<name>DNS Privacy/Encryption Mechanisms</name>
</section> <t>Clients or applications may use mechanisms for
DNS privacy/encryption, such as DNS over TLS (DoT)
<section title="DNS Privacy/Encryption Mechanisms" anchor="dnspri <xref target="RFC7858" format="default"/>, DNS over DTLS
v"> <xref target="RFC8094" format="default"/>,
<t>Clients or applications may use mechanisms for DNS queries over HTTPS (DoH) <xref target="RFC8484" forma
DNS privacy/encryption, such as DNS over TLS t="default"/>, or
(<xref target="RFC7858"/>), DNS over DTLS (<xref target=" DNS over QUIC (DoQ) <xref target="I-D.huitema-quic-dnsoqu
RFC8094"/>), ic" format="default"/>.
DNS queries over HTTPS (<xref target="RFC8484"/>) or </t>
DNS over QUIC (<xref target="I-D.huitema-quic-dnsoquic"/> <t>Currently, those DNS privacy/encryption options are typically
).
Those are commonly cited as DoT, DoH and DoQ.</t>
<t>Those DNS privacy/encryption options, currently are ty
pically
provided by the applications, not the Operating System ve ndors. provided by the applications, not the Operating System ve ndors.
At the time of writing this document, at least DoT and Do H standards At the time this document was written, the DoT and DoH st andards
have declared DNS64 (and consequently NAT64) out of their scope, so have declared DNS64 (and consequently NAT64) out of their scope, so
an application using them may break NAT64, unless a corre ctly configured an application using them may break NAT64, unless a corre ctly configured
CLAT function is used.</t> CLAT function is used.</t>
</section>
</section> <section anchor="SplitDNS" numbered="true" toc="default">
<name>Split DNS and VPNs</name>
<section title="Split DNS and VPNs" anchor="SplitDNS"> <t>When networks or hosts use "split-DNS" (also called Split Horizon,
<t>When networks or hosts use "split-DNS" (also called Sp DNS views, or private DNS), the successful use of DNS64 i
lit Horizon, s not guaranteed.
DNS views or private DNS), the successful use of the DNS6 This case is analyzed in <xref
4 is not guaranteed. target="RFC6950" sectionFormat="of" section="4"/>.</t>
Section 4 of <xref target="RFC6950"/>, analyses this case <t>A similar situation may happen with VPNs that force all
.</t> the DNS queries through the VPN and ignore the operator D
NS64 function.</t>
<t>A similar situation may happen in case of VPNs that fo </section>
rce all </section>
the DNS queries through the VPN, ignoring the operator DN <section anchor="WKP-NSP" numbered="true" toc="default">
S64 function.</t> <name>Well-Known Prefix (WKP) vs. Network-Specific Prefix (NSP)</name>
<t>Section 3 of "IPv6 Addressing of IPv4/IPv6 Translator" <xref target="
</section> RFC6052" format="default"/>
discusses some considerations that are useful to an opera
</section> tor when deciding if
a WKP or an NSP should be used.</t>
<section title="Well-Known Prefix (WKP) vs Network-Specific Prefi <t>Considering that discussion and other issues, we can
x (NSP)" anchor="WKP-NSP"> summarize the possible decision points to as follows:</t>
<t>Section 3 of <xref target="RFC6052"/> (IPv6 Addressing <ol spacing="normal" type="a">
of IPv4/IPv6 Translators), <li>The WKP <bcp14>MUST NOT</bcp14> be used to represent non-global IP
discusses some considerations which are useful to decide v4 addresses.
if If this is required because the network to be translated
an operator should use the WKP or an NSP.</t> uses
non-global addresses, then an NSP is required.</li>
<t>Taking in consideration that discussion and other issu <li>The WKP <bcp14>MAY</bcp14> appear in interdomain routing tables, i
es, we can f the operator
summarize the possible decision points as:</t>
<t><list style="letters">
<t>The WKP MUST NOT be used to represent non-global IPv4
addresses.
If this is required because the network to be translated
use
non-global addresses, then an NSP is required.</t>
<t>The WKP MAY appear in inter-domain routing tables, if
the operator
provides a NAT64 function to peers. However, in this case , special provides a NAT64 function to peers. However, in this case , special
considerations related to BGP filtering are required and considerations related to BGP filtering are required, and
IPv4-embedded IPv4-embedded
IPv6 prefixes longer than the WKP MUST NOT be advertised IPv6 prefixes longer than the WKP <bcp14>MUST NOT</bcp14>
(or accepted) be advertised (or accepted)
in BGP. An NSP may be a more appropriate option in those in BGP. An NSP may be a more appropriate option in those
cases.</t> cases.</li>
<li>If several NAT64s use the same prefix, packets from the same
<t>If several NAT64 use the same prefix, packets from the flow may be routed to a different NAT64 in case of routin
same g changes.
flow may be routed to different NAT64 in case of routing This can be avoided by either using different prefixes fo
changes. r each NAT64
This can be avoided either by using different prefixes fo function or ensuring that all the NAT64s coordinate their
r each NAT64 state.
function, or by ensuring that all the NAT64 coordinate th Using an NSP could simplify that.</li>
eir state. <li>If DNS64 is required and users, devices, Operating Systems, or
Using an NSP could simplify that.</t> applications may change their DNS configuration and delib
erately
<t>If DNS64 is required and users, devices, Operating Sys choose an alternative DNS64 function, the alternative
tems or DNS64 will most likely use the WKP by default. In that ca
applications may change their DNS configuration, and deli se, if an NSP is used by
berately
choose an alternative DNS64 function, most probably alter
native
DNS64 will use by default the WKP. In that case, if an NS
P is used by
the NAT64 function, clients will not be able to use the o perator the NAT64 function, clients will not be able to use the o perator
NAT64 function, which will break connectivity to NAT64 function, which will break connectivity to
IPv4-only destinations.</t> IPv4-only destinations.</li>
</ol>
</list></t> </section>
<section anchor="literals" numbered="true" toc="default">
</section> <name>IPv4 Literals and Non-IPv6-Compliant APIs</name>
<t>A host or application using literal IPv4 addresses or older APIs,
<section title="IPv4 literals and non-IPv6 Compliant APIs" anchor which aren't IPv6 compliant, behind a network with IPv6-o
="literals"> nly access
<t>A host or application using literal IPv4 addresses or will not work unless any of the following alternatives ar
older APIs, e provided:</t>
which aren't IPv6 compliant, behind a network with IPv6-o <ul spacing="normal">
nly access, <li>CLAT (or an equivalent function).</li>
will not work unless any of the following alternatives is <li>Happy Eyeballs v2 (Section 7.1 of <xref target="RFC8305" format="d
provided:</t> efault"/>).</li>
<li>Bump-in-the-Host <xref target="RFC6535" format="default"/> with a
<t><list style="symbols"> DNS64 function.</li>
<t>CLAT (or equivalent function).</t> </ul>
<t>Happy Eyeballs v2 (Section 7.1, <xref target=" <t>Those alternatives will solve the problem for an end host.
RFC8305"/>).</t> However, if the end host is providing "tethering" or an e
<t>Bump-in-the-Host (<xref target="RFC6535"/>) wi quivalent
th a DNS64 function.</t> service to other hosts, that needs to be considered as we
</list></t> ll.
In other
<t>Those alternatives will solve the problem for an end-h words, in a cellular network, these alternatives resolve
ost. the issue for
However, if that end-hosts is providing "tethering" or an the UE itself, but this may not be the case for hosts con
equivalent nected via the tethering.</t>
service to other hosts, that needs to be considered as we <t>Otherwise, the support of 464XLAT is the only valid and complete
ll. In other
words, in a case of a cellular network, it resolves the i
ssue for
the UE itself, but may be not the case for hosts behind i
t.</t>
<t>Otherwise, the support of 464XLAT is the only valid an
d complete
approach to resolve this issue.</t> approach to resolve this issue.</t>
</section> </section>
<section anchor="ipv4-only" numbered="true" toc="default">
<section title="IPv4-only Hosts or Applications" anchor="ipv4-onl <name>IPv4-Only Hosts or Applications</name>
y"> <t>IPv4-only hosts or an application behind a network with IPv6-only acc
<t>An IPv4-only hosts or application behind a network wit ess
h IPv6-only access,
will not work unless a CLAT function is present.</t> will not work unless a CLAT function is present.</t>
<t>464XLAT is the only valid approach to resolve this issue.</t>
<t>464XLAT is the only valid approach to resolve this iss </section>
ue.</t> <section anchor="CLAT" numbered="true" toc="default">
</section> <name>CLAT Translation Considerations</name>
<t>As described in "IPv6 Prefix
<section title="CLAT Translation Considerations" anchor="CLAT"> Handling" (see <xref
<t>As described in Section 6.3 of <xref target="RFC6877"/ target="RFC6877" sectionFormat="of" section="6.3"/>), if
> (IPv6 Prefix the CLAT function
Handling), if the CLAT function can be configured with a can be configured with a dedicated /64 prefix
dedicated /64 prefix
for the NAT46 translation, then it will be possible to do a more for the NAT46 translation, then it will be possible to do a more
efficient stateless translation.</t> efficient stateless translation.</t>
<t>Otherwise, if this dedicated prefix is not available, <t>Otherwise, if this dedicated prefix is not available, the CLAT functi
the CLAT function will on will
need to do a stateful translation, for example performing need to do a stateful translation, for example, perform s
stateful NAT44 tateful NAT44
for all the IPv4 LAN packets, so they appear as coming fr for all the IPv4 LAN packets so they appear as coming fro
om a single m a single
IPv4 address, and then in turn, stateless translated to a IPv4 address; in turn, the CLAT function will perform a s
single IPv6 tateless translation to a single IPv6
address.</t> address.</t>
<t>A possible setup, in order to maximize the CLAT
<t>A possible setup, in order to maximize the CLAT
performance, is to configure the dedicated translation pr efix. This performance, is to configure the dedicated translation pr efix. This
can be easily achieved automatically, if the broadband CE or can be easily achieved automatically, if the broadband CE or
end-user device is able to obtain a shorter prefix by mea ns end-user device is able to obtain a shorter prefix by mea ns
of DHCPv6-PD (<xref target="RFC8415"/>), or other alterna tives. of DHCPv6-PD <xref target="RFC8415" format="default"/> or other alternatives.
The CE can then use a specific /64 for the translation. T his is also The CE can then use a specific /64 for the translation. T his is also
possible when broadband is provided by a cellular access. </t> possible when broadband is provided by a cellular access. </t>
<t>The above recommendation is often not possible for cellular networks,
<t>The above recommendation is often not possible for cel when connecting smartphones (as UEs): generally they don'
lular networks, t use DHCPv6-PD
when connecting smartphones (as UEs), as generally they d <xref target="RFC8415" format="default"/>. Instead, a sin
on't use DHCPv6-PD gle /64 is provided for
(<xref target="RFC8415"/>). Instead, a single /64 is prov each Packet Data Protocol (PDP) context, and prefix shari
ided for ng <xref target="RFC6877" format="default"/> is used.
each PDP context and prefix sharing (<xref target="RFC687 In this case, the UEs typically have a build-in CLAT func
7"/>) is used. tion that
So, in this case, the UEs typically have a build-in CLAT is performing a stateful NAT44 translation before the sta
function teless NAT46.</t>
which is performing a stateful NAT44 translation </section>
before the stateless NAT46.</t> <section anchor="EAM" numbered="true" toc="default">
<name>EAM Considerations</name>
</section> <t>"Explicit Address Mappings for Stateless IP/ICMP Translation"
<xref target="RFC7757" format="default"/> provides a way
<section title="EAM Considerations" anchor="EAM"> to configure explicit
<t>Explicit Address Mappings for Stateless IP/ICMP Transl
ation
(<xref target="RFC7757"/>) provide a way to configure exp
licit
mappings between IPv4 and IPv6 prefixes of any length. mappings between IPv4 and IPv6 prefixes of any length.
When this is used, for example in a CLAT function, it may provide a When this is used, for example, in a CLAT function, it ma y provide a
simple mechanism in order to avoid traffic flows between simple mechanism in order to avoid traffic flows between
IPv4-only nodes or applications and dual-stack destinatio ns IPv4-only nodes or applications and dual-stack destinatio ns
to be translated twice (NAT46 and NAT64), by creating map ping to be translated twice (NAT46 and NAT64), by creating map ping
entries with the GUA of the IPv6-reachable destination. entries with the Global Unicast Address (GUA) of the IPv6
This optimization of the NAT64 usage is very useful in -reachable destination.
many scenarios, including CDNs and caches, as described i This optimization of NAT64 usage is very useful in
n many scenarios, including Content Delivery Networks (CDNs
<xref target="I-D.palet-v6ops-464xlat-opt-cdn-caches"/>.< ) and caches, as described in
/t> <xref target="I-D.palet-v6ops-464xlat-opt-cdn-caches" for
mat="default"/>.</t>
<t>In addition to that, it may provide as well a way for <t>In addition, it may also provide a way for IPv4-only
IPv4-only
nodes or applications to communicate with IPv6-only desti nations.</t> nodes or applications to communicate with IPv6-only desti nations.</t>
</section>
</section> <section anchor="incoming" numbered="true" toc="default">
<name>Incoming Connections</name>
<section title="Incoming Connections" anchor="incoming"> <t>The use of NAT64, in principle, disallows IPv4 incoming connections,
<t>The use of NAT64, in principle, disallows IPv4 incomin which may still be needed for IPv4-only peer-to-peer appl
g connections, ications.
which may be still needed for IPv4-only peer-to-peer appl
ications.
However, there are several alternatives that resolve this issue:</t> However, there are several alternatives that resolve this issue:</t>
<ol spacing="normal" type="a">
<t><list style="letters"> <li>Session Traversal Utilities for NAT (STUN) <xref target="RFC5389"
format="default"/>, Traversal Using Relays around NAT (TURN) <xref target="RFC57
<t>STUN (<xref target="RFC5389"/>), TURN (<xref target="R 66" format="default"/>, and
FC5766"/>) and Interactive Connectivity Establishment (ICE) <xref target
ICE (<xref target="RFC8445"/>) are commonly used by peer- ="RFC8445" format="default"/> are commonly used by peer-to-peer
to-peer applications in order to allow incoming connections with
applications in order to allow incoming connections with IPv4 NAT. In the case of NAT64, they
IPv4 NAT. work as well.
In the case of NAT64, they work as well. RFC editor note:
If in time,
replace STUN and TURN with <xref target="I-D.ietf-tram-st
unbis"/> /
<xref target="I-D.ietf-tram-turnbis"/>.</t>
<t>PCP (<xref target="RFC6887"/>) allows a host to contro </li>
l how incoming <li>The Port Control Protocol (PCP) <xref target="RFC6887" format="def
ault"/> allows a host to control how incoming
IPv4 and IPv6 packets are translated and forwarded. A NAT 64 may implement IPv4 and IPv6 packets are translated and forwarded. A NAT 64 may implement
PCP to allow this service.</t> PCP to allow this service.</li>
<li>EAM <xref target="RFC7757" format="default"/> may also be used in
<t>EAM (<xref target="RFC7757"/>) may also be used in ord order to configure
er to configure explicit mappings for customers that require them. This i
explicit mappings for customers that require them. This i s used, for example,
s used for example by Stateless IP/ICMP Translation for IPv6 Data Center Env
by SIIT-DC (<xref target="RFC7755"/>) and SIIT-DC-DTM (<x ironments (SIIT-DC) <xref target="RFC7755" format="default"/> and SIIT-DC Dual T
ref target="RFC7756"/>).</t> ranslation Mode (SIIT-DC-DTM) <xref target="RFC7756" format="default"/>.</li>
</ol>
</list></t> </section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Summary of Deployment Recommendations for NAT64/464XLAT</name>
<t>It has been demonstrated that NAT64/464XLAT is a valid choice in severa
<section title="Summary of Deployment Recommendations for NAT64/4 l
64XLAT">
<t>NAT64/464XLAT has demonstrated to be a valid choice in
several
scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the predo minant mechanism scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the predo minant mechanism
in the majority of the cellular networks, which account f or hundreds in the majority of the cellular networks, which account f or hundreds
of millions of users (<xref target="ISOC"/>). of millions of users <xref target="ISOC" format="default" />.
NAT64/464XLAT offer different choices of deployment, NAT64/464XLAT offer different choices of deployment,
depending on each network case, needs and requirements. D espite that, depending on each network case, needs, and requirements. Despite that,
this document is not an explicit recommendation for using this choice this document is not an explicit recommendation for using this choice
versus other IPv4aaS transition mechanisms. Instead, this document versus other IPv4aaS transition mechanisms. Instead, this document
is a guide that facilitates evaluating a possible impleme ntation is a guide that facilitates evaluating a possible impleme ntation
of NAT64/464XLAT and key decision points about specific d esign of NAT64/464XLAT and key decision points about specific d esign
considerations for its deployment.</t> considerations for its deployment.</t>
<t>Depending on the specific requirements of each deployment case,
<t>Depending on the specific requirements of each deploym DNS64 may be a required function, while in other cases, t
ent case, he
DNS64 may be a required function, while in other cases th
e
adverse effects may be counterproductive. adverse effects may be counterproductive.
Similarly, in some cases a NAT64 function, together with Similarly, in some cases, a NAT64 function, together with
a DNS64 function, a DNS64 function,
may be a valid solution, when there is a certainty that I may be a valid solution when there is a certainty that IP
Pv4-only hosts v4-only hosts
or applications do not need to be supported (<xref target or applications do not need to be supported
="literals"/> and (see Sections <xref target="literals"
<xref target="ipv4-only"/>). However, in other cases (i.e format="counter"/> and
. IPv4-only devices <xref target="ipv4-only" format="counter"/>). However, in other cases (i
or applications need to be supported), the limitations of .e., IPv4-only devices
NAT64/DNS64, or applications that need to be supported), the limitatio
may suggest the operator to look into 464XLAT as a more c ns of NAT64/DNS64
omplete solution.</t> may indicate that the operator needs to look into 464XLAT
as a more complete solution.</t>
<t>In the case of broadband managed networks (where the C <t>For broadband-managed networks (where the CE is provided or
E is provided or
suggested/supported by the operator), in order to fully s upport suggested/supported by the operator), in order to fully s upport
the actual user needs (IPv4-only devices and applications the actual user's needs (i.e., IPv4-only devices and appl
, ications and the
usage of IPv4 literals and non-IPv6 compliant APIs), the usage of IPv4 literals and non-IPv6-compliant APIs), the
464XLAT scenario 464XLAT scenario
should be considered. In that case, it must support a CLA T function.</t> should be considered. In that case, it must support a CLA T function.</t>
<t>If the operator provides DNS services, in order to inc <t>If the operator provides DNS services, they may support a DNS64 functio
rease performance n to avoid, as much as possible, breaking DNSSEC. This will also increase perfo
by reducing the double translation for all the IPv4 traff rmance,
ic, by reducing the double translation for all the IPv4 traff
they may support a DNS64 function and avoid, as much as p ic. In this case, if the DNS service
ossible, is offering DNSSEC validation, then it must be in such a
breaking DNSSEC. In this case, if the DNS service way that it is
is offering DNSSEC validation, then it must be in such wa
y that it is
aware of the DNS64. This is considered the simpler and sa fer approach, aware of the DNS64. This is considered the simpler and sa fer approach,
and may be combined as well with other recommendations de scribed and it may be combined with other recommendations describ ed
in this document:</t> in this document:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>DNS infrastructure <bcp14>MUST</bcp14> be aware of DNS64 (<xref targ
<t>DNS infrastructure MUST be aware of DNS64 (<xref targe et="dns64-aware" format="default"/>).</li>
t="dns64-aware"/>).</t> <li>Devices running CLAT <bcp14>SHOULD</bcp14> follow the indications in
<t>Devices running CLAT SHOULD follow the indications in "Stub Validator"
<xref target="stub"/> (Stub Validator). However, this may (see <xref target="stub" format="default"/>). However, th
be out of the is may be out of the
control of the operator.</t> control of the operator.</li>
<t>CEs SHOULD include a DNS proxy and validator (<xref ta <li>CEs <bcp14>SHOULD</bcp14> include a DNS proxy and validator (<xref t
rget="dns-proxy"/>).</t> arget="dns-proxy" format="default"/>).</li>
<t><xref target="acl-client"/> (ACL of clients) and <li>"ACL of Clients" (see <xref target="acl-client" format="default"/>)
<xref target="mapping-out"/> (Mapping-out IPv4 addresses) and "Mapping Out IPv4 Addresses"
MAY be considered by (see <xref target="mapping-out" format="default"/>) <bcp1
operators, depending on their own infrastructure.</t> 4>MAY</bcp14> be considered by
</list></t> operators, depending on their own infrastructure.</li>
</ul>
<t>This "increased performance" approach has the disadvan <t>This "increased performance" approach has the disadvantage of
tage of
potentially breaking DNSSEC for a small percentage of val idating potentially breaking DNSSEC for a small percentage of val idating
end-hosts versus the small impact of a double translation taking place end hosts versus the small impact of a double translation taking place
in the CE. If CE performance is not an issue, which is th e most frequent in the CE. If CE performance is not an issue, which is th e most frequent
case, then a much safer approach is to not use DNS64 at a ll, case, then a much safer approach is to not use DNS64 at a ll,
and consequently, ensure that all the IPv4 traffic and consequently, ensure that all the IPv4 traffic
is translated at the CLAT (<xref target="xlatwwdns64"/>). is translated at the CLAT (<xref target="xlatwwdns64" for
</t> mat="default"/>).</t>
<t>If DNS64 is not used, at least one of the alternatives
<t>If DNS64 is not used, at least one of the alternatives described in <xref target="nodns64" format="default"/> mu
described in <xref target="nodns64"/>, must be followed i st be followed in order
n order
to learn the NAT64 prefix.</t> to learn the NAT64 prefix.</t>
<t>The operator needs to consider that if the DNS configu <t>The operator needs to consider that if the DNS configuration is
ration can modified (see Sections <xref target="foreignDNS" format="
be modified (<xref target="foreignDNS"/>, <xref target="d counter"/>, <xref target="dnspriv" format="counter"/>, and
nspriv"/>, <xref target="SplitDNS" format="counter"/>), which most l
<xref target="SplitDNS"/>), which most probably ikely
is impossible to avoid, there are chances that instead of cannot be avoided, a foreign non-DNS64 could be used inst
configuring ead of configuring a DNS64. In a scenario with only a
a DNS64 a foreign non-DNS64 is used. In a scenario with o NAT64 function, an IPv4-only remote host will no longer b
nly a e accessible.
NAT64 function IPv4-only remote host will no longer be ac
cessible.
Instead, it will continue to work in the case of 464XLAT. </t> Instead, it will continue to work in the case of 464XLAT. </t>
<t>Similar considerations need to be made regarding the usage of
<t>Similar considerations need to be taken regarding the a NAT64 WKP vs.&nbsp;NSP (<xref target="WKP-NSP" format="default"/>), as they
usage of must match
a NAT64 WKP vs NSP (<xref target="WKP-NSP"/>), as they mu the configuration of DNS64. When using foreign DNS,
st match
with the configuration of the DNS64. In case of using for
eign DNS,
they may not match. they may not match.
If there is a CLAT and the configured foreign DNS is not a DNS64, the 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 network will keep working only if other means of learning the NAT64
prefix are available.</t> prefix are available.</t>
<t>For broadband networks, as described in <xref target="CLAT" format="def
<t>As described in <xref target="CLAT"/>, for broadband n ault"/>,
etworks, the CEs supporting a CLAT function <bcp14>SHOULD</bcp14>
the CEs supporting a CLAT function, SHOULD support DHCPv6-PD <xref target="RFC8415" format="default"
support DHCPv6-PD (<xref target="RFC8415"/>), or alternat /> or alternative means for
ive means for configuring a shorter prefix. The CE <bcp14>SHOULD</bcp14
configuring a shorter prefix. The CE SHOULD internally re > internally reserve
serve
one /64 for the stateless NAT46 translation. The operator must ensure one /64 for the stateless NAT46 translation. The operator must ensure
that the customers get allocated prefixes shorter than /6 that the customers are allocated prefixes shorter than /6
4 in order 4 in order
to support this optimization. One way or the other, this to support this optimization. One way or another, this is
is not not
impacting the performance of the operator network.</t> impacting the performance of the operator network.</t>
<t>Operators may follow "Deployment Considerations" (Section 7 of <xref ta
<t>Operators may follow Section 7 of <xref target="RFC687 rget="RFC6877" format="default"/>) for suggestions on how to
7"/> (Deployment take advantage of traffic-engineering requirements.</t>
Considerations), for suggestions in order to <t>For cellular networks, the considerations regarding DNSSEC
take advantage of traffic engineering requirements.</t> may appear to be out of scope because UEs' Operating Syst
ems
<t>In the case of cellular networks, the considerations r
egarding DNSSEC
may appear as out-of-scope, because UEs Operating Systems
,
commonly don't support DNSSEC. However, applications runn ing on them commonly don't support DNSSEC. However, applications runn ing on them
may do, or it may be an Operating System "built-in" suppo rt in the may, or it may be an Operating System "built-in" support in the
future. Moreover, if those devices offer tethering, future. Moreover, if those devices offer tethering,
other client devices behind the UE, may be doing the vali other client devices behind the UE may be doing the valid
dation, ation;
hence the relevance of a proper DNSSEC support by the ope hence, proper DNSSEC support by the operator network is r
rator network.</t> elevant.</t>
<t>Furthermore, cellular networks supporting 464XLAT
<t>Furthermore, cellular networks supporting 464XLAT <xref target="RFC6877" format="default"/> and "Discovery
(<xref target="RFC6877"/>) and "Discovery of the IPv6 Pre of the IPv6 Prefix Used for
fix Used for IPv6 Address Synthesis" <xref target="RFC7050" format="de
IPv6 Address Synthesis" (<xref target="RFC7050"/>), allow fault"/> allow a progressive
a progressive IPv6 deployment, with a single Access Point Name (APN) su
IPv6 deployment, with a single APN supporting all types o pporting all types of PDP context
f PDP context (IPv4, IPv6, and IPv4v6). This approach allows the networ
(IPv4, IPv6, IPv4v6). This approach allows the network to k to
automatically serve every possible combinations of UEs.</ automatically serve every possible combination of UEs.</t
t> >
<t>If the operator chooses to provide validation for the DNS64
<t>If the operator chooses to provide validation for the prefix discovery, it must follow the advice from "Validat
DNS64 ion of Discovered Pref64::/n" (see
prefix discovery, it must follow the advice from Section <xref target="RFC7050" sectionFormat="of" section="3.1"/>
3.1. of ).</t>
<xref target="RFC7050"/> (Validation of Discovered Pref64 <t>One last consideration is that many networks may have a mix of differen
::/n).</t> t
complex scenarios at the same time; for example, customer
<t>One last consideration, is that many networks may have s that require 464XLAT
a mix of different and those that don't,
complex scenarios at the same time, for example, customer customers that require DNS64 and those that don't, etc. I
s requiring 464XLAT, n
others not requiring it, customers requiring DNS64, other
s not, etc. In
general, the different issues and the approaches describe d in this document general, the different issues and the approaches describe d in this document
can be implemented at the same time for different custome rs or parts of can be implemented at the same time for different custome rs or parts of
the network. That mix of approaches don't present any pro the network. That mix of approaches doesn't present any p
blem or roblem or
incompatibility, as they work well together, being just a incompatibility; they work well together as a matter of
matter of
appropriate and differentiated provisioning. In fact, the NAT64/464XLAT appropriate and differentiated provisioning. In fact, the NAT64/464XLAT
approach facilitates an operator offering both cellular a nd broadband approach facilitates an operator offering both cellular a nd broadband
services, to have a single IPv4aaS for both networks whil services to have a single IPv4aaS for both networks while
e differentiating differentiating
the deployment key decisions to optimize each case. It ev the deployment key decisions to optimize each case. It's
en makes possible even possible to
using hybrid CEs that have a main broadband access link a use hybrid CEs that have a main broadband access link and
nd a backup via a backup via
the cellular network.</t> the cellular network.</t>
<t>In an ideal world, we could safely use DNS64 if the approach
<t>In an ideal world we could safely use DNS64, if the ap proposed in <xref target="I-D.bp-v6ops-ipv6-ready-dns-dns
proach sec" format="default"/>
proposed in <xref target="I-D.bp-v6ops-ipv6-ready-dns-dns were followed, avoiding the cases where DNSSEC may be bro
sec"/> ken.
is followed, avoiding the cases where DNSSEC may be broke However, this will not solve the issues related to DNS pr
n. ivacy
However, this will not solve the issues related to DNS Pr and split DNS.</t>
ivacy <t>The only 100% safe solution that also resolves all the issues
and Split DNS.</t> is, in addition to having a CLAT function, not using a DN
S64 but
<t>The only 100% safe solution, which also resolves all t
he issues,
will be, in addition to having a CLAT function, not using
a DNS64 but
instead making sure that the hosts have a built-in addres s instead making sure that the hosts have a built-in addres s
synthesis feature. Operators could manage to provide CEs with synthesis feature. Operators could manage to provide CEs with
the CLAT function, however the built-in address the CLAT function; however, the built-in address
synthesis feature is out of their control. If the synthes is is synthesis feature is out of their control. If the synthes is is
provided either by the Operating System (via its DNS reso provided by either the Operating System (via its DNS reso
lver API) lver API)
or by the application (via its own DNS resolver), in such or the application (via its own DNS resolver) in such way
way that that
the prefix used for the NAT64 function is reachable for t he host, the prefix used for the NAT64 function is reachable for t he host,
the problem goes away.</t> the problem goes away.</t>
<t>Whenever feasible, using EAM <xref target="RFC7757" format="default"/>
<t>Whenever feasible, using EAM (<xref target="RFC7757"/> as indicated in <xref target="EAM" format="default"/> pro
) vides a very relevant
as indicated in <xref target="EAM"/>, provides a very rel optimization, avoiding double translations.</t>
evant <t>Applications that require incoming connections typically
optimization, avoiding double-translations.</t> provide a means for that already. However, PCP and EAM, a
s indicated in
<t>Applications that require incoming connections, typica <xref target="incoming" format="default"/>, are valid alt
lly already ernatives, even for
provide means for that. However, PCP and EAM, as indicate
d in
<xref target="incoming"/>, are valid alternatives, even f
or
creating explicit mappings for customers that require the m.</t> creating explicit mappings for customers that require the m.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Deployment of 464XLAT/NAT64 in Enterprise Networks</name>
<section title="Deployment of 464XLAT/NAT64 in Enterprise Network <t>The recommendations in this document can also be used in
s"> enterprise networks, campuses, and other similar scenario
<t>The recommendations of this document can be used as we s (including
ll in
enterprise networks, campus and other similar scenarios (
including
managed end-user networks).</t> managed end-user networks).</t>
<t>This include scenarios where the NAT64 function <t>This includes scenarios where the NAT64 function
(and DNS64 function, if available) are under (and DNS64 function, if available) are under
the control of that network (or can be configured manuall y according the control of that network (or can be configured manuall y according
to that network specific requirements), and for whatever to that network's specific requirements), and there is a
reasons, need
there is a need to provide "IPv6-only access" to any part to provide IPv6-only access to any part of that
of that network, or it is IPv6 only connected to third-party netw
network or it is IPv6-only connected to third party-netwo orks.</t>
rks.</t> <t>An example is the IETF meeting network itself,
<t>An example of that is the IETF meetings network itself
,
where both NAT64 and DNS64 functions are provided, presen ting in this case where both NAT64 and DNS64 functions are provided, presen ting in this case
the same issues as per <xref target="spnatdns64"/>. If th ere the same issues as per <xref target="spnatdns64" format=" default"/>. If there
is a CLAT function in the IETF network, then there is no is a CLAT function in the IETF network, then there is no
need to use DNS64 and it falls under the considerations o need to use DNS64, and it falls under the considerations
f of
<xref target="xlat-dns64"/>. Both scenarios have been tes <xref target="xlat-dns64" format="default"/>. Both scenar
ted and ios have been tested and
verified already in the IETF network itself.</t> verified already in the IETF network.</t>
<t>Next figures are only meant to represent a few of the
possible
scenarios, not pretending to be the only feasible ones.</
t>
<t><xref target="enterprise-nat64-dns64"/> provides an ex
ample of an
IPv6-only enterprise network connected with dual-stack to
Internet and using local NAT64 and DNS64 functions.</t>
<figure align="center" anchor="enterprise-nat64-dns64" <t>The following figures represent a few of the possible
title="IPv6-only enterprise with NAT64 and DNS64"> scenarios.</t>
<artwork align="center"><![CDATA[ <t><xref target="enterprise-nat64-dns64" format="default"/> provides an ex
ample of an
IPv6-only enterprise network connected with a dual stack
to
the Internet using local NAT64 and DNS64 functions.</t>
<figure anchor="enterprise-nat64-dns64">
<name>IPv6-Only Enterprise with NAT64 and DNS64</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+----------------------------------+ +----------------------------------+
| Enterprise Network | | Enterprise Network |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
| | IPv6 | | NAT64 | | | IPv4 | | | IPv6- | | NAT64 | | | IPv4 |
| | only +--------+ + | +-------+ + | | | only +--------+ + | +-------+ + |
| | LANs | | DNS64 | | | IPv6 | | | LANs | | DNS64 | | | IPv6 |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+]]></artwork>
]]></artwork>
</figure>
<t><xref target="enterprise-464xlat"/> provides an exampl </figure>
e of a <t><xref target="enterprise-464xlat" format="default"/> provides an exampl
dual-stack (DS) enterprise network connected with dual-st e of a
ack (DS) DS enterprise network connected with DS
to Internet and using a CLAT function, without a DNS64 fu to the Internet using a CLAT function, without a DNS64 fu
nction.</t> nction.</t>
<figure align="center" anchor="enterprise-464xlat" <figure anchor="enterprise-464xlat">
title="DS enterprise with CLAT, DS Internet, without DNS64"> <name>DS Enterprise with CLAT, DS Internet, without DNS64</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+----------------------------------+ +----------------------------------+
| Enterprise Network | | Enterprise Network |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
| | IPv6 | | | | | IPv4 | | | IPv6 | | | | | IPv4 |
| | + +--------+ NAT64 | +-------+ + | | | + +--------+ NAT64 | +-------+ + |
| | CLAT | | | | | IPv6 | | | CLAT | | | | | IPv6 |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+]]></artwork>
]]></artwork>
</figure>
<t>Finally, <xref target="enterprise-own-clat"/> provides </figure>
an example of an <t>Finally, <xref target="enterprise-own-clat" format="default"/> provides
IPv6-only provider with a NAT64 function, and a dual-stac an example of an
k (DS) enterprise IPv6-only provider with a NAT64 function, and a DS enterp
rise
network by means of their own CLAT function, without a DN S64 function.</t> network by means of their own CLAT function, without a DN S64 function.</t>
<figure anchor="enterprise-own-clat">
<figure align="center" anchor="enterprise-own-clat" <name>DS Enterprise with CLAT and IPv6-Only Access, without DNS64</name>
title="DS enterprise with CLAT, IPv6-only Access, without DNS64" <artwork align="center" name="" type="" alt=""><![CDATA[
>
<artwork align="center"><![CDATA[
+----------------------------------+ +----------------------------------+
| Enterprise Network | | Enterprise Network |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
| | IPv6 | | | | IPv6 | | | | IPv6 | | | | IPv6 | |
| | + +--------+ CLAT | +--------+ NAT64 | | | + +--------+ CLAT | +--------+ NAT64 |
| | IPv4 | | | | only | | | | IPv4 | | | | only | |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+]]></artwork>
]]></artwork>
</figure>
</section>
<section title="Security Considerations"> </figure>
<t>This document does not have new specific security cons </section>
iderations beyond <section numbered="true" toc="default">
<name>Security Considerations</name>
<t>This document does not have new specific security considerations beyond
those already reported by each of the documents cited. Fo r example, DNS64 those already reported by each of the documents cited. Fo r example, DNS64
(<xref target="RFC6147"/>) already describes the DNSSEC i <xref target="RFC6147" format="default"/> already describ
ssues.</t> es the DNSSEC issues.</t>
<t>As already described in <xref target="foreignDNS" format="default"/>, n
ote that there
may be undesirable interactions, especially if using VPNs
or DNS privacy,
which may impact the correct performance of DNS64/NAT64.<
/t>
<t>Note that, as already described in <xref target="forei <t>Note that the use of a DNS64 function has
gnDNS"/>, there privacy considerations that are equivalent to regular DNS
may be undesirable interactions, specially if using VPNs , and they are located
or DNS privacy, in either the service provider or an external service pro
which may impact in the correct performance of DNS64/NAT6 vider.</t>
4.</t> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t> This document has no IANA actions.</t>
<t>It should be remarked that the use of a DNS64 function </section>
has equivalent </middle>
privacy considerations as in the case of a regular DNS, e <back>
ither located <displayreference target="I-D.ietf-6man-ra-pref64" to="PREF64"/>
in the service provider or an external one.</t> <displayreference target="I-D.huitema-quic-dnsoquic" to="QUIC-CONNECTIONS"/>
</section> <displayreference target="I-D.lmhp-v6ops-transition-comparison"
to="IPv6-TRANSITION"/>
<displayreference target="I-D.bp-v6ops-ipv6-ready-dns-dnssec"
to="DNS-DNSSEC"/>
<section title="IANA Considerations"> <displayreference target="I-D.palet-v6ops-464xlat-opt-cdn-caches" to="OPT-4
<t>This document does not have any new specific IANA cons 64XLAT"/>
iderations.</t> <displayreference target="I-D.vixie-dnsop-dns-rpz" to="DNS-RPZ"/>
<displayreference
target="I-D.li-intarea-nat64-prefix-dhcp-option" to="DHCPv6-OPTIONS"/>
<displayreference target="I-D.cheshire-sudn-ipv4only-dot-arpa" to="IPV4ONLY
-ARPA"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.1918.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5389.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5625.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5766.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6052.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6535.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7915.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6144.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6146.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6147.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6877.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6887.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7050.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7225.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7757.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8273.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8305.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8375.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8415.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8445.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8484.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6889.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6950.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7051.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7269.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7755.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7756.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7849.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7858.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8094.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8219.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8585.xml"/>
<!--draft-ietf-6man-ra-pref64-07; I-D Exists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-6man-ra-pref64.xml"/>
<t>Note: This section is assuming that https://www.rfc-ed <!--draft-huitema-quic-dnsoquic-07; in last call -->
itor.org/errata/eid5152 <xi:include
is resolved, otherwise, this section may include the requ href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.huitema-quic
ired text -dnsoquic.xml"/>
to resolve the issue.</t>
<t>Alternatively, this could be fixed also by <xref targe <!--draft-lmhp-v6ops-transition-comparison-03; I-D Exists -->
t="I-D.cheshire-sudn-ipv4only-dot-arpa"/>.</t> <xi:include
</section> href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.lmhp-v6ops-t
ransition-comparison.xml"/>
<section title="Acknowledgements"> <!--draft-bp-v6ops-ipv6-ready-dns-dnssec-00; Expired -->
<t>The author would like to acknowledge the inputs of Gab <xi:include
or Lencse, href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.bp-v6ops-
Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, ipv6-ready-dns-dnssec.xml"/>
Mohamed Boucadair, Alejandro D'Egidio, Dan Wing, Mikael A
brahamsson
and Eric Vyncke.</t>
<t>Conversations with Marcelo Bagnulo, one of the co-auth <!--draft-palet-v6ops-464xlat-opt-cdn-caches-04; I-D Exists-->
ors of NAT64 and <xi:include
DNS64, as well as several emails in mailing lists from Ma href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.palet
rk Andrews, -v6ops-464xlat-opt-cdn-caches.xml"/>
have been very useful for this work.</t>
<t>Christian Huitema inspired working in this document by <!--draft-li-intarea-nat64-prefix-dhcp-option-02; I-D Exists
suggesting -->
that DNS64 should never be used, during a discussion rega <xi:include
rding the href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.li-in
deployment of CLAT in the IETF network.</t> tarea-nat64-prefix-dhcp-option.xml"/>
</section> <!--draft-vixie-dnsop-dns-rpz-00; Replaced by draft-ietf-dnsop-dns-rpz,
which is replaced by draft-vixie-dnsop-dns-rpz
(which is expired; ISE review (history last modified 8/2018) -->
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.vixie
-dnsop-dns-rpz.xml"/>
<section title="ANNEX A: Example of Broadband Deployment with 464XLAT"> <!-- draft.cheshire-sudn-ipv4only-dot-arpa-15; I-D Exists-->
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.chesh
ire-sudn-ipv4only-dot-arpa.xml"/>
<reference anchor="Threat-DNS64" target="https://www.sciencedirect.com/s
cience/article/pii/S0167404818303663?via%3Dihub">
<front>
<title>Methodology for the identification of potential security issu
es of different IPv6 transition technologies: Threat analysis of DNS64 and state
ful NAT64</title>
<seriesInfo name="DOI" value="10.1016/j.cose.2018.04.012"/>
<seriesInfo name="pp." value="397-411"/>
<seriesInfo name="no." value="1"/>
<seriesInfo name="vol." value="77"/>
<seriesInfo name="Computers &amp; Security" value=""/>
<author initials="G" surname="Lencse"/>
<author initials="Y" surname="Kadobayashi"/>
<date month="August" year="2018"/>
</front>
</reference>
<reference anchor="DNS64-Benchm" target="https://www.sciencedirect.com/s
cience/article/pii/S0140366418302184?via%3Dihub">
<front>
<title>Benchmarking DNS64 Implementations: Theory and Practice</titl
e>
<seriesInfo name="DOI" value="10.1016/j.comcom.2018.05.005"/>
<seriesInfo name="pp." value="61-74"/>
<seriesInfo name="no." value="1"/>
<seriesInfo name="vol." value="127"/>
<seriesInfo name="Computer Communications" value=""/>
<author initials="G" surname="Lencse"/>
<author initials="Y" surname="Kadobayashi"/>
<date month="September" year="2018"/>
</front>
</reference>
<reference anchor="DNS64-BM-Meth" target="https://www.sciencedirect.com/
science/article/pii/S0140366416305904?via%3Dihub">
<front>
<title>Benchmarking Methodology for DNS64 Servers</title>
<seriesInfo name="DOI" value="10.1016/j.comcom.2017.06.004"/>
<seriesInfo name="pp." value="162-175"/>
<seriesInfo name="no." value="1"/>
<seriesInfo name="vol." value="109"/>
<seriesInfo name="Computer Communications" value=""/>
<author initials="G" surname="Lencse"/>
<author initials="M" surname="Georgescu"/>
<author initials="Y" surname="Kadobayashi"/>
<date month="September" year="2017"/>
</front>
</reference>
<reference anchor="About-DNS64" target="https://blog.apnic.net/2016/06/0
9/lets-talk-ipv6-dns64-dnssec/">
<front>
<title>Let's talk about IPv6 DNS64 &amp; DNSSEC</title>
<author initials="J" surname="Linkova">
<organization>APNIC Blog</organization>
</author>
<date month="June" year="2016"/>
</front>
</reference>
<reference anchor="FCC" target="https://www.fcc.gov/reports-research/rep
orts/measuring-broadband-america/measuring-broadband-america-mobile-2013-2018">
<front>
<title>Measuring Broadband America Mobile 2013-2018 Coarsened Data</
title>
<author>
<organization>FCC</organization>
</author>
<date month="December" year="2018"/>
</front>
</reference>
<reference anchor="ARCEP" target="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"
>
<front>
<title>Service client des operateurs : les mesures de qualite de ser
vice</title>
<author>
<organization>ARCEP</organization>
</author>
<date month="April" year="2018"/>
</front>
</reference>
<reference anchor="ISOC" target="https://www.internetsociety.org/resourc
es/2018/state-of-ipv6-deployment-2018/">
<front>
<title>State of IPv6 Deployment 2018</title>
<author>
<organization>ISOC</organization>
</author>
<date month="June" year="2018"/>
</front>
</reference>
<reference anchor="RIPE-690" target="https://www.ripe.net/publications/d
ocs/ripe-690">
<front>
<title>Best Current Operational Practice for Operators: IPv6 prefix
assignment for end-users - persistent vs non-persistent, and what size to choose
</title>
<author surname="RIPE">
<organization> RIPE</organization>
</author>
<date month="October" year="2017"/>
</front>
</reference>
</references>
</references>
<section numbered="true" toc="default" anchor="AppendixA">
<name>Example of Broadband Deployment with 464XLAT</name>
<t>This section summarizes how an operator may deploy an IPv6-only <t>This section summarizes how an operator may deploy an IPv6-only
network for residential/SOHO customers, supporting IPv6 inbound network for residential/SOHO customers, supporting IPv6 inbound
connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT.</t> connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT.</t>
<t>Note that an equivalent setup could also be provided for enterprise <t>Note that an equivalent setup could also be provided for enterprise
customers. In case they need to support IPv4 inbound connections, several customers. If they need to support IPv4 inbound connections, several
mechanisms, depending on specific customer needs, allow that, for instance mechanisms, depending on specific customer needs, allow it; see
<xref target="RFC7757"/>.</t> <xref target="RFC7757" format="default"/>.</t>
<t>Conceptually, most of the operator network could be IPv6 only
<t>Conceptually, most part of the operator network could be IPv6-only (represented in the next figures as "IPv6-only flow"), or even if
(represented in the next pictures as "IPv6-only flow"), or even if part of the network is actually dual stack, only IPv6 access
this part of the network is actually dual-stack, only IPv6-access is available for some customers (i.e., residential customers).
is available for some customers (i.e. residential customers).
This part of the network connects the IPv6-only subscribers This part of the network connects the IPv6-only subscribers
(by means of IPv6-only access links), to the IPv6 upstream providers, (by means of IPv6-only access links) to the IPv6 upstream providers
as well as to the IPv4-Internet by means of the NAT64 (PLAT and to the IPv4-Internet by means of NAT64 (PLAT
in the 464XLAT terminology).</t> in the 464XLAT terminology).</t>
<t>The traffic flow from and back to the CE to services available in the
<t>The traffic flow from and back to the CE to services available in th IPv6 Internet (or even dual-stack remote services, when IPv6 is being u
e sed)
IPv6 Internet (or even dual-stack remote services, when IPv6 is being u
sed),
is purely native IPv6 traffic, so there are no special considerations a bout it.</t> is purely native IPv6 traffic, so there are no special considerations a bout it.</t>
<t>Looking at the picture from the DNS perspective, there are remote <t>From the DNS perspective, there are remote
networks with are IPv4-only, and typically will have only IPv4 DNS networks with IPv4 only that will typically have only IPv4 DNS
(DNS/IPv4), or at least will be seen as that from the CE perspective. (DNS/IPv4) or will at least be seen as IPv4 DNS from the CE perspective
At the operator side, the DNS, as seen from the CE, is .
only IPv6 (DNS/IPv6) and has also a DNS64 function. </t> On the operator side, the DNS, as seen from the CE, is
only IPv6 (DNS/IPv6), and it also has a DNS64 function. </t>
<t>In the customer LANs side, there is actually one network, which of c <t>On the customer LANs side, there is actually one network, which of cour
ourse se
could be split in different segments. The most common setup will be could be split into different segments. The most common setup will be
those segments being dual-stack, using global IPv6 addresses and <xref dual-stack segments, using global IPv6 addresses and <xref target="RFC1
target="RFC1918"/> 918" format="default"/>
for IPv4, as usual in any regular residential/SOHO IPv4 network. for IPv4, in any regular residential / Small Office, Home Office (SOHO)
In the figure, it is represented as tree segments, just to show that th IPv4 network.
e In the figure below, it is represented as tree segments to show that th
three possible setups are valid (IPv6-only, IPv4-only and dual-stack).< e
/t> three possible setups are valid (IPv6 only, IPv4 only, and dual stack).
</t>
<figure align="center" anchor="clat-CE-DNS64" <figure anchor="clat-CE-DNS64">
title="CE setup with built-in CLAT with DNS64"> <name>CE Setup with Built-In CLAT, with DNS64</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
.-----. +-------+ .-----. .-----. .-----. +-------+ .-----. .-----.
/ IPv6- \ | | / \ / \ / IPv6- \ | | / \ / \
( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \
\ LANs / | SOHO +--( only )--( NAT64 )--( only ) \ LANs / | SOHO +--( only )--( NAT64 )--( only )
`-----´ | | \ flow / `-----´ \ flow / `-----' | | \ flow / `-----' \ flow /
.-----. | IPv6 | \ / \ / .-----. | IPv6 | \ / \ /
/ IPv4- \ | CE | `--+--´ `--+--´ / IPv4- \ | CE | `--+--' `--+--'
( only )--+ with | | | ( only )--+ with | | |
\ LANs / | CLAT | +---+----+ +---+----+ \ LANs / | CLAT | +---+----+ +---+----+
`-----´ | | |DNS/IPv6| |DNS/IPv4| `-----' | | |DNS/IPv6| |DNS/IPv4|
.-----. +---+---+ | with | +--------+ .-----. +---+---+ | with | +--------+
/ Dual- \ | | DNS64 | / Dual- \ | | DNS64 |
( Stack )------| +--------+ ( Stack )------| +--------+
\ LANs / \ LANs /
`-----´ `-----' ]]></artwork>
]]></artwork>
</figure>
<t>In addition to the regular CE setup, which will be typically </figure>
<t>In addition to the regular CE setup, which typically will be
access-technology dependent, the steps for the CLAT function access-technology dependent, the steps for the CLAT function
configuration can be summarized as:</t> configuration can be summarized as follows:</t>
<t><list style="numbers"> <ol spacing="normal" type="1">
<t>Discovery of the PLAT (NAT64) prefix: It may b <li>Discovery of the PLAT (NAT64) prefix: It may be done
e done using <xref target="RFC7050" format="default"/>,
using <xref target="RFC7050"/>, or in those netwo <xref target="RFC7225" format="default"/> in those networks where PCP
rks where PCP is supported, or other
is supported, by means of <xref target="RFC7225"/
>, or other
alternatives that may be available in the future, such as Router alternatives that may be available in the future, such as Router
Advertising (<xref target="I-D.ietf-6man-ra-pref6 Advertising <xref target="I-D.ietf-6man-ra-pref64
4"/>) or " format="default"/> or
DHCPv6 options (<xref target="I-D.li-intarea-nat6 DHCPv6 options <xref target="I-D.li-intarea-nat64
4-prefix-dhcp-option"/>).</t> -prefix-dhcp-option" format="default"/>.</li>
<li>If the CLAT function allows stateless NAT46 translation, a /64 from
<t>If the CLAT function allows stateless NAT46 tr
anslation, a /64 from
the pool typically provided to the CE by means of DHCPv6-PD the pool typically provided to the CE by means of DHCPv6-PD
<xref target="RFC8415"/>, need to be set aside fo r that translation. <xref target="RFC8415" format="default"/> needs t o be set aside for that translation.
Otherwise, the CLAT is forced to perform an inter mediate stateful Otherwise, the CLAT is forced to perform an inter mediate stateful
NAT44 before the a stateless NAT46, as described NAT44 before the stateless NAT46, as described in
in <xref target="CLAT"/>.</t> <xref target="CLAT" format="default"/>.</li>
</list></t> </ol>
<t>A more detailed configuration approach is described in
<t>A more detailed configuration approach is described in <xref target="RFC8585" format="default"/>.</t>
<xref target="RFC8585"/>.</t> <t>The operator network needs to ensure that the correct responses are pro
vided
<t>The operator network needs to ensure that the correct responses are
provided
for the discovery of the PLAT prefix. It is highly recommended for the discovery of the PLAT prefix. It is highly recommended
to follow <xref target="RIPE-690"/>, in order to ensure that multiple / 64s that <xref target="RIPE-690" format="default"/> be followed in order to ensure that multiple /64s
are available, including the one needed for the NAT46 stateless transla tion.</t> are available, including the one needed for the NAT46 stateless transla tion.</t>
<t>The operator needs to understand other issues, as described throughout
<t>The operator needs to understand other issues, described across this this document,
document, in order to make relevant decisions. For example, if several NAT64 func
in order to take the relevant decisions. For example, if several NAT64 tions
functions are needed in the context of scalability / high availability, an NSP sh
are needed in the context of scalability/high-availability, an NSP shou ould be
ld be considered (see <xref target="WKP-NSP" format="default"/>).</t>
considered (<xref target="WKP-NSP"/>).</t> <t>More complex scenarios are possible, for example, if a network offers
<t>More complex scenarios are possible, for example, if a network offer
s
multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.</t> multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.</t>
<t>If the operator decides not to provide a DNS64 function, then this
<t>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
setup turns into the one in the following Figure. This will be also the setup that will be seen from the perspective
the setup that "will be seen" from the perspective
of the CE, if a foreign DNS is used and consequently is of the CE, if a foreign DNS is used and consequently is
not the operator-provided DNS64 function.</t> not the operator-provided DNS64 function.</t>
<figure anchor="clat-CE">
<figure align="center" anchor="clat-CE" <name>CE Setup with Built-In CLAT, without DNS64</name>
title="CE setup with built-in CLAT without DNS64"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
.-----. +-------+ .-----. .-----. .-----. +-------+ .-----. .-----.
/ IPv6- \ | | / \ / \ / IPv6- \ | | / \ / \
( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \
\ LANs / | SOHO +--( only )--( NAT64 )--( only ) \ LANs / | SOHO +--( only )--( NAT64 )--( only )
`-----´ | | \ flow / `-----´ \ flow / `-----' | | \ flow / `-----' \ flow /
.-----. | IPv6 | \ / \ / .-----. | IPv6 | \ / \ /
/ IPv4- \ | CE | `--+--´ `--+--´ / IPv4- \ | CE | `--+--' `--+--'
( only )--+ with | | | ( only )--+ with | | |
\ LANs / | CLAT | +---+----+ +---+----+ \ LANs / | CLAT | +---+----+ +---+----+
`-----´ | | |DNS/IPv6| |DNS/IPv4| `-----' | | |DNS/IPv6| |DNS/IPv4|
.-----. +---+---+ +--------+ +--------+ .-----. +---+---+ +--------+ +--------+
/ Dual- \ | / Dual- \ |
( Stack )------| ( Stack )------|
\ LANs / \ LANs /
`-----´ `-----']]></artwork>
]]></artwork>
</figure>
<t>In this case, the discovery of the PLAT prefix needs to be arranged </figure>
as <t>In this case, the discovery of the PLAT prefix needs to be arranged as
indicated in <xref target="nodns64"/>.</t> indicated in <xref target="nodns64" format="default"/>.</t>
<t>In addition, if the CE doesn't have a built-in CLAT function, the custo
mer can
choose to set up the IPv6 operator-managed CE in bridge mode (and optio
nally
use an external router). Or, for example, if there is an access techno
logy
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.), th
e complete
setup will look like <xref target="clat-bridge" format="default"/>.
<t>In this case, the CE doesn't have a built-in CLAT function, or the c
ustomer can
choose to setup the IPv6 operator-managed CE in bridge mode (and option
ally
use an external router), or for example, there is an access technology
that requires some kind of media converter (ONT for FTTH, Cable-Modem
for DOCSIS, etc.), the complete setup will look as in <xref target="cla
t-bridge"/>.
Obviously, there will be some intermediate configuration steps for the Obviously, there will be some intermediate configuration steps for the
bridge, depending on the specific access technology/protocols, which bridge, depending on the specific access technology/protocols, which
should not modify the steps already described in the previous cases should not modify the steps already described in the previous cases
for the CLAT function configuration.</t> for the CLAT function configuration.</t>
<figure anchor="clat-bridge">
<figure align="center" anchor="clat-bridge" <name>CE Setup with Bridged CLAT, without DNS64</name>
title="CE setup with bridged CLAT without DNS64"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
| Res./ | / IPv6- \ .-----. / IPv4- \ | Res./ | / IPv6- \ .-----. / IPv4- \
| SOHO +--( only )--( NAT64 )--( only ) | SOHO +--( only )--( NAT64 )--( only )
| | \ flow / `-----´ \ flow / | | \ flow / `-----' \ flow /
| IPv6 | \ / \ / | IPv6 | \ / \ /
| CE | `--+--´ `--+--´ | CE | `--+--' `--+--'
| Bridge| | | | Bridge| | |
| | +---+----+ +---+----+ | | +---+----+ +---+----+
| | |DNS/IPv6| |DNS/IPv4| | | |DNS/IPv6| |DNS/IPv4|
+---+---+ +--------+ +--------+ +---+---+ +--------+ +--------+
| |
.-----. +---+---+ .-----. +---+---+
/ IPv6- \ | | / IPv6- \ | |
( only )--+ IPv6 | ( only )--+ IPv6 |
\ LANs / | Router| \ LANs / | Router|
`-----´ | | `-----' | |
.-----. | with | .-----. | with |
/ IPv4- \ | CLAT | / IPv4- \ | CLAT |
( only )--+ | ( only )--+ |
\ LANs / | | \ LANs / | |
`-----´ | | `-----' | |
.-----. +---+---+ .-----. +---+---+
/ Dual- \ | / Dual- \ |
( Stack )------| ( Stack )------|
\ LANs / \ LANs /
`-----´ `-----']]></artwork>
]]></artwork>
</figure>
<t>It should be avoided that several routers (i.e., the operator
provided CE
and a downstream user provided router) enable simultaneously rou
ting and/or
CLAT, in order to avoid multiple NAT44 and NAT46 levels, as well
as
ensuring the correct operation of multiple IPv6 subnets. In thos
e cases,
it is suggested the use of HNCP (<xref target="RFC8375"/>).</t>
<t>Note that the procedure described here for the CE setup, can b
e simplified
if the CE follows <xref target="RFC8585"/>.</t>
</section>
<section title="ANNEX B: CLAT Implementation">
<t>In addition to the regular set of features for a CE, a CLAT CE
implementation requires support of:</t>
<t><list style="symbols">
<t><xref target="RFC7915"/> for the NAT46 functio
n.</t>
<t><xref target="RFC7050"/> for the PLAT prefix d
iscovery.</t>
<t><xref target="RFC7225"/> for the PLAT prefix d
iscovery if PCP is supported.</t>
<t><xref target="I-D.ietf-6man-ra-pref64"/> for t
he PLAT prefix
discovery by means of Router Advertising.</t>
<t><xref target="I-D.li-intarea-nat64-prefix-dhcp
-option"/> for the PLAT prefix
discovery by means of DHCP.</t>
<t>If stateless NAT46 is supported, a mechanism t
o ensure that
multiple /64 are available, such as DHCPv6-PD <xr
ef target="RFC8415"/>.</t>
</list></t>
<t>There are several OpenSource implementations of CLAT, such as:
</t>
<t><list style="symbols">
<t>Android: https://github.com/ddrown/android_ext
ernal_android-clat.</t>
<t>Jool: https://www.jool.mx.</t>
<t>Linux: https://github.com/toreanderson/clatd.<
/t>
<t>OpenWRT: https://github.com/openwrt-routing/pa
ckages/blob/master/nat46/files/464xlat.sh.</t>
<t>VPP: https://git.fd.io/vpp/tree/src/plugins/na
t.</t>
</list></t>
</section>
<section title="ANNEX C: Benchmarking">
<t><xref target="RFC8219"/> has defined a benchmarking methodolog
y for IPv6
transition technologies. NAT64 and 464XLAT are addressed among th
e single and
double translation technologies, respectively. DNS64 is addressed
in
Section 9, and the methodology is more elaborated in <xref target
="DNS64-BM-Meth"/>.</t>
<t>Several documents provide references to benchmarking results, </figure>
for example
in the case of DNS64, <xref target="DNS64-Benchm"/>.</t>
</section>
<section title="ANNEX D: Changes from -00 to -01/-02"> <t>Several routers (i.e., the operator-provided
<t>Section to be removed after WGLC. CE and the downstream user-provided router) that enable
Significant updates are:<list style="numbers"> simultaneous routing and/or CLAT should be avoided to ensure th
<t>Text changes across all the document.</t> at multiple NAT44
</list></t> 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) <xref tar
get="RFC8375" format="default"/> is suggested.</t>
<t>Note that the procedure described here for the CE setup can be simplifi
ed
if the CE follows <xref target="RFC8585" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<name>CLAT Implementation</name>
<t>In addition to the regular set of features for a CE, a CLAT CE
implementation requires support for:</t>
<ul spacing="normal">
<li>
<xref target="RFC7915" format="default"/> for the NAT46 function.</li>
<li>
<xref target="RFC7050" format="default"/> for the PLAT prefix discover
y.</li>
<li>
<xref target="RFC7225" format="default"/> for the PLAT prefix discover
y if PCP is supported.</li>
<li>
<xref target="I-D.ietf-6man-ra-pref64" format="default"/> for the PLAT
prefix
discovery by means of Router Advertising.</li>
<li>
<xref target="I-D.li-intarea-nat64-prefix-dhcp-option" format="default
"/> for the PLAT prefix
discovery by means of DHCP.</li>
<section title="ANNEX E: Changes from -02 to -03"> <li>If stateless NAT46 is supported, a mechanism to ensure that
<t>Section to be removed after WGLC. multiple /64 are available, such as DHCPv6-PD <xr
Significant updates are:<list style="numbers"> ef target="RFC8415"/>, must be used.</li>
<t>Added references to new cited documents.</t> </ul>
<t>Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only LANs <t>There are several Open Source implementations of CLAT, such as:</t>
w/o DNS64.</t> <ul spacing="normal">
<t>Overall review and editorial changes.</t>
</list></t>
</section>
<section title="ANNEX F: Changes from -03 to -04"> <li>Android: <eref target="https://github.com/ddrown/android_external_an
<t>Section to be removed after WGLC. droid-clat"/></li>
Significant updates are:<list style="numbers"> <li>Jool: <eref target="https://www.jool.mx"/></li>
<t>Added text related to EAM considerations.</t> <li>Linux: <eref target="https://github.com/toreanderson/clatd"/></li>
</list></t>
</section>
<section title="ANNEX G: Changes from -04 to -05"> <li>OpenWRT: <eref target="https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&amp;
<t>Section to be removed after WGLC. a=search&amp;h=refs%2Ftags%2Fv19.07.0-rc1&amp;st=commit&amp;s=464xlat"/></li>
Significant updates are:<list style="numbers"> <li>VPP: <eref target="https://git.fd.io/vpp/tree/src/plugins/nat"/></li
<t>Added cross references to EAM section.</t> >
<t>Reworded "foreing DNS section".</t> </ul>
<t>Overall editorial review of text, pictures and nits correction.</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="ANNEX H: Changes from -05 to -06"> <name>Benchmarking</name>
<t>Section to be removed after WGLC. <t>A benchmarking methodology for IPv6
Significant updates are:<list style="numbers"> transition technologies has been defined in <xref target="RFC8219
<t>Corrected EAMT to EAM.</t> " format="default"/>. NAT64 and 464XLAT are addressed
<t>Typos and nits.</t> among the single- and
<t>New considerations regarding incoming connections.</t> double-translation technologies, respectively. DNS64 is addressed
</list></t> in
Section <xref target="RFC8219" sectionFormat="bare"
section="9"/>, and the methodology is elaborated in
<xref target="DNS64-BM-Meth" format="default"/> of that document.</t>
<t>Several documents provide references to benchmarking results, for examp
le,
for DNS64 <xref target="DNS64-Benchm" format="default"/>.</t>
</section> </section>
<section numbered="false" toc="default">
<section title="ANNEX H: Changes from -06 to -07"> <name>Acknowledgements</name>
<t>Section to be removed after WGLC. <t>The author would like to acknowledge the inputs of Gabor Lencse,
Significant updates are:<list style="numbers"> Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker,
<t>Inputs/clarifications from IESG review.</t> Mohamed Boucadair, Alejandro D'Egidio, Dan Wing, Mikael A
</list></t> brahamsson,
and Eric Vyncke.</t>
<t>Conversations with Marcelo Bagnulo, one of the coauthors of NAT64 and
DNS64, and email correspondence via the IETF mailing list
s with Mark Andrews
have been very useful for this work.</t>
<t>Work on this document was inspired by Christian Huitema, who suggested
that DNS64 should never be used when deploying CLAT
in the IETF network.</t>
</section> </section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1918" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.5389" ?>
<?rfc include="reference.RFC.5625" ?>
<?rfc include="reference.RFC.5766" ?>
<?rfc include="reference.RFC.6052" ?>
<?rfc include="reference.RFC.6535" ?>
<?rfc include="reference.RFC.7915" ?>
<?rfc include="reference.RFC.6144" ?>
<?rfc include="reference.RFC.6146" ?>
<?rfc include="reference.RFC.6147" ?>
<?rfc include="reference.RFC.6877" ?>
<?rfc include="reference.RFC.6887" ?>
<?rfc include="reference.RFC.7050" ?>
<?rfc include="reference.RFC.7225" ?>
<?rfc include="reference.RFC.7757" ?>
<?rfc include="reference.RFC.8174" ?>
<?rfc include="reference.RFC.8273" ?>
<?rfc include="reference.RFC.8305" ?>
<?rfc include="reference.RFC.8375" ?>
<?rfc include="reference.RFC.8415" ?>
<?rfc include="reference.RFC.8445" ?>
<?rfc include="reference.RFC.8484" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6889" ?>
<?rfc include="reference.RFC.6950" ?>
<?rfc include="reference.RFC.7051" ?>
<?rfc include="reference.RFC.7269" ?>
<?rfc include="reference.RFC.7755" ?>
<?rfc include="reference.RFC.7756" ?>
<?rfc include="reference.RFC.7849" ?>
<?rfc include="reference.RFC.7858" ?>
<?rfc include="reference.RFC.8094" ?>
<?rfc include="reference.RFC.8219" ?>
<?rfc include="reference.RFC.8585" ?>
<?rfc include="reference.I-D.ietf-6man-ra-pref64.xml" ?>
<?rfc include="reference.I-D.huitema-quic-dnsoquic.xml" ?>
<?rfc include="reference.I-D.lmhp-v6ops-transition-comparison.xml" ?>
<?rfc include="reference.I-D.bp-v6ops-ipv6-ready-dns-dnssec.xml" ?>
<?rfc include="reference.I-D.palet-v6ops-464xlat-opt-cdn-caches.xml" ?>
<?rfc include="reference.I-D.li-intarea-nat64-prefix-dhcp-option.xml" ?>
<?rfc include="reference.I-D.vixie-dns-rpz.xml" ?>
<?rfc include="reference.I-D.cheshire-sudn-ipv4only-dot-arpa.xml" ?>
<?rfc include="reference.I-D.ietf-tram-turnbis.xml" ?>
<?rfc include="reference.I-D.ietf-tram-stunbis.xml" ?>
<reference anchor="Threat-DNS64">
<front>
<title>Methodology for the identification of potential security issues
of different IPv6 transition technologies: Threat analysis of DNS64 and statefu
l NAT64</title>
<author initials="G" surname="Lencse">
</author>
<author initials="Y" surname="Kadobayashi">
</author>
<date month="August" year="2018" />
</front>
<seriesInfo name="Computers &amp; Security" value=""/>
<seriesInfo name="vol." value="77"/>
<seriesInfo name="no." value="1"/>
<seriesInfo name="pp." value="397-411"/>
<seriesInfo name="DOI" value="10.1016/j.cose.2018.04.012"/>
</reference>
<reference anchor="DNS64-Benchm">
<front>
<title>Benchmarking DNS64 Implementations: Theory and Practice</title>
<author initials="G" surname="Lencse">
</author>
<author initials="Y" surname="Kadobayashi">
</author>
<date month="September" year="2018" />
</front>
<seriesInfo name="Computer Communications" value=""/>
<seriesInfo name="vol." value="127"/>
<seriesInfo name="no." value="1"/>
<seriesInfo name="pp." value="61-74"/>
<seriesInfo name="DOI" value="10.1016/j.comcom.2018.05.005"/>
</reference>
<reference anchor="DNS64-BM-Meth">
<front>
<title>Benchmarking Methodology for DNS64 Servers</title>
<author initials="G" surname="Lencse">
</author>
<author initials="M" surname="Georgescu">
</author>
<author initials="Y" surname="Kadobayashi">
</author>
<date month="September" year="2017" />
</front>
<seriesInfo name="Computer Communications" value=""/>
<seriesInfo name="vol." value="109"/>
<seriesInfo name="no." value="1"/>
<seriesInfo name="pp." value="162-175"/>
<seriesInfo name="DOI" value="10.1016/j.comcom.2017.06.004"/>
</reference>
<reference anchor="About-DNS64" target="https://blog.apnic.net/2016/06/09/
lets-talk-ipv6-dns64-dnssec/">
<front>
<title>Let’s talk about IPv6 DNS64 &amp; DNSSEC</title>
<author initials="J" surname="Linkova">
<organization>APNIC Blog</organization>
</author>
<date year="2016" />
</front>
</reference>
<reference anchor="FCC" target="https://www.fcc.gov/reports-research/repor
ts/measuring-broadband-america/measuring-broadband-america-mobile-2013-2018">
<front>
<title>Measuring Broadband America Mobile 2013-2018 Coarsened Data</ti
tle>
<author>
<organization>FCC</organization>
</author>
<date year="2018" />
</front>
</reference>
<reference anchor="ARCEP" target="https://www.arcep.fr/cartes-et-donnees/n
os-publications-chiffrees/service-client-des-operateurs-mesures-de-la-qualite-de
-service/service-client-des-operateurs-les-mesures-de-qualite-de-service.html">
<front>
<title>Service client des opérateurs : les mesures de qualité de ser
vice</title>
<author>
<organization>ARCEP</organization>
</author>
<date year="2018" />
</front>
</reference>
<reference anchor="ISOC" target="https://www.internetsociety.org/resources
/2018/state-of-ipv6-deployment-2018/">
<front>
<title>State of IPv6 Deployment 2018</title>
<author>
<organization>ISOC</organization>
</author>
<date year="2018" />
</front>
</reference>
<reference anchor="RIPE-690" target="https://www.ripe.net/publications/do
cs/ripe-690">
<front>
<title>Best Current Operational Practice for Operators: I
Pv6 prefix assignment for end-users - persistent vs non-persistent, and what siz
e to choose</title>
<author surname="RIPE">
<organization> RIPE</organization>
</author>
<date month="October" year="2017" />
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 280 change blocks. 
2184 lines changed or deleted 1949 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/