return to first page linux journal archive
keywordscontents

CIDR: A Prescription for Shortness of Address Space

This article explains the concept of CIDR and shows how you can implement it on your network.

by David A. Bandel

CIDR, Classless Inter-Domain Routing, allows you to maximize use of the limited address space under the current implementation of the Internet Protocol version 4 (IPv4). After reading this article, even if you have never configured a computer for network communications before, you should have a good understanding of these references to networking.

Background

CIDR is the current trend in routing and has been for over three years. This concept was introduced in 1993 to alleviate the shortage of Internet Protocol (IP) addresses until the next generation (IP version 6--IPv6, aka IPng for IP next generation) arrives.

Currently in testing, IPng will significantly expand the IP address space by several orders of magnitude. IPng will also come with its own security enhancements. Those desiring to participate in the future today may have the opportunity to do so, since Linux has kernel-level support for IPng. Until IPng is deployed on a wide scale, making the best use of what we have is what CIDR is all about.

To help you understand why we need CIDR at all, let's journey back in time to the beginning of this decade. IPv4, the protocol used by computers to find each other on a network, was in use then, but there really weren't many connections to the Internet or machines needing Internet connections. In fact, a good number of systems still relied on uucp, the UNIX to UNIX copy protocol, where machines ``called'' each other at predetermined times and exchanged e-mail traffic. At that time, the IP-address pool seemed unlimited. That was also about the time Mosaic, the first web browser, appeared.

IP Basics

Those who consider themselves well-versed in ``classful'' routing may wish to skip ahead to the next section. Computers understand base 2 numbers (ones and zeroes), and humans understand base 10 (0-9), so engineers worked out a compromise to give computers numbers while keeping it simple for use by humans. All computers on the Internet have a unique IP address which can be represented by a string of ones and zeroes. If that string is divided up into four sets of eight (octets), you get four numbers with a range from 0 (eight zeroes) to 255 (eight ones), which are arranged in the form XXX.XXX.XXX.XXX. This arrangement is called ``dotted decimal notation'' and makes understanding the significance of each unique IP address a little easier for us humans. These addresses were then further broken down into arbitrary ``classes'' A-D. Looking at the first half of the first octet:

Class A = 0-127 (0000) 
Class B = 128-191 (1000)
Class C = 192-223 (1100)
Class D = the rest (1110)

The positions beginning from the left represent 128, 64, 32 and 16--see Table 1. Furthermore, Class A uses only the first number as the network number, e.g., 10.XXX.XXX.XXX; Class B uses the first two numbers as the network number, e.g., 172.32.XXX.XXX; Class C uses three numbers as the network number, e.g., 192.168.1.XXX; Class D is reserved for testing purposes. A network address can be thought of as having a network and host portions represented by numbers and XXXs respectively. For a Class C address, the network portion consists of the first three octets with the host portion as the final octet.

The following concepts with respect to networking computers must be understood. Note that the ``definitions'' I provide here are given to aid in understanding basic concepts for use in this article, and are not the actual definitions of the terms.

With this introduction to IP addressing, and remembering that a decade ago almost no PCs participated in networking, it is easy to see why during the 1980s IPv4 seemed to have an endless supply of addresses, even though not all addresses could be assigned. Theoretically, if you could make use of all the usable IP addresses available, you'd have a maximum of approximately 500 million addresses, but even 100 million is extremely optimistic and insufficient for today.

Before leaving this section, I'd like to describe an experiment. This experiment will not work properly if performed in an environment with machines using only the Microsoft Windows IP stack, since its implementation is broken, or at least doesn't follow the rules everyone else plays by. Therefore, you will need to be on a UNIX or Linux machine with other UNIX or Linux boxes on your network. Type the following command:

ping -c 1 
What you will see in response is every UNIX box answering back with its IP address, and each reply following the first one will have (DUP!) next to it, indicating it is a duplicate reply. The -c 1 argument tells ping to send only one ping packet. The number of replies received will depend on how many (non-MS) machines you have on the network. If this is performed from an MS Windows machine (95 or NT), you will receive a reply from the local machine only.

What is the point of this little demonstration? If you change the netmask on a machine, say from 255.255.255.0 to 255.255.0.0 thereby changing its network and broadcast addresses, even though nothing else changed (i.e., it still has the same IP address and is still connected to the network the same way) it will cease talking to its neighbors. In other words, this machine is now on another network and will require a gateway to talk to the other machines on the local net (all bets are off for the Microsoft machines).

CIDR

While IP classifications A-D are still in use in the networking world, those terms are obsolete. For the sake of clarity, I will continue to use them to explain how CIDR works and how you can implement it. Along with CIDR comes the concept of variable length subnet masking (VLSM).

Basically, with a ``Class'' address, you have a default subnet mask. For a Class C address, this default subnet is 24 bytes long, so putting all ones in the first 24 bytes and zeroes in the rest, we have 255.255.255.0. For class A and B, this would be 255.0.0.0 and 255.255.0.0, respectively. This basically gives anyone assigned a full Class C address 256 unique addresses, of which two are reserved, one each for network and broadcast addresses. Under ``classful'' addressing, we are limited to providing full Class A, B or C addresses to those requiring IP addresses. With ``classless'' addressing, we can subnet these addresses quite simply. As stated above, the network portion of the address is equivalent to that portion of the IP address corresponding in base 2 to all ones, and the host address to all zeroes. This means that a Class C address looks like:

11111111.11111111.11111111.00000000 = 255.255.255.0 (128+64+32+16+8+4+2+1 in the first three positions and 0 in the last). Again, note that this is 24 ones and 8 zeroes, for a total of 32 positions.

