This original system was simply a loose agreement among network/host administrators on a set of mnemonic names that correlated to numeric IP addresses. This agreement formalized an existing practice. These administrators had already realized that their user communities either couldn’t or wouldn’t use numeric addresses to access specific hosts. Thus, virtually all of them had deployed a scripted function that allowed their users to use mnemonic names for host access. Their scripts checked those names against a small but ever-growing list of known host addresses and provided an automatic translation between names and numbers.

Because this function was highly localized, there wasn’t much consistency from network to network with respect to host naming conventions. After all, this was a localized translation function; the names used didn’t need to be the names used by those remote hosts’ administrators. They could be somewhat arbitrarily selected. For example, a name could be the local user’s nickname instead of the host’s official name. Needless to say, this had the potential to create great confusion. More importantly, given the highly decentralized nature of maintaining such local lists, the probability of disseminating information about moves, adds, deletes, or other changes quickly and evenly throughout the ARPANET community was slim to none. Thus, you could reasonably expect connectivity problems caused by this attempt at simplifying host access for users. Life is full of delicious irony!

hosts.txt

Fortunately, these sage administrators communicated with each other and often published documents requesting comments (ARPANET’s RFCs) from other administrators. Together, they realized that it was critical to standardize on a format for naming hosts as well as a set of names for known hosts. To ensure future scalability, they further agreed to have this list managed centrally to ensure that it remained as up-to-date and evenly distributed as possible. This mechanism became known as the hosts.txt file. The Stanford Research Institute maintained the hosts.txt file via its Network Information Center (NIC) and transmitted to known hosts using the file transfer protocol (FTP). RFCs 952 and 953 spelled out the details of this update mechanism and procedure in October 1985.

NOTE

A vestige of the original hosts.txt file and the mind-set that led to its creation remain in evidence even today. Most operating systems support the creation of a file that correlates IP addresses with mnemonics that are of local significance only. For example, UNIX systems contain an etc/hosts file to support this function.

The idea was simple enough: maintain a list of all known hosts, as well as certain other data that would be useful in deciphering the list. This list would be nothing more than a flat text file that was pushed to all administrators in the network on a regular basis. Updating local lists was up to each administrator. Failure to do so meant that their users did not have access to the most current information about known hosts.

Although it might sound foolish to try and track all known hosts in a single flat file, you must remember that this dates back to RFC 606, published in December 1973. The ARPANET was using IP, but the IPv4 address scheme had yet to be devised. The address space was still only 8 bits long. Mathematically, there couldn’t be any more than 255 hosts.

Problems with Flatness

The hosts.txt file approach worked well for a couple of years. However, several inherent problems threatened the usefulness of this mechanism as the Internet continued to grow:

• Collision of host names Locally defined host names create the possibility of a single character string being used to identify two or more different end systems. This is known as name collision, and it can result in an inconsistent translation of names to numeric addresses.

• A limited number of mnemonically useful names A finite number of useful and meaningful character strings can be used to name hosts. Imagine, for example, that only one host in the world could have the name klingon. Absent a hierarchical naming system, the first Trekkie who gave his or her computer that name would prevent anyone else in the world from using it.

• Timeliness and uniformity of implementing updates The “official list” couldn’t be updated in real time, so a batch-oriented approach was required. In other words, changes, deletes, and additions to the hosts.txt file would be batched and then sent out periodically. Depending on how frequently the updated list was sent out, a host could be online but still inaccessible. An additional time lag could be experienced if network or host administrators did not promptly process the newly received hosts.txt file.

• The lack of a name dispute resolution mechanism and authority Some mechanism is needed to reconcile cases in which two or more people select the same name for their box. In the days of the hosts.txt file, there was no way to resolve such disputes aside from embracing a first-come, first-served philosophy. But even that approach wasn’t perfect, because updates were done in a batched manner.

Generally speaking, these problems were rooted in the flatness of the address space. Flatness in this particular case means the absence of a hierarchical structure. That by itself limited the number of meaningful names that could be assigned to hosts. Each name could be used only once throughout the worldat least the parts of the world that interconnected via the Internet! Although the NIC was responsible for tracking hosts on the Internet, it had no authority to resolve disputes over names. Thus, a chronic problem became the collision of names. In a flat environment, host names had to be unique.

You could cope with this lack of hierarchy by assigning pseudo-random strings of letters to substitute for names. That could help ensure uniqueness for a very long time, but it utterly defeats the intent behind having a mnemonic name that users can understand and remember better than pseudo-random strings of numbers.

Aside from the limited number of names that could be both useful and usable, the notion of sending out a flat file periodically to update distributed tables meant that there would be a gap between when a host came online and when distributed users would know it existed.

The largest problem with the hosts.txt approach was its inability to scale upward. As more hosts on more networks came online, the challenge of keeping them up-to-date in the file grew immeasurably. Not only were there more hosts to keep track of, each of them also had to receive the hosts.txt file. After a while, just updating the file of known hosts became almost a full-time job.

NOTE

The person whose job it was to maintain the hosts file was informally known as the hostmaster. This function exists today even though the hosts.txt file has long since slipped into obsolescence. Today’s hostmasters assign IP addresses to endpoints and manage IP address space, among other duties.

By September 1981, with a mere 400+ hosts on the ARPANET, it had become painfully obvious that there had to be a better solution. A series of RFCs began emanating from the technical constituents of ARPANET calling for a hierarchical approach to Internet names. Although each examined the same problem from a different perspective, the prevailing theme remained the need for a hierarchical namespace. Over time, these disparate RFCs coalesced into a distributed, hierarchical system that became known as the Domain Name System (DNS).

NAT, by its very nature, conceals source and/or destination IP addresses. Many problems can emanate from that basic, inescapable fact. You can categorize these problems by their impact area:

• Technical incompatibilities

• Scalability and network performance issues

• Logistical difficulties

Each of these is examined briefly in the next sections.

Technical Incompatibilities

The most egregious problem is that NAT breaks any network-based application that requires end-to-end session integrity. This is a direct result of NAT’s interception of inbound and outbound IP packets and rewriting their headers to achieve the desired address translation.

Some of the specific technologies that are at least partially incompatible with NAT include SNMP, IPSec’s authentication and encryption technologies, and the emerging Mobile IP. Many network engineers believe that NAT is directly responsible for the inability of IPSec and Mobile IP to achieve any meaningful degree of market acceptance.

Scalability

Other problems with NAT have nothing to do with technical incompatibilities. For example, NAT imposes a potentially substantial overhead on any router that supports the translation function. This overhead can be substantial enough, depending on the configuration, to prevent graceful scalability. Hardware-based appliances have appeared on the market to prevent such adverse effects on your network, but not everyone who needs to implement NAT can afford to purchase another device. Consequently, the point about NAT’s impacts on router performance remains valid.

Another problem is that the probability of experiencing address problems increases greatly with NAT. The problem becomes worse, not better, with each additional translator you configure in your network. Think about it: The more translation devices you have in your network (ideally, you’d have one for each egress point), the more address tables you would have. Keeping them synchronized can be challenging, time-consuming, and onerous.

Logistical Challenges

There are logistical challenges, too, with a NAT network. For example, security is a double-edged sword. This chapter has treated NAT’s privacy-enhancing aspect as a positive attribute. However, that capability also has a dark side. Debugging a problem or chasing a hacker can run into a brick wall at a NAT simply because the true source IP address is hidden from destinations. Although such challenges aren’t showstoppers, they are just some of the little “gotchas” that await any network administrator who must implement and use NAT.

In all honesty, NAT has become an unavoidable part of the Internet technology base. Recent policy changes regarding the availability of directly registered address space (as discussed in earlier chapters) have made it all but necessary for many organizations that no longer qualify for their own address space. Regardless of how you feel about it, NAT is here to stay!

Originally described in RFC 1631 in May 1994, NAT was originally conceived as yet another of the stopgap measures to shore up the flagging IPv4 address space. If you take the time to read this document (www.ietf.org/rfc/rfc1631.txt), you will see that the IETF was absolutely counting on IPv6 to save the Internet from its impending address crisis. This document explicitly identifies the two biggest problems facing the Internet as a shortage of IP addresses and the scalability of routing across the Internet. In Chapter 5, “The Date of Doom,” we looked at how these two are really different perspectives on the same problem, so their appearance in RFC 1631 shouldn’t be a startling revelation.

What is startling is the explicit admission that at least some parties within the IETF were concerned that CIDR (then under development) might not buy enough time for IPv6 to be completed. That’s a staggering statement! CIDR was initially conceived as just another stopgap tool to buy time for the new IP protocol and addressing system to be developed. This fear became the motivator for the development of NAT.

