idnits 2.17.1 draft-gersch-dnsop-revdns-cidr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 66 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 private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.gersch-grow-revdns-bgp' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'I-D.howard-isp-ip6rdns' is defined on line 844, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-gersch-grow-revdns-bgp-00 == Outdated reference: A later version (-08) exists of draft-howard-isp-ip6rdns-04 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gersch 3 Internet-Draft Secure64 SW Corp 4 Intended status: Informational D. Massey 5 Expires: August 29, 2013 Colorado State University 6 E. Osterweil 7 Verisign 8 C. Olschanowsky 9 Colorado State University 10 February 25, 2013 12 Reverse DNS Naming Convention for CIDR Address Blocks 13 draft-gersch-dnsop-revdns-cidr-04.txt 15 Abstract 17 This draft proposes a naming convention for encoding CIDR address 18 blocks into the reverse DNS namespace. The reverse DNS naming method 19 is commonly used to specify a complete IP address. This document 20 describes how to encode an IPv4 or IPv6 CIDR address block such as 21 129.82.128.0/17. By defining a common naming convention, one can 22 associate information with a prefix. The convention builds on past 23 work in RFC 1101 that associates network names with prefixes. 24 However, this previous work pre-dated the introduction of CIDR and 25 has several critical ambiguities. This convention corrects the 26 ambiguities and enables new applications ranging from routing 27 information to geolocation. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 29, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Aligning the DNS and IP Hierarchies . . . . . . . . . . . 4 65 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Conventions Used In This Document . . . . . . . . . . . . . . 7 68 3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 8 69 4. Reverse DNS CIDR Name Specification . . . . . . . . . . . . . 9 70 4.1. IPv4 Address Block Naming . . . . . . . . . . . . . . . . 9 71 4.2. IPv6 Address Block Naming . . . . . . . . . . . . . . . . 11 72 4.3. Maintaining one-to-one mapping . . . . . . . . . . . . . . 11 73 5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. Naming via RFC 1101 . . . . . . . . . . . . . . . . . . . 12 75 5.2. CIDR Naming via RFC 2317 . . . . . . . . . . . . . . . . . 13 76 5.3. Prior Work on CIDR Names for Routing . . . . . . . . . . . 14 77 6. Additional Considerations . . . . . . . . . . . . . . . . . . 16 78 6.1. Splitting a /16 into two /17s . . . . . . . . . . . . . . 16 79 6.2. Allocating a /16 and then assigning the /16 . . . . . . . 16 80 6.3. Delegations that Span Octet boundaries . . . . . . . . . . 16 81 6.4. Legacy Behavior at Octet Boundaries . . . . . . . . . . . 17 82 6.5. The Naming Convention and Zone Structures . . . . . . . . 17 83 6.6. Separation of Prefix Data and PTR Records . . . . . . . . 17 84 6.7. Prefix Enumeration . . . . . . . . . . . . . . . . . . . . 18 85 6.8. Finding Longest Matches . . . . . . . . . . . . . . . . . 19 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 89 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 23 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 93 Appendix A. Example Zone Files . . . . . . . . . . . . . . . . . 26 94 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 26 95 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 27 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 99 1. Introduction 101 This draft proposes a common naming convention for entering CIDR 102 prefixes into the Reverse DNS. 104 The Reverse DNS provides a naming convention for both IPv4 and IPv6 105 addresses. At this time, the most common use of the reverse-DNS is 106 to associate an IP address with a PTR resource record that identifies 107 the corresponding host name. For example, IP address 129.82.138.2 is 108 encoded as 2.138.82.129.in-addr.arpa and a PTR resource record 109 identifies the host name as alpha.netsec.colostate.edu. The Reverse 110 DNS would be more expressive if we had a formal convention for 111 encoding and returning information associated with a network address 112 range, not just a unique IP address. For example, the naming 113 convention in this document allows one to store and resolve resource 114 records associated with a prefix range such as 129.82.128/17. 116 The association of prefixes and data using reverse DNS has existing 117 applications. Specifically, [RFC1035] (section 3.5) uses the reverse 118 DNS to identify gateways on a subnet and [RFC1101] associates a 119 network name with an address block. The introduction of the CIDR 120 addressing architecture created ambiguities for naming conventions 121 such as RFC 1101. This document introduces a naming convention that 122 resolves the ambiguities, restores the historical uses, and enables 123 new uses such as the inclusion of routing data and geolocation data. 124 This list of possible applications is not intended to be complete, 125 but instead suggest some of the possibilities. 127 This draft proposes a naming convention for the prefix name and 128 argues that applications would benefit from the use of consistent 129 convention. Since it is only a naming convention, it requires no 130 changes to the DNS servers or resolvers. It simply provides a way to 131 express a prefix as a unique DNS name. DNS zone administrators can 132 choose to associate any name with a prefix, but having a common 133 convention facilities inter-operability between different 134 applications. In fact, there is already DNS data using this 135 document's naming convention in the reverse DNS. Standardizing the 136 convention allows it to be improved, clearly documented, and allows 137 other applications to make use of the same naming convention. 139 1.1. Aligning the DNS and IP Hierarchies 141 Both the DNS names and IP addresses are part of a hierarchical tree 142 structure and any naming convention should respect and align with 143 these tree structures whenever possible. In the DNS hierarchical 144 tree structure 128.82.129.in-addr.arpa is logically below 82.129.in- 145 addr.arpa, which is logically below 129.in-addr.arpa. Other "flat" 146 approaches to naming, such as Distributed Hash Tables, have been 147 proposed, but the DNS tree structure remains a powerful abstraction. 148 It forms the basis for the operation of DNS; caching, delegation, 149 DNSSEC signing, and so forth all benefit from the DNS tree structure. 151 IP addresses also have a logical tree structure where 129.82.128.0/24 152 is subprefix (logically below) 129.82.0.0/16 which is a subprefix of 153 129.0.0.0/8. The reverse DNS aligns with the structure; 154 128.82.129.in-addr.arpa is logically below 82.129.in-addr.arpa which 155 is logically below 129.in-addr.arpa. This alignment between the DNS 156 hierarchy and the IP address hierarchy serves both systems well and 157 allows one to easily encode prefixes that fall on an octet boundary 158 (e.g. IPv4 prefixes whose mask length is a multiple of 8). 160 The challenge is to preserve this alignment even when even when CIDR 161 prefixes do not fall on octet boundaries. For example, 162 129.82.128.0/19 is a subprefix of 129.82.128.0/18. The DNS name for 163 129.82.128.0/19 should be logically below the DNS name for 164 129.82.128.0/18. This document introduces a naming convention for 165 CIDR prefixes that preserves this alignment while also building on 166 the existing reverse DNS structure. 168 1.2. Purpose 170 In order to enable the association of prefixes and data using reverse 171 DNS, one must map an IPv4 or IPv6 prefix into a reverse DNS name. 172 There are various subtleties, advantages and disadvantages that 173 emerge when trying to define a naming convention. This requires no 174 DNS protocol changes and no modifications to resolvers, caches, or 175 authoritative servers. Today, zone administrators can use their own 176 individual approaches to encode a prefix in the reverse DNS. The 177 emergence of different encoding standards complicates (but does not 178 prevent) the design of systems that would make use of these resource 179 records. The aim of this work is to introduce a standard convention. 181 1.3. Terminology 183 The following terms are used throughout out the document: 185 Reverse DNS: 186 We use the term Reverse DNS to refer to the domains in-addr.arpa 187 and ip6.arpa. 189 Prefix: 190 A prefix refers to IPv4 or IPv6 address range specified by a 191 network portion and mask length, as described in [RFC4632]. For 192 example, 129.82.0.0/16 and 129.82.128/18 are examples of IPv4 193 prefixes. 195 Octet Boundary: 196 An IPv4 prefix falls on an octet boundary if its mask length is a 197 multiple 8. For example, 129.82.0.0/16 is on an octet boundary 198 while 129.82.128/18 is not. Prefixes that are on octet boundary 199 naturally map to the reverse DNS. Prefixes that do not fall on an 200 octet boundary are more complex and are the main challenge for any 201 naming convention. 203 Nibble Boundary: 204 An IPv6 prefix falls on a nibble boundary if its mask length is a 205 multiple 4. For example, 2607:fa88::/32 is on a nibble boundary 206 while 2607:fa88::/33 is not. Prefixes that are on nibble boundary 207 naturally map to the reverse DNS. Prefixes that do not fall on a 208 nibble boundary are more complex and are the main challenge for 209 any naming convention. 211 2. Conventions Used In This Document 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 3. Design Requirements 219 A naming convention to specify CIDR address blocks in the reverse-DNS 220 must satisfy the following requirements: 222 1. Unambiguous: A prefix must have a unique name and a name must 223 uniquely match a single prefix. It is very important that a 224 prefix should have only one unique DNS name. If there are 225 multiple DNS names for the same prefix, applications might need 226 to query data at each of the multiple names. Worse still, the 227 different names could contain conflicting information. To avoid 228 this, we require each prefix have exactly one unique DNS name. 229 It is equally important that a DNS name maps to only one prefix. 230 If the same name maps to more than one prefix, applications 231 cannot distinguish which records should be be associated with 232 which prefix. To avoid this, we require each name in our naming 233 convention maps to exactly one unique prefix. 235 2. Autonomy: The owner of a reverse-DNS zone file associated with a 236 CIDR address block should be able to act independently from any 237 other organization in order to create or modify data records 238 within the DNS zone. 240 3. Coverage Authority: With the exception of data that has been sub- 241 delegated to a child zone, the reverse DNS zone must be 242 authoritative for all sub-prefixes below the covering prefix. 243 Any query for a sub-prefix must be answered with a data record or 244 NXDOMAIN specifying this zone as the authority. 246 4. Delegation: It must allow the zone owner to delegate smaller 247 address blocks to a child zone which will be independently 248 managed. 250 5. Conformance: It should align with naming conventions and 251 delegation structures already in use by the RIRs for IN-ADDR.ARPA 252 and IP6.ARPA. 254 6. Simplicity: The naming structure should be understandable, or at 255 a minimum, able to be easily constructed by software provisioning 256 tools and utilities such as DIG. 258 4. Reverse DNS CIDR Name Specification 260 The naming method described in this section is based on the well- 261 known technique of performing a binary AND to a bit-mask and the low- 262 order octet of an IP address. The result is then broken up into 263 individual sub-names using the "." separator. The result looks like 264 an ENUM or IPv6 reverse-DNS address; that is, a string of chained 265 empty non-terminal sub-names. 267 This name-chaining creates the desired effect of enabling a DNS zone 268 delegation at any point in the chain. For example, the naming scheme 269 allows for the creation of two /17's from a /16, two /18's from a 270 /17. 272 4.1. IPv4 Address Block Naming 274 The CIDR to Reverse-DNS name conversion is performed as follows: 276 1. Remove any octets that are not significant. An octet is 277 significant if it includes any part of the network address. An 278 octet is not significant if all bits correspond to the host 279 portion of the address. For example, 129.82.0.0/16 --> 129.82 280 and 129.82.160.0/19 --> 129.82.160 282 2. If the prefix falls on an octet boundary: first, invert the 283 address and insert a "m" label as the first label to indicate 284 this is a prefix name and, then, append in-addr.arpa to the end 285 e.g. 129.82 --> m.82.129.in-addr.arpa. 287 3. If the prefix does not fall on an octet boundary: 289 A. Truncate the name to remove the least significant octet. Add 290 a "m" label to this domain name to indicate "mask". 292 B. Convert the least significant octet to binary, separating 293 each bit into its own label (with a "." character). 295 C. Truncate the binary labels to the N significant labels that 296 correspond to the given prefix_length. 298 D. Reverse the string and add ".in-addr.arpa." 300 Several examples illustrate this algorithm. These examples show the 301 conversion to binary, followed by the truncation, followed by the 302 name reversal. 304 129.82.0.0/16 --> m.82.129.in-addr.arpa. (at octet boundary) 305 129.82.64.0/18 --> 129.82.m.0.1.0.0.0.0.0.0 306 --> 129.82.m.0.1 (N = 18 mod 8 = 2) 307 --> 1.0.m.82.129.in-addr.arpa. 309 129.82.64.0/20 --> 129.82.m.0.1.0.0.0.0.0.0 310 --> 129.82.m.0.1.0.0 (N = 20 mod 8 = 4) 311 --> 0.0.1.0.m.82.129.in-addr.arpa. 313 129.82.160.0/20 --> 129.82.m.1.0.1.0.0.0.0.0 314 --> 129.82.m.1.0.1.0 (N = 20 mod 8 = 4) 315 --> 0.1.0.1.m.82.129.in-addr.arpa. 317 129.82.160.0/23 --> 129.82.m.1.0.1.0.0.0.0.0 318 --> 129.82.m.1.0.1.0.0.0.0 (N = 23 mod 8 = 7) 319 --> 0.0.0.0.1.0.1.m.82.129.in-addr.arpa. 321 15.192.0.0/12 --> 15.192.m.1.1.0.0.0.0.0.0 322 --> 15.192.m.1.1.0.0 (N = 12 mod 8 = 4) 323 --> 0.0.1.1.m.15.in-addr.arpa. 325 The Reverse-DNS name to CIDR conversion is performed as follows: 327 1. Drop ".in-addr.arpa" from the string. 329 2. Calculate the prefix length from the name using the formula: 331 p_len = 8*(token count after "m") + (token count before "m") 333 Each token comprises the digits (or letter) between periods. 335 3. Reverse the order of the tokens in the string. 337 4. Use the binary values at the end to calculate the final octet. 338 To do this take the binary values represented and left shift them 339 until there are 8 bits, convert to decimal. 341 5. Remove the m token and all tokens following it; replace them with 342 the decimal representation of the binary value. 344 6. Append a "/" and the prefix length. 346 Examples: 348 1.0.m.82.129.in-addr.arpa --> 129.82.64.0/18 349 (example has 2 octets + 2 binary digits, so mask length = 18) 351 0.0.1.0.m.82.129.in-addr.arpa --> 129.82.64.0/20 352 (example has 2 octets + 4 binary digits, so mask length = 20) 354 0.0.0.1.0.1.m.129.in-addr.arpa--> 129.160.0/14 355 (example has 1 octet + 6 binary digits, so mask length = 14) 357 4.2. IPv6 Address Block Naming 359 The IPv6 naming convention is similar, with the exception that 4-bit 360 nibble boundaries are used instead of octets, and "ip6.arpa" is used 361 as the suffix. 363 Examples: 365 2607:fa88::/32 --> m.8.8.a.f.7.0.6.2.ip6.arpa 366 (on nibble boundary) 368 2607:fa88:8000::/33 --> 2.6.0.7.f.a.8.8.m.1.0.0.0 369 --> 2.6.0.7.d.a.8.8.m.1 (33 mod 4 = 1) 370 --> 1.m.8.8.a.f.7.0.6.2.ip6.arpa 372 2607:fa88:e000::/35 --> 2.6.0.7.f.a.8.8.m.1.1.1.0 373 --> 2.6.0.7.d.a.8.8.m.1.1.1(35 mod 4 = 3) 374 --> 1.1.1.m.8.8.a.f.7.0.6.2.ip6.arpa 376 4.3. Maintaining one-to-one mapping 378 We note that the naming convention uses the letter "m" to indicate a 379 transition from octet/nibble numbering to binary numbering for the 380 remainder of the name. Nothing restricts a DNS administrator from 381 creating a name in which the sequence of binary digits extends past 382 the next octet or nibble boundary. Applications may actually find 383 this to be a useful capability. Nevertheless, this document defines 384 a naming convention where each prefix maps to a unique name, as 385 described in section 5. We therefore add the restriction that any 386 application looking for records associated with a prefix MUST check 387 standard naming convention (e.g. m.0.82.129.in-addr.arpa at an octet 388 boundary) and if the desired records are found, the application MUST 389 prefer these records over any records found at a non-standard 390 encoding. 392 5. Related Work 394 The process of mapping CIDR addresses into the reverse-DNS name space 395 is difficult because the prefix length of an IPv4 CIDR address is an 396 arbitrary number from 0 to 32. These numbers do not necessarily 397 align with an IPv4 octet. 399 The problem of associating records with network names dates back to 400 [RFC1035]. This RFC uses 10.in-addr.arpa to represent net 10 and 401 uses PTR records to identify gateways on net 10. This works 402 intuitively for simple classful network such as 10/8 and sets the 403 stage for future work, but fails to fully specify a convention. For 404 example, it does not show how to represent mask lengths that don't 405 match the classful boundary and clearly does not address arbitrary 406 mask lengths; CIDR addresses were not yet defined. 408 5.1. Naming via RFC 1101 410 [RFC1101] addressed how to add subnet masks by introducing both 411 reverse DNS conventions and pointers to names in the forward DNS tree 412 (e.g. DNS zones not under in-addr.arpa). However, this RFC also 413 pre-dates the existence of CIDR addresses and some small ambiguities 414 became more pronounced with the introduction of CIDR prefixes. These 415 ambiguities make the convention infeasible for current applications. 417 To illustrate the problem, suppose one wants to associate a network 418 name and some additional information with the address blocks 419 129.82.0.0/16, 129.82.0.0/18, and 129.82.0.0/20. RFC 1101 uses PTR 420 records to encode the network name and A records to define the 421 existence of a subnet with a specified mask length. We will use a 422 TXT record to store the additional information. The TXT record is 423 simply meant to represent an arbitrary RR type. 425 The following entries would be added to the appropriate enclosing 426 zone: 428 ;129.82.0.0/16 network name and additional information 429 0.0.82.129.in-addr.arpa IN PTR topnet.myzone.example. 430 0.0.82.129.in-addr.arpa IN TXT "my additional info" 432 ; define and name the 129.82.0.0/18 network name 433 0.0.82.129.in-addr.arpa IN PTR subnet1.myzone.example. 434 0.0.82.129.in-addr.arpa IN A 255.255.192.0; /18 mask 435 0.0.82.129.in-addr.arpa IN TXT "/18 additional info" 437 ; define and name the 129.82.0.0/20 network name 438 0.0.82.129.in-addr.arpa IN PTR subnet2.myzone.example. 439 0.0.82.129.in-addr.arpa IN A 255.255.240.0 ; /20 mask 440 0.0.82.129.in-addr.arpa IN TXT "/20 additional info" 442 The first A record indicates there is a 129.82.0.0/18 subnet defined. 443 The second A record indicates there is a 129.82.0.0/20 subnet 444 defined. The ambiguity arises when wants to obtain the TXT (or PTR 445 or any other RR type) associated with 129.82.0.0/18. A query will 446 return the three records in the TXT RRSet at 0.0.82.129.in-addr.arpa. 447 Only one of these TXT RRs is associated with 129.82.0.0/18 and there 448 is no way to determine which of the three is the correct one. 450 This naming convention fails the "Unambiguous" requirement. We do 451 not consider additional issues since the above ambiguity makes the 452 RFC 1101 approach infeasible. The naming convention introduced later 453 in this document builds on the main concepts in this RFC, resolves 454 the ambiguity, explicitly expands to more than just network names, 455 and addresses our design goals and operational concerns. 457 5.2. CIDR Naming via RFC 2317 459 According to [RFC2317], the purpose of the document is to describe "a 460 way to do IN-ADDR.ARPA delegation on non-octet boundaries for address 461 spaces covering fewer than 256 addresses." It is not a general 462 naming scheme for prefixes. However, some would argue that it might 463 be extended into a general naming convention. 465 To create a naming convention based on [RFC2317], we note a 466 representative example maps prefix 192.0.2.0/25 to the DNS name 467 0/25.2.0.192.in-addr.arpa. More generally, a prefix of the form 468 A.B.C.D/M is mapped to the name D/M.C.B.A.in-addr.arpa. IPv6 469 prefixes are not discussed and the IPv4 mask length is assumed to be 470 strictly greater than 24. 472 This approach does not satisfy the unambiguous requirement for 473 prefixes with a mask length smaller than 24. For example, the 474 [RFC2317] style name for prefix 129.82.0.0/16 maps to the DNS name 475 0/16.0.82.129.in-addr.arpa. It also maps to the names 476 0/16.82.129.in-addr.arpa, 82/16.129.in-addr.arpa, and 82.129.in- 477 addr.arpa. [RFC2317] does not defines which of these is correct. 478 This is not a flaw in the RFC. Instead, [RFC2317] says it is 479 designed for "address spaces covering fewer than 256 addresses". 480 129.82.0.0/16 covers over 65,000 addresses, is clearly out scope, and 481 thus a name for this prefix is not specified. 483 To extend this to a general naming convention, let 129.82.0.0/16 map 484 to the DNS name 82.129.in-addr.arpa, 129.82.0.0/18 map to the DNS 485 name 0/18.82.129.in-addr.arpa, and 129.82.0.0/20 map to the DNS name 486 0/20.82.129.in-addr.arpa. This mapping improves on the previous 487 [RFC1101] approach in that each prefix now has a unique name, but we 488 show the approach has several other critical flaws. 490 One limitation is that the scheme is flat rather than hierarchical. 491 In the prefix hierarchy, 129.82.0.0/18 is descendant of 492 129.82.0.0/16. In the DNS tree, the name 0/18.82.129.in-addr.arpa is 493 a descendant of 82.129.in-addr.arpa. This is the desired property, 494 but is only preserved at the octet boundary. 496 In the prefix hierarchy, 129.82.0.0/20 is descendant of 497 129.82.0.0/18. In the DNS tree, the name 0/18.82.129.in-addr.arpa 498 and 0/20.82.129.in-addr.arpa are siblings, both are direct 499 descendants of 82.129.in-addr.arpa. The hierarchical prefix 500 structure is not preserved and mapped into a single flat space. 501 Worse still, all /17, /18, /19, /20, /21, /22, and /23 prefixes are 502 siblings. There is no hierarchical relationship whatsoever for 503 prefixes that don't fall on an octet boundary, violating the Coverage 504 Authority and Delegation requirements. 506 This document proposes a naming convention that adds as much 507 hierarchy as possible, while still preserving the existing reverse 508 DNS tree structure. In our approach, the name for 129.82.0.0/20 is a 509 descendant of the name for 129.82.0.0/18. 511 Overall, [RFC2317] was not intended to encode IPv4 prefixes with a 512 mask length smaller than 24 and it does not consider IPv6. Because 513 the namespace is flat, it fails to meet the design requirements of 514 Coverage Authority, Allowing Delegation, and arguably Simplicity. 516 5.3. Prior Work on CIDR Names for Routing 518 Over a decade ago, [I-D.bates-bgp4-nlri-orig-verif] proposed to use 519 the reverse DNS to verify the origin AS associated with a prefix. 520 This requires both a naming convention for converting the name into a 521 prefix and additional resource record types for storing origin 522 information, along with recommendations on their use. 524 Our focus in this draft is on the naming convention. Draft 525 [I-D.bates-bgp4-nlri-orig-verif] as well as other subsequent work on 526 BGP security, extends [RFC2317] style names to encode a prefix. For 527 example, the draft proposes to encode the prefix 10.1.128/20 as the 528 DNS name 128/20.1.10.bgp.in-addr.arpa. 530 In [I-D.bates-bgp4-nlri-orig-verif], the DNS hierarchy and the IP 531 address hierarchy diverge and the approach fails to meet the Coverage 532 Authority requirement. To see this, consider the prefixes 533 10.1.128/20 and 10.1.128/21. in CIDR terminology, 10.1.128/21 is 534 covered by 10.1.128/20, but this relationship is not captured in the 535 DNS hierarchy. 10.1.128/21 is encoded as 128/21.1.10.bgp.in-addr.arpa 536 and thus 10.1.128/20 and 10.1.128/21 are siblings in the DNS tree 537 structure. 539 This can be overcome by introducing a large number of CNAME records; 540 one for every potential subprefix. We instead provide an approach 541 where the CIDR hierarchy and DNS hierarchy align. 543 6. Additional Considerations 545 This draft proposes a naming convention for IPv4 and IPv6 prefixes. 546 With the introduction of a such a convention, a number of new 547 possibilities are enabled and a number of issues have been raised. 548 In this section, we summarize some of the main discussions. Though 549 these are not directly part of the naming convention, they do help to 550 review issues that may help application designers make better use of 551 prefix names and help operators manage reverse zones. We first 552 discuss how the naming convention interacts with the current octet 553 (IPv4) or nibble (IPv6) based reverse DNS tree structure and then 554 turn to the problem of prefix enumeration and find the longest match 555 for a prefix. 557 6.1. Splitting a /16 into two /17s 559 Suppose organization X has been allocated 10.10.0.0/16 by SomeRIR. 560 Organization X assigns 10.10.0/17 to Organization Y and assigned 561 10.10.128/17 to Organization Z. Concerns have been raised that 562 Organization X needs to create 256 delegations. More precisely, 563 Organization X needs to delegate 0.10.10.in-addr.arpa, 1.10.10.in- 564 addr.arpa, up to 127.10.10.in-addr.arpa to Organization Y. Similarly, 565 128.10.10.in-addr.arpa up to 255.10.10.in-addr.arpa need to be 566 delegated to Organization Z. This is the current practice and the 567 naming convention here does not change this. 569 The naming convention described in this document requires no changes 570 to the existing delegation operations. The naming convention does 571 add one additional delegation, 0.m.10.10.in-addr.arpa, to 572 Organization Y. Similarly, the naming convention does add one 573 additional delegation, 1.m.10.10.in-addr.arpa, to Organization Z. 575 6.2. Allocating a /16 and then assigning the /16 577 Suppose organization X has been allocated 10.10.0.0/16 by SomeRIR. 578 Organization X assigns 10.10.0/16 to Organization Y. SomeRIR needs to 579 update the delegation (NS and DS records) in the 10.in-addr.arpa zone 580 to point to Organization Y. Again, this is the current practice and 581 the naming convention here does not change this. 583 6.3. Delegations that Span Octet boundaries 585 Suppose organization X has been allocated 10.0.0.0/10 by SomeRIR. 586 Organization X assigns 10.0.128/17 to Organization Y. SomeRIR 587 allocates 10.0/10 to Organization X, SomeRIR should also delegate the 588 64 zones 0.10.in-addr.arpa, 1.10.in-addr.arpa, ... 63.10.in-addr.arpa 589 to Organization X. Organization Y should be delegated the 128 zones 590 from 128.0.10.in-addr.arpa to 255.0.10.in-addr.arpa. Note all these 591 delegations come from the 0.10.in-addr.arpa zone, so SomeRIR is not 592 involved in the delegation. Again, this is the current practice and 593 the naming convention here does not change this. 595 SomeRIR should also delegate the 0.0.m.10.in-addr.arpa namespace to 596 Organization X. Similarly, Organization X should also delegate the 597 namespace 1.m.0.10.in-addr.arpa to Organization Y. Note this 598 delegation comes from the 0.10.in-addr.arpa zone run by Organization 599 X and SomeRIR is not involved in the delegation. 601 The addition of the new naming convention did not obsolete the need 602 to add to delegate the various octet boundary zones. In other words, 603 one still needs to continue the practice of delegating zones like 604 0.10.in-addr.arpa and 128.0.10.in-addr.zones. This draft 605 intentionally works with the existing reverse DNS tree and does not 606 change the practices for existing octet boundary zones. 608 6.4. Legacy Behavior at Octet Boundaries 610 The existing reverse DNS structure is aligned on octet boundaries for 611 IPv4 and nibble boundaries for IPv6. The naming convention 612 introduced here adds to the existing reverse DNS tree; it does not 613 change the existing structure. This is a deliberate choice not to 614 reinvent the reverse DNS but rather to enhance the existing 615 structure. The naming convention proposed here builds on the 616 existing reverse DNS structure and thus inherits both advantages and 617 disadvantages from the existing system. 619 6.5. The Naming Convention and Zone Structures 621 The naming convention does not impose any semantics on zone 622 structure. As with any DNS name, a resolver need not be aware of how 623 the zone cuts are structured and no specific requirements are added 624 for zone management. For example, some sites may choose to delegate 625 at a subprefix boundary while others maintain one large zone. Names 626 can make use of CNAME and DNAME records if the zone administrator so 627 desires. This is simply a naming convention and does not change any 628 existing resolver or server behavior. 630 6.6. Separation of Prefix Data and PTR Records 632 Some organization may want to separate the administration of prefix 633 related data (geolocations, prefix ownership, and so forth) from the 634 management of traditional PTR records. Note that all prefix related 635 data is stored at a name that includes the "m" label. This "m" label 636 could be used as delegation point to separate the administration of 637 prefix data from the administration of PTR records. 639 To illustrate this, suppose the owner of 129.82.128/17 would like one 640 to keep the management of prefix related data distinct from the 641 management of their PTR records. Note that for all prefixes with a 642 mask length between 17 and 23 are part of the zone 1.m.82.129.in- 643 addr.arpa. This zone can simply be delegated to the group managing 644 prefix related data while the group managing PTR records continues to 645 be responsible for the zones 128.82.129.in-addr.arpa to 646 255.82.129.in-addr.arpa. 648 If prefix data is also to be stored at mask lengths ranging between 649 24 and 32, then m.128.82.129.in-addr.arpa to m.255.82.129.in- 650 addr.arpa can also be delegated to the group managing prefix data. 651 In this sense, an organization can keep a complete separation between 652 groups managing prefix data and groups managing PTR records for host 653 names. 655 During the discussion of the draft, some organizations expressed a 656 desire to achieve this type of separation in operational practice. 657 In particular, groups associated with routing and prefix management 658 might manage the prefix related records while other groups associated 659 with DHCP and IP address management currently manage the PTR records. 660 This example simply illustrates these groups can be kept distinct if 661 an organization so desires. As with any DNS deployment, an 662 organization makes its own decisions on where to make zone cuts and 663 how to manage their own delegation. 665 6.7. Prefix Enumeration 667 This document introduces a convention for naming IPv4 and IPv6 668 prefixes. It is not an enumeration technique. To illustrate the 669 difference between lookup and enumeration we consider a hypothetical 670 application that uses LOC resource records to associate geographic 671 locations with prefixes. Note the use of the LOC record is simply to 672 make the example concrete and the same argument applies to any type 673 of data stored at a prefix. 675 An application can easily lookup the LOC resource record associated 676 with a prefix using this naming convention. The application simply 677 converts the prefix (IPv4 or IPv6) into a DNS name as described in 678 the previous sections and queries for the LOC record associated with 679 that name. Using DNSSEC, an application can also authenticate the 680 LOC record or provide authenticated denial of existence proving that 681 no such LOC record exists. 683 A distinct question is how one might enumerate all possible prefixes 684 that have LOC records. Techniques to provide enumeration of prefixes 685 in the DNS are outside the scope of this document. 687 6.8. Finding Longest Matches 689 Another distinct question is how one could find the longest match for 690 a given IP address or prefix. For example, the application might 691 want to find the most specific prefix (longest match) that has a LOC 692 record and covers a particular IP address. Similar to enumeration, 693 the naming convention does not directly provide longest match. 694 Applications might develop strategies for searching all covering 695 prefixes using variations of brute force searches, exploiting NSEC 696 records (if used), using NXDOMAIN queries to find zone boundaries, or 697 by adding additional record types to aid in finding related prefixes. 698 [RFC1101], for example, uses an A record to specify a mask length for 699 a contained subnet. It also shows how to chase such A record until 700 the longest match is found. This scheme could be used with the 701 naming convention proposed here as well. Nevertheless, these 702 techniques are application-dependent. The naming convention proposed 703 here in itself does not provide an explicit mechanism to find the 704 longest matching prefix for an IP address. 706 The naming convention proposed here provides a way to name a prefix. 707 Once one has this name, all the advantages (and disadvantages) of DNS 708 apply. One can easily issue queries for the name and retrieve 709 resource records associated with that name. For many applications, 710 this is sufficient. Applications that require more complex prefix 711 related functions, such as enumerating all prefixes of a given type 712 or finding the longest prefix match, need to build this functionality 713 into their application. The naming convention provides the necessary 714 building blocks to achieve this, but does not dictate how a 715 particular application will assemble the building blocks. 717 7. Security Considerations 719 This document only introduces a naming convention. Applications that 720 make use of this naming convention may require the use of DNSSEC to 721 validate the resource records stored at these names. 723 8. IANA Considerations 725 This document does not request any IANA action. 727 9. Acknowledgments 729 The authors would like to thank Danny McPherson (Verisign), Lixia 730 Zhang (UCLA), and Kim Claffy (CAIDA) for their comments and 731 suggestions. This document was aided via numerous discussions at 732 NANOG, IETF and private meetings with ISPs, telecomm carriers, and 733 research organizations too numerous to mention by name. Finally, the 734 naming convention has been in use by some organizations for over a 735 year at the time of this draft. Thanks to all for your comments and 736 advice. 738 10. Change History 740 Changes from version 03 to 04 742 No changes were made to the naming convention, requirements, or 743 document scope. 745 Minor changes to fix two typos and also to improve grammar 746 throughout. 748 Clarified the description of Related Work based on feedback 749 received. 751 Simplified the Additional Considerations based on feedback 752 received. 754 No changes in the convention itself were added or removed. 756 Changes from version 02 to 03 758 Added detail regarding [RFC1101] and how it historically defined a 759 method to name subnets; explained how CIDR introduced ambiguities 760 into [RFC1101] creating the need for a more comprehensive naming 761 convention. 763 Added similar explanatory material for [RFC2317]. 765 Added "unambiguous" as a design objective. 767 Added definition of "nibble boundary". 769 Expanded and clarified the discussion of operational procedures 770 required for maintaining the existing reverse DNS tree as subnets 771 are delegated within or across octet boundaries. 773 Showed how largest enclosing prefix could be found using [RFC1101] 774 A record semantics within the proposed naming structure. 776 Added clarification that the convention requires creating a name 777 in which the sequence of binary digits does not extend past the 778 next octet or nibble boundary. 780 Added Cathie Olschanowsky as a co-author. 782 Changes from version 01 to 02 784 Concerns were raised at the IETF 83 meeting that the document 785 appeared too specific to the routing application. Several other 786 applications were mentioned. We clarified the introduction to 787 show that the naming convention is application agnostic. 789 Expanded the related work discussion to include RFC 1101. 791 The "m" label is now added even when on an octet boundary. 793 Moved all other discussion into the Additional Considerations 794 section; removing the alternate naming and replacing it with a 795 discussion of existing delegations, adding a section on separating 796 prefix and PTR records, added a section on enumerating prefixes 797 and finding longest matches. All these changes reflect comments 798 from the mailing list, IETF 83 discussions, and other comments. 799 They do not change the naming scheme itself. 801 To emphasize the approach is application agnostic, the appendix 802 examples were changed from using routing security records to LOC 803 records. Any record type could be used, but LOC records were 804 chosen as they were viewed as easy to understand. 806 Changes from version 00 to 01 808 Introduction added an additional subsection on aligning the DNS 809 hierarchy with the IP address hierarchy. 811 Clarified step 1 of the naming algorithm on removing octets that 812 are not significant. 814 Expanded and clarified the discussion of alternate name encoding 815 for prefixes on an octet boundary. 817 Added Eric Osterweil as a co-author 819 11. References 821 11.1. Normative References 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, March 1997. 826 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 827 (CIDR): The Internet Address Assignment and Aggregation 828 Plan", BCP 122, RFC 4632, August 2006. 830 11.2. Informative References 832 [I-D.bates-bgp4-nlri-orig-verif] 833 Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based 834 NLRI origin AS verification in BGP", 835 draft-bates-bgp4-nlri-orig-verif-00 (work in progress), 836 January 1998. 838 [I-D.gersch-grow-revdns-bgp] 839 Gersch, J., Massey, D., Osterweil, E., and L. Zhang, "DNS 840 Resource Records for BGP Routing Data", 841 draft-gersch-grow-revdns-bgp-00 (work in progress), 842 February 2012. 844 [I-D.howard-isp-ip6rdns] 845 Howard, L. and A. Durand, "Reverse DNS in IPv6 for 846 Internet Service Providers", draft-howard-isp-ip6rdns-04 847 (work in progress), September 2010. 849 [RFC1035] Mockapetris, P., "Domain names - implementation and 850 specification", STD 13, RFC 1035, November 1987. 852 [RFC1101] Mockapetris, P., "DNS encoding of network names and other 853 types", RFC 1101, April 1989. 855 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 856 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. 858 Appendix A. Example Zone Files 860 A.1. Example 1 862 This example shows several DNS records added to an existing reverse- 863 DNS zone file at octet boundary 129.82.0.0/16. The records show how 864 LOC records could be specified in the zone file to be associated with 865 an address block. Otherwise no other changes were made. This 866 example has added records with LOC information pertinent to address 867 blocks 129.82/16 and the four /18's at 129.82.0.0/18, 129.82.64.0/18, 868 129.82.128.0/18, and 129.82.192.0/18. 870 $TTL 3600 871 $ORIGIN 82.129.in-addr.arpa. 873 @ IN SOA rush.colostate.edu. dnsadmin.colostate.edu. ( 874 2012021300 ; serial number 875 900 ; refresh, 15 minutes 876 600 ; update retry, 10 minutes 877 86400 ; expiry, 1 day 878 3600 ; minimum, 1 hour 879 ) 881 IN NS dns1.colostate.edu. 882 IN NS dns2.colostate.edu. 884 m IN LOC latitude/longitude info for the /16 885 ; 129.82.0.0/16 887 0.0.m IN LOC lat/long for North campus 888 ; 129.82.0.0/18 890 1.0.m IN LOC lat/long for South campus 891 ; 129.82.64.0/18 893 0.1.m IN LOC lat/long for Denver campus 894 ; 129.82.128.0/18 896 1.1.m IN LOC lat/long for Boulder campus 897 ; 129.82.192.0/18 899 ; delegations required for 256 /24 zones which contain PTR records 901 1 IN NS dns1.colostate.edu. 902 IN NS dns2.colostate.edu. 903 2 IN NS dns1.colostate.edu. 904 IN NS dns2.colostate.edu. 906 ; continuation to 255 is left out for the sake of brevity 908 A.2. Example 2 910 This example illustrates the creation of a new zone for 911 216.17.128.0/17 which is not at an octet boundary. The existing 256 912 zones delegated at IN-ADDR.ARPA for the range 0.17.128 through 913 255.17.216.in-addr.arpa remain unchanged; they contain PTR records 914 maintained by the appropriate zone owners. 916 In this example we have added several records all at the same domain 917 name with information pertinent to address block 216.17.128.0/17. 919 Only a single new delegation needs to be added to IN-ADDR.ARPA: 921 1.m.17.216.in-addr.arpa NS ns.frii.net 923 This delegation refers to the new /17 zone and is not in conflict 924 with any of the pre-existing /24 zones. 926 $TTL 3600 927 $ORIGIN 1.m.17.216.in-addr.arpa. 929 @ IN SOA ns1.frii.net. hostmaster.frii.net. ( 930 2012021300 ; serial number 931 14400 ; refresh, 4 hours 932 3600 ; update retry, 1 hour 933 604800 ; expiry, 7 days 934 600 ; minimum, 10 minutes 935 ) 937 IN NS ns1.frii.net. 938 IN NS ns2.frii.net. 940 $ORIGIN 17.216.in-addr.arpa. 942 1.m LOC lat/long for main office 943 ;216.17.128.0/17 945 ; no other delegations or PTR records are needed in this zone file 947 Authors' Addresses 949 Joe Gersch 950 Secure64 SW Corp 951 Fort Collins, CO 952 US 954 Email: joe.gersch@secure64.com 956 Dan Massey 957 Colorado State University 958 Fort Collins, CO 959 US 961 Email: massey@cs.colostate.edu 963 Eric Osterweil 964 Verisign 965 Reston, VA 966 US 968 Email: eosterweil@verisign.com 970 Cathie Olschanowsky 971 Colorado State University 972 Fort Collins, CO 973 US 975 Email: cathie@cs.colostate.edu