Dynamic Host Configuration Protocol (DHCP) Server Service

Overview

To communicate successfully with each other, all TCP/IP hosts must be properly configured. These hosts require a valid IP address that is unique on the host's internetwork, a subnet mask, and a default gateway. If the host is to communicate only on the local subnet, the default gateway can be omitted. For larger networks, additional configuration items are required, such as Domain Name System (DNS) server IP addresses, Windows Internet Name Service (WINS) server IP addresses, and NetBIOS node types.

In small networks, carrying out this configuration requires a degree of TCP/IP skill that might not be readily available. On large networks, ensuring that all hosts are properly configured can be a considerable management and administrative task, especially in a dynamic network with roaming users and laptops. Manual configuration or reconfiguration of a large number of computers can be time consuming, and errors in configuring an IP host can result in the host being unable to communicate with the rest of the network.

DHCP is a client/server protocol that simplifies the management of client IP configuration and the assignment of IP configuration data. With DHCP, administrators define all necessary configuration parameters on a central server or a set of servers, which are then able to provide hosts with all necessary IP configuration information.

DHCP provides four key benefits to those planning, designing, and maintaining an IPnetwork:

• Centralized administration of IP configurationThe DHCP administrator can centrally manage all IP configuration information. This eliminates the need to manually configure individual hosts when TCP/IP is first deployed, or when IP infrastructure changes are required.
• Seamless IP host configurationThe use of DHCP ensures that DHCP clients get accurate and timely IP configuration parameters without user intervention. Because the configuration is automatic, troubleshooting is largely eliminated.
• FlexibilityUsing DHCP gives the administrator increased flexibility over changes in IP configuration information, allowing the administrator to change IP configuration more simply as infrastructure changes are needed.
• ScalabilityDHCP scales from small to large networks. For very small, isolated networks, Automatic Private IP Addressing (APIPA) can be used.

Overview of DHCP in Windows Server 2003

This section presents an overview of DHCP and defines key DHCP terms.

What Is DHCP?

DHCP is a client/server protocol that automatically provides an IP host with its IP address and other related configuration information such as the subnet mask and default gateway. RFCs 2131 and 2132 define DHCP as an Internet Engineering Task Force (IETF) standard based on the Boot Protocol (BOOTP), with which it shares many implementation details. DHCP allows hosts to obtain all necessary TCP/IP configuration information from a DHCP server.

More Info

DHCP is an IETF standard based on the BOOTP protocol and is defined in RFCs 2131 and 2132, which can be found in the Rfc folder on the companion CD-ROM.

All Microsoft Windows Server 2003 products (including Standard Edition, Enterprise Edition, Web Edition, and Datacenter Edition) include a DHCP Server service, which is an optional installation. All Microsoft Windows clients automatically install the DHCP client service as part of TCP/IP, including Windows Server 2003, Windows XP, Windows 2000, Windows NT 4, Windows Millennium Edition (Windows Me), and Windows 98.

DHCP Overview and Key Terms

Before examining DHCP in detail, you should be familiar with the following key DHCP-related terms:

DHCP Clients and Servers

A computer that gets its configuration information from DHCP is known as a DHCP client. DHCP clients communicate with a DHCP server to obtain IP addresses and related TCP/IP configuration information. DHCP servers hold information about available IP addresses and related configuration information as defined by the DHCP administrator.

DHCP Scopes and Options

A set of IP addresses and associated configuration information that can be supplied to a DHCP client is known as a scope. A scope is a set of IP addresses that the server can issue to DHCP clients, along with one or more options. An option is a specific configuration item such as a subnet mask and a default gateway IP address, which the DHCP administrator wants the DHCP server to provide to the DHCP client.

A DHCP administrator can create one or more scopes on one or more Windows Server 2003 servers running the DHCP Server service. However, because DHCP servers do not communicate scope information with each other, the administrator must be careful to ensure that the scopes are defined carefully so that multiple DHCP servers are not handing out the same IP address to different clients, or handing out addresses that are taken by existing, manually configured IP hosts.

The IP addresses defined in a DHCP scope are continuous and are associated with a subnet mask. To allow for the possibility that some IP addresses in the scope might have been already assigned and in use, the DHCP administrator can specify an exclusion—one or more IP addresses in the scope that are not handed out to DHCP clients.

Note

In networks with multiple subnets and multiple networks, it is useful to have standards for separating the dynamic IP addresses given out by DHCP from the addresses used by manually configured hosts.

DHCP options are defined in detail in RFC 2132, and key Windows DHCP options are described later in this chapter. In the DHCP protocol packet, each option begins with a single tag octet, which defines the option. An option can be fixed length, such as the NetBIOS Node Type (Option 46); variable length, such as the Domain Name System (DNS) Domain Name (Option 15); or an array of items, such as the list of DNS Servers (Option 6).

With the Windows Server 2003 DHCP Server service, the DHCP administrator can manage options at the following five levels:

• Predefined optionsAllow the DHCP administrator to specify default option values for all options supported on the DHCP server and to create new option types for use on this server.
• Server optionsValues assigned to all clients and scopes defined on the DHCP server (unless they are overridden by scope, class, or client-assigned options).
• Scope optionsValues applied only to clients of a specific scope (unless they are overridden by class or client-assigned options).
• Class optionsAllow the administrator to set user- or vendor-defined option classes, providing option data to a specified class of DHCP clients (for example, all Windows 2000 or later DHCP clients). Options set at this level are overridden only by options assigned at the client level.
• Reserved client optionsSet for an individual reserved DHCP client. Only properties manually configured at the client computer can override optionsassigned at this level.

Options Classes

A DHCP options class is an additional set of options that can be provided to a DHCP client based on the computer being a member of a class of computers. The administrator can use these to submanage option values provided to DHCP clients. There are two types of options classes supported by the Windows Server 2003 DHCP server: vendor classes and user classes.

When an administrator configures options classes on a DHCP server, a client belonging to that class (for example, all Windows 2000 computers) can be provided with class-specific option types for its configuration. To support earlier DHCP clients that are unable to support sending of the class ID, the administrator can configure default classes to provide option values. This allows the administrator to leverage options specifically provided in a particular client class, simultaneously allowing the administrator to provide all necessary options for other clients.

A DHCP client can indicate in the DHCP protocol messages it sends to a server that the client is a member of a particular user or vendor class. The administrator can use DHCP to define option values that are returned only for this client class. For example, the administrator can configure options specific to computers running Windows 2000, which can be sent option values (for example, whether or not to release a DHCP lease when shutting down). Other clients that cannot support this feature would not receive these values.

For a DHCP client to receive option values for these extended options, the client must specify a user class string option, containing a string identifying the client type. The DHCP server can then use this to identify extra options to be sent to the client. The user class option is set using the Ipconfig command at the command prompt. For example:

C:>ipconfig /setclassid 3com kapoho
Windows IP Configuration
Successfully set the class id for adapter 3com.
C:>ipconfig
Windows IP Configuration
Ethernet adapter 3com:
 Connection-specific DNS Suffix . :
 IP Address. . . . . . . . . . . . : 10.10.1.62
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 10.10.1.100
 DHCP Class ID . . . . . . . . . . : kapoho

DHCP Messages

DHCP clients communicate with DHCP servers by sending application layer messages to, and receiving messages from, a DHCP server. There are eight DHCP message types, which are sent using User Datagram Protocol (UDP). DHCP clients with a bound IP address and a valid lease communicate with the DHCP server using unicast IP datagrams, whereas clients in the process of obtaining an IP address communicate using broadcast packets, sent to the limited broadcast IP address 255.255.255.255. The DHCP client binds to UDP port 68, and the DHCP server binds to UDP port 67.

There are eight DHCP message types:

