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]:?Introduction?
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
editThe Reverse Address Resolution Protocol (RARP) was defined in 1984 for the configuration of simple devices, such as diskless workstations, with a suitable IP address.[3] 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,[1] remains the core of the standard for IPv4 networks.
DHCPv6 was initially defined in 2003.[8] After updates by many subsequent RFCs, its definition was replaced in 2018,[9] where prefix delegation and stateless address autoconfiguration were now merged.
Overview
editInternet 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.[10]
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.[11] 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
edit
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.[1] 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
editThe 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.
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Destination MAC (FF:FF:FF:FF:FF:FF) | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | Source MAC (00:05:3C:04:8D:59) | |||||||||||||||||||||||||||||||
| 12 | 96 | EtherType (0x0800) | |||||||||||||||||||||||||||||||
| 16 | 128 | IPv4 packet, containing a UDP PDU with DHCP payload... | |||||||||||||||||||||||||||||||
| 20 | 160 | ||||||||||||||||||||||||||||||||
| ? | ? | ||||||||||||||||||||||||||||||||
| ? | ? | Frame Check Sequence | |||||||||||||||||||||||||||||||
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | IPv4 header start | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | TTL | Protocol (17 UDP) | Header Checksum | |||||||||||||||||||||||||||||
| 12 | 96 | Source Address (0.0.0.0) | |||||||||||||||||||||||||||||||
| 16 | 128 | Destination Address | |||||||||||||||||||||||||||||||
| 20 | 160 | Source Port (68) | Destination Port (67) | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 24 | 192 | Length | Checksum | ||||||||||||||||||||||||||||||
| 28 | 224 | OP (0x01) | HTYPE (0x01) | HLEN (0x06) | HOPS (0x00) | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 32 | 256 | XID (0x3903F326) | |||||||||||||||||||||||||||||||
| 36 | 288 | SECS (0x0000) | FLAGS (0x0000) | ||||||||||||||||||||||||||||||
| 40 | 320 | CIADDR (Client IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 44 | 352 | YIADDR (Your IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 48 | 384 | SIADDR (Server IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 52 | 416 | GIADDR (Gateway IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 56 | 448 | CHADDR (Client Hardware address: 0x00053C04 0x8D590000 0x00000000 0x00000000) | |||||||||||||||||||||||||||||||
| 60 | 480 | ||||||||||||||||||||||||||||||||
| 64 | 512 | ||||||||||||||||||||||||||||||||
| 68 | 544 | ||||||||||||||||||||||||||||||||
| 72 | 576 | 192 octets of 0s, or overflow space for additional options; BOOTP legacy. | |||||||||||||||||||||||||||||||
| ? | ? | ||||||||||||||||||||||||||||||||
| 260 | 2080 | ||||||||||||||||||||||||||||||||
| 264 | 2112 | Magic Cookie (0x63825363) | |||||||||||||||||||||||||||||||
| 268 | 2144 | First option: 0x350101: Option 53 (DHCP Message Type) 1 octet (containing DHCPDISCOVER) | Second option:? | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 272 | 2176 | ?0x3204c0a80164: Option 50 (Request IP address) 4 octets (containing 192.168.1.100) | |||||||||||||||||||||||||||||||
| 276 | 2208 | Third option: 0x370401030f06: Option: 55 (Parameter Request List) 4 octets? | |||||||||||||||||||||||||||||||
| 280 | 2240 | ?PRL cont... | ff | ||||||||||||||||||||||||||||||
Offer
editWhen 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 may contain the client's Client ID (Option 61, containing a unique value, 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 (as specified in the CHADDR field). This field must be used to identify the client, if no Client ID is provided in the DHCP packet.[1]:?§4.2?
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.
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Destination MAC (00:05:3C:04:8D:59) | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | Source MAC (B4:0C:25:E3:7D:62) | |||||||||||||||||||||||||||||||
| 12 | 96 | EtherType (0x0800) | |||||||||||||||||||||||||||||||
| 16 | 128 | IPv4 packet, containing a UDP PDU with DHCP payload... | |||||||||||||||||||||||||||||||
| 20 | 160 | ||||||||||||||||||||||||||||||||
| ? | ? | ||||||||||||||||||||||||||||||||
| ? | ? | Frame Check Sequence | |||||||||||||||||||||||||||||||
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | IPv4 header start | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | TTL | Protocol (17 UDP) | Header Checksum | |||||||||||||||||||||||||||||
| 12 | 96 | Source Address (192.168.1.1) | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 16 | 128 | Destination Address (192.168.1.100) | |||||||||||||||||||||||||||||||
| 20 | 160 | Source Port (67) | Destination Port (68) | ||||||||||||||||||||||||||||||
| 24 | 192 | Length | Checksum | ||||||||||||||||||||||||||||||
| 28 | 224 | OP (0x02) | HTYPE (0x01) | HLEN (0x06) | HOPS (0x00) | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 32 | 256 | XID (0x3903F326) | |||||||||||||||||||||||||||||||
| 36 | 288 | SECS (0x0000) | FLAGS (0x0000) | ||||||||||||||||||||||||||||||
| 40 | 320 | CIADDR (Client IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 44 | 352 | YIADDR (Your IP address: 0xC0A80164 or 192.168.1.100) | |||||||||||||||||||||||||||||||
| 48 | 384 | SIADDR (Server IP address: 0xC0A80101 or 192.168.1.1) | |||||||||||||||||||||||||||||||
| 52 | 416 | GIADDR (Gateway IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 56 | 448 | CHADDR (Client Hardware address: 0x00053C04 0x8D590000 0x00000000 0x00000000) | |||||||||||||||||||||||||||||||
| 60 | 480 | ||||||||||||||||||||||||||||||||
| 64 | 512 | ||||||||||||||||||||||||||||||||
| 68 | 544 | ||||||||||||||||||||||||||||||||
| 72 | 576 | 192 octets of 0s, or overflow space for additional options; BOOTP legacy. | |||||||||||||||||||||||||||||||
| ? | ? | ||||||||||||||||||||||||||||||||
| 260 | 2080 | ||||||||||||||||||||||||||||||||
| 264 | 2112 | Magic Cookie (0x63825363) | |||||||||||||||||||||||||||||||
| 268 | 2144 | First option: 0x350102: Option 53 (DHCP Message Type) 1 octet (containing DHCPOFFER) | Second option:? | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 272 | 2176 | ?0x0104ffffff00: Option 1 (Subnet mask) 4 octets (containing 255.255.255.0) | |||||||||||||||||||||||||||||||
| 276 | 2208 | Third option: 0x0304c0A80101: Option: 3 (Router) 4 octets (containing 192.168.1.1)? | |||||||||||||||||||||||||||||||
| 280 | 2240 | ?Router cont... | Fourth option: 0x330400015080: Option 51 (Address time) 4 octets (a 86400 second lease time)? | ||||||||||||||||||||||||||||||
| 284 | 2272 | ?Address time cont... | Fifth option: | ||||||||||||||||||||||||||||||
| 288 | 2304 | 0x060c09070a0f09070a1009070a13: Option 6 (Domain Server) 14 octets (containing 9.7.10.15,9.7.10.16,9.7.10.18) | |||||||||||||||||||||||||||||||
| 292 | 2336 | ||||||||||||||||||||||||||||||||
| 296 | 2368 | ||||||||||||||||||||||||||||||||
| 300 | 2400 | ff | |||||||||||||||||||||||||||||||
Request
editIn 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.
The client must send the server identification option in the DHCPREQUEST message, indicating the server whose offer the client has selected.[1]:?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.
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Destination MAC (FF:FF:FF:FF:FF:FF) | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | Source MAC (00:05:3C:04:8D:59) | |||||||||||||||||||||||||||||||
| 12 | 96 | EtherType (0x0800) | |||||||||||||||||||||||||||||||
| 16 | 128 | IPv4 packet, containing a UDP PDU with DHCP payload... | |||||||||||||||||||||||||||||||
| 20 | 160 | ||||||||||||||||||||||||||||||||
| ? | ? | ||||||||||||||||||||||||||||||||
| ? | ? | Frame Check Sequence | |||||||||||||||||||||||||||||||
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | IPv4 header start | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | TTL | Protocol (17 UDP) | Header Checksum | |||||||||||||||||||||||||||||
| 12 | 96 | Source Address (0.0.0.0) | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 16 | 128 | Destination Address (255.255.255.255) | |||||||||||||||||||||||||||||||
| 20 | 160 | Source Port (68) | Destination Port (67) | ||||||||||||||||||||||||||||||
| 24 | 192 | Length | Checksum | ||||||||||||||||||||||||||||||
| 28 | 224 | OP (0x01) | HTYPE (0x01) | HLEN (0x06) | HOPS (0x00) | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 32 | 256 | XID (0x3903F326) | |||||||||||||||||||||||||||||||
| 36 | 288 | SECS (0x0000) | FLAGS (0x0000) | ||||||||||||||||||||||||||||||
| 40 | 320 | CIADDR (Client IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 44 | 352 | YIADDR (Your IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 48 | 384 | SIADDR (Server IP address: 0xc0a80101 or 192.168.1.1) | |||||||||||||||||||||||||||||||
| 52 | 416 | GIADDR (Gateway IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 56 | 448 | CHADDR (Client Hardware address: 0x00053C04 0x8D590000 0x00000000 0x00000000) | |||||||||||||||||||||||||||||||
| 60 | 480 | ||||||||||||||||||||||||||||||||
| 64 | 512 | ||||||||||||||||||||||||||||||||
| 68 | 544 | ||||||||||||||||||||||||||||||||
| 72 | 576 | 192 octets of 0s, or overflow space for additional options; BOOTP legacy. | |||||||||||||||||||||||||||||||
| ? | ? | ||||||||||||||||||||||||||||||||
| 260 | 2080 | ||||||||||||||||||||||||||||||||
| 264 | 2112 | Magic Cookie (0x63825363) | |||||||||||||||||||||||||||||||
| 268 | 2144 | First option: 0x350103: Option 53 (DHCP Message Type) 1 octet (containing DHCPREQUEST) | Second option:? | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 272 | 2176 | ?0x3204c0a80164: Option 50 (Request IP address) 4 octets (containing 192.168.1.100) | |||||||||||||||||||||||||||||||
| 276 | 2208 | Third option: 0x3604c0a801601: Option: 54 (DHCP Server) 4 octets (containing 192.168.1.1)? | |||||||||||||||||||||||||||||||
| 280 | 2240 | ?DHCP Server cont... | ff | ||||||||||||||||||||||||||||||
Acknowledgement
editWhen 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.
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Destination MAC (00:05:3C:04:8D:59) | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | Source MAC (B4:0C:25:E3:7D:62) | |||||||||||||||||||||||||||||||
| 12 | 96 | EtherType (0x0800) | |||||||||||||||||||||||||||||||
| 16 | 128 | IPv4 packet, containing a UDP PDU with DHCP payload... | |||||||||||||||||||||||||||||||
| 20 | 160 | ||||||||||||||||||||||||||||||||
| ? | ? | ||||||||||||||||||||||||||||||||
| ? | ? | Frame Check Sequence | |||||||||||||||||||||||||||||||
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | IPv4 header start | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | TTL | Protocol (17 UDP) | Header Checksum | |||||||||||||||||||||||||||||
| 12 | 96 | Source Address (192.168.1.1) | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 16 | 128 | Destination Address (192.168.1.100) | |||||||||||||||||||||||||||||||
| 20 | 160 | Source Port (67) | Destination Port (68) | ||||||||||||||||||||||||||||||
| 24 | 192 | Length | Checksum | ||||||||||||||||||||||||||||||
| 28 | 224 | OP (0x02) | HTYPE (0x01) | HLEN (0x06) | HOPS (0x00) | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 32 | 256 | XID (0x3903F326) | |||||||||||||||||||||||||||||||
| 36 | 288 | SECS (0x0000) | FLAGS (0x0000) | ||||||||||||||||||||||||||||||
| 40 | 320 | CIADDR (Client IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 44 | 352 | YIADDR (Your IP address: 0xC0A80164 or 192.168.1.100) | |||||||||||||||||||||||||||||||
| 48 | 384 | SIADDR (Server IP address: 0xC0A80101 or 192.168.1.1) | |||||||||||||||||||||||||||||||
| 52 | 416 | GIADDR (Gateway IP address: 0x00000000) | |||||||||||||||||||||||||||||||
| 56 | 448 | CHADDR (Client Hardware address: 0x00053C04 0x8D590000 0x00000000 0x00000000) | |||||||||||||||||||||||||||||||
| 60 | 480 | ||||||||||||||||||||||||||||||||
| 64 | 512 | ||||||||||||||||||||||||||||||||
| 68 | 544 | ||||||||||||||||||||||||||||||||
| 72 | 576 | 192 octets of 0s, or overflow space for additional options; BOOTP legacy. | |||||||||||||||||||||||||||||||
| ? | ? | ||||||||||||||||||||||||||||||||
| 260 | 2080 | ||||||||||||||||||||||||||||||||
| 264 | 2112 | Magic Cookie (0x63825363) | |||||||||||||||||||||||||||||||
| 268 | 2144 | First option: 0x350105: Option 53 (DHCP Message Type) 1 octet (containing DHCPACK) | Second option:? | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 272 | 2176 | ?0x0104ffffff00: Option 1 (Subnet mask) 4 octets (containing 255.255.255.0) | |||||||||||||||||||||||||||||||
| 276 | 2208 | Third option: 0x0304c0A80101: Option: 3 (Router) 4 octets (containing 192.168.1.1)? | |||||||||||||||||||||||||||||||
| 280 | 2240 | ?Router cont... | Fourth option: 0x330400015080: Option 51 (Address time) 4 octets (a 86400 second lease time)? | ||||||||||||||||||||||||||||||
| 284 | 2272 | ?Address time cont... | Fifth option: | ||||||||||||||||||||||||||||||
| 288 | 2304 | 0x060c09070a0f09070a1009070a13: Option 6 (Domain Server) 14 octets (containing 9.7.10.15,9.7.10.16,9.7.10.18) | |||||||||||||||||||||||||||||||
| 292 | 2336 | ||||||||||||||||||||||||||||||||
| 296 | 2368 | ||||||||||||||||||||||||||||||||
| 300 | 2400 | ff | |||||||||||||||||||||||||||||||
Selecting and configuring IP addresses
editWhen the server is reusing an IP address from its pool, it may first check (using ping) to see if it is not taken already.[1]:?sec. 2.2? This may happen if a host is configured manually with an IP address that lies within the DHCP scope.
Before claiming an IP address, the client should probe the newly received address (e.g. with ARP), in order to find if there is another host present in the network with the proposed IP address.[1]:?sec. 2.2? If there is no reply, this address does not conflict with that of another host, so it is free to be used. If this probe finds another computer using that address, the client should broadcast a DHCPDECLINE to the DHCP server(s).
Information
editA 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
editThe 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
editA 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
editOptions 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.[13][12]
| 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. |
| 9 | LPR Server | Multiples of 4 octets | A list of Line Printer Daemon protocol servers available to the client, should be listed in order of preference |
| 10 | Impress server | Multiples of 4 octets | A list of Imagen Impress servers available to the client, should be listed in order of preference |
| 11 | Resource location server | Multiples of 4 octets | A list of Resource Location Protocol servers available to the client, should be listed in order of preference |
| 12 | Host name | Minimum of 1 octet | Name of the client. The name may be qualified with the local domain name. |
| 13 | Boot file size | 2 octets | Length of the boot image in 512B blocks |
| 14 | Merit dump file | Minimum of 1 octet | Path where crash dumps should be stored |
| 15 | Domain name | Minimum of 1 octet | |
| 16 | Swap server | 4 octets | |
| 17 | Root path | Minimum of 1 octet | |
| 18 | Extensions path | Minimum of 1 octet | |
| 255 | End | 0 octets | Used to mark the end of the vendor option field |
| Code | Name | Length | Notes |
|---|---|---|---|
| 19 | IP forwarding enable/disable | 1 octet | |
| 20 | Non-local source routing enable/disable | 1 octet | |
| 21 | Policy filter | Multiples of 8 octets | |
| 22 | Maximum datagram reassembly size | 2 octets | |
| 23 | Default IP time-to-live | 1 octet | |
| 24 | Path MTU aging timeout | 4 octets | |
| 25 | Path MTU plateau table | Multiples of 2 octets |
| Code | Name | Length | Notes |
|---|---|---|---|
| 26 | Interface MTU | 2 octets | |
| 27 | All subnets are local | 1 octet | |
| 28 | Broadcast address | 4 octets | |
| 29 | Perform mask discovery | 1 octet | |
| 30 | Mask supplier | 1 octet | |
| 31 | Perform router discovery | 1 octet | |
| 32 | Router solicitation address | 4 octets | |
| 33 | Static route | Multiples of 8 octets | A list of destination/router pairs |
| Code | Name | Length | Notes |
|---|---|---|---|
| 34 | Trailer encapsulation option | 1 octet | |
| 35 | ARP cache timeout | 4 octets | |
| 36 | Ethernet encapsulation | 1 octet |
| Code | Name | Length | Notes |
|---|---|---|---|
| 37 | TCP default TTL | 1 octet | |
| 38 | TCP keepalive interval | 4 octets | |
| 39 | TCP keepalive garbage | 1 octet |
| Code | Name | Length | Notes |
|---|---|---|---|
| 40 | Network information service domain | Minimum of 1 octet | |
| 41 | Network information servers | Multiples of 4 octets | |
| 42 | Network Time Protocol (NTP) servers | Multiples of 4 octets | |
| 43 | Vendor-specific information | Minimum of 1 octets | |
| 44 | NetBIOS over TCP/IP name server | Multiples of 4 octets | |
| 45 | NetBIOS over TCP/IP datagram Distribution Server | Multiples of 4 octets | |
| 46 | NetBIOS over TCP/IP node type | 1 octet | |
| 47 | NetBIOS over TCP/IP scope | Minimum of 1 octet | |
| 48 | X Window System font server | Multiples of 4 octets | |
| 49 | X Window System display manager | Multiples of 4 octets | |
| 64 | Network Information Service+ domain | Minimum of 1 octet | |
| 65 | Network Information Service+ servers | Multiples of 4 octets | |
| 68 | Mobile IP home agent | Multiples of 4 octets | |
| 69 | Simple Mail Transfer Protocol (SMTP) server | Multiples of 4 octets | |
| 70 | Post Office Protocol (POP3) server | Multiples of 4 octets | |
| 71 | Network News Transfer Protocol (NNTP) server | Multiples of 4 octets | |
| 72 | Default World Wide Web (WWW) server | Multiples of 4 octets | |
| 73 | Default Finger protocol server | Multiples of 4 octets | |
| 74 | Default Internet Relay Chat (IRC) server | Multiples of 4 octets | |
| 75 | StreetTalk server | Multiples of 4 octets | |
| 76 | StreetTalk Directory Assistance (STDA) server | Multiples of 4 octets |
| Code | Name | Length | Notes |
|---|---|---|---|
| 50 | Requested IP address | 4 octets | |
| 51 | IP address lease time | 4 octets | |
| 52 | Option overload | 1 octet | |
| 53 | DHCP message type | 1 octet | |
| 54 | Server identifier | 4 octets | |
| 55 | Parameter request list | Minimum of 1 octet | |
| 56 | Message | Minimum of 1 octet | |
| 57 | Maximum DHCP message size | 2 octets | |
| 58 | Renewal (T1) time value | 4 octets | |
| 59 | Rebinding (T2) time value | 4 octets | |
| 60 | Vendor class identifier | Minimum of 1 octet | |
| 61 | Client identifier | Minimum of 2 octets | |
| 66 | TFTP server name | Minimum of 1 octet | |
| 67 | Bootfile name | Minimum of 1 octet |
DHCP message types
editThis table lists the DHCP message types. These codes are the value in the DHCP extension 53, shown in the table above.
| Code | Name | Length | RFC |
|---|---|---|---|
| 1 | DHCPDISCOVER | 1 octet | 2132[13]:?§9.6? |
| 2 | DHCPOFFER | 1 octet | 2132 |
| 3 | DHCPREQUEST | 1 octet | 2132 |
| 4 | DHCPDECLINE | 1 octet | 2132 |
| 5 | DHCPACK | 1 octet | 2132 |
| 6 | DHCPNAK | 1 octet | 2132 |
| 7 | DHCPRELEASE | 1 octet | 2132 |
| 8 | DHCPINFORM | 1 octet | 2132 |
| 9 | DHCPFORCERENEW | 1 octet | 3203[14]:?§4? |
| 10 | DHCPLEASEQUERY | 1 octet | 4388[15]:?§6.1? |
| 11 | DHCPLEASEUNASSIGNED | 1 octet | 4388 |
| 12 | DHCPLEASEUNKNOWN | 1 octet | 4388 |
| 13 | DHCPLEASEACTIVE | 1 octet | 4388 |
| 14 | DHCPBULKLEASEQUERY | 1 octet | 6926[16]:?§6.2.1? |
| 15 | DHCPLEASEQUERYDONE | 1 octet | 6926 |
| 16 | DHCPACTIVELEASEQUERY | 1 octet | 7724[17]:?§5.2.1? |
| 17 | DHCPLEASEQUERYSTATUS | 1 octet | 7724 |
| 18 | DHCPTLS | 1 octet | 7724 |
Client vendor identification
editAn 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 by which a DHCP client can 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).
The value to which this option is set gives the DHCP server a hint about any required extra information that this client needs in a DHCP response. Some types of set-top boxes set the VCI to inform the DHCP server about the hardware type and functionality of the device. An Aruba campus wireless access point, for example, supplies value 'ArubaAP' as option 60 in its DHCPDISCOVER message.[18] The DHCP server can then augment its DHCPOFFER with an IP address of an Aruba wireless controller in option 43, so the access point knows where to register itself.
Setting a VCI by the client allows a DHCP server to differentiate between client machines and process the requests from them appropriately.
Other extensions
edit| Code | Name | Length | RFC |
|---|---|---|---|
| 77 | User Class | Minimum of 2 octets | 3004[19] |
| 82 | Relay agent information | Minimum of 2 octets | 3046[20] |
| 85 | Novell Directory Service (NDS) servers | Minimum of 4 octets, multiple of 4 octets | 2241[21]:?§2? |
| 86 | NDS tree name | Variable | 2241[21]:?§3? |
| 87 | NDS context | Variable | 2241[21]:?§4? |
| 100 | Time zone, POSIX style | Variable | 4833[22] |
| 101 | Time zone, tz database style | Variable | 4833 |
| 114 | DHCP Captive-Portal | Variable | 8910[23] |
| 119 | Domain search | Variable | 3397[24] |
| 121 | Classless static route | Variable | 3442[25] |
| 209 | Configuration File | Variable | 5071[26] |
| 210 | Path Prefix | Variable | 5071 |
| 211 | Reboot Time | Variable | 5071 |
Relay agent information sub-options
editThe relay agent information option (option 82) specifies container for attaching sub-options to DHCP requests transmitted between a DHCP relay and a DHCP server.[27]
| Code | Name | Length | RFC |
|---|---|---|---|
| 1 | Agent Circuit ID | Minimum of 1 octet | 3046[20] |
| 2 | Agent Remote ID | Minimum of 1 octet | 3046 |
| 4 | Data-Over-Cable Service Interface Specifications (DOCSIS) device class | 4 octets | 3256[28] |
Relaying
editIn 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.[1]:?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.
Client states
edit
A DHCP client can receive these messages from a server:[1]:?§4.4?
- DHCPOFFER
- DHCPACK
- DHCPNAK
The client moves through DHCP states depending on how the server responds to the messages that the client sends.
Reliability
editThe DHCP ensures reliability in several ways: periodic renewal, rebinding,[1]:?§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.[1]:?§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,[1]:?§4.4.5 Paragraph 8?[b] 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,[1]:?§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.[29][c]
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.[1]:?§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.
IPv6 networks
editThe 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.[30]
Security
editThe base DHCP does not include any mechanism for authentication.[20]:?§7? Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:[1]:?sec. 7?
- Unauthorized DHCP servers providing false information to clients.
- Unauthorized clients gaining access to resources.
- Resource exhaustion attacks from malicious DHCP clients.
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.[31] This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity,[32] or as a man-in-the-middle attack.[33] Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[1]:?sec. 7? 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.[34] 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.[34]
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.[31] 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.[31]
DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension[20] (usually referred to in the industry by its actual number as Option 82[35][36]) 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.[20]:?sec. 7?
Another extension, Authentication for DHCP Messages[37] (RFC 3118), provides a mechanism for authenticating DHCP messages. As of 2002, this extension had not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[38] A 2007 book about DSL technologies remarked that:
[T]here 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.[39]
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.[40]
Architectural proposals from 2008 involve authenticating DHCP requests using 802.1X or PANA (both of which transport EAP).[41] An IETF proposal was made for including EAP in DHCP itself, the so-called EAPoDHCP;[42] this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.[43]
IETF standards documents
edit- RFC 2131?–?
Dynamic Host Configuration Protocol,
[1] Draft Standard. - RFC 2132?–?
DHCP Options and BOOTP Vendor Extensions,
[13] Draft Standard. - RFC 3046?–?
DHCP Relay Agent Information Option,
[20] Proposed Standard. - RFC 3203?–?
DHCP reconfigure extension,
[14] Proposed Standard. - RFC 3397?–?
Dynamic Host Configuration Protocol (DHCP) Domain Search Option,
[24] Proposed Standard. - RFC 3442?–?
The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4,
[25] Proposed Standard. - RFC 3942?–?
Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options,
[44] Proposed Standard. - RFC 4361?–?
Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4),
[45] Proposed Standard. - RFC 4388?–?
Dynamic Host Configuration Protocol (DHCP) Leasequery,
[15] Proposed Standard. - RFC 4436?–?
Detecting Network Attachment in IPv4 (DNAv4),
[46] Proposed Standard. - RFC 6926?–?
DHCPv4 Bulk Leasequery,
[16] Proposed Standard. - RFC 7724?–?
Active DHCPv4 Lease Query,
[17] Proposed Standard. - RFC 8415?–?
Dynamic Host Configuration Protocol for IPv6 (DHCPv6),
[9] Proposed Standard.
See also
edit- Boot Service Discovery Protocol (BSDP) – a DHCP extension used by Apple's NetBoot
- Comparison of DHCP server software
- K. van den Hout; A. Koopal; R. van Mook (1 April 1998). Management of IP numbers by peg-dhcp. Network Working Group. doi:10.17487/RFC2322. RFC 2322. Informational. This is an April Fools' Day Request for Comments.
- Preboot Execution Environment (PXE)
- Reverse Address Resolution Protocol (RARP)
- Rogue DHCP
- UDP Helper Address – a tool for routing DHCP requests across subnet boundaries
- Zeroconf – Zero Configuration Networking
- Kea – an open-source DHCP server developed by the Internet Systems Consortium
Notes
edit- ^ As an optional client behavior, some broadcasts, such as those carrying DHCP discovery and request messages, may be replaced with unicasts in case the DHCP client already knows the DHCP server's IP address.[1]
- ^ The RFC calls for the client to wait one half of the remaining time until T2 before it retransmits the DHCPREQUEST packet
- ^ The proposal provided a mechanism whereby two servers could remain loosely in sync with each other in such a way that even in the event of a total failure of one server, the other server could recover the lease database and continue operating. Due to the length and complexity of the specification, it was never published as a standard; however, the techniques described in the proposal are in wide use, with open-source and several commercial implementations.
References
edit- ^ a b c d e f g h i j k l m n o p q r s R. Droms (March 1997). Dynamic Host Configuration Protocol. IETF Network Working Group. doi:10.17487/RFC2131. RFC 2131. Draft Standard. Obsoletes RFC 1541. Updated by RFC 3396, 4361, 5494 and 6842.
- ^ Peterson, Larry L.; Davie, Bruce S. (2011). Computer Networks: A Systems Approach (5th ed.). Elsevier. ISBN 978-0-12-385060-7. Retrieved March 21, 2019.
- ^ R. Finlayson; T. Mann; J. Mogul; M. Theimer (June 1984). A Reverse Address Resolution Protocol. Network Working Group. doi:10.17487/RFC0903. STD 38. RFC 903. Internet Standard 38.
- ^ Bill Croft; John Gilmore (September 1985). BOOTSTRAP PROTOCOL (BOOTP). Network Working Group. doi:10.17487/RFC0951. RFC 951. Draft Standard. Updated by RFC 1395, 1497, 1532, 1542 and 5494.
- ^ R. Droms (October 1993). Dynamic Host Configuration Protocol. Network Working Group. doi:10.17487/RFC1531. RFC 1531. Obsolete. Obsoleted by RFC 1541, due to errors in the editorial process.
- ^ R. Droms (October 1993). Dynamic Host Configuration Protocol. Network Working Group. doi:10.17487/RFC1541. RFC 1541. Obsolete. Obsoleted by RFC 2131. Obsoletes RFC 1531.
- ^ Network+ Certification 2006 Published By Microsoft Press.
- ^ J. Bound; B. Volz; T. Lemon; C. Perkins; M. Carney (July 2002). R. Droms (ed.). Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Network Working Group. doi:10.17487/RFC3315. RFC 3315. Obsolete. Obsoleted by RFC 8415. Updated by RFC 4361, 5494, 6221, 6422, 6644, 7083, 7283, 7227 and 7550.
- ^ a b T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (November 2018). Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Internet Engineering Task Force. doi:10.17487/RFC8415. ISSN 2070-1721. RFC 8415. Proposed Standard. Obsoletes RFC 3315, 3633, 3736, 4242, 7083, 7283 and 7550.
- ^ "DHCP - Dynamic Host Configuration Protocol".
- ^ Droms, Ralph; Lemon, Ted (2003). The DHCP Handbook. SAMS Publishing. p. 436. ISBN 978-0-672-32327-0.
- ^ a b "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters". iana.org. Retrieved 2025-08-04.
- ^ a b c d e f g h i j S. Alexander; R. Droms (March 1997). DHCP Options and BOOTP Vendor Extensions. IETF Network Working Group. doi:10.17487/RFC2132. RFC 2132. Draft Standard. Obsoletes RFC 1533. Updated by RFC 3442, 3942, 4361, 4833 and 5494.
- ^ a b Y. T'Joens; C. Hublet; P. De Schrijver (December 2001). DHCP reconfigure extension. Network Working Group. doi:10.17487/RFC3203. RFC 3203. Proposed Standard. Updated by RFC 6704.
- ^ a b R. Woundy; K. Kinnear (February 2006). Dynamic Host Configuration Protocol (DHCP) Leasequery. Network Working Group. doi:10.17487/RFC4388. RFC 4388. Proposed Standard. Updated by RFC 6148.
- ^ a b K. Kinnear; M. Stapp; R. Desetti; B. Joshi; N. Russell; P. Kurapati; B. Volz (April 2013). DHCPv4 Bulk Leasequery. Internet Engineering Task Force. doi:10.17487/RFC6926. ISSN 2070-1721. RFC 6926. Proposed Standard. Updated by RFC 7724.
- ^ a b K. Kinnear; M. Stapp; B. Volz; N. Russell (December 2015). Active DHCPv4 Lease Query. Internet Engineering Task Force. doi:10.17487/RFC7724. ISSN 2070-1721. RFC 7724. Proposed Standard. Updates RFC 6926.
- ^ "Aruba DHCP Option 60". 7 October 2020.
- ^ G. Stump; R. Droms; Y. Gu; R. Vyaghrapuri; A. Demirtjis; B. Beser; J. Privat (November 2000). The User Class Option for DHCP. Network Working Group. doi:10.17487/RFC3004. RFC 3004. Proposed Standard.
- ^ a b c d e f M. Patrick (January 2001). DHCP Relay Agent Information Option. Network Working Group. doi:10.17487/RFC3046. RFC 3046. Proposed Standard. Updated by RFC 6607.
- ^ a b c D. Provan (November 1997). DHCP Options for Novell Directory Services. Network Working Group. doi:10.17487/RFC2241. RFC 2241. Proposed Standard.
- ^ E. Lear; P. Eggert (April 2007). Timezone Options for DHCP. Network Working Group. doi:10.17487/RFC4833. RFC 4833. Proposed Standard. Updates RFC 2132.
- ^ W. Kumari; E. Kline (September 2020). Captive-Portal Identification in DHCP and Router Advertisements (RAs). Internet Engineering Task Force. doi:10.17487/RFC8910. ISSN 2070-1721. RFC 8910. Proposed Standard. Obsoletes RFC 7710. Updates RFC 3679.
- ^ a b B. Aboba; S. Cheshire (November 2002). Dynamic Host Configuration Protocol (DHCP) Domain Search Option. Network Working Group. doi:10.17487/RFC3397. RFC 3397. Proposed Standard.
- ^ a b T. Lemon; S. Cheshire; B. Volz (December 2002). The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4. Network Working Group. doi:10.17487/RFC3442. RFC 3442. Proposed Standard. Updates RFC 2132.
- ^ D. Hankins (December 2007). Dynamic Host Configuration Protocol Options Used by PXELINUX. Network Working Group. doi:10.17487/RFC5071. RFC 5071. Informational.
- ^ Patrick, Michael (January 2001). "DHCP Relay Agent Information Option". IETF Documents. IETF. doi:10.17487/RFC3046. Retrieved 22 July 2017.
- ^ D. Jones; R. Woundy (April 2002). The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option. Network Working Group. doi:10.17487/RFC3256. RFC 3256. Proposed Standard.
- ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (March 2003). DHCP Failover Protocol. IETF. I-D draft-ietf-dhc-failover-12. Retrieved May 9, 2010.
- ^ Weinberg, Neal (2025-08-04). "Why DHCP's days might be numbered". Network World. Retrieved 2025-08-04.
- ^ a b c Stapko, Timothy (2011). Practical Embedded Security: Building Secure Resource-Constrained Systems. Newnes. p. 39. ISBN 978-0-08-055131-9.
- ^ Rountree, Derrick (2013). Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure. Newnes. p. 22. ISBN 978-1-59749-965-1.
- ^ Rooney, Timothy (2010). Introduction to IP Address Management. John Wiley & Sons. p. 180. ISBN 978-1-118-07380-3.
- ^ a b Golovanov (Kaspersky Labs), Sergey (June 2011). "TDSS loader now got "legs"". Archived from the original on 25 January 2021.
- ^ Hens, Francisco J.; Caballero, José M. (2008). Triple Play: Building the converged network for IP, VoIP and IPTV. John Wiley & Sons. p. 239. ISBN 978-0-470-75439-9.
- ^ Ramirez, David H. (2008). IPTV Security: Protecting High-Value Digital Contents. John Wiley & Sons. p. 55. ISBN 978-0-470-72719-5.
- ^ R. Droms; W. Arbaugh, eds. (June 2001). Authentication for DHCP Messages. Network Working Group. doi:10.17487/RFC3118. RFC 3118. Proposed Standard.
- ^ Lemon, Ted (April 2002). "Implementation of RFC 3118".
- ^ Golden, Philip; Dedieu, Hervé; Jacobsen, Krista S. (2007). Implementation and Applications of DSL Technology. Taylor & Francis. p. 484. ISBN 978-1-4200-1307-8.
- ^ Rooney, Timothy (2010). Introduction to IP Address Management. John Wiley & Sons. pp. 181–182. ISBN 978-1-118-07380-3.
- ^ Copeland, Rebecca (2008). Converging NGN Wireline and Mobile 3G Networks with IMS. Taylor & Francis. pp. 142–143. ISBN 978-1-4200-1378-8.
- ^ Prasad, Ramjee; Mihovska, Albena (2009). New Horizons in Mobile and Wireless Communications: Networks, services, and applications. Vol. 2. Artech House. p. 339. ISBN 978-1-60783-970-5.
- ^ "Draft-pruss-DHCP-auth-DSL-07 - EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband". Archived from the original on 2025-08-04. Retrieved 2025-08-04.
- ^ B. Volz (November 2004). Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options. Network Working Group. doi:10.17487/RFC3942. RFC 3942. Proposed Standard. Updates RFC 2132.
- ^ T. Lemon; B. Sommerfield (February 2006). Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4). Network Working Group. doi:10.17487/RFC4361. RFC 4361. Proposed Standard. Updated by RFC 5494. Updates RFC 2131, 3315 and 2132.
- ^ B. Aboba; J. Carlson; S. Cheshire (March 2006). Detecting Network Attachment in IPv4 (DNAv4). Network Working Group. doi:10.17487/RFC4436. RFC 4436. Proposed Standard.
External links
edit
Media related to Dynamic Host Configuration Protocol (DHCP) at Wikimedia Commons
