Balkanizing an Address Space


Address space management took on greater urgency with the release of RFC 1917 in February 1996. This RFC was authored as part of the IETF's multifaceted effort to stave off an impending collapse of the Internet's address space and architecture. It didn't define any new technology. It was simply an urgent appeal to the Internet community to return unused address space to IANA for use in satisfying the growing demand for address space.

With the publication of this document, IP address space was viewed as a precious and finite commodity for the first time. Some organizations that had previously "stocked up" on network address space viewed this as justification for their foresight and reinforced the need to maintain their unused address blocks for future use. Their rationale was that if an organization surrendered its unused address blocks to help the Internet meet its surging demand for addresses, it might not be able to get more addresses in the future it they needed them.

One of the less-noble responses to RFC 1917 was the emergence of a new address management strategy: balkanization. Anyone familiar with European geopolitics will recognize the root of this word. The Balkans is a crossroads region of Europe that has long been both a cultural melting pot and a source of conflict. Its location midway between Europe and the Middle East has resulted in its settlement by a remarkable variety of ethnic tribes and religious convictions. The result is a land so divided that it resists integration into a cohesive system of government. In that spirit, balkanization of an IP address space refers to carving it into lots of little pieces so that it can't be taken away. Fragmentation, in theory, could be so complete that nothing remains but unroutable odd-sized blocks between assigned ranges of addresses.

Strengths and Weaknesses

Balkanization is an inherently inefficient practice. In fact, it was specifically intended to be inefficient. This tactic is territorialism at its worst. Its primary benefit is to break a larger address block into many smaller fragments that would be of limited value outside your organization. Attempts to reclaim and reuse otherwise unassigned address space fragments would only result in an increase in the size of Internet routing tables. That's not something that the IANA and ICANN organizations view as good for the Internet in the long term. Thus, balkanization solidifies your claim to a network address space that would otherwise be far too large for your needs.

A subtle benefit of using this address allocation approach is that each block assigned has ample room to grow at both ends of its range of valid addresses. Finally, this approach is rather simple to deploy. Little, if any, forethought and planning are required. In other words, the role of the hostmaster is greatly simplified by virtue of having so much address space to begin with.

The drawbacks of balkanization are few, but noteworthy. Whereas other tactics strive to conserve address space so that the IPv4 address space itself can service an ever-growing population, this approach is strictly selfish. A large amount of otherwise reusable address space is intentionally locked up within one organization.

Another subtle implication is that not every address space is a good candidate for balkanization. This practice is best suited to address blocks that are substantially larger than the networks they are servicing. For example, a /24 with a mere 254 usable host addresses is unlikely to attract the attention of IANA and/or ICANN for reclamation. Thus, it is a poor candidate for balkanization.

I'm not advocating the practice of balkanizing an address space. It is at best a defensive move designed to protect an address space from being reclaimed. Implicit in this is that the space was underutilized to the extent that it should be reclaimed. I mention this approach solely to reinforce the necessity of carefully managing your address space. A random or sloppy approach to managing an address space can have the same net effect as balkanization. Neither is acceptable.

I realize that I have rambled on ad nauseum about a somewhat esoteric topic. The next section helps you better appreciate what it means to balkanize an address space.

Realistic Context

Smaller address spaces simply aren't good candidates for balkanization. For one thing, there aren't enough addresses to fragment into smaller blocks. More important, larger blocks afford a greater benefit to the Internet if they can be reclaimed. Consequently, I'll depart from my usual custom of using smaller, more manageable address blocks as examples. The only way to adequately demonstrate balkanization is with a larger block. This example uses a /19 network address block. As you saw in Table 4-1 from Chapter 4, "Variable-Length Subnet Masks," a /19 offers 8192 total host addresses. This is the equivalent of 32 Class C-sized network address spaces.

