Droms R. The DHCP handbook

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

FIGURE 6.8 The format of the end option.

Examples of Message Formats

To illustrate the format of DHCP messages, this section uses the example from the

section “Using DHCP to Configure Computers” in Chapter 2 and presents the details

of the

DHCPREQUEST message, sent from the client to the server, and the details of the

DHCPACK message, sent in reply from the server to the client. Although the DHCPRE-

QUEST message does not begin the protocol exchange between client and server (that

is the purpose of the

DHCPDISCOVER message), it is the most frequently observed

DHCP message type.

The DHCPREQUEST Message Format

The client constructs its DHCPREQUEST message with its hardware address in the

chaddr field and its IP address in the requested IP address option. The resulting

message is shown in Figure 6.9.

CHAPTER 6 The Format of DHCP Messages76

255

8, 0, 32, 118, 15, 8

(chaddr)

(htype)

(op)

(hops)

(hlen)

1476309821

(xid)

0781518232431

(secs)

(flags)

(ciaddr)

(yiaddr)

(siaddr)

(giaddr)

(sname)

(file)

99, 130, 83, 99, 53, 1, 3, 50, 4, 192, 168, 12, 25, 255

FIGURE 6.9 An example of a DHCPREQUEST message.

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

In this message, the client has filled in the fields and options shown in Table 6.2.

TABLE 6.2 Fields in the Sample DHCPREQUEST Message

Field or Option Name Value Comments

op 1Amessage from a client

htype 1 Indicates an ethernet address

hlen 6 The length (in bytes) of the link-layer address

hops 0 Indicates that the message has not been

forwarded by relay agents

xid 1476309821 A random number chosen by the client to

identify this request

secs 0 The time elapsed (in seconds) since the client

began sending DHCP requests

flags 0 Indicates that no flags are set

ciaddr 0 (unused in this message)

yiaddr 0 (unused in DHCPREQUEST)

siaddr 0 (unused in DHCPREQUEST)

giaddr 0 Contains the address of the relay agent if the

message was forwarded by a relay agent

chaddr 8:00:20:76:0f:08 The client’s Ethernet address

sname 0 (unused in this message)

file 0 (unused in this message)

DHCP message type 3 A DHCPREQUEST message

requested IP address 192.168.11.25 An address for which the client has a lease

end 255 The end of options in option section

Here is the DHCPREQUEST message, as it is transmitted to the server, in hexadecimal

format:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000 01 01 06 00 57 FE B3 3D 00 00 00 00 00 00 00 00

010 00 00 00 00 00 00 00 00 00 00 00 00 08 00 20 76

020 0F 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

0E0 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63

0F0 35 01 03 32 04 C0 A8 0B 19 FF 00 00 00 00 00 00

The DHCPACK Message Format

In response to the DHCPREQUEST message, the server constructs a DHCPACK message,

which confirms that the client’s IP address is appropriate for the network segment to

which it is attached. In this example, the server also includes other configuration

parameters: the subnet mask, the address of a default router, and the address of a

DNS server. Figure 6.10 illustrates the contents of the

DHCPACK message.

Examples of Message Formats 77

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

FIGURE 6.10 An example of a DHCPACK message.

The fields and options the server sends in the

DHCPACK message shown in Figure 6.10

are shown in Table 6.3.

TABLE 6.3 Fields in the Sample DHCPACK Message

Field or Option Name Value Comments

op 2Amessage from a server

htype 1 Indicates an ethernet address

hlen 6 The length (in bytes) of the hardware

address

hops 0 Indicates that the message has not been

forwarded by relay agents

xid 1476309821 Copied from the client’s DHCPREQUEST

message

secs 0 (unused in DHCPACK)

flags 0 Indicates that no flags are set

ciaddr 0 (unused in DHCPACK)

yiaddr 192.168.11.25 The address that is confirmed by the

server

CHAPTER 6 The Format of DHCP Messages78

8, 0, 32, 118, 15, 8

(chaddr)

(htype)

(op)

(hops)

(hlen)

1476309821

(xid)

0781518232431

(secs)

(flags)

(ciaddr)

192, 168, 12, 25

(yiaddr)

(siaddr)

(giaddr)

(sname)

(file)

99, 130, 83, 99, 53, 1, 5, 1, 4, 255, 255, 255, 0,

3, 4, 192, 168, 12, 254, 6, 4, 192, 168, 11, 253, 255

(options)

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

siaddr 192.168.11.252 The server’s IP address

giaddr 0 (unused in DHCPACK)

chaddr 8:00:20:76:0f:08 The client’s hardware address

sname 0 (unused in DHCPACK)

file 0 (unused in DHCPACK)

DHCP message type 5 This is a DHCPACK message

Server identifier 192.168.11.252 The IP address of the DHCP server

