idnits 2.17.1 draft-housley-rfc2050bis-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 : ---------------------------------------------------------------------------- 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 (June 30, 2013) is 3951 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 4 Obsoletes: 2050 (if approved) J. Curran 5 Intended status: Informational ARIN 6 Expires: January 01, 2014 G. Huston 7 APNIC 8 D. Conrad 9 Virtualized, LLC 10 June 30, 2013 12 The Internet Numbers Registry System 13 draft-housley-rfc2050bis-02.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 current Internet 27 Numbers Registry System. Rather it documents the Internet Numbers 28 Registry System as it works today. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 01, 2014. 47 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. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Internet Numbers Registry System Structure . . . . . . . . . 3 63 4. Internet Numbers Registry Technical Considerations . . . . . 5 64 5. Internet Numbers Registry Evolution . . . . . . . . . . . . . 5 65 6. Summary of Changes Since RFC 2050 . . . . . . . . . . . . . . 6 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 10.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The administrative structures of the Internet Numbers Registry System 77 described in this document are largely the result of the interaction 78 of operational practices, existing routing technology, number 79 resource assignments that have occurred over time, and network 80 architectural history. Further discussion and analysis of these 81 interactions are outside the scope of this document. 83 This document provides information about the current Internet Numbers 84 Registry System used in the distribution of globally unique Internet 85 Protocol (IP) address space and autonomous system (AS) numbers. It 86 also describes the processes used for further evolution of the 87 Internet Numbers Registry System. This document does not propose any 88 changes to the current operation of this system. 90 This document replaces RFC 2050. Since the publication of RFC 2050, 91 the Internet Numbers Registry System has changed significantly. This 92 document describes the present Internet Numbers Registry System. 94 2. Goals 96 Internet number resources are currently distributed according to the 97 following (non-exclusive) goals: 99 1) Allocation Pool Management: Due to the fixed lengths of IP 100 addresses and AS numbers, the pools from which these resources 101 are allocated are finite. As such, allocations must be made in 102 accordance with the operational needs of those running the 103 networks that make use of these number resources and by taking 104 into consideration pool limitations at the time of allocation. 106 2) Hierarchical Allocation: Given current routing technology, the 107 distribution of IP addresses in a hierarchical manner increases 108 the likelihood of continued scaling of the Internet's routing 109 system. As such, it is currently a goal to allocate IP addresses 110 in such a way that permits aggregation of these addresses into a 111 minimum number of routing announcements. However, whether IP 112 addresses are actually announced to the Internet, and the manner 113 of their advertisement into the Internet's routing system is an 114 operational consideration outside of the scope of the Internet 115 Numbers Registry System. 117 3) Registration Accuracy: A core requirement of the Internet Numbers 118 Registry System is to maintain a registry of allocations to 119 ensure uniqueness and to provide accurate registration 120 information of those allocations in order to meet a variety of 121 operational requirements. Uniqueness ensures that IP addresses 122 and AS numbers are not allocated to more than one party at the 123 same time. 125 These goals may sometimes conflict with each other or be in conflict 126 with the interests of individual end-users, Internet service 127 providers, or other number resource consumers. Careful analysis, 128 judgment, and cooperation among registry system providers and 129 consumers at all levels via community-developed policies is necessary 130 to find appropriate compromises to facilitate Internet operations. 132 3. Internet Numbers Registry System Structure 134 The Internet Registry (IR) hierarchy was established to provide for 135 the allocation of IP addresses and AS numbers with consideration to 136 the above goals. This hierarchy is rooted in the Internet Assigned 137 Numbers Authority (IANA) address allocation function, which serves a 138 set of "Regional Internet Registries" (RIRs); the RIRs then serve a 139 set of "Local Internet Registries" (LIRs) and other customers. LIRs 140 in turn serve their respective number resource consumers (which may 141 be themselves, their customers, "sub-LIRs", etc.) 142 IETF 144 The IETF specifies the underlying technical facilities and 145 constraints of Internet numbers administered by the Internet 146 Numbers Registry System. These specifications are aimed at 147 enabling and protecting the long-term viability of the Internet 148 and adjustments to those specifications are made over time as 149 circumstances warrant. The IETF has also reserved portions of the 150 Internet number spaces and identifiers for future needs. 152 IANA 154 The Internet Assigned Numbers Authority (IANA) is a role, not an 155 organization. For the Internet Numbers Registry System, the IANA 156 role manages the top of the IP address and AS number allocation 157 hierarchies. The Internet Corporation for Assigned Names and 158 Numbers (ICANN) currently fulfills the IANA role in accordance 159 with the IETF-ICANN "Memorandum of Understanding Concerning 160 Technical Work of the Internet Assigned Numbers Authority", which 161 was signed and ratified in March 2000 [RFC2860]. In addition, 162 ICANN performs the IANA services related to the IP address space 163 and AS numbers according to global number resource policies that 164 have been developed by the community and formalized under a 165 Memorandum of Understanding between ICANN and the Regional 166 Internet Registries [ASOMOU] and documented in [ICANNv4], 167 [ICANNv6], and [ICANNASN]. 169 Regional IRs 171 In order to promote distribution of the Internet number resource 172 registration function, RFC 1366 proposed delegating responsibility 173 to regional bodies. These bodies became known as the Regional 174 Internet Registries (RIRs). The RIRs operate in continent-sized 175 geopolitical regions. Currently there are five RIRs: AfriNIC 176 serving Africa, APNIC serving parts of Asia and the Pacific 177 region, ARIN serving North America and parts of the Caribbean, 178 LACNIC serving Latin America and parts of the Caribbean, and RIPE 179 NCC serving Europe, parts of Asia and the Middle East. The RIRs 180 were established in a bottom-up fashion via a global policy 181 process that has been documented as the ICANN "Internet Consensus 182 Policy 2" [ICP-2], which details the principles and criteria for 183 establishment of Regional Internet Registries. The RIRs also 184 conduct regional number policy development used in the 185 administration of their number resources for which they are 186 responsible. 188 Local IRs 190 Local Internet Registries (LIRs) are established through a 191 relationship with the body from which they received their 192 addresses, typically the RIR that serves the region in which they 193 operate, a parent LIR, or other numbers allocating entity. In 194 cases where LIRs span multiple regions those LIRs have established 195 relationships with multiple RIRs. LIRs perform IP address 196 allocation services for their Customers, typically ISPs, end 197 users, or "child" or "sub-" LIRs. 199 4. Internet Numbers Registry Technical Considerations 201 As a result of the system of technical standards and guidelines 202 established by the IETF as well as historical and operational 203 constraints, there have been technical considerations regarding the 204 services provided by the Internet Numbers Registry System as it 205 evolved. These technical considerations have included: 207 1) Reverse DNS: In situations where reverse DNS was used, the 208 policies and practices of the Internet Numbers Registry System 209 have included consideration of the technical and operational 210 requirements posed by reverse DNS zone delegation [RFC5855]. 212 2) Public WHOIS: The policies and practices of the Internet Numbers 213 Registry System have included consideration of the technical and 214 operational requirements for supporting WHOIS services 215 [RFC3013][RFC3912]. 217 As the Internet and the Internet Numbers Registry System continue to 218 evolve, it may be necessary for the Internet community to examine 219 these and related technical and operational considerations and how 220 best to meet them. This evolution is discussed in the next section. 222 5. Internet Numbers Registry Evolution 224 Over the years, the Internet Numbers Registry System has developed 225 mechanisms by which the structures, policies, and processes of the 226 Internet Numbers Registry System itself can evolve to meet the 227 changing demands of the global Internet community. Further evolution 228 of the Internet Numbers Registry System is expected to occur in an 229 open, transparent, and broad multi-stakeholder manner. 231 Per the delineation of responsibility for Internet address policy 232 issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions 233 regarding the evolution of the Internet Numbers Registry System 234 structure, policy, and processes are to take place within the ICANN 235 framework and will respect ICANN's core values [ICANNBL]. These core 236 values encourage broad, informed participation reflecting the 237 functional, geographic, and cultural diversity of the Internet at all 238 levels of policy development and decision-making, as well as the 239 delegation of coordination functions and recognition of the policy 240 roles of other responsible entities that reflect the interests of 241 affected parties. The discussions regarding Internet Numbers 242 Registry evolution must also continue to consider the overall 243 Internet address architecture and technical goals referenced in this 244 document. 246 The foregoing does not alter the IETF's continued responsibility for 247 the non-policy aspects of Internet addressing such as the 248 architectural definition of IP address and AS number spaces and 249 specification of associated technical goals and constraints in their 250 application, assignment of specialized address blocks, and 251 experimental technical assignments as documented in RFC 2860. In 252 addition, in the cases where the IETF sets technical recommendations 253 for protocols, practices, or services which are directly related to 254 IP address space or AS numbers, such recommendations must be taken 255 into consideration in Internet Numbers Registry System policy 256 discussions regardless of venue. 258 6. Summary of Changes Since RFC 2050 260 Since RFC 2050 was published, the Internet and the Internet Numbers 261 Registry System have undergone significant change. This document 262 describes the Internet Numbers Registry System as it presently exists 263 and omits policy and operational procedures that have been superseded 264 by ICANN and RIR policy since RFC 2050 publication. 266 One particular change of note, RFC 2050 defined an appeal process and 267 included: 269 If necessary, after exhausting all other avenues, the appeal may 270 be forwarded to IANA for a final decision. Each registry must, as 271 part of their policy, document and specify how to appeal a 272 registry assignment decision. 274 The RIRs have developed consensus-based policies for appeals, and 275 over time, they have become accepted by the respective RIR 276 communities. As a result, the ability to further appeal to IANA is 277 no longer appropriate. 279 7. Security Considerations 281 It is generally recognized that accuracy and public availability of 282 Internet registry data is often an essential component in researching 283 and resolving security and operational issues on the Internet. 285 8. IANA Considerations 287 No updates to the registries are suggested by this document. 289 [RFC Editor: Please remove this section prior to publication.] 291 9. Acknowledgements 293 Several people have made comments on draft versions of this document. 294 The authors would like to thank Randy Bush, Brian Carpenter, Daniel 295 Karrenberg, Olaf Kolkman, Scott Bradner, Leslie Daigle, Adiel 296 Akplogan, Mark Kosters, Elise Gerich, and SM for their constructive 297 feedback and comments. Additionally, we are indebted to the authors 298 of RFC 1466 and RFC 2050 for their earlier contributions in this 299 area. 301 10. References 303 10.1. Normative References 305 [ASOMOU] Published by ICANN, "ICANN Address Supporting Organization 306 (ASO) MoU", October 2004. 308 http://archive.icann.org/en/aso/aso-mou-29oct04.htm 310 [ICANNASN] 311 Ratified by ICANN, "Internet Assigned Numbers Authority 312 (IANA) Policy for Allocation of ASN Blocks to Regional 313 Internet Registries", September 2010. 315 http://www.icann.org/en/resources/policy/global-addressing 316 /global-policy-asn-blocks-21sep10-en.htm 318 [ICANNBL] ICANN, "Bylaws for Internet Corporation for Assigned Names 319 and Numbers", December 2012. 321 http://www.icann.org/en/about/governance/bylaws 323 [ICANNv4] Ratified by ICANN, "Global Policy for Post Exhaustion IPv4 324 Allocation Mechanisms by the IANA", May 2012. 326 http://www.icann.org/en/resources/policy/global-addressing 327 /allocation-ipv4-post-exhaustion 329 [ICANNv6] Ratified by ICANN, "Internet Assigned Numbers Authority 330 (IANA) Policy For Allocation of IPv6 Blocks to Regional 331 Internet Registries", September 2006. 333 http://www.icann.org/en/resources/policy/global-addressing 334 /allocation-ipv6-rirs 336 [ICP-2] Published by ICANN, "ICP-2: Criteria for Establishment of 337 New Regional Internet Registries", July 2001. 339 http://www.icann.org/icp/icp-2.htm 341 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 342 Understanding Concerning the Technical Work of the 343 Internet Assigned Numbers Authority", RFC 2860, June 2000. 345 [RFC3013] Killalea, T., "Recommended Internet Service Provider 346 Security Services and Procedures", BCP 46, RFC 3013, 347 November 2000. 349 10.2. Informative References 351 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 352 September 2004. 354 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 355 Reverse Zones", BCP 155, RFC 5855, May 2010. 357 Authors' Addresses 359 Russ Housley 360 Vigil Security, LLC 361 918 Spring Knoll Drive 362 Herndon, VA 20170 363 USA 365 Phone: +1 703 435 1775 366 Email: housley@vigilsec.com 367 John Curran 368 American Registry for Internet Numbers (ARIN) 369 3635 Concorde Parkway 370 Chantilly, VA 20151-1125 371 USA 373 Phone: +1 703 227 9845 374 Email: jcurran@arin.net 376 Geoff Huston 377 Asia Pacific Network Information Centre (APNIC) 378 6 Cordelia St 379 South Brisbane, QLD 4101 380 Australia 382 Phone: +61 7 3858 3100 383 Email: gih@apnic.net 385 David Conrad 386 Virtualized, LLC 387 2310 Homestead Road, C1#204 388 Los Altos, CA 94024 389 USA 391 Phone: +1 650 397 6102 392 Email: drc@virtualized.org