If you have installed a large number of workstations
at your site,
setting up the initial and minimum configuration for
each by hand,
you must have wondered if there were not a better and
way to do it. Once the setup is complete, most configuration
done through automated procedures, such as rdist(1),
would be nice to automate that initial phase also. And
there is in
fact an easier way on the way. The Internet Engineering
(IETF) has come up with an RFC, to be implemented soon
vendors, which can do some of this work. The new method
is based on
an extension to the older BOOTP protocol and is known
as the Dynamic
Host Configuration Protocol, or DHCP. This protocol
provides a means
of sending network configuration information accross
from a DHCP server to a client, typically a new workstation.In "manual allocation mode" the IP address
the client is explicitly assigned by the system administrator,
the DHCP role here is only to forward that address through
communication method used with the previous two methods.
The system administrator can configure the server to
use these three
methods in any combination, in accordance with local
If the administrator uses the dynamic allocation method,
assigned address can be "recycled" and used
again at a later
time, after that host no longer needs the address. The
RFC which decribes
this protocol suggests that this method is useful where
IPs are to
be assigned to machines that will be in use only temporarily,
there are a limited number of IP addresses available
on the network.
My own experience inlcudes an instance where an automatic,
assignment of IP addresses would have been useful. In
case, machines were brought up on the network for a
few days while
they were installed and configured and then they were
and rolled out the door to be shipped to customers.
Even though the
production people had an assigned set of IP addresses,
they were constantly
able to find new ways to use duplicate addresses. DHCP
been a blessing there.
Since the DHCP protocol and message format is based
on the older BOOTP
protocol, a brief look at how BOOTP operates will serve
as a good
introduction to the world of DHCP.
The BOOTP Protocol
BOOTP is a bootstrap protocol (using UDP) which allows
client machine to find out which IP address it should
use, the IP
address of the boot server, and which file it should
load into memory
and executed. This bootstrap operation is done in two
steps. The BOOTP
protocol handles the first step, which consists of finding
IP addresses and determining what file should be transferred
the boot server. The second step, which consists of
loading the bootstrap
program into memory, is typically done with TFTP, but
could be performed
with another file transfer protocol, such as FTP.
Although the format of the protocol package is of little
to system administrators, but in order to understand
it's necessary to venture a little into this area. The
uses the same package format for both requests and replies.
is 328 bytes long, the first 20 bytes are occupied by
the IP header,
and the following 8 bytes are used by the UDP header.
300 bytes are used by the BOOTP protocol.
BOOTP presents a problem for the server of the chicken
and egg variety.
How can the server send a response to the client, if
the client does
not yet know its own address? The client cannot respond
Resolution Protocol (ARP) requests until it has learned
its own address.
In UNIX, the server will often solve this problem by
the server uses the ioctl system call to enter the client
into the ARP cache, then the server's ARP module will
have the client's
IP address in the cache.
If the client already knows its IP address from some
then the server can respond in the normal manner.
The Design of DHCP
The goal of the DHCP protocol is to provide a method
a client that has no implicit policies embedded. The
to give the local system administrator full control
issues. This is an important feature: too many system
tools implement implicit policies that may or may not
for a given site.
Another useful feature of DHCP is that it does not necessarily
manual configuration. Each client is able to discover
needs to know without user or system administrator intervention,
is able to enter this information into its own configuration.
DHCP allows the server to be anywhere on the local network
it does not require the server to be on the local subnet).
the clients are required to choose one of several replies,
it is possible
to have multiple servers to increase availability and
Finally, DHCP has been designed to co-exist with hosts
that were configured
the old-fashioned way -- that is, by the system administrator
the configuration files. This backward compatibility
means you can
start using DHCP without having to reconfigure your
Overview of the Protocol
As mentioned above, DHCP is essentially a number of
the BOOTP protocol. DHCP servers are thus able to interact
that can speak BOOTP (though, such clients cannot take
the DHCP extensions). There are two main differences
and DHCP. First, DHCP is capable of assigning an IP
address to a client
for a limited amount of time (the RFC calls this a lease),
the address to be recycled when no longer needed. Second,
a mechanism in place that allows the client to obtain
all the IP-related
information it needs to be able to operate on the network.
DHCP does show some small differences from BOOTP (the
RFC calls these
"clarifications"). The vendor extension field
BOOTP protocol becomes the options field in DHCP, and
field now has a minimum size 0f 312 bytes (larger packet
be negotiated through the "maximum DHCP message
New with DHCP is a "client identifier" option
which is used
to pass an explicit client identifier to a DHCP server.
eliminates the overloading of the chaddr field in BOOTP
messages, where chaddr is used both as a hardware address
for transmission of BOOTP reply messages and as a client
The package format for DHCP is shown in Figure 1. The
fields of a
DHCP message are shown to Figure 2.
DHCP also provides for vendor specific extensions, through
specific information" option. The intent here is
to allow vendors
to implement extensions to the protocol, yet still be
able to communicate
with servers or clients from other vendors. In fact,
the RFC states:
"Options encapsulated as 'vendor specific information'
must be carefully defined and documented so as to allow
between clients and servers from diferent vendors."
The RFC goes
on to specify a number of guidelines vendors must adhere
to in order
to use this option.
The Dynamic Allocation of IP Addresses
One of the services provided by DHCP is the assignment
of IP addresses
to clients, whether on a temporary or a permanent basis.
employed is simple. When a client requests an IP address,
specify how long the address will be needed. The server(s)
reallocate that address within the requested amount
of time, which
is the amount of time the "lease" of the address
The client can extend its lease, or it may give the
address back to
the server if the address is no longer needed. A lease
can be anywhere
from one hour (the minimum) to about 100 years; it can
also be a permanent
lease (a lease of infinite length), as the maximum value
for the lease
The server can reuse addresses for which the lease has
RFC assigns both the server and the client the responsibility
ensuring that such an addresses is indeed free, but
under some circumstances
duplicate IP addresses may still occur. It is also possible
lease on the IP address to expire while the client is
up and active.
According to the RFC, this should not happen with well-behaved
well-implemented servers and clients, but I think this
in the category of "if you don't absolutely need
it, you don't
A DHCP Example
The following steps represent a small example of how
an IP address to a client. The example refers to various
(see Figure 3 for a description of DHCP messages).
a graphical timeline of the interaction.
1. The client broadcasts a DHCPDISCOVER message to
tell the world it needs to know its own IP address.
2. Each server that receives the message responds
with a DHCPOFFER message that includes an IP address
in the yiaddr
field. The server can also return other kinds of configuration
as DHCP options.
3. Based on the configuration parameters offered
in the DHCPOFFER messages sent by the servers, the client
one server from which to request configuration parameters.
a DHCPREQUEST message that identifies which server it
has chosen to
be configured from.
4. The servers not selected by the client use the
message as notification that the client has chosen to
server. The server selected by the client responds with
message, which contains the configuration parameters
for the client.
If the selected server is unable to satisfy the DHCPREQUEST
message, it sends a DHCPNAK message (although in this
case one wonders
why the server responded in the first place).
5. Upon receiving the DHCPACK message containing
its configuration parameters, the client performs a
check on those
parameters (e.g., by sending an ARP for allocated network
and notes how long it will be allowed to use the address
how long the lease is). Unless the client finds a problem,
it is now
configured. If the client does find a problem, it notifies
with a DHCPDECLINE message, and then must start the
process over again.
6. If the client at some point finds that it no longer
needs the IP address it has been assigned, it can return
by sending a DHCPRELEASE message to the server. The
server is then
free to to assign the address to another client.
If the client already knows what IP address it wants
to use, it does
not need to go through as many steps as in the previous
it will follow the process shown in Figure 5 and outlined
1. The client broadcasts a DHCPREQUEST.
2. If the request is valid, the servers that know
the client's configuration respond with a DHCPACK message.
requests, the servers send a DHCPNAK message.
3. When the client receives the DHCPACK message with
its configuration parameters, it performs a check on
in the same manner as in the example above.
How the Lease Works
The concept of the lease of an IP address is new, and
a look at how
DHCP implements this is worthwhile.
When a server sends configuration data to a client (via
message), it must specifiy how long the client can use
the IP address
it is assigning. This is done by in one of the following
Parameters with non-default values on the client's subnet.
If all these conditions are met, the server inserts
field from the DHCPDISCOVER message into the xid field
the DHCPOFFER message and sends the DHCPOFFER message
to the requesting
DHCP is built directly on UDP and IP, which are still
Furthermore, DHCP is generally intended to make maintenance
and/or diskless hosts easier. While perhaps not impossible,
such hosts with passwords or keys may be difficult and
Therefore, DHCP in its current form is quite insecure.
Unauthorized DHCP servers can be set up easily. Such
servers can then
send false and potentially disruptive information to
as incorrect or duplicate IP addresses, incorrect routing
(including spoof routers, etc.), incorrect domain nameserver
(such as spoof nameservers), and so on. Once this seed
is in place, an attacker can further compromise affected
Malicious DHCP clients could masquerade as legitimate
retrieve information intended for those legitimate clients.
dynamic allocation of resources is used, a malicious
claim all resources for itself, thereby denying resources
A host should not act as a DHCP server unless explicitly
to do so by a system administrator. The diversity of
protocol implementations in the Internet would preclude
if random hosts were allowed to respond to DHCP requests.
IP requires the setting of many parameters within the
software. Because IP can be used on many dissimilar
kinds of network
hardware, values for those parameters cannot be guessed,
nor can they
be assumed to have correct defaults. Also, distributed
schemes depend on a polling/defense mechanism for discovery
that are already in use. IP hosts may not always be
able to defend
their network addresses, so such a distributed address
scheme cannot be guaranteed to avoid allocation of duplicate
Much of the information in this article has been taken
from RFC 1541,
which is freely available from ftp.internic.net and
ftp servers. BOOTP is described in RFC 951.
Several vendors (see Figure 6) are working on providing
clients for DHCP, and we should have a multitude to
choose from in
the near future. The one implementation I have had the
to work with is from Competive Automation, one of the
to ship a commercial version of this product. As of
this writing they
are also the only company I know of that is committed
some of the security problems in the protocol, although
I hope other
companies will soon follow suit.
DHCP has the promise of enabling system administrators
to make the
configuration process fully automated, but the unresolved
issues raise a cautionary red flag. A university or
arm of a commercial organization should be able to reap
while a financial organization will probably want to
wait for good
vendor extensions or, even better, security amendments
to the protocol
from the IETF.
About the Author
Bjorn Satdeva is the president of /sys/admin, inc.,
firm which specializes in large installation system
Bjorn is also co-founder and former president of Bay-LISA,
a San Francisco
Bay Area user's group for system administrators of large
can be contacted at /sys/admin, inc., 2787 Moorpark
Ave., San Jose,
CA 95128; electronically at email@example.com; or by
at (408) 241-3111.