16.

1 BOOTP
The Bootstrap Protocol (BOOTP) is a client/server protocol that
configures a diskless computer or a computer that is booted for the first
time. BOOTP provides the IP address, net mask, the address of a default
router, and the address of a name server.

The topics discussed in this section include:

Operation
Packet Format

TCP/IP Protocol Suite 2

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
can provide all these pieces of information including the IP address:
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
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
physical 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.
 Figure 21.7 BOOTP client and server on the same and different networks

21.14

Note

DHCP provides static and dynamic

address allocation that can be
manual or automatic.

21.15

1
for76042_ch18.fm Page 577 Monday, February 23, 2009 10:05 PM

CHAPTER 18 HOST CONFIGURATION: DHCP 577

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.

Figure 18.8 DHCP client transition diagram

Boot

INIT
_ / DHCPDISCOVER

DHCPOFFER
SELECTING

Select Offer / DHCPREQUEST

REQUESTING Lease time expired

or
DHCPNACK
Lease time 50% expired / DHCPACK Lease cancelled/
DHCPREQUEST DHCPRELEASE
BOUND

DHCPACK DHCPACK
RENEWING REBINDING

Lease time 87.5% expired /

DHCPREQUEST

INIT State
When the DHCP client first starts, it is in the INIT state (initializing state). The client
broadcasts a DHCPDISCOVER message (a request message with the DHCPDIS-
COVER option), using port 67.

SELECTING State
After sending the DHCPDISCOVER message, the client goes to the selecting state.
Those servers that can provide this type of service respond with a DHCPOFFER mes-
sage. In these messages, the servers offer an IP address. They can also offer the lease
duration. The default is 1 hour. The server that sends a DHCPOFFER locks the offered
IP address so that it is not available to any other clients. The client chooses one of the
for76042_ch18.fm Page 578 Tuesday, February 17, 2009 11:49 AM

578 PART 4 APPLICATION LAYER

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, the client sleeps for 5 minutes before trying again.
REQUESTING State
The client remains in the requesting state until it receives a DHCPACK message from
the server that creates the binding between the client physical address and its IP
address. After receipt of the DHCPACK, the client goes to the bound state.
BOUND State
In this state, the client can use the IP address until the lease expires. When 50 percent of
the lease period is reached, the 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 initializing state.
RENEWING State
The client remains in the renewing state until one of two events happens. It can receive
a DHCPACK, which renews the lease agreement. In this case, the client resets its timer
and goes back to the bound state. Or, if a DHCPACK is not received, and 87.5 percent
of the lease time expires, the client goes to the rebinding state.
REBINDING State
The client remains in the 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 IP address. If the client receives a DHCPACK, it goes to the bound
state and resets the timer.
for76042_ch18.fm Page 579 Tuesday, February 17, 2009 11:49 AM

CHAPTER 18 HOST CONFIGURATION: DHCP 579

Exchanging Messages
Figure 18.9 shows the exchange of messages related to the transition diagram.

Figure 18.9 Exchanging messages

Passive
open
Client 67 Server
UDP
Client 68 DHCPDISCOVER 67 Server
UDP UDP
Client 68 DHCPOFFER 67 Server
UDP UDP
Client 68 DHCPREQUEST 67 Server
UDP UDP
Client 68 DHCPACK 67 Server
UDP Before 50 percent of UDP
lease time expires.
Client 68 DHCPREQUEST 67 Server
UDP If the server does not respond, UDP
the request is repeated.
Client 68 DHCPREQUEST 67 Server
UDP If the server responds with a NACK, UDP
the client must start all over again.
Client 68 DHCPNACK 67 Server
UDP If the server responds with an ACK, UDP
the client has a new lease.
Client 68 DHCPACK 67 Server
UDP UDP

Client 68 DHCPRELEASE 67 Server

