Droms R. The DHCP handbook

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

which the computer broadcasts, asks for a response from routers on the network

segment. The second, which routers broadcast, announces that the router on the

network segment is available. A computer uses a router discovered through the

router discovery mechanism as its default router.

A computer can find network services, such as DNS and printers, by using Service

Location Protocol (SLP; see RFC 2165). SLP is configured either with a central server

or as a distributed service. In either case, a computer looking for a particular service

formulates a request for the service and submits the request through SLP. The

response, from either the SLP server or the computers providing the requested

service, returns to the requesting computer information that describes the service

and the address of the computer that is providing the service.

NOTE

Taken together, RARP/DRARP, the ICMP subnet mask and router discovery messages, and SLP

provide most of the important configuration information a TCP/IP host requires. As explained

in Chapter 3, “Configuring the DHCP Server,” a computer needs an IP address, the subnet

mask, the address of at least one default router, and the address of a DNS server before it can

effectively use TCP/IP.

A network administrator might find that DHCP is a better choice than these other protocols

for computer configuration management. Most importantly, DHCP provides all these configu-

ration functions through a single service. A network administrator needs to manage only one

DHCP server, rather than separate RARP/DRARP, ICMP, and SLP servers. Another advantage of

using DHCP is that it includes the leasing mechanism for automated recovery and reliable

reassignment of IP addresses. Finally, DHCP can provide other TCP/IP stack parameters in

addition to an IP address, subnet mask, and default router, and DHCP does not require a

server on every network segment.

The DHCP Client/Server Architecture

In the DHCP client/server model, the clients are the computers that use DHCP

services to obtain IP addresses and parameters. DHCP servers, managed by network

administrators, hand out the configuration information. DHCP clients initiate all

client/server transactions and are responsible for handling all the details of each

transaction, including generating transaction identifiers and retransmitting lost

protocol messages.

The DHCP model of centralized administration came about for at least two reasons:

to minimize client configuration before the client uses DHCP and to give network

administrators full control over the configuration of networked computers. BOOTP

also influenced the architecture and the details of DHCP. The client/server organiza-

tion in DHCP is identical to that in the BOOTP model. The DHCP message formats,

CHAPTER 5 DHCP Client/Server Model66

008 3273 CH05 10/3/02 5:05 PM Page 66

including the fixed-format header area and the individual option formats, are almost

identical to those in BOOTP. DHCP also uses relay agents in the same way as BOOTP,

to forward DHCP messages from clients to servers, avoiding the need for a DHCP or

BOOTP server on every network segment.

NOTE

Compatibility with BOOTP relay agents was the deciding factor in reusing the BOOTP

message formats for DHCP. When DHCP was designed, router vendors were just beginning to

include BOOTP message forwarding in their products. Rather than delay DHCP deployment

until a new type of relay agent was developed and integrated into routers, the DHCWG

decided to retain the BOOTP message format so that DHCP could use the installed base of

BOOTP relay agents.

In one sense, clients are more complicated than servers. Clients must maintain inter-

nal state information and generate the appropriate sequences of messages for

client/server transactions. Servers do not have to maintain protocol state information

for clients (although they must, of course, keep track of the IP address assignments);

they can simply respond whenever they receive a request from the client.

In another sense, servers are more complex than clients. A server must read and

parse a configuration file that describes the network architecture and the local

DHCP policies, and it must store the information about assigned addresses in some

kind of persistent storage, such as a disk file or database. Most importantly, a server

must be implemented carefully so that it responds quickly to client messages.

Summary

DHCP provides hands-off configuration of networked computers through network

messages the computer exchanges with a centralized server. The server manages the

client’s configuration, assigns it an IP address and provides other configuration para-

meters that are specified by the network administrator’s policies.

The client/server model in DHCP assigns all responsibility for initiating transactions

to the client. Servers are essentially stateless and can respond to individual client

messages independently. A server does maintain pertinent information about the

addresses assigned to clients, but it need not track the state of each client as it

obtains and uses its configuration.