Let's say we have one Class C address (192.168.1.0) available for use, but we have two offices with approximately 75 hosts at each location, one in New York and one in New Jersey. While we could simply use the Class A address at each site with each office using unique numbers, we can't connect them together because machines in New Jersey can't find those in New York and vice versa. The reason these two portions of the network can't find each other is because in order for a computer to find another on a network, it assumes an address on its local network (the host portion where all the numbers are zeroes) is directly connected to it, and one on another network is reachable only by going through a gateway.

A gateway is a machine (computer or router) that has two or more network addresses, at least one on the local network and one or more on other networks. A gateway sends any communications not on the local network via one of its other communications devices, depending on the information stored in its routing table. Under classful routing, we would need two half-used Class C addresses for each office, which would be very wasteful of scarce IP addresses.

With CIDR, we can cut the Class C address into two different networks. To do this, we will extend our netmask by one more bit, giving us two separate networks, where before we just had one. This will change our netmask from 255.255.255.0 or 24 ones (hereinafter referred to as /24) to a /25 network, or 255.255.255.128. Both of our new networks will have this same netmask; all other rules remain the same. We now have one network with a network address of 192.168.1.0 and a broadcast address of 192.168.1.127. The other network will use a network address of 192.168.1.128 and a broadcast address of 192.168.1.255.

In the same manner, we can continue slicing up our network into four, eight, sixteen, thirty-two, ... networks. In fact, starting at /8, we can slice and dice until we reach /30. Since we have 32 numbers to work with, a /32 represents just one address, and in this special case, there's no need for network or broadcast addresses. That also means a /31 would represent two addresses, but since one would be the network address and the other the broadcast address, this would leave us with no host addresses--almost certainly undesirable.

Under this scheme, the first octet of the netmask would remain 255, but after that we could change any of the other numbers. Instead of being restricted to 255 and 0, we may find ourselves replacing the first zero in our netmask with any of 128, 192, 224, 240, 248, 252 or 254, except in the last octet as noted above. The network and broadcast addresses would bind each subnet (see Table 2 for details). Now, any network can be referred to by its variable length subnet mask, or the number of ones in the host portion of the address from /8 to /32 (excepting /31). By extrapolation, each host can be referred to directly by its IP address and the VLSM notation, so that it is readily apparent what the network and broadcast addresses and netmask are.

For example, if someone told me to assign my machine 192.168.0.50/27, I would know that the network address was 192.168.0.32, the broadcast address was 192.168.0.63, and the netmask was 255.255.255.224. For those of you who still have problems visualizing how this all translates, I've provided a chart to assist you (Table 3).

You will find more uses for classless addressing than this. CIDR can also give you a way to isolate departments in large organizations to provide better security (by implementing internal firewalls) and decrease traffic on any given network segment, reducing collisions and increasing response times.

Private Address Groups

Another way many companies can expand their pool of usable IP addresses is to take advantage of the private IP addresses set aside for companies and individuals not requiring direct Internet access on all their machines. These numbers can be used as seen fit.

By using a firewall or proxy server that performs network address translation (NAT), called ``masquerading'' in the Linux community, these machines can still connect to the Internet. The bright side is you won't be routing internal company addresses to the Internet, since most routers are set up to not route these private addresses. Conversely, no one can directly access your systems, so rogue web sites springing up in your company will not come back to haunt you. In order for anyone to access an internal computer, they would have to either log in to the proxy server first, then continue in, or be redirected by the proxy through the server to the designated machine.

The reference for those addresses we can make use of with no prior coordination is RFC 1918, ``Address Allocation for Private Internets'', February 1996. These private addresses are as follows (excerpt from RFC):

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0   - 172.31.255.255 (172.16/12 prefix)
192.168.0.0  - 192.168.255.255 (192.168/16 prefix)
Note that under the old classful addressing, while the first address segment is one Class A network, the second would actually be 16 Class B networks, and the final segment 256 Class C networks. By implementing a Linux gateway box and setting up some simple rules in ipfwadm (generally available with all Linux distributions), we can perform masquerading or Network Address Translation, giving all computers on the private network full Internet access. However, those on the Internet cannot get to any of the computers with private addresses unless one of two things happens. One, the administrator sets up the gateway to act as a proxy server; proxying requests on a particular port to a particular computer, or two, by the Internet user using TELNET to access the gateway box first, then on to the internal computers. Thus, private addresses stay private.

These address groups can also be put to use in private networks that piggy back on the Internet. By using two ``live'' (non-private) IP addresses, one on each network's ``gateway'' machine, we can tie two private networks together using Linux's IPIP, IP tunneled inside IP. While this won't provide privacy unless the two gateways are running an encryption program such as ssh (secure shell), it can provide a virtual network.

Conclusion

While live Internet addresses are becoming scarce, companies and individuals can maximize use of their current address space and even expand their address space through the use of private addresses. CIDR can also be used to improve security and increase network response time through subnetting.

By staying current with trends in such things as CIDR and Linux's networking software, most obstacles to Internet and Intranet connectivity can be easily circumvented. As CIDR provides everyone with a way to maximize the little we have, private addresses afford us the flexibility to expand beyond those addresses provided by our Internet Service Provider.

David Bandel is a Computer Network Consultant specializing in Linux, but he begrudgingly works with Windows and those ``real'' UNIX boxes like DEC 5000s and Suns. When he's not working, he can be found hacking his own system or enjoying the view of Seattle from 2,500 feet up in an airplane. He welcomes your comments, criticisms, witticisms and will be happy to further obfuscate the issue. He can be reached via e-mail at dbandel@ix.netcom.com.