Droms R. The DHCP handbook

Подождите немного. Документ загружается.

NOTE

If the server sends a DHCP message to a client before the client has confirmed its IP address,

the client will not respond to link-layer address resolution protocols such as ARP. The DHCP

server or relay agent may need to explicitly create an entry in its ARP table to provide a

mapping between the IP address it has assigned to the client and the client’s link-layer

address, so that the IP stack on the server will not have to ask the DHCP client for its link-layer

address.

Using Broadcast for Delivery to Clients

Some TCP/IP implementations do not accept incoming IP datagrams that have

unicast destination addresses before the IP address has been configured. For such

implementations, the server sends DHCP messages to the IP broadcast address,

255.255.255.255, and to the local hardware broadcast address.

Using the Broadcast Flag

Sending DHCP messages to the client’s IP address is the preferred delivery mecha-

nism because it avoids interrupting other computers on the network with a broad-

cast message. Therefore, servers use unicast for DHCP messages unless a client

explicitly requests the use of broadcast.

A client can specify that servers use broadcast by setting the broadcast flag in the

flags field of the DHCP message header. If a server receives a DHCP message with

the broadcast flag set to 1, the server broadcasts responses to the client.

On some operating systems, it is not possible to send unicast messages to clients that

do not yet have confirmed IP addresses. In these cases, the DHCP server broadcasts

the message to the client even if the client does not set the broadcast flag to 1.

Relay Agents

Relay agents forward DHCP messages from clients to servers in cases where there is no

DHCP server on the network segment to which the client is connected. A relay agent

listens to the DHCP server port and receives broadcast messages from DHCP clients.

When the relay agent receives a client message, the relay agent does the following:

1. If the giaddr field in the message contains 0.0.0.0, the relay agent inserts the

address of the network interface on which the message was received into the

giaddr field.

2. It increments the hop count.

3. It appends any relay agent options.

4. It forwards the message to the DHCP servers that were configured by the

network administrator.

CHAPTER 7 Transmitting DHCP Messages86

010 3273 CH07 10/3/02 5:02 PM Page 86

Figure 7.3 shows the original message that is broadcast by the DHCP client and the

message that is forwarded by the relay agent to the DHCP server. In this example,

the DHCP message on network segment 192.168.12.0 is essentially the same as the

message in Figure 7.1. The contents of the message from the relay agent to the

DHCP server illustrate the details of the forwarded message.

Relay Agents 87

Internet

Router

Relay Agent

192.168.11.0

192.168.12.0

192.168.13.0

192.168.14.0

192.168.15.0

dhcpserve

desktop1

Frame: dst=08:00:20:23:62:77

src=08:00:20:A3:99:4C

IP: dst=192.168.11.252

src=192.168.12.254

UDP: dst=67

src=68

DHCP: chaddr=08:00:20:1F:C2:44

ciaddr=0.0.0.0

giaddr=192.168.12.254

yiaddr=0.0.0.0

flags=0

DHCP message

FIGURE 7.3 A DHCP message forwarded from desktop1 to dhcpserve by a relay agent

in a router.

Relay Agent Options

RFC 3046 defines the relay agent information option, which allows relay agents to

add information to a message sent by a DHCP client to a DHCP server. The

relay

agent information option is used to pass additional information related to the

client between the relay agent and the server. This information is encoded as subop-

tions within the

relay agent information option. Several suboptions can be used

to carry specific pieces of information between a relay agent and a server. The

section “

relay agent information” in Chapter 9 defines the relay agent

information option and suboptions in more detail and gives examples of the uses

for the

relay agent information option.

010 3273 CH07 10/3/02 5:02 PM Page 87

Forwarding Destinations

The destination to which a relay agent forwards DHCP messages must be explicitly

configured for the relay agent. Many relay agents can be configured with more than

one forwarding destination. This enables the relay agent to forward separate copies

of the client DHCP message to multiple DHCP servers.

