There was a time when names were somewhat arbitrary (if not outright capricious) and less-than-universal in their use. In the very beginning of the Internet, there were only hundreds of computers, and each one could be accessed using a mnemonic that was locally created by network administrators. This led to the inevitable: one destination computer that was known by a myriad of names that varied by location. Although there was merit in having such mnemonics, the administrators agreed that consistency of nomenclature would be even better. What was originally a convenience for a small cadre of network and host administrators evolved into a system that became the single most enabling mechanism that opened up the benefits of the Internet to nontechnical users. (more…)

Although NAT might sound like the perfect answer to virtually any scenario that involves a private network with Internet connectivity, it isn’t a panacea. In fact, it wouldn’t be very difficult to find knowledgeable network engineers who regard NAT as akin to crabgrass or kudzu, to name a pair of human-induced agricultural disasters. (more…)

Network Address Translation (NAT) was developed specifically to counter the lone weakness inherent in the private addresses of RFC 1918. That’s not to suggest that it makes those nonunique addresses globally routable, because it doesn’t. Rather, it lets you translate those nonunique addresses to unique and routable addresses at the edge of your network. This permits access to and from the global Internet. In other words, you operate with two sets of addresses: You would have your private RFC 1918 addresses configured on endpoints throughout your network, and then a globally routable block of addresses would be configured on your NAT device. NAT would be responsible for correlating the internal and global addresses and translating as needed to support communications. (more…)

After the Internet became commercialized, its popularity soared. More importantly, so did the popularity of TCP/IP and its addressing architecture and space. Seemingly overnight, software engineers embraced the TCP/IP communications protocol suite and it became the de facto standard for networked communications between applications. As a direct result of this trend, many organizations began implementing TCP/IP to support their base of applications even though they might not have needed or wanted access to the Internet. Implementing TCP/IP absolutely requires that you also implement the Internet’s addressing scheme, regardless of whether you intend to actually use the Internet. (more…)

Arguably the single most powerful advance experienced by the IPv4 address space is the capability known as supernetting. Before we delve too deeply into this topic, let’s dispel a very popular misperception. Supernetting was not introduced with CIDR! It was first specified in June 1992 in RFC 1338 as a standalone strategy for improving the aggregatability of IP address blocks. The fact that I’m including it as a subtopic in a chapter on CIDR should tell you something about how pervasive this myth has become. Yet the facts remain publicly available: Supernetting was introduced 15 months before CIDR. However, CIDR made supernetting infinitely more useful simply by creating a classless IP address space. Thus, supernets could be created on any bit boundary, as opposed to the class-based octet boundaries that constrained the authors of RFC 1388. (more…)

The binary mathematics of the IP address space creates a marvelous natural symmetry in CIDR-compliant addresses. What at first glance appears to be an unmanageable jumble of numbers is actually a remarkably logical system. The key is remembering that the binary number system works based on powers of 2. For each bit you move to the left, you double the bit’s value. For each bit you move to the right, you halve the bit’s value. These facts help you better appreciate CIDR’s /number notation. For example, if you halve a bit’s value by moving to the right, you can logically assume that the entire string of bits that follows the bit in question is also halved.

Look at Table 6-2 to see how this works. In this table, we’ll look at a real /24 network address block and then figure out how many /25 networks it contains. Logically, a /25 features a network prefix that is exactly 1 bit longer than a /24, and that bit comes from the right. So you can expect that a /25 is exactly half the size of a /24, but let’s prove it. Table 6-1 dissects 192.1.64.0/24. The bits that represent the extended network prefix are indicated in bold. I’ve indented both of the /25s to indicate that they are actually subcomponents of the /24 address space.

As is evident from Table 6-2, when you borrow a single bit from the host octet of the /24 network, you create exactly two /25 networks. That’s because you are borrowing only a single bit, and that bit can have only two possible values: 0 and 1. Thinking about this a little more, you can see that this borrowed bit is in the leftmost position of its octet. This bit carries a decimal value of 128. Thus, the initial value of the last octet in the second /25 network must be .128. Logically, then, the highest-value host address in 192.1.64.0/25 must be .127. Converting the binary string 01111111 to decimal yields exactly 127. This value serves as the broadcast address for that network and cannot be assigned to any endpoint.

This symmetry works on any bit boundary. Table 6-3 shows how exactly two /24 network blocks can be created from a /23. It uses the same address block as the preceding example so that you can see the progression of the addresses as subblocks are created.

