RFC 4632

Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan

📅 published August 2006, from ietf

RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan 🎀

Okay bestie, so this is RFC 4632, and it's a Best Current Practice (that's BCP 122 🌸). It's by V. Fuller from Cisco Systems and T. Li from Tropos Networks, dated August 2006. It obsoletes RFC 1519, so the original CIDR spec is officially retired and this one takes its place 👑. It doesn't list anything it updates.

Status of This Memo ✨

This document is an Internet Best Current Practice for the Internet Community, and it's basically asking everyone to talk about it and send in ideas for making it better 💬. Anyone can distribute it, with no limits 🦋.

Copyright (C) The Internet Society (2006).

Abstract 🌈

This memo is all about how we should hand out addresses in the existing 32-bit IPv4 address space, with two goals: conserve the space and slow down how fast the global routing state grows 🧚. It obsoletes the original CIDR spec in RFC 1519. The updates are there to clarify the ideas it introduced, and also to tell the community what happened after more than twelve years of actually using this tech 🔥.

Table of Contents 🍓

1. Introduction ....................................................3
2. History and Problem Description .................................3
3. Classless Addressing as a Solution ..............................4
   3.1. Basic Concept and Prefix Notation ..........................5
4. Address Assignment and Routing Aggregation ......................8
   4.1. Aggregation Efficiency and Limitations .....................8
   4.2. Distributed Assignment of Address Space ...................10
5. Routing Implementation Considerations ..........................11
   5.1. Rules for Route Advertisement .............................11
   5.2. How the Rules Work ........................................12
   5.3. A Note on Prefix Filter Formats ...........................13
   5.4. Responsibility for and Configuration of Aggregation .......13
   5.5. Route Propagation and Routing Protocol Considerations .....15
6. Example of New Address Assignments and Routing .................15
   6.1. Address Delegation ........................................15
   6.2. Routing Advertisements ....................................17
7. Domain Name Service Considerations .............................18
8. Transition to a Long-Term Solution .............................18
9. Analysis of CIDR's Effect on Global Routing State ..............19
10. Conclusions and Recommendations ...............................20
11. Status Updates to CIDR Documents ..............................21
12. Security Considerations .......................................23
13. Acknowledgements ..............................................24
14. References ....................................................25
   14.1. Normative References .....................................25
   14.2. Informative References ...................................25

1. Introduction ✨

Same vibe as the abstract, babe 💖: this memo covers how to assign addresses in the existing 32-bit IPv4 address space, so we conserve it and slow the growth of global routing state. This document obsoletes the original CIDR spec [RFC1519]. It has changes to clarify the concepts it introduced, and, after more than twelve years, it shares what we learned from actually deploying the technology 🎀.

2. History and Problem Description 🕰️

Okay, history lesson, but make it iconic 💅. The Internet started in the 1970s as a research project. The goal was a set of protocols that could run over lots of different network technologies and give a seamless, end-to-end way to connect a whole bunch of different end systems 🌍.

When people decided how the 32-bit address space would get used, they made assumptions about how many organizations would connect, how many end systems each one would have, and how many end systems there would be in total. The result was three classes of networks, set up in [RFC791] 🧩:

  • Class A, with the most significant address bits '00'. It had 128 possible networks, each with 16777216 end systems (minus the special bit values reserved for network and broadcast addresses).
  • Class B, with MSB '10'. It had 16384 possible networks, each with 65536 end systems (minus the reserved values).
  • Class C, with MSB '110'. It had 2097152 possible networks, each with 254 end systems (the 256 bit combinations minus the reserved all-zeros and all-ones patterns).

The set of addresses with MSB '111' was reserved for future use. Part of that eventually got defined (MSB '1110') for IPv4 multicast, and parts are still reserved as of when this document was written 🙈.

In the late 1980s, the former research network got expanded and commercialized, so lots of new organizations joined the fast-growing Internet, and each one needed an address assignment under the Class A/B/C plan 🚀. Demand for new network numbers, especially in the Class B space, grew at what looked like an exponential rate 📈. Some people in the operations and engineering community got worried about how well the Class A/B/C system would scale long-term. They started thinking about how to change network number assignment policy and routing protocols to handle the growth 😬.

In November, 1991, the Internet Engineering Task Force (IETF) created the ROAD (Routing and Addressing) group to look into it 🔍. The group met in January 1992 and identified three major problems:

  1. Exhaustion of the Class B network address space. One fundamental cause is that there's no network class the right size for mid-sized organizations. Class C, with a maximum of 254 host addresses, is too small. Class B, which allows up to 65534 host addresses, is too big for most organizations, but it was the best fit available for use with subnetting 🙃.
  2. Growth of routing tables in Internet routers beyond what current software, hardware, and people can effectively manage 😭.
  3. Eventual exhaustion of the 32-bit IPv4 address space.

It was clear that the then-current rates of Internet growth would make the first two problems critical sometime between 1993 and 1995 ⏰. Work already in progress on topological assignment of addressing for Connectionless Network Service (CLNS), presented to the community at the Boulder IETF in December of 1990, got people thinking about restructuring the 32-bit IPv4 address space to make it last longer 💡. Work in the ROAD group followed, and it eventually produced [RFC1338] and, later, [RFC1519] 📚.

The design and deployment of CIDR was meant to solve the first two problems by giving us a way to slow the growth of global routing tables and reduce how fast IPv4 address space gets used up 🎯. It did not try to solve the third problem, which is more long-term. Instead, it works to ease enough of the short- to mid-term difficulties so the Internet can keep running efficiently while we work on a longer-term solution 🫶.

