<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
     docName="draft-ietf-v6ops-nat64-deployment-08" submissionType="IETF" consensus="yes"
docName="draft-ietf-v6ops-nat64-deployment-08"> consensus="true" number="8683" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="6" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.35.0 -->
  <front>
    <title abbrev="NAT64/464XLAT Deployment">
  Additional NAT64/464XLAT Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks</title>
    <seriesInfo name="RFC" value="8683"/>
    <author fullname="Jordi Palet Martinez" initials="J" surname="Palet Martinez">
      <organization>The IPv6 Company</organization>
      <address>
        <postal>
          <street>Molino de la Navata, 75</street>
          <city>La Navata - Galapagar</city>
          <region>Madrid</region>
          <code>28420</code>
          <country>Spain</country>
        </postal>
        <email>jordi.palet@theipv6company.com</email>
        <uri>http://www.theipv6company.com/</uri>
      </address>
    </author>
    <date year="2019"/> year="2019" month="November"/>
    <workgroup>v6ops</workgroup>
    <keyword>
      IPv6, DNSSEC, NAT64, DNS64, 464XLAT, CLAT, NAT46, PLAT
    </keyword>
    <abstract>
      <t>This document describes how NAT64 Network Address and Protocol
   Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed
			in an IPv6 network, network -- whether it's cellular ISP, broadband ISP,
			or enterprise, enterprise -- and the possible
			optimizations.
			The
			This document also discusses issues to be considered when having
			IPv6-only connectivity, regarding: such as:
			a) DNS64,
			b) applications or devices that use literal IPv4 addresses or
			non-IPv6 compliant
			non-IPv6-compliant APIs,
			and c) IPv4-only hosts or applications.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Stateful NAT64 (<xref target="RFC6146"/>) <xref target="RFC6146" format="default"/> describes a stateful IPv6 to IPv4 IPv6-to-IPv4
		translation mechanism, which mechanism that allows IPv6-only hosts to communicate with
		IPv4-only servers using unicast UDP, TCP, or ICMP, ICMP by means of IPv4 public
		addresses sharing,
		address sharing among multiple IPv6-only
		hosts. Unless otherwise stated, references in the rest of this document
		to NAT64 (function) in this document should be interpreted as to Stateful NAT64.</t>
      <t>The translation of the packet headers is done using the IP/ICMP
		translation algorithm defined in <xref target="RFC7915"/> and target="RFC7915" format="default"/>;
		algorithmically translating the IPv4 addresses to IPv6 addresses addresses,
		and vice versa, is done following <xref target="RFC6052"/>.</t> target="RFC6052" format="default"/>.</t>
      <t>DNS64 (<xref target="RFC6147"/>) <xref target="RFC6147" format="default"/> is in charge of the synthesis
		of AAAA records from the A records, so it only works for applications
		making use of DNS. It was designed to avoid changes in both, both
		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="RFC6147"/>,
		target="RFC6147" sectionFormat="of" section="5.5"/>,
		a security-aware and validating host has to perform the
		DNS64 function locally.</t>
      <t>However, the use of NAT64 and/or DNS64 present presents three drawbacks:</t>

			<t><list style="letters">

			<t>Because
      <ol spacing="normal" type="1">

        <li>Because DNS64 (<xref target="RFC6147"/>) <xref target="RFC6147" format="default"/> modifies DNS answers,
			and DNSSEC is designed to detect such modifications, DNS64
			(<xref target="RFC6147"/>)
			<xref target="RFC6147" format="default"/> may potentially break DNSSEC, depending on
			a number of factors, factors such as the location of the DNS64
			function (at a DNS server or validator, at the end host, ...), how it
			has been configured, if the end-hosts is end hosts are validating, etc.</t>

			<t>Because etc.</li>
        <li>Because of the need of using to use DNS64 (<xref target="RFC6147"/>) <xref target="RFC6147" format="default"/> or
			an alternative "host/application built-in" mechanism for address synthesis,
			there may be an issue for NAT64 (<xref target="RFC6146"/>),
			as <xref target="RFC6146" format="default"/>
			because it doesn't work when IPv4 literal addresses or non-IPv6 compliant non-IPv6-compliant
			APIs are being used.</t>

			<t>NAT64 alone, used.</li>

        <li>NAT64 alone was not designed to provide a solution for
			IPv4-only hosts or applications that are located within a network
			which are
			and connected to a service provider IPv6-only access, access link,
			as it was designed for a very specific
	scenario (<xref target="RFC6144"/>, Section 2.1).</t>

			</list></t>

		<t>Above (see <xref target="RFC6144" sectionFormat="of" section="2.1"/>).</li>
      </ol>
      <t>The drawbacks discussed above may be true come into play if part of, of an enterprise network, 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 which that may
		apply to many other similar cases. All of them are deployment specific.</t>

		<t>According to that, across this document,

      <t>Accordingly, the use of "operator",
		"operator network", "service provider", and similar ones, terms in this document
		are interchangeable with equivalent cases of enterprise networks
		(and networks; other cases may be similar ones). as well. This may be also the case for "managed end-user
		networks".</t>
      <t>Note that if all the hosts in a network were performing the address synthesis,
		as described in Section 7.2 of <xref target="RFC6147"/>, target="RFC6147"
		sectionFormat="of" section="7.2"/>, some of the drawbacks
		may vanish. not apply. However, it is unrealistic today to expect that,
		that in today's world, considering
		the high number of devices and applications that aren't yet IPv6-enabled.
		So, in IPv6 enabled.
		In this document, this the case in which all hosts provide synthesis will be considered only for specific scenarios
		that can guarantee it.</t>
      <t>An analysis of stateful IPv4/IPv6 mechanisms is provided in
		<xref target="RFC6889"/>.</t> target="RFC6889" format="default"/>.</t>
      <t>This document looks into different possible NAT64 (<xref target="RFC6146"/>) <xref target="RFC6146" format="default"/>
		deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and similar ones,
		which ones
		that were not documented in <xref target="RFC6144"/>, target="RFC6144" format="default"/>, such as 464XLAT
		(<xref target="RFC6877"/>),
		<xref target="RFC6877" format="default"/> in operator (broadband and cellular) and
		enterprise networks, and networks; it provides guidelines to avoid operational issues.</t>

		<t>Towards that, this
      <t>This document first looks into also explores the possible NAT64 deployment
		scenarios (split in "known to work" and "known to work under special conditions"),
		providing a quick and generic comparison table among them.
		Then
		Then, the document describes the issues that an operator need needs to understand
		on different matters that understand, which
	        will allow to define what is the best
		approach/scenario to be defined for each specific network case. A summary provides some
		recommendations and decision points.

		A section with clarifications
		on the usage of this document for enterprise networks, networks is also provided.
		Finally, an annex <xref target="AppendixA"/> provides an example of a broadband deployment using 464XLAT
		and another annex provides hints for a CLAT customer-side translator (CLAT) implementation.</t>
      <t><xref target="RFC7269"/> target="RFC7269" format="default"/> already provides information about
		NAT64 deployment options and experiences. Both, this This document and
		<xref target="RFC7269"/> target="RFC7269" format="default"/> are complementary; they are looking both look into
		different deployment considerations and furthermore, considerations. Furthermore, this document is
		considering considers the updated deployment experience and newer standards.</t>
      <t>The target deployment scenarios in this document
		may also be covered as well by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. Note that this is
		true only for the case of broadband networks, as networks; in the case of cellular
		networks
		networks, the only supported solution is the use of NAT64/464XLAT.
		So, it is out of scope of this document to provide a comparison among the
		different IPv4aaS transition mechanisms, which is being are analyzed already
		in <xref target="I-D.lmhp-v6ops-transition-comparison"/>.</t> target="I-D.lmhp-v6ops-transition-comparison" format="default"/>.</t>
      <t>Consequently, this document should not be understood used as a guide for
		an operator or enterprise to decide which IPv4aaS is the best one for
		its own network. Instead Instead, it should be used as a tool for understanding
		all the implications, including relevant documents (or even specific
		parts of them), them) for the deployment of NAT64/464XLAT and facilitate for facilitating
		the decision process regarding specific deployment details.</t>
    </section>
    <section title="Requirements Language">
			<t>The numbered="true" toc="default">
      <name>Requirements Language</name>
      <t>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
			"OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
			BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/>
    when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section title="NAT64 numbered="true" toc="default">
      <name>NAT64 Deployment Scenarios">
		<t>Section 7 of DNS64 (<xref target="RFC6147"/>), Scenarios</name>
      <t>DNS64 (see <xref target="RFC6147"
      sectionFormat="of" section="7"/>) provides three deployment scenarios,
		depending on the location of the DNS64 function. However, since the publication
		of that document, other deployment scenarios and NAT64 use cases need to
		be considered in actual networks, despite the fact that some of them were specifically
		ruled out by the original NAT64/DNS64 work.</t>
      <t>Consequently, the perspective in this document is
		to broaden those scenarios,
		including scenarios and
		include a few new ones. However, in order to be able to reduce the number
		of possible cases, we work under the assumption that typically, the service
		provider wants to make sure that all the customers have a service
		without failures. This means considering the following assumptions
		for the worst possible case:</t>

			<t><list style="letters">
				<t>There
      <ol spacing="normal" type="a">
        <li>There are hosts that will be validating DNSSEC.</t>
				<t>IPv4 DNSSEC.</li>
        <li>IPv4 literal addresses and non-IPv6 compliant non-IPv6-compliant APIs are being used.</t>
				<t>There used.</li>
        <li>There are IPv4-only hosts or applications beyond the
				IPv6-only link (e.g., tethering in cellular networks).</t>
			</list></t>

		<t>The networks).</li>
      </ol>
      <t>This document uses a common set of possible "participant entities":</t>

			<t><list style="numbers">
				<t>An
      <ol spacing="normal" type="1">
        <li>An IPv6-only access network (IPv6).</t>
				<t>An (IPv6).</li>
        <li>An IPv4-only remote network/server/service (IPv4).</t>
				<t>A (IPv4).</li>
        <li>A NAT64 function (NAT64) in the service provider.</t>
				<t>A provider.</li>
        <li>A DNS64 function (DNS64) in the service provider.</t>
				<t>An provider.</li>
        <li>An external service provider offering the NAT64 function and/or the
				DNS64 function (extNAT64/extDNS64).</t>
				<t>464XLAT customer side (extNAT64/extDNS64).</li>
        <li>A 464XLAT customer-side translator (CLAT).</t>
			</list></t> (CLAT).</li>
      </ol>
      <t>Note that the nomenclature used in parenthesis parentheses is the one that, for short,
		will be used in the figures. Note also that Note: for simplicity, the boxes in
		the figures don't mean they are actually a single device; they just represent
		one or more functions as located in that part of the network (i.e. (i.e., a single box
		with NAT64 and DNS64 functions can actually be several devices, not just one).</t>
      <t>The possible scenarios are split in two general categories:<list style="numbers">
				<t>Known categories:</t>
      <ol spacing="normal" type="1">
        <li>Known to work.</t>
				<t>Known work.</li>
        <li>Known to work under special conditions.</t>
		</list></t> conditions.</li>
      </ol>
      <section title="Known numbered="true" toc="default">
        <name>Known to Work"> Work</name>
        <t>The scenarios in this category are known to work, as there are well-known
			existing deployments from different operators using them. Each one may have
			different pros and cons, and in some cases cases, the trade-offs,
			maybe trade-offs
			may be acceptable for some operators.</t>
        <section title="Service anchor="spnatdns64" numbered="true" toc="default">
          <name>Service Provider NAT64 with DNS64" anchor="spnatdns64"> DNS64</name>
          <t>In this scenario (<xref target="sp-nat64-dns64"/>), target="sp-nat64-dns64" format="default"/>), the service
				provider offers both, both the NAT64 and the DNS64 functions.</t>
          <t>This is the most common scenario as originally considered by
				the designers of NAT64 (<xref target="RFC6146"/>) <xref target="RFC6146" format="default"/> and
				DNS64 (<xref target="RFC6147"/>), however
				also <xref target="RFC6147" format="default"/>; however,
				it may also have the implications related to the DNSSEC.</t>

          <t>This scenario also may also fail to solve the issue issues of
				IPv4 literal addresses or non-IPv6 compliant addresses, non-IPv6-compliant APIs, as well as
				the issue of or
				IPv4-only hosts or applications behind the
				IPv6-only access network.</t>
          <figure align="center" anchor="sp-nat64-dns64"
                title="NAT64 anchor="sp-nat64-dns64">
            <name>NAT64 with DNS64"> DNS64</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+----------+        +----------+        +----------+
|          |        |  NAT64   |        |          |
|   IPv6   +--------+    +     +--------+   IPv4   |
|          |        |  DNS64   |        |          |
+----------+        +----------+        +----------+
            ]]></artwork>        +----------+]]></artwork>

          </figure>
          <t>A similar scenario (<xref target="sp-dns64-e-nat64"/>) will be target="sp-dns64-e-nat64"
	  format="default"/>) exists if
				the service provider offers only the
				DNS64 function, and function; the NAT64
				function is provided by an outsourcing agreement with
				an external provider.
				All the considerations in the previous paragraphs of this
				section,
				section are the same for this sub-case.</t>
          <figure align="center" anchor="sp-dns64-e-nat64"
                title="NAT64 anchor="sp-dns64-e-nat64">
            <name>NAT64 in external service provider"> an External Service Provider</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                    +----------+        +----------+
                    |          |        |          |
                    | extNAT64 +--------+   IPv4   |
                    |          |        |          |
                    +----+-----+        +----------+
                         |
                         |
