18.

1 INTRODUCTION
Each computer that uses the TCP/IP protocol suite needs to know its IP address. If the
computer uses classless addressing or is a member of a subnet, it also needs to know its
subnet mask. Most computers today need two other pieces of information: the address
of a default router to be able to communicate with other networks and the address of a
name server to be able to use names instead of addresses as we will see in the next
chapter. In other words, four pieces of information are normally needed:
1. The IP address of the computer
2. The subnet mask of the computer
3. The IP address of a router
4. The IP address of a name server
These four pieces of information can be stored in a configuration file and accessed by
the computer during the bootstrap process. But what about a diskless workstation or a
computer with a disk that is booted for the first time?
In the case of a diskless computer, the operating system and the networking soft-
ware could be stored in read-only memory (ROM). However, the above information is
not known to the manufacturer and thus cannot be stored in ROM. The information is
dependent on the individual configuration of the machine and defines the network to
which the machine is connected.

Previous Protocols
Before DHCP became the formal protocol for host configuration, some other protocols
were used for this propose. We briefly describe them here.
RARP
At the beginning of the Internet era, a protocol called Reverse Address Resolution Pro-
tocol (RARP) was designed to provide the IP address for a booted computer. RARP
was actually a version of ARP that we discussed in Chapter 8. ARP maps an IP address
to a physical address: RARP maps a physical address to an IP address. However, RARP
is deprecated today for two reasons. First, RARP used the broadcast service of the data
link layer, which means that a RARP server must be present in each network. Second,
RARP can provide only the IP address of the computer, but a computer today needs all
four pieces of information mentioned above.
BOOTP
The Bootstrap Protocol (BOOTP) is the prerunner of DHCP. It is a client/server pro-
tocol designed to overcome the two deficiencies of the RARP protocol. First, since it is
a client/server program, the BOOTP server can be anywhere in the Internet. Second, it

569
570 PART 4 APPLICATION LAYER

can provide all pieces of information we mentioned above, including the IP address. To
provide the four pieces of information described above, it removes all restriction about
the RARP protocol. BOOTP, however, is a static configuration protocol. When a client
requests its IP address, the BOOTP server consults a table that matches the physical
address of the client with its IP address. This implies that the binding between the physi-
cal address and the IP address of the client already exists. The binding is predetermined.
There are some situations in which we need a dynamic configuration protocol. For
example, when a host moves from one physical network to another, its physical address
changes. As another example, there are occasions when a host wants a temporary IP
address to be used for a period of time. BOOTP cannot handle these situations because
the binding between the physical and IP addresses is static and fixed in a table until
changed by the administrator. As we will see shortly, DHCP has been devised to handle
these shortcomings.

DHCP
The Dynamic Host Configuration Protocol (DHCP) is a client/server protocol
designed to provide the four pieces of information for a diskless computer or a computer
that is booted for the first time. DHCP is a successor to BOOTP and is backward compat-
ible with it. Although BOOTP is considered deprecated, there may be some systems that
may still use BOOTP for host configuration. The part of the discussion in this chapter that
does not deal with the dynamic aspect of DHCP can also be applied to BOOTP.

18.2 DHCP OPERATION

The DHCP client and server can either be on the same network or on different net-
works. Let us discuss each situation separately.

Same Network
Although the practice is not very common, the administrator may put the client and the
server on the same network as shown in Figure 18.1.

Figure 18.1 Client and server on the same network

CP: Client Port Number CIP: Client IP Address

Legend
SP: Server Port Number SIP: Server IP Address

DHCP DHCP
Client Server

To be
configured

0s 1s 68 67 DHCP Request

CP SP SIP 1s 67 68 DHCP Reply

CIP SIP
SP CP
SIP CIP
for76042_ch18.fm Page 571 Tuesday, February 17, 2009 11:49 AM

CHAPTER 18 HOST CONFIGURATION: DHCP 571

In this case, the operation can be described as follows:

