Supernetting: Address Aggregation

Imagine you're a core Internet router in the early 1990s. Your job seems straightforward: maintain a table of destination networks and forward packets accordingly. But there's a looming crisis: the routing table is growing exponentially.\n\nEvery time an organization gets assigned a new network, you need another entry. By 1992, Internet backbone routers were drowning under the weight of increasingly massive routing tables. Memory was expensive, lookup times were slowing, and projections indicated a complete collapse of the routing infrastructure within years.\n\nThe solution wasn't to build bigger routers—it was to fundamentally rethink how we represent network addresses. Instead of treating each network as a separate entity, what if we could combine multiple networks into a single, summarized entry? This revolutionary concept is called address aggregation, and it saved the Internet from routing infrastructure collapse.

To appreciate why address aggregation matters, we must first understand the routing scalability crisis that nearly brought down the Internet.\n\nThe Classful Addressing Disaster:\n\nIn the original classful addressing system, organizations received entire Class A, B, or C networks. Each allocated network required a separate routing table entry in every core router. The problems were twofold:\n\n1. Address Waste: A company needing 500 addresses would get a Class B (65,534 addresses), wasting over 65,000. A company needing 2 addresses would get a Class C (254 addresses), wasting over 250.\n\n2. Routing Table Explosion: If a large organization received multiple Class C networks to meet their needs, each Class C required a separate route. The number of routes grew dramatically with no natural aggregation boundary.

Notice the dramatic shift in growth rate after CIDR (Classless Inter-Domain Routing) and address aggregation were deployed in 1993-1994. The annual growth rate dropped from 80%+ to under 30%, even as Internet adoption accelerated exponentially. This wasn't because fewer networks were being added—it was because aggregation allowed multiple networks to share a single routing entry.

Address aggregation (also called route aggregation, route summarization, or supernetting) is the process of combining multiple contiguous network addresses into a single, encompassing network prefix. Instead of advertising each network individually, we advertise one larger network that includes all of them.\n\nThe Core Insight:\n\nConsider four consecutive Class C networks:\n- 192.168.0.0/24 (192.168.0.0 – 192.168.0.255)\n- 192.168.1.0/24 (192.168.1.0 – 192.168.1.255)\n- 192.168.2.0/24 (192.168.2.0 – 192.168.2.255)\n- 192.168.3.0/24 (192.168.3.0 – 192.168.3.255)\n\nWithout aggregation, upstream routers need four routing table entries—one for each /24 network. But notice that all four networks share the same first 22 bits. By advertising 192.168.0.0/22, we describe the same address space with a single routing entry.

The Mathematical Foundation:\n\nAggregation works because IP addresses are hierarchical binary numbers. When contiguous networks share a common prefix, that prefix can represent all of them. The key requirements are:\n\n1. Contiguity: Networks must be numerically adjacent (no gaps)\n2. Alignment: The aggregate must start at a valid network boundary\n3. Power of Two: The number of networks combined must be a power of 2 (2, 4, 8, 16, ...)\n\nThese constraints ensure the aggregate can be expressed as a single prefix/mask pair.

To truly understand aggregation, we must examine how it works at the binary level. Let's walk through combining our four Class C networks step by step.\n\nStep 1: Convert to Binary

Step 2: Identify the Common Prefix\n\nBy examining the binary representations, we find that the first 22 bits are identical across all four networks. The last two bits of the third octet (positions 23 and 24) vary: 00, 01, 10, 11. These four values cover all possible combinations of 2 bits—which is why exactly 4 networks can be aggregated here.\n\nStep 3: Create the Supernet\n\nThe supernet address uses the common 22-bit prefix with all remaining bits set to zero:

Address aggregation isn't a one-time operation—it's designed to work hierarchically across the entire Internet routing infrastructure. Each level of the network hierarchy aggregates addresses before passing routing information upstream.\n\nThe Hierarchical Model:

How Hierarchical Aggregation Works:\n\n1. End Sites: Individual subnets exist within an organization (/26, /27, /28, etc.)\n2. Campus/Building Level: Aggregates departmental subnets into building or campus blocks (/24)\n3. Enterprise Edge: Aggregates all campus blocks into the organization's entire address allocation (/22 or larger)\n4. ISP Level: Aggregates customer address blocks into provider-level allocations (/16 or larger)\n5. Internet Core: Aggregates ISP blocks into regional allocations from Regional Internet Registries (/8 or larger)\n\nThe Routing Information Reduction:\n\nAt each step upstream, the number of routing table entries potentially decreases. A core router doesn't need to know about every /28 subnet in a corporation—it only needs to know that 192.168.0.0/16 is reachable via a particular path.

Address aggregation provides multiple interconnected benefits that extend far beyond simple routing table size reduction. Understanding these benefits reveals why aggregation is fundamental to Internet architecture.

Address aggregation isn't just a historical solution to a past crisis—it's an ongoing architectural principle that shapes how IP addresses are allocated, announced, and managed globally.\n\nRegional Internet Registry (RIR) Allocation Model:\n\nThe five RIRs (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) allocate address blocks in aggregatable sizes to ISPs and large organizations. These allocations follow geographical and topological boundaries specifically designed to enable aggregation.

Provider-Independent vs. Provider-Aggregatable Addresses:\n\n- Provider-Aggregatable (PA): Addresses assigned from an ISP's block. When the customer connects through that ISP, addresses aggregate naturally. If the customer changes ISPs, addresses must change (disruption).\n\n- Provider-Independent (PI): Addresses assigned directly from an RIR. The customer keeps addresses regardless of ISP, but these addresses often cannot aggregate with the ISP's block, requiring a separate routing table entry globally.\n\nThis tension between aggregatability and address portability is ongoing. PI addresses provide stability for organizations but contribute to routing table growth.

BGP and Aggregation:\n\nBGP (Border Gateway Protocol), the Internet's inter-domain routing protocol, has explicit support for aggregation. The ATOMIC_AGGREGATE and AGGREGATOR attributes track when and where aggregation occurred. BGP routers can be configured to:\n\n- Aggregate customer routes before advertising upstream\n- Accept only aggregate prefixes (rejecting too-specific routes)\n- Automatically generate aggregate routes from more-specific entries\n\nThese mechanisms ensure aggregation remains practical at Internet scale.

We've covered the foundational concept of address aggregation—the technique that saved the Internet from routing table collapse and continues to enable global-scale routing today. Let's consolidate the key takeaways:

What's Next:\n\nNow that we understand what address aggregation is and why it matters, the next page examines contiguous networks—the fundamental requirement that networks must be numerically adjacent for aggregation to work. We'll explore how to identify contiguous blocks and understand the alignment constraints that make aggregation possible.