4. The Dynamic Host Configuration Protocol

The following is an overview of the Dynamic Host Configuration Protocol (DHCP), and how dhcp-agent deals with some of the deficiences of the protocol.

DHCP is based on the Bootstrap Protocol (BOOTP). It provides a mechanism whereby configuration parameters can be distributed from a central repository, a server or set of servers, to individual hosts, which are running a DHCP client.

The protocol uses leases to pass configuration parameters between the server and client. The term "lease" is used because the parameters expire. Prior to lease expiration the client attempts to renew.

A DHCP client and server communicate via a set of primitive messages which ideally allow the acquisition of leases to occur despite the fact that the client does not have an initialized IP stack. This is done by broadcasting IP datagrams, and later reverting to unicasting when the client has acquired an IP address. Additionally, the User Datagram Protocol (UDP) is used for DHCP which makes writing an ad-hoc IP stack in the client easier.

The client begins by broadcasting a DHCP DISCOVER message to discover what leases are available to it. The client can send a parameter request list in its DHCP DISCOVER message which would request specific configuration parameters to be offered back to it. It may also send a message with no such list if it is not particular about the options it wants to receive.

The DHCP servers which see the DHCP DISCOVER broadcast back the next lease which is available via DHCP OFFER message which, ideally, contains all the configuration parameters the client explicitly requested, or all the configuration parameters the server has been configured ot pass if the client did not request a specific list.

Unfortunately, RFC2131 leaves some ambiguity as to whether or not the server should only send specific options requested in the parameter request list, or all options it has been configured with. The dhcp-agent client can be configured to request specific options, require that specific options are available in a response, and configure only a set of specific options. This is a valuable feature to get around uncooperative servers, or very generous servers. See section 11. Configuring dhcp-client.

Once the client receives an offer for a suitable lease it responds with a DHCP REQUEST which includes a server identifier refering to whichever server the client has accepted the lease from. The server then responds with a DHCP ACK, or a DHCP NACK, acknowledging or retracting the offer, respectively.

If the client receives an acknowledgement it configures its host with the values passed. Among the values passed is the lease expiry time expressed in seconds. Additionally a "renew" and "rebind" time can also be passed from the server. The expiry, renew, and rebind values are used to setup three timers. The first timer is the renew timer when the client attempts to renew its lease by requesting it again from the server it received the lease from. The rebind timer is whenx the client attempts to renew its lease from broadcasting to any server that can hear it. Finally, once the lease expires the client will unconfigure the settings and attempt to discover a new lease.

Unfortunately, more ambigiouty exists with RFC2131. There is no mention of what the client should do if it receives no expiry time. dhcp-agent's client will assume an infinite time and never give up its lease unless explicitly killed. See section 6. Invoking dhcp-client.

There is no mention of what the client should do if the lease received during a rebind or renew differs from its own lease, except that the client should notify the user. dhcp-agent allows additional rebind and renew hooks in its sysconf script to handle this. See section 15. Extending dhcp-client.

And so the circle of life in the DHCP UNIXverse continues on. Kind of.

[ It should be noted that this protocol overview is client centric. More will be added in the future when the server is closer to completion. ]