A | B | C | D | E | F | G | H | CH | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.[1]
The technology eliminates the need for individually configuring network devices manually, and consists of two network components, a centrally installed network DHCP server and client instances of the protocol stack on each computer or device. When connected to the network, and periodically thereafter, a client requests a set of parameters from the server using DHCP.
DHCP can be implemented on networks ranging in size from residential networks to large campus networks and regional ISP networks.[2] Many routers and residential gateways have DHCP server capability. Most residential network routers receive a unique IP address within the ISP network. Within a local network, a DHCP server assigns a local IP address to each device.
DHCP services exist for networks running Internet Protocol version 4 (IPv4), as well as version 6 (IPv6). The IPv6 version of the DHCP protocol is commonly called DHCPv6.
History
The Reverse Address Resolution Protocol (RARP) was defined in 1984[3] 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 on 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 September 1985.[4] 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.
DHCP was first defined in October 1993.[5][6] It 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.[7]
Four years later, the DHCPINFORM message type (used for WPAD) and other small changes were added. This definition, from 1997,[8] remains the core of the standard for IPv4 networks.
DHCPv6 was initially defined in 2003.[9] After updates by many subsequent RFCs, its definition was replaced in 2018,[10] where prefix delegation and stateless address autoconfiguration were now merged.
Overview
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.[11]
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 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.[12] 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.
Operation
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). The server listens on UDP port number 67, and the client listens on UDP port number 68.
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.[8] 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.
Discovery
The DHCP client broadcasts a DHCPDISCOVER message on the network subnet using the destination address 255.255.255.255 (limited broadcast) or the specific subnet broadcast address (directed broadcast). A DHCP client may also request an IP address in the DHCPDISCOVER, which the server may take into account when selecting an address to offer.
For example, if HTYPE is set to 1, to specify that the medium used is Ethernet, HLEN is set to 6 because an Ethernet address (MAC address) is 6 octets long. The CHADDR is set to the MAC address used by the client. Some options are set as well.
|
Ethernet: source=sender's MAC; destination=FF:FF:FF:FF:FF:FF | |||
|
IP: source=0.0.0.0; destination=255.255.255.255 | |||
| Octet 0 | Octet 1 | Octet 2 | Octet 3 |
|---|---|---|---|
| OP | HTYPE | HLEN | HOPS |
| 0x01 | 0x01 | 0x06 | 0x00 |
| XID | |||
| 0x3903F326 | |||
| SECS | FLAGS | ||
| 0x0000 | 0x0000 | ||
| CIADDR (Client IP address) | |||
| 0x00000000 | |||
| YIADDR (Your IP address) | |||
| 0x00000000 | |||
| SIADDR (Server IP address) | |||
| 0x00000000 | |||
| GIADDR (Gateway IP address) | |||
| 0x00000000 | |||
| CHADDR (Client hardware address) | |||
| 0x00053C04 | |||
| 0x8D590000 | |||
| 0x00000000 | |||
| 0x00000000 | |||
| 192 octets of 0s, or overflow space for additional options; BOOTP legacy | |||
| Magic cookie | |||
| 0x63825363 | |||
| DHCP options | |||
| 0x350101 53: 1 (DHCP Discover) | |||
| 0x3204c0a80164 50: 192.168.1.100 requested | |||
0x370401030f06 55 (Parameter Request List):
| |||
| 0xff 255 (Endmark) | |||
Offer
 |