More historical background on this effort and on the ROAD group can be found in [RFC1380] and at [LWRD] 🧚.

3. Classless Addressing as a Solution 💖

The community's answer was to deprecate the Class A/B/C network address assignment system and switch to "classless", hierarchical blocks of IP addresses, called prefixes 🎀. Prefix assignments are supposed to roughly follow the underlying Internet topology, so aggregation can help the global routing system scale 📊. One result of this approach is that prefix assignment and aggregation usually happen along provider-subscriber relationships, because that's how the Internet topology is determined 🌐.

When [RFC1338] and [RFC1519] first proposed this addressing plan, it was supposed to be a short-term fix lasting about three to five years. During that time, a more permanent addressing and routing architecture would get designed and built. Looking at the dates on those original documents, you can tell CIDR has far outlasted that expectation and become the mid-term solution to the problems above 😭✨.

Heads up, though: in the text that follows, we describe the current policies and procedures put in place to carry out the allocation architecture discussed here. That description is not meant to be read as direction to IANA 🙈.

Along with the address management strategies run by the Regional Internet Registries (see [NRO] for details), CIDR-style addressing has also slowed how fast IPv4 address space gets consumed. That gives us short- to medium-term relief from problem #3 above 🌸.

Also, as defined, this plan doesn't require or assume that the parts of the legacy "Class C" space that can't be aggregated (sometimes called "the swamp") get re-assigned 🐸. Doing that would shrink routing table sizes a bit (the current estimate is that "the swamp" holds about 15,000 entries), but the renumbering cost would be significant 💸. There's also no hard requirement that an end site renumbers when it changes transit service provider. End sites are encouraged to do it anyway, though, so they don't need explicit advertisement of their prefixes into the global routing system 🦋.

Part 2 is coming, bestie 🧚💅

3.1. Basic Concept and Prefix Notation 🎀

okay so the big idea is this: the switch from Class A/B/C to classless prefixes makes it explicit which bits of a 32-bit IPv4 address are the network number (the prefix) for a site, and which bits are used to number the individual end systems inside that site. 🧠✨ In CIDR notation, a prefix looks like a 4-octet address, just like a regular IPv4 address or network number, then a "/" (slash), then a decimal value from 0 to 32 that tells you how many significant bits there are. 💅

Let's look at examples, bestie 🦋. The legacy "Class B" network 172.16.0.0, with its implied network mask of 255.255.0.0, is written as the prefix 172.16.0.0/16. The "/16" means the mask that pulls out the network portion is a 32-bit value where the most significant 16 bits are ones and the least significant 16 bits are zeros. 🌸 Same vibe for the legacy "Class C" network 192.168.99.0, which becomes 192.168.99.0/24: the most significant 24 bits are ones and the least significant 8 bits are zeros. 💜

Using classless prefixes with explicit lengths unlocks way more flexible matching of address space to what people actually need. 🌈 Back when only three network sizes existed, prefixes can now describe any power-of-two-sized block containing between one and 2^32 end system addresses. Iconic. 👑 In practice, the unallocated pool of addresses is run by the Internet Assigned Numbers Authority ([IANA]). IANA hands out allocations from that pool to Regional Internet Registries as needed. ⭐ These allocations come in contiguous, bit-aligned blocks of 2^24 addresses (a.k.a. /8 prefixes). Then the Regional Internet Registries (RIRs) allocate or assign smaller blocks to Local Internet Registries (LIRs) or Internet Service Providers (ISPs). 🍓 Those entities might use the assignment directly (very common for an ISP), or they might sub-allocate addresses to their customers. The RIR assignments also vary depending on each ISP's or LIR's needs. For example, a large ISP might get a block of 2^17 addresses (a /15 prefix), while a smaller ISP might get a block of 2^11 addresses (a /21 prefix). 🫶

Quick terminology check, because these words have specific meanings in the Internet address registry system 🤓: "allocate" means handing a block of address space to an organization that's expected to do further sub-delegations, while "assign" is for sites that directly use the block by numbering individual hosts. Don't mix them up, periodt. 💀

Here's a handy shortcut table of all the CIDR prefix sizes, showing how many addresses fit in each prefix and how many prefixes of that size can fit in the 32-bit IPv4 address space. 🧚

    notation       addrs/block      # blocks
    --------       -----------     ----------
    n.n.n.n/32               1     4294967296    "host route"
    n.n.n.x/31               2     2147483648    "p2p link"
    n.n.n.x/30               4     1073741824
    n.n.n.x/29               8      536870912
    n.n.n.x/28              16      268435456
    n.n.n.x/27              32      134217728
    n.n.n.x/26              64       67108864
    n.n.n.x/25             128       33554432
    n.n.n.0/24             256       16777216    legacy "Class C"
    n.n.x.0/23             512        8388608
    n.n.x.0/22            1024        4194304
    n.n.x.0/21            2048        2097152
    n.n.x.0/20            4096        1048576
    n.n.x.0/19            8192         524288
    n.n.x.0/18           16384         262144
    n.n.x.0/17           32768         131072
    n.n.0.0/16           65536          65536    legacy "Class B"
    n.x.0.0/15          131072          32768
    n.x.0.0/14          262144          16384
    n.x.0.0/13          524288           8192
    n.x.0.0/12         1048576           4096
    n.x.0.0/11         2097152           2048
    n.x.0.0/10         4194304           1024
    n.x.0.0/9          8388608            512
    n.0.0.0/8         16777216            256    legacy "Class A"
    x.0.0.0/7         33554432            128
    x.0.0.0/6         67108864             64
    x.0.0.0/5        134217728             32
    x.0.0.0/4        268435456             16
    x.0.0.0/3        536870912              8
    x.0.0.0/2       1073741824              4
    x.0.0.0/1       2147483648              2
    0.0.0.0/0       4294967296              1    "default route"

