[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/