--- 1/draft-ietf-v6ops-464xlat-optimization-00.txt 2020-07-07 11:13:09.425073897 -0700 +++ 2/draft-ietf-v6ops-464xlat-optimization-01.txt 2020-07-07 11:13:09.469075008 -0700 @@ -1,19 +1,19 @@ v6ops J. Palet Martinez Internet-Draft The IPv6 Company Intended status: Informational A. D'Egidio -Expires: July 17, 2020 Telecentro - January 14, 2020 +Expires: January 8, 2021 Telecentro + July 7, 2020 464XLAT/NAT64 Optimization - draft-ietf-v6ops-464xlat-optimization-00 + draft-ietf-v6ops-464xlat-optimization-01 Abstract This document proposes possible solutions to avoid certain drawbacks of IP/ICMP Translation Algorithm (SIIT) when the destinations are already available with IPv6. When SIIT is used as a stateless NAT46 and IPv4-only devices or applications initiate traffic flows to dual- stack services (in the operator network or Internet), those flows will be translated back to IPv4 by a NAT64. Avoiding this dual- translation will significantly reduce the usage of the NAT64 and the @@ -29,21 +29,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 July 17, 2020. + This Internet-Draft will expire on January 8, 2021. Copyright Notice Copyright (c) 2020 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 @@ -199,24 +199,23 @@ o More traffic needs to pass thru the NAT64 devices. o More NAT64 devices may be needed to handle the additional traffic. o Additional usage of IPv4 addresses. o Additional state at the NAT64 devices. o Additional logging, its relevant storage and processing resources. - o Clearly all those aspects have impact in both, CapEx and OpEx. - - This is extremely important when considering that most of the time, - the contents stored in CDNs, caches, and so on, is there for a good + Clearly, all those aspects have impact in both, CapEx and OpEx. This + is extremely important when considering that most of the time, the + contents stored in CDNs, caches, and so on, is there for a good reason: It is frequently accessed resources and/or big. Examples such as video, audio, software and updates, are very common. So, this optimization can be highly impacting in many networks. 4. Problem Statement If the devices or applications in the customer LAN are IPv6-capable, then the access to the CDNs, caches or other resources, will be made in an optimized way, by means of IPv6-only, not using the NAT64, as depicted in Figure 3. @@ -406,34 +405,35 @@ Each EAMT entry will contain, the fields already described in [RFC7757] and a few new ones: 1. ID: EAMT Entry Index (optional). 2. IPv4 address/prefix: By default, the prefix length is 32 bits. 3. IPv6 address/prefix: By default, the prefix length is 128 bits. 4. TTL: Because the optimization will make use of the AAAA (IPv6 - address), the TTL for the EAMT entry must be the one of the AAAA - RR. In normal conditions the TTL for both A and AAAA records, of - a given FQDN, should be the same, so this ensures a proper - behavior if there is any DNS mismatch. + address), the TTL for the EAMT entry must set to the same value + as in the AAAA RR. In normal conditions the TTL for both A and + AAAA records, of a given FQDN, should be the same, so this + ensures a proper behavior if there is any DNS mismatch. 5. FQDN: The one that originated the A query for this EAMT entry. Required in order to ensure a correct detection of cases such as the use of reverse-proxy with a single IPv4 address to multiple IPv6 addresses. 6. Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT be used and consequently no optimization performed. It may be used also for an explicit configuration (GUI, CLI, provisioning - system, etc.) to disallow optimization for any IPv4 addresses. + system, etc.) to disallow optimization for explicitly configured + IPv4 addresses. 7. Auto/Static: When set to 1, means that this EAMT entry has been manually/statically configured, for example by means of an explicit configuration (GUI, CLI, provisioning system, etc.), so it doesn't expire with TTL. When a new EAMT entry is first automatically created, it is marked as "Valid" and "Auto" (both bits cleared). If a subsequent A query, with a different FQDN, results in an IPv4 address that has already an EAMT entry and a different IPv6 address, it means that some reverse- @@ -448,24 +448,22 @@ which allows to re-enable optimization if a new query for the A record has changed the situation. For example, maybe the reverse- proxy has been removed, or there is now only a single device using it, so at the time being, the optimization is again possible without creating troubles to other hosts. Note that when an EAMT entry is marked as "invalid", it will not affect the devices or applications, as they will still be able to use the regular CLAT+NAT64 flow, of course, without the optimization. - ***** Open question regarding TTL and maybe FQDN and valid/auto bits. - Is this always a good thing to do for EAM? Should this document - update [RFC7757] to support this by default? Or it is just and - "extension" as per section 3.1 of [RFC7757]. + Note the newly defined EAMT fields, follow the "extensions" approach + as per section 3.1 of [RFC7757]. 5.2.4. Forwarding path via stateful NAT for existing EAMT entries Following this approach, if there is a valid EAMT entry, for a given IPv4-destination, the IPv6-native path pointed by the IPv6 address of that EAMT entry, will take precedence versus the NAT64 path, so the traffic will not be forwarded to the NAT64. However, this is not sufficient to ensure that individual applications are able to keep existing connections. In many cases, @@ -479,21 +477,22 @@ establish a forwarding path, but instead, to create a stateful NAT entry for the 4-tuple for the duration of the session/connection. 5.2.5. Maintenance of the EAMT entries The information in the EAMT MUST be kept timely-synchronized with the AAAA records TTL's, so the EAMT entries MUST expire on the AAAA TTL expiry and consequently be deleted. However, EAMT entries with the Auto/Static bit set, will not be - deleted. + deleted. This allows users/operators to set explicit rules for + diagnostics or resolution of issues in special situations. 5.2.6. Usage example Using the same example as in the previous approach: www.example.com A 192.0.2.1 AAAA 2001:db8::a:b:c:d EAMT entry 192.0.2.1 2001:db8::a:b:c:d NAT46/CLAT translated to 2001:db8::a:b:c:d CDN IPv6 interface already is 2001:db8::a:b:c:d @@ -516,38 +515,37 @@ 5.2.7. Behavior in case of multiple A/AAAA RRs If multiple A and/or AAAA records are available, the DNS proxy/stub resolver MUST follow existing procedures to choose each one. In other words, the chosen pair of A/AAAA records doesn't present any different result compared with a situation when this mechanism is not used. 5.2.8. Behavior in presence/absence of DNS64 - This mechanism performs the same in both cases, if a DNS64 is - present/used and if it is not present/used. This is explained - because the mechanism is only relevant for destinations which don't - have AAAA records, and in those cases DNS64 is not relevant. - - Furthermore, because as indicated in Section 5.2.2, the EAMT entry is - not created when the service is IPv6-enabled. This is relevant - because 464XLAT can be deployed/used with and without a DNS64. + This optimization performs the same in both cases: if a DNS64 is + present/used or if it is not present/used. This is explained because + the optimization is only relevant for destinations which already have + AAAA records, and in those cases DNS64 is not relevant. Furthermore, + because as indicated in Section 5.2.2, the EAMT entry is not created + when the service is IPv6-enabled. This is relevant because 464XLAT + can be deployed/used with and without a DNS64. 5.2.9. Behavior when using literal addresses or non IPv6-compliant APIs Because the EAMT entries are only created when the NAT46/CLAT/CE proxy/stub DNS is being used, any devices or applications that don't use DNS, will not create the relevant entries. - They will be however optimized if devices or applications using DNS, - at some point, query for the same A RRs, or if EAMT entries are - statically configured. + They maybe optimized if devices or applications using DNS, at some + point, query for the same A RRs, or if EAMT entries are statically + configured. 5.2.10. False detection of a dual-stack host as IPv4-only If a dual-stack host is issuing the A query using IPv4 transport, and the AAAA query using IPv6 transport, or using different IPv4 addresses for the A and AAAA queries, the EAMT entry will be created. However, this EAMT entry may not be used by dual-stack devices or applications, because those devices or applications should prefer IPv6. If the host is preferring IPv4 for connecting to the CDN/cache or IPv6-enabled service, it will be actually using the NAT46/CLAT, @@ -576,49 +574,50 @@ actually considered as a good thing, in the sense that an operator is interested in knowing as soon as possible, if the IPv6-only network is not performing correctly, because that means also IPv4 will not be working. If the issue is related to extra IPv6 delay versus the IPv4 delay, Happy Eyeballs will not be able to offer a significative advantage here, but it looks like an acceptable trade-off. Note that when using 464XLAT, the WAN link of the NAT46/CLAT/CE is IPv6-only. So even if Happy Eyeballs is present, the fallback to IPv4-only typically, will be slower than native IPv6 itself, because - the added detail in the NAT46+NAT64 translations, when not using this + the added delay in the NAT46+NAT64 translations, when not using this optimization. 5.2.12. Behavior in case of Foreign DNS Devices or applications may use DNS servers from other networks. For a complete description of reasons for that, refer to Section 4.4 of - [I-D.ietf-v6ops-nat64-deployment]. In the case the DNS is modified, - or some devices or applications use other DNS servers, the possible - scenarios and the implications are: + [RFC8683]. In the case the DNS is modified, or some devices or + applications use other DNS servers, the possible scenarios and the + implications are: a. Devices configured to use a DNS proxy/resolver which is not the CE/NAT46/CLAT. In this case this optimization will not work, because the EAMT entry will not be created based on their own flows. Nevertheless, the EAMT entry may be created by other devices using the same destinations. However, the lack of EAMT entry, will not impact negatively in the user's devices/ applications (the optimization is not performed). It should be noticed that users commonly, don't change the configuration of devices such as SmartTVs or STBs (if they do, some other functionalities, such as CDN/caches optimizations may not work as well), so this only happens typically if the vendor is doing it on-purpose and for good well-known reasons. b. DNS privacy/encryption. Hosts or applications that use mechanisms for DNS privacy/encryption, such as DoT ([RFC7858], - [RFC8094]), DoH ([RFC8484]) or DoQ ([I-D.huitema-quic-dnsoquic]), - will not make use of the stub/proxy resolver, so the same - considerations as for the previous case apply. + [RFC8094]), DoH ([RFC8484]) or DoQ + ([I-D.huitema-dprive-dnsoquic]), will not make use of the stub/ + proxy resolver, so the same considerations as for the previous + case apply. c. Users that modify the DNS in their Operating Systems. This is quite frequent, however commonly Operating Systems are dual- stack, so aren't part of the problem statement described by this document and will not be adversely affected. d. Users that modify the DNS in the CE. This is less common. In this case, this optimization is not adversely affected, because it doesn't depend on the operator DNS, it works only based on the internal CE interaction between the NAT46/CLAT and the stub/proxy @@ -672,74 +671,65 @@ 6. IPv6-only Services become accessible to IPv4-only devices/apps One of the issues with the IPv6 deployment, is that those services which become IPv6-only in Internet, aren't reachable by IPv4-only devices and applications. This means that new content providers must support dual-stack even for new services, even while IPv4 public addresses aren't available. If NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) is chosen, it also offers the chance to resolve this issue. This is possible if - IPv6-only services get configured with an A resource record (TBD: - special allocated IANA IPv4 address), despite they aren't actually - connected to IPv4. This will mean that those services will work fine - if there is a NAT46/CLAT. This A RR has no negative impact if the - NAT46/CLAT doesn't exist, because is not reachable via IPv4-only, so - is not a different situation than not having an A RR. + IPv6-only services get configured with an A resource record pointing + to a well-known IPv4 address despite they aren't actually connected + to IPv4. This is out of scope for this document, as it will require + further work and a reservation by IANA, This will mean that those + services will work fine if there is a NAT46/CLAT supporting the + optimization. This A RR has no negative impact if the NAT46/CLAT + doesn't exist, or it is not optimized, because is not reachable via + IPv4-only, so is not a different situation compared with not having + an A RR. The result of this is equivalent to the approach taken by MAP-T (Section 12.3 of [RFC7599]). However, it has the advantage that the MAP-T approach is restricted to services in the MAP-T domain. - TBD. In fact, it may become an incentive for the IPv6 deployment in - Internet services and provides the option to use an IPv4 address - (maybe anycast) for the "non-valid" A RR, that points to a - "universal" web page (maybe hosted by IANA or IETF?) that displays a - warning such as "You should contact your ISP; this service is only - available if the network is properly connected to Internet, which is - not the case.". + In fact, it may become an incentive for the IPv6 deployment in + Internet services, as it provides the option to use a well-known IPv4 + address (maybe anycast) for the "non-valid" A RR, that points, in + case of port 80/443 to a web page or service that returns a warning + such as "This service is only available if the network is properly + connected to Internet with IPv6". 7. Conclusions NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) seems the right solution for optimizing the access to dual-stack services, whether they are located inside or outside the ISP. It is also the only approach which has no additional requirements for the network - operator. + operators (both ISPs and CDN/cache operators). Having this type of optimization facilitates and increases the usage of IPv6, even for IPv4-only devices and applications, at the same time that decreases the use of the NAT64. - SIIT already has a SHOULD for EAM support. Should 464XLAT be updated - by this document so the CLAT has a MUST for EAM support?. - - Should we recommend having A records for IPv6-only services in - Internet? The A record may point to a "reserved" or "special" IPv4 - address. A web page IPv4-only hosted by IETF(?) showing "sorry this - web page/service is only available from IPv6 enabled operators"?. - - Open question: Should we consider any other risks? If CE's - implementing this optimization create troubles, it may bring the - content providers to switch back to IPv4-only. So possible failure - cases need to be carefully considered for every possible solution - approach. + SIIT already has a SHOULD for EAM support, so it is not a high + additional burden the support required for existing implementations + to be updated for this optimization. 8. Security Considerations This document does not have any new specific security considerations, besides the ones already known for DNS64. 9. IANA Considerations - This document does not have any new specific IANA considerations, - unless we decide to define a "special reserved IPv4 address". TBD. + This document does not have any new specific IANA considerations. 10. Acknowledgements The authors would like to acknowledge the inputs of Erik Nygren, Fred Baker, Martin Hunek, Chongfeng Xie, Fernando Gont, Fernando Frediani and TBD ... 11. References 11.1. Normative References @@ -794,50 +784,49 @@ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . 11.2. Informative References - [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-07 (work in - progress), September 2019. - - [I-D.ietf-v6ops-nat64-deployment] - Palet, J., "Additional NAT64/464XLAT Deployment Guidelines - in Operator and Enterprise Networks", draft-ietf-v6ops- - nat64-deployment-08 (work in progress), July 2019. + [I-D.huitema-dprive-dnsoquic] + Huitema, C., Mankin, A., and S. Dickinson, "Specification + of DNS over Dedicated QUIC Connections", draft-huitema- + dprive-dnsoquic-00 (work in progress), March 2020. [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, . [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, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . + [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for + NAT64/464XLAT in Operator and Enterprise Networks", + RFC 8683, DOI 10.17487/RFC8683, November 2019, + . + Authors' Addresses Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 La Navata - Galapagar, Madrid 28420 Spain Email: jordi.palet@theipv6company.com URI: http://www.theipv6company.com/