Quick decoder ring 💖: n is an 8-bit decimal octet value. Point-to-point links get a deeper dive in [RFC3021]. ✨

x is a 1- to 7-bit value, based on the prefix length, shifted into the most significant bits of the octet and converted to decimal form. The least significant bits of that octet are zero. 🔥

Now, in practice, prefixes shorter than 8 bits haven't been allocated or assigned so far 🙈, although routes to those short prefixes might show up in routing tables if or when aggressive aggregation happens. As of writing this document, no such routes are seen in the global routing system. But operator error and other events have caused some of them (i.e., 128.0.0.0/1 and 192.0.0.0/2) to pop up in some networks at some times in the past. Oof. 😭

4. Address Assignment and Routing Aggregation ✨

Classless addressing and routing was first developed mainly to improve how routing scales on the global Internet. 🌍 Routing scaling is super tightly tied to how addresses get used, so deploying CIDR also changed how addresses got assigned. It's giving cause and effect. 💅

4.1. Aggregation Efficiency and Limitations 🦋

The only commonly understood way to reduce routing state on a packet-switched network is aggregation of information. 🧁 For CIDR to shrink and slow the growth of the global routing system, the IPv4 address assignment process had to change so that routing information could be aggregated along topological lines. Since the topology of the network is generally determined by the service providers who built it, topologically significant address assignments are necessarily service-provider oriented. 👑

Aggregation is simple for an end site connected to one service provider. 💖 It uses address space assigned by that provider, and that address space is a small piece of a larger block allocated to the provider. No explicit route is needed for the end site, because the provider advertises a single aggregate route for the larger block. That one advertisement gives reachability and routeability for all the customers numbered in the block. Easy. 🫶

There are two more complicated situations that weaken aggregation's effectiveness 🥺:

  • An organization that is multi-homed. A multi-homed organization has to be advertised into the system by each of its service providers, so it's often not feasible to aggregate its routing information into the address space of any single one of those providers. The organization may still receive its address assignment out of a service provider's address space (which has other advantages), but in the most general case, a route to the organization's prefix is explicitly advertised by all of its service providers. So the global routing cost for a multi-homed organization is generally the same as it was before CIDR was adopted. A more detailed look at multi-homing practices can be found in [RFC4116].
  • An organization that changes service provider but doesn't renumber. This "punches a hole" in one of the original service provider's aggregated route advertisements. CIDR handles this by requiring the newer service provider to advertise a specific route for the re-homed organization. That advertisement is preferred over the provider aggregates because it's a longer match. 🦄 To keep aggregation efficient, it is recommended that an organization changing service providers plan to eventually migrate its network into a prefix assigned from its new provider's address space. To make that migration easier, it is recommended that mechanisms like dynamic host address assignment using [RFC2131] be deployed wherever possible, and that additional protocol work be done to develop better renumbering technology. 🛠️

Note that some aggregation efficiency can still be gained for multi-homed sites (and, in general, for any site made up of multiple logical IPv4 networks). 🌈 By allocating a contiguous, power-of-two block of address space to the site (instead of multiple independent prefixes), the site's routing information can be aggregated into a single prefix. Also, since the routing cost of assigning a multi-homed site out of a service provider's address space is no greater than the old method of sequential number assignment by a central authority, it makes sense to assign all end-site address space out of blocks allocated to service providers. 💅

It's also worth mentioning that aggregation can happen at multiple levels of the system, so it may still be possible to aggregate these anomalous routes at higher levels of whatever hierarchy exists. ⭐ For example, if a site is multi-homed to two relatively small providers that both get connectivity and address space from the same large provider, then the large provider's aggregation of routes from the smaller networks will include all routes to the multi-homed site. Slay. 👑 Whether this second-level aggregation is feasible depends on whether topological hierarchy exists among a site, its directly connected providers, and other providers they connect to. It may be practical in some regions of the global Internet but not in others. 🌸

Note: In the discussion and examples that follow, prefix notation is used to represent routing destinations. This is used for illustration only and does not require that routing protocols use this representation in their updates. 🙈

4.2. Distributed Assignment of Address Space ✨

okay so back in the early days of the Internet, IPv4 address space was handed out by one central Network Information Center (NIC) 🏢. Class A/B/C network numbers were given out in basically random order, kinda based on how big the organization was 🙈. Every single assignment got recorded in one central place, and nobody tried to hand out network numbers in a way that would let routing aggregation work 💀.

When CIDR first rolled out, the central authority was still around, but it switched things up and started giving big chunks of "Class C" network numbers to each service provider 🎀. Then each service provider split its space into bitmask-shaped pieces and gave those to its customers. This worked pretty well as long as there were only a few service providers and that number stayed steady, but it didn't scale well once the number of providers started growing super fast 📈.

