idnits 2.17.1 draft-palet-v6ops-464xlat-deployment-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6877]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 266: '... to deploy 464XLAT ([RFC6877]), MUST to support, at least, the...' RFC 2119 keyword, line 271: '... models, they MUST support the custo...' RFC 2119 keyword, line 275: '...ing DNSSEC, they MAY support DNS64. I...' RFC 2119 keyword, line 276: '...EC validation, then it MUST be in such...' RFC 2119 keyword, line 278: '...er approach, and MAY be combined as we...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2017) is 2386 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7278' is defined on line 379, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 6877 ** Downref: Normative reference to an Informational RFC: RFC 7278 Summary: 5 errors (**), 0 flaws (~~), 2 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 Consulintel, S.L. 4 Intended status: Best Current Practice October 8, 2017 5 Expires: April 11, 2018 7 464XLAT Deployment Guidelines in Operator Networks 8 draft-palet-v6ops-464xlat-deployment-00 10 Abstract 12 This document describes how 464XLAT ([RFC6877]) can be deployed in an 13 IPv6 operator network and the issues to be considered. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 11, 2018. 32 Copyright Notice 34 Copyright (c) 2017 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 3 51 2.1. DNSSEC validator aware of DNS64 . . . . . . . . . . . . . 4 52 2.2. Stub validator . . . . . . . . . . . . . . . . . . . . . 4 53 2.3. CLAT with DNS proxy and validator . . . . . . . . . . . . 4 54 2.4. ACL of clients . . . . . . . . . . . . . . . . . . . . . 4 55 2.5. Mapping-out IPv4 addresses . . . . . . . . . . . . . . . 4 56 3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . . . 5 57 4. DNS64 and Reverse Mapping Considerations . . . . . . . . . . 5 58 5. CLAT Translation Considerations . . . . . . . . . . . . . . . 6 59 6. Summary of deployment recommendations for 464XLAT . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 63 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 464XLAT ([RFC6877]) describes an architecture that provides IPv4 69 connectivity across a network, or part of it, when it is only 70 natively transporting IPv6. 72 In order to do that, 464XLAT ([RFC6877]) relies on the combination of 73 existing protocols: 75 1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6 76 translator (NAT46) ([RFC7915]) implemented in the end-user device 77 or CE, located at the "customer" edge of the network. 79 2. The provider-side translator (PLAT) is a stateful NAT64 80 ([RFC6146]), implemented typically at the opposite edge of the 81 operator network, that provides access to both IPv4 and IPv6 82 upstreams. 84 3. Optionally, DNS64 ([RFC6147]), implemented as part of the PLAT 85 allows an optimization (a single translation at the NAT64, 86 instead of two translations - NAT46+NAT64), when the application 87 at the end-user device supports IPv6 DNS (uses AAAA RR). 89 464XLAT ([RFC6877]) is a very simple approach to cope with the major 90 NAT64+DNS64 drawback: Not working with applications or devices that 91 use literal IPv4 addresses or non-IPv6 compliant APIs. 93 464XLAT ([RFC6877]) has been used initially in IPv6 cellular 94 networks, so providing an IPv6-only access network, the end-user 95 device applications can access IPv4-only end-networks/applications, 96 despite those applications or devices use literal IPv4 addresses or 97 non-IPv6 compliant APIs. 99 In addition to that, in the same example of the cellular network 100 above, if the User Equipment (UE) provides tethering, other devices 101 behind it will be presented with a traditional NAT44, in addition to 102 the native IPv6 support. 104 Furthermore, 464XLAT ([RFC6877]) can be used in non-cellular IPv6 105 wired (xDSL, DOCSIS, FTTH, Ethernet, ...) and wireless (WiFi) network 106 architectures, by implementing the CLAT functionality at the CE. 108 The remaining sections of this document, despite of any specific 109 examples being used, are applicable to any operator network 110 architecture, and introduces possible issues and general deployment 111 guidelines to be considered when deploying 464XLAT ([RFC6877]) in an 112 IPv6 network. 114 2. DNSSEC Considerations 116 As indicated in Section 8 of [RFC6147] (DNS64, Security 117 Considerations), because DNS64 modifies DNS answers and DNSSEC is 118 designed to detect such modifications, DNS64 can break DNSSEC. 120 If a device connected to an IPv6-only WAN queries for a domain name 121 in a signed zone, by means of a recursive name server that supports 122 DNS64, and the result is a synthesized AAAA record, and the recursive 123 name server is configured to perform DNSSEC validation and has a 124 valid chain of trust to the zone in question, it will 125 cryptographically validate the negative response from the 126 authoritative name server. So, the recursive name server actually 127 lie to the client device, however in most of the cases, the client 128 will not notice it, because generally they don't perform validation 129 themselves as instead rely on their recursive name servers. 131 If the client device performs DNSSEC validation on the AAAA record, 132 it will fail as it is a synthesized record. 134 Similarly, if the client querying the recursive name server is 135 another name server configured to use it as a forwarder, and is 136 performing DNSSEC validation, it will also fail on any synthesized 137 AAAA record. 139 There are several possible solutions to avoid breaking DNSSEC: 141 2.1. DNSSEC validator aware of DNS64 143 In general, DNS servers with DNS64 function, by default, will not 144 synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the 145 query. In this case, as only an A record is available, it means that 146 the CLAT will take the responsibility, as in the case of literal IPv4 147 addresses, to keep that traffic flow end-to-end as IPv4, so DNSSEC is 148 not broken. 150 2.2. Stub validator 152 If the DO flag is set and the client device performs DNSSEC 153 validation, and the Checking Disabled (CD) flag is set for a query, 154 as the DNS64 recursive server will not synthesize AAAA responses, the 155 client could perform the DNSSEC validation with the A record and then 156 may query the network for a NAT64 prefix ([RFC7050]) in order to 157 synthesize the AAAA ([RFC6052]). This allows the client device to 158 avoid using the CLAT and still use NAT64 even with DNSSEC. 160 Some devices/OSs may implement, instead of CLAT, a simliar function 161 by using Bump-in-the-Host ([RFC6535]). In this case, the 162 considerations in the above paragraphs are also applicable. 164 2.3. CLAT with DNS proxy and validator 166 If a CE includes CLAT support and also a DNS proxy, as indicated in 167 Section 6.4 of [RFC6877], the CE could behave as a stub validator on 168 behalf of the client devices, following the same approach described 169 in the precedent section (Stub validator). So the DNS proxy actually 170 lie to the client devices, which in most of the cases will not notice 171 it unless they perform validation themselves. Again, this allow the 172 clients devices to avoid using the CLAT and still use NAT64 with 173 DNSSEC. 175 2.4. ACL of clients 177 In cases of dual-stack clients, stub resolvers should send the AAAA 178 queries before the A ones. So such clients, if DNS64 is enabled, 179 will never get A records, even for IPv4-only servers, and they may be 180 in the path before the NAT64 and accesible by IPv4. If DNSSEC is 181 being used for all those flows, specific addresses or prefixes can be 182 left-out the DNS64 synthesis by means of ACLs. 184 2.5. Mapping-out IPv4 addresses 186 If there are well-known specific IPv4 addresses or prefixes using 187 DNSSEC, they can be mapped-out of the DNS64 synthesis. 189 Even if this is not related to DNSSEC, this "mapping-out" feature is 190 actually quite commonly used to ensure that [RFC1918] addresses (for 191 example used by LAN servers) are not synthesized to AAAA. 193 3. Using 464XLAT with/without DNS64 195 In the case the client device is IPv6-only (either because the stack 196 is IPv6-only, or because it is connected via an IPv6-only LAN) and 197 the server is IPv4-only (either because the stack is IPv4-only, or 198 because it is connected via an IPv4-only LAN), only NAT64 combined 199 with DNS64 will be able to provide access among both. Because DNS64 200 is then required, DNSSEC validation will be only possible if the 201 recursive name server is validating the negative response from the 202 authoritative name server and the client is not performing 203 validation. 205 However, when the client device is dual-stack and/or connected in a 206 dual-stack LAN by means of a CLAT (or has the built-in CLAT), DNS64 207 is an option. 209 1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if 210 using literal IPv4 addresses or non-IPv6 compliant APIs) will not 211 use the CLAT, so will use the IPv6 path and only one translation 212 will be done at the NAT64. This may break DNSSEC, unless 213 measures as described in the precedent section are taken. 215 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will 216 make use of the CLAT, so two translations are required (NAT46 at 217 the CLAT and NAT64 at the PLAT), which adds some overhead in 218 terms of the extra NAT46 translation, however avoids the AAAA 219 synthesis and consequently will never break DNSSEC. 221 When clients in an operator network use DNS from other networks, for 222 example manually configured by users, they may support or not DNS64, 223 so the considerations in this section will apply as well. 225 4. DNS64 and Reverse Mapping Considerations 227 When a client device, using a name server configured to perform 228 DNS64, tries to reverse-map a synthesized IPv6 address, the name 229 server responds with a CNAME record pointing the domain name used to 230 reverse-map the synthesized IPv6 address (the one under ip6.arpa), to 231 the domain name corresponding to the embedded IPv4 address (under in- 232 addr.arpa). 234 This is the expected behaviour, so no issues to be considered 235 regarding DNS reverse mapping. 237 5. CLAT Translation Considerations 239 As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if 240 the CLAT can be configured with a dedicated /64 prefix for the NAT64 241 translation, then it will be possible to do a more efficient 242 stateless translation. 244 However, if this dedicated prefix is not available, the CLAT will 245 need to do a stateful translation, for example performing stateful 246 NAT44 for all the IPv4 LAN packets, so they appear as coming from a 247 single IPv4 address, and then in turn, stateless translated to a 248 single IPv6 address. 250 The obvious recommended setup, in order to maximize the CLAT 251 performance, is to configure the dedicated translation prefix. This 252 can be easily achieved automatically, if the CE or end-user device is 253 able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]), so 254 the CE can use a /64 for that. 256 The above recommendation is often not posible for cellular networks, 257 when connecting UEs (some broadband cellular use DHCPv6-PD 258 ([RFC3633]), but smartphones, in general, not), as they provide a 259 single /64 for each PDP context and use /64 prefix sharing 260 ([RFC6877]). So in this case, the UEs typically have a build-in CLAT 261 client, which is doing a stateful NAT44 before the stateless NAT46. 263 6. Summary of deployment recommendations for 464XLAT 265 As indicated in the introduction of this document, operators willing 266 to deploy 464XLAT ([RFC6877]), MUST to support, at least, the 267 provider-side translator (PLAT). 269 In the case it is a non-cellular network and the operator is 270 providing the CEs to the customers, or suggesting them some specific 271 models, they MUST support the customer-side translator (CLAT). 273 If the operator offers DNS services, in order to increase performance 274 by reducing the double translation for all the IPv4 traffic, and 275 avoid breaking DNSSEC, they MAY support DNS64. In this case, if the 276 DNS service is offering DNSSEC validation, then it MUST be in such 277 way that it is aware of the DNS64. This is considered de simpler and 278 safer approach, and MAY be combined as well with the other possible 279 solutions described in this document: 281 o Devices running CLAT SHOULD follow the indications in the "Stub 282 validator" section recommendation. However, most of the time, 283 this is out of the control of the operator. 285 o CEs SHOULD include a DNS proxy and validador. This is relevant if 286 the operator is providing the CE or suggesting it to customers. 288 o ACL of clients and Mapping-out IPv4 addresses MAY be considered by 289 each operator, depending on their own infrastructure. 291 The ideal configuration for CEs supporting CLAT, is that they support 292 DHCPv6-PD ([RFC3633]) and internally reserve one /64 for the 293 stateless NAT46 translation. The operator MUST ensure that the 294 customers get allocated prefixes shorter than /64 in order to support 295 this optimization. One way or the other, this is not impacting the 296 performance of the operator network. 298 As indicated in Section 7 of [RFC6877] (Deployment Considerations), 299 operators MAY follow those suggestions in order to take advantage of 300 traffic engineering. 302 In the case of cellular networks, the considerations regarding DNSSEC 303 may appear as out-of-scope, because UEs OSs, commonly don't support 304 DNSSEC, however applications running on them may do, or it may be an 305 OS "built-in" support in the future. Moreover, if those devices 306 offer tethering, other client devices may be doing the validation, 307 hence the relevance of a proper DNSSEC support by the operator 308 network. 310 Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and 311 "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" 312 ([RFC7050]), allow a progressive IPv6 deployment, with a single APN 313 supporting all types of PDP context (IPv4, IPv6, IPv4v6), in such way 314 that the network is able to automatically serve all the possible 315 combinations of UEs. 317 Finally, if the operator choose to secure the NAT64 prefix, it MUST 318 follow the advise indicated in Section 3.1.1. of [RFC7050] 319 (Validation of Discovered Pref64::/n). 321 7. Security Considerations 323 This document does not have any new specific security considerations. 325 8. IANA Considerations 327 This document does not have any new specific IANA considerations. 329 9. Acknowledgements 331 The author would like to acknowledge the inputs of TBD ... Christian 332 Huitema inspired working in this document by suggesting that DNS64 333 should never be used, during a discussion regarding the deployment of 334 CLAT in the IETF network. 336 10. Normative References 338 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 339 and E. Lear, "Address Allocation for Private Internets", 340 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 341 . 343 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 344 Host Configuration Protocol (DHCP) version 6", RFC 3633, 345 DOI 10.17487/RFC3633, December 2003, 346 . 348 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 349 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 350 DOI 10.17487/RFC6052, October 2010, 351 . 353 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 354 NAT64: Network Address and Protocol Translation from IPv6 355 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 356 April 2011, . 358 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 359 Beijnum, "DNS64: DNS Extensions for Network Address 360 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 361 DOI 10.17487/RFC6147, April 2011, 362 . 364 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 365 Using "Bump-in-the-Host" (BIH)", RFC 6535, 366 DOI 10.17487/RFC6535, February 2012, 367 . 369 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 370 Combination of Stateful and Stateless Translation", 371 RFC 6877, DOI 10.17487/RFC6877, April 2013, 372 . 374 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 375 the IPv6 Prefix Used for IPv6 Address Synthesis", 376 RFC 7050, DOI 10.17487/RFC7050, November 2013, 377 . 379 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 380 /64 Prefix from a Third Generation Partnership Project 381 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 382 DOI 10.17487/RFC7278, June 2014, 383 . 385 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 386 "IP/ICMP Translation Algorithm", RFC 7915, 387 DOI 10.17487/RFC7915, June 2016, 388 . 390 Author's Address 392 Jordi Palet Martinez 393 Consulintel, S.L. 394 Molino de la Navata, 75 395 La Navata - Galapagar, Madrid 28420 396 Spain 398 Email: jordi.palet@consulintel.es 399 URI: http://www.consulintel.es/