RFC 1467

RFC 1467 is titled Status of CIDR Deployment in the Internet 🎀. C. Topolcic wrote it at CNRI, and it's dated August 1993. Its status is that it provides information for the Internet community and does not specify an Internet standard. It obsoletes RFC 1367, and no updates are listed.

---

Status of this Memo 📣

This memo is info for the Internet community, not an Internet standard. Distribution of this memo is unlimited 💖

Abstract 🦋

Okay so this doc is about where CIDR is at, meaning how far along the building and rollout of CIDR tech in the Internet has gotten ✨ It replaces RFC 1367, which was a schedule for rolling out IP address space management procedures to support route aggregation. Every milestone in RFC 1367 got met except for delivering and installing the CIDR software, so making a fresh schedule doesn't seem necessary 🙅‍♀️ Instead, this doc just tells you how the effort is going, which the community might find interesting 👀

1. Background 🌸

The Internet has been growing exponentially, and that's caused some real headaches with managing IP network numbers 😭 Handing out ever-growing piles of network numbers to global users has been a lot for the organizations doing the handing out. The number of IP network numbers reachable through the Internet has been a strain on some routers' ability to manage their forwarding tables. Plus, poor use of the numbers already allocated threatened to run the Class A and Class B address space dry 💀

Over the past few years, the Internet community agreed on a bunch of mechanisms to fix these problems for the mid-term 🫶 They're expected to be put in place in the short term and to give relief for the mid-term. Bigger, fundamental changes to the Internet protocols, which are needed for long-term growth and well-being, are being explored and are expected to succeed the mid-term mechanisms 🚀

The global Internet community has been working super closely in forums like the IETF and its working groups, the IEPG, the NSF Regional Techs Meetings, INET, INTEROP, FNC, FEPG, and other gatherings, all to keep the Internet stable and running 🧚 Because of the need for mid-term mechanisms and the support the community gave them, the US Federal Agencies proposed procedures to help deploy those mechanisms 🇺🇸 These procedures were first described in RFC 1366 [1], which was recently made obsolete by RFC 1466 [2]. In October 1992, a schedule for putting the procedures into practice was proposed, described in RFC 1367 [3] 📅

2. Milestones that have been met 🍓

Most of the milestones on the proposed schedule were hit on time ✨ Here they are, basically as they appear in [3], with extra commentary where it made sense:

1. 31 October 92:

The following address allocation procedures were continued:

• a) The initial set of criteria for picking regional address registries was put in place, and requests from prospective regional registries were accepted by the IANA.

The Reseaux IP Europeens Network Coordination Centre (RIPE NCC) asked to become a regional registry. Per the addressing plan of RFC 1366, the RIPE NCC was given the block 194.0.0.0 to 195.255.255.255 to administer for the European Internet community. The RIPE NCC had previously and independently gotten the block 193.0.0.0 to 193.255.255.255. Even though this block had been allocated before RFC 1366, the RIPE NCC was able to manage it according to the guidelines in RFC 1366 🙌

• b) Class A network numbers were put on reserve for possible future use. The unreserved Class A numbers became very hard to get 😤
• c) Class B network numbers were only issued when reasonably justified. Whenever possible, a block of C's was issued instead of a B. The requirements for allocating a Class B got more and more tightly restricted until the date in step (3).
• d) Class C network numbers were allocated according to the addressing plan of [1], now obsoleted by [2]. Allocation kept being done by the Internet Registry (IR) for regions of the world where the IANA hadn't yet designated an appropriate regional registry.

2. 14 February 93:

The schedule in [3] was re-evaluated, there seemed to be no reason to change it, so it carried on exactly as originally set out 🔁

3. 15 April 93:
   • a) The IR started allocating all networks according to the addressing plan of [1], now obsoleted by [2], in appropriately sized blocks of Class C numbers.
   • b) Class B network numbers got hard to get, following the recommendation of the addressing plan, and were only issued when justified.

Also, throughout this time, network service providers have been requesting blocks of network numbers from the Class C address space so they can hand them out to their clients 🤝 The RIPE NCC or the IR gave them that space, acting for Europe and North America and the Pacific Rim respectively. This process has started spreading the job of address registration out to a more regional level, closer to the end users 📍 And honestly? It has worked just like everyone hoped, with no major problems 💅

