idnits 2.17.1 draft-cheshire-sudn-ipv4only-dot-arpa-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6761], [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. -- The abstract seems to indicate that this document updates RFC6761, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2016) is 2865 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 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 24, 2016 6 Expires: November 25, 2016 8 Special Use Domain Name 'ipv4only.arpa' 9 draft-cheshire-sudn-ipv4only-dot-arpa-02 11 Abstract 13 The document "Discovery of the IPv6 Prefix Used for IPv6 Address 14 Synthesis" [RFC7050] specifies the Special Use Domain Name 15 'ipv4only.arpa', with certain precise special properties, but, 16 perversely, the Domain Name Reservation Considerations section 17 [RFC6761] in that document then goes on to deny the specialness of 18 that name, and (as of May 2016) the name 'ipv4only.arpa' does not 19 appear in the Special-Use Domain Names registry. 21 This document updates RFC 7050 with a more appropriate summary of the 22 legitimate and useful special properties of the name 'ipv4only.arpa', 23 and the corresponding reverse mapping names. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 25, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Introduction 59 The document "Discovery of the IPv6 Prefix Used for IPv6 Address 60 Synthesis" [RFC7050] specifies the Special Use Domain Name 61 'ipv4only.arpa', with certain precise special properties, but, 62 perversely, the Domain Name Reservation Considerations section 63 [RFC6761] in that document denies the specialness of that name, and 64 (as of May 2016) the name 'ipv4only.arpa' does not appear in the 65 Special-Use Domain Names registry [SUDN]. 67 As a result of the name 'ipv4only.arpa' being formally declared to 68 have no special properties, there was no mandate for software to 69 treat this name specially. Consequently, queries for this name have 70 to be handled normally, and result in a large volume of unnecessary 71 queries to the 'arpa' name servers. 73 Having millions of devices around the world issue these queries 74 generates pointless additional load on the 'arpa' name servers, which 75 is completely unnecessary when the name 'ipv4only.arpa' is defined, 76 by Internet Standard, to have only two IPv4 address records, 77 192.0.0.170 and 192.0.0.171, and no other records of any type. 79 At times, for reasons that are as yet unclear, the 'arpa' name 80 servers have been observed to be slow or unresponsive. The failures 81 of these 'ipv4only.arpa' queries result in unnecessary failures of 82 software that depends on them for NAT64 address synthesis. 84 To remedy this situation, this document updates RFC 7050 with a more 85 appropriate Domain Name Reservation Considerations section [RFC6761] 86 that properly lists the desirable and beneficial special handling for 87 'ipv4only.arpa'. 89 2. Conventions and Terminology Used in this Document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 96 3. Security Considerations 98 Hard-coding the answers for 'ipv4only.arpa' queries avoids the risk 99 of malicious devices intercepting those queries and returning 100 incorrect answers. 102 DNSSEC signing issues for the 'ipv4only.arpa' address records don't 103 apply, since the only use of the 'ipv4only.arpa' name is to trigger 104 synthesis of NAT64 AAAA records, which aren't signed by arpa anyway. 106 4. IANA Considerations 108 [Once published, this should say] 110 IANA has recorded the following names in the 111 Special-Use Domain Names registry [SUDN]: 112 ipv4only.arpa 113 170.0.0.192.in-addr.arpa 114 171.0.0.192.in-addr.arpa 116 IANA has recorded the following IPv4 addresses in the 117 IPv4 Special-Purpose Address Registry [SUv4]: 118 192.0.0.170 119 192.0.0.171 121 5. Domain Name Reservation Considerations 123 5.1. ipv4only.arpa 125 The name 'ipv4only.arpa' is defined, by Internet Standard, to have 126 two IPv4 address records with rdata 192.0.0.170 and 192.0.0.171. 128 When queried via a DNS64 recursive/caching server, the name 129 'ipv4only.arpa' is defined to also have two IPv6 AAAA records, with 130 rdata synthesized from a combination of the NAT64 IPv6 prefix, and 131 the IPv4 addresses 192.0.0.170 and 192.0.0.171. This can return more 132 than one pair of v6 addresses if there are multiple NAT64 prefixes. 134 The name 'ipv4only.arpa' has no other DNS records of any type. 136 The name 'ipv4only.arpa' is special only to 137 (a) client software wishing to perform NAT64 address synthesis, and 138 (b) the DNS64 server responding to such requests. 139 These two considerations are listed in items 2 and 4 below: 141 1. Normal users should never have reason to encounter the 142 'ipv4only.arpa' domain name. If they do, queries for 143 'ipv4only.arpa' should result in the answers specified in RFC 144 7050. 145 Normal users have no need to know that 'ipv4only.arpa' is 146 special. 148 2. Application software may explicitly use the name 'ipv4only.arpa' 149 for NAT64 address synthesis, and expect to get the answers 150 specified in RFC 7050. If application software encounters the 151 name 'ipv4only.arpa' in the normal course of handling user input, 152 the application software should resolve that name as usual and 153 need not treat it in any special way. 155 3. Name resolution APIs and libraries SHOULD NOT recognize 156 'ipv4only.arpa' as special and SHOULD NOT treat it differently. 157 Name resolution APIs SHOULD send queries for this name to their 158 configured recursive/caching DNS server(s). 160 4. Recursive/caching DNS servers SHOULD recognize 'ipv4only.arpa' as 161 special and SHOULD NOT, by default, attempt to look up NS records 162 for it, or otherwise query authoritative DNS servers in an 163 attempt to resolve this name. Instead, recursive/caching DNS 164 servers SHOULD, by default, act as authoritative and generate 165 immediate responses for all such queries. 167 Traditional recursive/caching DNS servers that act as 168 authoritative for this name MUST generate only the 192.0.0.170 169 and 192.0.0.171 responses for IPv4 address queries (DNS qtype 170 "A"), and a "no error no answer" response for all other query 171 types. An example configuration for BIND 9 to achieve this 172 result is given in Appendix A. 174 All DNS64 recursive/caching DNS servers MUST generate the 175 192.0.0.170 and 192.0.0.171 responses for IPv4 address queries 176 (DNS qtype "A"), the appropriate synthesized IPv6 address record 177 responses for IPv6 address queries (DNS qtype "AAAA"), and a 178 "no error no answer" response for all other query types. 179 This local self-contained generation of these responses is to 180 avoid placing unnecessary load on the 'arpa' name servers. 182 5. Traditional authoritative DNS server software need not recognize 183 'ipv4only.arpa' as special or handle it in any special way. 184 As a practical matter, only the administrators of the 'arpa' 185 namespace will configure their name servers to be authoritative 186 for this name and to generate the appropriate answers; all other 187 authoritative name servers will not be configured to know 188 anything about this name and will reject queries for it as they 189 would reject queries for any other name about which they have no 190 information. 192 6. Generally speaking, operators of authoritative DNS servers need 193 not know anything about the name 'ipv4only.arpa', just as they 194 don't need to know anything about any other names they are not 195 responsible for. Operators of authoritative DNS servers who are 196 configuring their name servers to be authoritative for this name 197 MUST understand that 'ipv4only.arpa' is a special name, with 198 answers specified by Internet Standard (generally this applies 199 only to the administrators of the 'arpa' namespace). 201 7. DNS Registries/Registrars need not know anything about the name 202 'ipv4only.arpa', just as they don't need to know anything about 203 any other name they are not responsible for. Only the 204 administrators of the 'arpa' namespace need to be aware of this 205 name's purpose and how it should be configured. 207 5.2. 170.0.0.192.in-addr.arpa and 171.0.0.192.in-addr.arpa 209 Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to 210 be special, and are listed in the IPv4 Special-Purpose Address 211 Registry [SUv4], the corresponding reverse mapping names in the 212 in-addr.arpa domain are similarly special. 214 The name '170.0.0.192.in-addr.arpa' is defined, by Internet Standard, 215 to have only a single DNS record, type PTR, with rdata 216 'ipv4only.arpa'. 218 The name '171.0.0.192.in-addr.arpa' is defined, by Internet Standard, 219 to have only a single DNS record, type PTR, with rdata 220 'ipv4only.arpa'. 222 Practically speaking these two names are rarely used, but to the 223 extent that they may be, they are special only to recursive/caching 224 DNS servers as described in item 3 below: 226 1. Normal users should never have reason to encounter these two 227 reverse mapping names. However, if they do, queries for these 228 reverse mapping names should return the expected answer 229 'ipv4only.arpa'. Normal users have no need to know that these 230 reverse mapping names are special. 232 2. Application software SHOULD NOT recognize these two reverse 233 mapping names as special, and SHOULD NOT treat them differently. 234 For example, if the user were to issue the Unix command 235 "host 192.0.0.170" then the "host" command should issue the query 236 as usual and display the result that is returned. 238 3. Name resolution APIs and libraries SHOULD NOT recognize these two 239 reverse mapping names as special and SHOULD NOT treat them 240 differently. Name resolution APIs SHOULD send queries for these 241 names to their configured recursive/caching DNS server(s). 243 4. Recursive/caching DNS servers SHOULD recognize these two reverse 244 mapping names as special and SHOULD NOT, by default, attempt to 245 look up NS records for them, or otherwise query authoritative DNS 246 servers in an attempt to resolve them. Instead, recursive/ 247 caching DNS servers SHOULD, by default, act as authoritative and 248 generate immediate responses for all such queries. 250 Recursive/caching DNS servers that act as authoritative for these 251 names MUST generate only the 'ipv4only.arpa' response for PTR 252 queries, and a "no error no answer" response for all other query 253 types. This local self-contained generation of these responses 254 is to avoid placing unnecessary load on the 'in-addr.arpa' name 255 servers. 257 5. Traditional authoritative DNS server software need not recognize 258 these two reverse mapping names as special or handle them in any 259 special way. 260 As a practical matter, only the administrators of the 261 'in-addr.arpa' namespace will configure their name servers to be 262 authoritative for these names and to generate the appropriate 263 answers; all other authoritative name servers will not be 264 configured to know anything about these names and will reject 265 queries for them as they would reject queries for any other name 266 about which they have no information. 268 6. Generally speaking, operators of authoritative DNS servers need 269 not know anything about these two reverse mapping names, just as 270 they don't need to know anything about any other names they are 271 not responsible for. Operators of authoritative DNS servers who 272 are configuring their name servers to be authoritative for this 273 name MUST understand that these two reverse mapping names are 274 special, with answers specified by Internet Standard (generally 275 this applies only to the administrators of the 'in-addr.arpa' 276 namespace). 278 7. DNS Registries/Registrars need not know anything about these two 279 reverse mapping names, just as they don't need to know anything 280 about any other name they are not responsible for. Only the 281 administrators of the 'in-addr.arpa' namespace need to be aware 282 of the purpose of these two names. 284 5.3. ip6.arpa Reverse Mapping PTR Records 286 For all IPv6 addresses synthesized by the NAT64 gateway, the DNS64 287 recursive/caching server is responsible for synthesizing the 288 appropriate ip6.arpa reverse mapping PTR records, if it chooses to do 289 so. The same applies to the synthesized IPv6 addresses corresponding 290 to the IPv4 addresses 192.0.0.170 and 192.0.0.171. 292 Generally a DNS64 recursive/caching server synthesizes appropriate 293 ip6.arpa reverse mapping PTR records by extracting the embedded IPv4 294 address from the encoded IPv6 address, performing a reverse mapping 295 query for that IPv4 address, and then synthesizing a corresponding 296 ip6.arpa reverse mapping PTR record containing the same rdata. 298 In the case of synthesized IPv6 addresses corresponding to the IPv4 299 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive/caching 300 server does not issue mapping queries for those IPv4 addresses, but 301 instead, according to rule 3 above, immediately returns the answer 302 'ipv4only.arpa'. 304 6. References 306 6.1. Normative References 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 310 RFC2119, March 1997, 311 . 313 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 314 RFC 6761, DOI 10.17487/RFC6761, February 2013, 315 . 317 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 318 the IPv6 Prefix Used for IPv6 Address Synthesis", 319 RFC 7050, DOI 10.17487/RFC7050, November 2013, 320 . 322 6.2. Informative References 324 [SUDN] "Special-Use Domain Names Registry", . 327 [SUv4] "IANA IPv4 Special-Purpose Address Registry", . 330 Appendix A. Example BIND 9 Configuration 332 A BIND 9 recursive/caching DNS server could be configured to act as 333 authoritative for the appropriate names as follows. 335 In /etc/named.conf the following lines are added: 337 zone "ipv4only.arpa" { type master; file "ipv4only"; }; 338 zone "170.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 339 zone "171.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 341 The file /var/named/ipv4only is created with the following content: 343 $TTL 86400 ; Default TTL 24 hours 344 @ IN SOA nameserver.example. admin.nameserver.example. ( 345 2016052400 ; Serial 346 7200 ; Refresh ( 7200 = 2 hours) 347 3600 ; Retry ( 3600 = 1 hour) 348 15724800 ; Expire (15724800 = 6 months) 349 60 ; Minimum 350 ) 351 @ IN NS nameserver.example. 353 @ IN A 192.0.0.170 354 @ IN A 192.0.0.171 356 The file /var/named/ipv4only-r is created with the following content: 358 $TTL 86400 ; Default TTL 24 hours 359 @ IN SOA nameserver.example. admin.nameserver.example. ( 360 2016052400 ; Serial 361 7200 ; Refresh ( 7200 = 2 hours) 362 3600 ; Retry ( 3600 = 1 hour) 363 15724800 ; Expire (15724800 = 6 months) 364 60 ; Minimum 365 ) 366 @ IN NS nameserver.example. 368 @ IN PTR ipv4only.arpa. 370 Authors' Addresses 372 Stuart Cheshire 373 Apple Inc. 374 1 Infinite Loop 375 Cupertino, California 95014 376 USA 378 Phone: +1 408 974 3207 379 Email: cheshire@apple.com 381 David Schinazi 382 Apple Inc. 383 1 Infinite Loop 384 Cupertino, California 95014 385 USA 387 Phone: +1 669 227 9921 388 Email: dschinazi@apple.com