When a DHCP server receives a DHCPDISCOVER message from a client, which is an IP address lease request, the DHCP server reserves an IP address for the client and makes a lease offer by sending a DHCPOFFER message to the client. This message contains the client's client id (traditionally a 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 DHCP server may also take notice of the hardware-level MAC address in the underlying transport layer: according to current RFCs the transport layer MAC address may be used if no client ID is provided in the DHCP packet.
The DHCP server determines the configuration based on the client's hardware address as specified in the CHADDR (client hardware address) field. In the following example the server (192.168.1.1) specifies the client's IP address in the YIADDR (your IP address) field.
|
Ethernet: source=sender's MAC; destination=client mac address | ||||
|
IP: source=192.168.1.1; destination=192.168.1.100 | ||||
| Octet 0 | Octet 1 | Octet 2 | Octet 3 | |
|---|---|---|---|---|
| OP | HTYPE | HLEN | HOPS | |
| 0x02 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR (Client IP address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP address) | ||||
| 0xC0A80164 (192.168.1.100) | ||||
| SIADDR (Server IP address) | ||||
| 0xC0A80101 (192.168.1.1) | ||||
| GIADDR (Gateway IP address) | ||||
| 0x00000000 | ||||
| CHADDR (Client hardware address) | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0s; BOOTP legacy. | ||||
| Magic cookie | ||||
| 0x63825363 | ||||
| DHCP options | ||||
| 53: 2 (DHCP Offer) | ||||
| 1 (subnet mask): 255.255.255.0 | ||||
| 3 (Router): 192.168.1.1 | ||||
| 51 (IP address lease time): 86400s (1 day) | ||||
| 54 (DHCP server): 192.168.1.1 | ||||
6 (DNS servers):
| ||||
Request
In response to the DHCP offer, the client replies with a DHCPREQUEST message, broadcast to the server,[a] requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. Before claiming an IP address, the client will broadcast an ARP request, in order to find if there is another host present in the network with the proposed IP address. If there is no reply, this address does not conflict with that of another host, so it is free to be used.
The client must send the server identification option in the DHCPREQUEST message, indicating the server whose offer the client has selected.[8]: Section 3.1, Item 3 When other DHCP servers receive this message, they withdraw any offers that they have made to the client and return their offered IP address to the pool of available addresses.
|
Ethernet: source=sender's MAC; destination=FF:FF:FF:FF:FF:FF | ||||
|
IP: source=0.0.0.0; destination=255.255.255.255;[a] | ||||
| Octet 0 | Octet 1 | Octet 2 | Octet 3 | |
|---|---|---|---|---|
| OP | HTYPE | HLEN | HOPS | |
| 0x03 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR (Client IP address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP address) | ||||
| 0x00000000 | ||||
| SIADDR (Server IP address) | ||||
| 0xC0A80101 (192.168.1.1) | ||||
| GIADDR (Gateway IP address) | ||||
| 0x00000000 | ||||
| CHADDR (Client hardware address) | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0s; BOOTP legacy. | ||||
| Magic cookie | ||||
| 0x63825363 | ||||
| DHCP options | ||||
| 53: 3 (DHCP Request) | ||||
| 50: 192.168.1.100 requested | ||||
| 54 (DHCP server): 192.168.1.1 | ||||
Acknowledgement
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.
After the client obtains an IP address, it should probe the newly received address[8]: sec. 2.2 (e.g. with ARP Address Resolution Protocol) to prevent address conflicts caused by overlapping address pools of DHCP servers. If this probe finds another computer using that address, the computer should send DHCPDECLINE, broadcast, to the server.
|
Ethernet: source=sender's MAC; destination=client's MAC | |||
|
IP: source=192.168.1.1; destination=192.168.1.100 | |||
| Octet 0 | Octet 1 | Octet 2 | Octet 3 |
|---|---|---|---|
| OP | HTYPE | HLEN | HOPS |
| 0x05 | 0x01 | 0x06 | 0x00 |
| XID | |||
| 0x3903F326 | |||
| SECS | FLAGS | ||
| 0x0000 | 0x0000 | ||
| CIADDR (Client IP address) | |||
| 0x00000000 | |||
| YIADDR (Your IP address) | |||
| 0xC0A80164 (192.168.1.100) | |||
| SIADDR (Server IP address) | |||
| 0xC0A80101 (192.168.1.1) | |||
| GIADDR (Gateway IP address switched by relay) | |||
| 0x00000000 | |||
| CHADDR (Client hardware address) | |||
| 0x00053C04 | |||
| 0x8D590000 | |||
| 0x00000000 | |||
| 0x00000000 | |||
| 192 octets of 0s. BOOTP legacy | |||
| Magic cookie | |||
| 0x63825363 | |||
| DHCP options | |||
| 53: 5 (DHCP ACK) | |||
| 1 (subnet mask): 255.255.255.0 | |||
| 3 (Router): 192.168.1.1 | |||
| 51 (IP address lease time): 86400s (1 day) | |||
| 54 (DHCP server): 192.168.1.1 | |||
6 (DNS servers):
| |||
Information
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.
Releasing
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.
Client configuration parameters
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.[13]
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
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.[14][13]
| Code | Name | Length | Notes |
|---|---|---|---|
| 0 | Pad | 0 octets | Can be used to pad other options so that they are aligned to the word boundary; is not followed by length byte |
| 1 | Subnet mask | 4 octets | Client's subnet mask as per RFC 950. If both the subnet mask and the router option (option 3) are included, the subnet mask option must be first. |
| 2 | Time offset | 4 octets | Offset of the client's subnet in seconds from Coordinated Universal Time (UTC). The offset is expressed as a two's complement 32-bit integer. A positive offset indicates a location east of the zero meridian and a negative offset indicates a location west of the zero meridian. |
| 3 | Router | Multiples of 4 octets | Available routers, should be listed in order of preference |
| 4 | Time server | Multiples of 4 octets | Available Time Protocol servers to synchronise with, should be listed in order of preference |
| 5 | Name server | Multiples of 4 octets | Available IEN 116 name servers, should be listed in order of preference |
| 6 | Domain name server | Multiples of 4 octets | Available DNS servers, should be listed in order of preference |
| 7 | Log server | Multiples of 4 octets | Available log servers, should be listed in order of preference |
| 8 | Cookie server | Multiples of 4 octets | Cookie in this case means "fortune cookie" or "quote of the day", a pithy or humorous anecdote often sent as part of a logon process on large computers; it has nothing to do with cookies sent by websites. |