draft-ietf-v6ops-nat64-deployment-02.txt   draft-ietf-v6ops-nat64-deployment-03.txt 
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational August 14, 2018 Intended status: Informational October 10, 2018
Expires: February 15, 2019 Expires: April 13, 2019
NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks
draft-ietf-v6ops-nat64-deployment-02 draft-ietf-v6ops-nat64-deployment-03
Abstract Abstract
This document describes how NAT64 and 464XLAT can be deployed in an This document describes how NAT64 and 464XLAT can be deployed in an
IPv6 network, whether cellular ISP, broadband ISP, or enterprise and IPv6 network, whether cellular ISP, broadband ISP, or enterprise and
the issues to be considered when having an IPv6-only access link, the issues to be considered when having an IPv6-only access link,
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 35 skipping to change at page 1, line 35
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 February 15, 2019. This Internet-Draft will expire on April 13, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 31 skipping to change at page 2, line 31
4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 16 4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 16
4.1. DNSSEC Considerations and Possible Approaches . . . . . . 16 4.1. DNSSEC Considerations and Possible Approaches . . . . . . 16
4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 17 4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 17
4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 18 4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 18
4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 18 4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 18
4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 19 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 19
4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 19 4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 19
4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 19 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 19
4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 19 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 19
4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 20 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 20
4.4. Manual Configuration of Foreign DNS . . . . . . . . . . . 20 4.4. Manual Configuration of Foreign DNS . . . . . . . . . . . 21
4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 21 4.6. Split DNS . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22 4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 22
4.8. IPv4-only Hosts or Applications . . . . . . . . . . . . . 22 4.8. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22
4.9. CLAT Translation Considerations . . . . . . . . . . . . . 22 4.9. IPv4-only Hosts or Applications . . . . . . . . . . . . . 23
5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23 4.10. CLAT Translation Considerations . . . . . . . . . . . . . 23
6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 31 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 28
12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 32
13. ANNEX D: Changes from -00 and -01 . . . . . . . . . . . . . . 31 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. ANNEX D: Changes from -00 and -01 . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . 31 14. ANNEX D: Changes from -01 and -02 . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . 33 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 15.1. Normative References . . . . . . . . . . . . . . . . . . 33
15.2. Informative References . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation
mechanisms, which allows IPv6-only hosts to communicate with mechanism, which allows IPv6-only hosts to communicate with IPv4-only
IPv4-only servers using unicast UDP, TCP or ICMP, by means of IPv4 servers using unicast UDP, TCP or ICMP, by means of IPv4 public
public addresses sharing (assigned to the translator), among multiple addresses sharing (assigned to the translator), among multiple
IPv6-only hosts. IPv6-only hosts.
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 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,
avoiding changes in both, the IPv6-only hosts and the IPv4-only avoiding changes in both, the IPv6-only hosts and the IPv4-only
server, so they can use a NAT64. As discussed in Section 5.5 of server, so they can use a NAT64. As discussed in Section 5.5 of
skipping to change at page 3, line 48 skipping to change at page 3, line 48
c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or
applications located within a network which are connected to a applications located within a network which are connected to a
service provider IPv6-only access, as it was designed for a very service provider IPv6-only access, as it was designed for a very
specific scenario ([RFC6144], Section 2.1). specific scenario ([RFC6144], Section 2.1).
The same issues are true if part of, for example, an enterprise The same issues are true if part of, for example, an enterprise
network, is connected to other parts of the same network or third network, is connected to other parts of the same network or third
party networks by means of IPv6-only connectivity. This applies to party networks by means of IPv6-only connectivity. This applies to
many other similar cases. many other similar cases.
According to that, across this document, the use of "operator According to that, across this document, the use of "operator",
network" is interchangeable with equivalent cases of enterprise (or "operator network", "service provider", and similar ones, are
similar) networks. interchangeable with equivalent cases of enterprise networks (and
similar ones). This may be also the case for other "managed end-user
networks".
An analysis of stateful IPv6/IPv6 mechanisms is provided in An analysis of stateful IPv6/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 and similar ones,
which were not documented by [RFC6144], such as 464XLAT ([RFC6877]), which were not documented by [RFC6144], such as 464XLAT ([RFC6877]),
in operator (broadband and cellular) and enterprise networks, and in operator (broadband and cellular) and enterprise networks, and
provides guidelines to avoid the above-mentioned issues. provides guidelines to avoid the above-mentioned 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
skipping to change at page 4, line 43 skipping to change at page 4, line 44
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 3 scenarios, looking at the
location of the DNS64. However, since the publication of that location of the DNS64. However, since the publication of that
document, there are new possible scenarios and NAT64 use cases that document, other possible scenarios and NAT64 use cases need to be
need to be considered now, despite they were specifically ruled out considered in actual networks, despite some of them were specifically
of the original NAT64/DNS64 work. ruled out of 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 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. 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).
We use 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/services (IPv4).
3. The NAT64 function (NAT64) in the service provider. 3. The NAT64 function (NAT64) in the service provider.
4. The DNS64 function (DNS64) in the service provider. 4. The 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 and/or the DNS64
function (extNAT64/extDNS64). function (extNAT64/extDNS64).
6. 464XLAT customer side translator (CLAT). 6. 464XLAT customer side translator (CLAT).
We split the possible scenarios 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.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
| | | | | | | | | |
| IPv6 +-------------+--------------+ IPv4 | | IPv6 +-------------+--------------+ IPv4 |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
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 only, and the DNS64 function is from an external provider
with or without a specific agreement among them. This is a scenario with or without a specific agreement among them. This is a scenario
already feasible today, as several "global" service providers provide already common today, as several "global" service providers provide
free DNS64 services and users often configure manually their DNS. free DNS/DNS64 services and users often configure manually their DNS.
This will only work if both the NAT64 and the DNS64 are using the WKP This will only work if both the NAT64 and the DNS64 are using the WKP
(Well-Known Prefix) or the same NSP (Network-Specific Prefix). All (Well-Known Prefix) or the same NSP (Network-Specific Prefix). All
the considerations in the previous paragraphs of this section are the the considerations in the previous paragraphs of this section are the
same for this sub-case. same for this sub-case.
Of course, if the external DNS64 is agreed with the service provider, Of course, if the external DNS64 is agreed with the service provider,
then we are in the same case as in the previous ones already depicted then we are in the same case as in the previous ones already depicted
in this scenario. in this scenario.
+----------+ +----------+
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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 RR).
Note that even in the 464XLAT ([RFC6877]) terminology, the provider- Note that even in the 464XLAT ([RFC6877]) terminology, the provider-
side translator is referred as PLAT, for simplicity and uniformity, side translator is referred as PLAT, for simplicity and uniformity,
in this document is always referred as NAT64. in this document is always referred as NAT64.
In this scenario the service provider deploys 464XLAT with DNS64. In this scenario the service provider deploys 464XLAT with DNS64.
As a consequence, the DNSSEC issues remain, unless the if the host is As a consequence, the DNSSEC issues remain, unless the host is doing
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 in IPv6-only cellular 464XLAT ([RFC6877]) has been used initially mainly in IPv6-only
networks. By supporting CLAT, the end-user device applications can cellular networks. By supporting CLAT, the end-user device
access IPv4-only end-networks/applications, despite those applications can access IPv4-only end-networks/applications, despite
applications or devices use literal IPv4 addresses or non-IPv6 those applications or devices use literal IPv4 addresses or non-IPv6
compliant APIs. It is also used for tethering purposes. 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 inside
the IPv6-only access network. the IPv6-only access network.
Furthermore, as indicated in [RFC6877], 464XLAT can be used in Furthermore, as indicated 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. functionality at the CE.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
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.
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 inside the IPv6-only access network, neither to to IPv4-only hosts (or IPv4-only applications) inside the IPv6-only
the usage of IPv4 literals or non-IPv6 compliant APIs. access network, neither to the usage of IPv4 literals or non-IPv6
compliant APIs.
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/ / \ | | \ Internet/\ `-----' \ Internet/
( Dual- )--+ IPv6 | \ / \ / \ / ( Dual- )--+ IPv6 | \ / \ / \ /
skipping to change at page 13, line 19 skipping to change at page 13, line 19
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. as if they were synthesized by a DNS64.
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). The latest, may have
implications in DNSSEC, if the zone is signed. Also, if the service implications in DNSSEC, if the zone is signed. Also, if the service
provider is using a NSP, having the mapping at the authoritative provider is using an NSP, having the mapping at the authoritative
server, will mean that may create troubles to other parties trying to server, will mean that may create troubles to other parties trying to
use different NSP or the WKP, unless multiple DNS "views" are also use different NSP or the WKP, unless multiple DNS "views" are also
being used at the authoritative servers. 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 reduced set of them, which support IPv6-only in the access, with
some kind of mutual agreement for using this procedure, so it doesn't some kind of mutual agreement for using this procedure, so it doesn't
care if they become a trouble for other parties across Internet care if they become a trouble for other parties across Internet
("closed services"). ("closed services").
skipping to change at page 15, line 17 skipping to change at page 15, line 17
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 changes the
DNS? Note that this apply similarly to split DNS, DNS in VPNs DNS? Note that this apply similarly to split DNS, DNS in VPNs
and DNS privacy. and DNS privacy.
In the next table, the columns represent each of the scenario from In the next table, the columns represent each of the scenario from
the previous sections, by the Figure number. The possible values the previous sections, by the Figure number. The possible values
are: are:
- Scenario "bad" for that item. o - Scenario "bad" for that item.
+ Scenario "good" for that item. o + Scenario "good" for that item.
Needs to be noted that in some cases "countermeasures", alternative Needs to be noted that in some cases "countermeasures", alternative
or special configurations, may be available for the items designated or special configurations, may be available for the items designated
as "bad", so this comparison is making a generic case, as a quick 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 comparison guide. In some cases, a "bad" item is not necessarily a
negative aspect, all it depends on the specific needs/characteristics negative aspect, all it depends on the specific needs/characteristics
of the network where the deployment will take place. For instance, of the network where the deployment will take place. For instance,
in a network which has only IPv6-only hosts and apps using only DNS 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 and IPv6-compliant APIs, there is no impact using only NAT64 and
DNS64, but if the hosts may validate DNSSEC, that item is still DNS64, but if the hosts may validate DNSSEC, that item is still
skipping to change at page 17, line 9 skipping to change at page 17, line 9
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 The ideal solution to avoid DNSSEC issues, will be that all the
signed zones also provide IPv6 connectivity, together with the signed zones also provide IPv6 connectivity, together with the
corresponding AAAA records, which is out of the control of the corresponding AAAA records, which is out of the control of the
operator needing to deploy NAT64. operator needing to deploy NAT64. This has been proposed already in
[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.
Previous data seems to indicate, that the figures of DNSSEC broken by
using DNS64 will be around 1.7% ([About-DNS64]).
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 (or
saying it in a different way: "trying to look for the most perfect saying it in a different way: "trying to look for the most perfect
approach"), because breaking DNSSEC will not happen if the end-host approach"), because breaking DNSSEC will not happen if the end-host
is not doing validation, which is the case today in 1.7% of the is not doing validation. Previous data seems to indicate that the
cases. So, a decision point for the operator must depend on "do I figures of DNSSEC actually broken by using DNS64 will be around 1.7%
really care for that percentage of cases or can I provide alternative ([About-DNS64]) of the cases. So, a decision point for the operator
solutions for them?". Some possible solutions may be taken, as must depend on "do I really care for that percentage of cases and the
depicted in the next sections. 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 The ideal solution will be to avoid using DNS64, but as already
indicated this is not possible in all the scenarios. indicated this is not possible in all the scenarios.
However, not having a DNS64, means that is not possible to However, not having a DNS64, means that is not possible to
heuristically discover the NAT64 ([RFC7050]) and consequently, an heuristically discover the NAT64 ([RFC7050]) and consequently, an
IPv6 host in the IPv6-only access network, will not be able to detect IPv6 host in the IPv6-only access network, will not be able to detect
the presence of the NAT64, neither to learn the IPv6 prefix to be the presence of the NAT64, neither to learn the IPv6 prefix to be
skipping to change at page 18, line 19 skipping to change at page 18, line 19
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 (Response
Policy Zones). Policy Zones).
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), to
follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP).
Other alternatives may be available in the future, such as DHCPv6 Other alternatives may be available in the future, such as Router
options. Advertising ([I-D.pref64folks-6man-ra-pref64]) or DHCPv6 options.
It may be convenient to support at the same time several of the It may be convenient to support at the same time several of the
approaches described, in order to ensure that clients with different approaches described, in order to ensure that clients with different
ways to configure the NAT64 prefix, obtain it. This is also ways to configure the NAT64 prefix, successfully obtain it. This is
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, DNS servers with DNS64 function, by default, 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 is not present as
the hosts will not be able to use IPv4 (scenarios without 464XLAT). 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 as the DNS64 recursive server will not synthesize AAAA responses, the
client could perform the DNSSEC validation with the A record and then client could perform the DNSSEC validation with the A record and then
may query the network for a NAT64 prefix ([RFC7050] or [RFC7225]) in may query the network for a NAT64 prefix ([RFC7050], [RFC7225],
order to synthesize the AAAA ([RFC6052]). This allows the client [I-D.pref64folks-6man-ra-pref64] or other methods) in order to
device to avoid using the CLAT and still use NAT64 even with DNSSEC. synthesize the AAAA ([RFC6052]). This allow the client device to
avoid using the CLAT 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 is not
present (scenarios without 464XLAT) or the client is able to locally present (scenarios without 464XLAT), unless the client is able to
do the address synthesis. locally perform the address synthesis.
Some devices/OSs may implement, instead of CLAT, a similar function Some devices/OSs may implement, instead of CLAT, a similar function
by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy
Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the
considerations in the above paragraphs are also applicable. 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, following the same approach described
in the precedent section (Stub validator). So, the DNS proxy in the precedent Section 4.1.3. So, the DNS proxy actually lies to
actually lies to the client devices, which in most of the cases will the client devices, which in most of the cases will not notice it
not notice it unless they perform validation themselves. Again, this unless they perform validation themselves. Again, this allow the
allow the client devices to avoid using the CLAT and still use NAT64 client devices to avoid using the CLAT and still use NAT64 with
with DNSSEC. DNSSEC.
Once more, this will not work without a CLAT (scenarios without Once more, this will not work without a CLAT (scenarios without
464XLAT). 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, stub resolvers should send the AAAA
queries before the A ones. So, such clients, if DNS64 is enabled, queries before the A ones. So, such clients, if DNS64 is enabled,
will never get A records, even for IPv4-only servers, and they may be will never get A records, even for IPv4-only servers, and they may be
in the path before the NAT64 and accessible by IPv4. If DNSSEC is in the path before the NAT64 and accessible by IPv4. If DNSSEC is
skipping to change at page 20, line 12 skipping to change at page 20, line 13
reverse-map the synthesized IPv6 address (the one under ip6.arpa), to reverse-map the synthesized IPv6 address (the one under ip6.arpa), to
the domain name corresponding to the embedded IPv4 address (under in- the domain name corresponding to the embedded 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 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
is IPv6-only, or because it is connected via an IPv6-only LAN) and or application is IPv6-only, or because it is connected via an
the remote server is IPv4-only (either because the stack is IPv6-only LAN) and the remote server is IPv4-only (either because the
IPv4-only, or because it is connected via an IPv4-only LAN), only stack is IPv4-only, or because it is connected via an IPv4-only LAN),
NAT64 combined with DNS64 will be able to provide access among both. only NAT64 combined with DNS64 will be able to provide access among
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
applications or operating systems are IPv6-only, and it will not be a
sensible decision for a developer to work on that direction, unless
it is clear that the deployment scenario allows it. On the other
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
IPv6-only, the operating system may be responsible either for doing a
local address synthesis, or alternatively, setting up some kind of
on-demand VPN (IPv4-in-IPv6), which need to be supported by that
network. This may become very common in enterprise networks, where
"Unique IPv6 Prefix per Host" [RFC8273].
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 (or has the built-in CLAT), DNS64
is an option. 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.
skipping to change at page 21, line 12 skipping to change at page 21, line 25
Even in the case that the external DNS supports DNS64 function, we Even in the case that the external DNS supports DNS64 function, we
may be in the situation of providing incorrect configurations may be in the situation of providing incorrect configurations
parameters, for example un-matching WKP or NSP, or a case such the parameters, for example un-matching WKP or NSP, or a case such the
one described in Section 3.2.3. one described in Section 3.2.3.
A similar situation may happen in case of split DNS scenarios, for A similar situation may happen in case of split DNS scenarios, for
example, when using a VPN that forces all the DNS queries thru the example, when using a VPN that forces all the DNS queries thru the
VPN, ignoring the DNS64. VPN, ignoring the DNS64.
Having a CLAT and using an external DNS without DNS64, ensures that Having a CLAT, even if using an external DNS without DNS64, ensures
everything will work, so the CLAT must be considered as an advantage that everything will work, so the CLAT must be considered as an
against user configuration errors. advantage against user configuration errors.
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, (scenarios without 464XLAT), an external DNS without DNS64 support,
will not only guarantee that DNSSEC is broken, but also disallow any will disallow any access to IPv4-only networks, and will not
access to IPv4-only networks, so will behave as in the Section 3.2.1. guarantee DNSSEC, so will behave as in the Section 3.2.1.
4.5. DNS Privacy 4.5. DNS Privacy
If clients use mechanisms for DNS privacy, such as DNS over TLS If clients use mechanisms for DNS privacy, such as DNS over TLS
([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS ([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS
([I-D.ietf-doh-dns-over-https]) or DNS over QUIC ([I-D.ietf-doh-dns-over-https]) or DNS over QUIC
([I-D.huitema-quic-dnsoquic]), as they may provide different results ([I-D.huitema-quic-dnsoquic]), as they may provide different results
to the same query, it must be expected equivalent effects as to the same query, it must be expected equivalent effects as
described in Section 4.4. described in Section 4.4.
4.6. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 4.6. Split DNS
As already indicated in precedent sections, the successful use of the
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)
[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
skipping to change at page 22, line 9 skipping to change at page 22, line 32
NSP may be a more appropriate option in those cases. 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 NAT64s 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 NAT64s 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, or by ensuring that all the NAT64s coordinate their state.
Using an NSP could facilitate that. Using an NSP could facilitate that.
d. If DNS64 is required and users may change their DNS d. If DNS64 is required and users may change their DNS
configuration, and deliberately choose an alternative DNS64, most configuration, and deliberately choose an alternative DNS64, most
probably alternative DNS64 will use by default the WKP. If an probably alternative DNS64s will use by default the WKP. In that
NSP is used by the NAT64, the users will not be able to use the case, if an NSP is used by the NAT64, the users will not be able
operator NAT64. to use the operator NAT64.
4.7. IPv4 literals and old APIs 4.8. IPv4 literals and old APIs
A hosts or application using literal IPv4 addresses or older APIs, A hosts 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 a CLAT
(or equivalent function) is present. (or equivalent function) is present.
A possible alternative approach is described as part of Happy A possible alternative approach is described as part of Happy
Eyeballs v2 Section 7.1 ([RFC8305]), or if not supporting HEv2, Eyeballs v2 Section 7.1 ([RFC8305]). When HEv2 is not supported, one
directly using Bump-in-the-Host ([RFC6535]), and then a DNS64 more alternative is using Bump-in-the-Host ([RFC6535]), and then a
function. DNS64 function.
Those alternatives will solve the problem for and end-hosts, however, Those alternatives will solve the problem for and end-hosts, 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 others hosts, that need 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 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, 464XLAT is the only valid approach to resolve this issue.
4.8. IPv4-only Hosts or Applications 4.9. 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 is present. 464XLAT is the only
valid approach to resolve this issue. valid approach to resolve this issue.
4.9. CLAT Translation Considerations 4.10. 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 can be configured with a dedicated /64 prefix for the NAT46
translation, then it will be possible to do a more efficient translation, then it will be possible to do a more efficient
stateless translation. stateless translation.
However, if this dedicated prefix is not available, the CLAT will However, if this dedicated prefix is not available, the CLAT will
need to do a stateful translation, for example performing stateful need to do a stateful translation, for example performing stateful
NAT44 for all the IPv4 LAN packets, so they appear as coming from a NAT44 for all the IPv4 LAN packets, so they appear as coming from a
single IPv4 address, and then in turn, stateless translated to a single IPv4 address, and then in turn, stateless translated to a
single IPv6 address. single IPv6 address.
One possible setup, in order to maximize the CLAT performance, is to One 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 ([RFC3633]) so, able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]), or
the CE can use a /64 for that. This is also possible when broadband other alternatives, so the CE can use a specific /64 for the
is provided by a cellular access. translation. This is also possible when broadband is provided by a
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 they don't use DHCPv6-PD when connecting smartphones (as UEs), as generally they don't use
([RFC3633]) an instead a single /64 is provided for each PDP context DHCPv6-PD ([RFC3633]) an instead a single /64 is provided for each
and use /64 prefix sharing ([RFC6877]). So, in this case, the UEs PDP context and use /64 prefix sharing ([RFC6877]). So, in this
typically have a build-in CLAT client, which is doing a stateful case, the UEs typically have a build-in CLAT client, which is doing a
NAT44 before the stateless NAT46. stateful NAT44 before the stateless NAT46.
5. Summary of Deployment Recommendations for NAT64 5. Summary of Deployment Recommendations for NAT64/464XLAT
It can be argued that none of the possible transition mechanisms is It can be argued that none of the possible transition mechanisms is
perfect, and somehow, we may consider that actually this is a good perfect, and somehow, we may consider that actually this is a good
thing as a way to push for the IPv6 deployment, or otherwise, it may thing as a way to push for the IPv6 deployment, or otherwise, it may
be further delayed, with clear undesirable effects for the global be further delayed, with clear undesirable effects for the global
Internet. Internet.
However, for an operator, being in business means minimizing the However, for an operator, being in business means minimizing the
adverse transition effects, and provide the most perfect one adverse transition effects, and provide the most perfect one,
reasonably balanced with cost (CAPEX/OPEX), and at the same time reasonably balanced with cost (CAPEX/OPEX) and at the same time,
looking for a valid long-term vision. 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.
Depending on those requirements, DNS64 may be a required function, Depending on those requirements, DNS64 may be a required function,
while in other cases the adverse effects may be counterproductive. while in other cases the adverse effects may be counterproductive.
Similarly, in some cases NAT64, together with DNS64, may be a valid Similarly, in some cases NAT64, together with DNS64, may be a valid
solution, when for sure there is no need to support hosts or solution, when for sure there is no need to support hosts or
applications which are IPv4-only (Section 4.7 and Section 4.8). applications which are IPv4-only (Section 4.8 and Section 4.9).
However, in other cases the limitations they have, may suggest the However, in other cases the limitations they have, may suggest the
operator to look into 464XLAT as a more complete solution. operator to look into 464XLAT as a more complete solution.
Service providers willing to deploy NAT64, need to take into account Service providers willing to deploy NAT64, need to take into account
the considerations of this document in order to better decide what is the considerations of this document in order to better decide what is
more appropriate for their own specific case. more appropriate for their own specific case.
In the case of broadband managed networks (CE provided or suggested/ In the case of broadband managed networks (CE provided or suggested/
supported by the operator), in order to fully support the actual user supported by the operator), in order to fully support the actual user
needs (IPv4-only devices and applications, usage of literals and old needs (IPv4-only devices and applications, usage of literals and old
skipping to change at page 24, line 23 skipping to change at page 24, line 46
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 each operator, depending on their addresses) MAY be considered by operators, depending on their own
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. Section 4.1.1, must be followed in order to learn he NAT64 prefix.
The operator need to consider that if the user can modify the DNS The operator needs to consider that if the user can modify the DNS
configuration (which most probably is impossible to avoid), and configuration (which most probably is impossible to avoid), and
instead of configuring a DNS64 choose an external regular DNS (non- instead of configuring a DNS64 choose an external regular DNS (non-
DNS64), a scenario with only NAT64 will not work with any IPv4-only DNS64), a scenario with only NAT64 will not work with any IPv4-only
remote host, while it will continue working in the case of 464XLAT remote host, while it will continue working in the case of 464XLAT
(Section 4.4). Same effects are to be expected if DNS privacy (Section 4.4). Same effects are to be expected if DNS privacy
protocols are being used by customers (Section 4.5). 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 vs Network-Specific Prefix (Section 4.6), in the NAT64 Well-Known-Prefix (WKP) vs Network-Specific Prefix (NSP)
sense of, if using DNS64, they must match and if the user can change (Section 4.7), in the sense of, if using DNS64, they must match and,
the DNS configuration, they will, most probably, not. if the user can change the DNS configuration, they will, most
probably, not match. If there is a CLAT and the users chosen DNS is
not a DNS64, the network will keep working of other means of learning
the NAT64 are available.
In broadband networks, it is recommended that CEs supporting CLAT, As described in Section 4.10 in broadband networks, it is recommended
support DHCPv6-PD ([RFC3633]) and internally reserve one /64 for the that CEs supporting CLAT, supports DHCPv6-PD ([RFC3633]), or
stateless NAT46 translation. The operator must ensure that the alternative means for configuring a shorter prefix, and internally
customers get allocated prefixes shorter than /64 in order to support reserve one /64 for the stateless NAT46 translation. The operator
this optimization. One way or the other, this is not impacting the must ensure that the customers get allocated prefixes shorter than
performance of the operator network. /64 in order to support this optimization. One way or the other,
this is not impacting the performance of the operator network.
As indicated in Section 7 of [RFC6877] (Deployment Considerations), Operators may follow Section 7 of [RFC6877] (Deployment
operators may follow those 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 OSs, commonly don't support
DNSSEC, however applications running on them may do, or it may be an DNSSEC, however applications running on them may do, or it may be an
OS "built-in" support in the future. Moreover, if those devices OS "built-in" support in the future. Moreover, if those devices
offer tethering, other client devices may be doing the validation, offer tethering, other client devices behind the UE, may be doing the
hence the relevance of a proper DNSSEC support by the operator validation, hence the relevance of a proper DNSSEC support by the
network. 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), in such way
that the network is able to automatically serve all the possible that the network is able to automatically serve every possible
combinations of UEs. combinations of UEs.
One last consideration is that many networks may have different If the operator chooses to provide validation for the DNS64 prefix
scenarios at the same time, for example, customers requiring 464XLAT, discovery, it must follow the advice from Section 3.1. of [RFC7050]
others not requiring it, customers requiring DNS64, others not, etc. (Validation of Discovered Pref64::/n).
In general, the different issues and approaches described in this
document can be implemented at the same time for different customers
or parts of the network, so not representing any problem for complex
cases.
Finally, if the operator chooses to provide validation for the DNS64 One last consideration, is that many networks may have a mix of
prefix discovery, it must follow the advice from Section 3.1. of different complex scenarios at the same time, for example, customers
[RFC7050] (Validation of Discovered Pref64::/n). requiring 464XLAT, others not requiring it, customers requiring
DNS64, others not, etc. In general, the different issues and the
approaches described in this document can be implemented at the same
time for different customers or parts of the network. That mix of
approaches don't present any problem or incompatibility, as they work
well together, being just a matter of appropriate and differentiated
provisioning.
In an ideal world will, we could safely use DNS64, if the approach
proposed in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed,
avoiding the cases where DNSSEC may be broken. However, this will
not solve the issues related to DNS Privacy and Split DNS.
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
making sure that the hosts have a built-in address synthesis feature.
Operators could manage to use the CLAT, however the built-in address
synthesis feature is out of their control, and can only be resolved
by operating system vendors.
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, when the enterprise networks, campus and other similar scenarios (including
NAT64 (and/or DNS64) are under the control of that network, and for managed end-user networks).
whatever reasons, there is a need to provide "IPv6-only access" to
any part of that network or it is IPv6-only connected to third party This include scenarios where the NAT64 (and/or DNS64) are under the
networks. control of that network (or can be configured manually according to
that network specific requirements), and for whatever reasons, there
is a need to provide "IPv6-only 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 a NAT64
and DNS64 are provided, presenting in this case the same issues as and DNS64 are provided, presenting in this case the same issues as
per Section 3.1.1. If there is a CLAT in the IETF network, then per Section 3.1.1. If there is a CLAT in the IETF network, then
there is no need to use DNS64 and it falls under the considerations there is no need to use DNS64 and it falls under the considerations
of Section 3.1.3. Both scenarios have been tested and verified of Section 3.1.3. Both scenarios have been tested and verified
already in the IETF network itself. 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 ones that are feasible. 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 and 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.
+----------------------------------+ +----------------------------------+
| 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 enterprise The following figure provides an example of dual-stack (DS)
network connected with dual-stack to Internet and using CLAT without enterprise network connected with dual-stack (DS) to Internet and
DNS64. using CLAT, without DNS64.
+----------------------------------+ +----------------------------------+
| Enterprise Network | | Enterprise Network |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
| | IPv6 | | | | | IPv4 | | | IPv6 | | | | | IPv4 |
| | + +--------+ NAT64 | +-------+ + | | | + +--------+ NAT64 | +-------+ + |
| | CLAT | | | | | IPv6 | | | CLAT | | | | | IPv6 |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+
Figure 15: Dual-stack enterprise with CLAT 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 enterprise network by means of provider with NAT64, and a dual-stack (DS) enterprise network by
their own CLAT without DNS64. means of their own CLAT, without DNS64.
+----------------------------------+ +----------------------------------+
| Enterprise Network | | Enterprise Network |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
| | IPv6 | | | | IPv6 | | | | IPv6 | | | | IPv6 | |
| | + +--------+ CLAT | +--------+ NAT64 | | | + +--------+ CLAT | +--------+ NAT64 |
| | IPv4 | | | | only | | | | IPv4 | | | | only | |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+
Figure 16: Dual-stack enterprise with CLAT without DNS64 Figure 16: DS enterprise with CLAT, IPv6-only Internet, without DNS64
7. Security Considerations 7. Security Considerations
This document does not have any new specific security considerations. This document does not have any new specific security considerations.
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-
skipping to change at page 27, line 49 skipping to change at page 28, line 38
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 IPv4 inbound connections, several customers. In case they need to support IPv4 inbound connections,
mechanisms, depending on specific customer needs, allow that. several mechanisms, depending on specific customer needs, allow that.
Conceptually, most of the operator network could be IPv6-only Conceptually, most 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 Internet"). This
part of the network connects the IPv6-only subscribers (by means of 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
skipping to change at page 29, line 4 skipping to change at page 29, line 42
\ 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 configuration can be
summarized as: 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 DHCPv6 options). future, such as Router Advertising
([I-D.pref64folks-6man-ra-pref64]) or DHCPv6 options.
2. If the CLAT allows stateless NAT46 translation, a /64 from the 2. If the CLAT allows stateless NAT46 translation, a /64 from the
pool typically provided to the CE by means of DHCPv6-PD pool typically provided to the CE by means of DHCPv6-PD
[RFC3633], need to be set aside for that translation. Otherwise, [RFC3633], 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.9. before the a stateless NAT46, as described in Section 4.10.
The operator network need to ensure that the correct responses are A more detailed configuration approach is described in
[I-D.ietf-v6ops-transition-ipv4aas].
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, as well as it is
highly recommended follows [RIPE-690], in order to ensure that highly recommended follows [RIPE-690], in order to ensure that
multiple /64s are available including the one needed for the NAT46 multiple /64s are available including the one needed for the NAT46
translation. stateless translation.
The operator need 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 are needed in the context of scalability/high-
availability, an NSP should be considered (Section 4.6). availability, an NSP should be considered (Section 4.7).
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 DNS64, then this setup turns
into the one in the following Figure. This will be also the setup into the one in the following Figure. This will be also the setup
that, if the user has changed the DNS and consequently is not using that, if the user has changed the DNS and consequently is not using
the operator DNS64, it will be seen from the perspective of the CE. the operator DNS64, "it will be seen" from the perspective of the CE.
.-----. +-------+ .-----. .-----. .-----. +-------+ .-----. .-----.
/ IPv6- \ | | / \ / \ / IPv6- \ | | / \ / \
( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \
\ LANs / | SOHO +--( only )--( NAT64 )--( only ) \ LANs / | SOHO +--( only )--( NAT64 )--( only )
`-----' | | \ Internet/ `-----' \ Internet/ `-----' | | \ Internet/ `-----' \ Internet/
.-----. | 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 te PLAT prefix need to be arranged as In this case, the discovery of the PLAT prefix need to be arranged as
indicated in Section 4.1.1. indicated in Section 4.1.1.
In this case the CE doesn't have a built-in CLAT, or the customer can In this case, the CE doesn't have a built-in CLAT, or the customer
choose to setup the IPv6 operator-managed CE in bridge mode (and can choose to setup the IPv6 operator-managed CE in bridge mode (and
optionally use its own external router), or for example there is an optionally use its own external router), or for example, there is an
access technology that requires some kind of media converter (ONT for access technology that requires some kind of media converter (ONT for
FTTH, CableModem for DOCSIS, etc.), the complete setup will look as FTTH, CableModem for DOCSIS, etc.), the complete setup will look as
in the next figure. Obviously, there will be some intermediate in the next figure. Obviously, there will be some intermediate
configuration steps for the bridge, depending on the specific access configuration steps for the bridge, depending on the specific access
technology/protocols, which should not modify the steps already technology/protocols, which should not modify the steps already
described in the previous cases for the CLAT configuration. described in the previous cases for the CLAT configuration.
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
| Res./ | / IPv6- \ .-----. / IPv4- \ | Res./ | / IPv6- \ .-----. / IPv4- \
skipping to change at page 30, line 50 skipping to change at page 31, line 43
( Stack )------| ( Stack )------|
\ LANs / \ LANs /
`-----' `-----'
Figure 19: CE setup with bridged CLAT without DNS64 Figure 19: CE setup with bridged CLAT without DNS64
It should be avoided that several routers (i.e., the operator It should be avoided that several routers (i.e., the operator
provided CE and a downstream user provided router) enable provided CE and a downstream user provided router) enable
simultaneously routing and/or CLAT, in order to avoid multiple NAT44 simultaneously routing and/or CLAT, in order to avoid multiple NAT44
and NAT46 levels, as well as ensuring the correct operation of and NAT46 levels, as well as ensuring the correct operation of
multiple IPv6 subnets, so it is suggested to use HNCP ([RFC8375]). multiple IPv6 subnets. In those cases, it is suggested the use of
HNCP ([RFC8375]).
Note that the procedure described here for the CE setup, can be 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
A CLAT CE implementation basically requires support of [RFC7915] for In addition to the regular set of features for a CE, a CLAT CE
the NAT46 functionality, [RFC7050] for the PLAT prefix discovery implementation requires support of:
(and/or [RFC7225] for PCP), and if stateless NAT46 is supported,
mechanisms to ensure that multiple /64 are available, such as o [RFC7915], for the NAT46 functionality.
DHCPv6-PD [RFC3633].
o [RFC7050], for the PLAT prefix discovery.
o [RFC7225], for the PLAT prefix discovery if PCP is supported.
o [I-D.pref64folks-6man-ra-pref64], for the PLAT prefix discovery by
means of Router Advertising.
o If stateless NAT46 is supported, a mechanism to ensure that
multiple /64 are available, such as DHCPv6-PD [RFC3633].
There are several OpenSource implementations of CLAT, such as: There are several OpenSource implementations of CLAT, such as:
Android: https://github.com/ddrown/android_external_android-clat. o Android: https://github.com/ddrown/android_external_android-clat.
Linux: https://github.com/toreanderson/clatd. o Linux: https://github.com/toreanderson/clatd.
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.
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 Several documents provide references to benchmarking, for example in
the case of DNS64, [DNS64-Benchm]. the case of DNS64, [DNS64-Benchm].
13. ANNEX D: Changes from -00 and -01 13. ANNEX D: Changes from -00 and -01
Section to be removed for WGLC. Significant updates are: Section to be removed for WGLC. Significant updates are:
1. Text changes across all the document. 1. Text changes across all the document.
14. References 14. ANNEX D: Changes from -01 and -02
14.1. Normative References Section to be removed for WGLC. Significant updates are:
1. Added references to new cited documents.
2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only
LANs w/o DNS64.
3. Overall review and editorial changes.
15. References
15.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 33, line 19 skipping to change at page 34, line 34
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, "IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016, DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>. <https://www.rfc-editor.org/info/rfc7915>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
<https://www.rfc-editor.org/info/rfc8375>. <https://www.rfc-editor.org/info/rfc8375>.
14.2. Informative References 15.2. Informative References
[About-DNS64] [About-DNS64]
J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, J. Linkova, "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]
G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 G. Lencse and Y. Kadobayashi, "Benchmarking DNS64
Implementations: Theory and Practice", Computer Implementations: Theory and Practice", Computer
Communications (Elsevier), vol. 127, no. 1, pp. 61-74, Communications (Elsevier), 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.
[I-D.bp-v6ops-ipv6-ready-dns-dnssec]
Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC
Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00
(work in progress), October 2018.
[I-D.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-05 (work in Connections", draft-huitema-quic-dnsoquic-05 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-doh-dns-over-https] [I-D.ietf-doh-dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-12 (work in (DoH)", draft-ietf-doh-dns-over-https-14 (work in
progress), June 2018. progress), August 2018.
[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-07 as-a-Service", draft-ietf-v6ops-transition-ipv4aas-09
(work in progress), August 2018. (work in progress), October 2018.
[I-D.pref64folks-6man-ra-pref64]
Colitti, L., Kline, E., and J. Linkova, "Discovering
PREF64 in Router Advertisements", draft-pref64folks-6man-
ra-pref64-02 (work in progress), October 2018.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in
the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
<https://www.rfc-editor.org/info/rfc6950>.
[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>.
[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>.
 End of changes. 83 change blocks. 
178 lines changed or deleted 268 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/