idnits 2.17.1 draft-palet-v6ops-464xlat-opt-cdn-caches-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 6, 2019) is 1877 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 March 6, 2019 5 Expires: September 7, 2019 7 464XLAT Optimization for CDNs/Caches 8 draft-palet-v6ops-464xlat-opt-cdn-caches-00 10 Abstract 12 This document describes the drawbacks of IP/ICMP Translation 13 Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or 14 applications initiate traffic flows to dual-stack CDNs (Content 15 Delivery Networks) or Caches, which are forced to be translated back 16 to IPv4 by a NAT64. The document proposes possible solutions to 17 avoid that. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 7, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 55 3. DNS/Routing-based Solution Approach . . . . . . . . . . . . . 5 56 4. CLAT/DNS-proxy-EAMT-based Solution Approach . . . . . . . . . 6 57 5. CLAT-provider-EAMT-based Solution Approach . . . . . . . . . 7 58 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 Different transition mechanisms, typically in the group of the so- 68 called IPv6-only with IPv4aaS (IPv4-as-a-Service), such as 464XLAT 69 ([RFC6877]) or MAP-T ([RFC7599]), allow IPv4-only devices or 70 applications to connect with IPv4 services in Internet, by means of a 71 NAT46 SIIT (IP/ICMP Translation Algorithm) as described by [RFC7915]. 73 This is done by the implementation of SIIT at the CE (Customer Edge) 74 Router or sometimes a device, for example, the UE (User Equipment) in 75 cellular networks. This functionality is typically called CLAT 76 (Customer Translator). 78 The CLAT is then connected by IPv6-only to the operator network, 79 which in turn, will have a reverse function, the NAT64 ([RFC6146]), 80 also called PLAT (Provider Translator), in order to be able to 81 translate back the IPv6-only flow to IPv4 in order to forward it to 82 Internet. 84 The translation of the packet headers is done using the IP/ICMP 85 translation algorithm defined in [RFC7915] and algorithmically 86 translating the IPv4 addresses to IPv6 addresses following [RFC6052]. 88 Optionally, a DNS64 ([RFC6147]) is in charge of the synthesis of AAAA 89 records from the A records, so they can use a NAT64, without the need 90 of doing a double-translation by means of the CLAT. However, this is 91 not useful in the case of IPv4-only devices or applications in the 92 LANs. 94 A typical 464XLAT deployment is depicted in Figure 1. 96 +-------+ .-----. .-----. 97 | IPv6 | / \ / \ 98 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 99 / \ | or +--( only )---( NAT64 )---( Internet ) 100 / LAN's \ | UE | \ Access /\ `-----' \ / 101 ( Dual- )--+ | \ / \ \ / 102 \ Stack / | with | `--+--' \ .-----. `-----' 103 \ / | | | \ / \ 104 `-----' | CLAT | +---+----+ / IPv6 \ 105 | | | DNS/ | ( Internet ) 106 +-------+ | DNS64 | \ / 107 +--------+ \ / 108 `-----' 110 Figure 1: Typical 464XLAT Deployment 112 As it can be observed in the precedent picture the situation is the 113 same, regardless of in case of a wired network with a CE Router or a 114 cellular network where a UE is connecting other devices (which may 115 have IPv4-only apps), by means of a tethering functionality. 117 If the operator is providing direct access to Content Delivery 118 Networks (CDNs) or caches, and they are dual-stacked, the situation 119 can be described as shown in Figure 2. 121 +-------+ .-----. .-----. 122 | IPv6 | / \ / \ 123 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 124 / \ | or +--( only )---( NAT64 )---( Internet ) 125 / LAN's \ | UE | \ Access /\ `-----' \ / 126 ( Dual- )--+ | \ / \ \ / 127 \ Stack / | with | `--+--' \ .-----. `--+--' 128 \ / | | | \ / \ \ 129 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 130 | | | DNS/ | ( Internet ) / Dual- \ 131 +-------+ | DNS64 | \ /----/ Stack \ 132 +--------+ \ / ( ) 133 `-----' \ CDNs/ / 134 \ Caches/ 135 `-----' 137 Figure 2: Typical 464XLAT Deployment with CDNs/Caches 139 If the devices or applications in the customer LAN are IPv6-capable, 140 then the access to the CDNs or caches will be made by means of 141 IPv6-only, not using the NAT64, as depicted in Figure 3. 143 +-------+ .-----. .-----. 144 | IPv6 | / \ / \ 145 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 146 / \ | or +--( only )---( NAT64 )---( Internet ) 147 / IPv6 \ | UE | \ Access /\ `-----' \ / 148 ( capable )--+ | \ / \ \ / 149 \ apps / | with | `--+--' \ .-----. `--+--' 150 \ / | | | \ / \ 151 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 152 | | | DNS/ | ( Internet )IPv6/ Dual- \ 153 +-------+ | DNS64 | \ /----/ Stack \ 154 +--------+ \ / ( ) 155 `-----' \ CDNs/ / 156 \ Caches/ 157 `-----' 158 <---------------------- end-to-end IPv6 flow ----------------------> 160 Figure 3: 464XLAT access to CDNs/Caches by IPv6-capable apps 162 However, if the devices or applications are IPv4-only, for example, 163 most of the SmartTVs and Set-Top-Boxes available today, a double 164 translation will occur (NAT46 at the CLAT and NAT64 at the PLAT), as 165 illustrated in Figure 4. 167 +-------+ .-----. .-----. 168 | IPv6 | / \ / \ 169 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 170 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 171 / only \ | UE | \ Access /\ `-----' \ / 172 ( SmartTV )--+ | \ / \ \ / 173 \ STB / | with | `--+--' \ .-----. `--+--' 174 \ VoIP / | | | \ / \ \ IPv4 175 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 176 | | | DNS/ | ( Internet ) / Dual- \ 177 +-------+ | DNS64 | \ / / Stack \ 178 +--------+ \ / ( ) 179 `-----' \ CDNs/ / 180 \ Caches/ 181 `-----' 182 <-------------------- IPv4 to IPv6 to IPv4 flow --------------------> 184 Figure 4: 464XLAT access to CDNs/Caches by IPv4-only apps 186 Clearly, this is a non-optimal situation, as it means that even if 187 there is a dual-stack service, the CLAT translated IPv6 traffic flow 188 is forced to be translated again to IPv4, traversing the stateful 189 NAT64, impacting in the need to scale it beyond what will be needed 190 if we consider possible solutions in order to keep using the IPv6 191 path towards those services. 193 As show in the precedent picture, this is also the case for other 194 services, not just CDNs or caches, such as VoIP access to the 195 relevant operator infrastructure, which may be also dual-stack, but 196 is not commonly the case for many VoIP devices or applications. 198 This document looks into different possible solution approaches in 199 order to optimize the IPv4-only SIIT translation providing a direct 200 path to IPv6-capable services, as depicted in Figure 5. 202 +-------+ .-----. .-----. 203 | IPv6 | / \ / \ 204 .-----. | CE | / IPv6- \ .-----. / IPv4 \ 205 / IPv4- \ | or +--( only )---( NAT64 )---( Internet ) 206 / only \ | UE | \ Access /\ `-----' \ / 207 ( SmartTV )--+ | \ / \ \ / 208 \ STB / | with | `--+--' \ .-----. `--+--' 209 \ VoIP / | | | \ / \ 210 `-----' | CLAT | +---+----+ / IPv6 \ .--+--. 211 | | | DNS/ | ( Internet )IPv6/ Dual- \ 212 +-------+ | DNS64 | \ /----/ Stack \ 213 +--------+ \ / ( ) 214 `-----' \ CDNs/ / 215 \ Caches/ 216 `-----' 217 <------------------------ IPv4 to IPv6 flow ------------------------> 219 Figure 5: Optimized 464XLAT access to CDNs/Caches by IPv4-only apps 221 2. Requirements Language 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in BCP 226 14 [RFC2119] [RFC8174] when, and only when, they appear in all 227 capitals, as shown here. 229 3. DNS/Routing-based Solution Approach 231 Because the IPv4-only devices will not be able to query for AAAA 232 records, the NAT46/CLAT will translate the IPv4 addresses from the A 233 record for the CDN/cache destination, using the WKP or NSP, as 234 configured by the operator. 236 If the CDN/cache provider is able to configure in the relevant 237 interfaces of the CDN/caches the same IPv6 addresses that will 238 naturally result as the translated destination addresses for the 239 queried A records, preceded by the WKP or NSP, then having more 240 specific routing prefixes, will result in traffic to those 241 destinations being directly routed towards those interfaces, instead 242 of needing to traverse the NAT64. 244 For example, let's suppose a provider using the WKP (64:ff9b::/96) 245 and a SmartTV querying for www.example.com: 247 www.example.com A 192.0.2.1 248 CLAT translated to 64:ff9b::192.0.2.1 249 CDN IPv6 interface must be 64:ff9b::192.0.2.1 250 Operator must have a specific route to 64:ff9b::192.0.2.1 252 Because the WKP is non-routable, this will only be possible if the 253 CDN/cache is in the same ASN as the provider network, or somehow 254 interconnected without routing to Internet. 256 How to handle IP changes in the CDN. TBD. 258 4. CLAT/DNS-proxy-EAMT-based Solution Approach 260 If the CLAT, as commonly is the case, is also a DNS proxy/stub 261 resolver, it may be possible to modify the behavior, so when there is 262 a query for an A record, and there is not a query for the AAAA record 263 from the same source, the DNS resolver can actually "force" the AAAA 264 query. If the response doesn't contain the WKP or NSP, it means that 265 the destination is IPv6-capable, so the CLAT can create/update an 266 entry for an Explicit Address Mapping [RFC7757]. 268 This way, an EAMT is maintained automatically by the DNS proxy/stub 269 resolver in the CLAT, and the CLAT is responsible to prioritize any 270 available entries in the EAMT, versus the use of the synthetic AAAA. 272 Following this approach, the IPv6-native path will take precedence 273 and traffic will not be forwarded to the NAT64. 275 Using the same example as in the previous section: 277 www.example.com A 192.0.2.1 278 AAAA 2001:db8::192.0.2.1 279 EAMT entry 192.0.2.1 2001:db8::192.0.2.1 280 CLAT translated to 2001:db8::192.0.2.1 281 CDN IPv6 interface already is 2001:db8::192.0.2.1 282 Operator already has a specific route to 2001:db8::192.0.2.1 284 This mechanism will not work if the devices are configured to use a 285 DNS proxy/resolver which is not the CE/CLAT, but will not impact 286 negatively in the user's applications. However, users commonly, 287 don't change the configuration of devices such as SmartTVs or STBs 288 (if they do, some functionalities may not work). It is common that 289 users modify the DNS either in the operating systems (which commonly 290 are dual-stack, so aren't part of the problem being described by this 291 document), or the CE. In the case the DNS servers are modified in 292 the CE, this mechanism is not adversely affected. 294 5. CLAT-provider-EAMT-based Solution Approach 296 Instead of using the DNS proxy/stub resolver to create the EAMT 297 entries, the operator may push this table into the CE/CLAT, by using 298 configuration/management mechanisms. TBD. 300 This solution has the advantage of not being affected by any DNS 301 changes from the user and ensures a complete control from the 302 operator. 304 TBD. 306 6. Conclusions 308 TBD. Risks to consider. Because the apps are IPv4-only, Happy 309 Eyeballs will not be able to support breakage situations. If a CE is 310 misconfigured, even a small percentage of broken CEs may bring the 311 content providers to switch back to IPv4-only. So possible failure 312 cases need to be carefully considered for every possible solution 313 approach. 315 TBD. 317 7. Security Considerations 319 This document does not have any new specific security considerations. 321 8. IANA Considerations 323 This document does not have any new specific IANA considerations. 325 9. Acknowledgements 327 The authors would like to acknowledge the inputs of Erik Nygren and 328 TBD ... 330 Alejandro D'Egidio inspired working in this document by wondering if 331 464XLAT traffic to CDNs could be optimized in discussions in the 332 v6ops mailing list. 334 10. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 342 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 343 DOI 10.17487/RFC6052, October 2010, 344 . 346 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 347 NAT64: Network Address and Protocol Translation from IPv6 348 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 349 April 2011, . 351 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 352 Beijnum, "DNS64: DNS Extensions for Network Address 353 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 354 DOI 10.17487/RFC6147, April 2011, 355 . 357 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 358 Combination of Stateful and Stateless Translation", 359 RFC 6877, DOI 10.17487/RFC6877, April 2013, 360 . 362 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 363 and T. Murakami, "Mapping of Address and Port using 364 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 365 2015, . 367 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 368 Mappings for Stateless IP/ICMP Translation", RFC 7757, 369 DOI 10.17487/RFC7757, February 2016, 370 . 372 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 373 "IP/ICMP Translation Algorithm", RFC 7915, 374 DOI 10.17487/RFC7915, June 2016, 375 . 377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 379 May 2017, . 381 Author's Address 383 Jordi Palet Martinez 384 The IPv6 Company 385 Molino de la Navata, 75 386 La Navata - Galapagar, Madrid 28420 387 Spain 389 Email: jordi.palet@theipv6company.com 390 URI: http://www.theipv6company.com/