Wikipedia

Dynamic Host Configuration Protocol: Difference between revisions

Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
m Reverted 2 edits by 176.88.175.206 (talk) to last revision by Entranced98
 
Line 1:
{{short description|Principal protocol used to assign IPv4 addresses on an IPv4 network}}
{{Otheruses4|the networking protocol|other uses|DHCP (disambiguation)}}
{{hatnote group|
{{Redirect|DHCP}}
{{Confusion|HDCP}}
}}
{{Internet protocol suite}}
The '''Dynamic Host Configuration Protocol''' ('''DHCP''') is a [[network protocol|network management protocol]] used on [[Internet Protocol]] (IP) networks for automatically assigning [[IP address]]es and other communication parameters to devices connected to the network using a [[client–server]] architecture.{{Ref RFC|2131}}{{rp|Introduction}}
 
The technology eliminates the need for individually configuring network devices manually, and consists of two network components, a centrally installed network DHCP [[Server (computing)|server]] and client instances of the [[protocol stack]] on each computer or device. When connected to the network, and periodically thereafter, a client [[Request–response|requests]] a set of parameters from the server using DHCP.
{{IPstack}}
'''DHCP''' is a set of rules used by communications devices such as a [[computer]], [[router]] or [[network adapter]] to allow the device to request and obtain an [[IP address]] from a [[Server (computing)|server]] which has a list of addresses available for assignment.'''
 
DHCP can be implemented on networks ranging in size from [[residential network]]s to large [[campus network]]s and regional ISP networks.<ref>{{cite book |last1=Peterson |first1=Larry L. |last2=Davie |first2=Bruce S. |date=2011 |url=https://books.google.com/books?id=BvaFreun1W8C&pg=PA372 |title=Computer Networks: A Systems Approach |publisher=Elsevier |isbn=978-0-12-385060-7 |edition=5th |access-date=March 21, 2019}}</ref> Many [[Router (computing)|routers]] and [[residential gateway]]s have DHCP server capability. Most residential network routers receive a [[Universally unique identifier|unique]] IP address within the ISP network. Within a local network, a DHCP server assigns a local IP address to each device.
DHCP is a protocol used by networked computers (''clients'') to obtain IP addresses and other parameters such as the [[default gateway]], [[subnet mask]], and IP addresses of [[Domain name system|DNS]] servers from a DHCP server. It facilitates access to a network because these settings would otherwise have to be made manually for the client to participate in the network.
 
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]].
The DHCP server ensures that all IP addresses are unique, e.g., no IP address is assigned to a second client while the first client's assignment is valid (its ''lease'' has not expired). Thus IP address pool management is done by the server and not by a human network administrator.
 
==History==
DHCP emerged as a [[standardization|standard protocol]] in October 1993. [[As of 2006]], RFC 2131 provides the latest ([dated March 1997]) DHCP definition. DHCP functionally became a successor to the older [[BOOTP]] protocol, whose leases were given for infinite time and did not support options. Due to the backward-compatibility of DHCP, very few networks continue to use pure BOOTP.
The [[Reverse Address Resolution Protocol]] (RARP) was defined in 1984 for the configuration of simple devices, such as [[diskless workstation]]s, with a suitable IP address.{{Ref RFC|903}} 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.{{Ref RFC|951}} 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.{{Ref RFC|1531}}{{Ref RFC|1541}} 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.<ref name="Network+ certification">Network+ Certification 2006 Published By Microsoft Press.</ref>
The [[as of 2004|latest]] non-standard of the protocol, describing [[DHCPv6]] (DHCP in an [[IPv6]] environment), appeared in July 2003 as RFC 3315.
 
Four years later, the DHCPINFORM message type (used for [[Web Proxy Autodiscovery Protocol|WPAD]]) and other small changes were added. This definition, from 1997,{{Ref RFC|2131}} remains the core of the standard for IPv4 networks.
==Overview==
The Dynamic Host Configuration Protocol (DHCP) automates the assignment of IP addresses, subnet masks, default gateway, and other IP parameters. The assignment occurs when the DHCP-configured machine boots up or regains connectivity to a network. The DHCP client sends out a query requesting a response from a DHCP server on the locally attached network. The query is typically initiated immediately after [[booting]] up and before the client initiates any [[Internet Protocol|IP]] based communication with other hosts. The DHCP server then replies to the client with its assigned IP address, subnet mask, DNS server and default gateway information.
 
[[DHCPv6]] was initially defined in 2003.{{Ref RFC|3315}} After updates by many subsequent RFCs, its definition was replaced in 2018,{{Ref RFC|8415}} where [[prefix delegation]] and [[stateless address autoconfiguration]] were now merged.
The assignment of the IP address generally expires after a predetermined period of time, before which the DHCP client and server renegotiate a new IP address from the server's predefined pool of addresses. Typical intervals range from one hour to several months, and can, if desired, be set to ''infinite'' (never expire). The length of time the address is available to the device it was assigned to is called a ''lease'', and is determined by the server.
 
=={{Anchor|LEASE}}Overview==
Configuring [[firewall (networking)|firewall]] rules to accommodate access from machines who receive their IP addresses via DHCP is therefore more difficult because the remote IP address will vary from time to time. Administrators must usually allow access to the entire remote DHCP subnet for a particular TCP/UDP port.
[[Internet Protocol]] (IP) defines how devices communicate within and across local networks on the Internet. A DHCP server can manage IP settings for devices on its local network, e.g., by assigning IP addresses to those devices automatically and dynamically.<ref>{{Cite web |title=DHCP - Dynamic Host Configuration Protocol |url=https://routeripnet.com/dhcp/ |website=}}</ref>
 
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 [[Broadcasting (networking)|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 server]]s, and [[time server]]s. 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.
Most home routers and firewalls are configured in the factory to be DHCP servers for a home network. An alternative to a home router is to use a computer as a DHCP server. [[Internet service provider|ISP]]s generally use DHCP to assign clients individual IP addresses.
 
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.
DHCP is a broadcast-based protocol. As with other types of broadcast traffic, it does not cross a router unless specifically configured to do so. Users who desire this capability must configure their routers to pass DHCP traffic across UDP ports 67 and 68. Home users, however, will practically never need this functionality.
 
Depending on implementation, the DHCP server may have three methods of allocating IP addresses:
==Extent of DHCP usage==
Most [[Cable modem|cable internet]] providers use DHCP to allocate 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 (computing)|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.
In the [[United Kingdom|UK]] many broad-band ISP networks use DHCP, but [[xDSL]] providers make
extensive use of "infinite lease", which amounts to assigning semi-static IPs.
 
;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.
In addition, many [[router]]s and other gateway devices provide DHCP support
for [[computer Network|networks]] running many computers being assigned private
IP addresses.
 
;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.
Office networks also use DHCP, in particular when workers make extensive use of
laptops which link directly to the in-house network only occasionally .
 
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.<ref>{{cite book |title = The DHCP Handbook |year = 2003 |isbn = 978-0-672-32327-0 |first1= Ralph |last1=Droms |first2= Ted |last2=Lemon |publisher = [[SAMS Publishing]] |page = 436 }}</ref> 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.
Network routers and often [[multilayer switch|multilayer switches]] employ a ''DHCP relay agent'', which relays DHCP "Discover" broadcasts from a LAN which does not include a DHCP server to a network which does have one. These devices may be sometimes configured to append information about port from which DHCP request originates (also known as ''option 82''). One example of such a relay agent is the [[UDP Helper Address]] command employed by [[Cisco]] routers.
 
==SecurityOperation==
[[File:DHCP session.svg|thumb|right|upright=1.2|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.{{Ref RFC|2131}}]]
{{sectstub}}
 
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 ___domain|Broadcast Domains]], a [[#Relaying|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.{{Ref RFC|2131}} 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.
==DHCP and firewalls==
[[Firewall (networking)|Firewalls]] usually have to permit DHCP traffic explicitly. Specification of the DHCP client-server protocol describes several cases when packets must have the source address of <tt>0x00000000</tt> or the destination address of <tt>0xffffffff</tt>. Anti-[[spoofing attack|spoofing]] policy rules and tight inclusive firewalls often stop such packets. [[Multi-homed]] DHCP servers require special consideration and further complicate configuration.
 
===Discovery===
To allow DHCP, network administrators need to allow several types of packets through the server-side firewall. All DHCP packets travel as [[User Datagram Protocol|UDP]] datagrams; all client-sent packets have source port 68 and destination port 67; all server-sent packets have source port 67 and destination port 68. For example, a server-side firewall should allow the following types of packets:
The DHCP client broadcasts a DHCPDISCOVER message on the network subnet using the destination address {{IPaddr|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.
* Incoming packets from 0.0.0.0 or dhcp-pool to dhcp-ip
* Incoming packets from any address to 255.255.255.255
* Outgoing packets from dhcp-ip to dhcp-pool or 255.255.255.255
where ''dhcp-ip'' represents any address configured on a DHCP server host and ''dhcp-pool'' stands for the pool from which a DHCP server assigns addresses to clients
 
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.
===Example in ipfw firewall===
{{APHD|start|title=Example Ethernet frame with a DHCPDISCOVER message}}
To give an idea of how a configuration would look in production, the following rules for a server-side [[ipfirewall]] to allow DHCP traffic through. Dhcpd operates on interface rl0 and assigns addresses from 192.168.0.0/24 :
{{APHD|0|bits1=32|border1=bottom|field1=Destination MAC|value1={{MACaddr|ff:ff:ff:ff:ff:ff}}}}
pass udp from 0.0.0.0,192.168.0.0/24 68 to me 67 in recv rl0
{{APHD|4|bits1=16|border1=top|field1={{nbsp}}|bits2=16|border2=bottom|field2={{nbsp}}}}
pass udp from any 68 to 255.255.255.255 67 in recv rl0
{{APHD|8|bits1=32|border1=top|field1=Source MAC|value1={{MACaddr|00:05:3c:04:8d:59}}}}
pass udp from me 67 to 192.168.0.0/24,255.255.255.255 68 out xmit rl0
{{APHD|12|bits1=16|field1=EtherType|value1={{Mono|0x0800}}|hint1=0x0800 indicates IPv4|bits2=16|border2=bottom|background2=mistyrose|field2={{nbsp}}}}
{{APHD|16|bits1=0|border1=top|background1=mistyrose|field1=IPv4 packet, containing a UDP PDU with DHCP payload...}}
{{APHD|999|bits1=32|field1=Frame Check Sequence|short1=FCS}}
{{APHD|end}}
{{APHD|start|header=yew|title=IPv4 Header}}
{{APHD|0|bits1=64|field1=IPv4 header start}}
{{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol|value2={{Mono|17}} UDP|field3=Header Checksum}}
{{APHD|12|bits1=32|field1=Source Address|value1={{IPaddr|0.0.0.0}}}}
{{APHD|16|bits1=32|field1=Destination Address|value11={{IPaddr|255.255.255.255}}}}
{{APHD|end}}
{{APHD|start|header=no|title=UDP Header}}
{{APHD|20|bits1=16|bits2=16|field1=Source Port|value1=68|field2=Destination Port|value2=67}}
{{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Payload: DHCPDISCOVER}}
{{APHD|28|bits1=8|bits2=8|bits3=8|bits4=8|field1=OP|value1={{Mono|0x01}}|hint1=BOOTREQUEST|field2=HTYPE|value2={{Mono|0x01}}|hint2=Ethernet|field3=HLEN|value3={{Mono|0x06}}|hint3=MAC addresses are 6 octets|field4=HOPS|value4={{Mono|0x00}}}}
{{APHD|32|bits1=32|field1=XID|value1={{Mono|0x3903F326}}}}
{{APHD|36|bits1=16|bits2=16|field1=SECS|value1={{Mono|0x0000}}|field2=FLAGS|value2={{Mono|0x0000}}}}
{{APHD|40|bits1=32|field1=CIADDR|value1=Client IP address: {{Mono|0x00000000}}}}
{{APHD|44|bits1=32|field1=YIADDR| value1=Your IP address: {{Mono|0x00000000}}}}
{{APHD|48|bits1=32|field1=SIADDR|value1=Server IP address: {{Mono|0x00000000}}}}
{{APHD|52|bits1=32|field1=GIADDR|value1=Gateway IP address: {{Mono|0x00000000}}|hint1=A zero GIADDR means client and DHCP server are on the same subnet.}}
{{APHD|56|bits1=128|field1=CHADDR|value1=Client Hardware address: {{Mono|0x00053C04<br>0x8D590000<br>0x00000000<br>0x00000000}}}}
{{APHD|72|bits1=1536|field1=192 octets of 0s, or overflow space for additional options; BOOTP legacy.}}
{{APHD|264|bits1=32|field1=[[Magic Cookie]]|value1={{Mono|0x63825363}}}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Options (in [[Type-length-value|TLV]] format)}}
{{APHD|268|bits1=24|background1=linen|field1=First option: {{Mono|0x350101}}: Option 53 (DHCP Message Type) 1 octet (containing DHCPDISCOVER)|bits2=8|background2=linen|border2=right|field2=Second option:}}
{{APHD|272|bits1=32|background1=linen|border1=left|field1={{Mono|0x3204c0a80164}}: Option 50 (Request IP address) 4 octets (containing {{IPaddr|192.168.1.100}})}}
{{APHD|276|bits1=32|background1=linen|field1=Third option: {{Mono|0x370401030f06}}: Option: 55 (Parameter Request List) 4 octets|hint1=0x01: Request Subnet Mask; 0x03: Router; 0x0f: Domain Name|border1=right}}
{{APHD|280|bits1=8|background1=linen|border1=left|field1=PRL cont...|hint1=0x06: Domain Name Server|bits2=1|field2=<small>{{Mono|ff}}</small>|hint2=0xff Option end mark}}
{{APHD|end}}
 
===Offer===
===Example in Cisco IOS Extended ACL===
When a DHCP server receives a DHCPDISCOVER message from a client, which is an IP address lease request, the DHCP server reserves an IP address for the client and makes a lease offer by sending a DHCPOFFER message to the client. This message 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.{{Ref RFC|2131|rsection=4.2}}
The following entries are valid on a Cisco 3560 switch with enabled DHCP service. The ACL is applied to a routed interface, 10.32.73.129, on input. The subnet is 10.32.73.128/26.
10 permit udp host 0.0.0.0 eq bootpc host 10.32.73.129 eq bootps
20 permit udp 10.32.73.128 0.0.0.63 eq bootpc host 10.32.73.129 eq bootps
30 permit udp any eq bootpc host 255.255.255.255 eq bootps
 
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 ({{IPaddr|192.168.1.1}}) specifies the client's IP address in the YIADDR (your IP address) field.
==Technical details==
{{APHD|start|title=Example Ethernet frame with a DHCPOFFER message}}
[[Image:DHCP_session_en.svg|thumb|Schema of a typical DHCP session]]
{{APHD|0|bits1=32|border1=bottom|field1=Destination MAC|value1={{MACaddr|00:05:3c:04:8d:59}}}}
{{APHD|4|bits1=16|border1=top|field1={{nbsp}}|bits2=16|border2=bottom|field2={{nbsp}}}}
{{APHD|8|bits1=32|border1=top|field1=Source MAC|value1={{MACaddr|b4:0c:25:e3:7d:62}}}}
{{APHD|12|bits1=16|field1=EtherType|value1={{Mono|0x0800}}|hint1=0x0800 indicates IPv4|bits2=16|border2=bottom|background2=mistyrose|field2={{nbsp}}}}
{{APHD|16|bits1=0|border1=top|background1=mistyrose|field1=IPv4 packet, containing a UDP PDU with DHCP payload...}}
{{APHD|999|bits1=32|field1=Frame Check Sequence|short1=FCS}}
{{APHD|end}}
{{APHD|start|header=yew|title=IPv4 Header}}
{{APHD|0|bits1=64|field1=IPv4 header start}}
{{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol ({{Mono|17}} UDP)|field3=Header Checksum}}
{{APHD|end}}
{{APHD|start|header=no|title=UDP Header}}
{{APHD|12|bits1=32|field1=Source Address ({{IPaddr|192.168.1.1}})}}
{{APHD|16|bits1=32|field1=Destination Address ({{IPaddr|192.168.1.100}})}}
{{APHD|20|bits1=16|bits2=16|field1=Source Port (67)|field2=Destination Port (68)}}
{{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Payload: DHCPOFFER}}
{{APHD|28|bits1=8|bits2=8|bits3=8|bits4=8|field1=OP ({{Mono|0x02}})|hint1=BOOTREPLY|field2=HTYPE ({{Mono|0x01}})|field3=HLEN ({{Mono|0x06}})|field4=HOPS ({{Mono|0x00}})}}
{{APHD|32|bits1=32|field1=XID ({{Mono|0x3903F326}})}}
{{APHD|36|bits1=16|bits2=16|field1=SECS ({{Mono|0x0000}})|field2=FLAGS ({{Mono|0x0000}})}}
{{APHD|40|bits1=32|field1=CIADDR (Client IP address: {{Mono|0x00000000}})}}
{{APHD|44|bits1=32|field1=YIADDR (Your IP address: {{Mono|0xC0A80164}} or {{IPaddr|192.168.1.100}})}}
{{APHD|48|bits1=32|field1=SIADDR (Server IP address: {{Mono|0xC0A80101}} or {{IPaddr|192.168.1.1}})}}
{{APHD|52|bits1=32|field1=GIADDR (Gateway IP address: {{Mono|0x00000000}})}}
{{APHD|56|bits1=128|field1=CHADDR (Client Hardware address: {{Mono|0x00053C04<br>0x8D590000<br>0x00000000<br>0x00000000}})}}
{{APHD|72|bits1=1536|field1=192 octets of 0s, or overflow space for additional options; BOOTP legacy.}}
{{APHD|264|bits1=32|field1=[[Magic Cookie]] ({{Mono|0x63825363}})}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Options (in [[Type-length-value|TLV]] format)}}
{{APHD|268|bits1=24|background1=linen|field1=First option: {{Mono|0x350102}}: Option 53 (DHCP Message Type) 1 octet (containing DHCPOFFER)|bits2=8|background2=linen|border2=right|field2=Second option:}}
{{APHD|272|bits1=32|background1=linen|border1=left|field1={{Mono|0x0104ffffff00}}: Option 1 (Subnet mask) 4 octets (containing {{IPaddr|255.255.255.0}})}}
{{APHD|276|bits1=32|background1=linen|field1=Third option: {{Mono|0x0304c0A80101}}: Option: 3 (Router) 4 octets (containing {{IPaddr|192.168.1.1}})|border1=right}}
{{APHD|280|bits1=8|bits2=24|background1=linen|border1=left|field1=Router cont...||background2=linen|border2=right|field2=Fourth option: {{Mono|0x330400015080}}: Option 51 (Address time) 4 octets (a 86400 second lease time)}}
{{APHD|284|bits1=16|background1=linen|border1=left|field1=Address time cont...|bits2=16|border2=bottom|field2=Fifth option:|background2=linen}}
{{APHD|288|bits1=96|background1=linen|border1=top-bottom|field1={{Mono|0x060c09070a0f09070a1009070a13}}:{{Break}}Option 6 (Domain Server) 14 octets (containing {{IPaddr|9.7.10.15}},{{IPaddr|9.7.10.16}},{{IPaddr|9.7.10.18}})}}
{{APHD|300|bits1=12|background1=linen|field1=&nbsp;|border1=top|field2=<small>{{Mono|ff}}</small>|hint2=0xff Option end mark}}
{{APHD|end}}
 
===Request===
DHCP uses the same two [[Internet Assigned Numbers Authority|IANA]] assigned ports as [[BOOTP]]: 67/udp for the [[server-side|server side]], and 68/udp for the [[client-side|client side]].
In response to the DHCP offer, the client replies with a DHCPREQUEST message, broadcast to the server,{{Efn|name="optional-unicasts"|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.{{Ref RFC|2131}}{{rp|section=4.4.4}}}} 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.{{Ref RFC|2131}}{{rp|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.
DHCP operations fall into four basic phases. These phases are IP lease request, IP lease offer, IP lease selection, and IP lease acknowledgement.
{{APHD|start|title=Example Ethernet frame with a DHCPREQUEST message}}
{{APHD|0|bits1=32|border1=bottom|field1=Destination MAC|value1={{MACaddr|ff:ff:ff:ff:ff:ff}}|hint1=Destination MAC (DHCPREQUESTs are broadcast)}}
{{APHD|4|bits1=16|border1=top|field1={{nbsp}}|bits2=16|border2=bottom|field2={{nbsp}}}}
{{APHD|8|bits1=32|border1=top|field1=Source MAC|value1={{MACaddr|00:05:3c:04:8d:59}}}}
{{APHD|12|bits1=16|field1=EtherType|value1={{Mono|0x0800}}|hint1=0x0800 indicates IPv4|bits2=16|border2=bottom|background2=mistyrose|field2={{nbsp}}}}
{{APHD|16|bits1=0|border1=top|background1=mistyrose|field1=IPv4 packet, containing a UDP PDU with DHCP payload...}}
{{APHD|999|bits1=32|field1=Frame Check Sequence|short1=FCS}}
{{APHD|end}}
{{APHD|start|header=yew|title=IPv4 Header}}
{{APHD|0|bits1=64|field1=IPv4 header start}}
{{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol ({{Mono|17}} UDP)|field3=Header Checksum}}
{{APHD|end}}
{{APHD|start|header=no|title=UDP Header}}
{{APHD|12|bits1=32|field1=Source Address ({{IPaddr|0.0.0.0}})}}
{{APHD|16|bits1=32|field1=Destination Address ({{IPaddr|255.255.255.255}})}}
{{APHD|20|bits1=16|bits2=16|field1=Source Port (68)|field2=Destination Port (67)}}
{{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Payload: DHCPREQUEST}}
{{APHD|28|bits1=8|bits2=8|bits3=8|bits4=8|field1=OP ({{Mono|0x01}})|hint1=BOOTREQUEST|field2=HTYPE ({{Mono|0x01}})|field3=HLEN ({{Mono|0x06}})|field4=HOPS ({{Mono|0x00}})}}
{{APHD|32|bits1=32|field1=XID ({{Mono|0x3903F326}})}}
{{APHD|36|bits1=16|bits2=16|field1=SECS ({{Mono|0x0000}})|field2=FLAGS ({{Mono|0x0000}})}}
{{APHD|40|bits1=32|field1=CIADDR (Client IP address: {{Mono|0x00000000}})}}
{{APHD|44|bits1=32|field1=YIADDR (Your IP address: {{Mono|0x00000000}})}}
{{APHD|48|bits1=32|field1=SIADDR (Server IP address: {{Mono|0xc0a80101}} or {{IPaddr|192.168.1.1}})}}
{{APHD|52|bits1=32|field1=GIADDR (Gateway IP address: {{Mono|0x00000000}})}}
{{APHD|56|bits1=128|field1=CHADDR (Client Hardware address: {{Mono|0x00053C04<br>0x8D590000<br>0x00000000<br>0x00000000}})}}
{{APHD|72|bits1=1536|field1=192 octets of 0s, or overflow space for additional options; BOOTP legacy.}}
{{APHD|264|bits1=32|field1=[[Magic Cookie]] ({{Mono|0x63825363}})}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Options (in [[Type-length-value|TLV]] format)}}
{{APHD|268|bits1=24|background1=linen|field1=First option: {{Mono|0x350103}}: Option 53 (DHCP Message Type) 1 octet (containing DHCPREQUEST)|bits2=8|background2=linen|border2=right|field2=Second option:}}
{{APHD|272|bits1=32|background1=linen|border1=left|field1={{Mono|0x3204c0a80164}}: Option 50 (Request IP address) 4 octets (containing {{IPaddr|192.168.1.100}})|hint1=Must match YIADDR from the DHCPOFFER packet.}}
{{APHD|276|bits1=32|background1=linen|field1=Third option: {{Mono|0x3604c0a801601}}: Option: 54 (DHCP Server) 4 octets (containing {{IPaddr|192.168.1.1}})|hint1=Server Identification: tell which offer you accept.|border1=right}}
{{APHD|280|bits1=8|background1=linen|border1=left|field1=DHCP Server cont...|bits2=1|field2=<small>{{Mono|ff}}</small>|hint2=0xff Option end mark}}
{{APHD|end}}
 
===DHCP discoveryAcknowledgement===
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 client broadcasts on the local physical subnet to find available servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server on a different subnet. This client-implementation creates a [[User Datagram Protocol|UDP]] packet with the broadcast destination of 255.255.255.255 or subnet broadcast address.
 
The protocol expects the DHCP client to configure its network interface with the negotiated parameters.
A client can also request its last-known IP address (in the example below, 192.168.1.100). If the client is still in a network where this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as [http://www.isc.org/index.pl?/sw/dhcp/authoritative.php authoritative] or not. An authoritative server will deny the request, making the client ask for a new IP immediately. A non-authoritative server simply ignores the request, leading to an implementation dependent time out for the client to give up on the request and ask for a new IP.
{{APHD|start|title=Example Ethernet frame with a DHCPACK message}}
{{APHD|0|bits1=32|border1=bottom|field1=Destination MAC|value1={{MACaddr|00:05:3c:04:8d:59}}|hint1=Destination MAC (unicast to the client)}}
{{APHD|4|bits1=16|border1=top|field1={{nbsp}}|bits2=16|border2=bottom|field2={{nbsp}}}}
{{APHD|8|bits1=32|border1=top|field1=Source MAC|value1={{MACaddr|b4:0c:25:e3:7d:62}}}}
{{APHD|12|bits1=16|field1=EtherType|value1={{Mono|0x0800}}|hint1=0x0800 indicates IPv4|bits2=16|border2=bottom|background2=mistyrose|field2={{nbsp}}}}
{{APHD|16|bits1=0|border1=top|background1=mistyrose|field1=IPv4 packet, containing a UDP PDU with DHCP payload...}}
{{APHD|999|bits1=32|field1=Frame Check Sequence|short1=FCS}}
{{APHD|end}}
{{APHD|start|header=yew|title=IPv4 Header}}
{{APHD|0|bits1=64|field1=IPv4 header start}}
{{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol ({{Mono|17}} UDP)|field3=Header Checksum}}
{{APHD|end}}
{{APHD|start|header=no|title=UDP Header}}
{{APHD|12|bits1=32|field1=Source Address ({{IPaddr|192.168.1.1}})}}
{{APHD|16|bits1=32|field1=Destination Address ({{IPaddr|192.168.1.100}})}}
{{APHD|20|bits1=16|bits2=16|field1=Source Port (67)|field2=Destination Port (68)}}
{{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Payload: DHCPACK}}
{{APHD|28|bits1=8|bits2=8|bits3=8|bits4=8|field1=OP ({{Mono|0x02}})|hint1=BOOTREPLY|field2=HTYPE ({{Mono|0x01}})|field3=HLEN ({{Mono|0x06}})|field4=HOPS ({{Mono|0x00}})}}
{{APHD|32|bits1=32|field1=XID ({{Mono|0x3903F326}})}}
{{APHD|36|bits1=16|bits2=16|field1=SECS ({{Mono|0x0000}})|field2=FLAGS ({{Mono|0x0000}})}}
{{APHD|40|bits1=32|field1=CIADDR (Client IP address: {{Mono|0x00000000}})}}
{{APHD|44|bits1=32|field1=YIADDR (Your IP address: {{Mono|0xC0A80164}} or {{IPaddr|192.168.1.100}})}}
{{APHD|48|bits1=32|field1=SIADDR (Server IP address: {{Mono|0xC0A80101}} or {{IPaddr|192.168.1.1}})}}
{{APHD|52|bits1=32|field1=GIADDR (Gateway IP address: {{Mono|0x00000000}})}}
{{APHD|56|bits1=128|field1=CHADDR (Client Hardware address: {{Mono|0x00053C04<br>0x8D590000<br>0x00000000<br>0x00000000}})}}
{{APHD|72|bits1=1536|field1=192 octets of 0s, or overflow space for additional options; BOOTP legacy.}}
{{APHD|264|bits1=32|field1=[[Magic Cookie]] ({{Mono|0x63825363}})}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Options (in [[Type-length-value|TLV]] format)}}
{{APHD|268|bits1=24|background1=linen|field1=First option: {{Mono|0x350105}}: Option 53 (DHCP Message Type) 1 octet (containing DHCPACK)|bits2=8|background2=linen|border2=right|field2=Second option:}}
{{APHD|272|bits1=32|background1=linen|border1=left|field1={{Mono|0x0104ffffff00}}: Option 1 (Subnet mask) 4 octets (containing {{IPaddr|255.255.255.0}})}}
{{APHD|276|bits1=32|background1=linen|field1=Third option: {{Mono|0x0304c0A80101}}: Option: 3 (Router) 4 octets (containing {{IPaddr|192.168.1.1}})|border1=right}}
{{APHD|280|bits1=8|bits2=24|background1=linen|border1=left|field1=Router cont...||background2=linen|border2=right|field2=Fourth option: {{Mono|0x330400015080}}: Option 51 (Address time) 4 octets (a 86400 second lease time)}}
{{APHD|284|bits1=16|background1=linen|border1=left|field1=Address time cont...|bits2=16|border2=bottom|field2=Fifth option:|background2=linen}}
{{APHD|288|bits1=96|background1=linen|border1=top-bottom|field1={{Mono|0x060c09070a0f09070a1009070a13}}:{{Break}}Option 6 (Domain Server) 14 octets (containing {{IPaddr|9.7.10.15}},{{IPaddr|9.7.10.16}},{{IPaddr|9.7.10.18}})}}
{{APHD|300|bits1=12|background1=linen|field1=&nbsp;|border1=top|field2=<small>{{Mono|ff}}</small>|hint2=0xff Option end mark}}
{{APHD|end}}
 
===Selecting and configuring IP addresses===
<table border="0">
When the server is reusing an IP address from its pool, it may first check (using [[Ping (networking utility)|ping]]) to see if it is not taken already.{{Ref RFC|2131}}{{rp|sec. 2.2}} This may happen if a host is configured manually with an IP address that lies within the DHCP scope.
<tr><td valign="top">
<table class="wikitable"><caption>DHCPDISCOVER</caption>
<tr><td colspan=4>[[User Datagram Protocol|UDP]] Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67</td></tr>
<tr><th>OP</th><th>HTYPE</th><th>HLEN</th><th>HOPS</th></tr>
<tr><td>0x01</td><td>0x01</td><td>0x06</td><td>0x00</td></tr>
<tr><th colspan=4>XID</th></tr>
<tr><td colspan=4>0x3903F326</td></tr>
<tr><th colspan=2>SECS</th><th colspan=2>FLAGS</th></tr>
<tr><td colspan=2>0x0000</td><td colspan=2>0x0000</td></tr>
<tr><th colspan=4>CIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>YIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>SIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>GIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>CHADDR</th></tr>
<tr><td colspan=4>0x00053C04</td></tr>
<tr><td colspan=4>0x8D590000</td></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><td colspan=4>192 octets of 0's. [[BOOTP]] legacy</td></tr>
<tr><td colspan=4>DHCP option 53: DHCP Discover</td></tr>
<tr><td colspan=4>DHCP option 50: 192.168.1.100 requested</td></tr>
</table></td>
 
Before claiming an IP address, the client should probe the newly received address (e.g. with [[Address Resolution Protocol|ARP]]), in order to find if there is another host present in the network with the proposed IP address.{{Ref RFC|2131}}{{rp|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).
===DHCP offers===
When a DHCP server receives an IP lease request from a client, it extends an IP lease offer. This is done by reserving an IP address for the client and sending a DHCPOFFER message across the network to the client. This message contains the client's MAC address, followed by 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.
 
===Information===
The server determines the configuration, based on the client's hardware address as specified in the CHADDR field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR field.
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 [[Web Proxy Auto-Discovery Protocol|WPAD]].
 
===Releasing===
<td valign="top"><table class="wikitable"><caption>DHCPOFFER</caption>
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''.
<tr><td colspan=4>UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68 </td></tr>
<tr><th>OP</th><th>HTYPE</th><th>HLEN</th><th>HOPS</th></tr>
<tr><td>0x02</td><td>0x01</td><td>0x06</td><td>0x00</td></tr>
<tr><th colspan=4>XID</th></tr>
<tr><td colspan=4>0x3903F326</td></tr>
<tr><th colspan=2>SECS</th><th colspan=2>FLAGS</th></tr>
<tr><td colspan=2>0x0000</td><td colspan=2>0x0000</td></tr>
<tr><th colspan=4>CIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>YIADDR</th></tr>
<tr><td colspan=4>0xC0A80164</td></tr>
<tr><th colspan=4>SIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>GIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>CHADDR</th></tr>
<tr><td colspan=4>0x00053C04</td></tr>
<tr><td colspan=4>0x8D590000</td></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><td colspan=4>192 octets of 0's. [[BOOTP]] legacy</td></tr>
<tr><td colspan=4>DHCP option 53: DHCP Offer</td></tr>
<tr><td colspan=4>DHCP option 1: 255.255.255.0 subnet mask</td></tr>
<tr><td colspan=4>DHCP option 3: 192.168.1.1 router</td></tr>
<tr><td colspan=4>DHCP option 51: 1 day IP lease time</td></tr>
<tr><td colspan=4>DHCP option 54: 192.168.1.1 DHCP server</td></tr>
</table></td>
 
==Client configuration parameters==
===DHCP requests===
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.<ref name=":0">{{cite web|url=https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml|title=Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters|publisher=iana.org|access-date=2018-10-16}}</ref>
The client selects a configuration out of the DHCP "Offer" packets it has received and broadcasts it on the local subnet. Again, this client requests the 192.168.1.100 address that the server specified. In case the client has received multiple offers it specifies the server from which it has accepted the offer.
 
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''.
<td valign="top"><table class="wikitable"><caption>DHCPREQUEST</caption>
<tr><td colspan=4>UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67 </td></tr>
<tr><th>OP</th><th>HTYPE</th><th>HLEN</th><th>HOPS</th></tr>
<tr><td>0x01</td><td>0x01</td><td>0x06</td><td>0x00</td></tr>
<tr><th colspan=4>XID</th></tr>
<tr><td colspan=4>0x3903F326</td></tr>
<tr><th colspan=2>SECS</th><th colspan=2>FLAGS</th></tr>
<tr><td colspan=2>0x0000</td><td colspan=2>0x0000</td></tr>
<tr><th colspan=4>CIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>YIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>SIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>GIADDR</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>CHADDR</th></tr>
<tr><td colspan=4>0x00053C04</td></tr>
<tr><td colspan=4>0x8D590000</td></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><td colspan=4>192 octets of 0's. [[BOOTP]] legacy</td></tr>
<tr><td colspan=4>DHCP option 53: DHCP Request</td></tr>
<tr><td colspan=4>DHCP option 50: 192.168.1.100 requested</td></tr>
<tr><td colspan=4>DHCP option 54: 192.168.1.1 DHCP server.</td></tr>
</table></td>
 
==Options==
===DHCP acknowledgement===
Options are octet strings of varying length. This is called [[Type–length–value]] encoding. The first octet is the option code, the second octet is the number of following octets and the remaining octets are code dependent.
For example, the DHCP message-type option for an offer would appear as 0x35, 0x01, 0x02, where 0x35 is code 53 for "DHCP message type", 0x01 means one octet follows and 0x02 is the value of "offer".
 
The following tables list the available DHCP options.{{Ref RFC|2132}}<ref name=":0" />
When the DHCP server receives the DHCPREQUEST message from the client, it initiates the final phase of the configuration process. This 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 TCP/IP configuration process is complete.
 
{| class="wikitable sortable"
The server acknowledges the request and sends the acknowledgement to the client. The system as a whole expects the client to configure its network interface with the supplied options.
|+ RFC 1497 (BOOTP Vendor Information Extensions) vendor extensions<ref name=rfc2132/>{{rp|Section 3}}
|-
! Code !! Name !! Length !! Notes
|-
| 0 || Pad || 0 [[Octet (computing)|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 [https://datatracker.ietf.org/doc/html/rfc950 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 [[HTTP cookie|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 Network|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
|}
 
<td valign="top"><table{| class="wikitable sortable"><caption>DHCPACK</caption>
|+ IP layer parameters per host<ref name=rfc2132/>{{rp|Section 4}}
<tr><td colspan=4>UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68 </td></tr>
|-
<tr><th>OP</th><th>HTYPE</th><th>HLEN</th><th>HOPS</th></tr>
! Code !! Name !! Length !! Notes
<tr><td>0x02</td><td>0x01</td><td>0x06</td><td>0x00</td></tr>
|-
<tr><th colspan=4>XID</th></tr>
| 19 || IP forwarding enable/disable || 1 octet ||
<tr><td colspan=4>0x3903F326</td></tr>
|-
<tr><th colspan=2>SECS</th><th colspan=2>FLAGS</th></tr>
| 20 || Non-local source routing enable/disable || 1 octet ||
<tr><td colspan=2>0x0000</td><td colspan=2>0x0000</td></tr>
|-
<tr><th colspan=4>CIADDR (Client IP Address)</th></tr>
| 21 || Policy filter || Multiples of 8 octets ||
<tr><td colspan=4>0x00000000</td></tr>
|-
<tr><th colspan=4>YIADDR (Your IP Address)</th></tr>
| 22 || Maximum datagram reassembly size || 2 octets ||
<tr><td colspan=4>0xC0A80164</td></tr>
|-
<tr><th colspan=4>SIADDR (Server IP Address)</th></tr>
| 23 || Default IP time-to-live || 1 octet ||
<tr><td colspan=4>0x00000000</td></tr>
|-
<tr><th colspan=4>GIADDR (Relay IP Address)</th></tr>
| 24 || Path MTU aging timeout || 4 octets ||
<tr><td colspan=4>0x00000000</td></tr>
|-
<tr><th colspan=4>CHADDR (Client Hardware Address)</th></tr>
| 25 || Path MTU plateau table || Multiples of 2 octets ||
<tr><td colspan=4>0x00053C04</td></tr>
|}
<tr><td colspan=4>0x8D590000</td></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><td colspan=4>192 octets of 0's. [[BOOTP]] legacy</td></tr>
<tr><td colspan=4>DHCP option 53: DHCP ACK</td></tr>
<tr><td colspan=4>DHCP option 1: 255.255.255.0 subnet mask</td></tr>
<tr><td colspan=4>DHCP option 3: 192.168.1.1 router</td></tr>
<tr><td colspan=4>DHCP option 51: 1 day IP lease time</td></tr>
<tr><td colspan=4>DHCP option 54: 192.168.1.1 DHCP server</td></tr>
</table></td>
</tr></table>
 
{| class="wikitable sortable"
===DHCP selection===
|+ IP Layer Parameters per Interface<ref name=rfc2132/>{{rp|Section 5}}
When the client PC receives an IP lease offer, it must tell all the other DHCP servers that it has accepted an offer. To do this, the client broadcasts a DHCPREQUEST message containing the IP address of the server that made the offer. When the other DHCP servers receive this message, they withdraw any offers that they might have made to the client. They then return the address that they had reserved for the client back to the pool of valid addresses that they can offer to another computer. Any number of DHCP servers can respond to an IP lease request, but the client can only accept one offer per network interface card.
|-
! 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
|}
 
{| class="wikitable sortable"
===DHCP information===
|+ Link layer parameters per interface<ref name=rfc2132/>{{rp|Section 6}}
The client sends a request to the DHCP server: either to request more information than the server sent with the original DHCPACK; or to repeat data for a particular application - for example, browsers use ''DHCP Inform'' to obtain web proxy settings via [[Web Proxy Autodiscovery Protocol|WPAD]]. Such queries do not cause the DHCP server to refresh the IP expiry time in its database.
|-
! Code !! Name !! Length !! Notes
|-
| 34 || Trailer encapsulation option || 1 octet ||
|-
| 35 || ARP cache timeout || 4 octets ||
|-
| 36 || Ethernet encapsulation || 1 octet ||
|}
 
{| class="wikitable sortable"
===DHCP releasing===
|+ TCP parameters<ref name=rfc2132/>{{rp|Section 7}}
The client sends a request to the DHCP server to release the DHCP and the client unconfigures its IP address. As clients usually do not know when users may unplug them from the network, the protocol does not define the sending of ''DHCP Release'' as mandatory.
|-
! Code !! Name !! Length !! Notes
|-
| 37 || TCP default TTL || 1 octet ||
|-
| 38 || TCP keepalive interval || 4 octets ||
|-
| 39 || TCP keepalive garbage || 1 octet ||
|}
 
{| class="wikitable sortable"
===Client configuration parameters===
|+ Application and service parameters<ref name=rfc2132/>{{rp|Section 8}}
A DHCP server can provide optional configuration parameters to the client. RFC 2132 defines the available DHCP options, which are summarized here.
|-
! 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 ||
|}
 
{| class="wikitable sortable"
''RFC 1497 Vendor Extensions:''
|+ DHCP extensions<ref name=rfc2132/>{{rp|Section 9}}
Data
|-
Tag Name Length Meaning
! Code !! Name !! Length !! Notes
--- ---- ------ -------
|-
0 Pad Option 0 None
| 50 || Requested IP address || 4 octets ||
255 End Option 0 None
|-
1 Subnet Mask 4 Subnet Mask Value
| 51 || IP address lease time || 4 octets ||
2 Time Offset 4 Time Offset in
|-
Seconds from UTC
| 52 || Option overload || 1 octet ||
3 Router N×4 Router addresses
|-
4 Time Server N×4 Timeserver addresses
| 53 || DHCP message type || 1 octet ||
5 Name Server N×4 IEN-116 Server addresses
|-
6 Domain Server N×4 DNS Server addresses
| 54 || Server identifier || 4 octets ||
7 Log Server N×4 Logging Server addresses
|-
8 Quotes Server N×4 Quotes Server addresses
| 55 || Parameter request list || Minimum of 1 octet ||
9 LPR Server N×4 Printer Server addresses
|-
10 Impress Server N×4 Impress Server addresses
| 56 || Message || Minimum of 1 octet ||
11 RLP Server N×4 N RLP Server addresses
|-
12 Hostname N Hostname string
| 57 || Maximum DHCP message size || 2 octets ||
13 Boot File Size 2 Size of boot file in 512-octet
|-
blocks
| 58 || Renewal (T1) time value || 4 octets ||
14 Merit Dump File N Client to dump and name
|-
the file to dump it to
| 59 || Rebinding (T2) time value || 4 octets ||
15 Domain Name N The DNS ___domain name of the
|-
client
| 60 || Vendor class identifier || Minimum of 1 octet ||
16 Swap Server 4 Swap Server address
|-
17 Root Path N Path name for root disk
| 61 || Client identifier || Minimum of 2 octets ||
18 Extensions File N Path name for more BOOTP info
|-
| 66 || TFTP server name || Minimum of 1 octet ||
|-
| 67 || Bootfile name || Minimum of 1 octet ||
|}
 
===DHCP message types===
''IP Layer Parameters per Host:''
This table lists the DHCP message types.
These codes are the value in the DHCP extension 53, shown in the table above.
 
{| class="wikitable sortable"
19 Forward On/Off 1 Enable/Disable IP Forwarding
|+ DHCP message types
20 SrcRte On/Off 1 Enable/Disable Non-Local Source Routing
|-
21 Policy Filter N×8 Non-Local Source Routing Policy Filters
! Code !! Name !! Length !! RFC
22 Max DG Assembly 2 Max Datagram Reassembly Size
|-
23 Default IP TTL 1 Default IP Time to Live
| 1 || DHCPDISCOVER || 1 octet || {{Sum RFC|2132|plain=yes}}{{Ref RFC|2132|rsection=9.6}}
24 MTU Timeout 4 Path MTU Aging Timeout
|-
25 MTU Plateau N×2 Path MTU Plateau Table
| 2 || DHCPOFFER || 1 octet || {{Sum RFC|2132|plain=yes}}
|-
| 3 || DHCPREQUEST || 1 octet || {{Sum RFC|2132|plain=yes}}
|-
| 4 || DHCPDECLINE || 1 octet || {{Sum RFC|2132|plain=yes}}
|-
| 5 || DHCPACK || 1 octet || {{Sum RFC|2132|plain=yes}}
|-
| 6 || DHCPNAK || 1 octet || {{Sum RFC|2132|plain=yes}}
|-
| 7 || DHCPRELEASE || 1 octet || {{Sum RFC|2132|plain=yes}}
|-
| 8 || DHCPINFORM || 1 octet || {{Sum RFC|2132|plain=yes}}
|-
| 9 || DHCPFORCERENEW || 1 octet || {{Sum RFC|3203|plain=yes}}{{Ref RFC|3203|rsection=4}}
|-
| 10 || DHCPLEASEQUERY || 1 octet || {{Sum RFC|4388|plain=yes}}{{Ref RFC|4388|rsection=6.1}}
|-
| 11 || DHCPLEASEUNASSIGNED || 1 octet || {{Sum RFC|4388|plain=yes}}
|-
| 12 || DHCPLEASEUNKNOWN || 1 octet || {{Sum RFC|4388|plain=yes}}
|-
| 13 || DHCPLEASEACTIVE || 1 octet || {{Sum RFC|4388|plain=yes}}
|-
| 14 || DHCPBULKLEASEQUERY || 1 octet || {{Sum RFC|6926|plain=yes}}{{Ref RFC|6926|rsection=6.2.1}}
|-
| 15 || DHCPLEASEQUERYDONE || 1 octet || {{Sum RFC|6926|plain=yes}}
|-
| 16 || DHCPACTIVELEASEQUERY || 1 octet || {{Sum RFC|7724|plain=yes}}{{Ref RFC|7724|rsection=5.2.1}}
|-
| 17 || DHCPLEASEQUERYSTATUS || 1 octet || {{Sum RFC|7724|plain=yes}}
|-
| 18 || DHCPTLS || 1 octet || {{Sum RFC|7724|plain=yes}}
|}
 
====Client vendor identification====
''IP Layer Parameters per Interface:''
An option exists to identify the vendor and functionality of a DHCP client. The information is a [[Variable-length code|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 Networks|Aruba]] campus [[wireless access point]], for example, supplies value 'ArubaAP' as option 60 in its DHCPDISCOVER message.<ref name="option60">{{cite web|title=Aruba DHCP Option 60|date=7 October 2020 |url=https://the-ethernets.com/2020/10/aruba-dhcp-option-60/}}</ref> 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.
26 MTU Interface 2 Interface MTU Size
27 MTU Subnet 1 All Subnets are Local
28 Broadcast Address 4 Broadcast Address
29 Mask Discovery 1 Perform Mask Discovery
30 Mask Supplier 1 Provide Mask to Others
31 Router Discovery 1 Perform Router Discovery
32 Router Request 4 Router Solicitation Address
33 Static Route N×8 Static Routing Table
 
Setting a VCI by the client allows a DHCP server to differentiate between client machines and process the requests from them appropriately.
''Link Layer Parameters per Interface:''
 
===Other extensions===
34 Trailers 1 Trailer Encapsulation
{| class="wikitable sortable"
35 ARP Timeout 4 ARP Cache Timeout
|+ Documented DHCP options
36 Ethernet 1 Ethernet Encapsulation
|-
! Code !! Name !! Length !! RFC
|-
| 77 || User Class || Minimum of 2 octets || {{Sum RFC|3004|plain=yes|ref=yes}}
|-
| 82 || [[#Relay agent information sub-options|Relay agent information]] || Minimum of 2 octets || {{Sum RFC|3046|plain=yes|ref=yes}}
|-
| 85 || [[Novell Directory Service]] (NDS) servers || Minimum of 4 octets, multiple of 4 octets || {{Sum RFC|2241|plain=yes}}{{Ref RFC|2241|rsection=2}}
|-
| 86 || NDS tree name || Variable || {{Sum RFC|2241|plain=yes}}{{Ref RFC|2241|rsection=3}}
|-
| 87 || NDS context || Variable || {{Sum RFC|2241|plain=yes}}{{Ref RFC|2241|rsection=4}}
|-
| 100 || [[Time zone]], POSIX style || Variable || {{Sum RFC|4833|plain=yes|ref=yes}}
|-
| 101 || [[Time zone]], [[tz database]] style || Variable || {{Sum RFC|4833|plain=yes}}
|-
| 114 || DHCP Captive-Portal || Variable || {{Sum RFC|8910|plain=yes|ref=yes}}
|-
| 119 || [[Search ___domain|Domain search]] || Variable || {{Sum RFC|3397|plain=yes|ref=yes}}
|-
| 121 || Classless static route || Variable || {{Sum RFC|3442|plain=yes|ref=yes}}
|-
| 209 || Configuration File || Variable || {{Sum RFC|5071|plain=yes|ref=yes}}
|-
| 210 || Path Prefix || Variable || {{Sum RFC|5071|plain=yes}}
|-
| 211 || Reboot Time || Variable || {{Sum RFC|5071|plain=yes}}
|}
 
====Relay agent information sub-options====
''TCP Parameters:''
The relay agent information option (option 82) specifies container for attaching sub-options to DHCP requests transmitted between a DHCP relay and a DHCP server.<ref name="ietf_spec_dhcp82">{{cite journal|last1=Patrick|first1=Michael|title=DHCP Relay Agent Information Option|url=https://tools.ietf.org/html/rfc3046|website=IETF Documents|publisher=[[IETF]]|access-date=22 July 2017|doi=10.17487/RFC3046|date=January 2001|doi-access=|url-access=subscription}}</ref>
 
{| class="wikitable sortable"
37 Default TCP TTL 1 Default TCP Time to Live
|+ Relay agent sub-options
38 Keepalive Time 4 TCP Keepalive Interval
|-
39 Keepalive Data 1 TCP Keepalive Garbage
! Code !! Name !! Length !! RFC
|-
| 1 || Agent Circuit ID || Minimum of 1 octet || {{Sum RFC|3046|plain=yes|ref=yes}}
|-
| 2 || Agent Remote ID || Minimum of 1 octet || {{Sum RFC|3046|plain=yes}}
|-
| 4 || Data-Over-Cable Service Interface Specifications (DOCSIS) device class || 4 octets || {{Sum RFC|3256|plain=yes|ref=yes}}
|}
 
==Relaying==
''Application and Service Parameters:''
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 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.
40 NIS Domain N NIS Domain Name
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.
41 NIS Servers N×4 NIS Server Addresses
The DHCP server uses the GIADDR-value to determine the subnet, and subsequently the corresponding address pool, from which to allocate an IP address.
42 NTP Servers N×4 NTP Server Addresses
When the DHCP server replies to the client, it sends the reply to the GIADDR-address, again using unicast.
43 Vendor Specific N Vendor Specific Information
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.
44 NETBIOS Name Srv N×4 NETBIOS Name Servers
The client should accept the packet as its own, even when that IP address is not yet set on the interface.{{Ref RFC|2131|rp=25}}
45 NETBIOS Dist Srv N×4 NETBIOS Datagram Distribution
Directly after processing the packet, the client sets the IP address on its interface and is ready for regular IP communication, directly thereafter.
46 NETBIOS Node Type 1 NETBIOS Node Type
47 NETBIOS Scope N NETBIOS Scope
48 X Window Font N×4 X Window Font Server
49 X Window Manager N×4 X Window Display Manager
64 NIS-Domain-Name N NIS+ v3 Client Domain Name
65 NIS-Server-Addr N×4 NIS+ v3 Server Addresses
68 Home-Agent-Addrs N×4 Mobile IP Home Agent Addresses
69 SMTP-Server N×4 Simple Mail Server Addresses
70 POP3-Server N×4 Post Office Server Addresses
71 NNTP-Server N×4 Network News Server Addresses
72 WWW-Server N×4 WWW Server Addresses
73 Finger-Server N×4 Finger Server Addresses
74 IRC-Server N×4 Chat Server Addresses
75 StreetTalk-Server N×4 StreetTalk Server Addresses
76 STDA-Server N×4 ST Directory Assist. Addresses
 
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.
''DHCP Extensions:''
The relay agent will use the {{IPaddr|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.
50 Address Request 4 Requested IP Address
51 Address Time 4 IP Address Lease Time
52 Option Overload 1 Overload "sname" or "file"
53 DHCP Msg Type 1 DHCP Message Type
54 DHCP Server Id 4 DHCP Server Identification
55 Parameter List N Parameter Request List
56 DHCP Message N DHCP Error Message
57 DHCP Max Msg Size 2 DHCP Maximum Message Size
58 Renewal Time 4 DHCP Renewal (T1) Time
59 Rebinding Time 4 DHCP Rebinding (T2) Time
60 Class Id N Vendor Class Identifier
61 Client Id N Client Identifier
66 Server-Name N TFTP Server Name
67 Bootfile-Name N Boot File Name
 
==Client states==
''Newer extensions:''
[[File:Dhcp-client-state-diagram.svg|thumb|A simplified DHCP client state-transition diagram based on figure 5 of RFC 2131]]
 
A DHCP client can receive these messages from a server:{{Ref RFC|2131|rsection=4.4}}
62 Netware/IP Domain N Netware/IP Domain Name
* DHCPOFFER
63 Netware/IP Option N Netware/IP sub Options
* DHCPACK
77 User-Class N User Class Information
* DHCPNAK
78 Directory Agent N directory agent information
 
79 Service Scope N service ___location agent scope
The client moves through DHCP states depending on how the server responds to the messages that the client sends.
80 Rapid Commit 0 Rapid Commit
 
81 Client FQDN N Fully Qualified Domain Name
==Reliability==
82 Relay Agent Information N Relay Agent Information, RFC 3046
The DHCP ensures reliability in several ways: periodic renewal, rebinding,{{Ref RFC|2131|rsection=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.{{Ref RFC|2131|rsection=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,{{Ref RFC|2131|rsection=4.4.5 Paragraph 8}}{{Efn|The RFC calls for the client to wait one half of the remaining time until T2 before it retransmits the ''DHCPREQUEST'' packet}} so if the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it and renew the lease.
83 iSNS N Internet Storage Name Service
 
84 REMOVED/Unassigned
If the DHCP server is unreachable for an extended period of time,{{Ref RFC|2131|rsection=4.4.5 Paragraph 5}} the DHCP client will attempt to rebind, by broadcasting its ''DHCPREQUEST'' rather than unicasting it. Because it is [[Broadcasting (networking)|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.
85 NDS Servers N Novell Directory Services
 
86 NDS Tree Name N Novell Directory Services
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.<ref>{{cite IETF
87 NDS Context N Novell Directory Services
| title = DHCP Failover Protocol
88 BCMCS Controller Domain Name list
| draft = draft-ietf-dhc-failover-12
89 BCMCS Controller IPv4 address option
| last1 = Droms | first1 = Ralph
90 Authentication N Authentication
| last2 = Kinnear | first2 = Kim
91-92 REMOVED/Unassigned
| last3 = Stapp | first3 = Mark
93 Client System N Client System Architecture
| last4 = Volz | first4 = Bernie
94 Client NDI N Client Network Device Interface
| last5 = Gonczi | first5 = Steve
95 LDAP N Lightweight Directory Access Protocol
| last6 = Rabil | first6 = Greg
96 REMOVED/Unassigned
| last7 = Dooley | first7 = Michael
97 UUID/GUID N UUID/GUID-based Client Identifier
| last8 = Kapur | first8 = Arun
98 User-Auth N Open Group's User Authentication
| date = March 2003
99-111 REMOVED/Unassigned
| publisher = [[IETF]]
112 Netinfo Address N NetInfo Parent Server Address
| access-date = May 9, 2010
113 Netinfo Tag N NetInfo Parent Server Tag
}}</ref>{{Efn|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.}}
114 URL N URL
 
115 REMOVED/Unassigned
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.{{Ref RFC|2131|rsection=4.4.5 Paragraph 9}} At that time it will restart the DHCP process from the beginning by broadcasting a <code>DHCPDISCOVER</code> 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.
116 Auto-Config N DHCP Auto-Configuration
 
117 Name Service Search N Name Service Search
==IPv6 networks==
118 Subnet Selection Option 4 Subnet Selection Option
The 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]].<ref name=":1">{{Cite web|url=https://www.networkworld.com/article/3297800/why-dhcps-days-might-be-numbered.html|title=Why DHCP's days might be numbered|last=Weinberg|first=Neal|date=2018-08-14|website=Network World|language=en|access-date=2019-08-07}}</ref>
119 Domain Search N DNS ___domain search list
 
120 SIP Servers DHCP Option N SIP Servers DHCP Option
==Security==
121 Classless Static Route N Classless Static Route Option
{{see also|DHCP snooping}}
Option
The base DHCP does not include any mechanism for authentication.{{Ref RFC|3046|rsection=7}}
122 CCC N CableLabs Client Configuration
Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:{{Ref RFC|2131}}{{rp|sec. 7}}
123 GeoConf Option 16 GeoConf Option
 
124 V-I Vendor Class Vendor-Identifying Vendor Class
* Unauthorized DHCP servers providing false information to clients.
125 V-I Vendor-Specific Vendor-Identifying Vendor-Specific
* Unauthorized clients gaining access to resources.
Information Information
* Resource exhaustion attacks from malicious DHCP clients.
126-127 Removed/Unassigned
 
128 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
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.<ref name="Stapko2011"/> This can serve either as a [[denial-of-service attack]], preventing the client from gaining access to network connectivity,<ref name="Rountree2013">{{cite book |first= Derrick |last=Rountree |title = Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure |url = https://books.google.com/books?id=NFzou_d4MGUC&pg=SA2-PA13 |year = 2013 |publisher = Newnes |isbn = 978-1-59749-965-1 |page = 22 }}</ref> or as a [[man-in-the-middle attack]].<ref name="Rooney2011">{{cite book |first= Timothy |last=Rooney |title = Introduction to IP Address Management |url = https://books.google.com/books?id=QgRDxkuI1MkC&pg=PA180 |year = 2010 |publisher = John Wiley & Sons |isbn = 978-1-118-07380-3 |page = 180 }}</ref> Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,{{Ref RFC|2131}}{{rp|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.<ref name="DNSRedirect">{{cite web |url = http://www.securelist.com/en/blog/208188095/TDSS_loader_now_got_legs |title = TDSS loader now got "legs" |first= Sergey |last=Golovanov (Kaspersky Labs) |date = June 2011 | archive-url=https://web.archive.org/web/20210125194521/https://securelist.com/tdss-loader-now-got-legs/30844/| archive-date=25 January 2021}}</ref> 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.<ref name="DNSRedirect" />
128 Etherboot signature. 6 bytes: E4:45:74:68:00:00
 
128 DOCSIS "full security" server IP address
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.<ref name="Stapko2011"/> 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.<ref name="Stapko2011">{{cite book |first= Timothy |last=Stapko |title = Practical Embedded Security: Building Secure Resource-Constrained Systems |url = https://books.google.com/books?id=Mly55VntuYMC&pg=PA39 |year = 2011 |publisher = Newnes |isbn = 978-0-08-055131-9 |page = 39 }}</ref>
128 TFTP Server IP address (for IP Phone software load)
 
129 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
DHCP does provide some mechanisms for mitigating these problems. The [[#Relay agent information sub-options|Relay Agent Information Option]] protocol extension{{Ref RFC|3046}} (usually referred to in the industry by its actual number as ''Option 82''<ref name="HensCaballero2008">{{cite book |first1 = Francisco J. |last1=Hens |first2 = José M. |last2=Caballero |title = Triple Play: Building the converged network for IP, VoIP and IPTV |url = https://books.google.com/books?id=aS1ZngveBIkC&pg=PA239 |year = 2008 |publisher = John Wiley & Sons |isbn = 978-0-470-75439-9 |page = 239 }}</ref><ref name="Ramirez2008">{{cite book |first= David H. |last=Ramirez |title = IPTV Security: Protecting High-Value Digital Contents |url = https://books.google.com/books?id=70tr_hSDULwC&pg=PA55 |year = 2008 |publisher = John Wiley & Sons |isbn = 978-0-470-72719-5 |page = 55 }}</ref>) 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.{{Ref RFC|3046}}{{rp|sec. 7}}
129 Kernel options. Variable length string
 
129 Call Server IP address
Another extension, Authentication for DHCP Messages{{Ref RFC|3118}} (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.<ref>{{cite web |url = http://www.ietf.org/mail-archive/web/dhcwg/current/msg00876.html |title = Implementation of RFC 3118 |first= Ted |last=Lemon |date = April 2002 }}</ref> A 2007 book about DSL technologies remarked that:<blockquote>[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.<ref name="GoldenDedieu2007">{{cite book |first1 = Philip |last1=Golden |first2 = Hervé |last2=Dedieu |first3 = Krista S. |last3=Jacobsen |title = Implementation and Applications of DSL Technology |url = https://books.google.com/books?id=Jjkd74jY47oC&pg=PA484 |year = 2007 |publisher = Taylor & Francis |isbn = 978-1-4200-1307-8 |page = 484 }}</ref></blockquote> A 2010 book notes that:<blockquote>[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.<ref name="Rooney2011b">{{cite book |first= Timothy |last=Rooney |title = Introduction to IP Address Management |url = https://books.google.com/books?id=QgRDxkuI1MkC&pg=PA181 |year = 2010 |publisher = John Wiley & Sons |isbn = 978-1-118-07380-3 |pages = 181–182 }}</ref></blockquote>
130 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
 
130 Ethernet interface. Variable length string.
Architectural proposals from 2008 involve authenticating DHCP requests using [[802.1X]] or [[Protocol for Carrying Authentication for Network Access|PANA]] (both of which transport [[Extensible Authentication Protocol|EAP]]).<ref name="Copeland2008">{{cite book |first= Rebecca |last=Copeland |title = Converging NGN Wireline and Mobile 3G Networks with IMS |url = https://books.google.com/books?id=ruWv8RGkBGgC&pg=PA142 |year = 2008 |publisher = Taylor & Francis |isbn = 978-1-4200-1378-8 |pages = 142–143 }}</ref> An IETF proposal was made for including EAP in DHCP itself, the so-called <abbr>EAPoDHCP</abbr>;<ref name="PrasadMihovska2009">{{cite book |first1 = Ramjee |last1=Prasad |first2 = Albena |last2=Mihovska |title = New Horizons in Mobile and Wireless Communications: Networks, services, and applications |url = https://books.google.com/books?id=w9bEwBwd33MC&pg=PA339 |year = 2009 |publisher = Artech House |isbn = 978-1-60783-970-5 |page = 339 |volume = 2 }}</ref> this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.<ref>{{cite web |url=http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 |title=Draft-pruss-DHCP-auth-DSL-07 - EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband |access-date=2013-12-12 |archive-url=https://web.archive.org/web/20150403091552/http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 |archive-date=2015-04-03 }}</ref>
130 Discrimination string (to identify vendor)
 
131 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
==IETF standards documents==
131 Remote statistics server IP address
* {{Sum RFC|2131|ref=yes}}
132 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
* {{Sum RFC|2132|ref=yes}}
132 802.1P VLAN ID
* {{Sum RFC|3046|ref=yes}}
133 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
* {{Sum RFC|3203|ref=yes}}
133 802.1Q L2 Priority
* {{Sum RFC|3397|ref=yes}}
134 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
* {{Sum RFC|3442|ref=yes}}
134 Diffserv Code Point
* {{Sum RFC|3942|ref=yes}}
135 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
* {{Sum RFC|4361|ref=yes}}
135 HTTP Proxy for phone-specific applications
* {{Sum RFC|4388|ref=yes}}
136-149 Unassigned
* {{Sum RFC|4436|ref=yes}}
150 TFTP server address (Tentatively Assigned - [[23 June]] [[2005]])
* {{Sum RFC|6926|ref=yes}}
150 Etherboot
* {{Sum RFC|7724|ref=yes}}
150 GRUB configuration path name
* {{Sum RFC|8415|ref=yes}}
151-174 Unassigned
175 Etherboot (Tentatively Assigned - [[23 June]] [[2005]])
176 IP Telephone (Tentatively Assigned - [[23 June]] [[2005]])
177 Etherboot (Tentatively Assigned - [[23 June]] [[2005]])
177 PacketCable and CableHome (replaced by 122)
178-207 Unassigned
208 pxelinux.magic (string) = F1:00:74:7E (241.0.116.126) (Tentatively
Assigned - [[23 June]] [[2005]])
209 pxelinux.configfile (text) (Tentatively Assigned - [[23 June]] [[2005]])
210 pxelinux.pathprefix (text) (Tentatively Assigned - [[23 June]] [[2005]])
211 pxelinux.reboottime (unsigned integer 32 bits) (Tentatively Assigned
- [[23 June]] [[2005]])
212-219 Unassigned
220 Subnet Allocation Option (Tentatively Assigned - [[23 June]] [[2005]])
221 Virtual Subnet Selection Option (Tentatively Assigned - [[23 June]] [[2005]])
222-223 Unassigned
224-254 Private Use
 
==See also==
{{cols}}
*[[Bootstrap Protocol]] (BOOTP)
* [[Boot Service Discovery Protocol]] (BSDP){{snd}} a DHCP extension used by Apple's [[NetBoot]]
*[[Peg DHCP]] RFC 2322
* [[Comparison of DHCP server software]]
*[[Preboot Execution Environment]] (PXE)
* {{Ref RFC|2322|ref=no}}
*[[Reverse Address Resolution Protocol]] (RARP)
* [[Preboot Execution Environment]] (PXE)
*[[Rogue DHCP]]
* [[Reverse Address Resolution Protocol]] (RARP)
*[[udhcpc]] - light version for embedded systems
* [[Rogue DHCP]]
*[[Zeroconf|Zero Configuration Networking]] (Zeroconf)
* [[UDP Helper Address]]{{snd}} a tool for routing DHCP requests across subnet boundaries
* [[Zeroconf]]{{snd}} Zero Configuration Networking
* [[Kea (software)|Kea]] – an open-source DHCP server developed by the [[Internet Systems Consortium]]
{{colend}}
 
==External linksNotes==
{{Notelist}}
*RFC 2131 - Dynamic Host Configuration Protocol
*RFC 2132 - DHCP Options and BOOTP Vendor Extensions
*[http://www.bind9.net/rfc-dhcp DHCP RFC] - Dynamic Host Configuration Protocol RFC's (IETF)
*[http://www.windowsecurity.com/articles/DHCP-Security-Part1.html DHCP Server Security] - This article looks at the different types of threats faced by DHCP servers and counter-measures for mitigating these threats.
*RFC 4242 - Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
*[http://www.eventhelix.com/RealtimeMantra/Networking/DHCP.pdf DHCP Sequence Diagram] - This sequence diagram covers several scenarios of DHCP operation.
*RFC 3046, [http://www.odva.org/10_2/03_events/New-EtherNet/PUB0088R0%20ODVA%20DHCP%20Option%2082v2.pdf Recommended Operation for Switches Running Relay Agent and Option 82] describes how DHCP option 82 works
*RFC 4361 - Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
*[http://support.microsoft.com/kb/169289 DHCP Protocol Messages] - A good description of the individual DHCP protocol messages.
 
==References==
[[Category:Internet protocols]]
{{Reflist|30em}}
[[Category:Internet standards]]
[[Category:Application layer protocols]]
 
== External links ==
[[af:DHCP]]
 
[[ar:بروتوكول التشكيل الدينامي]]
[[bs:* {{commons category-inline|Dynamic Host Configuration Protocol]] (DHCP)}}
 
[[cs:Dynamic Host Configuration Protocol]]
{{Authority control}}
[[da:DHCP]]
 
[[de:Dynamic Host Configuration Protocol]]
[[Category:Application layer protocols]]
[[et:Dünaamiline hostikonfiguratsiooni protokoll]]
[[Category:Internet Standards]]
[[el:DHCP]]
[[Category:Network service]]
[[es:DHCP]]
[[eu:DHCP]]
[[fr:Dynamic Host Configuration Protocol]]
[[id:DHCP]]
[[it:DHCP]]
[[he:Dynamic Host Configuration Protocol]]
[[hu:DHCP]]
[[nl:Dynamic Host Configuration Protocol]]
[[ja:Dynamic Host Configuration Protocol]]
[[no:DHCP]]
[[pl:DHCP]]
[[pt:DHCP]]
[[ru:DHCP]]
[[simple:Dynamic Host Configuration Protocol]]
[[sk:Dynamic Host Configuration Protocol]]
[[sl:DHCP]]
[[fi:DHCP]]
[[sv:DHCP]]
[[th:Dynamic Host Configuration Protocol]]
[[tr:DHCP]]
[[uk:DHCP]]
[[zh:DHCP]]
Retrieved from "https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol"