From time to time, we receive questions about DHCP and what it does. This article taken from wikipedia will help to understand DCHP and its configuration.
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
The Dynamic Host Configuration Protocol (DHCP) is a standardized networking protocol used on Internet Protocol (IP) networks for dynamically distributing network configuration parameters, such as IP addresses for interfaces and services. With DHCP, computers request IP addresses and networking parameters automatically from a DHCP server, reducing the need for a network administrator or a user to configure these settings manually.
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
Contents
[hide]
Overview[edit]
The Dynamic Host Configuration Protocol is used by computers for requesting Internet Protocol parameters, such as an IP address from a network server. The protocol operates based on the client-server model. DHCP is very common in all modern networks[1] ranging in size from home networks to large campus networks and regional Internet service provider networks. Most residential network routers receive a globally unique IP address within the provider network. Within a local network, DHCP assigns a local IP address to devices connected to the local network.
When a computer or other networked device connects to a network, its DHCP client software in the operating system sends a broadcast query requesting 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 request, the 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 the time period for which the allocation (lease) is valid. A host typically queries for this information immediately after booting, and periodically thereafter before the expiration of the information. When an assignment is refreshed by the client computer, it initially requests the same parameter values, but may be assigned a new address from the server, 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 client computer 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 the range defined by the 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.
- static allocation: The DHCP server allocates an IP address based on a preconfigured mapping to each client's MAC address. This feature is variously called static DHCP assignment by DD-WRT, fixed-address by the dhcpd documentation,address reservation by Netgear, DHCP reservation or static DHCP by Cisco and Linksys, and IP address reservation or MAC/IP address binding by various other router manufacturers.
DHCP is used for Internet Protocol version 4 (IPv4), as well as IPv6. While both versions serve the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they may be considered separate protocols.[2] For IPv6operation, devices may alternatively use stateless address autoconfiguration. IPv4 hosts may also use link-local addressing to achieve operation restricted to the local network link.
History[edit]
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 unused IP addresses.
DHCP development culminated in RFC 2131 in 1997, and remains as of 2014 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 the forwarding of BOOTP packets off the local network using standard IP routing, thus one central BOOTP server could serve hosts on many IP subnets.[3]
The Dynamic Host Configuration Protocol was created for the express purpose of addressing the shortcomings in RARP and BOOTP. DHCP is based on BOOTP to great extent, but instead of simply supplying predetermined configuration parameters to network clients, DHCP can dynamically allocate IP addresses from a pool and reclaim them when they are no longer in use. This prevents workstations from being assigned multiple IP addresses. In contrast to BOOTP, DHCP can deliver a wide range of configuration parameters to IP clients, including platform-specific parameters extending the core set of parameters.[4]
Operation[edit]
The DHCP protocol 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 BOOTP protocol. UDP port number 67 is the destination port of a server, and UDP port number 68 is used by the client.
DHCP operations fall into four phases: server discovery, IP lease offer, IP request, and IP lease acknowledgment. These stages are often abbreviated as DORA for discovery, offer, request, and acknowledgment.
The DHCP protocol operation begins with clients broadcasting a request. If the client and server are on different subnets, 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.
DHCP discovery[edit]
The client broadcasts messages on the network subnet using the destination address 255.255.255.255 or the specific subnet broadcast address. A DHCP client may also request its last-known IP address. If the client remains connected to the same network, the server may grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server denies the request, causing the client issue a new request. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client expire 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 (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 | |||
| 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) |
|||
DHCP offer[edit]
When a DHCP server receives an IP address lease request from a client, it reserves an IP address for the client and extends an IP address 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 client's 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 (Client IP address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP address) | ||||
| 0xC0A80164 | ||||
| SIADDR (Server IP address) | ||||
| 0xC0A80101 | ||||
| GIADDR (Gateway IP address) | ||||
| 0x00000000 | ||||
| CHADDR (Client hardware address) | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0s. 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 address 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 | ||||
DHCP request[edit]
In response to the DHCP offer, the client replies with a DHCP request, broadcast to the server, requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. Based on requiredserver identification option in the request and broadcast messaging, servers are informed whose offer the client has accepted.[5] 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.
| 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 (Client IP address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP address) | ||||
| 0x00000000 | ||||
| SIADDR (Server IP address) | ||||
| 0xC0A80101 | ||||
| GIADDR (Gateway IP address) | ||||
| 0x00000000 | ||||
| CHADDR (Client hardware address) | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0s. 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. | ||||
DHCP acknowledgement[edit]
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, the client may use the Address Resolution Protocol (ARP) to prevent address conflicts caused by overlapping address pools of DHCP servers.
| 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 0s. 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 address 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 | ||||
DHCP information[edit]
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 viaWPAD.
DHCP releasing[edit]
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[edit]
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.[6]
A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server.[7]
DHCP options[edit]
Options are variable length octet strings. 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 stated in RFC2132.[8]
| Code | Name | Length | Notes |
|---|---|---|---|
| 0 | Pad[8]:Section 3.1 | 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[8]:Section 3.3 | 4 octets | Must be sent after the router option (option 3) if both are included |
| 2 | Time Offset[8]:Section 3.4 | 4 octets | |
| 3 | Router | multiples of 4 octets | Available routers, should be listed in order of preference |
| 4 | Time Server | multiples of 4 octets | Available time servers to synchronise with, should be listed in order of preference |
| 5 | Name Server | multiples of 4 octets | Available IEN116 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 | |
| 9 | LPR Server | multiples of 4 octets | |
| 10 | Impress Server | multiples of 4 octets | |
| 11 | Resource Location Server | multiples of 4 octets | |
| 12 | Host Name | minimum of 1 octet | |
| 13 | Boot File Size | 2 octets | Length of the boot image in 4KiB 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 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 Transport Protocol (SMTP) Server | multiples of 4 octets | |
| 70 | Post Office Protocol (POP3) Server | multiples of 4 octets | |
| 71 | Network News Transport Protocol (NNTP) Server | multiples of 4 octets | |
| 72 | Default World Wide Web (WWW) Server) | multiples of 4 octets | |
| 73 | Default Finger 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 |
Vendor identification[edit]
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 this option is set to gives the DHCP server a hint about any required extra information that this client needs in a DHCP response.
DHCP relaying[edit]
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 the DHCP server using IP routing, because it doesn't have a routable IP address, nor does it know the IP address of a router. 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. 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 relay agent stores its own IP address in the GIADDR field of the DHCP packet. The DHCP server uses the GIADDR to determine the subnet on which the relay agent received the broadcast, and allocates an IP address on that subnet. 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.
Reliability[edit]
The DHCP protocol provides reliability in several ways: periodic renewal, rebinding, 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. 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, the DHCPREQUEST will be repeated by the client from time to time,[specify] so when the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it, and renew its lease.
If the DHCP server is unreachable for an extended period of time,[specify] 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[9][a]
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. 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.
Security[edit]
The base DHCP protocol does not include any mechanism for authentication.[10] 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.[11]
- Unauthorized clients gaining access to resources.[11]
- Resource exhaustion attacks from malicious DHCP clients.[11]
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.[12] This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity,[13] or as a man-in-the-middle attack.[14] Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[11] 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.[15] 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.[15]
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.[12] 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.[12]
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[16][17]) 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.[10]
Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. Unfortunately RFC 3118 has not seen (as of 2002) widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[18] 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."[19] A 2010 book notes that "[t]here have been very few implementations of DHCP Authentication. The challenged of key management and processing delays due to hash computation have been deemed too heavy a price to pay for the perceived benefits."[20]
More recent (2008) architectural proposals involve authenticating DHCP requests using 802.1x or PANA (both of which transport EAP).[21] An IETF proposal was made for including EAP in DHCP itself, the so-called EAPoDHCP;[22] this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.[23]
0 Comments