draft-ietf-v6ops-nat64-deployment-06.txt   draft-ietf-v6ops-nat64-deployment-07.txt 
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational May 4, 2019 Intended status: Informational July 8, 2019
Expires: November 5, 2019 Expires: January 9, 2020
Additional NAT64/464XLAT Deployment Guidelines in Operator and Additional NAT64/464XLAT Deployment Guidelines in Operator and
Enterprise Networks Enterprise Networks
draft-ietf-v6ops-nat64-deployment-06 draft-ietf-v6ops-nat64-deployment-07
Abstract Abstract
This document describes how NAT64 (including 464XLAT) can be deployed This document describes how NAT64 (including 464XLAT) can be deployed
in an IPv6 network, whether cellular ISP, broadband ISP, or in an IPv6 network, whether cellular ISP, broadband ISP, or
enterprise, and possible optimizations. The document also discusses enterprise, and possible optimizations. The document also discusses
issues to be considered when having IPv6-only connectivity, 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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 November 5, 2019. This Internet-Draft will expire on January 9, 2020.
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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. NAT64 Deployment Scenarios . . . . . . . . . . . . . . . . . 5 3. NAT64 Deployment Scenarios . . . . . . . . . . . . . . . . . 5
3.1. Known to Work . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Known to Work . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Service Provider NAT64 with DNS64 . . . . . . . . . . 6 3.1.1. Service Provider NAT64 with DNS64 . . . . . . . . . . 6
3.1.2. Service Provider Offering 464XLAT, with DNS64 . . . . 8 3.1.2. Service Provider Offering 464XLAT, with DNS64 . . . . 8
3.1.3. Service Provider Offering 464XLAT, without DNS64 . . 11 3.1.3. Service Provider Offering 464XLAT, without DNS64 . . 12
3.2. Known to Work Under Special Conditions . . . . . . . . . 14 3.2. Known to Work Under Special Conditions . . . . . . . . . 14
3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 14 3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 14
3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 15 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 16
3.2.3. Service Provider NAT64; DNS64 in the IPv4-only 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only
remote network . . . . . . . . . . . . . . . . . . . 16 remote network . . . . . . . . . . . . . . . . . . . 16
3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 16 3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 17
4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 18 4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 19
4.1. DNSSEC Considerations and Possible Approaches . . . . . . 18 4.1. DNSSEC Considerations and Possible Approaches . . . . . . 19
4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 20 4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 20
4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21 4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21
4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 21 4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 22
4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 21 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 22
4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22 4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22
4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 22 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 23
4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 22 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 23
4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 22 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 23
4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 23 4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1. Manual Configuration of Foreign DNS . . . . . . . . . 24 4.4.1. Manual Configuration of DNS . . . . . . . . . . . . . 25
4.4.2. DNS Privacy . . . . . . . . . . . . . . . . . . . . . 24 4.4.2. DNS Privacy/Encryption Mechanisms . . . . . . . . . . 25
4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 25 4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 26
4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 25 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 26
4.6. IPv4 literals and old APIs . . . . . . . . . . . . . . . 25 4.6. IPv4 literals and non-IPv6 Compliant APIs . . . . . . . . 26
4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 26 4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 27
4.8. CLAT Translation Considerations . . . . . . . . . . . . . 26 4.8. CLAT Translation Considerations . . . . . . . . . . . . . 27
4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 27 4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 28
4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 27 4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 28
5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 27 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 28
6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 30 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 32 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 34
11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 36 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 37
12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 37 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 38
13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 37 13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 38
14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 37 14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 38
15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 38 15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 39
16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 38 16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 39
17. ANNEX H: Changes from -05 to -06 . . . . . . . . . . . . . . 38 17. ANNEX H: Changes from -05 to -06 . . . . . . . . . . . . . . 39
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 18. ANNEX H: Changes from -06 to -07 . . . . . . . . . . . . . . 39
18.1. Normative References . . . . . . . . . . . . . . . . . . 38 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
18.2. Informative References . . . . . . . . . . . . . . . . . 41 19.1. Normative References . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 19.2. Informative References . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4
translation mechanism, which allows IPv6-only hosts to communicate translation mechanism, which allows IPv6-only hosts to communicate
with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of
IPv4 public addresses sharing, among multiple IPv6-only hosts. IPv4 public addresses sharing, among multiple IPv6-only hosts.
Unless otherwise stated, references in the rest of this document to Unless otherwise stated, references in the rest of this document to
NAT64 (function) should be interpreted as to Stateful NAT64. NAT64 (function) should be interpreted as to Stateful NAT64.
skipping to change at page 4, line 18 skipping to change at page 4, line 19
by means of IPv6-only connectivity. This is just an example which by means of IPv6-only connectivity. This is just an example which
may apply to many other similar cases. All them are deployment may apply to many other similar cases. All them are deployment
specific. 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 "managed end-user similar ones). This may be also the case for "managed end-user
networks". networks".
Note that if all the hosts in a network were performing the address
synthesis, as described in Section 7.2 of [RFC6147], some of the
drawbacks may vanish. However, it is today unrealistic to expect
that, considering the high number of devices and applications that
aren't yet IPv6-enabled. So, in this document, this will be
considered only for specific scenarios that can guarantee it.
An analysis of stateful IPv4/IPv6 mechanisms is provided in An analysis of stateful IPv4/IPv6 mechanisms is provided in
[RFC6889]. [RFC6889].
This document looks into different possible NAT64 ([RFC6146]) This document looks into different possible NAT64 ([RFC6146])
deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and
similar ones, which were not documented in [RFC6144], such as 464XLAT similar ones, which were not documented in [RFC6144], such as 464XLAT
([RFC6877]), in operator (broadband and cellular) and enterprise ([RFC6877]), in operator (broadband and cellular) and enterprise
networks, and provides guidelines to avoid operational issues. networks, 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
skipping to change at page 4, line 41 skipping to change at page 4, line 49
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.
A section with clarifications on the usage of this document for A section with clarifications on the usage of this document for
enterprise networks, is also provided. Finally, an annex provides an enterprise networks, is also provided. Finally, an annex provides an
example of a broadband deployment using 464XLAT and another annex example of a broadband deployment using 464XLAT and another annex
provides hints for a CLAT implementation. provides hints for a CLAT implementation.
[RFC7269] already provides information about NAT64 deployment options [RFC7269] already provides information about NAT64 deployment options
and experiences. Both, this document and [RFC7269] are and experiences. Both, this document and [RFC7269] are
complementary, as they are looking into different deployment complementary; they are looking into different deployment
considerations and furthermore, this document is considering the considerations and furthermore, this document is considering the
updated deployment experience and newer standards. 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 (IPv4aaS) transition mechanisms. well by other IPv4-as-a-Service (IPv4aaS) transition mechanisms.
Note that this is true only for the case of broadband networks, as in 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 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 of NAT64/464XLAT. So, it is out of scope of this document to provide
a comparison among the different IPv4aaS transition mechanisms, which a comparison among the different IPv4aaS transition mechanisms, which
is being analyzed already in [I-D.lmhp-v6ops-transition-comparison]. is being analyzed already in [I-D.lmhp-v6ops-transition-comparison].
skipping to change at page 6, line 11 skipping to change at page 6, line 19
3. A NAT64 function (NAT64) in the service provider. 3. A NAT64 function (NAT64) in the service provider.
4. A DNS64 function (DNS64) in the service provider. 4. A DNS64 function (DNS64) in the service provider.
5. An external service provider offering the NAT64 function and/or 5. An external service provider offering the NAT64 function and/or
the DNS64 function (extNAT64/extDNS64). the DNS64 function (extNAT64/extDNS64).
6. 464XLAT customer side translator (CLAT). 6. 464XLAT customer side translator (CLAT).
Note that the nomenclature used in parenthesis is the one that, for Note that the nomenclature used in parenthesis is the one that, for
short, will be used in the figures. short, will be used in the figures. Note also that for simplicity,
the boxes in the figures don't mean they are actually a single
device; they just represent one or more functions as located in that
part of the network (i.e. a single box with NAT64 and DNS64 functions
can actually be several devices, not just one).
The possible scenarios are split in two general categories: The possible scenarios are split in two general categories:
1. Known to work. 1. Known to work.
2. Known to work under special conditions. 2. Known to work under special conditions.
3.1. Known to Work 3.1. Known to Work
The scenarios in this category are known to work. Each one may have The scenarios in this category are known to work, as there are well-
different pros and cons, and in some cases the trade-offs, maybe known existing deployments from different operators using them. Each
acceptable for some operators. one may have different pros and cons, and in some cases the trade-
offs, maybe 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 (Figure 1), the service provider offers both, the
DNS64 functions. NAT64 and the DNS64 functions.
This is the most common scenario as originally considered by the This is the most common scenario as originally considered by the
designers of NAT64 ([RFC6146]) and DNS64 ([RFC6147]), however also designers of NAT64 ([RFC6146]) and DNS64 ([RFC6147]), however also
may have the implications related the DNSSEC. may have the implications related the DNSSEC.
This scenario also may fail to solve the issue of IPv4 literal This scenario also may fail to solve the issue of IPv4 literal
addresses or non-IPv6 compliant APIs, as well as the issue of addresses or non-IPv6 compliant APIs, as well as the issue of
IPv4-only hosts or applications behind 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 similar scenario will be if the service provider offers only the A similar scenario (Figure 2) will be if the service provider offers
DNS64 function, and the NAT64 function is provided by an outsourcing only the DNS64 function, and the NAT64 function is provided by an
agreement with an external provider. All the considerations in the outsourcing agreement with an external provider. All the
previous paragraphs of this section are the same for this sub-case. considerations in the previous paragraphs of this section, are the
same for this sub-case.
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| extNAT64 +--------+ IPv4 | | extNAT64 +--------+ IPv4 |
| | | | | | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
| |
+----------+ +----+-----+ +----------+ +----+-----+
| | | | | | | |
| IPv6 +--------+ DNS64 + | IPv6 +--------+ DNS64 +
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
Figure 2: NAT64 in external service provider Figure 2: NAT64 in external service provider
This is equivalent to the scenario where the outsourcing agreement This is equivalent to the scenario (Figure 3) where the outsourcing
with the external provider is to provide both the NAT64 and DNS64 agreement with the external provider is to provide both the NAT64 and
functions. Once more, all the considerations in the previous DNS64 functions. Once more, all the considerations in the previous
paragraphs of this section are the same for this sub-case. paragraphs of this section are the same for this sub-case.
+----------+ +----------+ +----------+ +----------+
| extNAT64 | | | | extNAT64 | | |
| + +-------+ IPv4 | | + +-------+ IPv4 |
| extDNS64 | | | | extDNS64 | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| | | | | |
| IPv6 +-------------+ | IPv6 +-------------+
| | | |
+----------+ +----------+
Figure 3: NAT64 and DNS64 in external provider Figure 3: NAT64 and DNS64 in external provider
One more equivalent scenario will be if the service provider offers One additional equivalent scenario (Figure 4) will be if the service
the NAT64 function only, and the DNS64 function is from an external provider offers the NAT64 function only, and the DNS64 function is
provider with or without a specific agreement among them. This is a from an external provider with or without a specific agreement among
scenario already common today, as several "global" service providers them. This is a scenario already common today, as several "global"
provide free DNS/DNS64 services and users often configure manually service providers provide free DNS/DNS64 services and users often
their DNS. This will only work if both the NAT64 and the DNS64 configure manually their DNS. This will only work if both the NAT64
functions are using the WKP (Well-Known Prefix) or the same NSP and the DNS64 functions are using the WKP (Well-Known Prefix) or the
(Network-Specific Prefix). All the considerations in the previous same NSP (Network-Specific Prefix). All the considerations in the
paragraphs of this section are the same for this sub-case. previous paragraphs of this section, are the same for this sub-case.
Of course, if the external DNS64 function is agreed with the service Of course, if the external DNS64 function is agreed with the service
provider, then we are in the same case as in the previous ones provider, then we are in the same case as in the previous ones
already depicted in this scenario. already depicted in this scenario.
+----------+ +----------+
| | | |
| extDNS64 | | extDNS64 |
| | | |
+----+-----+ +----+-----+
skipping to change at page 8, line 49 skipping to change at page 9, line 15
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 Resource Records). supports IPv6 DNS (uses AAAA Resource Records).
Note that even if in the 464XLAT ([RFC6877]) terminology, the Note that even if in the 464XLAT ([RFC6877]) terminology, the
provider-side translator is referred as PLAT, for simplicity and provider-side translator is referred as PLAT, for simplicity and
uniformity, across this document is always referred as NAT64 uniformity, across this document is always referred as NAT64
(function). (function).
In this scenario the service provider deploys 464XLAT with a DNS64 In this scenario (Figure 5) the service provider deploys 464XLAT with
function. 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 a CLAT function, the end-user cellular networks. By supporting a CLAT function, the end-user
skipping to change at page 9, line 26 skipping to change at page 9, line 41
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 behind the native IPv6 support, so clearly it allows IPv4-only hosts behind
the IPv6-only access network. the IPv6-only access network.
Furthermore, as discussed in [RFC6877], 464XLAT can be used in Furthermore, as discussed in [RFC6877], 464XLAT can be used in
broadband IPv6 network architectures, by implementing the CLAT broadband IPv6 network architectures, by implementing the CLAT
function at the CE. function at the CE.
The support of this scenario offers two additional advantages: The support of this scenario in a network, offers two additional
advantages:
o DNS load optimization: A CLAT should implement a DNS proxy (as per o DNS load optimization: A CLAT should implement a DNS proxy (as per
[RFC5625]), so that only IPv6 native queries and only for AAAA [RFC5625]), so that only IPv6 native queries and only for AAAA
records are sent to the DNS64 server. Otherwise doubling the records are sent to the DNS64 server. Otherwise doubling the
number of queries may impact the DNS infrastructure. number of queries may impact the DNS infrastructure.
o Connection establishment delay optimization: If the UE/CE o Connection establishment delay optimization: If the UE/CE
implementation is detecting the presence of a DNS64 function, it implementation is detecting the presence of a DNS64 function, it
may issue only the AAAA query, instead of both the AAAA and A may issue only the AAAA query, instead of both the AAAA and A
queries. queries.
skipping to change at page 11, line 5 skipping to change at page 11, line 13
placing the different elements. placing the different elements.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | NAT64 | | | | IPv6 | | NAT64 | | |
| + +--------+ + +--------+ IPv4 | | + +--------+ + +--------+ IPv4 |
| CLAT | | DNS64 | | | | CLAT | | DNS64 | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 5: 464XLAT with DNS64 Figure 5: 464XLAT with DNS64
A similar scenario will be if the service provider offers only the A similar scenario (Figure 6) will be if the service provider offers
DNS64 function, and the NAT64 function is provided by an outsourcing only the DNS64 function, and the NAT64 function is provided by an
agreement with an external provider. All the considerations in the outsourcing agreement with an external provider. All the
previous paragraphs of this section are the same for this sub-case. considerations in the previous paragraphs of this section are the
same for this sub-case.
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| extNAT64 +--------+ IPv4 | | extNAT64 +--------+ IPv4 |
| | | | | | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
| |
+----------+ +----+-----+ +----------+ +----+-----+
| IPv6 | | | | IPv6 | | |
| + +--------+ DNS64 + | + +--------+ DNS64 +
| CLAT | | | | CLAT | | |
+----------+ +----------+ +----------+ +----------+
Figure 6: 464XLAT with DNS64; NAT64 in external provider Figure 6: 464XLAT with DNS64; NAT64 in external provider
As well, is equivalent to the scenario where the outsourcing As well, is equivalent to the scenario (Figure 7) where the
agreement with the external provider is to provide both the NAT64 and outsourcing agreement with the external provider is to provide both
DNS64 functions. Once more, all the considerations in the previous the NAT64 and DNS64 functions. Once more, all the considerations in
paragraphs of this section are the same for this sub-case. the previous paragraphs of this section are the same for this sub-
case.
+----------+ +----------+ +----------+ +----------+
| extNAT64 | | | | extNAT64 | | |
| + +--------+ IPv4 | | + +--------+ IPv4 |
| extDNS64 | | | | extDNS64 | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| IPv6 | | | IPv6 | |
| + +-------------+ | + +-------------+
| CLAT | | CLAT |
+----------+ +----------+
Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in 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 (Figure 8), using 464XLAT
that the service provider ensures that DNSSEC is never broken, even without DNS64, is that the service provider ensures that DNSSEC is
in case the user modifies the DNS configuration. Nevertheless, some never broken, even in case the user modifies the DNS configuration.
CLAT implementations or applications may impose an extra delay, which Nevertheless, some CLAT implementations or applications may impose an
is induced by the dual A/AAAA queries (and wait for both responses), extra delay, which is induced by the dual A/AAAA queries (and wait
unless Happy Eyeballs v2 (HEv2, [RFC8305]) is also present. for both responses), unless Happy Eyeballs v2 ([RFC8305]) is also
present.
A possible variation of this scenario is the case when DNS64 is used 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 only for the discovery of the NAT64 prefix. The rest of the document
is not considering it as a different scenario, because once the is not considering it as a different scenario, because once the
prefix has been discovered, the DNS64 function is not used, so it prefix has been discovered, the DNS64 function is not used, so it
behaves as if the DNS64 synthesis function is not present. 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) behind the IPv6-only to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only
access network, neither related to the usage of IPv4 literals or non- access network, neither related to the usage of IPv4 literals or non-
IPv6 compliant APIs. IPv6 compliant APIs.
The support of this scenario offers one advantage: The support of this scenario in a network, offers one advantage:
o DNS load optimization: A CLAT should implement a DNS proxy (as per 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 [RFC5625]), so that only IPv6 native queries are sent to the DNS64
server. Otherwise doubling the number of queries may impact the server. Otherwise doubling the number of queries may impact the
DNS infrastructure. DNS infrastructure.
As indicated earlier, the connection establishment delay optimization As indicated earlier, the connection establishment delay optimization
is achieved only in the case of devices, Operating Systems, or is achieved only in the case of devices, Operating Systems, or
applications that use HEv2 ([RFC8305]), which is very common. applications that use Happy Eyeballs v2 ([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 )
/ \ | | \ flow /\ `-----' \ flow / / \ | | \ flow /\ `-----' \ flow /
( Dual- )--+ IPv6 | \ / \ / \ / ( Dual- )--+ IPv6 | \ / \ / \ /
skipping to change at page 13, line 43 skipping to change at page 14, line 18
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 (Figure 9) where there is an
agreement with an external provider for the NAT64 function. All the outsourcing agreement with an external provider for the NAT64
considerations in the previous paragraphs of this section are the function. All the considerations in the previous paragraphs of this
same for this sub-case. section are the same for this sub-case.
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| extNAT64 +--------+ IPv4 | | extNAT64 +--------+ IPv4 |
| | | | | | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| IPv6 | | | IPv6 | |
| + +-------------+ | + +-------------+
skipping to change at page 14, line 31 skipping to change at page 14, line 49
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 function, In this scenario (Figure 10), the service provider offers a NAT64
however there is no DNS64 function support at all. function, however there is no DNS64 function support at all.
As a consequence, an IPv6 host in the IPv6-only access network, will As a consequence, an IPv6 host in the IPv6-only access network, will
not be able to detect the presence of DNS64 by means of [RFC7050], not be able to detect the presence of DNS64 by means of [RFC7050],
neither to learn the IPv6 prefix to be used for the NAT64 function. 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 function becomes useless. NAT64 function becomes useless.
skipping to change at page 15, line 32 skipping to change at page 16, line 7
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| | | | | | | | | | | |
| 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 function, but In this scenario (Figure 11), the service provider offers the NAT64
not the DNS64 function. However, the IPv6 hosts have a built-in function, but not the DNS64 function. However, the IPv6 hosts have a
DNS64 function. built-in DNS64 function.
This may become common if the DNS64 function is implemented in all This may become common if the DNS64 function is implemented in all
the IPv6 hosts/stacks, which is not the actual situation, but it may the IPv6 hosts/stacks. However, commonly this is not the actual
happen in the medium-term. At this way, the DNSSEC validation is situation, even if it may happen in the medium-term. At this way,
performed on the A record, and then the host can use the DNS64 the DNSSEC validation is performed on the A record, and then the host
function so to be able to use the NAT64 function, without any DNSSEC can use the DNS64 function so to be able to use the NAT64 function,
issues. without any DNSSEC issues.
This scenario fails to solve the issue of IPv4 literal addresses or This scenario fails to solve the issue of IPv4 literal addresses or
non-IPv6 compliant APIs, unless the IPv6 hosts also supports HEv2 non-IPv6 compliant APIs, unless the IPv6 hosts also supports Happy
([RFC8305], Section 7.1), which may solve that issue. Eyeballs v2 ([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 behind the IPv6-only access network. hosts or applications behind the IPv6-only access network.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | | | | | IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 | | + +--------+ NAT64 +--------+ IPv4 |
| DNS64 | | | | | | DNS64 | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 11: NAT64; DNS64 in IPv6 hosts Figure 11: NAT64; DNS64 in IPv6 hosts
3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network
In this scenario, the service provider offers the NAT64 function In this scenario (Figure 12), the service provider offers the NAT64
only. The remote IPv4-only network offers the DNS64 function. 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. 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 IPv4 literal This scenario still fails to solve the issue of IPv4 literal
addresses or non-IPv6 compliant APIs. addresses or non-IPv6 compliant APIs.
skipping to change at page 17, line 7 skipping to change at page 17, line 30
b. Literal/APIs: Are there applications using IPv4 literals or non- b. Literal/APIs: Are there applications using IPv4 literals or non-
IPv6 compliant APIs? IPv6 compliant APIs?
c. IPv4-only: Are there hosts or applications using IPv4-only? c. IPv4-only: Are there hosts or applications using IPv4-only?
d. Foreign DNS: Is the scenario surviving if the user, Operating d. Foreign DNS: Is the scenario surviving if the user, Operating
System, applications or devices change the DNS? System, applications or devices change the DNS?
e. DNS load opt. (DNS load optimization): Are there extra queries e. DNS load opt. (DNS load optimization): Are there extra queries
that may impact DNS infrastructure?. that may impact DNS infrastructure?
f. Connect. opt. (Connection establishment delay optimization): Is f. Connect. opt. (Connection establishment delay optimization): Is
the UE/CE issuing only the AAAA query or also an A query and the UE/CE issuing only the AAAA query or also an A query and
waiting for both responses? waiting for both responses?
In the next table, the columns represent each of the scenarios from In the next table, the columns represent each of the scenarios from
the previous sections, by the figure number. The possible values the previous sections, by the figure number. The possible values
are: are:
o "-" Scenario "bad" for that criteria. o "-" Scenario "bad" for that criteria.
o "+" Scenario "good" for that criteria. o "+" Scenario "good" for that criteria.
o "*" Scenario "bad" for that criteria, however it is typically o "*" Scenario "bad" for that criteria, however it is typically
resolved, with the support of HEv2 ([RFC8305]). resolved, with the support of Happy Eyeballs v2 ([RFC8305]).
In some cases, "countermeasures", alternative or special In some cases, "countermeasures", alternative or special
configurations, may be available for the criteria designated as configurations, may be available for the criteria designated as
"bad". So, this comparison is considering a generic case, as a quick "bad". So, this comparison is considering a generic case, as a quick
comparison guide. In some cases, a "bad" criterion is not comparison guide. In some cases, a "bad" criterion is not
necessarily a negative aspect, all it depends on the specific needs/ necessarily a negative aspect, all it depends on the specific needs/
characteristics of the network where the deployment will take place. characteristics of the network where the deployment will take place.
For instance, in a network which has only IPv6-only hosts and apps 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 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 NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is
still relevant. still relevant.
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + | | DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+
skipping to change at page 18, line 25 skipping to change at page 18, line 48
built-in local address synthesis features, will provide a valid built-in local address synthesis features, will provide a valid
solution. Further to that, those scenarios will also keep working if solution. Further to that, those scenarios will also keep working if
the DNS configuration is modified. Clearly also, depending on if the DNS configuration is modified. Clearly also, depending on if
DNS64 is used or not, DNSSEC may be broken for those hosts doing DNS64 is used or not, DNSSEC may be broken for those hosts doing
DNSSEC validation. DNSSEC validation.
All the scenarios are good in terms of DNS load optimization, and in All the scenarios are good in terms of DNS load optimization, and in
the case of 464XLAT it may provide an extra degree of optimization. the case of 464XLAT it may provide an extra degree of optimization.
Finally, all them are also good in terms of connection establishment Finally, all them are also good in terms of connection establishment
delay optimization. However, in the case of 464XLAT without DNS64, delay optimization. However, in the case of 464XLAT without DNS64,
it requires the usage of HEv2. This is not an issue, as commonly it it requires the usage of Happy Eyeballs v2. This is not an issue, as
is available in actual Operating Systems. 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
specific 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 may 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 access network, queries for a
in a signed zone, by means of a recursive name server that supports domain name in a signed zone, by means of a recursive name server
DNS64, and the result is a synthesized AAAA record, and the recursive that supports DNS64, and the result is a synthesized AAAA record, and
name server is configured to perform DNSSEC validation and has a the recursive name server is configured to perform DNSSEC validation
valid chain of trust to the zone in question, it will and has a 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
skipping to change at page 19, line 48 skipping to change at page 20, line 25
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. Saying fact somehow simplified, looking at the worst possible case. 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". DNSSEC breach will not happen if the end-host is not approach". DNSSEC breach will not happen if the end-host is not
doing validation. doing validation.
Existing previous studies seems to indicate that the figures of Existing previous studies seems to indicate that the figures of
DNSSEC actually broken by using DNS64 will be around 1.7% DNSSEC actually broken by using DNS64 will be around 1.7%
([About-DNS64]) of the cases. However we can not negate that this ([About-DNS64]) of the cases. However, we can't negate that this may
may increase, as DNSSEC deployment grows. Consequently, a decision increase, as DNSSEC deployment grows. Consequently, a decision point
point for the operator must depend on "do I really care for that for the operator must depend on "do I really care for that percentage
percentage of cases and the impact in my helpdesk or can I provide of cases and the impact in my helpdesk or can I provide alternative
alternative solutions for them?". Some possible solutions may be solutions for them?". Some possible solutions may be taken, as
taken, as depicted in the next sections. depicted in the next sections.
4.1.1. Not using DNS64 4.1.1. Not using DNS64
A solution will be to avoid using DNS64, but as already indicated A solution will be to avoid using DNS64, but as already indicated
this is not possible in all the scenarios. this is not possible in all the scenarios.
The use of DNS64 is a key component for some networks, in order to The use of DNS64 is a key component for some networks, in order to
comply with traffic performance metrics, monitored by some comply with traffic performance metrics, monitored by some
governmental bodies and other institutions. governmental bodies and other institutions ([FCC], [ARCEP]).
One drawback of not having a DNS64 at the network side, is that is One drawback of not having a DNS64 at the network side, is that is
not possible to heuristically discover the NAT64 ([RFC7050]). not possible to heuristically discover the NAT64 ([RFC7050]).
Consequently, an IPv6 host behind the IPv6-only access network, will Consequently, an IPv6 host behind the IPv6-only access network, will
not be able to detect the presence of the NAT64 function, neither to not be able to detect the presence of the NAT64 function, neither to
learn the IPv6 prefix to be used for it, unless it is configured by learn the IPv6 prefix to be used for it, unless it is configured by
alternative means. alternative means.
The discovery of the IPv6 prefix could be solved by means of adding The discovery of the IPv6 prefix could be solved, as described in
the relevant AAAA records to the ipv4only.arpa. zone of the service [RFC7050], by means of adding the relevant AAAA records to the
provider recursive servers, i.e., if using the WKP (64:ff9b::/96): ipv4only.arpa. zone, of the service 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 An alternative option to the above, is the use of DNS RPZ
([I-D.vixie-dns-rpz]) or equivalent functionalities. Note that this ([I-D.vixie-dns-rpz]) or equivalent functionalities. Note that this
skipping to change at page 21, line 6 skipping to change at page 21, line 32
has evolved many considerations from that document. New options are has evolved many considerations from that document. New options are
being documented, such using Router Advertising being documented, such using Router Advertising
([I-D.ietf-6man-ra-pref64]) or DHCPv6 options ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options
([I-D.li-intarea-nat64-prefix-dhcp-option]). ([I-D.li-intarea-nat64-prefix-dhcp-option]).
It may be convenient the simultaneous support of several of the It may be convenient the simultaneous support of several of the
possible approaches, 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.
Of special relevance to this section is also
[I-D.cheshire-sudn-ipv4only-dot-arpa].
4.1.2. DNSSEC validator aware of DNS64 4.1.2. DNSSEC validator aware of DNS64
In general, by default, DNS servers with DNS64 function, will not In general, by default, DNS servers with DNS64 function will not
synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the
query. In this case, as only an A record is available, it means that query.
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 In this case, as only an A record is available, if a CLAT function is
not broken. However, this will not work if a CLAT function is not present, it means that the CLAT will take the responsibility, as in
present as the hosts will not be able to use IPv4 (scenarios without the case of literal IPv4 addresses, to keep that traffic flow end-to-
464XLAT). end as IPv4, so DNSSEC is not broken.
However, this will not work if a CLAT function is not present as the
hosts will not be able to use IPv4 (which is the case for all the
scenarios without 464XLAT).
4.1.3. Stub validator 4.1.3. Stub validator
If the DO flag is set and the client device performs DNSSEC If the DO flag is set and the client device performs DNSSEC
validation, and the Checking Disabled (CD) flag is set for a query, validation, and the Checking Disabled (CD) flag is set for a query,
the DNS64 recursive server will not synthesize AAAA responses. In the DNS64 recursive server will not synthesize AAAA responses. In
this case, the client could perform the DNSSEC validation with the A this case, the client could perform the DNSSEC validation with the A
record and then synthesize the AAAA ([RFC6052]). For that to be record and then synthesize the AAAA ([RFC6052]). For that to be
possible, the client must have learned beforehand the NAT64 prefix possible, the client must have learned beforehand the NAT64 prefix
using any of the available methods ([RFC7050], [RFC7225], using any of the available methods ([RFC7050], [RFC7225],
[I-D.ietf-6man-ra-pref64], [I-D.ietf-6man-ra-pref64],
[I-D.li-intarea-nat64-prefix-dhcp-option]). This allows the client [I-D.li-intarea-nat64-prefix-dhcp-option]). This allows the client
device to avoid using the DNS64 function and still use NAT64 even device to avoid using the DNS64 function and still use NAT64 even
with DNSSEC. with DNSSEC.
If the end-host is IPv4-only, this will not work if a CLAT function If the end-host is IPv4-only, this will not work if a CLAT function
is not present (scenarios without 464XLAT). is not present (scenarios without 464XLAT).
Some devices or Operating Systems may implement, instead of a CLAT, Some devices or Operating Systems may implement, instead of a CLAT,
an equivalent function by using Bump-in-the-Host ([RFC6535]), an equivalent function by using Bump-in-the-Host ([RFC6535]),
implemented as part of HEv2 (Section 7.1 of [RFC8305]). In this implemented as part of Happy Eyeballs v2 (Section 7.1 of [RFC8305]).
case, the considerations in the above paragraphs are also applicable. In this 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. Then, following the same approach behalf of the client devices. Then, following the same approach
described in the Section 4.1.3, the DNS proxy actually will "lie" to described in 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 by themselves. Again, this allow the unless they perform validation by themselves. Again, this allow the
client devices to avoid using the DNS64 function and still use NAT64 client devices to avoid using the DNS64 function and still use NAT64
with DNSSEC. with DNSSEC.
Once more, this will not work without a CLAT function (scenarios Once more, this will not work without a CLAT function (scenarios
without 464XLAT). without 464XLAT).
4.1.5. ACL of clients 4.1.5. ACL of clients
In cases of dual-stack clients, the AAAA queries typically take In cases of dual-stack clients, the AAAA queries typically take
preference over A queries. If DNS64 is enabled for those clients, preference over A queries. If DNS64 is enabled for those clients,
will never get A records, even for IPv4-only servers. As a will never get A records, even for IPv4-only servers.
consequence, if the IPv4-only servers are in the path before the
NAT64 function, the clients will never reach them. If DNSSEC is As a consequence, in cases where there are IPv4-only servers, and
being used for all those flows, specific addresses or prefixes can be those are located in the path before the NAT64 function, the clients
left-out of the DNS64 synthesis by means of ACLs. will not be able to reach them. If DNSSEC is being used for all
those flows, specific addresses or prefixes can be left-out of the
DNS64 synthesis by means of ACLs.
Once more, this will not work without a CLAT function (scenarios Once more, this will not work without a CLAT function (scenarios
without 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
skipping to change at page 23, line 50 skipping to change at page 24, line 39
device is doing a local address synthesis (see Section 7.1 of device is doing a local address synthesis (see Section 7.1 of
[RFC8305]). [RFC8305]).
4.4. Foreign DNS 4.4. Foreign DNS
Clients, devices or applications in a service provider network, may Clients, devices or applications in a service provider network, may
use DNS servers from other networks. This may be the case either if use DNS servers from other networks. This may be the case either if
individual applications use their own DNS server, the Operating individual applications use their own DNS server, the Operating
System itself or even the CE, or combinations of the above. System itself or even the CE, or combinations of the above.
Those "foreign" DNS servers may not support DNS64, which will mean Those "foreign" DNS servers may not support DNS64, which as a
that those scenarios that require a DNS64 may not work. However, if consequence, will mean that those scenarios that require a DNS64 may
a CLAT function is available, the considerations in Section 4.3 will not work. However, if a CLAT function is available, the
apply. considerations in Section 4.3 will apply.
In the case that the foreign DNS supports the DNS64 function, we may In the case that the foreign DNS supports the DNS64 function, we may
be in the situation of providing incorrect configurations parameters, be in the situation of providing incorrect configurations parameters,
for example, un-matching WKP or NSP, or a case such the one described for example, un-matching WKP or NSP, or a case such the one described
in Section 3.2.3. in Section 3.2.3.
Having a CLAT function, even if using foreign DNS without a DNS64 Having a CLAT function, even if using foreign DNS without a DNS64
function, ensures that everything will work, so the CLAT must be function, ensures that everything will work, so the CLAT must be
considered as an advantage even against user configuration errors. considered as an advantage even against user configuration errors.
The cost of this, is that all the traffic will use a double The cost of this, is that all the traffic will use a double
translation (NAT46 at the CLAT and NAT64 at the operator network), translation (NAT46 at the CLAT and NAT64 at the operator network),
unless there is support for EAM (Section 4.9). unless there is support for EAM (Section 4.9).
An exception to that is the case when there is a CLAT function at the An exception to that is the case when there is a CLAT function at the
CE, which is not able to obtain the correct configuration parameters CE, which is not able to obtain the correct configuration parameters
(again, un-matching WKP or NSP). (again, un-matching WKP or NSP).
However, it needs to be emphasized, that if there is not a CLAT However, it needs to be emphasized, that if there is not a CLAT
function (scenarios without 464XLAT), an external DNS without DNS64 function (scenarios without 464XLAT), an external DNS without DNS64
skipping to change at page 24, line 25 skipping to change at page 25, line 16
translation (NAT46 at the CLAT and NAT64 at the operator network), translation (NAT46 at the CLAT and NAT64 at the operator network),
unless there is support for EAM (Section 4.9). unless there is support for EAM (Section 4.9).
An exception to that is the case when there is a CLAT function at the An exception to that is the case when there is a CLAT function at the
CE, which is not able to obtain the correct configuration parameters CE, which is not able to obtain the correct configuration parameters
(again, un-matching WKP or NSP). (again, un-matching WKP or NSP).
However, it needs to be emphasized, that if there is not a CLAT However, it needs to be emphasized, that if there is not a CLAT
function (scenarios without 464XLAT), an external DNS without DNS64 function (scenarios without 464XLAT), an external DNS without DNS64
support, will disallow any access to IPv4-only destination networks, support, will disallow any access to IPv4-only destination networks,
and will not guarantee DNSSEC, so will behave as in the and will not guarantee the correct DNSSEC validation, so will behave
Section 3.2.1. as in the Section 3.2.1.
In summary, it can be said, that the consequences of the use of
foreign DNS depend very much in each specific case. However, in
general, if a CLAT function is present, most of the time, there will
not be any. In the other cases, generally, the access to
IPv6-enabled services is still guaranteed for IPv6-enabled hosts, but
not for IPv4-only hosts, neither the access to IPv4-only services for
any hosts in the network.
The causes of "foreign DNS" could be classified in three main The causes of "foreign DNS" could be classified in three main
categories, as depicted in the following sub-sections. categories, as depicted in the following sub-sections.
4.4.1. Manual Configuration of Foreign DNS 4.4.1. Manual Configuration of DNS
It is becoming increasingly common that end-users or even devices or It is becoming increasingly common that end-users or even devices or
applications configure alternative DNS in their Operating Systems, applications configure alternative DNS in their Operating Systems,
and sometimes in CEs. and sometimes in CEs.
4.4.2. DNS Privacy 4.4.2. DNS Privacy/Encryption Mechanisms
A new trend is for clients or applications to use mechanisms for DNS A new trend is for clients or applications to use mechanisms for DNS
privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS
([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC
([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH ([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH
and DoQ. and DoQ.
Those DNS privacy/encryption options, currently are typically Those DNS privacy/encryption options, currently are typically
provided by the applications, not the Operating System vendors. At provided by the applications, not the Operating System vendors. At
the time of writing this document, at least DoT and DoH standards the time of writing this document, at least DoT and DoH standards
skipping to change at page 25, line 48 skipping to change at page 26, line 48
their state. Using an NSP could simplify that. their state. Using an NSP could simplify that.
d. If DNS64 is required and users, devices, Operating Systems or d. If DNS64 is required and users, devices, Operating Systems or
applications may change their DNS configuration, and deliberately applications may change their DNS configuration, and deliberately
choose an alternative DNS64 function, most probably alternative choose an alternative DNS64 function, most probably alternative
DNS64 will use by default the WKP. In that case, if an NSP is DNS64 will use by default the WKP. In that case, if an NSP is
used by the NAT64 function, clients will not be able to use the used by the NAT64 function, clients will not be able to use the
operator NAT64 function, which will break connectivity to operator NAT64 function, which will break connectivity to
IPv4-only destinations. IPv4-only destinations.
4.6. IPv4 literals and old APIs 4.6. IPv4 literals and non-IPv6 Compliant APIs
A host or application using literal IPv4 addresses or older APIs, A host or application using literal IPv4 addresses or older APIs,
behind a network with IPv6-only access, will not work unless any of which aren't IPv6 compliant, behind a network with IPv6-only access,
the following alternatives is provided: will not work unless any of the following alternatives is provided:
o CLAT (or equivalent function). o CLAT (or equivalent function).
o HEv2 (Section 7.1, [RFC8305]). o Happy Eyeballs v2 (Section 7.1, [RFC8305]).
o Bump-in-the-Host ([RFC6535]) with a DNS64 function. o Bump-in-the-Host ([RFC6535]) with a DNS64 function.
Those alternatives will solve the problem for an end-host. However, Those alternatives will solve the problem for an end-host. However,
if that end-hosts is providing "tethering" or an equivalent service if that end-hosts is providing "tethering" or an equivalent service
to other hosts, that needs 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, the support of 464XLAT is the only valid and complete Otherwise, the support of 464XLAT is the only valid and complete
skipping to change at page 27, line 31 skipping to change at page 28, line 31
4.10. Incoming Connections 4.10. Incoming Connections
The use of NAT64, in principle, disallows IPv4 incoming connections, The use of NAT64, in principle, disallows IPv4 incoming connections,
which may be still needed for IPv4-only peer-to-peer applications. which may be still needed for IPv4-only peer-to-peer applications.
However, there are several alternatives that resolve this issue: However, there are several alternatives that resolve this issue:
a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are
commonly used by peer-to-peer applications in order to allow commonly used by peer-to-peer applications in order to allow
incoming connections with IPv4 NAT. In the case of NAT64, they incoming connections with IPv4 NAT. In the case of NAT64, they
work as well. work as well. Note also the relevance of
[I-D.ietf-tram-turnbis].
b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and
IPv6 packets are translated and forwarded. A NAT64 may implement IPv6 packets are translated and forwarded. A NAT64 may implement
PCP to allow this service. PCP to allow this service.
c. EAM ([RFC7757]) may also be used in order to configure explicit c. EAM ([RFC7757]) may also be used in order to configure explicit
mappings for customers that require them. This is used for mappings for customers that require them. This is used for
example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]). example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]).
5. Summary of Deployment Recommendations for NAT64/464XLAT 5. Summary of Deployment Recommendations for NAT64/464XLAT
NAT64/464XLAT has demonstrated to be a valid choice in several 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, being the predominant mechanism in the majority of the
network case, needs and requirements. Despite that, this document is cellular networks (which account for hundreds of millions of users).
not an explicit recommendation for using this choice versus other NAT64/464XLAT offer different choices of deployment, depending on
IPv4aaS transition mechanisms. Instead, this document is a guide each network case, needs and requirements. Despite that, this
that facilitates evaluating a possible implementation of document is not an explicit recommendation for using this choice
versus other IPv4aaS transition mechanisms. Instead, this document
is a guide that facilitates evaluating a possible implementation of
NAT64/464XLAT and key decision points about specific design NAT64/464XLAT and key decision points about specific design
considerations for its deployment. considerations for its deployment.
Depending on the specific requirements of each deployment case, DNS64 Depending on the specific requirements of each deployment case, DNS64
may be a required function, while in other cases the adverse effects may be a required function, while in other cases the adverse effects
may be counterproductive. Similarly, in some cases a NAT64 function, may be counterproductive. Similarly, in some cases a NAT64 function,
together with a DNS64 function, may be a valid solution, when there 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 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 supported (Section 4.6 and Section 4.7). However, in other cases
(i.e. IPv4-only devices or applications need to be supported), the (i.e. IPv4-only devices or applications need to be supported), the
limitations of NAT64/DNS64, may suggest the operator to look into limitations of NAT64/DNS64, may suggest the operator to look into
464XLAT as a more complete solution. 464XLAT as a more complete solution.
In the case of broadband managed networks (where the CE is provided In the case of broadband managed networks (where the CE is provided
or suggested/supported by the operator), in order to fully support or suggested/supported by the operator), in order to fully support
the actual user needs (IPv4-only devices and applications, usage of the actual user needs (IPv4-only devices and applications, usage of
IPv4 literals and old APIs), the 464XLAT scenario should be IPv4 literals and non-IPv6 compliant APIs), the 464XLAT scenario
considered. In that case, it must support a CLAT function. should be considered. In that case, it must support a CLAT function.
If the operator provides DNS services, in order to increase If the operator provides DNS services, in order to increase
performance by reducing the double translation for all the IPv4 performance by reducing the double translation for all the IPv4
traffic, they may support a DNS64 function and avoid, as much as traffic, they may support a DNS64 function and avoid, as much as
possible, breaking DNSSEC. In this case, if the DNS service is possible, breaking DNSSEC. In this case, if the DNS service is
offering DNSSEC validation, then it must be in such way that it is offering DNSSEC validation, then it must be in such way that it is
aware of the DNS64. This is considered the simpler and safer aware of the DNS64. This is considered the simpler and safer
approach, and may be combined as well with other recommendations approach, and may be combined as well with other recommendations
described in this document: described in this document:
skipping to change at page 31, line 16 skipping to change at page 32, line 19
An example of that is the IETF meetings network itself, where both An example of that is the IETF meetings network itself, where both
NAT64 and DNS64 functions are provided, presenting in this case the NAT64 and DNS64 functions are provided, presenting in this case the
same issues as per Section 3.1.1. If there is a CLAT function in the same issues as per Section 3.1.1. If there is a CLAT function in the
IETF network, then there is no need to use DNS64 and it falls under IETF network, then there is no need to use DNS64 and it falls under
the considerations of Section 3.1.3. Both scenarios have been tested the considerations of Section 3.1.3. Both scenarios have been tested
and verified 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 an IPv6-only enterprise Figure 14 provides an example of an IPv6-only enterprise network
network connected with dual-stack to Internet and using local NAT64 connected with dual-stack to Internet and using local NAT64 and DNS64
and DNS64 functions. 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 a dual-stack (DS) Figure 15 provides an example of a dual-stack (DS) enterprise network
enterprise network connected with dual-stack (DS) to Internet and connected with dual-stack (DS) to Internet and using a CLAT function,
using a CLAT function, without a DNS64 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, Figure 16 provides an example of an IPv6-only provider with
provider with a NAT64 function, and a dual-stack (DS) enterprise a NAT64 function, and a dual-stack (DS) enterprise network by means
network by means of their own CLAT function, without a DNS64 of their own CLAT function, without a DNS64 function.
function.
+----------------------------------+ +----------------------------------+
| Enterprise Network | | Enterprise Network |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
| | IPv6 | | | | IPv6 | | | | IPv6 | | | | IPv6 | |
| | + +--------+ CLAT | +--------+ NAT64 | | | + +--------+ CLAT | +--------+ NAT64 |
| | IPv4 | | | | only | | | | IPv4 | | | | only | |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+
Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64 Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64
7. Security Considerations 7. Security Considerations
This document does not have new specific security considerations This document does not have new specific security considerations
beyond those already reported by each of the documents cited. beyond those already reported by each of the documents cited.
It should be remarked that the use of a DNS64 function has equivalent
privacy considerations as in the case of a regular DNS, either
located in the service provider or an external one.
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.
Alternatively, this could be fixed also by
[I-D.cheshire-sudn-ipv4only-dot-arpa].
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, Alejandro D'Egidio, Dan Wing and Mikael Abrahamsson. Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson and Eric
Vyncke.
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
skipping to change at page 35, line 31 skipping to change at page 36, line 38
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 needs to be arranged In this case, the discovery of the PLAT prefix needs to be arranged
as 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 function, or the In this case, the CE doesn't have a built-in CLAT function, or the
customer can choose to setup the IPv6 operator-managed CE in bridge customer can choose to setup the IPv6 operator-managed CE in bridge
mode (and optionally use an external router), or for example, there mode (and optionally use an external router), or for example, there
is an access technology that requires some kind of media converter is an access technology that requires some kind of media converter
(ONT for FTTH, Cable-Modem for DOCSIS, etc.), the complete setup will (ONT for FTTH, Cable-Modem for DOCSIS, etc.), the complete setup will
look as in the next figure. Obviously, there will be some look as in Figure 19. Obviously, there will be some intermediate
intermediate configuration steps for the bridge, depending on the configuration steps for the bridge, depending on the specific access
specific access technology/protocols, which should not modify the technology/protocols, which should not modify the steps already
steps already described in the previous cases for the CLAT function described in the previous cases for the CLAT function configuration.
configuration.
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
| Res./ | / IPv6- \ .-----. / IPv4- \ | Res./ | / IPv6- \ .-----. / IPv4- \
| SOHO +--( only )--( NAT64 )--( only ) | SOHO +--( only )--( NAT64 )--( only )
| | \ flow / `-----' \ flow / | | \ flow / `-----' \ flow /
| IPv6 | \ / \ / | IPv6 | \ / \ /
| CE | `--+--' `--+--' | CE | `--+--' `--+--'
| Bridge| | | | Bridge| | |
| | +---+----+ +---+----+ | | +---+----+ +---+----+
skipping to change at page 37, line 10 skipping to change at page 38, line 10
o [RFC7915] for the NAT46 function. 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 [I-D.li-intarea-nat64-prefix-dhcp-option] for the PLAT prefix
discovery by means of DHCP.
o If stateless NAT46 is supported, a mechanism to ensure that 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 Jool: https://www.jool.mx.
o Linux: https://github.com/toreanderson/clatd. o Linux: https://github.com/toreanderson/clatd.
skipping to change at page 38, line 31 skipping to change at page 39, line 33
17. ANNEX H: Changes from -05 to -06 17. ANNEX H: Changes from -05 to -06
Section to be removed after WGLC. Significant updates are: Section to be removed after WGLC. Significant updates are:
1. Corrected EAMT to EAM. 1. Corrected EAMT to EAM.
2. Typos and nits. 2. Typos and nits.
3. New considerations regarding incoming connections. 3. New considerations regarding incoming connections.
18. References 18. ANNEX H: Changes from -06 to -07
18.1. Normative References Section to be removed after WGLC. Significant updates are:
1. Inputs/clarifications from IESG review.
19. References
19.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>.
skipping to change at page 41, line 5 skipping to change at page 42, line 15
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
18.2. Informative References 19.2. Informative References
[About-DNS64] [About-DNS64]
Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016, Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 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/>.
[ARCEP] ARCEP, "Service client des operateurs : les mesures de
qualite de service", 2018, <https://www.arcep.fr/
cartes-et-donnees/nos-publications-chiffrees/
service-client-des-operateurs-mesures-de-la-qualite-de-
service/service-client-des-operateurs-les-mesures-de-
qualite-de-service.html>.
[DNS64-Benchm] [DNS64-Benchm]
Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64
Implementations: Theory and Practice", Computer Implementations: Theory and Practice", Computer
Communications , vol. 127, no. 1, pp. 61-74, Communications , vol. 127, no. 1, pp. 61-74,
DOI 10.1016/j.comcom.2018.05.005, September 2018. DOI 10.1016/j.comcom.2018.05.005, September 2018.
[DNS64-BM-Meth] [DNS64-BM-Meth]
Lencse, G., Georgescu, M., and Y. Kadobayashi, Lencse, G., Georgescu, M., and Y. Kadobayashi,
"Benchmarking Methodology for DNS64 Servers", Computer "Benchmarking Methodology for DNS64 Servers", Computer
Communications , vol. 109, no. 1, pp. 162-175, Communications , vol. 109, no. 1, pp. 162-175,
DOI 10.1016/j.comcom.2017.06.004, September 2017. DOI 10.1016/j.comcom.2017.06.004, September 2017.
[FCC] FCC, "Measuring Broadband America Mobile 2013-2018
Coarsened Data", 2018, <https://www.fcc.gov/reports-
research/reports/measuring-broadband-america/
measuring-broadband-america-mobile-2013-2018>.
[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.cheshire-sudn-ipv4only-dot-arpa]
Cheshire, S. and D. Schinazi, "Special Use Domain Name
'ipv4only.arpa'", draft-cheshire-sudn-ipv4only-dot-arpa-14
(work in progress), November 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
progress), March 2019. progress), March 2019.
[I-D.ietf-6man-ra-pref64] [I-D.ietf-6man-ra-pref64]
Colitti, L., Kline, E., and J. Linkova, "Discovering Colitti, L. and J. Linkova, "Discovering PREF64 in Router
PREF64 in Router Advertisements", draft-ietf-6man-ra- Advertisements", draft-ietf-6man-ra-pref64-01 (work in
pref64-00 (work in progress), March 2019. progress), June 2019.
[I-D.ietf-tram-turnbis]
K, R., Johnston, A., Matthews, P., and J. Rosenberg,
"Traversal Using Relays around NAT (TURN): Relay
Extensions to Session Traversal Utilities for NAT (STUN)",
draft-ietf-tram-turnbis-27 (work in progress), June 2019.
[I-D.li-intarea-nat64-prefix-dhcp-option] [I-D.li-intarea-nat64-prefix-dhcp-option]
Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet, Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet,
"DHCPv6 Options for Discovery NAT64 Prefixes", draft-li- "DHCPv6 Options for Discovery NAT64 Prefixes", draft-li-
intarea-nat64-prefix-dhcp-option-02 (work in progress), intarea-nat64-prefix-dhcp-option-02 (work in progress),
April 2019. April 2019.
[I-D.lmhp-v6ops-transition-comparison] [I-D.lmhp-v6ops-transition-comparison]
Lencse, G., Palet, J., Howard, L., Patterson, R., and I. Lencse, G., Palet, J., Howard, L., Patterson, R., and I.
Farrer, "Pros and Cons of IPv6 Transition Technologies for Farrer, "Pros and Cons of IPv6 Transition Technologies for
IPv4aaS", draft-lmhp-v6ops-transition-comparison-02 (work IPv4aaS", draft-lmhp-v6ops-transition-comparison-03 (work
in progress), January 2019. in progress), July 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", draft-
Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress),
in progress), March 2019. June 2019.
[I-D.vixie-dns-rpz] [I-D.vixie-dns-rpz]
Vixie, P. and V. Schryver, "DNS Response Policy Zones Vixie, P. and V. Schryver, "DNS Response Policy Zones
(RPZ)", draft-vixie-dns-rpz-04 (work in progress), (RPZ)", draft-vixie-dns-rpz-04 (work in progress),
December 2016. December 2016.
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
"Analysis of Stateful 64 Translation", RFC 6889, "Analysis of Stateful 64 Translation", RFC 6889,
DOI 10.17487/RFC6889, April 2013, DOI 10.17487/RFC6889, April 2013,
<https://www.rfc-editor.org/info/rfc6889>. <https://www.rfc-editor.org/info/rfc6889>.
 End of changes. 70 change blocks. 
181 lines changed or deleted 263 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/