1. The DHCP server issues a passive open command on UDP port number 67 and
waits for a client.
2. A booted client issues an active open command on port number 68 (this number
will be explained later). The message is encapsulated in a UDP user datagram,
using the destination port number 67 and the source port number 68. The UDP user
datagram, in turn, is encapsulated in an IP datagram. The reader may ask how a cli-
ent can send an IP datagram when it knows neither its own IP address (the source
address) nor the server’s IP address (the destination address). The client uses all 0s
as the source address and all 1s as the destination address.
3. The server responds with either a broadcast or a unicast message using UDP
source port number 67 and destination port number 68. The response can be uni-
cast because the server knows the IP address of the client. It also knows the physi-
cal address of the client, which means it does not need the services of ARP for
logical to physical address mapping. However, some systems do not allow the
bypassing of ARP, resulting in the use of the broadcast address.

Different Networks
As in other application-layer processes, a client can be in one network and the server in
another, separated by several other networks. Figure 18.2 shows the situation.

Figure 18.2 Client and server on two different networks

DHCP Legend
client Relay agent
Broadcast request
Unicast request
1
LAN
2 DHCP
server

LAN
3
Internet

However, there is one problem that must be solved. The DHCP request is broadcast
because the client does not know the IP address of the server. A broadcast IP datagram
cannot pass through any router. A router receiving such a packet discards it. Recall that
an IP address of all 1s is a limited broadcast address.
To solve the problem, there is a need for an intermediary. One of the hosts (or a
router that can be configured to operate at the application layer) can be used as a relay.
The host in this case is called a relay agent. The relay agent knows the unicast address
of a DHCP server and listens for broadcast messages on port 67. When it receives this
type of packet, it encapsulates the message in a unicast datagram and sends the request
to the DHCP server. The packet, carrying a unicast destination address, is routed by any
for76042_ch18.fm Page 572 Tuesday, February 17, 2009 11:49 AM

572 PART 4 APPLICATION LAYER

router and reaches the DHCP server. The DHCP server knows the message comes from
a relay agent because one of the fields in the request message defines the IP address of
the relay agent. The relay agent, after receiving the reply, sends it to the DHCP client.

UDP Ports
Figure 18.3 shows the interaction between a client and a DHCP server. The server uses
the well-known port 67, which is normal. The client uses the well-known port 68,
which is unusual. The reason for choosing the well-known port 68 instead of an ephem-
eral port is to prevent a problem when the reply, from the server to the client, is broad-
cast. To understand the problem, let us look at a situation where an ephemeral port is
used. Suppose host A on a network is using a DHCP client on ephemeral port 2017
(randomly chosen). Host B, on the same network, is using a DAYTIME client on
ephemeral port 2017 (accidentally the same). Now the DHCP server sends a broadcast
reply message with the destination port number 2017 and broadcast IP address
FFFFFFFF16. Every host needs to open a packet carrying this destination IP address.
Host A finds a message from an application program on ephemeral port 2017. A correct
message is delivered to the DHCP client. An incorrect message is delivered to the
DAYTIME client. The confusion is due to the demultiplexing of packets based on the
socket address (see Chapter 17), which is a combination of IP address and port number.
In this case, both are the same.

Figure 18.3 Use of UDP ports

Passive
open
Client 67 Server
Active UDP
open
Client 68 Request 67 Server
UDP UDP
Reply
Client 68 Reply 67 Server
UDP UDP

The use of a well-known port (less than 1024) prevents the use of the same two
destination port numbers. Host B cannot select 68 as the ephemeral port because
ephemeral port numbers are greater than 1023.
The curious reader may ask what happens if host B is also running the DHCP cli-
ent. In this case, the socket address is the same and both clients will receive the mes-
sage. In this situation, a third identification number differentiates the clients. DHCP
uses another number, called the transaction ID, which is randomly chosen for each con-
nection involving DHCP. It is highly improbable that two hosts will choose the same ID
at the same time.

Using TFTP
The server does not send all of the information that a client may need for booting. In
the reply message, the server defines the pathname of a file in which the client can find