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.
|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.|
A random number chosen by the client, used by the client and server to associate the request message with it's and response.
passed since client began the request
Filled in by client.
|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)
In real DHCP messages at least one option (message type) must always be present, so this field is never empty.
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:
Different message types are used at different stages of the client/server interaction.
About the authors