draft-ietf-v6ops-nat64-deployment-08.txt   rfc8683.txt 
v6ops J. Palet Martinez Internet Engineering Task Force (IETF) J. Palet Martinez
Internet-Draft The IPv6 Company Request for Comments: 8683 The IPv6 Company
Intended status: Informational July 11, 2019 Category: Informational November 2019
Expires: January 12, 2020 ISSN: 2070-1721
Additional NAT64/464XLAT Deployment Guidelines in Operator and Additional Deployment Guidelines for NAT64/464XLAT in Operator and
Enterprise Networks Enterprise Networks
draft-ietf-v6ops-nat64-deployment-08
Abstract Abstract
This document describes how NAT64 (including 464XLAT) can be deployed This document describes how Network Address and Protocol Translation
in an IPv6 network, whether cellular ISP, broadband ISP, or from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be
enterprise, and possible optimizations. The document also discusses deployed in an IPv6 network -- whether it's cellular ISP, broadband
issues to be considered when having IPv6-only connectivity, ISP, or enterprise -- and the possible optimizations. This document
regarding: a) DNS64, b) applications or devices that use literal IPv4 also discusses issues to be considered when having IPv6-only
addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or connectivity, such as: a) DNS64, b) applications or devices that use
applications. literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only
hosts or applications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on January 12, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8683.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language
3. NAT64 Deployment Scenarios . . . . . . . . . . . . . . . . . 5 3. NAT64 Deployment Scenarios
3.1. Known to Work . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Known to Work
3.1.1. Service Provider NAT64 with DNS64 . . . . . . . . . . 6 3.1.1. Service Provider NAT64 with DNS64
3.1.2. Service Provider Offering 464XLAT, with DNS64 . . . . 8 3.1.2. Service Provider Offering 464XLAT Using DNS64
3.1.3. Service Provider Offering 464XLAT, without DNS64 . . 12 3.1.3. Service Provider Offering 464XLAT, without Using DNS64
3.2. Known to Work Under Special Conditions . . . . . . . . . 14 3.2. Known to Work under Special Conditions
3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 14 3.2.1. Service Provider NAT64 without DNS64
3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 16 3.2.2. Service-Provider NAT64; DNS64 in IPv6 Hosts
3.2.3. Service Provider NAT64; DNS64 in the IPv4-only 3.2.3. Service-Provider NAT64; DNS64 in the IPv4-Only Remote
remote network . . . . . . . . . . . . . . . . . . . 16 Network
3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 17 3.3. Comparing the Scenarios
4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 19 4. Issues to be Considered
4.1. DNSSEC Considerations and Possible Approaches . . . . . . 19 4.1. DNSSEC Considerations and Possible Approaches
4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 20 4.1.1. Not Using DNS64
4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21 4.1.2. DNSSEC Validator Aware of DNS64
4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 22 4.1.3. Stub Validator
4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 22 4.1.4. CLAT with DNS Proxy and Validator
4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22 4.1.5. ACL of Clients
4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 23 4.1.6. Mapping Out IPv4 Addresses
4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 23 4.2. DNS64 and Reverse Mapping
4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 23 4.3. Using 464XLAT with/without DNS64
4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 24 4.4. Foreign DNS
4.4.1. Manual Configuration of DNS . . . . . . . . . . . . . 25 4.4.1. Manual Configuration of DNS
4.4.2. DNS Privacy/Encryption Mechanisms . . . . . . . . . . 25 4.4.2. DNS Privacy/Encryption Mechanisms
4.4.3. Split DNS and VPNs . . . . . . . . . . . . . . . . . 26 4.4.3. Split DNS and VPNs
4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 26 4.5. Well-Known Prefix (WKP) vs. Network-Specific Prefix (NSP)
4.6. IPv4 literals and non-IPv6 Compliant APIs . . . . . . . . 26 4.6. IPv4 Literals and Non-IPv6-Compliant APIs
4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 27 4.7. IPv4-Only Hosts or Applications
4.8. CLAT Translation Considerations . . . . . . . . . . . . . 27 4.8. CLAT Translation Considerations
4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 28 4.9. EAM Considerations
4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 28 4.10. Incoming Connections
5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 28 5. Summary of Deployment Recommendations for NAT64/464XLAT
6. Deployment of 464XLAT/NAT64 in Enterprise Networks . . . . . 31 6. Deployment of 464XLAT/NAT64 in Enterprise Networks
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 9. References
10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 34 9.1. Normative References
11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 37 9.2. Informative References
12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 38 Appendix A. Example of Broadband Deployment with 464XLAT
13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 38 Appendix B. CLAT Implementation
14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 38 Appendix C. Benchmarking
15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 39 Acknowledgements
16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 39 Author's Address
17. ANNEX H: Changes from -05 to -06 . . . . . . . . . . . . . . 39
18. ANNEX H: Changes from -06 to -07 . . . . . . . . . . . . . . 39
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
19.1. Normative References . . . . . . . . . . . . . . . . . . 39
19.2. Informative References . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 Stateful NAT64 [RFC6146] describes a stateful IPv6-to-IPv4
translation mechanism, which allows IPv6-only hosts to communicate translation mechanism that allows IPv6-only hosts to communicate with
with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of IPv4-only servers using unicast UDP, TCP, or ICMP by means of IPv4
IPv4 public addresses sharing, among multiple IPv6-only hosts. public address sharing among multiple IPv6-only hosts. Unless
Unless otherwise stated, references in the rest of this document to otherwise stated, references to NAT64 (function) in this document
NAT64 (function) should be interpreted as to Stateful NAT64. should be interpreted as Stateful NAT64.
The translation of the packet headers is done using the IP/ICMP The translation of the packet headers is done using the IP/ICMP
translation algorithm defined in [RFC7915] and algorithmically translation algorithm defined in [RFC7915]; algorithmically
translating the IPv4 addresses to IPv6 addresses and vice versa, translating the IPv4 addresses to IPv6 addresses, and vice versa, is
following [RFC6052]. done following [RFC6052].
DNS64 ([RFC6147]) is in charge of the synthesis of AAAA records from DNS64 [RFC6147] is in charge of the synthesis of AAAA records from
the A records, so only works for applications making use of DNS. It the A records, so it only works for applications making use of DNS.
was designed to avoid changes in both, the IPv6-only hosts and the It was designed to avoid changes in both the IPv6-only hosts and the
IPv4-only server, so they can use a NAT64 function. As discussed in IPv4-only server, so they can use a NAT64 function. As discussed in
Section 5.5 of [RFC6147], a security-aware and validating host has to Section 5.5 of [RFC6147], a security-aware and validating host has to
perform the DNS64 function locally. perform the DNS64 function locally.
However, the use of NAT64 and/or DNS64 present three drawbacks: However, the use of NAT64 and/or DNS64 presents three drawbacks:
a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is 1. Because DNS64 [RFC6147] modifies DNS answers, and DNSSEC is
designed to detect such modifications, DNS64 ([RFC6147]) may designed to detect such modifications, DNS64 [RFC6147] may
potentially break DNSSEC, depending on a number of factors, such potentially break DNSSEC, depending on a number of factors such
as the location of the DNS64 function (at a DNS server or as the location of the DNS64 function (at a DNS server or
validator, at the end host, ...), how it has been configured, if validator, at the end host, ...), how it has been configured, if
the end-hosts is validating, etc. the end hosts are validating, etc.
b. Because the need of using DNS64 ([RFC6147]) or an alternative 2. Because of the need to use DNS64 [RFC6147] or an alternative
"host/application built-in" mechanism for address synthesis, "host/application built-in" mechanism for address synthesis,
there may be an issue for NAT64 ([RFC6146]), as it doesn't work there may be an issue for NAT64 [RFC6146] because it doesn't work
when IPv4 literal addresses or non-IPv6 compliant APIs are being when IPv4 literal addresses or non-IPv6-compliant APIs are being
used. used.
c. NAT64 alone, was not designed to provide a solution for IPv4-only 3. NAT64 alone was not designed to provide a solution for IPv4-only
hosts or applications located within a network which are hosts or applications that are located within a network and
connected to a service provider IPv6-only access, as it was connected to a service provider IPv6-only access link, as it was
designed for a very specific scenario ([RFC6144], Section 2.1). designed for a very specific scenario (see Section 2.1 of
[RFC6144]).
Above drawbacks may be true if part of, an enterprise network, is The drawbacks discussed above may come into play if part of an
connected to other parts of the same network or third-party networks enterprise network is connected to other parts of the same network or
by means of IPv6-only connectivity. This is just an example which to third-party networks by means of IPv6-only connectivity. This is
may apply to many other similar cases. All them are deployment just an example that may apply to many other similar cases. All of
specific. them are deployment specific.
According to that, across this document, the use of "operator", Accordingly, the use of "operator", "operator network", "service
"operator network", "service provider", and similar ones, are provider", and similar terms in this document are interchangeable
interchangeable with equivalent cases of enterprise networks (and with equivalent cases of enterprise networks; other cases may be
similar ones). This may be also the case for "managed end-user similar as well. This may be also the case for "managed end-user
networks". networks".
Note that if all the hosts in a network were performing the address Note that if all the hosts in a network were performing address
synthesis, as described in Section 7.2 of [RFC6147], some of the synthesis, as described in Section 7.2 of [RFC6147], some of the
drawbacks may vanish. However, it is unrealistic today to expect drawbacks may not apply. However, it is unrealistic to expect that
that, considering the high number of devices and applications that in today's world, considering the high number of devices and
aren't yet IPv6-enabled. So, in this document, this will be applications that aren't yet IPv6 enabled. In this document, the
considered only for specific scenarios that can guarantee it. case in which all hosts provide synthesis will be considered only for
specific scenarios that can guarantee it.
An analysis of stateful IPv4/IPv6 mechanisms is provided in An analysis of stateful IPv4/IPv6 mechanisms is provided in
[RFC6889]. [RFC6889].
This document looks into different possible NAT64 ([RFC6146]) This document looks into different possible NAT64 [RFC6146]
deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and
similar ones, which were not documented in [RFC6144], such as 464XLAT similar ones that were not documented in [RFC6144], such as 464XLAT
([RFC6877]), in operator (broadband and cellular) and enterprise [RFC6877] in operator (broadband and cellular) and enterprise
networks, and provides guidelines to avoid operational issues. networks; it provides guidelines to avoid operational issues.
Towards that, this document first looks into the possible NAT64 This document also explores the possible NAT64 deployment scenarios
deployment scenarios (split in "known to work" and "known to work (split in "known to work" and "known to work under special
under special conditions"), providing a quick and generic comparison conditions"), providing a quick and generic comparison table among
table among them. Then the document describes the issues that an them. Then, the document describes the issues that an operator needs
operator need to understand on different matters that will allow to to understand, which will allow the best approach/scenario to be
define what is the best approach/scenario for each specific network defined for each specific network case. A summary provides some
case. A summary provides some recommendations and decision points. recommendations and decision points. A section with clarifications
A section with clarifications on the usage of this document for on the usage of this document for enterprise networks is also
enterprise networks, is also provided. Finally, an annex provides an provided. Finally, Appendix A provides an example of a broadband
example of a broadband deployment using 464XLAT and another annex deployment using 464XLAT and hints for a customer-side translator
provides hints for a CLAT implementation. (CLAT) implementation.
[RFC7269] already provides information about NAT64 deployment options [RFC7269] already provides information about NAT64 deployment options
and experiences. Both, this document and [RFC7269] are and experiences. This document and [RFC7269] are complementary; they
complementary; they are looking into different deployment both look into different deployment considerations. Furthermore,
considerations and furthermore, this document is considering the this document considers the updated deployment experience and newer
updated deployment experience and newer standards. standards.
The target deployment scenarios in this document may be covered as The target deployment scenarios in this document may also be covered
well by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. Note
Note that this is true only for the case of broadband networks, as in that this is true only for broadband networks; in the case of
the case of cellular networks the only supported solution is the use cellular networks, the only supported solution is the use of
of NAT64/464XLAT. So, it is out of scope of this document to provide NAT64/464XLAT. So, it is out of scope of this document to provide a
a comparison among the different IPv4aaS transition mechanisms, which comparison among the different IPv4aaS transition mechanisms, which
is being analyzed already in [I-D.lmhp-v6ops-transition-comparison]. are analyzed in [IPv6-TRANSITION].
Consequently, this document should not be understood as a guide for Consequently, this document should not be used as a guide for an
an operator or enterprise to decide which IPv4aaS is the best one for operator or enterprise to decide which IPv4aaS is the best one for
its own network. Instead it should be used as a tool for its own network. Instead, it should be used as a tool for
understanding all the implications, including relevant documents (or understanding all the implications, including relevant documents (or
even specific parts of them), for the deployment of NAT64/464XLAT and even specific parts of them) for the deployment of NAT64/464XLAT and
facilitate the decision process regarding specific deployment for facilitating the decision process regarding specific deployment
details. details.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. NAT64 Deployment Scenarios 3. NAT64 Deployment Scenarios
Section 7 of DNS64 ([RFC6147]), provides three scenarios, depending DNS64 (see Section 7 of [RFC6147]) provides three deployment
on the location of the DNS64 function. However, since the scenarios, depending on the location of the DNS64 function. However,
publication of that document, other deployment scenarios and NAT64 since the publication of that document, other deployment scenarios
use cases need to be considered in actual networks, despite some of and NAT64 use cases need to be considered in actual networks, despite
them were specifically ruled out by the original NAT64/DNS64 work. the fact that some of them were specifically ruled out by the
original NAT64/DNS64 work.
Consequently, the perspective in this document is to broaden those Consequently, the perspective in this document is to broaden those
scenarios, including a few new ones. However, in order to be able to scenarios and include a few new ones. However, in order to reduce
reduce the number of possible cases, we work under the assumption the number of possible cases, we work under the assumption that the
that typically, the service provider wants to make sure that all the service provider wants to make sure that all the customers have a
customers have a service without failures. This means considering service without failures. This means considering the following
the following assumptions for the worst possible case: assumptions for the worst possible case:
a. There are hosts that will be validating DNSSEC. a. There are hosts that will be validating DNSSEC.
b. IPv4 literal addresses and non-IPv6 compliant APIs are being b. IPv4 literal addresses and non-IPv6-compliant APIs are being
used. used.
c. There are IPv4-only hosts or applications beyond the IPv6-only c. There are IPv4-only hosts or applications beyond the IPv6-only
link (e.g., tethering in cellular networks). link (e.g., tethering in cellular networks).
The document uses a common set of possible "participant entities": This document uses a common set of possible "participant entities":
1. An IPv6-only access network (IPv6). 1. An IPv6-only access network (IPv6).
2. An IPv4-only remote network/server/service (IPv4). 2. An IPv4-only remote network/server/service (IPv4).
3. A NAT64 function (NAT64) in the service provider. 3. A NAT64 function (NAT64) in the service provider.
4. A DNS64 function (DNS64) in the service provider. 4. A DNS64 function (DNS64) in the service provider.
5. An external service provider offering the NAT64 function and/or 5. An external service provider offering the NAT64 function and/or
the DNS64 function (extNAT64/extDNS64). the DNS64 function (extNAT64/extDNS64).
6. 464XLAT customer side translator (CLAT). 6. A 464XLAT customer-side translator (CLAT).
Note that the nomenclature used in parenthesis is the one that, for Note that the nomenclature used in parentheses is the one that, for
short, will be used in the figures. Note also that for simplicity, short, will be used in the figures. Note: for simplicity, the boxes
the boxes in the figures don't mean they are actually a single in the figures don't mean they are actually a single device; they
device; they just represent one or more functions as located in that represent one or more functions as located in that part of the
part of the network (i.e. a single box with NAT64 and DNS64 functions network (i.e., a single box with NAT64 and DNS64 functions can
can actually be several devices, not just one). actually be several devices, not just one).
The possible scenarios are split in two general categories: The possible scenarios are split in two general categories:
1. Known to work. 1. Known to work.
2. Known to work under special conditions. 2. Known to work under special conditions.
3.1. Known to Work 3.1. Known to Work
The scenarios in this category are known to work, as there are well- The scenarios in this category are known to work, as there are well-
known existing deployments from different operators using them. Each known existing deployments from different operators using them. Each
one may have different pros and cons, and in some cases the trade- one may have different pros and cons, and in some cases, the trade-
offs, maybe acceptable for some operators. offs may be acceptable for some operators.
3.1.1. Service Provider NAT64 with DNS64 3.1.1. Service Provider NAT64 with DNS64
In this scenario (Figure 1), the service provider offers both, the In this scenario (Figure 1), the service provider offers both the
NAT64 and the DNS64 functions. NAT64 and DNS64 functions.
This is the most common scenario as originally considered by the This is the most common scenario as originally considered by the
designers of NAT64 ([RFC6146]) and DNS64 ([RFC6147]), however also designers of NAT64 [RFC6146] and DNS64 [RFC6147]; however, it may
may have the implications related the DNSSEC. also have the implications related to the DNSSEC.
This scenario also may fail to solve the issue of IPv4 literal This scenario may also fail to solve the issues of IPv4 literal
addresses or non-IPv6 compliant APIs, as well as the issue of addresses, non-IPv6-compliant APIs, or IPv4-only hosts or
IPv4-only hosts or applications behind the IPv6-only access network. applications behind the IPv6-only access network.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| | | NAT64 | | | | | | NAT64 | | |
| IPv6 +--------+ + +--------+ IPv4 | | IPv6 +--------+ + +--------+ IPv4 |
| | | DNS64 | | | | | | DNS64 | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 1: NAT64 with DNS64 Figure 1: NAT64 with DNS64
A similar scenario (Figure 2) will be if the service provider offers A similar scenario (Figure 2) exists if the service provider offers
only the DNS64 function, and the NAT64 function is provided by an only the DNS64 function; the NAT64 function is provided by an
outsourcing agreement with an external provider. All the outsourcing agreement with an external provider. All the
considerations in the previous paragraphs of this section, are the considerations in the previous paragraphs of this section are the
same for this sub-case. same for this sub-case.
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| extNAT64 +--------+ IPv4 | | extNAT64 +--------+ IPv4 |
| | | | | | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
| |
+----------+ +----+-----+ +----------+ +----+-----+
| | | | | | | |
| IPv6 +--------+ DNS64 + | IPv6 +--------+ DNS64 +
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
Figure 2: NAT64 in external service provider Figure 2: NAT64 in an External Service Provider
This is equivalent to the scenario (Figure 3) where the outsourcing This is equivalent to the scenario (Figure 3) where the outsourcing
agreement with the external provider is to provide both the NAT64 and agreement with the external provider is to provide both the NAT64 and
DNS64 functions. Once more, all the considerations in the previous DNS64 functions. Once more, all the considerations in the previous
paragraphs of this section are the same for this sub-case. paragraphs of this section are the same for this sub-case.
+----------+ +----------+ +----------+ +----------+
| extNAT64 | | | | extNAT64 | | |
| + +-------+ IPv4 | | + +-------+ IPv4 |
| extDNS64 | | | | extDNS64 | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| | | | | |
| IPv6 +-------------+ | IPv6 +-------------+
| | | |
+----------+ +----------+
Figure 3: NAT64 and DNS64 in external provider Figure 3: NAT64 and DNS64 in an External Provider
One additional equivalent scenario (Figure 4) will be if the service One additional equivalent scenario (Figure 4) exists if the service
provider offers the NAT64 function only, and the DNS64 function is provider only offers the NAT64 function; the DNS64 function is from
from an external provider with or without a specific agreement among an external provider with or without a specific agreement among them.
them. This is a scenario already common today, as several "global" This is a common scenario today, as several "global" service
service providers provide free DNS/DNS64 services and users often providers provide free DNS/DNS64 services, and users often configure
configure manually their DNS. This will only work if both the NAT64 their DNS manually. This will only work if both the NAT64 and DNS64
and the DNS64 functions are using the WKP (Well-Known Prefix) or the functions are using the Well-Known Prefix (WKP) or the same Network-
same NSP (Network-Specific Prefix). All the considerations in the Specific Prefix (NSP). All the considerations in the previous
previous paragraphs of this section, are the same for this sub-case. paragraphs of this section are the same for this sub-case.
Of course, if the external DNS64 function is agreed with the service Of course, if the external DNS64 function is agreed with the service
provider, then we are in the same case as in the previous ones provider, then this case is similar to the ones already depicted in
already depicted in this scenario. this scenario.
+----------+ +----------+
| | | |
| extDNS64 | | extDNS64 |
| | | |
+----+-----+ +----+-----+
| |
| |
+----------+ +----+-----+ +----------+ +----------+ +----+-----+ +----------+
| | | | | | | | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 | | IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | | | | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 4: NAT64; DNS64 by external provider Figure 4: NAT64; DNS64 by an External Provider
3.1.2. Service Provider Offering 464XLAT, with DNS64 3.1.2. Service Provider Offering 464XLAT Using DNS64
464XLAT ([RFC6877]) describes an architecture that provides IPv4 464XLAT [RFC6877] describes an architecture that provides IPv4
connectivity across a network, or part of it, when it is only connectivity across a network, or part of it, when it is only
natively transporting IPv6. [RFC7849] already suggest the need to natively transporting IPv6. The need to support the CLAT function in
support the CLAT function in order to ensure the IPv4 service order to ensure the IPv4 service continuity in IPv6-only cellular
continuity in IPv6-only cellular deployments. deployments has been suggested in [RFC7849].
In order to do that, 464XLAT ([RFC6877]) relies on the combination of In order to do that, 464XLAT [RFC6877] relies on the combination of
existing protocols: existing protocols:
1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6 1. The CLAT is a stateless IPv4-to-IPv6 translator (NAT46) [RFC7915]
translator (NAT46) ([RFC7915]) implemented in the end-user device implemented in the end-user device or Customer Edge Router (CE),
or CE (Customer Edge Router), located at the "customer edge" of located at the "customer edge" of the network.
the network.
2. The provider-side translator (PLAT) is a stateful NAT64 2. The provider-side translator (PLAT) is a stateful NAT64
([RFC6146]), implemented typically at in the operator network. [RFC6146], implemented typically in the operator network.
3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a 3. Optionally, DNS64 [RFC6147] may allow an optimization: a single
single translation at the NAT64, instead of two translations translation at the NAT64, instead of two translations
(NAT46+NAT64), when the application at the end-user device (NAT46+NAT64), when the application at the end-user device
supports IPv6 DNS (uses AAAA Resource Records). supports IPv6 DNS (uses AAAA Resource Records).
Note that even if in the 464XLAT ([RFC6877]) terminology, the Note that even if the provider-side translator is referred to as PLAT
provider-side translator is referred as PLAT, for simplicity and in the 464XLAT terminology [RFC6877], for simplicity and uniformity
uniformity, across this document is always referred as NAT64 across this document, it is always referred to as NAT64 (function).
(function).
In this scenario (Figure 5) the service provider deploys 464XLAT with In this scenario (Figure 5), the service provider deploys 464XLAT
a DNS64 function. with a DNS64 function.
As a consequence, the DNSSEC issues remain, unless the host is doing As a consequence, the DNSSEC issues remain, unless the host is doing
the address synthesis. the address synthesis.
464XLAT ([RFC6877]) is a very simple approach to cope with the major 464XLAT [RFC6877] is a very simple approach to cope with the major
NAT64+DNS64 drawback: Not working with applications or devices that NAT64+DNS64 drawback: not working with applications or devices that
use literal IPv4 addresses or non-IPv6 compliant APIs. use literal IPv4 addresses or non-IPv6-compliant APIs.
464XLAT ([RFC6877]) has been used initially mainly in IPv6-only 464XLAT [RFC6877] has been used mainly in IPv6-only cellular
cellular networks. By supporting a CLAT function, the end-user networks. By supporting a CLAT function, end-user device
device applications can access IPv4-only end-networks/applications, applications can access IPv4-only end networks / applications,
despite those applications or devices use literal IPv4 addresses or despite the fact that those applications or devices use literal IPv4
non-IPv6 compliant APIs. addresses or non-IPv6-compliant APIs.
In addition to that, in the same example of the cellular network In addition, in the cellular network example above, if the User
above, if the User Equipment (UE) provides tethering, other devices Equipment (UE) provides tethering, other devices behind it will be
behind it will be presented with a traditional NAT44, in addition to presented with a traditional Network Address Translation from IPv4 to
the native IPv6 support, so clearly it allows IPv4-only hosts behind IPv4 (NAT44), in addition to the native IPv6 support, so clearly it
the IPv6-only access network. allows IPv4-only hosts behind the IPv6-only access network.
Furthermore, as discussed in [RFC6877], 464XLAT can be used in Furthermore, as discussed in [RFC6877], 464XLAT can be used in
broadband IPv6 network architectures, by implementing the CLAT broadband IPv6 network architectures, by implementing the CLAT
function at the CE. function at the CE.
The support of this scenario in a network, offers two additional The support of this scenario in a network offers two additional
advantages: advantages:
o DNS load optimization: A CLAT should implement a DNS proxy (as per * DNS load optimization: A CLAT should implement a DNS proxy (per
[RFC5625]), so that only IPv6 native queries and only for AAAA [RFC5625]) so that only IPv6-native queries and AAAA records are
records are sent to the DNS64 server. Otherwise doubling the sent to the DNS64 server. Otherwise, doubling the number of
number of queries may impact the DNS infrastructure. queries may impact the DNS infrastructure.
o Connection establishment delay optimization: If the UE/CE * Connection establishment delay optimization: If the UE/CE
implementation is detecting the presence of a DNS64 function, it implementation is detecting the presence of a DNS64 function, it
may issue only the AAAA query, instead of both the AAAA and A may issue only the AAAA query, instead of both the AAAA and A
queries. queries.
In order to understand all the communication possibilities, let's In order to understand all the communication possibilities, let's
assume the following representation of two dual-stack peers: assume the following representation of two dual-stack (DS) peers:
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only ) / Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ flow /\ `-----' \ flow / / \ | | \ flow /\ `-----' \ flow /
( Dual- )--+ IPv6 | \ / \ / \ / ( Dual- )--+ IPv6 | \ / \ / \ /
\ Stack / | CE | `--+--' \ .-----. / `--+--' \ Stack / | CE | `--+--' \ .-----. / `--+--'
\ Peer / | with | | \ / Remote\/ | \ Peer / | with | | \ / Remote\/ |
`-----' | CLAT | +---+----+ / \ +---+----+ `-----' | CLAT | +---+----+ / \ +---+----+
| | |DNS/IPv6| ( Dual- ) |DNS/IPv4| | | |DNS/IPv6| ( Dual- ) |DNS/IPv4|
+-------+ | with | \ Stack / +--------+ +-------+ | with | \ Stack / +--------+
| DNS64 | \ Peer / | DNS64 | \ Peer /
+--------+ `-----' +--------+ `-----'
Figure A: Representation of 464XLAT among two peers with DNS64 Figure A: Representation of 464XLAT among Two Peers with DNS64
The possible communication paths, among the IPv4/IPv6 stacks of both In this case, the possible communication paths, among the IPv4/IPv6
peers, in this case, are: stacks of both peers, are as follows:
a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among
peers. peers.
b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.
c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements EAM (Explicit Address Mappings) as indicated by implements Explicit Address Mappings (EAMs) as indicated by
Section 4.9. In principle, it is not expected that services are Section 4.9. In principle, it is not expected that services are
deployed in Internet using IPv6-only, unless there is certainty deployed in the Internet when using IPv6 only, unless there is
that peers will also be IPv6-capable. certainty that peers will also be IPv6 capable.
d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations. d. Local-IPv4 to Remote-IPv4: DNS64, CLAT, and NAT64 translations.
e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the
CLAT implements EAM as indicated by Section 4.9, instead of using CLAT implements EAM as indicated by Section 4.9, instead of using
the path d. above, NAT64 translation is avoided and the flow will the path d. above, NAT64 translation is avoided, and the flow
use IPv6 from the CLAT to the destination. will use IPv6 from the CLAT to the destination.
The rest of the figures in this section show different choices for The rest of the figures in this section show different choices for
placing the different elements. placing the different elements.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | NAT64 | | | | IPv6 | | NAT64 | | |
| + +--------+ + +--------+ IPv4 | | + +--------+ + +--------+ IPv4 |
| CLAT | | DNS64 | | | | CLAT | | DNS64 | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 5: 464XLAT with DNS64 Figure 5: 464XLAT with DNS64
A similar scenario (Figure 6) will be if the service provider offers A similar scenario (Figure 6) exists if the service provider only
only the DNS64 function, and the NAT64 function is provided by an offers the DNS64 function; the NAT64 function is provided by an
outsourcing agreement with an external provider. All the outsourcing agreement with an external provider. All the
considerations in the previous paragraphs of this section are the considerations in the previous paragraphs of this section are the
same for this sub-case. same for this sub-case.
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| extNAT64 +--------+ IPv4 | | extNAT64 +--------+ IPv4 |
| | | | | | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
| |
+----------+ +----+-----+ +----------+ +----+-----+
| IPv6 | | | | IPv6 | | |
| + +--------+ DNS64 + | + +--------+ DNS64 +
| CLAT | | | | CLAT | | |
+----------+ +----------+ +----------+ +----------+
Figure 6: 464XLAT with DNS64; NAT64 in external provider Figure 6: 464XLAT with DNS64; NAT64 in an External Provider
As well, is equivalent to the scenario (Figure 7) where the In addition, it is equivalent to the scenario (Figure 7) where the
outsourcing agreement with the external provider is to provide both outsourcing agreement with the external provider is to provide both
the NAT64 and DNS64 functions. Once more, all the considerations in the NAT64 and DNS64 functions. Once more, all the considerations in
the previous paragraphs of this section are the same for this sub- the previous paragraphs of this section are the same for this sub-
case. case.
+----------+ +----------+ +----------+ +----------+
| extNAT64 | | | | extNAT64 | | |
| + +--------+ IPv4 | | + +--------+ IPv4 |
| extDNS64 | | | | extDNS64 | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| IPv6 | | | IPv6 | |
| + +-------------+ | + +-------------+
| CLAT | | CLAT |
+----------+ +----------+
Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in an External Provider
3.1.3. Service Provider Offering 464XLAT, without DNS64 3.1.3. Service Provider Offering 464XLAT, without Using DNS64
The major advantage of this scenario (Figure 8), using 464XLAT The major advantage of this scenario (Figure 8), using 464XLAT
without DNS64, is that the service provider ensures that DNSSEC is without DNS64, is that the service provider ensures that DNSSEC is
never broken, even in case the user modifies the DNS configuration. never broken, even if the user modifies the DNS configuration.
Nevertheless, some CLAT implementations or applications may impose an Nevertheless, some CLAT implementations or applications may impose an
extra delay, which is induced by the dual A/AAAA queries (and wait extra delay, which is induced by the dual A/AAAA queries (and the
for both responses), unless Happy Eyeballs v2 ([RFC8305]) is also wait for both responses), unless Happy Eyeballs v2 [RFC8305] is also
present. present.
A possible variation of this scenario is the case when DNS64 is used A possible variation of this scenario is when DNS64 is used only for
only for the discovery of the NAT64 prefix. The rest of the document the discovery of the NAT64 prefix. In the rest of the document, it
is not considering it as a different scenario, because once the is not considered a different scenario because once the prefix has
prefix has been discovered, the DNS64 function is not used, so it been discovered, the DNS64 function is not used, so it behaves as if
behaves as if the DNS64 synthesis function is not present. the DNS64 synthesis function is not present.
In this scenario, as in the previous one, there are no issues related 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 to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only
access network, neither related to the usage of IPv4 literals or non- access network, as neither are related to the usage of IPv4 literals
IPv6 compliant APIs. or non-IPv6-compliant APIs.
The support of this scenario in a network, offers one advantage: The support of this scenario in a network offers one advantage:
o DNS load optimization: A CLAT should implement a DNS proxy (as per * DNS load optimization: A CLAT should implement a DNS proxy (per
[RFC5625]), so that only IPv6 native queries are sent to the DNS64 [RFC5625]) so that only IPv6 native queries are sent to the DNS64
server. Otherwise doubling the number of queries may impact the server. Otherwise, doubling the number of queries may impact the
DNS infrastructure. DNS infrastructure.
As indicated earlier, the connection establishment delay optimization As indicated earlier, the connection establishment delay optimization
is achieved only in the case of devices, Operating Systems, or is achieved only in the case of devices, Operating Systems, or
applications that use Happy Eyeballs v2 ([RFC8305]), which is very applications that use Happy Eyeballs v2 [RFC8305], which is very
common. common.
Let's assume the representation of two dual-stack peers as in the As in the previous case, let's assume the representation of two dual-
previous case: stack peers:
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only ) / Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ flow /\ `-----' \ flow / / \ | | \ flow /\ `-----' \ flow /
( Dual- )--+ IPv6 | \ / \ / \ / ( Dual- )--+ IPv6 | \ / \ / \ /
\ Stack / | CE | `--+--' \ .-----. / `--+--' \ Stack / | CE | `--+--' \ .-----. / `--+--'
\ Peer / | with | | \ / Remote\/ | \ Peer / | with | | \ / Remote\/ |
`-----' | CLAT | +---+----+ / \ +---+----+ `-----' | CLAT | +---+----+ / \ +---+----+
| | |DNS/IPv6| ( Dual- ) |DNS/IPv4| | | |DNS/IPv6| ( Dual- ) |DNS/IPv4|
+-------+ +--------+ \ Stack / +--------+ +-------+ +--------+ \ Stack / +--------+
\ Peer / \ Peer /
`-----' `-----'
Figure B: Representation of 464XLAT among two peers without DNS64 Figure B: Representation of 464XLAT among Two Peers without DNS64
The possible communication paths, among the IPv4/IPv6 stacks of both In this case, the possible communication paths, among the IPv4/IPv6
peers, in this case, are: stacks of both peers, are as follows:
a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among
peers. peers.
b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64 b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT, and NAT64
translations. translations.
c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements EAM as indicated by Section 4.9. In principle, it is implements EAM as indicated by Section 4.9. In principle, it is
not expected that services are deployed in Internet using not expected that services are deployed in the Internet using
IPv6-only, unless there is certainty that peers will also be IPv6 only, unless there is certainty that peers will also be
IPv6-capable. IPv6-capable.
d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT, and NAT64
translations. translations.
e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the
CLAT implements EAM as indicated by Section 4.9, instead of using CLAT implements EAM as indicated by Section 4.9, instead of using
the path d. above, NAT64 translation is avoided and the flow will the path d. above, NAT64 translation is avoided, and the flow
use IPv6 from the CLAT to the destination. will use IPv6 from the CLAT to the destination.
It needs to be noticed that this scenario works while the local Notice that this scenario works while the local hosts/applications
hosts/applications are dual-stack (which is the current situation), are dual stack (which is the current situation) because the
because the connectivity from a local-IPv6 to a remote-IPv4 is not connectivity from a local IPv6 to a remote IPv4 is not possible
possible without an AAAA synthesis. This aspect is important only without a AAAA synthesis. This aspect is important only when there
when in the LANs behind the CLAT there are IPv6-only hosts and they are IPv6-only hosts in the LANs behind the CLAT and they need to
need to communicate with remote IPv4-only hosts. However, it doesn't communicate with remote IPv4-only hosts. However, it is not a
look a sensible approach from an Operating System or application sensible approach from an Operating System or application vendor
vendor perspective, to provide IPv6-only support unless, similarly to perspective to provide IPv6-only support unless, similar to case c
case c above, there is certainty of peers supporting IPv6 as well. A above, there is certainty of peers supporting IPv6 as well. An
solution approach to this is also presented in approach to a solution for this is also presented in [OPT-464XLAT].
[I-D.palet-v6ops-464xlat-opt-cdn-caches].
The following figures show different choices for placing the The following figures show different choices for placing the
different elements. different elements.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | | | | | IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 | | + +--------+ NAT64 +--------+ IPv4 |
| CLAT | | | | | | CLAT | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
skipping to change at page 14, line 35 skipping to change at line 634
| extNAT64 +--------+ IPv4 | | extNAT64 +--------+ IPv4 |
| | | | | | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| IPv6 | | | IPv6 | |
| + +-------------+ | + +-------------+
| CLAT | | CLAT |
+----------+ +----------+
Figure 9: 464XLAT without DNS64; NAT64 in external provider Figure 9: 464XLAT without DNS64; NAT64 in an External Provider
3.2. Known to Work Under Special Conditions 3.2. Known to Work under Special Conditions
The scenarios in this category are known to not work unless The scenarios in this category are known not to work unless
significant effort is devoted to solve the issues, or are intended to significant effort is devoted to solving the issues or they are
solve problems across "closed" networks, instead of as a general intended to solve problems across "closed" networks instead of as a
Internet access usage. In addition to the different pros, cons and general Internet access usage. Even though some of the different
trade-offs, which may be acceptable for some operators, they have pros, cons, and trade-offs may be acceptable, operators have
implementation difficulties, as they are beyond the original implementation difficulties, as their expectations of NAT64/DNS64 are
expectations of the NAT64/DNS64 original intent. beyond the original intent.
3.2.1. Service Provider NAT64 without DNS64 3.2.1. Service Provider NAT64 without DNS64
In this scenario (Figure 10), the service provider offers a NAT64 In this scenario (Figure 10), the service provider offers a NAT64
function, however there is no DNS64 function support at all. function; however, there is no DNS64 function support at all.
As a consequence, an IPv6 host in the IPv6-only access network, will As a consequence, an IPv6 host in the IPv6-only access network will
not be able to detect the presence of DNS64 by means of [RFC7050], not be able to detect the presence of DNS64 by means of [RFC7050] or
neither to learn the IPv6 prefix to be used for the NAT64 function. learn the IPv6 prefix to be used for the NAT64 function.
This can be sorted out as indicated in Section 4.1.1. This can be sorted out as indicated in Section 4.1.1.
However, despite that, because the lack of the DNS64 function, the Regardless, because of the lack of the DNS64 function, the IPv6 host
IPv6 host will not be able to obtain AAAA synthesized records, so the will not be able to obtain AAAA synthesized records, so the NAT64
NAT64 function becomes useless. function becomes useless.
An exception to this "useless" scenario will be manually configure An exception to this "useless" scenario is to manually configure
mappings between the A records of each of the IPv4-only remote hosts mappings between the A records of each of the IPv4-only remote hosts
and the corresponding AAAA records, with the WKP (Well-Known Prefix) and the corresponding AAAA records with the WKP or NSP used by the
or NSP (Network-Specific Prefix) used by the service provider NAT64 service-provider NAT64 function, as if they were synthesized by a
function, as if they were synthesized by a DNS64 function. DNS64 function.
This mapping could be done by several means, typically at the This mapping could be done by several means, typically at the
authoritative DNS server, or at the service provider resolvers by authoritative DNS server or at the service-provider resolvers by
means of DNS RPZ (Response Policy Zones, [I-D.vixie-dns-rpz]) or means of DNS Response Policy Zones (RPZs) [DNS-RPZ] or equivalent
equivalent functionality. DNS RPZ, may have implications in DNSSEC, functionality. DNS RPZ may have implications in DNSSEC if the zone
if the zone is signed. Also, if the service provider is using an is signed. Also, if the service provider is using an NSP, having the
NSP, having the mapping at the authoritative server, may create mapping at the authoritative server may create troubles for other
troubles to other parties trying to use different NSP or the WKP, parties trying to use a different NSP or WKP, unless multiple DNS
unless multiple DNS "views" (split-DNS) is also being used at the "views" (split-DNS) are also being used at the authoritative servers.
authoritative servers.
Generally, the mappings alternative, will only make sense if a few Generally, the mappings alternative will only make sense if a few
set of IPv4-only remote hosts need to be accessed by a single network sets of IPv4-only remote hosts need to be accessed by a single
(or a small number of them), which support IPv6-only in the access. network (or a small number of them), which supports IPv6 only in the
This will require some kind of mutual agreement for using this access. This will require some kind of mutual agreement for using
procedure, so it doesn't care if they become a trouble for other this procedure; this should not be a problem because it won't
parties across Internet ("closed services"). interfere with Internet use (which is a "closed service").
In any case, this scenario doesn't solve the issue of IPv4 literal In any case, this scenario doesn't solve the issue of IPv4 literal
addresses or non-IPv6 compliant APIs, neither it solves the problem addresses, non-IPv6-compliant APIs, or IPv4-only hosts within that
of IPv4-only hosts within that IPv6-only access network. IPv6-only access network.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| | | | | | | | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 | | IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | | | | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 10: NAT64 without DNS64 Figure 10: NAT64 without DNS64
3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts 3.2.2. Service-Provider NAT64; DNS64 in IPv6 Hosts
In this scenario (Figure 11), the service provider offers the NAT64 In this scenario (Figure 11), the service provider offers the NAT64
function, but not the DNS64 function. However, the IPv6 hosts have a function but not the DNS64 function. However, the IPv6 hosts have a
built-in DNS64 function. built-in DNS64 function.
This may become common if the DNS64 function is implemented in all This may become common if the DNS64 function is implemented in all
the IPv6 hosts/stacks. However, commonly this is not the actual the IPv6 hosts/stacks. This is not common at the time of writing but
situation, even if it may happen in the medium-term. At this way, may become more common in the near future. This way, the DNSSEC
the DNSSEC validation is performed on the A record, and then the host validation is performed on the A record, and then the host can use
can use the DNS64 function so to be able to use the NAT64 function, the DNS64 function in order to use the NAT64 function without any
without any DNSSEC issues. DNSSEC issues.
This scenario fails to solve the issue of IPv4 literal addresses or This scenario fails to solve the issue of IPv4 literal addresses or
non-IPv6 compliant APIs, unless the IPv6 hosts also supports Happy non-IPv6-compliant APIs, unless the IPv6 hosts also support Happy
Eyeballs v2 ([RFC8305], Section 7.1), which may solve that issue. Eyeballs v2 (Section 7.1 of [RFC8305]).
However, this scenario still fails to solve the problem of IPv4-only Moreover, this scenario also fails to solve the problem of IPv4-only
hosts or applications behind the IPv6-only access network. hosts or applications behind the IPv6-only access network.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | | | | | IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 | | + +--------+ NAT64 +--------+ IPv4 |
| DNS64 | | | | | | DNS64 | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 11: NAT64; DNS64 in IPv6 hosts Figure 11: NAT64; DNS64 in IPv6 Hosts
3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network 3.2.3. Service-Provider NAT64; DNS64 in the IPv4-Only Remote Network
In this scenario (Figure 12), the service provider offers the NAT64 In this scenario (Figure 12), the service provider offers the NAT64
function only. The remote IPv4-only network offers the DNS64 function only. The IPv4-only remote network offers the DNS64
function. function.
This is not common, and looks like doesn't make too much sense that a This is not common, and it doesn't make sense that a remote network,
remote network, not deploying IPv6, is providing a DNS64 function. not deploying IPv6, is providing a DNS64 function. Like the scenario
As in the case of the scenario depicted in Section 3.2.1, it will depicted in Section 3.2.1, it will only work if both sides are using
only work if both sides are using the WKP or the same NSP, so the the WKP or the same NSP, so the same considerations apply. It can
same considerations apply. It can be also tuned to behave as in also be tuned to behave as in Section 3.1.1.
Section 3.1.1
This scenario still fails to solve the issue of IPv4 literal This scenario fails to solve the issue of IPv4 literal addresses or
addresses or non-IPv6 compliant APIs. non-IPv6-compliant APIs.
This scenario also fails to solve the problem of IPv4-only hosts or Moreover, this scenario also fails to solve the problem of IPv4-only
applications behind the IPv6-only access network. hosts or applications behind the IPv6-only access network.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| | | | | IPv4 | | | | | | IPv4 |
| IPv6 +--------+ NAT64 +--------+ + | | IPv6 +--------+ NAT64 +--------+ + |
| | | | | DNS64 | | | | | | DNS64 |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 12: NAT64; DNS64 in the IPv4-only Figure 12: NAT64; DNS64 in IPv4-Only Hosts
3.3. Comparing the Scenarios 3.3. Comparing the Scenarios
This section compares the different scenarios, including the possible This section compares the different scenarios, including possible
variations (each one represented in the precedent sections by a variations (each one represented in the previous sections by a
different figure), looking at the following criteria: different figure), while considering the following criteria:
a. DNSSEC: Are there hosts validating DNSSEC? a. DNSSEC: Are there hosts validating DNSSEC?
b. Literal/APIs: Are there applications using IPv4 literals or non- b. Literal/APIs: Are there applications using IPv4 literals or non-
IPv6 compliant APIs? IPv6-compliant APIs?
c. IPv4-only: Are there hosts or applications using IPv4-only? c. IPv4 only: Are there hosts or applications using IPv4 only?
d. Foreign DNS: Is the scenario surviving if the user, Operating d. Foreign DNS: Does the scenario survive if the user, Operating
System, applications or devices change the DNS? System, applications, or devices change the DNS?
e. DNS load opt. (DNS load optimization): Are there extra queries e. DNS load opt. (DNS load optimization): Are there extra queries
that may impact DNS infrastructure? that may impact the DNS infrastructure?
f. Connect. opt. (Connection establishment delay optimization): Is f. Connect. opt. (connection establishment delay optimization): Is
the UE/CE issuing only the AAAA query or also an A query and the UE/CE only issuing the AAAA query or also the A query and
waiting for both responses? waiting for both responses?
In the next table, the columns represent each of the scenarios from In the table below, the columns represent each of the scenarios from
the previous sections, by the figure number. The possible values the previous sections by the figure number. The possible values are
are: as follows:
o "-" Scenario "bad" for that criteria. "-" means the scenario is "bad" for that criterion.
o "+" Scenario "good" for that criteria. "+" means the scenario is "good" for that criterion.
o "*" Scenario "bad" for that criteria, however it is typically "*" means the scenario is "bad" for that criterion; however, it
resolved, with the support of Happy Eyeballs v2 ([RFC8305]). is typically resolved with the support of Happy Eyeballs v2
[RFC8305].
In some cases, "countermeasures", alternative or special In some cases, "countermeasures", alternative or special
configurations, may be available for the criteria designated as configurations, may be available for the criterion designated as
"bad". So, this comparison is considering a generic case, as a quick "bad". So, this comparison is considering a generic case as a quick
comparison guide. In some cases, a "bad" criterion is not comparison guide. In some cases, a "bad" criterion is not
necessarily a negative aspect, all it depends on the specific needs/ necessarily a negative aspect; it all depends on the specific needs/
characteristics of the network where the deployment will take place. characteristics of the network where the deployment will take place.
For instance, in a network that only has IPv6-only hosts and apps
For instance, in a network which has only IPv6-only hosts and apps using DNS and IPv6-compliant APIs, there is no impact using only
using only DNS and IPv6-compliant APIs, there is no impact using only NAT64 and DNS64, but if the hosts validate DNSSEC, that criterion is
NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is
still relevant. still relevant.
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +===============+===+===+===+===+===+===+===+===+===+====+====+====+
| DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + | | DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - | | Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - | | IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - | | Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| DNS load opt. | + | + | + | + | + | + | + | + | + | + | + | + | | DNS load opt. | + | + | + | + | + | + | + | + | + | + | + | + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Connect. opt. | + | + | + | + | + | + | + | * | * | + | + | + | | Connect. opt. | + | + | + | + | + | + | + | * | * | + | + | + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +---------------+---+---+---+---+---+---+---+---+---+----+----+----+
Figure 13: Scenario Comparison Table 1: Scenario Comparison
As a general conclusion, we should note that, if the network must As a general conclusion, we should note if the network must support
support applications using any of the following: applications using any of the following:
o IPv4 literals * IPv4 literals
o non-IPv6-compliant APIs * non-IPv6-compliant APIs
o IPv4-only hosts or applications * IPv4-only hosts or applications
Then, only the scenarios with 464XLAT, a CLAT function, or equivalent Then, only the scenarios with 464XLAT, a CLAT function, or equivalent
built-in local address synthesis features, will provide a valid built-in local address synthesis features will provide a valid
solution. Further to that, those scenarios will also keep working if solution. Furthermore, those scenarios will also keep working if the
the DNS configuration is modified. Clearly also, depending on if DNS configuration is modified. Clearly, depending on if DNS64 is
DNS64 is used or not, DNSSEC may be broken for those hosts doing used or not, DNSSEC may be broken for those hosts doing DNSSEC
DNSSEC validation. validation.
All the scenarios are good in terms of DNS load optimization, and in All the scenarios are good in terms of DNS load optimization, and in
the case of 464XLAT it may provide an extra degree of optimization. the case of 464XLAT, it may provide an extra degree of optimization.
Finally, all them are also good in terms of connection establishment Finally, all of the scenarios are also good in terms of connection
delay optimization. However, in the case of 464XLAT without DNS64, establishment delay optimization. However, in the case of 464XLAT
it requires the usage of Happy Eyeballs v2. This is not an issue, as without DNS64, the usage of Happy Eyeballs v2 is required. This is
commonly it is available in actual Operating Systems. not an issue as it is commonly available in actual Operating Systems.
4. Issues to be Considered 4. Issues to be Considered
This section reviews the different issues that an operator needs to This section reviews the different issues that an operator needs to
consider towards a NAT64/464XLAT deployment, as they may bring to consider for a NAT64/464XLAT deployment, as they may develop specific
specific decision points about how to approach that deployment. decision points about how to approach that deployment.
4.1. DNSSEC Considerations and Possible Approaches 4.1. DNSSEC Considerations and Possible Approaches
As indicated in Section 8 of [RFC6147] (DNS64, Security As indicated in the security considerations for DNS64 (see Section 8
Considerations), because DNS64 modifies DNS answers and DNSSEC is of [RFC6147]) because DNS64 modifies DNS answers and DNSSEC is
designed to detect such modifications, DNS64 may break DNSSEC. designed to detect such modifications, DNS64 may break DNSSEC.
If a device connected to an IPv6-only access network, queries for a When a device connected to an IPv6-only access network queries for a
domain name in a signed zone, by means of a recursive name server domain name in a signed zone, by means of a recursive name server
that supports DNS64, and the result is a synthesized AAAA record, and that supports DNS64, the result may be a synthesized AAAA record. In
the recursive name server is configured to perform DNSSEC validation that case, if the recursive name server is configured to perform
and has a valid chain of trust to the zone in question, it will DNSSEC validation and has a valid chain of trust to the zone in
cryptographically validate the negative response from the question, it will cryptographically validate the negative response
authoritative name server. This is the expected DNS64 behavior: The from the authoritative name server. This is the expected DNS64
recursive name server actually "lies" to the client device. However, behavior: the recursive name server actually "lies" to the client
in most of the cases, the client will not notice it, because device. However, in most of the cases, the client will not notice
generally, they don't perform validation themselves and instead, rely it, because generally, they don't perform validation themselves;
on the recursive name servers. instead, they rely on the recursive name servers.
A validating DNS64 resolver in fact, increase the confidence on the In fact, a validating DNS64 resolver increases the confidence on the
synthetic AAAA, as it has validated that a non-synthetic AAAA for synthetic AAAA, as it has validated that a non-synthetic AAAA doesn't
sure, doesn't exists. However, if the client device is exist. However, if the client device is oblivious to NAT64 (the most
NAT64-oblivious (most common case) and performs DNSSEC validation on common case) and performs DNSSEC validation on the AAAA record, it
the AAAA record, it will fail as it is a synthesized record. will fail as it is a synthesized record.
The best possible scenario from DNSSEC point of view, is when the The best possible scenario from a DNSSEC point of view is when the
client requests the DNS64 server to perform the DNSSEC validation (by client requests that the DNS64 server perform the DNSSEC validation
setting the DO bit to 1 and the CD bit to 0). In this case, the (by setting the DNSSEC OK (DO) bit to 1 and the CD bit to 0). In
DNS64 server validates the data, thus tampering may only happen this case, the DNS64 server validates the data; thus, tampering may
inside the DNS64 server (which is considered as a trusted part, thus only happen inside the DNS64 server (which is considered as a trusted
its likelihood is low) or between the DNS64 server and the client. part, thus, its likelihood is low) or between the DNS64 server and
All other parts of the system (including transmission and caching) the client. All other parts of the system (including transmission
are protected by DNSSEC ([Threat-DNS64]). and caching) are protected by DNSSEC [Threat-DNS64].
Similarly, if the client querying the recursive name server is Similarly, if the client querying the recursive name server is
another name server configured to use it as a forwarder, and is another name server configured to use it as a forwarder, and it is
performing DNSSEC validation, it will also fail on any synthesized performing DNSSEC validation, it will also fail on any synthesized
AAAA record. AAAA record.
All those considerations are extensively covered in Sections 3, 5.5 All those considerations are extensively covered in Sections 3, 5.5,
and 6.2 of [RFC6147]. and 6.2 of [RFC6147].
A solution to avoid DNSSEC issues, will be that all the signed zones DNSSEC issues could be avoided if all the signed zones provide IPv6
also provide IPv6 connectivity, together with the corresponding AAAA connectivity together with the corresponding AAAA records. However,
records. However, this is out of the control of the operator needing this is out of the control of the operator needing to deploy a NAT64
to deploy a NAT64 function. This has been proposed already in function. This has been proposed already in [DNS-DNSSEC].
[I-D.bp-v6ops-ipv6-ready-dns-dnssec].
An alternative solution, which was the one considered while An alternative solution, which was considered while developing
developing [RFC6147], is that validators will be DNS64-aware, so [RFC6147], is that the validators will be DNS64 aware. Then, they
could perform the necessary discovery and do their own synthesis. can perform the necessary discovery and do their own synthesis.
That was done under the expectation that it was sufficiently early in Since that was standardized sufficiently early in the validator
the validator-deployment curve that it would be ok to break certain deployment curve, the expectation was that it would be okay to break
DNSSEC assumptions for networks who were really stuck in a NAT64/ certain DNSSEC assumptions for networks that were stuck and really
DNS64-needing world. needing NAT64/DNS64.
As already indicated, the scenarios in the previous section, are in As already indicated, the scenarios in the previous section are
fact somehow simplified, looking at the worst possible case. Saying simplified to look at the worst possible case and for the most
it in a different way: "trying to look for the most perfect perfect approach. A DNSSEC breach will not happen if the end host is
approach". DNSSEC breach will not happen if the end-host is not not doing validation.
doing validation.
Existing previous studies seems to indicate that the figures of The figures in previous studies indicate that DNSSEC broken by using
DNSSEC actually broken by using DNS64 will be around 1.7% DNS64 makes up about 1.7% [About-DNS64] of the cases. However, we
([About-DNS64]) of the cases. However, we can't negate that this may can't negate that this may increase as DNSSEC deployment grows.
increase, as DNSSEC deployment grows. Consequently, a decision point Consequently, a decision point for the operator must depend on the
for the operator must depend on "do I really care for that percentage following question: Do I really care about that percentage of cases
of cases and the impact in my helpdesk or can I provide alternative and the impact on my help desk, or can I provide alternative
solutions for them?". Some possible solutions may be taken, as solutions for them? Some possible solutions may be exist, as
depicted in the next sections. depicted in the next sections.
4.1.1. Not using DNS64 4.1.1. Not Using DNS64
A solution will be to avoid using DNS64, but as already indicated One solution is to avoid using DNS64, but as already indicated, this
this is not possible in all the scenarios. is not possible in all the scenarios.
The use of DNS64 is a key component for some networks, in order to The use of DNS64 is a key component for some networks, in order to
comply with traffic performance metrics, monitored by some comply with traffic performance metrics, monitored by some
governmental bodies and other institutions ([FCC], [ARCEP]). governmental bodies and other institutions [FCC] [ARCEP].
One drawback of not having a DNS64 at the network side, is that is One drawback of not having a DNS64 on the network side is that it's
not possible to heuristically discover the NAT64 ([RFC7050]). not possible to heuristically discover NAT64 [RFC7050].
Consequently, an IPv6 host behind the IPv6-only access network, will Consequently, an IPv6 host behind the IPv6-only access network will
not be able to detect the presence of the NAT64 function, neither to not be able to detect the presence of the NAT64 function, nor learn
learn the IPv6 prefix to be used for it, unless it is configured by the IPv6 prefix to be used for it, unless it is configured by
alternative means. alternative means.
The discovery of the IPv6 prefix could be solved, as described in The discovery of the IPv6 prefix could be solved, as described in
[RFC7050], by means of adding the relevant AAAA records to the [RFC7050], by means of adding the relevant AAAA records to the
ipv4only.arpa. zone, of the service provider recursive servers, i.e., ipv4only.arpa. zone of the service-provider recursive servers, i.e.,
if using the WKP (64:ff9b::/96): if using the WKP (64:ff9b::/96):
ipv4only.arpa. SOA . . 0 0 0 0 0 ipv4only.arpa. SOA . . 0 0 0 0 0
ipv4only.arpa. NS . ipv4only.arpa. NS .
ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 ipv4only.arpa. AAAA 64:ff9b::192.0.0.170
ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171
ipv4only.arpa. A 192.0.0.170 ipv4only.arpa. A 192.0.0.170
ipv4only.arpa. A 192.0.0.171 ipv4only.arpa. A 192.0.0.171
An alternative option to the above, is the use of DNS RPZ An alternative option is the use of DNS RPZ [DNS-RPZ] or equivalent
([I-D.vixie-dns-rpz]) or equivalent functionalities. Note that this functionalities. Note that this may impact DNSSEC if the zone is
may impact DNSSEC if the zone is signed. signed.
One more alternative, only valid in environments with PCP support Another alternative, only valid in environments with support from the
(for both the hosts or CEs and for the service provider network), is Port Control Protocol (PCP) (for both the hosts or CEs and for the
to follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). service-provider network), is to follow "Discovering NAT64 IPv6
Prefixes Using the Port Control Protocol (PCP)" [RFC7225].
Other alternatives may be available in the future. All them are Other alternatives may be available in the future. All them are
extensively discussed in [RFC7051], however the deployment evolution extensively discussed in [RFC7051]; however, due to the deployment
has evolved many considerations from that document. New options are evolution, many considerations from that document have changed. New
being documented, such using Router Advertising options are being documented, such as using Router Advertising
([I-D.ietf-6man-ra-pref64]) or DHCPv6 options [PREF64] or DHCPv6 options [DHCPv6-OPTIONS].
([I-D.li-intarea-nat64-prefix-dhcp-option]).
It may be convenient the simultaneous support of several of the Simultaneous support of several of the possible approaches is
possible approaches, in order to ensure that clients with different convenient and will ensure that clients with different ways to
ways to configure the NAT64 prefix, successfully obtain it. This is configure the NAT64 prefix successfully obtain it. This is also
also convenient even if DNS64 is being used. convenient even if DNS64 is being used.
Of special relevance to this section is also Also of special relevance to this section is [IPV4ONLY-ARPA].
[I-D.cheshire-sudn-ipv4only-dot-arpa].
4.1.2. DNSSEC validator aware of DNS64 4.1.2. DNSSEC Validator Aware of DNS64
In general, by default, DNS servers with DNS64 function will not In general, by default, DNS servers with DNS64 function will not
synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the synthesize AAAA responses if the DO flag was set in the query.
query.
In this case, as only an A record is available, if a CLAT function is In this case, since only an A record is available, if a CLAT function
present, it means that the CLAT will take the responsibility, as in is present, the CLAT will, as in the case of literal IPv4 addresses,
the case of literal IPv4 addresses, to keep that traffic flow end-to- keep that traffic flow end to end as IPv4 so DNSSEC is not broken.
end as IPv4, so DNSSEC is not broken.
However, this will not work if a CLAT function is not present as the However, this will not work if a CLAT function is not present because
hosts will not be able to use IPv4 (which is the case for all the the hosts will not be able to use IPv4 (which is the case for all the
scenarios without 464XLAT). scenarios without 464XLAT).
4.1.3. Stub validator 4.1.3. Stub Validator
If the DO flag is set and the client device performs DNSSEC If the DO flag is set and the client device performs DNSSEC
validation, and the Checking Disabled (CD) flag is set for a query, validation, and the Checking Disabled (CD) flag is set for a query,
the DNS64 recursive server will not synthesize AAAA responses. In the DNS64 recursive server will not synthesize AAAA responses. In
this case, the client could perform the DNSSEC validation with the A this case, the client could perform the DNSSEC validation with the A
record and then synthesize the AAAA ([RFC6052]). For that to be record and then synthesize the AAAA responses [RFC6052]. For that to
possible, the client must have learned beforehand the NAT64 prefix be possible, the client must have learned the NAT64 prefix beforehand
using any of the available methods ([RFC7050], [RFC7225], using any of the available methods (see [RFC7050], [RFC7225],
[I-D.ietf-6man-ra-pref64], [PREF64], and [DHCPv6-OPTIONS]). This allows the client device to
[I-D.li-intarea-nat64-prefix-dhcp-option]). This allows the client avoid using the DNS64 function and still use NAT64 even with DNSSEC.
device to avoid using the DNS64 function and still use NAT64 even
with DNSSEC.
If the end-host is IPv4-only, this will not work if a CLAT function If the end host is IPv4 only, this will not work if a CLAT function
is not present (scenarios without 464XLAT). is not present (which is the case for all scenarios without 464XLAT).
Some devices or Operating Systems may implement, instead of a CLAT, Instead of a CLAT, some devices or Operating Systems may implement an
an equivalent function by using Bump-in-the-Host ([RFC6535]), equivalent function by using Bump-in-the-Host [RFC6535] as part of
implemented as part of Happy Eyeballs v2 (Section 7.1 of [RFC8305]). Happy Eyeballs v2 (see Section 7.1 of [RFC8305]). In this case, the
In this case, the considerations in the above paragraphs are also considerations in the above paragraphs are also applicable.
applicable.
4.1.4. CLAT with DNS proxy and validator 4.1.4. CLAT with DNS Proxy and Validator
If a CE includes CLAT support and also a DNS proxy, as indicated in If a CE includes CLAT support and also a DNS proxy, as indicated in
Section 6.4 of [RFC6877], the CE could behave as a stub validator on Section 6.4 of [RFC6877], the CE could behave as a stub validator on
behalf of the client devices. Then, following the same approach behalf of the client devices. Then, following the same approach
described in the Section 4.1.3, the DNS proxy actually will "lie" to described in Section 4.1.3, the DNS proxy will actually "lie" to the
the client devices, which in most of the cases will not notice it, client devices, which, in most cases, will not be noticed unless they
unless they perform validation by themselves. Again, this allow the perform validation by themselves. Again, this allows the client
client devices to avoid using the DNS64 function and still use NAT64 devices to avoid the use of the DNS64 function but to still use NAT64
with DNSSEC. with DNSSEC.
Once more, this will not work without a CLAT function (scenarios Once more, this will not work without a CLAT function (which is the
without 464XLAT). case for all scenarios without 464XLAT).
4.1.5. ACL of clients 4.1.5. ACL of Clients
In cases of dual-stack clients, the AAAA queries typically take In cases of dual-stack clients, AAAA queries typically take
preference over A queries. If DNS64 is enabled for those clients, preference over A queries. If DNS64 is enabled for those clients, it
will never get A records, even for IPv4-only servers. will never get A records, even for IPv4-only servers.
As a consequence, in cases where there are IPv4-only servers, and As a consequence, in cases where there are IPv4-only servers, and
those are located in the path before the NAT64 function, the clients 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 will not be able to reach them. If DNSSEC is being used for all
those flows, specific addresses or prefixes can be left-out of the those flows, specific addresses or prefixes can be left out of the
DNS64 synthesis by means of ACLs. DNS64 synthesis by means of Access Control Lists (ACLs).
Once more, this will not work without a CLAT function (scenarios Once more, this will not work without a CLAT function (which is the
without 464XLAT). case for all scenarios without 464XLAT).
4.1.6. Mapping-out IPv4 addresses 4.1.6. Mapping Out IPv4 Addresses
If there are well-known specific IPv4 addresses or prefixes using If there are well-known specific IPv4 addresses or prefixes using
DNSSEC, they can be mapped-out of the DNS64 synthesis. DNSSEC, they can be mapped out of the DNS64 synthesis.
Even if this is not related to DNSSEC, this "mapping-out" feature is Even if this is not related to DNSSEC, this "mapping-out" feature is
actually, quite commonly used to ensure that [RFC1918] addresses (for quite commonly used to ensure that addresses [RFC1918] (for example,
example used by LAN servers) are not synthesized to AAAA. used by LAN servers) are not synthesized to AAAA.
Once more, this will not work without a CLAT function (scenarios Once more, this will not work without a CLAT function (which is the
without 464XLAT). case for all scenarios without 464XLAT).
4.2. DNS64 and Reverse Mapping 4.2. DNS64 and Reverse Mapping
When a client device, using DNS64 tries to reverse-map a synthesized When a client device using DNS64 tries to reverse-map a synthesized
IPv6 address, the name server responds with a CNAME record pointing IPv6 address, the name server responds with a CNAME record that
the domain name used to reverse-map the synthesized IPv6 address (the points the domain name used to reverse-map the synthesized IPv6
one under ip6.arpa), to the domain name corresponding to the embedded address (the one under ip6.arpa) to the domain name corresponding to
IPv4 address (under in-addr.arpa). the embedded IPv4 address (under in-addr.arpa).
This is the expected behavior, so no issues need to be considered This is the expected behavior, so no issues need to be considered
regarding DNS reverse mapping. regarding DNS reverse mapping.
4.3. Using 464XLAT with/without DNS64 4.3. Using 464XLAT with/without DNS64
In the case the client device is IPv6-only (either because the stack In case the client device is IPv6 only (either because the stack or
or application is IPv6-only, or because it is connected via an application is IPv6 only or because it is connected via an IPv6-only
IPv6-only LAN) and the remote server is IPv4-only (either because the LAN) and the remote server is IPv4 only (either because the stack is
stack is IPv4-only, or because it is connected via an IPv4-only LAN), IPv4 only or because it is connected via an IPv4-only LAN), only
only NAT64 combined with DNS64 will be able to provide access among NAT64 combined with DNS64 will be able to provide access between
both. Because DNS64 is then required, DNSSEC validation will be only both. Because DNS64 is then required, DNSSEC validation will only be
possible if the recursive name server is validating the negative possible if the recursive name server is validating the negative
response from the authoritative name server and the client is not response from the authoritative name server, and the client is not
performing validation. performing validation.
Note that is not expected at this stage of the transition, that Note that at this stage of the transition, it is not expected that
applications, devices or Operating Systems are IPv6-only. It will applications, devices, or Operating Systems are IPv6 only. It will
not be a sensible decision for a developer to work on that direction, not be a sensible decision for a developer to work on that direction,
unless it is clear that the deployment scenario fully supports it. unless it is clear that the deployment scenario fully supports it.
On the other hand, an end-user or enterprise network may decide to On the other hand, an end user or enterprise network may decide to
run IPv6-only in the LANs. In case there is any chance for run IPv6 only in the LANs. In case there is any chance for
applications to be IPv6-only, the Operating System may be responsible applications to be IPv6 only, the Operating System may be responsible
either for doing a local address synthesis, or alternatively, setting for either doing a local address synthesis or setting up some kind of
up some kind of on-demand VPN (IPv4-in-IPv6), which need to be on-demand VPN (IPv4-in-IPv6), which needs to be supported by that
supported by that network. This may become very common in enterprise network. This may become very common in enterprise networks, where
networks, where "Unique IPv6 Prefix per Host" [RFC8273] is supported. "Unique IPv6 Prefix per Host" [RFC8273] is supported.
However, when the client device is dual-stack and/or connected in a However, when the client device is dual stack and/or connected in a
dual-stack LAN by means of a CLAT function (or has a built-in CLAT dual-stack LAN by means of a CLAT function (or has a built-in CLAT
function), DNS64 is an option. function), DNS64 is an option.
1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if 1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if
using literal IPv4 addresses or non-IPv6 compliant APIs) will not using literal IPv4 addresses or non-IPv6-compliant APIs) will not
use the CLAT, so will use the IPv6 path and only one translation use the CLAT and will instead use the IPv6 path, so only one
will be done at the NAT64. This may break DNSSEC, unless translation will be done at the NAT64. This may break DNSSEC,
measures as described in the precedent sections are taken. unless measures as described in the previous sections are taken.
2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will
make use of the CLAT, so two translations are required (NAT46 at make use of the CLAT, so two translations are required (NAT46 at
the CLAT and NAT64 at the PLAT), which adds some overhead in the CLAT and NAT64 at the PLAT), which adds some overhead in
terms of the extra NAT46 translation. However, this avoids the terms of the extra NAT46 translation. However, this avoids the
AAAA synthesis and consequently will never break DNSSEC. AAAA synthesis and consequently will never break DNSSEC.
Note that the extra translation, when DNS64 is not used, takes place Note that the extra translation, when DNS64 is not used, takes place
at the CLAT, which means no extra overhead for the operator. It at the CLAT, which means no extra overhead for the operator.
however adds potential extra delays to establish the connections, and However, it adds potential extra delays to establish the connections
no perceptible impact for a CE in a broadband network, while it may and has no perceptible impact for a CE in a broadband network, but it
have some impact in a battery powered device. This cost for a may have some impact on a battery-powered device. The cost for a
battery powered device, is possibly comparable to the cost when the battery-powered device is possibly comparable to the cost when the
device is doing a local address synthesis (see Section 7.1 of device is doing a local address synthesis (see Section 7.1 of
[RFC8305]). [RFC8305]).
4.4. Foreign DNS 4.4. Foreign DNS
Clients, devices or applications in a service provider network, may Clients, devices, or applications in a service-provider network may
use DNS servers from other networks. This may be the case either if use DNS servers from other networks. This may be the case if
individual applications use their own DNS server, the Operating individual applications use their own DNS server, the Operating
System itself or even the CE, or combinations of the above. System itself or even the CE, or combinations of the above.
Those "foreign" DNS servers may not support DNS64, which as a Those "foreign" DNS servers may not support DNS64; as a consequence,
consequence, will mean that those scenarios that require a DNS64 may those scenarios that require a DNS64 may not work. However, if a
not work. However, if a CLAT function is available, the CLAT function is available, the considerations in Section 4.3 will
considerations in Section 4.3 will apply. apply.
In the case that the foreign DNS supports the DNS64 function, we may If the foreign DNS supports the DNS64 function, incorrect
be in the situation of providing incorrect configurations parameters, configuration parameters may be provided that, for example, cause WKP
for example, un-matching WKP or NSP, or a case such the one described or NSP to become unmatched or result in a case such as the one
in Section 3.2.3. described in Section 3.2.3.
Having a CLAT function, even if using foreign DNS without a DNS64 Having a CLAT function, even if using foreign DNS without a DNS64
function, ensures that everything will work, so the CLAT must be function, ensures that everything will work, so the CLAT must be
considered as an advantage even against user configuration errors. considered to be an advantage despite user configuration errors. As
a result, all the traffic will use a double translation (NAT46 at the
The cost of this, is that all the traffic will use a double CLAT and NAT64 at the operator network), unless there is support for
translation (NAT46 at the CLAT and NAT64 at the operator network), EAM (Section 4.9).
unless there is support for EAM (Section 4.9).
An exception to that is the case when there is a CLAT function at the An exception is the case where there is a CLAT function at the CE
CE, which is not able to obtain the correct configuration parameters that is not able to obtain the correct configuration parameters
(again, un-matching WKP or NSP). (again, causing WKP or NSP to become unmatched).
However, it needs to be emphasized, that if there is not a CLAT However, it needs to be emphasized that if there is no CLAT function
function (scenarios without 464XLAT), an external DNS without DNS64 (which is the case for all scenarios without 464XLAT), an external
support, will disallow any access to IPv4-only destination networks, DNS without DNS64 support will disallow any access to IPv4-only
and will not guarantee the correct DNSSEC validation, so will behave destination networks and will not guarantee the correct DNSSEC
as in the Section 3.2.1. validation, so it will behave as in Section 3.2.1.
In summary, it can be said, that the consequences of the use of In summary, the consequences of using foreign DNS depends on each
foreign DNS depend very much in each specific case. However, in specific case. However, in general, if a CLAT function is present,
general, if a CLAT function is present, most of the time, there will most of the time there will not be any issues. In the other cases,
not be any. In the other cases, generally, the access to the access to IPv6-enabled services is still guaranteed for
IPv6-enabled services is still guaranteed for IPv6-enabled hosts, but IPv6-enabled hosts, but it is not guaranteed for IPv4-only hosts nor
not for IPv4-only hosts, neither the access to IPv4-only services for is the access to IPv4-only services for any hosts in the network.
any hosts in the network.
The causes of "foreign DNS" could be classified in three main The causes of "foreign DNS" could be classified in three main
categories, as depicted in the following sub-sections. categories, as depicted in the following subsections.
4.4.1. Manual Configuration of DNS 4.4.1. Manual Configuration of DNS
It is becoming increasingly common that end-users or even devices or It is becoming increasingly common that end users, or even devices or
applications configure alternative DNS in their Operating Systems, applications, configure alternative DNS in their Operating Systems
and sometimes in CEs. and sometimes in CEs.
4.4.2. DNS Privacy/Encryption Mechanisms 4.4.2. DNS Privacy/Encryption Mechanisms
Clients or applications may use mechanisms for DNS privacy/ Clients or applications may use mechanisms for DNS privacy/
encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS encryption, such as DNS over TLS (DoT) [RFC7858], DNS over DTLS
([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC [RFC8094], DNS queries over HTTPS (DoH) [RFC8484], or DNS over QUIC
([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH (DoQ) [QUIC-CONNECTIONS].
and DoQ.
Those DNS privacy/encryption options, currently are typically Currently, those DNS privacy/encryption options are typically
provided by the applications, not the Operating System vendors. At provided by the applications, not the Operating System vendors. At
the time of writing this document, at least DoT and DoH standards the time this document was written, the DoT and DoH standards have
have declared DNS64 (and consequently NAT64) out of their scope, so declared DNS64 (and consequently NAT64) out of their scope, so an
an application using them may break NAT64, unless a correctly application using them may break NAT64, unless a correctly configured
configured CLAT function is used. CLAT function is used.
4.4.3. Split DNS and VPNs 4.4.3. Split DNS and VPNs
When networks or hosts use "split-DNS" (also called Split Horizon, When networks or hosts use "split-DNS" (also called Split Horizon,
DNS views or private DNS), the successful use of the DNS64 is not DNS views, or private DNS), the successful use of DNS64 is not
guaranteed. Section 4 of [RFC6950], analyses this case. guaranteed. This case is analyzed in Section 4 of [RFC6950].
A similar situation may happen in case of VPNs that force all the DNS A similar situation may happen with VPNs that force all the DNS
queries through the VPN, ignoring the operator DNS64 function. queries through the VPN and ignore the operator DNS64 function.
4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 4.5. Well-Known Prefix (WKP) vs. Network-Specific Prefix (NSP)
Section 3 of [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), Section 3 of "IPv6 Addressing of IPv4/IPv6 Translator" [RFC6052]
discusses some considerations which are useful to decide if an discusses some considerations that are useful to an operator when
operator should use the WKP or an NSP. deciding if a WKP or an NSP should be used.
Taking in consideration that discussion and other issues, we can Considering that discussion and other issues, we can summarize the
summarize the possible decision points as: possible decision points to as follows:
a. The WKP MUST NOT be used to represent non-global IPv4 addresses. a. The WKP MUST NOT be used to represent non-global IPv4 addresses.
If this is required because the network to be translated use non- If this is required because the network to be translated uses
global addresses, then an NSP is required. non-global addresses, then an NSP is required.
b. The WKP MAY appear in inter-domain routing tables, if the b. The WKP MAY appear in interdomain routing tables, if the operator
operator provides a NAT64 function to peers. However, in this provides a NAT64 function to peers. However, in this case,
case, special considerations related to BGP filtering are special considerations related to BGP filtering are required, and
required and IPv4-embedded IPv6 prefixes longer than the WKP MUST IPv4-embedded IPv6 prefixes longer than the WKP MUST NOT be
NOT be advertised (or accepted) in BGP. An NSP may be a more advertised (or accepted) in BGP. An NSP may be a more
appropriate option in those cases. appropriate option in those cases.
c. If several NAT64 use the same prefix, packets from the same flow c. If several NAT64s use the same prefix, packets from the same flow
may be routed to different NAT64 in case of routing changes. may be routed to a different NAT64 in case of routing changes.
This can be avoided either by using different prefixes for each This can be avoided by either using different prefixes for each
NAT64 function, or by ensuring that all the NAT64 coordinate NAT64 function or ensuring that all the NAT64s coordinate their
their state. Using an NSP could simplify that. state. Using an NSP could simplify that.
d. If DNS64 is required and users, devices, Operating Systems or d. If DNS64 is required and users, devices, Operating Systems, or
applications may change their DNS configuration, and deliberately applications may change their DNS configuration and deliberately
choose an alternative DNS64 function, most probably alternative choose an alternative DNS64 function, the alternative DNS64 will
DNS64 will use by default the WKP. In that case, if an NSP is most likely use the WKP by default. In that case, if an NSP is
used by the NAT64 function, clients will not be able to use the used by the NAT64 function, clients will not be able to use the
operator NAT64 function, which will break connectivity to operator NAT64 function, which will break connectivity to
IPv4-only destinations. IPv4-only destinations.
4.6. IPv4 literals and non-IPv6 Compliant APIs 4.6. IPv4 Literals and Non-IPv6-Compliant APIs
A host or application using literal IPv4 addresses or older APIs, A host or application using literal IPv4 addresses or older APIs,
which aren't IPv6 compliant, behind a network with IPv6-only access, which aren't IPv6 compliant, behind a network with IPv6-only access
will not work unless any of the following alternatives is provided: will not work unless any of the following alternatives are provided:
o CLAT (or equivalent function). * CLAT (or an equivalent function).
o Happy Eyeballs v2 (Section 7.1, [RFC8305]). * Happy Eyeballs v2 (Section 7.1 of [RFC8305]).
o Bump-in-the-Host ([RFC6535]) with a DNS64 function. * Bump-in-the-Host [RFC6535] with a DNS64 function.
Those alternatives will solve the problem for an end-host. However, Those alternatives will solve the problem for an end host. However,
if that end-hosts is providing "tethering" or an equivalent service if the end host is providing "tethering" or an equivalent service to
to other hosts, that needs to be considered as well. In other words, other hosts, that needs to be considered as well. In other words, in
in a case of a cellular network, it resolves the issue for the UE a cellular network, these alternatives resolve the issue for the UE
itself, but may be not the case for hosts behind it. itself, but this may not be the case for hosts connected via the
tethering.
Otherwise, the support of 464XLAT is the only valid and complete Otherwise, the support of 464XLAT is the only valid and complete
approach to resolve this issue. approach to resolve this issue.
4.7. IPv4-only Hosts or Applications 4.7. IPv4-Only Hosts or Applications
An IPv4-only hosts or application behind a network with IPv6-only IPv4-only hosts or an application behind a network with IPv6-only
access, will not work unless a CLAT function is present. access will not work unless a CLAT function is present.
464XLAT is the only valid approach to resolve this issue. 464XLAT is the only valid approach to resolve this issue.
4.8. CLAT Translation Considerations 4.8. CLAT Translation Considerations
As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if As described in "IPv6 Prefix Handling" (see Section 6.3 of
the CLAT function can be configured with a dedicated /64 prefix for [RFC6877]), if the CLAT function can be configured with a dedicated
the NAT46 translation, then it will be possible to do a more /64 prefix for the NAT46 translation, then it will be possible to do
efficient stateless translation. a more efficient stateless translation.
Otherwise, if this dedicated prefix is not available, the CLAT Otherwise, if this dedicated prefix is not available, the CLAT
function will need to do a stateful translation, for example function will need to do a stateful translation, for example, perform
performing stateful NAT44 for all the IPv4 LAN packets, so they stateful NAT44 for all the IPv4 LAN packets so they appear as coming
appear as coming from a single IPv4 address, and then in turn, from a single IPv4 address; in turn, the CLAT function will perform a
stateless translated to a single IPv6 address. stateless translation to a single IPv6 address.
A possible setup, in order to maximize the CLAT performance, is to A possible setup, in order to maximize the CLAT performance, is to
configure the dedicated translation prefix. This can be easily configure the dedicated translation prefix. This can be easily
achieved automatically, if the broadband CE or end-user device is achieved automatically, if the broadband CE or end-user device is
able to obtain a shorter prefix by means of DHCPv6-PD ([RFC8415]), or able to obtain a shorter prefix by means of DHCPv6-PD [RFC8415] or
other alternatives. The CE can then use a specific /64 for the other alternatives. The CE can then use a specific /64 for the
translation. This is also possible when broadband is provided by a translation. This is also possible when broadband is provided by a
cellular access. cellular access.
The above recommendation is often not possible for cellular networks, The above recommendation is often not possible for cellular networks,
when connecting smartphones (as UEs), as generally they don't use when connecting smartphones (as UEs): generally they don't use
DHCPv6-PD ([RFC8415]). Instead, a single /64 is provided for each DHCPv6-PD [RFC8415]. Instead, a single /64 is provided for each
PDP context and prefix sharing ([RFC6877]) is used. So, in this Packet Data Protocol (PDP) context, and prefix sharing [RFC6877] is
case, the UEs typically have a build-in CLAT function which is used. In this case, the UEs typically have a build-in CLAT function
performing a stateful NAT44 translation before the stateless NAT46. that is performing a stateful NAT44 translation before the stateless
NAT46.
4.9. EAM Considerations 4.9. EAM Considerations
Explicit Address Mappings for Stateless IP/ICMP Translation "Explicit Address Mappings for Stateless IP/ICMP Translation"
([RFC7757]) provide a way to configure explicit mappings between IPv4 [RFC7757] provides a way to configure explicit mappings between IPv4
and IPv6 prefixes of any length. When this is used, for example in a and IPv6 prefixes of any length. When this is used, for example, in
CLAT function, it may provide a simple mechanism in order to avoid a CLAT function, it may provide a simple mechanism in order to avoid
traffic flows between IPv4-only nodes or applications and dual-stack traffic flows between IPv4-only nodes or applications and dual-stack
destinations to be translated twice (NAT46 and NAT64), by creating destinations to be translated twice (NAT46 and NAT64), by creating
mapping entries with the GUA of the IPv6-reachable destination. This mapping entries with the Global Unicast Address (GUA) of the
optimization of the NAT64 usage is very useful in many scenarios, IPv6-reachable destination. This optimization of NAT64 usage is very
including CDNs and caches, as described in useful in many scenarios, including Content Delivery Networks (CDNs)
[I-D.palet-v6ops-464xlat-opt-cdn-caches]. and caches, as described in [OPT-464XLAT].
In addition to that, it may provide as well a way for IPv4-only nodes In addition, it may also provide a way for IPv4-only nodes or
or applications to communicate with IPv6-only destinations. applications to communicate with IPv6-only destinations.
4.10. Incoming Connections 4.10. Incoming Connections
The use of NAT64, in principle, disallows IPv4 incoming connections, The use of NAT64, in principle, disallows IPv4 incoming connections,
which may be still needed for IPv4-only peer-to-peer applications. which may still be needed for IPv4-only peer-to-peer applications.
However, there are several alternatives that resolve this issue: However, there are several alternatives that resolve this issue:
a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are a. Session Traversal Utilities for NAT (STUN) [RFC5389], Traversal
commonly used by peer-to-peer applications in order to allow Using Relays around NAT (TURN) [RFC5766], and Interactive
incoming connections with IPv4 NAT. In the case of NAT64, they Connectivity Establishment (ICE) [RFC8445] are commonly used by
work as well. RFC editor note: If in time, replace STUN and TURN peer-to-peer applications in order to allow incoming connections
with [I-D.ietf-tram-stunbis] / [I-D.ietf-tram-turnbis]. with IPv4 NAT. In the case of NAT64, they work as well.
b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and b. The Port Control Protocol (PCP) [RFC6887] allows a host to
IPv6 packets are translated and forwarded. A NAT64 may implement control how incoming IPv4 and IPv6 packets are translated and
PCP to allow this service. forwarded. A NAT64 may implement PCP to allow this service.
c. EAM ([RFC7757]) may also be used in order to configure explicit c. EAM [RFC7757] may also be used in order to configure explicit
mappings for customers that require them. This is used for mappings for customers that require them. This is used, for
example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]). example, by Stateless IP/ICMP Translation for IPv6 Data Center
Environments (SIIT-DC) [RFC7755] and SIIT-DC Dual Translation
Mode (SIIT-DC-DTM) [RFC7756].
5. Summary of Deployment Recommendations for NAT64/464XLAT 5. Summary of Deployment Recommendations for NAT64/464XLAT
NAT64/464XLAT has demonstrated to be a valid choice in several It has been demonstrated that NAT64/464XLAT is a valid choice in
scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the predominant several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the
mechanism in the majority of the cellular networks, which account for predominant mechanism in the majority of the cellular networks, which
hundreds of millions of users ([ISOC]). NAT64/464XLAT offer account for hundreds of millions of users [ISOC]. NAT64/464XLAT
different choices of deployment, depending on each network case, offer different choices of deployment, depending on each network
needs and requirements. Despite that, this document is not an case, needs, and requirements. Despite that, this document is not an
explicit recommendation for using this choice versus other IPv4aaS explicit recommendation for using this choice versus other IPv4aaS
transition mechanisms. Instead, this document is a guide that transition mechanisms. Instead, this document is a guide that
facilitates evaluating a possible implementation of NAT64/464XLAT and facilitates evaluating a possible implementation of NAT64/464XLAT and
key decision points about specific design considerations for its key decision points about specific design considerations for its
deployment. deployment.
Depending on the specific requirements of each deployment case, DNS64 Depending on the specific requirements of each deployment case, DNS64
may be a required function, while in other cases the adverse effects may be a required function, while in other cases, the adverse effects
may be counterproductive. Similarly, in some cases a NAT64 function, may be counterproductive. Similarly, in some cases, a NAT64
together with a DNS64 function, may be a valid solution, when there function, together with a DNS64 function, may be a valid solution
is a certainty that IPv4-only hosts or applications do not need to be when there is a certainty that IPv4-only hosts or applications do not
supported (Section 4.6 and Section 4.7). However, in other cases need to be supported (see Sections 4.6 and 4.7). However, in other
(i.e. IPv4-only devices or applications need to be supported), the cases (i.e., IPv4-only devices or applications that need to be
limitations of NAT64/DNS64, may suggest the operator to look into supported), the limitations of NAT64/DNS64 may indicate that the
464XLAT as a more complete solution. operator needs to look into 464XLAT as a more complete solution.
In the case of broadband managed networks (where the CE is provided For broadband-managed networks (where the CE is provided or
or suggested/supported by the operator), in order to fully support suggested/supported by the operator), in order to fully support the
the actual user needs (IPv4-only devices and applications, usage of actual user's needs (i.e., IPv4-only devices and applications and the
IPv4 literals and non-IPv6 compliant APIs), the 464XLAT scenario usage of IPv4 literals and non-IPv6-compliant APIs), the 464XLAT
should be considered. In that case, it must support a CLAT function. scenario should be considered. In that case, it must support a CLAT
function.
If the operator provides DNS services, in order to increase If the operator provides DNS services, they may support a DNS64
performance by reducing the double translation for all the IPv4 function to avoid, as much as possible, breaking DNSSEC. This will
traffic, they may support a DNS64 function and avoid, as much as also increase performance, by reducing the double translation for all
possible, breaking DNSSEC. In this case, if the DNS service is the IPv4 traffic. In this case, if the DNS service is offering
offering DNSSEC validation, then it must be in such way that it is DNSSEC validation, then it must be in such a way that it is aware of
aware of the DNS64. This is considered the simpler and safer the DNS64. This is considered the simpler and safer approach, and it
approach, and may be combined as well with other recommendations may be combined with other recommendations described in this
described in this document: document:
o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). * DNS infrastructure MUST be aware of DNS64 (Section 4.1.2).
o Devices running CLAT SHOULD follow the indications in * Devices running CLAT SHOULD follow the indications in "Stub
Section 4.1.3 (Stub Validator). However, this may be out of the Validator" (see Section 4.1.3). However, this may be out of the
control of the operator. control of the operator.
o CEs SHOULD include a DNS proxy and validator (Section 4.1.4). * CEs SHOULD include a DNS proxy and validator (Section 4.1.4).
o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4 * "ACL of Clients" (see Section 4.1.5) and "Mapping Out IPv4
addresses) MAY be considered by operators, depending on their own Addresses" (see Section 4.1.6) MAY be considered by operators,
infrastructure. depending on their own infrastructure.
This "increased performance" approach has the disadvantage of This "increased performance" approach has the disadvantage of
potentially breaking DNSSEC for a small percentage of validating end- potentially breaking DNSSEC for a small percentage of validating end
hosts versus the small impact of a double translation taking place in 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 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, 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 and consequently, ensure that all the IPv4 traffic is translated at
the CLAT (Section 4.3). the CLAT (Section 4.3).
If DNS64 is not used, at least one of the alternatives described in If DNS64 is not used, at least one of the alternatives described in
Section 4.1.1, must be followed in order to learn the NAT64 prefix. Section 4.1.1 must be followed in order to learn the NAT64 prefix.
The operator needs to consider that if the DNS configuration can be The operator needs to consider that if the DNS configuration is
modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most modified (see Sections 4.4, 4.4.2, and 4.4.3), which most likely
probably is impossible to avoid, there are chances that instead of cannot be avoided, a foreign non-DNS64 could be used instead of
configuring a DNS64 a foreign non-DNS64 is used. In a scenario with configuring a DNS64. In a scenario with only a NAT64 function, an
only a NAT64 function IPv4-only remote host will no longer be IPv4-only remote host will no longer be accessible. Instead, it will
accessible. Instead, it will continue to work in the case of continue to work in the case of 464XLAT.
464XLAT.
Similar considerations need to be taken regarding the usage of a Similar considerations need to be made regarding the usage of a NAT64
NAT64 WKP vs NSP (Section 4.5), as they must match with the WKP vs. NSP (Section 4.5), as they must match the configuration of
configuration of the DNS64. In case of using foreign DNS, they may DNS64. When using foreign DNS, they may not match. If there is a
not match. If there is a CLAT and the configured foreign DNS is not CLAT and the configured foreign DNS is not a DNS64, the network will
a DNS64, the network will keep working only if other means of keep working only if other means of learning the NAT64 prefix are
learning the NAT64 prefix are available. available.
As described in Section 4.8, for broadband networks, the CEs For broadband networks, as described in Section 4.8, the CEs
supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or supporting a CLAT function SHOULD support DHCPv6-PD [RFC8415] or
alternative means for configuring a shorter prefix. The CE SHOULD alternative means for configuring a shorter prefix. The CE SHOULD
internally reserve one /64 for the stateless NAT46 translation. The internally reserve one /64 for the stateless NAT46 translation. The
operator must ensure that the customers get allocated prefixes operator must ensure that the customers are allocated prefixes
shorter than /64 in order to support this optimization. One way or shorter than /64 in order to support this optimization. One way or
the other, this is not impacting the performance of the operator another, this is not impacting the performance of the operator
network. network.
Operators may follow Section 7 of [RFC6877] (Deployment Operators may follow "Deployment Considerations" (Section 7 of
Considerations), for suggestions in order to take advantage of [RFC6877]) for suggestions on how to take advantage of traffic-
traffic engineering requirements. engineering requirements.
In the case of cellular networks, the considerations regarding DNSSEC For cellular networks, the considerations regarding DNSSEC may appear
may appear as out-of-scope, because UEs Operating Systems, commonly to be out of scope because UEs' Operating Systems commonly don't
don't support DNSSEC. However, applications running on them may do, support DNSSEC. However, applications running on them may, or it may
or it may be an Operating System "built-in" support in the future. be an Operating System "built-in" support in the future. Moreover,
Moreover, if those devices offer tethering, other client devices if those devices offer tethering, other client devices behind the UE
behind the UE, may be doing the validation, hence the relevance of a may be doing the validation; hence, proper DNSSEC support by the
proper DNSSEC support by the operator network. operator network is relevant.
Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and Furthermore, cellular networks supporting 464XLAT [RFC6877] and
"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
([RFC7050]), allow a progressive IPv6 deployment, with a single APN [RFC7050] allow a progressive IPv6 deployment, with a single Access
supporting all types of PDP context (IPv4, IPv6, IPv4v6). This Point Name (APN) supporting all types of PDP context (IPv4, IPv6, and
approach allows the network to automatically serve every possible IPv4v6). This approach allows the network to automatically serve
combinations of UEs. every possible combination of UEs.
If the operator chooses to provide validation for the DNS64 prefix If the operator chooses to provide validation for the DNS64 prefix
discovery, it must follow the advice from Section 3.1. of [RFC7050] discovery, it must follow the advice from "Validation of Discovered
(Validation of Discovered Pref64::/n). Pref64::/n" (see Section 3.1 of [RFC7050]).
One last consideration, is that many networks may have a mix of One last consideration is that many networks may have a mix of
different complex scenarios at the same time, for example, customers different complex scenarios at the same time; for example, customers
requiring 464XLAT, others not requiring it, customers requiring that require 464XLAT and those that don't, customers that require
DNS64, others not, etc. In general, the different issues and the DNS64 and those that don't, etc. In general, the different issues
approaches described in this document can be implemented at the same and the approaches described in this document can be implemented at
time for different customers or parts of the network. That mix of the same time for different customers or parts of the network. That
approaches don't present any problem or incompatibility, as they work mix of approaches doesn't present any problem or incompatibility;
well together, being just a matter of appropriate and differentiated they work well together as a matter of appropriate and differentiated
provisioning. In fact, the NAT64/464XLAT approach facilitates an provisioning. In fact, the NAT64/464XLAT approach facilitates an
operator offering both cellular and broadband services, to have a operator offering both cellular and broadband services to have a
single IPv4aaS for both networks while differentiating the deployment single IPv4aaS for both networks while differentiating the deployment
key decisions to optimize each case. It even makes possible using key decisions to optimize each case. It's even possible to use
hybrid CEs that have a main broadband access link and a backup via hybrid CEs that have a main broadband access link and a backup via
the cellular network. the cellular network.
In an ideal world we could safely use DNS64, if the approach proposed In an ideal world, we could safely use DNS64 if the approach proposed
in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, avoiding the in [DNS-DNSSEC] were followed, avoiding the cases where DNSSEC may be
cases where DNSSEC may be broken. However, this will not solve the broken. However, this will not solve the issues related to DNS
issues related to DNS Privacy and Split DNS. privacy and split DNS.
The only 100% safe solution, which also resolves all the issues, will The only 100% safe solution that also resolves all the issues is, in
be, in addition to having a CLAT function, not using a DNS64 but addition to having a CLAT function, not using a DNS64 but instead
instead making sure that the hosts have a built-in address synthesis making sure that the hosts have a built-in address synthesis feature.
feature. Operators could manage to provide CEs with the CLAT Operators could manage to provide CEs with the CLAT function;
function, however the built-in address synthesis feature is out of however, the built-in address synthesis feature is out of their
their control. If the synthesis is provided either by the Operating control. If the synthesis is provided by either the Operating System
System (via its DNS resolver API) or by the application (via its own (via its DNS resolver API) or the application (via its own DNS
DNS resolver), in such way that the prefix used for the NAT64 resolver) in such way that the prefix used for the NAT64 function is
function is reachable for the host, the problem goes away. reachable for the host, the problem goes away.
Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9, Whenever feasible, using EAM [RFC7757] as indicated in Section 4.9
provides a very relevant optimization, avoiding double-translations. provides a very relevant optimization, avoiding double translations.
Applications that require incoming connections, typically already Applications that require incoming connections typically provide a
provide means for that. However, PCP and EAM, as indicated in means for that already. However, PCP and EAM, as indicated in
Section 4.10, are valid alternatives, even for creating explicit Section 4.10, are valid alternatives, even for creating explicit
mappings for customers that require them. mappings for customers that require them.
6. Deployment of 464XLAT/NAT64 in Enterprise Networks 6. Deployment of 464XLAT/NAT64 in Enterprise Networks
The recommendations of this document can be used as well in The recommendations in this document can also be used in enterprise
enterprise networks, campus and other similar scenarios (including networks, campuses, and other similar scenarios (including managed
managed end-user networks). end-user networks).
This include scenarios where the NAT64 function (and DNS64 function, This includes scenarios where the NAT64 function (and DNS64 function,
if available) are under the control of that network (or can be if available) are under the control of that network (or can be
configured manually according to that network specific requirements), configured manually according to that network's specific
and for whatever reasons, there is a need to provide "IPv6-only requirements), and there is a need to provide IPv6-only access to any
access" to any part of that network or it is IPv6-only connected to part of that network, or it is IPv6 only connected to third-party
third party-networks. networks.
An example of that is the IETF meetings network itself, where both An example is the IETF meeting network itself, where both NAT64 and
NAT64 and DNS64 functions are provided, presenting in this case the DNS64 functions are provided, presenting in this case the same issues
same issues as per Section 3.1.1. If there is a CLAT function in the as per Section 3.1.1. If there is a CLAT function in the IETF
IETF network, then there is no need to use DNS64 and it falls under network, then there is no need to use DNS64, and it falls under the
the considerations of Section 3.1.3. Both scenarios have been tested considerations of Section 3.1.3. Both scenarios have been tested and
and verified already in the IETF network itself. verified already in the IETF network.
Next figures are only meant to represent a few of the possible The following figures represent a few of the possible scenarios.
scenarios, not pretending to be the only feasible ones.
Figure 14 provides an example of an IPv6-only enterprise network Figure 13 provides an example of an IPv6-only enterprise network
connected with dual-stack to Internet and using local NAT64 and DNS64 connected with a dual stack to the Internet using local NAT64 and
functions. DNS64 functions.
+----------------------------------+ +----------------------------------+
| Enterprise Network | | Enterprise Network |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
| | IPv6 | | NAT64 | | | IPv4 | | | IPv6- | | NAT64 | | | IPv4 |
| | only +--------+ + | +-------+ + | | | only +--------+ + | +-------+ + |
| | LANs | | DNS64 | | | IPv6 | | | LANs | | DNS64 | | | IPv6 |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+
Figure 14: IPv6-only enterprise with NAT64 and DNS64 Figure 13: IPv6-Only Enterprise with NAT64 and DNS64
Figure 15 provides an example of a dual-stack (DS) enterprise network Figure 14 provides an example of a DS enterprise network connected
connected with dual-stack (DS) to Internet and using a CLAT function, with DS to the Internet using a CLAT function, without a DNS64
without a DNS64 function. function.
+----------------------------------+ +----------------------------------+
| Enterprise Network | | Enterprise Network |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
| | IPv6 | | | | | IPv4 | | | IPv6 | | | | | IPv4 |
| | + +--------+ NAT64 | +-------+ + | | | + +--------+ NAT64 | +-------+ + |
| | CLAT | | | | | IPv6 | | | CLAT | | | | | IPv6 |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+
Figure 15: DS enterprise with CLAT, DS Internet, without DNS64 Figure 14: DS Enterprise with CLAT, DS Internet, without DNS64
Finally, Figure 16 provides an example of an IPv6-only provider with Finally, Figure 15 provides an example of an IPv6-only provider with
a NAT64 function, and a dual-stack (DS) enterprise network by means a NAT64 function, and a DS enterprise network by means of their own
of their own CLAT function, without a DNS64 function. CLAT function, without a DNS64 function.
+----------------------------------+ +----------------------------------+
| Enterprise Network | | Enterprise Network |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
| | IPv6 | | | | IPv6 | | | | IPv6 | | | | IPv6 | |
| | + +--------+ CLAT | +--------+ NAT64 | | | + +--------+ CLAT | +--------+ NAT64 |
| | IPv4 | | | | only | | | | IPv4 | | | | only | |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+
Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64 Figure 15: DS Enterprise with CLAT and IPv6-Only Access, without
DNS64
7. Security Considerations 7. Security Considerations
This document does not have new specific security considerations This document does not have new specific security considerations
beyond those already reported by each of the documents cited. For beyond those already reported by each of the documents cited. For
example, DNS64 ([RFC6147]) already describes the DNSSEC issues. example, DNS64 [RFC6147] already describes the DNSSEC issues.
Note that, as already described in Section 4.4, there may be As already described in Section 4.4, note that there may be
undesirable interactions, specially if using VPNs or DNS privacy, undesirable interactions, especially if using VPNs or DNS privacy,
which may impact in the correct performance of DNS64/NAT64. which may impact the correct performance of DNS64/NAT64.
It should be remarked that the use of a DNS64 function has equivalent Note that the use of a DNS64 function has privacy considerations that
privacy considerations as in the case of a regular DNS, either are equivalent to regular DNS, and they are located in either the
located in the service provider or an external one. service provider or an external service provider.
8. IANA Considerations 8. IANA Considerations
This document does not have any new specific IANA considerations. This document has no IANA actions.
Note: This section is assuming that https://www.rfc-
editor.org/errata/eid5152 is resolved, otherwise, this section may
include the required text to resolve the issue.
Alternatively, this could be fixed also by
[I-D.cheshire-sudn-ipv4only-dot-arpa].
9. Acknowledgements
The author would like to acknowledge the inputs of Gabor Lencse,
Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed
Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson and Eric
Vyncke.
Conversations with Marcelo Bagnulo, one of the co-authors of NAT64
and DNS64, as well as several emails in mailing lists from Mark
Andrews, have been very useful for this work.
Christian Huitema inspired working in this document by suggesting
that DNS64 should never be used, during a discussion regarding the
deployment of CLAT in the IETF network.
10. ANNEX A: Example of Broadband Deployment with 464XLAT
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.
Note that an equivalent setup could also be provided for enterprise
customers. In case they need to support IPv4 inbound connections,
several mechanisms, depending on specific customer needs, allow that,
for instance [RFC7757].
Conceptually, most part of the operator network could be IPv6-only
(represented in the next pictures as "IPv6-only flow"), or even if
this part of the network is actually dual-stack, only IPv6-access is
available for some customers (i.e. residential customers). This part
of the network connects the IPv6-only subscribers (by means of
IPv6-only access links), to the IPv6 upstream providers, as well as
to the IPv4-Internet by means of the NAT64 (PLAT in the 464XLAT
terminology).
The traffic flow from and back to the CE to services available in the
IPv6 Internet (or even dual-stack remote services, when IPv6 is being
used), is purely native IPv6 traffic, so there are no special
considerations about it.
Looking at the picture from the DNS perspective, there are remote
networks with are IPv4-only, and typically will have only IPv4 DNS
(DNS/IPv4), or at least will be seen as that from the CE perspective.
At the operator side, the DNS, as seen from the CE, is only IPv6
(DNS/IPv6) and has also a DNS64 function.
In the customer LANs side, there is actually one network, which of
course could be split in different segments. The most common setup
will be those segments being dual-stack, using global IPv6 addresses
and [RFC1918] for IPv4, as usual in any regular residential/SOHO IPv4
network. In the figure, it is represented as tree segments, just to
show that the three possible setups are valid (IPv6-only, IPv4-only
and dual-stack).
.-----. +-------+ .-----. .-----.
/ 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 /
`-----'
Figure 17: CE setup with built-in CLAT with DNS64
In addition to the regular CE setup, which will be typically access-
technology dependent, the steps for the CLAT function configuration
can be summarized as:
1. Discovery of the PLAT (NAT64) prefix: It may be done using
[RFC7050], or in those networks where PCP is supported, by means
of [RFC7225], or other alternatives that may be available in the
future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or
DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]).
2. If the CLAT function allows stateless NAT46 translation, a /64
from the pool typically provided to the CE by means of DHCPv6-PD
[RFC8415], need 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 Section 4.8.
A more detailed configuration approach is described in [RFC8585].
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 [RIPE-690], in order to ensure that multiple
/64s are available, including the one needed for the NAT46 stateless
translation.
The operator needs to understand other issues, described across this
document, in order to take the relevant decisions. For example, if
several NAT64 functions are needed in the context of scalability/
high-availability, an NSP should be considered (Section 4.5).
More complex scenarios are possible, for example, if a network offers
multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.
If the operator decides not to provide a DNS64 function, then this
setup turns into the one in the following Figure. This will be also
the setup that "will be seen" from the perspective of the CE, if a
foreign DNS is used and consequently is not the operator-provided
DNS64 function.
.-----. +-------+ .-----. .-----.
/ 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 /
`-----'
Figure 18: CE setup with built-in CLAT without DNS64
In this case, the discovery of the PLAT prefix needs to be arranged
as indicated in Section 4.1.1.
In this case, the CE doesn't have a built-in CLAT function, or the
customer can choose to setup the IPv6 operator-managed CE in bridge
mode (and optionally use an external router), or for example, there
is an access technology that requires some kind of media converter
(ONT for FTTH, Cable-Modem for DOCSIS, etc.), the complete setup will
look as in Figure 19. 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.
+-------+ .-----. .-----.
| | / \ / \
| 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 /
`-----'
Figure 19: CE setup with bridged CLAT without DNS64
It should be avoided that several routers (i.e., the operator
provided CE and a downstream user provided router) enable
simultaneously routing and/or CLAT, in order to avoid multiple NAT44
and NAT46 levels, as well as ensuring the correct operation of
multiple IPv6 subnets. In those cases, it is suggested the use of
HNCP ([RFC8375]).
Note that the procedure described here for the CE setup, can be
simplified if the CE follows [RFC8585].
11. ANNEX B: CLAT Implementation
In addition to the regular set of features for a CE, a CLAT CE
implementation requires support of:
o [RFC7915] for the NAT46 function.
o [RFC7050] for the PLAT prefix discovery.
o [RFC7225] for the PLAT prefix discovery if PCP is supported.
o [I-D.ietf-6man-ra-pref64] for the PLAT prefix discovery by means
of Router Advertising.
o [I-D.li-intarea-nat64-prefix-dhcp-option] for the PLAT prefix
discovery by means of DHCP.
o If stateless NAT46 is supported, a mechanism to ensure that
multiple /64 are available, such as DHCPv6-PD [RFC8415].
There are several OpenSource implementations of CLAT, such as:
o Android: https://github.com/ddrown/android_external_android-clat.
o Jool: https://www.jool.mx.
o Linux: https://github.com/toreanderson/clatd.
o OpenWRT: https://github.com/openwrt-
routing/packages/blob/master/nat46/files/464xlat.sh.
o VPP: https://git.fd.io/vpp/tree/src/plugins/nat.
12. ANNEX C: Benchmarking
[RFC8219] has defined a benchmarking methodology for IPv6 transition
technologies. NAT64 and 464XLAT are addressed among the single and
double translation technologies, respectively. DNS64 is addressed in
Section 9, and the methodology is more elaborated in [DNS64-BM-Meth].
Several documents provide references to benchmarking results, for
example in the case of DNS64, [DNS64-Benchm].
13. ANNEX D: Changes from -00 to -01/-02
Section to be removed after WGLC. Significant updates are:
1. Text changes across all the document.
14. ANNEX E: Changes from -02 to -03
Section to be removed after WGLC. Significant updates are:
1. Added references to new cited documents.
2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only
LANs w/o DNS64.
3. Overall review and editorial changes.
15. ANNEX F: Changes from -03 to -04
Section to be removed after WGLC. Significant updates are:
1. Added text related to EAM considerations.
16. ANNEX G: Changes from -04 to -05
Section to be removed after WGLC. Significant updates are:
1. Added cross references to EAM section.
2. Reworded "foreing DNS section".
3. Overall editorial review of text, pictures and nits correction.
17. ANNEX H: Changes from -05 to -06
Section to be removed after WGLC. Significant updates are:
1. Corrected EAMT to EAM.
2. Typos and nits.
3. New considerations regarding incoming connections.
18. ANNEX H: Changes from -06 to -07
Section to be removed after WGLC. Significant updates are:
1. Inputs/clarifications from IESG review.
19. References 9. References
19.1. Normative References 9.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
and E. Lear, "Address Allocation for Private Internets", J., and E. Lear, "Address Allocation for Private
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
<https://www.rfc-editor.org/info/rfc1918>. February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>. <https://www.rfc-editor.org/info/rfc5389>.
skipping to change at page 42, line 15 skipping to change at line 1648
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
19.2. Informative References 9.2. Informative References
[About-DNS64] [About-DNS64]
Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016, Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", June
<https://blog.apnic.net/2016/06/09/ 2016, <https://blog.apnic.net/2016/06/09/lets-talk-
lets-talk-ipv6-dns64-dnssec/>. ipv6-dns64-dnssec/>.
[ARCEP] ARCEP, "Service client des operateurs : les mesures de [ARCEP] ARCEP, "Service client des operateurs : les mesures de
qualite de service", 2018, <https://www.arcep.fr/ qualite de service", April 2018, <https://www.arcep.fr/
cartes-et-donnees/nos-publications-chiffrees/ cartes-et-donnees/nos-publications-chiffrees/service-
service-client-des-operateurs-mesures-de-la-qualite-de- client-des-operateurs-mesures-de-la-qualite-de-service/
service/service-client-des-operateurs-les-mesures-de- service-client-des-operateurs-les-mesures-de-qualite-de-
qualite-de-service.html>. service.html>.
[DHCPv6-OPTIONS]
Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet,
"DHCPv6 Options for Discovery NAT64 Prefixes", Work in
Progress, Internet-Draft, draft-li-intarea-nat64-prefix-
dhcp-option-02, 20 April 2019,
<https://tools.ietf.org/html/draft-li-intarea-nat64-
prefix-dhcp-option-02>.
[DNS-DNSSEC]
Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC
Infrastructure", Work in Progress, Internet-Draft, draft-
bp-v6ops-ipv6-ready-dns-dnssec-00, 10 October 2018,
<https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-
dns-dnssec-00>.
[DNS-RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones
(RPZ)", Work in Progress, Internet-Draft, draft-vixie-
dnsop-dns-rpz-00, 23 June 2018,
<https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz-
00>.
[DNS64-Benchm] [DNS64-Benchm]
Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64
Implementations: Theory and Practice", Computer Implementations: Theory and Practice", pp. 61-74, no. 1,
Communications , vol. 127, no. 1, pp. 61-74, vol. 127, Computer Communications,
DOI 10.1016/j.comcom.2018.05.005, September 2018. DOI 10.1016/j.comcom.2018.05.005, September 2018,
<https://www.sciencedirect.com/science/article/pii/
S0140366418302184?via%3Dihub>.
[DNS64-BM-Meth] [DNS64-BM-Meth]
Lencse, G., Georgescu, M., and Y. Kadobayashi, Lencse, G., Georgescu, M., and Y. Kadobayashi,
"Benchmarking Methodology for DNS64 Servers", Computer "Benchmarking Methodology for DNS64 Servers", pp. 162-175,
Communications , vol. 109, no. 1, pp. 162-175, no. 1, vol. 109, Computer Communications,
DOI 10.1016/j.comcom.2017.06.004, September 2017. DOI 10.1016/j.comcom.2017.06.004, September 2017,
<https://www.sciencedirect.com/science/article/pii/
S0140366416305904?via%3Dihub>.
[FCC] FCC, "Measuring Broadband America Mobile 2013-2018 [FCC] FCC, "Measuring Broadband America Mobile 2013-2018
Coarsened Data", 2018, <https://www.fcc.gov/reports- Coarsened Data", December 2018, <https://www.fcc.gov/
research/reports/measuring-broadband-america/ reports-research/reports/measuring-broadband-america/
measuring-broadband-america-mobile-2013-2018>. measuring-broadband-america-mobile-2013-2018>.
[I-D.bp-v6ops-ipv6-ready-dns-dnssec] [IPV4ONLY-ARPA]
Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC
Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00
(work in progress), October 2018.
[I-D.cheshire-sudn-ipv4only-dot-arpa]
Cheshire, S. and D. Schinazi, "Special Use Domain Name Cheshire, S. and D. Schinazi, "Special Use Domain Name
'ipv4only.arpa'", draft-cheshire-sudn-ipv4only-dot-arpa-14 'ipv4only.arpa'", Work in Progress, Internet-Draft, draft-
(work in progress), November 2018. cheshire-sudn-ipv4only-dot-arpa-14, 3 November 2018,
<https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-
[I-D.huitema-quic-dnsoquic] dot-arpa-14>.
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
Iyengar, "Specification of DNS over Dedicated QUIC
Connections", draft-huitema-quic-dnsoquic-06 (work in
progress), March 2019.
[I-D.ietf-6man-ra-pref64]
Colitti, L. and J. Linkova, "Discovering PREF64 in Router
Advertisements", draft-ietf-6man-ra-pref64-01 (work in
progress), June 2019.
[I-D.ietf-tram-stunbis]
Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", draft-ietf-tram-stunbis-21
(work in progress), March 2019.
[I-D.ietf-tram-turnbis]
K, R., Johnston, A., Matthews, P., and J. Rosenberg,
"Traversal Using Relays around NAT (TURN): Relay
Extensions to Session Traversal Utilities for NAT (STUN)",
draft-ietf-tram-turnbis-27 (work in progress), June 2019.
[I-D.li-intarea-nat64-prefix-dhcp-option]
Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet,
"DHCPv6 Options for Discovery NAT64 Prefixes", draft-li-
intarea-nat64-prefix-dhcp-option-02 (work in progress),
April 2019.
[I-D.lmhp-v6ops-transition-comparison] [IPv6-TRANSITION]
Lencse, G., Palet, J., Howard, L., Patterson, R., and I. Lencse, G., Palet, J., Howard, L., Patterson, R., and I.
Farrer, "Pros and Cons of IPv6 Transition Technologies for Farrer, "Pros and Cons of IPv6 Transition Technologies for
IPv4aaS", draft-lmhp-v6ops-transition-comparison-03 (work IPv4aaS", Work in Progress, Internet-Draft, draft-lmhp-
in progress), July 2019. v6ops-transition-comparison-03, 6 July 2019,
<https://tools.ietf.org/html/draft-lmhp-v6ops-transition-
comparison-03>.
[I-D.palet-v6ops-464xlat-opt-cdn-caches] [ISOC] ISOC, "State of IPv6 Deployment 2018", June 2018,
Palet, J. and A. D'Egidio, "464XLAT Optimization", draft- <https://www.internetsociety.org/resources/2018/state-of-
palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress), ipv6-deployment-2018/>.
June 2019.
[I-D.vixie-dns-rpz] [OPT-464XLAT]
Vixie, P. and V. Schryver, "DNS Response Policy Zones Palet, J. and A. D'Egidio, "464XLAT Optimization", Work in
(RPZ)", draft-vixie-dns-rpz-04 (work in progress), Progress, Internet-Draft, draft-palet-v6ops-464xlat-opt-
December 2016. cdn-caches-03, 8 July 2019, <https://tools.ietf.org/html/
draft-palet-v6ops-464xlat-opt-cdn-caches-03>.
[ISOC] ISOC, "State of IPv6 Deployment 2018", 2018, [PREF64] Colitti, L. and J. Linkova, "Discovering PREF64 in Router
<https://www.internetsociety.org/resources/2018/ Advertisements", Work in Progress, Internet-Draft, draft-
state-of-ipv6-deployment-2018/>. ietf-6man-ra-pref64-06, 3 October 2019,
<https://tools.ietf.org/html/draft-ietf-6man-ra-
pref64-06>.
[QUIC-CONNECTIONS]
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
Iyengar, "Specification of DNS over Dedicated QUIC
Connections", Work in Progress, Internet-Draft, draft-
huitema-quic-dnsoquic-07, 7 September 2019,
<https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-
07>.
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
"Analysis of Stateful 64 Translation", RFC 6889, "Analysis of Stateful 64 Translation", RFC 6889,
DOI 10.17487/RFC6889, April 2013, DOI 10.17487/RFC6889, April 2013,
<https://www.rfc-editor.org/info/rfc6889>. <https://www.rfc-editor.org/info/rfc6889>.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in "Architectural Considerations on Application Features in
the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
<https://www.rfc-editor.org/info/rfc6950>. <https://www.rfc-editor.org/info/rfc6950>.
skipping to change at page 45, line 20 skipping to change at line 1795
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking
Methodology for IPv6 Transition Technologies", RFC 8219, Methodology for IPv6 Transition Technologies", RFC 8219,
DOI 10.17487/RFC8219, August 2017, DOI 10.17487/RFC8219, August 2017,
<https://www.rfc-editor.org/info/rfc8219>. <https://www.rfc-editor.org/info/rfc8219>.
[RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima, [RFC8585] Palet Martinez, J., Liu, H. M.-H., and M. Kawashima,
"Requirements for IPv6 Customer Edge Routers to Support "Requirements for IPv6 Customer Edge Routers to Support
IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
2019, <https://www.rfc-editor.org/info/rfc8585>. 2019, <https://www.rfc-editor.org/info/rfc8585>.
[RIPE-690] [RIPE-690] RIPE, "Best Current Operational Practice for Operators:
RIPE, "Best Current Operational Practice for Operators:
IPv6 prefix assignment for end-users - persistent vs non- IPv6 prefix assignment for end-users - persistent vs non-
persistent, and what size to choose", October 2017, persistent, and what size to choose", October 2017,
<https://www.ripe.net/publications/docs/ripe-690>. <https://www.ripe.net/publications/docs/ripe-690>.
[Threat-DNS64] [Threat-DNS64]
Lencse, G. and Y. Kadobayashi, "Methodology for the Lencse, G. and Y. Kadobayashi, "Methodology for the
identification of potential security issues of different identification of potential security issues of different
IPv6 transition technologies: Threat analysis of DNS64 and IPv6 transition technologies: Threat analysis of DNS64 and
stateful NAT64", Computers & Security , vol. 77, no. 1, stateful NAT64", pp. 397-411, no. 1, vol. 77, Computers &
pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018. Security, DOI 10.1016/j.cose.2018.04.012, August 2018,
<https://www.sciencedirect.com/science/article/pii/
S0167404818303663?via%3Dihub>.
Appendix A. Example of Broadband Deployment with 464XLAT
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.
Note that an equivalent setup could also be provided for enterprise
customers. If they need to support IPv4 inbound connections, several
mechanisms, depending on specific customer needs, allow it; see
[RFC7757].
Conceptually, most of the operator network could be IPv6 only
(represented in the next figures as "IPv6-only flow"), or even if
part of the network is actually dual stack, only IPv6 access is
available for some customers (i.e., residential customers). This
part of the network connects the IPv6-only subscribers (by means of
IPv6-only access links) to the IPv6 upstream providers and to the
IPv4-Internet by means of NAT64 (PLAT in the 464XLAT terminology).
The traffic flow from and back to the CE to services available in the
IPv6 Internet (or even dual-stack remote services, when IPv6 is being
used) is purely native IPv6 traffic, so there are no special
considerations about it.
From the DNS perspective, there are remote networks with IPv4 only
that will typically have only IPv4 DNS (DNS/IPv4) or will at least be
seen as IPv4 DNS from the CE perspective. On the operator side, the
DNS, as seen from the CE, is only IPv6 (DNS/IPv6), and it also has a
DNS64 function.
On the customer LANs side, there is actually one network, which of
course could be split into different segments. The most common setup
will be dual-stack segments, using global IPv6 addresses and
[RFC1918] for IPv4, in any regular residential / Small Office, Home
Office (SOHO) IPv4 network. In the figure below, it is represented
as tree segments to show that the three possible setups are valid
(IPv6 only, IPv4 only, and dual stack).
.-----. +-------+ .-----. .-----.
/ 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 /
`-----'
Figure 16: CE Setup with Built-In CLAT, with DNS64
In addition to the regular CE setup, which typically will be access-
technology dependent, the steps for the CLAT function configuration
can be summarized as follows:
1. Discovery of the PLAT (NAT64) prefix: It may be done using
[RFC7050], [RFC7225] in those networks where PCP is supported, or
other alternatives that may be available in the future, such as
Router Advertising [PREF64] or DHCPv6 options [DHCPv6-OPTIONS].
2. If the CLAT function allows stateless NAT46 translation, a /64
from the pool typically provided to the CE by means of DHCPv6-PD
[RFC8415] needs to be set aside for that translation. Otherwise,
the CLAT is forced to perform an intermediate stateful NAT44
before the stateless NAT46, as described in Section 4.8.
A more detailed configuration approach is described in [RFC8585].
The operator network needs to ensure that the correct responses are
provided for the discovery of the PLAT prefix. It is highly
recommended that [RIPE-690] be followed in order to ensure that
multiple /64s are available, including the one needed for the NAT46
stateless translation.
The operator needs to understand other issues, as described
throughout this document, in order to make relevant decisions. For
example, if several NAT64 functions are needed in the context of
scalability / high availability, an NSP should be considered (see
Section 4.5).
More complex scenarios are possible, for example, if a network offers
multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.
If the operator decides not to provide a DNS64 function, then this
setup will be the same as the following figure. This will also be
the setup that will be seen from the perspective of the CE, if a
foreign DNS is used and consequently is not the operator-provided
DNS64 function.
.-----. +-------+ .-----. .-----.
/ 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 /
`-----'
Figure 17: CE Setup with Built-In CLAT, without DNS64
In this case, the discovery of the PLAT prefix needs to be arranged
as indicated in Section 4.1.1.
In addition, if the CE doesn't have a built-in CLAT function, the
customer can choose to set up the IPv6 operator-managed CE in bridge
mode (and optionally use an external router). Or, for example, if
there is an access technology that requires some kind of media
converter (Optical Network Termination (ONT) for fiber to the home
(FTTH), Cable Modem for Data-Over-Cable Service Interface
Specification (DOCSIS), etc.), the complete setup will look like
Figure 18. 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.
+-------+ .-----. .-----.
| | / \ / \
| 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 /
`-----'
Figure 18: CE Setup with Bridged CLAT, without DNS64
Several routers (i.e., the operator-provided CE and the downstream
user-provided router) that enable simultaneous routing and/or CLAT
should be avoided to ensure that multiple NAT44 and NAT46 levels are
not used and that the operation of multiple IPv6 subnets is correct.
In those cases, the use of the Home Networking Control Protocol
(HNCP) [RFC8375] is suggested.
Note that the procedure described here for the CE setup can be
simplified if the CE follows [RFC8585].
Appendix B. CLAT Implementation
In addition to the regular set of features for a CE, a CLAT CE
implementation requires support for:
* [RFC7915] for the NAT46 function.
* [RFC7050] for the PLAT prefix discovery.
* [RFC7225] for the PLAT prefix discovery if PCP is supported.
* [PREF64] for the PLAT prefix discovery by means of Router
Advertising.
* [DHCPv6-OPTIONS] for the PLAT prefix discovery by means of DHCP.
* If stateless NAT46 is supported, a mechanism to ensure that
multiple /64 are available, such as DHCPv6-PD [RFC8415], must be
used.
There are several Open Source implementations of CLAT, such as:
* Android: https://github.com/ddrown/android_external_android-clat
* Jool: https://www.jool.mx
* Linux: https://github.com/toreanderson/clatd
* OpenWRT: https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search
&h=refs%2Ftags%2Fv19.07.0-rc1&st=commit&s=464xlat
* VPP: https://git.fd.io/vpp/tree/src/plugins/nat
Appendix C. Benchmarking
A benchmarking methodology for IPv6 transition technologies has been
defined in [RFC8219]. NAT64 and 464XLAT are addressed among the
single- and double-translation technologies, respectively. DNS64 is
addressed in Section 9, and the methodology is elaborated in
[DNS64-BM-Meth] of that document.
Several documents provide references to benchmarking results, for
example, for DNS64 [DNS64-Benchm].
Acknowledgements
The author would like to acknowledge the inputs of Gabor Lencse,
Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed
Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson, and Eric
Vyncke.
Conversations with Marcelo Bagnulo, one of the coauthors of NAT64 and
DNS64, and email correspondence via the IETF mailing lists with Mark
Andrews have been very useful for this work.
Work on this document was inspired by Christian Huitema, who
suggested that DNS64 should never be used when deploying CLAT in the
IETF network.
Author's Address Author's Address
Jordi Palet Martinez Jordi Palet Martinez
The IPv6 Company The IPv6 Company
Molino de la Navata, 75 Molino de la Navata, 75
La Navata - Galapagar, Madrid 28420 28420 La Navata - Galapagar Madrid
Spain Spain
Email: jordi.palet@theipv6company.com Email: jordi.palet@theipv6company.com
URI: http://www.theipv6company.com/ URI: http://www.theipv6company.com/
 End of changes. 287 change blocks. 
1169 lines changed or deleted 1105 lines changed or added

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