Dynamic Host Configuration Protocol - 1
Dynamic Host Configuration Protocol - 1
DHCP Overview
DHCP is a TCP/IP standard that reduces the complexity and administrative overhead of managing
network client IPv4 addresses and other configuration parameters. A properly configured DHCP
infrastructure eliminates the configuration problems associated with manually configuring TCP/IP.
DHCP servers
Computers that offer dynamic configuration of IPv4 addresses and related configuration
parameters to DHCP clients.
DHCP clients
Network nodes that support the ability to communicate with a DHCP server to obtain a
dynamically leased IPv4 address and related configuration parameters.
Network nodes, typically routers, that listen for broadcast and unicast DHCP messages and relay
them between DHCP servers and DHCP clients. Without DHCP relay agents, you would have to
install a DHCP server on each subnet that contains DHCP clients.
Each time a DHCP client starts, it requests IPv4 addressing information from a DHCP server, including:
IPv4 address
Subnet mask
Additional configuration parameters, such as a default gateway address, Domain Name System
(DNS) server addresses, a DNS domain name, and Windows Internet Name Service (WINS)
server addresses.
When a DHCP server receives a request, it selects an available IPv4 address from a pool of addresses
defined in its database (along with other configuration parameters) and offers it to the DHCP client. If
1
2
the client accepts the offer, the IPv4 addressing information is leased to the client for a specified period
of time.
The DHCP client will typically continue to attempt to contact a DHCP server if a response to its request
for an IPv4 address configuration is not received, either because the DHCP server cannot be reached or
because no more IPv4 addresses are available in the pool to lease to the client. For DHCP clients that are
based on Microsoft® Windows® XP or Windows Server 2003™ operating systems, the DHCP Client
service uses the alternate configuration when it cannot contact a DHCP server. The alternate
configuration can be either an Automatic Private IP Addressing (APIPA) address or an alternate
configuration that has been configured manually.
Requests for Comments (RFCs) 2131 and 2132 define the operation of DHCP clients and servers. RFC
1542 defines the operation of DHCP relay agents. All DHCP messages are sent using the User Datagram
Protocol (UDP). DHCP clients listen on UDP port 67. DHCP servers listen on UDP port 68. DHCP relay
agents listen on both UDP ports.
The DHCP protocol simplifies configuration of IP clients in a network environment. Before DHCP was
used widely, each time you added a client to a network, you had to configure it with information about
the network on which you installed it, including the IP address, the network’s subnet mask, and the
default gateway for access to other networks.
When you need to manage many computers in a network, it becomes very time consuming to manage
them manually. Many corporations manage thousands of computer devices, including handhelds,
desktop computers, and laptops. It simply is not feasible to manage networks of this size manually.
With the DHCP Server role, you can ensure that all clients have the same configuration information,
which eliminates human error during configuration. When key configuration information changes in the
network, you can update it using the DHCP Server role without having to change the information directly
on each computer.
2
3
DHCP also is a key service for mobile users who change networks often. DHCP enables network
administrators to offer complex network-configuration information to nontechnical users, without users
having to deal with their network-configuration details.
DHCP uses a client-server model. The network administrator establishes one or more DHCP servers that
maintain TCP/IP configuration information and provide it to clients. The server database includes the
following:
With a DHCP server installed and configured on your network, DHCP-enabled clients can obtain their IP
address and related configuration parameters dynamically each time they start and join your network.
DHCP servers provide this configuration in the form of an address-lease offer to requesting clients.
DHCP uses the following basic process to automatically configure a DHCP client:
1. When the TCP/IP protocol initializes and has DHCP enabled on any of its interfaces, the DHCP
client sends a DHCPDiscover message to find the DHCP servers on the network and to obtain a
valid IPv4 address configuration.
2. All DHCP servers that receive the DHCPDiscover message and that have a valid IPv4 address
configuration for the client send a DHCPOffer message back to the DHCP client.
3. The DHCP client selects an IPv4 address configuration to use from the DHCPOffer messages that
it receives and sends a DHCPRequest message to all the DHCP servers, requesting the use of the
selected configuration.
3
4
The DHCPRequest message identifies the server that sent the offer that the DHCP client
selected. The other DHCP servers that receive the DHCPRequest message that sent offers place
their offered IPv4 addresses back into the available pool of addresses.
4. The selected DHCP server assigns the IPv4 address configuration to the DHCP client and sends a
DHCPAck (acknowledgment) message to the DHCP client.
The DHCP client computer finishes initializing the TCP/IP protocol on the interface. Once complete, the
client can use all TCP/IP services and applications for normal network communications and connectivity
to other IPv4 hosts.
If a computer has multiple network adapters, the DHCP process occurs separately over each network
adapter that is configured for automatic TCP/IP addressing until each network adapter in the computer
has been allocated a unique IPv4 address configuration.
The DHCP client can go through six states in the DHCP process:
Initializing
Selecting
Requesting
Bound
Renewing
4
5
Rebinding
DHCP clients and servers use the following messages to communicate during the DHCP configuration
process:
Figure 6-2 shows DHCP client states and messages, which are discussed in detail in the following
sections.
Computers running Windows XP or Windows Server 2003 use an additional DHCP message, the
DHCPInform message, to request and obtain information from a DHCP server for the following purposes:
5
6
In the Initializing state, the DHCP client is trying to initialize TCP/IP and it does not yet have an IPv4
address configuration. This state occurs the first time the TCP/IP protocol stack is initialized after being
configured for automatic configuration and when the DHCP client cannot renew the lease on an IPv4
address configuration.
When the DHCP client is in the Initializing state, its IPv4 address is 0.0.0.0, also known as the unspecified
address. The DHCP client's first task is to obtain an IPv4 address configuration by broadcasting a
DHCPDiscover message from UDP port 67 to UDP port 68. Because the DHCP client does not yet have an
IPv4 address and has not determined the IPv4 addresses of any DHCP servers, the source IPv4 address
for the DHCPDiscover broadcast is the unspecified address, 0.0.0.0, and the destination is the limited
broadcast address, 255.255.255.255. The DHCPDiscover message contains the DHCP client’s media
access control (MAC) address and computer name.
If a DHCP server is on the DHCP client's subnet, the server receives the broadcast DHCPDiscover
message. If no DHCP server on the DHCP client’s subnet (a more typical configuration), a DHCP relay
agent on the DHCP client’s subnet receives the broadcast DHCPDiscover message and relays it as a
unicast DHCPDiscover message from the DHCP relay agent to one or more DHCP servers. Before
forwarding the original DHCPDiscover message, the DHCP relay agent makes the following changes:
Increments the Hops field in the DHCP header of the DHCPDiscover message. The Hops field,
which is separate from the Time to Live (TTL) field in the IPv4 header, indicates how many DHCP
relay agents have handled this message. Typically, only one DHCP relay agent is located between
any DHCP client and any DHCP server.
If the value of the Giaddr (Gateway IP Address) field in the DHCP header of the DHCPDiscover
message is 0.0.0.0 (as set by the originating DHCP client), changes the value to the IPv4 address
of the interface on which the DHCPDiscover message was received. The Giaddr field records the
IPv4 address of an interface on the subnet of the originating DHCP client. The DHCP server uses
the value of the Giaddr field to determine the address range, known as a scope, from which to
allocate an IPv4 address to the DHCP client.
6
7
Changes the source IPv4 address of the DHCPDiscover message to an IPv4 address assigned to
the DHCP relay agent.
Changes the destination IPv4 address of the DHCPDiscover message to the unicast IPv4 address
of a DHCP server.
The DHCP relay agent sends the DHCPDiscover message as a unicast IPv4 packet rather than as an IPv4
and MAC-level broadcast. If the DHCP relay agent is configured with multiple DHCP servers, it sends
each DHCP server a copy of the DHCPDiscover message.
Figure 6-3 shows the sending of the DHCPDiscover message by a DHCP relay agent that is configured
with two DHCP servers.
In the Initializing state, the DHCP client can select from the set of IPv4 address configurations that the
DHCP servers offered. All DHCP servers that receive the DHCPDiscover message and that have a valid
IPv4 address configuration for the DHCP client respond with a DHCPOffer message from UDP port 68 to
UDP port 67. A DHCP server can receive the DHCPDiscover message either as a broadcast (because the
DHCP server is on the same subnet as the DHCP client) or as a unicast from a DHCP relay agent.
The DHCP server uses the following process to determine the scope on the DHCP server from which an
IPv4 address for the DHCP client is to be selected and included in the DHCPOffer message:
7
8
1. If the Giaddr field is set to 0.0.0.0, set the value of the Giaddr field to the IPv4 address of the
interface on which the DHCPDiscover message was received.
2. For each scope on the DHCP server, perform a bit-wise logical AND of the value in the Giaddr
field with the subnet mask of the scope. If the result matches the subnet prefix of the scope, the
DHCP server allocates an IPv4 address from that scope. To obtain the subnet prefix of the scope,
the DHCP server performs a bit-wise logical AND of the subnet mask of the scope with any
address in the scope.
If the DHCPDiscover message was received as a broadcast, the DHCP server sends the DHCPOffer
message to the DHCP client using the offered IPv4 address as the destination IPv4 address and the
client's MAC address as the destination MAC address. If the DHCPDiscover message was received as a
unicast, the DHCP server sends the DHCPOffer message to the DHCP relay agent. The DHCP relay agent
uses the Giaddr value to determine the interface to use to forward the DHCPOffer message. The DHCP
relay agent then forwards the DHCPOffer message to the client using the offered IPv4 address as the
destination IPv4 address and the client's MAC address as the destination MAC address.
Note The discussion of how the DHCP server or DHCP relay agent sends DHCP messages to the DHCP
client during the Selecting, Bound, and Rebinding states assumes that the Broadcast bit in the DHCP
header of DHCP messages that the DHCP client sends is set to 0. The Broadcast bit indicates whether the
8
9
DHCP client must receive responses to broadcast DHCPDiscover, DHCPRequest, and DHCPDecline
messages as broadcasts, rather than as unicasts. The DHCP Client service in Windows Server 2003 and
Windows XP allows unicast responses and therefore always sets the Broadcast bit to 0.
The DHCPOffer messages contain the DHCP client’s MAC address, an offered IPv4 address, appropriate
subnet mask, a server identifier (the IPv4 address of the offering DHCP server), the length of the lease,
and other configuration parameters. When a DHCP server sends a DHCPOffer message offering an IPv4
address, the DHCP server reserves the IPv4 address so that it will not be offered to another DHCP client.
The DHCP client selects the IPv4 address configuration of the first DHCPOffer message it receives. If the
DHCP client does not receive any DHCPOffer messages, it continues to retry sending DHCPDiscover
messages for up to one minute. After one minute, a DHCP client based on Windows Server 2003 or
Windows XP configures an alternate configuration, either through APIPA or an alternate configuration
that has been configured manually.
In the Requesting state, the DHCP client requests a specific IP address configuration by broadcasting a
DHCPRequest message. The client must use a broadcast because it does not yet have a confirmed IPv4
address configuration. Just as in the DHCPDiscover message, the DHCP client sends the DHCPRequest
message from UDP port 67 to UDP port 68 using the source IPv4 address of 0.0.0.0 and the destination
IPv4 address of 255.255.255.255.
If the DHCP client does not have a DHCP server on its subnet, a DHCP relay agent on its subnet receives
the broadcast DHCPRequest message and relays it as a unicast DHCPRequest message from the DHCP
relay agent to one or more DHCP servers.
The data in the DHCPRequest message varies in the following way, depending on how the requested
IPv4 address was obtained:
If the IPv4 address configuration of the DHCP client was just obtained with a
DHCPDiscover/DHCPOffer message exchange, the DHCP client includes the IPv4 address of the
server from which it received the offer in the DHCPRequest message. This server identifier
causes the specified DHCP server to respond to the request and all other DHCP servers to retract
9
10
their DHCP offers to the client. These retractions make the IPv4 addresses that the other DHCP
servers offered immediately available to the next DHCP client.
If the IPv4 address configuration of the client was previously known (for example, the computer
was restarted and is trying to renew its lease on its previous address), the DHCP client does not
include the IPv4 address of the server from which it received the IPv4 address configuration.
This condition ensures that when restarting, the DHCP client can renew its IPv4 address
configuration from any DHCP server.
In the Bound state, the DHCP client receives confirmation that DHCP server has allocated and reserved
the offered IPv4 address configuration to the DHCP client. The DHCP server that leased the requested
IPv4 address responds with either a successful acknowledgment (DHCPAck) or a negative
acknowledgment (DHCPNak). The DHCP server sends the DHCPAck message from UDP port 68 to UDP
port 67, and the message contains a lease period for the requested IPv4 address configuration as well as
any additional configuration parameters.
If the DHCPRequest message was received as a broadcast, the DHCP server sends the DHCPAck message
to the DHCP client using the offered IPv4 address as the destination IPv4 address and the client's MAC
10
11
address as the destination MAC address. If the DHCPRequest was received as a unicast, the DHCP server
sends the DHCPAck message to the DHCP relay agent. The DHCP relay agent uses the Giaddr value to
determine the interface to use to forward the DHCPAck message. The DHCP relay agent then forwards
the DHCPAck message to the DHCP client using the offered IPv4 address as the destination IPv4 address
and the DHCP client's MAC address as the destination MAC address.
When the DHCP client receives the DHCPAck message, it enters the Bound state. The DHCP client
completes the initialization of TCP/IP, which includes verifying that the IPv4 address is unique on the
subnet. If the IPv4 address is unique, the DHCP client computer can use TCP/IP to communicate. If the
IPv4 address is not unique, the DHCP client broadcasts a DHCPDecline message and returns to the
Initializing state. The DHCP server receives the DHCPDecline message either as a broadcast or as a
unicast through a DHCP relay agent. When the DHCP server receives the DHCPDecline message, it marks
the offered IPv4 address as unusable.
The client is trying to lease its previous IPv4 address and the IPv4 address is no longer available.
The IPv4 address is invalid because the client has been physically moved to a different subnet.
The DHCPNak message is forwarded to the DHCP client's subnet using the same method as the DHCPAck
message. When the DHCP client receives a DHCPNak, it returns to the Initializing state.
11
12
In the Renewing state, a DHCP client is attempting to renew the lease on its IPv4 address configuration
by communicating directly with its DHCP server. By default, DHCP clients first try to renew their lease
when 50 percent of the lease time has expired. To renew its lease, a DHCP client sends a unicast
DHCPRequest message to the DHCP server from which it obtained the lease.
The DHCP server automatically renews the lease by responding with a DHCPAck message. This DHCPAck
message contains the new lease and additional configuration parameters so that the DHCP client can
update its settings. For example, the network administrator might have updated settings on the DHCP
server since the lease was acquired or last renewed. When the DHCP client has renewed its lease, it
returns to the Bound state.
In the Rebinding state, a DHCP client is attempting to renew the lease on its IPv4 address configuration
by communicating directly with any DHCP server. When 87.5 percent of the lease time has expired and
the DHCP client has been unsuccessful in contacting its DHCP server to renew its lease, the DHCP client
attempts to contact any available DHCP server by broadcasting DHCPRequest messages. Any DHCP
server can respond with a DHCPAck message renewing the lease or a DHCPNak message denying the
continued use of the IPv4 address configuration.
12
13
If the lease expires or the DHCP client receives a DHCPNak message, it must immediately discontinue
using the IPv4 address configuration and return to the Initializing state. If the client loses its IPv4
address, communication over TCP/IP will stop until a different IPv4 address is assigned to the client. This
condition will cause network errors for any applications that attempt to communicate using the invalid
address.
The DHCP Client service in Windows XP and Windows Server 2003 uses these states when leasing an
IPv4 address configuration from a DHCP server. However, when a Windows-based DHCP client is shut
down, by default it does not release the IPv4 address configuration and return to the Initializing state. It
does not send a DHCPRelease message and, from the perspective of the DHCP server, the client is still in
the Bound state. When the Windows-based DHCP Client service is restarted, it enters the Requesting
state and attempts to lease its previously allocated IPv4 address configuration through a broadcasted
DHCPRequest message. The DHCPRequest is sent to the limited IPv4 broadcast address 255.255.255.255
and to the MAC-level broadcast address and contains the MAC address and the previously allocated IPv4
address of the DHCP client.
Figure 6-9 shows the DHCP states for a Windows-based DHCP client
13
14
When a DHCP relay agent on the subnet receives the DHCPRequest message, it makes the following
changes to the message before forwarding:
When the DHCP server receives the DHCPRequest message, it compares the subnet prefix of client's
previously allocated IPv4 address to the subnet prefix of the IPv4 address stored in the Giaddr field and
does the following:
If the two subnet prefixes are the same and the IPv4 address can be reallocated to the DHCP
client, the DHCP server sends a DHCPAck to the DHCP relay agent. When the DHCP relay agent
receives the DHCPAck, the agent re-addresses the message to the client's current IPv4 address
and MAC address.
If the two subnet prefixes are the same and the IPv4 address cannot be reallocated to the DHCP
client, the DHCP server sends a DHCPNak to the DHCP relay agent. When the DHCP relay agent
receives the DHCPNak, it sends the message to the client's current IPv4 address and MAC
address. At this point, the DHCP client goes into the Initializing state.
14
15
If the two subnet prefixes are not the same, the DHCP client has moved to a different subnet,
and the DHCP server sends a DHCPNak to the DHCP relay agent. When the DHCP relay agent
receives the DHCPNak, the agent sends the message to the client's current IPv4 address and
MAC address. At this point, the DHCP client goes into the Initializing state.
Before you install a Windows-based DHCP server, ask yourself these questions:
What IPv4 configuration options will DHCP clients obtain from a DHCP server (such as default
gateway, DNS servers, a DNS domain name, or WINS servers)?
The IPv4 configuration options determine how you should configure the DHCP server and
whether the options should be created for all clients in the entire network, clients on a specific
subnet, or individual clients.
If not, consider that non-DHCP clients have static IPv4 addresses, and you might have to exclude
those addresses from the scopes that you create on DHCP servers. If a specific DHCP client
requires a specific IPv4 address, you must reserve the address.
If so, each subnet must contain a DHCP relay agent. If a subnet does not have a DHCP relay
agent, you must install a separate DHCP server on the subnet.
To ensure fault tolerance for DHCP configuration, you should use at least two DHCP servers. You
might need additional DHCP servers for branch offices of a large organization.
15
16
DHCP allocates IP addresses on a dynamic basis, which is known as a lease. You can set the lease value
to unlimited. However, the value typically is not more than a few hours or days. The default lease time is
eight hours.
DHCP uses IP broadcasts to initiate communications. Therefore, DHCP servers are limited to
communication within their IP subnet. This means that in many networks, there is a DHCP server for
each IP subnet. If there are a large number of subnets, it may be very expensive to deploy servers for
every subnet. A single DHCP server may service collections of smaller subnets. For the DHCP server to
respond to DHCP client request, it must be able to receive DHCP requests. You can enable this by
configuring a DHCP agent.
The DHCP relay agent allows DHCP broadcast packets to be relayed into another IP subnet across a
router. You then configure the agent in the subnet that requires IP addresses. You also configure the
agent with the IP address of the DHCP server. This allows the agent to capture the client broadcasts and
forward them to the DHCP server in another subnet. You also can relay DHCP packets into other subnets
using a router that is compatible with RFC 1531.
The DHCP protocol lease-generation process includes four steps that enable a client to obtain an IP
address. Understanding how each step works will help you to troubleshoot problems when clients
cannot obtain an IP address:
1. The DHCP client broadcasts a DHCPDISCOVER packet. This is a message that is broadcast to
every computer in the subnet. The only computer that will respond is the computer that has
the DHCP server role or, if the computer is running the DHCP server agent. In the latter case,
the agent will forward the message to the DHCP server with which it is configured.
2. Any DHCP Server in the subnet will respond by broadcasting a DHCPOFFER packet. This
packet will provide the client with a potential address.
16
17
3. The client receives the DHCPOFFER packet. It may receive packets from multiple servers. If
the client receives offers from more than one server, it usually will choose the server that
made the fastest response to its DHCPDISCOVER. This typically is the DHCP server closest to
the client. The client then will broadcast a DHCPREQUEST. The DHCPREQUEST contains a
server identifier. This informs the DHCP servers that receive the broadcast which server the
client has chosen to accept the DHCPOFFER.
4. The DHCP servers receive the DHCPREQUEST. Those servers that the DHCPREQUEST
message does not accept use the message as notification that the client has declined that
server’s offer. The chosen server stores the IP address client information in the DHCP
database and responds with a DHCPACK message. If for some reason the DHCP server
cannot provide the address that was offered in the initial DHCPOFFER, the DHCP server will
send a DHCPNAK message.
DHCP allows a client computer to acquire configuration information about the network in which it is
started up. DHCP communication occurs before any authentication of the user or computer, and
because the DHCP protocol is based on IP broadcasts, an incorrectly configured DHCP server in a
network can provide invalid information to clients. To avoid this, the server must be authorized.
The DHCP Server role in Windows Server 2008 must be authorized in Active Directory before it will begin
leasing IP addresses. It is possible to have a single DHCP server providing IP addresses for subnets that
contain multiple Active Directory domains. Therefore, an Enterprise Administrator account must
authorize the DHCP server.
A stand-alone DHCP server is a computer running Windows Server 2008 that is not part of an Active
Directory domain, and that has the DHCP Server role installed and configured on it. If the stand-alone
17
18
DHCP server detects an authorized DHCP server in the domain, it will not lease IP addresses and will shut
down automatically.
Many network devices have built in DHCP server software. Many routers can act as a DHCP server, but it
is often the case that these servers do not recognize DHCP-authorized servers and may lease IP
addresses to clients.
A DHCP scope is a range of IP addresses that are available for lease. A scope typically is confined to the
IP addresses in a given subnet.
For example, a scope for the network 192.168.1.0/24 (subnet mask of 255.255.255.0), if all possible IP
addresses will be allocated, will have a range of 192.168.1.2 through 192.168.1.254. When a computer
or device in the 192.168.1.0/24 subnet requests an IP address, the scope that defined the range in this
example would allocate an address between 192.168.1.2 and 192.168.1.254.
Scope properties
You can configure scope data in the scope properties, and the following table lists the scope properties
that you can configure:
Tab Options
General Configure the IP range for the scope. If you need more IP addresses in the scope,
and there are unused addresses in the desired range, you can update the range
here.
Configure the lease duration. Depending on the needs of the scope, you may
want to increase or decrease the lease duration. If the scope is used for mobile
users who often move in and out of the office, a shorter scope may work best.
This ensures that the IP address pool remains full.
18
19
DNS Update a Domain Name System (DNS) server with the host name and the IP addresses of
the clients that lease IP addresses from the DHCP server. This enables the clients to be
accessible over the network using their host names. You can configure the DHCP server
to update and discard this information even if the client does not support this action.
Network Access Configure NAP settings.
Protection
Advanced Configure the type of dynamic IP requests that the scope will service. In most cases, the
type will be DHCP. You may need to respond to BOOTP requests. If this is the case, you
can enable it from this tab.
IPv6 scopes
You can configure the IPv6 scope options, as a separate scope, in the DHCP console’s IPv6 node. There
are several different options and an enhanced lease mechanism. Module 5, “Configuring and
Troubleshooting IPv6 TCP/IP”, details the IPv6 DHCP configuration options.
Creating scopes using the New Scope wizard or the netsh command
You can create scopes either using the Microsoft Management Consoles (MMC) for the DHCP Server role
or by using the netsh network-configuration command. This allows you to manage scopes remotely if
the DHCP server is running on a Server Core installation of Windows Server 2008. The netsh command
also is useful for scripting and automating server provisioning.
A superscope is a collection of scopes that are grouped together into an administrative whole. This
allows clients to receive an IP address from multiple logical subnets, even when they are on the same
physical subnet.
19
20
Benefits of superscopes
A superscope is useful in several situations. For example, if a scope has been depleted of addresses, and
you cannot add additional addresses from the subnet, you can add a new subnet to the DHCP server.
This scope will lease addresses to clients in the same physical network, but clients will be in a separate
network logically. This is known as multineting. It is important to configure routers to recognize the new
subnet to ensure local communications in the physical network.
A superscope also is useful when there is a need to move clients gradually into a new IP-numbering
scheme. By having both numbering schemes coexist for the original lease’s duration, you can move
clients into the new subnet transparently. When you have renewed all client leases in the new subnet,
you can retire the old one.
Multicast scopes
A multicast scope is a collection of multicast addresses from the class D IP address range of 224.0.0.0 to
239.255.255.255. These addresses are used when applications need to efficiently communicate with
numerous clients simultaneously. This is accomplished with multiples hosts that listen to traffic for the
same IP address. A multicast scope is referred to commonly as a Multicast Address Client Allocation
Protocol (MADCAP) scope. Applications that request addresses from these scopes need to support the
MADCAP application programming interface (API).
Multicast scopes allow applications to reserve a multicast IP address to deliver data or content.
DHCP servers can configure more than just an IP address. They also provide information about network
resources, such as DNS servers and the default gateway. You can apply DHCP options at the server,
scope, user, and vendor levels. An option code identifies the DHCP options, and most option codes come
from the Request for Comments (RFC) documentation found on the Internet Engineering Task Force
(IETF) website.
20
21
DHCP options can be applied at a several different levels, such as at the server and scope levels. You may
need to apply scope options to custom types of computers or specific groups of users.
You specify class-level options when you need to configure a device belonging to a particular class in a
specific way. A class is a logically defined group based on attributes of the IP-based device. This can be
based on vendor-specific data or it may be user-defined.
Vendor class. Microsoft’s DHCP server role offers special options based on the vendor class. An
example of using DHCP with a vendor class is disabling NetBIOS over TCP/IP for clients with a
vendor class matching Windows 2000 or Windows XP. Another example is configuring specific
options for a certain computer brand.
User class. You can specify user-class options when you want to set options for a certain class of
users, such as users from a particular physical location. User classes are set on the client’s
workstation using the IPconfig /setclassid command.
A DHCP reservation occurs when an IP address within a scope is set aside for use with a specific DHCP
client.
It often is desirable to provide servers and printers with a fixed IP address. This will ensure that IP
addresses in a predefined scope will not be assigned inadvertently to another device. This also ensures
that devices with reservations are guaranteed to have an IP address should a scope be depleted of
addresses. Configuring reservations enables you to centralize management of fixed IP addresses.
You can configure custom DHCP options for reservations. These settings will override all other DHCP
options that you configure at higher levels.
To configure a reservation, you must know the device’s Media Access Control (MAC) or physical address.
This address indicates to the DHCP server that the device should have a reservation. You can acquire a
21
22
network interface’s MAC address by using the ipconfig/all command. MAC addresses for network
printers and other network devices typically are printed on the device itself. Most laptop computers also
note this information on the bottom of their chassis.
The DHCP server database contains configuration data about the DHCP server and information about
client IP leases. If this information becomes corrupt or inconsistent, it can lead to network configuration
errors on clients’ computers. It also can lead to the same IP address being offered to multiple clients.
Managing DHCP database growth. The DHCP database is based on a Microsoft Jet database. Jet
databases need to be compacted on a regular basis.
Backup and restore. Information in the DHCP database is important to maintain. If the DHCP
server database becomes corrupt or gets lost, it could lead to significant IP configuration issues.
DHCP database consistency. The database needs to be accurate. If lease data in the DHCP
database does not match the client’s lease information, issues such as duplicate IP addresses
can occur on the network.
Moving the DHCP database. If the database is very large, you may need to move it to a larger
partition or a better performing volume.
Adding clients.
22
23
Adding new subnets. Adding clients, servers, and subnets can lead to changes in how the DHCP
database is used. These changes require database monitoring and may require new
maintenance actions.
The DHCP database is the data file that stores the DHCP configuration information and the lease data for
clients that have leased an IP address from the DHCP Server. By default, the DHCP database files are
stored in the %systemroot%\System32\Dhcp folder.
File Description
The DHCP server database is dynamic and updates as DHCP clients are assigned or as they release their
TCP/IP configuration parameters. Because the DHCP database is not a distributed database like the
Windows Internet Naming Service (WINS) server database, maintaining the DHCP server database is less
complex.
The DHCP database and related registry entries are backed up automatically at specific intervals (60
minutes by installation default). You can change this installation default by changing the value of
BackupInterval in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
23
24
You can back up a DHCP database manually or configure it to backup automatically. An automatic
backup is called a synchronous backup. A manual backup is called an asynchronous backup.
The DHCP database is backed up automatically every 60 minutes. The default backup path for the DHCP
back is: systemroot\System32\Dhcp\Backup. As a best practice, you can modify this path in the server
properties to point to another volume.
If you have an immediate need to create a backup, you can run the backup option in the DHCP console.
This action requires administrative-level permissions. The user also can be a member of the DHCP
administrators group.
When a synchronous or asynchronous backup occurs, the entire DHCP database is saved, including the
following:
Reservations
Leases
All options, including server options, scope options, reservation options, and class options
All registry keys and other configuration settings (for example, audit log settings and folder
location settings) set in DHCP server properties. These settings are stored in the following
registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
To back up this subkey, open Registry Editor, and save the specified key to a text file.
24
25
Restore process
If you need to restore the database, use the Restore function in the DHCP server console. You will be
prompted for the backup’s location. One you have selected the location, the DHCP service will stop and
the database will be restored. To restore the database, the user must have administrative-level
permissions or must be a member of the DHCP administrators group.
Backup security
When the DHCP database file is backed up, it should be in a protected location that only the DHCP
administrators can access. This ensures that any network information in the backup files remains
protected.
Maintaining a backup of the DHCP database protects you from data loss if the DHCP database is lost (for
example, due to hard disk failure) or becomes corrupted. There are three backup methods supported by
the DHCP Server service:
Synchronous backups that occur automatically. The default backup interval is 60 minutes.
Asynchronous (manual) backups, performed by using the Backup command on the DHCP
console. For more information about asynchronous backups, see Back up the DHCP database.
Backups using Windows Backup (ntbackup.exe) or non-Microsoft backup software. For more
information about Windows Backup, see Backup.
When a synchronous or asynchronous backup occurs, the entire DHCP database is saved, including the
following:
25
26
All registry keys and other configuration settings (for example, audit log settings and folder
location settings) set in DHCP server properties. These settings are stored in the following
registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
To back up this subkey, open Registry Editor, and save the specified key to a text file. For more
information, see Open Registry Editor and Import or Export Registry Keys.
Backup locations
The default DHCP database backup path is systemroot\System32\Dhcp\Backup. You can change the
database backup folder by selecting a different local folder during a manual backup or by changing the
backup folder location in DHCP server properties. For more information, see Set the DHCP database
backup path.
Synchronous backups are performed while the DHCP service is running. Similarly, when you
perform asynchronous (manual) backups, you do not need to stop the DHCP service unless you
are moving your database to a new server. For more information, see Move a DHCP database to
another server.
The backup folder location must be a local path.
Restoring the DHCP server database is useful in situations where the database has either become
corrupted or lost. In order to successfully restore the database, you need to back up the database on a
regular basis. By default, DHCP performs synchronous backups that occur automatically at a 60 minute
interval to the folder location systemroot\System32\Dhcp\Backup, but you can also perform manual
backups, or use backup software to copy the database to other locations. For more information, see
Backing up the DHCP database and Backup.
You can restore the DHCP database from a backup copy of the database file, Dhcp.mdb, using the
Restore command on the Action menu in the DHCP console. When you restore the DHCP database from
a backup copy of Dhcp.mdb, the following information is configured on the server:
26
27
Reconciling scopes can fix inconsistencies, such as incorrect or missing information, for client IP
addresses that the scope lease information stores.
The DHCP Server service stores scope IP address-lease information in two forms:
When reconciling scopes, the detail and summary entries are compared to find inconsistencies.
To correct and repair these inconsistencies, you must reconcile any scope inconsistencies. After you
select and reconcile scope inconsistencies, the DHCP service either restores those IP addresses to the
original owner or creates a temporary reservation for those addresses. These reservations are valid for
the lease time assigned to the scope. When the lease time expires, the addresses are recovered for
future use.
In the event that you must move the DHCP Server role to another server, it is advisable to move the
database to the new server, as well. This ensures that client leases are retained and reduces the
likelihood of client-configuration issues.
You move the database initially by backing it up on the old DHCP server. Then, shut down the DHCP
service on the old DHCP server. The DHCP database then is copied to the new server, where you can
restore it using the normal database restore procedure.
27
28
You also can use the DHCP NETSH command to backup the database. This is useful for backing up the
database to a remote location using a script file. An example of a script that you can use to export the
file is:
From the NETSH DHCP prompt, type: export "c:\My Folder\Dhcp Configuration" all
This command will back up the DHCP data for all scopes. To restore the DHCP database, use the
following command: import "c:\My Folder\Dhcp Configuration" all
DHCP is a dynamic protocol. Changes in the network environment usually result in DHCP server changes
to accommodate the new environment. These changes may come from more clients on the network,
which can cause a greater traffic load on the DHCP server, or because the DHCP server exhausts its
address pool. Monitoring these operations enables you to address new needs proactively as they arise.
This keeps service outages to a minimum and reduces downtime.
DHCP has three sources of information that you can use for monitoring:
DHCP statistics
The following table describes, and provides examples of, common DHCP issues:
Address conflicts The same IP address is offered to An administrator deletes a lease. However, the client who
two different clients. had the lease still believes the lease is valid. If the DHCP
server does not verify the IP, it may release the IP to
28
29
DHCP performance counters become available after you install the DHCP Server role. You then can use
Performance Monitor to load the performance counters.
A DHCP server typically should not come under a heavy network load. However, if you notice the queue
lengths are logging consistently high values, you should check the server for bottlenecks that could be
slowing DHCP performance.
The following table lists common performance counters and provides recommendations about what to
look for after you establish a baseline:
Packets received/second Monitor for sudden increases or decreases, which could reflect network problems.
29
30
Packets expired/second Monitor for sudden increases. A large number indicates that the server is either taking
too long to process some packets while other packets are queued and becoming stale,
or traffic on the network is too high for the server to manage.
Requests/second Monitor for sudden increases or decreases, which could reflect network problems.
Milliseconds per packet Monitor for sudden increases. A sudden or unusual increase might indicate a problem,
either with the input/output (I/O) subsystem becoming slower or because of an intrinsic
processing overhead on the server computer.
Active queue length Monitor for both sudden and gradual increases, which could reflect increased load or
decreased server capacity.
Duplicates dropped/second Monitor for any activity that could indicate that more than one request is being
transmitted on behalf of clients.
The Windows Server 2003 DHCP service includes a set of performance counters that can be used to
monitor various types of server activity. To access these counters, you must use System Monitor. For
more information, see System Monitor overview.
By default, performance monitoring of DHCP servers is available for use after the DHCP service
component is installed. DHCP performance is measured using the following metrics and counters:
Name Description
Packets The number of message packets received per second by the DHCP server. A
Received/sec large number indicates heavy DHCP-related message traffic to the server.
Duplicates The number of duplicated packets per second dropped by the DHCP server. This
Dropped/sec number can be affected by multiple DHCP relay agents or network interfaces
forwarding the same packet to the server. A large number here indicates that
either clients are probably timing out too fast or the server is not responding
30
31
fast enough.
Packets The number of packets per second that expire and are dropped by the DHCP
Expired/sec server. When a DHCP-related message packet is internally queued for 30
seconds or more, it is determined to be stale and expired by the server. A large
number here indicates that the server is either taking too long to process some
packets while other packets are queued and becoming stale, or traffic on the
network is too high for the server to manage.
Milliseconds per The average time in milliseconds used by the DHCP server to process each
packet (Avg.) packet it receives. This number can vary depending on the server hardware and
its I/O subsystem. A sudden or unusual increase might indicate a problem,
either with the I/O subsystem becoming slower or because of an intrinsic
processing overhead on the server computer.
Active Queue The current length of the internal message queue of the DHCP server. This
Length number equals the number of unprocessed messages received by the server. A
large number might indicate heavy server traffic.
Conflict Check The current length of the conflict check queue for the DHCP server. This queue
Queue Length holds messages without responses while the DHCP server performs address
conflict detection. A large value here might indicate that Conflict Detection
Attempts has been set too high or that there is unusually heavy lease traffic at
the server.
Discovers/sec The number of DHCP discover messages (DHCPDISCOVERs) received per second
by the server. These messages are sent by clients when they start on the
network and obtain a new address lease. A sudden or unusual increase
indicates a large number of clients are attempting to initialize and obtain an IP
address lease from the server, such as when a number of client computers are
started at any given time.
Offers/sec The number of DHCP offer messages (DHCPOFFERs) sent per second by the
DHCP server to clients. A sudden or unusual increase in this number indicates
31
32
Requests/sec The number of DHCP request messages (DHCPREQUESTs) received per second
by the DHCP server from clients. A sudden or unusual increase in this number
indicates a large number of clients trying to renew their leases with the DHCP
server. This might indicate that scope lease durations are too short.
Acks/sec The number of DHCP acknowledgment messages (DHCPACKs) sent per second
by the DHCP server to clients. A sudden or unusual increase in this number
indicates that a large number of clients are being renewed by the DHCP server.
This might indicate that scope lease durations are too short.
Nacks/sec The number of DHCP negative acknowledgment messages (DHCPNAKs) sent per
second by the DHCP server to clients. A very high value might indicate potential
network trouble in the form of misconfiguration of either the server or clients.
When servers are misconfigured, one possible cause is a deactivated scope. For
clients, a very high value could be caused by computers moving between
subnets, such as laptop portables or other mobile devices.
Declines/sec The number of DHCP decline messages (DHCPDECLINEs) received per second by
the DHCP server from clients. A high value indicates that several clients have
found their address to be in conflict, possibly indicating network trouble. In this
situation, it can help to enable conflict detection on the DHCP server. This
should only be used temporarily. Once the situation returns to normal, it should
be turned off.
Releases/sec The number of DHCP release messages (DHCPRELEASEs) received per second by
the DHCP server from clients. This number only exists if a DHCP client sends a
release to the server. This can occur manually, such as when the ipconfig
32
33
command is used at the client computer. Release messages can also be sent by
the client if it is configured with the "Release DHCP lease on shutdown" option.
Because clients rarely release their address, the value of this counter remains
low for many DHCP network configurations. For more information about DHCP
options, see "DHCP Options" at the Microsoft Windows Resource Kits Web site.
Securing DHCP
DHCP protocol has no built-in method for authenticating users. This means that if you do not take
precautions, IP leases could be granted to devices and users who have malicious intent. In this lesson,
you will learn how to prevent unauthorized users from obtaining a lease, how to manage rogue DHCP
servers, and how to configure DHCP servers so that a specific group can manage them.
DHCP by itself can be difficult to secure. This is because the protocol is designed to work before the
necessary information is in place for a client computer to authenticate with a domain controller.
Basic precautions that you should take to limit unauthorized access include:
Make sure that you reduce physical access. If users can access a live network connection in the
network, they are likely to be able to obtain an IP address. If a network port is not being used,
you should disconnect it physically from the switching infrastructure.
Enable audit logging on all DHCP servers. This can provide an historical view of activity, as well as
allow you to trace when a potentially malicious user obtained an IP address in the network.
Make sure to schedule time at regular intervals to review the audit logs.
33
34
Authenticate users. Most enterprise switches now support Institute of Electrical and Electronics
Engineers, Inc. (IEEE), and 802.1X authentication. This allows for port-level user authentication.
Implement NAP. NAP allows administrators to validate that a client computer is running all the
latest Windows updates. It also validates the client is running an up-to-date antivirus client. If a
user who does not meet security requirements tries to access the network, they will be allowed
to access a remediation network where they can receive the necessary updates. The
administrator also can restrict access to the network by allowing only authenticated users access
to the internal local area network (LAN).
34