For the sake of the example, assume that our organization is relatively small. It consists of 600 endpoints scattered across five different geographic locations, with an approximately equal number at each location. A /24 with its 254 usable addresses would more than suffice for each of the five locations. So a /19 is probably way more than we need. In fact, a /22 with its 1024 addresses would probably be just about right. Thus, if we weren't careful, we could find at least half of our /19 in danger of being reclaimed. If that block were reclaimed, we would be left with a /20 (half of a /19), which is still way too big for our needs. But there is a way of scattering our address assignments to make our network appear to require more space than it really does. We can balkanize our network address space.

Because the network belongs to a private enterprise, route aggregation internally is not of concern. There is only a single connection to the Internet, and all addresses assigned (regardless of size) are announced via a single route: the /19. Figure 14-2 shows the basic topology of this sample network. It gives you the context for understanding our hostmaster's records of address assignments within our network. Those assignments are listed in Table 14-8.

Figure 14-2. Network Topology of the Balkanized Address Space


In Figure 14-2, you can see that the hosts at each of the five locations are each treated to a /24 network address block. An additional /24 is allocated to LAN management ports at each of these locations. That brings us up to ten /24 networks allocated out of the 32 that are available in the 192.168.64.0/19 address space. Another one has been allocated for use in identifying network backbone interfaces, which means that 11 are used and 21 are surplus. Table 14-8 shows you how this size block can be fragmented so thoroughly that the remaining free spaces aren't worth using outside the organization.

Table 14-8. Balkanizing a 19-Bit Network
 

Binary Network Plus Subnet Address

Decimal Translation

Base

11000000.10101000.01000000.00000000

192.168.64.0/19

Backbone interfaces

11000000.10101000.01000000.00000000

192.168.64.0 /24

Backbone interfaces

Backbone interfaces

11000000.10101000.01000000.11111111

192.168.64.255

Unassigned

11000000.10101000.01000001.00000000

192.168.65.0 /24

Unassigned

Unassigned

11000000.10101000.01000001.11111111

192.168.65.255

Unassigned

11000000.10101000.01000010.00000000

192.168.66.0 /24

Unassigned

Unassigned

11000000.10101000.01000010.11111111

192.168.66.255

Location 1 LAN management ports

11000000.10101000.01000011.00000000

192.168.67.0 /24

Location 1 LAN management ports

Location 1 LAN management ports

11000000.10101000.01000011.11111111

192.168.67.255

Unassigned

11000000.10101000.01000100.00000000

192.168.68.0 /23

Unassigned

Unassigned

11000000.10101000.01000101.11111111

192.168.69.255

Location 1 hosts

11000000.10101000.01000110.00000000

192.168.70.0 /24

Location 1 hosts

Location 1 hosts

11000000.10101000.01000110.11111111

192.168.70.255

Unassigned

11000000.10101000.01000111.00000000

192.168.71.0 /24

Unassigned

Unassigned

11000000.10101000.01000111.11111111

192.168.71.255

Unassigned

11000000.10101000.01001000.00000000

192.168.72.0 /24

Unassigned

Unassigned

11000000.10101000.01001000.11111111

192.168.72.255

Location 2 LAN management ports

11000000.10101000.01001001.00000000

192.168.73.0 /24

Location 2 LAN management ports

Location 2 LAN management ports

11000000.10101000.01001001.11111111

192.168.73.255

Unassigned

11000000.10101000.01001010.00000000

192.168.74.0 /23

Unassigned

Unassigned

11000000.10101000.01001011.11111111

192.168.75.255

Location 2 hosts

11000000.10101000.01001100.00000000

192.168.76.0 /24

Location 2 hosts

Location 2 hosts

11000000.10101000.01001100.11111111

192.168.76.255

Unassigned

11000000.10101000.01001101.00000000

192.168.77.0 /24

Unassigned

Unassigned

11000000.10101000.01001101.11111111

192.168.77.255

Unassigned

11000000.10101000.01001110.00000000

192.168.78.0 /24