As the Internet blew up in the 1990s, it became super clear that one single, centralized address assignment authority was a problem 😭. This started getting decentralized when address space for European Internet sites was delegated in bit-aligned blocks of 16777216 addresses (what CIDR would later call a /8) to the RIPE NCC ([RIPE]), which basically made it the first of the RIRs 🌍. Ever since then, address assignment has been formally distributed as a hierarchical function across IANA, the RIRs, and the service providers 👑. Getting rid of the bottleneck of one organization being in charge of the whole global Internet address space made new assignments way more efficient and way faster to get back 🚀.

Hierarchical delegation like this means that sites with addresses assigned out of a given service provider are, for routing purposes, part of that service provider and will be routed via its infrastructure 🧚. That also means routing information about multi-homed organizations (i.e., organizations connected to more than one network service provider) will still need to be known by higher levels in the hierarchy 💅.

If you want the history tea on all this, [RFC1518] has a historical perspective on these issues. [RFC3221] has even more discussion too 📚.

5. Routing Implementation Considerations 🛣️

okay so once we switched from classful network numbers to classless prefixes, you can't figure out the network mask just by looking at the first bits of an IPv4 address anymore 🫠. That changes how routing information gets stored and passed around. Network masks or prefix lengths must be explicitly carried in routing protocols. The interior routing protocols like OSPF [RFC2328], Intermediate System to Intermediate System (IS-IS) [RFC1195], RIPv2 [RFC2453], and Cisco Enhanced Interior Gateway Routing Protocol (EIGRP), plus the BGP4 exterior routing protocol [RFC4271], all support this. They got developed or modified during the 1990s as CIDR was being deployed, so they're totally giving "built for this" 💖.

Older interior routing protocols, like RIP [RFC1058], HELLO, and Cisco Interior Gateway Routing Protocol (IGRP), and older exterior routing protocols, like Exterior Gateway Protocol (EGP) [RFC904], don't support explicitly carrying prefix length or mask. So they can't really be used on the Internet outside of very limited stub configurations 😬. They might still be fine in simple legacy end-site setups, but they're considered obsolete, and they SHOULD NOT be used in transit networks connected to the global Internet 🚫.

Routing and forwarding tables in layer-3 network equipment also have to store both the prefix and the prefix length or mask 🧠. Gear that organizes its routing/forwarding info by the legacy Class A/B/C network/subnet rules can't be expected to work correctly on networks connected to the global Internet, so using that kind of equipment is not recommended 🙅. Luckily, very little of that equipment is still in use today 🥹.

5.1. Rules for Route Advertisement 📜

  1. Forwarding in the Internet is done on a longest-match basis. This implies that destinations that are multi-homed relative to a routing domain must always be explicitly announced into that routing domain (i.e., they cannot be summarized). If a network is multi-homed, all of its paths into a routing domain that is "higher" in the hierarchy of networks must be known to the "higher" network).
  2. A router that generates an aggregate route for multiple, more-specific routes must discard packets that match the aggregate route, but not any of the more-specific routes. In other words, the "next hop" for the aggregate route should be the null destination. This is necessary to prevent forwarding loops when some addresses covered by the aggregate are not reachable.

Okay, now the important bit 🚨. During failures, some traffic can end up getting partially routed to a site that takes its address space from one service provider but is actually only reachable through another one (basically a site that switched service providers). This can happen because that traffic gets forwarded along the path advertised by the aggregated route 😵‍💫. Rule #2 stops packets from getting misdelivered by making the advertiser of the aggregated route discard that traffic. But the output of "traceroute" and other similar tools will make it look like the problem is inside that network, not in the network that stopped advertising the more-specific prefix 👀. That can be really confusing when you're trying to debug connectivity problems, so check out the example in Section 6.2 for the full details 🔍. Fixing this perceived "problem" is beyond the scope of this document. It's really about better education for the user/operator community, not routing technology 🎓.

An implementation following these rules should also be generalized, so an arbitrary network number and mask get accepted for all routing destinations 🌈. The only constraint left is that the mask must be left contiguous. Also, the degenerate route to prefix 0.0.0.0/0 is used as a default route and MUST be accepted by all implementations 💜. To protect against accidentally advertising this route through the inter-domain protocol, this route should only be advertised to another routing domain when a router is explicitly configured to do so, never as a non-configured, "default" option 🛡️.

5.2. How the Rules Work 🧩

Rule #1 guarantees that the forwarding algorithm is consistent across routing protocols and implementations ✨. 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're not, they clearly must be explicitly advertised.) It might seem like the "primary" service provider could advertise the multi-homed site implicitly as part of its aggregate, but longest-match forwarding makes that not work 🙃. More details are in [RFC4116].

Rule #2 guarantees that no routing loops form because of aggregation 🔁. Picture a site that's been assigned 192.168.64/19 by its "parent" provider, which has 192.168.0.0/16. The "parent" network will advertise 192.168.0.0/16 to the "child" network. If the "child" network were to lose internal connectivity to 192.168.65.0/24 (which is part of its aggregate), traffic from the "parent" to the to the "child" destined for 192.168.65.1 will follow the "child's" advertised route. When that traffic gets to the "child", though, the child must not follow the route 192.168.0.0/16 back up to the "parent", because that would create a forwarding loop 😱. Rule #2 says the "child" may not follow a less-specific route for a destination that matches one of its own aggregated routes. Typically, this is done by installing a "discard" or "null" route for all aggregated prefixes that one network advertises to another 🗑️. Also, handling the "default" route (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 aggregated advertisements 💅.

5.3. A Note on Prefix Filter Formats 🎀