Other protocols, including RARP/DRARP, ICMP, and SLP, also provide some of the

services DHCP provides. DHCP has the advantage of providing configuration

management through a single service, which reduces administrative overhead.

Summary 67

008 3273 CH05 10/3/02 5:05 PM Page 67

As this book was written, the working group was completing the definition of several

new functions and options for DHCP, including a protocol through which DHCP

servers can exchange information about clients, coordination of updates to DNS

information with assignment of addresses through DHCP and new options to carry

additional configuration information.

CHAPTER 5 DHCP Client/Server Model68

008 3273 CH05 10/3/02 5:05 PM Page 68

IN THIS CHAPTER

• DHCP Message Format

Overview

• The Fixed-Format Section

• The

options Section

• Examples of Message Formats

• Design Constraints

The Format of DHCP

Messages

DHCP clients and servers communicate by exchanging

messages as described in the protocol specification. All

DHCP messages share a common format, which is

described in this chapter. Future chapters describe how

DHCP messages are transmitted by using UDP and the

specific options that can be carried in a DHCP message.

DHCP was developed from BOOTP (see RFC 951) and uses

a message format that is based on the BOOTP specification.

Because DHCP shares UDP ports 67 and 68 with BOOTP,

DHCP messages include a special option in the

option

field that differentiates them from BOOTP messages.

DHCP Message Format Overview

All DHCP messages include a fixed-format section and a

variable-format section. The fixed-format section consists of

several fields that are the same in every DHCP message.

The variable-format section holds options, which carry

additional configuration parameters. The contents of the

fixed-format section and the format of the variable-format

section vary according to the type of DHCP message.

The fixed-format section is divided into several fields that

carry information such as the following:

• The network and link-layer addresses of the client

• The IP address of the server

• Control information about the message itself

These fields appear in every DHCP message, although not

all fields are used in every type of message.

009 3273 CH06 10/3/02 5:01 PM Page 69

CHAPTER 6 The Format of DHCP Messages70

The type of each DHCP message, as well as other information not defined in the

fixed-format section, is specified by DHCP options in the variable-format section. The

length of each DHCP option, as well as the contents and format of the data in the

option, depends on the definition of that option.

By default, DHCP messages contain 576 or fewer bytes (including the IP and UDP

headers). However, a client can indicate to a server that it is prepared to accept

messages larger than 576 bytes. If the server’s response requires more than 576 bytes

and the server can send a larger message, it might take advantage of the client’s will-

ingness to accept a larger message. In such cases, each message is carried in a single

UDP datagram.

The Fixed-Format Section

The fixed-format , illustrated in Figure 6.1, appears in every DHCP message. In the

figure, each row represents 32 bits of the fixed-format section. Individual fields are

delimited by vertical bars and are labeled with the name of the field. Some of the

larger fields are summarized in the figure, and their lengths are given explicitly. The

fields in the fixed-format section are summarized in Table 6.1.

chaddr

(16 bytes)

htypeop hopshlen

xid

0781518232431

secs flags

ciaddr

yiaddr

siaddr

giaddr

sname

(64 bytes)

file

(128 bytes)

options

(variable)

FIGURE 6.1 The fields in the fixed-format section of a DHCP message.

009 3273 CH06 10/3/02 5:01 PM Page 70

TABLE 6.1 A Summary of the DHCP Message Fields

Field Description

op Message operation code; set to 1 in messages sent by a client and 2 in

messages sent by a server. The two possible values for op are carried forward

from BOOTP for backward compatibility and are sometimes called

BOOTRE-

QUEST

and BOOTREPLY, respectively.

htype Link-layer address type; definitions are taken from the IANA list of ARP hard-

ware types (see RFC 1700). For example, the ethernet type is specified when

htype is set to 1.

hlen Link-layer address length (in bytes); defines the length of hardware address in

the chaddr field.

hops Number of relay agents that have forwarded this message.

xid Transaction identifier; used by clients to match responses from servers with

previously transmitted requests.

secs Elapsed time (in seconds) since the client began the DHCP process.