• DHCPDISCOVERSent by a DHCP client broadcast to locate a DHCP server.
• DHCPOFFERSent by a DHCP server to a DHCP client, in response to DHCPDISCOVER, along with offered configuration parameters.
• DHCPREQUESTSent by the DHCP client to DHCP servers to request parameters from one server while implicitly declining offers from other servers, and to confirm the validity of previously allocated addresses (for example, after a reboot or to extend an existing DHCP lease).
• DHCPACKSent by a DHCP server to a DHCP client to confirm an IP address and provide the client with those configuration parameters that the client has requested and the server is configured to provide.
• DHCPNAKSent by a DHCP server to a DHCP client denying the client's DHCPREQUEST. This might occur if the requested address is incorrect because of the client having moved to a new subnet or because the DHCP client's lease has expired and cannot be renewed.
• DHCPDECLINESent by a DHCP client to a DHCP server, informing the server that the offered IP address is declined because it appears to be in use by another computer.
• DHCPRELEASESent by a DHCP client to a DHCP server, relinquishing anIP address and canceling the remaining lease. This is sent to the server that provided the lease.
• DHCPINFORMSent from a DHCP client to a DHCP server, asking only for additional local configuration parameters; the client already has a configuredIP address. This message type is also used for rogue server detection.

DHCP Leases and Reservations

The IP addresses acquired by DHCP generally are not permanent. When a DHCP client is configured using DHCP, it acquires a lease on the assigned address. The DHCP administrator defines the lease duration, either when the lease is created, or subsequently. In Windows Server 2003, the administrator can specify either a specific lease time, between 1 minute and 999 days, or an unlimited lease time.

Although most IP addresses are dynamically allocated, Windows Server 2003 allows a DHCP administrator to create a reservation, a permanent address lease that the DHCP administrator creates to assign a specific IP address (and DHCP options) to a specific DHCP client. The administrator creates the reservation by specifying the IP address to be allocated and the host's media access control (MAC) address. The reservation ensures that the DHCP client with a network interface card (NIC) having that MAC address always obtains the same IP address and options.

DHCP Relay Agents

When a Windows DHCP client computer is started, it broadcasts DHCP messages to obtain or renew a lease from a DHCP server. A DHCP relay agent, also referred to as a BOOTP relay agent, is either a host or an IP router that listens for DHCP client messages being broadcast on a subnet and then forwards those DHCP messages to a configured DHCP server. The DHCP server sends DHCP response messages back to the relay agent, which then broadcasts them onto the subnet for the DHCP client. The DHCP administrator uses DHCP relay agents to centralize DHCP servers, avoiding the need for a DHCP server on each subnet.

The Routing and Remote Access service of Windows Server 2003 includes a DHCP relay agent. A DHCP administrator needs to enable the Routing and Remote Access service and configure the DHCP relay agent with interfaces and the IP addresses of DHCP servers. In addition, most modern hardware routers can be configured to provide relay facilities. On some routers, the DHCP relay function is referred to as BOOTP forwarding.

Unauthorized DHCP Server Detection

Properly configured DHCP servers provide IP configuration information for IP networks. However, when an incorrectly configured DHCP server is introduced into a network, or any DHCP server is introduced into the wrong network, problems might arise. Forexample, if a client obtains a lease from an incorrectly configured DHCP server, theclient might receive an invalid IP address, which prevents it from communicating on the network. This can prevent users from logging on. In Windows Server 2003, an unauthorized DHCP server is simply a DHCP server that has not explicitly been authorized. Unauthorized DHCP servers are also referred to as rogue DHCP servers.

In a Windows Server 2003 domain environment, the DHCP Server service on an unauthorized server fails to initialize. The administrator must explicitly authorize all Windows Server 2003 DHCP servers that operate in an Active Directory service domain environment. At initialization time, the DHCP Server service in Windows Server 2003 checks for authorization and does not start if the server detects that it is in a domain environment and the server has not been explicitly authorized.

APIPA

DHCP clients need to find a DHCP server to get an initial lease. In most cases, the DHCP client finds a server either on a local subnet or through a relay agent. To allow forthe possibility that a DHCP server is unavailable, Windows Server 2003, Windows XP,Windows 2000, and Windows 98 provide APIPA. APIPA is a facility of the Windows TCP/IP implementation that allows a computer to determine IP configuration information without a DHCP server or manual configuration.

APIPA avoids the problem of IP hosts being unable to communicate if, for some reason, the DHCP server is unavailable. APIPA is also useful for small workgroup networks whereno DHCP server is implemented. Because autoconfiguration does not support a default gateway, it works only with a single subnet and is not appropriate for larger networks.

If the DHCP client is unable to locate a DHCP server, the computer autoconfigures itself with an IP address randomly chosen from the Internet Assigned Numbers Authority (IANA)–reserved class B network 169.254.0.0, and with the subnet mask 255.255.0.0. The autoconfigured computer then tests to verify that the IP address it has chosen is not already in use, using a gratuitous Address Resolution Protocol (ARP) broadcast. If the chosenIP address is in use, the computer randomly selects another address. The computer makes up to 10 attempts to find an available IP address.

Once the selected address has been verified as available, the client is configured to use that address. The DHCP client continues to check for a DHCP server in the background every 5 minutes, and if a DHCP server is found, the configuration offered by the DHCP server is used.

Windows XP and Windows Server 2003 clients can be configured to use alternate configuration, which the DHCP client uses if a DHCP server cannot be contacted. The alternate configuration includes IP address, subnet mask, default gateway, and DNS and WINS server addresses. The alternate configuration is a solution for laptops that move between a corporate, DHCP-enabled network and a home network where static IP addressing is used.

DNS Integration

The DNS Server service, described in more detail in Chapter 17, "Domain Name System (DNS)," provides name resolution for DNS clients. Windows clients support DNS dynamic updates, which allows DHCP clients to automatically update their configured DNS servers with forward and reverse lookup information.

Routing and Remote Access Service Integration

The Windows Server 2003 Routing and Remote Access service includes a remote access server facility, which allows dial-up networking or virtual private network (VPN) clients to access a server running Routing and Remote Access and join a local network. To other computers on the local network, these clients appear to be peer clients. In this case, the remote access server acts as a gateway between the remote client and the local network. Remote access clients need IP addresses for the local network to operate. Although the remote access client can be manually configured with an appropriate IP address, this addsadministrative overhead. Alternatively, the Windows Server 2003 Routing and RemoteAccess service can be configured to obtain any required IP addresses from a DHCP server.

When a Windows Server 2003 remote access server is configured to use DHCP to obtain IP addresses, the remote access server obtains 10 IP addresses from a DHCP server when the first remote access client connects. The remote access server uses the first IP address obtained from DHCP for itself and allocates subsequent addresses to TCP/IP-based remote access clients as they connect. IP addresses that are freed when remote access clients disconnect are reused. When all 10 IP addresses are used, the remote access server obtains10 more addresses. When the Routing and Remote Access service is stopped, all IP addresses obtained through DHCP are released.

If a DHCP server is not available when the Routing and Remote Access service requests addresses, then APIPA addresses in the range from 169.254.0.1 through 169.254.255.254 are used.

Multicast Scopes

In addition to providing leases to unicast IP addresses, the Windows Server 2003 DHCP Server service supports multicast scopes. A multicast scope is a set of addresses in the class D range (224.0.0.0–239.255.255.255) for use by multicast applications. This feature allows the DHCP administrator to control the specific multicast addresses in use by multicast applications. Applications must be specifically written to DHCP to obtain leases for multicast IP addresses.

BOOTP Support

DHCP is based on BOOTP, an older protocol with similar functionality. BOOTP is an established protocol standard used for configuring IP hosts. BOOTP was originally designed to enable boot configuration for diskless workstations. Modern DHCP servers respond to both BOOTP requests and DHCP requests.

BOOTP clients initialize themselves in two distinct steps, as follows:

1. The BOOTP client requests an IP address and other configuration information, such as a default gateway address, a DNS server IP address, and the like, from a BOOTP server. This information includes the boot image filename and the server name where an IP address should be obtained.
2. The BOOTP client then contacts the server and downloads the boot image file using the Trivial File Transfer Protocol (TFTP).

Although DHCP has superseded BOOTP, the DHCP server in Windows Server 2003 provides support for BOOTP clients. The administrator can define a scope for use only by BOOTP clients. Alternatively, the administrator can define a scope to be used for both BOOTP and DHCP clients.

How DHCP Works

Hosts use the DHCP protocol to obtain an initial lease, to renew an existing lease, and to detect unauthorized DHCP servers.

Obtaining an Initial Lease

A DHCP client acquires an initial lease the first time the client boots up using a series of messages exchanged with a DHCP server. This is illustrated in Figure 16-1.

Figure 16-1: DHCP messages exchanged during initial lease acquisition.

