The Challenge of Managing an Address Space


Managing an address space is a deceptively difficult chore, particularly if you are using globally routable addresses. Do you remember the private addresses we looked at in Chapter 5, "The Date of Doom"? These were ranges of regular IP addresses that were arbitrarily reserved by the IETF in RFC 1918 for use in IP-based networks that didn't need Internet connectivity. IP might have been required to support an application base, but the fact that the network was not part of a larger internetwork meant that the addresses didn't have to be globally unique. If they don't have to be globally unique, they can't be routed on the Internet.

NOTE

The private address blocks reserved in RFCs 1597 and 1918 are sometimes described as being nonroutable because they can't be routed across the Internet. Those addresses, however, are perfectly routable within private networks. For that reason, describing them as nonroutable can be misleading. They are more accurately described as private addresses.


If you use the private addresses of RFC 1918, your address management chores become greatly simplified. Those addresses, by virtue of not having to be unique globally, aren't a finite resource. Thus, you can assign with almost reckless abandon. Almost. You still need to follow some sort of system to track assignments and manage your network's growth. Because these addresses are not globally unique, you can build in copious room for future growth. However, I caution you to treat whichever address block you implement as if it were a finite resource, regardless of its size. Bad habits are tough to break, so don't get accustomed to sloppy address management practices.

On the other hand, if you are using "real" IP addresses (those that are unique and globally routable), the task of managing that address space carries an extra burden. These addresses are a precious and finite resource. If you squander them, you might have a very difficult time convincing ARIN that you should be entrusted with more addresses. Consequently, it is in your best interest to manage unique IP addresses very carefully. The real art of being a hostmaster lies in balancing address space conservation through careful planning and enabling future growth.

For the purposes of this chapter, we'll walk through some of the inputs to the planning process, but our primary focus will be on the approaches to parsing an address block.

Planning: A Hostmaster's Best Friend

In the simplest of terms, a hostmaster is charged with managing and tracking the consumption of an IP address space. The decisions you make about how the address space is carved up and distributed can be remarkably persistent. Thus, it is imperative that you do it right the first time.

Two of the many factors you must consider when planning are long-term growth and technological innovation. Technological innovation is virtually impossible to plan for with any degree of accuracy. You simply never know when the next big innovation will come along. Similarly, an organization's long-term growth can be difficult to plan for simply because each group within the organization grows at different rates. Plus, none of those groups will likely share their strategic future plans with anyone outside their perimetereven the hostmaster. Either of these contingencies would be difficult to plan for, but trying to plan for both simultaneously can be a nightmare.

Both are sufficiently nebulous as to obviate making decisions with perfect information. In the absence of perfect information, you have to rely on margins for error. In other words, frame out your estimates for future requirements as best you can, and then add in a "fudge factor." The greater the degree of uncertainty in your plans, the larger your fudge factor needs to be. Right about now, you might be thinking that this is an exercise in futility. But when it comes to IP address spaces, you canand mustplan for ambiguity.

Indeed, a bit of catch-22 logic is in evidence here. If you don't leave adequate room for future expansion, you might find yourself having to repeatedly renumber your users' networks and devices. If you leave too much room for future expansion, you might create even bigger problems when you run out of usable addresses. Quite simply, the room you build in for growth might not prove useful. We'll look at how this paradox works throughout this chapter. Suffice it to say that mismanaging an address space can create unused and unusable IP addresses. The person responsible for charting a course through ambiguity and steering clear of these equally undesirable scenarios is the hostmaster. This leads us to one of the greatest ironies and injustices in the world of IP addressing: Being a hostmaster is a thankless job. If a hostmaster fulfills his duties well, nobody notices. If he doesn't, everybody notices.

The "Classless" Network Engineer Versus the "Class-y" Sys Admin

A system administrator in a data center I managed generated one of the more amusing trouble tickets I have encountered. This person, by virtue of his professional responsibilities, should have had a very firm command of IP addressingespecially as implemented inside that data center. No customers were complaining, and no downtime was being incurred. But there it was: a trouble ticket on a routing problem. Superficial analysis revealed that there was no problem, and that the network was performing as expected. No amount of explanation, it seemed, could dissuade our tenacious system administrator from his belief in the existence of a routing problem. It seemed as if the network engineer and the system administrator were speaking two completely different languages, and no effective communications were possible between them.

