v6ops J. Palet MartinezInternet-Draft The IPv6 CompanyIntended status: Informational A. D'EgidioExpires: January 9, 2020 Telecentro July 8, 2019 464XLAT Optimizationdraft-palet-v6ops-464xlat-opt-cdn-caches-03Abstract This document proposes possible solutions to avoid certain drawbacks of IP/ICMP Translation Algorithm (SIIT) when the destinations are available with IPv6. When SIIT is used as a NAT46 and IPv4-only devices or applications initiate traffic flows to dual-stack CDNs (Content Delivery Networks), Caches or other network resources (in the operator network or Internet), those flows will be translated back to IPv4 by a NAT64. This is the case for 464XLAT and MAP-T.Status of This Memo This Internet-Draft is submitted in full conformance with the provisions ofBCP 78 andBCP 79. 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 athttps://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 9, 2020.Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 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 mustPalet Martinez & D'EgidioExpires January 9, 2020 [Page 1]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .22. Requirements Language . . . . . . . . . . . . . . . . . . . .43. Problem Statement . . . . . . . . . . . . . . . . . . . . . .44. Solution Approaches . . . . . . . . . . . . . . . . . . . . .64.1. Approach 1: DNS/Routing-based Solution . . . . . . . . .64.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . .74.2.1. Detection of IPv4-only devices or applications . . .74.2.2. Detection of IPv6-enabled service . . . . . . . . . .84.2.3. Creation of EAMT entries . . . . . . . . . . . . . .84.2.4. Forwarding path for existing EAMT entries . . . . . .104.2.5. Maintenance of the EAMT entries . . . . . . . . . . .104.2.6. Usage example . . . . . . . . . . . . . . . . . . . .104.2.7. Behavior in case of multiple A/AAAA RRs . . . . . . .104.2.8. Behavior in presence/absence of DNS64 . . . . . . . .11 4.2.9. Behavior when using literal addreses or non IPv6-compliant APIs . . . . . . . . . . . . . . . . .114.2.10. False detection of a dual-stack host as IPv4-only . .114.2.11. Behaviour in presence of Happy Eyeballs . . . . . . .114.2.12. Behavior in case of Foreign DNS . . . . . . . . . . .124.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . .13 5. IPv6-only Services become accessible to IPv4-only devices/apps . . . . . . . . . . . . . . . . . . . . . . . .146. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .147. Security Considerations . . . . . . . . . . . . . . . . . . .158. IANA Considerations . . . . . . . . . . . . . . . . . . . . .159. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .1510. References . . . . . . . . . . . . . . . . . . . . . . . . .1510.1. Normative References . . . . . . . . . . . . . . . . . .1510.2. Informative References . . . . . . . . . . . . . . . . .16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .171. Introduction Different transition mechanisms, typically in the group of the so- called IPv6-only with IPv4aaS (IPv4-as-a-Service), such as 464XLAT ([RFC6877]) or MAP-T ([RFC7599]), allow IPv4-only devices or applications to connect with IPv4 services in Internet, by means of a NAT46 SIIT (IP/ICMP Translation Algorithm) as described by [RFC7915]. This is done by the implementation of SIIT at the CE (Customer Edge) Router or sometimes at the end-device, for example, the UE (User Equipment) in cellular networks. This functionality is the CLATPalet Martinez & D'EgidioExpires January 9, 2020 [Page 2]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 (Customer Translator) in the case of 464XLAT. The NAT46/CLAT (WAN side) is connected by IPv6-only to the operator network, which in turn, will have a reverse function, the NAT64 ([RFC6146]), known as PLAT (Provider Translator) in the case of 464XLAT. This allows to translate the IPv6-only flow back to IPv4, in order to forward it to Internet. The translation of the packet headers is done using the IP/ICMP translation algorithm defined in [RFC7915] and algorithmically translating the IPv4 addresses to IPv6 addresses following [RFC6052]. In the case of 464XLAT, a DNS64 ([RFC6147]) optionally is in charge of the synthesis of AAAA records from the A records, so they can use a NAT64, without the need of doing a double-translation by means of the CLAT. However, the DNS64 is not useful for the IPv4-only devices or applications in the LANs, as they will not be able to use the AAAA records. A typical 464XLAT deployment is depicted in Figure 1. +-------+ .-----. .-----. | IPv6 | / \ / \ .-----. | CE | / IPv6- \ .-----. / IPv4 \ / \ | or +--( only )---( NAT64 )---( Internet ) / LAN's \ | UE | \ Access /\ `-----' \ / ( Dual- )--+ | \ / \ \ / \ Stack / | with | `--+--' \ .-----. `-----' \ / | NAT46 | | \ / \ `-----' | CLAT | +---+----+ / IPv6 \ | | | DNS/ | ( Internet ) +-------+ | DNS64 | \ / +--------+ \ / `-----' Figure 1: Typical 464XLAT Deployment As it can be observed in the preceding picture, the situation is the same, regardless of in case of a wired network with a CE Router or a cellular network where a UE is connecting other devices (which may be IPv4-only or have IPv4-only apps), by means of a tethering functionality. If the operator is providing direct access to Content Delivery Networks (CDNs), caches, or other resources, and they are dual- stacked, the situation can be described as shown in Figure 2.Palet Martinez & D'EgidioExpires January 9, 2020 [Page 3]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 +-------+ .-----. .-----. | IPv6 | / \ / \ .-----. | CE | / IPv6- \ .-----. / IPv4 \ / \ | or +--( only )---( NAT64 )---( Internet ) / LAN's \ | UE | \ Access /\ `-----' \ / ( Dual- )--+ | \ / \ \ / \ Stack / | with | `--+--' \ .-----. `--+--' \ / | NAT46 | | \ / \ \ `-----' | CLAT | +---+----+ / IPv6 \ .--+--. | | | DNS/ | ( Internet ) / Dual- \ +-------+ | DNS64 | \ /----/ Stack \ +--------+ \ / ( ) `-----' \ CDNs/ / \ Caches/ `-----' Figure 2: Typical 464XLAT Deployment with CDNs/Caches2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described inBCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.3. 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.Palet Martinez & D'EgidioExpires January 9, 2020 [Page 4]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 +-------+ .-----. .-----. | IPv6 | / \ / \ .-----. | CE | / IPv6- \ .-----. / IPv4 \ / \ | or +--( only )---( NAT64 )---( Internet ) / IPv6 \ | UE | \ Access /\ `-----' \ / ( capable )--+ | \ / \ \ / \ apps / | with | `--+--' \ .-----. `--+--' \ / | NAT46 | | \ / \ `-----' | CLAT | +---+----+ / IPv6 \ .--+--. | | | DNS/ | ( Internet )IPv6/ Dual- \ +-------+ | DNS64 | \ /----/ Stack \ +--------+ \ / ( ) `-----' \ CDNs/ / \ Caches/ `-----' <---------------------- end-to-end IPv6 flow ----------------------> Figure 3: 464XLAT access to CDNs/Caches by IPv6-capable apps However, if the devices or applications are IPv4-only, for example, most of the SmartTVs and Set-Top-Boxes available today, a non-optimal double translation will occur (NAT46 at the CLAT and NAT64 at the PLAT), as illustrated in Figure 4. +-------+ .-----. .-----. | IPv6 | / \ / \ .-----. | CE | / IPv6- \ .-----. / IPv4 \ / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) / only \ | UE | \ Access /\ `-----' \ / ( SmartTV )--+ | \ / \ \ / \ STB / | with | `--+--' \ .-----. `--+--' \ VoIP / | NAT46 | | \ / \ \ IPv4 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. | | | DNS/ | ( Internet ) / Dual- \ +-------+ | DNS64 | \ / / Stack \ +--------+ \ / ( ) `-----' \ CDNs/ / \ Caches/ `-----' <-------------------- IPv4 to IPv6 to IPv4 flow --------------------> Figure 4: 464XLAT access to CDNs/Caches by IPv4-only apps Clearly, this is a non-optimal situation, as it means that even if there is a dual-stack service, the NAT46/CLAT translated IPv4 to IPv6 traffic flow, is unnecessarily translated back to IPv4, traversing the stateful NAT64. This has a direct impact in the need to scale the NAT64 beyond what will be actually needed if possible solutions,Palet Martinez & D'EgidioExpires January 9, 2020 [Page 5]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 in order to keep using the IPv6 path towards those services, are considered. As shown in the Figure 4, this is also the case for many other services, not just CDNs or caches, such as VoIP access to the relevant operator infrastructure, which may be also dual-stack. This is true as well for many other dual-stack or IPv6-enabled services, which may be directly reachable from the operator infrastructure, even if they are not part of it, for example peering agreements, services in IXs, etc. In general, this will become a more frequent situation for many other services, which are not yet dual-stack. For simplicity, across the rest of this document, references to CDNs/ caches, should be understood, unless otherwise stated, as any dual- stacked resources. This document looks into different possible solution approaches in order to optimize the IPv4-only SIIT translation providing a direct path to IPv6-capable services, as depicted in Figure 5. +-------+ .-----. .-----. | IPv6 | / \ / \ .-----. | CE | / IPv6- \ .-----. / IPv4 \ / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) / only \ | UE | \ Access /\ `-----' \ / ( SmartTV )--+ | \ / \ \ / \ STB / | with | `--+--' \ .-----. `--+--' \ VoIP / | NAT46 | | \ / \ `-----' | CLAT | +---+----+ / IPv6 \ .--+--. | | | DNS/ | ( Internet )IPv6/ Dual- \ +-------+ | DNS64 | \ /----/ Stack \ +--------+ \ / ( ) `-----' \ CDNs/ / \ Caches/ `-----' <------------------------ IPv4 to IPv6 flow ------------------------> Figure 5: Optimized 464XLAT access to CDNs/Caches by IPv4-only apps4. Solution Approaches4.1. Approach 1: DNS/Routing-based Solution Because the IPv4-only devices will not be able to query for AAAA records, the NAT46/CLAT/CE will translate the IPv4 addresses from the A record for the CDN/cache destination, using the WKP or NSP, as configured by the operator.Palet Martinez & D'EgidioExpires January 9, 2020 [Page 6]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 If the CDN/cache provider is able to configure, in the relevant interfaces of the CDN/caches, the same IPv6 addresses that will naturally result as the translated destination addresses for the queried A records, preceded by the WKP or NSP, then having more specific routing prefixes, will result in traffic to those destinations being directly forwarded towards those interfaces, instead of needing to traverse the NAT64. For example, let's suppose a provider using the WKP (64:ff9b::/96) and a SmartTV querying for www.example.com: www.example.com A 192.0.2.1 NAT46/CLAT translated to 64:ff9b::192.0.2.1 CDN IPv6 interface must be 64:ff9b::192.0.2.1 Operator must have a specific route to 64:ff9b::192.0.2.1 Note: Examples using text representation as perSection 2.3 of [RFC6052]. Because the WKP is non-routable, this solution will only be possible if the CDN/cache is in the same ASN as the provider network, or somehow interconnected without routing thru Internet. This solution has the additional drawback of the operational complexity/issues added to the operation of the CDN/cache, and the need to synchronize any IPv4 interface address changes with the relevant IPv6 ones, and possibly with routing.4.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution If the NAT46/CLAT/CE, as commonly is the case, is also a DNS proxy/ stub resolver, it is possible to modify the behavior and create an "internal" interaction among both of them. This approach uses the existing IPv4 and IPv6 addresses in the A and AAAA records, respectively, so no additional complexity/issues added to the CDN/caches operations. The following sub-sections detail this approach and provide a step- by-step example case.4.2.1. Detection of IPv4-only devices or applications The assumption is that, typically a dual-stack device will prefer using IPv6 as the DNS transport. So, when there is a DNS query, transported with IPv4, for an A record, and there is not a query for the AAAA record from the same IPv4 source (to the same destination), the DNS proxy/stub resolver can infer that, most probably, it is anPalet Martinez & D'EgidioExpires January 9, 2020 [Page 7]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 IPv4-only device or application. It needs to be remarked that, if the detection of the IPv4-only device or application is done incorrectly (either not detecting it or by a false detection), no harm is caused. In the worst case, optimization will not be performed, at least, at the time being. However, optimization maybe performed later on, if a new detection succeeds (for example, another device using the same A record).4.2.2. Detection of IPv6-enabled service In the case of an IPv4-only detected device or application, the DNS proxy/stub resolver MUST actually perform an additional AAAA query, unless the information is already present in the Additional Section, as perSection 3 of [RFC3596]. Note that the NAT46/CLAT MUST already know the WKP or NSP being used in that network. If the response contains at least one IPv6 address not using the WKP/NSP, it means that the destination is IPv6-enabled (because at least one of the IPv6 addresses is not synthesized). This means that it is possible for the NAT46/CLAT, to create an Explicit Address Mapping ([RFC7757]).4.2.3. Creation of EAMT entries This way, an EAM Table (EAMT used for short, across the rest of this document) is created/maintained automatically by the DNS proxy/stub resolver in the NAT46/CLAT, and the NAT46/CLAT is responsible to prioritize any available entries in the EAMT, versus the use of any synthetic AAAA. In order to create the EAMT entry, to determine if there is an AAAA record after an A record query, it is suggested to use the same delay value (50 milliseconds) as the "Resolution Delay" indicated by Happy Eyeballs [RFC8305]. This avoids a slight NAT64 overload and flapping between destination addresses (IPv4/IPv6), which may impact some applications, at the cost of a small extra delay for the initial communication setup, when the EAMT entry doesn't yet exist. 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 (IPv6Palet Martinez & D'EgidioExpires January 9, 2020 [Page 8]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 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. 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. 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- proxy or similar functionality is being used by the IPv6-enabled service. In this case, the existing EAMT entry will be marked as "Invalid" (bit set). No new EAMT entry is created for that IPv4 address. Otherwise, the optimization will only allow to access the first set of IPv4/IPv6/FQDN, which may break the access to other FQDN that share the same IPv4 address and different IPv6 addresses. In this case the EAMT entry will still expire according the TTL, 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 persection 3.1 of [RFC7757].Palet Martinez & D'EgidioExpires January 9, 2020 [Page 9]
Internet-Draft 464XLAT/NAT46 Optimization July 20194.2.4. Forwarding path 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.4.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.4.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 Operator already has a specific route to 2001:db8::a:b:c:d The following is an example of the CE behavior after the previous case has already created an EAMT entry and a reverse-proxy is detected: 1. A query for www.another-example.com A RR is received 2. www.another-example.com A 192.0.2.1 3. www.another-example.com AAAA 2001:db8::e:e:f:f 4. A conflict has been detected 5. The existing EAMT entry for 192.0.2.1 is set as invalid4.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.Palet Martinez & D'EgidioExpires January 9, 2020 [Page 10]
Internet-Draft 464XLAT/NAT46 Optimization July 20194.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 inSection 4.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.4.2.9. Behavior when using literal addreses 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.4.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, including the EAMT entry and consequently IPv6, so this mechanism will be correcting an undesirable behavior. This is a special case, which actually seems to be an incoherent host or application implementation. However, if other IPv4-only devices or applications subsequently need to connect to the same IPv6-enabled service, they will take advantage of the already existing EAMT entry, and consequently use the IPv6-optimised path.4.2.11. Behaviour in presence of Happy Eyeballs Happy Eyeballs [RFC8305] is only available in dual-stack hosts. Consequently, is not affected by this mechanism because both, the A and the AAAA queries should be issued by the host as soon after one another as possible. However, if the same NAT46/CLAT/CE is serving IPv4-only hosts and dual-stack hosts and both of them are using the same destinations, an EAMT entry will be created for that destination. Consequently, a Happy Eyeballs fallback to IPv4 willPalet Martinez & D'EgidioExpires January 9, 2020 [Page 11]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 actually be using the relevant EAMT entry IPv6 destination. This has the disadvantage that the IPv4-IPv6-IPv4 translation path can't be used by Happy Eyeballs-enabled applications. However, this may be 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 optimization.4.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: 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. 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.Palet Martinez & D'EgidioExpires January 9, 2020 [Page 12]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 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 resolver. Note that it may be affected if the operator offers different "DNS views" or "split DNS", however this is not related to this optimization and will anyway impact in the other possible operator optimizations (i.e. CDN/cache features). e. Combinations of the above ones. No further impact, than the one already described, is observed.4.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution Instead of using the DNS proxy/stub resolver to create the EAMT entries, the operator may push this table (or parts of it) into the CE/NAT46/CLAT, by using configuration/management mechanisms. This solution has the advantage of not being affected by any DNS changes from the user (the EAMT is created by the operator) and ensures a complete control from the operator. However, it may impact the cases of devices with a DNS configured by the vendor. In general, most of the considerations from the previous approach will apply. One more advantage of this solution is that the EAMT pairs doesn't need to match the "real" IPv4/IPv6 addresses available in the A/AAAA records, as shown in the next example. www.example.com A 192.0.2.1 AAAA 2001:db8::a:b:c:d EAMT pulled/pushed entry 192.0.2.1 2001:db8::f:e:d:c NAT46/CLAT translated to 2001:db8::f:e:d:c CDN IPv6 interface already is 2001:db8::f:e:d:c Operator already has a specific route to 2001:db8::f:e:d:c EAMT may contain TTLs which probably are derived from DNS ones, or alternatively, a global TTL for the full table. An alternative way to configure the table, is that the CE is actually pulling the table (or parts of it) from the operator infrastructure. In this case it will be mandatory that the entries have individual TTLs, again probably derived from the DNS ones. The major drawback of this approach is that it requires a new protocol, or an extension to existing ones, in order to push or pull the EAMT, in addition to the possible impact in terms of bandwidthPalet Martinez & D'EgidioExpires January 9, 2020 [Page 13]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 each time the CEs reboot, or an EAMT must be pushed to all the CEs, etc.5. 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 4.2) is chosen, it can be complemented to resolve this issue, by means of making sure that IPv6-only destinations have one A resource record (even an invalid one), despite they aren't actually connected to IPv4. This will mean that those services will work fine if there is a NAT46/CLAT, and will have no impact if that one doesn't exist, not a different situation than not having an A resource record. 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 resource record, that points to a "universal" web page (maybe hosted by IETF?) that displays a warning such as "Sorry, you don't IPv6 support in your operator, so this service is not available for you".6. Conclusions NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right solution for optimizing the access to dual-stack services, whether they are located inside or outside the ISP. 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 solutionPalet Martinez & D'EgidioExpires January 9, 2020 [Page 14]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 approach.7. Security Considerations This document does not have any new specific security considerations.8. IANA Considerations This document does not have any new specific IANA considerations, unless we decide to define a "special reserved IPv4 address".9. Acknowledgements The authors would like to acknowledge the inputs of Erik Nygren, Fred Baker, Martin Hunek and TBD ...10. References10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88,RFC 3596, DOI 10.17487/RFC3596, October 2003, <https://www.rfc-editor.org/info/rfc3596>. [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, <https://www.rfc-editor.org/info/rfc6052>. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers",RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers",RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.Palet Martinez & D'EgidioExpires January 9, 2020 [Page 15]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation",RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/info/rfc6877>. [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)",RFC 7599, DOI 10.17487/RFC7599, July 2015, <https://www.rfc-editor.org/info/rfc7599>. [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation",RFC 7757, DOI 10.17487/RFC7757, February 2016, <https://www.rfc-editor.org/info/rfc7757>. [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm",RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://www.rfc-editor.org/info/rfc7915>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase inRFC2119 Key Words",BCP 14,RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency",RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.10.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-06 (work in progress), March 2019. [I-D.ietf-v6ops-nat64-deployment] Palet, J., "Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks",draft-ietf-v6ops-nat64-deployment-06 (work in progress), May 2019. [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, <https://www.rfc-editor.org/info/rfc7858>.Palet Martinez & D'EgidioExpires January 9, 2020 [Page 16]
Internet-Draft 464XLAT/NAT46 Optimization July 2019 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)",RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>. [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)",RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.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/ Alejandro D'Egidio Telecentro Argentina Email: adegidio@telecentro.net.arPalet Martinez & D'EgidioExpires January 9, 2020 [Page 17]
draft-palet-v6ops-464xlat-opt-cdn-caches-03
| Document | Document type | This is an older version of an Internet-Draft whose latest revision state is "Replaced". This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process. | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors | Jordi Palet Martinez,Alejandro D'Egidio | ||
| Replaced by | draft-ietf-v6ops-464xlat-optimization draft-ietf-v6ops-464xlat-optimization | ||
| RFC stream | (None) | ||
| Other formats |