RFC 2050

Internet Registry IP Allocation Guidelines

📅 published November 1996, from ietf

RFC 2050: INTERNET REGISTRY IP ALLOCATION GUIDELINES 🎀

Okay bestie, let's get into RFC 2050 💖 It's from November 1996 and it's from the Network Working Group. It's a Best Current Practice (category, plus it's BCP 12 🌸), and it obsoletes RFC 1466. The authors are K. Hubbard and M. Kosters (both InterNIC), D. Conrad (APNIC), D. Karrenberg (RIPE), and J. Postel (ISI). The whole crew 🫶

Status of this Memo

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. ✨

IESG Note:

Okay, so by approving this document as a Best Current Practice, the IESG is saying it believes the policy described here is an accurate picture of how the IP address registries are currently handling address assignment 👀 It's not an endorsement or recommendation of the policy by the IESG, though. They'll be re-checking their approval in December 1997, taking into account what gets discussed in the IRE Working Group between now and then 🧐

Abstract 🦋

This document describes the registry system for handing out globally unique Internet address space, plus registry operations. It's especially about the rules and guidelines that govern how that address space gets distributed 💅

It also covers the IP assignment policies that the Regional Registries are using right now to carry out the guidelines IANA came up with. Those guidelines and policies can be revised at IANA's direction, and the registry working group (the IRE WG) is going to be discussing these issues and might give IANA advice about possible revisions 🌈

This document replaces RFC 1466, with all of the guidelines and procedures updated and modified based on experience 🍓

Plot twist: this document does not describe private Internet address space or multicast address space. It also doesn't describe regional and local refinements of the global rules and guidelines 🙈

This document can be treated as the base set of operational guidelines that every registry uses. Individual registries may add extra guidelines when they think it makes sense 💜

Table of Contents 📑

    1.  Introduction.......................................2
    2.  Allocation Framework...............................4
    2.1  Guidelines for Internet Service Providers.........4
    2.2  Submission of Reassignment Information............6
    3.   Assignment Framework..............................7
    3.1  Common Registry Requirements......................7
    3.2  Network Engineering Plans.........................8
    3.3  Previous Assignment History.......................9
    3.4  Network Deployment Plans..........................9
    3.5  Organization Information..........................9
    3.6  Expected Utilization Rate.........................10
    4.   Operational Guidelines for Registries.............10
    5.   In-Addr.Arpa Domain Maintenance...................11
    6.   Right to Appeal...................................11
    7.   References........................................12
    8.   Security Considerations...........................12
    9.   Authors' Addresses................................13

1. Introduction ✨

Okay, so the addressing constraints in this document are mostly the result of how existing router technology, address assignment, and architectural history all interact 🧠 After a lot of review and discussion, the authors, the IETF working group that reviewed it, and the IESG all concluded that there aren't any other currently deployable technologies that could get around these limitations. If routing or router technology gets to the point where good routing aggregation can be done some other way, or routers can handle bigger and more dynamic routing tables, it might make sense to revisit these constraints 👑

Internet address space is handed out according to these three goals:

  1. Conservation: Fair distribution of globally unique Internet address space based on what end-users and Internet Service Providers operating networks with it actually need operationally. Stockpiling gets prevented so the lifetime of the Internet address space gets maximized 🦋
  2. Routability: Globally unique Internet addresses get distributed in a hierarchical way, so the addresses can scale for routing. That scalability is needed for Internet routing to work properly. It's important to stress that routability is in no way guaranteed just by allocating or assigning IPv4 addresses 🌸
  3. Registration: A public registry records address space allocation and assignment. That's needed to keep addresses unique and to give information for Internet trouble shooting at all levels 💖

It's in the best interest of the whole Internet community that these goals get pursued 🫶 But it's worth noting that "Conservation" and "Routability" are often in conflict with each other 😭 All of the goals above can sometimes clash with the interests of individual end-users or Internet service providers too. So each individual case needs careful analysis and judgement to find a good compromise 💅

The Internet Registry system

To achieve the goals above, the Internet Registry (IR) hierarchy was set up 🌈

The Internet Registry hierarchy has these levels, seen from the top down: IANA, Regional IRs, Local IRs 🧚

IANA

The Internet Assigned Numbers Authority has authority over all number spaces used on the Internet, and that includes Internet Address Space 👑 IANA hands out parts of the Internet address space to regional IRs based on its established needs 💖

Regional IRs

Regional IRs operate in big geopolitical regions, like continents 🌍 There are currently three regional IRs: InterNIC serving North America, RIPE NCC serving Europe, and APNIC serving the Asian Pacific region 🎀 Since that doesn't cover every area, regional IRs also serve areas around their core service areas. The number of regional IRs is expected to stay relatively small, and their service areas will be continental in size ✨

Regional IRs get established under IANA's authority. That requires consensus within the Internet community of the region, and a consensus of Internet Service Providers in that region may be needed to fill that role 🫶

The specific duties of regional IRs include coordinating and representing all the local IRs in their respective regions 🍓

Local IRs

Local IRs are established under the authority of the regional IR and IANA 🌸 They have the same role and responsibility as regional registries, just within their designated geographical areas, which are usually national in size 💜

2. Allocation Framework ✨

2.1. Guidelines for Internet Service Providers (ISPs) ✨

okay so this doc is about the difference between allocating IP addresses and assigning them 🎀 Allocation is when regional registries hand addresses to ISPs so the ISPs can give them out to their customers. Assignment is the ISP handing addresses to the customers.

ISPs that swap routing info with other ISPs at multiple locations and run without default routing can ask the regional registry in their geographic area for space directly 🌸 If an ISP doesn't have a designated regional registry, it can contact any regional registry, and that registry can either handle the request itself or refer it to the right registry 💅

To keep hierarchical addressing working (it's built on Classless Inter-Domain Routing, or CIDR), every other ISP should request address space from its upstream provider 🦋 An ISP only goes straight to a regional registry if its immediate need, once it's satisfied with a contiguous block allocation, has a reasonable chance of being routable on the Internet, AND it meets one or more of these conditions:

  • a) the ISP is directly connected to a major routing exchange (for this document, a major routing exchange is a neutral layer 2 exchange point connecting four or more unrelated ISPs.)
  • b) the ISP is multi-homed, meaning it has more than one simultaneous connection to the global Internet and no connection is favored over the other

Quick reminder 🙈 addresses issued directly from the IRs (non-provider based) are the least likely to be routable across the Internet.

Here are the IP allocation guidelines for ISPs 👑

  1. CIDR addresses are allocated to ISPs in blocks. It is recommended that those blocks remain intact. Fragmenting CIDR blocks is discouraged. ISPs are encouraged to treat address assignments as loans for the duration of the connectivity provision. When the Internet connectivity contract ends (for example, the customer moves to another service provider), it is recommended the customer return the network addresses currently in use and renumber into the new provider's address space. The ISP should allow sufficient time for the renumbering process to be completed before the IP addresses are reused.
  2. To ensure efficient implementation and use of Classless Inter-Domain Routing (IDR), the Regional Registries issue address space on appropriate "CIDR-supported" bit boundaries.
  3. ISPs are required to utilize address space in an efficient manner. To that end, ISPs should have documented justification available for each assignment. The regional registry may, at any time, ask for this information. If the information is not available, future allocations may be impacted. In extreme cases, existing loans may be impacted.
  4. IP addresses are allocated to ISPs using a slow-start procedure ⭐ New ISPs receive a minimal amount based on their immediate requirement. After that, allocated blocks may be increased based on utilization verification supplied to the regional registry. The parent registries are responsible for determining appropriate initial and subsequent allocations. Each additional allocation provides enough address space for the ISP to assign addresses for three months without requesting more space from its parent registry. Please note that projected customer base has little impact on the allocations made by the parent registries. Initial allocation is not based on any current or future routing restrictions, but on demonstrated requirements.
  5. Because IPv4 address space needs to be used more efficiently, all assignments are made with the assumption that sites use variable length subnet mask (VLSM) and classless technologies within their network 🧚 Any request for address space based on classfull assumptions will require a detailed justification. Using classfull technologies for administrative convenience is generally insupportable, given how limited free IPv4 address space is.
  6. Regional registries may set a maximum limit on assignment sizes, such that a second opinion from the regional registry is required.
  7. Because the free pool of IPv4 address space is constrained, using static IP address assignments (e.g., one address per customer) for dial-up users is strongly discouraged. It's understood that static addressing may ease some administrative tasks, but the current rate of consumption of the remaining unassigned IPv4 address space does not permit assigning addresses for administrative ease. Organizations considering static IP address assignment are expected to investigate and implement dynamic assignment technologies whenever possible.

2.2. Submission of Reassignment Information

It is imperative that reassignment information be submitted promptly and efficiently 💖 This keeps the database maintained and its integrity intact. So assignment information must be submitted to the regional registry immediately upon making the assignment. Here's why it has to be sent:

  • a) to give operational staff information on who is using the network number, and to provide a contact in case of operational/security problems,
  • b) to make sure a provider has used up a majority of its current CIDR allocation, which justifies an additional allocation,
  • c) to help with IP allocation studies.

Each regional registry decides how reassignment information gets submitted, based on its own unique requirements.