---

3. Milestone that has not been met 🙈

The proposed schedule in [3] said that 6 June 1993 was the date an address aggregation mechanism would be generally available across the Internet. That date was based on plans the router vendors had stated, and it was reasonable at the time the schedule in [3] was written. But it has slipped 😬 Still, keeping that schedule going hasn't added much to the Internet's problems so far 🫠 The rest of this document looks at the current situation and what we can expect in the near future 🔮

5. Rate of growth 📈

okay so MERIT keeps publishing how many networks are in the NSFNET/ANSNET policy routing database 📊 and the trend is lowkey wild. The database is growing at about 8% per month, which means it doubles every nine or ten months [6] 🚀 bestie that is a LOT of networks 💀

There are over 13K networks in that database right now, but not all of them are active 👀 "Active" just means they're announced to the NSFNET/ANSNET Backbone. The 10K active network point got passed in late June 🎉 If the active count keeps growing at the same rate, the 12K active network point should show up around late September 1993, and the 25K active network point around mid-94 🗓️ (these are two high water marks, and you'll see why they matter later 👀✨)

Only networks that meet the NSF Acceptable Use Policy (AUP) or the ANSNET CO+RE AUP get into the NSFNET/ANSNET routing database 📋 But there are networks on the Internet that don't meet those rules 🙈 They aren't in that database, yet they still show up in the forwarding tables of some network providers 🌸 Right now, the networks connected to other known service providers but missing from the NSFNET/ANSNET database are way fewer than the ones that are in it, like less than 25% of the number 💅 Nobody has an estimate for how fast those non-NSFNET/ANSNET networks are growing, so for this doc it's assumed they grow at about the same rate as the AUP networks in the NSFNET/ANSNET routing database 🤷‍♀️

Looking at the more than 13K networks in the NSFNET/ANSNET routing database, plus the allocated but unconnected networks, CIDR deployment should have a big impact on how many forwarding table entries any router has to keep, and on how fast that number grows 🧚 Still, an in-depth study kicked off at the July 1993 meeting of the BGP Deployment Working Group of the IETF [5] 🔍 One of its goals is to figure out how CIDR affects how fast router forwarding tables grow, among other things 💜

6. Capacity of deployed networks 🏗️

bestie this section is the reality check 😭 It describes how full the forwarding tables are on the routers of several transit network providers, how much they can hold, and roughly when they'd hit that limit if today's growth keeps going 🚦 This list isn't every provider, but it's treated as roughly representative of everyone else 🫶 The providers are listed in alphabetical order 🔤

ALTERNET runs Cisco routers 🌐 They currently carry about 11K to 12K routes, both AUP and non-AUP 📦 With their current setup they have enough memory for up to about 35K routes ✨ If the number of routes grows at about the same rate as the NSFNET/ANSNET policy routing database, they could hit that limit in late 1994 ⏰ But if growth goes unchecked, the processing capacity of the routers will run out before their memory does 😱 CIDR is expected to be in place long before that point 🙌

ANSNET routers were all recently upgraded to AIX 3.2 💿 That version supports up to 12K networks 🎯 These routers only carry the active networks from the NSFNET/ANSNET routing database 📡 The next version of router code is expected to be deployed before September 1993, which is when 12K active networks are projected to show up 🗓️ That version will support 25K active networks 🔥 There are no current plans for router code that supports more than 25K networks, but CIDR is believed to help this situation 🦋

EBONE runs Cisco routers too 🖥️ They currently carry about 10K to 11K routes, and with their current configuration they may be able to support about 40K routes 💅 Here's the twist though: the number of paths might matter more 👀 The memory needed for the BGP table (not the forwarding table) depends on how many paths there are 🛤️ If a new transatlantic link were added, EBONE could receive all the North American routes through it 🌊 That would add a new set of paths, and each transatlantic link would increase the memory needed by about 20% 📈 Because of how the network topology between North America and Europe works, new transatlantic links tend to bring new paths, which means big memory needs 🧠 It's really hard to predict when new transatlantic links will be added, because they come from business or political needs, not bandwidth needs 🤷‍♀️

