This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding DHCP
Public IP addresses are registered with the Internet Assigned Numbers Authority (IANA) so that IANA can keep track of IP addresses that are being used on the Internet. In some cases, a network is not connected to the Internet and does not need to use registered public IP addresses. In other cases, the network is connected to the Internet with special hardware and software that can be configured to allow the network to use private addresses in conjunction with address translation, commonly referred to as Network Address Translation (NAT). By using NAT, you can (in simple terms) place an entire private network behind a single public IP address. As an example, the organization I work for has more than 5,000 hosts on its internal network. When I or anyone else visits a website on the Internet, we all appear to be coming from a single IP address. That's NAT in action!
Quite often, systems administrators use private (unregistered) addresses on their internal networks to ensure that there are enough readily available addresses for all users. This model works great on a network that is not tied directly to the Internet. However, with the shortage of Class A and Class B (and even Class C) IP addresses, some environments use small pools of registered addresses to service larger numbers of DHCP clients; the idea is that not every client computer needs access simultaneously. These environments require aggressive leasing policies to ensure that everyone can get an address.
In addition to IP addresses, DHCP can provide gateway addresses, DNS server addresses, and Windows Internet Name Service (WINS) server addresses—in essence, everything the client computer needs to participate in the network. This means that all available IP addresses can be stored in a central database, along with associated configuration information such as the subnet masks, gateways, and addresses of DNS servers.
DHCP
DHCP provides the mechanism for dynamically distributing IP addresses on a network—but it doesn't happen magically. Here's how a client computer gets an address:
- After bootup, the client computer broadcasts a DHCPDISCOVER message that is intended for the DHCP server(s) on the network. If a router sits between the DHCP server and the client, it needs to be configured with the IP address of the DHCP server and also be configured to forward BOOTP. BOOTP is discussed in the next section, "BOOTP."
- Each DHCP server that receives the DHCPDISCOVER message responds with a DHCP offer message. That message includes an IP address that is appropriate for the subnet where the client computer is attached. The DHCP server determines the appropriate address by looking at the source subnet for the broadcast DHCPDISCOVER message.
- The client computer considers the offer messages and selects one (usually the first offer it receives). It sends a request (DHCPREQUEST) to use the address to the DHCP server that originated the offer. If there are multiple DHCP servers, they need to be carefully configured. It is easy to inadvertently configure servers and end up with them conflicting, so if you have multiple DHCP servers on a network, they should not be capable of offering duplicate IP addresses. Because DHCP servers do not communicate with one another, they have no way of telling whether another DHCP server has already issued an address.
- The DHCP server acknowledges the request and grants the client computer a lease to use the address.
- The client computer uses the IP address to bind to the network. If the IP address is associated with any configuration parameters, the parameters are incorporated into the client computer's TCP/IP configuration.
- For the first renewal of the IP address, when 50% of the configured lease time has elapsed, the client sends another DHCPREQUEST message to the DHCP server that granted its lease, asking to renew and extend its current lease. All subsequent lease renewal is at 75%.
- If the DHCP server is reachable, it responds with a DHCPACK message to the client, renewing and extending the DHCP lease as requested.
- If the DHCP server is not reachable, the client continues trying to reach it until 87.5% of the lease time has elapsed. At this point, the client attempts to renew its lease with any DHCP server that responds. If this is unsuccessful, the client starts the process of acquiring a new DHCP lease.
The first step of this process indicates that DHCP clients request their addresses by using broadcast messages. If you are familiar with routing, particularly TCP/IP routing, you are probably familiar with the fact that one of the benefits of routing is that the router segregates broadcast domains. In other words, broadcasts do not generally cross routers. Does that mean that DHCP works only on the local segment and you need 50 DHCP servers for 50 subnets? No, that is not the case—not if you configure your routers or other Windows Server 2003 computers to act as DHCP relay agents.
Configuring a router or server as a DHCP relay agent causes it to begin using BOOTP. BOOTP was the precursor to DHCP, and it was the first protocol used to assign IP addresses dynamically. BOOTP was specially designed to pass across a router, and it continues to be used to allow DHCP broadcasts to propagate across routers. You'll learn about the installation and configuration of DHCP relay agents later in this chapter, in the section "Configuring and Implementing a DHCP Relay Agent."
Bootp
Before we discuss installing and configuring the DHCP service in Windows Server 2003, a brief discussion about BOOTP is necessary. A number of DHCP's features had their beginnings in BOOTP. BOOTP was originally designed in 1985 by Bill Croft and John Gilmore to automate the configuration of network devices. To use BOOTP, the systems administrator must create a table with a list of client computers, their IP addresses, and their network configurations. When a client computer comes on to the network, it broadcasts a request that the BOOTP server receives. The BOOTP server looks up the client computer in the table and responds with the configuration information stored in the table, allowing the client computer to communicate on the network.
Because BOOTP worked well, it was used extensively in the early 1990s in conjunction with diskless workstations. (A BOOTP chip was a common option on a network interface card [NIC], and many networks thrived on BOOTP.) The downside of BOOTP was that it provided only the configuration information entered in the table. The administrator still needed to configure the table. The limitations of BOOTP effectively prevented any automation of these tasks, so it was eventually replaced with DHCP. BOOTP and DHCP packets look virtually identical, and DHCP even takes advantage of the BOOTP forwarder functionality of many routers and switches. DHCP offers the automation features BOOTP lacked.
Now that we've completed the history lesson, you should have a pretty good understanding of the theory of DHCP. Before moving on to the workings of DHCP in Windows Server 2003, let's examine the new DHCP features that Windows Server 2003 provides.