DHCP for Windows 2000 | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Dynamic Host Configuration Protocol (DHCP) is an Internet standard protocol designed to dynamically allocate and distribute IP addresses as well as additional TCP/IP configuration information. DHCP is defined by RFCs 2131 and 2132. Working with the Internet Engineering Task Force (IETF) and a number of other vendors, Microsoft was instrumental in the development and standardization of DHCP.

Before the advent of DHCP, most TCP/IP configurations were maintained statically. An administrator configured each individual host with a valid IP address, subnet mask, and default gateway, as well as other TCP/IP configuration parameters. As you can guess, configuring and administrating static TCP/IP configurations for multiple workstations and network devices can be a burdensome task, especially if the network is large and/or changes frequently. The exception to the rule was the use of two predecessors to DHCP, the RARP and BOOTP protocols. These protocols are covered in more detail in Chapter 2.

DHCP uses a client/server model of operation (see Figure 1.1), where a DHCP client makes a request to a DHCP server for an IP address and other configuration parameters. When the DHCP client makes the request, the DHCP server assigns it an IP address and updates its database, noting which client has the address and the amount of time that the address can be used. This amount of time is known as a lease. When the time expires, the DHCP client needs to renew the lease or negotiate a new lease for a different IP address. Through the use of leases, the DHCP server can reclaim unused IP addresses.

Figure 1.1: The DHCP client/server model

Using DHCP allows an administrator to make changes to a client's IP configuration without the need to visit each and every client. The user at the workstation only needs to release and renew their DHCP lease. That is the power and benefit of DHCP.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the 1960s, the Department of Defense's Defense Advanced Research Projects Agency (DARPA) was in charge of developing a means of communication that would still function in the event of a nuclear war. Development focused on the new theory of the packet-switched network. All forms of networking up to this time (i.e., the phone system) had used a circuit-switched network.

A circuit-switched network connects the sending and receiving stations by a single, direct physical path. Circuit-switched connections are not shared with other traffic; they are meant to be one-to-one. The telephone system is an example of a circuit-switched network. When a person dials a phone number, the phone company equipment establishes a direct connection between the caller's phone and the receiving phone. This connection lasts for the duration of the call.

A packet-switched network operates by breaking the data to be transmitted into smaller datagrams or packets. Each of these packets is numbered and sent out across the network. Because the packets are individually numbered, they can take multiple paths to their destination. There they will be put back in order and reassembled into the original data.

Figure 1.2 illustrates the concepts of these two types of networks.

Figure 1.2: Circuit-switched and packet-switched networks

The weakness with a circuit-switched network is that communication links have to be set up ahead of time. If a circuit goes down, communication stops. The beauty of a packet-switched network is that if a point of communication goes down, the data is automatically rerouted through another location dynamically. In the end, it had great battlefield potential—which is what DARPA was looking for. If a command center was taken out, communications could continue by rerouting the data across any available medium: packet radio, satellite links, land links, etc.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Media Access Control (MAC) addresses are hardware addresses that uniquely identify a network interface card (NIC) in a host.

MAC addresses are 48 bits in length and are written as 12 hexadecimal digits. The first 6 hexadecimal digits identify the manufacturer of the NIC. This is known as the Organizational Unique Identifier (OUI), which is administered by the IEEE. Each manufacturer of Ethernet devices must register with the IEEE. The remaining 6 hexadecimal digits are used as a serial number, which is administered by the individual manufacturer (see Figure 1.6).

Figure 1.6: Example of MAC addresses

Table 1.1 lists the OUI numbers for several well-known NIC manufacturers.

Table 1.1: List of Common OUI Numbers
Manufacturer	OUI Number
Novell	00-00-1B
Cisco	00-00-0C
3Com	00-20-AF
HP	08-00-09
Apple	08-00-07
IBM	08-00-5A
Intel	00-90-27
Microsoft	00-50-F2

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

IP addressing is the heart of the TCP/IP-based internetwork. The process of routing IP packets is possible because of this logical addressing scheme.

An IP address is a logical 32-bit binary number that identifies a system on an internetwork. An IP address comprises two parts—the network portion and the host portion. The network portion of an IP address tells the host what logical network it is located on. The host portion identifies that particular host.