Framing the Problem Statement

The authors of RFC 1631 apparently believed strongly enough in their proposal to say the following:

It is possible that CIDR will not be adequate to maintain the IP Internet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary.

With the benefit of hindsight, that remarkable statement is both amusing and illuminating. As late as the middle of 1994, there was still great debate as to whether a migration to a classless IP address system was even needed. This is significant because CIDR was stipulated in a series of RFCs published in September 1993, 8 months prior to the release of RFC 1631 NAT! If nothing else, this should give you some indication that there was little consensus on anything other than three basic facts:

• The IPv4 address space, in its class-based configuration, was about to break.

• The correct way to solve the problem was to make a completely new Internet Protocol (eventually named IPv6).

• Something needed to be done immediately to forestall the impending collapse of the classful system long enough to roll out the new version of IP.

Beyond these three basic facts, consensus broke down. Nobody really knew the correct approach to take, so the IETF attacked in all directions. The development of NAT capability was aimed at enhancing the usefulness of the RFC 1918 addresses. One of the single biggest “traps” inherent in the use of nonunique addresses was the inability to convert them to routable addresses. Should requirements change, and Internet connectivity become necessary, anyone using RFC 1918 addresses would face a painful address migration. In comparison, address translation seemed like a welcome alternative.

As significant as NAT has become, it is almost laughable to think that at its inception it was being bandied about as an alternative to CIDR. With hindsight, it is remarkably obvious that CIDR and NAT are different tools intended for different uses. Both technologies were also so successful at buying time for IPv4 that they are still in active use.

Technical Overview

Before we get too caught up in technical details, one salient point to understand is that NAT is a router-based function. It was designed to provide hosts on a private network with a means of communicating transparently with destinations outside that network, and vice versa. Traditionally, NAT has been used in conjunction with RFC 1918 addresses (specifically designed for use in addressing private numbers), but that is not a mandate. NAT can be used to translate unique addresses into other unique addresses, too. Either way, it enhances security by hiding addresses within a private network from the outside world. Thus, NAT can be highly appropriate for securing a network, regardless of what kind of IP addresses are in use.

The way this works is actually quite simple. A gateway router (one that sits at the border of two different networks) functions as an address translator between two neighboring networks. This translation means that a NAT network has different types of IP addresses, each serving a slightly different purpose. Before we venture too far ahead, you need to understand the subtle distinctions between these address types. If you assume that an enterprise is using NAT to establish communications with the Internet, this helps you establish a frame of reference for understanding the differences between the address types. The original specification for NAT had two address types:

• Inside local (IL) address This is the address of a host inside an enterprise’s network as it is known within that network. The IL may be globally unique (either obtained from the ISP or directly registered to the enterprise), or it may be selected from an RFC 1918 reserved range. Communications within a network may occur directly using IL addresses, without the need for translation.

• Inside global (IG) address This is the IP address of a host inside an enterprise’s network as it appears to the Internet. That last phrase is the critical distinction between an IG and an IL address. IG addresses must be globally unique, regardless of whether they were obtained from the ISP or directly registered to the enterprise. It is important to recognize that the IG address is advertised to external networks and is used for routing to the internal network. Thus, RFC 1918 private addresses cannot be used as IG addresses.

Together, these address types let a network communicate with other IP-based networks without having to reveal its internal addresses. That’s a key statement, because so many people think that the only reason NAT exists is for use with RFC 1918 addresses. The truth is, it can be used with any network address and may be implemented to enhance a network’s security regardless of whether it uses private or globally routable addresses.

The NAT router must keep a tableknown as an address translation table (no acronyms, please)that correlates these different address types. How this correlation works depends on whether we are talking about packets coming into, or going out of, that private network. We’ll look at both traffic types in the next section.

Over time, NAT has become much more sophisticated and feature-rich. Today’s NAT can translate external as well as internal addresses and can even translate TCP port addresses. Later in this chapter we’ll look at some of the technological advances that NAT has benefited from. For now, let’s continue with our examination of the basic NAT specification. This will give you a context within which you can better appreciate the enhancements made to NAT since RFC 1631.

Operational Mechanics

NAT is a router-based function that must reside at a network’s border. For the purposes of explaining how a NAT works, let’s start with a very basic implementation topology. Take a look at Figure 7-1. This figure shows a simple stub network that consists of just one local-area network. This LAN uses private addresses in the 172.16.9.0/24 block. NAT is performed at the gateway router between that network and the Internet. This connection is the only egress point for this network.

Figure 7-1. NAT Translates Nonunique and Unique Addresses at the Border of a Stub Network

For now, let’s make the simplifying assumption that the end user entered an IP address as opposed to a host and domain name string. This lets you focus on the mechanics of NAT without the added complexity of translating a name into an IP number. We’ll look at how that is done in Chapter 9, “IP Multicasting.” Given this simplifying assumption, when an endpoint on that LAN tries to access a host that resides outside its boundaries, the request can’t be resolved locally, and the gateway router accepts it. That router has only two interfaces configured: the LAN and a serial connection to the Internet. Because it is seldom useful to send a datagram or packet back through the interface it came in on, the router has only two choicesdrop the packet or send it out the other interface. Using the other interface requires that some work be done to the datagram, because that is the interface where NAT resides.

The first thing NAT does is check the header of that packet to determine its source IP address. The packet is coming from an endpoint located somewhere within the network, so the source IP address is an inside local address. NAT won’t permit such addresses to pass into an external network. NAT searches its address translation table for this address. If no entry is found that corresponds to that destination address, the packet is simply discarded. If a match is found within the address translation table, the corresponding inside global address is retrieved from the table and is used in lieu of the inside local address in the packet’s source address field.

Table 7-4 summarizes this gateway router’s address translation table. For the sake of example, let’s pretend that the globally routable address is in the 254.16.35.0 range. That address is not a valid address. In fact, it’s a part of the reserved Class E address space. But I am extremely reluctant to use “real” IP addresses in an example.

After a packet’s source address field is updated with the appropriate inside global address, the packet can be launched out the router’s interface and into the foreign network that lies beyond. Although that’s a brief-enough synopsis of how NAT treats outbound packets, it is also necessary to see how NAT supports address translation for incoming packets.

Very generally speaking, there are two basic reasons for packets to be inbound to a NAT network:

• Responses to a session generated from within the NAT network

• Sessions that originate from external hosts

Regardless of the variety, packets that are inbound to a NAT network pass through the same process. Such packets are sent to machines bearing inside local address types. As such, they must be intercepted by the NAT for translation of the destination address to an inside global address.

The process by which NAT translates IG addresses to IL addresses is exactly the reverse of the one we just looked at. An incoming packet is accepted by the NAT (which could be a process configured on a router interface, firewall, or other specialized network appliance), and its destination address is examined and hashed against the address translation table for a matching record. If the destination address (really an IG address) is known, the corresponding IL address is then substituted in the packet’s destination address, and the packet is launched into the private network. If the destination IG address isn’t known, the packet is discarded.

Extend This Post Reach]]> http://www.ciscotrick.com/nat/feed/ 0 http://www.ciscotrick.com/private-address-spaces/ http://www.ciscotrick.com/private-address-spaces/#comments Fri, 15 Aug 2008 08:46:25 +0000 mekichan http://www.ciscotrick.com/?p=114 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.

In March 1994, the IETF released RFC 1597. This document acknowledged that many organizations were using TCP/IP and IP addresses but remained isolated from the Internet. This was perfectly acceptable in the days before commercialization, because the installed base of TCP/IP networks was relatively low. But the commercialization of the Internet threatened to rapidly deplete the IP address space.

The theory behind RFC 1597 (and its update in RFC 1918) was that a block of addresses could be reserved for use in private networks. This afforded a legitimate mechanism for networks that needed IP for application support but did not want or need to access the Internet. Such a mechanism would serve a twofold purpose.

First, it would mitigate the demand for new IP addresses. This would help make the remaining address blocks last a little longer. The downside is that these addresses cannot be routed over the Internet.

Second, this approach would help keep down the swelling of the Internet’s routing tables. Reserved address blocks cannot be routed through the Internet and are limited to local use.

NOTE

The addresses reserved in RFC 1918 are sometimes called nonroutable addresses because they cannot be routed across the Internet. However, that does not mean that they can’t be routed! Quite the contrary: Many a private IP WAN has been built successfully using these so-called nonroutable addresses. The reserved addresses can be routedjust not across the Internet.

The Mathematics of Private Addressing