The following Network Monitor trace (Capture 16-01, included in the Captures folder on the companion CD-ROM) provides an example of this process:

1 4.426365 KAPOHO10 *BROADCAST DHCP Discover (xid=43474883) 0.0.0.0 
255.255.255.255 IP
2 4.426365 LOCAL *BROADCAST DHCP Offer (xid=43474883) TALLGUY
255.255.255.255 IP
3 4.426365 KAPOHO10 *BROADCAST DHCP Request (xid=43474883) 0.0.0.0 
255.255.255.255 IP
4 4.436379 LOCAL *BROADCAST DHCP ACK (xid=43474883) TALLGUY 
255.255.255.255 IP

In this trace, the DHCP client broadcasts a DHCPDISCOVER message to find a DHCP server. Because the host does not have an IP address, it communicates with the DHCP server by means of a local area broadcast. On receipt of a DHCPDISCOVER message, a DHCP server responds with an offer of an IP lease by sending a DHCPOFFER message. If there is more than one DHCP server able to provide the DHCP client with a lease, the DHCP client could receive more than one DHCPOFFER response. If this occurs, the client chooses the "best" offer, which for Windows DHCP clients is the first offer received. To help other clients determine the best offer, the DHCPOFFER message contains values for options that the client has requested and that are configured on the offering DHCP server.

Any DHCP server that receives a DHCPREQUEST message and can assign the DHCP client a lease issues a DHCPOFFER message. This message contains an offered IP address and values for any option that the DHCP server has been configured to issue. If the client can accept an offered lease, it sends a DHCPREQUEST message to the offering DHCP server, requesting the offered IP address. This request also contains all the configuration options that the DHCP client wishes to obtain.

If it is still willing to offer the lease, the DHCP server sends a DHCPACK message to the DHCP client, confirming that the DHCP client now has the lease on the IP address. The DHCPACK also provides values for the requested options that were specified by the DHCP administrator on the server issuing the DHCPACK.

Renewing a Lease

Because the IP lease has a finite lifetime, the client must renew the lease at some point after obtaining it. As Figure 16-2 illustrates, Windows DHCP clients attempt to renew the lease, either at each reboot or at regular intervals after the DHCP client has initialized.

Figure 16-2: DHCP messages exchanged during lease renewal.

The following Network Monitor trace (Capture 16-02, included in the Captures folder on the companion CD-ROM) demonstrates the renewal of a lease:

1 81.757561 KAPOHO10 *BROADCAST DHCP Request (xid=492D15B9) 0.0.0.0
255.255.255.255 IP
2 81.767576 LOCA *BROADCAST DHCP ACK (xid=492D15B9) TALLGUY
255.255.255.255 IP

As shown in the Network Monitor trace, a lease renewal involves just two DHCP messages—DHCPREQUEST and DHCPACK. If a Windows DHCP client renews a lease while booting up, broadcast IP packets are used to send these messages, as shown in Capture 16-2. If the lease renewal is made while the Windows DHCP client is running, the DHCP client and the DHCP server communicate using unicast messages.

When a client obtains a lease, DHCP provides values for the configuration options that were requested by the DHCP client and are configured on the DHCP server. By reducing the lease time, the DHCP administrator can force clients to regularly renew leases and obtain updated configuration details. This can be useful when the administrator wishes to change a scope's IP configuration or configuration options.

A DHCP client first attempts to reacquire its lease at half the lease time, known as T1. The DHCP client obtains the value of T1 from the DHCPACK messages that confirmed the IP lease. If the lease reacquisition fails, the DHCP client attempts a further lease renewal at 87.5 percent of the lease time, known as T2. Like T1, T2 is specified in the DHCPACK message. If the lease is not reacquired before it expires (if, for example, the DHCP server is unreachable for an extended period of time), as soon as the lease expires, the client immediately unbinds the IP address and attempts to acquire a new lease.

Changing Subnets and DHCP Servers

If the DHCP client requests a lease through a DHCPREQUEST message that the DHCP server cannot fulfill (for example, when a laptop is moved to a different subnet), the DHCP server sends a DHCPNAK message to the client. This informs the client that the requested IP lease will not be renewed. The client then acquires a new lease using the lease acquisition process described earlier. Figure 16-3 illustrates this sequence of DHCP messages.

Figure 16-3: DHCP messages exchanged when DHCP client boots in a new subnet.

The following Network Monitor trace (Capture 16-03, included in the Captures folder on the companion CD-ROM) demonstrates a client that has moved subnets and as a result needs to acquire a different IP lease:

1 68.198064 KAPOHO10 *BROADCAST DHCP Request (xid=2DBB2B8B)
0.0.0.0 255.255.255.255 IP
2 68.198064 LOCAL *BROADCAST DHCP NACK (xid=2DBB2B8B)
TALLGUY 255.255.255.255 IP
3 69.419821 KAPOHO10 *BROADCAST DHCP Discover (xid=749C146A)
0.0.0.0 255.255.255.255 IP
4 69.419821 LOCAL *BROADCAST DHCP Offer (xid=749C146A)
TALLGUY 255.255.255.255 IP
5 69.429836 KAPOHO10 *BROADCAST DHCP Request (xid=749C146A)
0.0.0.0 255.255.255.255 IP
6 69.429836 LOCAL *BROADCAST DHCP ACK (xid=749C146A)
TALLGUY 255.255.255.255 IP

When a Windows DHCP client boots up, it broadcasts a DHCPREQUEST message to renew its lease. This ensures that the DHCP renewal request is sent to the DHCP server that provides DHCP addresses for the subnet the client is currently on. This could be different from the server that provided the initial lease. When the DHCP server receives the broadcast, it compares the address the DHCP client is requesting with the scopes configured on the server and the subnet the DHCPREQUEST message was received from. If it is not possible to satisfy the client request, the DHCP server issues a DHCPNAK, and the DHCP client then acquires a new lease.

If the DHCP client is unable to locate any DHCP server when rebooting, to renew its lease, it issues an ARP broadcast for the default gateway that was previously obtained, if one was provided. If the IP address of the gateway is successfully resolved, the DHCP client assumes that it remains located on the same network where it obtained its current lease and continues to use this lease.

If the ARP broadcast that the client sent for the default gateway receives no response, the client assumes that it has been moved to a network that has no DHCP services currently available (such as a home network), and it autoconfigures itself using either APIPA or alternate configuration. Once it autoconfigures itself, the DHCP client tries to locate a DHCP server every 5 minutes.

Using the DHCP Relay Agent

The DHCP relay agent is configured with the address of a DHCP server. The DHCP relay agents listen for DHCPDISCOVER and DHCPREQUEST (and DHCPINFORM) messages that are broadcast. The DHCP relay agent then waits a configured amount of time and, if no response is detected, sends the message to the configured DHCP server using unicast. The server then acts on the message and sends the reply back to the DHCP relay agent. The relay agent then broadcasts the message on the local subnet, allowing the DHCP client to receive it.

Detecting Unauthorized DHCP Servers

As part of the initialization of the DHCP Server service, all DHCP servers perform rogue server detection. As Figure 16-4 illustrates, if the server is not authorized in Active Directory, it shuts down. This process can be seen in the Network Monitor trace in Capture 16-04 (included in the Captures folder on the companion CD-ROM), which contains a trace of an unauthorized server performing successful rogue server detection.

Figure 16-4: A DHCP server performing rogue server detection.

Rogue server detection begins with the initializing DHCP server issuing DHCPINFORM queries to determine if there are other initialized DHCP servers on any attached network. If so, these servers respond with a DHCPACK message that contains the name of the domain in which they have been authorized. If other DHCP servers are found, as can be seen in the Network Monitor trace in Capture 16-4, a Windows Server 2003 DHCP Server service that is starting binds to Active Directory and issues a series of Lightweight Directory Access Protocol (LDAP) calls to discover whether or not it is authorized. If the server is not authorized, the service terminates. The DHCP server carries out this detection once per hour to detect newly deauthorized servers.

If DHCP event logging is enabled, a message is written to the DHCP event log. The event log message to accompany Capture 16-4 is as follows:

00,05/17/99,18:34:08,Started,,,
61,05/17/99,18:34:08,Server found that belongs to DS 
domain,10.10.1.200,kapoho.com,
01,05/17/99,18:34:08,Stopped,,, 

