Host Configuration: DHCP

TCP/IP Protocol Suite 1

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
 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:

• address of a default router to be able to communicate with other
networks and
• address of a name server to be able to use names instead of
addresses.

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
TCP/IP Protocol Suite 2
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.

What about a diskless workstation or a computer with a disk that is

booted for the first time?

TCP/IP Protocol Suite 3

 Previous Protocols

Before DHCP became the formal protocol for host configuration, some other
protocols were used for this propose.

RARP
Reverse Address Resolution Protocol (RARP) was designed to provide the IP
address for a booted computer.

RARP maps a physical address to an IP address.

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 4 pieces of information.

TCP/IP Protocol Suite 4

 BOOTP

Bootstrap Protocol (BOOTP) is the prerunner of DHCP.

It is a client/server protocol designed to overcome the 2 deficiencies of

RARP protocol.

• First, since it is a client/server program, the BOOTP server can be anywhere

in the Internet.
• Second, it can provide all pieces of information we mentioned above,
including the IP address.

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.

• Binding between physical address and the IP address of the client already
exists.

TCP/IP Protocol Suite 5

 There are situations where we need a dynamic configuration
protocol.

• When a host moves from one physical network to another, its

physical address changes.

• There are occasions when a host wants a temporary IP address to

be used for a period of time.

DHCP has been devised to handle these shortcomings.

TCP/IP Protocol Suite 6

 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.

TCP/IP Protocol Suite 7

 18-2 DHCP OPERATION

The DHCP client and server can either be on the same network
or on different networks.

TCP/IP Protocol Suite 8

  Same Network
 Different Networks
 UDP Ports
 Using TFTP
 Error Control
 Packet Format

TCP/IP Protocol Suite 9

 Same Network

Although the practice is not very common, the administrator may

put the client and the server on the same network.

TCP/IP Protocol Suite 10

 Figure 18.1 Client and server on the same network

TCP/IP Protocol Suite 11

 The operation can be described as follows:

1. 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. The
message is encapsulated in a UDP user datagram, using the destination port
number 67 and the source port number 68. 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
unicast because the server knows the IP address of the client.

TCP/IP Protocol Suite 12

 Different Networks

client can be in one network and the server in another, separated by

several other networks.

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. an IP address of all 1s is a

limited broadcast address.

TCP/IP Protocol Suite 13

 Different Networks (contd)

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.

Relay agent knows 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 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.

TCP/IP Protocol Suite 14

 Figure 18.2 Client and server on two different networks

TCP/IP Protocol Suite 15

 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 ephemeral port is to
prevent a problem when the reply, from the server to the client, is broadcast.

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 same).
• 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.
• Confusion is due to the demultiplexing of packets based on the socket address, which is a
combination of IP address and port number. In this case, both are the same.
TCP/IP Protocol Suite 16
 UDP Ports

Use of a well-known port (less than 1024) prevents the use of same two
destination port numbers.

Host B cannot select 68 as the ephemeral port because ephemeral port

numbers are greater than 1023.

What happens if host B is also running the DHCP client.

• The socket address is the same and both clients will receive the message.

• In this situation, a third identification number differentiates the clients.

• DHCP uses another number, called the transaction ID, which is randomly
chosen for each connection involving DHCP.

• It is highly improbable that two hosts will choose the same ID at the same
time.

TCP/IP Protocol Suite 17

 Figure 18.3 Use of UDP ports

TCP/IP Protocol Suite 18

 Using TFTP

Server does not send all of the information that a client may need for booting.

In reply message, server defines the pathname of a file in which the client can
find complete booting information.

Client can then use a TFTP message, which is encapsulated in a UDP user
datagram, to obtain the rest of the needed information.

TCP/IP Protocol Suite 19

 Error Control

What if a request is lost or damaged? What if the response is damaged?

There is a need for error control when using DHCP.

DHCP uses UDP, which does not provide error control. Therefore, DHCP must
provide error control.

Error control is accomplished through 2 strategies:

1. DHCP requires that UDP uses the checksum. Use of checksum in UDP is
optional.

2. DHCP client uses timers and a retransmission policy if it does not receive the
DHCP reply to a request. To prevent a traffic jam when several hosts need to
retransmit a request (after a power failure), DHCP forces the client to use a
random number to set its timers.

TCP/IP Protocol Suite 20

 Figure 18.4 DHCP packet format

Packet Format

Operation code. 8-bit field defines type of DHCP packet: request (1) or reply (2).
Hardware type. 8-bit field defining the type of physical network. For Ethernet the value
is 1.
Hardware length. 8-bit field defining length of physical address. For Ethernet the value
is 6.
Hop count. 8-bit field defining the maximum number of hops the packet can travel.
Transaction ID. 4-byte field carrying an integer. Transaction identification is set by the
client and is used to match a reply with the request. Server returns the same value in its
reply.
TCP/IP
NumberProtocol Suite
of seconds. 16-bit field that indicates the number of seconds elapsed since the 21
 Figure 18.5 Flag format

Flag.

16-bit field in which only leftmost bit is used and rest of the bits should be set to
0s.

A leftmost bit specifies a forced broadcast reply (instead of unicast) from the
server.

If the reply were to be unicast to the client, the destination IP address of the IP
packet is the address assigned to the client.

Since the client does not know its IP address, it may discard the packet.

If the IP datagram is broadcast, every host will receive and process the broadcast
message.

TCP/IP Protocol Suite 22

Client IP address. 4-byte field that contains the client IP address. If the client
does not have this information, this field has a value of 0.

