draft-ietf-v6ops-nat64-deployment-01.txt   draft-ietf-v6ops-nat64-deployment-02.txt 
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational August 13, 2018 Intended status: Informational August 14, 2018
Expires: February 14, 2019 Expires: February 15, 2019
NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks
draft-ietf-v6ops-nat64-deployment-01 draft-ietf-v6ops-nat64-deployment-02
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 14, 2019. This Internet-Draft will expire on February 15, 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 26 skipping to change at page 2, line 26
3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 12 3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 12
3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 13 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 13
3.2.3. Service Provider NAT64; DNS64 in the IPv4-only 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only
remote network . . . . . . . . . . . . . . . . . . . 14 remote network . . . . . . . . . . . . . . . . . . . 14
3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 14 3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . 18 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 . . . . . . . . . . . 20
4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 21 4.6. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 21
4.7. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22 4.7. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22
4.8. IPv4-only Hosts or Applications . . . . . . . . . . . . . 22 4.8. IPv4-only Hosts or Applications . . . . . . . . . . . . . 22
4.9. CLAT Translation Considerations . . . . . . . . . . . . . 22 4.9. CLAT Translation Considerations . . . . . . . . . . . . . 22
5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23 5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23
6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27
11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 30 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 31
12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. ANNEX D: Changes from -00 and -01 . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 32 14.1. Normative References . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation, NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation
which allows IPv6-only hosts to contact IPv4 servers using unicast mechanisms, which allows IPv6-only hosts to communicate with
UDP, TCP or ICMP, by means of a single or a set of IPv4 public IPv4-only servers using unicast UDP, TCP or ICMP, by means of IPv4
addresses assigned to the translator, to be shared by the IPv6-only public addresses sharing (assigned to the translator), among multiple
clients. 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-hosts addresses to IPv6 ones following translating the IPv4 addresses to IPv6 addresses following [RFC6052].
[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, avoiding changes in both, the IPv6-only hosts and the the A records, so only works for applications making use of DNS,
IPv4-only server, so they can use a NAT64. 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
[RFC6147], a security-aware and validating host has to perform the
DNS64 function locally.
However, the use of NAT64 and/or DNS64 present three issues: However, the use of NAT64 and/or DNS64 present three issues:
a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is
designed to detect such modifications, DNS64 ([RFC6147]) can designed to detect such modifications, DNS64 ([RFC6147]) can
potentially break DNSSEC, depending on a number of factors, such potentially break DNSSEC, depending on a number of factors, such
as the location of the DNS64 function (at a DNS server or as the location of the DNS64 function (at a DNS server or
validator, at the end host, ...), how it has been configured, if validator, at the end host, ...), how it has been configured, if
the end-hosts is validating, etc. the end-hosts is validating, etc.
b. Because the need of using DNS64 ([RFC6147]), there is a major b. Because the need of using DNS64 ([RFC6147]) or an alternative
issue for NAT64 ([RFC6146]), as doesn't work when literal "host/application built-in" mechanism for address synthesis,
addresses or non-IPv6 compliant APIs are being used. there is a major issue for NAT64 ([RFC6146]), as doesn't work
when literal addresses or non-IPv6 compliant APIs are being used.
c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or c. NAT64 alone, 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. service provider IPv6-only access, as it was designed for a very
specific scenario ([RFC6144], Section 2.1).
The same issues are true if part of an enterprise or similar network, The same issues are true if part of, for example, an enterprise
is connected to other parts of the same network or third party network, is connected to other parts of the same network or third
networks by means of IPv6-only links. party networks by means of IPv6-only connectivity. This applies to
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 network" is interchangeable with equivalent cases of enterprise (or
similar) networks. similar) networks.
An analysis of stateful IPv6/IPv6 mechanisms is provided in
[RFC6889].
This document looks into different possible NAT64 ([RFC6146]) This document looks into different possible NAT64 ([RFC6146])
deployment scenarios, including 464XLAT ([RFC6877]) ones, in deployment scenarios, including IPv4-IPv6-IPv4 and similar ones,
operators (broadband and cellular) and enterprise networks, and which were not documented by [RFC6144], such as 464XLAT ([RFC6877]),
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
under special conditions"), providing a quick and generic comparison under special conditions"), providing a quick and generic comparison
table among them. Then describes the issues that an operator need to table among them. Then the document describes the issues that an
understand on different matters that will allow to define what is the operator need to understand on different matters that will allow to
best approach/scenario for each specific network case. A summary define what is the best approach/scenario for each specific network
provides some recommendations and decision points and then a case. A summary provides some recommendations and decision points
clarification of the usage of this document for enterprise networks and then a clarification of the usage of this document for enterprise
is provided. Finally, an Annex provides an example of a broadband networks is provided. Finally, an annex provides an example of a
deployment using 464XLAT. broadband deployment using 464XLAT.
The target deployment scenarios in this document may be covered as
well by other IPv4-as-a-Service transition mechanisms. It is out of
scope of this document to provide a comparison among them.
[RFC7269] provides additional information about NAT64 deployment
options and experiences.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. NAT64 Deployment Scenarios 3. NAT64 Deployment Scenarios
Section 7 of DNS64 ([RFC6147]), provides 3 scenarios, looking at the Section 7 of DNS64 ([RFC6147]), provides 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, there are new possible scenarios and NAT64 use cases that
need to be considered now, despite they were specifically ruled out need to be considered now, despite they were specifically ruled out
of the original NAT64/DNS64 work. 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 the service provider wants to make sure that all the customers that typically, the service provider wants to make sure that all the
have a service without failures. This means considering the worst customers have a service without failures. This means considering
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. link (e.g., tethering in cellular networks).
We use a common set of possible "participant entities": We use 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.
skipping to change at page 5, line 27 skipping to change at page 5, line 42
3.1. Known to Work 3.1. Known to Work
The scenarios in this category are known to work. Each one may have The scenarios in this category are known to work. Each one may have
different pros and cons, and in some cases the trade-offs, maybe different pros and cons, and in some cases the trade-offs, maybe
acceptable for some operators. acceptable for some operators.
3.1.1. Service Provider NAT64 with DNS64 3.1.1. Service Provider NAT64 with DNS64
In this scenario, the service provider offers both, the NAT64 and the In this scenario, the service provider offers both, the NAT64 and the
DNS64 function. DNS64 functions.
This is probably the most common scenario, however also has the This is probably the most common scenario, however also may have the
implications related the DNSSEC. implications related the DNSSEC.
This scenario also fails to solve the issue of literal addresses or This scenario also may fail to solve the issue of literal addresses
non-IPv6 compliant APIs, as well as the issue of IPv4-only hosts or or non-IPv6 compliant APIs, as well as the issue of IPv4-only hosts
applications inside the IPv6-only access network. or applications inside the IPv6-only access network.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| | | NAT64 | | | | | | NAT64 | | |
| IPv6 +--------+ + +--------+ IPv4 | | IPv6 +--------+ + +--------+ IPv4 |
| | | DNS64 | | | | | | DNS64 | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 1: NAT64 with DNS64 Figure 1: NAT64 with DNS64
A totally equivalent scenario will be if the service provider offers A totally equivalent scenario will be if the service provider offers
skipping to change at page 6, line 44 skipping to change at page 7, line 10
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
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 feasible today, as several "global" service providers provide
free DNS64 services and users often configure manually their DNS. free DNS64 services and users often configure manually their DNS.
This will only work if both the NAT64 and the DNS64 are using the This will only work if both the NAT64 and the DNS64 are using the WKP
same WKP (Well-Known Prefix) or 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.
+----------+ +----------+
| | | |
| extDNS64 | | extDNS64 |
skipping to change at page 7, line 34 skipping to change at page 7, line 48
natively transporting IPv6. natively transporting IPv6.
In order to do that, 464XLAT ([RFC6877]) relies on the combination of In order to do that, 464XLAT ([RFC6877]) relies on the combination of
existing protocols: existing protocols:
1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6 1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6
translator (NAT46) ([RFC7915]) implemented in the end-user device translator (NAT46) ([RFC7915]) implemented in the end-user device
or CE, located at the "customer" edge of the network. or CE, located at the "customer" edge of the network.
2. The provider-side translator (PLAT) is a stateful NAT64 2. The provider-side translator (PLAT) is a stateful NAT64
([RFC6146]), implemented typically at the opposite edge of the ([RFC6146]), implemented typically at in the operator network.
operator network, that provides access to both IPv4 and IPv6
upstreams.
3. Optionally, DNS64 ([RFC6147]), implemented as part of the PLAT 3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a
allows an optimization (a single translation at the NAT64, single translation at the NAT64, instead of two translations
instead of two translations - NAT46+NAT64), when the application (NAT46+NAT64), when the application at the end-user device
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. As a consequence, the DNSSEC issues remain, unless the if the host is
doing 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 cellular 464XLAT ([RFC6877]) has been used initially in IPv6-only cellular
networks, providing an IPv6-only access network. By supporting CLAT, networks. By supporting CLAT, the end-user device applications can
the end-user device applications can access IPv4-only end-networks/ access IPv4-only end-networks/applications, despite those
applications, despite those applications or devices use literal IPv4 applications or devices use literal IPv4 addresses or non-IPv6
addresses or non-IPv6 compliant APIs. compliant APIs. It is also used for tethering purposes.
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 9, line 8 skipping to change at page 9, line 36
b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.
c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that
services are deployed in Internet using IPv6-only, unless there services are deployed in Internet using IPv6-only, unless there
is certainty that peers will also be IPv6-capable. is certainty that peers will also be IPv6-capable.
d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64
translations. translations.
The following pictures show different choices for placing the The following figures show different choices for placing the
different elements. different elements.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | NAT64 | | | | IPv6 | | NAT64 | | |
| + +--------+ + +--------+ IPv4 | | + +--------+ + +--------+ IPv4 |
| CLAT | | DNS64 | | | | CLAT | | DNS64 | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 5: 464XLAT with DNS64 Figure 5: 464XLAT with DNS64
skipping to change at page 11, line 25 skipping to change at page 11, line 47
It needs to be noticed that this scenario works while the local It needs to be noticed that this scenario works while the local
hosts/applications are dual-stack (which is the current situation), hosts/applications are dual-stack (which is the current situation),
because the connectivity from a local-IPv6 to a remote-IPv4 is not because the connectivity from a local-IPv6 to a remote-IPv4 is not
possible without an AAAA synthesis. This aspect is important only possible without an AAAA synthesis. This aspect is important only
when in the LANs behind the CLAT there are IPv6-only hosts and they when in the LANs behind the CLAT there are IPv6-only hosts and they
need to communicate with remote IPv4-only hosts. However, doesn't need to communicate with remote IPv4-only hosts. However, doesn't
look a sensible approach from an Operating System or application look a sensible approach from an Operating System or application
vendor perspective, to provide IPv6-only support unless, similarly to vendor perspective, to provide IPv6-only support unless, similarly to
c. above, there is certainty of peers supporting IPv6 as well. c. above, there is certainty of peers supporting IPv6 as well.
The following pictures show different choices for placing the The following figures show different choices for placing the
different elements. different elements.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | | | | | IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 | | + +--------+ NAT64 +--------+ IPv4 |
| CLAT | | | | | | CLAT | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 8: 464XLAT without DNS64 Figure 8: 464XLAT without DNS64
skipping to change at page 14, line 43 skipping to change at page 14, line 50
| IPv6 +--------+ NAT64 +--------+ + | | IPv6 +--------+ NAT64 +--------+ + |
| | | | | DNS64 | | | | | | DNS64 |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 12: NAT64; DNS64 in the IPv4-only Figure 12: NAT64; DNS64 in the IPv4-only
3.3. Comparing the Scenarios 3.3. Comparing the Scenarios
This section compares the different scenarios, including the possible This section compares the different scenarios, including the possible
variations (each one represented in the precedent sections by a variations (each one represented in the precedent sections by a
different Figure), looking at the following parameters: different figure), looking at the following parameters:
a. DNSSEC: Are there host validating DNSSEC? a. DNSSEC: Are there host validating DNSSEC?
b. Literal/APIs: Are there applications using literals or non-IPv6 b. Literal/APIs: Are there applications using literals or non-IPv6
compliant APIs? compliant APIs?
c. IPv4-only: Are there hosts or applications using IPv4-only? c. IPv4-only: Are there hosts or applications using IPv4-only?
d. Foreign DNS: Is the Scenario surviving if the user changes the d. Foreign DNS: Is the scenario surviving if the user 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. - Scenario "bad" for that item.
+ Scenario "good" for that item. + Scenario "good" for that item.
skipping to change at page 15, line 42 skipping to change at page 15, line 48
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - | | IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - | | Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+
Figure 13: Scenario Comparison Figure 13: Scenario Comparison
As a general conclusion, we should note that if the network must As a general conclusion, we should note that if the network must
support applications using literals, non-IPv6-compliant APIs, or support applications using literals, non-IPv6-compliant APIs, or
IPv4-only hosts or applications, only the scenarios with 464XLAT will IPv4-only hosts or applications, only the scenarios with 464XLAT, or
provide a solution. Further to that, those scenarios will also keep equivalent built-in local address synthesis features, will provide a
working if the user changes the DNS setup. Clearly also, depending solution. Further to that, those scenarios will also keep working if
on if DNS64 is used or not, DNSSEC may be broken for those hosts the user changes the DNS setup. Clearly also, depending on if DNS64
doing DNSSEC validation. is used or not, DNSSEC may be broken for those hosts doing DNSSEC
validation.
4. Issues to be Considered 4. Issues to be Considered
This section reviews the different issues that an operator needs to This section reviews the different issues that an operator needs to
consider towards a NAT64/464XLAT deployment, as they may bring to consider towards a NAT64/464XLAT deployment, as they may bring to
decision points about how to approach that deployment. 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
skipping to change at page 17, line 37 skipping to change at page 17, line 40
depicted in the next sections. 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 DNS64, neither to learn the IPv6 prefix to be the presence of the NAT64, neither to learn the IPv6 prefix to be
used for the NAT64. used for it, unless it is configured by alternative means.
The learning of the IPv6 prefix could be solved by means of adding The learning of the IPv6 prefix could be solved by means of adding
the relevant AAAA records to the ipv4only.arpa. zone of the service the relevant AAAA records to the ipv4only.arpa. zone of the service
provider recursive servers, i.e., if using the WKP (64:ff9b::/96): provider recursive servers, i.e., if using the WKP (64:ff9b::/96):
ipv4only.arpa. SOA . . 0 0 0 0 0 ipv4only.arpa. SOA . . 0 0 0 0 0
ipv4only.arpa. NS . ipv4only.arpa. NS .
ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 ipv4only.arpa. AAAA 64:ff9b::192.0.0.170
ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171
ipv4only.arpa. A 192.0.0.170 ipv4only.arpa. A 192.0.0.170
skipping to change at page 18, line 34 skipping to change at page 18, line 43
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]) in order to may query the network for a NAT64 prefix ([RFC7050] or [RFC7225]) in
synthesize the AAAA ([RFC6052]). This allows the client device to order to synthesize the AAAA ([RFC6052]). This allows the client
avoid using the CLAT and still use NAT64 even with DNSSEC. 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). present (scenarios without 464XLAT) or the client is able to locally
do 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
skipping to change at page 22, line 12 skipping to change at page 22, line 17
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 DNS64 will use by default the WKP. If an
NSP is used by the NAT64, the users will not be able to use the NSP is used by the NAT64, the users will not be able to use the
operator NAT64. operator NAT64.
4.7. IPv4 literals and old APIs 4.7. 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
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]), or if not supporting HEv2,
directly using Bump-in-the-Host ([RFC6535]), and then a DNS64 directly using Bump-in-the-Host ([RFC6535]), and then a DNS64
function. 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
skipping to change at page 22, line 46 skipping to change at page 22, line 51
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.
The obvious recommended setup, in order to maximize the CLAT One possible setup, in order to maximize the CLAT performance, is to
performance, is to configure the dedicated translation prefix. This configure the dedicated translation prefix. This can be easily
can be easily achieved automatically, if the broadband CE or end-user achieved automatically, if the broadband CE or end-user device is
device is able to obtain a shorter prefix by means of DHCPv6-PD able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]) so,
([RFC3633]) so, the CE can use a /64 for that. This is also possible the CE can use a /64 for that. This is also possible when broadband
when broadband is provided by a cellular access. 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 they don't use DHCPv6-PD
([RFC3633]) an instead a single /64 is provided for each PDP context ([RFC3633]) an instead a single /64 is provided for each PDP context
and use /64 prefix sharing ([RFC6877]). So, in this case, the UEs and use /64 prefix sharing ([RFC6877]). So, in this case, the UEs
typically have a build-in CLAT client, which is doing a stateful typically have a build-in CLAT client, which is doing a stateful
NAT44 before the stateless NAT46. NAT44 before the stateless NAT46.
5. Summary of Deployment Recommendations for NAT64 5. Summary of Deployment Recommendations for NAT64
skipping to change at page 23, line 26 skipping to change at page 23, line 31
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, with hundreds of millions of users, offering different scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions
choices of deployment, depending on each network case, needs and of users, offering different choices of deployment, depending on each
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, Section 4.8). applications which are IPv4-only (Section 4.7 and Section 4.8).
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
APIs), they SHOULD consider the 464XLAT scenario and in that case, APIs), they should consider the 464XLAT scenario and in that case,
MUST support the customer-side translator (CLAT). must support the customer-side translator (CLAT).
If the operator offers DNS services, in order to increase performance If the operator offers DNS services, in order to increase performance
by reducing the double translation for all the IPv4 traffic, they MAY by reducing the double translation for all the IPv4 traffic, they may
support DNS64 and avoid, as much as possible, breaking DNSSEC. In support DNS64 and avoid, as much as possible, breaking DNSSEC. In
this case, if the DNS service is offering DNSSEC validation, then it this case, if the DNS service is offering DNSSEC validation, then it
MUST be in such way that it is aware of the DNS64. This is must be in such way that it is aware of the DNS64. This is
considered the simpler and safer approach, and MAY be combined as considered the simpler and safer approach, and may be combined as
well with the other possible solutions described in this document: well with the other possible recommendations described in this
document:
o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2).
o Devices running CLAT SHOULD follow the indications in o Devices running CLAT SHOULD follow the indications in
Section 4.1.3 (Stub validator). However, this may be out of the Section 4.1.3 (Stub validator). However, this may be out of the
control of the operator. control of the operator.
o CEs SHOULD include a DNS proxy and validator (Section 4.1.4). o CEs SHOULD include a DNS proxy and validator (Section 4.1.4).
o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4 o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4
skipping to change at page 24, line 28 skipping to change at page 24, line 35
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.
The operator need to consider that if the user can modify the DNS The operator need 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).
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 vs Network-Specific Prefix (Section 4.6), in the
sense of, if using DNS64, they MUST match and if the user can change sense of, if using DNS64, they must match and if the user can change
the DNS config, they will, most probably, not. the DNS configuration, they will, most probably, not.
The ideal configuration for CEs supporting CLAT, is that they support In broadband networks, it is recommended that CEs supporting CLAT,
DHCPv6-PD ([RFC3633]) and internally reserve one /64 for the support DHCPv6-PD ([RFC3633]) and internally reserve one /64 for the
stateless NAT46 translation. The operator MUST ensure that the stateless NAT46 translation. The operator must ensure that the
customers get allocated prefixes shorter than /64 in order to support customers get allocated prefixes shorter than /64 in order to support
this optimization. One way or the other, this is not impacting the this optimization. One way or the other, this is not impacting the
performance of the operator network. performance of the operator network.
As indicated in Section 7 of [RFC6877] (Deployment Considerations), As indicated in Section 7 of [RFC6877] (Deployment Considerations),
operators MAY follow those suggestions in order to take advantage of operators may follow those suggestions in order to take advantage of
traffic engineering. 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 may be doing the validation,
hence the relevance of a proper DNSSEC support by the operator hence the relevance of a proper DNSSEC support by the operator
network. network.
Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and
skipping to change at page 25, line 29 skipping to change at page 25, line 35
combinations of UEs. combinations of UEs.
One last consideration is that many networks may have different One last consideration is that many networks may have different
scenarios at the same time, for example, customers requiring 464XLAT, scenarios at the same time, for example, customers requiring 464XLAT,
others not requiring it, customers requiring DNS64, others not, etc. others not requiring it, customers requiring DNS64, others not, etc.
In general, the different issues and approaches described in this In general, the different issues and approaches described in this
document can be implemented at the same time for different customers document can be implemented at the same time for different customers
or parts of the network, so not representing any problem for complex or parts of the network, so not representing any problem for complex
cases. cases.
Finally, if the operator chooses to secure the NAT64 prefix, it MUST Finally, if the operator chooses to provide validation for the DNS64
follow the advice from Section 3.1.1. of [RFC7050] (Validation of prefix discovery, it must follow the advice from Section 3.1. of
Discovered Pref64::/n). [RFC7050] (Validation of Discovered Pref64::/n).
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, when the
NAT64 (and/or DNS64) are under the control of that network, and for NAT64 (and/or DNS64) are under the control of that network, and for
whatever reasons, there is a need to provide "IPv6-only access" to 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 any part of that network or it is IPv6-only connected to third party
networks. networks.
skipping to change at page 27, line 20 skipping to change at page 27, line 31
This document does not have any new specific IANA considerations. This document does not have any new specific IANA considerations.
Note: This section is assuming that https://www.rfc- Note: This section is assuming that https://www.rfc-
editor.org/errata/eid5152 is resolved, otherwise, this section may editor.org/errata/eid5152 is resolved, otherwise, this section may
include the required text to resolve the issue. include the required text to resolve the issue.
9. Acknowledgements 9. Acknowledgements
The author would like to acknowledge the inputs of Gabor Lencse, The author would like to acknowledge the inputs of Gabor Lencse,
Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker and TBD ... Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed
Boucadair and TBD ...
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 31, line 19 skipping to change at page 31, line 32
OpenWRT: https://github.com/openwrt- 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. 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. References 13. ANNEX D: Changes from -00 and -01
13.1. Normative References Section to be removed for WGLC. Significant updates are:
1. Text changes across all the document.
14. References
14.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 31, line 43 skipping to change at page 32, line 15
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003, DOI 10.17487/RFC3633, December 2003,
<https://www.rfc-editor.org/info/rfc3633>. <https://www.rfc-editor.org/info/rfc3633>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010, DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>. <https://www.rfc-editor.org/info/rfc6052>.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
April 2011, <https://www.rfc-editor.org/info/rfc6144>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011, DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>. <https://www.rfc-editor.org/info/rfc6147>.
skipping to change at page 32, line 15 skipping to change at page 32, line 40
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, Using "Bump-in-the-Host" (BIH)", RFC 6535,
DOI 10.17487/RFC6535, February 2012, DOI 10.17487/RFC6535, February 2012,
<https://www.rfc-editor.org/info/rfc6535>. <https://www.rfc-editor.org/info/rfc6535>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013, RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>. <https://www.rfc-editor.org/info/rfc6877>.
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
"Analysis of Stateful 64 Translation", RFC 6889,
DOI 10.17487/RFC6889, April 2013,
<https://www.rfc-editor.org/info/rfc6889>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013, RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>. <https://www.rfc-editor.org/info/rfc7050>.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225, Port Control Protocol (PCP)", RFC 7225,
DOI 10.17487/RFC7225, May 2014, DOI 10.17487/RFC7225, May 2014,
<https://www.rfc-editor.org/info/rfc7225>. <https://www.rfc-editor.org/info/rfc7225>.
skipping to change at page 32, line 43 skipping to change at page 33, line 28
[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>.
13.2. Informative References 14.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,
skipping to change at page 33, line 28 skipping to change at page 34, line 11
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-12 (work in
progress), June 2018. progress), June 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-07
(work in progress), August 2018. (work in progress), August 2018.
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
Deployment Options and Experience", RFC 7269,
DOI 10.17487/RFC7269, June 2014,
<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>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
 End of changes. 53 change blocks. 
107 lines changed or deleted 147 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/