idnits 2.17.1 draft-ietf-v6ops-464xlat-optimization-01.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 7, 2020) is 1389 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 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 8, 2021 Telecentro 6 July 7, 2020 8 464XLAT/NAT64 Optimization 9 draft-ietf-v6ops-464xlat-optimization-01 11 Abstract 13 This document proposes possible solutions to avoid certain drawbacks 14 of IP/ICMP Translation Algorithm (SIIT) when the destinations are 15 already available with IPv6. When SIIT is used as a stateless NAT46 16 and IPv4-only devices or applications initiate traffic flows to dual- 17 stack services (in the operator network or Internet), those flows 18 will be translated back to IPv4 by a NAT64. Avoiding this dual- 19 translation will significantly reduce the usage of the NAT64 and the 20 relevant logging, which may be a high impact when traffic flows are 21 towards CDNs, caches or similar resources. This is the case for 22 464XLAT and MAP-T. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 8, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Possible Optimization . . . . . . . . . . . . . . . . . . . . 3 61 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 7 64 5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 8 65 5.2.1. Detection of IPv4-only devices or applications . . . 8 66 5.2.2. Detection of IPv6-enabled service . . . . . . . . . . 8 67 5.2.3. Creation of EAMT entries . . . . . . . . . . . . . . 9 68 5.2.4. Forwarding path via stateful NAT for existing EAMT 69 entries . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.2.5. Maintenance of the EAMT entries . . . . . . . . . . . 11 71 5.2.6. Usage example . . . . . . . . . . . . . . . . . . . . 11 72 5.2.7. Behavior in case of multiple A/AAAA RRs . . . . . . . 11 73 5.2.8. Behavior in presence/absence of DNS64 . . . . . . . . 11 74 5.2.9. Behavior when using literal addresses or non 75 IPv6-compliant APIs . . . . . . . . . . . . . . . . . 12 76 5.2.10. False detection of a dual-stack host as IPv4-only . . 12 77 5.2.11. Behavior in presence of Happy Eyeballs . . . . . . . 12 78 5.2.12. Behavior in case of Foreign DNS . . . . . . . . . . . 13 79 5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 14 80 6. IPv6-only Services become accessible to IPv4-only 81 devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 15 82 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 11.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 Different transition mechanisms, typically in the group of the so- 94 called IPv6-only with IPv4aaS (IPv4-as-a-Service), such as 464XLAT 95 ([RFC6877]) or MAP-T ([RFC7599]), allow IPv4-only devices or 96 applications to connect with IPv4 services in Internet, by means of a 97 stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described by 98 [RFC7915]. 100 This is done by the implementation of SIIT at the CE (Customer Edge) 101 Router or sometimes at the end-device, for example, the UE (User 102 Equipment) in cellular networks. This functionality is the CLAT 103 (Customer Translator) in the case of 464XLAT, while in the case of 104 MAP-T is called NAT46. 106 The NAT46/CLAT (WAN side) is connected by IPv6-only to the operator 107 network, which in turn, will have a reverse translation, the NAT64 108 ([RFC6146]), known as PLAT (Provider Translator) in the case of 109 464XLAT. This allows to translate the IPv6-only flow back to IPv4, 110 in order to forward it to Internet. 112 In both cases (NAT46 and NAT64), the translation of the packet 113 headers is done using the IP/ICMP translation algorithm defined in 114 [RFC7915] and algorithmically translating the IPv4 addresses to IPv6 115 addresses following [RFC6052]. 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. Possible Optimization 127 In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge 128 of the synthesis of AAAA records from the A records, so they can use 129 a NAT64, without the need of doing a double-translation by means of 130 the NAT46/CLAT. 132 However, the DNS64 is not useful for the IPv4-only devices or 133 applications in the LANs, as they will not be able to use the AAAA 134 records, so they are always forced to use the double-translation. 136 This is the expected behavior, as the original design of NAT64 was 137 targeted to connect IPv6-only devices (using DNS) to IPv4-only 138 services. 464XLAT expanded the solution to also allow IPv4-only 139 devices (even if not using DNS) to connect to IPv4-only services by 140 means of IPv6-only access networks. 142 The optimization solutions presented by this document try to avoid 143 this double-translation, in the cases when the Internet services, are 144 already IPv6-enabled. So, in those cases, if the NAT46 already 145 translated the IPv4-only flow to IPv6, it doesn't look necessary to 146 translate this back to IPv6. 148 A typical 464XLAT deployment is depicted in Figure 1. 150 +-------+ .-----. .-----. 151 | IPv6 | / \ / \ 152 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 153 / \ | or +--( only )---( NAT64 )---( Internet ) 154 / LAN's \ | UE | \ Access /\ `-----' \ / 155 ( Dual- )--+ | \ / \ \ / 156 \ Stack / | with | `--+--' \ .-----. `-----' 157 \ / | NAT46 | | \ / \ 158 `-----' | CLAT | +---+----+ / IPv6 \ 159 | | | DNS/ | ( Internet ) 160 +-------+ | DNS64 | \ / 161 +--------+ \ / 162 `-----' 164 Figure 1: Typical 464XLAT Deployment 166 As it can be observed in the preceding picture, the situation is the 167 same, regardless of in case of a wired network with a CE Router or a 168 cellular network where a UE is connecting other devices (which may be 169 IPv4-only or have IPv4-only apps), by means of a tethering 170 functionality. 172 If the operator is providing direct access, for example, to Content 173 Delivery Networks (CDNs), caches, or other resources, and they are 174 dual-stacked, the situation can be described as shown in Figure 2. 176 +-------+ .-----. .-----. 177 | IPv6 | / \ / \ 178 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 179 / \ | or +--( only )---( NAT64 )---( Internet ) 180 / LAN's \ | UE | \ Access /\ `-----' \ / 181 ( Dual- )--+ | \ / \ \ / 182 \ Stack / | with | `--+--' \ .-----. `--+--' 183 \ / | NAT46 | | \ / \ \ 184 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 185 | | | DNS/ | ( Internet ) / Dual- \ 186 +-------+ | DNS64 | \ /----/ Stack \ 187 +--------+ \ / ( ) 188 `-----' \ CDNs/ / 189 \ Caches/ 190 `-----' 192 Figure 2: Typical 464XLAT Deployment with CDNs/Caches 194 In this case if the flows initiated in the LANs come from IPv4-only 195 devices or applications, even if the destination resources are 196 IPv6-enabled, the double-translation is enforced, which has the 197 following consequences: 199 o More traffic needs to pass thru the NAT64 devices. 201 o More NAT64 devices may be needed to handle the additional traffic. 203 o Additional usage of IPv4 addresses. 205 o Additional state at the NAT64 devices. 207 o Additional logging, its relevant storage and processing resources. 209 Clearly, all those aspects have impact in both, CapEx and OpEx. This 210 is extremely important when considering that most of the time, the 211 contents stored in CDNs, caches, and so on, is there for a good 212 reason: It is frequently accessed resources and/or big. Examples 213 such as video, audio, software and updates, are very common. So, 214 this optimization can be highly impacting in many networks. 216 4. Problem Statement 218 If the devices or applications in the customer LAN are IPv6-capable, 219 then the access to the CDNs, caches or other resources, will be made 220 in an optimized way, by means of IPv6-only, not using the NAT64, as 221 depicted in Figure 3. 223 +-------+ .-----. .-----. 224 | IPv6 | / \ / \ 225 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 226 / \ | or +--( only )---( NAT64 )---( Internet ) 227 / IPv6 \ | UE | \ Access /\ `-----' \ / 228 ( capable )--+ | \ / \ \ / 229 \ apps / | with | `--+--' \ .-----. `--+--' 230 \ / | NAT46 | | \ / \ 231 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 232 | | | DNS/ | ( Internet )IPv6/ Dual- \ 233 +-------+ | DNS64 | \ /----/ Stack \ 234 +--------+ \ / ( ) 235 `-----' \ CDNs/ / 236 \ Caches/ 237 `-----' 238 <---------------------- end-to-end IPv6 flow ----------------------> 240 Figure 3: 464XLAT access to CDNs/Caches by IPv6-capable apps 242 However, if the devices or applications are IPv4-only, for example, 243 many SmartTVs and Set-Top-Boxes available today, a non-optimal double 244 translation will occur (NAT46 at the CLAT and NAT64 at the PLAT), as 245 illustrated in Figure 4. 247 +-------+ .-----. .-----. 248 | IPv6 | / \ / \ 249 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 250 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 251 / only \ | UE | \ Access /\ `-----' \ / 252 ( SmartTV )--+ | \ / \ \ / 253 \ STB / | with | `--+--' \ .-----. `--+--' 254 \ VoIP / | NAT46 | | \ / \ \ IPv4 255 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 256 | | | DNS/ | ( Internet ) / Dual- \ 257 +-------+ | DNS64 | \ / / Stack \ 258 +--------+ \ / ( ) 259 `-----' \ CDNs/ / 260 \ Caches/ 261 `-----' 262 <-------------------- IPv4 to IPv6 to IPv4 flow --------------------> 264 Figure 4: 464XLAT access to CDNs/Caches by IPv4-only apps 266 Clearly, this is a non-optimal situation, as it means that even if 267 there is a dual-stack service, the NAT46/CLAT translated IPv4 to IPv6 268 traffic flow, is unnecessarily translated back to IPv4, traversing 269 the stateful NAT64. This has a direct impact in the need to scale 270 the NAT64 beyond what will be actually needed if possible solutions, 271 in order to keep using the IPv6 path towards those services, are 272 considered. 274 As shown in the Figure 4, this is also the case for many other 275 services, not just CDNs or caches, such as VoIP access to the 276 relevant operator infrastructure, which may be also dual-stack. This 277 is true as well for many other dual-stack or IPv6-enabled services, 278 which may be directly reachable from the operator infrastructure, 279 even if they are not part of it, for example peering agreements, 280 services in IXs, etc. In general, this will become a more frequent 281 situation for many other services, which are not yet dual-stack. 283 For simplicity, across the rest of this document, references to CDNs/ 284 caches, should be understood, unless otherwise stated, as any dual- 285 stacked resources. 287 This document looks into different possible solution approaches in 288 order to optimize the IPv4-only SIIT translation providing a direct 289 path to IPv6-capable services, as depicted in Figure 5. 291 +-------+ .-----. .-----. 292 | IPv6 | / \ / \ 293 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 294 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 295 / only \ | UE | \ Access /\ `-----' \ / 296 ( SmartTV )--+ | \ / \ \ / 297 \ STB / | with | `--+--' \ .-----. `--+--' 298 \ VoIP / | NAT46 | | \ / \ 299 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 300 | | | DNS/ | ( Internet )IPv6/ Dual- \ 301 +-------+ | DNS64 | \ /----/ Stack \ 302 +--------+ \ / ( ) 303 `-----' \ CDNs/ / 304 \ Caches/ 305 `-----' 306 <------------------------ IPv4 to IPv6 flow ------------------------> 308 Figure 5: Optimized 464XLAT access to CDNs/Caches by IPv4-only apps 310 5. Solution Approaches 312 5.1. Approach 1: DNS/Routing-based Solution 314 Because the IPv4-only devices will not be able to query for AAAA 315 records, the NAT46/CLAT/CE will translate the IPv4 addresses from the 316 A record for the CDN/cache destination, using the WKP or NSP, as 317 configured by the operator. 319 If the CDN/cache provider is able to configure, in the relevant 320 interfaces of the CDN/caches, the same IPv6 addresses that will 321 naturally result as the translated destination addresses for the 322 queried A records, preceded by the WKP or NSP, then having more 323 specific routing prefixes, will result in traffic to those 324 destinations being directly forwarded towards those interfaces, 325 instead of needing to traverse the NAT64. 327 For example, let's suppose a provider using the WKP (64:ff9b::/96) 328 and a SmartTV querying for www.example.com: 330 www.example.com A 192.0.2.1 331 NAT46/CLAT translated to 64:ff9b::192.0.2.1 332 CDN IPv6 interface must be 64:ff9b::192.0.2.1 333 Operator must have a specific route to 64:ff9b::192.0.2.1 335 Note: Examples using text representation as per Section 2.3 of 336 [RFC6052] and IPv4 documentation addresses following [RFC5737]. 338 Because the WKP is non-routable, this solution will only be possible 339 if the CDN/cache is in the same ASN as the provider network, or 340 somehow interconnected without routing thru Internet. 342 This solution has the additional drawback of the operational 343 complexity/issues added to the operation of the CDN/cache, and the 344 need to synchronize any IPv4 interface address changes with the 345 relevant IPv6 ones, and possibly with routing. 347 5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution 349 If the NAT46/CLAT/CE, as commonly is the case, is also a DNS proxy/ 350 stub resolver, it is possible to modify the behavior and create an 351 "internal" interaction among both of them. 353 This approach uses the existing IPv4 and IPv6 addresses in the A and 354 AAAA records, respectively, so no additional complexity/issues added 355 to the CDN/caches operations. 357 The following sub-sections detail this approach and provide a step- 358 by-step example case. 360 5.2.1. Detection of IPv4-only devices or applications 362 The assumption is that, typically a dual-stack device will prefer 363 using IPv6 as the DNS transport. So, when there is a DNS query, 364 transported with IPv4, for an A record, and there is not a query for 365 the AAAA record from the same IPv4 source (to the same destination), 366 the DNS proxy/stub resolver can infer that, most probably, it is an 367 IPv4-only device or application. 369 It needs to be remarked that, if the detection of the IPv4-only 370 device or application is done incorrectly (either not detecting it or 371 by a false detection), no harm is caused. In the worst case, 372 optimization will not be performed, at least, at the time being. 373 However, optimization maybe performed later on, if a new detection 374 succeeds (for example, another device using the same A record). 376 5.2.2. Detection of IPv6-enabled service 378 In the case of an IPv4-only detected device or application, the DNS 379 proxy/stub resolver MUST actually perform an additional AAAA query, 380 unless the information is already present in the Additional Section, 381 as per Section 3 of [RFC3596]. Note that the NAT46/CLAT MUST already 382 know the WKP or NSP being used in that network. If the response 383 contains at least one IPv6 address not using the WKP/NSP, it means 384 that the destination is IPv6-enabled (because at least one of the 385 IPv6 addresses is not synthesized). This means that it is possible 386 for the NAT46/CLAT, to create an Explicit Address Mapping 387 ([RFC7757]). 389 5.2.3. Creation of EAMT entries 391 This way, an EAM Table (EAMT used for short, across the rest of this 392 document) is created/maintained automatically by the DNS proxy/stub 393 resolver in the NAT46/CLAT, and the NAT46/CLAT is responsible to 394 prioritize any available entries in the EAMT, versus the use of any 395 synthetic AAAA. 397 In order to create the EAMT entry, to determine if there is an AAAA 398 record after an A record query, it is suggested to use the same delay 399 value (50 milliseconds) as the "Resolution Delay" indicated by Happy 400 Eyeballs [RFC8305]. This avoids a slight NAT64 overload and flapping 401 between destination addresses (IPv4/IPv6), which may impact some 402 applications, at the cost of a small extra delay for the initial 403 communication setup, when the EAMT entry doesn't yet exist. 405 Each EAMT entry will contain, the fields already described in 406 [RFC7757] and a few new ones: 408 1. ID: EAMT Entry Index (optional). 410 2. IPv4 address/prefix: By default, the prefix length is 32 bits. 412 3. IPv6 address/prefix: By default, the prefix length is 128 bits. 414 4. TTL: Because the optimization will make use of the AAAA (IPv6 415 address), the TTL for the EAMT entry must set to the same value 416 as in the AAAA RR. In normal conditions the TTL for both A and 417 AAAA records, of a given FQDN, should be the same, so this 418 ensures a proper behavior if there is any DNS mismatch. 420 5. FQDN: The one that originated the A query for this EAMT entry. 421 Required in order to ensure a correct detection of cases such as 422 the use of reverse-proxy with a single IPv4 address to multiple 423 IPv6 addresses. 425 6. Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT 426 be used and consequently no optimization performed. It may be 427 used also for an explicit configuration (GUI, CLI, provisioning 428 system, etc.) to disallow optimization for explicitly configured 429 IPv4 addresses. 431 7. Auto/Static: When set to 1, means that this EAMT entry has been 432 manually/statically configured, for example by means of an 433 explicit configuration (GUI, CLI, provisioning system, etc.), so 434 it doesn't expire with TTL. 436 When a new EAMT entry is first automatically created, it is marked as 437 "Valid" and "Auto" (both bits cleared). If a subsequent A query, 438 with a different FQDN, results in an IPv4 address that has already an 439 EAMT entry and a different IPv6 address, it means that some reverse- 440 proxy or similar functionality is being used by the IPv6-enabled 441 service. In this case, the existing EAMT entry will be marked as 442 "Invalid" (bit set). No new EAMT entry is created for that IPv4 443 address. Otherwise, the optimization will only allow to access the 444 first set of IPv4/IPv6/FQDN, which may break the access to other FQDN 445 that share the same IPv4 address and different IPv6 addresses. 447 In this case the EAMT entry will still expire according the TTL, 448 which allows to re-enable optimization if a new query for the A 449 record has changed the situation. For example, maybe the reverse- 450 proxy has been removed, or there is now only a single device using 451 it, so at the time being, the optimization is again possible without 452 creating troubles to other hosts. 454 Note that when an EAMT entry is marked as "invalid", it will not 455 affect the devices or applications, as they will still be able to use 456 the regular CLAT+NAT64 flow, of course, without the optimization. 458 Note the newly defined EAMT fields, follow the "extensions" approach 459 as per section 3.1 of [RFC7757]. 461 5.2.4. Forwarding path via stateful NAT for existing EAMT entries 463 Following this approach, if there is a valid EAMT entry, for a given 464 IPv4-destination, the IPv6-native path pointed by the IPv6 address of 465 that EAMT entry, will take precedence versus the NAT64 path, so the 466 traffic will not be forwarded to the NAT64. 468 However, this is not sufficient to ensure that individual 469 applications are able to keep existing connections. In many cases, 470 audio and video streaming may use a single TCP connection lasting 471 from minutes to hours. Instead, the CDN TTLs may be configured in 472 the range from 10 to 300 seconds in order to allow new resolutions to 473 switch quickly and to handle large recursive resolvers (with hundreds 474 of thousands of clients behind them). 476 Consequently, the EAMT entries should not be used directly to 477 establish a forwarding path, but instead, to create a stateful NAT 478 entry for the 4-tuple for the duration of the session/connection. 480 5.2.5. Maintenance of the EAMT entries 482 The information in the EAMT MUST be kept timely-synchronized with the 483 AAAA records TTL's, so the EAMT entries MUST expire on the AAAA TTL 484 expiry and consequently be deleted. 486 However, EAMT entries with the Auto/Static bit set, will not be 487 deleted. This allows users/operators to set explicit rules for 488 diagnostics or resolution of issues in special situations. 490 5.2.6. Usage example 492 Using the same example as in the previous approach: 494 www.example.com A 192.0.2.1 495 AAAA 2001:db8::a:b:c:d 496 EAMT entry 192.0.2.1 2001:db8::a:b:c:d 497 NAT46/CLAT translated to 2001:db8::a:b:c:d 498 CDN IPv6 interface already is 2001:db8::a:b:c:d 499 Operator already has a specific route to 2001:db8::a:b:c:d 501 The following is an example of the CE behavior after the previous 502 case has already created an EAMT entry and a reverse-proxy is 503 detected: 505 1. A query for www.another-example.com A RR is received 507 2. www.another-example.com A 192.0.2.1 509 3. www.another-example.com AAAA 2001:db8::e:e:f:f 511 4. A conflict has been detected 513 5. The existing EAMT entry for 192.0.2.1 is set as invalid 515 5.2.7. Behavior in case of multiple A/AAAA RRs 517 If multiple A and/or AAAA records are available, the DNS proxy/stub 518 resolver MUST follow existing procedures to choose each one. In 519 other words, the chosen pair of A/AAAA records doesn't present any 520 different result compared with a situation when this mechanism is not 521 used. 523 5.2.8. Behavior in presence/absence of DNS64 525 This optimization performs the same in both cases: if a DNS64 is 526 present/used or if it is not present/used. This is explained because 527 the optimization is only relevant for destinations which already have 528 AAAA records, and in those cases DNS64 is not relevant. Furthermore, 529 because as indicated in Section 5.2.2, the EAMT entry is not created 530 when the service is IPv6-enabled. This is relevant because 464XLAT 531 can be deployed/used with and without a DNS64. 533 5.2.9. Behavior when using literal addresses or non IPv6-compliant APIs 535 Because the EAMT entries are only created when the NAT46/CLAT/CE 536 proxy/stub DNS is being used, any devices or applications that don't 537 use DNS, will not create the relevant entries. 539 They maybe optimized if devices or applications using DNS, at some 540 point, query for the same A RRs, or if EAMT entries are statically 541 configured. 543 5.2.10. False detection of a dual-stack host as IPv4-only 545 If a dual-stack host is issuing the A query using IPv4 transport, and 546 the AAAA query using IPv6 transport, or using different IPv4 547 addresses for the A and AAAA queries, the EAMT entry will be created. 548 However, this EAMT entry may not be used by dual-stack devices or 549 applications, because those devices or applications should prefer 550 IPv6. If the host is preferring IPv4 for connecting to the CDN/cache 551 or IPv6-enabled service, it will be actually using the NAT46/CLAT, 552 including the EAMT entry and consequently IPv6, so this mechanism 553 will be correcting an undesirable behavior. This is a special case, 554 which actually seems to be an incoherent host or application 555 implementation. 557 However, if other IPv4-only devices or applications subsequently need 558 to connect to the same IPv6-enabled service, they will take advantage 559 of the already existing EAMT entry, and consequently use the 560 IPv6-optimised path. 562 5.2.11. Behavior in presence of Happy Eyeballs 564 Happy Eyeballs [RFC8305] is only available in dual-stack hosts. 565 Consequently, is not affected by this mechanism because both, the A 566 and the AAAA queries should be issued by the host as soon after one 567 another as possible. However, if the same NAT46/CLAT/CE is serving 568 IPv4-only hosts and dual-stack hosts and both of them are using the 569 same destinations, an EAMT entry will be created for that 570 destination. Consequently, a Happy Eyeballs fallback to IPv4 will 571 actually be using the relevant EAMT entry IPv6 destination. This has 572 the disadvantage that the IPv4-IPv6-IPv4 translation path can't be 573 used by Happy Eyeballs-enabled applications. However, this may be 574 actually considered as a good thing, in the sense that an operator is 575 interested in knowing as soon as possible, if the IPv6-only network 576 is not performing correctly, because that means also IPv4 will not be 577 working. If the issue is related to extra IPv6 delay versus the IPv4 578 delay, Happy Eyeballs will not be able to offer a significative 579 advantage here, but it looks like an acceptable trade-off. 581 Note that when using 464XLAT, the WAN link of the NAT46/CLAT/CE is 582 IPv6-only. So even if Happy Eyeballs is present, the fallback to 583 IPv4-only typically, will be slower than native IPv6 itself, because 584 the added delay in the NAT46+NAT64 translations, when not using this 585 optimization. 587 5.2.12. Behavior in case of Foreign DNS 589 Devices or applications may use DNS servers from other networks. For 590 a complete description of reasons for that, refer to Section 4.4 of 591 [RFC8683]. In the case the DNS is modified, or some devices or 592 applications use other DNS servers, the possible scenarios and the 593 implications are: 595 a. Devices configured to use a DNS proxy/resolver which is not the 596 CE/NAT46/CLAT. In this case this optimization will not work, 597 because the EAMT entry will not be created based on their own 598 flows. Nevertheless, the EAMT entry may be created by other 599 devices using the same destinations. However, the lack of EAMT 600 entry, will not impact negatively in the user's devices/ 601 applications (the optimization is not performed). It should be 602 noticed that users commonly, don't change the configuration of 603 devices such as SmartTVs or STBs (if they do, some other 604 functionalities, such as CDN/caches optimizations may not work as 605 well), so this only happens typically if the vendor is doing it 606 on-purpose and for good well-known reasons. 608 b. DNS privacy/encryption. Hosts or applications that use 609 mechanisms for DNS privacy/encryption, such as DoT ([RFC7858], 610 [RFC8094]), DoH ([RFC8484]) or DoQ 611 ([I-D.huitema-dprive-dnsoquic]), will not make use of the stub/ 612 proxy resolver, so the same considerations as for the previous 613 case apply. 615 c. Users that modify the DNS in their Operating Systems. This is 616 quite frequent, however commonly Operating Systems are dual- 617 stack, so aren't part of the problem statement described by this 618 document and will not be adversely affected. 620 d. Users that modify the DNS in the CE. This is less common. In 621 this case, this optimization is not adversely affected, because 622 it doesn't depend on the operator DNS, it works only based on the 623 internal CE interaction between the NAT46/CLAT and the stub/proxy 624 resolver. Note that it may be affected if the operator offers 625 different "DNS views" or "split DNS", however this is not related 626 to this optimization and will anyway impact in the other possible 627 operator optimizations (i.e. CDN/cache features). 629 e. Combinations of the above ones. No further impact, than the one 630 already described, is observed. 632 5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution 634 Instead of using the DNS proxy/stub resolver to create the EAMT 635 entries, the operator may push this table (or parts of it) into the 636 CE/NAT46/CLAT, by using configuration/management mechanisms. 638 This solution has the advantage of not being affected by any DNS 639 changes from the user (the EAMT is created by the operator) and 640 ensures a complete control from the operator. However, it may impact 641 the cases of devices with a DNS configured by the vendor. 643 In general, most of the considerations from the previous approach 644 will apply. 646 One more advantage of this solution is that the EAMT pairs doesn't 647 need to match the "real" IPv4/IPv6 addresses available in the A/AAAA 648 records, as shown in the next example. 650 www.example.com A 192.0.2.1 651 AAAA 2001:db8::a:b:c:d 652 EAMT pulled/pushed entry 192.0.2.1 2001:db8::f:e:d:c 653 NAT46/CLAT translated to 2001:db8::f:e:d:c 654 CDN IPv6 interface already is 2001:db8::f:e:d:c 655 Operator already has a specific route to 2001:db8::f:e:d:c 657 EAMT may contain TTLs which probably are derived from DNS ones, or 658 alternatively, a global TTL for the full table. 660 An alternative way to configure the table, is that the CE is actually 661 pulling the table (or parts of it) from the operator infrastructure. 662 In this case it will be mandatory that the entries have individual 663 TTLs, again probably derived from the DNS ones. 665 The major drawback of this approach is that it requires a new 666 protocol, or an extension to existing ones, in order to push or pull 667 the EAMT, in addition to the possible impact in terms of bandwidth 668 each time the CEs reboot, or an EAMT must be pushed to all the CEs, 669 etc. 671 6. IPv6-only Services become accessible to IPv4-only devices/apps 673 One of the issues with the IPv6 deployment, is that those services 674 which become IPv6-only in Internet, aren't reachable by IPv4-only 675 devices and applications. This means that new content providers must 676 support dual-stack even for new services, even while IPv4 public 677 addresses aren't available. 679 If NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) is chosen, it also 680 offers the chance to resolve this issue. This is possible if 681 IPv6-only services get configured with an A resource record pointing 682 to a well-known IPv4 address despite they aren't actually connected 683 to IPv4. This is out of scope for this document, as it will require 684 further work and a reservation by IANA, This will mean that those 685 services will work fine if there is a NAT46/CLAT supporting the 686 optimization. This A RR has no negative impact if the NAT46/CLAT 687 doesn't exist, or it is not optimized, because is not reachable via 688 IPv4-only, so is not a different situation compared with not having 689 an A RR. 691 The result of this is equivalent to the approach taken by MAP-T 692 (Section 12.3 of [RFC7599]). However, it has the advantage that the 693 MAP-T approach is restricted to services in the MAP-T domain. 695 In fact, it may become an incentive for the IPv6 deployment in 696 Internet services, as it provides the option to use a well-known IPv4 697 address (maybe anycast) for the "non-valid" A RR, that points, in 698 case of port 80/443 to a web page or service that returns a warning 699 such as "This service is only available if the network is properly 700 connected to Internet with IPv6". 702 7. Conclusions 704 NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) seems the right 705 solution for optimizing the access to dual-stack services, whether 706 they are located inside or outside the ISP. It is also the only 707 approach which has no additional requirements for the network 708 operators (both ISPs and CDN/cache operators). 710 Having this type of optimization facilitates and increases the usage 711 of IPv6, even for IPv4-only devices and applications, at the same 712 time that decreases the use of the NAT64. 714 SIIT already has a SHOULD for EAM support, so it is not a high 715 additional burden the support required for existing implementations 716 to be updated for this optimization. 718 8. Security Considerations 720 This document does not have any new specific security considerations, 721 besides the ones already known for DNS64. 723 9. IANA Considerations 725 This document does not have any new specific IANA considerations. 727 10. Acknowledgements 729 The authors would like to acknowledge the inputs of Erik Nygren, Fred 730 Baker, Martin Hunek, Chongfeng Xie, Fernando Gont, Fernando Frediani 731 and TBD ... 733 11. References 735 11.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 739 DOI 10.17487/RFC2119, March 1997, 740 . 742 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 743 "DNS Extensions to Support IP Version 6", STD 88, 744 RFC 3596, DOI 10.17487/RFC3596, October 2003, 745 . 747 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 748 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 749 DOI 10.17487/RFC6052, October 2010, 750 . 752 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 753 NAT64: Network Address and Protocol Translation from IPv6 754 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 755 April 2011, . 757 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 758 Beijnum, "DNS64: DNS Extensions for Network Address 759 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 760 DOI 10.17487/RFC6147, April 2011, 761 . 763 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 764 Combination of Stateful and Stateless Translation", 765 RFC 6877, DOI 10.17487/RFC6877, April 2013, 766 . 768 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 769 and T. Murakami, "Mapping of Address and Port using 770 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 771 2015, . 773 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 774 Mappings for Stateless IP/ICMP Translation", RFC 7757, 775 DOI 10.17487/RFC7757, February 2016, 776 . 778 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 779 "IP/ICMP Translation Algorithm", RFC 7915, 780 DOI 10.17487/RFC7915, June 2016, 781 . 783 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 784 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 785 May 2017, . 787 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 788 Better Connectivity Using Concurrency", RFC 8305, 789 DOI 10.17487/RFC8305, December 2017, 790 . 792 11.2. Informative References 794 [I-D.huitema-dprive-dnsoquic] 795 Huitema, C., Mankin, A., and S. Dickinson, "Specification 796 of DNS over Dedicated QUIC Connections", draft-huitema- 797 dprive-dnsoquic-00 (work in progress), March 2020. 799 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 800 Reserved for Documentation", RFC 5737, 801 DOI 10.17487/RFC5737, January 2010, 802 . 804 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 805 and P. Hoffman, "Specification for DNS over Transport 806 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 807 2016, . 809 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 810 Transport Layer Security (DTLS)", RFC 8094, 811 DOI 10.17487/RFC8094, February 2017, 812 . 814 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 815 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 816 . 818 [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for 819 NAT64/464XLAT in Operator and Enterprise Networks", 820 RFC 8683, DOI 10.17487/RFC8683, November 2019, 821 . 823 Authors' Addresses 825 Jordi Palet Martinez 826 The IPv6 Company 827 Molino de la Navata, 75 828 La Navata - Galapagar, Madrid 28420 829 Spain 831 Email: jordi.palet@theipv6company.com 832 URI: http://www.theipv6company.com/ 834 Alejandro D'Egidio 835 Telecentro 836 Argentina 838 Email: adegidio@telecentro.net.ar