Dynamic Host Configuration Protocol

From Wikipedia, the free encyclopedia

(Redirected from Dhcp)
"DHCP" redirects here. For other uses, see DHCP (disambiguation).
This article's lead section may not adequately summarize key points of its contents.
Please consider expanding the lead to provide an accessible overview of all important
aspects of the article. Please discuss this issue on the article's talk page. (November 2015)
This article needs additional citations for verification. Please help improve this article
by adding citations to reliable sources. Unsourced material may be challenged and
removed. (April 2010) (Learn how and when to remove this template message)
Internet protocol suite

Application layer

 BGP
 DHCP
 DNS
 FTP
 HTTP
 IMAP
 LDAP
 MGCP
 NNTP
 NTP
 POP
 ONC/RPC
 RTP
 RTSP
 RIP
 SIP
 SMTP
 SNMP
 SSH
 Telnet
 TLS/SSL
 XMPP
 more...
Transport layer
 TCP
 UDP
 DCCP
 SCTP
 RSVP
 more...

Internet layer
 IP
o IPv4
o IPv6
 ICMP
 ICMPv6
 ECN
 IGMP
 IPsec
 more...

Link layer
 ARP
 NDP
 OSPF
 Tunnels
o L2TP
 PPP
 MAC
o Ethernet
o DSL
o ISDN
o FDDI
 more...

 v
 t
 e
The Dynamic Host Configuration Protocol (DHCP) is a standardized network protocol used
on Internet Protocol (IP) networks. The DHCP protocol is controlled by a DHCP server that
dynamically distributes network configuration parameters, such as IP addresses, for interfaces
and services. A router or a residential gateway can be enabled to act as a DHCP server. A DHCP
server enables computers to request IP addresses and networking parameters automatically,
reducing the need for a network administrator or a user to configure these settings manually. In
the absence of a DHCP server, each computer or other device (eg., a printer) on the network
needs to be statically (ie., manually) assigned an IP address.

Contents
 1 Overview
 2 History
 3 Operation
o 3.1 DHCP discovery
o 3.2 DHCP offer
o 3.3 DHCP request
o 3.4 DHCP acknowledgement
o 3.5 DHCP information
o 3.6 DHCP releasing
 4 Client configuration parameters
 5 DHCP options
o 5.1 Vendor identification
 6 DHCP relaying
 7 Reliability
 8 Security
 9 IETF standards documents
 10 See also
 11 Notes
 12 References
 13 External links

Overview
TCP/IP defines how devices on one network communicate with devices on another network. A
DHCP server can manage TCP/IP settings for devices on a network, by automatically or
dynamically assigning Internet Protocol (IP) addresses to the devices. As of 2011, networks
ranging in size from home networks to large campus networks and regional Internet service
provider networks commonly use DHCP.[1] Most residential network routers receive a globally
unique IP address within the provider network. Within a local network, a DHCP server assigns a
local IP address to each device connected to the network.

The DHCP protocol operates based on the client–server model. When a computer or other device
connects to a network, the DHCP client software sends a 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
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 for the time period for which the allocation (lease) is valid. A client typically
queries for this information immediately after booting, and periodically thereafter before the
expiration of the information. When a DHCP client refreshes an assignment, it initially requests
the same parameter values, but the DHCP server may assign a new address based on the
assignment policies set by administrators.

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

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

Dynamic allocation
A network administrator reserves a range of IP addresses for DHCP, and each DHCP
client on the LAN is configured to request an IP address from the DHCP server during
network initialization. The request-and-grant process uses a lease concept with a
controllable time period, allowing the DHCP server to reclaim (and then reallocate) IP
addresses that are not renewed.
Automatic allocation
The DHCP server permanently assigns an IP address to a requesting client from 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.
Manual allocation (commonly called static allocation)
The DHCP server is disabled and the administrator allocates a private 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 for IPv6. While both versions
serve the same purpose, the details of the protocol for IPv4 and IPv6 differ sufficiently that they
may be considered separate protocols.[2] 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.

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

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

