About DHCP

DHCP stands for Dynamic Host Configuration Protocol, and is used to
centrally allocate and manage TCP/ IP configurations of client nodes.

If you've got more than a handful of computers to manage, then DHCP
can help to save a great deal of time and trouble in setting up and
administering a TCP/ IP network. DHCP offers the following features:

The Dynamic Host Configuration Protocol (DHCP) provides configuration
parameters to Internet hosts. DHCP consists of two components: a
protocol for delivering host-specific configuration parameters from a
DHCP server to a host and a mechanism for allocation of network
addresses to hosts.

DHCP is built on a client-server model, where designated DHCP server
hosts allocate network addresses and deliver configuration parameters
to dynamically configured hosts. Throughout the remainder of this
document, the term "server" refers to a host providing initialization
parameters through DHCP, and the term "client" refers to a host
requesting initialization parameters from a DHCP server.

A host should not act as a DHCP server unless explicitly configured to
do so by a system administrator. The diversity of hardware and protocol
implementations in the Internet would preclude reliable operation if
random hosts were allowed to respond to DHCP requests. For example, IP
requires the setting of many parameters within the protocol
implementation software. Because IP can be used on many dissimilar
kinds of network hardware, values for those parameters cannot be
guessed or assumed to have correct defaults.

Also, distributed address allocation schemes depend on a
polling/defense mechanism for discovery of addresses that are already
in use. IP hosts may not always be able to defend their network
addresses, so that such a distributed address allocation scheme cannot
be guaranteed to avoid allocation of duplicate network addresses.

DHCP supports three mechanisms for IP address allocation. In "automatic
allocation", DHCP assigns a permanent IP address to a host. In "dynamic
allocation", DHCP assigns an IP address to a host for a limited period
of time (or until the host explicitly relinquishes the address). In
"manual allocation", a host's IP address is assigned by the network
administrator, and DHCP is used simply to convey the assigned address
to the host.

A particular network will use one or more of these mechanisms,
depending on the policies of the network administrator.

Dynamic allocation is the only one of the three mechanisms that allows
automatic reuse of an address that is no longer needed by the host to
which it was assigned. Thus, dynamic allocation is particularly useful
for assigning an address to a host that will be connected to the
network only temporarily or for sharing a limited pool of IP addresses
among a group of hosts that do not need permanent IP addresses. Dynamic
allocation may also be a good choice for assigning an IP address to a
new host being permanently connected to a network where IP addresses
are sufficiently scarce that it is important to reclaim them when old
hosts are retired.

Manual allocation allows DHCP to be used to eliminate the error-prone
process of manually configuring hosts with IP addresses in environments
where (for whatever reasons) it is desirable to manage IP address
assignment outside of the DHCP mechanisms.


The format of DHCP messages is based on the format of BOOTP messages,
to capture the BOOTP relay agent behavior described as part of the
BOOTP specification [7, 23] and to allow interoperability of existing
BOOTP clients with DHCP servers. Using BOOTP relaying agents eliminates
the necessity of having a DHCP server on each physical network segment.


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

This article discusses some of the reasons why an organization would
want to use DHCP, along with the many different issues that need to be
considered when designing a DHCP infrastructure. Some of these
considerations include planning for IP address use. An organization
needs to determine how its existing environment is used and what types
of users and workstations are being utilized (such as mobile users and
network devices).

In large-scale DHCP implementations, the topology of the network
becomes a very important factor. The network topology dictates where
DHCP servers and/or relay agents must be placed. The needs of the DHCP
client must be considered, including which DHCP options are supported
by the client's operating system and which options and their
correspomding values need to be assigned. Finally, all of these
elements are brought together to implement the DHCP scopes.

How DHCP Works

For a detailed description of DHCP, we suggest that you download RFC
1541 from any of the Internet draft repository sites. A good place to
start is ds.internic.net, available via FTP, Gopher and HTTP. For a
less detailed description, read on.

DHCP is an extension of BOOTP, the previous IP allocation
specification. So, existing BOOTP devices can communicate with DHCP
servers and allow DHCP requests to cross routers running BOOTP
forwarders. This level of backward compatibility makes it easy for
administrators to upgrade their network devices from BOOTP to DHCP as
needed, without having to replace all of the clients at once or having
to upgrade all of the routers.

Several major advancements beyond the BOOTP specifications provide
significant advantages. For example, DHCP supports the concept of a
"lease" whereby a server can allocate an address to a client for a
specific amount of time. If you have more devices than IP addresses,
using shorter leases can help to keep you from running out of
addresses. If you have more addresses than devices, you can utilize
permanent leases or you can assign fixed addresses to specific devices
similar to BOOTP's mechanism.

Also, DHCP incorporates a much more robust dialogue during lease
negotiation. Since the addresses can be assigned to the devices on an
ad-hoc basis, mechanisms need to be incorporated into the assignment
procedure that allow for a broader range of options, as well as for a
broader range of error handling conditions. BOOTP protocol only allowed
for two types of messages (request and reply), while DHCP has seven
possible message types that can be used during the address assignment
sequence.

When a DHCP device attaches itself to the network for the first time,
it broadcasts a DHCPDISCOVER packet. A DHCP servers on the local
segment will see the broadcast and return a DHCPOFFER packet that
contains an IP address and other information. The servers may or may
not conduct some sort of preliminary testing prior to offering the
address, such as generating an ARP or an ICMP echo to see if the
address is already in use by another node somewhere. If your network
does not have a DHCP server on every segment, you will need to
configure your routers to provide BOOTP relay agents that forward the
broadcasts to a predefined server on a remote segment.

The client may receive multiple DHCPOFFER packets from any number of
servers, so it must choose between them, and broadcast a DHCPREQUEST
packet that identifies the explicit server and lease offer that it
likes the best. This decision may be based on which offer has the
longest lease or which offer provides the most information that the
specific client needs for optimal operation (more on this later). The
non-chosen servers would notice the explicit DHCPREQUEST packet and go
on about their business.

Assuming that the offer is still valid, the chosen server would return
a DHCPACK that tells the client the lease is finalized. If the offer is
no longer valid for some reason-perhaps due to a time-out or another
client allocating the lease-then the selected server must respond with
a DHCPNAK message. This would cause the client to send another
DHCPDISCOVER packet, starting the process over again.

Once the client receives a DHCPACK, then all ownership and maintenance
of the lease is the responsibility of the client. For example, a client
may refuse an offer that is detailed in the DHCPACK message, and it is
the client's responsibility to do so. Clients are supposed to test the
addresses that have been offered to them by conducting ARP broadcasts.
So if another node responds to the ARP, the client would assume that
the offered address is in use. At this point, the client would reject
the offer by sending a DHCPDECLINE message to the offering server, and
would also send another DHCPDISCOVER packet, thereby starting the
process yet again.

Once the client has the lease, it must be renewed prior to the lease
expiration through another DHCPREQUEST message. If a client finishes
using a lease prior to its expiration date, the client is supposed to
send a DHCPRELEASE message to the server so that the lease can be made
available to other nodes. If the server doesn't hear from the client by
the end of the lease, it marks the lease as non-renewed, and makes it
available for other clients to use.

This sequence of events is pretty straightforward and leaves a lot of
room to correct any miscommunication between the clients and the
servers. This is a good thing, because most of the implementations that
we studied at in our labs didn't follow the letter of the law very
well. Only because of the negotiation.