Droms R. The DHCP handbook
Подождите немного. Документ загружается.
dhcpserve notifies desktop1 that its address is invalid by sending a DHCPNAK message.
After
desktop1 receives the DHCPNAK message, it discards its old address and enters
the
INIT state. At that point, the client tries to obtain a new, valid address as though
it just started up with no IP address. So,
desktop1 goes through the process described
in the section “Obtaining an Initial Configuration” to locate a server and obtain an
address that works on its new subnet. Figure 8.5 illustrates this sequence of
messages.
CHAPTER 16 Working with Graphs116
DHCPNAKDHCPREQUEST DHCPACKDHCPREQUESTDHCPOFFERDHCPDISCOVER
desktop1
Time
dhcpserve
FIGURE 8.5 Messages used by a DHCP client to obtain an address from a new subnet.
NOTE
Most kinds of network hardware provide ways to notice when a move may have occurred.
Ethernet has a carrier, which is always present when a node is connected to the Ethernet
network. If the node notices that the carrier has gone away and then comes back, it can
assume that the node might have changed networks. Some DHCP clients, such as the DHCP
client in Mac OS X, watch for this kind of transition, and if it happens, they immediately go
into the INIT-REBOOT state to reconfirm their leases. This is not required by the DHCP specifi-
cation, but is a useful optimization.
Working with Multiple Servers
Although the examples thus far in this chapter focus on the messages exchanged
between a client and a single server, the DHCP specification is, in fact, written to
accommodate the use of more than one server. More than one server may be
involved in all client/server exchanges—not just as alternate servers for lease exten-
sions, as described in the section “Extending a Lease.” The model of operation
described in RFC 2131 allows multiple, independent DHCP servers to be configured
on an organization’s network, and it requires that a DHCP client be prepared to
receive multiple responses to its broadcast messages.
011 3273 CH08 10/3/02 5:00 PM Page 116
Obtaining an Initial Address
When a DHCP client broadcasts a DHCPDISCOVER message, it might receive responses
from more than one server. Each responding server offers an address and other
configuration information for the client. The client listens for these responses after
sending the
DHCPDISCOVER message, and it chooses one address from among those
offered. The client uses whatever criteria it wants to select a server. In practice,
however, most clients simply choose the first server to respond.
NOTE
It might be the case that one of the responding servers already has an active lease for the
client. For example, a DHCP client with no local permanent storage sends an initial DHCPDIS-
COVER
every time it restarts because it has no record of its previous address. Similarly, a client
that crashed and lost its record of any previous address broadcasts a DHCPDISCOVER when it
restarts. Unfortunately, a server cannot indicate to a client that the client already has a lease
for the address offered by the server. So the client may choose a different server and unneces-
sarily switch addresses.
What about the servers and the offered addresses that are not selected? The client
indicates which server it has selected in its
DHCPREQUEST message by including the
server’s IP address in the
server identifier option. The DHCPREQUEST message is
then broadcast and delivered to all DHCP servers. The selected server responds to the
client, and the other servers return the offered addresses to their pools of available
addresses. Figure 8.6 illustrates this sequence of messages.
Working with Multiple Servers 117
DHCPDISCOVER DHCPREQUESTDHCPOFFER
dhcpserve2
Time
DHCPOFFERDHCPDISCOVER
DHCPACKDHCPREQUEST
desktop1
dhcpserve
FIGURE 8.6 A time line of messages exchanged between a client and multiple servers
when the client restarts.
011 3273 CH08 10/3/02 5:00 PM Page 117
Of course, the broadcast DHCPREQUEST message may not reach all the DHCP servers.
How long should a server reserve an offered address, waiting for the message from
the client? Reserving the address forever is, of course, a bad idea. If only a relatively
small number of addresses are available, the server will eventually run out of
addresses.
In fact, the DHCP specification enables the server to decide whether to reserve an
address. If, for some reason, it assigns an address to Client B that it previously
offered to Client A before Client A requested the address, the server sends a
DHCPNAK
message in response to Client A’s request. When the client receives the DHCPNAK, it
restarts its configuration process.
NOTE
The ISC DHCP server does not attempt to make use of DHCPREQUEST messages that are
intended for other servers. Instead, it reserves addresses offered to clients for two minutes.
The server also returns addresses offered but not subsequently requested to the end of the list
of available addresses. As long as enough addresses are available on the network, even a
DHCPREQUEST message from the client more than two minutes after the address was offered
will probably be honored.
Restarting
A client may receive replies from multiple servers in response to its DHCPREQUEST
message when restarting. In this case, the client’s job is easy: It simply records the
lease and configuration parameters from the first response and discards subsequent
responses.
A potential problem exists with the consistency of the lease information after servers
extend a client’s lease. Because the client does not respond to the servers’
DHCPACK
messages, the servers don’t know which response the client accepted. If the servers
offer different leases, they will have different information about when the client’s
lease expires. This problem can occur when the client restarts and when it broadcasts
a request to extend its lease. This problem is discussed as part of the larger issue of
exchanging DHCP information among servers in Chapter 10.
Broadcasting to Extend a Lease
A broadcast DHCPREQUEST message that a client sends to find an alternate server to
extend its lease might trigger replies from multiple servers. The client’s response is
much the same as if it receives multiple responses to its initial message when restart-
ing: The client simply records the lease and server identifier from the first reply it
receives, and it discards the rest.
CHAPTER 16 Working with Graphs118
011 3273 CH08 10/3/02 5:00 PM Page 118
Other Message Exchanges
Three additional message sequences are possible:
• The sequence used by a client that is configured with an IP address through
another mechanism
• The sequence used by a client to terminate its lease before the lease expires
• The sequence used by a server to force a client to renew its lease before time T1
These messages are used less frequently than the messages described earlier in this
chapter.
Obtaining Configuration Information with an IP Address Not
Obtained Through DHCP
Some network devices are manually configured with an IP address or they obtain
their addresses through another protocol, such as Point to Point Protocol (PPP; see
RFC 1661).
A network administrator might want to provide other configuration parameters to
these devices through DHCP. Using DHCP for configuration parameters such as DNS
servers and NTP servers enables the administrator to automatically change the
addresses of those servers on all managed computers, minimizing manual configura-
tion and ensuring consistency.
A client with an IP address sends a
DHCPINFORM message to a server to obtain other
configuration parameters. When the server receives the
DHCPINFORM message, it deter-
mines all the appropriate parameters, using the same policies it employs for comput-
ers that use dynamic address assignment. The server returns those parameters to the
client in a
DHCPACK message.
NOTE
DHCPINFORM doesn’t have a mechanism through which a DHCP server can schedule the time
at which the client recontacts the server. If the DHCP server administrator changes network
configuration parameters but the client does not use DHCPINFORM to obtain the new parame-
ters, the client may be using the old, incorrect parameters until the next time it is restarted
(which could be quite a long time).
If the DHCPFORCERENEW message is available on both the server and the client, the server can
use it to cause the client to contact the server immediately rather than wait for the next time
the client is restarted.
Other Message Exchanges 119
011 3273 CH08 10/3/02 5:00 PM Page 119
Terminating a Lease
A client can give up its lease on an address before the lease expires by sending a
DHCPRELEASE message. A user might want to send a DHCPRELEASE message from a
computer that is about to be moved from one subnet to another, so the server
knows that the computer’s old address is immediately available for reassignment.
Some DHCP clients can be configured to send a
DHCPRELEASE each time the
computer is shut down.
The client sends its current address in the
DHCPRELEASE message and does not wait
for a response. The client stops using its old address as soon as it sends the
DHCPRE-
LEASE message, so the server cannot send a response to the client. And, as a practical
matter, a user won’t want to wait for the server to respond while the computer is
shutting down.
Updating a Client’s Configuration
A DHCP server can use the DHCPFORCERENEW message to update a client’s IP address
and configuration immediately, without waiting for the client to contact the server
with a
DHCPREQUEST or DHCPREBIND message. The server sends the DHCPFORCERENEW
message directly to the DHCP client, as described in the section “DHCPFORCERENEW
Messages” in Chapter 7. After the client receives the message, it goes to the RENEWING
state (refer to Figure 8.1). The client then contacts the server by sending a DHCPRE-
QUEST message. If the server only needs to update the client’s parameters, and not its
IP address, it can simply respond with a
DHCPACK message that contains the new
parameters. Otherwise, it responds with a
DHCPNAK message, forcing the client into
the
INIT state. At this point, the client continues by broadcasting a DHCPDISCOVER
message. Finally, the server responds, as described in the section “Obtaining an
Initial Configuration,” with the client’s new IP address and configuration informa-
tion.
Summary
Several interactions between DHCP clients and servers involve specific sequences of
messages. These interactions are designed to allow the clients to operate without
prior knowledge of the location of DHCP servers and to accommodate responses
from more than one server. The interactions also minimize the effect of network and
server failures on the client. The goal is to provide a robust protocol that enables
clients to function in the event of network problems.
When a DHCP client does not have an IP address, it uses a two-phase process to
locate a DHCP server and obtain an initial address. After the client has obtained an
address, it confirms that its address is still valid whenever the client restarts. A client
can contact the server and extend the lease on its address while the client is still
CHAPTER 16 Working with Graphs120
011 3273 CH08 10/3/02 5:00 PM Page 120
running. A client that has already established a lease with a server and merely wants
to confirm the lease when rebooting can do so by using a one-phase process instead
of the two-phase process used initially.
Three other message sequences are less central to the usual client/server interaction.
A client can send a
DHCPRELEASE message to terminate its lease on an address before
the lease expires. If the client already has an IP address, it can use
DHCPINFORM to
obtain other configuration information such as server addresses. A server can use a
DHCPFORCERENEW message to cause a client to contact the server before the time at
which the client was scheduled to extend its lease.
Both this chapter and Chapter 7 describe the mechanisms through which clients
and servers communicate in DHCP. Chapter 9, “DHCP Options,” looks at the
specific information that clients and servers exchange in the
options section of
DHCP messages.
Summary 121
011 3273 CH08 10/3/02 5:00 PM Page 121
011 3273 CH08 10/3/02 5:00 PM Page 122
IN THIS CHAPTER
• DHCP-Specific Options
• Host Configuration
Parameters Options
• TCP/IP Stack Configuration
Parameters
• Service Parameter Options
•
subnet selection
• authentication
• relay agent information
9
DHCP Options
Chapter 6, “The Format of DHCP Messages,” introduces
options as the mechanism through which a DHCP message
type is identified and configuration parameters are trans-
mitted between DHCP servers and clients. This chapter
describes the DHCP options, which are defined in
RFC 2132. The next few chapters explain how options are
used in DHCP messages.
The options described in this chapter are organized into
several categories: options that are specific to DHCP,
options that provide configuration parameters for the
DHCP client, options that carry TCP/IP stack parameters,
and application and service parameter options.
As illustrated in Chapter 8, “DHCP Message Exchanges,”
all DHCP options except for
END and PAD share the same
three-part format: a 1-byte option code, a 1-byte
length
field, and the data that is carried by the option. Options
carry data in different formats, including IP addresses,
character strings, and integers. The descriptions in
this chapter give the option code, the acceptable
length
field values, and the format of the data in each option.
NOTE
The DHCP options listing servers and other network devices
identify servers by their IP addresses rather than by domain
names. Thus, if one of those servers is relocated or for some
other reason assigned a new IP address, the DHCP server data-
bases must be updated to reflect that new address. Also, DHCP
clients do not have a valid address for a server that has been
assigned a new IP address until the client contacts the DHCP
server when it restarts or extends its lease.
012 3273 CH09 10/3/02 4:57 PM Page 123
CHAPTER 9 DHCP Options124
NOTE
The DHCP specification calls for the use of 7-bit USASCII characters as used by the NVT
(network virtual terminal) and defined in the Telnet protocol (which is described in RFC 854).
The DHCP RFCs refer to NVT ASCII characters and NVT ASCII strings. This chapter simply uses
characters and strings.
DHCP-Specific Options
Although both DHCP and BOOTP clients and servers can use the options described
in other sections of this chapter, the options in this section are specific to DHCP
operation.
NOTE
The description of each option in this chapter includes a table that lists the option code, the
range of values of the length field, and the interpretation of data values, along with a short
text description of the option. Most of these options are defined in RFC 2132; specific refer-
ences are included for options that are defined elsewhere.
DHCP message type
Option code: 53
Length: 1
Data: DHCPDISCOVER 1
DHCPOFFER 2
DHCPREQUEST 3
DHCPDECLINE 4
DHCPACK 5
DHCPNAK 6
DHCPRELEASE 7
DHCPINFORM 8
012 3273 CH09 10/3/02 4:57 PM Page 124
DHCPFORCERENEW 9
DHCPLEASEQUERY 10
DHCPKNOWN 11
DHCPUNKNOWN 12
NOTE
At the time this book was written, the DHCPLEASEQUERY, DHCPKNOWN, and DHCPUNKNOWN
message types had not yet been assigned code values.
DHCP client/server transactions use several different message types. The DHCP
message type option identifies a specific type of DHCP message. Chapter 7,
“Transmitting DHCP Messages,” explains how the different message types are used.
client identifier
Option code: 61
Length: n
Data: identifier (n bytes)
DHCP servers use the value of the client identifier option to distinguish between
DHCP clients. If the
client identifier option is present, the DHCP server uses it;
otherwise, the server uses the contents of the
htype and chaddr fields of the DHCP
message. A DHCP client’s identifier must be unique among all the client identifiers
on the IP network to which the client is attached. The server treats a DHCP client
identifier as an opaque value and does not interpret it in any way.
RFC 2132 suggests that client identifiers be composed of a 1-byte type field, followed
by the identifier itself, similarly to the combination of
htype and chaddr fields in the
fixed-format section of a DHCP message. If this format is used, the type value in
the client identifier is either selected from the ARP hardware types defined in STD2
or is set to
0. In the latter case, the client identifier is an arbitrary string, such as a
domain name, rather than a link-layer address.
DHCP-Specific Options 125
012 3273 CH09 10/3/02 4:57 PM Page 125