--- 1/draft-ietf-v6ops-nat64-deployment-03.txt 2019-04-02 17:13:10.368804677 -0700 +++ 2/draft-ietf-v6ops-nat64-deployment-04.txt 2019-04-02 17:13:10.444806673 -0700 @@ -1,18 +1,18 @@ v6ops J. Palet Martinez Internet-Draft The IPv6 Company -Intended status: Informational October 10, 2018 -Expires: April 13, 2019 +Intended status: Informational April 2, 2019 +Expires: October 4, 2019 NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks - draft-ietf-v6ops-nat64-deployment-03 + draft-ietf-v6ops-nat64-deployment-04 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,25 +24,25 @@ 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 April 13, 2019. + This Internet-Draft will expire on October 4, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -73,34 +73,36 @@ 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 19 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 19 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 20 4.4. Manual Configuration of Foreign DNS . . . . . . . . . . . 21 4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 4.6. Split DNS . . . . . . . . . . . . . . . . . . . . . . . . 21 4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 22 4.8. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22 4.9. IPv4-only Hosts or Applications . . . . . . . . . . . . . 23 4.10. CLAT Translation Considerations . . . . . . . . . . . . . 23 - 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 23 - 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 26 + 4.11. EAMT Considerations . . . . . . . . . . . . . . . . . . . 23 + 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 24 + 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 - 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 28 + 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 29 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 32 - 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 32 - 13. ANNEX D: Changes from -00 and -01 . . . . . . . . . . . . . . 32 - 14. ANNEX D: Changes from -01 and -02 . . . . . . . . . . . . . . 32 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 33 - 15.2. Informative References . . . . . . . . . . . . . . . . . 34 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 + 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 33 + 13. ANNEX D: Changes from -00 to -01 . . . . . . . . . . . . . . 33 + 14. ANNEX E: Changes from -01 to -02 . . . . . . . . . . . . . . 33 + 15. ANNEX F: Changes from -02 to -03 . . . . . . . . . . . . . . 33 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 16.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 16.2. Informative References . . . . . . . . . . . . . . . . . 36 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation mechanism, which allows IPv6-only hosts to communicate with IPv4-only servers using unicast UDP, TCP or ICMP, by means of IPv4 public addresses sharing (assigned to the translator), among multiple IPv6-only hosts. The translation of the packet headers is done using the IP/ICMP @@ -803,21 +805,21 @@ ipv4only.arpa. A 192.0.0.171 An alternative option to the above, is the use of DNS RPZ (Response Policy Zones). One more alternative, only valid in environments with PCP support (for both the hosts or CEs and for the service provider network), to follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). Other alternatives may be available in the future, such as Router - Advertising ([I-D.pref64folks-6man-ra-pref64]) or DHCPv6 options. + Advertising ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options. It may be convenient to support at the same time several of the approaches described, in order to ensure that clients with different ways to configure the NAT64 prefix, successfully obtain it. This is also convenient even if DNS64 is being used. 4.1.2. DNSSEC validator aware of DNS64 In general, DNS servers with DNS64 function, by default, will not synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the @@ -827,23 +829,23 @@ not broken. However, this will not work if a CLAT is not present as the hosts will not be able to use IPv4 (scenarios without 464XLAT). 4.1.3. Stub validator If the DO flag is set and the client device performs DNSSEC validation, and the Checking Disabled (CD) flag is set for a query, as the DNS64 recursive server will not synthesize AAAA responses, the client could perform the DNSSEC validation with the A record and then may query the network for a NAT64 prefix ([RFC7050], [RFC7225], - [I-D.pref64folks-6man-ra-pref64] or other methods) in order to - synthesize the AAAA ([RFC6052]). This allow the client device to - avoid using the CLAT and still use NAT64 even with DNSSEC. + [I-D.ietf-6man-ra-pref64] or other methods) in order to synthesize + the AAAA ([RFC6052]). This allow the client device to avoid using + the CLAT and still use NAT64 even with DNSSEC. If the end-host is IPv4-only, this will not work if a CLAT is not present (scenarios without 464XLAT), unless the client is able to locally perform the address synthesis. Some devices/OSs may implement, instead of CLAT, a similar function by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the considerations in the above paragraphs are also applicable. @@ -966,24 +968,23 @@ However, it needs to be reinforced, that if there is not a CLAT (scenarios without 464XLAT), an external DNS without DNS64 support, will disallow any access to IPv4-only networks, and will not guarantee DNSSEC, so will behave as in the Section 3.2.1. 4.5. DNS Privacy If clients use mechanisms for DNS privacy, such as DNS over TLS ([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS - ([I-D.ietf-doh-dns-over-https]) or DNS over QUIC - ([I-D.huitema-quic-dnsoquic]), as they may provide different results - to the same query, it must be expected equivalent effects as - described in Section 4.4. + ([RFC8484]) or DNS over QUIC ([I-D.huitema-quic-dnsoquic]), as they + may provide different results to the same query, it must be expected + equivalent effects as described in Section 4.4. 4.6. Split DNS As already indicated in precedent sections, the successful use of the DNS64 is not guaranteed when networks or hosts can use "split-DNS" (also called Split Horizon), private DNS. Section 4. of [RFC6950], analyses this case. This a very common situation when using VPNs. 4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) @@ -1050,32 +1051,44 @@ However, if this dedicated prefix is not available, the CLAT will need to do a stateful translation, for example performing stateful NAT44 for all the IPv4 LAN packets, so they appear as coming from a single IPv4 address, and then in turn, stateless translated to a single IPv6 address. One possible setup, in order to maximize the CLAT performance, is to configure the dedicated translation prefix. This can be easily achieved automatically, if the broadband CE or end-user device is - able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]), or + able to obtain a shorter prefix by means of DHCPv6-PD ([RFC8415]), or other alternatives, so the CE can use a specific /64 for the translation. This is also possible when broadband is provided by a cellular access. The above recommendation is often not possible for cellular networks, when connecting smartphones (as UEs), as generally they don't use - DHCPv6-PD ([RFC3633]) an instead a single /64 is provided for each + DHCPv6-PD ([RFC8415]) an instead a single /64 is provided for each PDP context and use /64 prefix sharing ([RFC6877]). So, in this case, the UEs typically have a build-in CLAT client, which is doing a stateful NAT44 before the stateless NAT46. +4.11. EAMT Considerations + + Explicit Address Mappings for Stateless IP/ICMP Translation [RFC7757] + provides a way to configure explicit mappings between IPv4 and IPv6 + prefixes of any length. When this is used, for example in a CLAT, it + may provide a simple mechanism in order to avoid traffic flows + between IPv4-only nodes or applications and dual-stack destinations + to be translated twice (NAT46 and NAT64), by creating mapping entries + with the GUA of the IPv6-reachable destination. This optimization of + the NAT64 usage is very useful in many scenarios, including CDNs and + caches, as described in [I-D.palet-v6ops-464xlat-opt-cdn-caches]. + 5. Summary of Deployment Recommendations for NAT64/464XLAT It can be argued that none of the possible transition mechanisms is perfect, and somehow, we may consider that actually this is a good thing as a way to push for the IPv6 deployment, or otherwise, it may be further delayed, with clear undesirable effects for the global Internet. However, for an operator, being in business means minimizing the adverse transition effects, and provide the most perfect one, @@ -1148,21 +1161,21 @@ Similar considerations need to be taken regarding the usage of a NAT64 Well-Known-Prefix (WKP) vs Network-Specific Prefix (NSP) (Section 4.7), in the sense of, if using DNS64, they must match and, if the user can change the DNS configuration, they will, most probably, not match. If there is a CLAT and the users chosen DNS is not a DNS64, the network will keep working of other means of learning the NAT64 are available. As described in Section 4.10 in broadband networks, it is recommended - that CEs supporting CLAT, supports DHCPv6-PD ([RFC3633]), or + that CEs supporting CLAT, supports DHCPv6-PD ([RFC8415]), or alternative means for configuring a shorter prefix, and internally reserve one /64 for the stateless NAT46 translation. The operator must ensure that the customers get allocated prefixes shorter than /64 in order to support this optimization. One way or the other, this is not impacting the performance of the operator network. Operators may follow Section 7 of [RFC6877] (Deployment Considerations), for suggestions in order to take advantage of traffic engineering requirements. @@ -1200,20 +1213,24 @@ avoiding the cases where DNSSEC may be broken. However, this will not solve the issues related to DNS Privacy and Split DNS. The only 100% safe solution, which also resolves all the issues, will be, in addition to having a CLAT, not using a DNS64 but instead making sure that the hosts have a built-in address synthesis feature. Operators could manage to use the CLAT, however the built-in address synthesis feature is out of their control, and can only be resolved by operating system vendors. + Whenever feasible, using EAMT ([RFC7757]) as indicated in + Section 4.11, provides a very relevant optimization, avoiding double- + translations. + 6. Deployment of NAT64 in Enterprise Networks The recommendations of this document can be used as well in enterprise networks, campus and other similar scenarios (including managed end-user networks). This include scenarios where the NAT64 (and/or DNS64) are under the control of that network (or can be configured manually according to that network specific requirements), and for whatever reasons, there is a need to provide "IPv6-only access" to any part of that network @@ -1354,26 +1371,26 @@ Figure 17: CE setup with built-in CLAT with DNS64 In addition to the regular CE setup, which will be typically access- technology dependent, the steps for the CLAT configuration can be summarized as: 1. Discovery of the PLAT (NAT64) prefix: It may be done using [RFC7050], or in those networks where PCP is supported, by means of [RFC7225], or other alternatives that may be available in the - future, such as Router Advertising - ([I-D.pref64folks-6man-ra-pref64]) or DHCPv6 options. + future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or + DHCPv6 options. 2. If the CLAT allows stateless NAT46 translation, a /64 from the pool typically provided to the CE by means of DHCPv6-PD - [RFC3633], need to be set aside for that translation. Otherwise, + [RFC8415], need to be set aside for that translation. Otherwise, the CLAT is forced to perform an intermediate stateful NAT44 before the a stateless NAT46, as described in Section 4.10. A more detailed configuration approach is described in [I-D.ietf-v6ops-transition-ipv4aas]. The operator network needs to ensure that the correct responses are provided for the discovery of the PLAT prefix, as well as it is highly recommended follows [RIPE-690], in order to ensure that multiple /64s are available including the one needed for the NAT46 @@ -1467,78 +1484,79 @@ In addition to the regular set of features for a CE, a CLAT CE implementation requires support of: o [RFC7915], for the NAT46 functionality. o [RFC7050], for the PLAT prefix discovery. o [RFC7225], for the PLAT prefix discovery if PCP is supported. - o [I-D.pref64folks-6man-ra-pref64], for the PLAT prefix discovery by - means of Router Advertising. + o [I-D.ietf-6man-ra-pref64], for the PLAT prefix discovery by means + of Router Advertising. o If stateless NAT46 is supported, a mechanism to ensure that - multiple /64 are available, such as DHCPv6-PD [RFC3633]. + multiple /64 are available, such as DHCPv6-PD [RFC8415]. There are several OpenSource implementations of CLAT, such as: o Android: https://github.com/ddrown/android_external_android-clat. o Linux: https://github.com/toreanderson/clatd. o OpenWRT: https://github.com/openwrt- routing/packages/blob/master/nat46/files/464xlat.sh. o VPP: https://git.fd.io/vpp/tree/src/plugins/nat. 12. ANNEX C: Benchmarking Several documents provide references to benchmarking, for example in the case of DNS64, [DNS64-Benchm]. -13. ANNEX D: Changes from -00 and -01 +13. ANNEX D: Changes from -00 to -01 - Section to be removed for WGLC. Significant updates are: + Section to be removed after WGLC. Significant updates are: 1. Text changes across all the document. -14. ANNEX D: Changes from -01 and -02 +14. ANNEX E: Changes from -01 to -02 - Section to be removed for WGLC. Significant updates are: + Section to be removed after WGLC. Significant updates are: 1. Added references to new cited documents. 2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only LANs w/o DNS64. 3. Overall review and editorial changes. -15. References +15. ANNEX F: Changes from -02 to -03 -15.1. Normative References + Section to be removed after WGLC. Significant updates are: + + 1. Added text related to EAMT considerations. + +16. References + +16.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . - [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic - Host Configuration Protocol (DHCP) version 6", RFC 3633, - DOI 10.17487/RFC3633, December 2003, - . - [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, . [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, . [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful @@ -1570,20 +1588,25 @@ [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, . [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, DOI 10.17487/RFC7225, May 2014, . + [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address + Mappings for Stateless IP/ICMP Translation", RFC 7757, + DOI 10.17487/RFC7757, February 2016, + . + [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix @@ -1592,59 +1615,69 @@ [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, . -15.2. Informative References + [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., Lemon, T., and T. Winters, + "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 8415, DOI 10.17487/RFC8415, November 2018, + . + + [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS + (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, + . + +16.2. Informative References [About-DNS64] - J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, + APNIC Blog, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, . [DNS64-Benchm] - G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 - Implementations: Theory and Practice", Computer - Communications (Elsevier), vol. 127, no. 1, pp. 61-74, - DOI 10.1016/j.comcom.2018.05.005, September 2018. + "Benchmarking DNS64 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.bp-v6ops-ipv6-ready-dns-dnssec] Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00 (work in progress), October 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. + Connections", draft-huitema-quic-dnsoquic-06 (work in + progress), March 2019. - [I-D.ietf-doh-dns-over-https] - Hoffman, P. and P. McManus, "DNS Queries over HTTPS - (DoH)", draft-ietf-doh-dns-over-https-14 (work in - progress), August 2018. + [I-D.ietf-6man-ra-pref64] + Colitti, L., Kline, E., and J. Linkova, "Discovering + PREF64 in Router Advertisements", draft-ietf-6man-ra- + 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-09 - (work in progress), October 2018. + as-a-Service", draft-ietf-v6ops-transition-ipv4aas-15 + (work in progress), January 2019. - [I-D.pref64folks-6man-ra-pref64] - Colitti, L., Kline, E., and J. Linkova, "Discovering - PREF64 in Router Advertisements", draft-pref64folks-6man- - ra-pref64-02 (work in progress), October 2018. + [I-D.palet-v6ops-464xlat-opt-cdn-caches] + Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/ + Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work + in progress), March 2019. [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, . [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 Deployment Options and Experience", RFC 7269, DOI 10.17487/RFC7269, June 2014, . @@ -1659,26 +1692,25 @@ 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", Computers & Security (Elsevier), vol. 77, - no. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August - 2018. + "Methodology for the identification of potential security + issues of different IPv6 transition technologies: Threat + analysis of DNS64 and 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