idnits 2.17.1 draft-ietf-v6ops-nat64-deployment-02.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 (August 14, 2018) is 2082 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-07) exists of draft-huitema-quic-dnsoquic-05 == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-12 == Outdated reference: A later version (-15) exists of draft-ietf-v6ops-transition-ipv4aas-07 Summary: 1 error (**), 0 flaws (~~), 6 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 August 14, 2018 5 Expires: February 15, 2019 7 NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks 8 draft-ietf-v6ops-nat64-deployment-02 10 Abstract 12 This document describes how NAT64 and 464XLAT can be deployed in an 13 IPv6 network, whether cellular ISP, broadband ISP, or enterprise and 14 the issues to be considered when having an IPv6-only access link, 15 regarding: a) DNS64, b) applications or devices that use literal IPv4 16 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or 17 applications. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 15, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 55 3. NAT64 Deployment Scenarios . . . . . . . . . . . . . . . . . 4 56 3.1. Known to Work . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1.1. Service Provider NAT64 with DNS64 . . . . . . . . . . 5 58 3.1.2. Service Provider offering 464XLAT, with DNS64 . . . . 7 59 3.1.3. Service Provider offering 464XLAT, without DNS64 . . 10 60 3.2. Known to Work Under Special Conditions . . . . . . . . . 12 61 3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 12 62 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 13 63 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only 64 remote network . . . . . . . . . . . . . . . . . . . 14 65 3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 14 66 4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 16 67 4.1. DNSSEC Considerations and Possible Approaches . . . . . . 16 68 4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 17 69 4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 18 70 4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 18 71 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 19 72 4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 19 73 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 19 74 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 19 75 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 20 76 4.4. Manual Configuration of Foreign DNS . . . . . . . . . . . 20 77 4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 78 4.6. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 21 79 4.7. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22 80 4.8. IPv4-only Hosts or Applications . . . . . . . . . . . . . 22 81 4.9. CLAT Translation Considerations . . . . . . . . . . . . . 22 82 5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23 83 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 87 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27 88 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 31 89 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31 90 13. ANNEX D: Changes from -00 and -01 . . . . . . . . . . . . . . 31 91 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 92 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 93 14.2. Informative References . . . . . . . . . . . . . . . . . 33 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 96 1. Introduction 98 NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation 99 mechanisms, which allows IPv6-only hosts to communicate with 100 IPv4-only servers using unicast UDP, TCP or ICMP, by means of IPv4 101 public addresses sharing (assigned to the translator), among multiple 102 IPv6-only hosts. 104 The translation of the packet headers is done using the IP/ICMP 105 translation algorithm defined in [RFC7915] and algorithmically 106 translating the IPv4 addresses to IPv6 addresses following [RFC6052]. 108 DNS64 ([RFC6147]), is in charge of the synthesis of AAAA records from 109 the A records, so only works for applications making use of DNS, 110 avoiding changes in both, the IPv6-only hosts and the IPv4-only 111 server, so they can use a NAT64. As discussed in Section 5.5 of 112 [RFC6147], a security-aware and validating host has to perform the 113 DNS64 function locally. 115 However, the use of NAT64 and/or DNS64 present three issues: 117 a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is 118 designed to detect such modifications, DNS64 ([RFC6147]) can 119 potentially break DNSSEC, depending on a number of factors, such 120 as the location of the DNS64 function (at a DNS server or 121 validator, at the end host, ...), how it has been configured, if 122 the end-hosts is validating, etc. 124 b. Because the need of using DNS64 ([RFC6147]) or an alternative 125 "host/application built-in" mechanism for address synthesis, 126 there is a major issue for NAT64 ([RFC6146]), as doesn't work 127 when literal addresses or non-IPv6 compliant APIs are being used. 129 c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or 130 applications located within a network which are connected to a 131 service provider IPv6-only access, as it was designed for a very 132 specific scenario ([RFC6144], Section 2.1). 134 The same issues are true if part of, for example, an enterprise 135 network, is connected to other parts of the same network or third 136 party networks by means of IPv6-only connectivity. This applies to 137 many other similar cases. 139 According to that, across this document, the use of "operator 140 network" is interchangeable with equivalent cases of enterprise (or 141 similar) networks. 143 An analysis of stateful IPv6/IPv6 mechanisms is provided in 145 [RFC6889]. 147 This document looks into different possible NAT64 ([RFC6146]) 148 deployment scenarios, including IPv4-IPv6-IPv4 and similar ones, 149 which were not documented by [RFC6144], such as 464XLAT ([RFC6877]), 150 in operator (broadband and cellular) and enterprise networks, and 151 provides guidelines to avoid the above-mentioned issues. 153 Towards that, this document first looks into the possible NAT64 154 deployment scenarios (split in "known to work" and "known to work 155 under special conditions"), providing a quick and generic comparison 156 table among them. Then the document describes the issues that an 157 operator need to understand on different matters that will allow to 158 define what is the best approach/scenario for each specific network 159 case. A summary provides some recommendations and decision points 160 and then a clarification of the usage of this document for enterprise 161 networks is provided. Finally, an annex provides an example of a 162 broadband deployment using 464XLAT. 164 The target deployment scenarios in this document may be covered as 165 well by other IPv4-as-a-Service transition mechanisms. It is out of 166 scope of this document to provide a comparison among them. 168 [RFC7269] provides additional information about NAT64 deployment 169 options and experiences. 171 2. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 3. NAT64 Deployment Scenarios 181 Section 7 of DNS64 ([RFC6147]), provides 3 scenarios, looking at the 182 location of the DNS64. However, since the publication of that 183 document, there are new possible scenarios and NAT64 use cases that 184 need to be considered now, despite they were specifically ruled out 185 of the original NAT64/DNS64 work. 187 Consequently, the perspective in this document is to broaden those 188 scenarios, including a few new ones. However, in order to be able to 189 reduce the number of possible cases, we work under the assumption 190 that typically, the service provider wants to make sure that all the 191 customers have a service without failures. This means considering 192 the worst possible case: 194 a. There are hosts that will be validating DNSSEC. 196 b. Literal addresses and non-IPv6 compliant APIs are being used. 198 c. There are IPv4-only hosts or applications beyond the IPv6-only 199 link (e.g., tethering in cellular networks). 201 We use a common set of possible "participant entities": 203 1. An IPv6-only access network (IPv6). 205 2. An IPv4-only remote network/server/services (IPv4). 207 3. The NAT64 function (NAT64) in the service provider. 209 4. The DNS64 function (DNS64) in the service provider. 211 5. An external service provider offering the NAT64 and/or the DNS64 212 function (extNAT64/extDNS64). 214 6. 464XLAT customer side translator (CLAT). 216 We split the possible scenarios in two general categories: 218 1. Known to work. 220 2. Known to work under special conditions. 222 3.1. Known to Work 224 The scenarios in this category are known to work. Each one may have 225 different pros and cons, and in some cases the trade-offs, maybe 226 acceptable for some operators. 228 3.1.1. Service Provider NAT64 with DNS64 230 In this scenario, the service provider offers both, the NAT64 and the 231 DNS64 functions. 233 This is probably the most common scenario, however also may have the 234 implications related the DNSSEC. 236 This scenario also may fail to solve the issue of literal addresses 237 or non-IPv6 compliant APIs, as well as the issue of IPv4-only hosts 238 or applications inside the IPv6-only access network. 240 +----------+ +----------+ +----------+ 241 | | | NAT64 | | | 242 | IPv6 +--------+ + +--------+ IPv4 | 243 | | | DNS64 | | | 244 +----------+ +----------+ +----------+ 246 Figure 1: NAT64 with DNS64 248 A totally equivalent scenario will be if the service provider offers 249 only the DNS64 function, and the NAT64 function is provided by an 250 outsourcing agreement with an external provider. All the 251 considerations in the previous paragraphs of this section are the 252 same for this sub-case. 254 +----------+ 255 | | 256 | extNAT64 | 257 | | 258 +----+-----+ 259 | 260 | 261 +----------+ +----+-----+ +----------+ 262 | | | | | | 263 | IPv6 +--------+ DNS64 +--------+ IPv4 | 264 | | | | | | 265 +----------+ +----------+ +----------+ 267 Figure 2: NAT64 in external service provider 269 As well, is equivalent to the scenario where the outsourcing 270 agreement with the external provider is to provide both the NAT64 and 271 DNS64 functions. Once more, all the considerations in the previous 272 paragraphs of this section are the same for this sub-case. 274 +----------+ 275 | extNAT64 | 276 | + | 277 | extDNS64 | 278 +----+-----+ 279 | 280 +----------+ | +----------+ 281 | | | | | 282 | IPv6 +-------------+--------------+ IPv4 | 283 | | | | 284 +----------+ +----------+ 286 Figure 3: NAT64 and DNS64 in external provider 288 One more equivalent scenario will be if the service provider offers 289 the NAT64 only, and the DNS64 function is from an external provider 290 with or without a specific agreement among them. This is a scenario 291 already feasible today, as several "global" service providers provide 292 free DNS64 services and users often configure manually their DNS. 293 This will only work if both the NAT64 and the DNS64 are using the WKP 294 (Well-Known Prefix) or the same NSP (Network-Specific Prefix). All 295 the considerations in the previous paragraphs of this section are the 296 same for this sub-case. 298 Of course, if the external DNS64 is agreed with the service provider, 299 then we are in the same case as in the previous ones already depicted 300 in this scenario. 302 +----------+ 303 | | 304 | extDNS64 | 305 | | 306 +----+-----+ 307 | 308 | 309 +----------+ +----+-----+ +----------+ 310 | | | | | | 311 | IPv6 +--------+ NAT64 +--------+ IPv4 | 312 | | | | | | 313 +----------+ +----------+ +----------+ 315 Figure 4: NAT64; DNS64 by external provider 317 3.1.2. Service Provider offering 464XLAT, with DNS64 319 464XLAT ([RFC6877]) describes an architecture that provides IPv4 320 connectivity across a network, or part of it, when it is only 321 natively transporting IPv6. 323 In order to do that, 464XLAT ([RFC6877]) relies on the combination of 324 existing protocols: 326 1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6 327 translator (NAT46) ([RFC7915]) implemented in the end-user device 328 or CE, located at the "customer" edge of the network. 330 2. The provider-side translator (PLAT) is a stateful NAT64 331 ([RFC6146]), implemented typically at in the operator network. 333 3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a 334 single translation at the NAT64, instead of two translations 335 (NAT46+NAT64), when the application at the end-user device 336 supports IPv6 DNS (uses AAAA RR). 338 Note that even in the 464XLAT ([RFC6877]) terminology, the provider- 339 side translator is referred as PLAT, for simplicity and uniformity, 340 in this document is always referred as NAT64. 342 In this scenario the service provider deploys 464XLAT with DNS64. 344 As a consequence, the DNSSEC issues remain, unless the if the host is 345 doing the address synthesis. 347 464XLAT ([RFC6877]) is a very simple approach to cope with the major 348 NAT64+DNS64 drawback: Not working with applications or devices that 349 use literal IPv4 addresses or non-IPv6 compliant APIs. 351 464XLAT ([RFC6877]) has been used initially in IPv6-only cellular 352 networks. By supporting CLAT, the end-user device applications can 353 access IPv4-only end-networks/applications, despite those 354 applications or devices use literal IPv4 addresses or non-IPv6 355 compliant APIs. It is also used for tethering purposes. 357 In addition to that, in the same example of the cellular network 358 above, if the User Equipment (UE) provides tethering, other devices 359 behind it will be presented with a traditional NAT44, in addition to 360 the native IPv6 support, so clearly it allows IPv4-only hosts inside 361 the IPv6-only access network. 363 Furthermore, as indicated in [RFC6877], 464XLAT can be used in 364 broadband IPv6 network architectures, by implementing the CLAT 365 functionality at the CE. 367 In order to understand all the communication possibilities, let's 368 assume the following representation of two dual-stack peers: 370 +-------+ .-----. .-----. 371 | | / \ / \ 372 .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ 373 / Local \ | SOHO +--( only )---( NAT64 )---( only ) 374 / \ | | \ Internet/\ `-----' \ Internet/ 375 ( Dual- )--+ IPv6 | \ / \ / \ / 376 \ Stack / | CE | `--+--' \ .-----. / `--+--' 377 \ Peer / | with | | \ / Remote\/ | 378 `-----' | CLAT | +---+----+ / \ +---+----+ 379 | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| 380 +-------+ | with | \ Stack / +--------+ 381 | DNS64 | \ Peer / 382 +--------+ `-----' 384 Representation of 464XLAT among two peers with DNS64 386 The possible communication paths, among the IPv4/IPv6 stacks of both 387 peers, in this case, are: 389 a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among 390 peers. 392 b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. 394 c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that 395 services are deployed in Internet using IPv6-only, unless there 396 is certainty that peers will also be IPv6-capable. 398 d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 399 translations. 401 The following figures show different choices for placing the 402 different elements. 404 +----------+ +----------+ +----------+ 405 | IPv6 | | NAT64 | | | 406 | + +--------+ + +--------+ IPv4 | 407 | CLAT | | DNS64 | | | 408 +----------+ +----------+ +----------+ 410 Figure 5: 464XLAT with DNS64 412 An equivalent scenario will be if the service provider offers only 413 the DNS64 function, and the NAT64 function is provided by an 414 outsourcing agreement with an external provider. All the 415 considerations in the previous paragraphs of this section are the 416 same for this sub-case. 418 +----------+ 419 | | 420 | extNAT64 | 421 | | 422 +----+-----+ 423 | 424 | 425 +----------+ +----+-----+ +----------+ 426 | IPv6 | | | | | 427 | + +--------+ DNS64 +--------+ IPv4 | 428 | CLAT | | | | | 429 +----------+ +----------+ +----------+ 431 Figure 6: 464XLAT with DNS64; NAT64 in external provider 433 As well, is equivalent to the scenario where the outsourcing 434 agreement with the external provider is to provide both the NAT64 and 435 DNS64 functions. Once more, all the considerations in the previous 436 paragraphs of this section are the same for this sub-case. 438 +----------+ 439 | extNAT64 | 440 | + | 441 | extDNS64 | 442 +----+-----+ 443 | 444 +----------+ | +----------+ 445 | IPv6 | | | | 446 | + +-------------+--------------+ IPv4 | 447 | CLAT | | | 448 +----------+ +----------+ 450 Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider 452 3.1.3. Service Provider offering 464XLAT, without DNS64 454 The major advantage of this scenario, using 464XLAT without DNS64, is 455 that the service provider ensures that DNSSEC is never broken, even 456 in case the user modifies the DNS configuration. 458 In this scenario, as in the previous one, there are no issues related 459 to IPv4-only hosts inside the IPv6-only access network, neither to 460 the usage of IPv4 literals or non-IPv6 compliant APIs. 462 Let's assume the representation of two dual-stack peers as in the 463 previous case: 465 +-------+ .-----. .-----. 466 | | / \ / \ 467 .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ 468 / Local \ | SOHO +--( only )---( NAT64 )---( only ) 469 / \ | | \ Internet/\ `-----' \ Internet/ 470 ( Dual- )--+ IPv6 | \ / \ / \ / 471 \ Stack / | CE | `--+--' \ .-----. / `--+--' 472 \ Peer / | with | | \ / Remote\/ | 473 `-----' | CLAT | +---+----+ / \ +---+----+ 474 | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| 475 +-------+ +--------+ \ Stack / +--------+ 476 \ Peer / 477 `-----' 479 Representation of 464XLAT among two peers without DNS64 481 The possible communication paths, among the IPv4/IPv6 stacks of both 482 peers, in this case, are: 484 a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among 485 peers. 487 b. Local-IPv6 to Remote-IPv4: Because there is no DNS64, will fall- 488 back to d. below. 490 c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that 491 services are deployed in Internet using IPv6-only, unless there 492 is certainty that peers will also be IPv6-capable. 494 d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 495 translations. 497 It needs to be noticed that this scenario works while the local 498 hosts/applications are dual-stack (which is the current situation), 499 because the connectivity from a local-IPv6 to a remote-IPv4 is not 500 possible without an AAAA synthesis. This aspect is important only 501 when in the LANs behind the CLAT there are IPv6-only hosts and they 502 need to communicate with remote IPv4-only hosts. However, doesn't 503 look a sensible approach from an Operating System or application 504 vendor perspective, to provide IPv6-only support unless, similarly to 505 c. above, there is certainty of peers supporting IPv6 as well. 507 The following figures show different choices for placing the 508 different elements. 510 +----------+ +----------+ +----------+ 511 | IPv6 | | | | | 512 | + +--------+ NAT64 +--------+ IPv4 | 513 | CLAT | | | | | 514 +----------+ +----------+ +----------+ 516 Figure 8: 464XLAT without DNS64 518 This is equivalent to the scenario where there is an outsourcing 519 agreement with an external provider for the NAT64 function. All the 520 considerations in the previous paragraphs of this section are the 521 same for this sub-case. 523 +----------+ 524 | | 525 | extNAT64 | 526 | | 527 +----+-----+ 528 | 529 +----------+ | +----------+ 530 | IPv6 | | | | 531 | + +-------------+--------------+ IPv4 | 532 | CLAT | | | 533 +----------+ +----------+ 535 Figure 9: 464XLAT without DNS64; NAT64 in external provider 537 3.2. Known to Work Under Special Conditions 539 The scenarios in this category are known to not work unless 540 significant effort is devoted to solve the issues, or are intended to 541 solve problems across "closed" networks, instead of as a general 542 Internet access usage. In addition to the different pros, cons and 543 trade-offs, which may be acceptable for some operators, they have 544 implementation difficulties, as they are beyond the original 545 expectations of the NAT64/DNS64 original intent. 547 3.2.1. Service Provider NAT64 without DNS64 549 In this scenario, the service provider offers a NAT64, however there 550 is no DNS64 function support. 552 As a consequence, an IPv6 host in the IPv6-only access network, will 553 not be able to detect the presence of DNS64 by means of [RFC7050], 554 neither learning the IPv6 prefix to be used for the NAT64. 556 This can be sorted out as indicated in Section 4.1.1. 558 However, despite that, because the lack of the DNS64 function, the 559 IPv6 host will not be able to obtain AAAA synthesized records, so the 560 NAT64 becomes useless. 562 An exception to this "useless" scenario will be manually configure 563 mappings between the A records of each of the IPv4-only remote hosts 564 and the corresponding AAAA records, with the WKP (Well-Known Prefix) 565 or NSP (Network-Specific Prefix) used by the service provider NAT64, 566 as if they were synthesized by a DNS64. 568 This mapping could be done by several means, typically at the 569 authoritative DNS server, or at the service provider resolvers by 570 means of DNS RPZ (Response Policy Zones). The latest, may have 571 implications in DNSSEC, if the zone is signed. Also, if the service 572 provider is using a NSP, having the mapping at the authoritative 573 server, will mean that may create troubles to other parties trying to 574 use different NSP or the WKP, unless multiple DNS "views" are also 575 being used at the authoritative servers. 577 Generally, the mappings alternative, will only make sense if a few 578 set of IPv4-only remote hosts need to be accessed by a single network 579 or reduced set of them, which support IPv6-only in the access, with 580 some kind of mutual agreement for using this procedure, so it doesn't 581 care if they become a trouble for other parties across Internet 582 ("closed services"). 584 In any case, this scenario doesn't solve the issue of literal 585 addresses or non-IPv6 compliant APIs, neither it solves the problem 586 of IPv4-only hosts within that IPv6-only access network. 588 +----------+ +----------+ +----------+ 589 | | | | | | 590 | IPv6 +--------+ NAT64 +--------+ IPv4 | 591 | | | | | | 592 +----------+ +----------+ +----------+ 594 Figure 10: NAT64 without DNS64 596 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts 598 In this scenario, the service provider offers the NAT64, but not the 599 DNS64. However, the IPv6 hosts have a built-in DNS64 function. 601 This may become common if the DNS64 function is implemented in all 602 the IPv6 hosts/stacks, which is not the actual situation. At this 603 way, the DNSSEC validation is performed on the A record, and then the 604 host can use the DNS64 function so to be able to use the NAT64, 605 without any DNSSEC issues. 607 This scenario fails to solve the issue of literal addresses or non- 608 IPv6 compliant APIs, unless the IPv6 hosts also supports Happy 609 Eyeballs v2 ([RFC8305], Section 7.1), which may solve that issue. 611 However, this scenario still fails to solve the problem of IPv4-only 612 hosts or applications inside the IPv6-only access network. 614 +----------+ +----------+ +----------+ 615 | IPv6 | | | | | 616 | + +--------+ NAT64 +--------+ IPv4 | 617 | DNS64 | | | | | 618 +----------+ +----------+ +----------+ 620 Figure 11: NAT64; DNS64 in IPv6 hosts 622 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network 624 In this scenario, the service provider offers the NAT64 only. The 625 remote IPv4-only network offers the DNS64 function. 627 This is not common, and looks like doesn't make too much sense that a 628 remote network, not deploying IPv6, is providing a DNS64 function and 629 as in the case of the scenario depicted in Section 3.2.1, it will 630 only work if both sides are using the WKP or the same NSP so, the 631 same considerations apply. It can be also tuned to behave as in 632 Section 3.1.1 634 This scenario still fails to solve the issue of literal addresses or 635 non-IPv6 compliant APIs. 637 This scenario also fails to solve the problem of IPv4-only hosts or 638 applications inside the IPv6-only access network. 640 +----------+ +----------+ +----------+ 641 | | | | | IPv4 | 642 | IPv6 +--------+ NAT64 +--------+ + | 643 | | | | | DNS64 | 644 +----------+ +----------+ +----------+ 646 Figure 12: NAT64; DNS64 in the IPv4-only 648 3.3. Comparing the Scenarios 650 This section compares the different scenarios, including the possible 651 variations (each one represented in the precedent sections by a 652 different figure), looking at the following parameters: 654 a. DNSSEC: Are there host validating DNSSEC? 655 b. Literal/APIs: Are there applications using literals or non-IPv6 656 compliant APIs? 658 c. IPv4-only: Are there hosts or applications using IPv4-only? 660 d. Foreign DNS: Is the scenario surviving if the user changes the 661 DNS? Note that this apply similarly to split DNS, DNS in VPNs 662 and DNS privacy. 664 In the next table, the columns represent each of the scenario from 665 the previous sections, by the Figure number. The possible values 666 are: 668 - Scenario "bad" for that item. 670 + Scenario "good" for that item. 672 Needs to be noted that in some cases "countermeasures", alternative 673 or special configurations, may be available for the items designated 674 as "bad", so this comparison is making a generic case, as a quick 675 comparison guide. In some cases, a "bad" item is not necessarily a 676 negative aspect, all it depends on the specific needs/characteristics 677 of the network where the deployment will take place. For instance, 678 in a network which has only IPv6-only hosts and apps using only DNS 679 and IPv6-compliant APIs, there is no impact using only NAT64 and 680 DNS64, but if the hosts may validate DNSSEC, that item is still 681 relevant. 683 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 684 | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 685 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 686 | DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + | 687 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 688 | Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - | 689 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 690 | IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - | 691 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 692 | Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - | 693 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 695 Figure 13: Scenario Comparison 697 As a general conclusion, we should note that if the network must 698 support applications using literals, non-IPv6-compliant APIs, or 699 IPv4-only hosts or applications, only the scenarios with 464XLAT, or 700 equivalent built-in local address synthesis features, will provide a 701 solution. Further to that, those scenarios will also keep working if 702 the user changes the DNS setup. Clearly also, depending on if DNS64 703 is used or not, DNSSEC may be broken for those hosts doing DNSSEC 704 validation. 706 4. Issues to be Considered 708 This section reviews the different issues that an operator needs to 709 consider towards a NAT64/464XLAT deployment, as they may bring to 710 decision points about how to approach that deployment. 712 4.1. DNSSEC Considerations and Possible Approaches 714 As indicated in Section 8 of [RFC6147] (DNS64, Security 715 Considerations), because DNS64 modifies DNS answers and DNSSEC is 716 designed to detect such modifications, DNS64 can break DNSSEC. 718 If a device connected to an IPv6-only WAN queries for a domain name 719 in a signed zone, by means of a recursive name server that supports 720 DNS64, and the result is a synthesized AAAA record, and the recursive 721 name server is configured to perform DNSSEC validation and has a 722 valid chain of trust to the zone in question, it will 723 cryptographically validate the negative response from the 724 authoritative name server. This is the expected DNS64 behavior: The 725 recursive name server actually lies to the client device. However, 726 in most of the cases, the client will not notice it, because 727 generally, they don't perform validation themselves and instead, rely 728 on the recursive name servers. 730 A validating DNS64 resolver in fact, increase the confidence on the 731 synthetic AAAA, as it has validated that a non-synthetic AAAA for 732 sure, doesn't exists. However, if the client device is 733 NAT64-oblivious (most common case) and performs DNSSEC validation on 734 the AAAA record, it will fail as it is a synthesized record. 736 The best possible scenario from DNSSEC point of view is when the 737 client requests the DNS64 server to perform the DNSSEC validation (by 738 setting the DO bit to 1 and the CD bit to 0). In this case, the 739 DNS64 server validates the data thus tampering may only happen inside 740 the DNS64 server (which is considered as a trusted part, thus its 741 likelihood is low) or between the DNS64 server and the client. All 742 other parts of the system (including transmission and caching) are 743 protected by DNSSEC ([Threat-DNS64]). 745 Similarly, if the client querying the recursive name server is 746 another name server configured to use it as a forwarder, and is 747 performing DNSSEC validation, it will also fail on any synthesized 748 AAAA record. 750 All those considerations are extensively covered in Sections 3, 5.5 751 and 6.2 of [RFC6147]. 753 The ideal solution to avoid DNSSEC issues, will be that all the 754 signed zones also provide IPv6 connectivity, together with the 755 corresponding AAAA records, which is out of the control of the 756 operator needing to deploy NAT64. 758 An alternative solution, which was the one considered while 759 developing [RFC6147], is that validators will be DNS64-aware, so 760 could perform the necessary discovery and do their own synthesis. 761 That was done under the expectation that it was sufficiently early in 762 the validator-deployment curve that it would be ok to break certain 763 DNSSEC assumptions for networks who were really stuck in a NAT64/ 764 DNS64-needing world. 766 Previous data seems to indicate, that the figures of DNSSEC broken by 767 using DNS64 will be around 1.7% ([About-DNS64]). 769 As already indicated, the scenarios in the previous section, are in 770 fact somehow simplified, looking at the worst possible case (or 771 saying it in a different way: "trying to look for the most perfect 772 approach"), because breaking DNSSEC will not happen if the end-host 773 is not doing validation, which is the case today in 1.7% of the 774 cases. So, a decision point for the operator must depend on "do I 775 really care for that percentage of cases or can I provide alternative 776 solutions for them?". Some possible solutions may be taken, as 777 depicted in the next sections. 779 4.1.1. Not using DNS64 781 The ideal solution will be to avoid using DNS64, but as already 782 indicated this is not possible in all the scenarios. 784 However, not having a DNS64, means that is not possible to 785 heuristically discover the NAT64 ([RFC7050]) and consequently, an 786 IPv6 host in the IPv6-only access network, will not be able to detect 787 the presence of the NAT64, neither to learn the IPv6 prefix to be 788 used for it, unless it is configured by alternative means. 790 The learning of the IPv6 prefix could be solved by means of adding 791 the relevant AAAA records to the ipv4only.arpa. zone of the service 792 provider recursive servers, i.e., if using the WKP (64:ff9b::/96): 794 ipv4only.arpa. SOA . . 0 0 0 0 0 795 ipv4only.arpa. NS . 796 ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 797 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 798 ipv4only.arpa. A 192.0.0.170 799 ipv4only.arpa. A 192.0.0.171 801 An alternative option to the above, is the use of DNS RPZ (Response 802 Policy Zones). 804 One more alternative, only valid in environments with PCP support 805 (for both the hosts or CEs and for the service provider network), to 806 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). 808 Other alternatives may be available in the future, such as DHCPv6 809 options. 811 It may be convenient to support at the same time several of the 812 approaches described, in order to ensure that clients with different 813 ways to configure the NAT64 prefix, obtain it. This is also 814 convenient even if DNS64 is being used. 816 4.1.2. DNSSEC validator aware of DNS64 818 In general, DNS servers with DNS64 function, by default, will not 819 synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the 820 query. In this case, as only an A record is available, it means that 821 the CLAT will take the responsibility, as in the case of literal IPv4 822 addresses, to keep that traffic flow end-to-end as IPv4, so DNSSEC is 823 not broken. However, this will not work if a CLAT is not present as 824 the hosts will not be able to use IPv4 (scenarios without 464XLAT). 826 4.1.3. Stub validator 828 If the DO flag is set and the client device performs DNSSEC 829 validation, and the Checking Disabled (CD) flag is set for a query, 830 as the DNS64 recursive server will not synthesize AAAA responses, the 831 client could perform the DNSSEC validation with the A record and then 832 may query the network for a NAT64 prefix ([RFC7050] or [RFC7225]) in 833 order to synthesize the AAAA ([RFC6052]). This allows the client 834 device to avoid using the CLAT and still use NAT64 even with DNSSEC. 836 If the end-host is IPv4-only, this will not work if a CLAT is not 837 present (scenarios without 464XLAT) or the client is able to locally 838 do the address synthesis. 840 Some devices/OSs may implement, instead of CLAT, a similar function 841 by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy 842 Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the 843 considerations in the above paragraphs are also applicable. 845 4.1.4. CLAT with DNS proxy and validator 847 If a CE includes CLAT support and also a DNS proxy, as indicated in 848 Section 6.4 of [RFC6877], the CE could behave as a stub validator on 849 behalf of the client devices, following the same approach described 850 in the precedent section (Stub validator). So, the DNS proxy 851 actually lies to the client devices, which in most of the cases will 852 not notice it unless they perform validation themselves. Again, this 853 allow the client devices to avoid using the CLAT and still use NAT64 854 with DNSSEC. 856 Once more, this will not work without a CLAT (scenarios without 857 464XLAT). 859 4.1.5. ACL of clients 861 In cases of dual-stack clients, stub resolvers should send the AAAA 862 queries before the A ones. So, such clients, if DNS64 is enabled, 863 will never get A records, even for IPv4-only servers, and they may be 864 in the path before the NAT64 and accessible by IPv4. If DNSSEC is 865 being used for all those flows, specific addresses or prefixes can be 866 left-out the DNS64 synthesis by means of ACLs. 868 Once more, this will not work without a CLAT (scenarios without 869 464XLAT). 871 4.1.6. Mapping-out IPv4 addresses 873 If there are well-known specific IPv4 addresses or prefixes using 874 DNSSEC, they can be mapped-out of the DNS64 synthesis. 876 Even if this is not related to DNSSEC, this "mapping-out" feature is 877 actually, quite commonly used to ensure that [RFC1918] addresses (for 878 example used by LAN servers) are not synthesized to AAAA. 880 Once more, this will not work without a CLAT (scenarios without 881 464XLAT). 883 4.2. DNS64 and Reverse Mapping 885 When a client device, using a name server configured to perform 886 DNS64, tries to reverse-map a synthesized IPv6 address, the name 887 server responds with a CNAME record pointing the domain name used to 888 reverse-map the synthesized IPv6 address (the one under ip6.arpa), to 889 the domain name corresponding to the embedded IPv4 address (under in- 890 addr.arpa). 892 This is the expected behavior, so no issues to be considered 893 regarding DNS reverse mapping. 895 4.3. Using 464XLAT with/without DNS64 897 In the case the client device is IPv6-only (either because the stack 898 is IPv6-only, or because it is connected via an IPv6-only LAN) and 899 the remote server is IPv4-only (either because the stack is 900 IPv4-only, or because it is connected via an IPv4-only LAN), only 901 NAT64 combined with DNS64 will be able to provide access among both. 902 Because DNS64 is then required, DNSSEC validation will be only 903 possible if the recursive name server is validating the negative 904 response from the authoritative name server and the client is not 905 performing validation. 907 However, when the client device is dual-stack and/or connected in a 908 dual-stack LAN by means of a CLAT (or has the built-in CLAT), DNS64 909 is an option. 911 1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if 912 using literal IPv4 addresses or non-IPv6 compliant APIs) will not 913 use the CLAT, so will use the IPv6 path and only one translation 914 will be done at the NAT64. This may break DNSSEC, unless 915 measures as described in the precedent sections are taken. 917 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will 918 make use of the CLAT, so two translations are required (NAT46 at 919 the CLAT and NAT64 at the PLAT), which adds some overhead in 920 terms of the extra NAT46 translation, however avoids the AAAA 921 synthesis and consequently will never break DNSSEC. 923 Note that the extra translation, when DNS64 is not used, takes place 924 at the CLAT, which means no extra overhead for the operator, and no 925 perceptible impact for a CE in a broadband network, while it may have 926 some impact in a battery powered device. This cost for a battery 927 powered device, is possibly comparable to the cost when the device is 928 doing a local address synthesis (see Section 7.1 of [RFC8305]). 930 4.4. Manual Configuration of Foreign DNS 932 When clients, in a service provider network, use DNS servers from 933 other networks, for example manually configured by users, they may 934 support or not DNS64, so the considerations in Section 4.3 will apply 935 as well. 937 Even in the case that the external DNS supports DNS64 function, we 938 may be in the situation of providing incorrect configurations 939 parameters, for example un-matching WKP or NSP, or a case such the 940 one described in Section 3.2.3. 942 A similar situation may happen in case of split DNS scenarios, for 943 example, when using a VPN that forces all the DNS queries thru the 944 VPN, ignoring the DNS64. 946 Having a CLAT and using an external DNS without DNS64, ensures that 947 everything will work, so the CLAT must be considered as an advantage 948 against user configuration errors. 950 However, it needs to be reinforced, that if there is not a CLAT 951 (scenarios without 464XLAT), an external DNS without DNS64 support, 952 will not only guarantee that DNSSEC is broken, but also disallow any 953 access to IPv4-only networks, so will behave as in the Section 3.2.1. 955 4.5. DNS Privacy 957 If clients use mechanisms for DNS privacy, such as DNS over TLS 958 ([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS 959 ([I-D.ietf-doh-dns-over-https]) or DNS over QUIC 960 ([I-D.huitema-quic-dnsoquic]), as they may provide different results 961 to the same query, it must be expected equivalent effects as 962 described in Section 4.4. 964 4.6. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 966 [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), Section 3, 967 discusses some considerations which are useful to decide if an 968 operator should use the WKP or an NSP. 970 Taking in consideration that discussion and other issues, we can 971 summarize the possible decision points as: 973 a. The WKP MUST NOT be used to represent non-global IPv4 addresses. 974 If this is required, because the network to be translated use 975 non-global addresses then an NSP is required. 977 b. The WKP MAY appear in inter-domain routing tables, if the 978 operator provides NAT64 to peers, however special considerations 979 related to BGP filtering are then required and IPv4-embedded IPv6 980 prefixes longer than the WKP MUST NOT be advertised in BGP. An 981 NSP may be a more appropriate option in those cases. 983 c. If several NAT64s use the same prefix, packets from the same flow 984 may be routed to different NAT64s in case of routing changes. 985 This can be avoided either by using different prefixes for each 986 NAT64, or by ensuring that all the NAT64s coordinate their state. 987 Using an NSP could facilitate that. 989 d. If DNS64 is required and users may change their DNS 990 configuration, and deliberately choose an alternative DNS64, most 991 probably alternative DNS64 will use by default the WKP. If an 992 NSP is used by the NAT64, the users will not be able to use the 993 operator NAT64. 995 4.7. IPv4 literals and old APIs 997 A hosts or application using literal IPv4 addresses or older APIs, 998 behind a network with IPv6-only access, will not work unless a CLAT 999 (or equivalent function) is present. 1001 A possible alternative approach is described as part of Happy 1002 Eyeballs v2 Section 7.1 ([RFC8305]), or if not supporting HEv2, 1003 directly using Bump-in-the-Host ([RFC6535]), and then a DNS64 1004 function. 1006 Those alternatives will solve the problem for and end-hosts, however, 1007 if that end-hosts is providing "tethering" or an equivalent service 1008 to others hosts, that need to be considered as well. In other words, 1009 in a case of a cellular network, it resolves the issue for the UE 1010 itself, but may be not for hosts behind it. 1012 Otherwise, 464XLAT is the only valid approach to resolve this issue. 1014 4.8. IPv4-only Hosts or Applications 1016 An IPv4-only hosts or application behind a network with IPv6-only 1017 access, will not work unless a CLAT is present. 464XLAT is the only 1018 valid approach to resolve this issue. 1020 4.9. CLAT Translation Considerations 1022 As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if 1023 the CLAT can be configured with a dedicated /64 prefix for the NAT46 1024 translation, then it will be possible to do a more efficient 1025 stateless translation. 1027 However, if this dedicated prefix is not available, the CLAT will 1028 need to do a stateful translation, for example performing stateful 1029 NAT44 for all the IPv4 LAN packets, so they appear as coming from a 1030 single IPv4 address, and then in turn, stateless translated to a 1031 single IPv6 address. 1033 One possible setup, in order to maximize the CLAT performance, is to 1034 configure the dedicated translation prefix. This can be easily 1035 achieved automatically, if the broadband CE or end-user device is 1036 able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]) so, 1037 the CE can use a /64 for that. This is also possible when broadband 1038 is provided by a cellular access. 1040 The above recommendation is often not possible for cellular networks, 1041 when connecting smartphones (as UEs), as they don't use DHCPv6-PD 1042 ([RFC3633]) an instead a single /64 is provided for each PDP context 1043 and use /64 prefix sharing ([RFC6877]). So, in this case, the UEs 1044 typically have a build-in CLAT client, which is doing a stateful 1045 NAT44 before the stateless NAT46. 1047 5. Summary of Deployment Recommendations for NAT64 1049 It can be argued that none of the possible transition mechanisms is 1050 perfect, and somehow, we may consider that actually this is a good 1051 thing as a way to push for the IPv6 deployment, or otherwise, it may 1052 be further delayed, with clear undesirable effects for the global 1053 Internet. 1055 However, for an operator, being in business means minimizing the 1056 adverse transition effects, and provide the most perfect one 1057 reasonably balanced with cost (CAPEX/OPEX), and at the same time 1058 looking for a valid long-term vision. 1060 NAT64/464XLAT has demonstrated to be a valid choice in several 1061 scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions 1062 of users, offering different choices of deployment, depending on each 1063 network case, needs and requirements. 1065 Depending on those requirements, DNS64 may be a required function, 1066 while in other cases the adverse effects may be counterproductive. 1067 Similarly, in some cases NAT64, together with DNS64, may be a valid 1068 solution, when for sure there is no need to support hosts or 1069 applications which are IPv4-only (Section 4.7 and Section 4.8). 1070 However, in other cases the limitations they have, may suggest the 1071 operator to look into 464XLAT as a more complete solution. 1073 Service providers willing to deploy NAT64, need to take into account 1074 the considerations of this document in order to better decide what is 1075 more appropriate for their own specific case. 1077 In the case of broadband managed networks (CE provided or suggested/ 1078 supported by the operator), in order to fully support the actual user 1079 needs (IPv4-only devices and applications, usage of literals and old 1080 APIs), they should consider the 464XLAT scenario and in that case, 1081 must support the customer-side translator (CLAT). 1083 If the operator offers DNS services, in order to increase performance 1084 by reducing the double translation for all the IPv4 traffic, they may 1085 support DNS64 and avoid, as much as possible, breaking DNSSEC. In 1086 this case, if the DNS service is offering DNSSEC validation, then it 1087 must be in such way that it is aware of the DNS64. This is 1088 considered the simpler and safer approach, and may be combined as 1089 well with the other possible recommendations described in this 1090 document: 1092 o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). 1094 o Devices running CLAT SHOULD follow the indications in 1095 Section 4.1.3 (Stub validator). However, this may be out of the 1096 control of the operator. 1098 o CEs SHOULD include a DNS proxy and validator (Section 4.1.4). 1100 o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4 1101 addresses) MAY be considered by each operator, depending on their 1102 own infrastructure. 1104 This "increased performance" approach has the disadvantage of 1105 potentially breaking DNSSEC for a small percentage of validating end- 1106 hosts versus the small impact of a double translation taking place in 1107 the CE. If CE performance is not an issue, which is the most 1108 frequent case, then a much safer approach is to not use DNS64 at all, 1109 and consequently, ensure that all the IPv4 traffic is translated at 1110 the CLAT (Section 4.3). 1112 If DNS64 is not used, at least one of the alternatives described in 1113 Section 4.1.1, must be followed. 1115 The operator need to consider that if the user can modify the DNS 1116 configuration (which most probably is impossible to avoid), and 1117 instead of configuring a DNS64 choose an external regular DNS (non- 1118 DNS64), a scenario with only NAT64 will not work with any IPv4-only 1119 remote host, while it will continue working in the case of 464XLAT 1120 (Section 4.4). Same effects are to be expected if DNS privacy 1121 protocols are being used by customers (Section 4.5). 1123 Similar considerations need to be taken regarding the usage of a 1124 NAT64 Well-Known vs Network-Specific Prefix (Section 4.6), in the 1125 sense of, if using DNS64, they must match and if the user can change 1126 the DNS configuration, they will, most probably, not. 1128 In broadband networks, it is recommended that CEs supporting CLAT, 1129 support DHCPv6-PD ([RFC3633]) and internally reserve one /64 for the 1130 stateless NAT46 translation. The operator must ensure that the 1131 customers get allocated prefixes shorter than /64 in order to support 1132 this optimization. One way or the other, this is not impacting the 1133 performance of the operator network. 1135 As indicated in Section 7 of [RFC6877] (Deployment Considerations), 1136 operators may follow those suggestions in order to take advantage of 1137 traffic engineering requirements. 1139 In the case of cellular networks, the considerations regarding DNSSEC 1140 may appear as out-of-scope, because UEs OSs, commonly don't support 1141 DNSSEC, however applications running on them may do, or it may be an 1142 OS "built-in" support in the future. Moreover, if those devices 1143 offer tethering, other client devices may be doing the validation, 1144 hence the relevance of a proper DNSSEC support by the operator 1145 network. 1147 Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and 1148 "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" 1149 ([RFC7050]), allow a progressive IPv6 deployment, with a single APN 1150 supporting all types of PDP context (IPv4, IPv6, IPv4v6), in such way 1151 that the network is able to automatically serve all the possible 1152 combinations of UEs. 1154 One last consideration is that many networks may have different 1155 scenarios at the same time, for example, customers requiring 464XLAT, 1156 others not requiring it, customers requiring DNS64, others not, etc. 1157 In general, the different issues and approaches described in this 1158 document can be implemented at the same time for different customers 1159 or parts of the network, so not representing any problem for complex 1160 cases. 1162 Finally, if the operator chooses to provide validation for the DNS64 1163 prefix discovery, it must follow the advice from Section 3.1. of 1164 [RFC7050] (Validation of Discovered Pref64::/n). 1166 6. Deployment of NAT64 in Enterprise Networks 1168 The recommendations of this document can be used as well in 1169 enterprise networks, campus and other similar scenarios, when the 1170 NAT64 (and/or DNS64) are under the control of that network, and for 1171 whatever reasons, there is a need to provide "IPv6-only access" to 1172 any part of that network or it is IPv6-only connected to third party 1173 networks. 1175 An example of that is the IETF meetings network itself, where a NAT64 1176 and DNS64 are provided, presenting in this case the same issues as 1177 per Section 3.1.1. If there is a CLAT in the IETF network, then 1178 there is no need to use DNS64 and it falls under the considerations 1179 of Section 3.1.3. Both scenarios have been tested and verified 1180 already in the IETF network itself. 1182 Next figures are only meant to represent a few of the possible 1183 scenarios, not pretending to be the only ones that are feasible. 1185 The following figure provides an example of and IPv6-only enterprise 1186 network connected with dual-stack to Internet and using local NAT64 1187 and DNS64. 1189 +----------------------------------+ 1190 | Enterprise Network | 1191 | +----------+ +----------+ | +----------+ 1192 | | IPv6 | | NAT64 | | | IPv4 | 1193 | | only +--------+ + | +-------+ + | 1194 | | LANs | | DNS64 | | | IPv6 | 1195 | +----------+ +----------+ | +----------+ 1196 +----------------------------------+ 1198 Figure 14: IPv6-only enterprise with NAT64 and DNS64 1200 The following figure provides an example of dual-stack enterprise 1201 network connected with dual-stack to Internet and using CLAT without 1202 DNS64. 1204 +----------------------------------+ 1205 | Enterprise Network | 1206 | +----------+ +----------+ | +----------+ 1207 | | IPv6 | | | | | IPv4 | 1208 | | + +--------+ NAT64 | +-------+ + | 1209 | | CLAT | | | | | IPv6 | 1210 | +----------+ +----------+ | +----------+ 1211 +----------------------------------+ 1213 Figure 15: Dual-stack enterprise with CLAT without DNS64 1215 Finally, the following figure provides an example of an IPv6-only 1216 provider with NAT64, and a dual-stack enterprise network by means of 1217 their own CLAT without DNS64. 1219 +----------------------------------+ 1220 | Enterprise Network | 1221 | +----------+ +----------+ | +----------+ 1222 | | IPv6 | | | | IPv6 | | 1223 | | + +--------+ CLAT | +--------+ NAT64 | 1224 | | IPv4 | | | | only | | 1225 | +----------+ +----------+ | +----------+ 1226 +----------------------------------+ 1228 Figure 16: Dual-stack enterprise with CLAT without DNS64 1230 7. Security Considerations 1232 This document does not have any new specific security considerations. 1234 8. IANA Considerations 1236 This document does not have any new specific IANA considerations. 1238 Note: This section is assuming that https://www.rfc- 1239 editor.org/errata/eid5152 is resolved, otherwise, this section may 1240 include the required text to resolve the issue. 1242 9. Acknowledgements 1244 The author would like to acknowledge the inputs of Gabor Lencse, 1245 Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed 1246 Boucadair and TBD ... 1248 Conversations with Marcelo Bagnulo, one of the co-authors of NAT64 1249 and DNS64, as well as several emails in mailing lists from Mark 1250 Andrews, have been very useful for this work. 1252 Christian Huitema inspired working in this document by suggesting 1253 that DNS64 should never be used, during a discussion regarding the 1254 deployment of CLAT in the IETF network. 1256 10. ANNEX A: Example of Broadband Deployment with 464XLAT 1258 This section summarizes how an operator may deploy an IPv6-only 1259 network for residential/SOHO customers, supporting IPv6 inbound 1260 connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT. 1262 Note that an equivalent setup could also be provided for enterprise 1263 customers. In case they need IPv4 inbound connections, several 1264 mechanisms, depending on specific customer needs, allow that. 1266 Conceptually, most of the operator network could be IPv6-only 1267 (represented in the next pictures as "IPv6-only Internet"). This 1268 part of the network connects the IPv6-only subscribers (by means of 1269 IPv6-only access links), to the IPv6 upstream providers, as well as 1270 to the IPv4-Internet by means of the NAT64 (PLAT in the 464XLAT 1271 terminology). 1273 The traffic flow from and back to the CE to services available in the 1274 IPv6 Internet (or even dual-stack remote services, when IPv6 is being 1275 used), is purely native IPv6 traffic, so no special considerations 1276 about it. 1278 Looking at the picture from the DNS perspective, there are remote 1279 networks with are IPv4-only, and typically will have only IPv4 DNS 1280 (DNS/IPv4), or at least will be seen as that from the CE perspective. 1281 At the operator side, the DNS, as seen from the CE, is only IPv6 1282 (DNS/IPv6) and has also a DNS64 function. 1284 In the customer LANs side, there is actually one network, which of 1285 course could be split in different segments, and the most common 1286 setup will be those segments being dual-stack (global IPv6 addresses 1287 and [RFC1918] for IPv4, as usual in any regular residential/SOHO IPv4 1288 network today). In the figure it is represented as tree segments, 1289 just to show that the three possible setups are valid (IPv6-only, 1290 IPv4-only and dual-stack). 1292 .-----. +-------+ .-----. .-----. 1293 / IPv6- \ | | / \ / \ 1294 ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ 1295 \ LANs / | SOHO +--( only )--( NAT64 )--( only ) 1296 `-----' | | \ Internet/ `-----' \ Internet/ 1297 .-----. | IPv6 | \ / \ / 1298 / IPv4- \ | CE | `--+--' `--+--' 1299 ( only )--+ with | | | 1300 \ LANs / | CLAT | +---+----+ +---+----+ 1301 `-----' | | |DNS/IPv6| |DNS/IPv4| 1302 .-----. +---+---+ | with | +--------+ 1303 / Dual- \ | | DNS64 | 1304 ( Stack )------| +--------+ 1305 \ LANs / 1306 `-----' 1308 Figure 17: CE setup with built-in CLAT with DNS64 1310 In addition to the regular CE setup, which will be typically access- 1311 technology dependent, the steps for the CLAT configuration can be 1312 summarized as: 1314 1. Discovery of the PLAT (NAT64) prefix: It may be done using 1316 [RFC7050], or in those networks where PCP is supported, by means 1317 of [RFC7225], or other alternatives that may be available in the 1318 future (such as DHCPv6 options). 1320 2. If the CLAT allows stateless NAT46 translation, a /64 from the 1321 pool typically provided to the CE by means of DHCPv6-PD 1322 [RFC3633], need to be set aside for that translation. Otherwise, 1323 the CLAT is forced to perform an intermediate stateful NAT44 1324 before the a stateless NAT46, as described in Section 4.9. 1326 The operator network need to ensure that the correct responses are 1327 provided for the discovery of the PLAT prefix, as well as it is 1328 highly recommended follows [RIPE-690], in order to ensure that 1329 multiple /64s are available including the one needed for the NAT46 1330 translation. 1332 The operator need to understand other issues, described across this 1333 document, in order to take the relevant decisions. For example, if 1334 several NAT64 are needed in the context of scalability/high- 1335 availability, an NSP should be considered (Section 4.6). 1337 More complex scenarios are possible, for example, if a network offers 1338 multiple NAT64 prefixes, destination-based NAT64 prefixes, etc. 1340 If the operator decides not to provide DNS64, then this setup turns 1341 into the one in the following Figure. This will be also the setup 1342 that, if the user has changed the DNS and consequently is not using 1343 the operator DNS64, it will be seen from the perspective of the CE. 1345 .-----. +-------+ .-----. .-----. 1346 / IPv6- \ | | / \ / \ 1347 ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ 1348 \ LANs / | SOHO +--( only )--( NAT64 )--( only ) 1349 `-----' | | \ Internet/ `-----' \ Internet/ 1350 .-----. | IPv6 | \ / \ / 1351 / IPv4- \ | CE | `--+--' `--+--' 1352 ( only )--+ with | | | 1353 \ LANs / | CLAT | +---+----+ +---+----+ 1354 `-----' | | |DNS/IPv6| |DNS/IPv4| 1355 .-----. +---+---+ +--------+ +--------+ 1356 / Dual- \ | 1357 ( Stack )------| 1358 \ LANs / 1359 `-----' 1361 Figure 18: CE setup with built-in CLAT without DNS64 1363 In this case the discovery of te PLAT prefix need to be arranged as 1364 indicated in Section 4.1.1. 1366 In this case the CE doesn't have a built-in CLAT, or the customer can 1367 choose to setup the IPv6 operator-managed CE in bridge mode (and 1368 optionally use its own external router), or for example there is an 1369 access technology that requires some kind of media converter (ONT for 1370 FTTH, CableModem for DOCSIS, etc.), the complete setup will look as 1371 in the next figure. Obviously, there will be some intermediate 1372 configuration steps for the bridge, depending on the specific access 1373 technology/protocols, which should not modify the steps already 1374 described in the previous cases for the CLAT configuration. 1376 +-------+ .-----. .-----. 1377 | | / \ / \ 1378 | Res./ | / IPv6- \ .-----. / IPv4- \ 1379 | SOHO +--( only )--( NAT64 )--( only ) 1380 | | \ Internet/ `-----' \ Internet/ 1381 | IPv6 | \ / \ / 1382 | CE | `--+--' `--+--' 1383 | Bridge| | | 1384 | | +---+----+ +---+----+ 1385 | | |DNS/IPv6| |DNS/IPv4| 1386 +---+---+ +--------+ +--------+ 1387 | 1388 .-----. +---+---+ 1389 / IPv6- \ | | 1390 ( only )--+ IPv6 | 1391 \ LANs / | Router| 1392 `-----' | | 1393 .-----. | with | 1394 / IPv4- \ | CLAT | 1395 ( only )--+ | 1396 \ LANs / | | 1397 `-----' | | 1398 .-----. +---+---+ 1399 / Dual- \ | 1400 ( Stack )------| 1401 \ LANs / 1402 `-----' 1404 Figure 19: CE setup with bridged CLAT without DNS64 1406 It should be avoided that several routers (i.e., the operator 1407 provided CE and a downstream user provided router) enable 1408 simultaneously routing and/or CLAT, in order to avoid multiple NAT44 1409 and NAT46 levels, as well as ensuring the correct operation of 1410 multiple IPv6 subnets, so it is suggested to use HNCP ([RFC8375]). 1412 Note that the procedure described here for the CE setup, can be 1413 simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas]. 1415 11. ANNEX B: CLAT Implementation 1417 A CLAT CE implementation basically requires support of [RFC7915] for 1418 the NAT46 functionality, [RFC7050] for the PLAT prefix discovery 1419 (and/or [RFC7225] for PCP), and if stateless NAT46 is supported, 1420 mechanisms to ensure that multiple /64 are available, such as 1421 DHCPv6-PD [RFC3633]. 1423 There are several OpenSource implementations of CLAT, such as: 1425 Android: https://github.com/ddrown/android_external_android-clat. 1427 Linux: https://github.com/toreanderson/clatd. 1429 OpenWRT: https://github.com/openwrt- 1430 routing/packages/blob/master/nat46/files/464xlat.sh. 1432 VPP: https://git.fd.io/vpp/tree/src/plugins/nat. 1434 12. ANNEX C: Benchmarking 1436 Several documents provide references to benchmarking, for example in 1437 the case of DNS64, [DNS64-Benchm]. 1439 13. ANNEX D: Changes from -00 and -01 1441 Section to be removed for WGLC. Significant updates are: 1443 1. Text changes across all the document. 1445 14. References 1447 14.1. Normative References 1449 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1450 and E. Lear, "Address Allocation for Private Internets", 1451 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1452 . 1454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1455 Requirement Levels", BCP 14, RFC 2119, 1456 DOI 10.17487/RFC2119, March 1997, 1457 . 1459 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1460 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1461 DOI 10.17487/RFC3633, December 2003, 1462 . 1464 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1465 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1466 DOI 10.17487/RFC6052, October 2010, 1467 . 1469 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1470 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1471 April 2011, . 1473 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1474 NAT64: Network Address and Protocol Translation from IPv6 1475 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1476 April 2011, . 1478 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1479 Beijnum, "DNS64: DNS Extensions for Network Address 1480 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1481 DOI 10.17487/RFC6147, April 2011, 1482 . 1484 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 1485 Using "Bump-in-the-Host" (BIH)", RFC 6535, 1486 DOI 10.17487/RFC6535, February 2012, 1487 . 1489 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1490 Combination of Stateful and Stateless Translation", 1491 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1492 . 1494 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 1495 "Analysis of Stateful 64 Translation", RFC 6889, 1496 DOI 10.17487/RFC6889, April 2013, 1497 . 1499 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1500 the IPv6 Prefix Used for IPv6 Address Synthesis", 1501 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1502 . 1504 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 1505 Port Control Protocol (PCP)", RFC 7225, 1506 DOI 10.17487/RFC7225, May 2014, 1507 . 1509 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1510 "IP/ICMP Translation Algorithm", RFC 7915, 1511 DOI 10.17487/RFC7915, June 2016, 1512 . 1514 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1515 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1516 May 2017, . 1518 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1519 Better Connectivity Using Concurrency", RFC 8305, 1520 DOI 10.17487/RFC8305, December 2017, 1521 . 1523 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1524 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1525 . 1527 14.2. Informative References 1529 [About-DNS64] 1530 J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, 1531 . 1534 [DNS64-Benchm] 1535 G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 1536 Implementations: Theory and Practice", Computer 1537 Communications (Elsevier), vol. 127, no. 1, pp. 61-74, 1538 DOI 10.1016/j.comcom.2018.05.005, September 2018. 1540 [I-D.huitema-quic-dnsoquic] 1541 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 1542 Iyengar, "Specification of DNS over Dedicated QUIC 1543 Connections", draft-huitema-quic-dnsoquic-05 (work in 1544 progress), June 2018. 1546 [I-D.ietf-doh-dns-over-https] 1547 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1548 (DoH)", draft-ietf-doh-dns-over-https-12 (work in 1549 progress), June 2018. 1551 [I-D.ietf-v6ops-transition-ipv4aas] 1552 Palet, J., Liu, H., and M. Kawashima, "Requirements for 1553 IPv6 Customer Edge Routers to Support IPv4 Connectivity 1554 as-a-Service", draft-ietf-v6ops-transition-ipv4aas-07 1555 (work in progress), August 2018. 1557 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 1558 Deployment Options and Experience", RFC 7269, 1559 DOI 10.17487/RFC7269, June 2014, 1560 . 1562 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1563 and P. Hoffman, "Specification for DNS over Transport 1564 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1565 2016, . 1567 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1568 Transport Layer Security (DTLS)", RFC 8094, 1569 DOI 10.17487/RFC8094, February 2017, 1570 . 1572 [RIPE-690] 1573 RIPE, "Best Current Operational Practice for Operators: 1574 IPv6 prefix assignment for end-users - persistent vs non- 1575 persistent, and what size to choose", October 2017, 1576 . 1578 [Threat-DNS64] 1579 G. Lencse and Y. Kadobayashi, "Methodology for the 1580 identification of potential security issues of different 1581 IPv6 transition technologies: Threat analysis of DNS64 and 1582 stateful NAT64", Computers & Security (Elsevier), vol. 77, 1583 no. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 1584 2018. 1586 Author's Address 1588 Jordi Palet Martinez 1589 The IPv6 Company 1590 Molino de la Navata, 75 1591 La Navata - Galapagar, Madrid 28420 1592 Spain 1594 Email: jordi.palet@theipv6company.com 1595 URI: http://www.theipv6company.com/