+----------+        +----+-----+
|          |        |          |
|   IPv6   +--------+  DNS64   +
|          |        |          |
+----------+        +----------+
            ]]></artwork>        +----------+]]></artwork>

          </figure>
          <t>This is equivalent to the scenario (<xref target="e-nat64-dns64"/>) target="e-nat64-dns64" format="default"/>)
				where the outsourcing
				agreement with the external provider is to provide both the
				NAT64 and DNS64 functions. Once more, all the considerations
				in the previous paragraphs of this section are the same
				for this sub-case.</t>
          <figure align="center" anchor="e-nat64-dns64"
                title="NAT64 anchor="e-nat64-dns64">
            <name>NAT64 and DNS64 in external provider"> an External Provider</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                    +----------+       +----------+
                    | extNAT64 |       |          |
                    |    +     +-------+   IPv4   |
                    | extDNS64 |       |          |
                    +----+-----+       +----------+
                         |
+----------+             |
|          |             |
|   IPv6   +-------------+
|          |
+----------+
            ]]></artwork>
+----------+]]></artwork>

          </figure>
          <t>One additional equivalent scenario (<xref target="sp-nat64-e-dns64"/>)
				will be target="sp-nat64-e-dns64" format="default"/>)
				exists if the service provider
				only offers the NAT64 function only, and function; the DNS64 function is from an
				external provider with or without a specific agreement among them.
				This is a scenario already common scenario today, as
				several "global" service providers provide free DNS/DNS64
				services
				services, and users often configure manually their DNS. DNS manually. This
				will only work if both the NAT64 and the DNS64 functions are using the
				WKP (Well-Known Prefix)
				Well-Known Prefix (WKP) or the same NSP (Network-Specific Prefix). Network-Specific Prefix (NSP).
				All the considerations in the previous paragraphs
				of this section, section are the same for this sub-case.</t>

          <t>Of course, if the external DNS64 function is agreed with the
				service provider, then we are in the same this case as in is similar to the previous
				ones already depicted in this scenario.</t>
          <figure align="center" anchor="sp-nat64-e-dns64"
                title="NAT64; anchor="sp-nat64-e-dns64">
            <name>NAT64; DNS64 by external provider"> an External Provider</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                    +----------+
                    |          |
                    | extDNS64 |
                    |          |
                    +----+-----+
                         |
                         |
+----------+        +----+-----+        +----------+
|          |        |          |        |          |
|   IPv6   +--------+  NAT64   +--------+   IPv4   |
|          |        |          |        |          |
+----------+        +----------+        +----------+
            ]]></artwork>        +----------+]]></artwork>

          </figure>
        </section>
        <section title="Service numbered="true" toc="default">
          <name>Service Provider Offering 464XLAT, with DNS64"> 464XLAT Using DNS64</name>
          <t>464XLAT (<xref target="RFC6877"/>) <xref target="RFC6877" format="default"/> describes an architecture that
			provides IPv4 connectivity across a network, or part of it,
			when it is only natively transporting IPv6. <xref target="RFC7849"/>
			already suggest the
			The need to support the CLAT function in order to
			ensure the IPv4 service continuity in IPv6-only cellular deployments.</t> deployments has been suggested in <xref target="RFC7849" format="default"/>.</t>
          <t>In order to do that, 464XLAT (<xref target="RFC6877"/>) <xref target="RFC6877" format="default"/> relies on the
			combination of existing protocols:</t>
			<t><list style="numbers">
				<t>The customer-side translator (CLAT)
          <ol spacing="normal" type="1">
            <li>The CLAT is a stateless IPv4 to IPv6 IPv4-to-IPv6
				translator (NAT46) (<xref target="RFC7915"/>) <xref target="RFC7915" format="default"/> implemented in the
				end-user device or CE (Customer Customer Edge Router), Router (CE), located at the
				"customer edge" of the network.</t>
				<t>The network.</li>
            <li>The provider-side translator (PLAT) is a stateful NAT64
				(<xref target="RFC6146"/>),
				<xref target="RFC6146" format="default"/>, implemented typically at in
				the operator network.</t>
				<t>Optionally, network.</li>
            <li>Optionally, DNS64 (<xref target="RFC6147"/>), <xref target="RFC6147" format="default"/> may allow
				an optimization: a single translation at the NAT64, instead
				of two translations (NAT46+NAT64), when the application at
				the end-user device supports IPv6 DNS (uses AAAA
				Resource Records).</t>
			</list></t> Records).</li>
          </ol>
          <t>Note that even if in the 464XLAT (<xref target="RFC6877"/>) terminology, the provider-side translator is referred to as PLAT, PLAT in the
                        464XLAT terminology <xref target="RFC6877" format="default"/>, for simplicity and
			uniformity,
			uniformity across this document document, it is always referred to as NAT64 (function).</t>
          <t>In this scenario (<xref target="sp-464xlat-dns64"/>) target="sp-464xlat-dns64" format="default"/>), the service provider
			deploys 464XLAT with a DNS64 function.</t>
          <t>As a consequence, the DNSSEC issues remain, unless the host
			is doing the address synthesis.</t>
          <t>464XLAT (<xref target="RFC6877"/>) <xref target="RFC6877" format="default"/> is a very simple approach to cope
			with the major NAT64+DNS64 drawback: Not not working with applications or
			devices that use literal IPv4 addresses or non-IPv6 compliant non-IPv6-compliant APIs.</t>
          <t>464XLAT (<xref target="RFC6877"/>) <xref target="RFC6877" format="default"/> has been used initially mainly in
			IPv6-only cellular networks. By supporting a CLAT function, the end-user
			device applications can access IPv4-only end-networks/applications, end networks / applications,
			despite the fact that those applications or devices use literal IPv4 addresses
			or non-IPv6 compliant non-IPv6-compliant APIs.</t>
          <t>In addition to that, addition, in the same example of the cellular network example above,
			if the User Equipment (UE) provides tethering, other devices behind it
			will be presented with a traditional NAT44, Network Address Translation from IPv4 to IPv4 (NAT44), in addition to the native
			IPv6 support, so clearly it allows IPv4-only hosts behind the IPv6-only
			access network.</t>
          <t>Furthermore, as discussed in <xref target="RFC6877"/>, target="RFC6877" format="default"/>, 464XLAT
			can be used in broadband IPv6 network architectures,
			by implementing the CLAT function at the CE.</t>
          <t>The support of this scenario in a network, network offers two additional advantages:</t>
			<t><list style="symbols">
				<t>DNS
          <ul spacing="normal">
            <li>DNS load optimization: A CLAT should implement a DNS proxy
				(as per
				(per <xref target="RFC5625"/>), target="RFC5625" format="default"/>) so that only IPv6 native IPv6-native queries
				and only for AAAA records are sent to the DNS64 server. Otherwise Otherwise,
				doubling the number of queries may impact the DNS infrastructure.</t>
				<t>Connection infrastructure.</li>
            <li>Connection establishment delay optimization: If the UE/CE
				implementation is detecting the presence of a DNS64 function,
				it may issue only the AAAA query, instead of both the AAAA
				and A queries.</t>
			</list></t> queries.</li>
          </ul>
          <t>In order to understand all the communication possibilities, let's
			assume the following representation of two
	  dual-stack (DS) peers:</t>

        <figure align="center" suppress-title="true"
                title="Figure A: Representation of 464XLAT among two peers with DNS64">

          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
               +-------+     .-----.                     .-----.
               |       |    /       \                   /       \
   .-----.     | Res./ |   /  IPv6-  \     .-----.     /  IPv4-  \
  / Local \    | SOHO  +--(   only    )---( NAT64 )---(   only    )
 /         \   |       |   \  flow   /\    `-----´    `-----'     \  flow   /
(   Dual-   )--+ IPv6  |    \       /  \              / \       /
 \  Stack  /   |  CE   |     `--+--´     `--+--'    \   .-----.  /   `--+--´   `--+--'
  \ Peer  /    | with  |        |        \ / Remote\/       |
   `-----´
   `-----'     | CLAT  |    +---+----+    /         \    +---+----+
               |       |    |DNS/IPv6|   (   Dual-   )   |DNS/IPv4|
               +-------+    |  with  |    \  Stack  /    +--------+
                            | DNS64  |     \ Peer  /
                            +--------+      `-----´      `-----'

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

]]></artwork>
        </figure>

			<t>The

          <t>In this case, the possible communication paths, among the IPv4/IPv6 stacks of
			both peers, in this case, are:</t>
			<t><list style="letters">
				<t>Local-IPv6 are as follows:</t>
          <ol spacing="normal" type="a">
            <li>Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.</t>
				<t>Local-IPv6 peers.</li>
            <li>Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.</t>
				<t>Local-IPv4 translation.</li>
            <li>Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
				implements EAM (Explicit Explicit Address Mappings) Mappings (EAMs) as indicated by
				<xref target="EAM"/>. target="EAM" format="default"/>. In principle,
				it is not expected that services are deployed in the Internet when using
				IPv6-only,
				IPv6 only, unless there is certainty that peers will also be
				IPv6-capable.</t>
				<t>Local-IPv4
				IPv6 capable.</li>
            <li>Local-IPv4 to Remote-IPv4: DNS64, CLAT CLAT, and NAT64 translations.</t>
				<t>Local-IPv4 translations.</li>
            <li>Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT
				implements EAM as indicated by <xref target="EAM"/>, target="EAM" format="default"/>, instead of
				using the path d. above, NAT64 translation is avoided avoided, and the
				flow will use IPv6 from the CLAT to the destination.</t>
			</list></t> destination.</li>
          </ol>
          <t>The rest of the figures in this section show different choices for placing
			the different elements.</t>
          <figure align="center" anchor="sp-464xlat-dns64"
                title="464XLAT anchor="sp-464xlat-dns64">
            <name>464XLAT with DNS64"> DNS64</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+----------+        +----------+        +----------+
|   IPv6   |        |  NAT64   |        |          |
|     +    +--------+    +     +--------+   IPv4   |
|   CLAT   |        |  DNS64   |        |          |
+----------+        +----------+        +----------+ ]]></artwork>

          </figure>
          <t>A similar scenario (<xref target="ext-nat64-464xlatdns64"/>) will be target="ext-nat64-464xlatdns64" format="default"/>) exists
				if the service provider
				offers only
				offers the DNS64 function, and function; the NAT64 function is provided by
				an outsourcing agreement with an external provider.
				All the considerations in the previous paragraphs of this
				section are the same for this sub-case.</t>
          <figure align="center" anchor="ext-nat64-464xlatdns64"
                title="464XLAT anchor="ext-nat64-464xlatdns64">
            <name>464XLAT with DNS64; NAT64 in external provider"> an External Provider</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                    +----------+        +----------+
                    |          |        |          |
                    | extNAT64 +--------+   IPv4   |
                    |          |        |          |
                    +----+-----+        +----------+
                         |
                         |
+----------+        +----+-----+
|   IPv6   |        |          |
|     +    +--------+  DNS64   +
|   CLAT   |        |          |
+----------+        +----------+
            ]]></artwork>        +----------+]]></artwork>

          </figure>

				<t>As well,
          <t>In addition, it is equivalent to the scenario (<xref target="ext-nat64-dns64-464xlatdns64"/>) target="ext-nat64-dns64-464xlatdns64" format="default"/>)
				where the outsourcing
				agreement with the external provider is to provide both the
				NAT64 and DNS64 functions. Once more, all the considerations
				in the previous paragraphs of this section are the same
				for this sub-case.</t>
          <figure align="center" anchor="ext-nat64-dns64-464xlatdns64"
                title="464XLAT anchor="ext-nat64-dns64-464xlatdns64">
            <name>464XLAT with DNS64; NAT64 and DNS64 in external provider"> an External Provider</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                    +----------+        +----------+
                    | extNAT64 |        |          |
                    |    +     +--------+   IPv4   |
                    | extDNS64 |        |          |
                    +----+-----+        +----------+
                         |
+----------+             |
|   IPv6   |             |
|     +    +-------------+
|   CLAT   |
+----------+
            ]]></artwork>
+----------+]]></artwork>

          </figure>
        </section>
        <section title="Service anchor="xlat-dns64" numbered="true" toc="default">
          <name>Service Provider Offering 464XLAT,     without DNS64" anchor="xlat-dns64"> Using DNS64</name>
          <t>The major advantage of this scenario (<xref target="sp-464xlat"/>), target="sp-464xlat" format="default"/>),
			using 464XLAT without DNS64,
			is that the service provider ensures that DNSSEC is never broken, even
			in case
			if the user modifies the DNS configuration. Nevertheless, some
			CLAT implementations or applications may impose an extra delay, which
			is induced by the dual A/AAAA queries (and the wait for both responses),
			unless Happy Eyeballs v2 (<xref target="RFC8305"/>) <xref target="RFC8305" format="default"/> is also present.</t>
          <t>A possible variation of this scenario is the case when DNS64 is
			used only for the discovery of the NAT64 prefix. The In the rest of the document document,
			it is not considering it as considered a different scenario, scenario because once the prefix
			has been discovered, the DNS64 function is not used, so it behaves as if
			the DNS64 synthesis function is not present.</t>
          <t>In this scenario, as in the previous one, there are no
			issues related to IPv4-only hosts (or IPv4-only applications)
			behind the IPv6-only access network, as neither are related to the
			usage of IPv4 literals or non-IPv6 compliant non-IPv6-compliant APIs.</t>
          <t>The support of this scenario in a network, network offers one advantage:</t>
			<t><list style="symbols">
				<t>DNS
          <ul spacing="normal">
            <li>DNS load optimization: A CLAT should implement a DNS proxy
				(as per
				(per <xref target="RFC5625"/>), target="RFC5625" format="default"/>) so that only IPv6 native queries
				are sent to the DNS64 server. Otherwise Otherwise, doubling the number of
				queries may impact the DNS infrastructure.</t>
			</list></t> infrastructure.</li>
          </ul>
          <t>As indicated earlier, the connection establishment delay optimization
			is achieved only in the case of devices, Operating Systems, or applications
			that use Happy Eyeballs v2 (<xref target="RFC8305"/>), <xref target="RFC8305" format="default"/>, which is very common.</t>

			<t>Let's
          <t>As in the previous case, let's assume the representation of two dual-stack peers as in the
			previous case:</t>

        <figure align="center" suppress-title="true"
                title="Figure B: Representation of 464XLAT among two peers without DNS64"> peers:</t>

          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
               +-------+     .-----.                     .-----.
               |       |    /       \                   /       \
   .-----.     | Res./ |   /  IPv6-  \     .-----.     /  IPv4-  \
  / Local \    | SOHO  +--(   only    )---( NAT64 )---(   only    )
 /         \   |       |   \  flow   /\    `-----´    `-----'     \  flow   /
