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