Lease time 2592000 Lease time in seconds (30 days)

subnet mask 255.255.255.0 The subnet mask for the client

router 192.168.11.254 The default router for the client

DNS server 192.168.11.253 The DNS server for the client

Domain name genericstartup.com The default domain name for the client

end 255 The end of the options in the option

section

Here is the DHCPACK message in hexadecimal format:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000 02 01 06 00 57 FE B3 3D 00 00 00 00 00 00 00 00

010 C0 A8 0B 19 C0 A8 0B FC 00 00 00 00 08 00 20 76

020 0f 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

0E0 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63

0F0 35 01 05 36 04 C0 A8 0B FC 33 04 00 27 8D 00 01

100 04 FF FF FF 00 03 04 C0 A8 0B FE 06 04 C0 A8 0B

110 FD 0F 12 67 65 6E 65 72 69 63 73 74 61 72 74 75

120 70 2E 63 6F 6D FF

DHCP MESSAGE FORMAT SPECIAL CASES

A couple of special cases affect the format of options in a DHCP message. The first occurs

when multiple instances of the same option appear in the options area. The motivation for

allowing multiple instances of an option comes from the limitation on the data carried in an

option. Because the size of the data must be specified in a single byte, an option carries, at

most, 255 bytes of data. In order to allow a DHCP server or client to send an option longer

than 255 bytes, multiple instances of any option are allowed in a single message. DHCP spec-

ifies that the data from instances of a single option are concatenated and interpreted as a

single instance of the option. Thus, a list of 70 DNS servers can be split into two DNS server

options, each carrying the addresses of 35 servers in 140 bytes.

Examples of Message Formats 79

TABLE 6.3 Continued

Field or Option Name Value Comments

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

The situation in which long lists of items are carried in an option leads to the second special

case. Suppose the collection of options being sent in a DHCP message exceeds the default

maximum options section size of 312 bytes. In anticipation of this problem, DHCP enables

redefinition of the sname and file fields from the fixed-format section of the DHCP

message to hold options rather than a server name and configuration file name. Using the

two fields from the fixed-format section allows for 192 additional bytes of options, an

increase of more than 60%.

Design Constraints

One might look at the format of a DHCP message and ask, “How did anyone come

up with this format?” In the right situation, Ralph Droms, who is one of the authors

of this book and was part of the initial DHCP design process, might be persuaded to

admit that the DHCP message format is, indeed, arcane and bordering on ugly. The

primary constraint around which the DHCP message format was designed is back-

ward compatibility with BOOTP messages. When the design choices were made (in

1990–1991), some router vendors were including BOOTP relay agents in their prod-

ucts. The DHCP designers retained the original BOOTP format for DHCP in order to

leverage the availability of these BOOTP relay agents and allow for easy DHCP

deployment. To ensure that the BOOTP relay agents would correctly forward DHCP

messages, the BOOTP format was retained. Rather than encode new DHCP functions

in the

op field (which might have caused deployed BOOTP relay agents to reject the

message), the DHCP functions were encoded as options (which BOOTP relay agents

never touch).

DHCP messages differ from BOOTP messages in four important ways:

• DHCP messages include a

flags field, which is in an area defined as “unused”

by the BOOTP specification. The definition of the

flags came about as an engi-

neering solution (or workaround) for certain TCP/IP stacks; Chapter 7 explains

the details of the

flags field.

• DHCP allows the options section (called the vendor extensions field in

BOOTP) to be at least 312 bytes long, whereas BOOTP allows only 64 bytes of

options.

• The

DHCP message type option identifies DHCP messages.

• The sname and file fields in a DHCP message can be used to hold additional

options.

DHCP also retains the format of options, originally defined in RFC 1048, and the

convention of reserving option codes 128–254 for local use. Therefore, a network

architect can safely use the local-use options without conflicting with standard

CHAPTER 6 The Format of DHCP Messages80

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

options, which use option codes 1–127. However, this numbering convention is

becoming problematic because the option codes are being exhausted. When BOOTP

first adopted the convention about a decade ago, only a handful of options existed.

Therefore, reserving only the first 127 codes for globally defined options seemed

appropriate.

NOTE

Although option codes 128–254 are supposed to be reserved for definition and local use by

network administrators, some vendors of DHCP clients use those option codes for options that

are specific to their particular clients. When vendors use option codes 128–254 for their own

clients, they create a potential conflict with local use of those option codes. Rather than using

option codes 128–254 for their clients, vendors should use vendor-specific options, a proce-

dure discussed in more detail in Chapter 8, “DHCP Message Exchanges.”

Summary

DHCP messages include a fixed-format section and a variable-format section. The

DHCP message format is based on the message format used by BOOTP, primarily to

ensure backward compatibility with BOOTP relay agents. Several different DHCP

