CIDR: An Historic Review


CIDR was defined in RFCs 1517 through 1520, published in September 1993. As you peruse these documents, you can't help but notice the sense of urgency with which the IETF was grasping for a solution to its impending address crisis. The Internet's commercialization wrought a dramatic and rapid evolution in its size, scope, and user base. Once just populated with a few academic and research bodies collaborating on DARPA, the Internet quickly grew to global proportions. Its user community also spanned the gamut, including an ever-increasing number of users who tried desperately to figure out how to make money off the Net. The effect was rapidly increasing pressure on all the Internet's internal support mechanisms, including its address space, that threatened to collapse the Internet itself.

Specific areas of concern for the IESG included the following:

  • Impending depletion of the Class B address range The tremendous gap between the number of hosts available on a Class C network versus a Class B network meant that many Class B networks were being assigned to small companies that needed more addresses than the Class C network could provide.

  • Bloating of the Internet routing tables Determining which route any given packet should take requires a table lookup. The larger the Internet's routing table, the more time on average any given routing decision takes. The Internet's rapid expansion can best be explained by pointing out that the size of the Internet's routing tables was doubling approximately every 12 months during the early 1990s. According to Moore's Law, processing power doubles approximately every 18 months. Consequently, the routing tables were growing faster than technology could keep up! That slowed down routing across the Internet and threatened to disrupt its functionality unless checked.

  • IP address space exhaustion Ostensibly, the Class B space would deplete first, and that would trigger a chain reaction that would place increasing pressure on the remaining classes.

With these concerns for their motivation, the IESG studied the problems plaguing the IP address space extensively. They documented their recommendations in RFC 1380, which was published in November 1992. This document posited CIDR as the solution to the first two problems. CIDR remained to be developed, but enough of its desired functionality was spelled out in RFC 1380 that the Internet community could appreciate the impending changes.

At this point in time, nobody within the IETF was certain exactly how to solve the looming address crisis. Consequently, they attacked in all feasible directions. Specifying a classless IP architecture was but one of the myriad tactics deployed to buy enough time for IPv6 to be developed. Implicit in this statement is the fact that, like the various stopgap technologies we examined in Chapter 5, nobody really expected CIDR to be more than just another stepping-stone to IPv6.

CIDR: An Architectural Overview

The IETF witnessed the successful grassroots innovation of VLSM and appreciated the significance of moving beyond octet boundaries in the IP addressing architecture. With subnets, this was a trivial endeavor: A subnet mask, regardless of whether it is of fixed or variable length, is of local significance only. In other words, routers do not use subnet addresses to decide on optimal paths through a network. However, embracing a bit-level definition of network addresses would have a tremendous impact on routers and how they calculate routes.

The previous method of operation was the class-based addressing architecture that we examined in Chapter 2, "Classical IP: The Way It Was." Classical IP used the leftmost bits of leftmost octet to determine an address's class. It was possible to identify the class of any IP address simply by examining its first octet in binary form. By identifying in which bit position a 0 first appeared, you could determine whether it was a Class A, B, C, or D. After establishing an address's class, a router would know precisely how many bits of the 32-bit address it should use to make routing decisions.

Abandoning the class-based approach enables a more efficient use of an address space via more finely tunable address allocation. An even more important change was that the mathematical boundaries of the old address classes were done away with. Thus, the once-threatening problem of the depletion of Class B addresses was solved. The solution came in two forms:

  • Reducing demand for Class B address space

  • Increasing the potential supply of Class B-sized network addresses

The demand for Class B network addresses was seriously reduced simply by letting network addresses be created by bit boundaries, as opposed to octet boundaries. Thus, if a Class C (24-bit) network were too small, you could get a 23-bit, 22-bit, 21-bit, and so on network instead of just jumping right to a 16-bit network block.

