DHCP

DHCP (Dynamic Host Configuration Protocol) is used for dynamically configuring network information for hosts.

Table of contents

  1. Introduction
  2. Dynamic allocation of IP addressses
    1. Receiving an address
  3. DHCP format
  4. References

Introduction

DHCP has two components: a protocol for sending networking configuration values to hosts, and a mechanism for allocating network addresses to hosts [1, P. 2].

DHCP uses a client-server model. A DHCP server provides configuration to dynamic hosts (clients) [1, P. 2].

The DHCP service provides persistent storage of network parameters for clients, stored as a key-value entry for each client. The protocol messages, sent over UDP, are the interface for accessing configuration parameters from a DHCP server [1, Pp. 11-2].

Dynamic allocation of IP addressses

DHCP has three mechanisms for IP allocation:

  1. Automatic allocation
  2. Dynamic allocation
  3. Manual allocation

With automatic allocation, DHCP assigns a permanent IP address to a client. With dynamic allocation, DHCP assigns an IP address to a client for a specified period of time. With manual allocation, an IP address is assigned by an administrator, and DHCP is simply a way of sending the pre-assigned address to the client [1, P. 3].

A client requests the use of an address for a period of time. This agreement is known as a lease. The allocation system guarantees that the address won’t be allocated to another host during that time. A client can extend its lease by making further requests to the server [1, P. 12].

Receiving an address

A client sends a DHCPDISCOVER message on its physical subnet to receive an address [1, P. 13].

This can be picked up by multiple DHCP servers. A server responds with a DHCPOFFER message that includes an available network address in the yiaddr field [1, P. 13].

The client receives one or more offers from servers. The client chooses a server and sends a DHCPREQUEST message with the server identifier option set to the server it has chosen [1, P. 16].

The servers receive the DHCPREQUEST broadcast from the client. The selected server stores the binding for the client, and replies with a DHCPACK containing the configuration parameters for the client. If the server can no longer fulfill the request from DHCPREQUEST, it returns a DHCPNAK message [1, P. 16].

The client receives the DHCPACK and is considered configured [1, P. 17].

The client can end its lease by sending a DHCPRELEASE message to the server [1, P. 17].

DHCP format

DHCP extends the BOOTP protocol, a precursor to DCHP. It shares the same packet format as BOOTP, except that an unused BOOTP field has become a flags field [2, Pp. 2-3].

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   +-------------------------------+-------------------------------+
   |           secs (2)            |           flags (2)           |
   +-------------------------------+-------------------------------+
   |                          ciaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          yiaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          siaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          giaddr  (4)                          |
   +---------------------------------------------------------------+
   |                                                               |
   |                          chaddr  (16)                         |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   |                          sname   (64)                         |
   +---------------------------------------------------------------+
   |                                                               |
   |                          file    (128)                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                          options (variable)                   |
   +---------------------------------------------------------------+

[1, P. 9]

op is the message operation code, which is either BOOTREQUEST or BOOTREPLY.

htype (hardware address type) is the type of hardware address (1 is Ethernet).

htype is the hardware address length.

xid is the transaction ID, used to identify messages and responses between a client and a server.

secs is the number of seconds since the client began the address acquisition or renewal process.

flags contains the Broadcast flag bit. The Broadcast bit is set by a client that hasn’t yet received an IP address and can’t receive unicast datagrams [1, P. 25].

ciaddr (client IP address) is only filled in if the “client is in BOUND, RENEW or REBINDING state and can respond to ARP requests” [1, P. 10].

yiaddr (your IP address) is the client’s IP address, filled in by the server.

siaddr (server IP address) is the IP address of the server that should be used in the next step of the bootstrap process [1, P. 10].

chaddr is the client hardware address.

sname is the server host name (optional).

options is a parameter field that includes configuration options. For example, the Domain Name Server Field, which contains the IP addresses of domain name servers [3, P. 4].

[1, P. 10]

References

  1. [1] R. Droms, “Dynamic Host Configuration Protocol,” no. 2131. IETF, Mar-1997.
  2. [2] “Bootstrap Protocol,” no. 951. RFC Editor, Sep-1985.
  3. [3] J. K. Reynolds, “BOOTP Vendor Information Extensions,” no. 1497. RFC Editor, Aug-1993.