idnits 2.17.1 draft-ietf-v6ops-464xlat-optimization-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 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 11, 2020) is 1385 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 12, 2021 Telecentro 6 July 11, 2020 8 464XLAT/NAT64 Optimization 9 draft-ietf-v6ops-464xlat-optimization-02 11 Abstract 13 IP/ICMP Translation Algorithm (SIIT) can be used to provide access 14 for IPv4-only devices or applications to IPv4-only or dual-stack 15 destinations over IPv6-only infrastructure. In that case, the 16 traffic flows are translated twice: first from IPv4 to IPv6 17 (stateless NAT46 at the ingress point to the IPv6-only 18 infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at 19 the egress point). When the destination is IPv6-enabled, the second 20 translation might be avoided. This document describes a possible 21 optimization to 464XLAT and MAP-T to avoid translating IPv6 flows 22 back to IPv4 if the destination is reachable over IPv6. The proposed 23 solution would significantly reduce the NAT64 utilization in the 24 operator's network. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 12, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Possible Optimization . . . . . . . . . . . . . . . . . . . . 3 63 4. Problem Statement Summary . . . . . . . . . . . . . . . . . . 5 64 5. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 7 66 5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 8 67 5.2.1. Detection of IPv4-only hosts or applications . . . . 9 68 5.2.2. Detection of IPv6-enabled service . . . . . . . . . . 9 69 5.2.3. Creation of EAMT entries . . . . . . . . . . . . . . 9 70 5.2.4. Forwarding path via stateful NAT for existing EAMT 71 entries . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.2.5. Maintenance of the EAMT entries . . . . . . . . . . . 11 73 5.2.6. Usage example . . . . . . . . . . . . . . . . . . . . 11 74 5.2.7. Behavior in case of multiple A/AAAA RRs . . . . . . . 12 75 5.2.8. Behavior in presence/absence of DNS64 . . . . . . . . 12 76 5.2.9. Behavior when using literal addresses or non 77 IPv6-compliant APIs . . . . . . . . . . . . . . . . . 12 78 5.2.10. Behavior in case of Foreign DNS . . . . . . . . . . . 12 79 5.2.11. False detection of a dual-stack host as IPv4-only . . 13 80 5.2.12. Behavior in presence of Happy Eyeballs . . . . . . . 14 81 5.2.13. Troubleshooting Implications . . . . . . . . . . . . 16 82 5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 16 83 6. IPv6-only Services become accessible to IPv4-only 84 devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 17 85 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 11.2. Informative References . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 Different transition mechanisms, typically in the group of the so- 97 called IPv6-only with IPv4aaS (IPv4-as-a-Service), such as 464XLAT 98 ([RFC6877]) or MAP-T ([RFC7599]), allow IPv4-only devices or 99 applications to connect with IPv4 services in Internet over IPv6-only 100 infrastructure, by means of a stateless NAT46 SIIT (IP/ICMP 101 Translation Algorithm) as described by [RFC7915]. 103 This is done by the implementation of SIIT at the CE (Customer Edge) 104 Router or sometimes at the end-device, for example, the UE (User 105 Equipment) in cellular networks. This functionality is the CLAT 106 (Customer Translator) in the case of 464XLAT, while in the case of 107 MAP-T is called NAT46. 109 The NAT46/CLAT (WAN side) is connected by IPv6-only to the operator 110 network, which in turn, will have a reverse translation, the NAT64 111 ([RFC6146]), known as PLAT (Provider Translator) in the case of 112 464XLAT. This allows to translate the IPv6 flow back to IPv4, in 113 order to forward it to Internet. 115 In both cases (NAT46 and NAT64), the translation of the packet 116 headers is done using the IP/ICMP translation algorithm defined in 117 [RFC7915]. Translation between IPv4 and IPv6 addresses is done as 118 per [RFC6052]. The NAT64 prefix should be discovered by the CE by 119 one or more of the existing mechanisms ([RFC7225], [RFC8781] or 120 [RFC7050]), and sometimes it is pre-configured at the CE to the WKP. 122 2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Possible Optimization 132 In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge 133 of the synthesis of AAAA records from the A records, so the NAT64 can 134 be used without the need of doing a double-translation by means of 135 the NAT46/CLAT. 137 However, the DNS64 is not useful for the IPv4-only devices or 138 applications in the LANs, as they will not be able to use the AAAA 139 records, so they are always forced to use the double-translation. 141 This is the expected behavior, as the original design of NAT64 was 142 targeted to connect IPv6-only devices (using DNS) to IPv4-only 143 services. 464XLAT expanded the solution to also allow IPv4-only 144 devices (even if not using DNS) to connect to IPv4-only services by 145 means of IPv6-only access networks. 147 The optimization solutions presented by this document try to avoid 148 this double-translation, in the cases when the Internet services, are 149 already IPv6-enabled. So, in those cases, if the NAT46 already 150 translated the IPv4 flow to IPv6, it doesn't look necessary to 151 translate this back to IPv6. 153 A typical 464XLAT deployment is depicted in Figure 1. 155 +-------+ .-----. .-----. 156 | IPv6 | / \ / \ 157 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 158 / \ | or +--( only )---( NAT64 )---( Internet ) 159 / Dual- \ | UE | \ Access /\ `-----' \ / 160 ( Stack )--+ | \ / \ \ / 161 \ LAN's / | with | `--+--' \ .-----. `-----' 162 \ / | NAT46 | | \ / \ 163 `-----' | CLAT | +---+----+ / IPv6 \ 164 | | | DNS/ | ( Internet ) 165 +-------+ | DNS64 | \ / 166 +--------+ \ / 167 `-----' 169 Figure 1: Typical 464XLAT Deployment 171 Examples of a topology shown on the above picture includes: 173 o An IPv6-only residential access network where the CE Router (with 174 NAT46/CLAT) supports Dual-Stack in the customer LANs. 176 o An IPv6-only cellular network where a UE uses the NAT46/CLAT for 177 dual-stack internal applications and other devices connected via 178 tethering. 180 If the operator is providing direct access, for example, to Content 181 Delivery Networks (CDNs), caches, or other resources, and they are 182 dual-stacked, the situation can be described as shown in Figure 2. 184 +-------+ .-----. .-----. 185 | IPv6 | / \ / \ 186 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 187 / \ | or +--( only )---( NAT64 )---( Internet ) 188 / Dual- \ | UE | \ Access /\ `-----' \ / 189 ( Stack )--+ | \ / \ \ / 190 \ LAN's / | with | `--+--' \ .-----. `--+--' 191 \ / | NAT46 | | \ / \ \ 192 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 193 | | | DNS/ | ( Internet ) / Dual- \ 194 +-------+ | DNS64 | \ /----/ Stack \ 195 +--------+ \ / ( ) 196 `-----' \ CDNs/ / 197 \ Caches/ 198 `-----' 200 Figure 2: Typical 464XLAT Deployment with CDNs/Caches 202 In this case if the flows initiated in the LANs come from IPv4-only 203 devices or applications, even if the destination resources are 204 IPv6-enabled, the double-translation is enforced, which has the 205 following consequences: 207 o More traffic needs to pass thru the NAT64 devices. 209 o More NAT64 devices may be needed to handle the additional traffic. 211 o Additional usage of IPv4 addresses. 213 o Additional state at the NAT64 devices. 215 o Additional logging, its relevant storage and processing resources. 217 Clearly, all those aspects have impact in both, CapEx and OpEx. This 218 is extremely important when considering that most of the time, the 219 contents stored in CDNs, caches, and so on, is there for a good 220 reason: It is frequently accessed resources and/or big. Examples 221 such as video, audio, software and updates, are very common. So, 222 this optimization can be highly impacting in many networks. 224 4. Problem Statement Summary 226 If the devices or applications in the customer LAN are IPv6-capable, 227 then the access to the CDNs, caches or other resources, will be made 228 in an optimized way, by means of IPv6-only, not using the NAT64, as 229 depicted in Figure 3. 231 +-------+ .-----. .-----. 232 | IPv6 | / \ / \ 233 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 234 / \ | or +--( only )---( NAT64 )---( Internet ) 235 / IPv6 \ | UE | \ Access /\ `-----' \ / 236 ( capable )--+ | \ / \ \ / 237 \ apps / | with | `--+--' \ .-----. `-----' 238 \ / | NAT46 | | \ / \ 239 `-----' | CLAT | +---+----+ / IPv6 \ .-----. 240 | | | DNS/ | ( Internet )IPv6/ Dual- \ 241 +-------+ | DNS64 | \ /----/ Stack \ 242 +--------+ \ / ( ) 243 `-----' \ CDNs/ / 244 \ Caches/ 245 `-----' 246 <---------------------- end-to-end IPv6 flow ----------------------> 248 Figure 3: 464XLAT access to CDNs/Caches by IPv6-capable apps 250 However, if the devices or applications are IPv4-only, for example, 251 many SmartTVs and Set-Top-Boxes available today, a non-optimal double 252 translation will occur (NAT46 at the CLAT and NAT64 at the PLAT), as 253 illustrated in Figure 4. 255 +-------+ .-----. .-----. 256 | IPv6 | / \ / \ 257 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 258 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 259 / only \ | UE | \ Access /\ `-----' \ / 260 ( SmartTV )--+ | \ / \ \ / 261 \ STB / | with | `--+--' \ .-----. `--+--' 262 \ VoIP / | NAT46 | | \ / \ \ IPv4 263 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 264 | | | DNS/ | ( Internet ) / Dual- \ 265 +-------+ | DNS64 | \ / / Stack \ 266 +--------+ \ / ( ) 267 `-----' \ CDNs/ / 268 \ Caches/ 269 `-----' 270 <-------------------- IPv4 to IPv6 to IPv4 flow --------------------> 272 Figure 4: 464XLAT access to CDNs/Caches by IPv4-only apps 274 Clearly, this is a non-optimal situation, as it means that even if 275 there is a dual-stack service, the NAT46/CLAT translated IPv4 to IPv6 276 traffic flow, is unnecessarily translated back to IPv4, traversing 277 the stateful NAT64. This has a direct impact in the need to scale 278 the NAT64 beyond what will be actually needed, if possible solutions, 279 in order to keep using the IPv6 path towards those services, are 280 considered. 282 As shown in the Figure 4, this is also the case for many other 283 services, not just CDNs or caches, such as VoIP access to the 284 relevant operator infrastructure, which may be also dual-stack. This 285 is true as well for many other dual-stack or IPv6-enabled services, 286 which may be directly reachable from the operator infrastructure, 287 even if they are not part of it, for example peering agreements, 288 services in IXs, etc. In general, this will become a more frequent 289 situation for many other services, which are not yet dual-stack. 291 For simplicity, across the rest of this document, references to CDNs/ 292 caches, should be understood, unless otherwise stated, as any dual- 293 stacked resources. 295 This document looks into different possible solution approaches in 296 order to optimize the IPv4-only SIIT translation providing a direct 297 path to IPv6-capable services, as depicted in Figure 5. 299 +-------+ .-----. .-----. 300 | IPv6 | / \ / \ 301 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 302 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 303 / only \ | UE | \ Access /\ `-----' \ / 304 ( SmartTV )--+ | \ / \ \ / 305 \ STB / | with | `--+--' \ .-----. `-----' 306 \ VoIP / | NAT46 | | \ / \ 307 `-----' | CLAT | +---+----+ / IPv6 \ .-----. 308 | | | DNS/ | ( Internet )IPv6/ Dual- \ 309 +-------+ | DNS64 | \ /----/ Stack \ 310 +--------+ \ / ( ) 311 `-----' \ CDNs/ / 312 \ Caches/ 313 `-----' 314 <------------------------ IPv4 to IPv6 flow ------------------------> 316 Figure 5: Optimized 464XLAT access to CDNs/Caches by IPv4-only apps 318 5. Solution Approaches 320 5.1. Approach 1: DNS/Routing-based Solution 322 Because the IPv4-only devices will not be able to query for AAAA 323 records, the NAT46/CLAT/CE will translate the IPv4 addresses from the 324 A record for the CDN/cache destination, using the WKP or NSP, as 325 configured by the operator. 327 If the CDN/cache provider is able to configure, in the relevant 328 interfaces of the CDN/caches, the same IPv6 addresses that will 329 naturally result as the translated destination addresses for the 330 queried A records, preceded by the WKP or NSP, then having more 331 specific routing prefixes, will result in traffic to those 332 destinations being directly forwarded towards those interfaces, 333 instead of needing to traverse the NAT64. 335 For example, let's suppose a provider using the WKP (64:ff9b::/96) 336 and a SmartTV querying for www.example.com: 338 www.example.com A 192.0.2.1 339 NAT46/CLAT translated to 64:ff9b::192.0.2.1 340 CDN IPv6 interface must be 64:ff9b::192.0.2.1 341 Operator must have a specific route to 64:ff9b::192.0.2.1 343 Note: Examples using text representation as per Section 2.3 of 344 [RFC6052] and IPv4 documentation addresses following [RFC5737]. 346 It should be remarked that this approach requires that the path to 347 the destination is configured in such way (i.e., more specific 348 routing prefixes), that doesn't traverse the NAT64 devices. 350 Because the WKP is non-routable, this solution will only be possible 351 if the CDN/cache is in the same ASN as the provider network, or 352 somehow interconnected without routing thru Internet. 354 This solution has the additional drawback of the operational 355 complexity/issues added to the operation of the CDN/cache, and the 356 need to synchronize any IPv4 interface address changes with the 357 relevant IPv6 ones, and possibly with routing. 359 5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution 361 If the NAT46/CLAT/CE, as commonly is the case, is also a DNS proxy/ 362 stub resolver, it is possible to modify the behavior and create an 363 "internal" interaction among both of them. 365 This approach uses the existing IPv4 and IPv6 addresses in the A and 366 AAAA records, respectively, so no additional complexity/issues added 367 to the CDN/caches operations. 369 The following sub-sections detail this approach and provide a step- 370 by-step example case. Note that this optimization MUST NOT be 371 enabled when the WAN link is IPv4-only or dual-stack. In other 372 words, only can be enabled if the WAN link is IPv6-only and 373 consequently, the NAT46/CLAT is enabled in the CE. 375 5.2.1. Detection of IPv4-only hosts or applications 377 The assumption is that, typically a dual-stack host will prefer using 378 IPv6 as the DNS transport. So, when there is a DNS query, 379 transported with IPv4, for an A record, and there is not a query for 380 the AAAA record from the same IPv4 source (to the same destination), 381 the DNS proxy/stub resolver can infer that, most probably, it is an 382 IPv4-only device or application. 384 It needs to be remarked that, if the detection of the IPv4-only 385 device or application is done incorrectly (either not detecting it or 386 by a false detection), no harm is caused. In the worst case, 387 optimization will not be performed, at least, at the time being. 388 However, optimization maybe performed later on, if a new detection 389 succeeds (for example, another device using the same A record). 391 5.2.2. Detection of IPv6-enabled service 393 In the case of an IPv4-only detected device or application, the DNS 394 proxy/stub resolver MUST actually perform an additional AAAA query, 395 unless the information is already present in the Additional Section, 396 as per Section 3 of [RFC3596]. Note that the NAT46/CLAT MUST already 397 know the WKP or NSP being used in that network. If the response 398 contains at least one IPv6 address not using the WKP/NSP, it means 399 that the destination is IPv6-enabled (because at least one of the 400 IPv6 addresses is not synthesized). This means that it is possible 401 for the NAT46/CLAT, to create an Explicit Address Mapping 402 ([RFC7757]). 404 5.2.3. Creation of EAMT entries 406 This way, an EAM Table (EAMT used for short, across the rest of this 407 document) is created/maintained automatically by the DNS proxy/stub 408 resolver in the NAT46/CLAT, and the NAT46/CLAT is responsible to 409 prioritize any available entries in the EAMT, versus the use of any 410 synthetic AAAA. 412 In order to create the EAMT entry, to determine if there is an AAAA 413 record after an A record query, it is suggested to use the same delay 414 value (50 milliseconds) as the "Resolution Delay" indicated by Happy 415 Eyeballs [RFC8305]. This avoids a slight NAT64 overload and flapping 416 between destination addresses (IPv4/IPv6), which may impact some 417 applications, at the cost of a small extra delay for the initial 418 communication setup, when the EAMT entry doesn't yet exist. 420 Each EAMT entry MUST contain, the fields already described in 421 [RFC7757] and a few new ones: 423 1. ID: EAMT Entry Index (optional). 425 2. IPv4 address/prefix: By default, the prefix length is 32 bits. 427 3. IPv6 address/prefix: By default, the prefix length is 128 bits. 429 4. TTL: Because the optimization will make use of the AAAA (IPv6 430 address), the TTL for the EAMT entry MUST be set to the same 431 value as in the AAAA RR. In normal conditions the TTL for both A 432 and AAAA records, of a given FQDN, should be the same, so this 433 ensures a proper behavior if there is any DNS mismatch. 435 5. FQDN: The one that originated the A query for this EAMT entry. 436 Required in order to ensure a correct detection of cases such as 437 the use of reverse-proxy with a single IPv4 address to multiple 438 IPv6 addresses. 440 6. Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT 441 be used and consequently no optimization performed. It may be 442 used also for an explicit configuration (GUI, CLI, provisioning 443 system, etc.) to disallow optimization for explicitly configured 444 IPv4 addresses. 446 7. Auto/Static: When set to 1, means that this EAMT entry has been 447 manually/statically configured, for example by means of an 448 explicit configuration (GUI, CLI, provisioning system, etc.), so 449 it doesn't expire with TTL. 451 When a new EAMT entry is first automatically created, it is marked as 452 "Valid" and "Auto" (both bits cleared). If a subsequent A query, 453 with a different FQDN, results in an IPv4 address that has already an 454 EAMT entry and a different IPv6 address, it means that some reverse- 455 proxy or similar functionality is being used by the IPv6-enabled 456 service. In this case, the existing EAMT entry will be marked as 457 "Invalid" (bit set). No new EAMT entry is created for that IPv4 458 address. Otherwise, the optimization will only allow to access the 459 first set of IPv4/IPv6/FQDN, which may break the access to other FQDN 460 that share the same IPv4 address and different IPv6 addresses. 462 In this case the EAMT entry will still expire according the TTL, 463 which allows to re-enable optimization if a new query for the A 464 record has changed the situation. For example, maybe the reverse- 465 proxy has been removed, or there is now only a single device using 466 it, so at the time being, the optimization is again possible without 467 creating troubles to other hosts. 469 Note that when an EAMT entry is marked as "invalid", it will not 470 affect the devices or applications, as they will still be able to use 471 the regular CLAT+NAT64 flow, of course, without the optimization. 473 Note the newly defined EAMT fields, follow the "extensions" approach 474 as per section 3.1 of [RFC7757]. 476 5.2.4. Forwarding path via stateful NAT for existing EAMT entries 478 Following this approach, if there is a valid EAMT entry, for a given 479 IPv4-destination, the IPv6-native path pointed by the IPv6 address of 480 that EAMT entry, will take precedence versus the NAT64 path, so the 481 traffic will not be forwarded to the NAT64. 483 However, this is not sufficient to ensure that individual 484 applications are able to keep existing connections. In many cases, 485 audio and video streaming may use a single TCP connection lasting 486 from minutes to hours. Instead, the CDN TTLs may be configured in 487 the range from 10 to 300 seconds in order to allow new resolutions to 488 switch quickly and to handle large recursive resolvers (with hundreds 489 of thousands of clients behind them). 491 Consequently, the EAMT entries should not be used directly to 492 establish a forwarding path, but instead, to create a stateful NAT 493 entry for the 4-tuple for the duration of the session/connection. 495 5.2.5. Maintenance of the EAMT entries 497 The information in the EAMT MUST be kept timely-synchronized with the 498 AAAA records TTL's, so the EAMT entries MUST expire on the AAAA TTL 499 expiry and consequently be deleted. 501 However, EAMT entries with the Auto/Static bit set, will not be 502 deleted. This allows users/operators to set explicit rules for 503 diagnostics or resolution of issues in special situations. 505 5.2.6. Usage example 507 Using the same example as in the previous approach: 509 www.example.com A 192.0.2.1 510 AAAA 2001:db8::a:b:c:d 511 EAMT entry 192.0.2.1 2001:db8::a:b:c:d 512 NAT46/CLAT translated to 2001:db8::a:b:c:d 513 CDN IPv6 interface already is 2001:db8::a:b:c:d 514 Operator already has a specific route to 2001:db8::a:b:c:d 516 The following is an example of the CE behavior after the previous 517 case has already created an EAMT entry and a reverse-proxy is 518 detected: 520 1. A query for www.another-example.com A RR is received 522 2. www.another-example.com A 192.0.2.1 524 3. www.another-example.com AAAA 2001:db8::e:e:f:f 526 4. A conflict has been detected 528 5. The existing EAMT entry for 192.0.2.1 is set as invalid 530 5.2.7. Behavior in case of multiple A/AAAA RRs 532 Existing DNS proxy/stub resolvers already implement mechanisms for 533 DNS Load Balancing ([RFC1794]). This should not be modified to 534 implement the optimization so, if multiple A and/or AAAA records are 535 available, any of them could be chosen. In other words, the chosen 536 pair of A/AAAA records doesn't present any different result compared 537 with a situation when this mechanism is not used. 539 5.2.8. Behavior in presence/absence of DNS64 541 464XLAT can be deployed/used with and without a DNS64. However, as 542 indicated in Section 5.2.2, the EAMT entry is only created when the 543 service is IPv6-enabled, because the optimization is only relevant 544 for destinations which already have AAAA records. In those cases 545 DNS64 is not relevant. 547 5.2.9. Behavior when using literal addresses or non IPv6-compliant APIs 549 Because the EAMT entries are only created when the NAT46/CLAT/CE 550 proxy/stub DNS is being used, any devices or applications that don't 551 use DNS, will not create the relevant entries. 553 They may be optimized if devices or applications using DNS, at some 554 point, query for the same A RRs, or if EAMT entries are statically 555 configured. 557 5.2.10. Behavior in case of Foreign DNS 559 Devices or applications may use DNS servers from other networks. For 560 a complete description of reasons for that, refer to Section 4.4 of 561 [RFC8683]. In the case the DNS is modified, or some devices or 562 applications use other DNS servers, the possible scenarios and the 563 implications are: 565 a. Devices configured to use a DNS proxy/resolver which is not the 566 CE/NAT46/CLAT. In this case this optimization will not work, 567 because the EAMT entry will not be created based on their own 568 flows. Nevertheless, the EAMT entry may be created by other 569 devices using the same destinations. However, the lack of EAMT 570 entry, will not impact negatively in the user's devices/ 571 applications (the optimization is not performed). It should be 572 noticed that users commonly, don't change the configuration of 573 devices such as SmartTVs or STBs (if they do, some other 574 functionalities, such as CDN/caches optimizations may not work as 575 well), so this only happens typically if the vendor is doing it 576 on-purpose and for good well-known reasons. 578 b. DNS privacy/encryption. Hosts or applications that use 579 mechanisms for DNS privacy/encryption, such as DoT ([RFC7858], 580 [RFC8094]), DoH ([RFC8484]) or DoQ 581 ([I-D.huitema-dprive-dnsoquic]), will not make use of the stub/ 582 proxy resolver, so the same considerations as for the previous 583 case applies. 585 c. Users that modify the DNS in their Operating Systems. This is 586 quite frequent, however commonly Operating Systems are dual- 587 stack, so aren't part of the problem statement described by this 588 document and will not be adversely affected. 590 d. Users that modify the DNS in the CE. This is less common. In 591 this case, this optimization is not adversely affected, because 592 it doesn't depend on the operator DNS, it works only based on the 593 internal CE interaction between the NAT46/CLAT and the stub/proxy 594 resolver. Note that it may be affected if the operator offers 595 different "DNS views" or "split DNS", however this is not related 596 to this optimization and will anyway impact in the other possible 597 operator optimizations (i.e. CDN/cache features). 599 e. Combinations of the above ones. No further impact, than the one 600 already described, is observed. 602 5.2.11. False detection of a dual-stack host as IPv4-only 604 If a dual-stack host is issuing the A query using IPv4 transport, and 605 the AAAA query using IPv6 transport, or in the other way around, or 606 using different IPv4 addresses for the A and AAAA queries, the EAMT 607 entry will be created. However, this EAMT entry may not be used by 608 dual-stack devices or applications, because those devices or 609 applications should prefer IPv6. If the host is preferring IPv4 for 610 connecting to the CDN/cache or IPv6-enabled service, it will be 611 actually using the NAT46/CLAT, including the EAMT entry and 612 consequently IPv6, so this mechanism will be correcting an 613 undesirable behavior. This is a special case, which actually seems 614 to be an incoherent host or application implementation. 616 Afterwards, if other IPv4-only devices or applications subsequently 617 need to connect to the same IPv6-enabled service, they will take 618 advantage of the already existing EAMT entry, and consequently use 619 the IPv6-optimised path. 621 5.2.12. Behavior in presence of Happy Eyeballs 623 Happy Eyeballs [RFC8305] is only enabled in dual-stack hosts. 624 Consequently, it is not affected by this optimization because both, 625 the A and the AAAA queries should be issued by the host as soon after 626 one another as possible. In summary, the host should not be detected 627 as IPv4-only, following Section 5.2.1. 629 Nevertheless, if the same NAT46/CLAT/CE is serving IPv4-only hosts 630 and dual-stack hosts and both of them are using the same 631 destinations, an EAMT entry may have been previously created for that 632 destination. Consequently, if Happy Eyeballs triggers a fallback to 633 IPv4, it will be actually using the relevant EAMT entry towards the 634 IPv6 destination. This has the disadvantage that the IPv4-IPv6-IPv4 635 translation path can't be used by Happy Eyeballs-enabled 636 applications, so avoiding a real IPv4-fallback and making IPv6 the 637 only available protocol. 639 This is the natural and expected path for IPv6-only networks, so 640 actually it may be considered as a good thing, in the sense that an 641 operator is interested in knowing as soon as possible, if the 642 IPv6-only network is not performing correctly. 644 Note that when using 464XLAT, the WAN link of the NAT46/CLAT/CE is 645 IPv6-only. So even if Happy Eyeballs is present, IPv4 is expected to 646 be slower than native IPv6 itself due to delays added by the 647 NAT46+NAT64 translations. This optimization reduces those delays by 648 eliminating the second translation (NAT64). 650 However, there may be cases where this may be understood as 651 problematic. The possible reasons why Happy Eyeballs may trigger an 652 IPv4 fallback, in the case of IPv6-only access networks with IPv4aaS, 653 in general, can be classified as: 655 1. Failure at the CE or customer LANs. It may happen that the CE or 656 other devices in the customer LANs are showing erratic behaviors 657 or malfunctions. It is difficult to believe that this happens 658 only with IPv6, and if that's the case Happy Eyeballs will not 659 resolve the issue, because IPv4 is provided as a service on top 660 of IPv6. 662 2. Complete failure of the IPv6-only link or IPv6-only operator's 663 infrastructure (up to the NAT64). In this case, IPv4 will not 664 work for that subscriber. Happy Eyeballs will not resolve the 665 issue, and instead will only be adding some extra delay (the 666 attempt to fallback to IPv4 before timing-out). 668 3. Complete failure of both IPv4 and IPv6 links behind the 669 operator's NAT64 towards the destination. In this case, 670 typically both, IPv4 and IPv6 will fail (in many cases, they are 671 dual-stack links, not different links). Again, Happy Eyeballs 672 will also fail to resolve the issue. 674 4. Complete failure only in the IPv6 links behind the operator's 675 NAT64 towards the destination. This is less frequent, bus still 676 miss-configured AAAA RRs, or diverse paths for IPv4 and IPv6 677 together with outages or IPv6-only routing issues, could generate 678 this problem. In this case, Happy Eyeballs could resolve the 679 issue, however, the optimization will disallow it. 681 5. Partial failure: Slower IPv6 vs IPv4 path end-to-end. In 682 general, the added delay of the IPv4 translations and NAT across 683 the path, increases the chances that IPv4 is faster than IPv6. 684 However, it may happen that there is some IPv6 specific link 685 congestion or packet dropping, that generates the reverse 686 situation, so IPv4 becomes faster than IPv6. Because the 687 optimization, the end-to-end path is forced to be IPv6, so Happy 688 Eyeballs will not be able to offer any significative advantage in 689 resolving the issue. 691 In summary, the optimization may be hindering the Happy Eyeballs 692 assistance, only in the last two cases. In one of the cases (partial 693 failure: slower IPv6 vs IPv4 path end-to-end), just don't help to 694 make IPv6 faster. In the other case (complete failure only in the 695 IPv6 links behind the operator's NAT64 towards the destination), it 696 will completely fail. However, it should be observed that in both 697 cases, the problem will also impact other operators (even if not 698 using the optimization), and especially those using only NAT64+DNS64 699 instead of 464XLAT, or even more, any IPv6-only hosts or applications 700 in any operator network across the entire Internet. It looks like it 701 is very important to make sure that, as IPv6 is more prevalent, there 702 is a better monitoring and failures are detected ASAP, instead of 703 being hidden by Happy Eyeballs, specially in IPv6-only networks, so 704 it seems an acceptable trade-off. It should be noticed also that in 705 IPv6-only with IPv4aaS, the chances of troubles in the IPv4 paths 706 seem to be higher than in the IPv6, as there are more translations, 707 more devices, more delays, while the optimization will precisely 708 reduce them. 710 5.2.13. Troubleshooting Implications 712 When there is a need to troubleshoot IPv4 from the CE LANs, it may 713 happen that there is an EAMT entry forcing the flow to a given 714 destination(s) to use IPv6, which will distort the results. 716 This can be avoided, using a CLI/GUI or provisioning procedure, to 717 either completely disable the optimization during the 718 troubleshooting, or create specific static EAMT entries, using the 719 Valid/Invalid and Auto/Static flags, as described in Section 5.2.3. 721 Consequently, the CE MUST allow both, disabling the optimization and 722 the setup of manual/static EAMT entries. 724 5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution 726 Instead of using the DNS proxy/stub resolver to create the EAMT 727 entries, the operator may push this table (or parts of it) into the 728 CE/NAT46/CLAT, by using configuration/management mechanisms. 730 This solution has the advantage of not being affected by any DNS 731 changes from the user (the EAMT is created by the operator) and 732 ensures a complete control from the operator. However, it may impact 733 the cases of devices with a DNS configured by the vendor. 735 In general, most of the considerations from the previous approach 736 will apply. 738 One more advantage of this solution is that the EAMT pairs doesn't 739 need to match the "real" IPv4/IPv6 addresses available in the A/AAAA 740 records, as shown in the next example. 742 www.example.com A 192.0.2.1 743 AAAA 2001:db8::a:b:c:d 744 EAMT pulled/pushed entry 192.0.2.1 2001:db8::f:e:d:c 745 NAT46/CLAT translated to 2001:db8::f:e:d:c 746 CDN IPv6 interface already is 2001:db8::f:e:d:c 747 Operator already has a specific route to 2001:db8::f:e:d:c 749 EAMT may contain TTLs which probably are derived from DNS ones, or 750 alternatively, a global TTL for the full table. 752 An alternative way to configure the table, is that the CE is actually 753 pulling the table (or parts of it) from the operator infrastructure. 754 In this case it will be mandatory that the entries have individual 755 TTLs, again probably derived from the DNS ones. 757 The major drawback of this approach is that it requires a new 758 protocol, or an extension to existing ones, in order to push or pull 759 the EAMT, in addition to the possible impact in terms of bandwidth 760 each time the CEs reboot, or an EAMT must be pushed to all the CEs, 761 etc. 763 6. IPv6-only Services become accessible to IPv4-only devices/apps 765 One of the issues with the IPv6 deployment, is that those services 766 which become IPv6-only in Internet, aren't reachable by IPv4-only 767 devices and applications. This means that new content providers must 768 support dual-stack even for new services, even while IPv4 public 769 addresses aren't available. 771 If NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) is chosen, it also 772 offers the chance to resolve this issue. This is possible if 773 IPv6-only services get configured with an A resource record pointing 774 to a well-known IPv4 address despite they aren't actually connected 775 to IPv4. This is out of scope for this document, as it will require 776 further work and a reservation by IANA, This will mean that those 777 services will work fine if there is a NAT46/CLAT supporting the 778 optimization. This A RR has no negative impact if the NAT46/CLAT 779 doesn't exist, or it is not optimized, because is not reachable via 780 IPv4-only, so is not a different situation compared with not having 781 an A RR. 783 The result of this is equivalent to the approach taken by MAP-T 784 (Section 12.3 of [RFC7599]). However, it has the advantage that the 785 MAP-T approach is restricted to services in the MAP-T domain. 787 In fact, it may become an incentive for the IPv6 deployment in 788 Internet services, as it provides the option to use a well-known IPv4 789 address (maybe anycast) for the "non-valid" A RR, that points, in 790 case of port 80/443 to a web page or service that returns a warning 791 such as "This service is only available if the network is properly 792 connected to Internet with IPv6". 794 7. Conclusions 796 NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) seems the right 797 solution for optimizing the access to dual-stack services, whether 798 they are located inside or outside the ISP. It is also the only 799 approach which has no additional requirements for the network 800 operators (both ISPs and CDN/cache operators). 802 Having this type of optimization facilitates and increases the usage 803 of IPv6, even for IPv4-only devices and applications, at the same 804 time that decreases the use of the NAT64. 806 SIIT already has a SHOULD for EAM support, so it is not a high 807 additional burden the support required for existing implementations 808 to be updated for this optimization. 810 8. Security Considerations 812 This document does not have any new specific security considerations, 813 besides the ones already known for DNS64. 815 Spoofed DNS responses could generate incorrect EAMT entries. 816 However, this seems not different than if the optimization is not in 817 place and the spoofed DNS responses are cached by the CE DNS proxy/ 818 stub resolver or even by hosts in the CE LANs. It very much depends 819 on how and where the attack is actually performed. 821 In both cases, 464XLAT and MAP-T, the CE device should contain a DNS 822 proxy/stub resolver, which is also required for the optimization. 823 Nevertheless, it is common that the user change DNS settings. If it 824 happens, in the case of MAP-T, the port-set is restricted for an 825 efficient public IPv4 address sharing, so the entropy of the source 826 ports is significantly lowered. In this case, theoretically MAP-T is 827 less resilient against cache poisoning ([RFC5452]) compared with 828 464XLAT. However, an efficient cache poisoning attack requires that 829 the subscriber operates its own caching DNS server and the attack is 830 performed in the service provider network, so the chances of a 831 successful exploitation of this vulnerability are low. 833 9. IANA Considerations 835 This document does not have any new specific IANA considerations. 837 10. Acknowledgements 839 The authors would like to acknowledge the inputs of Erik Nygren, Fred 840 Baker, Martin Hunek, Chongfeng Xie, Fernando Gont, Fernando Frediani 841 and Jen Linkova. 843 11. References 845 11.1. Normative References 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, 849 DOI 10.17487/RFC2119, March 1997, 850 . 852 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 853 "DNS Extensions to Support IP Version 6", STD 88, 854 RFC 3596, DOI 10.17487/RFC3596, October 2003, 855 . 857 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 858 Resilient against Forged Answers", RFC 5452, 859 DOI 10.17487/RFC5452, January 2009, 860 . 862 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 863 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 864 DOI 10.17487/RFC6052, October 2010, 865 . 867 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 868 NAT64: Network Address and Protocol Translation from IPv6 869 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 870 April 2011, . 872 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 873 Beijnum, "DNS64: DNS Extensions for Network Address 874 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 875 DOI 10.17487/RFC6147, April 2011, 876 . 878 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 879 Combination of Stateful and Stateless Translation", 880 RFC 6877, DOI 10.17487/RFC6877, April 2013, 881 . 883 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 884 the IPv6 Prefix Used for IPv6 Address Synthesis", 885 RFC 7050, DOI 10.17487/RFC7050, November 2013, 886 . 888 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 889 Port Control Protocol (PCP)", RFC 7225, 890 DOI 10.17487/RFC7225, May 2014, 891 . 893 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 894 and T. Murakami, "Mapping of Address and Port using 895 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 896 2015, . 898 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 899 Mappings for Stateless IP/ICMP Translation", RFC 7757, 900 DOI 10.17487/RFC7757, February 2016, 901 . 903 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 904 "IP/ICMP Translation Algorithm", RFC 7915, 905 DOI 10.17487/RFC7915, June 2016, 906 . 908 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 909 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 910 May 2017, . 912 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 913 Better Connectivity Using Concurrency", RFC 8305, 914 DOI 10.17487/RFC8305, December 2017, 915 . 917 [RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router 918 Advertisements", RFC 8781, DOI 10.17487/RFC8781, April 919 2020, . 921 11.2. Informative References 923 [I-D.huitema-dprive-dnsoquic] 924 Huitema, C., Mankin, A., and S. Dickinson, "Specification 925 of DNS over Dedicated QUIC Connections", draft-huitema- 926 dprive-dnsoquic-00 (work in progress), March 2020. 928 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 929 DOI 10.17487/RFC1794, April 1995, 930 . 932 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 933 Reserved for Documentation", RFC 5737, 934 DOI 10.17487/RFC5737, January 2010, 935 . 937 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 938 and P. Hoffman, "Specification for DNS over Transport 939 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 940 2016, . 942 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 943 Transport Layer Security (DTLS)", RFC 8094, 944 DOI 10.17487/RFC8094, February 2017, 945 . 947 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 948 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 949 . 951 [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for 952 NAT64/464XLAT in Operator and Enterprise Networks", 953 RFC 8683, DOI 10.17487/RFC8683, November 2019, 954 . 956 Authors' Addresses 958 Jordi Palet Martinez 959 The IPv6 Company 960 Molino de la Navata, 75 961 La Navata - Galapagar, Madrid 28420 962 Spain 964 Email: jordi.palet@theipv6company.com 965 URI: http://www.theipv6company.com/ 967 Alejandro D'Egidio 968 Telecentro 969 Argentina 971 Email: adegidio@telecentro.net.ar