idnits 2.17.00 (12 Aug 2021) /tmp/idnits36213/draft-housley-rfc2050bis-01.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 (April 8, 2013) is 3330 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: October 08, 2013 G. Huston 7 APNIC 8 D. Conrad 9 Virtualized, LLC 10 April 8, 2013 12 The Internet Numbers Registry System 13 draft-housley-rfc2050bis-01.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 October 08, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Internet Numbers Registry System Structure . . . . . . . . . . 3 62 4. Internet Numbers Registry Technical Considerations . . . . . . 4 63 5. Internet Numbers Registry Evolution . . . . . . . . . . . . . 5 64 6. Summary of Changes Since RFC 2050 . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 10.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The administrative structures of the Internet Numbers Registry System 76 described in this document are largely the result of the interaction 77 of operational practices, existing routing technology, number 78 resource assignments that have occurred over time, and network 79 architectural history. Further discussion and analysis of these 80 interactions are outside the scope of this document. 82 This document does not propose any changes to the Internet Numbers 83 Registry System, but it does provide information about the current 84 Internet Numbers Registry System used in the distribution of globally 85 unique Internet Protocol (IP) address space and autonomous system 86 (AS) numbers, while also providing for further evolution of the 87 Internet Numbers Registry System. 89 This document replaces RFC 2050. Since the publication of RFC 2050, 90 the Internet Numbers Registry System has changed significantly. This 91 document describes the present Internet Numbers Registry System. 93 2. Goals 95 Internet number resources are currently distributed according to the 96 following (non-exclusive) goals: 98 1) Allocation Pool Management: Due to the fixed lengths of IP 99 addresses and AS numbers, the pools from which these resources 100 are allocated are finite. As such, allocations must be made 101 in accordance with the operational needs of those running the 102 networks that make use of these number resources and by taking 103 into consideration pool limitations at the time of allocation. 105 2) Hierarchical Allocation: Given current routing technology, the 106 distribution of IP addresses in a hierarchical manner 107 increases the likelihood of continued scaling of the 108 Internet's routing system. As such, it is a goal to allocate 109 IP addresses in such a way that permits these addresses 110 aggregated into a minimum number of routing announcements. 111 However, whether IP addresses are actually announced to the 112 Internet, and the manner of their advertisement into the 113 Internet's routing system is an operational consideration 114 outside of the scope of the Internet Numbers Registry System. 116 3) Registration Accuracy: A core requirement of the Internet 117 Numbers Registry System is to maintain a registry of 118 allocations to ensure uniqueness and to provide accurate 119 registration information of those allocations in order to meet 120 a variety of operational requirements. 122 These goals may sometimes conflict with each other or be in conflict 123 with the interests of individual end-users, Internet service 124 providers, or other number resource consumers. Careful analysis, 125 judgment, and cooperation among registry system providers and 126 consumers at all levels via community-developed policies is necessary 127 to find appropriate compromises to facilitate Internet operations. 129 3. Internet Numbers Registry System Structure 131 The Internet Registry (IR) hierarchy was established to provide for 132 the allocation of IP addresses and AS numbers with consideration to 133 the above goals. This hierarchy is rooted in the Internet Assigned 134 Numbers Authority (IANA) address allocation function, which serves a 135 set of "Regional Internet Registries" (RIRs); the RIRs then serve a 136 set of "Local Internet Registries" (LIRs) and other customers. LIRs 137 in turn serve their respective number resource consumers (which may 138 be themselves, their customers, "sub-LIRs", etc.) 140 IANA 141 The Internet Assigned Numbers Authority (IANA) is a role, not an 142 organization. The IANA role manages the top of the IP address and 143 AS number allocation hierarchies. The Internet Corporation for 144 Assigned Names and Numbers (ICANN) currently fulfills the IANA 145 role in accordance with the IETF-ICANN "Memorandum of 146 Understanding Concerning Technical Work of the Internet Assigned 147 Numbers Authority", which was signed and ratified in March 2000 148 [RFC2860]. In addition, ICANN performs the IANA services related 149 to the IP address space and AS numbers according to global number 150 resource policies that have been developed by the community and 151 formalized under a Memorandum of Understanding between ICANN and 152 the Regional Internet Registries [ASOMOU] and documented in 153 [ICANNv4], [ICANNv6], and [ICANNASN]. 155 Regional IRs 157 In order to promote distribution of the Internet number resource 158 registration function, RFC 1366 proposed delegating responsibility 159 to regional bodies. These bodies became known as the Regional 160 Internet Registries (RIRs). The RIRs operate in continent-sized 161 geopolitical regions. Currently there are five RIRs: AfriNIC 162 serving Africa, APNIC serving parts of Asia and the Pacific 163 region, ARIN serving North America and parts of the Caribbean, 164 LACNIC serving Latin America and parts of the Caribbean, and RIPE 165 NCC serving Europe, parts of Asia and the Middle East. The RIRs 166 were established in a bottom-up fashion via a global policy 167 process that has been documented as the ICANN "Internet Consensus 168 Policy 2" [ICP-2], which details the principles and criteria for 169 establishment of Regional Internet Registries. The RIRs also 170 conduct regional number policy development used in the 171 administration of their number resources for which they are 172 responsible. 174 Local IRs 176 Local Internet Registries (LIRs) are established through a 177 relationship with the body from which they received their 178 addresses, typically the RIR that serves the region in which they 179 operate, a parent LIR, or other numbers allocating entity. In 180 cases where LIRs span multiple regions those LIRs have established 181 relationships with multiple RIRs. LIRs perform IP address 182 allocation services for their Customers, typically ISPs, end 183 users, or "child" or "sub-" LIRs. 185 4. Internet Numbers Registry Technical Considerations 187 As a result of the system of technical standards and guidelines 188 established by the IETF as well as historical and operational 189 constraints, there have been technical considerations regarding the 190 services provided by the Internet Numbers Registry System as it 191 evolved. These technical considerations have included: 193 1) Reverse DNS: In situations where reverse DNS was used, the 194 policies and practices of the Internet Numbers Registry System 195 have included consideration of the technical and operational 196 requirements posed by reverse DNS zone delegation [RFC5855]. 198 2) Public WHOIS: The policies and practices of the Internet 199 Numbers Registry System have included consideration of the 200 technical and operational requirements for supporting WHOIS 201 services [RFC3013][RFC3912]. 203 As the Internet and the Internet Numbers Registry System continue to 204 evolve, it may be necessary for the Internet community to examine 205 these and related technical and operational considerations and how 206 best to meet them. This evolution is discussed in the next section. 208 5. Internet Numbers Registry Evolution 210 Over the years, the Internet Numbers Registry System has developed 211 mechanisms by which the structures, policies, and processes of the 212 Internet Numbers Registry System itself can evolve to meet the 213 changing demands of the global Internet community. Further evolution 214 of the Internet Numbers Registry System is expected to occur in an 215 open, transparent, and broad multi-stakeholder manner. 217 Per the delineation of responsibility for Internet address policy 218 issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions 219 regarding the evolution of the Internet Numbers Registry System 220 structure, policy, and processes are to take place within the ICANN 221 framework and will respect ICANN's core values [ICANNBL]. These core 222 values encourage broad, informed participation reflecting the 223 functional, geographic, and cultural diversity of the Internet at all 224 levels of policy development and decision-making, as well as the 225 delegation of coordination functions and recognition of the policy 226 roles of other responsible entities that reflect the interests of 227 affected parties. The discussions regarding Internet Numbers 228 Registry evolution must also continue to consider the overall 229 Internet address architecture and technical goals referenced in this 230 document. 232 The foregoing does not alter the IETF's continued responsibility for 233 the non-policy aspects of Internet addressing such as the 234 architectural definition of IP address and AS number spaces and 235 specification of associated technical goals and constraints in their 236 application, assignment of specialized address blocks, and 237 experimental technical assignments as documented in RFC 2860. In 238 addition, in the cases where the IETF sets technical recommendations 239 for protocols, practices, or services which are directly related to 240 IP address space or AS numbers, such recommendations must be taken 241 into consideration in Internet Numbers Registry System policy 242 discussions regardless of venue. 244 6. Summary of Changes Since RFC 2050 245 Since RFC 2050 was published, the Internet and the Internet Numbers 246 Registry System have undergone significant change. This document 247 describes the Internet Numbers Registry System as it presently exists 248 and omits policy and operational procedures that have been superseded 249 by ICANN and RIR policy since RFC 2050 publication. 251 7. Security Considerations 253 It is generally recognized that accuracy and public availability of 254 Internet registry data is often an essential component in researching 255 and resolving security and operational issues on the Internet. 257 8. IANA Considerations 259 No updates to the registries are suggested by this document. 261 [RFC Editor: Please remove this section prior to publication.] 263 9. Acknowledgements 265 Several people have made comments on draft versions of this document. 266 The authors would like to thank Randy Bush, Brian Carpenter, Daniel 267 Karrenberg, Olaf Kolkman, Scott Bradner, Leslie Daigle, Adiel 268 Akplogan, Mark Kosters, Elise Gerich, and SM for their constructive 269 feedback and comments. Additionally, we are indebted to the authors 270 of RFC 1466 and RFC 2050 for their earlier contributions in this 271 area. 273 10. References 275 10.1. Normative References 277 [ASOMOU] Published by ICANN, "ICANN Address Supporting Organization 278 (ASO) MoU", October 2004. 280 http://archive.icann.org/en/aso/aso-mou-29oct04.htm 282 [ICANNASN] 283 Ratified by ICANN, "Internet Assigned Numbers Authority 284 (IANA) Policy for Allocation of ASN Blocks to Regional 285 Internet Registries", September 2010. 287 http://www.icann.org/en/resources/policy/global-addressing 288 /global-policy-asn-blocks-21sep10-en.htm 290 [ICANNBL] ICANN, "Bylaws for Internet Corporation for Assigned Names 291 and Numbers", December 2012. 293 http://www.icann.org/en/about/governance/bylaws 295 [ICANNv4] Ratified by ICANN, "Global Policy for Post Exhaustion IPv4 296 Allocation Mechanisms by the IANA", May 2012. 298 http://www.icann.org/en/resources/policy/global-addressing 299 /allocation-ipv4-post-exhaustion 301 [ICANNv6] Ratified by ICANN, "Internet Assigned Numbers Authority 302 (IANA) Policy For Allocation of IPv6 Blocks to Regional 303 Internet Registries", September 2006. 305 http://www.icann.org/en/resources/policy/global-addressing 306 /allocation-ipv6-rirs 308 [ICP-2] Published by ICANN, "ICP-2: Criteria for Establishment of 309 New Regional Internet Registries", July 2001. 311 http://www.icann.org/icp/icp-2.htm 313 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 314 Understanding Concerning the Technical Work of the 315 Internet Assigned Numbers Authority", RFC 2860, June 2000. 317 [RFC3013] Killalea, T., "Recommended Internet Service Provider 318 Security Services and Procedures", BCP 46, RFC 3013, 319 November 2000. 321 10.2. Informative References 323 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 324 September 2004. 326 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 327 Reverse Zones", BCP 155, RFC 5855, May 2010. 329 Authors' Addresses 331 Russ Housley 332 Vigil Security, LLC 333 918 Spring Knoll Drive 334 Herndon, VA 20170 335 USA 337 Phone: +1 703 435 1775 338 Email: housley@vigilsec.com 340 John Curran 341 American Registry for Internet Numbers (ARIN) 342 3635 Concorde Parkway 343 Chantilly, VA 20151-1125 344 USA 346 Phone: +1 703 227 9845 347 Email: jcurran@arin.net 348 Geoff Huston 349 Asia Pacific Network Information Centre (APNIC) 350 6 Cordelia St 351 South Brisbane, QLD 4101 352 Australia 354 Phone: +61 7 3858 3100 355 Email: gih@apnic.net 357 David Conrad 358 Virtualized, LLC 359 2310 Homestead Road, C1#204 360 Los Altos, CA 94024 361 USA 363 Phone: +1 650 397 6102 364 Email: drc@virtualized.org