idnits 2.17.1 draft-palet-v6ops-nat64-deployment-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6146], [RFC6147]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 676: '... models, they MUST support the custo...' RFC 2119 keyword, line 682: '...ing DNSSEC, they MAY support DNS64. I...' RFC 2119 keyword, line 683: '...EC validation, then it MUST be in such...' RFC 2119 keyword, line 685: '...er approach, and MAY be combined as we...' RFC 2119 keyword, line 688: '...ces running CLAT SHOULD follow the ind...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2018) is 2239 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6335' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC7278' is defined on line 833, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 6877 ** Downref: Normative reference to an Informational RFC: RFC 7278 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops J. Palet Martinez 3 Internet-Draft The IPv6 Company 4 Intended status: Best Current Practice March 4, 2018 5 Expires: September 5, 2018 7 NAT64 Deployment Guidelines in Operator and Enterprise Networks 8 draft-palet-v6ops-nat64-deployment-00 10 Abstract 12 This document describes how NAT64 ([RFC6146]) can be deployed in an 13 IPv6 operator or enterprise network and the issues to be considered 14 when having an IPv6-only access link, regarding: a) DNS64 15 ([RFC6147]), b) applications or devices that use literal IPv4 16 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or 17 applications. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 5, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 3 55 3. NAT64 Deployment Scenarios . . . . . . . . . . . . . . . . . 4 56 3.1. Service Provider NAT64 without DNS64 . . . . . . . . . . 5 57 3.2. Service Provider NAT64 with DNS64 . . . . . . . . . . . . 6 58 3.3. Service Provider NAT64; DNS64 in the IPv6 hosts . . . . . 7 59 3.4. Service Provider NAT64; DNS64 in the IPv4-only remote 60 network . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.5. Service Provider offering 464XLAT, without DNS64 . . . . 9 62 3.6. Service Provider offering 464XLAT, with DNS64 . . . . . . 10 63 4. Possible Solutions to the DNSSEC Issue . . . . . . . . . . . 10 64 4.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . . . 11 65 4.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . . . 11 66 4.3. Stub validator . . . . . . . . . . . . . . . . . . . . . 11 67 4.4. CLAT with DNS proxy and validator . . . . . . . . . . . . 12 68 4.5. ACL of clients . . . . . . . . . . . . . . . . . . . . . 12 69 4.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . . . 12 70 5. DNS64 and Reverse Mapping Considerations . . . . . . . . . . 13 71 6. Issue with IPv4 literals and old APIs . . . . . . . . . . . . 13 72 7. Issue with IPv4-only Hosts or Applications . . . . . . . . . 13 73 8. Using 464XLAT with/without DNS64 . . . . . . . . . . . . . . 13 74 9. Manual Configuration of Foreign DNS . . . . . . . . . . . . . 14 75 10. CLAT Translation Considerations . . . . . . . . . . . . . . . 14 76 11. Summary of Deployment Recommendations for NAT64 . . . . . . . 15 77 12. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 16 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 81 16. Normative References . . . . . . . . . . . . . . . . . . . . 17 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation, 87 which allows IPv6-only hosts to contact IPv4 servers using unicast 88 UDP, TCP or ICMP, by means of a single or a set of IPv4 public 89 addresses assigned to the translator, to be shared by the IPv6-only 90 clients. 92 The translation of the packet headers is done using the IP/ICMP 93 Translation Algorithm defined in [RFC7915] and algorithmically 94 translating the IPv4-hosts addresses to IPv6 ones following 95 [RFC6052]. 97 To avoid changes in both, the IPv6-only hosts and the IPv4-only 98 server, NAT64 requires also the use of a DNS64 ([RFC6147]), in charge 99 for the synthesis of AAAA records from the A records. 101 However, the use of NAT64 and/or DNS64 present three issues: 103 a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is 104 designed to detect such modifications, DNS64 ([RFC6147]) can 105 potentially break DNSSEC, depending on a number of factors, such 106 as the location of the DNS64 function (at a DNS server or 107 validator, at the end host, ...), how as been configured, if the 108 end-hosts is validating, etc. 110 b. Because the need of using DNS64 ([RFC6147]), there is a major 111 issue for NAT64 ([RFC6146]), as doesn't work when literal 112 addresses or non-IPv6 compliant APIs are being used. 114 c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or 115 applications located within a network which are connected to a 116 service provider IPv6-only access. 118 The same issues are true if part of an enterprise or similar network, 119 is connected to other parts of the same network or third party 120 networks by means of IPv6-only links. 122 According to that, across this document, the use of "operator 123 network" is interchangeable with equivalent cases of enterprise (or 124 similar) networks. 126 This document looks into different possible NAT64 ([RFC6146]) 127 deployment scenarios in operators and enterprise networks, and 128 provides guidelines to avoid the above mentioned issues. 130 2. DNSSEC Considerations 132 As indicated in Section 8 of [RFC6147] (DNS64, Security 133 Considerations), because DNS64 modifies DNS answers and DNSSEC is 134 designed to detect such modifications, DNS64 can break DNSSEC. 136 If a device connected to an IPv6-only WAN queries for a domain name 137 in a signed zone, by means of a recursive name server that supports 138 DNS64, and the result is a synthesized AAAA record, and the recursive 139 name server is configured to perform DNSSEC validation and has a 140 valid chain of trust to the zone in question, it will 141 cryptographically validate the negative response from the 142 authoritative name server. So, the recursive name server actually 143 lie to the client device, however in most of the cases, the client 144 will not notice it, because generally they don't perform validation 145 themselves as instead rely on their recursive name servers. 147 If the client device performs DNSSEC validation on the AAAA record, 148 it will fail as it is a synthesized record. 150 Similarly, if the client querying the recursive name server is 151 another name server configured to use it as a forwarder, and is 152 performing DNSSEC validation, it will also fail on any synthesized 153 AAAA record. 155 The obvious solution to avoid DNSSEC issues, will be that all the 156 signed zones also provide IPv6 connectivity, together with the 157 corresponding AAAA records. Previous data seems to indicate, that 158 the figures of DNSSEC broken by using DNS64 will be around 1.7% 159 (information 2 years old). 161 3. NAT64 Deployment Scenarios 163 Section 7 of DNS64 ([RFC6147]), provides 3 scenarios, looking at the 164 location of the DNS64. However, since the publication of that 165 document, there are new possible scenarios and NAT64 use cases that 166 need to be considered. 168 The perspective in this document is to broader those scenarios, 169 including a few new ones. However, in order to be able to reduce the 170 number of possible cases, we work under the assumption that the 171 service provider want to make sure that all the customers have a 172 service without failures. This means considering the worst possible 173 case: 175 a. There are hosts that will be validating DNSSEC. 177 b. Literal addresses and non-IPv6 compliant APIs are being used. 179 c. There are IPv4-only hosts or applications beyond the IPv6-only 180 link. 182 We use a common set of possible "participant entities": 184 1. An IPv6-only access network (IPv6). 186 2. An IPv4-only remote network (IPv4). 188 3. The NAT64 of the service provider (NAT64). 190 4. The DNS64 function (DNS64). 192 5. An external service provider offering the NAT64 and/or the DNS64 193 function (extNAT64/extDNS64). 195 6. 464XLAT customer side translator (CLAT). 197 3.1. Service Provider NAT64 without DNS64 199 In this scenario, the service provider offers a NAT64, however there 200 is no DNS64 function support. 202 As a consequence, an IPv6 host in the IPv6-only access network, will 203 not be able to detect the presence of DNS64 neither learning the IPv6 204 prefix to be used for the NAT64. 206 This can be sorted out as indicated in Section 4.1. 208 However, despite that, because the lack of the DNS64 function, the 209 IPv6 host will not be able to obtain AAAA synthesised records, so the 210 NAT64 becomes useless. 212 An exception to this "useless" scenario will be manually configure 213 mappings between the A records of each of the IPv4-only remote hosts 214 and the corresponding AAAA records, with the WKP (Well-Known Prefix) 215 or NSP (Network-Specific Prefix) used by the service provider NAT64, 216 as if they were synthesised by a DNS64. 218 This mapping could be done by several means, typically at the 219 authoritative DNS server, or at the service provider resolvers by 220 means of DNS RPZ (Response Policy Zones). The latest, may have 221 implications in DNSSEC, if the zone is signed. Also, if the service 222 provider is using a NSP, having the mapping at the authoritative 223 server, will mean that may create troubles to other parties trying to 224 use different NSP or the WKP, unless multiple DNS "views" are also 225 being used at the authoritative servers. 227 Generally, the mappings alternative, will only make sense if a few 228 set of IPv4-only remote hosts need to be accessed by a single network 229 or reduced set of them, which support IPv6-only in the access, with 230 some kind of mutual agreement for using this procedure, so it doesn't 231 care if they become a trouble for other parties across Internet 232 ("closed services"). 234 In any case, this scenario doesn't solve the issue of literal 235 addresses or non-IPv6 compliant APIs, neither it solves the problem 236 of IPv4-only hosts within that IPv6-only access network. 238 +----------+ +----------+ +----------+ 239 | | | | | | 240 | IPv6 +--------+ NAT64 +--------+ IPv4 | 241 | | | | | | 242 +----------+ +----------+ +----------+ 244 Figure 1: Scenario of NAT64 without DNS64 246 3.2. Service Provider NAT64 with DNS64 248 In this scenario, the service provider offers both, the NAT64 and the 249 DNS64 function. 251 This is probably the most common scenario, however also has the 252 implications related the DNSSEC. 254 This scenario also fails to solve the issue of literal addresses or 255 non-IPv6 compliant APIs, as well as the issue of IPv4-only hosts or 256 applications inside the IPv6-only access network. 258 +----------+ +----------+ +----------+ 259 | | | NAT64 | | | 260 | IPv6 +--------+ + +--------+ IPv4 | 261 | | | DNS64 | | | 262 +----------+ +----------+ +----------+ 264 Figure 2: Scenario of NAT64 with DNS64 266 A totally equivalent scenario will be if the service provider offers 267 only the DNS64 function, and the NAT64 function is provided by an 268 agreement with an external provider. All the considerations in the 269 previous paragraphs of this section are the same for this sub-case. 271 +----------+ 272 | | 273 | extNAT64 | 274 | | 275 +----+-----+ 276 | 277 | 278 +----------+ +----+-----+ +----------+ 279 | | | | | | 280 | IPv6 +--------+ DNS64 +--------+ IPv4 | 281 | | | | | | 282 +----------+ +----------+ +----------+ 284 Figure 3: Scenario of DNS64; NAT64 in external service provider 286 As well, is equivalent to the scenario where the agreement with the 287 external provider is to provide both the NAT64 and DNS64 function. 288 Once more, all the considerations in the previous paragraphs of this 289 section are the same for this sub-case. 291 +----------+ 292 | extNAT64 | 293 | + | 294 | extDNS64 | 295 +----+-----+ 296 | 297 +----------+ | +----------+ 298 | | | | | 299 | IPv6 +-------------+--------------+ IPv4 | 300 | | | | 301 +----------+ +----------+ 303 Figure 4: Scenario of NAT64 and DNS64 in external provider 305 3.3. Service Provider NAT64; DNS64 in the IPv6 hosts 307 In this scenario, the service provider offers the NAT64, but not the 308 DNS64. However, the IPv6 hosts have a built-in DNS64 function. 310 This may become common if the DNS64 function is implemented in all 311 the IPv6 hosts/stacks, which is not the actual situation. At this 312 way, the DNSSEC validation is performed on the A record, and then the 313 host can use the DNS64 function so to be able to use the NAT64, 314 without any DNSSEC issues. 316 This scenario fails to solve the issue of literal addresses or non- 317 IPv6 compliant APIs, unless the IPv6 hosts also supports Happy 318 Eyeballs v2 ([RFC8305]), which may solve that issue. 320 However, this scenario still fails to solve the problem of IPv4-only 321 hosts or applications inside the IPv6-only access network. 323 +----------+ +----------+ +----------+ 324 | IPv6 | | | | | 325 | + +--------+ NAT64 +--------+ IPv4 | 326 | DNS64 | | | | | 327 +----------+ +----------+ +----------+ 329 Figure 5: Scenario of NAT64; DNS64 in IPv6 hosts 331 3.4. Service Provider NAT64; DNS64 in the IPv4-only remote network 333 In this scenario, the service provider offers the NAT64 only. The 334 remote IPv4-only network offers the DNS64 function. 336 This is not common, and looks like doesn't make too much sense that a 337 remote network, not deploying IPv6, is providing a DNS64 function and 338 as, in the case of the scenario depicted in Section 3.1, it will only 339 work if both sides are using the WKP or the same NSP, etc., so the 340 same considerations apply. 342 This scenario still fails to solve the issue of literal addresses or 343 non-IPv6 compliant APIs. 345 This scenario also fails to solve the problem of IPv4-only hosts or 346 applications inside the IPv6-only access network. 348 +----------+ +----------+ +----------+ 349 | | | | | IPv4 | 350 | IPv6 +--------+ NAT64 +--------+ + | 351 | | | | | DNS64 | 352 +----------+ +----------+ +----------+ 354 Figure 6: Scenario of NAT64; DNS64 in the IPv4-only 356 A totally equivalent scenario will be if the service provider offers 357 the NAT64 only, and the DNS64 function is provided by an external 358 provider without an specific agreement among them. This is an 359 scenario already feasible today, as several "global" service 360 providers provide open DNS64 services and users often configure 361 manually their DNS. All the considerations in the previous 362 paragraphs of this section are the same for this sub-case. 364 If the user instead of configuring a DNS64 uses a regular external 365 DNS, the situation is even much worst, because in that case, NAT64 366 will not work at all with any IPv4-only remote host. 368 However, if the external DNS64 is agreed with the service provider, 369 then we are in the same case, in terms of considerations of issues, 370 as in Section 3.2. 372 +----------+ 373 | | 374 | extDNS64 | 375 | | 376 +----+-----+ 377 | 378 | 379 +----------+ +----+-----+ +----------+ 380 | | | | | | 381 | IPv6 +--------+ NAT64 +--------+ IPv4 | 382 | | | | | | 383 +----------+ +----------+ +----------+ 385 Figure 7: Scenario of NAT64; DNS64 by external provider 387 3.5. Service Provider offering 464XLAT, without DNS64 389 464XLAT ([RFC6877]) describes an architecture that provides IPv4 390 connectivity across a network, or part of it, when it is only 391 natively transporting IPv6. 393 In order to do that, 464XLAT ([RFC6877]) relies on the combination of 394 existing protocols: 396 1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6 397 translator (NAT46) ([RFC7915]) implemented in the end-user device 398 or CE, located at the "customer" edge of the network. 400 2. The provider-side translator (PLAT) is a stateful NAT64 401 ([RFC6146]), implemented typically at the opposite edge of the 402 operator network, that provides access to both IPv4 and IPv6 403 upstreams. 405 3. Optionally, DNS64 ([RFC6147]), implemented as part of the PLAT 406 allows an optimization (a single translation at the NAT64, 407 instead of two translations - NAT46+NAT64), when the application 408 at the end-user device supports IPv6 DNS (uses AAAA RR). 410 In this scenario, using 464XLAT without DNS64, the service provider 411 ensures that DNSSEC is not broken. 413 464XLAT ([RFC6877]) is a very simple approach to cope with the major 414 NAT64+DNS64 drawback: Not working with applications or devices that 415 use literal IPv4 addresses or non-IPv6 compliant APIs. 417 464XLAT ([RFC6877]) has been used initially in IPv6 cellular 418 networks, so providing an IPv6-only access network, the end-user 419 device applications can access IPv4-only end-networks/applications, 420 despite those applications or devices use literal IPv4 addresses or 421 non-IPv6 compliant APIs. 423 In addition to that, in the same example of the cellular network 424 above, if the User Equipment (UE) provides tethering, other devices 425 behind it will be presented with a traditional NAT44, in addition to 426 the native IPv6 support, so clearly it allows IPv4-only hosts inside 427 the IPv6-only access network. 429 Furthermore, 464XLAT ([RFC6877]) can be used in non-cellular IPv6 430 wired (xDSL, DOCSIS, FTTH, Ethernet, ...) and wireless (WiFi) network 431 architectures, by implementing the CLAT functionality at the CE. 433 +----------+ +----------+ +----------+ 434 | IPv6 | | | | | 435 | + +--------+ NAT64 +--------+ IPv4 | 436 | CLAT | | | | | 437 +----------+ +----------+ +----------+ 439 Figure 8: Scenario of 464XLAT, without DNS64 441 3.6. Service Provider offering 464XLAT, with DNS64 443 In this scenario the service provider deploys 464XLAT with DNS64. 445 As a consequence, the DNSSEC issues remain. 447 However, in this scenario, as in the previous one, there are no 448 issues related to IPv4-only hosts inside the IPv6-only access 449 network, neither to the usage of IPv4 literals or non-IPv6 compliant 450 APIs. 452 +----------+ +----------+ +----------+ 453 | IPv6 | | NAT64 | | | 454 | + +--------+ + +--------+ IPv4 | 455 | CLAT | | DNS64 | | | 456 +----------+ +----------+ +----------+ 458 Figure 9: Scenario of 464XLAT, with DNS64 460 4. Possible Solutions to the DNSSEC Issue 462 As already mention, the scenarios in the precious section, are in 463 fact somehow simplified, looking at the worst case, because breaking 464 DNSSEC will not happen, if the end-host is not doing validation, and/ 465 or some countermeasures are taken, depicted in the next sections. 467 4.1. Not using DNS64 469 The ideal solution will be to avoid using DNS64, but as already 470 indicated this is not possible in all the scenarios. 472 However, not having a DNS64, means that is not possible to 473 heuristically discover the NAT64 ([RFC7050]) and consequently, an 474 IPv6 host in the IPv6-only access network, will not be able to detect 475 the presence of the DNS64, neither to learn the IPv6 prefix to be 476 used for the NAT64. 478 The learning of the IPv6 prefix could be solved by means of adding 479 the relevant AAAA records to the ipv4only.arpa. zone of the service 480 provider recursive servers, i.e., if using the WKP (64:ff9b::/96): 482 ipv4only.arpa. SOA . . 0 0 0 0 0 483 ipv4only.arpa. NS . 484 ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 485 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 486 ipv4only.arpa. A 192.0.0.170 487 ipv4only.arpa. A 192.0.0.171 489 An alternative option to the above, is the use of DNS RPZ (Response 490 Policy Zones). 492 One more alternative, only valid in environments with PCP support 493 (for both the hosts or CEs and for the service provider network), to 494 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). 496 4.2. DNSSEC validator aware of DNS64 498 In general, DNS servers with DNS64 function, by default, will not 499 synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the 500 query. In this case, as only an A record is available, it means that 501 the CLAT will take the responsibility, as in the case of literal IPv4 502 addresses, to keep that traffic flow end-to-end as IPv4, so DNSSEC is 503 not broken. However, this will not work if a CLAT is not present as 504 the hosts will not be able to use IPv4 (scenarios without 464XLAT). 506 4.3. Stub validator 508 If the DO flag is set and the client device performs DNSSEC 509 validation, and the Checking Disabled (CD) flag is set for a query, 510 as the DNS64 recursive server will not synthesize AAAA responses, the 511 client could perform the DNSSEC validation with the A record and then 512 may query the network for a NAT64 prefix ([RFC7050]) in order to 513 synthesize the AAAA ([RFC6052]). This allows the client device to 514 avoid using the CLAT and still use NAT64 even with DNSSEC. 516 If the end-host is IPv4-only, this will not work if a CLAT is not 517 present (scenarios without 464XLAT). 519 Some devices/OSs may implement, instead of CLAT, a simliar function 520 by using Bump-in-the-Host ([RFC6535]). In this case, the 521 considerations in the above paragraphs are also applicable. 523 4.4. CLAT with DNS proxy and validator 525 If a CE includes CLAT support and also a DNS proxy, as indicated in 526 Section 6.4 of [RFC6877], the CE could behave as a stub validator on 527 behalf of the client devices, following the same approach described 528 in the precedent section (Stub validator). So the DNS proxy actually 529 lie to the client devices, which in most of the cases will not notice 530 it unless they perform validation themselves. Again, this allow the 531 clients devices to avoid using the CLAT and still use NAT64 with 532 DNSSEC. 534 Once more, this will not work without a CLAT (scenarios without 535 464XLAT). 537 4.5. ACL of clients 539 In cases of dual-stack clients, stub resolvers should send the AAAA 540 queries before the A ones. So such clients, if DNS64 is enabled, 541 will never get A records, even for IPv4-only servers, and they may be 542 in the path before the NAT64 and accesible by IPv4. If DNSSEC is 543 being used for all those flows, specific addresses or prefixes can be 544 left-out the DNS64 synthesis by means of ACLs. 546 Once more, this will not work without a CLAT (scenarios without 547 464XLAT). 549 4.6. Mapping-out IPv4 addresses 551 If there are well-known specific IPv4 addresses or prefixes using 552 DNSSEC, they can be mapped-out of the DNS64 synthesis. 554 Even if this is not related to DNSSEC, this "mapping-out" feature is 555 actually quite commonly used to ensure that [RFC1918] addresses (for 556 example used by LAN servers) are not synthesized to AAAA. 558 Once more, this will not work without a CLAT (scenarios without 559 464XLAT). 561 5. DNS64 and Reverse Mapping Considerations 563 When a client device, using a name server configured to perform 564 DNS64, tries to reverse-map a synthesized IPv6 address, the name 565 server responds with a CNAME record pointing the domain name used to 566 reverse-map the synthesized IPv6 address (the one under ip6.arpa), to 567 the domain name corresponding to the embedded IPv4 address (under in- 568 addr.arpa). 570 This is the expected behaviour, so no issues to be considered 571 regarding DNS reverse mapping. 573 6. Issue with IPv4 literals and old APIs 575 A hosts or application using literal IPv4 addresses or older APIs, 576 behind a network with IPv6-only access, will not work unless a CLAT 577 is present. 579 A possible alternative approach is described as part of Happy 580 Eyeballs v2 Section 7.1 ([RFC8305]), or if not supporting HEv2, 581 directly using Bump-in-the-Host ([RFC6535]), and then a DNS64 582 function. 584 Those alternatives will solve the problem for and end-hosts, however, 585 if that end-hosts is providing "tethering" or an equivalent service 586 to others hosts, that need to be considered as well. In other words, 587 in a case of a cellular network, it resolves the issue for the 588 cellular device itself, but may be not for hosts behind it. 590 Otherwise, 464XLAT is the only valid approach to resolve this issue. 592 7. Issue with IPv4-only Hosts or Applications 594 An IPv4-only hosts or application behind a network with IPv6-only 595 access, will not work unless a CLAT is present. 464XLAT is the only 596 valid approach to resolve this issue. 598 8. Using 464XLAT with/without DNS64 600 In the case the client device is IPv6-only (either because the stack 601 is IPv6-only, or because it is connected via an IPv6-only LAN) and 602 the server is IPv4-only (either because the stack is IPv4-only, or 603 because it is connected via an IPv4-only LAN), only NAT64 combined 604 with DNS64 will be able to provide access among both. Because DNS64 605 is then required, DNSSEC validation will be only possible if the 606 recursive name server is validating the negative response from the 607 authoritative name server and the client is not performing 608 validation. 610 However, when the client device is dual-stack and/or connected in a 611 dual-stack LAN by means of a CLAT (or has the built-in CLAT), DNS64 612 is an option. 614 1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if 615 using literal IPv4 addresses or non-IPv6 compliant APIs) will not 616 use the CLAT, so will use the IPv6 path and only one translation 617 will be done at the NAT64. This may break DNSSEC, unless 618 measures as described in the precedent section are taken. 620 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will 621 make use of the CLAT, so two translations are required (NAT46 at 622 the CLAT and NAT64 at the PLAT), which adds some overhead in 623 terms of the extra NAT46 translation, however avoids the AAAA 624 synthesis and consequently will never break DNSSEC. 626 9. Manual Configuration of Foreign DNS 628 When clients in a service provider network use DNS servers from other 629 networks, for example manually configured by users, they may support 630 or not DNS64, so the considerations in Section 8 will apply as well. 632 Even in the case that the external DNS supports DNS64 function, we 633 may be in the situation of providing incorrect configurations 634 parameters, as explained in Section 3.4. Having a CLAT and using an 635 external DNS without DNS64, ensures that everything will work. 637 However, it needs to be reinforced, that if there is not a CLAT 638 (scenarios without 464XLAT), an external DNS without DNS64 support, 639 will not only guarantee that DNSSEC is broken, but also disallow any 640 access to IPv4-only networks, so will behave as in the Section 3.1. 642 10. CLAT Translation Considerations 644 As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if 645 the CLAT can be configured with a dedicated /64 prefix for the NAT46 646 translation, then it will be possible to do a more efficient 647 stateless translation. 649 However, if this dedicated prefix is not available, the CLAT will 650 need to do a stateful translation, for example performing stateful 651 NAT44 for all the IPv4 LAN packets, so they appear as coming from a 652 single IPv4 address, and then in turn, stateless translated to a 653 single IPv6 address. 655 The obvious recommended setup, in order to maximize the CLAT 656 performance, is to configure the dedicated translation prefix. This 657 can be easily achieved automatically, if the CE or end-user device is 658 able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]), so 659 the CE can use a /64 for that. 661 The above recommendation is often not posible for cellular networks, 662 when connecting UEs (some broadband cellular use DHCPv6-PD 663 ([RFC3633]), but smartphones, in general, not), as they provide a 664 single /64 for each PDP context and use /64 prefix sharing 665 ([RFC6877]). So in this case, the UEs typically have a build-in CLAT 666 client, which is doing a stateful NAT44 before the stateless NAT46. 668 11. Summary of Deployment Recommendations for NAT64 670 Service providers willing to deploy NAT64, need to take into account 671 the considerations of this document to avoid the issues depicted in 672 this document. 674 In the case it is a non-cellular network and the operator is 675 providing the CEs to the customers, or suggesting them some specific 676 models, they MUST support the customer-side translator (CLAT), in 677 order to fully support the actual user needs (IPv4-only devices and 678 applications, usage of literals and old APIs). 680 If the operator offers DNS services, in order to increase performance 681 by reducing the double translation for all the IPv4 traffic, and 682 avoid breaking DNSSEC, they MAY support DNS64. In this case, if the 683 DNS service is offering DNSSEC validation, then it MUST be in such 684 way that it is aware of the DNS64. This is considered de simpler and 685 safer approach, and MAY be combined as well with the other possible 686 solutions described in this document: 688 o Devices running CLAT SHOULD follow the indications in the "Stub 689 validator" section recommendation. However, most of the time, 690 this is out of the control of the operator. 692 o CEs SHOULD include a DNS proxy and validador. This is relevant if 693 the operator is providing the CE or suggesting it to customers. 695 o ACL of clients and Mapping-out IPv4 addresses MAY be considered by 696 each operator, depending on their own infrastructure. 698 This "increased performance" approach has the disadvantage of 699 potentially breaking DNSSEC for a small percentage of validating end- 700 hosts. 702 If CE performance is not an issue, then a much safer approach is to 703 not use DNS64 at all, and consequently ensure that all the IPv4 704 traffic is translated at the CLAT. 706 If DNS64 is not used, one of the alternatives described in 707 Section 4.1, MUST be followed. 709 The ideal configuration for CEs supporting CLAT, is that they support 710 DHCPv6-PD ([RFC3633]) and internally reserve one /64 for the 711 stateless NAT46 translation. The operator MUST ensure that the 712 customers get allocated prefixes shorter than /64 in order to support 713 this optimization. One way or the other, this is not impacting the 714 performance of the operator network. 716 As indicated in Section 7 of [RFC6877] (Deployment Considerations), 717 operators MAY follow those suggestions in order to take advantage of 718 traffic engineering. 720 In the case of cellular networks, the considerations regarding DNSSEC 721 may appear as out-of-scope, because UEs OSs, commonly don't support 722 DNSSEC, however applications running on them may do, or it may be an 723 OS "built-in" support in the future. Moreover, if those devices 724 offer tethering, other client devices may be doing the validation, 725 hence the relevance of a proper DNSSEC support by the operator 726 network. 728 Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and 729 "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" 730 ([RFC7050]), allow a progressive IPv6 deployment, with a single APN 731 supporting all types of PDP context (IPv4, IPv6, IPv4v6), in such way 732 that the network is able to automatically serve all the possible 733 combinations of UEs. 735 Finally, if the operator choose to secure the NAT64 prefix, it MUST 736 follow the advise indicated in Section 3.1.1. of [RFC7050] 737 (Validation of Discovered Pref64::/n). 739 12. Deployment of NAT64 in Enterprise Networks 741 The recommendations of this documents can be used as well in 742 enterprise networks, campus and other similar scenarios, when the 743 NAT64 is under the control of that network, and for whatever reasons, 744 there is a need to provide "IPv6-only access" to any part of that 745 network or it is IPv6-only connected to third party networks. 747 An example of that is the IETF meetings network itself, where a NAT64 748 and DNS64 are provided, presenting in this case the same issues as 749 per Section 3.2. If there is a CLAT in the IETF network, then there 750 is no need to use DNS64 and it falls under the considerations of 751 Section 3.5. Both scenarios have been tested and verified already in 752 the IETF network itself. 754 13. Security Considerations 756 This document does not have any new specific security considerations. 758 14. IANA Considerations 760 This document does not have any new specific IANA considerations. 762 Note: This section is assuming that https://www.rfc- 763 editor.org/errata/eid5152 is resolved, otherwise, this section may 764 include the required text to resolve the issue. 766 15. Acknowledgements 768 The author would like to acknowledge the inputs of TBD ... 770 Conversations with Marcelo Bagnulo, one of the co-authors of DNS64, 771 as well as several emails in public mailing lists from Mark Andrews, 772 have been very useful for this work. 774 Christian Huitema inspired working in this document by suggesting 775 that DNS64 should never be used, during a discussion regarding the 776 deployment of CLAT in the IETF network. 778 16. Normative References 780 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 781 and E. Lear, "Address Allocation for Private Internets", 782 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 783 . 785 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 786 Host Configuration Protocol (DHCP) version 6", RFC 3633, 787 DOI 10.17487/RFC3633, December 2003, 788 . 790 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 791 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 792 DOI 10.17487/RFC6052, October 2010, 793 . 795 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 796 NAT64: Network Address and Protocol Translation from IPv6 797 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 798 April 2011, . 800 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 801 Beijnum, "DNS64: DNS Extensions for Network Address 802 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 803 DOI 10.17487/RFC6147, April 2011, 804 . 806 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 807 Cheshire, "Internet Assigned Numbers Authority (IANA) 808 Procedures for the Management of the Service Name and 809 Transport Protocol Port Number Registry", BCP 165, 810 RFC 6335, DOI 10.17487/RFC6335, August 2011, 811 . 813 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 814 Using "Bump-in-the-Host" (BIH)", RFC 6535, 815 DOI 10.17487/RFC6535, February 2012, 816 . 818 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 819 Combination of Stateful and Stateless Translation", 820 RFC 6877, DOI 10.17487/RFC6877, April 2013, 821 . 823 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 824 the IPv6 Prefix Used for IPv6 Address Synthesis", 825 RFC 7050, DOI 10.17487/RFC7050, November 2013, 826 . 828 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 829 Port Control Protocol (PCP)", RFC 7225, 830 DOI 10.17487/RFC7225, May 2014, 831 . 833 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 834 /64 Prefix from a Third Generation Partnership Project 835 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 836 DOI 10.17487/RFC7278, June 2014, 837 . 839 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 840 "IP/ICMP Translation Algorithm", RFC 7915, 841 DOI 10.17487/RFC7915, June 2016, 842 . 844 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 845 Better Connectivity Using Concurrency", RFC 8305, 846 DOI 10.17487/RFC8305, December 2017, 847 . 849 Author's Address 851 Jordi Palet Martinez 852 The IPv6 Company 853 Molino de la Navata, 75 854 La Navata - Galapagar, Madrid 28420 855 Spain 857 Email: jordi.palet@theipv6company.com 858 URI: http://www.theipv6company.com/