NOTE

Network architects usually configure relay agents to forward client messages using IP unicast.

Thus, the DHCP message from the client is broadcast only over the network segment to

which the client is attached, and it is subsequently delivered directly to the server or servers in

a unicast message. This means that DHCP broadcasts are limited to the networks to which

clients are attached—there are no DHCP broadcasts on the network segment to which the

DHCP server is connected unless there are DHCP clients on that network segment.

Response Delivery

DHCP servers use relay agents to deliver responses to DHCP clients. However, a

DHCP server must explicitly forward DHCP messages through the appropriate relay

agent. To determine how to deliver responses, a server examines the

giaddr field in

the message from the client. If the

giaddr field is set to 0, a relay agent did not

forward the message and the client must be connected to the same network segment

as the server. In this case, the server delivers the message directly to the client. If the

giaddr field is not set to 0, the server sends the response to the IP address in the

giaddr field—the address of the relay agent that originally forwarded the client’s

DHCP message to the server.

Figure 7.4 shows the message the server sent to the relay agent and the message the

relay agent delivered to the client in response to the sample message in Figure 7.3.

Messages from a server to a relay agent are sent to the DHCP server port. When a

relay agent receives a message on the DHCP server port that has the

op field set to

BOOTREPLY, it forwards that message to the appropriate client. The relay agent

forwards the server message to the client on the network segment identified by the

address in the

giaddr field. Because this field contains the IP address of the interface

on which the client’s message was originally received, the relay agent can deliver the

response to the client through the same interface. The relay agent must also honor

the broadcast flag and broadcast the response to the client if the broadcast flag is set

CHAPTER 7 Transmitting DHCP Messages88

010 3273 CH07 10/3/02 5:02 PM Page 88

FIGURE 7.4 A response from dhcpserve forwarded by a relay agent in a router to

desktop1.

Multiple Relay Agents

A DHCP message can be forwarded through more than one relay agent. In this case,

the second relay agent finds that the

giaddr field in the message already contains

the address of the first relay agent. If a relay agent receives a DHCP message with a

nonzero

giaddr field, it forwards the message as usual but does not modify the

contents of the

giaddr field. When a DHCP server receives a message that has been

forwarded by multiple relay agents, the

giaddr field contains the address of the relay

agent that first received the message. The server sends its response directly to the

address specified in the

giaddr field, bypassing the intermediate relay agents.

NOTE

RFC 3046 specifically prohibits any relay agent except the first from adding a relay agent

information

option. Network administrators at sites that use the relay agent information

option should be sure that only the first relay agent in a relay agent chain needs to add a

relay agent information option.

Relay Agents 89

Internet

Router

Relay Agent

192.168.11.0

192.168.12.0

192.168.13.0

192.168.14.0

192.168.15.0

dhcpserve

desktop1

Frame: dst=08:00:20:A3:99:4C

src=08:00:20:23:62:77

IP: dst=192.168.12.254

src=192.168.11.252

UDP: dst=68

src=67

DHCP: chaddr=08:00:20:1F:C2:44

ciaddr=0.0.0.0

giaddr=192.168.12.254

yiaddr=192.168.12.25

flags=0

DHCP message

010 3273 CH07 10/3/02 5:02 PM Page 89

Relay Agent Implementation

A relay agent does not have to keep track of information about specific DHCP

messages it forwards. However, it must be configured with the address or addresses to

which the client messages should be forwarded. All the other information the relay

agent needs is contained in the DHCP message, which means the relay agent can be

a stateless device. A relay agent is therefore simple to implement, doesn’t consume

many resources, and can support any number of DHCP clients without scaling

problems.

Most commercial routers provide a relay agent function; although it is not required

that a router perform this function, relay agents in dedicated routers are the most

common configuration.

Reliable Delivery of DHCP Messages

Because UDP does not guarantee delivery, DHCP provides for reliable delivery. DHCP

