summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7020.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7020.txt')
-rw-r--r--doc/rfc/rfc7020.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc7020.txt b/doc/rfc/rfc7020.txt
new file mode 100644
index 0000000..26aa288
--- /dev/null
+++ b/doc/rfc/rfc7020.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Housley
+Request for Comments: 7020 Vigil Security
+Obsoletes: 2050 J. Curran
+Category: Informational ARIN
+ISSN: 2070-1721 G. Huston
+ APNIC
+ D. Conrad
+ Virtualized, LLC
+ August 2013
+
+
+ The Internet Numbers Registry System
+
+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 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; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7020.
+
+
+
+
+
+
+
+
+Housley, et al. Informational [Page 1]
+
+RFC 7020 Internet Registry System August 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. 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 Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Internet Numbers Registry System Structure . . . . . . . . . . 3
+ 4. Internet Numbers Registry Technical Considerations . . . . . . 5
+ 5. Internet Numbers Registry Evolution . . . . . . . . . . . . . . 5
+ 6. Summary of Changes since RFC 2050 . . . . . . . . . . . . . . . 6
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
+
+1. 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 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.
+
+
+
+Housley, et al. Informational [Page 2]
+
+RFC 7020 Internet Registry System August 2013
+
+
+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 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 by RFC 1466,
+ which was replaced by RFC 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 core
+
+
+
+Housley, 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 in RFC 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 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 the publication of RFC 2050.
+
+ One particular change of note is that RFC 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 2013
+
+
+8. 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
+ of RFC 1466 and RFC 2050 for their earlier contributions in this
+ area.
+
+9. References
+
+9.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 2013
+
+
+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#204
+ Los Altos, CA 94024
+ USA
+
+ Phone: +1 650 397 6102
+ EMail: drc@virtualized.org
+
+
+
+
+
+
+
+
+
+
+
+Housley, et al. Informational [Page 9]
+