464XLAT Optimization for CDNs/Caches
draft-palet-v6ops-464xlat-opt-cdn-caches-01
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".
|
|
|---|---|---|---|
| Authors | Jordi Palet Martinez , Alejandro D'Egidio | ||
| Last updated | 2019-03-25 | ||
| Replaced by | draft-ietf-v6ops-464xlat-optimization, draft-ietf-v6ops-464xlat-optimization | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-01
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
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 26, 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
Palet Martinez & D'EgidExpires September 26, 2019 [Page 1]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
the Trust Legal Provisions and are provided without warranty as
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. IPv6-only Services become accessible to IPv4-only
devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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 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.
Palet Martinez & D'EgidExpires September 26, 2019 [Page 2]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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
Palet Martinez & D'EgidExpires September 26, 2019 [Page 3]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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
Palet Martinez & D'EgidExpires September 26, 2019 [Page 4]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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
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
Palet Martinez & D'EgidExpires September 26, 2019 [Page 5]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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.
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 (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:
Palet Martinez & D'EgidExpires September 26, 2019 [Page 6]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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.
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 (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
Palet Martinez & D'EgidExpires September 26, 2019 [Page 7]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
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.
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.
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".
7. Conclusions
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.
Palet Martinez & D'EgidExpires September 26, 2019 [Page 8]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
8. Security Considerations
This document does not have any new specific security considerations.
TBD.
9. IANA Considerations
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 and TBD ...
11. 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>.
[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>.
Palet Martinez & D'EgidExpires September 26, 2019 [Page 9]
Internet-Draft 464XLAT Optimization for CDNs/Caches March 2019
[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>.
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.ar
Palet Martinez & D'EgidExpires September 26, 2019 [Page 10]