Because humans tend to have trouble remembering and evaluating binary numbers, IP addresses are expressed in dotted decimal notation. A 32-bit binary IP address is written out in four octets, each of which contains eight bits. Each bit position in an octet represents a value (one of 128, 64, 32, 16, 8, 4, 2, 1); the sum of these values, when totaled, represents the octet's decimal value (see Figure 1.9).

Figure 1.9: Dotted decimal example

Initially, when IP was developed, the IP address space was divided into distinct IP address classes to determine where the network portion stops and the host portion begins. The value of the first octet and its highest order (leftmost) bits determine the class. There are five IP address classes, three of which (A, B, and C) are available for commercial use (see Figure 1.10). Class D is reserved for IP multicasting. Multicasting allows multiple computers in the same multicast group to receive the same data transmission, sort of like a directed broadcast. Class E is strictly reserved for research use by the Internet Engineering Task Force (IETF).

Figure 1.10: IP address classes

Section 1.3.2.1: Class A

In a Class A IP address, the network portion is represented by the first octet; it has 0 in its leftmost bit. In other words, if you were to set all the remaining bits in the first octet to 0s, the resulting value for the octet would be 0. If you set all the remaining bits in the first octet to 1s, the resulting value would be 127. Therefore all Class A IP addresses fall into the 0-127 range for the first octet. This also results in 127 possible networks and a maximum of 16,777,214 hosts on each network. (Please note that the network 127.0.0.0 is reserved for loopback addresses.) Figure 1.11 summarizes the characteristics of the Class A address class.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Trying to remember many IP addresses is nearly impossible for anyone, especially with the growth of the Internet during the past 10 years. Hostnames make everyone's life easier by giving an IP address a memorable name. After all, remembering microsoft.com is much easier than remembering 207.46.130.149.

Originally, in the dark days of the Internet and TCP/IP, hostname resolution was left to a single text file, called the HOSTS file. Hostnames were manually added to this file, and then the file was downloaded and distributed to each TCP/IP host. HOSTS files work fine and are manageable if your network is small. HOSTS files in Windows NT and Windows 2000 are stored in the %systemroot%\SYSTEM32\DRIVERS\ETC directory. Example 1.1 shows a sample HOSTS file.

Example 1.1. Sample HOSTS File

# Copyright (c) 1994 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Chicago
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

127.0.0.1          localhost
192.168.0.l        cg141484-a
192.168.0.254      proxy
192.168.0.2        nalcott

The HOSTS file method of hostname resolution became more cumbersome and inefficient as the Internet grew. In 1984, two new RFCs (882 and 883) were released detailing DNS. These RFCs have since been superceded by RFCs 1034 and 1035.

DNS is a distributed database that allows local administrators to maintain their portion of the DNS database while allowing access to it for hostname resolution across the entire Internet. DNS is implemented in a client/server arrangement. The server portion is driven by name servers. Name servers hold the segment of the DNS database (called a zone) that they have authority over. The client portion is known as a resolver. This can be any TCP/IP client that supports DNS. Whenever you are using the Internet, whether it is the World Wide Web or simply email, you are using DNS.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Windows 2000 is the first Microsoft operating system with the capability to rely completely on DNS for name resolution. The primary naming system for Microsoft networks before Windows 2000 was based on NetBIOS names. A computer's NetBIOS name, sometimes called its "computer name," is assigned by the administrator who first installs the operating system. Modifying the network properties on the operating system can also change the NetBIOS name. Although Windows 2000 relies heavily on DNS for name resolution, the installer must still assign the computer a computer name. This name is then used for the computer's hostname as well as its NetBIOS name. Each computer has its own NetBIOS name that it broadcasts to all other computers on the network.

As you can imagine, maintaining NetBIOS names on a local area network is extremely easy, because whenever it is booted up, a computer always either broadcasts its NetBIOS name or adds itself to the NetBIOS name database on a WINS server.

However, using NetBIOS names in a subnetted environment suffers the major limitation that routers do not forward broadcasts. Therefore computers in different subnets are never aware of each other.

One method of eliminating this problem is using an LMHOSTS file (see Example 1.1). Much like a HOSTS file, an LMHOSTS file is a text file listing NetBIOS names and their corresponding IP addresses. To facilitate NetBIOS name resolution on an internetwork, an administrator has to manually edit and distribute LMHOSTS files to all computers on the internetwork.

