draft-ietf-v6ops-nat64-deployment-03.txt   draft-ietf-v6ops-nat64-deployment-04.txt 
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational October 10, 2018 Intended status: Informational April 2, 2019
Expires: April 13, 2019 Expires: October 4, 2019
NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks
draft-ietf-v6ops-nat64-deployment-03 draft-ietf-v6ops-nat64-deployment-04
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 April 13, 2019. This Internet-Draft will expire on October 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 38 skipping to change at page 2, line 38
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 . . . . . . . . . . . 21 4.4. Manual Configuration of Foreign DNS . . . . . . . . . . . 21
4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Split DNS . . . . . . . . . . . . . . . . . . . . . . . . 21 4.6. Split DNS . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 22 4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 22
4.8. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22 4.8. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22
4.9. IPv4-only Hosts or Applications . . . . . . . . . . . . . 23 4.9. IPv4-only Hosts or Applications . . . . . . . . . . . . . 23
4.10. CLAT Translation Considerations . . . . . . . . . . . . . 23 4.10. CLAT Translation Considerations . . . . . . . . . . . . . 23
5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 23 4.11. EAMT Considerations . . . . . . . . . . . . . . . . . . . 23
6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 26 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 24
6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 28 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 29
11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 32 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 32
12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 32 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 33
13. ANNEX D: Changes from -00 and -01 . . . . . . . . . . . . . . 32 13. ANNEX D: Changes from -00 to -01 . . . . . . . . . . . . . . 33
14. ANNEX D: Changes from -01 and -02 . . . . . . . . . . . . . . 32 14. ANNEX E: Changes from -01 to -02 . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 15. ANNEX F: Changes from -02 to -03 . . . . . . . . . . . . . . 33
15.1. Normative References . . . . . . . . . . . . . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 16.2. Informative References . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation
mechanism, which allows IPv6-only hosts to communicate with IPv4-only mechanism, which allows IPv6-only hosts to communicate with IPv4-only
servers using unicast UDP, TCP or ICMP, by means of IPv4 public servers using unicast UDP, TCP or ICMP, by means of IPv4 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
skipping to change at page 18, line 20 skipping to change at page 18, line 20
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 Router Other alternatives may be available in the future, such as Router
Advertising ([I-D.pref64folks-6man-ra-pref64]) or DHCPv6 options. Advertising ([I-D.ietf-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, successfully obtain it. This is ways to configure the NAT64 prefix, successfully obtain it. This is
also convenient even if DNS64 is being used. also convenient even if DNS64 is being used.
4.1.2. DNSSEC validator aware of DNS64 4.1.2. DNSSEC validator aware of DNS64
In general, DNS servers with DNS64 function, by default, will not In general, 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
skipping to change at page 18, line 44 skipping to change at page 18, line 44
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], [RFC7225], may query the network for a NAT64 prefix ([RFC7050], [RFC7225],
[I-D.pref64folks-6man-ra-pref64] or other methods) in order to [I-D.ietf-6man-ra-pref64] or other methods) in order to synthesize
synthesize the AAAA ([RFC6052]). This allow the client device to the AAAA ([RFC6052]). This allow the client device to avoid using
avoid using the CLAT and still use NAT64 even with DNSSEC. 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), unless the client is able to present (scenarios without 464XLAT), unless the client is able to
locally perform 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.
skipping to change at page 21, line 38 skipping to change at page 21, line 38
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 disallow any access to IPv4-only networks, and will not will disallow any access to IPv4-only networks, and will not
guarantee DNSSEC, 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 ([RFC8484]) or DNS over QUIC ([I-D.huitema-quic-dnsoquic]), as they
([I-D.huitema-quic-dnsoquic]), as they may provide different results may provide different results to the same query, it must be expected
to the same query, it must be expected equivalent effects as equivalent effects as described in Section 4.4.
described in Section 4.4.
4.6. Split DNS 4.6. Split DNS
As already indicated in precedent sections, the successful use of the As already indicated in precedent sections, the successful use of the
DNS64 is not guaranteed when networks or hosts can use "split-DNS" DNS64 is not guaranteed when networks or hosts can use "split-DNS"
(also called Split Horizon), private DNS. Section 4. of [RFC6950], (also called Split Horizon), private DNS. Section 4. of [RFC6950],
analyses this case. This a very common situation when using VPNs. analyses this case. This a very common situation when using VPNs.
4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP)
skipping to change at page 23, line 29 skipping to change at page 23, line 29
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]), or able to obtain a shorter prefix by means of DHCPv6-PD ([RFC8415]), or
other alternatives, so the CE can use a specific /64 for the other alternatives, so the CE can use a specific /64 for the
translation. This is also possible when broadband is provided by a translation. This is also possible when broadband is provided by a
cellular access. cellular access.
The above recommendation is often not possible for cellular networks, The above recommendation is often not possible for cellular networks,
when connecting smartphones (as UEs), as generally they don't use when connecting smartphones (as UEs), as generally they don't use
DHCPv6-PD ([RFC3633]) an instead a single /64 is provided for each DHCPv6-PD ([RFC8415]) an instead a single /64 is provided for each
PDP context and use /64 prefix sharing ([RFC6877]). So, in this PDP context and use /64 prefix sharing ([RFC6877]). So, in this
case, the UEs typically have a build-in CLAT client, which is doing a case, the UEs typically have a build-in CLAT client, which is doing a
stateful NAT44 before the stateless NAT46. stateful NAT44 before the stateless NAT46.
4.11. EAMT Considerations
Explicit Address Mappings for Stateless IP/ICMP Translation [RFC7757]
provides a way to configure explicit mappings between IPv4 and IPv6
prefixes of any length. When this is used, for example in a CLAT, it
may provide a simple mechanism in order to avoid traffic flows
between IPv4-only nodes or applications and dual-stack destinations
to be translated twice (NAT46 and NAT64), by creating mapping entries
with the GUA of the IPv6-reachable destination. This optimization of
the NAT64 usage is very useful in many scenarios, including CDNs and
caches, as described in [I-D.palet-v6ops-464xlat-opt-cdn-caches].
5. Summary of Deployment Recommendations for NAT64/464XLAT 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,
skipping to change at page 25, line 29 skipping to change at page 25, line 42
Similar considerations need to be taken regarding the usage of a Similar considerations need to be taken regarding the usage of a
NAT64 Well-Known-Prefix (WKP) vs Network-Specific Prefix (NSP) NAT64 Well-Known-Prefix (WKP) vs Network-Specific Prefix (NSP)
(Section 4.7), in the sense of, if using DNS64, they must match and, (Section 4.7), in the sense of, if using DNS64, they must match and,
if the user can change the DNS configuration, they will, most 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 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 not a DNS64, the network will keep working of other means of learning
the NAT64 are available. the NAT64 are available.
As described in Section 4.10 in broadband networks, it is recommended As described in Section 4.10 in broadband networks, it is recommended
that CEs supporting CLAT, supports DHCPv6-PD ([RFC3633]), or that CEs supporting CLAT, supports DHCPv6-PD ([RFC8415]), or
alternative means for configuring a shorter prefix, and internally alternative means for configuring a shorter prefix, and internally
reserve one /64 for the stateless NAT46 translation. The operator reserve one /64 for the stateless NAT46 translation. The operator
must ensure that the customers get allocated prefixes shorter than must ensure that the customers get allocated prefixes shorter than
/64 in order to support this optimization. One way or the other, /64 in order to support this optimization. One way or the other,
this is not impacting the performance of the operator network. this is not impacting the performance of the operator network.
Operators may follow Section 7 of [RFC6877] (Deployment Operators may follow Section 7 of [RFC6877] (Deployment
Considerations), for suggestions in order to take advantage of Considerations), for suggestions in order to take advantage of
traffic engineering requirements. traffic engineering requirements.
skipping to change at page 26, line 33 skipping to change at page 26, line 46
avoiding the cases where DNSSEC may be broken. However, this will avoiding the cases where DNSSEC may be broken. However, this will
not solve the issues related to DNS Privacy and Split DNS. not solve the issues related to DNS Privacy and Split DNS.
The only 100% safe solution, which also resolves all the issues, will The only 100% safe solution, which also resolves all the issues, will
be, in addition to having a CLAT, not using a DNS64 but instead be, in addition to having a CLAT, not using a DNS64 but instead
making sure that the hosts have a built-in address synthesis feature. making sure that the hosts have a built-in address synthesis feature.
Operators could manage to use the CLAT, however the built-in address Operators could manage to use the CLAT, however the built-in address
synthesis feature is out of their control, and can only be resolved synthesis feature is out of their control, and can only be resolved
by operating system vendors. by operating system vendors.
Whenever feasible, using EAMT ([RFC7757]) as indicated in
Section 4.11, provides a very relevant optimization, avoiding double-
translations.
6. Deployment of NAT64 in Enterprise Networks 6. Deployment of NAT64 in Enterprise Networks
The recommendations of this document can be used as well in The recommendations of this document can be used as well in
enterprise networks, campus and other similar scenarios (including enterprise networks, campus and other similar scenarios (including
managed end-user networks). managed end-user networks).
This include scenarios where the NAT64 (and/or DNS64) are under the This include scenarios where the NAT64 (and/or DNS64) are under the
control of that network (or can be configured manually according to control of that network (or can be configured manually according to
that network specific requirements), and for whatever reasons, there that network specific requirements), and for whatever reasons, there
is a need to provide "IPv6-only access" to any part of that network is a need to provide "IPv6-only access" to any part of that network
skipping to change at page 29, line 44 skipping to change at page 30, line 30
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 Router Advertising future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or
([I-D.pref64folks-6man-ra-pref64]) or DHCPv6 options. 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, [RFC8415], need to be set aside for that translation. Otherwise,
the CLAT is forced to perform an intermediate stateful NAT44 the CLAT is forced to perform an intermediate stateful NAT44
before the a stateless NAT46, as described in Section 4.10. before the a stateless NAT46, as described in Section 4.10.
A more detailed configuration approach is described in A more detailed configuration approach is described in
[I-D.ietf-v6ops-transition-ipv4aas]. [I-D.ietf-v6ops-transition-ipv4aas].
The operator network needs to ensure that the correct responses are The operator network needs to ensure that the correct responses are
provided for the discovery of the PLAT prefix, as well as it is provided for the discovery of the PLAT prefix, 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
skipping to change at page 32, line 16 skipping to change at page 33, line 7
In addition to the regular set of features for a CE, a CLAT CE In addition to the regular set of features for a CE, a CLAT CE
implementation requires support of: implementation requires support of:
o [RFC7915], for the NAT46 functionality. o [RFC7915], for the NAT46 functionality.
o [RFC7050], for the PLAT prefix discovery. o [RFC7050], for the PLAT prefix discovery.
o [RFC7225], for the PLAT prefix discovery if PCP is supported. o [RFC7225], for the PLAT prefix discovery if PCP is supported.
o [I-D.pref64folks-6man-ra-pref64], for the PLAT prefix discovery by o [I-D.ietf-6man-ra-pref64], for the PLAT prefix discovery by means
means of Router Advertising. of Router Advertising.
o If stateless NAT46 is supported, a mechanism to ensure that o If stateless NAT46 is supported, a mechanism to ensure that
multiple /64 are available, such as DHCPv6-PD [RFC3633]. multiple /64 are available, such as DHCPv6-PD [RFC8415].
There are several OpenSource implementations of CLAT, such as: There are several OpenSource implementations of CLAT, such as:
o Android: https://github.com/ddrown/android_external_android-clat. o Android: https://github.com/ddrown/android_external_android-clat.
o Linux: https://github.com/toreanderson/clatd. o Linux: https://github.com/toreanderson/clatd.
o OpenWRT: https://github.com/openwrt- o OpenWRT: https://github.com/openwrt-
routing/packages/blob/master/nat46/files/464xlat.sh. routing/packages/blob/master/nat46/files/464xlat.sh.
o VPP: https://git.fd.io/vpp/tree/src/plugins/nat. o VPP: https://git.fd.io/vpp/tree/src/plugins/nat.
12. ANNEX C: Benchmarking 12. ANNEX C: Benchmarking
Several documents provide references to benchmarking, for example in 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 to -01
Section to be removed for WGLC. Significant updates are: Section to be removed after WGLC. Significant updates are:
1. Text changes across all the document. 1. Text changes across all the document.
14. ANNEX D: Changes from -01 and -02 14. ANNEX E: Changes from -01 to -02
Section to be removed for WGLC. Significant updates are: Section to be removed after WGLC. Significant updates are:
1. Added references to new cited documents. 1. Added references to new cited documents.
2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only 2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only
LANs w/o DNS64. LANs w/o DNS64.
3. Overall review and editorial changes. 3. Overall review and editorial changes.
15. References 15. ANNEX F: Changes from -02 to -03
15.1. Normative References Section to be removed after WGLC. Significant updates are:
1. Added text related to EAMT considerations.
16. References
16.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>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<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 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
April 2011, <https://www.rfc-editor.org/info/rfc6144>. April 2011, <https://www.rfc-editor.org/info/rfc6144>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
skipping to change at page 34, line 25 skipping to change at page 35, line 15
[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>.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
Mappings for Stateless IP/ICMP Translation", RFC 7757,
DOI 10.17487/RFC7757, February 2016,
<https://www.rfc-editor.org/info/rfc7757>.
[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 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
skipping to change at page 34, line 47 skipping to change at page 35, line 42
[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>.
15.2. Informative References [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
16.2. Informative References
[About-DNS64] [About-DNS64]
J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, APNIC Blog, "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 "Benchmarking DNS64 Implementations: Theory and Practice",
Implementations: Theory and Practice", Computer Computer Communications (Elsevier), vol. 127, no. 1,
Communications (Elsevier), vol. 127, no. 1, pp. 61-74, pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September
DOI 10.1016/j.comcom.2018.05.005, September 2018. 2018.
[I-D.bp-v6ops-ipv6-ready-dns-dnssec] [I-D.bp-v6ops-ipv6-ready-dns-dnssec]
Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC
Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00 Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00
(work in progress), October 2018. (work in progress), October 2018.
[I-D.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-06 (work in
progress), June 2018. progress), March 2019.
[I-D.ietf-doh-dns-over-https] [I-D.ietf-6man-ra-pref64]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS Colitti, L., Kline, E., and J. Linkova, "Discovering
(DoH)", draft-ietf-doh-dns-over-https-14 (work in PREF64 in Router Advertisements", draft-ietf-6man-ra-
progress), August 2018. pref64-00 (work in progress), March 2019.
[I-D.ietf-v6ops-transition-ipv4aas] [I-D.ietf-v6ops-transition-ipv4aas]
Palet, J., Liu, H., and M. Kawashima, "Requirements for Palet, J., Liu, H., and M. Kawashima, "Requirements for
IPv6 Customer Edge Routers to Support IPv4 Connectivity IPv6 Customer Edge Routers to Support IPv4 Connectivity
as-a-Service", draft-ietf-v6ops-transition-ipv4aas-09 as-a-Service", draft-ietf-v6ops-transition-ipv4aas-15
(work in progress), October 2018. (work in progress), January 2019.
[I-D.pref64folks-6man-ra-pref64] [I-D.palet-v6ops-464xlat-opt-cdn-caches]
Colitti, L., Kline, E., and J. Linkova, "Discovering Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/
PREF64 in Router Advertisements", draft-pref64folks-6man- Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work
ra-pref64-02 (work in progress), October 2018. in progress), March 2019.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in "Architectural Considerations on Application Features in
the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
<https://www.rfc-editor.org/info/rfc6950>. <https://www.rfc-editor.org/info/rfc6950>.
[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>.
skipping to change at page 36, line 17 skipping to change at page 37, line 27
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>.
[RIPE-690] [RIPE-690]
RIPE, "Best Current Operational Practice for Operators: RIPE, "Best Current Operational Practice for Operators:
IPv6 prefix assignment for end-users - persistent vs non- IPv6 prefix assignment for end-users - persistent vs non-
persistent, and what size to choose", October 2017, persistent, and what size to choose", October 2017,
<https://www.ripe.net/publications/docs/ripe-690>. <https://www.ripe.net/publications/docs/ripe-690>.
[Threat-DNS64] [Threat-DNS64]
G. Lencse and Y. Kadobayashi, "Methodology for the "Methodology for the identification of potential security
identification of potential security issues of different issues of different IPv6 transition technologies: Threat
IPv6 transition technologies: Threat analysis of DNS64 and analysis of DNS64 and stateful NAT64", Computers &
stateful NAT64", Computers & Security (Elsevier), vol. 77, Security (Elsevier), vol. 77, no. 1, pp. 397-411,
no. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August DOI 10.1016/j.cose.2018.04.012, August 2018.
2018.
Author's Address Author's Address
Jordi Palet Martinez Jordi Palet Martinez
The IPv6 Company The IPv6 Company
Molino de la Navata, 75 Molino de la Navata, 75
La Navata - Galapagar, Madrid 28420 La Navata - Galapagar, Madrid 28420
Spain Spain
Email: jordi.palet@theipv6company.com Email: jordi.palet@theipv6company.com
 End of changes. 35 change blocks. 
67 lines changed or deleted 99 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/