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

Versions: 00 01 02 draft-ietf-v6ops-nat64-deployment

v6ops                                                  J. Palet Martinez
Internet-Draft                                          The IPv6 Company
Intended status: Best Current Practice                     March 4, 2018
Expires: September 5, 2018


    NAT64 Deployment Guidelines in Operator and Enterprise Networks
                 draft-palet-v6ops-nat64-deployment-00

Abstract

   This document describes how NAT64 ([RFC6146]) can be deployed in an
   IPv6 operator or enterprise network and the issues to be considered
   when having an IPv6-only access link, regarding: a) DNS64
   ([RFC6147]), b) applications or devices that use literal IPv4
   addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or
   applications.

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 5, 2018.

Copyright Notice

   Copyright (c) 2018 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 5, 2018               [Page 1]


Internet-Draft              NAT64 Deployment                  March 2018


   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  DNSSEC Considerations . . . . . . . . . . . . . . . . . . . .   3
   3.  NAT64 Deployment Scenarios  . . . . . . . . . . . . . . . . .   4
     3.1.  Service Provider NAT64 without DNS64  . . . . . . . . . .   5
     3.2.  Service Provider NAT64 with DNS64 . . . . . . . . . . . .   6
     3.3.  Service Provider NAT64; DNS64 in the IPv6 hosts . . . . .   7
     3.4.  Service Provider NAT64; DNS64 in the IPv4-only     remote
           network . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.5.  Service Provider offering 464XLAT, without DNS64  . . . .   9
     3.6.  Service Provider offering 464XLAT, with DNS64 . . . . . .  10
   4.  Possible Solutions to the DNSSEC Issue  . . . . . . . . . . .  10
     4.1.  Not using DNS64 . . . . . . . . . . . . . . . . . . . . .  11
     4.2.  DNSSEC validator aware of DNS64 . . . . . . . . . . . . .  11
     4.3.  Stub validator  . . . . . . . . . . . . . . . . . . . . .  11
     4.4.  CLAT with DNS proxy and validator . . . . . . . . . . . .  12
     4.5.  ACL of clients  . . . . . . . . . . . . . . . . . . . . .  12
     4.6.  Mapping-out IPv4 addresses  . . . . . . . . . . . . . . .  12
   5.  DNS64 and Reverse Mapping Considerations  . . . . . . . . . .  13
   6.  Issue with IPv4 literals and old APIs . . . . . . . . . . . .  13
   7.  Issue with IPv4-only Hosts or Applications  . . . . . . . . .  13
   8.  Using 464XLAT with/without DNS64  . . . . . . . . . . . . . .  13
   9.  Manual Configuration of Foreign DNS . . . . . . . . . . . . .  14
   10. CLAT Translation Considerations . . . . . . . . . . . . . . .  14
   11. Summary of Deployment Recommendations for NAT64 . . . . . . .  15
   12. Deployment of NAT64 in Enterprise Networks  . . . . . . . . .  16
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  17
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   15. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   16. Normative References  . . . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation,
   which allows IPv6-only hosts to contact IPv4 servers using unicast
   UDP, TCP or ICMP, by means of a single or a set of IPv4 public
   addresses assigned to the translator, to be shared by the IPv6-only
   clients.

   The translation of the packet headers is done using the IP/ICMP
   Translation Algorithm defined in [RFC7915] and algorithmically
   translating the IPv4-hosts addresses to IPv6 ones following
   [RFC6052].




Palet Martinez          Expires September 5, 2018               [Page 2]


Internet-Draft              NAT64 Deployment                  March 2018


   To avoid changes in both, the IPv6-only hosts and the IPv4-only
   server, NAT64 requires also the use of a DNS64 ([RFC6147]), in charge
   for the synthesis of AAAA records from the A records.

   However, the use of NAT64 and/or DNS64 present three issues:

   a.  Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is
       designed to detect such modifications, DNS64 ([RFC6147]) can
       potentially break DNSSEC, depending on a number of factors, such
       as the location of the DNS64 function (at a DNS server or
       validator, at the end host, ...), how as been configured, if the
       end-hosts is validating, etc.

   b.  Because the need of using DNS64 ([RFC6147]), there is a major
       issue for NAT64 ([RFC6146]), as doesn't work when literal
       addresses or non-IPv6 compliant APIs are being used.

   c.  NAT64 alone, doesn't provide a solution for IPv4-only hosts or
       applications located within a network which are connected to a
       service provider IPv6-only access.

   The same issues are true if part of an enterprise or similar network,
   is connected to other parts of the same network or third party
   networks by means of IPv6-only links.

   According to that, across this document, the use of "operator
   network" is interchangeable with equivalent cases of enterprise (or
   similar) networks.

   This document looks into different possible NAT64 ([RFC6146])
   deployment scenarios in operators and enterprise networks, and
   provides guidelines to avoid the above mentioned issues.