Table 6-4 shows how this pattern progresses even further. If two /25 networks can be created from a single /24, there must also be two /26 networks in each of those /25 networks, for a total of four /26 networks in each /24. The next logical conclusion is that each /24 network can be used to create exactly eight /27 networks, because Base2 has eight unique numeric combinations ranging from 000 through 111. This is what you see in Table 6-4. Focus on the bold italic numbers, and you can see how you are counting in binary. This “counting” is obvious only when you look at the value of the last octet in binary. In decimal, you can see the incrementation, but it occurs in increments of 32, which is the value of the least-significant of the 3 bits borrowed from the host field to create the /27 networks.

This pattern can get quite tedious to fully examine using just mathematics. If you tend to learn best visually, refer to Figure 6-1. It demonstrates the hierarchical and mathematical relationship between network blocks. Space constraints prevent the creation of this type of chart for the entire IP address space, but this small sampling from /24 through /27 should adequately demonstrate the pattern.

Figure 6-1. The Mathematical Relationship Between Network Block Sizes

If you understand this basic symmetry, and you adhere to it when creating subnets in your network, you shouldn’t experience any problemsunless, of course, you fail to keep good records! My point is simple: Understanding the bit boundaries and nested symmetries found in CIDR lets you properly create subnetwork addresses. Some examples presented in Chapter 4, “Variable-Length Subnet Masks,” violated this principle. Now you can better appreciate why those examples were suboptimal. Reviewing the tables in that chapter, you will see that subnets often started outside conventional bit boundaries.

Violating bit boundaries has its consequences, but they are not necessarily fatal. For example, a network can function quite well with a poorly designed address space. The two main consequences of poor address space implementation are

• Confusion as to which hosts fit in which subnet

• Creating inefficiency and possibly unusable addresses, because one subnet boundary might overlap with another

Although none of these consequences will kill a network, they tend to be very persistent. Most address schemes take on a life of their own after they are implemented. You would be surprised at how difficult it can be to correct past mistakes in an address space that is in daily use.

Other consequences of a poorly designed addressing scheme require a finer appreciation of just how useful CIDR’s symmetry really is. The next two sections look at how CIDR blocks are designed to be aggregatable and subdividable.

From Symmetry Comes Aggregatability

Under the rules of Classical IP, there was at best a weak, positive correlation between network addresses and geography. Thus, two numerically adjacent network addresses of any class could be on opposite sides of the world. From a router’s perspective, even though these two network blocks are numerically contiguous, they must be regarded as completely and utterly unrelated! Logically, if they are on opposite sides of the world, you probably will take different routes to get to each one. Thus, routers throughout the Internet would have to remember a separate route for each router. This is the opposite of aggregatability, and it can quickly spell death for a network’s performance simply by consuming more and more of a router’s finite memory and CPU resources.

Aggregatability: What a Concept!

Aggregation of addresses is nothing more than the inverse of subnetting on a large scale. Subnetting lets you take a single network address block and carve it into smaller subnetwork blocks. Aggregation is taking several network addresses (also known as prefixes), lumping them together, and advertising just one network prefix to other networks. Several critical assumptions are buried in this simple explanation. The two most important are as follows:

• Network prefixes must be numerically similar, if not contiguous, to enable identifying them via a unique network prefix.

• Networks using those prefixes should be close enough geographically to be able to use the same ISP for their connectivity to the Internet.

From an ISP’s perspective, numerically similar network addresses should be aggregated. For example, let’s say that an ISP has been given a Class B-sized network address (a /16 network prefix). An address block of this size can support 65,535 endpoints. The ISP isn’t too likely to encounter any single customer that requires all this address space. Instead, it is much more likely that the ISP will have dozens or hundreds of customers that each require a small number of addresses.

Without trying to chart an entire /16 network’s potential allocation scheme, let’s just agree that it would be to everyone’s benefit to be able to just tell the rest of the Internet about the /16 network address. This simplification relieves you of the burden of having to communicate explicitly about each /27 or /24 or /20 network address that might have been created from it. All those subnetworks begin with the same 16 bits anyway. Thus, they canand shouldbe aggregated and advertised to the Internet as a single network prefix. The subnetworks’ longer bitstrings are of use only within that service provider’s network. In this sense, aggregatable network addresses function precisely like subnets created from a single network address.

