464XLAT Optimization for CDNs/Caches
draft-palet-v6ops-464xlat-opt-cdn-caches-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Jordi Palet Martinez | ||
| Last updated | 2019-03-06 | ||
| Replaced by | draft-ietf-v6ops-464xlat-optimization, draft-ietf-v6ops-464xlat-optimization | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-palet-v6ops-464xlat-opt-cdn-caches-00
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
Abstract
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.
Status of This Memo
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 Notice
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
Palet Martinez Expires September 7, 2019 [Page 1]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. DNS/Routing-based Solution Approach . . . . . . . . . . . . . 5
4. CLAT/DNS-proxy-EAMT-based Solution Approach . . . . . . . . . 6
5. CLAT-provider-EAMT-based Solution Approach . . . . . . . . . 7
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. 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 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.
Palet Martinez Expires September 7, 2019 [Page 2]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
+-------+ .-----. .-----.
| 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.
Palet Martinez Expires September 7, 2019 [Page 3]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
+-------+ .-----. .-----.
| 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
Palet Martinez Expires September 7, 2019 [Page 4]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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
2. 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 in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. DNS/Routing-based Solution Approach
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
Palet Martinez Expires September 7, 2019 [Page 5]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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.
4. CLAT/DNS-proxy-EAMT-based Solution Approach
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,
Palet Martinez Expires September 7, 2019 [Page 6]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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.
5. CLAT-provider-EAMT-based Solution Approach
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.
6. Conclusions
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.
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.
9. Acknowledgements
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.
Palet Martinez Expires September 7, 2019 [Page 7]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
10. 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>.
[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>.
[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 in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Palet Martinez Expires September 7, 2019 [Page 8]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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
URI: http://www.theipv6company.com/
Palet Martinez Expires September 7, 2019 [Page 9]