2.  DNSSEC Considerations

   As indicated in Section 8 of [RFC6147] (DNS64, Security
   Considerations), because DNS64 modifies DNS answers and DNSSEC is
   designed to detect such modifications, DNS64 can break DNSSEC.

   If a device connected to an IPv6-only WAN queries for a domain name
   in a signed zone, by means of a recursive name server that supports
   DNS64, and the result is a synthesized AAAA record, and the recursive
   name server is configured to perform DNSSEC validation and has a
   valid chain of trust to the zone in question, it will
   cryptographically validate the negative response from the
   authoritative name server.  So, the recursive name server actually
   lie to the client device, however in most of the cases, the client
   will not notice it, because generally they don't perform validation



Palet Martinez          Expires September 5, 2018               [Page 3]


Internet-Draft              NAT64 Deployment                  March 2018


   themselves as instead rely on their recursive name servers.

   If the client device performs DNSSEC validation on the AAAA record,
   it will fail as it is a synthesized record.

   Similarly, if the client querying the recursive name server is
   another name server configured to use it as a forwarder, and is
   performing DNSSEC validation, it will also fail on any synthesized
   AAAA record.

   The obvious solution to avoid DNSSEC issues, will be that all the
   signed zones also provide IPv6 connectivity, together with the
   corresponding AAAA records.  Previous data seems to indicate, that
   the figures of DNSSEC broken by using DNS64 will be around 1.7%
   (information 2 years old).

3.  NAT64 Deployment Scenarios

   Section 7 of DNS64 ([RFC6147]), provides 3 scenarios, looking at the
   location of the DNS64.  However, since the publication of that
   document, there are new possible scenarios and NAT64 use cases that
   need to be considered.

   The perspective in this document is to broader those scenarios,
   including a few new ones.  However, in order to be able to reduce the
   number of possible cases, we work under the assumption that the
   service provider want to make sure that all the customers have a
   service without failures.  This means considering the worst possible
   case:

   a.  There are hosts that will be validating DNSSEC.

   b.  Literal addresses and non-IPv6 compliant APIs are being used.

   c.  There are IPv4-only hosts or applications beyond the IPv6-only
       link.

   We use a common set of possible "participant entities":

   1.  An IPv6-only access network (IPv6).

   2.  An IPv4-only remote network (IPv4).

   3.  The NAT64 of the service provider (NAT64).

   4.  The DNS64 function (DNS64).

   5.  An external service provider offering the NAT64 and/or the DNS64



Palet Martinez          Expires September 5, 2018               [Page 4]


Internet-Draft              NAT64 Deployment                  March 2018


       function (extNAT64/extDNS64).

   6.  464XLAT customer side translator (CLAT).