flags Flags field; the least significant bit, called the broadcast bit, can be set to 1 to

indicate that messages to the client must be broadcast (see the section

“Using the Broadcast Flag” in Chapter 7, “Transmitting DHCP Messages,” for

details).

ciaddr Client’s IP address; set by the client when the client has confirmed that its IP

address is valid.

yiaddr Client’s IP address; set by the server to inform the client of the client’s IP

address (that is, “your” IP address).

siaddr IP address of the next server for the client to use in the configuration process

(for example, the server to contact for TFTP download of an operating

system kernel).

giaddr Relay agent (or gateway) IP address; filled in by the relay agent with the

address of the interface through which DHCP message was received.

chaddr Client’s link-layer address.

sname Name of the next server for client to use in the configuration process.

file Name of the file for the client to request from the next server (for example,

the name of the file that contains the operating system for this client).

The options Section

The options section of a DHCP message carries a sequence of options that convey

additional configuration information between the client and the server. Each option

includes an option code, an option length, and option data, as illustrated in

Figure 6.2. The option code identifies the specific option and the information carried

in the option. The option data is the actual information, and the option length is

the length, in bytes, of the option data field.

The options Section 71

009 3273 CH06 10/3/02 5:01 PM Page 71

FIGURE 6.2 The format of the DHCP message options section.

The first 4 bytes in the

options section define the format of the remainder of the

section. The 4 bytes are set to the decimal values 99, 130, 83, 99 (or 63, 82, 53, 63 in

hexadecimal). These values are referred to as a magic number in the BOOTP specifica-

tion (see RFC 951) and a magic cookie in the DHCP options and BOOTP extensions

(originally defined in RFC 1048 and included in RFC 2132).

The options are stored sequentially in the

options section, without word alignment

or other formatting restrictions. The option data is formatted according to the speci-

fication of the particular option. Examples of data formats include a single IP

address, a list of IP addresses, and a character string.

The remainder of this section describes some examples of options, and the following

section illustrates the use of DHCP message fields and options in messages

exchanged between a client and a server. The options described in the remainder of

this section illustrate some specific option data formats.

OPTION ORIGIN

One of the reasons for using a variable-format section is to allow the definition of new options

as new configuration requirements are defined. Many of the options in RFC 2132 carry the

addresses of servers for applications and services that hadn’t been invented when the first

version of DHCP was published as a standard in 1993. Today, new options are being devel-

oped to adapt DHCP to new technologies, such as DSL and cable modems, and to allow

DHCP to operate with other protocols, such as DNS.

The IETF defines new options through a process described in RFC 2132 and subsequently

modified in RFC 2939 (and also in BCP 29). Each new option (or group of related options) is

described in a separate document and considered for adoption independently. In the review

process, which is based on the IETF standards process for new Internet protocols, a new

option is first defined in an Internet Draft. The draft is then reviewed by the DHC working

group of the IETF and is revised based on input from the working group. After the draft has

passed the working group review, it is submitted to the IESG for acceptance as an Internet

Standard. When the new option is accepted as a standard, it is assigned an option number.

The DHCP message type Option

This section describes the DHCP message type option. DHCP client/server message

exchanges are composed of messages of different types, representing the steps in the

transaction. DHCP messages are often referred to by their type. In the example of

DHCP operation described in Chapter 2, the client first broadcasts a

DHCPDISCOVER

message (or just DISCOVER), and the server replies with a DHCPOFFER message.

CHAPTER 6 The Format of DHCP Messages72

option lengthoption code option data

009 3273 CH06 10/3/02 5:01 PM Page 72

The DHCP message type option, which is included in every DHCP message, identifies

the type of DHCP message being sent. The

DHCP message type option includes the

DHCP message type option code (53), the length of the

data field (1), and the

message type, encoded as a single byte with one of the following values:

Message Type Option Value

DHCPDISCOVER 1

DHCPOFFER 2

DHCPREQUEST 3

DHCPDECLINE 4

DHCPACK 5

DHCPNAK 6