In this example, the DHCP Server service started up and performed the unauthorized DHCP server detection. This authorization failed and the DHCP Server service, therefore, was stopped. Any attempts to restart the DHCP Server service would be unsuccessful until the DHCP server was authorized.

Updating DNS Entries

When a DHCP lease is granted to an IP host, it is important for the host name and IP address mapping to be provided to the DNS. Traditionally, this was a manual task that involved creating the DNS forward and reverse lookup entries.

More Info

Windows 2000, Windows XP, and Windows Server 2003 implementthe DNS Dynamic update protocol described in RFC 2136. This protocol enables Windows clients to automatically update DNS entries on the DNS server. This RFC can be found in the Rfc folder on the companion CD-ROM.

Each time a DHCP client receives a new lease or renews an existing lease, the client sends its fully qualified name to the DHCP server as part of the DHCPREQUEST message. The DHCPREQUEST message requests the DHCP server to register a reverse lookup address mapping in the DNS server on behalf of the client. The DHCP client usually handles the forward lookup registration on its own, if it is capable.

The DHCP administrator can configure the DHCP server to send DNS updates for both the forward and reverse lookup address mappings to the DNS server. This is useful for down-level DHCP clients that do not support DNS dynamic updates.

The Network Monitor trace in Capture 16-05 (included in the Captures folder on the companion CD-ROM) illustrates a DHCP server registering both the forward and reverse lookup mappings for a new address lease. In the trace, the DHCP server queries for the DNS Start of Authority (SOA) record for the forward lookup zone, then updates the forward lookup entry for the DHCP client. The DHCP server then queries the DNS server for the reverse lookup zone and performs the update of the DHCP client's reverse lookup entry.

For the dynamic updates to be successful, the DNS server must support DNS dynamic updates and have the forward and reverse lookup zones configured to allow dynamic updates. The Windows Server 2003 DNS service supports DNS dynamic updates, but the default for new zones does not allow dynamic updates. If, for some reason, the dynamic updating of a zone is not configured when the DHCP server attempts to update the DNS entry, the server receives an error from the DNS server. This can be seen in the Network Monitor trace in Capture 16-06 (included in the Captures folder on the companion CD-ROM), where the reverse lookup zone is configured to not allow dynamic updates. In this case, the DHCP server sends the update to the DNS service, but receives an error in return.

DHCP Messages

The format of DHCP messages is based on the message format used with the BOOTP protocol, as described in this section. The descriptions of the DHCP messages refer to DHCP options, which are described in more detail in the "DHCP Options" section of this chapter.

General Message Format

RFC 2131 defines the format of the messages sent between a DHCP client and a DHCP server. The basic message format is illustrated in Figure 16-5.

Figure 16-5: DHCP message format.

Table 16-1 displays the individual fields in the DHCP message and a short description of each.

Table 16-1: DHCP Message Fields and Descriptions

Field	Description
Message Type (Op)	Message type.
Hardware Address Type (Htype)	Hardware address type, as defined at: http://www.iana.org/assignments/arp-parameters (for example, "0x1" means 10 MB Ethernet).
Hardware Address Length (Hlen)	Hardware address length, in octets (for example, "0x6" for 10 MB Ethernet).
Hops (Hops)	DHCP client sets this to 0. The relay agent can use this optionally when the DHCP client is booting using a relay agent.
Transaction ID (Xid)	A random number used to denote a conversationbetween a DHCP client and a DHCP server (forexample, a lease acquisition).
Seconds (Secs)	Filled in by DHCP client. Number of seconds elapsed since the DHCP client commenced the address acquisition process.
Flags (Flags)	Flags set by client. In RFC 2131, the Broadcast flag is the only flag defined. A DHCP client that cannot receive unicast IP datagrams until it has been configured with an IP address sets this Broadcast flag.
Client IP Address (Ciaddr)	Filled in only if the client has an IP address and can respond to ARP requests to defend this IP address.
Your IP Address (Yiaddr)	Address given by the DHCP server to the DHCP client.
DHCP Server IP Address (Siaddr)	IP address of the DHCP server that is offering a lease (returned by DHCPOFFER).
Gateway IP Address (Giaddr)	DHCP relay agent IP address, used when booting using a DHCP relay agent.
Client Hardware Address (Chaddr)	Client hardware address.
Server Host name (Sname)	Windows Server 2003 does not use this field.
Boot File Name (File)	The name of the file containing a boot image for a BOOTP client.
Options (Options)	A variable-length set of fields containing DHCP options.

As Figure 16-5 illustrates, DHCP messages consist of a fixed part—236 octets in length—plus a variable-length section, used to hold options. As DHCP messages are transmitted using UDP, all DHCP messages must fit fully into a UDP datagram, which limits the variable-length section to the IP maximum transmission unit (MTU) minus 264 bytes (allowing for the IP header of 20 bytes and the UDP header of 8 bytes). Thus, for Ethernet, this limit is 1236 bytes.

DHCPDISCOVER

A DHCP client that wants to find a DHCP server to provide a lease sends a DHCPDISCOVER message. Using DHCP, this is the first step in obtaining an IP address. Because the DHCP client does not have a valid IP address, the DHCPDISCOVER message is transmitted using the limited-broadcast IP address 255.255.255.255 and a source IP address of 0.0.0.0.

Before transmitting the DHCPDISCOVER message, the DHCP client fills in the fields (described earlier) in the fixed-length portion of the DHCP message as follows:

• OpSet to 0x1
• Htype, HlenSet based on the type of network in use
• Hops, Secs, FlagsSet to 0
• XidClient selects a random 32-bit value as a transaction ID
• Ciaddr, Yiaddr, Siaddr, GiaddrAll set to 0
• ChaddrSet to the client MAC address of the interface acquiring a DHCP lease, and is the address used in all subsequent DHCP messages to refer to this interface on this client
• Cname, FileSet to 0

Windows 2000, Windows XP, and Windows Server 2003 DHCP clients also set a series of options in the DHCPDISCOVER message as follows:

• Magic CookieAlways set to 99.130.83.99 to indicate that vendor extensions follow.
• Client IdentifierSet to the DHCP client's hardware address.
• Host NameSet to the client's host name.
• Client ClassSet to MSFT 5.0 to indicate that this is a Windows 2000 system (or later).
• Parameter Request ListSet to indicate the parameters the DHCP client wants to obtain from the server. For Windows 2000, Windows XP, andWindows Server 2003 clients, these are as follows:
  • 0x01 (subnet mask)
  • 0x0F (DNS domain name)
  • 0x03 (default gateway)
  • 0x06 (DNS servers)
  • 0x2C (WINS server address)
  • 0x2E (NetBIOS node type)
  • 0x2F (NetBIOS Scope ID)
  • 0x2B (vendor class information)
  • 0x1F (perform router discovery)
  • 0x21 (static routes)

  Note

  The Windows 98 DHCPDISCOVER message does not send client class information and does not request vendor class information. In addition, the Windows 98 DHCPDISCOVER message sends an Option Request message forOption 57, a maximum DHCP message size that is not acted on by theWindows Server 2003 DHCP server.

The following Network Monitor trace (part of Capture 16-01, included in the Captures folder on the companion CD-ROM) shows a DHCPDISCOVER message sent from a Windows 2000 client discovering available DHCP servers:

+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x120; Proto = UDP; Len: 328
+ UDP: IP Multicast: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server
(67); Length = 308 (0x134)
 DHCP: Discover (xid=43474883)
 DHCP: Op Code (op) = 1 (0x1)
 DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
 DHCP: Hardware Address Length (hlen) = 6 (0x6)
 DHCP: Hops (hops) = 0 (0x0)
 DHCP: Transaction ID (xid) = 1128745091 (0x43474883)
 DHCP: Seconds (secs) = 0 (0x0)
 + DHCP: Flags (flags) = 0 (0x0)
 DHCP: Client IP Address (ciaddr) = 0.0.0.0
 DHCP: Your IP Address (yiaddr) = 0.0.0.0
 DHCP: Server IP Address (siaddr) = 0.0.0.0
 DHCP: Relay IP Address (giaddr) = 0.0.0.0
 DHCP: Client Ethernet Address (chaddr) = 00600801D303
 DHCP: Server Host Name (sname) = 
 DHCP: Boot File Name (file) = 
 DHCP: Magic Cookie = 99.130.83.99
 DHCP: Option Field (options)
 DHCP: DHCP Message Type = DHCP Discover
 DHCP: Unrecognized Option = 251 (0xFB)
 DHCP: Client-identifier = (Type: 1) 00 60 08 01 d3 03
 DHCP: Requested Address = 12.12.12.12
 DHCP: Host Name = KAPOHO10
 DHCP: Client Class information = (Length: 8) 4d 53 46 54 20 35 2e 30
 DHCP: Parameter Request List = (Length: 10) 01 0f 03 06 2c 2e 2f 1f 21 2b
 DHCP: End of this option field