Four years later the DHCPINFORM message type[5] and other small changes were added by RFC
2131; which as of 2014 remains the standard for IPv4 networks.

DHCPv6 was initially described by RFC 3315 in 2003, but this has been updated by many
subsequent RFCs.[6] RFC 3633 added a DHCPv6 mechanism for prefix delegation, and stateless
address autoconfiguration was added by RFC 3736.

Operation

An illustration of a typical non-renewing DHCP session; each message may be either a broadcast
or a unicast, depending on the DHCP client capabilities.[7]
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
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 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 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. Additionally, there is a BOOTP flag the client can use
to indicate in which way (broadcast or unicast) it can receive the DHCPOFFER: 0x8000 for
broadcast, 0x0000 for unicast.[8] Only hosts with preconfigured IP addresses can receive unicast
packets so in the usual use case clients in discovery phase should set BOOTP flag to 0x8000
(broadcast).

DHCP discovery

The client broadcasts messages on the network subnet using the destination address
[Link] 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 to issue a new request. A non-
authoritative server simply ignores the request, leading to an implementation-dependent timeout
for the client to expire the request and ask for a new IP address.

Below is an example. 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.

Example DHCPDISCOVER message

IP: source=[Link]; destination=[Link]
UDP: source port=68; destination port=67
Octet 0 Octet 1 Octet 2 Octet 3
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x8000
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
53: 1 (DHCP Discover)
50: [Link] requested
55 (Parameter Request List):

 1 (Request Subnet Mask),

 3 (Router),
 15 (Domain Name),
 6 (Domain Name Server)

DHCP offer

When a DHCP server receives a DHCPDISCOVER message from a client, which is an IP

address lease request, the 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 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, [Link], specifies the client's IP
address in the YIADDR (your IP address) field.

DHCPOFFER message
IP: source=[Link]; destination=[Link]
UDP: source port=67; destination port=68
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 ([Link])
SIADDR (Server IP address)
0xC0A80101 ([Link])
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): [Link]
3 (Router): [Link]
51 (IP address lease time): 86400s (1 day)
54 (DHCP server): [Link]
6 (DNS servers):

 [Link],
 [Link],
 [Link]

DHCP request

In response to the DHCP offer, the client replies with a DHCP request, 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. Based on required server identification option in the request
and broadcast messaging, servers are informed whose offer the client has accepted.[10]:Section 3.1, Item 3
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.

DHCPREQUEST message
IP: source=[Link] destination=[Link];[a]
UDP: source port=68; destination port=67
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)
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
53: 3 (DHCP Request)
50: [Link] requested
54 (DHCP server): [Link]

DHCP 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[11] (e.g. with
ARP Address Resolution Protocol) to prevent address conflicts caused by overlapping address
pools of DHCP servers.