3.1.  Service Provider NAT64 without DNS64

   In this scenario, the service provider offers a NAT64, however there
   is no DNS64 function support.

   As a consequence, an IPv6 host in the IPv6-only access network, will
   not be able to detect the presence of DNS64 neither learning the IPv6
   prefix to be used for the NAT64.

   This can be sorted out as indicated in Section 4.1.

   However, despite that, because the lack of the DNS64 function, the
   IPv6 host will not be able to obtain AAAA synthesised records, so the
   NAT64 becomes useless.

   An exception to this "useless" scenario will be manually configure
   mappings between the A records of each of the IPv4-only remote hosts
   and the corresponding AAAA records, with the WKP (Well-Known Prefix)
   or NSP (Network-Specific Prefix) used by the service provider NAT64,
   as if they were synthesised by a DNS64.

   This mapping could be done by several means, typically at the
   authoritative DNS server, or at the service provider resolvers by
   means of DNS RPZ (Response Policy Zones).  The latest, may have
   implications in DNSSEC, if the zone is signed.  Also, if the service
   provider is using a NSP, having the mapping at the authoritative
   server, will mean that may create troubles to other parties trying to
   use different NSP or the WKP, unless multiple DNS "views" are also
   being used at the authoritative servers.

   Generally, the mappings alternative, will only make sense if a few
   set of IPv4-only remote hosts need to be accessed by a single network
   or reduced set of them, which support IPv6-only in the access, with
   some kind of mutual agreement for using this procedure, so it doesn't
   care if they become a trouble for other parties across Internet
   ("closed services").

   In any case, this scenario doesn't solve the issue of literal
   addresses or non-IPv6 compliant APIs, neither it solves the problem
   of IPv4-only hosts within that IPv6-only access network.







Palet Martinez          Expires September 5, 2018               [Page 5]


Internet-Draft              NAT64 Deployment                  March 2018


   +----------+        +----------+        +----------+
   |          |        |          |        |          |
   |   IPv6   +--------+  NAT64   +--------+   IPv4   |
   |          |        |          |        |          |
   +----------+        +----------+        +----------+

                 Figure 1: Scenario of NAT64 without DNS64

3.2.  Service Provider NAT64 with DNS64

   In this scenario, the service provider offers both, the NAT64 and the
   DNS64 function.

   This is probably the most common scenario, however also has the
   implications related the DNSSEC.

   This scenario also fails to solve the issue of literal addresses or
   non-IPv6 compliant APIs, as well as the issue of IPv4-only hosts or
   applications inside the IPv6-only access network.

   +----------+        +----------+        +----------+
   |          |        |  NAT64   |        |          |
   |   IPv6   +--------+    +     +--------+   IPv4   |
   |          |        |  DNS64   |        |          |
   +----------+        +----------+        +----------+

                  Figure 2: Scenario of NAT64 with DNS64

   A totally equivalent scenario will be if the service provider offers
   only the DNS64 function, and the NAT64 function is provided by an
   agreement with an external provider.  All the considerations in the
   previous paragraphs of this section are the same for this sub-case.

                       +----------+
                       |          |
                       | extNAT64 |
                       |          |
                       +----+-----+
                            |
                            |
   +----------+        +----+-----+        +----------+
   |          |        |          |        |          |
   |   IPv6   +--------+  DNS64   +--------+   IPv4   |
   |          |        |          |        |          |
   +----------+        +----------+        +----------+

      Figure 3: Scenario of DNS64; NAT64 in external service provider




Palet Martinez          Expires September 5, 2018               [Page 6]


Internet-Draft              NAT64 Deployment                  March 2018


   As well, is equivalent to the scenario where the agreement with the
   external provider is to provide both the NAT64 and DNS64 function.
   Once more, all the considerations in the previous paragraphs of this
   section are the same for this sub-case.

                       +----------+
                       | extNAT64 |
                       |    +     |
                       | extDNS64 |
                       +----+-----+
                            |
   +----------+             |              +----------+
   |          |             |              |          |
   |   IPv6   +-------------+--------------+   IPv4   |
   |          |                            |          |
   +----------+                            +----------+

        Figure 4: Scenario of NAT64 and DNS64 in external provider

3.3.  Service Provider NAT64; DNS64 in the IPv6 hosts

   In this scenario, the service provider offers the NAT64, but not the
   DNS64.  However, the IPv6 hosts have a built-in DNS64 function.

   This may become common if the DNS64 function is implemented in all
   the IPv6 hosts/stacks, which is not the actual situation.  At this
   way, the DNSSEC validation is performed on the A record, and then the
   host can use the DNS64 function so to be able to use the NAT64,
   without any DNSSEC issues.

   This scenario fails to solve the issue of literal addresses or non-
   IPv6 compliant APIs, unless the IPv6 hosts also supports Happy
   Eyeballs v2 ([RFC8305]), which may solve that issue.

   However, this scenario still fails to solve the problem of IPv4-only
   hosts or applications inside the IPv6-only access network.

   +----------+        +----------+        +----------+
   |   IPv6   |        |          |        |          |
   |     +    +--------+  NAT64   +--------+   IPv4   |
   |   DNS64  |        |          |        |          |
   +----------+        +----------+        +----------+

             Figure 5: Scenario of NAT64; DNS64 in IPv6 hosts