DHCPOFFER

When a DHCP server receives a DHCPREQUEST, the server uses the Ciaddr field to identify the client requesting the DHCP lease. The server first checks its database to see if the DHCP client requesting the lease has an existing lease or a reservation for a lease. If it does not, the DHCP server then checks to see if it has a configured scope from which to allocate an IP address lease.

To determine which scope to use for address assignment, the DHCP server examines the Giaddr field in the DHCPDISCOVER message. If Giaddr is 0, the DHCP server uses the interface that the message was received on to determine the scope. If a DHCP relay agent sent the DHCPDISCOVER message to the DHCP server, the relay agent sets the Giaddr field to the relay agent's IP address. Thus, if the Giaddr field is not 0, the DHCP server uses the scope that corresponds to the subnet the DHCP relay agent resides in.

If there is no existing lease for the client, the DHCP server examines the chosen scope to find an IP address for the DHCP client. If the client had a previously assigned lease, but the lease expired, and the address is available, the DHCP server offers this address. Otherwise, the server picks an available address from the scope being used for theallocation.

If the DHCP server can offer a lease, it constructs a DHCPOFFER message with thefollowing fields set in the fixed-length portion of the DHCP message:

• OpSet to 0x2
• HtypeSet according to the network hardware in use
• XidSet to the xid in the received DHCPDISCOVER
• YiaddrSet to the IP address being offered to the DHCP client
• SiaddrSet to the IP address of the DHCP server offering the lease
• ChaddrSet to the client's hardware address as received in the DHCPDISCOVER message

The DHCP server also sets a series of options as follows:

• Magic CookieSet to 99.130.83.99
• DHCP Message TypeSet to 0x02 (DHCPOFFER)
• Subnet MaskObtained from the scope definition
• Renewal Time (T1)Set to 50 percent of the lease time, in seconds
• Rebinding Time (T2)Set to 87.5 percent of the lease time, in seconds
• IP Address Lease TimeThe duration of the lease, in seconds
• Server IdentifierThe IP address of the server offering the lease
• Domain NameIf requested in the DHCPDISCOVER message (and configured for the scope), the DNS domain name specified in the scope definition
• Domain Name ServerIf requested in the DHCPDISCOVER message (and configured for the scope), the list of DNS servers specified in the scope definition
• NetBIOS Name ServerIf requested in the DHCPDISCOVER message (and configured for the scope), the list of WINS servers specified in the scope definition
• NetBIOS Node TypeIf requested in the DHCPDISCOVER message (and configured for the scope), the NetBIOS node type specified in the scope definition

The DHCP client, having issued a DHCPDISCOVER, might receive zero, one, or more DHCPOFFER messages. If no DHCPOFFER message is received, the DHCP client retransmits the DHCPOFFER message. If the DHCP client receives no offer after three attempts, the client initiates autoconfiguration using APIPA.

A DHCPOFFER message is shown in the following Network Monitor trace (part ofCapture 16-01, included in the Captures folder on the companion CD-ROM), which details a Windows 2000 client being offered a lease on the IP address 10.10.1.51:

+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xD8B; Proto = UDP; Len: 337
+ UDP: IP Multicast: Src Port: BOOTP Server, (67); Dst Port: BOOTP Client 
(68); Length = 317 (0x13D)
 DHCP: Offer (xid=43474883)
 DHCP: Op Code (op) = 2 (0x2)
 DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
 DHCP: Hardware Address Length (hlen) = 6 (0x6)
 DHCP: Hops (hops) = 0 (0x0)
 DHCP: Transaction ID (xid) = 1128745091 (0x43474883)
 DHCP: Seconds (secs) = 0 (0x0)
 + DHCP: Flags (flags) = 0 (0x0)
 DHCP: Client IP Address (ciaddr) = 0.0.0.0
 DHCP: Your IP Address (yiaddr) = 10.10.1.51
 DHCP: Server IP Address (siaddr) = 10.10.1.100
 DHCP: Relay IP Address (giaddr) = 0.0.0.0
 DHCP: Client Ethernet Address (chaddr) = 00600801D303
 DHCP: Server Host Name (sname) = 
 DHCP: Boot File Name (file) = 
 DHCP: Magic Cookie = 99.130.83.99
 DHCP: Option Field (options)
 DHCP: DHCP Message Type = DHCP Offer
 DHCP: Subnet Mask = 255.255.255.0
 DHCP: Renewal Time Value (T1) = 4 Days, 0:00:00
 DHCP: Rebinding Time Value (T2) = 7 Days, 0:00:00
 DHCP: IP Address Lease Time = 8 Days, 0:00:00
 DHCP: Server Identifier = 10.10.1.100
 DHCP: Domain Name = kapoho.com
 DHCP: Router = 10.10.1.100
 DHCP: Domain Name Server = 10.10.1.200 10.10.2.200

DHCPREQUEST

A DHCP client sends the DHCPREQUEST to a DHCP server, either as part of an initial lease acquisition (that is, responding to a DHCPOFFER) or as part of a subsequent lease renewal. A DHCP client can use it to confirm its previously allocated IP address and associated configuration parameters as well.

Based either on the information in a DHCPOFFER message or on the currently configured DHCP properties, the Windows client constructs a DHCPREQUEST message with the following fields set in the fixed-length portion of the DHCP message:

• OpSet to 0x1.
• Htype, HlenSet according to the network hardware in use
• XidSet to either the xid in the original DHCPDISCOVER (for new leases) or a new transaction ID (for lease renewals and IP address confirmations)
• ChaddrSet to the client's hardware address as specified in the original DHCPDISCOVER message
• CiaddrFor new leases, this field is set to 0; for lease renewals, this is set to the IP address being renewed (or if the lease has expired, the IP address last leased by the DHCP client)

Windows DHCP clients also set a series of options in the DHCPREQUEST message as follows:

• Magic CookieAlways set to 99.130.83.99.
• DHCP Message TypeSet to 0x03 (DHCPREQUEST).
• Client IdentifierSet to the DHCP client's hardware address.
• Requested AddressThis is the address being requested. For new leases, this is the address offered in the DHCPOFFER message. If multiple offers were received, this is the address the client has chosen from the set of addresses that were offered and which the client is now requesting.
• Server IDThe client is addressing the DHCP request to this server.
• Host NameThis is the DHCP client's host name.
• DNS Dynamic UpdatesThis option, which is not defined in RFC 2131,contains the fully qualified host name that the DHCP server uses to formatDynamic DNS forward and reverse lookup updates.
• Client Class InformationSpecifies the DHCP client's vendor class. ForWindows 2000, Windows XP, and Windows Server 2003, the class-identifier string is MSFT 5.0. The DHCP server uses this to identify the client class type and to identify any vendor-specific information to be returned.
• Parameter Request ListThe list of configuration parameters that the client wishes to obtain. For Windows clients this request list contains the following options:
  • 0x01 (subnet mask)
  • 0x03 (router)
  • 0x06 (DNS server list)
  • 0x0F (domain name)
  • 0x2B (vendor-specific information)
  • 0x2C (WINS server list)
  • 0x2E (NetBIOS node type)
  • 0x2F (NetBIOS scope)

  Note

  Windows 98 DHCPREQUEST messages are similar to those sent byWindows 2000, Windows XP, and Windows Server 2003 DHCP clients. TheWindows 98 client sends Option 57 (maximum DHCP message size), although the Windows Server 2003 DHCP server does not acknowledge this. TheWindows 98 client, however, does not send the DNS Dynamic updates option or vendor class information in the Parameter Request List.