Unfortunately, not all the Internet’s address space can be aggregated to any appreciable degree. Benefiting from CIDR’s aggregatability means that you have to start handing out network address blocks based on geography. During the Internet’s early days, any organization could request its own address space. Such requests were satisfied as they were received, and the actual range of addresses allocated to that organization depended only on the size of the request. Thus, there was no attempt to correlate geography and IP network addresses. This policy enabled the notion of an IP address space being portable from ISP to ISP but effectively defied the promised benefits of aggregatability. IANA and the IETF countered by effectively declaring address space given to ISPs to be nonportable. We’ll revisit this volatile issue in the last section of this chapter, as well as in subsequent chapters.

Aggregation Versus Subnetting

CIDR introduced mechanisms designed to enhance aggregatability. The first and foremost of these mechanisms was simply the ability to define network addresses on any bit boundary instead of on every eighth bit boundary. VLSM had previously demonstrated the wisdom of this bitwise approach. Despite the handicaps of not being routable and, therefore, of only local significance, VLSM had a dramatic positive impact on the efficiency with which IP network blocks could be used.

CIDR built upon this approach by implementing subnet masks as routable information. That’s a point that often creates confusion, even among experienced network engineers! For many years, subnets were limited to local use. The distinction between subnets and network addresses was reinforced by the routability of only those addresses that conformed to Classical IP’s octet boundaries. Networks created along other boundaries (such as a /23 or a /25 instead of a /24) couldn’t be routed. Thus, they were deemed useful only locally. CIDR changed that by doing away with the old routable classes. Under CIDR’s rules, anything from a /5 to a /32 prefix could be routed. Thus, the old, easy delineation between a subnet and a network was rendered obsolete. The difference between a subnet and a network address is now just semantic.

A practical implication of this evolutionary step is that now you must pass subnet mask information explicitly as part of the routing information. Thus, masks are still essential! If anything, the term subnet mask has become a misnomer that only contributes to confusion. It is properly termed a network mask. In fact, the shorthand convention of a slash followed by the number of bits used to identify the network address is intended just for human use. When configuring routers, you are still expected to enter the subnet mask in good old-fashioned dotted-quad style. Thus, instead of specifying a /23 route, you must enter a mask of 255.255.254.0. In binary, that translates into

11111111.11111111.11111110.0000000

Without the mask, it would be impossible to determine how many bits of a CIDRized IP address were used to identify the network versus the hosts within that network.

CIDR obviously had a dramatic impact on routers and routing protocols. It required a comprehensive upgrade to the Internet’s infrastructure before it could be implemented and supported. Despite the logistics and cost of this migration, CIDR became an unqualified success.

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. (more…)

The old saw still cuts true: Every little bit helps. In that spirit, the IETF attacked in all directions as it tried to stave off the impending, projected Date of Doom. Some of the measures, as you’ve seen so far in this chapter, were fairly dramatic, big-ticket items. Others were remarkably simple and easy, yet effective. In this section, I’ll show you some of the simple items that helped the Internet cope with its addressing crisis. These efforts included some measures to increase the pool of available address space. Others were intended to set the stage for abolishing class-based network architectures in favor of a classless architecture. (more…)

By 1992, the Internet was growing at rates that were straining it, its address space, and its physical and logical support infrastructures. Concern was running high among the techies behind the scenes at the IETF, but nobody else really seemed to grasp the problem. In November 1992, RFC 1380 was released. This RFC was strictly informational in nature, but it caused a sensation the likes of which the network engineering community has seldom experienced!

Certain parties within the IETF had already calculated the projected date by which the remaining supply of Class B address spaces would be exhausted. After that point, the other address classes would also come under increased pressure, and the failure would increase exponentially. The bottom line was that everything would start crashing sometime around March 1994. This Date of Doom became the rallying cry for mobilizing engineering resources to resolve all sorts of problems, big and small, short-term and long-term, for the sake of maintaining the Internet’s viability. (more…)

To better demonstrate how VLSM works in practical terms, Table 4-6 shows the progression from the sample network’s base address (192.168.125.0) through the defined subnets. Pay particular attention to the binary and decimal translations for each subnet’s base and terminal addresses. In decimal terms, you are progressing sequentially through the address space. In binary terms, you can see that each network uses a different combination of high-order bits in the last octet to identify the subnet. This might seem strange, but it is eminently logical. I distinguish between host and subnet bits in the binary address by indicating the subnet bits in bold italic and then delineating the two subfields with a dash (-). Ordinarily, you wouldn’t find a dash in the middle of a bit string. (more…)