Systems that process route announcements have to be able to verify that the information they receive is acceptable according to policy rules 🔐. Implementations that filter route advertisements must allow masks or prefix lengths in filter elements. So filter elements that used to look like this:

   accept 172.16.0.0
   accept 172.25.120.0.0
   accept 172.31.0.0
   deny 10.2.0.0
   accept 10.0.0.0

now look something like this:

   accept 172.16.0.0/16
   accept 172.25.0.0/16
   accept 172.31.0.0/16
   deny 10.2.0.0/16
   accept 10.0.0.0/8

This is just making explicit the network mask that was implied by the Class A/B/C classification of network numbers 📝. It's also useful for boosting filtering capability so you can match a prefix and all of its more-specific prefixes with the same bit pattern. Good news: most vendors of equipment used on the Internet have already implemented this functionality 🥳.

5.4. Responsibility for and Configuration of Aggregation 💅

Okay bestie, so normally a routing domain (an "Autonomous System") that has been given a set of prefixes is the only one responsible for aggregating them 🫶 Usually the AS sets up one or more of its routers to create aggregate routes from the more-specific routes its internal routing system already knows. Those aggregates get advertised into the global routing system by the domain's border routers. The more-specific internal routes that overlap with the aggregates should not be advertised globally 🌸

Sometimes an AS wants to hand off aggregation to another AS. A customer might want its service provider to generate aggregated routing info for it, for example ✨ In that case, a router in the second AS does the aggregation, based on the routes it gets from the first AS, plus configured policy that says how those routes should be aggregated. It's giving teamwork 🎀

Here's the tea: one provider can aggregate the routes it receives from another without any explicit agreement. This is called "proxy aggregation" 👀 It can be super useful for cutting down how much routing state an AS has to carry and pass along to its customers and neighbors. BUT it can also cause weird traffic engineering consequences 😭 Picture this: AS 2 and AS 3 both get routes from AS 1, but AS 2 does proxy aggregation and AS 3 doesn't. Other ASes that get transit routing info from both AS 2 and AS 3 will see an inconsistent view of the routes AS 1 originated. That can cause an unexpected shift of traffic toward AS 1 through AS 3, for AS 3's customers and anyone else receiving transit routes from AS 3. Since proxy aggregation can cause unplanned chaos for parts of the Internet that have no connection to either the source of the routes or the provider doing the aggregating, it should be used with extreme caution 🙈

Proxy aggregation is a total wildcard. Please be careful with it, it can ripple out to networks that had nothing to do with it 💀

Setting up which routes get combined into aggregates is an implementation of routing policy, and it needs some manually maintained info. On top of the info you already keep for your routeable prefixes, aggregation config is usually just a line or two that defines the range of the IPv4 address block to be aggregated 🍓 A site doing its own aggregation is working with address blocks it was assigned. A site aggregating on behalf of someone else knows the info because of a delegation agreement. Assuming the best common practice for network admins is to swap lists of prefixes to accept from each other, setting up aggregation info doesn't add a ton of admin overhead. Low-key an easy win 💖

The generation of an aggregate route is usually specified either statically, or in response to learning an active dynamic route for a prefix inside that aggregate. If you do dynamic aggregate advertisement, be careful that routes aren't excessively added or withdrawn. That's called "route flapping," and it's a real mood-killer 😩 In general, a dynamic aggregate is added when at least one component of the aggregate becomes reachable, and it's only withdrawn when all of the components become unreachable. When it's configured properly, aggregated routes are more stable than non-aggregated routes, which means they improve global routing stability ✨

Implementation note: Aggregation of the "Class D" (multicast) address space is beyond the scope of this document. 🦋

5.5. Route Propagation and Routing Protocol Considerations 🧚