All sub-registries (ISPs, Local registries, etc.) must register with their respective regional registry to receive information about reassignment guidelines. No additional CIDR blocks will be allocated by the regional registry or upstream providers until approximately 80% of all reassignment information has been submitted 🍓

3. Assignment Framework

An assignment is the delegation of authority over a block of IP addresses to an end enterprise 🦋 The end enterprise uses addresses from an assignment internally only, and it will not sub-delegate those addresses. This section covers some of the issues involved in assignments and the framework behind them.

To keep the Internet scaling with existing technologies, use of regional registry services should be limited to assigning IP addresses for organizations that meet one or more of these conditions:

  • a) the organization has no intention of connecting to the Internet, either now or in the future, but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC1918. If that turns out not to be possible, they can be issued unique (if not Internet routable) IP addresses.
  • b) the organization is multi-homed with no favored connection.
  • c) the organization's actual requirement for IP space is very large, for example, the network prefix required to cover the request is of length /18 or shorter.

All other requestors should contact their ISP for address space, or use the addresses reserved for non-connected networks described in RFC1918 until an Internet connection is established 🌈 Again, addresses issued directly from the IRs (non-provider based) are the least likely to be routable across the Internet.

3.1. Common Registry Requirements

Because the number of available IP addresses on the Internet is limited, the utilization rate of address space is a key factor in network number assignment 😭 So, in the best interest of the Internet as a whole, specific guidelines have been created to govern assignments based on utilization rates.

Topological issues may make exceptions necessary, but the basic criteria for receiving network numbers are listed below:

            25% immediate utilization rate
            50% utilization  rate within 1 year

The utilization rate above is a guideline, and there may be be occasions when the 1 year rate does not fall exactly in this range. Organizations must show a high confidence level in their 1 year utilization rate and supply documentation to justify that confidence 🔥

Organizations are assigned address space based on immediate utilization plus 1 year projected utilization. A prefix longer than /24 may be issued if deemed appropriate. Organizations with fewer than 128 hosts will not be issued an IP address directly from the IRs. Organizations may be issued a prefix longer than /24 if they can provide documentation from a registry-recognized ISP indicating that the ISP will accept the long prefix for injection into the global routing system.

Exceptions to the criteria will not be made based on insufficient equipment without additional detailed justification. Organizations should implement variable length subnet mask (VLSM) internally to make the most of their address space. Address assignments are made under the assumption that VLSM is, or will be, implemented.

IP addresses stay valid as long as the criteria continue to be met. The IANA reserves the right to invalidate any IP assignments once it is determined the the requirement for the address space no longer exists. If an address gets invalidated, the appropriate registry will make reasonable efforts to inform the organization that the addresses have been returned to the free pool of IPv4 address space 🫶

3.2. Network Engineering Plans

Before a registry makes an assignment, it must examine each address space request in terms of the requesting organization's networking plans 💅 These plans should be documented, and should include the following information:

  1. subnetting plans, including subnet masks and number of hosts on each subnet for at least one year
  2. a description of the network topology
  3. a description of the network routing plans, including the routing protocols to be used as well as any limitations

The subnetting plans should include:

  • a) a tabular listing of all subnets on the network
  • b) its associated subnet masks
  • c) the estimated number of hosts
  • d) a brief descriptive remark regarding the subnet

If subnetting is not being used, an explanation of why it cannot be implemented is required. Care must be taken to ensure that the host and subnet estimates correspond to realistic requirements and are not based on administrative convenience 🧠

3.3. Previous Assignment History ✨

okay so, to encourage better use of address space 💅, the registries will want an accounting of any address space the enterprise was already given, if it has any. For allocation purposes, an "enterprise" means all the divisions and/or subsidiaries under one common parent organization 🏢. The history should list every network number given to the organization, the network masks for those networks, and the number of hosts on each (sub-)network. The assigning registry also needs enough corroborating evidence to feel confident the network descriptions are accurate 🫶. Routing table efficiency gets considered by the regional registries, and every request is handled case by case 🦋.

3.4. Network Deployment Plans 🚀

to give an organization the right amount of space in the time frame it needs, a registry may ask for deployment plans for a network 📅. Those plans should cover the number of hosts to be deployed per time period, the expected network growth during that period, and the changes in network topology that describe that growth 🌱.

3.5. Organization Information 🏷️

a registry may ask an organization for a published description that proves it is what it claims to be 📰. This can be brochures, incorporation documents, or similar published material ✨.

3.6. Expected Utilization Rate 📊