(   Dual-   )--+ IPv6  |    \       /  \              / \       /
 \  Stack  /   |  CE   |     `--+--´     `--+--'    \   .-----.  /   `--+--´   `--+--'
  \ Peer  /    | with  |        |        \ / Remote\/       |
   `-----´
   `-----'     | CLAT  |    +---+----+    /         \    +---+----+
               |       |    |DNS/IPv6|   (   Dual-   )   |DNS/IPv4|
               +-------+    +--------+    \  Stack  /    +--------+
                                           \ Peer  /
                                            `-----´
                                            `-----'

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

]]></artwork>
        </figure>

			<t>The

          <t>In this case, the possible communication paths, among the IPv4/IPv6 stacks of
			both peers, in this case, are:</t>
			<t><list style="letters">
				<t>Local-IPv6 are as follows:</t>
          <ol spacing="normal" type="a">
            <li>Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.</t>
				<t>Local-IPv6 peers.</li>
            <li>Local-IPv6 to Remote-IPv4: Regular DNS, CLAT CLAT, and NAT64 translations.</t>
				<t>Local-IPv4 translations.</li>
            <li>Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
				implements EAM as indicated by <xref target="EAM"/>. target="EAM" format="default"/>. In principle,
				it is not expected that services are deployed in the Internet using
				IPv6-only,
				IPv6 only, unless there is certainty that peers will also be
				IPv6-capable.</t>
				<t>Local-IPv4
				IPv6-capable.</li>
            <li>Local-IPv4 to Remote-IPv4: Regular DNS, CLAT CLAT, and NAT64 translations.</t>
				<t>Local-IPv4 translations.</li>
            <li>Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT
				implements EAM as indicated by <xref target="EAM"/>, target="EAM" format="default"/>, instead of
				using the path d. above, NAT64 translation is avoided avoided, and the flow
				will use IPv6 from the CLAT to the destination.</t>
			</list></t>

			<t>It needs to be noticed destination.</li>
          </ol>
          <t>Notice that this scenario works while the local
			hosts/applications are dual-stack dual stack (which is the current situation), situation)
			because the connectivity from a local-IPv6 local IPv6 to a remote-IPv4 remote IPv4 is not possible
			without an a AAAA synthesis. This aspect is important only when there are IPv6-only hosts in the LANs behind the CLAT there are IPv6-only hosts and they need to
			communicate with remote IPv4-only hosts. However, it doesn't look is not a sensible
			approach from an Operating System or application vendor
			perspective,
			perspective to provide IPv6-only support unless,
			similarly
			similar to case c above, there is certainty of peers supporting
			IPv6 as well. A solution An approach to a solution for this is also presented
			in <xref target="I-D.palet-v6ops-464xlat-opt-cdn-caches"/>.</t> 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>
          <figure align="center" anchor="sp-464xlat"
                title="464XLAT anchor="sp-464xlat">
            <name>464XLAT without DNS64"> DNS64</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+----------+        +----------+        +----------+
|   IPv6   |        |          |        |          |
|     +    +--------+  NAT64   +--------+   IPv4   |
|   CLAT   |        |          |        |          |
+----------+        +----------+        +----------+
            ]]></artwork>        +----------+]]></artwork>

          </figure>
          <t>This is equivalent to the scenario (<xref target="ext-nat64-464xlat"/>) target="ext-nat64-464xlat" format="default"/>)
				where there is an
				outsourcing agreement with an external provider for the
				NAT64 function. All the considerations in the previous
				paragraphs of this section are the same for this sub-case.</t>
          <figure align="center" anchor="ext-nat64-464xlat"
                title="464XLAT anchor="ext-nat64-464xlat">
            <name>464XLAT without DNS64; NAT64 in external provider"> an External Provider</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                    +----------+        +----------+
                    |          |        |          |
                    | extNAT64 +--------+   IPv4   |
                    |          |        |          |
                    +----+-----+        +----------+
                         |
+----------+             |
|   IPv6   |             |
|     +    +-------------+
|   CLAT   |
+----------+
            ]]></artwork>
+----------+]]></artwork>

          </figure>
        </section>
      </section>
      <section title="Known numbered="true" toc="default">
        <name>Known to Work Under under Special Conditions"> Conditions</name>
        <t>The scenarios in this category are known to
			not to work unless significant
			effort is devoted to solve solving the issues, issues or they are intended to solve problems
			across "closed" networks, networks instead of as a general Internet access usage.
			In addition to

			Even though some of the different pros, cons cons, and trade-offs,
			which trade-offs
			may be acceptable for some operators, they acceptable, operators have implementation
			difficulties, as they are beyond the original their expectations of the
			NAT64/DNS64 are beyond the original intent.</t>
        <section title="Service anchor="onlynat64" numbered="true" toc="default">
          <name>Service Provider NAT64 without DNS64" anchor="onlynat64"> DNS64</name>
          <t>In this scenario (<xref target="only-nat64"/>), target="only-nat64" format="default"/>),
				the service provider offers a NAT64 function,
				however function;
				however, there is no DNS64 function support at all.</t>
          <t>As a consequence, an IPv6 host in the IPv6-only
				access network, network will not be able to detect the presence
				of DNS64 by means of <xref target="RFC7050"/>, neither to target="RFC7050" format="default"/> or learn the
				IPv6 prefix to be used for the NAT64 function.</t>
          <t>This can be sorted out as indicated in <xref target="nodns64"/>.</t>

				<t>However, despite that, target="nodns64" format="default"/>.</t>
          <t>Regardless, because of the lack of the DNS64
				function, the IPv6 host will not be able to obtain
				AAAA synthesized records, so the NAT64 function becomes useless.</t>
          <t>An exception to this "useless" scenario will be is to
				manually configure mappings between the A records of each
				of the IPv4-only remote hosts and the corresponding AAAA records, records
				with the WKP (Well-Known Prefix) or NSP (Network-Specific Prefix)
				used by the service provider service-provider NAT64 function,
				as if they were synthesized by a DNS64 function.</t>
          <t>This mapping could be done by several means, typically
				at the authoritative DNS server, server or at the service provider service-provider
				resolvers by means of DNS RPZ (Response Response Policy Zones, Zones (RPZs)
				<xref target="I-D.vixie-dns-rpz"/>) target="I-D.vixie-dnsop-dns-rpz" format="default"/> or equivalent functionality.
				DNS RPZ, RPZ may have implications in DNSSEC, DNSSEC if the zone is signed.
				Also, if the service provider is using an NSP, having the mapping
				at the authoritative server, server may create troubles to for other parties
				trying to use a different NSP or the WKP, unless multiple DNS "views"
				(split-DNS) is are also being used at the authoritative servers.</t>
                               <t>Generally, the mappings alternative, alternative will only make sense
				if a few set sets of IPv4-only remote hosts need to be accessed
				by a single network (or a small number of them), which support
				IPv6-only supports
				IPv6 only in the access.
                                This will require some kind of mutual
				agreement for using this procedure, so it doesn't care if they
				become procedure; this should not be a trouble for other parties across problem because it won't interfere with Internet
				("closed services").</t> use (which is a "closed service").</t>
          <t>In any case, this scenario doesn't solve the issue of
				IPv4 literal addresses or non-IPv6 compliant addresses, non-IPv6-compliant APIs, neither it
				solves the problem of or IPv4-only
                                hosts within that IPv6-only access network.</t>
          <figure align="center" anchor="only-nat64"
                title="NAT64 anchor="only-nat64">
            <name>NAT64 without DNS64"> DNS64</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+----------+        +----------+        +----------+
|          |        |          |        |          |
|   IPv6   +--------+  NAT64   +--------+   IPv4   |
|          |        |          |        |          |
+----------+        +----------+        +----------+
            ]]></artwork>        +----------+]]></artwork>

          </figure>
        </section>
        <section title="Service Provider numbered="true" toc="default">
          <name>Service-Provider NAT64; DNS64 in the IPv6 hosts"> Hosts</name>
          <t>In this scenario (<xref target="sp-nat64-h-dns64"/>), target="sp-nat64-h-dns64" format="default"/>),
				the service provider offers the
				NAT64 function, function but not the DNS64 function. However, the IPv6 hosts
				have a built-in DNS64 function.</t>
          <t>This may become common if the DNS64 function is
				implemented in all the IPv6 hosts/stacks.
				However, commonly this
				This is not common at the actual
				situation, even if it
				time of writing but may happen become more
				common in the medium-term.
				At this near future.
				This way, the DNSSEC validation is performed on the A record,
				and then the host can use the DNS64 function so to be able in order to
				use the NAT64 function, function without any DNSSEC issues.</t>
          <t>This scenario fails to solve the issue of
				IPv4 literal addresses or non-IPv6 compliant non-IPv6-compliant APIs, unless
				the IPv6 hosts also supports support Happy Eyeballs v2
				(<xref target="RFC8305"/>, Section 7.1), which may solve that issue.</t>

				<t>However, target="RFC8305"
				sectionFormat="of" section="7.1"/>).</t>
          <t>Moreover, this scenario still also fails to solve the problem
				of IPv4-only hosts or applications behind the IPv6-only
				access network.</t>
          <figure align="center" anchor="sp-nat64-h-dns64"
                title="NAT64; anchor="sp-nat64-h-dns64">
            <name>NAT64; DNS64 in IPv6 hosts"> Hosts</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+----------+        +----------+        +----------+
|   IPv6   |        |          |        |          |
|     +    +--------+  NAT64   +--------+   IPv4   |
|   DNS64  |        |          |        |          |
+----------+        +----------+        +----------+
            ]]></artwork>        +----------+]]></artwork>

          </figure>
        </section>
        <section title="Service Provider anchor="sprdns64" numbered="true" toc="default">
          <name>Service-Provider NAT64; DNS64 in the IPv4-only
			remote network" anchor="sprdns64"> IPv4-Only     Remote Network</name>
          <t>In this scenario (<xref target="sp-nat64-r-dns64"/>), target="sp-nat64-r-dns64" format="default"/>), the service provider offers the
				NAT64 function only. The remote IPv4-only remote network offers the
				DNS64 function.</t>
          <t>This is not common, and looks like it doesn't make too much sense
				that a remote network, not deploying IPv6, is providing a DNS64
				function. As in the case of Like the scenario depicted in
				<xref target="onlynat64"/>, target="onlynat64" format="default"/>, it will only work if both sides are
				using the WKP or the same NSP, so the same considerations apply.
				It can be also be tuned to behave as in <xref target="spnatdns64"/></t> target="spnatdns64" format="default"/>.</t>
          <t>This scenario still fails to solve the issue of
				IPv4 literal addresses or non-IPv6 compliant non-IPv6-compliant APIs.</t>

				<t>This
          <t>Moreover, this scenario also fails to solve the problem
				of IPv4-only hosts or applications behind the IPv6-only
				access network.</t>

          <figure align="center" anchor="sp-nat64-r-dns64"
                title="NAT64; anchor="sp-nat64-r-dns64">
            <name>NAT64; DNS64 in the IPv4-only"> IPv4-Only Hosts</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+----------+        +----------+        +----------+
