idnits 2.17.1 draft-palet-v6ops-464xlat-opt-cdn-caches-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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1751 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 (-08) exists of draft-ietf-v6ops-nat64-deployment-06 Summary: 0 errors (**), 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 A. D'Egidio 5 Expires: January 9, 2020 Telecentro 6 July 8, 2019 8 464XLAT Optimization 9 draft-palet-v6ops-464xlat-opt-cdn-caches-03 11 Abstract 13 This document proposes possible solutions to avoid certain drawbacks 14 of IP/ICMP Translation Algorithm (SIIT) when the destinations are 15 available with IPv6. When SIIT is used as a NAT46 and IPv4-only 16 devices or applications initiate traffic flows to dual-stack CDNs 17 (Content Delivery Networks), Caches or other network resources (in 18 the operator network or Internet), those flows will be translated 19 back to IPv4 by a NAT64. This is the case for 464XLAT and MAP-T. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 9, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 57 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 6 60 4.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 7 61 4.2.1. Detection of IPv4-only devices or applications . . . 7 62 4.2.2. Detection of IPv6-enabled service . . . . . . . . . . 8 63 4.2.3. Creation of EAMT entries . . . . . . . . . . . . . . 8 64 4.2.4. Forwarding path for existing EAMT entries . . . . . . 10 65 4.2.5. Maintenance of the EAMT entries . . . . . . . . . . . 10 66 4.2.6. Usage example . . . . . . . . . . . . . . . . . . . . 10 67 4.2.7. Behavior in case of multiple A/AAAA RRs . . . . . . . 10 68 4.2.8. Behavior in presence/absence of DNS64 . . . . . . . . 11 69 4.2.9. Behavior when using literal addreses or non 70 IPv6-compliant APIs . . . . . . . . . . . . . . . . . 11 71 4.2.10. False detection of a dual-stack host as IPv4-only . . 11 72 4.2.11. Behaviour in presence of Happy Eyeballs . . . . . . . 11 73 4.2.12. Behavior in case of Foreign DNS . . . . . . . . . . . 12 74 4.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 13 75 5. IPv6-only Services become accessible to IPv4-only 76 devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 10.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 Different transition mechanisms, typically in the group of the so- 89 called IPv6-only with IPv4aaS (IPv4-as-a-Service), such as 464XLAT 90 ([RFC6877]) or MAP-T ([RFC7599]), allow IPv4-only devices or 91 applications to connect with IPv4 services in Internet, by means of a 92 NAT46 SIIT (IP/ICMP Translation Algorithm) as described by [RFC7915]. 94 This is done by the implementation of SIIT at the CE (Customer Edge) 95 Router or sometimes at the end-device, for example, the UE (User 96 Equipment) in cellular networks. This functionality is the CLAT 97 (Customer Translator) in the case of 464XLAT. 99 The NAT46/CLAT (WAN side) is connected by IPv6-only to the operator 100 network, which in turn, will have a reverse function, the NAT64 101 ([RFC6146]), known as PLAT (Provider Translator) in the case of 102 464XLAT. This allows to translate the IPv6-only flow back to IPv4, 103 in order to forward it to Internet. 105 The translation of the packet headers is done using the IP/ICMP 106 translation algorithm defined in [RFC7915] and algorithmically 107 translating the IPv4 addresses to IPv6 addresses following [RFC6052]. 109 In the case of 464XLAT, a DNS64 ([RFC6147]) optionally is in charge 110 of the synthesis of AAAA records from the A records, so they can use 111 a NAT64, without the need of doing a double-translation by means of 112 the CLAT. However, the DNS64 is not useful for the IPv4-only devices 113 or applications in the LANs, as they will not be able to use the AAAA 114 records. 116 A typical 464XLAT deployment is depicted in Figure 1. 118 +-------+ .-----. .-----. 119 | IPv6 | / \ / \ 120 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 121 / \ | or +--( only )---( NAT64 )---( Internet ) 122 / LAN's \ | UE | \ Access /\ `-----' \ / 123 ( Dual- )--+ | \ / \ \ / 124 \ Stack / | with | `--+--' \ .-----. `-----' 125 \ / | NAT46 | | \ / \ 126 `-----' | CLAT | +---+----+ / IPv6 \ 127 | | | DNS/ | ( Internet ) 128 +-------+ | DNS64 | \ / 129 +--------+ \ / 130 `-----' 132 Figure 1: Typical 464XLAT Deployment 134 As it can be observed in the preceding picture, the situation is the 135 same, regardless of in case of a wired network with a CE Router or a 136 cellular network where a UE is connecting other devices (which may be 137 IPv4-only or have IPv4-only apps), by means of a tethering 138 functionality. 140 If the operator is providing direct access to Content Delivery 141 Networks (CDNs), caches, or other resources, and they are dual- 142 stacked, the situation can be described as shown in Figure 2. 144 +-------+ .-----. .-----. 145 | IPv6 | / \ / \ 146 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 147 / \ | or +--( only )---( NAT64 )---( Internet ) 148 / LAN's \ | UE | \ Access /\ `-----' \ / 149 ( Dual- )--+ | \ / \ \ / 150 \ Stack / | with | `--+--' \ .-----. `--+--' 151 \ / | NAT46 | | \ / \ \ 152 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 153 | | | DNS/ | ( Internet ) / Dual- \ 154 +-------+ | DNS64 | \ /----/ Stack \ 155 +--------+ \ / ( ) 156 `-----' \ CDNs/ / 157 \ Caches/ 158 `-----' 160 Figure 2: Typical 464XLAT Deployment with CDNs/Caches 162 2. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 3. Problem Statement 172 If the devices or applications in the customer LAN are IPv6-capable, 173 then the access to the CDNs, caches or other resources, will be made 174 in an optimized way, by means of IPv6-only, not using the NAT64, as 175 depicted in Figure 3. 177 +-------+ .-----. .-----. 178 | IPv6 | / \ / \ 179 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 180 / \ | or +--( only )---( NAT64 )---( Internet ) 181 / IPv6 \ | UE | \ Access /\ `-----' \ / 182 ( capable )--+ | \ / \ \ / 183 \ apps / | with | `--+--' \ .-----. `--+--' 184 \ / | NAT46 | | \ / \ 185 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 186 | | | DNS/ | ( Internet )IPv6/ Dual- \ 187 +-------+ | DNS64 | \ /----/ Stack \ 188 +--------+ \ / ( ) 189 `-----' \ CDNs/ / 190 \ Caches/ 191 `-----' 192 <---------------------- end-to-end IPv6 flow ----------------------> 194 Figure 3: 464XLAT access to CDNs/Caches by IPv6-capable apps 196 However, if the devices or applications are IPv4-only, for example, 197 most of the SmartTVs and Set-Top-Boxes available today, a non-optimal 198 double translation will occur (NAT46 at the CLAT and NAT64 at the 199 PLAT), as illustrated in Figure 4. 201 +-------+ .-----. .-----. 202 | IPv6 | / \ / \ 203 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 204 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 205 / only \ | UE | \ Access /\ `-----' \ / 206 ( SmartTV )--+ | \ / \ \ / 207 \ STB / | with | `--+--' \ .-----. `--+--' 208 \ VoIP / | NAT46 | | \ / \ \ IPv4 209 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 210 | | | DNS/ | ( Internet ) / Dual- \ 211 +-------+ | DNS64 | \ / / Stack \ 212 +--------+ \ / ( ) 213 `-----' \ CDNs/ / 214 \ Caches/ 215 `-----' 216 <-------------------- IPv4 to IPv6 to IPv4 flow --------------------> 218 Figure 4: 464XLAT access to CDNs/Caches by IPv4-only apps 220 Clearly, this is a non-optimal situation, as it means that even if 221 there is a dual-stack service, the NAT46/CLAT translated IPv4 to IPv6 222 traffic flow, is unnecessarily translated back to IPv4, traversing 223 the stateful NAT64. This has a direct impact in the need to scale 224 the NAT64 beyond what will be actually needed if possible solutions, 225 in order to keep using the IPv6 path towards those services, are 226 considered. 228 As shown in the Figure 4, this is also the case for many other 229 services, not just CDNs or caches, such as VoIP access to the 230 relevant operator infrastructure, which may be also dual-stack. This 231 is true as well for many other dual-stack or IPv6-enabled services, 232 which may be directly reachable from the operator infrastructure, 233 even if they are not part of it, for example peering agreements, 234 services in IXs, etc. In general, this will become a more frequent 235 situation for many other services, which are not yet dual-stack. 237 For simplicity, across the rest of this document, references to CDNs/ 238 caches, should be understood, unless otherwise stated, as any dual- 239 stacked resources. 241 This document looks into different possible solution approaches in 242 order to optimize the IPv4-only SIIT translation providing a direct 243 path to IPv6-capable services, as depicted in Figure 5. 245 +-------+ .-----. .-----. 246 | IPv6 | / \ / \ 247 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 248 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 249 / only \ | UE | \ Access /\ `-----' \ / 250 ( SmartTV )--+ | \ / \ \ / 251 \ STB / | with | `--+--' \ .-----. `--+--' 252 \ VoIP / | NAT46 | | \ / \ 253 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 254 | | | DNS/ | ( Internet )IPv6/ Dual- \ 255 +-------+ | DNS64 | \ /----/ Stack \ 256 +--------+ \ / ( ) 257 `-----' \ CDNs/ / 258 \ Caches/ 259 `-----' 260 <------------------------ IPv4 to IPv6 flow ------------------------> 262 Figure 5: Optimized 464XLAT access to CDNs/Caches by IPv4-only apps 264 4. Solution Approaches 266 4.1. Approach 1: DNS/Routing-based Solution 268 Because the IPv4-only devices will not be able to query for AAAA 269 records, the NAT46/CLAT/CE will translate the IPv4 addresses from the 270 A record for the CDN/cache destination, using the WKP or NSP, as 271 configured by the operator. 273 If the CDN/cache provider is able to configure, in the relevant 274 interfaces of the CDN/caches, the same IPv6 addresses that will 275 naturally result as the translated destination addresses for the 276 queried A records, preceded by the WKP or NSP, then having more 277 specific routing prefixes, will result in traffic to those 278 destinations being directly forwarded towards those interfaces, 279 instead of needing to traverse the NAT64. 281 For example, let's suppose a provider using the WKP (64:ff9b::/96) 282 and a SmartTV querying for www.example.com: 284 www.example.com A 192.0.2.1 285 NAT46/CLAT translated to 64:ff9b::192.0.2.1 286 CDN IPv6 interface must be 64:ff9b::192.0.2.1 287 Operator must have a specific route to 64:ff9b::192.0.2.1 289 Note: Examples using text representation as per Section 2.3 of 290 [RFC6052]. 292 Because the WKP is non-routable, this solution will only be possible 293 if the CDN/cache is in the same ASN as the provider network, or 294 somehow interconnected without routing thru Internet. 296 This solution has the additional drawback of the operational 297 complexity/issues added to the operation of the CDN/cache, and the 298 need to synchronize any IPv4 interface address changes with the 299 relevant IPv6 ones, and possibly with routing. 301 4.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution 303 If the NAT46/CLAT/CE, as commonly is the case, is also a DNS proxy/ 304 stub resolver, it is possible to modify the behavior and create an 305 "internal" interaction among both of them. 307 This approach uses the existing IPv4 and IPv6 addresses in the A and 308 AAAA records, respectively, so no additional complexity/issues added 309 to the CDN/caches operations. 311 The following sub-sections detail this approach and provide a step- 312 by-step example case. 314 4.2.1. Detection of IPv4-only devices or applications 316 The assumption is that, typically a dual-stack device will prefer 317 using IPv6 as the DNS transport. So, when there is a DNS query, 318 transported with IPv4, for an A record, and there is not a query for 319 the AAAA record from the same IPv4 source (to the same destination), 320 the DNS proxy/stub resolver can infer that, most probably, it is an 321 IPv4-only device or application. 323 It needs to be remarked that, if the detection of the IPv4-only 324 device or application is done incorrectly (either not detecting it or 325 by a false detection), no harm is caused. In the worst case, 326 optimization will not be performed, at least, at the time being. 327 However, optimization maybe performed later on, if a new detection 328 succeeds (for example, another device using the same A record). 330 4.2.2. Detection of IPv6-enabled service 332 In the case of an IPv4-only detected device or application, the DNS 333 proxy/stub resolver MUST actually perform an additional AAAA query, 334 unless the information is already present in the Additional Section, 335 as per Section 3 of [RFC3596]. Note that the NAT46/CLAT MUST already 336 know the WKP or NSP being used in that network. If the response 337 contains at least one IPv6 address not using the WKP/NSP, it means 338 that the destination is IPv6-enabled (because at least one of the 339 IPv6 addresses is not synthesized). This means that it is possible 340 for the NAT46/CLAT, to create an Explicit Address Mapping 341 ([RFC7757]). 343 4.2.3. Creation of EAMT entries 345 This way, an EAM Table (EAMT used for short, across the rest of this 346 document) is created/maintained automatically by the DNS proxy/stub 347 resolver in the NAT46/CLAT, and the NAT46/CLAT is responsible to 348 prioritize any available entries in the EAMT, versus the use of any 349 synthetic AAAA. 351 In order to create the EAMT entry, to determine if there is an AAAA 352 record after an A record query, it is suggested to use the same delay 353 value (50 milliseconds) as the "Resolution Delay" indicated by Happy 354 Eyeballs [RFC8305]. This avoids a slight NAT64 overload and flapping 355 between destination addresses (IPv4/IPv6), which may impact some 356 applications, at the cost of a small extra delay for the initial 357 communication setup, when the EAMT entry doesn't yet exist. 359 Each EAMT entry will contain, the fields already described in 360 [RFC7757] and a few new ones: 362 1. ID: EAMT Entry Index (optional). 364 2. IPv4 address/prefix: By default, the prefix length is 32 bits. 366 3. IPv6 address/prefix: By default, the prefix length is 128 bits. 368 4. TTL: Because the optimization will make use of the AAAA (IPv6 369 address), the TTL for the EAMT entry must be the one of the AAAA 370 RR. In normal conditions the TTL for both A and AAAA records, of 371 a given FQDN, should be the same, so this ensures a proper 372 behavior if there is any DNS mismatch. 374 5. FQDN: The one that originated the A query for this EAMT entry. 375 Required in order to ensure a correct detection of cases such as 376 the use of reverse-proxy with a single IPv4 address to multiple 377 IPv6 addresses. 379 6. Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT 380 be used and consequently no optimization performed. It may be 381 used also for an explicit configuration (GUI, CLI, provisioning 382 system, etc.) to disallow optimization for any IPv4 addresses. 384 7. Auto/Static: When set to 1, means that this EAMT entry has been 385 manually/statically configured, for example by means of an 386 explicit configuration (GUI, CLI, provisioning system, etc.), so 387 it doesn't expire with TTL. 389 When a new EAMT entry is first automatically created, it is marked as 390 "Valid" and "Auto" (both bits cleared). If a subsequent A query, 391 with a different FQDN, results in an IPv4 address that has already an 392 EAMT entry and a different IPv6 address, it means that some reverse- 393 proxy or similar functionality is being used by the IPv6-enabled 394 service. In this case, the existing EAMT entry will be marked as 395 "Invalid" (bit set). No new EAMT entry is created for that IPv4 396 address. Otherwise, the optimization will only allow to access the 397 first set of IPv4/IPv6/FQDN, which may break the access to other FQDN 398 that share the same IPv4 address and different IPv6 addresses. 400 In this case the EAMT entry will still expire according the TTL, 401 which allows to re-enable optimization if a new query for the A 402 record has changed the situation. For example, maybe the reverse- 403 proxy has been removed, or there is now only a single device using 404 it, so at the time being, the optimization is again possible without 405 creating troubles to other hosts. 407 Note that when an EAMT entry is marked as "invalid", it will not 408 affect the devices or applications, as they will still be able to use 409 the regular CLAT+NAT64 flow, of course, without the optimization. 411 ***** Open question regarding TTL and maybe FQDN and valid/auto bits. 412 Is this always a good thing to do for EAM? Should this document 413 update [RFC7757] to support this by default? Or it is just and 414 "extension" as per section 3.1 of [RFC7757]. 416 4.2.4. Forwarding path for existing EAMT entries 418 Following this approach, if there is a valid EAMT entry, for a given 419 IPv4-destination, the IPv6-native path pointed by the IPv6 address of 420 that EAMT entry, will take precedence versus the NAT64 path, so the 421 traffic will not be forwarded to the NAT64. 423 4.2.5. Maintenance of the EAMT entries 425 The information in the EAMT MUST be kept timely-synchronized with the 426 AAAA records TTL's, so the EAMT entries MUST expire on the AAAA TTL 427 expiry and consequently be deleted. 429 However, EAMT entries with the Auto/Static bit set, will not be 430 deleted. 432 4.2.6. Usage example 434 Using the same example as in the previous approach: 436 www.example.com A 192.0.2.1 437 AAAA 2001:db8::a:b:c:d 438 EAMT entry 192.0.2.1 2001:db8::a:b:c:d 439 NAT46/CLAT translated to 2001:db8::a:b:c:d 440 CDN IPv6 interface already is 2001:db8::a:b:c:d 441 Operator already has a specific route to 2001:db8::a:b:c:d 443 The following is an example of the CE behavior after the previous 444 case has already created an EAMT entry and a reverse-proxy is 445 detected: 447 1. A query for www.another-example.com A RR is received 449 2. www.another-example.com A 192.0.2.1 451 3. www.another-example.com AAAA 2001:db8::e:e:f:f 453 4. A conflict has been detected 455 5. The existing EAMT entry for 192.0.2.1 is set as invalid 457 4.2.7. Behavior in case of multiple A/AAAA RRs 459 If multiple A and/or AAAA records are available, the DNS proxy/stub 460 resolver MUST follow existing procedures to choose each one. In 461 other words, the chosen pair of A/AAAA records doesn't present any 462 different result compared with a situation when this mechanism is not 463 used. 465 4.2.8. Behavior in presence/absence of DNS64 467 This mechanism performs the same in both cases, if a DNS64 is 468 present/used and if it is not present/used. This is explained 469 because the mechanism is only relevant for destinations which don't 470 have AAAA records, and in those cases DNS64 is not relevant. 471 Furthermore, because as indicated in Section 4.2.2, the EAMT entry is 472 not created when the service is IPv6-enabled. This is relevant 473 because 464XLAT can be deployed/used with and without a DNS64. 475 4.2.9. Behavior when using literal addreses or non IPv6-compliant APIs 477 Because the EAMT entries are only created when the NAT46/CLAT/CE 478 proxy/stub DNS is being used, any devices or applications that don't 479 use DNS, will not create the relevant entries. 481 They will be however optimized if devices or applications using DNS, 482 at some point, query for the same A RRs, or if EAMT entries are 483 statically configured. 485 4.2.10. False detection of a dual-stack host as IPv4-only 487 If a dual-stack host is issuing the A query using IPv4 transport, and 488 the AAAA query using IPv6 transport, or using different IPv4 489 addresses for the A and AAAA queries, the EAMT entry will be created. 490 However, this EAMT entry may not be used by dual-stack devices or 491 applications, because those devices or applications should prefer 492 IPv6. If the host is preferring IPv4 for connecting to the CDN/cache 493 or IPv6-enabled service, it will be actually using the NAT46/CLAT, 494 including the EAMT entry and consequently IPv6, so this mechanism 495 will be correcting an undesirable behavior. This is a special case, 496 which actually seems to be an incoherent host or application 497 implementation. 499 However, if other IPv4-only devices or applications subsequently need 500 to connect to the same IPv6-enabled service, they will take advantage 501 of the already existing EAMT entry, and consequently use the 502 IPv6-optimised path. 504 4.2.11. Behaviour in presence of Happy Eyeballs 506 Happy Eyeballs [RFC8305] is only available in dual-stack hosts. 507 Consequently, is not affected by this mechanism because both, the A 508 and the AAAA queries should be issued by the host as soon after one 509 another as possible. However, if the same NAT46/CLAT/CE is serving 510 IPv4-only hosts and dual-stack hosts and both of them are using the 511 same destinations, an EAMT entry will be created for that 512 destination. Consequently, a Happy Eyeballs fallback to IPv4 will 513 actually be using the relevant EAMT entry IPv6 destination. This has 514 the disadvantage that the IPv4-IPv6-IPv4 translation path can't be 515 used by Happy Eyeballs-enabled applications. However, this may be 516 actually considered as a good thing, in the sense that an operator is 517 interested in knowing as soon as possible, if the IPv6-only network 518 is not performing correctly, because that means also IPv4 will not be 519 working. If the issue is related to extra IPv6 delay versus the IPv4 520 delay, Happy Eyeballs will not be able to offer a significative 521 advantage here, but it looks like an acceptable trade-off. 523 Note that when using 464XLAT, the WAN link of the NAT46/CLAT/CE is 524 IPv6-only. So even if Happy Eyeballs is present, the fallback to 525 IPv4-only typically, will be slower than native IPv6 itself, because 526 the added detail in the NAT46+NAT64 translations, when not using this 527 optimization. 529 4.2.12. Behavior in case of Foreign DNS 531 Devices or applications may use DNS servers from other networks. For 532 a complete description of reasons for that, refer to Section 4.4 of 533 [I-D.ietf-v6ops-nat64-deployment]. In the case the DNS is modified, 534 or some devices or applications use other DNS servers, the possible 535 scenarios and the implications are: 537 a. Devices configured to use a DNS proxy/resolver which is not the 538 CE/NAT46/CLAT. In this case this optimization will not work, 539 because the EAMT entry will not be created based on their own 540 flows. Nevertheless, the EAMT entry may be created by other 541 devices using the same destinations. However, the lack of EAMT 542 entry, will not impact negatively in the user's devices/ 543 applications (the optimization is not performed). It should be 544 noticed that users commonly, don't change the configuration of 545 devices such as SmartTVs or STBs (if they do, some other 546 functionalities, such as CDN/caches optimizations may not work as 547 well), so this only happens typically if the vendor is doing it 548 on-purpose and for good well-known reasons. 550 b. DNS privacy/encryption. Hosts or applications that use 551 mechanisms for DNS privacy/encryption, such as DoT ([RFC7858], 552 [RFC8094]), DoH ([RFC8484]) or DoQ ([I-D.huitema-quic-dnsoquic]), 553 will not make use of the stub/proxy resolver, so the same 554 considerations as for the previous case apply. 556 c. Users that modify the DNS in their Operating Systems. This is 557 quite frequent, however commonly Operating Systems are dual- 558 stack, so aren't part of the problem statement described by this 559 document and will not be adversely affected. 561 d. Users that modify the DNS in the CE. This is less common. In 562 this case, this optimization is not adversely affected, because 563 it doesn't depend on the operator DNS, it works only based on the 564 internal CE interaction between the NAT46/CLAT and the stub/proxy 565 resolver. Note that it may be affected if the operator offers 566 different "DNS views" or "split DNS", however this is not related 567 to this optimization and will anyway impact in the other possible 568 operator optimizations (i.e. CDN/cache features). 570 e. Combinations of the above ones. No further impact, than the one 571 already described, is observed. 573 4.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution 575 Instead of using the DNS proxy/stub resolver to create the EAMT 576 entries, the operator may push this table (or parts of it) into the 577 CE/NAT46/CLAT, by using configuration/management mechanisms. 579 This solution has the advantage of not being affected by any DNS 580 changes from the user (the EAMT is created by the operator) and 581 ensures a complete control from the operator. However, it may impact 582 the cases of devices with a DNS configured by the vendor. 584 In general, most of the considerations from the previous approach 585 will apply. 587 One more advantage of this solution is that the EAMT pairs doesn't 588 need to match the "real" IPv4/IPv6 addresses available in the A/AAAA 589 records, as shown in the next example. 591 www.example.com A 192.0.2.1 592 AAAA 2001:db8::a:b:c:d 593 EAMT pulled/pushed entry 192.0.2.1 2001:db8::f:e:d:c 594 NAT46/CLAT translated to 2001:db8::f:e:d:c 595 CDN IPv6 interface already is 2001:db8::f:e:d:c 596 Operator already has a specific route to 2001:db8::f:e:d:c 598 EAMT may contain TTLs which probably are derived from DNS ones, or 599 alternatively, a global TTL for the full table. 601 An alternative way to configure the table, is that the CE is actually 602 pulling the table (or parts of it) from the operator infrastructure. 603 In this case it will be mandatory that the entries have individual 604 TTLs, again probably derived from the DNS ones. 606 The major drawback of this approach is that it requires a new 607 protocol, or an extension to existing ones, in order to push or pull 608 the EAMT, in addition to the possible impact in terms of bandwidth 609 each time the CEs reboot, or an EAMT must be pushed to all the CEs, 610 etc. 612 5. IPv6-only Services become accessible to IPv4-only devices/apps 614 One of the issues with the IPv6 deployment, is that those services 615 which become IPv6-only in Internet, aren't reachable by IPv4-only 616 devices and applications. This means that new content providers must 617 support dual-stack even for new services, even while IPv4 public 618 addresses aren't available. 620 If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it can 621 be complemented to resolve this issue, by means of making sure that 622 IPv6-only destinations have one A resource record (even an invalid 623 one), despite they aren't actually connected to IPv4. This will mean 624 that those services will work fine if there is a NAT46/CLAT, and will 625 have no impact if that one doesn't exist, not a different situation 626 than not having an A resource record. 628 In fact, it may become an incentive for the IPv6 deployment in 629 Internet services and provides the option to use an IPv4 address 630 (maybe anycast) for the "non-valid" A resource record, that points to 631 a "universal" web page (maybe hosted by IETF?) that displays a 632 warning such as "Sorry, you don't IPv6 support in your operator, so 633 this service is not available for you". 635 6. Conclusions 637 NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right 638 solution for optimizing the access to dual-stack services, whether 639 they are located inside or outside the ISP. 641 Having this type of optimization facilitates and increases the usage 642 of IPv6, even for IPv4-only devices and applications, at the same 643 time that decreases the use of the NAT64. 645 SIIT already has a SHOULD for EAM support. Should 464XLAT be updated 646 by this document so the CLAT has a MUST for EAM support?. 648 Should we recommend having A records for IPv6-only services in 649 Internet? The A record may point to a "reserved" or "special" IPv4 650 address. A web page IPv4-only hosted by IETF(?) showing "sorry this 651 web page/service is only available from IPv6 enabled operators"?. 653 Open question: Should we consider any other risks? If CE's 654 implementing this optimization create troubles, it may bring the 655 content providers to switch back to IPv4-only. So possible failure 656 cases need to be carefully considered for every possible solution 657 approach. 659 7. Security Considerations 661 This document does not have any new specific security considerations. 663 8. IANA Considerations 665 This document does not have any new specific IANA considerations, 666 unless we decide to define a "special reserved IPv4 address". 668 9. Acknowledgements 670 The authors would like to acknowledge the inputs of Erik Nygren, Fred 671 Baker, Martin Hunek and TBD ... 673 10. References 675 10.1. Normative References 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, 679 DOI 10.17487/RFC2119, March 1997, 680 . 682 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 683 "DNS Extensions to Support IP Version 6", STD 88, 684 RFC 3596, DOI 10.17487/RFC3596, October 2003, 685 . 687 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 688 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 689 DOI 10.17487/RFC6052, October 2010, 690 . 692 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 693 NAT64: Network Address and Protocol Translation from IPv6 694 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 695 April 2011, . 697 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 698 Beijnum, "DNS64: DNS Extensions for Network Address 699 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 700 DOI 10.17487/RFC6147, April 2011, 701 . 703 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 704 Combination of Stateful and Stateless Translation", 705 RFC 6877, DOI 10.17487/RFC6877, April 2013, 706 . 708 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 709 and T. Murakami, "Mapping of Address and Port using 710 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 711 2015, . 713 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 714 Mappings for Stateless IP/ICMP Translation", RFC 7757, 715 DOI 10.17487/RFC7757, February 2016, 716 . 718 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 719 "IP/ICMP Translation Algorithm", RFC 7915, 720 DOI 10.17487/RFC7915, June 2016, 721 . 723 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 724 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 725 May 2017, . 727 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 728 Better Connectivity Using Concurrency", RFC 8305, 729 DOI 10.17487/RFC8305, December 2017, 730 . 732 10.2. Informative References 734 [I-D.huitema-quic-dnsoquic] 735 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 736 Iyengar, "Specification of DNS over Dedicated QUIC 737 Connections", draft-huitema-quic-dnsoquic-06 (work in 738 progress), March 2019. 740 [I-D.ietf-v6ops-nat64-deployment] 741 Palet, J., "Additional NAT64/464XLAT Deployment Guidelines 742 in Operator and Enterprise Networks", draft-ietf-v6ops- 743 nat64-deployment-06 (work in progress), May 2019. 745 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 746 and P. Hoffman, "Specification for DNS over Transport 747 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 748 2016, . 750 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 751 Transport Layer Security (DTLS)", RFC 8094, 752 DOI 10.17487/RFC8094, February 2017, 753 . 755 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 756 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 757 . 759 Authors' Addresses 761 Jordi Palet Martinez 762 The IPv6 Company 763 Molino de la Navata, 75 764 La Navata - Galapagar, Madrid 28420 765 Spain 767 Email: jordi.palet@theipv6company.com 768 URI: http://www.theipv6company.com/ 770 Alejandro D'Egidio 771 Telecentro 772 Argentina 774 Email: adegidio@telecentro.net.ar