ESNET uses Cisco routers 🔌 It's already in trouble, but not because of the size of its forwarding tables 😬 The problem is that it has to keep a lot of configuration info about which networks it should or should not accept from its neighbors, and that info has to live in non-volatile memory, which is pretty limited 🥺 CIDR aggregation is expected to help with this 🙏 ESNET also plans to deploy BGP-4 and CIDR only after it's in a full release, so it won't be part of the initial BGP-4 deployment 🙅‍♀️ In the meantime, ESNET will upgrade its nodes to Cisco CSC-4's ⬆️

ESNET is the one to watch here, because the memory limit on its configuration info is a real problem right now 🚨

SPRINTLINK and ICM nodes all got recently upgraded to Cisco CSC-4 routers with 16MB of memory 💪 They'll carry full routing, which includes the routes the NSFNET/ANSNET carries and also routes to networks that don't comply with the NSF or CO+RE AUPs 🌍 The SPRINT routers currently carry about 11K to 12K routes, and they're expected to support up to about 25K routes with their current setup 🎯 The 25K announced network point may get reached around mid-1994 🗓️ Again, CIDR deployment is expected to have a big impact on this growth rate well before that time 🦋✨

7. Acknowledgements 🫶

this report pulls info from a bunch of sources, including vendors, operators, researchers, and organizations that help the Internet community work together 🌈 The specific organizations are the Intercontinental Engineering and Planning Group (IEPG), the BGP-4 Deployment Working Group of the IETF, the Federal Networking Council (FNC), and the FNC Engineering and Planning Group (FEPG) 🏢 The individuals, listed in alphabetical order, are Arun Arunkumar, Tony Bates, Mary Byrne, Bob Collet, Mike Craren, Dennis Ferguson, Tony Hain, Elise Gerich, Mark Knopper, John Krawczyk, Tony Li, Peter Lothberg, Andrew Partan, Gary Rucinski, Frank Solensky, and Jessica Yu 💖 None of this would've been possible without these people sharing their info publicly for the good of the community 🥹🎀

8. References 📚

• [1] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1366, Merit, October 1992.
• [2] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit, May 1993.
• [3] Topolcic, C., "Schedule for IP Address Space Management Guidelines", RFC 1367, CNRI, October 1992.
• [4] Fuller, V. et al, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", working draft obsoleting RFC 1338, BARRNet, February 1993.
• [5] Yu, J., "Minutes of the BGP Deployment Working Group (BGPDEPL)", MERIT, July 1993.
• [6] Solensky, F., Internet Growth Charts, "big-internet" mailing list, munnari.oz.au:big-internet/nsf-netnumbers-<yymm>.ps

9. Other relevant documents 🗂️

these are the extra reads for when you want the full lore 🤓📖

• Huitema, C., "IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling", RFC 1481, Internet Architecture Board, July 1993.
• Knopper, M., "Minutes of the NSFNET Regional Techs Meeting", working draft, MERIT, June 1993.
• Knopper, M., and Richardson, S., "Aggregation Support in the NSFNET Policy-Based Routing Database", RFC 1482, MERIT, June 1993.
• Topolcic, C., "Notes of BGP-4/CIDR Coordination Meeting of 11 March 93", working draft, CNRI, March 1993.
• Rekhter, Y., and Topolcic, C., "Exchanging Routing Information Across Provider/Subscriber Boundaries in the CIDR Environment", working draft, IBM Corp., CNRI, April 1993.
• Rekhter, Y., and Li, T., "An Architecture for IP Address Allocation with CIDR", working draft, IBM Corp., cisco Systems, February 1993.
• Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, IESG, November 1992.

10. Security Considerations 💀

okay the big moment 🥁 this memo says: "Security issues are not discussed in this memo." 😭 That's the whole section, bestie, so don't go looking for threat models in here 🙈

Security is not covered in this document at all. Go elsewhere for that part of the story 🚨

11. Author's Address 💌

the author is Claudio Topolcic at the Corporation for National Research Initiatives 🎀 Here's how to reach them:

Claudio Topolcic
Corporation for National Research Initiatives
895 Preston White Drive, Suite 100
Reston, VA  22091

Phone: (703) 620-8990
EMail: topolcic@CNRI.Reston.VA.US

✨ and that's the whole doc, bestie 🦋 you're officially a CIDR and routing-table expert now 👑🌸