clients, not servers, are responsible for managing message delivery. A client uses the

response from a server as an implicit acknowledgment of receipt of the original

message from the client. If the client does not receive a response to a message, the

client retransmits the message as necessary until it does receive a response, or until it

decides that no server is responding to DHCP messages.

The DHCP specification defines the amount of time a client must wait before

retransmitting a message. The client waits 4 seconds before the first retransmission.

It then doubles the waiting time between retransmissions, up to a maximum of 64

seconds. The particular client implementation determines how many retransmissions

to send before giving up on the transmission of a message.

NOTE

There is no provision in DHCP for a DHCP server to respond to a DHCPDISCOVER message by

saying “I can’t provide service.” So when a DHCP server is not able to provide service to a

DHCP client, it simply ignores requests from that client. This can happen either because the

DHCP server has no IP addresses to allocate or because it has been configured not to respond

to some clients.

There is one exception to the retransmission rules: The DHCPRELEASE message is never

retransmitted. Because it is an advisory message, the only harm that can come from

it being lost is that the DHCP server will not free up the lease until it has expired.

Reliable delivery of a

DHCPFORCERENEW message, which is initially sent by a server, is

provided by the server. The server retransmits the

DHCPFORCERENEW message,

doubling the retransmission delay to provide exponential backoff, until it receives a

CHAPTER 7 Transmitting DHCP Messages90

010 3273 CH07 10/3/02 5:02 PM Page 90

DHCPREQUEST message from the client. The specific retransmission delays and the

number of times the server should retransmit the

DHCPFORCERENEW message before

giving up are not defined by DHCP.

Reliable delivery of a

DHCPLEASEQUERY message is the responsibility of the original

sender. The server responds to a

DHCPLEASEQUERY message with either a DHCPKNOWN or

DHCPUNKNOWN message. If the sender doesn’t receive a response, it retransmits the

DHCPLEASEQUERY message, using exponential backoff to delay retransmissions.

DHCPFORCERENEW and DHCPLEASEQUERY are relatively new additions to DHCP and not

all clients and servers include code that implements these messages. Clients and

servers that do not have code for

DHCPFORCERENEW and DHCPLEASEQUERY will simply

discard those messages without responding to the sender. Servers and clients sending

DHCPFORCERENEW and DHCPLEASEQUERY messages should take into account that they

might never receive responses from some recipients of these messages and compen-

sate by reducing the number and frequency of retransmissions.

Avoiding Message Collisions

Under some circumstances, a DHCP server may receive incoming messages faster

than it can respond to them. It is easy to imagine a scenario in which this might

happen: For example, if power fails in a building, then when the power comes back

on, all the computers in that building might restart at the same time. Computers

that have DHCP clients initiate their DHCP protocol exchanges at almost the same

time. If a network segment has many identical or similar machines, many messages

will be delivered to a server at once.

DHCP includes two mechanisms to decrease the likelihood of overloading a server

with messages from clients. First, a client is required to delay its initial DHCP

message by a random time between 0 and 10 seconds. Second, a DHCP client adjusts

the delay time (in seconds) between retransmissions of a message with a random

value in the range of –1 to +1 to avoid synchronization with other clients.

Transaction IDs

A DHCP client inserts a 32-bit identification number, or transaction ID, in the xid

field of every DHCP message. The DHCP specification gives the client significant

freedom in choosing transaction IDs; the goal is to minimize the chance that two

DHCP clients will use the same transaction ID simultaneously. The client can reuse

the same transaction ID when it retransmits a DHCP message, or it can choose a

different transaction ID for retransmissions. Similarly, the client can choose subse-

quent transaction IDs sequentially, starting with an initial random transaction ID, or

it can choose each transaction ID at random.

Reliable Delivery of DHCP Messages 91

010 3273 CH07 10/3/02 5:02 PM Page 91