messages exist, and all share the same format. The fixed-format section of a DHCP

message carries information that identifies the client to the server and conveys some

configuration information from the server to the client. The variable-format section

holds options that carry additional configuration parameters.

The type of DHCP message is determined by the

DHCP message type option. The

presence of this option also differentiates DHCP from BOOTP messages. If a

DHCP/BOOTP format message includes a

DHCP message type option, it is a DHCP

message; otherwise, it is interpreted as a BOOTP message. Other options carry proto-

col stack configuration parameters, the addresses of application servers, and other

configuration information.

Summary 81

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

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

IN THIS CHAPTER

• Using UDP for DHCP

• Relay Agents

• Reliable Delivery of DHCP

Messages

• Other Transmission Methods

• Authenticated DHCP

Messages

Transmitting DHCP

Messages

DHCP clients, servers, and relay agents use UDP ports 67

and 68 when transmitting DHCP messages. Use of these

ports is derived from BOOTP. Port 67 is referred to as

BOOTPS (RFC 1700) or the DHCP server port, and port 68 is

known as BOOTPC or the DHCP client port.

Use of UDP raises an interesting question: How can a

DHCP client use UDP before the client has a valid IP

address? DHCP solves this problem by using the limited

broadcast IP address, 255.255.255.255, as the destination

IP address and the “this host” address, 0.0.0.0, as the

source IP address in any message sent by a DHCP client

that does not have an IP address.

Use of the limited broadcast IP address limits the delivery

of messages from a client to servers that are connected to

the same network segment as the client. DHCP uses relay

agents, often running in routers, to forward broadcast

messages from clients to servers and to forward replies

from servers back to clients.

This chapter explains DHCP message delivery, including

the use of UDP and broadcast, relay agents, and retrans-

mission of lost DHCP messages.

Using UDP for DHCP

The client sends all DHCP messages to UDP port 67 (the

DHCP server port). The client broadcasts messages if it

does not yet have an address. If the client knows the

address of a DHCP server and has an IP address of its own,

it sends DHCP messages directly to the server.

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

CHAPTER 7 Transmitting DHCP Messages84

Broadcast Messages

If the client doesn’t yet have a valid IP address, it broadcasts messages to the limited

broadcast IP address, 255.255.255.255, and to the appropriate link-layer broadcast

address. The client uses port 68 (the DHCP client port) as the UDP source port,

0.0.0.0 as the IP source address, and its own link-layer address as the frame source

address. This use of IP and link-layer addresses complies with RFC 1122.

NOTE

DHCP assumes that every client uses a physical layer and data link layer that together support

broadcast. Use of DHCP to configure DHCP clients that are connected to a network segment

whose physical or data link layer do not support broadcast has been proposed, but standards

have not been developed to date. DHCP servers and relay agents communicate using unicast

datagrams, so this restriction applies only to the network segment to which a DHCP client is

attached.

In the DHCP message header, the client puts its link-layer address in the chaddr field

and sets the

ciaddr field to 0. The ciaddr field is used only if the client has

confirmed that its IP address is usable on its local network. The client also sets the

field to BOOTREQUEST.

Figure 7.1 shows a DHCP message that is broadcast by the client desktop1.

Internet

Router

192.168.11.0

192.168.12.0

192.168.13.0

192.168.14.0

192.168.15.0

dhcpserve

desktop1

Frame: dst=FF:FF:FF:FF:FF:FF

src=08:00:20:1F:C2:44

IP: dst=255.255.255.255

src=0.0.0.0

UDP: dst=67

src=68

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

ciaddr=0.0.0.0

giaddr=0.0.0.0

yiaddr=0.0.0.0

flags=0

DHCP message

FIGURE 7.1 A DHCP message that is broadcast by the client desktop1.

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

Unicast Messages

When the client has a valid IP address, it sends DHCP messages to the DHCP server

by using IP unicast, using its own IP address as the IP source address. The client then

fills in the

chaddr field with its link-layer address and the ciaddr field with its IP

address. For example, a client uses IP unicast when it is extending the lease on an

address.

Server Response Messages

Servers send DHCP messages directly to clients with the following information:

• UDP destination port 68

• UDP source port 67

• The IP destination address set to the client’s IP address

• The link-layer destination address set to the client’s link-layer address

Servers also set the

op field to BOOTREPLY.

Figure 7.2 shows a DHCP message sent by a server in response to the message from

the DHCP client in Figure 7.1.

Using UDP for DHCP 85

Internet

Router

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:1F:C2:44

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

IP: dst=192.168.11.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=0.0.0.0

yiaddr=192.168.11.25

flags=0

DHCP message

FIGURE 7.2 A DHCP message sent by dhcpserve in response to a message from

desktop1.

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