Example 1.2. Sample LMHOSTS File

192.168.0.2    nalcott     #PRE  #DOM:ALCOTT  #DC for network
192.168.0.254  proxy       #PRE  #Proxy Server for Network
192.168.0.1    cg141484-a  #PRE

To alleviate some of these problems, Microsoft introduced the Windows Internet Naming Service (WINS) with Windows NT. WINS maintains a NetBIOS name database much like

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter gave an overview of some of the configuration information that DHCP is expected to deliver to its clients.

TCP/IP is the dominant network protocol in use in today's network environments. It is also the network protocol for the Internet, and I strongly urge that you learn as much about it as you can. Understanding TCP/IP will help you configure, maintain, and troubleshoot many systems that a network engineer will encounter.

The chapter began with a discussion of the TCP/IP protocol suite. This included a comparison of the two common reference models: the Open Systems Interconnect (OSI) Model and the Department of Defense (DOD) Reference Model. During the discussion I delved into the various layers in the models and provided examples of how the various components in TCP/IP are implemented.

Next I moved into a discussion on hardware addresses. These addresses, also known as MAC addresses, are used to uniquely identify the network interface card (NIC) in a computer.

The next section described IP addressing. IP addressing is the heart of a TCP/IP-based network. An IP address is a 32-bit binary number that identifies a computer on a network. It contains two parts: the network portion and the host portion of the address. This section also included a discussion of IP address classes and how they are employed. The section concluded with a discussion of IP subnetting and Classless Interdomain Routing (CIDR). The entire concept of packet routing is made possible through the use of IP addressing.

The chapter concluded with a discussion of the various name resolution processes found on Microsoft TCP/IP-based networks. This included Domain Name System (DNS), which is the standard name resolution process for many corporate networks and the Internet. Windows Internet Naming Service (WINS) is used on Microsoft networks to provide NetBIOS to IP address name resolution.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter describes the predecessors to DHCP, the Reverse Address Resolution Protocol (RARP) and the Bootstrap Protocol (BOOTP). These two protocols are illustrated here to highlight the need for a more robust and dynamic configuration protocol as well as to provide a basic foundation to understanding DHCP.

RARP is a protocol that exists at the Data Link Layer. Think of it as the exact opposite of ARP (described in Chapter 1). It provides a mechanism for a host to determine its IP address when it is only aware of its MAC address.

RARP typically is utilized when a diskless workstation is booted. Since it does not have any IP configuration data stored locally, it must use RARP to find out its IP address. RARP accomplishes this by using a client/server process. The RARP server contains a database that simply maps IP addresses to their corresponding MAC addresses.

When a RARP client wants to find out its IP address, it sends a broadcast Ethernet frame (target MAC address = FF:FF:FF:FF:FF:FF) containing its MAC address. The RARP server, upon receiving the message, looks up the requester's MAC address in its RARP table. If a match is found, the RARP server creates a reply packet that contains the requester's IP address (see Figure 2.1). If no match is found, the packet is discarded.

Figure 2.1: Example of RARP

Although very basic in functionality, RARP can determine and configure a diskless workstation with an IP address. However, it does not contain a method for determining and delivering other configuration data (e.g., subnet mask, default gateway, etc.). Another downside of RARP is that an RARP server can service only a single subnet because of its complete reliance on Ethernet broadcasts. To overcome these shortfalls, another protocol was developed, called BOOTP.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

RARP is a protocol that exists at the Data Link Layer. Think of it as the exact opposite of ARP (described in Chapter 1). It provides a mechanism for a host to determine its IP address when it is only aware of its MAC address.

RARP typically is utilized when a diskless workstation is booted. Since it does not have any IP configuration data stored locally, it must use RARP to find out its IP address. RARP accomplishes this by using a client/server process. The RARP server contains a database that simply maps IP addresses to their corresponding MAC addresses.

When a RARP client wants to find out its IP address, it sends a broadcast Ethernet frame (target MAC address = FF:FF:FF:FF:FF:FF) containing its MAC address. The RARP server, upon receiving the message, looks up the requester's MAC address in its RARP table. If a match is found, the RARP server creates a reply packet that contains the requester's IP address (see Figure 2.1). If no match is found, the packet is discarded.

Figure 2.1: Example of RARP