Before CIDR was originally deployed, the common practice was to propagate routes learned via exterior routing protocols (that's EGP or BGP) through a site's interior routing protocol (typically OSPF, IS-IS, or RIP). The point was to make sure consistent and correct exit points got picked for traffic going to a destination learned through those protocols 🗺️

But four evolutionary effects have basically retired that practice 💀 Those are: the arrival of CIDR, explosive growth of global routing state, the widespread adoption of BGP4, and a requirement to propagate full path information. To make sure paths propagate properly and to prevent inter-AS routing inconsistency (BGP4's loop detection and prevention mechanism needs full path propagation), transit networks must use internal BGP (iBGP) to carry routes learned from other providers, both within their networks and through them 💜

6. Example of New Address Assignments and Routing 👑

6.1. Address Delegation 🎀

Let's look at a block of 524288 (2^19) addresses, starting at 10.24.0.0 and ending at 10.31.255.255. It's allocated to one network provider, "PA". That's the same size as a block of 2048 legacy "Class C" network numbers (or /24s) 🌈 A classless route to this block would be written as 10.24.0.0 with a mask of 255.248.0.0, or as the prefix 10.24.0.0/13.

Now assume this service provider connects six sites, in this order. The order matters because it shows how temporary "holes" can form in the provider's address space 🕳️

  • "C1", requiring fewer than 2048 addresses (/21 or 8 x /24)
  • "C2", requiring fewer than 4096 addresses (/20 or 16 x /24)
  • "C3", requiring fewer than 1024 addresses (/22 or 4 x /24)
  • "C4", requiring fewer than 1024 addresses (/22 or 4 x /24)
  • "C5", requiring fewer than 512 addresses (/23 or 2 x /24)
  • "C6", requiring fewer than 512 addresses (/23 or 2 x /24)

In every case, the number of IPv4 addresses "required" by each site is assumed to allow for significant growth 🌱 Here's how the service provider delegates its address space:

  • C1. Assign 10.24.0 through 10.24.7. This block of networks is described by the route 10.24.0.0/21 (mask 255.255.248.0).
  • C2. Assign 10.24.16 through 10.24.31. This block is described by the route 10.24.16.0/20 (mask 255.255.240.0).
  • C3. Assign 10.24.8 through 10.24.11. This block is described by the route 10.24.8.0/22 (mask 255.255.252.0).
  • C4. Assign 10.24.12 through 10.24.15. This block is described by the route 10.24.12.0/22 (mask 255.255.252.0).
  • C5. Assign 10.24.32 and 10.24.33. This block is described by the route 10.24.32.0/23 (mask 255.255.254.0).
  • C6. Assign 10.24.34 and 10.24.35. This block is described by the route 10.24.34.0/23 (mask 255.255.254.0).

These six sites should be represented as six prefixes of varying size within the provider's IGP 🧩 If, for some reason, the provider is using an obsolete IGP that doesn't support classless routing or variable-length subnets, then explicit routes for all /24s will have to be carried. Yikes 😭

To make this more realistic, let's say C4 and C5 are multi-homed through another service provider, "PB". Also, there's a site called "C7" that was originally connected to "RB" but has since moved to "PA". Because of that, it has a block of network numbers that's assigned out of PB's block of (the next) 2048 x /24 🔄

  • C7. Assign 10.32.0 through 10.32.15. This block is described by the route 10.32.0.0/20 (mask 255.255.240.0).

For the multi-homed sites, C4 is advertised as primary via "RA" and secondary via "RB". C5 is primary via "RB" and secondary via "RA" 🔀 Also, "RA" and "RB" are both connected to the same transit service provider, "BB".

Here's a picture of what this topology looks like:

10.24.0.0 -- 10.24.7.0__         __10.32.0.0 - 10.32.15.0
C1: 10.24.0.0/21        \       /  C7: 10.32.0.0/20
                         \     /
                          +----+                              +----+
10.24.16.0 - 10.24.31.0_  |    |                              |    |
C2: 10.24.16.0/20       \ |    |  _10.24.12.0 - 10.24.15.0__  |    |
                         \|    | / C4: 10.24.12.0/20        \ |    |
                          |    |/                            \|    |
10.24.8.0 - 10.24.11.0___/| PA |\                             | PB |
C3: 10.24.8.0/22          |    | \__10.24.32.0 - 10.24.33.0___|    |
                          |    |    C5: 10.24.32.0/23         |    |
                          |    |                              |    |
10.24.34.0 - 10.24.35.0__/|    |                              |    |
C6: 10.24.34.0/23         |    |                              |    |
                          +----+                              +----+
                            ||                                  ||
routing advertisements:     ||                                  ||
                            ||                                  ||
        10.24.12.0/22 (C4)  ||              10.24.12.0/22 (C4)  ||
        10.32.0.0/20 (C7)   ||              10.24.32.0/23 (C5)  ||
        10.24.0.0/13 (PA)   ||              10.32.0.0/13 (PB)   ||
                            ||                                  ||
                            VV                                  VV
                  +---------- BACKBONE NETWORK BB ----------+

6.2. Routing Advertisements 📣

To follow rule #1, PA needs to advertise the block of addresses it was given, plus C7. Since C4 is multi-homed and primary through PA, it must also be advertised. C5 is multi-homed and primary through PB. In principle (and in the example above), it need not be advertised, since longest match by PB will automatically select PB as primary, and the advertisement of PA's aggregate will be used as a secondary. In actual practice, though, C5 will normally be advertised via both providers 🤷‍♀️

Advertisements from "PA" to "BB" will be:

10.24.12.0/22 primary    (advertises C4)
10.32.0.0/20 primary     (advertises C7)
10.24.0.0/13 primary     (advertises remainder of PA)

For PB, the advertisements must also include C4 and C5, as well as its block of addresses 💅

Advertisements from "PB" to "BB" will be:

10.24.12.0/22 secondary  (advertises C4)
10.24.32.0/23 primary    (advertises C5)
10.32.0.0/13 primary     (advertises remainder of RB)

To illustrate the problem diagnosis issue mentioned in Section 5.1, consider what happens if PA loses connectivity to C7 (the site assigned out of PB's space). In a stateful protocol, PA will announce to BB that 10.32.0.0/20 has become unreachable. Now, when BB flushes this info out of its routing table, any future traffic sent through it for this destination will be forwarded to PB (where it will be dropped according to Rule #2) because of PB's less-specific match, 10.32.0.0/13. 😵‍💫 Although this doesn't cause an operational problem (C7 is unreachable anyway), it does create some extra traffic across "BB". It may also be super confusing for someone trying to debug the outage with "traceroute". A mechanism to cache such unreachable state might be nice, but it's beyond the scope of this document 🧃

7. Domain Name Service Considerations 🌐✨

Okay bestie, so the move to CIDR totally shook up address-to-name translation 😭 The zone at the center of it is IN-ADDR.ARPA, the part of the domain system that handles address-to-name lookups. It only gets delegated on octet boundaries, so switching to bitmask-oriented address assignment meant extra work for anyone maintaining parts of IN-ADDR.ARPA. Not gonna lie, that's a lot of tedious admin 💀

If you need techniques for populating IN-ADDR.ARPA when used address blocks don't line up with octet boundaries, they're described in [RFC2317] 🧚

8. Transition to a Long-Term Solution 🦋

CIDR was never meant to be the forever answer 💖 It was designed as a short-term fix for routing state and address depletion on the IPv4 Internet. It doesn't change the fundamental Internet routing or addressing architectures at all. It isn't expected to mess with any plans for transitioning to a more long-term solution, except maybe by making the urgency of building that solution feel a little less intense 🫶

9. Analysis of CIDR's Effect on Global Routing State 📈

Okay, time for the glow-up data 📊 When CIDR was first proposed in the early 1990s, the original authors looked at how fast global routing state was growing and projected that CIDR deployment would, hopefully, turn what looked like exponential growth into a more sustainable rate. Since then, an ongoing effort called "The CIDR Report" [CRPT] has been quantifying and tracking that growth. What follows is a quick summary of the CIDR Report as of March 2005, plus an attempt to explain the different patterns and changes in growth rate since measurements of global routing state began in 1988 🔥

When you look at the graph of "Active BGP Table Entries" [CBGP], there seem to be several different growth trends with distinct inflection points, each reflecting changes in policy and practice. Here's the tea on the trends and the events believed to have caused them ☕

  1. Exponential growth at the far left of the graph. This is the period of early expansion and commercialization of the former research network, from the late 1980s through about 1994 🌱 The main driver was a lack of aggregation capability for transit providers, plus the widespread use of legacy Class C allocations for end sites. Every time a new site connected to the global Internet, one or more new routing entries got generated.
  2. Acceleration of the exponential trend in late 1993 and early 1994. This happened as CIDR "supernet" blocks were first assigned by the NIC and routed as separate legacy class-C networks by service providers 🙈
  3. A sharp drop in 1994. BGP4 deployment by providers allowed the "supernet" blocks to be aggregated 🎉 Fun fact: the biggest drops in routing table entries typically line up with the weeks right after each meeting of the IETF CIDR Deployment Working Group 🍓
  4. Roughly linear growth from mid-1994 to early 1999. CIDR-based address assignments were made and aggregated routes were added throughout the network 📏
  5. A new period of exponential growth from early 1999 until 2001. The "high-tech bubble" fueled both rapid expansion of the Internet and a big jump in more-specific route advertisements for multi-homing and traffic engineering 🚀
  6. Flattening of growth through 2001. This came from a combo of the "dot-com bust", which made lots of organizations stop operating, and the "CIDR police" [CPOL] work aimed at improving aggregation efficiency 👮‍♀️
  7. Roughly linear growth through 2002 and 2003. This most likely shows a return to the "normal" growth rate seen before the "bubble", plus the end of the "CIDR Police" effort 🧘‍♀️
  8. A more recent trend of exponential growth beginning in 2004. The best explanation seems to be an improving global economy driving more Internet expansion, combined with the continued absence of the "CIDR Police" effort. That effort had been acting as an educational tool for new providers to improve aggregation efficiency 📚 There have also been cases where service providers deliberately de-aggregated prefixes to try to mitigate security problems caused by conflicting route advertisements (see Section 12) 😬 Sure, that might fix things short-term for those providers, but it's fundamentally non-scalable and really detrimental to the community as a whole 💀 On top of that, many providers seem to be advertising both their allocated prefixes and all the /24 components inside them, probably because there's no consistent current information about recommended routing configuration 🤷‍♀️

10. Conclusions and Recommendations 🌸

Let's talk about the big picture 💜 In 1992, when CIDR was first developed, the Internet was facing serious problems. Growth in routing state complexity and the rapid consumption of address space made it look like one or both would stop continued growth of the Internet within a few short years 😱

Deploying CIDR, together with BGP4's support for carrying classless prefix routes, eased the short-term crisis ✨ That only happened because equipment manufacturers and the provider community made a concerted effort together 🫶 The threat of charging networks for advertising prefixes (and, in some cases, actually doing it) may have given an extra push to share address space, and therefore to share the costs of advertising routes to service providers 💸

The IPv4 routing system architecture carries topology information based on aggregate address advertisements, plus a collection of more-specific advertisements tied to traffic engineering, multi-homing, and local configuration 🗺️ As of March 2005, the base aggregate address load in the routing system had some 75,000 entries 📦

There are about 85,000 additional entries that are more specific entries of this base "root" collection 😳 There's reason to believe many of these extra entries exist to solve problems of regional or even local scope, and they shouldn't need to be globally propagated 🌍

So, can CIDR keep being a viable approach to keeping global routing state growth and address space depletion at sustainable rates? Recent measurements show exponential growth has resumed, but further analysis suggests this trend can be mitigated by a more active effort to educate service providers on efficient aggregation strategies and proper equipment configuration 📣 Looking further ahead, there's a clear need for better multi-homing technology that doesn't require global routing state for each site, and for methods of traffic load balancing that don't require adding even more state ⭐ Without those developments, and without major architectural change, aggregation is the only tool available for making routing scale in the global Internet 🔥

11. Status Updates to CIDR Documents 💅

Time for some cleanup 🧹 This memo makes the following RFCs obsolete and requests that they be re-classified as Historic. They all describe CIDR usage and deployment 🫧

  • RFC 1467: Status of CIDR Deployment in the Internet This Informational RFC described the status of CIDR deployment in 1993. As of 2005, CIDR has been thoroughly deployed, so this status note just gives a historical data point 📜
  • RFC 1481: IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling This very short Informational RFC described the IAB's endorsement of using CIDR to address scaling issues. Because the goal of RFC 1481 has been achieved, it's now only of historical value 🏛️
  • RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing Database This Informational RFC described plans for supporting route aggregation, as specified by CIDR, on the NSFNET. Since the NSFNET has long since ceased to exist and CIDR is ubiquitously deployed, RFC 1482 now only has historical relevance 🕰️
  • RFC 1517: Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) This Standards Track RFC described where CIDR was expected to be required and where it was expected to be (strongly) recommended. With CIDR fully deployed on the Internet, situations where CIDR isn't required are only of historical interest 🎀
  • RFC 1518: An Architecture for IP Address Allocation with CIDR This Standards Track RFC discussed routing and address aggregation considerations at some length. Some of these issues are summarized in this document in Section 3.1. Because address assignment policies and procedures now mainly live with the RIRs, it isn't appropriate to try to document those practices in a Standards Track RFC. Also, [RFC3221] describes many of the same issues from the point of view of the routing system 🧩
  • RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment This Informational RFC described transition scenarios where CIDR wasn't fully supported for exchanging route information between providers. With CIDR fully deployed, those scenarios are no longer operationally relevant 🙌
  • RFC 1817: CIDR and Classful Routing This Informational RFC described the implications of CIDR deployment in 1995. It notes that formerly-classful addresses were to be allocated using CIDR mechanisms, and it describes the use of a default route for non-CIDR-aware sites. With CIDR fully deployed, those scenarios are no longer operationally relevant 🌈
  • RFC 1878: Variable Length Subnet Table For IPv4 This Informational RFC provided a table of pre-calculated subnet masks and address counts for each subnet size. Since a similar table is incorporated into this document (see Section 3.1), it's no longer necessary to document it in a separate RFC 🌸
  • RFC 2036: Observations on the use of Components of the Class A Address Space within the Internet This Informational RFC described several operational issues associated with allocating classless prefixes from previously-classful address space. With CIDR fully deployed and more than half a dozen years of experience making classless prefix allocations out of historical "Class A" address space, this RFC now has only historical value 🦋

12. Security Considerations 🔐

okay bestie, security time, and this part is seriously important 😭 Moving to longest-match routing and classless prefixes introduces at least two security concerns:

  1. Traffic hijacking 🕵️‍♀️ Someone can advertise a prefix that is more specific than the aggregate normally advertised for a destination. Say a popular end system at 192.168.17.100 is connected to a provider that advertises 192.168.16.0/20. A malicious operator who wants to intercept that site's traffic might advertise, or at least try to advertise, 192.168.17.0/24 into the global routing system. Because that prefix is more specific than the "normal" one, traffic gets diverted away from the legitimate end system and over to the malicious operator's network. Before CIDR, you could already pull traffic from some parts of the network onto a false advertisement that matched a network number exactly, but CIDR makes it somewhat worse, since longest-match routing generally makes all traffic prefer the more-specific routes. The fix for a CIDR-based attack is the same as for a pre-CIDR one: trust relationships between providers, plus strong route policy filters at provider borders. The catch is that filters like that are hard to implement in the highly de-centralized Internet. As a workaround, lots of providers use generic filters that set upper bounds on the prefix lengths they accept from other providers, with the bounds derived from RIR guidelines for the sizes of blocks they allocate. Also, spammers have been seen using this exact trick to hijack address space temporarily and hide where their "spam" emails are coming from 💀
  2. Denial-of-service attacks 💥 Advertising a huge number of routes into the system can take down parts of the Internet infrastructure, because it overflows routing and forwarding tables. A non-malicious example of this kind of failure was the infamous "AS 7007" event [7007], where an operator's router misconfiguration caused a massive number of invalid routes to spread through the global routing system. Again, this isn't brand new with CIDR. Using legacy Class A/B/C routes, you could advertise a maximum of 16843008 unique network numbers into the global routing system, which is enough to cause problems even for the most modern routing equipment made in 2005. What's different is that correctly configuring routers in the presence of CIDR is moderately complex, which makes accidental "attacks" of this sort more likely. The measures for preventing this are pretty much the same as the ones for hijacking above, plus the best common practice of configuring a reasonable maximum number of prefixes that a border router will accept from its neighbors 🛡️
⚠️ This is not meant to be an exhaustive list of the attacks CIDR makes easier. A more thorough look at security vulnerabilities in the global routing system is out of scope for this document.

13. Acknowledgements 🫶

The authors want to thank the other original authors of RFC 1519, Kannan Varadhan and Jessica Yu 💜 They also thank the ROAD group, whose work inspired and shaped a lot of the ideas behind CIDR ✨ And they thank the early reviewers of this re-spun version of the document: Barry Greene, Danny McPherson, Dave Meyer, Eliot Lear, Bill Norton, Ted Seely, Philip Smith, and Pekka Savola. Their comments, corrections, and suggestions were invaluable 🙌 Special shout-out to Geoff Huston for contributions way above and beyond the call of duty 👑

14. References 📚

14.1. Normative References

  • [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

14.2. Informative References

Authors' Addresses 📬

Vince Fuller
170 W. Tasman Drive
San Jose, CA  95134
USA

EMail: vaf@cisco.com


Tony Li
555 Del Rey Avenue
Sunnyvale, CA 94085

Email: tli@tropos.com

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌸

📦 where this page comes from