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

Versions: 00 01 02 03 04

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]


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