Although very basic in functionality, RARP can determine and configure a diskless workstation with an IP address. However, it does not contain a method for determining and delivering other configuration data (e.g., subnet mask, default gateway, etc.). Another downside of RARP is that an RARP server can service only a single subnet because of its complete reliance on Ethernet broadcasts. To overcome these shortfalls, another protocol was developed, called BOOTP.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

BOOTP, much like RARP, is a protocol that allows a diskless host to request an IP address. It also provides other configuration parameters, as well as supplying a boot file. BOOTP is an IP-based protocol that uses UDP to provide the communication between a BOOTP client and a BOOTP server. More importantly, BOOTP allows hosts (e.g., desktop PCs, servers, X terminals, etc.) to be dynamically configured to use the TCP/IP protocol suite. So instead of manually configuring each TCP/IP-based host on a network, BOOTP delivers the information automatically without user intervention.

BOOTP is a client/server process where the BOOTP client, during the boot phase, requests configuration information from a BOOTP server. The BOOTP server, upon receiving the request from the BOOTP client, looks up the client's MAC address in its BOOTP configuration database and sends a reply containing IP configuration information. The client receives the reply and configures its TCP/IP stack. The BOOTP client will also load a boot file if the BOOTP server supplies a path using the fully qualified filename. A major improvement is the magic cookie, which is a mechanism for a BOOTP server to supply vendor-specific operating system (OS) options to a BOOTP client. These options could include DNS servers, WINS or NetBIOS name servers (NBNS), time servers, etc.

