The DHCP protocol is documented in RFC2131, and is used to get the boot time config information, used by the other protocols. DHCP is based on the older BOOTP protocol. The main difference is that a BOOTP packet's data is 64 bytes, and a DHCP packet's data is 312 bytes. This is because the extentions that make BOOTP into DHCP are mostly alot of new options. This is that unlike BOOTP, DHCP is designed to get all of it's parameters through the appropriate options. Intel's PXE extensions add even more options, pushing the total DHCP packet size to 512 bytes.
Another difference is that BOOTP typically assigns static IP addresses, while DHCP assigns an IP address for a temporary time, called a lease. DHCP also provides much more imformation to the client than BOOTP.
There is a specified order of DHCP commands. The sessions starts with a DHCPDISCOVER packet from Nilo to the server. The server then responds with a DHCPOFFFER packet. Nilo responds to this packet with a DHCPREQUEST packet. The server then finishes the sessions with a DHCPACK.
The first packet sent is a DHCPDISCOVER broadcast to look for the server. This DHCP packet contains the following options. Some options must be in all DHCP packets.
This option is used to request that a particular IP address be assigned to Nilo.
This option specifies the name of the client, and is usually "nilo". The name may or may not be qualified with the local domain names.
This option is used by a DHCP client to request values for specified configuration parameters. The list of requested parameters is specified as n octets, where each octet is a valid DHCP option code as defined in this document. The client may list the options in order of preference. The DHCP server is not required to return the options in the requested order, but must try to insert the requested options in the order requested by Nilo
This option is used by DHCP clients to specify their unique identifier. DHCP servers use this value to index their database of address bindings. This value is expected to be unique for all clients in an administrative domain. Identifiers should be treated as opaque objects by DHCP servers. The client identifier may consist of type-value pairs similar to the 'htype'/'chaddr' fields. For instance, it may consist of a hardware type and hardware address. In this case the type field SHOULD be one of the ARP hardware types defined in STD2. A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address (e.g. a fully qualified domain name). For correct identification of clients, each client's client identifier MUST be unique among the client-identifiers used on the subnet to which the client is attached. Vendors and system administrators are responsible for choosing client-identifiers that meet this requirement for uniqueness.