[Previous] [Next] [Contents] [Glossary]

Dynamic Host Configuration Protocol

Message Format

As mentioned earlier, the format of the DHCP messages is based on the format of BOOTP messages in order to keep compatible with BOOTP relay agents and BOOTP clients.

Here is the DHCP message format. The numbers in parentheses indicate the size of each field in octets.

DHCP frame

Description of fields in a DHCP message

FIELD OCTETS DESCRIPTION
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type (e.g., '1' = 10Mb Ethernet)
hlen 1 Hardware address length (e.g. '6' for 10Mb Ethernet)
hops 1 Client sets to zero, optionally used by relay agents when booting via a relay agent.
xid 4 Transaction ID.
A random number chosen by the client, used by the client and server to associate the request message with it's and response.
secs 2 Seconds passed since client began the request process.
Filled in by client.
flags 2 Flags
ciaddr 4 Client IP address.
Filled in by client if it knows it's IP address (from previouse requests or from manual configurations). and can respond to ARP requests.
yiaddr 4 'your' (client) IP address. Server's response to client.
siaddr 4 Server IP address. Address of sending server or of the next server to use in the next bootstrap process step.
giaddr 4 Relay agent IP address, used in booting via a relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name. Null terminated string.
file 128 Boot file name.
Null terminated string; "generic" name or null in request, fully qualified directory-path name in reply.
options var Optional (BOOTP semantics) parameters field.
In real DHCP messages at least one option (message type) must always be present, so this field is never empty.

The options field in a DHCP message

Appart from the small amount of the fields imported from the BOOTP frame format there came a need for a lot more fields, some of them changing from one message to another, others from one subnet to another etc.

That need came first after defining the BOOTP protocol which led to the BOOTP extension mechanism, where the last field in the frame format, the 'vendor extensions' filed was of variable length and could contain the extra information.

DHCP improved this mechanism, changing the field name to 'options' and adding more options.

One way to categorize those options whould be to split them into two groups:

All options begin with a tag octet, which uniquely identifies the option. The next octet is the option length specifier, it's value does not include the two octets specifying the tag and length. The length octet is followed by length octets of data.

All these optins/vendor extensions are defind in RFC 2132, Where they are split to the following groups:

Here are some important DHCP options:

Message Type (a DHCP control).
Specifies the type of the DHCP message in order to be more specific than the originally BOOTP field 'op'.
Has to appear in every DHCP message.

Different message types are used at different stages of the client/server interaction.

Renewal Time Value (a DHCP control).
Specifies the time interval from address assignment until the client attempts to contact the server that originally issued the client's network address before the lease expire.
Parameter Request List (a DHCP control).
A list of valid DHCP option codes. Used by a DHCP client to request values for specified configuration parameters.
Subnet Mask (a Configuration parameter)
Specifies the client's subnet mask.
DNS Option (a Configuration parameter)
Specifies a list of DNS name servers available to the client.

[Previous] [Next] [Contents] [Glossary]

About the authors