The following Network Monitor trace (part of Capture 16-01, included in theCap-tures folder on the companion CD-ROM) shows a DHCPREQUEST message with aWindows 2000 client requesting a lease on the IP address 10.10.1.51:

+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x121; Proto = UDP; Len: 365
+ UDP: IP Multicast: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server 
(67); Length = 345 (0x159)
 DHCP: Request (xid=43474883)
 DHCP: Op Code (op) = 1 (0x1)
 DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
 DHCP: Hardware Address Length (hlen) = 6 (0x6)
 DHCP: Hops (hops) = 0 (0x0)
 DHCP: Transaction ID (xid) = 1128745091 (0x43474883)
 DHCP: Seconds (secs) = 0 (0x0)
 + DHCP: Flags (flags) = 0 (0x0)
 DHCP: Client IP Address (ciaddr) = 0.0.0.0
 DHCP: Your IP Address (yiaddr) = 0.0.0.0
 DHCP: Server IP Address (siaddr) = 0.0.0.0
 DHCP: Relay IP Address (giaddr) = 0.0.0.0
 DHCP: Client Ethernet Address (chaddr) = 00600801D303
 DHCP: Server Host Name (sname) = 
 DHCP: Boot File Name (file) = 
 DHCP: Magic Cookie = 99.130.83.99
 DHCP: Option Field (options)
 DHCP: DHCP Message Type = DHCP Request
 DHCP: Client-identifier = (Type: 1) 00 60 08 01 d3 03
 DHCP: Requested Address = 10.10.1.51
 DHCP: Server Identifier = 10.10.1.100
 DHCP: Host Name = KAPOHO10
 DHCP: DNS Dynamic updates = (Length: 38) 00 00 00 4b 41 50 4f 48 
4f 31 30 2e 72 65 64 6d ...
 DHCP: Client Class information = (Length: 8) 4d 53 46 54 20 35 2e 30
 DHCP: Parameter Request List = (Length: 10) 01 0f 03 06 2c 2e 2f 1f 21 2b
 DHCP: End of this option field

DHCPACK

The DHCP server sends the DHCPACK message to the DHCP client in response to the DHCPREQUEST or DHCPINFORM message. The DHCPACK message is a confirmation by the DHCP server that it has issued the DHCP client with a lease on an IP address and provides values for any required options (as specified in the Parameter Request List of the DHCPREQUEST message).

The Windows Server 2003 DHCP server constructs a DHCPACK message with thefollowing fields set in the fixed-length portion of the DHCP message:

• OpSet to 0x2.
• Htype, HlenSet according to the network hardware in use.
• XidSet to either the xid in the original DHCPDISCOVER (for new leases) or a new transaction ID (for lease renewals and IP address confirmations).
• YiaddrSet to the client's IP address. The DHCP server issues this address to the client.
• ChaddrSet to the client's hardware address as specified in the original DHCPDISCOVER message.

The Windows Server 2003 DHCP server also sets a series of options in the DHCPREQUEST message as follows:

• Magic CookieAlways set to 99.130.83.99
• DHCP Message TypeSet to 0x05 (DHCPACK)
• Renewal Time (T1)Set to 50 percent of the lease time, in seconds
• Rebinding Time (T2)Set to 87.5 percent of the lease time, in seconds
• IP Address Lease TimeThe duration of the lease, in seconds
• Server IDThe client is addressing the DHCP request to this server
• Subnet MaskThe client's subnet mask
• DNS Dynamic UpdatesSent in response to the DNS Dynamic updates in the DHCPREQUEST message

In addition, the DHCP server sends all option values for any of the options requested in the DHCPREQUEST message. The following Network Monitor trace (part of Capture 16-01, included in the Captures folder on the companion CD-ROM) shows a Windows 2000 DHCP server confirming a lease on IP address 10.10.1.51 to a Windows 2000 client:

+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xD90; Proto = UDP; Len: 342
+ UDP: IP Multicast: Src Port: BOOTP Server, (67); Dst Port: BOOTP Client 
(68); Length = 322 (0x142)
 DHCP: ACK (xid=43474883)
 DHCP: Op Code (op) = 2 (0x2)
 DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
 DHCP: Hardware Address Length (hlen) = 6 (0x6)
 DHCP: Hops (hops) = 0 (0x0)
 DHCP: Transaction ID (xid) = 1128745091 (0x43474883)
 DHCP: Seconds (secs) = 0 (0x0)
 + DHCP: Flags (flags) = 0 (0x0)
 DHCP: Client IP Address (ciaddr) = 0.0.0.0
 DHCP: Your IP Address (yiaddr) = 10.10.1.51
 DHCP: Server IP Address (siaddr) = 0.0.0.0
 DHCP: Relay IP Address (giaddr) = 0.0.0.0
 DHCP: Client Ethernet Address (chaddr) = 00600801D303
 DHCP: Server Host Name (sname) = 
 DHCP: Boot File Name (file) = 
 DHCP: Magic Cookie = 99.130.83.99
 DHCP: Option Field (options)
 DHCP: DHCP Message Type = DHCP ACK
 DHCP: Renewal Time Value (T1) = 4 Days, 0:00:00
 DHCP: Rebinding Time Value (T2) = 7 Days, 0:00:00
 DHCP: IP Address Lease Time = 8 Days, 0:00:00
 DHCP: Server Identifier = 10.10.1.100
 DHCP: Subnet Mask = 255.255.255.0
 DHCP: DNS Dynamic updates = (Length: 3) 03 ff ff
 DHCP: Domain Name = kapoho.com
 DHCP: Router = 10.10.1.100
 DHCP: Domain Name Server = 10.10.1.200 10.10.2.200

DHCPDECLINE

When a DHCP client receives an IP address from a DHCP server, the client must determine whether the IP address is in use. The Windows 2000 and Windows Server 2003 DHCP servers can be configured to check that the address is in use before issuing the address. However, Windows clients also perform this check after receiving a DHCPACK. The client performs the check by issuing an ARP broadcast for the address.

If the DHCP client receives an ARP reply indicating that the address is in use, the client broadcasts a DHCPDECLINE to the DHCP server and unbinds the address. The Windows Server 2003 DHCP server marks the address as "bad" in the DHCP database. The client is then free to acquire a lease for another IP address.

The Network Monitor trace in Capture 16-07 (included in the Captures folder on the companion CD-ROM) contains a trace of a Windows XP system acquiring a lease. In the trace, the DHCP server offers and acknowledges an IP address against which the DHCP client performs a gratuitous ARP. Because the address is in use, the ARP finds a host using the address, and the DHCP client broadcasts the DHCPDECLINE. This allows the DHCP server to mark the address as "bad_address" in the DHCP database. The DHCP client also writes an Event Log Warning message to the DHCP client's event log, as well as to the event log of the client currently holding the disputed IP address (if that client is a computer running Windows Server 2003).

The Windows DHCP client constructs a DHCPDECLINE message with the following fields set in the fixed-length portion of the DHCP message:

• OpSet to 0x1
• Htype, HlenSet according to the network hardware in use
• XidSet to the xid in the original DHCPDISCOVER or DHCPREQUEST
• CiaddrSet to the IP address that is in dispute (that is, the one the client was issued but has determined is already in use)
• ChaddrSet to the client's hardware address as specified in the original in the DHCPDISCOVER message

The Windows DHCP client also sets a series of options in the DHCPDECLINE message as follows:

• Magic CookieAlways set to 99.130.83.99
• DHCP Message TypeSet to 0x04 (DHCPDECLINE)
• Client IdentifierThe MAC address of the client issuing the DHCPDECLINE message
• Requested AddressThe disputed IP address
• Server IDThe IP address of the server that issued the client with the disputed address

The following trace (part of Capture 16-07, included in the Captures folder on the companion CD-ROM) shows the DHCPDECLINE message in detail:

