Dynamic Host Configuration Protocol

The Reverse Address Resolution Protocol (RARP) was defined in RFC 903 in 1984 for the configuration of simple devices, such as diskless workstations, with a suitable IP address. Acting in the data link layer it made implementation difficult in many server platforms. It required that a server be present on each individual network link. RARP was superseded by the Bootstrap Protocol (BOOTP) defined in RFC 951 in September 1985. This introduced the concept of a relay agent, which allowed the forwarding of BOOTP packets across networks, allowing one central BOOTP server to serve hosts on many IP subnets.[3]

DHCP is based on BOOTP, but can dynamically allocate IP addresses from a pool and reclaim them when they are no longer in use. It can also be used to deliver a wide range of extra configuration parameters to IP clients, including platform-specific parameters.[4] DHCP was first defined in RFC 1531 in October 1993, but due to errors in the editorial process was almost immediately reissued as RFC 1541.

Four years later the DHCPINFORM message type[5] and other small changes were added by RFC 2131, which as of 2021 remains the core of the standard for IPv4 networks, with updates in RFC 3396, RFC 4361, RFC 5494, and RFC 6842.[6]

DHCPv6 was initially described by RFC 3315 in 2003. After updates by many subsequent RFCs,[7] it was replaced with RFC 8415, which merged in prefix delegation, and stateless address autoconfiguration.

Internet Protocol (IP) defines how devices communicate within and across local networks on the Internet. A DHCP server can manage IP settings for devices on its local network, e.g., by assigning IP addresses to those devices automatically and dynamically.

DHCP operates based on the client–server model. When a computer or other device connects to a network, the DHCP client software sends a DHCP broadcast query requesting the necessary information. Any DHCP server on the network may service the request. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, and time servers. On receiving a DHCP request, the DHCP server may respond with specific information for each client, as previously configured by an administrator, or with a specific address and any other information valid for the entire network and for the time period for which the allocation (lease) is valid. A DHCP client typically queries for this information immediately after booting, and periodically thereafter before the expiration of the information. When a DHCP client refreshes an assignment, it initially requests the same parameter values, but the DHCP server may assign a new address based on the assignment policies set by administrators.

On large networks that consist of multiple links, a single DHCP server may service the entire network when aided by DHCP relay agents located on the interconnecting routers. Such agents relay messages between DHCP clients and DHCP servers located on different subnets.

Depending on implementation, the DHCP server may have three methods of allocating IP addresses:

Dynamic allocation

A network administrator reserves a range of IP addresses for DHCP, and each DHCP client on the LAN is configured to request an IP address from the DHCP server during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim and then reallocate IP addresses that are not renewed.

Automatic allocation

The DHCP server permanently assigns an IP address to a requesting client from a range defined by an administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had.

Manual allocation

This method is also variously called static DHCP allocation, fixed address allocation, reservation, and MAC/IP address binding. An administrator maps a unique identifier (a client id or MAC address) for each client to an IP address, which is offered to the requesting client. DHCP servers may be configured to fall back to other methods if this fails.

DHCP services are used for Internet Protocol version 4 (IPv4) and IPv6. The details of the protocol for IPv4 and IPv6 differ sufficiently that they may be considered separate protocols.[8] For the IPv6 operation, devices may alternatively use stateless address autoconfiguration. IPv6 hosts may also use link-local addressing to achieve operations restricted to the local network link.

An illustration of a typical non-renewing DHCP session; each message may be either a broadcast or a unicast, depending on the DHCP client capabilities.[9]

The DHCP employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the bootstrap protocol (BOOTP). UDP port number 67 is the port used by the server, and UDP port number 68 is used by the client.

DHCP operations fall into four phases: server discovery, IP lease offer, IP lease request, and IP lease acknowledgement. These stages are often abbreviated as DORA for discovery, offer, request, and acknowledgement.

The DHCP operation begins with clients broadcasting a request. If the client and server are in different Broadcast Domains, a DHCP Helper or DHCP Relay Agent may be used. Clients requesting renewal of an existing lease may communicate directly via UDP unicast, since the client already has an established IP address at that point. Additionally, there is a BROADCAST flag (1 bit in 2 byte flags field, where all other bits are reserved and so are set to 0) the client can use to indicate in which way (broadcast or unicast) it can receive the DHCPOFFER: 0x8000 for broadcast, 0x0000 for unicast.[9] Usually, the DHCPOFFER is sent through unicast. For those hosts which cannot accept unicast packets before IP addresses are configured, this flag can be used to work around this issue.

A DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the available DHCP options defined by Internet Assigned Numbers Authority (IANA) - DHCP and BOOTP PARAMETERS.[12]

A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server. In Unix-like systems this client-level refinement typically takes place according to the values in the configuration file /etc/dhclient.conf.

Options are octet strings of varying length. This is called Type–length–value encoding. The first octet is the option code, the second octet is the number of following octets and the remaining octets are code dependent. For example, the DHCP message-type option for an offer would appear as 0x35, 0x01, 0x02, where 0x35 is code 53 for "DHCP message type", 0x01 means one octet follows and 0x02 is the value of "offer".

The following tables list the available DHCP options, as listed in RFC 2132[13] and IANA registry.[12]

In small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP servers. However, DHCP servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with a DHCP server not on the same subnet, as the client's broadcast can only be received on its own subnet.