DHCPRELEASE 7

DHCPINFORM 8

DHCPFORCERENEW 9

Figure 6.3 illustrates the format of the DHCP message type option.

The options Section 73

153 Message type

FIGURE 6.3 The format of the DHCP message type option.

NOTE

The DHCP message type option also differentiates DHCP messages from BOOTP messages.

Because DHCP and BOOTP use different messages and semantics, a server must be able to

distinguish between DHCP messages and BOOTP messages so that it can process each appro-

priately. Although DHCP and BOOTP messages share the same format and are delivered to

the same UDP port, only DHCP messages include the DHCP message type option. Thus, a

server can use the presence of the DHCP message type option to determine that a message is

a DHCP message.

The subnet mask Option

The subnet mask option carries the subnet mask that the client should use for its

local network segment. Whereas the client’s IP address appears in the

ciaddr field in

the fixed-format section of the DHCP message, the subnet mask is carried in an

option.

009 3273 CH06 10/3/02 5:01 PM Page 73

NOTE

The allocation of a field in the fixed-format section of the message to the client’s IP address

while using an option for the subnet mask was first employed in BOOTP and carried over to

DHCP. The reason for this design decision is purely historical.

The subnet mask option has an option code of 1, a length of 4, and a subnet

mask encoded as a 32-bit IP address. The subnet mask is encoded in network-byte

ordering, with the most significant byte immediately following the

length field.

Figure 6.4 illustrates the format of the

subnet mask option.

CHAPTER 6 The Format of DHCP Messages74

subnet mask

(in network byte order)

first default

router address

second default

router address

FIGURE 6.4 The format of the DHCP subnet mask option.

The router Option

Before a host can exchange IP datagrams with other hosts on different network

segments, it must know the address of at least one router on its own network

segment. The

router option carries a list of routers, sometimes known as default

routers, which are connected to the same network segment as the client. The

router

option can carry the addresses of more than one router, in order to provide backup

routers that a client can use in case one router fails. The

router option has an

option code of 2, the length (four times the number of routers listed in the option),

and the addresses of the routers.

Figure 6.5 provides an example of the

router option. In the figure, the option

includes two router addresses; more router addresses can be carried if desired.

Although the routers are listed in order of preference, in practice the client can

decide how to choose among the specified routers.

FIGURE 6.5 The format of the

router option.

The DNS server Option

If a host is to support the translation of domain names into IP addresses, it must

know the address of a DNS server to which it can send name-resolution requests.

The

DNS server option carries a list of addresses of DNS servers that the client can

use, in the same format as the

router option. The DNS server option includes the

009 3273 CH06 10/3/02 5:01 PM Page 74

option code, 6, the length (four times the number of DNS server addresses carried in

the option), and the addresses of the DNS servers.

Figure 6.6 shows the format of a

DNS server option that is carrying the address of

one DNS server. Like the

router option, the DNS server option can carry more than

one server address.

The options Section 75

64 DNS server address

50 4 requested IP address

FIGURE 6.6 The format of the DNS server option.

The requested IP address Option

When a DHCP client is allocated an IP address, it must check that address every time

it starts or connects to a network. As described in the example in the section

“Restarting

desktop1” in Chapter 2, the client contacts the DHCP server with a

DHCP message that contains the address assigned to the client. The address is carried

in the

requested IP address option. The format of this option includes the option

code (50), the length (4), and the client’s requested address, as shown in Figure 6.7.

FIGURE 6.7 The format of the

requested IP address option.

The end Option

The end option indicates the end of the options in the options section of a DHCP

message. The

end option is formatted in a slightly different manner from the other

options described in this section; the

end option has a fixed length and includes

neither a

length field nor data. The format, as shown in Figure 6.8, is a single byte

set to the value 255.

NOTE

The end option is not required by the DHCP specification, and it might not appear in the

options section of every DHCP message. DHCP clients and servers must be prepared to

correctly process DHCP messages that do not include an end option.

009 3273 CH06 10/3/02 5:01 PM Page 75