DHCP messages

Dealing with the server

DHCP messages are sent with UDP. Even if it is not very reliable, UDP is enough to carry small packets on a local network and it is also very simple so that it is quite easy to implement on small systems. Therefore, DHCP works is a connectionless protocol.

The client opens a single UDP socket on port 68 for sending and receiving messages; the server opens a single UDP socket on port 67 to send and receive messages from clients.

Format of BOOTP/DHCP messages

DHCP messages have the same format as BOOTP messages, except that the last field may be bigger (numbers between brackets are the sizes of fields in bytes):

• op: set to 1 for a BOOTREQUEST (client request) and 2 for a BOOTREPLY (server reply)
• htype: type of the hardware address (MAC address for instance). See RFC1340.
• hlen: length (in byte) of the hardware address. It is 6 for a MAC address.
• hops: may be used by DHCP relays
• xid: random number chosen by the client and used to identify the client
• secs: time spent (in seconds) between the very first request of the client
• flags: flags
• ciaddr: IP address of the client, if it has one already
• yiaddr: the (future?) IP address of the client
• siaddr: IP address of the next DHCP server to contact
• giaddr: IP address of the DHCP relay when a direct dialogue with the server is not possible
• chaddr: client's hardware address
• sname: optional. Name of the server
• file: name of the file to download and boot with
• options: reserved field to set options (see RFC2132). In a previous RFC, the field was limited (64 bytes for the very first version of BOOTP); now, there is no limitations, but a DHCP client must be able to receive at least 576 bytes. On the other way, a client may ask to limit the length for this field.

Setting options

Giving parameters (hostname) is performed by options. Options are documented in the RFC2132. They all have an identification number; for instance option 15 is used to specify the domain name.

Of course, it is possible to set several options in the same DHCP message; anyway, the last option to be set must be the option 255 (end).

Format of options is this one:

As the option number is coded with 1 byte, there are only 256 possible options. The second byte is used to give the length of the next field; it does not take into account the 2 bytes that come before the data.

Some options such as 255 do not need any data. In this case there is no length or data fields.

The different type of DHCP messages we saw in the previous chapter (DHCPACK...) are options! The option 53 is used to specifiy the type of message a machine is sending: the data field for this option is simply set the identification number of the request (1 for a DHCPDISCOVER...).

The first 4 bytes of the options field must be set with these values: 99, 130, 83 and 99 (decimal values). This sequence is what we call the "magic cookie".

The DHCP client is allowed to impose the maximal length of the options field on the server (option 57). The consequence of such a limitation is that the server may not have enough space to write all the options it wants; to solve this problem, the server is allow to use the available space in the sname and file fields. The client is aware of this with an option 52 set in the usual options field.

 printable format

requests