The TCP/IP Guide - 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.

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.

Please Whitelist This Site?