Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Searchable, convenient, complete TCP/IP information.
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)
           9  Host Configuration and TCP/IP Host Configuration Protocols (BOOTP and DHCP)
                9  TCP/IP Dynamic Host Configuration Protocol (DHCP)
                     9  DHCP Messaging, Message Types and Formats

Previous Topic/Section
DHCP Message Generation, Addressing, Transport and Retransmission
Previous Page
Pages in Current Topic/Section
1
Next Page
DHCP Options, Option Format and "Option Overloading"
Next Topic/Section

DHCP Message Format

When DHCP was created, its developers had a bit of an issue related to how exactly they should structure DHCP messages. BOOTP was already widely used, and maintaining compatibility between DHCP and BOOTP was an important goal. This meant that DHCP's designers needed to continue using the existing BOOTP message format. However, DHCP has more functionality than BOOTP, and this means more information than can easily be held in the limited BOOTP message format.

This apparent contradiction was resolved in two ways. First, the existing BOOTP message format was maintained for basic functionality, but DHCP clients and servers were programmed to use the BOOTP message fields in slightly different ways. Second, the BOOTP vendor extensions were formalized and became DHCP options, as we'll see in the next two topics. Despite the name “options”, some of these are in fact the additional fields needed for basic DHCP functionality, and are quite mandatory. J

With this dual approach, DHCP devices have access to the extra information they need. Meanwhile, the basic field format is unchanged, which allows DHCP servers to communicate with older BOOTP clients, which ignore the extra DHCP information that doesn't relate to them. See the topic on BOOTP/DHCP interoperability for more.

Table 189 describes the format of DHCP messages, which is also shown in Figure 267. In the table, I have specifically indicated which fields are used in DHCP in a manner similar to how they are used in BOOTP, and which are significantly different.


Table 189: DHCP Message Format

Field Name

Size (bytes)

Description

Op

1

Operation Code: Specifies the general type of message. A value of 1 indicates a request message, while a value of 2 is a reply message.

This code represents the general category of the DHCP message; a client sending a request to a server uses an Op code of 1, while a server replying uses a code of 2. So, for example, a DHCPREQUEST would be a request, while a DHCPACK or DHCPNAK is a reply. The actual specific type of DHCP message is encoded using the
DHCP Message Type option.

HType

1

 

HLen

1

Hardware Address Length: Specifies how long hardware addresses are in this message. For Ethernet or other networks using IEEE 802 MAC addresses, the value is 6. This is also the same as a field in the ARP field format, HLN.

Hops

1

Hops: Set to 0 by a client before transmitting a request and used by relay agents to control the forwarding of BOOTP and/or DHCP messages.

XID

4

Transaction Identifier: A 32-bit identification field generated by the client, to allow it to match up the request with replies received from DHCP servers.

Secs

2

Seconds: In BOOTP this field was vaguely defined and not always used. For DHCP, it is defined as the number of seconds elapsed since a client began an attempt to acquire or renew a lease. This may be used by a busy DHCP server to prioritize replies when multiple client requests are outstanding.

Flags

2

 

CIAddr

4

Client IP Address: The client puts its own current IP address in this field if and only if it has a valid IP address while in the BOUND, RENEWING or REBINDING states; otherwise, it sets the field to 0. The client can only use this field when its address is actually valid and usable, not during the process of acquiring an address. Specifically, the client does not use this field to request a particular IP address in a lease; it uses the Requested IP Address DHCP option.

YIAddr

4

“Your” IP Address: The IP address that the server is assigning to the client.

SIAddr

4

Server IP Address: The meaning of this field is slightly changed in DHCP. In BOOTP, it is the IP address of the BOOTP server sending a BOOTREPLY message. In DHCP, it is the address of the server that the client should use for the next step in the bootstrap process, which may or may not be the server sending this reply.

The sending server always includes its own IP address in the Server Identifier
DHCP option.

GIAddr

4

Gateway IP Address: This field is used just as it is in BOOTP, to route BOOTP messages when BOOTP relay agents are involved to facilitate the communication of BOOTP requests and replies between a client and a server on different subnets or networks. See the topic on DHCP relaying. As with BOOTP, this field is not used by clients and does not represent the server giving the client the address of a default router (that's done using the Router DHCP option).

CHAddr

16

Client Hardware Address: The hardware (layer two) address of the client, which is used for identification and communication.

SName

64

Server Name: The server sending a DHCPOFFER or DHCPACK message may optionally put its name in this field. This can be a simple text “nickname” or a fully-qualified DNS domain name (such as “myserver.organization.org”).

This field may also be used to carry DHCP options, using the
“option overload” feature, indicated by the value of the DHCP Option Overload option.

File

128

Boot Filename: Optionally used by a client to request a particular type of boot file in a DHCPDISCOVER message. Used by a server in a DHCPOFFER to fully specify a boot file directory path and filename.

This field may also be used to carry DHCP options, using the
“option overload” feature, indicated by the value of the DHCP Option Overload option.

Options

Variable

Options: Holds DHCP options, including several parameters required for basic DHCP operation. Note that this field was fixed at 64 bytes in length in BOOTP but is variable in length in DHCP. See the next two topics for more information. This field may be used by both client and server.



Figure 267: DHCP Message Format

 


The DHCP standard does not specify the details of how DHCP messages are encapsulated within UDP. I would assume that due to the other similarities to BOOTP, DHCP maintains BOOTP's optional use of message checksums. It also most likely assumes that messages will not be fragmented (sent with the Do Not Fragment bit set to 1 in the IP datagram). This is to allow BOOTP clients to avoid the complexity of reassembling fragmented messages.

I should point out, however, that DHCP messages are variable in length, compared to BOOTP's fixed message size. This was done by changing BOOTP's 64-byte Vend field into the variable-length Options field. DHCP relies on options much more than BOOTP does, and a device must be capable of accepting a message with an Options field at least 312 bytes in length. The SName and File fields may also be used to carry options, as described in the next topic.


Previous Topic/Section
DHCP Message Generation, Addressing, Transport and Retransmission
Previous Page
Pages in Current Topic/Section
1
Next Page
DHCP Options, Option Format and "Option Overloading"
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005

© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.