@internet -- How Hard Is CIDR?



Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero

I was researching the IAHC new domain names proposal when Kim Hubbard's January 2 announcement of Network Solutions, Inc.'s American Registry for Internet Numbers (ARIN) proposal was cross-posted from the pagan mailing list to the iahc list. Kim is the NSI manager in charge of IP network number assignments and ARIN is a proposal to create a not-for-profit entity to take charge of assigning large CIDR blocks to entities in the Americas.

ARIN, basically, is a mechanism designed to permit NSI to jettison its responsibility for assigning IP network numbers, (an activity which makes no money for its owner, Science Applications International Corporation, and which requires a highly-skilled staff) allowing it to concentrate, on registering domain names (an activity which is largely automated and which makes SAIC lots and lots of money). It is also a harbinger of a sweeping change in how Internet administration and governance are financed and from whence they draw their legitimacy.

Before NSI began charging for domain name registrations in 1995, the costs for most Internet administrative and governance activities were underwritten by the U.S. government. They were "free" in the sense that their costs were hidden. U.S. taxpayers picked up the bills, so the direct beneficiaries of these services received them without being forced to confront the unpleasant truth that there really ain't no such thing as a free lunch.

The domain name registry was easy to make self-financing. The concept of a domain name as a valuable property is something even relatively unsophisticated Internet users can grasp. It's a lot harder to explain to a corporate executive that a block of IP addresses also has value, especially when the Internet Assigned Numbers Authority (IANA-from whom all IP blocks are ultimately delegated) encourages the IP community to think of them as "leased" rather than as "owned."

ARIN proposes to charge large ISPs and Autonomous Systems in the Americas enough for new IP block assignments to recover the costs of providing and administering them.

Following the ARIN list made it clear to me that an awful lot of smaller ISPs misunderstood who was going to be expected to pay, how much they were going to pay and what they were going to be paying for. It was also clear that a lot of ISPs who posted to the ARIN list don't understand the Classless InterDomain Routing (CIDR) protocol upon which the Internet's routers so desperately depend. They don't "get" route aggregation and they don't understand the concept of block suballocation by which most of them obtain their own IP assignments.

I get the feeling that most of these folks are afraid to admit that they don't know this stuff. It can be confusing, but it's important to soldier on until you understand how it works. Then, and only then, can you intelligently discuss whether the ARIN proposal is "fair"-and whether it even applies to you.

Set the Wayback Machine for 1992

In many ways, 1992 was a watershed for the Internet. The Honorable Albert Gore, Jr.'s Presidential campaign brought the buzz term "information superhighway" into everyman's vocabulary. The notoriously optimistic Internet Society (ISOC) estimated that the number of Netizens was growing by 15 percent per month and the equally unrealistic folks at CommerceNet agreed with them. Some of the brighter lamps of the Internet Engineering Task Force (IETF) took a look at this ferment of growth and performed a few basic arithmetical calculations on what it might mean for the anticipated demand for new IP network assignments and the routing tables to support them.

What they found was a little scary. The way things were going, the entire IP address space was liable to be gone by 1996, which wasn't going to matter, since the routing tables were due to melt down sometime in 1995.

Both of these dire consequences were artifacts of the original, "classful" IP network allocation scheme. There are, for instance, only 126 Class A networks. Each one consists of about 16 million IP addresses. In the early days of the Net, when nobody could envision a time when there would be more than 10,000-15,000 hosts on a single network, Class As were handed out to practically anyone who asked for one. Almost none of the organizations which got Class As needed them. In many cases, they didn't even need a Class B (about 64,000 hosts). And the folks who got Class Bs didn't need them either.

So, there was an awful lot of wasted address space in the original allocation design. Most of the Class Bs and a lot of the Class As had already been spoken for, which essentially left the 16 million or so Class Cs into which the rest of the world would have to fit.

Except that the existing routers simply couldn't handle 16 million separate, new entries. Terabytes of RAM would be needed to hold the routing table and even the fastest available processors would need hours to do lookups. Clearly, some other way had to be found.

These problems were attacked on two fronts. The first approach was to design a follow-on protocol to take the place of the venerable (and increasingly creaky) IP version 4. This effort, dubbed IPng (Internet Protocol the Next Generation) and more formally known as IPv6, would eventually result in a protocol with nearly unlimited address space that was designed so that new functionality could be easily added to it and that has an amazing variety of native capabilities. Unfortunately, IPv6 is not yet supported by the major router manufacturers and, until it is, it will remain a solution in search of a market.

The second avenue of attack was the one which crafted an interim solution to both the routing table growth and address depletion problems. That solution, known as Classless InterDomain Routing (CIDR, defined in RFCs 1517, 1518, 1519 and 1520), worked so well that the IPv4 address space is probably now sufficient to meet anticipated demand through the end of the century. It also permits a technique called route aggregation which, so far, has kept the growth of the Internet core routing table down to a linear, rather than an exponential rate.

