draft-ietf-v6ops-nat64-deployment-05.txt   draft-ietf-v6ops-nat64-deployment-06.txt 
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational April 19, 2019 Intended status: Informational May 4, 2019
Expires: October 21, 2019 Expires: November 5, 2019
Additional NAT64/464XLAT Deployment Guidelines in Operator and Additional NAT64/464XLAT Deployment Guidelines in Operator and
Enterprise Networks Enterprise Networks
draft-ietf-v6ops-nat64-deployment-05 draft-ietf-v6ops-nat64-deployment-06
Abstract Abstract
This document describes how NAT64 (including 464XLAT) can be deployed This document describes how NAT64 (including 464XLAT) can be deployed
in an IPv6 network, whether cellular ISP, broadband ISP, or in an IPv6 network, whether cellular ISP, broadband ISP, or
enterprise, and possible optimizations. The document also discusses enterprise, and possible optimizations. The document also discusses
issues to be considered when having IPv6-only connectivity, issues to be considered when having IPv6-only connectivity,
regarding: a) DNS64, b) applications or devices that use literal IPv4 regarding: a) DNS64, b) applications or devices that use literal IPv4
addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or
applications. applications.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 21, 2019. This Internet-Draft will expire on November 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 22 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 22
4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 22 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 22
4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 23 4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Manual Configuration of Foreign DNS . . . . . . . . . 24 4.4.1. Manual Configuration of Foreign DNS . . . . . . . . . 24
4.4.2. DNS Privacy . . . . . . . . . . . . . . . . . . . . . 24 4.4.2. DNS Privacy . . . . . . . . . . . . . . . . . . . . . 24
4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 25 4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 25
4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 25 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 25
4.6. IPv4 literals and old APIs . . . . . . . . . . . . . . . 25 4.6. IPv4 literals and old APIs . . . . . . . . . . . . . . . 25
4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 26 4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 26
4.8. CLAT Translation Considerations . . . . . . . . . . . . . 26 4.8. CLAT Translation Considerations . . . . . . . . . . . . . 26
4.9. EAMT Considerations . . . . . . . . . . . . . . . . . . . 27 4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 27
4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 27
5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 27 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 27
6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 30 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 32 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 32
11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 36 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 36
12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 36 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 37
13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 36 13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 37
14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 37 14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 37
15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 37 15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 38
16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 37 16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 38
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 17. ANNEX H: Changes from -05 to -06 . . . . . . . . . . . . . . 38
17.1. Normative References . . . . . . . . . . . . . . . . . . 37 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
17.2. Informative References . . . . . . . . . . . . . . . . . 39 18.1. Normative References . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 18.2. Informative References . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4
translation mechanism, which allows IPv6-only hosts to communicate translation mechanism, which allows IPv6-only hosts to communicate
with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of
IPv4 public addresses sharing, among multiple IPv6-only hosts. IPv4 public addresses sharing, among multiple IPv6-only hosts.
Unless otherwise stated, references in the rest of this document to Unless otherwise stated, references in the rest of this document to
NAT64 (function) should be interpreted as to Stateful NAT64. NAT64 (function) should be interpreted as to Stateful NAT64.
skipping to change at page 7, line 20 skipping to change at page 7, line 20
| |
| |
+----------+ +----+-----+ +----------+ +----+-----+
| | | | | | | |
| IPv6 +--------+ DNS64 + | IPv6 +--------+ DNS64 +
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
Figure 2: NAT64 in external service provider Figure 2: NAT64 in external service provider
As well, is equivalent to the scenario where the outsourcing This is equivalent to the scenario where the outsourcing agreement
agreement with the external provider is to provide both the NAT64 and with the external provider is to provide both the NAT64 and DNS64
DNS64 functions. Once more, all the considerations in the previous functions. Once more, all the considerations in the previous
paragraphs of this section are the same for this sub-case. paragraphs of this section are the same for this sub-case.
+----------+ +----------+ +----------+ +----------+
| extNAT64 | | | | extNAT64 | | |
| + +-------+ IPv4 | | + +-------+ IPv4 |
| extDNS64 | | | | extDNS64 | | |
+----+-----+ +----------+ +----+-----+ +----------+
| |
+----------+ | +----------+ |
| | | | | |
skipping to change at page 10, line 30 skipping to change at page 10, line 30
The possible communication paths, among the IPv4/IPv6 stacks of both The possible communication paths, among the IPv4/IPv6 stacks of both
peers, in this case, are: peers, in this case, are:
a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among
peers. peers.
b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.
c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements EAMT as indicated by Section 4.9. In principle, it is implements EAM (Explicit Address Mappings) as indicated by
not expected that services are deployed in Internet using Section 4.9. In principle, it is not expected that services are
IPv6-only, unless there is certainty that peers will also be deployed in Internet using IPv6-only, unless there is certainty
IPv6-capable. that peers will also be IPv6-capable.
d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations. d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations.
e. Local-IPv4 to Remote-dual-stack using EAMT optimization: If the e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the
CLAT implements EAMT as indicated by Section 4.9, instead of CLAT implements EAM as indicated by Section 4.9, instead of using
using the path d. above, NAT64 translation is avoided and the the path d. above, NAT64 translation is avoided and the flow will
flow will use IPv6 from the CLAT to the destination. use IPv6 from the CLAT to the destination.
The rest of the figures in this section show different choices for The rest of the figures in this section show different choices for
placing the different elements. placing the different elements.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| IPv6 | | NAT64 | | | | IPv6 | | NAT64 | | |
| + +--------+ + +--------+ IPv4 | | + +--------+ + +--------+ IPv4 |
| CLAT | | DNS64 | | | | CLAT | | DNS64 | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
skipping to change at page 11, line 49 skipping to change at page 11, line 49
| CLAT | | CLAT |
+----------+ +----------+
Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider
3.1.3. Service Provider Offering 464XLAT, without DNS64 3.1.3. Service Provider Offering 464XLAT, without DNS64
The major advantage of this scenario, using 464XLAT without DNS64, is The major advantage of this scenario, using 464XLAT without DNS64, is
that the service provider ensures that DNSSEC is never broken, even that the service provider ensures that DNSSEC is never broken, even
in case the user modifies the DNS configuration. Nevertheless, some in case the user modifies the DNS configuration. Nevertheless, some
CLAT implementations or applications may expose an extra delay, which CLAT implementations or applications may impose an extra delay, which
is inducted by the dual A/AAAA queries (and wait for both responses), is induced by the dual A/AAAA queries (and wait for both responses),
unless Happy Eyeballs v2 (HEv2, [RFC8305]) is also present. unless Happy Eyeballs v2 (HEv2, [RFC8305]) is also present.
A possible variation of this scenario is the case when DNS64 is used A possible variation of this scenario is the case when DNS64 is used
only for the discovery of the NAT64 prefix. The rest of the document only for the discovery of the NAT64 prefix. The rest of the document
is not considering it as a different scenario, because once the is not considering it as a different scenario, because once the
prefix has been discovered, the DNS64 function is not used, so it prefix has been discovered, the DNS64 function is not used, so it
behaves as if the DNS64 synthesis function is not present. behaves as if the DNS64 synthesis function is not present.
In this scenario, as in the previous one, there are no issues related In this scenario, as in the previous one, there are no issues related
to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only
skipping to change at page 13, line 7 skipping to change at page 13, line 7
The possible communication paths, among the IPv4/IPv6 stacks of both The possible communication paths, among the IPv4/IPv6 stacks of both
peers, in this case, are: peers, in this case, are:
a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among
peers. peers.
b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64 b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64
translations. translations.
c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements EAMT as indicated by Section 4.9. In principle, it is implements EAM as indicated by Section 4.9. In principle, it is
not expected that services are deployed in Internet using not expected that services are deployed in Internet using
IPv6-only, unless there is certainty that peers will also be IPv6-only, unless there is certainty that peers will also be
IPv6-capable. IPv6-capable.
d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64
translations. translations.
e. Local-IPv4 to Remote-dual-stack using EAMT optimization: If the e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the
CLAT implements EAMT as indicated by Section 4.9, instead of CLAT implements EAM as indicated by Section 4.9, instead of using
using the path d. above, NAT64 translation is avoided and the the path d. above, NAT64 translation is avoided and the flow will
flow will use IPv6 from the CLAT to the destination. use IPv6 from the CLAT to the destination.
It needs to be noticed that this scenario works while the local It needs to be noticed that this scenario works while the local
hosts/applications are dual-stack (which is the current situation), hosts/applications are dual-stack (which is the current situation),
because the connectivity from a local-IPv6 to a remote-IPv4 is not because the connectivity from a local-IPv6 to a remote-IPv4 is not
possible without an AAAA synthesis. This aspect is important only possible without an AAAA synthesis. This aspect is important only
when in the LANs behind the CLAT there are IPv6-only hosts and they when in the LANs behind the CLAT there are IPv6-only hosts and they
need to communicate with remote IPv4-only hosts. However, it doesn't need to communicate with remote IPv4-only hosts. However, it doesn't
look a sensible approach from an Operating System or application look a sensible approach from an Operating System or application
vendor perspective, to provide IPv6-only support unless, similarly to vendor perspective, to provide IPv6-only support unless, similarly to
case c above, there is certainty of peers supporting IPv6 as well. A case c above, there is certainty of peers supporting IPv6 as well. A
skipping to change at page 17, line 24 skipping to change at page 17, line 24
the previous sections, by the figure number. The possible values the previous sections, by the figure number. The possible values
are: are:
o "-" Scenario "bad" for that criteria. o "-" Scenario "bad" for that criteria.
o "+" Scenario "good" for that criteria. o "+" Scenario "good" for that criteria.
o "*" Scenario "bad" for that criteria, however it is typically o "*" Scenario "bad" for that criteria, however it is typically
resolved, with the support of HEv2 ([RFC8305]). resolved, with the support of HEv2 ([RFC8305]).
In some cases "countermeasures", alternative or special In some cases, "countermeasures", alternative or special
configurations, may be available for the criteria designated as configurations, may be available for the criteria designated as
"bad". So this comparison is considering a generic case, as a quick "bad". So, this comparison is considering a generic case, as a quick
comparison guide. In some cases, a "bad" criteria is not necessarily comparison guide. In some cases, a "bad" criterion is not
a negative aspect, all it depends on the specific needs/ necessarily a negative aspect, all it depends on the specific needs/
characteristics of the network where the deployment will take place. characteristics of the network where the deployment will take place.
For instance, in a network which has only IPv6-only hosts and apps For instance, in a network which has only IPv6-only hosts and apps
using only DNS and IPv6-compliant APIs, there is no impact using only using only DNS and IPv6-compliant APIs, there is no impact using only
NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is
still relevant. still relevant.
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+
| DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + | | DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + |
skipping to change at page 23, line 35 skipping to change at page 23, line 35
will be done at the NAT64. This may break DNSSEC, unless will be done at the NAT64. This may break DNSSEC, unless
measures as described in the precedent sections are taken. measures as described in the precedent sections are taken.
2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will
make use of the CLAT, so two translations are required (NAT46 at make use of the CLAT, so two translations are required (NAT46 at
the CLAT and NAT64 at the PLAT), which adds some overhead in the CLAT and NAT64 at the PLAT), which adds some overhead in
terms of the extra NAT46 translation. However, this avoids the terms of the extra NAT46 translation. However, this avoids the
AAAA synthesis and consequently will never break DNSSEC. AAAA synthesis and consequently will never break DNSSEC.
Note that the extra translation, when DNS64 is not used, takes place Note that the extra translation, when DNS64 is not used, takes place
at the CLAT, which means no extra overhead for the operator. at the CLAT, which means no extra overhead for the operator. It
However, adds potential extra delays to establish the connections, however adds potential extra delays to establish the connections, and
and no perceptible impact for a CE in a broadband network, while it no perceptible impact for a CE in a broadband network, while it may
may have some impact in a battery powered device. This cost for a have some impact in a battery powered device. This cost for a
battery powered device, is possibly comparable to the cost when the battery powered device, is possibly comparable to the cost when the
device is doing a local address synthesis (see Section 7.1 of device is doing a local address synthesis (see Section 7.1 of
[RFC8305]). [RFC8305]).
4.4. Foreign DNS 4.4. Foreign DNS
Clients, devices or applications in a service provider network, may Clients, devices or applications in a service provider network, may
use DNS servers from other networks. This may be the case either if use DNS servers from other networks. This may be the case either if
individual applications use their own DNS server, the Operating individual applications use their own DNS server, the Operating
System itself or even the CE, or combinations of the above. System itself or even the CE, or combinations of the above.
Those "foreign" DNS servers may not support DNS64, which will mean Those "foreign" DNS servers may not support DNS64, which will mean
that those scenarios that require a DNS64 may not work. However, if that those scenarios that require a DNS64 may not work. However, if
a CLAT function is available, the considerations in Section 4.3 will a CLAT function is available, the considerations in Section 4.3 will
apply. apply.
In the case that the foreign DNS supports the DNS64 function, we may In the case that the foreign DNS supports the DNS64 function, we may
be in the situation of providing incorrect configurations parameters, be in the situation of providing incorrect configurations parameters,
for example un-matching WKP or NSP, or a case such the one described for example, un-matching WKP or NSP, or a case such the one described
in Section 3.2.3. in Section 3.2.3.
Having a CLAT function, even if using foreign DNS without a DNS64 Having a CLAT function, even if using foreign DNS without a DNS64
function, ensures that everything will work, so the CLAT must be function, ensures that everything will work, so the CLAT must be
considered as an advantage even against user configuration errors. considered as an advantage even against user configuration errors.
The cost of this, is that all the traffic will use a double The cost of this, is that all the traffic will use a double
translation (NAT46 at the CLAT and NAT64 at the operator network), translation (NAT46 at the CLAT and NAT64 at the operator network),
unless there is support for EAMT (Section 4.9). unless there is support for EAM (Section 4.9).
An exception to that is the case when there is a CLAT function at the An exception to that is the case when there is a CLAT function at the
CE, which is not able to obtain the correct configuration parameters CE, which is not able to obtain the correct configuration parameters
(again, un-matching WKP or NSP). (again, un-matching WKP or NSP).
However, it needs to be reinforced, that if there is not a CLAT However, it needs to be emphasized, that if there is not a CLAT
function (scenarios without 464XLAT), an external DNS without DNS64 function (scenarios without 464XLAT), an external DNS without DNS64
support, will disallow any access to IPv4-only destination networks, support, will disallow any access to IPv4-only destination networks,
and will not guarantee DNSSEC, so will behave as in the and will not guarantee DNSSEC, so will behave as in the
Section 3.2.1. Section 3.2.1.
The causes of "foreign DNS" could be classified in three main The causes of "foreign DNS" could be classified in three main
categories, as depicted in the following sub-sections. categories, as depicted in the following sub-sections.
4.4.1. Manual Configuration of Foreign DNS 4.4.1. Manual Configuration of Foreign DNS
skipping to change at page 25, line 16 skipping to change at page 25, line 16
When networks or hosts use "split-DNS" (also called Split Horizon, When networks or hosts use "split-DNS" (also called Split Horizon,
DNS views or private DNS), the successful use of the DNS64 is not DNS views or private DNS), the successful use of the DNS64 is not
guaranteed. Section 4 of [RFC6950], analyses this case. guaranteed. Section 4 of [RFC6950], analyses this case.
A similar situation may happen in case of VPNs that force all the DNS A similar situation may happen in case of VPNs that force all the DNS
queries through the VPN, ignoring the operator DNS64 function. queries through the VPN, ignoring the operator DNS64 function.
4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP)
[RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), Section 3, Section 3 of [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators),
discusses some considerations which are useful to decide if an discusses some considerations which are useful to decide if an
operator should use the WKP or an NSP. operator should use the WKP or an NSP.
Taking in consideration that discussion and other issues, we can Taking in consideration that discussion and other issues, we can
summarize the possible decision points as: summarize the possible decision points as:
a. The WKP MUST NOT be used to represent non-global IPv4 addresses. a. The WKP MUST NOT be used to represent non-global IPv4 addresses.
If this is required because the network to be translated use non- If this is required because the network to be translated use non-
global addresses, then an NSP is required. global addresses, then an NSP is required.
skipping to change at page 27, line 6 skipping to change at page 27, line 6
translation. This is also possible when broadband is provided by a translation. This is also possible when broadband is provided by a
cellular access. cellular access.
The above recommendation is often not possible for cellular networks, The above recommendation is often not possible for cellular networks,
when connecting smartphones (as UEs), as generally they don't use when connecting smartphones (as UEs), as generally they don't use
DHCPv6-PD ([RFC8415]). Instead, a single /64 is provided for each DHCPv6-PD ([RFC8415]). Instead, a single /64 is provided for each
PDP context and prefix sharing ([RFC6877]) is used. So, in this PDP context and prefix sharing ([RFC6877]) is used. So, in this
case, the UEs typically have a build-in CLAT function which is case, the UEs typically have a build-in CLAT function which is
performing a stateful NAT44 translation before the stateless NAT46. performing a stateful NAT44 translation before the stateless NAT46.
4.9. EAMT Considerations 4.9. EAM Considerations
Explicit Address Mappings for Stateless IP/ICMP Translation Explicit Address Mappings for Stateless IP/ICMP Translation
([RFC7757]) provide a way to configure explicit mappings between IPv4 ([RFC7757]) provide a way to configure explicit mappings between IPv4
and IPv6 prefixes of any length. When this is used, for example in a and IPv6 prefixes of any length. When this is used, for example in a
CLAT function, it may provide a simple mechanism in order to avoid CLAT function, it may provide a simple mechanism in order to avoid
traffic flows between IPv4-only nodes or applications and dual-stack traffic flows between IPv4-only nodes or applications and dual-stack
destinations to be translated twice (NAT46 and NAT64), by creating destinations to be translated twice (NAT46 and NAT64), by creating
mapping entries with the GUA of the IPv6-reachable destination. This mapping entries with the GUA of the IPv6-reachable destination. This
optimization of the NAT64 usage is very useful in many scenarios, optimization of the NAT64 usage is very useful in many scenarios,
including CDNs and caches, as described in including CDNs and caches, as described in
[I-D.palet-v6ops-464xlat-opt-cdn-caches]. [I-D.palet-v6ops-464xlat-opt-cdn-caches].
In addition to that, it may provide as well a way for IPv4-only nodes In addition to that, it may provide as well a way for IPv4-only nodes
or applications to communicate with IPv6-only destinations. or applications to communicate with IPv6-only destinations.
4.10. Incoming Connections
The use of NAT64, in principle, disallows IPv4 incoming connections,
which may be still needed for IPv4-only peer-to-peer applications.
However, there are several alternatives that resolve this issue:
a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are
commonly used by peer-to-peer applications in order to allow
incoming connections with IPv4 NAT. In the case of NAT64, they
work as well.
b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and
IPv6 packets are translated and forwarded. A NAT64 may implement
PCP to allow this service.
c. EAM ([RFC7757]) may also be used in order to configure explicit
mappings for customers that require them. This is used for
example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]).
5. Summary of Deployment Recommendations for NAT64/464XLAT 5. Summary of Deployment Recommendations for NAT64/464XLAT
NAT64/464XLAT has demonstrated to be a valid choice in several NAT64/464XLAT has demonstrated to be a valid choice in several
scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions
of users, offering different choices of deployment, depending on each of users, offering different choices of deployment, depending on each
network case, needs and requirements. Despite that, this document is network case, needs and requirements. Despite that, this document is
not an explicit recommendation for using this choice versus other not an explicit recommendation for using this choice versus other
IPv4aaS transition mechanisms. Instead, this document is a guide IPv4aaS transition mechanisms. Instead, this document is a guide
that facilitates evaluating a possible implementation of that facilitates evaluating a possible implementation of
NAT64/464XLAT and key decision points about specific design NAT64/464XLAT and key decision points about specific design
skipping to change at page 28, line 39 skipping to change at page 29, line 10
the CLAT (Section 4.3). the CLAT (Section 4.3).
If DNS64 is not used, at least one of the alternatives described in If DNS64 is not used, at least one of the alternatives described in
Section 4.1.1, must be followed in order to learn he NAT64 prefix. Section 4.1.1, must be followed in order to learn he NAT64 prefix.
The operator needs to consider that if the DNS configuration can be The operator needs to consider that if the DNS configuration can be
modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most
probably is impossible to avoid, there are chances that instead of probably is impossible to avoid, there are chances that instead of
configuring a DNS64 a foreign non-DNS64 is used. In a scenario with configuring a DNS64 a foreign non-DNS64 is used. In a scenario with
only a NAT64 function IPv4-only remote host will no longer be only a NAT64 function IPv4-only remote host will no longer be
accesible. Instead, it will continue to work in the case of 464XLAT. accessible. Instead, it will continue to work in the case of
464XLAT.
Similar considerations need to be taken regarding the usage of a Similar considerations need to be taken regarding the usage of a
NAT64 WKP vs NSP (Section 4.5), as they must match with the NAT64 WKP vs NSP (Section 4.5), as they must match with the
configuration of the DNS64. In case of using foreign DNS, they may configuration of the DNS64. In case of using foreign DNS, they may
not match. If there is a CLAT and the configured foreign DNS is not not match. If there is a CLAT and the configured foreign DNS is not
a DNS64, the network will keep working only if other means of a DNS64, the network will keep working only if other means of
learning the NAT64 prefix are available. learning the NAT64 prefix are available.
As described in Section 4.8, for broadband networks, the CEs As described in Section 4.8, for broadband networks, the CEs
supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or
skipping to change at page 30, line 15 skipping to change at page 30, line 33
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 function, not using a DNS64 but be, in addition to having a CLAT function, not using a DNS64 but
instead making sure that the hosts have a built-in address synthesis instead making sure that the hosts have a built-in address synthesis
feature. Operators could manage to provide CEs with the CLAT feature. Operators could manage to provide CEs with the CLAT
function, however the built-in address synthesis feature is out of function, however the built-in address synthesis feature is out of
their control. If the synthesis is provided either by the Operating their control. If the synthesis is provided either by the Operating
System (via its DNS resolver API) or by the application (via its own System (via its DNS resolver API) or by the application (via its own
DNS resolver), in such way that the prefix used for the NAT64 DNS resolver), in such way that the prefix used for the NAT64
function is reachable for the host, the problem goes away. function is reachable for the host, the problem goes away.
Whenever feasible, using EAMT ([RFC7757]) as indicated in Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9,
Section 4.9, provides a very relevant optimization, avoiding double- provides a very relevant optimization, avoiding double-translations.
translations.
Applications that require incoming connections, typically already
provide means for that. However, PCP and EAM, as indicated in
Section 4.10, are valid alternatives, even for creating explicit
mappings for customers that require them.
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 function (and DNS64 function, This include scenarios where the NAT64 function (and DNS64 function,
if available) are under the control of that network (or can be if available) are under the control of that network (or can be
configured manually according to that network specific requirements), configured manually according to that network specific requirements),
skipping to change at page 33, line 51 skipping to change at page 34, line 18
of [RFC7225], or other alternatives that may be available in the of [RFC7225], or other alternatives that may be available in the
future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or
DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]). DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]).
2. If the CLAT function allows stateless NAT46 translation, a /64 2. If the CLAT function allows stateless NAT46 translation, a /64
from the pool typically provided to the CE by means of DHCPv6-PD from the pool typically provided to the CE by means of DHCPv6-PD
[RFC8415], need to be set aside for that translation. Otherwise, [RFC8415], need to be set aside for that translation. Otherwise,
the CLAT is forced to perform an intermediate stateful NAT44 the CLAT is forced to perform an intermediate stateful NAT44
before the a stateless NAT46, as described in Section 4.8. before the a stateless NAT46, as described in Section 4.8.
A more detailed configuration approach is described in A more detailed configuration approach is described in [RFC8585].
[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. It is highly provided for the discovery of the PLAT prefix. It is highly
recommended to follow [RIPE-690], in order to ensure that multiple recommended to follow [RIPE-690], in order to ensure that multiple
/64s are available, including the one needed for the NAT46 stateless /64s are available, including the one needed for the NAT46 stateless
translation. translation.
The operator needs to understand other issues, described across this The operator needs to understand other issues, described across this
document, in order to take the relevant decisions. For example, if document, in order to take the relevant decisions. For example, if
several NAT64 functions are needed in the context of scalability/ several NAT64 functions are needed in the context of scalability/
skipping to change at page 34, line 52 skipping to change at page 35, line 30
Figure 18: CE setup with built-in CLAT without DNS64 Figure 18: CE setup with built-in CLAT without DNS64
In this case, the discovery of the PLAT prefix needs to be arranged In this case, the discovery of the PLAT prefix needs to be arranged
as indicated in Section 4.1.1. as indicated in Section 4.1.1.
In this case, the CE doesn't have a built-in CLAT function, or the In this case, the CE doesn't have a built-in CLAT function, or the
customer can choose to setup the IPv6 operator-managed CE in bridge customer can choose to setup the IPv6 operator-managed CE in bridge
mode (and optionally use an external router), or for example, there mode (and optionally use an external router), or for example, there
is an access technology that requires some kind of media converter is an access technology that requires some kind of media converter
(ONT for FTTH, CableModem for DOCSIS, etc.), the complete setup will (ONT for FTTH, Cable-Modem for DOCSIS, etc.), the complete setup will
look as in the next figure. Obviously, there will be some look as in the next figure. Obviously, there will be some
intermediate configuration steps for the bridge, depending on the intermediate configuration steps for the bridge, depending on the
specific access technology/protocols, which should not modify the specific access technology/protocols, which should not modify the
steps already described in the previous cases for the CLAT function steps already described in the previous cases for the CLAT function
configuration. configuration.
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
| Res./ | / IPv6- \ .-----. / IPv4- \ | Res./ | / IPv6- \ .-----. / IPv4- \
| SOHO +--( only )--( NAT64 )--( only ) | SOHO +--( only )--( NAT64 )--( only )
skipping to change at page 35, line 48 skipping to change at page 36, line 43
Figure 19: CE setup with bridged CLAT without DNS64 Figure 19: CE setup with bridged CLAT without DNS64
It should be avoided that several routers (i.e., the operator It should be avoided that several routers (i.e., the operator
provided CE and a downstream user provided router) enable provided CE and a downstream user provided router) enable
simultaneously routing and/or CLAT, in order to avoid multiple NAT44 simultaneously routing and/or CLAT, in order to avoid multiple NAT44
and NAT46 levels, as well as ensuring the correct operation of and NAT46 levels, as well as ensuring the correct operation of
multiple IPv6 subnets. In those cases, it is suggested the use of multiple IPv6 subnets. In those cases, it is suggested the use of
HNCP ([RFC8375]). HNCP ([RFC8375]).
Note that the procedure described here for the CE setup, can be Note that the procedure described here for the CE setup, can be
simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas]. simplified if the CE follows [RFC8585].
11. ANNEX B: CLAT Implementation 11. ANNEX B: CLAT Implementation
In addition to the regular set of features for a CE, a CLAT CE In addition to the regular set of features for a CE, a CLAT CE
implementation requires support of: implementation requires support of:
o [RFC7915] for the NAT46 function. o [RFC7915] for the NAT46 function.
o [RFC7050] for the PLAT prefix discovery. o [RFC7050] for the PLAT prefix discovery.
skipping to change at page 37, line 20 skipping to change at page 38, line 9
2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only 2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only
LANs w/o DNS64. LANs w/o DNS64.
3. Overall review and editorial changes. 3. Overall review and editorial changes.
15. ANNEX F: Changes from -03 to -04 15. ANNEX F: Changes from -03 to -04
Section to be removed after WGLC. Significant updates are: Section to be removed after WGLC. Significant updates are:
1. Added text related to EAMT considerations. 1. Added text related to EAM considerations.
16. ANNEX G: Changes from -04 to -05 16. ANNEX G: Changes from -04 to -05
Section to be removed after WGLC. Significant updates are: Section to be removed after WGLC. Significant updates are:
1. Added cross references to EAMT section. 1. Added cross references to EAM section.
2. Reworded "foreing DNS section". 2. Reworded "foreing DNS section".
3. Overall editorial review of text, pictures and nits correction. 3. Overall editorial review of text, pictures and nits correction.
17. References 17. ANNEX H: Changes from -05 to -06
17.1. Normative References Section to be removed after WGLC. Significant updates are:
1. Corrected EAMT to EAM.
2. Typos and nits.
3. New considerations regarding incoming connections.
18. References
18.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>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<https://www.rfc-editor.org/info/rfc5625>. <https://www.rfc-editor.org/info/rfc5625>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5766>.
[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 38, line 35 skipping to change at page 39, line 41
[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>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>.
[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 39, line 33 skipping to change at page 40, line 43
[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>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
17.2. Informative References 18.2. Informative References
[About-DNS64] [About-DNS64]
Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016, Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016,
<https://blog.apnic.net/2016/06/09/ <https://blog.apnic.net/2016/06/09/
lets-talk-ipv6-dns64-dnssec/>. lets-talk-ipv6-dns64-dnssec/>.
[DNS64-Benchm] [DNS64-Benchm]
Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64
Implementations: Theory and Practice", Computer Implementations: Theory and Practice", Computer
Communications , vol. 127, no. 1, pp. 61-74, Communications , vol. 127, no. 1, pp. 61-74,
skipping to change at page 40, line 27 skipping to change at page 41, line 40
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
Iyengar, "Specification of DNS over Dedicated QUIC Iyengar, "Specification of DNS over Dedicated QUIC
Connections", draft-huitema-quic-dnsoquic-06 (work in Connections", draft-huitema-quic-dnsoquic-06 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-6man-ra-pref64] [I-D.ietf-6man-ra-pref64]
Colitti, L., Kline, E., and J. Linkova, "Discovering Colitti, L., Kline, E., and J. Linkova, "Discovering
PREF64 in Router Advertisements", draft-ietf-6man-ra- PREF64 in Router Advertisements", draft-ietf-6man-ra-
pref64-00 (work in progress), March 2019. pref64-00 (work in progress), March 2019.
[I-D.ietf-v6ops-transition-ipv4aas]
Palet, J., Liu, H., and M. Kawashima, "Requirements for
IPv6 Customer Edge Routers to Support IPv4 Connectivity
as-a-Service", draft-ietf-v6ops-transition-ipv4aas-15
(work in progress), January 2019.
[I-D.li-intarea-nat64-prefix-dhcp-option] [I-D.li-intarea-nat64-prefix-dhcp-option]
Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet, Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet,
"DHCPv6 Options for Discovery NAT64 Prefixes", draft-li- "DHCPv6 Options for Discovery NAT64 Prefixes", draft-li-
intarea-nat64-prefix-dhcp-option-01 (work in progress), intarea-nat64-prefix-dhcp-option-02 (work in progress),
March 2017. April 2019.
[I-D.lmhp-v6ops-transition-comparison] [I-D.lmhp-v6ops-transition-comparison]
Lencse, G., Palet, J., Howard, L., Patterson, R., and I. Lencse, G., Palet, J., Howard, L., Patterson, R., and I.
Farrer, "Pros and Cons of IPv6 Transition Technologies for Farrer, "Pros and Cons of IPv6 Transition Technologies for
IPv4aaS", draft-lmhp-v6ops-transition-comparison-02 (work IPv4aaS", draft-lmhp-v6ops-transition-comparison-02 (work
in progress), January 2019. in progress), January 2019.
[I-D.palet-v6ops-464xlat-opt-cdn-caches] [I-D.palet-v6ops-464xlat-opt-cdn-caches]
Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/ Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/
Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work
skipping to change at page 41, line 30 skipping to change at page 42, line 35
[RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of [RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of
Solution Proposals for Hosts to Learn NAT64 Prefix", Solution Proposals for Hosts to Learn NAT64 Prefix",
RFC 7051, DOI 10.17487/RFC7051, November 2013, RFC 7051, DOI 10.17487/RFC7051, November 2013,
<https://www.rfc-editor.org/info/rfc7051>. <https://www.rfc-editor.org/info/rfc7051>.
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
Deployment Options and Experience", RFC 7269, Deployment Options and Experience", RFC 7269,
DOI 10.17487/RFC7269, June 2014, DOI 10.17487/RFC7269, June 2014,
<https://www.rfc-editor.org/info/rfc7269>. <https://www.rfc-editor.org/info/rfc7269>.
[RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
IPv6 Data Center Environments", RFC 7755,
DOI 10.17487/RFC7755, February 2016,
<https://www.rfc-editor.org/info/rfc7755>.
[RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP
Translation for IPv6 Internet Data Center Environments
(SIIT-DC): Dual Translation Mode", RFC 7756,
DOI 10.17487/RFC7756, February 2016,
<https://www.rfc-editor.org/info/rfc7756>.
[RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, [RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,
N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,
"An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849,
DOI 10.17487/RFC7849, May 2016, DOI 10.17487/RFC7849, May 2016,
<https://www.rfc-editor.org/info/rfc7849>. <https://www.rfc-editor.org/info/rfc7849>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
skipping to change at page 42, line 5 skipping to change at page 43, line 20
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking
Methodology for IPv6 Transition Technologies", RFC 8219, Methodology for IPv6 Transition Technologies", RFC 8219,
DOI 10.17487/RFC8219, August 2017, DOI 10.17487/RFC8219, August 2017,
<https://www.rfc-editor.org/info/rfc8219>. <https://www.rfc-editor.org/info/rfc8219>.
[RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima,
"Requirements for IPv6 Customer Edge Routers to Support
IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
2019, <https://www.rfc-editor.org/info/rfc8585>.
[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]
Lencse, G. and Y. Kadobayashi, "Methodology for the Lencse, G. and Y. Kadobayashi, "Methodology for the
identification of potential security issues of different identification of potential security issues of different
IPv6 transition technologies: Threat analysis of DNS64 and IPv6 transition technologies: Threat analysis of DNS64 and
 End of changes. 40 change blocks. 
67 lines changed or deleted 133 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/