The Internet Protocol (IP) address is the most important configuration item in any TCP/IP system. It determines how your system interacts with others in an enterprise-wide network. For example, every address contains a local network identifier so that system can determine whether to deliver a particular message locally or forward it to a gateway or router. Each address also contains the identifier for that specific system, so it can be uniquely designated within its local network. Even if you address other systems by name, that name is translated into an IP address behind the scenes.
Given the significance of IP addresses, it's important to look at how they are assigned, configured, and maintained in a TCP/IP network. In particular, networks that configure and maintain IP addresses manually--the traditional, do-it-yourself management scheme--have significant shortcomings and potential pitfalls. In contrast, those that configure and maintain IP addresses automatically--such as Microsoft's Dynamic Host Configuration Protocol (DHCP)--are more stable and easier to manage. Let's start by looking at a problem common to both approaches: developing an enterprise-wide IP address scheme.
The Master Plan
Before individual IP addresses can be configured, the network administrator must devise an addressing scheme that conforms to the logical organization of the network. For example, if individual business units are to operate as independent networks, then the addressing scheme should break the network into smaller, self-contained subnetworks. Alternatively, if all the systems are to operate under the umbrella of one unified network, then one broad address scheme should be used.
The "rules" of constructing IP addresses also play an important role. IP addresses may follow one of three different formats (see the sidebar "Building an IP Address" on page 32). The format used determines the number of subnetworks allowed and the number of systems allowed within each of those subnetworks. Thus, the IP address "class" must be a reasonable match for the network being constructed. For example, Class C has a limit of 256 system addresses, so it's unreasonable to use Class C addressing for a network with more than 256 systems. (If the network will be connected to the Internet, the addresses must be registered with the Internet Network Information Center (InterNIC) and must not duplicate any existing Internet addresses.)
Once the network layout has been identified and the IP address Class selected, you can assign addresses to individual network systems. The usual procedure is to assign address ranges to logical groups of systems using the system portion of the IP address. These ranges should include both the network's current status and its projected growth. The range assignment can be done in different ways:
- Consecutive groups:/I Groups of systems can be assigned a series of consecutive addresses. For example, a department with 10 systems now and a projected growth to 15 systems could be assigned Class A addresses 126.96.36.199 through 188.8.131.52.
- Tagged groups:/I One or more bits in the address can be used to "tag" the address to a group. For example, all Class A addresses that begin with 191.0.1 could be assigned to one business unit; those beginning with 191.0.2 could be assigned to another one; and so forth. Each business unit could have up to 256 systems under this scheme.
If the network involves subnetworks, you can use the network component of the IP address to create groupings. For example, the Class A address 191.0 can be assigned to one business unit; 191.1 to another; and so forth. You can also use network groupings and systems groupings together. For example, 191.0.1 could be the research department in business unit A; 191.0.2 could be the sales department in business unit A; 191.1.1 could be the research department in business unit B; and 191.1.2 could be the sales department in business unit B. Using any method, you can easily create an IP address scheme that mirrors the breakdown of your logical networks.
If you are implementing subnetworks, make sure that you incorporate gateways or routers into your plan. Under TCP/IP, a message can't cross from one subnetwork to another without going through a gateway or router.
Once your IP address scheme is in place, the focus shifts to getting the addresses configured correctly in each system on the network. This is where the differences between manual and automated configuration procedures become obvious.
In the do-it-yourself approach, IP addresses are manually configured in each system according to the enterprise-wide addressing scheme. At first glance, this procedure may seem relatively simple--most systems have a variety of options that must be configured locally (e.g., type of display, size of hard disk). Once you dig deeper, however, you find that the do-it-yourself approach poses problems in two key areas:
- Finding skilled personnel to configure the systems in the field
- Implementing support procedures (documentation, Help desk, etc.) to assist in the configuration process and resolve any problems
Finding the right people to configure systems on the network depends on the types of systems deployed. While technical people familiar with system configuration procedures would find IP address configuration relatively simple, the client side of the modern client/server environment is filled with PCs and Macs. Non-technical people often use these machines, and they may not be comfortable making configuration changes to network-level software. Even if they have experience installing or configuring today's client/server networks, they aren't necessarily prepared to install and configure TCP/IP.
Why are TCP/IP installation and configuration so different? Client/server networks, such as NetWare, AppleTalk, and NetBEUI, don't require assigning individual addresses or identifying server addresses. Instead, they rely on the hardware addresses "burned in" to the LAN adapter cards. They may be coupled with either simple system names (as in AppleTalk and NetBEUI) or have no local identity at all (as in NetWare).
TCP/IP, however, requires configuring an IP address and a TCP/IP name server--the Windows Internet Name System (WINS) or the Domain Name System (DNS)--that can translate names into IP addresses (see "DNS Strategies" on page 27). On PC networks, clients and servers discover one another through broadcasts or other types of network announcements.
Technical hurdles notwithstanding, users are normally the best resources to handle the TCP/IP configuration of their own systems. If nothing else, they are ideally located. Calling on technicians to perform the configuration might be an option on small networks, but on larger networks it is often cost-prohibitive. For users to be effective, however, they need guidance and help. This points out the second shortcoming of manually configured IP addresses: You must implement a support procedure to make sure configuration changes go smoothly.
To implement a Help desk or some other support procedure, you must first realize that the documentation for TCP/IP is of little value in the field. You need to provide instructions--verbal or written--that are direct and to the point. Each system must be assigned a unique IP address; at some point, you need to define specific procedures for the users. These procedures may include a table look-up, a write-in field, or a call to obtain specific information.
Without a doubt, the biggest danger lies in the area of "helpful neighbors"--individuals who get their own systems working and then help others by exactly duplicating their own configuration on other systems. TCP/IP has no internal safeguards against duplicate addresses, and once defined, duplicate addresses become an annoying network problem that is difficult to track down.
As bad as it sounds, plenty of organizations have navigated their way through the problems and implemented perfectly functional networks. However, lots of companies have failed to implement TCP/IP networks because they didn't deal with the problems associated with manually configuring addresses.
The alternative to manually configuring network IP addresses is to implement a protocol that automates the process. Using this method, a system contacts the server and asks for the IP address it should use. When the server assigns it an address, the system is ready to use the network.
An automated IP configuration protocol eliminates the need to configure individual IP addresses for each system. Automated configuration allows you to develop one set of instructions for all systems on the network. It enables "helpful neighbors" to be really helpful; if you duplicate your configuration on a neighboring system, it works without causing subsequent network problems.
Are there negatives associated with automatic IP configuration? Not on the client side--it's certainly easier to set up a system. The trade-off, however, comes in the IP address server. Some server must maintain a list of available IP addresses as well as which addresses can be associated with which systems. In essence, the burden of configuration shifts from the user to the network administrator--where it belongs.
Microsoft was not the first company to ponder the question of automated IP configuration. Most UNIX implementations support two protocols that allow a system to discover its network identity: the Reverse Address Resolution Protocol (RARP) and the Boot Protocol (bootp). Both allow a system to request an IP address and other load information from a local server.
RARP and bootp were developed to handle diskless workstations and are not particularly dynamic or flexible. For example, to use RARP, the network administrator must manually maintain a file on the server that maps specific hardware addresses to specific IP addresses. Bootp has similar restrictions. As a result, a network administrator must make configuration changes in the RARP or bootp server to accommodate new systems or hardware changes (e.g., replacing an Ethernet adapter).
In contrast, Microsoft's DHCP solution is dynamic. Once the overall IP address scheme has been configured (see the sidebar "Configuring DHCP" on page 33), you can add individual systems at any time without changing the server. Whenever a DHCP server receives a request from a new client, it finds an available address and assigns it.
In addition to automatically configuring client-side IP addresses, DHCP can download IP addresses for name servers and other server-oriented services available to DHCP clients. You simply enable DHCP operation, and all the other relevant configuration values are downloaded from the DHCP server.
DHCP is a better choice than manual configuration, but its value doesn't end there; it also solves problems that come with RARP, bootp, and manually configured IP environments:
- Reclaiming unused addresses is a major headache in non-DHCP environments, because network administrators must rely on users or local managers to inform them of equipment changes. Thus, IP addresses may remain assigned to systems that are no longer on the network. Under DHCP when you remove client systems from the network, the DHCP server automatically reclaims the IP address and makes it available to a new system.
- System mobility is a major constraint in non-DHCP environments because each system is tied to a specific IP address and, therefore, to a specific network. If a system (e.g., a laptop) needs to move around on a large network that contains subnetworks, you must assign it multiple IP addresses, one for each subnetwork it's connected to. DHCP, on the other hand, accommodates new systems dynamically, so a laptop can be plugged in anywhere and receive an IP address relevant to that portion of the network.
The dynamic nature of DHCP does, however, change the way you develop and implement an enterprise-wide IP address scheme. While it's still advisable to create a scheme that represents the logical structure of your network, you must also keep in mind how DHCP clients and servers communicate with one another.
When a system generates a DHCP initialization request, it broadcasts a simple message containing its hardware address and its logical name. Because this is a broadcast message, the request will be picked up by the first DHCP server that "hears" it. This may be a server on the same local network or a server on another network connected by a router.
The server receiving the request uses the client's point of origin to determine which scope to apply to the request. The scope combines the subnetwork identification and the address range; each DHCP server is capable of handling multiple scopes. For example, a request coming in on the local network falls into one scope, while a request sent from a different network via a router falls into a different scope.
Once the server knows which scope to use, it performs a table look-up using the requesting system's hardware address and name to see if it had previously been assigned an address. If it had, that address is reassigned. If the systemis a new one, the server locates an unassigned address and passes it on to the client.
DHCP is oriented toward breaking a large network down into smaller subnetworks. Individual DHCP servers can be deployed in each subnetwork (each server supporting a different scope); a single server supporting multiple scopes can be used; or a series of servers (each server supporting multiple scopes) can be employed. A single DHCP server with one scope can handle a small network with no subnetworks.
DHCP doesn't force you to use dynamic addressing for all your systems. You can exclude individual addresses or ranges of addresses in your DHCP servers. These addresses can then be "permanently" assigned to servers and network printers, as well as to systems that don't support DHCP.
Manual or Automatic?
If you have already implemented your TCP/IP network or if you are looking at a small (24 systems or less) network, DHCP may appear to be of limited value to you. Don't be fooled. DHCP contributes value to all TCP/IP networks, regardless of size or stage of construction. Any time you remove a manual configuration step, you reduce your opportunities for error.
The best way to judge the value of DHCP is to see it for yourself. Fortunately, the flexibility of DHCP allows you to implement it on a trial basis. You can, for example, pick an arbitrary location and implement a DHCP server for a handful of client systems with no changes to the rest of the network.
Finally, you may be wondering: "If DHCP is so great, why aren't more people using it?" Unquestionably, the biggest issue with DHCP right now is the lack of availability of non-Microsoft TCP/IP software that supports it.
On the client side, DHCP availability is rapidly increasing as major network software vendors such as Walker, Richer, & Quinn release support for DHCP in their client products. The inclusion of DHCP into UNIX and other commercial systems will take longer. They have no vested interest in jumping on the DHCP bandwagon. But rest assured, if DHCP becomes a major force in the client/ server market, the others will follow.