Palet Martinez          Expires September 5, 2018               [Page 7]


Internet-Draft              NAT64 Deployment                  March 2018


3.4.  Service Provider NAT64; DNS64 in the IPv4-only remote network

   In this scenario, the service provider offers the NAT64 only.  The
   remote IPv4-only network offers the DNS64 function.

   This is not common, and looks like doesn't make too much sense that a
   remote network, not deploying IPv6, is providing a DNS64 function and
   as, in the case of the scenario depicted in Section 3.1, it will only
   work if both sides are using the WKP or the same NSP, etc., so the
   same considerations apply.

   This scenario still fails to solve the issue of literal addresses or
   non-IPv6 compliant APIs.

   This scenario also fails to solve the problem of IPv4-only hosts or
   applications inside the IPv6-only access network.

   +----------+        +----------+        +----------+
   |          |        |          |        |   IPv4   |
   |   IPv6   +--------+  NAT64   +--------+     +    |
   |          |        |          |        |   DNS64  |
   +----------+        +----------+        +----------+

            Figure 6: Scenario of NAT64; DNS64 in the IPv4-only

   A totally equivalent scenario will be if the service provider offers
   the NAT64 only, and the DNS64 function is provided by an external
   provider without an specific agreement among them.  This is an
   scenario already feasible today, as several "global" service
   providers provide open DNS64 services and users often configure
   manually their DNS.  All the considerations in the previous
   paragraphs of this section are the same for this sub-case.

   If the user instead of configuring a DNS64 uses a regular external
   DNS, the situation is even much worst, because in that case, NAT64
   will not work at all with any IPv4-only remote host.

   However, if the external DNS64 is agreed with the service provider,
   then we are in the same case, in terms of considerations of issues,
   as in Section 3.2.











Palet Martinez          Expires September 5, 2018               [Page 8]


Internet-Draft              NAT64 Deployment                  March 2018


                       +----------+
                       |          |
                       | extDNS64 |
                       |          |
                       +----+-----+
                            |
                            |
   +----------+        +----+-----+        +----------+
   |          |        |          |        |          |
   |   IPv6   +--------+  NAT64   +--------+   IPv4   |
   |          |        |          |        |          |
   +----------+        +----------+        +----------+

          Figure 7: Scenario of NAT64; DNS64 by external provider

3.5.  Service Provider offering 464XLAT, without DNS64

   464XLAT ([RFC6877]) describes an architecture that provides IPv4
   connectivity across a network, or part of it, when it is only
   natively transporting IPv6.

   In order to do that, 464XLAT ([RFC6877]) relies on the combination of
   existing protocols:

   1.  The customer-side translator (CLAT) is a stateless IPv4 to IPv6
       translator (NAT46) ([RFC7915]) implemented in the end-user device
       or CE, located at the "customer" edge of the network.

   2.  The provider-side translator (PLAT) is a stateful NAT64
       ([RFC6146]), implemented typically at the opposite edge of the
       operator network, that provides access to both IPv4 and IPv6
       upstreams.

   3.  Optionally, DNS64 ([RFC6147]), implemented as part of the PLAT
       allows an optimization (a single translation at the NAT64,
       instead of two translations - NAT46+NAT64), when the application
       at the end-user device supports IPv6 DNS (uses AAAA RR).

   In this scenario, using 464XLAT without DNS64, the service provider
   ensures that DNSSEC is not broken.

   464XLAT ([RFC6877]) is a very simple approach to cope with the major
   NAT64+DNS64 drawback: Not working with applications or devices that
   use literal IPv4 addresses or non-IPv6 compliant APIs.

   464XLAT ([RFC6877]) has been used initially in IPv6 cellular
   networks, so providing an IPv6-only access network, the end-user
   device applications can access IPv4-only end-networks/applications,



Palet Martinez          Expires September 5, 2018               [Page 9]