UDP UDP
DHCP: Dynamic Host Configuration Protocol
Goal: allow host to dynamically obtain its IP address from
network server when it joins network
Can renew its lease on address in use
Allows reuse of addresses (only hold address while connected an
“on”
Support for mobile users who want to join network (more
shortly)
DHCP overview:
 host broadcasts “DHCP discover” msg
 DHCP server responds with “DHCP offer” msg
 host requests IP address: “DHCP request” msg
 DHCP server sends address: “DHCP ack” msg

DHCP client-server scenario

A 223.1.1.1 DHCP 223.1.2.1

server
223.1.1.2
223.1.1.4 223.1.2.9
B
223.1.2.2 arriving DHCP
223.1.1.3 223.1.3.27 E
client needs
223.1.3.1 223.1.3.2
address in this
network

2
 DHCP client-server scenario
DHCP server: 223.1.2.5 arriving
DHCP discover
client
src : 0.0.0.0, 68
dest.: 255.255.255.255,67
yiaddr: 0.0.0.0
transaction ID: 654

DHCP offer
src: 223.1.2.5, 67
dest: 255.255.255.255, 68
yiaddrr: 223.1.2.4
transaction ID: 654
Lifetime: 3600 secs
DHCP request
src: 0.0.0.0, 68
dest:: 255.255.255.255, 67
yiaddrr: 223.1.2.4
transaction ID: 655
time Lifetime: 3600 secs

DHCP ACK
src: 223.1.2.5, 67
dest: 255.255.255.255, 68
yiaddrr: 223.1.2.4
transaction ID: 655
Lifetime: 3600 secs

21-2 ICMP

The IP protocol has no error-reporting or error-

correcting mechanism. The IP protocol also lacks a
mechanism for host and management queries. The
Internet Control Message Protocol (ICMP) has been
designed to compensate for the above two deficiencies.
It is a companion to the IP protocol.
Topics discussed in this section:
Types of Messages
Message Format
Error Reporting and Query
Debugging Tools

21.19

3
 Figure 21.8 General format of ICMP messages

21.20

Note

ICMP always reports error messages to

the original source.
Message Format
An ICMP message has an 8-byte header and a variable-size data section. Although the
general format of the header is different for each message type, the first 4 bytes are
common to all. As Figure 9.3 shows, the first field, ICMP type, defines the type of the
message. The code field specifies the reason for the particular message type. The last
common field is the checksum field (to be discussed later in the chapter). The rest of the
header is specific for each message type.
The data section in error messages carries information for finding the original
packet that had the error. In query messages, the data section carries extra information
based on the type of the query.
21.21

4
 Figure 21.9 Error-reporting messages

21.22

Figure 21.10 Contents of data field for the error messages

21.23

5
 Figure 21.12 Query messages

21.24

Figure 21.13 Encapsulation of ICMP query messages

21.25

6
 Frequent ICMP Error message

Type Code Description

3 0 15 Destination Notification that an IP datagram could not be

–

unreachable forwarded and was dropped. The code field

contains an explanation.
5 0 3 Redirect
–

Informs about an alternative route for the

datagram and should result in a routing table
update. The code field explains the reason for
the route change.
11 0, 1 Time Sent when the TTL field has reached zero
exceeded (Code 0) or when there is a timeout for the
reassembly of segments (Code 1)
12 0, 1 Parameter Sent when the IP header is invalid (Code 0) or
problem when an IP header option is missing (Code 1)

Echo Request and Reply

An echo-request message can be sent by a host or router. An echo-reply message is sent

by the host or router that receives an echo-request message.

Echo-request and echo-reply messages can be used by network managers to check the
operation of the IP protocol.

Echo-request and echo-reply messages can test the reachability of a host. This is usually
done by invoking the ping command.

Timestamp Request and Reply

Timestamp-request and timestamp-reply messages can be used to calculate the
round-trip time between a source and a destination machine even if their
clocks are not synchronized.

The timestamp-request and timestamp-reply messages can be used to synchronize two

clocks in two machines if the exact one-way time duration is known.

The timestamp-request and timestamp-reply messages can be used to synchronize two

clocks in two machines if the exact one-way time duration is known.
 Example 21.2

Figure 21.14 shows an example of checksum calculation

for a simple echo-request message. We randomly chose
the identifier to be 1 and the sequence number to be 9.
The message is divided into 16-bit (2-byte) words. The
words are added and the sum is complemented. Now the
sender can put this value in the checksum field.
Checksum Calculation
The sender follows these steps using one’s complement arithmetic:
1. The checksum field is set to zero.
2. The sum of all the 16-bit words (header and data) is calculated.
3. The sum is complemented to get the checksum.
4. The checksum is stored in the checksum field.

Checksum Testing
The receiver follows these steps using one’s complement arithmetic:
1. The sum of all words (header and data) is calculated.
2. The sum is complemented.
3. If the result obtained in step 2 is 16 0s, the message is accepted; otherwise, it is
rejected.

Figure 21.14 Example of checksum calculation

21.27

7
 Example 21.3

We use the ping program to test the server fhda.edu. The

result is shown on the next slide. The ping program sends
messages with sequence numbers starting from 0. For
each probe it gives us the RTT time. The TTL (time to
live) field in the IP datagram that encapsulates an ICMP
message has been set to 62. At the beginning, ping defines
the number of data bytes as 56 and the total number of
bytes as 84. It is obvious that if we add 8 bytes of ICMP
header and 20 bytes of IP header to 56, the result is 84.
However, note that in each probe ping defines the number
of bytes as 64. This is the total number of bytes in the
ICMP packet (56 + 8).

21.28

Example 21.3 (continued)

21.29