Symmetry of CIDR Notation


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

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

Table 6-2. Symmetry of CIDR Notation

Decimal Address

Binary Address

192.168.64.0/24

11000000.10101000.01000000.00000000

192.168.64.0/25

11000000.10101000.01000000.00000000

192.168.64.128/25

11000000.10101000.01000000.10000000


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-3. Creating /24 Networks from a /23

Decimal Address

Binary Address

192.168.64.0/23

11000000. 10101000.01000000.00000000

192.168.64.0/24

11000000. 10101000.01000000.00000000

192.168.65.0/24

11000000. 10101000.01000001.00000000


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.

Table 6-4. Creating /27 Networks from a /24

Decimal Address

Binary Address

192.168.64.0/24

11000000. 10101000.01000000.00000000

192.168.64.0/27

11000000. 10101000.01000000.00000000

192.168.64.32/27

11000000. 10101000.01000000.00100000

192.168.64.64/27

11000000. 10101000.01000000.01000000

192.168.64.96/27

11000000. 10101000.01000000.01100000

192.168.64.128/27

11000000. 10101000.01000000.10000000

192.168.64.160/27

11000000. 10101000.01000000.10100000

192.168.64.192/27

11000000. 10101000.01000000.11000000

192.168.64.224/27

11000000. 10101000.01000000.11100000


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.




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

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