| v6ops | J. Palet Martinez |
| Internet-Draft | The IPv6 Company |
| Intended status: Informational | A. D'Egidio |
| Expires: September 26, 2019 | Telecentro |
| March 25, 2019 |
464XLAT Optimization for CDNs/Caches
draft-palet-v6ops-464xlat-opt-cdn-caches-01
This document describes the drawbacks of IP/ICMP Translation Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or applications initiate traffic flows to dual-stack CDNs (Content Delivery Networks) or Caches, which are forced to be translated back to IPv4 by a NAT64. The document proposes possible solutions to avoid that.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 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 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 September 26, 2019.
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 described in the Simplified BSD License.
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 typically called CLAT (Customer Translator).
The CLAT is then connected by IPv6-only to the operator network, which in turn, will have a reverse function, the NAT64 ([RFC6146]), also called PLAT (Provider Translator), in order to be able to translate back the IPv6-only flow 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].
Optionally, a DNS64 ([RFC6147]) 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 | `--+--´ \ .-----. `-----´
\ / | | | \ / \
`-----´ | 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) or caches, and they are dual-stacked, the situation can be described as shown in Figure 2.
+-------+ .-----. .-----.
| IPv6 | / \ / \
.-----. | CE | / IPv6- \ .-----. / IPv4 \
/ \ | or +--( only )---( NAT64 )---( Internet )
/ LAN's \ | UE | \ Access /\ `-----´ \ /
( Dual- )--+ | \ / \ \ /
\ Stack / | with | `--+--´ \ .-----. `--+--´
\ / | | | \ / \ \
`-----´ | CLAT | +---+----+ / IPv6 \ .--+--.
| | | DNS/ | ( Internet ) / Dual- \
+-------+ | DNS64 | \ /----/ Stack \
+--------+ \ / ( )
`-----´ \ CDNs/ /
\ Caches/
`-----´
Figure 2: Typical 464XLAT Deployment with CDNs/Caches
If the devices or applications in the customer LAN are IPv6-capable, then the access to the CDNs or caches will be made by means of IPv6-only, not using the NAT64, as depicted in Figure 3.
+-------+ .-----. .-----.
| IPv6 | / \ / \
.-----. | CE | / IPv6- \ .-----. / IPv4 \
/ \ | or +--( only )---( NAT64 )---( Internet )
/ IPv6 \ | UE | \ Access /\ `-----´ \ /
( capable )--+ | \ / \ \ /
\ apps / | with | `--+--´ \ .-----. `--+--´
\ / | | | \ / \
`-----´ | 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 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 / | | | \ / \ \ 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 CLAT translated IPv6 traffic flow is forced to be translated back to IPv4, traversing the stateful NAT64, impacting in the need to scale it beyond what will be needed if we consider possible solutions in order to keep using the IPv6 path towards those services.
As show in the preceding picture, 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, but is not commonly yet the case for many VoIP devices or applications. This is true as well for many other dual-stack services, which may be directly reachable from the operator infrastructure, even if not part of it, for example peering agreements, services in IXs, etc.
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 / | | | \ / \
`-----´ | 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 apps
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 in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Because the IPv4-only devices will not be able to query for AAAA records, the NAT46/CLAT will translate the IPv4 addresses from the A record for the CDN/cache destination, using the WKP or NSP, as configured by the operator.
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 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 per Section 2.3 of [RFC6052].
Because the WKP is non-routable, this will only be possible if the CDN/cache is in the same ASN as the provider network, or somehow interconnected without routing to Internet.
How to handle IP address changes in the CDN. CDN operational issues/complexity. TBD.
If the CLAT, as commonly is the case, is also a DNS proxy/stub resolver, it may be possible to modify the behavior, so when there is a query for an A record, and there is not a query for the AAAA record from the same source (to the same destination), the DNS resolver can actually perform an AAAA, unless the information is already present in the Additional Section, as per Section 3 of [RFC3596]. If the response doesn’t contain the WKP or NSP, it means that the destination is IPv6-capable, so the CLAT can create/update an entry for an Explicit Address Mapping [RFC7757].
This way, an EAMT is maintained automatically by the DNS proxy/stub resolver in the CLAT, and the CLAT is responsible to prioritize any available entries in the EAMT, versus the use of the synthetic AAAA.
Following this approach, the IPv6-native path will take precedence and traffic will not be forwarded to the NAT64.
Using the same example as in the previous section:
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
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
This approach will allows using the existing IPv4 and IPv6 addresses in the A and AAAA records, respectively.
This mechanism will not work if the devices are configured to use a DNS proxy/resolver which is not the CE/CLAT, but will not impact negatively in the user’s applications (optimization is disabled). However, users commonly, don't change the configuration of devices such as SmartTVs or STBs (if they do, some other functionalities may not work).
It is common that users modify the DNS either in the operating systems (which commonly are dual-stack, so aren't part of the problem being described by this document), or the CE. In the case the DNS servers are modified in the CE, this mechanism is not adversely affected, unless the operator offers different "DNS view", which in any case will be affected also by the "user-misconfigured" CE.
The information in the EAMT MUST be kept timely-synchronized with the A records TTL's. TBD.
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/CLAT, by using configuration/management mechanisms.
This solution has the advantage of not being affected by any DNS changes from the user and ensures a complete control from the operator.
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
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.
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.
A possible solution approach, when the customer network or device has a NAT46 (CLAT or equivalent), is to ensure that the IPv6-only destinations have A Resource Records, even if those aren't real ones. This will mean that those services will work fine if there is a 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".
CLAT/DNS-proxy-EAMT Approach seems the right solution (TBC). SIIT already has a SHOULD for EAMT support. So, 464XLAT may be updated by this document so the CLAT has a MUST for EAMT support.
Should we recommend having A “null” records for IPv6-only services in Internet? A web page IPv4-only hosted by IETF(?) showing “sorry this web page/service is only available from IPv6 enabled operators”?.
TBD. Risks to consider. Because the apps are IPv4-only, Happy Eyeballs will not be able to support breakage situations. If a CE is misconfigured, even a small percentage of broken CEs 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.
TBD.
This document does not have any new specific security considerations. TBD.
This document does not have any new specific IANA considerations.
The authors would like to acknowledge the inputs of Erik Nygren, Fred Baker and TBD ...