Internet-Draft              NAT64 Deployment                  March 2018


   despite those applications or devices use literal IPv4 addresses or
   non-IPv6 compliant APIs.

   In addition to that, in the same example of the cellular network
   above, if the User Equipment (UE) provides tethering, other devices
   behind it will be presented with a traditional NAT44, in addition to
   the native IPv6 support, so clearly it allows IPv4-only hosts inside
   the IPv6-only access network.

   Furthermore, 464XLAT ([RFC6877]) can be used in non-cellular IPv6
   wired (xDSL, DOCSIS, FTTH, Ethernet, ...) and wireless (WiFi) network
   architectures, by implementing the CLAT functionality at the CE.

   +----------+        +----------+        +----------+
   |   IPv6   |        |          |        |          |
   |     +    +--------+  NAT64   +--------+   IPv4   |
   |   CLAT   |        |          |        |          |
   +----------+        +----------+        +----------+

               Figure 8: Scenario of 464XLAT, without DNS64

3.6.  Service Provider offering 464XLAT, with DNS64

   In this scenario the service provider deploys 464XLAT with DNS64.

   As a consequence, the DNSSEC issues remain.

   However, in this scenario, as in the previous one, there are no
   issues related to IPv4-only hosts inside the IPv6-only access
   network, neither to the usage of IPv4 literals or non-IPv6 compliant
   APIs.

   +----------+        +----------+        +----------+
   |   IPv6   |        |  NAT64   |        |          |
   |     +    +--------+    +     +--------+   IPv4   |
   |   CLAT   |        |  DNS64   |        |          |
   +----------+        +----------+        +----------+

                 Figure 9: Scenario of 464XLAT, with DNS64

4.  Possible Solutions to the DNSSEC Issue

   As already mention, the scenarios in the precious section, are in
   fact somehow simplified, looking at the worst case, because breaking
   DNSSEC will not happen, if the end-host is not doing validation, and/
   or some countermeasures are taken, depicted in the next sections.





Palet Martinez          Expires September 5, 2018              [Page 10]


Internet-Draft              NAT64 Deployment                  March 2018


4.1.  Not using DNS64

   The ideal solution will be to avoid using DNS64, but as already
   indicated this is not possible in all the scenarios.

   However, not having a DNS64, means that is not possible to
   heuristically discover the NAT64 ([RFC7050]) and consequently, an
   IPv6 host in the IPv6-only access network, will not be able to detect
   the presence of the DNS64, neither to learn the IPv6 prefix to be
   used for the NAT64.

   The learning of the IPv6 prefix could be solved by means of adding
   the relevant AAAA records to the ipv4only.arpa. zone of the service
   provider recursive servers, i.e., if using the WKP (64:ff9b::/96):

           ipv4only.arpa.  SOA     . . 0 0 0 0 0
           ipv4only.arpa.  NS      .
           ipv4only.arpa.  AAAA    64:ff9b::192.0.0.170
           ipv4only.arpa.  AAAA    64:ff9b::192.0.0.171
           ipv4only.arpa.  A       192.0.0.170
           ipv4only.arpa.  A       192.0.0.171

   An alternative option to the above, is the use of DNS RPZ (Response
   Policy Zones).

   One more alternative, only valid in environments with PCP support
   (for both the hosts or CEs and for the service provider network), to
   follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP).

4.2.  DNSSEC validator aware of DNS64

   In general, DNS servers with DNS64 function, by default, will not
   synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the
   query.  In this case, as only an A record is available, it means that
   the CLAT will take the responsibility, as in the case of literal IPv4
   addresses, to keep that traffic flow end-to-end as IPv4, so DNSSEC is
   not broken.  However, this will not work if a CLAT is not present as
   the hosts will not be able to use IPv4 (scenarios without 464XLAT).

4.3.  Stub validator

   If the DO flag is set and the client device performs DNSSEC
   validation, and the Checking Disabled (CD) flag is set for a query,
   as the DNS64 recursive server will not synthesize AAAA responses, the
   client could perform the DNSSEC validation with the A record and then
   may query the network for a NAT64 prefix ([RFC7050]) in order to
   synthesize the AAAA ([RFC6052]).  This allows the client device to
   avoid using the CLAT and still use NAT64 even with DNSSEC.



Palet Martinez          Expires September 5, 2018              [Page 11]


