The Internet Numbers Registry System
How IP addresses and AS numbers are allocated and managed globally.
Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, August 2013, <https://www.rfc-editor.org/info/rfc7020>.
@misc{rfc7020,
series = {Request for Comments},
number = 7020,
howpublished = {RFC 7020},
publisher = {RFC Editor},
doi = {10.17487/RFC7020},
url = {https://www.rfc-editor.org/info/rfc7020},
author = {R. Housley and J. Curran and G. Huston and D. Conrad},
title = {{The Internet Numbers Registry System}},
pagetotal = 9,
year = 2013,
month = aug,
} RFC text
Contents
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.
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.
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.)
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.
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
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.
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.
[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.
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
AI ELI5
On this page
§1The Address Allocation System
Every computer and network on the Internet needs a unique identifier. The Internet Numbers Registry System is the framework that assigns and tracks globally unique IP addresses and Autonomous System (AS) numbers.
RFC 7020 describes how this system works today, documenting it for future reference. It replaces RFC 2050 (which was issued in 1996) and reflects the significant changes that have occurred in the registry system since then. The RFC does not propose changes to the system; it simply describes the current state.
Every internet address and network number needs to be different so networks can find each other. This document explains who hands these out and how they do it.
§2Three Goals of the System
The Internet Numbers Registry System operates under three guiding goals:
Allocation Pool Management: Since IP addresses and AS numbers have fixed-length formats, the pools of available numbers are finite. Allocations must be made carefully to meet current operational needs while respecting future limitations.
Hierarchical Allocation: IP addresses are distributed hierarchically to support Internet routing aggregation. This hierarchical structure helps the routing system scale as the Internet grows.
Registration Accuracy: The registry system must maintain accurate records of all allocations to ensure uniqueness (no two parties get the same number) and to provide reliable information for operational requirements such as reverse DNS and WHOIS lookups.
These goals sometimes conflict with each other or with the interests of specific users and providers. Resolving these conflicts requires careful analysis and cooperation among all participants via community-developed policies.
Three rules guide the system: there are only so many numbers, so use them wisely; organize them in a tree so routing works well; and keep honest records so nobody gets the same number twice.
§3The Registry Hierarchy
The Internet Numbers Registry System is structured as a four-level hierarchy:
IETF: Sets the technical standards and specifications for IP addresses and AS numbers. The IETF also reserves portions of number space for future use and special purposes.
IANA: The Internet Assigned Numbers Authority, currently operated by ICANN, manages the top of the allocation hierarchy. IANA receives allocations and distributes them to Regional Internet Registries. IANA also develops allocation policies in coordination with the RIRs.
Regional Internet Registries (RIRs): Five continent-sized organizations that receive allocations from IANA and distribute them within their regions. Current RIRs are AfriNIC (Africa), APNIC (Asia-Pacific), ARIN (North America and Caribbean), LACNIC (Latin America and Caribbean), and RIPE NCC (Europe, Middle East, parts of Asia).
Local Internet Registries (LIRs): Organizations that receive allocations from RIRs (or parent LIRs) and distribute them to their customers, which may include ISPs, end users, or sub-LIRs.
IETF says what kind of numbers we need. IANA has the master pile at the top. Five regional offices split it up by continent. Then local offices in each region hand them out to the ISPs and other customers.
§4Technical Considerations
The registry system's operation is shaped by technical and operational requirements:
Reverse DNS: The registry system coordinates with the reverse DNS zone delegation process (managed by IANA) to ensure that network operators can properly set up reverse lookups for their address space.
WHOIS: Public WHOIS services allow network operators, security analysts, and others to query registry data about address allocations and their operators. The registry system maintains WHOIS as a key operational tool.
As the Internet and the registry system continue to evolve, the community examines these technical requirements and considers how to best meet them in the future.
Two important tools depend on the registry system: reverse DNS (so emails have the right sender information) and WHOIS (so people can find out who runs a network).
§5Future Evolution
The Internet Numbers Registry System is designed to evolve as the Internet community's needs change. Evolution happens through an open, transparent, multi-stakeholder process that respects the ICANN framework and core values.
Per the IETF/IAB/ICANN Memorandum of Understanding, discussions about the structure, policy, and processes of the registry system take place within the ICANN framework. These discussions must continue to consider the overall Internet address architecture and the technical goals of the registry system.
The IETF retains responsibility for non-policy aspects of Internet addressing, such as the architectural definition of address and AS number spaces and the technical goals and constraints associated with them. This division of responsibility allows technical standards development and address policy development to proceed in appropriate forums.
The system changes as needed, but only through agreement by many people. The IETF handles the technical parts, while the ICANN community handles the policies about who gets what.