as we said earlier 💖, one of the big factors in deciding how much address space an organization should get is its expected utilization rate. That rate is the number of hosts connected to the network divided by the total number of hosts possible on that network 🧮. The estimated number of hosts should also be projected over a reasonable time frame, meaning one the requesting enterprise feels highly confident about 🔮. The minimal utilization rate is set by the IANA and can be changed at any time 🔄. The regional registries may enforce new utilization rates before the written policy is updated 👑.

4. Operational Guidelines For Registries 📜

  1. Regional Registries provide registration services as their main job 💼. So regional registries may charge some fee for services rendered, usually based on what it costs to provide those services 💸.
  2. No matter where its address space came from, sub-registries (Local IRs, ISPs, etc.) must follow the guidelines of their regional registry 📋. They also have to make sure their customers follow those guidelines too 🫶.
  3. To make the most of address space, IP addresses need to be assigned/allocated in classless blocks 🧩. With that in mind, assignments will not be made in Class Cs or Bs and will instead be made by prefix length 🎀. So an organization that would have gotten a Class B in the past will now get a /16 prefix, no matter its actual address class 💅.
  4. All IP address requests are subject to audit and verification by any means the regional registry thinks is appropriate 🔍. If an assignment turns out to be based on false information, the registry may invalidate the request and return the assigned addresses to the pool of free addresses for later assignment 🙈.
  5. The Internet routing system has technical and implementation limits, and there is a chance of routing overload 😭. So major transit providers may need to impose certain restrictions to cut down the number of globally advertised routes 🌐. This may include setting limits on the size of CIDR prefixes added to the routing tables, filtering non-aggregated routes, etc. 🧹. Therefore, addresses obtained directly from a regional registry (provider-independent, also known as portable) are not guaranteed to be routable on the Internet 💔.
  6. Information given to request address space is often sensitive to the requesting organization 🔒. The assigning registry must treat as confidential any and all information that the requesting organization specifically marks as sensitive 🤫. When a requesting organization does not have assurance of privacy, the parent of the assigning registry may be required to do the assignment 👑. In those cases, the parent registry will give the assigning registry information about the appropriate amount of address space to allocate 📨.
  7. Transferring IP addresses from one party to another must be approved by the regional registries 🤝. The party trying to get the IP address must meet the same criteria as if it were requesting an IP address directly from the IR 💅.

5. In-ADDR.ARPA Domain Maintenance 🗂️

the regional registries will be responsible for maintaining IN-ADDR.ARPA records only on the parent blocks of IP addresses issued directly to the ISPs, or on CIDR blocks of less than /16 🌸. Local IRs/ISPs with a prefix length of /16 or shorter will be responsible for maintaining all IN-ADDR.ARPA resource records for their customers 🧚.

IN-ADDR.ARPA resource records for networks not associated with a specific provider will keep being maintained by the regional registry 🌈.

6. Right to Appeal ⚖️

if an organization feels that the registry that assigned its address did not do its task the way it should have, the organization has the right of appeal to the parent registry 😤.

in those cases, the assigning registry shall make all relevant documentation available to the parent registry, and the parent registry's decision shall be considered final (barring additional appeals to the parent registry's parent) 📂. If necessary, after exhausting all other avenues, the appeal may be forwarded to IANA for a final decision 🦋. Each registry must, as part of its policy, document and specify how to appeal a registry assignment decision 📝.

7. References 📚

  • [RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", September 1993. 💜
  • [RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", September 1993. 💖
  • [RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", February 1996. 🎀
  • [RFC 1814] Gerich, E., "Unique Addresses are Good", June 1995. ✨
  • [RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", February 1996. 🌷

8. Security Considerations 💀

security issues are not discussed in this memo 🙈. Yes, the entire security section is one sentence, and no, that doesn't make it less serious 😭. If you're deploying anything based on this, go look up the security guidance elsewhere before you ship 🔥.

9. Authors' Addresses 🫶

Kim Hubbard
InterNIC Registration Services
c/o Network Solutions
505 Huntmar Park Drive
Herndon, VA 22070

Phone: (703) 742-4870
EMail: kimh@internic.net

Mark Kosters
InterNIC Registration Services
c/o Network Solutions
505 Huntmar Park Drive
Herndon, VA 22070

Phone: (703) 742-4795
EMail: markk@internic.net

David Conrad
Asia Pacific Network Information Center
c/o United Nations University
53-70 Jingumae 5-chome,
Shibuya-ku, Tokyo 150
JP

Phone: +81-3-5467-7014
EMail: davidc@APNIC.NET

Daniel Karrenberg
RIPE NCC
Kruislaan 409
SJ Amsterdam NL-1098
NL

Phone: +31 20 592 5065
EMail: dfk@RIPE.NET

Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA  90292

Phone: 310-822-1511
EMail: Postel@ISI.EDU
📦 where this page comes from