Internet-Draft              NAT64 Deployment                  March 2018


   If the end-host is IPv4-only, this will not work if a CLAT is not
   present (scenarios without 464XLAT).

   Some devices/OSs may implement, instead of CLAT, a simliar function
   by using Bump-in-the-Host ([RFC6535]).  In this case, the
   considerations in the above paragraphs are also applicable.

4.4.  CLAT with DNS proxy and validator

   If a CE includes CLAT support and also a DNS proxy, as indicated in
   Section 6.4 of [RFC6877], the CE could behave as a stub validator on
   behalf of the client devices, following the same approach described
   in the precedent section (Stub validator).  So the DNS proxy actually
   lie to the client devices, which in most of the cases will not notice
   it unless they perform validation themselves.  Again, this allow the
   clients devices to avoid using the CLAT and still use NAT64 with
   DNSSEC.

   Once more, this will not work without a CLAT (scenarios without
   464XLAT).

4.5.  ACL of clients

   In cases of dual-stack clients, stub resolvers should send the AAAA
   queries before the A ones.  So such clients, if DNS64 is enabled,
   will never get A records, even for IPv4-only servers, and they may be
   in the path before the NAT64 and accesible by IPv4.  If DNSSEC is
   being used for all those flows, specific addresses or prefixes can be
   left-out the DNS64 synthesis by means of ACLs.

   Once more, this will not work without a CLAT (scenarios without
   464XLAT).

4.6.  Mapping-out IPv4 addresses

   If there are well-known specific IPv4 addresses or prefixes using
   DNSSEC, they can be mapped-out of the DNS64 synthesis.

   Even if this is not related to DNSSEC, this "mapping-out" feature is
   actually quite commonly used to ensure that [RFC1918] addresses (for
   example used by LAN servers) are not synthesized to AAAA.

   Once more, this will not work without a CLAT (scenarios without
   464XLAT).







Palet Martinez          Expires September 5, 2018              [Page 12]


Internet-Draft              NAT64 Deployment                  March 2018


5.  DNS64 and Reverse Mapping Considerations

   When a client device, using a name server configured to perform
   DNS64, tries to reverse-map a synthesized IPv6 address, the name
   server responds with a CNAME record pointing the domain name used to
   reverse-map the synthesized IPv6 address (the one under ip6.arpa), to
   the domain name corresponding to the embedded IPv4 address (under in-
   addr.arpa).

   This is the expected behaviour, so no issues to be considered
   regarding DNS reverse mapping.

6.  Issue with IPv4 literals and old APIs

   A hosts or application using literal IPv4 addresses or older APIs,
   behind a network with IPv6-only access, will not work unless a CLAT
   is present.

   A possible alternative approach is described as part of Happy
   Eyeballs v2 Section 7.1 ([RFC8305]), or if not supporting HEv2,
   directly using Bump-in-the-Host ([RFC6535]), and then a DNS64
   function.

   Those alternatives will solve the problem for and end-hosts, however,
   if that end-hosts is providing "tethering" or an equivalent service
   to others hosts, that need to be considered as well.  In other words,
   in a case of a cellular network, it resolves the issue for the
   cellular device itself, but may be not for hosts behind it.

   Otherwise, 464XLAT is the only valid approach to resolve this issue.

7.  Issue with IPv4-only Hosts or Applications

   An IPv4-only hosts or application behind a network with IPv6-only
   access, will not work unless a CLAT is present. 464XLAT is the only
   valid approach to resolve this issue.

8.  Using 464XLAT with/without DNS64

   In the case the client device is IPv6-only (either because the stack
   is IPv6-only, or because it is connected via an IPv6-only LAN) and
   the server is IPv4-only (either because the stack is IPv4-only, or
   because it is connected via an IPv4-only LAN), only NAT64 combined
   with DNS64 will be able to provide access among both.  Because DNS64
   is then required, DNSSEC validation will be only possible if the
   recursive name server is validating the negative response from the
   authoritative name server and the client is not performing
   validation.



Palet Martinez          Expires September 5, 2018              [Page 13]