DHCPACK message
IP: source=[Link]; destination=[Link]
UDP: source port=67; destination port=68
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
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
53: 5 (DHCP ACK) or 6 (DHCP NAK)
1 (subnet mask): [Link]
3 (Router): [Link]
51 (IP address lease time): 86400s (1 day)
54 (DHCP server: [Link]
6 (DNS servers):
  [Link],
 [Link],
 [Link]

DHCP 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.

DHCP 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.[12]

A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server. [13]

DHCP options
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.[14]

RFC1497 vendor extensions[14]:Section 3

Code Name Length Notes
Can be used to pad other options so that they are aligned to
0 Pad[14]:Section 3.1 0 octets
the word boundary; is not followed by length byte
Subnet Must be sent after the router option (option 3) if both are
1 4 octets
Mask[14]:Section 3.3 included
Time
2 4 octets
Offset[14]:Section 3.4
3 Router Multiples of Available routers, should be listed in order of preference
 RFC1497 vendor extensions[14]:Section 3
Code Name Length Notes
4 octets
Multiples of Available time servers to synchronise with, should be listed
4 Time Server
4 octets in order of preference
Multiples of Available IEN 116 name servers, should be listed in order
5 Name Server
4 octets of preference
Domain Name Multiples of Available DNS servers, should be listed in order of
6
Server 4 octets preference
Multiples of Available log servers, should be listed in order of
7 Log Server
4 octets preference.
"Cookie" in this case means "fortune cookie" or "quote of
Multiples of the day," a pithy or humorous anecdote often sent as part of
8 Cookie Server
4 octets a logon process on large computers; it has nothing to do
with cookies sent by websites.
Multiples of
9 LPR Server
4 octets
Multiples of
10 Impress Server
4 octets
Resource Multiples of
11
Location Server 4 octets
Minimum of
12 Host Name
1 octet
13 Boot File Size 2 octets Length of the boot image in 4KiB blocks
Minimum of
14 Merit Dump File Path where crash dumps should be stored
1 octet
Minimum of
15 Domain Name
1 octet
16 Swap Server 4 octets
Minimum of
17 Root Path
1 octet
Minimum of
18 Extensions Path
1 octet
255 End 0 octets Used to mark the end of the vendor option field
IP Layer Parameters per Host[14]:Section 4
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
 IP Layer Parameters per Interface[14]:Section 5
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
Link Layer Parameters per Interface[14]:Section 6
Code Name Length Notes
34 Trailer Encapsulation Option 1 octet
35 ARP Cache Timeout 4 octets
36 Ethernet Encapsulation 1 octet
[14]:Section 7
TCP Parameters
Code Name Length Notes
37 TCP Default TTL 1 octet
38 TCP Keepalive Interval 4 octets
39 TCP Keepalive Garbage 1 octet
Application and Service Parameters[14]:Section 8
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
 Application and Service Parameters[14]:Section 8
Code Name Length Notes
76 StreetTalk Directory Assistance (STDA) Server Multiples of 4 octets
[14]:Section 9
DHCP Extensions
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

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
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 does not 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
The DHCP protocol ensures reliability in several ways: periodic renewal, rebinding, [10]:Section 4.4.5
and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to
attempt to renew their leases once half the lease interval has expired.[10]:Section 4.4.5 Paragraph 3 They do
this by sending a unicast DHCPREQUEST message to the DHCP server that granted the original
lease. If that server is down or unreachable, it will fail to respond to the DHCPREQUEST.
However, in that case the client repeats the DHCPREQUEST from time to time, [10]:Section 4.4.5 Paragraph
8[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,[10]:Section 4.4.5 Paragraph 5 the DHCP
client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it.
Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If
some other DHCP server is able to renew the lease, it will do so at this time.

In order for rebinding to work, when the client successfully contacts a backup DHCP server, that
server must have accurate information about the client's binding. Maintaining accurate binding
information between two servers is a complicated problem; if both servers are able to update the
same lease database, there must be a mechanism to avoid conflicts between updates on the
independent servers. A proposal for implementing fault-tolerant DHCP servers was submitted[by
whom?]
to the Internet Engineering Task Force, but never formalized[15][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.[10]:Section 4.4.5 Paragraph 9 At that time it will restart the
DHCP process from the beginning by broadcasting a DHCPDISCOVER message. Since its lease
has expired, it will accept any IP address offered to it. Once it has a new IP address (presumably
from a different DHCP server) it will once again be able to use the network. However, since its
IP address has changed, any ongoing connections will be broken.

Security
See also: DHCP snooping

The base DHCP protocol does not include any mechanism for authentication.[16] 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.[17]

  Unauthorized clients gaining access to resources.[17]
 Resource exhaustion attacks from malicious DHCP clients.[17]

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.[18] This can serve either as a denial-of-service attack, preventing the
client from gaining access to network connectivity,[19] or as a man-in-the-middle attack.[20]
Because the DHCP server provides the DHCP client with server IP addresses, such as the IP
address of one or more DNS servers,[17] 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.[21][22] 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.[21]

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.[18] 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.[18]

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[23][24]) 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.[16]

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.[25] 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."[26] 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."[27]

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