draft-ietf-v6ops-nat64-deployment-04.txt   draft-ietf-v6ops-nat64-deployment-05.txt 
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational April 2, 2019 Intended status: Informational April 19, 2019
Expires: October 4, 2019 Expires: October 21, 2019
NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks Additional NAT64/464XLAT Deployment Guidelines in Operator and
draft-ietf-v6ops-nat64-deployment-04 Enterprise Networks
draft-ietf-v6ops-nat64-deployment-05
Abstract Abstract
This document describes how NAT64 and 464XLAT can be deployed in an This document describes how NAT64 (including 464XLAT) can be deployed
IPv6 network, whether cellular ISP, broadband ISP, or enterprise and in an IPv6 network, whether cellular ISP, broadband ISP, or
the issues to be considered when having an IPv6-only access link, enterprise, and possible optimizations. The document also discusses
issues to be considered when having IPv6-only connectivity,
regarding: a) DNS64, b) applications or devices that use literal IPv4 regarding: a) DNS64, b) applications or devices that use literal IPv4
addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or
applications. applications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 4, 2019. This Internet-Draft will expire on October 21, 2019.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. NAT64 Deployment Scenarios . . . . . . . . . . . . . . . . . 4 3. NAT64 Deployment Scenarios . . . . . . . . . . . . . . . . . 5
3.1. Known to Work . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Known to Work . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Service Provider NAT64 with DNS64 . . . . . . . . . . 5 3.1.1. Service Provider NAT64 with DNS64 . . . . . . . . . . 6
3.1.2. Service Provider offering 464XLAT, with DNS64 . . . . 7 3.1.2. Service Provider Offering 464XLAT, with DNS64 . . . . 8
3.1.3. Service Provider offering 464XLAT, without DNS64 . . 10 3.1.3. Service Provider Offering 464XLAT, without DNS64 . . 11
3.2. Known to Work Under Special Conditions . . . . . . . . . 12 3.2. Known to Work Under Special Conditions . . . . . . . . . 14
3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 12 3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 14
3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 13 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 15
3.2.3. Service Provider NAT64; DNS64 in the IPv4-only 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only
remote network . . . . . . . . . . . . . . . . . . . 14 remote network . . . . . . . . . . . . . . . . . . . 16
3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 14 3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 16
4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 16 4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 18
4.1. DNSSEC Considerations and Possible Approaches . . . . . . 16 4.1. DNSSEC Considerations and Possible Approaches . . . . . . 18
4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 17 4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 20
4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 18 4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21
4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 18 4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 21
4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 19 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 21
4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 19 4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22
4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 19 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 22
4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 19 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 22
4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 20 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 22
4.4. Manual Configuration of Foreign DNS . . . . . . . . . . . 21 4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 23
4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.1. Manual Configuration of Foreign DNS . . . . . . . . . 24
4.6. Split DNS . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.2. DNS Privacy . . . . . . . . . . . . . . . . . . . . . 24
4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 22 4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 25
4.8. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 25
4.9. IPv4-only Hosts or Applications . . . . . . . . . . . . . 23 4.6. IPv4 literals and old APIs . . . . . . . . . . . . . . . 25
4.10. CLAT Translation Considerations . . . . . . . . . . . . . 23 4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 26
4.11. EAMT Considerations . . . . . . . . . . . . . . . . . . . 23 4.8. CLAT Translation Considerations . . . . . . . . . . . . . 26
5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 24 4.9. EAMT Considerations . . . . . . . . . . . . . . . . . . . 27
6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 27 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 32 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 32
12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 33 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 36
13. ANNEX D: Changes from -00 to -01 . . . . . . . . . . . . . . 33 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 36
14. ANNEX E: Changes from -01 to -02 . . . . . . . . . . . . . . 33 13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 36
15. ANNEX F: Changes from -02 to -03 . . . . . . . . . . . . . . 33 14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 37
16.1. Normative References . . . . . . . . . . . . . . . . . . 34 16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . 36 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 17.1. Normative References . . . . . . . . . . . . . . . . . . 37
17.2. Informative References . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4
mechanism, which allows IPv6-only hosts to communicate with IPv4-only translation mechanism, which allows IPv6-only hosts to communicate
servers using unicast UDP, TCP or ICMP, by means of IPv4 public with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of
addresses sharing (assigned to the translator), among multiple IPv4 public addresses sharing, among multiple IPv6-only hosts.
IPv6-only hosts. Unless otherwise stated, references in the rest of this document to
NAT64 (function) should be interpreted as to 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] and algorithmically
translating the IPv4 addresses to IPv6 addresses following [RFC6052]. translating the IPv4 addresses to IPv6 addresses and vice versa,
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, the A records, so only works for applications making use of DNS. It
avoiding changes in both, the IPv6-only hosts and the IPv4-only was designed to avoid changes in both, the IPv6-only hosts and the
server, so they can use a NAT64. As discussed in Section 5.5 of IPv4-only server, so they can use a NAT64 function. As discussed in
[RFC6147], a security-aware and validating host has to perform the Section 5.5 of [RFC6147], a security-aware and validating host has to
DNS64 function locally. perform the DNS64 function locally.
However, the use of NAT64 and/or DNS64 present three issues: However, the use of NAT64 and/or DNS64 present three drawbacks:
a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is
designed to detect such modifications, DNS64 ([RFC6147]) can 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 is validating, etc.
b. Because the need of using DNS64 ([RFC6147]) or an alternative b. Because the need of using DNS64 ([RFC6147]) or an alternative
"host/application built-in" mechanism for address synthesis, "host/application built-in" mechanism for address synthesis,
there is a major issue for NAT64 ([RFC6146]), as doesn't work there may be an issue for NAT64 ([RFC6146]), as it doesn't work
when literal addresses or non-IPv6 compliant APIs are being used. when IPv4 literal addresses or non-IPv6 compliant APIs are being
used.
c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or c. NAT64 alone, was not designed to provide a solution for IPv4-only
applications located within a network which are connected to a hosts or applications located within a network which are
service provider IPv6-only access, as it was designed for a very connected to a service provider IPv6-only access, as it was
specific scenario ([RFC6144], Section 2.1). designed for a very specific scenario ([RFC6144], Section 2.1).
The same issues are true if part of, for example, an enterprise Above drawbacks may be true if part of, an enterprise network, is
network, is connected to other parts of the same network or third connected to other parts of the same network or third-party networks
party networks by means of IPv6-only connectivity. This applies to by means of IPv6-only connectivity. This is just an example which
many other similar cases. may apply to many other similar cases. All them are deployment
specific.
According to that, across this document, the use of "operator", According to that, across this document, the use of "operator",
"operator network", "service provider", and similar ones, are "operator network", "service provider", and similar ones, are
interchangeable with equivalent cases of enterprise networks (and interchangeable with equivalent cases of enterprise networks (and
similar ones). This may be also the case for other "managed end-user similar ones). This may be also the case for "managed end-user
networks". networks".
An analysis of stateful IPv6/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 and similar ones, deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and
which were not documented by [RFC6144], such as 464XLAT ([RFC6877]), similar ones, which were not documented in [RFC6144], such as 464XLAT
in operator (broadband and cellular) and enterprise networks, and ([RFC6877]), in operator (broadband and cellular) and enterprise
provides guidelines to avoid the above-mentioned issues. networks, and provides guidelines to avoid operational issues.
Towards that, this document first looks into the possible NAT64 Towards that, this document first looks into the possible NAT64
deployment scenarios (split in "known to work" and "known to work deployment scenarios (split in "known to work" and "known to work
under special conditions"), providing a quick and generic comparison under special conditions"), providing a quick and generic comparison
table among them. Then the document describes the issues that an table among them. Then the document describes the issues that an
operator need to understand on different matters that will allow to operator need to understand on different matters that will allow to
define what is the best approach/scenario for each specific network define what is the best approach/scenario for each specific network
case. A summary provides some recommendations and decision points case. A summary provides some recommendations and decision points.
and then a clarification of the usage of this document for enterprise A section with clarifications on the usage of this document for
networks is provided. Finally, an annex provides an example of a enterprise networks, is also provided. Finally, an annex provides an
broadband deployment using 464XLAT. example of a broadband deployment using 464XLAT and another annex
provides hints for a CLAT implementation.
[RFC7269] already provides information about NAT64 deployment options
and experiences. Both, this document and [RFC7269] are
complementary, as they are looking into different deployment
considerations and furthermore, this document is considering the
updated deployment experience and newer standards.
The target deployment scenarios in this document may be covered as The target deployment scenarios in this document may be covered as
well by other IPv4-as-a-Service transition mechanisms. It is out of well by other IPv4-as-a-Service (IPv4aaS) transition mechanisms.
scope of this document to provide a comparison among them. Note that this is true only for the case of broadband networks, as in
the case of cellular networks the only supported solution is the use
of NAT64/464XLAT. So, it is out of scope of this document to provide
a comparison among the different IPv4aaS transition mechanisms, which
is being analyzed already in [I-D.lmhp-v6ops-transition-comparison].
[RFC7269] provides additional information about NAT64 deployment Consequently, this document should not be understood as a guide for
options and experiences. an operator or enterprise to decide which IPv4aaS is the best one for
its own network. Instead it should be used as a tool for
understanding all the implications, including relevant documents (or
even specific parts of them), for the deployment of NAT64/464XLAT and
facilitate the decision process regarding specific deployment
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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 3 scenarios, looking at the Section 7 of DNS64 ([RFC6147]), provides three scenarios, depending
location of the DNS64. However, since the publication of that on the location of the DNS64 function. However, since the
document, other possible scenarios and NAT64 use cases need to be publication of that document, other deployment scenarios and NAT64
considered in actual networks, despite some of them were specifically use cases need to be considered in actual networks, despite some of
ruled out of the original NAT64/DNS64 work. 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, including a few new ones. However, in order to be able to
reduce the number of possible cases, we work under the assumption reduce the number of possible cases, we work under the assumption
that typically, the service provider wants to make sure that all the that typically, the service provider wants to make sure that all the
customers have a service without failures. This means considering customers have a service without failures. This means considering
the worst possible case: the following 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. Literal addresses and non-IPv6 compliant APIs are being used. b. IPv4 literal addresses and non-IPv6 compliant APIs are being
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": The 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/services (IPv4). 2. An IPv4-only remote network/server/service (IPv4).
3. The NAT64 function (NAT64) in the service provider. 3. A NAT64 function (NAT64) in the service provider.
4. The DNS64 function (DNS64) in the service provider. 4. A DNS64 function (DNS64) in the service provider.
5. An external service provider offering the NAT64 and/or the DNS64 5. An external service provider offering the NAT64 function and/or
function (extNAT64/extDNS64). the DNS64 function (extNAT64/extDNS64).
6. 464XLAT customer side translator (CLAT). 6. 464XLAT customer side translator (CLAT).
Note that the nomenclature used in parenthesis is the one that, for
short, will be used in the figures.
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. Each one may have The scenarios in this category are known to work. Each one may have
different pros and cons, and in some cases the trade-offs, maybe different pros and cons, and in some cases the trade-offs, maybe
acceptable for some operators. acceptable for some operators.
3.1.1. Service Provider NAT64 with DNS64 3.1.1. Service Provider NAT64 with DNS64
In this scenario, the service provider offers both, the NAT64 and the In this scenario, the service provider offers both, the NAT64 and the
DNS64 functions. DNS64 functions.
This is probably the most common scenario, however also may have the This is the most common scenario as originally considered by the
implications related the DNSSEC. designers of NAT64 ([RFC6146]) and DNS64 ([RFC6147]), however also
may have the implications related the DNSSEC.
This scenario also may fail to solve the issue of literal addresses This scenario also may fail to solve the issue of IPv4 literal
or non-IPv6 compliant APIs, as well as the issue of IPv4-only hosts addresses or non-IPv6 compliant APIs, as well as the issue of
or applications inside the IPv6-only access network. IPv4-only hosts or 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 totally equivalent scenario will be if the service provider offers A similar scenario will be if the service provider offers only the
only the DNS64 function, and the NAT64 function is provided by an DNS64 function, and the NAT64 function is provided by an outsourcing
outsourcing agreement with an external provider. All the agreement with an external provider. All the considerations in the
considerations in the previous paragraphs of this section are the previous paragraphs of this section are the same for this sub-case.
same for this sub-case.
+----------+ +----------+ +----------+
| | | | | |
| extNAT64 | | extNAT64 +--------+ IPv4 |
| | | | | |
+----+-----+ +----+-----+ +----------+
| |
| |
+----------+ +----+-----+ +----------+ +----------+ +----+-----+
| | | | | | | | | |
| IPv6 +--------+ DNS64 +--------+ IPv4 | | IPv6 +--------+ DNS64 +
| | | | | | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+
Figure 2: NAT64 in external service provider Figure 2: NAT64 in external service provider
As well, is equivalent to the scenario where the outsourcing As well, is equivalent to the scenario 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 |
| extDNS64 | | extDNS64 | | |
+----+-----+ +----+-----+ +----------+
| |
+----------+ | +----------+ +----------+ |
| | | | | | | |
| IPv6 +-------------+--------------+ IPv4 | | IPv6 +-------------+
| | | | | |
+----------+ +----------+ +----------+
Figure 3: NAT64 and DNS64 in external provider Figure 3: NAT64 and DNS64 in external provider
One more equivalent scenario will be if the service provider offers One more equivalent scenario will be if the service provider offers
the NAT64 only, and the DNS64 function is from an external provider the NAT64 function only, and the DNS64 function is from an external
with or without a specific agreement among them. This is a scenario provider with or without a specific agreement among them. This is a
already common today, as several "global" service providers provide scenario already common today, as several "global" service providers
free DNS/DNS64 services and users often configure manually their DNS. provide free DNS/DNS64 services and users often configure manually
This will only work if both the NAT64 and the DNS64 are using the WKP their DNS. This will only work if both the NAT64 and the DNS64
(Well-Known Prefix) or the same NSP (Network-Specific Prefix). All functions are using the WKP (Well-Known Prefix) or the same NSP
the considerations in the previous paragraphs of this section are the (Network-Specific Prefix). All the considerations in the previous
same for this sub-case. paragraphs of this section are the same for this sub-case.
Of course, if the external DNS64 is agreed with the service provider, Of course, if the external DNS64 function is agreed with the service
then we are in the same case as in the previous ones already depicted provider, then we are in the same case as in the previous ones
in this scenario. already depicted in this scenario.
+----------+ +----------+
| | | |
| extDNS64 | | extDNS64 |
| | | |
+----+-----+ +----+-----+
| |
| |
+----------+ +----+-----+ +----------+ +----------+ +----+-----+ +----------+
| | | | | | | | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 | | IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | | | | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 4: NAT64; DNS64 by external provider Figure 4: NAT64; DNS64 by external provider
3.1.2. Service Provider offering 464XLAT, with DNS64 3.1.2. Service Provider Offering 464XLAT, with 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. natively transporting IPv6. [RFC7849] already suggest the need to
support the CLAT function in order to ensure the IPv4 service
continuity in IPv6-only cellular deployments.
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 customer-side translator (CLAT) is a stateless IPv4 to IPv6
translator (NAT46) ([RFC7915]) implemented in the end-user device translator (NAT46) ([RFC7915]) implemented in the end-user device
or CE, located at the "customer" edge of the network. or CE (Customer Edge Router), located at the "customer edge" of
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 at in the operator network.
3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a 3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a
single translation at the NAT64, instead of two translations single 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 RR). supports IPv6 DNS (uses AAAA Resource Records).
Note that even in the 464XLAT ([RFC6877]) terminology, the provider- Note that even if in the 464XLAT ([RFC6877]) terminology, the
side translator is referred as PLAT, for simplicity and uniformity, provider-side translator is referred as PLAT, for simplicity and
in this document is always referred as NAT64. uniformity, across this document is always referred as NAT64
(function).
In this scenario the service provider deploys 464XLAT with DNS64. In this scenario the service provider deploys 464XLAT 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 initially mainly in IPv6-only
cellular networks. By supporting CLAT, the end-user device cellular networks. By supporting a CLAT function, the end-user
applications can access IPv4-only end-networks/applications, despite device applications can access IPv4-only end-networks/applications,
those applications or devices use literal IPv4 addresses or non-IPv6 despite those applications or devices use literal IPv4 addresses or
compliant APIs. non-IPv6 compliant APIs.
In addition to that, in the same example of the cellular network In addition to that, in the same example of the cellular network
above, if the User Equipment (UE) provides tethering, other devices above, if the User Equipment (UE) provides tethering, other devices
behind it will be presented with a traditional NAT44, in addition to behind it will be presented with a traditional NAT44, in addition to
the native IPv6 support, so clearly it allows IPv4-only hosts inside the native IPv6 support, so clearly it allows IPv4-only hosts behind
the IPv6-only access network. the IPv6-only access network.
Furthermore, as indicated 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
functionality at the CE. function at the CE.
The support of this scenario offers two additional advantages:
o DNS load optimization: A CLAT should implement a DNS proxy (as per
[RFC5625]), so that only IPv6 native queries and only for AAAA
records are sent to the DNS64 server. Otherwise doubling the
number of queries may impact the DNS infrastructure.
o Connection establishment delay optimization: If the UE/CE
implementation is detecting the presence of a DNS64 function, it
may issue only the AAAA query, instead of both the AAAA and A
queries.
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 peers:
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only ) / Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ Internet/\ `-----' \ Internet/ / \ | | \ 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 /
+--------+ `-----' +--------+ `-----'
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 The possible communication paths, among the IPv4/IPv6 stacks of both
peers, in this case, are: peers, in this case, are:
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. It is not expected that c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
services are deployed in Internet using IPv6-only, unless there implements EAMT as indicated by Section 4.9. In principle, it is
is certainty that peers will also be IPv6-capable. not expected that services are deployed in Internet using
IPv6-only, unless there is certainty that peers will also be
IPv6-capable.
d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations.
translations.
The following figures show different choices for placing the e. Local-IPv4 to Remote-dual-stack using EAMT optimization: If the
different elements. CLAT implements EAMT as indicated by Section 4.9, instead of
using the path d. above, NAT64 translation is avoided and the
flow will use IPv6 from the CLAT to the destination.
The rest of the figures in this section show different choices for
placing the different elements.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | NAT64 | | | | IPv6 | | NAT64 | | |
| + +--------+ + +--------+ IPv4 | | + +--------+ + +--------+ IPv4 |
| CLAT | | DNS64 | | | | CLAT | | DNS64 | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 5: 464XLAT with DNS64 Figure 5: 464XLAT with DNS64
An equivalent scenario will be if the service provider offers only A similar scenario will be if the service provider offers only the
the DNS64 function, and the NAT64 function is provided by an DNS64 function, and the NAT64 function is provided by an outsourcing
outsourcing agreement with an external provider. All the agreement with an external provider. All the considerations in the
considerations in the previous paragraphs of this section are the previous paragraphs of this section are the same for this sub-case.
same for this sub-case.
+----------+ +----------+ +----------+
| | | | | |
| extNAT64 | | extNAT64 +--------+ IPv4 |
| | | | | |
+----+-----+ +----+-----+ +----------+
| |
| |
+----------+ +----+-----+ +----------+ +----------+ +----+-----+
| IPv6 | | | | | | IPv6 | | |
| + +--------+ DNS64 +--------+ IPv4 | | + +--------+ DNS64 +
| CLAT | | | | | | CLAT | | |
+----------+ +----------+ +----------+ +----------+ +----------+
Figure 6: 464XLAT with DNS64; NAT64 in external provider Figure 6: 464XLAT with DNS64; NAT64 in external provider
As well, is equivalent to the scenario where the outsourcing As well, is equivalent to the scenario 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 |
| extDNS64 | | extDNS64 | | |
+----+-----+ +----+-----+ +----------+
| |
+----------+ | +----------+ +----------+ |
| IPv6 | | | | | IPv6 | |
| + +-------------+--------------+ IPv4 | | + +-------------+
| CLAT | | | | CLAT |
+----------+ +----------+ +----------+
Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider
3.1.3. Service Provider offering 464XLAT, without DNS64 3.1.3. Service Provider Offering 464XLAT, without DNS64
The major advantage of this scenario, using 464XLAT without DNS64, is The major advantage of this scenario, using 464XLAT without DNS64, is
that the service provider ensures that DNSSEC is never broken, even that the service provider ensures that DNSSEC is never broken, even
in case the user modifies the DNS configuration. in case the user modifies the DNS configuration. Nevertheless, some
CLAT implementations or applications may expose an extra delay, which
is inducted by the dual A/AAAA queries (and wait for both responses),
unless Happy Eyeballs v2 (HEv2, [RFC8305]) is also present.
A possible variation of this scenario is the case when DNS64 is used
only for the discovery of the NAT64 prefix. The rest of the document
is not considering it as a different scenario, because once the
prefix has been discovered, the DNS64 function is not used, so it
behaves as if the DNS64 synthesis function is not present.
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) inside the IPv6-only to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only
access network, neither to the usage of IPv4 literals or non-IPv6 access network, neither related to the usage of IPv4 literals or non-
compliant APIs. IPv6 compliant APIs.
The support of this scenario offers one advantage:
o DNS load optimization: A CLAT should implement a DNS proxy (as per
[RFC5625]), so that only IPv6 native queries are sent to the DNS64
server. Otherwise doubling the number of queries may impact the
DNS infrastructure.
As indicated earlier, the connection establishment delay optimization
is achieved only in the case of devices, Operating Systems, or
applications that use HEv2 ([RFC8305]), which is very common.
Let's assume the representation of two dual-stack peers as in the Let's assume the representation of two dual-stack peers as in the
previous case: previous case:
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only ) / Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ Internet/\ `-----' \ Internet/ / \ | | \ 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 /
`-----' `-----'
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 The possible communication paths, among the IPv4/IPv6 stacks of both
peers, in this case, are: peers, in this case, are:
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: Because there is no DNS64, will fall- b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64
back to d. below. translations.
c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
services are deployed in Internet using IPv6-only, unless there implements EAMT as indicated by Section 4.9. In principle, it is
is certainty that peers will also be IPv6-capable. not expected that services are deployed in Internet using
IPv6-only, unless there is certainty that peers will also be
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 EAMT optimization: If the
CLAT implements EAMT as indicated by Section 4.9, instead of
using the path d. above, NAT64 translation is avoided and the
flow will use IPv6 from the CLAT to the destination.
It needs to be noticed that this scenario works while the local It needs to be noticed that this scenario works while the local
hosts/applications are dual-stack (which is the current situation), hosts/applications are dual-stack (which is the current situation),
because the connectivity from a local-IPv6 to a remote-IPv4 is not because the connectivity from a local-IPv6 to a remote-IPv4 is not
possible without an AAAA synthesis. This aspect is important only possible without an AAAA synthesis. This aspect is important only
when in the LANs behind the CLAT there are IPv6-only hosts and they when in the LANs behind the CLAT there are IPv6-only hosts and they
need to communicate with remote IPv4-only hosts. However, doesn't need to communicate with remote IPv4-only hosts. However, it doesn't
look a sensible approach from an Operating System or application look a sensible approach from an Operating System or application
vendor perspective, to provide IPv6-only support unless, similarly to vendor perspective, to provide IPv6-only support unless, similarly to
c. above, there is certainty of peers supporting IPv6 as well. case c above, there is certainty of peers supporting IPv6 as well. A
solution approach to this is also presented in
[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 | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 8: 464XLAT without DNS64 Figure 8: 464XLAT without DNS64
This is equivalent to the scenario where there is an outsourcing This is equivalent to the scenario where there is an outsourcing
agreement with an external provider for the NAT64 function. All the agreement with an external provider for the NAT64 function. 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 | | extNAT64 +--------+ IPv4 |
| | | | | |
+----+-----+ +----+-----+ +----------+
| |
+----------+ | +----------+ +----------+ |
| IPv6 | | | | | IPv6 | |
| + +-------------+--------------+ IPv4 | | + +-------------+
| CLAT | | | | CLAT |
+----------+ +----------+ +----------+
Figure 9: 464XLAT without DNS64; NAT64 in external provider Figure 9: 464XLAT without DNS64; NAT64 in 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 to not work unless
significant effort is devoted to solve the issues, or are intended to significant effort is devoted to solve the issues, or are intended to
solve problems across "closed" networks, instead of as a general solve problems across "closed" networks, instead of as a general
Internet access usage. In addition to the different pros, cons and Internet access usage. In addition to the different pros, cons and
trade-offs, which may be acceptable for some operators, they have trade-offs, which may be acceptable for some operators, they have
implementation difficulties, as they are beyond the original implementation difficulties, as they are beyond the original
expectations of the NAT64/DNS64 original intent. expectations of the NAT64/DNS64 original intent.
3.2.1. Service Provider NAT64 without DNS64 3.2.1. Service Provider NAT64 without DNS64
In this scenario, the service provider offers a NAT64, however there In this scenario, the service provider offers a NAT64 function,
is no DNS64 function support. 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],
neither learning the IPv6 prefix to be used for the NAT64. neither to 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 However, despite that, because the lack of the DNS64 function, the
IPv6 host will not be able to obtain AAAA synthesized records, so the IPv6 host will not be able to obtain AAAA synthesized records, so the
NAT64 becomes useless. NAT64 function becomes useless.
An exception to this "useless" scenario will be manually configure An exception to this "useless" scenario will be 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 (Well-Known Prefix)
or NSP (Network-Specific Prefix) used by the service provider NAT64, or NSP (Network-Specific Prefix) used by the service provider NAT64
as if they were synthesized by a DNS64. function, as if they were synthesized by a 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). The latest, may have means of DNS RPZ (Response Policy Zones, [I-D.vixie-dns-rpz]) or
implications in DNSSEC, if the zone is signed. Also, if the service equivalent functionality. DNS RPZ, may have implications in DNSSEC,
provider is using an NSP, having the mapping at the authoritative if the zone is signed. Also, if the service provider is using an
server, will mean that may create troubles to other parties trying to NSP, having the mapping at the authoritative server, may create
use different NSP or the WKP, unless multiple DNS "views" are also troubles to other parties trying to use different NSP or the WKP,
being used at the authoritative servers. unless multiple DNS "views" (split-DNS) is also being used at the
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 set of IPv4-only remote hosts need to be accessed by a single network
or reduced set of them, which support IPv6-only in the access, with (or a small number of them), which support IPv6-only in the access.
some kind of mutual agreement for using this procedure, so it doesn't This will require some kind of mutual agreement for using this
care if they become a trouble for other parties across Internet procedure, so it doesn't care if they become a trouble for other
("closed services"). parties across Internet ("closed services").
In any case, this scenario doesn't solve the issue of 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 or non-IPv6 compliant APIs, neither it solves the problem
of IPv4-only hosts within that IPv6-only access network. of IPv4-only hosts within that 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 the IPv6 hosts
In this scenario, the service provider offers the NAT64, but not the In this scenario, the service provider offers the NAT64 function, but
DNS64. However, the IPv6 hosts have a built-in DNS64 function. not the DNS64 function. However, the IPv6 hosts have a 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, which is not the actual situation. At this the IPv6 hosts/stacks, which is not the actual situation, but it may
way, the DNSSEC validation is performed on the A record, and then the happen in the medium-term. At this way, the DNSSEC validation is
host can use the DNS64 function so to be able to use the NAT64, performed on the A record, and then the host can use the DNS64
without any DNSSEC issues. function so to be able to use the NAT64 function, without any DNSSEC
issues.
This scenario fails to solve the issue of literal addresses or non- This scenario fails to solve the issue of IPv4 literal addresses or
IPv6 compliant APIs, unless the IPv6 hosts also supports Happy non-IPv6 compliant APIs, unless the IPv6 hosts also supports HEv2
Eyeballs v2 ([RFC8305], Section 7.1), which may solve that issue. ([RFC8305], Section 7.1), which may solve that issue.
However, this scenario still fails to solve the problem of IPv4-only However, this scenario still fails to solve the problem of IPv4-only
hosts or applications inside 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, the service provider offers the NAT64 only. The In this scenario, the service provider offers the NAT64 function
remote IPv4-only network offers the DNS64 function. only. The remote IPv4-only network offers the DNS64 function.
This is not common, and looks like doesn't make too much sense that a This is not common, and looks like doesn't make too much sense that a
remote network, not deploying IPv6, is providing a DNS64 function and remote network, not deploying IPv6, is providing a DNS64 function.
as in the case of the scenario depicted in Section 3.2.1, it will As in the case of the scenario depicted in Section 3.2.1, it will
only work if both sides are using the WKP or the same NSP so, the only work if both sides are using the WKP or the same NSP, so the
same considerations apply. It can be also tuned to behave as in same considerations apply. It can be also tuned to behave as in
Section 3.1.1 Section 3.1.1
This scenario still fails to solve the issue of literal addresses or This scenario still fails to solve the issue of IPv4 literal
non-IPv6 compliant APIs. addresses or non-IPv6 compliant APIs.
This scenario also fails to solve the problem of IPv4-only hosts or This scenario also fails to solve the problem of IPv4-only hosts or
applications inside the IPv6-only access network. 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 the IPv4-only
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 the possible
variations (each one represented in the precedent sections by a variations (each one represented in the precedent sections by a
different figure), looking at the following parameters: different figure), looking at the following criteria:
a. DNSSEC: Are there host validating DNSSEC? a. DNSSEC: Are there hosts validating DNSSEC?
b. Literal/APIs: Are there applications using literals or non-IPv6
compliant APIs? b. Literal/APIs: Are there applications using IPv4 literals or non-
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 changes the d. Foreign DNS: Is the scenario surviving if the user, Operating
DNS? Note that this apply similarly to split DNS, DNS in VPNs System, applications or devices change the DNS?
and DNS privacy.
In the next table, the columns represent each of the scenario from e. DNS load opt. (DNS load optimization): Are there extra queries
the previous sections, by the Figure number. The possible values that may impact DNS infrastructure?.
f. Connect. opt. (Connection establishment delay optimization): Is
the UE/CE issuing only the AAAA query or also an A query and
waiting for both responses?
In the next table, the columns represent each of the scenarios from
the previous sections, by the figure number. The possible values
are: are:
o - Scenario "bad" for that item. o "-" Scenario "bad" for that criteria.
o + Scenario "good" for that item. o "+" Scenario "good" for that criteria.
Needs to be noted that in some cases "countermeasures", alternative o "*" Scenario "bad" for that criteria, however it is typically
or special configurations, may be available for the items designated resolved, with the support of HEv2 ([RFC8305]).
as "bad", so this comparison is making a generic case, as a quick
comparison guide. In some cases, a "bad" item is not necessarily a In some cases "countermeasures", alternative or special
negative aspect, all it depends on the specific needs/characteristics configurations, may be available for the criteria designated as
of the network where the deployment will take place. For instance, "bad". So this comparison is considering a generic case, as a quick
in a network which has only IPv6-only hosts and apps using only DNS comparison guide. In some cases, a "bad" criteria is not necessarily
and IPv6-compliant APIs, there is no impact using only NAT64 and a negative aspect, all it depends on the specific needs/
DNS64, but if the hosts may validate DNSSEC, that item is still characteristics of the network where the deployment will take place.
relevant. For instance, in a network which has only IPv6-only hosts and apps
using only DNS and IPv6-compliant APIs, there is no impact using only
NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is
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. | + | + | + | + | + | + | + | + | + | + | + | + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Connect. opt. | + | + | + | + | + | + | + | * | * | + | + | + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
Figure 13: Scenario Comparison Figure 13: Scenario Comparison
As a general conclusion, we should note that if the network must As a general conclusion, we should note that, if the network must
support applications using literals, non-IPv6-compliant APIs, or support applications using any of the following:
IPv4-only hosts or applications, only the scenarios with 464XLAT, or
equivalent built-in local address synthesis features, will provide a o IPv4 literals
o non-IPv6-compliant APIs
o IPv4-only hosts or applications
Then, only the scenarios with 464XLAT, a CLAT function, or equivalent
built-in local address synthesis features, will provide a valid
solution. Further to that, those scenarios will also keep working if solution. Further to that, those scenarios will also keep working if
the user changes the DNS setup. Clearly also, depending on if DNS64 the DNS configuration is modified. Clearly also, depending on if
is used or not, DNSSEC may be broken for those hosts doing DNSSEC DNS64 is used or not, DNSSEC may be broken for those hosts doing
validation. DNSSEC validation.
All the scenarios are good in terms of DNS load optimization, and in
the case of 464XLAT it may provide an extra degree of optimization.
Finally, all them are also good in terms of connection establishment
delay optimization. However, in the case of 464XLAT without DNS64,
it requires the usage of HEv2. This is not an issue, as commonly it
is 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 towards a NAT64/464XLAT deployment, as they may bring to
decision points about how to approach that deployment. specific 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 Section 8 of [RFC6147] (DNS64, Security
Considerations), because DNS64 modifies DNS answers and DNSSEC is Considerations), because DNS64 modifies DNS answers and DNSSEC is
designed to detect such modifications, DNS64 can break DNSSEC. designed to detect such modifications, DNS64 may break DNSSEC.
If a device connected to an IPv6-only WAN queries for a domain name If a device connected to an IPv6-only WAN, queries for a domain name
in a signed zone, by means of a recursive name server that supports in a signed zone, by means of a recursive name server that supports
DNS64, and the result is a synthesized AAAA record, and the recursive DNS64, and the result is a synthesized AAAA record, and the recursive
name server is configured to perform DNSSEC validation and has a name server is configured to perform DNSSEC validation and has a
valid chain of trust to the zone in question, it will valid chain of trust to the zone in question, it will
cryptographically validate the negative response from the cryptographically validate the negative response from the
authoritative name server. This is the expected DNS64 behavior: The authoritative name server. This is the expected DNS64 behavior: The
recursive name server actually lies to the client device. However, recursive name server actually "lies" to the client device. However,
in most of the cases, the client will not notice it, because in most of the cases, the client will not notice it, because
generally, they don't perform validation themselves and instead, rely generally, they don't perform validation themselves and instead, rely
on the recursive name servers. on the recursive name servers.
A validating DNS64 resolver in fact, increase the confidence on the A validating DNS64 resolver in fact, increase 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 for
sure, doesn't exists. However, if the client device is sure, doesn't exists. However, if the client device is
NAT64-oblivious (most common case) and performs DNSSEC validation on NAT64-oblivious (most common case) and performs DNSSEC validation on
the AAAA record, it will fail as it is a synthesized record. the AAAA record, it 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 DNSSEC point of view, is when the
client requests the DNS64 server to perform the DNSSEC validation (by client requests the DNS64 server to perform the DNSSEC validation (by
setting the DO bit to 1 and the CD bit to 0). In this case, the setting the DO bit to 1 and the CD bit to 0). In this case, the
DNS64 server validates the data thus tampering may only happen inside DNS64 server validates the data, thus tampering may only happen
the DNS64 server (which is considered as a trusted part, thus its inside the DNS64 server (which is considered as a trusted part, thus
likelihood is low) or between the DNS64 server and the client. All its likelihood is low) or between the DNS64 server and the client.
other parts of the system (including transmission and caching) are All other parts of the system (including transmission and caching)
protected by DNSSEC ([Threat-DNS64]). 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 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].
The ideal solution to avoid DNSSEC issues, will be that all the A solution to avoid DNSSEC issues, will be that all the signed zones
signed zones also provide IPv6 connectivity, together with the also provide IPv6 connectivity, together with the corresponding AAAA
corresponding AAAA records, which is out of the control of the records. However, this is out of the control of the operator needing
operator needing to deploy NAT64. This has been proposed already in to deploy a NAT64 function. This has been proposed already in
[I-D.bp-v6ops-ipv6-ready-dns-dnssec]. [I-D.bp-v6ops-ipv6-ready-dns-dnssec].
An alternative solution, which was the one considered while An alternative solution, which was the one considered while
developing [RFC6147], is that validators will be DNS64-aware, so developing [RFC6147], is that validators will be DNS64-aware, so
could perform the necessary discovery and do their own synthesis. could perform the necessary discovery and do their own synthesis.
That was done under the expectation that it was sufficiently early in That was done under the expectation that it was sufficiently early in
the validator-deployment curve that it would be ok to break certain the validator-deployment curve that it would be ok to break certain
DNSSEC assumptions for networks who were really stuck in a NAT64/ DNSSEC assumptions for networks who were really stuck in a NAT64/
DNS64-needing world. DNS64-needing world.
As already indicated, the scenarios in the previous section, are in As already indicated, the scenarios in the previous section, are in
fact somehow simplified, looking at the worst possible case (or fact somehow simplified, looking at the worst possible case. Saying
saying it in a different way: "trying to look for the most perfect it in a different way: "trying to look for the most perfect
approach"), because breaking DNSSEC will not happen if the end-host approach". DNSSEC breach will not happen if the end-host is not
is not doing validation. Previous data seems to indicate that the doing validation.
figures of DNSSEC actually broken by using DNS64 will be around 1.7%
([About-DNS64]) of the cases. So, a decision point for the operator Existing previous studies seems to indicate that the figures of
must depend on "do I really care for that percentage of cases and the DNSSEC actually broken by using DNS64 will be around 1.7%
impact in my helpdesk or can I provide alternative solutions for ([About-DNS64]) of the cases. However we can not negate that this
them?". Some possible solutions may be taken, as depicted in the may increase, as DNSSEC deployment grows. Consequently, a decision
next sections. point for the operator must depend on "do I really care for that
percentage of cases and the impact in my helpdesk or can I provide
alternative solutions for them?". Some possible solutions may be
taken, as depicted in the next sections.
4.1.1. Not using DNS64 4.1.1. Not using DNS64
The ideal solution will be to avoid using DNS64, but as already A solution will be to avoid using DNS64, but as already indicated
indicated this is not possible in all the scenarios. this is not possible in all the scenarios.
However, not having a DNS64, means that is not possible to The use of DNS64 is a key component for some networks, in order to
heuristically discover the NAT64 ([RFC7050]) and consequently, an comply with traffic performance metrics, monitored by some
IPv6 host in the IPv6-only access network, will not be able to detect governmental bodies and other institutions.
the presence of the NAT64, neither to learn the IPv6 prefix to be
used for it, unless it is configured by alternative means.
The learning of the IPv6 prefix could be solved by means of adding One drawback of not having a DNS64 at the network side, is that is
not possible to heuristically discover the NAT64 ([RFC7050]).
Consequently, an IPv6 host behind the IPv6-only access network, will
not be able to detect the presence of the NAT64 function, neither to
learn the IPv6 prefix to be used for it, unless it is configured by
alternative means.
The discovery of the IPv6 prefix could be solved by means of adding
the relevant AAAA records to the ipv4only.arpa. zone of the service the relevant AAAA records to the ipv4only.arpa. zone of the service
provider recursive servers, i.e., if using the WKP (64:ff9b::/96): provider recursive servers, i.e., 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 (Response An alternative option to the above, is the use of DNS RPZ
Policy Zones). ([I-D.vixie-dns-rpz]) or equivalent functionalities. Note that this
may impact DNSSEC if the zone is signed.
One more alternative, only valid in environments with PCP support One more alternative, only valid in environments with PCP support
(for both the hosts or CEs and for the service provider network), to (for both the hosts or CEs and for the service provider network), is
follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). to follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP).
Other alternatives may be available in the future, such as Router Other alternatives may be available in the future. All them are
Advertising ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options. extensively discussed in [RFC7051], however the deployment evolution
has evolved many considerations from that document. New options are
being documented, such using Router Advertising
([I-D.ietf-6man-ra-pref64]) or DHCPv6 options
([I-D.li-intarea-nat64-prefix-dhcp-option]).
It may be convenient to support at the same time several of the It may be convenient the simultaneous support of several of the
approaches described, in order to ensure that clients with different possible approaches, in order to ensure that clients with different
ways to configure the NAT64 prefix, successfully obtain it. This is ways to configure the NAT64 prefix, successfully obtain it. This is
also convenient even if DNS64 is being used. also convenient even if DNS64 is being used.
4.1.2. DNSSEC validator aware of DNS64 4.1.2. DNSSEC validator aware of DNS64
In general, DNS servers with DNS64 function, by default, 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 DNSSEC OK (DO) flag was set in the
query. In this case, as only an A record is available, it means that query. In this case, as only an A record is available, it means that
the CLAT will take the responsibility, as in the case of literal IPv4 the CLAT will take the responsibility, as in the case of literal IPv4
addresses, to keep that traffic flow end-to-end as IPv4, so DNSSEC is addresses, to keep that traffic flow end-to-end as IPv4, so DNSSEC is
not broken. However, this will not work if a CLAT is not present as not broken. However, this will not work if a CLAT function is not
the hosts will not be able to use IPv4 (scenarios without 464XLAT). present as the hosts will not be able to use IPv4 (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,
as the DNS64 recursive server will not synthesize AAAA responses, the the DNS64 recursive server will not synthesize AAAA responses. In
client could perform the DNSSEC validation with the A record and then this case, the client could perform the DNSSEC validation with the A
may query the network for a NAT64 prefix ([RFC7050], [RFC7225], record and then synthesize the AAAA ([RFC6052]). For that to be
[I-D.ietf-6man-ra-pref64] or other methods) in order to synthesize possible, the client must have learned beforehand the NAT64 prefix
the AAAA ([RFC6052]). This allow the client device to avoid using using any of the available methods ([RFC7050], [RFC7225],
the CLAT and still use NAT64 even with DNSSEC. [I-D.ietf-6man-ra-pref64],
[I-D.li-intarea-nat64-prefix-dhcp-option]). This allows the client
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 is not If the end-host is IPv4-only, this will not work if a CLAT function
present (scenarios without 464XLAT), unless the client is able to is not present (scenarios without 464XLAT).
locally perform the address synthesis.
Some devices/OSs may implement, instead of CLAT, a similar function Some devices or Operating Systems may implement, instead of a CLAT,
by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy an equivalent function by using Bump-in-the-Host ([RFC6535]),
Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the implemented as part of HEv2 (Section 7.1 of [RFC8305]). In this
considerations in the above paragraphs are also applicable. case, the considerations in the above paragraphs are also 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, following the same approach described behalf of the client devices. Then, following the same approach
in the precedent Section 4.1.3. So, the DNS proxy actually lies to described in the Section 4.1.3, the DNS proxy actually will "lie" to
the client devices, which in most of the cases will not notice it the client devices, which in most of the cases will not notice it,
unless they perform validation themselves. Again, this allow the unless they perform validation by themselves. Again, this allow the
client devices to avoid using the CLAT and still use NAT64 with client devices to avoid using the DNS64 function and still use NAT64
DNSSEC. with DNSSEC.
Once more, this will not work without a CLAT (scenarios without Once more, this will not work without a CLAT function (scenarios
464XLAT). without 464XLAT).
4.1.5. ACL of clients 4.1.5. ACL of clients
In cases of dual-stack clients, stub resolvers should send the AAAA In cases of dual-stack clients, the AAAA queries typically take
queries before the A ones. So, such clients, if DNS64 is enabled, preference over A queries. If DNS64 is enabled for those clients,
will never get A records, even for IPv4-only servers, and they may be will never get A records, even for IPv4-only servers. As a
in the path before the NAT64 and accessible by IPv4. If DNSSEC is consequence, if the IPv4-only servers are in the path before the
NAT64 function, the clients will never reach them. If DNSSEC is
being used for all those flows, specific addresses or prefixes can be being used for all those flows, specific addresses or prefixes can be
left-out the DNS64 synthesis by means of ACLs. left-out of the DNS64 synthesis by means of ACLs.
Once more, this will not work without a CLAT (scenarios without Once more, this will not work without a CLAT function (scenarios
464XLAT). 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 actually, quite commonly used to ensure that [RFC1918] addresses (for
example used by LAN servers) are not synthesized to AAAA. example used by LAN servers) are not synthesized to AAAA.
Once more, this will not work without a CLAT (scenarios without Once more, this will not work without a CLAT function (scenarios
464XLAT). without 464XLAT).
4.2. DNS64 and Reverse Mapping 4.2. DNS64 and Reverse Mapping
When a client device, using a name server configured to perform When a client device, using DNS64 tries to reverse-map a synthesized
DNS64, tries to reverse-map a synthesized IPv6 address, the name IPv6 address, the name server responds with a CNAME record pointing
server responds with a CNAME record pointing the domain name used to the domain name used to reverse-map the synthesized IPv6 address (the
reverse-map the synthesized IPv6 address (the one under ip6.arpa), to one under ip6.arpa), to the domain name corresponding to the embedded
the domain name corresponding to the embedded IPv4 address (under in- IPv4 address (under in-addr.arpa).
addr.arpa).
This is the expected behavior, so no issues 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 the case the client device is IPv6-only (either because the stack
or application is IPv6-only, or because it is connected via an or application is IPv6-only, or because it is connected via an
IPv6-only LAN) and the remote server is IPv4-only (either because the IPv6-only LAN) and the remote server is IPv4-only (either because the
stack is IPv4-only, or because it is connected via an IPv4-only LAN), stack is IPv4-only, or because it is connected via an IPv4-only LAN),
only NAT64 combined with DNS64 will be able to provide access among only NAT64 combined with DNS64 will be able to provide access among
both. Because DNS64 is then required, DNSSEC validation will be only both. Because DNS64 is then required, DNSSEC validation will be only
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 is not expected at this stage of the transition, that
applications or operating systems are IPv6-only, and it will not be a applications, devices or Operating Systems are IPv6-only. It will
sensible decision for a developer to work on that direction, unless not be a sensible decision for a developer to work on that direction,
it is clear that the deployment scenario allows it. On the other unless it is clear that the deployment scenario fully supports it.
hand, an end-user or enterprise network may decide to run IPv6-only
in the LANs, but in case there is any chance for applications to be On the other hand, an end-user or enterprise network may decide to
IPv6-only, the operating system may be responsible either for doing a run IPv6-only in the LANs. In case there is any chance for
local address synthesis, or alternatively, setting up some kind of applications to be IPv6-only, the Operating System may be responsible
on-demand VPN (IPv4-in-IPv6), which need to be supported by that either for doing a local address synthesis, or alternatively, setting
network. This may become very common in enterprise networks, where up some kind of on-demand VPN (IPv4-in-IPv6), which need to be
"Unique IPv6 Prefix per Host" [RFC8273]. supported by that network. This may become very common in enterprise
networks, where "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 (or has the built-in CLAT), DNS64 dual-stack LAN by means of a CLAT function (or has a built-in CLAT
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, so will use the IPv6 path and only one translation
will be done at the NAT64. This may break DNSSEC, unless will be done at the NAT64. This may break DNSSEC, unless
measures as described in the precedent sections are taken. measures as described in the precedent 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 avoids the AAAA terms of the extra NAT46 translation. However, this avoids the
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, and no at the CLAT, which means no extra overhead for the operator.
perceptible impact for a CE in a broadband network, while it may have However, adds potential extra delays to establish the connections,
some impact in a battery powered device. This cost for a battery and no perceptible impact for a CE in a broadband network, while it
powered device, is possibly comparable to the cost when the device is may have some impact in a battery powered device. This cost for a
doing a local address synthesis (see Section 7.1 of [RFC8305]). battery powered device, is possibly comparable to the cost when the
device is doing a local address synthesis (see Section 7.1 of
[RFC8305]).
4.4. Manual Configuration of Foreign DNS 4.4. Foreign DNS
When clients, in a service provider network, use DNS servers from Clients, devices or applications in a service provider network, may
other networks, for example manually configured by users, they may use DNS servers from other networks. This may be the case either if
support or not DNS64, so the considerations in Section 4.3 will apply individual applications use their own DNS server, the Operating
as well. System itself or even the CE, or combinations of the above.
Even in the case that the external DNS supports DNS64 function, we Those "foreign" DNS servers may not support DNS64, which will mean
may be in the situation of providing incorrect configurations that those scenarios that require a DNS64 may not work. However, if
parameters, for example un-matching WKP or NSP, or a case such the a CLAT function is available, the considerations in Section 4.3 will
one described in Section 3.2.3. apply.
A similar situation may happen in case of split DNS scenarios, for In the case that the foreign DNS supports the DNS64 function, we may
example, when using a VPN that forces all the DNS queries thru the be in the situation of providing incorrect configurations parameters,
VPN, ignoring the DNS64. for example un-matching WKP or NSP, or a case such the one described
in Section 3.2.3.
Having a CLAT, even if using an external DNS without DNS64, ensures Having a CLAT function, even if using foreign DNS without a DNS64
that everything will work, so the CLAT must be considered as an function, ensures that everything will work, so the CLAT must be
advantage against user configuration errors. considered as an advantage even against user configuration errors.
The cost of this, is that all the traffic will use a double
translation (NAT46 at the CLAT and NAT64 at the operator network),
unless there is support for EAMT (Section 4.9).
An exception to that is the case when there is a CLAT function at the
CE, which is not able to obtain the correct configuration parameters
(again, un-matching WKP or NSP).
However, it needs to be reinforced, that if there is not a CLAT However, it needs to be reinforced, that if there is not a CLAT
(scenarios without 464XLAT), an external DNS without DNS64 support, function (scenarios without 464XLAT), an external DNS without DNS64
will disallow any access to IPv4-only networks, and will not support, will disallow any access to IPv4-only destination networks,
guarantee DNSSEC, so will behave as in the Section 3.2.1. and will not guarantee DNSSEC, so will behave as in the
Section 3.2.1.
4.5. DNS Privacy The causes of "foreign DNS" could be classified in three main
categories, as depicted in the following sub-sections.
If clients use mechanisms for DNS privacy, such as DNS over TLS 4.4.1. Manual Configuration of Foreign DNS
([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS
([RFC8484]) or DNS over QUIC ([I-D.huitema-quic-dnsoquic]), as they
may provide different results to the same query, it must be expected
equivalent effects as described in Section 4.4.
4.6. Split DNS It is becoming increasingly common that end-users or even devices or
applications configure alternative DNS in their Operating Systems,
and sometimes in CEs.
As already indicated in precedent sections, the successful use of the 4.4.2. DNS Privacy
DNS64 is not guaranteed when networks or hosts can use "split-DNS"
(also called Split Horizon), private DNS. Section 4. of [RFC6950],
analyses this case. This a very common situation when using VPNs.
4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) A new trend is for clients or applications to use mechanisms for DNS
privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS
([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC
([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH
and DoQ.
Those DNS privacy/encryption options, currently are typically
provided by the applications, not the Operating System vendors. At
the time of writing this document, at least DoT and DoH standards
have declared DNS64 (and consequently NAT64) out of their scope, so
an application using them may break NAT64, unless a correctly
configured CLAT function is used.
4.4.3. Split DNS
When networks or hosts use "split-DNS" (also called Split Horizon,
DNS views or private DNS), the successful use of the DNS64 is not
guaranteed. Section 4 of [RFC6950], analyses this case.
A similar situation may happen in case of VPNs that force all the DNS
queries through the VPN, ignoring the operator DNS64 function.
4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP)
[RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), Section 3, [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), Section 3,
discusses some considerations which are useful to decide if an discusses some considerations which are useful to decide if an
operator should use the WKP or an NSP. operator should use the WKP or an NSP.
Taking in consideration that discussion and other issues, we can Taking in consideration that discussion and other issues, we can
summarize the possible decision points as: summarize the possible decision points as:
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 If this is required because the network to be translated use non-
non-global addresses then an NSP is required. 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 inter-domain routing tables, if the
operator provides NAT64 to peers, however special considerations operator provides a NAT64 function to peers. However, in this
related to BGP filtering are then required and IPv4-embedded IPv6 case, special considerations related to BGP filtering are
prefixes longer than the WKP MUST NOT be advertised in BGP. An required and IPv4-embedded IPv6 prefixes longer than the WKP MUST
NSP may be a more appropriate option in those cases. NOT be advertised (or accepted) in BGP. An NSP may be a more
appropriate option in those cases.
c. If several NAT64s use the same prefix, packets from the same flow c. If several NAT64 use the same prefix, packets from the same flow
may be routed to different NAT64s in case of routing changes. may be routed to different NAT64 in case of routing changes.
This can be avoided either by using different prefixes for each This can be avoided either by using different prefixes for each
NAT64, or by ensuring that all the NAT64s coordinate their state. NAT64 function, or by ensuring that all the NAT64 coordinate
Using an NSP could facilitate that. their state. Using an NSP could simplify that.
d. If DNS64 is required and users may change their DNS d. If DNS64 is required and users, devices, Operating Systems or
configuration, and deliberately choose an alternative DNS64, most applications may change their DNS configuration, and deliberately
probably alternative DNS64s will use by default the WKP. In that choose an alternative DNS64 function, most probably alternative
case, if an NSP is used by the NAT64, the users will not be able DNS64 will use by default the WKP. In that case, if an NSP is
to use the operator NAT64. used by the NAT64 function, clients will not be able to use the
operator NAT64 function, which will break connectivity to
IPv4-only destinations.
4.8. IPv4 literals and old APIs 4.6. IPv4 literals and old APIs
A hosts or application using literal IPv4 addresses or older APIs, A host or application using literal IPv4 addresses or older APIs,
behind a network with IPv6-only access, will not work unless a CLAT behind a network with IPv6-only access, will not work unless any of
(or equivalent function) is present. the following alternatives is provided:
A possible alternative approach is described as part of Happy o CLAT (or equivalent function).
Eyeballs v2 Section 7.1 ([RFC8305]). When HEv2 is not supported, one
more alternative is using Bump-in-the-Host ([RFC6535]), and then a
DNS64 function.
Those alternatives will solve the problem for and end-hosts, however, o HEv2 (Section 7.1, [RFC8305]).
o Bump-in-the-Host ([RFC6535]) with a DNS64 function.
Those alternatives will solve the problem for an end-host. However,
if that end-hosts is providing "tethering" or an equivalent service if that end-hosts is providing "tethering" or an equivalent service
to others hosts, that need to be considered as well. In other words, to other hosts, that needs to be considered as well. In other words,
in a case of a cellular network, it resolves the issue for the UE in a case of a cellular network, it resolves the issue for the UE
itself, but may be not the case for hosts behind it. itself, but may be not the case for hosts behind it.
Otherwise, 464XLAT is the only valid approach to resolve this issue. Otherwise, the support of 464XLAT is the only valid and complete
approach to resolve this issue.
4.9. IPv4-only Hosts or Applications 4.7. IPv4-only Hosts or Applications
An IPv4-only hosts or application behind a network with IPv6-only An IPv4-only hosts or application behind a network with IPv6-only
access, will not work unless a CLAT is present. 464XLAT is the only access, will not work unless a CLAT function is present.
valid approach to resolve this issue.
4.10. CLAT Translation Considerations 464XLAT is the only valid approach to resolve this issue.
4.8. CLAT Translation Considerations
As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if
the CLAT can be configured with a dedicated /64 prefix for the NAT46 the CLAT function can be configured with a dedicated /64 prefix for
translation, then it will be possible to do a more efficient the NAT46 translation, then it will be possible to do a more
stateless translation. efficient stateless translation.
However, if this dedicated prefix is not available, the CLAT will Otherwise, if this dedicated prefix is not available, the CLAT
need to do a stateful translation, for example performing stateful function will need to do a stateful translation, for example
NAT44 for all the IPv4 LAN packets, so they appear as coming from a performing stateful NAT44 for all the IPv4 LAN packets, so they
single IPv4 address, and then in turn, stateless translated to a appear as coming from a single IPv4 address, and then in turn,
single IPv6 address. stateless translated to a single IPv6 address.
One 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, so the CE can 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), as generally they don't use
DHCPv6-PD ([RFC8415]) an instead a single /64 is provided for each DHCPv6-PD ([RFC8415]). Instead, a single /64 is provided for each
PDP context and use /64 prefix sharing ([RFC6877]). So, in this PDP context and prefix sharing ([RFC6877]) is used. So, in this
case, the UEs typically have a build-in CLAT client, which is doing a case, the UEs typically have a build-in CLAT function which is
stateful NAT44 before the stateless NAT46. performing a stateful NAT44 translation before the stateless NAT46.
4.11. EAMT Considerations
Explicit Address Mappings for Stateless IP/ICMP Translation [RFC7757] 4.9. EAMT Considerations
provides a way to configure explicit mappings between IPv4 and IPv6
prefixes of any length. When this is used, for example in a CLAT, it
may provide a simple mechanism in order to avoid traffic flows
between IPv4-only nodes or applications and dual-stack destinations
to be translated twice (NAT46 and NAT64), by creating mapping entries
with the GUA of the IPv6-reachable destination. This optimization of
the NAT64 usage is very useful in many scenarios, including CDNs and
caches, as described in [I-D.palet-v6ops-464xlat-opt-cdn-caches].
5. Summary of Deployment Recommendations for NAT64/464XLAT Explicit Address Mappings for Stateless IP/ICMP Translation
([RFC7757]) provide a way to configure explicit mappings between IPv4
and IPv6 prefixes of any length. When this is used, for example in a
CLAT function, it may provide a simple mechanism in order to avoid
traffic flows between IPv4-only nodes or applications and dual-stack
destinations to be translated twice (NAT46 and NAT64), by creating
mapping entries with the GUA of the IPv6-reachable destination. This
optimization of the NAT64 usage is very useful in many scenarios,
including CDNs and caches, as described in
[I-D.palet-v6ops-464xlat-opt-cdn-caches].
It can be argued that none of the possible transition mechanisms is In addition to that, it may provide as well a way for IPv4-only nodes
perfect, and somehow, we may consider that actually this is a good or applications to communicate with IPv6-only destinations.
thing as a way to push for the IPv6 deployment, or otherwise, it may
be further delayed, with clear undesirable effects for the global
Internet.
However, for an operator, being in business means minimizing the 5. Summary of Deployment Recommendations for NAT64/464XLAT
adverse transition effects, and provide the most perfect one,
reasonably balanced with cost (CAPEX/OPEX) and at the same time,
looking for a valid long-term vision.
NAT64/464XLAT has demonstrated to be a valid choice in several NAT64/464XLAT has demonstrated to be a valid choice in several
scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions
of users, offering different choices of deployment, depending on each of users, offering different choices of deployment, depending on each
network case, needs and requirements. network case, needs and requirements. Despite that, this document is
not an explicit recommendation for using this choice versus other
Depending on those requirements, DNS64 may be a required function, IPv4aaS transition mechanisms. Instead, this document is a guide
while in other cases the adverse effects may be counterproductive. that facilitates evaluating a possible implementation of
Similarly, in some cases NAT64, together with DNS64, may be a valid NAT64/464XLAT and key decision points about specific design
solution, when for sure there is no need to support hosts or considerations for its deployment.
applications which are IPv4-only (Section 4.8 and Section 4.9).
However, in other cases the limitations they have, may suggest the
operator to look into 464XLAT as a more complete solution.
Service providers willing to deploy NAT64, need to take into account Depending on the specific requirements of each deployment case, DNS64
the considerations of this document in order to better decide what is may be a required function, while in other cases the adverse effects
more appropriate for their own specific case. may be counterproductive. Similarly, in some cases a NAT64 function,
together with a DNS64 function, may be a valid solution, when there
is a certainty that IPv4-only hosts or applications do not need to be
supported (Section 4.6 and Section 4.7). However, in other cases
(i.e. IPv4-only devices or applications need to be supported), the
limitations of NAT64/DNS64, may suggest the operator to look into
464XLAT as a more complete solution.
In the case of broadband managed networks (CE provided or suggested/ In the case of broadband managed networks (where the CE is provided
supported by the operator), in order to fully support the actual user or suggested/supported by the operator), in order to fully support
needs (IPv4-only devices and applications, usage of literals and old the actual user needs (IPv4-only devices and applications, usage of
APIs), they should consider the 464XLAT scenario and in that case, IPv4 literals and old APIs), the 464XLAT scenario should be
must support the customer-side translator (CLAT). considered. In that case, it must support a CLAT function.
If the operator offers DNS services, in order to increase performance If the operator provides DNS services, in order to increase
by reducing the double translation for all the IPv4 traffic, they may performance by reducing the double translation for all the IPv4
support DNS64 and avoid, as much as possible, breaking DNSSEC. In traffic, they may support a DNS64 function and avoid, as much as
this case, if the DNS service is offering DNSSEC validation, then it possible, breaking DNSSEC. In this case, if the DNS service is
must be in such way that it is aware of the DNS64. This is offering DNSSEC validation, then it must be in such way that it is
considered the simpler and safer approach, and may be combined as aware of the DNS64. This is considered the simpler and safer
well with the other possible recommendations described in this approach, and may be combined as well with other recommendations
document: described in this document:
o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2).
o Devices running CLAT SHOULD follow the indications in o Devices running CLAT SHOULD follow the indications in
Section 4.1.3 (Stub validator). However, this may be out of the Section 4.1.3 (Stub Validator). 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). o 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 o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4
addresses) MAY be considered by operators, depending on their own addresses) MAY be considered by operators, depending on their own
infrastructure. 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 he NAT64 prefix. Section 4.1.1, must be followed in order to learn he NAT64 prefix.
The operator needs to consider that if the user can modify the DNS The operator needs to consider that if the DNS configuration can be
configuration (which most probably is impossible to avoid), and modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most
instead of configuring a DNS64 choose an external regular DNS (non- probably is impossible to avoid, there are chances that instead of
DNS64), a scenario with only NAT64 will not work with any IPv4-only configuring a DNS64 a foreign non-DNS64 is used. In a scenario with
remote host, while it will continue working in the case of 464XLAT only a NAT64 function IPv4-only remote host will no longer be
(Section 4.4). Same effects are to be expected if DNS privacy accesible. Instead, it will continue to work in the case of 464XLAT.
protocols are being used by customers (Section 4.5), as well as in
the case of Split DNS (Section 4.6).
Similar considerations need to be taken regarding the usage of a Similar considerations need to be taken regarding the usage of a
NAT64 Well-Known-Prefix (WKP) vs Network-Specific Prefix (NSP) NAT64 WKP vs NSP (Section 4.5), as they must match with the
(Section 4.7), in the sense of, if using DNS64, they must match and, configuration of the DNS64. In case of using foreign DNS, they may
if the user can change the DNS configuration, they will, most not match. If there is a CLAT and the configured foreign DNS is not
probably, not match. If there is a CLAT and the users chosen DNS is a DNS64, the network will keep working only if other means of
not a DNS64, the network will keep working of other means of learning learning the NAT64 prefix are available.
the NAT64 are available.
As described in Section 4.10 in broadband networks, it is recommended As described in Section 4.8, for broadband networks, the CEs
that CEs supporting CLAT, supports DHCPv6-PD ([RFC8415]), or supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or
alternative means for configuring a shorter prefix, and internally alternative means for configuring a shorter prefix. The CE SHOULD
reserve one /64 for the stateless NAT46 translation. The operator internally reserve one /64 for the stateless NAT46 translation. The
must ensure that the customers get allocated prefixes shorter than operator must ensure that the customers get allocated prefixes
/64 in order to support this optimization. One way or the other, shorter than /64 in order to support this optimization. One way or
this is not impacting the performance of the operator network. the other, this is not impacting the performance of the operator
network.
Operators may follow Section 7 of [RFC6877] (Deployment Operators may follow Section 7 of [RFC6877] (Deployment
Considerations), for suggestions in order to take advantage of Considerations), for suggestions in order to take advantage of
traffic engineering requirements. traffic engineering requirements.
In the case of cellular networks, the considerations regarding DNSSEC In the case of cellular networks, the considerations regarding DNSSEC
may appear as out-of-scope, because UEs OSs, commonly don't support may appear as out-of-scope, because UEs Operating Systems, commonly
DNSSEC, however applications running on them may do, or it may be an don't support DNSSEC. However, applications running on them may do,
OS "built-in" support in the future. Moreover, if those devices or it may be an Operating System "built-in" support in the future.
offer tethering, other client devices behind the UE, may be doing the Moreover, if those devices offer tethering, other client devices
validation, hence the relevance of a proper DNSSEC support by the behind the UE, may be doing the validation, hence the relevance of a
operator network. proper DNSSEC support by the operator network.
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 APN
supporting all types of PDP context (IPv4, IPv6, IPv4v6), in such way supporting all types of PDP context (IPv4, IPv6, IPv4v6). This
that the network is able to automatically serve every possible approach allows the network to automatically serve every possible
combinations of UEs. combinations 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 Section 3.1. of [RFC7050]
(Validation of Discovered Pref64::/n). (Validation of Discovered Pref64::/n).
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 requiring 464XLAT, others not requiring it, customers requiring
DNS64, others not, etc. In general, the different issues and the DNS64, others not, etc. In general, the different issues and the
approaches described in this document can be implemented at the same approaches described in this document can be implemented at the same
time for different customers or parts of the network. That mix of time for different customers or parts of the network. That mix of
approaches don't present any problem or incompatibility, as they work approaches don't present any problem or incompatibility, as they work
well together, being just a matter of appropriate and differentiated well together, being just a matter of appropriate and differentiated
provisioning. provisioning. In fact, the NAT64/464XLAT approach facilitates an
operator offering both cellular and broadband services, to have a
single IPv4aaS for both networks while differentiating the deployment
key decisions to optimize each case. It even makes possible using
hybrid CEs that have a main broadband access link and a backup via
the cellular network.
In an ideal world will, we could safely use DNS64, if the approach In an ideal world we could safely use DNS64, if the approach proposed
proposed in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, avoiding the
avoiding the cases where DNSSEC may be broken. However, this will cases where DNSSEC may be broken. However, this will not solve the
not solve the issues related to DNS Privacy and Split DNS. issues related to DNS Privacy and Split DNS.
The only 100% safe solution, which also resolves all the issues, will The only 100% safe solution, which also resolves all the issues, will
be, in addition to having a CLAT, not using a DNS64 but instead be, in addition to having a CLAT function, not using a DNS64 but
making sure that the hosts have a built-in address synthesis feature. instead making sure that the hosts have a built-in address synthesis
Operators could manage to use the CLAT, however the built-in address feature. Operators could manage to provide CEs with the CLAT
synthesis feature is out of their control, and can only be resolved function, however the built-in address synthesis feature is out of
by operating system vendors. their control. If the synthesis is provided either by the Operating
System (via its DNS resolver API) or by the application (via its own
DNS resolver), in such way that the prefix used for the NAT64
function is reachable for the host, the problem goes away.
Whenever feasible, using EAMT ([RFC7757]) as indicated in Whenever feasible, using EAMT ([RFC7757]) as indicated in
Section 4.11, provides a very relevant optimization, avoiding double- Section 4.9, provides a very relevant optimization, avoiding double-
translations. translations.
6. Deployment of NAT64 in Enterprise Networks 6. Deployment of NAT64 in Enterprise Networks
The recommendations of this document can be used as well in The recommendations of this document can be used as well in
enterprise networks, campus and other similar scenarios (including enterprise networks, campus and other similar scenarios (including
managed end-user networks). managed end-user networks).
This include scenarios where the NAT64 (and/or DNS64) are under the This include scenarios where the NAT64 function (and DNS64 function,
control of that network (or can be configured manually according to if available) are under the control of that network (or can be
that network specific requirements), and for whatever reasons, there configured manually according to that network specific requirements),
is a need to provide "IPv6-only access" to any part of that network and for whatever reasons, there is a need to provide "IPv6-only
or it is IPv6-only connected to third party networks. access" to any part of that network or it is IPv6-only connected to
third party-networks.
An example of that is the IETF meetings network itself, where a NAT64 An example of that is the IETF meetings network itself, where both
and DNS64 are provided, presenting in this case the same issues as NAT64 and DNS64 functions are provided, presenting in this case the
per Section 3.1.1. If there is a CLAT in the IETF network, then same issues as per Section 3.1.1. If there is a CLAT function in the
there is no need to use DNS64 and it falls under the considerations IETF network, then there is no need to use DNS64 and it falls under
of Section 3.1.3. Both scenarios have been tested and verified the considerations of Section 3.1.3. Both scenarios have been tested
already in the IETF network itself. and verified already in the IETF network itself.
Next figures are only meant to represent a few of the possible Next figures are only meant to represent a few of the possible
scenarios, not pretending to be the only feasible ones. scenarios, not pretending to be the only feasible ones.
The following figure provides an example of and IPv6-only enterprise The following figure provides an example of an IPv6-only enterprise
network connected with dual-stack to Internet and using local NAT64 network connected with dual-stack to Internet and using local NAT64
and DNS64. and 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 14: IPv6-only enterprise with NAT64 and DNS64
The following figure provides an example of dual-stack (DS) The following figure provides an example of a dual-stack (DS)
enterprise network connected with dual-stack (DS) to Internet and enterprise network connected with dual-stack (DS) to Internet and
using CLAT, without DNS64. using a CLAT function, without a DNS64 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 15: DS enterprise with CLAT, DS Internet, without DNS64
Finally, the following figure provides an example of an IPv6-only Finally, the following figure provides an example of an IPv6-only
provider with NAT64, and a dual-stack (DS) enterprise network by provider with a NAT64 function, and a dual-stack (DS) enterprise
means of their own CLAT, without DNS64. network by means of their own 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 Internet, without DNS64 Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64
7. Security Considerations 7. Security Considerations
This document does not have any new specific security considerations. This document does not have new specific security considerations
beyond those already reported by each of the documents cited.
8. IANA Considerations 8. IANA Considerations
This document does not have any new specific IANA considerations. This document does not have any new specific IANA considerations.
Note: This section is assuming that https://www.rfc- Note: This section is assuming that https://www.rfc-
editor.org/errata/eid5152 is resolved, otherwise, this section may editor.org/errata/eid5152 is resolved, otherwise, this section may
include the required text to resolve the issue. include the required text to resolve the issue.
9. Acknowledgements 9. Acknowledgements
The author would like to acknowledge the inputs of Gabor Lencse, The author would like to acknowledge the inputs of Gabor Lencse,
Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed
Boucadair and TBD ... Boucadair, Alejandro D'Egidio, Dan Wing and Mikael Abrahamsson.
Conversations with Marcelo Bagnulo, one of the co-authors of NAT64 Conversations with Marcelo Bagnulo, one of the co-authors of NAT64
and DNS64, as well as several emails in mailing lists from Mark and DNS64, as well as several emails in mailing lists from Mark
Andrews, have been very useful for this work. Andrews, have been very useful for this work.
Christian Huitema inspired working in this document by suggesting Christian Huitema inspired working in this document by suggesting
that DNS64 should never be used, during a discussion regarding the that DNS64 should never be used, during a discussion regarding the
deployment of CLAT in the IETF network. deployment of CLAT in the IETF network.
10. ANNEX A: Example of Broadband Deployment with 464XLAT 10. ANNEX A: Example of Broadband Deployment with 464XLAT
This section summarizes how an operator may deploy an IPv6-only This section summarizes how an operator may deploy an IPv6-only
network for residential/SOHO customers, supporting IPv6 inbound network for residential/SOHO customers, supporting IPv6 inbound
connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT. connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT.
Note that an equivalent setup could also be provided for enterprise Note that an equivalent setup could also be provided for enterprise
customers. In case they need to support IPv4 inbound connections, customers. In case they need to support IPv4 inbound connections,
several mechanisms, depending on specific customer needs, allow that. several mechanisms, depending on specific customer needs, allow that,
for instance [RFC7757].
Conceptually, most of the operator network could be IPv6-only Conceptually, most part of the operator network could be IPv6-only
(represented in the next pictures as "IPv6-only Internet"). This (represented in the next pictures as "IPv6-only flow"), or even if
part of the network connects the IPv6-only subscribers (by means of 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 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 to the IPv4-Internet by means of the NAT64 (PLAT in the 464XLAT
terminology). terminology).
The traffic flow from and back to the CE to services available in the 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 IPv6 Internet (or even dual-stack remote services, when IPv6 is being
used), is purely native IPv6 traffic, so no special considerations used), is purely native IPv6 traffic, so there are no special
about it. considerations about it.
Looking at the picture from the DNS perspective, there are remote Looking at the picture from the DNS perspective, there are remote
networks with are IPv4-only, and typically will have only IPv4 DNS 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. (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 At the operator side, the DNS, as seen from the CE, is only IPv6
(DNS/IPv6) and has also a DNS64 function. (DNS/IPv6) and has also a DNS64 function.
In the customer LANs side, there is actually one network, which of In the customer LANs side, there is actually one network, which of
course could be split in different segments, and the most common course could be split in different segments. The most common setup
setup will be those segments being dual-stack (global IPv6 addresses will be those segments being dual-stack, using global IPv6 addresses
and [RFC1918] for IPv4, as usual in any regular residential/SOHO IPv4 and [RFC1918] for IPv4, as usual in any regular residential/SOHO IPv4
network today). In the figure it is represented as tree segments, network. In the figure, it is represented as tree segments, just to
just to show that the three possible setups are valid (IPv6-only, show that the three possible setups are valid (IPv6-only, IPv4-only
IPv4-only and dual-stack). and dual-stack).
.-----. +-------+ .-----. .-----. .-----. +-------+ .-----. .-----.
/ IPv6- \ | | / \ / \ / IPv6- \ | | / \ / \
( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \
\ LANs / | SOHO +--( only )--( NAT64 )--( only ) \ LANs / | SOHO +--( only )--( NAT64 )--( only )
`-----' | | \ Internet/ `-----' \ Internet/ `-----' | | \ flow / `-----' \ flow /
.-----. | IPv6 | \ / \ / .-----. | IPv6 | \ / \ /
/ IPv4- \ | CE | `--+--' `--+--' / IPv4- \ | CE | `--+--' `--+--'
( only )--+ with | | | ( only )--+ with | | |
\ LANs / | CLAT | +---+----+ +---+----+ \ LANs / | CLAT | +---+----+ +---+----+
`-----' | | |DNS/IPv6| |DNS/IPv4| `-----' | | |DNS/IPv6| |DNS/IPv4|
.-----. +---+---+ | with | +--------+ .-----. +---+---+ | with | +--------+
/ Dual- \ | | DNS64 | / Dual- \ | | DNS64 |
( Stack )------| +--------+ ( Stack )------| +--------+
\ LANs / \ LANs /
`-----' `-----'
Figure 17: CE setup with built-in CLAT with DNS64 Figure 17: CE setup with built-in CLAT with DNS64
In addition to the regular CE setup, which will be typically access- In addition to the regular CE setup, which will be typically access-
technology dependent, the steps for the CLAT configuration can be technology dependent, the steps for the CLAT function configuration
summarized as: can be summarized as:
1. Discovery of the PLAT (NAT64) prefix: It may be done using 1. Discovery of the PLAT (NAT64) prefix: It may be done using
[RFC7050], or in those networks where PCP is supported, by means [RFC7050], or in those networks where PCP is supported, by means
of [RFC7225], or other alternatives that may be available in the of [RFC7225], or other alternatives that may be available in the
future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or
DHCPv6 options. DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]).
2. If the CLAT allows stateless NAT46 translation, a /64 from the 2. If the CLAT function allows stateless NAT46 translation, a /64
pool typically provided to the CE by means of DHCPv6-PD from the pool typically provided to the CE by means of DHCPv6-PD
[RFC8415], need to be set aside for that translation. Otherwise, [RFC8415], need to be set aside for that translation. Otherwise,
the CLAT is forced to perform an intermediate stateful NAT44 the CLAT is forced to perform an intermediate stateful NAT44
before the a stateless NAT46, as described in Section 4.10. before the a stateless NAT46, as described in Section 4.8.
A more detailed configuration approach is described in A more detailed configuration approach is described in
[I-D.ietf-v6ops-transition-ipv4aas]. [I-D.ietf-v6ops-transition-ipv4aas].
The operator network needs to ensure that the correct responses are The operator network needs to ensure that the correct responses are
provided for the discovery of the PLAT prefix, as well as it is provided for the discovery of the PLAT prefix. It is highly
highly recommended follows [RIPE-690], in order to ensure that recommended to follow [RIPE-690], in order to ensure that multiple
multiple /64s are available including the one needed for the NAT46 /64s are available, including the one needed for the NAT46 stateless
stateless translation. translation.
The operator needs to understand other issues, described across this The operator needs to understand other issues, described across this
document, in order to take the relevant decisions. For example, if document, in order to take the relevant decisions. For example, if
several NAT64 are needed in the context of scalability/high- several NAT64 functions are needed in the context of scalability/
availability, an NSP should be considered (Section 4.7). high-availability, an NSP should be considered (Section 4.5).
More complex scenarios are possible, for example, if a network offers More complex scenarios are possible, for example, if a network offers
multiple NAT64 prefixes, destination-based NAT64 prefixes, etc. multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.
If the operator decides not to provide DNS64, then this setup turns If the operator decides not to provide a DNS64 function, then this
into the one in the following Figure. This will be also the setup setup turns into the one in the following Figure. This will be also
that, if the user has changed the DNS and consequently is not using the setup that "will be seen" from the perspective of the CE, if a
the operator DNS64, "it will be seen" from the perspective of the CE. foreign DNS is used and consequently is not the operator-provided
DNS64 function.
.-----. +-------+ .-----. .-----. .-----. +-------+ .-----. .-----.
/ IPv6- \ | | / \ / \ / IPv6- \ | | / \ / \
( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \
\ LANs / | SOHO +--( only )--( NAT64 )--( only ) \ LANs / | SOHO +--( only )--( NAT64 )--( only )
`-----' | | \ Internet/ `-----' \ Internet/ `-----' | | \ flow / `-----' \ flow /
.-----. | IPv6 | \ / \ / .-----. | IPv6 | \ / \ /
/ IPv4- \ | CE | `--+--' `--+--' / IPv4- \ | CE | `--+--' `--+--'
( only )--+ with | | | ( only )--+ with | | |
\ LANs / | CLAT | +---+----+ +---+----+ \ LANs / | CLAT | +---+----+ +---+----+
`-----' | | |DNS/IPv6| |DNS/IPv4| `-----' | | |DNS/IPv6| |DNS/IPv4|
.-----. +---+---+ +--------+ +--------+ .-----. +---+---+ +--------+ +--------+
/ Dual- \ | / Dual- \ |
( Stack )------| ( Stack )------|
\ LANs / \ LANs /
`-----' `-----'
Figure 18: CE setup with built-in CLAT without DNS64 Figure 18: CE setup with built-in CLAT without DNS64
In this case, the discovery of the PLAT prefix need to be arranged as In this case, the discovery of the PLAT prefix needs to be arranged
indicated in Section 4.1.1. as indicated in Section 4.1.1.
In this case, the CE doesn't have a built-in CLAT, or the customer In this case, the CE doesn't have a built-in CLAT function, or the
can choose to setup the IPv6 operator-managed CE in bridge mode (and customer can choose to setup the IPv6 operator-managed CE in bridge
optionally use its own external router), or for example, there is an mode (and optionally use an external router), or for example, there
access technology that requires some kind of media converter (ONT for is an access technology that requires some kind of media converter
FTTH, CableModem for DOCSIS, etc.), the complete setup will look as (ONT for FTTH, CableModem for DOCSIS, etc.), the complete setup will
in the next figure. Obviously, there will be some intermediate look as in the next figure. Obviously, there will be some
configuration steps for the bridge, depending on the specific access intermediate configuration steps for the bridge, depending on the
technology/protocols, which should not modify the steps already specific access technology/protocols, which should not modify the
described in the previous cases for the CLAT configuration. steps already described in the previous cases for the CLAT function
configuration.
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
| Res./ | / IPv6- \ .-----. / IPv4- \ | Res./ | / IPv6- \ .-----. / IPv4- \
| SOHO +--( only )--( NAT64 )--( only ) | SOHO +--( only )--( NAT64 )--( only )
| | \ Internet/ `-----' \ Internet/ | | \ flow / `-----' \ flow /
| IPv6 | \ / \ / | IPv6 | \ / \ /
| CE | `--+--' `--+--' | CE | `--+--' `--+--'
| Bridge| | | | Bridge| | |
| | +---+----+ +---+----+ | | +---+----+ +---+----+
| | |DNS/IPv6| |DNS/IPv4| | | |DNS/IPv6| |DNS/IPv4|
+---+---+ +--------+ +--------+ +---+---+ +--------+ +--------+
| |
.-----. +---+---+ .-----. +---+---+
/ IPv6- \ | | / IPv6- \ | |
( only )--+ IPv6 | ( only )--+ IPv6 |
skipping to change at page 32, line 50 skipping to change at page 36, line 10
HNCP ([RFC8375]). HNCP ([RFC8375]).
Note that the procedure described here for the CE setup, can be Note that the procedure described here for the CE setup, can be
simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas]. simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas].
11. ANNEX B: CLAT Implementation 11. ANNEX B: CLAT Implementation
In addition to the regular set of features for a CE, a CLAT CE In addition to the regular set of features for a CE, a CLAT CE
implementation requires support of: implementation requires support of:
o [RFC7915], for the NAT46 functionality. o [RFC7915] for the NAT46 function.
o [RFC7050], for the PLAT prefix discovery. o [RFC7050] for the PLAT prefix discovery.
o [RFC7225], for the PLAT prefix discovery if PCP is supported. 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 o [I-D.ietf-6man-ra-pref64] for the PLAT prefix discovery by means
of Router Advertising. of Router Advertising.
o If stateless NAT46 is supported, a mechanism to ensure that o If stateless NAT46 is supported, a mechanism to ensure that
multiple /64 are available, such as DHCPv6-PD [RFC8415]. multiple /64 are available, such as DHCPv6-PD [RFC8415].
There are several OpenSource implementations of CLAT, such as: There are several OpenSource implementations of CLAT, such as:
o Android: https://github.com/ddrown/android_external_android-clat. o Android: https://github.com/ddrown/android_external_android-clat.
o Jool: https://www.jool.mx.
o Linux: https://github.com/toreanderson/clatd. o Linux: https://github.com/toreanderson/clatd.
o OpenWRT: https://github.com/openwrt- o OpenWRT: https://github.com/openwrt-
routing/packages/blob/master/nat46/files/464xlat.sh. routing/packages/blob/master/nat46/files/464xlat.sh.
o VPP: https://git.fd.io/vpp/tree/src/plugins/nat. o VPP: https://git.fd.io/vpp/tree/src/plugins/nat.
12. ANNEX C: Benchmarking 12. ANNEX C: Benchmarking
Several documents provide references to benchmarking, for example in [RFC8219] has defined a benchmarking methodology for IPv6 transition
the case of DNS64, [DNS64-Benchm]. 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].
13. ANNEX D: Changes from -00 to -01 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: Section to be removed after WGLC. Significant updates are:
1. Text changes across all the document. 1. Text changes across all the document.
14. ANNEX E: Changes from -01 to -02 14. ANNEX E: Changes from -02 to -03
Section to be removed after WGLC. Significant updates are: Section to be removed after WGLC. Significant updates are:
1. Added references to new cited documents. 1. Added references to new cited documents.
2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only 2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only
LANs w/o DNS64. LANs w/o DNS64.
3. Overall review and editorial changes. 3. Overall review and editorial changes.
15. ANNEX F: Changes from -02 to -03 15. ANNEX F: Changes from -03 to -04
Section to be removed after WGLC. Significant updates are: Section to be removed after WGLC. Significant updates are:
1. Added text related to EAMT considerations. 1. Added text related to EAMT considerations.
16. References 16. ANNEX G: Changes from -04 to -05
16.1. Normative References Section to be removed after WGLC. Significant updates are:
1. Added cross references to EAMT section.
2. Reworded "foreing DNS section".
3. Overall editorial review of text, pictures and nits correction.
17. References
17.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", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <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>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<https://www.rfc-editor.org/info/rfc5625>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010, DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>. <https://www.rfc-editor.org/info/rfc6052>.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
April 2011, <https://www.rfc-editor.org/info/rfc6144>. April 2011, <https://www.rfc-editor.org/info/rfc6144>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
skipping to change at page 34, line 49 skipping to change at page 38, line 35
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, Using "Bump-in-the-Host" (BIH)", RFC 6535,
DOI 10.17487/RFC6535, February 2012, DOI 10.17487/RFC6535, February 2012,
<https://www.rfc-editor.org/info/rfc6535>. <https://www.rfc-editor.org/info/rfc6535>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013, RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>. <https://www.rfc-editor.org/info/rfc6877>.
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
"Analysis of Stateful 64 Translation", RFC 6889,
DOI 10.17487/RFC6889, April 2013,
<https://www.rfc-editor.org/info/rfc6889>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013, RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>. <https://www.rfc-editor.org/info/rfc7050>.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225, Port Control Protocol (PCP)", RFC 7225,
DOI 10.17487/RFC7225, May 2014, DOI 10.17487/RFC7225, May 2014,
<https://www.rfc-editor.org/info/rfc7225>. <https://www.rfc-editor.org/info/rfc7225>.
skipping to change at page 36, line 5 skipping to change at page 39, line 37
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[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>.
16.2. Informative References 17.2. Informative References
[About-DNS64] [About-DNS64]
APNIC Blog, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016,
<https://blog.apnic.net/2016/06/09/ <https://blog.apnic.net/2016/06/09/
lets-talk-ipv6-dns64-dnssec/>. lets-talk-ipv6-dns64-dnssec/>.
[DNS64-Benchm] [DNS64-Benchm]
"Benchmarking DNS64 Implementations: Theory and Practice", Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64
Computer Communications (Elsevier), vol. 127, no. 1, Implementations: Theory and Practice", Computer
pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September Communications , vol. 127, no. 1, pp. 61-74,
2018. DOI 10.1016/j.comcom.2018.05.005, September 2018.
[DNS64-BM-Meth]
Lencse, G., Georgescu, M., and Y. Kadobayashi,
"Benchmarking Methodology for DNS64 Servers", Computer
Communications , vol. 109, no. 1, pp. 162-175,
DOI 10.1016/j.comcom.2017.06.004, September 2017.
[I-D.bp-v6ops-ipv6-ready-dns-dnssec] [I-D.bp-v6ops-ipv6-ready-dns-dnssec]
Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC
Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00 Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00
(work in progress), October 2018. (work in progress), October 2018.
[I-D.huitema-quic-dnsoquic] [I-D.huitema-quic-dnsoquic]
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
Iyengar, "Specification of DNS over Dedicated QUIC Iyengar, "Specification of DNS over Dedicated QUIC
Connections", draft-huitema-quic-dnsoquic-06 (work in Connections", draft-huitema-quic-dnsoquic-06 (work in
skipping to change at page 36, line 40 skipping to change at page 40, line 33
Colitti, L., Kline, E., and J. Linkova, "Discovering Colitti, L., Kline, E., and J. Linkova, "Discovering
PREF64 in Router Advertisements", draft-ietf-6man-ra- PREF64 in Router Advertisements", draft-ietf-6man-ra-
pref64-00 (work in progress), March 2019. pref64-00 (work in progress), March 2019.
[I-D.ietf-v6ops-transition-ipv4aas] [I-D.ietf-v6ops-transition-ipv4aas]
Palet, J., Liu, H., and M. Kawashima, "Requirements for Palet, J., Liu, H., and M. Kawashima, "Requirements for
IPv6 Customer Edge Routers to Support IPv4 Connectivity IPv6 Customer Edge Routers to Support IPv4 Connectivity
as-a-Service", draft-ietf-v6ops-transition-ipv4aas-15 as-a-Service", draft-ietf-v6ops-transition-ipv4aas-15
(work in progress), January 2019. (work in progress), January 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-01 (work in progress),
March 2017.
[I-D.lmhp-v6ops-transition-comparison]
Lencse, G., Palet, J., Howard, L., Patterson, R., and I.
Farrer, "Pros and Cons of IPv6 Transition Technologies for
IPv4aaS", draft-lmhp-v6ops-transition-comparison-02 (work
in progress), January 2019.
[I-D.palet-v6ops-464xlat-opt-cdn-caches] [I-D.palet-v6ops-464xlat-opt-cdn-caches]
Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/ Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/
Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work
in progress), March 2019. in progress), March 2019.
[I-D.vixie-dns-rpz]
Vixie, P. and V. Schryver, "DNS Response Policy Zones
(RPZ)", draft-vixie-dns-rpz-04 (work in progress),
December 2016.
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
"Analysis of Stateful 64 Translation", RFC 6889,
DOI 10.17487/RFC6889, April 2013,
<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>.
[RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of
Solution Proposals for Hosts to Learn NAT64 Prefix",
RFC 7051, DOI 10.17487/RFC7051, November 2013,
<https://www.rfc-editor.org/info/rfc7051>.
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
Deployment Options and Experience", RFC 7269, Deployment Options and Experience", RFC 7269,
DOI 10.17487/RFC7269, June 2014, DOI 10.17487/RFC7269, June 2014,
<https://www.rfc-editor.org/info/rfc7269>. <https://www.rfc-editor.org/info/rfc7269>.
[RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,
N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,
"An IPv6 Profile for 3GPP Mobile Devices", RFC 7849,
DOI 10.17487/RFC7849, May 2016,
<https://www.rfc-editor.org/info/rfc7849>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[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
Methodology for IPv6 Transition Technologies", RFC 8219,
DOI 10.17487/RFC8219, August 2017,
<https://www.rfc-editor.org/info/rfc8219>.
[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]
"Methodology for the identification of potential security Lencse, G. and Y. Kadobayashi, "Methodology for the
issues of different IPv6 transition technologies: Threat identification of potential security issues of different
analysis of DNS64 and stateful NAT64", Computers & IPv6 transition technologies: Threat analysis of DNS64 and
Security (Elsevier), vol. 77, no. 1, pp. 397-411, stateful NAT64", Computers & Security , vol. 77, no. 1,
DOI 10.1016/j.cose.2018.04.012, August 2018. pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018.
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 La Navata - Galapagar, Madrid 28420
Spain Spain
Email: jordi.palet@theipv6company.com Email: jordi.palet@theipv6company.com
 End of changes. 223 change blocks. 
628 lines changed or deleted 861 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/