RFC 7020

RFC 7020: The Internet Numbers Registry System 🌈

Title block tea ☕ This one is Informational (so it's published for info, not as a Standards Track spec 🎀), dated August 2013, with ISSN 2070-1721. It was written by R. Housley (Vigil Security), J. Curran (ARIN), G. Huston (APNIC), and D. Conrad (Virtualized, LLC). It obsoletes RFC 2050 and doesn't update anything. 💅

Abstract ✨

Okay so this doc is basically a tour of how the Internet Numbers Registry System works right now 🦋 It covers how globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers get handed out, and it also explains how the system is allowed to keep evolving.

It replaces RFC 2050 💖 but it does NOT propose any changes. It's just documenting the vibe as it is today. 🫶

Status of This Memo 📜

Not an Internet Standards Track spec, just published for info 🌸

It's still a product of the IETF, so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not everything the IESG approves is a candidate for an Internet Standard, though. See Section 2 of RFC 5741 for that 👀

For the latest status, errata, and how to send feedback, check 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. Please read those carefully, because they spell out your rights and restrictions for this doc. 🙈 Any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. 🍓

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 admin structures of the Internet Numbers Registry System in this doc are mostly the result of a mix of operational practices, existing routing tech, number resource assignments that happened over time, and network architecture history 📚 Digging into how those things interact is outside the scope of this doc, so we're not doing that here 🙅‍♀️

This doc tells you about the current Internet Numbers Registry System, the one used to hand out globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. It also describes the processes used for further evolution of the system. It does not propose any changes to how the system currently runs 💅

Since RFC 2050 came out, the Internet Numbers Registry System has changed a lot, so this doc describes the present-day version. It's giving "new and improved" 🦋

2. Goals 🎯

Internet number resources are currently handed out according to the following goals, which aren't exclusive of each other:

1. Allocation Pool Management: Because IP addresses and AS numbers have fixed lengths, the pools they come from are finite. So allocations have to match the operational needs of the people running the networks that use these number resources, and they have to take the pool limits at the time of allocation into account 🫧
2. Hierarchical Allocation: With current routing tech, handing out IP addresses in a hierarchy makes it more likely the Internet's routing system keeps scaling. So it's currently a goal to allocate IP addresses in a way that lets them be aggregated into a minimum number of routing announcements. Whether addresses are actually announced to the Internet, and how they get advertised into the routing system, are operational considerations outside the scope of the Internet Numbers Registry System 🌊
3. Registration Accuracy: A core requirement of the system is keeping a registry of allocations, so that uniqueness is maintained and accurate registration info is available for a variety of operational needs 🗂️ Uniqueness means IP addresses and AS numbers aren't allocated to more than one party at the same time. No sharing drama here 🙅‍♀️

These goals can sometimes clash with each other, or with the interests of individual end users, Internet service providers, or other number resource consumers. It takes careful analysis, judgment, and cooperation among registry system providers and consumers at all levels, using community-developed policies, to find compromises that keep Internet operations running smoothly 🤝

3. Internet Numbers Registry System Structure 🏛️

The Internet Registry (IR) hierarchy was set up to allocate IP addresses and AS numbers while keeping the goals above in mind. It's 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 serve their own number resource consumers in turn, which may be themselves, their customers, "sub-LIRs", etc. 🌳

IETF 🧠

The IETF specifies the underlying technical facilities and constraints of the Internet numbers administered by the Internet Numbers Registry System. These specs are aimed at enabling and protecting the long-term viability of the Internet, and they get adjusted 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, so keep that in mind 💡 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 fills the IANA role under the IETF-ICANN "Memorandum of Understanding Concerning Technical Work of the Internet Assigned Numbers Authority", which was signed and ratified in March 2000 [RFC2860]. ICANN also handles the IANA services for the IP address space and AS numbers, following global number resource policies that the community developed and formalized under a Memorandum of Understanding between ICANN and the Regional Internet Registries [ASOMOU]. Those policies are documented in [ICANNv4], [ICANNv6], and [ICANNASN] 📜

Regional IRs 🌍

To spread out 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. Right now 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
• RIPE NCC serving Europe, parts of Asia, and the Middle East

The RIRs were established in a bottom-up fashion through a global policy process documented as the ICANN "Internet Consensus Policy 2" [ICP-2], which details the principles and criteria for establishing Regional Internet Registries. They also do regional number policy development for the number resources they're responsible for ✨

Local IRs 🏡

Local Internet Registries (LIRs) are set up through a relationship with the body they got their addresses from. That's typically the RIR serving their region, a parent LIR, or some other number-allocating entity. When LIRs span multiple regions, they've set up relationships with multiple RIRs. LIRs do IP address allocation for their customers, which are typically ISPs, end users, or child LIRs (also known as "sub-LIRs") 💌

4. Internet Numbers Registry Technical Considerations ⚙️

The system of technical standards and guidelines set by the IETF, plus historical and operational constraints, has led to technical considerations about the services the Internet Numbers Registry System provides, as the system evolved. These considerations have included:

1. Reverse DNS: Where reverse DNS was used, the system's policies and practices have considered the technical and operational requirements posed by reverse DNS zone delegation [RFC5855].
2. Public WHOIS: The system's policies and practices have considered the technical and operational requirements for supporting WHOIS services [RFC3013] [RFC3912].

As the Internet and the Internet Numbers Registry System keep evolving, the Internet community may need to examine these and related technical and operational considerations, and figure out how best to meet them. That evolution is discussed in the next section 🦋

5. Internet Numbers Registry Evolution ✨

Okay bestie, so the Internet Numbers Registry System has been glowing up for years 💅 its structures, policies, and processes can actually evolve to keep up with what the global Internet community needs 🌈 and that evolution is expected to happen in an open, transparent, and broad multi-stakeholder way 🫶

Here's the tea 🍵 under the IETF/IAB/ICANN MOU [RFC2860], discussions about how the Internet Numbers Registry System is structured, what its policies are, and how it runs are supposed to happen inside the ICANN framework, and they have to respect ICANN's core values [ICANNBL] 💖 those values are all about broad, informed participation that reflects how diverse the Internet is (functionally, geographically, and culturally) at every level of policy making and decision making 🌸 they also cover delegating coordination work and recognizing that other responsible entities have policy roles that reflect what affected parties care about 🦋 and the discussions about Internet Numbers Registry evolution must also keep the overall Internet address architecture and technical goals from this document in mind 🧚

Also, none of this takes away the IETF's ongoing job on the non-policy side of Internet addressing 👑 that includes defining the architecture of IP address and AS number spaces, specifying the technical goals and constraints for how they're used, assigning specialized address blocks, and making experimental technical assignments, all as documented in RFC 2860 🎀 and when the IETF sets technical recommendations for protocols, practices, or services that are directly tied to IP address space or AS numbers, those recommendations MUST be taken into consideration in Internet Numbers Registry System policy discussions no matter where those discussions happen 🔥

6. Summary of Changes since RFC 2050 💜

Ever since RFC 2050 came out, the Internet and the Internet Numbers Registry System have changed a LOT 😭 this document describes the Registry System as it exists right now, and it leaves out policy and operational procedures that ICANN and the RIRs have superseded since RFC 2050 was published 🍓

One big change: RFC 2050 defined an appeal process and included this:

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 came up with consensus-based appeal policies, and over time those policies got accepted by their own communities ✨ so appealing further to IANA is no longer appropriate 🙈

7. Security Considerations 🔐

Okay, this one's important 💀 it is generally recognized that accurate, publicly available Internet registry data is often an essential piece of researching and resolving security and operational issues on the Internet 🫶

8. Acknowledgements 🎀

Lots of people gave comments on draft versions of this document, and the authors want 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 💖 they're also grateful to the authors of RFC 1466 and RFC 2050 for their earlier work 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