The server copies the transaction ID from incoming DHCP messages into the corre-

sponding responses. A client then matches the transaction ID in a server response to

the transaction ID from the client’s most recently transmitted message. If the trans-

action IDs match, the client accepts the response to its previous message; otherwise,

the client discards the message and continues waiting for the correct response.

Inappropriate delivery of a server response to a client may occur, for example, if a

client sets the broadcast flag to

1, requesting that responses be broadcast. These

responses are delivered to every DHCP client on the network segment and must be

filtered out by the clients that did not send the original message.

NOTE

The ISC DHCP client and other DHCP clients check the returned client link-layer address and

the contents of the xid field to further reduce the likelihood of a collision.

Other Transmission Methods

A DHCP client uses broadcast and relay agents to send messages to DHCP servers

when the client does not have an IP address. When the client has an address and

knows the address of a DHCP server, it uses unicast and transmits messages directly

to servers through the normal IP datagram delivery service. This section discusses

how DHCP messages are delivered. The use of these messages is discussed in more

detail in Chapter 8, “DHCP Message Exchanges.”

DHCPREQUEST

Messages

DHCP uses DHCPREQUEST messages at four stages of a lease’s lifetime:

• During the initial selection of the lease

•When confirming the validity of an IP address after a restart

•When the lease is renewed at specific points during its lifetime

•When the lease is rebound near the end of its lifetime

When the DHCPREQUEST message is sent during the initial selection phase, it indicates

which lease offer the client has selected and implicitly indicates that addresses

offered by servers the client has not selected may be reclaimed for assignment to

other clients. This

DHCPREQUEST message is broadcast and must use the server iden-

tifier option to indicate which server it has selected. It can also include other

options that specify desired configuration values. The

requested IP address option

must be set to the value of

yiaddr in the DHCPOFFER message from the server.

CHAPTER 7 Transmitting DHCP Messages92

010 3273 CH07 10/3/02 5:02 PM Page 92

This broadcast DHCPREQUEST message can be relayed through DHCP/BOOTP relay

agents. It is important that BOOTP relay agents forward the

DHCPREQUEST message to

the same set of DHCP servers that received the original

DHCPDISCOVER message. To

help ensure that they do, the

DHCPREQUEST message uses the same value that’s in the

DHCP message header’s

secs field and is sent to the limited broadcast IP address.

A DHCP client also broadcasts a DHCPREQUEST message when it restarts or reconnects

to the network, if it still holds a valid lease on an IP address. This DHCPREQUEST

message contains the client’s current IP address, which is to be confirmed by the

DHCP server, but does not include the

server identifier option.

NOTE

Some relay agents take advantage of the ability to use more than one DHCP server to provide

backup reliability and load balancing by selectively forwarding DHCP messages to different

servers. For example, a relay agent might forward messages that have the secs field set to 0

to a primary server and other messages to a backup server. To ensure that messages are

forwarded to the correct server, the client must set the secs field in the DHCPREQUEST message

to the same value used in the DHCPDISCOVER message.

A DHCP client sends a DHCPREQUEST message to request an extension of the client’s

lease on an IP address. The client sends the extension request to the IP address of the

server from which the address was originally obtained (the client gets the server’s IP

address from the

server identifier option when it receives it in a DHCPACK

message). The client uses the client’s own valid IP address as the source address in

the message.

If the server from which the client requests a lease extension has moved to a new

network or is temporarily shut down, the client will not receive a response from the

server. In this case, the client sends a

DHCPREQUEST message to 255.255.255.255.The

message is delivered to every DHCP server that is providing service on the client’s

network segment. Because the client still has a valid IP address at this time, it uses

that address as the source address in the message.

DHCPINFORM

Messages

A client that does not need to obtain an address through DHCP uses the DHCPINFORM

message. Computers with manually configured IP addresses, such as large systems or

mission-critical servers, can use

DHCPINFORM to obtain other network information,

