--- 1/draft-ietf-v6ops-nat64-deployment-01.txt 2018-08-14 11:13:13.818382561 -0700 +++ 2/draft-ietf-v6ops-nat64-deployment-02.txt 2018-08-14 11:13:13.886384220 -0700 @@ -1,18 +1,18 @@ v6ops J. Palet Martinez Internet-Draft The IPv6 Company -Intended status: Informational August 13, 2018 -Expires: February 14, 2019 +Intended status: Informational August 14, 2018 +Expires: February 15, 2019 NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks - draft-ietf-v6ops-nat64-deployment-01 + draft-ietf-v6ops-nat64-deployment-02 Abstract This document describes how NAT64 and 464XLAT can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. @@ -24,21 +24,21 @@ 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 February 14, 2019. + This Internet-Draft will expire on February 15, 2019. 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 @@ -61,131 +61,149 @@ 3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 12 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 13 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network . . . . . . . . . . . . . . . . . . . 14 3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 14 4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 16 4.1. DNSSEC Considerations and Possible Approaches . . . . . . 16 4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 17 4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 18 4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 18 - 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 18 + 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 19 4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 19 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 19 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 19 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 20 4.4. Manual Configuration of Foreign DNS . . . . . . . . . . . 20 4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 4.6. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 21 4.7. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22 4.8. IPv4-only Hosts or Applications . . . . . . . . . . . . . 22 4.9. CLAT Translation Considerations . . . . . . . . . . . . . 22 5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27 - 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 30 + 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 31 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 13.2. Informative References . . . . . . . . . . . . . . . . . 32 + 13. ANNEX D: Changes from -00 and -01 . . . . . . . . . . . . . . 31 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 + 14.2. Informative References . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 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. + NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation + mechanisms, which allows IPv6-only hosts to communicate with + IPv4-only servers using unicast UDP, TCP or ICMP, by means of IPv4 + public addresses sharing (assigned to the translator), among multiple + IPv6-only hosts. 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]. + translation algorithm defined in [RFC7915] and algorithmically + translating the IPv4 addresses to IPv6 addresses following [RFC6052]. DNS64 ([RFC6147]), is in charge of the synthesis of AAAA records from - the A records, avoiding changes in both, the IPv6-only hosts and the - IPv4-only server, so they can use a NAT64. + the A records, so only works for applications making use of DNS, + avoiding changes in both, the IPv6-only hosts and the IPv4-only + server, so they can use a NAT64. As discussed in Section 5.5 of + [RFC6147], a security-aware and validating host has to perform the + DNS64 function locally. 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 it has 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. + b. Because the need of using DNS64 ([RFC6147]) or an alternative + "host/application built-in" mechanism for address synthesis, + 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. + service provider IPv6-only access, as it was designed for a very + specific scenario ([RFC6144], Section 2.1). - 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. + The same issues are true if part of, for example, an enterprise + network, is connected to other parts of the same network or third + party networks by means of IPv6-only connectivity. This applies to + many other similar cases. According to that, across this document, the use of "operator network" is interchangeable with equivalent cases of enterprise (or similar) networks. + An analysis of stateful IPv6/IPv6 mechanisms is provided in + + [RFC6889]. + This document looks into different possible NAT64 ([RFC6146]) - deployment scenarios, including 464XLAT ([RFC6877]) ones, in - operators (broadband and cellular) and enterprise networks, and + deployment scenarios, including IPv4-IPv6-IPv4 and similar ones, + which were not documented by [RFC6144], such as 464XLAT ([RFC6877]), + in operator (broadband and cellular) and enterprise networks, and provides guidelines to avoid the above-mentioned issues. Towards that, this document first looks into the possible NAT64 deployment scenarios (split in "known to work" and "known to work under special conditions"), providing a quick and generic comparison - table among them. Then describes the issues that an operator need to - understand on different matters that will allow to define what is the - best approach/scenario for each specific network case. A summary - provides some recommendations and decision points and then a - clarification of the usage of this document for enterprise networks - is provided. Finally, an Annex provides an example of a broadband - deployment using 464XLAT. + table among them. Then the document describes the issues that an + operator need to understand on different matters that will allow to + define what is the best approach/scenario for each specific network + case. A summary provides some recommendations and decision points + and then a clarification of the usage of this document for enterprise + networks is provided. Finally, an annex provides an example of a + broadband deployment using 464XLAT. + + The target deployment scenarios in this document may be covered as + well by other IPv4-as-a-Service transition mechanisms. It is out of + scope of this document to provide a comparison among them. + + [RFC7269] provides additional information about NAT64 deployment + options and experiences. 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. 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 now, despite they were specifically ruled out of the original NAT64/DNS64 work. Consequently, the perspective in this document is to broaden 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 wants to make sure that all the customers - have a service without failures. This means considering the worst - possible case: + that typically, the service provider wants 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. + link (e.g., tethering in cellular networks). We use a common set of possible "participant entities": 1. An IPv6-only access network (IPv6). 2. An IPv4-only remote network/server/services (IPv4). 3. The NAT64 function (NAT64) in the service provider. 4. The DNS64 function (DNS64) in the service provider. @@ -203,28 +221,28 @@ 3.1. Known to Work The scenarios in this category are known to work. Each one may have different pros and cons, and in some cases the trade-offs, maybe acceptable for some operators. 3.1.1. Service Provider NAT64 with DNS64 In this scenario, the service provider offers both, the NAT64 and the - DNS64 function. + DNS64 functions. - This is probably the most common scenario, however also has the + This is probably the most common scenario, however also may have 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. + This scenario also may fail 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 1: NAT64 with DNS64 A totally equivalent scenario will be if the service provider offers @@ -265,22 +283,22 @@ | | | | +----------+ +----------+ Figure 3: NAT64 and DNS64 in external provider One more equivalent scenario will be if the service provider offers the NAT64 only, and the DNS64 function is from an external provider with or without a specific agreement among them. This is a scenario already feasible today, as several "global" service providers provide free DNS64 services and users often configure manually their DNS. - This will only work if both the NAT64 and the DNS64 are using the - same WKP (Well-Known Prefix) or NSP (Network-Specific Prefix). All + This will only work if both the NAT64 and the DNS64 are using the WKP + (Well-Known Prefix) or the same NSP (Network-Specific Prefix). All the considerations in the previous paragraphs of this section are the same for this sub-case. Of course, if the external DNS64 is agreed with the service provider, then we are in the same case as in the previous ones already depicted in this scenario. +----------+ | | | extDNS64 | @@ -303,46 +321,45 @@ 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. + ([RFC6146]), implemented typically at in the operator network. - 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). + 3. Optionally, DNS64 ([RFC6147]), may allow 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). Note that even in the 464XLAT ([RFC6877]) terminology, the provider- side translator is referred as PLAT, for simplicity and uniformity, in this document is always referred as NAT64. In this scenario the service provider deploys 464XLAT with DNS64. - As a consequence, the DNSSEC issues remain. + As a consequence, the DNSSEC issues remain, unless the if the host is + doing the address synthesis. 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, providing an IPv6-only access network. By supporting CLAT, - the end-user device applications can access IPv4-only end-networks/ - applications, despite those applications or devices use literal IPv4 - addresses or non-IPv6 compliant APIs. + 464XLAT ([RFC6877]) has been used initially in IPv6-only cellular + networks. By supporting CLAT, the end-user device applications can + access IPv4-only end-networks/applications, despite those + applications or devices use literal IPv4 addresses or non-IPv6 + compliant APIs. It is also used for tethering purposes. 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, as indicated in [RFC6877], 464XLAT can be used in broadband IPv6 network architectures, by implementing the CLAT functionality at the CE. @@ -374,21 +391,21 @@ b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that services are deployed in Internet using IPv6-only, unless there is certainty that peers will also be IPv6-capable. d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 translations. - The following pictures show different choices for placing the + The following figures show different choices for placing the different elements. +----------+ +----------+ +----------+ | IPv6 | | NAT64 | | | | + +--------+ + +--------+ IPv4 | | CLAT | | DNS64 | | | +----------+ +----------+ +----------+ Figure 5: 464XLAT with DNS64 @@ -480,21 +497,21 @@ It needs to be noticed that this scenario works while the local hosts/applications are dual-stack (which is the current situation), because the connectivity from a local-IPv6 to a remote-IPv4 is not possible without an AAAA synthesis. This aspect is important only when in the LANs behind the CLAT there are IPv6-only hosts and they need to communicate with remote IPv4-only hosts. However, doesn't look a sensible approach from an Operating System or application vendor perspective, to provide IPv6-only support unless, similarly to c. above, there is certainty of peers supporting IPv6 as well. - The following pictures show different choices for placing the + The following figures show different choices for placing the different elements. +----------+ +----------+ +----------+ | IPv6 | | | | | | + +--------+ NAT64 +--------+ IPv4 | | CLAT | | | | | +----------+ +----------+ +----------+ Figure 8: 464XLAT without DNS64 @@ -625,30 +642,29 @@ | IPv6 +--------+ NAT64 +--------+ + | | | | | | DNS64 | +----------+ +----------+ +----------+ Figure 12: NAT64; DNS64 in the IPv4-only 3.3. Comparing the Scenarios This section compares the different scenarios, including the possible variations (each one represented in the precedent sections by a - different Figure), looking at the following parameters: + different figure), looking at the following parameters: a. DNSSEC: Are there host validating DNSSEC? - b. Literal/APIs: Are there applications using literals or non-IPv6 compliant APIs? c. IPv4-only: Are there hosts or applications using IPv4-only? - d. Foreign DNS: Is the Scenario surviving if the user changes the + d. Foreign DNS: Is the scenario surviving if the user changes the DNS? Note that this apply similarly to split DNS, DNS in VPNs and DNS privacy. In the next table, the columns represent each of the scenario from the previous sections, by the Figure number. The possible values are: - Scenario "bad" for that item. + Scenario "good" for that item. @@ -673,25 +689,26 @@ +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ Figure 13: Scenario Comparison As a general conclusion, we should note that if the network must support applications using literals, non-IPv6-compliant APIs, or - IPv4-only hosts or applications, only the scenarios with 464XLAT will - provide a solution. Further to that, those scenarios will also keep - working if the user changes the DNS setup. Clearly also, depending - on if DNS64 is used or not, DNSSEC may be broken for those hosts - doing DNSSEC validation. + IPv4-only hosts or applications, only the scenarios with 464XLAT, or + equivalent built-in local address synthesis features, will provide a + solution. Further to that, those scenarios will also keep working if + the user changes the DNS setup. Clearly also, depending on if DNS64 + is used or not, DNSSEC may be broken for those hosts doing DNSSEC + validation. 4. Issues to be Considered This section reviews the different issues that an operator needs to consider towards a NAT64/464XLAT deployment, as they may bring to decision points about how to approach that deployment. 4.1. DNSSEC Considerations and Possible Approaches As indicated in Section 8 of [RFC6147] (DNS64, Security @@ -760,22 +777,22 @@ depicted in the next sections. 4.1.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 presence of the NAT64, neither to learn the IPv6 prefix to be + used for it, unless it is configured by alternative means. 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 @@ -805,26 +822,27 @@ 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.1.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. + may query the network for a NAT64 prefix ([RFC7050] or [RFC7225]) in + order to synthesize the AAAA ([RFC6052]). This allows the client + device to avoid using the CLAT and still use NAT64 even with DNSSEC. If the end-host is IPv4-only, this will not work if a CLAT is not - present (scenarios without 464XLAT). + present (scenarios without 464XLAT) or the client is able to locally + do the address synthesis. Some devices/OSs may implement, instead of CLAT, a similar function by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the considerations in the above paragraphs are also applicable. 4.1.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 @@ -971,21 +989,21 @@ d. If DNS64 is required and users may change their DNS configuration, and deliberately choose an alternative DNS64, most probably alternative DNS64 will use by default the WKP. If an NSP is used by the NAT64, the users will not be able to use the operator NAT64. 4.7. 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. + (or equivalent function) 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 UE @@ -1005,26 +1023,26 @@ 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 broadband CE or end-user - device is able to obtain a shorter prefix by means of DHCPv6-PD - ([RFC3633]) so, the CE can use a /64 for that. This is also possible - when broadband is provided by a cellular access. + One possible setup, in order to maximize the CLAT performance, is to + configure the dedicated translation prefix. This can be easily + achieved automatically, if the broadband CE or end-user device is + able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]) so, + the CE can use a /64 for that. This is also possible when broadband + is provided by a cellular access. The above recommendation is often not possible for cellular networks, when connecting smartphones (as UEs), as they don't use DHCPv6-PD ([RFC3633]) an instead a single /64 is provided 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. 5. Summary of Deployment Recommendations for NAT64 @@ -1033,49 +1051,50 @@ thing as a way to push for the IPv6 deployment, or otherwise, it may be further delayed, with clear undesirable effects for the global Internet. However, for an operator, being in business means minimizing the adverse transition effects, and provide the most perfect one reasonably balanced with cost (CAPEX/OPEX), and at the same time looking for a valid long-term vision. NAT64/464XLAT has demonstrated to be a valid choice in several - scenarios, with hundreds of millions of users, offering different - choices of deployment, depending on each network case, needs and - requirements. + scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions + of users, offering different choices of deployment, depending on each + network case, needs and requirements. Depending on those requirements, DNS64 may be a required function, while in other cases the adverse effects may be counterproductive. Similarly, in some cases NAT64, together with DNS64, may be a valid solution, when for sure there is no need to support hosts or - applications which are IPv4-only (Section 4.7, Section 4.8). + applications which are IPv4-only (Section 4.7 and Section 4.8). However, in other cases the limitations they have, may suggest the operator to look into 464XLAT as a more complete solution. Service providers willing to deploy NAT64, need to take into account the considerations of this document in order to better decide what is more appropriate for their own specific case. In the case of broadband managed networks (CE provided or suggested/ supported by the operator), in order to fully support the actual user needs (IPv4-only devices and applications, usage of literals and old - APIs), they SHOULD consider the 464XLAT scenario and in that case, - MUST support the customer-side translator (CLAT). + APIs), they should consider the 464XLAT scenario and in that case, + must support the customer-side translator (CLAT). If the operator offers DNS services, in order to increase performance - by reducing the double translation for all the IPv4 traffic, they MAY + by reducing the double translation for all the IPv4 traffic, they may support DNS64 and avoid, as much as possible, breaking DNSSEC. 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 the simpler and safer approach, and MAY be combined as - well with the other possible solutions described in this document: + must be in such way that it is aware of the DNS64. This is + considered the simpler and safer approach, and may be combined as + well with the other possible recommendations described in this + document: o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). o Devices running CLAT SHOULD follow the indications in Section 4.1.3 (Stub validator). However, this may be out of the control of the operator. o CEs SHOULD include a DNS proxy and validator (Section 4.1.4). o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4 @@ -1084,45 +1103,45 @@ This "increased performance" approach has the disadvantage of potentially breaking DNSSEC for a small percentage of validating end- hosts versus the small impact of a double translation taking place in the CE. If CE performance is not an issue, which is the most frequent case, 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 (Section 4.3). If DNS64 is not used, at least one of the alternatives described in - Section 4.1.1, MUST be followed. + Section 4.1.1, must be followed. The operator need to consider that if the user can modify the DNS configuration (which most probably is impossible to avoid), and instead of configuring a DNS64 choose an external regular DNS (non- DNS64), a scenario with only NAT64 will not work with any IPv4-only remote host, while it will continue working in the case of 464XLAT (Section 4.4). Same effects are to be expected if DNS privacy protocols are being used by customers (Section 4.5). Similar considerations need to be taken regarding the usage of a NAT64 Well-Known vs Network-Specific Prefix (Section 4.6), in the - sense of, if using DNS64, they MUST match and if the user can change - the DNS config, they will, most probably, not. + sense of, if using DNS64, they must match and if the user can change + the DNS configuration, they will, most probably, not. - 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 + In broadband networks, it is recommended that CEs supporting CLAT, + 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. + operators may follow those suggestions in order to take advantage of + traffic engineering requirements. 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 @@ -1133,23 +1152,23 @@ combinations of UEs. One last consideration is that many networks may have different scenarios at the same time, for example, customers requiring 464XLAT, others not requiring it, customers requiring DNS64, others not, etc. In general, the different issues and approaches described in this document can be implemented at the same time for different customers or parts of the network, so not representing any problem for complex cases. - Finally, if the operator chooses to secure the NAT64 prefix, it MUST - follow the advice from Section 3.1.1. of [RFC7050] (Validation of - Discovered Pref64::/n). + Finally, if the operator chooses to provide validation for the DNS64 + prefix discovery, it must follow the advice from Section 3.1. of + [RFC7050] (Validation of Discovered Pref64::/n). 6. Deployment of NAT64 in Enterprise Networks The recommendations of this document can be used as well in enterprise networks, campus and other similar scenarios, when the NAT64 (and/or DNS64) are 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. @@ -1216,21 +1235,22 @@ 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. 9. Acknowledgements The author would like to acknowledge the inputs of Gabor Lencse, - Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker and TBD ... + Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed + Boucadair and TBD ... Conversations with Marcelo Bagnulo, one of the co-authors of NAT64 and DNS64, as well as several emails in 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. 10. ANNEX A: Example of Broadband Deployment with 464XLAT @@ -1408,23 +1429,29 @@ OpenWRT: https://github.com/openwrt- routing/packages/blob/master/nat46/files/464xlat.sh. VPP: https://git.fd.io/vpp/tree/src/plugins/nat. 12. ANNEX C: Benchmarking Several documents provide references to benchmarking, for example in the case of DNS64, [DNS64-Benchm]. -13. References +13. ANNEX D: Changes from -00 and -01 -13.1. Normative References + Section to be removed for WGLC. Significant updates are: + + 1. Text changes across all the document. + +14. References + +14.1. 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -1432,20 +1459,24 @@ [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, . [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, . + [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for + IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, + April 2011, . + [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, . [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, . @@ -1453,20 +1484,25 @@ [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, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . + [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, + "Analysis of Stateful 64 Translation", RFC 6889, + DOI 10.17487/RFC6889, April 2013, + . + [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, . [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, DOI 10.17487/RFC7225, May 2014, . @@ -1481,21 +1517,21 @@ [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, . -13.2. Informative References +14.2. Informative References [About-DNS64] J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, . [DNS64-Benchm] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. 61-74, @@ -1511,20 +1547,25 @@ Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", draft-ietf-doh-dns-over-https-12 (work in progress), June 2018. [I-D.ietf-v6ops-transition-ipv4aas] Palet, J., Liu, H., and M. Kawashima, "Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service", draft-ietf-v6ops-transition-ipv4aas-07 (work in progress), August 2018. + [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 + Deployment Options and Experience", RFC 7269, + DOI 10.17487/RFC7269, June 2014, + . + [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, .