|          |        |          |        |   IPv4   |
|   IPv6   +--------+  NAT64   +--------+     +    |
|          |        |          |        |   DNS64  |
+----------+        +----------+        +----------+
            ]]></artwork>        +----------+]]></artwork>

          </figure>
        </section>
      </section>
      <section title="Comparing numbered="true" toc="default">
        <name>Comparing the Scenarios"> Scenarios</name>
        <t>This section compares the different scenarios, including the
			possible variations (each one represented in the precedent previous sections
			by a different figure), looking at while considering the following criteria:</t>

            <t><list style="letters">
				<t>DNSSEC:
        <ol spacing="normal" type="a">
          <li>DNSSEC: Are there hosts validating DNSSEC?</t>
				<t>Literal/APIs: DNSSEC?</li>
          <li>Literal/APIs: Are there applications using IPv4 literals or non-IPv6
				compliant APIs?</t>
				<t>IPv4-only:
                                non-IPv6-compliant APIs?</li>
          <li>IPv4 only: Are there hosts or applications using IPv4-only?</t>
				<t>Foreign IPv4 only?</li>
          <li>Foreign DNS: Is Does the scenario surviving survive if the user, Operating System,
				applications
				applications, or devices change the DNS?</t>
				<t>DNS DNS?</li>
          <li>DNS load opt. (DNS opt.&nbsp;(DNS load optimization): Are there extra queries that
    may impact the DNS infrastructure?</t>
				<t>Connect. opt. (Connection infrastructure?</li>
          <li>Connect. opt.&nbsp;(connection establishment delay optimization):
    Is the UE/CE issuing only issuing the AAAA query or also an the A query and
    waiting for both responses?</t>
			</list></t> responses?</li>
        </ol>
        <t>In the next table, table below, the columns represent each of the scenarios from the
			previous sections, sections by the figure number. The
			possible values are:</t>
            <t><list style="symbols">
				<t>"-" Scenario are as follows:</t>
<ul empty="true"><li>
        <dl spacing="normal" indent="6">
          <dt>"-"</dt><dd>means the scenario is "bad" for that criteria.</t>
				<t>"+" Scenario criterion.</dd>
          <dt>"+"</dt><dd>means the scenario is "good" for that criteria.</t>
				<t>"*" Scenario criterion.</dd>
          <dt>"*"</dt><dd>means the scenario is "bad" for that criteria, however criterion; however, it is typically
				resolved,
				resolved with the support of Happy Eyeballs v2 (<xref target="RFC8305"/>).</t>
			</list></t> <xref target="RFC8305" format="default"/>.</dd>
        </dl></li></ul>
        <t>In some cases, "countermeasures", alternative or
			special configurations, may be available for the criteria criterion designated
			as "bad". So, this comparison is considering a generic
			case,
			case as a quick comparison guide. In some cases, a "bad" criterion is
			not necessarily a negative aspect, all aspect; it all depends on the specific
			needs/characteristics of the network where the deployment will
			take place.

                        For instance, in a network which has that only has IPv6-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 DNSSEC,
	that item criterion is still relevant.</t>

        <figure align="center" anchor="comparing"
                title="Scenario Comparison">
          <artwork align="center"><![CDATA[
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Item / Figure  | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| DNSSEC         | - | - | - | - | - | - | - | + | + |  + |  + |  + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Literal/APIs   | - | - | - | - | + | + | + | + | + |  - |  - |  - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| IPv4-only      | - | - | - | - | + | + | + | + | + |  - |  - |  - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Foreign DNS    | - | - | - | - | + | + | + | + | + |  - |  + |  - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| DNS

<table anchor="comparing">
	<name>Scenario Comparison</name>
	<thead>
	<tr>
		<th>Item / Figure</th>
		<th>1</th>
		<th>2</th>
		<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.  | + | + | + | + | + | + | + | + | + |  + |  + |  + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Connect. opt.  | + | + | + | + | + | + | + | * | * |  + |  + |  + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
            ]]></artwork>
        </figure> 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>As a general conclusion, we should note that, if the network
			must support applications using any of the following:</t>
            <t><list style="symbols">
				<t>IPv4 literals</t>
				<t>non-IPv6-compliant APIs</t>
				<t>IPv4-only
        <ul spacing="normal">
          <li>IPv4 literals</li>
          <li>non-IPv6-compliant APIs</li>
          <li>IPv4-only hosts or applications</t>
			</list></t> applications</li>
        </ul>
        <t>Then, only the scenarios with 464XLAT, a CLAT function,
			or equivalent built-in local address synthesis features, features
			will provide a valid solution. Further to that, Furthermore, those scenarios will also
			keep working if the DNS configuration is modified. Clearly also, Clearly,
			depending on if DNS64 is used or not, DNSSEC may be broken for
			those hosts doing DNSSEC validation.</t>
        <t>All the scenarios are good in terms of DNS load optimization,
			and in the case of 464XLAT 464XLAT, it may provide an extra degree
			of optimization. Finally, all them of the scenarios are also good in terms of
			connection establishment delay optimization.
			However, in the case of 464XLAT without DNS64, it requires the
			usage of Happy Eyeballs v2. v2 is required. This is not an issue, issue as commonly it is commonly available
			in actual Operating Systems.</t>
      </section>
    </section>
    <section title="Issues numbered="true" toc="default">
      <name>Issues to be Considered"> Considered</name>
      <t>This section reviews the different issues that an operator needs
			to consider towards for a NAT64/464XLAT deployment, as they may bring
			to develop
			specific decision points about how to approach that deployment.</t>
      <section title="DNSSEC numbered="true" toc="default">
        <name>DNSSEC Considerations and Possible Approaches"> Approaches</name>
        <t>As indicated in Section 8 of the security considerations for DNS64 (see
	<xref target="RFC6147"/> (DNS64, Security
			Considerations), target="RFC6147" sectionFormat="of" section="8"/>)
                        because DNS64 modifies DNS answers and DNSSEC is designed
			to detect such modifications, DNS64 may break DNSSEC.</t>

			<t>If

        <t>When a device connected to an IPv6-only access network, network queries
			for a domain name in a signed zone, by means of a recursive name server
			that supports DNS64, and the result is may be a synthesized AAAA record, and record. In that case,
			if the recursive name server is configured to perform DNSSEC validation and has
			a valid chain of trust to the zone in question, it will
			cryptographically validate the negative response from the authoritative
			name server. This is the expected DNS64 behavior: The the recursive name
			server actually "lies" to the client device. However, in most of the cases,
			the client will not notice it, because generally, they don't perform
			validation themselves and themselves; instead, they rely on the recursive name servers.</t>

			<t>A
        <t>In fact, a validating DNS64 resolver in fact, increase increases the confidence on
			the synthetic AAAA, as it has validated that a non-synthetic AAAA
			for sure,
			doesn't exists. exist. However, if the client device is NAT64-oblivious
			(most oblivious to NAT64
			(the most common case) and performs DNSSEC validation on the AAAA record,
			it will fail as it is a synthesized record.</t>
        <t>The best possible scenario from a DNSSEC point of view, view is when the
			client requests that the DNS64 server to perform the DNSSEC validation
			(by setting the DO DNSSEC OK (DO) bit to 1 and the CD bit to 0). In this case,
			the DNS64 server validates the data, thus data; thus, tampering may only happen
			inside the DNS64 server (which is considered as a trusted part,
			thus
			thus, its likelihood is low) or between the DNS64 server and the
			client. All other parts of the system (including transmission
			and caching) are protected by DNSSEC (<xref target="Threat-DNS64"/>).</t> <xref target="Threat-DNS64" format="default"/>.</t>
        <t>Similarly, if the client querying the recursive name server is another
			name server configured to use it as a forwarder, and it is performing DNSSEC
			validation, it will also fail on any synthesized AAAA record.</t>
        <t>All those considerations are extensively covered in
	Sections 3, 5.5
	<xref target="RFC6147" sectionFormat="bare" section="3"/>,
	<xref target="RFC6147" sectionFormat="bare" section="5.5"/>,
	and 6.2
	<xref target="RFC6147" sectionFormat="bare" section="6.2"/> of
	<xref target="RFC6147"/>.</t>

			<t>A solution to avoid DNSSEC issues, will

        <t>DNSSEC issues could be that avoided if all the signed zones also provide IPv6 connectivity, connectivity together with the
			corresponding AAAA records. However, this is out of the control
			of the operator needing to deploy a NAT64 function. This has been
			proposed already in <xref target="I-D.bp-v6ops-ipv6-ready-dns-dnssec"/>.</t> target="I-D.bp-v6ops-ipv6-ready-dns-dnssec" format="default"/>.</t>
      <t>An alternative solution, which was the one considered
			while developing <xref target="RFC6147"/>, target="RFC6147" format="default"/>, is that the validators
			will be DNS64-aware, so could DNS64 aware.  Then, they can perform the necessary discovery
			and do their own synthesis. That was done under the expectation Since that it was standardized sufficiently early in the validator-deployment
			curve validator deployment
			curve, the expectation was that it would be ok okay to break certain DNSSEC assumptions
			for networks who that were really stuck in a NAT64/DNS64-needing world.</t> and really needing NAT64/DNS64.</t>

        <t>As already indicated, the scenarios in the previous section, section
			are in fact somehow simplified, looking simplified to look at the worst possible case.
			Saying it in a different way: "trying to look case and for the most perfect
			approach". approach.
		        A DNSSEC breach will not happen if the end-host end host
			is not doing validation.</t>

			<t>Existing
        <t>The figures in previous studies seems to indicate that the figures of DNSSEC
			actually
			broken by using DNS64 will be around makes up about 1.7%
			(<xref target="About-DNS64"/>)
			<xref target="About-DNS64" format="default"/> of the cases. However, we can't negate
			that this may increase, increase as DNSSEC deployment grows.

			Consequently, a decision point for the operator must depend on
			"do
			the following question: Do I really care for about that percentage of cases and the impact in on
			my helpdesk help desk, or can I provide alternative solutions for them?". them?
			Some possible solutions may be taken, exist, as depicted in the next sections.</t>
        <section title="Not using DNS64" anchor="nodns64">
			<t>A anchor="nodns64" numbered="true" toc="default">
          <name>Not Using DNS64</name>
          <t>One solution will be is to avoid using DNS64, but as already
			indicated
			indicated, this is not possible in all the scenarios.</t>
          <t>The use of DNS64 is a key component for some networks, in order
			to comply with traffic performance metrics, monitored by some
			governmental bodies and other institutions (<xref target="FCC"/>, <xref target="ARCEP"/>).</t> target="FCC" format="default"/> <xref target="ARCEP" format="default"/>.</t>
          <t>One drawback of not having a DNS64 at on the network side, side
			is that is it's not possible to heuristically discover
			the
			NAT64 (<xref target="RFC7050"/>). <xref target="RFC7050" format="default"/>.
			Consequently, an IPv6 host behind the IPv6-only access network, network will not
			be able to detect the presence of the NAT64 function, neither to nor learn the
			IPv6 prefix to be used for it, unless it is configured by alternative
			means.</t>
          <t>The discovery of the IPv6 prefix could be solved,
			as described in <xref target="RFC7050"/>, target="RFC7050" format="default"/>, by means
			of adding the relevant AAAA records to the ipv4only.arpa. zone, zone
			of the service provider service-provider recursive servers, i.e., if
			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.  NS      .
ipv4only.arpa.  AAAA    64:ff9b::192.0.0.170
ipv4only.arpa.  AAAA    64:ff9b::192.0.0.171
ipv4only.arpa.  A       192.0.0.170
ipv4only.arpa.  A       192.0.0.171
]]></artwork></figure>

]]></artwork>
          <t>An alternative option to the above, is the use of DNS RPZ
			(<xref target="I-D.vixie-dns-rpz"/>)
			<xref target="I-D.vixie-dnsop-dns-rpz" format="default"/> or equivalent functionalities. Note
			that this may impact DNSSEC if the zone is signed.</t>

			<t>One more
          <t>Another alternative, only valid in environments with PCP support from the Port Control Protocol (PCP) (for
			both the hosts or CEs and for the service provider service-provider network), is to follow
			<xref target="RFC7225"/> (Discovering
			"Discovering NAT64 IPv6 Prefixes using PCP).</t> Using the Port Control Protocol (PCP)" <xref target="RFC7225" format="default"/>.</t>

          <t>Other alternatives may be available in the future. All them are
			extensively discussed in <xref target="RFC7051"/>,
			however target="RFC7051" format="default"/>;
			however, due to the deployment evolution has evolved evolution, many considerations
			from that document. document have changed. New options are being documented, such as using Router
			Advertising (<xref target="I-D.ietf-6man-ra-pref64"/>) <xref target="I-D.ietf-6man-ra-pref64" format="default"/> or DHCPv6 options
			(<xref target="I-D.li-intarea-nat64-prefix-dhcp-option"/>).</t>

			<t>It may be convenient the simultaneous
			<xref target="I-D.li-intarea-nat64-prefix-dhcp-option" format="default"/>.</t>

          <t>Simultaneous support of several of the
			possible approaches, in order to approaches is convenient and will ensure that clients with different
			ways to configure the NAT64 prefix, prefix successfully obtain it.
			This is also convenient even if DNS64 is being used.</t>

			<t>Of
          <t>Also of special relevance to this section is also <xref target="I-D.cheshire-sudn-ipv4only-dot-arpa"/>.</t> target="I-D.cheshire-sudn-ipv4only-dot-arpa" format="default"/>.</t>
        </section>
        <section title="DNSSEC validator aware anchor="dns64-aware" numbered="true" toc="default">
          <name>DNSSEC Validator Aware of DNS64" anchor="dns64-aware"> DNS64</name>
          <t>In general, by default, DNS servers with DNS64 function will not
			synthesize AAAA responses if the DNSSEC OK (DO) DO flag was set in the query.</t>
          <t>In this case, as since only an A record is available, if a CLAT function
			is present, it means that the CLAT will take the responsibility, will,
			as in the case of literal IPv4 addresses, to keep that traffic
			flow end-to-end end to end as IPv4, IPv4 so DNSSEC is not broken.</t>
          <t>However, this will not work if a CLAT function is not present
			as
			because the hosts will not be able to use IPv4 (which is the case for all the
			scenarios without 464XLAT).</t>
        </section>
        <section title="Stub validator" anchor="stub"> anchor="stub" numbered="true" toc="default">
          <name>Stub Validator</name>
          <t>If the DO flag is set and the client device performs DNSSEC validation,
			and the Checking Disabled (CD) flag is set for a query, the DNS64
			recursive server will not synthesize AAAA responses.
                        In this case,
			the client could perform the DNSSEC validation with the A record
			and then synthesize the AAAA (<xref target="RFC6052"/>). responses <xref target="RFC6052" format="default"/>.
			For that to be possible, the client must have learned beforehand
			the NAT64 prefix beforehand using any of the available methods
			(<xref target="RFC7050"/>,
			(see <xref target="RFC7050" format="default"/>, <xref target="RFC7225"/>, target="RFC7225" format="default"/>,
			<xref target="I-D.ietf-6man-ra-pref64"/>, target="I-D.ietf-6man-ra-pref64" format="default"/>, and <xref target="I-D.li-intarea-nat64-prefix-dhcp-option"/>). target="I-D.li-intarea-nat64-prefix-dhcp-option" format="default"/>).
			This allows the client device to avoid using the DNS64 function and still
			use NAT64 even with DNSSEC.</t>
          <t>If the end-host end host is IPv4-only, IPv4 only, this will not work if a CLAT function is
			not present (scenarios (which is the case for all scenarios without 464XLAT).</t>

			<t>Some
          <t>Instead of a CLAT, some devices or Operating Systems may implement, instead of a CLAT, implement
			an equivalent function by using Bump-in-the-Host (<xref target="RFC6535"/>),
			implemented <xref target="RFC6535" format="default"/>
                        as part of Happy Eyeballs v2 (Section 7.1 of (see
			<xref target="RFC8305"/>). target="RFC8305" sectionFormat="of" section="7.1"/>).
			In this case, the considerations in the above paragraphs are
			also applicable.</t>
        </section>
        <section title="CLAT anchor="dns-proxy" numbered="true" toc="default">
          <name>CLAT with DNS proxy Proxy and validator" anchor="dns-proxy"> Validator</name>
          <t>If a CE includes CLAT support and also a DNS proxy, as indicated in
			Section 6.4 of
			<xref target="RFC6877"/>, target="RFC6877"
			sectionFormat="of" section="6.4"/>, the CE could behave as a stub
			validator on behalf of the client devices. Then, following the same approach
			described in the <xref target="stub"/>, target="stub" format="default"/>, the DNS proxy
			actually
		        will actually "lie" to the client devices, which which, in most of the cases cases, will
			not notice it, be noticed unless they perform validation by themselves. Again, this
			allow
			allows the client devices to avoid using the use of
			the DNS64 function and but to still use NAT64
			with DNSSEC.</t>
          <t>Once more, this will not work without a CLAT function (scenarios (which is the case for all scenarios without 464XLAT).</t>
        </section>
        <section title="ACL anchor="acl-client" numbered="true" toc="default">
          <name>ACL of clients" anchor="acl-client"> Clients</name>
          <t>In cases of dual-stack clients, the AAAA queries typically take
			preference over A queries. If DNS64 is enabled for those clients,
			it will never get A records, even for IPv4-only servers.</t>
          <t>As a consequence, in cases where there are IPv4-only servers,
			and those are located in the path before the NAT64 function,
			the clients will not be able to reach them. If DNSSEC is being
			used for all those flows, specific addresses or prefixes can be
			left-out
			left out of the DNS64 synthesis by means of ACLs.</t> Access Control Lists (ACLs).</t>
          <t>Once more, this will not work without a CLAT function (scenarios (which is the case for all scenarios without 464XLAT).</t>
        </section>
        <section title="Mapping-out anchor="mapping-out" numbered="true" toc="default">
          <name>Mapping Out IPv4 addresses" anchor="mapping-out"> Addresses</name>
          <t>If there are well-known specific IPv4 addresses or prefixes
			using DNSSEC, they can be mapped-out mapped out of the DNS64 synthesis.</t>
          <t>Even if this is not related to DNSSEC, this "mapping-out" feature
			is actually, quite commonly used to ensure that <xref target="RFC1918"/>
			addresses <xref target="RFC1918" format="default"/> (for example example, used by LAN servers) are not synthesized to
			AAAA.</t>
          <t>Once more, this will not work without a CLAT function (scenarios (which is the case for all scenarios without 464XLAT).</t>
        </section>
      </section>
      <section title="DNS64 numbered="true" toc="default">
        <name>DNS64 and Reverse Mapping"> Mapping</name>
        <t>When a client device, device using DNS64 tries to reverse-map a
			synthesized IPv6 address, the name server responds with a CNAME record
			pointing
			that points the domain name used to reverse-map the
			synthesized IPv6 address (the one under ip6.arpa), ip6.arpa) to the domain name
			corresponding to the embedded IPv4 address (under in-addr.arpa).</t>
        <t>This is the expected behavior, so no issues need to be considered
			regarding DNS reverse mapping.</t>
      </section>
      <section title="Using anchor="xlatwwdns64" numbered="true" toc="default">
        <name>Using 464XLAT with/without DNS64" anchor="xlatwwdns64"> DNS64</name>
        <t>In the case the client device is IPv6-only IPv6 only (either because the stack or
			application is IPv6-only, IPv6 only or because it is connected via an IPv6-only LAN)
			and the remote server is IPv4-only IPv4 only (either because the stack is IPv4-only, IPv4 only
			or because it is connected via an IPv4-only LAN), only NAT64 combined
			with DNS64 will be able to provide access among between both. Because DNS64 is
			then required, DNSSEC validation will be only be possible if the recursive
			name server is validating the negative response from the authoritative
			name server server, and the client is not performing validation.</t>
        <t>Note that is not expected at this stage of the transition, it is not expected
			that applications, devices devices, or Operating Systems are IPv6-only. IPv6 only. It will
			not be a sensible decision for a developer to work on that direction,
			unless it is clear that the deployment scenario fully supports it.</t>
        <t>On the other hand, an end-user end user or enterprise network may decide to
			run IPv6-only IPv6 only in the LANs. In case there is any chance for
			applications to be IPv6-only, IPv6 only, the Operating System may be
			responsible either for either doing a local address synthesis, synthesis or
			alternatively,
			setting up some kind of on-demand VPN (IPv4-in-IPv6),
			which need needs to be supported by that network. This may become
			very common in enterprise networks, where "Unique IPv6 Prefix
			per Host" <xref target="RFC8273"/> target="RFC8273" format="default"/> is supported.</t>
        <t>However, when the client device is dual-stack dual stack and/or connected in a
			dual-stack LAN by means of a CLAT function (or has a built-in
			CLAT function), DNS64 is an option.</t>

            <t><list style="numbers">

				<t>With
        <ol spacing="normal" type="1">
          <li>With DNS64: If DNS64 is used, most of the IPv4 traffic
				(except if using literal IPv4 addresses or non-IPv6 compliant non-IPv6-compliant APIs)
				will not use the CLAT, so CLAT and will instead use the IPv6 path and path, so only one
				translation will be done at the NAT64. This may break DNSSEC,
				unless measures as described in the precedent previous sections are taken.</t>

				<t>Without taken.</li>
          <li>Without DNS64: If DNS64 is not used, all the IPv4 traffic
				will make use of the CLAT, so two translations are required (NAT46
				at the CLAT and NAT64 at the PLAT), which adds some overhead in
				terms of the extra NAT46 translation. However, this avoids the AAAA
				synthesis and consequently will never break DNSSEC.</t>

			</list></t> DNSSEC.</li>
        </ol>
        <t>Note that the extra translation, when DNS64 is not used, takes place
			at the CLAT, which means no extra overhead for the operator.
			It however
			However, it adds potential extra delays to establish the connections, connections and has no
			perceptible impact for a CE in a broadband network, while but it may have
			some impact in on a battery powered battery-powered device. This The cost for a battery powered
			device, battery-powered
			device is possibly comparable to the cost when the device is doing a
			local address synthesis (see Section 7.1 of
	<xref target="RFC8305"/>).</t> target="RFC8305" sectionFormat="of" section="7.1"/>).</t>
      </section>
      <section title="Foreign DNS" anchor="foreignDNS"> anchor="foreignDNS" numbered="true" toc="default">
        <name>Foreign DNS</name>
        <t>Clients, devices devices, or applications in a service provider network, service-provider network
			may use DNS servers from other networks. This may be the case either
			if individual applications use their own DNS server, the
			Operating System itself or even the CE, or combinations of the above.</t>
        <t>Those "foreign" DNS servers may not support DNS64, which DNS64; as a consequence,
			will mean that
			those scenarios that require a DNS64 may not work.
			However, if a CLAT function is available, the considerations in
			<xref target="xlatwwdns64"/> target="xlatwwdns64" format="default"/> will apply.</t>

			<t>In the case that

         <t>If the foreign DNS supports the DNS64 function,
			we incorrect configuration parameters may be in the situation of providing incorrect configurations parameters, provided that,
                           for example, un-matching cause WKP or NSP, NSP to become unmatched or result in a case such as the one described in <xref target="sprdns64"/>.</t> target="sprdns64" format="default"/>.</t>
        <t>Having a CLAT function, even if using foreign DNS
			without a DNS64 function, ensures that everything will work,
			so the CLAT must be considered as to be an advantage even against despite
			user configuration errors. The cost of this, is that
                        As a result, all the
			traffic will use a double translation (NAT46 at the CLAT
			and NAT64 at the operator network), unless there is
			support for EAM (<xref target="EAM"/>).</t> target="EAM" format="default"/>).</t>
        <t>An exception to that is the case when where there is a CLAT function
			at the CE, which CE that is not able to obtain the correct configuration
			parameters (again, un-matching causing WKP or NSP).</t> NSP to become unmatched).</t>
        <t>However, it needs to be emphasized, emphasized that if there is not a no CLAT function
			(scenarios
			(which is the case for all scenarios without 464XLAT), an external DNS without DNS64 support, support
			will disallow any access to IPv4-only destination networks, networks and will
			not guarantee the correct DNSSEC validation,
			so it will behave as in the <xref target="onlynat64"/>.</t> target="onlynat64" format="default"/>.</t>
        <t>In summary, it can be said, that the consequences of the use of using
			foreign DNS depend very much in depends on each specific case. However, in general,
			if a CLAT function is present, most of the time, time there will not be any. any issues.
			In the other cases, generally, the access to IPv6-enabled services
			is still guaranteed for IPv6-enabled hosts, but it is not guaranteed for IPv4-only hosts,
			neither hosts
			nor is the access to IPv4-only services for any hosts in the network.</t>
        <t>The causes of "foreign DNS" could be classified in three main categories,
			as depicted in the following sub-sections.</t> subsections.</t>
        <section title="Manual numbered="true" toc="default">
          <name>Manual Configuration of DNS"> DNS</name>
          <t>It is becoming increasingly common that end-users end users, or even devices
			or applications applications, configure alternative DNS in their Operating Systems, Systems
			and sometimes in CEs.</t>
        </section>
        <section title="DNS anchor="dnspriv" numbered="true" toc="default">
          <name>DNS Privacy/Encryption Mechanisms" anchor="dnspriv"> Mechanisms</name>

          <t>Clients or applications may use mechanisms for
			DNS privacy/encryption, such as DNS over TLS
			(<xref target="RFC7858"/>), (DoT)
			<xref target="RFC7858" format="default"/>, DNS over DTLS (<xref target="RFC8094"/>), <xref target="RFC8094" format="default"/>,
			DNS queries over HTTPS (<xref target="RFC8484"/>) (DoH) <xref target="RFC8484" format="default"/>, or
			DNS over QUIC (<xref target="I-D.huitema-quic-dnsoquic"/>).
			Those are commonly cited as DoT, DoH and DoQ.</t>

			<t>Those (DoQ) <xref target="I-D.huitema-quic-dnsoquic" format="default"/>.
		</t>
          <t>Currently, those DNS privacy/encryption options, currently options are typically
			provided by the applications, not the Operating System vendors.
			At the time of writing this document, at least document was written, the DoT and DoH standards
			have declared DNS64 (and consequently NAT64) out of their scope, so
			an application using them may break NAT64, unless a correctly configured
			CLAT function is used.</t>
        </section>
        <section title="Split anchor="SplitDNS" numbered="true" toc="default">
          <name>Split DNS and VPNs" anchor="SplitDNS"> VPNs</name>
          <t>When networks or hosts use "split-DNS" (also called Split Horizon,
			DNS views views, or private DNS), the successful use of the DNS64 is not guaranteed.
			Section 4 of
			This case is analyzed in <xref target="RFC6950"/>, analyses this case.</t>
			target="RFC6950" sectionFormat="of" section="4"/>.</t>
          <t>A similar situation may happen in case of with VPNs that force all
			the DNS queries through the VPN, ignoring VPN and ignore the operator DNS64 function.</t>
        </section>
      </section>
      <section title="Well-Known anchor="WKP-NSP" numbered="true" toc="default">
        <name>Well-Known Prefix (WKP) vs vs. Network-Specific Prefix (NSP)" anchor="WKP-NSP"> (NSP)</name>
        <t>Section 3 of <xref target="RFC6052"/> (IPv6 "IPv6 Addressing of IPv4/IPv6 Translators), Translator" <xref target="RFC6052" format="default"/>
			discusses some considerations which that are useful to decide if an operator should use the when deciding if
			a WKP or an NSP.</t>

			<t>Taking in consideration NSP should be used.</t>
        <t>Considering that discussion and other issues, we can
			summarize the possible decision points as:</t>
			<t><list style="letters">

			<t>The to as follows:</t>
        <ol spacing="normal" type="a">
          <li>The WKP MUST NOT <bcp14>MUST NOT</bcp14> be used to represent non-global IPv4 addresses.
			If this is required because the network to be translated use uses
			non-global addresses, then an NSP is required.</t>

			<t>The required.</li>
          <li>The WKP MAY <bcp14>MAY</bcp14> appear in inter-domain interdomain routing tables, if the operator
			provides a NAT64 function to peers. However, in this case, special
			considerations related to BGP filtering are required required, and IPv4-embedded
			IPv6 prefixes longer than the WKP MUST NOT <bcp14>MUST NOT</bcp14> be advertised (or accepted)
			in BGP. An NSP may be a more appropriate option in those cases.</t>

			<t>If cases.</li>
          <li>If several NAT64 NAT64s use the same prefix, packets from the same
			flow may be routed to a different NAT64 in case of routing changes.
			This can be avoided either by either using different prefixes for each NAT64
			function,
			function or by ensuring that all the NAT64 NAT64s coordinate their state.
			Using an NSP could simplify that.</t>

			<t>If that.</li>
          <li>If DNS64 is required and users, devices, Operating Systems Systems, or
			applications may change their DNS configuration, configuration and deliberately
			choose an alternative DNS64 function, most probably the alternative
			DNS64 will most likely use by default the WKP. WKP by default. In that case, if an NSP is used by
			the NAT64 function, clients will not be able to use the operator
			NAT64 function, which will break connectivity to
			IPv4-only destinations.</t>

			</list></t> destinations.</li>
        </ol>
      </section>
      <section title="IPv4 literals anchor="literals" numbered="true" toc="default">
        <name>IPv4 Literals and non-IPv6 Compliant APIs" anchor="literals"> Non-IPv6-Compliant APIs</name>
        <t>A host or application using literal IPv4 addresses or older APIs,
			which aren't IPv6 compliant, behind a network with IPv6-only access, access
			will not work unless any of the following alternatives is are provided:</t>

            <t><list style="symbols">
				<t>CLAT
        <ul spacing="normal">
          <li>CLAT (or an equivalent function).</t>
				<t>Happy function).</li>
          <li>Happy Eyeballs v2 (Section 7.1, 7.1 of <xref target="RFC8305"/>).</t>
				<t>Bump-in-the-Host (<xref target="RFC6535"/>) target="RFC8305" format="default"/>).</li>
          <li>Bump-in-the-Host <xref target="RFC6535" format="default"/> with a DNS64 function.</t>
			</list></t> function.</li>
        </ul>
        <t>Those alternatives will solve the problem for an end-host. end host.
			However, if that end-hosts the end host is providing "tethering" or an equivalent
			service to other hosts, that needs to be considered as well.
                        In other
			words, in a case of a cellular network, it resolves these alternatives resolve the issue for
			the UE itself, but this may be not be the case for hosts behind it.</t> connected via the tethering.</t>
        <t>Otherwise, the support of 464XLAT is the only valid and complete
			approach to resolve this issue.</t>
      </section>
      <section title="IPv4-only anchor="ipv4-only" numbered="true" toc="default">
        <name>IPv4-Only Hosts or Applications" anchor="ipv4-only">
			<t>An IPv4-only Applications</name>
        <t>IPv4-only hosts or an application behind a network with IPv6-only access, access
			will not work unless a CLAT function is present.</t>
        <t>464XLAT is the only valid approach to resolve this issue.</t>
      </section>
      <section title="CLAT anchor="CLAT" numbered="true" toc="default">
        <name>CLAT Translation Considerations" anchor="CLAT"> Considerations</name>
        <t>As described in Section 6.3 of <xref target="RFC6877"/> (IPv6 "IPv6 Prefix
			Handling),
			Handling" (see <xref
			target="RFC6877" sectionFormat="of" section="6.3"/>), if the CLAT function
                        can be configured with a dedicated /64 prefix
			for the NAT46 translation, then it will be possible to do a more
			efficient stateless translation.</t>

        <t>Otherwise, if this dedicated prefix is not available, the CLAT function will
			need to do a stateful translation, for example performing example, perform stateful NAT44
			for all the IPv4 LAN packets, packets so they appear as coming from a single
			IPv4 address, and then address; in turn, the CLAT function will perform a stateless translated translation to a single IPv6
			address.</t>
        <t>A possible setup, in order to maximize the CLAT
			performance, is to configure the dedicated translation prefix. This
			can be easily achieved automatically, if the broadband CE or
			end-user device is able to obtain a shorter prefix by means
			of DHCPv6-PD (<xref target="RFC8415"/>), <xref target="RFC8415" format="default"/> or other alternatives.
			The CE can then use a specific /64 for the translation. This is also
			possible when broadband is provided by a cellular access.</t>
        <t>The above recommendation is often not possible for cellular networks,
			when connecting smartphones (as UEs), as UEs): generally they don't use DHCPv6-PD
			(<xref target="RFC8415"/>).
			<xref target="RFC8415" format="default"/>. Instead, a single /64 is provided for
			each PDP context Packet Data Protocol (PDP) context, and prefix sharing (<xref target="RFC6877"/>) <xref target="RFC6877" format="default"/> is used.
			So, in
			In this case, the UEs typically have a build-in CLAT function
			which that
			is performing a stateful NAT44 translation before the stateless NAT46.</t>
      </section>
      <section title="EAM Considerations" anchor="EAM">
			<t>Explicit anchor="EAM" numbered="true" toc="default">
        <name>EAM Considerations</name>
        <t>"Explicit Address Mappings for Stateless IP/ICMP Translation
			(<xref target="RFC7757"/>) provide Translation"
			<xref target="RFC7757" format="default"/> provides a way to configure explicit
			mappings between IPv4 and IPv6 prefixes of any length.
			When this is used, for example example, in a CLAT function, it may provide a
			simple mechanism in order to avoid traffic flows between
			IPv4-only nodes or applications and dual-stack destinations
			to be translated twice (NAT46 and NAT64), by creating mapping
			entries with the GUA Global Unicast Address (GUA) of the IPv6-reachable destination.
			This optimization of the NAT64 usage is very useful in
			many scenarios, including CDNs Content Delivery Networks (CDNs) and caches, as described in
			<xref target="I-D.palet-v6ops-464xlat-opt-cdn-caches"/>.</t> target="I-D.palet-v6ops-464xlat-opt-cdn-caches" format="default"/>.</t>
        <t>In addition to that, addition, it may also provide as well a way for IPv4-only
			nodes or applications to communicate with IPv6-only destinations.</t>
      </section>
      <section title="Incoming Connections" anchor="incoming"> anchor="incoming" numbered="true" toc="default">
        <name>Incoming Connections</name>
        <t>The use of NAT64, in principle, disallows IPv4 incoming connections,
			which may be still be needed for IPv4-only peer-to-peer applications.
			However, there are several alternatives that resolve this issue:</t>

			<t><list style="letters">

			<t>STUN (<xref target="RFC5389"/>), TURN (<xref target="RFC5766"/>)
        <ol spacing="normal" type="a">

          <li>Session Traversal Utilities for NAT (STUN) <xref target="RFC5389" format="default"/>, Traversal Using Relays around NAT (TURN) <xref target="RFC5766" format="default"/>, and
			ICE (<xref target="RFC8445"/>)
			Interactive Connectivity Establishment (ICE) <xref target="RFC8445" format="default"/> are commonly used by peer-to-peer
			applications in order to allow incoming connections with IPv4 NAT. In the case of NAT64, they
                        work as well. RFC editor note: If in time,
			replace STUN and TURN with <xref target="I-D.ietf-tram-stunbis"/> /

          </li>
          <li>The Port Control Protocol (PCP) <xref target="I-D.ietf-tram-turnbis"/>.</t>

			<t>PCP (<xref target="RFC6887"/>) target="RFC6887" format="default"/> allows a host to control how incoming
			IPv4 and IPv6 packets are translated and forwarded. A NAT64 may implement
			PCP to allow this service.</t>

			<t>EAM (<xref target="RFC7757"/>) service.</li>
          <li>EAM <xref target="RFC7757" format="default"/> may also be used in order to configure
			explicit mappings for customers that require them. This is used used, for example example,
			by SIIT-DC (<xref target="RFC7755"/>) Stateless IP/ICMP Translation for IPv6 Data Center Environments (SIIT-DC) <xref target="RFC7755" format="default"/> and SIIT-DC-DTM (<xref target="RFC7756"/>).</t>

			</list></t> SIIT-DC Dual Translation Mode (SIIT-DC-DTM) <xref target="RFC7756" format="default"/>.</li>
        </ol>
      </section>
    </section>
    <section title="Summary numbered="true" toc="default">
      <name>Summary of Deployment Recommendations for NAT64/464XLAT">
			<t>NAT64/464XLAT NAT64/464XLAT</name>
      <t>It has been demonstrated to be that NAT64/464XLAT is a valid choice in several
			scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the predominant mechanism
			in the majority of the cellular networks, which account for hundreds
			of millions of users (<xref target="ISOC"/>). <xref target="ISOC" format="default"/>.
			NAT64/464XLAT offer different choices of deployment,
			depending on each network case, needs needs, and requirements. Despite that,
			this document is not an explicit recommendation for using this choice
			versus other IPv4aaS transition mechanisms. Instead, this document
			is a guide that facilitates evaluating a possible implementation
			of NAT64/464XLAT and key decision points about specific design
			considerations for its deployment.</t>
      <t>Depending on the specific requirements of each deployment case,
			DNS64 may be a required function, while in other cases cases, the
			adverse effects may be counterproductive.
			Similarly, in some cases cases, a NAT64 function, together with a DNS64 function,
			may be a valid solution, solution when there is a certainty that IPv4-only hosts
			or applications do not need to be supported (<xref target="literals"/>
			(see Sections <xref target="literals"
			format="counter"/> and
        <xref target="ipv4-only"/>). target="ipv4-only" format="counter"/>). However, in other cases (i.e. (i.e., IPv4-only devices
			or applications that need to be supported), the limitations of NAT64/DNS64, NAT64/DNS64
			may suggest indicate that the operator needs to look into 464XLAT as a more complete solution.</t>

			<t>In the case of broadband managed
      <t>For broadband-managed networks (where the CE is provided or
			suggested/supported by the operator), in order to fully support
			the actual user user's needs (IPv4-only (i.e., IPv4-only devices and applications, applications and the
			usage of IPv4 literals and non-IPv6 compliant non-IPv6-compliant APIs), the 464XLAT scenario
			should be considered. In that case, it must support a CLAT function.</t>

      <t>If the operator provides DNS services, in order to increase performance
			by reducing the double translation for all the IPv4 traffic, they may support a DNS64 function and to avoid, as much as possible, breaking DNSSEC.  This will also increase performance,
			by reducing the double translation for all the IPv4 traffic.  In this case, if the DNS service
			is offering DNSSEC validation, then it must be in such a way that it is
			aware of the DNS64. This is considered the simpler and safer approach,
			and it may be combined as well with other recommendations described
			in this document:</t>

			<t><list style="symbols">
			<t>DNS
      <ul spacing="normal">
        <li>DNS infrastructure MUST <bcp14>MUST</bcp14> be aware of DNS64 (<xref target="dns64-aware"/>).</t>
			<t>Devices target="dns64-aware" format="default"/>).</li>
        <li>Devices running CLAT SHOULD <bcp14>SHOULD</bcp14> follow the indications in "Stub Validator"
			(see <xref target="stub"/> (Stub Validator). target="stub" format="default"/>). However, this may be out of the
			control of the operator.</t>
			<t>CEs SHOULD operator.</li>
        <li>CEs <bcp14>SHOULD</bcp14> include a DNS proxy and validator (<xref target="dns-proxy"/>).</t>
			<t><xref target="acl-client"/> (ACL target="dns-proxy" format="default"/>).</li>
        <li>"ACL of clients) and Clients" (see <xref target="mapping-out"/> (Mapping-out target="acl-client" format="default"/>) and "Mapping Out IPv4 addresses) MAY Addresses"
			(see <xref target="mapping-out" format="default"/>) <bcp14>MAY</bcp14> be considered by
			operators, depending on their own infrastructure.</t>
			</list></t> infrastructure.</li>
      </ul>
      <t>This "increased performance" approach has the disadvantage of
			potentially breaking DNSSEC for a small percentage of validating
			end-hosts
			end hosts versus the small impact of a double translation taking place
			in the CE. If CE performance is not an issue, which is the most frequent
			case, then a much safer approach is to not use DNS64 at all,
			and consequently, ensure that all the IPv4 traffic
			is translated at the CLAT (<xref target="xlatwwdns64"/>).</t> target="xlatwwdns64" format="default"/>).</t>
      <t>If DNS64 is not used, at least one of the alternatives
			described in <xref target="nodns64"/>, target="nodns64" format="default"/> must be followed in order
			to learn the NAT64 prefix.</t>

      <t>The operator needs to consider that if the DNS configuration can
			be is
			modified (<xref target="foreignDNS"/>, (see Sections <xref target="dnspriv"/>, target="foreignDNS" format="counter"/>, <xref target="SplitDNS"/>), target="dnspriv" format="counter"/>, and
			<xref target="SplitDNS" format="counter"/>), which most probably
			is impossible to avoid, there are chances that likely
			cannot be avoided, a foreign non-DNS64 could be used instead of configuring a DNS64 a foreign non-DNS64 is used. DNS64. In a scenario with only a
			NAT64 function function, an IPv4-only remote host will no longer be accessible.
			Instead, it will continue to work in the case of 464XLAT.</t>
      <t>Similar considerations need to be taken made regarding the usage of
   a NAT64 WKP vs NSP vs.&nbsp;NSP (<xref target="WKP-NSP"/>), target="WKP-NSP" format="default"/>), as they must match
			with
			the configuration of the DNS64. In case of When using foreign DNS,
			they may not match.
			If there is a CLAT and the configured foreign DNS is not a DNS64, the
			network will keep working only if other means of learning the NAT64
			prefix are available.</t>

			<t>As
      <t>For broadband networks, as described in <xref target="CLAT"/>, for broadband networks, target="CLAT" format="default"/>,
			the CEs supporting a CLAT function, SHOULD function <bcp14>SHOULD</bcp14>
			support DHCPv6-PD (<xref target="RFC8415"/>), <xref target="RFC8415" format="default"/> or alternative means for
			configuring a shorter prefix. The CE SHOULD <bcp14>SHOULD</bcp14> internally reserve
			one /64 for the stateless NAT46 translation. The operator must ensure
			that the customers get are allocated prefixes shorter than /64 in order
			to support this optimization. One way or the other, another, this is not
			impacting the performance of the operator network.</t>
      <t>Operators may follow Section "Deployment Considerations" (Section 7 of <xref target="RFC6877"/> (Deployment
			Considerations), target="RFC6877" format="default"/>) for suggestions in order on how to
			take advantage of traffic engineering traffic-engineering requirements.</t>

			<t>In the case of
      <t>For cellular networks, the considerations regarding DNSSEC
			may appear as out-of-scope, to be out of scope because UEs UEs' Operating Systems, Systems
			commonly don't support DNSSEC. However, applications running on them
			may do,
			may, or it may be an Operating System "built-in" support in the
			future. Moreover, if those devices offer tethering,
			other client devices behind the UE, UE may be doing the validation,
			hence the relevance of a validation;
			hence, proper DNSSEC support by the operator network.</t> network is relevant.</t>
      <t>Furthermore, cellular networks supporting 464XLAT
			(<xref target="RFC6877"/>)
			<xref target="RFC6877" format="default"/> and "Discovery of the IPv6 Prefix Used for
			IPv6 Address Synthesis" (<xref target="RFC7050"/>), <xref target="RFC7050" format="default"/> allow a progressive
			IPv6 deployment, with a single APN Access Point Name (APN) supporting all types of PDP context
			(IPv4, IPv6, and IPv4v6). This approach allows the network to
			automatically serve every possible combinations combination of UEs.</t>
      <t>If the operator chooses to provide validation for the DNS64
			prefix discovery, it must follow the advice from Section 3.1. of
			<xref target="RFC7050"/> (Validation "Validation of Discovered Pref64::/n).</t> Pref64::/n" (see
			<xref target="RFC7050" sectionFormat="of" section="3.1"/>).</t>
      <t>One last consideration, consideration is that many networks may have a mix of different
			complex scenarios at the same time, time; for example, customers requiring 464XLAT,
			others not requiring it, that require 464XLAT
                        and those that don't,
			customers requiring DNS64, others not, that require DNS64 and those that don't, etc. In
			general, the different issues and the approaches described in this document
			can be implemented at the same time for different customers or parts of
			the network. That mix of approaches don't doesn't present any problem or
			incompatibility, as
			incompatibility; they work well together, being just together as a matter of
			appropriate and differentiated provisioning. In fact, the NAT64/464XLAT
			approach facilitates an operator offering both cellular and broadband
			services,
			services to have a single IPv4aaS for both networks while differentiating
			the deployment key decisions to optimize each case. It It's even makes possible
			using to
			use hybrid CEs that have a main broadband access link and a backup via
			the cellular network.</t>
      <t>In an ideal world world, we could safely use DNS64, DNS64 if the approach
			proposed in <xref target="I-D.bp-v6ops-ipv6-ready-dns-dnssec"/>
			is target="I-D.bp-v6ops-ipv6-ready-dns-dnssec" format="default"/>
			were followed, avoiding the cases where DNSSEC may be broken.
			However, this will not solve the issues related to DNS Privacy privacy
			and Split split DNS.</t>
      <t>The only 100% safe solution, which solution that also resolves all the issues,
			will be, issues
			is, in addition to having a CLAT function, not using a DNS64 but
			instead making sure that the hosts have a built-in address
			synthesis feature. Operators could manage to provide CEs with
			the CLAT function, however function; however, the built-in address
			synthesis feature is out of their control. If the synthesis is
			provided either by either the Operating System (via its DNS resolver API)
			or by the application (via its own DNS resolver), resolver) in such way that
			the prefix used for the NAT64 function is reachable for the host,
			the problem goes away.</t>
      <t>Whenever feasible, using EAM (<xref target="RFC7757"/>) <xref target="RFC7757" format="default"/>
			as indicated in <xref target="EAM"/>, target="EAM" format="default"/> provides a very relevant
			optimization, avoiding double-translations.</t> double translations.</t>
      <t>Applications that require incoming connections, connections typically already
			provide a means for that. that already. However, PCP and EAM, as indicated in
			<xref target="incoming"/>, target="incoming" format="default"/>, are valid alternatives, even for
			creating explicit mappings for customers that require them.</t>
    </section>
    <section title="Deployment numbered="true" toc="default">
      <name>Deployment of 464XLAT/NAT64 in Enterprise Networks"> Networks</name>
      <t>The recommendations of in this document can also be used as well in
			enterprise networks, campus campuses, and other similar scenarios (including
			managed end-user networks).</t>

      <t>This include includes scenarios where the NAT64 function
			(and DNS64 function, if available) are under
			the control of that network (or can be configured manually according
			to that network network's specific requirements), and for whatever reasons, there is a need
			to provide "IPv6-only access" IPv6-only access to any part of that
			network
			network, or it is IPv6-only IPv6 only connected to third party-networks.</t> third-party networks.</t>
      <t>An example of that is the IETF meetings meeting network itself,
			where both NAT64 and DNS64 functions are provided, presenting in this case
			the same issues as per <xref target="spnatdns64"/>. target="spnatdns64" format="default"/>. If there
			is a CLAT function in the IETF network, then there is no
			need to use DNS64 DNS64, and it falls under the considerations of
			<xref target="xlat-dns64"/>. target="xlat-dns64" format="default"/>. Both scenarios have been tested and
			verified already in the IETF network itself.</t>

			<t>Next network.</t>

      <t>The following figures are only meant to represent a few of the possible
			scenarios, not pretending to be the only feasible ones.</t>
			scenarios.</t>
      <t><xref target="enterprise-nat64-dns64"/> target="enterprise-nat64-dns64" format="default"/> provides an example of an
			IPv6-only enterprise network connected with dual-stack a dual stack to
			the Internet and using local NAT64 and DNS64 functions.</t>
      <figure align="center" anchor="enterprise-nat64-dns64"
                title="IPv6-only enterprise anchor="enterprise-nat64-dns64">
        <name>IPv6-Only Enterprise with NAT64 and DNS64"> DNS64</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+----------------------------------+
|       Enterprise Network         |
| +----------+        +----------+ |       +----------+
| |   IPv6   IPv6-  |        |  NAT64   | |       |   IPv4   |
| |   only   +--------+    +     | +-------+     +    |
| |   LANs   |        |  DNS64   | |       |   IPv6   |
| +----------+        +----------+ |       +----------+
+----------------------------------+
            ]]></artwork>
