idnits 2.17.1 draft-cheshire-sudn-ipv4only-dot-arpa-08.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 17 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 (October 30, 2017) is 2369 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 October 30, 2017 6 Expires: May 3, 2018 8 Special Use Domain Name 'ipv4only.arpa' 9 draft-cheshire-sudn-ipv4only-dot-arpa-08 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, (at the time of writing) 'ipv4only.arpa' still does not appear 20 as one of the names with special properties recorded in the Special- 21 Use Domain Names registry. 23 As a result of this omission, in cases where software needs to give 24 this name special treatment in order for it to work correctly, there 25 is no clear mandate authorizing software authors to implement that 26 special treatment. Software implementers are left with the choice 27 between not implementing the special behavior necessary for the name 28 queries to work correctly, or implementing the special behavior and 29 being accused of being noncompliant with some RFC. 31 This document formally declares the actual special properties of the 32 name, and adds similar declarations for the corresponding reverse 33 mapping names. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 3, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 1. Introduction 68 The specification for how a client discovers its network's NAT64 69 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this 70 purpose, but declares it to be a non-special name in that 71 specification's Domain Name Reservation Considerations section. 73 Consequently, despite the well articulated special purpose of the 74 name, (at the time of writing) 'ipv4only.arpa' still does not appear 75 as one of the names with special properties recorded in the Special- 76 Use Domain Names registry [SUDN]. 78 As a result of this omission, in cases where software needs to give 79 this name special treatment in order for it to work correctly, there 80 is no clear mandate authorizing software authors to implement that 81 special treatment. Software implementers are left with the choice 82 between not implementing the special behavior necessary for the name 83 queries to work correctly, or implementing the special behavior and 84 being accused of being noncompliant with some RFC. 86 This document formally declares the actual special properties of the 87 name, and adds similar declarations for the corresponding reverse 88 mapping names. 90 2. Specialness of 'ipv4only.arpa' 92 The hostname 'ipv4only.arpa' is peculiar in that it was never 93 intended to be treated like a normal hostname. 95 A typical client never looks up the IPv4 address records for 96 'ipv4only.arpa', because it is already known, by specification 97 [RFC7050], to have exactly two IPv4 address records, 192.0.0.170 and 98 192.0.0.171. No client ever has to look the name in order to learn 99 those two addresses. 101 In contrast, clients often look up the IPv6 AAAA address records for 102 'ipv4only.arpa', which is contrary to general DNS expectations, given 103 that it is already known, by specification [RFC7050], that no such 104 IPv6 AAAA address records exist. And yet, clients expect to receive, 105 and do in fact receive, positive answers for these IPv6 AAAA address 106 records that are known to not exist. 108 This is clearly not a typical DNS name. In normal operation, clients 109 never query for the two records that do in fact exist; instead they 110 query for records that are known to not exist, and then get positive 111 answers to those abnormal queries. Clients are using DNS to perform 112 queries for this name, but they are certainly not using DNS to learn 113 legitimate answers from the name's legitimate authoritative server. 114 Instead, these clients have, in effect, co-opted the DNS protocol as 115 an impromptu client-to-middlebox communication protocol, to 116 communicate with the NAT64/DNS64 [RFC6146][RFC6147] gateway, if 117 present, and request that it disclose the prefix it is using for IPv6 118 address synthesis. 120 It is this use of specially-crafted DNS queries as an impromptu 121 client-to-middlebox communication protocol that makes the name 122 'ipv4only.arpa' most definitely a special name, and one that should 123 be listed in IANA's registry along with other DNS names that have 124 special uses [SUDN]. 126 3. Consequences of 'ipv4only.arpa' previously being declared unspecial 128 As a result of the original specification [RFC7050] not formally 129 declaring 'ipv4only.arpa' to have special properties, there was no 130 mandate for any DNS software to treat this name specially. 131 Consequently, queries for this name had to be handled normally, 132 resulting in unnecessary queries to the authoritative 'arpa' name 133 servers. 135 Having millions of devices around the world issue these queries 136 generated pointless additional load on the authoritative 'arpa' name 137 servers, which was completely unnecessary when the name 138 'ipv4only.arpa' is defined, by Internet Standard, to have exactly two 139 IPv4 address records, 192.0.0.170 and 192.0.0.171, and no other 140 records of any type. 142 Also, at times, for reasons that are as yet unclear, the 143 authoritative 'arpa' name servers have been observed to be slow or 144 unresponsive. The failures of these 'ipv4only.arpa' queries result 145 in unnecessary failures of software that depends on them for DNS64 146 [RFC6147] address synthesis. 148 Even when the authoritative 'arpa' name servers are operating 149 correctly, having to perform an unnecessary query to obtain an answer 150 that is already known in advance can add precious milliseconds of 151 delay for no reason. 153 A more serious problem occurs when a device is configured to use a 154 recursive/caching DNS server other than the one it learned from the 155 network. Typically a device joining a NAT64 network will learn the 156 recursive/caching DNS server recommended for that network either via 157 IPv6 Router Advertisement Options for DNS Configuration [RFC6106] or 158 via DNS Configuration options for DHCPv6 [RFC3646]. On a NAT64 159 network it is essential that the client use the recursive/caching 160 DNS64 server recommended for that network, since only that DNS64 161 server can be relied upon to know the appropriate prefix(es) to use 162 for synthesizing IPv6 addresses that will be acceptable to the NAT64 163 server. 165 However, it is not uncommon for users to manually override their 166 default DNS configuration because they wish to use some other public 167 recursive resolver on the Internet, perhaps because they perceive 168 their preferred recursive resolver to be faster, more reliable, or 169 more trustworthy. 171 Another common scenario is the use of corporate VPN client software, 172 which overrides the default configuration to divert DNS requests to 173 the company's own private internal recursive resolver, because the 174 local network's recursive resolver will typically be unable to 175 provide answers for the company's private internal host names. 176 Similarly, the company's private internal recursive resolver may not 177 be able to synthesize IPv6 addresses correctly for use with the local 178 network's NAT64 server, because it is unlikely to be aware of the 179 NAT64 prefix in use on the local network. It is clear that a single 180 recursive resolver cannot meet both needs. The local network's 181 recursive resolver cannot give answers for some company's private 182 internal host names, and some company's private internal recursive 183 resolver cannot give correctly synthesized IPv6 addresses suitable 184 for the local network's NAT64 gateway. 186 The conflict here arises because DNS is being used for two unrelated 187 purposes. The first purpose is retrieving data from a (nominally) 188 global database -- generally retrieving the IP address(es) associated 189 with a hostname. The second purpose is using the DNS protocol as a 190 middlebox communication protocol, to interrogate the local network 191 infrastructure to discover the IPv6 prefix(es) in use by the local 192 NAT64 gateway for address synthesis. 194 (Possibly this problem could be solved if we could force all NAT64 195 gateways to use the same Well-Known Prefix for IPv6 address synthesis 196 [RFC6052], but that would alleviate the need for 'ipv4only.arpa' 197 altogether.) 199 This document leverages this operational experience to update the 200 Domain Name Reservation Considerations section [RFC6761] of the 201 earlier specification [RFC7050] with one that accurately lists the 202 actual special properties of the name 'ipv4only.arpa' so that 203 software can legitimately make appropriate performance and 204 reliability optimizations. 206 4. Security Considerations 208 Hard-coding the known answers for 'ipv4only.arpa' queries in 209 recursive/caching DNS servers reduces the risk of malicious devices 210 intercepting those queries and returning incorrect answers, 211 particularly in the case of recursive/caching DNS servers that do not 212 perform DNSSEC validation. 214 One of the known concerns with DNS64 [RFC6147] is that it interferes 215 with DNSSEC. DNSSEC may cryptographically assert that a name has no 216 IPv6 AAAA records, while at the same time DNS64 address synthesis is 217 contradicting this and claiming that IPv6 AAAA records do exist. 219 Section 3 of the DNS64 specification [RFC6147] discusses this: 221 ... DNS64 receives a query with the DO bit set and 222 the CD bit set. In this case, the DNS64 is supposed 223 to pass on all the data it gets to the query initiator. 224 This case will not work with DNS64, unless the 225 validating resolver is prepared to do DNS64 itself. 227 The NAT64 Prefix Discovery specification [RFC7050] provides the 228 mechanism for the query initiator to learn the NAT64 prefix so that 229 it can do its own validation and DNS64 synthesis as described above. 230 With this mechanism the client can (i) interrogate the local NAT64/ 231 DNS64 gateway with an 'ipv4only.arpa' query to learn the IPv6 address 232 synthesis prefix, (ii) query for the (signed) IPv4 address records 233 itself, and then (iii) perform its own IPv6 address synthesis 234 locally, combining the IPv6 address synthesis prefix learned from the 235 local NAT64/DNS64 gateway with the secure DNSSEC-signed data learned 236 from the global Domain Name System. 238 It is conceivable that over time, if DNSSEC is successful, the 239 majority of clients could move to this validate-and-synthesize- 240 locally model, which reduces the DNS64 machinery to the vestigial 241 role of simply responding to the 'ipv4only.arpa' query to report the 242 local IPv6 address synthesis prefix. In no case does the client care 243 what answer(s) the authoritative 'arpa' name servers might give for 244 that query. The 'ipv4only.arpa' query is being used purely as a 245 local client-to-middlebox communication message. 247 This approach is even more attractive if it does not create an 248 additional dependency on the authoritative 'arpa' name servers to 249 answer a query that is unnecessary because the NAT64/DNS64 gateway 250 already knows the answer before it even issues the query. Avoiding 251 this unnecessary query improves performance and reliability for the 252 client, and reduces unnecessary load for the authoritative 'arpa' 253 name servers. 255 5. IANA Considerations 257 [Once published, this should say] 259 IANA has recorded the following names in the 260 Special-Use Domain Names registry [SUDN]: 262 ipv4only.arpa. 263 170.0.0.192.in-addr.arpa. 264 171.0.0.192.in-addr.arpa. 266 IANA has recorded the following IPv4 addresses in the 267 IPv4 Special-Purpose Address Registry [SUv4]: 269 192.0.0.170 270 192.0.0.171 272 6. Domain Name Reservation Considerations 274 6.1. Conventions and Terminology Used in this Section 276 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 277 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 278 "OPTIONAL" in this section are to be interpreted as described in "Key 279 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 281 6.2. Special Use Domain Name 'ipv4only.arpa' 283 The name 'ipv4only.arpa' is defined, by Internet Standard, to have 284 two IPv4 address records with rdata 192.0.0.170 and 192.0.0.171. 286 When queried via a DNS64 [RFC6147] recursive/caching server, the name 287 'ipv4only.arpa' is also defined to have IPv6 AAAA records, with rdata 288 synthesized from a combination of the NAT64 IPv6 prefix(es), and the 289 IPv4 addresses 192.0.0.170 and 192.0.0.171. This can return more 290 than one pair of IPv6 addresses if there are multiple NAT64 prefixes. 292 The name 'ipv4only.arpa' has no other DNS records of any type. 293 There are no subdomains of ipv4only.arpa. All names falling below 294 'ipv4only.arpa' are defined to be nonexistent (NXDOMAIN). 296 The name 'ipv4only.arpa' is special to 297 (a) client software wishing to perform DNS64 address synthesis, 298 (b) APIs responsible for retrieving the correct information, and 299 (c) the DNS64 recursive/caching server responding to such requests. 300 These three considerations are listed in items 2, 3 and 4 below: 302 1. Normal users should never have reason to encounter the 303 'ipv4only.arpa' domain name. If they do, they should expect 304 queries for 'ipv4only.arpa' to result in the answers required by 305 the specification [RFC7050]. Normal users have no need to know 306 that 'ipv4only.arpa' is special. 308 2. Application software may explicitly use the name 'ipv4only.arpa' 309 for NAT64/DNS64 address synthesis, and expect to get the answers 310 required by the specification [RFC7050]. If application software 311 encounters the name 'ipv4only.arpa' in the normal course of 312 handling user input, the application software should resolve that 313 name as usual and need not treat it in any special way. 315 3. Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' 316 as special and MUST give it special treatment. Regardless of any 317 manual client DNS configuration, DNS overrides configured by VPN 318 client software, or any other mechanisms that influence the 319 choice of the client's recursive/caching DNS server address(es) 320 (including client devices that run their own local recursive 321 resolver and use the loopback address as their configured 322 recursive/caching DNS server address) all queries for 323 'ipv4only.arpa' and any subdomains of that name MUST be sent to 324 the recursive/caching DNS server learned from the network via 325 IPv6 Router Advertisement Options for DNS Configuration [RFC6106] 326 or via DNS Configuration options for DHCPv6 [RFC3646]. Because 327 DNS queries for 'ipv4only.arpa' are actually a special middlebox 328 communication protocol, it is essential that they go to the 329 middlebox in question, and failure to honor this requirement 330 would cause failure of the NAT64 Prefix Discovery mechanism 331 [RFC7050]. 333 4. For the purposes of this section, recursive/caching DNS servers 334 fall into two categories. The first category is the traditional 335 recursive/caching DNS servers that are in widespread use today. 336 The second category is DNS64 servers, whose purpose is to 337 synthesize IPv6 address records. 339 Traditional recursive/caching DNS servers SHOULD NOT recognize 340 'ipv4only.arpa' as special or give that name, or subdomains of 341 that name, any special treatment. The rationale for this is that 342 a traditional recursive/caching DNS server, such as built in to a 343 home gateway, may itself be downstream of a DNS64 server. 345 Passing though the 'ipv4only.arpa' queries to the upstream DNS64 346 server will allow the correct NAT64 prefix to be discovered. 348 All DNS64 servers MUST recognize 'ipv4only.arpa' as special and 349 MUST NOT attempt to look up NS records for it, or otherwise query 350 authoritative DNS servers in an attempt to resolve this name. 351 Instead, DNS64 servers MUST act as authoritative for this domain 352 and generate immediate responses for all such queries. 354 DNS64 servers MUST generate the 192.0.0.170 and 192.0.0.171 355 responses for IPv4 address queries (DNS qtype "A"), the 356 appropriate synthesized IPv6 address record responses for IPv6 357 address queries (DNS qtype "AAAA"), and a negative 358 ("no error no answer") response for all other query types. 360 For all subdomains of 'ipv4only.arpa', DNS64 servers MUST 361 generate immediate NXDOMAIN responses. All names falling below 362 'ipv4only.arpa' are defined to be nonexistent. 364 An example configuration for BIND 9 showing how to achieve the 365 desired result is given in Appendix A. 367 5. Traditional authoritative DNS server software need not recognize 368 'ipv4only.arpa' as special or handle it in any special way. 369 Recursive/caching DNS servers SHOULD routinely act as 370 authoritative for this name and return the results described 371 above. Only the administrators of the 'arpa' namespace need to 372 explicitly configure their actual authoritative name servers to 373 be authoritative for this name and to generate the appropriate 374 answers; all other authoritative name servers will not be 375 configured to know anything about this name and will reject 376 queries for it, as they would reject queries for any other name 377 about which they have no information. 379 6. Generally speaking, operators of authoritative DNS servers need 380 not know anything about the name 'ipv4only.arpa', just as they do 381 not need to know anything about any other names they are not 382 responsible for. Operators of authoritative DNS servers who are 383 configuring their name servers to be authoritative for this name 384 MUST understand that 'ipv4only.arpa' is a special name, with 385 records rigidly specified by Internet Standard (generally this 386 applies only to the administrators of the 'arpa' namespace). 388 7. DNS Registries/Registrars need not know anything about the name 389 'ipv4only.arpa', just as they do not need to know anything about 390 any other name they are not responsible for. Only the 391 administrators of the 'arpa' namespace need to be aware of this 392 name's purpose and how it should be configured. 394 6.3. Names '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa' 396 Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to 397 be special, and are listed in the IPv4 Special-Purpose Address 398 Registry [SUv4], the corresponding reverse mapping names in the 399 in-addr.arpa domain are similarly special. 401 The name '170.0.0.192.in-addr.arpa' is defined, by Internet Standard, 402 to have only a single DNS record, 403 type PTR, with rdata 'ipv4only.arpa'. 405 The name '171.0.0.192.in-addr.arpa' is defined, by Internet Standard, 406 to have only a single DNS record, 407 type PTR, with rdata 'ipv4only.arpa'. 409 There are no subdomains of '170.0.0.192.in-addr.arpa' or 410 '171.0.0.192.in-addr.arpa'. All names falling below these names are 411 defined to be nonexistent (NXDOMAIN). 413 Practically speaking these two names are rarely used, but to the 414 extent that they may be, they are special only to recursive/caching 415 DNS servers as described in item 4 below: 417 1. Normal users should never have reason to encounter these two 418 reverse mapping names. However, if they do, queries for these 419 reverse mapping names should return the expected answer 420 'ipv4only.arpa'. Normal users have no need to know that these 421 reverse mapping names are special. 423 2. Application software SHOULD NOT recognize these two reverse 424 mapping names as special, and SHOULD NOT treat them differently. 425 For example, if the user were to issue the Unix command 426 "host 192.0.0.170" then the "host" command should issue the query 427 as usual and display the result that is returned. 429 3. Name resolution APIs and libraries SHOULD recognize these two 430 reverse mapping names as special and generate the required 431 responses locally. For the names '170.0.0.192.in-addr.arpa' and 432 '171.0.0.192.in-addr.arpa' PTR queries yield the result 433 'ipv4only.arpa'; all other query types yield a negative 434 ("no error no answer") response. For all subdomains of these two 435 reverse mapping domains, all queries yield an NXDOMAIN response. 436 All names falling below these two reverse mapping domains are 437 defined to be nonexistent. 439 This local self-contained generation of these responses is to 440 avoid placing unnecessary load on the authoritative 441 'in-addr.arpa' name servers. 443 4. Recursive/caching DNS servers SHOULD NOT recognize these two 444 reverse mapping names as special and SHOULD NOT, by default, give 445 them any special treatment. 447 5. Traditional authoritative DNS server software need not recognize 448 these two reverse mapping names as special or handle them in any 449 special way. 450 As a practical matter, only the administrators of the 451 '192.in-addr.arpa' namespace will configure their name servers to 452 be authoritative for these names and to generate the appropriate 453 answers; all other authoritative name servers will not be 454 configured to know anything about these names and will reject 455 queries for them as they would reject queries for any other name 456 about which they have no information. 458 6. Generally speaking, operators of authoritative DNS servers need 459 not know anything about these two reverse mapping names, just as 460 they do not need to know anything about any other names they are 461 not responsible for. Operators of authoritative DNS servers who 462 are configuring their name servers to be authoritative for this 463 name MUST understand that these two reverse mapping names are 464 special, with answers specified by Internet Standard (generally 465 this applies only to the administrators of the '192.in-addr.arpa' 466 namespace). 468 7. DNS Registries/Registrars need not know anything about these two 469 reverse mapping names, just as they do not need to know anything 470 about any other name they are not responsible for. Only the 471 administrators of the '192.in-addr.arpa' namespace need to be 472 aware of the purpose of these two names. 474 6.3.1. ip6.arpa Reverse Mapping PTR Records 476 For all IPv6 addresses synthesized by a DNS64 recursive resolver, the 477 DNS64 recursive resolver server is responsible for synthesizing the 478 appropriate 'ip6.arpa' reverse mapping PTR records too, if it chooses 479 to provide reverse mapping PTR records. The same applies to the 480 synthesized IPv6 addresses corresponding to the IPv4 addresses 481 192.0.0.170 and 192.0.0.171. 483 Generally a DNS64 recursive/caching server synthesizes appropriate 484 'ip6.arpa' reverse mapping PTR records by extracting the embedded 485 IPv4 address from the encoded IPv6 address, performing a reverse 486 mapping PTR query for that IPv4 address, and then synthesizing a 487 corresponding 'ip6.arpa' reverse mapping PTR record containing the 488 same rdata. 490 In the case of synthesized IPv6 addresses corresponding to the IPv4 491 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive/caching 492 server does not issue reverse mapping queries for those IPv4 493 addresses, but instead, according to rule 3 above, immediately 494 returns the answer 'ipv4only.arpa'. 496 In the case of a client that uses the 'ipv4only.arpa' query to 497 discover the IPv6 prefixes in use by the local NAT64 gateway, and 498 then proceeds to perform its own address synthesis locally (which has 499 benefits such as allowing DNSSEC validation), that client MUST also 500 synthesize 'ip6.arpa' reverse mapping PTR records for those 501 discovered prefix(es), according to the rules above: When a client's 502 name resolution APIs and libraries receive a request to look up an 503 'ip6.arpa' reverse mapping PTR record for an address that falls 504 within one of the discovered NAT64 address synthesis prefixes, the 505 software extracts the embedded IPv4 address and then, for IPv4 506 addresses 192.0.0.170 and 192.0.0.171, returns the fixed answer 507 'ipv4only.arpa', and for all other IPv4 addresses performs a reverse 508 mapping PTR query for the IPv4 address, and then synthesizes a 509 corresponding 'ip6.arpa' reverse mapping PTR record containing the 510 same rdata. 512 7. Acknowledgements 514 Thanks to Jouni Korhonen, Teemu Savolainen, and Dan Wing, for 515 devising the NAT64 Prefix Discovery mechanism [RFC7050], and for 516 their feedback on this document. Thanks to Geoff Huston for his 517 feedback on the draft, and to Erik Kline for pointing out that the 518 in-addr.arpa names are special too. Thanks particularly to Lorenzo 519 Colitti for an especially spirited hallway discussion at IETF 96 in 520 Berlin, which lead directly to significant improvements in how this 521 document presents the issues. 523 8. References 525 8.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, . 532 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 533 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 534 DOI 10.17487/RFC3646, December 2003, . 537 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 538 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 539 DOI 10.17487/RFC6052, October 2010, . 542 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 543 "IPv6 Router Advertisement Options for DNS Configuration", 544 RFC 6106, DOI 10.17487/RFC6106, November 2010, 545 . 547 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 548 NAT64: Network Address and Protocol Translation from IPv6 549 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 550 April 2011, . 552 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 553 Beijnum, "DNS64: DNS Extensions for Network Address 554 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 555 DOI 10.17487/RFC6147, April 2011, . 558 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 559 RFC 6761, DOI 10.17487/RFC6761, February 2013, 560 . 562 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 563 the IPv6 Prefix Used for IPv6 Address Synthesis", 564 RFC 7050, DOI 10.17487/RFC7050, November 2013, 565 . 567 8.2. Informative References 569 [SUDN] "Special-Use Domain Names Registry", 570 . 573 [SUv4] "IANA IPv4 Special-Purpose Address Registry", 574 . 577 Appendix A. Example BIND 9 Configuration 579 A BIND 9 recursive/caching DNS server can be configured to act as 580 authoritative for the necessary DNS64 names as described below. 582 In /etc/named.conf the following line is added: 584 zone "ipv4only.arpa" { type master; file "ipv4only"; }; 586 The file /var/named/ipv4only is created with the following content: 588 $TTL 86400 ; Default TTL 24 hours 589 @ IN SOA nameserver.example. admin.nameserver.example. ( 590 2016052400 ; Serial 591 7200 ; Refresh ( 7200 = 2 hours) 592 3600 ; Retry ( 3600 = 1 hour) 593 15724800 ; Expire (15724800 = 6 months) 594 60 ; Minimum 595 ) 596 @ IN NS nameserver.example. 598 @ IN A 192.0.0.170 599 @ IN A 192.0.0.171 600 @ IN AAAA 64:ff9b::192.0.0.170 ; If not using Well-Known Prefix 601 @ IN AAAA 64:ff9b::192.0.0.171 ; place actual NAT64 prefix here 603 Authors' Addresses 605 Stuart Cheshire 606 Apple Inc. 607 1 Infinite Loop 608 Cupertino, California 95014 609 USA 611 Phone: +1 408 974 3207 612 Email: cheshire@apple.com 614 David Schinazi 615 Apple Inc. 616 1 Infinite Loop 617 Cupertino, California 95014 618 USA 620 Phone: +1 669 227 9921 621 Email: dschinazi@apple.com