Network Working Group R. Housley Internet-Draft Vigil Security, LLC Obsoletes: 2050 (if approved) J. Curran Intended status: Informational ARIN Expires:August 31,October 08, 2013 G. Huston APNIC D. Conrad Virtualized, LLCMarchApril 8, 2013 The Internet Numbers Registry Systemdraft-housley-rfc2050bis-00.txtdraft-housley-rfc2050bis-01.txt Abstract This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. This document also provides information about the processes for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. This document does not propose any changes to the Internet Numbers Registry System. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onAugust 31,October 08, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introductionand Goals. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Internet Numbers Registry System Structure . . . . . . . . . . 33.4. Internet Numbers Registry Technical Considerations . . . . . . 44.5. Internet Numbers Registry Evolution . . . . . . . . . . . . .4 5.5 6. Summary of Changes Since RFC 2050 . . . . . . . . . . . . . . 56.7. Security Considerations . . . . . . . . . . . . . . . . . . .5 7.6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . .5 8.6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69.10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69.1.10.1. Normative References . . . . . . . . . . . . . . . . . ..69.2.10.2. Informative References . . . . . . . . . . . . . . . . ..7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .87 1. Introductionand GoalsThe administrative structures of the Internet Numbers Registry System described in this document are largely the result of the interaction of operational practices, existing routing technology, number resource assignments that have occurred over time, and network architectural history. Further discussion and analysis of these interactions are outside the scope of this document. This document does not propose any changes to the Internet Numbers Registry System, but it does provide information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers, while also providing for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly. This document describes the present Internet Numbers Registry System. 2. Goals Internet number resources are currently distributed according to the following (non-exclusive) goals: 1) Allocation Pool Management: Due to the fixed lengths of IP addresses and AS numbers, the pools from which these resources are allocated are finite. As such, allocations must be made in accordance with the operational needs of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation. 2) Hierarchical Allocation: Given current routing technology, the distribution of IP addresses in a hierarchical manner increases the likelihood of continued scaling of the Internet's routing system. As such, it is a goal to allocate IP addresses in such a way that permits these addresses aggregated into a minimum number of routing announcements. However, whether IP addresses are actually announced to the Internet, and the manner of their advertisement into the Internet's routing system is an operational consideration outside of the scope of the Internet Numbers Registry System. 3) Registration Accuracy: A core requirement of the Internet Numbers Registry System is to maintain a registry of allocations to ensure uniqueness and to provide accurate registration information of those allocations in order to meet a variety of operational requirements. These goals may sometimes conflict with each other or be in conflict with the interests of individual end-users, Internet service providers, or other number resource consumers. Careful analysis, judgment, and cooperation among registry system providers and consumers at all levels via community-developed policies is necessary to find appropriate compromises to facilitate Internet operations.2.3. Internet Numbers Registry System Structure The Internet Registry (IR) hierarchy was established to provide for the allocation of IP addresses and AS numbers with consideration to the above goals. This hierarchy is rooted in the Internet Assigned Numbers Authority (IANA) address allocation function, which serves a set of "Regional Internet Registries" (RIRs); the RIRs then serve a set of "Local Internet Registries" (LIRs) and other customers. LIRs in turn serve their respective number resource consumers (which may be themselves, their customers, "sub-LIRs", etc.) IANA The Internet Assigned Numbers Authority (IANA) is a role, not an organization. The IANA role manages thetraditional name fortop of thetechnical team makingIP address andpublishing the assignments of Internet protocol technical parameters, includingAS number allocation hierarchies. The InternetProtocol (IP) address space. As a result of a Memorandum of Understanding (MOU)[RFC2860] between the IETF, IAB,Corporation for Assigned Names andICANN,Numbers (ICANN) currently fulfills thetechnical workIANA role in accordance with the IETF-ICANN "Memorandum of Understanding Concerning Technical Work of the Internet Assigned NumbersAuthority (IANA) is now performed by ICANN. Today,Authority", which was signed and ratified in March 2000 [RFC2860]. In addition, ICANN performs the IANAadministersservices related to the IP address space and AS numbers according to global number resource policiesasthat have been developedperby theagreementcommunity and formalized under a Memorandum of Understanding between ICANN and the Regional Internet Registries [ASOMOU] and documented in [ICANNv4], [ICANNv6], and [ICANNASN]. Regional IRs In order to promote distribution of the Internet number resource registration function, RFC 1366 proposed delegating responsibility to regional bodies. These bodies became known as the Regional Internet Registries (RIRs). The RIRs operate in continent-sized geopolitical regions. Currently there are five RIRs: AfriNIC serving Africa, APNIC serving parts of Asia and the Pacific region, ARIN serving North America and parts of the Caribbean, LACNIC serving Latin America and parts of the Caribbean, and RIPE NCC serving Europe, parts of Asia and the Middle East. The RIRs were established in a bottom-up fashion via a global policy process that has been documented as the ICANN "Internet Consensus Policy 2" [ICP-2], which details the principles and criteria for establishment of Regional Internet Registries. The RIRs also conduct regional number policy development used in the administration of their numberresources.resources for which they are responsible. Local IRs Local Internet Registries (LIRs) are established through a relationship with the body from which they received their addresses, typically the RIR that serves the region in which they operate, a parent LIR, or other numbers allocating entity. In cases where LIRsthatspan multiple regionsmay establishthose LIRs have established relationships with multiple RIRs. LIRstypicallyperform IP address allocation services for theircustomers such asCustomers, typically ISPs, end users, orother"child" or "sub-" LIRs.3.4. Internet Numbers Registry Technical Considerations As a result of the system of technical standards and guidelines established by the IETF as well as historical and operational constraints, there have been technical considerations regarding the services provided by the Internet Numbers Registry System as it evolved. These technical considerations have included: 1) Reverse DNS: In situations where reverse DNS was used, the policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements posed by reverse DNS zone delegation[RFC3172].[RFC5855]. 2) Public WHOIS: The policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements for supporting WHOIS services[RFC3013].[RFC3013][RFC3912]. As the Internet and the Internet Numbers Registry System continue to evolve, it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them.4.This evolution is discussed in the next section. 5. Internet Numbers Registry Evolution Over the years, the Internet Numbers Registry System has developed mechanisms by which the structures, policies, and processes of the Internet Numbers Registry System itself can evolve to meet the changing demands of the global Internet community. Further evolution of the Internet Numbers Registry System is expected to occur in an open, transparent, and broad multi-stakeholder manner. Per the delineation of responsibility for Internet address policy issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]. These core values encourage broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making, as well as the delegation of coordination functions and recognition of the policy roles of other responsible entities that reflect the interests of affected parties. The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. The foregoing does not alter the IETF's continued responsibility for the non-policy aspects of Internet addressing such as the architectural definition of IP address and AS number spaces and specification of associated technical goals and constraints in their application, assignment of specialized address blocks, and experimental technical assignments as documented in RFC 2860. In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue.5.6. Summary of Changes Since RFC 2050 Since RFC 2050 was published, the Internet and the Internet Numbers Registry System have undergone significant change. This document describes the Internet Numbers Registry System as it presently exists and omits policy and operational procedures that have been superseded by ICANN and RIR policy since RFC 2050 publication.6.7. Security Considerations It is generally recognized that accuracy and public availability of Internet registry data is often an essential component in researching and resolving security and operational issues on the Internet.7.8. IANA ConsiderationsThe IANA will continueNo updates toprovide the root oftheIP address and autonomous system number hierarchies and will maintain a registry that provides registration information for any allocations maderegistries are suggested bythe IANA. 8.this document. [RFC Editor: Please remove this section prior to publication.] 9. Acknowledgements Several people have made comments on draft versions of this document. The authors would like to thank Randy Bush, Brian Carpenter, Daniel Karrenberg, Olaf Kolkman, Scott Bradner, LeslieDaigle andDaigle, AdielAkploganAkplogan, Mark Kosters, Elise Gerich, and SM for their constructive feedback and comments. Additionally, we are indebted to the authors of RFC 1466 and RFC 2050 for their earlier contributions in this area.9.10. References9.1.10.1. Normative References [ASOMOU] Published by ICANN, "ICANN Address Supporting Organization (ASO) MoU", October 2004. http://archive.icann.org/en/aso/aso-mou-29oct04.htm [ICANNASN] Ratified by ICANN, "Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries", September 2010. http://www.icann.org/en/resources/policy/global-addressing /global-policy-asn-blocks-21sep10-en.htm [ICANNBL] ICANN, "Bylaws for Internet Corporation for Assigned Names and Numbers", December 2012. http://www.icann.org/en/about/governance/bylaws [ICANNv4] Ratified by ICANN, "Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA", May 2012. http://www.icann.org/en/resources/policy/global-addressing /allocation-ipv4-post-exhaustion [ICANNv6] Ratified by ICANN, "Internet Assigned Numbers Authority (IANA) Policy For Allocation of IPv6 Blocks to Regional Internet Registries", September 2006. http://www.icann.org/en/resources/policy/global-addressing /allocation-ipv6-rirs [ICP-2] Published by ICANN, "ICP-2: Criteria for Establishment of New Regional Internet Registries", July 2001. http://www.icann.org/icp/icp-2.htm [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.[RFC3172] Huston, G., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, September 2001. [RFC6484] Kent, S., Kong, D., Seo, K. and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012. 9.2.10.2. Informative References[RFC1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, May 1993. [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993. [RFC1814] Gerich, E., "Unique Addresses are Good", RFC 1814, June 1995. [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", BCP 12, RFC 2050, November 1996. [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. [RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, June 1998. [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001. [RFC3707] Newton, A., "Cross Registry Internet Service[RFC3912] Daigle, L., "WHOIS Protocol(CRISP) Requirements",Specification", RFC3707, February3912, September 2004.[RFC4632] Fuller, V.[RFC5855] Abley, J. and T.Li, "Classless Inter-domain Routing (CIDR): The Internet Address AssignmentManderson, "Nameservers for IPv4 andAggregation Plan",IPv6 Reverse Zones", BCP122,155, RFC4632, August 2006.5855, May 2010. Authors' Addresses Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA Phone: +1 703 435 1775 Email: housley@vigilsec.com John Curran American Registry for Internet Numbers (ARIN) 3635 Concorde Parkway Chantilly, VA 20151-1125 USA Phone: +1 703 227 9845 Email: jcurran@arin.net Geoff Huston Asia Pacific Network Information Centre (APNIC) 6 Cordelia St South Brisbane, QLD 4101 Australia Phone: +61 7 3858 3100 Email: gih@apnic.net David Conrad Virtualized, LLC 2310 Homestead Road,C1#240C1#204 Los Altos, CA 94024 USA Phone:+1-650-397-6102+1 650 397 6102 Email: drc@virtualized.org