Internet-Draft              NAT64 Deployment                  March 2018


   However, when the client device is dual-stack and/or connected in a
   dual-stack LAN by means of a CLAT (or has the built-in CLAT), DNS64
   is an option.

   1.  With DNS64: If DNS64 is used, most of the IPv4 traffic (except if
       using literal IPv4 addresses or non-IPv6 compliant APIs) will not
       use the CLAT, so will use the IPv6 path and only one translation
       will be done at the NAT64.  This may break DNSSEC, unless
       measures as described in the precedent section are taken.

   2.  Without DNS64: If DNS64 is not used, all the IPv4 traffic will
       make use of the CLAT, so two translations are required (NAT46 at
       the CLAT and NAT64 at the PLAT), which adds some overhead in
       terms of the extra NAT46 translation, however avoids the AAAA
       synthesis and consequently will never break DNSSEC.

9.  Manual Configuration of Foreign DNS

   When clients in a service provider network use DNS servers from other
   networks, for example manually configured by users, they may support
   or not DNS64, so the considerations in Section 8 will apply as well.

   Even in the case that the external DNS supports DNS64 function, we
   may be in the situation of providing incorrect configurations
   parameters, as explained in Section 3.4.  Having a CLAT and using an
   external DNS without DNS64, ensures that everything will work.

   However, it needs to be reinforced, that if there is not a CLAT
   (scenarios without 464XLAT), an external DNS without DNS64 support,
   will not only guarantee that DNSSEC is broken, but also disallow any
   access to IPv4-only networks, so will behave as in the Section 3.1.

10.  CLAT Translation Considerations

   As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if
   the CLAT can be configured with a dedicated /64 prefix for the NAT46
   translation, then it will be possible to do a more efficient
   stateless translation.

   However, if this dedicated prefix is not available, the CLAT will
   need to do a stateful translation, for example performing stateful
   NAT44 for all the IPv4 LAN packets, so they appear as coming from a
   single IPv4 address, and then in turn, stateless translated to a
   single IPv6 address.

   The obvious recommended setup, in order to maximize the CLAT
   performance, is to configure the dedicated translation prefix.  This
   can be easily achieved automatically, if the CE or end-user device is



Palet Martinez          Expires September 5, 2018              [Page 14]


Internet-Draft              NAT64 Deployment                  March 2018


   able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]), so
   the CE can use a /64 for that.

   The above recommendation is often not posible for cellular networks,
   when connecting UEs (some broadband cellular use DHCPv6-PD
   ([RFC3633]), but smartphones, in general, not), as they provide a
   single /64 for each PDP context and use /64 prefix sharing
   ([RFC6877]).  So in this case, the UEs typically have a build-in CLAT
   client, which is doing a stateful NAT44 before the stateless NAT46.

11.  Summary of Deployment Recommendations for NAT64

   Service providers willing to deploy NAT64, need to take into account
   the considerations of this document to avoid the issues depicted in
   this document.

   In the case it is a non-cellular network and the operator is
   providing the CEs to the customers, or suggesting them some specific
   models, they MUST support the customer-side translator (CLAT), in
   order to fully support the actual user needs (IPv4-only devices and
   applications, usage of literals and old APIs).

   If the operator offers DNS services, in order to increase performance
   by reducing the double translation for all the IPv4 traffic, and
   avoid breaking DNSSEC, they MAY support DNS64.  In this case, if the
   DNS service is offering DNSSEC validation, then it MUST be in such
   way that it is aware of the DNS64.  This is considered de simpler and
   safer approach, and MAY be combined as well with the other possible
   solutions described in this document:

   o  Devices running CLAT SHOULD follow the indications in the "Stub
      validator" section recommendation.  However, most of the time,
      this is out of the control of the operator.

   o  CEs SHOULD include a DNS proxy and validador.  This is relevant if
      the operator is providing the CE or suggesting it to customers.

   o  ACL of clients and Mapping-out IPv4 addresses MAY be considered by
      each operator, depending on their own infrastructure.

   This "increased performance" approach has the disadvantage of
   potentially breaking DNSSEC for a small percentage of validating end-
   hosts.

   If CE performance is not an issue, then a much safer approach is to
   not use DNS64 at all, and consequently ensure that all the IPv4
   traffic is translated at the CLAT.




Palet Martinez          Expires September 5, 2018              [Page 15]