The potential supply of 16-bit-sized networks was greatly increased by eliminating the mathematical boundaries of the old address classes. Under the CIDR rules, any sized network block could be created from anywhere in the 32-bit addressing system. An additional benefit of CIDR was that smaller networks could still be carved from larger network blocks. In the class-based architecture, this was known as subnetting. Subnets, as you have seen in previous chapters, violated the class-based architecture. Thus, they couldn't be routed but were invaluable for creating local subnetworks.

In a CIDRized environment, abandoning the rigid hierarchy of class-based addresses in favor of bit-level boundaries created a huge problem for routers: How do you figure out how many bits are significant for routing? The answer was to expand the use of subnet masks and to make them routable instead of just of local significance. In this fashion, the boundary or distinction between subnet masks and network blocks became perfectly blurred. Today, the distinction is almost semantic. It depends on how aggregatable your address distribution scheme is and how your routers are configured. If the word aggregatable leaves you scratching your head, fear not! It's not as complex as it sounds. We will look at aggregatability later in this chapter. For now, let's take a closer look at CIDR notation.

CIDR Notation

It is imperative that you understand CIDR notation, including what it is and what it isn't. CIDR notation has become the predominant paradigm for conveying the size of a network's prefix. But it is just a human-friendly form of shorthand. When you configure routers, you must still use the dotted-quad style of IP mask. For example, 255.255.255.248 is the equivalent of a /29. It should be obvious which one is easier to use.

Table 6-1 shows the valid range of CIDR block sizes, the corresponding bitmask, and how many mathematically possible addresses each block contains. If this table looks familiar, it's because of the similarities between CIDR and VLSM. You've seen some of this data before, in Table 4-1. CIDR notation was included with that table simply to make it easier for you to go back and compare VLSM with CIDR.

Table 6-1. CIDR Notation

CIDR Notation

Decimal Mask

Number of Possible Host Addresses

/5

248.0.0.0

134,217,728

/6

252.0.0.0

67,108,864

/7

254.0.0.0

33,554,432

/8

255.0.0.0

16,777,216 (Class A network)

/9

255.128.0.0

8,388,608

/10

255.192.0.0

4,194,304

/11

255.224.0.0

2,097,152

/12

255.240.0.0

1,048,576

/13

255.248.0.0

524,288

/14

255.252.0.0

262,144

/15

255.254.0.0

131,072

/16

255.255.0.0

65,536 (Class B network)

/17

255.255.128.0

32,768

/18

255.255.192.0

16,384

/19

255.255.224.0

8,192

/20

255.255.240.0

4,096

/21

255.255.248.0

2,048

/22

255.255.252.0

1,024

/23

255.255.254.0

512

/24

255.255.255.0

256 (Class C network)

/25

255.255.255.128

128

/26

255.255.255.192

64

/27

255.255.255.224

32

/28

255.255.255.240

16

/29

255.255.255.248

8

/30

255.255.255.252

4

/31

255.255.255.254

2

/32

255.255.255.255

1


This table omits network masks /1 through /4 because they are invalid. The largest network permitted under current CIDR rules is a /5. A /5 is sometimes called a superblock because it is equivalent to eight Class A address blocks. Such an enormous address block is not made available for end-user organizations on the Internet. Instead, a /5 might be allocated to a regional registry for use in providing IP address block assignments to service providers and/or large end-user organizations in the registry's home region.

Backward Compatibility with Classical IP

Backward compatibility is always a critical issue whenever a technological advancement is proposed. CIDR was no exception. You know, based on your reading thus far in the book, that Classical IP has become obsolete. However, CIDR represented more of an extension of Classical IP than a complete rewrite. The backward compatibility was almost complete: The entire 32-bit address space was preserved, as was support for all previously assigned IP addresses. The notion of splitting an address into host and network address subfields was also retained. As you'll see throughout this chapter, CIDR represented nothing more than a complete legitimization of the classical form of VLSM. The degree of backward compatibility with Classical IP ensured CIDR's success. The classes themselves were abolished, yet the address space survived.




IP Addressing Fundamentals
IP Addressing Fundamentals
ISBN: 1587050676
EAN: 2147483647
Year: 2002
Pages: 118
Authors: Mark Sportack

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net