draft-ietf-v6ops-nat64-deployment-00.txt   draft-ietf-v6ops-nat64-deployment-01.txt 
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational July 2, 2018 Intended status: Informational August 13, 2018
Expires: January 3, 2019 Expires: February 14, 2019
NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks
draft-ietf-v6ops-nat64-deployment-00 draft-ietf-v6ops-nat64-deployment-01
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 January 3, 2019. This Internet-Draft will expire on February 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 47
5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23 5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23
6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27
11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 30 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 30
12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . 31 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 33 13.2. Informative References . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation, NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation,
which allows IPv6-only hosts to contact IPv4 servers using unicast which allows IPv6-only hosts to contact IPv4 servers using unicast
UDP, TCP or ICMP, by means of a single or a set of IPv4 public UDP, TCP or ICMP, by means of a single or a set of IPv4 public
addresses assigned to the translator, to be shared by the IPv6-only addresses assigned to the translator, to be shared by the IPv6-only
clients. clients.
skipping to change at page 3, line 28 skipping to change at page 3, line 28
DNS64 ([RFC6147]), is in charge of the synthesis of AAAA records from DNS64 ([RFC6147]), is in charge of the synthesis of AAAA records from
the A records, avoiding changes in both, the IPv6-only hosts and the the A records, avoiding changes in both, the IPv6-only hosts and the
IPv4-only server, so they can use a NAT64. IPv4-only server, so they can use a NAT64.
However, the use of NAT64 and/or DNS64 present three issues: However, the use of NAT64 and/or DNS64 present three issues:
a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is
designed to detect such modifications, DNS64 ([RFC6147]) can designed to detect such modifications, DNS64 ([RFC6147]) can
potentially break DNSSEC, depending on a number of factors, such potentially break DNSSEC, depending on a number of factors, such
as the location of the DNS64 function (at a DNS server or as the location of the DNS64 function (at a DNS server or
validator, at the end host, ...), how as been configured, if the validator, at the end host, ...), how it has been configured, if
end-hosts is validating, etc. the end-hosts is validating, etc.
b. Because the need of using DNS64 ([RFC6147]), there is a major b. Because the need of using DNS64 ([RFC6147]), there is a major
issue for NAT64 ([RFC6146]), as doesn't work when literal issue for NAT64 ([RFC6146]), as doesn't work when literal
addresses or non-IPv6 compliant APIs are being used. addresses or non-IPv6 compliant APIs are being used.
c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or
applications located within a network which are connected to a applications located within a network which are connected to a
service provider IPv6-only access. service provider IPv6-only access.
The same issues are true if part of an enterprise or similar network, The same issues are true if part of an enterprise or similar network,
skipping to change at page 6, line 41 skipping to change at page 6, line 41
+----------+ | +----------+ +----------+ | +----------+
| | | | | | | | | |
| IPv6 +-------------+--------------+ IPv4 | | IPv6 +-------------+--------------+ IPv4 |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
Figure 3: NAT64 and DNS64 in external provider Figure 3: NAT64 and DNS64 in external provider
One more equivalent scenario will be if the service provider offers One more equivalent scenario will be if the service provider offers
the NAT64 only, and the DNS64 function is from an external provider the NAT64 only, and the DNS64 function is from an external provider
with or without a specific agreement among them. This is an scenario with or without a specific agreement among them. This is a scenario
already feasible today, as several "global" service providers provide already feasible today, as several "global" service providers provide
free DNS64 services and users often configure manually their DNS. free DNS64 services and users often configure manually their DNS.
This will only work if both the NAT64 and the DNS64 are using the This will only work if both the NAT64 and the DNS64 are using the
same WKP (Well-Known Prefix) or NSP (Network-Specific Prefix). All same WKP (Well-Known Prefix) or NSP (Network-Specific Prefix). All
the considerations in the previous paragraphs of this section are the the considerations in the previous paragraphs of this section are the
same for this sub-case. same for this sub-case.
Of course, if the external DNS64 is agreed with the service provider, Of course, if the external DNS64 is agreed with the service provider,
then we are in the same case as in the previous ones already depicted then we are in the same case as in the previous ones already depicted
in this scenario. in this scenario.
skipping to change at page 8, line 18 skipping to change at page 8, line 18
the end-user device applications can access IPv4-only end-networks/ the end-user device applications can access IPv4-only end-networks/
applications, despite those applications or devices use literal IPv4 applications, despite those applications or devices use literal IPv4
addresses or non-IPv6 compliant APIs. addresses or non-IPv6 compliant APIs.
In addition to that, in the same example of the cellular network In addition to that, in the same example of the cellular network
above, if the User Equipment (UE) provides tethering, other devices above, if the User Equipment (UE) provides tethering, other devices
behind it will be presented with a traditional NAT44, in addition to behind it will be presented with a traditional NAT44, in addition to
the native IPv6 support, so clearly it allows IPv4-only hosts inside the native IPv6 support, so clearly it allows IPv4-only hosts inside
the IPv6-only access network. the IPv6-only access network.
Furthermore, as indicated in [RFC6877] (464XLAT), can be used in Furthermore, as indicated in [RFC6877], 464XLAT can be used in
broadband IPv6 network architectures, by implementing the CLAT broadband IPv6 network architectures, by implementing the CLAT
functionality at the CE. functionality at the CE.
In order to understand all the communication possibilities, let's In order to understand all the communication possibilities, let's
assume the following representation of two dual-stack peers: assume the following representation of two dual-stack peers:
+-------+ .-----. .-----. +-------+ .-----. .-----.
| | / \ / \ | | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only ) / Local \ | SOHO +--( only )---( NAT64 )---( only )
skipping to change at page 15, line 18 skipping to change at page 15, line 18
the previous sections, by the Figure number. The possible values the previous sections, by the Figure number. The possible values
are: are:
- Scenario "bad" for that item. - Scenario "bad" for that item.
+ Scenario "good" for that item. + Scenario "good" for that item.
Needs to be noted that in some cases "countermeasures", alternative Needs to be noted that in some cases "countermeasures", alternative
or special configurations, may be available for the items designated or special configurations, may be available for the items designated
as "bad", so this comparison is making a generic case, as a quick as "bad", so this comparison is making a generic case, as a quick
comparison guide. In some cases, a "bad" idem is not necessarily a comparison guide. In some cases, a "bad" item is not necessarily a
negative aspect, all it depends on the specific needs/characteristics negative aspect, all it depends on the specific needs/characteristics
of the network where the deployment will take place. For instance, of the network where the deployment will take place. For instance,
in a network which has only IPv6-only hosts and apps using only DNS in a network which has only IPv6-only hosts and apps using only DNS
and IPv6-compliant APIs, there is no impact using only NAT64 and and IPv6-compliant APIs, there is no impact using only NAT64 and
DNS64, but if the hosts may validate DNSSEC, that item is still DNS64, but if the hosts may validate DNSSEC, that item is still
relevant. 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 |
+----------------+---+---+---+---+---+---+---+---+---+----+----+----+ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+
skipping to change at page 16, line 26 skipping to change at page 16, line 26
If a device connected to an IPv6-only WAN queries for a domain name If a device connected to an IPv6-only WAN queries for a domain name
in a signed zone, by means of a recursive name server that supports in a signed zone, by means of a recursive name server that supports
DNS64, and the result is a synthesized AAAA record, and the recursive DNS64, and the result is a synthesized AAAA record, and the recursive
name server is configured to perform DNSSEC validation and has a name server is configured to perform DNSSEC validation and has a
valid chain of trust to the zone in question, it will valid chain of trust to the zone in question, it will
cryptographically validate the negative response from the cryptographically validate the negative response from the
authoritative name server. This is the expected DNS64 behavior: The authoritative name server. This is the expected DNS64 behavior: The
recursive name server actually lies to the client device. However, recursive name server actually lies to the client device. However,
in most of the cases, the client will not notice it, because in most of the cases, the client will not notice it, because
generally, they don't perform validation themselves an instead, rely generally, they don't perform validation themselves and instead, rely
on the recursive name servers. on the recursive name servers.
A validating DNS64 resolver in fact, increase the confidence on the A validating DNS64 resolver in fact, increase the confidence on the
synthetic AAAA, as it has validated that a non-synthetic AAAA for synthetic AAAA, as it has validated that a non-synthetic AAAA for
sure, doesn't exists. However, if the client device is sure, doesn't exists. However, if the client device is
NAT64-oblivious (most common case) and performs DNSSEC validation on NAT64-oblivious (most common case) and performs DNSSEC validation on
the AAAA record, it will fail as it is a synthesized record. the AAAA record, it will fail as it is a synthesized record.
The best possible scenario from DNSSEC point of view is when the The best possible scenario from DNSSEC point of view is when the
client requests the DNS64 server to perform the DNSSEC validation (by client requests the DNS64 server to perform the DNSSEC validation (by
skipping to change at page 24, line 4 skipping to change at page 24, line 4
supported by the operator), in order to fully support the actual user supported by the operator), in order to fully support the actual user
needs (IPv4-only devices and applications, usage of literals and old needs (IPv4-only devices and applications, usage of literals and old
APIs), they SHOULD consider the 464XLAT scenario and in that case, APIs), they SHOULD consider the 464XLAT scenario and in that case,
MUST support the customer-side translator (CLAT). MUST support the customer-side translator (CLAT).
If the operator offers DNS services, in order to increase performance If the operator offers DNS services, in order to increase performance
by reducing the double translation for all the IPv4 traffic, they MAY by reducing the double translation for all the IPv4 traffic, they MAY
support DNS64 and avoid, as much as possible, breaking DNSSEC. In support DNS64 and avoid, as much as possible, breaking DNSSEC. In
this case, if the DNS service is offering DNSSEC validation, then it this case, if the DNS service is offering DNSSEC validation, then it
MUST be in such way that it is aware of the DNS64. This is MUST be in such way that it is aware of the DNS64. This is
considered de simpler and safer approach, and MAY be combined as well considered the simpler and safer approach, and MAY be combined as
with the other possible solutions described in this document: well with the other possible solutions described in this document:
o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2).
o Devices running CLAT SHOULD follow the indications in o Devices running CLAT SHOULD follow the indications in
Section 4.1.3 (Stub validator). However, this may be out of the Section 4.1.3 (Stub validator). However, this may be out of the
control of the operator. control of the operator.
o CEs SHOULD include a DNS proxy and validator (Section 4.1.4). o CEs SHOULD include a DNS proxy and validator (Section 4.1.4).
o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4 o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4
skipping to change at page 30, line 42 skipping to change at page 30, line 42
Figure 19: CE setup with bridged CLAT without DNS64 Figure 19: CE setup with bridged CLAT without DNS64
It should be avoided that several routers (i.e., the operator It should be avoided that several routers (i.e., the operator
provided CE and a downstream user provided router) enable provided CE and a downstream user provided router) enable
simultaneously routing and/or CLAT, in order to avoid multiple NAT44 simultaneously routing and/or CLAT, in order to avoid multiple NAT44
and NAT46 levels, as well as ensuring the correct operation of and NAT46 levels, as well as ensuring the correct operation of
multiple IPv6 subnets, so it is suggested to use HNCP ([RFC8375]). multiple IPv6 subnets, so it is suggested to use 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 draft-ietf-v6ops-transition-ipv4aas ... simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas].
TBD.
11. ANNEX B: CLAT Implementation 11. ANNEX B: CLAT Implementation
TBD.
A CLAT CE implementation basically requires support of [RFC7915] for A CLAT CE implementation basically requires support of [RFC7915] for
the NAT46 functionality, [RFC7050] for the PLAT prefix discovery the NAT46 functionality, [RFC7050] for the PLAT prefix discovery
(and/or [RFC7225] for PCP), and if stateless NAT46 is supported, (and/or [RFC7225] for PCP), and if stateless NAT46 is supported,
mechanisms to ensure that multiple /64 are available, such as mechanisms to ensure that multiple /64 are available, such as
DHCPv6-PD [RFC3633]. DHCPv6-PD [RFC3633].
There are several OpenSource implementations of CLAT, such as: There are several OpenSource implementations of CLAT, such as:
Android: https://github.com/ddrown/android_external_android-clat. Android: https://github.com/ddrown/android_external_android-clat.
Linux: https://github.com/toreanderson/clatd. Linux: https://github.com/toreanderson/clatd.
OpenWRT: https://github.com/openwrt- OpenWRT: https://github.com/openwrt-
routing/packages/blob/master/nat46/files/464xlat.sh. routing/packages/blob/master/nat46/files/464xlat.sh.
VPP: https://git.fd.io/vpp/tree/src/plugins/nat. VPP: https://git.fd.io/vpp/tree/src/plugins/nat.
12. ANNEX C: Benchmarking 12. ANNEX C: Benchmarking
TBD.
Several documents provide references to benchmarking, for example in Several documents provide references to benchmarking, for example in
the case of DNS64, [DNS64-Benchm]. the case of DNS64, [DNS64-Benchm].
13. References 13. References
13.1. Normative References 13.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,
skipping to change at page 33, line 14 skipping to change at page 33, line 7
13.2. Informative References 13.2. Informative References
[About-DNS64] [About-DNS64]
J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016,
<https://blog.apnic.net/2016/06/09/ <https://blog.apnic.net/2016/06/09/
lets-talk-ipv6-dns64-dnssec/>. lets-talk-ipv6-dns64-dnssec/>.
[DNS64-Benchm] [DNS64-Benchm]
G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 G. Lencse and Y. Kadobayashi, "Benchmarking DNS64
Implementations: Theory and Practice", September 2018. Implementations: Theory and Practice", Computer
Communications (Elsevier), vol. 127, no. 1, pp. 61-74,
DOI 10.1016/j.comcom.2018.05.005, September 2018.
[I-D.huitema-quic-dnsoquic] [I-D.huitema-quic-dnsoquic]
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
Iyengar, "Specification of DNS over Dedicated QUIC Iyengar, "Specification of DNS over Dedicated QUIC
Connections", draft-huitema-quic-dnsoquic-05 (work in Connections", draft-huitema-quic-dnsoquic-05 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-doh-dns-over-https] [I-D.ietf-doh-dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-12 (work in (DoH)", draft-ietf-doh-dns-over-https-12 (work in
progress), June 2018. progress), June 2018.
[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-07
(work in progress), August 2018.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
[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 G. Lencse 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
stateful NAT64", September 2018. stateful NAT64", Computers & Security (Elsevier), vol. 77,
no. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August
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. 16 change blocks. 
21 lines changed or deleted 26 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/