idnits 2.17.00 (12 Aug 2021) /tmp/idnits36832/draft-housley-rfc2050bis-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2013) is 3354 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6484' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC1466' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC1518' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC1814' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC1900' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC2050' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC2317' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC2350' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC3221' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC3707' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC4632' is defined on line 344, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1466 (Obsoleted by RFC 2050) -- Obsolete informational reference (is this intentional?): RFC 2050 (Obsoleted by RFC 7020) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security, LLC 4 Obsoletes: 2050 (if approved) J. Curran 5 Intended status: Informational ARIN 6 Expires: August 31, 2013 G. Huston 7 APNIC 8 D. Conrad 9 Virtualized, LLC 10 March 2013 12 The Internet Numbers Registry System 13 draft-housley-rfc2050bis-00.txt 15 Abstract 17 This document provides information about the current Internet Numbers 18 Registry System used in the distribution of globally unique Internet 19 Protocol (IP) address space and autonomous system (AS) numbers. 21 This document also provides information about the processes for 22 further evolution of the Internet Numbers Registry System. 24 This document replaces RFC 2050. 26 This document does not propose any changes to the Internet Numbers 27 Registry System. 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 31, 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 (http://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Table of Contents 59 1. Introduction and Goals . . . . . . . . . . . . . . . . . . . . 2 60 2. Internet Numbers Registry System Structure . . . . . . . . . . 3 61 3. Internet Numbers Registry Technical Considerations . . . . . . 4 62 4. Internet Numbers Registry Evolution . . . . . . . . . . . . . 4 63 5. Summary of Changes Since RFC 2050 . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction and Goals 74 The administrative structures of the Internet Numbers Registry System 75 described in this document are largely the result of the interaction 76 of operational practices, existing routing technology, number 77 resource assignments that have occurred over time, and network 78 architectural history. Further discussion and analysis of these 79 interactions are outside the scope of this document. 81 Internet number resources are currently distributed according to the 82 following (non-exclusive) goals: 84 1) Allocation Pool Management: Due to the fixed lengths of IP 85 addresses and AS numbers, the pools from which these resources 86 are allocated are finite. As such, allocations must be made 87 in accordance with the operational needs of those running the 88 networks that make use of these number resources and by taking 89 into consideration pool limitations at the time of allocation. 91 2) Hierarchical Allocation: Given current routing technology, the 92 distribution of IP addresses in a hierarchical manner 93 increases the likelihood of continued scaling of the 94 Internet's routing system. As such, it is a goal to allocate 95 IP addresses in such a way that permits these addresses 96 aggregated into a minimum number of routing announcements. 97 However, whether IP addresses are actually announced to the 98 Internet, and the manner of their advertisement into the 99 Internet's routing system is an operational consideration 100 outside of the scope of the Internet Numbers Registry System. 102 3) Registration Accuracy: A core requirement of the Internet 103 Numbers Registry System is to maintain a registry of 104 allocations to ensure uniqueness and to provide accurate 105 registration information of those allocations in order to meet 106 a variety of operational requirements. 108 These goals may sometimes conflict with each other or be in conflict 109 with the interests of individual end-users, Internet service 110 providers, or other number resource consumers. Careful analysis, 111 judgment, and cooperation among registry system providers and 112 consumers at all levels via community-developed policies is necessary 113 to find appropriate compromises to facilitate Internet operations. 115 2. Internet Numbers Registry System Structure 117 The Internet Registry (IR) hierarchy was established to provide for 118 the allocation of IP addresses and AS numbers with consideration to 119 the above goals. This hierarchy is rooted in the Internet Assigned 120 Numbers Authority (IANA) address allocation function, which serves a 121 set of "Regional Internet Registries" (RIRs); the RIRs then serve a 122 set of "Local Internet Registries" (LIRs) and other customers. LIRs 123 in turn serve their respective number resource consumers (which may 124 be themselves, their customers, "sub-LIRs", etc.) 126 IANA 128 The Internet Assigned Numbers Authority (IANA) is the traditional 129 name for the technical team making and publishing the assignments 130 of Internet protocol technical parameters, including Internet 131 Protocol (IP) address space. As a result of a Memorandum of 132 Understanding (MOU)[RFC2860] between the IETF, IAB, and ICANN, the 133 technical work of the Internet Assigned Numbers Authority (IANA) 134 is now performed by ICANN. Today, IANA administers IP address 135 space and AS numbers according to global number resource policies 136 as developed per the agreement between ICANN and the Regional 137 Internet Registries [ASOMOU] and documented in [ICANNv4], 138 [ICANNv6], and [ICANNASN]. 140 Regional IRs 141 In order to promote distribution of the Internet number resource 142 registration function, RFC 1366 proposed delegating responsibility 143 to regional bodies. These bodies became known as the Regional 144 Internet Registries (RIRs). The RIRs operate in continent-sized 145 geopolitical regions. Currently there are five RIRs: AfriNIC 146 serving Africa, APNIC serving parts of Asia and the Pacific 147 region, ARIN serving North America and parts of the Caribbean, 148 LACNIC serving Latin America and parts of the Caribbean, and RIPE 149 NCC serving Europe, parts of Asia and the Middle East. The RIRs 150 were established via a global policy process that has been 151 documented as the ICANN "Internet Consensus Policy 2" [ICP-2], 152 which details the principles and criteria for establishment of 153 Regional Internet Registries. The RIRs also conduct regional 154 number policy development used in the administration of their 155 number resources. 157 Local IRs 159 Local Internet Registries (LIRs) are established through a 160 relationship with the body from which they received their 161 addresses, typically the RIR that serves the region in which they 162 operate, a parent LIR, or other allocating entity. LIRs that span 163 multiple regions may establish relationships with multiple RIRs. 164 LIRs typically perform IP address allocation services for their 165 customers such as ISPs, end users, or other "child" LIRs. 167 3. Internet Numbers Registry Technical Considerations 169 As a result of the system of technical standards and guidelines 170 established by the IETF as well as historical and operational 171 constraints, there have been technical considerations regarding the 172 services provided by the Internet Numbers Registry System as it 173 evolved. These technical considerations have included: 175 1) Reverse DNS: In situations where reverse DNS was used, the 176 policies and practices of the Internet Numbers Registry System 177 have included consideration of the technical and operational 178 requirements posed by reverse DNS zone delegation [RFC3172]. 180 2) Public WHOIS: The policies and practices of the Internet 181 Numbers Registry System have included consideration of the 182 technical and operational requirements for supporting WHOIS 183 services [RFC3013]. 185 As the Internet and the Internet Numbers Registry System continue to 186 evolve, it may be necessary for the Internet community to examine 187 these and related technical and operational considerations and how 188 best to meet them. 190 4. Internet Numbers Registry Evolution 191 Over the years, the Internet Numbers Registry System has developed 192 mechanisms by which the structures, policies, and processes of the 193 Internet Numbers Registry System itself can evolve to meet the 194 changing demands of the global Internet community. Further evolution 195 of the Internet Numbers Registry System is expected to occur in an 196 open, transparent, and broad multi-stakeholder manner. 198 Per the delineation of responsibility for Internet address policy 199 issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions 200 regarding the evolution of the Internet Numbers Registry System 201 structure, policy, and processes are to take place within the ICANN 202 framework and will respect ICANN's core values [ICANNBL]. These core 203 values encourage broad, informed participation reflecting the 204 functional, geographic, and cultural diversity of the Internet at all 205 levels of policy development and decision-making, as well as the 206 delegation of coordination functions and recognition of the policy 207 roles of other responsible entities that reflect the interests of 208 affected parties. The discussions regarding Internet Numbers 209 Registry evolution must also continue to consider the overall 210 Internet address architecture and technical goals referenced in this 211 document. 213 The foregoing does not alter the IETF's continued responsibility for 214 the non-policy aspects of Internet addressing such as the 215 architectural definition of IP address and AS number spaces and 216 specification of associated technical goals and constraints in their 217 application, assignment of specialized address blocks, and 218 experimental technical assignments as documented in RFC 2860. In 219 addition, in the cases where the IETF sets technical recommendations 220 for protocols, practices, or services which are directly related to 221 IP address space or AS numbers, such recommendations must be taken 222 into consideration in Internet Numbers Registry System policy 223 discussions regardless of venue. 225 5. Summary of Changes Since RFC 2050 227 Since RFC 2050 was published, the Internet and the Internet Numbers 228 Registry System have undergone significant change. This document 229 describes the Internet Numbers Registry System as it presently exists 230 and omits policy and operational procedures that have been superseded 231 by ICANN and RIR policy since RFC 2050 publication. 233 6. Security Considerations 235 It is generally recognized that accuracy and public availability of 236 Internet registry data is often an essential component in researching 237 and resolving security and operational issues on the Internet. 239 7. IANA Considerations 240 The IANA will continue to provide the root of the IP address and 241 autonomous system number hierarchies and will maintain a registry 242 that provides registration information for any allocations made by 243 the IANA. 245 8. Acknowledgements 247 Several people have made comments on draft versions of this document. 248 The authors would like to thank Randy Bush, Brian Carpenter, Daniel 249 Karrenberg, Olaf Kolkman, Scott Bradner, Leslie Daigle and Adiel 250 Akplogan for their constructive feedback and comments. Additionally, 251 we are indebted to the authors of RFC 1466 and RFC 2050 for their 252 earlier contributions in this area. 254 9. References 256 9.1. Normative References 258 [ASOMOU] Published by ICANN, "ICANN Address Supporting Organization 259 (ASO) MoU", October 2004. 261 http://archive.icann.org/en/aso/aso-mou-29oct04.htm 263 [ICANNASN] 264 Ratified by ICANN, "Internet Assigned Numbers Authority 265 (IANA) Policy for Allocation of ASN Blocks to Regional 266 Internet Registries", September 2010. 268 http://www.icann.org/en/resources/policy/global-addressing 269 /global-policy-asn-blocks-21sep10-en.htm 271 [ICANNBL] ICANN, "Bylaws for Internet Corporation for Assigned Names 272 and Numbers", December 2012. 274 http://www.icann.org/en/about/governance/bylaws 276 [ICANNv4] Ratified by ICANN, "Global Policy for Post Exhaustion IPv4 277 Allocation Mechanisms by the IANA", May 2012. 279 http://www.icann.org/en/resources/policy/global-addressing 280 /allocation-ipv4-post-exhaustion 282 [ICANNv6] Ratified by ICANN, "Internet Assigned Numbers Authority 283 (IANA) Policy For Allocation of IPv6 Blocks to Regional 284 Internet Registries", September 2006. 286 http://www.icann.org/en/resources/policy/global-addressing 287 /allocation-ipv6-rirs 289 [ICP-2] Published by ICANN, "ICP-2: Criteria for Establishment of 290 New Regional Internet Registries", July 2001. 292 http://www.icann.org/icp/icp-2.htm 294 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 295 Understanding Concerning the Technical Work of the 296 Internet Assigned Numbers Authority", RFC 2860, June 2000. 298 [RFC3013] Killalea, T., "Recommended Internet Service Provider 299 Security Services and Procedures", BCP 46, RFC 3013, 300 November 2000. 302 [RFC3172] Huston, G., "Management Guidelines & Operational 303 Requirements for the Address and Routing Parameter Area 304 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 306 [RFC6484] Kent, S., Kong, D., Seo, K. and R. Watro, "Certificate 307 Policy (CP) for the Resource Public Key Infrastructure 308 (RPKI)", BCP 173, RFC 6484, February 2012. 310 9.2. Informative References 312 [RFC1466] Gerich, E., "Guidelines for Management of IP Address 313 Space", RFC 1466, May 1993. 315 [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address 316 Allocation with CIDR", RFC 1518, September 1993. 318 [RFC1814] Gerich, E., "Unique Addresses are Good", RFC 1814, June 319 1995. 321 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 322 RFC 1900, February 1996. 324 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 325 E. Lear, "Address Allocation for Private Internets", BCP 326 5, RFC 1918, February 1996. 328 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and 329 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 330 BCP 12, RFC 2050, November 1996. 332 [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN- 333 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. 335 [RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer 336 Security Incident Response", BCP 21, RFC 2350, June 1998. 338 [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the 339 Internet", RFC 3221, December 2001. 341 [RFC3707] Newton, A., "Cross Registry Internet Service Protocol 342 (CRISP) Requirements", RFC 3707, February 2004. 344 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 345 (CIDR): The Internet Address Assignment and Aggregation 346 Plan", BCP 122, RFC 4632, August 2006. 348 Authors' Addresses 350 Russ Housley 351 Vigil Security, LLC 352 918 Spring Knoll Drive 353 Herndon, VA 20170 354 USA 356 Phone: +1 703 435 1775 357 Email: housley@vigilsec.com 359 John Curran 360 American Registry for Internet Numbers (ARIN) 361 3635 Concorde Parkway 362 Chantilly, VA 20151-1125 363 USA 365 Phone: +1 703 227 9845 366 Email: jcurran@arin.net 368 Geoff Huston 369 Asia Pacific Network Information Centre (APNIC) 370 6 Cordelia St 371 South Brisbane, QLD 4101 372 Australia 374 Phone: +61 7 3858 3100 375 Email: gih@apnic.net 377 David Conrad 378 Virtualized, LLC 379 2310 Homestead Road, C1#240 380 Los Altos, CA 94024 381 USA 383 Phone: +1-650-397-6102 384 Email: drc@virtualized.org