In order to allow DHCP clients on subnets not directly served by DHCP servers to communicate with DHCP servers, DHCP relay agents can be installed on these subnets. A DHCP relay agent runs on a network device, capable of routing between the client's subnet and the subnet of the DHCP server. The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using unicast. The IP addresses of the DHCP servers are manually configured in the relay agent. The relay agent stores its own IP address, from the interface on which it has received the client's broadcast, in the GIADDR field of the DHCP packet. The DHCP server uses the GIADDR-value to determine the subnet, and subsequently the corresponding address pool, from which to allocate an IP address. When the DHCP server replies to the client, it sends the reply to the GIADDR-address, again using unicast. The relay agent then retransmits the response on the local network, using unicast (in most cases) to the newly reserved IP address, in an ethernet frame directed to the client's MAC address. The client should accept the packet as its own, even when that IP address is not yet set on the interface.[10]^: 25 Directly after processing the packet, the client sets the IP address on its interface and is ready for regular IP communication, directly thereafter.

If the client's implementation of the IP stack does not accept unicast packets when it has no IP address yet, the client may set the broadcast bit in the FLAGS field when sending a DHCPDISCOVER packet. The relay agent will use the 255.255.255.255 broadcast IP address (and the clients MAC address) to inform the client of the server's DHCPOFFER.

The communication between the relay agent and the DHCP server typically uses both a source and destination UDP port of 67.

A simplified DHCP client state-transition diagram based on figure 5 of RFC 2131.

As described in RFC 2131,[10]^{: Section 4.4} a DHCP client can receive these messages from a server:

• DHCPOFFER
• DHCPACK
• DHCPNAK

The client moves through DHCP states depending on how the server responds to the messages that the client sends.

The DHCP ensures reliability in several ways: periodic renewal, rebinding,[10]^{: Section 4.4.5} and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to attempt to renew their leases once half the lease interval has expired.[10]^{: Section 4.4.5 Paragraph 3} They do this by sending a unicast DHCPREQUEST message to the DHCP server that granted the original lease. If that server is down or unreachable, it will fail to respond to the DHCPREQUEST. However, in that case the client repeats the DHCPREQUEST from time to time,[10]^{: Section 4.4.5 Paragraph 8}[lower-alpha 2] so if the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it and renew the lease.

If the DHCP server is unreachable for an extended period of time,[10]^{: Section 4.4.5 Paragraph 5} the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it. Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time.

In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A proposal for implementing fault-tolerant DHCP servers was submitted to the Internet Engineering Task Force, but never formalized.[26][lower-alpha 3]

If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease.[10]^{: Section 4.4.5 Paragraph 9} At that time it will restart the DHCP process from the beginning by broadcasting a DHCPDISCOVER message. Since its lease has expired, it will accept any IP address offered to it. Once it has a new IP address (presumably from a different DHCP server) it will once again be able to use the network. However, since its IP address has changed, any ongoing connections will be broken.

The basic methodology of DHCP was developed for networks based on Internet Protocol version 4 (IPv4). Since the development and deployment of IPv6 networks, DHCP has also been used for assigning parameters in such networks, despite the inherent features of IPv6 for stateless address autoconfiguration. The IPv6 version of the protocol is designated as DHCPv6.[27]

The base DHCP does not include any mechanism for authentication.[28] Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:

• Unauthorized DHCP servers providing false information to clients.[29]
• Unauthorized clients gaining access to resources.[29]
• Resource exhaustion attacks from malicious DHCP clients.[29]

Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers (commonly called "rogue DHCP") can be operated on networks, providing incorrect information to DHCP clients.[30] This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity,[31] or as a man-in-the-middle attack.[32] Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[29] an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.[33] This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.[33]

Because the DHCP server has no secure mechanism for authenticating the client, clients can gain unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to other DHCP clients.[30] This also allows DHCP clients to exhaust the DHCP server's store of IP addresses—by presenting new credentials each time it asks for an address, the client can consume all the available IP addresses on a particular network link, preventing other DHCP clients from getting service.[30]

DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension (RFC 3046, usually referred to in the industry by its actual number as Option 82[34][35]) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.[28]

Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. As of 2002, RFC 3118 had not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[36] A 2007 book about DSL technologies remarked that:

there were numerous security vulnerabilities identified against the security measures proposed by RFC 3118. This fact, combined with the introduction of 802.1x, slowed the deployment and take-rate of authenticated DHCP, and it has never been widely deployed.[37]

A 2010 book notes that:

[t]here have been very few implementations of DHCP Authentication. The challenges of key management and processing delays due to hash computation have been deemed too heavy a price to pay for the perceived benefits.[38]

Architectural proposals from 2008 involve authenticating DHCP requests using 802.1x or PANA (both of which transport EAP).[39] An IETF proposal was made for including EAP in DHCP itself, the so-called EAPoDHCP;[40] this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.[41]

• RFC 2131, Dynamic Host Configuration Protocol
• RFC 2132, DHCP Options and BOOTP Vendor Extensions
• RFC 3046, DHCP Relay Agent Information Option
• RFC 3397, Dynamic Host Configuration Protocol (DHCP) Domain Search Option
• RFC 3942, Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
• RFC 4242, Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
• RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
• RFC 4436, Detecting Network Attachment in IPv4 (DNAv4)
• RFC 3442, Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4
• RFC 3203, DHCP reconfigure extension
• RFC 4388, Dynamic Host Configuration Protocol (DHCP) Leasequery
• RFC 6926, DHCPv4 Bulk Leasequery
• RFC 7724, Active DHCPv4 Lease Query

• Media related to Dynamic Host Configuration Protocol (DHCP) at Wikimedia Commons