idnits 2.17.1 draft-cheshire-sudn-ipv4only-dot-arpa-09.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 ([RFC7050]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 20 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC7050, but the abstract doesn't seem to directly say this. It does mention RFC7050 though, so this could be OK. 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 (May 1, 2018) is 2180 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) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cheshire 3 Internet-Draft D. Schinazi 4 Updates: 7050 (if approved) Apple Inc. 5 Intended status: Standards Track May 1, 2018 6 Expires: November 2, 2018 8 Special Use Domain Name 'ipv4only.arpa' 9 draft-cheshire-sudn-ipv4only-dot-arpa-09 11 Abstract 13 The specification for how a client discovers its network's NAT64 14 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this 15 purpose, but declares it to be a non-special name in that 16 specification's Domain Name Reservation Considerations section. 18 Consequently, despite the well articulated special purpose of the 19 name, 'ipv4only.arpa' was not recorded in the Special-Use Domain 20 Names registry as a name with special properties. 22 As a result of this omission, in cases where software needs to give 23 this name special treatment in order for it to work correctly, there 24 was no clear mandate authorizing software authors to implement that 25 special treatment. Software implementers were left with the choice 26 between not implementing the special behavior necessary for the name 27 queries to work correctly, or implementing the special behavior and 28 being accused of being noncompliant with some RFC. 30 This document formally declares the actual special properties of the 31 name, and adds similar declarations for the corresponding reverse 32 mapping names. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 2, 2018. 50 Copyright Notice 52 Copyright (c) 2018 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 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 1. Introduction 67 The specification for how a client discovers its network's NAT64 68 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this 69 purpose, but declares it to be a non-special name in that 70 specification's Domain Name Reservation Considerations section. 72 Consequently, despite the well articulated special purpose of the 73 name, 'ipv4only.arpa' was not recorded in the Special-Use Domain 74 Names registry [SUDN] as a name with special properties. 76 This omission was discussed in the Special-Use Domain Names Problem 77 Statement [RFC8244]. 79 As a result of this omission, in cases where software needs to give 80 this name special treatment in order for it to work correctly, there 81 was no clear mandate authorizing software authors to implement that 82 special treatment. Software implementers were left with the choice 83 between not implementing the special behavior necessary for the name 84 queries to work correctly, or implementing the special behavior and 85 being accused of being noncompliant with some RFC. 87 This document formally declares the actual special properties of the 88 name, and adds similar declarations for the corresponding reverse 89 mapping names. 91 2. Specialness of 'ipv4only.arpa' 93 The hostname 'ipv4only.arpa' is peculiar in that it was never 94 intended to be treated like a normal hostname. 96 A typical client never looks up the IPv4 address records for 97 'ipv4only.arpa', because it is already known, by specification 98 [RFC7050], to have exactly two IPv4 address records, 192.0.0.170 and 99 192.0.0.171. No client ever has to look up the name in order to 100 learn those two addresses. 102 In contrast, clients often look up the IPv6 AAAA address records for 103 'ipv4only.arpa', which is contrary to general DNS expectations, given 104 that it is already known, by specification [RFC7050], that no such 105 IPv6 AAAA address records exist. And yet, clients expect to receive, 106 and do in fact receive, positive answers for these IPv6 AAAA address 107 records that are known to not exist. 109 This is clearly not a typical DNS name. In normal operation, clients 110 never query for the two records that do in fact exist; instead they 111 query for records that are known to not exist, and then get positive 112 answers to those abnormal queries. Clients are using DNS to perform 113 queries for this name, but they are certainly not using DNS to learn 114 legitimate answers from the name's legitimate authoritative server. 115 Instead, these clients have, in effect, co-opted the DNS protocol as 116 an impromptu client-to-middlebox communication protocol, to 117 communicate with the NAT64/DNS64 [RFC6146] [RFC6147] gateway, if 118 present, and request that it disclose the prefix it is using for IPv6 119 address synthesis. 121 It is this use of specially-crafted DNS queries as an impromptu 122 client-to-middlebox communication protocol that makes the name 123 'ipv4only.arpa' most definitely a special name, and one that needs to 124 be listed in IANA's registry along with other DNS names that have 125 special uses [SUDN]. 127 3. Consequences of 'ipv4only.arpa' previously being declared unspecial 129 As a result of the original specification [RFC7050] not formally 130 declaring 'ipv4only.arpa' to have special properties, there was no 131 mandate for any DNS software to treat this name specially. 132 Consequently, queries for this name had to be handled normally, 133 resulting in unnecessary queries to the authoritative 'arpa' name 134 servers. 136 Having millions of devices around the world issue these queries 137 generated pointless additional load on the authoritative 'arpa' name 138 servers, which was completely unnecessary when the name 139 'ipv4only.arpa' is defined, by Internet Standard, to have exactly two 140 IPv4 address records, 192.0.0.170 and 192.0.0.171, and no other 141 records of any type. 143 Also, at times, for reasons that remain unclear, the authoritative 144 'arpa' name servers have been observed to be slow or unresponsive. 145 The failures of these 'ipv4only.arpa' queries result in unnecessary 146 failures of software that depends on them for DNS64 [RFC6147] address 147 synthesis. 149 Even when the authoritative 'arpa' name servers are operating 150 correctly, having to perform an unnecessary query to obtain an answer 151 that is already known in advance can add precious milliseconds of 152 delay for no reason. 154 A more serious problem occurs when a device is configured to use a 155 recursive resolver other than the one it learned from the network. 156 Typically a device joining a NAT64 network will learn the recursive 157 resolver recommended for that network either via IPv6 Router 158 Advertisement Options for DNS Configuration [RFC6106] or via DNS 159 Configuration options for DHCPv6 [RFC3646]. On a NAT64 network it is 160 essential that the client use the DNS64 recursive resolver 161 recommended for that network, since only that recursive resolver can 162 be relied upon to know the appropriate prefix(es) to use for 163 synthesizing IPv6 addresses that will be acceptable to the NAT64 164 gateway. 166 However, it is increasingly common for users to manually override 167 their default DNS configuration because they wish to use some other 168 public recursive resolver on the Internet, which may offer better 169 speed, better reliability, or better privacy than the local network's 170 default recursive resolver. At the time of writing, examples of 171 widely known public recursive resolver services include 1.1.1.1, 172 8.8.8.8, and 9.9.9.9. 174 Another common scenario is the use of corporate VPN client software, 175 which overrides the local network's default configuration to divert 176 DNS requests to the company's own private internal recursive 177 resolver, because the local network's recursive resolver will 178 typically be unable to provide answers for the company's private 179 internal host names. Similarly, the company's private internal 180 recursive resolver may not be able to synthesize IPv6 addresses 181 correctly for use with the local network's NAT64 gateway, because it 182 is unlikely to be aware of the NAT64 prefix in use on the local 183 network. It is clear that a single recursive resolver cannot meet 184 both needs. The local network's recursive resolver cannot give 185 answers for some company's private internal host names, and some 186 company's private internal recursive resolver cannot give correctly 187 synthesized IPv6 addresses suitable for the local network's NAT64 188 gateway. 190 The conflict here arises because DNS is being used for two unrelated 191 purposes. The first purpose is retrieving data from a (nominally) 192 global database -- generally retrieving the IP address(es) associated 193 with a hostname. The second purpose is using the DNS protocol as a 194 middlebox communication protocol, to interrogate the local network 195 infrastructure to discover the IPv6 prefix(es) in use by the local 196 NAT64 gateway for address synthesis. 198 Possibly this problem could have been avoided if we had forced all 199 NAT64 gateways to use the same Well-Known Prefix for IPv6 address 200 synthesis [RFC6052]. If the decision had been made to use a single 201 fixed Well-Known Prefix, then there would have been no need for 202 clients to discover the local network's NAT64 prefix, and no need for 203 the 'ipv4only.arpa' [RFC7050] query. However, that was not the 204 decision that was made. 206 This document leverages operational experience to update the Domain 207 Name Reservation Considerations [RFC6761] section of the earlier 208 specification [RFC7050] with one that accurately lists the actual 209 special properties of the name 'ipv4only.arpa', so that software can 210 legitimately implement the correct behavior necessary for better 211 performance, better reliability, and correct operation. 213 4. Security Considerations 215 Hard-coding the known answers for 'ipv4only.arpa' queries in 216 recursive resolvers reduces the risk of malicious devices 217 intercepting those queries and returning incorrect answers, 218 particularly in the case of recursive resolvers that do not perform 219 DNSSEC validation. 221 One of the known concerns with DNS64 [RFC6147] is that it interferes 222 with DNSSEC. DNSSEC may cryptographically assert that a name has no 223 IPv6 AAAA records, while at the same time DNS64 address synthesis is 224 contradicting this and claiming that IPv6 AAAA records do exist. 226 Section 3 of the DNS64 specification [RFC6147] discusses this: 228 ... DNS64 receives a query with the DO bit set and 229 the CD bit set. In this case, the DNS64 is supposed 230 to pass on all the data it gets to the query initiator. 231 This case will not work with DNS64, unless the 232 validating resolver is prepared to do DNS64 itself. 234 The NAT64 Prefix Discovery specification [RFC7050] provides the 235 mechanism for the query initiator to learn the NAT64 prefix so that 236 it can do its own validation and DNS64 synthesis as described above. 237 With this mechanism the client can (i) interrogate the local NAT64/ 238 DNS64 gateway with an 'ipv4only.arpa' query to learn the IPv6 address 239 synthesis prefix, (ii) query for the (signed) IPv4 address records 240 itself, and then (iii) perform its own IPv6 address synthesis 241 locally, combining the IPv6 address synthesis prefix learned from the 242 local NAT64/DNS64 gateway with the secure DNSSEC-signed data learned 243 from the global Domain Name System. 245 It is conceivable that over time, if DNSSEC is successful, the 246 majority of clients could move to this validate-and-synthesize- 247 locally model, which reduces the DNS64 machinery to the vestigial 248 role of simply responding to the 'ipv4only.arpa' query to report the 249 local IPv6 address synthesis prefix. In no case does the client care 250 what answer(s) the authoritative 'arpa' name servers might give for 251 that query. The 'ipv4only.arpa' query is being used purely as a 252 local client-to-middlebox communication message. 254 This approach is even more attractive if it does not create an 255 additional dependency on the authoritative 'arpa' name servers to 256 answer a query that is unnecessary because the NAT64/DNS64 gateway 257 already knows the answer before it even issues the query. Avoiding 258 this unnecessary query improves performance and reliability for the 259 client, and reduces unnecessary load for the authoritative 'arpa' 260 name servers. 262 5. IANA Considerations 264 [Once published, this should say] 266 IANA has recorded the following names in the 267 Special-Use Domain Names registry [SUDN]: 269 ipv4only.arpa. 270 170.0.0.192.in-addr.arpa. 271 171.0.0.192.in-addr.arpa. 273 IANA has recorded the following IPv4 addresses in the 274 IPv4 Special-Purpose Address Registry [SUv4]: 276 192.0.0.170 277 192.0.0.171 279 6. Domain Name Reservation Considerations 281 6.1. Conventions and Terminology Used in this Section 283 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 284 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 285 and "OPTIONAL" in this section are to be interpreted as described 286 in "Key words for use in RFCs to Indicate Requirement Levels", 287 when, and only when, they appear in all capitals, as shown here 288 [RFC2119] [RFC8174]. 290 6.2. Special Use Domain Name 'ipv4only.arpa' 292 The name 'ipv4only.arpa' is defined, by Internet Standard, to have 293 two IPv4 address records with rdata 192.0.0.170 and 192.0.0.171. 295 When queried via a DNS64 [RFC6147] recursive resolver, the name 296 'ipv4only.arpa' is also defined to have IPv6 AAAA records, with rdata 297 synthesized from a combination of the NAT64 IPv6 prefix(es) and the 298 IPv4 addresses 192.0.0.170 and 192.0.0.171. This can return more 299 than one pair of IPv6 addresses if there are multiple NAT64 prefixes. 301 The name 'ipv4only.arpa' has no other DNS records of any type. 302 There are no subdomains of ipv4only.arpa. All names falling below 303 'ipv4only.arpa' are defined to be nonexistent (NXDOMAIN). 305 The name 'ipv4only.arpa' is special to 306 (a) client software wishing to perform DNS64 address synthesis, 307 (b) APIs responsible for retrieving the correct information, and 308 (c) the DNS64 recursive resolver responding to such requests. 309 These three considerations are listed in items 2, 3 and 4 below: 311 1. Normal users should never have reason to encounter the 312 'ipv4only.arpa' domain name. If they do, they should expect 313 queries for 'ipv4only.arpa' to result in the answers required by 314 the specification [RFC7050]. Normal users have no need to know 315 that 'ipv4only.arpa' is special. 317 2. Application software may explicitly use the name 'ipv4only.arpa' 318 for NAT64/DNS64 address synthesis, and expect to get the answers 319 required by the specification [RFC7050]. If application software 320 encounters the name 'ipv4only.arpa' in the normal course of 321 handling user input, the application software should resolve that 322 name as usual and need not treat it in any special way. 324 3. Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' 325 as special and MUST give it special treatment. Regardless of any 326 manual client DNS configuration, DNS overrides configured by VPN 327 client software, or any other mechanisms that influence the 328 choice of the client's recursive resolver address(es) (including 329 client devices that run their own local recursive resolver and 330 use the loopback address as their configured recursive resolver 331 address) all queries for 'ipv4only.arpa' and any subdomains of 332 that name MUST be sent to the recursive resolver learned from the 333 network via IPv6 Router Advertisement Options for DNS 334 Configuration [RFC6106] or via DNS Configuration options for 335 DHCPv6 [RFC3646]. Because DNS queries for 'ipv4only.arpa' are 336 actually a special middlebox communication protocol, it is 337 essential that they go to the middlebox in question, and failure 338 to honor this requirement would cause failure of the NAT64 Prefix 339 Discovery mechanism [RFC7050]. 341 4. For the purposes of this section, recursive resolvers fall into 342 two categories. The first category is the traditional recursive 343 resolvers that are in widespread use today. The second category 344 is DNS64 recursive resolvers, whose purpose is to synthesize IPv6 345 address records. 347 Traditional recursive resolvers SHOULD NOT recognize 348 'ipv4only.arpa' as special or give that name, or subdomains of 349 that name, any special treatment. The rationale for this is that 350 a traditional recursive resolver, such as built in to a home 351 gateway, may itself be downstream of a DNS64 recursive resolver. 352 Passing though the 'ipv4only.arpa' queries to the upstream DNS64 353 recursive resolver will allow the correct NAT64 prefix to be 354 discovered. 356 All DNS64 recursive resolvers MUST recognize 'ipv4only.arpa' as 357 special and MUST NOT attempt to look up NS records for it, or 358 otherwise query authoritative name servers in an attempt to 359 resolve this name. Instead, DNS64 recursive resolvers MUST act 360 as authoritative for this domain and generate immediate responses 361 for all such queries. 363 DNS64 recursive resolvers MUST generate the 192.0.0.170 and 364 192.0.0.171 responses for IPv4 address queries (DNS qtype "A"), 365 the appropriate synthesized IPv6 address record responses for 366 IPv6 address queries (DNS qtype "AAAA"), and a negative 367 ("no error no answer") response for all other query types. 369 For all subdomains of 'ipv4only.arpa', DNS64 recursive resolvers 370 MUST generate immediate NXDOMAIN responses. All names falling 371 below 'ipv4only.arpa' are defined to be nonexistent. 373 An example configuration for BIND 9 showing how to achieve the 374 desired result is given in Appendix A. 376 5. Traditional authoritative name server software need not recognize 377 'ipv4only.arpa' as special or handle it in any special way. 378 Recursive resolvers SHOULD routinely act as authoritative for 379 this name and return the results described above. Only the 380 administrators of the 'arpa' namespace need to explicitly 381 configure their actual authoritative name servers to be 382 authoritative for this name and to generate the appropriate 383 answers; all other authoritative name servers will not be 384 configured to know anything about this name and will reject 385 queries for it, as they would reject queries for any other name 386 about which they have no information. 388 6. Generally speaking, operators of authoritative name servers need 389 not know anything about the name 'ipv4only.arpa', just as they do 390 not need to know anything about any other names they are not 391 responsible for. Operators of authoritative name servers who are 392 configuring their name servers to be authoritative for this name 393 MUST understand that 'ipv4only.arpa' is a special name, with 394 records rigidly specified by Internet Standard (generally this 395 applies only to the administrators of the 'arpa' namespace). 397 7. DNS Registries/Registrars need not know anything about the name 398 'ipv4only.arpa', just as they do not need to know anything about 399 any other name they are not responsible for. Only the 400 administrators of the 'arpa' namespace need to be aware of this 401 name's purpose and how it should be configured. 403 6.3. Names '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa' 405 Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to 406 be special, and are listed in the IPv4 Special-Purpose Address 407 Registry [SUv4], the corresponding reverse mapping names in the 408 in-addr.arpa domain are similarly special. 410 The name '170.0.0.192.in-addr.arpa' is defined, by Internet Standard, 411 to have only one DNS record, type PTR, with rdata 'ipv4only.arpa'. 413 The name '171.0.0.192.in-addr.arpa' is defined, by Internet Standard, 414 to have only one DNS record, type PTR, with rdata 'ipv4only.arpa'. 416 There are no subdomains of '170.0.0.192.in-addr.arpa' or 417 '171.0.0.192.in-addr.arpa'. All names falling below these names are 418 defined to be nonexistent (NXDOMAIN). 420 Practically speaking these two names are rarely used, but to the 421 extent that they may be, they are special only to recursive resolvers 422 as described in item 4 below: 424 1. Normal users should never have reason to encounter these two 425 reverse mapping names. However, if they do, queries for these 426 reverse mapping names should return the expected answer 427 'ipv4only.arpa'. Normal users have no need to know that these 428 reverse mapping names are special. 430 2. Application software SHOULD NOT recognize these two reverse 431 mapping names as special, and SHOULD NOT treat them differently. 432 For example, if the user were to issue the Unix command 433 "host 192.0.0.170" then the "host" command should issue the query 434 as usual and display the result that is returned. 436 3. Name resolution APIs and libraries SHOULD recognize these two 437 reverse mapping names as special and generate the required 438 responses locally. For the names '170.0.0.192.in-addr.arpa' and 439 '171.0.0.192.in-addr.arpa' PTR queries yield the result 440 'ipv4only.arpa'; all other query types yield a negative 441 ("no error no answer") response. For all subdomains of these two 442 reverse mapping domains, all queries yield an NXDOMAIN response. 443 All names falling below these two reverse mapping domains are 444 defined to be nonexistent. 446 This local self-contained generation of these responses is to 447 avoid placing unnecessary load on the authoritative 448 'in-addr.arpa' name servers. 450 4. Recursive resolvers SHOULD NOT recognize these two reverse 451 mapping names as special and SHOULD NOT, by default, give them 452 any special treatment. 454 5. Traditional authoritative name server software need not recognize 455 these two reverse mapping names as special or handle them in any 456 special way. 458 As a practical matter, only the administrators of the 459 '192.in-addr.arpa' namespace will configure their name servers to 460 be authoritative for these names and to generate the appropriate 461 answers; all other authoritative name servers will not be 462 configured to know anything about these names and will reject 463 queries for them as they would reject queries for any other name 464 about which they have no information. 466 6. Generally speaking, operators of authoritative name servers need 467 not know anything about these two reverse mapping names, just as 468 they do not need to know anything about any other names they are 469 not responsible for. Operators of authoritative name servers who 470 are configuring their name servers to be authoritative for this 471 name MUST understand that these two reverse mapping names are 472 special, with answers specified by Internet Standard (generally 473 this applies only to the administrators of the '192.in-addr.arpa' 474 namespace). 476 7. DNS Registries/Registrars need not know anything about these two 477 reverse mapping names, just as they do not need to know anything 478 about any other name they are not responsible for. Only the 479 administrators of the '192.in-addr.arpa' namespace need to be 480 aware of the purpose of these two names. 482 6.3.1. ip6.arpa Reverse Mapping PTR Records 484 For all IPv6 addresses synthesized by a DNS64 recursive resolver, the 485 DNS64 recursive resolver is responsible for synthesizing the 486 appropriate 'ip6.arpa' reverse mapping PTR records too, if it chooses 487 to provide reverse mapping PTR records. The same applies to the 488 synthesized IPv6 addresses corresponding to the IPv4 addresses 489 192.0.0.170 and 192.0.0.171. 491 Generally a DNS64 recursive resolver synthesizes appropriate 492 'ip6.arpa' reverse mapping PTR records by extracting the embedded 493 IPv4 address from the encoded IPv6 address, performing a reverse 494 mapping PTR query for that IPv4 address, and then synthesizing a 495 corresponding 'ip6.arpa' reverse mapping PTR record containing the 496 same rdata. 498 In the case of synthesized IPv6 addresses corresponding to the IPv4 499 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive resolver 500 does not issue reverse mapping queries for those IPv4 addresses, but 501 instead, according to rule 3 above, immediately returns the answer 502 'ipv4only.arpa'. 504 In the case of a client that uses the 'ipv4only.arpa' query to 505 discover the IPv6 prefixes in use by the local NAT64 gateway, and 506 then proceeds to perform its own address synthesis locally (which has 507 benefits such as allowing DNSSEC validation), that client MUST also 508 synthesize 'ip6.arpa' reverse mapping PTR records for those 509 discovered prefix(es), according to the rules above: When a client's 510 name resolution APIs and libraries receive a request to look up an 511 'ip6.arpa' reverse mapping PTR record for an address that falls 512 within one of the discovered NAT64 address synthesis prefixes, the 513 software extracts the embedded IPv4 address and then, for IPv4 514 addresses 192.0.0.170 and 192.0.0.171, returns the fixed answer 515 'ipv4only.arpa', and for all other IPv4 addresses performs a reverse 516 mapping PTR query for the IPv4 address, and then synthesizes a 517 corresponding 'ip6.arpa' reverse mapping PTR record containing the 518 same rdata. 520 7. Acknowledgements 522 Thanks to Jouni Korhonen, Teemu Savolainen, and Dan Wing, for 523 devising the NAT64 Prefix Discovery mechanism [RFC7050], and for 524 their feedback on this document. Thanks to Geoff Huston for his 525 feedback on the draft, and to Erik Kline for pointing out that the 526 in-addr.arpa names are special too. Thanks particularly to Lorenzo 527 Colitti for an especially spirited hallway discussion at IETF 96 in 528 Berlin, which lead directly to significant improvements in how this 529 document presents the issues. 531 8. References 533 8.1. Normative References 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, 537 DOI 10.17487/RFC2119, March 1997, . 540 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 541 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 542 DOI 10.17487/RFC3646, December 2003, . 545 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 546 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 547 DOI 10.17487/RFC6052, October 2010, . 550 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 551 "IPv6 Router Advertisement Options for DNS Configuration", 552 RFC 6106, DOI 10.17487/RFC6106, November 2010, 553 . 555 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 556 NAT64: Network Address and Protocol Translation from IPv6 557 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 558 April 2011, . 560 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 561 Beijnum, "DNS64: DNS Extensions for Network Address 562 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 563 DOI 10.17487/RFC6147, April 2011, . 566 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 567 RFC 6761, DOI 10.17487/RFC6761, February 2013, 568 . 570 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 571 the IPv6 Prefix Used for IPv6 Address Synthesis", 572 RFC 7050, DOI 10.17487/RFC7050, November 2013, 573 . 575 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 576 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 577 May 2017, . 579 8.2. Informative References 581 [RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain 582 Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, 583 October 2017, . 585 [SUDN] "Special-Use Domain Names Registry", 586 . 589 [SUv4] "IANA IPv4 Special-Purpose Address Registry", 590 . 593 Appendix A. Example BIND 9 Configuration 595 A BIND 9 recursive resolver can be configured to act as authoritative 596 for the necessary DNS64 names as described below. 598 In /etc/named.conf the following line is added: 600 zone "ipv4only.arpa" { type master; file "ipv4only"; }; 602 The file /var/named/ipv4only is created with the following content: 604 $TTL 86400 ; Default TTL 24 hours 605 @ IN SOA nameserver.example. admin.nameserver.example. ( 606 2016052400 ; Serial 607 7200 ; Refresh ( 7200 = 2 hours) 608 3600 ; Retry ( 3600 = 1 hour) 609 15724800 ; Expire (15724800 = 6 months) 610 60 ; Minimum 611 ) 612 @ IN NS nameserver.example. 614 @ IN A 192.0.0.170 615 @ IN A 192.0.0.171 616 @ IN AAAA 64:ff9b::192.0.0.170 ; If not using Well-Known Prefix 617 @ IN AAAA 64:ff9b::192.0.0.171 ; place actual NAT64 prefix here 619 Authors' Addresses 621 Stuart Cheshire 622 Apple Inc. 623 One Apple Park Way 624 Cupertino, California 95014 625 USA 627 Phone: +1 (408) 996-1010 628 Email: cheshire@apple.com 630 David Schinazi 631 Apple Inc. 632 One Apple Park Way 633 Cupertino, California 95014 634 USA 636 Email: dschinazi@apple.com