Classful Addresses--
Three Sizes Fit Almost No One

Until the advent of CIDR, all IP routers examined the first three bits of an IPv4 address to determine its class. If bit 1 was a zero, it was a Class A address. If bit 1 was a 1 and bit 2 was a zero, it was a Class B. And, if bit 1 was a 1 and bit 2 was also a 1, it was a Class C. (We'll ignore Classes D and E for purposes of this discussion.) Each IP address was composed of two parts expressed as a single, 32-bit number in dotted-decimal notation.

In Class A addresses, the first 8 bits made up the network address, leaving 24 bits for individual host addresses. Class Bs used 16 bits for the network and 16 for the host components of the address. Class C addresses require 24 bits for the network segment and use the remaining 8 bits for the host identifier.

Simple, straightforward and totally inflexible, the limits of this approach became apparent in the mid-eighties. Organizations were forced to request multiple Class B or Class C assignments to set up administratively-separate LANs, even if relatively small numbers of hosts were attached. And, if there were more than 254 hosts on a single Class C LAN, a Class B assignment was required, despite the enormous waste of address space that a 255-host LAN entailed. (Both the network itself--the all-zeroes address--and the broadcast address--the all-ones address--were reserved for those purposes and couldn't be assigned to host machines.)

In 1985, in recognition of the need to provide some standard method for breaking classful IP network assignments into smaller, more useful chunks, Mogul and Postel published RFC 950. This RFC described a procedure for subnetting-making a lot of little subnetworks out of a big Class A or B net. Subnetting introduced a fundamental new component to IP addressing: the subnet mask. In essence, it extended the network portion of an IP address into the host ID portion, with the extension used to identify the subnet to which the host belonged. It also required that a fully-qualified IP address include both a 32-bit network/ host address and a 32-bit submask.

That, in turn, required new routing software be developed that could understand this new address component. Routing Information Protocol version 1 (RIP-1), which is fundamentally classful, but understands basic subnetting, was the first solution. (Unfortunately, RIP-1 only understands symmetric subnets. Thus, all subnets served by a router capable only of RIP-1 must each be the same size.)

1987's RFC 1009 specified requirements for Internet gateways (i.e.--routers interfacing between two distinct IP networks). Among them was the requirement that gateway routers understand variable-length subnet masks. (Variable--length masks permit subnets of different sizes to be constructed out of a given classful network, giving the network architect much greater leeway in designating subnets of sizes appropriate to their specific applications.)

That specification worked pretty well for almost 15 years.

Then came the twin bugaboos of IP address space depletion and exponential routing table growth and something had to give.

CIDR--a Classless Act

What the CIDR solution did was to discard classful IP addressing altogether. Instead, it extended the IP network submask concept to the definition of IP networks in general. Where earlier, classful routers look at the first three bits of the address to determine the network class, CIDR-capable routers look at the combination of the 32-bit IP number and the 32-bit submask. The Border Gateway Protocol (which core routers use to route IP packets between the Internet's Autonomous Systems) was revved to support CIDR in BGP-4. That then permitted NSI's InterNIC to assign large blocks of contiguous IP numbers to ISPs. They, in turn were then free to further sub-allocate appropriately-sized chunks of that address space to their customers. This had the welcome effect of offloading much of the increasing burden of IP number assignment from NSI's InterNIC to the individual ISPs who, at least theoretically, know their customers well enough to be able to make appropriately-sized IP assignments to them.

That's important because one of the primary values of CIDR is that a network of any size desired can be defined to the nearest power of two, using CIDR masking. In fact, a useful general rule of thumb in sizing CIDR block suballocations is:

  1. Take the maximum desired number of nodes on a single subnet, double it and raise it to the nearest power of two (to allow for future growth). Translate it to binary. The number of digits in the binary expression of the result gives you the minimum desirable size of the host portion of the allocation. (As an example, let's take 25 hosts per network. Doubling gives us 50. The nearest power of two is 64. It takes 6 binary digits to express 64 in base 2, so the host portion of our solution is 6.)

  2. Then take the maximum desired number of subnetworks in the total allocation, double it and raise it to the nearest power of two. Translate it to binary. The number of digits in the binary expression of the result gives you the minimum desirable size of the network portion of the allocation. (Continuing our example, let's take 5 subnetworks. Doubling gives us 10. The nearest power of two is 16. It takes 4 binary digits to express 16 in base 2, so the network portion of our solution is 4.)

  3. Add together the number of binary digits in the two numbers you obtained in the previous steps. Subtract that sum from 32 (the number of binary digits in an IP number or network mask). The result gives you the "slash number" needed to provide an allocation that will provide sufficient room for future growth pending the widespread adoption of IPv6. In our example, we'd add 6 (the number of binary digits in 64 host nodes per network) to 4 (the number of binary digits in 16 networks), giving us 10. Subtracting that number from 32 gives us 22, meaning that a /22 CIDR block allocation should handily meet the needs of our fictional customer network both now and for the next few years.
You'll notice that CIDR uses "slash notation" to indicate the length of the network mask in bits. Thus, a traditional Class A network would be the equivalent of a /8 (i.e.-the network portion of a Class A IP address is 8 bits long), a Class B would be a /16 and a Class C a /24. Note that smaller "slash numbers" define larger networks (i.e.-networks with more host addresses) and larger "slash numbers" define smaller networks.

CIDR-based networks have another advantage. A gateway router can advertise all the contiguous addresses in a CIDR block range as a single routing table entry. This aggregation of routes keeps the size of the core routing tables down to something that current-day router technology can handle--although it still requires a significant amount of both RAM and CPU horsepower. It is route aggregation that lies behind IANA's advocacy of a "leased" model for IP assignments, rather than an "owned" model.

If a customer changes ISPs and insists on taking "his" IP assignment with him, that range of addresses can no longer be aggregated with the old ISP's CIDR blocks. Instead, it must be advertised as a separate route in the new ISP's router table, since it also won't aggregate with the new ISP's CIDR blocks, either. That adds another static route to the core routing tables. Too many such routes, and the smaller ones will start getting dropped on the floor, breaking the system.

That's a bad thing.

ISPs depend on the Internet's constituent parts to be reachable. If parts of the system become impossible to reach, the value of the whole is diminished relative to that of traditional online services with their proprietary content offerings. It's critical that ISPs understand that the value of route aggregation is maximized only if the address space remains relatively unfragmented.

One way in which ISPs can contribute to the routability goals of CIDR is to make certain that their customers understand that any CIDR block allocations they receive from their ISP are leased, not owned. If a customer switches to another ISP, that customer should obtain a new CIDR block from his/her new ISP and renumber his/her network. It's inconvenient, but necessary to minimize route "flapping," which happens when a block switches from one route advertisement to another.

Many smaller ISPs get their own CIDR block allocations from an upstream provider. The route advertisements of those smaller ISPs, in turn, are aggregated with those of their upstream providers.

IANA delegated to NSI the responsibility to allocate IP address assignments for all of North America. Although NSI's policies strongly encourage end users to obtain their CIDR assignments from an upstream provider, if the end user was really, REALLY adamant, NSI has little other choice than to directly grant the applicant a "portable" CIDR block, even though that block is really too small to meet the criteria for advertisement as an exception in the core routers.

ARIN could change that.

No False Idols in ARIN

ARIN is proposed to be a not-for-profit corporation, established to replace NSI as the body responsible for IP number registration and administration in the Americas. It won't sell IP numbers, but it will charge to recover its costs to allocate CIDR blocks and to determine that any requested allocation is justified. Membership in ARIN will be $1,000 per year. Membership currently includes the privilege of attending semi-annual meetings. It may eventually also include the right to vote for members of ARIN's Advisory Board and/or its Board of Trustees. You won't have to be an ARIN member to request an IP block "subscription" from ARIN.

Charges for CIDR blocks will be in the form of an annual "subscription" fee, based on how much space was allocated to the applicant in the previous calendar year. Charges will be weighted so that per-address charges are low for large allocations and high for small ones, thus encouraging large upstream providers to "subscribe" for large annual blocks and resell them at discount rates to the smaller ISPs downstream. Although smaller ISPs will be able to purchase small blocks directly from ARIN, the prices they'll pay are liable to be higher than what their upstream providers will charge them for the same address space. Sample "subscriptions" proposed are:

Allocation Annual Cost
of "Subscription Fee"
CIDR Block Size
Small $2,500 /24 - /19
Medium $5,000 >/19 - /16
Large $10,000 >/16 - /14
X-Large $20,000 >/14

It's important to understand that European and Asian-Pacific Internet users have been directly paying for the costs of IP allocation and top-level administration for some years now. Uncle Sam, in the person of the National Science Foundation, has determined to stop footing the bill in the U.S., so, like it or not, some kind of fee-based mechanism is going to replace the free ride sometime in the immediate future.

Is ARIN the right mechanism? Perhaps so, perhaps not. As of now, it is the only proposed alternative to taxpayer funding-and taxpayer funding is definitely the wave of the past.

If you're curious about the proposal, ARIN's home page is www.arin.net. It includes a terrific reading list at www.arin.net/arin_rr.html, too. The reading list features links to relevant RFCs, Hank Nussbacher's CIDR FAQ, 3Com's excellent IP Addressing: Everything You Ever Wanted To Know and other tools, research materials and addressing/routing-related resources. It also links to RIPE-NCC (Réseaux IP Européens--Network Coordination Center) and APNIC (Asia Pacific Network Information Center), ARIN's European and Pacific Rim counterparts.

(Copyright© 1997 by Thom Stark--all rights reserved)