idnits 2.17.1 draft-ietf-v6ops-nat64-deployment-06.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 (May 4, 2019) is 1819 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 (-07) exists of draft-huitema-quic-dnsoquic-06 == Outdated reference: A later version (-09) exists of draft-ietf-6man-ra-pref64-00 == Outdated reference: A later version (-06) exists of draft-lmhp-v6ops-transition-comparison-02 == Outdated reference: A later version (-04) exists of draft-palet-v6ops-464xlat-opt-cdn-caches-01 Summary: 2 errors (**), 0 flaws (~~), 7 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 May 4, 2019 5 Expires: November 5, 2019 7 Additional NAT64/464XLAT Deployment Guidelines in Operator and 8 Enterprise Networks 9 draft-ietf-v6ops-nat64-deployment-06 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 November 5, 2019. 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 . . 11 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 . . . 15 65 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only 66 remote network . . . . . . . . . . . . . . . . . . . 16 67 3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 16 68 4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 18 69 4.1. DNSSEC Considerations and Possible Approaches . . . . . . 18 70 4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 20 71 4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21 72 4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 21 73 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 21 74 4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22 75 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 22 76 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 22 77 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 22 78 4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 23 79 4.4.1. Manual Configuration of Foreign DNS . . . . . . . . . 24 80 4.4.2. DNS Privacy . . . . . . . . . . . . . . . . . . . . . 24 81 4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 25 82 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 25 83 4.6. IPv4 literals and old APIs . . . . . . . . . . . . . . . 25 84 4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 26 85 4.8. CLAT Translation Considerations . . . . . . . . . . . . . 26 86 4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 27 87 4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 27 88 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 27 89 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 30 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 93 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 32 94 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 36 95 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 37 96 13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 37 97 14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 37 98 15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 38 99 16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 38 100 17. ANNEX H: Changes from -05 to -06 . . . . . . . . . . . . . . 38 101 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 102 18.1. Normative References . . . . . . . . . . . . . . . . . . 38 103 18.2. Informative References . . . . . . . . . . . . . . . . . 41 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 106 1. Introduction 108 Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 109 translation mechanism, which allows IPv6-only hosts to communicate 110 with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of 111 IPv4 public addresses sharing, among multiple IPv6-only hosts. 112 Unless otherwise stated, references in the rest of this document to 113 NAT64 (function) should be interpreted as to Stateful NAT64. 115 The translation of the packet headers is done using the IP/ICMP 116 translation algorithm defined in [RFC7915] and algorithmically 117 translating the IPv4 addresses to IPv6 addresses and vice versa, 118 following [RFC6052]. 120 DNS64 ([RFC6147]) is in charge of the synthesis of AAAA records from 121 the A records, so only works for applications making use of DNS. It 122 was designed to avoid changes in both, the IPv6-only hosts and the 123 IPv4-only server, so they can use a NAT64 function. As discussed in 124 Section 5.5 of [RFC6147], a security-aware and validating host has to 125 perform the DNS64 function locally. 127 However, the use of NAT64 and/or DNS64 present three drawbacks: 129 a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is 130 designed to detect such modifications, DNS64 ([RFC6147]) may 131 potentially break DNSSEC, depending on a number of factors, such 132 as the location of the DNS64 function (at a DNS server or 133 validator, at the end host, ...), how it has been configured, if 134 the end-hosts is validating, etc. 136 b. Because the need of using DNS64 ([RFC6147]) or an alternative 137 "host/application built-in" mechanism for address synthesis, 138 there may be an issue for NAT64 ([RFC6146]), as it doesn't work 139 when IPv4 literal addresses or non-IPv6 compliant APIs are being 140 used. 142 c. NAT64 alone, was not designed to provide a solution for IPv4-only 143 hosts or applications located within a network which are 144 connected to a service provider IPv6-only access, as it was 145 designed for a very specific scenario ([RFC6144], Section 2.1). 147 Above drawbacks may be true if part of, an enterprise network, is 148 connected to other parts of the same network or third-party networks 149 by means of IPv6-only connectivity. This is just an example which 150 may apply to many other similar cases. All them are deployment 151 specific. 153 According to that, across this document, the use of "operator", 154 "operator network", "service provider", and similar ones, are 155 interchangeable with equivalent cases of enterprise networks (and 156 similar ones). This may be also the case for "managed end-user 157 networks". 159 An analysis of stateful IPv4/IPv6 mechanisms is provided in 160 [RFC6889]. 162 This document looks into different possible NAT64 ([RFC6146]) 163 deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and 164 similar ones, which were not documented in [RFC6144], such as 464XLAT 165 ([RFC6877]), in operator (broadband and cellular) and enterprise 166 networks, and provides guidelines to avoid operational issues. 168 Towards that, this document first looks into the possible NAT64 169 deployment scenarios (split in "known to work" and "known to work 170 under special conditions"), providing a quick and generic comparison 171 table among them. Then the document describes the issues that an 172 operator need to understand on different matters that will allow to 173 define what is the best approach/scenario for each specific network 174 case. A summary provides some recommendations and decision points. 175 A section with clarifications on the usage of this document for 176 enterprise networks, is also provided. Finally, an annex provides an 177 example of a broadband deployment using 464XLAT and another annex 178 provides hints for a CLAT implementation. 180 [RFC7269] already provides information about NAT64 deployment options 181 and experiences. Both, this document and [RFC7269] are 182 complementary, as they are looking into different deployment 183 considerations and furthermore, this document is considering the 184 updated deployment experience and newer standards. 186 The target deployment scenarios in this document may be covered as 187 well by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. 188 Note that this is true only for the case of broadband networks, as in 189 the case of cellular networks the only supported solution is the use 190 of NAT64/464XLAT. So, it is out of scope of this document to provide 191 a comparison among the different IPv4aaS transition mechanisms, which 192 is being analyzed already in [I-D.lmhp-v6ops-transition-comparison]. 194 Consequently, this document should not be understood as a guide for 195 an operator or enterprise to decide which IPv4aaS is the best one for 196 its own network. Instead it should be used as a tool for 197 understanding all the implications, including relevant documents (or 198 even specific parts of them), for the deployment of NAT64/464XLAT and 199 facilitate the decision process regarding specific deployment 200 details. 202 2. Requirements Language 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 206 "OPTIONAL" in this document are to be interpreted as described in BCP 207 14 [RFC2119] [RFC8174] when, and only when, they appear in all 208 capitals, as shown here. 210 3. NAT64 Deployment Scenarios 212 Section 7 of DNS64 ([RFC6147]), provides three scenarios, depending 213 on the location of the DNS64 function. However, since the 214 publication of that document, other deployment scenarios and NAT64 215 use cases need to be considered in actual networks, despite some of 216 them were specifically ruled out by the original NAT64/DNS64 work. 218 Consequently, the perspective in this document is to broaden those 219 scenarios, including a few new ones. However, in order to be able to 220 reduce the number of possible cases, we work under the assumption 221 that typically, the service provider wants to make sure that all the 222 customers have a service without failures. This means considering 223 the following assumptions for the worst possible case: 225 a. There are hosts that will be validating DNSSEC. 227 b. IPv4 literal addresses and non-IPv6 compliant APIs are being 228 used. 230 c. There are IPv4-only hosts or applications beyond the IPv6-only 231 link (e.g., tethering in cellular networks). 233 The document uses a common set of possible "participant entities": 235 1. An IPv6-only access network (IPv6). 237 2. An IPv4-only remote network/server/service (IPv4). 239 3. A NAT64 function (NAT64) in the service provider. 241 4. A DNS64 function (DNS64) in the service provider. 243 5. An external service provider offering the NAT64 function and/or 244 the DNS64 function (extNAT64/extDNS64). 246 6. 464XLAT customer side translator (CLAT). 248 Note that the nomenclature used in parenthesis is the one that, for 249 short, will be used in the figures. 251 The possible scenarios are split in two general categories: 253 1. Known to work. 255 2. Known to work under special conditions. 257 3.1. Known to Work 259 The scenarios in this category are known to work. Each one may have 260 different pros and cons, and in some cases the trade-offs, maybe 261 acceptable for some operators. 263 3.1.1. Service Provider NAT64 with DNS64 265 In this scenario, the service provider offers both, the NAT64 and the 266 DNS64 functions. 268 This is the most common scenario as originally considered by the 269 designers of NAT64 ([RFC6146]) and DNS64 ([RFC6147]), however also 270 may have the implications related the DNSSEC. 272 This scenario also may fail to solve the issue of IPv4 literal 273 addresses or non-IPv6 compliant APIs, as well as the issue of 274 IPv4-only hosts or applications behind the IPv6-only access network. 276 +----------+ +----------+ +----------+ 277 | | | NAT64 | | | 278 | IPv6 +--------+ + +--------+ IPv4 | 279 | | | DNS64 | | | 280 +----------+ +----------+ +----------+ 282 Figure 1: NAT64 with DNS64 284 A similar scenario will be if the service provider offers only the 285 DNS64 function, and the NAT64 function is provided by an outsourcing 286 agreement with an external provider. All the considerations in the 287 previous paragraphs of this section are the same for this sub-case. 289 +----------+ +----------+ 290 | | | | 291 | extNAT64 +--------+ IPv4 | 292 | | | | 293 +----+-----+ +----------+ 294 | 295 | 296 +----------+ +----+-----+ 297 | | | | 298 | IPv6 +--------+ DNS64 + 299 | | | | 300 +----------+ +----------+ 302 Figure 2: NAT64 in external service provider 304 This is equivalent to the scenario where the outsourcing agreement 305 with the external provider is to provide both the NAT64 and DNS64 306 functions. Once more, all the considerations in the previous 307 paragraphs of this section are the same for this sub-case. 309 +----------+ +----------+ 310 | extNAT64 | | | 311 | + +-------+ IPv4 | 312 | extDNS64 | | | 313 +----+-----+ +----------+ 314 | 315 +----------+ | 316 | | | 317 | IPv6 +-------------+ 318 | | 319 +----------+ 321 Figure 3: NAT64 and DNS64 in external provider 323 One more equivalent scenario will be if the service provider offers 324 the NAT64 function only, and the DNS64 function is from an external 325 provider with or without a specific agreement among them. This is a 326 scenario already common today, as several "global" service providers 327 provide free DNS/DNS64 services and users often configure manually 328 their DNS. This will only work if both the NAT64 and the DNS64 329 functions are using the WKP (Well-Known Prefix) or the same NSP 330 (Network-Specific Prefix). All the considerations in the previous 331 paragraphs of this section are the same for this sub-case. 333 Of course, if the external DNS64 function is agreed with the service 334 provider, then we are in the same case as in the previous ones 335 already depicted in this scenario. 337 +----------+ 338 | | 339 | extDNS64 | 340 | | 341 +----+-----+ 342 | 343 | 344 +----------+ +----+-----+ +----------+ 345 | | | | | | 346 | IPv6 +--------+ NAT64 +--------+ IPv4 | 347 | | | | | | 348 +----------+ +----------+ +----------+ 350 Figure 4: NAT64; DNS64 by external provider 352 3.1.2. Service Provider Offering 464XLAT, with DNS64 354 464XLAT ([RFC6877]) describes an architecture that provides IPv4 355 connectivity across a network, or part of it, when it is only 356 natively transporting IPv6. [RFC7849] already suggest the need to 357 support the CLAT function in order to ensure the IPv4 service 358 continuity in IPv6-only cellular deployments. 360 In order to do that, 464XLAT ([RFC6877]) relies on the combination of 361 existing protocols: 363 1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6 364 translator (NAT46) ([RFC7915]) implemented in the end-user device 365 or CE (Customer Edge Router), located at the "customer edge" of 366 the network. 368 2. The provider-side translator (PLAT) is a stateful NAT64 369 ([RFC6146]), implemented typically at in the operator network. 371 3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a 372 single translation at the NAT64, instead of two translations 373 (NAT46+NAT64), when the application at the end-user device 374 supports IPv6 DNS (uses AAAA Resource Records). 376 Note that even if in the 464XLAT ([RFC6877]) terminology, the 377 provider-side translator is referred as PLAT, for simplicity and 378 uniformity, across this document is always referred as NAT64 379 (function). 381 In this scenario the service provider deploys 464XLAT with a DNS64 382 function. 384 As a consequence, the DNSSEC issues remain, unless the host is doing 385 the address synthesis. 387 464XLAT ([RFC6877]) is a very simple approach to cope with the major 388 NAT64+DNS64 drawback: Not working with applications or devices that 389 use literal IPv4 addresses or non-IPv6 compliant APIs. 391 464XLAT ([RFC6877]) has been used initially mainly in IPv6-only 392 cellular networks. By supporting a CLAT function, the end-user 393 device applications can access IPv4-only end-networks/applications, 394 despite those applications or devices use literal IPv4 addresses or 395 non-IPv6 compliant APIs. 397 In addition to that, in the same example of the cellular network 398 above, if the User Equipment (UE) provides tethering, other devices 399 behind it will be presented with a traditional NAT44, in addition to 400 the native IPv6 support, so clearly it allows IPv4-only hosts behind 401 the IPv6-only access network. 403 Furthermore, as discussed in [RFC6877], 464XLAT can be used in 404 broadband IPv6 network architectures, by implementing the CLAT 405 function at the CE. 407 The support of this scenario offers two additional advantages: 409 o DNS load optimization: A CLAT should implement a DNS proxy (as per 410 [RFC5625]), so that only IPv6 native queries and only for AAAA 411 records are sent to the DNS64 server. Otherwise doubling the 412 number of queries may impact the DNS infrastructure. 414 o Connection establishment delay optimization: If the UE/CE 415 implementation is detecting the presence of a DNS64 function, it 416 may issue only the AAAA query, instead of both the AAAA and A 417 queries. 419 In order to understand all the communication possibilities, let's 420 assume the following representation of two dual-stack peers: 422 +-------+ .-----. .-----. 423 | | / \ / \ 424 .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ 425 / Local \ | SOHO +--( only )---( NAT64 )---( only ) 426 / \ | | \ flow /\ `-----' \ flow / 427 ( Dual- )--+ IPv6 | \ / \ / \ / 428 \ Stack / | CE | `--+--' \ .-----. / `--+--' 429 \ Peer / | with | | \ / Remote\/ | 430 `-----' | CLAT | +---+----+ / \ +---+----+ 431 | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| 432 +-------+ | with | \ Stack / +--------+ 433 | DNS64 | \ Peer / 434 +--------+ `-----' 436 Figure A: Representation of 464XLAT among two peers with DNS64 438 The possible communication paths, among the IPv4/IPv6 stacks of both 439 peers, in this case, are: 441 a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among 442 peers. 444 b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. 446 c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT 447 implements EAM (Explicit Address Mappings) as indicated by 448 Section 4.9. In principle, it is not expected that services are 449 deployed in Internet using IPv6-only, unless there is certainty 450 that peers will also be IPv6-capable. 452 d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations. 454 e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the 455 CLAT implements EAM as indicated by Section 4.9, instead of using 456 the path d. above, NAT64 translation is avoided and the flow will 457 use IPv6 from the CLAT to the destination. 459 The rest of the figures in this section show different choices for 460 placing the different elements. 462 +----------+ +----------+ +----------+ 463 | IPv6 | | NAT64 | | | 464 | + +--------+ + +--------+ IPv4 | 465 | CLAT | | DNS64 | | | 466 +----------+ +----------+ +----------+ 468 Figure 5: 464XLAT with DNS64 470 A similar scenario will be if the service provider offers only the 471 DNS64 function, and the NAT64 function is provided by an outsourcing 472 agreement with an external provider. All the considerations in the 473 previous paragraphs of this section are the same for this sub-case. 475 +----------+ +----------+ 476 | | | | 477 | extNAT64 +--------+ IPv4 | 478 | | | | 479 +----+-----+ +----------+ 480 | 481 | 482 +----------+ +----+-----+ 483 | IPv6 | | | 484 | + +--------+ DNS64 + 485 | CLAT | | | 486 +----------+ +----------+ 488 Figure 6: 464XLAT with DNS64; NAT64 in external provider 490 As well, is equivalent to the scenario where the outsourcing 491 agreement with the external provider is to provide both the NAT64 and 492 DNS64 functions. Once more, all the considerations in the previous 493 paragraphs of this section are the same for this sub-case. 495 +----------+ +----------+ 496 | extNAT64 | | | 497 | + +--------+ IPv4 | 498 | extDNS64 | | | 499 +----+-----+ +----------+ 500 | 501 +----------+ | 502 | IPv6 | | 503 | + +-------------+ 504 | CLAT | 505 +----------+ 507 Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider 509 3.1.3. Service Provider Offering 464XLAT, without DNS64 511 The major advantage of this scenario, using 464XLAT without DNS64, is 512 that the service provider ensures that DNSSEC is never broken, even 513 in case the user modifies the DNS configuration. Nevertheless, some 514 CLAT implementations or applications may impose an extra delay, which 515 is induced by the dual A/AAAA queries (and wait for both responses), 516 unless Happy Eyeballs v2 (HEv2, [RFC8305]) is also present. 518 A possible variation of this scenario is the case when DNS64 is used 519 only for the discovery of the NAT64 prefix. The rest of the document 520 is not considering it as a different scenario, because once the 521 prefix has been discovered, the DNS64 function is not used, so it 522 behaves as if the DNS64 synthesis function is not present. 524 In this scenario, as in the previous one, there are no issues related 525 to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only 526 access network, neither related to the usage of IPv4 literals or non- 527 IPv6 compliant APIs. 529 The support of this scenario offers one advantage: 531 o DNS load optimization: A CLAT should implement a DNS proxy (as per 532 [RFC5625]), so that only IPv6 native queries are sent to the DNS64 533 server. Otherwise doubling the number of queries may impact the 534 DNS infrastructure. 536 As indicated earlier, the connection establishment delay optimization 537 is achieved only in the case of devices, Operating Systems, or 538 applications that use HEv2 ([RFC8305]), which is very common. 540 Let's assume the representation of two dual-stack peers as in the 541 previous case: 543 +-------+ .-----. .-----. 544 | | / \ / \ 545 .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ 546 / Local \ | SOHO +--( only )---( NAT64 )---( only ) 547 / \ | | \ flow /\ `-----' \ flow / 548 ( Dual- )--+ IPv6 | \ / \ / \ / 549 \ Stack / | CE | `--+--' \ .-----. / `--+--' 550 \ Peer / | with | | \ / Remote\/ | 551 `-----' | CLAT | +---+----+ / \ +---+----+ 552 | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| 553 +-------+ +--------+ \ Stack / +--------+ 554 \ Peer / 555 `-----' 557 Figure B: Representation of 464XLAT among two peers without DNS64 559 The possible communication paths, among the IPv4/IPv6 stacks of both 560 peers, in this case, are: 562 a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among 563 peers. 565 b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64 566 translations. 568 c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT 569 implements EAM as indicated by Section 4.9. In principle, it is 570 not expected that services are deployed in Internet using 571 IPv6-only, unless there is certainty that peers will also be 572 IPv6-capable. 574 d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 575 translations. 577 e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the 578 CLAT implements EAM as indicated by Section 4.9, instead of using 579 the path d. above, NAT64 translation is avoided and the flow will 580 use IPv6 from the CLAT to the destination. 582 It needs to be noticed that this scenario works while the local 583 hosts/applications are dual-stack (which is the current situation), 584 because the connectivity from a local-IPv6 to a remote-IPv4 is not 585 possible without an AAAA synthesis. This aspect is important only 586 when in the LANs behind the CLAT there are IPv6-only hosts and they 587 need to communicate with remote IPv4-only hosts. However, it doesn't 588 look a sensible approach from an Operating System or application 589 vendor perspective, to provide IPv6-only support unless, similarly to 590 case c above, there is certainty of peers supporting IPv6 as well. A 591 solution approach to this is also presented in 592 [I-D.palet-v6ops-464xlat-opt-cdn-caches]. 594 The following figures show different choices for placing the 595 different elements. 597 +----------+ +----------+ +----------+ 598 | IPv6 | | | | | 599 | + +--------+ NAT64 +--------+ IPv4 | 600 | CLAT | | | | | 601 +----------+ +----------+ +----------+ 603 Figure 8: 464XLAT without DNS64 605 This is equivalent to the scenario where there is an outsourcing 606 agreement with an external provider for the NAT64 function. All the 607 considerations in the previous paragraphs of this section are the 608 same for this sub-case. 610 +----------+ +----------+ 611 | | | | 612 | extNAT64 +--------+ IPv4 | 613 | | | | 614 +----+-----+ +----------+ 615 | 616 +----------+ | 617 | IPv6 | | 618 | + +-------------+ 619 | CLAT | 620 +----------+ 622 Figure 9: 464XLAT without DNS64; NAT64 in external provider 624 3.2. Known to Work Under Special Conditions 626 The scenarios in this category are known to not work unless 627 significant effort is devoted to solve the issues, or are intended to 628 solve problems across "closed" networks, instead of as a general 629 Internet access usage. In addition to the different pros, cons and 630 trade-offs, which may be acceptable for some operators, they have 631 implementation difficulties, as they are beyond the original 632 expectations of the NAT64/DNS64 original intent. 634 3.2.1. Service Provider NAT64 without DNS64 636 In this scenario, the service provider offers a NAT64 function, 637 however there is no DNS64 function support at all. 639 As a consequence, an IPv6 host in the IPv6-only access network, will 640 not be able to detect the presence of DNS64 by means of [RFC7050], 641 neither to learn the IPv6 prefix to be used for the NAT64 function. 643 This can be sorted out as indicated in Section 4.1.1. 645 However, despite that, because the lack of the DNS64 function, the 646 IPv6 host will not be able to obtain AAAA synthesized records, so the 647 NAT64 function becomes useless. 649 An exception to this "useless" scenario will be manually configure 650 mappings between the A records of each of the IPv4-only remote hosts 651 and the corresponding AAAA records, with the WKP (Well-Known Prefix) 652 or NSP (Network-Specific Prefix) used by the service provider NAT64 653 function, as if they were synthesized by a DNS64 function. 655 This mapping could be done by several means, typically at the 656 authoritative DNS server, or at the service provider resolvers by 657 means of DNS RPZ (Response Policy Zones, [I-D.vixie-dns-rpz]) or 658 equivalent functionality. DNS RPZ, may have implications in DNSSEC, 659 if the zone is signed. Also, if the service provider is using an 660 NSP, having the mapping at the authoritative server, may create 661 troubles to other parties trying to use different NSP or the WKP, 662 unless multiple DNS "views" (split-DNS) is also being used at the 663 authoritative servers. 665 Generally, the mappings alternative, will only make sense if a few 666 set of IPv4-only remote hosts need to be accessed by a single network 667 (or a small number of them), which support IPv6-only in the access. 668 This will require some kind of mutual agreement for using this 669 procedure, so it doesn't care if they become a trouble for other 670 parties across Internet ("closed services"). 672 In any case, this scenario doesn't solve the issue of IPv4 literal 673 addresses or non-IPv6 compliant APIs, neither it solves the problem 674 of IPv4-only hosts within that IPv6-only access network. 676 +----------+ +----------+ +----------+ 677 | | | | | | 678 | IPv6 +--------+ NAT64 +--------+ IPv4 | 679 | | | | | | 680 +----------+ +----------+ +----------+ 682 Figure 10: NAT64 without DNS64 684 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts 686 In this scenario, the service provider offers the NAT64 function, but 687 not the DNS64 function. However, the IPv6 hosts have a built-in 688 DNS64 function. 690 This may become common if the DNS64 function is implemented in all 691 the IPv6 hosts/stacks, which is not the actual situation, but it may 692 happen in the medium-term. At this way, the DNSSEC validation is 693 performed on the A record, and then the host can use the DNS64 694 function so to be able to use the NAT64 function, without any DNSSEC 695 issues. 697 This scenario fails to solve the issue of IPv4 literal addresses or 698 non-IPv6 compliant APIs, unless the IPv6 hosts also supports HEv2 699 ([RFC8305], Section 7.1), which may solve that issue. 701 However, this scenario still fails to solve the problem of IPv4-only 702 hosts or applications behind the IPv6-only access network. 704 +----------+ +----------+ +----------+ 705 | IPv6 | | | | | 706 | + +--------+ NAT64 +--------+ IPv4 | 707 | DNS64 | | | | | 708 +----------+ +----------+ +----------+ 710 Figure 11: NAT64; DNS64 in IPv6 hosts 712 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network 714 In this scenario, the service provider offers the NAT64 function 715 only. The remote IPv4-only network offers the DNS64 function. 717 This is not common, and looks like doesn't make too much sense that a 718 remote network, not deploying IPv6, is providing a DNS64 function. 719 As in the case of the scenario depicted in Section 3.2.1, it will 720 only work if both sides are using the WKP or the same NSP, so the 721 same considerations apply. It can be also tuned to behave as in 722 Section 3.1.1 724 This scenario still fails to solve the issue of IPv4 literal 725 addresses or non-IPv6 compliant APIs. 727 This scenario also fails to solve the problem of IPv4-only hosts or 728 applications behind the IPv6-only access network. 730 +----------+ +----------+ +----------+ 731 | | | | | IPv4 | 732 | IPv6 +--------+ NAT64 +--------+ + | 733 | | | | | DNS64 | 734 +----------+ +----------+ +----------+ 736 Figure 12: NAT64; DNS64 in the IPv4-only 738 3.3. Comparing the Scenarios 740 This section compares the different scenarios, including the possible 741 variations (each one represented in the precedent sections by a 742 different figure), looking at the following criteria: 744 a. DNSSEC: Are there hosts validating DNSSEC? 746 b. Literal/APIs: Are there applications using IPv4 literals or non- 747 IPv6 compliant APIs? 749 c. IPv4-only: Are there hosts or applications using IPv4-only? 751 d. Foreign DNS: Is the scenario surviving if the user, Operating 752 System, applications or devices change the DNS? 754 e. DNS load opt. (DNS load optimization): Are there extra queries 755 that may impact DNS infrastructure?. 757 f. Connect. opt. (Connection establishment delay optimization): Is 758 the UE/CE issuing only the AAAA query or also an A query and 759 waiting for both responses? 761 In the next table, the columns represent each of the scenarios from 762 the previous sections, by the figure number. The possible values 763 are: 765 o "-" Scenario "bad" for that criteria. 767 o "+" Scenario "good" for that criteria. 769 o "*" Scenario "bad" for that criteria, however it is typically 770 resolved, with the support of HEv2 ([RFC8305]). 772 In some cases, "countermeasures", alternative or special 773 configurations, may be available for the criteria designated as 774 "bad". So, this comparison is considering a generic case, as a quick 775 comparison guide. In some cases, a "bad" criterion is not 776 necessarily a negative aspect, all it depends on the specific needs/ 777 characteristics of the network where the deployment will take place. 778 For instance, in a network which has only IPv6-only hosts and apps 779 using only DNS and IPv6-compliant APIs, there is no impact using only 780 NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is 781 still relevant. 783 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 784 | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 785 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 786 | DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + | 787 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 788 | Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - | 789 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 790 | IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - | 791 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 792 | Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - | 793 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 794 | DNS load opt. | + | + | + | + | + | + | + | + | + | + | + | + | 795 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 796 | Connect. opt. | + | + | + | + | + | + | + | * | * | + | + | + | 797 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 799 Figure 13: Scenario Comparison 801 As a general conclusion, we should note that, if the network must 802 support applications using any of the following: 804 o IPv4 literals 806 o non-IPv6-compliant APIs 808 o IPv4-only hosts or applications 810 Then, only the scenarios with 464XLAT, a CLAT function, or equivalent 811 built-in local address synthesis features, will provide a valid 812 solution. Further to that, those scenarios will also keep working if 813 the DNS configuration is modified. Clearly also, depending on if 814 DNS64 is used or not, DNSSEC may be broken for those hosts doing 815 DNSSEC validation. 817 All the scenarios are good in terms of DNS load optimization, and in 818 the case of 464XLAT it may provide an extra degree of optimization. 819 Finally, all them are also good in terms of connection establishment 820 delay optimization. However, in the case of 464XLAT without DNS64, 821 it requires the usage of HEv2. This is not an issue, as commonly it 822 is available in actual Operating Systems. 824 4. Issues to be Considered 826 This section reviews the different issues that an operator needs to 827 consider towards a NAT64/464XLAT deployment, as they may bring to 828 specific decision points about how to approach that deployment. 830 4.1. DNSSEC Considerations and Possible Approaches 832 As indicated in Section 8 of [RFC6147] (DNS64, Security 833 Considerations), because DNS64 modifies DNS answers and DNSSEC is 834 designed to detect such modifications, DNS64 may break DNSSEC. 836 If a device connected to an IPv6-only WAN, queries for a domain name 837 in a signed zone, by means of a recursive name server that supports 838 DNS64, and the result is a synthesized AAAA record, and the recursive 839 name server is configured to perform DNSSEC validation and has a 840 valid chain of trust to the zone in question, it will 841 cryptographically validate the negative response from the 842 authoritative name server. This is the expected DNS64 behavior: The 843 recursive name server actually "lies" to the client device. However, 844 in most of the cases, the client will not notice it, because 845 generally, they don't perform validation themselves and instead, rely 846 on the recursive name servers. 848 A validating DNS64 resolver in fact, increase the confidence on the 849 synthetic AAAA, as it has validated that a non-synthetic AAAA for 850 sure, doesn't exists. However, if the client device is 851 NAT64-oblivious (most common case) and performs DNSSEC validation on 852 the AAAA record, it will fail as it is a synthesized record. 854 The best possible scenario from DNSSEC point of view, is when the 855 client requests the DNS64 server to perform the DNSSEC validation (by 856 setting the DO bit to 1 and the CD bit to 0). In this case, the 857 DNS64 server validates the data, thus tampering may only happen 858 inside the DNS64 server (which is considered as a trusted part, thus 859 its likelihood is low) or between the DNS64 server and the client. 860 All other parts of the system (including transmission and caching) 861 are protected by DNSSEC ([Threat-DNS64]). 863 Similarly, if the client querying the recursive name server is 864 another name server configured to use it as a forwarder, and is 865 performing DNSSEC validation, it will also fail on any synthesized 866 AAAA record. 868 All those considerations are extensively covered in Sections 3, 5.5 869 and 6.2 of [RFC6147]. 871 A solution to avoid DNSSEC issues, will be that all the signed zones 872 also provide IPv6 connectivity, together with the corresponding AAAA 873 records. However, this is out of the control of the operator needing 874 to deploy a NAT64 function. This has been proposed already in 875 [I-D.bp-v6ops-ipv6-ready-dns-dnssec]. 877 An alternative solution, which was the one considered while 878 developing [RFC6147], is that validators will be DNS64-aware, so 879 could perform the necessary discovery and do their own synthesis. 880 That was done under the expectation that it was sufficiently early in 881 the validator-deployment curve that it would be ok to break certain 882 DNSSEC assumptions for networks who were really stuck in a NAT64/ 883 DNS64-needing world. 885 As already indicated, the scenarios in the previous section, are in 886 fact somehow simplified, looking at the worst possible case. Saying 887 it in a different way: "trying to look for the most perfect 888 approach". DNSSEC breach will not happen if the end-host is not 889 doing validation. 891 Existing previous studies seems to indicate that the figures of 892 DNSSEC actually broken by using DNS64 will be around 1.7% 893 ([About-DNS64]) of the cases. However we can not negate that this 894 may increase, as DNSSEC deployment grows. Consequently, a decision 895 point for the operator must depend on "do I really care for that 896 percentage of cases and the impact in my helpdesk or can I provide 897 alternative solutions for them?". Some possible solutions may be 898 taken, as depicted in the next sections. 900 4.1.1. Not using DNS64 902 A solution will be to avoid using DNS64, but as already indicated 903 this is not possible in all the scenarios. 905 The use of DNS64 is a key component for some networks, in order to 906 comply with traffic performance metrics, monitored by some 907 governmental bodies and other institutions. 909 One drawback of not having a DNS64 at the network side, is that is 910 not possible to heuristically discover the NAT64 ([RFC7050]). 911 Consequently, an IPv6 host behind the IPv6-only access network, will 912 not be able to detect the presence of the NAT64 function, neither to 913 learn the IPv6 prefix to be used for it, unless it is configured by 914 alternative means. 916 The discovery of the IPv6 prefix could be solved by means of adding 917 the relevant AAAA records to the ipv4only.arpa. zone of the service 918 provider recursive servers, i.e., if using the WKP (64:ff9b::/96): 920 ipv4only.arpa. SOA . . 0 0 0 0 0 921 ipv4only.arpa. NS . 922 ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 923 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 924 ipv4only.arpa. A 192.0.0.170 925 ipv4only.arpa. A 192.0.0.171 927 An alternative option to the above, is the use of DNS RPZ 928 ([I-D.vixie-dns-rpz]) or equivalent functionalities. Note that this 929 may impact DNSSEC if the zone is signed. 931 One more alternative, only valid in environments with PCP support 932 (for both the hosts or CEs and for the service provider network), is 933 to follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). 935 Other alternatives may be available in the future. All them are 936 extensively discussed in [RFC7051], however the deployment evolution 937 has evolved many considerations from that document. New options are 938 being documented, such using Router Advertising 939 ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options 940 ([I-D.li-intarea-nat64-prefix-dhcp-option]). 942 It may be convenient the simultaneous support of several of the 943 possible approaches, in order to ensure that clients with different 944 ways to configure the NAT64 prefix, successfully obtain it. This is 945 also convenient even if DNS64 is being used. 947 4.1.2. DNSSEC validator aware of DNS64 949 In general, by default, DNS servers with DNS64 function, will not 950 synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the 951 query. In this case, as only an A record is available, it means that 952 the CLAT will take the responsibility, as in the case of literal IPv4 953 addresses, to keep that traffic flow end-to-end as IPv4, so DNSSEC is 954 not broken. However, this will not work if a CLAT function is not 955 present as the hosts will not be able to use IPv4 (scenarios without 956 464XLAT). 958 4.1.3. Stub validator 960 If the DO flag is set and the client device performs DNSSEC 961 validation, and the Checking Disabled (CD) flag is set for a query, 962 the DNS64 recursive server will not synthesize AAAA responses. In 963 this case, the client could perform the DNSSEC validation with the A 964 record and then synthesize the AAAA ([RFC6052]). For that to be 965 possible, the client must have learned beforehand the NAT64 prefix 966 using any of the available methods ([RFC7050], [RFC7225], 967 [I-D.ietf-6man-ra-pref64], 968 [I-D.li-intarea-nat64-prefix-dhcp-option]). This allows the client 969 device to avoid using the DNS64 function and still use NAT64 even 970 with DNSSEC. 972 If the end-host is IPv4-only, this will not work if a CLAT function 973 is not present (scenarios without 464XLAT). 975 Some devices or Operating Systems may implement, instead of a CLAT, 976 an equivalent function by using Bump-in-the-Host ([RFC6535]), 977 implemented as part of HEv2 (Section 7.1 of [RFC8305]). In this 978 case, the considerations in the above paragraphs are also applicable. 980 4.1.4. CLAT with DNS proxy and validator 982 If a CE includes CLAT support and also a DNS proxy, as indicated in 983 Section 6.4 of [RFC6877], the CE could behave as a stub validator on 984 behalf of the client devices. Then, following the same approach 985 described in the Section 4.1.3, the DNS proxy actually will "lie" to 986 the client devices, which in most of the cases will not notice it, 987 unless they perform validation by themselves. Again, this allow the 988 client devices to avoid using the DNS64 function and still use NAT64 989 with DNSSEC. 991 Once more, this will not work without a CLAT function (scenarios 992 without 464XLAT). 994 4.1.5. ACL of clients 996 In cases of dual-stack clients, the AAAA queries typically take 997 preference over A queries. If DNS64 is enabled for those clients, 998 will never get A records, even for IPv4-only servers. As a 999 consequence, if the IPv4-only servers are in the path before the 1000 NAT64 function, the clients will never reach them. If DNSSEC is 1001 being used for all those flows, specific addresses or prefixes can be 1002 left-out of the DNS64 synthesis by means of ACLs. 1004 Once more, this will not work without a CLAT function (scenarios 1005 without 464XLAT). 1007 4.1.6. Mapping-out IPv4 addresses 1009 If there are well-known specific IPv4 addresses or prefixes using 1010 DNSSEC, they can be mapped-out of the DNS64 synthesis. 1012 Even if this is not related to DNSSEC, this "mapping-out" feature is 1013 actually, quite commonly used to ensure that [RFC1918] addresses (for 1014 example used by LAN servers) are not synthesized to AAAA. 1016 Once more, this will not work without a CLAT function (scenarios 1017 without 464XLAT). 1019 4.2. DNS64 and Reverse Mapping 1021 When a client device, using DNS64 tries to reverse-map a synthesized 1022 IPv6 address, the name server responds with a CNAME record pointing 1023 the domain name used to reverse-map the synthesized IPv6 address (the 1024 one under ip6.arpa), to the domain name corresponding to the embedded 1025 IPv4 address (under in-addr.arpa). 1027 This is the expected behavior, so no issues need to be considered 1028 regarding DNS reverse mapping. 1030 4.3. Using 464XLAT with/without DNS64 1032 In the case the client device is IPv6-only (either because the stack 1033 or application is IPv6-only, or because it is connected via an 1034 IPv6-only LAN) and the remote server is IPv4-only (either because the 1035 stack is IPv4-only, or because it is connected via an IPv4-only LAN), 1036 only NAT64 combined with DNS64 will be able to provide access among 1037 both. Because DNS64 is then required, DNSSEC validation will be only 1038 possible if the recursive name server is validating the negative 1039 response from the authoritative name server and the client is not 1040 performing validation. 1042 Note that is not expected at this stage of the transition, that 1043 applications, devices or Operating Systems are IPv6-only. It will 1044 not be a sensible decision for a developer to work on that direction, 1045 unless it is clear that the deployment scenario fully supports it. 1047 On the other hand, an end-user or enterprise network may decide to 1048 run IPv6-only in the LANs. In case there is any chance for 1049 applications to be IPv6-only, the Operating System may be responsible 1050 either for doing a local address synthesis, or alternatively, setting 1051 up some kind of on-demand VPN (IPv4-in-IPv6), which need to be 1052 supported by that network. This may become very common in enterprise 1053 networks, where "Unique IPv6 Prefix per Host" [RFC8273] is supported. 1055 However, when the client device is dual-stack and/or connected in a 1056 dual-stack LAN by means of a CLAT function (or has a built-in CLAT 1057 function), DNS64 is an option. 1059 1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if 1060 using literal IPv4 addresses or non-IPv6 compliant APIs) will not 1061 use the CLAT, so will use the IPv6 path and only one translation 1062 will be done at the NAT64. This may break DNSSEC, unless 1063 measures as described in the precedent sections are taken. 1065 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will 1066 make use of the CLAT, so two translations are required (NAT46 at 1067 the CLAT and NAT64 at the PLAT), which adds some overhead in 1068 terms of the extra NAT46 translation. However, this avoids the 1069 AAAA synthesis and consequently will never break DNSSEC. 1071 Note that the extra translation, when DNS64 is not used, takes place 1072 at the CLAT, which means no extra overhead for the operator. It 1073 however adds potential extra delays to establish the connections, and 1074 no perceptible impact for a CE in a broadband network, while it may 1075 have some impact in a battery powered device. This cost for a 1076 battery powered device, is possibly comparable to the cost when the 1077 device is doing a local address synthesis (see Section 7.1 of 1078 [RFC8305]). 1080 4.4. Foreign DNS 1082 Clients, devices or applications in a service provider network, may 1083 use DNS servers from other networks. This may be the case either if 1084 individual applications use their own DNS server, the Operating 1085 System itself or even the CE, or combinations of the above. 1087 Those "foreign" DNS servers may not support DNS64, which will mean 1088 that those scenarios that require a DNS64 may not work. However, if 1089 a CLAT function is available, the considerations in Section 4.3 will 1090 apply. 1092 In the case that the foreign DNS supports the DNS64 function, we may 1093 be in the situation of providing incorrect configurations parameters, 1094 for example, un-matching WKP or NSP, or a case such the one described 1095 in Section 3.2.3. 1097 Having a CLAT function, even if using foreign DNS without a DNS64 1098 function, ensures that everything will work, so the CLAT must be 1099 considered as an advantage even against user configuration errors. 1100 The cost of this, is that all the traffic will use a double 1101 translation (NAT46 at the CLAT and NAT64 at the operator network), 1102 unless there is support for EAM (Section 4.9). 1104 An exception to that is the case when there is a CLAT function at the 1105 CE, which is not able to obtain the correct configuration parameters 1106 (again, un-matching WKP or NSP). 1108 However, it needs to be emphasized, that if there is not a CLAT 1109 function (scenarios without 464XLAT), an external DNS without DNS64 1110 support, will disallow any access to IPv4-only destination networks, 1111 and will not guarantee DNSSEC, so will behave as in the 1112 Section 3.2.1. 1114 The causes of "foreign DNS" could be classified in three main 1115 categories, as depicted in the following sub-sections. 1117 4.4.1. Manual Configuration of Foreign DNS 1119 It is becoming increasingly common that end-users or even devices or 1120 applications configure alternative DNS in their Operating Systems, 1121 and sometimes in CEs. 1123 4.4.2. DNS Privacy 1125 A new trend is for clients or applications to use mechanisms for DNS 1126 privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS 1127 ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC 1128 ([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH 1129 and DoQ. 1131 Those DNS privacy/encryption options, currently are typically 1132 provided by the applications, not the Operating System vendors. At 1133 the time of writing this document, at least DoT and DoH standards 1134 have declared DNS64 (and consequently NAT64) out of their scope, so 1135 an application using them may break NAT64, unless a correctly 1136 configured CLAT function is used. 1138 4.4.3. Split DNS 1140 When networks or hosts use "split-DNS" (also called Split Horizon, 1141 DNS views or private DNS), the successful use of the DNS64 is not 1142 guaranteed. Section 4 of [RFC6950], analyses this case. 1144 A similar situation may happen in case of VPNs that force all the DNS 1145 queries through the VPN, ignoring the operator DNS64 function. 1147 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 1149 Section 3 of [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), 1150 discusses some considerations which are useful to decide if an 1151 operator should use the WKP or an NSP. 1153 Taking in consideration that discussion and other issues, we can 1154 summarize the possible decision points as: 1156 a. The WKP MUST NOT be used to represent non-global IPv4 addresses. 1157 If this is required because the network to be translated use non- 1158 global addresses, then an NSP is required. 1160 b. The WKP MAY appear in inter-domain routing tables, if the 1161 operator provides a NAT64 function to peers. However, in this 1162 case, special considerations related to BGP filtering are 1163 required and IPv4-embedded IPv6 prefixes longer than the WKP MUST 1164 NOT be advertised (or accepted) in BGP. An NSP may be a more 1165 appropriate option in those cases. 1167 c. If several NAT64 use the same prefix, packets from the same flow 1168 may be routed to different NAT64 in case of routing changes. 1169 This can be avoided either by using different prefixes for each 1170 NAT64 function, or by ensuring that all the NAT64 coordinate 1171 their state. Using an NSP could simplify that. 1173 d. If DNS64 is required and users, devices, Operating Systems or 1174 applications may change their DNS configuration, and deliberately 1175 choose an alternative DNS64 function, most probably alternative 1176 DNS64 will use by default the WKP. In that case, if an NSP is 1177 used by the NAT64 function, clients will not be able to use the 1178 operator NAT64 function, which will break connectivity to 1179 IPv4-only destinations. 1181 4.6. IPv4 literals and old APIs 1183 A host or application using literal IPv4 addresses or older APIs, 1184 behind a network with IPv6-only access, will not work unless any of 1185 the following alternatives is provided: 1187 o CLAT (or equivalent function). 1189 o HEv2 (Section 7.1, [RFC8305]). 1191 o Bump-in-the-Host ([RFC6535]) with a DNS64 function. 1193 Those alternatives will solve the problem for an end-host. However, 1194 if that end-hosts is providing "tethering" or an equivalent service 1195 to other hosts, that needs to be considered as well. In other words, 1196 in a case of a cellular network, it resolves the issue for the UE 1197 itself, but may be not the case for hosts behind it. 1199 Otherwise, the support of 464XLAT is the only valid and complete 1200 approach to resolve this issue. 1202 4.7. IPv4-only Hosts or Applications 1204 An IPv4-only hosts or application behind a network with IPv6-only 1205 access, will not work unless a CLAT function is present. 1207 464XLAT is the only valid approach to resolve this issue. 1209 4.8. CLAT Translation Considerations 1211 As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if 1212 the CLAT function can be configured with a dedicated /64 prefix for 1213 the NAT46 translation, then it will be possible to do a more 1214 efficient stateless translation. 1216 Otherwise, if this dedicated prefix is not available, the CLAT 1217 function will need to do a stateful translation, for example 1218 performing stateful NAT44 for all the IPv4 LAN packets, so they 1219 appear as coming from a single IPv4 address, and then in turn, 1220 stateless translated to a single IPv6 address. 1222 A possible setup, in order to maximize the CLAT performance, is to 1223 configure the dedicated translation prefix. This can be easily 1224 achieved automatically, if the broadband CE or end-user device is 1225 able to obtain a shorter prefix by means of DHCPv6-PD ([RFC8415]), or 1226 other alternatives. The CE can then use a specific /64 for the 1227 translation. This is also possible when broadband is provided by a 1228 cellular access. 1230 The above recommendation is often not possible for cellular networks, 1231 when connecting smartphones (as UEs), as generally they don't use 1232 DHCPv6-PD ([RFC8415]). Instead, a single /64 is provided for each 1233 PDP context and prefix sharing ([RFC6877]) is used. So, in this 1234 case, the UEs typically have a build-in CLAT function which is 1235 performing a stateful NAT44 translation before the stateless NAT46. 1237 4.9. EAM Considerations 1239 Explicit Address Mappings for Stateless IP/ICMP Translation 1240 ([RFC7757]) provide a way to configure explicit mappings between IPv4 1241 and IPv6 prefixes of any length. When this is used, for example in a 1242 CLAT function, it may provide a simple mechanism in order to avoid 1243 traffic flows between IPv4-only nodes or applications and dual-stack 1244 destinations to be translated twice (NAT46 and NAT64), by creating 1245 mapping entries with the GUA of the IPv6-reachable destination. This 1246 optimization of the NAT64 usage is very useful in many scenarios, 1247 including CDNs and caches, as described in 1248 [I-D.palet-v6ops-464xlat-opt-cdn-caches]. 1250 In addition to that, it may provide as well a way for IPv4-only nodes 1251 or applications to communicate with IPv6-only destinations. 1253 4.10. Incoming Connections 1255 The use of NAT64, in principle, disallows IPv4 incoming connections, 1256 which may be still needed for IPv4-only peer-to-peer applications. 1257 However, there are several alternatives that resolve this issue: 1259 a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are 1260 commonly used by peer-to-peer applications in order to allow 1261 incoming connections with IPv4 NAT. In the case of NAT64, they 1262 work as well. 1264 b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and 1265 IPv6 packets are translated and forwarded. A NAT64 may implement 1266 PCP to allow this service. 1268 c. EAM ([RFC7757]) may also be used in order to configure explicit 1269 mappings for customers that require them. This is used for 1270 example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]). 1272 5. Summary of Deployment Recommendations for NAT64/464XLAT 1274 NAT64/464XLAT has demonstrated to be a valid choice in several 1275 scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions 1276 of users, offering different choices of deployment, depending on each 1277 network case, needs and requirements. Despite that, this document is 1278 not an explicit recommendation for using this choice versus other 1279 IPv4aaS transition mechanisms. Instead, this document is a guide 1280 that facilitates evaluating a possible implementation of 1281 NAT64/464XLAT and key decision points about specific design 1282 considerations for its deployment. 1284 Depending on the specific requirements of each deployment case, DNS64 1285 may be a required function, while in other cases the adverse effects 1286 may be counterproductive. Similarly, in some cases a NAT64 function, 1287 together with a DNS64 function, may be a valid solution, when there 1288 is a certainty that IPv4-only hosts or applications do not need to be 1289 supported (Section 4.6 and Section 4.7). However, in other cases 1290 (i.e. IPv4-only devices or applications need to be supported), the 1291 limitations of NAT64/DNS64, may suggest the operator to look into 1292 464XLAT as a more complete solution. 1294 In the case of broadband managed networks (where the CE is provided 1295 or suggested/supported by the operator), in order to fully support 1296 the actual user needs (IPv4-only devices and applications, usage of 1297 IPv4 literals and old APIs), the 464XLAT scenario should be 1298 considered. In that case, it must support a CLAT function. 1300 If the operator provides DNS services, in order to increase 1301 performance by reducing the double translation for all the IPv4 1302 traffic, they may support a DNS64 function and avoid, as much as 1303 possible, breaking DNSSEC. In this case, if the DNS service is 1304 offering DNSSEC validation, then it must be in such way that it is 1305 aware of the DNS64. This is considered the simpler and safer 1306 approach, and may be combined as well with other recommendations 1307 described in this document: 1309 o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). 1311 o Devices running CLAT SHOULD follow the indications in 1312 Section 4.1.3 (Stub Validator). However, this may be out of the 1313 control of the operator. 1315 o CEs SHOULD include a DNS proxy and validator (Section 4.1.4). 1317 o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4 1318 addresses) MAY be considered by operators, depending on their own 1319 infrastructure. 1321 This "increased performance" approach has the disadvantage of 1322 potentially breaking DNSSEC for a small percentage of validating end- 1323 hosts versus the small impact of a double translation taking place in 1324 the CE. If CE performance is not an issue, which is the most 1325 frequent case, then a much safer approach is to not use DNS64 at all, 1326 and consequently, ensure that all the IPv4 traffic is translated at 1327 the CLAT (Section 4.3). 1329 If DNS64 is not used, at least one of the alternatives described in 1330 Section 4.1.1, must be followed in order to learn he NAT64 prefix. 1332 The operator needs to consider that if the DNS configuration can be 1333 modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most 1334 probably is impossible to avoid, there are chances that instead of 1335 configuring a DNS64 a foreign non-DNS64 is used. In a scenario with 1336 only a NAT64 function IPv4-only remote host will no longer be 1337 accessible. Instead, it will continue to work in the case of 1338 464XLAT. 1340 Similar considerations need to be taken regarding the usage of a 1341 NAT64 WKP vs NSP (Section 4.5), as they must match with the 1342 configuration of the DNS64. In case of using foreign DNS, they may 1343 not match. If there is a CLAT and the configured foreign DNS is not 1344 a DNS64, the network will keep working only if other means of 1345 learning the NAT64 prefix are available. 1347 As described in Section 4.8, for broadband networks, the CEs 1348 supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or 1349 alternative means for configuring a shorter prefix. The CE SHOULD 1350 internally reserve one /64 for the stateless NAT46 translation. The 1351 operator must ensure that the customers get allocated prefixes 1352 shorter than /64 in order to support this optimization. One way or 1353 the other, this is not impacting the performance of the operator 1354 network. 1356 Operators may follow Section 7 of [RFC6877] (Deployment 1357 Considerations), for suggestions in order to take advantage of 1358 traffic engineering requirements. 1360 In the case of cellular networks, the considerations regarding DNSSEC 1361 may appear as out-of-scope, because UEs Operating Systems, commonly 1362 don't support DNSSEC. However, applications running on them may do, 1363 or it may be an Operating System "built-in" support in the future. 1364 Moreover, if those devices offer tethering, other client devices 1365 behind the UE, may be doing the validation, hence the relevance of a 1366 proper DNSSEC support by the operator network. 1368 Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and 1369 "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" 1370 ([RFC7050]), allow a progressive IPv6 deployment, with a single APN 1371 supporting all types of PDP context (IPv4, IPv6, IPv4v6). This 1372 approach allows the network to automatically serve every possible 1373 combinations of UEs. 1375 If the operator chooses to provide validation for the DNS64 prefix 1376 discovery, it must follow the advice from Section 3.1. of [RFC7050] 1377 (Validation of Discovered Pref64::/n). 1379 One last consideration, is that many networks may have a mix of 1380 different complex scenarios at the same time, for example, customers 1381 requiring 464XLAT, others not requiring it, customers requiring 1382 DNS64, others not, etc. In general, the different issues and the 1383 approaches described in this document can be implemented at the same 1384 time for different customers or parts of the network. That mix of 1385 approaches don't present any problem or incompatibility, as they work 1386 well together, being just a matter of appropriate and differentiated 1387 provisioning. In fact, the NAT64/464XLAT approach facilitates an 1388 operator offering both cellular and broadband services, to have a 1389 single IPv4aaS for both networks while differentiating the deployment 1390 key decisions to optimize each case. It even makes possible using 1391 hybrid CEs that have a main broadband access link and a backup via 1392 the cellular network. 1394 In an ideal world we could safely use DNS64, if the approach proposed 1395 in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, avoiding the 1396 cases where DNSSEC may be broken. However, this will not solve the 1397 issues related to DNS Privacy and Split DNS. 1399 The only 100% safe solution, which also resolves all the issues, will 1400 be, in addition to having a CLAT function, not using a DNS64 but 1401 instead making sure that the hosts have a built-in address synthesis 1402 feature. Operators could manage to provide CEs with the CLAT 1403 function, however the built-in address synthesis feature is out of 1404 their control. If the synthesis is provided either by the Operating 1405 System (via its DNS resolver API) or by the application (via its own 1406 DNS resolver), in such way that the prefix used for the NAT64 1407 function is reachable for the host, the problem goes away. 1409 Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9, 1410 provides a very relevant optimization, avoiding double-translations. 1412 Applications that require incoming connections, typically already 1413 provide means for that. However, PCP and EAM, as indicated in 1414 Section 4.10, are valid alternatives, even for creating explicit 1415 mappings for customers that require them. 1417 6. Deployment of NAT64 in Enterprise Networks 1419 The recommendations of this document can be used as well in 1420 enterprise networks, campus and other similar scenarios (including 1421 managed end-user networks). 1423 This include scenarios where the NAT64 function (and DNS64 function, 1424 if available) are under the control of that network (or can be 1425 configured manually according to that network specific requirements), 1426 and for whatever reasons, there is a need to provide "IPv6-only 1427 access" to any part of that network or it is IPv6-only connected to 1428 third party-networks. 1430 An example of that is the IETF meetings network itself, where both 1431 NAT64 and DNS64 functions are provided, presenting in this case the 1432 same issues as per Section 3.1.1. If there is a CLAT function in the 1433 IETF network, then there is no need to use DNS64 and it falls under 1434 the considerations of Section 3.1.3. Both scenarios have been tested 1435 and verified already in the IETF network itself. 1437 Next figures are only meant to represent a few of the possible 1438 scenarios, not pretending to be the only feasible ones. 1440 The following figure provides an example of an IPv6-only enterprise 1441 network connected with dual-stack to Internet and using local NAT64 1442 and DNS64 functions. 1444 +----------------------------------+ 1445 | Enterprise Network | 1446 | +----------+ +----------+ | +----------+ 1447 | | IPv6 | | NAT64 | | | IPv4 | 1448 | | only +--------+ + | +-------+ + | 1449 | | LANs | | DNS64 | | | IPv6 | 1450 | +----------+ +----------+ | +----------+ 1451 +----------------------------------+ 1453 Figure 14: IPv6-only enterprise with NAT64 and DNS64 1455 The following figure provides an example of a dual-stack (DS) 1456 enterprise network connected with dual-stack (DS) to Internet and 1457 using a CLAT function, without a DNS64 function. 1459 +----------------------------------+ 1460 | Enterprise Network | 1461 | +----------+ +----------+ | +----------+ 1462 | | IPv6 | | | | | IPv4 | 1463 | | + +--------+ NAT64 | +-------+ + | 1464 | | CLAT | | | | | IPv6 | 1465 | +----------+ +----------+ | +----------+ 1466 +----------------------------------+ 1468 Figure 15: DS enterprise with CLAT, DS Internet, without DNS64 1470 Finally, the following figure provides an example of an IPv6-only 1471 provider with a NAT64 function, and a dual-stack (DS) enterprise 1472 network by means of their own CLAT function, without a DNS64 1473 function. 1475 +----------------------------------+ 1476 | Enterprise Network | 1477 | +----------+ +----------+ | +----------+ 1478 | | IPv6 | | | | IPv6 | | 1479 | | + +--------+ CLAT | +--------+ NAT64 | 1480 | | IPv4 | | | | only | | 1481 | +----------+ +----------+ | +----------+ 1482 +----------------------------------+ 1484 Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64 1486 7. Security Considerations 1488 This document does not have new specific security considerations 1489 beyond those already reported by each of the documents cited. 1491 8. IANA Considerations 1493 This document does not have any new specific IANA considerations. 1495 Note: This section is assuming that https://www.rfc- 1496 editor.org/errata/eid5152 is resolved, otherwise, this section may 1497 include the required text to resolve the issue. 1499 9. Acknowledgements 1501 The author would like to acknowledge the inputs of Gabor Lencse, 1502 Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed 1503 Boucadair, Alejandro D'Egidio, Dan Wing and Mikael Abrahamsson. 1505 Conversations with Marcelo Bagnulo, one of the co-authors of NAT64 1506 and DNS64, as well as several emails in mailing lists from Mark 1507 Andrews, have been very useful for this work. 1509 Christian Huitema inspired working in this document by suggesting 1510 that DNS64 should never be used, during a discussion regarding the 1511 deployment of CLAT in the IETF network. 1513 10. ANNEX A: Example of Broadband Deployment with 464XLAT 1515 This section summarizes how an operator may deploy an IPv6-only 1516 network for residential/SOHO customers, supporting IPv6 inbound 1517 connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT. 1519 Note that an equivalent setup could also be provided for enterprise 1520 customers. In case they need to support IPv4 inbound connections, 1521 several mechanisms, depending on specific customer needs, allow that, 1522 for instance [RFC7757]. 1524 Conceptually, most part of the operator network could be IPv6-only 1525 (represented in the next pictures as "IPv6-only flow"), or even if 1526 this part of the network is actually dual-stack, only IPv6-access is 1527 available for some customers (i.e. residential customers). This part 1528 of the network connects the IPv6-only subscribers (by means of 1529 IPv6-only access links), to the IPv6 upstream providers, as well as 1530 to the IPv4-Internet by means of the NAT64 (PLAT in the 464XLAT 1531 terminology). 1533 The traffic flow from and back to the CE to services available in the 1534 IPv6 Internet (or even dual-stack remote services, when IPv6 is being 1535 used), is purely native IPv6 traffic, so there are no special 1536 considerations about it. 1538 Looking at the picture from the DNS perspective, there are remote 1539 networks with are IPv4-only, and typically will have only IPv4 DNS 1540 (DNS/IPv4), or at least will be seen as that from the CE perspective. 1541 At the operator side, the DNS, as seen from the CE, is only IPv6 1542 (DNS/IPv6) and has also a DNS64 function. 1544 In the customer LANs side, there is actually one network, which of 1545 course could be split in different segments. The most common setup 1546 will be those segments being dual-stack, using global IPv6 addresses 1547 and [RFC1918] for IPv4, as usual in any regular residential/SOHO IPv4 1548 network. In the figure, it is represented as tree segments, just to 1549 show that the three possible setups are valid (IPv6-only, IPv4-only 1550 and dual-stack). 1552 .-----. +-------+ .-----. .-----. 1553 / IPv6- \ | | / \ / \ 1554 ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ 1555 \ LANs / | SOHO +--( only )--( NAT64 )--( only ) 1556 `-----' | | \ flow / `-----' \ flow / 1557 .-----. | IPv6 | \ / \ / 1558 / IPv4- \ | CE | `--+--' `--+--' 1559 ( only )--+ with | | | 1560 \ LANs / | CLAT | +---+----+ +---+----+ 1561 `-----' | | |DNS/IPv6| |DNS/IPv4| 1562 .-----. +---+---+ | with | +--------+ 1563 / Dual- \ | | DNS64 | 1564 ( Stack )------| +--------+ 1565 \ LANs / 1566 `-----' 1568 Figure 17: CE setup with built-in CLAT with DNS64 1570 In addition to the regular CE setup, which will be typically access- 1571 technology dependent, the steps for the CLAT function configuration 1572 can be summarized as: 1574 1. Discovery of the PLAT (NAT64) prefix: It may be done using 1575 [RFC7050], or in those networks where PCP is supported, by means 1576 of [RFC7225], or other alternatives that may be available in the 1577 future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or 1578 DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]). 1580 2. If the CLAT function allows stateless NAT46 translation, a /64 1581 from the pool typically provided to the CE by means of DHCPv6-PD 1582 [RFC8415], need to be set aside for that translation. Otherwise, 1583 the CLAT is forced to perform an intermediate stateful NAT44 1584 before the a stateless NAT46, as described in Section 4.8. 1586 A more detailed configuration approach is described in [RFC8585]. 1588 The operator network needs to ensure that the correct responses are 1589 provided for the discovery of the PLAT prefix. It is highly 1590 recommended to follow [RIPE-690], in order to ensure that multiple 1591 /64s are available, including the one needed for the NAT46 stateless 1592 translation. 1594 The operator needs to understand other issues, described across this 1595 document, in order to take the relevant decisions. For example, if 1596 several NAT64 functions are needed in the context of scalability/ 1597 high-availability, an NSP should be considered (Section 4.5). 1599 More complex scenarios are possible, for example, if a network offers 1600 multiple NAT64 prefixes, destination-based NAT64 prefixes, etc. 1602 If the operator decides not to provide a DNS64 function, then this 1603 setup turns into the one in the following Figure. This will be also 1604 the setup that "will be seen" from the perspective of the CE, if a 1605 foreign DNS is used and consequently is not the operator-provided 1606 DNS64 function. 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 .-----. +---+---+ +--------+ +--------+ 1619 / Dual- \ | 1620 ( Stack )------| 1621 \ LANs / 1622 `-----' 1624 Figure 18: CE setup with built-in CLAT without DNS64 1626 In this case, the discovery of the PLAT prefix needs to be arranged 1627 as indicated in Section 4.1.1. 1629 In this case, the CE doesn't have a built-in CLAT function, or the 1630 customer can choose to setup the IPv6 operator-managed CE in bridge 1631 mode (and optionally use an external router), or for example, there 1632 is an access technology that requires some kind of media converter 1633 (ONT for FTTH, Cable-Modem for DOCSIS, etc.), the complete setup will 1634 look as in the next figure. Obviously, there will be some 1635 intermediate configuration steps for the bridge, depending on the 1636 specific access technology/protocols, which should not modify the 1637 steps already described in the previous cases for the CLAT function 1638 configuration. 1640 +-------+ .-----. .-----. 1641 | | / \ / \ 1642 | Res./ | / IPv6- \ .-----. / IPv4- \ 1643 | SOHO +--( only )--( NAT64 )--( only ) 1644 | | \ flow / `-----' \ flow / 1645 | IPv6 | \ / \ / 1646 | CE | `--+--' `--+--' 1647 | Bridge| | | 1648 | | +---+----+ +---+----+ 1649 | | |DNS/IPv6| |DNS/IPv4| 1650 +---+---+ +--------+ +--------+ 1651 | 1652 .-----. +---+---+ 1653 / IPv6- \ | | 1654 ( only )--+ IPv6 | 1655 \ LANs / | Router| 1656 `-----' | | 1657 .-----. | with | 1658 / IPv4- \ | CLAT | 1659 ( only )--+ | 1660 \ LANs / | | 1661 `-----' | | 1662 .-----. +---+---+ 1663 / Dual- \ | 1664 ( Stack )------| 1665 \ LANs / 1666 `-----' 1668 Figure 19: CE setup with bridged CLAT without DNS64 1670 It should be avoided that several routers (i.e., the operator 1671 provided CE and a downstream user provided router) enable 1672 simultaneously routing and/or CLAT, in order to avoid multiple NAT44 1673 and NAT46 levels, as well as ensuring the correct operation of 1674 multiple IPv6 subnets. In those cases, it is suggested the use of 1675 HNCP ([RFC8375]). 1677 Note that the procedure described here for the CE setup, can be 1678 simplified if the CE follows [RFC8585]. 1680 11. ANNEX B: CLAT Implementation 1682 In addition to the regular set of features for a CE, a CLAT CE 1683 implementation requires support of: 1685 o [RFC7915] for the NAT46 function. 1687 o [RFC7050] for the PLAT prefix discovery. 1689 o [RFC7225] for the PLAT prefix discovery if PCP is supported. 1691 o [I-D.ietf-6man-ra-pref64] for the PLAT prefix discovery by means 1692 of Router Advertising. 1694 o If stateless NAT46 is supported, a mechanism to ensure that 1695 multiple /64 are available, such as DHCPv6-PD [RFC8415]. 1697 There are several OpenSource implementations of CLAT, such as: 1699 o Android: https://github.com/ddrown/android_external_android-clat. 1701 o Jool: https://www.jool.mx. 1703 o Linux: https://github.com/toreanderson/clatd. 1705 o OpenWRT: https://github.com/openwrt- 1706 routing/packages/blob/master/nat46/files/464xlat.sh. 1708 o VPP: https://git.fd.io/vpp/tree/src/plugins/nat. 1710 12. ANNEX C: Benchmarking 1712 [RFC8219] has defined a benchmarking methodology for IPv6 transition 1713 technologies. NAT64 and 464XLAT are addressed among the single and 1714 double translation technologies, respectively. DNS64 is addressed in 1715 Section 9, and the methodology is more elaborated in [DNS64-BM-Meth]. 1717 Several documents provide references to benchmarking results, for 1718 example in the case of DNS64, [DNS64-Benchm]. 1720 13. ANNEX D: Changes from -00 to -01/-02 1722 Section to be removed after WGLC. Significant updates are: 1724 1. Text changes across all the document. 1726 14. ANNEX E: Changes from -02 to -03 1728 Section to be removed after WGLC. Significant updates are: 1730 1. Added references to new cited documents. 1732 2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only 1733 LANs w/o DNS64. 1735 3. Overall review and editorial changes. 1737 15. ANNEX F: Changes from -03 to -04 1739 Section to be removed after WGLC. Significant updates are: 1741 1. Added text related to EAM considerations. 1743 16. ANNEX G: Changes from -04 to -05 1745 Section to be removed after WGLC. Significant updates are: 1747 1. Added cross references to EAM section. 1749 2. Reworded "foreing DNS section". 1751 3. Overall editorial review of text, pictures and nits correction. 1753 17. ANNEX H: Changes from -05 to -06 1755 Section to be removed after WGLC. Significant updates are: 1757 1. Corrected EAMT to EAM. 1759 2. Typos and nits. 1761 3. New considerations regarding incoming connections. 1763 18. References 1765 18.1. Normative References 1767 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1768 and E. Lear, "Address Allocation for Private Internets", 1769 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1770 . 1772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1773 Requirement Levels", BCP 14, RFC 2119, 1774 DOI 10.17487/RFC2119, March 1997, 1775 . 1777 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1778 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1779 DOI 10.17487/RFC5389, October 2008, 1780 . 1782 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 1783 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 1784 . 1786 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1787 Relays around NAT (TURN): Relay Extensions to Session 1788 Traversal Utilities for NAT (STUN)", RFC 5766, 1789 DOI 10.17487/RFC5766, April 2010, 1790 . 1792 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1793 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1794 DOI 10.17487/RFC6052, October 2010, 1795 . 1797 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1798 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1799 April 2011, . 1801 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1802 NAT64: Network Address and Protocol Translation from IPv6 1803 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1804 April 2011, . 1806 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1807 Beijnum, "DNS64: DNS Extensions for Network Address 1808 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1809 DOI 10.17487/RFC6147, April 2011, 1810 . 1812 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 1813 Using "Bump-in-the-Host" (BIH)", RFC 6535, 1814 DOI 10.17487/RFC6535, February 2012, 1815 . 1817 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1818 Combination of Stateful and Stateless Translation", 1819 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1820 . 1822 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1823 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1824 DOI 10.17487/RFC6887, April 2013, 1825 . 1827 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1828 the IPv6 Prefix Used for IPv6 Address Synthesis", 1829 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1830 . 1832 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 1833 Port Control Protocol (PCP)", RFC 7225, 1834 DOI 10.17487/RFC7225, May 2014, 1835 . 1837 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 1838 Mappings for Stateless IP/ICMP Translation", RFC 7757, 1839 DOI 10.17487/RFC7757, February 2016, 1840 . 1842 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1843 "IP/ICMP Translation Algorithm", RFC 7915, 1844 DOI 10.17487/RFC7915, June 2016, 1845 . 1847 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1848 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1849 May 2017, . 1851 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1852 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1853 . 1855 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1856 Better Connectivity Using Concurrency", RFC 8305, 1857 DOI 10.17487/RFC8305, December 2017, 1858 . 1860 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1861 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1862 . 1864 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1865 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1866 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1867 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1868 . 1870 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1871 Connectivity Establishment (ICE): A Protocol for Network 1872 Address Translator (NAT) Traversal", RFC 8445, 1873 DOI 10.17487/RFC8445, July 2018, 1874 . 1876 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1877 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1878 . 1880 18.2. Informative References 1882 [About-DNS64] 1883 Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016, 1884 . 1887 [DNS64-Benchm] 1888 Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 1889 Implementations: Theory and Practice", Computer 1890 Communications , vol. 127, no. 1, pp. 61-74, 1891 DOI 10.1016/j.comcom.2018.05.005, September 2018. 1893 [DNS64-BM-Meth] 1894 Lencse, G., Georgescu, M., and Y. Kadobayashi, 1895 "Benchmarking Methodology for DNS64 Servers", Computer 1896 Communications , vol. 109, no. 1, pp. 162-175, 1897 DOI 10.1016/j.comcom.2017.06.004, September 2017. 1899 [I-D.bp-v6ops-ipv6-ready-dns-dnssec] 1900 Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC 1901 Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00 1902 (work in progress), October 2018. 1904 [I-D.huitema-quic-dnsoquic] 1905 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 1906 Iyengar, "Specification of DNS over Dedicated QUIC 1907 Connections", draft-huitema-quic-dnsoquic-06 (work in 1908 progress), March 2019. 1910 [I-D.ietf-6man-ra-pref64] 1911 Colitti, L., Kline, E., and J. Linkova, "Discovering 1912 PREF64 in Router Advertisements", draft-ietf-6man-ra- 1913 pref64-00 (work in progress), March 2019. 1915 [I-D.li-intarea-nat64-prefix-dhcp-option] 1916 Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet, 1917 "DHCPv6 Options for Discovery NAT64 Prefixes", draft-li- 1918 intarea-nat64-prefix-dhcp-option-02 (work in progress), 1919 April 2019. 1921 [I-D.lmhp-v6ops-transition-comparison] 1922 Lencse, G., Palet, J., Howard, L., Patterson, R., and I. 1923 Farrer, "Pros and Cons of IPv6 Transition Technologies for 1924 IPv4aaS", draft-lmhp-v6ops-transition-comparison-02 (work 1925 in progress), January 2019. 1927 [I-D.palet-v6ops-464xlat-opt-cdn-caches] 1928 Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/ 1929 Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work 1930 in progress), March 2019. 1932 [I-D.vixie-dns-rpz] 1933 Vixie, P. and V. Schryver, "DNS Response Policy Zones 1934 (RPZ)", draft-vixie-dns-rpz-04 (work in progress), 1935 December 2016. 1937 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 1938 "Analysis of Stateful 64 Translation", RFC 6889, 1939 DOI 10.17487/RFC6889, April 2013, 1940 . 1942 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 1943 "Architectural Considerations on Application Features in 1944 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 1945 . 1947 [RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of 1948 Solution Proposals for Hosts to Learn NAT64 Prefix", 1949 RFC 7051, DOI 10.17487/RFC7051, November 2013, 1950 . 1952 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 1953 Deployment Options and Experience", RFC 7269, 1954 DOI 10.17487/RFC7269, June 2014, 1955 . 1957 [RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for 1958 IPv6 Data Center Environments", RFC 7755, 1959 DOI 10.17487/RFC7755, February 2016, 1960 . 1962 [RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP 1963 Translation for IPv6 Internet Data Center Environments 1964 (SIIT-DC): Dual Translation Mode", RFC 7756, 1965 DOI 10.17487/RFC7756, February 2016, 1966 . 1968 [RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, 1969 N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, 1970 "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, 1971 DOI 10.17487/RFC7849, May 2016, 1972 . 1974 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1975 and P. Hoffman, "Specification for DNS over Transport 1976 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1977 2016, . 1979 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1980 Transport Layer Security (DTLS)", RFC 8094, 1981 DOI 10.17487/RFC8094, February 2017, 1982 . 1984 [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking 1985 Methodology for IPv6 Transition Technologies", RFC 8219, 1986 DOI 10.17487/RFC8219, August 2017, 1987 . 1989 [RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima, 1990 "Requirements for IPv6 Customer Edge Routers to Support 1991 IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 1992 2019, . 1994 [RIPE-690] 1995 RIPE, "Best Current Operational Practice for Operators: 1996 IPv6 prefix assignment for end-users - persistent vs non- 1997 persistent, and what size to choose", October 2017, 1998 . 2000 [Threat-DNS64] 2001 Lencse, G. and Y. Kadobayashi, "Methodology for the 2002 identification of potential security issues of different 2003 IPv6 transition technologies: Threat analysis of DNS64 and 2004 stateful NAT64", Computers & Security , vol. 77, no. 1, 2005 pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018. 2007 Author's Address 2009 Jordi Palet Martinez 2010 The IPv6 Company 2011 Molino de la Navata, 75 2012 La Navata - Galapagar, Madrid 28420 2013 Spain 2015 Email: jordi.palet@theipv6company.com 2016 URI: http://www.theipv6company.com/