When pressed for details, the system administrator explained that two machines, both addressed in the x.168.42.0 network (I've substituted an x for the first octet of the address to protect the guilty), should receive the same Layer 3 broadcasts. But he could prove that, in fact, they were not receiving the same Layer 3 broadcast packets from another host on that network. From a host-level perspective, this indicated a routing problem. The problem was reported and escalated without the benefit of tracing cables or otherwise attempting to discern the network's topology. The only basis for the claim was the commonality of the IP network address.

From the network's perspective, all was in order. The two hosts were on different /28 networks that were separate VLANs connected to the same Layer 2/3 switch. The key piece of information that the system administrator failed to grasp was that both /28 network addresses were carved from the same /24. This system administrator was "class-y" but had no concept of classless IP addresses! The administrator knew that network address blocks were allocated in CIDR blocks as small as /30 inside the data center, yet hadn't grasped the significance of classless addressing.


The only way to get past this conundrum is through planning and the development of a comprehensive address management plan. The basic steps involved in the planning stage are fairly simple:

Step 1.

Identify the various user communities, the number of addresses currently needed, and the likelihood and magnitude of future expansion.

Step 2.

Evaluate those communities relative to the size of the address space you have to work with. Pay particular attention to the pain factors of underestimating versus overestimating future growth for each community.

Step 3.

Determine how many surplus addresses to build in for each community.

After you have completed the planning, the last thing you need to do is implement the plan. This requires you to select a methodology for distributing address spaces to those user communities. Addresses can be allocated manually (in which case records need to be maintained manually) or can be dynamically assigned to specific endpoints using an automated tool such as Dynamic Host Configuration Protocol (DHCP).

Identifying the User Communities

The first step in developing a coherent address management plan is to identify the base of users you need to support. Included in this is some sense of how likely the potential for growth in each group is. This includes not only people, but also the number of IP-addressable peripherals.

Today, a decent planning number for addressing purposes is to allocate two IP addresses for each user. That's not to say each user will need two addresses; some might, and most won't. However, the array of peripheral devices that can be directly connected to the network will only continue to grow. Such devices might be connected to the network to facilitate their shared use (such as printers), or they might only need a connection for their management port (such as LAN switches and PBXs) so that monitoring and/or management software can track them. Each logical group should be considered a community and treated to a separate block assignment.

One of your first steps must be figuring out how large each user community (that is, subnet) is, its propensity to use networked peripherals, and the likelihood of future growth. All these considerations will have an impact on the number of addresses you assign.

Comparing the Pain Factors

The next step in figuring out how to manage your address space is to establish your pain thresholds. Basically, you have to balance the risks of creating address block assignments too close to the required size (that is, leaving little, if any, room for future growth) versus the risks of creating too much room for growth. The best way to assess these risks is to understand how much pain and effort you could incur if you overestimate versus underestimate future expected requirements. This is where there is more art than science in address management.

The negative impact of underestimating growth for any given community is fairly obvious. If the address space they were assigned can't be expanded, you will have to migrate them to a different, larger address space. Each endpoint will have to be reconfigured. If any of them are hosts or destinations that are accessible via host names or domain names, you will have to coordinate DNS changes concurrent with the endpoint reconfiguration. Negotiating with the affected users for scheduled downtime within which you can complete these tasks will be extraordinarily painful. Even worse will be when you have to break the news of the IP renumbering to application developers. It has become a common practice to embed IP addresses directly into custom-developed application software, so renumbering might well translate into rewriting and recompiling software.

Another option might be to simply accommodate growth by using a second range of IP addresses. If the two blocks of IP addresses are not numerically contiguous, you could find yourself having to route between two devices that are essentially on the same network. This approach is far from ideal, but it is much less painful than renumbering.

The impact of overestimating growth is a bit more subtle and tougher to appreciate. On the surface, you could argue that all the negative impacts of a poor address management decision are a direct result of underestimating future requirements. Thus, you could extend your argument that the more excess you build into each network or subnet, the less likely that you will experience any problems. Such an argument is founded on the belief that IP addresses are infinitely available. That's not always the case. In fact, as mentioned at the beginning of this chapter, that is the case only with RFC 1918 addresses.

Overestimating growth in a unique range of IP addresses can result in prematurely exhausting that address space. Today, the watchdogs of the Internet's address space (IANA and ARIN) have really clamped down on giving out address space. Enterprises in particular are routinely turned down when they petition for their own address space. The current philosophy at IANA and ARIN is that, with all the tools currently available (including NAT and RFC 1918 addresses), there is no good reason for a private entity to "own" its own address space. As a direct result of this change in policy, you might not be able to obtain additional IP addresses should you exhaust your existing supply.

NOTE

Nobody really "owns" their IP addressesnot even those that might be registered to them directly. IANA owns the entire Internet address space, but it allocates blocks of addresses to Internet service providers. Those service providers can then assign smaller blocks to their customers for use in accessing, and being accessed from, the Internet. In accordance with RFC 2050 and Internet BCP #12, these assignments are to be regarded as leases. When the contract for service expires, gets canceled, or is not renewed, the customer is expected to return its assigned address block to the issuing service provider.


When you begin evaluating communities of users, it is imperative that you learn to appreciate how resistant to readdressing they would be. That's not to suggest that you do something as ham-fisted as ask them that question directly. Instead, try to figure out the technical and political sources of any potential reluctance to change within their environment. Generally speaking, all users hate change. But some hate it more than others. Those are the ones to identify early in the process.

Building in Growth

You can build in the appropriate amount of growth in a number of ways. Here are the three that I can think of:

  • Natural or architectural surplus inherent in the CIDR bit boundaries

  • Rounding up to the next-largest bitmask

  • Leaving explicit gaps between assigned blocks

These tools for building in growth are not mutually exclusive and can be used in combination.

Natural or architectural surplus is formed almost automatically by the architecture of the binary numbering system. Address blocks and subnets are both are created using powers of 2. Thus, the size of the space you carve out contains 1, 2, 4, 8, 16, 32, 64, 128, 256 (and so on) hosts. Statistically speaking, you will more frequently encounter networks with addressing requirements that fall between these powers of 2 than you will encounter an exact fit. Thus, there is some room for future growth almost automatically when you assign network prefixes or subnets.

Your next option for building in some fluff for future expansion is rounding up. For example, suppose a group requires 13 usable host addresses for its network. You could give them a /28 (or a subnet mask of 255.255.255.240), which yields a total of 16 host addresses.

Subtracting the reserved all-0s and all-1s addresses leaves only 14 usable host addresses. The natural or architectural room for growth in this network would be only one host!

NOTE

When sizing subnets, it is imperative to remember that addresses have to be assigned to nonuser devices, such as LAN switches, router interfaces, network printers, and so on. Thus, as a general rule, you need to overestimate rather than underestimate the number of addresses needed per subnet.


Rounding up that mask to a /27 (a subnet mask of 255.255.255.224) offers 32 total addresses. Subtracting the reserved-value addresses leaves 30 usable host addresses. The surplus for satisfying future growth is 17 addresses (30 13). That's a much nicer cushion for supporting future growth than just one address. This is about as much extra as you'd probably want to build into a community of that size. More than that becomes wasteful.

As nice as rounding up masks is for building native capacity for growth, this approach isn't a panacea. It works well for a while, but eventually it results in an inordinate number of surplus addresses. That's just the powers of 2 working against you. For example, rounding up from a /25 to a /24 results in an additional 128 host addresses. Rounding up from a /24 to a /23 generates an additional 256 addresses. Depending on your needs, that's probably a bit more than you really want to allocate. But it is important to recognize this tool for building in growth and to appreciate its abilities and limitations.

The last approach is one we'll look at in a bit more detail throughout the remainder of this chapter. Rather than play games with the binary mathematics of the address space, you can build in room for growth by simply leaving gaps between address spaces you assign. Done properly, two assigned spaces are buffered by a free or unassigned space. That space can then accommodate growth of either of its neighboring address blocks.

After evaluating your users' needs (present and projected) vis-à-vis your address space constraints and the pain of making mistakes, you should be able to make a much more informed decision about which basic tactic(s) you should use to manage your address space.

Basic Tactics

There are four basic address management tactics; each approach has its own strengths and weaknesses. You need to understand each one and then make your own decision about how useful it might be in the context of your job. I wouldn't be surprised if you concluded that the best tactic in any given situation is actually a blend of tactics.

The basic tactics you might find useful are

  • Sequential

  • Sequential with gaps

  • Predefining symmetrical gaps

  • Balkanization

Of course, the fifth option is always the random approach. I don't consider that a valid approach for managing an address space. An all-too-familiar scenario is when a new hostmaster comes into an organization, looks at the address allocation records he has just inherited, and concludes that his predecessor assigned blocks at random. I prefer to believe that what initially appears to be a random assignment of address space is nothing more than the entropic effects of constant change being exerted on an address space over time.

We'll examine each of these four basic tactics for managing an address space in the remainder of this chapter. First, I'll describe the approach and how it works. That will help you better appreciate some of the benefits and limitations or drawbacks. Then I'll show you a network diagram and a detailed table to demonstrate how a particular address management tactic would affect address assignment within the context of a specific network.




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