One very common misperception about RFCs 1597 and 1918 is that these documents reserved an entire Class A, an entire Class B, and an entire Class C network address space. People who think this either don’t really understand the IP address architecture or haven’t read the RFCs. Probably both. Table 7-1 lists the address blocks that were reserved in RFC 1597 (and reinforced in the updated RFC 1918, which is still Internet Best Current Practice #5) for use solely in private networks.

A quick glance at Table 7-1 should demonstrate that entire blocks of Class A, B, and C network address space are indeed not reserved! In fact, if you read those RFCs, you’ll see that only the address block taken from the Class A space matches the classical boundary for that address. Thus, the space reserved from the Class A address space by RFC 1918 is, in fact, an entire Class A address space. 8 of its address bits are used for network identification. That leaves 24 bits for host addresses. For this reason, the RFC refers to this reserved address block as the 24-bit address. This is in stark contrast to the popular convention of explicitly identifying the number of bits in a network address.

The others don’t follow the classical boundaries so neatly. The address block reserved by RFC 1918 within the Class B address range, for example, is actually a block of 16 numerically contiguous Class B spaces. If you plotted this out in a binary string, you would see that the Class B RFC 1597 space offers 20 bits for host addresses (rather than just 16, as is found in a Class B network). Thus, in the RFC, this address type is called the 20-bit address. As I mentioned before, this is very confusing and is contrary to the established conventions.

Table 7-2 shows you the binary and decimal limits of this reserved address space. The network mask is indicated in bold so that you can more easily see that this network block uses 12 bits.

The Class C network space is equal in size to a set of 255 numerically contiguous Class C network addresses. If you think about this, and visualize it in binary, you will realize that this reserved address space offers 16 bits of host addresses. Thus, the block reserved from the Class C address space is identical in size to a Class B network block. Table 7-3 shows the actual reserved range of addresses. Again, for your visual reference, the bits used to identify the network are indicated in bold. The other bits are used for host addressing.

Benefits and Drawbacks of Private Addressing

Having waded through the mathematics of reserved private address blocks, it’s probably appropriate to look at some of the operational impacts of private addressing. In other words, let’s look at the benefits and limitations of this tool.

Benefits

The greatest benefit of using private address space is that the global Internet address space is conserved for use where it is really needed. Although this is a noble goal, the benefits are distributed externally: The organization implementing private addressing is helping the Internet community at large, but not necessarily itself, in the processat least, not if this were the only benefit.

One other benefit, perhaps the most compelling of all, is that you don’t need permission to use these addresses. They were created explicitly to be unique per network but nonunique globally. As you saw earlier in this chapter, one of the more effective ways that IANA’s pool of available addresses was protected was by rationing them carefully. Gone are the days when address blocks were handed out to anyone who asked. With the introduction of RFC 1466, a stringent standard of justification was imposed on anyone asking for address space. Even service providers had to pass stringent criteria to justify being assigned more address space. So, here was the classic carrot and stick: Use the RFC 1597/1918 addresses hassle-free, or butt heads with the Keeper of Unassigned Addresses in an almost-always-futile attempt to procure your own addresses.

Another, more-subtle reason to use private addressing is that the network becomes inherently more secure. Because private address spaces are not valid routes across the Internet, a network that used them couldn’t be hacked via the Internet. Of course, such a network would have a difficult time communicating with the Internet if it had those addresses in the first place, but hopefully you get my point.

Drawbacks

The drawbacks of using the private address space reserved in RFC 1918 are relatively easy to enumerate. There’s exactly one. That first, last, and only drawback is that these addresses cannot be routed across the Internet. But they can be routed internally within a private network. You’re probably thinking that this isn’t a flaw; it’s a feature. And you’re right. But this becomes a problem if your requirements change after you implement RFC 1918 addresses. For example, if you suddenly find that your users require connectivity to, or accessibility from, the Internet, this limitation can become quite problematic. Quite literally, if you try to connect to the Internet using RFC 1918 addresses, you won’t be able to communicate at all. The ISP you are connecting to won’t recognize your address space (identified in each of your IP packets via the source address field) as routable, so no inbound packets will be able to reach you. That includes packets generated in response to your queries!

That’s not to say that using RFC 1918 addresses is risky. In fact, if you have no plans to connect to the Net, RFC 1918 is perfect for you.

When requirements change like that, you aren’t necessarily facing an address migration. This is where NAT can be extremely useful.

Supernetting is the concept of taking two or more numerically contiguous network address blocks and consolidating them into a single, larger network address. Thus, if you had a pair of /25 networks that happened to be numerically contiguous, you could probably aggregate them into a single /24 network. This would free you from having to route between the two /25 address spaces. Supernetting would also let you advertise just one network block (the /24) to the world instead of two distinct /25 network addresses.

I say probably because certain rules and limitations apply. Just because two network blocks are numerically contiguous doesn’t mean that they can be supernetted. However, if they are not numerically contiguous, they absolutely cannot be formed into a supernet. The next section looks a bit more closely at some of the rules that govern the creation of supernets.

The Rules

Supernetting, like many other topics indigenous to the IP address space, gets a bad reputation for being complex and difficult to understand. That’s unfortunate, because supernetting is one of CIDR’s most important features. More importantly, it can be remarkably easy to understand if it is explained properly. I have already given you a thumbnail sketch of the supernet function. Now it’s time to look at the provisos. There are only three basic rules for supernet creation:

• Numeric contiguity

• Even divisibility

• Single interface

Each of these is examined in the following sections to help you better appreciate their impact on supernetting an address space.

Numeric Contiguity

In order for supernetting to be possible, network addresses must be numbered consecutively. This rule is probably the one that is the most intuitive of the three rules for creating supernets. If two network address blocks are not numerically adjacent, attempts to join them must necessarily include all the addresses that keep them apart. You can more completely understand what that means by looking at an example and learning from it. Table 6-5 demonstrates a /24 network block that has been subnetted into eight fixed-length subnets using a mask of 255.255.255.224. That mask, if you’ll refer back to Table 6-1, equates to a /27 CIDR network.

The third column of Table 6-5 identifies the direct contiguity of each of the eight defined subnets. Subnet 0 is numerically contiguous only with subnet 1, and subnet 1 is numerically contiguous with both subnets 0 and 2. This much should be fairly obvious. Getting back to my point about nonadjacent addresses, suppose you want to supernet subnets 1 and 3. You can’t do that directly because subnet 2 (with its 32 addresses) lies between them. However, it might be possible to create a much larger subnet by integrating subnets 1, 2, and 3. However, we still have two more rules to examine before we can state with authority that such a supernet is technically feasible!

Even Divisibility

The next test to determine the supernetability of an address space is even divisibility. This test is designed to ensure that network addresses end on the correct bit boundaries to preserve the symmetry of a CIDRized address space. Even divisibility is determined by dividing the octet that contains the boundary between host and network address fields by the number of networks you are trying to supernet together. For example, if you were to combine two /24 networks, the third octet of the first network address must be divisible by 2. If you wanted to combine eight /24 networks, the first network’s third octet would have to be divisible by 8.

In essence, the first network block in a supernetted group of addresses forms the base address of the new, larger address block. Everything else in the supernet is built from it. Thus, it is imperative that this initial address block conform to CIDR bit boundaries.

Table 6-6 helps you better understand why this is the case. This table builds on Table 6-5 by showing both the numerically contiguous subnets and whether the appropriate octet is evenly divisible. I have used bold to indicate which octet of each address you look at to make this determination.

Let’s look at some of these individual base addresses a bit more closely so that you can better appreciate the logic behind the rule of even divisibility. Table 6-7 shows the binary mathematics that underlie the test of even divisibility. The 2 bits that are critical to determining even divisibility for our supernet example are shown in bold italic.

In effect, this proposed supernet reduces the size of the network’s mask from 27 bits to 26 bits. For the symmetry of the address space to be conserved, that 26th bit must start at 0. In Table 6-7, 192.168.64.32/27 and 192.168.64.64/27 are supernetted together and are advertised as 192.168.64.32/26. In binary math, the next increment above 00 is 01. Thus, the two /27 network blocks can both be referenced by the same 26-bit network address.

The next example does not conform to symmetry and doesn’t work as expected. Although in binary math 01 increments to 10, the increment requires you to reset the least-significant bit to 0 and then increment a more-significant bit (the leftmost of the two number columns) to 1. Thus, the bitstring differs for the two subnets, and they cannot be supernetted together. Table 6-8 shows you how this bitstring differs. The bits significant for supernetting are in bold italic.

Table 6-6 shows that the only subnet that can’t become the base of a two-network supernet is subnet 3. Its final octet is an odd number95. Now you know why. All the other subnets can become the base of a two-network /26 supernet. Thus, of all the potential combinations for supernetting, the only set that doesn’t meet both the criteria (even divisibility and numeric contiguity) is the pairing of subnets 3 and 4.

Single Interface

The last critical precondition for supernetting is that the two or more network blocks that are to be aggregated must be connected to the same interface. Otherwise, why bother? If they are connected to different interfaces, you must route between the two networks. In practical terms, this rule does not preclude you from creating a supernet from two networks that are connected to different router interfaces. However, this rule forces you to reconfigure your physical topology so that the combined supernet connects to only one interface.

Figures 6-2 and 6-3 better demonstrate how the single-interface rule can have a physical impact on a network’s topology. Together they demonstrate the before-and-after perspective of supernetting.

Figure 6-2. Before: Two /27 Networks Routed Together

Figure 6-3. After: Two /27 Networks Supernetted to Form a /26

Figure 6-3 shows a network after supernetting. Two small LANs are routed together; all traffic flowing between them must be routed.

Obviously, this criterion adds a physical element to the purely mathematical requirements of supernetting’s first two prerequisites. You must accept the fact that, unless a pair of subnets are physically constructed such that they can be interconnected, and then use the same router interface, they cannot be supernetted. This is true even if two or more subnets pass the criteria for contiguity and divisibility. Thus, the actual number of supernets that can be formed is a subset of those that are mathematically feasible. It is impossible to determine which subnets are supernetable without physically examining each subnetwork.

Aggregation Versus Supernetting

Supernetting and aggregation are extremely similar concepts, especially mathematically. It is how they are implemented that makes them distinct. Aggregation is what routers to do reduce their workload. They try to shorten network prefixes to minimize the total number of prefixes that must be advertised externally either to the rest of the network or to the Internet. Supernetting, by virtue of its single-interface rule, requires physical consolidation of networks as opposed to just a logical consolidation of the network addresses into a smaller prefix.

Figures 6-4 and 6-5 better demonstrate aggregation versus supernetting.

Figure 6-4. From the Internet’s Perspective, a Pair of /24 Networks Are Aggregated as a /23

Figure 6-5. The Pair of /24 Networks Are Supernetted into a /23

In Figure 6-4, you can see that interconnectivity between the two /24 networks is achieved via the same router. This router recognizes that the two networks are numerically contiguous, and it advertises just a single /23 network prefix to the Internet. Thus, the Internet can reach both networks using just 23 bits of their network addresses. Inbound packets get only as far as the router shared by the /24 networks. That router must then examine the destination address of each inbound packet to determine which of its two /24 networks the packet is destined for. Making such a determination requires the router to make a routing decision based on all 24 bits of the two network prefixes.

This captures the essence of aggregation, albeit on a very small scale. There is a strong correlation between geographic distance and the number of bits you need in order to reach any given destination. A good way to think about how this works is navigating your way to your favorite restaurant. If that restaurant is located in Kansas City, Mo., your initial directions can be as simple as “Go west” if you are located east of the Mississippi River. However, after you reach that city, you need much more precise information in order to find your way through the complex network of streets and storefronts in order to find your destination. IP-based networks are no different. Precision is just defined in terms of how many of the network prefix’s bits you are looking at.

Figure 6-5 shows the same network topology and also advertises just a single /23 network prefix to the Internet. However, that’s where the similarities end. The two /24 networks have been integrated into a /23 network. This network requires only a single connection to the router. More importantly, the router need not look at the 24th bit of an inbound packet to figure out what to do with it: All inbound packets can be forwarded using just the /23 network. The individual /24 networks have, in effect, ceased to exist. In their place is a single, larger network.

This pair of examples use a limited scale to demonstrate aggregation versus supernetting. In reality, aggregation can occur on a very large scale. In fact, ISPs might aggregate hundreds or thousands of customer networks into just one network prefix that gets communicated to the entire Internet. This, of course, raises an issue. Is it possible to overaggregate? In other words, which is better: longer or shorter network prefixes?

Which Is Better: Longer or Shorter?

Under CIDR supernetting rules, no distinction is made between network and subnetwork addresses. Both are regarded as a network prefix to a host address, and routing decisions can be made on the entire prefix. I say “can” because it isn’t mandatory.

We tend to take the Internet for granted. Everything we could ever hope to find is always right at our fingertips. At least, that’s how it seems! However, if you look a little deeper, you discover a concept known as reachability. Reachability is a general term that describes whether any given destination can be reached through the Internet. The very fact that such a term exists should tell you that reaching intended destinations is not necessarily guaranteed. Which ISP networks you need to traverse to satisfy any given communication request across the Internet, and which approaches those ISPs use for routing, can have a huge impact on the reachability of destination networks. This is a by-product of network aggregation.

NOTE

A /20 is considered the smallest network size for global routability. That’s not to say you couldn’t advertise a smaller block, such as a /24 network. Smaller blocks run the risk of not being accepted universally throughout the Internet simply because each ISP sets its own policy as to how long a prefix it will support. Ideally, there won’t be any standalone /24 network addresses; all should be created from within much larger ISP network address blocks and be advertised to the Internet as those larger blocks.

Each ISP decides how it will route across its own network. There are many different approaches, one of which is based on the principle of the longest numeric “match.” Having examined how supernetting and CIDR were intended to improve route aggregation across the Internet, you can now better appreciate the pros and cons of network prefix length. It’s a concise debate. Longer prefixes are much more precise. But they result in the need to track a greater overall number of routes than if you abstract a smaller network prefix from among a larger number of more-specific prefixes.

The aggregatability of the CIDR IPv4 address space gives you the best of both worlds: You can use very long (and therefore very precise) network prefixes where you have to, and very short, less-precise network prefixes where you can. Ostensibly, the closer you are in an internetwork to the destination network, the greater the precision you require of the network address. The farther you get from that destination, the less precise the network prefix can be. In this manner, routes can be generalized, with specificity increasing with proximity to the destination. In simpler terms, and as discussed earlier in this chapter, you might be able to accurately route an IP packet to a service provider network using just 16 network address bits. Then you can look at additional bits to figure out what to do with that packet after it’s on the service provider’s network.

The bottom line is that both longer and shorter prefixes play an important role in the proper functioning of an IP network. This works due to the concept of aggregation.

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.

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.

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.

Here are some of the quick fixes employed by the IETF:

• Emergency reallocation of classful address spaces

• Emergency rationing of the remaining address spaces

• Urging holders of over-sized class-based addresses to return any unused or underused blocks

• Reserving address blocks for use in private networks but not across the Internet

• Changing the criteria for obtaining address spaces to make it significantly more difficult for enterprises and organizations to get their own address space

Each of these tactics helped, in some small way, to stave off the Date of Doom. Cumulatively, they revolutionized how the Internet is accessed and used. Internet users are still experiencing the impacts of these changes today, sometimes for the first time. Throughout the remainder of this chapter, we’ll examine each of these tactics and their impacts on IP network users so that you can better appreciate some of the subtle challenges inherent in obtaining and managing an IP address space in today’s environment.

One of the other, more-significant proposals that emanated from the IETF’s emergency effort was to more fully embrace the concepts proven in VLSM. Although VLSM was just a grassroots innovation, there was tremendous benefit in being able to flexibly devise subnet masks. Logic fairly dictates that there would be even more benefit if network masks (as opposed to just subnet masks) were equally flexible. Imagine being able to define network addresses at any bit boundary! Unfortunately, that would require an almost complete rewrite of the IPv4 address space and its supporting protocols. That’s nearly as big a change as IPv6. This proposal ultimately came to be known as Classless Interdomain Routing (CIDR). CIDR would abandon class-based addresses in favor of bit-boundary network definitions. We’ll look at CIDR and its architecture, symmetry, benefits, and uses in Chapter 6. For now, let’s continue to focus on the IETF’s quick fixes.

Emergency Reallocation

One of the simpler devices in the IETF’s bag of tricks to buy time was documented in RFC 1466. This document basically called for the as-yet still-unused Class C network address space to be reallocated into larger, equal-sized blocks. These blocks could then be allocated to regional registries to satisfy the growing and increasingly global demand for Internet access.

Table 5-1 shows the new allocation scheme, including the specific address blocks that were reallocated.

These blocks are huge. In fact, they represent the equivalent of two Class A network blocks. You might question how serious the impending address shortage could have been given that so many addresses were still available. That’s a fair question, but you have to remember that this was a proactive initiative to shore up the impending depletion of the Class B address space. The IETF was using all the resources at its disposal to ensure that a failure did not occur.

The important thing to note about this reallocation was that it set the stage for two things:

• Due to the fact that the large reallocated blocks were to be handed out to global registries, route aggregation could be done much more effectively as the Internet scaled to global proportions.

• Migration away from a class-based address architecture toward a more flexible bit-level definition. (This approach came to be known as Classless Interdomain Routing [CIDR]. It is thoroughly examined in Chapter 7.) Removing so many addresses from the pool of available Class C networks was a powerful statement of the IETF’s intention to evolve away from the class-based addressing system.

Each of these aspects warrants closer inspection.

Improving Aggregatability

Reallocation of unassigned Class C network blocks enabled a dramatic improvement in route aggregatability in comparison to the previous size-based classful architecture. Aggregatability is a mouthful of a word that simply means the ability to be aggregated, or lumped together. Stop and think about that: This inventory of Class C blocks was previously handed out directly to end-user organizations solely on the basis of size. This meant there was little, if any, correlation between numeric contiguity (which is an absolute prerequisite to route aggregation) and geographic location. There was, however, a near-perfect correlation between numeric contiguity and the size of end-user networks. Unfortunately, for routing purposes, that’s a useless correlation!

RFC 1466 sought to correct this deficiency inherent in the original class-based IPv4 architecture by creating an inventory of “superblocks” that could be distributed to regional Internet registries. In Chapter 1, “Developing the Internet’s Technologies,” you learned that registries are entities responsible for parsing address blocks within global regions. Examples that might jog your memory include APNIC, RIPE, and ARIN.

Creating very large blocks of addresses for those registries to distribute within their region automatically meant that, over time, route aggregation around the world would improve. This was deigned necessary to bring the Internet’s address space into alignment with its evolving needs. Specifically, commercialization meant globalization. Globalization meant scales previously unheard of for a single internetwork. It also meant that distributing addresses in a manner that precluded any meaningful aggregation could no longer be afforded.

Introduction to a Classless Environment

The other aspect of RFC 1466’s impact was to set the stage for introducing a classless address system. This aspect is very subtle and requires some thought to appreciate. The reallocation of Class C-sized networks into superblocks meant that all demands for address spaces within geographic regions would be satisfied via those superblocks, regardless of the size of those demands. Having examined the mathematics of the class-based IPv4 architecture in Chapter 2, you know how early routers determined how many bits of an IP address were used for the network portion of the address. They examined the 32-bit address (in binary) and looked to see where the first binary 0 appeared in the leftmost octet of that address. RFC 1466 undermined this old approach, because all the superblocks (and, consequently, all the network addresses created from them) were from the old Class C range. Thus, another mechanism would be absolutely essential in determining how many bits of an IP address from this range were used for the network address.

This is where CIDR comes in. It is, unarguably, the most significant of the IPv4 enhancements to come out of the Date of Doom mobilization, and it is complex enough to warrant its own chapter. For now, suffice it to say that RFC 1466 set the stage for deploying CIDR globally. The basis for CIDR predated RFC 1466, but the version that became standard came later, in RFCs 1517 through 1520. Thus, the chronology fits. The IETF knew how it wanted to evolve the address space, so it used RFC 1466 to create a pool of addresses to support this evolution. Doing so allowed it to finalize the details of classless addressing.

The Net 39 Experiment

An initiative closely related to RFC 1466 was a series of experiments designed to demonstrate how the huge Class A address space could be used more efficiently. Dubbed the Net 39 Experiment for its use of address space 39.0.0.0, these tests validated the concept of routing to variable-length network masks. This was important because the IPv4 address space itself wasn’t in danger of depletion. Indeed, plenty of Class A and C network blocks were left! Only Class B was coming under pressure. But using addresses from different numeric ranges meant completely rewriting IP’s address architecture and supporting protocols. You wouldn’t want to undertake such an endeavor without first testing your concepts extensively.

The Class A address space was particularly important to test because it represented fully half the total IPv4 addresses. Unfortunately, each Class A block was so huge as to be impractical for end-user organizations. Consequently, many of those blocks sat idle while the Class B space was endangered. The experiments to understand Class A subnetting were documented in RFCs 1797 and 1879. Knowing how much address space was locked away in impractically large blocks, the IETF was very motivated to find a way to use them. There were more than enough addresses there to stave off the impending addressing crisis almost indefinitely.

NOTE

RFC 1897, published in January 1996, presents an interesting juxtaposition that helps you better appreciate the stopgap nature of many of the technologies presented in this chapter. That RFC, published concurrently with many of the other RFCs mentioned in this chapter, allocated addresses for use in testing IPv6.

The output of this trial was used to figure out what would happen if an address block from one class were used in a way that was inconsistent with its original intent. For example, a Class A address (network 39.0.0.0 was used) could be assigned to an ISP. That ISP could then carve it into smaller networks for assignment to end users. Thus, a customer could be given a Class C-sized network created within 39.0.0.0. For the sake of continuing this example, let’s say an ISP customer was given 39.1.1.0/24. One of the more obvious problems encountered was that routers would tend to look at 39.1.1.0/24 and treat it as 39.0.0.0/8. That was always true if a classful interior routing protocol were used. In retrospect, that shouldn’t be so surprising.

From this research came the conclusion that the Class A address space could be carved up to shore up the rapidly depleting IPv4 address spaces. However, some constraints were necessary to ensure that routing across the Internet was not adversely affected.

One of the constraints deemed necessary for the Internet to continue functioning properly was how convoluted its topology could become. The IETF recommended against end-user organizations connecting to more than one ISP, because this meant that the network block of such organizations would have to be supported by each of their ISPs. That would directly increase the number of routes that the Internet would have to support. Perhaps the most intriguing aspect of the Net 39 Experiment RFCs was that, at this stage of the IPv4 address space’s development, the IETF was thinking in terms of both classful and classless (CIDR) addressing and routing. However, they recognized that you couldn’t ensure problem-free internetworking if you needed to support both simultaneously. Thus, all classful interior routing protocols (known more commonly as Interior Gateway Protocols [IGPs]) were deemed historic. The message was clear: The tests were successful, and that opened the door for a classless address architectureCIDR.

Emergency Call for Unused Addresses

Not wanting to overlook even the most obvious of opportunities in their quest to prop up the failing IPv4 address space, the IETF issued RFC 1917 in February 1996. Although it doesn’t stipulate any technology and, consequently, could be termed an information RFC, this document has achieved the status of an Internet Best Current Practice. It remains in effect as BCP #4.

This RFC was unarguably the simplest of the stopgap measures: It called for people to voluntarily surrender any unused or underutilized address spaces. In theory, this would result in a temporary increase in their inventory of available and assignable address spaces and would let that inventory be parsed out in aggregatable blocks to Internet service providers (ISPs). Two primary target audiences were identified in this RFC:

• Holders of IP address blocks that were too large for their requirements

• Holders of IP address blocks that required IP addresses to support IP-based applications but who were isolated from the Internet

For different reasons, each of these communities represented an opportunity to reclaim addresses that were currently being wasted.

Oversized Block Assignments

The more pragmatic side of this request was an acknowledgment that many existing holders of IP address blocks were given blocks larger than they needed due to the inefficiency of the class-based architecture. In a classless environment, network prefixes can be established on any bit boundary. Thus, it is possible to more precisely tailor a network block to an Internet user community’s actual needs. For example, if an organization needed 450 IP addresses, in a classful environment they would have been given a Class B address block. However, in a classless environment, they could be given a network with 512 addresses instead of 65,535. You could logically expect that a large number of the holders of Class B space would be able to return at least half of the space they were originally allocated. The point is that many very usable and routable blocks could be harvested from organizations that grabbed a Class B network space but needed only hundreds of addresses. These blocks could be freed up for reallocation to other organizations if and only if a mechanism were developed that enabled the definition of network blocks on bit boundaries instead of octet boundaries.

Isolation from the Internet

Many companies required IP and, consequently, IP addresses to support a base of networked applications without really requiring access to the Internet. Others chose to embrace IP for their internal communication requirements but could not connect to the Internet for fear of compromising the security of their networked computing assets. In theory, obtaining legitimate IP addresses was the “right” thing to do. I can remember very specific instances in which two network engineers would be on opposite sides of this issue. One would argue that, because the network in question would never be connected to the Internet, there was no reason to obtain “legal” IP addresses. The other would invariably argue from the purists’ perspective. You can’t predict the future, and your requirements might change, so do it right the first time! With that supporting logic, they would advocate obtaining real IP addresses.

There was no good way to settle this argument. Neither position was clearly right or wrong. It was more a matter of what you believed. Even the existence of RFC 1597, with its private address spaces, didn’t really settle the argument. Those addresses were reserved for private networks but didn’t mandate their use. With RFC 1917, the correct answer was that in the best interests of the Internet community, you shouldn’t waste “real” IP addresses for an isolated network. Instead, the IETF urged you to save those addresses for use in routing across the Internet. Private IP networks, regardless of size, should use the addresses stipulated in RFC 1918 (which were previously reserved in RFC 1597, but as class-based address blocks).

The great debate had finally been settled: Don’t use real IP addresses unless you need to route over the Internet. This gave the caretakers of the Internet’s address space (IANA and its myriad delegate organizations) a clear directive as well as a means of enforcement.

Although that was all very well and good, and it would certainly help slow down the rate of address consumption, something still needed to be done about all the past decisions that had already been made. Quite simply, the purists of the world were sitting on a substantial number of address blocks that were being used on isolated networks! This represented a tremendous potential pool of addresses that could greatly mitigate the address crisis being experienced. The IETF and IANA would embark on an aggressive campaign to identify and reclaim unused and underused address spaces. This effort was largely successful, but, as you’ll see in Chapter 13, “Planning and Managing an Address Space,” it did induce some very unexpected behaviors in terms of evolving address-space management tactics!

Preserving Address Block Integrity

One of the more subtle problems plaguing the Internet during the early to mid-1990s was a side effect of address space depletion. This side effect was the rate at which the Internet’s routing tables were growing. As you saw earlier in this chapter, the size of a network’s routing tables are crucial to that network’s end-to-end performance. Routing tables can expand for numerous reasons. In addition to the exponential rate of growth it was experiencing, the Internet’s tables were expanding for three primary reasons:

• Class-based addresses still being assigned to new customers had legacy effects. RFC 1466, as you just saw, was a huge step toward minimizing such legacy effects. By converting so many class-based network addresses into classless address space, the IETF sought to make as clean a break as possible from the old, obviously inefficient, class-based IPv4 addressing.

• Customers leaving their ISPs did not return their address blocks. This forced the new ISP to support routing for those specific blocks of addresses.

• End users of the Internet were applying for their own address blocks instead of using blocks assigned to them by an ISP.

The last two items are interrelated. Rather than trying to explore them separately, it makes more sense to my twisted way of thinking to examine them from the perspective of their practical impacts on the Internet. Essentially, how well or how poorly you manage an address space is evident in how well the routes for that space aggregate or fragment. Aggregation is rolling smaller network addresses into larger network addresses without affecting routes to those networks. For example, instead of listing 10.10.1.0/24, 10.10.2.0/24, 10.10.3.0/24, and so on up to 10.10.255.0/24, you could aggregate all those network blocks into just 10.10.0.0/16. This larger block tells the rest of the world how to access all the smaller network blocks that may be defined from that /16 block.

Fragmentation is the opposite of aggregation: Network addresses are so numerically dissimilar and discontiguous as to defy aggregation. If aggregation isn’t possible, the routers in the internetwork must remember a discrete route to each network. This is inefficient and can hurt the internetwork’s performance.

Aggregation and fragmentation are best thought of as extremes, with infinite room for compromise in between. The politics of Internet governance have basically pitted Internet end-user organizations against ISPs in an ongoing struggle between these two idealistic extremes.

These impacts include route aggregation (and how it was damaged by rapid growth using Classical IP addressing rules) and the effects of directly registered customer address blocks. Examining these two impacts from a practical perspective will help you better appreciate how the Internet’s address-space policies and rules have evolved over time and why things are the way they are.

Aggregation Versus Fragmentation

The addition of lots of new networks to the Internet would not necessarily contribute to the bloat of the Internet’s routing tables. In theory, new networks (and their addresses) could be added to the Internet without increasing its routing tables if those network addresses were correlated regionally and/or by service provider. In other words, a clever approach to managing address assignment could accommodate tremendous growth with little to no impact on the Internet’s routing tables simply by keeping numerically similar network addresses clumped together in a region. You could route from around the world to that region using only the highest-order bits of those related network addresses.

Although this might sound like a Utopian ideal, it is actually quite practical and realistic. To better demonstrate how such a scheme would work, consider the following example. An ISP is granted a relatively large block (let’s say a Class B-sized block). It then carves this block into smaller blocks that it can assign to its customers. As far as the rest of the Internet is concerned, a single routing table entry would be required to that Class B-sized (/16) network address. This concept is known as route aggregation.

To see how this works, refer to Figures 5-1 and 5-2. Figure 5-1 demonstrates four ISP customers buying access to the Internet but using their own IP address space. For the sake of this example, I have used the addresses reserved in RFC 1918 instead of real addresses. The last time I used a real host address in a book, I caught an earful from the administrator of that box! Getting back to the point, even though these addresses are fictitious, they are too far apart numerically to be reliably aggregated. Thus, the ISP would have to advertise each one individually to the rest of the Internet.

Figure 5-1. ISP Supporting Directly-Registered Customer Address Blocks

Figure 5-2. Route Aggregation of an ISP Using ISP-Provided Address Blocks

In real life, a service provider would probably have hundreds of customers, but that would make for a very cluttered illustration! Figure 5-2 shows how those customers could each use a smaller block carved from the ISP’s 16-bit network address.

Route aggregation, in the simplistic interpretation shown in Figure 5-2, directly contributes to a reduction in the size of the Internet’s routing tables. If each of the ISP’s customers had its own unique network addresses, each would have to be announced to the Internet. More to the point, each network address would require its own entry in every routing table of every router in the Internet. Instead, four routing table entries can be satisfied with a single entry in the Internet, because the route through the Internet is the same for each of the four customer networks. The routes start to differ only within the network of their mutual service provider. This is the only part of the Internet that needs to track routes to the four distinct customer network addresses. Thus, the entire world uses just the first two octets of the service provider’s network address to reach all its customer networks. Within that service provider’s network, the third octet becomes significant for routing packets to their destination.

When viewed from this perspective, it seems perfectly logical that the right way to provide Internet addressing is via a service provider’s larger address blocks. But some problems are inherent with this approach. Implementing an IP address scheme represents a potentially huge investment in planning and effort. From an Internet user’s perspective, changing IP addresses is undesirable, because it forces you to make the same investment in time and effort without having anything to show for it.

Thus, although using service provider addresses does minimize routing table bloat, and makes sense for the Internet, you have to realize that benefits of this approach are asymmetrically distributed. That’s a euphemistic way of saying that it is better for the Internet and ISPs than it is for the owners/operators of networks that connect to the Internet. For those entities, this approach can actually be harmful!

The danger of obtaining and using IP addresses from a service provider is that the service provider “owns” them. In effect, you are leasing the addresses for the duration of your service contract with that provider. If you wanted to change service providers (maybe you found a better deal, or maybe your provider doesn’t meet your performance requirements), you would have to relinquish the “leased” addresses and obtain a new range from your new provider. Changing service providers therefore would necessitate renumbering all your IP endpoints! Renumbering becomes a very effective barrier to changing service providers.

Directly-Registered Address Spaces

It’s not difficult to see why ISP customers are motivated to avoid changing their IP addresses. Renumbering endpoints is that onerous and risky a proposition! The surest way to avoid having to renumber is to “own” your IP addresses. Of course, you know that nobody really “owns” IP addresses except IANA, but ownership in this sense means that an organization would have IP addresses registered directly in its name. As soon as an address block is registered directly to you, it is yours foreverprovided, of course, that you don’t outgrow it or forget to pay the annual fee.

In the early days of the Internet, it was relatively easy to obtain directly registered address spaces. Such spaces were said to be portable, because they were independent of service provider address blocks. Thus, the holder of a directly registered address block enjoyed the unparalleled freedom to change service providers at will without having to worry about changing address blocks at the same time.

The drawback of this approach is, of course, the impact on the Internet’s routing tables. Portability, more than any other factor, fragments large, contiguous (and therefore aggregatable) address blocks. Unfortunately for those end users, the Internet’s routing tables were outpacing technology in their growth. They were becoming bigger at a faster pace than CPUs were increasing in speed. Consequently, Internet performance was deteriorating quickly, and the trend didn’t look good. This was one of the facets of the impending Date of Doom that the IETF sought to obviate. One of the easy scapegoats was the portability of network addresses.

Preventing Further Fragmentation

End-user organizations highly prize portable address spaces. But they are the bane of the Internet. The IETF sought to protect the Internet by more specifically constraining address assignment practices to prevent any further address space fragmentation. This effort was documented in RFC 2050. RFC 2050 is still in effect and is also Internet Best Current Practice #12. Specifically, this document stipulated the rules and regulations regarding subassignments of IP address spaces by ISPs.

The way it works is simple. An ISP’s customerif it didn’t already have directly registered address blocks of its owncould obtain addresses from its service provider. However, to preserve the integrity of large service provider address blocks, those addresses had to be surrendered when the contract for service ended. In other words, these addresses were nonportable and remained with the service provider with which they were registered. That way, the ISP could advertise just a single, large network address to the Internet that encompassed all its customer networks created from that large block.

But if a customer wanted to move to a different service provider to obtain a lower monthly recurring cost, it found itself in the uncomfortable position of having to quickly renumber its entire network and all its addressed endpoints. Adding insult to injury, the range it had to migrate to was another nonportable address range supplied by the new service provider. Each time the customer wanted to change providers, it had to go through the same expensive, risky, painful process of renumbering endpoints.

RFC 2050/BCP 12 doesn’t do anything to mitigate this pain for end users. Rather, it compels service providers to treat all their assignable address space as nonportable, regardless of whether any given subset of it may be globally routable. If an ISP chooses to disregard RFC 2050 and let ex-customers keep their assigned space, it will eventually exhaust its address space. That ISP will find it impossible to convince its regional Registry to entrust it with more address space. An ISP without an inventory of available network addresses cannot service any new customers. RFC 2050 seeks to prevent further fragmentation of the Internet’s address space (which directly increases the size of the Internet’s routing tables) by giving ISPs the incentive to preserve the integrity of their existing blocks.

Rationing Directly Registered Addresses

RFC 2050, in the absence of any other policy changes, was a tweak to the nose of the Internet’s end-user community. It wasn’t intended to be painful. Rather, it was designed as an emergency effort to ensure the Internet’s continued operability. Such austerity measures are often palatable provided that the pain is shared somewhat equitably. Because the end-user community bore the brunt of the inconvenience caused by that RFC, they had every reason to be upset. The only mitigating factor was that those organizations could shield themselves from any pain just by having their own directly registered address spacesthat is, they could until IANA started rationing new directly registered address blocks.

This is where things started getting ugly. IANA exacerbated the routability versus portability conflict when it tightened its policy on directly registered address spaces. Organizations that wanted their “own” address spaces would have to meet very stringent requirements before that privilege would be granted. The cumbersome and bureaucratic application process alone was enough to deter most would-be applicants. Those persistent enough to successfully complete an application with their Registry quickly discovered that did not guarantee their request would be granted.

Although this policy shift was a necessity caused by the impending address-space crisis, it meant that it was now almost impossible for an end-user organization to obtain its own directly registered address space. When you view this fact in conjunction with the bias against end-user organizations in RFC 2050, it becomes clear that end-user organizations bore the full brunt of the policy changes necessary to prevent the Internet’s address space from collapsing.

Ostensibly, this policy shift was designed to immediately curtail the outflow of the finite supply of the remaining IPv4 addresses. This, all by itself, would buy a lot of time and forestall the crisis. However, it also forced Internet users to seriously consider alternative options for their IP addressing, such as the following:

• Using ISP-provided addresses

• Using nonunique addresses

• Using a translation function between your network and the Internet

We’ve already looked at why using ISP-provided addressing isn’t very attractive to end-user organizations. We’ll look at the other two options much more closely in the next chapter. For now, just realize that none of these were very palatable, nor as convenient as directly registered address space. The fact that these unattractive options were forced on end-user organizations created the potential for a tremendous backlash that is still being experienced today.

End-User Backlash

In some cases, the backlash has been extremely aggressive and creative. The goal is simple, and it can be summed up in just one word: portability. The extent to which end-user organizations pursue this grail is remarkable. It is characterized by aggressiveif not desperateattempts. The stakes are that high!

Part of the problem, or maybe I should say part of the game, is that there is tremendous confusion about what constitutes portability. Internet Registries, for example, interpret portability to mean global routability.

Determining global routability from a Registry’s perspective is simple: Is the address block large enough to be worth routing on the Internet? That criterion has absolutely nothing to do with block ownership. As you have seen, service providers are bound by a different criterion: compliance with RFC 2050/BCP 12. Consequently, they have a different interpretation of portability. Service providers have an obligation to interpret portability to mean both global routability and directly registered to the end-user organization. They might provide a range of addresses to a customer that is large enough for routing over the Internet, but they cannot consider it portable, because it is theirs.

End-user organizations try desperately to exploit this chained ambiguity of definitions by insisting their service-provider blocks meet the criteria of global routability. Therefore, their argument continues, those addresses should be handed over when they change providers! Sometimes this argument works, and sometimes it doesn’t. If it doesn’t, the game doesn’t end there for some end-user organizations. I’ve seen quite a few ex-customers simply refuse to return their address blocks! Although I won’t pretend to understand the rule of law well enough to pass judgment on the legality of such hijacking of address space, I can tell you it certainly violates Internet BCP 12 and does nothing to help the Internet’s performance.

Sadly, these unintended consequences caused by RFC 2050 and the emergency rationing of directly registered address spaces continue to haunt the Internet. We’ve spent quite a bit of time looking at them for the simple reason that they form an unavoidable constraint in today’s IP network environment. The more you know about these and the other constraints, the better you’ll be able to deal with them on the job.

Hijacked Address Spaces

Since its inception, RFC 2050 has done wonders for minimizing the expansion of Internet routing tables. However, it has created potentially serious tension between ISPs and their customersor should I say their ex-customers? One of the less-heralded side effects of RFC 2050, in combination with IANA’s crackdown on granting privately registered address spaces, has been the hijacking of ISP address blocks.

When a customer leaves an ISP, it is required to return its IP address space to that ISP. That ISP can, in theory, put those addresses back in its inventory of unused addresses with which it satisfies new customer requests for addresses. However, it is not uncommon for a customer to terminate service with one ISP, start service with a new ISP, and then insist that new ISP support its existing blocks. By refusing to stop using an address space, an end-user organization can effectively convert a nonportable address space to a de facto portable space! Even though this is a violation of an Internet Best Current Practice, some ISPs are reluctant to do anything to upset a paying customer. Money talks!

An ISP whose addresses have been hijacked in this manner faces few good options. ARIN and IANA don’t offer any active help, but they still insist that you reclaim your blocks. I’ve found that contacting the ex-customer’s new service provider and demanding that it immediately cease supporting the hijack of addresses meets with only mixed success. Some ISPs are much more reputable than others and will jump at the opportunity to help you reclaim your lost property. Others require a bit of coercion. Letting them know that you will be advertising the hijacked addresses as null routes and that they should expect a trouble call from an unhappy and out-of-service customer usually does the trick.

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.

The Problems

The problems dated back to the beginning but remained latent. During the Internet’s early days, it grew very slowly. That slow rate of growth was caused by two primary factors:

• These were the halcyon days before client/server computing architectures.

• The Internet was still not a commercial vehicle; the only entities connected to it were academic, research, and military organizations. They all used it to facilitate their mutual research.

These two factors led to the mistaken belief that the 32-bit address space, the class-based address architecture, and all the Internet’s physical and logical support infrastructure would service the Internet far into the future. Not much time passed before that was proven untrue. The symptoms of commercialization, and their projected impacts, appeared likely to cause numerous problems. The most immediate problem areas foreseen by the IETF included the following:

• Impending exhaustion of the Class B address space Subsequent exhaustion of the other areas of the IPv4 address space.

• Routing performance problems caused by an explosion in the size of the Internet’s routing tables Human impacts of having to support an increasingly larger set of routes in an ever-growing internetwork.

Let’s take a look at these two points, because they are highly correlated.

Address Space Exhaustion

The class-based IPv4 address architecture was flawed from the start. Only the very slow initial growth of the Internet masked its deficiencies. The slow growth vis-à-vis the sheer size of the address space (remember, an 8-bit address space with just 256 addresses was upgraded to a 32-bit address space with more than 4 billion addresses) created a false sense of security. This resulted in wasteful address assignment practices. Not the least of these included the following:

• Hoarding of address blocks Early adopters of the Internet tended to register far more blocks of addresses than they needed. Many large, early Internet users grabbed Class A address spaces just because they could. In retrospect, it seems the only criterion in handing out IP address blocks was the size of the organization, not the size of its needs. This was justified as “planning” for unknown and unspecified future requirements.

• Inefficient assignments Because IP addresses were so plentiful, many organizations assigned their numbers in a wasteful manner. This too could be attributed to planning.

• Inefficient architecture As you saw in Chapter 2, “Classical IP: The Way It Was,” the class-based architecture contained inordinately large gaps between the classes. These gaps wasted a considerable number of addresses. Under strict classical rules, a medium-sized company that requires 300 IP addresses would have been justified in requesting a Class B address. In effect, more than 65,000 addresses would be wasted due to the architectural inefficiency.

The inadequacy of the original address space and architecture was being felt most acutely in the Class B range. It was believed, based on an examination of address-space assignments, that this range would be exhausted first, and that continued explosive growth would rapidly exhaust the remaining address classes in a chain reaction.

Routing Table Explosion

A slightly more subtle implication of the rapid consumption of IP address blocks was the commensurate increase in the size of the Internet’s routing table. A routing table, in simple terms, is a router’s list of all known destinations, correlated with which interface should be used to forward datagrams to those destinations. Logically, then, the greater the number of network addresses, the larger a routing table becomes. When a router receives a packet to be forwarded to a destination, it must first examine that packet’s destination IP address and then do a table lookup to find out which port it should use to forward that packet. The larger the table, the greater the amount of time and effort required to find any given piece of data. This means that the time it takes to figure out where to send each datagram increases with the size of the routing table. Even worse, the demands on physical resources also increase.

That’s a bit of an oversimplification, but it serves to illustrate my point: The Internet was growing rapidly, and this was directly increasing the size of the routing tables needed by the Internet’s routers. This, in turn, caused everything to slow down. It was also straining the physical capabilities of the Internet’s routers, sometimes right to the outer edges of the router’s capabilities. In other words, simply plugging in more memory or upgrading to the next-larger router or CPU wouldn’t help.

The bloating of the Internet’s routing tables had the potential to become a vicious, self-sustaining cycle: The larger the tables became, the more time was required to process any given packet. The more time was required to process a packet, the more memory and CPU time were consumed. As you consumed more CPU cycles to process a packet, the more packets became backlogged. This was a problem that could, if left unchecked, cause the Internet to collapseespecially since the Internet continued to grow at a phenomenal rate.

Clearly, something had to be done.

The Long-Term Solution

Being able to identify a problem’s root cause is always the necessary first step in solving the problem. Thus, you could argue that the IETF was perfectly positioned to rectify the problems inherent in the IPv4 address space: It understood precisely the sources of its impending problems. But the IETF faced a catch-22. This was the type of problem that couldn’t be solved quickly, yet time was not a luxury the IETF could afford! They had to act, and act quickly, to ensure the Internet’s continued operability.

The IETF realized that the right answerlong-termwas to completely reinvent the Internet Protocol’s address space and mechanisms. But that would require a tremendous amount of time and effort. Something had to be done in the short term. They had to find ways to buy the time needed to come up with a new IP addressing system. This new protocol, and preferred long-term solution, became known as IPv6. We’ll examine IPv6 in Chapter 15, “IPv6: The Future of IP Addressing.”

For now, let’s focus on the emergency measures deployed to shore up the ailing IPv4. The vast majority of these measures were simple quick fixes. Although none of these, individually, would solve the larger problem, each would help forestall the impending Date of Doom in some small way. We’ll call these quick fixes interim solutions and look at them in the next section.

The unassigned space illustrated in Table 4-6 can be used in a number of different ways. Here are two of the more feasible scenarios for using this space:

• Any existing subnet can suddenly expand beyond the surplus afforded by its current mask.

• A new group of users might have to be supported, which necessitates the creation of a new subnet.

Both of these scenarios and their implications on subnetting schemes are explored in the remainder of this section.

Adding a Subnet

In the example used throughout this chapter, Subnets 1 through 3 have been used, with Subnet 0 idle. It is equal in size to a subnet defined with a mask of 255.255.255.224, but the 32 addresses it would contain are not used. I did this on purpose to show you that in many cases, old subnetting rules can be very persistent. Consequently, it is not uncommon to find Subnet 0 unused in networks today. Under today’s rules for subnetting, this space doesn’t have to lie fallow. To continue with the sample network, if a requirement emerges for a new subnet with 30 or fewer devices, Subnet 0 could be pressed into service.

Additional unallocated addresses remain in the high end of the network address block. Addresses 64 through 255 are unused, so it is possible for additional subnets to be created in the future. Thus, you have some options for satisfying new requests for subnets. Depending on the number of hosts in a new subnet, you could assign Subnet 0 or carve Subnet 4 out of the currently unassigned address space (addresses 64 through 255). A more nettlesome question is how you accommodate growth within the existing subnets.

Outgrowing a Subnet

As you were looking at Tables 4-4 and 4-5, did you notice that even VLSM isn’t perfectly efficient? There are still wasted addresses. That’s a direct function of the binary math that is the foundation of the address space itself, rather than a flaw in any particular approach to carving the space into subnets. You can create a subnet on any bit boundary, but each bit increments by a factor of 2. Remember: The rightmost bit in an octet has a decimal value of 1, the bit to the immediate left carries a value of 2, then 4, then 8, then 16, then 32, then 64, and ultimately 128 for the leftmost bit in the octet. Consequently, you must form your subnets in this sequence from powers of 2.

You could look at this architectural feature as a negative in that it results in wasted space. Alternatively, you could take a more pragmatic perspective and appreciate the positive implications of this feature. For example, even if it were possible to create subnets of the precise size you require for any given subnet, would you really want to tailor it so concisely? Many things can happen that would require you to add endpoints to a subnet. For example, the user community on any of your subnets might hire someone new. The same thing would hold true for technological innovation. It wasn’t that many years ago that printers didn’t have a built-in network interface card (NIC), and you had to use a server to spool print requests to them. A more commonly encountered scenario is that the group you are supporting can simply outgrow its subnet.

The point is that there are many reasons why the number of host addresses in any given subnet could change over time. Trying to add a few addresses to a tightly constructed subnetted scheme can be painful. Depending on the extent of the growth, you might find it necessary to completely renumber one or more subnets! That might not sound so bad, but it is not fun, and your users might not appreciate having to experience it either. Plus, you might discover a relatively common practice: application developers who hard-code IP addresses into their software. Renumbering a network will cause every such application to fail!

To illustrate this point, let’s assume that Subnet 2 of the sample network needs to grow by five endpoints. Unfortunately, that subnet has only two available IP addresses within its assigned range (192.168.125.40 through 192.168.125.47), and Subnet 3 picks up right where Subnet 2 ends, so there is no opportunity to just change the mask’s size to encompass sequential but unassigned addresses. Because Subnets 2 and 3 are numerically contiguous, your only choices both involve renumbering the endpoints within Subnet 2. You have to move them to a section of the address space that offers more addresses. Your two options are as follows:

• Move the endpoints from Subnet 2 to Subnet 0.

• Move the endpoints from Subnet 2 to the newly created Subnet 4 using previously unassigned addresses from the high end of the address block.

Table 4-7 shows you what the subnetting scheme would look like if you were to renumber the endpoints in Subnet 2 to use the range of addresses in Subnet 0. Doing so results in the allocation of 30 usable host addresses to a group of users that requires only 17, but you don’t have any better options! The coarseness of the architecture works against you. A mask of 255.255.255.240 would yield only 14 usable hosts, which is inadequate. However, a mask of 255.255.255.224 (1 less bit in the subnet prefix) yields 30 usable hosts and is the only feasible solution. This should seem familiar to you, but if it doesn’t, just refer back to Table 4-4.

Your second option for satisfying the outgrowth of Subnet 2 is to create a new subnet from the unassigned addresses. Table 4-8 demonstrates how this would be done. Pay particular attention to the binary and decimal translations for Subnet 4 to see how that would be accomplished.

If you look carefully at the progression of numbersparticularly the binary numbersyou will see a very familiar pattern. Both Subnets 3 and 4 use a 3-bit subnet mask. This makes it easy to see why one subnet ends with 00111111 and another begins with 01000000. In the other cases, mismatched subnet prefixes make it a bit tougher to follow the logic. In those cases, ignore my visual cues about subnet formation and just look at the 8-bit string as a whole. Then, things make more sense.

Keep Careful Records!

Looking back over the previous three tables, you must draw one simple, inescapable conclusion: It is critical to maintain an accurate and up-to-date record of address assignments! Subnetting, in its original incarnation, was deemed practical only if you used a fixed-length mask to subdivide an entire network address. Although this wasn’t the most efficient way to subdivide a network, it was still far more efficient than the previous method of operation, which was to secure separate network addresses for each of your subnets.

The grassroots innovation of flexible subnetting happened outside the auspices of the IETF. Thus, there was no solid base of research to draw on, no well-worn trail to follow, and no set of tools to rely on. If you chose to ignore the recommendation of using a single-sized subnet mask for your subnetting, you were on your own! This was a simplifying assumption embedded in the original subnetting RFCs. It gave ordinary network administrators a chance to improve the efficiency with which they consumed IP address space without creating a mathematics exercise that could have qualified as a Herculean task.

Despite the risks of stepping outside the safe confines of an RFC, flexible subnetting became the dominant paradigm. Technical personnel realized that the price they had to pay for this was the creation and maintenance of an accurate database of address assignments. This has never been more true.