There are many configuration options (known as vendor options) available. Refer to RFC-1533 (http://www.ietf.org/rfc/rfc1533.txt) for a complete listing.

Some of the more important information supplied includes:

IP address
IP subnet mask
IP address of the default gateway for the client's subnet
IP addresses of primary and secondary DNS servers
IP addresses of primary and secondary WINS or NBNS

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before delving into the conversation between a BOOTP client and a BOOTP server, I will examine the packet structure of the BOOTP protocol (see Figure 2.2).

A BOOTP packet's transmission order is from left to right, top to bottom—just as you are reading this page. The number shown in parentheses is the number of octets (or bytes) each field occupies.

Figure 2.2: BOOTP packet structure

Table 2.1 lists the available fields in a BOOTP packet and describes the type of information each field is to supply.

Table 2.1: BOOTP Field Definitions
Field	Definition
op	Specifies the message type: if 1, the message is a BOOTPREQUEST; if 2, the message is a BOOTPREPLY.
htype	Specifies the hardware address type (i.e., Ethernet or Token Ring). 10 Mbps Ethernet = 1.
hlen	Specifies the hardware address length. Ethernet = 6.
hops	Specifies the number of hops or routers between the client and the server.
xid	Specifies the transaction ID number. This is a random number that is used to match up the request with the reply that is returned.
secs

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Let's explore the BOOTP conversation in more detail. There are two types of BOOTP messages, the BOOTPREQUEST and the BOOTPREPLY. The packet structure of these messages is identical; the only difference is in the type of information they contain.

When the BOOTP client firsts boots up, it constructs a BOOTPREQUEST message and broadcasts this message across the network. This message includes information that allows the BOOTP server to determine what configuration data it must supply to the requesting host.

The BOOTPREQUEST message contains the following information:

Source's MAC address: From the client's LAN adapter
Destination's MAC address: FF:FF:FF:FF:FF:FF (Ethernet broadcast)
Destination's IP address: 255.255.255.255 (IP broadcast)
Source's IP address: 0.0.0.0 (unless the requester knows its IP address)
Destination server hostname: If requester prefers a specific server
Boot filename: If requester prefers a specific boot file
Vendor-specific data: Configuration data relating to operating system-specific functions.

Let's take a moment to examine the contents of a BOOTPREQUEST message. In this example, I will work my way up the OSI Model starting with the Data Link Layer.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

RARP and BOOTP were simply the first steps in figuring out a method to deliver IP configuration information. After RARP was developed, it became apparent that it had a couple of major shortfalls. First, a RARP server could only operate on a single subnet. Second, it lacked the critical ability to provide any IP configuration information other than the IP address.

Although BOOTP provided a vast improvement over RARP, it also suffered some serious shortfalls. First, the BOOTP database was a static text file. This meant that administrators needed to maintain the file by hand as changes were made to the network. A simple change like replacing a host's network interface card required the administrator to update the BOOTP database file. Another shortfall was the inability to dynamically allocate and distribute IP addresses. In the age of depleted IP address space, dynamic IP addressing was a critical feature.

Seeing this, the IETF started work to create a new protocol that would overcome these shortfalls: Dynamic Host Configuration Protocol (DHCP).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter provides an introduction to the Dynamic Host Configuration Protocol (DHCP). As you will see, DHCP shares many traits with BOOTP. However, they are two separate protocols and as such operate in different ways. I will also detail the DHCP conversation that takes place between a DHCP client and DHCP server. Finally I will cover DHCP relay agents, which allow DHCP to operate in a subnetted environment by relaying requests between the client and server, and how relay agents operate.

As shown in the previous chapters, RARP and BOOTP made inroads towards creating a way to dynamically configure a host on a TCP/IP-based network. RARP provided a means of obtaining an IP address; however, it could only function on a single subnet and did not provide any other configuration information, such as the subnet mask and default gateway. BOOTP alleviated some of the problems of RARP, but an administrator still had to maintain static configuration files on the BOOTP server. Also, BOOTP clients could not renew their configurations until the system was restarted, thus triggering the BOOTP process.

DHCP, defined in RFC2131 and RFC2132, was developed to alleviate many of these shortcomings and to accomplish the following:

DHCP allows administrators to control configuration parameters on their network.
Clients using DHCP can be dynamically configured. This allows additions and changes to networks without the need to visit each individual host or workstation.
For fault tolerance, multiple DHCP servers can service one or more subnets.
DHCP servers, via BOOTP relay agents, can service more than one subnet.
DHCP provides a dynamic database for IP address allocation. These IP addresses, when no longer in use, can also be reclaimed via lease durations.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As shown in the previous chapters, RARP and BOOTP made inroads towards creating a way to dynamically configure a host on a TCP/IP-based network. RARP provided a means of obtaining an IP address; however, it could only function on a single subnet and did not provide any other configuration information, such as the subnet mask and default gateway. BOOTP alleviated some of the problems of RARP, but an administrator still had to maintain static configuration files on the BOOTP server. Also, BOOTP clients could not renew their configurations until the system was restarted, thus triggering the BOOTP process.

DHCP, defined in RFC2131 and RFC2132, was developed to alleviate many of these shortcomings and to accomplish the following:

DHCP allows administrators to control configuration parameters on their network.
Clients using DHCP can be dynamically configured. This allows additions and changes to networks without the need to visit each individual host or workstation.
For fault tolerance, multiple DHCP servers can service one or more subnets.
DHCP servers, via BOOTP relay agents, can service more than one subnet.
DHCP provides a dynamic database for IP address allocation. These IP addresses, when no longer in use, can also be reclaimed via lease durations.
Clients can continue to use a DHCP-allocated IP address even after the client is rebooted. BOOTP clients must always obtain an IP address from a BOOTP server when they are booted.

It is important to remember that DHCP is based on the earlier BOOTP protocol. They share many of the same characteristics:

Client/server operating model: IP configuration information is allocated when a client requests an IP address from the server. The server holds and maintains the configuration information via either static files (on the BOOTP server) or a dynamic database (on the DHCP server).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Let's examine the packet structure of the DHCP protocol. As you will see, the DHCP packet structure is fundamentally the same as the BOOTP packet structure. There are only two differences: the vend field was changed to the options field, and this field was expanded from 64 octets in length to a minimum of 312 octets.

As shown in Figure 3.1, a DHCP packet's transmission order is from left to right, top to bottom. The number shown in parentheses is the number of octets (or bytes) each field occupies.

Figure 3.1: DHCP packet structure

Table 3.1 lists the available fields in a DHCP packet and describes the type of information each field supplies.

Table 3.1: DHCP Field Definitions
Field	Definition
`op`	Specifies the message type: if 1, the message is a BOOTPREQUEST; if 2, the message is a BOOTPREPLY.
`htype`	Specifies the hardware address type (i.e., ethernet or token ring). 10 Mbps Ethernet = 1.
`hlen`	Specifies the hardware address length. Ethernet = 6.
`hops`

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are three main components in a DHCP conversation, as shown in Figure 3.2.

The first component, the DHCP client, is the software portion of an operating system that is designed to request IP addresses and other related configuration information. Once it receives the requested information, the software reconfigures the operating system.

The second component, the DHCP server, is a program that listens for requests from DHCP clients on the network and supplies them with the information that is requested. The DHCP server is maintained by a network administrator. It is configured with a database that houses the configuration information, including IP addresses, subnet masks, default gateways, and DNS and WINS server addresses. The database also tracks which IP addresses are currently in use and which MAC addresses are using them.

The third component is the DHCP relay agent. Identical to the BOOTP relay agent, the DHCP relay agent listens for DHCP broadcasts on its local subnets. The DHCP relay agent is configured with IP addresses of DHCP servers. If it receives a DHCP broadcast from a DHCP client, the DHCP relay agent will send the request as a unicast message directly to a DHCP server. I will examine BOOTP and DHCP relay agents later in this chapter.

Figure 3.2: The DHCP conversation

DHCP greatly differs from BOOTP in how it handles the conversation between DHCP clients and DHCP servers. The DHCP conversation is more robust, so DHCP is more dynamic and flexible. Whereas BOOTP provides a simple conversation between a BOOTP client and a single BOOTP server, DHCP provides a full conversation, allowing multiple DHCP servers to respond to a DHCP client's single request.

Let's take a moment and walk through a typical DHCP conversation between a DHCP client and DHCP server on a local subnet. Later in this chapter, I will discuss how DHCP relay agents allow DHCP to operate in a multiple-subnet environment.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As noted earlier, the entire DHCP conversation takes place using broadcast messages. When a DHCP client requests an IP address, it sends a broadcast DHCPDISCOVER message to the local subnet. DHCP servers, in turn, respond to the request by broadcasting DHCPOFFER messages. The client receives these messages and accepts one of them. The client then responds with a broadcast DHCPREQUEST message, in which the DHCP server that was selected is identified. The DHCP server, upon receiving the DHCPREQUEST message, allocates the IP address in its database and responds with a DHCPACK message to the client.

So what happens if the network environment is not a single subnet, but a routed environment containing multiple subnets? In a routed environment, separate segments are connected via routers. A router is a hardware component that contains two or more interfaces that connect the router to the multiple physical segments. The router directs traffic between the subnets by examining the destination IP addresses in the packet headers. If a packet is destined for another subnet, the router examines its routing table to determine if a route to that subnet is available. If one is available, the router sends the packet out the interface that is the next hop to the subnet. If a route is not available, the router drops the packet and sends an ICMP message to the sending computer stating that the destination is not available.

Besides routing packets, another role a router plays is containing broadcast traffic to a single subnet. Broadcast traffic can take many forms, such as ARP requests, DHCP requests, NetBIOS name resolution requests (B-Node), etc. If broadcast traffic like this was permitted to travel throughout the network, the network would come to a grinding halt. By containing these broadcasts, routers create what is known as a broadcast domain (see Figure 3.8).

Figure 3.8:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this chapter, I described the differences between BOOTP and DHCP. Although they share many traits, there are significant differences in their operation. The BOOTP conversation is very simple, comprising a request and a reply. Because BOOTP uses static configuration files, and a client's MAC address must be listed in the file to receive an IP address, only one BOOTP server can be operational on a network at a time. The DHCP conversation in which a DHCP client broadcasts a request that multiple DHCP servers can receive is more robust. All DHCP servers that receive the request can respond. The DHCP client can then select a lease offer.

Also covered were the reasons why DHCP was developed and is currently being used in today's TCP/IP-based networking environments. Next I went step by step through the DHCP conversation, detailing the data that is supplied by each type of message. Finally I covered how the DHCP relay agent operates. When the DHCP client requests an IP address, it broadcasts the request. In a routed environment, routers do not route broadcasts. The DHCP relay agent provides a method for DHCP to function in a routed environment by intercepting DHCP requests and forwarding the request as a unicast message directly to the DHCP server.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

DHCP can quickly become an essential piece of an organization's data network. Once set up, DHCP is usually hardly noticed, silently and faithfully performing its duties day in and day out. Unfortunately, the hardest thing with DHCP is getting it to that point.

This chapter discusses the reasons an organization would want to use DHCP, along with the many different issues that need to be considered when designing a DHCP infrastructure.

Some of these considerations include planning for IP address use. An organization needs to determine how their existing environment is used as well as what types of users and workstations exist, such as mobile users and network devices.

The needs of a DHCP client must be considered, including which DHCP options are supported by the client's operating system and which options and their values need to be assigned.

In large-scale DHCP implementations, the topology of the network becomes a very important factor. The network topology dictates where DHCP servers and/or relay agents must be placed.

A final consideration is planning for fault tolerance. Once DHCP is implemented, it quickly becomes a service that the entire network is dependent on. Steps can be taken to ensure that DHCP will be available at all times.

The Internet Engineering Task Force (IETF) created this new protocol, DHCP, to dynamically distribute IP addresses and configurations to clients. But what types of organizations would benefit from using DHCP?

Some administrators believe that having to administer yet another network service and the additional traffic it creates is an unnecessary burden. Administrators with this philosophy believe that it is easier to set up workstations and servers with static configurations that do not need to be maintained or administered.

In reality, however, any organization that wants to save the time and aggravation of manually maintaining the allocation of IP addresses would want to use DHCP. DHCP allows an administrator to standardize the IP address configurations for the entire network while dynamically maintaining the address table in a database.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Internet Engineering Task Force (IETF) created this new protocol, DHCP, to dynamically distribute IP addresses and configurations to clients. But what types of organizations would benefit from using DHCP?

Some administrators believe that having to administer yet another network service and the additional traffic it creates is an unnecessary burden. Administrators with this philosophy believe that it is easier to set up workstations and servers with static configurations that do not need to be maintained or administered.

In reality, however, any organization that wants to save the time and aggravation of manually maintaining the allocation of IP addresses would want to use DHCP. DHCP allows an administrator to standardize the IP address configurations for the entire network while dynamically maintaining the address table in a database.

Small companies benefit from DHCP because of the lower administrative burden. Most small companies cannot afford a full time network administrator who knows the ins and outs of IP addressing. Typically they delegate network administration to the one person in the office who is the most computer-savvy, whether or not he or she has technical training or experience with networking. By utilizing DHCP, the day-to-day administration of IP addressing and associated configuration details is handled automatically without any intervention from office personnel.

The biggest problem for small companies is the initial implementation of DHCP. Small companies may have to use a consultant for the initial implementation, during which the designated administrator is trained in the administration of DHCP. Alternatively, the administrator can attempt the DHCP implementation through trial and error, although this is not recommended.

Larger enterprises benefit from DHCP on two fronts: lower administrative burden and standardized IP configurations throughout the organization.

The benefit of lower administrative burden is similar to the benefit reaped by a small company, with the addition of the time saved from administering an IP address table. The next section about static IP addressing discusses some of the problems with manually maintaining the IP address table.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before deciding to implement DHCP, an administrator must first decide on an IP addressing plan. There are many different ways to create an IP addressing plan, and in some cases they may need to be combined. This is a critical step because it is the foundation of the entire DHCP infrastructure. This section looks into each of the different methods, describing their benefits, how they may be implemented, and some of their limitations.

In an environment that uses static IP addressing, when an administrator installs a new workstation, she looks up an available IP address and the corresponding subnet mask in the IP address table. This table may be written in a notebook or saved on a computer in a spreadsheet. Once she finds the IP address, she needs to determine the correct DNS and WINS server addresses for the workstation to use. In addition, in a routed environment, the administrator needs to ascertain the correct default gateway address for the workstation's subnet. Then she manually configures the workstation with the proper TCP/IP information. For small networks or networks that do not experience many changes, this may be fine.

One of the downsides to this method of administering IP addresses is human error. If the administrator mistypes the IP address or subnet mask, the workstation may not have connectivity to the resources it requires. If the DNS or WINS server IP addresses are mistyped, the workstation will not be able to perform name resolution. If the default gateway is incorrect, the workstation will not be able to connect to remote subnets and resources.

Another downside is maintaining the IP address table. The administrator must continually spend time viewing and searching the address table for available addresses. Once she finds an available address, the administrator must note in the table that the IP address is now in use. Also, by storing the address table in a notebook, the table could easily be lost. Even storing the address table in a spreadsheet does not lessen the chance that it will become corrupted or lost.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When designing a DHCP infrastructure, it is important to take into account the topology of the network being serviced. By determining the topology, the designer will be able to anticipate where the load on the DHCP servers may be high and identify single points of failure that may cause DHCP services to be disrupted.

There are two different areas that need to be examined:

The physical layout of the network
The number of users in each physical location

By determining the physical layout of the network, the designer will be able to create a list of subnets that need to be serviced by DHCP. This information will be needed when scopes are created later.

Another important factor is the placement of DHCP relay agents. The physical layout of the network establishes which routers and subnets will need to be serviced by relay agents.

The number of users in each location helps determine the placement of DHCP servers. If there are a small number of users located in a single location, the DHCP server may be placed in a remote subnet with a DHCP Relay Agent set up on the router to listen for DHCP requests. This eliminates the need to place a server physically on the LAN where the users reside. If the WAN link goes down, the number of users disrupted is minimized.

If some of your DHCP clients at remote sites are Windows 2000 or Windows 98 systems and the WAN link goes down, they will not be able to contact a DHCP server. As mentioned earlier in this chapter, when these operating systems fail to contact a DHCP server, they resort to using APIPA to obtain an IP address. As a result, once the WAN link is restored, they will not be able to achieve network connectivity with the rest of the production network until the APIPA address is released. Connectivity is restored once a new address lease is obtained from the DHCP server. See Chapter 7, for information about disabling APIPA in Windows 2000 and Windows 98.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before creating any scopes, an administrator must first determine the needs of the DHCP clients the scope will be servicing.

Besides receiving an IP address, subnet mask, and default gateway from a DHCP server, DHCP clients can receive DHCP options that supply many different configuration parameters. Deciding which DHCP options to include can be determined by asking the following questions:

Which DHCP options do DHCP clients in this scope require?
What DHCP clients are in use on the network?
Which DHCP options do the DHCP clients support?

Determining which options are required is relatively simple, unless there are applications in use that have special needs. Besides determining which options to use, an administrator must determine the values of those options as well. For example, an administrator wants the DHCP clients to receive DNS server addresses. For load balancing, each subnet has a different secondary DNS server to service client requests. In this case, the administrator must supply the correct IP address for each subnet's DNS server.

Next, an administrator must determine which DHCP clients are in use on the network. Since Microsoft operating systems are the most prevalent on most corporate desktops and laptops, it can pretty much be said that almost every network includes some Microsoft DHCP clients.

But there may be other types of DHCP clients as well, such as Unix, Linux, or Macintosh. Although these operating systems can all be DHCP clients, their implementations of DHCP vary. For example, they may not support certain DHCP options, such as WINS servers. The DHCP server in Windows 2000 supports all DHCP options defined in RFC2132. If you have a non-Microsoft DHCP client, you can configure the Windows 2000 DHCP Server to supply any DHCP option that the client can support. Refer to your non-Microsoft DHCP client's documentation for a complete list of supported DHCP options.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that the IP addressing plan, network topology, and DHCP client needs have been defined, it is time to start defining the various scopes.

When defining a scope, the most important information to define is the address range of the scope. The address range will be used by the DHCP server to determine which IP address to assign to a DHCP client. The address range is defined by the subnet the scope will be servicing. For example, if the subnet is 10.64.0.0/11, the valid range of IP addresses for this scope is 10.64.0.1 through 10.95.255.254. For any statically configured network devices on that subnet, exemptions have to be created. An exemption designates an IP address not to be assigned to a DHCP client. If a static IP address was not exempted, the DHCP server may assign the IP address to a DHCP client. As a result, an IP address conflict could occur and cause connectivity problems for the two computers involved.

If the IP addressing plan calls for using dynamic address allocation for this subnet, simply assign the address range to the scope. If the IP addressing plan calls for using manual address allocation, reservations need to be created for each network device.

Lease durations determine when the DHCP server can reclaim the allocated IP address. Usually the default time period, 8 days, is more than sufficient for most scopes. Setting the lease duration too long will cause IP addresses to be shown as allocated, thus unable to be reclaimed. Setting the lease duration too short may cause excessive DHCP traffic on the network as DHCP clients attempt to renew their address leases.

One situation that does call for a shorter lease duration is when the roaming address allocation method is being used on a scope. By specifying a short lease duration, the DHCP server will be able to reclaim IP addresses that are only in use for a short period of time, such as a conference room or library.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|

Table of Contents

Section 1.3.2.1: Class A