RFC 1519
Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
RFC 1519: Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy 🎀
Part 1 of 6 💖
- Network Working Group: this one lives in the Network Working Group 🧚
- Request for Comments: 1519
- Authors: V. Fuller (BARRNet), T. Li (cisco), J. Yu (MERIT), and K. Varadhan (OARnet) 👑
- Category: Standards Track
- Date: September 1993
- Obsoletes: RFC 1338
- Updates: nothing listed in the title block 🌸
Status of this Memo ✨
okay so this RFC specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards." Distribution of this memo is unlimited, so share it with everyone 💅
Abstract 🦋
This memo talks about strategies for assigning addresses from the existing IP address space. The goal is to conserve that space and stop the explosive growth of routing tables in default-route-free routers. Big main character energy 👑
Table of Contents 💜
Acknowledgements ................................................. 2
1. Problem, Goal, and Motivation ................................ 2
2. CIDR address allocation ...................................... 3
2.1 Aggregation and its limitations ............................. 3
2.2 Distributed network number allocation ....................... 5
3. Cost-benefit analysis ........................................ 6
3.1 Present allocation figures .................................. 7
3.2 Historic growth rates ....................................... 8
3.3 Detailed analysis ........................................... 8
3.3.1 Benefits of new addressing plan ........................... 9
3.3.2 Growth rate projections ................................... 9
4. Changes to inter-domain routing protocols and practices ...... 11
4.1 Protocol-independent semantic changes ....................... 11
4.2 Rules for route advertisement ............................... 11
4.3 How the rules work .......................................... 13
4.4 Responsibility for and configuration of aggregation ......... 14
4.5 Intra-domain protocol considerations ........................ 15
5. Example of new allocation and routing ........................ 15
5.1 Address allocation .......................................... 15
5.2 Routing advertisements ...................................... 17
6. Extending CIDR to class A addresses .......................... 18
7. Domain Naming Service considerations ......................... 20
7.1 Procedural changes for class-C "supernets" ................... 20
7.2 Procedural changes for class-A subnetting .................... 21
8. Transitioning to a long term solution ........................ 22
9. Conclusions .................................................. 22
10. Recommendations ............................................. 22
11. References .................................................. 23
12. Security Considerations ..................................... 23
13. Authors' Addresses .......................................... 24Acknowledgements 🌈
the authors want to say a huge thank you to the members of the ROAD group 🫶 Lots of the ideas in this document were inspired and developed with them, and we're obsessed 🥹
1. Problem, Goal, and Motivation ✨
okay so as the Internet has evolved and grown over the last few years, it's become clear that it's about to run into some serious scaling problems 😭 These include:
- Exhaustion of the class B network address space. One big cause is that there's no network class that fits mid-sized organizations. Class C tops out at 254 host addresses, which is too small, while class B allows up to 65534 addresses, which is way too big for most orgs 💀
- Routing table growth in Internet routers that's gotten past what current software, hardware, and people can actually manage 🙈
- Eventual exhaustion of the 32-bit IP address space. 🔥
The first two problems are likely to get critical within the next one to three years, so this memo is trying to fix them 💅 The plan is to slow down the growth of the routing table and the need for brand new IP network numbers. It doesn't try to solve problem three, which is more of a long-term thing. Instead it eases the short-to-mid-term stress so the Internet can keep running efficiently while people work on a longer-term solution 🦋
The proposed solution is to allocate future IP address assignments topologically, by handing out segments of the IP address space to the transit routing domains 🧚
This allocation plan should be undertaken as soon as possible. The authors believe it will work as a short-term strategy, filling the gap until a viable long-term plan can be put in place and deployed effectively. The plan should stay viable for at least three (3) years. After that, deployment of a suitable long-term solution is expected to happen. 💖
This plan mainly targets the first two problems. The authors believe that using variable-length subnetting wisely should help delay the onset of the last one, the exhaustion of the 32-bit address space 🌸 Also, better tools for address allocation in a "supernetted" and variably-subnetted world would really help users accept these sometimes confusing techniques, so the Internet community should be encouraged to build some simple tools for this 🛠️
Note that this plan neither requires nor assumes that already assigned addresses will be reassigned. Reassigning them would be a bonus, though, since it would shrink routing table sizes even more. The plan assumes routing technology can handle the current routing table size and some reasonably small rate of growth. The whole emphasis is on significantly slowing that growth 📉
Also, this plan does not require domains to renumber when they change their attached transit routing domain. Domains are encouraged to renumber so their individual address allocations don't need to be advertised ✨
Last but not least, this plan won't affect the deployment of any specific long-term plan. That's why this document won't discuss any long-term plans for routing and address architectures 💜
2. CIDR address allocation ✨
okay bestie, this part is where the plan gets its hands dirty 💅 there are two basic components here: one, handing out Internet address space, and two, giving us a way to aggregate routing information 🗺️
2.1 Aggregation and its limitations
one big goal of this addressing plan is to hand out Internet address space so that routing info can be aggregated along topological lines 🦋 for simple, single-homed clients, getting their space out of a transit routing domain's space does this automatically. instead of advertising a separate route for each client, the transit domain can advertise one aggregate route that covers every destination connected to it 🎀 unfortunately, not all sites are singly-connected to the network, so some aggregation ability gets lost in the non-trivial cases 😭
there are two situations that cause a loss of aggregation efficiency 🥀
- Multi-homed organizations. Multi-homed organizations MUST be advertised into the system by each of their service providers, so it's often not feasible to aggregate their routing info into the address space of any one of those providers 💀 they can still get their address allocation out of a transit domain's address space (which has other perks!), but their routing info still MUST be explicitly advertised by most of their service providers. the exception: if the site's allocation comes out of its least-preferable service provider, that provider doesn't need to advertise the explicit route, because longest-match will ensure its aggregated route gets used to reach the site as a backup 🛟 so the routing cost for these organizations is typically about the same as it is today.
- Organizations that change service provider but don't renumber. this "punches a hole" in the original service provider's advertisement 🕳️ the plan handles it by having the newer service provider advertise a specific route for the new client, which wins because it's the longest match. to keep aggregation efficient, it's RECOMMENDED that organizations changing providers plan to eventually migrate their address assignments from the old provider's space to the new provider's space. it's also RECOMMENDED that mechanisms to make this migration easier get developed, including improved protocols and procedures for dynamic host address assignment 🧚
some aggregation efficiency can still be had for multi-homed sites (and, in general, for any site made up of multiple, logical IP network numbers) 🌸 if you give the client a contiguous power-of-two block of network numbers, instead of multiple independent ones, the client's routing info can be aggregated into a single (net, mask) pair. plus, since the routing cost of assigning a multi-homed site out of a service provider's address space is no greater than the current method of random allocation by a central authority, it makes sense to allocate all address space out of blocks assigned to service providers 💜
it's also worth mentioning that aggregation can happen at multiple levels in the system, so it may still be possible to aggregate these anomalous routes at higher levels of whatever hierarchy is present 👑 for example, if a site is multi-homed to two NSFNET regional networks that both get their address space from the NSFNET, then aggregation by the NSFNET of routes from the regionals will include all routes to the multi-homed site. iykyk 🙈
finally, the new addressing plan in this document MAY (and SHOULD) start being deployed almost immediately, but using the plan to aggregate routing info effectively will REQUIRE changes to some Inter-Domain routing protocols 🔥 likewise, deploying classless Inter-Domain protocols without the new address plan won't allow useful aggregation (so the addressing plan and the routing protocol changes are both REQUIRED for supernetting, and its resulting reduction in table growth, to be effective 🫶). heads up though: in the period between deploying the addressing plan and deploying the new protocols, the size of routing tables may temporarily grow very rapidly 😱 this MUST be considered when planning the deployment of the two plans!!
Note: in the discussion and examples that follow, the network and mask notation is used to represent routing destinations. this is for illustration only and doesn't require routing protocols to use this representation in their updates 🌈
2.2 Distributed allocation of address space
the basic idea of the plan: allocate one or more blocks of Class C network numbers to each network service provider 🍓 organizations that use that provider for Internet connectivity get bitmask-oriented subsets of the provider's address space as they need it.
it's also worth mentioning that once inter-domain protocols that support classless network destinations are widely deployed, the rules in this plan generalize to allow arbitrary super/subnetting of the remaining class A and class B address space ✨ (the assumption being that classless inter-domain protocols will either allow non-contiguous subnets to exist in the system, or that all components of a sub-allocated class A/B will be contained within a single routing domain). this lets the plan keep being used if the class C space runs out before a long-term solution is deployed. this alternative is discussed further below in section 6.
hierarchical sub-allocation like this means clients with addresses allocated out of a given service provider are, for routing purposes, part of that service provider, and they'll be routed via its infrastructure 🚀 it also means routing info about multi-homed organizations (organizations connected to more than one network service provider) still needs to be known by higher levels in the hierarchy.
the advantages of hierarchical assignment this way are:
a) it's expected to be easier for a relatively small number of service providers to get addresses from the central authority, instead of a much larger, and monotonically increasing, number of individual clients. this is not to be considered a loss of part of the service providers' address space 💖
b) given the current growth of the Internet, a scalable and delegatable method of future network number allocation has to be achieved 📈
for these reasons, and to provide a consistent procedure for obtaining Internet addresses, it's RECOMMENDED that most, if not all, network numbers get distributed through service providers 🎀 these issues are discussed in much greater length in [2].
3. Cost-benefit analysis 💰✨
okay so this new way of handing out addresses through service providers can be put into effect immediately 🚀, and right from the start it gets the benefit of spreading out the currently centralized process of assigning new addresses. the tea though: before we can get the win of shrinking the size of globally-known routing destinations, we have to deploy an Inter-Domain routing protocol that can handle arbitrary network and mask pairs 😭. only then can individual class C networks get aggregated into bigger blocks, with each block represented by a single routing table entry 🧩.
so at the moment of introduction, the new addressing allocation plan won't by itself help with the routing table size problem 💀. once the new Inter-Domain routing protocol is deployed, though, there's an immediate drop in the number of destinations that clients of the new protocol have to carry 📉. a detailed analysis of how big that drop is, plus the permanent slowdown in the rate of growth, is in the next section 👀.
also, it should be noted that the current flat address allocation setup puts a huge bureaucratic cost on the central address allocation authority 🏛️. for scaling reasons that have nothing to do with address space exhaustion or routing table overflow, this should be changed 🙌. using the mechanism proposed in this paper has the lucky side effect of distributing the address allocation procedure, which greatly reduces the load on the central authority 💅.
3.1. Present Allocation Figures 📊
an informal analysis of "network-contacts.txt" (available from the DDN NIC) says that as of 2/25/92, 46 of 126 class A network numbers were allocated (leaving 81), and 5467 of 16382 class B numbers were allocated, leaving 10915 🍓. if recent trends keep going, the number of allocated class B's will keep doubling approximately once a year. at that rate, all class B's will be exhausted within about 15 months 😱. as of 1/13/93, 52 class A network numbers had been allocated and 7133 class B's had been allocated. we suggest that the change in the class B allocation rate is due to the initial deployment of this address allocation plan 🤔.
3.2. Historic growth rates 📈
MM/YY ROUTES MM/YY ROUTES
ADVERTISED ADVERTISED
------------------------ -----------------------
Dec-92 8561 Sep-90 1988
Nov-92 7854 Aug-90 1894
Oct-92 7354 Jul-90 1727
Sep-92 6640 Jun-90 1639
Aug-92 6385 May-90 1580
Jul-92 6031 Apr-90 1525
Jun-92 5739 Mar-90 1038
May-92 5515 Feb-90 997
Apr-92 5291 Jan-90 927
Mar-92 4976 Dec-89 897
Feb-92 4740 Nov-89 837
Jan-92 4526 Oct-89 809
Dec-91 4305 Sep-89 745
Nov-91 3751 Aug-89 650
Oct-91 3556 Jul-89 603
Sep-91 3389 Jun-89 564
Aug-91 3258 May-89 516
Jul-91 3086 Apr-89 467
Jun-91 2982 Mar-89 410
May-91 2763 Feb-89 384
Apr-91 2622 Jan-89 346
Mar-91 2501 Dec-88 334
Feb-91 2417 Nov-88 313
Jan-91 2338 Oct-88 291
Dec-90 2190 Sep-88 244
Nov-90 2125 Aug-88 217
Oct-90 2063 Jul-88 173
Table I : Growth in routing table size, total numbers
Source for the routing table size data is MERIT3.3. Detailed Analysis 🔍
there's a small technical cost and a minimal administrative cost tied to deploying the new address assignment plan 🛠️. the administrative cost is basically convincing the NIC, the IANA, and the network service providers to agree to this plan, which isn't expected to be too difficult 🤝. administrative cost for the central numbering authorities (the NIC and the IANA) will also be greatly decreased by deploying this plan 💖. to take advantage of aggregation of routing information, though, it is necessary that the capability to represent routes as arbitrary network and mask fields (as opposed to the current class A/B/C distinction) be added to the common Internet inter-domain routing protocol(s). so the technical cost is in implementing classless interdomain routing protocols 🦋.
3.3.1. Benefits of the new addressing plan ✨
there are two benefits to deploying this plan:
- the current problem with depletion of the available class B address space can be eased by assigning more-appropriately sized blocks of class C's to mid-sized organizations (in the 200-4000 host range) 🎀
- when the improved inter-domain routing protocol is deployed, an immediate decrease in the number of routing table entries should occur, followed by a significant reduction in the rate of growth of routing table size (for default-free routers) 🌈
3.3.2. Growth rate projections 🔮
as of Jan '92, a default-free routing table (for example, the routing tables maintained by the routers in the NSFNET backbone) contained approximately 4700 entries 💜. that number reflects the current size of the NSFNET routing database. historic data shows that this number, on average, doubled every 10 months between 1988 and 1991. assuming this growth rate keeps going in the foreseeable future (and there's no reason to assume otherwise 🙃), we expect the number of entries in a default-free routing table to grow to approximately 30000 in two years time. in the following analysis, we assume the growth of the Internet has been, and will keep being, exponential 📐.
it should be stressed that these projections do not consider that the current shortage of class B network numbers may increase the number of instances where many class C's are used rather than a class B. using an assumption that new organizations which formerly obtained class B's will now obtain somewhere between 4 and 16 class C's, the rate of routing table growth can conservatively be expected to at least double and probably quadruple. this means the number of entries in a default-free routing table may well exceed 10,000 entries within six months and 20,000 entries in less than a year 😬.
as of Dec '92, the routing table contains 8500 routes. the original growth curves would predict over 9400 routes. at this time, it is not clear if this would indicate a significant change in the rate of growth 🤷♀️.
under the proposed plan, growth of the routing table in a default-free router is greatly reduced, since most new address assignment will come from one of the large blocks allocated to the service providers 🧃. for the sake of this analysis, we assume prompt implementation of this proposal and deployment of the revised routing protocols. we make the initial assumption that any initial block given to a provider is sufficient to satisfy its needs for two years.
since under this plan, multi-homed networks must continue to be explicitly advertised throughout the system (according to Rule #1 described in section 4.2), the number of multi-homed routes is expected to be the dominant factor in future growth of routing table size, once the supernetting plan is applied 🌸.
presently, it is estimated that there are fewer than 100 multi-homed organizations connected to the Internet. each such organization's network is comprised of one or more network numbers. in many cases (and in all future cases under this plan), the network numbers used by an organization are consecutive, meaning that aggregation of those networks during route advertisement may be possible. this means that the number of routes advertised within the Internet for multi-homed networks may be approximated as the total number of multi-homed organizations. assuming that the number of multi-homed organizations will double every year (which may be an over-estimation, given that every connection costs money 💸), the number of routes for multi-homed networks would be expected to grow to approximately 800 in three years.
if we further assume that there are approximately 100 service providers, then each service provider will also need to advertise its block of addresses. however, due to aggregation, these advertisements will be reduced to only 100 additional routes. we assume that after the initial two years, new service providers combined with additional requests from existing providers will require an additional 50 routes per year. thus, the total is 4700 + 800 + 150 = 5650. this represents an annual growth rate of approximately 6%. this is in clear contrast to the current annual growth of 130% 🚨. this analysis also assumes an immediate deployment of this plan with full compliance. note that this analysis assumes only a single level of route aggregation in the current Internet. intelligent address allocation should significantly improve this 🧠.
clearly, this is not a very conservative assumption in the Internet environment, nor can 100% adoption of this proposal be expected. still, with only a 90% participation in this proposal by service providers, at the end of the target three years, global routing table size will be "only" 4700 + 800 + 145 + 7500 = 13145 routes. without any action, the routing table will grow to approximately 75000 routes during that time period 😳.
4. Changes to inter-domain routing protocols and practices 🔧
in order to support supernetting efficiently, it is clear that some changes will need to be made to both routing protocols themselves and to the way in which routing information is interpreted. in the case of "new" inter-domain protocols, the actual protocol syntax changes should be relatively minor. this mechanism will not work with older inter-domain protocols such as EGP2. the only ways to interoperate with old systems using such protocols are either to use existing mechanisms for providing "default" routes, or b) require that new routers talking to old routers "explode" supernet information into individual network numbers. since the first of these is trivial while the latter is cumbersome (at best -- consider the memory requirements it imposes on the receiver of the exploded information), it is recommended that the first approach be used, meaning that older systems continue to use the mechanisms they currently employ for default handling 🙏.
note that a basic assumption of this plan is that those organizations which need to import "supernet" information into their routing systems must run IGPs (such as OSPF [1]) which support classless routes. systems running older IGPs may still advertise and receive "supernet" information, but they will not be able to propagate such information through their routing domains 🚧.
4.1. Protocol-independent semantic changes 🧠
There are two big changes that have to happen in Inter-Domain routing protocols for this plan to work, bestie 🎀. First, the whole idea of network "class" needs to be deprecated 💅. This plan assumes that routing destinations are represented by network and mask pairs, and that routing is done on a longest-match basis (so for any destination that matches more than one network+mask pair, the match with the longest mask wins 👑). Second, current inter-domain protocols mostly don't support route aggregation at all, so the new semantics need a brand-new set of inter-domain protocols 🦋. Aggregation gets messy fast, especially with multi-homed sites or destinations that switch service providers 😭. The good news? It's possible to write a few pretty simple rules for handling those cases ✨.
4.2. Rules for route advertisement 🌸
- Routing to all destinations must be done on a longest-match basis only 💖. This means that destinations which are multi-homed relative to a routing domain must always be explicitly announced into that routing domain. They can't be summarized 🙈. (This makes total sense: if a network is multi-homed, every one of its paths into a routing domain that sits "higher" in the network hierarchy has to be known to that "higher" network 🧚.)
- A routing domain that summarizes multiple routes must discard packets which match the summary but don't match any of the explicit routes that make up that summary 🔥. This is needed to prevent routing loops when less-specific information is around, such as a default route 💀. Implementation note: one simple way to do this is for the border router to keep a "sink" route for each of its aggregations 🍓. Thanks to the longest-match rule, this makes all traffic headed for parts of the aggregation that aren't explicitly known get thrown away 🗑️.
Now, here's the tea ☕. During failures, some traffic can get partially routed to a site that takes its address space from one service provider, but is actually only reachable through a different one (aka the case of a site that has changed service providers) 😬. That happens because the traffic follows the path advertised by the aggregated route. Rule #2 keeps any real damage from happening by forcing that traffic to be discarded by whoever advertises the aggregate 🛑. BUT, the output of traceroute and similar tools will make it look like the problem is inside the service provider advertising the aggregate, which can be super confusing for network operators 😵💫 (check the example in section 5.2 for the details). Solving this seems pretty challenging, and current Inter-Domain protocols probably can't do it within the timeframe this document suggests 🕰️. This decision may need a second look as Inter-Domain protocols evolve 🌈.
An implementation that follows these rules should also be general 🧠. That means it should accept an arbitrary network number and mask for all routing destinations. The only constraint left is that the mask must be left contiguous 📏. Also, the degenerate route 0.0.0.0 with mask 0.0.0.0 is used as a default route, and it MUST be accepted by all implementations 👑. To protect against accidental advertisements of this route through the inter-domain protocol, this route should never be advertised unless there's specific configuration information telling it to be 🔒.
Systems that process route announcements also need to be able to verify that the information they receive is correct ✅. So implementations of this plan that filter route advertisements must also allow masks in their filter elements 🎀. To make admin life easier, it would be helpful if filter elements automatically let more specific network numbers and masks through when a more general mask is given 🫶. So filter elements that looked like this:
accept 128.32.0.0
accept 128.120.0.0
accept 134.139.0.0
deny 36.2.0.0
accept 36.0.0.0would look something like this:
accept 128.32.0.0 255.255.0.0
accept 128.120.0.0 255.255.0.0
accept 134.139.0.0 255.255.0.0
deny 36.2.0.0 255.255.0.0
accept 36.0.0.0 255.0.0.0Basically, this is just making explicit the network mask that was implied by the class A/B/C classification of network numbers 🦋✨.
4.3. How the rules work 💅
Rule #1 keeps the routing algorithm consistent across implementations and consistent with other routing protocols, such as OSPF 🤝. Multi-homed networks are always explicitly advertised by every service provider they're routed through, even if they're a specific subset of one provider's aggregate 🌸. (If they weren't, they'd obviously have to be explicitly advertised anyway.) You might think the "primary" service provider could just advertise the multi-homed site implicitly as part of its aggregate, but since longest-match routing is always in play, that doesn't work 🙅♀️.
Rule #2 guarantees that no routing loops form because of aggregation 🔁. Picture a mid-level network that's been allocated the 2048 class C networks starting with 192.24.0.0 (see the example in section 5 for more on this) 🗺️. The mid-level advertises 192.24.0.0/255.248.0.0 to a "backbone". Say the "backbone" was allocated the block 192.0.0.0/255.0.0.0, so it advertises that aggregate route to the mid-level 📡. Now, if the mid-level loses internal connectivity to 192.24.1.0/255.255.255.0 (which is part of its aggregate), traffic from the "backbone" to the mid-level for destination 192.24.1.1 will follow the mid-level's advertised route 😳. When that traffic reaches the mid-level, the mid-level must not follow the 192.0.0.0/255.0.0.0 route it learned from the backbone, because that would create a routing loop 🌀. Rule #2 says the mid-level may not follow a less-specific route for a destination that matches one of its own aggregated routes 🚫. The "default" route (0.0.0.0/0.0.0.0) is a special case of this rule: a network must not follow the default to destinations that are part of one of its own aggregated advertisements 💜.
4.4. Responsibility for and configuration of aggregation 👑
The domain that's been allocated a range of addresses has sole authority over aggregating its address space 🏰. Usually, the AS will install manual configuration commands in its border routers to aggregate some portion of that space ⚙️. A domain can also delegate aggregation authority to another domain. When that happens, the aggregation is done in the other domain by one of its border routers 🤝.
When an inter-domain border router performs route aggregation, it needs to know the range of the block of IP addresses to be aggregated 📦. The basic principle is to aggregate as much as possible, but not to aggregate routes that can't be treated as one unit because of multi-homing, policy, or other constraints 🧩.
There are two mechanisms for this. The first is to aggregate based solely on dynamically learned routing information. This has a danger, though: it might not specify a precise enough range, because when a route is missing, it isn't always possible to tell whether it's temporarily unreachable or just doesn't belong in the aggregate 😱. Purely dynamic routing also doesn't give you the flexibility to define what gets aggregated within a range 🙃. The second mechanism is to do all aggregation based on ranges of IP address blocks preconfigured in the router. It is recommended that preconfiguration be used, since it's more flexible and allows a precise specification of the range of destinations to aggregate 🎯.
Preconfiguration does require some manually maintained configuration information, but not excessively more than what router administrators already maintain today 📝. On top of the information a human already types in and maintains, preconfiguration is just a line or two defining the range of the block of IP addresses to aggregate 🌷. As for gathering the information: if the advertising router is doing the aggregation, its administrator already knows it, because the aggregation ranges are assigned to its domain 🏠. If the receiving domain has been granted the authority and task of performing aggregation, the information would be known as part of the agreement to delegate aggregation 🤝. Since it's common practice for a network administrator to learn from a neighbor which routes they should be willing to accept, preconfiguring aggregation information doesn't add extra administrative overhead 🥳.
Implementation note: aggregates that encompass the class D address space (multicast addresses) are currently not well understood 🌀. For now, it looks like the best strategy is to consider aggregates to never encompass class D space, even if they do so numerically 🙅♀️.
4.5 Intra-domain protocol considerations 🧚
No changes need to be made to internal routing protocols to support advertising aggregated routing information between autonomous systems 🙌. However, it's often the case that external routing information gets propagated within interior protocols, either for policy reasons or to help move information through a transit network 🚇. Once aggregated routing information starts showing up in the new exterior protocols, this practice of importing external information will have to change 😤. A transit network that imports external information will have to do one of the following:
- a) use an interior protocol that supports aggregated routing
- b) find some other way of propagating external information that doesn't involve flooding it through the interior protocol (for example, by using internal BGP) 🌐
- c) stop importing external information and flood a "default" route through the internal protocol so that paths to external destinations can still be discovered 🧭
For case (a), the changes needed for a routing protocol to support aggregated information may not be simple 😬. For protocols like OSPF and IS-IS, which represent routing information as either a destination+mask (OSPF) or as a prefix+prefix-length (IS-IS), the changes needed to support aggregated information are conceptually fairly simple 🍰. But for protocols that depend on the class-A/B/C nature of networks, or that only support fixed-size subnets, the changes are much more fundamental 🧱. And even in the "conceptually simple" cases of OSPF and IS-IS, an implementation might need modifications to support supernets in the database or in the forwarding table 💻✨.
5. Example of new allocation and routing ✨
okay bestie, this is where we finally see the whole CIDR thing in action 🦋 we're following one real-ish provider called "RA" and its clients 💅
5.1. Address allocation
so picture a block of 2048 class C network numbers, from 192.24.0.0 (0xC0180000) all the way to 192.31.255.0 (0xC01FFF00), all handed to one single network provider, "RA" 🎀 the "supernetted" route for that whole block is 192.24.0.0 with mask 255.248.0.0 (0xFFF80000). iconic 👑
RA then connects six clients, and the ORDER matters 🧚 it shows how temporary "holes" can pop up in the provider's address space:
"C1" requiring fewer than 2048 addresses (8 class C networks)
"C2" requiring fewer than 4096 addresses (16 class C networks)
"C3" requiring fewer than 1024 addresses (4 class C networks)
"C4" requiring fewer than 1024 addresses (4 class C networks)
"C5" requiring fewer than 512 addresses (2 class C networks)
"C6" requiring fewer than 512 addresses (2 class C networks)every single one of these counts already leaves room for big growth 🌈 RA allocates like this:
C1: allocate 192.24.0 through 192.24.7. This block of networks is
described by the "supernet" route 192.24.0.0 and mask
255.255.248.0
C2: allocate 192.24.16 through 192.24.31. This block is described
by the route 192.24.16.0, mask 255.255.240.0
C3: allocate 192.24.8 through 192.24.11. This block is described
by the route 192.24.8.0, mask 255.255.252.0
C4: allocate 192.24.12 through 192.24.15. This block is described
by the route 192.24.12.0, mask 255.255.252.0
C5: allocate 192.24.32 and 192.24.33. This block is described by
the route 192.24.32.0, mask 255.255.254.0
C6: allocate 192.24.34 and 192.24.35. This block is described by
the route 192.24.34.0, mask 255.255.254.0ngl this is so satisfying 🫶 now, if RA's IGP can handle classless networks, RA can (but doesn't have to) supernet right where it hooks up with its clients. that means only six distinct routes for those 36 class C numbers 💖 if it can't, then explicit routes to all 36 class C networks have to be carried by the IGP 😭
to make this more realistic (because real life is messy 💀), say C4 and C5 are multi-homed through another provider, "RB". ALSO there's a client "C7" that was originally connected to RB but moved over to RA 🏃♀️ so C7 has a block carved out of RB's block of (the next) 2048 class C network numbers:
C7: allocate 192.32.0 through 192.32.15. This block is described
by the route 192.32.0, mask 255.255.240.0for the multi-homed clients: C4 is advertised as primary via "RA" and secondary via "RB", and C5 is primary via "RB" and secondary via "RA" 🔥 and to tie it all together, "RA" and "RB" are connected through a common "backbone" provider, "BB" 🦋
here's the vibe in diagram form 👇
C1
192.24.0.0 -- 192.24.7.0 \ _ 192.32.0.0 - 192.32.15.0
192.24.0.0/255.255.248.0 \ / 192.32.0.0/255.255.240.0
\ / C7
C2 +----+ +----+
192.24.16.0 - 192.24.31.0 \| | | |
192.24.16.0/255.255.240.0 | | _ 192.24.12.0 - 192.24.15.0 _ | |
| | / 192.24.12.0/255.255.252.0 \ | |
C3 -| |/ C4 \| |
192.24.8.0 - 192.24.11.0 | RA | | RB |
192.24.8.0/255.255.252.0 | |___ 192.24.32.0 - 192.24.33.0 ___| |
/| | 192.24.32.0/255.255.254.0 | |
C6 | | C5 | |
192.24.34.0 - 192.24.35.0 | | | |
192.24.34.0/255.255.254.0 | | | |
+----+ +----+
\\ \\
192.24.12.0/255.255.252.0 (C4) || 192.24.12.0/255.255.252.0 (C4) ||
192.32.0.0/255.255.240.0 (C7) || 192.24.32.0/255.255.254.0 (C5) ||
192.24.0.0/255.248.0.0 (RA) || 192.32.0.0/255.248.0.0 (RB) ||
|| ||
VV VV
+--------------- BACKBONE PEER BB ---------------+5.2. Routing advertisements
okay so, to follow rule #1, RA has to advertise the block of addresses it was given AND C7 🙌 since C4 is multi-homed and primary through RA, it must also be advertised too. C5 is multi-homed and primary through RB, so it doesn't need to be advertised, because the longest match at BB will automatically pick RB as primary and RA's aggregate just gets used as a secondary 💅
RA's advertisements to BB look like this:
192.24.12.0/255.255.252.0 primary (advertises C4)
192.32.0.0/255.255.240.0 primary (advertises C7)
192.24.0.0/255.248.0.0 primary (advertises remainder of RA)for RB, the advertisements also have to include C4 and C5 along with its own block of addresses 🍓 RB may also advertise that C7 is unreachable.
RB's advertisements to BB look like this:
192.24.12.0/255.255.252.0 secondary (advertises C4)
192.24.32.0/255.255.254.0 primary (advertises C5)
192.32.0.0/255.248.0.0 primary (advertises remainder of RB)now here's the drama 😭 remember that "note" in section 4.2? this is the problem it was talking about. say RA loses connectivity to C7 (the client carved out of RB's space). in a stateful protocol, RA announces to BB that 192.32.0.0/255.255.240.0 is unreachable. but when BB flushes that from its routing table, any future traffic sent through it for that destination gets forwarded to RB (where it gets dropped under Rule #2) because of RB's less specific match, 192.32.0.0/255.248.0.0 💀 this doesn't cause a real operational problem (C7 is unreachable anyway), but it does create extra traffic across "BB", and it can also be super confusing for a network manager debugging the outage with "traceroute" 🙈
a mechanism to cache that unreachability info would help here, but it's beyond the scope of this document (and honestly, such a mechanism isn't implementable in the near-term either) 🫠
6. Extending CIDR to class A addresses ✨
okay so the big question is: what happens when the class C pool runs dry? 😭 The plan is expected to eventually eat all the remaining class C space. Right now the upper half of the class A space is already reserved for future expansion, and this section is about how CIDR could use that chunk efficiently. It's a backup plan, though. It's only expected to get used if no long term solution has shown up by the time class C is gone. 🦋
There are basically two differences between using a class A address and a bunch of class C's. First, DNS gets more complicated once you aggregate class A subnets. Second, the routers inside that class A would need to support and use a classless IGP. 🧚
Maintaining DNS for a subnetted class A is kind of painful, ngl. For reverse lookups, DNS keeps an "IN-ADDR.ARPA" reverse domain. You make it by reversing the dotted decimal network number, tacking on "IN-ADDR.ARPA", and treating that as a sort of pseudo-domain. Individual hosts then point back to a host name. So, for example, 131.108.1.111 has the DNS record 111.1.108.131.IN-ADDR.ARPA. 💅 The catch is that pseudo-domains can only be delegated on a byte boundary, so it gets messy when a stub domain gets a block of address space that doesn't line up with a byte boundary. The workaround is to enumerate all the possible byte combinations involved. It's painful, but workable. We'll get into it more below. 🙈
Routing inside a class A used for CIDR is also a whole thing. The usual case is that a domain gets assigned a portion of the class A space. That domain can either run an IGP that allows variable length subnets, or it can pick a single subnet mask to use everywhere in the domain. With the single mask option, things get tricky, because other domains have been handed other parts of the class A and might be using a different mask. If the domain is itself a transit, it may also need to hand some of its space to a client, and that client might use yet another mask. The client would then need routing information about the rest of the class A. 😭
If the client's IGP doesn't support variable length subnet masks, one option is to advertise the rest of the class A's address space as appropriately sized subnets. But unless the client has a very large portion of the class A space, this ends up creating a huge number of subnets. For example, a mask of 255.255.255.0 would require a total of 65535 subnets, including the ones allocated to the client. Yikes. 💀 So it may be better to just use an IGP that supports variable length subnet masks inside the client's domain.
Same deal for transits. If a transit got its address space from a class A network number, it probably didn't get the entire class A, and other transit domains will get space from that class A too. In that case, the transit would also have to inject routing information about the rest of the class A into its IGP. That's basically the situation above, with the same complications. 🌸 For that reason, we recommend that a class A only be used for CIDR if IGP's with variable length subnet mask support are used throughout the class A. Also, the IGP's don't need to support supernetting, as discussed above.
Quick aside: this technique could also apply to class B addresses. But there aren't many class B addresses to go around, and they're used a lot for multihomed networks. So this space should only be reserved for those large single organizations that really warrant this type of address. [2] 🎀
7. Domain Service considerations
Here's a big one. Whether we move to "supernetted" class C network numbers or subdivided class A's, the address-to-name translation mechanism is going to feel it: the IN-ADDR.ARPA zone of the domain system. This zone is delegated on octet boundaries only. So any address allocation plan that uses bitmask-oriented addressing is going to cause some difficulty for folks who maintain parts of the IN-ADDR.ARPA zone. 🍓
7.1 Procedural changes for class-C "supernets"
Right now, parts of the IN-ADDR.ARPA zone only get delegated on network boundaries that happen to fall on octet boundaries. To make blocks of class C networks easier to use, it is recommended that this policy be relaxed, so arbitrary, octet-oriented pieces of the IN-ADDR.ARPA zone can be delegated. 🦋
Let's look at an example. Say there's a large network provider called "BigNet" that's been allocated 1024 class C networks, 199.0.0 through 199.3.255. Under current policies, the root domain servers would need 1024 entries that look like this:
0.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
1.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
....
255.3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.With the revised policy described above, that shrinks down to just four delegation records:
0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
1.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
2.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.After that, the provider maintains further delegations of naming authority for each individual class C network it assigns, instead of each one being registered separately. ✨ Note that because of how the DNS is designed, the root nameservers can still keep the delegation information for individual networks in cases where the provider isn't willing or able to do it. This should greatly reduce the load on the domain servers for the "top" levels of the IN-ADDR.ARPA domain. The example above only shows the records for a single nameserver. In the normal case there are usually several nameservers for each domain, so the examples will double or triple in the common cases. 🌈
7.2 Procedural changes for class-A subnetting
If class A network numbers end up getting subdivided into blocks for transit network providers, the restriction on how IN-ADDR.ARPA naming works will similarly need to be relaxed for them. 💜 As an example, let's say a provider gets the 19-bit portion of address space that matches 10.8.0.0 with mask 255.248.0.0. That covers every address starting with the prefixes 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, and 10.15, and it requires these IN-ADDR.ARPA delegations:
8.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.
9.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.
....
15.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.To show how sub-delegation works in practice, imagine a company called "FOO" that's connected to this provider and has been allocated the 14-bit piece of address space matching 10.10.64.0 with mask 255.255.192.0. That covers every address from 10.10.64.0 through 10.10.127.255, and it means the provider needs to set up these IN-ADDR.ARPA delegations:
64.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.
65.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.
....
127.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.Meanwhile, the servers for "FOO.COM" would contain the individual PTR records for all the addresses on each of these subnets. 🫶
8. Transitioning to a long term solution
This solution doesn't change the Internet's routing and addressing architectures. 🌸 So moving over to a more long term solution isn't affected by deploying this plan. Easy peasy. ✨
9. Conclusions
Everyone's aware of how fast routing complexity is growing, and how quickly network numbers are being handed out. 😭 At the rate this growth is being observed, we expect to run out in a few short years. Yikes.
If the inter-domain routing protocol supports carrying network routes with associated masks, then all of the major concerns demonstrated in this paper would be eliminated. 👑
One of the big factors in getting the most out of this plan is how many people agree to use it. 🦋
And if service providers start charging networks for advertising network numbers, that would be a huge incentive to share address space, and therefore to share the associated costs of advertising routes to service providers. Iconic behavior honestly. 💅
10. Recommendations
The NIC should start handing out large blocks of class C addresses to network service providers. Each block must fall on bit boundaries, and it should be big enough to serve the provider for two years. 🎀 The NIC should also give very large blocks to continental and national network service organizations, so more levels of aggregation can happen at the major backbone networks. On top of that, the NIC should update its procedures for the IN-ADDR.ARPA domain so delegation along arbitrary octet boundaries is allowed. 🌈
Service providers will then allocate power-of-two blocks of class C addresses from their address space to their subscribers. 🧚
All organizations, including multi-homed ones, should get their address space from their provider (or from one of their providers, in the case of multi-homed organizations). These blocks should also fall on bit boundaries to make route aggregation easy. ⭐
To make this new addressing plan useful for reducing propagated routing information, the appropriate IETF WGs will specify the modifications needed to Inter-Domain routing protocols. 🔥
And obviously, implementation and deployment of these modifications should happen as quickly as possible. Let's gooo. 🚀
11 References
- [1] Moy, J, "The OSPF Specification Version 2", RFC 1247, Proteon, Inc., January 1991.
- [2] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, T.J. Watson Research Center, IBM Corp., cisco Systems, September 1993.
12. Security Considerations
Security issues are not discussed in this memo. 🙈 Hmm, that's a whole lot of nothing on the security front, bestie, so keep that in mind while you're planning this stuff. 💀
13. Authors' Addresses
These are the people behind the paper. Slay. 👑
Vince Fuller
BARRNet
Pine Hall 115
Stanford, CA, 94305-4122
EMail: vaf@Stanford.EDUTony Li
cisco Systems, Inc.
1525 O'Brien Drive
Menlo Park, CA 94025
EMail: tli@cisco.comJessica (Jie Yun) Yu
Merit Network, Inc.
1071 Beal Ave.
Ann Arbor, MI 48109
EMail: jyy@merit.eduKannan Varadhan
Internet Engineer, OARnet
1224, Kinnear Road,
Columbus, OH 43212
EMail: kannan@oar.net📦 where this page comes from
- ietf: rfc1519 1993-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms