In the early 1990’s the IETF realized that the classful “3 sizes fit all” (Class A, B and C) allocation scheme was going to deplete all the remaining IPv4 addresses in a very short time indeed (maybe before the year 2000). At the time, the split between the address prefix (network number) and address suffix (interface identifier) could only be in one of three bit positions: 8, 16 or 24. The number of usable addresses is 2 raised to the number of bits in the suffix (32 – prefix length), minus two. Why minus 2? You can’t assign the first suffix of a block (0 = “this network”) or last suffix of a block (all ones = broadcast), as a node address.
The allocation scheme was “3 sizes fit all”:
|Prefix Length||Blocks per /8||Usable Addresses per Block|
If an organization needed more than 254 addresses, the next step up was 65,534. If an organization needed more than 65,534 addresses, the next step up was 16.7 million. Ooops. So, RFC 1519, “Classless Inter-Domain Routing (CIDR)”, September 1993, allowed the split in the IP address between prefix and suffix to come anywhere from positions 8 to 30. Now we have lots of allocation block sizes, from “/8” (16.7M addresses) down to “/30” (2 usable addresses). We can fit the allocation size much more closely to the customers’ needs than before. If they need more than 254 addresses, the next step up now is 510, not 65,534. If they need more than 65,534, the next step up is 131,070, not 16.7 million. Much better!Here is the list of all possible allocation blocks sizes under CIDR, including how many CIDR allocation blocks could be made from a single /8 block, and how many usable addresses are in each allocation block. It also shows the subnet mask for a block of that size. Now instead of “3 sizes fit all”, it is “23 sizes fit all”:
RFC 1519 was replaced by RFC 4632, “Classless Inter-Domain Routing (CIDR)”, August 2006, which is the current version.
CIDR and the IPv4 Core Routing Table
The core routing table is like the central telco switch for the Internet. This is where the various blocks of addresses are stitched together to make an Internet. In reality, since the Border Gateway Protocol (BGP) was introduced, no single router has a view of the complete IPv4 Internet, but the concept is still applicable, in that there are total number of core routes, even if distributed over a number of core routers by BGP.
CIDR of course impacted the IPv4 core routing table – if you break a /8 block up into a lots of smaller blocks, instead of one entry in the routing table for the entire /8, you now need one entry for every newly created block. Overnight the growth of the central routing tables started to explode.
You can see the impact that CIDR had on the core routing table (starting in 1993, when RFC 1519 was released), even with its suggestions regarding route aggregation. The giant increase in 2010 was due to the panic allocation of IPv4 addresses as the IANA pool neared exhaustion. With the introduction of CGN (Carrier Grade NAT), the IPv4 core routing table may experience unprecedented growth. This is one more area where IPv4 is rapidly approaching End of Life.
|Prefix Length||Blocks per /8||Usable Addrs per Block||Subnet Mask in Hex|
CIDR is really an IPv4 thing. There is no mention of IPv6 in RFC 4632. For the most part, all subnets in IPv6 are /64. However, the CIDR notation is widely used in IPv6. Some examples:
There are continuing concerns regarding the growth of the IPv6 core routing table as well.