Movatterモバイル変換

Internet Engineering Task Force (IETF)                        R. HousleyRequest for Comments: 7020                                Vigil SecurityObsoletes:2050                                                J. CurranCategory: Informational                                             ARINISSN: 2070-1721                                                G. Huston                                                                   APNIC                                                               D. Conrad                                                        Virtualized, LLC                                                             August 2013The Internet Numbers Registry SystemAbstract   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 replacesRFC 2050.   This document does not propose any changes to the current Internet   Numbers Registry System.  Rather, it documents the Internet Numbers   Registry System as it works today.Status of This Memo   This document is not an Internet Standards Track specification; it is   published for informational purposes.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Not all documents   approved by the IESG are a candidate for any level of Internet   Standard; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7020.Housley, et al.               Informational                     [Page 1]

RFC 7020                Internet Registry System             August 2013Copyright Notice   Copyright (c) 2013 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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.  Code Components extracted from this document must   include Simplified BSD License text as described in Section 4.e of   the Trust Legal Provisions and are provided without warranty as   described in the Simplified BSD License.Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .22.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33.  Internet Numbers Registry System Structure  . . . . . . . . . .34.  Internet Numbers Registry Technical Considerations  . . . . . .55.  Internet Numbers Registry Evolution . . . . . . . . . . . . . .56.  Summary of Changes sinceRFC 2050 . . . . . . . . . . . . . . .67.  Security Considerations . . . . . . . . . . . . . . . . . . . .68.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .79.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .79.1.  Normative References  . . . . . . . . . . . . . . . . . . .79.2.  Informative References  . . . . . . . . . . . . . . . . . .81.  Introduction   The 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 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.  It   also describes the processes used for further evolution of the   Internet Numbers Registry System.  This document does not propose any   changes to the current operation of this system.   This document replacesRFC 2050.  Since the publication ofRFC 2050,   the Internet Numbers Registry System has changed significantly.  This   document describes the present Internet Numbers Registry System.Housley, et al.               Informational                     [Page 2]

RFC 7020                Internet Registry System             August 20132.  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 currently a goal to allocate IP addresses       in such a way that permits aggregation of these addresses 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 are       operational considerations outside 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.  Uniqueness ensures that IP addresses       and AS numbers are not allocated to more than one party at the       same time.   These goals may sometimes conflict with each other or 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 are necessary to find   appropriate compromises to facilitate Internet operations.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.)Housley, et al.               Informational                     [Page 3]

RFC 7020                Internet Registry System             August 2013   IETF      The IETF specifies the underlying technical facilities and      constraints of Internet numbers administered by the Internet      Numbers Registry System.  These specifications are aimed at      enabling and protecting the long-term viability of the Internet,      and adjustments to those specifications are made over time as      circumstances warrant.  The IETF has also reserved portions of the      Internet number spaces and identifiers for future needs.   IANA      The Internet Assigned Numbers Authority (IANA) is a role, not an      organization.  For the Internet Numbers Registry System, the IANA      role manages the top of the IP address and AS number allocation      hierarchies.  The Internet Corporation for Assigned Names and      Numbers (ICANN) currently fulfills the IANA role in accordance      with the IETF-ICANN "Memorandum of Understanding Concerning      Technical Work of the Internet Assigned Numbers Authority", which      was signed and ratified in March 2000 [RFC2860].  In addition,      ICANN performs the IANA services related to the IP address space      and AS numbers according to global number resource policies that      have been developed by the community 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.  (Note:RFC 1366 was replaced byRFC 1466,      which was replaced byRFC 2050.)  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 the number resources for      which they are responsible.Housley, et al.               Informational                     [Page 4]

RFC 7020                Internet Registry System             August 2013   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 number-allocating entity.  In      cases where LIRs span multiple regions, those LIRs have      established relationships with multiple RIRs.  LIRs perform IP      address allocation services for their customers, typically ISPs,      end users, or child LIRs (also known as "sub-LIRs").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 [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]       [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.  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 coreHousley, et al.               Informational                     [Page 5]

RFC 7020                Internet Registry System             August 2013   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 inRFC 2860.  In   addition, in the cases where the IETF sets technical recommendations   for protocols, practices, or services that 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.6.  Summary of Changes sinceRFC 2050   SinceRFC 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 the publication ofRFC 2050.   One particular change of note is thatRFC 2050 defined an appeal   process and included:      If necessary, after exhausting all other avenues, the appeal may      be forwarded to IANA for a final decision.  Each registry must, as      part of their policy, document and specify how to appeal a      registry assignment decision.   The RIRs have developed consensus-based policies for appeals, and   over time, they have become accepted by the respective RIR   communities.  As a result, the ability to further appeal to IANA is   no longer appropriate.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.Housley, et al.               Informational                     [Page 6]

RFC 7020                Internet Registry System             August 20138.  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, Leslie Daigle, Adiel   Akplogan, Mark Kosters, Elise Gerich, and SM for their constructive   feedback and comments.  Additionally, we are indebted to the authors   ofRFC 1466 andRFC 2050 for their earlier contributions in this   area.9.  References9.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]    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.Housley, et al.               Informational                     [Page 7]

RFC 7020                Internet Registry System             August 2013   [RFC3013]  Killalea, T., "Recommended Internet Service Provider              Security Services and Procedures",BCP 46,RFC 3013,              November 2000.9.2.  Informative References   [RFC3912]  Daigle, L., "WHOIS Protocol Specification",RFC 3912,               September 2004.   [RFC5855]  Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6               Reverse Zones",BCP 155,RFC 5855, May 2010.Housley, et al.               Informational                     [Page 8]

RFC 7020                Internet Registry System             August 2013Authors' 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#204   Los Altos, CA  94024   USA   Phone: +1 650 397 6102   EMail: drc@virtualized.orgHousley, et al.               Informational                     [Page 9]