The Dynamic Host Configuration Protocol (DHCP) is an autoconfiguration protocol used on IP networks. Computers that are connected to IP networks must be configured before they can communicate with other computers on the network. DHCP allows a computer to be configured automatically, eliminating the need for intervention by a network administrator. It also provides a central database for keeping track of computers that have been connected to the network. This prevents two computers from accidentally being configured with the same IP address.
In the absence of DHCP, hosts may be manually configured with an IP address. Alternatively IPv6 hosts may use stateless address autoconfiguration to generate an IP address. IPv4 hosts may use link-local addressing to achieve limited local connectivity.
In addition to IP addresses, DHCP also provides other configuration information, particularly the IP addresses of local caching DNS resolvers. Hosts that do not use DHCP for address configuration may still use it to obtain other configuration information.
There are two versions of DHCP, one for IPv4 and one for IPv6. While both versions bear the same name and perform much the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they can be considered separate protocols.[1]
| Internet Protocol Suite | |
|---|---|
| Application Layer | |
|
BGP · DHCP · DNS · FTP · HTTP · IMAP · IRC · LDAP · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · SIP · SMTP · SNMP · SSH · Telnet · TLS/SSL · XMPP · (more) |
|
| Transport Layer | |
| (more) | |
| Internet Layer | |
| (more) | |
| Link Layer | |
| ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, DSL, ISDN, FDDI) · (more) | |
Contents |
DHCP was first defined as a standards track protocol in RFC 1531 in October 1993, as an extension to the Bootstrap Protocol (BOOTP). The motivation for extending BOOTP was that BOOTP required manual intervention to add configuration information for each client, and did not provide a mechanism for reclaiming disused IP addresses.
Much work was done to clarify the protocol as it gained popularity, and in 1997 RFC 2131 was released, and remains the standard for IPv4 networks. DHCPv6 is documented in RFC 3315. RFC 3633 added a DHCPv6 mechanism for prefix delegation. DHCPv6 was further extended to provide configuration information to clients configured using stateless address autoconfiguration in RFC 3736.
The BOOTP protocol itself was first defined in RFC 951 as a replacement for the Reverse Address Resolution Protocol RARP. The primary motivation for replacing RARP with BOOTP was that RARP was a data link layer protocol. This made implementation difficult on many server platforms, and required that a server be present on each individual network link. BOOTP introduced the innovation of a relay agent, which allowed BOOTP packets to be forwarded off of the local network using standard IP routing, so that one central BOOTP server could serve hosts on many IP subnets.[2]
Dynamic Host Configuration Protocol automates network-parameter assignment to network devices from one or more DHCP servers. Even in small networks, DHCP is useful because it makes it easy to add new machines to the network.
When a DHCP-configured client (a computer or any other network-aware device) connects to a network, the DHCP client sends a broadcast query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, other servers such as time servers, and so forth. On receiving a valid request, the server assigns the computer an IP address, a lease (length of time the allocation is valid), and other IP configuration parameters, such as the subnet mask and the default gateway. The query is typically initiated immediately after booting, and must complete before the client can initiate IP-based communication with other hosts.
Depending on implementation, the DHCP server may have three methods of allocating IP-addresses:
DHCP uses the same two ports assigned by IANA for BOOTP: UDP port 67 for sending data to the server, and UDP port 68 for data to the client. DHCP communications are connectionless in nature.
DHCP operations fall into four basic phases: IP discovery, IP lease offer, IP request, and IP lease acknowledgement.
Where a DHCP client and server are on the same subnet, they will communicate via UDP broadcasts. When the client and server are on different subnets, IP discovery and IP request messages are sent via UDP broadcasts, but IP lease offer and IP lease acknowledgement messages are sent via unicast.
The client broadcasts messages on the physical subnet to discover available DHCP servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server from a different subnet. This client-implementation creates a User Datagram Protocol (UDP) packet with the broadcast destination of 255.255.255.255 or the specific subnet broadcast address.
A DHCP client can also request its last-known IP address (in the example below, 192.168.1.100). If the client remains connected to a network for which this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP address immediately. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to give up on the request and ask for a new IP address.
| UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67 |
|||
| OP | HTYPE | HLEN | HOPS |
|---|---|---|---|
| 0x01 | 0x01 | 0x06 | 0x00 |
| XID | |||
| 0x3903F326 | |||
| SECS | FLAGS | ||
| 0x0000 | 0x0000 | ||
| CIADDR | |||
| 0x00000000 | |||
| YIADDR | |||
| 0x00000000 | |||
| SIADDR | |||
| 0x00000000 | |||
| GIADDR | |||
| 0x00000000 | |||
| CHADDR | |||
| 0x00053C04 | |||
| 0x8D590000 | |||
| 0x00000000 | |||
| 0x00000000 | |||
| 192 octets of 0's. BOOTP legacy | |||
| Magic Cookie | |||
| 0x63825363 | |||
| DHCP Options | |||
| DHCP option 53: DHCP Discover | |||
| DHCP option 50: 192.168.1.100 requested | |||
| DHCP option 55: Parameter Request List:
Request Subnet Mask (1), Router (3), Domain Name (15), Domain Name Server (6) |
|||
When a DHCP server receives an IP lease request from a client, it reserves an IP address for the client and extends an IP lease offer by sending a DHCPOFFER message to the client. This message contains the client's MAC address, the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration based on the client's hardware address as specified in the CHADDR (Client Hardware Address) field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR (Your IP Address) field.
| UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68 |
||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x02 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR | ||||
| 0x00000000 | ||||
| YIADDR | ||||
| 0xC0A80164 | ||||
| SIADDR | ||||
| 0xC0A80101 | ||||
| GIADDR | ||||
| 0x00000000 | ||||
| CHADDR | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0's. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| DHCP option 53: DHCP Offer | ||||
| DHCP option 1: 255.255.255.0 subnet mask | ||||
| DHCP option 3: 192.168.1.1 router | ||||
| DHCP option 51: 86400s (1 day) IP lease time | ||||
| DHCP option 54: 192.168.1.1 DHCP server | ||||
| DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18 | ||||
A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer and broadcast a DHCP request message. Based on the Transaction ID field in the request, servers are informed whose offer the client has accepted. When other DHCP servers receive this message, they withdraw any offers that they might have made to the client and return the offered address to the pool of available addresses. The DHCP request message is broadcast, instead of being unicast to a particular DHCP server, because the DHCP client has still not received an IP address. Also, this way one message can let all other DHCP servers know that another server will be supplying the IP address without missing any of the servers with a series of unicast messages.
| UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67 |
||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x01 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR | ||||
| 0x00000000 | ||||
| YIADDR | ||||
| 0xC0A80164 | ||||
| SIADDR | ||||
| 0xC0A80101 | ||||
| GIADDR | ||||
| 0x00000000 | ||||
| CHADDR | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0's. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| DHCP option 53: DHCP Request | ||||
| DHCP option 50: 192.168.1.100 requested | ||||
| DHCP option 54: 192.168.1.1 DHCP server. | ||||
When the DHCP server receives the DHCPREQUEST message from the client, the configuration process enters its final phase. The acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the IP configuration process is completed.
The protocol expects the DHCP client to configure its network interface with the negotiated parameters.
| UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68 |
||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x02 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR (Client IP Address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP Address) | ||||
| 0xC0A80164 | ||||
| SIADDR (Server IP Address) | ||||
| 0xC0A80101 | ||||
| GIADDR (Gateway IP Address switched by relay) | ||||
| 0x00000000 | ||||
| CHADDR (Client Hardware Address) | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0's. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| DHCP option 53: DHCP ACK | ||||
| DHCP option 1: 255.255.255.0 subnet mask | ||||
| DHCP option 3: 192.168.1.1 router | ||||
| DHCP option 51: 86400s (1 day) IP lease time | ||||
| DHCP option 54: 192.168.1.1 DHCP server | ||||
| DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18 | ||||
After the client obtains an IP address, the client may use the Address Resolution Protocol (ARP) to prevent IP conflicts caused by overlapping address pools of DHCP servers.
A DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request repeat data for a particular application. For example, browsers use DHCP Inform to obtain web proxy settings via WPAD. Such queries do not cause the DHCP server to refresh the IP expiry time in its database.
The client sends a request to the DHCP server to release the DHCP information and the client deactivates its IP address. As client devices usually do not know when users may unplug them from the network, the protocol does not mandate the sending of DHCP Release.
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.
A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server.[3]
An option exists to identify the vendor and functionality of a DHCP client. The information is a variable-length string of characters or octets which has a meaning specified by the vendor of the DHCP client. One method that a DHCP client can utilize to communicate to the server that it is using a certain type of hardware or firmware is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60). This method allows a DHCP server to differentiate between the two kinds of client machines and process the requests from the two types of modems appropriately. Some types of set-top boxes also set the VCI (Option 60) to inform the DHCP server about the hardware type and functionality of the device. The value that this option is set to give the DHCP server a hint about any required extra information that this client needs in a DHCP response.
In small networks DHCP typically uses broadcasts. However, in some circumstances, unicast addresses will be used, for example: when networks have a single DHCP server that provides IP addresses for multiple subnets. When a router for such a subnet receives a DHCP broadcast, it converts it to unicast (with a destination MAC/IP address of the configured DHCP server, source MAC/IP of the router itself). The GIADDR field of this modified request is populated with the IP address of the router interface on which it received the original DHCP request. The DHCP server uses the GIADDR field to identify the subnet of the originating device in order to select an IP address from the correct pool. The DHCP server then sends the DHCP OFFER back to the router via unicast. The router then converts the DHCP OFFER back to a broadcast, sent out on the interface of the original device.
A standard for implementing fault-tolerant DHCP servers has been discussed by the Internet Engineering Task Force,[4] but the draft standard has expired. The draft standard proposed redundant servers, one primary and one backup. The backup server tracks the IP address allocations made by the primary and takes over if the primary fails.
The base DHCP protocol does not include any mechanism for authentication.[5] Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:
Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers can be operated on networks, providing incorrect information to DHCP clients. This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity, or as a man-in-the-middle attack. Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers[6], 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. 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.
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. 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.
DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension (RFC 3046) 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.[5]
Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. Unfortunately RFC 3118 has not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[7]
/etc/dhclient.conf configuration file.