RFC 1917

RFC 1917: An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA 💖

okay bestie, this is RFC 1917 📜✨ It's a Best Current Practice (BCP 4) from February 1996, written by P. Nesser II of Nesser & Nesser Consulting, and it's part of the Network Working Group. The header doesn't list anything it obsoletes or updates, so it stands on its own 🫶

---

Status of this Memo 📋

So this doc is an Internet Best Current Practices thing for the whole Internet Community 🌐, and it's literally asking for discussion and suggestions for improvements 💬. Distribution of this memo is unlimited 🦋

Abstract 🦋

This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. Similarly, an appeal is issued to providers to return unused prefixes which fall outside their customary address blocks to the IANA for reapportionment 🙏

---

1. Background 🌍

okay so the Internet of today is SO different from what the original designers ever pictured 😭 It's the biggest public data network in the world, and it keeps growing at an exponential rate that doubles all the major operational parameters every nine months 📈. In engineering there's this saying that every time a problem increases in size by an order of magnitude, it becomes a new problem 🙈 And honestly? That's been true the whole time the Internet has existed.

The Internet is currently facing two major operational problems (among others) 💀 The first is the eventual exhaustion of the IPv4 address space, and the second is the ability to route packets between the large number of individual networks that make up the Internet. The first one is simply a supply problem. There are only 2^32 IPv4 addresses available 😬 The lifetime of that space depends on how efficiently it gets allocated and used. The second problem is mainly a capacity problem. If the number of routes goes past what the core Internet routers can handle, some routes will get dropped, and sections of the Internet won't be able to talk to each other anymore 😱 The two problems are coupled, and the dominant one has changed over time and will keep changing ✨

The initial design of IP had every address the same: eight bits of network number and twenty four bits of host number. The expectation was a few big, global networks. During the first spurts of growth, especially once LAN technologies got invented, it became super obvious that this assumption was wrong. So the address space got split into three classes 🎀 (Class A for a few huge networks; Class B for more, smaller networks; and Class C for those really small LANs, with lots of network numbers). Soon after, subnets were added, so sites with many small LANs could show up as a single network to everyone else. That was the first step at limiting routing table size 🧚 And finally, CIDR came along to add even more flexibility to the addressing, stretching the split from three classes to potentially thirty different classes 🌈

Subnets were introduced so sites could divide a single network number (Class A, B, or C) into pieces, which means higher utilization of the address space and better conservation of the IPv4 address space 💅 Because classful addresses have that built-in idea, subnetting automatically cut down on routing requirements across the Internet 🙌 Instead of using two (or more) Class C networks, a site could subnet a single Class B into two (or more) subnets. That saves both the allocation and the advertisement of a route for the second and every later Class C 🍓

Since 1993, the concept of classless addresses (the "C" in CIDR) has been introduced to the Internet community ✨ Addresses are increasingly thought of as bitwise contiguous blocks of the entire address space, rather than as a Class A, B, or C network. For example, the address block that used to be a Class A network would be called a network with a /8 prefix, meaning the first 8 bits of the address define the network portion 🦋 Sometimes the /8 gets written as a mask of 255.0.0.0 (the same way a 16 bit subnet mask gets written as 255.255.0.0) 💜

This scheme allows "supernetting" of addresses into blocks that can be advertised as a single routing entry 🫶 The practical purpose here is to let service providers and address registries hand out realistic address spaces to organizations, without being stuck with the traditional network classes, which were badly sized for most organizations 😤 For example, the block of 2048 Class C network numbers beginning with 192.24.0.0 and ending with 192.31.255.0 can be written as 192.24/19, or as 192.24.0.0 with a mask of 255.248.0.0 (basically like a 19 bit subnet mask written in dotted decimal notation) 🤯 The concept of "supernetting" lets the rest of the Internet address space get allocated in smaller blocks, which means more networks and better efficiency 🌸 For a more detailed discussion, refer to RFC 1518 📚