+----------------------------------+]]></artwork>

      </figure>
      <t><xref target="enterprise-464xlat"/> target="enterprise-464xlat" format="default"/> provides an example of a
			dual-stack (DS)
			DS enterprise network connected with dual-stack (DS) DS
			to the Internet and using a CLAT function, without a DNS64 function.</t>

      <figure align="center" anchor="enterprise-464xlat"
                title="DS enterprise anchor="enterprise-464xlat">
        <name>DS Enterprise with CLAT, DS Internet, without DNS64"> DNS64</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+----------------------------------+
|       Enterprise Network         |
| +----------+        +----------+ |       +----------+
| |   IPv6   |        |          | |       |   IPv4   |
| |     +    +--------+  NAT64   | +-------+     +    |
| |   CLAT   |        |          | |       |   IPv6   |
| +----------+        +----------+ |       +----------+
+----------------------------------+
            ]]></artwork>
+----------------------------------+]]></artwork>

      </figure>
      <t>Finally, <xref target="enterprise-own-clat"/> target="enterprise-own-clat" format="default"/> provides an example of an
			IPv6-only provider with a NAT64 function, and a dual-stack (DS) DS enterprise
			network by means of their own CLAT function, without a DNS64 function.</t>
      <figure align="center" anchor="enterprise-own-clat"
                title="DS enterprise anchor="enterprise-own-clat">
        <name>DS Enterprise with CLAT, IPv6-only CLAT and IPv6-Only Access, without DNS64"> DNS64</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+----------------------------------+
