idnits 2.17.00 (12 Aug 2021) /tmp/idnits60806/draft-boucadair-dnsop-prefix64-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 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (5 January 2022) is 129 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ThisDocument' is mentioned on line 305, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft Orange 4 Updates: 6147 (if approved) 5 January 2022 5 Intended status: Standards Track 6 Expires: 9 July 2022 8 An EDNS0 Option for Sharing Pref64::/n 9 draft-boucadair-dnsop-prefix64-02 11 Abstract 13 This document specifies an Extension Mechanisms for DNS (EDNS0) 14 option to convey the IPv6 prefix used to build IPv4-converted IPv6 15 addresses. When conveyed in a DNS query, the option communicates the 16 IPv6 prefix used in the network from which the query was originated. 17 Such a network is assumed to enable a Network Address and Protocol 18 Translation from IPv6 clients to IPv4 servers (NAT64) function. 19 DNS64-capable servers will use that prefix to build synthesized AAAA 20 records, rather than relying on a preconfigured prefix. When 21 conveyed in a DNS reply, the option conveys the IPv6 prefix that is 22 used by a DNS64-capable server to synthesized AAAA records. Such 23 information helps to automatically detect mismatches between the 24 local NAT64 configuration and the one enforced at the DNS64 server. 25 Also, security-aware and validating hosts may use the new EDNS0 26 option to signal the presence of a NAT64 function. That signal is 27 used by the DNS server to fill the additional section of the AAAA 28 reply in order to supply A RRs of the target. Dual queries and 29 delays are thus avoided. 31 This document updates RFC 6147. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 9 July 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 8.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 Network Address and Protocol Translation from IPv6 clients to IPv4 81 servers (NAT64) function [RFC6146] is widely deployed, especially in 82 cellular networks. Such a function is solicited when an IPv6-only 83 host communicates with an IPv4-only server. For that communication 84 to take place, IPv4-only servers are represented in the IPv6 domain 85 by synthesizing IPv6 addresses based on IPv4 addresses (called, 86 IPv4-converted IPv6 addresses). The address translation algorithm is 87 specified in [RFC6052]. In addition to an IPv4 address, this 88 algorithm uses a dedicated IPv6 prefix as input. Such a prefix can 89 be the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network-Specific 90 Prefix (NSP). 92 DNS64 [RFC6147] specifies a companion mechanism to represent 93 IPv4-only servers in the IPv6 domains. Such a mechanism relies upon 94 the same address translation algorithm as the one used by the NAT64 95 function. When both DNS64 and NAT64 are deployed in the same 96 network, the same IPv6 prefix must be used to feed the address 97 translation algorithm (Section 2 of [RFC6147]). A sample deployment 98 scenario is depicted in Figure 1. Note that no mechanism is 99 supported to synchronize the prefix configured in both functions. In 100 particular, there is no communication between the DNS64 and NAT64 101 functions. 103 +---------------------+ +---------------+ 104 |IPv6 network | | IPv4 | 105 | | +-------------+ | network | 106 | |--| Name server |--| | 107 | | | with DNS64 | | +----+ | 108 | +----+ | +-------------+ | | H2 | | 109 | | H1 |---| | | +----+ | 110 | +----+ | +-------+ | 192.0.2.1 | 111 |2001:db8::1|------| NAT64 |----| | 112 | | +-------+ | | 113 | | | | | 114 +---------------------+ +---------------+ 116 Figure 1: Sample Deployment (RFC6146) 118 In networks where DNS64 is enabled, some deployments use distinct IP 119 addresses to reach the "normal" DNS server and the DNS64 server. 120 This is used to demux queries issues by IPv6-only hosts from those 121 from dual-stack hosts. The mechanism defined in this document allows 122 to use the same DNS configuration for both IPv6-only and dual-stack 123 hosts. 125 NAT64 does not require a DNS64 server to be enabled and, even if it 126 is used, it does not mandate that it is enabled in the same network. 127 As such, several public DNS64 servers are currently available for use 128 over the Internet. However, these servers are restricted to the 129 Well-Known Prefix. Users who decides to bypass their network- 130 provisioned DNS64 server (e.g., including both trusted (access 131 network, typically) and untrusted networks such as Airports) may 132 experience connectivity issues if an NSP is used in their local 133 networks (Section 4.4 of [RFC8683]). This document solves that 134 issues by specifying a mechanism that allows to use any DNS64 server, 135 not only the one hosted in the network that enables the NAT64. 137 If the IPv4 address of a remote IPv4-only server is known to an 138 IPv6-only host (e.g., IPv4 literals, legacy DNS), the IPv6-only host 139 can proceed with local address synthesis. For example, the stub 140 resolver on the IPv6-only host tries to obtain (native) AAAA records, 141 and if they are not found, the DNS64 function on the host will send a 142 query for A records and then synthesize AAAA records. This behavior 143 requires the host's stub-resolver to learn the prefix used for IPv6/ 144 IPv4 translation and synthesize AAAA records accordingly. Many 145 mechanisms were specified to discover such prefix, e.g.: 147 * [RFC7225] defines a new Port Control Protocol (PCP) option 148 [RFC6887] to inform hosts about the Pref64::/n and suffix used by 149 a NAT64 function. 151 * [RFC8781] specifies a Neighbor Discovery option used in Router 152 Advertisements (RAs) to communicate NAT64 prefixes to hosts. 154 The reader may refer to [RFC7050][RFC7051] for an analysis on the 155 issues related to the discovery of the Pref64::/n. 157 In some environments two DNS queries are issued even if the host is 158 serviced using an IPv6-only connectivity (typically, AAAA followed by 159 A). These two queries are sent sequentially, which introduces an 160 extra delay when the target resource is IPv4-only. Such delay can be 161 prevented owing to the mechanism specified in this document. As a 162 side effect, the mechanism optimizes the load on DNS64 servers as 163 only one query will be used instead of two. 165 This document updates [RFC6146] as it extends the DNS64 processing to 166 also consider the supplied Pref64::/n in an EDNS0 option to 167 synthesize AAA records. In particular statements such as "locally 168 configured Pref64::/n" are updated to "locally configured Pref64::/n 169 or Pref64::/n supplied in an EDNS0 PREFIX64 option". To that aim, 170 this document leverages the aforementioned discovery mechanism to 171 detect the presence of a NAT64 function. 173 In summary, the mechanism defined in this document is meant to: 175 * Provide a signal to indicate the support of NAT64 in a network. 177 * Allow a DNS64 server to service clients with distinct NAT64 178 prefixes. 180 * Avoid delays when both A and AAA queries are required. 182 * Optimize load on DNS server as only one query is generated rather 183 that duplicating load when both AAA and A queries are required. 185 2. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in BCP 190 14 [RFC2119][RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 The reader should be familiar with terms and concepts defined in 194 [RFC6052], [RFC6146], and [RFC6147]. Also, the document makes use of 195 terms defined in [RFC8499]. 197 "IPv6-only host" refers to a host with an IPv6-only connectivity. 199 3. Option Format 201 The format of the PREFIX64 EDNS0 option is shown in Figure 2. This 202 format adheres to the guidelines specified in Section 6.1.2 of 203 [RFC6891]. 205 +0 (MSB) +1 (LSB) 206 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 207 0: | OPTION-CODE | 208 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 209 2: | OPTION-LENGTH | 210 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 4: | | 212 / PREFIX64 / 213 / / 214 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 216 Figure 2: PREFIX64 EDNS0 Option Format 218 The description of the fields is as follows: 220 OPTION-CODE: MUST be set to TBA (Section 6). 222 OPTION-LENGTH: Size (in octets) of the enclosed Pref64::/n. Allowed 223 values are: 0, 4, 5, 6, 7, 8, and 9. 225 The receiver MUST ignore the option if the OPTION-LENGTH is not 226 set to one of those values. 228 When the value is set to 0, this indicates the presence of a NAT64 229 function in the network from which the query is generated. 231 PREFIX64: This field identifies the IPv6 unicast prefix to be used 232 for constructing an IPv4-converted IPv6 address from an IPv4 233 address as specified in Section 2.2 of [RFC6052]. In such case, 234 the prefix length MUST be 32, 40, 48, 56, 64, and 96 bits (i.e., 235 OPTION-LENGTH must be set to 4, 5, 6, 7, 8, and 9) as specified in 236 [RFC6052]. 238 This prefix can be the Well-Known Prefix (i.e., 64:ff9b::/96) or a 239 Network-Specific Prefix. 241 The address synthesis MUST follow the guidelines documented in 242 [RFC6052]. 244 4. Protocol Description 246 A stub-resolver on an IPv6-only host that discovers the presence of 247 NAT64 inserts the PREFIX64 EDNS0 option in its AAAA queries. If the 248 stub-resolver is on a multi-interfaced device, the Pref64::/n 249 conveyed in the PREFIX64 EDNS0 option MUST be the one that is 250 associated with the interface over which the DNS query is sent. 252 A stub-resolver that is prepared to handle A RRs enclosed in the 253 additional section (e.g., security-aware and validating hosts) MAY 254 insert a PREFIX64 EDNS0 option with an OPTION-LENGTH set to zero in 255 its AAAA DNS queries. Such option is used by intermediate/ 256 authoritative servers as a signal to include A RR in the additional 257 section. 259 If a DNS server enables a DNS64 function, then the AAAA query is 260 treated as in [RFC6147] with the exception that supplied valid 261 Pref64::/n are used for synthesizing AAAA records. The reply MAY 262 echo the PREFIX64 EDNS0 option. 264 A DNS forwarder MAY be configured to forward AAAA queries that carry 265 an PREFIX64 EDNS0 option with non-null prefixes to a DNS64 server. 266 Such queries are thus relayed to that DNS64 server. Upon receipt of 267 such queries, the AAAA query is treated as in [RFC6147] with the 268 exception that supplied valid Pref64::/n are used for synthesizing 269 AAAA records. This prevents from exposing distinct IP addresses of 270 DNS servers for "normal" DNS and DNS64 operations. 272 A DNS64 MAY be instructed to return the Pref64::/n that it uses when 273 synthesizing AAAA records. If so, the DNS64 MUST include the 274 PREFIX64 option in its replies that carry synthesized AAAA records. 275 This is superior to the current situation where users have to check 276 the documentation (when available) to determine the prefix used by a 277 DNS64 server for address synthesis. Absent such checks, errors can 278 be encountered to service IPv6-only hosts. The use of PREFIX64 279 option allows to automatically detect mismatches between the prefix 280 used in the network (that is, the NAT64 function) and the one that is 281 used by a DNS64 function. 283 A stub-resolver SHOULD determine whether the returned AAAA includes a 284 native or IPv4-converted IPv6 by comparing the first bits of the IPv6 285 address with the local Pref64::/n. This check is also meant to 286 determine that an on-path attacker has modified the PREFIX64 option. 288 5. Security Considerations 290 Generic EDNS0 security considerations are discussed in Section 8 of 291 [RFC6891]. 293 As discussed in Section 5.5 of [RFC6147], a security-aware and 294 validating host has to perform the DNS64 function locally. This 295 specification does not prevent that. The only enhancement is the 296 receipt of A RRs in the additional section of AAAA replies. 298 6. IANA Considerations 300 This document requests IANA to assign the following new code from the 301 "DNS EDNS0 Option Codes (OPT)" registry available at [DNS-OPT]: 303 Value Name Status Reference 304 ----- -------- -------- ------------- 305 TBA PREFIX64 Standard [ThisDocument] 307 7. Acknowledgements 309 Thanks to Tiru Reddy for the comments. 311 8. References 313 8.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 321 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 322 DOI 10.17487/RFC6052, October 2010, 323 . 325 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 326 NAT64: Network Address and Protocol Translation from IPv6 327 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 328 April 2011, . 330 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 331 Beijnum, "DNS64: DNS Extensions for Network Address 332 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 333 DOI 10.17487/RFC6147, April 2011, 334 . 336 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 337 for DNS (EDNS(0))", STD 75, RFC 6891, 338 DOI 10.17487/RFC6891, April 2013, 339 . 341 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 342 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 343 May 2017, . 345 8.2. Informative References 347 [DNS-OPT] IANA, "DNS EDNS0 Option Codes (OPT)", 348 . 351 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 352 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 353 DOI 10.17487/RFC6887, April 2013, 354 . 356 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 357 the IPv6 Prefix Used for IPv6 Address Synthesis", 358 RFC 7050, DOI 10.17487/RFC7050, November 2013, 359 . 361 [RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of 362 Solution Proposals for Hosts to Learn NAT64 Prefix", 363 RFC 7051, DOI 10.17487/RFC7051, November 2013, 364 . 366 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 367 Port Control Protocol (PCP)", RFC 7225, 368 DOI 10.17487/RFC7225, May 2014, 369 . 371 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 372 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 373 January 2019, . 375 [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for 376 NAT64/464XLAT in Operator and Enterprise Networks", 377 RFC 8683, DOI 10.17487/RFC8683, November 2019, 378 . 380 [RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router 381 Advertisements", RFC 8781, DOI 10.17487/RFC8781, April 382 2020, . 384 Author's Address 386 Mohamed Boucadair 387 Orange 388 35000 Rennes 389 France 391 Email: mohamed.boucadair@orange.com