/24 – The Internet’s Smallest Block
by Leo Vegoda
IPv4.GLOBAL’s marketplace and auction platform filters scores of open auctions in several ways. One is by block size where the smallest block is a /24 (256 IPv4 addresses). But why /24?
IPv4.Global Auction Platform showing the block-size filter
One answer is that this is the smallest block that some RIRs will transfer. But that doesn’t completely explain the rationale or history for why this is true. Underlying the transfer rules is the fact that it is very difficult to use anything smaller than a /24 on the internet. But why?
A Brief History
On January 1, 1983, the ARPANET switched from the Network Control Protocol (NCP) to TCP/IP, a date known as “flag day”. To understand the mindset of the engineers at this time it is important to remember that the network had on the order of 100 nodes. The concept of a LAN was brand new, with Ethernet becoming commercially available in 1980. It’s likely no one could even imagine the Internet of today.
RFC 791 is the initial addressing specification. Internet engineers cut the IPv4 space into three sizes of network.
- Big networks (Class A) had 16 million addresses
- Medium sized networks (Class B) had 65,536 addresses
- Small networks (Class C) had 256 addresses
IP addresses were distributed to networks in these three sizes only. The notion of these three address sizes was designed into additional protocols. The Exterior Gateway Protocol (EGP) was used at the time for global routing, and it only new how to deal with networks of these three sizes.
Over time the network started to grow. The next inflection point was the creation of the NSFNET in 1986 to create a general-purpose research network. A trend emerged, the research institutions were too large for a Class C, they all received Class B addresses. There started to be concern over the exhaustion of the Class B address space.
In parallel, the Border Gateway Protocol (BGP) was developed to replace EGP. Eventually BGP version 4 became the BGP we know today, able to route networks of any size. There was no longer a class dependency in the routing protocol.
Things rapidly changed in the early 1990s. Commercial use of the Internet began with many of these new commercial entities receiving Class C address blocks. These commercial entities often came back for more address space, as a Class C was small, and the Internet was starting to grow exponentially. This created a new concern, the size of the routing table.
Classless Inter-Domain Routing – CIDR
A proposal for a new approach came in 1993.
The new approach, known as Classless Inter-Domain Routing (aka CIDR) and offers more granularity. Engineers recognized that many different sizes of address block were needed, and that the old boundaries were arbitrary. With the new thinking, the boundary between “network” and “host” address could be placed at any bit in the 32 bit space:
This delivered three advantages.
- Addresses could be allocated in aggregations more appropriate to need. That is, less over-allocation would occur than happened by assigning a Class B where something between a Class C and a Class B was needed.
- The growth of routing entires in the global table would be reduced as a single right sized allocation could be made where previously disjoint Class C allocations would have been made.
- This thinking paved the way to variable length subnetting inside of individual networks. An entity receiving a /19 no longer had to assign one /24 per LAN, they could subdivide into anything from a /20 to a /32 as needed.
Motivations Change
The early Internet was a series of cooperating research intuitions. There was a collegial collective effort to make the network functional. The connection of commercial entities to the network began to change that dynamic in multiple ways. Commercial networks were driven by making money and keeping their customers happy. Newly minted “network engineers” focused on growth rather than cooperation, and on managing their very expensive bandwidth.
Traffic engineering began to result in large blocks being announced as /24s. Traffic for an organization’s addresses might not be spread evenly. One /24 could get a disproportionately heavy load. The network’s operator might want that heavy load to use one path and the rest of the traffic to use another. Although the organization had received a single large block via a CIDR allocation they were once again taking up many slots in the global table by routing it as individual /24 networks. This is called deaggregation. Keeping all addresses in a single announcement is called aggregation.
The example network ensures that most traffic for 10.31.8.0/24 comes from Upstream 2 telling it about the more specific – smaller – /24. The whole /19 network is announced to both upstreams.
The internet engineers who developed the CIDR strategy in 1993 described two benefits. One was that “more-appropriately sized blocks” could stave off depletion. The other was “an immediate decrease in the number [of] routing table entries”. The networks carrying traffic for those downstream networks need to have what internet engineers call the full ‘default free’ routing table. With the table size growing rapidly, as well as traffic increasing exponentially the equipment of the day was strained.
Network operators always encouraged each other to minimize the number of routes they advertise. This is because the cost of routes is paid for in router upgrades. Since the mid-1990s, engineers have been sharing a weekly CIDR Report. It showcases the networks that could reduce the size of the routing table by aggregating better.
AS7007 famously caused a major internet outage in 1997 when it leaked, or unintentionally deaggregated, 72,000 routes. Outages like this are a result of sudden, unplanned growth in routes exceeding the capabilities of deployed hardware. In some cases the network could not automatically recover, engineers would have to manually reset the routers to recover from these events.
Network operators also began to filter routing advertisements motivated both by limiting the growth of the table to extend the life of equipment, but also protecting themselves from these route leaking events. There were a wide range of approaches early on, but gradually some standard practices emerged. One practice was “nothing smaller than a /24”. That was the smallest unit allocated by RIRs at the time, and the feeling was no one needed to deaggregate intentionally or accidentally smaller than that size.
The early IPv4 distribution policies noted that conservation and routability are often “conflicting goals.” Traffic engineering could be added to that.
Regional Internet Registries
A full history of the Regional Internet Registries (aka RIRs) would be much longer than the history of the /24. It is important to understand that each of the RIRs developed some form of a “community consensus” approach to managing the address space. They each have a policy process guiding how IP address space is distributed and transferred.
Their history is intertwined with the technical history, and as a result the /24 boundary feature prominently in many RIR policies. The specific answer as to why an RIR does not allow smaller than a /24 to be transferred is that such a restriction is codified in their policies. Those policies in turn are a direct result of the path taken by the technical evolution of the Internet.
Current Practice
The /24 boundary comes not from any one decision, but a confluence of different decisions over time. The original choice of a Class C network at a /24 boundary was clearly an influence. The need to limit the size of the global table resulted in a /24 being seen as a reasonable cut off point. The need to protect the global routing system led to widespread deployments of filters at the /24 boundary.
Each Internet network is independent. There is no rule saying a network can’t advertise or accept longer prefixes. Today, Geoff Huston’s BGP Routing Table Analysis Report shows about 3,000 routes for blocks smaller than a /24. These tend to be short lived route leaks. At 0.3% of the whole routing table, these are not a problem. Most ISPs will filter these announcements and never see them. However, if two networks want to exchange more specific routing information they can, and sometimes do!