|       Enterprise Network         |
| +----------+        +----------+ |        +----------+
| |   IPv6   |        |          | |  IPv6  |          |
| |     +    +--------+   CLAT   | +--------+   NAT64  |
| |   IPv4   |        |          | |  only  |          |
| +----------+        +----------+ |        +----------+
+----------------------------------+
            ]]></artwork>
+----------------------------------+]]></artwork>

      </figure>
    </section>
    <section title="Security Considerations"> 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. For example, DNS64
			(<xref target="RFC6147"/>)
			<xref target="RFC6147" format="default"/> already describes the DNSSEC issues.</t>

			<t>Note that, as
      <t>As already described in <xref target="foreignDNS"/>, target="foreignDNS" format="default"/>, note that there
			may be undesirable interactions, specially especially if using VPNs or DNS privacy,
			which may impact in the correct performance of DNS64/NAT64.</t>

			<t>It should be remarked

      <t>Note that the use of a DNS64 function has equivalent
			privacy considerations as in the case of a that are equivalent to regular DNS, either and they are located
			in either the service provider or an external one.</t> service provider.</t>
    </section>
    <section title="IANA Considerations">
			<t>This numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t> This document does not have any new specific has no IANA considerations.</t>

			<t>Note: This section is assuming that https://www.rfc-editor.org/errata/eid5152 actions.</t>

    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-6man-ra-pref64" to="PREF64"/>
    <displayreference target="I-D.huitema-quic-dnsoquic" to="QUIC-CONNECTIONS"/>
     <displayreference target="I-D.lmhp-v6ops-transition-comparison"
		       to="IPv6-TRANSITION"/>
     <displayreference target="I-D.bp-v6ops-ipv6-ready-dns-dnssec"
		       to="DNS-DNSSEC"/>

     <displayreference target="I-D.palet-v6ops-464xlat-opt-cdn-caches" to="OPT-464XLAT"/>
     <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/reference.RFC.1918.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5389.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5625.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5766.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6052.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6535.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7915.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6144.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6877.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6887.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7050.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7225.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7757.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8273.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8375.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6889.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6950.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7051.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7269.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7755.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7756.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7849.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8219.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.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"/>

         <!--draft-huitema-quic-dnsoquic-07; in last call -->
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.huitema-quic-dnsoquic.xml"/>

