idnits 2.17.1 draft-ietf-v6ops-nat64-deployment-08.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 : ---------------------------------------------------------------------------- == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2019) is 1743 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-17) exists of draft-cheshire-sudn-ipv4only-dot-arpa-14 == Outdated reference: A later version (-07) exists of draft-huitema-quic-dnsoquic-06 == Outdated reference: A later version (-09) exists of draft-ietf-6man-ra-pref64-01 == Outdated reference: A later version (-29) exists of draft-ietf-tram-turnbis-27 == Outdated reference: A later version (-06) exists of draft-lmhp-v6ops-transition-comparison-03 == Outdated reference: A later version (-04) exists of draft-palet-v6ops-464xlat-opt-cdn-caches-02 Summary: 2 errors (**), 0 flaws (~~), 9 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: Informational July 11, 2019 5 Expires: January 12, 2020 7 Additional NAT64/464XLAT Deployment Guidelines in Operator and 8 Enterprise Networks 9 draft-ietf-v6ops-nat64-deployment-08 11 Abstract 13 This document describes how NAT64 (including 464XLAT) can be deployed 14 in an IPv6 network, whether cellular ISP, broadband ISP, or 15 enterprise, and possible optimizations. The document also discusses 16 issues to be considered when having IPv6-only connectivity, 17 regarding: a) DNS64, b) applications or devices that use literal IPv4 18 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or 19 applications. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 12, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 57 3. NAT64 Deployment Scenarios . . . . . . . . . . . . . . . . . 5 58 3.1. Known to Work . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1.1. Service Provider NAT64 with DNS64 . . . . . . . . . . 6 60 3.1.2. Service Provider Offering 464XLAT, with DNS64 . . . . 8 61 3.1.3. Service Provider Offering 464XLAT, without DNS64 . . 12 62 3.2. Known to Work Under Special Conditions . . . . . . . . . 14 63 3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 14 64 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 16 65 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only 66 remote network . . . . . . . . . . . . . . . . . . . 16 67 3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 17 68 4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 19 69 4.1. DNSSEC Considerations and Possible Approaches . . . . . . 19 70 4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 20 71 4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21 72 4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 22 73 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 22 74 4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22 75 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 23 76 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 23 77 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 23 78 4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 24 79 4.4.1. Manual Configuration of DNS . . . . . . . . . . . . . 25 80 4.4.2. DNS Privacy/Encryption Mechanisms . . . . . . . . . . 25 81 4.4.3. Split DNS and VPNs . . . . . . . . . . . . . . . . . 26 82 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 26 83 4.6. IPv4 literals and non-IPv6 Compliant APIs . . . . . . . . 26 84 4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 27 85 4.8. CLAT Translation Considerations . . . . . . . . . . . . . 27 86 4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 28 87 4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 28 88 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 28 89 6. Deployment of 464XLAT/NAT64 in Enterprise Networks . . . . . 31 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 93 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 34 94 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 37 95 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 38 96 13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 38 97 14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 38 98 15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 39 99 16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 39 100 17. ANNEX H: Changes from -05 to -06 . . . . . . . . . . . . . . 39 101 18. ANNEX H: Changes from -06 to -07 . . . . . . . . . . . . . . 39 102 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 103 19.1. Normative References . . . . . . . . . . . . . . . . . . 39 104 19.2. Informative References . . . . . . . . . . . . . . . . . 42 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 107 1. Introduction 109 Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 110 translation mechanism, which allows IPv6-only hosts to communicate 111 with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of 112 IPv4 public addresses sharing, among multiple IPv6-only hosts. 113 Unless otherwise stated, references in the rest of this document to 114 NAT64 (function) should be interpreted as to Stateful NAT64. 116 The translation of the packet headers is done using the IP/ICMP 117 translation algorithm defined in [RFC7915] and algorithmically 118 translating the IPv4 addresses to IPv6 addresses and vice versa, 119 following [RFC6052]. 121 DNS64 ([RFC6147]) is in charge of the synthesis of AAAA records from 122 the A records, so only works for applications making use of DNS. It 123 was designed to avoid changes in both, the IPv6-only hosts and the 124 IPv4-only server, so they can use a NAT64 function. As discussed in 125 Section 5.5 of [RFC6147], a security-aware and validating host has to 126 perform the DNS64 function locally. 128 However, the use of NAT64 and/or DNS64 present three drawbacks: 130 a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is 131 designed to detect such modifications, DNS64 ([RFC6147]) may 132 potentially break DNSSEC, depending on a number of factors, such 133 as the location of the DNS64 function (at a DNS server or 134 validator, at the end host, ...), how it has been configured, if 135 the end-hosts is validating, etc. 137 b. Because the need of using DNS64 ([RFC6147]) or an alternative 138 "host/application built-in" mechanism for address synthesis, 139 there may be an issue for NAT64 ([RFC6146]), as it doesn't work 140 when IPv4 literal addresses or non-IPv6 compliant APIs are being 141 used. 143 c. NAT64 alone, was not designed to provide a solution for IPv4-only 144 hosts or applications located within a network which are 145 connected to a service provider IPv6-only access, as it was 146 designed for a very specific scenario ([RFC6144], Section 2.1). 148 Above drawbacks may be true if part of, an enterprise network, is 149 connected to other parts of the same network or third-party networks 150 by means of IPv6-only connectivity. This is just an example which 151 may apply to many other similar cases. All them are deployment 152 specific. 154 According to that, across this document, the use of "operator", 155 "operator network", "service provider", and similar ones, are 156 interchangeable with equivalent cases of enterprise networks (and 157 similar ones). This may be also the case for "managed end-user 158 networks". 160 Note that if all the hosts in a network were performing the address 161 synthesis, as described in Section 7.2 of [RFC6147], some of the 162 drawbacks may vanish. However, it is unrealistic today to expect 163 that, considering the high number of devices and applications that 164 aren't yet IPv6-enabled. So, in this document, this will be 165 considered only for specific scenarios that can guarantee it. 167 An analysis of stateful IPv4/IPv6 mechanisms is provided in 168 [RFC6889]. 170 This document looks into different possible NAT64 ([RFC6146]) 171 deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and 172 similar ones, which were not documented in [RFC6144], such as 464XLAT 173 ([RFC6877]), in operator (broadband and cellular) and enterprise 174 networks, and provides guidelines to avoid operational issues. 176 Towards that, this document first looks into the possible NAT64 177 deployment scenarios (split in "known to work" and "known to work 178 under special conditions"), providing a quick and generic comparison 179 table among them. Then the document describes the issues that an 180 operator need to understand on different matters that will allow to 181 define what is the best approach/scenario for each specific network 182 case. A summary provides some recommendations and decision points. 183 A section with clarifications on the usage of this document for 184 enterprise networks, is also provided. Finally, an annex provides an 185 example of a broadband deployment using 464XLAT and another annex 186 provides hints for a CLAT implementation. 188 [RFC7269] already provides information about NAT64 deployment options 189 and experiences. Both, this document and [RFC7269] are 190 complementary; they are looking into different deployment 191 considerations and furthermore, this document is considering the 192 updated deployment experience and newer standards. 194 The target deployment scenarios in this document may be covered as 195 well by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. 196 Note that this is true only for the case of broadband networks, as in 197 the case of cellular networks the only supported solution is the use 198 of NAT64/464XLAT. So, it is out of scope of this document to provide 199 a comparison among the different IPv4aaS transition mechanisms, which 200 is being analyzed already in [I-D.lmhp-v6ops-transition-comparison]. 202 Consequently, this document should not be understood as a guide for 203 an operator or enterprise to decide which IPv4aaS is the best one for 204 its own network. Instead it should be used as a tool for 205 understanding all the implications, including relevant documents (or 206 even specific parts of them), for the deployment of NAT64/464XLAT and 207 facilitate the decision process regarding specific deployment 208 details. 210 2. Requirements Language 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 214 "OPTIONAL" in this document are to be interpreted as described in BCP 215 14 [RFC2119] [RFC8174] when, and only when, they appear in all 216 capitals, as shown here. 218 3. NAT64 Deployment Scenarios 220 Section 7 of DNS64 ([RFC6147]), provides three scenarios, depending 221 on the location of the DNS64 function. However, since the 222 publication of that document, other deployment scenarios and NAT64 223 use cases need to be considered in actual networks, despite some of 224 them were specifically ruled out by the original NAT64/DNS64 work. 226 Consequently, the perspective in this document is to broaden those 227 scenarios, including a few new ones. However, in order to be able to 228 reduce the number of possible cases, we work under the assumption 229 that typically, the service provider wants to make sure that all the 230 customers have a service without failures. This means considering 231 the following assumptions for the worst possible case: 233 a. There are hosts that will be validating DNSSEC. 235 b. IPv4 literal addresses and non-IPv6 compliant APIs are being 236 used. 238 c. There are IPv4-only hosts or applications beyond the IPv6-only 239 link (e.g., tethering in cellular networks). 241 The document uses a common set of possible "participant entities": 243 1. An IPv6-only access network (IPv6). 245 2. An IPv4-only remote network/server/service (IPv4). 247 3. A NAT64 function (NAT64) in the service provider. 249 4. A DNS64 function (DNS64) in the service provider. 251 5. An external service provider offering the NAT64 function and/or 252 the DNS64 function (extNAT64/extDNS64). 254 6. 464XLAT customer side translator (CLAT). 256 Note that the nomenclature used in parenthesis is the one that, for 257 short, will be used in the figures. Note also that for simplicity, 258 the boxes in the figures don't mean they are actually a single 259 device; they just represent one or more functions as located in that 260 part of the network (i.e. a single box with NAT64 and DNS64 functions 261 can actually be several devices, not just one). 263 The possible scenarios are split in two general categories: 265 1. Known to work. 267 2. Known to work under special conditions. 269 3.1. Known to Work 271 The scenarios in this category are known to work, as there are well- 272 known existing deployments from different operators using them. Each 273 one may have different pros and cons, and in some cases the trade- 274 offs, maybe acceptable for some operators. 276 3.1.1. Service Provider NAT64 with DNS64 278 In this scenario (Figure 1), the service provider offers both, the 279 NAT64 and the DNS64 functions. 281 This is the most common scenario as originally considered by the 282 designers of NAT64 ([RFC6146]) and DNS64 ([RFC6147]), however also 283 may have the implications related the DNSSEC. 285 This scenario also may fail to solve the issue of IPv4 literal 286 addresses or non-IPv6 compliant APIs, as well as the issue of 287 IPv4-only hosts or applications behind the IPv6-only access network. 289 +----------+ +----------+ +----------+ 290 | | | NAT64 | | | 291 | IPv6 +--------+ + +--------+ IPv4 | 292 | | | DNS64 | | | 293 +----------+ +----------+ +----------+ 295 Figure 1: NAT64 with DNS64 297 A similar scenario (Figure 2) will be if the service provider offers 298 only the DNS64 function, and the NAT64 function is provided by an 299 outsourcing agreement with an external provider. All the 300 considerations in the previous paragraphs of this section, are the 301 same for this sub-case. 303 +----------+ +----------+ 304 | | | | 305 | extNAT64 +--------+ IPv4 | 306 | | | | 307 +----+-----+ +----------+ 308 | 309 | 310 +----------+ +----+-----+ 311 | | | | 312 | IPv6 +--------+ DNS64 + 313 | | | | 314 +----------+ +----------+ 316 Figure 2: NAT64 in external service provider 318 This is equivalent to the scenario (Figure 3) where the outsourcing 319 agreement with the external provider is to provide both the NAT64 and 320 DNS64 functions. Once more, all the considerations in the previous 321 paragraphs of this section are the same for this sub-case. 323 +----------+ +----------+ 324 | extNAT64 | | | 325 | + +-------+ IPv4 | 326 | extDNS64 | | | 327 +----+-----+ +----------+ 328 | 329 +----------+ | 330 | | | 331 | IPv6 +-------------+ 332 | | 333 +----------+ 335 Figure 3: NAT64 and DNS64 in external provider 337 One additional equivalent scenario (Figure 4) will be if the service 338 provider offers the NAT64 function only, and the DNS64 function is 339 from an external provider with or without a specific agreement among 340 them. This is a scenario already common today, as several "global" 341 service providers provide free DNS/DNS64 services and users often 342 configure manually their DNS. This will only work if both the NAT64 343 and the DNS64 functions are using the WKP (Well-Known Prefix) or the 344 same NSP (Network-Specific Prefix). All the considerations in the 345 previous paragraphs of this section, are the same for this sub-case. 347 Of course, if the external DNS64 function is agreed with the service 348 provider, then we are in the same case as in the previous ones 349 already depicted in this scenario. 351 +----------+ 352 | | 353 | extDNS64 | 354 | | 355 +----+-----+ 356 | 357 | 358 +----------+ +----+-----+ +----------+ 359 | | | | | | 360 | IPv6 +--------+ NAT64 +--------+ IPv4 | 361 | | | | | | 362 +----------+ +----------+ +----------+ 364 Figure 4: NAT64; DNS64 by external provider 366 3.1.2. Service Provider Offering 464XLAT, with DNS64 368 464XLAT ([RFC6877]) describes an architecture that provides IPv4 369 connectivity across a network, or part of it, when it is only 370 natively transporting IPv6. [RFC7849] already suggest the need to 371 support the CLAT function in order to ensure the IPv4 service 372 continuity in IPv6-only cellular deployments. 374 In order to do that, 464XLAT ([RFC6877]) relies on the combination of 375 existing protocols: 377 1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6 378 translator (NAT46) ([RFC7915]) implemented in the end-user device 379 or CE (Customer Edge Router), located at the "customer edge" of 380 the network. 382 2. The provider-side translator (PLAT) is a stateful NAT64 383 ([RFC6146]), implemented typically at in the operator network. 385 3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a 386 single translation at the NAT64, instead of two translations 387 (NAT46+NAT64), when the application at the end-user device 388 supports IPv6 DNS (uses AAAA Resource Records). 390 Note that even if in the 464XLAT ([RFC6877]) terminology, the 391 provider-side translator is referred as PLAT, for simplicity and 392 uniformity, across this document is always referred as NAT64 393 (function). 395 In this scenario (Figure 5) the service provider deploys 464XLAT with 396 a DNS64 function. 398 As a consequence, the DNSSEC issues remain, unless the host is doing 399 the address synthesis. 401 464XLAT ([RFC6877]) is a very simple approach to cope with the major 402 NAT64+DNS64 drawback: Not working with applications or devices that 403 use literal IPv4 addresses or non-IPv6 compliant APIs. 405 464XLAT ([RFC6877]) has been used initially mainly in IPv6-only 406 cellular networks. By supporting a CLAT function, the end-user 407 device applications can access IPv4-only end-networks/applications, 408 despite those applications or devices use literal IPv4 addresses or 409 non-IPv6 compliant APIs. 411 In addition to that, in the same example of the cellular network 412 above, if the User Equipment (UE) provides tethering, other devices 413 behind it will be presented with a traditional NAT44, in addition to 414 the native IPv6 support, so clearly it allows IPv4-only hosts behind 415 the IPv6-only access network. 417 Furthermore, as discussed in [RFC6877], 464XLAT can be used in 418 broadband IPv6 network architectures, by implementing the CLAT 419 function at the CE. 421 The support of this scenario in a network, offers two additional 422 advantages: 424 o DNS load optimization: A CLAT should implement a DNS proxy (as per 425 [RFC5625]), so that only IPv6 native queries and only for AAAA 426 records are sent to the DNS64 server. Otherwise doubling the 427 number of queries may impact the DNS infrastructure. 429 o Connection establishment delay optimization: If the UE/CE 430 implementation is detecting the presence of a DNS64 function, it 431 may issue only the AAAA query, instead of both the AAAA and A 432 queries. 434 In order to understand all the communication possibilities, let's 435 assume the following representation of two dual-stack peers: 437 +-------+ .-----. .-----. 438 | | / \ / \ 439 .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ 440 / Local \ | SOHO +--( only )---( NAT64 )---( only ) 441 / \ | | \ flow /\ `-----' \ flow / 442 ( Dual- )--+ IPv6 | \ / \ / \ / 443 \ Stack / | CE | `--+--' \ .-----. / `--+--' 444 \ Peer / | with | | \ / Remote\/ | 445 `-----' | CLAT | +---+----+ / \ +---+----+ 446 | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| 447 +-------+ | with | \ Stack / +--------+ 448 | DNS64 | \ Peer / 449 +--------+ `-----' 451 Figure A: Representation of 464XLAT among two peers with DNS64 453 The possible communication paths, among the IPv4/IPv6 stacks of both 454 peers, in this case, are: 456 a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among 457 peers. 459 b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. 461 c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT 462 implements EAM (Explicit Address Mappings) as indicated by 463 Section 4.9. In principle, it is not expected that services are 464 deployed in Internet using IPv6-only, unless there is certainty 465 that peers will also be IPv6-capable. 467 d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations. 469 e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the 470 CLAT implements EAM as indicated by Section 4.9, instead of using 471 the path d. above, NAT64 translation is avoided and the flow will 472 use IPv6 from the CLAT to the destination. 474 The rest of the figures in this section show different choices for 475 placing the different elements. 477 +----------+ +----------+ +----------+ 478 | IPv6 | | NAT64 | | | 479 | + +--------+ + +--------+ IPv4 | 480 | CLAT | | DNS64 | | | 481 +----------+ +----------+ +----------+ 483 Figure 5: 464XLAT with DNS64 485 A similar scenario (Figure 6) will be if the service provider offers 486 only the DNS64 function, and the NAT64 function is provided by an 487 outsourcing agreement with an external provider. All the 488 considerations in the previous paragraphs of this section are the 489 same for this sub-case. 491 +----------+ +----------+ 492 | | | | 493 | extNAT64 +--------+ IPv4 | 494 | | | | 495 +----+-----+ +----------+ 496 | 497 | 498 +----------+ +----+-----+ 499 | IPv6 | | | 500 | + +--------+ DNS64 + 501 | CLAT | | | 502 +----------+ +----------+ 504 Figure 6: 464XLAT with DNS64; NAT64 in external provider 506 As well, is equivalent to the scenario (Figure 7) where the 507 outsourcing agreement with the external provider is to provide both 508 the NAT64 and DNS64 functions. Once more, all the considerations in 509 the previous paragraphs of this section are the same for this sub- 510 case. 512 +----------+ +----------+ 513 | extNAT64 | | | 514 | + +--------+ IPv4 | 515 | extDNS64 | | | 516 +----+-----+ +----------+ 517 | 518 +----------+ | 519 | IPv6 | | 520 | + +-------------+ 521 | CLAT | 522 +----------+ 524 Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider 526 3.1.3. Service Provider Offering 464XLAT, without DNS64 528 The major advantage of this scenario (Figure 8), using 464XLAT 529 without DNS64, is that the service provider ensures that DNSSEC is 530 never broken, even in case the user modifies the DNS configuration. 531 Nevertheless, some CLAT implementations or applications may impose an 532 extra delay, which is induced by the dual A/AAAA queries (and wait 533 for both responses), unless Happy Eyeballs v2 ([RFC8305]) is also 534 present. 536 A possible variation of this scenario is the case when DNS64 is used 537 only for the discovery of the NAT64 prefix. The rest of the document 538 is not considering it as a different scenario, because once the 539 prefix has been discovered, the DNS64 function is not used, so it 540 behaves as if the DNS64 synthesis function is not present. 542 In this scenario, as in the previous one, there are no issues related 543 to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only 544 access network, neither related to the usage of IPv4 literals or non- 545 IPv6 compliant APIs. 547 The support of this scenario in a network, offers one advantage: 549 o DNS load optimization: A CLAT should implement a DNS proxy (as per 550 [RFC5625]), so that only IPv6 native queries are sent to the DNS64 551 server. Otherwise doubling the number of queries may impact the 552 DNS infrastructure. 554 As indicated earlier, the connection establishment delay optimization 555 is achieved only in the case of devices, Operating Systems, or 556 applications that use Happy Eyeballs v2 ([RFC8305]), which is very 557 common. 559 Let's assume the representation of two dual-stack peers as in the 560 previous case: 562 +-------+ .-----. .-----. 563 | | / \ / \ 564 .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ 565 / Local \ | SOHO +--( only )---( NAT64 )---( only ) 566 / \ | | \ flow /\ `-----' \ flow / 567 ( Dual- )--+ IPv6 | \ / \ / \ / 568 \ Stack / | CE | `--+--' \ .-----. / `--+--' 569 \ Peer / | with | | \ / Remote\/ | 570 `-----' | CLAT | +---+----+ / \ +---+----+ 571 | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| 572 +-------+ +--------+ \ Stack / +--------+ 573 \ Peer / 574 `-----' 576 Figure B: Representation of 464XLAT among two peers without DNS64 578 The possible communication paths, among the IPv4/IPv6 stacks of both 579 peers, in this case, are: 581 a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among 582 peers. 584 b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64 585 translations. 587 c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT 588 implements EAM as indicated by Section 4.9. In principle, it is 589 not expected that services are deployed in Internet using 590 IPv6-only, unless there is certainty that peers will also be 591 IPv6-capable. 593 d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 594 translations. 596 e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the 597 CLAT implements EAM as indicated by Section 4.9, instead of using 598 the path d. above, NAT64 translation is avoided and the flow will 599 use IPv6 from the CLAT to the destination. 601 It needs to be noticed that this scenario works while the local 602 hosts/applications are dual-stack (which is the current situation), 603 because the connectivity from a local-IPv6 to a remote-IPv4 is not 604 possible without an AAAA synthesis. This aspect is important only 605 when in the LANs behind the CLAT there are IPv6-only hosts and they 606 need to communicate with remote IPv4-only hosts. However, it doesn't 607 look a sensible approach from an Operating System or application 608 vendor perspective, to provide IPv6-only support unless, similarly to 609 case c above, there is certainty of peers supporting IPv6 as well. A 610 solution approach to this is also presented in 611 [I-D.palet-v6ops-464xlat-opt-cdn-caches]. 613 The following figures show different choices for placing the 614 different elements. 616 +----------+ +----------+ +----------+ 617 | IPv6 | | | | | 618 | + +--------+ NAT64 +--------+ IPv4 | 619 | CLAT | | | | | 620 +----------+ +----------+ +----------+ 622 Figure 8: 464XLAT without DNS64 624 This is equivalent to the scenario (Figure 9) where there is an 625 outsourcing agreement with an external provider for the NAT64 626 function. All the considerations in the previous paragraphs of this 627 section are the same for this sub-case. 629 +----------+ +----------+ 630 | | | | 631 | extNAT64 +--------+ IPv4 | 632 | | | | 633 +----+-----+ +----------+ 634 | 635 +----------+ | 636 | IPv6 | | 637 | + +-------------+ 638 | CLAT | 639 +----------+ 641 Figure 9: 464XLAT without DNS64; NAT64 in external provider 643 3.2. Known to Work Under Special Conditions 645 The scenarios in this category are known to not work unless 646 significant effort is devoted to solve the issues, or are intended to 647 solve problems across "closed" networks, instead of as a general 648 Internet access usage. In addition to the different pros, cons and 649 trade-offs, which may be acceptable for some operators, they have 650 implementation difficulties, as they are beyond the original 651 expectations of the NAT64/DNS64 original intent. 653 3.2.1. Service Provider NAT64 without DNS64 655 In this scenario (Figure 10), the service provider offers a NAT64 656 function, however there is no DNS64 function support at all. 658 As a consequence, an IPv6 host in the IPv6-only access network, will 659 not be able to detect the presence of DNS64 by means of [RFC7050], 660 neither to learn the IPv6 prefix to be used for the NAT64 function. 662 This can be sorted out as indicated in Section 4.1.1. 664 However, despite that, because the lack of the DNS64 function, the 665 IPv6 host will not be able to obtain AAAA synthesized records, so the 666 NAT64 function becomes useless. 668 An exception to this "useless" scenario will be manually configure 669 mappings between the A records of each of the IPv4-only remote hosts 670 and the corresponding AAAA records, with the WKP (Well-Known Prefix) 671 or NSP (Network-Specific Prefix) used by the service provider NAT64 672 function, as if they were synthesized by a DNS64 function. 674 This mapping could be done by several means, typically at the 675 authoritative DNS server, or at the service provider resolvers by 676 means of DNS RPZ (Response Policy Zones, [I-D.vixie-dns-rpz]) or 677 equivalent functionality. DNS RPZ, may have implications in DNSSEC, 678 if the zone is signed. Also, if the service provider is using an 679 NSP, having the mapping at the authoritative server, may create 680 troubles to other parties trying to use different NSP or the WKP, 681 unless multiple DNS "views" (split-DNS) is also being used at the 682 authoritative servers. 684 Generally, the mappings alternative, will only make sense if a few 685 set of IPv4-only remote hosts need to be accessed by a single network 686 (or a small number of them), which support IPv6-only in the access. 687 This will require some kind of mutual agreement for using this 688 procedure, so it doesn't care if they become a trouble for other 689 parties across Internet ("closed services"). 691 In any case, this scenario doesn't solve the issue of IPv4 literal 692 addresses or non-IPv6 compliant APIs, neither it solves the problem 693 of IPv4-only hosts within that IPv6-only access network. 695 +----------+ +----------+ +----------+ 696 | | | | | | 697 | IPv6 +--------+ NAT64 +--------+ IPv4 | 698 | | | | | | 699 +----------+ +----------+ +----------+ 701 Figure 10: NAT64 without DNS64 703 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts 705 In this scenario (Figure 11), the service provider offers the NAT64 706 function, but not the DNS64 function. However, the IPv6 hosts have a 707 built-in DNS64 function. 709 This may become common if the DNS64 function is implemented in all 710 the IPv6 hosts/stacks. However, commonly this is not the actual 711 situation, even if it may happen in the medium-term. At this way, 712 the DNSSEC validation is performed on the A record, and then the host 713 can use the DNS64 function so to be able to use the NAT64 function, 714 without any DNSSEC issues. 716 This scenario fails to solve the issue of IPv4 literal addresses or 717 non-IPv6 compliant APIs, unless the IPv6 hosts also supports Happy 718 Eyeballs v2 ([RFC8305], Section 7.1), which may solve that issue. 720 However, this scenario still fails to solve the problem of IPv4-only 721 hosts or applications behind the IPv6-only access network. 723 +----------+ +----------+ +----------+ 724 | IPv6 | | | | | 725 | + +--------+ NAT64 +--------+ IPv4 | 726 | DNS64 | | | | | 727 +----------+ +----------+ +----------+ 729 Figure 11: NAT64; DNS64 in IPv6 hosts 731 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network 733 In this scenario (Figure 12), the service provider offers the NAT64 734 function only. The remote IPv4-only network offers the DNS64 735 function. 737 This is not common, and looks like doesn't make too much sense that a 738 remote network, not deploying IPv6, is providing a DNS64 function. 739 As in the case of the scenario depicted in Section 3.2.1, it will 740 only work if both sides are using the WKP or the same NSP, so the 741 same considerations apply. It can be also tuned to behave as in 742 Section 3.1.1 744 This scenario still fails to solve the issue of IPv4 literal 745 addresses or non-IPv6 compliant APIs. 747 This scenario also fails to solve the problem of IPv4-only hosts or 748 applications behind the IPv6-only access network. 750 +----------+ +----------+ +----------+ 751 | | | | | IPv4 | 752 | IPv6 +--------+ NAT64 +--------+ + | 753 | | | | | DNS64 | 754 +----------+ +----------+ +----------+ 756 Figure 12: NAT64; DNS64 in the IPv4-only 758 3.3. Comparing the Scenarios 760 This section compares the different scenarios, including the possible 761 variations (each one represented in the precedent sections by a 762 different figure), looking at the following criteria: 764 a. DNSSEC: Are there hosts validating DNSSEC? 766 b. Literal/APIs: Are there applications using IPv4 literals or non- 767 IPv6 compliant APIs? 769 c. IPv4-only: Are there hosts or applications using IPv4-only? 771 d. Foreign DNS: Is the scenario surviving if the user, Operating 772 System, applications or devices change the DNS? 774 e. DNS load opt. (DNS load optimization): Are there extra queries 775 that may impact DNS infrastructure? 777 f. Connect. opt. (Connection establishment delay optimization): Is 778 the UE/CE issuing only the AAAA query or also an A query and 779 waiting for both responses? 781 In the next table, the columns represent each of the scenarios from 782 the previous sections, by the figure number. The possible values 783 are: 785 o "-" Scenario "bad" for that criteria. 787 o "+" Scenario "good" for that criteria. 789 o "*" Scenario "bad" for that criteria, however it is typically 790 resolved, with the support of Happy Eyeballs v2 ([RFC8305]). 792 In some cases, "countermeasures", alternative or special 793 configurations, may be available for the criteria designated as 794 "bad". So, this comparison is considering a generic case, as a quick 795 comparison guide. In some cases, a "bad" criterion is not 796 necessarily a negative aspect, all it depends on the specific needs/ 797 characteristics of the network where the deployment will take place. 799 For instance, in a network which has only IPv6-only hosts and apps 800 using only DNS and IPv6-compliant APIs, there is no impact using only 801 NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is 802 still relevant. 804 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 805 | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 806 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 807 | DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + | 808 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 809 | Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - | 810 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 811 | IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - | 812 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 813 | Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - | 814 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 815 | DNS load opt. | + | + | + | + | + | + | + | + | + | + | + | + | 816 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 817 | Connect. opt. | + | + | + | + | + | + | + | * | * | + | + | + | 818 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 820 Figure 13: Scenario Comparison 822 As a general conclusion, we should note that, if the network must 823 support applications using any of the following: 825 o IPv4 literals 827 o non-IPv6-compliant APIs 829 o IPv4-only hosts or applications 831 Then, only the scenarios with 464XLAT, a CLAT function, or equivalent 832 built-in local address synthesis features, will provide a valid 833 solution. Further to that, those scenarios will also keep working if 834 the DNS configuration is modified. Clearly also, depending on if 835 DNS64 is used or not, DNSSEC may be broken for those hosts doing 836 DNSSEC validation. 838 All the scenarios are good in terms of DNS load optimization, and in 839 the case of 464XLAT it may provide an extra degree of optimization. 840 Finally, all them are also good in terms of connection establishment 841 delay optimization. However, in the case of 464XLAT without DNS64, 842 it requires the usage of Happy Eyeballs v2. This is not an issue, as 843 commonly it is available in actual Operating Systems. 845 4. Issues to be Considered 847 This section reviews the different issues that an operator needs to 848 consider towards a NAT64/464XLAT deployment, as they may bring to 849 specific decision points about how to approach that deployment. 851 4.1. DNSSEC Considerations and Possible Approaches 853 As indicated in Section 8 of [RFC6147] (DNS64, Security 854 Considerations), because DNS64 modifies DNS answers and DNSSEC is 855 designed to detect such modifications, DNS64 may break DNSSEC. 857 If a device connected to an IPv6-only access network, queries for a 858 domain name in a signed zone, by means of a recursive name server 859 that supports DNS64, and the result is a synthesized AAAA record, and 860 the recursive name server is configured to perform DNSSEC validation 861 and has a valid chain of trust to the zone in question, it will 862 cryptographically validate the negative response from the 863 authoritative name server. This is the expected DNS64 behavior: The 864 recursive name server actually "lies" to the client device. However, 865 in most of the cases, the client will not notice it, because 866 generally, they don't perform validation themselves and instead, rely 867 on the recursive name servers. 869 A validating DNS64 resolver in fact, increase the confidence on the 870 synthetic AAAA, as it has validated that a non-synthetic AAAA for 871 sure, doesn't exists. However, if the client device is 872 NAT64-oblivious (most common case) and performs DNSSEC validation on 873 the AAAA record, it will fail as it is a synthesized record. 875 The best possible scenario from DNSSEC point of view, is when the 876 client requests the DNS64 server to perform the DNSSEC validation (by 877 setting the DO bit to 1 and the CD bit to 0). In this case, the 878 DNS64 server validates the data, thus tampering may only happen 879 inside the DNS64 server (which is considered as a trusted part, thus 880 its likelihood is low) or between the DNS64 server and the client. 881 All other parts of the system (including transmission and caching) 882 are protected by DNSSEC ([Threat-DNS64]). 884 Similarly, if the client querying the recursive name server is 885 another name server configured to use it as a forwarder, and is 886 performing DNSSEC validation, it will also fail on any synthesized 887 AAAA record. 889 All those considerations are extensively covered in Sections 3, 5.5 890 and 6.2 of [RFC6147]. 892 A solution to avoid DNSSEC issues, will be that all the signed zones 893 also provide IPv6 connectivity, together with the corresponding AAAA 894 records. However, this is out of the control of the operator needing 895 to deploy a NAT64 function. This has been proposed already in 896 [I-D.bp-v6ops-ipv6-ready-dns-dnssec]. 898 An alternative solution, which was the one considered while 899 developing [RFC6147], is that validators will be DNS64-aware, so 900 could perform the necessary discovery and do their own synthesis. 901 That was done under the expectation that it was sufficiently early in 902 the validator-deployment curve that it would be ok to break certain 903 DNSSEC assumptions for networks who were really stuck in a NAT64/ 904 DNS64-needing world. 906 As already indicated, the scenarios in the previous section, are in 907 fact somehow simplified, looking at the worst possible case. Saying 908 it in a different way: "trying to look for the most perfect 909 approach". DNSSEC breach will not happen if the end-host is not 910 doing validation. 912 Existing previous studies seems to indicate that the figures of 913 DNSSEC actually broken by using DNS64 will be around 1.7% 914 ([About-DNS64]) of the cases. However, we can't negate that this may 915 increase, as DNSSEC deployment grows. Consequently, a decision point 916 for the operator must depend on "do I really care for that percentage 917 of cases and the impact in my helpdesk or can I provide alternative 918 solutions for them?". Some possible solutions may be taken, as 919 depicted in the next sections. 921 4.1.1. Not using DNS64 923 A solution will be to avoid using DNS64, but as already indicated 924 this is not possible in all the scenarios. 926 The use of DNS64 is a key component for some networks, in order to 927 comply with traffic performance metrics, monitored by some 928 governmental bodies and other institutions ([FCC], [ARCEP]). 930 One drawback of not having a DNS64 at the network side, is that is 931 not possible to heuristically discover the NAT64 ([RFC7050]). 932 Consequently, an IPv6 host behind the IPv6-only access network, will 933 not be able to detect the presence of the NAT64 function, neither to 934 learn the IPv6 prefix to be used for it, unless it is configured by 935 alternative means. 937 The discovery of the IPv6 prefix could be solved, as described in 938 [RFC7050], by means of adding the relevant AAAA records to the 939 ipv4only.arpa. zone, of the service provider recursive servers, i.e., 940 if using the WKP (64:ff9b::/96): 942 ipv4only.arpa. SOA . . 0 0 0 0 0 943 ipv4only.arpa. NS . 944 ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 945 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 946 ipv4only.arpa. A 192.0.0.170 947 ipv4only.arpa. A 192.0.0.171 949 An alternative option to the above, is the use of DNS RPZ 950 ([I-D.vixie-dns-rpz]) or equivalent functionalities. Note that this 951 may impact DNSSEC if the zone is signed. 953 One more alternative, only valid in environments with PCP support 954 (for both the hosts or CEs and for the service provider network), is 955 to follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). 957 Other alternatives may be available in the future. All them are 958 extensively discussed in [RFC7051], however the deployment evolution 959 has evolved many considerations from that document. New options are 960 being documented, such using Router Advertising 961 ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options 962 ([I-D.li-intarea-nat64-prefix-dhcp-option]). 964 It may be convenient the simultaneous support of several of the 965 possible approaches, in order to ensure that clients with different 966 ways to configure the NAT64 prefix, successfully obtain it. This is 967 also convenient even if DNS64 is being used. 969 Of special relevance to this section is also 970 [I-D.cheshire-sudn-ipv4only-dot-arpa]. 972 4.1.2. DNSSEC validator aware of DNS64 974 In general, by default, DNS servers with DNS64 function will not 975 synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the 976 query. 978 In this case, as only an A record is available, if a CLAT function is 979 present, it means that the CLAT will take the responsibility, as in 980 the case of literal IPv4 addresses, to keep that traffic flow end-to- 981 end as IPv4, so DNSSEC is not broken. 983 However, this will not work if a CLAT function is not present as the 984 hosts will not be able to use IPv4 (which is the case for all the 985 scenarios without 464XLAT). 987 4.1.3. Stub validator 989 If the DO flag is set and the client device performs DNSSEC 990 validation, and the Checking Disabled (CD) flag is set for a query, 991 the DNS64 recursive server will not synthesize AAAA responses. In 992 this case, the client could perform the DNSSEC validation with the A 993 record and then synthesize the AAAA ([RFC6052]). For that to be 994 possible, the client must have learned beforehand the NAT64 prefix 995 using any of the available methods ([RFC7050], [RFC7225], 996 [I-D.ietf-6man-ra-pref64], 997 [I-D.li-intarea-nat64-prefix-dhcp-option]). This allows the client 998 device to avoid using the DNS64 function and still use NAT64 even 999 with DNSSEC. 1001 If the end-host is IPv4-only, this will not work if a CLAT function 1002 is not present (scenarios without 464XLAT). 1004 Some devices or Operating Systems may implement, instead of a CLAT, 1005 an equivalent function by using Bump-in-the-Host ([RFC6535]), 1006 implemented as part of Happy Eyeballs v2 (Section 7.1 of [RFC8305]). 1007 In this case, the considerations in the above paragraphs are also 1008 applicable. 1010 4.1.4. CLAT with DNS proxy and validator 1012 If a CE includes CLAT support and also a DNS proxy, as indicated in 1013 Section 6.4 of [RFC6877], the CE could behave as a stub validator on 1014 behalf of the client devices. Then, following the same approach 1015 described in the Section 4.1.3, the DNS proxy actually will "lie" to 1016 the client devices, which in most of the cases will not notice it, 1017 unless they perform validation by themselves. Again, this allow the 1018 client devices to avoid using the DNS64 function and still use NAT64 1019 with DNSSEC. 1021 Once more, this will not work without a CLAT function (scenarios 1022 without 464XLAT). 1024 4.1.5. ACL of clients 1026 In cases of dual-stack clients, the AAAA queries typically take 1027 preference over A queries. If DNS64 is enabled for those clients, 1028 will never get A records, even for IPv4-only servers. 1030 As a consequence, in cases where there are IPv4-only servers, and 1031 those are located in the path before the NAT64 function, the clients 1032 will not be able to reach them. If DNSSEC is being used for all 1033 those flows, specific addresses or prefixes can be left-out of the 1034 DNS64 synthesis by means of ACLs. 1036 Once more, this will not work without a CLAT function (scenarios 1037 without 464XLAT). 1039 4.1.6. Mapping-out IPv4 addresses 1041 If there are well-known specific IPv4 addresses or prefixes using 1042 DNSSEC, they can be mapped-out of the DNS64 synthesis. 1044 Even if this is not related to DNSSEC, this "mapping-out" feature is 1045 actually, quite commonly used to ensure that [RFC1918] addresses (for 1046 example used by LAN servers) are not synthesized to AAAA. 1048 Once more, this will not work without a CLAT function (scenarios 1049 without 464XLAT). 1051 4.2. DNS64 and Reverse Mapping 1053 When a client device, using DNS64 tries to reverse-map a synthesized 1054 IPv6 address, the name server responds with a CNAME record pointing 1055 the domain name used to reverse-map the synthesized IPv6 address (the 1056 one under ip6.arpa), to the domain name corresponding to the embedded 1057 IPv4 address (under in-addr.arpa). 1059 This is the expected behavior, so no issues need to be considered 1060 regarding DNS reverse mapping. 1062 4.3. Using 464XLAT with/without DNS64 1064 In the case the client device is IPv6-only (either because the stack 1065 or application is IPv6-only, or because it is connected via an 1066 IPv6-only LAN) and the remote server is IPv4-only (either because the 1067 stack is IPv4-only, or because it is connected via an IPv4-only LAN), 1068 only NAT64 combined with DNS64 will be able to provide access among 1069 both. Because DNS64 is then required, DNSSEC validation will be only 1070 possible if the recursive name server is validating the negative 1071 response from the authoritative name server and the client is not 1072 performing validation. 1074 Note that is not expected at this stage of the transition, that 1075 applications, devices or Operating Systems are IPv6-only. It will 1076 not be a sensible decision for a developer to work on that direction, 1077 unless it is clear that the deployment scenario fully supports it. 1079 On the other hand, an end-user or enterprise network may decide to 1080 run IPv6-only in the LANs. In case there is any chance for 1081 applications to be IPv6-only, the Operating System may be responsible 1082 either for doing a local address synthesis, or alternatively, setting 1083 up some kind of on-demand VPN (IPv4-in-IPv6), which need to be 1084 supported by that network. This may become very common in enterprise 1085 networks, where "Unique IPv6 Prefix per Host" [RFC8273] is supported. 1087 However, when the client device is dual-stack and/or connected in a 1088 dual-stack LAN by means of a CLAT function (or has a built-in CLAT 1089 function), DNS64 is an option. 1091 1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if 1092 using literal IPv4 addresses or non-IPv6 compliant APIs) will not 1093 use the CLAT, so will use the IPv6 path and only one translation 1094 will be done at the NAT64. This may break DNSSEC, unless 1095 measures as described in the precedent sections are taken. 1097 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will 1098 make use of the CLAT, so two translations are required (NAT46 at 1099 the CLAT and NAT64 at the PLAT), which adds some overhead in 1100 terms of the extra NAT46 translation. However, this avoids the 1101 AAAA synthesis and consequently will never break DNSSEC. 1103 Note that the extra translation, when DNS64 is not used, takes place 1104 at the CLAT, which means no extra overhead for the operator. It 1105 however adds potential extra delays to establish the connections, and 1106 no perceptible impact for a CE in a broadband network, while it may 1107 have some impact in a battery powered device. This cost for a 1108 battery powered device, is possibly comparable to the cost when the 1109 device is doing a local address synthesis (see Section 7.1 of 1110 [RFC8305]). 1112 4.4. Foreign DNS 1114 Clients, devices or applications in a service provider network, may 1115 use DNS servers from other networks. This may be the case either if 1116 individual applications use their own DNS server, the Operating 1117 System itself or even the CE, or combinations of the above. 1119 Those "foreign" DNS servers may not support DNS64, which as a 1120 consequence, will mean that those scenarios that require a DNS64 may 1121 not work. However, if a CLAT function is available, the 1122 considerations in Section 4.3 will apply. 1124 In the case that the foreign DNS supports the DNS64 function, we may 1125 be in the situation of providing incorrect configurations parameters, 1126 for example, un-matching WKP or NSP, or a case such the one described 1127 in Section 3.2.3. 1129 Having a CLAT function, even if using foreign DNS without a DNS64 1130 function, ensures that everything will work, so the CLAT must be 1131 considered as an advantage even against user configuration errors. 1133 The cost of this, is that all the traffic will use a double 1134 translation (NAT46 at the CLAT and NAT64 at the operator network), 1135 unless there is support for EAM (Section 4.9). 1137 An exception to that is the case when there is a CLAT function at the 1138 CE, which is not able to obtain the correct configuration parameters 1139 (again, un-matching WKP or NSP). 1141 However, it needs to be emphasized, that if there is not a CLAT 1142 function (scenarios without 464XLAT), an external DNS without DNS64 1143 support, will disallow any access to IPv4-only destination networks, 1144 and will not guarantee the correct DNSSEC validation, so will behave 1145 as in the Section 3.2.1. 1147 In summary, it can be said, that the consequences of the use of 1148 foreign DNS depend very much in each specific case. However, in 1149 general, if a CLAT function is present, most of the time, there will 1150 not be any. In the other cases, generally, the access to 1151 IPv6-enabled services is still guaranteed for IPv6-enabled hosts, but 1152 not for IPv4-only hosts, neither the access to IPv4-only services for 1153 any hosts in the network. 1155 The causes of "foreign DNS" could be classified in three main 1156 categories, as depicted in the following sub-sections. 1158 4.4.1. Manual Configuration of DNS 1160 It is becoming increasingly common that end-users or even devices or 1161 applications configure alternative DNS in their Operating Systems, 1162 and sometimes in CEs. 1164 4.4.2. DNS Privacy/Encryption Mechanisms 1166 Clients or applications may use mechanisms for DNS privacy/ 1167 encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS 1168 ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC 1169 ([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH 1170 and DoQ. 1172 Those DNS privacy/encryption options, currently are typically 1173 provided by the applications, not the Operating System vendors. At 1174 the time of writing this document, at least DoT and DoH standards 1175 have declared DNS64 (and consequently NAT64) out of their scope, so 1176 an application using them may break NAT64, unless a correctly 1177 configured CLAT function is used. 1179 4.4.3. Split DNS and VPNs 1181 When networks or hosts use "split-DNS" (also called Split Horizon, 1182 DNS views or private DNS), the successful use of the DNS64 is not 1183 guaranteed. Section 4 of [RFC6950], analyses this case. 1185 A similar situation may happen in case of VPNs that force all the DNS 1186 queries through the VPN, ignoring the operator DNS64 function. 1188 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 1190 Section 3 of [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), 1191 discusses some considerations which are useful to decide if an 1192 operator should use the WKP or an NSP. 1194 Taking in consideration that discussion and other issues, we can 1195 summarize the possible decision points as: 1197 a. The WKP MUST NOT be used to represent non-global IPv4 addresses. 1198 If this is required because the network to be translated use non- 1199 global addresses, then an NSP is required. 1201 b. The WKP MAY appear in inter-domain routing tables, if the 1202 operator provides a NAT64 function to peers. However, in this 1203 case, special considerations related to BGP filtering are 1204 required and IPv4-embedded IPv6 prefixes longer than the WKP MUST 1205 NOT be advertised (or accepted) in BGP. An NSP may be a more 1206 appropriate option in those cases. 1208 c. If several NAT64 use the same prefix, packets from the same flow 1209 may be routed to different NAT64 in case of routing changes. 1210 This can be avoided either by using different prefixes for each 1211 NAT64 function, or by ensuring that all the NAT64 coordinate 1212 their state. Using an NSP could simplify that. 1214 d. If DNS64 is required and users, devices, Operating Systems or 1215 applications may change their DNS configuration, and deliberately 1216 choose an alternative DNS64 function, most probably alternative 1217 DNS64 will use by default the WKP. In that case, if an NSP is 1218 used by the NAT64 function, clients will not be able to use the 1219 operator NAT64 function, which will break connectivity to 1220 IPv4-only destinations. 1222 4.6. IPv4 literals and non-IPv6 Compliant APIs 1224 A host or application using literal IPv4 addresses or older APIs, 1225 which aren't IPv6 compliant, behind a network with IPv6-only access, 1226 will not work unless any of the following alternatives is provided: 1228 o CLAT (or equivalent function). 1230 o Happy Eyeballs v2 (Section 7.1, [RFC8305]). 1232 o Bump-in-the-Host ([RFC6535]) with a DNS64 function. 1234 Those alternatives will solve the problem for an end-host. However, 1235 if that end-hosts is providing "tethering" or an equivalent service 1236 to other hosts, that needs to be considered as well. In other words, 1237 in a case of a cellular network, it resolves the issue for the UE 1238 itself, but may be not the case for hosts behind it. 1240 Otherwise, the support of 464XLAT is the only valid and complete 1241 approach to resolve this issue. 1243 4.7. IPv4-only Hosts or Applications 1245 An IPv4-only hosts or application behind a network with IPv6-only 1246 access, will not work unless a CLAT function is present. 1248 464XLAT is the only valid approach to resolve this issue. 1250 4.8. CLAT Translation Considerations 1252 As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if 1253 the CLAT function can be configured with a dedicated /64 prefix for 1254 the NAT46 translation, then it will be possible to do a more 1255 efficient stateless translation. 1257 Otherwise, if this dedicated prefix is not available, the CLAT 1258 function will need to do a stateful translation, for example 1259 performing stateful NAT44 for all the IPv4 LAN packets, so they 1260 appear as coming from a single IPv4 address, and then in turn, 1261 stateless translated to a single IPv6 address. 1263 A possible setup, in order to maximize the CLAT performance, is to 1264 configure the dedicated translation prefix. This can be easily 1265 achieved automatically, if the broadband CE or end-user device is 1266 able to obtain a shorter prefix by means of DHCPv6-PD ([RFC8415]), or 1267 other alternatives. The CE can then use a specific /64 for the 1268 translation. This is also possible when broadband is provided by a 1269 cellular access. 1271 The above recommendation is often not possible for cellular networks, 1272 when connecting smartphones (as UEs), as generally they don't use 1273 DHCPv6-PD ([RFC8415]). Instead, a single /64 is provided for each 1274 PDP context and prefix sharing ([RFC6877]) is used. So, in this 1275 case, the UEs typically have a build-in CLAT function which is 1276 performing a stateful NAT44 translation before the stateless NAT46. 1278 4.9. EAM Considerations 1280 Explicit Address Mappings for Stateless IP/ICMP Translation 1281 ([RFC7757]) provide a way to configure explicit mappings between IPv4 1282 and IPv6 prefixes of any length. When this is used, for example in a 1283 CLAT function, it may provide a simple mechanism in order to avoid 1284 traffic flows between IPv4-only nodes or applications and dual-stack 1285 destinations to be translated twice (NAT46 and NAT64), by creating 1286 mapping entries with the GUA of the IPv6-reachable destination. This 1287 optimization of the NAT64 usage is very useful in many scenarios, 1288 including CDNs and caches, as described in 1289 [I-D.palet-v6ops-464xlat-opt-cdn-caches]. 1291 In addition to that, it may provide as well a way for IPv4-only nodes 1292 or applications to communicate with IPv6-only destinations. 1294 4.10. Incoming Connections 1296 The use of NAT64, in principle, disallows IPv4 incoming connections, 1297 which may be still needed for IPv4-only peer-to-peer applications. 1298 However, there are several alternatives that resolve this issue: 1300 a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are 1301 commonly used by peer-to-peer applications in order to allow 1302 incoming connections with IPv4 NAT. In the case of NAT64, they 1303 work as well. RFC editor note: If in time, replace STUN and TURN 1304 with [I-D.ietf-tram-stunbis] / [I-D.ietf-tram-turnbis]. 1306 b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and 1307 IPv6 packets are translated and forwarded. A NAT64 may implement 1308 PCP to allow this service. 1310 c. EAM ([RFC7757]) may also be used in order to configure explicit 1311 mappings for customers that require them. This is used for 1312 example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]). 1314 5. Summary of Deployment Recommendations for NAT64/464XLAT 1316 NAT64/464XLAT has demonstrated to be a valid choice in several 1317 scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the predominant 1318 mechanism in the majority of the cellular networks, which account for 1319 hundreds of millions of users ([ISOC]). NAT64/464XLAT offer 1320 different choices of deployment, depending on each network case, 1321 needs and requirements. Despite that, this document is not an 1322 explicit recommendation for using this choice versus other IPv4aaS 1323 transition mechanisms. Instead, this document is a guide that 1324 facilitates evaluating a possible implementation of NAT64/464XLAT and 1325 key decision points about specific design considerations for its 1326 deployment. 1328 Depending on the specific requirements of each deployment case, DNS64 1329 may be a required function, while in other cases the adverse effects 1330 may be counterproductive. Similarly, in some cases a NAT64 function, 1331 together with a DNS64 function, may be a valid solution, when there 1332 is a certainty that IPv4-only hosts or applications do not need to be 1333 supported (Section 4.6 and Section 4.7). However, in other cases 1334 (i.e. IPv4-only devices or applications need to be supported), the 1335 limitations of NAT64/DNS64, may suggest the operator to look into 1336 464XLAT as a more complete solution. 1338 In the case of broadband managed networks (where the CE is provided 1339 or suggested/supported by the operator), in order to fully support 1340 the actual user needs (IPv4-only devices and applications, usage of 1341 IPv4 literals and non-IPv6 compliant APIs), the 464XLAT scenario 1342 should be considered. In that case, it must support a CLAT function. 1344 If the operator provides DNS services, in order to increase 1345 performance by reducing the double translation for all the IPv4 1346 traffic, they may support a DNS64 function and avoid, as much as 1347 possible, breaking DNSSEC. In this case, if the DNS service is 1348 offering DNSSEC validation, then it must be in such way that it is 1349 aware of the DNS64. This is considered the simpler and safer 1350 approach, and may be combined as well with other recommendations 1351 described in this document: 1353 o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). 1355 o Devices running CLAT SHOULD follow the indications in 1356 Section 4.1.3 (Stub Validator). However, this may be out of the 1357 control of the operator. 1359 o CEs SHOULD include a DNS proxy and validator (Section 4.1.4). 1361 o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4 1362 addresses) MAY be considered by operators, depending on their own 1363 infrastructure. 1365 This "increased performance" approach has the disadvantage of 1366 potentially breaking DNSSEC for a small percentage of validating end- 1367 hosts versus the small impact of a double translation taking place in 1368 the CE. If CE performance is not an issue, which is the most 1369 frequent case, then a much safer approach is to not use DNS64 at all, 1370 and consequently, ensure that all the IPv4 traffic is translated at 1371 the CLAT (Section 4.3). 1373 If DNS64 is not used, at least one of the alternatives described in 1374 Section 4.1.1, must be followed in order to learn the NAT64 prefix. 1376 The operator needs to consider that if the DNS configuration can be 1377 modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most 1378 probably is impossible to avoid, there are chances that instead of 1379 configuring a DNS64 a foreign non-DNS64 is used. In a scenario with 1380 only a NAT64 function IPv4-only remote host will no longer be 1381 accessible. Instead, it will continue to work in the case of 1382 464XLAT. 1384 Similar considerations need to be taken regarding the usage of a 1385 NAT64 WKP vs NSP (Section 4.5), as they must match with the 1386 configuration of the DNS64. In case of using foreign DNS, they may 1387 not match. If there is a CLAT and the configured foreign DNS is not 1388 a DNS64, the network will keep working only if other means of 1389 learning the NAT64 prefix are available. 1391 As described in Section 4.8, for broadband networks, the CEs 1392 supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or 1393 alternative means for configuring a shorter prefix. The CE SHOULD 1394 internally reserve one /64 for the stateless NAT46 translation. The 1395 operator must ensure that the customers get allocated prefixes 1396 shorter than /64 in order to support this optimization. One way or 1397 the other, this is not impacting the performance of the operator 1398 network. 1400 Operators may follow Section 7 of [RFC6877] (Deployment 1401 Considerations), for suggestions in order to take advantage of 1402 traffic engineering requirements. 1404 In the case of cellular networks, the considerations regarding DNSSEC 1405 may appear as out-of-scope, because UEs Operating Systems, commonly 1406 don't support DNSSEC. However, applications running on them may do, 1407 or it may be an Operating System "built-in" support in the future. 1408 Moreover, if those devices offer tethering, other client devices 1409 behind the UE, may be doing the validation, hence the relevance of a 1410 proper DNSSEC support by the operator network. 1412 Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and 1413 "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" 1414 ([RFC7050]), allow a progressive IPv6 deployment, with a single APN 1415 supporting all types of PDP context (IPv4, IPv6, IPv4v6). This 1416 approach allows the network to automatically serve every possible 1417 combinations of UEs. 1419 If the operator chooses to provide validation for the DNS64 prefix 1420 discovery, it must follow the advice from Section 3.1. of [RFC7050] 1421 (Validation of Discovered Pref64::/n). 1423 One last consideration, is that many networks may have a mix of 1424 different complex scenarios at the same time, for example, customers 1425 requiring 464XLAT, others not requiring it, customers requiring 1426 DNS64, others not, etc. In general, the different issues and the 1427 approaches described in this document can be implemented at the same 1428 time for different customers or parts of the network. That mix of 1429 approaches don't present any problem or incompatibility, as they work 1430 well together, being just a matter of appropriate and differentiated 1431 provisioning. In fact, the NAT64/464XLAT approach facilitates an 1432 operator offering both cellular and broadband services, to have a 1433 single IPv4aaS for both networks while differentiating the deployment 1434 key decisions to optimize each case. It even makes possible using 1435 hybrid CEs that have a main broadband access link and a backup via 1436 the cellular network. 1438 In an ideal world we could safely use DNS64, if the approach proposed 1439 in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, avoiding the 1440 cases where DNSSEC may be broken. However, this will not solve the 1441 issues related to DNS Privacy and Split DNS. 1443 The only 100% safe solution, which also resolves all the issues, will 1444 be, in addition to having a CLAT function, not using a DNS64 but 1445 instead making sure that the hosts have a built-in address synthesis 1446 feature. Operators could manage to provide CEs with the CLAT 1447 function, however the built-in address synthesis feature is out of 1448 their control. If the synthesis is provided either by the Operating 1449 System (via its DNS resolver API) or by the application (via its own 1450 DNS resolver), in such way that the prefix used for the NAT64 1451 function is reachable for the host, the problem goes away. 1453 Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9, 1454 provides a very relevant optimization, avoiding double-translations. 1456 Applications that require incoming connections, typically already 1457 provide means for that. However, PCP and EAM, as indicated in 1458 Section 4.10, are valid alternatives, even for creating explicit 1459 mappings for customers that require them. 1461 6. Deployment of 464XLAT/NAT64 in Enterprise Networks 1463 The recommendations of this document can be used as well in 1464 enterprise networks, campus and other similar scenarios (including 1465 managed end-user networks). 1467 This include scenarios where the NAT64 function (and DNS64 function, 1468 if available) are under the control of that network (or can be 1469 configured manually according to that network specific requirements), 1470 and for whatever reasons, there is a need to provide "IPv6-only 1471 access" to any part of that network or it is IPv6-only connected to 1472 third party-networks. 1474 An example of that is the IETF meetings network itself, where both 1475 NAT64 and DNS64 functions are provided, presenting in this case the 1476 same issues as per Section 3.1.1. If there is a CLAT function in the 1477 IETF network, then there is no need to use DNS64 and it falls under 1478 the considerations of Section 3.1.3. Both scenarios have been tested 1479 and verified already in the IETF network itself. 1481 Next figures are only meant to represent a few of the possible 1482 scenarios, not pretending to be the only feasible ones. 1484 Figure 14 provides an example of an IPv6-only enterprise network 1485 connected with dual-stack to Internet and using local NAT64 and DNS64 1486 functions. 1488 +----------------------------------+ 1489 | Enterprise Network | 1490 | +----------+ +----------+ | +----------+ 1491 | | IPv6 | | NAT64 | | | IPv4 | 1492 | | only +--------+ + | +-------+ + | 1493 | | LANs | | DNS64 | | | IPv6 | 1494 | +----------+ +----------+ | +----------+ 1495 +----------------------------------+ 1497 Figure 14: IPv6-only enterprise with NAT64 and DNS64 1499 Figure 15 provides an example of a dual-stack (DS) enterprise network 1500 connected with dual-stack (DS) to Internet and using a CLAT function, 1501 without a DNS64 function. 1503 +----------------------------------+ 1504 | Enterprise Network | 1505 | +----------+ +----------+ | +----------+ 1506 | | IPv6 | | | | | IPv4 | 1507 | | + +--------+ NAT64 | +-------+ + | 1508 | | CLAT | | | | | IPv6 | 1509 | +----------+ +----------+ | +----------+ 1510 +----------------------------------+ 1512 Figure 15: DS enterprise with CLAT, DS Internet, without DNS64 1514 Finally, Figure 16 provides an example of an IPv6-only provider with 1515 a NAT64 function, and a dual-stack (DS) enterprise network by means 1516 of their own CLAT function, without a DNS64 function. 1518 +----------------------------------+ 1519 | Enterprise Network | 1520 | +----------+ +----------+ | +----------+ 1521 | | IPv6 | | | | IPv6 | | 1522 | | + +--------+ CLAT | +--------+ NAT64 | 1523 | | IPv4 | | | | only | | 1524 | +----------+ +----------+ | +----------+ 1525 +----------------------------------+ 1527 Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64 1529 7. Security Considerations 1531 This document does not have new specific security considerations 1532 beyond those already reported by each of the documents cited. For 1533 example, DNS64 ([RFC6147]) already describes the DNSSEC issues. 1535 Note that, as already described in Section 4.4, there may be 1536 undesirable interactions, specially if using VPNs or DNS privacy, 1537 which may impact in the correct performance of DNS64/NAT64. 1539 It should be remarked that the use of a DNS64 function has equivalent 1540 privacy considerations as in the case of a regular DNS, either 1541 located in the service provider or an external one. 1543 8. IANA Considerations 1545 This document does not have any new specific IANA considerations. 1547 Note: This section is assuming that https://www.rfc- 1548 editor.org/errata/eid5152 is resolved, otherwise, this section may 1549 include the required text to resolve the issue. 1551 Alternatively, this could be fixed also by 1552 [I-D.cheshire-sudn-ipv4only-dot-arpa]. 1554 9. Acknowledgements 1556 The author would like to acknowledge the inputs of Gabor Lencse, 1557 Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed 1558 Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson and Eric 1559 Vyncke. 1561 Conversations with Marcelo Bagnulo, one of the co-authors of NAT64 1562 and DNS64, as well as several emails in mailing lists from Mark 1563 Andrews, have been very useful for this work. 1565 Christian Huitema inspired working in this document by suggesting 1566 that DNS64 should never be used, during a discussion regarding the 1567 deployment of CLAT in the IETF network. 1569 10. ANNEX A: Example of Broadband Deployment with 464XLAT 1571 This section summarizes how an operator may deploy an IPv6-only 1572 network for residential/SOHO customers, supporting IPv6 inbound 1573 connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT. 1575 Note that an equivalent setup could also be provided for enterprise 1576 customers. In case they need to support IPv4 inbound connections, 1577 several mechanisms, depending on specific customer needs, allow that, 1578 for instance [RFC7757]. 1580 Conceptually, most part of the operator network could be IPv6-only 1581 (represented in the next pictures as "IPv6-only flow"), or even if 1582 this part of the network is actually dual-stack, only IPv6-access is 1583 available for some customers (i.e. residential customers). This part 1584 of the network connects the IPv6-only subscribers (by means of 1585 IPv6-only access links), to the IPv6 upstream providers, as well as 1586 to the IPv4-Internet by means of the NAT64 (PLAT in the 464XLAT 1587 terminology). 1589 The traffic flow from and back to the CE to services available in the 1590 IPv6 Internet (or even dual-stack remote services, when IPv6 is being 1591 used), is purely native IPv6 traffic, so there are no special 1592 considerations about it. 1594 Looking at the picture from the DNS perspective, there are remote 1595 networks with are IPv4-only, and typically will have only IPv4 DNS 1596 (DNS/IPv4), or at least will be seen as that from the CE perspective. 1597 At the operator side, the DNS, as seen from the CE, is only IPv6 1598 (DNS/IPv6) and has also a DNS64 function. 1600 In the customer LANs side, there is actually one network, which of 1601 course could be split in different segments. The most common setup 1602 will be those segments being dual-stack, using global IPv6 addresses 1603 and [RFC1918] for IPv4, as usual in any regular residential/SOHO IPv4 1604 network. In the figure, it is represented as tree segments, just to 1605 show that the three possible setups are valid (IPv6-only, IPv4-only 1606 and dual-stack). 1608 .-----. +-------+ .-----. .-----. 1609 / IPv6- \ | | / \ / \ 1610 ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ 1611 \ LANs / | SOHO +--( only )--( NAT64 )--( only ) 1612 `-----' | | \ flow / `-----' \ flow / 1613 .-----. | IPv6 | \ / \ / 1614 / IPv4- \ | CE | `--+--' `--+--' 1615 ( only )--+ with | | | 1616 \ LANs / | CLAT | +---+----+ +---+----+ 1617 `-----' | | |DNS/IPv6| |DNS/IPv4| 1618 .-----. +---+---+ | with | +--------+ 1619 / Dual- \ | | DNS64 | 1620 ( Stack )------| +--------+ 1621 \ LANs / 1622 `-----' 1624 Figure 17: CE setup with built-in CLAT with DNS64 1626 In addition to the regular CE setup, which will be typically access- 1627 technology dependent, the steps for the CLAT function configuration 1628 can be summarized as: 1630 1. Discovery of the PLAT (NAT64) prefix: It may be done using 1631 [RFC7050], or in those networks where PCP is supported, by means 1632 of [RFC7225], or other alternatives that may be available in the 1633 future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or 1634 DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]). 1636 2. If the CLAT function allows stateless NAT46 translation, a /64 1637 from the pool typically provided to the CE by means of DHCPv6-PD 1638 [RFC8415], need to be set aside for that translation. Otherwise, 1639 the CLAT is forced to perform an intermediate stateful NAT44 1640 before the a stateless NAT46, as described in Section 4.8. 1642 A more detailed configuration approach is described in [RFC8585]. 1644 The operator network needs to ensure that the correct responses are 1645 provided for the discovery of the PLAT prefix. It is highly 1646 recommended to follow [RIPE-690], in order to ensure that multiple 1647 /64s are available, including the one needed for the NAT46 stateless 1648 translation. 1650 The operator needs to understand other issues, described across this 1651 document, in order to take the relevant decisions. For example, if 1652 several NAT64 functions are needed in the context of scalability/ 1653 high-availability, an NSP should be considered (Section 4.5). 1655 More complex scenarios are possible, for example, if a network offers 1656 multiple NAT64 prefixes, destination-based NAT64 prefixes, etc. 1658 If the operator decides not to provide a DNS64 function, then this 1659 setup turns into the one in the following Figure. This will be also 1660 the setup that "will be seen" from the perspective of the CE, if a 1661 foreign DNS is used and consequently is not the operator-provided 1662 DNS64 function. 1664 .-----. +-------+ .-----. .-----. 1665 / IPv6- \ | | / \ / \ 1666 ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ 1667 \ LANs / | SOHO +--( only )--( NAT64 )--( only ) 1668 `-----' | | \ flow / `-----' \ flow / 1669 .-----. | IPv6 | \ / \ / 1670 / IPv4- \ | CE | `--+--' `--+--' 1671 ( only )--+ with | | | 1672 \ LANs / | CLAT | +---+----+ +---+----+ 1673 `-----' | | |DNS/IPv6| |DNS/IPv4| 1674 .-----. +---+---+ +--------+ +--------+ 1675 / Dual- \ | 1676 ( Stack )------| 1677 \ LANs / 1678 `-----' 1680 Figure 18: CE setup with built-in CLAT without DNS64 1682 In this case, the discovery of the PLAT prefix needs to be arranged 1683 as indicated in Section 4.1.1. 1685 In this case, the CE doesn't have a built-in CLAT function, or the 1686 customer can choose to setup the IPv6 operator-managed CE in bridge 1687 mode (and optionally use an external router), or for example, there 1688 is an access technology that requires some kind of media converter 1689 (ONT for FTTH, Cable-Modem for DOCSIS, etc.), the complete setup will 1690 look as in Figure 19. Obviously, there will be some intermediate 1691 configuration steps for the bridge, depending on the specific access 1692 technology/protocols, which should not modify the steps already 1693 described in the previous cases for the CLAT function configuration. 1695 +-------+ .-----. .-----. 1696 | | / \ / \ 1697 | Res./ | / IPv6- \ .-----. / IPv4- \ 1698 | SOHO +--( only )--( NAT64 )--( only ) 1699 | | \ flow / `-----' \ flow / 1700 | IPv6 | \ / \ / 1701 | CE | `--+--' `--+--' 1702 | Bridge| | | 1703 | | +---+----+ +---+----+ 1704 | | |DNS/IPv6| |DNS/IPv4| 1705 +---+---+ +--------+ +--------+ 1706 | 1707 .-----. +---+---+ 1708 / IPv6- \ | | 1709 ( only )--+ IPv6 | 1710 \ LANs / | Router| 1711 `-----' | | 1712 .-----. | with | 1713 / IPv4- \ | CLAT | 1714 ( only )--+ | 1715 \ LANs / | | 1716 `-----' | | 1717 .-----. +---+---+ 1718 / Dual- \ | 1719 ( Stack )------| 1720 \ LANs / 1721 `-----' 1723 Figure 19: CE setup with bridged CLAT without DNS64 1725 It should be avoided that several routers (i.e., the operator 1726 provided CE and a downstream user provided router) enable 1727 simultaneously routing and/or CLAT, in order to avoid multiple NAT44 1728 and NAT46 levels, as well as ensuring the correct operation of 1729 multiple IPv6 subnets. In those cases, it is suggested the use of 1730 HNCP ([RFC8375]). 1732 Note that the procedure described here for the CE setup, can be 1733 simplified if the CE follows [RFC8585]. 1735 11. ANNEX B: CLAT Implementation 1737 In addition to the regular set of features for a CE, a CLAT CE 1738 implementation requires support of: 1740 o [RFC7915] for the NAT46 function. 1742 o [RFC7050] for the PLAT prefix discovery. 1744 o [RFC7225] for the PLAT prefix discovery if PCP is supported. 1746 o [I-D.ietf-6man-ra-pref64] for the PLAT prefix discovery by means 1747 of Router Advertising. 1749 o [I-D.li-intarea-nat64-prefix-dhcp-option] for the PLAT prefix 1750 discovery by means of DHCP. 1752 o If stateless NAT46 is supported, a mechanism to ensure that 1753 multiple /64 are available, such as DHCPv6-PD [RFC8415]. 1755 There are several OpenSource implementations of CLAT, such as: 1757 o Android: https://github.com/ddrown/android_external_android-clat. 1759 o Jool: https://www.jool.mx. 1761 o Linux: https://github.com/toreanderson/clatd. 1763 o OpenWRT: https://github.com/openwrt- 1764 routing/packages/blob/master/nat46/files/464xlat.sh. 1766 o VPP: https://git.fd.io/vpp/tree/src/plugins/nat. 1768 12. ANNEX C: Benchmarking 1770 [RFC8219] has defined a benchmarking methodology for IPv6 transition 1771 technologies. NAT64 and 464XLAT are addressed among the single and 1772 double translation technologies, respectively. DNS64 is addressed in 1773 Section 9, and the methodology is more elaborated in [DNS64-BM-Meth]. 1775 Several documents provide references to benchmarking results, for 1776 example in the case of DNS64, [DNS64-Benchm]. 1778 13. ANNEX D: Changes from -00 to -01/-02 1780 Section to be removed after WGLC. Significant updates are: 1782 1. Text changes across all the document. 1784 14. ANNEX E: Changes from -02 to -03 1786 Section to be removed after WGLC. Significant updates are: 1788 1. Added references to new cited documents. 1790 2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only 1791 LANs w/o DNS64. 1793 3. Overall review and editorial changes. 1795 15. ANNEX F: Changes from -03 to -04 1797 Section to be removed after WGLC. Significant updates are: 1799 1. Added text related to EAM considerations. 1801 16. ANNEX G: Changes from -04 to -05 1803 Section to be removed after WGLC. Significant updates are: 1805 1. Added cross references to EAM section. 1807 2. Reworded "foreing DNS section". 1809 3. Overall editorial review of text, pictures and nits correction. 1811 17. ANNEX H: Changes from -05 to -06 1813 Section to be removed after WGLC. Significant updates are: 1815 1. Corrected EAMT to EAM. 1817 2. Typos and nits. 1819 3. New considerations regarding incoming connections. 1821 18. ANNEX H: Changes from -06 to -07 1823 Section to be removed after WGLC. Significant updates are: 1825 1. Inputs/clarifications from IESG review. 1827 19. References 1829 19.1. Normative References 1831 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1832 and E. Lear, "Address Allocation for Private Internets", 1833 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1834 . 1836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1837 Requirement Levels", BCP 14, RFC 2119, 1838 DOI 10.17487/RFC2119, March 1997, 1839 . 1841 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1842 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1843 DOI 10.17487/RFC5389, October 2008, 1844 . 1846 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 1847 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 1848 . 1850 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1851 Relays around NAT (TURN): Relay Extensions to Session 1852 Traversal Utilities for NAT (STUN)", RFC 5766, 1853 DOI 10.17487/RFC5766, April 2010, 1854 . 1856 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1857 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1858 DOI 10.17487/RFC6052, October 2010, 1859 . 1861 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1862 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1863 April 2011, . 1865 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1866 NAT64: Network Address and Protocol Translation from IPv6 1867 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1868 April 2011, . 1870 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1871 Beijnum, "DNS64: DNS Extensions for Network Address 1872 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1873 DOI 10.17487/RFC6147, April 2011, 1874 . 1876 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 1877 Using "Bump-in-the-Host" (BIH)", RFC 6535, 1878 DOI 10.17487/RFC6535, February 2012, 1879 . 1881 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1882 Combination of Stateful and Stateless Translation", 1883 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1884 . 1886 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1887 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1888 DOI 10.17487/RFC6887, April 2013, 1889 . 1891 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1892 the IPv6 Prefix Used for IPv6 Address Synthesis", 1893 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1894 . 1896 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 1897 Port Control Protocol (PCP)", RFC 7225, 1898 DOI 10.17487/RFC7225, May 2014, 1899 . 1901 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 1902 Mappings for Stateless IP/ICMP Translation", RFC 7757, 1903 DOI 10.17487/RFC7757, February 2016, 1904 . 1906 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1907 "IP/ICMP Translation Algorithm", RFC 7915, 1908 DOI 10.17487/RFC7915, June 2016, 1909 . 1911 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1912 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1913 May 2017, . 1915 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1916 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1917 . 1919 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1920 Better Connectivity Using Concurrency", RFC 8305, 1921 DOI 10.17487/RFC8305, December 2017, 1922 . 1924 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1925 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1926 . 1928 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1929 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1930 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1931 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1932 . 1934 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1935 Connectivity Establishment (ICE): A Protocol for Network 1936 Address Translator (NAT) Traversal", RFC 8445, 1937 DOI 10.17487/RFC8445, July 2018, 1938 . 1940 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1941 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1942 . 1944 19.2. Informative References 1946 [About-DNS64] 1947 Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016, 1948 . 1951 [ARCEP] ARCEP, "Service client des operateurs : les mesures de 1952 qualite de service", 2018, . 1958 [DNS64-Benchm] 1959 Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 1960 Implementations: Theory and Practice", Computer 1961 Communications , vol. 127, no. 1, pp. 61-74, 1962 DOI 10.1016/j.comcom.2018.05.005, September 2018. 1964 [DNS64-BM-Meth] 1965 Lencse, G., Georgescu, M., and Y. Kadobayashi, 1966 "Benchmarking Methodology for DNS64 Servers", Computer 1967 Communications , vol. 109, no. 1, pp. 162-175, 1968 DOI 10.1016/j.comcom.2017.06.004, September 2017. 1970 [FCC] FCC, "Measuring Broadband America Mobile 2013-2018 1971 Coarsened Data", 2018, . 1975 [I-D.bp-v6ops-ipv6-ready-dns-dnssec] 1976 Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC 1977 Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00 1978 (work in progress), October 2018. 1980 [I-D.cheshire-sudn-ipv4only-dot-arpa] 1981 Cheshire, S. and D. Schinazi, "Special Use Domain Name 1982 'ipv4only.arpa'", draft-cheshire-sudn-ipv4only-dot-arpa-14 1983 (work in progress), November 2018. 1985 [I-D.huitema-quic-dnsoquic] 1986 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 1987 Iyengar, "Specification of DNS over Dedicated QUIC 1988 Connections", draft-huitema-quic-dnsoquic-06 (work in 1989 progress), March 2019. 1991 [I-D.ietf-6man-ra-pref64] 1992 Colitti, L. and J. Linkova, "Discovering PREF64 in Router 1993 Advertisements", draft-ietf-6man-ra-pref64-01 (work in 1994 progress), June 2019. 1996 [I-D.ietf-tram-stunbis] 1997 Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 1998 D., Mahy, R., and P. Matthews, "Session Traversal 1999 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-21 2000 (work in progress), March 2019. 2002 [I-D.ietf-tram-turnbis] 2003 K, R., Johnston, A., Matthews, P., and J. Rosenberg, 2004 "Traversal Using Relays around NAT (TURN): Relay 2005 Extensions to Session Traversal Utilities for NAT (STUN)", 2006 draft-ietf-tram-turnbis-27 (work in progress), June 2019. 2008 [I-D.li-intarea-nat64-prefix-dhcp-option] 2009 Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet, 2010 "DHCPv6 Options for Discovery NAT64 Prefixes", draft-li- 2011 intarea-nat64-prefix-dhcp-option-02 (work in progress), 2012 April 2019. 2014 [I-D.lmhp-v6ops-transition-comparison] 2015 Lencse, G., Palet, J., Howard, L., Patterson, R., and I. 2016 Farrer, "Pros and Cons of IPv6 Transition Technologies for 2017 IPv4aaS", draft-lmhp-v6ops-transition-comparison-03 (work 2018 in progress), July 2019. 2020 [I-D.palet-v6ops-464xlat-opt-cdn-caches] 2021 Palet, J. and A. D'Egidio, "464XLAT Optimization", draft- 2022 palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress), 2023 June 2019. 2025 [I-D.vixie-dns-rpz] 2026 Vixie, P. and V. Schryver, "DNS Response Policy Zones 2027 (RPZ)", draft-vixie-dns-rpz-04 (work in progress), 2028 December 2016. 2030 [ISOC] ISOC, "State of IPv6 Deployment 2018", 2018, 2031 . 2034 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 2035 "Analysis of Stateful 64 Translation", RFC 6889, 2036 DOI 10.17487/RFC6889, April 2013, 2037 . 2039 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 2040 "Architectural Considerations on Application Features in 2041 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 2042 . 2044 [RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of 2045 Solution Proposals for Hosts to Learn NAT64 Prefix", 2046 RFC 7051, DOI 10.17487/RFC7051, November 2013, 2047 . 2049 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 2050 Deployment Options and Experience", RFC 7269, 2051 DOI 10.17487/RFC7269, June 2014, 2052 . 2054 [RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for 2055 IPv6 Data Center Environments", RFC 7755, 2056 DOI 10.17487/RFC7755, February 2016, 2057 . 2059 [RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP 2060 Translation for IPv6 Internet Data Center Environments 2061 (SIIT-DC): Dual Translation Mode", RFC 7756, 2062 DOI 10.17487/RFC7756, February 2016, 2063 . 2065 [RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, 2066 N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, 2067 "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, 2068 DOI 10.17487/RFC7849, May 2016, 2069 . 2071 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2072 and P. Hoffman, "Specification for DNS over Transport 2073 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2074 2016, . 2076 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 2077 Transport Layer Security (DTLS)", RFC 8094, 2078 DOI 10.17487/RFC8094, February 2017, 2079 . 2081 [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking 2082 Methodology for IPv6 Transition Technologies", RFC 8219, 2083 DOI 10.17487/RFC8219, August 2017, 2084 . 2086 [RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima, 2087 "Requirements for IPv6 Customer Edge Routers to Support 2088 IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 2089 2019, . 2091 [RIPE-690] 2092 RIPE, "Best Current Operational Practice for Operators: 2093 IPv6 prefix assignment for end-users - persistent vs non- 2094 persistent, and what size to choose", October 2017, 2095 . 2097 [Threat-DNS64] 2098 Lencse, G. and Y. Kadobayashi, "Methodology for the 2099 identification of potential security issues of different 2100 IPv6 transition technologies: Threat analysis of DNS64 and 2101 stateful NAT64", Computers & Security , vol. 77, no. 1, 2102 pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018. 2104 Author's Address 2106 Jordi Palet Martinez 2107 The IPv6 Company 2108 Molino de la Navata, 75 2109 La Navata - Galapagar, Madrid 28420 2110 Spain 2112 Email: jordi.palet@theipv6company.com 2113 URI: http://www.theipv6company.com/