idnits 2.17.1 draft-ietf-v6ops-464xlat-optimization-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 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 28, 2020) is 1367 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3655 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 1 error (**), 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 29, 2021 Telecentro 6 July 28, 2020 8 464XLAT/MAT-T Optimization 9 draft-ietf-v6ops-464xlat-optimization-03 11 Abstract 13 IP/ICMP Translation Algorithm (SIIT) can be used to provide access 14 for IPv4-only hosts 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, increasing the performance. 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 29, 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 . . . . . . . . . . . . . . . . . . 6 64 5. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 8 66 5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 9 67 5.2.1. Optimization enabling . . . . . . . . . . . . . . . . 9 68 5.2.2. Detection of IPv4-only hosts . . . . . . . . . . . . 9 69 5.2.3. Detection of IPv6-enabled service . . . . . . . . . . 10 70 5.2.4. CE DNS proxy responses . . . . . . . . . . . . . . . 10 71 5.2.5. Creation of EAMT entries . . . . . . . . . . . . . . 11 72 5.2.6. Forwarding path via stateful NAT for existing EAMT 73 entries . . . . . . . . . . . . . . . . . . . . . . . 13 74 5.2.7. Maintenance of the EAMT entries . . . . . . . . . . . 13 75 5.2.8. Usage example . . . . . . . . . . . . . . . . . . . . 14 76 5.2.9. Behavior in case of multiple A/AAAA RRs . . . . . . . 14 77 5.2.10. Behavior in presence/absence of DNS64 . . . . . . . . 14 78 5.2.11. Behavior when using literal addresses or non 79 IPv6-compliant APIs . . . . . . . . . . . . . . . . . 15 80 5.2.12. Behavior in case of Foreign DNS . . . . . . . . . . . 15 81 5.2.13. False detection of a dual-stack host as IPv4-only . . 16 82 5.2.14. Behavior in presence of Happy Eyeballs . . . . . . . 16 83 5.2.15. Troubleshooting Implications . . . . . . . . . . . . 18 84 5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 18 85 6. IPv6-only Services become accessible to IPv4-only 86 devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 19 87 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 93 11.2. Informative References . . . . . . . . . . . . . . . . . 22 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 96 1. Introduction 98 Different transition mechanisms, typically in the group of the so- 99 called IPv6-only with IPv4aaS (IPv4-as-a-Service), such as 464XLAT 100 ([RFC6877]) or MAP-T ([RFC7599]), allow IPv4-only hosts or 101 applications to connect with IPv4 services in Internet over IPv6-only 102 infrastructure, by means of a stateless NAT46 SIIT (IP/ICMP 103 Translation Algorithm) as described by [RFC7915]. 105 This is done by the implementation of SIIT at the CE (Customer Edge) 106 Router or sometimes at the end-device, for example, the UE (User 107 Equipment) in cellular networks. This functionality is the CLAT 108 (Customer Translator) in the case of 464XLAT, while in the case of 109 MAP-T is called NAT46. 111 The NAT46/CLAT (WAN side) is connected by IPv6-only to the operator 112 network, which in turn, will have a reverse translation, the NAT64 113 ([RFC6146]), known as PLAT (Provider Translator) in the case of 114 464XLAT. This allows to translate the IPv6 flow back to IPv4, in 115 order to forward it to Internet. 117 In both cases (NAT46 and NAT64), the translation of the packet 118 headers is done using the IP/ICMP translation algorithm defined in 119 [RFC7915]. Translation between IPv4 and IPv6 addresses is done as 120 per [RFC6052]. The NAT64 prefix should be discovered by the CE by 121 one or more of the existing mechanisms ([RFC7225], [RFC8781] or 122 [RFC7050]), and sometimes it is pre-configured at the CE to the WKP. 124 2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 3. Possible Optimization 134 In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge 135 of the synthesis of AAAA records from the A records, so the NAT64 can 136 be used without the need of doing a double-translation by means of 137 the NAT46/CLAT. 139 However, the DNS64 is not useful for the IPv4-only hosts or 140 applications in the LANs, as they will not be able to use the AAAA 141 records, so they are always forced to use the double-translation. 143 This is the expected behavior, as the original design of NAT64 was 144 targeted to connect IPv6-only devices (using DNS) to IPv4-only 145 services. 464XLAT expanded the solution to also allow IPv4-only 146 devices (even if not using DNS) to connect to IPv4-only services by 147 means of IPv6-only access networks. 149 The optimization solutions presented by this document try to avoid 150 this double-translation, in the cases when the Internet services, are 151 already IPv6-enabled. So, in those cases, if the NAT46 already 152 translated the IPv4 flow to IPv6, it doesn't look necessary to 153 translate this back to IPv6. 155 A typical 464XLAT deployment is depicted in Figure 1. 157 +-------+ .-----. .-----. 158 | IPv6 | / \ / \ 159 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 160 / \ | or +--( only )---( NAT64 )---( Internet ) 161 / Dual- \ | UE | \ Access /\ `-----' \ / 162 ( Stack )--+ | \ / \ \ / 163 \ LAN's / | with | `--+--' \ .-----. `-----' 164 \ / | NAT46 | | \ / \ 165 `-----' | CLAT | +---+----+ / IPv6 \ 166 | | | DNS/ | ( Internet ) 167 +-------+ | DNS64 | \ / 168 +--------+ \ / 169 `-----' 171 Figure 1: Typical 464XLAT Deployment 173 Examples of a topology shown on the above picture includes: 175 o An IPv6-only residential access network where the CE Router (with 176 NAT46/CLAT) supports Dual-Stack in the customer LANs. 178 o An IPv6-only cellular network where a UE uses the NAT46/CLAT for 179 dual-stack internal applications and other hosts connected via 180 tethering. 182 If the operator is providing direct access, for example, to Content 183 Delivery Networks (CDNs), caches, or other resources, and they are 184 dual-stacked, the situation can be described as shown in Figure 2. 186 +-------+ .-----. .-----. 187 | IPv6 | / \ / \ 188 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 189 / \ | or +--( only )---( NAT64 )---( Internet ) 190 / Dual- \ | UE | \ Access /\ `-----' \ / 191 ( Stack )--+ | \ / \ \ / 192 \ LAN's / | with | `--+--' \ .-----. `--+--' 193 \ / | NAT46 | | \ / \ \ 194 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 195 | | | DNS/ | ( Internet ) / Dual- \ 196 +-------+ | DNS64 | \ /----/ Stack \ 197 +--------+ \ / ( ) 198 `-----' \ CDNs/ / 199 \ Caches/ 200 `-----' 202 Figure 2: Typical 464XLAT Deployment with CDNs/Caches 204 In this case if the flows initiated in the LANs come from IPv4-only 205 hosts or applications, even if the destination resources are 206 IPv6-enabled, the double-translation is enforced, which has the 207 following consequences: 209 o More traffic needs to pass thru the NAT64 devices. 211 o More NAT64 devices may be needed to handle the additional traffic. 213 o Additional usage of IPv4 addresses. 215 o Additional state at the NAT64 devices. 217 o Additional logging, its relevant storage and processing resources. 219 o Increasing of delay and redduction of traffic performance. 221 o Unnecessary point(s) of failure for that traffic. 223 Clearly, all those aspects have impact in both, CapEx and OpEx. This 224 is extremely important when considering that most of the time, the 225 contents stored in CDNs, caches, and so on, is there for a good 226 reason: It is frequently accessed resources and/or big. Examples 227 such as video, audio, software and updates, are very common. So, 228 this optimization can be highly impacting in many networks. 230 4. Problem Statement Summary 232 If the hosts or applications in the customer LAN are IPv6-capable, 233 then the access to the CDNs, caches or other resources, will be made 234 in an optimized way, by means of IPv6-only, not using the NAT64, as 235 depicted in Figure 3. 237 +-------+ .-----. .-----. 238 | IPv6 | / \ / \ 239 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 240 / \ | or +--( only )---( NAT64 )---( Internet ) 241 / IPv6 \ | UE | \ Access /\ `-----' \ / 242 ( capable )--+ | \ / \ \ / 243 \ apps / | with | `--+--' \ .-----. `-----' 244 \ / | NAT46 | | \ / \ 245 `-----' | CLAT | +---+----+ / IPv6 \ .-----. 246 | | | DNS/ | ( Internet )IPv6/ Dual- \ 247 +-------+ | DNS64 | \ /----/ Stack \ 248 +--------+ \ / ( ) 249 `-----' \ CDNs/ / 250 \ Caches/ 251 `-----' 252 <---------------------- end-to-end IPv6 flow ----------------------> 254 Figure 3: 464XLAT access to CDNs/Caches by IPv6-capable apps 256 However, if the hosts or applications are IPv4-only, for example, 257 many SmartTVs and Set-Top-Boxes available today, a non-optimal double 258 translation will occur (NAT46 at the CLAT and NAT64 at the PLAT), as 259 illustrated in Figure 4. 261 +-------+ .-----. .-----. 262 | IPv6 | / \ / \ 263 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 264 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 265 / only \ | UE | \ Access /\ `-----' \ / 266 ( SmartTV )--+ | \ / \ \ / 267 \ STB / | with | `--+--' \ .-----. `--+--' 268 \ VoIP / | NAT46 | | \ / \ \ IPv4 269 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 270 | | | DNS/ | ( Internet ) / Dual- \ 271 +-------+ | DNS64 | \ / / Stack \ 272 +--------+ \ / ( ) 273 `-----' \ CDNs/ / 274 \ Caches/ 275 `-----' 276 <-------------------- IPv4 to IPv6 to IPv4 flow --------------------> 278 Figure 4: 464XLAT access to CDNs/Caches by IPv4-only apps 280 Clearly, this is a non-optimal situation, as it means that even if 281 there is a dual-stack service, the NAT46/CLAT translated IPv4 to IPv6 282 traffic flow, is unnecessarily translated back to IPv4, traversing 283 the stateful NAT64. This has a direct impact in the need to scale 284 the NAT64 beyond what will be actually needed, if possible solutions, 285 in order to keep using the IPv6 path towards those services, are 286 considered. 288 As shown in the Figure 4, this is also the case for many other 289 services, not just CDNs or caches, such as VoIP access to the 290 relevant operator infrastructure, which may be also dual-stack. This 291 is true as well for many other dual-stack or IPv6-enabled services, 292 which may be directly reachable from the operator infrastructure, 293 even if they are not part of it, for example peering agreements, 294 services in IXs, etc. In general, this will become a more frequent 295 situation for many other services, which are not yet dual-stack. 297 For simplicity, across the rest of this document, references to CDNs/ 298 caches, should be understood, unless otherwise stated, as any dual- 299 stacked resources. 301 This document looks into different possible solution approaches in 302 order to optimize the IPv4-only SIIT translation providing a direct 303 path to IPv6-capable services, as depicted in Figure 5. 305 +-------+ .-----. .-----. 306 | IPv6 | / \ / \ 307 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 308 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 309 / only \ | UE | \ Access /\ `-----' \ / 310 ( SmartTV )--+ | \ / \ \ / 311 \ STB / | with | `--+--' \ .-----. `-----' 312 \ VoIP / | NAT46 | | \ / \ 313 `-----' | CLAT | +---+----+ / IPv6 \ .-----. 314 | | | DNS/ | ( Internet )IPv6/ Dual- \ 315 +-------+ | DNS64 | \ /----/ Stack \ 316 +--------+ \ / ( ) 317 `-----' \ CDNs/ / 318 \ Caches/ 319 `-----' 320 <------------------------ IPv4 to IPv6 flow ------------------------> 322 Figure 5: Optimized 464XLAT access to CDNs/Caches by IPv4-only apps 324 5. Solution Approaches 326 5.1. Approach 1: DNS/Routing-based Solution 328 Because the IPv4-only devices will not be able to query for AAAA 329 records, the NAT46/CLAT/CE will translate the IPv4 addresses from the 330 A record for the CDN/cache destination, using the WKP or NSP, as 331 configured by the operator. 333 If the CDN/cache provider is able to configure, in the relevant 334 interfaces of the CDN/caches, the same IPv6 addresses that will 335 naturally result as the translated destination addresses for the 336 queried A records, preceded by the WKP or NSP, then having more 337 specific routing prefixes, will result in traffic to those 338 destinations being directly forwarded towards those interfaces, 339 instead of needing to traverse the NAT64. 341 For example, let's suppose a provider using the WKP (64:ff9b::/96) 342 and a SmartTV querying for www.example.com: 344 www.example.com A 192.0.2.1 345 NAT46/CLAT translated to 64:ff9b::192.0.2.1 346 CDN IPv6 interface must be 64:ff9b::192.0.2.1 347 Operator must have a specific route to 64:ff9b::192.0.2.1 349 Note: Examples using text representation as per Section 2.3 of 350 [RFC6052] and IPv4 documentation addresses following [RFC5737]. 352 It should be remarked that this approach requires that the path to 353 the destination is configured in such way (i.e., more specific 354 routing prefixes), that doesn't traverse the NAT64 devices. 356 Because the WKP is non-routable, this solution will only be possible 357 if the CDN/cache is in the same ASN as the provider network, or 358 somehow interconnected without routing thru Internet. 360 This solution has the additional drawback of the operational 361 complexity/issues added to the operation of the CDN/cache, and the 362 need to synchronize any IPv4 interface address changes with the 363 relevant IPv6 ones, and possibly with routing. 365 5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution 367 If the NAT46/CLAT/CE, as commonly is the case, is also a DNS proxy/ 368 stub resolver, it is possible to modify the behavior and create an 369 "internal" interaction among both of them. 371 This approach uses the existing IPv4 and IPv6 addresses in the A and 372 AAAA records, respectively, so no additional complexity/issues added 373 to the CDN/caches operations. 375 The following sub-sections detail this approach and provide a step- 376 by-step example case. 378 5.2.1. Optimization enabling 380 This optimization MUST be enabled by default, but only when the WAN 381 link is IPv6-only and the NAT46/CLAT is being used. This allows the 382 users to get CEs from the retail and take advantage of the 383 optimization, without requiring any configuration. 385 The CE MUST support a way to completely disable the optimization, in 386 order to allow the operator to turn it off in case it is required. 388 It is expected that the NAT64/CLAT is only enabled if the WAN link is 389 IPv6-only. 391 5.2.2. Detection of IPv4-only hosts 393 The goal is to ensure that only IPv4-only hosts are optimized. 394 Towards that, the CE MUST use ARP and ND (and their relevant caches, 395 if the information of a hosts has been already learnt) each time a 396 new host starts a connection. If it is possible to bind the same MAC 397 address to both an IPv4 and IPv6 address, then the host is not 398 IPv4-only (it may be IPv6-only or dual-stack), and MUST NOT be 399 optimized. 401 The CE MUST maintain a table of IPv4-only hosts and ensure that if 402 any IPv4-only hosts become IPv6-enabled, it is properly handled. 404 This mechanism to detect IPv4-only hosts has two drawbacks: 406 1. If a subscriber has intermediate dual-stack routers in between 407 the IPv4-only host and the NAT46/CLAT, the IPv4-only hosts will 408 be detected as dual-stack, so no optimization will be performed. 409 This is not the most common scenario, as typically the devices 410 that are more relevant to the optimization (in terms of those 411 that generate more IPv4-only traffic) are directly attached to 412 the CE, or in bridged interfaces. 414 2. If a host is dual-stack, but has some IPv4-only applications, 415 because the host will be detected as dual-stack, none of the 416 applications will be optimized. This is a good trade-off, 417 considering the most important traffic to optimize is typically 418 coming from real IPv4-only devices such as old SmartTVs/STBs. 419 Furthermore, this avoid breaking other mechanisms present only in 420 dual-stack hosts, such as Happy Eyeballs [RFC8305] and simplifies 421 troubleshooting. 423 It needs to be remarked that, if the detection of the IPv4-only host 424 is done incorrectly (either not detecting it or by a false 425 detection), the goal is that no harm is caused. In the worst case, 426 optimization MUST NOT be performed. 428 5.2.3. Detection of IPv6-enabled service 430 In the case of an IPv4-only detected host, the DNS proxy/stub 431 resolver MUST actually perform an additional AAAA query, unless the 432 information is already present in the Additional Section, as per 433 Section 3 of [RFC3596]. 435 Note that the NAT46/CLAT MUST already know the WKP or NSP being used 436 in that network. If the response contains at least one IPv6 address 437 not using the WKP/NSP, it means that the destination is IPv6-enabled 438 (because at least one of the IPv6 addresses is not synthesized). 439 This means that it is possible for the NAT46/CLAT, to create an 440 Explicit Address Mapping ([RFC7757]). 442 5.2.4. CE DNS proxy responses 444 In the case of an IPv4-only detected host, the CE DNS proxy MUST only 445 return the answer to an A query once any of the following happens: 447 1. An answer to the AAAA query has been received. 449 2. A SERVFAIL has been received. 451 3. The "Resolution Delay" has passed. 453 The Resolution Delay MUST be set to the same value (50 milliseconds) 454 as indicated by Happy Eyeballs [RFC8305]. 456 5.2.5. Creation of EAMT entries 458 An EAM Table (EAMT used for short, across the rest of this document) 459 MUST be created/maintained automatically by the NAT46/CLAT, which is 460 responsible to prioritize any available entries in the EAMT, versus 461 the use of any synthetic AAAA. 463 The EAMT entry MUST only be created if all the following conditions 464 are met: 466 1. The source host is IPv4-only. 468 2. The DNS proxy is ready to return the A answer (according to 469 Section 5.2.4). 471 3. There is at least one non-synthesized AAAA response. 473 4. If DNSSEC is available, the response has been locally validated 474 or the AD bit has been set by a trusted resolver, as per 475 [RFC3655]. 477 This avoids a slight NAT64 overload and flapping between destination 478 addresses (IPv4/IPv6), which may impact some applications, at the 479 cost of a small extra delay for the initial communication setup, when 480 the EAMT entry doesn't yet exist. 482 Each EAMT entry MUST contain, the fields already described in 483 [RFC7757] and a few new extensions (as per section 3.1 of [RFC7757]): 485 1. ID: EAMT Entry Index (optional). 487 2. MAC address: Identify the host to which this EAMT entry belongs. 489 3. Destination IPv4 address/prefix: By default, the prefix length is 490 32 bits. 492 4. Destination IPv6 address/prefix: By default, the prefix length is 493 128 bits. Only non-synthesized addresses are allowed. 495 5. TTL: It MUST be set to the minimum value from the AAAA/A RR pair. 496 In normal conditions the TTL for both A and AAAA records, of a 497 given FQDN, should be the same, so this ensures a proper behavior 498 if there is any DNS mismatch. 500 6. FQDN: The one that originated the A query for this EAMT entry. 501 Required in order to ensure a correct detection of cases such as 502 the use of reverse-proxy with a single IPv4 address to multiple 503 IPv6 addresses. 505 7. Valid/Stale/Invalid: When set to Stale, means that this EAMT 506 entry MUST NOT be used for new connections. When set to Invalid, 507 means that this EAMT entry can be deleted, unless the Auto/Static 508 bit is also set. 510 8. Auto/Static: When set to 1, means that this EAMT entry has been 511 manually/statically configured, for example by means of an 512 explicit configuration (GUI, CLI, provisioning system, etc.). 514 Note that allowing destination IPv4 and IPv6 prefixes, together with 515 the Valid/Stale/Invalid and Auto/Static flags, allows manual explicit 516 optimization and non-optimization configuration for specific parts of 517 Internet. 519 When a new EAMT entry is first automatically created, it is flagged 520 as "Valid" and "Auto". If a subsequent A query, with a different 521 FQDN, results in an IPv4 address that has already an EAMT entry and a 522 different IPv6 address, it means that some reverse-proxy or similar 523 functionality is being used by the IPv6-enabled service. In this 524 case, the existing EAMT entry will be marked as "Stale". No new EAMT 525 entry is created for that IPv4 address. Otherwise, the optimization 526 will only allow to access the first set of IPv4/IPv6/FQDN, which may 527 break the access to other FQDN that share the same IPv4 address and 528 different IPv6 addresses. 530 In this case the EAMT entry will still become "Invalid" according the 531 TTL, which allows to re-enable optimization if a new query for the A 532 record has changed the situation. For example, maybe the reverse- 533 proxy has been removed, or there is now only a single device using 534 it, so at the time being, the optimization is again possible without 535 creating troubles to other hosts. 537 An EAMT entry marked as "Stale" or "Invalid", only affects the 538 relevant host. Other hosts have their own EAMT entries or they are 539 using the regular NAT46/CLAT+NAT64 path (without the optimization). 541 5.2.6. Forwarding path via stateful NAT for existing EAMT entries 543 Following this approach, if there is a valid EAMT entry, for a given 544 pair of source-MAC-address/IPv4-destination, the IPv6-native path 545 pointed by the IPv6 address of that EAMT entry, will take precedence 546 versus the NAT64 path, so the traffic will not be forwarded to the 547 NAT64. 549 However, this is not sufficient to ensure that individual 550 applications are able to keep existing connections. In many cases, 551 audio and video streaming may use a single TCP connection lasting 552 from minutes to hours. Instead, the CDN TTLs may be configured in 553 the range from 10 to 300 seconds in order to allow new resolutions to 554 switch quickly and to handle large recursive resolvers (with hundreds 555 of thousands of clients behind them). 557 Consequently, the EAMT entries MUST NOT be used directly to establish 558 a forwarding path, but instead, MUST be used to create a stateful NAT 559 entry for the 4-tuple for the duration of the session/connection. 560 This means that to implement the optimization the NAT46 MUST be 561 stateful. Typically, stateful NAT46 are implemented by means of a 562 stateful NAT44 (which often maybe hardware off-loaded), followed by a 563 stateless NAT46. If the SoC/code is able to do stateless NAT46, this 564 still could be used when the optimization is disabled. 566 5.2.7. Maintenance of the EAMT entries 568 An EATM entry with the Auto/Static bit set, MUST NOT be automatically 569 modified. 571 An EAMT entry with the Auto/Static bit clear, MUST be set to Stale in 572 case of: 574 1. TTL time-out. 576 2. Or the conditions for creation of the EAMT entry (Section 5.2.5) 577 aren't longer met. 579 Entries in Stale state MUST be set to Invalid once existing 580 connections time-out. 582 The Invalid EAMT entries MUST be deleted, unless the Auto/Static bit 583 is set. This allows users/operators to set explicit rules for 584 diagnostics or resolution of issues in special situations. 586 5.2.8. Usage example 588 Using the same example as in the previous approach: 590 www.example.com A 192.0.2.1 591 AAAA 2001:db8::a:b:c:d 592 EAMT entry 192.0.2.1 2001:db8::a:b:c:d 593 NAT46/CLAT translated to 2001:db8::a:b:c:d 594 CDN IPv6 interface already is 2001:db8::a:b:c:d 595 Operator already has a specific route to 2001:db8::a:b:c:d 597 The following is an example of the CE behavior after the previous 598 case has already created an EAMT entry and a reverse-proxy is 599 detected: 601 1. A query for www.example.net A RR is received 603 2. www.example.net A 192.0.2.1 605 3. www.example.net AAAA 2001:db8::e:e:f:f 607 4. A conflict has been detected 609 5. The existing EAMT entry for 192.0.2.1 is set to Stale 611 5.2.9. Behavior in case of multiple A/AAAA RRs 613 If multiple A/AAAA RRs are available, any of them could be chosen and 614 in general, the optimization will not present any different result to 615 the hosts compared with a situation where the optimization is not 616 used. 618 Existing DNS proxy/stub resolvers already implement mechanisms for 619 DNS Load Balancing ([RFC1794]). This don't need to be modified to 620 implement the optimization if some degree of randomness is already 621 secured. 623 To secure sufficient randomness, a possible algorithm shall ensure 624 that different EAMT entries (for different hosts) are permuted 625 randomly among different A/AAAA records on the A/AAAA RR set. 627 5.2.10. Behavior in presence/absence of DNS64 629 464XLAT can be deployed/used with and without a DNS64. However, as 630 indicated in Section 5.2.3, the EAMT entry is only created when the 631 service is IPv6-enabled, because the optimization is only relevant 632 for destinations which already have AAAA records. In those cases 633 DNS64 is not relevant. 635 5.2.11. Behavior when using literal addresses or non IPv6-compliant 636 APIs 638 Because the EAMT entries are only created when the NAT46/CLAT/CE 639 proxy/stub DNS is being used, any hosts or applications that don't 640 use DNS, will not create the relevant entries. 642 They will not be optimized unless EAMT entries are statically 643 configured. 645 5.2.12. Behavior in case of Foreign DNS 647 Hosts or applications may use DNS servers from other networks. For a 648 complete description of reasons for that, refer to Section 4.4 of 649 [RFC8683]. In the case the DNS is modified, or some hosts or 650 applications use other DNS servers, the possible scenarios and the 651 implications are: 653 a. Devices configured to use a DNS proxy/resolver which is not the 654 CE/NAT46/CLAT. In this case this optimization will not work, 655 because the EAMT entry will not be created based on their own 656 flows. Nevertheless, the EAMT entry may be manually created. 657 However, the lack of EAMT entry, will not impact negatively in 658 the user's hosts/applications (the optimization is not 659 performed). It should be noticed that users commonly, don't 660 change the configuration of devices such as SmartTVs or STBs (if 661 they do, some other functionalities, such as CDN/caches 662 optimizations may not work as well), so this only happens 663 typically if the vendor is doing it on-purpose and for good well- 664 known reasons. 666 b. DNS privacy/encryption. Hosts or applications that use 667 mechanisms for DNS privacy/encryption, such as DoT ([RFC7858], 668 [RFC8094]), DoH ([RFC8484]) or DoQ 669 ([I-D.huitema-dprive-dnsoquic]), will not make use of the stub/ 670 proxy resolver, so the same considerations as for the previous 671 case applies. 673 c. Users that modify the DNS in their Operating Systems. This is 674 quite frequent, however commonly Operating Systems are dual- 675 stack, so aren't part of the problem statement described by this 676 document and will not be adversely affected. 678 d. Users that modify the DNS in the CE. This is less common. In 679 this case, this optimization is not adversely affected, because 680 it doesn't depend on the operator DNS, it works only based on the 681 internal CE interaction between the NAT46/CLAT and the stub/proxy 682 resolver. Note that it may be affected if the operator offers 683 different "DNS views" or "split DNS", however this is not related 684 to this optimization and will anyway impact in the other possible 685 operator optimizations (i.e. CDN/cache features). 687 e. Combinations of the above ones. No further impact is observed, 688 beyond the ones already described. 690 5.2.13. False detection of a dual-stack host as IPv4-only 692 If a dual-stack host is being detected as IPv4-only, is because it is 693 not responding to the CE ND messages, so by all means, should be 694 considered, at the time being, as IPv4-only, and consequently EAMT 695 entries will be created and traffic will be optimized for IPv4 flows. 697 However, if this hosts suddenly become IPv6-enabled (or dual-stack), 698 the relevant EAMT entries must be flagged by the CE as "Stale". The 699 host will be able to complete the connections and the entries will be 700 marked as "Invalid" and deleted. 702 Anyway, those EAMT entries, while "Valid", may not be actually used 703 by the dual-stack hosts, because those hosts or applications should 704 prefer IPv6, so most probably was either a temporary failure or done 705 on-purpose (user, troubleshooting). If the host is preferring IPv4 706 for connecting to the CDN/cache or IPv6-enabled service, it will be 707 actually using the NAT46/CLAT, including the EAMT entry and 708 consequently IPv6, so this mechanism will be correcting an 709 undesirable behavior. This may be also a special case, which 710 actually seems to be an incoherent host or application 711 implementation. 713 5.2.14. Behavior in presence of Happy Eyeballs 715 Happy Eyeballs [RFC8305] is only enabled in dual-stack hosts. 716 Consequently, it is not affected by this optimization because both, 717 as the host should not be detected as IPv4-only, following 718 Section 5.2.2. 720 If Happy Eyeballs triggers a fallback to IPv4 for a given host, it 721 will be actually using IPv4 without the optimization, which in turn, 722 uses the IPv6-only WAN link of the NAT46/CLAT/CE. So even if Happy 723 Eyeballs is present, IPv4 is expected to be slower than native IPv6 724 itself due to delays added by the NAT46/CLAT+NAT64 translations. 725 This optimization reduces those delays by eliminating the second 726 translation (NAT64) for IPv4-only detected hosts. 728 However, there may be cases where this may be understood as 729 problematic. The possible reasons why Happy Eyeballs may trigger an 730 IPv4 fallback, in the case of IPv6-only access networks with IPv4aaS, 731 in general, can be classified as: 733 1. Failure at the CE or customer LANs. It may happen that the CE or 734 other devices in the customer LANs are showing erratic behaviors 735 or malfunctions. It is difficult to believe that this happens 736 only with IPv6, and if that's the case Happy Eyeballs will not 737 resolve the issue, because IPv4 is provided as a service on top 738 of IPv6. 740 2. Complete failure of the IPv6-only link or IPv6-only operator's 741 infrastructure (up to the NAT64). In this case, IPv4 will not 742 work for that subscriber. Happy Eyeballs will not resolve the 743 issue, and instead will only be adding some extra delay (the 744 attempt to fallback to IPv4 before timing-out). 746 3. Complete failure of both IPv4 and IPv6 links behind the 747 operator's NAT64 towards the destination. In this case, 748 typically both, IPv4 and IPv6 will fail (in many cases, they are 749 dual-stack links, not different links). Again, Happy Eyeballs 750 will also fail to resolve the issue. 752 4. Complete failure only in the IPv6 links behind the operator's 753 NAT64 towards the destination. This is less frequent, bus still 754 miss-configured AAAA RRs, or diverse paths for IPv4 and IPv6 755 together with outages or IPv6-only routing issues, could generate 756 this problem. In this case, Happy Eyeballs could resolve the 757 issue, however. It will work because the optimization is not 758 enabled for dual-stack hosts. 760 5. Partial failure: Slower IPv6 vs IPv4 path end-to-end. In 761 general, the added delay of the IPv4 translations and NATs across 762 the path, increases the chances that IPv4 is slower than IPv6. 763 However, it may happen that there is some IPv6 specific link 764 congestion or packet dropping, that generates the reverse 765 situation, so IPv4 become faster than IPv6. Because the 766 optimization is not being used for dual-stack hosts, Happy 767 Eyeballs will be resolving the issue. 769 In summary, the optimization will not change the Happy Eyeballs 770 behaviour. Furthermore, it should be observed that IPv6 failures 771 will also impact other operators (even if not using the 772 optimization), and especially those using only NAT64+DNS64 instead of 773 464XLAT, or even more, any IPv6-only hosts and applications in any 774 operator network across the entire Internet. It looks like it is 775 very important to make sure that, as IPv6 is more prevalent, there is 776 a better monitoring and failures are detected ASAP, instead of being 777 hidden by Happy Eyeballs, specially in IPv6-only networks. It should 778 be noticed also that in IPv6-only with IPv4aaS, the chances of 779 troubles in the IPv4 paths seem to be higher than in the IPv6, as 780 there are more translations, more devices, more delays, while the 781 optimization will precisely reduce them. 783 5.2.15. Troubleshooting Implications 785 When there is a need to troubleshoot IPv4 from the CE LANs, it may 786 happen that there is an EAMT entry forcing the flow to a given 787 destination(s) to use IPv6, which will distort the results, unless 788 the host being used is dual-stack (which is the most common 789 situation). 791 This can be avoided, using a CLI/GUI or provisioning procedure, to 792 either completely disable the optimization during the 793 troubleshooting, or create specific static EAMT entries, using the 794 Valid/Stale/Invalid and Auto/Static flags, as described in 795 Section 5.2.5. 797 Consequently, the CE MUST allow both, disabling the optimization and 798 the setup of manual/static EAMT entries. 800 5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution 802 Instead of using the DNS proxy/stub resolver to create the EAMT 803 entries, the operator may push this table (or parts of it) into the 804 CE/NAT46/CLAT, by using configuration/management mechanisms. 806 This solution has the advantage of not being affected by any DNS 807 changes from the user (the EAMT is created by the operator) and 808 ensures a complete control from the operator. However, it may impact 809 the cases of devices with a DNS configured by the vendor. 811 In general, most of the considerations from the previous approach 812 will apply. 814 One more advantage of this solution is that the EAMT pairs doesn't 815 need to match the "real" IPv4/IPv6 addresses available in the A/AAAA 816 records, as shown in the next example. 818 www.example.com A 192.0.2.1 819 AAAA 2001:db8::a:b:c:d 820 EAMT pulled/pushed entry 192.0.2.1 2001:db8::f:e:d:c 821 NAT46/CLAT translated to 2001:db8::f:e:d:c 822 CDN IPv6 interface already is 2001:db8::f:e:d:c 823 Operator already has a specific route to 2001:db8::f:e:d:c 825 EAMT may contain TTLs which probably are derived from DNS ones, or 826 alternatively, a global TTL for the full table. 828 An alternative way to configure the table, is that the CE is actually 829 pulling the table (or parts of it) from the operator infrastructure. 830 In this case it will be mandatory that the entries have individual 831 TTLs, again probably derived from the DNS ones. 833 This approach has three major drawbacks: 835 1. CDNs are used to do frequent changes at the DNS level, so unless 836 the CDNs offer an API or equivalent convenient solution to keep 837 updated the EAMT, the operator will need to cache the most 838 frequent FQDNs being resolved in their own DNS and based on the 839 TTLs, update the EAMT. 841 2. It requires a new protocol, or an extension to existing ones, in 842 order to push or pull the EAMT updates. 844 3. It may generate additional bandwidth utilization in the WAN links 845 for every CE when the EAMT needs to be update, even when a CE 846 reboots. 848 6. IPv6-only Services become accessible to IPv4-only devices/apps 850 One of the issues with the IPv6 deployment, is that those services 851 which become IPv6-only in Internet, aren't reachable by IPv4-only 852 hosts and applications. This means that new content providers must 853 support dual-stack even for new services, even while IPv4 public 854 addresses aren't available. 856 If NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) is chosen, it also 857 offers the chance to resolve this issue. This is possible if 858 IPv6-only services get configured with an A resource record pointing 859 to a well-known IPv4 address despite they aren't actually connected 860 to IPv4. This is out of scope for this document, as it will require 861 further work and a reservation by IANA, This will mean that those 862 services will work fine if there is a NAT46/CLAT supporting the 863 optimization. This A RR has no negative impact if the NAT46/CLAT 864 doesn't exist, or it is not optimized, because is not reachable via 865 IPv4-only, so is not a different situation compared with not having 866 an A RR. 868 The result of this is equivalent to the approach taken by MAP-T 869 (Section 12.3 of [RFC7599]). However, it has the advantage that the 870 MAP-T approach is restricted to services in the MAP-T domain. 872 In fact, it may become an incentive for the IPv6 deployment in 873 Internet services, as it provides the option to use a well-known IPv4 874 address (maybe anycast) for the "non-valid" A RR, that points, in 875 case of port 80/443 to a web page or service that returns a warning 876 such as "This service is only available if the network is properly 877 connected to Internet with IPv6". 879 7. Conclusions 881 NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) seems the right 882 solution for optimizing the access to dual-stack services, whether 883 they are located inside or outside the ISP. It is also the only 884 approach which has no additional requirements for the network 885 operators (both ISPs and CDN/cache operators). 887 Having this type of optimization facilitates and increases the usage 888 of IPv6, even for IPv4-only hosts and applications, at the same time 889 that decreases the use of the NAT64. 891 SIIT already has a SHOULD for EAM support, so it is not a high 892 additional burden the support required for existing implementations 893 to be updated for this optimization. 895 8. Security Considerations 897 This document does not have any new specific security considerations, 898 besides the ones already known for DNS64. 900 Spoofed DNS responses could generate incorrect EAMT entries. 901 However, this seems not different than if the optimization is not in 902 place and the spoofed DNS responses are cached by the CE DNS proxy/ 903 stub resolver or even by hosts in the CE LANs. It very much depends 904 on how and where the attack is actually performed. 906 In both cases, 464XLAT and MAP-T, the CE device should contain a DNS 907 proxy/stub resolver, which is also required for the optimization. 908 Nevertheless, it is common that the user change DNS settings. If it 909 happens, in the case of MAP-T, the port-set is restricted for an 910 efficient public IPv4 address sharing, so the entropy of the source 911 ports is significantly lowered. In this case, theoretically MAP-T is 912 less resilient against cache poisoning ([RFC5452]) compared with 913 464XLAT. However, an efficient cache poisoning attack requires that 914 the subscriber operates its own caching DNS server and the attack is 915 performed in the service provider network, so the chances of a 916 successful exploitation of this vulnerability are low. 918 9. IANA Considerations 920 This document does not have any new specific IANA considerations. 922 10. Acknowledgements 924 The authors would like to acknowledge the inputs of Erik Nygren, Fred 925 Baker, Martin Hunek, Chongfeng Xie, Fernando Gont, Fernando Frediani, 926 Jen Linkova, Eduard Vasilenko and Philip Homburg. 928 11. References 930 11.1. Normative References 932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, 934 DOI 10.17487/RFC2119, March 1997, 935 . 937 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 938 "DNS Extensions to Support IP Version 6", STD 88, 939 RFC 3596, DOI 10.17487/RFC3596, October 2003, 940 . 942 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 943 Authenticated Data (AD) bit", RFC 3655, 944 DOI 10.17487/RFC3655, November 2003, 945 . 947 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 948 Resilient against Forged Answers", RFC 5452, 949 DOI 10.17487/RFC5452, January 2009, 950 . 952 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 953 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 954 DOI 10.17487/RFC6052, October 2010, 955 . 957 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 958 NAT64: Network Address and Protocol Translation from IPv6 959 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 960 April 2011, . 962 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 963 Beijnum, "DNS64: DNS Extensions for Network Address 964 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 965 DOI 10.17487/RFC6147, April 2011, 966 . 968 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 969 Combination of Stateful and Stateless Translation", 970 RFC 6877, DOI 10.17487/RFC6877, April 2013, 971 . 973 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 974 the IPv6 Prefix Used for IPv6 Address Synthesis", 975 RFC 7050, DOI 10.17487/RFC7050, November 2013, 976 . 978 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 979 Port Control Protocol (PCP)", RFC 7225, 980 DOI 10.17487/RFC7225, May 2014, 981 . 983 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 984 and T. Murakami, "Mapping of Address and Port using 985 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 986 2015, . 988 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 989 Mappings for Stateless IP/ICMP Translation", RFC 7757, 990 DOI 10.17487/RFC7757, February 2016, 991 . 993 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 994 "IP/ICMP Translation Algorithm", RFC 7915, 995 DOI 10.17487/RFC7915, June 2016, 996 . 998 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 999 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1000 May 2017, . 1002 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1003 Better Connectivity Using Concurrency", RFC 8305, 1004 DOI 10.17487/RFC8305, December 2017, 1005 . 1007 [RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router 1008 Advertisements", RFC 8781, DOI 10.17487/RFC8781, April 1009 2020, . 1011 11.2. Informative References 1013 [I-D.huitema-dprive-dnsoquic] 1014 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1015 of DNS over Dedicated QUIC Connections", draft-huitema- 1016 dprive-dnsoquic-00 (work in progress), March 2020. 1018 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 1019 DOI 10.17487/RFC1794, April 1995, 1020 . 1022 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1023 Reserved for Documentation", RFC 5737, 1024 DOI 10.17487/RFC5737, January 2010, 1025 . 1027 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1028 and P. Hoffman, "Specification for DNS over Transport 1029 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1030 2016, . 1032 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1033 Transport Layer Security (DTLS)", RFC 8094, 1034 DOI 10.17487/RFC8094, February 2017, 1035 . 1037 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1038 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1039 . 1041 [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for 1042 NAT64/464XLAT in Operator and Enterprise Networks", 1043 RFC 8683, DOI 10.17487/RFC8683, November 2019, 1044 . 1046 Authors' Addresses 1048 Jordi Palet Martinez 1049 The IPv6 Company 1050 Molino de la Navata, 75 1051 La Navata - Galapagar, Madrid 28420 1052 Spain 1054 Email: jordi.palet@theipv6company.com 1055 URI: http://www.theipv6company.com/ 1056 Alejandro D'Egidio 1057 Telecentro 1058 Argentina 1060 Email: adegidio@telecentro.net.ar