<!--draft-lmhp-v6ops-transition-comparison-03; I-D Exists -->
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.lmhp-v6ops-transition-comparison.xml"/>

<!--draft-bp-v6ops-ipv6-ready-dns-dnssec-00; Expired -->
    <xi:include
	href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.bp-v6ops-ipv6-ready-dns-dnssec.xml"/>

        <!--draft-palet-v6ops-464xlat-opt-cdn-caches-04; I-D Exists-->
	<xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.palet-v6ops-464xlat-opt-cdn-caches.xml"/>

        <!--draft-li-intarea-nat64-prefix-dhcp-option-02; I-D Exists
	-->
	<xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.li-intarea-nat64-prefix-dhcp-option.xml"/>

        <!--draft-vixie-dnsop-dns-rpz-00; Replaced by draft-ietf-dnsop-dns-rpz, which is resolved, otherwise, this section may include the required text
			to resolve the issue.</t>

			<t>Alternatively, this could be fixed also replaced by <xref target="I-D.cheshire-sudn-ipv4only-dot-arpa"/>.</t>
		</section>

		<section title="Acknowledgements">
			<t>The author would like to acknowledge 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"/>

        <!-- draft.cheshire-sudn-ipv4only-dot-arpa-15; I-D Exists-->
	<xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.cheshire-sudn-ipv4only-dot-arpa.xml"/>

        <reference anchor="Threat-DNS64" target="https://www.sciencedirect.com/science/article/pii/S0167404818303663?via%3Dihub">
          <front>
            <title>Methodology for the inputs identification of Gabor Lencse,
			Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker,
			Mohamed Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson
			and Eric Vyncke.</t>

			<t>Conversations with Marcelo Bagnulo, one potential security issues of the co-authors different IPv6 transition technologies: Threat analysis of NAT64 DNS64 and
			DNS64, as well as several emails in mailing lists from Mark Andrews,
			have been very useful for this work.</t>

			<t>Christian Huitema inspired working in this document by suggesting
			that stateful 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/science/article/pii/S0140366418302184?via%3Dihub">
          <front>
            <title>Benchmarking DNS64 should never be used, during a discussion regarding the
			deployment of CLAT in the IETF network.</t>

		</section>

    <section title="ANNEX A: Example of Broadband Deployment with 464XLAT">
      <t>This section summarizes how an operator may deploy an IPv6-only
      network for residential/SOHO customers, supporting IPv6 inbound
      connections, Implementations: Theory and IPv4-as-a-Service Practice</title>
            <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/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 month="June" year="2016"/>
          </front>
        </reference>

        <reference anchor="FCC" target="https://www.fcc.gov/reports-research/reports/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 service</title>
            <author>
              <organization>ARCEP</organization>
            </author>
            <date month="April" 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 month="June" year="2018"/>
          </front>
        </reference>
        <reference anchor="RIPE-690" target="https://www.ripe.net/publications/docs/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
      network for residential/SOHO customers, supporting IPv6 inbound
      connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT.</t>
      <t>Note that an equivalent setup could also be provided for enterprise
      customers. In case If they need to support IPv4 inbound connections, several
      mechanisms, depending on specific customer needs, allow that, for instance it; see
      <xref target="RFC7757"/>.</t> target="RFC7757" format="default"/>.</t>
      <t>Conceptually, most part of the operator network could be IPv6-only IPv6 only
	  (represented in the next pictures figures as "IPv6-only flow"), or even if
	  this
	  part of the network is actually dual-stack, dual stack, only IPv6-access IPv6 access
	  is available for some customers (i.e. (i.e., residential customers).
	  This part of the network connects the IPv6-only subscribers
	  (by means of IPv6-only access links), links) to the IPv6 upstream providers,
	  as well as providers
	  and to the IPv4-Internet by means of the NAT64 (PLAT
	  in the 464XLAT terminology).</t>
      <t>The traffic flow from and back to the CE to services available in the
	  IPv6 Internet (or even dual-stack remote services, when IPv6 is being used), used)
	  is purely native IPv6 traffic, so there are no special considerations about it.</t>

	  <t>Looking at the picture from

      <t>From the DNS perspective, there are remote
	  networks with are IPv4-only, and typically IPv4 only that will typically have only IPv4 DNS
	  (DNS/IPv4),
	  (DNS/IPv4) or will at least will be seen as that IPv4 DNS from the CE perspective.
	  At
	  On the operator side, the DNS, as seen from the CE, is
	  only IPv6 (DNS/IPv6) (DNS/IPv6), and has it also has a DNS64 function. </t>

	  <t>In
      <t>On the customer LANs side, there is actually one network, which of course
	  could be split in into different segments. The most common setup will be
	  those segments being dual-stack,
	  dual-stack segments, using global IPv6 addresses and <xref target="RFC1918"/> target="RFC1918" format="default"/>
	  for IPv4, as usual in any regular residential/SOHO residential / Small Office, Home Office (SOHO) IPv4 network.
	  In the figure, figure below, it is represented as tree segments, just segments to show that the
	  three possible setups are valid (IPv6-only, IPv4-only (IPv6 only, IPv4 only, and dual-stack).</t> dual stack).</t>
      <figure align="center" anchor="clat-CE-DNS64"
                title="CE setup anchor="clat-CE-DNS64">
        <name>CE Setup with built-in CLAT Built-In CLAT, with DNS64"> DNS64</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
    .-----.    +-------+     .-----.                   .-----.
   / IPv6- \   |       |    /       \                 /       \
  (  only   )--+ Res./ |   /  IPv6-  \    .-----.    /  IPv4-  \
   \ LANs  /   | SOHO  +--(   only    )--( NAT64 )--(   only    )
    `-----´
    `-----'    |       |   \  flow   /    `-----´    `-----'    \  flow   /
    .-----.    | IPv6  |    \       /                 \       /
   / IPv4- \   |  CE   |     `--+--´                   `--+--´     `--+--'                   `--+--'
  (  only   )--+ with  |        |                         |
   \ LANs  /   | CLAT  |    +---+----+                +---+----+
    `-----´
    `-----'    |       |    |DNS/IPv6|                |DNS/IPv4|
    .-----.    +---+---+    |  with  |                +--------+
   / Dual- \       |        | DNS64  |
  (  Stack  )------|        +--------+
   \ LANs  /
    `-----´
    `-----' ]]></artwork>

      </figure>
      <t>In addition to the regular CE setup, which typically will be typically
	  access-technology dependent, the steps for the CLAT function
	  configuration can be summarized as:</t>
			<t><list style="numbers">
				<t>Discovery as follows:</t>
      <ol spacing="normal" type="1">
        <li>Discovery of the PLAT (NAT64) prefix: It may be done
				using <xref target="RFC7050"/>, or target="RFC7050" format="default"/>, <xref target="RFC7225" format="default"/> in those networks where PCP
				is supported, by means of <xref target="RFC7225"/>, or other
				alternatives that may be available in the future, such as Router
				Advertising (<xref target="I-D.ietf-6man-ra-pref64"/>) <xref target="I-D.ietf-6man-ra-pref64" format="default"/> or
				DHCPv6 options (<xref target="I-D.li-intarea-nat64-prefix-dhcp-option"/>).</t>

				<t>If <xref target="I-D.li-intarea-nat64-prefix-dhcp-option" format="default"/>.</li>
        <li>If the CLAT function allows stateless NAT46 translation, a /64 from
				the pool typically provided to the CE by means of DHCPv6-PD
				<xref target="RFC8415"/>, need target="RFC8415" format="default"/> needs to be set aside for that translation.
				Otherwise, the CLAT is forced to perform an intermediate stateful
				NAT44 before the a stateless NAT46, as described in <xref target="CLAT"/>.</t>
			</list></t> target="CLAT" format="default"/>.</li>
      </ol>
      <t>A more detailed configuration approach is described in
	  <xref target="RFC8585"/>.</t> target="RFC8585" format="default"/>.</t>
      <t>The operator network needs to ensure that the correct responses are provided
	  for the discovery of the PLAT prefix. It is highly recommended
	  to follow
	  that <xref target="RIPE-690"/>, target="RIPE-690" format="default"/> be followed in order to ensure that multiple /64s
	  are available, including the one needed for the NAT46 stateless translation.</t>
      <t>The operator needs to understand other issues, as described across throughout this document,
	  in order to take the make relevant decisions. For example, if several NAT64 functions
	  are needed in the context of scalability/high-availability, scalability / high availability, an NSP should be
	  considered (<xref target="WKP-NSP"/>).</t> (see <xref target="WKP-NSP" format="default"/>).</t>
      <t>More complex scenarios are possible, for example, if a network offers
	  multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.</t>
      <t>If the operator decides not to provide a DNS64 function, then this
	  setup turns into will be the one in same as the following Figure. figure. This will be also be
	  the setup that "will will be seen" seen from the perspective
	  of the CE, if a foreign DNS is used and consequently is
	  not the operator-provided DNS64 function.</t>
      <figure align="center" anchor="clat-CE"
                title="CE setup anchor="clat-CE">
        <name>CE Setup with built-in CLAT Built-In CLAT, without DNS64"> DNS64</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
    .-----.    +-------+     .-----.                   .-----.
   / IPv6- \   |       |    /       \                 /       \
  (  only   )--+ Res./ |   /  IPv6-  \    .-----.    /  IPv4-  \
   \ LANs  /   | SOHO  +--(   only    )--( NAT64 )--(   only    )
    `-----´
    `-----'    |       |   \  flow   /    `-----´    `-----'    \  flow   /
    .-----.    | IPv6  |    \       /                 \       /
   / IPv4- \   |  CE   |     `--+--´                   `--+--´     `--+--'                   `--+--'
  (  only   )--+ with  |        |                         |
   \ LANs  /   | CLAT  |    +---+----+                +---+----+
    `-----´
    `-----'    |       |    |DNS/IPv6|                |DNS/IPv4|
    .-----.    +---+---+    +--------+                +--------+
   / Dual- \       |
  (  Stack  )------|
   \ LANs  /
    `-----´
            ]]></artwork>
    `-----']]></artwork>

      </figure>
      <t>In this case, the discovery of the PLAT prefix needs to be arranged as
	  indicated in <xref target="nodns64"/>.</t> target="nodns64" format="default"/>.</t>

      <t>In this case, addition, if the CE doesn't have a built-in CLAT function, or the customer can
	  choose to setup set up the IPv6 operator-managed CE in bridge mode (and optionally
	  use an external router), or router).  Or, for example, if there is an access technology
	  that requires some kind of media converter (ONT for FTTH, Cable-Modem (Optical Network Termination (ONT) for DOCSIS,
          fiber to the home (FTTH), Cable Modem
	  for Data-Over-Cable Service Interface Specification (DOCSIS), etc.), the complete
          setup will look as in like <xref target="clat-bridge"/>. target="clat-bridge" format="default"/>.

	  Obviously, there will be some intermediate configuration steps for the
	  bridge, depending on the specific access technology/protocols, which
	  should not modify the steps already described in the previous cases
	  for the CLAT function configuration.</t>
      <figure align="center" anchor="clat-bridge"
                title="CE setup anchor="clat-bridge">
        <name>CE Setup with bridged CLAT Bridged CLAT, without DNS64"> DNS64</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
               +-------+     .-----.                   .-----.
               |       |    /       \                 /       \
               | Res./ |   /  IPv6-  \    .-----.    /  IPv4-  \
               | SOHO  +--(   only    )--( NAT64 )--(   only    )
               |       |   \  flow   /    `-----´    `-----'    \  flow   /
               | IPv6  |    \       /                 \       /
               |  CE   |     `--+--´                   `--+--´     `--+--'                   `--+--'
               | Bridge|        |                         |
               |       |    +---+----+                +---+----+
               |       |    |DNS/IPv6|                |DNS/IPv4|
               +---+---+    +--------+                +--------+
                   |
    .-----.    +---+---+
   / IPv6- \   |       |
  (  only   )--+ IPv6  |
   \ LANs  /   | Router|
    `-----´
    `-----'    |       |
    .-----.    | with  |
   / IPv4- \   | CLAT  |
  (  only   )--+       |
   \ LANs  /   |       |
    `-----´
    `-----'    |       |
    .-----.    +---+---+
   / Dual- \       |
  (  Stack  )------|
   \ LANs  /
    `-----´
            ]]></artwork>
    `-----']]></artwork>

      </figure>

		<t>It should be avoided that several

      <t>Several routers (i.e., the operator provided operator-provided
                 CE and a the downstream user provided user-provided router) that enable simultaneously
                 simultaneous routing and/or
		 CLAT, in order CLAT should be avoided to avoid ensure that  multiple NAT44
                 and NAT46 levels, as well as
		 ensuring levels are not used and that the correct operation of
                 multiple IPv6 subnets. subnets is correct.  In those cases,
		 it is suggested
		 the use of HNCP (<xref target="RFC8375"/>).</t> the Home Networking Control Protocol (HNCP) <xref target="RFC8375" format="default"/> is suggested.</t>
      <t>Note that the procedure described here for the CE setup, setup can be simplified
		if the CE follows <xref target="RFC8585"/>.</t> target="RFC8585" format="default"/>.</t>
    </section>
    <section title="ANNEX B: CLAT Implementation"> 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 of:</t>
			<t><list style="symbols">
		 		<t><xref target="RFC7915"/> for:</t>
      <ul spacing="normal">
        <li>
          <xref target="RFC7915" format="default"/> for the NAT46 function.</t>
		 		<t><xref target="RFC7050"/> function.</li>
        <li>
          <xref target="RFC7050" format="default"/> for the PLAT prefix discovery.</t>
		 		<t><xref target="RFC7225"/> discovery.</li>
        <li>
          <xref target="RFC7225" format="default"/> for the PLAT prefix discovery if PCP is supported.</t>
		 		<t><xref target="I-D.ietf-6man-ra-pref64"/> supported.</li>
        <li>
          <xref target="I-D.ietf-6man-ra-pref64" format="default"/> for the PLAT prefix
		 		discovery by means of Router Advertising.</t>
		 		<t><xref target="I-D.li-intarea-nat64-prefix-dhcp-option"/> Advertising.</li>
        <li>
          <xref target="I-D.li-intarea-nat64-prefix-dhcp-option" format="default"/> for the PLAT prefix
		 		discovery by means of DHCP.</t>
		 		<t>If DHCP.</li>

        <li>If stateless NAT46 is supported, a mechanism to ensure that
		 		multiple /64 are available, such as DHCPv6-PD <xref target="RFC8415"/>.</t>
			</list></t> target="RFC8415"/>, must be used.</li>
      </ul>
      <t>There are several OpenSource Open Source implementations of CLAT, such as:</t>
			<t><list style="symbols">
				<t>Android: https://github.com/ddrown/android_external_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/packages/blob/master/nat46/files/464xlat.sh.</t>
				<t>VPP: https://git.fd.io/vpp/tree/src/plugins/nat.</t>
			</list></t>

    </section>

    <section title="ANNEX C: Benchmarking">
		<t><xref target="RFC8219"/> has defined a
      <ul spacing="normal">

        <li>Android: <eref target="https://github.com/ddrown/android_external_android-clat"/></li>
        <li>Jool: <eref target="https://www.jool.mx"/></li>
        <li>Linux: <eref target="https://github.com/toreanderson/clatd"/></li>

<li>OpenWRT: <eref target="https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&amp;a=search&amp;h=refs%2Ftags%2Fv19.07.0-rc1&amp;st=commit&amp;s=464xlat"/></li>
        <li>VPP: <eref target="https://git.fd.io/vpp/tree/src/plugins/nat"/></li>
      </ul>
    </section>
    <section numbered="true" toc="default">
      <name>Benchmarking</name>
      <t>A benchmarking methodology for IPv6
		transition technologies. technologies has been defined in <xref target="RFC8219" format="default"/>. NAT64 and 464XLAT are addressed
                among the single single- and
		double translation
		double-translation technologies, respectively. DNS64 is addressed in
		Section 9, <xref target="RFC8219" sectionFormat="bare"
		section="9"/>, and the methodology is more elaborated in
      <xref target="DNS64-BM-Meth"/>.</t> target="DNS64-BM-Meth" format="default"/> of that document.</t>
      <t>Several documents provide references to benchmarking results, for example
		in the case of DNS64, example,
		for DNS64 <xref target="DNS64-Benchm"/>.</t> target="DNS64-Benchm" format="default"/>.</t>
    </section>
    <section title="ANNEX D: Changes from -00 to -01/-02">
      <t>Section numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The author would like to be removed after WGLC.
      Significant updates are:<list style="numbers">
      <t>Text changes across all acknowledge the document.</t>
      </list></t>
    </section>

    <section title="ANNEX E: Changes from -02 to -03">
      <t>Section to be removed after WGLC.
      Significant updates are:<list style="numbers">
      <t>Added references to new cited documents.</t>
      <t>Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only LANs w/o DNS64.</t>
      <t>Overall review inputs of Gabor Lencse,
			Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker,
			Mohamed Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson,
			and editorial changes.</t>
      </list></t>
    </section>

    <section title="ANNEX F: Changes from -03 to -04">
      <t>Section to be removed after WGLC.
      Significant updates are:<list style="numbers">
      <t>Added text related to EAM considerations.</t>
      </list></t>
    </section>

    <section title="ANNEX G: Changes from -04 to -05">
      <t>Section to be removed after WGLC.
      Significant updates are:<list style="numbers">
      <t>Added cross references to EAM section.</t>
      <t>Reworded "foreing DNS section".</t>
      <t>Overall editorial review Eric Vyncke.</t>
      <t>Conversations with Marcelo Bagnulo, one of the coauthors of text, pictures NAT64 and nits correction.</t>
      </list></t>
    </section>

    <section title="ANNEX H: Changes from -05 to -06">
      <t>Section to be removed after WGLC.
      Significant updates are:<list style="numbers">
      <t>Corrected EAMT to EAM.</t>
      <t>Typos
			DNS64, and nits.</t>
      <t>New considerations regarding incoming connections.</t>
      </list></t>
    </section>

    <section title="ANNEX H: Changes from -06 to -07">
      <t>Section to be removed after WGLC.
      Significant updates are:<list style="numbers">
      <t>Inputs/clarifications from IESG review.</t>
      </list></t>
    </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 email correspondence via the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful 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 IETF mailing lists 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 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/reports/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 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 opérateurs : les mesures de qualité de service</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/docs/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> should never be used when deploying CLAT
			in the IETF network.</t>
    </section>
  </back>
</rfc>