Like subnetting, CIDR also helps with reducing routing requirements, but it's not as automatic as subnets are 🥲 CIDR blocks get allocated in a way that promotes hierarchical routing. A provider is usually given a large block of addresses to redistribute to its customers. For example, if the provider P has been given the CIDR block 192.168/16, which is a block of 255 contiguous Class C networks, they can give one Class C network to each of 255 customers (who may then subnet those Class C networks into smaller pieces) and still only advertise the single route 192.168/16 🧠 So CIDR only helps reduce the routing problem if blocks are assigned and maintained in a hierarchical manner 💖

RFC 1797 described a technical experiment designed to test the problems with allocating the currently reserved Class A network space 🧪 RFC 1879 described the results of that experiment. This effort shows that "supersubnetting" of a Class A network into numerous (even millions of) smaller networks is practical 🎉

The biggest part of the problem facing the Internet today is routing requirements 🚦 The following statements are a first order approximation based on current growth, a simple model of router resources, and so on. Current routing technology can handle approximately twice the number of routes that are currently advertised on "core" Internet routers. Router capacity is doubling every 18 months, while routing tables are doubling every 9 months 📉 If routes keep getting introduced at the current rate, the Internet will cease to function as a reliable infrastructure in approximately 2 to 3 years 😭

The good news? CIDR is working ✨ Address blocks are being allocated and assigned in a hierarchical manner, and the CIDR'ization of large portions of the address space that were assigned under the guidelines of RFC 1466 caused a significant drop in advertised routes 🎀 BUT recent growth trends show that the number of routes is growing at an exponential rate again, and the drop from CIDR was basically just a sawtooth in the rate 🥴

