idnits 2.17.1 draft-ietf-v6ops-nat64-deployment-04.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 (April 2, 2019) is 1848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (-04) exists of draft-palet-v6ops-464xlat-opt-cdn-caches-01 Summary: 0 errors (**), 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 April 2, 2019 5 Expires: October 4, 2019 7 NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks 8 draft-ietf-v6ops-nat64-deployment-04 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 October 4, 2019. 36 Copyright Notice 38 Copyright (c) 2019 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 . . . . . . . . . . . 21 77 4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 78 4.6. Split DNS . . . . . . . . . . . . . . . . . . . . . . . . 21 79 4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 22 80 4.8. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22 81 4.9. IPv4-only Hosts or Applications . . . . . . . . . . . . . 23 82 4.10. CLAT Translation Considerations . . . . . . . . . . . . . 23 83 4.11. EAMT Considerations . . . . . . . . . . . . . . . . . . . 23 84 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 24 85 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 27 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 89 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 29 90 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 32 91 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 33 92 13. ANNEX D: Changes from -00 to -01 . . . . . . . . . . . . . . 33 93 14. ANNEX E: Changes from -01 to -02 . . . . . . . . . . . . . . 33 94 15. ANNEX F: Changes from -02 to -03 . . . . . . . . . . . . . . 33 95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 16.1. Normative References . . . . . . . . . . . . . . . . . . 34 97 16.2. Informative References . . . . . . . . . . . . . . . . . 36 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 100 1. Introduction 102 NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation 103 mechanism, which allows IPv6-only hosts to communicate with IPv4-only 104 servers using unicast UDP, TCP or ICMP, by means of IPv4 public 105 addresses sharing (assigned to the translator), among multiple 106 IPv6-only hosts. 108 The translation of the packet headers is done using the IP/ICMP 109 translation algorithm defined in [RFC7915] and algorithmically 110 translating the IPv4 addresses to IPv6 addresses following [RFC6052]. 112 DNS64 ([RFC6147]), is in charge of the synthesis of AAAA records from 113 the A records, so only works for applications making use of DNS, 114 avoiding changes in both, the IPv6-only hosts and the IPv4-only 115 server, so they can use a NAT64. As discussed in Section 5.5 of 116 [RFC6147], a security-aware and validating host has to perform the 117 DNS64 function locally. 119 However, the use of NAT64 and/or DNS64 present three issues: 121 a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is 122 designed to detect such modifications, DNS64 ([RFC6147]) can 123 potentially break DNSSEC, depending on a number of factors, such 124 as the location of the DNS64 function (at a DNS server or 125 validator, at the end host, ...), how it has been configured, if 126 the end-hosts is validating, etc. 128 b. Because the need of using DNS64 ([RFC6147]) or an alternative 129 "host/application built-in" mechanism for address synthesis, 130 there is a major issue for NAT64 ([RFC6146]), as doesn't work 131 when literal addresses or non-IPv6 compliant APIs are being used. 133 c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or 134 applications located within a network which are connected to a 135 service provider IPv6-only access, as it was designed for a very 136 specific scenario ([RFC6144], Section 2.1). 138 The same issues are true if part of, for example, an enterprise 139 network, is connected to other parts of the same network or third 140 party networks by means of IPv6-only connectivity. This applies to 141 many other similar cases. 143 According to that, across this document, the use of "operator", 144 "operator network", "service provider", and similar ones, are 145 interchangeable with equivalent cases of enterprise networks (and 146 similar ones). This may be also the case for other "managed end-user 147 networks". 149 An analysis of stateful IPv6/IPv6 mechanisms is provided in 150 [RFC6889]. 152 This document looks into different possible NAT64 ([RFC6146]) 153 deployment scenarios, including IPv4-IPv6-IPv4 and similar ones, 154 which were not documented by [RFC6144], such as 464XLAT ([RFC6877]), 155 in operator (broadband and cellular) and enterprise networks, and 156 provides guidelines to avoid the above-mentioned issues. 158 Towards that, this document first looks into the possible NAT64 159 deployment scenarios (split in "known to work" and "known to work 160 under special conditions"), providing a quick and generic comparison 161 table among them. Then the document describes the issues that an 162 operator need to understand on different matters that will allow to 163 define what is the best approach/scenario for each specific network 164 case. A summary provides some recommendations and decision points 165 and then a clarification of the usage of this document for enterprise 166 networks is provided. Finally, an annex provides an example of a 167 broadband deployment using 464XLAT. 169 The target deployment scenarios in this document may be covered as 170 well by other IPv4-as-a-Service transition mechanisms. It is out of 171 scope of this document to provide a comparison among them. 173 [RFC7269] provides additional information about NAT64 deployment 174 options and experiences. 176 2. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 3. NAT64 Deployment Scenarios 186 Section 7 of DNS64 ([RFC6147]), provides 3 scenarios, looking at the 187 location of the DNS64. However, since the publication of that 188 document, other possible scenarios and NAT64 use cases need to be 189 considered in actual networks, despite some of them were specifically 190 ruled out of the original NAT64/DNS64 work. 192 Consequently, the perspective in this document is to broaden those 193 scenarios, including a few new ones. However, in order to be able to 194 reduce the number of possible cases, we work under the assumption 195 that typically, the service provider wants to make sure that all the 196 customers have a service without failures. This means considering 197 the worst possible case: 199 a. There are hosts that will be validating DNSSEC. 201 b. Literal addresses and non-IPv6 compliant APIs are being used. 203 c. There are IPv4-only hosts or applications beyond the IPv6-only 204 link (e.g., tethering in cellular networks). 206 The document uses a common set of possible "participant entities": 208 1. An IPv6-only access network (IPv6). 210 2. An IPv4-only remote network/server/services (IPv4). 212 3. The NAT64 function (NAT64) in the service provider. 214 4. The DNS64 function (DNS64) in the service provider. 216 5. An external service provider offering the NAT64 and/or the DNS64 217 function (extNAT64/extDNS64). 219 6. 464XLAT customer side translator (CLAT). 221 The possible scenarios are split in two general categories: 223 1. Known to work. 225 2. Known to work under special conditions. 227 3.1. Known to Work 229 The scenarios in this category are known to work. Each one may have 230 different pros and cons, and in some cases the trade-offs, maybe 231 acceptable for some operators. 233 3.1.1. Service Provider NAT64 with DNS64 235 In this scenario, the service provider offers both, the NAT64 and the 236 DNS64 functions. 238 This is probably the most common scenario, however also may have the 239 implications related the DNSSEC. 241 This scenario also may fail to solve the issue of literal addresses 242 or non-IPv6 compliant APIs, as well as the issue of IPv4-only hosts 243 or applications inside the IPv6-only access network. 245 +----------+ +----------+ +----------+ 246 | | | NAT64 | | | 247 | IPv6 +--------+ + +--------+ IPv4 | 248 | | | DNS64 | | | 249 +----------+ +----------+ +----------+ 251 Figure 1: NAT64 with DNS64 253 A totally equivalent scenario will be if the service provider offers 254 only the DNS64 function, and the NAT64 function is provided by an 255 outsourcing agreement with an external provider. All the 256 considerations in the previous paragraphs of this section are the 257 same for this sub-case. 259 +----------+ 260 | | 261 | extNAT64 | 262 | | 263 +----+-----+ 264 | 265 | 266 +----------+ +----+-----+ +----------+ 267 | | | | | | 268 | IPv6 +--------+ DNS64 +--------+ IPv4 | 269 | | | | | | 270 +----------+ +----------+ +----------+ 272 Figure 2: NAT64 in external service provider 274 As well, is equivalent to the scenario where the outsourcing 275 agreement with the external provider is to provide both the NAT64 and 276 DNS64 functions. Once more, all the considerations in the previous 277 paragraphs of this section are the same for this sub-case. 279 +----------+ 280 | extNAT64 | 281 | + | 282 | extDNS64 | 283 +----+-----+ 284 | 285 +----------+ | +----------+ 286 | | | | | 287 | IPv6 +-------------+--------------+ IPv4 | 288 | | | | 289 +----------+ +----------+ 291 Figure 3: NAT64 and DNS64 in external provider 293 One more equivalent scenario will be if the service provider offers 294 the NAT64 only, and the DNS64 function is from an external provider 295 with or without a specific agreement among them. This is a scenario 296 already common today, as several "global" service providers provide 297 free DNS/DNS64 services and users often configure manually their DNS. 298 This will only work if both the NAT64 and the DNS64 are using the WKP 299 (Well-Known Prefix) or the same NSP (Network-Specific Prefix). All 300 the considerations in the previous paragraphs of this section are the 301 same for this sub-case. 303 Of course, if the external DNS64 is agreed with the service provider, 304 then we are in the same case as in the previous ones already depicted 305 in this scenario. 307 +----------+ 308 | | 309 | extDNS64 | 310 | | 311 +----+-----+ 312 | 313 | 314 +----------+ +----+-----+ +----------+ 315 | | | | | | 316 | IPv6 +--------+ NAT64 +--------+ IPv4 | 317 | | | | | | 318 +----------+ +----------+ +----------+ 320 Figure 4: NAT64; DNS64 by external provider 322 3.1.2. Service Provider offering 464XLAT, with DNS64 324 464XLAT ([RFC6877]) describes an architecture that provides IPv4 325 connectivity across a network, or part of it, when it is only 326 natively transporting IPv6. 328 In order to do that, 464XLAT ([RFC6877]) relies on the combination of 329 existing protocols: 331 1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6 332 translator (NAT46) ([RFC7915]) implemented in the end-user device 333 or CE, located at the "customer" edge of the network. 335 2. The provider-side translator (PLAT) is a stateful NAT64 336 ([RFC6146]), implemented typically at in the operator network. 338 3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a 339 single translation at the NAT64, instead of two translations 340 (NAT46+NAT64), when the application at the end-user device 341 supports IPv6 DNS (uses AAAA RR). 343 Note that even in the 464XLAT ([RFC6877]) terminology, the provider- 344 side translator is referred as PLAT, for simplicity and uniformity, 345 in this document is always referred as NAT64. 347 In this scenario the service provider deploys 464XLAT with DNS64. 349 As a consequence, the DNSSEC issues remain, unless the host is doing 350 the address synthesis. 352 464XLAT ([RFC6877]) is a very simple approach to cope with the major 353 NAT64+DNS64 drawback: Not working with applications or devices that 354 use literal IPv4 addresses or non-IPv6 compliant APIs. 356 464XLAT ([RFC6877]) has been used initially mainly in IPv6-only 357 cellular networks. By supporting CLAT, the end-user device 358 applications can access IPv4-only end-networks/applications, despite 359 those applications or devices use literal IPv4 addresses or non-IPv6 360 compliant APIs. 362 In addition to that, in the same example of the cellular network 363 above, if the User Equipment (UE) provides tethering, other devices 364 behind it will be presented with a traditional NAT44, in addition to 365 the native IPv6 support, so clearly it allows IPv4-only hosts inside 366 the IPv6-only access network. 368 Furthermore, as indicated in [RFC6877], 464XLAT can be used in 369 broadband IPv6 network architectures, by implementing the CLAT 370 functionality at the CE. 372 In order to understand all the communication possibilities, let's 373 assume the following representation of two dual-stack peers: 375 +-------+ .-----. .-----. 376 | | / \ / \ 377 .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ 378 / Local \ | SOHO +--( only )---( NAT64 )---( only ) 379 / \ | | \ Internet/\ `-----' \ Internet/ 380 ( Dual- )--+ IPv6 | \ / \ / \ / 381 \ Stack / | CE | `--+--' \ .-----. / `--+--' 382 \ Peer / | with | | \ / Remote\/ | 383 `-----' | CLAT | +---+----+ / \ +---+----+ 384 | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| 385 +-------+ | with | \ Stack / +--------+ 386 | DNS64 | \ Peer / 387 +--------+ `-----' 389 Representation of 464XLAT among two peers with DNS64 391 The possible communication paths, among the IPv4/IPv6 stacks of both 392 peers, in this case, are: 394 a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among 395 peers. 397 b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. 399 c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that 400 services are deployed in Internet using IPv6-only, unless there 401 is certainty that peers will also be IPv6-capable. 403 d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 404 translations. 406 The following figures show different choices for placing the 407 different elements. 409 +----------+ +----------+ +----------+ 410 | IPv6 | | NAT64 | | | 411 | + +--------+ + +--------+ IPv4 | 412 | CLAT | | DNS64 | | | 413 +----------+ +----------+ +----------+ 415 Figure 5: 464XLAT with DNS64 417 An equivalent scenario will be if the service provider offers only 418 the DNS64 function, and the NAT64 function is provided by an 419 outsourcing agreement with an external provider. All the 420 considerations in the previous paragraphs of this section are the 421 same for this sub-case. 423 +----------+ 424 | | 425 | extNAT64 | 426 | | 427 +----+-----+ 428 | 429 | 430 +----------+ +----+-----+ +----------+ 431 | IPv6 | | | | | 432 | + +--------+ DNS64 +--------+ IPv4 | 433 | CLAT | | | | | 434 +----------+ +----------+ +----------+ 436 Figure 6: 464XLAT with DNS64; NAT64 in external provider 438 As well, is equivalent to the scenario where the outsourcing 439 agreement with the external provider is to provide both the NAT64 and 440 DNS64 functions. Once more, all the considerations in the previous 441 paragraphs of this section are the same for this sub-case. 443 +----------+ 444 | extNAT64 | 445 | + | 446 | extDNS64 | 447 +----+-----+ 448 | 449 +----------+ | +----------+ 450 | IPv6 | | | | 451 | + +-------------+--------------+ IPv4 | 452 | CLAT | | | 453 +----------+ +----------+ 455 Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider 457 3.1.3. Service Provider offering 464XLAT, without DNS64 459 The major advantage of this scenario, using 464XLAT without DNS64, is 460 that the service provider ensures that DNSSEC is never broken, even 461 in case the user modifies the DNS configuration. 463 In this scenario, as in the previous one, there are no issues related 464 to IPv4-only hosts (or IPv4-only applications) inside the IPv6-only 465 access network, neither to the usage of IPv4 literals or non-IPv6 466 compliant APIs. 468 Let's assume the representation of two dual-stack peers as in the 469 previous case: 471 +-------+ .-----. .-----. 472 | | / \ / \ 473 .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ 474 / Local \ | SOHO +--( only )---( NAT64 )---( only ) 475 / \ | | \ Internet/\ `-----' \ Internet/ 476 ( Dual- )--+ IPv6 | \ / \ / \ / 477 \ Stack / | CE | `--+--' \ .-----. / `--+--' 478 \ Peer / | with | | \ / Remote\/ | 479 `-----' | CLAT | +---+----+ / \ +---+----+ 480 | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| 481 +-------+ +--------+ \ Stack / +--------+ 482 \ Peer / 483 `-----' 485 Representation of 464XLAT among two peers without DNS64 487 The possible communication paths, among the IPv4/IPv6 stacks of both 488 peers, in this case, are: 490 a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among 491 peers. 493 b. Local-IPv6 to Remote-IPv4: Because there is no DNS64, will fall- 494 back to d. below. 496 c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that 497 services are deployed in Internet using IPv6-only, unless there 498 is certainty that peers will also be IPv6-capable. 500 d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 501 translations. 503 It needs to be noticed that this scenario works while the local 504 hosts/applications are dual-stack (which is the current situation), 505 because the connectivity from a local-IPv6 to a remote-IPv4 is not 506 possible without an AAAA synthesis. This aspect is important only 507 when in the LANs behind the CLAT there are IPv6-only hosts and they 508 need to communicate with remote IPv4-only hosts. However, doesn't 509 look a sensible approach from an Operating System or application 510 vendor perspective, to provide IPv6-only support unless, similarly to 511 c. above, there is certainty of peers supporting IPv6 as well. 513 The following figures show different choices for placing the 514 different elements. 516 +----------+ +----------+ +----------+ 517 | IPv6 | | | | | 518 | + +--------+ NAT64 +--------+ IPv4 | 519 | CLAT | | | | | 520 +----------+ +----------+ +----------+ 522 Figure 8: 464XLAT without DNS64 524 This is equivalent to the scenario where there is an outsourcing 525 agreement with an external provider for the NAT64 function. All the 526 considerations in the previous paragraphs of this section are the 527 same for this sub-case. 529 +----------+ 530 | | 531 | extNAT64 | 532 | | 533 +----+-----+ 534 | 535 +----------+ | +----------+ 536 | IPv6 | | | | 537 | + +-------------+--------------+ IPv4 | 538 | CLAT | | | 539 +----------+ +----------+ 541 Figure 9: 464XLAT without DNS64; NAT64 in external provider 543 3.2. Known to Work Under Special Conditions 545 The scenarios in this category are known to not work unless 546 significant effort is devoted to solve the issues, or are intended to 547 solve problems across "closed" networks, instead of as a general 548 Internet access usage. In addition to the different pros, cons and 549 trade-offs, which may be acceptable for some operators, they have 550 implementation difficulties, as they are beyond the original 551 expectations of the NAT64/DNS64 original intent. 553 3.2.1. Service Provider NAT64 without DNS64 555 In this scenario, the service provider offers a NAT64, however there 556 is no DNS64 function support. 558 As a consequence, an IPv6 host in the IPv6-only access network, will 559 not be able to detect the presence of DNS64 by means of [RFC7050], 560 neither learning the IPv6 prefix to be used for the NAT64. 562 This can be sorted out as indicated in Section 4.1.1. 564 However, despite that, because the lack of the DNS64 function, the 565 IPv6 host will not be able to obtain AAAA synthesized records, so the 566 NAT64 becomes useless. 568 An exception to this "useless" scenario will be manually configure 569 mappings between the A records of each of the IPv4-only remote hosts 570 and the corresponding AAAA records, with the WKP (Well-Known Prefix) 571 or NSP (Network-Specific Prefix) used by the service provider NAT64, 572 as if they were synthesized by a DNS64. 574 This mapping could be done by several means, typically at the 575 authoritative DNS server, or at the service provider resolvers by 576 means of DNS RPZ (Response Policy Zones). The latest, may have 577 implications in DNSSEC, if the zone is signed. Also, if the service 578 provider is using an NSP, having the mapping at the authoritative 579 server, will mean that may create troubles to other parties trying to 580 use different NSP or the WKP, unless multiple DNS "views" are also 581 being used at the authoritative servers. 583 Generally, the mappings alternative, will only make sense if a few 584 set of IPv4-only remote hosts need to be accessed by a single network 585 or reduced set of them, which support IPv6-only in the access, with 586 some kind of mutual agreement for using this procedure, so it doesn't 587 care if they become a trouble for other parties across Internet 588 ("closed services"). 590 In any case, this scenario doesn't solve the issue of literal 591 addresses or non-IPv6 compliant APIs, neither it solves the problem 592 of IPv4-only hosts within that IPv6-only access network. 594 +----------+ +----------+ +----------+ 595 | | | | | | 596 | IPv6 +--------+ NAT64 +--------+ IPv4 | 597 | | | | | | 598 +----------+ +----------+ +----------+ 600 Figure 10: NAT64 without DNS64 602 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts 604 In this scenario, the service provider offers the NAT64, but not the 605 DNS64. However, the IPv6 hosts have a built-in DNS64 function. 607 This may become common if the DNS64 function is implemented in all 608 the IPv6 hosts/stacks, which is not the actual situation. At this 609 way, the DNSSEC validation is performed on the A record, and then the 610 host can use the DNS64 function so to be able to use the NAT64, 611 without any DNSSEC issues. 613 This scenario fails to solve the issue of literal addresses or non- 614 IPv6 compliant APIs, unless the IPv6 hosts also supports Happy 615 Eyeballs v2 ([RFC8305], Section 7.1), which may solve that issue. 617 However, this scenario still fails to solve the problem of IPv4-only 618 hosts or applications inside the IPv6-only access network. 620 +----------+ +----------+ +----------+ 621 | IPv6 | | | | | 622 | + +--------+ NAT64 +--------+ IPv4 | 623 | DNS64 | | | | | 624 +----------+ +----------+ +----------+ 626 Figure 11: NAT64; DNS64 in IPv6 hosts 628 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network 630 In this scenario, the service provider offers the NAT64 only. The 631 remote IPv4-only network offers the DNS64 function. 633 This is not common, and looks like doesn't make too much sense that a 634 remote network, not deploying IPv6, is providing a DNS64 function and 635 as in the case of the scenario depicted in Section 3.2.1, it will 636 only work if both sides are using the WKP or the same NSP so, the 637 same considerations apply. It can be also tuned to behave as in 638 Section 3.1.1 640 This scenario still fails to solve the issue of literal addresses or 641 non-IPv6 compliant APIs. 643 This scenario also fails to solve the problem of IPv4-only hosts or 644 applications inside the IPv6-only access network. 646 +----------+ +----------+ +----------+ 647 | | | | | IPv4 | 648 | IPv6 +--------+ NAT64 +--------+ + | 649 | | | | | DNS64 | 650 +----------+ +----------+ +----------+ 652 Figure 12: NAT64; DNS64 in the IPv4-only 654 3.3. Comparing the Scenarios 656 This section compares the different scenarios, including the possible 657 variations (each one represented in the precedent sections by a 658 different figure), looking at the following parameters: 660 a. DNSSEC: Are there host validating DNSSEC? 661 b. Literal/APIs: Are there applications using literals or non-IPv6 662 compliant APIs? 664 c. IPv4-only: Are there hosts or applications using IPv4-only? 666 d. Foreign DNS: Is the scenario surviving if the user changes the 667 DNS? Note that this apply similarly to split DNS, DNS in VPNs 668 and DNS privacy. 670 In the next table, the columns represent each of the scenario from 671 the previous sections, by the Figure number. The possible values 672 are: 674 o - Scenario "bad" for that item. 676 o + Scenario "good" for that item. 678 Needs to be noted that in some cases "countermeasures", alternative 679 or special configurations, may be available for the items designated 680 as "bad", so this comparison is making a generic case, as a quick 681 comparison guide. In some cases, a "bad" item is not necessarily a 682 negative aspect, all it depends on the specific needs/characteristics 683 of the network where the deployment will take place. For instance, 684 in a network which has only IPv6-only hosts and apps using only DNS 685 and IPv6-compliant APIs, there is no impact using only NAT64 and 686 DNS64, but if the hosts may validate DNSSEC, that item is still 687 relevant. 689 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 690 | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 691 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 692 | DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + | 693 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 694 | Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - | 695 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 696 | IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - | 697 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 698 | Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - | 699 +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ 701 Figure 13: Scenario Comparison 703 As a general conclusion, we should note that if the network must 704 support applications using literals, non-IPv6-compliant APIs, or 705 IPv4-only hosts or applications, only the scenarios with 464XLAT, or 706 equivalent built-in local address synthesis features, will provide a 707 solution. Further to that, those scenarios will also keep working if 708 the user changes the DNS setup. Clearly also, depending on if DNS64 709 is used or not, DNSSEC may be broken for those hosts doing DNSSEC 710 validation. 712 4. Issues to be Considered 714 This section reviews the different issues that an operator needs to 715 consider towards a NAT64/464XLAT deployment, as they may bring to 716 decision points about how to approach that deployment. 718 4.1. DNSSEC Considerations and Possible Approaches 720 As indicated in Section 8 of [RFC6147] (DNS64, Security 721 Considerations), because DNS64 modifies DNS answers and DNSSEC is 722 designed to detect such modifications, DNS64 can break DNSSEC. 724 If a device connected to an IPv6-only WAN queries for a domain name 725 in a signed zone, by means of a recursive name server that supports 726 DNS64, and the result is a synthesized AAAA record, and the recursive 727 name server is configured to perform DNSSEC validation and has a 728 valid chain of trust to the zone in question, it will 729 cryptographically validate the negative response from the 730 authoritative name server. This is the expected DNS64 behavior: The 731 recursive name server actually lies to the client device. However, 732 in most of the cases, the client will not notice it, because 733 generally, they don't perform validation themselves and instead, rely 734 on the recursive name servers. 736 A validating DNS64 resolver in fact, increase the confidence on the 737 synthetic AAAA, as it has validated that a non-synthetic AAAA for 738 sure, doesn't exists. However, if the client device is 739 NAT64-oblivious (most common case) and performs DNSSEC validation on 740 the AAAA record, it will fail as it is a synthesized record. 742 The best possible scenario from DNSSEC point of view is when the 743 client requests the DNS64 server to perform the DNSSEC validation (by 744 setting the DO bit to 1 and the CD bit to 0). In this case, the 745 DNS64 server validates the data thus tampering may only happen inside 746 the DNS64 server (which is considered as a trusted part, thus its 747 likelihood is low) or between the DNS64 server and the client. All 748 other parts of the system (including transmission and caching) are 749 protected by DNSSEC ([Threat-DNS64]). 751 Similarly, if the client querying the recursive name server is 752 another name server configured to use it as a forwarder, and is 753 performing DNSSEC validation, it will also fail on any synthesized 754 AAAA record. 756 All those considerations are extensively covered in Sections 3, 5.5 757 and 6.2 of [RFC6147]. 759 The ideal solution to avoid DNSSEC issues, will be that all the 760 signed zones also provide IPv6 connectivity, together with the 761 corresponding AAAA records, which is out of the control of the 762 operator needing to deploy NAT64. This has been proposed already in 763 [I-D.bp-v6ops-ipv6-ready-dns-dnssec]. 765 An alternative solution, which was the one considered while 766 developing [RFC6147], is that validators will be DNS64-aware, so 767 could perform the necessary discovery and do their own synthesis. 768 That was done under the expectation that it was sufficiently early in 769 the validator-deployment curve that it would be ok to break certain 770 DNSSEC assumptions for networks who were really stuck in a NAT64/ 771 DNS64-needing world. 773 As already indicated, the scenarios in the previous section, are in 774 fact somehow simplified, looking at the worst possible case (or 775 saying it in a different way: "trying to look for the most perfect 776 approach"), because breaking DNSSEC will not happen if the end-host 777 is not doing validation. Previous data seems to indicate that the 778 figures of DNSSEC actually broken by using DNS64 will be around 1.7% 779 ([About-DNS64]) of the cases. So, a decision point for the operator 780 must depend on "do I really care for that percentage of cases and the 781 impact in my helpdesk or can I provide alternative solutions for 782 them?". Some possible solutions may be taken, as depicted in the 783 next sections. 785 4.1.1. Not using DNS64 787 The ideal solution will be to avoid using DNS64, but as already 788 indicated this is not possible in all the scenarios. 790 However, not having a DNS64, means that is not possible to 791 heuristically discover the NAT64 ([RFC7050]) and consequently, an 792 IPv6 host in the IPv6-only access network, will not be able to detect 793 the presence of the NAT64, neither to learn the IPv6 prefix to be 794 used for it, unless it is configured by alternative means. 796 The learning of the IPv6 prefix could be solved by means of adding 797 the relevant AAAA records to the ipv4only.arpa. zone of the service 798 provider recursive servers, i.e., if using the WKP (64:ff9b::/96): 800 ipv4only.arpa. SOA . . 0 0 0 0 0 801 ipv4only.arpa. NS . 802 ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 803 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 804 ipv4only.arpa. A 192.0.0.170 805 ipv4only.arpa. A 192.0.0.171 807 An alternative option to the above, is the use of DNS RPZ (Response 808 Policy Zones). 810 One more alternative, only valid in environments with PCP support 811 (for both the hosts or CEs and for the service provider network), to 812 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). 814 Other alternatives may be available in the future, such as Router 815 Advertising ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options. 817 It may be convenient to support at the same time several of the 818 approaches described, in order to ensure that clients with different 819 ways to configure the NAT64 prefix, successfully obtain it. This is 820 also convenient even if DNS64 is being used. 822 4.1.2. DNSSEC validator aware of DNS64 824 In general, DNS servers with DNS64 function, by default, will not 825 synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the 826 query. In this case, as only an A record is available, it means that 827 the CLAT will take the responsibility, as in the case of literal IPv4 828 addresses, to keep that traffic flow end-to-end as IPv4, so DNSSEC is 829 not broken. However, this will not work if a CLAT is not present as 830 the hosts will not be able to use IPv4 (scenarios without 464XLAT). 832 4.1.3. Stub validator 834 If the DO flag is set and the client device performs DNSSEC 835 validation, and the Checking Disabled (CD) flag is set for a query, 836 as the DNS64 recursive server will not synthesize AAAA responses, the 837 client could perform the DNSSEC validation with the A record and then 838 may query the network for a NAT64 prefix ([RFC7050], [RFC7225], 839 [I-D.ietf-6man-ra-pref64] or other methods) in order to synthesize 840 the AAAA ([RFC6052]). This allow the client device to avoid using 841 the CLAT and still use NAT64 even with DNSSEC. 843 If the end-host is IPv4-only, this will not work if a CLAT is not 844 present (scenarios without 464XLAT), unless the client is able to 845 locally perform the address synthesis. 847 Some devices/OSs may implement, instead of CLAT, a similar function 848 by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy 849 Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the 850 considerations in the above paragraphs are also applicable. 852 4.1.4. CLAT with DNS proxy and validator 854 If a CE includes CLAT support and also a DNS proxy, as indicated in 855 Section 6.4 of [RFC6877], the CE could behave as a stub validator on 856 behalf of the client devices, following the same approach described 857 in the precedent Section 4.1.3. So, the DNS proxy actually lies to 858 the client devices, which in most of the cases will not notice it 859 unless they perform validation themselves. Again, this allow the 860 client devices to avoid using the CLAT and still use NAT64 with 861 DNSSEC. 863 Once more, this will not work without a CLAT (scenarios without 864 464XLAT). 866 4.1.5. ACL of clients 868 In cases of dual-stack clients, stub resolvers should send the AAAA 869 queries before the A ones. So, such clients, if DNS64 is enabled, 870 will never get A records, even for IPv4-only servers, and they may be 871 in the path before the NAT64 and accessible by IPv4. If DNSSEC is 872 being used for all those flows, specific addresses or prefixes can be 873 left-out the DNS64 synthesis by means of ACLs. 875 Once more, this will not work without a CLAT (scenarios without 876 464XLAT). 878 4.1.6. Mapping-out IPv4 addresses 880 If there are well-known specific IPv4 addresses or prefixes using 881 DNSSEC, they can be mapped-out of the DNS64 synthesis. 883 Even if this is not related to DNSSEC, this "mapping-out" feature is 884 actually, quite commonly used to ensure that [RFC1918] addresses (for 885 example used by LAN servers) are not synthesized to AAAA. 887 Once more, this will not work without a CLAT (scenarios without 888 464XLAT). 890 4.2. DNS64 and Reverse Mapping 892 When a client device, using a name server configured to perform 893 DNS64, tries to reverse-map a synthesized IPv6 address, the name 894 server responds with a CNAME record pointing the domain name used to 895 reverse-map the synthesized IPv6 address (the one under ip6.arpa), to 896 the domain name corresponding to the embedded IPv4 address (under in- 897 addr.arpa). 899 This is the expected behavior, so no issues to be considered 900 regarding DNS reverse mapping. 902 4.3. Using 464XLAT with/without DNS64 904 In the case the client device is IPv6-only (either because the stack 905 or application is IPv6-only, or because it is connected via an 906 IPv6-only LAN) and the remote server is IPv4-only (either because the 907 stack is IPv4-only, or because it is connected via an IPv4-only LAN), 908 only NAT64 combined with DNS64 will be able to provide access among 909 both. Because DNS64 is then required, DNSSEC validation will be only 910 possible if the recursive name server is validating the negative 911 response from the authoritative name server and the client is not 912 performing validation. 914 Note that is not expected at this stage of the transition, that 915 applications or operating systems are IPv6-only, and it will not be a 916 sensible decision for a developer to work on that direction, unless 917 it is clear that the deployment scenario allows it. On the other 918 hand, an end-user or enterprise network may decide to run IPv6-only 919 in the LANs, but in case there is any chance for applications to be 920 IPv6-only, the operating system may be responsible either for doing a 921 local address synthesis, or alternatively, setting up some kind of 922 on-demand VPN (IPv4-in-IPv6), which need to be supported by that 923 network. This may become very common in enterprise networks, where 924 "Unique IPv6 Prefix per Host" [RFC8273]. 926 However, when the client device is dual-stack and/or connected in a 927 dual-stack LAN by means of a CLAT (or has the built-in CLAT), DNS64 928 is an option. 930 1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if 931 using literal IPv4 addresses or non-IPv6 compliant APIs) will not 932 use the CLAT, so will use the IPv6 path and only one translation 933 will be done at the NAT64. This may break DNSSEC, unless 934 measures as described in the precedent sections are taken. 936 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will 937 make use of the CLAT, so two translations are required (NAT46 at 938 the CLAT and NAT64 at the PLAT), which adds some overhead in 939 terms of the extra NAT46 translation, however avoids the AAAA 940 synthesis and consequently will never break DNSSEC. 942 Note that the extra translation, when DNS64 is not used, takes place 943 at the CLAT, which means no extra overhead for the operator, and no 944 perceptible impact for a CE in a broadband network, while it may have 945 some impact in a battery powered device. This cost for a battery 946 powered device, is possibly comparable to the cost when the device is 947 doing a local address synthesis (see Section 7.1 of [RFC8305]). 949 4.4. Manual Configuration of Foreign DNS 951 When clients, in a service provider network, use DNS servers from 952 other networks, for example manually configured by users, they may 953 support or not DNS64, so the considerations in Section 4.3 will apply 954 as well. 956 Even in the case that the external DNS supports DNS64 function, we 957 may be in the situation of providing incorrect configurations 958 parameters, for example un-matching WKP or NSP, or a case such the 959 one described in Section 3.2.3. 961 A similar situation may happen in case of split DNS scenarios, for 962 example, when using a VPN that forces all the DNS queries thru the 963 VPN, ignoring the DNS64. 965 Having a CLAT, even if using an external DNS without DNS64, ensures 966 that everything will work, so the CLAT must be considered as an 967 advantage against user configuration errors. 969 However, it needs to be reinforced, that if there is not a CLAT 970 (scenarios without 464XLAT), an external DNS without DNS64 support, 971 will disallow any access to IPv4-only networks, and will not 972 guarantee DNSSEC, so will behave as in the Section 3.2.1. 974 4.5. DNS Privacy 976 If clients use mechanisms for DNS privacy, such as DNS over TLS 977 ([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS 978 ([RFC8484]) or DNS over QUIC ([I-D.huitema-quic-dnsoquic]), as they 979 may provide different results to the same query, it must be expected 980 equivalent effects as described in Section 4.4. 982 4.6. Split DNS 984 As already indicated in precedent sections, the successful use of the 985 DNS64 is not guaranteed when networks or hosts can use "split-DNS" 986 (also called Split Horizon), private DNS. Section 4. of [RFC6950], 987 analyses this case. This a very common situation when using VPNs. 989 4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 991 [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), Section 3, 992 discusses some considerations which are useful to decide if an 993 operator should use the WKP or an NSP. 995 Taking in consideration that discussion and other issues, we can 996 summarize the possible decision points as: 998 a. The WKP MUST NOT be used to represent non-global IPv4 addresses. 999 If this is required, because the network to be translated use 1000 non-global addresses then an NSP is required. 1002 b. The WKP MAY appear in inter-domain routing tables, if the 1003 operator provides NAT64 to peers, however special considerations 1004 related to BGP filtering are then required and IPv4-embedded IPv6 1005 prefixes longer than the WKP MUST NOT be advertised in BGP. An 1006 NSP may be a more appropriate option in those cases. 1008 c. If several NAT64s use the same prefix, packets from the same flow 1009 may be routed to different NAT64s in case of routing changes. 1010 This can be avoided either by using different prefixes for each 1011 NAT64, or by ensuring that all the NAT64s coordinate their state. 1012 Using an NSP could facilitate that. 1014 d. If DNS64 is required and users may change their DNS 1015 configuration, and deliberately choose an alternative DNS64, most 1016 probably alternative DNS64s will use by default the WKP. In that 1017 case, if an NSP is used by the NAT64, the users will not be able 1018 to use the operator NAT64. 1020 4.8. IPv4 literals and old APIs 1022 A hosts or application using literal IPv4 addresses or older APIs, 1023 behind a network with IPv6-only access, will not work unless a CLAT 1024 (or equivalent function) is present. 1026 A possible alternative approach is described as part of Happy 1027 Eyeballs v2 Section 7.1 ([RFC8305]). When HEv2 is not supported, one 1028 more alternative is using Bump-in-the-Host ([RFC6535]), and then a 1029 DNS64 function. 1031 Those alternatives will solve the problem for and end-hosts, however, 1032 if that end-hosts is providing "tethering" or an equivalent service 1033 to others hosts, that need to be considered as well. In other words, 1034 in a case of a cellular network, it resolves the issue for the UE 1035 itself, but may be not the case for hosts behind it. 1037 Otherwise, 464XLAT is the only valid approach to resolve this issue. 1039 4.9. IPv4-only Hosts or Applications 1041 An IPv4-only hosts or application behind a network with IPv6-only 1042 access, will not work unless a CLAT is present. 464XLAT is the only 1043 valid approach to resolve this issue. 1045 4.10. CLAT Translation Considerations 1047 As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if 1048 the CLAT can be configured with a dedicated /64 prefix for the NAT46 1049 translation, then it will be possible to do a more efficient 1050 stateless translation. 1052 However, if this dedicated prefix is not available, the CLAT will 1053 need to do a stateful translation, for example performing stateful 1054 NAT44 for all the IPv4 LAN packets, so they appear as coming from a 1055 single IPv4 address, and then in turn, stateless translated to a 1056 single IPv6 address. 1058 One possible setup, in order to maximize the CLAT performance, is to 1059 configure the dedicated translation prefix. This can be easily 1060 achieved automatically, if the broadband CE or end-user device is 1061 able to obtain a shorter prefix by means of DHCPv6-PD ([RFC8415]), or 1062 other alternatives, so the CE can use a specific /64 for the 1063 translation. This is also possible when broadband is provided by a 1064 cellular access. 1066 The above recommendation is often not possible for cellular networks, 1067 when connecting smartphones (as UEs), as generally they don't use 1068 DHCPv6-PD ([RFC8415]) an instead a single /64 is provided for each 1069 PDP context and use /64 prefix sharing ([RFC6877]). So, in this 1070 case, the UEs typically have a build-in CLAT client, which is doing a 1071 stateful NAT44 before the stateless NAT46. 1073 4.11. EAMT Considerations 1075 Explicit Address Mappings for Stateless IP/ICMP Translation [RFC7757] 1076 provides a way to configure explicit mappings between IPv4 and IPv6 1077 prefixes of any length. When this is used, for example in a CLAT, it 1078 may provide a simple mechanism in order to avoid traffic flows 1079 between IPv4-only nodes or applications and dual-stack destinations 1080 to be translated twice (NAT46 and NAT64), by creating mapping entries 1081 with the GUA of the IPv6-reachable destination. This optimization of 1082 the NAT64 usage is very useful in many scenarios, including CDNs and 1083 caches, as described in [I-D.palet-v6ops-464xlat-opt-cdn-caches]. 1085 5. Summary of Deployment Recommendations for NAT64/464XLAT 1087 It can be argued that none of the possible transition mechanisms is 1088 perfect, and somehow, we may consider that actually this is a good 1089 thing as a way to push for the IPv6 deployment, or otherwise, it may 1090 be further delayed, with clear undesirable effects for the global 1091 Internet. 1093 However, for an operator, being in business means minimizing the 1094 adverse transition effects, and provide the most perfect one, 1095 reasonably balanced with cost (CAPEX/OPEX) and at the same time, 1096 looking for a valid long-term vision. 1098 NAT64/464XLAT has demonstrated to be a valid choice in several 1099 scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions 1100 of users, offering different choices of deployment, depending on each 1101 network case, needs and requirements. 1103 Depending on those requirements, DNS64 may be a required function, 1104 while in other cases the adverse effects may be counterproductive. 1105 Similarly, in some cases NAT64, together with DNS64, may be a valid 1106 solution, when for sure there is no need to support hosts or 1107 applications which are IPv4-only (Section 4.8 and Section 4.9). 1108 However, in other cases the limitations they have, may suggest the 1109 operator to look into 464XLAT as a more complete solution. 1111 Service providers willing to deploy NAT64, need to take into account 1112 the considerations of this document in order to better decide what is 1113 more appropriate for their own specific case. 1115 In the case of broadband managed networks (CE provided or suggested/ 1116 supported by the operator), in order to fully support the actual user 1117 needs (IPv4-only devices and applications, usage of literals and old 1118 APIs), they should consider the 464XLAT scenario and in that case, 1119 must support the customer-side translator (CLAT). 1121 If the operator offers DNS services, in order to increase performance 1122 by reducing the double translation for all the IPv4 traffic, they may 1123 support DNS64 and avoid, as much as possible, breaking DNSSEC. In 1124 this case, if the DNS service is offering DNSSEC validation, then it 1125 must be in such way that it is aware of the DNS64. This is 1126 considered the simpler and safer approach, and may be combined as 1127 well with the other possible recommendations described in this 1128 document: 1130 o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). 1132 o Devices running CLAT SHOULD follow the indications in 1133 Section 4.1.3 (Stub validator). However, this may be out of the 1134 control of the operator. 1136 o CEs SHOULD include a DNS proxy and validator (Section 4.1.4). 1138 o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4 1139 addresses) MAY be considered by operators, depending on their own 1140 infrastructure. 1142 This "increased performance" approach has the disadvantage of 1143 potentially breaking DNSSEC for a small percentage of validating end- 1144 hosts versus the small impact of a double translation taking place in 1145 the CE. If CE performance is not an issue, which is the most 1146 frequent case, then a much safer approach is to not use DNS64 at all, 1147 and consequently, ensure that all the IPv4 traffic is translated at 1148 the CLAT (Section 4.3). 1150 If DNS64 is not used, at least one of the alternatives described in 1151 Section 4.1.1, must be followed in order to learn he NAT64 prefix. 1153 The operator needs to consider that if the user can modify the DNS 1154 configuration (which most probably is impossible to avoid), and 1155 instead of configuring a DNS64 choose an external regular DNS (non- 1156 DNS64), a scenario with only NAT64 will not work with any IPv4-only 1157 remote host, while it will continue working in the case of 464XLAT 1158 (Section 4.4). Same effects are to be expected if DNS privacy 1159 protocols are being used by customers (Section 4.5), as well as in 1160 the case of Split DNS (Section 4.6). 1162 Similar considerations need to be taken regarding the usage of a 1163 NAT64 Well-Known-Prefix (WKP) vs Network-Specific Prefix (NSP) 1164 (Section 4.7), in the sense of, if using DNS64, they must match and, 1165 if the user can change the DNS configuration, they will, most 1166 probably, not match. If there is a CLAT and the users chosen DNS is 1167 not a DNS64, the network will keep working of other means of learning 1168 the NAT64 are available. 1170 As described in Section 4.10 in broadband networks, it is recommended 1171 that CEs supporting CLAT, supports DHCPv6-PD ([RFC8415]), or 1172 alternative means for configuring a shorter prefix, and internally 1173 reserve one /64 for the stateless NAT46 translation. The operator 1174 must ensure that the customers get allocated prefixes shorter than 1175 /64 in order to support this optimization. One way or the other, 1176 this is not impacting the performance of the operator network. 1178 Operators may follow Section 7 of [RFC6877] (Deployment 1179 Considerations), for suggestions in order to take advantage of 1180 traffic engineering requirements. 1182 In the case of cellular networks, the considerations regarding DNSSEC 1183 may appear as out-of-scope, because UEs OSs, commonly don't support 1184 DNSSEC, however applications running on them may do, or it may be an 1185 OS "built-in" support in the future. Moreover, if those devices 1186 offer tethering, other client devices behind the UE, may be doing the 1187 validation, hence the relevance of a proper DNSSEC support by the 1188 operator network. 1190 Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and 1191 "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" 1192 ([RFC7050]), allow a progressive IPv6 deployment, with a single APN 1193 supporting all types of PDP context (IPv4, IPv6, IPv4v6), in such way 1194 that the network is able to automatically serve every possible 1195 combinations of UEs. 1197 If the operator chooses to provide validation for the DNS64 prefix 1198 discovery, it must follow the advice from Section 3.1. of [RFC7050] 1199 (Validation of Discovered Pref64::/n). 1201 One last consideration, is that many networks may have a mix of 1202 different complex scenarios at the same time, for example, customers 1203 requiring 464XLAT, others not requiring it, customers requiring 1204 DNS64, others not, etc. In general, the different issues and the 1205 approaches described in this document can be implemented at the same 1206 time for different customers or parts of the network. That mix of 1207 approaches don't present any problem or incompatibility, as they work 1208 well together, being just a matter of appropriate and differentiated 1209 provisioning. 1211 In an ideal world will, we could safely use DNS64, if the approach 1212 proposed in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, 1213 avoiding the cases where DNSSEC may be broken. However, this will 1214 not solve the issues related to DNS Privacy and Split DNS. 1216 The only 100% safe solution, which also resolves all the issues, will 1217 be, in addition to having a CLAT, not using a DNS64 but instead 1218 making sure that the hosts have a built-in address synthesis feature. 1219 Operators could manage to use the CLAT, however the built-in address 1220 synthesis feature is out of their control, and can only be resolved 1221 by operating system vendors. 1223 Whenever feasible, using EAMT ([RFC7757]) as indicated in 1224 Section 4.11, provides a very relevant optimization, avoiding double- 1225 translations. 1227 6. Deployment of NAT64 in Enterprise Networks 1229 The recommendations of this document can be used as well in 1230 enterprise networks, campus and other similar scenarios (including 1231 managed end-user networks). 1233 This include scenarios where the NAT64 (and/or DNS64) are under the 1234 control of that network (or can be configured manually according to 1235 that network specific requirements), and for whatever reasons, there 1236 is a need to provide "IPv6-only access" to any part of that network 1237 or it is IPv6-only connected to third party networks. 1239 An example of that is the IETF meetings network itself, where a NAT64 1240 and DNS64 are provided, presenting in this case the same issues as 1241 per Section 3.1.1. If there is a CLAT in the IETF network, then 1242 there is no need to use DNS64 and it falls under the considerations 1243 of Section 3.1.3. Both scenarios have been tested and verified 1244 already in the IETF network itself. 1246 Next figures are only meant to represent a few of the possible 1247 scenarios, not pretending to be the only feasible ones. 1249 The following figure provides an example of and IPv6-only enterprise 1250 network connected with dual-stack to Internet and using local NAT64 1251 and DNS64. 1253 +----------------------------------+ 1254 | Enterprise Network | 1255 | +----------+ +----------+ | +----------+ 1256 | | IPv6 | | NAT64 | | | IPv4 | 1257 | | only +--------+ + | +-------+ + | 1258 | | LANs | | DNS64 | | | IPv6 | 1259 | +----------+ +----------+ | +----------+ 1260 +----------------------------------+ 1262 Figure 14: IPv6-only enterprise with NAT64 and DNS64 1264 The following figure provides an example of dual-stack (DS) 1265 enterprise network connected with dual-stack (DS) to Internet and 1266 using CLAT, without DNS64. 1268 +----------------------------------+ 1269 | Enterprise Network | 1270 | +----------+ +----------+ | +----------+ 1271 | | IPv6 | | | | | IPv4 | 1272 | | + +--------+ NAT64 | +-------+ + | 1273 | | CLAT | | | | | IPv6 | 1274 | +----------+ +----------+ | +----------+ 1275 +----------------------------------+ 1277 Figure 15: DS enterprise with CLAT, DS Internet, without DNS64 1279 Finally, the following figure provides an example of an IPv6-only 1280 provider with NAT64, and a dual-stack (DS) enterprise network by 1281 means of their own CLAT, without DNS64. 1283 +----------------------------------+ 1284 | Enterprise Network | 1285 | +----------+ +----------+ | +----------+ 1286 | | IPv6 | | | | IPv6 | | 1287 | | + +--------+ CLAT | +--------+ NAT64 | 1288 | | IPv4 | | | | only | | 1289 | +----------+ +----------+ | +----------+ 1290 +----------------------------------+ 1292 Figure 16: DS enterprise with CLAT, IPv6-only Internet, without DNS64 1294 7. Security Considerations 1296 This document does not have any new specific security considerations. 1298 8. IANA Considerations 1300 This document does not have any new specific IANA considerations. 1302 Note: This section is assuming that https://www.rfc- 1303 editor.org/errata/eid5152 is resolved, otherwise, this section may 1304 include the required text to resolve the issue. 1306 9. Acknowledgements 1308 The author would like to acknowledge the inputs of Gabor Lencse, 1309 Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed 1310 Boucadair and TBD ... 1312 Conversations with Marcelo Bagnulo, one of the co-authors of NAT64 1313 and DNS64, as well as several emails in mailing lists from Mark 1314 Andrews, have been very useful for this work. 1316 Christian Huitema inspired working in this document by suggesting 1317 that DNS64 should never be used, during a discussion regarding the 1318 deployment of CLAT in the IETF network. 1320 10. ANNEX A: Example of Broadband Deployment with 464XLAT 1322 This section summarizes how an operator may deploy an IPv6-only 1323 network for residential/SOHO customers, supporting IPv6 inbound 1324 connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT. 1326 Note that an equivalent setup could also be provided for enterprise 1327 customers. In case they need to support IPv4 inbound connections, 1328 several mechanisms, depending on specific customer needs, allow that. 1330 Conceptually, most of the operator network could be IPv6-only 1331 (represented in the next pictures as "IPv6-only Internet"). This 1332 part of the network connects the IPv6-only subscribers (by means of 1333 IPv6-only access links), to the IPv6 upstream providers, as well as 1334 to the IPv4-Internet by means of the NAT64 (PLAT in the 464XLAT 1335 terminology). 1337 The traffic flow from and back to the CE to services available in the 1338 IPv6 Internet (or even dual-stack remote services, when IPv6 is being 1339 used), is purely native IPv6 traffic, so no special considerations 1340 about it. 1342 Looking at the picture from the DNS perspective, there are remote 1343 networks with are IPv4-only, and typically will have only IPv4 DNS 1344 (DNS/IPv4), or at least will be seen as that from the CE perspective. 1345 At the operator side, the DNS, as seen from the CE, is only IPv6 1346 (DNS/IPv6) and has also a DNS64 function. 1348 In the customer LANs side, there is actually one network, which of 1349 course could be split in different segments, and the most common 1350 setup will be those segments being dual-stack (global IPv6 addresses 1351 and [RFC1918] for IPv4, as usual in any regular residential/SOHO IPv4 1352 network today). In the figure it is represented as tree segments, 1353 just to show that the three possible setups are valid (IPv6-only, 1354 IPv4-only and dual-stack). 1356 .-----. +-------+ .-----. .-----. 1357 / IPv6- \ | | / \ / \ 1358 ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ 1359 \ LANs / | SOHO +--( only )--( NAT64 )--( only ) 1360 `-----' | | \ Internet/ `-----' \ Internet/ 1361 .-----. | IPv6 | \ / \ / 1362 / IPv4- \ | CE | `--+--' `--+--' 1363 ( only )--+ with | | | 1364 \ LANs / | CLAT | +---+----+ +---+----+ 1365 `-----' | | |DNS/IPv6| |DNS/IPv4| 1366 .-----. +---+---+ | with | +--------+ 1367 / Dual- \ | | DNS64 | 1368 ( Stack )------| +--------+ 1369 \ LANs / 1370 `-----' 1372 Figure 17: CE setup with built-in CLAT with DNS64 1374 In addition to the regular CE setup, which will be typically access- 1375 technology dependent, the steps for the CLAT configuration can be 1376 summarized as: 1378 1. Discovery of the PLAT (NAT64) prefix: It may be done using 1379 [RFC7050], or in those networks where PCP is supported, by means 1380 of [RFC7225], or other alternatives that may be available in the 1381 future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or 1382 DHCPv6 options. 1384 2. If the CLAT allows stateless NAT46 translation, a /64 from the 1385 pool typically provided to the CE by means of DHCPv6-PD 1386 [RFC8415], need to be set aside for that translation. Otherwise, 1387 the CLAT is forced to perform an intermediate stateful NAT44 1388 before the a stateless NAT46, as described in Section 4.10. 1390 A more detailed configuration approach is described in 1391 [I-D.ietf-v6ops-transition-ipv4aas]. 1393 The operator network needs to ensure that the correct responses are 1394 provided for the discovery of the PLAT prefix, as well as it is 1395 highly recommended follows [RIPE-690], in order to ensure that 1396 multiple /64s are available including the one needed for the NAT46 1397 stateless translation. 1399 The operator needs to understand other issues, described across this 1400 document, in order to take the relevant decisions. For example, if 1401 several NAT64 are needed in the context of scalability/high- 1402 availability, an NSP should be considered (Section 4.7). 1404 More complex scenarios are possible, for example, if a network offers 1405 multiple NAT64 prefixes, destination-based NAT64 prefixes, etc. 1407 If the operator decides not to provide DNS64, then this setup turns 1408 into the one in the following Figure. This will be also the setup 1409 that, if the user has changed the DNS and consequently is not using 1410 the operator DNS64, "it will be seen" from the perspective of the CE. 1412 .-----. +-------+ .-----. .-----. 1413 / IPv6- \ | | / \ / \ 1414 ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ 1415 \ LANs / | SOHO +--( only )--( NAT64 )--( only ) 1416 `-----' | | \ Internet/ `-----' \ Internet/ 1417 .-----. | IPv6 | \ / \ / 1418 / IPv4- \ | CE | `--+--' `--+--' 1419 ( only )--+ with | | | 1420 \ LANs / | CLAT | +---+----+ +---+----+ 1421 `-----' | | |DNS/IPv6| |DNS/IPv4| 1422 .-----. +---+---+ +--------+ +--------+ 1423 / Dual- \ | 1424 ( Stack )------| 1425 \ LANs / 1426 `-----' 1428 Figure 18: CE setup with built-in CLAT without DNS64 1430 In this case, the discovery of the PLAT prefix need to be arranged as 1431 indicated in Section 4.1.1. 1433 In this case, the CE doesn't have a built-in CLAT, or the customer 1434 can choose to setup the IPv6 operator-managed CE in bridge mode (and 1435 optionally use its own external router), or for example, there is an 1436 access technology that requires some kind of media converter (ONT for 1437 FTTH, CableModem for DOCSIS, etc.), the complete setup will look as 1438 in the next figure. Obviously, there will be some intermediate 1439 configuration steps for the bridge, depending on the specific access 1440 technology/protocols, which should not modify the steps already 1441 described in the previous cases for the CLAT configuration. 1443 +-------+ .-----. .-----. 1444 | | / \ / \ 1445 | Res./ | / IPv6- \ .-----. / IPv4- \ 1446 | SOHO +--( only )--( NAT64 )--( only ) 1447 | | \ Internet/ `-----' \ Internet/ 1448 | IPv6 | \ / \ / 1449 | CE | `--+--' `--+--' 1450 | Bridge| | | 1451 | | +---+----+ +---+----+ 1452 | | |DNS/IPv6| |DNS/IPv4| 1453 +---+---+ +--------+ +--------+ 1454 | 1455 .-----. +---+---+ 1456 / IPv6- \ | | 1457 ( only )--+ IPv6 | 1458 \ LANs / | Router| 1459 `-----' | | 1460 .-----. | with | 1461 / IPv4- \ | CLAT | 1462 ( only )--+ | 1463 \ LANs / | | 1464 `-----' | | 1465 .-----. +---+---+ 1466 / Dual- \ | 1467 ( Stack )------| 1468 \ LANs / 1469 `-----' 1471 Figure 19: CE setup with bridged CLAT without DNS64 1473 It should be avoided that several routers (i.e., the operator 1474 provided CE and a downstream user provided router) enable 1475 simultaneously routing and/or CLAT, in order to avoid multiple NAT44 1476 and NAT46 levels, as well as ensuring the correct operation of 1477 multiple IPv6 subnets. In those cases, it is suggested the use of 1478 HNCP ([RFC8375]). 1480 Note that the procedure described here for the CE setup, can be 1481 simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas]. 1483 11. ANNEX B: CLAT Implementation 1485 In addition to the regular set of features for a CE, a CLAT CE 1486 implementation requires support of: 1488 o [RFC7915], for the NAT46 functionality. 1490 o [RFC7050], for the PLAT prefix discovery. 1492 o [RFC7225], for the PLAT prefix discovery if PCP is supported. 1494 o [I-D.ietf-6man-ra-pref64], for the PLAT prefix discovery by means 1495 of Router Advertising. 1497 o If stateless NAT46 is supported, a mechanism to ensure that 1498 multiple /64 are available, such as DHCPv6-PD [RFC8415]. 1500 There are several OpenSource implementations of CLAT, such as: 1502 o Android: https://github.com/ddrown/android_external_android-clat. 1504 o Linux: https://github.com/toreanderson/clatd. 1506 o OpenWRT: https://github.com/openwrt- 1507 routing/packages/blob/master/nat46/files/464xlat.sh. 1509 o VPP: https://git.fd.io/vpp/tree/src/plugins/nat. 1511 12. ANNEX C: Benchmarking 1513 Several documents provide references to benchmarking, for example in 1514 the case of DNS64, [DNS64-Benchm]. 1516 13. ANNEX D: Changes from -00 to -01 1518 Section to be removed after WGLC. Significant updates are: 1520 1. Text changes across all the document. 1522 14. ANNEX E: Changes from -01 to -02 1524 Section to be removed after WGLC. Significant updates are: 1526 1. Added references to new cited documents. 1528 2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only 1529 LANs w/o DNS64. 1531 3. Overall review and editorial changes. 1533 15. ANNEX F: Changes from -02 to -03 1535 Section to be removed after WGLC. Significant updates are: 1537 1. Added text related to EAMT considerations. 1539 16. References 1541 16.1. Normative References 1543 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1544 and E. Lear, "Address Allocation for Private Internets", 1545 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1546 . 1548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1549 Requirement Levels", BCP 14, RFC 2119, 1550 DOI 10.17487/RFC2119, March 1997, 1551 . 1553 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1554 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1555 DOI 10.17487/RFC6052, October 2010, 1556 . 1558 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1559 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1560 April 2011, . 1562 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1563 NAT64: Network Address and Protocol Translation from IPv6 1564 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1565 April 2011, . 1567 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1568 Beijnum, "DNS64: DNS Extensions for Network Address 1569 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1570 DOI 10.17487/RFC6147, April 2011, 1571 . 1573 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 1574 Using "Bump-in-the-Host" (BIH)", RFC 6535, 1575 DOI 10.17487/RFC6535, February 2012, 1576 . 1578 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1579 Combination of Stateful and Stateless Translation", 1580 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1581 . 1583 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 1584 "Analysis of Stateful 64 Translation", RFC 6889, 1585 DOI 10.17487/RFC6889, April 2013, 1586 . 1588 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1589 the IPv6 Prefix Used for IPv6 Address Synthesis", 1590 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1591 . 1593 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 1594 Port Control Protocol (PCP)", RFC 7225, 1595 DOI 10.17487/RFC7225, May 2014, 1596 . 1598 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 1599 Mappings for Stateless IP/ICMP Translation", RFC 7757, 1600 DOI 10.17487/RFC7757, February 2016, 1601 . 1603 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1604 "IP/ICMP Translation Algorithm", RFC 7915, 1605 DOI 10.17487/RFC7915, June 2016, 1606 . 1608 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1609 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1610 May 2017, . 1612 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1613 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1614 . 1616 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1617 Better Connectivity Using Concurrency", RFC 8305, 1618 DOI 10.17487/RFC8305, December 2017, 1619 . 1621 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1622 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1623 . 1625 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1626 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1627 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1628 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1629 . 1631 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1632 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1633 . 1635 16.2. Informative References 1637 [About-DNS64] 1638 APNIC Blog, "Let's talk about IPv6 DNS64 & DNSSEC", 2016, 1639 . 1642 [DNS64-Benchm] 1643 "Benchmarking DNS64 Implementations: Theory and Practice", 1644 Computer Communications (Elsevier), vol. 127, no. 1, 1645 pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September 1646 2018. 1648 [I-D.bp-v6ops-ipv6-ready-dns-dnssec] 1649 Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC 1650 Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00 1651 (work in progress), October 2018. 1653 [I-D.huitema-quic-dnsoquic] 1654 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 1655 Iyengar, "Specification of DNS over Dedicated QUIC 1656 Connections", draft-huitema-quic-dnsoquic-06 (work in 1657 progress), March 2019. 1659 [I-D.ietf-6man-ra-pref64] 1660 Colitti, L., Kline, E., and J. Linkova, "Discovering 1661 PREF64 in Router Advertisements", draft-ietf-6man-ra- 1662 pref64-00 (work in progress), March 2019. 1664 [I-D.ietf-v6ops-transition-ipv4aas] 1665 Palet, J., Liu, H., and M. Kawashima, "Requirements for 1666 IPv6 Customer Edge Routers to Support IPv4 Connectivity 1667 as-a-Service", draft-ietf-v6ops-transition-ipv4aas-15 1668 (work in progress), January 2019. 1670 [I-D.palet-v6ops-464xlat-opt-cdn-caches] 1671 Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/ 1672 Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work 1673 in progress), March 2019. 1675 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 1676 "Architectural Considerations on Application Features in 1677 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 1678 . 1680 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 1681 Deployment Options and Experience", RFC 7269, 1682 DOI 10.17487/RFC7269, June 2014, 1683 . 1685 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1686 and P. Hoffman, "Specification for DNS over Transport 1687 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1688 2016, . 1690 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1691 Transport Layer Security (DTLS)", RFC 8094, 1692 DOI 10.17487/RFC8094, February 2017, 1693 . 1695 [RIPE-690] 1696 RIPE, "Best Current Operational Practice for Operators: 1697 IPv6 prefix assignment for end-users - persistent vs non- 1698 persistent, and what size to choose", October 2017, 1699 . 1701 [Threat-DNS64] 1702 "Methodology for the identification of potential security 1703 issues of different IPv6 transition technologies: Threat 1704 analysis of DNS64 and stateful NAT64", Computers & 1705 Security (Elsevier), vol. 77, no. 1, pp. 397-411, 1706 DOI 10.1016/j.cose.2018.04.012, August 2018. 1708 Author's Address 1710 Jordi Palet Martinez 1711 The IPv6 Company 1712 Molino de la Navata, 75 1713 La Navata - Galapagar, Madrid 28420 1714 Spain 1716 Email: jordi.palet@theipv6company.com 1717 URI: http://www.theipv6company.com/