+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xC58; Proto = UDP; Len: 328
+ UDP: IP Multicast: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server 
(67); Length = 308 (0x134)
 DHCP: Decline (xid=3D136017)
 DHCP: Op Code (op) = 1 (0x1)
 DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
 DHCP: Hardware Address Length (hlen) = 6 (0x6)
 DHCP: Hops (hops) = 0 (0x0)
 DHCP: Transaction ID (xid) = 1024679959 (0x3D136017)
 DHCP: Seconds (secs) = 0 (0x0)
 + DHCP: Flags (flags) = 0 (0x0)
 DHCP: Client IP Address (ciaddr) = 10.10.1.50
 DHCP: Your IP Address (yiaddr) = 0.0.0.0
 DHCP: Server IP Address (siaddr) = 0.0.0.0
 DHCP: Relay IP Address (giaddr) = 0.0.0.0
 DHCP: Client Ethernet Address (chaddr) = 00600801D303
 DHCP: Server Host Name (sname) = 
 DHCP: Boot File Name (file) = 
 DHCP: Magic Cookie = 99.130.83.99
 DHCP: Option Field (options)
 DHCP: DHCP Message Type = DHCP Decline
 DHCP: Client-identifier = (Type: 1) 00 60 08 01 d3 03
 DHCP: Requested Address = 10.10.1.50
 DHCP: Option MUST NOT be Present
 DHCP: Server Identifier = 10.10.1.100
 DHCP: End of this option field

DHCPNAK

The DHCP server uses DHCPNAK messages to tell a DHCP client that an address it is requesting cannot be provided. This can occur when a client that has a lease is offline or, for administrative reasons, the DHCP administrator cancels the lease. In that case, the DHCP server could reallocate the address to another client. This can also occur on clients that move between different subnets.

If the requested address comes from a scope that does not match the scope of the value in the Giaddr field or the scope of the interface on which it was received (if the Giaddr field is 0), the DHCP server determines that the DHCP client has moved to a different subnet.

After receiving a DHCPNAK message, Windows DHCP clients immediately release the IP address and attempt to acquire a new IP address.

The following Network Monitor trace (part of Capture 16-03, included in the Captures folder on the companion CD-ROM) illustrates the DHCPNAK. The trace shows a DHCPREQUEST for an address, followed by a DHCPNAK indicating that it is not available:

+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xAE; Proto = UDP; Len: 353
+ UDP: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server (67); Length = 333 
(0x14D)
 DHCP: Request (xid=199F7780)
 DHCP: Op Code (op) = 1 (0x1)
 DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
 DHCP: Hardware Address Length (hlen) = 6 (0x6)
 DHCP: Hops (hops) = 0 (0x0)
 DHCP: Transaction ID (xid) = 429881216 (0x199F7780)
 DHCP: Seconds (secs) = 0 (0x0)
 + DHCP: Flags (flags) = 0 (0x0)
 DHCP: Client IP Address (ciaddr) = 10.10.1.50
 DHCP: Your IP Address (yiaddr) = 0.0.0.0
 DHCP: Server IP Address (siaddr) = 0.0.0.0
 DHCP: Relay IP Address (giaddr) = 0.0.0.0
 DHCP: Client Ethernet Address (chaddr) = 00600801D303
 DHCP: Server Host Name (sname) = 
 DHCP: Boot File Name (file) = 
 DHCP: Magic Cookie = 99.130.83.99
 DHCP: Option Field (options)
 DHCP: DHCP Message Type = DHCP Request
 DHCP: Client-identifier = (Type: 1) 00 60 08 01 d3 03
 DHCP: Host Name = KAPOHO10
 DHCP: DNS Dynamic updates = (Length: 38) 00 00 00 4b 41 50 4f 48
 4f 31 30 2e 72 65 64 6d ...
 DHCP: Client Class information = (Length: 8) 4d 53 46 54 20 35 2e 30
 DHCP: Parameter Request List = (Length: 10) 01 0f 03 06 2c 2e 2f 1f 21 2b
 DHCP: End of this option field
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xCBEA; Proto = UDP; Len: 328
+ UDP: Src Port: BOOTP Server, (67); Dst Port: BOOTP Client (68); Length = 308 
(0x134)
 DHCP: NACK (xid=199F7780)
 DHCP: Op Code (op) = 2 (0x2)
 DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
 DHCP: Hardware Address Length (hlen) = 6 (0x6)
 DHCP: Hops (hops) = 0 (0x0)
 DHCP: Transaction ID (xid) = 429881216 (0x199F7780)
 DHCP: Seconds (secs) = 0 (0x0)
 + DHCP: Flags (flags) = 128 (0x80)
 DHCP: Client IP Address (ciaddr) = 0.0.0.0
 DHCP: Your IP Address (yiaddr) = 0.0.0.0
 DHCP: Server IP Address (siaddr) = 0.0.0.0
 DHCP: Relay IP Address (giaddr) = 0.0.0.0
 DHCP: Client Ethernet Address (chaddr) = 00600801D303
 DHCP: Server Host Name (sname) = 
 DHCP: Boot File Name (file) = 
 DHCP: Magic Cookie = 99.130.83.99
 DHCP: Option Field (options)
 DHCP: DHCP Message Type = DHCP NACK
 DHCP: Server Identifier = 10.10.1.100

DHCPRELEASE

The DHCP client sends this message to the DHCP server releasing the IP address and canceling the lease. The released IP address can then be reused for other DHCP clients. The Windows Server 2003 DHCP server does not acknowledge the DHCPRELEASE. The DHCPRELEASE message is unicast from the DHCP client to the DHCP server that originally issued the lease that the client is releasing.

The Windows DHCP client constructs a DHCPRELEASE message with the following fields set in the fixed-length portion of the DHCP message:

• OpSet to 0x1
• Htype, HlenSet according to the network hardware in use
• XidSet to a new transaction ID
• CiaddrSet to the client's IP address that's being released
• ChaddrSet to the client's hardware address as specified in the original DHCPDISCOVER message

The Windows DHCP client also sets a series of options in the DHCPRELEASE message as follows:

• Magic CookieAlways set to 99.130.83.99
• DHCP Message TypeSet to 0x07 (DHCPRELEASE)
• Server IdentifierThe server that originally issued the lease
• Client IdentifierThe DHCP client's MAC address

The following Network Monitor trace (Capture 16-08, included in the Captures folder on the companion CD-ROM) shows a DHCPRELEASE message sent from a Windows 2000 computer, releasing the IP address 10.10.1.61:

+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xFA; Proto = UDP; Len: 328
+ UDP: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server (67); Length = 308 
(0x134)
 DHCP: Release (xid=771D3A02)
 DHCP: Op Code (op) = 1 (0x1)
 DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
 DHCP: Hardware Address Length (hlen) = 6 (0x6)
 DHCP: Hops (hops) = 0 (0x0)
 DHCP: Transaction ID (xid) = 1998404098 (0x771D3A02)
 DHCP: Seconds (secs) = 0 (0x0)
 + DHCP: Flags (flags) = 128 (0x80)
 DHCP: Client IP Address (ciaddr) = 10.10.1.61
 DHCP: Your IP Address (yiaddr) = 0.0.0.0
 DHCP: Server IP Address (siaddr) = 0.0.0.0
 DHCP: Relay IP Address (giaddr) = 0.0.0.0
 DHCP: Client Ethernet Address (chaddr) = 00600801D303
 DHCP: Server Host Name (sname) = 
 DHCP: Boot File Name (file) = 
 DHCP: Magic Cookie = 99.130.83.99
 DHCP: Option Field (options)
 DHCP: DHCP Message Type = DHCP Release
 DHCP: Server Identifier = 10.10.1.100
 DHCP: Client-identifier = (Type: 1) 00 60 08 01 d3 03
 DHCP: End of this option field

DHCPINFORM

RFC 2131 defines the DHCPINFORM DHCP message type. DHCP clients can use the DHCPINFORM message to request additional configuration information, regardless of how the DHCP clients were originally configured. Thus, a DHCP client, configured with a static IP address, could use the DHCPINFORM messages to request additional local configuration parameters from a DHCP server. Windows Server 2003 remote access clients also use DHCPINFORM to automatically obtain a DNS domain name, after the Point-to-Point Protocol (PPP) connection is configured.

In Windows 2000 and later, the key use of the DHCPINFORM message is to enable a Windows DHCP server to discover the name of the Directory Services (DS) enterprise root on which each server is installed. This is performed as part of rogue DHCP serverdetection. This information is requested within the DHCPINFORM message by including information in the message's vendor-specific options area. When other DHCP servers running the Windows Server 2003 DHCP Server service receive the DHCPINFORM message, they process, acknowledge, and respond with the requested information about the DS enterprise root.