The growth in the number of routes can logically come from only two places: the extra routes created when CIDR blocks get broken up, and previously allocated networks that were never announced finally getting connected 🔌 (Registries are still allocating a few addresses that aren't within CIDR blocks, so a small third source does exist.) With growing popularity comes growing competition between providers 🏁 If a site changes provider but keeps using its CIDR block addresses, holes show up in the blocks, and specific routes get added to the routing structure to handle those cases. So over time, CIDR will improve address utilization efficiency, yet it won't help the routing requirements unless providers can keep their CIDR blocks intact 🧩

The second source of new routes is sites that previously operated a private IP network, which had been registered and assigned a network number (or many networks), but have only recently connected to the global Internet 🌐 This RFC is a policy-based attempt to help preserve the operation of the current Internet by addressing the issues of previously registered but unannounced IP networks 🫶

An additional source of new routes comes from non-aggregating router configurations 🙈 Aggregation isn't automatic on most routers, so providers who may have intact CIDR blocks are, in many cases, advertising individual routes instead of one aggregate block, without even realizing it 😩

In the context of this document, the phrase "Global Internet" refers to the mesh of interconnected public networks (Autonomous Systems) that started with the U.S. National Science Foundation (NSF) backbone, other national networks, and commercial enterprises 🌈 Similarly, the phrase "Core Routers," or any references to them, refers to the set of routers that carry the full set of route advertisements and act as interconnect points for the public networks making up the "Global Internet" 💜

---

2. History 🕰️

The IANA has historically managed the assignment of addresses to Internet sites 📖 Back in the earliest days of the IANA, with a vast address space to work with, the requirements for assigning network address space were way less strict than they are today. Organizations were basically assigned networks based on their requests 🥰

2.1 Class A Networks (/8 Prefixes) 🦁

The upper half of the Class A address space (64.0.0.0 - 126.0.0.0) has been reserved by the IANA for growth within the IPv4 address space 🌱 (127.0.0.0 has traditionally been used by the Unix operating system as the "loopback" network, so it's unavailable.) Of the lower half of the address space, 22 were assigned pre-1982, 6 were assigned between 1982 and 1987, 26 were assigned between 1988 and 1992, and 2 were assigned between 1993 and 1995 📊 In May of 1995, four previously assigned Class A networks were returned to the IANA 🎀 All remaining Class A addresses have also been reserved for growth within the IPv4 address space. The Class A address space is 50% of the total IPv4 address space 🌈

2.2 Class B Networks (/16 prefixes) 🐚

From 1989 until 1993, approximately 80% of the currently assigned Class B IP networks were assigned or allocated 📈 Allocations dropped dramatically in 1994 and 1995 because of the adoption of the policies outlined in RFC 1466 📉 61.65% of the Class B address space is currently allocated. The Class B address space is 25% of the total IPv4 address space 🍑

2.3 Class C Networks (/24 Prefixes) 🧸

With the introduction of CIDR and RFC 1466, the allocation of Class C address space has skyrocketed since 1993 🚀 27.82% of the Class C address space is currently allocated. The Class C address space is 12.5% of the total IPv4 address space 🌿

2.4 Class "D" and Beyond 🌸

Of the remaining 12.5% of the address space, the lower 6.25% is allocated for multicast applications (mbone, OSPF, etc.), and the upper half is reserved for future applications 🔮

2.5 Totals 🧮

The weighted total shows that 40.99% of the total IPv4 address space is allocated, and the remainder is reserved for future growth 🌟 It's worth noting that careful extrapolations of the current trends suggest the address space will be exhausted early in the next century 😭💔

3. Problem 🌸

okay so picture this 🎀 before RFC 1466 and CIDR showed up, the IANA had handed out some 50,000 networks, but only about 30-40% of sites were actually connected to the global Internet and advertising those networks. 😭 As the Internet keeps getting more popular, more of those sites are getting connected, and that makes the routing tables bigger and bigger. 💀

Current Internet sites got their address assignments in all sorts of ways and steps. Some sites could donate unused IP nets back to the IANA with little work, or in some cases no work at all. ✨

Some organizations started with small requests and got a Class C assignment (or several Class C assignments). Then they grew way faster than expected and asked for Class B assignments. 📈

Several Internet service providers were given blocks of Class B address space to hand out to their customers. ✨ That space was often given out based on the level of service a customer bought, not on what they actually needed. 🙃

Lots of organizations have merged or are tied to parent organizations, and that creates some seriously big inefficiencies in how addresses get assigned. 🫠

Plenty of organizations requested addresses just so they could run TCP/IP on internal machines that have zero interest in connecting to the global Internet. 💅 Most vendors' manuals told sites to request IP address assignments, and some even included copies of the application forms. 🙈

Other organizations have big internal IP networks. They connect to the Internet through application layer gateways or network address translators, and they will never announce those internal networks. 🧚

---

4. Appeal 💖

To everyone in the Internet community who holds IP network assignments that might be sitting unused right now, the community would love for you to give those addresses back to the IANA or your provider so they can be reapportioned. 🫶

Sites with networks that are unused are especially encouraged to return them. The community also encourages sites that are only using a small percentage of their address space, and who could fairly easily take network assignments out of active use, to do the same. 🌈

If your networks will never need to connect to the global Internet, or will always be isolated for security reasons, think about returning those address assignments to the IANA or your provider and using the prefixes recommended in RFC 1597. 🔥

When renumbering is needed, sites are encouraged to make a plan to renumber their machines as is reasonably convenient, and to work toward minimizing the number of routes they advertise to their providers. 🍓

4.1 Suggestions to Providers

Lots of providers are advertising non-CIDR routes that cover a huge block of addresses, i.e., any Class A (0/1) or Class B (128/2) space. 👑 Some customers only use a percentage of their address space (assuming they're subnetting using contiguous bits), and they might be willing to let their provider use the upper portion of their assigned space for the provider's other customers. 🦋

This setup needs certain elements to be installed or already in place so the routing comes out right. ✨ But it could unlock a large number of small networks without growing the global routing tables. It would take extra cooperation between providers and their customers, and it could bring economic advantages as well as good Internet citizen standing. 💜

Here's an example. Large organization S has been assigned the Class A block 10.0.0.0. and is using provider P for its connection to the global Internet. P is already advertising the route for 10.0.0.0 to the global Internet. S has been allocating its internal networks using a right to left bit incrementing model. P and S could agree that S will make some /18 (for example) prefixes available for P's other customers. 🎀 This would impose no hardships whatsoever on S, presuming his router can speak BGP, and it would let P attach a huge number of small customers without advertising more routes or requesting additional address blocks from the IANA or their upstream provider. 🤯

The "Net 39" experiment, outlined in RFC 1797 and summarized in RFC 1879, gave practical data on how these suggested schemes work in practice. 🧪

Providers are also encouraged to release all unused networks that fall outside their normal address blocks back to the IANA or the appropriate registry. 🌷

New customers, especially those who recently switched providers and have small networks that aren't part of CIDR'ized blocks, should be encouraged to renumber and give their previous addresses back to the provider or the IANA. 🦢

Since CIDR was first introduced in April of 1994, lots of providers have really gone after the concepts of aggregation. 🔥 Some providers actively persuaded their customers to renumber, others pursued peering arrangements with other providers, and some did both. Providers should keep actively and routinely pursuing both methods to streamline routing table growth. 💅 Cooperation between providers is absolutely essential for managing routing requirements in both the short and long term. 🫶

Providers should regularly verify the routes they advertise to their upstream provider(s) to validate their router configurations and confirm that correct aggregation is happening. ✅

4.2 Suggestions to the IANA and Address Registries

When addresses are returned to the IANA, or to any other address registry, and they fit into another registry's or provider's block, those addresses should be turned over to the appropriate authority. 🧚 This helps maximize address availability and minimize routing table loads. 💖

4.3 How to Return a Block of Address Space to the IANA

To return a block, send the following form to Hostmaster@internic.net & iana@isi.edu, changing $NET_PREFIX to the network being returned. 📬

----------------------------------------------------------------

Please update the contact information on the following net as
follows:

Netname: RESERVED
Netnumber: $NET_PREFIX

Coordinator:
  Reynolds, Joyce K.  (JKR1)  JKRey@ISI.EDU
  (310) 822-1511
Alternate Contact:
  Postel, Jon  (JBP)  POSTEL@ISI.EDU
  (310) 822-1511

----------------------------------------------------------------

4.4 How to Return a Block of Address Space to another Address Registry

Each registry has its own forms and addresses, so please contact the appropriate registry directly. 🌸

---

5. Conclusion 🌈

Tidying up the global addressing hierarchy is a goal that every organization currently connected to the Internet, or planning to connect, should support. 💜 If (and possibly when) things ever reach a critical point, the core service providers whose routers are failing and losing routes will be forced to pick one of two options, and both are painful for the user community. 😩

Option one: they could start blocking routes to customers who advertise too many disjoint routes, where "too many" is set at the level needed to keep their routers functioning properly. 🚫 This is a domino effect, since the next level of providers will be forced to do the same, until individual organizations are only allowed to advertise routes to portions of their networks. 🫠

Option two: the core providers could charge for advertised routes. 💸 The price would be set at a point that reduces the number of routes to a level that keeps their routers functioning properly. Again, a domino effect would follow until the price increases reach individual organizations. 💀

There is some time available right now, so some planning and effort from organizations and providers can help delay or prevent either of the two scenarios from happening. ⏳

This system has already produced very favorable results when applied on a small scale. ✨ As of this writing, 4 Class A networks have been returned to the IANA. That may not sound like a lot, but those 4 networks represent over 1.5% of the total IPv4 address capacity. 🎉

6. References 📚

1. Gerich, E., "Guidelines for Management of the IP Address Space", RFC 1466, May 1993.
2. Topolcic, C., "Status of CIDR Deployment in the Internet", RFC 1467, August 1993.
3. Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
4. Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
5. Rekhter, Y., Moskowitz, R., Karrenberg, D., and de Groot, G., "Address Allocation for Private Internets", RFC 1597, March 1994.
6. Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC 1627, July 1994.
7. Huitema, C., "The H Ratio for Address Assignment Efficiency", RFC 1715, November 1994.
8. IANA, Class A Subnet Experiment, RFC 1797, April 1995.

7. Security Considerations 🔐

Security issues are not discussed in this memo. 🙈

8. Acknowledgements 🫶

I would like to thank the members of the CIDRD mailing list and working groups for their suggestions and comments on this document. Specific thanks go to Michael Patton, Tony Li, Noel Chiappa, and Dale Higgs for detailed comments and suggestions. 💖

9. Author's Address 🖋️

Philip J. Nesser II
Nesser & Nesser Consulting
16015 84th Avenue N.E.
Bothell, WA 98011-4451

Phone: (206)488-6268
Fax: (206)488-6268
EMail: pjnesser@martigny.ai.mit.edu