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