| v6ops | J. Palet Martinez |
| Internet-Draft | The IPv6 Company |
| Intended status: Informational | March 6, 2019 |
| Expires: September 7, 2019 |
464XLAT Optimization for CDNs/Caches
draft-palet-v6ops-464xlat-opt-cdn-caches-00
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 7, 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 a 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, this is not useful in the case of IPv4-only devices or applications in the LANs.
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 precedent 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 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 again 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 precedent picture, this is also the case for 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 the case for many VoIP devices or applications.
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 routed 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
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 changes in the CDN. 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, the DNS resolver can actually "force" the AAAA query. 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::192.0.2.1
EAMT entry 192.0.2.1 2001:db8::192.0.2.1
CLAT translated to 2001:db8::192.0.2.1
CDN IPv6 interface already is 2001:db8::192.0.2.1
Operator already has a specific route to 2001:db8::192.0.2.1
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. However, users commonly, don't change the configuration of devices such as SmartTVs or STBs (if they do, some 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.
Instead of using the DNS proxy/stub resolver to create the EAMT entries, the operator may push this table into the CE/CLAT, by using configuration/management mechanisms. TBD.
This solution has the advantage of not being affected by any DNS changes from the user and ensures a complete control from the operator.
TBD.
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.
This document does not have any new specific IANA considerations.
The authors would like to acknowledge the inputs of Erik Nygren and TBD ...
Alejandro D'Egidio inspired working in this document by wondering if 464XLAT traffic to CDNs could be optimized in discussions in the v6ops mailing list.