The server running Windows Server 2003 constructs a DHCPINFORM message with the following fields set in the fixed-length portion of the DHCP message:

• OpSet to 0x1
• Htype, HlenSet according to the network hardware in use
• XidThe DHCP server generates a new transaction ID
• CiaddrSet to the DHCP server's IP address

The Windows Server 2003 DHCP server also sets a series of options in the DHCPINFORM message as follows:

• Magic CookieAlways set to 99.130.83.99
• DHCP Message TypeSet to 0x08 (DHCPINFORM)
• Vendor-Specific InformationFor unauthorized server detection, this field is set to 0x5E

DHCP Options

The Windows Server 2003 DHCP Server service provides leases on IP addresses to DHCP clients. The lease includes an IP address, subnet mask, and values for specific options as requested by the DHCP client. This section defines the options that Windows Server 2003 DHCP servers support and that Windows clients can request.

What Are DHCP Options?

A DHCP option is an IP configuration parameter that a DHCP server can send to a DHCP client. These can be standard options, used in all DHCP messages or all messages of a particular type, such as the Magic Cookie option, or DHCP message types. Additionally, DHCP options can contain configuration parameters that are explicitly requested by DHCP clients, such as the default gateway IP address.

The Windows Server 2003 DHCP server supports the standard option types, defined in RFC 2132. Moreover, Windows Server 2003 supports additional vendor-specific options that the administrator can use to provide Windows 2000 and later DHCP clients with additional information.

More Info

Standard option types are defined in RFC 2131, which can be found in the Rfc folder on the companion CD-ROM.

Option Formats

As defined by RFCs 2131 and 2132, options can be of either fixed length or variable length, and might or might not have associated data. As shown in Figure 16-6, all options begin with an octet holding the option code to identify it. Fixed-length options without data consist of only a single tag octet. The only fixed-length options without data are Option 0 (Pad) and Option 255 (End). All other options are of variable length and have a length octet following the tag octet. The length octet value excludes the two octets that specify the tag and length. The length value indicates the number of octets that the option contains. Some variable-length options have a fixed-length field but a length option is still specified.

Figure 16-6: DHCP option format.

The vendor option class is formatted slightly differently in that there is a single option (vendor-specific information) that consists of a list of suboptions.

Options Supported by Windows Server 2003

The Windows Server 2003 DHCP Server service supports all options specified in RFC 2132. However, most of the defined options are no longer in use or are not used by Windows or MS-DOS DHCP clients. For the full list of options that Windows Server 2003 DHCP Server service supports, refer to Windows Server 2003 Help. The options that the Windows Server 2003 DHCP Server service supports fall into the following three categories:

• Options that are present in all messages (or all occurrences of a specific message type)
• Standard options that clients can request and that the DHCP server provides, if the administrator at the DHCP server has defined the option value
• Vendor options that are returned based on the client class

Options Present in All DHCP Messages

Table 16-2 displays the DHCP options that can appear in all DHCP messages (or in all occurrences of a particular DHCP message).

Table 16-2: DHCP Options Appearing in All DHCP Messages

Option Name	Option Code (Decimal)	Option Length	Option Description
Pad	0	1 octet	Used to cause subsequent fields to align. Can be used in any DHCP message.
Subnet Mask	1	4 octets	Used in conjunction with an offered IP address. Used in DHCPOFFER and DHCPACK messages.
Host Name	12	Variable length; minimum length is 1 octet	Specifies the name of the client. Used in DHCPDISCOVER, DHCPREQUEST, and DHCPNAK messages.
Vendor- Specific information.	43	Variable length	Used by clients and servers to exchange The vendor-specific definition ofInformation this information is vendor-specific and is not defined in RFC 2132. Used in DHCPINFORM messages.
Requested	50	4 octets	The DHCP client is requesting (or declining)Address this address. This is used in DHCPREQUEST and DHCPDECLINE messages.
Lease Time	51	4 octets	The length of the lease in seconds. This is present in only DHCPOFFER and DHCPACK messages.
DHCP Message type	53	1 octet	Used to define the DHCP. Message The values are as follows:Type Used in all DHCP messages. 0x01DHCPDISCOVER 0x02DHCPOFFER 0x03DHCPREQUEST 0x04DHCPDECLINE 0x05DHCPACK 0x06DHCPNAK 0x07DHCPRELEASE 0x08DHCPINFORM Used in all DHCP messages.
Server Identifier	54	4 octets	The DHCP server's IP address. This is used in DHCPREQUEST, DHCPACK, DHCPDECLINE, and DHCPRELEASE messages.
Parameter Request List	55	Variable length; but for Windows clients, this is8 octets in length	Used by a DHCP client to request values for specific configuration parameters. Each octet is a valid DHCP option code (defined in RFC RFC 2132) for options that the DHCP client is requesting values from the DHCP server. This occurs in DHCPDISCOVER, DHCPREQUEST, and DHCPINFORM messages.
Renewal Time (T1)	58	4 octets	Length of time, in seconds, until the client enters renewal state. This is used in DHCPOFFER and DHCPACK messages
Rebinding Time (T2)	59	4 octets	Length of time, in seconds, until the client enters rebinding state. This is used in DHCPOFFER and DHCPACK messages.
Client	61	Variable length; minimum length is 2 octets; for Ethernet, the length is 6 octets	A value to identify the client uniquely. For Windows DHCP clients, this is the client's MAC address. This is used in DHCPDISCOVER DHCPREQUEST, DHCPDECLINE, DHCPNAK,, and DHCPRELEASE messages.
Dynamic DNS Update	81	Variable length	This is the fully qualified domain name of the host and the DHCP server uses it to send DNS Dynamic updates to a DNS server. This is used in DHCPREQUEST messages.
End	255	1 octet	Marks the end of the Options field in a DHCP message. This is used in all DHCP messages.

Options Requested by DHCP Clients

The options that clients can request and receive values for (assuming the administrator has specified values for them on the DHCP server) are shown in Table 16-3.

Table 16-3: Options for Which Clients Can Request and Receive Values

Option Name	Option Code (Decimal)	Option Length	Option Description
Router	3	Variable; but always a multiple of4 octets	A list of IP addresses for routers on the client's subnet, which should be listed in order of preference. Generally, there is only one router—the default gateway—but multiple gateways can be specified.
Domain	6	Variable; but always a multiple of4 octets	A list of IP addresses for DNS serversName (per RFC 1035) available to the client.Servers
DNS domain name	15	Variable-length set of ASCII characters	The DNS Domain Name that the DHCP client should use when resolving host names using DNS.
WINS Server Names	44	Variable; but always a multiple of 4	A list of WINS server IP addresses for client use. This is typically a primary and secondary server
NetBIOS Over TCP/IP Node Type	46	1 octet	Used to tell a TCP/IP client how NetBIOS names should be resolved, as follows: 0x1B-node (broadcast) 0x2P-node (point-to-point) 0x4M-node (mixed) 0x8H-node (hybrid) See Chapter 18, "Windows Internet Name Service (WINS)," for more detail on the NetBIOS Node Type
NetBIOS Scope ID	47	Variable; minimum length is 1	Specifies the NetBIOS over TCP/IP scope for the client, as specified in RFCs 1001 and 1002.

Vendor-Specific Options

In addition to the standard options already noted, the administrator can set specific options to be returned to clients of a particular class (such as Windows XP, Windows 2000, or Windows 98).

Table 16-4 shows the options that can be returned to a client running Windows 2000, Windows XP, and Windows Server 2003.

Table 16-4: Options That Can Be Returned to a Windows Client

Option Name	Option Code	Option Length	Option Descriptio
Microsoft Disable NetBIOS Option	1	4	Informs the DHCP client whether or not to disable NetBIOS
Microsoft Release On Shutdown	2	4	Informs the DHCP client whether or not to release the DHCP lease on shutdown
Microsoft Default Router Metric Base	2	4	Specifies the default router metric base

Summary

DHCP is a simple client/server protocol that makes TCP/IP network configuration much simpler for the administrator. DHCP is based on the BOOTP protocol, which explains some of the message formats. Windows Server 2003 implements the latest RFCs that define both the DHCPINFORM message type and the new Vendor and User class options. The DHCP Server service in Windows Server 2003 supports all down-level Microsoft networking clients that support DHCP.