such as the location of print servers, time servers, name servers and so on. The client

can either use unicast to send a message to a server known by the client or use

broadcast to send the message to all available servers. In either case, the client uses

its own IP address as the source address in the message.

Other Transmission Methods 93

010 3273 CH07 10/3/02 5:02 PM Page 93

DHCPRELEASE Messages

Clients also use unicast to deliver DHCPRELEASE messages to the server from which

the address was originally obtained. The client puts the address it is releasing in the

ciaddr field. However, because the DHCP specification specifies that the client termi-

nates its lease on an address when it first transmits the

DHCPRELEASE message, the

server cannot deliver a response to the client, which no longer has a valid IP address.

Thus, servers do not respond to

DHCPRELEASE messages, and clients do not wait for

responses to

DHCPRELEASE messages nor do clients retransmit DHCPRELEASE messages.

DHCPFORCERENEW

Messages

The DHCPFORCERENEW message is the only DHCP message that is sent by the server

without a message being sent by the client. A server can send a

DHCPFORCERENEW

message to any DHCP client that has an IP address assigned to it through DHCP.

Because the client is guaranteed to have an IP address, the server uses the client’s

address as the destination address in a unicast IP datagram.

DHCPLEASEQUERY

Messages

The DHCPLEASEQUERY message is typically sent by a device or an application rather

than from a DHCP client. Because the device or computer on which the requesting

application is running must already have an IP address, the sender transmits the

DHCPLEASEQUERY message to the server in a unicast IP datagram.

Authenticated DHCP Messages

In some situations, network administrators and users might want to reliably identify

the other participants in DHCP message exchanges. For example, a cable system

subscriber might want to be sure that she trusts the DHCP server from which her

computer is obtaining configuration information. The administrator of a wireless

LAN in a university library might want to limit access to the network by restricting

the assignment of IP addresses to computers that have been identified as authorized

to use the university network.

RFC 3118 defines an extension to DHCP through which DHCP clients and servers

can authenticate the identity of other DHCP participants and can verify that the

content of a DHCP message has not been changed during delivery through the

network. Using the authentication mechanisms described in RFC 3118, a client can

verify that a DHCP server can be trusted to provide valid configuration information.

A DHCP server can use the mechanisms in RFC 3118 to decide whether a request for

DHCP information comes from a client that is authorized to use the network.

CHAPTER 7 Transmitting DHCP Messages94

010 3273 CH07 10/3/02 5:02 PM Page 94

Protocol Design

The design goals for the authentication mechanism in DHCP are as follows:

•Provide a mechanism through which clients and servers can reliably identify

each other and confirm that the contents of DHCP messages were not altered

while in transit

•Avoid changing the current protocol and maintain backward compatibility

with existing clients, servers, and relay agents

• Allow for multiple authentication mechanisms and algorithms

• Allow for automated selection of authentication tokens

•Minimize manual configuration of DHCP clients

The authentication mechanism and the

authentication option are a framework for

the definition of multiple authentication protocols. The

authentication option

carries an identification of the protocol and the algorithm used within the option.

The authentication mechanism also includes additional information to prevent

spoofing of identities through replay of authenticated DHCP messages.

RFC 3118 defines two authentication mechanisms: a simple plain-text token that is

used to identify clients and servers and a keyed-hashing technique that is based on

Hashed Message Authentication Code (HMAC; see RFC 2104). These two authentication

mechanisms use the same format for the

authentication option, as shown in

Figure 7.5.

Authenticated DHCP Messages 95

lengthcode algorithmprotocol

replay detection

0781518232431

replay detection (continued)

authentication information

rdm

replay det.

(continued)

FIGURE 7.5 The format of the DHCP authentication option.

The difference between the two mechanisms is in the contents of the

authentica-

tion information field. The fields in the authentication option are described in

Table 7.1.

010 3273 CH07 10/3/02 5:02 PM Page 95