Unassigned

Unassigned

11000000.10101000.01001110.11111111

192.168.78.255

Location 3 LAN management ports

11000000.10101000.01001111.00000000

192.168.79.0 /24

Location 3 LAN management ports

Location 3 LAN management ports

11000000.10101000.01001111.11111111

192.168.79.255

Unassigned

11000000.10101000.01010000.00000000

192.168.80.0 /23

Unassigned

Unassigned

11000000.10101000.01010001.11111111

192.168.81.255

Location 3 hosts

11000000.10101000.01010010.00000000

192.168.82.0 /24

Location 3 hosts

Location 3 hosts

11000000.10101000.01010010.11111111

192.168.82.255

Unassigned

11000000.10101000.01010011.00000000

192.168.83.0 /24

Unassigned

Unassigned

11000000.10101000.01010011.11111111

192.168.83.255

Unassigned

11000000.10101000.01010100.00000000

192.168.84.0 /24

Unassigned

Unassigned

11000000.10101000.01010100.11111111

192.168.84.255

Location 4 LAN management ports

11000000.10101000.01010101.00000000

192.168.85.0 /24

Location 4 LAN management ports

Location 4 LAN management ports

11000000.10101000.01010101.11111111

192.168.85.255

Unassigned

11000000.10101000.01010110.00000000

192.168.86.0 /23

Unassigned

Unassigned

11000000.10101000.01010111.11111111

192.168.87.255

Location 4 hosts

11000000.10101000.01011000.00000000

192.168.88.0 /24

Location 4 hosts

Location 4 hosts

11000000.10101000.01011000.11111111

192.168.88.255

Unassigned

11000000.10101000.01011001.00000000

192.168.89.0 /24

Unassigned

Unassigned

11000000.10101000.01011001.11111111

192.168.89.255

Unassigned

11000000.10101000.01011010.00000000

192.168.90.0 /24

Unassigned

Unassigned

11000000.10101000.01011010.11111111

192.168.90.255

Location 5 LAN management ports

11000000.10101000.01011011.00000000

192.168.91.0 /24

Location 5 LAN management ports

Location 5 LAN management ports

11000000.10101000.01011011.11111111

192.168.91.255

Unassigned

11000000.10101000.01011100.00000000

192.168.92.0 /23

Unassigned

Unassigned

11000000.10101000.01011101.11111111

192.168.93.255

Location 5 hosts

11000000.10101000.01011110.00000000

192.168.94.0 /24

Location 5 hosts

Location 5 hosts

11000000.10101000.01011110.11111111

192.168.94.255

Unassigned

11000000.10101000.01011111.00000000

192.168.95.0 /24


This example bears the earmarks of an insightful, maybe even insidious, hostmaster. Did you notice that all the backbone router interfaces are assigned IP addresses from the same /24 block? Similarly, LAN management ports are assigned numbers from other ranges of numbers. Each location has been treated to a /24 just for this purpose. Although this lets each location grow to a maximum of 254 LAN switches, it seems highly unlikely that this number is needed. Instead, it seems more likely that a /29 or /30 address block would serve this purpose marvelously.

You might be wondering why such networking devices would be given their own IP blocks. The answer is simple, and it isn't to facilitate routing. This practice greatly simplifies data collection for network monitoring, management, and trend-analysis tools. Generally speaking, it is always preferable to separate the addresses of infrastructure devices from hosts that function as destination and/or origination points of a communication session.

The combination of overallocating blocks achieves the goal of balkanization. It makes the network look as if it requires 11 Class C-sized networks (/24s). The fact that those 11 /24s are scattered across the entire /19 range effectively fragments the remaining free space into discontiguous blocks. If they were numerically contiguous, a reasonable argument could be made for their return to IANA and ICANN for reallocation to another Internet user community. In their current form, any attempt to reclaim them would only result in a bloating of the Internet's address routing tables, because they defy effective aggregation.




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