Internet-Draft              NAT64 Deployment                  March 2018


   If DNS64 is not used, one of the alternatives described in
   Section 4.1, MUST be followed.

   The ideal configuration for CEs supporting CLAT, is that they support
   DHCPv6-PD ([RFC3633]) and internally reserve one /64 for the
   stateless NAT46 translation.  The operator MUST ensure that the
   customers get allocated prefixes shorter than /64 in order to support
   this optimization.  One way or the other, this is not impacting the
   performance of the operator network.

   As indicated in Section 7 of [RFC6877] (Deployment Considerations),
   operators MAY follow those suggestions in order to take advantage of
   traffic engineering.

   In the case of cellular networks, the considerations regarding DNSSEC
   may appear as out-of-scope, because UEs OSs, commonly don't support
   DNSSEC, however applications running on them may do, or it may be an
   OS "built-in" support in the future.  Moreover, if those devices
   offer tethering, other client devices may be doing the validation,
   hence the relevance of a proper DNSSEC support by the operator
   network.

   Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and
   "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
   ([RFC7050]), allow a progressive IPv6 deployment, with a single APN
   supporting all types of PDP context (IPv4, IPv6, IPv4v6), in such way
   that the network is able to automatically serve all the possible
   combinations of UEs.

   Finally, if the operator choose to secure the NAT64 prefix, it MUST
   follow the advise indicated in Section 3.1.1. of [RFC7050]
   (Validation of Discovered Pref64::/n).

12.  Deployment of NAT64 in Enterprise Networks

   The recommendations of this documents can be used as well in
   enterprise networks, campus and other similar scenarios, when the
   NAT64 is under the control of that network, and for whatever reasons,
   there is a need to provide "IPv6-only access" to any part of that
   network or it is IPv6-only connected to third party networks.

   An example of that is the IETF meetings network itself, where a NAT64
   and DNS64 are provided, presenting in this case the same issues as
   per Section 3.2.  If there is a CLAT in the IETF network, then there
   is no need to use DNS64 and it falls under the considerations of
   Section 3.5.  Both scenarios have been tested and verified already in
   the IETF network itself.




Palet Martinez          Expires September 5, 2018              [Page 16]


Internet-Draft              NAT64 Deployment                  March 2018


13.  Security Considerations

   This document does not have any new specific security considerations.

14.  IANA Considerations

   This document does not have any new specific IANA considerations.

   Note: This section is assuming that https://www.rfc-
   editor.org/errata/eid5152 is resolved, otherwise, this section may
   include the required text to resolve the issue.

15.  Acknowledgements

   The author would like to acknowledge the inputs of TBD ...

   Conversations with Marcelo Bagnulo, one of the co-authors of DNS64,
   as well as several emails in public mailing lists from Mark Andrews,
   have been very useful for this work.

   Christian Huitema inspired working in this document by suggesting
   that DNS64 should never be used, during a discussion regarding the
   deployment of CLAT in the IETF network.

16.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <https://www.rfc-editor.org/info/rfc3633>.

   [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>.






Palet Martinez          Expires September 5, 2018              [Page 17]


Internet-Draft              NAT64 Deployment                  March 2018


   [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>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <https://www.rfc-editor.org/info/rfc6335>.

   [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
              Using "Bump-in-the-Host" (BIH)", RFC 6535,
              DOI 10.17487/RFC6535, February 2012,
              <https://www.rfc-editor.org/info/rfc6535>.

   [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>.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, DOI 10.17487/RFC7050, November 2013,
              <https://www.rfc-editor.org/info/rfc7050>.

   [RFC7225]  Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
              Port Control Protocol (PCP)", RFC 7225,
              DOI 10.17487/RFC7225, May 2014,
              <https://www.rfc-editor.org/info/rfc7225>.

   [RFC7278]  Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
              /64 Prefix from a Third Generation Partnership Project
              (3GPP) Mobile Interface to a LAN Link", RFC 7278,
              DOI 10.17487/RFC7278, June 2014,
              <https://www.rfc-editor.org/info/rfc7278>.

   [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>.

   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017,
              <https://www.rfc-editor.org/info/rfc8305>.



Palet Martinez          Expires September 5, 2018              [Page 18]


Internet-Draft              NAT64 Deployment                  March 2018


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 5, 2018              [Page 19]


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