Your IP address. 4-byte field that contains the client IP address. It is filled by the
server (in the reply message) at the request of the client.

Server IP address. 4-byte field containing the server IP address. It is filled by the
server in a reply message.

Gateway IP address. 4-byte field containing the IP address of a router. It is filled

by the server in a reply message.

Client hardware address. physical address of the client.

Server name. 64-byte field that is optionally filled by the server in a reply packet.
It contains a null-terminated string consisting of the domain name of the server. If
the server does not want to fill this field with data, the server must fill it with all 0s.

TCP/IP Protocol Suite 23

 Boot filename. 128-byte field that can be optionally filled by the server in a reply
packet. It contains full pathname of the boot file. Client can use this path to retrieve
other booting information. If the server does not want to fill this field with data,
server must fill it with all 0s.

Options. An option is composed of three fields: a 1-byte tag field, a 1-byte length
field, and a variable-length value field. The length field defines the length of the
value field, not the whole option.

TCP/IP Protocol Suite 24

 18-3 CONFIGURATION

The DHCP has been devised to provide static and dynamic

address allocation.

TCP/IP Protocol Suite 25

  Static Address Allocation
 Dynamic Address Allocation
 Transition States
 Other Issues
 Exchanging Messages

TCP/IP Protocol Suite 26

 Static Address Allocation

DHCP server has a database that statically binds physical addresses

to IP addresses.

When working in this way, DHCP is backward compatible with the

deprecated protocol BOOTP.

TCP/IP Protocol Suite 27

 Dynamic Address Allocation
DHCP has a second database with a pool of available IP addresses.

This second database makes DHCP dynamic.

When a DHCP client requests a temporary IP address, DHCP server goes to

the pool of available IP addresses and assigns an IP address for a
negotiable period of time.

When a DHCP client sends a request to a DHCP server, server first checks
its static database.

If an entry with requested physical address exists in the static database,

permanent IP address of the client is returned.

If the entry does not exist in static database, server selects an IP address
from available pool, assigns address to the client, and adds entry to the
dynamic database.

TCP/IP Protocol Suite 28

 Dynamic Address Allocation (contd)

Dynamic aspect of DHCP is needed when a host moves from network to

network or is connected and disconnected from a network.

DHCP provides temporary IP addresses for a limited period of time.

The addresses assigned from the pool are temporary addresses.

DHCP server issues a lease for a specific period of time. When the lease
expires, the client must either stop using the IP address or renew the
lease.

Server has the choice to agree or disagree with the renewal. If the server
disagrees, the client stops using the address.

TCP/IP Protocol Suite 29

 Figure 18.7 Option with tag 53

Transition States

To provide dynamic address allocation, DHCP client acts as a state machine that
performs transitions from one state to another depending on messages it receives
or sends.

The type of message in this case is defined by the option with tag 53 that is
included in DHCP packet.

Figure 18.7 shows the type option and the interpretation of its value to define the
type of the DHCP packet.
Figure 18.8 shows the transition diagram with main states.

TCP/IP Protocol Suite 30

 Figure 18.8 DHCP client transition diagram

TCP/IP Protocol Suite 31

 Figure 18.8 DHCP client transition diagram

INIT State When the DHCP client first starts, it is in the INIT state. The client broadcasts a
DHCPDISCOVER message, using port 67.

SELECTING State After sending the DHCPDISCOVER message, client goes to the selecting
state. Those servers that can provide this type of service respond with a DHCPOFFER message.
In these messages, the servers offer an IP address. They can also offer lease duration. The
default is 1 hour. The client chooses one of the offers and sends a DHCPREQUEST message to
the selected server. It then goes to the requesting state. However, if the client receives no
DHCPOFFER message, it tries four more times, each with a span of 2 seconds. If there is no reply
to any of these DHCPDISCOVERs, client sleeps for 5 minutes before trying again.

REQUESTING State The client remains in requesting state until it receives a DHCPACK
message from server that creates the binding between client physical address and its IP
address. After receipt of the DHCPACK, client goes to the bound state.

BOUND State In this state, client can use the IP address until lease expires. When 50 percent of
the lease period is reached, client sends another DHCPREQUEST to ask for renewal. It then goes
to the renewing state. When in the bound state, the client can also cancel the lease and go to
the state.client remains in renewing state until one of two events happens. It can
initializingState
RENEWING
receive a DHCPACK, which renews lease agreement. In this case, client resets its timer and goes
back to bound state. Or, if a DHCPACK is not received, and 87.5 percent of lease time expires,
client goes to the rebinding state.

REBINDING State client remains in rebinding state until one of three events happens. If the
client receives a DHCPNACK or the lease expires, it goes back to the initializing state and tries to
get another
TCP/IP IP address.
Protocol Suite If the client receives a DHCPACK, it goes to the bound state and resets32
the timer.
 Other Issues

Few issues related to the DHCP states.

Early Release A DHCP client that has been assigned an address for a period of
time may release the address before expiration time. The client may send a
DHCPRELEASE message to tell the server that address is no longer needed. This
helps server to assign the address to another client waiting for it.

Timers above discussion requires that client uses 3 times: renewal timer, rebinding
timer, and expiration timer. If the server does not specify time-out values for these
timers when the address is allocated, client needs to use the default value. default
value for each timer is shown below:

TCP/IP Protocol Suite 33

 Figure 18.9 Exchanging messages

Exchanging Messages
Exchange of messages related to the transition diagram.

TCP/IP Protocol Suite 34

 END

TCP/IP Protocol Suite 35