--- 1/draft-ietf-v6ops-nat64-deployment-00.txt 2018-08-13 16:13:12.809276631 -0700 +++ 2/draft-ietf-v6ops-nat64-deployment-01.txt 2018-08-13 16:13:12.881278383 -0700 @@ -1,18 +1,18 @@ v6ops J. Palet Martinez Internet-Draft The IPv6 Company -Intended status: Informational July 2, 2018 -Expires: January 3, 2019 +Intended status: Informational August 13, 2018 +Expires: February 14, 2019 NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks - draft-ietf-v6ops-nat64-deployment-00 + draft-ietf-v6ops-nat64-deployment-01 Abstract This document describes how NAT64 and 464XLAT can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -82,21 +82,21 @@ 5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 30 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 13.2. Informative References . . . . . . . . . . . . . . . . . 33 + 13.2. Informative References . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation, 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 addresses assigned to the translator, to be shared by the IPv6-only clients. @@ -108,22 +108,22 @@ 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 IPv4-only server, so they can use a NAT64. However, the use of NAT64 and/or DNS64 present three issues: a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is designed to detect such modifications, DNS64 ([RFC6147]) can potentially break DNSSEC, depending on a number of factors, such as the location of the DNS64 function (at a DNS server or - validator, at the end host, ...), how as been configured, if the - end-hosts is validating, etc. + validator, at the end host, ...), how it has been configured, if + the end-hosts is validating, etc. b. Because the need of using DNS64 ([RFC6147]), there is a major issue for NAT64 ([RFC6146]), as doesn't work when literal addresses or non-IPv6 compliant APIs are being used. c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or applications located within a network which are connected to a service provider IPv6-only access. The same issues are true if part of an enterprise or similar network, @@ -262,21 +262,21 @@ +----------+ | +----------+ | | | | | | IPv6 +-------------+--------------+ IPv4 | | | | | +----------+ +----------+ Figure 3: NAT64 and DNS64 in external provider One more equivalent scenario will be if the service provider offers 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 free DNS64 services and users often configure manually their DNS. 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 the considerations in the previous paragraphs of this section are the same for this sub-case. 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 in this scenario. @@ -336,21 +336,21 @@ the end-user device applications can access IPv4-only end-networks/ applications, despite those applications or devices use literal IPv4 addresses or non-IPv6 compliant APIs. In addition to that, in the same example of the cellular network above, if the User Equipment (UE) provides tethering, other devices 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 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 functionality at the CE. In order to understand all the communication possibilities, let's assume the following representation of two dual-stack peers: +-------+ .-----. .-----. | | / \ / \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ / Local \ | SOHO +--( only )---( NAT64 )---( only ) @@ -649,21 +649,21 @@ the previous sections, by the Figure number. The possible values are: - Scenario "bad" for that item. + Scenario "good" for that item. Needs to be noted that in some cases "countermeasures", alternative or special configurations, may be available for the items designated 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 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 and IPv6-compliant APIs, there is no impact using only NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is still relevant. +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ @@ -700,21 +700,21 @@ 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 DNS64, and the result is a synthesized AAAA record, and the recursive name server is configured to perform DNSSEC validation and has a valid chain of trust to the zone in question, it will cryptographically validate the negative response from the authoritative name server. This is the expected DNS64 behavior: The recursive name server actually lies to the client device. However, 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. A validating DNS64 resolver in fact, increase the confidence on the synthetic AAAA, as it has validated that a non-synthetic AAAA for sure, doesn't exists. However, if the client device is NAT64-oblivious (most common case) and performs DNSSEC validation on the AAAA record, it will fail as it is a synthesized record. The best possible scenario from DNSSEC point of view is when the client requests the DNS64 server to perform the DNSSEC validation (by @@ -1060,22 +1060,22 @@ supported by the operator), in order to fully support the actual user needs (IPv4-only devices and applications, usage of literals and old APIs), they SHOULD consider the 464XLAT scenario and in that case, MUST support the customer-side translator (CLAT). If the operator offers DNS services, in order to increase performance by reducing the double translation for all the IPv4 traffic, they MAY support DNS64 and avoid, as much as possible, breaking DNSSEC. In 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 - considered de simpler and safer approach, and MAY be combined as well - with the other possible solutions described in this document: + considered the simpler and safer approach, and MAY be combined as + well with the other possible solutions described in this document: o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). o Devices running CLAT SHOULD follow the indications in Section 4.1.3 (Stub validator). However, this may be out of the control of the operator. 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 @@ -1382,48 +1382,43 @@ Figure 19: CE setup with bridged CLAT without DNS64 It should be avoided that several routers (i.e., the operator provided CE and a downstream user provided router) enable simultaneously routing and/or CLAT, in order to avoid multiple NAT44 and NAT46 levels, as well as ensuring the correct operation of multiple IPv6 subnets, so it is suggested to use HNCP ([RFC8375]). Note that the procedure described here for the CE setup, can be - simplified if the CE follows draft-ietf-v6ops-transition-ipv4aas ... - TBD. + simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas]. 11. ANNEX B: CLAT Implementation - TBD. - A CLAT CE implementation basically requires support of [RFC7915] for the NAT46 functionality, [RFC7050] for the PLAT prefix discovery (and/or [RFC7225] for PCP), and if stateless NAT46 is supported, mechanisms to ensure that multiple /64 are available, such as DHCPv6-PD [RFC3633]. There are several OpenSource implementations of CLAT, such as: Android: https://github.com/ddrown/android_external_android-clat. Linux: https://github.com/toreanderson/clatd. OpenWRT: https://github.com/openwrt- routing/packages/blob/master/nat46/files/464xlat.sh. VPP: https://git.fd.io/vpp/tree/src/plugins/nat. 12. ANNEX C: Benchmarking - TBD. - Several documents provide references to benchmarking, for example in the case of DNS64, [DNS64-Benchm]. 13. References 13.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, @@ -1495,54 +1490,64 @@ 13.2. Informative References [About-DNS64] J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, . [DNS64-Benchm] 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] Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Iyengar, "Specification of DNS over Dedicated QUIC Connections", draft-huitema-quic-dnsoquic-05 (work in progress), June 2018. [I-D.ietf-doh-dns-over-https] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", draft-ietf-doh-dns-over-https-12 (work in 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., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, . [RIPE-690] RIPE, "Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non- persistent, and what size to choose", October 2017, . [Threat-DNS64] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different 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 Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 La Navata - Galapagar, Madrid 28420 Spain Email: jordi.palet@theipv6company.com